Salvo la tragedia en Iraq eran tiempos buenos. Pero entonces llegó uno de esos términos nerds que se volvieron “mainstream”: web 2.0, y entonces  era momento de volverese cool, ¿Cómo podíamos lograrlo con la pobre oferta de herramientas para ese tiempo?

Comienzo aclarando que jamás he utilizado Ruby on Rails para desarrollar, es más, ni siquiera he visto código por curiosidad, no se si es falta  de interés, falta de tiempo o las dos cosas. De cualquier modo como desarrolladores deberíamos de tratar de entender las herramientas que tenemos  a la mano, las dominemos o no.

Chaos B.R. (Chaos Before RoR)

Allá pues en ese año 2003 donde poco sabía yo de programación el desarrollo “web” no era algo común, o no algo como lo que se ve ahora. Aunque  existían millones de sitios ya (incluídos los de pornografía) el término “Aplicación web” no estaba en el repertorio de toda la horda de programadores ni coexistía en miles de blogs de diseñadores, es más, pocos blogs existían en ese tiempo. Lo más que podíamos llamar aplicación web sería acaso los sitios que ofrecían servicios en línea como bancos y grandes empresas, creo que, si mi mente no falla, fuera de  estos mercados era poca la oferta de estas aplicaciones web.

Si se deseaba desarrollar algo “online” había básicamente 3 categorías, o mejor dicho yo lo pondría en tres categorías:

1. Sitios informativos
2. Sitios “dinámicos”
3. Aplicaciones grandes (e-business, b2b, etc)

Realmente fuera de estas tres categorías no había mucho que ofrecer o mas bien no lo suficiente maduro, para el primer caso la selección de herramienta a utilizar era sencilla: Html, diseñado con tablas por supuesto y una herramienta como Dreamweaver que no solo facilitaba la tarea sino además generaba suficiente código como para justificar cobrar el triple ya que dicho código generado parecía haber llevado ese tiempo de desarrollo. Para El segundo caso era común utilizar Perl por medio de CGI para generar “resultados dinámicos” en pantalla, quienes trataban de usar algo mas moderno preferían PHP por su facilidad. Finalmente para el tercer caso mayormente se optaba por algún monstruo como Java, ASP.Net y  su creciente pero inmaduro framework o peor aun ColdFusion y alguna otra cosa que se le pudiera “pegar”.

Estos fueron los años de caos, donde las tecnologías web 2.0 apenas emergían y por lo tanto oportunidades para nuevas tecnologías de desarrollo  no convencionales o al menos mas “arriesgadas” que la oferta que ya existía.

It’s 2005, bitch

Después de este año algo curioso pasó: “La web” comenzó a ofertar mas servicios de lo habitual, servicios que ya no solo eran aburridas transferencias bancarias y carritos de compra, nacía Twitter que por cierto a nadie le importaba, MySpace parecía la nacionalidad oficial de aquellos que gustaban de aventarse el pelo “pa enfrente” (o sea el 80% de los adolescentes/pubertos de la época) y en general cada vez nacían mas pequeños startups tratando de aprovechar esta fiebre de servicios en la web, servicios “desenfadados” y “cool” que no necesariamente estaban relacionados a actividades de negocios o empresariales, “amusement if you will” dirían mis vecinos los weros, entonces dentro de toda esta fiebre de servicios divertidos faltaba algo, algo para completar la fórmula: un ambiente de desarrollo divertido e informal, justo como estos mismos servicios.

Mira mamá, no estoy usando Ruby on Rails

Para cuando Ruby on Rails dejaba la estación “desconocido” para llegar a su destino siguiente “éxito” por el andén marcado como “cool” yo era un incipiente aprendíz de programador. De hecho mi primer intento de aprender a programar recuerdo fué cuando compré un libro de python por allá en  el 2004 después de una noche de borrachera de un gulev o un consol, donde por cierto conocí a Marco Islas que sí aprendió a programar en python,  en la cual como muchos otros me emocioné por las discusiones técnicas que tuvimos y el afán de crear un proyecto de algo para aprender, proyecto  que por supuesto no concreté por que soy mexicano y por lo tanto bien hocicón. Aunque cuando era mas peque y chateaba en latinchat, llevaba  clases de TurboPascal en la secu, realmente no tenía “experiencia real” en desarrollo de software.

