miércoles, 27 de mayo de 2015

Ptron Singleton




El patrón de diseño singleton (instancia única) está diseñado para restringir la creación de objetos pertenecientes a una clase o el valor de un tipo a un único objeto.
Su intención consiste en garantizar que una clase sólo tenga una instancia y proporcionar un punto de acceso global a ella.
El patrón singleton se implementa creando en nuestra clase un método que crea una instancia del objeto sólo si todavía no existe alguna. Para asegurar que la clase no puede ser instanciada nuevamente se regula el alcance del constructor (con atributos como protegido o privado).
La instrumentación del patrón puede ser delicada en programas con múltiples hilos de ejecución. Si dos hilos de ejecución intentan crear la instancia al mismo tiempo y esta no existe todavía, sólo uno de ellos debe lograr crear el objeto. La solución clásica para este problema es utilizar exclusión mutua en el método de creación de la clase que implementa el patrón.
Las situaciones más habituales de aplicación de este patrón son aquellas en las que dicha clase controla el acceso a un recurso físico único (como puede ser el ratón o un archivo abierto en modo exclusivo) o cuando cierto tipo de datos debe estar disponible para todos los demás objetos de la aplicación.


C#:
public class Singleton
{
    // Variable estática para la instancia, se necesita utilizar una función lambda ya que el constructor es privado
    private static readonly Lazy<Singleton> instance = new Lazy<Singleton>(() => new Singleton());
 
    // Constructor privado para evitar la instanciación directa
    private Singleton()
    {
    }
 
    // Propiedad para acceder a la instancia
    public static Singleton Instance
    {
        get
        {
            return instance.Value;
        }
    }
}
 
// Clase de prueba
public class Prueba
{
   private static void Main(string[] args)
   {
     //Singleton s0 = new Singleton();  //Error
     Singleton s1 = Singleton.Instance;
     Singleton s2 = Singleton.Instance;
     if(s1==s2)
     {
       // Misma instancia
     }
   }
}


C++


template <class T>
class Singleton
{
    public:
        static T& Instance()
        {
            static T laInstanciaSingleton; //asumir T posee un constructor por defecto
            return laInstanciaSingleton;
        }
};
 
class Singleton : public Singleton<Singleton>
{
     friend class Singleton<Singleton>; //para dar acceso al constructor privado de SoloUno
     //..definir aquí el resto de la interfaz
};

JAVA:

public class Singleton {
    private static Singleton INSTANCE = new Singleton();
 
    // El constructor privado no permite que se genere un constructor por defecto.
    // (con mismo modificador de acceso que la definición de la clase) 
    private Singleton() {}
 
    public static Singleton getInstance() {
        return INSTANCE;
    }
}



public class Singleton {
    private static Singleton INSTANCE = null;
 
    // Private constructor suppresses 
    private Singleton(){}
 
    // creador sincronizado para protegerse de posibles problemas  multi-hilo
    // otra prueba para evitar instanciación múltiple 
    private synchronized static void createInstance() {
        if (INSTANCE == null) { 
            INSTANCE = new Singleton();
        }
    }
 
    public static Singleton getInstance() {
        if (INSTANCE == null) createInstance();
        return INSTANCE;
    }
}



JAVASCRIPT

Singleton = function Singleton$constructor() {
    return { 
        getInstance : function Singleton$getInstance() {
            return this;
        }
    };
}();
Unknown Web Developer

Maven?





Que es Maven?

Maven es una herramienta open-source, que se creó en 2001 con el objetivo de simplificar los procesos de build (compilar y generar ejecutables a partir del código fuente).
Antes de que Maven proporcionara una interfaz común para hacer builds del software, cada proyecto solía tener a alguna persona dedicada exclusivamente a configurar el proceso de build.
Además, los desarrolladores tenían que perder tiempo en aprender las peculiaridades de cada nuevo proyecto en el que participaban.
Si queríamos compilar y generar ejecutables de un proyecto, teníamos que analizar qué partes de código se debían compilar, qué librerías utilizaba el código, dónde incluirlas, qué dependencias de compilación había en el proyecto…
En el mejor de los casos, se empleaban unos pocos minutos para saber cómo hacer una build del proyecto. En el peor de los casos, el proceso de build era tan complejo que un desarrollador podía tardar horas en saber cómo compilar y generar los ejecutables a partir del código.
Ahora, la build de cualquier proyecto Maven, independientemente de sus módulos, dependencias, librerías…consiste simplemente en ejecutar el comando mvn install.
Por otra parte, antes de Maven, cada vez que salía una nueva versión de un analizador estático de código, de un framework de pruebas unitarias (como JUnit) o cualquier librería, había que parar todo el desarrollo para reajustar el proceso de build a las nuevas necesidades.
Y… ¿cómo se ejecutaban las pruebas? ¿Cómo se generaban informes? Sin Maven, en cada proyecto esto se hacía de distinta manera.

