Categoría: .NET

Lo tenia delante pero no sabia decir porque no me gustaba: Java

Posted on by ecardenas

Cuando uno llega a una situacion u opinion es porque ha recorrido un camino previo, nadie te ha teletransportado ahi, solo que a veces nos olvidamos de dicho camino.

Concretamente debo referirme a la predileccion como desarrollador que tengo para con la plataforma .Net, el porque termine ahi y lo prefiero frente a Java … tiene su historia.

Luego del paso obligatorio por Pascal, C/C++, COBOL tocaba enfrentarse a las herramientas de desarrollo “real”, con la que se hacian las cosas en las empresas, y sobre todo, las que permitian desarrollar para Windows. Tuve ocasion de hacer un curso de Gupta SQL Windows, el cual me dejo un mal sabor de boca.

Es por esa epoca que tambien me expongo ante Visual Basic 4/3, se comenta algo sobre Java, pero aun no recuerdo el como y porque (creo que lo que lei por ahi) termino en mi casa haciendo experimentos con Borland Delphi 1 y fue quedar seducido por la propuesta hecha: un poderoso lenguaje Orientado a Objetos, con una interfaz que cogia lo mejor de los conceptos drag and drop popularizados por Visual Basic.

Pero claro, lamentablemente en Peru Delphi era un lenguaje casi de “culto”, por lo que urgia revisar las cosas que iban apareciendo en el mercado y una de esas cosas fue algo que me comentaron a poco de terminar mi primera Feria del Hogar: un lenguaje llamado Java el cual prometia traer la interaccion a la web mediante los llamados “applets”, propuesta interesante la verdad, el caso es que no me pude poner a probar Java sino hasta el 97 en que pude instalar Windows 95, esto debido a que no habia opciones para correr Java en W3.11 como no sea mediante el proyecto ADK que no se en que habra terminado.

Intente darle su espacio a Java, pero entonces me topaba con unos problemas que para entonces eran criticos:
– Ausencia de un IDE lo suficientemente rapido, aun el Borland JBuilder era muy lento, siendo que aun VB (5 para entonces) era mucho mas rapido y ni que hablar de Delphi (3 y 4).
– No continuidad en el modelo de presentacion grafica, de un momento a otro se decidio que las AWT debian dar paso al modelo Swing.

El lenguaje en si no daba muchos problemas (regresaremos a esto), pues ya contaba con la base de saber C/C++, pero lamentablemente costaba mucho ser productivo, siendo que con Delphi implementar algo era relativamente simple (pero no tan innecesariamente simple como con VB). Tambien es conviente notar que como el enfoque era hacia dar “dinamismo” a la web, surgieron herramientas que proponian alejarte del codigo para generar applets (semi prefabricados) de manera mas agil, hablo de Kinetix y Jamba. Y claro, por otro lado teniamos a Kawa, que fundamentalmente era un gestor de proyectos que tras bastidores llamaba por linea de comandos al JDK.

Es asi que me volvi en uno de los pocos defensores de Delphi en Lima de esa epoca, hice experimentos con las opciones de desarrollar paginas con ISAPI, controles ActiveX incrustados, desarrollo en 3 capas mediante Midas, y claro un buen rato metido en el newsgroup non-technical de Borland asi como en ClubDelphi, circunstancias que me llevaron a conocer a Claudio Briceño (responsable comercial de Borland para Latinomaerica) quien me vino a visitar a mi trabajo de entonces, lo cual luego conduciria (gracias a la posterior coordinacion de un comunidad de Linux en el Peru) a la posterior presentacion de John Kaster en el Hotel Los Delfines para presentar los avances que hacia Borland en desarrollar Kylix un entorno Delphi para Linux, y si, ahi estoy yo… :

Luego me tocaria cenar tanto con Claudio y John a la espera de posteriores acciones que permitieran potenciar la presencia de Delphi en el mercado peruano, lo cual no logro a materializarse.

En esas circunstancias, veo que las cosas cambian, nadie habla de applets, todo se orienta hacia los servlets, y a los EJB, les doy una revision… nuevamente, cuesta hacer algo simple de manera rapida, se nos habla de que ya saldran los JSP….. Lo interesante es que a pesar de esas limitaciones Java estaba cogiendo un mayor arrastre, el cambio de lo “visual” hacia los modelos de componentes orientados a servidor habian probado ser buenos para la estrategia de Sun, ya que habia una demanda en el mercado por una solucion no atada a Microsoft, mas orientada a objetos y que fuera robusta, en ese sentido los Application Server lanzados por diversos fabricantes permitieron consolidar su posicion en el mundo corporativo.

