La pregunta es: ¿se puede dar la paradoja de que con chips más potentes tengamos ordenadores más lentos?. La respuesta es que, no es que se pueda dar, es que se está dando ya.

Hace ya unas semanas que tenía ganas de escribir sobre este tema desde que lo leí en el Fortune del 8 de septiembre (lo sé, me suscribo a cosas "muy raras"), pero como podéis comprobar si véis las fechas de mis últimos post, cada vez me resulta más complicado escribir algo con todo lo que tengo encima.

En fin, volviendo al tema, el caso es que la dinámica del sector hasta hace unos pocos años fué siempre la misma: los fabricantes de hardware hacían CPUs más rápidas y los fabricantes de software (entiéndase, de sistemas operativos) hacían sistemas más potentes también (lo cual no siempre se traduce en mayor rapidez, no hay que confundir). Así se cumplía la ley de Moore y todos tan contentos.

El problema es que llega un punto en que exprimir los ciclos del procesador para darles más velocidad no es viable, bien económicamente, bien por eficiencia energética, por lo que las últimas generaciones de CPUs de hecho corren a frecuencias de reloj menores que las que había hace tres o cuatro años. Es por eso que lo habitual ahora es que ni siquiera te indiquen la velocidad de reloj de las CPUs. Lo que se ha hecho para poder seguir progresando en potencia es algo más "fácil" para los geniecillos del hardware (ojo con el entrecomillado, es para entendernos) que para los del software: los procesadores multicore. En lugar de poner más velocidad ponemos dos procesadores o más en uno sólo. Es parecido a tener sistemas multiprocesador pero en un sólo chip. Hoy en día es casi seguro que tu ordenador de sobremesa o portátil tiene un doble núcleo. En nuestra oficina en Krasis, por ejemplo, el nuevo servidor de dominio (bastante normalito) tiene dos procesadores de cuatro núcleos, es decir, como si fueran ocho procesadores.

Lo que ocurre es que esta tecnología es tan diferente de la anterior que los que trabajan en software a bajo nivel "rillan" (como se dice en mi tierra gallega, que no es "dar grima" como en Canarias, sino "desesperarse intentando resolver un problema" o "hacer algo que cuesta demasiado esfuerzo", entre otras cosas). Según Craig Mundie, el jefe de estrategia e investigación de Microsoft, "es el cambio debido a "conceptos diferentes" más importante de la historia moderna de la computación". ¿Exagerado?. Bueno, Sean Maloney de Intel reconoce que "se trata de un gran problema", y otros van más allá y dicen que es una verdadera crisis.

La informática masivamente paralela lleva siendo una realidad desde hace muchos años en entornos científicos (para simulaciones que conllevan complejísimos cálculos), pero se trata normalmente de entornos muy cerrados y especializados, no de propósito general y con sistemas con lo mínimo para correr ese tipo de aplicaciones. Ahora la guerra es diferente pues estamos hablando de sistemas que deben funcionar con miles de propósitos diferentes y en entornos no controlados. Al parecer, desarrollar con eficiencia para esto es tan endemoniadamente complicado que hoy en día hay no personal cualificado suficiente para poder desarrollar una industria sobre estos chips. Los propios fabricantes de CPUs como Intel reconociendo el problema está contratando programadores en masa para intentar aportar soluciones desde su parte también.

La industria de los videojuegos ha vivido una crisis parecida hace unos años, a principios de la década, cuando Sony empezó a incorporar diferentes y múltiples chips a la Playstation 2. Los creadores de juegos "rillaron" intentando ponerse al día y lograr sacar juegos que al final llevaban enormes retrasos (y por lo tantos pérdidas millonarias). Incluso hubo empresas que directamente dejaron de producir juegos por no ser capaz de adaptarlos a la nueva realidad hardware.

Pues algo similar e incluso peor está pasando hoy en día en el mundo de los ordenadores. Se puede dar (y se da) la paradoja de que te compras un maravilloso PC con un quadcore y que algunas tareas tardan lo mismo o incluso tardan más que antes en hacerse. Si ya la programación multi-subproceso de alto nivel con lenguajes como C# o C++ es compleja, imagínate como será a esos niveles tan bajos. Por cierto, si te interesa el tema deberías echarle un vistazo al lenguaje experimental C Omega que extiende a C# para paralelismo.

