¿Es el fin de las aplicaciones de escritorio?

Hace poco me encomendaron  el desarrollo de un sistema de software. Inicialmente pensé en usar Java, pero terminé con algo "más web".

Cuando nos enfrentamos al desarrollo de software, aparte del diseño acorde a la captura de requerimientos que se haya realizado, y las interfaces de usuario; entre muchas otras cosas; se debe escoger la tecnología adecuada.

La elección de que tecnología utilizar normalmente va ligada a la instalación, vale decir en las características de la máquina del cliente donde se instalará la aplicación. En la propuesta inicial pensé en realizar el desarrollo usando Java y una base de datos H2. Logré un avance para la generación medianamente rápida de la GUI, sin embargo me di cuenta que para conseguir interfaces de usuario sencillas, y por sobretodo intuitivas, Java me limitaba demasiado, aún considerando Swing, JavaFX y muchas otras librerías de terceros que entregan infinitas alternativas.

La alternativa:

Hacer un desarrollo "más web", vale decir desarrollar el FrontEnd en HTML y el backend en modo "servidor". Entre las elecciones "lógicas" estaba utilizar un servidor Apache Tomcat, un Jetty, o algo para contener JSP y Servlets, o usar Apache (o similar) con PHP.
El problema de esas opciones es que el computador huésped, la máquina del cliente y usuario final, de una u otra manera termina convirtiéndose en un servidor, eso sin considerar la cantidad de dependencias que se deben considerar:

• JDK de Java
• Servidor web
• Motor de base de datos
• Plugins varios
• etc.

Pensé ¿.NET será una alternativa? y el problema es similar al de Java, necesitas previamente instalar muchas dependencias. Si el PC del cliente no tiene todo lo necesario, una aplicación que pesa un par de megas significa finalmente descargar sobre 40 MB de instaladores anexos. ¿Cómo evitamos eso?

De vuelta al enfoque inicial

¿Una WebApp local quizás? Con eso se soluciona el peso de la aplicación, aunque hay 2 problemas:

1. El almacenamiento de datos usando WebDB está limitado a las restricciones del navegador que se utilice. Eso y los riesgos que el usuario utilice distintos navegadores, generando inconsistencias en la información, o que haga una limpieza agresiva del caché del navegador (lo que eliminaría la BD).
2. La versión del navegador es un elemento que no se puede ignorar, y créanlo, aún hay usuarios de Internet Explorer 6...

Busqué alternativas disponibles, y ahorrándoles el proceso de análisis y selección de la a mi parecer mejor, finalmente llegué a node-webkit.
Aprovechando mi reciente incursión con Node.js decidí hacer algunas pruebas, que luego de resolver un par de problemas han resultado en una aplicación que cumple todas mis expectativas. Lo que utilicé:

• Bootstrap para las interfaces.
• Fontello para los íconos de la aplicación.
• Angular y jQuery para la lógica de aplicación.
• node-webkit para embeber Node.js y poder generar una aplicación ejecutable "tipo escritorio" pero con "olor a web".
• Sequelize y SQLite para la capa de persistencia y la base de datos.

Y una vez llegado a esto empiezo a cuestionar que tanto vale la pena desgastarse tratando de hacer una aplicación de escritorio, con miles de dependencias y limitaciones. Más considerando que hoy en día todo avanza hacia convertirse en Web:

• La comunicación entre las personas se vuelve más y más Web, sólo piensen en las redes sociales.
• La experiencia de juego cada vez se enlaza más a la Web.
• Aplicaciones móviles desarrolladas de manera híbrida, vale decir HTML5+CSS3+JavaScript+API nativas. Phonegap lleva mucho avanzado en esta línea.
• Las aplicaciones de Windows 8, que muchas veces están desarrolladas 100% usando tecnologías web.
• Los temas de escritorio de GnomeShell utilizan CSS para muchas de sus definiciones.
• Muchos widgets de escritorio de cada uno de los distintos sistemas operativos
• El mismo Node.js que es JavaScript en el servidor.
• Me arriesgaría a decir que más del 90% de los desarrollos de Google.

Incluso escalar este el modelo de aplicación de escritorio web no es tan difícil, pensando en un escenario en el que se decida masificar el uso de la aplicación en la organización.

Estoy claro que esta línea puede no ser la respuesta a todos los problemas que podemos enfrentar en desarrollo de software, pero al menos a mi me hace dar una segunda mirada cada vez que me hablan de desarrollar una aplicación de escritorio.

Si tienen dudas sobretodo respecto a como resolver la persistencia de datos con node-webkit, Sequelize y SQLite no duden en hacerlas.

Cómo rescatar archivos desde un correo en .eml (Linux)

Muchas veces recibimos correos con información adjunta, y también muchas veces nuestros remitentes nos reenvían un archivo de extensión .eml que eventualmente trae uno o muchos archivos adjuntos. Aquí una pequeña fórmula de como recuperar estos archivos adjuntos.

1. Lo primero determinar cuantos adjuntos pueden venir. A veces bastará  con ejecutar un comando como este:
   
   grep "filename=" archivo.eml
   que nos mostrará el listado de archivos supuestamente incluidos.
2. Luego ejecutar el siguiente comando:
   
   munpack archivo.eml 
   Este comando rescatará el listado de archivos que supuestamente vendría codificado dentro del adjunto.
3. En casos especiales (como el que me sucedió recién), en los cuales el comando no rescata todos los archivos que se supone trae dentro. En ese caso habrá que abrir el archivo .eml con un visor de archivos de texto y buscar la línea donde aparezca el archivo qeu nos interesa rescatar. por ejemplo:
   
   Control+F filename="archivo.zip"
   Una vez encontrada la línea, se procede a eliminar todo lo anterior, y volvemos al paso 2. Eso debiera funcionar (debiera...). Esto se puede hacer por línea de comando, pero eso lo dejo a la inquietud del lector :)

Ejecutando un proceso en múltiples procesadores (Linux y Windows)

Muchas veces tenemos a nuestra disposición un servidor con múltiples procesadores, y nos interesaría poder aprovecharlos ejecutando algunos procesos de manera que utilicen más de un procesador.

Esto lo aprendí en una capacitación de Bonita BPM, donde el instructor nos señalaba que la licencia dependerá de la cantidad de procesadores qeu se desee utilizar.

Para Windows:

Los procesos deberán iniciarse con el comando:

start /AFFINITY [n] [archivo ejecutable]

donde [n] es un número decimal equivalente al binario que indica que procesadores se van a utilizar (ya lo explicaré), y [archivo ejecutable] es el ejecutable del programa (sea un .exe, un .bat u otro).

Respecto al valor de n:

Supongamos que tenemos 4 procesadores, entonces de izquierda a derecha los tendríamos:

