¿Cómo hay que regular la Ingeniería Informática?

Estos días estamos viviendo otra vuelta más de tuerca a la Ingeniería Informática. Así que creo que ha llegado la hora de exponer mi punto de vista.

Espero que no contente totalmente a nadie. Ni a los partidarios. Ni a los detractores. Si no, es que algo habré hecho mal.

Por supuesto, esta es mi personal visión de las cosas.

NOTA: Es este texto el término "Ingeniero Informático" incluye a las profesiones de Ingeniero en Informática e Ingeniero Técnico en Informática así como a todos los títulos universitarios vinculados a ellos.

Pedir la regulación de la Ingeniería Informática ¿no es corporativismo?

Si yo pensase que se debe pedir la regulación de la Ingeniería Informática para defender los derechos de los profesionales de la Ingeniería Informática no me atrevería a decir nada. Nunca he sido partidario de los privilegios y no voy a empezar ahora.

Pero entoces ¿Qué razones hay para regular una profesión?

Claramente solamente veo una razón la defensa del interés general. Yo quiero que exista una regulación de la profesión de Ingeniero de Caminos porque no quiero que los puentes se caigan. Así mismo, yo quiero que exista una regulación de la profesión de médico porque mi salud y la de mis conciudadanos depende de ello.

¿y cómo identificamos el interés general?

Pues a falta de otras referencia a mi se me ocurre que una buena fuente es la Constitución Española. El Título I define los derechos y deberes fundamentales. Y ese creo que debe ser el marco de referencia. Volveré a ello más tarde.

Entonces ¿No debería requerirse la firma de un Ingeniero Informático en todos los proyectos Informáticos?

Pues de ninguna manera. Yo creo que solamente debe regularse la realización de actividades que afecten al interés general.

¿Y no debemos exigir un título concreto para programar?

Pues eso está en la libertad de cada empleador. Pero no se me ocurre por qué habría que pedir tal cosa.

¿Qué modelo de regulación deberíamos tener?

Básicamente, según yo lo veo hay dos modelos de regulación de acceso a una profesión: el acceso basado en titulación y el acceso basado en acreditación.

El modelo basado en titulación es el que tenemos en España. Estar en posesión de un título da acceso directo a una profesión regulada. Uno va con su título universitario de Arquitecto y se inscribe en el Colegio de Arquitectos.

El modelo basado en acreditación se usa en algunos países anglosajones. Este modelo separa totalmente la titulación universitaria de la profesión. En este modelo son las sociedades profesionales las que evalúan que un profesional tiene la capacidad para ejercer una profesión regulada, independientemente de la titulación. Típicamente uno va a la universidad, ejerce bajo la supervisión de un profesional acreditado durante un periodo (uno o dos años en muchos casos) y luego realiza el examen en la sociedad profesional para obtener la acreditación. Como anécdota os diré que una vez conocí a una persona que era "Geólogo de formación e Ingeniero de Minas de profesión".

Un efecto adicional que tiene el modelo basado en acreditación es que la sociedad profesional se convierte de forma automática en un control de calidad externo de la formación que las universidades dan a sus titulados.

A estas alturas el lector habrá adivinado que modelo me gusta más.

Pero entonces volviendo a la Ingeniería Informática ¿Qué hay que regular?

Dije antes que únicamente aquello que afecte al interés general. Bien empecemos por la constitución como marco de referencia e intentmos ver algunso casos concretos:

Artículo 15: Derecho a la vida

Dice este artículo que "Todos tienen derecho a la vida y a la integridad física y moral". Bien, interpreto que esta es la razón que aconseja la regulación de las profesiones que pueden poner en riesgo la vida de las personas.

Bien revisemos algunos ejemplos de sistemas informáticos, para ver si afectan a esto:

Caso 1: Sistemas de control de tráfico. Hace años participé en el diseño y construcción del sistema de control del carril BUS-VAO en la entrada a Madrid por la A-6. Un error en este sistema puede provocar que dos vehículos se encuentren de frente sin posibilidad de maniobra. En el pero de los casos esto puede dar lugar a accidentes de tráfico.

Caso 2: Equipamiento hospitalario. Hace menos años diseñé y desarrollé una parte de un equipo de tomografía por rayos X (comunmente conocidos como TAC). Bien un error en el software de este tipo de máquinas puede provocar una dosis excesiva de rayos X a una persona. Y todos sabemos el efecto que tiene sobre la salud.

Caso 3: Tráfico aéreo. Recientemente se ha sabido que fallos de seguridad informática podrían permitir que una aplicación informática podría permitir desviar la ruta de un avión. Sin comentarios.

Artículo 18: Informática y derecho a la intimidad

Dice el artículo 18.1 que "Se garantiza el derecho al honor, a la intimidad personal y familiar y a la propia imagen". Y el artículo 18.4 insiste en que "La ley limitará el uso de la informática para garantizar el honor y la intimidad personal y familiar de los ciudadanos y el pleno ejercicio de sus derechos".

En la época en las que nuestros datos son almacenados y tratados por múltiples sistemas informáticos uno se hace múltiples preguntas.

• ¿Quién garantiza que los datos que almacena la agencia tributaria se almacenan y tratan con las debidas garantías?
• ¿Quién garantiza que los datos que de nosotros tiene la seguridad social (como nuestro historial médico) se custodia con las debidas garantías? ¿Y los de los hospitales privados?
• ¿Quién garantiza que los datos que tiene la administración de trabajo no se revelarán a nadie?
• ¿Y los datos que tienen nuestros empleadores?
• ¿Y los bancos?
• ¿Y las compañías de seguros?

En definitiva ¿Se está garantizando adecuadamente nuestro derecho a la intimidad?

Artículo 30: Derecho de propiedad

Dice aquí que "Se reconoce el derecho a la propiedad privada y a la herencia."

Este es un derecho tremendamente complejo y con muchas derivaciones. Pero me gustaría hacer alguna consideración.

He perticipado en la puesta en marcha de servicios de alguna entidad bancaria. En este caso, un error en el desarrollo o en la operación y mantenimiento del sistema informático, puede dar lugar a graves pérdidas para la entidado así como perjuicios para los clientes.

Y ¿qué pasa cuando la un problema llega a los tribunales?

Un caso de litigio laboral

Supongamos un caso concreto y muy parecido a uno real que conozco de primera mano. Una empresa despide a un empleado aduciendo que su baja productividad se debe a que hace uso de los medios informáticos de la empresa para fines personales. Como prueba, presenta un listado del registro de actividad del router de acceso a internet en formato PDF (cuando queráis generáis uno así con el Word). Así mismo presenta un informe pericial realizado por un Ingeniero Técnico Industrial Mecánico (disciplina, a la que por otra parte respeto profundamente).

