viernes, diciembre 30, 2011

Teclado en español Latinoamérica

Cuando empecé a utilizar computadoras lo hacia únicamente con teclados en ingles (EN-US) ya que al vivir en Tijuana (frontera con San Diego) era más fácil (y barato) conseguir teclados en ese idioma. Ademas todos los programas que utilizaba estaban en ingles. En esa época era común el uso de (alt+164) para las ´ñ’ y otros códigos más.

Como programador seguía con el teclado EN-US cuando trabajaba desde la “oficina” de la empresa. Como parte de un proyecto tuve que estar en sitio por varios meses en una empresa de la cuidad donde las estaciones de trabajo todas tenían teclados en español Latinoamérica. Durante algún tiempo batallé para acostumbrarme, sentía que odiaba los teclados en español. Recuerdo que un amigo en la universidad usaba un teclado en español en su casa y me llamaba la atención por qué alguien haría eso a propósito, pudiendo usar un teclado en ingles. Recuerdo, también, que me comentó lo fácil que era escribir la ‘ñ’, los acentos, signos de puntuación, etc. Ahí fue cuando empecé a ver la ventaja.

Tiempo después fue necesario reemplazar mi viejo equipo personal y al comprar una laptop en Tijuana, sin darme cuenta,  venia con teclado en español. Como ya estaba acostumbrado al teclado, por el trabajo en sitio, fue fácil usarlo. Una vez que deje de trabajar en sitio seguí trabajando fuera de la oficina, ahora desde mi casa, y seguía utilizando teclado en español.

Después de un tiempo cambié de trabajo y en esta empresa nos daban a cada uno una laptop para trabajar en ella. La laptop tenia el teclado en ingles, todo estaba bien hasta que necesitaba escribir acentos o ‘ñ’ es decir texto en español. En esa época fue cuando empecé a utilizar el teclado en EN International Sort. El cual ayuda con el texto en español pero no es tan cómodo como el teclado en español sobre todo al escribir comillas, lo cual puede ser común al momento de programar.

En la actualidad cuando trabajo desde una computadora de escritorio utilizo un teclado en español (México) y cuando trabajo directamente desde la laptop lo utilizo en ingles (international sort) ya que mi laptop personal tiene teclado en ingles. Traté de comprarla en México para tener el teclado en español pero por el costo/beneficio la compré en US con teclado en ingles.

En estos años usando teclado en español no he notado que afecte mi productividad al programar, han habido detalles cuando compañeros de trabajo ingresan a mi maquina de manera local o remota y no pueden teclear; pero fuera de eso no afecta y a la vez siento que me facilita la escritura de texto en español cuando es necesario.

¡Ah olvidaba mencionar! Hace tiempo me toco usar teclado en español internacional y ese teclado definitivamente no me gustó. Será quizás que no estoy acostumbrado; pero lo sentí muy incomodo.

Nota: Esta entrada fue escrita desde un teclado en ingles (International sort).

Post relacionado: Software en español

jueves, diciembre 29, 2011

Software en español

Aunque uso principalmente solo software en inglés, seguido tengo la tentación de usar software en español. Tanto en el sistema operativo como en las herramientas de desarrollo y de base de datos.
Esto me pasa más cuando se trata de software administrativo, de entretenimiento o aplicaciones donde necesito escribir en español. En esos casos creo que sí tiene sentido usar aplicaciones e incluso el sistema operativo en español. Porque lo que realizo es en español y el programa (al estar en el mismo lenguaje) puede ofrecerme ayuda adicional. Por ejemplo prevenir faltas de ortografía, de gramática, etc.
El problema viene al tratar de usar herramientas de desarrollo que no están en ingles, ya que el desarrollo debe ser en inglés y si la herramienta de desarrollo esta en español es una desventaja. Tanto en los mensajes de error como en la terminología utilizada. Puede ser difícil encontrar información sobre términos técnicos en español o por lo menos encontrar información reciente.
Hace tiempo instalé la versión en español de visual web developer y se sentía raro usarlo, algunos mensajes arrojados por las excepciones no me eran familiares por estar en español. Pero fue algo divertido y quizás lo vuelva a intentar pero siento que podría haber problemas de compatibilidad con el resto del equipo.
¿Es común usar software completamente en español? Por lo menos en frontera no lo he visto así; pero me gustaría saber como sería la experiencia. Quizás el próximo año me anime a hacer el experimento e instale todo en español para saber que se siente. Aunque presiento que no será posible tener las versiones más recientes.
Post relacionado: Teclado en Español Latinoamérica

viernes, diciembre 23, 2011

Usando varios atributos en C#

Al trabajar en proyectos sobre ASP.NET MVC, al crear los modelos he estado usando Data Annotations las cuales consisten en agregar atributos a las propiedades de tu modelo para indicar algo de meta datos que pueden ser usados por la vista. Además de que al usar entity framework code first he necesitado en alguna ocasión usar atributos, aunque últimamente he optado por configurar eso en el mapping del DbContext. También en lo controladores hay necesidad de escribir algunos atributos para los Action Filters.