CPU3 CPU2 CPU1 CPU0

1 para encendido y 0 para apagado. Entonces si por ejemplo queremos usar los 2 primeros procesadores (CPU0 y CPU1): 0011 binario cuyo equivalente en decimal es 3.

Para Linux:

De manera equivalente, los procesos deberán ejecutarse con el comando:

taskset [COREMASK] [EXECUTABLE]

donde [COREMASK] es el hexadecimal equivalente al binario que indica que procesadores se van a utilizar, y [EXECUTABLE] como se podrán imaginar, es precisamente el ejecutable del programa (.sh, binario u otro).

La única salvedad es que [COREMASK] se pone en notación hexadecimal, por ejemplo 3 en decimal es 0x3 en hexadecimal.

Para el tema del [n] y del [COREMASK] este enlace les puede servir: http://www.vlsm-calc.net/decbinhex.php

Fuente:

• http://xmodulo.com/2013/10/run-program-process-specific-cpu-cores-linux.html
• http://stackoverflow.com/questions/7759948/set-affinity-with-start-affinity-command-on-windows-7

Si me preguntan, la verdad es que ignoro que efectos adversos pueda tener ejecutar  un proceso de esta manera. Pero nunca está de más saber como hacerlo.

Clonando máquinas virtuales Linux

Una tarea relativamente habitual cuando se trabaja con entornos de desarrollo virtualizados es tener que agregar máquinas adicionales. Y para "ahorrarnos trabajo" (créanme que es sólo una falsa ilusión), utilizamos como "base" alguna otra máquina que ya tenemos creada y funcionando.
El problema: Hay alguna cosas que no se nos pueden olvidar, sino lo más probable es que nada funcione como esperamos.

Identificación de la máquina

Típicamente vamos a querer que cada nueva máquina tenga un nombre a lo menos descriptivo, que sirva para saber en que proyecto la tenemos.
En clones de máquinas Linux de sabor CentOS, o Red Hat (o similares), el nombre de la máquina está en el archivo /etc/sysconfig/network

En clones de máquinas Linux de sabor Debian, o Ubuntu (o similares), el nombre de la máquina está en el archivo /etc/hostname, pero además será necesario cambiar la referencia en el archivo /etc/hosts de modo que el IP 127.0.1.1 apunte al nuevo nombre.

Para que los cambios sean efectivos será necesario reiniciar la máquina virtual.

Configuración de red

Por una práctica más bien propia (mucho dirán que es de viejo mañoso), me gusta asignarle IPs fijos a las máquinas. Por ello al clonarlas reinicio la MAC de cada máquina virtual (lo que genera una MAC aleatoria), y utilizo una configuración de 2 tarjetas de red, una NAT y la otra virtual.

Lo primero será borrar el archivo /etc/udev/rules.d/70-persistent-net.rules que hace referencia a la MAC de la tarjeta de red de la máquina clonada (original).

En clones de máquinas Linux de sabor CentOS, o Red Hat (o similares),lo siguiente es editar los archivos /etc/sysconfig/networking/devices/ifcfg-eth*  borrando las líneas que hacen referencia a la MAC y la UUID.

Luego deberán reiniciar y sus máquinas virtuales estarán listas para jugar.

Si alguien tiene algún dato adicional o alguna corrección que agregar, pueden hacerlo en los comentarios.

Entrevistas de trabajo y pruebas de conocimientos técnicos (parte II) - Amazon

Siguiendo con la secuencia de artículos, en esta oportunidad me referiré a mi propia experiencia de entrevistas de trabajos con Amazon. Aparte de satisfacer la curiosidad de muchos amigos que estuvieron atentos a como me iba (en serio ¡gracias  todos ustedes! :) ), espero que mucho de lo que voy a escribir sirva de consejo para otras personas que vayan a enfrentar entrevistas con  Amazon.

La primera vez que me entrevistaron me contactaron por Linked In, esto fue a fines de Abril de 2013, mi suegra había fallecido recién, y la verdad mi estado de ánimo estaba afectado, fuera de la ansiedad natural de enfrentar a una prueba con una de las empresas más importantes del mundo.
La prueba en si fue escrita, 3 preguntas de Diseño Orientado a Objetos (OOD) y Codificación, y consideraban tus respuestas  siempre y cuando las hubieras contestado en 65 minutos o menos.

1. La primera  pregunta fue de diseño orientado a objetos. El requerimiento era modelar (y dentro de lo posible implementar) un software de diseño gráfico, algo así como Inkscape o MS Paint. No era difícil, pero era una pregunta larga, te podías complicar tanto como quisieras.
   

   Let's say we're developing a vector graphics application. It will allow the user to create lines, rectangles, circles, text, etc. and manipulate them independently - move them, resize them, etc. Design an object model for this application. (How would you model the representation of the document in an object oriented language? What classes would you define? What methods would you have? What would your API look like?)

2. La segunda pregunta fue de algoritmos y estructuras de datos. Se debía implementar un método que mostrara en pantalla el listado de amigos directos o por nivel (amigos de mis amigos) de una red social, y así sucesivamente. El problema real era como recorrer un árbol por nivel.
   

   Code printSocialGraph(Member m). Direct friends of m are Level 1 friends. Friends of friends are level 2 friends.....and so on
   Print level 1 friends first. Then print level 2 friends....and so on

3. La tercera pregunta era de programación de algoritmos eficientes. Pedían una implementación eficiente para calcular un ene-ésimo número de Fibonacci. Lo más "obvio" era haber implementado una especie de pila con memoria para futuras ejecuciones (o algo así), o usar alguna ecuación matemática avanzada para este  cálculo. Por un tema de tiempo hice la implementación recursiva tradicional, y lo más seguro que mal...
   

   Write an efficient function that returns the n’th Fibonacci number (There are many ways to solve this problem. Please write the most efficient method possible). Each Fibonacci number is the sum of the last two. The first 10 are: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55.
   long getNthFibonacci(long i) { ... }

Las cosas importantes que rescato de aquí:

• Prepararse para manejo de tiempo
• Repasar patrones de diseño
• Manejar las estructuras de datos básicas, árboles sobretodo y manejar los algoritmos para recorrerlos.
• Leer y entender algunos algoritmos de computación distribuida

Según he leído, la evaluación es bastante estricta en cuanto a la sintaxis, se espera poder copiar y pegar el código que hayan generado y que compile correctamente. Y una cosa que me llamó la atención es que la plataforma que utilizan para la prueba técnica literalmente graba el como vas respondiendo, probablemente para entender los procesos mentales detrás de cada respuesta.

En la segunda oportunidad me contactaron directamente a mi correo, seguramente debido a que ya tenían mi currículum de la oportunidad anterior. Ahora la entrevista sería telefónica, de 1 hora, y se me solicitaba tener acceso a internet y compartir una pantalla para escribir código colaborativo.

