Bower

Bower es un instalador de paquetes mantenido por Twitter al estilo npm bastante similar pero que gestiona packages más amplios.

Introducción

No hay mucho que hablar sobre Bower, básicamente Bower lo que hace es en lugar de instalar dependencias agrupar paquetes, que a su vez pueden contener una serie de archivos.  Mientras que NPM está más enfocado a suministrar packages para Node, Bower también tiene package de herramientas más orientadas al Front-end u otros como puede ser Bootstrap, Angular u otros.

El poder de Bower es justamente ese, que instala de un plumazo un paquete de dependencias más complejas, de por si tiene bastante juego pero es junto a otras herramientas como Grunt/Gulp y Yeoman cuando brilla.

Comandos

La verdad es que otra de las opciones más interesantes de Bower son sus comandos.  Además de los típicos de inicializar, instalar y buscar (similares a npm) tiene una opción de listar los packages instalados, pero es que además nos mostrará la versión instalada y la versión más actual disponible.  Pero es que además podemos desinstalar packages o actualizar los existentes.

Archivos

Basicamente hay 2 archivos importantes en el caso de Bower, uno de ellos es bower.json que es muy similar a package.json y en él se especifican los packages a instalar y por otro .bowerrc que también es otro json sin embargo, su principal utilidad es especificar el directorio donde se van a instalar los packages.

Considero que no hace falta analizar más en detalle a Bower, sino ver las herramientas que lo aprobechan, más información sobre Bower en su página web oficial: http://bower.io/

Workflow, ¿Qué es y cómo mejorarlo?

Cuando estamos viendo artículos o vídeos, es normal de vez en cuando ver alguna referencia al workflow o cómo mejorarlo, pero no son pocos los que no lo llegan a comprender y muchos quien no lo mejoran considerablemente.

¿Qué es el workflow?

Como su nombre indica, workflow es el flujo de trabajo o dicho de otra forma los pasos que seguimos y herramientas que utilizamos desde que empezamos a realizar nuestro trabajo hasta que tenemos el resultado, aquí se incluyen tanto técnicas como herramientas.

En lo que se refiere a técnicas podríamos encontrar tanto enfoques de diseño como Mobile first o Progressive enhancement como de productividad como la técnica del pomodoro o kanban.

En herramientas, podemos encontrar programas que o bien nos permiten generar un plus de calidad, ahorrarnos tiempo o darnos algunos extras a la hora de compartir información.

¿Por qué no se suele mejorar?

Sobre el papel es muy bonito, en el mismo tiempo cambiando algunas cosas podemos hacer un trabajo de mejor calidad en menos tiempo, pero... ¿Por qué es tan común ver a personas con un workflow tan poco eficiente?  Esto no es tan solo algo temporal, sino que también se da en el caso de las empresas.  Los motivos pueden ser varios:

- Resistencia al cambio:  Una vez nos sentimos cómodos con una herramienta, una forma de trabajar, o incluso en la vida cotidiana; hay una cierta tendencia a que haya una resistencia al cambio.  La expresión más habitual puede ser "Para qué voy a aprender a algo nuevo si como lo hago ahora me va bien", pero por lo general el tiempo invertido en esos cambios puede llegar a ser ridículo en comparación a los beneficios.

En el caso de las empresas, tiene un poco más de sentido según la embergadura de los cambios, pero hay pequeños cambios en el workflow que no afectan a otros y sin embargo dan lugar a mejores resultados.

- Coste de la investigación/aprendizaje: Para utilizar algo primero hace falta conocerlo, si no conocemos la existencia de los preprocesadores CSS y de lo fácil que es implementar y potentes que son no vamos a usarlos.  Y claro, estar al tanto de estas herramientas, ver si funcionan y aprender a usarlo.

Eso conlleva tiempo y el tiempo es valioso, con lo que la primera opción de no pocos es dejarlo de lado.  Pero es justamente porque el tiempo es valioso, que hay que invertirlo en eso, si estar al tanto nos cuesta 2 horas semanales y sólo por el hecho de implementar algo como Gulp nos podemos ahorrar 3, ya estamos sacando 1 hora semanal de beneficio.

