Industria del Software: Misión española en Buenos Aires

Recojo la nota de Antonio Más, que conociera gracias a Emilio, de I2E. Antonio participó en la semana de conversaciones entre empresas de Software de España y Argentina desarrollada hace pocos días. Su resumen es el mejor que he leído en mucho tiempo sobre el estado actual de la industria del software en Argentina. Una visión externa para medir el futuro posible:

• Los argentinos están muy preparados. Hay una base de empresas importantes, con gente formada, buenas universidades, abundancia de ingenieros y entramado empresarial en todos los niveles –de grandes multinacionales a PYMES-.
• Tanto la economía como la población tiene una gran concentración en el Gran Buenos Aires que suma casi la mitad de la población y buena parte de las empresas. No obstante oras ciudades como Córdoba, Mendoza, Rosario o La Plata tienen empresas pujantes que, en muchas ocasiones, son contratadas por las ubicadas en la capital.
• Hay una apuesta nacional por el desarrollo de software y ello ha implicado una ley a la medida, la creación de un barrio tecnológico al estilo @22 y fuertes estímulos a la exportación con la creación de la ley de Promoción de la Industria del Software y Servicios Informáticos
• Muchas empresas ya están exportando e incluso adaptan sus horarios para coordinar la relación, entrando algunos de ellos a las 6 de la mañana para incrementar las horas simultáneas con clientes europeos.
• La mayoría de los exportadores tienen ya una buena base de clientes en EEUU incluyendo un abanico muy amplio. Desde Google –aquí se ha desarrollado parte de CheckOut y OpenSocial- a PYMES de un par de empleados.
• La mayoría de los exportadores tienen en las empresas de desarrollo de software y diseño web a sus principales clientes.
• Las empresas bonaerenses empiezan a tener problemas en captar personal cualificado y muchos de ellos tienen freelances o otras empresas fuera de la zona a las que subcontratan en puntas de trabajo.
• La forma de operar con ellos puede ser tanto por proyecto –precio cerrado sobre un desarrollo concreto- como por horas –contratación de recursos cualificados por horas-. El coste de hora de un programador con más de 3 años de experiencia ronda de los 12 a los 25 euros.
• Hay muchas más empresas con conocimiento en Java y .Net pero pocas en PHP o Ruby.

Sigue un análisis detallado de aquellas empresas con las que se entrevistó, que dan una idea de volúmen de iniciativas, y oportunidades para todos los que se lo propongan.

Como no podía ser de otra manera, en otro post describe los puntos débiles y cargas que se deben afrontar. Y como en otros sectores que podrían aportar crecimiento a la economía, encontramos la carga que reclama el Estado. Es de observar que las iniciativas que ayudaron a salir de la crisis, en general han nacido del esfuerzo de particulares, con poca colaboración de la Administración. Así, apunta Antonio:

Siempre nos quejamos de impuestos, ya sea como aprticulares o como empresarios. Así que, aunque sea un mal consuelo, os dejo unos datos de como está la situación impositiva en Argentina.

Toda empresa debe pagar lo siguiente:

Impuesto sobre ingresos brutos. Un 3% directo sobre la facturación a liquidar mensualmente -independientemente de tus beneficios-.

Impuesto sobre las transferencias. Un 0,6% con cada movimiento de ingreso o pago en cuenta. En total, un 1,2% que el banco cobra y liquida posteriormente al estado.

Impuesto de utilidades o nuestro equivalente a sociedades. 35% sobre el beneficio.

IVA o Impuesto sobre el Valor Añadido. 21% del total.

En especial me asombra ese 4,2% sobre las ventas entre los dos primeros impuestos.

Para más dolor, añadirle que cualquier dinero que se recibe del extranjero debe de ser canalizado a través de un banco central que despues retrasa el pago hasta tu cuenta final entre 15 y 30 días. Esto es, un cliente español paga a un banco que actúa como consolidador y controlador para después liquidar a la cuenta del empresario argentino.

Plex en Eclipse

Christopher Smith, en su tiempo libre, está desarrollando en SourceForge un plugin para soportar el desarrollo con Plex. Para quien le interese la combinación de Eclipse/Plex.
De su comunicación en el foro de Plex:

The complete Eclipse project for Plex Services for Eclipse is now hosted at SourceForge.

The project is located at http://sourceforge.net/projects/plexservices/

The subversion repository is located at https://plexservices.svn.sourceforge.net/svnroot/plexservices

This project is licenced with the Apache 2.0 open source licence so please use it and contribute.

If you want to just install the plugin, an Eclipse update site is available at http://adcaustin.com/eclipse/

There is a half completed setup page on the Plex WIKI.

Please remember, I'm doing this in my spare time. If it needs a feature or a fix, I will try and help as best as my schedule allows.

If you have a question on how you can extend it and want to share, I will be MORE than happy to answer.

The plugin currently requires at least Eclipse 3.3 and I'm targeting my future development for 3.4.

Como Christopher dice, en la Wiki de Plex se puede encontrar más información:

How does Eclipse relate to Plex?

Plex can generate Java source code for very functional and usable applications. Building, Debugging, Deploying and Managing the generated source is not an easy or straight forward task. Eclipse can handle these tasks for you.

Plex 5.X ships with Microsoft's NMAKE as it's Java Builder (6.0 uses ANT). Building a large Applications can take a very long time. Eclipse can build your application in a fraction of the time. Diagnosing build errors with the compile listings from NMAKE is clumsy, if not impossible. Finding and discovering how to correct build errors in Eclipse is quite simple.

Debugging Java without an IDE can be very difficult. Debugging is inherent part of the Eclipse Platform.

Deploying a Plex Java application is a cumbersome manual process. Eclipse, along with the integrated ANT support, can automate the whole process. You can even create J2EE projects in Eclipse to automate the packaging and deployment of Plex EJB Proxy applications to J2EE servers.

Managing a single developer environment of Plex generated source code and other required artifacts is difficult to impossible, never mind trying to do so in a multi-developer environment. Eclipse provides a "workspace" for each developer and source repository support for source control products like CVS and Subversion.

Windows 7 en el camino del Vista?

Computerworld publica un pequeño artículo de Eric Lai, que extrae la conclusión de que en el nuevo Windows trabajan unas 2000 personas, en base a declaraciones de Steven Sinofsky, de Microsoft.

"We create feature teams with n developers, n testers, and 1/2n program managers," Sinofsky wrote in a four-page blog that introduced his views on managing large-scale software development. "On average a feature team is about 40 developers across the Windows 7 project."

Based on that arrangement, each feature team would appear to have about 40 developers writing code, an equal number of beta testers -- which Sinofsky separately described as "software development engineers in test" -- and about 20 program managers.

In other words, that would be 2,000 developers creating or testing Windows 7 code, overseen by 500 managers.

Microsoft's public relations firms declined to confirm or clarify those figures.

Es probable que en estos términos, Windows 7 tenga viscisitudes parecidas a las de Vista...

