Ultimo post del año (2017)

Según google analytics este año han entrado 102,943 visitas únicas, un número no tan enorme, pero para mí significa mucho, ya que todos los post que escribo es para compartir información que en alguno momento a mi como desarrollador de software me arranco algunos cabellos, información que no muchas veces esta en foros de programación, y espero que por lo menos de esos 102,943 personas que ingresaron este año, por lo menos el 10% le haya servido alguno de mis post, mi software gratuito o todas esas cosas que plasmo en este blog.

No soy mucho de festejar el cambio de año, ni de festejar estas épocas, pero me pareció interesante sacar el total de visitas y darme una idea de cuantas personas son las que ingresan.

Continuare escribiendo post el siguiente año, e igual publicare la versión tan esperada del sistema de gimnasio 2.0.
Y lo único que les deseo es que si sus combobox que han puesto en sus sistemas de manera directa sin utilizar un DateTime.Now, pues es momento que vayan cambiándolos ya que el lunes les va a tronar su sistema.
Nos vemos en el 2018, el año del .Net Core.

8 curiosidades sobre las neuronas

Las neuronas son la base del procesamiento del cerebro, y forman una red en la cual se desarrolla la funcionalidad motora y comportamiento de los seres vivos.

En las ciencias computacionales forman parte como la base de lo que conocemos como redes neuronales, las cuales funcionan simulando el comportamiento de las neuronas, las células de la mente.
En este artículo veremos 8 hechos sobre las neuronas.

1. Son células

Son un tipo de célula, las cuales forman una red de comunicación en el cerebro del reino animal. Su número es variable, se puede encontrar en gusanos cantidades de 300 neuronas hasta cien mil millones en el ser humano.

2.- Su descubrimiento

Las neuronas fueron descubiertas a finales del siglo XIX por Santiago Ramón y Cajal, un español que más tarde gano el premio nobel por este descubrimiento. Dentro de su descubrimientos, por medio del microscopio, observo que entre cada neurona rara vez se tocan directamente, mas tarde esto tomaría gran relevancia en el manejo de los mensajes comunicados neurona a neurona.

3.- La conexión

La conexión de las neuronas se realiza por medio del axón y las dendritas, dos ramificaciones que realizan el papel de emisor (axón) y receptor (dendrita). La zona de interacción de las neuronas se llama sinapsis, y lo que pasa en esta sección sirve para explicar las acciones del cerebro, tanto motoras como de comportamiento.
Existen a su vez dos tipos de sinapsis, una es eléctrica y otra química, siendo la segunda más compleja, y es donde se han encontrado relaciones de los procesos realizados con las emociones.

4.- La química de las neuronas.

La sinapsis eléctrica de las neuronas es una conexión directa, la cual ocurre instantáneamente, pero la sinapsis química, tiene más complejidad y es donde hay más material de estudio para comprender como funciona el cerebro.


Como mención anteriormente, las neuronas se conectan por medio de una ramificación llamada axón la cual lleva el mensaje, y las dendritas las cuales reciben el dato. La parte final del axón contiene varias estructuras sinápticas de nombre vesículas, estas son unas bolsistas que guardan los neurotransmisores, por su parte las dendritas tienen una proteína que actúa como receptor, al momento de la sinapsis, las vesículas reciben el mensaje que conlleva el axón y dependiendo el tipo de llamada, arrojan el neurotransmisor adecuado, el cual es recibido por la proteína en la dendrita. Continuando el ciclo hasta llegar al fin de la red, ya sea un musculo o una parte del cerebro.

5.- Los Neurotransmisores

Los neurotransmisores son moléculas químicas, existen tres tipos de estos: aminoácidos, aminas y péptidos.
Dependiendo el neurotransmisor enviado de la neurona mensajera, existe un receptor adecuado para recibirla. Antes se pensaba que solo existía un tipo de receptor para cada tipo de neurotransmisor, pero estudios recientes han demostrado que existen distintos tipos de proteínas receptoras, por lo cual el número de combinaciones de funcionalidad crece.

6.- Efectos de los venenos

Las neuronas controlan el sistema motor, entre ellos el sistema respiratorio. Algunos venenos (El de la cobra por ejemplo) han evolucionado a tal grado de imitar a un neurotransmisor, pero con la diferencia de no eliminarse, si no queda pegado en la proteína receptora de las dendritas. Imagina que una llave queda atascada en la puerta, la puerta ya no puede recibir una nueva llave para abrirse. De esta manera el veneno bloquea la sinapsis, es por ello que si no se atiende a tiempo, el veneno se expande por la red neuronal, taponeando los receptores, y a su vez impidiendo las instrucciones como respirar, es por ello que las personas con mordedura de cobra, mueren por paro respiratorio.

7.- Efectos de las drogas

Al igual que los venenos, las drogas actúan como neurotransmisores, elevando placer o adrenalina, gracias a que pueden aumentar el envió de neurotransmisores que producen placer.
El problema de las drogas es que conocemos poco aun de cómo actúan los neurotransmisores, por ello ocasionan efectos secundarios. Esto es, por que un neurotransmisor que sirve para una cosa, puede servir para otra, todo depende la proteína receptora que lo reciba. Así que si la droga no induce un incremento de dopamina (neurotransmisor para el control de estados depresivos), la misma dopamina es empleada por las neuronas para el control motor, por lo cual pueden producir taquicardias, o vómitos.