Mi pregunta es ¿debe el juez aceptar esto como prueba? Seguro que al lector se le ocurren más preguntas al respecto de este caso.

Otro caso distinto

Supongamos ahora que los empleados del departamento de informática de una empresa se marchan de la misma. Supongamos que se llevan una copia del código fuente de la aplicación estrella de la empresa al que realizan modificaciones y lo comercializan bajo otro nombre.

Y yo me pregunto ¿quién está cualificado para determinar si se ha producido copia del producto?

En conclusión

Visto lo visto, si como parece el Gobierno decido no regular la profesión de Ingeniero en Informática estará cometiendo un grave error, no porque decida dejar en una situación irregular a los Ingenieros en Informática de este país. No será por eso. Será porque no está defendiendo el interés general.

Y hasta donde yo se, es obligación del Gobierno de la Nación defender el interés general de sus ciudadanos.

Standards and Patents (Educating colleagues)

Usually, I do not write twice about the same thing. And usually I am not very disciplined about blogging.

However, after my last blog entry, I have had multiple twitter interaction with a twitter user (@DrPantera). And finally I have decided that I have to post something that should serve as general standards education.

I want reproduce every interaction (which, by the way are in Spanish) but just give some general ideas. During our twitter discussion this user said:

• Only Microsoft can implement ISO/IEC 29500.
• It is nonsense standardizing a tool that only one company can implement.

I think both assertions are false. Firstly, I will explain why.

ISO/IEC 29500 defines a set of standard files format. So, it is not appropriate to speak about implementing the ISO/IEC 29500. What somebody can implement is a tool to produce, read, process, render (or whatever) files in such a format.

Anyway, the real argument was that as some parts of the format are protected by patents, only the patent holder (Microsoft in this case) can implement it. I argued, that another company could license the patent. The counterargument is that only licensed companies would implement. That's right, that is how business work.

As the discussion was going on. I thought that instead of speculating the right thing was to go the right source: ISO.

Reading this page about Standards and Patents in the ISO Website was crystal clear:

First: ISO, IEC and ITU have a common patent policy. I am not a lawyer, read it yourself to be sure. However what I interpret in short is that if a deliverable contains provisions depending on a patent there are 3 options: either the patent holder agrees to negotiate licenses free of charge or the patent holder agrees to negotiate licenses with charge or the provisions are removed from the deliverable. In all cases license negotiations need to be on a nondiscriminatory basis on reasonable terms and conditions.

Second: What model applies to ISO/IEC 29500? Well in the same page there is en Excel file with all the current standards and associated patent holders. OK. What doest it says about 29500? There are patent notes at the name of Microsoft and the entry is marked with an "F".

What does the "F" means. Literally: <"F" = Prepared to grant a license free of charge>.

By the way, according to the same sources:

• ISO/IEC 14496-14 (MP4) is related to a patent from Apple (US Patent numbers 6,134,243,6,453,355).
• ISO/IEC 15444-3 (JPEG) is related to a patent from Apple (6,134,243).
• ISO/IEC 32000-1 (PDF) is related to a patent from Adobe Sytems Incorporated 
• ISO/IEC 11172 series (MP3) is related to patents from very long list of companies.
• ISO/IEC 14496-10 (MP4) is related to patents from another long lsit of companies.

Most of those patentes do not have the "F", so you need to negotiate a patent licensing and eventually pay for it.

There is an important point on all this. There are some things that we have been forgetting for a long time in Higher Education of Computer Professionals.

FIRST: An engineer must always be as agonostic as possible. This means that if possible he/she must go to the right sources to get the right information. Moreover, making claims only based on available date is included both in IEEE and ACM code of Ethics.

SECOND: Understanding of standards is essential to any Computer or Software Engineer these days. It is important to understand the technical issues in the standards. But as I have shown this is not enough. It is important also to understand which is are the rules of standards bodies, how different stakeholders are represented (or sometimes underrepresented) in standardization, which are the standardization procedures.

THIRD: A basic knowledge of law is also very important. I have shown here that sometimes national laws may enforce the use of a standard. It is also very important that we as engineers are able to understand the implications of intellectual property and the role of patents (where applicable).

And coming back to our code of ethics, I feel that this post is writteng according to item 10 of IEEE Code of Ethics (to assist colleagues and co-workers in their professional development and to support them in following this code of ethics), and similar provisions in the ACM code of ethics and in the ACM Software Engineering Code of Ethics.

IMPORTANTE NOTICE: If you find that anythin of this post is not true or has any inacurracy, please, contact me and I will correct it inmediately.

Standards and Open Standards

When I write something about standards, usually is about C++. This post is not the case, so if you were reading this looking for C++ info, stop now.

A few hours ago, a good friend of mine (@jmdodero) wrote this tweet:

El MAP dice que docx es abierto! Standards for ES Public Administrations http://www.boe.es/boe/dias/2012/10/31/pdfs/BOE-A-2012-13501.pdf …

In English: "The Spanish Public Administration ministry says that docx is open! Standards for ES (Spanish) Public Adminstrations". The link points to an official document from the Spanish Government approving the Technical Standard of Standards Catalogue Interoperability. In essence this document establishes a list of standards to be used for the Spanish Public Administration.

I'll save you the legal details. However one of the items in the list is:

• Category: File formats - Image and/or Text.
• Common Name: Strict Open XML
• Formal Name: ISO/IEC 29500-1:2012 Information technology -- Document description and Processing languages -- Office Open XML File Formats -- Part 1: Fundamentals and Markup Language Reference - Strict
• Type: Open
• Version (minimum accepted): 2012
• Extension: docx, xlsx, pptx

A few minutes later. I answered:

ISO/IEC 29500-1:2012 y ECMA-376. Las dos públicamente disponibles = estándar abierto. ¿Cuál es el problema?

In English:

IOS/IEC 29500-1:2012 and ECMA-376. Both publicly available = open standards ¿What is the problem?

I should not be a typical suspect. I mean, I run a Linux laptop and 2 android devices. Many know that I think that the best editor is vi (vim is ok, too) and a really like LaTeX. However in a few minutes I got the following answers:

• @jdgarciauc3m when you save a document in MS Office 2010 […] you are not saving them in the advertised OpenXML format This document will hence NOT be properly readable by other software http://t.co/AeohSarn
• @jdgarciauc3m que no existe ninguna implementación del standard, ni siquiera MS Office lo soporta
• There exists no implementation of the standard, even MS Office does not support it.

Well, I thought that it was time to clarify what a I think. I'll try to do so:

Question 1: Is ISO/IEC 29500-1:2012 an open standard?

Well, this is the easiest question. By definition any ISO/IEC standard is an International Standard. I could explain this in more detail, but for now let's agree on this.

