miércoles, 7 de julio de 2010

Cliente FTP - Full Lazarus

En la empresa donde laboro se me presento la necesidad de desarrollar un cliente FTP para apoyar a los clientes subir archivos y descargarlos para realizar migraciones de información de un sistema a Otro.

Decidí desarrollar el aplicativo en Lazarus el clon de delphi en el mundo de software Libre. Para esto utilice los componentes lnet (Lightweight Networking Library) utilizando, específicamente el la clase TLFTPClient y el desarrollo fe muy sencillo. Lo único que hay que instalar los componentes en lazarus pero hoy por hoy es algo bastante sencillo.
Aqui unas capturas de pantalla en Lazarus.

Aqui unas capturas del Aplicativo:



El programa utiliza tambien el componente trayicon para mostrarce en la barra de estado y efectuar su trabajo segun los tiempos programados que se les especifique en el archivo ini.

jueves, 4 de marzo de 2010

FreePascal y Lazarus el Renacer

Finales del año 2009 empecé a desarrollar un proyecto interesante el cual consistía en desarrollar un reproductor multimedia que tenga la lista de reproducción en una base de datos y se realicen actualizaciones periódicas desde un servidor remoto. Una de las condiciones del proyecto es que se desarrolle íntegramente utilizando software libre.
Mi experiencia como desarrollador me indico que la plataforma de desarrollo podría ser la siguiente:
  • Motor de base de datos Firebird
  • Entorno de desarrollo del reproductor multimedia Qt basado en libvlc
  • Actualización de la base de datos QT
  • Descarga de videos , se desarrollará en QT
  • Interfaz de creación de la programación Freepascal y Lazarus.
En este articulo me centraré principalmente en el desarrollo de la interfaz del módulo de creación y mantenimiento de la base de datos desarrollado en Freepascal y Lazarus.
Estuve tentado a utilizar Java para el desarrollo de esta interfaz pero lo que necesitaba era optimización de recursos y velocidad en el desarrollo, no era necesario levantar todo el jdk para cargar todo el aplicativo, además valgan verdades una aplicación desktop Java siempre es más lenta que una aplicación nativa.
He seguido de cerca el proyecto Lazarus desde que apareció y la verdad que las versiones antes de las 0.9 eran versiones muy inestables y casi no se podía trabajar con ellas, gratamente me sorprendí al testear la versión 0.98 la cual es una versión estable y se puede trabajar con las ventajas del compilador freepascal de ser multiplataforma ejecutándose en Windows, Linux, freeBSD, etc. La productividad de freepascal es bastante buena pudiendo desarrollar interfaces para mantenimiento de base de datos sin mucho esfuerzo y en poco tiempo.
Los componentes para conexión de base de datos son bastante buenos y permiten el desarrollo compatible con Delphi.
Todo esto me decidio que el desarrollo de esta parte del proyecto se desarrollaría con Lazarus y Firebird como base de datos, hablar de las bondades de Firebird estaría de más hay varios artículos al respecto en este Blog.
Una de las cosas que me llamó la atención fue el tamaño del ejecutable un poco grande lo cual se justifica pues tiene enlazado de manera estática las librerías , dando independencia al ejecutable, este al inicio no se valora pero cuando el ejecutable se tiene que correr en diferentes distribuciones vale la pena esos MB de mas, antes de distribuir finalmente el aplicativo este se puede reducir de tamaño quitando la información de depuración y reduciendo este con programas como UPX, finalmente el resultado lo vale.
Otra cosa que me sorprendió fue el soporte de drag and drop y la implementación de controles shelllistview y shelltreeview de manera muy sencilla.

Una tremenda alegría al comunicar esta noticia a todos los desarrolladores amantes de pascal !ya contamos con un entorno estable, productivo y multiplataforma! LAZARUS.
Mucha gente en el mundo del desarrollo creia que el lenguaje pascal había muerto el nombre Lazarus lo dice todo "FreePascal y Lazarus el Renacer"

Bueno, a continuación unas capturas de pantallas, ya que las imágenes hablan más que mil palabras:





Pequeño detalle me olvidaba todo esta corriendo sobre fedora 12 Constantine aca una captura.

miércoles, 15 de abril de 2009

¿Qué les pasa a los profesionales de sistemas?

Después de haber laborado en diferentes empresas peruanas en los últimos 10 años, en las cuales tuve la oportunidad de conocer a muchos profesionales de sistemas, de universidades nacionales y particulares del país.
En la mayoría de los puestos de trabajo que desempeñe muy a menudo fui responsable de realizar las entrevistas de selección del personal de la empresa.
Haber ejercido la docencia universitaria, me dio la oportunidad de compartir experiencias con los futuros profesionales de sistemas, obteniendo de esta manera una visión más amplia para analizar este problema.

Lo primero que pude observar es que la gran mayoría de ellos tienen una actitud facilista y no tienen la cualidad de ser autodidactas. Las soluciones mediocres son las que suelen implementar en la mayoría de los casos, la falta de ambición por el aprendizaje y la dejadez demuestran hoy por hoy, el bajo nivel del profesional de sistemas en el Perú.
Me pregunto ¿Esto se deberá a cuestiones de formación?, ¿Al medio donde se desenvuelve el profesional ? o ¿Son cuestiones innatas de cada persona?.

Creo que los factores preponderantes son: la formación académica y el ámbito social del individuo, el grupo con el que se socializara juega un papel importante ya que los hábitos del grupo tienden a formar parte del individuo, así como la formación académica repercutirá sobre el futuro profesional de sistemas.

En el Perú la proliferación de universidades nacionales y particulares sin un control adecuado han contribuido a una formación deficiente de los profesionales de sistemas, existen en el medio Universidades en las cuales no existe competencia para el ingreso, sólo basta con presentarse y el ingreso está asegurado esto hace que los exámenes de admisión no filtren a los postulantes, recibiendo a postulantes sin una base adecuada.

Es curioso, en una oportunidad escuché a un director de escuela de una universidad particular decir que no podían exigir a los estudiantes, porque sino los estudiantes se quejan y luego se retiran, es decir que los alumnos deben pasar los cursos sin aprender, sin el nivel y rigurosidad requerido.
La educación se ha convertido en un tráfico donde lo único que interesa es captar alumnado, sin brindar el nivel y exigencia requerido que garantizaría una educación de calidad y por lo tanto profesionales competentes que enfrenten los retos de hoy y que puedan contribuir con el desarrollo del País.
A las actuales generaciones de estudiantes no les gusta leer ni esforzarse, pertenecen a una generación que cuenta con muchas facilidades con respecto a la información. Antes no se contaba con ello, pero sin embargo hoy no se hace un buen uso de ello como debiera, la Internet es utilizada como un medio social de distracción en vez de un medio de aprendizaje genuino.
La formación de objetivos y personalidad de los estudiantes de Sistemas no se forma debido al facilismo habituado en ellos por aprobar los cursos, un profesor es bueno si no exige, es allí donde están contentos los estudiantes, salvo honrosas excepciones.

La verdad me he sorprendido como existen alumnos en VII y VIII ciclo de sistemas que no conocen un lenguaje de programación como por ejemplo: C o Pascal, y cuando les preguntaba que les han enseñado, ellos me contestaban que Visual Basic.

¿Porque es perjudicial aprender a programar con Visual Basic?

Esto me refiero a los profesionales de sistemas en particular, Analicemos el origen de Visual Basic, se remonta al Basic el que fue creado para aficionados y no desarrolladores, pues hay muchas cosas que te limita el lenguaje. Aprender a diseñar formularios con colorcitos y animaciones distorsiona el objetivo fundamental del aprendizaje de la programación. Hoy se cree que programar es poner formularios coloridos y animaciones, descuidando la esencia que es lo que está dentro de ese formulario.
Analicemos en que están desarrollados la mayoría de aplicativos en el mundo, nos centraremos que la gran mayoría de aplicaciones que utilizamos en el día a día esta desarrollado en C/C++, nuestros procesadores de texto, editores gráficos, sistemas operativos, servidores de base de datos, lenguajes de programación, etc.