(Thinking in Objects)

Henry Story, en su blog The Sun BabelFish, plantea un problema que mide los límites de la programación orientada a objetos, y la contrapone a las herramientas usuales en la Web Semantica. Con un ejemplo basado en el mundo del autismo, Story presenta un mundo de vistas personales, no de objetos reales. Probablemente el ejemplo usado no fue muy afortunado, particularmente en cómo implementarlo en OOP y en su contrapartida con RDF. Henry fue muy criticado, y en general con acierto, tanto en su expresión del problema en OOP como en la correlación parcial entre ambos ejemplos. Sin embargo, la presentación del problema es estimulante para medir OOP y sus límites:

In order to be able to have a mental theory one needs to be able to understand that other people may have a different view of the world. On a narrow three dimensional understanding of 'view', this reveals itself in that people at different locations in a room will see different things. One person may be able to see a cat behind a tree that will be hidden to another. In some sense though these two views can easily be merged into a coherent description. They are not contradictory. But we can do the same in higher dimensions. We can think of people as believing themselves to be in one of a number of possible worlds. Sally believes she is in a world where the ball is in the basket, whereas Ann believes she is in a world where the ball is in the box. Here the worlds are contradictory. They cannot both be true of the actual world.

To be able to make this type of statement one has to be able to do at least the following things:

• Speak of ways the world could be
• Refer to objects across these worlds
• Compare these worlds

Henry propone un ejemplo (imperfecto y criticado por varios de sus lectores):

Let us illustrate this with a simple example. Let us see how one could naively program the puppet play in Java. Let us first create the objects we will need:

Person sally = new Person("Sally");
Person ann = new Person("Ann");
Container basket = new Container("Basket");
Container box = new Container("Box");
Ball ball = new Ball("b1");
Container room = new Container("Room");

So far so good. We have all the objects. We can easily imagine code like the following to add the ball into the basket, and the basket into the room.

basket.add(ball);
room.add(basket);

Perhaps we have methods whereby the objects can ask what their container is. This would be useful for writing code to make sure that a thing could not be in two different places at once - in the basket and in the box, unless the basket was in the box.

Container c = ball.getImmediateContainer();
Assert.true(c == basket);
try {
     box.add(ball)
     Assert.fail();
} catch (InTwoPlacesException e) {
}

All that is going to be tedious coding, full of complicated issues of their own, but it's the usual stuff. Now what about the beliefs of Sally and Ann? How do we specify those? Perhaps we can think of sally and ann as being small databases of objects they are conscious of. Then one could just add them like this:

sally.consciousOf(basket,box,ball);
ann.consciousOf(basket,box,ball);

But the problem should be obvious now. If we move the ball from the basket to the box, the state of the objects in sally and ann's database will be exactly the same! After all they are the same objects!

basket.remove(ball);
box.add(ball);
Ball sb = sally.get(Ball.class,"b1");
Assert.true(box.contains(sb));
//that is because
Ball ab = ann.get(Ball.class,"b1");
Assert.true(ab==sb);

There is really no way to change the state of the ball for one person and not for the other,... unless perhaps we give both people different objects. This means that for each person we would have to make a copy of all the objects that they could think of. But then we would have a completely different problem: namely deciding when these two objects were the same. For it is usually understood that the equality of two objects depends on their state. So one usually would not think that an physical object could be the same if it was in two different physical places. Certainly if we had a ball b1 in a box, and another ball b2 in a basket, then what on earth would allow us to say we were speaking of the same ball? Perhaps their name, if it we could guarantee that we had unique names for things. But we would still have some pretty odd things going on then, we would have objects that would somehow be equal, but would be in completely different states! And this is just the beginning of our problems. Just think of the dangers involved here in taking an object from ann's belief database, and how easy it would be to by mistake allow it to be added to sally's belief store.

Henry aboga por el uso de RDF (Resource Description Framework) como herramienta capaz de expresar adecuadamente las distintas vistas de un problema, en un universo de vistas en lugar de objetos. Pero sin duda, esto merece otro espacio.
De los comentarios que siguen al artículo, particularmente abre un poco más el que hiciera Ryan, y la respuesta de Henry
Ryan:

I really like your analysis of OOP and it's relation to autism. I have never thought of it in such a way, but it does make a lot of sense (when I am able to remove my preconceptions). However, why is autism bad in this scenario (if you are even implying it)? I can understand that if our perspective is not an omniscient one then this can fail us. Would you please provide a applied example of the problem at hand with relation to your point on Semantic Web? Thanks a lot!

Henry:

Thanks for asking Ryan. Yes there are a lot of examples. The following article "Extending the Representational State Transfer (REST) Architectural Style for Decentralized Systems" which you can find here
http://portal.acm.org/citation.cfm?id=999447
makes the point about how the distance between the source of a message and the recipient of a message makes perfect immediate communication impossible, if you think of it as resources having the same access to an object. But if you think of it as message passing then you can do some interesting things... Ok I read that quickly, but that is what made me decide to write this article out today.

In the AddressBook I am writing, which I describe in an audio slide cast here:
http://blogs.sun.com/bblfish/entry/building_secure_and_distributed_social
I need to get data from distributed places around the web. This can only be done seriously if you accept that there will be spammers, liars, and just simply wrong data out there. So though you may by default merge data, you may want to make it easy to unmerge it too. I wrote about that in more detail here:
http://blogs.sun.com/bblfish/entry/beatnik_change_your_mind

As I said, if you are writing tools, that you can think of as physical, mechanical objects, that don't have to have points of view on the universe, say if you are writing a web browser, a calculator, or some such thing, then this is not important. But as soon as you want to mesh the information on the web, you will need to take the opinion of others into account. We are fast moving to a world where this is going to become more and more important.

In any case it is good to know the limitations of your tools. :-)

En el mismo sentido, apunta Benjamin Damman:

Hmmmm. Parts of your intriguing article made me think of erlang.

"When one fetches information from a remote server one just has to take into account the fact that the server's view of the world may be different and incompatible in some respects with one's own. One cannot in an open world just assume that every body agrees with everything. One is forced to develop languages that enable a theory of mind. A lot of failures in distributed programming can probably be traced down to working with tools that don't."

Erlang was created for coding highly fault-tolerant (and distributed) systems; characteristics stemming this fact might make it an example of a language that 'enables a theory of mind.'

http://erlang.org/white_paper.html

Un papel sugerente de ideas, mas allá de los puntos observados por su crítica.

El proyecto Oslo

Con adelantos apenas delineados, se incrementan las noticias sobre el proyecto Oslo. Si el proyecto desarrollara el ambiente de modelado de Microsoft, y si pudiera ensamblar los distintos esfuerzos anteriores, quizá el conjunto pudiera tomar un rumbo más consistente. Durante 2008 tendremos una idea más clara del tema.
Ron Jacobs dice, anunciando su presentación junto a David Chappell:

Microsoft's "Oslo" project aims at creating a unified platform for model-based, service-oriented applications. This new approach will affect the next versions of several products and technologies, including the Microsoft .NET Framework, Microsoft Visual Studio, Microsoft BizTalk Server, Microsoft System Center, and more. Although many details of "Oslo" won't be public until later in 2008, this session provides an overview of what Microsoft has revealed so far. Along with a description of the problems it addresses, the session includes a look at several new "Oslo" technologies, including a general-purpose modeling language, role-specific modeling tools, a shared model repository, and a distributed service bus.

Uno de los nuevos elementos de Oslo, es el impulso al lenguaje D. Darryl Taft dice:

“The language was designed with an RDBMS [relational DBMS] as very, very, very much top-of-mind, so that we have a very clean mapping,” Lovering said. “But the language is not hard-wired to an RDBMS or relational model. And the language is actually built against an abstract data model. We represent the program itself also in that same abstract data model, which is a very LISP-ish idea—you know, where the whole program itself is the same data structure on which it operates.”

En su sitio dedicado a SOA, se resume así las características de Oslo:

”Oslo” is the codename for Microsoft’s forthcoming modeling platform. Modeling is used across a wide range of domains and allows more people to participate in application design and allows developers to write applications at a much higher level of abstraction. “Oslo” consists of:

• A tool that helps people define and interact with models in a rich and visual manner
• A language that helps people create and use textual domain-specific languages and data models
• A relational repository that makes models available to both tools and platform components

Tres elementos se destacan, en los adelantos que funcionarios y allegados a Microsoft van develando: la mencionada utilización de un nuevo lenguaje (D), el énfasis en el modelado y la abstracción, y la idea de un repositorio que ordene los recursos participantes. No es algo nuevo (la idea del repositorio como sustento de las herramientas de modelado ya había generado iniciativas de Microsoft y otros en los 90), pero el conjunto es aplicado sobre recursos que han madurado y sobre los que se ha discutido mucho ya.
En el sitio de Microsoft sobre SOA, algunas ideas expuestas por Bob Muglia, arrojan luz sobre el futuro que Oslo traerá:

“Oslo” and a Mainstream Approach to Modeling

Modeling has often been heralded as a means to break down technology and role silos in application development to assist IT departments in delivering more effective business strategies. However, while the promise of modeling has existed for decades, it has failed to have a mainstream impact on the way organizations develop and manage their core applications. Microsoft believes that models must evolve to be more than static diagrams that define a software system; they are a core part of daily business discussions, from organizational charts to cash flow diagrams. Implementing models as part of the design, deployment and management process would give organizations a deeper way to define and communicate across all participants and aspects involved in the application lifecycle.

In order to make model-driven development a reality, Microsoft is focused on providing a model-driven platform and visual modeling tools that make it easy for all “mainstream” users, including information workers, developers, database architects, software architects business analysts and IT Professionals, to collaborate throughout the application development lifecycle. By putting model-driven innovation directly into the .NET platform, organizations will gain visibility and control over applications from end-to-end, ensuring they are building systems based on the right requirements, simplifying iterative development and re-use, and enabling them to resolve potential issues at a high level before they start committing resources.

Modeling is a core focus of Microsoft’s Dynamic IT strategy, the company’s long-term approach to provide customers with technology, services and best practices to enable IT and development organizations to be more strategic to the business. “Oslo” is a core piece of delivering on this strategy.

“The benefits of modeling have always been clear, but traditionally only large enterprises have been able to take advantage of it and on a limited scale. We are making great strides in extending these benefits to a broader audience by focusing on three areas. First, we are deeply integrating modeling into our core .NET platform; second, on top of the platform, we then build a very rich set of perspectives that help specific personas in the lifecycle get involved; and finally, we are collaborating with partners and organizations like OMG to ensure we are offering customers the level of choice and flexibility they need.”

Bob Muglia, Senior Vice President, Microsoft Server & Tools Business

Esperaremos más noticias...

Microsoft ingresa en OMG

Consecuente con su reciente viraje hacia la aceptación de UML, Microsoft anunció este miércoles su ingreso a la OMG. Largo camino desde los tiempos de las observaciones sarcásticas sobre los esfuerzos del Object Management Group...

REDMOND, Wash. — Sept. 10, 2008 — Microsoft Corp. today outlined its approach for taking modeling into mainstream industry use and announced its membership in the standards body Object Management Group™ (OMG™). Modeling is a core focus of Microsoft’s Dynamic IT strategy, the company’s long-term approach to provide customers with technology, services and best practices to enable IT and development organizations to be more strategic to the business.

Modeling often has been heralded as a means to break down technology and role silos in application development to assist IT departments in delivering more effective business strategies. However, although the promise of modeling has existed for decades, it has failed to have a mainstream impact on the way organizations develop and manage their core applications. Microsoft believes that models must evolve to be more than static diagrams defining a software system; they are a core part of daily business discussions, from organizational charts to cash flow diagrams. Implementing models as part of the design, deployment and management process would give organizations a deeper way to define and communicate across all participants and aspects involved in the application life cycle.

To make model-driven development a reality, Microsoft is focused on providing a model-driven platform and visual modeling tools that make it easy for all “mainstream” users, including information workers, developers, database architects, software architects, business analysts and IT professionals, to collaborate throughout the application development life cycle. By putting model-driven innovation directly into the Microsoft .NET platform, organizations will gain visibility and control over applications from end to end, ensuring that they are building systems based on the right requirements, simplifying iterative development and re-use, and resolving potential issues at a high level before they start committing resources.

“We’re building modeling in as a core part of the platform,” said Bob Muglia, senior vice president, Server and Tools Business at Microsoft. “This enables IT pros to specify their business needs and build applications that work directly from those specifications. It also brings together the different stages of the IT life cycle — connecting business analysts, who specify requirements, with system architects, who design the solution, with developers, who build the applications, and with operations experts, who deploy and maintain the applications. Ultimately, this means IT pros can innovate and respond faster to the needs of their business.”

OMG has been an international, open-membership, not-for-profit computer industry consortium since 1989. OMG’s modeling standards include the Unified Modeling Language™ (UML^®) and Business Process Management Notation (BPMN™). In addition to joining the organization, Microsoft will take an active role in numerous OMG working groups to help contribute to the open industry dialogue and assist with evolution of the standards to meet mainstream customer needs. For example, Microsoft is already working with the finance working group on information models for insurance business functions related to the property and casualty industry, and will eventually look to expand those models so that they can be applied to P&C, life and reinsurance. Another early focus will be on developing specifications for converting messages across the various payments messaging standards.

“Microsoft has always been one of the driving forces in the development industry, helping to make innovation possible but also simplifying many of the most challenging aspects of the application development process,” said Dr. Richard Mark Soley, CEO at OMG. “In less than 10 years, OMG’s UML, a cornerstone of the Model Driven Architecture initiative, has been adopted by the majority of development organizations, making OMG the seminal modeling organization and supporting a broad array of vertical market standards efforts in healthcare, finance, manufacturing, government and other areas. Microsoft’s broad expertise and impact will make its membership in OMG beneficial to everyone involved.”