The definition of "Open Standard" is "a standard that is publicly available". As any other ISO standard, ISO/IEC 29500-1:2012 is available from www.iso.org.

Question 2: Does MS Office 2010 fulfill the ISO/IEC 29500-1:2012?

I hope not.

Surprised?

It is almost impossible that a product shipped in 2010 fulfills a standard that has been approved in 2012. The only possibility I see is that people at Microsoft had a time machine. And, I do not think they have (otherwise sometimes they would have made different business decissions), but, paraphrasing Michael Ende, that is a different story and must be told in a different time.

Question 3: If there is no existing implementation of the standadrd does it make sens to put it in the catalogue?

Yes. Let me explain why.

First. No one implements a file format. What one can implement is a tool for processing files (generate them, render them, ...) in such a format. However it may be true (I do not know and I do not mind), that no existing tool correctly processes the format.

What the Spanish official document is saying is that if a public agency wants to receive text documents from another public agency or a citizen, it must say which formats is willing to accept. By the way, ODT (ISO/IEC 26300:2006) , PDF (ISO/IEC 32000-1:2008) and PDF/A(ISO/IEC 19005-1:2005 and ISO/IEC 19005-2:2011) are also in the same list.

So, the point is. We have a format in the list and when some tools are available it is possible that an agency includes in the list that format.

I still do not see the problem.

Important news for the C++ Community

C++11 has been a major step for the C++ community. However, we need to do much more in the forthcoming years to help developers prodece better and faster software.

I recommend all of you interested in C++ to see Herb Sutter's talk this Friday:


The Future of C++ 
Friday, November 2, 2012
12:45pm (U.S. Pacific Time)

Probably, for those of you in Europe the time is not the best. In any case, it will be available for download a couple of days later. 

Let me tell you, that there will be at least one important announcement for C++ community.

To throw or not to throw: That is the question

While having dinner with some colleagues. We had an interesting discussion on the usefulness of throwing exceptions from libraries.

The discussion lead to comments on two books:

• C++ Coding Standards: 101 Rules, Guidelines, and best practices. By Sutter and Alexandrescu.
• API Design for C++. By Martin Reddy.

As I remember the conversation the statement was more or less "A (well designed) API should not throw". My first thougt was that some time had passed since I read both books and that I did not remember the rule to be so severe. So I decided to go back and read again the books. First of all let me say that I enjoyed a lot reading both of them. C++ Coding Standards is an excellent book and I am really willing to see when Sutter and Alexandrescu release a C++11 update of the book. C++ API Design is a good book. Although I may have some concerns on specific parts of it, I like it. And I have used some chapters in an invited course I gave on software design and patterns in C++.

Now, let's go to the topic.

A lot has been said about exceptions in general as an error reporting mechanism. One of my colleagues found conflicting the following advices/rules:

• Prefer exceptions to report errors. This is guideline 72 from Sutter and Alexandrescu.
• Don't allow exceptions to propagate accross module boundaries. This is guideline 62 from Sutter and Alexandrescu.

At first sight, it seems that both rules are conflicting. Are they? As some imprecise reference on API design for C++ was also done. I decided to go first to this one. I did not really find anything in Reddy's book against the usage of exceptions in general. What Reddy does is to provide good suggestions if you provide error reporting through exceptions in your library. To be fair, it also states that "Google forbids the use of exceptions in their C++ coding conventios because most of their existing code is not tolerant of exceptions". However that does not seem an argument against the usage of exceptions.

Now, let's go back to rules 62 and 72 from the C++ Coding Standards book. I will start with rule 72. I usually prefer this rule and I usually report errors through exception. The key rationale is that it easily allows to make a separation between the point were the error condition is detected and the point where the error condition is handled. This is generally what happens when a library does not know what to do when it detects the error.

Exceptions exhibit advantages over returning error codes:

•  Exceptions can't be silently ignored.
•  Exceptions propagate automatically.
•  Exceptions handling removes error handling and recovery from the main line of control flow.
•  Exception handling is a very good alternative for reporting errors from constructors and operators.

Some general disadvantages may be identified:

• Writing exception safe code is not easy for beginners and special care must be taken in destructors.
• Having exception compiler flags activated may lead to larger executable sizes. And in some platforms to minor performance penalties. However as even the standard library may throw exceptions it does not seem practical to deactivate those compiler options. And if the flags are activated the performance penalty is very low or even zero.

And finally let's got to the conflictive rule 62. If I read it as an absolute rule I am told that I should not propagate exceptions outside a module. My first answer was: "Well it depends on what you call a module". So I decided to read again rule 62.

I found out that Sutter and Alexandrescu name several things as a module. Their general definition is any cohesive unit of release maintained by the same person/team and consistently compiled with the same compiler and settings. Several grain size apply:

• A single object file delivering a single class.
• A single shared/dynamic library

As I read rule 62 and go through the summary I find an "unless". So the rule really says:

"Don't allow exceptions to propagate accross module boundaries unless you control the compiler and compiler flags used to build both sides". 

Now I got it. The reasoning behind the rule is that there is no standard for ABI. That is Application Binary Interface is dependent on compiler vendors and platforms.

So we have the following cases:

1. Applications using static linking. In that case you do not need to bother you can throw exceptions as they are needed.
2. Applications using dynamic linking in which the dynamic library and the client code are compiled by the same team, or tat least use the same compiler and the same compiler flags. I do not see a problem here either.
3. Applications using dynamic linking in which the dynamic library are distributed in binary format and/or are compiled with different settings. That is the case where we cannot have the luxury of propagating exceptions.

Is there any other reason to avoid the usage of exceptions? Well. Yes. There are.

Some specific guidelines for high integrity safety critical software may exclude using exceptions for different reasons. But that's a diffeent story.

A partir de ahora, también en inglés

En el pasado he recibido peticiones de poner en inglés alguna entrada de mi blog. Me sorprendió la verdad.

Mi primer impulso fue poner un plugin de google-translate. Sin embargo algunas cosas no acabaron de funcionar. Especialmente cuando empecé a poner código C++ en las entradas.

Conclusión. A partir de ahora algunas entradas las pondré en inglés.

Noticias desde la normalización de lenguajes de programación

Hoy ha terminado la asamblea plenaria anual del subcomité ISO/IEC JTC1/SC22. Los se. En el mundo de la normalización se utilizan acrónimos insoportables. Probablemente resultará más inteligible si lo reformulo: Hoy a terminado la asamblea plenaria anual de subcomité de normalización de lenguajes de programación, sus entornos e interfaces de sistema.

Hay una larga lista de resoluciones tomadas por el subcomité. Algunas son meramente burocráticas y me las saltaré. Vayamos a la que pueden tener cierrto interés.

