Cada vez que inicies tu terminal puedes empezar el día con una frase motivadora 😀
Instala primero fortune:
brew install fortune
Luego instala cowsay:
sudo gem install cowsay
Por último agrega a tu .bashrc o .bash_profile:
fortune -s | cowsay
Y listo cada vez que abras tu terminal veras la magia.
Quiero escribir este post para agradecer a todas aquellas personas que me hicieron notar su aprecio, estima y cariño hacia mi persona, es complicado encontrar las palabras apropiadas para agradecer tantas muestras de estima y consideración. Muchas gracias a todos.
En especial quiero agradecer a mi familia que siempre está conmigo apoyándome, a mi linda esposa que organizó una bonita cena y se encargó de que el día fuera genial (te amo Auro).
Empiezo el camino hacia la siguiente versión muy animado de algunos cambios que estoy haciendo en el campo personal, sobre todo en mi salud, espero que muy pronto se den cuenta de ello y también en el campo laboral, también ya habran noticias.
Nuevamente muchas gracias a todos 🙂
p.d:
Feliz cumpleaños @neosergio …cada vez más orgullosa de ti! Love you bro! #sisterproud++ pic.twitter.com/fA31qzi1PV
— Milagros Infante M. (@milale) May 4, 2016
@neosergio Happy https://t.co/GpJHNXoXSq pic.twitter.com/NEdiUhbQOC
— Roy RV (@RoyRV13) May 4, 2016
Últimamente hay una moda en crecimiento por el uso de librerías y frameworks que faciliten el desarrollo de software y reduzcan considerablemente el tiempo y esfuerzo empleados, sin embargo a la vez que este crecimiento tiene sus ventajas, también se ve una reducción en la calidad de código. Hace unos meses leí una pregunta en una lista de correos sobre Django, la pregunta era: ¿Se puede hacer operaciones matemáticas en Django?, quedé con un gigantesco WTF en la mente. Al principio pensé que debía ser un error o que quizás se refería a algo más con plantillas o algo así, me quede pensando como carajos no pregunto ¿Cómo se hacen operaciones matemáticas con Python?, puesto que Django sólo es un framework el lenguaje es Python, continué leyendo el hilo y se trataba de un error de novatos, el que escribió la pregunta estaba sumando una variable simple con un diccionario por lo que recuerdo. Pero esta pregunta es solo una de las tantas que se pueden leer en tuits, foros y demás, como consecuencia de no haber aprendido primero el lenguaje de programación y luego el framework. Mi hipótesis es que estos “nuevos programadores” que producen en su gran parte código basura y proyectos insostenibles en el tiempo son el producto de tanto humo generado por cursos online con instructores inexpertos que no tienen proyectos reales en su historial, por tanto mentor y guru que usan hangouts para seguir vendiendo lo que sabe a duras penas. El uso de frameworks sin el conocimiento sólido del lenguaje de programación hace que la experiencia sea mas difícil debido a que se incurren en errores simples, incluso de sintaxis en muchos casos. He compilado de acuerdo a mi experiencia una serie de consejos que pueden ayudarle a cualquier programador a tener mejores resultados con cualquier framework y producir con ellos mejores resultados.
Si quieres agregar algo a esta lista o tienes una opinión diferente déjala en los comentarios.
Actualización: Cambié la imagen del post, ya que Symfony estaba mal escrito, gracias @mario21ic por notarlo.
Happy coding 🙂
Hay muchas religiones en la actualidad y a sus fieles se los llaman: Pythoneros, Javeros, PHPeros, Raileros, Javascripteros, PuntoNeteros y cualquier otra forma de llamar a un programador que le gusta y usa el mayor tiempo un lenguaje de programación, cada programador en algún momento se ha visto tentado a defender con todo a su alcance a el lenguaje de programación favorito, y es muy común encontrarse con batallas épicas y discusiones acaloradas en las listas de correo.
Yo hasta hace unos tres años era del tipo: “yo solo uso estos lenguajes nada mas y no me jodan” (PHP, Python, C++ y Javascript) y también del tipo “Yo sólo uso GNU/Linux o cualquier otro tipo UNIX o BSD y el resto de sistemas operativos sólo sirven para jugar”.
Pero hace tres años decidí alternar mi manera de trabajar (freelance) con un trabajo a tiempo completo dedicado a construir software, fue una decisión difícil, involucraba mudarme de ciudad (con lo tedioso que pueden ser las mudanzas), vivir lejos de la familia, tener un horario de oficina (con las reglas de oficina, algo que para un freelancer puede ser bastante incomodo), sin embargo la oportunidad de trabajar con clientes importantes de USA era un gran motivante, el apoyo de mi esposa fue fundamental en esto y así decidimos dar el paso.
Este cambio hizo ampliar mi visión, me hizo entender finalmente que en la industria del software a gran escala lo que interesa por encima de la forma como se hacen las cosas y las herramientas que se usan, están los resultados, que el software libre y el opensource son buenos pero que son mejores si se integran con el software propietario, es mejor la armonía tecnológica que estar limitando la creatividad porque el software que usas no se adapta a lo que necesitas.
No me arrepiento de mi pasado radical, el de solamente usar cosas abiertas y libres, aprendí de eso, aprendí a defender y sustentar mis opiniones con fundamento técnico, aprendí mucho al enfrentarme a los que defendían el software propietario y que no conocían internamente su funcionamiento, aprendí a buscar siempre el porque de las cosas, la única diferencia es que ahora, si debo usar software privativo o desarrollar software privativo, pues ya no soy radical, le doy una oportunidad, analizo que opción se acomoda a mi forma de trabajar y elijo la que me hace más productivo.
A partir de ahora en este blog no sólo postearé cosas sobre software libre y opensource, también postearé cosas sobre software privativo, no al nivel de volverme fanático de una u otra tecnología, sino tratando de ser lo más objetivo posible, siempre poniendo por delante los resultados y la productividad.
Seguiré contribuyendo al software libre y opensource como lo he venido haciendo hasta ahora, para mi es más efectivo contribuir con código, creando o solucionando bugs, que tener peleas eternas en las listas de correo, o redes sociales, que al final no producen valor, y muchos menos perteneciendo a comunidades o asociaciones que lo único que buscan es vivir de los eventos y actividades para su beneficio personal, pero que no tienen forma de sustentar (cuantitativamente) sus aportes y sólo están a la espera de conseguir un buen “contacto”.
SVN y Git provienen de dos modelos distintos de control de versiones: el centralizado y el distribuido, en la práctica son similares, sin embargo existen marcadas diferencias que hacen que la elección de cuál usar en un proyecto, dependen de varios factores.
El modo de guardar la historia: Para SVN la historia de un proyecto nunca cambia, sin embargo Git permite modificar commits anteriores usando por ejemplo: git rebase. A pesar de que puedan haber maneras de editar el mensaje de un commit en SVN, esto requiere permisos de administrador, algo que no es recomendable si hay que darle permisos de administrador con equipos de trabajo grande.
Estructura del directorio: Para SVN se deben tener carpetas distintas para trunk, branches, y tags, en Git todo esta en una sola carpeta y Git se encarga de ocultar el master, branches y tags.
Subproyectos: Un subproyecto permite compartir código o módulos entre proyectos, para SVN se usa el svn-external y en git existen los Git submodels, comparten el mismo concepto pero el uso y el flujo de trabajo es el mismo.
Este artículo de Github amplia esta breve explicación de las diferencias: https://help.github.com/articles/what-are-the-differences-between-svn-and-git
Hay casos específicos en los cuales su combinación de verdad que resuelve muchos problemas, sobre todo aprovechando que el uso de Git para ramas locales es fantástico.
Actualmente trabajo en Belatrix y por motivos de contrato con el cliente (confidencialidad), no puedo mencionar detalles, nombres, mucho menos información privada del proyecto, sin embargo puedo explicar el flujo de trabajo que usamos y que se puede replicar en otros proyectos.
Mi cliente es una compañía multinacional que tiene un producto muy bueno de banca móvil, completamente configurable y adaptable a los sistemas bancarios actuales, lo que hace que tenga a su vez miles de clientes (entidades financieras) que usan su producto y por lo tanto al final el producto que ayudamos a construir es usado por millones de personas alrededor del mundo, para lograr y mantener ese éxito tan grande que están teniendo ahora, se necesitan muchas personas involucradas en el desarrollo del producto, decenas de desarrolladores usando los mismos repositorios, las mismas ramas, con diferentes permisos de acceso y demás. Mi cliente ha elegido SVN como gestor de sus repositorios, por diversas razones técnicamente justificables.
A pesar de que la tendencia se da hacia modelos distribuidos de control de versiones (Git y Mercurial en su mayoría), el uso de SVN sigue siendo masivo en muchas empresas y proyectos.
En este proyecto Belatrix lleva aproximadamente 4 años y nuestro equipo en particular lleva un año y medio aproximadamente, al principio mi equipo empezó a utilizar git-svn para manejar ramas locales y funcionaba muy bien, el cliente tenia una rama principal, una rama para el proyecto, una rama para el modulo que estábamos desarrollando, y nosotros gracias a git-svn teníamos ramas para lo que queramos: bugs, User Stories, improvements, cleanups y encontramos un flujo de trabajo muy bueno y simple de mantener.
Para lograr esto usábamos git-svn (https://www.kernel.org/pub/software/scm/git/docs/git-svn.html), todo iba bien hasta que en el lado del SVN se empezó a usar svn-externals, a partir de entonces dejo de funcionar git-svn y si hubiéramos querido forzarlo, hubiéramos complicado el flujo de trabajo y probablemente hubiéramos aumentando las probabilidades a cometer errores.
Es aquí donde encontramos una forma simple de continuar con nuestro flujo de trabajo y este fue un par de cambios en el .gitignore, el flujo de trabajo es como el que describo a continuación:
Si te sirve sienteté libre de comentar, sugerir una mejora para este flujo y compartirlo 🙂
Hace dos años tuve la iniciativa de hacer un curso en español sobre Django, uno que me permitiera plasmar lo que aprendí como programador, mi intención de colaborar con la comunidad de programadores y mi experiencia como profesor universitario, me contacté con @cvander y el resultado fue un tremendo éxito, mucha gente escribiéndome al día, cientos de correos electrónicos con muchas consultas, realmente logre mi propósito, el acercar Django a la comunidad hispana a través de Maestros del Web, fue una experiencia estupenda.
Luego de hacer el curso y que se publicará empezaron a aparecer muchos cursos que eran parecidos al mío, en video, audio y con otros ejemplos, en un momento me llego a molestar pues simplemente a veces copiaban el curso le cambiaban el nombre y lo publicaban, pero luego comprendí que es normal que eso suceda y que por el contrario de molestarme lo empecé a tomar como un agradecimiento.
Sin embargo como siempre hay gente que llego a pensar que tenia el derecho de exigirme que les de soporte, que solucione sus errores de codificación, que su trabajo dependía de ello y obviamente lo pedían de mala manera, hay gente que no lee, simplemente copia y pega el código y cree haber aprendido, o incluso gente que tuvo errores simples con sintaxis de python y que insistía en que yo corrija su código.
En los últimos meses he estado recibiendo varios correos con supuestos errores que tiene la guía y que dicen que es malo, sin darse cuenta tal y como esta escrito que la versión que use es la 1.4 y obviamente va a fallar con las nuevas versiones del framework, hay tanta mala onda en esos correos que simplemente me canse de contestarlos, y aquí viene la pregunta que me hizo @shinjiDev
@neosergio y por qué no actualizarla? =)
— Christian Palomares (@shinjiDev) August 1, 2014
Y pues de verdad que lo intente, escribí algunos capítulos con la versión 1.5, luego no pude concluirlo, mi situación laboral cambio, llegaron mas responsabilidades a mi vida profesional, lo retomé, actualicé y escribí algunos capítulos con la versión 1.6 y nuevamente llegaron mas responsabilidades profesionales, hice un último intento por actualizar lo poco que había escrito para la 1.6.5 y ahora lo veo ya innecesario porque la 1.7 está por salir y realmente no quiero dar falsas esperanzas a aquellos que me siguen escribiendo y pidiendo que actualice la guía, se necesita un gran esfuerzo para cumplir con publicar semanalmente y con una calidad aceptable y capturas de pantalla, con código entendible y depurado sin mencionar que se debe publicar gratis, y lo que vendrá luego ayudar a muchos a solucionar los problemas que puedan tener, a asesorar y a responder correos a los que no leen del todo.
Así que por ahora, pienso aprovechar que esta por salir la 1.7 y refactorizar la estructura de la guía, sacar una nueva versión o porque no convertirlo en un libro, esta vez pienso usar Leanpub me parece una buena opción.
Todo este contexto me ha permitido aprender y dar estos consejos si alguna vez se animan a publicar un curso o guía técnica:
Empezaré a trabajar desde ahora en la nueva versión de esta guía, que espero que se convierta en un libro.
Actualización: Aquí está disponible el PDF del Curso de Django en Maestros del web
Actualización 29/01/2017: Hace varias semanas atras he recibido varios email y mensajes para poder actualizar al menos en parte el proyecto en github con una versión mas reciente del framework, aún me sigo sorprendiendo que despues de 5 años muchos sigan tomando el curso como base para aprender Django, asi que me tome un tiempo para poder actualizar los archivos principales, asi que ahora hay una nueva versión del proyecto en github compatible con Django 1.10.5.
Cuando se tiene una idea de una aplicación móvil o una interfaz especial para web móviles (no responsive, sino especificamente construida para movil, algo como los que tienen el subdominio m.ejemplo.com), empezamos a imaginar como debería lucir en el móvil, la distribución de componentes y otros detalles claves, que determinan el éxito o fracaso de una aplicación. Es en esos momentos en los cuales es ideal consultar galerías y patrones de interfaces, que presentan soluciones comunes a las que el usuario ya esta acostumbrado y que permite. Estas son las fuentes de inspiración que a mi parecer tienen la mayor cantidad de patrones:
Especializada en patrones de interfaces de usuarios para iPhone y iPad, posee mas de 2000 patrones. 
Esta más enfocado a patrones de interacción en interfaces de usuarios para Android. 
La galería relacionada al libro de Theresa Neil sobre patrones de diseño móvil de editorial O’Reilly, $9.99 como ebook para kindle que valen la pena. 
Patrones de diseño para android, son diversos screenshots de interfaces existentes.
Diversos patrones de diseño para iPhone y Android 
Recursos visuales que se pueden descargar y también comprar, algunos muy creativos e innovadores, definitivamente gran fuente de inspiración 
Ademas de tener patrones para iPhone y Android, también posee una categoría para iPad. 
Es mas una colección de elementos visuales, pero que también valen de inspiración
Aqui puedes encontrar elementos visuales al igual que el anterior, pero orientados a iOS y OS X, incluyendo una clasificación por licencias.
Estas son algunos de los mejores recursos online que se pueden utilizar para buscar inspiración y patrones que funcionan.
Happy UI designing 😉
