¿Estudiar en la Universidad es tan necesario?

Es una pregunta para mi mismo. Últimamente cada vez que cruzo la entrada de mi Universidad me viene a la mente en ese momento, pero no sabía que decirme. Ahora creo que hasta vale la pena escribirlo.

ceti-colomos-jardin-central

Las personas que necesitan estudiar en la Universidad, al menos para una carrera como la Ingeniería, deberían hacerlo si realmente quieren conocimientos con una fuerte base científica. Me encanta estudiar Ingeniería Electrónica en Computación, solo que como aprendí a temprana edad y además he trabajado mucho por mi cuenta, en ciertos momentos siento a la Universidad como un estorbo para mi desarrollo.

La realidad es ahora me doy cuenta que así como hay cosas que solo aprendes con experiencia laboral, hay otras que solo en la Universidad. Los conocimientos tan exactos, precisos y fundamentados solo los puedes obtener con una disciplina académica. Donde tu profesor va tema por tema, explicando cada cosa, fundamentándola y demostrándola científicamente (idealmente hablando).

La Universidad forma las bases definitivamente, pero nunca entendí que tan profundas y científicas iban a ser. Sigo en la escuela, porque me fascina aprender toda esta teoría que “nunca usaré en el trabajo”… pero la verdad es que si la uso, pero de forma diferente. Saber esas bases da seguridad al hacer cualquier cosa relacionada, y sobretodo te da mucho criterio para analizar y resolver problemas. Cualquier técnico aprende como reparar las cosas empíricamente, pero hacer analisis completos, deducciones y ajustes, en cosas tan sencillas y aparentemente insignificantes… no tiene precio.

La Universidad no es necesaria, solo es un capricho mio :) … Finalmente, aunque parte mi fracaso académico es culpa de mis ganas de emprendimiento, no estoy dispuesto a dejar alguno de los dos, ya que ambos valen la pena.

Manipulando archivos con “find”

El comando find es una bendición para los usuarios de Unix/Linux que trabajan con muchos archivos. En mi caso particular, estar editando cientos de scripts -y toda clase de archivos- con mi editor favorito GEdit, me deja un lamentable basurero de archivos demporales. Un ejemplo práctico:

1
2
3
4
5
6
-rw-r--r-- 1 linnk linnk 2.9K 2009-04-13 02:22 put_phpftp
-rw-r--r-- 1 linnk linnk 2.9K 2009-04-13 02:22 put_phpftp~
-rw-r--r-- 1 linnk linnk 1.9K 2009-04-12 22:40 README.txt
-rwxr-xr-x 1 linnk linnk 2.4K 2009-04-13 03:47 remove_phpftp
-rw-r--r-- 1 linnk linnk 2.4K 2009-04-13 03:47 remove_phpftp~
-rwxr-xr-x 1 linnk linnk 7.4K 2009-04-12 22:40 svn2web

En este caso solo tengo dos archivos temporales que quedaron olvidados y que cuando quiera arrastrar este directorio a un FTP, estos archivos se subiran haciendo más basura en mi servidor.

La solución a esto la encontré con find googleando, pero admito que solo la repetía sistemáticamente. Suena ridículo porque ahora entiendo bien como funciona este comando y es muy sencillo de usar, además de poderoso. La solución:

1
find /home/usuario/proyecto/ -name "*~" -exec rm {} \;

El primer parametro de find es el directorio donde se va a buscar (incluyendo subdirectorios), el segundo es el parametro -name el cual filtra por nombre según "*~" (cualquier nombre que termine con ~). El siguiente parametro es -exec que ejectuará el comando rm {} donde {} es el archivo encontrado por find y termina el comando con \;

Para entender bien como funciona, si quitamos la parte desde -exec, lo que hará listarnos únicamente los archivos temporales. De esta forma comprendemos que find puede ejectuar comandos por cada archivo encontrado con -exec, como en este otro ejemplo muy útil:

1
find /home/usuario/proyecto/ -type f | xargs grep -l 'texto_buscado' | xargs sed -i '' -e 's/texto_buscado/texto_reemplazo/g'

En este caso buscamos un texto_buscado y lo reemplazamos por texto_reemplazo en muchos archivos dentro del directorio especificado. Finalmente, las posibilidades son infinitas y no lo comprendí hasta que necesité hacer algo avanzado y me puse a jugar con el comando :P

