• Del autor
  • Principios y algoritmos de concurrencia

Ricardo Galli, de software

~ De software libre, internet, legales

Ricardo Galli, de software

Publicaciones de la categoría: desarrollo

Un actor útil y eficiente en Go

03 miércoles Ago 2016

Posted by gallir in concurrencia, desarrollo, programación

≈ Comentarios desactivados en Un actor útil y eficiente en Go

Etiquetas

actor, actores, golang

Este es un truco en Go muy útil y eficiente para hacer tareas de «mantenimiento» en estructuras de forma concurrente (y seguramente paralela).

Supongamos que tenéis una lista de elementos, a esta lista se agregan u obtienen elementos pero hay que mantener solamente los últimos N, donde N puede estar basado en una límite temporal.

Las operaciones sobre la lista deben responder muy rápidamente por lo que no es posible llamar a la función que elimina los más antiguos porque tiene un coste computacional (O(n) o O(log n) en el mejor de los casos) que retrasaría la respuesta.

Hay dos técnicas muy habituales en Go:

  1. Lanzar al principio una goroutine que periódicamente se ejecute después de una espera con time.Sleep() o usar el time.Ticker que ya hace ambas cosas. El problema con esta solución es que se ejecuta y consume CPU aunque no haya actividad.
  2. Lanzar la goroutine cada vez que hay actividad, por ejemplo al agregar u obtener elementos de la lista. El problema, además del pequeño overhead de lanzar la goroutine, es que si hay muchas operaciones se creará un número idénticos de goroutines y seguramente cada una de ellas tendrá que esperar que la otra acabe (se necesitan mutex, la estructura es compartida entre varios hilos de ejecución) y el trabajo se estará haciendo trabajo de más sin ninguna utilidad.

Una tercera forma muy eficiente, algunos le llaman actor (por el modelo de actores). Como en el caso 1 anterior, se lanza una goroutine -el actor– cuando se crea la estructura (o la interfaz), esta rutina sólo espera recibir un mensaje de un canal específico para ella. Cuando recibe un mensaje hace su trabajo y vuelve a esperar por uno nuevo.

Sigue leyendo →

El mejor consejo que puedo dar a un joven ingeniero

24 jueves Mar 2016

Posted by gallir in desarrollo, personal, programación

≈ 14 comentarios

Etiquetas

consejos, programación

En unos meses cumplo 25 años desde que presenté mi proyecto final de carrera de Ingeniería en Informática («la tesis» le llamaban en mi universidad) y algo más de 15 desde que leí mi tesis doctoral. Llevo años pensando en escribir sobre cuál fue el mayor error de mi carrera profesional y curiosamente -o no- me parece el mejor consejo -doble- que puedo dar, no hacer lo mismo:

No te adelantes, no te dejes seducir por puestos de dirección, gestión o representación. Durante los primeros 20 años de carrera sólo preocúpate de aprender y practicar para ser un experto de élite en el área en que estás trabajando. Cuando la domines creerás que lo sabes todo pero en realidad no sabes nada, aprende una nueva y repite el proceso: ganarás tanta humildad como conocimiento.

Ya llegará el momento -si lo deseas- de ocupar cargos de dirección o gestión, cuando seas un profesional reconocido: tendrás ya mucha experiencia en proyectos, sabrás bastante de la psicología y sus problemas sociales, tomarás mejores decisiones y serás de ayuda -que no un gestor molesto- y la gente a tu cargo te respetará y confiará desde el primer día. Afortunadamente con el dominio del software en tantas áreas se puede vivir bien como un buen ingeniero con experiencia. Además -desafortunadamente- es muy difícil encontrar ingenieros de alta calidad y con conocimientos en diferentes áreas.

