PHP vs RoR

Hoy encontre unos graciosos videos donde la gente de ruby, se roba (literalmente), la idea de la publicidad Mac vs PC.

En estos videos se habla de lo simple que es usar ruby y como genera envidia en la gente de PHP.

Aca voy a subir los videos comparando RoR con PHP, pero hay varios, comparandolo incluso con .net.
Veremos quien sigue en pie en 10 años ;).

Obviamente nunca hay que aferrarse a un lenguaje, hay que aprender y conocer distintas tecnologias para nosotros decidamos cual es nuestra mejor alternativa.

Es gracioso que el gordito de PHP, use la remera de cake, porque es un framework que esta basado en PHP 4.

Otro punto tambien es en el segundo video hace alarde del uso de MVC, cuando en PHP tenemos Zend y otros framework que trabajan sobre este patron.

Ruby es Ruby gracias a su Framework, Ruby on Rails y que es un lenguaje POO puro, basado en la idea de Smalltalk. La idea de diseñar aplicaciones 2.0 de fomra rapida y efectiva es muy tentador. El codigo es bastante simple he intuitivo, pero con esto no estoy desmereciendo a PHP, sino que seria bueno tomar de Ruby lo mejor de èl, con PHP5 el codigo es mas claro, con Zend y otros, conseguimos trabajar en MVC de manera limpia. Hay una tendencia que dice que PHP va bien, y estara mejor.

Y si ruby anda bien, en dos años me estare comprando mi primera Mac Pro, y dejare Zend Studio para usar RadRails :P.

Scaffolding en Zend Framework

El otro día tratando de encontrar si había algún proyecto de implementar la técnica de Scaffolding que tanto trabajo nos quita a los programadores. Me encontré con que existe un componente creado por la gente de Zend que si bien aun esta en desarrollo (Zend_Controller_Fron_Scaffold ), seguramente pronto podremos contar con el para implementarlo en nuestras aplicaciones. En PHP el scaffolding lo implementan el framework: CakePHP, y Symfony.

Encontré una definición en el blog de Carlos Leopoldo que nos va a orientar que es esta técnica:
"La palabra Scaffold está en inglés y en español significa Andamio, pero en programación el scaffolding es un método para contruir aplicaciones basadas en bases de datos, esta técnica está soportada por algunos frameworks del tipo MVC en el cuál el programador escribe una especificación que describe cómo debe ser usada la base de datos. Luego el compilador utiliza esa especificación para generar el código que la aplicación usará para crear, leer, actualizar y eliminar registros de la base de datos, esto es conocido cómo CRUD (create, read, update, delete).El Scaffolding fue popularizado por el framework Ruby on Rails y ahora es utilizado por otros frameworks también cómo CakePHP, Symfony.".

Entendiendo el modelo de Objetos en PHP5

En el blog de Sebastian Bergman, encontré un documento titulado "Understanding the PHP Object Model" ( 'Entendiendo el modelo de objetos en PHP'), esto esta basado obviamente en PHP5. Si bien esta en ingles, hay mas código que texto, y creo que esta mas que claro. Los que sigan trabajando con PHP4, van a notar muchas cambios con respecto a su código. Y la verdad que PHP4 no se podía considerar Orientado. PHP5 es una evolución notoria en este aspecto. Si bien todavía nos falta un camino, el lenguaje evoluciono bastante. Ahora faltan algunos detalles, algunos se van a agregar en la versión de PHP6 que son el manejo de paquetes, y otros probablemente vendrán pronto.

Bueno les dejo el documento para que lo disfruten

| View | Upload your own

Steve Jobs - 3 Historias

El discurso es un poco viejo (2005), pero me gusto mucho en su momento, y mas viniendo de un personaje tan importante como uno de los fundadores de Apple, el discurso esta dividido en dos partes, en la primer parte van a tener las dos primeras historias y en el segundo video la tercer y ultima historia.