8.- Muerte de las neuronas

Cada día mueren más de 10 mil neuronas, es un pequeño número para la cantidad que tenemos. Estas comienzan a morir en el caso de los humanos, cuando se cumplen los 20 años. Hay un grupo pequeño de neuronas que tienen la función de dividirse y crear nuevas, pero el grupo es muy pequeño, las demás mueren debido a un proceso natural. Existen casos en los cuales se acelera el asesinato de las neuronas como enfermedades que aceleran su destrucción, como el Parkinson o Alzheimer, o ingerir drogas.

Estos son 8 hechos sobre las neuronas, la unidad del cerebro, que conforme pasa el tiempo más sabemos de ellas, pero aun estamos en la etapa larval en descifrar el órgano más complicado, el cerebro.

Un poco de canvas en este 2018

A lo largo de mi vida profesional he conocido pocos programadores que se involucran realmente en el desarrollo de videojuegos, con la llegada de HTML5 se nos facilitó el desarrollo de juegos gracias a canvas (algo inventado por Apple en el 2004), pero hoy ya más de 10 años después pocos lo conocen realmente, un propósito que tengo el siguiente año es dominarlo a la perfección, no tanto por aspectos laborales sino por un hobby que viene desde mi niñez, crear videojuegos.

Ya he realizado algunas cosas con canvas, pero como todo no por hacer unos cuantos gráficos o animaciones quiere decir que sea un experto (muchos por hacer algo ya ponen en su CV que son expertos), y no es para que todos los desarrolladores se involucren en esta tecnología ni hacer una revolución de ella la cual ya lo fue hace algunos años, sino simplemente dejar este escrito aquí para ser leído por mí un año después.

Por lo pronto abajo dejo un código que hice ahorita en 10 min para que los acompañe cuando tomen hongos o alguna otra droga psicodélica.

Código HTML

 <canvas width="500" height="500" id="myCanvas" > </canvas>

Código JAVASCRIPT


var context = document.querySelector("#myCanvas").getContext('2d');
context.beginPath();
context.arc(250,250,200,0,2*Math.PI,false)
context.fill();
context.stroke();
context.closePath();


    var i=0;
    setInterval(function(){

        DibujaPoligono("#myCanvas",3,i);
       
        if(i==360)
            i=0;  
        i++;

   },10);
    

    function DibujaPoligono(canvas,sides,iTurn){

        var context = document.querySelector(canvas).getContext('2d');
       
        context.beginPath();
        context.fillStyle = "white";
        context.strokeStyle="black";
        
        //pentagono
        var numberOfSides = sides,
            size = 200,
            Xcenter = 250,
            Ycenter = 250,
            step  = 2 * Math.PI / numberOfSides,//para pintar la figura calculamos la posicion
            shift = (Math.PI / 180.0) + iTurn; //giro


        for (var i = 0; i <= numberOfSides;i++) {
            var curStep = i * step + shift;
            
            context.lineTo (Xcenter + size * Math.cos(curStep), Ycenter + size * Math.sin(curStep));
        }


      
        context.fill();
        context.stroke();
        context.closePath();

}

SAT, cfdi 3.3, facturación electrónica, la opinión de un desarrollador de software PARTE I – Adaptación

Esta entrada fue impresa en el número publicado en Marzo 2018 de la revista Talento Empresarial.

Mi experiencia con facturación electrónica viene desde el desarrollo de la plataforma www.facturacenter.com.mx, posterior a ese desarrollo he hecho miles más que van desde servicios web, consultoría a empresas y algunos municipios del país, y lo último la migración de cfdi 3.2 a 3.3 de algunos sistemas.
Tratare de dar mi punto de vista como desarrollador de software, no soy experto en contabilidad ni temas fiscales, yo solo soy un desarrollador de software por lo cual puedo desconocer algunos temas a la perfección. En esta entrada me enfocare en la adaptación de los usuarios a este mecanismo.

¿Por qué facturación electrónica?

Entiendo las ventajas que significan para SAT que los contribuyentes emitan facturas electrónicas, ya que esto da mayor control a todo movimiento que hacen las pequeñas y grandes empresas, y poco a poco quitando el trabajo de los contadores de calculadora, y todo electrónico sin gastar papel, ni renovar los folios y todo el engorro que se hacía hace años. Lo malo del asunto es haber optado por sacar una versión 3.2 con tanta deficiencia la cual quieren tapar con la nueva versión 3.3 (la cual creo que complica todo al contribuyente, ahorita vamos para allá). No sé a quién consulto SAT para realizar la facturación electrónica en cuanto a sus secciones y formatos, catálogos, atributos, complementos etc. Hay características buenas como todo, pero las deficiencias que tenía la versión 3.2 quisieron mejorarlas teniendo un mayor control en lo que captura el contribuyente, cambiándolo todo (o casi todo) a claves, esto asegurando que el emisor no captura discrepancias, todo suena perfecto y como programador lo aplaudo, pero esto debió ser parte de la versión 3.2 no de la 3.3. ¿Qué es lo que pasa ahora con todo el tema de la migración? Que todos los sistemas fueron hechos para la versión 3.2 una versión que fue perfeccionándose y si la comparamos con la versión 3.3 hace un caos en los sistemas y en los usuarios que utilizan dichos sistemas.