He visto que la forma más común para agregar más de un atributo a una clase, propiedad o método es escribiendo uno abajo del otro. Con lo que al declarar una propiedad que tiene varios meta-datos se termine con varias líneas de código. O al definir una acción en un controlador donde necesitas que se ejecuten varios action filters termines con varias líneas en la declaración del método, lo cual (en mi opinión) se ve igual que si se ejecutan las llamadas de los filtros dentro de los métodos.
[Required]
[DataType(DataType.Password)]
[Display(Name = "Current password")]
public string OldPassword { get; set; }

En mi caso me ha gustado más el escribir los atributos uno a un lado del otro separados por coma dentro del mismo par de corchetes. Esto hace que sean menos líneas la declaración de un método, propiedad, etc. Y lo principal es que (para mi) se ve más claro. Es decir no es por ahorrarme líneas, las líneas son gratis, sino para quitar ruido en el código.
[Required, DataType(DataType.Password), Display(Name = "Current password")]
public string OldPassword { get; set; }

Como todo es cuestión de gustos y si todo el equipo decide usar uno abajo del otro me tendré que alinear; pero por lo pronto prefiero escribir uno después del otro.

jueves, diciembre 15, 2011

CoffeeCamp: El año en revisión

La comunidad .Net de Tijuana organiza un CoffeeCamp el próximo Sábado 17 de diciembre de 2011 en el café Starbucks que esta frente a las torres. El tema es "El Año En Revisión". La idea es reunirnos y platicar de software mientras nos tomamos café (u otra cosa). En la página del evento pueden encontrar más información.




Si eres desarrollador y estas en Tijuana el Sábado 17/12/11, esperamos verte por ahí.

jueves, noviembre 24, 2011

Dev3Cast (Podcast) sobre FubuMVC

El pasado 12 de Noviembre participé en el podcast Dev3Cast. Donde junto con Gabriel Flores (@gabo)  platicamos con Francisco Ruiz (@squidge) sobre FubuMVC. El cual es un proyecto de código abierto para el desarrollo de aplicaciones web que corre sobre .Net (es una alternativa a ASP.NET MVC).

Escucha el episodio y deja tus comentarios.


viernes, noviembre 18, 2011

Mantenerse al día

Cuando empece a programar, la forma en que aprendía era principalmente a través de libros; pero sobre todo con la ayuda que me proporcionaba el entorno de desarrollo. Buscaba ejemplos que mostraran como utilizar cierta función o ejemplos de como lograr lo que quería hacer.

Desde hace ya buen tiempo que no instalo la ayuda que viene con los entornos de desarrollo. Esto se debe, principalmente, a que es más rápido hacer una búsqueda en Internet sobre como funciona algo a buscar en la documentación que viene con los programas.

Esto también ha ido pasando con la forma en que aprendo a usar o hacer cosas nuevas. Aun sigue siendo un buen recurso el tener un libro sobre tecnología. sobre todo los que son sobre principios básicos; pero también es cierto que los libros que tratan sobre tecnologías especificas rápidamente quedan obsoletos.

Ahora para aprender sobre alguna tecnología (framework, lenguaje, librería, etc.) me ayuda el buscar información en Internet, generalmente es fácil encontrar la teoría sobre la cual esta fundada esa tecnología que quiero aprender. De ahí trato de buscar screencasts. En lo personal me ayuda mucho ver un screencast donde se vea la aplicación de esa tecnología. Para ver lo especifico y así tratar de aplicarlo en una practica.

Algo que me ayuda, también, a estar enterado de que es lo que se usa fuera de mi trabajo. Es el escuchar podcasts con regularidad. Aunque no todo lo que escucho lo trato de poner en practica, aun así me sirve para estar enterado de las opciones que hay disponibles. Y así cuando se presente una oportunidad, por lo menos sabré que preguntas hacer ya que conoceré un poco del tema. El leer blogs también ayuda -es muy incomodo tener discusiones con algún desarrollador por temas que hace años la comunidad ya resolvió-. Ademas de asistir a las reuniones de los grupos de usuarios locales y a eventos donde se pueda hablar en persona con quienes usan esa tecnología que quiero conocer.

Otra cosa que me ayuda es tratar de mantener este blog con contenido actual, eso me motiva a presentar buen contenido y por lo tanto a buscar aprender ese contenido que trataré de explicar.

sábado, octubre 29, 2011

Dev3Cast sobre Build

El pasado 5 de octubre participé en un episodio de dev3cast (podcast) donde hablamos sobre lo que se presento en el evento build de Microsoft, en el cual se mostró lo que viene en la siguiente versión de windows y Visual Studio. Tuvimos como invitado especial a Seth Juarez, quien asistió al evento como parte de devexpress y pudo hacer varias entrevistas estando allá. También participamos en la conversación Gabriel Flores, Samuel Arellano y yo.

jueves, octubre 27, 2011

Dev3Cast sobre ASP.NET vNext

El día de ayer participe en la grabación de un episodio del podcast de la comunidad de usuarios .net en Tijuana, dev3cast. Donde hablé, junto con Gabriel Flores y Samuel Arellano, sobre algunas de la características que vienen en la próxima versión de ASP.NET.