Después de una fallida entrevista, debido a mala conexión telefónica (moraleja, para llamadas internacionales NUNCA dar el celular, o línea fija o Skype (o similar)), logré que agendáramos la entrevista para otro día.
Llegado el día D, me entrevisté con el jefe del equipo de desarrollo al que postularía.

La entrevista se desarrollo de esta manera:

• Mohan me contó un poco que es lo que hacía en  Amazon  me fue preguntando sobre mi experiencia laboral reciente. Tengan presente cuál fue su trabajo más desafiante e interesante. Yo me equivoqué y cité una experiencia más del montón que destacable, era otro el proyecto sobre el que  me tuve que explayar.
• Al momento de la parte de preguntas técnicas comenzamos con generalidades. Al respecto, tengan frescos los conceptos de OOP, UML y estructuras de datos. Yo me enredé innecesariamente al intentar definir conceptos básicos. Afortunadamente Mohan (mi entrevistador) supo interpretar mi enredo y, quizás sin intención, guiarme hacia la respuesta correcta. No teman dar ejemplos, pero procuren que sean los ejemplos adecuados.
• Luego prosigueron las preguntas relativas a patrones de diseño. Mohan me preguntó sobre que patrones me resultaban familiares y cuales había utilizado recientemente. Esta fue la pregunta trampa. Mencioné conocer y haber trabajado con los patrones Singleton, Proxy, Command, MVC, y entre esos haber utilizado más recientemente el Singleton.
  Aquí pueden perderse o coronarse. Me hizo implementar el patrón Singleton, y aún bajo las traiciones de mi memoria, y muchos alcances de errores que me mencionó detectar, lo logré sacar. Ojo el patrón Singleton, así de paquete no es "thread safe" (i.e. múltiples threads llamando la clase en el mismo instante exacto no aseguran que el singleton funcione como es esperado), por lo que hay que sincronizarlo. Esto también fue parte de la entrevista. Yo no recordé la sintaxis de como sincronizar la llamada.
• Finalmente la parte técnica terminó con una pregunta tipo, y digo tipo porque recuerdo haberla visto en varios otros lados:
  

  Se tiene un archivo con líneas de texto con una palabra por línea. cada palabra puede ser un anagrama de otra, vale decir esta compuesta por las mismas letras que otra palabra pero en distinto orden. Ejemplos:
  { opt, pot, top }, { apt, tap, pat }, { casa, saca }
  Se pide determinar que grupos de palabras son anagramas entre si.

Esta pregunta clásica la razoné de la siguiente manera:

1. Agrupar las palabras según su largo (en caracteres) ya que entre palabras de igual longitud existe mayor probabilidad que sean anagramas entre ellas.
2. Recorrer este nuevo listado agrupado haciendo un chequeo de equivalencia para cada nueva palabra rescatada. Aquí mi idea apuntó hacia un "hashmap de múltiples llaves" (ERROR garrafal, eso no es un hashmap, y si lo fuera no es eficiente). Mohan me perdonó lo de las múltiples llaves, señalándome que efectivamente la cosa iba por un hashmap, y me dió como "hint" que ordenara las palabras. En un principio pense en ordenar todas las palabras, pero eso no tenía mucho sentido, hasta que ejemplificó:

• apt ordenado (alfabéticamente) es apt
• tap ordenado (alfabéticamente) es apt
• pat ordenado (alfabéticamente) es apt

Entonces la solución salta a la vista, hashmap donde la llave es la palabra ordenada.

Nuevamente me traicionaron la ansiedad, los nervios y el tiempo. Resolví el problema en seudocódigo, y finalmente me dijo si tenía preguntas. lo único que atiné a preguntar fue "¿Cómo es trabajar en Amazon? ¿es como resolver estos tests?" A lo que respondió que si, efectivamente su trabajo a diario es optimizar los procesos de  Amazon  sobretodo los procesos de distribución de paquetes para resolver los envíos minimizando costos tanto para clientes como para la empresa.

Cosas que rescato, y voy a repetir mucho de lo que mencioné más arriba:

• Asegúrense de establecer un canal de comunicación confiable, NUNCA por teléfono móvil.
• Tengan presente cuál fue su trabajo más desafiante e interesante.
• Tengan frescos los conceptos de OOP, UML y estructuras de datos.
• Tengan frescas las implementaciones de patrones de diseño simple (o en su defecto algún cheat sheet a mano).
• No tengan miedo a preguntar.
• Siempre seguros de lo que están diciendo, incluso al reconocer que no saben.

Consideren que la persona que los va a entrevistar tiene un nivel técnico muy alto, así que no le van a poder mentir sin que se de cuenta, muy acorde a los estándares de la empresa.
 Amazon exige profesionales de un nivel técnico MUY alto, con fuerte dominio en patrones de diseño y algoritmos, y sobretodo en algoritmos. No basta saber un poco de todo, o ser un especialista en determinada tecnología (sea herramienta, lenguaje de programación o arquitectura). Las pruebas DEMANDAN preparación A CONCIENCIA.
Y esto es porque el nivel de empresa que ha alcanzado Amazon, EXIGE excelencia, y la única forma de mantener ese nivel es con PROFESIONALES DE 1er NIVEL.

No es la típica entrevista donde con suerte sabes que te pueden preguntar. Todo está disponible para que puedas prepararte de la mejor manera:

• Cargo al que postulas, o la base desde la que te van a medir.
• Amazon Values que es básicamente lo que esperan de ti (en términos no técnicos)
• Pauta de preparación con la que uno debiera estudiar
• Recomendaciones generales para la entrevista

Yo no soy un tipo que "se peine" con algoritmos, mi fuerte ha sido resolver el día a día y tratar de hacerlo de la mejor manera. Por eso me siento honrado que una empresa como  Amazon me haya dado una oportunidad y haya destinado una hora de sus valiosos recursos en entrevistarme.

Como dijo un colega "El NO ya lo tienes", así que nada se perdía con intentarlo. Ustedes ya tienen más información de como enfrentar a este monstruo.

Nota a Mayo de 2020: Sí, estoy claro que pasados 7 años muchas cosas han cambiado. Sin embargo no puedo no dejar este enlace con ciertas apreciaciones que como joven desarrollador no investigué en su oportunidad. Lo feo de trabajar como desarrollador en Amazon: https://gist.github.com/bricker/cb811b3b86d767124801 Simplemente léanlo.

Recomendaciones generales para entrevista técnica con Amazon

Al momento de coordinar una entrevista con Amazon, te hacen llegar las sigueintes recomendaciones para que la entrevista se desarrolle de la mejor manera posible.

