7 adversidades que tienes que superar en tus inicios como programador

06/10/2017
Artículo original

Alambre de espino cerca de Menin-Francia, Enero de 1940 - Fotografía de libre disposición del Reino Unido

Aprender a programar, y nos referimos a un lenguaje concreto, sino al oficio, es algo que no viene sin esfuerzo. Muchos programadores cuando empiezan a menudo se enfrentan a los mismos obstáculos. En este artículo analizaremos las principales adversidades a las que se enfrenta un programador intentando dar consejos sobre cómo superarlas.

La idea es prevenir a todos aquellos desarrolladores y programadores noveles sobre algunas de las principales frustraciones de la profesión para que intenten atajarlas lo mejor posible y facilitarles la entrada en este oficio tan apasionante y prometedor.

Las dificultades que citaremos a continuación no son las únicas a las que se enfrenta un programador en formación, pero se podría decir que son las más comunes. Si eres programador y quieres añadir alguna más, te animamos a que lo hagas en la sección de comentarios para completar esta entrada.

1. Estar atascado

Una de las peores cosas que le pasa a todo el mundo cuando empieza en cualquier actividad con algún grado de complejidad es quedarse atascado. Puede que estés intentando instalar algo y no puedes continuar porque el sistema te da un error incomprensible, o quieres añadir una ruta a tu aplicación y la aplicación te da un pantallazo sin más, sin un triste mensaje de error. ¿Qué hacer? No hay un camino claro a seguir.

En primer lugar decir que el hecho de quedarse atascado es el pan de cada día de los programadores - y no solo los principiantes. Hay que aprender a ser un poco indulgentes con nosotros mismos. Hay días en los que parece que no avanzamos, y en los que estar atascado es la norma. Pero en verdad esos periodos de frustración son la base para progresar. No hay aprendizaje sin frustración.

El enfoque que debemos tener es el siguiente: lo más común es no avanzar y cada vez que lo hagamos, tenemos que celebrarlo y sentirnos orgullosos. Si no eres capaz de gestionar la frustración y buscarle un enfoque positivo, quizás nunca serás un buen programador.

Hay muchas formas de intentar salir de un bloqueo de este tipo, hay miles de recursos en la web, foros llenos de comentarios y de situaciones que te pueden ayudar. La forma de salir de un estado de enrocamiento es simplemente solucionar el problema para seguir avanzado. Esto es fácil de decir pero difícil de hacer.

La mejor táctica en estos casos es pensar que la barrera que tenemos enfrente es una grandísima oportunidad para aprender algo nuevo. Para ello tenemos que aprender a desarrollar nuestra paciencia. No es recomendable chocar contra el muro a lo loco intentando solventar el problema mal y pronto.

Lo más aconsejable es coger perspectiva e investigar sobre el problema, familiarizándose con la tecnología en la que estamos. Si entendemos a la perfección la raíz del problema aunque no seamos capaces de arreglarlo a la hora de hacer que el software funcione, ya habremos hecho grandes progresos. Esta forma de gestionar las frustraciones, aprendiendo de cada una de ellas, hará que a la larga avancemos más rápido, evitando obstáculos y atascos programando.

2. La soledad del programador

Otra gran fuente de frustraciones viene de programar de forma solitaria. Cuando empezamos a programar no nos vemos obligados a formar parte de un equipo de desarrollo. Estamos todo el tiempo solos, haciendo algún curso enlatado o leyendo una documentación infumable, y no somos capaces de avanzar. Además, si tenemos un programador senior a mano en la empresa, nos da un poco de reparo interrumpirles ya que no queremos invadir su tiempo de programación y su proceso mental, ya que para muchos de los programadores experimentados estos momentos de máxima concentración son sagrados. Es muy incómodo interrumpir a un compañero cuando está programando.

La experiencia nos muestra que, en general, los programadores son seres solitarios que llevan bien el aislamiento. Quizás es muy aventurado decir que la programación es un deporte en equipo, que no siempre lo es, pero sí podemos afirmar que es una actividad en la que se ven implicadas varias personas, y es de alguna manera un oficio social. Un código no es bueno porque nos gusta solo a nosotros, es bueno cuando un equipo y un jefe de desarrollo o de producto dan su visto bueno. El mejor código siempre nace del consenso.

