WampServer 2.0: el nuevo WAMP5

ByLuis

WAMP5 ha cambiado y ahora se llama WampServer 2.0, el cambio no solo ser refiere al nombre, sino a una gran novedad, permite instalar distintas versiones de Apache, MySQL y PHP, pudiendo elegir la que más nos convenga en cada situación, teniendo en cuenta que no todas las versiones de PHP son compatibles con todas las versiones de Apache.
wampserver.png
Este cambio es muy importante, ya que los entornos de trabajo no son siempre los mismos y debido a imcompatibilidades es necesario crear nuestras aplicaciones en entornos de trabajo exactos al real.
Nos permite modificar las opciones de las versiones de MySQL, PHP y Apache que estén seleccionadas en ese momento, aunque aún echo en falta poder visualizar los logs de apache que desee (no solo el por defecto), elegir la aplicación para ver los logs y poder permitir modificar los virtual hosts de apache.
WampServer 2.0
Vía / OpenSourceCommunity.org

Similar Posts

Project Kenai: proyectos open source alojados por Sun

ByLuis

Project Kenay es una especie de SourceForge que ha realizado Sun y que aún está en fase beta. Dispone de pocos proyectos alojados (la mayoría basados en Java y Ruby) pero está empezando y vamos a tener que estar pendiente de este proyecto.
Kenai provee a los proyectos de SVN y Mercurial, foros, listas de correo, wikis, sistemas de bugs y personalización de tu página.
Porject Kenai

W2W: la web vista desde el P2P

ByLuis

Aviso: este post es simplemente una idea que se me ha ocurrido y que quería compartir, posiblemente no digo más que tonterías, pero bueno, quizás mis tonterías puedan tener algo de sentido común.

Estaba leyendo un post de High Scalability acerca de cómo construir web altamente escalables. El artículo, entre otras muchas cosas habla sobre la posibilidad de crear una red social que tenga la capacidad de soportar miles de millones de usuarios.

Esta magnitud de usuarios puede parecer futurista, pero los datos que aporta sobre Facebook y el crecimiento en número de conexiones a nivel mundial, hacen que estos datos puedan ser posibles en unos cuantos años:

[…] Para hacer este mágico trabajo, Facebook gasta cientos de millones de dólares en datacenters, tienen más de 30.000 servidores, 300 millones de usuarios activos, 80.000 millones de fotografías, sirven 600.000 fotos por segundo, tienen 28TB de caché, generan 25TB de logs por día y su caché sirve 120 millones de queries cada segundo.

A mi estos números me asustan, no sólo por la cantidad en sí de todo: servidores, fotos, queries, … sino porque si por algún casual alguna vez llego a estar metido en un proyecto de esta envergadura no sé si seré capaz de estar a la altura.

Pero si Facebook da miedo, la gente de Google son de otro planeta:

El sistema que Google está construyendo se llama Spanner, La meta de Spanner es soportar 10 millones de servidores, 1013 directorios, 1018 bytes de almacenamiento, extenderlo entre cientos y miles de localizaciones al rededor del mundo para aguantar 109 clientes.

El problema de las redes sociales es que los datos son muy activos: dependen de los usuarios y sus “amigos”, y al estar los usuarios siempre activos, los datos son escasamente cacheables y su recuperación altamente problematica. Si a esto le sumamos la cantidad de usuarios que puede llegar a tener una red social exitosa, hace que me plantee lo siguiente: ¿vamos por el buen camino?

Últimamente se habla mucho de la nube o el cloud computing, pero el planteamiento que a veces se plantea para mí no es el más correcto: desperdigar mi aplicación por Internet (mi aplicación en mi servidor, la BD en Google y las imagenes en Amazon). Yo no estoy en contra de la nube, ni mucho menos, pero quizás en vez del planteamiento guay2.0 que a veces se le da, se podría replantear de distinta forma: el P2P. ¿Por qué es necesario que toda mi información, amigos, fotos y vicios estén en Facebook si no tengo necesidad de ello? En Facebook hay 300 millones de usuarios activos y yo tengo 100 amigos (bueno, yo no tengo ninguno porque no uso Facebook, pero esta es otra historia), eso es el 3×10-5% de la capacidad de Facebook. ¿De verdad necesito Facebook?.

