lunes, diciembre 31, 2012

El 2012

Como ya va terminar el año, en lugar de escribir predicciones preferí hacer un resumen de las actividades y eventos en los que participé en este 2012.

Super Happy Dev House Tijuana
En Marzo participé en la organización del séptimo SHDH-TJ. Hubo buena asistencia, podríamos decir que el evento fue un éxito.

391405_2751239074705_1207758899_n539440_2751238554692_1571180181_n545711_2751239914726_1403608_n

Hubo varios proyectos usando diferentes tecnologías; pero con algo en común. La mayoría (si no es que todos) eran Web así que tiempo después surgió tijuana.js

tijuana.js
En Abril publiqué el sitio tijuanajs.org. El grupo de usuario de javascript de Tijuana tuvo su primera reunión el último martes de Mayo y así cada ultimo martes de mes hasta Octubre, fueron 6 reuniones en este primer año. Esperamos seguir reuniéndonos en el 2013.

WP_000151WP_000288WP_000441

Tijuana.net
Participé como expositor en reuniones de la comunidad .net de Tijuana:

dev3cast
Fue un año más en que participé, junto con Gabriel Flores e invitados, en el dev3cast podcast. Los temas tratados en el 2012 fueron:

CafeScript
Como puede verse, en los primeros episodios del año del dev3cast, hubo varios relacionados con JavaScript. De ahí surgió la idea de crear un podcast dedicado a JavaScript. Se unió Iván González al proyecto y así inicio CafeScript. Los episodios del año fueron:

Google Developers Group (GDG) Tijuana
Fui invitado a participar con el GDG como expositor del tema “Extensiones para Google Chrome”. Fue agradable participar en otras comunidades.

WP_000290

Universidad
El 2012 fue el año en que regresé a la Universidad; pero esta vez no como alumno sino como profesor. Impartiendo 2 Materias (Programación Visual y Desarrollo Web). Me gustó la experiencia, tanto que el siguiente cuatrimestre impartiré una materia más.

Vista4ojos
Por último, ya para terminar el año mi vista se canso. Al parecer el pasar mucho tiempo con la vista fija en la laptop (trabajo, proyectos extras, blogs, etc.) fue la causa de que tuviera problemas con uno de mis ojos. Eso provocó que me convirtiera en un “programador 4 ojos”.

Estas fueron algunas de las actividades en las que participé este 2012.

lunes, noviembre 05, 2012

Convenciones de nombrado

¿Qué son?
Las convenciones de nombrado son un conjunto de reglas para nombrar identificadores (nombres de variables, clases, propiedades, funciones, etcétera) dentro de un lenguaje de programación. No son requeridas por el compilador o interprete para que el programa funcione, son un estilo en la forma de escribir el programa.

¿Por qué utilizar convenciones de nombrado? ¿Cuáles son las ventajas?
El utilizar una convención de nombrado dará al código un estilo consistente que ayuda a la lectura para el resto del equipo o incluso para el mismo desarrollador que lo escribió. Es fácil saber que esta pasando con sólo ver el estilo utilizado. Similar a como ocurre al leer un libro.  Algunos autores usan diferentes formatos a lo largo de los libros (itálica para ciertas partes del texto, recuadros con otro tipo de letra, etcétera) estos sirven para que el lector tenga un mejor contexto de lo que esta leyendo.

Denota cierta intención. Si la notación es consistente, a lo largo del programa, con sólo leer un fragmento del código podemos descubrir lo que se intenta (y como) lograr. El no seguir una convención puede requerir que el lector tenga que leer más del código para poder entender mejor el contexto y el objetivo de cada variable o procedimiento.

Muestra que él código fue escrito por un profesional, esto pareciera no ser importante; pero al momento de tener que mantener código de otras personas (o de uno mismo) es más agradable trabajar con código escrito de manera profesional.

¿Cuáles serían las desventajas?
La mayoría de las desventajas aparecen cuando se sigue una convención equivocada o "anticuada", sí, me refiero a la notación húngara.