Es en esas circunstancias que (me)ocurrieron varios eventos de manera casi consecutiva, Microsoft anuncia .NET prometiendo una plataforma totalmente Orientada a Objetos(*), soy admitido en una beca de Microsoft para estudiar VS 6 y ceso en mi trabajo de entonces.

Estudiar lo que ofrecia VS (VB + Interdev fundamentalmente) me hace ver ciertos detalles que no eran tan claros para mi, era perfectamente viable construir aplicaciones robustas con esas herramientas, pero que muchas veces la simplicidad te conducia a errores de diseño que penalizaban la performance y la mantenibilidad, siendo necesario un conocimiento serio de la arquitectura detras (algo en lo que los cursos de Certificacion enfatizaban bastante).

A pesar de haber “cambiado” de herramienta por razones de mercado, sabia que esto era algo transitorio, pues veia la fuerza que iba a arrastrar el lanzamiento de .NET, producto al que recibia con expectativas positivas debido a que el cerebro detras de esto era nada menos que Anders Hejlsberg quien habia sido arquitecto de Delphi en sus dos primeras versiones, del cual solo podria esperar que introdujera en la nueva plataforma la evolucion de las innovaciones que habian sido introducidas originalmente en Delphi.

(Para ese entonces Borland libera Kylix, el cual debo decir que nunca use)

Obviamente que apenas pude me consegui una de las primeras Beta de Visual Studio .NET, aparatoso como buena beta, ya dejaba ver que habia asumido totalmente el modelo de objetos, y por todas partes se notan los guiños a Delphi, especialmente en C# en el tema de la gestion de eventos, comprendi entonces que me encontraba ante una herramienta potente y sobre todo que introducia la programacion RAD y orientada a eventos al desarrollo Web, algo tan simple y a la vez potente era algo por lo que los desarrolladores habiamos estado esperando buen tiempo. Pero lo mas importante era que todo lo aprendido sobre OOP en Delphi se aplicaba directamente en la nueva plataforma, y a estas alturas creo que mi transicion fue mucho mas simple que si hubiera venido solo procedente de VB6, lenguaje que con todo lo flexible que era, te enmascaraba muchos detalles los cuales no te permitian una total potencia en el desarrollo.

Para cuando llegue a España ya habia experimentado con la Beta 2 (y una pre-Beta2 no lanzada masivamente pero que me fue facilitada en Microsoft Peru), por lo que seria cuestion de tiempo que me terminara involucrando en proyectos de .NET como ha sido hasta la fecha, incluyendo examenes de certificacion en el interin.

Han pasado los años y es gracias a CampusMVP que me entero de unos articulos de Ian Marteens(al cual ya habia leido por 1999) en los que se hacen interesantes comparativas entre Java y C#, enterandome de que la implementacion de los Generics en C# es mejor que en Java, pero confirmando algo que ya habia intuido en mis primeras peleas con Java: su implementacion de eventos es penosa, ya que como el mismo Marteens dice “Los diseñadores de Java eran personajes que odiaban los punteros, y nunca hubiesen aceptado implementar los eventos al estilo Delphi. De hecho, ni siquiera tuvieron en cuenta el soporte para eventos cuando crearon Java”. No vieran el alivio que tuve al leer esto, durante mucho tiempo creia que era yo quien podria estar haciendo algo mal cuando trate de implementar cosas en Java, pero como se puede ver en esta serie de articulos, hay errores (llamalos caracteristicas si quieres) en la implementacion del lenguaje, y era algo que alguien que provenia del entorno Delphi podia intuir, pero es bueno saber que hay bases formales para entender las ventajas de un lenguaje (lenguaje, no plataforma, esa es otra guerra) sobre otro.

Como digo, es un camino el que me ha traido hasta aqui y ese camino empezo con la experimentacion de Delphi, herramienta que a pesar de no trabajar con ella en años, no puedo sino recordar con cariño y agradecimiento por las bases que me dejo.

(*)Recordemos los fuertes ataques que recibia VB por no incluir algo tan simple como la herencia.

Repasando el Remix en el SIMO

Posted on by ecardenas


Como ya lo tenía planeado hoy día asistí al reMIX España el cual se llevo a cabo dentro del SIMO Network, sonaba interesante la idea, pues a diferencia de la mayoría de conferencias de Microsoft esta estaba centrada en el tema de interfaces de usuario, lo cual nunca está de mas saber.

