Fueron Rechazados y Se Hicieron Millonarios | La Historia de Google

La Historia de Google 

Tomado del canal Negocios y emprendimiento

¡El programa que TODO DESARROLLADOR debería tener INSTALADO! 🔨 La documentación de 99 lenguajes en 1

¡El programa que TODO DESARROLLADOR debería tener INSTALADO! 🔨 La documentación de 99 lenguajes en 1

Tomado del canal de Victor Robles
 

La ruta para ser desarrollador web profesional en 2022

 

La ruta para ser desarrollador web profesional en 2022

Tomado del canal Victor Robles Web.

¿Sabes quien es el Chema Alonso? ¿Sabes que es un Hacker? aclaralo e inspirante

2020] Conferencia y coloquio de Chema Alonso: Ciberpeligros en 2020 en la Fundación MGS

Historia de los Hackers Informáticos [ Los inicios ] Documental - Discovery Chanel

DOCUMENTAL QUE TODO INFORMÁTICO DEBE DE CONOCER

Revisando Clean code, vale la pena leerlo? | review clean code

 

 

Leyendas de la programación y el desarrollo de software

Lenguajes de programación de Software mejor pagados en México 2019

Estos son los lenguajes de programación de software mejor pagados en México

Una de las preguntas más frecuentes que suelen tener los estudiantes universitarios de carreras a fines en programación, es el lenguaje de software que deben elegir para especializarse.

Si bien, las tecnologías han demostrado ser un sector de constante cambio, el desarrollo de software que lo respalda también lo es, y es por esta razón que resulta interesante continuar el aprendizaje de nuevos lenguajes y mantenerse al día de las tendencias en la industria.

El estudio

Según el estudio realizado por Software Guru a finales de 2018, con una muestra poblacional de 2,075 profesionistas en el país con actividad en el sector, el promedio mensual en el area es de $33,000 moneda nacional, 52% son titulados de universidad. Sin embargo esto no quiere decir que todas los lenguajes reciban la misma percepción económica, cabe mencionar que el nivel de ingles que se tenga también afecta abruptamente el sueldo, así como los años de experiencia y otros dominios que se tengan.

Lenguajes mejor pagados

Los lenguajes de programación arrojados de este proyecto reflejan que Elixir tiene de momento una implementación baja en esta muestra con 32 personas, sin embargo resulta ser la mejor pagada con sueldo promedio de $54,000 pesos al mes. El segundo lugar lo lleva Go con 34 personas y un sueldo promedio de $46,800 y en tercer lugar se encuentra Ruby con más implementación (112 personas) con sueldo promedio de $42,000.

Otros lenguajes como Python, Java y PHP son de los más populares y con mayor cantidad poblacional lo que repercute en que los sueldos bajen a $35,000, $32,000 y $20,000 respectivamente.

Vale la pena observar que los primeros tres se debe a que hay poca oferta y más demanda, eso no significa que sean las más buscadas.

Experiencia

En esta investigación también se logró apreciar que el salario medio de los primeros 7 años se mantiene lineal con un incremento de 5 mil pesos anual por año de experiencia, a partir del octavo año el salario se estabiliza al rededor de los 40 mil pesos mensuales.

Si bien el titulo universitario continúa siendo un requisito en muchas empresas, resulta importante agregar certificaciones y proyectos en linea que puedan consultar los reclutadores. Una buena practica es tener un portafolio en plataformas como Git Hub.

Tomado de Digital El Heraldo de México

Angular vs React vs Vue

Por Fernando Herrera, Analista programador e instructor en línea(UDEMY)

Hice este artículo porque es una pregunta que me hacen a diario, ¿Cuál es mejor?, ¿Cuál debería de aprender?, etc…estas son ideas que yo tengo al respecto.

Tengan presente que mi opinión es que no hay ninguno mejor que otro, simplemente tienen diferentes características y si hoy, siguen vivos, en un mundo donde todos los días aparecen nuevos frameworks de JavaScript y estos 3 siguen sobresaliendo, quiere decir que sea como sean, son muy buenos.

Angular (Angular la última versión), en lo particular no me gusta la curva de aprendizaje, es bastante alta y si no se tiene la introducción ideal puede asustar mucho especialmente con los decoradores y TypeScript…