The technical interview will include (but is not limited to) questions related to Coding, Data structures, Algorithms and Object Oriented Design and will last about an hour.  Due to the technical nature of this interview, please do not drive or commute during your phone interview. Please consider the following interview tips: 1. Be in a quiet place where you are comfortable and there are no distractions .2. Have a copy of your resume available just in case you are questioned on it.3. Please have access to the internet during this time.4. Have any questions you have for the interviewer ready.5. If you will be speaking on your cell phone, please ensure that you are in a place with enough cell phone coverage to avoid any call drops.6. Review the job description and this link: Amazon Values

Nota a Mayo de 2020: Sí, estoy claro que pasados 7 años muchas cosas han cambiado. Sin embargo no puedo no dejar este enlace con ciertas apreciaciones que como joven desarrollador no investigué en su oportunidad. Lo feo de trabajar como desarrollador en Amazon: https://gist.github.com/bricker/cb811b3b86d767124801 Simplemente léanlo.

Pauta de preparación para pruebas técnicas de Amazon

Estas es la pauta de preparación que te hace llegar Amazon cuando postulas. Básicamente es lo que se espera uno debiera preparar.
¿Saben de otra empresa qué haga lo mismo? Yo no, y he hablado con muchas empresas. Este es el tipo de cosas que marca la diferencia entre las grandes empresas y el resto.

Work hard. Have fun. Make history.

Amazon.com/Careers

Thank you for the interest in Amazon.com and taking the time to speak with us about some of the exciting opportunities that we have available.  We’ve put this document together to help give you an idea of what types of knowledge we expect some level of familiarity with.

Preparing for Your Interview

At Amazon.com we’re looking for talented engineers that can apply the knowledge that they’ve learned in school and in industry to solving some of the world’s most complicated software problems.  As such, our interviews are mainly focused on how well you can use your acquired knowledge to solve real world (or in some cases not so real world) problems.  Below is a list of broad areas that we expect people to be familiar with.  It’s certainly not required that you memorize all of the information outlined below, but this should serve as a helpful reference guide for the types of things you might want to brush up on before interviewing with Amazon.com.

Programming Languages

We do not require that you know any specific language before interviewing for a technical position at Amazon.com, but familiarity with a prominent object oriented language is generally a prerequisite for success.  Not only should you be familiar with the syntax of a language like C++, Java, or C#, you should also know some of the language nuances such as how memory management works, what some of the most commonly used collections or libraries are, etc.  You should be able to compare languages and talk about the tradeoffs between using language X vs. language Y.

Additionally, it’s considered a plus to be familiar with some scripting language such as perl, ruby, awk, etc.  It’s also nice to know the basics of regular expression as they are now a mainstay in both the object oriented and scripting worlds.

Data Structures

Most of the work we do involves storing and providing access to data in efficient ways.  This necessitates a very strong background in standard data structures.  You should know what each of these data structures is and how they’re implemented; what their runtimes are for common operations; and under what circumstances it would be beneficial to use one.  The below are in no particular order.

Array

Linked List

Tree (Tree, Binary Tree, Binary Search Tree, Red-Black Tree, etc.)

Heap

Hash Table

Stack

Queue

Trie

Graph (both directed and undirected)

Algorithms

It’s also important to know efficient ways manipulate data.  One great way of doing this is brushing up on some common algorithms.  We’ll expect that you can apply and discuss the tradeoffs between some commonly used algorithms.

Sorting

Bubble Sort

Merge Sort

Quick Sort

Radix/Bucket Sort

Traversals (On multiple data structures)

                Depth First Search

                Breadth First Search

Coding

Expect to be asked to code syntactically correct code – no pseudo code.  If you’re a bit rusty coding without an IDE or coding in a specific language, it’s probably a good idea to dust off the cobwebs and get comfortable coding with pen and paper.  The most important thing a software engineer does at Amazon.com is write scalable, stable, robust, and well tested code.  These are going to be the main criteria by which your code will be evaluated, so make sure that you check for edge cases and common error inputs as well as the “happy paths” through the code.

Object Oriented Design

Good design is paramount to extensible, bug free, and long living code.  It’s possible to solve a software problem in an almost limitless number of ways, but when software needs to be robust and extensible, it’s important to know some common techniques that help with this.  Using object oriented design best practices is one way to build lasting software.  You should have a working knowledge of a few common and useful design patterns (singleton, factory, adapter, bridge, visitor, command, proxy, observer, etc.) as well as know how to write software in an object oriented way with appropriate use of inheritance and aggregation.

Databases

Most of the software that we write is backed by a database somewhere.  A lot of the challenges we face come in to play when interfacing with existing data models and when designing new data models.  You should know the basics of how relational databases work, how to design relational database schemas, as well as how to write basic SQL queries against a database.

Distributed Computing

Our systems at Amazon.com usually have to work under very strict tolerances at high load.  While we have some internal tools that help us with scaling it’s important to have an understanding of a few basic distributed computing concepts.  Having an understanding of topics such as map-reduce, service oriented architectures, distributed caching, load balancing, etc. will help you in formulating answers to some of the more complicated distributed architecture questions you might encounter.

Internet Topics

This is Amazon.com, we’re an online company and we expect our engineers to be familiar with, at least, the basics of how the internet works.  You might want to brush up on how internet browsers do what they do, DNS lookups, what TCP/IP and HTTP are, sockets, etc.  We’re not looking for network engineering types of qualifications, but a solid understanding of the fundamentals of how the web works is a requirement.

Operating Systems

You won’t need to know how to build your own operating system, but you should be familiar with some OS topics that can affect code performance, such as memory management, processes, threads, synchronization, paging, multithreading, deadlocks (causes, detection, avoidance).

Nota a Mayo de 2020: Sí, estoy claro que pasados 7 años muchas cosas han cambiado. Sin embargo no puedo no dejar este enlace con ciertas apreciaciones que como joven desarrollador no investigué en su oportunidad. Lo feo de trabajar como desarrollador en Amazon: https://gist.github.com/bricker/cb811b3b86d767124801 Simplemente léanlo.

Entrevistas de trabajo y pruebas de conocimientos técnicos (parte I)

Quisiera compartir algunas experiencias e impresiones relativas a algunas entrevistas de trabajo he tenido en mis años desempeñándome como ingeniero informático. Va a ser un artículo extenso, por lo que advierto al honorable lector que si no es conquistado por mi narrativa, es altamente probable que se aburra.

Hace yo diría un año atrás, aproximadamente, respondí a la consulta en Twitter de una persona con quien tuve la oportunidad de trabajar hace algunos años atrás. Necesitaba alguien que "se manejara con XML", a lo que dados los proyectos en los que trabajé, repliqué con un poco humilde "XML is spoken".
Algo así como un mes después de mi respuesta, Andrés me contacta telefónicamente para citarme a una entrevista, de la cual él no me entregó mayor información y equivocadamente (ya diré porqué) yo tampoco solicité mayores antecedentes. Antes de seguir consideren esto como una regla de oro:

SIEMPRE PREGUNTEN LOS TÉRMINOS DE LAS ENTREVISTAS A LAS QUE VAN A ASISTIR

Es esperable que un empleador serio y respetuoso por los postulantes a cargos disponibles informe sobre el carácter de las entrevistas que realizará. No es justo para los candidatos llegar sin preparación a un prueba técnica, o ser sorprendidos por una.

Una vez en la reunión, Andrés no pudo estar presente a la hora acordada, ya que debió responder a otro compromiso laboral, sin embargo encomendó a una colega de él el entrevistarme. Mi entrevistadora me explicó un poco lo relacionado con este trabajo, que resumiendo se trataba de desarrollos en torno a un Bus de Comunicación para múltiples canales de entrada. Un equipo de excelencia, muy acorde al modus operandi que ya me resultaba familiar.

Tras una interesante conversación con mi entrevistadora, ella me señala que mientras esperaba que Andrés pudiera desocuparse, contestara un test escrito de conocimientos técnicos. A pesar de no ir preparado, y sabiendo solamente que sería "algo con XML", lo contesté.
Aquí me dí cuenta que debí haber preguntado como se desarrollaría la entrevista.

Hubo muchas preguntas de caracter semi-general que supe responder sin problemas, pero un gran porcentaje eran cosas que sinceramente JAMÁS he resuelto a mano, y por ende si bien conozco y domino, delego "el trabajo sucio" en la IDE o en aplicaciones auxiliares. Algunos ejemplos fueron hacer un schema XML, y otro escribir un WSDL, ¡a mano! ¡sin IDE! Digamos que desde la prehistoria que muchos desarrolladores no hacen ninguna de esas tareas a mano.
Mi sensación de esta prueba fue que ni el mismo equipo de excelencia sería capaz de contestar un 60% adecuadamente. Y si así fuera realmente me preocuparía, ya que si bien se valora el conocimiento "a mano", hay infinitas tareas cuya resolución eficiente puede realizarse a través del buen uso de herramientas dispuestas para ello.

Luego llegó Andrés, conversamos un tanto, y bromeamos un poco respecto a que no hice trampa para contestar la prueba, buscando en Internet usando mi teléfono móvil. Finalmente llegamos al tema de pretensiones de sueldo, y por la cara de Andrés ni siquiera hubo intención de negociar.

Independiente del resultado de la prueba, que dada mi absoluta NO preparación, fue sencillamente indigno (y ya les contaré como me enteré de esto), Andrés conocía mi trabajo, y tenía una muy buena idea previa de mis capacidades, mal que mal trabajamos en un proyecto anterior bastante grande. La lamentable lectura que hice fue que sencillamente prefirió no trabajar conmigo, y sostuvo una decisión predefinida en mi pobre desempeño en la prueba técnica. Como si haberme entrevistado hubiera sido "por cumplir" o para "ver que tal". Triste sensación, pero sólo eso una sensación de.

Tiempo después un amigo me consideró para apoyarlos en un proyecto en la empresa donde él trabaja. Su jefe, que era un muy buen amigo de mi ex-jefe cuando trabajamos con Andrés, se refiere a mi como alguien que "no se manejaba", precisamente aludiendo a que sabía de mi mal desempeño en la prueba técnica que les comento.
Esto es otra confirmación de que el mundo es pequeño y redondo, y que de una u otra manera, tarde o temprano siempre vas a saber que pasa a tu alrededor. No mucho que decir por este impasse de discreción, y dejémoslo ahí.

Sobre las pruebas técnicas, sobre todo  aquellas que son muy extensas, tengo 2 posturas:

1. Por un lado no les encuentro sentido ya que no son representativas del verdadero potencial de un postulante.
   Un buen reclutador ES capaz de determinar si un postulante se ajusta al cargo al que postula.
   Un buen reclutador SE HACE ASESORAR por un experto (o al menos alguien con conocimientos) en las áreas que debe dominar el postulante.
   A un buen reclutador le es suficiente la entrevista personal con el postulante.
   
   Los nervios pueden jugar en contra del postulante, hay demasiados factores, incluyendo una evaluación absolutamente alejada de la realidad del modo de trabajo y desarrollo de la misma empresa, que pueden tener incidencia negativa en la calificación del candidato.
   
   En el peor caso el primer contrato normalmente es a prueba, por período no demasiado largos y se puede no renovar si el candidato no cumple los requerimientos del cargo.
2. Por otro lado, si los cargos demandan REALMENTE un conocimiento técnico experto, o la postulación requiere que la empresa tenga PLENA CERTEZA (minimizando el riesgo a cero o casi cero) que se escogerá al candidato adecuado, y si finalmente trabajar en esa empresa es REALMENTE ATRACTIVO, como por ejemplo trabajar en Amazon, Facebook, Google o alguna otra empresa de similar estampa, entonces las pruebas técnicas tienen todo el sentido esperable.

Hay un tercer caso donde en realidad mi pronunciamiento es sobre la empresa, y como delega la selección de personal más que la utilidad o no utilidad de la prueba.

Son empresas que solicitan responder a una prueba muy extensa, que trata los más diversos tópicos técnicos, y en las que el postulante realmente no sabe a que cargo postulará, o que es lo que realmente necesitan que sepa (ya me pasó en una empresa donde respondí una prueba que me paseaba desde shell scripts, a base de datos, a SOA, a Java, a PHP, a administración de sistemas, indistintamente), y en que aparentemente la misma empresa tampoco tiene claro que tipo de profesional necesita.

A mi parecer o se puede medir todas las experticias con una misma regla, ni evaluarlas con una misma prueba.

En la parte II pretendo referirme a las pruebas técnicas de  Amazon, de las que he conocido de cerca 2 variantes.

Nota a Mayo de 2020: Sí, estoy claro que pasados 7 años muchas cosas han cambiado. Sin embargo no puedo no dejar este enlace con ciertas apreciaciones que como joven desarrollador no investigué en su oportunidad. Lo feo de trabajar como desarrollador en Amazon: https://gist.github.com/bricker/cb811b3b86d767124801 Simplemente léanlo.

Respaldando un repositorio SVN

Hace poco necesitamos empezar a respaldar regularmente el SVN de la empresa en la cual trabajo. La idea es poder manejar respaldos regulares en una máquina distinta a aquella donde opera el repositorio de código.

Como es habitual, este artículo es de contenido técnico. SI no entiende nada de lo que escribo, entonces simplemente pase a saludar :)

