viernes, enero 27, 2012

Iniciando con jQuery

He estado pensando en escribir alguno que otro post sobre JavaScript. No digo que vaya a empezar una serie ni mucho menos (luego las dejo a medias) pero si escribir algunos post. Así que iniciamos por el principio. Lo básico de jQuery.

El ejemplo será una lista de comentarios a la cual le quisiéramos ir agregando elementos a la lista. Tenemos el siguiente HTML:

<html>
<head>
<title>Comentarios</title>
</head>
<body>
<ul id="comments">
<li>Comentario 1</li>
<li>Comentario 2</li>
</ul>
<input id="comment" type="text" />
<button id="add" >Agregar</button>
</body>
</html>

La intención es que cuando el usuario haga clic en el botón “Agregar” se agregue lo escrito en la caja de texto a la lista de comentarios.


Lo primero que debemos hacer es agregar la referencia al código de jQuery. Podemos usar una copia local o hacer uso de alguna red de distribución de contenidos (CDN).


<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>

con esto ya podemos hacer uso de jQuery. Así que agregamos un bloque de script a nuestra página para agregar la funcionalidad que requerimos.


<script>
$(function () {
$("#add").click(function () {
var newCommentTextBox = $("#comment");
var commentText = newCommentTextBox.val();
$("#comments").append("<li>" + commentText + "</li>");
newCommentTextBox.val('');
});
});
</script>