• Se va a iniciar el estudio de una posible propuesta para normalizar la firma digital de código fuente.
• Se ha disuelto el grupo de trabajo WG11 (binding techniques). Este grupo ha sido responsable de trabajos en especificación de aritmética independiente del lenguaje. No obstante, el interés directo de la industria en las actividades del grupo parece bajo y no se consigue tener una masa crítica en el grupo de trabajo. Este grupo de trabajo no desaparecerá realmente, sino que sus actividades se transfieren a otro subcomité (gestión e intercambio de datos / metadatos).
• Se ha disuelto el grupo de trabajo WG16 (lenguaje Lisp). Este grupo ha dejado de tener actividad y no parece que haya sufiente interés industrial en el lenguaje.
• Se ha aprobado la posibilidad de que la especificación del lenguaje ECMAScript (norma ISO/IEC 16262:2011) se pueda obtener gratuitamente a través de ISO. Esta norma ya se puede obtener de forma gratuita a través de ECMA.
• Se ha confirmado la confirmación de las siguientes normas:
• ISO/IEC/IEEE 9945:2009 Portable Operating Systems Interface (POSIX) Issue 7.
• ISO/IEC/IEEE 11404:2007 General Purpose Datatypes.
• ISO/IEC TR 19768:2007 Technical Report on C++ Library Extensions.
• ISO/IEC 24716:2007 Native COBOL Syntax for XML support.
• ISO/IEC 24731:2007 Extensions to the C Library - Part 1: Bounds checking interfaces.
• Se ha decidido pasar a estado estabilizado (lo que hace hace que las normas dejen de estar activas) las siguientes normas:
• ISO/IEC 13568:2002 Z formal specification notation - Syntax, type system and semantics.
• ISO/IEC 15145:1997 Programming Languages - FORTH.
• ISO/IEC 20970:2002 JEFF File Format.

Además, se ha revisado el estado en el que se encuentra la normalización del lenguaje Ruby que ya es una norma nacional en Japón y que previsiblemente se convertirá pronto en una norma internacional.

Tras esto, merece la pena fijarse en cual es el panorama en la normalización de lenguajes de programación en los distintos foros internacionales.

La estructura de grupos de trabajo de normalización dentro del ISO/IEC JTC1/SC22 queda de la siguiente forma:

• WG4: COBOL.
• WG5: Fortran.
• WG9: Ada.
• WG14: C.
• WG17: Prolog.
• WG19: Lenguajes de especificación formal.
• WG23: Vulnerabilidades de los lenguajes de programación.

Otra organización internacional que trabaja en la normalización de lenguajes de programación es ECMA que mantiene los siguientes grupos de trabajo:

• TC49-TG2: C#.
• TC49-TG3: CLI.
• TC49-TG4: Eiffel.
• TC49-TG5: C++ para CLI.
• TC39: ECMAScript.

Por último, en Japón, IPA mantiene la normalización del estándar sobre el lenguaje Ruby.

Tanto Ruby, como las normas desarrolladas por ECMA pueden pasar por un proceso especial para convertirse en normas ISO. De hecho esto constituye una práctica habitual de la que Ruby y ECMAScript son dos ejemplos actuales.

Y ¿adonde nos lleva esto? Pues a una lista bastante pequeña de lenguajes. Es lo que yo llamaría los lenguajes portables de interés. ¿Qué quiero decir con esto?

Veamos para estar en mi lista un lenguaje de programación debe tener una especificación mediante una norma internacional, porque esto garantiza que:

1. Existe un interés por parte de varios actores de la industria del software en que exista una norma internacional sobre el lenguaje.
2. Existe una norma internacional que especifica claramente el lenguaje y su entorno de forma que distintos fabricantes compitan ofreciendo productos que cumplen con la norma.
3. El software desarrollado usando un lenguaje normalizado puede portarse con cierta facilidad de una plataforma a otra.

Como veréis mi lista no es muy larga. Por orden alfabético: Ada, C, C++, C#, COBOL, ECMAScript, Eiffel, Fortran, Prolog. A esta lista podremos añadir en breve Ruby.

De todas formas, debemos tener cuidado con las interpretaciones de mi lista. Esto no quiere decir que estos lenguajes sean los mejores, ni los más usados, ni nada por el estilo. No trato de generar una versión n+1 de la gran batalla de los lenguajes de programación.

Si un lenguaje está fuera de mi lista es porque:

a) No hay suficiente interés en la industria en el uso del lenguaje o en la existencia de una norma independiente.

b) El lenguaje está sujeto a algún tipo de propiedad intelectual que impide la competición entre distintos fabricantes o la existencia del mismo en determinado tipo de plataformas.

Sin embargo no me gustaría que este post empiece a generar comentarios masivos de fanáticos de ningún lenguaje.

decltype: ¿De qué tipo es esa expresión?

En mi anterior post sobre C++11 vimos que el uso de auto permite deducir el tipo de una variable, siempre que ésta se vaya a iniciar en el momento en que se define. Esto cubre un cierto número de casos, pero no todos.

hora obten_hora_actual() ;
coordenada obten_posicion_actual() ;

std::map<hora , coordenada> m;
m[obten_hora_actual()] = obten_posicion_actual();
//...

Bien. Parece que no habrá problemas. Bueno, realmente no habrá problemas mientras no se modifique el tipo de retorno de las funciones obten_hora_actual() y obten_fecha_actual. Lo que realmente me gustaría expresar es que m es un mapa que usa como tipo para la clave el tipo de retorno de la primera función y como tipo para el valor el tipo de retorno de la segunda función.

Aquí aparece en nuestra ayuda el operador decltype. Este operador, permite obtener el tipo de una expresión y se puede usar en cualquier contexto en el que se pueda usar un tipo.

hora obten_hora_actual();
coordenada obten_posicion_actual();

std::map<decltype(obten_hora_actual()),
 decltype(obten_posicion_actual())> m;
m[obten_hora_actual()] = obten_posicion_actual();
//...

Originalmente, algunos fabricantes habían implementado una extensión con un operador parecido: typeof. Sin embargo, la semántica de este operador era distinta, y el comité de ISO C++ decidió optar por una palabra reservada distinta. La elección de decltype puede parecerte poco afortunada, pero era la opción que menos afectaba al código ya existente.

Reglas para la evaluación de decltype

La expresión decltype(expr) se puede utilizar en cualquier tipo donde se pueda usar un especificador de tipo. De esta manera, se puede escribir el siguiente código:

int x;
long y;
decltype(x+y) z; // z es long

En este caso la expresión decltype(x+z) equivale al tipo long, puesto que el resultado de sumar un int y un long es un long.