Pero me gusta mucho lo veloz que es para hacer una aplicación cuando ya lo conoces, los componentes, la reutilización de los mismos, los servicios, la inyección de dependencias, los pipes, la personalización y la integración con RXJS. También las rutas, las validaciones, formularios y muchas otras cosas.

Ahora mucho del éxito de Angular 2+, es porque su predecesor AngularJS fue muy popular, hoy en día se siguen haciendo aplicaciones en esa versión de Angular.. muchas empresas se quedaron con AngularJS porque tienen muchas aplicaciones desarrolladas en ese Framework. La controversia que sucedido cuando salió Angular 2+ contra AngularJS hizo que muchos otros Frameworks como Backbone, React y Vue tomaran más fuerza porque a la gente no le gusto la idea de tener que aprender un nuevo Framework ya que Angular 2 había cambiado tanto, y se tenía mucho miedo que Angular 3 (que nunca salió), fuera a pasar lo mismo. (que no fue así)

Ahora, Angular 2+ efectivamente es mejor que AngularJS, es más rápido y eficiente, aunque a veces el peso de las aplicaciones en producción es superior al de Angular, mucha gente se le olvida que en el bundle generado por Angular va todo el código de las librerías usadas, lo que lo hace muy útil para no preocuparse por el cache del navegador web cuando hacíamos cambios pequeños (entre otras cosas)

Ahora con las actualizaciones de Angular, también muchas personas se asustan porque tienen presente ese salto que fue de pasar de AngularJS a Angular 2+, normalmente es bueno tener actualizaciones periódicas, ningún framework es perfecto y necesita ser mejorado constantemente, lo que hace que todos nos beneficiemos de eso porque las aplicaciones serán más seguras, rápidas y eventualmente nos obligan a tener mejores prácticas de desarrollo… nadie te obliga tampoco a actualizarte, mira el caso de aplicaciones de AngularJS, se quedo en la versión 1.6 y conozco lugares donde esas aplicaciones ya llevan años corriendo sin problemas.

Ahora, TypeScript?, muchas personas cuando comienzan en el framework también se asustan por esto, especialmente aquellos que están acostumbrados a trabajar con Vanilla JavaScript (JavaScript puro), como se programo mucho AngularJS… porque ahora hay cosas un poco diferentes como interfaces, importación de módulos, tipado de datos y mucho más… realmente no hay que tener miedo a eso… de hecho en mi opinión, creo que la web se ira enfocando en usar más y más TypeScript sobre JavaScript plano con los años, ya que los beneficios de TypeScript y su desarrollo nos ayudan a reducir la cantidad de errores que cometemos al escribir código y utilizar paquetes y librerías de terceros. ( si deseas saber más sobre TypeScript puedes ver este artículo)

Recuerden que estos son mis puntos de vista, muchos podrán tener otras cosas a favor, más puntos en contra, pero esta bien, no es una discusión.

Ahora REACT, en lo personal, y como muchos me conocerán, yo no soy un gran fan de React, tengo varios amigos que están metidos en esta librería y les encanta, en lo particular cada día lo estudio más y ellos me enseñan cosas con las cuales quiero trabajar en unos cursos después… y en mi experiencia puedo decir que es una librería grandiosa y que si tu ya lo conoces sigue especializándote porque hay mucho que aprender ahí como en Angular.

¿No se si notaron que use la palabra librería?, esto es porque React al menos en este momento no es un framework completo para crear aplicaciones como Angular, es solo la capa visual, pero puede hacer todo lo que hace Angular con el apoyo de la comunidad y otros paquetes.

Ahora es usado por muchas grandes compañías como Facebook (quien fue quien creo React), aunque en lo particular no me gusta mucho tener que mezclar mucho JavaScript con el HTML, en lo personal pienso que siempre deben de estar separados y como React tiene esta relación muy fuerte con este patrón, realmente tienes que aprender una sintaxis especial de JavaScript (nada que no sea imposible o nada complicado como fue aprender TypeScript)

Por ejemplo en lugar de usar la palabra class, para definir una clase de CSS, debes de usar className, se por qué lo hace pero no me gusta… aprender un framework o librería no es fácil, pero hay cosas que ya están dadas como el CSS o JavaScript, y cuando lo automatizaron apareció el SASS y el TypeScript, pero se sabe de entrada que hay que aprender algo nuevo, pero si me incomoda un poco aprender atributos HTML nuevos especiales para React, ademas recordemos que también el HTML y CSS van mejorando día con día y las nuevas características puede ser que tengan que ser adaptadas para poderlas usar en aplicaciones de React.

