Pregúntale al pato.

Estoy seguro de que en más de una ocasión se han quedado detenidos pensando en algún problema que surgió y que no saben cómo resolver. Suele ocurrirme mucho en el trabajo, cuando de repente tengo un error en alguna parte del código y al preguntarle a Mr. Google no encuentro nada.


Para quienes, como yo, se dedican a programar (o algo que tenga que ver con IT), seguro se habrán topado con stackoverflow. En StackOverflow, una vez registrado, puedes realizar preguntas acerca del problema de IT que te aqueja, y (en mi experiencia), en sólo unas horas alguien responde, y si bien es posible que no te resuelva por completo el problema, seguro te ayudará a descubrir el camino para resolverlo tú mismo.


La filosofía detrás del sistema de preguntas y respuestas con la que funciona dicha página es muy interesante, y plantea una muy ingeniosa metodología para que realmente pienses en tu problema. Es más,  es muy probable que al pensar cómo plantear tu pregunta logres encontrar la respuesta tú solito.


En palabras de uno de los fundadores del sitio, Jeff Atwood (cuyo blog ha sido una excelente inspiración para mí y se los recomiendo fervientemente), la filosofía detrás de StackOverflow se puede resumir en 3 palabras: "Pregúntale al pato". 


No, no es broma, es una metodología perfectamente válida. Todo surgió gracias a una historia publicada aquí. Les ofrezco una traducción un tanto burda:

Bob señaló a una esquina de la oficina. "Ahí está un pato", dijo. "Quiero que le hagas tu pregunta al pato". 

Miré al pato. Era un pato evidentemente muerto, de peluche. Incluso si no hubiera estado muerto, seguramente no sería una buena fuente de información sobre diseño. Miré a Bob, pero su mirada era totalmente seria. Además, era mi jefe, así que no tenía mucha alternativa.

Un tanto apenado, me acerqué al pato con la cabeza baja, como si fuera a rezarle. En eso, Bob me encrespó: "¿Qué demonios estás haciendo?". Uno de los superintendentes de Bob estaba en la oficina con nosotros. Sonriendo ampliamente y con cara de burla, me dice: "Andy, no quiero que le reces al pato. Sólo quiero que le hagas tu pregunta". 

"¿En voz alta?", pregunté yo. 

"Así es, en voz alta", respondió Bob. En eso el superintendente añade, con la risa evidente en su cara: "Su nombre es Bob Jr.". Lo miré con cara de desagrado total. 

"Señor Pato", continué, "quisiera saber, si cuando uso un sujetador de tuberías, qué cosa mantiene la tubería del rociador de salirse del sujetador cuando la cabeza comienza a funcionar, causando que la tubería..." 

Justo a la mitad de formularle mi pregunta al pato, encontré la respuesta a mi pregunta. Volteo entonces hacia Bob y veo que asiente con la cabeza. "Ahora ya sabes, ¿no es cierto?". Le comenté la solución que había encontrado. "Así es. La próxima vez que tengas una pregunta, ven a mi oficina y dísela en voz alta al pato, no a mí. Si después de preguntarle a él no tienes la respuesta, entonces sí puedes preguntarme". 

¿Qué sucede? Al forzarnos a nosotros mismos a pensar en cómo podemos explicar nuestro problema de la manera más concisa, exacta y detallada posible, también nuestro cerebro se ve forzado a ver el problema desde varios ángulos, lo que en la mayoría de las ocasiones nos permite encontrar una solución que antes no veíamos. Al final lo más probable es que no tengamos que terminar la pregunta: ya sabemos cuál es el problema, y si no, al menos varios candidatos. Gracias a eso, ya no le quito (tanto) el tiempo a David, mi compañero en el trabajo, sino que pienso detenidamente las cosas, y si no encuentro la solución, imagino que quien está enfrente es un pato, y le hago mentalmente la pregunta.