Unknown Web Developer

martes, 26 de mayo de 2015

Curso Andruino


Unknown Web Developer

lunes, 25 de mayo de 2015

Como evitar Ataques de XSS en PHP



Unknown Web Developer

domingo, 24 de mayo de 2015

Big Data?



Big Data se define como el conjunto de herramientas informáticas destinadas a la manipulación, gestión y análisis de grandes volúmenes de datos de todo tipo los cuales no pueden ser gestionados por las herramientas informáticas tradicionales. Big data es un término de origen inglés cuya traducción equivale a "Datos masivos", la tecnología big data tiene por objetivo analizar datos e información de manera inteligente que ayuden a una correcta toma de decisión.


Enlace : http://www.quees.info/que-es-big-data.html
Unknown Web Developer

Sobre el deficit de ingenieros en el sector de software Colombiano.


(la versión original de este articulo en inglés se encuentra aquí)
TL;DR: Mi experiencia me ha mostrado que no hay una escasez de ingenieros talentosos en Colombia, sino más bien una escasez de empresas con buenas culturas de ingeniería en las que estos ingenieros desean trabajar. Aunque la educación para Ingenieros de Sistemas no está a la par con los estándares de EEUU, la calidad y el contenido son impulsados por la industria existente y las necesidades de quienes contratan y lo que exige el mercado local. Necesitamos mejores empresas, no más ingenieros.


Mirando las cifras
La culpa es de la industria
¿Existe un déficit de ingeniería para las startups de tecnología en Colombia?
¿Dónde están todos los programadores calificados?
No puedo encontrarlos. Por lo tanto, no existen
Por qué usted no puede encontrar buenos ingenieros
No se puede comprar cultura de ingeniería con perks estúpidos.
¿Por qué habría de dedicarle a usted la porción más productiva de mi vida para construir su visión “innovadora” a cambio de poco?
¿Qué hace a una buena cultura de ingeniería?
  1. Profundo entendimiento de la disciplina de la ingeniería de software por parte de los ejecutivos y fundadores quienes han tenido una extensiva experiencia técnica.
  1. Respeto por la calidad de todo el software producido, resultando en amplios tiempos dedicados a la investigación y al diseño, buenas prácticas de pruebas y excelente documentación incluso cuando algunas veces tienen que ponerse al día (Twitter).
  1. Interés genuino, contribuciones constantes y apoyo financiero de proyectos Open Source y las comunidades.
La búsqueda eterna del Producto Minimo Viable (PMV)
Muéstrenos su GitHub
Los ingenieros de sistemas colombianos conocen de software, hardware, diseño, administración de redes, y mucho más. Sin embargo, pocos de ellos son capaces de contribuir a proyectos open source globales. De hecho, y muy desafortunadamente, Colombia es uno de los países menos activos en GitHub — Alex Torrenegra

Recomiendo ir a Twitter y leer todo este tConclusión


Apéndice A (que articulo tan largo)¿Qué se puede hacer para encontrar buenos ingenieros?
  • Todos los ingenieros miembros de Ride pueden clasificar para un bono anual de Open Source si invierten al menos 20hrs/mes de su propio tiempo durante 3 meses consecutivos. Esto no solo incluye contribuciones de software, sino además desarrollo comunitario, esfuerzos en educación de software, organización de eventos y evangelización.
  • 4 miembros de nuestro equipo se han vuelto fundadores/coorganizadores de uno o más meetups desde que se unieron a Ride. Incluyendo uno que se enfoca en mejorar los espacios para las mujeres en el software y los primeros meetups de Elixir y Golang en Colombia. El liderazgo de comunidades está en nuestro ADN.
  • Publicamos nuestro primer ember addon hace unas pocas semanas y ya tiene más de 150 descargas.
  • Estamos en los pasos finales para obtener una política open-source oficial.
  • Todos los miembros de nuestro equipo tienen un estipendio educativo, que puede ser usado para asistir a conferencias, tomar cursos, comprar libros o incluso patrocinar cualquier evento o meetup de su elección!!
  • Ya hemos patrocinado y hemos sido voluntarios en una conferencia y 5 meetups de software diferentes.
  • 3 miembros de nuestro equipo participan en la organización de 3 conferencias de software diferentes este año, y muy probablemente Ride las patrocinará también.
  • Cualquier conferencia aceptada por los miembros del equipo Ride viene con nuestro apoyo. Cubriremos vuelos, acomodación, guardería, y transporte para las parejas de estos nuevos padres cuando sea necesario.
  • Todo lo anterior ya se encuentra financiado para los próximos 2 años gracias a la gigantesca cantidad de dinero que ahorramos en tarifas de reclutamiento standard (20–30% del salario anual) durante nuestro primer periodo de contratación de 13 ingenieros ( 0 empleos fueron publicados en bolsas de empleo)
  • Ya comenzamos a estructurar nuestros programas de pasantías para estudiantes aspirantes tanto en NYC como en Colombia. Estamos en conversaciones con las mejores universidades del país y hemos logrado muy buenos avances para establecer prácticas profesionales de alto nivel con nuestro equipo.