El SVN se encuentra en una máquina Linux que está virtualizada.
La máquina donde se va a hacer el respaldo es una máuina física y está en otra red.

Lo primero es hacer que las máquinas se vean vía SSH sin necesidad de password. Para ello generamos certificados RSA, Pueden buscar por SSH public key no password login y algo encontrarán.

Lo segundo es mapear una carpeta física de la máquina destino (donde se hará el respaldo) dentro de la máquina del SVN. Esto lo haremos usando sshfs, que como quizás puedan deducir es un sistema de archivos (Files System) que opera vía SSH. Voy a suponer que ya tiene el sshfs instalado.
Entonces se deberán ejecutar los siguientes comandos en la máquina SVN:

SVN:~# sshfs @<>:
SVN:~# svnadmin dump | gzip -9 > `date +%Y%m%d%H%M%S`_.dump.gz

Para efectos de simplicidad, decidí automontar la carpeta. Para ello hay que tener un gran cuidado, e indicar en los parámetros que se reconecte la unidad al reiniciary que se permita la escritura a otros usuarios. también es importante indicar el uuid y el gid del usuario que se está conectando:
Editar el archivo /etc/fstab y agregar al final la siguiente línea:

sshfs#sshfs @<>:  fuse comment=sshfs,auto,users,exec,uid=,gid=,allow_other,_netdev,reconnect,transform_symlinks,BatchMode=yes 0 0

Y además agregué un script para realizar el respaldo.
Crear el archivo /bin/svnbackup con permisos 755 y las siguientes líneas:

#!/bin/bashsvnadmin dump $1 | gzip -9 > $2`date +%Y%m%d%H%M%S`_$3.dump.gz

Donde $1 es la carpeta del repositorio SVN, $2 es la carpeta de destino (importante terminarla en / ya que es una carpeta), y $3 es un identificador que permitirá distinguir el respaldo de otros (en caso de haber más repositorios).

Y si quieren simplificar aún más las tareas de respaldo, pongan el script en una línea en su archivo cron. Importante: Si van a usar cron usen el script, ya intenté poner el comando completo y no pude conseguir que funcionara.

Porqué usar herramientas obsoletas puede perjudicar tu empresa

Hace poco más de medio año que estoy trabajando en una transnacional que ha cambiado su nombre 3 veces. La promesa inicial era innovación, proyectos atractivos y proyección a futuro. La triste realidad es que todos los desarrollos son sobre una plataforma tan probada y archi-probada que estancó su evolución.

El escenario:

• Un equipo de ingenieros, programadores y desarrolladores, con buena formación académica.
• Una empresa, con promesas muy atractivas
• Proyectos de diversa índole (siempre en el contexto TI)
• Una  plataforma históricamente probada

La combinación de estos  elementos, no debiera ser mala, y no debiera NO funcionar... PERO:

• Cada nuevo proyecto demanda funcionalidades que no necesariamente están cubiertas por la plataforma base.
• Los componentes de la plataforma base se van actualizando con el paso del tiempo, mejorándose y corrigiendo errores.
• La oferta laboral siempre ofrece propuestas que SI tienen innovación.

El éxito de un proyecto, y por transitividad de la empresa, no radica en la capacidad de cautivar a tus clientes con una plataforma que solo la empresa puede manejar y mantener. Radica en la capacidad de poder sacar adelante los desafíos a los que se enfrenten, de manera eficiente (ya definiré eficiente), y poder responder a los requerimientos del cliente.

¿Qué entendemos por eficiente? EFICIENTE  es no reinventar la rueda. la rueda ya existe y lo más probable es que el problema base que se resuelve esté solucionado de mejor manera de lo que se podría conseguir. Claramente hay cosas que hay que desarrollar, pero en lo relativo a los componentes base ya existen muchos productos con una madurez no despreciable y comunidades sólidas que los respaldan.

¿Qué sucede cuándo usas herramientas obsoletas?

• La mayoría de los errores que se puedan detectar se solucionan con alguna actualización de versión.
• Agregar nuevas funcionalidades implicará repetir un desarrollo que ya se incorporó en nuevas versiones.
• Te enfrentas a problemas no menores de rendimiento.
• Limitas el crecimiento de tus desarrollos, sobre todo si los niveles de acoplamiento de la plataforma son muy altos.
• No existe una comunidad que ofrezca soporte a tu plataforma.
• Basta un cliente que haga una auditoría sobre los códigos y la plataforma para poner en tela de juicio la filosofía de desarrollo.
• Y finalmente, si tu equipo abre los ojos, probablemente se dé cuenta que si no se mejora ese esquema "seguro y probado", se estancará profesionalmente. Y una empresa sin un equipo  que la sostenga no funciona.

Dejemos la resistencia al cambio a los clientes, y no como una constante dentro de las propias empresas, menos si son las propias jefaturas las que la amparan escudándose en tener al cliente cautivo.

Si insisten en sobrevivir en torno a desarrollos sobre plataformas obsoletas háganlo en caso que estén prontos a jubilar (y en realidad poco les interese la continuidad de la empresa), o si la vida útil de los proyectos desarrollados es baja (menor a un año).

En materia de TI, y siguiendo una línea de tiempo, se avanza hacia adelante. No te quedas estancado en un punto fijo, ni tampoco caminas hacia tus espaldas.

Diseño orientado al pixel vs Diseño web

Hace algún tiempo que me vengo relacionando con varios amigos diseñadores. Debo decirlo, sus trabajos gráficos son increíbles, pero lamentablemente tienen poca o nula idea de diseño web.

En cuanto a mi apreciación, ¿porqué tan radical? se preguntará el honorable lector. Muy simple, la mayoría de ellos dibuja muy bonito, sabe usar Photoshop (cosa que yo no sé), pero son todos obstinados en cuanto a su diseño. Cuando se ponen a diseñar sitios web, insisten en usar anchos fijos, ubicaciones estáticas, todo orientado al pixel.

Y esto es herencia de su escuela, muchos aprendieron diseño en papel, o diseño digital. Saben a la perfección de paletas de colores, colores complementarios, balance en la imagen, y muchos otros conceptos que claramente yo NO manejo ni conozco. Pero no saben de diseño web, y de como focalizar un trabajo gráfico increíble en la atención de los visitantes del sitio.

Con el tiempo he desarrollado la capacidad de poder pasar un diseño en PSD, o una simple imagen, a una versión web con HTML y CSS, sin demasiado esfuerzo. Pero ello implica saber, y sobretodo entender que el diseño orientado al pixel aplicado a web es contraproducente. Hay un desgaste no menor tratando de alinear todo a la perfección, y si el diseñador no está consciente de esto, y el cliente tampoco, entonces puede ser un factor bastante negativo para el proyecto.