A mi modo de verlo, no cuesta tanto mejorar el workflow, porque ya hay artículos o tutoriales que explican varias herramientas y el ahorro de tiempo puede ser muy grande.

¿Y entonces?

Hay varias formas de mejorar el workflow dependiendo del entorno en el que estemos.  Hay herramientas como Bower o Yeoman que nos permiten comenzar un proyecto con una base, preprocesadores CSS que nos dan mucha potencia en nuestro código y estructurarlo, herramientas de linteo que nos permiten ver dónde hay posibles herrores incluso antes de ejecutar nuestra aplicación, otras tantas herramientas e incluso herramientas de gestión de tareas como Gulp o Grunt que nos permiten que todas las anteriores tareas se ejecuten de forma automática tras guardar los cambios en alguno de nuestros archivos de código.

Esa es la gran ventaja de un workflow eficiente, invertir un tiempo previo nos permite instar un esqueleto base de nuestra app ahorrándonos instalar una serie de herramientas o módulos y luego configurar las tareas necesarias en Grunt o Gulp nos permite que con la misma acción de guardar el archivo pasar por una serie de validadores o test unitaros y generar el resultado final. Considero que es estúpido e improductivo el no dedicar un cierto tiempo a mejorar nuestra forma de trabajar, siempre y lo que queremos es conseguir un resultado mejor con menos tiempo.

Dedicando mis esfuerzos a Node y Express

He decidido realizar una serie de artículos sobre conceptos de Node.js enfocados a Express y sobre Express en si; eso sí, intentando entrar un poco más en detalle en algunos aspectos o intentar dar una versión más clara.

PHP vs Node

Originalmente, mi idea era tener unos conocimientos aceptables de Express para poder usarlo como back de cara a otros proyectos, a la vez que repasaba y ampliaba mis conocimientos de JavaScript para posteriormente pasarme a PHP con Laravel 5.

En España en general y en Málaga en particular, PHP está mucho más difundido que Node con lo cual, de cara a ofertas de trabajo la apuesta era clara por PHP.  Sin embargo, al estar trabajando con Express me apetece más profundizar en ese tema a la vez que voy tocando otros aspectos cercanos.

La experiencia me ha enseñado que la mejor forma de aprender, es estudiar algo que nos apetece y en ese sentido, por ahora voy a seguir por la parte JavaScript.

La importancia creciente de JavaScript

Igualmente, no es una mala opción.  JavaScript cada vez es más importante, y si bien voy a dedicar tiempo a mis aptitudes como back-end, mi objetivo sigue siendo el front-end; pero gracias a JavaScript y a frameworks como Angular, Backbone o Ember la diferencia entre front y back no es tan distante y si se usa el mismo lenguaje, menos aún.

Es ese uno de los motivos por el que ha surgido el stack MEAN (MongoDB, Express, Angular y Node). Node se está haciendo hueco en el mercado y es en si y sus herramientas una tecnología de futuro y de presente.  Así que invertir tiempo en ella es una buena inversión, se mire por donde se mire, tener soltura en JavaScript lo veo como algo obligatorio si queremos estar al día en nuevas tecnologías del desarrollo web.

Reflexionando un poco, que algunas compañías sigan ancladas en hacer páginas web con plantillas de Wordpress (o con peores métodos) a fin de potenciar la cantidad a bajo coste, a costa de la calidad, no quiere decir que tengamos que aprender formas de hacer páginas web de hace unos años, sino que tenemos que seguir buscando por compañías que buscan estar al día en las últimas tecnologías para poder ofrecer productos de calidad.

La importancia del código limpio y estructurado

Es posible que en otra ocasión ya haya hablado un poco por encima, pero me parece algo tan importante como para dedicar una entrada exclusiva a soltarlo y quedarme agusto.

¿Tan difícil es hacer un código limpio y estructurado?

