Otro compa que leyó el post anterior me hizo notar que hago demasiado enfasis en “defender” a java, y tiene razon.

No quise editar el post sino hacer un edit o en este caso hacer otro post (para aquel par de personas que lo hayan leido ja) comentando que mi intencion original era causar un poco de discusion y escuchar argumentos acerca de preferencias de tales lenguajes, no tanto “mostrar desprecio sobre PHP” ni “defender” tanto a java.

Sigo pensando que cualquier lenguaje es mejor para el proposito hacia cual fue diseñado; extraño java, pero no le “hago el feo” a PHP.  De hecho, me siento mas comodo con PHP por razones de familiaridad en estos momentos; ojala algun javero pudiera postear algun comentario, pero creo que este blog ya esta un poco empolvado.

Hablando con un compa, acerca de que si PHP es mejor que java, o viceversa, se hizo un interesante y largo tema de discusión, que tal vez sea bueno como tema alrededor de cerveza ( entre geeks tal vez ).

Todo comenzó con la pregunta: es java más rapido que PHP?

No es mi intención defender indiscriminadamente a java, por el hecho de ser el lenguaje que más llegue a conocer, ademas de C++, pero tenia que postear mis comentarios al respecto, y se acepta cualquier comentario.

Personalmente, la conclusión final es que java si es mejor y más rapido de PHP, si se saben aprovechar los recursos, y hablando de manera genera. Java tiene estándares bien definidos, cosa que PHP esta “muy verde” todavía, aún en su version 5; ambos funcionan sobre un motor que los hace multiplataforma; ambos son “hijos de C” ( aunque PHP para mi es como un tataranieto de C );

Pero para fines prácticos, puedo decir que cada lenguaje es mejor dependiendo del uso que le quieras dar: por definición, PHP es un scripting language, mientras que Java es un Lenguaje de programación orientado a objetos. PHP no nació para hacer aplicaciones, sino páginas personales o sitios pequeños con el que su sintaxis te permita desarrollar rápidamente y con fácil mantenimiento. Java tiene estándares para desarrollo de aplicaciones multi-capas, soporte de varios servidores de aplicaciones, y hasta tiene su propio scripting language que forma parte de toda una aplicación.

Claro que, PHP es más rápido, si hacemos un script que te genere un par de objetos clases que te representen datos, guardamos los datos, los leemos, y los mostramos, y hacemos lo mismo con los estándares de java, en un benchmark se demostraría que PHP se ejecuta más rapido. Pero si implementas codigo por separado, con el patrón de MVC, en PHP, esa sería otra historia.

Y la verdad, uno diría, porqué tantos sitios “grandes” usan PHP, y mantienen su uso hasta ahora ? En lo personal, pienso que es por la misma razón que yo desarrollo en PHP: para desarrollar aplicaciones de una manera más rápida entre equipos moderados de trabajo, modificaciones rápidas y extremas in-situ, rápido mantenimiento y mucho soporte de foros y sitios en internet.

Al menos me mantengo tranquilo, sé que hay algun lenguaje por ahi esperándonos que nos pueda ser más útil en su momento.

Mi mákina sobrevivió, después de una larga lista de dias tratando de hacer un emerge –update –world –deep –newuse, causando errores siempre y dejando al final del dia el buscar cómo corregirlos, correrlo de nuevo y esperar a ver al dia siguiente.

Estragos: ahora mi X me saca de onda cuando quiero mover alguna ventanita un poco y me la manda a otro monitor ( tengo configurada mi ATI radeon X1300 con dual monitor ), mi tarjeta de sonido solo puedo subir el volumen con el master ( con el audacious no puedo controlar el audio ) y … es lo único que he detectado aún.  Al menos, todo el X funciona mejor, con el nuevo driver de la ATI parece que todos los gráficos se mueven más rápido, ya tengo openoffice de nuevo, ya pude instalar el k3b ( al finnn ), y todo esta como un linux recien instalado.  Sólo me falta recompilar el kernel y cargar el sistema con él.