Claro esta es mi opinion y se que muchas personas aman React y los entiendo, es una excelente librería con una excelente historia.

Ahora como comparamos React contra Angular, bueno para la gente que no le gusta TypeScript, ya con eso deberían de estar convencidos de usar React, aunque a mi parecer usar TypeScript es algo que me hace amar programar en Angular… ahora pero muchas personas que empiezan en React sabiendo JavaScript básico, siempre tienen que aprender ECMAScript 6 porque usa mucho de los nuevos estándares de JavaScript, y por supuesto nuevas características del ES7 o JavaScript 2017 ya están en camino, así que es mentira que no deben de aprender algo si se van a React.

Otra diferencia es que no hay un proceso de conversión real en React, prácticamente todo lo que haces y como funciona tu aplicación es el resultado que tendrás cuando lo despliegues en producción, y esto es algo que a muchas personas les gusta sobre Angular… las personas que han creado aplicaciones en Angular, sabrán que cuando se hace el build de producción, a veces falla, puede fallar alguna optimización, se puede un paquete y hay que realizar algo adicional para que funcione en producción, cosa que en React es raro que suceda (pero puede suceder) pero no es tan frecuente como en Angular…

Ahora React no es tan completo como Angular en algunas áreas, como por ejemplo el Router, tienes que importarlo de un paquete comunitario, también validaciones de formularios no viene en React propio, pero en Angular si los tienes y como es parte del mismo equipo de desarrollo del framework, tendrás actualizaciones periódicas sobre esos elementos… Ahora unos amigos míos que trabajan con React, dicen que siempre tener la comunidad de desarrolladores es mejor porque no es un monopolio y hay mucha gente muy hábil que comparte sus ideas y aporta mucho a esos paquetes…

Ahora hablando de otros temas que interesan en el ambiente laboral y real, es que muchas empresas en su momento buscaban personal que supiera AngularJS, pero como paso lo que paso con la versión 2+, React tomo mucha fuerza y en estas alturas, creo que hay 50% que te digan “¿Sabe React?” o “¿Sabe Angular?”, entonces definitivamente vale la pena pensar en estudiar y conocer ambas y cuando ya seas contratado en ese trabajo, especializarte en el framework que usarás.

Ahora Angular esta pensado en crear aplicaciones de una sola página, que usualmente eso es lo que queremos, pero tener que hacer una pequeña página web para anexarla a un sitio web… pues… ahí si se complica un poco la cosa porque aunque es posible hacer una pequeña app para una pequeña sección de mi página web, sería algo pesada y esto React lo hace mucho mejor o mejor dicho, si es posible hacerlo sin tener que arrugar la cara cuando alguien te pida eso siendo alguien que domina Angular.

Ahora hablemos un poco de Vue.js, en lo particular me gusta mucho más que React y siento que es como AngularJS (el cual también me gusto mucho), de hecho siento que es el hijo de React y Angular, es como que tomaron las mejores ideas de ambos para crear Vue.

Ahora Vue no es perfecto tampoco, hay muchas cosas que no me gustan tampoco, puedes programar en ES5, o bien en ES6 si prefieres, inclusive puedes usar TypeScript (aunque es un poco más difícil, pero puedes). Ahora me gusta la separación que tienes entre JavaScript y el código HTML, es un código entendible casi sin mucho conocimiento del framework (a diferencia de Angular y React), también para realizar aplicaciones de una sola página, tienes el equipo de desarrollo del framework que hizo el router, así recibes actualizaciones periódicas, aunque el problema es que de igual forma debes de importar muchas cosas de la comunidad, como validaciones de formularios y otras cosas…

En donde vivo, pocas empresas usan Vue.js, de hecho pocos lo conocen y esto es un factor que debes de considerar antes de aprender este framework, ¿Encontraré trabajo si lo aprendo? En mi caso también estoy estudiando Vue, porque de los 3 frameworks es el que menos conozco pero el que más familiar siento al buen amigo que fue AngularJS… por eso no me siento tan perdido que cuando comencé a estudiar React, que me enojaba con los atributos html nuevos que son similares a los existentes…

