Categorías
PHP

¿Por qué programar en PHP?

Cuando se trata de encarar un proyecto en Internet, ya sea una aplicación compleja como un salón de chat, foro de discusión o carro de compras, las alternativas para desarrollarla son muchas y, cada implementador de tecnologías enumera una larga lista de «características únicas» que poseen sus productos.

El espectro de influencia de las aplicaciones web ya no se limita únicamente a la Internet.

El navegador web se ha transformado de hecho en la interfaz elegida para numerosas funciones comerciales.

En las empresas, se utilizan en una gran variedad de formas: como en las intranets, donde se provee el acceso a la información interna de la empresa, extranets, que se utilizan para interactuar con los clientes y, por supuesto, internet, a través de programas interactivos, como catálogos o sistemas e-commerce.

Este texto recomienda la utilización de la tecnología PHP, un lenguaje de programación Open Source utilizado para construir páginas web dinámicas.

Una página dinámica es la que interactúa con el visitante de forma tal que el mismo recibe información personalizada.


Este tipo de desarrollos son los que prevalecen en los sitios e-commerce, los cuales generan su contenido accediendo a bases de datos u otro recurso externo.

Los programas PHP (scripts) están embebidos en las páginas HTML de manera similar a la tecnología ASP (Active Server Pages de Microsoft Corporation) y JSP (Java Server Pages de Sun Microsystems).

Como estos últimos, PHP corre en el servidor web, contrariamente al JavaScript que lo hace en el navegador (browser) del cliente.

¿Porqué utilizar PHP?

Ante todo, casi sin publicidad, PHP existe en más de siete millones de dominios y está instalado en el 36% de los servidores Apache del mundo.

Desde la óptica de un programador estas son algunas de las razones por las cuales es tan popular:

  • Es fácil de usar y aprender (tiene una semblanza a los lenguajes C, C++ y Java)
  • Fue diseñado desde un comienzo exclusivamente para la web
  • Es ideal para crear páginas web interactivas
  • Es muy veloz
  • Guarda compatibilidad con otras tecnologías web claves como Java, COM, XML y Macromedia Flash
  • Soporta una innumerable cantidad de bases de datos (por ejemplo Oracle, MySql, Interbase, etc)
  • Es Cross platform. Esto significa que corre sobre Windows, UNIX, etc.
  • Es Cross web server. Se ejecuta sobre Apache, IIS, Zeus, etc.

El código fuente o binarios pre-compilados pueden bajarse de php.net y, como todo Open Source, es gratuito.

NOTA: Para utilizarlo comercialmente es muy recomendable leer la licencia.

Categorías
Programación

¿Debo utilizar el Código Abierto?

Cuanto más crece y se populariza en los negocios el Open Source (Código Abierto), y alcanza niveles definitivos, todos los productores de software se preguntarán a sí mismos «¿Debo utilizar el Código Abierto?».

Para esta gente la respuesta se encuentra en el valor comercial del código abierto, más que en la recompensa filosófica.

Las ideas fueron recopiladas de conversaciones y discusiones con expertos de la industria en la Convención Código Abierto de O’Reilly

Introducción

El Código Abierto tiene muchas ventajas sobre el tradicional modelo propietario, pero esto no significa que será ideal para cada producto de cada empresa. Construir una exitosa empresa de Código Abierto es muy complicado. Cambiar de un modelo propietario a uno de Código Abierto es aún más difícil. Exponer el código fuente es la menor de sus preocupaciones cuanto más se investiga el modelo comercial, se crea una comunidad y se cambia la naturaleza de su organización.

Las preguntas clave, problemas y desventajas a considerar al tomar la decisión son dadas a continuación. Usted comprobará rapidamente que la mayoría de éstas están relacionadas con su habilidad para construir y mantener una comunidad de desarrolladores y usuarios.

Usted conoce su empresa y su producto mejor que nadie. Utilice las descripciones de alto nivel dadas a continuación para determinar qué puntos requieren mayor nivel de atención en su caso.

Código Abierto es Buen Negocio

Sendmail y Apache son dos buenos ejemplos de proyectos con código abierto que son extremadamente populares. Construir productos y empresas sobre proyectos exitosos como estos le permite heredar un gran mercado compartido y construir una reputación existente. Un gran ejemplo de este tipo de negocio es la distribución Distribución Mandrake de Linux. Ellos tomaron un producto ya confiable, El Red Hat Linux y lo reorganizaron con diferentes características.

