jueves, 30 de enero de 2014

Las cinco cosas más frustrantes de la profesión de programador

Trabajar como programador implica una serie de cosas realmente frustrante que podemos declarar como propias de la profesión. No os preocupéis, realmente puede seguir gustándote trabajar como programador, pero debes asumirlo cuanto antes.
La profesión de programador está lejos de ser automatizada por completo, es necesario resolver muchos y variados problemas a diario mediante la intervención humana. Parte de ellos son quebraderos de cabeza que no tienen que ver con el trabajo en sí que estamos haciendo.
A continuación una serie de las cosas más frustrantes de la profesión de programador.

1. Arreglar el ordenador a todo el mundo
Que gran parte de la humanidad (incluyendo a conocidos, amigos, vecinos y, por supuesto, familiares) asuman que puedes y debes arreglarles el ordenador o cualquier aparato electrónico. Por supuesto, todo esto de forma gratuita y dedicando tu tiempo libre. Lo peor de esto, no es arreglar el ordenador en sí, si no aguantar todos los comentarios y vacilaciones cuando realmente algo no tiene solución y les intentas convencer que deben llevarlo al SAT oficial.

2. Incidencias de errores incompletas
Informes de bugs sin suficiente información para reproducir el error. Cualquiera que se dedique a programar y mantener una aplicación con usuarios finales ha sufrido auténticos quebraderos de cabeza al intentar resolver incidencias incompletas. Los usuarios tienen el gatillo fácil para abrir una incidencia sin preocuparse si realmente lo están haciendo bien o aportar la suficiente información sobre el problema. Hay que perseguirlos para recabar datos e insistir para que aprendan a abrir incidencias de errores adecuadamente.

3. Que los usuarios ignoren la documentación de la aplicación
Ignorar la documentación. Hay que reconocerlo: escribir documentación es una de las tareas más tediosas que existen, sobre todo cuando te toca hacerlo al final, después de haber dedicado toda tu energía a desarrollar una aplicación. Por eso, es especialmente frustrante cuando un usuario ignora la documentación y pretende que le expliquemos cómo funciona algo sin haberse molestado en echar un vistazo al manual de usuario.

4. Las prisas en los plazos de entrega
Una lucha constante entre los desarrolladores y sus gestores de proyectos imposible de solucionar (da igual si internamente usas metodologías ágiles, para ellos no existen). Por un lado se quiere tener una nueva funcionalidad (muchas veces sin importar cómo) y, por el otro, se intenta hacer lo mejor posible, pero con plazos de entrega que no son realistas se fuerza a las horas extras y no aplicar correctamente las buenas prácticas a la hora de desarrollar: no hay tests, no se documenta, no existe ningún principio de clean code, etc…

5. Los errores inesperados en el entorno de desarrollo o en las maquinas de producción
Resolver los errores inesperados de servidores, de que el Eclipse empiece a fallar, problemas entre librerías, maquinas sin espacio, liarla parda con el repositorio, trabajar sin un correcto entorno de pre-producción etc.. Una serie de errores externos a nuestra aplicación, e incluso a nuestro equipo de desarrollo que nos hacen perder una mañana entera para resolverlo.






Noticia original en Genbetadev

lunes, 20 de enero de 2014

Desarrollo de apps, ¿un negocio rentable?

Debido a que en los últimos años el mercado de los dispositivos móviles inteligentes ha crecido de forma exponencial en todo el mundo, y especialmente en España, muchos desarrolladores han puesto sus esperanzas en ganarse la vida desarrollando sus propias apps para las diferentes plataformas de Smartphone y Tablet.
Sin embargo, las cifras apuntan a que, si bien el número de descargas de aplicaciones está subiendo vertiginosamente, la inmensa mayoría de ellas son, eminentemente, gratuitas, lo que deja un escaso margen de oportunidades a los desarrolladores. Incluso, para la mayor parte de las apps de pago existe una versión o alternativa gratuita, por lo que, cada vez son más altos los requerimientos que los consumidores piden a la hora de pagar por una aplicación.
En este sentido, dentro de sus predicciones para 2014 en movilidad, Gartner dibuja un escenario más bien sombrío durante los próximos años. Para Ken Dulaney, vicepresidente y analista de Gartner, “el amplio número de apps existente implica que las plataformas móviles podrían resultar una vía de ingresos para muchos”. Sin embargo, afirma, “nuestros análisis muestran que la mayoría de las aplicaciones móviles no están generando beneficios. De hecho, muchas de ellas no están diseñadas para obtenerlos, sino para obtener imagen de marca o reconocimiento”.
Según Gartner, en 2018 únicamente el 0,01 por ciento de las aplicaciones móviles de consumo serán consideradas como un éxito desde el punto de vista financiero, una tasa muy pequeña si tenemos en cuenta el potencial del mercado a nivel mundial.
Y es que, hoy en día existen muchas aplicaciones móviles gratuitas que por definición no han sido creadas para obtener beneficios. Para el futuro, además, esta tendencia se reforzará, ya que Gartner espera para 2017 que el 94,5 por ciento de las aplicaciones móviles sean gratuitas. Pero, además del poco margen existente, desde Gartner afirman que la oferta de apps móviles de pago será todavía más alta, ya que se irán sumando nuevas iniciativas (especialmente en las áreas más exitosas), lo que encorsetará aún más las posibilidades.
¿Y tú qué piensas?, ¿crees que el desarrollo de apps un negocio rentable?

