sábado, 30 de agosto de 2014

Mi aplicación

Casi todos (los programadores, obvio) tenemos “mi aplicación”. Ésa que, cuando haya tiempo, vamos a hacer “como se debe”.

El “como se debe” varía con cada uno, pero me arriesgo a generalizar: no es una afirmación positiva sobre ciertas herramientas y prácticas, es más bien una negación de aquellas que venimos utilizando, utilizamos o nos obligaron a utilizar, o de las que escuchamos hablar mal por ahí o… un largo etcétera.

En criollo: “mi aplicación” no va a ser como éste proyecto-huérfano-engendro-mutante del que me contaron, caí o armé (“por culpa de…”, seguro).

¿Cómo es “mi aplicación”? La mía de mi propiedad, al día de hoy, es:

-Una aplicación web hosteada en google.

-Server side: en java, pero va a devolver exclusivamente JSON. Pura data. Lo juro.

-Con alguna base de datos no relacional, porque son re-cool.

-Bootstrap.

-Pero no pienso escribir una sola regla de css. Lo juro.

-Ni tampoco mucha imagen ni iconito. Si puedo quedarme sólo con lo de bootstrap, mejor.

-Ni meterle 10.000 plugins (aunque ya empecé… pero lo voy a deshacer, y cuando lo deshaga lo juro).

-Jquery

-Jquery validation, si hace falta (imagino que sí).

-Knockout.

-Require.

-Y visjs, porque necesito algo así.

-Y NADA más.

El problema es… el de más arriba: que es cuasi-simétricamente-opuesto a todo lo que alguna vez hice: no soy diseñador ni mucho menos (estoy aprendiendo que entre “seguir la onda”, y “diseñar” hay un abismo insondable). Nunca programé en java (profesionalmente, proyectitos de prueba hicimos todos). Nunca usé bootrstrap. De íconos y gráfica o imágenes… sólo sé buscar en google, y al photoshop no me lo presentaron (ni siquiera sé usar bien el paint.Net). Visjs es genial, pero todavía estoy leyendo la documentación. Los únicos viejos conocidos son Knockout, require, jquery y compañía. Pero son herramientas, no una forma de trabajar con la que uno viene acostumbrado, y en la que “el camino para hacer tal cosa” aparece casi naturalmente.

Como todo primer intento, es… bueno, como se imaginan que es. Pero hay que seguir haciendo y rehaciendo hasta que salga. Mentalmente, claro, porque en la real realidad, uno va dedicándole horas a cuentagotas entre proyectos más rentables, con la esperanza de que en algún momento éste también lo sea.

Si bien “construir éste sistema lo antes posible” es la madre de todas las cag…, también es la madre de todas las cosas que están ahí afuera en este preciso momento, satisfaciendo necesidades de éste preciso momento, probablemente tan efímeras como la combinación de herramientas que (ahora) “me gusta”.

“Como a mí me gusta” va variando a medida que avanzamos. A veces más, a veces menos, pero siempre, con cada paso hacia adelante, surge el imperioso impulso de pasarle la guadaña a (casi) todo lo que se deja atrás… y uno va y lo hace. Porque ésta es “como a mí me gusta”. Es inevitable: la motivación parte de “armar un proyecto como a mí me gusta”, y no “construir éste sistema lo antes posible”.

Pero bueno, juntar dos o veinte librerías, copypastear un poco de código y salir con algo rápido a ver si pega es, probablemente, eficaz. O por lo menos un fracaso rápido y a otra cosa… pero no es lo que tengo ganas de hacer ahora.

Tengo ganas de seguir jugando.

Y a todo esto… ¿qué hace, exactamente, “mi aplicación”?

Por ahora, nada.

¿Qué debería hacer?

No está muy claro, ya veremos. Lo importante es que “esté como a mí me gusta”.

¿Verá la luz del sol?

lunes, 2 de junio de 2014

4096

A small victory.

4096

buscando en google veo unos screenshots que llegan hasta 65536… ¿fakes? Si sigo así, en un par de meses les confirmo.

jueves, 15 de mayo de 2014

Jetas*

En mis tiempos, cuando se quería hacer alguna gráfica (folleto, página web, calcomanía, papel higiénico, mouse pads servilleta o lo que sea) se tiraban un par de print screens de las pantallas más “bonitas” (o se inventaba alguna si es que no había), un poco de bla bla bla “mejorará su vida” y listo.

Ahora la onda es poner la jeta* de algún CEO presentable (pocos consiguen), o  empleado, o modelito o pobre flaco que iba corriendo una maratón con cara de langa (no, no vi que lo hayan usado, pero podría ser) y nada más. De qué hace el sistema, ni una palabra (o bien abajo), no sea cosa que alguien reclame la letra chica. Si es mujer, morocho, latino, indio, oriental o miembro de alguna “minoría con onda en USA”, mejor, y si es de varias al mismo tiempo (una mujer negra de ojos rasgados vestida de Pancho Villa), mejor que mejor.