CFDI 3.2

Un usuario que estaba acostumbrado: 10,20 quizá 30 o más años a hacer sus facturas con papel se le obliga a realizar facturación electrónica, ya que no fue opcional sino obligatoria al final, esta persona nunca ha utilizado una computadora, meses después el usuario comienza a crear su factura, y de repente le toca un cliente al cual le obliga hacer una addenda, el usuario no tiene ni idea que es una addenda, lo peor aún, el sistema que utiliza el usuario no tiene dicha addenda(si porque cada receptor puede hacer su addenda), el usuario llama a su proveedor de software y le dicen que la addenda estará lista en unos días. Por fin llega el día y el usuario ve que para hacer una factura para ese cliente en particular (ya que si la factura está mal no recibe su pago) debe llenar más datos y cuando por fin logra hacer la factura, se encuentra con una nueva sorpresa, el cliente le dice que la factura debe subirse a una página web la cual validara la addenda, y al subirla el sitio del cliente le dice que su factura no es válida; la persona nuevamente llama a su proveedor de software y se vuelve un ciclo prueba y error hasta que resuelve una problemática que no tenía cuando solo utilizaba papel. Este es un pequeño ejemplo de la problemática que pasó un contribuyente al migrar de papel a facturación electrónica. ¿Sera verdad que con la facturación electrónica se beneficia el contribuyente? O ¿Quién se beneficia realmente? El contribuyente en lugar de beneficiarse ha gastado en un software caro y en más tiempo del que utilizaba para hacer algo que hacía en minutos.

CFDI 3.3

Después de 6 años cuando los contribuyentes por fin llevan una vida más o menos tranquila en cuestión de facturación (a veces falla el pac, se caducaron sus sellos), y sale la súper noticia de la migración a la nueva súper poderosa facturación electrónica 3.3 la cual contiene miles de mejoras, más organizada, lo mejor que le pudo pasar al contribuyente, y arrojan como 20 catálogos los cuales deben ser utilizados ahora en lugar de que el usuario capture lo que siempre capturaba. Ahora para capturar conceptos el SAT obliga a que capture el usuario el producto y una clave que proporciona el bondadoso SAT, y lo dicen como si el usuario solo buscara la clave entre más de 50 mil (un numero absurdo y más adelante veremos porque) y rápidamente le resolviera su vida pero aquí es por lo cual dije con anterioridad, estos catálogos debieron salir en la anterior versión, las personas ya utilizan sistemas donde tienen hasta miles de productos, los contribuyentes viven al día, y ahora para hacer una factura deben ir producto por producto buscando la clave más o menos adecuada (ya que hay ambigüedades) esto en el caso de los conceptos, ah pero si te equivocas el SAT te dará perdón unos meses porque los contribuyentes son unos pecadores por no saber cuál es la clave de sus conceptos. Ahora veamos lo absurdo de este famoso catalogo:

  • Clave 92111704 – Guerra de guerrillas
  • Clave 25151501 – Nave espacial tripulada
  • Clave 11131602 – Semen
  • Clave 92112100 – Guerra nuclear
  • Clave 92112207 – Guerra ambiental
  • Clave 92112403 – Guerra nuclear
  • Clave 92112404 – Guerra basada en el espacio
  • Clave 92111806 – Mercenarios

Estos son unos ejemplos, y es cuando me pregunto ¿En realidad eran necesarios más de 50 mil elementos? Además esto está lleno de huecos, hay bastantes ambigüedades, y otro problema es que ese catálogo debe seguir creciendo a la lógica del SAT, ya que habrá cada vez nuevos productos, creo que si querían absorber todo producto posible se metieron en un problema enorme. Se debió contemplar una categorización menor, no más de 1000 elementos, esto ayudaría bastante al usuario, pero yo casi estoy seguro que este catálogo tiende al fracaso. El simple hecho de evaluar si corresponde lo que capturo el cliente con la clave ya es algo engorroso, así que no dudo que el siguiente año se elimine o se reduzca este catálogo así como el de unidad que también es otra maravilla.

Hablar de facturación electrónica es un tema para más de una entrada, es por ello que me enfoque en la adaptación en estos años, en otras entradas hablare de los monopolios existentes, nomina electrónica, y también del famoso y paradójico complemento de pago.
La facturación electrónica también tiene sus puntos buenos y puede mejorar la forma en como está organizada, lástima que SAT teniendo recaudaciones enormes (2015: 300 mil millones de pesos) no invierta ni el 1% de eso para su departamento de sistemas (siguen utilizando applets, yo amo java, no las applets).
Nos vemos en siguientes entradas.

SAT, cfdi 3.3, facturación electrónica, la opinión de un desarrollador de software PARTE II – Beneficio.

Un poco de abstracción en la programación no hace daño