Algo que puede no gustarte, puede ser muchísimo código en los componentes cuando son aplicaciones grandes, no hay inyección de dependencias, aunque siempre puedes hacer módulos y muchas otras cosas, pero a veces siento que Angular hace mucho mejor estas cosas… como les dije, puedo estar equivocado no soy un experto en Vue, aunque si me estoy preparando para serlo…

Ahora si me tocara elegir entre Vue y React, yo seleccionaría Vue, porque de verdad me molesta mucho mezclar JavaScript con HTML, porque para mi es un problema no poder trabajar con archivos HTML independientes y usar CSS y HTML regular, o bien muchas librerías que uso en mi día a día me dan problemas y tengo que buscar adaptaciones para React, pero bueno, puede ser por mi falta de experiencia en React…  y también me gusta que los desarrolladores de Vue dan más paquetes que los que incluye React por defecto (como el Router)

Ahora la documentación de Vue es EXCELENTE, definitivamente es muy buena, es para mi la mejor de todas, es fácil de empezar con eso y tiene una gran comunidad amigable, muchas de las preguntas que he hecho, he sentido calidez en las respuestas y a veces me pasa que cuando he posteado preguntas sobre React y Vue, me tratan como si fuera un estúpido que no tiene idea lo mal que esta ese código que quiero implementar…

Ahora Angular es potenciado por Google y React con Facebook, Vue no tiene un gigante atrás que lo respalde, tiene un grupo de personas que yo considero genios que viven por mejorar su framework, es algo como los origines de Angular, pero ellos siguen en la face de equipo… claro es posible que si su framework sigue creciendo, terminen siendo adquiridos por una gran compañía… puedes ver el equipo de Vue.js aquí

Ahora, recuerden que Vue es un framework más nuevo que Angular o React, por lo que conseguir trabajos donde uses Vue.js es mucho menor a React y Angular, pero definitivamente hay compañías que le interesa seguir mejorando constantemente su área de desarrollo, (bueno no muchas en Latinoamérica honestamente), la mayoría solo se preocupa por su infraestructura y hacer mejor software con lo que ya tienen… pero pocas invierten en estudios de nuevos frameworks… pero como digo, puedo estar equivocado, es mi opinion persona y no estoy haciendo saliendo a las calles a realizar encuestas tampoco, es mi percepción de como se encuentra todo esto en la realidad donde vivo…

Si hablamos de las curvas de aprendizaje y no de la parte laboral que queda claro que Vue es el último, Vue es el más fácil de aprender, React el segundo y el último sería Angular con su curva tan complicada al inicio.

Hay muchas personas que hablan maravillas de React y el uso de su JSX, como hay personas que hablan maravillas del poder de Angular lo robusto que, es como hay gente que defiende a capa y espada lo simple, poderoso y fácil de aprender de Vue… la verdad que a mi parecer, debes de estudiar o enfocarte en lo que demande el trabajo… todos son excelentes, todos merecen ser estudiados y aprendidos.

Pros y contras de cada uno

Pros de Angular: Puede ser escalado a grandes equipos de trabajo, tener una persona nueva que casi no sepa Angular en el equipo no es caótico y su trabajo puede ser aislado, templates y código separado y como la mayor parte del código es proporcionado por el equipo de Angular, hay mucho menor riesgo de que al importar un Router nuevo, la aplicación explote y el uso de TypeScript para mi es un pro también.

Cons de Angular: TypeScript puede ser a veces demasiado quisquilloso a comparación de JS o JSX usado en React, el paso de AngularJS a Angular 2 asusto a mucha gente, como depende de varios paquetes como RXJS a veces surgen cambios que es necesario corregir manualmente especialmente cuando hay cambios de versiones mayores.

Pros de React: Se basa en componentes, y el hecho que AngularJS pasara a esto con su Angular 2+, dice que están en lo correcto, facebook realmente usa su librería, React es mucho más fácil de usar en varios dispositivos, aunque Angular esa Cordova, no es tan versátil como React.

Cons de React: La licencia de React es de Facebook, y últimamente Facebook no es el genio que era antes con las demandas y los riesgos de fugas de información, JSX aunque muchos lo consideran grandioso, hace un poco difícil la separación de las responsabilidades entre desarrollador y diseñador gráfico, y una queja que me han dicho mucho es que el npm en React es una pesadilla.