O gente laburando en unas oficinas con toda la onda, limpias y llenas de luz, muy prolijamente desordenadas, súper informal. Vaya uno a saber ande se trabaja así, tal vez en algún lugar (hay uno de casi todo), pero me juego que no es la regla (al menos no para los que tocan el teclado).

O un tipo más o menos joven haciendo garabatos en un pizarrón, y todos alrededor con cara de “estoy aportando ideas”… y siempre alguna mina hay, por eso de las minorías que mencionaba antes. A veces hasta eligen uno o dos medio feos (medio al fondo, a un costado o fuera de foco), para darle realismo. Pero todos tienen los dientes blanquísimos, eso sí (debe ser por los tubos de luz), y nadie con los ojos rojos ni las ojeras negras ni la barba crecida ni la mandíbula colgando en un bostezo interminable.

Debe ser para mostrarle al mundo que el desarrollo de software, especialmente el de line-of-business, es producto del trabajo de personas comunes y silvestres y extremadamente cool (a este ventiañero lo vendemos por genio). Trabajo en equipo (lo vendemos diez veces) que demanda un ambiente acorde (total lo encadenamos al teclado hasta que le salga algo), re-creativo (con una play se queda contento), pero de mucha responsabilidad (y si no es la play están los palos, y de última de acá no te vas) y, sobre todo, esfuerzo (te va a costar un ojo de la cara), un gran esfuerzo sostenido en el tiempo (lo vas a tener para el día en que te mueras)… un trabajo casi artístico (así que si sale cualquiera no es culpa nuestra, el arte es así… indomable).

Será para hacer el software más humano, digo yo.

* jeta = cara, rostro (soy re-internacional).

martes, 13 de mayo de 2014

Prefiero el picado fino.

Creo (comienzo que permite divagar sin molestarse en verificar ni pensar dos veces) que esta preferencia es impronta de los últimos años de trabajo “Senior” (comillas obligatorias) en equipos más o menos medianos, más o menos “rotativos”. Picaba funcionalidad, sí, pero la mayor parte del tiempo tenía que buscar bugs en, verificar o consultar código de otros, en funcionalidad de la que no tenía más que una (valga la redundancia) vaga idea funcional. Entiéndase “no tenía mucha idea de cómo estaba programada o siquiera pensada”.

Entonces abría una carpeta (y a veces otra y otra y otra) y por los nombres me iba dando cuenta de cómo venía la mano. Me es cómodo encontrar una lista de archivos con nombres de clase más o menos coherentes, sintiéndome seguro de que no hay más que eso, simplemente porque “un namespace por carpeta, una clase por archivo”.

Ése es el picado fino. ¿Se entiende? Si no, querido lector, mejor siga su camino por otros callejones de la web, que acá ya no se le explica nada a nadie.

A veces hay un archivo con un enum y nada más. A veces una clase enorme con otras privadas y públicas y enums e interfaces y demás, adentro unas de otras, como muñecas rusas… pero en definitiva siempre una y sólo una clase en el archivo (amén). Se supone, al fin y al cabo, que cualquier otra cosa interna hace al detalle de lo que la contenedora dice (en su nombre) que hace.

A otros no. A otros les gusta el picado grueso. Un par de carpetas, las mínimas necesarias para leer el contenido con comodidad, arregladas en una jerarquía más bien plana y a otra cosa mariposa. Los nombres de los archivos se refieren no a clases sino más bien a… bueno, nunca encontré/entendí si había una regla, supongo que obedecen al (o son la medida del) sentido común de quien los crea.

Éstos otros, los del picado grueso, suelen argumentar con cierta razón que codificar una funcionalidad, tocando al mismo tiempo 5 o 10 archivos por separado, es un mareo. Uno trabaja en MVC, por ejemplo, saltando entre vista, controlador, modelo (principal y varios secundarios), un par de helpers, algo más aquí, algo más allá… y son como 10 archivos o más, si la cosa es compleja.  Y sí, puede ser… a mí no me molesta tanto, y, a la inversa, me es un mareo ver todo junto. “Así es MVC”, o “Así son las reglas de estilo en .Net”, contraataco (por no decir “así me gusta y punto”).

Normalmente, de encontrar código “picado grueso” en en una solución compilada de .Net, puteo (a veces para adentro, a veces para afuera)… pero en javascript, por ejemplo… “y bueh, así es la we’ ¿vio?”. Después empecé a usar require.js y… ¡picado fino en javascript! Y pienso (a futuro cercano, lo veo verde todavía) empezar con TypeScript y ahí los del picado grueso me van a odiar en serio, porque ya no hay excusa (salvo el gusto personal, argumento tan fuerte como el que lo utiliza –débil en mi caso-).