Este es un tema muy subjetivo pero el cual es tan importante como el conocer el lenguaje de programación y herramientas de terceros.
La abstracción es un concepto filosófico que comenzó por las reflexiones filosóficas de aquel pensador llamado Aristóteles (dudo que hubiera sido el primero), y se resume como las propiedades y funciones que hacen un objeto (esos griegos ya sabían POO). En palabras simples, la abstracción es aquello que hace que un triángulo no sea un cuadrado, y si un sujeto entiende un triángulo a la perfección y otro sujeto también lo entiende a la perfección deberían ver el concepto de triángulo de la misma forma. Claro esto es yéndonos al extremo de abstracción.
¿Entonces todas estas cosas marihuanas a que nos llevan o para que nos sirven en la programación? Pues sirve prácticamente para trabajar menos.
Los requerimientos son los que definen un problema y para resolver ese problema es para lo que nos pagan, cuando tenemos un par de años trabajando desarrollando software es más fácil identificar los requerimientos parecidos y por lo cual es más fácil aplicar funcionalidades compartidas, en sí, estamos aplicando abstracción funcional al desarrollo, por lo cual trabajaremos menos pero pensaremos más (cuando digo más no hablo de tiempo aplicado sino de complejidad).
Un poco de abstracción no hace daño, un poco de herencia, sobrecarga y rehusó de funcionalidad ayuda a crear más estética en nuestro código, pero como todo, el exceso es malo, el balance de cuanta abstracción utilizar es decisión de uno, y cuando hablo de saber cuánto rehusó de funcionalidad utilizar, hablo por los cambios de requerimientos que a veces van desde una funcionalidad única en solo un módulo la cual nos hace re-codificar mucho.
Como conclusión, la abstracción es algo que se aprende por uno mismo con la experiencia, ni un curso ayudara a tener mejor abstracción, ni gurus, ni evangelistas, lo único que nos hará mejorar el nivel son los distintos problemas nacidos de distintos requerimientos.

Ver – Abstracción en la programación 

¿Cuál es el mejor lenguaje de programación?

Este artículo lo hago para romper muchos dogmas que existen en el área de desarrollo de software. Primero hablare de conceptos básicos y al final daré la conclusión y mi punto de vista. También hablare de lenguaje de programación encasillando: lenguaje de programación, framework, librería, Software-Stack etc.
Siempre los desarrolladores de software creen que los lenguajes que utilizan son los mejores ya que son los que utilizan. También existe el dogma de creer que el lenguaje de programación de moda (véase Ruby en el 2012, véase Mean últimamente) es el lenguaje más potente de todos.
Siempre defenderemos el lenguaje que sabemos utilizar ya que es el que nos da de comer, pero no por ello quiere decir que es el mejor. Los lenguajes de programación son como los colores, un gusto por el verde no lo hace mejor que el azul. O algo más acercado es, los idiomas con los que nos comunicamos, no por estar escrito el Quijote en inglés es mejor que el japonés. Para entender un poco el fin de este artículo, centrémonos en esto último.
Un libro nos cuenta una historia la cual pasa de generación en generación. Esta historia puede ser traducida y no por eso pierde su simbolismo. En los lenguajes de programación se cuentan al igual historias las cuales pueden ser traducidas de un lenguaje a otro (de programación); algo hecho en java del lado del servidor puede ser traducido a node.js o a php, y el lector de la historia (front-end por ejemplo) recibirá el mismo resultado. Aquí vemos un punto clave: la solución del problema es lo que le importa al cliente. Pero también le importa el tiempo en que es escrita la historia.
El tiempo en que se escribe una historia (programa) es parte de por qué nuestra elección sobre un lenguaje de programación nos hace pensar que es el mejor, pues es el que conocemos. Obviamente lo defenderemos a capa y espada. Aquí ya tenemos dos puntos clave: la historia y el tiempo en que esta es escrita, o a su vez, la solución del problema (historia plasmada en libro) y el tiempo de desarrollo (escritura de la historia).
Ahora ya que hablamos de la similitud de libros y programas, hablemos de otros puntos clave. Existen libros que son malos pero cuentan una historia que es entretenida más o menos, y existen libros que son buenos y cuentan una historia que entretiene, divierte, motiva, bueno es una obra de arte. Esto relacionado a los lenguajes de programación es lo siguiente: existen programas que son lentos, mal hechos pero resuelven el problema más o menos, y existen programas que resuelven el problema pero a su vez hace verlo como una obra de arte por su rapidez, y sobre todo la manera que parece que hace magia con el modelo de negocio del cliente. Es aquí el punto más importante: no importa en qué lenguaje de programación hagas las cosas, lo que importa es que hagas bien las cosas.
Otro punto clave es la antigüedad, la mayoría de las veces un lenguaje viejo es un lenguaje obsoleto (yo no veo a nadie escribiendo libros en griego o en hebreo). Pero no siempre es el caso, es mejor decir que un lenguaje es obsoleto cuando no evoluciona (nunca se implementó lambda, no tiene orms, no tiene plugins que hacen el desarrollo más rápido, etc).