¿Y tú qué opinas de esto? ¿Comentarios? ¿Ideas?

Recursos de interés que te sugiero:

· Artículo original completo en Fortune
· Parallel Computing en Microsoft
· Blog del equipo de Parallel Computing de Microsoft
· LINQ Paralelo: Running Queries On Multi-Core Processors
· Optimize Managed Code For Multi-Core Machines
· Curso de programación multihilo con .NET de campusMVP

La semana pasada hemos lanzado desde Krasis Press el primer libro que se publica en el mundo, en cualquier lengua, sobre la nueva y esperada tecnología de acceso a datos de Microsoft: Entity Framework.

¡Y qué libro! La verdad es que ha quedado una obra alucinante, escrita por tres cracks de este tema que llevan trabajando con las betas de esta tecnología, y en proyectos reales, desde hace muchos meses. Unai Zorrilla, Octavio Hernández y Eduardo Quintás.

A Unai y a Octavio ya los conocéis porque aparte de ser conocidos articulistas y MVP, son autores de la casa y autores de los libros "Modelando procesos de negocio con Workflow foundation" y "C# 3.0 y LINQ" respectivamente.

Los primeros libros sobre el tema en inglés saldrán para finales de año o principios del que viene.

La obra consta de seis capítulos más cinco apéndices, que cubren ampliamente la gran mayoría de las características de Entity Framework:

    • El libro comienza con un capítulo de introducción a la tecnología, para luego centrarse en la creación de modelos conceptuales de entidades, que describe desde los apartados más básicos hasta las posibilidades más avanzadas por medio de ejemplos claros y prácticos.

    • Los siguientes capítulos introducen al lector en las distintas posibilidades que la tecnología ofrece para consultar y actualizar los datos de un modelo conceptual, todo ello de una forma ordenada, tal y como se fueron concibiendo los distintos subsistemas que componen Entity Framework, y explicando las ventajas e inconvenientes de cada uno de ellos.

    • Para finalizar, el último capítulo del libro ofrece una introducción a ADO.NET Data Services, una aplicación práctica de Entity Framework desarrollada por Microsoft para exponer la infraestructura que conforma esta tecnología a través de servicios REST.

Puedes descargarte el índice completo con parte del primer capítulo y los detalles de la portada y contraportada desde aquí. También puedes comprarlo desde la misma página. Los gastos de envío por mensajero van incluidos en el precio.

¡Qué lo disfrutes!

Leo en el Blog de Ángel Medinilla un resumen de un artículo de Forrester en el que se habla sobre cosas que podemos hacer desde el departamento de Tecnologías de la Información para luchar contra la crisis:

1. El outsourcing no es una “bala de plata”. Aprovecha la recesión para desarrollar las aptitudes internas.
2. Ya que vamos más lentos, aprovecha para mejorar los equipos. De hecho, aprovecha para traerte a gente buena que ha sido despedida de otros sitios.
3. Evita el “Efecto Mar Muerto”. En el Mar Muerto entra agua, pero no sale, así que la mayoría del agua pura se evapora dejando los residuos. No dejes que tu mejor gente se evapore durante una recesión.
4. Lo último en recortar debe ser el presupuesto de formación y desarrollo. Se trata de unos recursos críticos para el éxito tras la recesión.
5. Aprovecha la recesión para tomar las decisiones duras: desembarazarte de proveedores redundantes o que no rinden y de empleados cuyo rendimiento no sea adecuado.
6. Acelera la virtualización y otras medidas de eficiencia en tecnologías de la información y de negocio.
7. Redobla los esfuerzos para añadir valor. Afila las métricas del ROI, publica los éxitos en IT/BT, reconoce y premia a los mejores trabajadores, intensifica la colaboración entre la tecnología y el negocio. Usa esta época para ser más visible al Director General, no menos.
8. Contrata a los grandes MBA que se habrían ido a Wall Street en otras circunstancias
9. Pide descuentos a tus proveedores y re-negocia los contratos siempre que sea posible

Me gustan especialmente las que he dejado en negrita. Lo del "Efecto Mar Muerto" no lo conocía y me ha parecido simpático y una forma muy gráfica (y muy americana) de decirlo ;-)