1. El correo. En mi caso muy particular, me llegó a mi cuenta de gmail. El sistema de gmail tiene un bug que permite que los correos lleguen al inbox en lugar de que lleguen como spam. El truco consiste en tener un sistema de correo que cumpla la mayoria de las reglas que piden, pero la clave del bug es poner en el FROM del correo a no-reply@google.com o noreply-mail@google.com ( no se si funcione con @gmail.com ). Yo mismo comprobé enviandome un correo de un servidor, con este FROM en los headers, y efectivamente, me llegó a mi inbox. Parece que después de 1 mes, no han arreglado este bug.

2. Conseguir un dominio parecido al de algun banco, o que parezca legítimo. En mi caso, me llegó un correo de data-exchange.co.tz/boa/ssl/online , pero para los que sabemos, de inmediato te das cuenta que no estas en un sitio con ssl ( obviamente no dan certificados para sitios fraudulentos ). En el otro caso ( no recuerdo si clamaban ser bank one o bank of america ), utilizaban en el URL la IP en hex, de manera que la gente “normal” no pueden darse cuenta de la ip o dominio en sí. Como ejemplo, saca la IP de youtube.com que en mi caso me resolvió a 208.65.153.238. Convirtiendo estos en hex, te da D0 41 99 EE, con lo que puedes entrar al sitio como http://0xd04199ee/ , de manera que puedes confundir al usuario. Ese es el primer paso.

3. Copia del diseño. En ambos casos el diseño era una copia fiel del sitio al que trataban de fraudar. Mismos logos, mismo layout, mismos fonts, mismo todo ( recordé las veces que hice esto para obtener algunas cuentas de hotmail ). Los usuarios “normales” de internet creen todo lo que ven, y si se sienten como en el sitio “original”, ya v….

4. Acceso. De entrada, los sitios piden los datos de acceso a la cuenta de internet. Yo al no tener una cuenta en ese banco ( y aunque la tuviera ) le inventé cualquier cosa como login y pass ( digamos phised / user ). Cualquier cosa que le pongas a esta página de acceso, magia!!! te deja entrar. Para los usuarios “normales”, esto es parte del procedimiento, y meten su login y pass actuales. Para el defraudador, ya tienen una pieza ganada: el acceso del usuario al sitio del banco. Además de todo, el login y pass se guarda en sesión en el servidor, más adelante sabrán para qué ) .

5. “Actualización de datos”. Voilá! Despues de hacer login con datos fantasmas, te dice que has entrado al sistema, y sobre el problema que ha sucedido en tu cuenta, o cuentas, o el sistema, o pueden inventar miles de cosas, pero te piden que porfavor actualices tu información. Te piden nombre, dirección, teléfono, obviamente tu numero de tarjeta, y … si!!! tu numero de verificación de tu tarjeta!! jajaja ( esos tres numeritos que te piden cuando haces una compra ). Con el número de tarjeta, numero de verificación y dirección ya los usuarios “normales” les regalan cualquier compra que puedan hacer por internet. Eso es lo mas gacho.

6. “Gracias”. Ajá. ( Gracias por regalarme tu dinero, tus cuentas, tu dirección, acceso a tu cuenta bancaria y, para usuarios “normales”, acceso a su im, hi5, blog, myspace, o cualquier otras cuentas que puedan tener, ya que usan el mismo password para todo ). Y gracias, y que esto es para prevención de fraude o cosas extrañas, blablabla, un botón para continuar.

7. Lo mejor de todo, después de tanto meterle tanto a la mente del usuario, con el user y pass que traes en sesion, despues de clickear el botón de ‘continuar’, haces un post al sitio auténtico, y si el login y pass fueron puestos bien a la primera, el POST te autentifica en el sitio real, metiendote a tu cuenta de verdad, haciéndote creer que todo lo que hiciste fue, de verdad, algún procedimiento del banco.