Desde mi punto de vista el alumno de sistemas debería iniciarse con un lenguaje base como C o Pascal los cuales le darán los sólidos cimientos que le ayudarán en el futuro a aprender cualquier otro lenguaje de programación, es mucho más fácil para un programador de C o Pascal aprender Visual Basic, Java o PowerBuilder que lo contrario. En la Universidad se deberían enseñar las bases y fundamentos que permitirán guiar al futuro profesional de sistemas, el alumno deberá comprender el fundamento de como funcionan las cosas para que con cualquier problema que se le presente, él lo pueda solucionar con las bases aprendidas.

Tener metas lo más ambiciosas posibles, es algo que la mayoría de estudiantes de estas generaciones están perdiendo, solo se contentan con hacer lo que le pida y hasta menos, el resultado ya se conoce, proyectos y trabajos mediocres.
Todo está en lo que quieran hacer, a dónde se quiera llegar, no es lo mismo hacer una vasija de barro grotesca que una hermosa vasija terminada, enlucida y pintada, lo primero se podrá hacer rápido, lo segundo requerirá de más esfuerzo y dedicación obteniendo mejores resultados. ¿Existe una diferencia? Claro que la existe.

Frase conformistas de muchos profesionales, como por ejemplo:

• Para qué esforzarme más, si igual me van a pagar
• Mejor mañana lo hacemos con más calma (y el mañana nunca llega o llega después de meses)
• Yo ya no estoy para esforzarme
• Pon eso así, haz el programa como sea ya mañana se verá
• De a pocos, de a pocos (jajaja y nunca se termina)
• Para qué aprender C o Linux si nunca los voy a Utilizar.


Otro de los grandes errores que escucho es: “terminaré y seré Jefe de Proyectos o Arquitecto de software”, si tienes tu padrino de seguro lo serás. Pero la gran mayoría no tiene padrinos y ¿Cómo dirigir la construcción de un edificio si no se sabe como poner un ladrillo?, ¿Querer crear un edificio y no saber como se ponen las columnas?

En otros países se comienza de la siguiente manera:

Primero: serás programador Junior (por lo menos 2 años)
• Segundo: serás Programador Senior (por Lo menos 2 años)
• Tercero: serás Analista Junior (por lo menos 2 años)
• Cuarto: serás Analista Senior (por lo menos 2 años)
• Serás Jefe de Proyecto (10 grandes proyectos de software)
• Serás Arquitecto de Software

Ahora ya sabemos el porqué muchos proyectos fracasan, se escuchan casos en los cuales se asume la jefatura de un área de sistemas y no se sabe que hacer, los jefes son paseados por los analistas y programadores. No existe respeto hacia la jefatura. Un proyecto sin rumbo, sin cabeza, va camino al fracaso. En realidad la experiencia en diferentes empresas da el conocimiento de cómo se manejan los procesos de las empresas, uno puede saber programar pero sin el conocimiento de los procesos no se sabrá que hacer. Un jefe de proyectos tendrá que ser también un Ingeniero de procesos, ya que se debe tener la capacidad de conocer los procesos y mejorarlos, eso sólo se consigue con la experiencia.

He escuchado a muchos profesionales decir esto: "no se puede hacer mi versión de Visual Basic, no trae el control tal, así que es imposible desarrollarlo".

Analizando esta actitud de los estudiantes, me percate que se debía en gran medida al entorno donde se estaban desarrollando.
Muchos alumnos me contestaron que la mayoría de docentes no les exigían y les habían creado malos hábitos inconscientemente, como no investigar, no esforzarse en aprender nuevas herramientas o tecnologías, recuerdo que muchos estudiantes me confesaron cosas que me hacían tener vergüenza ajena como por ejemplo:

No hay problema este trabajo lo hemos copiado muchas veces y solo cambiamos los colores de los formularios el profesor como no sabe nada no nos revisará el trabajo, sólo mirará que es diferente y pondrá buena nota.
• Me contaban también, que algún docente solo bajaba el primer link de google y lo imprimía y la clase se transformaba en una clase de redacción, si al docente se le olvidaba su impreso pues cancelaba la clase con cualquier excusa.
• Los alumnos realizaban apuestas en las cuales decían: “mira, este trabajo está lleno de sandeces pero se lo presentaré a tal profesor y apuesto que me pondrá buena nota”.

La lista de historias es interminable y existen muchas que son muy jocosas,

La gran verdad es que al docente universitario Peruano sobre todo en Sistemas le falta experiencia, hablan de cosas que nunca han realizado, enseñan sobre sistemas que nunca han desarrollado, enseñan materias que nunca en la práctica las han trabajado, es algo curioso pero muy cierto, hoy por hoy la gran mayoría de maestrías son un gran engaño, antes un Magister era un profesional más preparado que realizaba verdadera investigación, aportaba con al desarrollo social y tecnológico del país, existen maestrías “combo”, las cuales te brindan dos menciones en lo que más desees y no olvidarnos de las Maestrias-Doctorado en fin de todo se ha dado en la educación Peruana.

Es lamentable el nivel de muchos Pseudo Magisters, que no saben ni lo mínimo de informática, como existe una frase célebre: “uno puede engañar a los demás pero el mayor pecado es engañarse a uno mismo”, creer que saben algo y perjudicar a la educación de los estudiantes es una estafa, deberían hacer una mea culpa y esforzarse por mejorar y de esta manera dar lo mejor de ellos a los futuros profesionales de sistemas.

Uno de los grandes vacíos que existe en la educación universitaria particularmente en ingeniería, es la falta de actitud de muchos estudiantes, entonces los docentes universitario aparte de desarrollar las materias de la curricula deberían preocuparse por enseñar a tener actitudes positivas en la vida, por más falencias que tenga el docente, este debería ser sincero y reconocerlo.

Luego, deberíamos:
  • Fomentar la cultura del éxito con ejemplos e insistir con actitudes positivas y de mejora continua en el educando.
  • Fomentar también los hábitos de lectura y aprendizaje constante, incrementando la aplicación de la teoría en la práctica.
  • Atreverse a soñar y que todo es posible.
  • Inculcar el habito del auto aprendizaje.
  • Demostrar actitudes positivas frente a cualquier problema.
  • Enseñarles a ser pro activos y siempre dar más de lo que a uno le piden.
  • Ser conscientes de la responsabilidad social y el aporte tecnológico del Profesional con el País.

Recordemos que las personas que cambian el mundo son los idealistas, los soñadores, pues si ellos el mundo no hubiera llegado a donde está.

sábado, 22 de noviembre de 2008

Regresando a Publicar

Hola a todos les agradezco por los buenos comentarios sobre los diferentes artículos, después de ciertos cambios en mi vida profesional regreso con muchas ganas de escribir mas artículos y comentarles mis experiencias.

Gracias a Todos

Atte. Ing. Oscar Zelada Pozo

miércoles, 12 de marzo de 2008

Quien Mato al Ingeniero de Software ?

Este articulo es muy interesante y muestra la problemática real del desarrollo de software, la pregunta es todos deberían estudiar informática?

Robert Dewar, autor junto Edmond Schoenberg del artículo “¿Dónde están los Ingenieros de Software del mañana?” continuó la discusión al respecto en otra entrevista para Datamation. A continuación una traducción general con algunas opiniones de dicha entrevista:

Su argumento se resume así: los programas universitarios de ciencia de la computación no son lo suficientemente rigurosos, y no promueven la resolución de problemas y pensamiento en profundidad. En vez de eso, en un esfuerzo por aumentar el matriculado, los programas se enfocan en un currículo fácilmente accesible, y fallan en preparar a los estudiantes a competir con sus colegas internacionales.
Describe que su artículo fue malinterpretado en el punto en que comenta que la adopción de Java como primer lenguaje en los cursos ha llevado a ésta decadencia. Si bien Dewar entiende que las bibliotecas gráficas de Java permiten a los estudiantes crear software sin entender el código fuente por debajo, éste no es el problema principal.