martes, 14 de enero de 2014

Eclipse IDE



Hoy vamos a dedicar unas palabras al entorno de desarrollo integrado Eclipse.
Eclipse es una plataforma de desarrollo, diseñada para ser extendida de forma indefinida a través de plug-ins. Fue concebida desde sus orígenes para convertirse en una plataforma de integración de herramientas de desarrollo. No tiene en mente un lenguaje específico, sino que es un IDE genérico, aunque goza de mucha popularidad entre la comunidad de desarrolladores del lenguaje Java usando el plug-in JDT que viene incluido en la distribución estándar del IDE.
Proporciona herramientas para la gestión de espacios de trabajo, escribir, desplegar, ejecutar y depurar aplicaciones.
Principales características
Perspectivas, editores y vistas: en Eclipse el concepto de trabajo está basado en las perspectivas, que no es otra cosa que una preconfiguración de ventanas y editores, relacionadas entre sí, y que nos permiten trabajar en un determinado entorno de trabajo de forma óptima.
Gestión de proyectos: el desarrollo sobre Eclipse se basa en los proyectos, que son el conjunto de recursos relacionados entre sí, como puede ser el código fuente, documentación, ficheros configuración, árbol de directorios,… El IDE nos proporcionará asistentes y ayudas para la creación de proyectos. Por ejemplo, cuando creamos uno, se abre la perspectiva adecuada al tipo de proyecto que estemos creando, con la colección de vistas, editores y ventanas preconfigurada por defecto.
Depurador de código: se incluye un potente depurador, de uso fácil e intuitivo, y que visualmente nos ayuda a mejorar nuestro código. Para ello sólo debemos ejecutar el programa en modo depuración (con un simple botón). De nuevo, tenemos una perspectiva específica para la depuración de código, la perspectiva depuración, donde se muestra de forma ordenada toda la información necesaria para realizar dicha tarea.
Extensa colección de plug-ins: están disponibles en una gran cantidad, unos publicados por Eclipse, otros por terceros. Al haber sido un estándar de facto durante tanto tiempo (no el único estándar, pero sí uno de ellos), la colección disponible es muy grande. Los hay gratuitos, de pago, bajo distintas licencias, pero casi para cualquier cosa que nos imaginemos tenemos el plug-in adecuado.
Plug-in JDT
Dado el extenso uso que se le da, nos permitimos dedicarle un apartado específico. Es el plug-in encargado del soporte del IDE al lenguaje Java, incluido en la versión estándar de Eclipse por defecto, que como ya hemos explicado, no está concebido para dar soporte a un lenguaje determinado.
Cuando abrimos un proyecto Java, se abre la perspectiva correspondiente. Está formada por dos vistas: Outline y Package Explorer. La vista Outline se encarga de mostrar el esquema de la clase que tenemos abierta en el editor activo en ese momento. Una cuestión muy interesante es que cuando tenemos una vista activa, se visualizan en la barra de herramientas iconos extra, que nos permitirán el acceso rápido a las funciones más usadas de dicha vista.
El coloreado de código en el editor es una característica muy interesante, realizando para ello el reconocimiento sintáctico de todas aquellas palabras que son reservadas en el lenguaje Java.
Asímismo nos permite completar el código automáticamente (code completion), con sugerencias dependientes del contexto, lo cual nos permitirá escribir código más rápidamente.
Se podrá configurar el formateo de código, la forma de escribir los comentarios, incluyendo comentarios para la posterior creación del Javadoc. Podemos generar los esqueletos de clase automáticamente, generación de métodos getters y setters de manera automática, y un largo etcétera de funcionalidades, que a día de hoy nos parecen típicos, pero muy útiles.
Historia
Los orígenes de Eclipse los encontramos en su antecesor VisualAge de IBM, que desarrollo una máquina virtual dual para Java y Smaltalk (lenguaje este último en el que se escribió el producto). Cuando Java se comenzó a extender, y aumentó su popularidad, IBM decidió abandonar el proyecto de la máquina virtual dual y desarrollar una nueva plataforma basada en dicho lenguaje.
De ahí, en el año 2001, nació junto con Borland la Fundación Eclipse, sin ánimo de lucro, convirtiendo a Eclipse en un proyecto de código abierto, bajo licencia Eclipse Public License. Esta fundación se ha ido enriqueciendo con la inclusión de importantes empresas del mundo del desarrollo: Red Hat, Oracle, HP,…
Proceso de instalación
Es tan sencillo como descargárselo de la página de Eclipse y descomprimir el fichero en la ubicación deseada. No hay nada más que hacer, ejecutarlo, configurarlo y listo.
Versiones
Está muy bien, ¡que fácil es de instalar!, pero ¿qué versión me bajo?. En la página de descargas de Eclipse podemos ver todas las versiones que se muestran en la imagen que acompaña a estas líneas.
Lo primero, y bastante obvio es elegir el sistema operativo para el cual va a ser instalado: Windows, Linux o Mac OS X (desplegable de la parte superior del listado). Después deberemos ver el listado de versiones preconfiguradas que se nos ofrecen, esto es la misma base pero con diferentes plug-ins instalados, ajustándose a las necesidades más conocidas para los distintas necesidades de programación. En la fecha actual hay 12 versiones disponibles, que no encontráis la vuestra, no olvidéis buscar en las “Developer Builds“ donde podemos encontrar la que se adapte a nuestras necesidades, pero en desarrollo. Los programadores de PHP podrán encontrar en este listado la versión de Eclipse adecuada para ellos:
Si aun así no encontramos la versión que se adapta a nuestras necesidades, podemos buscar entre la extensa lista de software basado en eclipse.
Existen otras versiones, basadas también en Eclipse, y desarrolladas por terceros, como puede ser el caso de STS (Spring Tool Suite), Amzi! Prolog + Logic Server, Goclipse, MyEclipse, TimeStorm, Aptana Studio, Zend Studio,… La lista de IDEs basados en Eclipse es enorme, con lo cual nos hacemos una idea de la importancia de este.