¿Por qué no me gusta la notación húngara?
La Notación Húngara consiste en usar prefijos en el nombre de las variables, dependiendo del tipo. Esta notación la utilizaba en la escuela y en los primeros proyectos en los que participé saliendo de ella. Era común en lenguajes como Delphi y VisualBasic al momento de nombrar los componentes (controles) utilizados.

Algo que noté como desventaja era que tenía que recordar cual era el prefijo para la variable que iba a declarar. Por ejemplo, actualmente si voy a definir un botón para guardar cambios puedo llamarlo saveButton, con lo cual es claro ver que se trata de un botón para guardar; Pero con la notación húngara tenía que recordar cual era ese prefijo para los botones antes de poder nombrar mi variable btnSave. Esto se complicaba más entre menos común fuera el control a utilizar. Había ocasiones que perdía tiempo definiendo prefijos y después buscándolos para poder así nombrar variables y el código fuera consistente.

En otras ocasiones son totalmente innecesarios los prefijos y sólo sirven para meter ruido y hacer más difícil la lectura del código. Tomemos como ejemplo  el siguiente calculo:

Sin notación húngara
    item.amount =  unitPrice * quantity;

Con notación húngara
    oItem.fAmount = fUnitPrice * iQuantity;

En una sola línea de código se ve que tenemos ruido innecesario, en programas algo grandes el ruido que introducen los prefijos llega a ser muy molesto.
Las convenciones varían según el lenguaje
Es importante conocer la convención de nombrado utilizada (recomendada) para el lenguaje que estamos utilizando, estas varían de leguaje a lenguaje. Aun y que estemos usando varios lenguajes en un mismo proyecto las convenciones pueden (y deben) cambiar según el lenguaje en uso.

Por mi trabajo es común ver JavaScript, HTML, CSS (incluso SQL) escrito siguiendo convenciones de C# lo cual no creo que sea correcto (sin tomar en cuenta lo mucho que me molesta). En esos casos se esta desaprovechando las ventajas de usar una convención, se hace más complejo leer la intención del código.

Al final de lo que se trata es de poner atención en que el código sea fácil de leer y entender. Para esto debe ser escrito de una manera profesional, siguiendo las convenciones comunes para el lenguaje. Cuando el código no sigue la convención del lenguaje  es fácil dudar de la experiencia (profesionalismo) que tenía el desarrollador  en ese lenguaje en particular (al momento de escribirlo), por lo tanto se  tendría que revisar más código para saber si el código hace lo que suponemos y que  además que lo haga de la mejor manera.

viernes, junio 22, 2012

MagmaRails 2012

WP_000230Hace poco asistimos a magmarails. Este es el segundo año consecutivo que vamos, aunque el año pasado se suspendió el evento de 3 días que se tenia programado aun así se llevo a cabo un día de presentaciones con un ambiente muy bueno que decidimos volver este año. Además de que había la posibilidad de ganarnos un ipad por haber asistido en el 2011, este no fue un factor para decidirnos hacer el viaje; pero al final sí costeó.

Aunque no trabajamos con RubyOnRails, en nuestro trabajo actual, de cualquier forma me parece una buena conferencia para asistir y aquí algunas de las razones:

Presentaciones sobre personas, presentaciones no técnicas. Varias de las presentaciones hablaban de conceptos que se pueden aplicar a cualquier lenguaje y plataforma. Algunas hablaban de temas tales como el lugar de trabajo, la organización del equipo, como ser un mejor desarrollador, etc. Muchas de estas presentaciones hechas por personas que trabajan en empresas exitosas y con buen ambiente de trabajo.

Practicas aplicables a cualquier Framework/Lenguaje. Las presentaciones que fueron técnicas hablaban de practicas que son aplicables a la mayoría de las plataformas para realizar desarrollo web, cosas como DDD, diseño de APIs, FrontEnd, Backbone.js entre otras.

Todos podemos aprender de Ruby y RubyOnRails. Las presentaciones que si fueron más enfocadas a RubyOnRails fueron interesantes aunque no trabajemos con él. Considero que como desarrollador profesional debemos saber cuales son las opciones que tenemos para desarrollar. Quizás no ha detalle; pero sí de tal manera que cuando se presente un problema recordemos esa opción y entonces sí ver los detalles. Además de que en lo personal me parece muy interesante lo que pasa en el mundo de Ruby.WP_000238

