Unas recomendaciones generalizables

 Existe una verdad publicada, y existe una vida real. La verdad publicada está siempre en la cresta de la ola, convirtiendo en el non plus ultra a la última invención presentada. Y esto es especialmente, fundamentalemente válido en el universo de la tecnología. Se afirma que una tecnología determinada debe ser adoptada ya, porque tiene un efecto x, y soluciona un problema z "como nunca hasta ahora". Sucede como las invitaciones de todos los proveedores de servicio de Internet y telefonía: si le hiciéramos caso a todos, deberíamos reemplazar nuestro contrato de servicio una o dos veces por semana. Por eso aprecio las reflexiones de un veterano en el desarrollo de aplicaciones. A veces, el rey está desnudo.

Las recomendaciones de Beau Beauchamp se dirigen a quienes desarrollan en la categoría de Javascript, pero se pueden extender, cambiando algunos nombres, a otras categorías. 

En primer lugar, su presentación:

I’ve been a web application developer for over 20 years. I’ve seen all kinds of UI libraries come and I’ve seen them go. I’ve been in the industry long enough to know that just because a framework is new and cool and “OMG! Everyone cool is using it!”, doesn’t mean you should use it too.

Speaking from a purely enterprise perspective, which is probably the same perspective you should be looking at if you plan on building the next great SaaS app, you should be thinking long and hard about incorporating any kind of library or UI framework into your app.

Right now you’re small, nimble, you code things in record time and push to production with a minimal number of steps. You’re probably not writing tests, or very few, and all of your builds are done automagically locally.

But if you get successful, really successful, like with hundreds of developers working on your app kind of successful, all of that is going to change. You are going to become an enterprise; and in the enterprise, we do things very differently in the “real world” than you do in the “startup world”.

 Su lista de recomendaciones se hacen dialogando contra lo que se pudiera practicar en una pequeña "startup". Cambie el destinatario por otros. Hay muchos candidatos. 

La primera recomendación:

Cualquier cambio es costoso

Every step you add into the deployment process costs you time and money in ways you cannot see when you’re a small startup.

If you unwisely choose the technology stack for your app, especially the UI, it’s going to take a tremendous amount of resources to rip it out and update it

 Evite tecnologías de moda que se actualizan demasiado rapidamente, o que vienen y van

UI is notorious for flavor-of-the-day UI libraries and frameworks. Handlebars, React, Vue, AngularJS, Angular 2, 4, 5, 6, 7, and now fucking 8. All in the span of what—6 years? I’m sure there are bunch of others I’ve not even heard of yet.

“Angular is not a fad, Beau.” Sorry, it is. In the enterprise you cannot be changing out libraries and updating shit this fast. You won’t have the budget or the resources (“resources” is enterprise-speak for the people who will now hate you).

Each time some library or framework “updates” or changes versions, it costs you money.

Costo versus reales beneficios

Think about which UI framework you’re thinking of using in your project or next project. What is the framework really doing for you? Is it saving you time or just giving your application some cool “whiz-bang” features?

“It gives us model and DOM binding! A huge time saver.” Fine, you can do that with a jQuery plugin that you don’t have to compile. Next?

“It gives us an MVC on the front end with model-bound templates for a SPA (single-page application).” Fine, but this is not saving you time; in fact, it’s costing you more time in building pages, compiling, and SPA’s are terrible if you need real SEO and accurate analytics.

At the end of the day, by the time you are done installing all of the crap that you need to actually run the super-really-cool fad-tech UI framework, it’s not easier at all, and all you have done is saddled your enterprise team with hours and hours of frustrating local setup and configuration and IDE integration. It’s nonsense.

Yea, we do it; but it’s NOT easier. I’ve seen enterprise devs saddled with setting up the new wiz-bang technology spend literally weeks working out the bugs in their development environments because someone decided to install a new “framework”.

And at the end of the day, the UI framework, much more of a pain in the ass, much more difficult to debug, than it was helpful in achieving a good clean easy-to-mange front-end.

Diga no a compiladores de UI. Mantengo este punto porque está en su lista, y tiene importancia en este caso. Aquí, la generalización está en qué línea de desarrollo recomienda: 

I once interviewed with a really big video game company. You know what their development policy was changing to? Plain ECMA (JavaScript) and CSS. No compilers. No CoffeeScript. No TypeScript. They even ripped out jQuery. I was impressed.

Now why were they doing this? Because they needed to save time and money. Over the years developers had come into their teams, added in all kinds of wiz-bang fad tech into their UI, and then left. Now their teams were saddled with all of the UI garbage that was costing the company millions in developer hours each time Angular or whatever SPA library had an update or an upgrade. We’re talking about touching literally millions of lines of code and tens of thousands of files across the enterprise.

I totally understand why they junked all of it. Now, I personally wouldn’t junk jQuery or Bootstrap, but those don’t need to be compiled to run; and jQuery isn’t updating every 5-minutes either. You can usually update without causing huge regressions, if any at all.

 

A la conclusión de Beau podríamos agregarle otros causantes...

The reason these fad-tech UI libraries even exist is because of bored engineers working at big tech, like Google, Facebook, Twitter, etc. But at the end of the day nothing works better and is easier to debug and maintain than just pain JS and native CSS.

Nuevas capacidades del System i (AKA AS400)

Se llame System i, AS400, o cualquier otro nombre intermedio, el i no es un equipo estancado, sino todo lo contrario: robusto como siempre, y evolucionado al paso de las tecnologías. Como un breve recordatorio, Alex Woodie, en The Four Hundered, enumera las nuevas características sumadas entre 2014 y 2015:

1. Native Flash Storage

IBM added support for native flash storage in the latest round of technology refreshes, which were IBM i 7.1 TR 10 and i 7.2 TR 2. This enables native use of solid state drives (SSDs) based on flash technology.

Prior to this, getting flash storage running on an IBM i-based Power Systems server was accomplished by way of the Virtual I/O Server (VIOS). Not all IBM i shops are thrilled with VIOS, which is an AIX program and can muddy the troubleshooting of performance issues. Thanks to VIOS and the overall adoption of virtualization in the IT world, there are rumblings from the natives that we've gotten too far away from the data.

But thanks to native support for flash, IBM i shops can now benefit from the ridiculous performance boost that NAND technology can deliver, especially for busy IBM i applications that are I/O bound with traditional DASD. And it can do so without going down the VIOS/AIX rabbit hole, which still looks intimidating to smaller shops.

2. Row and Column Access Control

