Pase lo que pase, los desarrolladores tienen la llave del futuro

Ayer escribí un artículo en mi otro blog no-técnico que realmente tiene mucho que ver también con este blog y con los programadores. Como creo que a muchos de los que leen este blog técnico les puede interesar, ya que realmente trata temas importantes sobre tendencias y futuro de las plataformas y de Internet. Si eres un programador debes estar al tanto de estas tendencias.


El artículo es bastante largo por lo que resumo a continuación algunas ideas clave:



  • Los fabricantes de sistemas operativos móviles (Apple, Microsoft, Blackberry, Android..) se están peleando encarnizadamente por conseguir desarrolladores para sus plataformas.
  • Es indudable que el futuro de Internet pasa en gran medida por los dispositivos móviles, entendidos como algo más que los teléfonos. Internet cada vez está más imbricado en nuestra vida y no querremos prescindir de él en ningún momento.
  • Apple ha llevado hasta ahora la iniciativa con sus iPhone/iPad, pero los demás se están poniendo las pilas.
  • El éxito de cualquier plataforma siempre ha dependido de la cantidad de aplicaciones útiles existentes para la misma. Se analizan algunos ejemplos conocidos.
  • Los fabricantes en cierto modo se están aprovechando de los desarrolladores ofreciéndoles una zanahoria (los ingresos por ventas en las Apps Stores de turno), cuando en realidad lo que hacen es utilizarlos para captar masa crítica de aplicaciones.
  • El modelo de negocio en Internet está cambiando, y la movilidad está ayudando a ello.
  • Los operadores son los que probablemente lo pasen peor en el futuro, ya que han perdido su oportunidad de oro.

iPhoneZanahoria


Reproduzco también el resumen final a continuación:


El movimiento imparable desde el escritorio al móvil atenta contra el negocio de los sistemas operativos tradicionales. Éstos cada vez tendrán menos importancia puesto que todo está “en la nube” y accesible desde otros dispositivos. Por ello Microsoft debe poner todo su empeño en que Windows Phone 7 salga bien o su preponderancia puede acabar en manos de Google, Apple u otro competidor de fuera del negocio. Ello implica que los desarrolladores serán importantes durante estos primeros años. Así que si eres uno de ellos debes pensar cómo le vas a sacar partido a esta oportunidad.


Por otro lado el movimiento desde el navegador hacia aplicaciones especializadas (que en los móviles muchas veces son necesarias) atenta contra el negocio de Google y compañía, ya que no tienen tan fácil vivir de la publicidad. Por eso es tan importante para ellos posicionarse con un sistema operativo + distribución de software y atar a los usuarios a su plataforma. Por eso, si eres desarrollador deberías elegir muy bien por qué plataforma apuestas pues en algunas el problema es que a lo mejor no puedes cobrar aunque la gente quiera pagarte.


En tercer lugar los operadores se verán muy afectados por el masivo volumen de tráfico que deberán gestionar sus redes, por lo que tendrán que cambiar paulatinamente de tecnología y habilitar otros medios de acceso para no dejar sin servicio a los clientes y que sus clientes móviles sigan siendo rentables. La limitación artificial del tráfico máximo consumido no es una opción (o eso espero). Veremos que pasa.


Y por fin, mi apuesta para el medio plazo sería desarrollar todo para ser usado vía Web, con HTML 5 y no para plataformas propietarias. Ya puedes usar desde un navegador hardware como el GPS o el acelerómetro. Si se incorpora de manera semi-estándar también la cámara y otros pequeños dispositivos, las aplicaciones nativas sólo tendrían sentido para ciertas funciones muy específicas. A Google esto le interesaría pues encaja con su modelo actual. A los de más probablemente no. ¿Romperá alguien la baraja? Y si lo hace ¿qué efecto tendría en todo esto que he comentado?

 Los únicos que, en cualquier caso, tendrán un futuro complicado y a la vez lleno de oportunidades van a ser los operadores. Y los desarrolladores tienen la llave del futuro pase lo que pase.

Puedes leer el post completo aquí: “La movilidad, el cambio de paradigma, los fabricantes, los buscadores y los desarrolladores

Evitar que se publiquen las descripciones de nuestros servicios Web

Si disponemos de un servicio Web en nuestro servidor que está destinado a ser utilizado por nuestras aplicaciones pero no queremos facilitar que otros programadores le puedan sacar partido: ¿para qué queremos dejar publicado su archivo de descripción WSDL?