Es algo que vale la pen ver, o re ver para los que ya lo vieron


Primer video



Segundo Video

Trabajando con subversion ( tutorial )

Ampliando la info que di en un post anterior sobre svn.

Voy a incluir un tutorial, bastante completo sobre svn, con todos los comandos, y la adminsitracion de un svn no solo el uso como programadores.

| View | Upload your own

Action View Helper

Muchas veces vamos a necesitar ejecutar mas de un modulo dentro de un modulo.
Supongamos que tenemos el modulo home. El cual esta dividido en varias secciones, mostrar Banners, modulo de registro, modulo de login, modulo de ultimos comentarios, etc.

Si queremos ejecutar un controlador desde un modulo distinto. Tenemos que usar "Action View Helper", con solo ejecutar desde la vista una linea vamos a ejecutar ese controller y mostrar la vista. Dentro de la vista de nuestro modulo principal.

Por ejemplo:
para mostrar el modulo de registracion vamos a tener que poner esta linea en nuestro view, del home
1
<?php echo $this->action('formulario', 'index','registracion'); ?>



Quedaria asi, con algunos modulos agregados

1
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
2 <html xmlns="http://www.w3.org/1999/xhtml">
3 <head>
4 <meta http-equiv="content-type" content="text/html; charset=us-ascii" />
5 <script type="text/javascript"> var size=11;</script>
6 <link href="<?php echo $this->baseUrl; ?>/html/styles/estilo.css" rel="stylesheet" type="text/css" />
7 <link rel="stylesheet" href="<?php echo $this->baseUrl; ?>/html/styles/moodalbox.css" type="text/css" media="screen" />
8 <script type="text/javascript" src="<?php echo $this->baseUrl; ?>/html/clientScripts/mootools/mootools.js"></script>
9 <script type="text/javascript" src="<?php echo $this->baseUrl; ?>/html/clientScripts/mootools/fvalidator.js"></script>
10 <script type="text/javascript" src="<?php echo $this->baseUrl; ?>/html/clientScripts/mootools/moodalbox.js"></script>
11 <title>Mi Web</title>
12 </head>
13 <body>
14 <div id="header"><!-- Cabecera -->
15 <h1 class="titulo1" title="titulo de mi modulo">Este es el titulo de mi modulo</h1>
16 </div>
17 <div id="menu">
18 <ul class="menu">
19 <li>Home</li>
20 <li>Foro</li>
21 <li>Blog</li>
22 <li>Registrate</li>
23 <li>Ingresar</li>
24 </ul>
25 <?php echo $this->action('listar', 'index','autentication'); ?>
26 </div>
27 <div id="contenido">
28 <div id="registracion"><?php echo $this->action('formulario', 'index','registracion'); ?></div>
29 <div id="ultimos_post"><?php echo $this->action('top10', 'index','foro'); ?></div>
30 </div>
31 </body>
32 </html>


Parametros de Action View Helpers.

$this->action(action, controller, module, arrayParameters);

* action: Es la accion del Controlador que vamos a ejecutar.
* controller: nombre del archivo del controller.
* modulo: puede o no ser necesario, nos sirve para especificar sobre que modulo estamos hablando en mi caso todos los modulos tienen un indexController, para que me funcione si o si tengo que indicar el modulo.
* arrayParameters: Podemos enviar parametros a nuestro controllers, se lo enviamos en un array.

Edito y agrego algo importante, como obtener los parametros que enviamos por array al controller. Para eso tan solo tenemos que desde nuestro action $this->getRequest()->nombredelindice por ejemplo si enviamos un array como el siguiente:

array("nombre"=>"Juan")

Desde el controller lo tomamos asi:
$this->getRequest()->nombre

Es bastante facil de implementar.

Espero que les sirva saludos.

El patrón MVC.

