miércoles, abril 29, 2009
martes, abril 21, 2009
Most consumers do not want to get a PC by purchasing microprocessors, hard drives and operating system software from different suppliers and assembling them all into a working computer. They prefer to buy a complete, customized machine from one supplier.Vance no piensa en lo que le pase a MySql, ni el cambio de manos de Java, sino en la consolidación de agentes con control completo del negocio. Quizá sea su punto de vista el más acertado en todo lo que comienza a debatirse tras la compra. ¿Habrá cometido IBM un error histórico?
Corporate customers increasingly want the same thing: a one-stop shop for hardware, software and services. And the largest technology companies are deploying their huge cash hoards to make acquisitions to bolster their ability to be that single provider.
That trend drove Oracle, a leader in business software, to announce Monday that it was spending $7.4 billion to buy an ailing Sun Microsystems and get into the computer hardware business. Oracle beat out rival I.B.M., which considered buying Sun to enhance its own software offerings but ended serious acquisition talks about two weeks ago.“Oracle will be the only company that can engineer an integrated system — applications to disk — where all the pieces fit and work together so customers do not have to do it themselves,” Oracle’s chief executive, Lawrence J. Ellison, said Monday.
domingo, abril 19, 2009
The TIOBE Programming Community index gives an indication of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. The popular search engines Google, MSN, Yahoo!, and YouTube are used to calculate the ratings. Observe that the TIOBE index is not about the bestmost lines of code have been written. programming language or the language in whichThe index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system.
El ranking completo para los primeros veinte puestos:
|Delta in Position||Programming Language||Ratings|
El análisis completo se puede encontrar en la página de Tiobe. Se puede suscribir al informe mensual.
Otro aspecto de interés acerca del análisis es el análisis por categorías, con indicación de un 40% de persistencia de lenguajes procedurales:
|Category||Ratings April 2009||Delta April 2008|
El método de cálculo del índice es este.
TIOBE is specialized in assessing and tracking the quality of software. We measure the quality of a software system by applying widely accepted coding standards and quality metrics to it.
We provide quality systems that monitor your software real-time. Software managers and architects are offered a top down view, whereas engineers get a plug-in for their programming environment to measure the quality at file level.
martes, abril 14, 2009
I am personally a bit sick of that, it seems that Oslo is taking the same path as WCF/WF and it will take years to undo quick "pragmatic" decisions made in the early days of the project. Considering that WCF was announced in 2003, shipped 2007 and being rewritten (one more time...) in 2009 for a release in 2010-2011, it looks like we should expect Oslo to do anything useful in 2014-2015 timeframe. I wish a lot more people would have the luxury to work with these kinds of time frames.¿Será Oslo solo aplicable para la plataforma Windows? Tan pronto se desenvuelve cualquier discusión sobre el tema, éste se encauza por ese camino. En ese caso, el valor que se discute sobre la capa superior (meta-metamodelo) tendría escaso alcance.
Dubray puntualiza lo que Charles Young piensa al respecto. Todo lo dicho por Young es de mucho interés, pero particularmente sobre los objetivos de Oslo:
In this thought exercise, we are capturing models which are specific to a given technology. We need to be able to specify the metamodel very precisely in order to ensure that our models are valid and well-formed in respect to BizTalk Server. However, we will probably be less interested, in this scenario, in ensuring that our metamodels conform to some meta-metamodel. One reason for this is that we probably won’t have a compelling need to exchange BizTalk-specific metadata with other systems and applications. This could change over time, however. For example, as BizTalk Server evolves further, future versions may exhibit much closer integration with platform-level technologies such as WCF and WF, or standards such as BPEL4WS and BPMN. They may be more deeply integrated into platform-level host environments (this is already the case with regard to IIS-based ‘isolated’ hosts in BizTlk Server). In this case, the ability to exchange and transform metadata on the basis of some meta-metamodel could become an important consideration. Even here, though, we might wish to our meta-metamodelling to address a specific technology platform.Charles Young historia las relaciones entre Microsoft y la OMG (UML, metamodels, MOF and MDA), hasta desembocar en las Software Factories y Oslo. Pero eso podría verse por separado. Curiosamente, esta historia de interrelaciones es prácticamente inhallable hoy.
A major theme in Oslo is the reduction of the bar that ISVs and development teams face when seeking to support rich modelling approaches to software development and runtime configuration. Oslo is agnostic with regards to the number of metalayers that are required in any given scenario and makes no assumptions with regard to how platform/technology-specific or independent a particular model needs to be. It avoids forcing conformance to any abstract M3 specification and provides a general-purpose metamodelling language that minimises the learning curve for developers. To all this, Microsoft adds pre-defined mappings to T-SQL and is building additional tooling for generalised visualisation of models and parser generation tools for creating domain-specific modelling languages. They also provide many pre-defined models (e.g., for WF workflows) out of the box.
In our BizTalk Server example, the bar is now set very low. MSchema is a natural choice for defining model specifications whose conformance to the models in the BizTalk management database can be verified, but which can reduce the amount of detail to an appropriate level. The Oslo tooling can be used to create tables in the repository which correspond directly to the tables in the Management database. Access to models in the repository can be via any appropriate and familiar data access technology that can connect to SQL Server. There is no need for developers to engage in a steep learning curve in respect to meta-metamodelling, no need to conform to unfamiliar APIs and no need to inject an unnecessary level of platform independence in the way models are specified.
jueves, abril 09, 2009
En primer lugar, sus observaciones sobre Oslo:
What is clear is that now Oslo is only about "modeling", SOA and Composite Applications are simply areas where Oslo can be applied. That's a bit different from the original announcement on the project in the fall of 2007 and pieces like "Dublin" seem to have fallen off Oslo which is now only 3 elements: a metadata repository, quadrant and the M language.Dubray parte de una premisa con la cual juzga Oslo:Metamodel Oriented Programming (MOP):
MOP is an approach which seeks to create a programming model independent of architecture such that architects can architect and developers can build the solution in an architecture independent way. This is in line with projects like Microsoft Volta which talked about "Architecture Refactoring" concepts. Incidentally Volta has disappeared from the face of the earth, what a shame. MOP is not about creating a single programming model, but again, rather an approach to separate architecture(s) from programming model(s). I, of course, focus on SOA and Composite Apps, but as a good software engineer, I believe that anything I do is so general MOP can be applied to anything...Dubray, basado en las conjeturas que permite extraer la todavía difusa información sobre Oslo, sostiene que el proyecto no logra establecer una separación clara entre el nivel de abstracción de modelado y la programación:
If you build something like Oslo you start with a programming model like .Net RIA Services or anything you want that tries to do the same thing and then you build Oslo to make it easy(ier) to build something like .Net RIA Services. In case you have not noticed MOP has already happened, all the annotations in Java or C# is MOP layered on top of OO. But MOP layered on top of OO does not provide a clean separation between Architecture and Programming Models. This is the mission that Oslo should set itself up with. So starting with an "app" is, of course, a traditional Microsoft approach. But this is the wrong level. This is actually catastrophic to start at this level, it ensures they will never deliver something at the MOP level. What our industry needs today is not a better way to write code snippets or string templates, it needs a way to express business logic in a sustainable way, i.e. outside a given architecture.Sobre M:
"M lets developers build out domain-specific languages (DSLs) relatively easily" is no longer the problem, Microsoft has DSL tools for that, the question that the Oslo team should ask itself is does M stands for Model or Metamodel?Douglas Purdy, mencionado por Dubray, acaba de contestarle. En todo caso, postula M como una herramienta para trabajar a nivel de metamodelos y meta-metamodelos. Diferenciando M de las DSL tools de VS:
The current DSL tools (the DSL Toolkit) are for visual DSLs, not for textual DSLs. We want an architecture that supports both both textual and visual DSLs operating over the same model. Speaking of model, M is for model and metamodel and metametamodel. Since my Smalltalk days, I have grown tired of using the meta prefix, as it often confuses more than helps the conversation with developers.También en su contestación está implícito el rumbo zigzagueante de Oslo desde su inicio al contestar aceerca de la relación entre Oslo y FTA.
Está abierta una discusión...Más allá del punto de vista sobre Oslo, otras aristas del pensamiento de Dubray merecen ser seguidas. En otro momento.
miércoles, abril 01, 2009
Stephen Colebourne argues that there will be no Java 7 because of the ongoing disagreements between the Apache Software Foundation, Sun, and the JCP regarding Apache Harmony, the independent, open source, compatible Java SDK.
Stephen argues that Harmony's success motivated Sun to return to a proprietary Java development model and is blocking Harmony from getting the JDK compatibility kits it needs for validating that its Java implementation is up to snuff.[Según Stephen Colebourne] Apache's implementation of the Java SE 5 JSR specification is Apache Harmony. However, when Apache came to obtain the testing kit for the specification a whole political game started. Instead of Sun offering the testing kit as normal for each of the other 25 JSRs, they offered a testing kit where the results of the tested code would not be Open Source
Obviously, Apache couldn't accept this limitation, which is against the legal agreement signed between Sun and Apache. Apache complained 2 years ago, but has yet to receive an acceptable response. And no, there is no way a charity not-for-profit like Apache is going to sue a multi-national corporation - who do you think would get the better lawyers?
The key point is that Sun's tactics here were quite deliberate. They knew exactly what they were doing by offering a testing kit with a restrictive license. They wanted to ensure that Apache Harmony couldn't be certified as complete. Sun was going out of its way to ensure that there was no competition to its own JDK.
In the meantime, Sun played the OpenJDK card. It announced the release of the JDK under the GPL license [...] I think this shows a gross lack of perspective - the code may now be GPL open source, but the specification is now no longer open. Which is more important?
Thus, the next release will be JDK 7, not Java 7.
This means that there won't be an open Java 7 specification. This would mean that what makes it into Java is what Sun choses to release in OpenJDK, not what's agreed in the JSRs. This returns control of Java back to Sun and prevents its standardization.
Stephen made a second posting where he documents the ongoing discussions between the Apache Harmony and Sun regarding the Java 7 specifications, using the JCP Executive Committee meeting minutes to support his argument.
An interesting read, to say the least, and a potential threat to having an open Java specification.
¿Qué peso puede tener esta hipótesis? En este caso es simple: el tiempo le dará su lugar en pocos meses.