No puedo dejar de poner otros que aprendí con errores que ahora intento no volver a cometer:

  1. Cuando trabajes en grupo, sobre todo si estáis intentando solucionar un problema, no eches la culpa de nada a tus compañeros, déjales que se equivoquen -es parte de la búsqueda-, colabora y asume las responsabilidades aunque no hayan sido tuyas.
  2. Por el contrario, si alguien nunca asume una responsabilidad o error, o culpabiliza a otros hasta de que no le dejan hacer nada, intenta que quede fuera del equipo. O que al menos no moleste.
  3. Participarás en proyectos interesantes y en otros que son marrones. En realidad todos pueden ser interesantes, depende de la actitud con que los encares: siempre hay cosas que mejorar y aplicar ideas creativas. Tengo el ejemplo reciente de un compañero que le tocó uno de esos proyectos marrones hasta que se dio cuenta que podía reducir los tiempos de ejecución de batches con threads concurrentes, se lo pasó pipa aprendiendo y practicando. No sólo le quedó un programa mucho más rápido y eficiente,  ahora él es un profesional mucho más formado y capaz que hace un par de meses.
  4. Puedes ser un doctor o un graduado en el MIT, pero a la hora de verdad tu compañero autodidacta y tú ejercéis de ingenieros. Trátalo como tal, los títulos formales solo sirven como carné de autoridad para la universidad ;), entre colegas no cuentan, solo lo que has demostrado saber hacer.
  5. Lee mucho código de terceros, fundamentalmente de las librerías, módulos y programas que usas habitualmente. Es una de las mejores formas de aprender.
  6. No dejes de leer, no solo de libros técnicos específicos, también de historia de la informática y ciencia, un poco de filosofía y psicología, álgebra, estadística y algo de cálculo.
  7. No te contentes con dominar una herramienta o lenguaje, aprende cómo funciona toda la pila que lo sustenta: el hardware, el sistema operativo, la máquina virtual o compilador, el API, las librerías, etc. Aprende C o ensamblador, son clarificadores de cómo funcionan las máquinas y todo lo que hay por encima.
  8. Domina al menos tres lenguajes diferentes que cubran: compilados, dinámicos, y funcionales.
  9. Tus programas nunca serán perfectos ni lo suficientemente buenos. Con el paso de los años te avergonzarás de tu propio código. Esto es bueno, has mejorado.
  10. Cuando programes piensa en los lectores de ese programa: escribe y comenta en inglés, que el código sea elegante, si el código te parece espagueti o ilegible descártalo y empieza de nuevo, no dejes de refactorizar mientras programas. No tengas miedo de descartar programas, no es tiempo perdido. Programar es como escribir un libro pero más complejo, si hasta los mejores autores siempre descartan capítulos o textos completos, ¿por qué tú habrías de acertar a la primera?
  11. No empieces a programar como un mono, pasa horas pensando, camina, conversa con colegas, pregunta, haz un prototipo, descártalo y vuelve a empezar hasta que esas primeras líneas no te den asco ni te generen desasosiego por lo que se viene: todo lo contrario, deberían entusiasmarte a seguir programando.
  12. De todas las ideas o propuestas, elige siempre la opción más sencilla (el KISS). Si no hay ninguna que sea claramente sencilla es porque falta pensar más. Si durante el desarrollo te das cuenta que hay soluciones más simples para hacer lo mismo (es muy habitual), descarta y comienza de nuevo.
  13. No hagas optimizaciones prematuras ni tampoco diseño de lo desconocido. Lo primero genera código más difícil de verificar y lo segundo complica el sistema con funcionalidades que nunca se usarán.
  14. Si cuando sale una nueva tecnología eres capaz de darte cuenta en qué podría servirte pero te ríes del hype y buzzwords es señal de que estás madurando como profesional.
  15. Si además de acabar tus proyectos en tiempos razonables y con programas fiables, los haces con buen humor, te acaban ilusionando hasta los más coñazos y festejas como un crío cuando pudiste solucionar una tontería que te tomó horas, ya eres un buen profesional. O al menos no un coñazo de profesional. Que es casi lo mismo.