Hoy en día se utilizan hasta el extremo acrónimos anglosajones para debatir qué hace que un código sea bueno. El principio DRY (no te repitas), o los principios SOLID de la programación orientada a objetos para hacer software robusto, el KISS (el diseño debe ser sencillo), o el SRP (Principio de responsabilidad única) que sostiene que una clase o módulo debe tener una sola razón para cambiar, porque debe tener una sola responsabilidad y el YAGNI (ahorra tiempo y esfuerzo implementando solo lo necesario), etc...

Estos principios surgen cuando los programadores tienen que revisar y dar mantenimiento al código de otros programadores, y empiezan a determinar qué prácticas hacen que un software sea posible y más fácil de mantener y cuales provocan lo contrario. Esta forma de trabajar hace que todos seamos mejores programadores.

En campusMVP siempre hemos sostenido que la mejor forma de aprender a programar es programando (de perogrullo, sí, pero luego no se aplica en mucha de la formación que hay por ahí). En consecuencia, al tener que aprender haciendo, hace que el aprendizaje de la programación sea una actividad social. Necesitas a alguien que te proporcione otras ideas o diferentes enfoques, y también que evalúe la calidad del código que estás programando.

3. Los despistes

Una de las mayores barreras que tenemos que superar en la rutina diaria como programadores son los despistes. La sintaxis de muchos lenguajes de programación puede ser enrevesada y difícil de retener y recordar. O lo que es peor: muy parecida de unos a otros y debes trabajar con varios de ellos. Esto forma parte inherente de la complejidad de la programación: tenemos que ser capaces de acordarnos de miles de pequeños detalles.

Para mitigar el problema podemos ser metódicos a la hora de documentarnos. Es buena idea tener la documentación de lo que estemos usando a mano, para poder acceder a ella a golpe de teclado.

Otra práctica recomendable es ejercitar la memoria por medio de la repetición. Podemos, por ejemplo, escribir en un blog técnico documentando aquellas cosas que nos hayan resultado complicadas, y describiendo cómo las hemos resuelto. Un buen truco es compartirlo con nuestros compañeros para que comenten lo que quieran y nos ayuden a mejorar. Las bitácoras, si somos capaces de mantenerlas en el tiempo, también nos ayudan a ver lo lejos que hemos llegado al echar la vista atrás.

Otra técnica de repetición es decir las cosas en voz alta. La memoria auditiva está infravalorada. Evidentemente no te vas a poner a hablar como un loco en una sala llena de programadores, pero podemos buscar un lugar apropiado y a un compañero dispuesto a comentar un extracto de código complicado.

Por último, otra técnica es que nos busquemos un reto de programación semanal. Perfila retos que te ayuden a mejorar en aquellas cosas en las que sueles fallar programando.

4. No temas a la revisión por pares

La revisión por pares es algo muy común en el mundo de la programación. Lo mejor es acostumbrarse a ello y verlo como una oportunidad de mejora. Es mucho peor no hacer la revisión por pares que hacerla para todas las partes implicadas. No hay que tenerle miedo.

Es una oportunidad de mejora para el programador y es bueno hacerlo a todos los niveles, incluso entre programadores senior. Nunca se sabe cuándo algún compañero puede identificar un algoritmo mejor en relación con la tarea en la que estamos trabajando.

También es bueno para la empresa ya que pueden ver ayudarnos a ajustarnos a los estándares de la empresa y saber si tu trabajo está hecho conforme a los mismos. Quizás tenemos mucha proyección dentro de la empresa y es una forma de identificarlo.

Otro aspecto positivo es que nos obliga a entender el por qué hacemos las cosas. Y si no lo entendemos, nos obliga a hacer preguntas sobre el diseño y el código de las aplicaciones. Lo que no queremos es llegar a las sesiones de revisión y no estar alineados con los estándares de la empresa. Queremos que nuestro código sea consistente con el resto del software que se hace.

5. No internalizar nuestros logros

Muchas veces nos sentimos un fraude, caemos en lo que los psicólogos llaman el síndrome del fraude o síndrome del impostor. Esto nos ocurre a los programadores cuando no somos capaces de reconocer nuestros logros y tememos ser un fraude. Es un tema muy manido que probablemente ya conocemos todos y que sucede en todas las profesiones.

Para evitar caer en este estado de ansiedad es buena idea intentar realzar nuestros logros. Al igual que en punto anterior, usando un blog técnico, podemos claramente ver nuestro progreso si echamos la vista atrás. El crecimiento de un programador novel en un año es tan grande que la mayoría no se da cuenta de cuánto han mejorado hasta que se comparan con su yo del pasado.