“Mucho se trata de ‘hagamos ésto más divertido’. Sabes, ‘la matemática no es divertida, reduzcamos los requerimientos de matemáticas. Los algoritmos no son divertidos, deshagámonos de ellos. Ewww - bibliotecas gráficas son divertidas. Hagamos que la gente juegue con las bibliotecas. Y [olvidarse] todo éste asunto con ‘línea de comando’ - haremos que la gente use interfaces visuales lindas donde puedan apuntar y hacer clic y crear cosas gráficas llamativas y divertirse.”

Dewar menciona que su casilla de correo se llenó de respuestas positivas a su artículo, de estudiantes así como empleadores. Mucho lectores le han agradecido por hablar de una situación que creen necesario debe ser atendida, cuenta. Un email era de un IR que trabaja con un programador junior. El trabajador más viejo sugirió que el joven ingeniero chequeara el stack del núcleo para ver sobre un problema, pero desafortunadamente, “nunca había oído sobre un stack de núcleo”.

Desde el punto de vista de Dewar, la culpa es de las universidades que están deseperadas por compensar las bajas matriculaciones en programas de ciencia de la computación, aunque signifique destrozar los programas. Es conocido ampliamente que las matriculaciones han decrecido. Las causas principales: la caída de las punto com, y los encabezados constantes sobre outsourcing.
Responden a ésta baja en estudiantes del sector “atontando” los programas, esperando hacerlos más accesibles y populares. Lo que sea muy demandante o percibido como tedioso, se reemplaza con material simplificado que atraiga más enrolamientos. Obviamente como dice Dewar, ésto es contraproducente.

“Para mí, los números no son necesariamente la primera preocupación. La primer preocupación es que la gente obtenga una buena educación.”
Éstos estudiantes que fueron alimentados con material fácil no están preparados para competir globalmente.

Dice, uno de los pasos más contraproducentes que dieron las universidades fue adoptar Java como el lenguaje más usando en los cursos introductorios de programación, en un deseo de hacer la carrera más popular. Recuerda una discusión en la NYU hace varios años cuando decidieron cambiar el lenguaje introductorio de Pascal a Java. Pascal nunca había sido tan popular en la industria, cosa que no importaba; aprender Pascal tendía a promover prácticas de programación sólidas.
“Enseñaban Pascal porque parecía pedagógicamente la mejor opción”, dice Dewar.
El cambio a Java se hizo “puramente sobre la base de la demanda percibida de los estudiantes”. Para estar seguro, es un código popular para aplicaciones web y es relativamente fácil para los principiantes. Sin embargo, es exactamente ésta facilidad que lleva al núcleo de lo que está mal con los currículos de hoy en día.

“Si vas a una tienda y compras un libro de Java, son 1.200 páginas; 300 páginas son el lenguaje y 900 son bibliotecas misceláneas. Y es verdad que puedes sortear muchas cosas juntas en java muy fácilmente… así que puedes sortear cosas juntas sin un conocimiento mínimo,” dice. “Pero para mí, eso no es ingeniería del software, eso es algún tipo de programación consume-nivel.”

“El problema con Java es que esconde muchas cosas… esconde los temas de compilación - ¿qué está haciendo un compilador? Creo que si fuera a hablarle a un estudiante de Java, ni conocerían la palabra ‘compilador’. Si la conocieran, estoy seguro que no voy a obtener una idea si preguntara ‘¿qué hace un compilador?’”
El problema, a nivel de mercado en Norte América sería “Si la gente sale de las escuelas y saben Java y programación Web, y saben cómo armar cosas usando bibliotecas, ese es el tipo de habilidades que no se demandan”, Los trabajos que requieren no más que éstas habilidades de bajo nivel puede perfectamente hacerse desde países con sueldos bajos.
Como resúmen, el constructor a partir de bibliotecas de Java de hoy, es el repartidor de pizzas de mañana.

¿Quién debería estudiar (y quién no) Ciencias de la Computación?