Por supuesto con el punto 4 no podría estar más de acuerdo. Y yo añadiría, fuera del departamenteo de TI, que es también el momento de redoblar esfuerzos en marketing y comunicación.

Es curioso ver cómo la mayor parte de las emrpesas, en cuanto vienen momentos díficiles, lo primero que recortan son los gastos de marketing y los de formación. Craso error. Es precisamente en estas épocas duras cuando más debemos invertir en marketing para destacar sobrela competencia y conseguir llevarte más parte de una tarta que ha menguado, y es precisamente cuando debemos invertir en formación por razones obvias.

Estos días he estado intentando instalar Office 2007 en un Windows XP recién instalado. El caso es que, inexplicablemente, y aunque ejecuté el instalador como administrador, una y otra vez recibía el mensaje siguiente:

"Windows installer service cannot update one or more protected windows files."

No podía entenderlo. Jamás me había pasado. El caso es que sorprendentemente y aunque había instalado todo Windows XP prácticamente la solución consiste en añadir manualmente un archivo que no tiene el sistema. Para encontrar la solución en Internet, tela...

1. Desde el disco de instalación de Windows en su carpeta i386 busca el archivo FP40EXT.CAB y ábrela.

2. Buscaa dentro el archivito: fp4ault.dll.

3. Extráelo a la carpeta C:\Archivos de programa\Archivos comunes\microsoft shared\web server extensions\40\bin

Ahora intenta instalar de nuevo Office 2007 y verás como te funciona. Vivir para ver :-(

Lo cierto es que no sé para qué rayos quiere la instalación una DLL de Frontpage, pero espero que a alguien le ahorre mucha frustación.

Es que este tío, Javier Aguilera, es muy bueno :-)

La verdad es que esto lo sé desde hace ya tiempo pero hasta ahora no me he decidido a hacerlo público.

Tengo la suerte y el honor de ser ponente en el próximo TechEd Developers, el evento internacional para desarrolladores más importante dentro del mundo Microsoft. Y encima tengo la suerte de compartir ponencia con mi buen amigo Iván González, un crack:

Pulsa para aumentar

Nuestra ponencia se titula "ASP.NET Instrumentation and Health Monitoring" y os dejo el "abstract" de la misma para que sepáis de que va:

"It´s not everything about program functionality and functional requirements. What about post-deployment health and monitoring?. Keep your programs productive and virtually bug-free.

Develop ASP.NET applications aware of the event log, performance counters and trace listeners, keep applications under control and get ready before problems strike.

Dive into the IIS7 expanded monitoring & diagnostics capability through features like Runtime Status & Control data, Failed Request, etc...

We will see how to implement health measures in both application code (ASP.NET 3.5) and hosting (IIS 7.0) in order to ensure continuity."

Está en inglés porque la ponencia será en inglés, claro (es un evento internacional). Tendremos la suerte de compartir "cartel" con gente tan conocida como David Chappell, Steve Lasker, Michael Howard o Daniel Moth, por citar unos pocos.

La verdad es que tanto Iván como yo estamos muy contentos porque creo que se pueden contar con los dedos de la mano los españoles que han tenido la oportunidad de ser ponentes en TechEd. Además este año estamos que nos salimos los españoles, porque aparte de Iván y yo también será ponente Miguel Jiménez y nuestro ponente más internacional y autor del libro de Windows Communication Foundation de Krasis Press, Hadi Hariri.

¡Deseadnos suerte!

Y por supuesto, si estás por Barcelona la semana del 10 de noviembre a ver si te vemos por allí :-)

En mi anterior post os hablaba sobre la forma de poder utilizar varios certificados SSL en un mismo servidor y las posibilidades y limitaciones técnicas que existían.

Un certificado de servidor para SSL suele ser un producto caro. El precio en una entidad certificadora decente van desde unos pocos cientos a más de 1.000 euros, dependiente del tipo de certificado. Además es un proceso tedioso ya que hay que demostrar fehacientemente que somos quiénes decimos ser (que es de lo que va todo esto realmente, claro), lo que implica envío de papeles para su verficación, llamadas, faxes, etc... Conviene seleccionar una entidad certificadora conocida ya que de este modo su certificado raíz, que la verifica a ella primeramente, estará ya instalada en nuestro equipo, cosa que no ocurre con otras menos comunes (y supone una barrera comercial importante para éstas últimas). Todo el sistema de infraestructura de clave pública (PKI) se sustenta en esas relaciones de confianza jerarquizadas.