Otra forma de destacar los logros es hablar sobre ellos de vez en cuando en reuniones de trabajo. Es lo que se llama hacer retrospectiva cada X tiempo para analizar los aciertos de un proyecto de software, y no solo los errores, ni la pila de cosas que quedan por hacer. Lo lógico es que el 80% de las reuniones sean sobre errores y cosas que queden por hacer. Lo que no es bueno es que el 100% sean así. Tenemos también que abrir espacio para celebrar lo que hemos hecho bien y darnos refuerzo positivo para repetir esas conductas en el futuro y estar auto-motivados por ello.

Cuando somos un programador que está empezando no nos sentimos tan cómodos usando lenguaje técnico como nuestros compañeros. Para mejorar en estos contextos es bueno buscarse situaciones en las que podemos hablar sobre código sin que haya cosas importantes en juego.

Por ejemplo, hablar sobre código a la hora de comer con compañeros, asistiendo a meet-ups, viendo videos en YouTube o escuchando podcasts. Lo normal es que no entiendas todo, pero con el paso del tiempo, irás adquiriendo conceptos y podrás entender más cosas, hacer mejores preguntas para terminar haciendo mejores aportaciones en las reuniones en las que sí hay cosas importantes sobre la mesa.

En muchas empresas tienen la costumbre de traer invitados a reuniones que no son de su competencia. Puede que nos sintamos abrumados y que pensemos que es una pérdida de tiempo, pero en verdad se aprende muchísimo y nos da mucha perspectiva de las cosas del trabajo y de los motivos de las decisiones que nos afectan en el día a día. Si en tu empresa no lo hacen, no temas en pedir que te inviten a una de vez en cuando, a tu superior no le va a parecer mal que muestres entusiasmo e interés por la empresa.

6. Programar es resolver problemas

Tenemos que saber que esta profesión implica resolver problemas. No hay otra forma de concebirla. Es muy habitual que programando nos encontremos siempre en dos fases: avance-muro. Todo va bien, avanzamos, y de repente nos encontramos un muro infranqueable y estamos ahí parados. Sorteas el muro tras solucionar el problema, avanzas otro poco, y de la nada, otro muro...

No es descabellado afirmar que en cualquier tarea que implique escribir código siempre vamos a tener que solucionar algún problema inesperado que nos encontraremos por el camino. La programación es así, es pegarse de frente contra muros.

La mayoría de las barreras las podemos pasar preguntando a algún compañero o usando Internet o trasteando algo con el código. En no pocas ocasiones no somos capaces de saber cómo avanzar. Los mensajes de error muchas veces son indescifrables o simplemente no hay mensaje de error, y las búsquedas en Internet nos llevan a callejones sin salida.

En estos casos un posible enfoque es entrar en profundidad a evaluar el problema. Aquí tenemos que parar en seco y empezar a reflexionar más profundamente. Para empezar, debemos cuestionar nuestras presunciones con preguntas del tipo:

  • ¿Qué cosa no funciona?
  • ¿Por qué he pensado que iba a funcionar?
  • ¿Qué cosas he dado por supuesto que iban a funcionar pero no he verificado?

Es en estos momentos en los que tener una buena base de conocimiento de nuestro trabajo marca la diferencia frente a aquellos que han aprendido solo "recetas" o son "programadores de Stack-Overflow" (de copia-pega: ¡hay muchos!). Este tipo de preguntas nos obligan a meternos de lleno en el problema en cuestión, centrarnos en él, en vez de saltar de una posible solución a otra. Nos obligan a pensar mucho en el código que tenemos entre manos y revisar todo de arriba abajo.

Otra posible ayuda a la hora de solucionar problemas es leer la documentación a fondo. No es la forma más popular de resolver un problema, pero nos aporta más contexto y, a fin de cuentas, es otra forma de aprender más. Es el camino más largo, pero en la etapa de programador junior nunca se puede considerar una pérdida de tiempo leer documentación.

Es bueno tomarse un tiempo para aprender más sobre el lenguaje de programación o el framework. Por otro lado, al leer la documentación podemos discriminar mucha información que hemos memorizado ya que sabemos dónde encontrarla y la tenemos perfectamente localizada.