Se necesita una persona con un set bien específico de inclinaciones y talentos para ser un programador de computadoras, comenta Dewar. Son éstas personas específicas para quienes deberían apuntar sus programas las escuelas - no la masa de personas semi-interesadas que usan bibliotecas pre-hechas para crear aplicaciones sin inspiración. Reflexión final de Dewar:

“La mayoría de los que entramos en programación realmente lo hacíamos porque lo encontrábamos divertido. Encontramos el desafío intelectual divertido. Encontramos que enfrentarnos a un problema complicado, luego pensar soluciones algorítmicas interesantes, es divertido. Encontramos estructuras de datos listas que resuelven problemas interesantes, divertidas.”
“Tal vez no sea divertido para una audiencia más grande, pero la educación de ciencias de la computación debería ser más sobre encontrar a esas personas que disfrutan ese tipo de diversión y enfocarse a ellos en vez de hacerlo todo fácil.”
“Si la gente encuentra aburrido computar algún valor interesante, entonces corre ese programa y obtiene un valor de 42 cuando debería ser 83, y encuentre porqué obtuvieron 42 en vez de 83, si encuentran eso tedioso y aburrido, entonces no son la clase de gente que necesitamos.”

Para los que se sientan identificados con la gente que describe en su reflexión final, creo que vamos por buen camino.

¿Los dos tipos de Programadores ?

En Coding Horror, un blog bien interesante para programadores, Jeff Atwood escribe un post titulado “The Two Types of Programmers”, donde plantea una agrupación más general de los tipos de programadores.

“Contrario al mito, no hay catorce tipos de programadores.. Hay realmente solo dos, como nos recuerda Ben Collins-Sussman.

Hay dos “clases” de programadores en el mundo del desarrollo del software: voy a llamarlos el 20% y el 80%. Los tipos del 20% son lo que se llamarían programadores “alfa” - los líderes, el tipo que lugares como Google y Fog Creek software buscan contratar desesperadamente. Éstos tipos fueron los primeros en instalar Linux en su casa en los 90´s; la gente que escribe compiladores en Lisp y aprende Haskell los fines de semana “por diversión”; participan activamente en proyectos open source; siempre están al tanto de las últimas, y más frescas tendencias en la programación y herramientas.

Los tipos del 80% hacen el bulto de la industria del desarrollo de software. No son estúpidos; son meramente vocacionales. Fueron a la escuela, aprendieron suficiente Java/C#/C++, luego obtuvieron un trabajo escribiendo aplicaciones internas para bancos, gobiernos, firmas de viajes, firmas legales, etc. El mundo usualmente ni ve su software. Usan cualquier herramienta que les provee Microsoft — usualmente VS.NET si están en C++, o capaz un GUI IDE como Eclipse o IntelliJ para desarrollar en Java. Nunca han usado Linux, y no están muy interesados en él de todas formas. Muchos nunca han usado siquiera control de versiones. Si lo han hecho, es con cualquier herramienta entregada con la caja Microsoft (como SourceSafe), o alguna cosa antigua que le hayan entregado. Saben exactamente lo suficiente para hacer su trabajo, luego se van los fines de semana a casa y se olvidan de las computadoras.”Personalmente, convivo con esta teoría a diario en clase. Una frase típica, a tono de burla, en mi salón de clase es: “Eso el Visual Studio te lo hace solo” ó “¿Para qué vas a aprender eso si ya está hecho?” ó “Ésto nunca lo vas a usar, es al pedo aprenderlo“. Con esa mentalidad se maneja este 80%.

El problema, el primer año aprendimos a usar Visual Basic, un IDE que te autocompleta, te tabula, y el framework .NET que incluye todo. Y resulta muy difícil para la mayoría salir de eso. Trabajar en C a bajo nivel es como darse contra un muro de piedra en un automóvil a 90 km/h y sin cinturón de seguridad…

Lo peor no es ésto, sino la cabeza de no salir de lo que ya se aprendió, de aprender una cosa que resulta “cómoda”, y no salir de eso. Muchos dijeron cuando empezamos con la materia: “¿Para qué quiero aprender C si nunca lo voy a usar?” ó “Yo nunca voy a programar un sistema operativo, ¿para qué quiero aprender C?” Conociendo esa mentalidad, ¿quién contrataría a ésta gente para un puesto de programador?