Amigos. En nuestra primera visitas hicimos buenos amigos allá en colima y esta era una buena oportunidad para ir a visitarlos otra vez (gracias Mario y Nizait por tratarnos tan bien, nos hicieron sentir como en casa).

Vacaciones. La conferencia fue en manzanillo así que aprovechamos para tener unas vacaciones algo geek.

Crowd Interactive. La conferencia no es organizada por una empresa que quiere venderte sus productos y/o herramientas de desarrollo. Es organizada por una empresa de desarrollo que esta interesada en formar comunidades de desarrolladores. Busca que se generé talento nacional. Creo que eso es algo que ayuda a que el ambiente sea muy agradable. En ningún momento sientes que te están vendiendo algo, solo esperan que te la pases muy bien, convivas con otros desarrolladores y que formes parte de la comunidad.WP_000225

“Celebridades”. Otro de los atractivos de la conferencia es que asisten personas reconocidas, por su trabajo, dentro de la comunidad. Esta es una oportunidad para poder hablar con ellos en persona, hacer preguntas, convivir y aprender de lo que hacen. Te das cuenta que son personas accesibles y que están dispuesta a ayudarte.

viernes, abril 27, 2012

Introducción a jQuery (Parte 12)

En esta ocasión no grabe un screencast, ya que solo voy a reacomodar código en base a lo explicado en los pasados posts. Creo que será más fácil apreciar esos cambios si lo muestro como estaba el código y como fue cambiando. Así pueden ver los detalles sin tener que esperar a que lo escriba.

En la parte 11 de la serie el archivo tasks.js iba de la siguiente forma:

$( function () {
$( 'input[type="checkbox"]' ).click( function ( event ) {
$( this ).parent().toggleClass( "done", this.checked );
event.stopPropagation();
} );

// $( "li" ).click( function () {
// $( this ).toggleClass( "highlight" );
// } );

$( "ol" ).on( "click", "li", function () {
$( this ).toggleClass( "highlight" );
} );

$( "a.delete" ).click( function ( event ) {
if ( confirm( '¿Borrar la tarea?' ) ) {
$li = $( this ).parent();
$li.slideUp( function () { $li.remove(); } );
}
event.stopPropagation();
} );

$( "button#add" ).click( function () {
var $input = $( "input#task" );
var value = $input.val();

var $ol = $( "ol" );

var templateHtml = $( "div.template" ).html();

$ol.append( templateHtml.replace( "{{task}}", value ) );
} );

} );


Expliqué el uso de “on” en lugar de usar “click” directamente en los eventos, así que lo primero que haré es cambiar los “clicks” por “on” y borrar los comentarios del código.



$( function () {
$( "ol" ).on( "click", 'input[type="checkbox"]' , function ( event ) {
$( this ).parent().toggleClass( "done", this.checked );
event.stopPropagation();
} );

$( "ol" ).on( "click", "li", function () {
$( this ).toggleClass( "highlight" );
} );

$( "ol" ).on( "click", "a.delete", function ( event ) {
if ( confirm( '¿Borrar la tarea?' ) ) {
$li = $( this ).parent();
$li.slideUp( function () { $li.remove(); } );
}
event.stopPropagation();
} );

$( "button#add" ).click( function () {
var $input = $( "input#task" );
var value = $input.val();
var $ol = $( "ol" );
var templateHtml = $( "div.template" ).html();
$ol.append( templateHtml.replace( "{{task}}", value ) );
} );

} );


Aquí se puede ver que se esta usando varias veces el selector $( “ol” ) lo cual puede guardarse en una variable y no tener que hacer la consulta al DOM cada vez que lo necesitamos.