Llegados a este punto, y con el nuevo conocimiento adquirido, podemos volver a crear el código de forma distinta e ir viendo cómo se comporta la aplicación paso a paso. Aunque no logremos que funcione, si conseguimos que nos devuelva un mensaje de error descifrable, ya hemos dado muchos pasos hacia adelante.

Otro posible enfoque es buscar la solución en Internet. Ir a Google y ponerse a investigar cada uno de los hilos y los blogs que hacen alguna mención al problema que tenemos.

A veces esta forma de enfocar el problema nos funciona bien, pero otras nos pasamos media mañana investigando para no avanzar nada. Probar diferentes estrategias una tras otra esperando a que alguna nos funcione nos puede dar varios dolores de cabeza y no es una forma de aprender en profundidad el framework o el lenguaje de programación. Es como jugar a los dados hasta que salga la combinación de números que queremos. Algo siempre se aprende, pero no nos da todo el contexto del problema, y tras todo el tiempo invertido investigando y haciendo ensayo y error, quizás sea mejor invertir un poco más y aprender más a fondo.

7. Diferenciar entre buenas prácticas y estilos de programación

Como desarrolladores junior nos falta experiencia para saber si nuestros mentores nos están enseñando buenas prácticas o si nos están imprimiendo su estilo de programación. Si sospechamos que lo que nos están enseñando es más bien su forma de hacer las cosas que buenas prácticas, quizás resulte un poco violento plantearlo, especialmente si tu mentor es un desarrollador senior de la empresa en la que trabajas. Puede resultar muy complicado salir de estas dudas sin caer en la confrontación.

Muchas veces estamos en pleno proceso de aprendizaje y nos enseñan cómo se hacen las cosas en la empresa. Pueden ser buenas prácticas o no... De todos modos lo mejor es que en líneas generales confiemos en que saben lo que están haciendo. Habiendo dicho esto, como novatos muchas veces nos corresponde dar por hecho que nuestros compañeros más veteranos son algo obstinados, siempre pensarán en primer lugar que la persona que está equivocada eres tú, y que prefieren ceñirse a su forma de hacer las cosas antes que cambiar. Algunos incluso se desenvuelven con aires de superioridad.

Sea cual sea la situación, siempre tendremos que asumir el hecho de que los mandos técnicos de la empresa tienen su forma de hacer las cosas, y tenemos que vivir con ello.

Si detectamos que algo se puede hacer mejor (de verdad, con razón), lo mejor es sacar el tema sin entrar en una confrontación directa. Siempre podemos preguntar con educación por qué se hace algo de una manera determinada, para luego añadir, si vemos algún tipo de apertura por la otra parte, la forma en la que creemos que se podría hacer, justificando bien el porqué. Siempre nos vamos a encontrar con personas que nunca van a transigir y que se consideran infalibles, pero salvo contadas excepciones, incluso los programadores senior quieren aprender nuevas formas de hacer si se basan en argumentaciones sólidas.

Conclusión

En general, sentimos frustración cuando nos quedamos atascados en algo. Esa frustración se puede mitigar si encontramos un apaño para seguir, pero también si aprovechamos las adversidades para aprender, que también nos proporciona una sensación de progresar.

Por si no te habías dado cuenta, este es el blog de campusMVP, la mejor forma de aprender a programar.

Nuestra metodología hace que te encuentres adversidades muy concretas por el camino. Si haces alguno de nuestros cursos de programación, a partir de lo explicado y de las prácticas especialmente diseñadas, te surgirán dudas que tendrás que preguntar, te tendrás que pegar con ellas. Y esto es otra forma más de aprendizaje, pues nos obligará a reflexionar y concretar los detalles de la tecnología.

Con campusMVP, para que no nos quedemos atascados existe la figura del tutor, que normalmente es la persona que ha diseñado el curso. El tutor contestará las dudas al mismo tiempo que seguimos practicando y/o estudiando en paralelo. Obtener respuestas rápidas y precisas por parte de los tutores que asisten tu formación es muy importante. No sirve que te contesten cuatro días más tarde.

¡Anímate con uno de nuestros cursos y cuéntanos que tal te ha ido!

Aprender Online a través de tutores por Skype

03/10/2017
Artículo original

Espero y este post sea de tu agrado, no olvides compartirlo en su redes sociales y sobre todo.. Gracias por seguirnos!