¿Qué idea absurda planteo? La comunicación e intercambio de información entre webs y no entre usuarios. Es decir, yo tengo mis datos en un servicio, y este servicio comparte los datos con un protocolo parecido al P2P (el W2W) con otros servicios (ya sea el mismo u otros distintos). El servicio puede ser Facebook, Twitter, mi propio servidor o blog, una aplicación que tengo en el ordenador conectado todo el día, mi móvil de ultimísima generación, el Kindle, el netbook o una web genérica que se encarga de almacenar mis datos y fotos para que esté siempre online. Cuando yo me conecto a mi servicio y quiero ver lo que han escrito mis amigos o ver sus fotos, mi servicio lee mi lista de amigos (desperdigados en cientos de servicios) y accede a los servicios de cada amigo para recuperar la información. ¿Qué posibilidades ofrece el P2P? que si los datos no los tengo disponibles, se puedan recuperar de otro cliente. En el W2W sería igual, si mis datos no están disponibles porque mi servicio está caído, que se puedan recuperar mis datos de mis amigos, siempre que los permisos lo permitan (ambos son amigos míos o mi perfil es público).

w2w.png

¿Qué se gana con el W2W?

  • No tengo que darme de alta en Facebook porque tenga un amigo que está registrado y es allí donde comparte sus fotos, mi servicio se conectará a Facebook para recuperar sus fotos.
  • No hay necesidad de grandes aplicaciones con necesidad de soluciones drásticas de escalabilidad porque la información se reparte en muchos nodos/servicios.
  • Puedo seguir a mis amigos de Twitter desde otro servicio de microbloggin que me guste más
  • No hay necesidad de registrarse en cientos de aplicaciones para poder estar conectados con todo el mundo
  • Sería algo abierto y distribuido

Quizás a muchos les chirríe esta idea, sobre todo ahora que parece que el futuro está en tenerlo todo en la web, pero viendo la situación actual, los cientos de millones de dólares gastados en datacenters, los problemas de rendimiento de Twitter, los cambios de políticas de privacidad de Facebook, y otras historias, creo que mi idea, a parte de absurda, puede tener algo de futuro.

Aunque el término W2W es algo que me acabo de inventar, no sé si a alguien se le ocurrió lo mismo antes que a mi, no pretendo ser innovador ni original, así que si a alguien conoce algún post que diga lo mismo, por favor que me lo envíe.

Por cierto, interesante web que plantea algo similar para crawlear webs: 80legs.

|

Scale-out vs Scale-up

ByLuis

In this post I'll cover the difference between multi-core concurrency that is often referred to as Scale-Up and distributed computing that is often referred to as Scale-Out mode.  more.. Source: Scale-out vs Scale-up (http://www.dzone.com/links/r/scaleout_vs_scaleup.html) by Nati Shalom …

Post original

5 consejos para reducir la carga de la página enfocado a imágenes

ByLuis

Una cosa es realizar una aplicación o tener un blog y otra es que el número de visitas aumenten y tengamos que optimizar la carga de la página. Hay que intentar ganar rendimiento de cualquier forma, y una de estas formas es mediante imágenes, por eso estos consejos (que quizás sean un poco obvios) no vienen mal:

  • Evita usar imágenes complejas o grandes: cuanto más ligeras sean antes cargarán.
  • Optimiza las imágenes: existe diferentes formatos, y cada cual es conveniente en un caso. Los más usados son GIF, PNG y JPEG. JPEG y PNG tienen un valor de calidad de la imagen, reducirlo puede hacernos ganar algunos Kb y no perder en calidad.
  • Indica el tamaño de las imágenes en el HTML: así el navegador sabrá como repartir el espacio para la imagen antes de que cargue por lo que el render de la página será más rápido.
  • Precarga imágenes: aquí el autor dice un consejo un tanto peculiar, no sé si bueno o malo, pero sí interesante. Se trata de cargar imágenes grandes en páginas anteriores y asignarle el tamaño 1×1 para que no se vean y así esté cargada anteriormente. Eso sí, forzaría a que tire de caché para que no te la cargue dos veces.
  • Animaciones flash: si tienes que usar una animación no uses GIFs animados (sí, algunos te encuentras aún), usa flash, pero tampoco te pases.

