¿Qué está de moda en el desarrollo de software y programación?

¿Qué está de moda en el desarrollo de software y programación?

software y programación

Si alguien hoy en día, en otoño de 2015, se preguntase ¿Qué está de moda en el desarrollo de software y programación?, la respuesta tendría que ser la programación funcional. Este paradigma de programación, muy conocida por usarse en excel de Microsoft, está causando un gran revuelo en el desarrollo de software y la programación.

Las ideas fundamentales detrás de la programación funcional son que:

  1. Los datos deben permanecer inmutables: en vez de manipular datos, debes hacer una nueva copia de los mismos.
  2. Los programas no debe tener estados. A ninguna función le debería importar ni tener en cuenta que ha sucedido en el pasado.

¿Por qué te debería importar la programación funcional?

Aquí presentamos una serie de razones por las que muchos proyectos de código abierto hoy en día apuestan por la programación funcional:

  • Permite concurrencias y paralelismos a escala masiva. Por esta razón algunos de los lenguajes de programación de mayor rendimiento son funcionales.
  • Al usar abstracciones para manejar tareas como la iteración, reduces el volumen de código al que tienes que darle mantenimiento, y en consecuencia, también reduces las probabilidades de que algo falle.
  • Desplazas el trabajo de un montón de funciones pequeñas y específicas a funciones de una jerarquía mayor (es decir, funciones que toman a otras funciones como inputs  o que tienen como resultado una función a modo de output). Esto te permite mantener el foco sobre los resultados que sobre pequeños pasos intermedios.
  • Sin un estado guardado y solo datos derivados, puedes escalar horizontalmente (con ordenadores más baratos) en vez de hacia arriba (con ordenadores más potentes). Esto facilita el hecho de disparar servidores cuando el tráfico aumenta y ponerlos en stand-by cuando el tráfico cae.
  • JavaScript, el lenguaje más popular en los últimos tiempos, está bien casada con el paradigma de programación funcional.

En conclusión, podemos afirmar que la programación funcional es una moda, pero no nueva. La diferencia es que de esta vez puede que deje de ser moda para convertirse en estándar.

Este artículo está inspirado en ese hilo de debate.

Este artículo ¿Qué está de moda en el desarrollo de software y programación? es original de Velneo.

4 claves para programar de forma rentable cambiando de actitud

icono_velneo_reflejoEn este post vamos a recoger las reflexiones sobre cómo ser rentables de uno de los consultores expertos de Velneo, Miguel Pérez Oliver -con más de 25 años de experiencia en el mundo del software-, y que lleva ya 10 años centrado en conversar con empresas de programación de todo tipo, tamaño y condición de todos los países del mundo donde se habla español. Vamos a resumir aquí las conclusiones a las que ha llegado tras miles de conversaciones con desarrolladores en pocas ideas: 4 claves para programar de forma rentable. Las empresas que llevan estás 4 claves a rajatabla suelen tener mucho éxito. Y al final todo se reduce a una cuestión de actitud, no de recetas mágicas ni grandes secretos:

  1.  Nicho, foco y replicar el modelo
  2. Ingresos periódicos
  3. La programación es solo parte del negocio
  4. Clientes educados (tiempo)

La máxima es siempre estar convencido de lo que vendes. Si crees que debes hacer instalaciones y desarrollos para trabajar en local, no vendas aplicaciones en la nube porque si no crees en la nube, ¿cómo piensas convencer a tus clientes?

Nicho, foco y replicar el modelo

Hay que ser pragmático. No vamos a hacer un Twitter ni un Facebook. Hay que ser realistas y desarrollar una aplicación de ese estilo está al alcance de unos pocos visionarios. Tenemos que buscar programar de forma práctica, buscar un modelo de negocio claro que nos permita vivir cada vez un poquito mejor, disfrutar y ser rentables para seguir a partir de ahí.

No te puedes pasar la vida programando. De nada te sirve estar todo un año programando 10 programas, comercializándolos, dando mantenimientos, soporte, etc… Puede que así ganes más dinero, pero pierdes en rentabilidad, y sobretodo, en calidad de vida. Tu vida se puede volver una angustia porque no te queda tiempo libre para disfrutar, ni para pensar en otras cosas que no sean programar.

Cuando un programador se pone a hacer un nuevo desarrollo, la fase más angustiosa es siempre la puesta en marcha de un nuevo proyecto: los bugs, los errores, las quejas del cliente, etc… Ese periodo termina pasando pero mientras estás en él es una verdadera angustia. Si hacemos 10 proyectos nuevos al año, tenemos 10 angustias al año. Si nos pasamos toda la vida haciendo desarrollos y poniendo proyectos en marcha, toda nuestra vida será una angustia. Hay que cambiar esta forma de pensar, y por eso es una cuestión de actitud. Hay que centrarse en un nicho, tener foco y replicar ese modelo. Ser pragmáticos.

Ingresos periódicos

Es muy importante establecer una política comercial que te permita ingresar dinero de forma periódica, mes a mes. No podemos estar pendientes todo el rato de las ventas, porque si estamos pendientes de las ventas lo que sucede es que cuando llega esa nueva venta, ¿qué le pasa al cliente al que le vendimos hace un año? Nos olvidamos de él. Le dejamos atrás. ¿Crees que eso es lo que se merece tu cliente? Cuando llegues a la conclusión de que tu cliente no se merece eso seguro que cuando vayas a venderle un nuevo producto pensarás en el mantenimiento, y será mucho más fácil vendérselo. Si tus clientes no apuestan por el mantenimiento a la larga es mejor que los abandones por aquellos que sí lo hagan.

La programación es solo parte del negocio

Hay que tener tiempo para dedicarle al menos 15 minutos al día a leer sobre las novedades de tu herramienta de desarrollo, el foro o el blog. Es tu herramienta de trabajo, no estamos hablando de diversión, no es perder el tiempo. Es como si un abogado no está al tanto de las nuevas reformas en una ley. Así no se puede trabajar.

Hay que dedicarle tiempo a la formación, parte a la labor comercial y otros aspectos que nos son programación y aunque seas una persona tienes que organizarte porque sino no vas a triunfar.

Clientes educados (tiempo)

Este tema es conflictivo porque estamos hablando de decirle que no a un cliente y no es fácil. ¿Cómo le vas a decir a u cliente que no te llame y que te mande un email? Bueno, pero al final esto es también un problema de actitud. Para educar a los clientes tenemos que convertirnos en “maestros del no”, aprender a decirle que no a los clientes de forma educada, razonando y todas estas consideraciones. Pero no, es no.

Para educar al cliente primero tenemos que educarnos a nosotros mismos dentro de la empresa y plantearnos varios noes:

  • no programar ni una sola línea de código que no guarde relación con el nicho al que vas dirigido y el programa que vendes en ese nicho.
  • destinar 6 horas diarias a la programación y no más, programar cansado te hace cometer errores que luego cuestan mucho tiempo y dinero.
  • solo dar soporte en casos de urgencia, pactados con el cliente de forma previa a la puesta en marcha de un proyecto.