En el caso de que la expresión pasada a decltype sea una variable, la regla es ligeramente distinta y el resultado es el tipo con el que se declaró la variable:

int x;

int & rx = x;

decltype(x) y = x; // int y

decltype(rx) ry = x; // int & y

Esta regla, hace que en este caso la deducción de tipos no funcione exactamente igual con auto que con decltype:

int x;

int & rx = x;

auto y1 = rx; // int y1. y1 es una copia de x

decltype(rx) y2 = rx; // int & y2 = rx. y2 es una referencia a x

Esto también es aplicable a los parámetros de una función:

template <typename T> class X { /*...*/};
void f(int x1, int & x2, const int & x3) {
  X<decltype(x1)> z1; // X<int> z1;
  X<decltype(x2)> z2; // X<int&> z2;
  X<decltype font="" int&>="" x>
  /*...*/
}

También se puede utilizar decltype sobre una invocación a una llamada a función. Es importante tener en cuenta que una invocación a función dentro de decltype no realiza una llamada a la función. Su único objetivo es determinar el tipo de retorno de la función.

string obten_valor(const string & clave, int indice);

void imprime() {

  list<decltype(obten_valor("usuario",0))> l;
  for (int i=0;i

    l.push_back(obten_valor("usuario",i));

  }

}

Una diferencia bastante relevante ocurre en el caso de que decltype se aplique a una variable que se encuentre entre paréntesis. En este caso el tipo determinado por decltype es siempre una referencia.

int x;

decltype((x)) y = x; // int & y = x

De forma general, esto ocurre con cualquier expresión que no sea exactamente un nombre de variable y que pueda actuar como un l-valor.

template <class C>
void f(C & c) {
  decltype(c[0]) t; // Error t es referencia sin iniciador
  // ...
}
//...
vector<string> v = { "uno", "dos", "res" };
f(v);

En este caso, el tipo de t se obtiene evaluando la expresión decltype(v.operator[](int)) que es un l-valor (en este caso una referencia a string). Por tanto el tipo de t acaba siendo string& y la primera línea de la función f() genera un error de compilación porque se estaría declarando una variable de tipo referencia sin darle un valor inicial.

Ahora bien, la mayoría de los ejemplos empleados hasta ahora (aunque no todos) pueden parecer artificiosos y poco útiles. Probablemente, sea cierto. Sin embargo, hay contextos en los que declttype manifiesta su verdadera utilidad como la deducción automática del tipo de retorno de una función o la especificación de excepciones mediante la nueva palabra reservada noexcept.

Una nueva vida para auto en C++11

Introducción

En C++11, la palabra reservada auto ha resucitado con un nuevo significado. C++ heredó esta palabra reservada de C, donde originalmente implicaba almacenamiento automático, como contraposición al almacenamiento estático. Sin embargo, al convertirse el almacenamiento automático en el almacenamiento por defecto de las variables, se hizo innecesaria su utilización.

Cuando un lenguaje evoluciona (como es el caso de C++11) se debe poner especial atención en que las modificaciones al lenguaje no afecten al código ya existente. Esto hace que los diseñadores del lenguaje sean muy reticentes a la introducción de nuevas palabras reservadas. Por esta razón, el comité de normalización tomó la decisión de resucitar auto dotándola de nuevas semánticas.

En C++11 se puede dar dos usos a auto:

• Para indicar la deducción automática de tipos en la declaración de una variable.
• Para indicar la deducción automática de tipo de retorno en la declaración de una función.

Cada uno de estos usos presenta ventajas en la escritura de código. Hoy presentaré algunos ejemplos del primer caso y dejaré para un próximo post el caso de las funciones con deducción automática de tipo de retorno.

Deducción automática del tipo de variables

Cualquiera que haya escrito código usando la biblioteca estándar de C++ habrá visto alguna vez cosas como la siguiente:

vector<int> v = {1, 2, 3};
for (vector<int>::iterator i=v.begin(), e=v.end();i!=e;++i) {
    cout << *i << endl;
}

Claro que esto puede empeorar:

vector<list<string> > v = { { "Carlos", "Maria"}, {"Niño", "Niña"} };
for (vector<list<string> >::iterator i=v.begin(),e=v.end();i!=e;++i) {
for (list<string>::iterator j=i->begin(), e=i->end(); j!=e; ++j) {
cout << *j << " ";
}
cout << endl;
}

Para complicar las cosas un poco más, todos los contenedores ofrecen variantes de iteradores (como const_iterator) que ocasionan algunos pequeños dolores de cabeza al escribir código.

Sin embargo en los ejemplos anteriores, tener que escribir los tipos de las variables i y j. No es realmente necesario. Se puede simplificar el lenguaje siguiendo una máxima que a mí me gusta mucho: “Deja que el compilador haga todo lo que puede hacer y deja el resto para el programador”.

Antes de entrar en los detalles del uso de auto, veamos los ejemplos anteriores en C++11. Baste por ahora decir que cuando se especifica que el tipo de una variable es auto, el compilador determina su tipo a partir del valor que se usa para iniciar la variable.

Con esto nuestro primer ejemplo queda:

  vector<int> v = {1, 2, 3};
  for (auto i=v.begin(), e=v.end();i!=e;++i) {
    cout << *i << endl;
  }

Y el segundo ejemplo:

  vector<list<string> > v = { { "Carlos", "Maria"}, {"Niño", "Niña"} };
  for (auto i=v.begin(),e=v.end();i!=e;++i) {
    for (auto j=i->begin(), e=i->end(); j!=e; ++j) {
      cout << *j << " ";
    }
    cout << endl;
  }

Deducción de tipos en contextos de declaración de variable

El principal uso de la deducción automática de variables es la declaración de variables.
Probablemente el uso más simple de auto es la declaración de una variable en un bloque (dentro de una función, dentro de un bucle,…) o bien en un alcance de un espacio de nombres.

  auto x = 5; // x es int
  auto z = 2.5;  // z es double
  string s = "Daniel";
  auto lon = s.length(); // el tipo de lon coincide con el tipo de retorno de length

Otros usos equivalentes son la declaración de una variable en una sentencia de iniciación de un bucle for, en una condición de una sentencia de selección (if, switch) o de una sentencia de iteración (while, do, for).

  string s = "Daniel";
  for (auto i=s.length();i>0;--i) {
    cout << s[i-1];
  }
  cout << endl;

Estos usos facilitan la vida del desarrollador permitiendo escribir código más simple. En este casi no es necesario recordar que tipo concreto devuelve la función miembro length(), basta con indicar que la variable i debe tener el mismo tipo.