Para web el diseño que sirve es netamente conceptual:

• Paleta de colores adecuada
• Ubicación referencial de los elementos importantes de cada página
• Imágenes de fondo
• Tipografías

Incluso muchos de esos elementos ya son la sintonía fina del diseño. 

No es tan necesario esforzarse tanto en que el diseño esté pensado para pantallas de 1024x768 con un contenedor de 980px y un espacio útil de 960px, y que todo encuadre perfectamente en esas dimensiones. Tarde o temprano alguien con otra resolución verá el sitio y este se verá mal, y lamentablemente, siempre pensando en diseño web,  no se puede satisfacer todas las necesidades de diseño. Pensemos solamente en los distintos dispositivos móviles en los cuales se podría ver el sitio, y la orientación del dispositivo (vertical u horizontal).

No digo que para el diseño web no sirva ajustarse a una resolución, pero no pensar en el pixel. Es hora de que, ustedes amigos diseñadores, empiecen a distinguir cada elemento y cuál es su importancia en el diseño web, más que solamente ver si debe estar 10px a la derecha de la imagen principal y cuadrar dentro de un espacio de 960px.

Web 2.0 y tus clientes - Parte 1

Hay empresas y particulares que captan clientes, promocionan sus productos y servicios, y han hecho su reputación en función de la llamada Web 2.0 , y que sin embargo no entienden, ni saben aprovechar su intrínseco aspecto social.

Lo ejemplificaré con 2 casos a los que me enfrenté, ninguno relacionado con el otro, con la salvedad de haberme afectado a mi.

Primer caso) Luthier del Sur

Uno de mis hobbies es tocar guitarra y bajo, y tengo a mi haber algunos instrumentos que por un tema de espacio tenía que almacenar en otra disposición. Navegando por internet encontré un luthier de la VIII región de Chile, Lutheria Vettan.
Debo reconocer que Víctor Rivera hace un trabajo increíble con la madera, y ha sabido sacar un enorme provecho del aromo australiano, árbol que crece casi como la maleza en la VIII región.

Mi requerimiento, comparativamente a lo que es construir un instrumento, era sencillo, un soporte de muro para 5 guitarras (en rigor 3 guitarras eléctricas, una guitarra acústica y un bajo). Algo como esto:

Lo contacté por primera vez el 5 de abril (fecha de mi cumpleaños) del 2011, y en esa oportunidad Víctor había ganado unos fondos concursables y debido a todo lo que estaba realizando no pudo atender mi requerimiento.
Comprendiendo la situación dejé pasar un mes y le recordé el tema. En esta oportunidad Víctor me solicitó comprar unos soportes metálicos para guitarra que encontré en una empresa llamada Vroka y lo hice. Esto fue la última semana de mayo de 2011.

A eso de mediados de junio, envié los soportes y supuestamente ahí empezaría el trabajo.
Después de darnos cuenta que estábamos pensando en soportes distintos determinamos que le enviaba los soportes, ya que él podría darles un mejor uso que yo, y que me depositara el costo. Siempre de buena fe. Como de todas formas yo necesitaba un soporte seguí confiando en el profesionalismo de la cabeza de Luthería Vettan. Durante Julio fueron varios correos del tipo "Estoy avanzando", "Ya te envió fotos de lo que llevo", etc. Finalmente en Agosto hice mi última consulta y me dijo que no había podido avanzar.

Decidimos dejarlo en nada, y sólo en enero de 2012 le consulté si podía visitarlo, ya que estaría de visita en la región, para hacerle nuevamente el encargo. Ese correo NO recibió respuesta.

¿Qué tiene que ver esto con la Web 2.0?

La Web 2.0 es la visión social de Internet, te haces de una reputación, muestras tus productos, haces de tu negocio algo con integración social.
Si como empresario, proveedor o emprendedor, adoptas esto como parte de tu negocio, mínimo que respondas acorde, y que no mates esta vía.

Ya que nuevamente me quedaba sin soporte en marzo de 2012 decidí intentar nuevamente, pero con otro luthier. Mestizo Luthier de Valdivia (al sur de Chile) había comentado en un foro que disponía de herramientas para hacer trabajos de tipo CNC en madera, y también tiene trabajos muy lindos.
Lo contacté, le envié un plano bastante rudimentario de como quería el soporte, confié en la experticia Luis Carrasco, el luthier, y cuento corto, los primeros días de abril tenía un hermoso soporte en mi poder.

Aquí la galería de fotos

Comunicación constante y transparencia desde el principio. Sin tanta promoción, Mestizo sabe como fidelizar a sus clientes.

Al poco tiempo, y dado que las redes sociales son bastante gritonas, y dado también que mi soporte de guitarras causó cierta revolución, Vettan publicó un comentario tipo "me copiaron el diseño/este diseño me resulta familiar", y yo, con cierta molestia arrastrada por casi un año, le dije que él mejor que nadie sabía porque las cosas se habían dado de esa manera. Por interno tuvimos réplicas, pero finalmente le pedí disculpas por el impasse.

Quiero dejar claro que no me cabe duda que Víctor Rivera, de Luthería Vettan, es un excelente luthier y artesano, por eso fue que lo elegí como primera opción y confié en el trabajo que ví en fotos y en su sitio web . En esta oportunidad simplemente no se dieron las cosas, y no se supo manejar a un cliente que se mostró más que paciente.
Culpemos a la distancia y al conocimiento informal del manejo empresarial y del marketing.

La Web 2.0 es un tema complejo, y no estoy hablando de diseño con brillos y reflejos, sino de la parte social intrínseca a la definición. Si adoptas este aspecto de la "mal-llamada" Web 2.0 entonces tienes que entender que si no eres el único proveedor, y no cumples, las mismas redes que te han hecho increíble publicidad pueden generar un innecesario ruido negativo.

Acceso vía REST a listas de Sharepoint 2013

Por un proyecto que estamos siguiendo en mi actual trabajo tenemos que realizar una serie de integraciones con MS Sharepoint 2013. Entre ellas una interfaz "algo" compleja para las búsquedas, que demandó realizar un WebPart particular que se encarga de realizar la búsqueda con una toxi-consulta CAML, y luego se rescata el detalle de cada registro usando el  plugin jQuery SPWebServices.

Debido a un error que prefiero no mencionar para no perjudicar a los inocentes, estuvimnos mirando que maneras alternativas teníamos para rescatar esta misma información, y en esta búsqueda llegamos a la API REST de Sharepoint 2013.
Esta API nos provee de una vía bastante intuitiva para abordar temas como la recuperación de registros, sobretodo si hay conocimiento de la lista a la que pertenece y su correspondiente Id (siempre del registro).