¿Quieres una opción educativa para entretener a tus hijos? La opción de cursos presenciales representan algunos problemas de tiempo y dinero para los padres por lo que actualmente la opción de tutores por skype para aprender online y entretener a los pequeños esta tomando fuerza. ¿Quieres saber más sobre el aprendizaje online? Recientemente habiamos hablado sobre el papel de los padres en la educación de sus hijos y es que es tan importante ofrecer opciones de calidad que no solo entretengan o mantegan quietos a los niños sino que aporten algo de valor y aprendizaje para el desarrollo de los

Compartir en Facebook

Comparte en Google Plus

Compartir en Twitter

El post Aprender Online a través de tutores por Skype aparece en el Blog de Jonathan Melgoza

Cómo enviar correo electrónico con Java a través de GMail

02/10/2017
Artículo original

Imagen ornamental

Muchas aplicaciones que vas a desarrollar necesitarán enviar algún correo electrónico que otro de vez en cuando. Si necesitas hacer muchos envíos es mejor recurrir a servicios especializados, como por ejemplo Sendgrid o Mailgun, pero si lo único que quieres es poder enviar un correo muy de vez en cuando (por ejemplo, para un formulario de contacto en tu web o cuando se produzca un error), entonces puedes recurrir a soluciones más "rupestres" como la que te vamos a contar.

Precisamente por esta necesidad, una de las preguntas más frecuentes que se ven en foros sobre envío de correo es ¿cómo envío correo desde Java usando mi actual cuenta de GMail?.

La manera más sencilla es usando la API de JavaMail, pensada para enviar correo a través de SMTP a través de cualquier servidor.

Lo que ocurre es que GMail es un poco especial para esto, ya que por defecto no permite la conexión directa mediante usuario y clave a sus servidores de envío.

El motivo es que dispone de una API oficial para conectarse mediante la cuenta de Google y autenticar al usuario antes de enviar. Pero si queremos hacer uso del servidor SMTP para un envío directo, todavía podemos hacerlo.

Permitir aplicaciones "menos seguras"

Este eufemismo es el que utiliza Google para referirse a aplicaciones que, en lugar de usar la API de seguridad de Google y sus tokens, utilizan la vieja pareja "usuario-clave" para acceder al servicio.

Es un ajuste que está en la zona de seguridad de tu cuenta de Google, en la parte de abajo del todo de la sección de autenticación, pero existe también un acceso directo a este ajuste en exclusiva:

Interfaz de selección para permitir aplicaciones menos seguras

Si no lo marcas, cuando intentes enviar correo a través del servidor SMTP de GMail obtendrás el error:

"The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.5.1 Authentication Required"

Pero una vez cambiado este ajuste ya podrás utilizar sin problema la funcionalidad que te explicamos a continuación.

Nota: marcando esta funcionalidad se supone que tu cuenta está menos segura ya que ciertas aplicaciones no pasarían por la API de Google y sus tokens de autenticación. Y es cierto. Pero por otro lado si pierdes la clave de tu cuenta tendrás un problema de todos modos. Simplemente, si activas esta opción asegúrate de que guardas las credenciales a buen recaudo, y desde luego no las pongas en tu código y las distribuyas con tu aplicación, pues entonces seguro que las pierdes.

Enviar email a través de servidores SMTP con Java

Como decíamos antes, lo primero que tienes que asegurarte de que tienes la API de JavaMail disponible. Si tienes J2EE instalado, entonces no tienes que hacer nada pues ya dispones de dichas clases. En caso de no usar J2EE puedes descargarte los .jar y añadirlos como dependencias a tu proyecto si utilizas un IDE como NetBeans, o bien asegurarte de que los tienes en el classpath en caso de no utilizar IDE alguno.

Una vez hecho podemos definir una función como esta:

private static void enviarConGMail(String destinatario, String asunto, String cuerpo) {
    // Esto es lo que va delante de @gmail.com en tu cuenta de correo. Es el remitente también.
    private String remitente = "nomcuenta";  //Para la dirección nomcuenta@gmail.com

    Properties props = System.getProperties();
    props.put("mail.smtp.host", "smtp.gmail.com");  //El servidor SMTP de Google
    props.put("mail.smtp.user", remitente);
    props.put("mail.smtp.clave", "miClaveDeGMail");    //La clave de la cuenta
    props.put("mail.smtp.auth", "true");    //Usar autenticación mediante usuario y clave
    props.put("mail.smtp.starttls.enable", "true"); //Para conectar de manera segura al servidor SMTP
    props.put("mail.smtp.port", "587"); //El puerto SMTP seguro de Google

    Session session = Session.getDefaultInstance(props);
    MimeMessage message = new MimeMessage(session);

    try {
        message.setFrom(new InternetAddress(remitente));
        message.addRecipient(Message.RecipientType.TO, destinatario);   //Se podrían añadir varios de la misma manera
        message.setSubject(asunto);
        message.setText(cuerpo);
        Transport transport = session.getTransport("smtp");
        transport.connect("smtp.gmail.com", remitente, clave);
        transport.sendMessage(message, message.getAllRecipients());
        transport.close();
    }
    catch (MessagingException me) {
        me.printStackTrace();   //Si se produce un error
    }
}

Que se encargará de hacer los envíos. Luego podemos llamarla desde cualquier lugar de la siguiente manera:

public static void main(String[] args) {
    String destinatario =  "alguien@servidor.com"; //A quien le quieres escribir.
    String asunto = "Correo de prueba enviado desde Java";
    String cuerpo = "Esta es una prueba de correo...";

    enviarConGMail(destinatario, asunto, cuerpo);
}

Lo que hará que se envíe un mensaje a la dirección especificada con el asunto y el cuerpo que hayamos indicado.

Importante: nunca deberías incluir el nombre de usuario y la clave de la cuenta que usas para enviar, directamente en el código, puesto que el Bytecode es muy fácil de desofuscar y cualquiera podría verlos. En el caso de una aplicación web es mejor que los guardes externamente, en un archivo de configuración en el servidor, lejos del alcance de los visitantes. En una aplicación de escritorio lo mejor sería que solicitases esos datos a cada usuario y los guardases de manera local, pero nunca en el código.

¿Cómo ignorar la caché del navegador (cache busting)?

01/10/2017
Artículo original

¿Cómo ignorar la caché del navegador (cache busting)?

¿Cómo ignorar la caché del navegador (cache busting)? - Escuela Digital
Álvaro Felipe Mar, 11/15/2016 - 19:35

Una de las estrategias más útiles para mejorar el rendimiento de un sitio web es tener un sistema de caché habilitado. De esta forma le decimos al navegador que almacene en sus archivos temporales los assets del sitio por un tiempo determinado (una semana, un mes, varios meses, etc.). Entonces, cuando volvemos a visitar el sitio, el navegador no descarga los assets de internet (archivos js, css, imagenes, etc) sino que toma los que tiene en su caché acelerando la renderización de la página.

Hasta ahí perfecto. Hay muchas formas de habilitar la caché en nuestro desarrollo o directamente desde el servidor pero no es tema de este post. Lo que vamos a ver es como forzar al navegador a ignorar su caché. Seguro te preguntarás: “¿para qué, si la caché mejora el rendimiento?” Pues porque si realizas actualizaciones tus usuarios seguirán viendo la versión antigua por culpa de la caché (es entonces cuando deja de ser cool). Y aunque pedirle que limpien la caché de su navegador es una opción, no es la mejor. Incluso puede que muchos ni tengan idea de como limpiar la caché (a menudo un CTRL F5 o SHIFT F5 debería bastar).

Así que vamos al punto, ¿cómo le digo al navegador que ignore la caché y cargue la nueva versión? Existen varias formas para hacer cachebusting (romper la caché) pero veamos la más fácil de todas que consiste en añadirle un parámetro (query string) a la URL de los assets. Por ejemplo, si antes cargabas tu css así:


Ahora la cargarás así:


Entonces cuando hagas un cambio simplemente cambias el parámetro. Por ejemplo, para la siguiente actualización:


Así, cuando el navegador cargue la página, como el parámetro es diferente, asumirá que se trata de otro archivo que no tiene en su caché y lo descargará. Fantástico.

El parámetro comienza con un signo ? y un string aleatorio. En nuestro caso hemos usado ?abcde como ejemplo pero no es muy buena idea. Mucho mejor ?v1.0.1 y ?v.1.0.2.

Y es todo, solo no te olvides de actualizar el parámetro para cada actualización antes de llevar a producción. Aunque siempre puedes automatizar este proceso, pero ya es cosa de otro post.

¿Conoces otro tip para cachebusting? Cuéntalo en los comentarios.

