Utilización de ANKI en la preparación de las oposiciones

[John Doe]

A quien pueda interesar.

He compartido una serie de nuevos mazos con el temario de TAI - OEP 2018.

Si bien conocí la aplicación gracias al compañero Julivert, lo cual le agradezco, he elaborado estas cartas a partir de libros e internet, conforme avanzaba en el estudio.

Paso a listar las urls. Recuerdo a los que ya tengan instalada la app que pueden buscarlos directamente, término recomendado: Temario TAI.

B. I: https://ankiweb.net/shared/info/415530049
B. II: https://ankiweb.net/shared/info/267106480
B. III: https://ankiweb.net/shared/info/2068746965
B: IV: https://ankiweb.net/shared/info/1234202326

* El contenido debe ser considerado como una base a ampliar durante el estudio.
** Hay tarjetas repetidas, sobre todo en el B. IV.

Espero que os resulte de utilidad. Un saludo.

[erprofe32]

He encontrado errores en un par de preguntas en ANKI.
Aparece que 802.3ae es 10 Gbps. Par trenzado y 802.3an es 10 Gbps Fibra, cuando es al revés.
Lo correcto es 802.3ae 10 Gbps. Fibra y 802.3an 10 Gbps. Par trenzado.

[John Doe]

He encontrado errores en un par de preguntas en ANKI.
Aparece que 802.3ae es 10 Gbps. Par trenzado y 802.3an es 10 Gbps Fibra, cuando es al revés.
Lo correcto es 802.3ae 10 Gbps. Fibra y 802.3an 10 Gbps. Par trenzado.

Corregido. Gracias por el feedback.

[John Doe]

Actualización.

Bloque IV:

Eliminadas: 48 tarjetas duplicadas.
Corregidas: 802.3ae/an y 802.3ab/z.
Añadidas: CCN-CERT ATENEA, Droid Crypter, Droid Wiper y CLAUDIA.

[erprofe32]

Actualización.

Bloque IV:

Eliminadas: 48 tarjetas duplicadas.
Corregidas: 802.3ae/an y 802.3ab/z.
Añadidas: CCN-CERT ATENEA, Droid Crypter, Droid Wiper y CLAUDIA.

Gracias a ti de nuevo, menudo currazo, yo solo he comunicado esos fallos.
Aprovecho para preguntaros una duda sobre el código de estado http 102.
En ANKI dice Processing. Reanudar peticiones PUT o POST abortadas.
En la Wikipedia dice processing pero lo de reanudar peticiones PUT o POST abortadas lo pone para el código 103 https://es.wikipedia.org/wiki/Anexo:C%C ... stado_HTTP
Esto también lo indican en otras web https://uniwebsidad.com/tutoriales/los- ... do-de-http
Mientras que otras indican que tal como lo tenemos en ANKI está correcto https://diego.com.es/codigos-de-estado-http
¿Alguien puede aportar algo para dejarlo claro?
Gracias.

[John Doe]

Actualización.

Bloque IV:

Eliminadas: 48 tarjetas duplicadas.
Corregidas: 802.3ae/an y 802.3ab/z.
Añadidas: CCN-CERT ATENEA, Droid Crypter, Droid Wiper y CLAUDIA.

Gracias a ti de nuevo, menudo currazo, yo solo he comunicado esos fallos.
Aprovecho para preguntaros una duda sobre el código de estado http 102.
En ANKI dice Processing. Reanudar peticiones PUT o POST abortadas.
En la Wikipedia dice processing pero lo de reanudar peticiones PUT o POST abortadas lo pone para el código 103 https://es.wikipedia.org/wiki/Anexo:C%C ... stado_HTTP
Esto también lo indican en otras web https://uniwebsidad.com/tutoriales/los- ... do-de-http
Mientras que otras indican que tal como lo tenemos en ANKI está correcto https://diego.com.es/codigos-de-estado-http
¿Alguien puede aportar algo para dejarlo claro?
Gracias.

He echado un vistazo a los RFC de ambos:

102: https://tools.ietf.org/html/rfc2518#section-10.1
103: https://tools.ietf.org/html/rfc8297#section-2

En ninguna de las secciones que describen la función del código se mencionan las peticiones PUT o POST. Ahora bien, tampoco coincide el nombre que las dos primeras webs dan al código 103, que ellas llaman Checkpoint, mientras que su RFC lo nombra Early Hints.

A grosso modo podemos hacernos una idea de la función de cada uno de los códigos:

102: Indica al cliente que el servidor ha aceptado la petición, pero que aún no la ha completado.
103: Indica al cliente que el servidor incluirá los campos de cabecera dentro de la respuesta.

Creo, y espero vuestra respuesta, que lo mejor sería limitar la tarjeta a Processing. Aprovecho para añadir el 103, seré fiel al RFC y lo nombraré Early Hints, sin descripciones que den lugar a equívoco.

[erprofe32]

Actualización.

Bloque IV:

Eliminadas: 48 tarjetas duplicadas.
Corregidas: 802.3ae/an y 802.3ab/z.
Añadidas: CCN-CERT ATENEA, Droid Crypter, Droid Wiper y CLAUDIA.

Gracias a ti de nuevo, menudo currazo, yo solo he comunicado esos fallos.
Aprovecho para preguntaros una duda sobre el código de estado http 102.
En ANKI dice Processing. Reanudar peticiones PUT o POST abortadas.
En la Wikipedia dice processing pero lo de reanudar peticiones PUT o POST abortadas lo pone para el código 103 https://es.wikipedia.org/wiki/Anexo:C%C ... stado_HTTP
Esto también lo indican en otras web https://uniwebsidad.com/tutoriales/los- ... do-de-http
Mientras que otras indican que tal como lo tenemos en ANKI está correcto https://diego.com.es/codigos-de-estado-http
¿Alguien puede aportar algo para dejarlo claro?
Gracias.

He echado un vistazo a los RFC de ambos:

102: https://tools.ietf.org/html/rfc2518#section-10.1
103: https://tools.ietf.org/html/rfc8297#section-2

En ninguna de las secciones que describen la función del código se mencionan las peticiones PUT o POST. Ahora bien, tampoco coincide el nombre que las dos primeras webs dan al código 103, que ellas llaman Checkpoint, mientras que su RFC lo nombra Early Hints.

A grosso modo podemos hacernos una idea de la función de cada uno de los códigos:

102: Indica al cliente que el servidor ha aceptado la petición, pero que aún no la ha completado.
103: Indica al cliente que el servidor incluirá los campos de cabecera dentro de la respuesta.

Creo, y espero vuestra respuesta, que lo mejor sería limitar la tarjeta a Processing. Aprovecho para añadir el 103, seré fiel al RFC y lo nombraré Early Hints, sin descripciones que den lugar a equívoco.

Opino como tú. Visto lo confuso que está en diferentes webs, lo mejor dejar 102 como Processing únicamente y 103 Early Hints.

[ymvs84]

Hola a todos!!

No conocía nada de esta aplicación y mira... una gran ayuda.
Muchas gracias a todos los que habéis compartido todo esto