Durante muchos años, Sourceforge fue uno de los principales repositorios de software "open source". GitHub le quitó el puesto, pero me temo que son ellos mismos (SF) los que se acaban de poner el último clavo al ataúd.
Desde hace un tiempo, empezaron a poner adware en los instaladores de los desarrolladores, llegando al límite de quedarse con la cuenta de algunos proyectos emblemáticos, como GIMP, VLC, Nmap o Notepad++, al más puro estilo Softonic (parece que estos últimos ya se han reformado, menos mal).
Todos estamos de acuerdo en que hay que buscar vías de financiación, pero apoderarse del código e instalar crapware a los usuarios finales... no puede ser.
Les deseo una pronta desaparición y que se busquen la vida de una forma más honrada y respetuosa con los usuarios y desarrolladores.
Actualización: parece que también han llenado de crapware un instalador de Firefox. Morir matando, lo llaman.
lunes, 15 de junio de 2015
viernes, 8 de mayo de 2015
El venerable cowsay
Lo bien que me lo pasaba "tuneando" la shell con cowsay... Lo divertido es que se lo enseñas a gente joven y se queda alucinada ;-)
miércoles, 11 de marzo de 2015
10 años de desarrollo web
Ante todo, debo felicitarme a mi mismo. Este blog cumple 10 años. No voy a hacer el propósito de actualizarlo más a menudo (sobre todo porque no lo puedo mantener), pero seguirá existiendo por ahora.
¿Cómo ha ido cambiando el desarrollo web en estos años?
En 2005 teníamos la versión 5 de PHP recién salida del horno, la gente empezó a dejar de usar el "register_globals" (lo que costó...). No obstante, durante mucho tiempo se siguió utilizando PHP 4 en muchos sitios.
Por entonces se empezó a extender la idea en el mundillo PHP de que separar la lógica de la presentación era bueno y se empezó a extender el uso de motores de plantillas como Smarty. Parece que no, pero empezar a ver código PHP limpio de echo y sprintf fue un alivio.
Perl seguía fuerte en desarrollo web (Movable Type,...). Python no tenía mucha relevancia en el desarrollo web y Ruby era prácticamente un desconocido por estos lares.
Afortunadamente, ya empezaba a calar la idea entre los responsables IT de que quizás hacer las webs con tecnología J2EE no era lo adecuado en todos los casos. El tiempo nos ha dado la razón a los que pensábamos que era viable realizar proyectos de envergadura mantenibles con lenguajes de scripting.
Un punto de inflexión en el desarrollo web fue la aparición y popularización de varias soluciones que simplificaban mucho el trabajo: los frameworks. En el lado del servidor, herramientas como Ruby On Rails, Symfony, Django, y similares demostraron que era posible hacer aplicaciones web sin tener que estar tirando consultas SQL a pelo y manteniendo el código de forma organizada y previsible. En el lado cliente, las librerías de Javascript Prototype y jQuery (entre otras) nos ayudaron a abstraernos en cierta forma de las peculiaridades de cada navegador.
En 2008 ocurrieron dos cosas muy interesantes: llegaron los primeros iPhone a España y se lanzó el navegador Chrome. Nada ha vuelto a ser igual. Desde ese momento, Internet Explorer empezó a perder cuota de mercado inexorablemente.
Recuerdo alguna anécdota de entonces: le pregunté a un responsable editorial...
Je, je, je. A día de hoy, ya no tenemos que dar soporte a los Explorer más antiguos. Los diseñadores y maquetadores respiran aliviados.
Por otra parte, el incremento de uso de los teléfonos móviles con navegador nos obligó a todos a empezar a hacer webs diferenciadas para estos dispositivos.
De esta época también data la locura de las "apps". Todo el mundo quería tener una app, sin saber ni siquiera diferenciar una app nativa de un acceso directo en el "escritorio" del móvil con el iconito a la versión web. El tiempo parece que también ha colocado las cosas en su sitio. No era normal que unos dispositivos con un navegador tan completo (el Safari de los iPhone o el stock browser de Android, ambos basados en Webkit, también estaba el Opera Mini) necesitasen una aplicación nativa para mostrar lo que el navegador podía hacer perfectamente.
En 2010 se empezó a comercializar el iPad y poco después todas las tabletas de otros fabricantes. Otro cachivache más al que dar soporte. La maquetación y diseño se han complicado bastante, así que se ha terminado haciendo un diseño único que se adapte al dispositivo en el que se ve la página. No era viable tener tres versiones diferentes de una misma web, una para "desktop", otra para tablet y otra para móvil.
JavaScript ha evolucionado mucho y parece que prácticamente está estandarizado. Librerías como jQuery, Motools,.. y multitud de frameworks y librerías han surgido para facilitarnos el trabajo. Ya no vemos cosas como document.getElementById().
El lenguaje se ha rehabilitado a los ojos de los desarrolladores. JS ya no es el lenguaje que se usa para hacer monerías en una página web. Es un estándar, con muchas implementaciones y ya no está restringido a ejecutarse en el navegador. Node.js es la implementación más conocida de JS fuera del navegador, pudiendo correr en el "backend".
La sintaxis de objetos de JS (JSON) se ha convertido en muchos casos en el formato estándar "de facto" para intercambiar información estructurada, desplazando al voluminoso XML.
AJAX... Asynchronous Javascript And Xml... las siglas se han quedado, pero nadie utiliza ya XML para intercambiar datos, mejor JSON, que es más compacto y se parsea más rápido.
HTML5, casi más una buzzword que otra cosa. Pero está muy bien tener un <video>, <audio> y <canvas> nativos y estructurar un poco mejor el HTML (<header>, <section>, <footer>,...), pero parece que no nos terminamos de quitar de encima al COBOL de la web: Flash.
Volviendo a JavaScript, en los últimos años ha habido una "explosión" de utilidades, implementaciones, frameworks y librerías. Los que nos hemos quedado un poco en la parte del desarrollo del backend estamos un poco desconcertados (yo al menos).
La última tecnología que se ha popularizado y ha pasado a ser "mainstream" en los últimos años son las bases de datos no relacionales (NoSQL). Otro campo en el que profundizar, sobre todo los que hemos seguido en el paradigma relacional.
Pese a todos estos cambios, hay una constante que permanece: hacer webs se lleva mucho tiempo. Tenemos mejores herramientas y entornos, pero los requisitos ahora son mucho más exigentes.
¿Cómo ha ido cambiando el desarrollo web en estos años?
En 2005 teníamos la versión 5 de PHP recién salida del horno, la gente empezó a dejar de usar el "register_globals" (lo que costó...). No obstante, durante mucho tiempo se siguió utilizando PHP 4 en muchos sitios.
Por entonces se empezó a extender la idea en el mundillo PHP de que separar la lógica de la presentación era bueno y se empezó a extender el uso de motores de plantillas como Smarty. Parece que no, pero empezar a ver código PHP limpio de echo y sprintf fue un alivio.
Perl seguía fuerte en desarrollo web (Movable Type,...). Python no tenía mucha relevancia en el desarrollo web y Ruby era prácticamente un desconocido por estos lares.
Afortunadamente, ya empezaba a calar la idea entre los responsables IT de que quizás hacer las webs con tecnología J2EE no era lo adecuado en todos los casos. El tiempo nos ha dado la razón a los que pensábamos que era viable realizar proyectos de envergadura mantenibles con lenguajes de scripting.
Un punto de inflexión en el desarrollo web fue la aparición y popularización de varias soluciones que simplificaban mucho el trabajo: los frameworks. En el lado del servidor, herramientas como Ruby On Rails, Symfony, Django, y similares demostraron que era posible hacer aplicaciones web sin tener que estar tirando consultas SQL a pelo y manteniendo el código de forma organizada y previsible. En el lado cliente, las librerías de Javascript Prototype y jQuery (entre otras) nos ayudaron a abstraernos en cierta forma de las peculiaridades de cada navegador.
En 2008 ocurrieron dos cosas muy interesantes: llegaron los primeros iPhone a España y se lanzó el navegador Chrome. Nada ha vuelto a ser igual. Desde ese momento, Internet Explorer empezó a perder cuota de mercado inexorablemente.
Recuerdo alguna anécdota de entonces: le pregunté a un responsable editorial...
"Si la cuota de usuarios de alguna de las versiones de Internet Explorer baja del 5%, ¿nos autorizas a dejar de darle soporte?"
Je, je, je. A día de hoy, ya no tenemos que dar soporte a los Explorer más antiguos. Los diseñadores y maquetadores respiran aliviados.
Por otra parte, el incremento de uso de los teléfonos móviles con navegador nos obligó a todos a empezar a hacer webs diferenciadas para estos dispositivos.
De esta época también data la locura de las "apps". Todo el mundo quería tener una app, sin saber ni siquiera diferenciar una app nativa de un acceso directo en el "escritorio" del móvil con el iconito a la versión web. El tiempo parece que también ha colocado las cosas en su sitio. No era normal que unos dispositivos con un navegador tan completo (el Safari de los iPhone o el stock browser de Android, ambos basados en Webkit, también estaba el Opera Mini) necesitasen una aplicación nativa para mostrar lo que el navegador podía hacer perfectamente.
En 2010 se empezó a comercializar el iPad y poco después todas las tabletas de otros fabricantes. Otro cachivache más al que dar soporte. La maquetación y diseño se han complicado bastante, así que se ha terminado haciendo un diseño único que se adapte al dispositivo en el que se ve la página. No era viable tener tres versiones diferentes de una misma web, una para "desktop", otra para tablet y otra para móvil.
JavaScript ha evolucionado mucho y parece que prácticamente está estandarizado. Librerías como jQuery, Motools,.. y multitud de frameworks y librerías han surgido para facilitarnos el trabajo. Ya no vemos cosas como document.getElementById().
El lenguaje se ha rehabilitado a los ojos de los desarrolladores. JS ya no es el lenguaje que se usa para hacer monerías en una página web. Es un estándar, con muchas implementaciones y ya no está restringido a ejecutarse en el navegador. Node.js es la implementación más conocida de JS fuera del navegador, pudiendo correr en el "backend".
La sintaxis de objetos de JS (JSON) se ha convertido en muchos casos en el formato estándar "de facto" para intercambiar información estructurada, desplazando al voluminoso XML.
AJAX... Asynchronous Javascript And Xml... las siglas se han quedado, pero nadie utiliza ya XML para intercambiar datos, mejor JSON, que es más compacto y se parsea más rápido.
HTML5, casi más una buzzword que otra cosa. Pero está muy bien tener un <video>, <audio> y <canvas> nativos y estructurar un poco mejor el HTML (<header>, <section>, <footer>,...), pero parece que no nos terminamos de quitar de encima al COBOL de la web: Flash.
Volviendo a JavaScript, en los últimos años ha habido una "explosión" de utilidades, implementaciones, frameworks y librerías. Los que nos hemos quedado un poco en la parte del desarrollo del backend estamos un poco desconcertados (yo al menos).
La última tecnología que se ha popularizado y ha pasado a ser "mainstream" en los últimos años son las bases de datos no relacionales (NoSQL). Otro campo en el que profundizar, sobre todo los que hemos seguido en el paradigma relacional.
Pese a todos estos cambios, hay una constante que permanece: hacer webs se lleva mucho tiempo. Tenemos mejores herramientas y entornos, pero los requisitos ahora son mucho más exigentes.
martes, 9 de diciembre de 2014
Si eres un desarrollador web y no sabes usar curl... estás tardando
¿Funcionan las redirecciones de mi .htaccess o mi httpd.conf?
curl -LI http://url/a/probar
¿Cómo simular el envío de un formulario?
curl -d "campo1=valor1&campo2=valor2" http://url/a/probar
¿Qué pasa si entro a un sitio con un móvil?
curl -I -A "mobile" http://url/a/probar
Descargar un fichero
curl -o salida.mp4 http://url/fichero/grandisiomo.mp4
Si usamos curl en shell scripts, tenemos una herramienta muy útil para automatizar un montón de tareas web.
Sacar todos los enlaces de una página web
curl -s http://url/a/probar | grep -o -P 'href="(.*)"' | sed -e 's/href=//g' -e 's/"//g' | sort | uniq
curl -LI http://url/a/probar
¿Cómo simular el envío de un formulario?
curl -d "campo1=valor1&campo2=valor2" http://url/a/probar
¿Qué pasa si entro a un sitio con un móvil?
curl -I -A "mobile" http://url/a/probar
Descargar un fichero
curl -o salida.mp4 http://url/fichero/grandisiomo.mp4
Si usamos curl en shell scripts, tenemos una herramienta muy útil para automatizar un montón de tareas web.
Sacar todos los enlaces de una página web
curl -s http://url/a/probar | grep -o -P 'href="(.*)"' | sed -e 's/href=//g' -e 's/"//g' | sort | uniq
viernes, 20 de junio de 2014
~/.bashrc
[david@localhost ~]$ cat ~/.bashrc
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
alias gits='git status'
alias gita='git add'
alias gitc='git commit'
alias rm='rm -i'
alias curli='curl -LI'
Somos animales de costumbres. Cada vez que hago login en una máquina que no es la mía...
[USUARIO@SERVIDOR ~]$ gita
-bash: gita: command not found
[USUARIO@SERVIDOR ~]$ curli
-bash: curli: command not found
Suscribirse a:
Entradas (Atom)