El origen de Bootstrap, el framework CSS líder

Hace unos días me daba vueltas en la cabeza quiénes eran las personas que desarrollaron Bootstrap, este framework tan amigable (que a muchos nos ha aliviado en más de un par de ocasiones), me hacía preguntas como ¿son personas normales? ¿dónde viven? y ¿qué otras cosas hacen? por este y otros cuestionamientos más, hoy me dí a la tarea de investigar y este fue el resultado de mi investigación.

Bootstrap fue desarrollado por Mark Otto (@mdo) y Jacob Thornton (@fat) desarrolladores del famosísimo Twitter, proveedor de servicios de microblogueo.

¿Pero quiénes son Mark Otto y Jacob Thornton?

Mark Otto es un diseñador viviendo y trabajando en San Francisco, trabajó como freelance durante la secundaria y la universidad, antes de mudarse a California para trabajar en la empresa de diseño ZURB, en 2007.

Durante su estancia en ZURB diseñó y desarrolló docenas de proyectos con grandes y pequeños clientes, incluido un sitio web para Britney Spears -¡Cool! – .

Después de un periodo de dos años y medio en ZURB, renunció para comenzar a trabajar en Twitter como diseñador de productos.

En Twitter trabajó en numerosos proyectos y varias herramientas internas, ahí fue donde creó el popular kit de herramientas para front-end de código abierto Bootstrap con ayuda del buen Jacob Thornton.

Bootstrap nació en Twitter como un medio para crear mejores herramientas internas, comenzó como algo simple de HTML/CSS, luego Jacob construyó complementos encima y así es como comenzó “Bootstrap de Twitter” llamado así originalmente.

Bootstrap es un framework de código abierto para diseño de sitios y aplicaciones web. Entre sus herramientas contiene una gran variedad de plantillas de diseño con tipografía, botones, menús de navegación, tarjetas y otros elementos de diseño basado en HTML y CSS, así como también extensiones de JavaScript.

Hasta la fecha Otto y Jacob han puesto más de 1000 horas en Bootstrap, sino es que más. Semanalmente trabajan de tiempo completo en sus respectivos empleos, pero suelen realizar esfuerzos durante algunas horas por la noche y más los fines de semana, esto quiere decir que ellos no trabajan de tiempo completo en Bootstrap.

Actualmente Otto se desempeña como Director Principal de Diseño en GitHub, administra un equipo de aproximadamente 25 diseñadores web, ingenieros y artistas.

Por su parte Jacob Thornton es cofundador de Bumpers (aplicación de podcasting). Trabajó en Medium y Twitter, dondé junto a Otto creó Bootstrap.

Jacob hace un tiempo solía mantener un blog, donde escribía una serie de artículos de filosofía, sociología, teoría crítica y tecnología, donde abordó diferentes temas “con los que estaba luchando en ese momento”.

Jacob en particular tiene ideas que dan vueltas en su cabeza como ¿los robots o la inteligencia artificial se volverán demasiado inteligentes y tomarán el control? ¿ya vivimos en una realidad virtual? y cuestiones como “necesitamos colonizar Marte, o de lo contrario nos vamos a extinguir” y temas por las que la gente como él está obsesionada.

Jacob dice que no se deprime demasiado por este tipo de aspectos humanistas, pero sí es juicioso al respecto y tiene la tendencia a enloquecer al respecto.

Él es una persona muy filosófica y de ideas futuristas, sufre de alergias y le encantaría tener un ‘gato robótico’, y que no estaría nada preocupado si su gato intentara atacarlo.

Soy alguien que realmente quiere que haya destinos y experiencias radicales, únicas y diferentes, especialmente en Internet.

Bootstrap 4

Finalmente, Bootstrap es un proyecto que recientemente se ha actualizado a su versión 4, añadiendo diversas funcionalidades y mejoras, las cuales les invito a conocer en un muy entretenido y amigable curso impartido por nuestro amigo Alex Arriaga donde serás testigo de la genialidad de estos dos personajes.

https://webtraining.zone/cursos/curso-profesional-de-bootstrap-4

Conclusión general

Creo que Otto y Jacob son personas como tu y como yo, que con el esfuerzo y dedicación de su día a día han logrado proyectos muy interesantes e innovadores.

Así que sigamos trabajando todos los días “pasito a pasito” y así poco a poquito alcanzaremos y construiremos cosas más grandes y mejores para bien de todos.

Corre tras tus sueños…

Los 10 mandamientos de un buen Ingeniero de Software

Disclaimer: Este post no tiene nada que ver con religión. Respetamos todas las creencias y la fé que tienen nuestros amables lectores.

Leerás los requerimientos antes de empezar a codificar

Sabemos que nos encanta el código pero… trata de resistir la tentación de iniciar a codificar si antes haber leído tu lista de requerimientos, que esperemos que tu compañero Business Analyst haya preparado para ti. Si no hay una lista de requerimientos, créala, te aseguro que tu alter ego frustrado del futuro te lo agradecerá.

Diseñarás la arquitectura de tu aplicación antes de iniciar con el código