El lado negativo de esta conferencia no debo atribuirlo a Microsoft sino al propio personal de IFEMA, tradicionalmente he asistido a diversos eventos de Microsoft con solo dar mi nombre y comprobando este en la lista de asistentes, pero lamentablemente la cerrazón del personal de Ifema me impidió asistir el día de ayer a la presentación de Windows 7, por lo que tuve que ir a una cabina a imprimir mi invitación y de esta manera no perderme el reMix, para que el día de hoy notara la insistencia de los empleados en pedir tarjeta o datos de empresa, mal de su parte.

Microsoft siempre tiene un objetivo en sus presentaciones, en este caso introducirnos a las ventajas que trae Windows 7, y lo mas fundamental plantear el paradigma de integración en los procesos de diseño de interfaz de usuario y la programación “pura y dura”, amen de lo usual en estos eventos: promocionar sus herramientas de desarrollo y tecnologías, curiosamente el plato fuerte en este sentido no fue Visual Studio sino Silverlight y Microsoft Expression.

Luego del clásico discurso motivador de uno de los Developer Evangelist de Microsoft, dos empresas playmusic.fm y Telecinco enseñaron el estado de sus desarrollos usando estas tecnologías, y la verdad es que la primera para ser un startup ha apostado por crear una interfaz moderna, yendo mas allá del clásico formulario de caja de texto y botones (paradigma contra el cual se iría a lo largo de la jornada), la verdad es que para quien toda la vida ha trabajado en esta clase de interfaces, primero con Delphi, luego VB y ASP.NET el pensar en carruseles y drag and drop … cuesta un poco, pero no hay que perder esto de vista a la hora de plantearse un diseño de aplicaciones.

También toco un vistazo a Azure, el cual si bien esta en beta no dudo que en breve sera demandado por las empresas, por lo que tocara estar listos.

Luego se explico sobre el Expression SketchFlow, herramienta la verdad que era completamente desconocida para mi, la cual sin ser totalmente revolucionaria la veo muy útil, siendo la sesión eminentemente practica se nos enseño como se crea un prototipo de aplicación navegable, siendo el objetivo transmitir la clase de cosas que podrá hacer la aplicación al cliente, esta herramienta resulta muy practica para discutir y definir ajustes de una manera más clara que mediante enésimos powerpoints o documentos de Word. El pequeño problema, como comentábamos con Jordi, es que Microsoft partió de la idea de ofrecerla como una herramienta para los diseñadores gráficos antes que como una utilísima herramienta para el Analista Funcional.

Esto me hizo pensar en un detalle, si bien Microsoft nos recalca la evolución que se está dando desde el punto de vista de las interfaces de usuario y como quienes desarrollamos debemos pensar más de acorde a estos tiempos y a los nuevos tipos de usuarios, por otro lado no se recalco mucho en la necesidad que hay en el “lado del diseño” de pensar en la funcionalidad y sobre todo en desarrollar buenas prácticas que permitan un trabajo de equipo de manera integrado, algo de esto lo comente hace dos años, y creo que aún permanece vigente y se hará necesario reflexionar sobre cómo hacer que las bonitas interfaces que nos mandan (gracias a Photoshop o Corel) sean fácilmente trasladables a una aplicación “real” ya sea en ASP.NET, Silverlight o Windows Forms.

La siguiente sesión antes del almuerzo ya fue más light y con pretensiones de ser divertida, se trataba de dar un vistazo a las novedades de Windows 7 en cuanto a interfaz de usuario y sobre la forma de acceder programáticamente a ellas, por lo menos se cumplió con el objetivo de dar ese vistazo y dejarnos con la curiosidad de intentar explorar.

A la vuelta del almuerzo (bocadillo de tortilla de patatas y ensalada cortesía de Microsoft) tocaba una sesión a la cual le tenía interés pues a Silverlight solo lo he visto cuando alguna web (como esta imprescindible Web dedicada al evento de ALM del año pasado) lo utiliza en vez de Flash (palabra que no fue mencionada en ningún momento del remix, lo cual es una señal clara de intenciones), lamentablemente el nerviosismo del expositor no permitió explotar totalmente un tema que de por si era muy interesante.

En contraparte, la conferencia final dedicada a Surface, sí que cumplió con las expectativas ya que tanto la claridad del expositor de Plain Concepts como los ejemplos (sencillitos pero efectivos prueba de concepto) permitieron consolidar la idea sobre el cambio de paradigmas de uso de la informática, la nueva clase de usuarios en estos tiempos, y como pensar a la hora de tratar de aprovechar la tecnología que está saliendo.