¿A qué viene todo esto?  Recientemente siguiendo un curso de CodigoFacilito de desarrollo de una aplicación web la gran mayoría del código está en app.js.  Salvo cosas que realmente no pueden estar como las vistas y poco más.

Cierto es, que la aplicación no es nada del otro mundo y no llega a 200 líneas de código, sin embargo, para ser un tutorial, creo que con más motivo se debería estructurar y comentar inline, por no mencionar que la mejor forma de empezar es con buenas prácticas.

Todo esto vino en su día, a que hubo problemas con el módulo de cloudinary y al empezar a depurar donde estaba (lo que sirve en un vídeo puede no servir varias semanas después siendo el mismo código) me desanimé mucho al no saber bien por donde meterle mano y teniendo otras cosas que hacer pues... lo dejé de lado.

¿Por qué es tan difícil hacerlo?  Mi opinión, es que los seres humanos somos por naturaleza vagos, perezosos y excesivamente optimistas.

Cuando nos topamos con un proyecto, especialmente si no es muy grande, en el momento en que estamos trabajando en él sabemos el motivo del código y creemos que añadir comentarios o crear una estructura más legible es innecesario, a eso se le une esa cierta pereza, una mala creencia de que podemos pensar que escribir comentarios es perder el tiempo, un tiempo que podríamos estar utilizando en que la aplicación progrese y como no, tendemos a pensar que todo va a ir bien, que la aplicación va a funcionar de primeras y no vamos a tener que depurarla.  Realmente no es que creamos que va a funcionar de primeras, sino que esperamos a que así sea para no afrontar la realidad, o que no falle y luego el proyecto pase a otras manos y sea otra persona la que se coma el marrón.  Tristemente es así, hay personas que esperan que funcione y luego el que venga detrás se come el marrón, eso sí, una gran cantidad de ocasiones el que viene detrás es nuestro yo del futuro y nos va a odiar por ello.

Estructurar código

Os voy a poner un ejemplo, tenemos por un lado el código original de CodigoFacilito en su GitHub https://github.com/codigofacilito/primera_pagina_node y luego mi versión https://github.com/ShinFDuran/codigofacilito-Node.  Realmente, salvo algunos retoques la funcionalidad es la misma.

Sin embargo además de los archivos normales de la versión del tutorial, en mi versión hay otras carpetas:
- controllers: Contienen la gestión de las vistas
- docs: Documentos de los diferentes commits realizados
- models: Modelos de la base de datos
- routes: Gestión de las rutas de la aplicación

En lugar de tenerlo todo en un archivo, hemos separado las capas de vistas, enrutamiento, control y modelamiento de la base de datos.  Es decir, en lugar de tener un archivo con 200 líneas de código, tenemos una serie de archivos con una función muy específica y delimitada.  A partir de ahí podemos ir testeando y probar los diferentes módulos, lo que inicialmente nos permite una mayor facilidad para localizar el error, pero en el futuro nos permitirá que si queremos cambiar un desterminado aspecto, cambiar únicamente esos archivos, dejando intactos el resto.

Estructurar el código, nos permite además de tener un código más legible una modularidad y poder reutilizar bloques mucho más fácilmente.

Comentarios

Quizás algo que sí es criticable en los proyectos que estoy realizando es la excesiva cantidad de comentarios.  Muchos comentarios inline y muchos archivos con información de los commits.  ¿Es necesario tanto comentario?  Pues la verdad es que no.

A mi modo de verlo, esta gran cantidad de comentarios tiene el fin de facilitar mi autoaprendizaje, el colocar esos comentarios como notas o recordatorios me permite que cuando estoy viendo el código refresco esos conocimientos, que a veces con echar un vistazo a los documentos de los commits entre en contexto y recuerde lo que hice y por qué.

El otro motivo, es facilitar a quienes vean mi código lo que es cada cosa, aun cuando su nivel de conocimiento no sea muy amplio.  Una vez tenga soltura y a fin de reducir tiempos o excesivos comentarios, veo importante establecer algunos delimitadores entre secciones, pero la idea es comentar lo que necesite ser comentado.

