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.