¿Por qué no usar Google Drive?

01/10/2017
Artículo original

¿Por qué no usar Google Drive?

Escuela Digital por que no usar google drive
Álvaro Felipe Lun, 11/14/2016 - 21:36

Google Drive nació como una respuesta a Dropbox. Asumámoslo, es completamente normal que cuando una empresa lanza un producto que tiene éxito, su competencia lance sus propias versiones para no quedarse relegados. El factor "supuestamente" decisivo para inclinarse a Google Drive en lugar de Dropbox era precio y cantidad de almacenamiento. Dropbox rápidamente niveló la valla, con lo cual la única ventaja "en teoría" de Google Drive era el espacio gratuito (15GB que incluyen el espacio ocupado por Gmail, Google fotos y demás servicios) y su integración con las aplicaciones de Google (documentos, presentaciones, hojas de cálculo).

En Escuela Digital usamos GSuite (antes Google Apps) para correo electrónico y documentos (MS Office sigue siendo más poderoso pero no necesitamos las funciones avanzadas con lo que GSuite nos basta) pero no nos habíamos animado a usarlo para sincronizar archivos de escritorio (al estilo Dropbox) hasta ahora. Y la decepción ha sido enorme.

Y es que entre pagar 10 dólares extra por usuario (para Dropbox) o aprovechar el almacenamiento de Google Drive incluido en la suscripción, obviamente era más rentable irnos por Google Drive (lo hemos usado para guardar los diseños de publicidad de los cursos hechos en Photoshop). Y entonces comenzó al calvario: errores de sincronización, de permisos, archivos eliminados, cambios no guardados. Un infierno. 

Si se intentaba guardar un archivo mientras se estaba sincronizando, daba un error de permisos e impedía guardarlo (es normal guardar con mucha frecuencia cuando se diseña). Uno esperaría que al terminar de sincronizar se liberarían los permisos y ya se podría guardar nuevamente. Pero era imposible, el archivo estaba bloqueado, no se podía renombrar, guardar ni eliminar. Pero no era lo peor, sino que el archivo en realidad no estaba sincronizado (llevaba la equis roja) y cuando forzaba la sincronización (desde la aplicación de Google Drive) el archivo se eliminaba (EN SERIO). Había que ir a Google Drive desde el navegador, luego a la papelera y restaurar el archivo. El cual, oh sorpresa, no incluía los últimos cambios. Es decir, habias perdido tu trabajo.

Dropbox tampoco es que sea la aplicación perfecta. Cada vez que se inicia indexa todo (tengo casi 500GB y es un *PITA* esperar a que indexe todo aunque no haya nada nuevo que sincronizar) pero prefiero eso a perder horas de trabajo como con Google Drive. 

En lo particular, creo que podemos seguir usando Google Drive para los propios documentos de Google o para guardar archivos que no se editarán (como archivo). Pero jamás para "documentos vivos" (que serán editados continuamente, como diseños p.ej.). De hecho, con Google Drive tenía que apagar la sincronización, trabajar y luego activar de nuevo la sincronización. Pero es un paso extra, muy torpe, y fácil de olvidar. Así que en más de una ocasión perdí mi trabajo por olvidarme el estúpido paso adicional.

Me cuentan en los comentarios si han tenido una experiencia similar (o peor) con Google Drive, o Dropbox o OneDrive (que no lo pruebo hace mucho pero cuando lo hice me parecía el peor de los tres). 

15 recursos / canales / podcasts sobre matemáticas

01/10/2017
Artículo original

¿Qué es esta lista?

A continuación se listan una serie de Podcast, Canales de Youtube y Blogs que sigo que hablan sobre matemáticas.

Si conoces de algún recurso digital que hable y enseñe matemáticas no listado abajo, contribuye dejándonos un comentario y lo añadiremos a la lista, o mejor aún, añádelo tú mismo haciendo un Pull Request!

Gracias a @sinclair_88 por proponer la idea de crear la lista.

Otras listas

Podcasts

My Favorite Theorem

My Favorite Theorem Logo

Join us as we spend each episode talking with a mathematical professional about their favorite result. And since the best things in life come in pairs, find out what our guest thinks pairs best with their theorem.

Math Mutation

Welcome to Math Mutation, a short podcast for people of all ages, where we explore fun, interesting, or just plain weird corners of mathematics that you probably didn't hear in school.