Por ejemplo, una función que se use a modo de helper, indicar cuál es su objetivo, parámetros o que devuelve, siempre y cuando no sea algo muy evidente.   En su momento leí/vi, que un buen código es aquel que no necesita ser comentado, con esto se refería, a que es importante que sea un código claro en cuanto a que las variables deben expresar lo que contienen y las funciones la acción que realizan, una buena elección de nombres puede reducir enormemente la necesidad de comentarios.

Código limpio

Una de las cosas que más me mosquean de JavaScript es que es un código terriblemente feo, en tanto que es muy fácil liarlo de una forma que no se entienda nada, entre parámetros, funciones, callback y otras cosas, se crea un infierno de callbacks y anidamientos que es horrible.

En el futuro, uno de los puntos que tendré que profundizar es en el concepto de las promises para mitigar el "Callback Hell" y preprocesadores como TypeScript o CoffeeScript para mitigar un poco la falta de visibilidad del código.

La clave, es que hay que intentar crear un código limpio, que sea fácil de leer y se vea claramente los ámbitos a fin de disminuir la posibilidad de errores.
Coste/beneficio
Esta es una parte muy importante, porque se entiende a malinterpretar.  Seamos realistas, el crear un código estructurado, limpio y comentado requiere más tiempo, pero no es ya tanto el tiempo físico en si, sino el tiempo necesario para tomarlo como un hábito.

La inversión inicial de tiempo en algunos casos puede ser considerable y a eso hay que sumarle el tiempo dedicado a escribir los comentarios.  Pero a mi modo de ver, ese tiempo es ridículo en comparación al tiempo que nos podemos ahorrar en el futuro ya sea más o menos inmediato.

El tener un código modular, reutilizable, claro y fácil de testear supone un enorme ahorro de tiempo (y por lo tanto dinero) no ya sólo a medio o largo plazo, sino también a corto plazo.   Especialmente en el caso de las empresas, toda empresa que tenga un proyecto a medio-largo plazo debería fomentar esto, porque ayuda a reducir costes posteriores a la vez que lo hace menos dependiente de los trabajadores.  Los programadores van y vienen, pero los programas de la empresa siguen ahí y tendrán que irse adaptando según las necesidades y por diferentes formas.

La inversión inicial de tiempo quedará rentabilizada con creces en la mayoría de las ocasiones; el mayor problema a mi modo de verlo es concienciar a los programadores que debemos tener una visión más a medio-largo plazo y unos hábitos más productivos.  No solo para nuestro yo futuro, sino para otros trabajadores de la empresa.

Conclusión final

Más allá de todo lo dicho, de los beneficios y ahorros que conlleva adoptar unos hábitos y técnicas, hay algo un poco más rebuscado.

Digamos que es el factor psicológico o anímico, cuando hay un problema que tenemos que solucionar, ya sea un fallo o algunos cambios si vemos un código largo, confuso o mal estructurado, podemos perfectamente entrar en un estado en el que nos desanimemos ante la mala perspectiva que tenemos.

Horas perdidas sólo en ver qué se supone que hacen determinadas funciones o módulos, el intentar descifrar lo que contienen unas variables y estar continuamente usando la opción de buscar para localizar las líneas de código donde están las funciones que hay que modificar.  Todo eso produce desánimo y junto a la pérdida de tiempo una bajada en la productividad enorme y una sensación de que avanza poco.

Por contra, un código limpio, en el que de un vistazo podamos saber lo que hace cada cosa, además del ahorro de tiempo en si nos pone en una situación opuesta, en la que nos apetece tocar el código, que hay una sensación positiva de que trabajo va a ser productivo y que va a avanzar rápido.

Ese punto psicológico lo considero muy importante y por eso creo que es necesario crear un código con el que nos guste trabajar, con el que nos sintamos código y que en lugar de maldecir a quien lo creó nos impulse a mejorarlo o aportar nuestro granito de arena.  En definitiva, estar en una situación en la que nos apetezca trabajar porque nos gusta lo que estamos haciendo.