Referencia Rápida de Mootools 1.2.x

mootools-cheat-sheet-demo

Leyendo varios blogs he acabado en uno muy bueno con 14 hojas de referencia rápida para diseño web, de entre las que destacan esta hoja de CSS y la hoja de Mootools 2.1.

En cualquier caso recomiendo que, si estas empezando con Mootools, te bajes una versión del framework sin compresión y con comentarios. No le tengas miedo al código del framework, está tan bien escrito que es como leer poesía en la programación. Gracias a sus estandares, podemos consultar el código -que es perfectamente entendible- y aprender mucho para desarrollar nuestras aplicaciones.

¿Por qué prefieres usar Linux?

Acabo de leer algo interesante en LinuxLoop, que todos los usuarios de Linux hemos tenido que responder estas preguntas: “¿Que es eso?”, seguido inevitablemente de esta otra “¿Porque es mejor que Windows?” … ¿Que les respondes tu?

Las respuestas típicas del discurso linuxero son:

  • Porque es gratis.
  • Porque es código abierto.
  • Porque no necesita muchos requerimientos.
  • Porque es más muy seguro.

Exceptuando la primera, las demás no son tan llamativas para el usuario promedio windowsero y en cualquier caso, ¿realmente son las razones por las que usas Linux? La filosofía del Software Libre es maravillosa, pero en la práctica no suele ser la razón de más peso a la hora de elegir un sistema operativo.

Me pongo a pensar porque NO volvería a Windows y creo que mis verdaderas razones son más prácticas que ideológicas:

  1. Estabilidad y confiabilidad. Sabes que el software en su versión estable, es verdaderamente estable. El sistema operativo no se hace lento conforme pasa el tiempo, no necesitas defragmentar, el sistema operativo simplemente funciona.
  2. Seguridad. Existen virus para sistemas *nix, pero en la práctica el riesgo es casi nulo. El sistema operativo es muy seguro ante software malintencionado y el sistema de permisos protege tu información a capa y espada.
  3. Flexibilidad y personalización. Linux es como tu quieres que sea, esto va mucho más allá de la apariencia, el nivel de personalización llega hasta lo más profundo del sistema y si sabes programar, no tendrás limites a la hora de modificar.
  4. Comunidad. Hay gente que está dispuesta a ayudarte siempre y cuando tu pregunta no sea un error típico de novatos, que para eso existe muchísima documentación por todas partes. Es cuestión de saber buscar.
  5. Usabilidad. Suena raro, pero una vez entendiendo el nuevo sistema operativo todo se vuelve más claro y fácil. La instalación del S.O. y de aplicaciones cotidianas es rápida y sencilla, mucho más que en Windows. Un niño de 10 años puede instalar Ubuntu en un PC nuevo sin problemas.

Por otra parte, hay ciertas aplicaciones como Amarok y GEdit que yo extrañaría :) La verdad es que hay muchos pequeños detalles que me dejan demasiado contento en Linux como para cambiarme. Aunque tambien extrañas programas como Photoshop, pero al menos en mi caso no vale la pena volver a Windows solo por eso y claro, el tema de la usabilidad todavía tiene mucho que mejorar, a pesar de que ciertos procesos están muy perfeccionados.

Cada quien tendrá sus razones y evidentemente sus necesidades. Un diseñador que vive de Illustrator evidentemente no podría divorciarse de Windows tan fácilmente, por ejemplo. En mi caso personal Linux satisface la gran mayoría de mis necesidades como ningún otro y me siento muy feliz de que existan Ubuntu y Fedora.

La difusa linea entre diseñador web y programador web

He escrito al respecto sobre éste tema, pero creo que lo abordé al revéz. Primero deberíamos separar los roles en el desarrollo web e identificar al profesional que ¿debería? cubrirlos. Como le comentaba a Luis Alarcón vía email, de entrada lo más obvio para mi es:

  • XHTML y CSS no pertenecen a la programación, XHTML es la estructura y CSS el diseño.
  • Javascript es un lenguaje de programación y AJAX es solo una técnica.
  • “Diseño de plantillas” para CMS es diseño. Involucra saber código de un lenguaje (PHP generalmente), pero no deja de ser “diseño”.
  • Programar alguna funcionalidad en estas plantillas, entonces si sería programación.
  • Dreamweaver y editores de código WYSIWYG son para diseñar, aunque se puede programar con ellos, pero no tiene mucho sentido.
  • Flash puede ser tanto diseño como programación, aunque un programador preferirá programar en Flex (pues para eso es) y Flash queda más como herramienta de diseño.
  • “Propiedad intelectual” ¿?. Lo comentó Luis Alarcón en su post del “diserrollador”, yo creo que esto es tema de abogados y no más. Debemos conocer las leyes, pero no si me enfoco puramente a un perfil técnico, no lo incluiría.