Top 5 tips to decrease the load time of your websites via images

| |

Laboratorio: área clientes mediante Apache y PHP

ByLuis

Viendo diferentes empresas con página corporativa, he visto que suele ser común el área para los clientes. En este mundo es normal que el tema de los pagos suela dar complicaciones, por eso yo creo que es preferible subir lo que se va desarrollando para el cliente en un servidor propio que en el servidor del cliente, ya que hasta que no pague en su totalidad, no dispone de ello.

Si te encuentras en esta situación, quizás te sea útil este truco para habilitar una área privada protegida para los clientes, la cual redireccionará al contenido del cliente, ya sea el propio trabajo en sí o una aplicación en particular.

Para el caso del ejemplo, yo lo he hecho para unas páginas web estáticas, y luego que cada cual, si le interesa, que lo adapte a su gusto.

El funcionamiento es el siguiente: el usuario accede a una ruta con acceso restringido a usuarios válidos mediante Apache. También mediante Apache se le redirigirá a una página propia, en este caso las páginas HTML que están guardadas en un directorio específico para clientes (fuera del webroot) y en un directorio específico para ese cliente en concreto.

Supongamos que tenemos el directorio webroot siguiente home/www y el área web de clientes está en el directorio home/www/clientes y el espacio físico específico de clientes está en home/www/_clientes. Lo primero que debemos hacer es añadir el siguiente .htaccess en el directorio clientes.

AuthType Basic
AuthName "Acceso a clientes"
AuthUserFile [path]\passwords.conf
Require valid-user
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/clientes(.*)$
RewriteRule ^(.*)$ /_clientes/index.php?url=$1  [L,QSA]

Lo que hace esta configuración es añadir autenticación al directorio clientes y redireccionar al script index.php del directorio _clientes, pasándole como parámetro la url a la que se accede.

El script index.php para este ejemplo, lo que he hecho ha sido incrustar el fichero que se quiere directamente, teniendo en cuenta el Content-Type y que si no se añade ninguna url después de clientes se tome por defecto el fichero index.html.

<?php
// Devuelve el content-type
function content_type($url) {
$ext = substr($url, strrpos($url, '.')+1);
if ($ext == 'swf') {
header("Content-type: application/octet-stream");
} else if ($ext == 'png') {
header("Content-type: image/png");
} else if ($ext == 'jpg') {
header("Content-type: image/jpeg");
} else if ($ext == 'gif') {
header("Content-type: image/gif");
} else if ($ext == 'js') {
header("Content-type: text/javascript");
} else if ($ext == 'css') {
header("Content-type: text/css");
} else if ($ext == 'html') {
header("Content-type: text/html");
} else {
header("Content-type: text/plain");
}
}
// Obtengo el usuario y la ruta a la que quiere acceder
$user = $_SERVER['REMOTE_USER'];
$url = substr($_SERVER['REQUEST_URI'], strlen("/clientes"));
$url = $url == '/'? '/index.html' : $url;
// Añado el content-type
content_type($url);
// Inserto el fichero
if (file_exists('./'.$user.$url)) {
include './'.$user.$url;
}
?>

Por supuesto a este truco le faltan cosas, como seguridad en el directorio _clientes, a parte de que hay que tener cuidado con los paths relativos o absolutos, y alguna cosilla más, pero creo que como idea desde la que partir no está mal.