Técnica de estudio: Repetición espaciada

En la informática en general y en el desarrollo web en particular, no basta con saber algo e irlo aplicando hasta conseguir una cierta maestría, es necesario estar continuamente aprendiendo a utilizar nuevos programas, metodologías, workflows,...

Sin embargo, tan importante es el proponernos y dedicar tiempo a aprender, como la forma en la que aprender.

La repetición contínua

 

Digamos que es la repetición más habitual o que más hemos utilizado en nuestra época de estudiante, se trata de coger un concepto y machacarlo una y otra vez hasta que lo sepamos, o creamos saberlo, ya que al cabo de un tiempo nos damos cuenta que no lo sabíamos tanto.

Este es uno de los errores típicos del falso aprendizaje ya que tendremos a creer que cuando en una sesión comprendemos una idea, ya la entendemos y la "sabemos".  El machacar una idea o concepto  hasta que nos sentimos cómos y creemos que lo sabemos es denominado como "overlearning" es una de las llamadas "Ilusiones de la competencia" en la que creemos que aprendemos cuando no es así.

El proceso del cerebro

Para entender mejor las bases de esta técnica voy a explicar un poco el proceso del cerebro.  Para afianzar y mantener una idea, concepto o dato en la memoria a largo plazo necesitamos crear una estructura o camino físico entre las dendritas de las neuronas.  Sí, nuestras ideas, recuerdos y demás no son algo abstracto, sino algo físico basado en la interconexión de neuronas.

Ahora bien, en nuestro caso para que realmente se produzca esa interconexión es necesario por un lado comprender bien la idea o concepto que queremos aprender, esto ayuda y mucho, pero... es que también es necesario dejar a nuestro cerebro que cree esas interconexiones, pero el momento en que estas se crean es cuando dormimos.

El sueño es muy imporante en el aprendizaje, porque es cuando el cerebro empieza a coger todos los sucesos del día, los pone en orden y los almacena generando esas interconexiones; si dedicamos una sesión muy larga de estudio sólo lo "escribe" una vez en el cerebro.

De hecho, en su día una de mis formas de aprender era la siguiente:  Supongamos que quiero aprender a usar Bootstrap, recurro a libros o tutoriales, pero en lugar de hacerlo uno tras otro me miro la estructura del tutorial y la misma sección (layout por ejemplo) y me estudio el de todos antes de pasar al siguiente punto.  Si bien tiene la ventaja de que al ver la misma idea en diferentes fuentes pueden complementarse, al veerlos muy seguidos aunque en ese momento me da la impresión de dominar ese aspecto, al cabo de un tiempo veo que he ido olvidando partes.

La repetición espaciada

 

En el caso anterior, ahora como lo hago, si tengo 3 tutoriales me leo la sección que quiero aprender un día, esa misma sección de otro tutorial no la veo hasta el día seguiente, y la misma sección del tercer tutorial no la veo hasta pasado un día más.  De esta forma, se deja asentar los conocimientos un día y reforzarlos o ampliarlos en los sucesivos días.

En ese concepto se basa la repetición espaciada.  En lugar de muchas sesiones de estudio un mismo día, irlas separando, cada vez más a lo largo del tiempo.  Por ejemplo, insistir en un concepto 3 días seguidos, luego día sí, día no, luego cada 3 días, una vez por semana... Al cabo de un tiempo, esa idea, concepto o dato estará firmemente arraigada a nuestro cerebro.

De hecho, tengo pendiente aprender a usar una aplicación llamada Anki para este propósito tal y como se explica en este artículo:  Tips For Mastering A Programming Language Using Spaced Repetition

Por lo demás, os animo a mejorar vuestro sistema de aprendizaje con esta y otras técnicas de estudio

Proyecto Jade-Bootstrap 1: Introducción