Algunos pueden ver esta utilización de auto como una simple conveniencia que no mejora la calidad del código. Sin embargo, incluso en estos casos tan sencillos, la deducción automática de tipos aporta ventajas.
Por una parte, permite expresar claramente la intención del desarrollador. Es decir, la variable i debe tener el mismo tipo que el valor devuelto por la función miembro length(). Por otra parte, este estilo permite evitar errores derivados de la conversión automática de tipos. Veamos:

  string s = "Daniel";
  for (short i=s.length();i>0;--i) {
    cout << s[i-1];
  }
  cout << endl;

¿Qué ocurre si el valor devuelto por length() no cabe en un short? Ciertamente, es una situación que puede calificarse como mínimo de desagradable.

Pero cuando auto se vuelve realmente útil es en la escritura de código genérico. En C++03, se hacía necesario recurrir a código innecesariamente largo para escribir una función que imprimiese los elementos de un contenedor.

template <typename C>
void imprime(const C & c) {
  for (typename C::const_iterator i=c.begin(), e=c.end();i!=e;++i) {
    cout << *i << endl;
  }
}

Con C++11 uno no se tiene que volver a preguntar si el tipo concreto del iterador tiene que ser iterator o const_iterator y tampoco hace falta cualificar el tipo con typename para indicar al compilador de que realmente se trata de un tipo dependiente.

template <typename C>
void imprime(const C & c) {
  for (auto i=c.begin(), e=c.end();i!=e;++i) {
    cout << *i << endl;
  }
}

Más sobre la deducción de tipos

Una pregunta que conviene hacerse sobre la deducción de tipos es qué ocurre con las referencias. Es decir:

int x = 3;
int & z = x;
auto t = z;  // ¿int o int&?

Es decir, si una variable declarada como auto si inicia con otra variable de tipo referencia ¿qué tipo se deduce? La respuesta se obtiene, una vez que se observa que lo que se utiliza como iniciador (en nuestro caso z) expresión y por tanto su tipo es int.

¿Y si se desea que t sea una referencia? La solución es simple, puesto que se puede combinar auto con cualquier otro especificador de declaraciones:

int x = 3;
int & z = x;
auto&  t = z;  // int&
const auto u = x; // const int
auto *p = &x;

Otros usos de la deducción automática de tipos

Probablemente, un caso más sorprendente (aunque no debería) es la deducción automática de tipos en expresiones asociadas al operador new.

auto p = new auto(1.5); // p es un double*

Además, se puede usar la deducción automática de tipos con variables miembro estáticas que se inician dentro de la definición de una clase.

class X {
public:
  static const auto n = 3;
};

En resumen

C++11 introduce un mecanismo que permite que el compilador pueda deducir el tipo de una variable a partir de la expresión con la que ésta se inicia. Este mecanismo simplifica la escritura de código genérico. Como complemento, el mecanismo permite que evitar errores comunes de programación derivados de conversiones implícitas no deseadas.

Próximamente comentaré dos características del lenguaje que están íntimamente relacionadas con esta: la deducción automática de tipos de retorno en funciones y la obtención del tipo de un objeto.

Nuevas bibliotecas estándar para C++

Cuando digieras las 1400 páginas que tiene el nuevo estándar de C++, comprobarás que una parte bastante importante de la norma la constituye una renovada biblioteca de clases. No obstante, es probable que todavía pienses que faltan cosas.

Bien, las buenas noticias son que se abre la puerta para nuevas propuestas de bibliotecas. El comité ha decidido animar a que se presenten propuestas para una futura extensión de la biblioteca estándar.

Esta es la resolución del comité:

The C++ committee Library Working Group welcomes proposals for library extensions which will be considered starting in the February 2012 meeting. We have not yet set out an overall timeline for future library extensions, but are ready to consider new proposals at this point.

To increase the chances of your proposal being accepted by the committee, we strongly recommend that a committee member willing to champion your proposal (this could be you yourself, or a delegate) attend upcoming meetings to help shepherd your proposal through the process.

La preparación de una propuesta de biblioteca para normalizar debe considerar múltiples aspectos que van desde la utilidad general del componente hasta la implementabilidad en las diversas plataformas usadas y la capacidad de ser expresadas de forma portable.

Como comentaba en mi anterior post, ya tenemos diversas propuestas encima de la mesa, pero si tienes una propuesta interesante este es el momento.

Estándar C++. Reunión de Bloomington

Hoy hemos terminado la reunión del JTC1/SC22/WG21 (comité de C++ para los amigos). La reunión comenzó con la noticia de que el nuevo estándar ha sido oficialmente aprobado de forma unánime por los países con derecho a voto, como adelantaba en mi anterior post. De hecho, hemos tenido confirmación de ISO de que se van a acelerar los trámites de la publicación oficial del documento, por lo que con casi toda seguridad podemos hablar de C++11 (ISO/IEC 14882:2011) y no de C++ 2012.

Una buena parte de la reunión ha estado dedicada a la resolución de issues tanto de la biblioteca como del propio lenguaje. Si. El estándar se acaba de publicar, pero el comité es consciente de que el documento tiene algunos errores e inconsistencias menores que habrá que resolver. En la resolución de estos defectos se ha avanzado bastante, pero no se ha votado ninguno de ellos. Esto hace prever que la próxima reunión en Marzo de 2012 tendremos una buena lista que aprobar.

Además de esto, dentro del grupo de trabajo de biblioteca hemos visto versiones preliminares de algunas propuestas que podrían añadirse:

• Sistema de ficheros. Es biblioteca te permitirá olvidarte del API C/POSIX para navegar por directorios, entro otras cosas.
• Cerrojos compartidos. Básicamente son algunos tipos más de mutex, que no se añadieron al estándar para no retrasarlo más. Estos cerrojos (con nombres tentativos de shared_mutex y upgrade_mutex) son especialmente apropiados para soportar problemas del tipo múltiples lectores/único escritor.
• Nuevos algoritmos para la generación de distintos tipos de permutaciones y combinaciones que generalizan el existente next_permutation.
• Entrada salida para tipos que representan duraciones de tiempo (espacio de nombres chrono). De esta manera se podrán imprimir mensajes que en el caso de duraciones se incluya de forma automática la unidad en la que se expresa la duración.
• Un nuevo tipo para representar fechas (también  a incluir en el espacio de nombres chrono).

Otro aspecto bastante relevante ha sido la discusión sobre el futuro del lenguaje. Aunque el comité no ha cerrado decisiones al respecto, parece que los más probable será que se trabaje por una parte un modificaciones al lenguaje y por otra parte en la extensión de la biblioteca estándar. Estos trabajos se podrán realizar de forma independiente de forma que se hagan públicos con ritmos de trabajo diferentes.