No puedo esperar a que publique su próximo artículo, ¡tengo que armar mi equipo ahora!
No hace mucho tiempo, mi buen amigo Alex Torrenegra publicó un post en el blog de su empresa el cual atrajo bastantes comentarios y provocó una conversación muy interesante entre la comunidad de desarrolladores de software en la región.
Asumiendo que usted se ha tomado el tiempo para leer este artículo, lo que encontrará a continuación es un análisis profundo de lo que he aprendido a lo largo de los últimos 5 años, armando equipos de ingeniería y brindando soporte a comunidades Open Source (código abierto) en los Estados Unidos y en América Latina. Yo solía tener una posición muy similar antes de volverme un participante activo de la comunidad de desarrolladores colombianos. Y, en ese momento encontré que el “déficit de ingeniería” (no solamente software) en Colombia era un tema nuevo. Hoy en día esta conversación se está volviendo más mainstream (popular), en gran parte debido a la creciente popularidad de las startups de tecnología y las más diversas formaciones de las personas que quieren construirlas, ya no son en su mayoría ingenieros.
Se pueden encontrar publicaciones acerca de este déficit/crisis en Colombia que se remontan al 2008, y continuamente a través del 201020112012,2013, y 2014. Le he dedicado una cantidad significativa de mis recursos personales a lo largo de los últimos 5 años a promover el desarrollo de software en la región. Hoy puedo decir que me han hecho ver que estaba equivocado numerosas veces en lo que respecta a esta suposición, y me gustaría compartirles con cierto detalle por qué pienso que la creencia sobre la escasez de “buenos desarrolladores” en Colombia no está muy bien fundamentada.
La mejor prueba que tengo es el nivel superior de ingenieros que se han unido al equipo de Ride en los últimos 4 meses. No somos una empresa colombiana y aun así 70% (9 miembros) de nuestro equipo principal de ingeniería está distribuido entre Barranquilla, Medellín y Bogotá. Cada semana veo el trabajo que hemos estado haciendo y me digo a mí mismo “Nunca jamás voy a poder armar un equipo de este nivel nuevamente”, pero como no hemos lanzado nuestro producto aún, tendrán que creer en mi palabra por ahora. Espero se den cuenta de lo que quiero decir cuando lo hagamos público en los meses que vienen.

Colombia es un país en vías de desarrollo donde el conocimiento académico y la investigación no son tan prestigiosos como en los países desarrollados. Es difícil dedicarle mucho tiempo a contestar preguntas académicas cuando más de la mitad de tu población apenas y puede sobrevivir. Esto está ilustrado por el hecho de que entre 1960–2000 solo 162 PhD se graduaron en todas las áreas de estudio (1). Esta cantidad ha crecido enormemente a 909 entre los años 2001–2010 (2). Yo diría que es un paso en la dirección correcta. De cualquier forma en que se le mire, no se estaría equivocado al decir que nuestro sistema educativo necesita trabajar mucho más duro y que nuestra economía necesita mejorar para que podamos dedicarle más de nuestros recursos a la academia.
Asombrosamente, en el mismo periodo de 2001–2010 hubo 108.784 Ingenieros de Sistemas que se graduaron (3), convirtiéndola en la carrera profesional con la cuarta cantidad más alta de egresados en todo el país. Considerando que solo se graduaron 24.618 abogados más que Ingenieros de Sistemas (4), yo francamente encuentro esa cifra muy impresionante. Aún más impresionante es el hecho de que un anonadante 39% de egresados eran mujeres. Desde una perspectiva puramente numérica, se me dificulta ver el déficit.