$( function () {
var $ol = $( "ol" );

$ol.on( "click", 'input[type="checkbox"]' , function ( event ) {
$( this ).parent().toggleClass( "done", this.checked );
event.stopPropagation();
} );

$ol.on( "click", "li", function () {
$( this ).toggleClass( "highlight" );
} );

$ol.on( "click", "a.delete", function ( event ) {
if ( confirm( '¿Borrar la tarea?' ) ) {
$li = $( this ).parent();
$li.slideUp( function () { $li.remove(); } );
}
event.stopPropagation();
} );

$( "button#add" ).click( function () {
var $input = $( "input#task" );
var value = $input.val();
var templateHtml = $( "div.template" ).html();
$ol.append( templateHtml.replace( "{{task}}", value ) );
} );
} );


Por último voy a dejar de usar funciones anónimas y especificar el ligado de los eventos en un solo lugar. Además guardo en una variable la caja de texto para agregar tareas y así no tener que buscarla cada que se necesite agregar una tarea:



$( function () {
var $ol = $( "ol" ),
$newTask = $( "input#task" );

function checkbox_click ( event ) {
$( this ).parent().toggleClass( "done", this.checked );
event.stopPropagation();
}

function hightlight() {
$( this ).toggleClass( "highlight" );
}

function deleteItem( event ) {
if ( confirm( '¿Borrar la tarea?' ) ) {
$li = $( this ).parent();
$li.slideUp( function () { $li.remove(); } );
}
event.stopPropagation();
}

function addItem () {
var templateHtml = $( "div.template" ).html();
$ol.append( templateHtml.replace( "{{task}}", $newTask.val() ) );
}

$ol.on( "click", 'input[type="checkbox"]', checkbox_click );
$ol.on( "click", "li", hightlight);
$ol.on( "click", "a.delete", deleteItem);
$( "button#add" ).click( addItem );
} );


Con esto, en mi opinión, el código se ve más claro.



Links Relacionados:

Introducción a jQuery (Parte 11)



Mario H. Cornejo

lunes, abril 23, 2012

Introducción a jQuery (Parte 11)

Esta vez hago uso de una plantilla para agregar nuevas tareas a la lista y empiezo a utilizar el método “on” para ligar eventos.

Links Relacionados:
Introducción a jQuery (parte 10)
Introducción a jQuery (parte 12)

Iniciando tijuana.js

Recientemente el uso de JavaScript ha cobrado importancia al momento de realizar casi cualquier aplicación web. Ahora hay muchas librerías y/o Frameworks desarrollados en JavaScript y empieza a no ser extraño usarlo fuera del browser.

En el pasado Super Happy Dev House Tijuana se reunieron varios desarrolladores a trabajar en diversos proyectos. Cada uno de estos proyectos estaban desarrollados en diferentes lenguajes/Frameworks (tales como RubyOnRails, PHP, ASP.NET, etcétera). Se contó con la asistencia de varias de las comunidades de la región, como la comunidad de Ruby Tijuana, Tijuana .Net, Grupo de usuarios GNU/Linux, Comunidad de PHPeros en Tijuana y Google Developer Group.

WP_000405WP_000407WP_000408

A pesar de ser desarrolladores de diversas tecnologías algo que tienen estas comunidades en común es JavaScript. De ahí la idea de iniciar un grupo donde podemos reunirnos para hablar de lo que todos los desarrolladores web tenemos en común y que cada vez tiene mayor impacto en el desarrollo de las aplicaciones.

He publicado el sitio tijuanajs.org donde espero sea un punto de encuentro para todas aquellas personas, de la región, que les guste hablar de JavaScript.

Ingresen al grupo y espero verlos en las reuniones.

Mario H. Cornejo

lunes, marzo 26, 2012

Introducción a jQuery (Parte 0)

En la pasada reunión de la comunidad .Net Tijuana presenté el tema de jQuery, Mostré que es y como usar lo básico de esta librería, aunque faltó tiempo para presentar todo el temario que había preparado. Se grabó la presentación pero al final de la misma nos dimos cuenta que el audio no se grabó así que decidí grabar una serie de screencasts donde muestro el uso de jQuery al realizar una aplicación de ejemplo. Los videos son de 5 minutos o menos. Espero los disfruten.

Links Relacionados:
Introducción a jQuery (Parte 1)

lunes, febrero 06, 2012

Iniciando con QUnit