lunes, octubre 03, 2011

Rumbo a MagmaRails (parte 4)

En la parte anterior de la serie, generé el modelo y controlador para los invitados, además de que modifiqué el archivo routes.rb para colocar a los invitados como recursos dentro de otros recursos:

resources :weddings do      
resources :guests
end

Esto hace que pueda tener una ruta como /weddings/{wedding_id}/guests/ para mostrar la lista de invitados según la boda que se pase a través del URL.


Para leer el valor de la boda dentro del controlador utilizamos la variable params la cual es como un diccionario. Así dentro de nuestro controlador de invitados podemos obtener el valor del ID de la boda de la siguiente forma:


def index    
wedding_id = params[:wedding_id]
@wedding = Wedding.find wedding_id
@guests = @wedding.guests.all
end

La función del controlador es la de asignar valores a las variables que necesita la vista para mostrarse al usuario. En este caso estoy obteniendo el valor de wedding_id que viene dentro de los parámetros y lo estoy guardando en la variable wedding_id.  después uso ese valor para obtener el objeto completo de la boda (usando el método de la clase Wedding). También obtengo la lista de invitados a través del objeto boda.


Una vez que asignamos los valores a variables, estos pueden ser usados por la vista para mostrarse al usuario.


ya he grabado antes screencasts donde se muestra algo de esto. En aquella ocasión usaba netbeans y una versión anterior de rails, pero los mismos conceptos aplican. Pueden verse aquí

lunes, septiembre 12, 2011

jueves, septiembre 01, 2011

martes, agosto 30, 2011

Rumbo a MagmaRails

El próximo 12 de octubre se realizará en Manzanillo la conferencia MagmaRails a la cual pretendo (junto con mi esposa) asistir. Nosotros trabajamos principalmente con tecnología .Net así que para practicar un poco de rails inicié un proyecto y estoy grabando algunas partes en screencasts de 5 minutos.  Aquí el primero:

Entradas relacionadas:
- Rumbo a MagmaRails (Parte 2)
- Rumbo a MagmaRails (Parte 3)

miércoles, junio 29, 2011

Reunión 44 de Tijuana .Net Sobre Razor

Razor

El día de hoy estaré presentando en la reunión 44 de la comunidad el tema de Razor. Hablaremos de la sintaxis de razor usando WebMatrix en webpages y después un ejemplo de un blog usando razor en asp.net mvc en Visual Studio.

Los temas serán:

  • Code blocks
  • Syntax, encoding
  • Code expresions
  • Html Helpers en razor
  • Layout
  • Sections
  • Html helper en C#
  • EditorTemplates
  • Partial Views
  • Html.Action

Esperamos grabar la presentación y mostrarla aquí y en la página del evento.

viernes, junio 17, 2011

Adicción a la Refactorización

Siempre que trabajo en una nueva característica, para algún proyecto, modifico el código antes de entregarlo. Tratando de hacerlo más compacto y/o fácil de leer. Esto con la intención de mejorar la calidad del código.

También cuando necesito modificar cierta funcionalidad existente, cambio el código antes de implementar los cambios. Con la intención de entender mejor la funcionalidad actual y así dejar todo listo para realizar los cambios que se requieren implementar. Una vez hechos los cambios vuelvo a buscar áreas donde haya oportunidad de refactorizar…hasta ahí creo que todo va bien. El problema viene cuando se convierte en una especie de adicción.

Hay ocasiones que al trabajar en alguna característica determinada me encuentro con algún trozo de código “malo” que no esta relacionado con lo que estoy trabajando y aun así siento la necesidad de modificarlo. A veces logro aguantarme las ganas; pero otras veces simplemente no puedo evitarlo. También me pasa cuando algún compañero de trabajo me pregunta  algo especifico y al mostrarme el código quiero empezar a modificarlo, cuando ese no es el punto de la pregunta que me hicieron. Aunque estoy tratando de que el código sea mejor, puede convertirse en un problema.

A veces no se si lo hago por el proyecto o lo hago por mi. El código “malo” puede ser mucho, por lo tanto requiere algo de tiempo. Aunque hay herramientas que ayudan con la refactorización (ya sea como parte del IDE o como plugins), aun así es tiempo que le estoy quitando a tareas que el cliente espera y que están pendientes por realizar.

Estoy convencido de que La refactorización constante ayuda a la calidad del código, mantiene activo al proyecto, previene en cierta medida que el proyecto se vuelva legacy. Pero también debo aceptar que existe código que se puede mejorar y que esta bien (si funciona) dejarlo así como esta. Aunque sea difícil de vencer la tentación de mejorarlo. Es importante enfocarse en las tareas que le dan valor al usuario y en ocasiones la refactorización no da ese valor.

Como en todo lo demás: “Es bueno el uso; pero no el abuso”.

miércoles, junio 15, 2011

Motivación diaria