Pros de Vue: Template y código separado, tiene componentes como React y Angular, lo que sigue afirmando que React lo pensó muy bien, no tiene el problema de las restricciones de TypeScript, no hay problemas con licencias ya que es un grupo de personas y una gran comunidad de ayudantes, muy fácil de aprender y poderoso.

Cons de Vue: Es muy joven todavía, no hay mucha oferta laboral para él, como no tiene una gran compañía que lo respalde, se basa en la buena voluntad de las personas para seguir expandiéndolo, aunque en el peor de los casos, parece que el proyecto va por muy buen camino.

Recuerden que esto es mi simple opinion para contestar la miles de preguntas que tengo sobre este tema, no pretendo tirarle flores a ninguno y no soy experto en los 3, por lo que me es imposible hacer algo 100% apegado a la realidad, es lo que he podido apreciar en mi trabajo con estos 3 increíbles y poderoso frameworks y librerías para poder crear aplicaciones.

Mi objetivo real es darles a ustedes una opinion desde mi perspectiva que espero que los motive a ustedes a seguir aprendiendo más al respecto.

¿Sabes cuál es la diferencia entre habilidades duras y blandas?

Al inicio de tu carrera es muy probable que seas contratado principalmente para tus habilidades duras. Pero, para ascender, necesitarás habilidades blandas.

Si un candidato desea tener mejores oportunidades de conseguir un empleo debe saber diferenciar las habilidades blandas de las duras. Esto le permitirá, durante el proceso de selección, determinar cuál de todas se adapta mejor a las necesidades de la empresa a la que postula.

Durante los procesos de selección, los reclutadores buscan candidatos que cuenten con dos tipos de habilidades: las técnicas o duras y las sociales o blandas.

Las habilidades blandas son aquellas asociadas con la personalidad y la naturaleza de la persona, por ejemplo: relaciones interpersonales; capacidad de liderazgo; actitud positiva, entre otras.

En ese sentido, estudios aseguran que los empleadores están considerando estos factores en su proceso de selección.

No obstante, es importante señalar que al inicio de la carrera del profesional, este será contratado por sus habilidades duras, es decir, conocimientos que son relevantes para la posición que ocupa.

Cuando los jóvenes están recién egresados de la universidad, o incluso tienen pocos años de experiencia, factores como el dominio del sector y el conocimiento que se ha adquirido durante las prácticas son realmente importantes.

Diferencia entre ellas

Para poder entender la diferencia entre ambos tipos de competencias es necesario tener en cuenta la siguiente comparación.

¿Cuáles son las habilidades duras o técnicas?

• El dominio de una lengua extranjera que ayuda a mejorar las oportunidades de ser contratado. La persona que domina el inglés tendrá más oportunidades de viajar para cerrar negocios.
• Un título que le permita al profesional demostrar sus habilidades para una tarea específica. Esto se ve con frecuencia en empresas que brindan servicios de Outsourcing.
• El certificado que indica el manejo de cierto tipo de maquinaria de operaciones. Los casos más comunes serían en empresas dedicadas al sector minero, petrolero, pesquero, entre otros.
• Uso de programas de computadoras que le permitan un mejor desempeño en el trabajo. Es indispensable que, en estos tiempos, todo profesional domine herramientas Office y de diseño.

¿Cuáles son las habilidades blandas?

• Trabajo en equipo, es necesario que los colaboradores entiendan que sus aportes deberán sumar para conseguir un objetivo.
• Liderazgo, todo grupo requiere contar con una persona que los sepa guiar, pero el líder no impone ideas, sino que las propone y las debate en beneficio de los resultados.
• Comunicación, las personas que trabajan en una empresa deben saber explicar sus ideas a cualquier nivel.
• Persuasión, esta es una habilidad muy útil al momento de hacer negociaciones.
• Motivación, los colaboradores deben entender que las cosas no siempre saldrán bien, pero es importante saber levantarse y levantar a los compañeros de las adversidades.

Al momento de postular

Mientras que ciertas habilidades duras son necesarias para cualquier posición, los empleadores están buscando cada vez más -entre los solicitantes de trabajo- habilidades blandas.

Esto se debe a que es más sencillo entrenar a un nuevo empleado en una destreza en particular(utilizar un determinado programa de ordenador) y más difícil prepararlos para competencias transversales (como la paciencia).