Para concluir yo aconsejo que se debe conocer un lenguaje de programación con el cual estés cómodo, y después te hagas experto, más tarde en 1 o 2 años, ve conociendo más lenguajes, esto te ayuda a comparar la forma en que otros lenguajes resuelven lo que tú ya has resuelto, esto lograra que tu abstracción crezca y te ayudara a pensar de manera más ágil. Lo que más importa no es el lenguaje de programación sino la abstracción y creatividad que tengas para resolver las cosas.

Ningún lenguaje de programación es el mejor, sino el cómo tú piensas y resuelves el problema, eso es lo que en realidad importa.

Como detectar un verdadero programador senior

Este tema es un poco rebuscado, ya que muchos de los que trabajan en el ambiente de contratar personal desconocen los aspectos técnicos y es por ello que se crea la problemática de no poder diferenciar un programador experto tan fácilmente.

guagua

Yo soy de los que tienen la idea que un currículum es una carta de mentiras donde uno puede ser un súper héroe pero existen puntos clave que te sugiero puedas tomar en cuenta para detectar si un programador es senior o no:

  1. El currículum: el currículum es un medio que presta a la persona a cometer mitomanía pero igual puede la persona misma ahorcarse sola por medio de este. Un currículum lleno de lenguajes de programación es la primera señal de que la persona no tiene nada de senior, así de simple.Es más factible un currículum lleno de herramientas, frameworks o librerías que se engloben a 2 o 3 lenguajes de programación, que todo un libro de colección de lenguajes de programación que no lo hace un experto solo un mentirosillo.
  2. El trabajar en equipo: es poco común que una persona indique en una entrevista de trabajo, cuanto y como ha trabajado en equipo. El trabajar en equipo es de las cosas primordiales, la mayoría de desarrollos son en equipo, y si la persona demuestra que ha trabajado con equipos en lugar de ser un programador solitario (esos programadores que se sienten estrellas) es otro punto extra para demostrar que es un programador senior, un programador senior no es un súper hombre es solo una persona que sabe hacer las cosas bien.
  3. Arquitectura de Software: el conocer conceptos fundamentales de la arquitectura de software, desde básicos como el UML, tipos de arquitecturas, patrones de diseño es tan importante como el saber programar, y a un nivel de senior es algo que debe conocerse por ley.
  4. Base de datos: un senior sabe diseñar una base de datos de cero, también sabe utilizar procedimientos, triggers y funciones en un lenguaje relacional, eso es básico, no digo que sea un DBA pero si tener el nivel de diseñar bien la estructura de la base de datos. Si no sabe hacer esto, esta lejísimos de ser un senior.
  5. Tipos de sistemas: las personas pueden ser senior cuando han resuelto distintos tipos de sistemas, si una persona se la ha pasado haciendo puntos de venta que siempre es lo mismo, el mismo tipo de problema, eso lo aleja demasiado a ser un senior. Un programador senior ha creado sistemas distintos, viéndose en la problemática de diferentes escenarios a los cuales pudo resolver.
  6. Modelo de procesos: si la persona no conoce un modelo de procesos ya sea CMMI, MoProSoft u otro, es probable que no realice software de calidad (es probable porque he conocido personas que no utilizan nada de esto pero crean su propio modelo de procesos sin saberlo y su software es bueno, no excelente pero si es bueno). El no separar el desarrollo del software en procesos indica un sinónimo de ser novato.
  7. Control de versiones: un senior sabe y conoce distintos programas o herramientas de control de versiones de código, si la persona en su vida ha utilizado esto, está lejos de ser un senior. También está lejos de ser un senior una persona que conoce programas de control de versiones pero no le sirve de mucho, nunca sube sus avances (he conocido muchos así y que han perdido hasta 3 semanas de trabajo porque se descompuso su computadora).
  8. Documentar: las personas que no documentan no respetan su trabajo, por lo tanto no son senior (abre un software creado por ti sin documentar hace 2 años, y veras a que me refiero). Documentar el software es tan importante como codificar (esto incluye los comentarios en el código), no documentar el software es crear algo que más tarde nadie sabrá cómo se realizó y se deberá invertir tiempo en ingeniería inversa (como los platillos de marcianos de Roswell).
  9. Honestidad: la honestidad de decir: “No, ese tiempo de entrega es imposible”, la honestidad de decirle al líder de proyecto o al cliente: “eso no está dentro del presupuesto”. La honestidad de saber las limitaciones personales representadas al tiempo del desarrollo son más benéficas que decir si a todo, se beneficia el cliente por no esperar algo que no se le dará, se beneficia el equipo de desarrollo por no involucrarse en tareas imposibles respecto al tiempo, y se beneficia la empresa ya que no quedara mal con nadie. Un senior es honesto en este aspecto.

Existen algunos otros puntos, pero estos para mi son lo primordial para identificar a un senior de un mentirosillo.

Los 8 personajes más importantes en la computación

Existen muchas personas que han aportado algo para conocer la ciencia de la computación como hoy en día la conocemos, pero hay quienes son pilares en el desarrollo de esta, veamos ocho de las personalidades que fueron pilares en el desarrollo de la computación.

Euclides (325-ca. 265 a. C.)

euclides