Esta muy de moda este patrón ya que la tendencia a usar framework esta aumentando y generalmente los frameworks usan este patrón para resolver la arquitectura del proyecto. Si bien MVC tiene una definición supuestamente clara. Hay muchas incertidumbres en torno a este "patrón", la verdad es que hay mucha info y mucha de es info confunde mas de lo que explica. Hoy visitando foros del web, en la sección de php orientado a objetos, encontré 3 thread sin leer desde mi ultima coneccion, que en el titulo tenían las siglas MVC. En dos de esos thread habia un usuario que respondía sobre este tema y dio una explicacion, a mi forma de ver excelente y precisa de lo que significa MVC en un entorno web. El ejemplo que da sobre la cocina es increíblemente preciso. Me ilumino, y todos esos fantasmas que me rodeaban a través de MVC desaparecieron.

Quiero compartir en este blog el post enviado por venkman, en foros del web.


Lo aclaro:

1. Arquitectura vs. patrón
Como ya dije en otro mensaje, MVC no es una arquitectura. Es un patrón de diseño. En su origen se aplicaba como patrón de diseño, para solucionar un problema concreto, no para establecer la arquitectura completa de una aplicación como dice.


2. MVC: Qué soluciona.
MVC es un patrón, como más o menos explica el comentario, que soluciona la separación entre 3 preocupaciones existentes en el problema de hacer que un usuario interaccione con algún objeto de la aplicación. Las 3 partes son:
- Por un lado está el concepto, el objeto que queremos manipular. En una aplicación que gestiona una cocina automatizada, por poner un ejemplo, esto sería la propia cocina, con sus características, sus funcionalidades y aparatos.
- Por otro lado está la visualización del estado de la cocina. A qué temperatura está el horno, qué presión hay en las ollas, qué calor está produciendo el fuego, cuánta agua hay en... Todo eso necesita monitorizarse, visualizarse de algún modo.
- Por último el cocinero, debe poder manejar la cocina. Así que habrá un dial para aumentar o disminuir la potencia del horno, otro para establecer la temperatura del termostato, un mecanismo que tape o destape las ollas, que ...

Así que separamos nuestro problema en 3 partes:
- El modelo representa la cocina en sí.
- Las vistas serán los diversos indicadores que tengamos para ver el estado del modelo.
- Los controladores serán los diversos mecanismos, actuadores, etc, que tengamos para actuar sobre el modelo.

Es muy importante notar que este es el único aspecto que soluciona el patrón MVC. En la cocina existirán otros muchos aspectos a tener en cuenta. ¿El modelo necesita acceder a los alimentos para cocinarlos? Claro, pero ese es otro problema. ¿Debemos impedir que alguien no autorizado pueda manejar los controles? Por supuesto, sólo el cocinero debe poder... pero de nuevo es otro problema distinto. MVC no se ocupa de esos aspectos de la aplicación.


3. Patrón
Ahora hay que parar un momento y pensar qué es eso de un patrón. Ya arriba decía algo, que no es una arquitectura. Bien, pero ¿qué es?
Un patrón es la suma de estas cosas:
Una situación (1) conocida en la que tenemos un problema (2) que solucionar, y una forma de solucionarlo (3) que sabemos que es apropiada para ese problema en esa situación.

La situación abarca todo el entorno de definición de nuestro problema, que a su vez es la preocupación que queremos poder manejar. La solución debe ser, por encima de otros aspectos, una que sabemos que es apropiada para ese problema en esa situación. Y ojo, porque es importante la parte de "en esa situación".


4. Problemas con el entorno web
El problema principal de aplicar la solución que propone MVC al entorno web, es que ya no es la misma situación que la definida en el patrón. Hay algunas diferencias importantes.
La más importante de todas es que la vista no puede ser activa (salvo haciendo mucho mucho esfuerzo). Esto es una pega porque para realmente poder separar las tres partes M, V y C (que es lo que busca el patrón, la separación de responsabilidades) la vista debe poder recibir o percibir los cambios que se produzcan en el modelo. La vista debe ser como una grabación en video, algo que permanentemente extrae (o lo recibe) el estado del modelo.