PS: Ahora veo que me falta algo fundamental, siempre explica a tus colegas por qué haces algo o tomas una decisión. En el código o tomando un café.

 

Miles de apps en los móviles: mitos, realidades y las preguntas claves

04 sábado Abr 2015

Posted by gallir in desarrollo, empresas, internet, medios

≈ 8 comentarios

Etiquetas

apps, apps vs web, web

Ayer hice una búsqueda y el primer resultado que me salió fue una página de Linkedin, al ir a ella un aviso en pantalla completa para que instale su app. ¡Cielos! yo sólo quería saber una información muy concreta y que no necesitaba más de unos pocos segundos de lectura. Además esa misma información está disponible en miles de sitios, que haya entrado a Linkedin fue puro accidente. Tengo cuenta en Linkedin desde hace años pero no la uso habitualmente ni tengo la intención de hacerlo: no soy un buscatalentos, no busco ni ofrezco trabajo habitualmente. No tengo intenciones ni ganas de instalar su app en mi teléfono, pero ¿por qué insisten?

Los mitos de las apps

No es nada nuevo ni soy original en lo que voy a comentar. Sin embargo me sigue sorprendiendo la molesta insistencia de muchos sitios web a que sus lectores esporádicos o accidentales instalen una nueva app en su móvil. Los que diseñan o deciden estas estrategias parecen asumir los varios de los siguientes supuestos falsos:

Sigue leyendo →

Las elecciones de Podemos, voto electrónico, y AgoraVoting (y 2)

04 martes Nov 2014

Posted by gallir in desarrollo, programación

≈ 16 comentarios

Etiquetas

agoravoting, podemos, seguridad, voto electónico

Hace unos días escribí un apunte sobre las tan comentadas elecciones electrónicas de Podemos. Comencé el artículo con una descripción de los requisitos que tiene que tener un sistema de votación (de papeleta y electrónico) y el procedimiento que se seguía en las votaciones tradicionales para asegurar que se cumplan esos requisitos (voto secreto y anónimo, no adulteración, impedir agregar votos, auditoría…).

En ese apunte me limité a comentar el problema del censo de Podemos, y cómo sólo eso hacía que se incumpliesen varios de los requisitos mencionados anteriormente. Aquí introduzco un leve paréntesis para dejar claras algunas cosas (lo pongo «entrecomillado» para que te lo puedas saltar).

Sigue leyendo →

El voto electrónico y las elecciones de Podemos

30 jueves Oct 2014

Posted by gallir in desarrollo

≈ 49 comentarios

Etiquetas

e-vote, podemos, voto electrónico

Hace pocos días los simpatizantes de Podemos votaron las propuestas organizativas del partido, se habló bastante de ello. Pero el tema del voto electrónico se tomó con mucha superficialidad e incluso hype que estaba muy lejos de la realidad.

Antes de entrar al tema dejadme hacer una introducción breve [pero incompleta] de los requisitos de sistemas de votación en sistemas democráticos. Tened en cuenta que el 100% de seguridad o el 0% de error es una meta imposible, lo que se intenta es tener un sistema lo más preciso y fiable posible, donde los errores se minimicen y que estos se distribuyan proporcionalmente entre las diferentes opciones, así se asegura que afecten lo mínimo posible (con porcentajes muy bajos, menores al 1%) al resultado final. Aún en caso de que haya dudas estas se resuelvan con normas claras y definidas antes de la elección (incluso vale con tirar la moneda).

Sigue leyendo →

Ciencias de la computación e ingeniería, y [algunas de] sus diferencias

07 martes Oct 2014

Posted by gallir in ciencia, desarrollo, programación

≈ 17 comentarios

Etiquetas

concurrencia, exlcusión mutua