Usabilidad, accesibilidad, diseño de interfaces… son conceptos que se introdujeron por medio de la Ingeniería de software, por lo que sus raíces están en la programación (el comportamiento). Sin embargo en el desarrollo web, un diseñador tambien participa muchísimo durante la creación del sitio, ya que los diseños en la web están intimamente relacionados con aspectos del comportamiento. Paradigmas de la programación como MVC solucionan mucho de estos problemas, pero no todos.

Hay otras cuestiones más complicadas, por ejemplo: estrictamente hablando XHTML/CSS son aspectos técnicos del diseño, sin embargo, la programación de interfaces con Javascript involucra XHTML/CSS profundamente. Por otro lado, si el diseñador quiere hacerlas deberá aprender Javascript, y PHP/XML si quiere implementar AJAX.

Volviendo a una visión estricta: El diseñador se encarga de hacer la estructura y el diseño, el programador se encarga del comportamiento, pero ambos tienen que manejar XHTML para sus labores. Entonces, ¿el SEO pertenece a…? Por más que le doy vueltas, sigo creyendo que a ninguno de los dos, es un aspecto único y propio del desarrollo web.

De hecho, creo que por eso la linea es tan difusa, porque el desarrollo web es completamente otro paradigma.

El desarrollo web y los desarrolladores

love_ring_by_lakrestas_700

Cual sea que fuera la razón, nos hemos acostumbrado a llamarle desarrollador web a la persona encargada de la programación y en algunos casos, administración de un sitio web. ¿Como llegamos a esto? No se, la programación web y la administración de un servidor, son tareas de tiempo completo en areas sumamente diferentes que no necesariamente se comparten.

Es común que los programadores estén involucrados en la administración de un servidor, pero en muchos de los casos ni siquiera conocen Linux (S.O. predominante en servidores de Internet), entonces, ¿de donde sacamos que tambien es un administrador? ¿solo porque saben usar el cPanel?. Las aplicaciones web requieren que el programador domine varios lenguajes de programación web y otros conocimientos especializados, que ni siquiera posee un Programador de Fierros™. Al mismo tiempo, un administrador de servidores, aunque normalmente son programadores gracias a su educación, su labor requiere de cierta especialización en su area, desde conocimiento sobre redes, sistemas operativos y los servicios involucrados en un servidor web. ¿Desde cuando un desarrollador es ambas cosas y porque?

Si el perfil de un desarrollador web es un programador con conocimientos de servidores, hemos empezado mal. La administración de un servidor no se si podría considerarla un “desarrollo” propiamente dicho, aunque la palabra per se significa “deshacer un rollo”, empero, la asumimos como parte del proceso de creación.

Quizás deberíamos dejarnos de inventar un nombre para algo que ya tiene, “programador”, pero no podemos puesto que -además de la administración- su función no es estrictamente el meterle mano al código XHTML y CSS de un sitio, porque no son lenguajes de programación. De hecho, un Programador de Fierros™ se sentiría insultado si le dices que programas en HTML, no miento.

Entonces definamos ¿Que es el XHTML y el CSS?

Y ¿De quien es el trabajo del HTML/CSS? ¿Del programador? ¿Del diseñador? De una u otra forma, ambos se acaban involucrando. El diseñador acaba aprendiendo PHP y SQL, mientras que el programador aprende a utilizar Photoshop, Illustrator y Flash. Y finalmente, ambos le meten mano el XHTML y al CSS. Aquí surge una duda que muchos se plantearon:

¿Un programador que sabe utilizar Illustrator se convierte en un diseñador? ¿Un diseñador que sabe algo de PHP  se convierte en un programador? Lo dudo. De entrada estoy seguro que muchos ponen en su curriculum “Programación en PHP y SQL”, cuando solo saben hacer un par de algoritmos sencillos, instalar un Wordpress y crear bases de datos sencillas en el PhpMyAdmin. Lo mismo con los que pretenden venderse como diseñadores, solo porque hace figuritas en Illustrator o porque hizo un encabezado guay en Photoshop a base de meter filtros a lo imbécil para crear una imagen colorida. Yo a estos personajes les daba un libro de programación orientada a objetos y uno de psicología del color, respectivamente… y un par de hostias ¡por engreídos!