Usar un producto de código abierto como la base de su producto es similar a proveer una demostración gratuita o regalar el primer mes de servicio sin cargo. Estos métodos son efectivos porque las actualizaciones son más baratas que las nuevas ventas. De hecho, es beneficioso perder esos consumidores que realmente no quieren pagar por el producto, sobre todo porque ellos son los que requieren más soporte técnico.

Una gran base de usuarios le agrega valor a su producto, aún cuando ellos puedan no estar pagándole directamente. Muchos usuarios traen como consecuencia una gran cantidad de defectos descubiertos más rápidamente. Mejor aún, los usuarios de software gratuito tienden a ser más tolerantes de los problemas, o inclusive hasta llegan a arreglarlos por usted! El resultado final es un producto muy estable para los consumidores que lo pagan y una reputación enaltecida de su empresa.

Todo el movimiento y decir circundante al Código Abierto se debe al hecho de que abrir sus productos es Buen Negocio. Comparadas con las corrientes tecnológicas pasadas, el boca a boca del Código Abierto es accesible para todos. ¿Qué es más sencillo, cambiar su licencia de software, o reescribir enteramente su producto en Java? Al ingresar en este tren, existe una oportunidad de alcanzar el veloz ritmo y reputación rentable de los proyectos de código abierto, para su producto.

El buen nombre y el boca en boca se auto-perpetúan. Cada producto y empresa que adhiere al código abierto contribuye al ruido general. Agregar su producto beneficia al movimiento, el cual, a su vez, acrecienta los beneficios por los cuales su producto ha sido agregado en primer término. Los mismos beneficios surgen de las contribuciones a proyectos de código abierto, inclusive cuando estos no están relacionados con sus productos.

En mercados emergentes como el Linux, el beneficio del crecimiento de todo el mercado supera al de competir por una parte del mismo. Es por eso que los distribuidores de Linux se comportan bien entre ellos en esta etapa. Cuando un producto va alcanzando la saturación, la lucha por el el mercado se hace más dura. En este caso el código abierto puede usarse para socavar a sus competidores. Productos libres, de código abierto, pueden convertir a ciertas tecnologías en una comodidad. Si usted tiene una cierta superioridad teconológica por sobre sus competidores, puede lograr que los productos de ellos no valgan casi nada si renuncian al nivel de funcionalidad de los suyos. Usted simplemente vende esa superioridad como un valora agregado de sus productos.

Colocar su producto en el centro del movimiento de código abierto, en su campo, conlleva ventajas significantes. Los proyectos cerrados (APIs) no benefician al software libre porque éste ya está completamente abierto. El resultado es que los proyectos de código abierto tienden a crear, liderar y definir los standars.

Los Buenos proyectos de código abierto utilizan mucho tiempo y esfuerzo en involucrar a la comunidad, atrayendo gente con ideas para mejorar y ampliar los proyectos. Escuche esas ideas, ellas le proporcionarán nuevas perspectivas y lograrán que el producto evolucione por caminos que usted no imaginaba.

El Código Abierto es una manera muy poderosa de estimular el desarrollo. Si el proyecto arrastra a los líderes tecnológicos, entonces esos productos pueden actuar como especificadores virtuales o creadores de un mapa o camino para el desarrollo. Recién ahora el Linux se está alejando del modo de emulación. Cuando el plan inicial se va concluyendo, la pasión de la comunidad proporciona su empuje. Buenos negocios utilizan mucho tiempo y dinero para entrar en contacto y escuchar a sus consumidores. Los proyectos de Código Abierto llevan esto un paso más allá, logran que los usuarios se involucren en el desarrollo del producto, inclusive si lo hacen sólo para testear, comentar y contribuir con ideas. Esto es verdaderamente diferente a proveer soporte técnico o sistemas de respuestas al consumidor. En lugar de esperar las soluciones o ver si se los consulta, los usuarios son los que se mueven.

Desarrollar código para proyectos abiertos promueve las buenas prácticas de programación. Cuando muchas personas alejadas geográficamente, con tiempo disponible limitado, trabajan juntas es muy importante escribir código modular.

Las interfaces entres esos módulos necesitan estar bien definidas y estrictamente respetadas. De esa manera, yo puedo trabajar en mi módulo (inclusive cambiar completamente las funciones internas) sin afectar la operación de todo el programa.

Pequeños módulos son necesarios para permitir a los desarrolladores realizar trabajos efectivos en cortos tiempos. Esto quedó perfectamente claro con los problemas ocurridos en el proyecto Mozilla. Grandes progresos se han conseguido y la comunidad está creciendo ahora que el código base ha sido simplificado y separado en módulos manejables.