En web -y quitando como decía antes hacer muchas "trampas"- esto no es posible. La vista no puede monitorizar el modelo. La vista sólo se actualiza cuando lo decide el usuario (cuando hacemos click en algo).


5. Variaciones sobre un mismo tema
Sin embargo, el objetivo de separar las responsabilidades sigue siendo un objetivo interesante. Por eso mismo se han buscado ciertas variaciones sobre el patrón MVC. Lo que ha ocurrido, tras diversas iteraciones, es que lo que ahora mucha gente llama MVC ya no es lo mismo que lo que se llamaba MVC originalmente. En buena medida a esto ha contribuido Sun con un documento en el que no supo elegir mejores nombres que "Model 1" y "Model 2". "Model 2" es lo que básicamente se conoce como MVC cuando hablamos de entornos web.


6. Problemas con las personas
Las personas, todos vosotros habitantes de este planeta (xD), tienden a dar nombres a las cosas para ganar ventaja sobre ellas. Se da nombre a lo que se desconoce para hacerlo más conocido y familiar, se da nombre a lo que no se sabe cómo llamar para poder así comunicarlo a otras personas. Con MVC ha ocurrido esto de una manera muy notable. "Model 2" es un nombre estúpido. más aún cuando "Model 1" es uno que nunca nadie va a querer usar intencionadamente salvo para decir "No lo hagas según el Model 1". Así que alguien empezó a asociarlo con el MVC. Porque sí, tiene cierto parecido. Así se ha terminado llamando MVC a varias cosas distintas.


7. Sobre la validez de la conclusión
Efectivamente MVC, el original MVC, no es apropiado para aplicarlo en web. Pero sin embargo hay una serie de detalles que el artículo equivoca.

• No hablamos del MVC-original, sino del MVC-Model 2. Como tal, tendrá sus ventajas e inconvenientes, pero claramente sí es aplicable en el entorno web.
• No hablamos de una arquitectura, sino de un patrón. Las aplicaciones web tendrán una arquitectura determinada y, para algunos de sus problemas, podrán o no, aplicar unas soluciones u otras. Usar un Singleton, una AbstractFactory o una Estrategia, no hace que tu arquitectura sea Singleton, AbstractFactory o Estrategia. (*)
• MVC no se preocupa en absoluto por la persistencia del modelo. Esto es algo completamente independiente y ajeno al patrón MVC.
• MVC no es exclusivamente para entornos de bitmaps. En absoluto. Ha sido perfectamente aplicado en otros ámbitos.
• Todo esto está muy bien si lo miramos desde un punto de vista rígido, pero las normas están para 1. conocerlas 2. respetarlas y 3. saber cuándo romperlas y con qué consecuencias. Si nos quedamos únicamente en los puntos 1 y 2, nunca se produce el progreso. El avance, el progreso del conocimiento, la técnica, la tecnología, la ciencia, sólo ocurre cuando conociendo las reglas establecidas sabemos cómo romperlas, por qué romperlas y qué consecuencias tiene hacerlo. El progreso se produce entonces cuando, conociendo esas consecuencias, las aceptamos las desventajas a cambio de las ventajas que nos pueda aportar.

En fin, lo más importante de todo esto es ese último párrafo en plan filosófico (xD) y el primer punto de todos: No confundir patrón con arquitectura. La arquitectura define toda la organización y estructura de nuestra aplicación. Un patrón sólo define una estructura para un determinado aspecto de la aplicación o para solucionar un determinado problema.




(*) Se me ocurre una situación muy posible, que es la de implementar dentro de una misma página, con Javascript, una parte del modelo, o un modelo de presentación y que ahí apliquemos el patrón MVC. Es perfectamente aplicable en ese caso el MVC original.




Enlaces: Post Original
Enlaces: Foro de PHP Orientado a Objetos.

Trabajando con subversion