Mi primer empleo como desarrollador fué por allá del 2006. La empresa para la que trabajaba me requería que aprendiera el recién lanzado C# 2.0  el cual ya tenía tiempo estudiando precisamente por que sabía que había mas oferta local de empleo que aprendiendo python. Pensar en aprender  ruby on rails ni siquiera pasaba por mi mente ya que además de ser una tecnología relativamente “nueva” para entonces necesitaba pagar “las  cuentas” así que mi mejor apuesta en ese momento era o C# o Java. Decidí aprender C# porque me pareció atractivo el proyecto mono en ese  entonces.

Aunque aprendí rápidamente a moverme en .Net y C# nunca me llamó la atención aprender ASP.Net. Hasta el día de hoy podría decir que de hecho  sigue pareciendome poco atractivo. Traté de tomar experiencia en cosas que en el momento me eran útiles como C#, SQL y otras cosas más aburridas  que tiene uno que hacer en su empleo de 9 a 5 aunque, cuando llegaba a mi casa, cansado y con pocas ganas de aprender más, me sentía un poco  triste al ver que no era cool, y no era cool porque parecía que la nueva onda era aprender estas cosas del desarrollo web, de metodologías  ágiles, de lenguajes ligeros y en general de nuevas formas de ver y hacer las cosas, y yo, desarrollando software empresarial y para gobierno  (que por cierto tiene mucho mérito, aplausos) me estaba quedando atrasado.

Web apps, la nube, go green, hipsters

¿Cómo llegamos de utilizar linux, java, tomar soda y comer pizza en noches de desvelo a tener una flamante macbook, preocuparnos por el ambiente, tomar café orgánico  y desarrollar en ruby on rails? Aun trato de decifrarlo y quizá sea tema para otro post. Lo que si sé es que pasaron dos cosas: El tiempo de  desarrollo se acortó por que las herramientas eran mas ágiles y el programador fué más feliz.

Sumar estas toneladas de felicidad con los tiempos cortos de desarrollo permitió que quienes hacían aplicaciones web no solo ofrecieran prototipos de productos en menor tiempo y con un costo mas accesible sino que la cultura de los startups o emprendedores comenzó a acercarse a  esta nueva generación de desarrolladores que no solo tenían ideas frescas para nuevos productos sino que podían de algún modo asegurar un retorno  de inversión con menos riesgo. Creo que esto empujó mucho la madurez de dichas herramientas y una parte importante de esta evolución fué  precisamente ruby on rails.

Debe haber una manera obvia de hacer las cosas

Este es el motto de Python. De hecho cuando me saltó el interés de tratar de aprender este lenguaje fué precisamente por esta razón. Utilizar  perl me parecía no solo difícil sino contraproducente con mi situación: falta de tiempo. El motto de perl es precisamente “there is more than one  way to do it” (hay mas de una forma de hacerlo) y el de python era todo lo contrario, “There should be one obvious way to do it” (Debe haber una forma obvia de hacerlo) que acerca mas al programador a la idea de DRY (Don’t Repeat Yourself), Convention Over Configuration, etc.

Aunque python es diferente en algunos aspectos específicos a ruby, es similar en general. Son lenguajes de scripting, ágiles y que se pueden aprender fácilmente y además son “divertidos”. Para mi python era el mejor lenguaje, o al menos el mejor lenguaje de scripting porque tenía características que no tenía perl (era fácil de usar), java (era ligero y fácil de aprender), o php (ordenado y con convenciones y estándares) y estaba decidido a aprender a hacer algo más útil que imprimir un “Hola mundo” en la terminal.

Aunque para mí, y para google, y muchas otras empresas grandes, python era el mejor lenguaje de scripting había algo que hacía falta: un entorno  que llevara la filosofía del lenguaje al mismo y que permitiera desarrollar aplicaciones web rápidamente. Desgraciadamente para mi el lenguaje  que hizo esto fue ruby y no python.

El que pega primero pega dos veces

Tal como lo dice el título del post, el que pega primero pega dos veces, dice por ahí un refrán. Y quien haya inventado este dicho tiene toda la razón. Ruby no es el mejor lenguaje, o al menos me parece que no es la única oferta. Como lo dije, python para mi es un lenguaje fácil de aprender y poderoso pero que en su momento no tuvo las herramientas necesarias para ser utilizado como plataforma de desarrollo web ágil.