Por otro lado hay que tener cuidado con las peticiones que te hacen los clientes una vez que el programa ya está funcionando. Cuando estás trabajando en un nicho y te diriges a varios clientes dentro de ese nicho, no te puedes permitir el lujo de que un cliente te diga pon un campo fórmula ahí o una columna aquí. Ten claro que el especialista del sector eres tú y que además el cliente no se lo merece, tu eres el que se ha especializado, el que está en nicho. Cuando un cliente te da una solución, quizás esa solución no sirva para el resto. Para no caer en este error pídele al cliente que te explique el problema, no que te de la solución. Conoce el problema, ya buscarás la solución y así te irá mucho mejor.

Este artículo 4 claves para programar de forma rentable cambiando de actitud es original de Velneo.

Lenguajes de programación más demandados en 2015

Programes o no en Velneo aplicaciones y programas de negocio, herramienta que recomendamos encarecidamente para tal fin si programas en español, es siempre interesante estar informados sobre qué lenguajes de programación están siendo demandados en la actualidad en el mundo. Para redactar este artículo me he basado en varias páginas webs que nos dan información sobre el tema y que iré enlazando a lo largo del mismo: Lenguajes de programación más demandados en 2015

Lenguajes de programación más demandados en 2015

En los dos últimos años la tendencia apenas ha variado y la tendencia del 2014 se confirma en el 2015. Aquí va un pequeño listado de tendencias que merece la pena destacar.

  • JavaScript: su uso se está disparando y todo el mundo parece necesitar un desarrollador de JS en la empresa. Su crecimiento y proyección es muy prometedor y por eso encabeza esta lista.

En relación con los Frameworks:

  • Entre las opciones para JavaScript destaca NodeJS npm

En el lado servidor de las cosas quizás merece la pena destacar:

Si hablamos de Ruby, todo queda igual:

En relación con la programación funcional, que vuelve a pegar fuerte en 2015 y que es interesante tenerlo en cuenta ya que su demanda crece progresivamente, cabe destacar:

  • El lenguaje de programación Go
  • También cabe reseñar el lenguaje de programación Julia

En otro ámbito, en el de las start-up americanas, crece la demanda de especialistas en Data Science o “ciencia de los datos” y más conocimientos de las máquinas, así que se puede citar:

  • R, el lenguaje y entorno de programación para análisis estadístico y gráfico.
  • Python

En el campo del desarrollo móvil:

  • En iOS se observa una fuerte demanda de programadores en Apple Swift, que funciona mano a mano con Objective-C. Muchas empresas están empezando a hacer uso de esta tecnología en sus productos aplicaciones móviles para iOS en los meses venideros.

En lo que se refiere a tecnologías web, para observar las tendencias puede resultar divertido ir a la web de estadísticas builtWith.

servidores web

librerías javascript

 

frameworks

 

Por último voy a incluir un par gráficos extraídos del índice Tiobe que utilizan información de los motores de búsquedas más usados como Google, Bing, Yahoo!, Wikipedia y Amazón para hacer una estimación de la popularidad de los diferentes lenguajes de programación.

  • El primero muestra las variaciones en popularidad interanual:

popularidad de los lenguajes de programación septiembre 2015

  • Y el segundo la tendencia en términos de popularidad desde el año 2002 hasta día de hoy:

Fuentes del artículo Lenguajes de programación más demandados en 2015: Quora, Tiobe, BuiltWith.

Este artículo Lenguajes de programación más demandados en 2015 es original de Velneo V7.

Las 9 tareas más difíciles para un programador

La mayoría de las personas que no son programadores asumen que el trabajo de desarrollar software es difícil -y es que lo es, pero no en la forma que se imaginan las personas que no programan software-. En muchos foros de programación se pueden encontrar comentarios sobre las tareas más difíciles para un programador. Tras repasar ese hilo y otro más antiguo de los foros de Ubuntu, he decidido hacer una recopilación de las 9 tareas más difíciles para un programador. Como conclusión general, resulta que escribir código no es una de las cosas más difíciles del trabajo de un programador de software. Si eres un desarrollador de software profesional, puedes ver a continuación cuantas de estas tareas identificas como las más difíciles de tu profesión.

Las 9 tareas más difíciles para un programador

9. Diseñar una solución

La tarea: Dados una serie de requisitos, diseñar y dar forma a la solución técnica que se tiene que implementar. Esta tarea incluye el diseño de los datos y la estructura del código, los algoritmos funcionales y el flujo de la aplicación que engloba la lógica del negocio y satisface los casos de uso del software.

El reto: Estar seguro de que diseñas una aplicación que cumple los requisitos del cliente, que les tenga sentido y que se pueda desarrollar e implementar en el tiempo requerido.

8. Hacer pruebas

La tarea: Escribir pruebas unitarias, es decir, pruebas programáticas de pequeñas unidades de código para asegurarnos de que funcionan bien. Este tipo de pruebas nos ayudan a depurar bugs desde las fases iniciales del desarrollo del software y hacen más fácil pruebas de regresión posteriores cuando haya que editar o actualizar el software. Algunas metodologías de desarrollo de software promueven que se escriban las pruebas antes de empezar a desarrollar el software, mientras que otras apuestan por hacerlo a posteriori.

El reto: Puede ser un proceso tedioso elegir qué pruebas unitarias hacer y escribir el código de las mismas, ya que siempre da la impresión de que es una trabajo adicional al del propio desarrollo de la aplicación que tenemos entre manos.

7. Redactar la documentación

La tarea: Crear documentación explicando qué es lo que hace la aplicación y como funciona. Puede incluir documentos en forma de manual o comentarios en el código. El público objetivo puede ir desde el usuario final hasta otros desarrolladores.

El reto: Puede ser una tarea que consume mucho tiempo, que puede parecer una perdida de tiempo si nadie lo va a leer. A los programadores les gusta más picar código que documentarlo.

6. Implementar funcionalidades con las que NO estás de acuerdo

La tarea: Tener que implementar una característica o funcionalidad que, por el motivo que sea, sientes que no debería ser incluida pero que el cliente, o uno de tus superiores, insiste en que así sea.

El reto: Poner a un lado tus sensaciones personales y opiniones y dedicar tiempo y esfuerzo a implementar – y dar soporte a- la funcionalidad de que se trate.

5. Trabajar con el código de otros

La tarea: Tener que dar mantenimiento, depurar o mejorar una aplicación o el código que ha sido escrito por otro desarrollador.

El reto: Intentar entender cómo funciona el código heredado e intuir qué intenciones tenía el desarrollador original. Esto es incluso más difícil cuando el desarrollador original ya no está y el código está mal escrito, mal comentado y/o documentado.