En el caso de la biblioteca, el comité hará publica una petición de propuestas de nuevas bibliotecas en breve. Así que si tienes una buena idea para alguna biblioteca que te gustaría ver en el futuro como parte del estándar, este parece un buen momento.

Nuestra próxima reunión será en Kona, Hawaii en febrero de 2012. Probablemente, en esa reunión dediquemos una parte del tiempo a definir la evolución del lenguaje. En cualquier caso y con toda seguridad dedicaremos tiempo a estudiar propuestas de modificaciones y adiciones a la biblioteca (entre mis favoritos estarán propuestas para mejorar la concurrencia y las comunicaciones a través de red).

Y eso es todo por ahora.

FDIS de C++ aprobado

Por fin ha finalizado el periodo de voto del FDIS del nuevo estándar de C++ (C++0x para los amigos).

El estándar ha sido aprobado con los votos favorables de: Canadá, China, República Checa, Dinamarca, Finlandia, Francia, Alemania, Irlanda, Italia, Japón, Kenya, Corea, Holanda, Nigeria, Noruega, Pakistán, Federación Rusa, España, Suiza, Ucrania, Reino Unido y Estados Unidos.

No ha habido ningún voto en contra.

Ciertamente para la comunidad de C++ es una gran noticia. Después de más de una década por fin tenemos una nueva norma del lenguaje. Sin duda, esto va a revitalizar mucho el lenguaje con nuevas características largamente esperadas y una biblioteca más completa.

Y desde hoy, empezamos a trabajar en el nuevo estándar. Bueno, realmente desde este próximo lunes 15 de agosto que es cuando nos reuniremos en Bloomington, Indiana.

Evidentemente, la norma es perfecta y seguro que encontraremos defectos y posibles mejoras. Si encuentras algo, no dudes en hacérmelo llegar por correo electrónico.

Pero por ahora disfrutemos de la nueva versión del lenguaje...

La informática en Educación Secundaria