Sin embargo, pienso mejorar. Tomaré este Yoshi que me regaló una ex-novia, me lo llevaré conmigo a trabajar, y será mi code-buddy. Espero levantar muchas cejas la próxima vez que le pregunte en voz alta al Yoshi cómo extender una clase de tipo de dato para Doctrine.

¿Alguna sugerencia de nombre para Yoshi?

Criptografía de llave pública

¿Alguna vez se preguntaron qué es todo ese asunto de las llaves públicas y privadas? Espero este video resuelva algunas de sus dudas.

Este post será el primero en una serie de posts respecto a seguridad informática. Próximamente:

• Imágenes ejecutables.
• ¿Por qué se bloquean las imágenes en los correos electrónicos?
• Cómo crear una línea de comandos de php en un servidor remoto,
• entre otras.

¡Disfruten!

Arquitectura REST para servicios web (con ejemplo en jQuery!)

Hola a todos!

En esta ocasión les platicaré un poco acerca de REST, una arquitectura para diseñar y construir servicios web. Este tema fué escogido debido a que fuera de los ámbitos de los desarrolladores, rara vez uno escucha los términos "arquitectura" al hablar de programación. No es lo mismo hablar de arquitectura de servicios como de  patrones de programación, o patrones de diseño. En próximas entregas hablaré un poco acerca de estos últimos.

Entonces, comencemos. Las siglas REST vienen de Representational State Transfer, y el término per se fué acuñado por Roy Fielding en su disertación de doctorado. Para no adentrarnos en los específicos de él, trataremos cómo implementarlo y por qué se ha vuelto tan popular desde su introducción.

REST plantea una nueva manera de modelar los servicios distribuidos, es decir, aquellos servicios que operan a través de una red, ya sea que se tengan recursos diferentes en máquinas diferentes, o que se trate de un servidor central y cierta cantidad de clientes. Históricamente, utilizando SOAP o algún otro tipo de servicios, se hacía lo siguiente:

Digamos que tenemos un blog, y queremos diseñar la interfaz del servicio al mundo exterior. Primeramente, definiríamos las acciones que se podrían llevar a cabo, por poner algunas:

• getPostsList($tag, $category)
• getUserPosts($userId)
• getPostComments($postId)

en adelante. ¿Qué sucede si 6 meses después de que inicia operaciones nuestro blog queremos desarrollar una aplicación móvil, o simplemente nuestra interfaz de usuario cambia? Nos veríamos obligados a seguir las reglas del contrato que realizamos al inicio del desarrollo, es decir, a utilizar las funciones que mapean las acciones posibles del servidor a cada paso, lo cual representaría una tarea ardua de mantenimiento y actualización en cada cambio. ¿Y qué tal si requerimos cambiar algo en el servidor, aunque sea la firma de alguna función? Peor aún: tenemos que recorrer todo el código que depende de tal función, cambiarlo y verificar que cumple la nueva firma. En conclusión: tal vez parezca intuitivo hacer todo así, pero a la larga causará problemas de mantenimiento y escalabilidad.

En cambio, REST propone algo un tanto extraño: utilizar la definición del HTTP al máximo, y crear interfaces que expongan las recursos del servicio por medio de métodos estándar: es decir, adiós a los getters() y setters().

Para quienes no estén tan familiarizados con HTTP, basta recordar que existen dos tipos de métodos bastante usuales: GET y POST. Sin embargo, no son esos todos los que fueron definidos en el RFC, sino que existen otros dos cuya importancia ha sido marginal puesto que hasta hace poco, ningún navegador implementaba ese tipo de peticiones. Con la llegada de HTML5 y toda la funcionalidad extra que trae consigo, la presión sobre los desarrolladores de los navegadores fué mayor y por tanto podemos encontrar que la mayoría de los navegadores ya permiten realizar peticiones de esos tipos, si bien sólo por medio de XHttpRequest, mejor conocido como AJAX. Evidentemente, el hermano relegado de estos navegadores es IE, que no tenía pensado soportar dichas peticiones.