4. Tener que tratar con otras personas

La tarea: Recopilar los requisitos de los clientes, elaborar informes del estado de las tareas a los responsables, trabajar con los beta-testers de la aplicación y debatir con otros programadores sobre el proyecto.

El reto: Explicar cosas técnicas a personas que no lo son, que tu trabajo dependa de terceros y estar en desacuerdo con el personal de control de calidad y otros desarrolladores.

3. Estimar el tiempo que va a tomar una tarea concreta

La tarea: Al principio de un proyecto, intentar concretar estimaciones del tiempo que tomará concluir la tarea.

El reto: Adivinar cuanto tiempo te va a tomar algo que nunca antes habías hecho, haciendo estimaciones basados en requisitos poco específicos e intentando incluir el tiempo necesario para solucionar imprevistos.

2. Explicar a lo que me dedico (y a lo que no)

La tarea: Hacer llegar a los no programadores (miembros de tu familia, amigos, compañeros de trabajo no técnico…) lo que implica tu trabajo -y lo que no.

El reto: Que tus seres queridos no entiendan qué es lo que haces para ganarte la vida. Que todo el mundo esté todo el rato pidiéndote que les resuelvas sus problemas con los ordenadores de forma generalizada.

1. Ponerle nombres a las cosas

La tarea: Crear nombres para tus variables, procedimientos, funcionalidades, clases, objetos y componentes de la base de datos.

El reto: Incluso una pequeña aplicación o programa puede requerir el hecho de ponerles un nombre. La elección de nombres apropiados que transmitan el sentido de lo que es la cosa o de lo que hace durante todo el proceso de desarrollo y que sean concisos.

Este artículo Las 9 tareas más difíciles para un programador es original de Velneo V7.

Consejos prácticos para programadores

En los últimos 12 meses hemos procurado desde el blog de Velneo publicar artículos dirigidos a ofrecer consejos prácticos para programadores. En este post hago una recopilación de los mismos.

consejos hacer software

El hecho de que te cueste programar y desarrollar software al principio es lo que realmente te puede impedir que te conviertas en un buen programador. Personalmente mi experiencia me dice que el hecho de programar y picar código, y el diseño de aplicaciones le cuesta mucho a un programador medio. Se debe a que la mayoría en su día a día en el trabajo no pican el código suficiente ni realizan muchos desarrollos. Por cierto, hay una gran cantidad de consejos para ser mejor programador pero yo me ciño a mi lista, la cual sigo y me ha ayudado siempre: 10 consejos para mejorar destrezas de programación y ser mejor desarrollador.

Si siempre te han interesado los ordenadores, te encantan tanto los sistemas de software complejos como las nuevas tecnologías y quieres llegar a ser un buen desarrollador de softwaret, te vamos a ayudar y te dejamos aquí información importante y esencial en relación con la mejora general de las habilidades como desarrollador de aplicaciones de software: ¿Cómo mejorar en mi oficio de desarrollador de software?

En múltiples ocasiones, las personas que se acercan hasta nuestra web nos plantean algunas dudas a través de alguno de nuestros canales de comunicación, bien el blog, a través de lo foros o en las redes sociales. Pensamos que es interesante compartirlas con todos pues podrían servir de respuesta a otros. Una de las preguntas más recurrentes tiene respuesta en este post: ¿Cual es el mejor programa para crear apps sin saber código?

La contratación de un desarrollador o programador senior para tu startup es un asunto de “vida o muerte”. Èsta es la persona sobre cuya visión creativa y saber-hacer tecnológico pende el éxito de tu producto. Éste es el líder que dirigirá a los ingenieros que contrates en adelante, encargado de sacar el máximo provecho de sus cualidades en busca de innovación. Y será esta persona la que determinará, mediante su habilidad y ambición, si tu producto destaca o si es solo un poco de ruido más en una escena tecnológica abarrotada de voces chillonas: 5 Formas de Encontrar un Desarrollador Senior para Tu “Startup”

Si lo que buscas son 10 consejos breves para programar de forma exitosa, puedes visitar el siguientes post: 10 claves para programar con éxito

El proceso de desarrollo de un nuevo producto de software también se conoce como SDLC -ciclo de vida del desarrollo de software- (siglas en inglés de software development life cycle) y puede considerarse una subcategoría del ciclo de vida de desarrollo de sistemas. Existen varios modelos de SDLCs y se pueden estandarizar bajo la ISO/IEC 12207, la cual enumera todas la tareas que deben formar parte del desarrollo y mantenimiento de software. El ciclo de vida del desarrollo de software

Este artículo Consejos prácticos para programadores es original de Velneo V7.

Calidad del software

Calidad de software, agilidad y terror son los ingredientes de la ponencia de Javier Garzás en el último evento Life is soft. Descubre como evitar que tu software se convierta en un proyecto zombie implementando metodologías y consejos de desarrollo que se preocupan por la calidad del software.

Este artículo Calidad del software es original de Velneo V7.

13 pesadillas para programadores

hockey_mask

Para la gran mayoría de personas las cosas que les causan pesadillas son bastante estándar: fantasmas, arañas, ser perseguidos por maníacos homicidas en máscaras de hockey, etc… Pero para otros sus peores temores nacen de cosas menos convencionales.

Tomemos, por ejemplo, a los desarrolladores de software. Si le preguntas a un programador de software cual es su peor pesadilla, probablemente tenga poco que ver con brujas o gatos negros y más con la tecla del punto y coma que no funciona o un producto de Microsoft. Tras analizar diversos foros sobre las mayores fuentes de preocupación para programadores, aquí describiremos cuales son las 13 pesadillas para programadores más comunes.

1. No puedo resolver mi duda usando Internet

Páginas web del estilo Stack Exchange se han convertido en herramientas fundamentales en la caja de herramientas de un desarrollador de software. Por supuesto que también hay muchísimos otros foros para desarrolladores a los que recurrir para buscar ayuda. Nada le hiela más la sangre a un programador que quepa la más remota posibilidad que esta aparentemente infinita fuente de conocimiento para programadores no pueda responder sus dudas.

Citas:

“Ir a Stackoverflow y ver el post de alguien con tu misma pregunta colgada desde hace un año y sin respuestas.” Jorge Irun

“!Ver que una respuesta dada por buena en el foro no me funciona!” Ramchand Rajasekaran

2. Las teclas más importantes del teclado dejan de funcionar

No hace falta ser muy listo para darse cuenta de que el teclado es muy importante para un desarrollador. Pero no todas las teclas son creadas -ni valoradas por los desarrolladores- de igual forma. Algunas teclas se usan muchísimo más que otras por algunos lenguajes de programación en concreto, como el punto y coma en JavaScript, Perl y Objective-C. A los programadores les encantan los atajos de teclado y usan muchísimo más el teclado que el ratón, para ahorrarse tiempo y prevenir lesiones. No resulta sorprendente entonces que los desarrolladores de software se despierten en medio de la noche con sudores fríos soñando que su tecla preferida del teclado ha dejado de funcionar, o lo que es peor, ha desaparecido.