This security feature was added with the release of IBM i 7.2 in 2014 to prevent unauthorized users from accessing huge swaths of data. As IBM's DB2 for i guru Mike Cain explains, RCAC was added at the request of IBM i customers to protect sensitive data.

"Prior to RCAC, the security scheme was provided through the object-based security measure," Cain says in this video on the RCAC Redbook landing page. "This really means that someone. . . could get access to all of the rows or records, or they would have no access to the row or file."

Since there was no prior way for DB2 for i to subset the record access--absent defining it at the application level, which leaves the data vulnerable still to ODBC/JDBC--IBM built it, and that's RCAC. "DB2 for RCAC provides a new and robust solution that allows for the governance and control of data through all interfaces, whether those interfaces are SQL or whether they're native record-level access," Cain says.

Simply put: If you need to dole out data based on a user's specific role and don't want to completely rebuild your database schema to prevent snooping, then you need RCAC, which means you need IBM i 7.2.

3. JSON

IBM added a technology preview for JavaScript Object Notation (JSON) in IBM i 7.2 TR2 and IBM i 7.1 TR10, which shipped in the spring.

JSON is a lightweight, human-readable data format that's become the default way that Web applications store and share data. Compared to XML--which 10 years ago paved the way toward self-definable data--JSON is both easier for programmers to use and faster to load.