Euclides era un matemático griego, considerado el padre de la geometría, pero pocos saben que fue de los primeros en describir un algoritmo como tal (instrucciones o pasos a seguir para un fin, utilizados en computación). Su famoso algoritmo de Euclides descrito en su obra Elementos, sirve para encontrar el máximo común divisor de dos elementos (enlace para ver la descripción del algoritmo).

Abu Abdallah Muḥammad ibn Mūsā al-Jwārizmī (780 -850 ¿?)

Al_Khwarizmi

El dueño de este nombre (mejor conocido como al-Juarismi) tan emblemático lo tiene el matemático persa del siglo IX, este matemático creo la palabra algoritmo derivada de algebra, palabra que nace en su obra de nombre “Kitab al jabr wa´l-muqabala” (de nombres bonitos, nacen cosas bonitas), esta obra se cree es la más antigua que habla sobre algebra, por lo cual se da el merito a Al-Juarismi de ser el padre de la misma. En este texto se expone por primera vez la resolución de ecuaciones de primer y segundo grado, y un conjunto de reglas que guían al lector para resolver problemas, dándole significado a lo que es un algoritmo, hoy utilizado en todas las computadoras del mundo.

Blaise Pascal (1623 – 1662)

pascal

Fue un matemático francés del siglo XVII, fue el creador de una de las calculadoras mecánicas más antiguas, la Pascalina. La maquina servía al inicio para sumar, pero más tarde Pascal agrego aditamentos para que permitiera restar.

Lo interesante de la Pascalina, es que es una maquina mecánica de engranes y ruedas, que permitían sumar o restar. La maquina tenía 8 ruedas (6 para los enteros y 2 para los decimales) cada una con el número del 0 al 9; la Pascalina al momento de sumar el 1 al 9, la rueda que contenía el 9 se convertía en un 0, y la rueda vecina a la izquierda se movía de la posición inicial 0 al 1, dando 10 nuestra suma.

Alonzo Church (1904 – 1995)

church

Matemático y Lógico norteamericano, esta persona es la responsable de crear el concepto de computación, ya que fue el primero que describió este concepto en su sistema de nombre “Calculo Lambda” (con ayuda de Stephen Kleene).
El cálculo lambda nació para resolver el problema de Entscheidungsproblem (decimo problema de Hilbert). En el año de 1900, en el congreso Internacional de Matemáticos en Paris, el matemático David Hilbert planteo 23 problemas, en los cuales destaca el Entscheidungsproblem (o decimo problema de Hilbert). Hilbert buscaba un procedimiento algorítmico general para resolver un proceso matemático, y que este proceso nos dijera si la sentencia tenia solución o no.
El sistema de cálculo lambda sirve para definir si una función es computable, es decir, si un problema por medio de pasos y reglas puede llegar a su solución. Se puede considerar el cálculo lambda como el más pequeño lenguaje de programación.

Alan Turing (1912 – 1954)

Mucho circula alrededor de este gran matemático, criptógrafo y experto en computación, que muchos lo recuerdan por su suicidio con la manzana envenenada con cianuro.

Se podrían escribir libros y libros sobre lo que aporto a la computación, pero existe algo que sobresale entre todo, es la famosa maquina de Turing.

Al igual que Church, Alan Turing (alumno del primero) creó su sistema para resolver el decimo problema de Hilbert. Para resolver el problema concibió una maquina abstracta (objeto no físico), que tenía 3 elementos: una cinta de entrada, una cinta de salida y un procesador central (como los micros que tienes en tu computadora). La maquina funciona por medio de una tabla de reglas las cuales se aplican dependiendo el estado en que se encuentre la cinta, por ejemplo: si la cinta está en el estado 1 y hay una regla que nos dice que nos movamos al estado 3, la cinta se mueve y se vuelve a verificar la regla para ese estado, hasta llegar al estado final (lo cual nos diría que el problema fue resuelto). A partir de esta simple maquina hipotética, nació todo el manejo que realiza el CPU de las computadoras.

Jhon Von Neumann (1903 – 1957)

john_von_neumann

Matemático húngaro-estadounidense, es considerado uno de los más grandes matemáticos de la historia.

Su contribución en la computación radica en la Arquitectura de von Neumann. Esta arquitectura se basa principalmente en un la unidad aritmético-logica (ALU) que realiza los cálculos aritméticos, la unidad de control que se encarga de ir a la memoria principal por instrucciones para realizar, una memoria principal o memoria Ram que sirve para almacenar datos temporalmente, el sistemas de entrada/salida (un teclado de entrada o el monitor de salida por ejemplo) y el bus de datos que hace la comunicación de los datos en los distintos componentes. La mayoría de computadoras utilizan este modelo arquitectónico.

Konrad Zuse (1910 – 1995)

konrad

Ingeniero civil alemán, con grandes sueños desde pequeño, y culminándolos en la una idea grandiosa cuando cursaba la universidad. Zuse aburrido de realizar siempre procedimientos rutinarios a mano ideo una maquina la cual pudiera hacer cálculos. Más tarde logro su primer intento, una maquina llamada la Z1, la cual funcionaba por medio de tarjetas perforadas, pero nunca funciono bien, hasta que logro hacer mejoras y llego a la culminación de la primera computadora controlada por programas con el nombre de Z3.
Cabe destacar que Zuse fue el creador del primer lenguaje de programación de nombre Plankalkül entre los años 1943 y 1946, aunque el lenguaje solo fue propuesto teóricamente por Zuse.