Ruby  con Ruby on Rails cumplió eso. La analogía que hago es la del iPhone y en general del ecosistema de desarrollo de Apple. A nadie le gusta Objective-C, y quien diga lo contrario es un mentiroso, o al menos el 90% de los desarrolladores que lo utilicen, ¿Por qué? Porque es más facil desarrollar algo en cualquier otro lenguaje Mainstream como C# o Java o mejor aun, Python o Ruby, para cualquier tipo de aplicación: Manejo de  memoria automática (adios a los benditos punteros), thread safety, APIs extensamente documentadas, y en general comunidades mas activas de  desarrollo, ¿Por qué entonces se decide alguien a aprender este “viejo” y difícil lenguaje habiendo tantos otros? Fácil, porque existe un ecosistema creado por Apple con su iTunes store, su hardware como iPhone y iPad y un mercado de ventas excelente donde vale la pena aprender  dicha herramienta que por cierto no sirve mas que para dichos dispositivos y aunque ya existen otras ofertas como Android que permite desarrollo  sobre Java por ejemplo, Apple sigue teniendo la sarten por el mango, y el mango también, diría Alberto Cortéz.

Es la misma razón por la que Apple elevó el uso de Objective-C y cocoa que la que hizo que Ruby sea un lenguaje tan utilizado. Si tan solo  alguien más hubiera decidido crear una plataforma como Ruby on Rails en cualquier otro lenguaje entonces muy seguramente dicho lenguaje hubiera tenido un crecimiento de uso exponencial.

Por esta razón creo que decir que “Ruby on  rails” es el mejor entorno de desarrollo de aplicaciones web que existe hoy por hoy es algo injusto.  Si bien existen lenguajes donde personalmente creo que sigue siendo díficil y aburrido desarrollar para web como Java o ASP.Net creo que la oferta ha mejorado en otros lenguajes con otras tecnologías, tenemos un Django en python que es igual de bueno y mantiene la filosofía de RoR, un  CakePHP y un CodeIgniter en PHP, un ASP.Net MVC en el lado obscuro de las cosas, etc.

Los mayores beneficiados por RoR no solo son sus usuarios sino los demás programadores que también utilizamos otras herramientas. Yo, por ejemplo, con todo el esceptisismo que caracteriza a cualquier programador, me negaba a utilizar PHP, porque me parecía un lenguaje feo. Tener “islas de código” mezcladas en un archivo para crear la conexion a la base de datos, generar cálculos y posteriormente presentar dicha información, todo en ese mismo archivo me parecía algo vergonzoso, característica de PHP que viene arrastrando como fama por muchos años.

Cuando  conocí a mi amigo y socio Alan me dijo “Yo uso CodeIgniter en PHP”, comencé a usarlo por pura comodidad ya que nuestros primeros proyectos iban a  ser hospedados en servidores LAMP más económicos que los requeridos para “montar” aplicaciones en python o ruby y finalmente cedí cuando me di  cuenta que a pesar de que me parece que python por ejemplo tiene mejor sintáxis, también se pueden hacer cosas ordenadas en PHP utilizando algo  como CakePHP o CodeIgniter y muy seguramente es el mismo caso de Perl y otros lenguajes.

Esta tendencia de “organizarse” mejor definitivamente es honor de Ruby on Rails. Y aunque prefiero no juzgar ninguna de estas plataformas les diría que aprendan alguna. Todas tienen ventajas y desventajas, claramente, y cada proyecto sigue objetivos diferentes pero al final lo que beneficia es algo común: desarrollo organizado, ágil y divertido. Y aunque RoR fue el padre de esta tendencia creo que ya hay ofertas en otros lados igual de buenas, justo como probablemente sea igual de buena la oferta de aprender a desarrollar para Andoid y no solo para Apple aunque esta última haya “pegado primero”.

Angel, jefe de todos en Arkus, decidió que pondríamos tres horas de nuestro viernes y se las dedicariamos a este proyecto.  Antes saliamos a las 4 p.m. los viernes lo cual estaba excelente pero desgraciadamente nos movieron el horario y ahora salimos todos los días a las seis en ves de las 6:30 pero los viernes ya no salimos a las 4.