martes, 7 de enero de 2014

D: un nuevo lenguaje de programación

D es un lenguaje de propósito general y para aplicaciones. Es de alto nivel pero retiene la capacidad de escribir código de alto desempeño y poderlo ligar directamente con el API del sistema operativo y el hardware del equipo. D es una buena opción para escribir programas medianamente grandes a algunos de gran escala, con millones de líneas de código, escritos por un grupo de desarrolladores. D -dicen los creadores- es fácil de aprender y da muchas posibilidades y ayudas al programador. Tiene además una optimización agresiva en el compilador.
D no es un lenguaje de scripts o interpretado. No tiene una máquina virtual como Java, por ejemplo. No es una religión ni una filosofía de vida. Es un lenguaje práctico para los programadores prácticos que necesitan sacar el trabajo rápidamente, con código entendible y mantenible fácilmente. Es, dicen, la culminación de décadas de experiencia implementando compiladores para diversos lenguajes e intentando construir proyectos grandes usando estos lenguajes. D obtiene su inspiración en C++.
Pero… ¿por qué necesitaríamos un nuevo lenguaje? La industria del software ha tenido un largo camino desde que el lenguaje C fue inventado. Muchos conceptos se añadieron a C++, pero manteniendo la compatibilidad hacia atrás con C. Con ello también se mantenía la compatibilidad con sus debilidades, por decirlo de algún modo. Y aunque C y C++ están en constante revisión, cada nueva característica debe ponerse cdon mucho cuidado para ser compatible con las estructuras existentes sin requerir reescribir código antiguo. El resultado es complicado: El C estándar tiene cerca de 500 páginas y C++ tiene unas 750. Es costoso y difícil escribir hoy en día programas en C++ que sean portables a otros sistemas operativos.
La cuestión es si es posible extraer el poder y capacidades de C++, rediseñarlas y ponerlas en un lenguaje simple, ortogonal y práctico. ¿Puede ponerse todo en un paquete que es fácil para los escritores de compiladores implementar correctamente, lo cual permitiría a los compiladores generar código agresivamente optimizado? Ésa es una de las pretensiones de este nuevo lenguaje D.
Waltr Bright es el creador de D, en el cual empezó a trabajar en 1999. D salió públicamente en diciembre del 2001, y alcanzó la versión 1.0 en enero del 2007. La primera versión del lenguaje (D1) se concentró en ser imperativo, orientado a objetos y con paradigmas de metaprogramación, similar a C++. Sin embargo, no estaba satisfecho con Phobos, el módulo de tiempo de ejecución de D, así como la biblioteca estándqar, por lo que la comunidad de D creó una alternativa llamada Tango. El primer anuncio oficial de Tango salió días después de la versión 1.0 de D. Tango adopta un estilo de programación diferente, apoyando la programación orientada a objetos y la alta modularidad. Siendo un proyecto comunitario, Tango estaba más abierto a contribuciones de terceros, permitiendo que se progresará más rápidamente que con la librería estándar. Ya para entonces, Tango y Phobos eran incompatibles y no se podían usar las dos bibliotecas al mismo tiempo. Esto ha llevado a una disputa entre los que apoyan una u otra biblioteca.
En junio del 2007, la primera versón de D 2.0 salió públicamente. D2 introdujo cambios interesantes en el lenguaje y añadió conceptos que ahora están en boga: closure, purity, así como soporte a los paradigmas de la programación concurrente y funcional. D2 resolvió el problema de las bibliotecas estándar separando el módulo de ejecución en tiempo real de la biblioteca estándar. D2 Tango se anunció en febrero del 2012.
Y siguiendo con la tradición, Andrei Alexandrescu sacó el libro: “The D Programming Language” en junio del 2010, lo que marcó la estabilización del lenguaje, el cual se le conoce genéricamente como lenguaje D.
D es de código abierto y evidentemente podría ser un contendiente en esta batalla por hacer el mejor lenguaje de desarrollo.