Me imagino la situación (situación Dilbert):
Jefe - “Mirá, tenés que hacer una librería en C que interactúe con nuestro framework de persistencia para controlar el puerto serie del servidor
Empleado - “¡Ah no!, yo eso no lo sé hacer, aparte el Visual no trae cómo hacerlo…

Son el tipo de gente que cumple con las 12 señales de que eres un mal programador. Son una nueva generación de 80% que se está gestando…

Para reafirmar más ésta teoría, se aplica la teoría general del Dr. Gregory Walter Graffin III, quien declaró que

En cualquier muestra al azar de la población general, se encontraría que el 80% de la gente son completos idiotas.

Es totalmente compatible, aislamos una muestra de la población, con la característica en común de ser programadores. El 80%, por ende, no son muy inteligentes…
El artículo de Coding Horror continúa diciendo:

“Cuando trabajo con equipos de programadores en el campo, consistentemente me asombro con el abismo entre ese 20% y el resto del mundo. Hace que la división entre el campo open-source y el campo Microsoft parezca un charco llano.

Declaración shockeante #1: La mayor parte de la industria está hecho del 80% de los programadores.. Sí, la mayoría del mundo son tiendas pequeñas de desarrollo para Windows, o firmas pequeñas que contratan programadores internos. La mayoría de las compañías tienen unos pocos tipos del 20%, y son generalmente los que presionan a sus jefes de pelo parado para cambiar políticas, actualizar herramientas, o usar un sistema de control de versiones sano.
Declaración shockeante #2: La mayoría de los alpha-geeks se olvidan de la declaración shockeante #1. La gente que trabaja con software open source, participan en argumentos apasionantes de criptografía en Slashdot, y bajan los últimos lanzamientos GIT son extremadamente propensos a perder de vista el hecho de que “el 80%” existe. Se emocionan con la última distro de Linux o herramientas de AJAX o sistema SCM distribuido, pasan todo el fin de semana en eso, bloguean al respecto… y luego están confundidos sobre porqué no pueden lograr que su oficina empieza a usarlo.

Tal vez no es algo impresionante para mí, pero un excelente e importante recordatorio para todos, sin embargo.

A menudo pienso que perdemos el tiempo escribiendo blogs los cuales son mayormente leído por el mismo 20%. En mi experiencia existe un pequeño efecto de goteo de los programadores alfa hacia todos los demás. Y si lo hay, lleva décadas.”

Jeff continúa su artículo incitando al 20% a cambiar, a construir un puente entre el 20% y el 80%:

“Si realmente quieres cambiar el status quo del desarrollo de software, si realmente quieres marcar una diferencia este año, tienes que ayudar fuera del pequeño grupo insular de programadores alfa y crear el cambio en el otro 80% del mundo. Y eso es mucho, mucho mas difícil que predicarle al convertido 20%. Es por eso que admiro a gente como Scott Mitchell, porque entiende la importancia de llegarle al otro 80%.”
(…)
“Desearía que fuera más sencillo para mí, porque estoy de acuerdo con Scott” (…) “Creo que la verdadera medida de éxito no es cuántos alpha geeks podés hacer que te presten atención. Es cuántos típicos, poogramadores promedio has alcanzado, aunque sea de una forma pequeña. Si realmente te importa el arte del desarrollo de software, nos ayudarás a construir ese puente entre el 80% y el 20% también.

Es difícil lidiar con éste 80%, pero a lo largo de la carrera, van a estar siempre presentes. ¿Qué piensas al respecto? ¿Te consideras ofendido por el post? Estás en el 80…

domingo, 9 de marzo de 2008

Nace el Proyecto JDataObject

Un grupo de Alumnos de la Universidad Nacional del Santa y mi persona estamos desarrollando un proyecto con las siguientes características