Culpar a las universidades por la falta de Ingenieros de Software es tal como culpar a las mismas por la falta de Ingenieros Nucleares. Es cierto que no hay Ingenieros Nucleares en Colombia, pero no solo porque la carrera no exista, sino también porque no hay demanda por alguien con estas habilidades en la economía colombiana.
Volvamos al problema el cual Alex, y que muchos otros con los que he hablado, enfrentan en Colombia. Su versión de un ingeniero de Software es una definida por la cultura de las startups. Están construyendo nuevas empresas de tecnología en Colombia, y aun cuando su mercado objetivo es algunas veces local, están compitiendo contra los mejores equipos de ingeniería en el mundo ubicados en centros tecnológicos establecidos como Silicon Valley (SV). Las empresas colombianas están buscando habilidades técnicas muy específicas en una cantera de talentos en donde estas habilidades no son valoradas.
La industria del software en Colombia está compuesta casi en su totalidad por dos grandes sectores: software empresarial y consultorías de software.Fedesoft es una organización dedicada a la promoción y el crecimiento de la industria del software en el país (5). Para la fecha en que fue publicado este artículo, 100% de los miembros de la junta directiva de esta organización eran ejecutivos en empresas que se enfocan en proveer ya sea soluciones de software empresarial o servicios de consultoría en software. Ya que estas son las empresas que dominan el panorama del software, son ellas quienes determinan cuales habilidades se necesitan para hacer parte de su población activa. La vasta mayoría de estas empresas se enfocan en lenguajes más antiguos, herramientas y prácticas más anticuadas que aquellas utilizadas por startups más pequeñas y ágiles.
Cuando el mercado laboral determina qué habilidades anticuadas se requieren para ser empleado, las escuelas y universidades no pueden escoger enseñar a sus estudiantes sobre tecnologías vanguardistas. Esto pasa en todas las industrias, pero la velocidad a la cual avanza nuestra disciplina es significativamente mayor que la de las demás. La ley de Moore está vivita y coleando.
En Colombia tenemos una industria de software que no está lista para contratar personas que están experimentando con Go o Rust (lenguajes de programación muy modernos que están siendo desarrollados por Google y Mozilla) porque el mercado que hemos creado nosotros mismos no es uno de innovación. Más importante aún, no se puede esperar encontrar una industria con miras al futuro cuando la organización que trata de promoverla se encuentra trabajando activamente con el Congreso Colombiano en una ley bastante limitante y desmesurada que apunta a regular todo el software colombiano y agregar burocracia al proceso de innovación.
Entonces, cuando el Ministro de Tecnología, e instituciones relacionadashablan de un déficit de ingenieros, se están refiriendo a los miles de trabajadores que estas fábricas de software necesitan para seguir creciendo. Es una industria que está comenzando a tener un mayor impacto en la economía y existen importantes intereses políticos, lo cual quiere decir que se convierte en una industria que le importa al gobierno. Esta es una industria dedicada a replicar e importar la innovación de alguien más, brindar soporte al cliente para el software creado por otros, ofrecer mano de obra barata a mercados internacionales (near-shoring), y enviar enormes piezas de software mal diseñado a instituciones gubernamentales y empresas que tienen poco conocimiento de cómo medir su calidad.
Esta industria definitivamente tiene un déficit y es un problema que ella misma se ha creado. No son un sector atractivo para trabajar, incluso tras haber aumentado los salarios gracias a una afluencia de consultorías extranjeras y empresas near-shoring. La industria del software empresarial en Colombia necesita poner los pies en la tierra, mejorar su estándares y condiciones laborales generales, si quiere algún día llegar a ser un sector competitivo. Yo diría que esta industria tiene dos problemas, uno relacionado con la manera en que se venden como empleadores y la otra relacionada con hacia donde han llevado la calidad de la educación en las facultades de ingeniería. Solo se volverá más difícil para ellos atraer talento mientras los jóvenes ingenieros se dan cuenta que sus habilidades tendrán un impacto más grande si trabajan para startups, o compañías más interesantes como Google, en especial cuando no hay una diferencia salarial significativa.
Cada día más y más ingenieros están cambiando sus trabajos de 9–5 (8 a 6 en Colombia) y sus trajes por empleos en startups y compañías modernas de tecnología. Las compañías de software empresarial, la industria financiera y otras que dependen de sus equipos de ingeniería han tenido que seguir incrementando los salarios y bonos para retener el talento. Yo no creo necesariamente que todos los empleos en startups sean mucho mejores que en la industria, pero son definitivamente mejores al venderse a sí mismas y atraer talento, incluso cuando hay recortes en la compensación, riesgos más altos y poca seguridad laboral. Esto está lejos de suceder en nuestro país.