Developers can begin to implement model-driven approaches today through innovations such as Extensible Application Markup Language (XAML) — the declarative model that underlies Windows Presentation Foundation and Windows Workflow Foundation — and ASP.NET MVC, which deeply integrates model-driven development into the .NET Framework and makes it easy to implement the model-view-controller (MVC) pattern for Web applications. Both XAML and MVC are examples of models that drive the actual runtime behavior of .NET applications. These are part of Microsoft’s broader companywide efforts to deliver a connected platform modeling, which includes technologies being delivered across both “Oslo” and Visual Studio “Rosario” initiatives.

(En Microsoft PressPass)

InfoQ le dedica un artículo que reseña los antecedentes, y algunas de las voces que aquí también se comentaron.

Google Chrome en InfoQ

En estos días, varios millones de entusiastas están probando Chrome, el browser de Google (me incluyo), en su primer lanzamiento público. Evidentemente, se ha lanzado una carga de profundidad en el mercado, que, como otros productos de su dueño, apenas comienza, y mucho más veremos.
Geoffrey Wiseman, en InfoQ, publica un breve pero abarcador artículo sobre estado y perspectivas, que es conveniente leer.
En cuanto al escenario en la industria, Wiseman estima:

Many people have heralded the launch as the renewal of the browser wars once fought between Microsoft and Netscape / Mozilla (those were the primary contenders, although every browser has its contigent willing to trumpet its strengths). Some are willing to count Chrome out already, while others are adopting a wait and see stance.

Many argue that Google doesn't wish to compete with other browsers, simply to advance the state of network-delivered applications to where they are indistinguishable from desktop applications and in so doing, push the operating system into the background.

In particular, people telling this story love to cast Microsoft in the opposing role, so that one can imagine the two titans clashing.

En su resúmen técnico, Wiseman escribe:

The Chrome browser is the result of the Chromium project, which connects the WebKit web browser engine with the new Google V8 JavaScript Engine, the Skia vector graphics engine, and Google Gears.

The WebKit browser engine began its life as a fork of the KDE project's KHTML and KJS engines by Apple, becoming the basis of the Safari browser. WebKit was later re-adopted by KDE. Google already employs WebKit within their Android mobile phone platform, and it became the obvious solution for them. As the comic introduction to Chrome states:

It uses memory efficiently, was easily adapted to embedded devices, and it was easy for new browser developers to learn to make the code base work. Browsers are complex. One of the things done well with WebKit is that it's kept SIMPLE.

The version of WebKit used in the initial Windows beta seems to be WebKit 525.13, which is not the most recent version, and has some security vulnerabilities (see Security below). Some users have also noticed rendering differences from Safari's WebKit rendering to Chrome's, including antialiasing and shadows. This may be the result of the Skia graphics engine used under the hood.

Talking about the integration with WebKit, the Chromium FAQ says:

The Chromium source code includes a copy of the WebKit source. We frequently snapshot against the WebKit tip of tree or specific branches according to our release needs.

Our goal is to reduce the size and complexity of the differences between the copy we maintain in order to work more effectively as a participant in the WebKit community and also to make periodic updates occur more smoothly.

The V8 JavaScript Engine is open-source and hosted on Google Code, but was written for Chrome, rather than adopting an existing JavaScript engine. V8 is written in ~100,000 lines of C++ and can be run standalone or embedded in C++ applications.

The foremost reason for V8's creation seems to be performance. The V8 Design Documentation states, "V8 is ... designed for fast execution of large JavaScript applications." The Chromium Blog on V8 is entitled "The Need for Speed" and states:

Google Chrome features a new JavaScript engine, V8, that has been designed for performance from the ground up. In particular, we wanted to remove some common bottlenecks that limit the amount and complexity of JavaScript code that can be used in Web applications.

V8 claims a number of performance improvements and innovations, from fast property access using hidden classes, dynamic machine code generation and efficient garbage collection (stop-the-world, generational, accurate, compacting), small object hreaders, multi-threaded from the ground up. The team that created V8 was headed by Lars Bak, who, as Avi Bryant says, was "the technical lead for both Strongtalk and the HotSpot Java VM, and a huge contributor to the original Self VM" and has a number of VM-related patents to his name.

V8 is not a virtual machine in the classic sense as Matthieu Riou points out: there's no intermediate representation or byte-code. As a result, you cannot write your own language that compiles to "V8 byte code", although you can cross-compile to JavaScript. Despite this, Dave Griswold believes that V8 could serve as the engine for other dynamic languages:

I think these properties will rapidly make V8 the dominant VM for dynamic languages. It ought to make a great platform for Smalltalk.

Google Gears has also moved into the Chromimum Project, as pointed out in the FAQ:

With Gears as a plug-in to Chromium we're carrying two copies of sqlite and two copies of V8. That's silly. We're integrating the code so Gears can run great in Chromium. We plan to continue to build Gears for other browsers out of the same code base.

Although Google Chrome supports plugins for content handling like Flash and PDF, it does not currently support browser extensions, although that is planned.

Por mi parte, no reemplazaré (por ahora) a Firefox, porque aún Chrome es incompleto para algunos de los usos que hoy mantengo en Firefox, pero sus ventajas por ahora son innegables, y en primer lugar, en performance. En Septiembre, la lucha ha comenzado.

Plex Beta 6.1

En un mejor ciclo de desarrollo que en releases anteriores, la versión 6.1 de Plex está en Beta, por un mes más, aproximadamente. En estos días estoy ocupado probando. Para cualquier interesado ajeno a Plex, lo más interesante en el 6.1, es el desarrollo de aplicaciones para SOA. Del documento de sumario del release:

Model-Based Service Development
This feature strengthens CA Plex support for SOA development by providing model-based service development capabilities directly in the product. Services are represented as objects within the Plex model, using the component modeling approach already established for COM and EJB objects.
WCF service generation is supported with this release and a plug-in architecture enables developers to create their own service generators.
WCF Service Generation
Windows Communication Foundation (WCF) is a new communication
subsystem within the Microsoft .NET Framework that unifies several different communication technologies such as web services, .NET remoting, message queuing, and so on.
The WCF service generation in CA Plex r6.1 enables you to present business logic as services based on WCF. This can include business logic developed in the Plex model and logic from third-party applications.
Service Wrappers and Cross-Platform Interoperability
The new WCF service generation is designed to support the convenient wrappering of existing applications as services. This includes Java, i5/OS, and .NET programs. Generally, this means that the target of a FNC implemented by FNC triple can be a Java or RPG function. In the case of RPG, the target function can correspond to an i5/OS program developed outside CA Plex, such
as i5/OS programs or programs developed with CA 2E.

Hay otras mejoras, en Java, en Iseries, en el manejo del modelo. Pero esto es particularmente interesante.