Hay días en los que siento que soy productivo y tengo muchas ganas de programar. En cambio hay otros en los que simplemente no tengo ganas, estoy frente a la computadora, pero no logro avanzar en las tareas pendientes. Tratando de encontrar cuales son los factores que influyen para estar motivado y ser productivo, identifique los siguientes:

Conocer el dominio del problema: Cuando ya se lo que tengo que hacer es más rápido ponerme a hacerlo. Cuando no conozco el beneficio o la razón de una característica del sistema donde estoy trabajando, o peor cuando no se exactamente que es lo que se supone que debe de hacer, mi productividad baja. Cuando se lo que se requiere, simplemente lo hago.

Comunicación constante: Esto va ligado al primer punto, para conocer el dominio del problema es necesaria una comunicación constante con el cliente. Cuando tengo dudas y el cliente tarda mucho en contestarlas o simplemente no lo hace, en algunos de esos casos simplemente no puedo avanzar, me desmotiva y se me quitan las ganas de trabajar en eso. También la comunicación entre los miembros del equipo me ayuda a mantenerme enfocado en lo que se quiere lograr, no me aburro ni busco algo con que entretenerme en el internet.

Tareas cortas y bien definidas: Tener bien definidas las acciones concretas a realizar me permite concentrarme en esa acción, evitando la parálisis por análisis. Que las tareas sean cortas me ayuda a poder terminarlas en poco tiempo. Dándome una sensación de avance, la cual, me motiva a seguir avanzando en el proyecto.

Café: Hay días que lo más difícil es empezar. Una vez que inicio con las tareas, el resto no es tan difícil. Para iniciar con ganas un café por la mañana ha sido muy efectivo.  Hay ocasiones (generalmente después de comer) que no tengo ganas de programar y lo único que pienso es en la hora de la salida. Para esos casos una bebida energética me “vuelve a la vida”, después ni cuenta me doy cuando ya es hora de irme.

Evitar interrupciones: Una vez que ya inicié a programar es fácil enracharse. El problema con las interrupciones es que me quitan esa viada que llevaba y necesito volver a empezar (que es lo más difícil). Las interrupciones pueden ser tanto internas (por mi mismo) o externas (alguien más me interrumpe). Para las externas no hay mucho que pueda hacer; pero para las internas he notado que el escuchar música me ayuda a concentrarme en lo que estoy, sin tratar de ver que dice la gente en las redes sociales o ver alguna foto graciosa.

Evitar estrés: Una mente tranquila produce más, que una mente casada o frustrada. Algunas veces el trabajo no es como quisiera, ya sea por decisiones de los managers, trabajar con sistemas legacy, “clientes especiales”, etcétera. Aunque me quejo seguido por cosas así, trato de que no me afecte al momento escribir código. Y si me pongo a pensar en esas cosas mejor me voy a caminar un rato, para que se me pase o para hablarlo con alguien más. Para evitar el estrés también ayuda estar bien con la familia, dormir bien… o no dormir Guiño.

Bueno… estos son algunos de los factores que he notado ayudan a mantenerme contento trabajando, motivado y productivo.

jueves, junio 02, 2011

El ingles es parte de las mejores prácticas

Hace algunos años leí un comentario que no me gustó mucho. Decía algo como que todos los buenos desarrolladores sabían ingles. No me gustó, creo principalmente, porque mi primer idioma no es el ingles. Ademas conozco a personas que no hablan ingles y que son muy capaces de desarrollar. Me pareció un poco arrogante el comentario. Sin embargo en ese momento recuerdo que no pude pensar en algún programador que no hablara ingles; pero pensé que se debía a que vivo en la frontera con los Estados Unidos (Tijuana) y aquí la mayoría habla (o por lo menos entiende) ingles.

Ahora, después de ya algún tiempo, me ha tocado conocer a colegas desarrolladores que no dominan el ingles y he visto como sus opciones para buscar información, sobre cualquier tema técnico, se ve limitada comparada con la cantidad de información que se puede encontrar en ingles. Esto es más notorio cuando se trata de tecnología o técnicas nuevas (tendencias).

La mayoría de la información técnica es generada en ingles, incluso cuando para quien la genera el ingles no es su primera lengua. Esto puede causar que por la falta de información, sobre algo nuevo por ejemplo, se pierda competitividad frente a otros desarrolladores que sí dominan el ingles y pueden usar la información a su favor (más en estos tiempos donde google es una herramienta muy usada en el desarrollo).

El saber ingles ayuda a tener más opciones para resolver problemas y eso (en mi opinión) te hace un mejor desarrollador. Ademas los lenguajes de programación y las APIs estan en ingles, conociendo el ingles se puede leer, escribir... por lo tanto entender y mantener el código con mayor facilidad.

Hay varios esfuerzos para tener información disponible en español, ya que es nuestro idioma (creo que este blog es parte de ese esfuerzo). Aun así, si se desea conocer las mejores practicas y como aplicarlas, el ingles debe de estar en esa lista.

viernes, mayo 06, 2011

Dev3Cast Sobre Documentación Técnica

El pasado cinco de mayo participé en un episodio de dev3cast junto con Eber Irigoyen, Haarón González, Samuel Arellano y Gabriel Flores. Donde hablamos sobre la documentación técnica en proyectos de software.