Dennis Ritchie (1941 – 2011)

dennis


Fue un científico de la computación, mejor conocido por crear junto a Ken Thompson el sistema operativo de nombre Unix, que hoy en día los hijos (directos o indirectos) que desencadeno este sistema operativo son utilizados por la mayoría de personas; ¿no me creen? algunos hijos directos o indirectos son Linux, Android, IOS y la lista de sistemas operativos llega a cuatro ceros o más.
Pero antes de crear Unix, Dennis creo el lenguaje de programación más conocido en el mundo, el lenguaje C.
Toda persona que se dedica a la informática, ha tenido un encuentro con este lenguaje, y algo que destaca mas (para mi claro) que haber creado el sistema operativo Unix, es que los lenguajes que utilizan los desarrolladores de software hoy en día, le deben mucho al lenguaje C, ya que fue gran influencia a lo que se utiliza en la época moderna para crear sistemas computacionales.

Estos fueron 8 personajes que sobresalen como pilares de la computación que conocemos hoy en día, no son los únicos claro, pero si son de los más relevantes. Después de las aportaciones estas personas (y algunas otras), ya conocemos todo lo demás, que gracias a ellos tenemos para nuestra comodidad en cuestión de computadoras.

EL problema de los departamentos de sistemas en México

Esta entrada está dedicada a un problema que se presenta en la mayoría de empresas mexicanas ajenas al software (que se dedican a otro giro) pero que cuentan con un departamento de sistemas en el cual se desarrolla el software a la medida el cual requiere la compañía.
Enumerare una lista de puntos que para mí engloban la gran problemática en los departamentos de sistemas:

  1. El primer problema radica en que la empresa se dedica a vender un producto que nada tiene que ver con software, por lo cual su departamento de sistemas no es su prioridad, esto ocasiona que el departamento tenga bajo presupuesto, lo cual afecta tanto el equipo a utilizar como el personal a contratar, una empresa de este tipo termina contratando personal por 12,000 pesos al mes en promedio y lo único bueno que tiene para ofrecerle es las prestaciones ya que el ambiente en el que trabajaran deja mucho que desear. Si ofreces bananas, pues obtendrás changos (frase de Alex).
  2. El segundo punto lo centrare en la documentación, en la mayoría de departamentos de sistemas no les pasa por la cabeza documentar su software, no piensan en que pasara cuando el personal encargado de cierto proyecto renuncie o sea despedido, o el nuevo personal que corregirá los bugs o se encargara de terminar sistemas a medias, todo esto solo dirige que su personal siga renunciando, si se tiene un software sin documentación, esperen contratar adivinos ya que ningún programador piensa igual.
  3. Como tercer punto, mencionare a los programadores de la vieja escuela que siguen programando con lenguajes de programación antiguos y lo peor aún es que son lenguajes que ya tienen problemas con los mismos sistemas operativos, todo esto nos dirige a desarrollos que duran mucho más tiempo cuando puede mejorarlos utilizando lenguajes de quinta generación que aceleran el proceso de desarrollo. Este problema en parte es culpa del programador que se cierra a lo que conoce o teme conocer algo nuevo y también es culpa de la empresa, ya que esta última no obliga a su personal a capacitarse pagándoles cursos y certificaciones.
  4. En el cuarto y último punto menciono algo importante y es el hecho de las empresas por no tener un modelo de mejora y evaluación de procesos, por ejemplo CMMI, MoProSoft. Esto es una gran parte de todo el espiral de problemas que hay, ya que no solo se necesita saber programar, se necesita saber organizar el proceso de un software, no solo es que llegue Pepe y te diga quiero esto y en tiempo real vas al código de producción (si directo de producción, no es broma), y se modifica el cambio, después Pepe se enoja por que fallaron cosas que ya funcionaban, pues claro no se sigue una organización para realizar el cambio, es lógico que fallen cosas, y todo esto hace que el sistema valla tomando forma de Frankenstein.

Para concluir yo recomendaría que las empresas le den más importancia al área de sistemas, ya que son el núcleo de su logística, casi todos los departamentos dependen de un software creado en esta área, y siempre el personal de sistemas termina llevándose todas las culpas en la mayoría de ocasiones. Se necesita mejorar los departamentos de sistemas ya que es un beneficio para la empresa, si se mejora los procesos como se realiza un software, con procesos como toma de requerimientos, análisis, desarrollo, pruebas e implementación se puede mejorar en calidad, y la calidad reduce los errores en el software ya que hacer un software cuando Pepe viene a joder pedir un cambio, es un 99% que va a fallar algo, y Pepe tendrá que seguir chingando dando vuelta al departamento hasta que se esté listo el cambio. También las empresas invirtiendo dinero en capacitación a su personal tendrán gente más preparada y no se cerraran en utilizar herramientas de los años 80, a lo cual harán los desarrollos de forma más rápida. Y como ultima sugerencia, optar por tener un modelo de mejora y evaluación de procesos no está demás, ya que esto les daría un estatus de calidad superior y lo cual se vería sin duda reflejado en los ingresos monetarios que obtiene la empresa.