El WSDL (Web Services Description Language) describe cómo es un servicio Web: qué tipos usa, qué métodos expone, etc… y es lo que usan Visual Studio y otras herramientas para crear un proxy que nos permita usar un determinado servicio. Se puede visualizar para cualquier servicio de .NET añadiendo ?wsdl al final de su URL, por ejemplo:



http://www.miservidor.com/Servicios/miServicio.asmx?wsdl


Cuando añadimos una nueva referencia Web a nuestro proyecto, en el diálogo que aparece podemos inspeccionar el servicio gracias a su descripción WSDL:


AnhadirWS_WSDL


Sin ese WSDL no podríamos inspeccionarlo ni tampoco añadir la clase proxy correspondiente.


Un proxy es una serie de clases .NET que actúan de intermediarias entre nuestro código y el servicio. Para nosotros es transparente el uso del proxy ya que nuestro código las ve como clases normales, y nos parece que estamos manejando de manera directa el servicio y llamando a sus métodos directamente. Sin embargo lo que ocurre es que las clases proxy, por debajo se encargan de hacer las llamadas pertinentes al servicio utilizando la clase SoapHttpClientProtocol por debajo. El nombre de la clase proxy que se crea al agregar una referencia es el que indiquemos en el diálogo anterior( recuadrado en rojo en la figura).


Una vez que está generado el proxy en nuestro proyecto ya no es necesario el WSDL para nada. Es decir, en un servidor en producción, salvo que queramos que cualquiera pueda conectarse y utilizar el servicio, no se necesita exportar el WSDL.


Entonces, lo mejor que podríamos hacer es evitar que se publique esta información en el servidor de producción. No es una medida de seguridad por si sola, ya que no evitará que alguien que conozca el servicio pueda utilizarlo, pero sí que pondrá una buena barrera para la mayor parte de los posibles “curiosos”.


Dado que por defecto, si alguien le añade ?WSDL al nombre del servicio, aparecerá el WSDL del mismo ¿cómo evitamos que esto funcione así?


Puedes evitar que se publique el WSDL añadiendo este ajuste a web.config:

<webServices>
<protocols>
<remove name=»Documentation» />
</protocols>
</webServices>

De esta forma podemos decidir por configuración si queremos que sea visible o no, sin tener que tocar el código ni recompilar.


¡Espero que te sea útil!


AÑADIDO 19/08/2010: Quitar WSDL en servicios WCF


A raíz de una pregunta de un lector del blog en Geeks.ms (sitio donde se hace crossposting), si el servicio no es «puro» de ASP.NET sino que se ha construido con Windows Communication Foundation (WCF), entonces para conseguir el mismo efecto basta con retirar el nodo <serviceMetadata> de su configuración para que no se publique el WSDL.

TRUCO: Cómo centrar un elemento HTML con CSS

En mi opinión la combinación HTML+CSS es un verdadero infierno. Es para volverse loco como el de la foto. Y si le añades JavaScript no te quiero ni contar. Y no debería ser así. Hay muchas cosas que debes hacer normalmente y que deberían ser muuuuy fáciles, pero CSS las convierte en algo complicadísimo. Por ejemplo lo que me ocupa hoy: si quiero que un elemento de mi página aparezca centrado dentro de su elemento padre ¿por qué no puedo poner simplemente un atributo “centered:true;” o algo así?. No debería ser tan complicado como es ahora ¿verdad?.

Bien es cierto que no soy un super-experto en CSS y que además lo que de verdad convierte el trabajo Web en un infierno son los navegadores y sus pequeñas sutilezas y diferencias a la hora de cumplir (o no) los estándares. Pero también es verdad que es excesivamente complicado y no debería ser así. Encima todavía hay mucho gañán por ahí que usa Internet Explorer 6 (o peor aún, Windows 98), Firefox del año de la polka, o (me dan escalofríos sólo de pensarlo) alguna versión de Netscape. Y así es cuando es imposible conseguir algo que funcione como es debido. A esos, lo siento mucho, pero que no haré esfuerzo alguno por darles soporte en mis páginas. Total, acabarán tarde o temprano con el ordenador frito por algún virus (muy merecidamente), y se comprarán uno nuevo con Windows 7 o Mac OS X. Como Dios manda 😉

Bueno, a lo que íbamos, que me disperso…

Si tienes que conseguir que un elemento de tu página se centre automáticamente en la misma lo que tienes que hacer es aplicarle un estilo como este:

.centrado{
  margin-left: auto;
  margin-right: auto;
}

Es decir, lo que tenemos que hacer es indicar que queremos un margen automático tanto a la izquierda como a la derecha del elemento. Obvio y sencillo ¿verdad? 😉

