Por favor lean este excelente artículo de @micronauta: http://blog.canal.cl/2010/07/wi-fi-podria-degradarse-en-chile-por.html
Después de casi 5 años usando MovableType este blog ha cambiado de tecnología y de look. Así que espero que les guste el nuevo diseño, y disculpen las molestias que este cambio pueda causar.
Próximamente retomamos las "transmisiones". Gracias por leer este blog, y si tienen comentarios, o indicaciones sobre el nuevo look se los agradeceré.
Por cierto la pregunta es interesante:
"¿cual es la forma más eficiente de ordenar un millón de enteros de 32 bits?"
Seguro que no elegirían bubble sort, en eso el Presidente Obama tiene toda la razón.
Pero, ¿cuál es la respuesta a esta pregunta? En el próximo post la respuesta.
Que algo sea lógico no significa que sea razonable, ni tampoco lo inverso. Muchos confunden lo lógico con lo razonable, ese es un error bastante común.
Una de las cosas que no podemos perdonarle a Gene Rodenberry y al Señor Spock es el sentido que le dan a la palabra lógica.
El problema es que cuando Mr. Spock dice "eso no sería lógico", en realidad quiere decir que es "eso no sería razonable". Este es un ejemplo más de como la televisión, incluso la de calidad, estropea la cultura de las personas.
Casi siempre cuando se dice que un hecho es lógico, en realidad quieren expresar lo contrario, que ese hecho parece correcto basado en la intuición y el sentido común.
Siendo estrictos, cuando decimos que algo es lógico por si mismo estamos diciendo un sinsentido. Por que lo que significa que una sentencia sea lógica es que esa afirmación se infiere de un conjunto de axiomas mediante un sistema de racionamiento formal. Si no conoces el sistema formal, ni los axiomas, entonces no puedes afirmar si la sentencia es lógica, y decir que algo es lógico carece de sentido.
Además, las cosas que la gente llama "lógicas" ni siquiera son inferibles a partir de ningún axioma.
Pueden ser cosas razonables, pero no son lógicas, a menos que te muestren la cadena de inferencias y razonamientos previos.
La lógica no es una cosa, sino una forma de nombrar a una familias de sistemas de pruebas formarles con sus reglas de inferencia.
Hay muchas lógicas, como lo expone Mark Chu Carroll, en "Mr. Spock no es lógico"
Hay muchas lógicas, y un sentencia que es una inferencia válida (es decir, es lógica) en un sistema puede no serlo en otro. Para darles un ejemplo simple, piensen en una sentencia como "La casa de la esquina es roja". Mucha gente dirá que es lógico que esa sentencia ya sea verdadera o falsa: después de todo, la casa es roja o la casa no es roja. De hecho, la mayoría estaría de acuerdo en que la sentencia "La casa es roja o no es roja" debe ser verdadera.
En la lógica más común, llamada la lógica de predicados, esto es absolutamente correcto. La sentencia original es verdadera o falsa, la sentencia con un "o" entre medio debe ser verdadera. Pero en otra lógica común, llamada lógica intuicionista, esto no es verdad. En lógic intuicionista, hay tres posibles valores de verdad: algo puede ser verdad (lo que significa que hay una prueba de que es verdad); algo puede ser falso (lo que significa que hay una prueba de que es falso); y algo puede ser desconocido hasta el momento (lo que significa que no hay prueba en ningún sentido).
Adicionalmente a tener distintas maneras de definir lo que es verdad o demostrable, las lógicas pueden describir diferentes cosas. Nuestra buena, vieja y familiar lógica de predicados es inútils para describir cosas que involucren el tiempo, realmente no hay una buena manera en la lógica de predicados de decir "Estoy siempre hambriento a las 6pm". Pero hay otras lógicas, llamadas lógicas temporales que están diseñadas específicamente para construir sentencias sobre el tiempo.
Ahora, lo interesante de la lógica es que es totalmente mecanizable. No necesitas entender las sentencias dentro de un razonamiento para poder realizar inferencias. Eso es importante entenderlo, porque muchas personas se enredan y no notan que sus razonamientos no siguen una cadena lógica, y es fácil demostrarles que están equivocados, sin tener que emitir ningún jucio de valor a sus palabras. Eso se puede hacer, pero no necesariamente sería algo razonable, sobretodo si estás discutiendo con tus amigos.
Mi anterior apunte sobre contol de versiones tuvo buena aceptación, y recibí comentarios de gente que no es desarrolladora de software, lo que es bueno. Insisto en que el control de versiones es una herramienta que tiene aplicaciones fuera del mundo de la programación.
Pero la vez anterior hablamos de sistemas centralizados, como Subversion (SVN) o CVS, los más populares. Pero esta vez les quiero invitar a que prueben los sistemas de control distribuidos, o DCVS por sus siglas en inglés.
Si ustedes no tienen la mente dañada con sistemas como Subversion o CVS, no tendrán problemas en adoptar estos sistemas, y les sugiero explorar entre los dos más populares en la actualidad Mercurial (hg) y GIT.http://git-scm.com/.
Cuando uno se enfrenta por primera vez a un DCVS viniendo del mundo de los sistemas centralizados, cuesta adoptar este modelo. Hay que reaprender algunas cosas.
Sugiero leer este tutorial de Joel Spolsky, donde explica muy bien los cambios que debemos adoptar cuando entramos desde un sistema centralizado como Subversion a un DCVS, como Mercurial en su caso.
Lo principal es la libertad que podemos ganar como desarrolladores.
Subversion no nos deja beneficiarnos del control de versiones porque siempre nos obliga a hacer commit cuando el código está completamente probado y libre de errores, o de lo contrario estamos arruinando el trabajo de los demás.
Esta viñeta de Geek and Poke expone el problema:
Con un DVCS los programadores trabajan en sus copias particulares del repositorio sin interferir en el código central.
Los DCVS tienen muy buenos sistemas que permiten mezclar (merge) el código que viene desde distintas ramas.
En este sentido GIT es un ejemplo destacado, puesto que el mismo Linus Torvalds es capaz de hacer un merge desde 12 distintas ramas casi sin ningún problema.
Yo he evaluado 4 herramientas, usándolas bastante tiempo para mi trabajo personal.
La primera herramienta que ocupé fue Bazaarr, hace unos 3 años. Bzr es la herramienta usada por Canonical, en el desarrollo de Ubuntu. Está desarrollada en Python, y es bastante simple de usar.
La segunda fue Darcs, es una herramienta interesante, desarrollada por un físico cuántico y que tiene un modelo matemático (algebra de parches), y está escrita en Haskell. Recomendable para el que tenga inclinaciones más académicas.
La tercera y cuarta son Mercurial y GIT.
Como dijo alguien por ahí, GIT es McGyver, Mercurial es James Bond, ambos tienen sus pro y contras.
A mi me gusta GIT, y es lo que uso en la actualidad en forma personal, llevar el cambio al ambiente corporativo donde trabajo creo que tomará tiempo, pero puedo seguir interoperando con Subversion gracias a GIT.
Lo que más me gusta de GIT es que es una herramienta muy rápida, es probablemente el controlador de versiones más rápido que he usado, incluso cuando hago un push a un servidor central en internet.
Pero la decisión es de ustedes. Si nunca han usado Subversion o CVS, es mejor elijan una herramienta DCVS. Si me preguntan a mi, les recomiendo GIT, o Mercurial, probablemente la última es más simple de usar, pero la primera es más flexible y rápida.
Image via Wikipedia
¿Usaron alguna vez SCCS? ¿No? ¿Que tal RCS? ¿Tampoco? Bah, son ustedes muy jóvenes. Pero, usan un sistema de control de versiones, ¿verdad? Hoy es raro que un desarrollador no use un sistema de control de versiones como CVS o Subversion (conocido también como SVN).
Lo que no me explico es ¡por qué no lo usa todo el mundo!
Verán, mucha gente escribe un archivo word, "aburrido_informe_para_el_auditor.doc", empiezan a trabajar en este, si son astutos, y tienen experiencia, antes de realizar una modificación hacen una copia y empiezan a trabajar en "aburrido_informe_para_el_auditor-version-2.doc", y después en "aburrido_informe_para_el_auditor-version-3.doc" y sigue la cosa, y la carepta se llena de archivos como "informe_auditor_4.doc", informe-auditor-final.doc", "informe-para-el-auditor-revisado-por-mi-jefe.doc", "informe-ups-me-equivoqué-en-losplazos.doc" y así, la carpeta de trabajo es un desastre, si es que usan carpeta, y no lo tienen desparramado en el escritorio (los lectores de LNDS no hacen eso, por supuesto).
Los programadores tenemos este problema, pero multiplicado por mil, porque los usuarios están llenos de ideas creativas y el software va cambiando todo el tiempo, y a veces hay que volver atrás. O tienes código que implantas para un cliente, y luego se crea una rama de código con modificaciones ad hoc para un cliente. Los escenarios son múltiples.
Es por eso que desde 1972 tenemos sistemas de gestión de versiones de código. Los primeros eran los que mencioné en la primera parte de este artículo. Estos primeros sistemas estaban orientados al trabajo individual de cada programador.
El problema era cuando un equipo de programadores trabajaban en el mismo proyecto, ahí nacieron sistemas centralizados, como CVS, SourceSafe (de Microsoft), Perforce, y el más famoso de todos Subversion.
No les voy a explicar acá qué es un sistema de control de versiones, sólo les voy a sugerir, si no son programadores, que investiguen sobre estas cosas, y las utilicen en su trabajo, es una buena estrategía (para los diseñadores web esta es una herramienta muy útil).
En lo que si me quiero meter es en el tema de los sistemas de control de versiones distribuidos, que son, en mi opinión (y no estoy sólo en esto), un gran avance en nuestro campo. Pero eso lo vamos a dejar para el próximo post.
El gráfico de más abajo muestra las ventas, en miles de millones de dolares, para el 2007 en diversas industrias, la principal diferencia es el grado de protección a la propiedad intelectual entre ellas. A la izquierda están las que tienen muy baja, o casi ninguna protección a la propiedad intelectual, y a la derecha las industrias con alto grado de protección a la propiedad intelectual:
La gráfica es parte de la presentación que Johanna Blakley dió en TEDxUSC este año.
La presentación es brillante, y cuando llega a este gráfico recibe aplausos. Al fin y al cabo, la moda tiene su base en la imitación, como complementa (sincronía otra vez) muy bien La Valentina (los énfasis son míos):
[...] la imitación se transforma en un instrumento clave de navegación social, imitar al otro implica necesariamente, primero, un reconocimiento de sus señales diferenciadoras y luego una identificación con ellas, constituyéndose en el primer paso en la generación de comunidad la cual termina de constituirse cuando unos y otros hacen suyas y consolidan esas señales como un código compartido o las rechazan estableciendo la diferencia. Es la imitación la que nos otorga esa seguridad de que no estamos equivocados, de que no nos hemos salido erróneamente de los márgenes delimitados por el grupo al cual pertenecemos, o bien no nos alejamos aun más de ese grupo de personas al cual queremos que nos relacionen. Es por tanto la imitación la manera más segura de sentirse parte de algo, y por tanto de sentirse especial y distinguido respecto de quienes aún no logran alcanzar este carácter de especial. Es también desde aquí desde donde buscamos la diferencia, aquello que no nos hace como esos, pero que indefectiblemente busca encontrar su sentido en otros, otros.
La imitación es la base para empezar a innovar. Creo que estas lecciones son importantes, y debemos reflexionar sobre esto, es gratificante escuchar estas lecciones.
Les dejo el video:
Imagen via Wikipedia
Hemos hablado bastante de cloud computing en este blog, pero creo que no hemos precisado mucho que significa esto de la computación en la nube.
Tener una definición clara de lo que significa este término es importante para tomar decisiones. Hay un video que me sugirieron, que es bastante bueno como introducción, pero se necesita algo más preciso desde el punto de vista técnico.
El NIST tiene una guía bastante útil que contiene definiciones precisas sobre el tema y que voy a compartir con ustedes.
Lo primero que hay que entender que el cloud computing es un paradigma en evolución. Las definiciones van a cambiar en el tiempo. La industria del cloud computing representa un vasto grupo de empresas, modelos, oferentes, y nichos de mercado. La definición del NIST trata de cubrir todo estos temas.
Cloud Computing
Según el NIST, el Cloud Computing es un modelo para habilitar un acceso conveniente, en demanda y a través de la red, a un conjunto de recursos computacionales compartidos (por ejemplo, redes, servidores, almacenamiento, aplicaciones y servicios), los que pueden ser provisionados y liberados rápidamente con un mínimo esfuerzo administrativo o con poca interacción con el proveedor de servicios. Este modelo de nube promueve la disponibilidad y se compone de cinco características esenciales, tres modelos de servicio y cuatro modelos de implementación.
Características Esenciales
Auto servicio a demanda. Un consumidor puede unilateralmente provisionar capacidades computacionales, tales como tiempo de servidor y almacenamiento en red, de acuerdo a la necesidad y en forma automática sin requerir de una interacción humana con cada proveedor de servicio.Amplio acceso a través de la red. Las capacidades están disponibles a través de la red y se accesan a través de mecanismos estándares que promueven el uso desde plataformas clientes diversasa (por ejemplo, teléfonos móviles, laptops, PDAs).Disponibilidad de recursos. Los recursos computacionales del proveedor se agrupan para servir a múltiples consumidores usando un modelo de arriendo múltiple, con diferentes recursos físicos y virutales asignados dinámicamente y reasignados de acuerdo a la demanda del consumidor. Hay un sentido de independencia de la localización en que el consumidor generalmente no tiene control o conocimiento de la localización exacta de los recursos provistos, pero puede especificar la localización a un nivel más alto de abstracción (por ejemplo, un país, estado o datacenter). Ejemplos de estos recursos incluyen el almacenamiento, procesadores, memoria, ancho de banda y máquinas virtuales.Rápida Elasticidad. Las capacidades pueden ser rápida y elasticamente provisionadas, en algunos casos automáticamente, para escalar rápidamente y ser liberadas rápidamente para reducir la escala de operación. Para el consumidor, las capacidades disponibles para el provisionamient a menudo parecen ser ilimitadas y pueden ser compradas en cualquier cantidad en cualquier momento.Servicio Medido. Los sistemas en nube automáticamente controlan y optimizan el uso de recursos al aprovechar las capacidades de medición en cierto nivel de abstracción apropiado para el tipo de servicio (p.ej. almacenamiento usado, procesamiento, ancho de banda, cuentas de usuario activas). El uso de recursos puede ser monitoreado, controlado y reportado, proveyendo transparencia para ambos, el proveedor y el consumidor del servicio utilizado.
Modelos de Servicio
Los modelos de servicio son tres:
Nube tipo Software como un Servicio(SaaS). La capacidad provista para el consumidor es usar las aplicaciones del proveedor corriendo en una infraestructura en la nube. Las aplicaciones son accesibles desde varios dispositivos clientes a través de una interfaz de cliente "delgada" como un navegador web (p.ej. correo electrónico en la web). El consumidor no administra o controla la infraestructura de nube subyacente que incluye redes, servidores, sistemas operativos, almacenamiento o incluso las capacidades individuales de la aplicación, con la posible excepción de ciertas configuraciones específicas para el usuario en la aplicación.
Nube tipo Plataforma como un Servivio (PaaS). La capacidad que se le provee al consumidor es la de desplegar en la infraestructura en la nube las aplicaciones, propias o adquiridas, creadas usando lenguajes de programación y herramientes soportadas por el proveedor. El consumidor no administra o controla la infraestructura de nube subyacente, incluyendo redes, servidores, sistemas operativos o almacenamiento, pero tiene control sobre las aplicaciones desplegadas y posiblemente sobre las configuraciones del entorno de alojamiento.Nube tipo Infraestructura como un Servicio (IaaS). La capacidad provista al consumidor es provisionar procesamiento, almacenamiento, y otros recursos computacionales fundamentales donde el consumidor es capaz de desplegar y ejecutar software arbitrario, el que puede incluir sistemas operativos y aplicaciones. El consumidor no administra o controla la infraestructura de nube subyacente pero tiene control sobre los sistemas operativos, almacenamiento, aplicaciones desplegadas y posiblemente un control limitado sobre componentes selectas de las redes (p.ej. los firewalls de sus hosts).
Modelos de Implementación
Nube Privada. La infraestructura de nube es operada solamente por una organización. Puede ser manejadas por la organización o una tercera parte y puede existir siempre, o ante una situación específica.
Nube Comunitaria. La infraestructura es compartida por varias organizaciones y soporta a una comunidad específica que tiene preocupaciones compartidas (p.ej. misión, requerimientos de seguridad, políticas, y consideraciones de conformidad). Puede ser administradas por las organizaciones o una tercera p
arte y puede existir permanentemente o ante situaciones específicas.
Nube Pública. La infraestructura es provista al público general o a un grupo de industria grande y es propiedad de una organización que vende servicios en nube.
Nube Híbrida. La infraestructura de nube es la composición de dos o más nubes (privadas, comunitarias o públicas) que permanecen como entidades únicas pero están enlazadas juntas por una tecnología estandarizada o propietaria que permite la portabilidad de datos y aplicaciones. (ej. cloud bursting (ruptura de nubes) para permitir el balanceo de carga entre nubes).
¿Qué es Información?
¿Qué es la computación?
¿Qué podemos saber a través de la computación?
¿Qué no podemos saber?
Estas preguntas una vez eran sólo del interés de los especialistas en computación, pero estas preguntas ahora son preocupación de gente en todos los campos de la ciencia, ingeniería y aún en la política (menos en Chile, claro).La computación es la ciencia de los procesos de información. Se han descubierto procesos de información en las estructuras profundas de todos estos campos.Descifrar los misterios de estos procesos permitirá lograr grandes avances en estos campos. Los principsio de la computación están ayudando en esta tarea.La computación necesita un nuevo lenguaje para sus principios básicos. La forma tradicional de enfocar las ideas en las tecnologías de computación coloca al computador, mas que a la computación, en el centro. El computador es la herramienta, la computación el principio.El proyecto Great Principles of Computing está desarrollando un lenguaje para discutir los principios fundamentales de la computación. Este marco de referencia está ayudando a fomentar la colaboración entre la computación y otros campos. Está ayudando a las innovaciones exponiendo las conexiones antes no vistas entre las tecnologías. Está ayudando a comunicar la alegría, el placer de la computación a la gente jóven, quienes pueden ver ahora como estos principios les sirven en su vida diaria, aún cuando se encuentren desconectados de sus computadores.
El texto anterior viene del sitio Great Principles of Computing, una
Peter Denning, Image via Wikipedia
iniciativa liderada por Peter Denning.
Cuando entendemos los principios de la computación no nos enredamos más con terminologías erróneas, y tenemos claros los conceptos (por qué hablamos de TI y no de TIC, por ejemplo). Entendemos por qué es importante entender el poder de la computación, y por qué ésta es una ciencia fundamental.
Denning y su equipo han desarrollado un marco conceptual, tras analizar varias tecnologías de la computación para identificar los principios en que están basadas, y estudiando cómo los aspectos de la computación están influenciando otros campos. De este análisis han conluido que los principios de la computación pueden ser agrupados en siete categorías:
Computación (sentido y límites de la computación)Comunicación (transmisión confiables de los datos)Coordinación (cooperación entre las entidades en red)Recolección (almacenamiento y recuperación de la información)Automatización (sentido y límites de la automatización)Evaluación (predicción del desempeño y planificación de la capacidad)Diseño (construcción de sistemas de software confiables)
Estas categorías son el resultado de un anáñisis funcional de muchas tecnologías y aplicaciones de la computación.
- Los sistemas computacionales se construyen de "elementos de procesamiento" que procesas y almacenan información (computación, recolección).
- Los elementos de procesamiento intercambian información (comunicación).
- Los elementos de procesamiento cooperan hacia una meta común (coordinación)
- Los humanos delegan las tareas a los sistemas de elementos de procesamiento (automatización).
- Los humanos predicen la velocidad y capacidad de los sistemas (evaluación) y
- Los humanos descomponen los sistemas en elementos de procesamiento y organizan su construcción (diseño).
Estas categorías son ventanas para observar el espacio de conocimiento de la computación, más que zonas o separaciones. Cada ventana ve el espacio de una manera distintiva, pero la misma cosa puede ser observada por más de una ventana. Por ejemplos, los protoco
los de internet, a veces son vistos como comunicación de datos, a veces como mecanismos de coordinación y a veces como medios para la recolección.
Cuando estudié el ramo de física moderna en la escuela de ingeniería, me contaron una historia, que partió con el intento de Planck de explicar la radiación de cuerpo negro con un modelo más adecuado, compatible con lo observado y que no llevara a los absurdos predichos por el modelo clásico, esta historia seguía con el trabajo de Einstein y la confirmación de la existencia de los cuantos de energía.
La ciencia explica sus principios de esta manera, mediante historías, donde en una narrativa se cuenta como el pincipio evolucionó y alcanzó una mayor aceptación con el tiempo. Se nombran los principales contribuyentes a esta ideas. Se explican los errores iniciales, y finalmente como operan estos principios, y cómo afectan a todo el resto. En computación las historias que narren los principios de nuestra ciencia son relativamente poco comunes.
Lamentablemente en la formación de los ingenieros de la computación, estas narrativas los principios, de cómo evolucionaron las principales ideas de nuestro campo, no están presentes. He visto ingenieros de computación que ignoran totalmente quién fue Alan Turing, Knuth, Parnas, o el mismo Denning, cuales son los principios que ellos aportaron al campo.
Esas narrativas son las que debemos recoger, difundir, entre los especialistas, y los jóvenes que queremos formar, y entre los que no son especialistas, pero se ven afectados por nuestro trabajo. Esa es otra misión de este blog difundir estas narrativas, y estos principios de la computación.
Síguenos
Síguenos (RSS)
Archivos
Estadísticas