UML/DSL por Johan Den Haan (a propósito de Steven Kelly)

Continuando la rueda de discusiones, Johan Den Haan se apoya en la nota que publicara hace pocos días Steven Kelly, a propósito de las afirmaciones originadas en Microsoft, revalorizando el lugar de UML, o reubicando a las herramientas DSL. Johan comparte en cierta medida las observaciones de Kelly, pero, como antes lo hiciera ya en otros artículos, da un paso más, proponiendo un modelo más amplio para solucionar el problema en discusión:

I definitely agree with Steven [...] that using UML and DSLs as presented by Cameron isn't a very good idea. I do however think, that the worlds of MDE (MDE is broader in scope than MDA, it adds multiple modeling dimensions and a software engineering process) and DSLs aren't opposites. I think that both DSLs and MDE are necessary assets for Model-Driven approaches. While multiple DSLs are needed to describe a software artifact (see for example the different architectural aspects of Service-Oriented Business Applications (SOBA) ), MDE is needed to provide a framework for connecting the different DSLs. An MDE methodology defines a framework of dimensions and their intersections, thereby defining the different models needed to describe a certain software application. This information also gives us the opportunity to discuss the needed DSL's in a (more or less) formal way. Last but not least, an MDE methodology also describes a software engineering process and a maintenance process, thereby defining the order in which models should be produced, how they are transformed into each other (if applicable) and how to change an existing software system using models.

Es recomendable, saludable, recorrer todo el material de Johan.
Más adelante, otros enfoques...

Steven Kelly sobre Microsoft, UML, DSL

Sin mucho tiempo en vacaciones + Beta Test de Plex 6.1, veo una contestación de Steven Kelly al giro de Microsoft hacia UML + DSL. Steven no comparte el cambio, pero creo que explica bien su naturaleza:

Now things start to become a little clearer! The UML models are being used like MDA's PIMs, and the DSL models are the PSMs. The DSLs are thus not specific to the problem domain, as they should be, but to the solution domain: they have the implementation concepts of a particular Microsoft framework or library. (I've blogged earlier about the problems of such framework-based DSLs.) Putting UML before DSLs in this way isn't just putting the cart before the horse: it's putting the horse firmly into the cart -- and pulling it yourself.

What makes this all the more ironic is how eager Microsoft were to put the boot into UML and MDA back at the start of the DSL Tools project.

Lo de "explicar bien su naturaleza" no incluye su imágen de "poner el caballo adentro del carro"...
Steven retrotrae el debate a sus orígenes:

If you want to look back at calm, polite, reasoned discussions, try Microsoft's Alan Cameron Wills' and IBM's Simon Johnston's blog posts. If you want to see the big guns fighting it out with good old FUD-slinging, try Steve Cook vs. Grady Booch (Dec 3, 2004).

Volveremos sobre esto (vacaciones mediante)...

Banda Ancha en Latinoamérica

Un informe de Cisco para América Latina destaca el potencial de crecimiento de la banda ancha en Latinoamérica, pero su bajo desarrollo actual. Comentado en La Nación por Ricardo Quesada, el informe muesta una penetración baja, comparada a la europea (sin hablar de los países más destacados en Asia). El informe es un papel orientado a mejorar los negocios de Cisco en el continente, pero las cifras son considerables:

"América latina tiene una oportunidad enorme. El alto valor de las commodities hace que haya mucha plata en los países de la región. Si se reinvierte en infraestructura y en tecnología de la comunicación, es posible que esta bonanza se convierta en crecimiento duradero", afirmó Jaime Valles, responsable para América latina de Cisco Systems.

Según Valles, la región está frente al crucial desafío de mejorar las condiciones de conectividad y el acceso de la población a la banda ancha, que hoy, en promedio, llega al 3,5%. El país con mayor porcentaje de conexiones es Chile, con un 8,8%, y la Argentina está segundo, con 6,6%, lo que representa más de 2,5 millones de accesos. "Los países más desarrollados tienen cerca de un 20% de penetración de banda ancha. Cisco tiene el reto de mejorar estos números", expresó el ejecutivo.

Más allá de los objetivos de mejora, esa cifra no es buena. Es de destacar también que Brasil continúa por debajo de Chile y Argentina. Las cifras mejoran bastante respecto a informes anteriores (1 y 2), pero en cifras absolutas siguen siendo bajas. Entre otras cosas, ¿cuánto se pierde de interconexión internacional? Cada vez más, cualquier sitio da por supuesto que los usuarios que se acercan a una página, lo hacen a velocidades de banda ancha mínima al menos, lo que permite elaborar contenidos complejos. Si en América Latina el 91,2 % o más de la población no tiene acceso a conexiones rápidas ¿qué alcance existe?

Code Generation 2008 finalizada

A finales de junio se efectuaron las sesiones de Code Generation 2008, anunciada aquí dos o tres veces. Centrada en las distintas variantes de desarrollo basado en modelos, ha continuado progresando en extender su uso, y en debatir el peso y alcance de las distintas vías de construcción de software. Las sesiones predominantemente ocuparon las dos tendencias corrientes en modelado: las distintas variantes del estándar de OMG, Model Driven Architecture, y las distintas ofertas de Domain Specific Languages; dos temas relacionados de particular interés, también tratados, son las relaciones con Lineas de Producto Software, y la aplicación a arquitecturas orientadas a servicios (SOA). Comentarios de algunos de sus participantes, en los blogs de Mark Dalgarno y Pedro Molina. Las presentaciones están disponibles en el sitio de la conferencia. El programa, mencionado en alguna nota anterior, da una idea del alcance de la conferencia.
Steve Cook y Bran Selic estuvieron a cargo de las keynotes. Y un excelente grupo de investigadores tomó a su cargo cada tema.

UML, DSL, y Microsoft, parte 2

En refuerzo de lo dicho antes, encuentro a Tad Anderson, escribiendo en .NET Developer´s Journal, que en septiembre de 2007 habla de las decisiones de Microsoft sobre UML, y su respaldo a DSL, afirmando que en dos años, no tuvo oportunidad ni medios de usar el set incluído en VSTS:
Over the past 2 years I have had the VSTS Architecture version installed and I have not used the DSL tools once on a project
Las razones muestran un camino que hoy parece estar remontándose:

A few years ago Microsoft decided to cut off its nose to spite its face.The war on UML started with the DSL movement.Although Microsoft still claimed to see UML as an essential tool, they stopped trying to compete with the rest of the market and tried to lead us down a new path that did not include UML.
With Rosario around the corner (a very big corner) the emphases is on Application Life-cycle Management (ALM).I think that is great. But the claim that their DSL tools will support the essential design documents is once again WRONG!!!! The DSL tools currently supported are the ones they are going to depend on again in the future.
Over the past 2 years I have had the VSTS Architecture version installed and I have not used the DSL tools once on a project. I have looked at them several times, but I always found SPARX Enterprise Architect (EA) easier to use to make meaningful artifacts. Microsoft did try to save a little face by saying they do support and suggest UML for domain modeling.
But there suggestion was to model in Visio (UML 1.2 or 1.4??), forward engineer the model to code and then open it up in their DSL class modeler. That is just plain dumb when tools like Enterprise Architect exist. Yes, Microsoft is partnering with SPARX now, but the ALM movement just confuses things because it introduces tools that step all over SPARX EA tools that support ALM, except for UML. Go figure.?.?.