Como su nombre lo indica, GET, POST, PUT y DELETE hacen referencia a acciones que pueden realizarse con la información, y dado que son peticiones estándar, nos hace pensar en una arquitectura que explote al máximo esta funcionalidad: REST. 

Al repensar nuestro modelo de acuerdo a la arquitectura REST, vemos que no requerimos "funciones" para cada una de las acciones posibles dentro del servicio. Asimismo, ya no requerimos pensar en cómo exponer los recursos con los que contamos, puesto que todo esto se resuelve con HTTP:

• Primero, pensamos en los recursos como objetos, como si fueran instancias de clases.
• Después, vemos que con una sola dirección de acces (y diferentes peticiones) podemos realizar las operaciones básicas (CRUD) con ese objeto, lo cual simplifica mucho la interfaz.

En términos prácticos, esto se refleja en la siguiente estructura del blog:

1. Se tendrán ciertas direcciones de recursos (URI) las cuales expondrán la información de dicho objeto.
2. Mediante el tipo de petición, el servidor sabrá qué acción desea realizarse con el objeto, la realizará y le informará del resultado mediante los códigos de status HTTP al cliente.

Entonces, podemos, después de pensar un rato, que las entidades de las que se compone el blog son, a grandes rasgos, los usuarios, posts, comentarios, y tags. Fácil es ver que se requerirían 4 direcciones en nuestro servicio:

1. midominio.com/blog/user/x
2. midominio.com/blog/post/x
3. midominio.com/blog/comment/x
4. midominio.com/blog/tag/x

Ahora bien, eso sólo cubre una parte de los requisitos. Podemos realizar las acciones CRUD en cada una de esas entidades, pero nos resta saber de qué manera interactúan entre ellas. Por ejemplo, no tiene sentido hablar de un comentario a menos que sea a través de su autor o de el post en el que fué hecho. Eso provoca que se den los siguientes cambios:

1. midominio.com/blog/user/x
2. midominio.com/blog/user/x/comment/x
3. midominio.com/blog/post/x
4. midominio.com/blog/post/x/comment/x
5. ...

Ahora, la cuestión de las peticiones: PUT, después de leer y leer discusiones, puede considerarse correcto su uso al querer hacer algo con información ya existente, es decir, información cuyo acceso conocemos. En otras palabras, su uso se presta perfectamente a un update, puesto que para realizarlo ya conocemos la identidad de la entidad a actualizar. POST puede utilizarse para muchas cosas, usualmente procesamiento de datos. Sin embargo, en el contexto REST, es comúnmente utilizado para crear una nueva instancia. DELETE, como su nombre indica, elimina la instancia del servidor, y GET sirve para obtener información sobre ella.

Para concluir entonces, les comparto un pequeño código en jQuery que ilustra la manera de trabajar:

$.ajax({
        type: "PUT",
        url: "http://midominio.com/blog/user/"+login,
        dataType: "json",
        data : {login : login,
                pass : pass,
                },
        success: function(datos) {
          alert("Datos recibidos! "+datos.login);
          //Recibimos datos como JSON: accedemos a sus propiedades como key.value
          $("div#json_results").append(datos.login);
        }
      });
    });

Básicamente, sucede lo siguiente: se realiza una petición AJAX a nuestro servidor en la dirección .../blog/user/x, que al ser PUT, actualizaría los datos con los que le enviamos, y nos podría regresar un array de datos en JSON, donde uno de ellos es el login actualizado (para verificar que todo salió a pedir de boca).

Para el lado servidor, pueden "simular" REST utilizando las variables de entorno como $_REQUEST, o utilizar alguno de los frameworks existentes. Existen varios que permiten trabajar de esta manera mucho más cómodamente, como Symfony (PHP, mediante un front-controller) y bakbone.js (JS, MVC de javascript para el cliente). Se realizan peticiones AJAX hacia los recursos del servidor, quien en caso de requerir regresar información, lo puede hacer de manera conveniente codificada como JSON o XML.

