Un link bastante útil que recopila todos los posibles mime-types (al menos aquellos más usados habitualmente, realmente algunos no los había visto en mi vida).
http://www.webmaster-toolkit.com/mime-types.shtml
Como detalle adicional, necesitaba usar una respuesta XML plana desde una página, al estilo de un pseudo web service, para el JQuery hay una diferencia entre application/xml y text/xml, de hecho el text/xml no es reconocido directamente como un objeto XML sino como texto puro y debe ser manipulado a través de DOM. El text/xml en sí es recomendado para hacerlo legible en una salida al usuario o si se usan DTD's.
Por otra parte, usar UTF-16 y UTF-2 a través de SMTP inhabilita por completo el uso de text/xml ya que no funciona.
sábado, 12 de diciembre de 2009
miércoles, 18 de noviembre de 2009
Remoting vs WCF
Debido a un tema de tecnología actualmente en el trabajo hemos tenido que realizar una cantidad importante de pruebas respecto de Remoting y WCF. En principio necesitamos modelar toda una serie de desarrollos orientados a objetos (OO) con una plataforma que nos permita operar los mismos desde cualquier lugar de forma (generalmente) SingleInstance.
En principio pareció simple evaluar y decidir, pero el tema entre Remoting y WCF parece más problemático que un clásico de fútbol. Incluso los foros tienden a sugerir una u otra tecnología basados en datos directos, como ser que uno tiene más performance que otro (lo cual es cierto en general) pero no basándose en cual es la mejor opción según la arquitectura.
En general todo aquel allegado a Microsoft sugiere inmediatamente WCF, para el caso nuestro la realidad es que dicha tecnología, aunque a mi me encanta, no nos sirve del todo y nos trae enormes complicaciones ya que genera un overhead importante, una cantidad de código adicional muy significativo, y ciertas cosas que no son para nada transparentes, como ser el hecho de enviar las excepciones tal cual se produjeron en el servidor.
Uno de mis compañeros abrió un post en Social MSDN y fuimos evaluando y preguntando según el feedback de usuarios y personas relacionadas a Microsoft, pueden seguirlo en la siguiente dirección:
http://social.msdn.microsoft.com/Forums/es-ES/wcf/thread/47948574-a573-4a9b-a470-e234720ba520
De todas maneras el tema es aún mucho más complejo, continuando con las pruebas encontramos pros y contras en ambas tecnologías, a tal punto que al margen de ser Remoting la antigua (pero aún subyacente) y wcf en teoría el futuro, optar por una u otra nos traería gran cantidad de problemas y beneficios.
En sucesivos post's agregaré información relacionada a lo que fui encontrando punto por punto entre ambos. En principio la opinión formal de Microsoft es que Remoting "es lo que es"; nada más se le agregará y tenderá a discontinuarse en el futuro, algo que dudo ya que internamente la tecnología que usa WCF es remoting! El futuro parece ser WCF pero hay una gran diferencia, hay un cambio de paradigma que para arquitecturas fuertemente orientadas a objetos, complica más el desarrollo de lo que ayuda.
Posteriormente desarrollaré el tema para que tengan información al respecto y puedan decidir o guiarse por lo que comentaré de ambas tecnologías. Por mi parte, me gusta mucho WCF y lo use o no en este proyecto, lo tendré en cuenta para todo lo que necesite en cuanto a arquitecturas orientadas a servicios (SOA).
En principio pareció simple evaluar y decidir, pero el tema entre Remoting y WCF parece más problemático que un clásico de fútbol. Incluso los foros tienden a sugerir una u otra tecnología basados en datos directos, como ser que uno tiene más performance que otro (lo cual es cierto en general) pero no basándose en cual es la mejor opción según la arquitectura.
En general todo aquel allegado a Microsoft sugiere inmediatamente WCF, para el caso nuestro la realidad es que dicha tecnología, aunque a mi me encanta, no nos sirve del todo y nos trae enormes complicaciones ya que genera un overhead importante, una cantidad de código adicional muy significativo, y ciertas cosas que no son para nada transparentes, como ser el hecho de enviar las excepciones tal cual se produjeron en el servidor.
Uno de mis compañeros abrió un post en Social MSDN y fuimos evaluando y preguntando según el feedback de usuarios y personas relacionadas a Microsoft, pueden seguirlo en la siguiente dirección:
http://social.msdn.microsoft.com/Forums/es-ES/wcf/thread/47948574-a573-4a9b-a470-e234720ba520
De todas maneras el tema es aún mucho más complejo, continuando con las pruebas encontramos pros y contras en ambas tecnologías, a tal punto que al margen de ser Remoting la antigua (pero aún subyacente) y wcf en teoría el futuro, optar por una u otra nos traería gran cantidad de problemas y beneficios.
En sucesivos post's agregaré información relacionada a lo que fui encontrando punto por punto entre ambos. En principio la opinión formal de Microsoft es que Remoting "es lo que es"; nada más se le agregará y tenderá a discontinuarse en el futuro, algo que dudo ya que internamente la tecnología que usa WCF es remoting! El futuro parece ser WCF pero hay una gran diferencia, hay un cambio de paradigma que para arquitecturas fuertemente orientadas a objetos, complica más el desarrollo de lo que ayuda.
Posteriormente desarrollaré el tema para que tengan información al respecto y puedan decidir o guiarse por lo que comentaré de ambas tecnologías. Por mi parte, me gusta mucho WCF y lo use o no en este proyecto, lo tendré en cuenta para todo lo que necesite en cuanto a arquitecturas orientadas a servicios (SOA).
lunes, 19 de octubre de 2009
Perfil de Windows XP dañado
Luego de un clásico problema de energía eléctrica acá en Buenos Aires, al encender la máquina recibí el maravilloso mensaje siguiente queriendo acceder mi perfil:
"The system has recovered from a serious error"
El perfil se dañó y perdí toda la configuración del mismo, no lo pude acceder nunca más. Lo peor es que ni siquiera podía repararlo ya que me indicó que todo cambio se iba a perder posteriormente.
Encontré un tipo de solución en las páginas de soporte de Microsoft.
http://support.microsoft.com/default.aspx?scid=kb;en-us;326688
A pesar que lo intenté buscando hacia atrás una configuración válida ninguna funcionó, el problema se dio hoy y restaurando hacia atrás en el tiempo no dio resultado. La única solución que encontré fue crear un nuevo perfil y comenzar a copiar a mano los datos del perfil anterior (previo backup por las dudas).
Casi todo está dentro del perfil si no se dañaron archivos; generalmente en:
C:\Documents and Settings\[Nombre Perfil]
El más importante de los settings es:
C:\Documents and Settings\[Nombre Perfil]\Datos de programa
Ya que contiene muchos datos importantes, como cuentas de Ftp (en mi caso) que hubiera perdido de no recuperar esa información, copiando y pegando de un perfil a otro funciona perfecto.
Alguna sugerencia para repararlo de manera más elegante es bienvenida.
"The system has recovered from a serious error"
El perfil se dañó y perdí toda la configuración del mismo, no lo pude acceder nunca más. Lo peor es que ni siquiera podía repararlo ya que me indicó que todo cambio se iba a perder posteriormente.
Encontré un tipo de solución en las páginas de soporte de Microsoft.
http://support.microsoft.com/default.aspx?scid=kb;en-us;326688
A pesar que lo intenté buscando hacia atrás una configuración válida ninguna funcionó, el problema se dio hoy y restaurando hacia atrás en el tiempo no dio resultado. La única solución que encontré fue crear un nuevo perfil y comenzar a copiar a mano los datos del perfil anterior (previo backup por las dudas).
Casi todo está dentro del perfil si no se dañaron archivos; generalmente en:
C:\Documents and Settings\[Nombre Perfil]
El más importante de los settings es:
C:\Documents and Settings\[Nombre Perfil]\Datos de programa
Ya que contiene muchos datos importantes, como cuentas de Ftp (en mi caso) que hubiera perdido de no recuperar esa información, copiando y pegando de un perfil a otro funciona perfecto.
Alguna sugerencia para repararlo de manera más elegante es bienvenida.
lunes, 12 de octubre de 2009
Configuración de Apache
Una página con la configuración bien explicada sobre Apache:
http://www.estrellateyarde.es/discover/servidor-http-en-linux
http://www.estrellateyarde.es/discover/servidor-http-en-linux
Soy Maximiliano Rios
Conocé todas mis publicaciones
PHP con IIS o Apache
Problemas con PHP en IIS / Apache y mod_rewrite
Como desarrollador con más de 15 años de experiencia he obtenido información de la web en cantidades industriales, ya sea topándome con problemas menores (comodidad) o mayúsculos e indescifrables. Haciendo un poco de memoria recuerdo que hace 15 años atrás le pagábamos a soporte de desarrollo Microsoft unos 250 pesos actuales por cada página faxeada con soluciones de su base de conocimiento. Por suerte hoy está todo casi al alcance de la mano y, como retribución a todos los que me ayudaron en su momento sin saberlo, comienzo a escribir artículos con inconvenientes que tuve y soluciones que encontré para compartirlas con los demás.
Hace poco más de un año retomé el desarrollo en PHP, el cual había dejado de lado por un tiempo largo ya que principalmente desarrollo con herramientas de Microsoft (.Net 1.1, 2.0 y 3.5). Instalé en mi máquina de desarrollo la versión 5.2.4 de php sobre el ya existente IIS. Hasta ahí todo funcionó perfectamente pero un trabajo actual me exigía el mod_rewrite para las famosas friendly url's. Intenté agregar algunas extensiones que ya existen y que hacen lo mismo, pero al tener que modificar ciertos comportamientos y tratándose de un sitio existente opté por instalar Apache tal cual está en el servidor de producción.
La versión de Apache instalada es la 2.2.14 y desde el principio comencé a tener inconvenientes. Primero debía hacer funcionar el php, y a pesar de las distintas combinaciones de modificar el httpd.conf por mi cuenta no logré hacerlo funcionar. Lo que más encontraba en los blogs y foros era agregar lo siguiente:
ScriptAlias /php/ "C:\Directorio\PHP"
AddType application/x-httpd-php .php
Action application/x-httpd-php "/php/php.exe"
Si bien todos indican que debe funcionar no lo hace, hay temas de permisos implícitos que se deben modificar y ninguna sugerencia funcionó. En teoría el php.exe debería ejecutarse en un subdirectorio de la raíz del servidor Apache, o bien modificar permisos. Opté por abrir la instalación de PHP, ejecutar la opción "cambiar configuración" y dejar que se encargue el instalador, el cual escribió lo siguiente:
#BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
PHPIniDir "C:/Directorio/PHP/"
LoadModule php5_module "C:/Directorio/PHP/php5apache2_2.dll"
#END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
Dejando activo de las anteriores líneas sólo el AddType:
AddType application/x-httpd-php .php
Evidentemente por defecto usa la librería mencionada y no el exe como Shell. Hasta ahí fue relativamente simple.
Luego debía configurar el .htaccess y la redirección. En principio un dato importante que me volvió loco al no estar tan acostumbrado a trabajar con php:
Hint: Los ftp por defecto ocultan los archivos que empiezan con . por seguridad, por ende jamás veía el archivo .htaccess para bajarlo hasta que no modifiqué la configuración. En FileZilla por ejemplo está en "Server -> Force showing hidden files"
Luego de agregar a la raíz del directorio donde estaba trabajando el .htaccess seguía sin funcionar porque no había activado el rewrite, eso se logra sacando el comentario a la línea
#LoadModule rewrite_module modules/mod_rewrite.so
para transformarla en:
LoadModule rewrite_module modules/mod_rewrite.so
Al reiniciar el servidor, si no hubo errores, ya el módulo está cargado. Como eso no me permitía visualizar la friendly url tuve que hacer más modificaciones al httpd.conf, en la configuración Directory hay que activar el AllowOverride para que quede de la siguiente manera:
<directory>
Options FollowSymLinks
AllowOverride All
Order deny,allow
Deny from all
</directory>
De todas maneras no comenzó a funcionar hasta que en el Directory de la raíz (el anterior es el default) lo activé también. En eso no estoy seguro si ambos son realmente necesarios, porque no me funcionó hasta que el siguiente tag:
<Directory "C:/dir instalación/Apache2.2/htdocs">
No tuvo los mismos cambios que el anterior.
Luego de todas estas modificaciones por fin pude hacer funcionar adecuadamente las friendly url's.
Otro dato menor pero que ya me causó problemas, en un momento determinado el IIS dejó de funcionar y no levantaba, me di cuenta algo muy simple pero que trae complicaciones.
Hint: Al instalar Skype por defecto está configurado para usar los puertos 80 (estándar para http) y 443 (estándar SSL) como alternativa para conexiones entrantes. (Herramientas -> Opciones -> Conexión). Evidentemente lo abre al puerto aún no estando conectado y no se puede usar para el IIS, al modificarlo al 8080 en IIS comenzó a funcionar. Pero también hizo que no se instalara correctamente el Apache luego, por lo cual es mejor al menos hasta que se instale desmarcar esa casilla y usar un puerto alternativo en el textbox superior hasta que esté instalado el Apache.
Espero que les haya sido útil, y los más expertos de php me pueden corregir o sugerir lo que crean conveniente ya que, como aclaré, no estoy tan involucrado con las herramientas como php comparado a .Net.
Como desarrollador con más de 15 años de experiencia he obtenido información de la web en cantidades industriales, ya sea topándome con problemas menores (comodidad) o mayúsculos e indescifrables. Haciendo un poco de memoria recuerdo que hace 15 años atrás le pagábamos a soporte de desarrollo Microsoft unos 250 pesos actuales por cada página faxeada con soluciones de su base de conocimiento. Por suerte hoy está todo casi al alcance de la mano y, como retribución a todos los que me ayudaron en su momento sin saberlo, comienzo a escribir artículos con inconvenientes que tuve y soluciones que encontré para compartirlas con los demás.
Hace poco más de un año retomé el desarrollo en PHP, el cual había dejado de lado por un tiempo largo ya que principalmente desarrollo con herramientas de Microsoft (.Net 1.1, 2.0 y 3.5). Instalé en mi máquina de desarrollo la versión 5.2.4 de php sobre el ya existente IIS. Hasta ahí todo funcionó perfectamente pero un trabajo actual me exigía el mod_rewrite para las famosas friendly url's. Intenté agregar algunas extensiones que ya existen y que hacen lo mismo, pero al tener que modificar ciertos comportamientos y tratándose de un sitio existente opté por instalar Apache tal cual está en el servidor de producción.
La versión de Apache instalada es la 2.2.14 y desde el principio comencé a tener inconvenientes. Primero debía hacer funcionar el php, y a pesar de las distintas combinaciones de modificar el httpd.conf por mi cuenta no logré hacerlo funcionar. Lo que más encontraba en los blogs y foros era agregar lo siguiente:
ScriptAlias /php/ "C:\Directorio\PHP"
AddType application/x-httpd-php .php
Action application/x-httpd-php "/php/php.exe"
Si bien todos indican que debe funcionar no lo hace, hay temas de permisos implícitos que se deben modificar y ninguna sugerencia funcionó. En teoría el php.exe debería ejecutarse en un subdirectorio de la raíz del servidor Apache, o bien modificar permisos. Opté por abrir la instalación de PHP, ejecutar la opción "cambiar configuración" y dejar que se encargue el instalador, el cual escribió lo siguiente:
#BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
PHPIniDir "C:/Directorio/PHP/"
LoadModule php5_module "C:/Directorio/PHP/php5apache2_2.dll"
#END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
Dejando activo de las anteriores líneas sólo el AddType:
AddType application/x-httpd-php .php
Evidentemente por defecto usa la librería mencionada y no el exe como Shell. Hasta ahí fue relativamente simple.
Luego debía configurar el .htaccess y la redirección. En principio un dato importante que me volvió loco al no estar tan acostumbrado a trabajar con php:
Hint: Los ftp por defecto ocultan los archivos que empiezan con . por seguridad, por ende jamás veía el archivo .htaccess para bajarlo hasta que no modifiqué la configuración. En FileZilla por ejemplo está en "Server -> Force showing hidden files"
Luego de agregar a la raíz del directorio donde estaba trabajando el .htaccess seguía sin funcionar porque no había activado el rewrite, eso se logra sacando el comentario a la línea
#LoadModule rewrite_module modules/mod_rewrite.so
para transformarla en:
LoadModule rewrite_module modules/mod_rewrite.so
Al reiniciar el servidor, si no hubo errores, ya el módulo está cargado. Como eso no me permitía visualizar la friendly url tuve que hacer más modificaciones al httpd.conf, en la configuración Directory hay que activar el AllowOverride para que quede de la siguiente manera:
<directory>
Options FollowSymLinks
AllowOverride All
Order deny,allow
Deny from all
</directory>
De todas maneras no comenzó a funcionar hasta que en el Directory de la raíz (el anterior es el default) lo activé también. En eso no estoy seguro si ambos son realmente necesarios, porque no me funcionó hasta que el siguiente tag:
<Directory "C:/dir instalación/Apache2.2/htdocs">
No tuvo los mismos cambios que el anterior.
Luego de todas estas modificaciones por fin pude hacer funcionar adecuadamente las friendly url's.
Otro dato menor pero que ya me causó problemas, en un momento determinado el IIS dejó de funcionar y no levantaba, me di cuenta algo muy simple pero que trae complicaciones.
Hint: Al instalar Skype por defecto está configurado para usar los puertos 80 (estándar para http) y 443 (estándar SSL) como alternativa para conexiones entrantes. (Herramientas -> Opciones -> Conexión). Evidentemente lo abre al puerto aún no estando conectado y no se puede usar para el IIS, al modificarlo al 8080 en IIS comenzó a funcionar. Pero también hizo que no se instalara correctamente el Apache luego, por lo cual es mejor al menos hasta que se instale desmarcar esa casilla y usar un puerto alternativo en el textbox superior hasta que esté instalado el Apache.
Espero que les haya sido útil, y los más expertos de php me pueden corregir o sugerir lo que crean conveniente ya que, como aclaré, no estoy tan involucrado con las herramientas como php comparado a .Net.
Suscribirse a:
Entradas (Atom)