No lo creo, puede que la industria colombiana de software empresarial tenga un problema con la escasez de trabajadores, y uno que seguirá empeorando si se empeñan en sacar listas como esta en su búsqueda de talento. Están buscando “mano de obra barata” como ellos la llaman, y este no es el mismo tipo de talento que se busca en tecnología, más bien todo lo contrario. Entonces, si ellos son los del problema entonces ¿dónde quedamos nosotros, el naciente ecosistema tecnológico innovador colombiano?
No voy a negar que las startups y las nuevas empresas de tecnología en Colombia se les dificulta encontrar ingenieros calificados que contratar, pero el hecho de que no los pueden contratar no significa que no existan. Su desafío puede ser separado en dos partes, la disponibilidad de ingenieros calificados y la habilidad de la empresa para reclutar a dichos ingenieros, examinemos la primera parte de este problema.

La cantidad de empresas trabajando en la innovación de productos de software y plataformas tecnológicas en Colombia es muy limitada. Incluso si incluimos a las empresas de near-shoring que trabajan para clientes de los EEUU, la cantidad de Ingenieros de Sistemas que han podido experimentar con nuevas tecnologías y herramientas, resolver problemas complejos y fallar lo suficiente como para adquirir una experiencia significativa es bastante pequeña. Y, a pesar de que no puedo estimar la cantidad de ingenieros de software calificados, puedo darles algunos números para entrar en contexto.
Desde 2011, Colombia ha logrado construir la comunidad JavaScript más grande de Latinoamérica. BogotaJS y MedellinJS, con 1.193 y 1.190 miembros son por lejos los Meet-up (encuentros) más grandes en toda la región latinoamericana, incluyendo a Ciudad de MéxicoSantiagoBuenos Aires,Sao PauloRío de Janeiro, y Lima. Actualmente existen 8 meet-ups pertenecientes a la familia ColJS: BogotaJSMedellinJSCaliJS,VillavicencioJSQuibdóJSPereiraJSMonteriaJS, PopayánJS (en progreso) yManizalesJS (en progreso). En total, estamos cerca de alcanzar los 3.000 miembros.
Puede que no tenga cifras exactas sobre el tamaño de la cantera de talento en programadores calificados, pero el hecho de que lográramos agotar entradas a una conferencia de 2 días dedicada solamente a JavaScript para 310 asistentes (y 40 becas de diversidad), con un 98% de asistentes colombianos me dice que la cantidad potencial de individuos calificados es mucho, mucho más grande de lo que creemos.
Si asumiéramos que no se graduaron más Ingenieros de Sistemas a partir de 2010 y extrapolamos algunos de los resultados de la encuesta salarial de 2012 hecha por el MinTic (una muestra muy baja de 646 encuestados en todos los 246 miembros afiliados a Fedesoft), y hacemos otras asunciones bastante exageradas como decir que ̴ 10% de las personas en roles técnicos se hayan ido a otras industrias, aún nos quedarían el 33,5% o más o menos 36.000 personas en roles técnicos. ¿Qué haría usted si le dijera que ̴ 10% de ellos ya poseen cuentas Github? Creo que incluso en el peor escenario posible, y asumiendo que solo el ̴ 10% de este ̴ 10% (el ̴ 1%) están calificados para trabajar en su empresa, usted aún tendría ̴ 360 personas. Se podrían construir bastantes startups con esa cantidad de gente, con un promedio de 7 ingenieros por startup podríamos construir ̴ 50. Lograr que uno de ellos trabaje para usted, ese es el verdadero reto.