Esta vieja “técnica” se llama phishing, e incluso hoy en día se aprovechan de vulnerabilidades tecnológicas y la credibilidad de los “users”. La mejor manera de evitar estos fraudes, es orientar a los usuarios “normales” a aprender a no creer todo lo que ven en internet, al menos a los usuarios que nos importen. Simplemente que no metan informacion por internet de algun sitio que lleguen de repente ( si van a entrar al banco, que SIEMPRE escriban el URL del banco directamente en el browser ). Que siempre observen que cuando estan metiendo información, hay un https ( con S ) en el URL, o el candadito que indica que estás con ssl.

PHP originalmente era el acrónimo de Personal Home Page, lo cual nos puede hablar no muy bien de este lenguaje para desarrollo de aplicaciones web o sitios de dimensiones considerables. Ahora, parece que le cambiaron el significado al acrónimo recursivo “PHP: Hypertext Preprocessor”. Cual sea el significado, ha evolucionado bastante, al grado de tener su propio ‘engine’ ( zend ) al estilo de VM, y diseñado para poder desarrollar orientado a objetos, de una manera mas avanzada ( PHP 5 ). Despues de ver varios debates sobre PHP y otros lenguajes, quedé de acuerdo con que PHP aun le falta mucho para mejorar su API, tienen muchas inconsistencias en su nomenclatura de funciones, puedes enredarte un poco al estar depurando si tienes que estar siguiendo archivos que estan incluidos como locos, o puedes volverte loco al depurar un script que tenga todo mezclado ( base de datos, logica, diseño, evaluacion de formas, etc ), aunque esto puede suceder en cualquier otro lenguaje ja!.

Lo bueno de PHP, es que como decía, con bastante soporte, ya hay funciones para todo ( casi les falta funciones como fart( ) o getCoke ( $flavor ) ), soluciones para casi toda situacion, estan las librerias PEAR, y mucho soporte de PHP en foros y su propio sitio web; aunque esto ultimo de forosy tips y ejemplitos pueden ser en algunos casos malos, por enseñar practicas no-muy-buenas. Pero bueno…

El caso es que a como está PHP en este punto, se pueden hacer DAOs, los cuales son patrones de J2EE, pero igual, se puede implementar como muchos otros patrones. El detalle es, es bueno implementarlo? Uno de los detalles que vi en los debates PHP/Java, es que PHP termina siendo mas rapido ( hasta comprobado con benchmarks ), puesto que tienes la logica de base de datos, logica de negocios e interfaces de usuarios muy unidos entre si; aunque pueden estar separados por clases, todo se incluye y queda donde mismo, se compila el script, se ejecuta y voilá; en java tenemos que si son llamadas de RMI, que se tienen que crear los objetitos, los POJOs, llamar a la otra capa, la cual tiene que regresar la info, populando arreglos de los objetitos, y despues utilizarlos en algun controlador, para despues poderlos utilizar. Ok, esta bien organizado, pero segun tiene el overhead de hacer todo esto. Volviendo al detalle de los DAO, si se implementa en PHP, podemos caer en lo mismo: tienes una clase DAO que te envuelve las llamadas a base de datos de cierto tipo de objeto, otro objeto para conexion a base de datos, el controlador del objeto, para esto tenemos los objetitos ( que en una pagina los nombraban value objects o VO, pero nosotros los bautizamos como POPOs ), y sobre esto el manejador de lo que estamos haciendo, y sobre esto el script para el cliente que a su vez manda llamar el generador de templetes ( smarty ) … aaaargh :s …. caes de nuevo en J2EE, pero mas bien seria algo como PHP5EE jaja. Entonces, resulta esto peor que manejar PHP de la manera ‘clasica’? la ventaja de hacerlo asi, es que tienes la flexibilidad de cambiarlo todo y re-juntar muchas de las cosas sin perjudicar tiempo de desarrollo ni caer en errores criticos que te consuman tiempo y que les salgan al usuario final.

Pero ese es el dilema por el momento, y en verdad no he encontrado mucha informacion acerca de si es mejor o no, algunos dicen que no es bueno hacer “java” en PHP, mientras otras partes dicen que PHP esta lo suficiente maduro para esto y mas … seria bueno saber opiniones y comentarios