Y concluye, tras relacionar el modelado con el marco en que lo usaría:

Microsoft’s ALM push will probably be good for project managers, but Microsoft still does not get that they are continuing to ignore the architect.

No está de más leer su nota completa. Es más contundente que lo que aquí extracto.

UML, DSL, y Microsoft

En junio ya hemos conversado sobre el repentino interés de Microsoft en UML. Anticipado por el propio Bill Gates en su keynote de Microsoft Tech-Ed 2008, la noticia ha hechado a rodar con amplitud, y hará más camino seguramente. Es interesante el párrafo que Gates le dedica al tema:

[Respondiendo a una pregunta sobre UML] we'll have additional support for UML in Visual Studio 10 for the specific modeling tools that are there. Then as we move forward and take the modeling platform to the next layer, we'll get even more ability for you to create your own models.

So, you're absolutely right that the modeling world is fairly disparate today. Even at Microsoft our people who do our business applications have some of their modeling environment. Excel in a sense is a pretty limited modeling type environment.

The thing that we've recognized is that by bringing those things together we can actually enable new things like what you do across the lifetime of an application. And underneath these models we actually use UML.

We think it's very rare -- a very rare person would actually want to look directly at the UML because it's so kind of abstract, but underneath, both in terms of exchange with other people's products and some of the exchange we're doing between our own products, we do have UML based subscriptions of these models.

Jack Vaughan y Michael Meehan han dado su opinión sobre este interés, y algo de sus dichos creo que da en el clavo: luego de alentar DSL versus UML, realmente una herramienta que articule la totalidad de un modelo es necesaria (And underneath these models we actually use UML...). DSL es un concepto positivo y conveniente, pero hacer pasar todo por lenguajes específicos de dominio es inapropiado, probablemente difundido más como una operación comercial que como una realidad. Primero, no todo dominio será expresado en un DSL, y segundo, sigue quedando en pie cuál será el pegamento que englobe conceptualmente el conjunto como un sistema; ¿la factoría de software?, o dicho de otra forma, ¿el Visual Studio Team System?.
Parafraseando a Jacobson, Vaughan dice:

Noted software technologist Ivar Jacobson, one of the original "Three Amigos" responsible for UML, said the problem of transforming representation between specific domains is not trivial.

"With DSLs, the problem is you need to have underlying semantics in common. You have a serious transformation problem across domains," said Jacobson, head of Ivar Jacobson International. "UML has a profile that allows you to have specific language constructs, but it has the same underlying model."

With DSLs, common semantics are very difficult to achieve.

Meehan va en la misma dirección a propósito de SOA; su punto de vista es que no es casual que al intentar poner un pie en SOA, sea necesario un medio de expresar lo que haya en común:

Yet Oslo is Microsoft’s Hail Mary pass over the rest of the SOA market and apparently the company has decided to end its religious differences with UML for the sake of giving Oslo mass appeal. Previously Microsoft had been pushing domain specific languages (DSLs) as an alternative to the general purpose format of UML. Unfortunately for the folks in Redmond, DSLs have failed to gain much traction. Part of the problem is getting the people who form a domain to agree upon a standard syntax. Another part is having that DSL interact with anything outside of its domain. Those things surely will come with the march of time, but the uptake has been painfully slow.

SOA demands some commonality, that everyone stop trying to be so special and idiosyncratic. Microsoft has always understood that on some levels, but it’s got skin in the proprietary software business (actually it’s got skin, blood, muscle, bone, you name it). Its maverick tendencies have often led to it offering users products that do SOA the Microsoft way. That is in stark contrasts to the company’s Web services tooling, which has for the most part embraced open standards and heterogeneous systems (most notably Windows Communication Foundation). This is where I remind some readers out there that, yes, there truly is a difference between SOA and Web services.

In fact, one way to look at Oslo, which supposedly will offer a Community Technical Preview in September, is that this is Microsoft’s flag in the ground for SOA. It emphasizes the importance of modeling, attempting to bring the technology as close as possible to the business. As such, UML represents an excellent choice. It should create interoperability between Oslo projects and those built with rival modeling tools (e.g. IBM Rational). And Eclipse’s Modeling Development Tools Project will have a UML2 component ready by the end of the month.

UML gives Oslo a reach it never would have had if it were based on a proprietary modeling language. The UML foundation means Oslo stands a chance of being truly universal, which is as SOA a concept as you can get.

Así, comenzamos a dejar de ver al UML y su significado básico como bosquejos escritos en servilletas a la hora de conversar...

De pronto, UML, II

El 8 de junio, Dr Dobbs Code Talk publicó una entrada de Christopher Diggins, que reconoce tres elementos que en el último tiempo han sido oscurecidos o cuestionados: que en programación hacen falta modelos, que UML tiene un papel que cumplir, y que existe un intento de crear un modelado que se convierta intrínsicamente en código, basado en UML (xUML, UML ejecutable). Diggins propone una sintaxis para no diagramar, sino escribir los modelos, que luego se ejecutarán (Heron).
Más allá del futuro de su iniciativa, lo motivan algunas objeciones comunmente formuladas a estándar:

Modeling is frequently used in certain software development domains to help verify the design of software, both formally and informally, before implementation starts.

One of the reasons that this approach hasn't caught on in the programming community at large is that it slows down development and increases the overall cost significantly. You have to maintain separate artifacts that contain largely the same information: the source code and the model. Finally models are often ignored after implementation starts.

Diggins reconoce que esta objeción no vale para el "UML ejecutable", que genera código a partir del modelo:

There is however a better solution that already exists: make the code and models synonymous with each other. In other words: make the model the code. This approach is the holy grail of the model-driven architecture (MDA) movement, and only one technology actually offers it today: executable UML (xUML).

Una objeción es acerca del carácter gráfico del modelo:

The problem with xUML is that it is primarily a diagram based formalism (with some unspecfied syntax thrown in). Most of us programmers hate diagrams. They are slow and cumbersome to develop and manipulate. My view, which I am sure is shared by many of you out there, is this: I wish everyone else in the world could supply me with up to date UML models with their source code, but I don't want to be obliged to do so myself.

Otra importante es acerca de la real posibilidad de traducir todos los diagramas a código. O mejor al revés: que todo el código requerido sea manejable con diagramas:

So a question one might ask is: why can't we simply generate models from code? Well the problem is that code is too low-level. Just like you can't generate pretty and elegant source code with meaningful symbol information from assembly code, the same is true of models.