Hay un tema que se estudia en todas las carreras de informática, el de «sincronización, concurrencia y exclusión mutua entre procesos». Surgió en la década de 1950 cuando empezaron a desarrollarse los primeros sistemas con multiprogramación. Aunque surgió como problemática de sistemas operativos se ha convertido en un tema de general y fundamental en informática. Todas las carreras de informática incluyen su estudio tanto en las asignaturas de sistemas operativos como en otras específicas de programación concurrente.

El tema de concurrencia (y su hermano más complejo «programación distribuida») es un típico tema de «ciencias de la computación», donde se estudian los algoritmos y se prueban formalmente que funcionan: se demuestra que aseguran exclusión mutua, que no produce inanición (starvation), ni interbloqueos (deadlocks). No es simple enseñar estos temas y sus soluciones obligan a pensar de otro manera, un programa ya no es una serie secuencial de instrucciones, sino que se mete por medio una intercalación «no controlada» y no determinística de otras instrucciones de procesos independientes.

El tema de exclusión mutua es un tema relativamente sencillo de demostrar, por ejemplo este código que suma una variable desde cero hasta 99.999.999 (cien millones menos uno), pero no lo hace de una forma tradicional, sino que son dos hilos (threads) los que la incrementan individualmente. Podéis compilarlo y probarlo (no olvidéis de compilarlo con la opción -pthread), veréis que produce unos errores enormes. El problema es que dos procesos diferentes acceden al mismo recurso compartido (la variable count) y se «pierden» operaciones debido a las interrupciones e intercalaciones.

Este caso es muy estudiado y todas las asignaturas comienzan con algo similar, es la exclusión mutua entre [solo] dos procesos. Así se estudian los «cuatro intentos» para solucionarlo, luego el algoritmo de Dekker y finalmente el de Peterson (aquí los tenéis a todos).

Así se puede demostrar formalmente que funciona correctamente, que asegura exclusión mutua y tal y cual. Pero si lo implementas (aquí lo tenéis listo para compilar y ejecutar con el ejemplo anterior) y lo pruebas en cualquier ordenador moderno verás que… falla como escopeta de feria.

¿Qué pasó? ¿Falla la teoría? ¿Fallan las demostraciones? ¿Los teóricos de las ciencias de la computación no sirven para nada?

Actualización: la respuesta.

Ninguna de ellas, este es un típico ejemplo donde la teoría se distanció de la «realidad», o mejor dicho, donde la evolución tecnológica de los microprocesadores modernos hace que las técnicas de concurrencia que dábamos por buenas (y que lo son formalmente y con todos los modelos de computación y/o de lenguajes «tradicionales») ya no funcionen. Es la diferencia entre hacer «sólo ciencia» y la «ingeniería» (es decir, resolver problemas que te impone la realidad, no tan perfecta como la teoría).

Tampoco es para los ingenieros se feliciten y miren por encima del hombro a los teóricos, porque la mayoría de «ingenieros» tampoco saben explicar o resolver este problema, muchas veces ni siquiera son capaces de identificarlo (no, si estás leyendo este blog no eres de la «media», eres bastante friki y al menos lo habrás oído, o sabrás buscar rápidamente en la Wikipedia o Stackoverflow 😉 ).

Si no tienes idea de qué está pasando, ya lo explicaré en un comentario (si nadie lo hace antes), pero mientras tanto puedes ir probando este otro código que sí funciona y sólo difiere en una línea con el anterior.

Sólo quería recordar que aún en ciencias tan «formales» como la informática la teoría no siempre funciona en la práctica, que el tema de concurrencia tiene sus complejidades no siempre a la vista, que un buen ingeniero debe saber reconocer esos problemas y poder solucionarlo, y que esto exige que conozcamos bastante de detalles del hardware y microprocesadores actuales.

No es nada simple, lleva su tiempo, y tendemos a pensar que lo sabemos todo. O que la «ingeniería informática» consiste en saber liderar sprints de Scrums con postits de colores fosforitos.

PS: Por estas cosas, entre muchas, la informática es apasionante.