Esto incluso afecta la consciencia de los desarrolladores en el hecho de cualquiera puede leer su código. Esto hace que los funcionamientos externos del programa sean casi tan importantes como la funcionalidad externa. El deseo de impresionar a los pares con la elegancia de su código es fuerte. El resultado es código que es claro, muy bien pensado y revisado múltiples veces.

Muchos ojos hacen que los defectos sean más fácil de encontrar. Jeff Dutky dice que «El control de errores es paralelizable» porque «si bien el descubrimiento de errores requiere que los programadores se comuniquen con algún coordinador, esto no requiere que los correctores se comuniquen entre ellos. Sin embargo, esto no soluciona la complejidad cuadrática y los costos gerenciales que hacen problemática la incorporación de desarrolladores.» Cita perteneciente a Eric Raymond en The Cathedral and the Bazaar (La Catedral y el Bazar)..

Un proyecto de código abierto es un excelente medio para atraer a nuevos reclutas, lo cual es realmente difícil en el actual mercado técnico laboral. Estos reclutas pueden ya tener un conocimiento íntimo de su producto por haber contribuido al proyecto. Mejor aún, usted tiene la oportunidad de evaluar su capacidad en una situación de trabajo real observando sus contribuciones al proyecto y su interacción con la comunidad.

Altos salarios y abundantes oportunidades de trabajo le brindan a los desarrolladores la lujuria de ser más flexibles cuando eligen a su empleador. El tipo de trabajo y la naturaleza de la empresa se transforman en factores de decisión verdaderamente importantes. Muchos desarrolladores se ven atraídos por el prospecto de trabajar en una compañía de código abierto.

Utilizar su existente equipo de desarrollo en un proyecto de código abierto inclusive conlleva un número de beneficios. Las personas que programan en su tiempo libre son usualmente extremadamente dedicadas y excelentes programadores. Exponiendo e incluyendo a sus desarrolladores en esa comunidad les dará a ellos fuertes oportunidades de aprender de los gurúes.

Los proyectos de Código Abierto les da a sus empleados la oportunidad de devolverle algo a la comunidad, ganar reputación e interactuar con otros desarrolladores. Para muchos programadores estos son fuertes factores motivantes para trabajar.

Pero también puede ser Mal Negocio

Si bien hay muchas razones para abrir el código, existe un lado oscuro en la ecuación. Elegir el Código Abierto es una decisión permanente debido a las restricciones de las licencias y porque cualquiera puede colocar tu código en un servidor ftp.

El primer y obvio ejemplo es perder rentabilidad por hacer públicos los fuentes del producto. En algunos casos, esto puede ser amortizado a través de la venta de servicios o actualizaciones a una base de usuarios mucha más grande. Este alejamiento del producto especializado puede ser muy costoso como para resignarlo.

De hecho, algunas personas se preguntan si el código abierto es un modelo viable para todos los tipos de software. ¿Existe una gran comunidad de desarrolladores interesados en su particular deseo de hacer beneficioso al Código Abierto? ¿Son los problemas y el código demasiado difíciles de entender para todos excepto para los más devotos? Yo personalmente pienso que el código abierto puede ser bueno para cualquier producto porque los beneficio para el propietario del software son muchos, inclusive si la comunidad de desarrolladores es pequeña.

En esos ejemplos de productos especializados los consumidores son dejados en frío con un sistema que no pueden actualizar.

El Código Abierto, como ningún otro modelo, le provee de la tranquilidad de saber que Usted siempre puede pagarle a alguien para que trabaje en el código que Usted tiene, inclusive si el vendedor del mismo cierra su empresa.

Aunque la curva de aprendizaje sea muy empinada, esto puede ser más barato que instalar y aprender un nuevo sistema.