Durante la entrevista de trabajo el candidato debe estar seguro de destacar tanto sus habilidades duras y como blandas.

De esta manera, incluso, si no tienes una habilidad dura requerida por la empresa, podrás aportar con una habilidad blanda en particular que sabes, sería valiosa en la posición.

Si el empleo implica trabajar en una serie de proyectos grupales, es importante que el candidato se asegure en hacer hincapié en la experiencia como jugador de equipo y la capacidad para comunicarse con todos los miembros del grupo de trabajo.

Tomado de APTITUS.COM

Code Clean (Código Limpio)

Code Clean (Código Limpio)

Alguna vez te ha tocado entender el código de otra persona para usar y modificar, y te has decepcionado porque pierdes demasiado tiempo en identificar las razones por las que pusieron como nombre de variables A, PanTFc, o cualquier otro nemotécnico que no tiene sentido. Esta es la razón por la que actualmente se promueve el Code Clean (Código Limpio), que consiste en crear un código fácil de leer y entender, sii y aunque vaya en contra de lo que hemos aprendido hasta ahora sobre desarrollo, uno de los tips de código limpio es no tener ningún comentario(La famosa autodocumentación). Aquí te dejo un video donde se comenta el fomento a Code Clean.




Espero lo consideres en tus proyectos de desarrollo...

Tomado del canal de
Diego Castaño · Desarrollo Web Creativo

10 Tips para Programar Mejor

10 Tips para Programar Mejor

Navegando por allí me encontré un video donde se plasma la mayoría de las sugerencias que cada vez que tengo oportunidad le comento a mis alumnos, en verdad estoy completamente de acuerdo con todos.

Espero coincidas conmigo.

Le agregaría Enseña lo que sabes, por que al enseñarlo lo refinas y dominas más...
Tomado del canal ADD Costa Tropical

QDOS, el “padre” del DOS (1979)

Un poco de gran Historia para los informáticos...

Tim Paterson y Bill  Gates

QDOS, el “padre” del DOS (1979)

Escrito por Tim Paterson en 1979

El QDOS, un Sistema Operativo (SO) escrito por Tim Paterson en 1979, fue adquirido por Bill Gates y “convertido” en el MS-DOS, el producto que sería clave para el posterior éxito del imperio Microsoft. QDOS era un SO de 16 bits diseñado para correr en el microprocesador Intel 8086, inspirado fuertemente en el CP/M escrito previamente por Gary Kildall. Paterson, a los 22 años, escribió QDOS en solo un mes y medio, dotándolo de la misma interfaz y la mayor parte de los comandos disponibles en CP/M. Te contamos los secretos de los orígenes del MS-DOS, uno de los sistemas operativos más populares de la historia.

Gary Kildall

Circulan muchas historias sobre Bill Gates y su empresa Microsoft. Una de las más interesantes es el origen de lo que sería uno de los sistemas operativos (SO) más utilizados en el mundo, cuyo éxito impulsó financieramente a la empresa de Gates y la convirtió en el gigante que es hoy día. La leyenda -no todos los pasajes de este entretenido culebrón han sido ratificados o desmentidos por los personajes implicados, y posiblemente no lo serán nunca- cuenta que Microsoft compró por un puñado de dólares un SO existente, le hizo algunas modificaciones, y lo licenció a IBM ganando en el proceso cientos de millones de dólares. El SO en cuestión era el QDOS (por “Quick and Dirty Operating System“, o “Sistema Operativo Rápido y Sucio“) escrito por Tim Paterson.

QDOS, el “padre” del DOS

El QDOS era un SO destinado a los sistemas de 16 bits que utilizaban el microprocesador Intel 8086, que Paterson había escrito inspirándose a su vez en la interfaz y los comandos que utilizaba el más popular SO de la época: el Control Program/Monitor (CP/M). El CP/Mhabía sido programado por Gary Kildall entre 1973 y 1974, quien en 1976 fundó la compañíaDigital Research Inc (DRI). Si tienes más de 35 años, quizás recuerdes un SO alternativo al MS-DOS llamado DR-DOS, que no era otra cosa que la versión de Digital Research del sistema más utilizado por las primeras PC.

Tarjeta de visita del dueño de Seattle Computer Products