Tendencias («trends») históricas del uso de palabras con Sphinx

13 jueves Feb 2014

Posted by gallir in desarrollo, menéame, programación, software libre, trucos

≈ 4 comentarios

Etiquetas

menéame trends, sphinx

Hace unos días quise saber desde cuándo se empezó a hablar de desahucios y suicidios en la prensa en España. Fui a Google Trends y el gráfico mostraba una evolución demasiada plana, que no se correspondía con tantas noticias que leímos en la prensa española. Me pregunté si, y cómo, podía obtener esas estadísticas en Menéame. Se me ocurrió que debería haber un truco relativamente sencillo usando los índices de de búsqueda de Sphinx (lo usamos para el buscador de Menéame). Así fue que en pocas horas pude implementar un sistema similar a Google Trends en Menéame.

Esto es lo que salió con las tendencias de esas dos palabras por su frecuencia de aparición por meses:

Evolución de suicidios y deshaucios

Sigue leyendo →

No basta con ser ingeniero (y II), un ejemplo práctico

30 sábado Nov 2013

Posted by gallir in desarrollo, programación

≈ 7 comentarios

Etiquetas

android kitkat, openFileChooser

Hace unos días ya comenté el problema de que eliminaron una función importante en KitKat con la excusa de que no estaba documentada y por lo tanto «no oficial», pero es una limitación seria para millones de usuarios y casi una traición para miles de desarrolladores. Hoy veo el siguiente comentario en el hilo del bug:

You broke file-uploading and released 4.4 without a ready replacement or workaround? O_o

So even if app devs manage to hack around it, they’ll have to maintain the hack forever to support phones stuck on 4.4 even after 4.5+ introduces a proper replacement function?

I need a Kitkat bar.

Es una observación clave.

Una pésima decisión de los ingenieros tendrá consecuencias negativas a largo plazo para desarrolladores, usuarios, y hasta toda la plataforma. No lo meditaron, todavía no se han percatado que las decisiones de ingenieros tienen efectos muy reales sobre las personas. Por eso, para ser un ingeniero hay que ser más que un ingeniero.

De nuevo queda en evidencia que los programadores vamos muy justitos en el tema, incluso para el nivel de programadores del sistema Android. Me genera una mezcla de decepción y cabreo, y me hace admirar cada vez más las «visión social» a largo plazo de Linus Torvalds: literalmente se enfurece cuando alguien le propone cambiar la interfaz (ABI) del kernel Linux que genera incompatibilidades con aplicaciones existentes, aunque tengan más de 10 años. Eso es ser más que un ingeniero.

PS: La única opción para remediar el problema es que parcheen las librerías de Android Kitkat para re-implementar la función openFileChooser() que eliminaron. Otra cosa es que asuman el error y lo hagan. Lo dudo, ojalá esté equivocado.

Android KitKat… ¿pretenden matar el HTML5 en Android?

27 miércoles Nov 2013

Posted by gallir in desarrollo, internet, menéame, programación

≈ 13 comentarios

Etiquetas

android kitkat, chrome, file upload, webview

La pregunta no es tan sensacionalista como parece. Hace unos días me avisaron de problemas para subir fotos a Menéame con Android KitKat. Era muy raro que diese problemas, está todo programado respetando estándares de HTML5 y Javascript. Descubrí que ese caso se debía a problemas de la gestión de memoria de Android y cómo la trataba Chrome (al ejecutar otro programa para seleccionar la imagen, si necesita memoria se la quita al Chrome, por lo que hay un «cambio de configuración», al volver a Chrome, éste recarga la página completa, en vez de «reconstruir» lo que tenía). Pero descubrí otro error aún peor y que sucede siempre: es imposible subir una fotografía. Lo probé con el Nexus 4 y con el 7, en ambos el mismo problema, da un error «fatal» al seleccionar cualquier foto.