Finalmente, les dejo varias referencias que me fueron bastante útiles a la hora de aprender a hacer cosas "RESTful", como se le denomina a todo lo que cumpla esta arquitectura.

Happy Coding!

Referencias:

[1] http://tomayko.com/writings/rest-to-my-wife

[2] http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

[3] http://msdn.microsoft.com/en-us/library/dd203052.aspx

Kamehameha

Hoy, para variar un poco los temas del blog, les platicaré sobre Kamehameha. Y para los fans de Dragon Ball que llegaron por el título del post, siento decirles que terminarán un tanto decepcionados, pues no me refiero a ese kamehameha, a.k.a, la onda destructiva de la tortuga.

A quien sí me refiero es (platillos y bombos por favor!) a Kamehameha I, o Kamehameha El Grande, el primer Rey de Hawaii, quien se encargó de unificar las islas y de crear una serie de relaciones que le permitirían a Hawaii permanecer independiente.

Entre sus logros, llegó a juntar un ejército de 10,000 soldados, cuando entre todas las islas Hawaiianas en ese tiempo (1795) no llegaba a los 250,000 personas. Con esos soldados fué invadiendo isla tras isla, hasta que las conquistó a todas excepto a la última, que al ver la cantidad de soldados y lanchas (sí, lanchas!), decidió anexarse al reino.

Luego, una vez unificadas todas las islas (nota, son 8, al menos las principales), se las ingenió para que los imperios coloniales de ese entonces, europeos ellos, no lograran anexarse su reino: determinó que nadie que no fuera hawaiano podría comprar terrenos en las islas. Sin embargo, no cerró las islas al comercio, sino que unificó el sistema legal y los impuestos, y con ellos comenzó a comerciar con Europa y Estados Unidos, lo que permitió hacer que el comercio en las islas floreciera aún más.

Y finalmente, de su historia bélica, le legó algo importantísimo para cualquier movimiento armado posterior: una ley conocida como "ley del remo astillado" o Mamalahoa, que, además de tener una historia bastante curiosa detrás, básicamente le da protección legal a los civiles en zonas de combate. Fué la primera ley en la historia que procuró el bienestar de los no combatientes durante un conflicto armado.

En conclusión, si estuviera él vivo, yo lo lanzaba para presidente. Pero como no, Dr. Mono para presidente.

Are you ready for Talentism?

Ayer, viendo el desierto de Google+, topé con un post bastante interesante, originalmente hecho por Tom Reilly y compartido por uno de mis contactos, Antonio Guzmán. Este habla sobre las nuevas necesidades económicas, tema a tratar en la próxima reunión anual del World Economic Forum.

Entre otras cosas, menciona que, con la crisis económica y el estado actual de la industria, en la que cada vez se requiere menos personal para ser más productivos, a nosotros estudiantes que seremos los nuevos profesionistas en muy poco tiempo, se nos presenta un panorama un tanto gris en el importantísimo asunto del empleo. ¿Qué hacer cuando las empresas ya no buscan tantas personas como antes, y cuando la competencia por esos puestos alcanza niveles de locura?