Pero no está mal el picado grueso, no. Es un tema de preferencias, nada más, de idiosincrasia, costumbre, organización mental de cada uno… andá a saber. Alguno dirá “hay que encontrar el punto justo”… y suena bien, pero (en este punto) prefiero seguir un (y sólo un) criterio, aunque se vaya al extremo. Habrá que ponerse de acuerdo y decidir con qué se prefiere lidiar cuando toque: ¿un archivo de 1000 líneas o una jerarquía de 5 carpetas de profundidad con 20 archivos de 30-50 líneas en cada una? Pero a veces una cosa y a veces otra (y a veces ninguna) sí que es un enjambre.

Es, en todo caso, una buen tema para animar la conversación alrededor del fuego de algún proyecto incendiado. Basta, me voá trabajar.

martes, 29 de abril de 2014

10 Razones para escribir un post después de 4 años de nada.

  1. Hacer una pausa en el trabajo.
  2. No poder darle al botón “Eliminar” del blog.
  3. Porque si voy a tener un blog desactualizado, que no sea con esa imagen “2000osa” tan horrible.
  4. Para empujar hacia abajo los post viejos, links muertos y servicios desaparecidos (pensaba en delicious, feedburner y cia.; pero siguen ahí… medio zombies).
  5. Curiosidad de ver cuántos feed readers quedan vivos (estimación: 5 o 6 de más de 100).
  6. Para hacerme el muerto a ver quién viene a velarme.
  7. Autobombo, porque soy genial.
  8. Talvez por estirar los dedos se me caiga una idea…
  9. Puesh porque me plaze (con acento español de españa – no offense).
  10. Para demostarme a mí mismo que todavía puedo rellenar una lista de “10 boludeces para que vean mi página y pueda cobrar el AdSense”.

Yapa: para hablar solo con excusa.

martes, 25 de mayo de 2010

La integración de la base de datos. Una cura definitiva para esta enfermedad crónica.

Martín Gargiulo Una colaboración de Martín Gargiulo (*).


Es muy común que los equipos de desarrollo trabajen sobre un ambiente de base de datos compartido. ¿Quién no ha sufrido las consecuencias de los desfasajes entre *la* base de datos y el resto del proyecto? ¿Quién no ha sido víctima –o victimario– de algún improperio cuando, en pleno desarrollo, un cambio en alguna propiedad u objeto de la base deja al resto del código pataleando en el aire?

Nunca, desde mis tempranos inicios, a través de diferentes proyectos en varias compañías, tuvieron estas cuestiones la suficiente importancia como para quitarle el sueño a nadie. Siempre, esto es lo realmente grave, parecieron ser lo normal. Estaba ante una enfermedad crónica.

Desarrollar implica agregar código, depurar, refactorizar y repetir estas operaciones un número de veces hasta obtener una determinada pieza de software. A nadie se le ocurre, hoy en día, que no se disponga de un sistema de control de código fuente, que permita a cada integrante del equipo trabajar localmente y luego, una vez concluida la construcción de la pieza, incorporar sus cambios al repositorio común.

Cada desarrollador debe trabajar en su propio espacio. Siguiendo esta premisa, ¿por qué la base de datos, siendo parte esencial del producto, no se incluye en él? ¿Por qué no es natural que cada desarrollador trabaje sobre su propio ambiente de base de datos?

Surge un problema. Si cada programador opera sobre su propio ambiente, ¿cómo obtienen los demás integrantes del equipo las modificaciones al esquema realizadas localmente? Del mismo modo que lo hace con el resto del código de la aplicación: mediante el repositorio de código fuente.

Por ello es indispensable que los scripts de base de datos estén incluidos en el controlador de código fuente, al igual que todo el resto del código. Es a través de estos scripts que se deben formalizar los cambios en la base que completan la programación de una pieza de software.

La base de datos, a diferencia de una pieza de código común, contiene estado (para eso está). Por eso, además del código para la creación de sus objetos, se deben tener en cuenta scripts de inserción de datos básicos para la aplicación (tablas paramétricas, tablas maestras) y, eventualmente, algún pequeño set de datos de prueba.

…continuará…


(*) Andrés dice: por fin, y luego de dos años de arrastrarme, alguien ha escuchado mis ruegos, dignándose a brindar… ¡una colaboración! Y en buena hora, que en este lugar ya se empezó a juntar el polvo. Esperemos que sea la primera de una larga serie y dé comienzo a una maratón de talentosos desarrolladores ansiosos por ayudarme a mantener vivo este humilde espacio (esperar es gratis, dicen).

jueves, 15 de abril de 2010

Frases: Lo que sobra.

[…] como verás, arquitectura y diseño es lo que sobra... sobra porque todos somos arquitectos y diseñadores y hacemos lo que se nos da la gana, no hay directivas.

Un amigo”, hablando sobre esas cosas lindas que tienen los sistemas.