Total que, las tres horas después de la entrada de comida del viernes (a las 3 p.m.) tendremos que dedicarlas a este proyecto. Yo tuvé muchas ideas que tenían que ver con software organizacional pero al parecer no muchos me siguieron la onda. La mayoría opinaba que desarrollar un juego sería lo mas divertido pero después de ver que, 3 horas a la semana, es muy poco para un proyecto que es “técnicamente” complicado decidieron pensar de nuevo y todos votaron por un sitio tipo “red social”

Al final se llegó a la conclusión de que debíamos solucionar un problema con nuestro software y terminó siendo (o terminará, ya que no existe código aun)  una aplicación web para hacer pedidos de comida. Quizá en otro post lo explique mejor.

Después de decidir cual sería la aplicación se repartieron los puestos o cargos. Yo decidí no tomar la iniciativa ya que no sería un “reto” pues sabía que había algo que nadie iba a querer tomar. Todos estaban emocionados con la arquitectura, el análisis, el backend, el frontend… pero había algo que nadie (y que usualmente, nadie hace) quería hacer y que fue lo que “quedó” a lo último y lo que finalmente tomé: La documentación.

Me parece que documentar un proyecto es una de las actividades mas importantes para cualquier software que se jacte de decir que está “organizado” de algún modo. La documentación que tendré que desarrollar es la de usuario y la del desarrollador.

Para poder llevar la documentación y el código ordenados creí que sería buena idea llevar un software tipo wiki. También pensé que tendriamos que tener un software de bug tracking y al final parece que Trac es lo mas adecuado que existe ya que bugzilla me parece demasiado complejo y además no está integrado con nada. Aprovechando que tenía pretexto he adquirido un servidor en webfaction para poder hospedar la aplicación y el depósito de subversion ya que la idea es que este proyecto sea lanzado como Open Source.

Otra razón más por la cual decidí adquirir mi cuenta en webfaction es que desde que aprendí a programar con python nunca desarrollé nada en serio y hoy que ya vivo de esto me gustaría retomar el aprendizaje pero enfocado a algo mas útil. Por el momento estoy en el debate si debería empezar a aprender django o turbogears. En realidad aún no se por donde empezar pero creo que al menos tendré que retomar mis libros y actualizarme.

Me han estado cambiando mucho de proyectos y la verdad no me agrada la idea pero al final es trabajo. Pasa que, invariablemente estos proyectos donde me han asignado tareas tienen fecha límite de entrega de “ayer” así que en teoría algunos estan ya retrasados. Sinceramente no me gusta trabajar así todo el tiempo ya que es molesto hacer las cosas apurado pero supongo es una racha, si no ya veremos a que me dedico después

Algo con lo que me he topado estos días precisamente es mi falta de experiencia con bases de datos. En general puedo considerar que tengo buena experiencia con desarrollo de software pero las bases de datos siguen siendo algo con lo que me sigo peleando día a día y es que como alguna vez comenté por aquí, yo tuve la fortuna o desgracia, depende el punto de vista, de comenzar a desarrollar software utilizando un ORM y hoy que tengo que usar día a día SQL y todo lo que ello conlleva (al menos de la parte de Microsoft) he tenido que pensar seriamente en tomar algún curso. De hecho ya tengo bastantes videos que baje del sitio de ASP.Net es solo que me he vuelto un poco perezoso para leer manuales y documentacion o ver videotutoriales pero creo que esta misma tarde comienzo.

Estos últimos días tuve la “suerte” de tomar un proyecto en la oficina que había que entregar pronto. Uno de los requerimientos del proyecto era imprimir una factura la cual se diseña con un reporte. La “tecnología” de reportes utilizada es la que viene por default con Visual Studio 2005: Crystal Reports.

La sensación de desolación que me dejó utilizar crystal reports es incomparable con cualquier otro tipo de dolor. De entrada quise utilizar dos DataTable’s que tenía definidos en un DataSet, de ahí, uno de estos datatables contenía la información general de la factura y por otra parte el otro datatable contenía los detalles o conceptos de la factura, o sea los datos que se “repiten” en la factura. Después de intentar me dí por vencido hasta que Alfredo, compañero de trabajo y mi jefe anterior de proyecto me dijo que lo mejor para mi tranquilidad mental era meter como parámetros los datos generales y solamente meter un datatable para los detalles. Sí, de algún modo crystal reports no soportó manejar dos tablas para generar el reporte, solamente una, algún error de autentificación me marcó que ya no recuerdo.