Cuando se habla de teletrabajo o trabajo en grupos en programacion, generalmente se habla de un control de versiones, para que los programadores no pisen el trabajo de otros, y no necesiten usar el ftp constantemente para editar algo. Tambien resulta muy importante para liberar una versión estable y seguir trabajando en una versión de prueba, o para recuperar versiones de los archivos, es común que alguien cambie algo y resulte que ese cambio no era correcto, y si lo era el que estaba antes, con el versioando solo tendríamos que volver a una versión anterior.

Recuerdo hace un tiempo entre en una empresa que trabajaba con CVS, había leído algo al respecto pero no me había metido en el tema. En ese entonces el entorno de trabajo era un windows 98, y usabamos winCvs para el control de versiones, eramos 5 programadores, 3 en Argentina y dos en USA. Y el trabajo era totalmente coordinado, si tuvimos 3 problemas con pisadas de archivos estoy exagerando, y en los casos que paso algo fue error de algún programador ( yo me mande dos de esas tres :P ).

CVS quedo un poco en el tiempo, ahora se habla sobre SVN que es una versión mejorada de este sistema.
El mecanismo del svn es simple. Se crea un repositorio el acceso al respositorio puede ser publico o privado, una vez creado el repositorio en el servidor, es necesario que se haga un checkout por única vez, para configurar todo el entorno de trabajo. Una vez hecho el checkout solo tenemos que hacer commit para agregar cambios al repositorio y que otro se lo pueda actualizar, y update para actualizar dependiendo de los cambios que tenga el repositorio.

Cabe aclarar que cuando uno hace un svn update, o svn commit no se suben todos los archivos, sino únicamente los que tienen cambio, previamente comparando que no haya versiones posteriores a las nuestras en dicho caso nos va pedir que hagamos un update antes de hacer el commit. Otro dato importante es que los commit solo se hace sobre los archivos que están en el repositorio, si nosotros creamos un archivo localmente y queremos subirlo al repositorio para que este dentro del control de versiones primero agregamos el archivo al repositorio y despues hacemos el commit.

SVN desde Linux.

En los ejemplos yo estoy usando Ubuntu.

Lo primero que tenemos que hacer es conseguir la url de algún repositorio para probar podemos usar uno de prueba de google code tienen el buscador de proyectos, pueden elegir cualquiera y van a la solapa de source, y copian en el porta papeles ( ctrl + c ) la url del sistema

Supongamos que nuestro locahost, apunta a /var/www/. Desde la consola vamos hasta esta carpeta. Una vez en este path escribimos el siguiente comando para hacer nuestro primer checkout.

$ sudo svn co http://dominiodelrepositorio.com nombre_carpeta_proyecto

Cuando damos enter nos pueden salir 3 errores.

1- Error 1: Que el svn no esta instalado, para solucionar esto desde nuestra consola escribimos la siguiente linea

$ sudo apt-get install subversion

Este ejemplo es para los paquetes .deb para los rpm tienen que consultar como instalar SVN.

Una vez instalado volvemos a ejecutar nuestra linea para hacer el checkout.

2- Error 2: Que el repositorio no exista, vamos a chequear la url. Si este es el caso, es porque no existe esa url o no es un repositorio.

3- Error 3: Que la carpeta exista y contenga un proyecto subversionado.
En el caso que una carpeta ya contenga una versión de este o de otro proyecto no vamos a poder hacer el checkout, tenemos dos opciones, borramos la carpeta con todo su contenido, o guardamos nuestro proyecto en otra carpeta.

Sino surgió ninguno de estos errores, la consola tendría que mostrar que esta descargando archivos, y al finalizar nos tiene que decir la versión del sistema.

Una vez finalizado el checkout controlamos que nuestro proyecto este funcionando. Es probable que tengamos que configurar los datos de la base de datos que use el proyecto para que funcione correctamente, en este caso configuramos lo que sea necesario, y en localhost/proyecto/ tendríamos que ver el contenido.