¡No me funciona en Internet Explorer!

Esto funcionará bien en Chrome, Firefox o Safari, pero si lo pruebas en Internet Explorer 8 no te hará ni caso por defecto. Más de alguno ya estará pensando: “¡Maldita sea!, estos #$%@ de Microsoft pasando de cumplir con los estándares”.

Bueno en realidad lo que pasa es otra cosa. Si no le indicamos otra cosa, por defecto IE8 mostrará el contenido HTML en modo «quirks», es decir, en modo de compatibilidad con páginas viejas, por lo que no hará caso a indicaciones estándar que le pongamos. Pero eso no siginifica que no soporte el estándar adecuadamente (al menos en este caso). Simplemente hay que indicarle que debe hacerlo.

Para ello lo que hay que hacer es poner como primera línea del código HTML el tipo de documento, indicando por tanto que debe ceñirse a un estándar concreto (sí, IE es un infierno). Por ejemplo, para XHTML 1.0 sería este:

<!DOCTYPE html PUBLIC «-//W3C//DTD XHTML 1.1//EN» «http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd»>

Haciendo esto, ahora IE8 intepreta correctamente las instrucciones y centra el elemento horizontalmente al aplicarle un estilo como el anterior.

¡Eh! Las imágenes siguen sin centrarse

Claro. Es que lo anterior se aplica a aquellos elementos, como los DIV, que se renderizan en modo bloque. Sin embargo las imágenes se renderizan en modo «inline» (en línea con el texto y otros elementos inline), por lo que no hace ni caso a los atributos anteriores de margen automático. Otros elementos inline son los enlaces, span, controles input, etc…

¿Cómo lo solucionamos?

Pues tenemos dos opciones: usar el estilo CSS «text-align:center;» que hace que el texto (y los elementos en línea) se centren o, mejor aún, hacer que la imagen se comporte como un elemento de bloque añadiendo a sus estilos «display:block;«:

.centrado{
  display:block;
  margin-left: auto;
  margin-right: auto;
}

Al hacer esto ya se comportará de la manera esperada.

¿Y cómo centro verticalmente?

Buena pregunta. Me alegro de que la hagas… En CSS2 tampoco hay ninguna forma fácil de hacerlo. Y aún es más rebuscado que el caso anterior.

Básicamente lo que hay que hacer (y lo dice la propia W3C), es hacer que el elemento contenedor del elemento que queremos centrar se comporte como una celda de una tabla. Como las celdas de las tablas síse pueden alinear con el estilo vertical-align, entonces si le damos una determinada altura seremos capaces de que se centren los elementos que contiene:

.centradoV
{
    display: table-cell;
    vertical-align: middle
}

El problema es que esto destruye el centrado horizontal del elemento padre, y si queremos centrar ambos tenemos que nidar otros elementos.

En resumen

Lo dicho: una pesadilla. Parece mentira.

La versión 3 de CSS, que lleva en desarrollo desde 2005, parece que algo van a hacer para mejorarlo. No me he leído a fondo el draft actual de la parte de posicionamiento de elementos (que es de abril de este año), pero eso de definir «slots» y colocar cosas en ellos posicionándolos con letras no me llama ni un poco. A este paso va a ser más dificil aprender HTML+CSS que sacarse la carrera de aeronáuticos 🙁

Por cierto, me ha llamado la atención ver que en el Draft de esta parte está trabajando un español de la Univerdad de Oviedo…

En fin, espero que lo que cuento en este post te resulte de ayuda y te saque de algún apuro.

Mensaje “No se permite guardar los cambios” en SQL Server 2008

Una vez creada una nueva tabla en una base de datos en SQL Server 2008 o SQL Server 2008 R2, si utilizas en SQL Server Management Studio, cuando intentas modificarla con algún cambio importante (como añadir o quitar un campo, por ejemplo), seguramente te encontrarás con este mensaje de advertencia:


Unable to modify table - No se ha podido modificar la tabla


Lo que te está indicando es que no se han podido grabar los cambios en la tabla, y que los únicos campos permitidos son los que pueden contener nulos o tienen un valor por defecto (en este caso concreto).


Además, la única opción que te da es la de aceptar, por lo que al hacerlo se te muestra otro mensaje de advertencia diciéndote que has cancelado el grabar los cambios (qué simpáticos: no te quedaba más opción que hacerlo):


User canceled out of save dialog - El usuario ha cancelado el guardado