Pueden descargar el episodio y comentar en el sitio de dev3cast para que todos quienes descarguen el podcast puedan leer sus opiniones.

lunes, marzo 21, 2011

Aplicar lo nuevo lleva su tiempo

Uno de los “problemas” que he encontrado al querer aplicar técnicas, usar librerías, frameworks, lenguajes, etcétera. De los que he leído e incluso usado en algún pet Project. Es que al momento de querer aplicarlo en algún proyecto real, este tienen fechas de entrega a muy corto plazo y por lo tanto lo más “seguro”, para cumplir con esas fechas de entrega, es haciéndolo utilizando lo ya conocido y probado en proyectos anteriores.

No es común que el cliente nos pida alguna aplicación y nos de el tiempo necesario para aprender la tecnología a usar. Primero porque desea el sistema lo más rápido posible y segundo porque no quiere cubrir el costo del tiempo invertido en aprender lo nuevo. Cuando al final el recibe el mismo sistema, no importando la tecnología o técnicas usadas en el desarrollo.

Pude ser que esta necesidad sea mas del desarrollador, ya que es él el que trabaja directamente con la tecnología (ya sea framework,lenguaje de programación, etc).

Para poder aplicar/implementar algo nuevo en un proyecto real requiere de un esfuerzo adicional al que se necesitaría para aplicar lo que ya se conoce. Todo, por fácil que sea, tiene su curva de aprendizaje, sus ventajas y sus desventajas y debes de haberte encontrado con algunas de ellas antes de poder usarlo en producción, para que así sepas como resolver lo posibles problemas que se presenten.

Pero entonces. ¿Como puedo aplicar o usar lo nuevo en los proyectos de mi trabajo, si nunca tengo el tiempo necesario? Algo que he tenido que hacer al querer aplicar algo nuevo en proyectos del trabajo es primero practicar por fuera en proyectos personales (a.k.a. pet projects) la tecnología/técnica que me interesa y en una oportunidad que se presente proponer el uso de tal tecnología o técnica. Esta propuesta procuro hacerla mostrando algo ya funcionando (un demo funcional), para convencer de las bondades que tiene utilizar lo nuevo.

Esto requiere dedicarle tiempo extra al trabajo, porque lo aprendido en pet projects lleva su tiempo aplicarlo en proyectos reales. Puede incluso llegar a ser frustrante tardar en realizar algo sencillo que usando lo que ya conocemos lo haríamos en minutos; pero a la larga es aun más frustrante (por lo menos para mi) el trabajar con técnicas/tecnologías viejas, con las que no puedo lograr lo que se que es posible realizar con algo nuevo.

De no dedicarle tiempo por mi cuenta a practicar lo que quiero usar, la decisión de usar algo diferente correría totalmente a cargo de alguien más, ya sea el cliente, jefe o algún programador más que hiciera la sugerencia. Para algunos eso no es problema, esperar que a el jefe/cliente se le ocurra intentar algo nuevo (a veces hasta que ya no es tan nuevo, incluso ya viejo); pero para mi conocer y no aplicarlo no es divertido.

Entonces: Si quiero usar algo nuevo tengo que proponerlo, lo mejor seria hacerlo mostrando avances donde puedan verse las ventajas. Esto requiere algunas veces dedicar algo de mi propio tiempo para aprender las nuevas tecnologías y así poder convencer a los clientes/jefes que estamos listos para usar la tecnología/técnica nueva, porque el cliente no quiere pagar la curva de aprendizaje.

lunes, marzo 14, 2011

La practica hace al maestro

Hace unos días tuve la oportunidad de dar una capacitación (en el .Net Framework) a unos compañeros de trabajo que acaban de egresar de la universidad y que aun no tienen experiencia laboral. Algo común entre ellos era la falta de practica al momento de empezar a escribir código. Podían entender fácilmente el ejemplo escrito por mi, pero no les era igual de fácil escribir código propio.

Me di cuenta que algunos tomaban varias notas en papel sobre lo que íbamos haciendo, en lugar de ponerse a practicar. Esto me hizo pensar que el aprender (y mejorar) a programar debe de hacerse de la misma forma en la que se aprenden las matemáticas. No basta con saber los procedimientos para resolver un problema, es necesario practicar las operaciones con varios ejercicios para poder dominar el tema (y resolver los problemas mas rápido y fácil).

Cuando aprendemos a sumar, restar, multiplicar, dividir, etcétera. La parte de tomar notas es muy poca, la mayor parte del aprendizaje se da al practicar. Lo mismo pasa con la ortografía, no es solo conociendo las reglas, es con la practica constante como aprendemos a escribir mejor y cometer menos faltas de ortografía (como reconocer las palabras que llevan acento).

También se podría comparar con el aprender un segundo idioma, llega un momento en que puedes entenderlo casi perfectamente pero para poder hablarlo correctamente se necesita de practica, equivocarte constantemente hasta que puedas darte cuenta que algo no suena bien y busques una mejor forma de expresarlo. Y si dejas de practícar puede ser que algunas palabras se te olviden aunque no tuvieras ningún problema en entenderla si alguien mas la dice.