jueves, 2 de enero de 2014

M#, el nuevo lenguaje de alto nivel para programar sistemas de Microsoft

Hace tiempo que viene oyéndose por los círculos tecnófilos el nombre de Midori como el sistema operativo de nueva generación de Microsoft. Y lo que antes era un proyecto de investigación que tenía toda la pinta de transformarse en un nuevo proyecto Cairo ahora parece ser algo tangible y del que incluso hemos podido conocer detalles de su implementación.
Por ejemplo, el lenguaje de programación que se está utilizando para construir el sistema. Se trata de M# (M sharp), un lenguaje de alto nivel que está orientado a la programación del propio sistema operativo. La idea es tener un lenguaje que dé un muy buen rendimiento y sea fácil de desarrollar, siguiendo los principios de C#.
M# proviene de Sing#, el lenguaje utilizado para desarrollar Singularity, un micronúcleo desarrollado por Microsoft Research. Así lo menciona alguien que se declara antiguo empleado de Microsoft en un hilo de Reddit.

¿En lo técnico, qué mejoras trae?

M# aboga por cambiar dos aspectos de C# para mejorar el rendimiento. Por una parte, el garbage collector, componente que se encarga de recorrer las zonas de memoria ocupadas por cada programa y de liberar, en cada zona, aquellas partes que no se estén utilizando. M# se vuelve más eficiente e inteligente, sabiendo cuándo un objeto deja de ser necesario y puede ser eliminado de la memoria.
Por otra parte, también hay mejoras en el sistema de tipado, intentando afrontar un problema acuciante en los sistemas operativos actuales. Citando a mi compañero Guillermo, actualmente «los procesadores crecen a lo ancho y no a lo alto»: es decir, en vez de haber núcleos más rápidos, lo que tenemos son procesadores con más núcleos, en ocasiones optimizados y especializados para ciertos usos concretos.
Además, M# parece fomentar el uso de contratos de código para que los programas restrinjan su comportamiento a los caminos definidos por el sistema y fáciles de entender, de manera que el compilador pueda realizar optimizadores y los programas acaben siendo más robustos y fiables.
Por último, al parecer M# busca ser open source desde el primer momento. No se trata de una experiencia nueva para Microsoft: F#, la propuesta de Microsoft en programación funcional, también es open source.

¿Qué significa esto? ¿Qué sabemos de Midori?

Midori, según sabíamos hasta el momento, era un proyecto de Microsoft Research sobre un nuevo concepto de sistema operativo, totalmente distinto a lo que conocemos hasta el momento. Aunque oficialmente Midori no existe: Microsoft no ha declarado todavía nada al respecto.
Windows arrastra lastres desde el primer Windows NT, lanzado en 1993. Cada versión de Windows tiene por máxima la retrocompatibilidad casi total con todos los programas existentes para Windows. Midori parece ser el sistema operativo de nueva generación, máxime ahora que forma parte de la división de Sistemas Operativos de Microsoft, dirigida por Terry Myerson.
Además, Midori estaría desarrollado utilizando M#, que no es sino una extensión de C# y .NET (M# busca ser eficiente en tipos desde el principio, y C# es un punto de partida magnífico). Esto significa que, probablemente, Midori estaría preparado para ejecutar todas las aplicaciones desarrolladas utilizando estas tecnologías, e incluso de manera más eficiente.
No se trata de un proyecto a corto plazo, desde luego. Un proceso así no se completa de la noche a al mañana. Pero tampoco pueden dormirse en los laureles: la informática ya ha cambiado demasiado con respecto a cuando Windows tenía su apogeo. A Microsoft no le conviene dejar pasar otro tren.