domingo, noviembre 20, 2011

ERPs: Aviso a navegantes

Este es un asunto importante, que entra en el terreno de la ética: la credibilidad que puede esperarse del consejo de una empresa que vende un producto de software (en rigor, esto vale para todo vendedor). Es  interesante ver que las observaciones que siguen a continuación vienen de una consultora de primera línea: el comentario está originado en la presentación de Dennis Gaughan en la Conferencia de Gartner Australia, esta semana pasada. No tenemos el contenido directo de su presentación, pero sí su resumen tomado por dos publicaciones de tecnología, al menos: Business Insider, e IT News de Australia.
Esta es la nota en Business Insider:
The four big software vendors -- Microsoft, Oracle, IBM, and SAP -- have hidden motives that customers need to understand, otherwise they might be pushed into buying products and services that don't fit their needs.
That's the takeaway from a recent Gartner talk in Australia, reported by IT News.
At a symposium this week, Gartner analyst Dennis Gaughan explained what the four big vendors are really trying to do, based on Gartner's experience with its clients.
  • Microsoft mainly wants to protect Windows and Office. Microsoft is a platform company, and its main goal is to protect its highly lucrative Windows and Office monopolies, while establishing other platforms that will be hard for customers to break away from later. New functionality is "drip fed" to users of those core platforms, but new products exist to protect the core. He advised extreme caution before moving to Office 365, and said not to slip into an "all-Microsoft" mentality.
  • Oracle products don't really work well together. Oracle's sales force is extremely aggressive about pushing a suite of products, but has much fewer integration points than SAP. In fact, integration is usually left entirely up to the customer. Oracle is also very reluctant to talk about product roadmaps for fear that future products will cannibalize existing ones. The company makes more than 90% of its profits through maintenance fees, and will do whatever it takes to keep those fees flowing in. Gaughan also expressed some surprise that so many customers keep working with Oracle despite reporting that Oracle is "the most difficult vendor to deal with."
  • IBM wants to take over your IT strategy. IBM bills itself as a thought leader, but its real business is selling consulting services. To thrive, IBM account managers try to take control of a company's IT strategy so they can keep pushing new products. Gaughan recommends taking a collaborative or partner approach.
  • SAP confuses customers with pricing. A lot of SAP customers ask Gartner for help figuring out SAP's pricing and licensing, as SAP has unusual terms for billing data going into and out of systems. Gaughan also said that a big technology transition that was driving SAP revenue for the last few years -- moving existing customers from the old R/3 system to the newer Business Suite -- is almost done, which means SAP will have to be more aggressive with maintenance fees. He recommended locking in maintenance prices now.
Overall, Gaughan said that most of the innovation being done in these companies is in their research arms. Their real goal is protecting the status quo for as long as possible.
 Frecuentemente, las empresas son conducidas a compras que, especialmente en el campo de ERPs o grandes infraestructuras de hardware, pueden llevarlas a gastos interminables e inabordables, y luego, a un fracaso difícil de levantar. Frente a la idea de la visión del software como un commodity, algo que se puede tercerizar, estoy convencido que una compañia mediana o grande debe defender y capacitar sus recursos humanos tecnológicos, y debe defender un punto de vista y una estrategia propia, confrontada, si, aceptando la consulta de terceros, pero con capacidad de maniobra e independencia de criterio. No todas las estrategias son adecuadas para cada caso.
De aquí se derivan dos o tres líneas de discusión, que trataremos de seguir: el valor de un ERP "empaquetado", la encrucijada de la implementación de un ERP, la ética esperable de una consultoría. Será en el futuro, si es posible.

jueves, noviembre 17, 2011

Críticas a OOP