Ayer pasé la tarde y la noche diseñando la factura y fué una experiencia terrible, las herramientas de diseño que tiene crystal reports son bastante inestables y de hecho muy, pero muy limitadas. Después de pasar preciadas 6 a 8 horas de mi sabado de descanso en esta tarea (y arreglando algunos otros bugs) me quedé a ver TV un rato y me fuí a dormir ya que Yari se había ido a Rosarito con sus amigos y todos los demás conocidos que viven aquí se habían ido a San Luis.

Hoy recordé que tenía un pendiente con el proyecto y mañana debo ir a instalarlo con el cliente así que decidí solucionarlo hoy domingo. Sorpresa que, al abrir Visual Studio e intentar cerrar las pestañas de los archivos aspx que habían quedado abiertas al abrir la solución, este se colgaba.

No me había pasado esto de hecho hasta que comencé a utilizar Crystal Reports, la solución fue cerrar unicamente la pestaña del reporte y acto seguido cerrar visual studio, posteriormente lo volví a abrir y el problema desapareció. Parece ser que el problema es que crystal reports carga algún control ActiveX no soportado por Windows Vista lo cual crea incompatibilidad e inestabilidad.

Uno de los bugs que me causó mas problemas fue que, al agregar un objeto tipo “CrystalReportSource” a la página aspx y dirijirme a seleccionar el reporte este se negaba a mostrarme la vista previa y por lo tanto el reporte no se visualizaba. Resulta que al seleccionar el archivo de reporte me aparecía la siguiente ventana:

Después de varios intentos y de estar seguro que el reporte que estaba seleccionando era el correcto decidí eliminarlo y crear uno nuevo. Después, también gracias a la ayuda de Alfredo, pude solucionarlo, me dijo con una tranquilidad de monje tibetano: “No, así no va a funcionar, quitale el path y deja solamente el nombre del archivo” y es que sucede que, crystal (o visual studio) tiene un bug que hace que no tome el path correctamente del archivo, es decir, el archivo aspx que contiene el código que utilizará este reporte estaba mas o menos así:

/Invoice/getInvoice.aspx

Y el reporte:

/Invoice/Invoice.rpt

Por lo cual dí por hecho que lo que me estaba mostrando el combobox era correcto, para solucionar el problema debía eliminar la carpeta “/Invoice” de la ruta del repore aun sabiendo que efectivamente ahí estaba el reporte:

Sé, y entiendo perfectamente que todos los desarrolladores de software nos equivocamos, nadie es perfecto, pero, por Dios, ¿Cómo algo tan importante paso las pruebas de calidad? Supongo que nadie en el grupo de desarrollo de Visual Studio utiliza Crystal Reports, de hecho, hablando con varios compañeros de la oficina me dí cuenta que efectivamente ahí nadie utilizaba crystal reports, preferian hacerlo “a mano” generando páginas con código html.

¿Alguién tiene alguna buena historia con este producto? Por que creo que de lo contrario de hoy en adelante trataré de mantenerme al margen del mismo ya que la primera impresión fué mala y en esto como en las relaciones amorosas, eso es lo mas importante.

Mi pregunta es, ¿Donde diablos agarra la gente esta barra? ¿MySpace?, ¿Emoticons para el messenger?, juro que, a pesar de a veces estar en sitios no seguros jamás he podido agarrar ese “spyware” y lo mas molesto es que, quitarlo es un poco engorroso ya que al parecer ni spybot ni adaware lo eliminan completamente.

Para desactivarlo hay que descargar el “HiJack this”, es un programa que nos permite ver que componentes, programas, opciones de menu, etc se cargan al inicio. Puedes decargarlo desde aquí. Una vez que lo descargaste simplemente ejecutalo y aparece la siguiente ventana:

Una vez que el programa se ejecutó hacemos click en la opción “Do a system scan only” y despues de que el programa procese las entradas del sistema algo así nos debería de aparecer:

Hecho esto podemos seleccionar las entradas que deseamos desaparezcan del sistema, busquen cualquiera con la expresión “MYWEB” o “Mywbs” etc. Una vez que las localizamos las seleccionamos en el checkbox y presionamos fix checked, reiniciamos el sistema y listo.