En fin, estas objeciones serían objetables...En OMG existen estándares para manejar información de los modelos por medio de directivas que completen los diagramas. Tampoco es mi experiencia: el modelador que uso (Plex/no UML/si MDD) también es capaz de completar la información con un metalenguaje capaz de expresar lo que haga falta, y lo suficientemente abstracto como para que pueda generar código para distintas plataformas y arquitecturas, basadas en las mismas directivas, configuradas para distintos contextos.
La iniciativa de Diggins va en esa dirección. Nótese que Diggins, ante los puntos no satisfactorios de UML, va por más, no hacia atrás.

De pronto, UML

Desde hace poco, diversos teóricos y técnicos próximos a Microsoft, han vuelto a hablar de UML y modelado. Como anticipa Stuart Kent, parecería que se ha pasado (de una visión negativa e irónica de UML), a otra que pretende integrar DSL y UML. Probablemente, como lo declara Kent, se trata más bien de allanar el camino a una mayor utilización de DSLs, pero al menos, ahora UML tiene existencia y algún valor...
Dice Stuart Kent:

We've found that DSL Tools is very appealing to customers who've already bought into modeling. It allows them to create their own customized model driven solutions fairly quickly. However, for those not already into modeling it's a harder sell (although, we have had customers who have seen what others have produced and decide to build something similar which focuses on their domain). To really get modeling out to a broader audience it's necessary to have tools that people can use straight out of the box. I'm still convinced that if you want to dramatically increase productivity then you should be using DSLs driving code generators, or further model transformations, or visualizing abstractions discovered from existing artifacts, or some combination of all three. On the other hand, whatever your views are about the effectiveness or not of UML, it has significantly raised the awareness of modeling with a broad audience and it is something that many people are familiar with. So I'm really pleased that Team Architect has now stepped up to drive a strategy that delivers on both sides of the modeling coin, and connects them up.

El cambio es expresado más claramente por Cameron Skinner, referido por Kent:

There has been some speculation in the press recently around Microsoft's commitment to DSLs now that we are planning on supporting five UML 2.1 diagrams in the Rosario release ( Class, Use Case, Component, Sequence, and Activity diagrams ). Specifically, some articles have been written in a way to lead the reader towards a perception that Microsoft is moving away from DSLs and towards UML. Not at all correct! I wanted to take a moment and set the record straight on this, and start a broader conversation.

Let me first start by making one thing very clear: Microsoft is very committed to our DSL strategy, and in particular to the DSL toolkit that ships as part of the VS SDK. In fact, our UML designers are built on top of that toolkit.

I believe that supporting both approaches to modeling gives developers and Architects alike the "right tool for the right job". For those folks who want to analyze and design their architecture using a standard notation that does not imply an implementation decision, use some UML diagrams. UML is great for describing higher level concepts and for defining the initial glossary that can be used to describe the concepts necessary to facilitate broader communication. For those folks who have decided on an implementation strategy, and do not want to be encumbered by the more general nature of the UML to describe that implementation choice, use DSLs.

In the coming months, you will very likely hear me or others on the team talk about using UML at the "logical" layer and DSLs at the "physical" layer. We are really trying to promote a clean separation between the two approaches, while at the same time, attempt to maintain an understanding of how one can inform the other, and vice versa. In this way, we are hoping to more cleanly support the understanding and intent behind the models at each layer.

So this is not a "DSL vs. UML" conversation. This is a "DSL + UML" conversation. And more importantly, this is about meeting our customers where they are and giving them tools that allow them to get to where they need to be.

The true innovation in this space is going to be how we can seamlessly connect the two approaches, and how we can make modeling more central to a broader range of people.

Volveremos sobre esto.

Facebook o LinkedIn?

Hace alrededor de tres semanas, mis ex-colegas de Chile me invitaron a abrir una cuenta en Facebook: primero uno, luego dos más. Finalmente, aunque me resistía a dedicar tiempo a este tipo de redes, acepté, para mantener contacto con ellos, y recordar lo que ya es irrepetible (Pero este es otro asunto). Luego, otro más me invitó a MySpace, y acepté porque es un colega que lo merece; y finalmente ayer, recibí dos invitaciones de Argentina y Honduras de colegas y amigos con los que no quiero perder contacto para otra red, Tagged, a la que ya había rechazado varias veces (y que continuaré haciendo). El futuro me presenta una tarea: convencer a todos los colegas y amigos a que converjamos en una sola red. No pensaba dedicar tiempo a ninguna; de hecho estaba rechazando invitaciones, y explicando por qué lo hacía. Sin embargo, tengo que reconocer que Facebook tiene aspectos de interés: es un sitio informal para conversar con quienes están lejos, como en general es mi caso, y la oferta de aplicaciones disponibles es más que variada; así como es posible dedicarse a (cientos) de juegos, y estar a un nivel de proximidad adolescente, así también es posible encontrar comunidades de gran interés, expresadas a través de actividades de grupos de afinidad o del uso de aplicaciones. Luego de hacer una revisión de semanas, mi adhesión a grupos dedicados a lenguajes de programación , herramientas y actividades en la Web, trabajo y emprendedores se ha vuelto descontrolada. Sé por experiencia que, andando el tiempo, esas pequeñas comunidades desarrollan intereses comunes sólidos. ¿Cuánto tiempo se le puede dedicar?. Poco; terminaré creando un sistema de alertas, y consolidando las relaciones con una pequeña porción de ese universo.
Un fenómeno curioso, que creo que va camino de la simplificación, es el predominio de la adhesión por naciones: Según comentan, y pude comprobar, Orkut es un excelente sitio para estar en contacto con personas de Brasil, y parecería que también de India. Es abrumadora la cantidad de personas de Chile participando en Facebook.
Pero yendo al asunto inicial, Facebook o LinkedIn?
Tengo la impresión de que las redes del estilo de Facebook son la continuidad con mayor alcance e interactividad, de lo que Messenger o los fotologs representaron: un sitio para conectarse informalmente, mayoritariamente para jóvenes, y para el ocio. Messenger creció por su decidida apuesta a capturar el mercado de los jóvenes; muchas de estas redes no despegan de ese modelo. Y esta es la razón por la que visito Messenger sólo una vez cada tanto, si acaso un amigo o familiar lo usa y tenemos que conversar. De lo contrario, de manera más espartana, se puede conversar con Google Talk. Lo mismo vale para las redes sociales. Estimo que este modelo es su límite. Y LinkedIn (o Xing) representan la reacción a él. Estas redes son, contrariamente, económicas en su presentación, con nula oferta de ocio o expansión informal (ni albumes de fotografía, ni videos, ni expresiones de deseos o fanatismos, ni citas amorosas). Sólo el desarrollo de herramientas de presentación profesional o académica, y de colaboración, con reglas rigurosas de protección de información. No se fomenta el trato indiscriminado, estableciendo un esquema conservador de presentación. Pero el resultado es muy valioso; en mi caso, me ha permitido estar en contacto con colegas que de otra manera difícilmente hallaría. Y las herramientas disponibles me estan ayudando a planificar actividades que de otra manera resultarían complicadas. En el terreno de facilidades para las actividades laborales, profesionales o académicas, comienzan a ofrecer poderosos medios de trabajo.
¿Qué le espera a las redes sociales? Creo que la diversidad que hay ahora se simplificará pronto, y que muchas de ellas están en una carrera para ver quién las compra, y a cuánto. Esto también vale para las profesionales, pero por su propio carácter, creo que un margen de competencia quedará. Sea como sea, en un futuro próximo, creo que me ahorrarán el dilema de qué hacer con tantas invitaciones, porque todo el agua irá al mar.
Finalmente, quiero destacar algunos aspectos señalados por Brad Stone, de New York Times, sobre LinkedIn:

The average age of a LinkedIn user is 41, the point in life where people are less likely to build their digital identities around dates, parties and photos of revelry.
LinkedIn gives professionals, even the most hopeless wallflower, a painless way to follow the advice of every career counselor: build a network. Users maintain online résumés, establish links with colleagues and business acquaintances and then expand their networks to the contacts of their contacts. The service also helps them search for experts who can help them solve daily business problems.
The four-year-old site is decidedly antisocial: only last fall, after what executives describe as a year of intense debate, did the company ask members to add photos to their profiles.

Sobre las bases del negocio de LinkedIn:

That business-only-please strategy appears to be paying off. The number of people using LinkedIn, based in Mountain View, Calif., tripled in May over the previous year, according to Nielsen Online. At 23 million members, LinkedIn remains far smaller than Facebook and MySpace, each with 115 million members, but it is growing considerably faster.

LinkedIn also has a more diversified approach to making money than its entertainment-oriented rivals, which are struggling to bring in ad dollars and keep up with inflated expectations for increased revenue.

LinkedIn will get only a quarter of its projected $100 million in revenue this year from ads. (It places ads from companies like Microsoft and Southwest Airlines on profile pages.) Other moneymakers include premium subscriptions, which let users directly contact any user on the site instead of requiring an introduction from another member.

A third source of revenue is recruitment tools that companies can use to find people who may not even be actively looking for new jobs. Companies pay to search for candidates with specific skills, and each day, they get new prospects as people who fit their criteria join LinkedIn.

Un aspecto que se incrementará, pero que ya está presente, es el lugar que las empresas tendrían:

LinkedIn is set to undergo a radical shift in strategy to find other sources of revenue. Instead of catering primarily to individual white-collar workers, the site will soon introduce new services aimed at companies. It is a risky move that could alienate members who prefer to use the networking site to network — without their bosses peering over their shoulders.

One new product, Company Groups, automatically gathers all the employees from a company who use LinkedIn into a single, private Web forum. Employees can pose questions to each other, and share and discuss news articles about their industry.

Soon, LinkedIn plans to add additional features, like a group calendar, and let independent developers contribute their own programs that will allow employees to collaborate on projects.

The idea is to let firms exploit their employees’ social connections, institutional memories and special skills — knowledge that large, geographically dispersed companies often have a difficult time obtaining.

(...) “It will be extraordinarily challenging to simultaneously serve as a corporate tool and yet promote the ‘brand of me’ in an emerging free-agent nation,” said Keith Rabois, a former LinkedIn executive who is now vice president at Slide, a maker of applications for social networks.

Jeffrey Glass, a partner at Bain Capital, says his firm invested in LinkedIn primarily because it is now becoming popular enough to introduce these kinds of products to companies and other organizations, like universities.

“This is a powerful tool because inside the corporation, there are massive bodies of knowledge and relationships between individuals that the corporation has been unable to take advantage of until now,” he said.

Reid Hoffman, de la dirección de LinkedIn, y anterior inversor en Facebook, compara ambos:

(...) he said that most members of Facebook who are older than 30 use it for entertainment, like playing Scrabulous, a version of Scrabble — not for doing their jobs.

“Scrabulous is not work, and it does not enable you to be an effective professional,” he said.

Firefox 3.0: record de descargas

Firefox 3.0 se acerca a los nueve millones de descargas, con casi un cuarto de las descargas en Estados Unidos...Veremos cómo termina el día inicial (ver en su sitio)

Google/Yahoo/Microsoft ¿Un solo ganador?

Varios sucesos de los últimos días en las negociaciones entre Yahoo y Microsoft, y el seguimiento cercano de Google, quizá impliquen un cambio futuro de tendencias. Por lo menos, probablemente representan una ventaja de negocios para uno de los participantes, Google. Las negociaciones han puesto a Yahoo en una situación débil, con un frente interno dividido, que le ha acarreado una gran pérdida de valor de bolsa. Su acuerdo con Google, si bien le asegura un ingreso de ganancias, lo convierte en un asociado dependiente de su competidor. Para Microsoft, la puja por su competidor ha significado reconocer en qué áreas no ha conquistado posiciones, hasta el punto de su retiro del mercado de avisos.
Sin duda, Microsoft seguirá siendo robusta, aunque un poco menos, Google más próximo, y Yahoo será una incógnita, dividida entre una dirección que no parece saber conducir la empresa, y un grupo importante de accionistas interesados en cambiar un proyecto por dinero contante y sonante.
Quizá lo más notable sea lo que varios analistas han expresado en estos días: Microsoft parece no adaptarse a las nuevas características del mercado. Juan Freire lo ha descripto bien hace pocos días:

Microsoft no deja indiferente a casi nadie, ni como empresa ni por sus productos y su defensa de los estándares propietarios. La corta pero intensa historia de la era digital nos explica que la irrupción de Internet significó un drama para los responsables de Windows. Su error de cálculo los colocó en desventaja en la carrera por ofrecer productos y servicios en la web, a pesar de su posición inicial provilegiada. Pero quizás lo más importante no sea este retraso en la llegada al mercado, algo que con su tamaño y capacidad podría acabar por resolver. Puede que sea más crítico para el futuro de Microsoft su incapacidad para generarar en su organización el cambio cultural que significa la transformación desde la era industrial, donde nació y se desarrolló, a la digital. En realidad Microsoft sigue siendo una empresa analógica y sigue actuando como tal en mercados que, para su desgracia, hace tiempo que ya se han digitalizado.

Algunos incidentes recientes que pesarán en su futuro próximo:
Finalmente, parece que XP será historia, dejando su lugar a un continuador muy controvertido.
OOXML sigue generando consecuencias desagradables, con final incierto (1,2,3, entre muchos otros).
La Comisión Europea, y otros organismos regionales, continúan cuestionando su carácter de proveedor.

Programadores en España

Juan Palacio apunta una reflexión sobre los programadores en la empresa española, que creo que es particularmente asociable a nuestros entornos (Iberoamérica), en general bastante lejanos del concepto de Toyota del "Respeto por la gente". Una vez más, algunos de los comentarios abren una línea de discusión que amplía la nota original.