Considero para que un desarrollador profesional pueda seguir superándose es importante leer, ya sea blog posts, artículos, código de algún proyecto de código abierto, screencasts, podcasts, en fin… consumir y producir contenido técnico. Pero algo que ayuda mucho a ser un mejor desarrollador es la practica constante, escribir muchas líneas de código, cometer errores y aprender de ellos (echando a perder se aprende). Así que además de leer y tomar notas es necesario practicar constantemente, porque (ya lo dice el viejo y conocido refrán) “la practica hace al maestro”.

sábado, marzo 12, 2011

NuGet Manejador de paquetes

Al trabajar en proyectos en .Net es común hacer uso de librerías de terceros, ya sean de código abierto e incluso de algunas con código propietario. Para usar estas librerías necesitaba ir al sitio de cada una de ellas y descargar la última versión (o la que necesitara) y descargar los archivos, después agregar una carpeta al nivel de mi archivo de solución de VisualStudio que acostumbraba llamarla “Lib” y ahí agregar los DLLs de terceros que usaría en mi solución.

Ahora con NuGet, el manejo de dependencias se simplifica. Lo primero que necesito es instalarlo, lo cual lo puedo hacer desde VisualStudio, usando el Extension Manager y buscando “NuGet”

extension_manager_nuget 

En algunas maquinas con esto fue suficiente, sin embrago (desconozco la razón) en una de mis maquina no pude instalarlo a través del extension manager. Lo que hice fue instalarlo desde nuget.org

nuget.org 

Una vez instalado se debe de reiniciar VisualStudio y aparece una nueva opción en el menú de Tools (Herramientas) y en el menú de View > Other Windows

tools

Con esto se puede abrir la consola de NuGet (se necesita tener instalado PowerShell 2.0) y descargar e instalar desde ahí los paquetes (librerías) que se necesiten para el proyecto actual.

nuget_console

En un proyecto en particular necesitaba instalar MSpec, para eso solo ejecuté en la consola de NuGet:

PM> Install-Package Machine.Specifications


NuGet se encargó del resto: descargar dlls, agregar referencias, etc. El único ajuste que tuve que hacer en mi manera de trabajar es que nuget usa una carpeta llamada “packages” en lugar de “lib” como yo lo hacia. Pero es un pequeño cambio que bien vale la pena para aprovechar lo que hace NuGet por mi.

martes, marzo 08, 2011

Al desarrollador le gusta desarrollar

Seguido leo (y escribo) comentarios, tweets, posts, etc sobre lo mal que la pasamos en ciertos proyectos en los que trabajamos. Aun y cuando lo que nos gusta hacer, como desarrolladores que somos, es desarrollar. ¿Entonces por qué es que surgen estas situaciones de descontento entre los desarrolladores?

Considero que parte del problema es la falta de decisión que se tiene sobre el curso de algún proyecto, la arquitectura, metodología, framework, (peor cuando nos toca usar el intento de framework que hizo alguien más), etc. Esto hace que el desarrollador se sienta como un code monkey, alguien que hace la talacha y no como alguien que desarrolla soluciones para las necesidades del cliente. No hay motivación.

Al participar en proyectos con diferentes empresas he notado que en los proyectos que he sufrido mas frustración, al trabajar en ellos, es cuando el cliente ya eligió que usar y peor cuando ya eligió el como hacerlo. Al iniciar o continuar el desarrollo del proyecto me encuentro con que la decisión del cliente no fue la mejor, muchas veces basada en las viejas formas de hacer las cosas o basado en la tecnología que un tercero le vendió. Esto hace que haya cierta frustración en el desarrollo del proyecto porque estoy en problemas por culpa de alguien más.

Este descontento también aparece cuando no se entienden bien las necesidades del cliente. Ya sea porque se trata de un sistema ya establecido y solo se pide que se corrijan algunos errores. Y no se quiere perder tiempo en explicarle al equipo la importancia de lo que hace el sistema. Esto hace que el desarrollador no sienta el proyecto como suyo y por lo tanto no sienta motivación para mejorarlo.

En cambio cuando se trabaja en proyectos donde el cliente explica, no solo las necesidades sino también las razones por las cuales es importante. Incluso que nos explique porque eligió la posible solución y el como. De una manera en la que el equipo pueda aportar y mejorar esa idea. Es cuando se siente una mayor motivación para trabajar en ese proyecto.

Hace poco grabamos un episodio de Dev3Cast y ahí nos comentaba Iván González sobre la importancia de la confianza en el equipo. Y la importancia de la opinión de todos los desarrolladores, incluso de aquellos que aun no tienen experiencia.

Esto puede ayudar a que el desarrollador sienta el proyecto como suyo y este dispuesto a dar un poco más de esfuerzo con tal de que se logre un mejor resultado, mientras hace lo que le gusta. Los managers deben de tomar ventaja de que al desarrollador le gusta desarrollar.

viernes, febrero 18, 2011

La idea de nuestro propio “Framework”