El mayor problema que me causa el argumento de que “no hay ingenieros en Colombia” es que básicamente niega todo el trabajo que un pequeño grupo de individuos apasionados de diferentes ciudades y comunidades han hecho para crear una cultura de programación substancial y una cantera de talento de alta calidad en el país. Todo esto durante su tiempo libre, sin compensación, muchas veces usando su propio dinero y por amor al oficio. Si su empresa no puede atraer y contratar a los mejores ingenieros, no necesariamente significa que no existan. Creo que es más factible que sea usted quien necesite evaluar si realmente está ofreciendo las mejores oportunidades a aquellos con los que quiere trabajar. Probablemente también esté desperdiciando su valioso tiempo echándole la culpa a nuestro sistema educativo, dejémosle eso a otros sectores y a la clase dirigente.
El equipo en el que estoy trabajando actualmente es la cuarta organización de ingeniería para la cual he contratado gente, y aunque he tenido bastante suerte en el pasado encontrando gente grandiosa con quien trabajar en el feroz mundo de los startups, esta es la primera vez que siento que entiendo 5% de cómo se supone que debo hacerlo. Lo que puedo observar del obviamente reducido contexto que tengo, es que en Colombia hay un gran número de ofertas laborales, una buena cantidad de relaciones públicas y rumores de como la industria va a cambiar al mundo, bastantes conversaciones sobre inversión, lean startups y startup weekends, un pobre entendimiento de las entrevistas técnicas, una terrible perspectiva de la compensación y los beneficios y cero comprensión de lo que los ingenieros talentosos o calificados pueden hacer y de qué los motiva.
Todos las startups de tecnología colombianas que conozco están fuertemente influenciadas por la cultura del Silicon Valley (sucede en todo el mundo, no somos únicos), y es natural ya que el SV es la cuna de esta revolución tecnológica la cual va a llevar en algún punto a 15 personas a Marte en cohetes auto-dirigidos. El problema con esta mentalidad de culto es que las empresas asumen que opinar, escribir un blog y publicar el banner de “estamos contratando” por toda su página web automáticamente les da el derecho a múltiples programadores sabelotodo, quienes tienen más de 5 años de experiencia en tecnologías vanguardistas, que trabajan 10 horas al día, contribuyen al Open Source los fines de semana, organizan meet-ups mientras duermen y hablan en conferencias durante sus vacaciones. Este es su problema mis amigas y amigos fundadores, y no estoy aquí para debatir si estos maravillosos ingenieros existen o no, pero asumiendo que si, ¿por qué deberían estar trabajando con ustedes? La palabra clave acá es con y no para ustedes.
Las startups de tecnología no se convirtieron en estos grandiosos y geniales lugares para trabajar solo porque podían hacerlo, genial = gastar dinero. Ofrecer mejores ambientes de trabajo (los espacios abiertos ya no son tan divertidos), más libertad (sin trajes, sin horario, sin jefes) y la promesa de una gran recompensa (opciones de participación accionaria) probaron ser una manera extremadamente efectiva de robarles individuos talentosos a las grandes empresas cuando los fondos son limitados y apenas se está comenzando (¿le suena familiar?). Cuando la diferencia salarial no era tan grande entre grandes empresas y startups jóvenes, estos eran los factores decisivos.
Atraer y retener talento se ha vuelto mucho, mucho más difícil. Los salarios han incrementado un montón en las compañías de tecnología establecidas incluso con esfuerzos para fijar los salarios, haciendo de ellas la nueva empresa. Mientras que los beneficios adicionales y las altas compensaciones son el estándar en el “Valley”, el prospecto de trabajar bajo desafiantes problemas técnicos al lado de las mejores mentes en el campo desde un ambiente de trabajo saludable no lo es. Hoy en día la manera más efectiva en que una empresa de tecnología se puede diferenciar de las demás, incluso si su producto parece ser menos complejo técnicamente (aplicaciones de fotografía vs química computacional), es teniendo un interés genuino por la ingeniería.


Al ser parte de un ecosistema de tecnología que tardó en florecer importado en su mayoría por fundadores influenciados por el SV, los ingenieros colombianos pueden disfrutar en un 100% de las porquerías de perks (beneficios) estupidos como escritorios de pie (todavía no hay dinero envuelto en tocino), de 0 a 0,3% de participación accionaria incluso si están entre los primeros 10–20 empleados contratados, un salario al nivel del mercado colombiano (incluso si son parte de una compañía con mercado global) y lo más importante, con 0% de cultura ingenieril.
Basado en la experiencia personal, he encontrado que muy poca gente preferiría trabajar para una firma de consultoría de software que para una compañía orientada al producto y bien manejada, asumiendo que están bien compensados. Existe una oportunidad increíble para construir compañías de tecnología en Colombia en este preciso momento. Muy pronto, actores internacionales comenzaran a subir los niveles de la compensación debido a la gran diferencia de salarios y si usted no tiene nada significativo que ofrecer, su equipo entero se irá. Se de unas pocas compañías a las que ya les está ocurriendo esto, y Amazon apenas está comenzando a intentar llevarse a los mejores de Colombia hacia Columbia Británica. Es triste ver que no están estableciendo una oficina en nuestro país, lo cual prefería verlos hacer y estaría más que dispuesto a ayudarles a entender a nuestras comunidades locales; ellos pueden traer montones de increíble experiencia técnica que, en el futuro, puede llevar a una generación completamente nueva de compañías fundadas en Colombia.
De la misma forma que compañías crean cultura empresarial, algunas de ellas pueden establecer una cultura de ingeniería. En algunos casos estas dos tienden a mezclarse más que en otras, y esto depende en su mayoría de fundadores técnicos o liderazgo técnico, incluso cuando el problema que estén resolviendo no es inherentemente técnico. Piensen en Etsy, ellos respiran cultura de la ingeniería aunque su actividad principal sea la venta de artesanías y manualidades.
En todo caso, no existe tal cosa como la cultura correcta, cada compañía decide su identidad. Stack Overflow, Etsy, Stripe, Netflix, Mozilla, Google, Amazon y Twitter son algunos ejemplos de compañías de las cuales uno puede darse cuenta inmediatamente que tienen una buena idea de cómo ser una compañía enfocada hacia la ingeniería. ¿Qué compañías cree usted que tienen las mayores tasas de recién egresados aplicando para pasantías?