Citas:

“Mi peor pesadilla es cuando deja de funcionar la tecla del punto y coma.” Ali Akbar

“Escribir un montón de lineas de código para descubrir que las teclas de control han dejado de reaccionar…….” Nikesh Shetty

3. Internet está caída -o desaparecida-

Un tipo de pesadilla menor es que el foro de una herramienta en particular esté caído o en mantenimiento y no se pueda resolver una duda, pero muy distinto es cuando toda la red está caída y no se puede acceder a Internet, punto. Porque después de todo, además de acceder a los foros, la red es como un gran baúl lleno de muchas otras cosas útiles como software de código abierto y snippets de código.  Por no decir lo difícil que sería el acceso a servidores remotos o en la nube, la programación en equipo o tu servicio favorito para hacer streaming de música online si Internet de repente se cae… Así que si en verdad quieres acongojar a un programador, grítale “!NO HAY INTERNET!”. Asegúrate de tener un desfibrilador a mano.

Cita:

“Si Internet y Google desaparecen tendríamos que volver a una época arcaica de aislamiento y oscuridad. Estaríamos atascados sin saber muy bien qué hacer si nos topamos con un bug.”Thoriq Firdaus

4. Un bug crítico que no soy capaz de reproducir

Para arreglar un bug, un desarrollador tiene que antes ser capaz de replicar las condiciones que lo ocasionaron en un entorno de desarrollo o de pruebas. Después, si hay suerte, se puede diagnosticar y arreglar el error antes de ser implementados en un entorno de producción. Muchos desarrolladores temen a los bugs que solo ocurren aleatoriamente y no se pueden replicar en un entorno controlado. Ese dichoso bug se convierte en muy crítico el día que te hace quedar mal delante de un cliente muy importante. Esto es una verdadera pesadilla para un programador.

Citas:

“… bugs que solo hacen aparición en demos ante muchos clientes o clientes importantes.” Jeremy Friesner

“Un pantallazo azul que no se puede replicar en la empresa pero que sucede todos los meses en casa del cliente.” Joe Wezorek

5. Falta de buena -o de cualquier tipo de- documentación

Sentarse a entender un código que ya existe sin la ayuda de una buena documentación o comentarios en el código es complicado. Hacerlo sin documentación o comentarios en el código es incluso más fastidiado. Esto no solo es aplicable al código escrito por terceros que hereda un programador, sino también al código que un mismo programador ha escrito en el pasado y que no ha documentado bien. El código indocumentado, no importa quien lo haya picado, siempre es una verdadera pesadilla.

Citas:

“Hacer el mantenimiento de software viejo y no documentado. Literalmente tengo pesadillas con eso.” Sam Sartor

6. Jefes y directores del infierno

A nadie, ni a programadores ni a nadie, les gusta tener superiores entrometidos o incompetentes. A mayores, los desarrolladores de software sienten especial aversión por gestores no técnicos que meten las narices en su código. Aquellos directores que prometen cosas que no se pueden hacer, los que infravaloran el tiempo que requiere picar el código para un proyecto y los que toman decisiones tecnológicas también aparecen de forma recurrente en las pesadillas de los programadores que pegan gritos en mitad del sueño.

Citas:

“Para mi lo peor es un gerente “dolor de muelas” que se cree que está sobre-cualificado y espera poder cumplir con las expectativas de los clientes -cualesquiera que sean- antes de tiempo. Esos que se creen que la programación es cosa de minions y que el código aparece mágicamente por el aire.” Rachit Agrawal

 7. Limpiar y adecentar el código de otros

A casi ningún programador le gusta tener que trabajar sobre el código de otro; después de todo, el código de otro programador nunca podrá ser tan bueno como el de uno, ¿no? ;). Incluso el código de un tercero bien documentado puede ser un dolor de cabeza. Que te pida hacer un debugging, refactorizar, o modernizar y adaptar el código que otro ha picado, probablemente hace ya muchas lunas, hará que el corazón de cualquier programador empiece a bombear sangre -y no precisamente por cosas buenas-.

8. El cambio en los requisitos de un proyecto

Independientemente de como se presente en las formas, a los desarrolladores de software les gusta tener los requisitos de la aplicación que van a programar claramente delimitados y que se mantengan inamovibles. En la práctica, esos requisitos sí varían sobre la marcha, y aveces de forma justificada, y otras por tener malos responsables de proyectos, y otras por quejas o interferencias de mandos superiores o de los propios clientes. Sea cual sea la razón, el temor a requisitos cambiantes -especialmente en el último minuto- siempre ronda por el alma de los desarrolladores. 

9. Código que desaparece para siempre

No importa cuantas horas meta un desarrollador en programar software, todo será inútil si el código desaparece por sorpresa. El código puede desaparecer de forma inesperada por varias razones, que van desde olvidarse simplemente de guardar un archivo hasta fuerza mayor  divina o bugs maliciosos incomprensibles y desafortunados. Cualesquiera que sea la causa, y a pesar de todo el cuidado y el mimo que se ponga, los programadores siempre viven aterrados pensando que todo su esfuerzo, todas esas horas de algoritmos y funciones pueden desvanecerse sin dejar rastro. 

10. Internet Explorer

Los programadores siempre sienten aversión y dolor de estómago por algunas tecnologías. Por ejemplo, los desarrolladores webs temen tener que programar cosas que funcionen en Internet Explorer. A pesar de seguir siendo uno de los navegadores más populares, IE es inmisericorde con los desarrolladores web. Y para empeorar las cosas, las antiguas versiones, que eran incluso más despiadadas y tenían aun más usuarios, necesitan más soporte que las versiones más modernas y amigables. Digamos que si Jason Vorhees de las películas de Viernes 13 tuviese que atemorizar a un grupo de desarrolladores web, su máscara sería el logo de IE. 

11. Lesión o dolor físico

La programación no es un trabajo físico, pero como en muchas otras profesiones que requieren picar datos en un ordenador todo el día, sería difícil hacerlo sin brazos, manos y dedos. Además cualquier cosa que afecte negativamente la visión o la habilidad general para pensar de forma lógica sería un problema. Naturalmente, por lo tanto, una pesadilla típica para desarrolladores de software sería la inhabilidad de usar o la pérdida total de una o más partes vitales del cuerpo.

12. Mi bug lesiona, hiere o mata a alguien