El mes pasado estuve leyendo el libro más reciente del Uncle Bob (a. k. a. Robert C. Martin): Clean Architecture: A Craftsman’s Guide to Software Structure and Design y en particular encontré muy buenas opiniones acerca de qué tan importante es sentarnos y pensar cómo vamos a construir nuestro sistema, no sólo se trata de la cuestión técnica de cuál framework usar, o si usaremos REST o GraphQL sino ir más allá, diseñar interacciones (inputs/outputs), prever casos dónde nuestro sistema pueda fallar, etc.

Una de las cosas que normalmente no hacemos es priorizar nuestras tareas. Y me gustó mucho esta frase:

I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent.

– Dwight D. Eisenhower

Imagen de SafariBooksOnline.

Those things that are urgent are rarely of great importance, and those things that are important are seldom of great urgency.

Es decir, si algo es urgente casi nunca es importante y viceversa las cosas importantes rara vez son urgentes. La arquitectura de un sistema es algo IMPORTANTE.

No desearás el framework de tu prójimo

A todos nos encanta probar nuevos frameworks, la más reciente biblioteca para hacer tal cosa, lo más moderno, sin embargo, otra vez, trata de no desear lo que otros están usando y en su lugar pregúntate ¿realmente necesito migrar esta funcionalidad? ¿qué beneficios le traerá a mi cliente este cambio? ¿cuánto va a costar implementar tal o cual cosa? ¿qué tan importante es probar la nueva tecnología? ¿puedo re-usar partes de lo que tengo? ¿qué valor agregado me dará cambiarme ahora mismo? ¿estoy listo para dar el salto?

Te aseguro que después de responder las preguntas anteriores estarás más en paz con tu implementación y sabrás qué camino tomar.

Usarás un controlador de versiones

¿Verdad que no hay nada más triste que llegar a un proyecto y darte cuenta que nunca se guardó en un Version Control System (VCS)? Si puedes usar Git mejor; si no puedes por políticas internas no importa, pero por favor usa un controlador de versiones, te quitará muchos dolores de cabeza y reducirá drásticamente los errores en tu ciclo de desarrollo de software.

Crearás un conjunto de pruebas (si son automatizadas mejor)

Sí, estoy de acuerdo; crear pruebas para un sistema es una de las tareas más cansadas, largas y hasta tediosas, sin embargo son un excelente punto para asegurar la calidad de tu software y más aún, estarás creando un mecanismo para ayudarte a reducir la cantidad de errores cuando se agreguen nuevas características o se cambien las ya existentes.

Escucharás atentamente a tu equipo, ellos tienen mucho que aportar

Que no te gane el ego, todos tienen una opinión y una forma de ver las cosas. Nadie tiene la verdad absoluta; recuerda existen tres verdades:

  • Tu verdad: lo que tu crees que es lo mejor y lo más correcto
  • La verdad de tu prójimo: lo qué él cree que debería hacerse
  • Y la verdad: lo que realmente es correcto (ésta suele ser una combinación de las dos anteriores).

Pensarás antes de criticar el código de tu prójimo

Antes de decir ¡que $#$%@ es esto! Investiga, lee, documéntate, quizá quien creó el sistema o aplicación, lo tuvo que hacer en un tiempo muy corto y por ello no tuvo los recursos para crear algo mejor.

Quizá el ingeniero anterior tenía muchas dudas pero no fueron resueltas en el tiempo apropiado y tuvo que salir a producción con lo que tenía.

Quizá el cliente cambió los requerimientos a última hora. Esto casi no pasa ¿verdad?

Estarás en comunicación con tu Project Manager

Los Project Managers no son dioses, no son intocables, diles cuando no te sientas cómodo con los tiempos que te dieron para hacer tus tareas, que sepan que te están causando conflicto en tu vida porque ahora tendrás que desvelarte durante 4 meses para poder salir en el tiempo previsto.

Ellos son tus compañeros, son tus aliados y colegas, hazlos partícipes de tus preocupaciones. Qué sepan que vas a tener que hacer mucho más de lo que en su sistema de tracking de tareas dice.

Pedirás ayuda cuando lo necesites

Aceptémoslo, siempre hay alguien mejor que nosotros, y tu siempre sabrás algo más que otra persona. No cierres tus pensamientos a sólo lo que tu crees que es mejor, pregunta, lee y busca la opinión de quienes ya han recorrido por más tiempo este apasionante pero complicado mundo de la creación de software.

Encuentra a quien admirar, síguelo, busca su código, lee sus ideas, escríbele. Te aseguro que hay mucha sabiduría en esas personas que llevan muchos más años en estos caminos.

Buscarás en Google o Stack Overflow antes de preguntar

Tu tiempo es valioso, así como el de tu prójimo también lo es. Busca por tu cuenta primero, lee, estudia y analiza; tenemos mucha información en internet y claro en nuestro amado Stack Overflow, trata de solucionar tus tareas, primero por ti mismo.

Sin embargo, tampoco dejes que pase mucho tiempo, si ya pasaste más de tres horas con un problema y no encuentras la solución, entonces pregunta a tu prójimo, tal vez pueda ayudarte.

Tu servidor,

Alex Arriaga