I.- DESCRIPCION DEL PROYECTO
Desarrollo de herramientas y componentes para la generación de consultas de Base de datos y diseño de objetos (Texto,Campos, Imágenes, Campos calculados, lines, etc.) asi como de sus propiedades para la edición y mantenimiento de los datos.
Añadir una nueva funcionalidad a NetBeans que permita la creación de Objeto de datos (JDataObjetc) para el manejo y edición de datos a través del control JDataControl.
El proyecto esto formado de 2 elementos:

1.-Plugin para NetBeans que permite el diseño dinámico de consultas así como el diseño de Objetos de Datos (JDataObjetc). El objeto JDataObject es un objeto que encapsula una consulta SQL así como las propiedades de cada uno de los objetos definidos en esta. Estos objetos pueden ser Texto, campos de tablas y campos calculados. El objeto también pose propiedades en si mismo para las funciones inherentes al trabajo con Datos y la presentación de estos. El diseñador de objetos JDataObjet utiliza archivos en formato XML para almacenar las diferentes propiedades de cada objeto.

2.-JDataEditControl.-
Es un Bean que encapsula la funcionalidad del trabajo con una consulta de base de datos haciendo uso de cursores desplazables con cualquier base de datos cuyo controlador JDBC soporte estas funcionalidades. La mayoría de las operaciones cotidianas de trabajo con una consulta actualizable de datos se pueden realizar de una manera muy sencilla con una mínima programación. Este control aumenta tremendamente la productividad en la creación de aplicaciones que trabajan con una base de datos.
Módulos que conforman el Proyecto
• Diseñador dinámico de consultas
• Diseñador de Objetos JdataObjetc
• Componente JdataeditControl

II- BENEFICIOS PARA LA COMUNIDAD DE NETBEANS
• Permitir a NetBeans poder competir con otros entornos de desarrollo como PowerBuilder, Delphi y Visual Basic los cuales cuentan con herramientas productivas para el acceso y manejo de datos.
• Incrementar el desarrollo de aplicaciones Desktop con NetBeans
• Incremento de la productividad en el desarrollo de aplicaciones con Base de datos.
• Facilidad de adopción de Netbeans para desarrolladores de otros lenguajes y entornos de desarrollo.
• Introducción al mundo de las Base de datos de una manera fácil y práctica para los programadores de Java noveles.

III.- PLAN DE IMPLEMENTACION
El proyecto se implementara utilizando solo componentes proporcionados por la plataforma de Netbeans y el proyecto Ireport de JasperSoft. Se desarrollara un modulo que extienda las capacidades de Trabajo con base de datos, para lo cual se desarrollara un generador dinámico de consultas, este generador enviara la consulta SQL al diseñador de Objetos JDataObject, en el cual se podrá ajustar las propiedades de visualización y otras de cada objeto pudiendo ser este Texto, Imágenes, Dibujos y campos calculados. Los objetos JDataObjet podrán ser llamados por el componente JDataEditControl que es un Beans que encapsulará la mayoría de operaciones con el tratamiento de datos, se utilizara como repositorio de información archivos en formato XML. El Proyecto esta dividido en 3 Módulos
• Diseñador dinámico de consultas .- Esta se desarrollara de manera visual permitiendo al usuario seleccionar el origen de base de datos y realizar la selección de Tablas y campos de estas , así como establecer las relaciones existentes entre las diferentes tablas, pudiendo alternativamente ingresar parámetros de recuperación de la base de datos.
• Diseñador de Objetos JDataObjetc.- La consulta generada con la herramienta anterior es utilizada por esta herramienta la cual permitirá el diseño y ubicación de los diferentes campos así como de sus propiedades, los formatos de presentación de los registros serán 2 de manera Tabular y otra un Grid. Todos los parámetros de la consulta se grabaran en un archivo XML el cual será interpretado mas adelante por el Control JDataEditControl
• Componente JdataeditControl (Grid y Tabular).- Es un componente que permite trabajar con el Objeto JDataObjetc, y provee las funciones y propiedades para el manejo de las operaciones con los registros de la base de datos.
Se utilizara la plataforma NetBeans para la creación del plugin para la generación de consultas dinámicas así como el diseño del JDataObjetc.