Ningún desarrollador de software quiere ser el causante de un bug. Pero no todos los bugs son igual de desastrosos. Algunos son tediosos pero inofensivos. Otros le pueden suponer un coste a la empresa o al cliente e incluso puede suponer perder el puesto de trabajo al desarrollador de software responsable del mismo. Pero el peor escenario en temas de bugs para un desarrollador se da cuando el bug implica hacer daño físico o incluso la muerte de alguien… 

13. Fallos de segmentación

Una pesadilla muy habitual entre los programadores es toparse con un fallo de segmentación. Este error se produce por una violación de acceso a la memoria, es decir, intentar acceder a memoria restringida o llevar a cabo una acción restringida. Normalmente en estos casos la unidad de acceso a la memoria notifica al sistema operativo, que a su vez notifica el proceso ofensor que, mayormente, termina con el programa colgado y en un dolor de muelas para el desarrollador que tiene que intentar dar con la causa del problema. Por eso esas palabras, fallo y segementación, juntas son una pesadilla para un programador. 

 Nota: este artículo es una traducción de este post.

Este artículo 13 pesadillas para programadores es original de Velneo V7.

Life is Soft 2015 evento en Madrid para desarrolladores de aplicaciones

¡Ya está aquí!, el próximo jueves 12 de marzo de 2015, en Madrid tienes la oportunidad de participar en el evento anual de desarrollo de software empresarial, Life is soft.

Este año, Life is soft 2015 va A +.

PageLines- jesus_arboleya_lis2012.jpg

Tendrás ponencias, en formato TED, sobre calidad de software, aplicaciones rentables en la nube, aplicaciones que integran QML, DHTML, te enseñaremos la plantilla empresarial vERP para que dispongas de tu propio ERP y muchas más temáticas.

Es una oportunidad única para convivir e interactuar con el equipo de Velneo y su comunidad, participar en las diferentes mesas redondas temáticas, conocer los diferentes casos de éxito de la comunidad e intercambiar experiencias e inquietudes con otros desarrolladores.

¡¡Date prisa porque quedan muy pocas plazas presenciales!! Regístrate ahora

Continuamos con la confianza depositada en nosotros por la Universidad Politécnica de Madrid para permitirnos realizar el evento presencial en sus instalaciones.
Este año será mucho más potente y más técnico, algo que ya nos solicitaron nuestros clientes.

Para ello, el evento estará dividido en dos partes. Por la mañana, realizaremos unas jornadas de networking con mesas temáticas sobre estrategia, desarrollo y comercial, una mesa redonda con casos de éxito de clientes y la entrega de un premio al mejor forero de la comunidad Velneo. Este evento será exclusivamente presencial.

Por la tarde, empezarán las ponencias sobre diferentes temas relacionados con las empresas de software empresarial donde intercalaremos ponencias puramente técnicas con grandes novedades de esta versión y de las posibilidades que ofrece Velneo para integrarse con otras tecnologías. Este evento será retransmitido por streaming para toda España y la comunidad Latinoamericana.

Puedes consultar la agenda detallada del evento aquí.

Este año tendré el placer de compartir escenario con mi amigo Nicolás Osuna para presentaros las importantes novedades del gran componente de la plataforma Velneo vERP, la plantilla de código abierto con la que puedes construir tu propio ERP.

Te esperamos y en caso de que no puedas asistir al evento presencialmente recuerda que podrás asistir al mismo con la transmisión online que realizaremos.

The post Life is Soft 2015 evento en Madrid para desarrolladores de aplicaciones appeared first on Lógica mente Velneo V7.

9 problemas que todo desarrollador debe afrontar

El camino que nos lleva desde el nacimiento hasta la muerte está lleno de elecciones sobre dónde trabajar y qué tipo de trabajo hacer. En ocasiones el mundo es bueno y nos da algo de información para poder decidir. Hoy en día los desarrolladores tienen más posibilidades de poder exigir cosas en su trabajo dado que hay más demanda de sus servicios.

Ya seas un autónomo o un trabajador por cuenta ajena que merodea por las ofertas de trabajo, sabes que los anuncios pidiendo programadores abundan. Cada oferta de trabajo suscita innumerables dudas de cómo encaminarse profesionalmente en el mundo de la programación. Para muchas personas todo esto supone un territorio totalmente desconocido ya que han optado por emplearse a través del software y los ordenadores para satisfacer el deseo de trabajar, sin tener una clara vocación por ser desarrollador.

Las siguientes nueve preocupaciones son claves a la hora de trazar el camino de tu carrera profesional. Algunas afectan al currículo. Otras ofrecen oportunidades para el desarrollo profesional en sí mismas. Y luego hay una serie de cuestiones que versan sobre cómo capear los problemas laborales específicamente relacionados con las TIC. El hecho de dedicarle tiempo a pensar en estas cosas es algo más que simplemente estar preparado para responder sobre ellas con alguien te las pregunte. Es el primer paso para sacarle el máximo provecho a tus intereses y habilidades.

¿Te dará una certificación ventaja en el mercado laboral?

Un dilema muy común al que se enfrentan los desarrolladores preocupados por su carrera profesional es cuánta atención deben prestarle a las certificaciones. Después de todo, los empleadores quieren averiguar si realmente sabes lo que dice saber, y las empresas tecnológicas siempre están ofreciéndose voluntarias para ayudarles a determinarlo con programas de certificación.

Los programas de certificación van dirigidos a enseñar una tecnología determinada, y luego evaluar el grado de competencia sobre lo que han enseñado. Ponen el foco en soluciones prácticas, no en enigmas teóricos como en la mayoría de las universidades. De esta forma, resultan atractivas para empresas en busca de candidatos veteranos para determinar cual es su capacidad de dar soluciones reales a problemas reales.

Sin embargo, la pregunta clave para un desarrollador es saber si existe o no una demanda real por una certificación en concreto. La mayoría de las tecnologías de vanguardia son demasiado nuevas para poder evaluar a alguien sobre ellas, así que los empleadores lo que hacen es buscar otras pruebas que demuestren su dominio. El verdadero mercado de las certificaciones siempre estará en herramientas de base como la ejecución de una base de datos Oracle o el mantenimiento de una flota de formularios en Microsoft. Las empresas que dependen de Oracle o Microsoft pagarán más a personas que ya han demostrado tener la destreza. Cuando tu certificación y las necesidades del empleador están alineadas, todo el mundo está contento.

Pero lo cierto es que los desarrolladores necesitan elegir bien. Preparar exámenes de certificación toma mucho tiempo, y muchas de las preguntas versan sobre conocimientos triviales. Yo he hecho varios exámenes sobre Java stack y me he dicho a mi mismo: saber esta respuesta es responsabilidad de Eclipse, no mía. Windows XP era genial hace 10 años, pero hoy no sirve de nada a no ser que la empresa para la que trabajes se quede con XP hasta el día del juicio final. Muchas veces existen certificaciones distintas en función de las versiones del software…

¿Cuál es el valor verdadero de una licenciatura en Informática?