Pero volvamos a los orígenes del QDOS. A fines de la década de 1970 era posible encontrar en el mercado varios ordenadores -algunos bastante potentes- que se comercializaban en forma de kit. Esto bajaba sensiblemente los precios, y una gran cantidad de usuarios “construyeron” sus propios ordenadores. Pero para que estas máquinas sirviesen de algo se necesitaba un sistema operativo capaz de manejar ficheros y los recursos del sistema. Una de las empresas especializadas en el desarrollo de kits de ordenadores era Seattle Computer Products (SCP), cuyas ventas no terminaban de despegar por falta de software capaz de correr en su sistema. SCP únicamente podía vender con sus placas el Microsoft BASIC-86, un lenguaje de programación que Microsoft había desarrollado especialmente para la plataforma. SCP soñaba con incluir en su catálogo la versión del CP/M que Digital Research había anunciado para el microprocesador Intel 8086, pero los meses pasaban y el lanzamiento del CP/M se posponía una y otra vez.

DRI cargaba sobre sus espaldas con una verdadera “tradición” en cuanto a las demoras: dos años antes se había retrasado en migrar CP/M a los nuevos formatos de diskettes y discos duros. Cansados de esperar, en abril de 1980 SCP tomó el toro por las astas y asignó a uno de sus empleados la programación de un sistema operativo propio. El empleado era, como habrás adivinado, Tim Paterson, y el SO que escribió fue el QDOS. El nuevo sistema operativo, cuyo nombre hacia referencia a lo rápido que había sido escrito por Paterson (demoró solo un mes y medio) y a las “concesiones” que habia hecho en cuanto a sus características para poder terminarlo a tiempo.

Asi se veia el 86-DOS

Paterson, que sólo tenía 22 años, diseñó el QDOS para que fuese lo más parecido posible al CP/M, ya que este era un SO aceptado por el público y muy popular. Intentando que QDOS no fuese simplemente una copia descarada -y tener que enfrentarse a una dura demanda legal- Paterson programó la mayoría de los comandos disponibles en el CP/M, pero no utilizó el mismo sistema de archivos. En su lugar utilizó el sistema de archivos FAT (File Allocation Table, o Tabla de Asignación de Archivos) que utilizaba Microsoft en algunas de sus versiones de BASIC.

Para evitar forzar la actualización del contenido de los discos antes de quitarlos, Paterson evitó el uso de una copia del sistema de archivos en memoria RAM. Esto, si bien hacia al sistema de discos un poco más lento, dejaba más memoria libre para el usuario. No era un detalle menor, ya que por aquellos años la memoria era extremadamente cara y escasa. También reemplazó algunos comandos CP/M por otros menos potentes pero más intuitivos. Así fue como el poderoso y versátil comando de copia “PIP” del CP/M fue reemplazado por “COPY”. Se dice que para realizar su trabajo, Paterson compró un manual de CP/M y lo utilizó como base para programar QDOS. Es posible que haya utilizado bastante más que eso, ya que resulta bastante difícil escribir un “clon” de -por ejemplo- Windows XP viendo solo su manual del usuario. Como sea, lo cierto es que el joven programador proporcionó a Seattle Computer Products el SO que necesitaban, y esta empezó a comercializarlo bajo el nombre 86-DOS.

IBM PC

Mientras tanto, IBM tenia un grupo de ingenieros encerrados en Boca Ratón diseñando lo que sería el bombazo más espectacular en la historia de la informática: el IBM PC. A finales de 1980 CP/M era sin discusión el SO más popular, e IBM lo quería para su nuevo ordenador. Pero cuando los representantes de la Big Blue se entrevistaron con los directores de Digital Research, descubrieron que tal cosa no sería sencilla. Durante la discusión sobre los términos y alcances de la licencia, Dorothy McEwen Kildall -la  representante de licencias de DRI- se negó a firmar el contrato alegando la existencia de una cláusula de no divulgación. IBM, decidida a utilizar CP/M, eliminó este escollo del contrato, pero Digital volvió a negarse a firmar por que no estaba de acuerdo con los 250 mil dólares (más un importe en concepto de regalías por cada venta) que IBM ofrecía a cambio de la autorización para vender todas las copias del SO que estimasen necesarias.