Cuando se aprende, especialmente de forma autodidacta es muy fácil perder el rumbo, especialmente si lo que estamos aprendiendo forma parte de un campo muy amplio.  El ¿Merece la pena empezar esto? Es algo muy recurrente, especialmente cuando todavía no se han cerrado otros proyectos o campos, ya que tenemos un tiempo limitado y mucho que aprender.

La tendendencia a dejar las cosas sin acabar

 

Nuestra mente es muy puñetera y uno de los aspectos más problemáticos es que ante la dificultad tiende a buscar otras tareas más placenteras, es lo que se conoce como procrastinación en alguna de sus variantes.

Cuando estamos aprendiendo algo nuevo, especialmente si nos encontramos con algún punto problemático o no nos gusta mucho, tendemos a querer cambiar y buscar otros tareas o estudios que a priori pueden parecer más placenteras.  Los pretextos son variados, pero por lo general acabamos conociendo poco de mucho, algo que en la práctica no es nada recomendable.

¿A qué viene esto?  Pues que en cierta forma esta sensación es la que me ha surgido con este proyecto, ya que tengo abiertos otros 2 similares, el curso de MiriadaX (al que me faltan 2 prácticas por entregar) y el tutorial de codigofacilito (con el que tengo un problema con la API de subir imágenes).  ¿Merece la pena este cambio aunque sea temporal?  Eso me he estado planteando, y si lo estoy haciendo es porque la respuesta es sí.  Ambos proyectos usan Bootstrap y si bien en el caso de MiriadaX ha sido por voluntad propia, creo que este proyecto me servirá para asentar las bases de Express.js a la vez que crear una base de Bootstrap que puede servirme para acelerar y mejorar el proceso de creación tanto del front en los proyectos mencionados como en otros futuros.

¿En qué consiste Jade-Bootstrap?

 

En la actualidad muchos esfuerzos van dedicados a modularizar el desarrollo y a reutilizar el trabajo realizado, iniciativas como los web components o los frameworks son una buena muestra de ello.

La idea de este proyecto es justamente esa, crear una pequeña librería de componentes usando Bootstrap y Jade, de forma que en futuros proyectos pueda reutilizar buena parte del código utilizado aquí, consiguiendo por un lado estructurar los diferentes componentes de forma fácil y con un estilo más propio.

Pero... ¿Por qué usar Jade?  Me gusta la sintaxis limpia y su uso de la indentación como forma de anidar etiquetas, es muy del estilo de Python ¿Y porque Node.js?  Si bien con programas como Prepros podría haber prescindido del backend y limitarme a usar Jade de forma que Prepros se encargara de convertirlo a HTML pero por un lado quería familiarizarme más con Node y Express y por otro quería dejar abierta la posibilidad de creación de componentes de forma dinámica.  Por ejemplo, si queremos crear una tabla determinada tendríamos la estructura base y a partir de ahí habría que modificarla, sin embargo, si introducimos un formulario que nos pida filas, columnas u otros datos podemos crear una lógica para generar esa determinada estructura.

Notas adicionales del proyecto

 

El código del proyecto lo tenéis en mi Github, más concretamente en https://github.com/ShinFDuran/Jade-Bootstrap.  Mi idea es que en cada commit añadir una funcionalidad y salvo en casos muy simples añadir un documento en la carpeta docs donde explicar un poco en más detalle el commit.

Cada cierto tiempo o número de commits, postearé aquí realizando un resumen de los cambios acompañado de algunas opiniones, problemas o ideas que me han ido surgiendo.

¿Qué es un ORM?

Bajo las siglas ORM se oculta las palabras Object-relational mapping, lo que viene a ser intentar un modelo de un objeto que se pueda traducir a una base relacional, aunque actualmente también sirve para bases no relacionales.  Aunque antes de entrar en detalle, una pequeña introducción.

¿Cómo se hacía antes?

Anteriormente... y cuando digo anteriormente, digo hasta hace 1-3 años o incluso actualmente, ya sabéis que la informática y el desarrollo web cambia en muy poco tiempo, se partía de una base de datos determinada como MySQL, PostgreSQL, SQLite,... en función de la base de datos teníamos unas consultas u otras ya que tienen pequeñas diferencias.

