manudo_cr7

Popularidad de los lenguajes de programación A enero de 2010 Me encontre en la web esta comparativa-ranking de los lenguajes mas populares, sin duda me llamo la atencion que el lenguaje mas usado en mi pais (Costa Rica), este entre los 5 mas usados... Los dejo con la noticia... TIOBE ha publicado la primera revisión de su índice para el 2010. Éste índice trata de reflejar la popularidad de los lenguajes de programación; para ello se basa en el número de ofertas laborales que se publican en varios portales de Internet para los distintos lenguajes, el número de libros publicados sobre cada lenguaje, la respuestas que varios buscadores de Internet devuelven a consultas relacionadas con el lenguaje y métricas de este tipo. En general, se le considera el índice que mejor refleja la popularidad de los distintos lenguajes de programación. A lo largo del año 2009 han pasado cosas interesantes en el índice. Por un lado, Java ha ido perdiendo su supremacía (llegó a tener por encima del 20%, es decir "más de un quinto de la popularidad total". Java lleva liderando este índice desde el 2004. Por otro lado, C (en segunda posición desde que Java le desbancó) ha ido recortando diferencia con Java. Según las impresiones de Mitchell Pronschinske (blogger muy recomendable) uno de los motivos podría deberse a que cada vez hay más lenguajes de programación dentro de la plataforma Java, lo que hace que el lenguaje Java "pierda" parte de su popularidad. Probablemente la gran sorpresa del 2009 haya sido PHP, ahora el tercero del ranking tras haber pasado a C++ (tercer lenguaje de programación más popular durante muchos años) y visual Basic, que todavía sigue siendo el quinto lenguaje de programación más popular. Los dos lenguajes que relativamente más han ganado durante el 2009 han sido Go (sin duda por el apoyo de Google) y Objetive C. Por último, por primera vez, Ruby ha llegado al top 10 del ranking. ¿Coincide vuestra percepción del mercado laboral con los resultados de este ranking? Fuente: www.javahispano.com LINK

Cosas raras e incomprensibles del mundo Supongo que todos vosotros os habréis fijado en cosas que pasan a vuestro alrededor. O no. Simplemente pasáis por el lado de cosas curiosas e incomprensibles que pasan y no sois conscientes de esa tontería que acaba de pasar. Pero yo vengo aquí a daros ejemplos claros sobre las tonterías que se hacen en el mundo. Por ejemplo, una cosa tonta y que es habitual es esta: ¿Por qué leches ponen ceniceros en los trenes si está prohibido fumar? Yo no soy fumador, pero si lo fuese me estarían provocando unas ganas de algo que encima me prohíben, ¡pues qué mala leche de los creadores de trenes! Y tú pensarás, pues lo mismo es que te vendan tabaco en la gasolinera y está prohibido fumar allí. ¡Error! Porque en las gasolineras no hay ceniceros, dan por supuesto que no vas a fumar, aunque lo compres. Es como si dices que vaya contradicción comprar condones en la farmacia si dentro está prohibido jincar. Pues eso. Lo mismo pasa, o algo parecido, en el metro. Tú vas tan tranquilo en el metro, bueno, tranquilo no, a reventar de gente. Y justo cuando ves que no te puedes agarrar a ningún sitio vas para el pasillito, y allí hay unas agarraderas. Dices bien, aquí me puedo quedar. Pues no, hay un cartel que pone: "No os quedéis dentro del pasillo, gracias". Oye, pues no pongáis agarraderas porque sinó me voy a quedar fijo... Es como si vas al campo y te dicen, "aquí no se puede hacer pis". ¡Pues no me pongas el árbol! ¡Los perros lo hacen! A mí me parece incomprensible, sobretodo, algunos comportamientos de personas. Como por ejemplo el ir leyendo por los pasillos del metro, por las escaleras, caminando, agachándose a atarse los cordones... En fin, no sueltan el libro. ¿Lo tienen enganchado con SuperGlue? ¿Está tan interesante que no lo pueden soltar para nada? ¿Cómo es posible que nunca se caigan? Y es más, si están tan atentos para no caerse, ¿cómo son capaces de seguir el hilo del libro? Si hay algún lector de esta web que lee así, que por favor, me lo explique porque tengo un sinvivir en mí. También son incomprensibles algunos nombres, como en los Simpsons que decían: "¿Cómo puede ser que inflamable signifique flamable?" Que decía el doctor Nick cuando quemó su consulta. Como también llaman inodoro al water. A ver, supongo que sería menos "odoro" que las letrinas antiguas, pero de ahí a decir que no huele... Vamos, ya tienes que echar ambientador para que después de una "liberada de Willy" no huela. En fin, que en el mundo hay montones de cosas difíciles de comprender, si sabéis alguna más no dudéis en comentarlo, y si se me ocurren más, habrá nuevo post. SAludos desde Costa Rica y visiten mis otros posts Leyendas Urbanas de la Informatica Linux, Toda una Religion Historias de Horror en Programacion Programas 2009 en descarga directa MacOs en tu PC Intel, No es un sueño Programas poco comunes muy utiles Top Ten Programas Libres Las computadoras en las peliculas (Curiosidades)

Saludos Chicos... Me llego al correo esta imagen tan graciosa y queria compartirla... Saludos desde Costa Rica y visiten mis otros posts... Historia de un Programador Anecdotas de un Programador Peliculas para programadores Un Cuento de Programacion...(erase una vez) Leyendas Urbanas de la Informatica Linux, Toda una Religion Historias de Horror en Programacion Programas 2009 en descarga directa MacOs en tu PC Intel, No es un sueño Programas poco comunes muy utiles Top Ten Programas Libres Las computadoras en las peliculas (Curiosidades) Se nos va winXP Solo para informaticos Actualiza tu WinXP Offline Pack Programas 2009 Descarga Directa

Leyendas Informáticas Este es un artículo tomado de la revista PCWorld, donde se resuelven muchas dudas sobre leyendas y mitos relacionados con la informática. Borrado de los datos de un disco de 3,5” por imantación: Si acercamos un imán promedio a un disco flexible de 3,5” (cuando existían) perderemos sus datos a causa de la imantación, ya que el imán se peguera al disco y se cargara los datos al variar el campo magnético del disco, esto es cierto. Sin embargo esto no pasa con otros medios de almacenamiento actuales como las memorias Flash ya sean USB (ej: Pendrives) o mediante tarjetas de memoria (SD; MMC; Compact Flash; xD; Memory Stick;…), ya que no se basan en un sistema de almacenamiento magnético por lo que no pierden los datos; curiosamente los discos duros a pesar de ser un sistema de almacenamiento magnético no resultan afectados por un imán de poca potencia; sin embargo ambos (Memorias Flash y Discos duros) podrían verse afectados por la fuerza de un imán muy potente, cosa que no se encuentra en el ámbito domestico, aunque si existen imanes de este tipo (denominados degaussers) en laboratorios de investigación. Desenchufar un dispositivo USB sin detenerlo antes en Windows XP puede dañarlo: es posible que pueda producir una perdida de datos e incluso dañe el dispositivo en cuestión, aunque depende del tipo de dispositivo, “ejemplo: un redactor de PC World desconecto una memoria flash USB que tenia actividad en segundo plano, el resultado fue la perdida de los datos y unidad flash USB dañada”. Para desconectar un dispositivo USB en Windows XP y/o Windows Vista es necesario desconectarlo desde la opción de desconectar hardware con seguridad; pero hay que tener en cuenta que no todos los dispositivos USB admiten esta opción por lo que si se quitan no debería haber ninguno problema ya que no seria necesario deternerlo. Que hacen las Cookies: las cookies sirven para personalizar un website al usuario, para ello guardan cierta información del mismo, sin embargo mucha gente piensa que las cookies también sirven para seguir todo el movimiento del usuario a través de internet cosa que no es cierta, al menos no todas las cookies hacen esto. Responder al correo no deseado (Spam) genera más spam: no esta demostrado que esto sea cierto, sin embargo si no se responden los correos tampoco se podría saber si se va a recibir más spam, aun así los spammer tienen métodos para conseguir direcciones de correo electrónico, la única solución es aplicar filtros antispam si es posible. Una persona puede destruir datos del disco duro desde un ordenador remoto: Totalmente posible, de hecho algunos virus/gusanos como el MyDoom.f eliminaba archivos aleatoriamente, así mismo si un hacker consigue entrar en un sistema (ej: usando un troyano) puede controlar la máquina de forma remota de tal forma que podría hacer con los ficheros prácticamente lo que quisiera (abrirlos, editarlos; imprimirlos, cambiarlos de sitio; borrarlos;…) sin ningún tipo de problema, de ahí la importancia de tener un buen sistema de seguridad formado por un antivirus (AV) de calidad, y un cortafuegos (firewall). Apagar el ordenador para ahorrar energía acorta la vida útil del ordenador: parece que esto no esta muy claro, pero parece que la balanza se inclina a favor del apagado para ahorrar energía; no obstante la vida útil de un procesador (CPU) normalmente es de unos 10 años con lo cual posiblemente un usuario cambie de ordenador, antes de que este “muera”. Sin embargo las piezas electromecánicas (ej: discos duros; disqueteras; unidades ópticas; ventiladores;…) si que tienen una vida útil limitada que suele ser mucho más corta que la de las piezas electrónicas (ej: una CPU; modulo de RAM, una gráfica, tarjeta de sonido,…). El Sistema Operativo (S.O) DOS (Disk Operating System) esta muerto: bueno se puede decir que MS-DOS esta casi “muerto” sobre todo desde la aparición de los Sistemas Operativos con entorno gráfico como Windows (Windows 98 y siguientes que no tenían MS-DOS como principal sistema o ni siquiera lo implementaban como era el caso de la familia NT), sin embargo parece ser que aún se usa en muchas empresas; y no solo eso sino que la emulación de MS-DOS que tiene Windows XP por ejemplo resulta muy útil cuando Windows XP no responde a una orden dada por el usuario (ej: borrar un archivo y no poder ser borrado porque esta en uso a pesar de no ser cierto), cosa que con el modo MS-DOS emulado no suele suponer problemas (a veces tampoco funciona, aunque si se reinicia el ordenador normalmente se pude borrar desde Windows); así mismo muchos programas de testeo de discos duros o RAM suelen estar basados en el sistema DOS (no en MS-DOS); actualmente se puede encontrar Free-DOS como sistema compatible DOS. El uso de sistemas de sobretensión/sobrevoltaje mejora la seguridad del equipo: esto es cierto sin embargo parece ser que no hay que fijarse solo en los "joules" (unidad de medida de energía) que soporta y el tiempo de respuesta, sino también en que el dispositivo pase la norma UL 1449 que es un estándar de seguridad para suprimir los sobrevoltajes transitorios. Se pueden distinguirse básicamente dos tipos de sistemas: la típica regleta con diversas tomas de corriente que simplemente actúa en caso de sobretensión/sobrevoltaje protegiendo lo que este conectado a ella; y los SAI (Sistema de Alimentación Ininterrumpida) o UPS (Uninterruptible Power Supply) que además de actuar frente a sobretensiones/sobrevoltajes, en caso de apagón permiten trabajar con el ordenador el tiempo justo para guardar el trabajo y poco más (aunque esto depende de la autonomía del SAI/UPS y del consumo del ordenador) ya que tienen unas baterías. Las baterías de un portátil pierden su capacidad si no se recargan siempre desde cero: actualmente esto no es cierto, ya que las baterías de ion Litio, son las mas comunes, no tienen efecto “memoria” (cosa que si ocurre con las anteriores de Níquel-Cadmio, Ni-Cd). Las baterías de Ni-Cd deben descargarse totalmente una vez cada 3 meses para evitar el efecto memoria y asi estropear la batería; mientras que las de Litio se pueden cargar sin preocuparse del efecto memoria, sin embargo aconsejan que las de Litio se descarguen al menos cada 30 veces, es decir por cada 30 cargas de una batería de Litio se debe cargar esta una vez desde cero, no para preservar la vida de la batería sino para que el indicador de batería del portátil sea correcto. Esto mismo se puede aplicar a otras baterías similares como por ejemplo las usadas en los móviles o PDA´s. Perdon muchachos si no puse imagenes pero el post era un poco largo y no enconre algo relacionado al post que ya estuviera en la red... fuente:hinchasdelatlas

Historias de Horror en programación Con motivo del Jalogüin, les pongo un par de historias de horror, que me tocó vivir en distintos proyectos. 1. El password como llave primaria En un trabajo hace ya mucho tiempo, me tocó revisar un proyecto que habían realizado otras personas, porque estaban atoradas en una cosa que no les salía. Me hicieron una demo del proyecto (un sitio web ya no recuerdo ni para qué pero era de los típicos que requieren que la gente se registre para entrar y ver o mover cosas). Lo noté algo lento y luego llegamos a la parte problemática y ya me enseñaron el error que salía y todo. Empezamos a ver el código de la página y noté algo raro; la página que fallaba era de las que ya estaban dentro del sitio, no requería autenticación adicional porque el usuario ya se había identificado para entonces y no era algo crucial en cuanto a seguridad se refería; sin embargo, había varias referencias al password del usuario. Así que empecé a preguntar, y se me fue bajando la presión, como cuando descubres algo horrible, tan horrible que tu cerebro no lo puede procesar, se niega a aceptar esa realidad... el password era la llave primaria de la tabla usuario. Seguramente sus ojos pasaron por esa frase pero su cerebro no la pudo procesar así que ahi va de nuevo: el password era la llave primaria de la tabla usuario. Bueno, lo primero que me vino a la mente: estaban encriptando el password al menos? si. Pero no le ponían sal, sino que lo encriptaban solito. Cuando encriptas un password normalmente usas un dado adicional, como el nombre del usuario, para que la encripción del mismo password pero con datos adicionales distintos resulte distinta, y de esa manera si Juan y Pedro tienen el mismo password "password", cuando lo encriptas usando como sal "Juan" sale algo muy distinto de encriptarlo usando como sal "Pedro". Pero aquí nada más encriptaban el password solito. De modo que si Juan y Pedro usaban de password "password", el resultado era idéntico en ambos casos. Entonces, si Juan se registra usando "password", qué pasa cuando Pedro se quiere registrar también usando "password"? Ah pues muy fácil! a Pedro le parece un mensaje de error diciéndole que ese password ya está siendo usado por otro usuario y que por favor escoja uno distinto. Woooooow. Les dejo las implicaciones de esto a su imaginación. Bueno y después pensé en otra cosa que no sé si es todavía más seria, cuál es la peor de las dos: Si el password es la llave primaria del usuario, entonces cualquier dato relacionado con el usuario debe tener el password, por lo tanto el password seguramente está regado en varias tablas de la base de datos... obviamente, la respuesta era que sí. Vi algunas tablas de la base de datos y muchas tenían un campo "password" que era la llave foránea hacia usuario. Bueno, al menos estaba encriptado... pobremente... Mi siguiente pregunta: el usuario entonces NO puede cambiar su password, verdad? Pero ellos pensaron que eso era algo importante, el usuario debe de poder cambiar su password, digo, hay que pensar en la seguridad, no? y cómo le hacen, si es la llave primaria? Ah pues muy fácil! Tenían un objeto con un método al que le pasaban el usuario y el nuevo password. De entrada, si el password que querían usar ya estaba en uso por otro usuario, les avisaba y entonces al usuario le salía un mensaje de que no podían cambiar a ese passsword porque estaba en uso por otro usuario (nomás faltaba que les dijera quién!!!). Pero si no estaba en uso por nadie, entonces insertaban un nuevo usuario con un nombre temporal y el nuevo password, y luego iban a hacer updates a todas las tablas que hacian referencia a usuario, poniendoles el nuevo password a los registros que tenian el password anterior, para que apunten al nuevo registro... finalmente, se copiaban ya los datos restantes (como el username, que también tenía una restricción de UNIQUE) al nuevo registro, y se borraba el registro anterior (liberando así ese password viejo para que alguien más lo pudiera usar despues). Ya nada más pregunté qué hacían cuando había que agregar una nueva tabla al sistema, que hiciera referencia al usuario... fácil! nada más se tienen que acordar de modificar ese procedimiento para que se actualizara también la nueva tabla. Y si quitaban una tabla? lo mismo. Ya en broma les dije que por qué no hacían un stored procedure o algo que revisara todas las tablas de la base de datos y cuando se encontrara una que tuviera una columna "password" la tomara en cuenta para el cambio de password... y les pareció muy buena idea! Antes de que fueran a implementar ese esperpento de Stored Procedure, me puse a explicarles lo más tranquilamente que pude (que a esas alturas fue a gritos, pero al menos mantuve los insultos a un mínimo), que en todo caso deberían usar el username como llave primaria, no el password... el password debe estar en un solo lugar, no regado por toda la base de datos, aunque esté encriptado. Y el username ya no tienen por qué cambiarlo, así se queda y punto. Y no importa si todos los usuarios deciden usar como password "password"; están en su derecho. Pero si alguien ve la base de datos, todos los passwords deben verse encriptados distinto, aunque sean el mismo. 2. NPE en vez de if Un programador con el que trabajé (brevemente, cabe mencionar) que tenía que hacer un programita para migrar unos datos, tenía que leer algunos registros de una tabla y si existían registros relacionados en otra tabla, actualizar unas cosas, si no existía el registro relacionado, crear otra. Fácil, no? Una llamada a un método para obtener el registro en cuestión, y luego: if (objeto == null) { /*hacer una cosa*/ } else { /* hacer otra cosa */} cierto? Pues no... este cuate tuvo la brillante idea de obtener el objeto, y luego poner un try-catch de NullPointerException. En el try ponía todo el código que tenía que ejecutarse si el objeto existía, y en el catch estaba todo el código que se tenía que ejecutar si el objeto no existía. Algo asi: try { objeto.hazAlgo(); objeto.hazOtraCosa(); /*etc*/ } catch (NullPointerException) { objeto=new Cosa(); /*y luego repetir mucho de lo que venía en el try*/ } Fue una larga discusión, para convencerlo de que NO era lo mismo, uno por performance, otro porque había tanto código en el try, que bien se podía causar una NPE por otra cosa que no fuera la primera línea dentro del try, y entonces se iba a ejecutar código que no tenía por qué correr... y finalmente por qué carajos alguien va a usar un try-catch en vez de un if? NOOOOOO!!!!!! Lo peor es que había más de 20 bloques iguales en su código. Y se quejó amargamente de que tendría que cambiarlos todos. Tiempo después cuando vi Hostel me identifiqué con las víctimas porque recordé el día que vi este diseño de base de datos, y lo del NPE, y me sentí igual. Hubieran podido pasar a un programador o DBA encadenado y luego entra un equipo de programadores maletas a decirle las super ideas que tienen para el sistema usando el password como llave primaria y cómo el try-catch es lo mismo que un if (x == null) {} else {}.

Seguro que en tu día a día profesional, el contacto con otros compañeros informáticos, o la lectura de documentación, libros, webs, etc..., supone un conocimiento de una parte de la historia de la Informàtica, una historia que hayaís vivido, una anécdota que conozcais, una leyenda que escenifique una realidad de nuestra profesión etc.. Seymour Cray y los Apple MAC En cierta ocasión (final de los 90's), le preguntaron al CEO de CRAY (fabricante de supercomputadores) acerca de su opinión sobre la noticia de que el último modelo de Apple MAC fue diseñado con un CRAY. El respondió que le parecia estupendo, pues su último modelo de CRAY lo había diseñado con un MAC. Razón no le faltaba, solo que unos aprovecharon el CRAY para simular la arquitectura, y los otros para diseñar la carcasa. Bug El término "BUG" (error en un programa informático) apareció por primera vez en 1945. La Investigadora Grace Murray Hopper trabajaba como programadora en el laboratorio de cálculo de la Universidad de Harvard y cuando trataba de averiguar la causa de un fallo de un ordenador, descubrió que era debido a una polilla que se había introducido entre los contactos de unos de los relés del computador, por lo que anotó en el cuaderno de incidencias "First actual case of bug being found" ( en español: "Primer caso real de bicho que se ha hallado". De ahí el nombre de "bug". Poco despues, cuando algunos programadores se encontraban con problemas, la primera explicación que daban era la de asignar las culpas a una posible polilla (bug). De aquí que poco a poco se fue consolidando la expresión en el sentido que actualmente le damos en nuestra profesión. El Instituto de Informática Allá por el 1969, y aprovechando la reforma educativa del Ministro Villar Palasí, a la sazón Ministro de Educación y Ciencia (vaya una coincidencia de nombre pues es el mismo que tiene en 2006 el mismo ministerio) por Decreto, se creó el Instituto de Informática, el primer centro de formación en Informática. Este centro, inicialmente no dependia de ninguna universidad, sino de un Patronato presidido por el Subsecretario del Ministerio de Educación y Ciencia, siendo el primero D. Alberto Monreal Luque que luego fué Ministro de Hacienda. Este Instituto de Informática en pocos años se transformó en Facultad de Informática y después de una lucha entre catedráticos de la UPM y de la UCM se incorporó a la Universidad Politécnica de madrid. Su transformación en Facultad acabó con el experimento de un original plan de estudios que atendía directamente las necesidades del mercado de entonces y no los intereses de la Universidad Creación de Fortran Cuenta la leyenda, que en los inicios de la Informàtica, cunado no existían objetivos de paridad en los puestos de trabajo y practicamente todos los informàticos eran hombres en un entorno social que hoy nos parecería extraño, al darse cuenta que para programar los científicos necesitaban un lenguaje de programación de alto nivel, se reunieron en un piso de Nueva York las mentes más avanzadas en computación para definir un nuevo lenguaje de programación: Fortran ! Teóricamente no se debían alargar demanasiado en definirlo, sin embargo al tener en la ventana de delante del piso donde se encerraron para trabajar una venina atractiva que se les mostraba de manera atrayente, los sabios, que asistieron en mente alma y ... cuerpo, decidieron tomarse todo el tiempo necesario para definir el lenguaje ... hasta que alguno de ellos habló más de la cuenta, con lo que se decidió que acabarn su trabajo en un campus universitario, lo cual hicieron con sorprendente agilidad. Así que si eres programador de Fortran y discrepas sobre su gramática o te molesta alguno de sus inconvenientes, ya sabes de donde puede provenir su origen ... Cookie El origen de la palabra 'cookie' -galleta- asociada a la navegación por internet está sujeto a interpretaciones varias. Recurriendo al imaginario infantil, hay quien dice que está inspirado en el popular Mónstruo de las Galletas -Cookie Monster- de Barrio Sésamo. Otras fuentes citan las migas de pan que soltaban Hansel y Gretel para marcar su camino de regreso. Teorías más prosaicas son las que hacen referencia a la supuesta existencia de galletas que contenían LSD o a las bombas -'cookies'- que soltaban los pilotos de aviación norteamericanos durante la guerra. La interpretación más aceptada se remite al artículo escrito por Paul Bonner en 1997 y publicado en Builder.com En esta colaboración, Bonner hacía referencia a las especificaciones desarrolladas por Lou Montulli para el uso de 'cookies' en el navegador de internet Netscape Navigator, que en aquel momento era el más extendido. Según Montulli, la elección de la palabra 'cookie' no tuvo ningún tipo de inspiración particular. Y si aprieto la F Bueno, yo voy a colaborar tambien con una pequeña anecdota, pero en lugar de escribirla aqui, dejo el enlace ya que la he puesto en mi blog. http://www.ati.es/blog/index.php?op=ViewArticle&articleId=24&blogId=2 Primera huega de internautas El 26 de enero de 1997 tuvo lugar la primera huega de internautas en España. Este incipiente y cada vez mayor colectivo protestaba por el elevado coste de las tarifas de conexión a Internet y solicitaba el establecimiento de tarifas planas. A lo largo de todo el dia dejaron de conectarse a la red. Lo importante de las copias de seguridad Un dia, un servidor aquí presente, se dirigió a casa de un cliente que tenía problemas con el softare instalado. Era a finales de los 80, la contabilidad estaba escrita en Basic, era el mundo del DOS, windows no existía y los discos eran de 10Mb. Al comentarle que era posible que los índices de acceso a la contabilidad estuvieran dañados pregunté al "operador" si tenían copia de seguridad. "Claro que sí", añadió. "La hacemos todos los viernes" y para demostrármelo se fue a buscar la copia. Cual sería mi sorpresa cuando, al volver, el operador me enseño el balance y los movimientos contables...en papel pautado! cosas de la historia Diskette de 5 1/4 Sumergible En uno de mis primeros trabajos, cuando los pc's y la ofimática empezaba a despuntar, cuando los discos duros no superaban los 20 Mb y lo de internet era ciencia ficción , primeros de los 80.A un compañero se le cayo un disco en un charco, todos los que estabamos allí pensamos, que todo el trabajo se había perdido... pero resulto que no, que los datos estaban ahí perfectamente no habian sufrido daño alguno. Efectivamente los diskettes de 5 1/4 erán magnéticos y por que no también sumergibles. Saludos desde Costa Rica muchachos...gracias por visitar mi post... Aca mas de mis posts Leyendas Urbanas de la Informatica Linux, Toda una Religion Historias de Horror en Programacion Programas 2009 en descarga directa MacOs en tu PC Intel, No es un sueño Programas poco comunes muy utiles Top Ten Programas Libres Las computadoras en las peliculas (Curiosidades) Se nos va winXP

link: http://www.videos-star.com/watch.php?video=64JQ44oX2xc Para el experto en seguridad informática Charlie Miller fue extremadamente sencillo hackear una Macintosh. El procedimiento le tomó sólo 10 segundos y el premio fue de 5.000 dólares. Charlie Miller, quien ha ganado renombre en el mundo de Macintosh al haber hackeado en 2008 una MacBook Air en menos de dos minutos, logró el miércoles 18 de marzo la proeza de hackear una Mac en menos de 10 segundos, batiendo así su propio récord personal. El concurso es denominado Pwn2own y es organizado cada año en el marco de la conferencia de seguridad Cansecwest. Un requisito mínimo de concurso es ejecutar código en el sistema intervenido. Este año, Cansecwest se ha concentrado en el tema de los iPhone y los navegadores. Hace dos semanas, Miller declaró que Safari sería sin duda alguna el navegador más fácil de vulnerar. Explicó que el alto nivel técnico y numerosas funciones de Safari implican que éste tiene un gran potencial para vulnerabilidades, que los desarrolladores sencillamente han olvidado corregir. "No puedo comentar los detalles de la vulnerabilidades, pero se trata de una Macintosh con las últimas actualizaciones de seguridad. Me tomó entre 5 y 10 segundos hackearla", comentó Miller. Los hackers participantes no tuvieron problema alguno en intervenir los navegadores Firefox y Explorer 8, además de Windows 7. Sin embargo, ninguno logró intervenir los sistemas de teléfonos móviles, incluido el iPhone. El premio por un hack de ese tipo habría sido el doble. Los detalles de los hacks fueron proporcionados a las empresas desarrolladora de los software, para su análisis y corrección. Según Miller, su hack fue posible aprovechando una vulnerabilidad que detectó durante el concurso del año pasado. Aja...para los que creian que Peluchin habia vuelto a sus andadas pss no, se equivocan... Saludos chicos, y visiten mis posts Leyendas Urbanas de la Informatica Linux, Toda una Religion Historias de Horror en Programacion Programas 2009 en descarga directa MacOs en tu PC Intel, No es un sueño Programas poco comunes muy utiles Top Ten Programas Libres Las computadoras en las peliculas (Curiosidades) Se nos va winXP

Anecdotas de un Programador Yo si soy tonto! Recuerdo cuando empecé a trabajar, picando código y aprendiendo a programar, tenía unos "jefes" realmente curiosos. Para que quedara claro que eran jefes, se solían quedar ellos lo mejor, dejándonos a nosostros, los nuevos, las sobras. ¿Que llegaba material nuevo?, rápidamente se lo agenciaban ellos, se agenciaban los nuevos monitores, o se agenciaban los pen-drives, o las libretas más "molonas", o los "pilot" y a nosotros nos llegaban sus sobras, sus ordenadores viejos, sus monitores viejos, nos quedábamos sin pen-drives y nos tocaban los "bic". Ahora he "ascendido" un poquito, pero aun recuerdo aquellos tiempos. Hace unas semanas pedí pen-drives para repartir y efectivamente, los repartí: ¡¡ todos para la gente más nueva !!. Yo sigo con mi viejo pen-drive de 2 Gigas y no me he quedado ninguno de los nuevos. Es más, a los que son "jefecillos" como yo, tampoco les he dado pen-drives, aunque algunos me lo reclamaro. Les dije algo así como "a los jefes, ni agua" y se quedaron sin ellos. Total, que toda la gente nueva anda con pen-drives nuevos y yo ando con la sensación de ser tonto … Un Par de Cosilla Un par de cosillas que aunque no son muy de programación, ahí van. La primera es una pequeña anécdota que me ha pasado hoy. Pregunté a mi compañero cómo se hacía "no sé qué" con log4j, que estaba seguro de que se podía hacer, pero no recordaba cómo. El tampoco sabía, así que miró en google, encontró cómo y me mando un corredo diciendo "me engañas, sí que sabes cómo se hace" y un enlace … ¡ a mi propia página de log4j en la Chuwiki !. Creo que me estoy haciendo mayor y no sólo la mano izquierda no sabe lo que hace la derecha, sino que además no se acuerda. La otra es sobre un compañero de trabajo, que ha hecho un sitio web sobre venta de pastores alemanes y cahorros. Aunque es fan de las herramientas de Microsoft, casi le tengo convencido para que la haga con PHP y CSS. Por cierto, si alguien visita la página y se decide a comprar un perro, que le diga que va de mi parte, que me llevo comisión ; - ) Maravilloso Codigo Es increible, pero cierto. Hoy un compañero mío, revisando código, se ha encontrado algo como esto public byte[] getBytes (int valor) { byte [] a = new byte[1]; switch (valor) { case 0: a[0]=(byte)0; break; case 1: a[0]=(byte)1; break; case 2: a[0]=(byte)2; break; …. case 15: a[0]=(byte)15; break; default: a[0] = (byte)0; } return a; } Menos mal que sólo eran 16 valores. ¿Al menos se la habrá ocurrido usar el copy-paste? Los moviles no tienen CTRL + C Ayer me puse a hacer un pequeño jueguecito para el móvil, como siempre, no por el juego, sino para aprender cosas nuevas, en este caso algo de J2ME. Un cuatro en raya. Hago una primera "cosa" para dibujar el tablero y poder colocar las piezas, genero el jar correspondiente y lo pongo en el móvil. Juego un poquito con esa pequeña chorrada y todo va estupendo…. hasta que quiero dejar el juego. ¡¡ Vaya por Dios !!. No he puesto un botón de salir y el móvil no tiene Ctrl-C. La única forma que encontrado de salir de mi juego es apagar el móvil. Objetivo conseguido, he aprendido una cosa nueva: En los móviles es imprescindible poner un botón de Salir. Saludos chicos espero que les haya gustado... Y recuerden Visitar mis otros posts... Peliculas para programadores Un Cuento de Programacion...(erase una vez) Leyendas Urbanas de la Informatica Linux, Toda una Religion Historias de Horror en Programacion Programas 2009 en descarga directa MacOs en tu PC Intel, No es un sueño Programas poco comunes muy utiles Top Ten Programas Libres Las computadoras en las peliculas (Curiosidades) Se nos va winXP Solo para informaticos Actualiza tu WinXP Offline Pack Programas 2009 Descarga Directa

Despues de algun tiempo en este complicado pero apasionante mundo tenencuentras todo tipo de cosas, desde obras de arte, hasta cosas tan descabelladas que realmente te preguntas que clase de bastardo escrinio dicho codigo... Sin duda nos hemos encontrado algun dia con algo asi, asi que si sos programador te identificaras con algunas de los siguientes casos... Y si tenes uno propio agregalo... # Comentarios que explican el “como” y no el “qué”. Lo que me han metido hasta la saciedad este año en la cabeza es la costumbre de documentar correctamente los apartados o métodos adecuadamente explicando todo lo que en un futuro no podamos entender y procurando hacérselo comprender a otras personas. Hay programadores que más que creen que los comentarios se utilizan para poner el pseudocódigo, vamos prácticamente repiten la información que te da el propio código. El siguiente ejemplo es revelador: r = n / 2; //Igualamos r a n dividido por 2 //Se repite mientras r – (n/r) sea mayor que t while ( abs( r – (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); //Igualamos r a la mitad de r + (n/r) } Las interrupciones. Todos los desarrolladores sabemos cuando estás totalmente enfrascado en el código un momento de distracción puede eliminar todos los pensamientos que tenías en tu cabeza, con el consecuente problema de tener que volver a “conectarte” después de una interrupción. Las causas suelen ser llamadas, mensajes o Messenger en su defecto, jefes o compañeros con su aliento en tu nuca preguntándote por la resolución de un método o metiéndote caña con los plazos de entrega (menos si trabajas en Microsoft, parece ser) y otras de la misma índole. Ampliación del ámbito. Que casualmente se suele dar durante el desarrollo de la aplicación. Esto significa que en un principio te asignan un problema sencillo de unas “pocas líneas” y a medida que pasa el tiempo y la fecha de entrega se acerca aumenta considerablemente la dificultad del problema porque resulta que ahora los analizadores y el cliente deciden que sería mejor si… Como ejemplo nada mejor que el del post original: Versión 1: Mostrar un mapa de geolocalización Fácil, cojo un mapa de por ahí y unas pocas líneas de código y a otra cosa mariposa Versión 2: Mostrar un mapa 3D de localización Madre del verbo bendito, qué bien se lo pasan tocando las narices a uno, ahora hay que currarse más el diseño y con suerte encontrarlo, cogerlo y adaptarlo de código ya existente Versión 3: Mostrar un mapa 3D de localización, por el que el usuario pueda desplazarse volando WTF! Gestores que no entienden de programación. Qué bien, el desarrollador el último otra vez, la incapacidad de los gestores muchas veces supone un problema terrible para el desarrollador, como no. Documentación. Además del código el programador debe crear documentación que suele incluir documentación para el usuario final y documentación delpropio programa en algunos casos. # Aplicaciones, métodos o clases sin documentación. Es bastante frustrante tener que implementar una API que tenga una documentación prácticamente nula dejándonos el método de “A ver qué pasa si ejecuto este método” como única solución. Hardware. Los errores de hardware son realmente complicados de detectar y conllevan el cabreo del usuario final, pensando éste que el principal problema está en que la aplicación está mal desarrollada. Imprecisiones. Irritante como lo que más es la imprecisión tanto en el nivel de usuario como en el de desarrollo y diseño, cosas que se deberían pulir realmente y que suelen venir desde fases anteriores que suelen ser más abstractas. Otros programadores. Choques de personalidad, problemas de comprensión, falta de habilidad en la comunicación, falta de iniciativa, apatía hacia el código o el proyecto… Tu propio código 6 meses después. Cuando seis meses después intentas reciclar tu propio código es cuando te preguntas si realmente eres tan malo documentando como los demás. Al fin y al cabo todos somos parecidos y todos cometemos errores. Saludos desde Costa Rica y visiten mis otros post.

¿Existe una barrera infranqueable entre los programadores y el común de los mortales? ¿Qué factores contribuyen a que no nos entiendan? Tengo un buen amigo que tiene un sitio web. Cuando quiere hacer algún cambio llama al “hechicero”, así es como denomina el a su programador; dice que el hechicero le da unos pases mágicos al site y ¡zas! todo funciona. A veces la web se “cae”, aunque no suele haber nadie recogiéndola, en ocasiones se “rompe”, y otras veces simplemente “apache anda con el período”. Este es el primer motivo por el cual la gente odia a los programadores: la incertidumbre. A la gente le gusta que el futuro sea predecible. Obviamente no lo es. Pero les gusta pensar que existe alguna esperanza de que lo sea. Los mejores programadores son reductores natos de la incertidumbre. Cogen un proceso de negocio mal definido, que nadie sabe muy bien cómo funciona ni qué calidad tiene o que resultados produce. Analizan dicho proceso, lo automatizan, y lo convierten en algo eficiente, repetible, medible y fiable. La incertidumbre tiene que ver con los plazos y con la fiabilidad. Los programadores a menudo denominan una “beta” a algo que falla más que una escopeta de feria. Sus sistemas son “escalables” hasta que les entran 1 millón de consultas simultáneas y se va todo directamente a la Chuña. En el PC del programador siempre funciona todo, pero tan pronto como sacas el programa y lo instalas en otro lado las malditas librerías/paquetes “de terceros” lo fastidian todo. El segundo factor por el cual los programadores tienen tan pocos amigos es la arrogancia. La mayoría de los programadores consideran a los usuarios como una especie de subhumanos. Yo creo que el programador medio consideraría de veras la opción de suicidarse si en un proceso al estilo de la Metamorfosis de Kafka un día empezase a convertirse lenta e inexorablemente en un técnico de marketing o de recursos humanos. Un efecto secundario de la arrogancia es la tendencia crónica a subestimar el esfuerzo requerido para hacer las cosas. Aunque hay que reconocer que aunque se estime correctamente, siempre acaba llegando el jefecillo de turno y cortando los plazos a la mitad, con lo cual el resultado final es el mismo. La arrogancia suele ir acompañada de una falta total de empatía y de sensibilidad sobre las reacciones emocionales que el software produce en los usuarios. Vale que la mayoría de las personas (usuarios o no) no son precisamente muy hábiles reconociendo y controlando sus emociones, pero en el caso de los programadores se junta el hambre con la gana de comer. En tercer lugar, el informático medio es un tipo de ingeniero terriblemente poco riguroso y chancao (chapucero). Hay unos pocos profesionales serios, pero a la mayoría les pillas en un bug gordo a los 2 minutos de leerte su código. Muy pocos programadores tienen una conciencia clara de lo que significan cosas como resilencia y mucho menos usabilidad. Siempre ha existido cierto conflicto entre los matemáticos puros, amantes del rigor, y el resto de los científicos como los físicos, más prestos a desarrollar un modelo experimental primero y cuadrar las matemáticas a martillazos después. Pero en ninguna rama ingenieril existen probablemente tanta tendencia a lo chancao (bueno, en la construcción de las casas hay aún más, pero esto mejor ni pensarlo porque se echa uno a llorar). Por último, existe ese regustillo marginal en el vestir. Escenificado en llevar poleras negras de alguna distro, o algo peor. Los más creativos son raros, y a menudo desaliñados, pero al menos normalmente estilosos. El programador típico podría trabajar de extra en una peli de bajo presupuesto y nadie notaría que no ha pasado por vestuario. Gracias por visitar mis posts! y Saludos desde Costa Rica