Creo que muchos de los desarrolladores hemos tenido la idea e incluso iniciado el desarrollo alguna vez de nuestro propio “Framework” para generar aplicaciones. No veo malo el escribir otro Framework. Pero muchas veces solo terminan limitándose, haciendo lo fácil mas fácil y lo difícil casi imposible, poco flexibles. Se vuelven una carga que mantener. Algo con lo que los desarrolladores no están muy entusiasmados en trabajar, porque prefieren usar algo nuevo.
He notado que esos pequeños Frameworks tienen algunas características en común (esta no es una receta, solo son unos de los problemas comunes que he visto en esos pequeños frameworks privados):
No se conocen los frameworks existentes: Lo más seguro es que ya exista algo que hace lo que se quiere lograr. Puede que se trate de un problema resuelto. Quizás lo mejor sea contribuir a un proyecto open source existente, agregando las características que se necesitan. Si la idea es hacer lo mismo que ya hace otro Framework, debe haber una razón más fuerte que el solo no tomarse la molestia de aprender a trabajar con los existentes.
No tienen un proyecto real donde usarlo: Sin una aplicación real donde probar los conceptos es difícil que se le atine a lo que realmente se necesita en un proyecto real. Puede tomarse en cuenta la experiencia de proyectos anteriores. Aun así creo que uno de los riesgos que se corre al no tener un proyecto donde probarlo es agregar características que no se necesitan u omitir las necesarias.
No son de código abierto (Open Source): Varios de estos pequeños frameworks son para uso exclusivo de quien lo desarrollo y a veces no quieren mostrarle el código a nadie fuera de la empresa, como si alguien les fuera a robar la idea y teniendo el secreto ya nadie necesitaría (contrataría) del autor del framework. Cuando en realidad es todo lo contrario, Al liberar el código de la librería/framework ayuda a que el código tenga mas ojos; y mas ojos pueden ayudar a que el proyecto sea mejor. Además de que es una buena oportunidad de que el autor se de a conocer en la comunidad (publicidad) y que la comunidad se beneficie de esto, ambas partes ganan, pero sobre todo código.
No conocen la teoría: Conocer la teoría para que la practica tenga mas sentido. Cuando el proyecto tiene buenas bases teóricas logra ser mas consistente en la manera como esta desarrollado y tanto la mantenebilidad, como su extensibilidad generalmente logran ser mayor.
Quieren abarcar mucho: El no tener un objetivo claro o un problema concreto el cual se quiere resolver termina generando una gran cantidad de código que nadie quiere usar.
El desarrollo de un framework es una buena actividad para ser un mejor desarrollador, es algo que se debe intentar (más si es en un proyecto open source). La innovación puede ocurrir. Si conociendo las soluciones existentes se cree necesitar una opción mas, pues adelante.

viernes, febrero 11, 2011

Comunicación con messenger en la oficina

Ahora que volví a trabajar desde la oficina, con compañeros de trabajo (antes trabajaba desde mi casa) he notado que mucha de la comunicación entre los desarrolladores, incluso con la administración, se da a través del messenger e incluso por redes sociales como twitter y facebook (aunque por estas la comunicación es mas informal). Es algo que ya venia haciendo, pero pensé que era porque no estaba físicamente ahí con ellos.

Al principio no me gustaba tanto y prefería levantarme e ir al lugar de los demás. Empece a notar que era de los pocos que hacia eso y sentía que estaba distrayendo a la persona que con la estaba hablando y a los de su alrededor.

Ahora uso mas el messenger (mensajero en español) para hablar con mis compañeros (aunque estén a lado mio) y he notado que tiene algunos beneficios que explico a continuación.

Debido a que somos muchos personas trabajando en la oficina, es casi imposible que a todos nos guste la misma música; por eso el uso de audífonos es algo común. Esto hace que al escuchar música (con los audífonos) logres cierta concentración hacia la computadora. El problema con una interrupción en persona es que obliga a "desconectarse" para poder atenderla. En cambio si la interrupción es a través del mensajero; entonces se puede atrasar un poco, no "desconectarte" en ese momento y después atender el mensaje cuando se tenga oportunidad. Incluso aunque se atienda el mensaje de inmediato, el no tener que poner en pausa la música y quitarte los audífonos para responder, logra que se pierda menos la concentración de lo que se esta haciendo.

Esto me hace pensar que si toda la comunicación se da a través de medios electrónicos, entonces ¿por que no trabajamos todos desde nuestras casas? Con las herramientas actuales de comunicación fácil podríamos todos trabajar desde casa; pero el problema es que no todos pueden. Hay para quienes trabajar desde casa implica muchas distracciones en persona, o simplemente se distraen por otras cosas, etc.

Extraño los días en que todo el equipo trabajaba escuchando la misma música (o sin música), cuando no había necesidad de audífonos. Y hablábamos sin necesidad del mensajero, pero ahora veo las ventajas y me parece una buena idea, porque hay quienes en la oficina no lo usan para hablar entre ellos y distraen a los demás con sus discusiones técnicas.

jueves, febrero 03, 2011

Desarrollo Web Arrastrando y Soltando