El objetivo de un certificado digital de servidor (para SSL) es triple ya que pretende lo siguiente:

1.- Autenticación del servidor: sirve para constatar ante los usuarios, de forma fiable, que el servidor al que se están conectando es quién dice ser y que por lo tanto nos estamos conectando de verdad a nuestro banco o servicio on-line.

2.- Cifrado de comunicaciones: la clave pública del servidor se utiliza para cifrar las comunicaciones iniciales, en las que se acuerdan el método de cifrado simétrico y la clave de cifrado que se utilizarán para cifrar todas las comunicaciones posteriores. Eso asegura la confidencialidad de las comunicaciones entre cliente y servidor, y es uno de los motivos por los que no se pueden simultanear certificados como hemos visto en el post anterior, ya que hasta la URL que se solicita viaja cifrada.

3.- No repudio de las comunicaciones realizadas por parte del servidor.

Cuando estamos desarrollando una aplicación y la queremos probar con SSL, o bien cuando sólo queremos el certificado SSL para un uso restringido (por ejemplo para nuestros dos o tres usuarios móviles que se quieren conectar cuando están fuera de la oficina), quizá el coste de un certificado real no está justificado. Para generar un certificado propio podemos poner en marcha nuestra propia infraestructura PKI, para lo cual Windows Server viene preparad. Aunque nos resultará fácil montar una PKI propia puede que no esté justificado todo el trabajo que conlleva para genrar uno o dos certificados.

Para permitir a los desarrolladores el uso de certificados SSL sin tener que comprarlos o generarlos con una PKI propia, en el interesante Kit de Recursos de Windows Server 2003 que ya hemos mencionado en el anterior post, se incluye una pequeña utilidad de línea de comandos que te va a encantar. Se trata de SelfSSL.exe.

Este ejecutable nos permite generar para cualquier servidor virtual de IIS un certificado digital SSL que está firmado por nosotros mismos. Lo genera y además lo instala y deja listo para su uso. La utilización de SelfSSL es muy sencilla:

Así, para generar un certificado SSL para un servidor virtual que tenga una validez de un año y que valide al dominio zonasegura.midominio.com tendría que escribir algo como esto:

selfssl /T /N:CN=zonasegura.midominio.com /V:365 /S:1669802537

El valor para el parámetro /S es el identificador d enuestro servidor virtual y, como hemos visto, lo sacamos con la utilidad IIS Metabase Explorer. Además he añadido el parámetro /T para que el certificado generado se instale en la lista de certificados de confianza del navegador local. De este modo en el servidor de pruebas no recibiremos advertencias sobre que el origen del certificado no se puede validar.

Y es que este es el mayor inconveniente de estos certificados: al acceder mediante SSL a los sitios protegidos con ellos recibiremos una advertencia de seguridad delnavegador, ya que el certificado no está emitido por una entidad de confianza reconocida. Esto es lógico sino el uso de certificados "de verdad" carecería de sentido, pues se perdería su objetivo principal que es la confianza, y pervertiríamos el concepto subyacente a las PKI.

No obstante, incluso en estas condiciones y aparte de su uso para pruebas y desarrollo, este tipo de certificados auto-firmados pueden ser muy útiles, ya que nos permiten conseguir el objetivo 2, es decir, el cifrado de las comunicaciones. Si por ejemplo tenemos algún trabajador que esporádicamente está de viaje y se quiere conectar al webmail o a una aplicación desde una red pública (un WiFi en una cafetería o centro comercial, por ejemplo) podemos utilizar uno de estos certificados para cifrar las comunicaciones y que las claves no viajen en claro y puedan ser interceptadas. No nos valida el servidor pero tampoco tenemos esto si nos conetcamos de forma "normal", por HTTP, y sería muy raro que alguien intentara suplantar justo a nuestro webmail usando envenanimiento de DNS en un centro comercial para engañar a un comercial nuestro y robarle las credenciales ¿no? ;-)