El video es una presentacion de David Heinemeier Hansson, creador de Ruby on Rails. En el video habla precisamente de algo que yo había estado preguntandome desde hace mucho tiempo: ¿Cómo se puede hacer dinero con un producto de software? Parece que la respuesta se vuelve bastante compleja. David habla de como el sueño guajiro de todos los desarrolladores y gente que esta dentro de las TI están traumados con tener una idea excelente, explotarla, tener miles de clientes o visitantes y de repente Google llega y nos ofrece 1000 millones de dolares por nuestro producto.

David también menciona como el sueño de todos nosotros es convertirnos en el próximo MySpace, Facebook o Youtube cuando, aún posible matemáticamente hablando, físicamente es casi imposible dadas las pocas probabilidades que tenemos. El negocio de las “redes sociales” y sitios de videos etc ya no es inovador, lo fue cuando los pioneros lo tuvieron en mente y lo lanzaron pero ya no lo es mas. Un sitio que me ofrece exactamente lo mismo que youtube o que myspace no me ofrece ninguna novedad (bebo, ringo, metacafe?)

Este tipo trabaja para basecamp, una empresa de software organizacional que es vendido al estilo SAS (software as a service) es decir, se renta en sus propios servidores, y hasta la fecha, les ha funcionado, cuentan con varios paquetes de software para empresas, la clave del éxito, según David es bastante simple:

1. Crear un producto que solucione un problema
2. ????????
3. Ganar dinero

David bromea en el video de la presentación con el punto número dos, ¿Cuál es la gran clave para ganar dinero, bueno, resulta que el punto número dos es “ponerle un precio al producto”. Así es, tan sencillo como eso. La mayoría de gente que conozco y que son programadores alguna vez se quizo hacer rico con cosas “gratis” por ejemplo escribiendo un blog y recibiendo dinero de AdSense, y si bien a algunos les ha funcionado, es mas fácil seguir el modelo antiguo de crear un producto que resuelva el problema de algún cliente, ponerle precio y venderlo.

Así de fácil. El video contiene otros puntos interesantes, totalmente recomendable:

Ver el video

*PD: El video está en inglés.

La verdad es que, lo confieso, hace algún tiempo me registré en rentacoder. Para los que no lo saben, rentacoder es un sitio de “subastas” donde empresas o personas que necesitan algún proyecto de software envían su propuesta de trabajo y después los programadores subastan en dicho proyecto, fácil, ¿No?…

Pues no… Recuerdo que di con ese sitio por que cuando iniciamos uno de los proyectos en el trabajo, que por cierto nunca concretamos por que salieron otros,  mi coordinador y jefe mandó a desarrollar un módulo de seguridad para la aplicación así que pensé que si había personas que podían trabajar haciendo outsourcing yo también podría hacerlo.

Después de registrarme en el sitio me dí cuenta de algo curioso: la mayoría de los proyectos terminaban siendo subastados en cantidades que dan risa, todos los trabajos los obtenia algún programador de Sri Lanka o India y finalmente, para si quiera ser considerado uno debería tener al menos unos 20 proyectos terminados.

Total que, para terminar rápido decidí darme de baja. Después de mucho tiempo de buscarle me di cuenta de que era mas el tiempo que perdía en buscar trabajo dentro de ese sitio que lo que me llevaría conseguirlo “localmente”.

Y se que la culpa no es del capitalismo ni del hindú en cuestión, lo que si es insoportablemente desagradable es ver como el trabajo de los ingenieros en sistemas / software / etc. se ha convertido en una de las formas de prostitución laboral actuales.

Algo que he notado en mi experiencia laboral es que, la mayoría de las personas que  no se dedican a esto de “las computadoras” es que piensan que los que sí somos otro tipo de profesionista, es decir, que ser ingeniero en sistemas o lic en informática o algo parecido es ser como un plomero y no, no tengo nada en contra de los plomeros, cualquier empleo que no sea el de delincuente, narcotraficante o peor aun, político (que generalmente tienen las dos cualidades antes mencionadas) es honesto y noble pero obviamente la mayoría de los plomeros, al menos aquí en México son personas autodidactas sin estudios profesionales, bueno, ustedes saben a que me refiero. Y es por esa razón que esta misma gente cree que desarrollar un software o una página de internet es como “bajar algo” del limewire o del ares.