Lo primero que hacemos es pasar como parámetro a la función “$” de jQuery una función que queremos que se ejecute al cargarse la página. Dentro de esta función tenemos la línea $(“#add”).click(function () { que lo que hace es primero buscar al elemento con id=“add”  (en este caso el botón) después llamar el método click y pasarle la función que queremos ejecutar cuando se haga un clic en el elemento.


Dentro de la función buscamos el elemento id=“comment” (que es la caja de texto) y obtenemos su contenido con la función val(). Después agregamos un elemento más a la lista de comentarios (id="comments") con el texto que obtuvimos de la caja de texto. Por último limpiamos la caja de texto con newCommentTextBox.val('');.


Espero que este post sirva para que quienes aun no se animan a entrarle a JavaScript vean lo fácil que es, empiecen a perderle el miedo y aprovechen las ventajas que tiene.

martes, enero 24, 2012

Probando sin mocking framework

Al estar trabajando en un proyecto sobre ASP.NET MVC pequeño. Pensé que sería mas fácil animar a escribir pruebas, a personas que no están acostumbradas, si al escribirlas no necesitaran usar librerías externas. Como son los mocking frameworks y las librerías para las aserciones. Así que decidí escribir las pruebas unitarias usando solo las herramientas que me brinda Visual Studio. Eso significa usar msTest y escribir implementaciones falsas de las dependencias de los sistemas bajo prueba.

Llegué a pensar que eso significaría escribir mucho más código ya que tendría que proporcionar varías implementaciones que un mocking framework me ahorraría. Sin embargo he notado que la cantidad de código no es mucho más. Ya que con las mocking frameworks necesitaba hacer más setups dentro del test. Es claro que tiene sus ventajas y desventajas.

Noté que para un programador, que no esta acostumbrado a escribir pruebas unitarias, es fácil entender qué es lo que pasa cuando usamos una implementación falsa donde puede ver el código. A la vez es fácil que escriba sus implementaciones que solo le sirven para pruebas. En ocasiones cuando trataba de explicar TDD (a gente que no esta acostumbrada) usando un mocking framework, u otra librería, notaba que varios se perdían un poco tratando de entender el código de setups de moq o de NSubstitute. Con implementaciones falsas escritas por ellos mismos (o que pueden ver lo que pasa) es más fácil concentrarse en (y encontrarle más sentido a) la prueba.

El método de prueba puede centrarse en los efectos secundarios del sistema bajo prueba, en lugar de la implementación. Es decir no pruebas que realice llamadas a ciertos métodos de las dependencias sino que tenga los efectos secundarios que se espera.

Una de las desventajas es que se necesita escribir la implementación falsa para que la prueba pueda correr y eso hace que pierda un poco el flujo de lo que se esta probando. Al tener que abrir otro archivo y escribir algo de código. Además que terminas con más código que mantener.

Otra es que a pesar de tener una implementación falsa que se puede compartir. De cualquier forma se necesita algo de código en la prueba para cumplir con las precondiciones que la prueba requiere y terminas con la implementación falsa además de código de setup. Otra vez más código que quizás el mocking framework me hubiera ahorrado.

viernes, enero 13, 2012

¿Seguir usando Delphi?

Aun mantengo y agrego nueva funcionalidad a una aplicación que desarrollé hace algunos años usando Delphi. Específicamente con Turbo Delphi, basado en la versión 2006 del entonces conocido como Borland Developer Studio. En realidad no se trata de una sola aplicación sino de una familia de aplicaciones para la administración de un negocio de venta al menudeo y medio mayoreo.

producto

Sigo agregando nuevas características, conforme las necesidades de la empresa, lo cual no es muy seguido. Cada vez que tengo que agregar alguna funcionalidad me pregunto ¿Debería migrar el código fuente a alguna otra tecnología?

¿Por qué cambiar?

Bueno si funciona ¿Para que cambiar? es la otra pregunta que me hago inmediatamente después de pensar en migrar. Las razones son:

  1. Mi forma personal de programar ha cambiado: al usar Delphi debo regresar a usar objetos como datasets, escribir SQL a mano (Sin ORM’s), mucho arrastrar y soltar para después modificar propiedades en el object inspector. Cuando lo que quisiera hacer es utilizar características de lenguajes y frameworks nuevos.
  2. Documentación: Ya que no es una tecnología que use todos los días, cada vez que regreso a algún proyecto y necesito agregar algo de código o modificar alguna propiedad necesito buscar documentación para saber cual es la manera Delphi de hacerlo. No quiero escribir mucho código para algo que con cambiar alguna propiedad o arrastrar un componente hubiera bastado. No es mucha la documentación que se encuentra y la mayoría de esta es vieja o trata las nuevas características que aun salen para Delphi.
  3. Precio: Otra razón para no migrar a una versión más reciente de Delphi (ahora parte de Embarcadero) es el precio de la licencia. Es más cara que una licencia de VisualStudio y siento que con VS puedo hacer más cosas que solo escribir aplicaciones de escritorio. Además de que las puedo desarrollar de una manera “moderna”.
  4. La tecnología puede llegar a ser obsoleta: Al seguir desarrollando en la versión actual corro el riesgo de no encontrar soporte, alguien que pueda ayudarme, cuando necesite realizar algo que no este soportado en la tecnología actual. Como puede ser la integración con sistemas más “modernos”.

¿Por qué seguir en Delphi?

Aun con las desventajas que tiene el mantener la aplicación en una tecnología “vieja” creo que tiene ciertas ventajas mantener el código donde esta:

  1. La aplicación funciona:Esta es la principal razón por la que sigo usando Delphi para esos proyectos. Aun no se ha presentado problemas graves por estar usando esa tecnología.
  2. Tiempo de desarrollo: Es más rápido agregar características a las aplicaciones usando la tecnología actual que reescribir todo en alguna tecnología “nueva”. Además el código no esta mal/feo es relativamente fácil de seguir o de modificar para después agregar nueva funcionalidad.
  3. Costo-Beneficio: Al final todo se reduce al costo beneficio. No estoy convencido que el costo que implica reescribir toda (o gran parte) de la aplicación tenga un beneficio que valga la pena el gasto. Si bien es posible que en un futuro sea más fácil seguir usando una tecnología moderna; por el momento no ha causado un problema seguir desarrollando en Delphi. Solo alguno que otro enojo (como programador) por no poder usar lambdas o cosas así.

Conclusión

Al no poder justificar completamente el gasto creo que seguiré desarrollando (por el momento) las aplicaciones principales en Delphi mientras me sea posible. Quizás haga proyectos pequeños, relacionados, usando alguna otra tecnología (como .Net) para ir migrando poco a poco. Pero sin descuidar que el desarrollo principal en estos proyectos es en Delphi. Aun sigo considerando también comprar la versión más reciente de Delphi aunque es lo menos probable.

viernes, enero 06, 2012

Programando en laptop

Llevo varios días trabajando exclusivamente desde la laptop, sin teclado ni monitor externo. Esto es principalmente porque el monitor externo ha estado fallando últimamente y porque he estado trabajando desde varios lugares de la casa.

Me ha gustado la experiencia de usar solo la laptop, lo limpio que se ve el escritorio sin los cables del monitor. Es fácil cerrar la laptop y moverme al sofá o incluso a la cocina. Además de que me estoy acostumbrando a trabajar con las limitaciones del teclado/mouse pero estoy aprovechando las ventajas de no tener que cargar con más equipo y poder trabajar desde donde sea. Ahora tecleo más lento pero no he visto que afecte el trabajo del día [soy desarrollador, no secretaria ;-)].

Algunos aspectos que he empezado a considerar tratando de decidir si debo comprar otro monitor o seguir trabajando solo con la laptop son:

Movilidad: Trabajando solo usando la laptop me permite trabajar desde cualquier parte (cualquier habitación de la casa, oficina, en una cafetería, etc.). Al trabajar con un monitor, teclado, mouse externo necesito conectar/desconectar cada que quiero moverme de lugar.

Comodidad: Es más cómodo trabajar con 2 monitores (sobre todo porque el monitor externo es grande) , con mouse y teclado externo. Sin embargo también es cómodo poder trabajar desde cualquier parte. Llegué a pensar que solo es cuestión de acostumbrarme; pero cuando trabajo varios días solo con la laptop aparece un dolor detrás del cuello que es muy molesto. Aunque supongo que hay maneras de evitarlo.

Económico: Es más barato no comprar monitor externo y trabajar directamente desde la laptop. También he considerado comprar una computadora de escritorio para trabajar en la oficina/casa y dejar la laptop para cosas personales o cuando requiera moverme, aunque para ese caso me sale más barato solo comprar el monitor externo y no toda la computadora.

Aun no he decidido que haré…

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.