El método que se seguía era generar un string con la consulta (este estaba formado por una parte fija y otra variable aunque el resultado final era un string) después "lanzarlo" a la base de datos y ahí controlar si había un error o si lo que nos devolvía era un resultado vacío o no.

Posteriormente, ese resultado debía ser procesado.  Como podéis ver todo esto era un proceso tedioso y no muy eficiente en cuanto al tiempo a decidarle.

¿En qué se diferencia ahora?

Mientras que anteriormente el proceso era más pesado y requería conocimientos de base de datos y dependía tanto del lenguaje de programación como de la base de datos, los ORM lo que pretenden es crear una capa intermedia que nos abstraiga de la base de datos y sea más compatible y fácil de usar.

Ahora, en función del módulo de ORM que usemos Sequelize o Mongoose en Node.js (JavaScript), Eloquent en Laravel (PHP), el ORM de Django (Python), u otros tantos tienen una forma de crear un modelo con una serie de atributos.  Se crea una única vez y tiene una forma muy similar a lo que sería un objeto en ese lenguaje.  Ese modelo servirá para las bases de datos que sean compatibles con el ORM y en lugar de conocer cómo hacer las sentencias hay que conocer los diferentes métodos que nos ofrece.

Dicho de otra forma, permite crearnos una estructura de objetos y métodos fácilmente entendibles abstrayéndonos de las bases de datos a la vez que las hace más portables.

¿Entonces?

 

En la medida de lo posible, salvo que queramos apurar y sea necesario podemos desentendernos totalmente de las bases de datos y su sistema de consultas, al menos en pequeños proyectos, en otros más grandes donde haya que tener en cuenta la eficiencia si es importante saberlo, la elección de índices y estructura de objetos en MongoDB puede cambiar brutalmente la eficiencia si se manejan muchos datos, pero por lo general para esos casos suele ya haber un especialista que se encargue.

En todo caso, lo mejor que podemos hacer, es empezar a utilizarlo lo antes posible.  Pero como ya he dicho dependerá del lenguaje y framework que estéis usando.  Quienes no estén usando uno, mucho están tardando, es como el front-end que no usa un preprocesador para CSS es algo que no tiene sentido si quieres ser bueno y productivo en tu trabajo.

Re-presentación

Como ya comenté hace poco, retomo el desarrollo web y este blog de paso.

No voy a entrar en detalles que ya expuse en su día con más o menos profundidad, por un lado que me llamo Francisco Durán Navarro y que podréis verme en diferentes redes o con ese nombre o con el nick ShinFDuran.  ¿Motivo? El nombre completo es muy largo, quien me haya escrito un correo lo entiende, FDuran está ocupado así que decidí usar ShinFDuran.  ¿Qué es "Shin"? "Shin" es una palabra japonesa que significa "Nuevo", sí... no es muy original... pero me gusta.

Me he propuesto de postear al menos 3 veces por semana, para intentar no dejar esto de lado, lo considero una buena herramienta para obligarme a poner algunas de mis ideas en orden, investigar un poco y que los demás me conozcan y vean mis intereses e inquietudes.

¿De qué voy a hablar?

• Proyectos en los que estoy trabajando
• Temas de interés relacionados con el Front-end: Task managers, preprocesadores, performance, cross-browsing,...
• Temas de interés generales relacionados sobre otros campos, mayormente back-end: Estructura REST, Laravel, Vagrant,...
• Temas actuales, que aunque no queramos profundizar sí nos vendría bien saber al menos que es: React.js, Material Design, ECMAScript 2015, Go,...
• Libros/tutoriales recomendados
• Webs de recursos
• MOOCs interesantes
• Salud, productividad,..

Nada más que escribir, veremos a ver si consigo mantener este reto, igualmente, que quiera poner al menos 3 no significa que sean sólo 3, no hay límite superior en cuanto a número de artículos.  Por cierto, sobra decir que considero este mi primer artículo de la semana XD

Recuperando la ilusión