Si fuera una pregunta sencilla no estaríamos teniendo esta discusión, pero puedo decirles que hay tres factores principales los cuales he logrado identificar en todas estas compañías:
Si usted quiere contratar ingenieros para su startup mientras que crea una cultura enfocada hacia la ingeniería (para competir con las grandes empresas por el talento), asegúrese de no destruir los factores 1 y 2 mencionados anteriormente al pretender entender el desarrollo de software como un fundador no técnico.
La simplicidad percibida del desarrollo de software causada por la explosión de la revolución de los startups hace que los fundadores y otros executivos/tomadores de decisiones que no son programadores se sientan lo suficientemente capaces para asumir que pueden seleccionar talento técnico y establecer directrices de proyectos y desarrollo de software.
¿Alguna vez ha creído tener el conocimiento necesario para reclutar y decirles a profesionales de la salud, pilotos, contadores o abogados como hacer su trabajo? ¿Que lo hace pensar que puede hacerlo en temas de desarrollo de software y producto? Curiosamente, esto también sucede en el mundo de los restaurantes, pero la realidad es que las personas que no están creando software de manera rutinaria carecen de contexto en cuanto a los esfuerzos que se requieren para producirlo. Esta también es una de las razones principales de por qué los restaurantes fracasan tan seguido, hay más paralelos entre estos dos mundos de los que uno imagina.
Cada vez que me he visto envuelto en esfuerzo donde gente descontextualizada ha intentado estar a cargo de procesos de desarrollo técnico ha habido resultados desastrosos. Me horrorizan las asunciones sin fundamento que tengo que oír durante sesiones de asesoramiento o de producto acerca de la simplicidad de construir aplicaciones de software, incluyendo a ex-programadores convertidos en gerentes mediocres. Sea cauteloso al oír “es tan solo un(a) ________ (botón, formulario, web-scraper, banner publicitario, plugin, módulo)”. Aún tengo pesadillas de vez en cuando. ¿Será que tenemos Startup Weekends™ y hackatones que culpar?
Los proyectos de software fracasan cuando las personas con falta de contexto intentan tomar decisiones sin reconocer que no saben lo que no conocen. Cuando las fechas límite son establecidas por otros aún más descontextualizados, lo que termina pasando es que los estándares de calidad, no la complejidad en funcionalidad, bajan a medida que se llega a la temida fecha (yo he hecho que esto ocurra en el pasado y aprendí de ello). Las pruebas y la documentación son las primeras en sufrir con la excusa de “somos una empresa lean, enfoquémonos solo en los PMVs” y una vez se halla zarpado no hay vuelta atrás.
Tarde o temprano tendrá que sentarse a diseñar y reestructurar sus sistemas mientras se engaña a si mismo con ponerse al día en los 2/3 del software que dejó por fuera. También tendrá que hacerlo mientras tiene que apoyar software no probado, usuarios reales, una compañía en crecimiento y todas las nuevas funcionalidades que su equipo de ventas ya prometió. He estado en esa situación 3 veces. La disponibilidad de su equipo para desarrollar nueva funcionalidad puede pasar de un 100% a un 10% en un abrir y cerrar de ojos gracias a la cantidad de soporte necesario, muy pocas compañías pueden solucionar las cosas antes de quedarse sin dinero y los perdedores no escriben la historia.

Querido fundador colombiano, ¿le pide usted a los candidatos que le muestren su perfil GitHub como parte de sus entrevistas? ¿Son las contribuciones Open Source algo que usted realmente valora al evaluar las calificaciones de un ingeniero? Detengámonos un minuto, ¿puede mostrarnos el suyo primero? El hecho de pedir el perfil de un individuo no está mal en sí, lo que está mal es esperar que la gente tenga un registro completo de sus contribuciones cuando estas compañías no tienen sus propias contribuciones substanciales.
Citando a Alex:
Lo siento, pero tengo que cuestionarte aquí Alex. No porque estés equivocado, sino porque estás cuestionando a los desarrolladores mientras tu compañía no tiene nada que mostrar. Soy muy consciente y estoy muy agradecido por tus contribuciones a la comunidad de emprendedores y por tu rol en la fundación de BogoDev (el primer meetup sobre desarrollo en Colombia). Desafortunadamente, Bunny Inc. no ha tenido el mismo impacto en Open Source.
Pedir el perfil de Github se ha vuelto una práctica más común, la opinión de que ahora Github es tu hoja de vida se ha vuelto cada vez más popular, especialmente entre los startups influenciados por el SV. A simple vista, pedir o requerir el perfil de Github puede ser inofensivo, pero tras haber hecho parte de las comunidades OSS ahora entiendo lo privilegiado que se necesita ser para contribuir a cualquiera de estos proyectos. No creo que este sea el lugar para entrar en detalle, pero pueden leer algunas piezas excelentes sobre esto como The Ethics of Unpaid Labor and the OSS Community Why Github is not your CV.