La negociación estaba estancada, y finalmente la gente de IBM se reunió con Bill Gates para ver si Microsoft disponía de un sistema operativo que les permitiese introducir la máquina -que ya estaba casi lista- en el mercado. Bill negoció duramente con IBM y consiguió mas o menos el mismo trato que la Big Blue le habia ofrecido a DRI, pero conservando los derechos para vender el SO con su propia marca. Esta resultó ser una genial jugada para Microsoft: el IBM PC y sus clones dominaron el mundo, y por cada uno que se vendía Gates y sus amigos embolsaban un puñado de dólares. Pero lo mejor de todo es que, al momento de comprometerse con IBM, Microsoft no tenia nada para vender.

Portada del Manual del Usuario del 86-DOS v0.3

Efectivamente, Microsoft no poseía un sistema operativo para entregar a IBM, ni el tiempo necesario para programarlo. Lejos de desanimarse, Gates compró -en Diciembre de 1980- una licencia no exclusiva del 86-DOS a Seattle Computer Products por solo 25 mil dólares. Obviamente, no podía entregar ese producto tal cual estaba a IBM, por lo que en Mayo de 1981 Microsoft contrató a Tim Paterson para que modificase su ex QDOS de forma que corriese en el nuevo IBM-PC. Las modificaciones eran necesarias por que IBM había basado su diseño en el más barato y lento microprocesador Intel 8088, que a pesar de ser muy similar al 8086 no era 100% compatible. Fueron necesarios más de 300 cambios, todos ellos supervisados bien de cerca por los representantes de IBM, quienes tenían muy claro que el buen funcionamiento de su ordenador dependía en buena medida de la calidad de este software.

Finalmente, en Julio de 1981, solo un mes antes de que lanzaran el IBM PC a las tiendas, Microsoft compró todos los derechos sobre el 86-DOS a cambio de 50 mil dolares adicionales. Esta operación completaba la jugada de Bill Gates: IBM obtenía un SO muy parecido a CP/M, los programas escritos para ese SO podían ser portados fácilmente al nuevo DOS, se aseguraba de obtener beneficios económicos con la venta de cada PC, y eliminaba cualquier intento de juicio por plagio por parte de SCP al haberle comprado todos los derechos de su 86-DOS. Lo que se dice, un negocio redondo.

IBM OS/2, el sucesor de IBM-DOS,

Microsoft convirtió el QDOS en el PC-DOS 1.0 -“DOS” significa “Disk Operating System”, o “Sistema Operativo de Disco”- y se lo entregó a IBM. Además, empezo a vender su propia versión bajo el nombre de MS-DOS (MicroSoft Disk Operating System) y rápidamente cosecharon una fortuna. Lógicamente, los abogados de Seattle Computer Products alegaron que Gates había encubierto su relación con IBM a la hora de comprarles la licencia del 86-DOS, pero solo consiguieron un pago extra de un millón de dólares por parte de Microsoft.Se dice que Gary Kildall examinó cuidadosamente los ejecutables del PC-DOS y encontró -según declaraciones del periodista y escritor Jerry Pournelle– que contenía partes del código original de su CP/M.

Pournelle asegura que Kildall le mostró personalmente como, introduciendo un comando en el PC-DOS, éste mostraba su nombre en la pantalla. Sin embargo, dicho comando jamás fue revelado y la historia no ha sido corroborada. A manera de descargo, Paterson siempre ha sostenido que QDOS fue escrito desde cero por él mismo, y que solo imitó su interfaz y comandos, sin ver jamás su código fuente. Y la gran mayoría de los historiadores creen en esta versión. En esa época, un SO era lo suficientemente pequeño como para poder ser escrito por una sola persona, y Paterson era lo suficientemente inteligente como para hacerlo.

QDOS se convirtió en el SO de la IBM PC

Evidentemente, en la historia del QDOS el personaje más inteligente de todos ha demostrado ser Bill Gates. Sin infringir la ley, moviéndose siempre al borde de la frontera de lo que separa lo ético de la trampa, logró que Microsoft ganase miles de millones de dólares a partir de una inversión de poco más de un millón. Tuvo el coraje de sentarse frente a los directivos de IBM y asegurarles que tendrían el SO que necesitaban, aún cuando Microsoft no tenia nada tangible para ofrecer. Como sea, QDOS -el producto de la mente de un programador de solo 22 años- se convirtió en el PC-DOS / MS-DOS que millones de personas compraron durante más de una década. ¿Que te parece?

Tim Paterson, enWikipedia