Si ya es difícil discernir si merece la pena obtener una certificación profesional para una tecnología en particular, resulta casi imposible decidir si merece la pena invertir en una licenciatura universitaria tradicional. Todo lo que hay que hacer es echar un ojo a líderes como Steve Jobs, Michael Dell, Bill Gates, o Mark Zuckerberg para darse cuenta de que una licenciatura universitaria no es un requisito imprescindible para cambiar el mundo.

Sin embargo es difícil acabar con las viejas tradiciones. Algunas empresas insisten en tener una licenciatura o incluso un máster porque es una forma fácil de filtrar y hacer criba de Currículos, o también porque dan una idea sobre cualidades intangibles de los candidatos como un profundo interés y versatilidad a la hora trabajar con ordenadores. Cualquiera que sea la razón, un gran número de personas siguen pensando que es fundamental tener un título, así que los desarrolladores con el ojo puesto en las ofertas de empleo se encuentran con la disyuntiva de acumular títulos y diplomas una y otra vez.

El valor práctico de una licenciatura universitaria es controvertido. Algunos encuentran que los temarios universitarios versan sobre cuestiones demasiado teóricas sobre algoritmos que no son significativos en el entorno laboral. Los profesores están más interesados en pensar si el tiempo de ejecución puede predecirse con un polinomio o con una función exponencial.

Otros creen que este entendimiento abstracto de algoritmos y estructuras de datos es esencial para hacer un buen trabajo ante nuevos retos y desafíos. Los lenguajes de programación vienen y van, pero un profundo entendimiento permanece hasta la jubilación.

¿Deberías especializarte o abarcar muchos lenguajes de programación?

Un buen desarrollador puede programar en cualquier lenguaje porque los lenguajes al final son declaraciones if-then-else envueltos en funcionalidades ingeniosas para ser re-utilizables. Todos los desarrolladores al final terminan teniendo un lenguaje preferido con un conjunto de fórmulas y construcciones que se les quedan grabadas a fuego.

El verdadero reto está en elegir el mejor lenguaje para el mercado. La mayor demanda será en aquellos lenguajes que forman los cimientos de las grandes pilas. Java, C++, PHP, y JavaScript siempre son buenas alternativas.

Pero los nuevos lenguajes como también seducen. No solo resuelven los problemas que nos volvían locos de los viejos lenguajes, sino que tampoco nadie ha sido capaz de expresar con palabras las nuevas irritaciones que causan.

Los empleadores a menudo están igual de titubeantes a la hora de comprometerse con un nuevo lenguaje de programación. Por un lado, les seducen las promesas de que un nuevo lenguaje acabará con los viejos problemas, pero también se muestran escépticos y prudentes ante posibles modas pasajeras. A la hora de comprometerse tecnológicamente lo hacen por un tiempo indeterminado, incluso varias décadas, y deben elegir sabiamente para evitar encadenarse a un lenguaje que en su día estuvo de moda y que ya nadie usa ni conoce.

Para los desarrolladores la mejor opción es obtener pericia en un lenguaje con una demanda creciente. Antes de que saliera el iPhone, Objective-C era un lenguaje que se usaba para escribir aplicaciones nativas para el Mac que se estaba desvaneciendo. Luego cambiaron las cosas y la demanda de Objective-C explotó. La apuesta que cada desarrollador debe hacer es jugársela por un lenguaje que con el tiempo quizás se muera o crezca.

¿Deberías contribuir a proyectos de código abierto?

El clásico estereotipo de los proyectos de código abierto es que los organizan puristas descuidados que le dan la espalda a cualquier cosa que tenga que ver con dinero. Este estereotipo se va desmontando a medida que los programadores se están dando cuenta que tener experiencia en los principales proyectos de código abierto al final se convierte en un gran activo para muchos empleadores e incluso una profesión en si mismo.

La ventaja más obvia de trabajar en un proyecto de código abierto es que puedes compartir tu código con un empleador o demandante de empleo potencial. No hay cláusulas de confidencialidad ni restricciones propietarias que no te permitan compartir tu código con empleadores potenciales. Cualquiera puede verlo y si has alcanzado cierto estatus en la comunidad demuestra además que sabes trabajar en equipo y tienes conocimientos y capacidad para contribuir a un proyecto en marcha. Son destrezas muy valoradas que muchos programadores nunca llegan a desarrollar.

Algunos de los proyectos de código abierto más famosos forman parte ahora del código de aplicaciones empresariales, así que hay empresas buscando desarrolladores que forman parte de la comunidad alrededor de la cual depende su aplicación. Un gerente en una gran empresa de servidores me dijo una vez que no podía permitirse contratar Linus Torvalds, pero que necesitaba alguien con conocimiento profundo de Linux. Se fue a echar un vistazo al proyecto Linux y contrató a gente que conocía a Linus Torvalds. Si en el proyecto se encontraba intercambios de correos entre Torvalds y un programador X, el gerente le llamaba.

Muchos proyectos de código abierto necesitan de soporte, y esto también puede ser una especie de segundo trabajo que para muchos termina siendo su profesión a tiempo completo. A las empresas les resulta más barato adoptar una tecnología de código abierto y contratar a unos cuantos consultores técnicos para hacer que funcione en vez de adquirir software propietario.

Los programadores más hábiles tambien le dedican tiempo a proyectos de código abierto desde una edad muy joven aportando código. Pueden así trabajar en proyectos de vanguardia porque son molones. Si el proyecto va y se convierte en el próximo Hadoop, Lucene, o Linux, serán capaces de convertir ese experimento en un trabajo y, muy probablemente, en una profesión duradera.

¿Cómo gestiono el hacerme mayor?

¿Qué es lo que quiere cualquier empleador? Un programador soltero de 21 años licenciado para tarbajar mil horas y crear grandes cosas. ¿Y qué tal un de 22 años con un año de experiencia? Bueno, quizás. ¿Hay muchos jóvenes veinteañeros disponibles?

Una de las grandes, y muchas veces innombrables, reglas de la programación es que los gestores tienen ideas muy cerradas sobre la edad apropiada para el trabajo. No es que los gerentes quieran discriminar,-y no es que los humanos quieran cambiar al volverse mayores-, pero es que lo hacen. Así que todo el mundo se aferra a los estereotipos aunque sean contrarios a la ley.

Este es el más obvio en el mundo hiper-competitivo de las startups tecnológicas, donde la actitud de trabajo es como en la NBA. Si te atascas al final de la licenciatura, no eres lo suficientemente especial. Este mundo premia a las personas que se tiran muchas horas haciendo cosas de manera obsesiva. Les gusta la juventud, y no resulta extraño escuchar historias de como las empresas de capital-riesgo dejan de lado a todos los que no tienen veinti-tantos.