Lo probé con el Firefox sobre los mismos dispositivos, y no hubo problemas (además de sorprenderme la velocidad de Firefox, ¡cómo ha mejorado!). Se puede observar el fallo («Error abrir archivo seleccionado» [sic]) en el siguiente vídeo que hice en el Nexus 4:

Visto lo visto, y que no parecía simple de solucionar, además que quería solucionar lo de compartir más fácilmente a Menéame desde un móvil, me decidí a desarrollar una pequeña app:

app Menéame de pruebas

Esta app sólo crea una actividad, basada en WebView, que empotra el renderer HTML. Hasta la versión 4.3 de Android, este renderer era el del «webkit» básico, a partir de 4.4 (KitKat) ya se usa el Chromium (el proyecto libre del Chrome). Todo iba bien, y funcionaba muy rápido… hasta que probé la subida de ficheros: imposible, no funciona en KitKat, y es imposible arreglarla (al menos en teoría y con la información que hay hasta ahora).

Las WebView tienen una pequeña interfaz con unas pocas clases de Java para controlar cosas básicas, y también para que el programa haga algunas de las cosas que no hace la vista por sí misma, por ejemplo, seleccionar ficheros para el <input type=»file»> de HTML. Resulta que no había un API para ello, pero dado que es imprescindible para casi cualquier aplicación HTML5, la gente analizó el código fuente del navegador estándar de Android y encontró la función que se llama cuando se selecciona el campo de subir fichero. La implementé tal cuál, adaptadas a las diferentes versiones de Android:

WbeChromeClient

Pero no funcionaba en KitKat, sólo en las versiones anterior, sin problemas. En KitKat ni se llaman esas funciones, no hace nada cuando se selecciona el campo.

Así fue que busqué, y veo que eliminaron esa interfaz, sin ninguna alternativa. Sólo dicen «no estaba documentada como oficial, y ya pensaremos una alternativa para futuras versiones de Android». En los comentarios queda claro cómo afecta a tantas aplicaciones, sobre todos a las de PhoneGap, que están basadas completamente en HTML5: con KitKat es imposible subir ficheros de apps programadas en HTML5.

Sumado a eso, el propio Chrome de Google también falla para subir imágenes.

Es decir, miles de apps que dejarán de funcionar en Android KitKat, por decisiones [estúpidas] de eliminar la única interfaz posible para poder subir ficheros desde el «navegador empotrado» para apps, y por fallos increíbles en el navegador por defecto, Chrome.

La pregunta es: ¿están perjudicando así a aplicaciones en HTML5 por simple estupidez? ¿O es una estrategia para que se usen apps completamente nativas? No hay otra explicación, en cualquier caso, vaya ceguera y/o ineptitud enorme de los ingenieros que toman decisiones de desarrollo en Android. Para miles de :facepalm:.

PS: Mientras tanto, si tenéis Android KitKat y queréis subir fotos en Menéame o cualquier otro sitio, tenéis que usar Firefox u Opera Mini. Si habéis desarrollado una app que usa WebViews, estáis jodidos, porque no hay otra alternativa, al menos hasta que salga el GeckoView for Android, pero le falta todavía mucho tiempo 😦

Nota: cómo hacer esos vídeos de la pantalla.

Para ser ingeniero no basta con ser ingeniero (y los programadores vamos justitos)

29 martes Oct 2013

Posted by gallir in desarrollo, internet, programación

≈ 50 comentarios

Etiquetas

chapuzas, hangouts, vídeo conferencia

Hace una hora iba conduciendo, llevaba mi teléfono en el bolsillo delantero derecho del pantalón, de golpe empieza a vibrar y sonar. Una vez, dos, tres, cuatro… parecía que llevaba se había desatado una batalla campal entre mis pantalones (y no eran mis tripas ni el Viagra). Me empiezo a asustar, debe ocurrir algo grave para que alguien conocido me esté escribiendo de esa manera, pensé que podía ser problemas de familia o Menéame (que ni aún así insisten tanto).