Existen muchos más puntos pero trate de englobar los que creo son los principales.

¿Cuantos planetas existen en el universo?

Cada que miramos al cielo siempre vemos las estrellas que van apareciendo a través de la noche, algunas son planetas otras un cumulo de estrellas y otras son como nuestro sol, pero siempre nos preguntamos cuantas estrellas habría en el universo, ¿pero por qué no? cuantos planetas habrá, y de estos cuantos con vida.



Existe una ecuación para calcular el número de civilizaciones existentes, pero no me enfocare a esos aspectos, ya que ni matemático soy, y en esa ecuación existen muchos parámetros desconocidos y solo son suposiciones, esa ecuación es la ecuación de Drake .

Bueno ahora vamos a sacar datos curiosos por medio de sentido común, sin un método científico ya que es absurdo hacerlo cuando no tenemos los parámetros enteros, así que solo haré algo de ocio con los datos que conocemos o estamos acercados por medio de la observación que se ha hecho del universo desde hace años.

Se estima que se tienen cien mil millones (100,000,000,000) de galaxias en el universo observable, de esas galaxias existen varias clasificaciones en cuanto a número de estrellas que existen en ellas, que va desde las enanas, con 10(10,000,000 diez millones), hasta las gigantes, con 1012(1,000,000,000,000 un billón) pero como no tenemos un dato exacto de cuantas hay enanas o gigantes tomaremos el número promedio que seria 109, que sería 1,000,000,000 mil millones de estrellas por galaxia.

Ya tenemos que son 100,000,000,000 cien mil millones de galaxias de las cuales cada galaxia tiene 1,000,000,000 mil millones de estrellas, por lo cual con una multiplicación tendríamos que: 1011 x 109= 1020 cien trillones de estrellas en el universo(100,000,000,000,000,000,000).
Ahora sacaremos los planetas promedio por estrella, para esto no me meteré en mucha problemática; si suponemos que nuestro sistema solar tiene 8 planetas y 5 planetas enanos (los conocidos hasta hoy 24-marzo-2012, Ceres, Plutón, Haumea, Makemake y Eris) tomaremos en cuenta que la mayoría de sistemas extra solares que han sido detectados no sobrepasan el numero de planetas de nuestro sistema planetario, quizá por falta de observación, eso no quiere decir que tengan menor numero, pero hasta el momento es lo que sabemos, tomaremos como referencia la mitad de nuestro sistema planetario para sacar el numero de planetas, por lo cual tendríamos en promedio 5 planetas mas 3 planetas enanos por sistema planetario, entonces tendríamos por unas simples multiplicaciones para sacar los planetas del universo:

1020 x 5 = 5020 quinientos trillones de planetas (500,000,000,000,000,000,000) y

1020 x 3 = 3020 trescientos trillones de planetas enanos (300,000,000,000,000,000,000)

Así que en el universo con los datos que conocemos, aproximadamente hay 3020  + 5020 = 8020 ochocientos trillones de planetas (800,000,000,000,000,000,000)

800 trillones de planetas de los cuales si suponemos que de cada 15 uno tiene vida (quince planetas de nuestro sistema solar y uno solo tiene vida) entonces:

8020 / 15 = 5319 cincuenta y tres trillones de planetas habitables (53,000,000,000,000,000,000)

Aunque no creo que de cada 15 haya uno con vida sino el numero debe ser mucho menor, pero como sea que veamos esa cantidad aun así el numero es enorme, aparte quizá en varios satélites haya vida pero esos no los tome en cuenta ya que el numero crecería radicalmente.

En resumen:

  • En el universo hay 100,000,000,000 cien mil millones de galaxias
  • De las cuales cada galaxia tiene 1,000,000,000 mil millones de estrellas
  • Esto nos da 100,000,000,000,000,000,000 cien trillones de estrellas en el universo
  • De las cuales cada estrella tiene en promedio 8 planetas (5 planetas y 3 enanos)
  • Esto nos da un total de 800,000,000,000,000,000,000 ochocientos trillones de planetas en el universo.
  • De los cuales en el mejor de los casos 53,000,000,000,000,000,000 cincuenta y tres trillones de planetas con vida en el universo

Este ultimo dato es exagerado pero el punto de este articulo no es ser exactos, ademas deberíamos tomar otros factores como de cuanto tiempo dura una civilización o un planeta con vida y cosas así, pero el fin de este articulo es tomar como dato curioso, que a pesar de nuestro planeta que parece enorme, el universo es demasiado grande, que solo cuando uno se pone a ver las cosas detenidamente, se comienza a ver que solo somos un grano de arena en este océano, llamado Universo.

Como detalle ya que estamos con esto de los números y multiplicaciones, la cantidad de planetas que existe aproximadamente en el universo si por cada planeta usamos la medida de un grano de arena (1 milimetro) y ponemos cada grano uno sobre otro formando una edificación, nuestra estructura mediría cerca a el ancho de la Vía Láctea.