Desde una aplicación desarrollada con ASP.Net, es posible utilizar los informes de Crystal Reports que hayamos generado desde Visual Studio. Pero hace poco tuve un problema, y dejo aquí la solución por si ha alguien le sirve.

Situación: aplicación desarrollada ASP.Net MVC que utiliza informes creados con Crystal Reports (en formato .rpt) y que funciona sin problemas desde los equipos de desarrollo (Windows 7). Los informes se muestran en el cliente mediante un Stream que genera un archivo PDF que se visualiza en el navegador.

Problema: un informe utiliza un fuente para mostrar un código de barras EAN-13 dentro de un documento. Desde los equipos de desarrollo, tanto con el servidor web de desarrollo integrado en Visual Studio, como utilizando IIS 7 desde los equipos se muestra perfectamente. Sin embargo, al pasar al servidor de producción (Windows 2003 Small Business Server) que utiliza IIS 6, el PDF visualizado no muestra el código de barras.

Pruebas fallidas: se instalan las fuentes en el equipo cliente, se instalan en el servidor, se colocan en la carpeta bin, accesible a la aplicación MVC, se cambia de versión de runtime de Crystal Reports, etc. Nada de esto funciona.

La solución: después de probar y buscar soluciones durante varias horas, al final encuentro está que sí que funcionó: Ir a la Configuración regional y de idioma del Windows 2003, en la pestaña de Idiomas marcar la casilla “Instalar archivos de idiomas de escritura compleja y de escritura de derecha a izquierda (incluyendo tailandés)”.

En la misma ventana, en la ficha de Opciones avanzadas, marcar la casilla “Aplicar toda la configuración a la cuenta de usuario actual y al perfil de usuario predeterminado”.

Este cambio, exige el reinicio del servidor, pero después de hacerlo, el informe de Crystal Reports con todas las fuentes, aparece sin problemas en los equipos cliente.

Cuando quereamos modificar la página principal, vamos… la home page de una aplicación que esté hecha con Ruby on Rails, hay que tener en cuenta que cualquier fichero que se encuentre en el directoriopublic, siempre tendrá preferencia con respecto a cualquier contenido dinámico que sea generado a partir de un controlador.

Por lo tanto, lo primero es entrar en la carpeta public y borrar el fichero index.html

Lo segundo es generar el controlador que responerá a la acción que queremos con la plantilla del método que nos interesa:

> rails generate controller home index

Ahora en el fichero de plantilla index.html.erb, ubicado en el directorio /views/home tendremos el contenido que se mostrará en el navegador.

Por último, hay que indicarle a Rails cuál va a ser la nueva ruta de la página principal. Para ello hay que entrar en el fichero config/routes.rb, buscar la línea que empieza con la palabra root :to y colocar la ruta en el formato:

"nombre_del_controlador#nombre_del_método"

En nuestro caso quedará así:

root :to => "home#index"

Con esto, ya podemos modificar el fichero /views/home/index.html.erb con el contenido que quedamos que se muestre en el navegador al ir a la home de nuestro servidor web.

No siempre cuando empezamos a programar una aplicación sabemos que nombre va a tener definitivamente, o bien, arrancamos con un ejemplo y al irle añadiendo funcionalidad descubrimos que nos sirve y lo vamos a utilizar. En este caso es útil cambiarle el nombre a la aplicación.

Eso me ha ocurrido utilizando Rails 3.2.1, y para cambiar el nombre he sustituido la referencia del nombre del proyecto antiguo por el nuevo en:

• La carpeta del proyecto.
• config/application.rb
• config/environment.rb
• config/routes.rb
• config/environments/development.rb
• config/environments/production.rb
• config/environments/test.rb
• config/initializers/secret_token.rb
• config/initializers/session_store.rb (aquí hay que sustituirlo tanto en la línea activa, como en la línea comentada, por si en algún momento cambiamos el control de sesiones de usuario).
• config.ru
• Rakefile
• app/views/layouts/application.html.erb (no es importante para Rails ya que está en la etiqueta de título).

Con esto he podido utilizar el proyecto sin ningún problema.

Después de varios años sin programar con Ruby on Rails, estoy retomandolo, y están son las  recomendaciones básicas sobre guías, libros (en inglés), webs, etc. Las dejo aquí por si a alguien más le sirven:

Webs:

• http://www.rubyonrails.org (por supuesto, el primer sitio donde empezar).
• http://guides.rubyonrails.org/getting_started.html (la guía básica)
• https://marakana.com/s/tags/ruby/
• http://ruby.railstutorial.org/ruby-on-rails-tutorial-book
• http://www.railscasts.com (colección de vídeos con ejemplos prácticos)
• http://snippets.dzone.com/tags/rails (fragmentos de código para “insertar”)

Libros:

• “Agile Web Development with Rails” (web)
• “Programming Ruby” (web)
• “Rails antipatterns: best practice Ruby on Rails refactoring”  (en amazon.com)

Sitios construidos con RoR:

• Por supuesto… Twitter
• Aplicaciones web de 37signals
• Shopify (comercio electrónico)
• Groupon.
• Yellow pages.