Hace poco escribí un post sobre como iniciar con jQuery. En esta ocasión quiero mostrar como hacer el mismo ejemplo; pero escribiendo las pruebas unitarias primero (a la TDD) utilizando QUnit.

Lo primero que debo hacer es crear un archivo HTML con la plantilla que esta en el sitio de QUnit con unos cuantos cambios…. cambié la ubicación de la hoja de estilos,  agregue las ubicaciones de los scripts de jQuery, QUnit y agregué un div con id “main” que es donde escribiré el HTML necesario para las pruebas. El archivo me quedo así:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>QUnit Tests</title>
<link rel="stylesheet" href="http://code.jquery.com/qunit/qunit-git.css" >
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
<script src="http://code.jquery.com/qunit/qunit-git.js"></script>
</head>
<body>
<h1 id="qunit-header">QUnit Hello World</h1>
<h2 id="qunit-banner"></h2>
<ol id="qunit-tests"></ol>
<div id="main"></div>
<script>
test("hello", function() {
ok(true, "world");
});
</script>
</body>
</html>


En esta plantilla viene escrito una prueba de ejemplo llamada “hello”. Voy a modificar esa función para especificar lo que quiero probar. Para escribir la prueba voy a aplicar el estilo AAA (Arrange, Act, Assert). Primero (Arrange) especifico las precondiciones para que pueda correr la prueba, en este caso sería escribir el HTML necesario y ligar el evento clic del botón a mi función. En la segunda parte (Act) escribo el nuevo comentario en la caja de texto y disparo el evento en el botón. En la tercera parte (Assert) verifico que se haya agregado un comentario, es decir que la lista tenga un elemento con el contenido esperado. La prueba queda de la siguiente manera:



test("when click 'add' then a comment should be added to the list", function(){

//Arrange - Agrego el HTML necesario y ligo el evento click del botón
$("#main").append('<ul id="comments"></ul>'
+ '<input id="comment" type="text" />'
+ '<button id="add">Add</button>');
$("#add").click(addComment);

//Act – Escribo el nuevo comentario y hago clic en el botón
$("#comment").val("comment");
$("#add").click();

//Assert – Verifico que el nuevo comentario este en la lista
equals($("#comments").html(), "<li>comment</li>");

});


Una vez que tenemos la prueba, lo que sigue es correrla y verificar que falle para después escribir el código necesario para hacerla pasar. Para correr la prueba lo único que necesito es guardar el archivo (en este caso lo llamé test.html) y abrirlo con un navegador. Al abrir el archivo en el navegador este me muestra el error.



error1



El error dice que no se encontró la función “addComment” que es la función que se va a ejecutar cuando se haga clic en el botón. Para definir mi función voy a crear un nuevo archivo al cual llamaré comments.js y agregar la referencia a el desde el archivo test.html. En este archivo (comments.js) es donde definiré la función addComment (por ahora haré la función global espero después escribir sobre como simular namespaces y definir funciones “privadas” en JavaScript). A continuación muestro el contenido de mi archivo comments.js



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


Como puede verse es lo mismo que en el post anterior solo que ahora esta en su propio archivo js. Agrego la referencia en el archivo test.html



<script src="comments.js"></script>

y vuelvo a correr las pruebas (actualizando la página en el navegador). Veo que la prueba pasa. pass

Ahora puedo tener confianza para hacer modificaciones sin preocuparme de que eche a perder funcionalidad. Además de que el código JavaScript quedó en su propio archivo (comments.js) separado del HTML.

jueves, febrero 02, 2012

Dev3Cast sobre NancyFx

El pasado 16 de enero Gabriel Flores y yo platicamos con Miguel Ángel Jiménez sobre el web framework Nancy. Miguel nos platicó de que se trata y a grandes rasgos como es que se usa. Además hablamos un poco sobre el open source en la plataforma .Net

Pueden escuchar la platica y unirse a ella comentando en el post del dev3cast

Dev3Cast sobre MongoDB y Redis

El pasado 2 de diciembre se publicó un episodio del dev3cast podcast donde participé junto con Eber, Samuel y Gabriel. En esta ocasión hablamos sobre MongoDB, redis y como usar en proyectos de software estas tecnologías NoSQL.

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é…