La buena noticia para los programadores es que otros empleadores prefieren personas con más edad, más curtidos que ya saben tarbajar en equipo. No son los trabajos guay y molones que salen en la prensa, pero sí están bien-remunerados y resultan satisfactorios.

Los programadores más habilidosos se miden compitiendo contra la competencia. Algunos puestos son para esas personas que se quedan programando toda la noche como posesos, y los programadores con más edad con familias ya ni se deben molestar en competir por los mismos. Otros requieren experiencia, y los jóvenes desarrolladores estrellas del rock se deben mantener al margen de jefes que buscan estabilidad, no brillo ni desparpajo.

¿Cuánto importa el lugar donde trabajas?

Si estás dispuesto a montar todas tus posesiones en la parte trasera del coche y moverte, lo único que importa del sitio donde trabajas es si te gusta el menú del día del sitio más cercano. Buena comida y un buen entorno es lo único que importa.

Pero dónde buscar tu próximo trabajo es una pregunta difícil cuando no puedes coger y marchar a cualquier parte. Si tienes una familia o cualquier otra razón que te impidan ser un nómada de la programación, tienes que pensar en un lugar de mucha estabilidad antes de comprometerte con cualquier empresa.

Muchos programadores en Silicon Valley van moviéndose de startup a startup. Si una no funciona, hay otra montándose en este mismo minuto. Hay bastantes ofertas en otras empresas, y eso hace que encontrar nuevos desafíos sea más fácil.

Por esta razón a algunas empresas les resulta difícil atraer talento a regiones donde solo hay una empresa dominante. Si te mudas a Oregón o Washington y el trabajo no sale bien, te tienes que volver a mudar.

¿Puedes elegir un nicho para evitar el achazo de la deslocalización?

Últimamente los programadores han empezado a especializarse en capas específicas. Algunos son genios de los interfaces de usuario. Otros entienden de particiones y arquitectura de datos.

El creciemiento potencial de una profesión en una capa específica de la programación debe siempre valorarse, en particular en relación con su vulnerabilidad frente a la deslocalización. Algunos sugieren que los GUI dependen de la cultura, así que el riesgo de sufrir deslocalización en este ámbito es menor.  Otros piensan que la mejor opción es pillar la gran ola de los repositorios de big data porque cuando sube la marea todos los barcos flotan.

Aunque el cambio es una constante en las TIC, no es una buena idea coger todas las olas. Si tienes un sentido de la estética lamentable, no intentes convertirte en una estrella del rock de las GUI. Tampoco tendría mucho sentido venderte como un genio de la big data si te resulta confuso un libro de texto sobre estadística.  Hay ciertos límites de hacia donde puedes maniobrar en tu vida profesional, pero si hay formas para de adaptarse al cambio y ser inmune al fenómeno de la deslocalización.

¿Debería convertirme en autónomo y ser programador freelance?

Un dilema profesional cada vez más común para los programadores es si quedarme en mi puesto a tiempo completo trabajando como empleado por cuenta ajena o dar el salto y trabajar por cuenta propia como autónomo. Muchas empresas, especialmente las más grandes, están encantadas de trabajar con autónomos porque les facilita mucho la vida en términos de planificación a largo plazo, ya que les permite coger nuevos proyectos sin levantar la ira de los administradores que están todo el día contando cabezas y viendo gastos de personal.

A nivel práctico lo más importante es hacer que te cuadre tus gastos de seguridad social y tu prestación cuando te jubiles. Muchos autónomos recurren a planes privados una vez que el les va bien aunque muchos otros encuentran todo esto muy engorroso y les da dolor de cabeza el simple hecho de pensar en ello. En verdad es engorroso al principio pero una vez que ya tienes un plan claro, es bueno saber que tienes eso cubierto y que solo tienes que buscar clientes para poder ceñirte a los pagos.

Otro aspecto más importante es saber en verdad que es lo que te gusta hacer. Los trabajadores por cuenta ajena son perfiles más conservadores y les gusta la responsabilidad de que las cosas funcionen y sigan su curso. Los programadores freelance se caracterizan por hacer cosas nuevas y resolver problemas y se les contrata solo cuando se les necesita. Es difícil generalizar, pero mayormente cuando ya llevas años en una empresa de desarrollo acabas siendo encargado de mantenimiento de software más que otra cosa.

Por esta razón, los programadores freelance tienen la libertad profesional de poder especializarse en tecnologías concretas mientras que los trabajadores por cuenta ajena se especializan en hacer que los desarrollos sigan funcionando. Ambos perfiles se pueden vender a sí mismos como expertos en Oracle o Microsoft o Lucene, pero los empleados son los encargados de hacer que los proyectos estén listos para funcionar porque el jefe lo necesita para el viernes que viene.

Dependiendo de la cultura del empleador, esta forma de trabajar puede suponer dos cosas: coger mucha experiencia como trabajador o una alta probabilidad de prestar mantenimiento a software de empresas desfasado durante demasiado tiempo para un desarrollador con otras inquietudes.

Hay trabajo mas allá de la tecnología…

A muchos programadores se les olvida que hay muchos puestos de trabajo en empresas que poco tienen que ver con la tecnología. Lo facil es dar por hecho que todos los desarrolladores trabajan para empresas tecnológicas.

Un desarrollador inteligente debe darse cuenta que elegir un empleador que no es tecnológico puede brindar unas posibilidades profesionales únicas. Hoy en día casi cualquier empresa necesita trabajadores con buen dominio informático y un plan para sacarle el máximo partido a los sistemas informáticos que tienen implementados. La fuerza de venta necesita software para seguir la pista de clientes potenciales, los almacenes necesitan software para controlar la mercancía. En la mayoría de los casos tiene que haber alguien que personalice estas aplicaciones para que se adapten a las necesidades de estas empresas.

Entender plenamente la tecnología y el negocio de una empresa es uno de los principales argumentos en contra del outsourcing. El conocimiento de muchas herramientas famosas se vuelve algo fácilmente vendible, y ello hace que crezca la deslocalización de ese tipo de mercados lo que obliga a competir contra precios mucho mas bajos. Pero si conoces bien dos o mas aspectos de un negocio como programador eres difícil de reemplazar.

La clave de esta cuestión es saber cuanto estas dispuesto a aprender sobre el negocio, sea cual fuere. Si solo quieres hablar de punteros y estructura de datos, quedare en la empresa TIC. Pero si eres curioso por naturaleza sobre como funcionan los negocios mas allá del software, ten en cuenta que hay demanda de trabajadores como tu en otros sectores cambien.

Nota: este post es una traducción de este artículo.

Articulo relacionado: 16 años creando software, Quieres ofrecer tu propio ERP, Estrategias para crear software, Como mejorar en mi oficio de desarrollador de software

Este artículo 9 problemas que todo desarrollador debe afrontar es original de Velneo V7.

Organiza los subformularios con un combobox

VITAMINA – 14