Lo anterior da mucho que hablar sobre la linea que separa al programador y al diseñador, debido a que sus labores suelen estar demasiado relacionadas y no podemos evitar la curiosidad por intentar definir al ser que saldría de una suma de ellos, como lo hace Luis Alarcón. Pero antes que nada, es importante tener claro el perfil de cada uno por separado: diseñador, programador y administrador. Los tiempos y nuestra propia curiosidad han hecho que nosotros aprendamos de otras areas, al punto incluso de especializarnos, pero ¿Realmente necesitamos acuñar un nuevo termino?

Yo creo que si. Hay una diferencia entre un diseñador y un diseñador web, entre un programador y un programador web, por tanto creo que nuestro campo en Internet abre un nuevo paradigma. Si quisiera englobar un perfil que posee los conocimientos de un diseñador, de un programador y quizás tambien de un administrador, aunque sea de forma muy elemental, tal vez le llamaría: Desarrollador web.

¡Quizás no hace falta un termino nuevo! De hecho, éste me suena muy lógico y correcto. En la ingenieria de software, un desarrollador de software no es solamente un programador, es una persona que se dedica al proceso de este desarrollo desde una perspectiva general más allá de la programación, incluyendo aspectos de usabilidad, accesibilidad, entre otros. En el desarrollo web ocurre lo mismo.

Un programador web cuando adquiere conocimientos de diseño,  su forma de programar tomará en cuenta las necesidades del diseño web. Del mismo modo, un diseñador web cuando adquiere conocimientos de programación, su forma de diseñar tomará en cuenta las necesidades de la programación. En estos casos, se deja de ser simplemente “programador” y “diseñador”, pasan a ser Desarrolladores web, profesionales que tienen una visión -en la creación de sitios y aplicaciones web- más allá de una sola area técnica, como la programación y el diseño, abarcando diversos aspectos (como semántica, usabilidad, SEO, accesibilidad, AJAX, estandares XHTML/CSS, Interfaces RIA, descubribilidad, administración, etc) en el desarrollo de un sitio web.

¿Te parece correcto este concepto de Desarrollador Web? ¿Por que?

Fotografía | Love ring

Interceptando la salida accidental del usuario

El problema (y lo detecte gracias a mi madre :P), es, ¿y que si el usuario presiona F5 cuando va a la mitad de un enorme formulario? No es culpa del usuario, pero incluso cuando me pasa a mi, me da tanto coraje perder lo que había llenado por tan tremenda tontería, que se me quitan las ganas de volverlo a intentar.

No queda opción, hay que interceptar cuando el usuario presiona ciertas teclas en ciertos lugares. Por suerte, fue muy fácil hacerlo. Para Mootools el script sería así:

1
2
3
4
5
6
7
8
9
10
11
12
13
window.addEvent('domready',function(){
 
	if($$('div.no-f5').length > 0)
	{
		document.addEvent('keydown',function(event){
 
			var tag = event.target.tagName.toLowerCase();
 
			if(event.key=='f5' || (event.key=='backspace' && tag!='input' && tag!='textarea'))
				event.stop();
		});
	}
});

Revisamos si existe un div.no-f5, que no es más que una clase bandera, para saber si en esa pantalla necesitaré del script. Si procede, creo el evento keydown para el documento. Cuando el evento suceda, comprobamos a que elemento se está apuntando, pues no queremos interceptar el backspace cuando el usuario esta escribiendo en algún campo de texto, pero si en cualquier otro caso pues lo regresaría a la pantalla anterior. La tecla F5 la interceptamos en todo momento.

Al mismo tiempo, descubrí (todo por no leer en su momento), que Mootols no extiende el objeto event.target con $, por razones de rendimiento. Así que si los chicos de Moo tuvieron buenas razones, decidí no extenderlo aunque hacer un $(event.target).get('tag') era muy tentador… pero hacerlo con Javascript nativo es muy fácil y cross browser.

Tanto el problema como la solución son detalles muy simples y normalmente subestimadas, pero seguro salvas a algún usuario de que se arranque el cabello mientras llenaba un enorme formulario.