Detuve el coche en cuanto pude, saqué el teléfono, era el Hangouts (el reemplazo de Google Talk para Android) de Google. Me habían metido en un texto-vídeo hangout con muchas personas (no sé cuántas, pero eran muchas),  todos escribiendo a la vez. Después del susto que me pegué, ¡qué cabreo! Primero con el irresponsable (no sé quién fue, salí inmediatamente) que abrió una vídeo conferencia de muchas personas. Pero luego lo pensé mejor.

¿Cómo es posible que un programa me meta automáticamente en un sala de vídeo conferencia? No lo podía creer. Nunca había configurado nada así. Voy a mirar la configuración del Hangouts -que recuerdo que es un reemplazo del Gtalk de Android- y veo que Google, y sus programadores, decidieron que me iba aceptar automáticamente conversaciones de toda la gente que tengo en mis círculos de Google+, y ¡también a la que no!. También incluye a las que tengo en «My Stream» (gente a la que sólo sigo sus publicaciones en G+).

Alucinante.

Nunca quise eso (en GTalk sólo me podían escribir a los que tenía autorizado), me meten en una sala con mucha gente y a la que ni conozco por el apodo en internet, y en su momento tampoco agregué a gente en mis círculos -o en «My Stream»- para que me puedan abrir automáticamente vídeo conferencias. No sé quién es el genio al que se le ocurrió eso, pero obviamente lo han tenido que implementar programadores. Un burrada que difícilmente se deje pasar tan fácilmente en otras ingenierías.

Estamos rodeados de programas informáticos, no podemos hacer nada sin ellos, y con los móviles estamos «abiertos» al mundo las 24 horas.  Cualquier cosa que haga un ingeniero/programador tiene efectos reales sobre la gente. Te puede molestar y asustar cuando vas en coche, o despertarte cuando estás durmiendo, o molestarte en medio de una reunión o clase. Hasta hace poco teníamos razonablemente bien controlado, hay un botón u opción rápida para que las llamadas no suenen. Pero es bastante más complicado hacer que todas las aplicaciones no molesten (tampoco tiene sentido estar deshabilitando continuamente la capacidad de que te avise si tienes un Whatsapp o chat). Las cosas empeoran cuando te pueden meter sin preguntar en una sala de conferencia, por ejemplo.

Ortega y Gasset ya lo ha dicho «recuerda que para ser ingeniero no basta con ser ingeniero».

Y tiene toda la razón, lo que hacemos tiene efectos reales sobre la gente, debemos pensar muy bien las causas de lo que implementamos, y corregir inmediatamente si causan problemas. Esta es la responsabilidad de cualquier ingeniero. Pero parece que la tendencia en informáticos es «lo implemento porque se puede», sin pararse a pensar siquiera en lo básico de privacidad, respeto y no molestar innecesariamente.

Cada día me molesta más este pasotismo y «solucionismo» (como diría Eugeny Morozov) de mis colegas. Últimamente lo pienso cada vez que recibo el aviso, varias veces al día, del sistema de bloqueo de DoS de Menéame (en pocas semanas tenemos ya varios cientos de IPs que hacían «DoS» involuntarios). Bots descontrolados que podrían tirar sitios completos (y/o causar gastos innecesarios), programas que generan cientos de conexiones por segundo, a veces durante meses (como nos pasa con la IP 46.105.237.95 de un servidor de DreaMule). No se salva nadie, tenemos bloqueadas IPs de muchas empresas importantes, incluido proxies corporativos de Google, servidores de Automattic/Wordpress, buscadores e indexadores sociales, y hasta con el bot del buscador Bing de Microsoft [*].

Hablando de lecciones. @google, avisé por los canales posibles pero siguen activos bots programados con el orto pic.twitter.com/dCGIjfB8yw

— Ricardo Galli (@gallir) October 21, 2013