¡¡Wuala!! Sí que ha pasado tiempo de la última entrada... y no menos cosas.

Creo que lo mejor es empezar con una explicación. ¿A qué  se ha debido el dejar el blog de lado? ¿Y por qué retomarlo ahora?

Los motivos de dejarlo de lado

En su día, tenía la convicción de dedicarme al desarrollo web (y aún la tengo) pero después de dedicarle una gran cantidad de esfuerzo a aprender, no tan sólo desarrollo web, sino también zonas adyacentes como SEO, marketing online, diseño web, UX; si en su día hasta dediqué 2 tardes a tutoriales únicamente sobre el buen uso de la tipografía y su importancia.  Esto me ha dado un conocimiento más amplio, pero a la hora de la verdad ha sido una inversión de tiempo que ha dado pocos frutos.

Ya lo comenté en otras entradas, mi némesis es el diseño.  Mira que dediqué tiempo a aprender las bases del diseño, un buen diseño realmente podría basarse en seguir una serie de pasos en función de patrones de diseño, accesibilidad y otros conceptos.  Un buen diseño no depende de la inspiración (el diseño excepcional sí), de hecho la inspiración puede hacer que el diseño sea nefasto por primar el impacto visual sobre la usabilidad o por romper con unos determinados patrones de diseño haciendo que el usuario se sienta confundido y no pueda cumplir con sus objetivos de forma eficiente.

Si bien se podría limitar la cantidad de opciones en el diseño, siguen estando ahí y en tanto que no me resulta cómodo se hace improductivo, más aún, cuando implica una gran cantidad de tiempo en profundizar en ello; inversión de tiempo que en un futuro trabajo de desarrollador no sería rentable.

Incluso intenté a través de foros y comunicades formar grupos en los que hubiera diferentes roles, con nulo éxito.  Como resultado de esa aparente falta de resultados después de tanto esfuerzo y a otras condiciones personales que ocurrieron un tiempo después, uno tiende al conformismo a ir viendo lo que va saliendo en lugar de pelear y buscar lo que uno quiere.

De nuevo la luz al final del túnel

Las personas como entes emocionales que somos, estamos muy influenciados por el entorno, por decisiones e incluso por actos más o menos fortuitos.  Hace unos meses se produjo esa chispa que inició el fuego de cambiar las cosas, en cierta forma "obligado" volví a entrar en contacto con el mundo web y volví a recordar que esto es lo que me gusta y lo que quiero hacer.  Que el mero hecho de que en su día no consiguiera unos buenos resultados o el contexto pasado no fuera idóneo, no era motivo para dejarlo de lado.

Después de este "descanso" he podido comprobar que un año en el mundo web es una eternidad, la velocidad a la que avanza es enorme.  Sólo el hecho de "estar al día" ya supone una gran inversión de tiempo y esfuerzo, el entrar, mucho más.

Por eso mismo, es de vital importancia fijarse unos objetivos o campo de especialización e intentar centrarse en los recursos necesarios para poder cumplirlos, actualmente querer ser bueno en las diferentes partes de la creación y mantenimiento de una web si bien es muy difícil, pero incluso, aunque se pudiera no lo considero rentable debido a la enorme inversión de tiempo necesaria.

En lo que a mi respecta, me centraré en el front-end; probablemente tendré que tocar algo de diseño y back-end pero intentaré que sea lo mínimo posible aunque los resultados en esos campos no sean buenos, ya tengo algunas ideas/proyectos entre manos e intentaré en la medida de lo posible darlos a conocer.

Porque otro punto importante, para adquirir verdadera maestría en algo, es necesario practicarlo.  Mas allá del tiempo necesario para invertir en aprender otros campos, si luego no se practica, se tiende a olvidar y al final, el resultado se queda en nada.

Ya sólo me queda animar a todos los que os guste alguna parte de este mundillo a seguir intentándolo y no dejarlo de lado, la perseverancia es una virtud, aunque cueste a veces sobreponerse hay que ser positivo y seguir peleando por lo que uno quiere.