Es decir, ni se te ocurra usar esto para una aplicación de verdad ni para algo a lo que deban acceder muchos usuarios, pero para pruebas y para conexiones esporádicas a sistemas no críticos nos permitirá ahorrarnos un dinero y conseguir al menos el cifrado de datos en las conexiones, lo que no es poco.

Espero que te sirva :-)

El título es así de largo proque realmente trato varios temas que están relacionados yq ue a muchos programadores Web les pueden a resultar útiles.

Primeramente, pregunta típica: ¿puedo utilizar varios certificados SSL (Secure Sockets Layer) en un mismo servidor Internet Information Server (IIS)?

Respuesta: Sí y No.

Un servidor IIS 6.0 permite por defecto asignar varios certificados a servidores virtuales diferentes siempre y cuando éstos funcionen cada uno en un puerto distinto. Así, si usamos en alguno un puerto no estándar (distinto al 443), pues entonces sí nos deja, pero vamos, esto dista bastante de ser una buena solución. También nospermite tener dos certificados en dos servidores virtuales diferentes si cada uno de ellos utiliza una IP distinta. Tampoco es muy útil.

Si vamos al diálogo "Avanzadas" de la pestaña general de propiedades de un sitio Web de IIS, veremos que aunque en peticiones sin encriptar nos permite definir tantos encabezados de host como queramos en la misma IP y mismo puerto para así distinguir unas peticiones de otras, en el caso de SSL sólo nos deja indicar una IP y un puerto, sin posibilidad de distinguir encabezados de host:

Por este motivo, si en dos sitios Web utilizan la misma IP y el puerto estándar 443 y les asociamos un certificado de servidor para que cifren las ocmunicaciones con SSL, en cuanto lo hagamos con el segundo éste se nos parará. No nos dejará arrancarlo de nuevo porque nos dice que no puede haber dos servidores escuchando en el mismo puerto.

Si tuviésemos la posibilidad de distinguir las peticiones SSL por encabezado de host, como pasa en peticiones normales sin encriptar, entonces ya estaría el tema solucionado. El problema es que, por definición, la información viaja encriptada (incluyendo la petición y el encabezado de host) por lo que IIS no tiene manera de determinar ese encabezado de host hasta que lo desencripta en el servidor con el certificado adecuado. Es decir, que si antes no sabe qué certificado utilizar entonces no puede determinar el encabezado de host que tiene la petición, y viceversa. Es un típico problema recursivo que crea esta limitación. Antes de que algún anti-MS salte a la yugular diré, por si no está suficientemente claro aún con la explicación, que se trata de una limitación de SSL no de IIS. Le pasa a todos los servidores web.

Entonces ¿cómo solucionamos el asunto?

Bueno, la conclusión es que sólo podremos distinguir entre unas peticiones y otras si usamos para todas ellas el mismo certificado. Pero por definición cada sitio web (con un dominio distinto) tiene que tener un certificado diferente, o entonces podríamos desencriptar pero fallaría la autenticaicón del servidor pues no se correspondería con el dominio (¿me explico?). Por lo tanto la única solución es que todos esos dominios que queremos proteger deben tener el mismo dominio o subdominio principal, y debemos asignar al servidor un certificado comodín, es decir, uno que sirva para proteger un dominio y todos sus subdominios.

Así, podremos proteger con un mismo certificado comodín por ejemplo a los dominios: shop.campusmvp.com, www.campusmvp.com y aulas.campusmvp.com, o cualesquiera otros que compartan un mismo sufijo en el dominio. El certificado que usemos debe certificar al dominio comodín: *.campusmvp.com.

Estos certificados comodín los tenemos que pedir expresamente a nuestro proveedor de certificados (Thawte, verisign, Camaras.org o quien sea). Generalmente son bastante más caros que los normales puesto que, realmente, les estás fastidiando el negocio porque con un solo certificado proteges varios dominios, así que se aseguran unas ganacias penalizándote el precio.

Si tienes que proteger varios dominios distintos no te quedará más remedio que asignarle una IP diferente a cada uno. Efectos secundarios de la seguridad ;-)

Asignación de encabezados de host a cada subdominio

Vale. supongamos entonces que quieresproteger varios subdominios con un certificado comodín. Según he dicho antes no vamos a poder de todos modos establecer el encabezado de host porque la herramienta de administración de IIS no nos lo permite. Entonces ¿cómo lo hacemos?