El más dificultoso, demandante e importante aspecto de un proyecto de código abierto es la comunidad que lo rodea. Cualquier compañía que utiliza código abierto debe estar preparada para construir, nutrir, soportar y escuchar a su comunidad. La comunidad `puede tratar de moverse de manera que Usted no esperaba, o que no encaja en su modelo de negocio. Como un fuerte y respetado elemento en la comunidad Usted tiene una gran influencia sobre esas direcciones, pero en última instancia la comunidad es libre de hacer lo que quiera.

Soportar una comunidad a través de la interacción y abriendo su tecnología a todos es extremadamente dificultoso. No es una transición que todas las empresas o desarrolladores estén listos para realizar. La comunicación clara y la naturaleza abierta son vitales para el éxito. Los hábitos de trabajo para los desarrolladores tendrán que cambiarse. Gente de todos los niveles tendrán ahora que explicar sus decisiones a una comunidad de usuarios y programadores en cada paso del desarrollo.

El desarrollo abierto requiere ingenierías técnicas fuertes, abiertas y escalables. Los métodos para aceptar o rechazar correcciones, reportar errores y demás necesitan ser claros y bien mantenidos. Esto incluye un sustancial trabajo de administración y cuidadosa documentación de los cambios por parte sus desarrolladores internos.

Puede ser muy dificultoso encontrar un negocio exitoso entre los proyectos que tienen una base de usuarios masiva. Diferentes usuarios tendrán una gran variedad de necesidades para el mismo proyecto, su trabajo es encontrar los problemas comunes.

Tal vez lo peor de todo, es la ausencia de perspectiva financiera en el modelo de Código Abierto. El software libre creció en base a un sentimiento anti-propietario.

El Código abierto adaptó las ideas del software libre para hacerlas más atractivas a la comunidad comercial.

El Código abierto es una manera de trabajar y manejar su compañía, no es un modelo de negocios. Puede brindarle valor a su producto, pero transformar esa calidad extra en ganancia financiera es aún una cuestión muy difícil.

Categorías
Programación

¿Cómo elegir un diseñador web para su sitio?

¿Cuántas ofertas existen en los medios (y/o multimedios) de soluciones completas para su empresa?

¿Cuántas de aquel conocido que, dicen, hace mucho que está en esto o se las ingenia muy bien?

Pareciera ser que en estos tiempos desde un joven de 14 ó 15 años hasta nuestra abuela pudiesen diseñar una sitio web. Tal vez sea cierto, después de todo hoy en día casi todos los procesadores de texto pueden guardar la página como HTML o insertar una imagen, y ¿de qué están compuestos los sitios web sino de texto e imágenes?

Sin embargo si Ud. quiere que su proyecto web alcance niveles competitivos y profesionales, no deje de seguir leyendo.

A pesar de la escasa antigüedad que tiene la web, se pueden realizar algunas observaciones, a saber:

  • Un sitio debe tener un diseño acorde al perfil de los usuarios a quienes Ud. quiere llegar.
    • ¿Está inmediatamente claro el objetivo del sitio?
      ¿A cuántos sitios ha ingresado y no sabe qué va a encontrar? Por las características libres y heterogéneas de internet, este caso es muy frecuente, y es una de las cosas que lo hace tan interesante, pero…
      ¿Son éstas las reglas que deben regir un sitio comercial?
    • ¿Es necesario recargar la presentación del mismo, con la inclusión de largas presentaciones, introducciones o, tal vez, pesados gráficos, si el objetivo central es brindar, por ejemplo, noticias?
      ¿Se ha tomado unos momentos para pensar en quién será el potencial consumidor de los servicios que Ud. ofrece? Tenga en cuenta que, por la naturaleza misma del medio, lo más posible es que el usuario no disponga del tiempo y la paciencia para absorber despliegues innecesarios.
      Si Ud., en cambio, está promocionando su nuevo concepto estético y gráfico, es probable que le sea beneficiosotambientar su sitio con presentaciones multimedia o impactantes imágenes.
  • El diseño debe ser consistente.
    • ¿Tiene el sitio un sistema de navegación claro?
      ¿Puede usted acceder a las secciones principales desde cualquier sector o se descubre con frecuencia buscando un link a la página de inicio o al buscador?
    • ¿Qué ocurre cuando los visitantes no utilizan el mismo navegador que quien ha diseñado el sitio?
      Tómese unos minutos, tal vez acompañado de un café, y descargue de internet los otros navegadores, a saber:
      Netscape Comunicator, Opera, etc. Puede acceder a las direcciones web colocando estas palabras en el Buscador, indicando la sección «vínculos».
      Instálelos y visite los sitios que usualmente usa, se sorprenderá de cuántos diseñadores no realizan este ejercicio. Realice esta práctica, sobre todo, en aquellas webs que aparecen en el curriculum de su potencial diseñador. ¿Tiene esta persona la experiencia suficiente en Internet, o ha limitado su investigación y estudio a una línea de tecnologías?
    • Observa inconcordancias en los colores del sitio? ¿Mantienen todas las páginas el mismo concepto estético?
      Cuántas veces ha hecho clickeado en un link experimentado la sensación de haber cambiado de sitio, para luego descubrir que simplemente han linkeado una nueva página y olvidado el look general.
  • El contenido debe cambiar con frecuencia.
    • ¿Volvería Ud. a un sitio donde se encuentra con los mismos artículos y noticias una y otra vez?
      El problema está a la vista, hay que encontrar alguna manera de actualizar los contenidos de manera frecuente, sin sacrificar la apariencia y consistencia del sitio.
      Para acercarnos a la solución tendríamos que contratar a un productor de contenidos (léase escritor, periodísta, etc.) y a un diseñador que trabaje conjuntamente con él y que consiga mantener el concepto estético/gráfico de nuestra web, o, aún peor, a alguien que pueda cumplir las dos funciones conjuntamente (este es uno de los puntos en los cuales las habilidades de nuestro aficionado sobrinito y/o conyuge quedan en el camino).
      Aún cuando cubramos estos perfiles, la tarea resulta irrealizable, económica y prácticamente. Imagínese cuántatgente necesitaría para mantener actualizado un sitio con las últimas noticias.
      La solución alcanzada por algunos emprendimientos es precisamente la de separar estos dos campos:

      • El diseño por un lado, consistente en la programación de la interface con los usuarios (lo que se ve)
      • El contenido, agregado y actualizado por los escritores especializados, a traves de formularios en-línea,sin necesidad de comprometer la integridad visual del sitio.

      Estas tareas son realizadas por los programadores. Después de todo, un redactor de crónicas de espectáculos nottiene porqué saber como programar.

Estos son algunos de los conceptos a tener en cuenta al elegir un diseñador, quien, minimamente, debe poseer estos conocimientos técnicos.

Es importante saber de la existencia de las tecnologías para poder elegir la solución adecuada.

Esta persona debe tomar en consideración, también, los aspectos no visibles del desarrollo, algunos, a veces, no tan notorios:

    • Las tecnologías empleadas deben contemplar el software utilizado por la mayoría de los usuarios
      Es decir, por ejemplo, que si la estimación es que los visitantes del sitio usan navegadores versión 3 o, a lo sumo, 4 (Internet Explorer/Netscape Navigator 3/4), no deben utilizarse recursos de JavaScript inexistentes en esas plataformas.
      Otro caso similar podría ser el de los controles de envío de archivos hacia el servidor (control tipo file en el código HTML), que, como quienes están en este trabajo saben, no son soportados por algunos de los browsers.
    • El tiempo de carga de las páginas no debe ser innecesariamente alto
      Es fundamental que quien diseñe las mismas realice un análisis para determinar cuántas y cuáles imágenes deben utilizarse, que optimizaciones deben realizarse en las mismas y en el código fuente (HTML), etc.

 

  • Las modificaciones y actualizaciones del sitio deben ser invisibles a los usuarios
    No es recomendable que los navagantes vean errores de bases de datos o página no encontrada (error 404) o Parse error in unapagina.html at line …., etc. Este tipo de problemas le quitan profesionalismo al sitio, aunque cabe mencionar que no hay sido (y siguen siendo) pocos los casos en los que algunos sitios corporativos o importantes tienen errores de este tipo.

Y, fundamentalmente, la característica más importante:

    • El diseñador debe tener una relación transparente con nosotros (los directores del proyecto, empleadores)
      No es grato descubrir, por ejemplo, que nuestros cálculos de tiempo para la finalización de nuestro proyecto no se condicen con la realidad, ni siquiera remotamente.
      Es fundamental que se expongan y definan los objetivos y compromisos para los desarrollos, y se discutan las prioridades a respetar y los tiempos de conclusión de las tareas. Esto incluye el pautar los días y horarios de las actualizaciones (en los casos en los que la arquitectura del sitio no permita separar el contenido del diseño, que son la mayoría, por otra parte), definir las metodologías para el trabajo con los otros colaboradores del proyecto y otros temas similares.
      El webmaster debe ser, también, nuestra fuente de información en lo que a posibilidades, riesgos y tecnologías web se refiere. Esta persona debe estar al tanto de los avances existentes, los últimos problemas conocidos en internet, etc., e, idealmente, debería poder presentarnos alternativas varias para la realización de nuestros proyectos y objetivos.
      Nuestra comunicación con el desarrollador debe facilitar el tratamiento de todos estos temas.

Estos puntos resumen, en mi opinión, los aspectos fundamentales a tener en cuenta para la elección del responsable técnico de nuestro proyecto web. Han quedado fuera de la discusión muchos temas como las posibles arquitecturas del sitio, características técnicas y sistemas de trabajo, los cuales ameritan futuros artículos.

Espero que estas notas hayan aportado detalles en los que Usted no había pensado y contribuyan a esclarecer estos temas.
Será bienvenida su opinión (utilice el vínculo que se encuentra al final de esta página) y buena suerte con sus proyectos!!