James Hague, programador funcional (o por lo menos por un tiempo), interesado en Python y Erlang, hablando del primero, hace una referencia a la programación orientada a objetos, puntualizando lo que lo aparta de oop:
 (Don't Distract New Programmers with OOP
[...] The shift from procedural to OO brings with it a shift from thinking about problems and solutions to thinking about architecture. That's easy to see just by comparing a procedural Python program with an object-oriented one. The latter is almost always longer, full of extra interface and indentation and annotations. The temptation is to start moving trivial bits of code into classes and adding all these little methods and anticipating methods that aren't needed yet but might be someday.

When you're trying to help someone learn how to go from a problem statement to working code, the last thing you want is to get them sidetracked by faux-engineering busywork. Some people are going to run with those scraps of OO knowledge and build crazy class hierarchies and end up not as focused on on what they should be learning. Other people are going to lose interest because there's a layer of extra nonsense that makes programming even more cumbersome.

At some point, yes, you'll need to discuss how to create objects in Python, but resist for as long as you can. 
Esta nota de Hague es de marzo de este año. Por casualidad o no, ese mes otro entusiasta de la programación funcional desacredita totalmente oop. Y nada menos que en un curso introductorio de Carnegie Mellon.
Sería muy interesante conocer un balance del curso terminado.

lunes, noviembre 07, 2011

La década de Eclipse en InfoQ

Hablamos en octubre de los diez años de historia de Eclipse, pero el artículo de InfoQ editado hoy es interesante por su crónica histórica, que destaca el gran aporte de IBM desde el comienzo:
Ten years ago today, an open-source Java development environment called Eclipse was released for both Windows and Linux. Eclipse 1.0 is still available for download for Windows (98/ME/2000/NT) and Linux (RH 7.1), along with translation packs (also provided by IBM).
The Eclipse consortium itself wasn't founded until 29th November 2001, and the Eclipse Foundation wasn't created until 2nd February 2004; so today marks the 10th anniversary of the initial release of the software rather than the organisation itself.
Eclipse 1.0 was the result of a $40 million valued donation of source code by IBM. Back at the turn of the millennium, there was a plethora of Java development environments available, such as Symantec VisualCafé, Borland JBuilder and IBM's own Visual Age for Java. However, as predominantly Java-only environments, they did not cope well initially with the advance of Servlets and HTML pages (and later, JSPs). In particular, IBM's Visual Age for Java used an object database to store source code instead of files; so it was not able to develop the nascent Enterprise Java applications that were becoming increasingly popular.

(...) 
With the initial release of IBM WebSphere in June 1998 (at that time, just a Servlet engine), IBM needed a development tool to be able to complement its existing Java development tools. IBM developed WebSphere Studio to provide the HTML editing, released as far back as September 1998 with the combined release of WebSphere Studio 1.0 and WebSphere Application Server 1.1. WebSphere Studio would go on to form the foundation of Eclipse 1.0, and on 5th November 2001 was announced:
IBM's new WebSphere Studio tools are the first commercially available tools built on open source software, code-named Eclipse, which is being donated by IBM to a new community of software tool vendors. Developers working on WebSphere Studio and other Eclipse-based tools use a common, easy-to-use interface that provides a consistent "look and feel," regardless of vendor, which cuts training costs for customers.
At the time, IBM was losing developers from its flagship Visual Age for Java product. A new breed of development tools – such as Apache Ant, which was publicly released as version 1.1 in 19th July 2000 – operated purely on the Java source files. As a result, Visual Age was not able to take advantage of these or other tools built around creating dynamic websites. Other commercial tools were gaining in popularity, but each offered a slightly different interface and actions. Whether IBM's decision to release the core of WebSphere Studio as open source was driven by a means to increase familiarity with its commercial products, or whether it was a foresighted decision to enable greater collaboration between competitors, the release of Eclipse achieved two specific goals; it became a de-facto Java IDE and went on to become an organisation and tool chain supported by a multitude of different companies.
It's also worth acknowledging that Eclipse wasn't the first open-source IDE for Java; NetBeans was open-sourced in June 2000. However, whilst NetBeans was based on the less powerful (at the time) Swing, Eclipse was based on an entirely new widget toolkit that adopted the OS's own native widget set for displaying the user interface. Over time, this speed discrepancy has reduced; although SWT continues to provide better native integration than Swing renderings as operating systems have evolved.
The only other commercial Java development environment to survive from the period was IntelliJ, released in January 2001. All of the other significant commercial efforts either folded or moved towards running on an Eclipse runtime. 

 (...)
The Eclipse Consortium initially consisted of Borland, IBM, Merant, QNX Software Systems, Rational Software, RedHat, SuSE, and TogetherSoft. Initially released under the IBM created Common Public License, the platform initially focussed on the Java platform with code taken from the WebSphere Studio product, which itself grew out of Visual Age Micro Edition.
Visual Age for Java was both based on and implemented with Visual Age for Smalltalk. It was not until J2ME development with the re-implementation of Visual Age for Java as Visual Age Micro Edition that the toolset was re-implemented in Java, which went on to become WebSphere Studio and then Eclipse. Visual Age for Smalltalk was inspired by the Interface Builder in Nextstep. It's also worth noting that this was all done by the Ottwa-based Object Technology International, which was acquired by IBM in 1996, which is why many of the Eclipse committers, and indeed subsequent foundation, are based in Ottwa, Canada.
With Borland, Rational and other traditional Java developers behind Eclipse, it quickly took off, reaching an average 4000 downloads/day in the first month. (IBM would later go on to acquire Rational Software during December 2002–February 2003.) QNX aimed at the embedded market, and joined in to provide CDT 1.0 in March 2003, after less than a year's development. Today, Java still leads the development pack with CDT running a close second.

miércoles, noviembre 02, 2011

WinRT en el laboratorio...

 Rafael Ontiveros publica un interesante artículo sobre WinRT, tratando de adivinar las características de un producto que todavía es más trabajo de mercadeo que realidades. Aprecio su interés por ir a las cosas mismas, antes que adherir a las alabanzas tempranas. Fundamental, pone en duda el alcance de WinRT:
WinRT y Metro se ejecutan, como todo lo demás, sobre Win32, con las ventajas y los inconvenientes que eso pueda tener. No me malinterpretéis: no hay nada malo que la arquitectura sea diferente a la indicada en el gráfico de arriba, lo que está mal es que Microsoft nos mienta tan descaradamente. Simplemente eso.
Si lo han hecho así, por algo será y sus motivos tendrán, y es entonces cuando, ya definitivamente, yo tenía razón: Windows ya no es Windows NT, y su grandiosa arquitectura por bloques se ha perdido en el camino. Y esto sí que es malo, bastante malo, porque estamos volviendo a un batiburrillo de código como es, por cierto, el OS X (quizás algún día hable de ello).
Vosotros mismos podéis comprobarlo sin problema alguno y de forma muy rápida. Tenéis que construir dos aplicaciones, una WinRT en C++/CX y otra clásica de Win32. No hay más que utilizar las plantillas por defecto sin ningún cambio.
Eso sí, hay que hacerlo a partir de la versión Developer de 64 bits de Windows 8, e instalar una versión de la MSDN, porque la Express creo que no es capaz de generar programas Win32 puros.
(...) He llamado “TestWin32” a mi aplicación tradicional, que genera una ventana de Windows normal y corriente utilizando directamente el API de Win32. A la Metro la he llamado “TestSplitApplication”. Una vez generadas, tenemos que compilarlas.
(...) Si ahora nos vamos a la carpeta en donde está almacenado el proyecto (que podemos hacer desde el mismo IDE posicionándonos en el nombre de la solución en el Explorador y elegimos Open Folder in Windows Explorer), carpeta Debug, encontraremos el ejecutable del programa nativo (TestWin32.exe) y dentro de la carpeta TestSplitApplication, el de la aplicación Metro.
(...) Si nos diera por abrir, por ejemplo, uno de los dos KERNEL32.DLL, veríamos que ambas DLL son la misma con las mismas dependencias y exportaciones. Por lo tanto, ambas aplicaciones dependen del mismo subsistema.
Reitero que es una tontería, pero no lo es cuando intentan engañarte.
Lo que sí parece han hecho ha sido romper KERNEL32.DLL en otros ficheros más pequeños que contemplan subconjuntos de lo que en versiones anteriores había en él. Quizás de esta forma reduzcan la huella de memoria evitando cargar sub ficheros cuando estos no se vayan a utilizar.
(...) 
Esto nos lleva a un tercer problema: parecer ser que una aplicación Metro no puede ejecutar funciones de Win32, y una de Win32 tampoco de WinRT.
¡¡Pero si es el mismo subsistema!!
Pues bien, estamos ante una limitación artificialmente impuesta por Microsoft sin ningún motivo técnico aparente… con lo guapo que sería hacer aplicaciones Win32 con C++/CX…

 Conocido gracias a Bruno Capuano.