¿A qué es debido esto?: El motivo es que el SQL Server Management Studio que viene con SQL Server 2008 trae activada una opción por defecto que impide cualquier cambio sobre las tablas que implique el tener que regenerarlas (es decir, que implique eliminar la tabla, crearla de nuevo y volver a rellenarla). Toda operación que implique eso está prohibida.


Esta medida está muy bien en entornos de producción, en los que podemos meter la pata fácilmente haciendo cambios, pero en nuestro equipo de desarrollo tenerlo activado es un sinsentido.


Para solucionarlo vete al menú “Herramientas/Opciones” y en el diálogo que aparece desmarca la opción indicada a continuación dentro de la pestaña “Diseñadores”:


Prevent saving changes that require table re-creation




¡Listo! Ahora cierra los diálogos que tuvieras abiertos y vuelve a intentarlo. Verás que funciona sin problema.


¡Espero que te sea útil!

Impresionante utilidad on-line para Favicons

Los iconos para favoritos son esos gráficos que aparecen en lapestaña del navegador y en favoritos cuando visitas una página:



Hoy he descubierto de casualidad una impresionante utilidad on-line para generar iconos para Favoritos: HTML-Kit.com FavIcon from Pics


Te permite subir cualquier imagen y la convierte en un Favicon de diversos tamaños, sin necesidad de instalar nada y totalmente gratuita. Hasta aquí lo normal, pues hay muchísimas utilidades parecidas por Internet. Pero esta página además te permite hacer muchas otras cosas: Favicon para iPhone/iPad/iPod, favoritos animados con un texto pudiendo elegir colores, etc…, elección de formatos, bordes,…


En un minuto puedes generar verdaderas «virguerías» de iconos para favoritos, así que os lo recomiendo mucho.


Por supuesto le he donado unos dólares al autor, para compensar su esfuerzo.


Este tipo de cosas se hacen gratuitamente pero cuestan mucho esfuerzo (lo mismo que hacer un blog decente, por ejemplo), y si queremos que sigan existiendo hay que apoyarlas de algún modo económicamente. Hay dos formas principalmente:


1) Donar dinero si disponen de algún botón para ello (puede ser tan sólo un dólar o menos, todo depende de lo que te hayan ayudado)
2) Pulsar en algún anuncio que nos interese, si la página muestra anuncios decetes, claro.


Saludos!

BlogEngine.net Extension: Scribd Viewer 1.0

I’m a big fan of the «YouTube of documents», Scribd. Our company has a page full of interesting technical documents there (in Spanish, sorry) and it’s frequent that we need to add one of those documents embedded in a blog post or page.

So I decided to create a new extension for BlogEngine.net that will allow to use the already available embdedded codes that Scribd offers for WordPress users.

Installing the Scribd Viewer Extension for BlogEngine.net

Just download this ZIP here: ScribdViewer.zip (108KB), expand the contenst and copy the ScribdViewer.cs file to your BlogEngine.net /App_Code/Extensions folder. That’s it.

Now go to the administration part of your blog and in the «Extensiones» tab make sure that the new «Scribd Viewer» extension is enabled. You can configure it by setting the width and height of the viewer (read more about it below).

Now you can start using the extension for embedding Scribd documents in your posts and pages (both types of content are supported).

Using the Scribd Viewer Extension for BlogEngine.net

After installing this extension the only thing you need to do for embed an Scribd document automatically is to use the WordPress code that Scribd generates for you, something like this:

[scribd id=28867978 key=key-2jphu1aoqphuyqs9hxfn mode=slideshow]

Getting the WordPress embded code for a document in Scribd is quite straight forward in the Flash version of their viewer, but it’s a little bit trickier in the HTML5 viewer they are using lately:

First (1) you must click on the Share&Embed button in the bottom bar, then (2) unfold the settings section, and after taht (3) click on the «More sahre options» link. That opens another dialog:

In this new floating layer just click on the «WordPress.com format» tab (1) and the use the «Copy» button to copy the embedding code to the clipboard.

Now, you just need to paste this code in your BlogEngine.net post or page and you’re done!.

This is how the viewer looks like in a post:

In the «Extensions» tab of the BlogEngine.net configuration you can configure the Width and Height of the viewer. By default it uses 100% width and 600px height, wich are the default values in Scribd and should be Ok for most cases, but you can use any other values as long as they are valid HTML/CSS units (that is: px, pt, em, %, etc…).

In fact the height is automatically adjusted by the flash viewer itself to adap to the aspect ratio of the document, as you can easily see in the sample picture before.

Have fun!