Considering the rising adoption of JavaScript frameworks like Dojo, Ext JS, and jQuery among IBM i developers for front-end Web development, it was a natural for IBM i to add support for JSON in the database. (While JavaScript doesn't require JSON, there are advantages to using them in combination.)

The JSON Store Technology Preview that IBM shipped with the latest TRs allow JSON documents to be stored and retrieved using DB2 for i database tables. For a good primer on the three ways developers can utilize JSON, check out this recent developerWorks article.

4. Node.js

IBM unveiled support for last October with IBM i 7.1 TR9 and IBM i 7.2 TR1.

You're probably aware of how JavaScript can accelerate development of Web clients. The frameworks mentioned above bring a host of out-of-the-box UI widgets that developers can easily drop into their development environment. What Node.js does is extend that ease-of-use to the server. Node.js (or simply "Node" to those in the know) is an open-source runtime environment for server-side applications written in JavaScript. The framework has been widely adopted because it takes much of the complexity out of building and running scalable, data-intensive Web applications.

The addition of Node.js is a good example of IBM reacting to changing trends in application development (the addition of support for Ruby is another example). To learn more about Node.js, check out Aaron Bartell's LinkedIn story about his first experience with the framework.

5. REST Web Services

IBM's support for Representational State Transfer (REST) Web services, which IBM shipped in December with the group PTFs for IBM i 7.1 TR9 and IBM i 7.2 TR1, can be grouped into the same vein as JSON and Node.js: Keeping the platform relevant to a new class of developers and a new programing style.

If JSON has become the defacto data integration standard on the Web (largely replacing XML), then REST has become the defacto program integration standard for Web-based applications--largely replacing the XML-based service oriented application protocol (SOAP) that came before it.

If you want to connect your IBM i app so it can talk to hosted cloud service, such as Salesforce or Netsuite, you're going to be doing it via REST. IBM i developers who want to keep their apps current would do well to adopt REST, not only to partake of the rich ecosystem of REST-enabled services that are already out there, but to contribute back to it too.

Como se ha dicho otras veces, el problema no es el 400, sino la apertura de ideas de quienes toman decisiones sobre su uso. Usado como servidor, suele quedar atado al criterio más bien conservador en el manejo de la lógica de negocios escrita en los servidores.

Efectividad en aplicaciones móviles

Releyendo los 12 tips para crear un sitio móvil amigable (12 Tips for Creating a Mobile-Friendly Website) recomendados por Jennifer Lonoff Schiff en CIO...
Algunos de los tips son previsibles y conocidos, alguno difícilmente realizable (Don't go overboard with Java[...script?];  "consider replacing bulky JavaScript libraries like jQuery Mobile with standalone JavaScript"). Pero en conjunto, no deja de ser una buena guía.
Detrás de la simplicidad y síntesis requerida por una aplicación móvil hay un monto de trabajo y conceptualización superior al usual "en otras eras" del desarrollo de aplicaciones, particularmente basados en dos características especialmente dadas en ellas: la vida de una aplicación puede ser considerablemente corta, y debe prevenirse su visualización sobre un número alto de clientes, formados por dos dimensiones concurrentes de actores: sistemas operativos diversos, y visualizadores (browsers) diversos. Y las diferentes versiones de sistema operativo y visualizadores...Sólo puede salvarse de esta matriz de conformidad una empresa que desarrolle aplicaciones para su propio uso...y fuerce el uso de un producto y una versión.
¿Es posible encarar una serie de proyectos móviles sin contar con un marco de recursos que simplifique el trabajo de desarrollo?
Pero un marco tal, en muchos puntos entrará en conflicto con este tipo de recomendaciones, fundamentalmente aquellas que hacen a la construcción en sí misma. En mi caso, trabajando con plantillas de Webclient, existe una oportunidad de refactorización, en la propia capa intermedia. Webclient recurre a Dojo (aplicaciones web) o Sencha (aplicaciones móviles). Si bien técnicamente podría recurrir a javascript personalizado, mucho más económico y adaptado a la recomendación ("Avoid excessive JavaScript in your mobile websites where possible, because it runs differently across different browsers and devices," says Hume. "Even different models of the same phone can often behave quite differently when it comes to JavaScript"), esto requeriría algo así como reinventar la rueda, dedicando un tiempo precioso. Más económico es revisar las propias plantillas cuando resulte necesario, y buscar medios de simplificar su solicitud de servicios del marco Dojo/Sencha. Un compromiso entre resultado final y optimización.

Una presentación: Plex + Webclient

Una presentación publicada hoy por CM First, sobre PLex + Webclient. Para quienes no conocen Plex, una vista estimulante de sus posibilidades. Para quienes usan Plex y evalúan mover sus aplicaciones a nuevas arquitecturas, una idea de cómo mover aplicaciones a web + /o cloud +/o dispositivos móviles. Para quienes no conozcan Plex, es importante tener en cuenta la flexibilidad disponible en cuanto a arquitecturas.

Developing App with CA Plex + CM WebClient from CM First Technologies

En mi caso, este mes, testeando Plex + Android. Quizá agregue algunas líneas sobre sus resultados.

Plex 7.0 disponible

Desde hace unos pocos días está disponible la versión 7.0 de Plex, con buenas novedades especialmente para la variante .NET, soporte de Azure, servicios web, java/JEE (pensado para java 7), y el uso incrementado del API de Plex. Un aspecto que especialmente valoro es que su aparición mantiene un ciclo relativamente corto de actualizaciones.
La persistencia en el trabajo sobre el API del modelo facilita además la labor de partners, que pueden crear extensiones con mayor control sobre el modelo. Podemos decir que Plex sumado a las extensiones que explotan el API abierto, permiten cubrir ampliamente las plataformas existentes y las emergentes. En particular, estoy esperando en algunos días ver el primer ensayo sobre Windows 8 Metro, la ejecución de una aplicación construída con WebClient (Plex generando Java, HTML5, JavaScript, y CSS3). Considerando la evolución de Windows 8, creo que tenemos garantizada una nueva actualización de Plex en un ciclo más corto que el anterior.
Un documento de presentación está disponible en el sitio de CA.

Java y Metro/WinRT

Windows 8, en su versión orientada a futuro, es Metro/WinRT. Francamente, no sé si Metro será un nuevo Vista, condenado a ser cambiado a una nueva versión tras ser descartado masivamente; sin embargo, creo que está claro que este será el nuevo sistema operativo de Microsoft, con mayores o menores parches o variaciones, después de un mayor o menor paso de tiempo. Y también está claro que el API de Win32 tiene sus años contados, que será considerado "legacy", y que no se deben esperar mejoras futuras sobre él. En estas condiciones, que creo que son irreversibles desde el punto de vista de Microsoft, WinRT debe ser considerado como el futuro del mercado Windows dependiente.
Si esta premisa es cierta, la pregunta siguiente es acerca del universo de productos, lenguajes o herramientas construídas sobre y para esta plataforma: seguramente, algunas que ya hoy han quedado obsoletas, o cambiarán radicalmente, o deberán repensar una tecnología que las suplante, como sería el caso de Flash. Otras, las más, enfrentan un camino complicado. Particularmente, en este momento pienso en Java; no sé si tendrá sentido crear una máquina virtual pensando en Metro como interfaz de usuario (tiles, pantalla táctil), que pudiera quedar a futuro como algo más asociado al usuario final, a tablets, a dispositivos móviles en general. Pero seguramente sí debe comprobarse que una máquina virtual puede ejecutarse sobre WinRT. No he visto todavía ningún pronunciamiento de Oracle ni de otros responsables del estándar, y probablemente pase algún tiempo antes de que haya alguno; habrá problemas de políticas (qué excelente momento para cerrar Windows a la competencia...), antes de resolver cómo enlazar la máquina virtual. por ahora, solo es posible encontrar algunos sencillos intentos de ejecutar java, algunos logrados, pero doy por entendido que estos casos lo han hecho sobre el escritorio (Win32). La siguiente es una pequeña lista de  casos en este sentido:
Ejecutando Java en DOS, claramente sobre Win32,
Lo mismo, en una edición temprana.
Un intento de  instalar Eclipse.
Un intento algo inadvertido, quizá sobre Metro, pero que cae hacia Win32.
Un intento con muchos problemas.

Sin embargo, lo más sustancioso está en otros casos tempranos enfocando Metro/WinRt. Particularmente uno en Google Groups (The Java Posse), discutiendo los problemas de arquitectura (aunque para nada hay que despreciar otro argumento discutido allí: "The real reason is Microsoft pathetically trying to exclude competitors and competing technologies, trying to impose HTML5 for everything"):

So it seems that Windows 8's new "Metro" user environment will make IE plugin-free. Any attempt to use plugins like Flash, Java, Silverlight or anything else, will bring the user to the "old-style" (as in  Windows 7) desktop, which will be seen as a severe experience degradation for users who prefer the new environment.

I am not as much plugin-hater as some people; in my Android smartphone, I certainly appreciate the support for Flash, for simple practical purposes - the rare website that uses some Flash and has no mobile-optimized version or native Android app. And yeah, my karma be damned but Flash works well enough  for me (admittedly on a nice hardware - Tegra2, dual-core Droid X2, rooted & debloated, Flash updated to 10.3).

Still, I love the idea of a plugin-free world, if only for the security improvement. (Including avoidance of trash like "security plugins" mandated by online banking sites...) But this is not really fair if we consider modern browsers that run plugins in separate and low-privilege processes, plus enhanced plugin technology like Google's (Pepper and NaCl / PNaCl), plus plugins for runtimes that are managed and have their own sandboxing and security mechanisms and are sufficiently well patched (candidates: Java, Flash, Silverlight - yes none of them are perfect, they all add some to the attack surface, but the ever-growing browser is already a huge attack surface, there's no single week going without new security bugs being found in every major browser so I don't think the "three big" plugins would make things significantly worse).

There's already people betting that Microsoft will have to back away and maybe, put an option to allow plugins in Metro mode even if not active by default. I know for sure, that corporations are writing new apps with things like Flash, by the thousands. Everybody complains that the corporate world is still dragging its feet with old versions of IE, remarkably the much reviled IE6; but if you think that ActiveX code for IE6 is holding back the web, this is nothing compared to how much stuff depends on Flash. A plugin-free IE10+ will be adopted in corporate world by 2020 with some optimism...

What about the applet tag? This is not part of HTML5 anymore, but it's part of previous versions even if deprecated. This should give Java applets special privileges, at least if Metro-mode-IE will support pre-HTML5 markup (and sure as hell it must, for a long time still). I'm too lazy to install the Win8 beta just to check this, would anybody report if applet [tag] works in Metro/IE? Just curious, I guess it doesn't...

Even in HTML5, there's the [object] tag which is supported and not even deprecated. Will Microsoft break the spec and declare that this feature of HTML5 is not supported in Metro mode? What about Java WebStart, maybe the deployment toolkit can be adapted to detect Metro and not depend on [object], I guess the only fundamental need is the ability to download a JNLP file and launch the associated program? Will Metro restrict such launching too? Both Oracle and Adobe are working on their Plan B for the eventual dominance of HTML5, with new tooling that convert their stuff in plain HTML5. In Oracle's case, there is hope for JavaFX 2.0 if its Web Runtime turns out to be good (it's not yet included in the public beta so I have no idea). There is no similar hope though for old-style, AWT/Swing applets or JAWS apps that will not benefit from a similar Web Runtime.

By the way, the JavaFX Web Runtime (WRT) will be a very interesting test for the claim that Javascript & HTML5 can be fast enough and powerful enough to build any application, competing at least with Java/Silverlight/Flash if not with native apps. Summarizing, the WRT will have a pure-web implementation of the JavaFX frameworks (animation, controls, graphics etc.), I guess using canvas or WebGL and Javascript; and the application code will be (perhaps partially) converted to Javascript code. So, supposing that this WRT is well designed and implemented - and that's a core part of the v2.0 reboot plan so I guess they carefully redesigned the whole thing to make the WRT possible - then if it turns out to be much less efficient than the conventional runtime, this will be strong evidence that the mantra "HTML5/Javascript is fast enough" is bullshit. Let's wait and see.

In another interesting development, Google's technologies like PNaCl and Dart can be powerful enablers for anything that generates Javascript code, from GWT to Adobe's and Oracle's  tools. Dart is supposed to be much more efficient than Javascript, and also, the Java language will probably be much
closer to Dart than it is to Javascript (less sure about AS3...); and I'm sure Oracle and Adobe can write new compilers that emit Dart code instead of Javascript code. Or even, PNaCl code. So if these Google technologies succeed, they can benefit other platforms too. We will still be able to run other browsers in Win8. 

Otra interesante apertura es la expuesta en Iced in code:

The big question now is where does JavaSE fit in all this bold re-imagining? Oracle/Sun have done a great deal of work over the past few years to get Java to work pretty well on Windows and become as natively integrated as possible, but with the re-working of Windows, Java will be confined to the “legacy” application section for the time being, and will not be able to play with the new cool kids in the “Metroverse”. I wonder what steps Oracle  is going to take to make Java still a viable product in the new Windows 8 platform, or will they simple give up and require us all to move to platform specific programming again, like C#?

y alguna acotación de lectores:

First, Oracle should under all circumstances make Java SE compatible with the new platforms like tables, macbooks and metro to keep their concept intact – OR – find a way to easily let Java SE applications run as “apps-likes” under another Java distribution made specificly to these platforms.
Second, Metro is nothing more (or less) than a simple “start-web-page”. Windows 8 is very similar to Windows 7, with program and filesystem seperated – where android and apple are more likely to melt these two things together. Therefore I doesn’t like andorid and apple as their operationsystem are defining the limitations. Some people would call that user-friendliness, I partially agree with that.
I believe that Windows 8 Metro will be an extension to their current desktop on traditional computers, but not a future replacement making the desktop legacy – and we won’t see anything like this within the next 10 years. But Windows 8 Metro will be the beginning of web and computers melting together – and this will eventually make the desktop computer look more like a tablet – and a tablet will look more like a desktop computer – and that will happen!

Uno de los casos que chocaron con WinRT.
Una discusión que refiere a Intel y ARM.

En fin, faltando una respuesta oficial de Oracle, comienza a abrirse el juego. ¿Va usted sopesando el impacto de Windows 8 en sus inversiones en licencias, plataformas, aplicaciones?

Plex => WebClient => Ipad

Para usuarios de Plex, o interesados en mover un modelo a aplicaciones móviles: una pequeña presentación de WebClient adelanta bastante información acerca del proceso de creación de una aplicación desarrollada para Ipad con Plex. No es posible entrar en detalles sin la documentación esperada para la versión 1.8, pero da una idea de los pasos a seguir, básicamente en la misma vía que lo necesario para construír una aplicación web estándar de Webclient, pero en una Mac: Plex [en una máquina virtual]=> Eclipse [Indigo en este caso] => [PhoneGap] => Código listo. Brevemente se explica también la variante Android.

Webclient 1.8 anunciado

CM First ha publicado una presentación que adelanta la salida de su versión 1.8, y programa la 2.0. Debo decir que conozco de primera mano la versión 1.8, y puedo asegurar que en principio la versión agrega confiabilidad y robustez, sin contar cualquier otro cambio que incluyera. La principal novedad es el lanzamiento oficial del soporte de aplicaciones móviles (Ipad, Android) usando patrones de Sencha, HTML5, CSS3. Arrastrar y soltar, exportar a Excel y otros, almacenamiento local, manejo de temas como conjuntos de definiciones de estilo, son aspectos que se agregan. Soporte de servicios web,  portlets y la nube de Amazon son anunciadas, y veremos hasta dónde es aprovechable su extensión. Webclient 1.8 está testeada sobre la próxima nueva versión de Plex (7.0), que está en este momento en pleno beta. Buenas noticias...

Webclient mobile es ahora open source

La newletter de CM First publicada hoy comunica que la elaboración de las nuevas plantillas destinadas al soporte de aplicaciones móviles se convierte en un proyecto open source. Es decir, abierta fundamentalmente a la comunidad de usuarios y desarrolladores de Plex/Webclient, porque de todas formas trabajar con ellas exige disponer de una licencia. Sin embargo, esta decisión representa otro paso destinado a abrir el desarrollo de patrones, semejante al que diera AllAbout hace un par de años abriendo el desarrollo de su desarrollo sobre XML. La arquitectura de Plex en su basamento en patrones y el desarrollo creciente de su API están permitiendo abrir sus posibilidades y extender su alcance. Los patrones para dispositivos móviles (teléfonos y tablets) se han iniciado con una base importante, y se potenciarán con participación abierta. Hay muchos otros campos donde aplicar este concepto.
El nuevo proyecto, en Google.Code.

Lenguajes de programación y rankings

Reviendo dos rankings de lenguajes de programación: Tiobe y The Transparent Language Popularity Index, éste último, en Source Forge (apuntado por Jean Bezivin). Coincidencias básicas entre ambos para los primeros puestos: con leves diferencias, Java, C, C++, PHP, C#. En ambos rankings, no se habla de número de aplicaciones, líneas de código, ponderación de la importancia de las aplicaciones involucradas. Fundamentalemnte, lo que establece su importancia es la popularidad del lenguaje. La fórmula de Tiobe lo explica:

The ratings are calculated by counting hits of the most popular search engines. The search query that is used is

+" programming"

This search query is executed for the top 6 websites of Alexa that meet the following conditions:

• The entry page of the site contains a search facility
• The result of querying the site contains an indication of the number of page hits

Based on these criteria currently Google (32%), YouTube (10%), Yahoo! (3%), Bing (3%), Wikipedia (16%), Blogger (32%) and Baidu (3%) are used as search engines. The number of hits determine the ratings of a language. The counted hits are normalized for each search engine for the first 50 languages. In other words, the first 50 languages together have a score of 100%. Let's define "hits50(SE)" as the sum of the number of hits for the first 50 languages for search engine SE and "hits(PL,SE)" as the number of hits for programming language PL for search engine SE. Possible false positives for a query are already filtered out in the definition of "hits(PL,SE)". This is done by using a manually determined confidence factor per query. A query such as "Basic programming" also returns pages that contain "Improve your basic programming skills in Java". The first 100 pages per search engine are checked for possible false positives and this is used to define the confidence factor. If this factor is 90%, then only 90% of the hits are used for "hits(PL,SE)". An overview of the confidence factor can be found in the groupings table below.
The ratings are calculated with the following formula:

((hits(PL,SE1)/hits50(SE1) + ... + hits(PL,SEn)/hits50(SEn))/n

where n is the number of search engines used.

¿Son importantes estos índices? La popularidad implica que han ocupado la atención pública, que fue analizado para su adopción, que distintas comunidades recurrieron a consultas para resolver problemas o educarse, en fin, que estuvieron en el foco de la atención de la comunidad de la industria. Pero no habla en todo caso de los consolidados, aquellos que se usan sin ruido, y que pueden ser usados también en abundancia, como sin duda sucede con COBOL, RPG y otros.
En el último tiempo, suele hablarse de Java como un lenguaje "corporativo", igualándolo a "legacy". Su continuidad en la primera línea en todo caso muestra que su interés no se ha amortiguado.

Plex adopta los sistemas móviles

Finalmente, luego de la entrada inicial de Websydian con aplicaciones WAP, la introducción de Ajax en distintos grupos de patrones derivados de Plex, favorecieron la extensión de su soporte a recursos móviles. Ya prefigurado en la versión 1.6 de Webclient (con soporte de Dojo y JSON) , el anuncio de su siguiente versión confirma la capacidad de generar aplicaciones para smartphones (iPhone, Android). ADC Austin ha programado una webcast para enero con explicaciones específicas sobre las nuevas capacidades planeadas. El nuevo release está previsto para la primavera europea.
Websydian, como hemos dicho antes, también agrega soporte AJAX a sus patrones usando Ext JS, que seguramente también robustecerá su soporte de aplicaciones móviles. Su versión está anunciada para junio del próximo año.

Websydian agrega AJAX a sus patrones web

El 16 del mes próximo CA y Websydian organizan una presentación de la incorporación de Ajax a los patrones de Websydian. Finalmente, luego de varios años de basarse en el modelo de formularios Get/Post con html, Websydian/SoftDesign adoptan el modelo Ajax. Se unen así a lo que adelantara ADC Austin con Webclient, y All About Software con PlexXml. Mientras que ADC se ha basado en Dojo, Websydian declara apoyarse en Ext JS. Se trata de un paso adelante muy importante, especialmente considerando el gran patrimonio que ya posee Websydian en patrones de arquitectura web. Esperaremos las novedades.

Nuevas reflexiones sobre el software futuro

La semana pasada hubo un gran revuelo en la comunidad de usuarios de Silverlight. En su PDC2010 (Professional Developers Conference 2010, finales de octubre), Bob Muglia y Steve Ballmer hicieron comentarios que indujeron a pensar a distintos observadores que Silverlight pasaba a una vía muerta. Mary Jo Foley publicó un artículo que corrió como la pólvora, y desató toda clase de especulaciones que todavía duran. Aunque el tema de por sí es muy interesante, en este caso deberá quedar para otra oportunidad. Está por verse si realmente Siverlight pasa a mejor vida, o el revuelo proviene de un torpe manejo de relaciones públicas (dicho sea de paso, el post del blog de Siverlight que acompañó al anuncio, y que se convirtió en un muro de los lamentos, todavía no ha tenido una respuesta clara y definitiva de parte de sus autores, a cinco días de emitido). En fin, lo que particularmente me atrajo en este caso, fue el tipo de discusión que generó: una vivísima representación del estado de la construcción del software en ésta época. Lo que sigue es una lista de asuntos de primera importancia que fueron discutidos. Todos los comentarios siguientes son respuestas al post de Bob Muglia en el sitio de Silverlight. Al fin de cada párrafo se indica el nom de guerre que cada usuario prefirió usar. Hay mucho más material en otros sitios que generaron respuestas, otros interesados con blog propio, comentarios de periodistas de tecnología, etc. Quizá más adelante se agregue algo de esto.

Múltiples dispositivos y plataformas, no más un ambiente cerrado y confortable
Uno de los temas de mayor preocupación reflejados es el de la cobertura del producto respecto de dispositivos crecientemente heterogéneos, no sólo escritorio: mientras sus seguidores esperarían la ampliación de Silverlight "al menos" a Android, si algo dejan claro, es que para el producto, sólo hay planes para Windows Phone 7. Claramente, el mundo ha devenido heterogéneo y no monoproducto:

I'm in a project where we have to make a decision between Silverlight and HTML5. We were leaning toward Silverlight, but then put the brakes on when we heard about the comments from the PDC. This blog post doesn't help Silverlight's case. It merely looks like you're trying to calm a panic. But the reality is that anyone deciding on Silverlight vs HTML5 for new applications, that will be supported years down the road, must seriously consider jumping into HTML5 as the safer path. Clearly you've admitted it's the best path for cross platform applications. In an iPad, Android, Windows and everything else world we are flying toward... how can we *not* pick HTML5. (Dave Friedel)

To rectify this, I need to see an announcement that Silverlight will be ported to Android. Flash has. Yes, an iPhone port won't happen bc Apple policy, but Android is shipping on more phones and is more likely to be used by business people than iPhone. WP7 is starting from too small a base to invest in significant development. Right now develop for iPhone bc it's got the buzz, Android bc it's got the momentum, and then WP7 if and when resources allow. An Android port of Silverlight means develop for Android/WP7 first which further deflates iPhone momentum. Think strategically. (Anónimo)


I understand that porting it to iPhone is beyond Microsoft's reach and depends primarily on Apple , but it would be nice to get it ported to Android. No one expects you guys to cover all of the platforms with SL, but it would be nice to cover the most popular ones.(Nick Polyak)


Your competitior isn't backing away from taking its technology to popular platforms - they're finding ways to reward developers and designers for their continued support and loyalty by making sure they have a path to run everywhere that's relevant. There's no questioning their commitment, and yet questions persist about yours. (Anónimo)

Basically you're saying that it's not a battle you want to fight, so you're giving up altogether. I don't think everyone expected Silverlight to be on every device. Heck, the top 10 would be more than enough to satisfy nearly everyone out there (including devices your company controls and owns, such as Windows, Zune/WP7 and XBox).
HTML5 certainly hasn't had a problem with adoption on several devices. Heck, even Android (an entire OS) hasn't. So why is Silverlight having such a challenge in doing it? (Daniel)


I've been building a website over the past 2 years that incorporates 20,000+ lines of Silverlight on the client side (and yes, it really does need to be that complex.). I've been completely trusting Microsoft's commitment to this platform, but I'm now very very worried indeed. I've just spent all weekend learning GWT, and I'm starting to think a port might actually be plausible. Bob's blog post really seems nothing more than a half-assed effort at damage control, and I'm afraid that where there's smoke there's probably fire.
This time last week, I was silverlight's greatest fan. But unless you do a *lot* more to restore my confidence, I'm planning to spend the next month seeing how far I can get in migrating to GWT. I can't quite understand why you think this is a good thing for Microsoft. (ArcMan)

I'd like to see Silverlight and the Metro UI phone/tablet interface integrated tightly into Windows 8 the way iOS is being integrated into OSX Lion.

Microsoft should utilize Windows Phone 7 and the Silverlight implementation to create an install base of developers who can then populate a mobile, desktop, tablet, and web app store. It only makes sense then to include license options for apps that run across the different mediums the Silverlight can hit.
I think anyone who doesn't see Silverlight as an LOB/media tool is missing the boat. I would never build a website in Silverlight. I would build my media viewer or my backend system though. I would definitely build an app on Silverlight. (CKLuis)


" As a result, getting a single runtime implementation installed on every potential device is practically impossible. " [conceptos de Bob Muglia en su post]
It's absolutely possible, and moreover that's exactly what must be done. You can have platform specific extensions of course, but core must be the same for all platforms. And if you cannot implement SilverLight runtime for all possible devices, just open source it, and it will be ported to any "potential" device in few months, and we won't need to even listen this meaningless statements how "cool" HTML5 is. (Sipank)

As a .NET/XAML programmer I've been very disappointed that I can't target one of Microsoft's popular platforms, the XBOX 360. It has been difficult to understand this glaring omission, but Scott Barnes' explanation as to the internal unpopularity of WPF sure seemed to make a lot of sense. For the immediate future, say the next five years, these are the relevant platforms...

Windows
Mac
iPhone
Droid
WP7
XBOX
Playstation

You're already on three of the seven. After watching you guys for years supporting NT on x86, Alpha, and x64, you can't convince me that you can't easily port a 5MB runtime to four more platforms. The tools and silverlight groups have done AMAZING work, to "shift" strategies now would truly be grabbing defeat from the jaws of victory. I imagine your partners like Netflix would be delighted if they never had to do another port again and could rely on Silverlight. Seriously, if Sun and their grotesquely incompetent programmers were able to port java to so many platforms, you guys should at least be able to get it on seven. (Jack Bond)

I see silverlight as a better and lighter version of desktop runtime in replacing wpf which is so heavy and hard to deploy to people who don't have the latest runtime.
I found that even without html 5, the current javascript + html4 + css enable people to build much prettier and user friendly UI. Silverlight follows a desktop UI philosophy and doesn't really fit into the browser except some case of advertising oriented banner... (collaboration cloud)

Do what should have been done in the first place - make Silverlight compile down to a html5 compliant web application. You know, sorta like how GWT does it. Write java, get all the benefits of it, but it produces minimized, best practice compiled javascript.

I think MS took the fight against 'Flex', and by the time it was ready, realized they missed the train because Apple and Google are attacking the web pieces, meanwhile MS went backwards and is now sitting in the same 'yucky' spot as Adobe.

Making browser plugin's is yesterday's technology.

Actually, what is odd, is that the MS team used Script# to build the online Office - not Silverlight - that alone should tell you the status of Silverlight. Wake up people. MS should be investing in Script#, not Silverlight. (Steve)


The community will definetly like to see silverlight ported to more platforms. How commited are you to making silverlight cross platform? (Arson)

When you buy a PC or a car, you own it. You are free to use it the way you like and you can install any extension/software you want without asking the manufacturer. The mobile phone market is different. Think of it as a car you paid for in cash, however every year you have to pay a license fee and for every drive you have to pay-per-use for the steering wheel. Not to mention the payment for the manufacturer's OK for 3rd party tires... This is exactly the Apple business model for the iPad/iPhone. You buy it, yet Apple owns it/controls its usage.
Now Microsoft obviously failed in coming up with a similar or competing business model. Option a) entering the hardware market, controlling the devices, with full power offends all hardware partners and option b) controlling the application market through a license check in the SL runtime fails, because Silverlight (legally) cannot be installed at the majority of mobile devices.
(...)

So dear fellow developers, this is not about SL, this is about losing the first big battle on the mobile phone operating theatre. We're the collateral damage.

Microsoft has enough cash for scraping another phone platform; happened early this summer didn't it? However what about you and me?
And I hope: Microsoft buys Nokia. (Hidden War)

Los lenguajes y arquitecturas propietarias son un escollo
Un tema que subyace en la preocupación de varios de los reclamantes, es la necesidad (aceptada o no, da lo mismo en este caso) de adaptarse a estándares concertados, dado que "el mundo es ancho y ajeno":

What we have here is a fundamental conflict between the desire for standards (although how anyone can call HTML a standard is beyond me since even simple stuff renders differently in different browsers) versus the desire for productivity. Given enough time, resources, and patience, you could create and maintain just about any piece of software using just about any environment and tools. However, creating increasingly complex RIAs with the brain dead HTML/CSS/Javascript/4 million libraries stack strains the time constraints and resource that companies have and exceeds the patience of professional developers used to working with even modestly productive development environments. Silverlight should be more correctly call Silverbullet because it massively overdelivers on the productivity and capability needed to create RIAs. If standards are a problem, why not just turn the future definition Silverlight over to a standards body like Netscape did with Javascript and whoever did with HTML? Then the standards people would have their objections undercut and those of us who actually do development could get on with our work. (Bryan Morris)


Perhaps MS should consider releasing a lightweight SL runtime for low power handheld devices. This make great sense, because these small screen interfaces normally use fancy animations with just a minimal input control set, and a lightweight runtime would allow MS to easily port SL to a large number of low power devices.
The apparent problem now is that SL is rather weighted with features -- many of which are appropriate only in larger screen environs, and this limits the potential device audience. This is likely why WP7 required a more robust engine. Perhaps a simple solution would be to offer WP7 with the full runtime, but publish lightweight runtimes for the rest of the mobile universe. This would give WP7 a control set edge, and at the same time, would allow most (efficiently coded) apps to cover the bulk of the device universe.
The iPhone and other market-significant proprietary boxes will quite likely be pressed by market forces or lawsuits into support other runtimes, such as Flash and SL. A lightweight runtime option makes SL more palatable to these vendors, since they wish to protect product performance perceptions, but at the same, wish to enjoy revenues from app sales. (Handled device suggestion)


Silverlight is not and never will be the one tool to use for all situations but it continues to be a very useful tool for many situations.
I'm typing this on a iPad and so I cant use many of my own Silverlight apps in the same way that Flash isn't available to me.
After lunch I'll go back to my desk and continue to work on my current Silverlight project which is the best tool for that particular project and environment with some support software being written in MVC2 for the web.
To get angry for being told Silverlight won't run on iPads and some other environments is madness, we already know this. If you want to hit every environment, use an open standard like H5 and accept the limitations that come with it. Judge on a project by project basis. (kaseciu pildymas)


I understand your point and your choice of client side technology is the most reasonable choice given the platforms you are targetting. However that does change nothing about Javascript not being suitable for complex client application development. I believe that the main reason for the choice has nothing to do with Javascript qualities as a language and development technology rather than the simple fact that Javascript is available on all those platforms and Silverlight is not. And I believe you would seriously consider Silverlight or other technology based on statically typed language, full cross-browser and cross-platform compatibility etc. if it was supported on all those platforms.
My understanding of Microsoft's message is "we are not able to put Silverlight on every platform so we are moving to HTML5/Javascript". And my fear is that it will slow down and with time maybe even stop Silverlight development and expansion because Microsoft "already has a strategy to get you everywhere" so why invest to Silverlight. Or at very least "why invest to Silverlight in a pace like last years", which is also disappointing.
HTML5 is a must have, there is no doubt about it, but it should not affect Silverlight in any way. (Martin)


I am not sure why so many people blame Microsoft for their commitment to Silverlight. It was quite clear from the beginning that Silverlight will be only available for Windows platform. I don't think this decision changed to much. If you stick with Widows platform you will be fine in any case. If you wanted to have a cross platform solution Silverlight was never a good choose or did some of you naively think that it will be ported to other platforms? (Aleximo)


I commited our development team and reputation to Silverlight. And now I have been left high and dry ! I am not really convinced by this Blog Post. The message is out there, Microsoft is adopting HTML5 in preference to developing Silverlight further. Microsoft are just going to let Silverlight die, after a couple more weak releases. Shopw me the Silverlight Roadmap for the next 5 years, on the Main Microsoft.com page, and maybe you will convince the Developer and their bosses that we have all not just adopted a turky technology.
I should have learn't from the J++ experiment.
I will never trust MS again. (No longer trust Microsoft)

I think some of you are missing the big picture. Whether or not Silverlight's direction has "shifted" or whether or not HTML5 is a full replacement is tangential at best to the point Bob made in his original quote.
Many of you have been saying Silverlight is "cross platform". If we were in the 90s, this would be right, it covers multiple browsers on the two largest operating systems.
Bob's comments are simple: web development is not about cross browsers, and it's definitely not about two operating systems. The ecosystem of web applications on a broad scale is widening greatly to include many new OSes, hardware types, form factors, screen sizes, hell even bandwidth assumptions are up in the air at this point.
If you wanted a "cross platform" web site or web application, Silverlight isn't and never was the right answer. The only difference between last week and this week is that Bob pointed out that it is infeasible to port Silverlight to all of these devices, form factors, and platforms. That should have been obvious to anyone knowledgable enough to be on this thread; him saying it is just a rubber stamp on something intuitively true.
This was true last week and it'll be true next week: If you're trying to come up with a desktop application that is loaded through a web interface, and you're okay with only supporting two operating systems, Silverlight will give you some nice bells and whistles for grander application. However, if you're looking to make a truly cross platform web solution, you need to be using HTML and its related standards and technologies. (ChrisC)

El panorama está dado...Hay otros elementos de gran interés, que en todo caso, irán en otro momento. Por ahora es suficiente. Un común denominador entre tantos desarrolladores del ecosistema de productos de Microsoft, es la nula referencia entre todos ellos a herramientas de desarrollo basado en modelos, o al menos, referencias a lenguajes específicos de dominio,  a pesar que durante dos años el tema fue un caballo de batalla de Microsoft. Sin embargo, en el fárrago de lenguajes y arquitecturas, éste debiera ser el punto que les diera perspectiva y tranquilidad ante abruptos cambios de frente o apariciones de nuevas arquitecturas. Un elemento general es el sentido de decepción y vacío, frente a la inversión de horas y dinero, cuando el dueño de un producto los deja solos y sin respuesta. Una estrategia no recomendable, existiendo la alternativa del desarrollo basado en modelos, en el sabor que se desee.

El modelo de Eclipse + Plex... ¿+ Xtext?

Varios meses muy atareado. Vuelvo de dos semanas de vacaciones, y llega el momento de rematar el trabajo...Extendiendo dos modelos construídos con Plex, con una presentación basada en C++ y servicios llamados en iSeries-RPG400/RPGIV, para que puedan disponer una presentación Web. La parte Web, hecha con Webclient (ADC Austin), con su extensión Java/Javascript disparada a través del uso de Eclipse. Este es el segundo proyecto organizado fuera de CA usando Eclipse como un mediador para extender Plex (el primero, el open source encarado por Christopher Smith para usar las facilidades de test y depuración de Eclipse/java con Plex).
En fin, el proyecto funciona...A partir de los modelos diseñados para C++/RPG, creamos una variante Java-WebClient que separa el diseño de paneles (y reportes) en la variante, de tal forma que conviven en el mismo modelo dos paneles distintos; con sólo configurar una variante u otra, generamos paneles para cada lenguaje. La lógica la hemos desarrollado en la variante base (C++), usando metaoperaciones para separar las diferencias de implementación entre ambos lenguajes. Luego, el modelo declara en la variante Java-Web dos elementos: nueva herencia que indica qué tipo de paneles Web se construirán, y el lenguaje Java de implementación.Así, se genera distinto código según la variante configurada.
¿Cómo pasa el código de Plex a Eclipse? El código Java generado en Plex es tomado por scripts escritos en Ant y transferido a un proyecto JEE en Eclipse. El área de trabajo en Eclipse se compone de un proyecto Ant , uno Java, un servlet WebClient, y un proyecto Web (JEE). Por cada panel el proyecto java construye una función (servlet) que enlaza la presentación y los eventos interactivos con el código Javascript que ejecutará en tiempo real. El código javascript (Dojo + Json) está enlazado a plantillas tipo que son invocadas al indicarle al modelo que se hereda de determinados patrones Webclient.
Teóricamente, (y lo he puesto en práctica rudimentariamente) cada plantilla es factible de ser creada por el modelador. Mientras nos familiarizamos, nos hemos sujetado a utilizar las que están disponibles, modificando algunos aspectos de éstas, sea en las directivas de las plantillas o en las hojas de estilo asociadas.
El último paso es configurar los ficheros properties y adecuar el fichero de configuración de la aplicación Web (Web.xml), crear un paquete War, e implementarlo en Websphere (este paso resultó sorprendentemente más fácil de hacer de lo que esperaba).

Es decir, Plex es extendido en este caso agregando enteramente el código Ajax en un proyecto Eclipse, y asociándolo con el código Plex java mediante un servlet. Así, no sólo extendemos Plex a aplicaciones Web que se basan en Ajax, sino que podemos usar las facilidades de testeo y depuración de Eclipse: en una sesión normal, testeo el código java directamente en el ambiente Eclipse, y, usando Tomcat o Jetty, el código Web. Si hay diferencias de comportamiento, a revisar...(Consola de Java, Log de actividad del servlet).

Generalizando, la utilización de Eclipse por distintos grupos de desarrollos de Plex, puntualiza la potencia disponible a partir de esta combinación. Existen infinitos recursos disponibles en Eclipse, particularmente el Eclipse Modeling Framework, y las extensiones que lo utilizan (UML2, OCL). Aquí se ha mencionado a MODISCO (Model Discovery), como un elemento de mucho interés que debería ser seguido con atención. Y otro más debería ser seguido con máximo interés: Xtext, que por su versatilidad podría ser usado para extender Plex de muy distintas maneras.
Es mi parecer, y ojalá estuviera en mis posibilidades explorarlo, que es posible extender Plex para muy distintos alcances, entre ellos algunos que en más de una oportunidad fueron desestimados basados en el alcance estricto de sus generadores.
A modo de confirmación, dos discusiones (1,2) de finales de este mes muestran que es posible incluír IPhone o IPad entre las aplicaciones generables a partir de modelos Plex.

Rápida y breve historia del desarrollo en la Web

Un gráfico suele ayudar a entender un problema, particularmente las líneas de tiempo. Publicadas en Wikipedia, dos "timelines" sobre evolución de lenguajes y de browsers tienen la virtud de hacer visible el fulminante crecimiento de Internet como carril del desarrollo del software. Con trabajos precursores a finales de los ochenta, a partir de la década del 90 su crecimiento convirtió cualquier predicción sobre su evolución en hechos consumados en pocos años, retroalimentando una espiral de crecimiento que abre posibilidades apenas imaginadas quince años antes. Un impacto que promete cambiar profundamente las posibilidades de conocimiento del conjunto de la sociedad urbana.
Aquí se publica uno de ellos. El otro, se lo puede encontrar en Wikimedia.
Los artículos de Wikipedia que los sustentan son History of the web browser, y Web development.

Swift, un experimento sobre seguridad en Web

Lambda The Ultimate comenta un ensayo en curso que parece muy interesante: Swift, un sistema que basa la construcción de aplicaciones web en la utilización de una extensión de Java que aplica políticas de seguridad, y en tiempo de compilación divide el código entre JavaScript en el cliente, y Java en el servidor. Para seguir, tenga éxito o no. Presentación en Lambda...:

Swift: making web applications secure by construction

Swift is a language-based approach to building web applications that are secure by construction. Swift applications are written in the Jif language, a Java-based language that incorporates "security-typing" to manage the flow of information within an application. The Swift compiler automatically partitions the application code into a client-side JavaScript application and a server-side Java application, with code placement constrained by declarative information flow policies that strongly enforce the confidentiality and integrity of server-side information.

Swift was recently featured in the "Research Highlights" section of the Communications of the ACM, as a condensed version of an earlier conference paper. The original conference paper is Stephen Chong, Jed Liu, Andrew C. Myers, Xin Qi, K. Vikram, Lantian Zheng, and Xin Zheng, Secure web applications via automatic partitioning, Proceedings of the 21st ACM Symposium on Operating Systems Principles (SOSP'07), pages 31–44, October 2007.

Jif has been mentioned previously on LtU here and here.

La presentación en el sitio de Swift:

Swift is a new, principled approach to building web applications that are secure by construction. Web applications are hard to build because code and data need to be partitioned to make them responsive. They are also hard to build because code and data need to be partitioned for security. Currently there are no good methods for deciding when it is secure to move code and data to the client side.

Because of the connection (and tension) between the problems of security and interactive performance, Swift addresses both at once, automatically partitioning application code while providing assurance that the resulting placement is secure and efficient.

In the Swift approach, application code is written in the Jif language, a Java-based language that includes information security policies. The source code is automatically partitioned into JavaScript code running in the browser, and Java code running on the server. For interactive performance, code and data are placed on the client side where possible. Security-critical code is placed on the server and user interface code is placed on the client. Code placement is constrained by high-level, declarative information flow policies that strongly enforce the confidentiality and integrity of server-side information. The Swift compiler may also choose to replicate code and data across the client and server, with benefits for both security and performance.

En la base del sistema está Jif, que es descripto así en su sitio:

Jif is a security-typed programming language that extends Java with support for information flow control and access control, enforced at both compile time and run time. The source code for the Jif compiler and run-time system is now available for download. Jif is written in Java and is built using the Polyglot extensible Java compiler framework.
Static information flow control can protect the confidentiality and integrity of information manipulated by computing systems. The compiler tracks the correspondence between information the policies that restrict its use, enforcing security properties end-to-end within the system. After checking information flow within Jif programs, the Jif compiler translates them to Java programs and uses an ordinary Java compiler to produce secure executable programs.

Jif extends Java by adding labels that express restrictions on how information may be used. For example, the following variable declaration declares not only that the variable x is an int, but also that the information in x is governed by a security policy:

    int {Alice→Bob} x;

In this case, the security policy says that the information in x is controlled by the principal Alice, and that Alice permits this information to be seen by the principal Bob. The policy {Alice←Bob} means that information is owned by Alice, and that Alice permits it to be affected by Bob. Based on label annotations like these, the Jif compiler analyzes information flows within programs, to determines whether they enforce the confidentiality and integrity of information.

¿Podría agregarse una capa más, para crear el código que luego se compilará?. Para investigar, en la hora 25 del día...