Ben Ben Blue

A podcast by Grant Sanderson, Ben Eater and Ben Stenhaug about education, technology, and whatever else comes to mind.

Rel Prime

Relatively Prime is a mathematics podcast all about the stories behind the Queen of the Sciences that Samuel Hansen dreamt up in an extreme bout of egotism and delusions of grandeur where he spent too long listening to Radiolab, This American Life, and Snap Judgment and began to think, “Hey, I could do that.”

Youtube

3Blue1Brow

3Blue1Brow-postn is some combination of math and entertainment, depending on your disposition. The goal is for explanations to be driven by animations and for difficult problems to be made simple with changes in perspective.

3Blue1Brow, también tiene un podcast: benbenandblue.com.

MathoLoger

Enter the world of the Mathologer in which beautiful math(s) rules.

MinutePhysics

Simply put: cool physics and other sweet science.

MinutoDeFísica

En pocas palabras: física genial y ciencia interesante

NumberPhile

Videos about numbers - it's that simple.

NumberPhile2

This is Numberphile's "second channel" for extra footage or stuff that didn't quite fit on the main channel

PBS Infinite Series

Mathematician Kelsey Houston-Edwards offers ambitious content for viewers that are eager to attain a greater understanding of the world around them. Math is pervasive - a robust yet precise language - and with each episode you’ll begin to see the math that underpins everything in this puzzling, yet fascinating, universe.

StandUpMaths

I do mathematics and stand-up. Sometimes simultaneously. Occasionally while being filmed. (It's quite the Venn diagram.)

Blogs

Quanta Magazine is an editorially independent online publication launched by the Simons Foundation to enhance public understanding of science. Why Quanta? Albert Einstein called photons “quanta of light.” Our goal is to “illuminate science.”

Referencias

Display 7 Segmentos Y PIC – Tutorial Electronica

30/09/2017
Artículo original

Espero y este post sea de tu agrado, no olvides compartirlo en su redes sociales y sobre todo.. Gracias por seguirnos!

¿Quieres aprender a montar un display 7 segmentos en un pic? En este Articulo veremos como conectar un display de 7 segmentos de anodo comun a un PIC16F877A y mostrar un contador de 0 a 9. Tambien conectaremos un led para indicar el estado del circuito. Comenzemos… Requerimientos -Programador de Pics (Uso uno master prog) -PIC16F877A -Display de 7 segmentos de anodo comun -Cristal de Cuarzo de 4 MHZ -2 Capacitores Ceramicos de 22pF -3 Resistencias de 220Ω -1 Resistencia de 10KΩ -1 led color Verde -Alimentacion 5V (Baterias,conexion usb,fuente de poder,etc) -Protoboard -Cable para Protoboard Recomendado Manual PIC16F877A Conceptos

Compartir en Facebook

Comparte en Google Plus

Compartir en Twitter

El post Display 7 Segmentos Y PIC – Tutorial Electronica aparece en el Blog de Jonathan Melgoza

¡Usa Emojis y GIFs en tu estrategia de contenidos!

30/09/2017
Artículo original

De la misma forma que es bien conocido que la expresión corporal tiene un gran impacto en la comunicación, los Emojis y GIFs son una buena manera de "humanizar" la comunicación digital y conseguir una relación más cercana con tus lectores o clientes. ¡Úsalos con sentido común!

The post ¡Usa Emojis y GIFs en tu estrategia de contenidos! appeared first on Nelio Software.

TruquiTrucos Dev – Controlar el tamaño de las imágenes de tu biblioteca de medios

30/09/2017
Artículo original

Aunque seas plenamente consciente de la importancia que tiene limitar el tamaño de las imágenes que usas en tu web, es fácil despistarse y subir una imagen de varios megas. ¿La solución? Que WordPress no te lo permita.

The post TruquiTrucos Dev – Controlar el tamaño de las imágenes de tu biblioteca de medios appeared first on Nelio Software.

Descubre por qué vanilla JavaScript es el futuro

30/09/2017
Artículo original

La lista de cosas que podemos hacer hoy en día con JavaScript pelado es muy grande. Por desgracia, muchos desarrolladores lo desconocen y siguen confiando en librerías como jQuery o Underscore.js. ¡Es hora de renovarse!

The post Descubre por qué vanilla JavaScript es el futuro appeared first on Nelio Software.

Página Anterior Página Siguiente