Se requiere un nuevo modelo de empleo. No es sostenible la situación actual, y seremos nosotros quienes tendremos que dar el salto hacia el nuevo paradigma. Dado que ellos pueden decirlo mucho mejor que yo, anexo una parte del documento (encontrado en http://www.weforum.org/content/great-transformation-shaping-new-models):

"The key to mitigating a catastrophic situation is to provide young people with the capability to create their own jobs: to move from the pure concept of unemployment to the concept of micro-entrepreneurship. This will require fundamental changes in educational systems, nurturing a societal spirit of entrepreneurial risk-taking, allowing true gender equality – to integrate the other half of hidden talents – and making innovation and the support of innovation a key imperative in public and private life. The success of any national and business model for competitiveness in the future will be less based on capital and much more based on talent. I define this transition as moving from capitalism to “talentism”."

¿Te sientes listo para el cambio?

Software y Mecatrónica.

Me gustaría hoy tratar un tema que es de especial interés para mí: la carrera de Ingeniería Mecatrónica.
Tal vez muchos de ustedes, lectores, no conozcan lo que es eso, o piensen que sólo se trata de robots. Para los que sí saben, enhorabuena, mas les contaré algo que tal vez no conozcan.


Al ritmo en el que los nuevos dispositivos mecatrónicos van encontrando un lugar en las industrias y en los productos que consumimos en la actualidad, se vuelve cada vez más importante la velocidad de desarrollo del producto, y por supuesto, el conocimiento y la práctica de metodologías de diseño que permitan ahorrar tiempo y esfuerzo del desarrollador. Ya no se trata de reinventar la rueda cada vez que se diseña algo, sino el realizar el mejor diseño inicial posible y continuar construyendo sobre lo antes hecho.


Esto quiere decir que nuestros primeros diseños, a pesar de ser (quizás) hechos sin experiencia previa, deben ser cada vez más flexibles, fácilmente mantenibles y escalables. Asimismo, la participación de los sistemas de información en procesos y productos mecatrónicos es cada vez mayor, por lo que las metodologías que se aplican en esa área también deben comenzarse a implementar en la mecatrónica. Así que, partiendo un poco de mi experiencia en el desarrollo de software, trataré de analizar el diseño y construcción de un dispositivo mecatrónico de acuerdo a principios de diseño que faciliten eso.


Primeramente, comenzaremos definiendo los conceptos de diseño de software y sus analogías en el contexto mecatrónico.


Inicialmente se tiene la capa de infraestructura en software. Esta usualmente se refiere a la última capa del sistema en la que se lleva a cabo operaciones de persistencia de datos, es decir, se guarda y obtiene la información contenida en las variables del sistema, ya sea en un sistema de archivos o en una base de datos. Esto podríamos verlo en un dispositivo mecatrónico como la última capa posible de nuestro sistema, los que nos permitirían guardar y obtener información acerca de nuestro dispositivo. En otras palabras, serían los sensores y actuadores de nuestro dispositivo. Viéndolo así, un sensor nos permitiría obtener información mientras que el actuador permitiría "guardar" una variable de nuestro sistema. 


A continuación, se encuentra una capa a veces llamada dominio y otras veces llamada lógica de negocios. Es en esta capa donde se encuentran las clases dedicadas a hacer que se haga algo en el sistema. En otras palabras, si hablamos de un sistema de administración de empleados, en esta capa se deben implementar las cuestiones que permiten administrar empleados, cuestiones que si bien están ligadas con la capa de infraestructura, no dependen de ésta. Por ejemplo, no nos importaría cómo están guardados los datos, sino el saber que si debemos trabajar con ellos, estarán estos disponibles de cierta manera (e.g. como objetos o instancias de una clase Empleado). En un dispositivo mecatrónico encontramos un gran parecido, por ejemplo: ¿qué tal si, ante una petición expresa de un cliente se requiere instalar un sensor distinto al de todos los demás productos del mismo modelo? Sería necesario reprogramar todo para asegurarse de que funcione. En cambio, si se diseña la programación del producto o proceso de tal manera que sólo sea necesario modificar la información concreta del sensor, sin modificar lo que otras capas más abstractas esperan de él, el mantenimiento y/o desarrollo de nuevas versiones del producto se vuelve increíblemente sencilla.


Siguiendo, podemos definir una capa llamada de aplicación. Es en esta capa donde se introduce el concepto de API (Application Programming Interface), concepto fácilmente resumible: es una serie de librerías que implementan funciones útiles para el desarrollo de sistemas basados en ella. Un ejemplo son las Collections de Java. Éstas son una serie de estructuras (muy) útiles para el desarrollo de sistemas, como listas ligadas, pilas, colas, entre otros. Esto le permite al desarrollador pasar menos tiempo implementando estructuras de datos necesarias para su programa y más tiempo pensando en el correcto modelado, diseño y lógica de su aplicación. La idea detrás de estas API es ofrecer una interfaz fácil de usar para obtener acceso a los datos del sistema, con el objetivo secundario de permitir a terceros construir sus aplicaciones con los datos de tu sistema embebidos (como el API de Facebook, que te permite crear tus "aplicaciones" en Facebook mismo, utilizando los datos que Facebook tenga sobre tus usuarios), o crear aplicaciones para tu sistema, como versiones para móviles de redes sociales, como Twitter. En un sistema mecatrónico, la capa de aplicación es una capa invisible: existe sólo como software, usualmente en el controlador del sistema (que no sólo funciona como intermediario, usualmente tiene también las funciones propias de un controlador, con su propia ley de control). Al final de esta entrada me ocuparé de un ejemplo concreto y bien conocido de la mecatrónica y se disectará a fin de encontrar las diversas capas de las que les hablo.


Finalmente, se encuentra la capa más conocida (debido a que es la capa visible después de todo el proceso), la interfaz de usuario. La función de esta capa es fácilmente intuida: trata sobre la manera de presentar la información del sistema al usuario y en ocasiones permitir que éste interfiera en el funcionamiento del sistema. En otras, la interfaz es la única manera de que el sistema funcione, es decir, sin interfaz el sistema no está completo, es inútil. En la mecatrónica, nos encontramos con una flexibilidad inmensa al implementar una interfaz. Como ejemplos, fácilmente podemos pensar en LED's indicadores, displays de 7 segmentos, LCD's, pantallas sensibles al tacto, luces, sonidos, movimientos, entre otros. Todos los anteriores muestran información sobre el proceso o producto al usuario, pero no permiten modificar la operación de éste. Sin embargo, con interfaces como joysticks, botones, switches, controles (como los de Wii), interfaces basadas en la comunicación con otros dispositivos como celulares, tablets y computadores, entre otras, usualmente nos es posible modificar el comportamiento de nuestro dispositivo o proceso mecatrónico. Esta capa entonces no se preocupará de qué sensores, actuadores, microcontrolador o elementos en general contenga nuestra creación, sino que sólo será el puente entre el usuario y el API.


Entonces, ya sabemos cómo podemos dividir nuestro producto o software y en qué capas usualmente conviene hacerlo. Ahora veámoslo concretamente en el siguiente caso: un robot móvil.
Al tener un robot móvil nos encontramos con diversas cuestiones: peso, volumen, instrumentación, procesamiento, entre otras. Así que apliquemos el enfoque de capas al proceso de diseño.
Si lo que buscamos es un software con las características previamente mencionadas (flexibilidad, facilidad de manutención, facilidad para añadir nuevas funciones, etc) para el robot, entonces debemos pensarlo como una serie de capas que se comunicarán entre sí. 

• Primero: capa de infraestructura. Requeriremos crear métodos o funciones que nos permitan mover nuestros motores. No importará qué motor usemos al final del proceso si éstas funciones son bien diseñadas. Una función así sería aquella que, con sólo requerir una velocidad de entrada, fuera capaz de calcular la frecuencia del pulso necesario para lograrla, teniendo en cuenta dentro de la misma función el tipo de motor que se eligió, y las limitantes de éste. Lo mismo sucede con los sensores, si al inicio se decide utiliza un sensor analógico cuya salida se encuentre entre los 0 y 5 V, si después lo cambiamos por uno cuya salida sea distinta, sólo será necesario modificar la función que trate con él. Un ejemplo, al utilizar un sensor de temperatura analógico tendremos una salida entre un valor mínimo correspondiente con la menor lectura posible del sensor y el valor máximo, que corresponde a la mayor temperatura que permite medir el sensor. Una función abstracta que nos sea útil es aquella que al llamarla nos regresaría el valor de la temperatura en grados celsuis. Para quien la llama no le importa si el valor máximo es 5 V o si es 3 V, porque la lógica detrás de la conversión se encuentra en la función, por lo que podríamos cambiar el sensor y sólo modificar ésta.
• Una vez construida la interfaz entre el software y el hardware, pasemos a la lógica de negocios. Ahora será necesario para nosotros construir funciones que estén más relacionadas con la actividad a realizar. En este caso, podríamos definir una función mover, que al ser llamada con una velocidad y dirección como argumentos, llamaría a su vez a las funciones de motores de la capa de infraestructura de tal manera que nos permitiera avanzar en la dirección deseada con la velocidad deseada, sin preocuparse de qué motor se utiliza. 
• Posteriormente, construiríamos nuestra RobotAPI. Ésta constaría de todas aquellas funciones que nos permitieran saber el estado del sistema, en este caso las lecturas (útiles) de los sensores, aquellas que nos permitieran modificar algún parámetro del sistema, por ejemplo, a qué región de lecturas de un sensor infrarojo corresponde un color blanco y a qué un color negro. Finalmente, están aquellas que nos permitieran realizar alguna acción, como la anteriormente definida, mover.
• Para terminar, definimos qué tipo y protocolo de comunicación se tendrá con el mundo exterior (RF, Bluetooth, WiFi, RS232, USB), y construimos una interfaz en un dispositivo compatible con dicho protocolo para observar el proceso o dispositivo trabajando, y si es el caso, modificar su operación.

¿Cuáles son los beneficios de hacerlo así? Si se trata de un ejercicio académico que no recibirá mayor atención después de entregado, entiendo que sea difícil encontrarle utilidad al procedimiento mencionado. En cambio, si se trata de un sistema de manufactura, es importante que así sea, puesto que no se trata de un sistema desechable, sino de uno cuyo desempeño debe ser medido al segundo y debe permanecer operando continuamente el mayor tiempo posible, en un esquema a largo plazo donde deben contemplarse repuestos de máquinas, máquinas nuevas y distintas a las que fueron consideradas en el proceso de diseño, y sobre todo, aquellas situaciones imprevistas.

¿Qué piensan ustedes? 

Hoy es una fecha especial: después de haber creado dos blogs, ahora bien muertos, finalmente decidí abrir un tercero, con un objetivo un tanto distinto al de los dos fallecidos: esta vez no pretendo decir tonterías sin parar, el objetivo es acercar un poco a tanta gente como sea posible a los proyectos que realice, teniendo una mente tan inquieta como la mía.

Ahora bien, serviría de mucho definir de qué tipo de proyectos hablo. Pues bien, mis intereses principales son la programación y la electrónica, así que esperen mucho de ambas cosas, y de vez en cuando, algún post sobre Linux. El punto es que cualquier persona que por azar llegue a este blog, salga con algo nuevo, que de alguna manera se inmersa en este mundo tan fascinante :D.

Además, haré algo sin precedentes en los otros blogs que he hecho: haré una versión en Inglés y otra en Español para cada post que realice, primero porque el Español es mi lengua materna y conozco a muchas personas y varios foros en español que tratan sobre algunos de estos temas, muchos de ellos me fueron muy útiles al estar aprendiendo, y me gustaría colaborar rellenando aquellos agujeros del conocimiento que encontré, y segunda, escribir en Inglés me permitirá practicar un poco y poder brindarle estos posts a una mayor cantidad de gente. Prometo checar todo lo que escribo :P

De cualquier manera, feliz creación, engineersmod.blogspot.com!