Y es que, sinceramente, son pocas las profesiones que requieren que uno esté documentandose y leyendo todos los benditos días y donde uno debe dominar tantas cosas. Se que los médicos, por ejemplo, son uno de esos casos donde deben dominar varios temas dentro de su profesión y además estarse actualizando. La mayoría de las otras profesiones que no son tan técnicas suelen ser mas cuestión de creatividad y estar al tanto de las tendencias y cosas por el estilo. Un informático, como dicen los gachupines, tiene que dominar 300 cosas diferentes para poder crear un solo producto a veces.

Entre las trescientas cosas que tiene que dominar uno a veces estan algunos paquetes de software o tendencias que nos llevan a otras cosas, total que para terminar pronto a veces uno puede ver este tipo de puestos de trabajo:

Se solicita ing. en sistemas o afín con el siguiente perfil:

Programación en C/C++/C#/PHP/ASP/Java, JavaScript

Html, CSS, struts, jboss

Manejo de routers, voip, configuracion de firewall, servicios de red 

Conocimiento en sistemas operativos linux, bsd, windows 

Manejo de bases de datos SQL Server, MySQL, Oracle etc

Programas de diseño como photoshop, corel draw, flash…

Minimo  5 años de experiencia, ofrecemos sueldo mensual de 6000 pesos mas prestaciones de ley…

¿Qué? Uno se queda pensando si realmente la persona en recursos humanos tiene idea de lo que esta pidiendo, y no es que sea imposible, pero simplemente para conseguir el dinero que costaría comprar las licencias del software del cual piden experiencia sería como el equivalente a un año de trabajo sin gastarnos ni un solo centavo mas que en eso mismo.

Y al final, la verdad es que, el problema radica en que el software se ha vuelto en un producto bastante barato y donde, por conseguir clientes, uno como desarrollador o profesionista suele “bajarse los pantalones” como vulgarmente dicen. Y no es broma, el tipo de oferta de trabajo como el anteriormente expuesto existe. Pero, ¿Por qué piden tanto para una persona del área de informática? Creo que no he visto en ningún bufette de abogados a alguien solicitando un licenciado en derecho con experiencia en derecho laboral, propiedad intelectual, derecho militar, casos penales, etc. O una empresa de construcción pidiendo a un ingeniero civil que construya casas, edificios, centros comerciales, puentes, parques etc…

Así que volviendo al tema principal, definitivamente el ser un “freelancer” desarrollando software puede ser algo que, aunque placentero, por la cuestión del horario e independencia, no siempre es una situación comoda ya que uno no puede aspirar a obtener muchos ingresos de ello. Está de mas resaltar que como dicen, lo “barato sale caro”, y cualquier proyecto de software bien hecho cuesta dinero, como cualquier consulta a un medico, una casa bien hecha o un abogado defendiendo nuestro caso. Yo personalmente preferiría pagarle a un buen arquitecto que diseñe mi casa y que se especialice en eso a tener a alguien que me cobre barato pero me haga un mal trabajo, es algo que he aprendido al vivir solo, mucho del trabajo que me han hecho en mi casa, como remodelaciones, instalaciones electricas y de ese tipo, han sido trabajos pésimos por ahorrarme algo de dinero, aprendí la lección y creo que algunas personas que consumen servicios de tecnología deberían considerar eso también, que un trabajo bien hecho y de calidad siempre costará.

Y ustéd mi amigo lector, ¿Qué opina?

El enlace (en inglés)  aquí

Ya había tenido ese problema antes pero no le tomé importancia hasta hoy. Resulta que a veces, de repente, cuando estamos editando un menú o utilizando el editor de WYSIWYG jce, de repente, el sistema backend o el área administrativa nos “bota” del sistema y tenemos que volver a iniciar sesión.

Este problema lo noté cuando actualicé los sitios que tengo a joomla 1.0.13. Parece ser que es un problema conocido aunque, al parecer no ha salido ninguna actualización asi que me puse a buscar un parche y al parecer funciona. El parche lo pueden descargar de aquí

Para los que no lo saben, o no sabían, como yo, rails, o mejor dicho ruby on rails, es un framework para desarrollar aplicaciones web siguiendo el modelo “MVC” (Model-View-Controller) utilizando la metodología “agile” o programación ágil.

Todos estos conceptos son conceptos que la verdad, suenan muy bonitos y tecnológicamente avanzados pero a veces no los entendemos y yo, lo admito, no entendía algunas de esas cosas. Aún cuando sé que significan algunos conceptos ya en la práctica esto es muy diferente.