Ya deberíamos tener el proyecto corriendo en nuestro sistema sin ningún problema.

Agregando cambios.

Después de revisar un poco el código se dieron cuenta que había un error, y deciden editarlo.
En forma local lo editan, con el IDE que mas le guste.
Una vez solucionado el problema, decidimos subirlo al repositorio para que el próximo que lo baje tenga el código corregido.

Para hacerlo nos posicionamos dentro del path del proyecto desde la consola

$ cd /var/www/proyecto/

Ejecutamos el commado commit, que podemos reemplazarlo por "ci". Y nos quedaría de la siguiente forma

$ sudo svn ci -m 'Corregimos un error en la carga de datos'

Hay un beneficio que no comente al principio sobre SVN, y son los comentarios de los cambios. Todos los cambios tienen la opción de enviarse con un comentario con una descripción de lo realizado. Esto es importante para controlar los diferentes cambios. Para agregar un comentario en un commit agregamos el parámetro "-m" y entre comillas el mensaje

Despues de ejecutar el commit el sistema nos tiene que mostrar por consola los detalles del commit, y nos devuelve la versión del repositorio actual ;)

Manteniendo actualizada la versión del sistema

Si necesitaramos actualizar el sistema solo tendríamos que hacer un update.

$ sudo svn up

Podríamos usar sudo svn update, pero para escribir menos podemos usar el alias up ;).

Si existen diferencias con nuestros archivos locales nos va a actualizar lo necesario.

Subiendo Archivos.

Para subir archivo solo tenemos que ejecutar la opción add.

$ svn add nombre_archivo_extendsion

Si el archivo no se encuentra en el repositorio lo va agregar, en caso contrario nos va a decir que el archivo ya se encuentra bajo control de versiones.

Podemos agregar una carpeta que contenga un grupo de archivos, y de carpeta, sin necesidad de agregar uno por uno.

Puede ser que consideren esto un poco cerrado ya que solo explico como trabajar desde linux, pero el problema es que con windows todo es supuestamente tan facil, que no deberías complicarles mucho esto. Tienen Tortoise que es una herramienta espectacular para trabajar desde windows ;), donde todas las acciones que hicimos en este mini tutorial lo tienen haciendo click derecho sobre la carpeta que tienen el proyecto.

Otro punto muy importante, es que la mayoria de los IDE decentes tienen soporte de control de versiones revisen la documentacion de su IDE para saber como configurarlo.

links relacionados: Configuracion, uso e instalacion de Subversion de Linux.

Zend_Json

Con esta librería vamos a poder codificar o decodificar objectos PHP en Javascript Object Notation y viceversa.

JSON se utiliza para intercambiar información entre JavaScripts y otros lenguajes. En nuestro caso PHP.

Si necesitan saber mas de JSON pueden consultar la Wiki.

El uso mas común que le vamos a dar es cuando pasemos datos por Ajax y queremos entenderlos desde PHP y poder enviar una respuesta clara,y liviana.

Un Objeto Json tiene una forma parecida a la siguiente:

{"nombre":"Pedro","apellido":"Moreira"}

También podríamos tener una matriz:
{"nombre":"Pedro","apellido":"Moreira"},
{"nombre":"Juan","apellido":"Saenz"},
{"nombre":"Carlos","apellido":"Perez"}

Para convertir esta cadena a un array PHP, donde se entienda a la cadena nombre, como índice de la primer posición de nuestro array, y "Pedro" como valor de nombre, deberíamos usar Zend_Json de la siguiente manera.

1  
<?php
2  $requestJson = $_REQUEST['json'];
3  $usuarios = Zend_Json :: decode ( $requestJson );
4  ?>


Con esta sintaxis vamos a obtener un array como el siguiente:

array ( 'nombre' => 'Pedro', 'apellido' => 'Moreira' );

Si quisieramos conseguir el resultado inverso, tendríamos el siguiente código