Nosotros hicimos algunas trampas, en la lista de origen teníamos en las etiquetas data de los enlaces de cada registro tanto la lista como el id que he mencionado.

Básicamente los pasos a seguir son:

• Identificar las listas disponibles, de modo de poder identificar el nombre de la lista (su título). Para ello pueden abrir la URL:
  
  http://[servidor sharepoint]/_vti_bin/listdata.svc
• Recuperar el registro utilizando la interfaz REST, abriendo la URL:
  
  http://[servidor sharepoint]/_api/Web/lists/getByTitle('[nombre de la lista]')/Items([id numérico])
• Otra manera de hacer exactamente lo mismo es usando la URL:
  
  http://[servidor sharepoint]/_vti_bin/listdata.svc/[nombre de la lista]([id numérico])

Notar los paréntesis en la llamada.

Con esto se recuperará un XML bastante tóxico y sin embargo bastante legible, sobre el cual pueden realizar las operaciones que determinen convenientes según sus requerimientos.
Si esto lo combinamos con un poco de jQuery, AJAX, y eventualmente algo de JSON (entiendo que haciendo la llamada adecuadamente se puede recuperar el resultado en JSON, pero por tiempo no lo verifiqué) se podrían hacer cosas bastante entretenidas.

Eso lo dejamos o para el pedido del público o para otro artículo más adelante.
Dudas, comentarios, aportes y observaciones son siempre bienvenidas.

Cabe advertirles que mi paso por Sharepoint es netamente circunstancial debido a este proyecto que espero se termine pronto.

Integración Fancybox y Flowplayer (en Sharepoint)

Advertencia: Este artículo no necesariamente está pensado para el lector casual

Por un desarrollo Sharepoint en el que me ha tocado participar por la empresa donde trabajo, se tuvo qeu hacer una integración de Fancybox con Flowplayer, JavaScripts para una galería de fotos en ventanas modales y un reproductor de videos respectivamente, ambos para desarrollos web. Personalmente ni Fancybox ni Flowplayer son santos de mi devoción, hubiera preferido optar por PrettyPhoto y algún otro reproductor de video en HTML5 .

El consultor que se está encargando de los desarrollos Sharepoint (y el responsable indirecto de esta publicación) me señaló que había un script llamado FancyPlayer que hacía la mencionada integración. El problema es que esta integración se hace con versiones algo desactualizadas de ambos script.

Con las versiones más actuales la integración en realidad es bastante directa.
Paso a paso:
1.- Agregar los siguientes estilos solamente para el ajuste:

.flowplayer { margin: 1em auto; height: auto; text-align: center; } .flowplayer video { width: 90%; } .fancybox-nav { top: 35%; height: 30%; width: 40px; } .fancybox-next { right: -1.3em; } .fancybox-prev { left: -1.3em; }

Aquí hay varios estilos que son para el ajuste de los botones de navegación en las galerías. Loss estilos importantes son los referentes al tamaño del contenedor flowplayer.

2.- Hacer que cada bloque de código que lleve la clase flowplayer (normalmente un div con el atributo class="flowplayer") especifique en el atributo style el ancho y alto del video (esos parámetros se pueden obtener usando Sharepoint).

3.- Agregar el siguiente código en el bloque $(document).ready( function(){ /* aqui */}); :

$('.flowplayer').flowplayer({ swf: '/_layouts/15/js/flowplayer.swf' }); $('div.gallery div.photo a').fancybox({ scrolling: 'no', autoSize:true , helpers: { overlay: { locked:false}} });

Aquí lo importante es que los videos se desplegarán del tamaño que especifique el elemento contenedor.
Y sería. El resto es solamente referirse a la documentación de ambos plugins.

Esta integración no es exclusiva para Sharepoint, claramente la pueden extrapolar a desarrollos no-Sharepoint, y claramente pueden mejorarla.

Escritorios múltiples en Windows al estilo de Compiz

La advertencia habitual: Es probable que este artículo no sea del interés común. Léalo y vea si le interesa (nunca se sabe).

En mi ambiente de trabajo Linux tengo un Compiz ligeramente personalizado.
4 escritorios dispuestos en una "pared" de 2x2.

• La esquina superior derecha me muestra las ventanas abiertas
• La esquina inferior izquierda me muestra la pared de escritorios
• La combinación Control+Alt+Flecha Derecha me desplaza al escritorio siguiente
• La combinación Control+Alt+Flecha Derecha me desplaza al escritorio anterior
• Los botones laterales de mi mouse funcionan igual que las combinaciones de teclas antes mencionadas

En la oficina estoy condenado a utilizar Windows (de hecho Windows 8 :-S ), y mi idea era poder tener algo similar, que no consumiera demasiados recursos extra.

Ya había explorado un poco el tema de los escritorios múltiples sin encontrar una solución decente, hasta que repetí la búsqueda y encontré el programa Dexpot.
Provee las mismas funcionalidades de Compiz, salvo por los efectos visuales, y la configuración de teclas.

La configuración de teclas quise manejarla utilizando los controladores de mi mouse, un descontinuado A4Tech X-750F, y su software Smart-X7, sin embargo Windows 8 se mostró reacio a aceptar las configuraciones que indiqué.
Realizando una nueva búsqueda llegue al programa X-Mouse Button Control (no confundir con el XMBC, que es una media center).

Con ese programa es muy fácil configurar las acciones para los distintos botones del ratón, de hecho lo que hice fue simplemente mapear los botones adicionales a los atajos de teclado.

Lo mejor de todo es que funciona, y no hay una pérdida sustancial de rendimiento en mi máquina (esto puede variar de una máquina a otra, dependerá de las especificaciones de hardware).

eSata en Ubuntu

Advertencia: Lo habitual, esto es un artículo técnico sin relevancia para el lector casual. De hecho es caso un recordatorio en caso que llegara a olvidar la secuencia de comandos.

Problema: Tienes a tu disposición una unidad de disco duro externa con capacidad de conexión eSata, lo que es muy positivo considerando que la velocidad de transferencia de datos (lectura y escritura) es mucho muy (intencionalmente mal redactado para denotar la ganancia) más rápida que por USB. Lo conectas a la entrada eSata y Ubuntu no la reconoce a menos que reinicies con la unidad conectada (lo que es absurdo si piensasa que un eSata es hotplug).

Solución (paso a paso):

1. Instalar las scsitools con el comando:
   $ sudo apt-get install scsitools
   Va a pedir la clave ya que la estamos ejecutando en modo root a través de sudo.
2. Conectar la unidad eSata.
3. Ejecutar el comando:
   $ sudo rescan-scsi-bus
   lo que va a refrescar las unidades conectadas.
4. Montar la unidad eSata (suele funcionar el click derecho y montar, sino derechamente explorar la unidad) y a trabajar.

Suerte.