Hace unos días necesitaba realizar una aplicación web en muy poco tiempo. Debía mostrar un demo en un día; así que decidí olvidarme de las buenas practicas por un día y (usando ASP.NET WebForms) empezar a arrastrar y soltar componentes a mi página. Diseñando las paginas de captura y lectura (Grids) sin ver el markup que VisualStudio me iba generando.

Tenia mucho tiempo sin trabajar en Design View, pero no tenia tiempo de ponerme a editar el markup a mano. Una vez creadas las páginas (a la drag and drop) usando el ratón empece a conectar mis GridViews y DropDownsLists usando LinqDataSources. Todo esto con la ayuda de wizards, en algunas consultas utilice views definidas en la base de datos (MS SQL Server) también con la ayuda de diseñadores, no use SQL para definir mis views. (Creo que tenia años sin usar Views y menos de usar el query designer).

No pudieron faltar los lugares donde necesite algo de código y para ello LinqToSql me ayudo a realizar las consultas y/o actualizaciones a la base de datos. Como no tenia mucho tiempo y el código era poco opté por escribirlo directamente en los event handlers (button_click, etc). Donde el código crecía un poco entonces sí agregaba una clase para no tener métodos muy largos.

Al final el demo se pudo terminar en un día y la aplicación estaba lista para usarse en un semana. El haber podido entregar una aplicación en una semana me ha hecho reconsiderar mi opinión sobre el desarrollo web hecho arrastrando y soltando.

Se que el problema vendrá con el mantenimiento. Precisamente esta es una de las razones por las que deje de hacer desarrollo arrastrando y soltando; Pero el poco código que escribí es facil de mantener (al menos así lo veo ahora) y si despues necesito algo mas complejo podria refactorizarlo y apoyarme en pruebas unitarias para eso.

No se... me puso a pensar que tal vez si hubiera seguido las buenas practicas (TDD) quizas no hubiera terminado a tiempo y por lo tanto el proyecto se hubiera perdido.

Con esto no quiero decir que de ahora en adelante puro drag en drop (veremos como nos va con las nuevas features). Solo quise compartir mi experiencia en un proyecto pequeño y rápido del cual me sentí bien del código entregado y del poco tiempo que nos tomo hacerlo (Aunque fuera a la Drag and Drop) .

viernes, enero 07, 2011

Editores para RubyOnRails en Windows

Al trabajar con RubyOnRails desde Windows he usado algunos editores y IDE's con sus ventajas y desventajas cada uno de ellos.

El primero que utilicé fue Notepad++, porque ya lo tenia instalado en el sistema. Me gustó por lo ligero y rápido que responde el editor, pero lo que me hizo buscar opciones es que no coloreaba muy bien todos los archivos con los que trabajaba. Ademas de que no cuenta con un explorador del proyecto. Hay complementos para para tener una lista de carpetas, pero ninguna me gustó del todo.

La segunda herramienta que usé fue NetBeans. Ya había trabajado con NetBeans antes (desarrollando en java) así que no me fue difícil conocer el IDE. Me gustó trabajar con el IDE ya que estoy acostumbrado a usar uno en mi trabajo (trabajo con .Net en C# desde Visual Studio). Pero seguí buscando alternativas, ya que NetBeans es algo pesado y al buscar información, sobre como realizar ciertas tareas en rails, siempre encontraba ejemplos con la consola y simples editores. Al hacerlos en netbeans sentía como que hacia "trampa".

Intenté aptana pero estaba lentísimo en mi maquina, así que lo des-instale luego luego.

Buscando algo parecido a TextMate encontré E-Editor que según dicen es algo así como el textmate para windows; pero es de pago y actualmente no cobro por desarrollar en ruby. Por lo que seguí buscando una opción gratis.

Así fue como encontré intype un editor muy sencillo y bonito que cuenta con un project view (que es simplemente una carpeta raíz en una vista de árbol, no tiene un archivo con la definición del proyecto). Lo estuve usando por algún tiempo junto con la consola de comandos; pero a ratos sentía que tenia que escribir mucho, no te auto-completa nada...entonces seguí buscando.

Encontré Komodo, un editor sencillo que si te auto-completa algunas cosas y ademas puedes definir tus propias plantillas, funciona bien. Sin embargo nunca me terminó de gustar. Tiene algunos detalles como no poder abrir un archivo rápidamente con solo teclear parte del nombre y otras cosillas que hacían que no me gustara del todo. Lo usaba junto con la consola de comandos.

Y así después de intentar con algunos editor regresé a NetBeans, donde todo esta integrado, No necesito la consola para usar los generadores básicos, ni para la mayoría de los comandos de rake, ni para iniciar el servidor Web. Es por eso que por ahora mi editor (IDE) para trabajar en ruby on rails en windows es netbeans.

Siento que me sirvió el estar usando editores sencillos y usar la consola. Para conocer (practicar) a bien los comandos. Pero una vez que los conozco me gusta lo rápido que los uso desde NetBeans...obviamente esta opinión puede cambiar de un momento a otro sin previo aviso.

Aun me falta por intentar Vim...