Planteamiento de la necesidad

Hay ocasiones en las que nos encontramos con la necesidad de incorporar en el separador de un formulario un numero elevado de subformularios, además es habitual que los textos de las pestañas no sean cortos para poder describir con precisión su contenido. En estos casos la interfaz de la aplicación plantea un problema de usabilidad al usuario final ya que dependiendo de la resolución de su pantalla es posible que no tenga a la vista de forma directa todas las pestañas por lo que le resultará más complicado acceder a una de las ocultas. Incluso debemos tener en cuenta que la organización de pestañas horizontalmente resulta más difícil de leer cuando el número de pestañas es elevado.

Formulario con muchas pestañas con la interfaz a mejorar

Objetivo a conseguir

Con el fin de mejorar la usabilidad de la aplicación para el usuario final vamos a intentar sustituir las pestañas por una lista de opciones ubicada en un control de tipo combobox. De esta forma el usuario tendrá la posibilidad de acceder directamente a cada una de ellas e incluso las opciones podrán tener textos largos más descriptivos, además del correspondiente icono.

Formulario en  ejecución con interfaz de subformularios sincronizados con combobox

Piezas de la solución

Para conseguir programar una solución práctica y sencilla con un código fácilmente reutilizable vamos a crear un formulario que contenga solo 2 subcontroles: El primero que estará situado en la parte superior será el combobox (MEN_CFG) que contendrá las lista de opciones (subformularios), debajo ubicaremos un control de tipo pila de formularios (FRM_CFG) que será el contenedor de todos los subformularios que el usuario tendrá visibles.

Formulario en edición con el control combobox y la pila de formularios sincronizada

Combobox sincronizado con la pila de formularios

La idea se basa en que solo nos tengamos que preocupar en añadir subformularios al control pila de formularios en el orden que deseemos aparezcan en el control combobox que hará de menú. A partir de ahí, al ejecutar la aplicación el código que vamos a ver a continuación se encarga de leer los subformularios de la pila y añadir al combobox los elementos correspondientes basados en los nombre de los objeto formulario incrustados en la pila.

Realmente no se necesita nada más porque el orden de elementos del combobox y el de los subformularios en la pila es el mismo, por lo que cuando el usuario selecciona un elemento del combobox, la posición de ese elemento nos sirve para conocer el índice del subformlulario que debemos activar. De la misma forma podemos marcar como seleccionado el elemento del combobox que se corresponda con el formulario en curso de la pila, es decir que se garantiza la sincronización en ambas direcciones.

Otro aspecto a tener en cuenta de esta solución es que contempla los puntos de inserción que serán totalmente funcionales, por lo que la personalización de estos controles para incluir nuevos formularios es realmente sencillo, ya que una vez incluido el subformulario a través del punto de inserción el elemento se incorpora automáticamente al combobox igual que el resto de formulario incrustados por el programador directamente en el control pila de formularios.

2 conexiones y 2 manejadores de evento para controlarlo todo

Para programar esta vitamina necesitamos crear 2 manejadores de evento y sus correspondientes conexiones de evento:

Conexión de evento OnShow formulario para carga del combobox
Manejador onShow sincornización combbox y pila de formularios

Manejador de evento CAR_COM_BOX

/**
 * Devuelve el icono de un formulario
 *
 * @param {VObjectInfo} formulario Objeto de la clase VObjectInfo del formulario
  * @return {VImage} icono Objeto de la clase VImage con el icono del formulario
 */
var iconoFormulario = function (formulario)
{
	if (formulario)
	{
		importClass("VImage");
		var icono = new VImage();
		var iconoIdRef = formulario.propertyData(6).replace("@", "/");
		icono.loadResource(iconoIdRef);
		return icono;
	};
};

// ------------------------------
// Cargar formularios en combobox
// ------------------------------

var controlComboBox = theRoot.dataView().control("MEN_CFG");
var controlPila = theRoot.dataView().control("FRM_CFG");

// --------------------------------------------------------------------
// Leer los subformularios  y dar de alta los registros en el combobox
// --------------------------------------------------------------------

// Limpiamos el combobox antes de cargarlo
controlComboBox.clear();

var numFormularios = controlPila.count;
for (var numFormulario = 0; numFormulario < numFormularios; numFormulario++)
{
	var formulario = controlPila.form(numFormulario);
	var nombre = formulario.objectInfo().name();
	var icono = iconoFormulario(formulario.objectInfo());
	controlComboBox.addItem(icono, nombre, numFormulario);
};

// Marcamos el primer elemento como seleccionado
controlComboBox.currentIndex = controlPila.currentIndex;

Es muy importante cargar los elementos del combobox en el mismo orden es que están declarados los formularios en el control, y más aún teniendo en cuenta que podemos usar puntos de inserción.

La última línea del script se encarga de dejar seleccionada la líneas del combobox que se corresponde con el formulario abierto, esto es necesario tanto para la carga inicial como sobre todo si cargamos el combobox en el OnShow, ya que la primera vez estará cargado el primer formulario de la pila, pero si salimos de la pestaña y luego regresamos el formulario que veremos será el último seleccionado, y como en ese punto recargados el combobox es necesario volver a posicionarlo. Si no queremos que se cargue en el OnShow podemos hacerlo en la conexión de evento Post-inicializado, perdiendo dinamismo y ganando tiempos de ejecución ya que se solo se carga la primera vez.

Otro punto a tener en cuenta en el script es que añade al combobox el icono que se corresponda con la propiedad icono declarada en cada uno de los formularios añadidos a la pila. Para que el combobox quede homogéneo o bien le ponemos icono a todos los formularios o a ninguno.

Conexión de evento ítem de cambio seleccionado en el combobox
Manejador de cambio de elemento seleccionado en el combobox

Manejador de evento CAR_FRM_SEL

// --------------------------------
// Abrir el formulario seleccionado
// --------------------------------
var controlComboBox = theRoot.dataView().control("MEN_CFG");
var controlPila = theRoot.dataView().control("FRM_CFG");
controlPila.setCurrentIndex(controlComboBox.currentIndex);

A diferencia de lo que hacíamos en la vitamina 13 con el listbox aquí no hemos incluido en la última línea el código para establecer el foco en el formulario de la pila, ya que esto facilita la navegación por el combobox a través de flechas o escribiendo las primeras letras de la opción que queremos disparar.

Código reutilizable

Lo único que tenemos que hacer para utilizarlo en otro formulario es asegurarnos de que o bien coinciden los identificadores de los controles combobox (MEN_CFG) y pila de formularios (FRM_CFG) o cambiamos dichos identificadores en el código.

Si quieres ver como crear una interfaz similar pero con un control listbox consulta la VITAMINA – 13 Organiza los subformularios con un listbox.

The post Organiza los subformularios con un combobox appeared first on Lógica mente Velneo V7.