1  
<?php
2  $arrayPHP = array ( 'nombre' => 'Pedro', 'apellido' => 'Moreira' );
3  $usuarios = Zend_Json :: encode ( $arrayPHP );
4  ?>



Zend_Json es Abstracta por eso no la instanciamos en ningún momento, con solo cargarla desde Zend_Loader es suficiente.

1  
<?php
2  Zend_Loader::loadClass('Zend_Json');
3  ?>



Instalar un entorno de trabajo Web en Ubuntu.

Herramientas a instalar

- Maquina Virtual Java
- Eclipse PDT
- Xampp

Instalando Eclipse PDT

Eclipse es un entorno de desarrollo (IDE), se concibió como la versión linuxera de Visual Studio, a través de plugins, se puede trabajar en cualquier entorno, en nuestro caso Eclipse PDT, ya tiene los plugins de php configurados. PDT significa PHP Development Tools.

Antes de empezar a trabajar vamos a actualizar nuestro repositorio. Desde nuestra terminal ejecutamos.

$ sudo apt-get update

Después vamos a instalar la maquina virtual java, la cual es necesaria para correr Eclipse.

$ sudo apt-get install sun-java6-jdk



Descarga de paquetes de la maquina virtual Java

Una vez instalado la maquina virtual de Java vamos a descargar Eclipse PDT nos vamos a bajar la versión estable de la pagina oficial. Obviamente vamos a elegir la versión para linux. ;)

Cuando termine de descargar vamos a descomprimir todo el contenido en el directorio /opt que es el lugar que vamos a elegir para instalar todas nuestras aplicaciones.

Para descomprimir nuestro archivo en /opt dentro de nuestra terminal vamos a ir hasta la ruta donde hayamos descargado el archivo, que generalmente FireFox lo hace en nuestro escritorio en mi caso

$ cd /home/pablo/Escritorio

Una vez en el path del archivo tar.gz escribimos la siguiente linea en la terminal

$ sudo tar xvzf pdt-all-in-one-S20080505_RC1-linux-gtk.tar.gz -C /opt

Con esta linea le estamos diciendo que descomprima el archivo que bajamos en la carpeta correspondiente.

Una vez terminado la descompresión ejecutamos la aplicacion escribiendo la siguiente linea.

$ /opt/eclipse/eclipse

O vamos a la carpeta desde el explorador de archivos de Gnome, y ejecutamos el archivo eclipse.

Configuramos nuestro workspace, y listo ya tenemos eclipse corriendo en nuestra pc

Xampp

Nos falta lo mas importante. Nuestro servidor web!. Y para esto vamos a usar Xampp, que viene con todo lo que necesitamos para un servidor web con php. El paquete incluye Apache, MySql, php, phpmyadmin, y mas. Además tiene el mod_rewirte activado para que nuestras aplicaciones en Zend funcionen sin necesidad de configurar ningún parámetro extra.

La instalación es tan fácil como la de eclipse.

Descargamos el archivo tag.gz de la pagina oficial de Xampp

Desde una terminal una vez terminada la descarga ingresamos el siguiente comando

$ tar xvfz xampp-linux-1.6.6.tar.gz -C /opt

Al igual que con Eclipse instalamos Xampp en la carpeta /opt

Para correr nuestro servidor web, lo único que nos hace falta es ejecutar la siguiente linea:

$ sudo /opt/lampp/lampp start

y listo, vamos a nuestro browser escribimos en la barra de direcciones http://localhost, si el browser nos muestra la imagen de Xampp, ya tenemos 100% funcionando nuestro servidor web.

La carpeta donde se guardan todas las paginas web que vayamos haciendo es htdocs, dentro de xampp

Si quieren editar sus bases de datos mysql, pueden ir a la url http://localhost/phpmyadmin/

Y con esto terminamos de configurar nuestro entorno de desarrollo web.

También puede consultar este tutorial de configuración de eclipse PDT enlace