Y ahora uno de Automattic, @photomatt give a :facepalm: on my behalf to one (or some) of the programmers 😉 pic.twitter.com/qsMzeJlblG

— Ricardo Galli (@gallir) October 28, 2013

Demasiadas molestias innecesarias causadas por programadores.  Lo de los bots descontrolados que hacen DoS y generan tanto tráfico inútil es de locos, además de las molestias individuales debe tener un coste económico enorme globalmente (¿y cuántos deben pensar que están recibiendo ataques DoS o DDoS cuando es simple irresponsabilidad de programadores). Pero que por defecto y sin preguntar un programa te meta en salas grupales de vídeo conferencia es ya indescriptible: imaginaros que estáis con roaming y no os dais cuenta que vuestro teléfono entró en una conferencia de estas… para daros una idea del daño económico real que puede causar.

No es tan difícil si se piensa un poco, sobre todo si los programas afectan a lo cotidiano de millones de personas, y lo molesto y el daño que pueden causar. Me enerva cada vez más esta incapacidad de pensar profesionalmente en las consecuencias de lo que hacemos. No llegamos ni a ingenieros.

—-
[*] En el caso de Microsoft tuve que darme de alta en Outlook.con, luego agregar los dominios de Menéame, y luego configurar la frecuencia de rastreo para evitar el problema, no ofrecían otra opción. En el caso de Google, envié un email a la dirección de abuse de registros de sus direcciones IP (en ARIN), me devolvió un email automático de que no leen emails, me envió a  un formulario de Google, después de varios intentos, no hubo forma de dejar el comentario. Al final me dijo que lo comente en un foro de Google (que ya ni me acuerdo), nadie me contestó, al final dejamos bloqueadas esas IPs de Google.

← Entradas anteriores

Comprar el libro

Principios y algoritmos de concurrencia

gallir@twitter

  • RT @jlhortelano: Siempre ha sido un manipulador. Pero encima es muy tonto si trata de colar esta foto de Septiembre de 2021, época donde no… 19 hours ago
  • ¿Qué? Por algo se re-empieza. https://t.co/dJ16CcMu9J 1 day ago
  • "sexeafectives" twitter.com/La_Directa/sta… https://t.co/or6E5bOLvT 1 day ago
  • RT @IrvingGatell: 1. No, no se va a armar la Tercera Guerra Mundial. Pero el asunto sí se puso candente. Todo parece indicar que #Iran ha s… 2 days ago
Follow @gallir

RSS Notas recientes

  • Se ha producido un error; es probable que la fuente esté fuera de servicio. Vuelve a intentarlo más tarde.

Archivos

Comentarios recientes

PM en Cuidado con las «clever soluti…
Me matan si no traba… en Cuando el periodismo cede el c…
surco en Cuando el periodismo cede el c…
pancho pérez (@lonch… en Cuando el periodismo cede el c…
Fernando en Cuando el periodismo cede el c…
@beoxman en Cuando el periodismo cede el c…
gallir en Cuando el periodismo cede el c…
Jan Smite en Cuando el periodismo cede el c…
Alejandro en Cuando el periodismo cede el c…
Galletor en Cuando el periodismo cede el c…

Meta

  • Registro
  • Acceder
  • Feed de entradas
  • Feed de comentarios
  • WordPress.com

Licencia

Creative Commons License
Esta obra está bajo una licencia de Creative Commons.

Blog de WordPress.com.

  • Seguir Siguiendo
    • Ricardo Galli, de software
    • Únete a 667 seguidores más
    • ¿Ya tienes una cuenta de WordPress.com? Accede ahora.
    • Ricardo Galli, de software
    • Personalizar
    • Seguir Siguiendo
    • Regístrate
    • Acceder
    • Denunciar este contenido
    • Ver sitio web en el Lector
    • Gestionar las suscripciones
    • Contraer esta barra
 

Cargando comentarios...