En resumen una de las mejores conferencias de Microsoft a la que haya asistido, también será por el factor novedad de mi parte, pero al menos me dejo la idea de cosas a tomar en cuenta para el desarrollo futuro de aplicaciones. Lo malo: es que no se menciono en ningún momento a Windows Forms, es que claro todo el empuje va hacia Silverlight y Windows Presentation Foundation.

 

Ya es oficial… LINQ to SQL es obsoleto

Posted on by ecardenas

Hace unos meses decidi hacer un experimento en casa, se trataba de combinar (y asi practicar) el uso de SQL Server 2008, Windows Presentation Foundation y… LINQ to SQL. El proyecto consistia en meter en una Base de Datos el grueso de mi coleccion de MP3, sus posiciones relativas al Ranking de Doble9, y mediante LINQ (en vez de T-SQL) efectuar las respectivas consultas.

Pues si, el experimento ha funcionado bien a efectos de las consultas, no tanto a nivel de WPF, pues…. como buen ingeniero a veces fallamos en la parte de la estetica y la funcionalidad, pero el caso es que mejor hubiera sido al reves (al menos ya lo tengo todo en SQL Server) pues hoy gracias a Directions on Microsoft me vengo a enterar que Microsoft ha decidido reemplazar LINQ to SQL por el ADO.NET Entity Framework, que si.. que seguira funcionando pero no se beneficiara de las innovaciones que vaya desarrollando Microsoft.

En parte tiene sentido el movimiento, cuando empece con mis primeras pruebas una de las primeras cosas que intente fue ver si era capaz de conectarse a Oracle, lo cual… no era posible, y por ahi salian las recomendaciones de que eso debia de hacerse mediante el Entity Framework, y claro.. entre trabajar un API que solo te permite conectarte a una BD (por mas de que sea la mejor) y otra mas abierta… las cosas caen por su peso.

LINQ to SQL debuted with LINQ in the .NET Framework 3.5 in 2007. LINQ is a set of APIs and programming language features that enable data access queries to be written in programming languages such as C# and Visual Basic, rather than treated as text data. LINQ simplifies data access code and enables the developer to use the Visual Studio tools, such as the compiler and IntelliSense command completion, to help write queries. At its launch, LINQ supported a variety of data sources, including in-memory data objects and XML documents, and the Microsoft C# team had built a stopgap LINQ connector to SQL Server—LINQ to SQL.

However, when LINQ to SQL shipped, the Microsoft data access team had already begun work on the ADO.NET Entity Framework, a more general data access technology that provides LINQ connectivity to SQL Server and other database management systems, including Oracle and IBM DB2. When the Entity Framework was introduced with the .NET Framework 3.5 SP1 in July 2008, LINQ to SQL became largely redundant.
…….
Microsoft has begun publishing documentation for migrating applications from LINQ to SQL over to the Entity Framework. Migration is manual, and both application-side LINQ code and data access code might have to change. Furthermore, the Entity Framework itself is due for major changes, some designed to simplify migration from LINQ to SQL and address requests from LINQ to SQL developers. Consequently, developers who have existing LINQ to SQL applications might want to wait for the next version of the Entity Framework, due in late 2009 with the .NET Framework 4, before attempting a migration.

Creo que sera buena idea estar pendiente de las betas para saber como va evolucionando el Entity Framework, asi que … mi experimento sigue sin terminar 😉

Errores de alto vuelo en la web de Air Plus

Posted on by ecardenas

Un articulo reciente de Eduardo y su posterior discusión, me ha convencido de seguir con esto de los problemas en las paginas Web, problemas que no están restringidos a ninguna tecnología en particular, ya que como le decía a Eduardo no ha sido rara la ocasión en que he visto la entera pila interna de mensajes de error generados en sites JSP o PHP. Sin ir mas lejos, la primera versión de la web del Continental te sacaba todos sus mensajes JSP cada vez que salia un error (cosa muy frecuente entonces)

Como sabran estoy yendo a Perú en Septiembre, así que como contaba entonces realice mi investigación de precios (con los resultados conocidos), lo que no conté entonces fue de este error que aparecio mientras buscaba precios en la web de Air Plus Comet

Lindo, no? Una hermosa query SQL para que todo el mundo intuya como van tus tablas mySQL, y de ahí … hasta la cocina.

Por cierto, los webmasters de El Comercio bien harían en revisar el siguiente articulo: 25+ ASP Tips to Improve Performance and Style, articulo muy especifico a ASP y que me sirvió de gran ayuda antes de la llegada de ASP.NET.

Joder con el puto AJAX de los cojones!!

Posted on by ecardenas