En pocas palabras, sea consistente. Si les está pidiendo a sus candidatos sus contribuciones OSS e involucramiento en comunidades de desarrollo, su compañía debería demostrar que está dispuesta a ir más lejos para apoyar y contribuir de todas las maneras posibles, y de manera desinteresada. Dar u organizar una charla sobre su propia implementación interna, con el único propósito de reclutar no cuenta.

Colombia tiene bastante talento técnico, desde mi perspectiva, el déficit real está en las compañías con altos estándares de ingeniería y mentalidades de clase mundial. Las compañías fundadas por aquellos que tienen la visión de capacitar, construir programas de reclutamiento, entender la motivación técnica y la dinámica del Open Source, evangelizar y gastar dinero real en ponerle el “tech” a tech hub.

Acompáñenme a evangelizar esta hermosa disciplina de la Ingeniería de software. Ya me he puesto en contacto con algunas instituciones educativas y tengo planes para este año, pero si ustedes logran ponerme en frente de un público superior a 100 estudiantes aspirantes, yo mismo pagaré los tiquetes aéreos. Durante los próximos 5 años quisiera ver al menos 5 compañías enfocadas en la ingeniería salir de Colombia, y en 10 años espero que el 100% de los ingenieros fundadores de Ride hayan construido muchas más
No soy fanático de hablar de problemas sin proponer soluciones. Lo que sí creo es que esta publicación es lo suficientemente larga y ya he comenzado a redactar una continuación que en su mayor parte repasa mis aprendizajes y como se puede mejorar el reclutamiento, la retención, la moral y la motivación en su equipo de ingeniería que a la final tiene un gran impacto en su negocio y crecimiento. También tendrá un enorme impacto en nuestra economía latinoamericana.
Por ahora, les puedo contar muy brevemente lo que ya estamos haciendo en Ride, incluso sin haber lanzado nuestro producto. Muy probablemente entrare en detalles sobre cada uno de estos en mi próxima publicación.
Tenemos menos de 4 meses siendo una organización de ingeniería y apenas estamos comenzando.
Si usted se encuentra en una situación en la que tiene preguntas urgentes o concretas y específicas sobre la cultura de ingeniería de su equipo, la estrategia de reclutamiento, prácticas de desarrollo, etc. Le tengo una propuesta:
Le daré 30 minutos de mi tiempo a cambio de una donación de $100 aColombia.dev. Esta es una nueva comunidad de desarrollo de software que estoy intentando construir en Colombia, con la intención de balancear las conversaciones sobre inversión y financiación que se están tomando nuestro ecosistema tecnológico. Si usted está interesado, llene este formulario con sus datos y me pondré en contacto. Las donaciones serán manejadas por mí personalmente, y serán utilizadas para apoyar a los grupos regionales de usuarios, el sueño de un espacio hacker, un laboratorio de dispositivos, hardware para robótica y pruebas en dispositivos móviles.
Agradecimiento especial a Camilo Aguilar por gastar un montón de su tiempo editando esta pieza. Adicionalmente, me gustaría agradecer aElizabeth RamirezGuillermo IguaranCamila GaitánAdrián Estrada,Carlos Velásquez y Juan Camilo Pryor por leer versiones tempranas de este trabajo y darme su opinión.
Finalmente, quisiera agradecer a Alex Torrenegra por su publicación inicial que me llevó a hacer un análisis serio de los últimos 6 años de mi carrera. Espero con ansia todas las cosas positivas que saldrán de estos esfuerzos por explorar la ingeniería de software colombiana.
Traducción del original por Daniel Bernal
Bibliografía
(1), (2) — Campo Saavedra, Maria F. “Seguimiento a Los Graduados De La Educación Superior En Los últimos 10 Años.” Ministerio De Educación Nacional, Bogota, Colombia. Aug. 2011
(3), (4) — Colombia. Ministerio De Educación Nacional. Observatorio Laboral Para La Educación. PERFIL ACADÉMICO Y CONDICIONES DE EMPLEABILIDAD DE LOS GRADUADOS DE EDUCACIÓN SUPERIOR — 2001–2010. N.p., Dec. 2011. Web. Jan. 2015.
Unknown Web Developer