El proceso es el siguiente. Instalas el certificado en el primero de los dominios y le asignas el puerto 443 a la IP que le corresponda. Ahora debes usar una herramienta de script administrativo de IIS para establecer el encabezado. Abres una línea de comandos, vas hasta la carpeta de scipts administrativos (por defecto C:\InetPub\AdminScripts) y escribes lo siguiente:

cscript.exe adsutil.vbs set /w3svc/<ID del servidor virtual>/SecureBindings ":443:subdominio.dominio.com"

Por ejemplo:

cscript.exe adsutil.vbs set /w3svc/1669802537/SecureBindings ":443:mcs.krasis.es"

Vale. Primera dificultad: hay que averiguar cuál es el identificador de nuestro servidor virtual :-?

Para ello tienes que irte a la metabase de IIS y buscarlo entre todo ese infernal XML :-( Así que mucho mejor vamos a usar una herramienta que lo haga por nosotros. Si te descargas el Resource Kit de IIS 6.0, dentro del mismo hay una herramienta llamada IIS Metabase Explorer que te permite hacer lo que su nombre indica: bucear en la metabase sin tener que lidiar directamente con ella. Instálala y podrás averiguar fácilmente el identificador de tu servidor virtual viéndolo en el nodo correspondiente de la rama LM\W3SVC, como en esta figura:

Pulsa para aumentar

Con esto es coser y cantar pues sólo tienes que copiar el "numerito" y ya podrás asignarle el certificado al subdominio (o subdominios) que necesites.

Ahora sólo resta repetir la misma operación en el resto de subdominios/servidores virtuales y listo.

Espero que esto le resulte útil a mucha gente.

En el próximo post voy a comentar algo muy interesante relacionado con este tema: cómo crear y asignar automáticamente certificados SSL a nuestros dominios creados y firmados por nosotros mismos para pruebas o para uso privado. Y lo mejor: sin tener que instalar ningún tipo de infraestructura PKI (Infraestructura de clave pública) y con un simple programita de línea de comandos :-)

Las páginas ASPX funcionan mediante la inclusión de un formulario único que contiene todo los controles de la página y que, al enviarlo, actualiza ciertos parámetros para mantener el ViewState, saber qué control ha provocado un evento, etc... El funcionamiento basado en un formulario provoca algunos comportamientos indeseados.

Por ejemplo, los cuadros de texto, por defecto, cuando tienen el foco (porque estás escribiendo en ellos) provocan el envío automático del formulario si pulsas ENTER. Si tienes el típico cuadro de búsqueda con un botón o un formulario de recogida de datos con un botón de enviar, al pulsar ENTER conseguirás que se envíe la página pero al no haber pulsado sobre el botón no se detectará el evento correspondiente y por lo tanto no se ejecutará el código del eento click de éste. El resultado es que no se actualiza correctamente la página y simplemente volvemos a tener la misma página exactamente igual y la búsqueda no funciona o los datos no se almacenan.

Seguro que te ha pasado muchas veces al visitar aplicaciones hechas con ASP.NET. De hecho es una de las típicas preguntas que le surgen a todo el mundo: ¿cómo evito esto?

En ASP.NET 1.x tenías que capturar con JavaScript el evento de pulsación de la tecla y actuar en consecuencia. Por suerte desdela versión 2.0 de ASP.NET (y posteriores), tenemos una propiedad estupenda que se puede ajustar en el formulario de la página llamada DefaultButton y que sirve precisamente para evitar este problema.

Así, si ponemos esto:

<form id="Form1" runat="server" defaultbutton="cmdBuscar">

conseguiremos que alel hecho de pulsar ENTER y provocar un envío del formulario, en realidad será equivalente a pulsar el botón indicado. De este modo se evita el problema por completo y podemos procesar correctamente el evento :-)

Por cierto, en la versión 2.0 también apareció una propiedad del formulario relacionada en cierto modo con esta y útil para no tener que scribir un sencillo script por nuestra parte: DefaultFocus. Como se puede esperar esta propiedad nos permite indicar qué control de los disponibles en nuestra página va a tener el foco al cargar la página (generalmente un cuadro de texto).

¡Espero que os sea útil!