Como decia un profesor en el IE “mis muertos los cuento frios”, asi que recien ahora puedo contar algo de mi experiencia profesional reciente, que espero que sea de utilidad para el que le interese la gestion del desarrollo de software.

Con todos estos años de practica, algunas cosas se te quedan claras en base a las experiencias pasadas y tratas de aplicarlas en la medida de lo posible, lamentablemente a veces no se esta en la posicion de aplicarlas y este fue el caso.

Como decia, algunas cosas se te quedan claras y con fundamento, en este caso tenia claro que avanzado un proyecto no es conveniente meter una tecnologia nueva salvo que: Estuviera focalizada en un sector con poca interaccion con el resto de la aplicacion, o que estuviera claro que fuera completamente compatible y/o evolutiva de la tecnologia empleandose en ese momento.

Pareceria una politica simple y razonable de seguir, pero quienes estan en informatica sabran que estas dos palabras no estan precisamente a la orden del dia en la gestion de proyectos, aunque debo reconocer que he tenido jefes que sin tenido la habilidad suficiente como para llevar razonablemente el proyecto y los intereses de los stakeholders.

Se trataba de una aplicacion Web para uso interno, donde como consecuencia del alto numero de datos a ingresar eran frecuentes las idas y vueltas al servidor, ocasionando un efecto de parpadeo o “pantallazo” que era incomodo para algunos usuarios. Sin ir al detalle tecnico (conocido para quienes conocen esta tecnologia) sabran que este efecto es consecuencia del modelo que trajo ASP.NET el cual es necesario para brindarnos una facilidad de desarrollo que habiamos perdido cuando se paso de la Programacion Visual (con VB, Delphi o PowerBuilder) a desarrollar para la Web (quien ha programado CGIs, ASP Clasico o PHP3 sabe de lo que hablo).

Lamentablemente las quejas salieron cuando la estructura de la aplicacion estaba completada en un 80%, asi que poco se podia hacer (yo proponia aumentar la capacidad de procesamiento del servidor), hasta que alguien planteo la posibilidad de usar lo que recientemente se ha dado por denominar AJAX (aunque las tecnologias base han estado disponibles desde hace tiempo) para solucionar el problema y claro …. se dio el visto bueno a dicha propuesta.

Como ya he comentado la aplicacion ya habia avanzado bastante pero aun faltaban ajustes finales, por lo que se inicio un desarrollo paralelo, por un lado se trataba de replicar en AJAX la funcionalidad existente, y por otro lado se continuaba el refinamiento en la tecnologia actual hasta llegar a un punto de convergencia para integrar las modificaciones hechas en paralelo (las cuales tenian que apuntarse con sumo cuidado).

Cuando correspondio a que se manipulara mis modulos recien cai en la cruda realidad, trabajar con AJAX (al menos en la version que se utilizo) involucraba un paso atras en lo que habiamos ganado en funcionalidad de desarrollo con ASP.NET (si quieres la explicacion marciana ve al final del articulo) siendo mucho mas complicado depurar la aplicacion obligandote a mantener un doble juego de variables y de logica de la pantalla, ya que como la tecnologia se inyecto estando la aplicacion avanzada no hubo alternativa, siendo otra la situacion si se hubiera tenido un desarrollo en AJAX puro desde el principio o con modelo ASP.NET como lo teniamos.

La desesperacion para tratar de ajustar y que vuelvan a funcionar cosas que YA ESTABAN BIEN nos llevo en algunos momentos a decir la frase que titula este post, porque de veras…. era desesperante que cosas sencillas como asignar u obtener el valor de un control de una variable fuera algo complicadisimo.

En honor a la verdad debo decir que el proyecto salio adelante y ya esta en produccion, pero no dejo de pensar que los dos meses (como minimo) que se agregaron al proyecto multiplicado por el coste de 2 recursos (igualmente como minimo) hubiera podido alcanzar para la adquisicion de un mejor servidor, sin el inconveniente de la poca mantenibilidad que adquirio el proyecto.

En resumidas cuentas con ASP.NET uno se acostumbra a manipular directamente los valores de los diversos controles que estan en la pantalla, con AJAX tareas simples como requerian la regeneracion de un XML con el conjunto de valores de los controles, siendo necesario implementar funciones (mas complejas) para recuperar los valores utilizados pues los valores que usa por defecto ASP.NET se vuelven completamente inutiles, mas aun: como en este caso teniamos logica duplicada en ciertos momentos debia hacerse una multiple verificacion para saber que conjunto de variables estaba informado, so pena de que la aplicacion fallara.