¿Cuáles son vuestras recomendaciones?

Esto no debería ocurrir… porque deberíamos saber cuál es el juego  de caracteres de una base de datos que manejemos, pero a veces en base de datos antiguas, o cuando no administramos una B.D. y tenemos que hacer alguna modificación, necesitamos saber cuál es el juego de caracteres utilizado.

En bases de datos SQL Server 2005 y en adelante, se pueden usar estas sentencias:

1. Para saber cuál es el juego de caracteres de una columna de una tabla concreta:

SELECT collation_name FROM sys.columns WHERE name = 'nombreDeCampo' AND [object_id] = OBJECT_ID('dbo.nombreDeTabla');

2.Para saber el juego de caracteres por defecto de una base de datos:

SELECT collation_name FROM sys.databases WHERE name = 'nombreDeLaBaseDeDatos';

Por último, si queremos estar seguros de la versión del motor de SQL Server, hay que ejecutar la consulta:

SELECT @@version;

SQL Server 2005 es la versión 9, así que para que funcionen las consultas anteriores, necesitamos que sea como mínimo esa versión.

Espero que os sirva!

Según leo en el New York Times, dos investigadores de la Universidad de Virgina y cuatro del Microsoft Research han presentado un documento relacionado con el cloud computing en el que plantean la posibilidad de que haya servidores (operados por las empresas) en domicilios particulares. Al concepto lo llaman “horno de datos” (data furnace).

La ventaja para las empresas es el ahorro, ya que estos investigadores han calculado tener  cada servidor en un centro de datos cuesta 400$ anuales, incluyendo los gatos de enfriar el calor que emite el servidor. Teniendo en cuenta que en muchos casos, los gastos de enfriar el servidor llegan al 50% del coste de su consumo eléctrico, podríamos calcular que el gasto de enfriar el calor producido puede acercarse a los 150$ anuales.

La ventaja para los usuarios es el ahorro (vaya igual que para las empresas . En zonas frías de EEUU, unas 110 placas podrían mantener una casa caliente. Los servidores serían operados a través de la conexión de Internet que hay en las casas, y teniendo en cuenta que en caso de desconexiones o problemas, los sistemas de cloud computing ya tienen previstos los sistemas de relevo entre servidores, no debería producirse ninguna gran catástrofe.

El tiempo nos dirá si esta idea funciona. De momento, tiene a su favor el ahorro que produciría para las empresas y para el usuario.

Voy a encender el servidor, que hace frío.

Cuando desarrollamos una aplicación para Windows, también llamada aplicación de escritorio (usando herramientas de desarrollo de Microsoft) tenemos disponibles dos tecnologías desde Visual Studio:

• WPF: Windows Presentation Foundation.
• Windows Forms.

Los formularios de Windows han sido la opción más habitual para crear los interfaces de usuario en Visual Studio. Sin embargo, WPF es la tecnología destinada a sustuir a Windows Forms. Tienen una diferencia (que para mí es una ventaja) fundamental: el código del interfaz está separado del código de la aplicación. De esta forma, el código de la aplicación lo definiremos con lenguajes como Visual Basic o C#, mientras que el interfaz lo deniremos con una lenguaje llamado XAML (eXtensible application markup language).

En WPF se pueden usar tres tipos de controles:

1. Controles individuales: tienen un único propósito o uso, como por ejemplo los botones, las cajas de texto, los deslizadores, las barras de progreso y las etiquetas.
2. Controles de tipo item: sirven para contener grupos de elementos gráficos relacionados. Por ejemplo, un ComboBox, un ListBox, un menú o una barra de herramientas.
3. Controles layout: contienen otros controles y definen visualmente cómo van a estar posicionados dichos controles. Por ejemplo, un grid panel, un dock panel o un canvas.

Todos los elementos gráficos de WPF se controlan mediante sus propiedades, pero además, en determinados casos y según el layout utilizado, pueden aparecer unas propiedades adicionales llamadas attached properties, que contienen información de la posición del control dentro de su layout, por ejemplo, si un control está dentro de un grid panel aparecen propiedades para indicar en qué fila y columna se encuentra.

Podemos ver el XAML que define los controles en Windows como una especie HTML, que mediante etiquetas, valores y propiedades define una ventana. Algunos ejemplos podrían ser:

Definición de un TextBox:

<TextBox Name="usuario" Height="95" Margin="15,30,15,30" VerticalAlignment="Top" />

Definición de un ListBox:

<ListBox Name=color">

<CheckBox Name="rojo">Color rojo</CheckBox>

<CheckBox Name="azul">Color azul</CheckBox>

<CheckBox Name="verde">Color verde</CheckBox>

</ListBox>

Si podemos ver el XAML como una especie de HTML, este también tiene su definición de estilos como si CSS se tratara, de forma que en un formulario podemos utilizar una declaración como esta:

<Window.Resources>

<Style TargetType="Button">

<Setter Property="Background" Value="Black" />
<Setter Property="Foreground" Value="White" />
<Setter Property="Width" Value="135" />

</Style>

</Window.Resources>