Esta mañana he leído un interesante artículo en IEEE Computer con el título "Transforming Computer Science Education in High Schools" (http://dx.doi.org/10.1109/MC.2011.191). La verdad es que el debate sobre la necesidad de formación en IT (a.k.a Tecnologías Informáticas) me parece pertinente. Especialmente teniendo en cuenta las previsibles necesidades en profesionales del sector en todas partes.

Hace unos días leía un informe que constata que en Europa las necesidades de profesionales altamente cualificados en Tecnologías Informáticas no son cubiertas ni de lejos por la oferta. Según el mencionado informe, en 2015 Europa tendrá un déficit de entre 384,000 y 669,000 profesionales que las universidades europeas no habrán sido capaces de haber formado. El informe enfatiza que la conclusión es que la industria necesita de forma desesperada profesionales altamente cualificados en IT y Europa necesita que más jóvenes se conviertan en profesionales de IT para satisfacer los futuros incrementos de la demanda"

La situación en USA no es distinta. Las proyecciones a día de hoy son que el incremento de puestos de trabajo en IT es tan fuerte que supera al resto de disciplinas STEM (Science, Technology, Engineering and Mathematics) de forma conjunta. Sin embargo, el porcentaje de estudiantes norteamericanos que siguen un curso de informática en secundaria ha descendido un 8% entre 2007 y 2009.

La pregunta del millón es ¿Qué está pasando? y ¿Es trasladable a la situación de España?

Lo primero que se identifica es que mientras que disciplinas clásicas como la matemática o la física son enseñadas de forma rigurosa y por profesionales altamente cualificados. La situación de la informática, cuando se enseña es radicalmente distinta.

Veamos el diagnóstico en USA y los posibles paralelismos en España.

En 41 estados la informática es una materia accesoria que no está clasificada como las matemáticas o la física y que no tiene impacto en los criterios de graduación de la educación secundaria. Curiosamente esta situación es equivalente a la situación española, donde la informática es una asignatura optativa que muchos estudiantes no escogen porque no pueden examinarse de ella en las pruebas de acceso a la selectividad.

La materia de informática suele incluir el uso básico del computador y la utilización de paquetes básicos de software. En España la asignatura de Tecnología de la Información (optativa de bachillerato) se limite también al uso básico del computador y al uso de paquetes ofimáticos.

Otro problema de la enseñanza preuniversitaria de la informática en España es la cualificación de los docentes. Si bien existen unas oposiciones específicas para ser profesor de matemáticas o de física, esto no es así para informática.

En un momento en el que recurrentemente se habla la necesidad de cambiar el modelo productivo de España se está olvidando la formación en una de las disciplinas que puede ser motor de ese cambio. Para alcanzar ese cambio de formación sería interesante seguir muy de cerca iniciativas de reformulación del currículum de informática, como por ejemplo la iniciativa Computer Science Principles, que está definiendo un nuevo curso orientado tanto a estudiantes con intereses en la Ingeniería Informática como a aquellos que tienen intereses más generales en ciencia, ingeniería y humanidades.

Si hiciésemos con la Física de Bachillerato lo que estamos haciendo con la Informática, deberíamos dejar de enseñar las ecuaciones de Newton y en su lugar enseñar a conducir coches. Esto es lo que estamos haciendo hoy día con la informática.

Los 6 trabajos con más potencial en Tecnología Informática (IT)

Leo la siguiente noticia en cio.com:

http://www.cio.com/article/684344/The_6_Hottest_New_Jobs_in_IT?source=CIONLE_nlt_careers_2011-06-21

Parece que los 6 trabajos con más potencial en TI (Tecnología Informática):

• Business Architect.
• Data Scientist.
• Social Media Architect.
• Mobile Tecnology Expert.
• Enterprise Mobile Developer.
• Cloud Architect

Interesante.

Por otra parte el 65% de los ejecutivos encuestados dicen que contratará más personal en el segundo semestre de 2011 que en el primero.

Tenemos nuevo estándar de C++

Si os digo que esta semana se ha celebrado en Madrid la reunión del comité ISO/IEC JTC1/SC22/WG21 y que se a aprobado el FDIS de la norma ISO/IEC 14882:2011, probablemente me diréis que lo que quiero es que no entendáis nada de lo que digo. Y tendríais razón. Así que lo diremos de otra forma.

Esta semana se ha reunido en Madrid el comité internacional de normalización del lenguaje C++. Algunos sabéis que represento a España en este comité. Y bueno la gran noticia es que hemos acordado una nueva norma para el lenguaje y su biblioteca estándar. Realmente los procedimientos de ISO harán que la nueva norma no sea oficial hasta el verano (más o menos).

Estoy muy contento por varias razones.

Por una parte, el estándar se a aprobado en Madrid, así que permitidme una ligera dosis de chovinismo. Además, la norma incluyen algunas propuesta menores que yo hice, así que permitidme otra dosis de egolatría.

Siendo un poco más serios, creo que el lenguaje se va a ver sensiblemente reforzado. Ha pasado demasiado tiempo desde la anterior norma (la ISO 14882:1998) que tuvo posteriormente una revisión menor en el año 2003.

Cada vez que doy una charla o conferencia sobre esta renovación siempre que hay alguien que me pregunta sobre su aspecto más destacable. He ido dando una respuesta distinta a lo largo de los últimos años, al tiempo que las características aparecían y desaparecían del lenguaje. A día de hoy, creo que el lenguaje se ha renovado de forma sustancial y que ahora se disponer de una biblioteca mejor y más completa.

Es difícil hacer una enumeración de las distintas novedades en el lenguaje y en la biblioteca. Y además esto está bien hecho en algunas páginas Web. Por ejemplo se puede encontrar una buena explicación de la mayoría de los cambios en la página Web de Bjarne Stroustrup (http://www2.research.att.com/~bs/C++0xFAQ.html).

Desde mi punto de vista, y posiblemente esto sea una visión sesgada, una de las novedades más relevantes es la incorporación de un modelo de hilos como parte del lenguaje. Esto afecta, tanto a las reglas del lenguaje como a la biblioteca, pero permitirá que se puedan escribir aplicaciones multi-hilo de forma portable e independiente de la plataforma (hw y sistema operativo).

A partir de ahora surgirán dos retos importantes:

• En primer lugar, va a ser necesario realizar un importante esfuerzo de diseminación de la información. Ya están varios libros en marcha. Serán necesarios nuevos materiales de formación y la adaptación de cursos.
• Por otra parte, será necesario seguir trabajando en la siguiente renovación del lenguajes que debería concluirse con mayor celeridad que la actual. Las estrategias para esta nueva versión la discutiremos en la siguiente reunión del comité que tendrá lugar este verano en Bloomington, Indiana.

Como siempre las posiciones de España se fijarán en el comité español de C++. Este es el comité CTN71/GT21 en el que siempre estamos deseosos de incorporar a nuevas empresas y organismos.

Para más información, me podéis encontrar en josedaniel.garcia@uc3m.es.

Lo que significa la Universidad Pública en España

Cursé mis estudios universitarios entre los años 87 y 93. Fui la primera persona de mi familia en ir a la Universidad. Mi padre era empleado de banca. Mis abuelos fueron cantero y conductor de autobuses, respectivamente. Si yo pude ir a la Universidad fue gracias a la generalización de la Universidad pública que se produjo en los 80.

Por eso, me entristece ver cómo con cierta frecuencia aparecen mentes clarividentes que enarbolando la bandera de la liberalización proponen medidas que me repugnan.

Leo hoy en la edición digital de El País que Mas-Collell quiere liberalizar los costes de los estudios de postgrado. Leyendo la noticia, descubro que lo que realmente quiere es liberalizar el precio que el estudiante deba pagar por los estudios de postgrado. Lo siento, pero no puedo estar de acuerdo ni de lejos. No tengo ningún problema con que una institución privada defina la política de precios que considere adecuada. Ahora bien, las Universidades públicas son financiadas por todos para cumplir varias funciones que redundan en beneficio de la sociedad en su conjunto. Una de estas funciones, es garantizar, en la medida de lo posible, que cualquier español tenga acceso a los estudios universitarios independientemente de su nivel de renta.

Si los fondos públicos son insufucientes deberíamos pensar en formar a menos estudiantes, pero siguiendo el criterio de formar a los más capaces y no a los que tienen más recursos económico.

La reciente reestructuración de los estudios universitarios en Grado y Máster ya ha supuesto un cambio en las cantidades que un estudiante tiene que abonar. Tradicionalmente un estudiante de una licenciatura o una ingeniería tenía que abonar un precio anual que rondaba los 1000 euros anuales. Con la reorganización que trajo Bolonia esto se mantiene para los primeros años. Sin embargo, Bolonia hace mucho más importante que un estudiante complete sus estudios con un postgrado. Y los precios públicos para cursar un Máster (de entre 1 y 2 años) rondan los 1800 euros por año. Subir más (o dejar barra libre) en los precios de que debe pagar un estudiante es una manera de formar mejor solamente a los que más tienen.

Otro día, hablaré de la otra propuesta del Sr. Mas-Collell, la del control político de las Universidades sustituyendo la elección del rector por un nombramiento a dedo.

La Clasificación Nacional de Ocupaciones, CNO-11 ignora a la Ingeniería Informática

Si como lo oyes. En un alucinante comportamiento del INE no clasifican mi profesión con nombre y apellidos. Es decir, en la clasificación de ocupaciones aparecen ocupaciones como Ingeniero de Telecomunicación, Físico, o Estadístico, pero no Ingeniero Informático.

¿Puedes hacer algo? Si que puedes. Presenta una queja por escrito.

¿Cómo? En el siguiente enlace tienes el texto para hacer copy/paste y los lugares donde puedes hacerlo. No te llevará más de cinco minutos.

http://blog.conciti.org/2011/01/19/plan-de-actuacion-del-conciti-por-la-no-aparicion-en-la-clasificacion-nacional-de-ocupaciones-cno-11/

¿Puedes hacer algo más? Si, pasa esta información a todos los compañeros de profesión.

La ley Sinde

Me gusta más hablar de tecnología que de política ...

Sin embargo, esta mañana escuchaba los argumentos de la ministra Sinde en defensa de la controvertida nueva ley.

La verdad es que me ha hecho reflexionar. No voy a entrar en valorar el detalle de la ley, pero el argumentario básico es que la ley debe defender a los creadores. Y yo me pregunto, ¿cómo se puede estar a favor de esto y al mismo tiempo en contra de las patentes software?

Sinceramente yo no lo entiendo.

La paradoja del profesionalismo

Le en el último artículo de David L. Parnas en el Communications del ACM:

Until customers demand evidence that the designers were qualified and disciplined they will continue to get sloppy software.

As long as there is no better software, we will buy sloppy software.

As long a s we buy sloppy software, developers will continue to use undisciplined development methods.

As long as we fail to demand that developers use disciplined methods, we run the risk - certainty - that we will continue to encounter software full o bugs.

¿Y como salimos de este bucle?

Admitido a trámite el recurso contencioso administrativo interpuesto contra el Real Decreto 1837/2008 de reconocimiento de cualificaciones profesionales

http://www.coitimur.org/2010/10/31/admitido-a-tramite-el-recurso-contencioso-administrativo-interpuesto-contra-el-real-decreto-18372008/

Bueno. Es un paso más en la defensa de la profesión.

Una vez más enhorabuena a todos los que están trabajando por defender una profesión tan necesaria para nuestra sociedad.