Total que me dediqué las pasadas semanas a experimentar con rails. Lo único que sabía es que era una plataforma de desarrollo web basada en un lenguaje de programación (ruby) el cual por cierto no conocía tampoco.

Al principio me pareció fácil ya que ruby es mas o menos parecido en sintaxis a python, lenguaje en el cual aprendí mas o menos a programar, aunque después de “cascarearle” un rato me pareció un poco dificil de seguirle el paso ya que de por sí programar en lenguajes altamente tipificados como C# (lo que uso a diario) deja costumbres diferentes a las que dejan los lenguajes de “scripting” como python, perl o ruby y la verdad es que ya tenía bastante de no cascarearle a python.

Ruby on rails es un framework excelente: código limpio, una API bien documentada y todo el marketing del mundo, y obviamente tiempos de desarrollo lo suficientemente cortos como para poder ver los simpson por las tardes.

Pero después de analizar ruby on rails comencé a leer un poco mas sobre el lenguaje (quizá debí primero leer sobre el lenguaje, y despues por las herramientas) y aunque es un lenguaje agradable me pareció un poco menos legible que python, aun así, me parece un lenguaje “noble” como python pero por cuestiones de gusto creo que me quedo con python.

Así que ya que ví que ruby on rails es bueno decidí buscar algo parecido para python, es decir un framework, y ya alguna ves había leído sobre estos como turbogears, django, zope, pylons, etc. A decir verdad existen bastantes para python es solo que no tuvieron quizá el mismo marketing que ruby on rails tuvo.

Hasta el día de hoy puedo decir que ya tengo cierta experiencia en .Net con C# y pretendo retomar mis “raices” con python para desarrollo web “agil” ya que es mas rapido que hacerlo con Asp.Net y por que PHP no termina de gustarme.

El punto de todo este post es que, hoy por hoy existen herramientas para desarrollo web que han facilitado a muchos el desarrollo de aplicaciones, sea php con mysql, aun con sus defectos, ruby y python con frameworks para desarrollo ágil y finalmente Java y .Net para desarrollos empresariales. Recuerdo hace algunos años, cuando solía frecuentar el canal de unixmexico en irc que habia un tipo medio payaso que nos decía a todos en el canal que python no tenía futuro, que era un lenguaje para “script kiddies” y que los administradores de red de verdad utilizaban perl, también recuerdo alguna ves haberle dicho a esta persona en el canal que, aun con todas las ventajas de perl tenia una grande desventaja: no tenía soporte para varios lenguajes y de por sí la sintaxis de perl era horrible, al menos para mí, en ese tiempo (2001) .Net apenas daba sus primeros pasos y al ser una herramienta de Microsoft obviamente no era (quizá aun no lo sea) bien vista por los usuarios de Unix, sobre todo de linux. La respuesta a mis argumentos, por su parte, fue la siguiente:

“perl hace todo lo que python puede hacer y mejor, tiene mejores expresiones regulares y se está desarrollando parrot, una maquina virtual que va a poder ejecutar todos los lenguajes de programación que existen”

Hasta el día de hoy, python ha llegado a ser exitoso en grandes entornos, por ejemplo, google lo utiliza en muchas de sus aplicaciones, php es el “rey” de las aplicaciones web aun cuando no tiene las mejores prácticas pero tiene una gran parte del mercado, ruby, con ruby on rails, es la herramienta de desarrollo favorita que está en boca de todos, de hecho, python ha sido portado ya a la maquina virtual de java con jython y a .Net con IronPython con apoyo de Microsoft, ruby ha sido portado totalmente a java con JRuby por parte de Sun Microsystems, y está siendo portado también a .Net con Ruby.Net, PHP ha tenido algunos avances con frameworks como CakePHP que intentan llevar algo de rails u otros frameworks a este lenguaje… .Net ha sido portado a Unix/Linux con Mono y se tiene yá un buen soporte para gran parte de la API y se puede utilizar con confianza para desarrollar aplicaciones multiplataforma como Java.

Y entonces, 7 años despues, donde esta perl, que puede ofrecer que no ofrezcan ya otros lenguajes de programación? Parrot?, no, gracias, perl 6, versión sobre la que supuestamente correría parrot parece no tener fecha tampoco. Creo que perl 6/parrot se convirtieron finalmente en el “duke nukem” de las herramientas de programación.

Powered by ScribeFire.