Perversiones curiosas del mundo de TI - 3

El Daily WTF ha estado recopilando historias divertidas, salvajes y / o tristes del mundo de TI durante 14 años. Traduje varias historias que me parecieron interesantes. Todos los nombres de compañías y nombres han sido cambiados. Los problemas anteriores se pueden encontrar bajo la etiqueta " perversiones curiosas ".

imagen

La primera historia: "No solo genial"


[ Original ]

Todos teníamos colegas que no podían hacer nuestro trabajo. Jarad también tuvo suerte.

Trabajó en Initech en un pequeño grupo de desarrolladores que crearon un cliente de Windows para clientes que lo usaron para interactuar con su servidor. La compañía decidió portar la aplicación de .NET a Java. La guía más importante recomendaba al desarrollador líder de Java Kisha, muy respetado, de Intelligenuity como gerente del proyecto. "No se preocupe", dijo la gerencia. "La inteligencia solo contrata a los programadores más brillantes".

En la primera reunión del proyecto, el gerente anunció que usarían Eclipse para el proyecto Java. Kisha dijo: “No tengo Eclipse. ¿Alguien puede enviar? Jarad le envió un enlace. En la próxima reunión, él le preguntó si ella instaló Eclipse. Ella respondió que no podía descargar el medio, por lo que esperó a la próxima reunión para pedir ayuda. El gerente corrió hacia su auto y resolvió el problema haciendo clic en el enlace de descarga.

Avancemos rápidamente a la próxima reunión: Kisha dijo que no podía seguir trabajando porque "Eclipse tiene algunos problemas con el JDK, ¿alguien me lo puede enviar?" Jarad le envió el enlace nuevamente. Unos días después, en la próxima reunión, dijo: "Eclipse no funciona porque necesita un archivo jar, ¿alguien puede enviarlo?" Y después de eso, "¿Alguien puede enviarme un código para crear clases porque Eclipse informa constantemente una NullPointerException ?"

Finalmente, el gerente cambió la estructura de las reuniones. Continuaron sus reuniones regulares de clientes de Windows, pero agregaron una reunión dedicada por separado solo para Kishi. Con el tiempo, resultó que ella y su esposo eran amigos de un líder de muy alto rango y su esposa. Se celebró una reunión separada para "asegurar su trabajo exitoso"; esto significaba que el gerente del equipo escribió un código para ella.

Una vez, Kisha le dijo al gerente que el cliente tenía un problema crítico con el portal web y que se debería realizar una reunión con el cliente lo antes posible para resolver su problema.

El gerente organizó una reunión con el cliente, él mismo, Kishi, Jarad y el gerente del proyecto, para resolver el problema de una vez por todas. El día de la reunión, el cliente se sorprendió por la cantidad de personal y gerentes de soporte técnico. Explicó: "Um ... el" problema con el portal "fue que le pedí a Kisha la URL del portal web. Fue suficiente para enviarle una carta ".

A veces la justicia ocurre en este mundo, y Kisha como resultado perdió su trabajo.

La segunda historia: "picazón de tres meses"


[ Original ]


En marzo de 2016, Ian necesitaba un trabajo. Casi inmediatamente después del inicio de la búsqueda, tuvo suerte: encontró una pequeña startup que necesitaba un trabajador con conocimientos de arquitectura Python y habilidades de diseño. "Tiny" porque además de Ian, la compañía tenía solo tres desarrolladores bajo el liderazgo de su fundador Jack.

La entrevista con Ian fue realizada por el propio Jack. Después de una prueba técnica, aprendió más sobre el proyecto de la compañía: un prototipo casi completo de la aplicación iOS. El usuario sincroniza su teléfono con un monitor de frecuencia cardíaca de muñeca, después de lo cual el teléfono debe reproducir música que coincida con las actividades actuales del usuario. El objetivo principal de la aplicación era ayudar a lograr el pulso necesario durante el entrenamiento. La aplicación también utilizó los acelerómetros del teléfono para rastrear el ritmo del usuario mientras conducía. Estos datos, según Jack, deberían haber sido útiles para los estudios de la enfermedad de Parkinson. Apoyó su declaración con artículos científicos de las mejores universidades. Jack quería que Ian desarrollara un nuevo sistema de back-end para el almacenamiento de datos y el procesamiento de consultas.

Jack era amable y carismático, y su entusiasmo contagiaba a otros. Ian aceptó de inmediato la oferta y se puso a trabajar al día siguiente. Su oficina era pequeña, pero todavía le pertenecía a él solo. Su tarea consistía en crear el backend necesario para la aplicación.

Han pasado dos semanas. Una madrugada del lunes, Jack invitó a su equipo de desarrollo a la sala de reuniones. El resplandor de su presentación en Powerpoint quemó la retina.

“Lo pensé detenidamente. Somos una startup completamente nueva. Nadie sabe de nosotros, ¿verdad? Necesitamos hacer algo para aumentar el conocimiento de la marca. Entonces, decidí: eliminaremos la parte musical de la aplicación y nos centraremos únicamente en la recopilación de datos ".

Ian instintivamente casi dijo "¡¿Qué ?!" Tendrán que tirar los resultados de dos semanas de trabajo. Además, la parte de recopilación de datos era anteriormente completamente opcional.

Jack cambió a otra diapositiva, que mostraba las métricas que ahora quería rastrear para cada usuario. Había tantos de ellos que tuve que usar la fuente más pequeña. Para leer, Ian tuvo que entrecerrar los ojos.

"¡Si juntas un pajar lo suficientemente grande, ciertamente aparecerá una aguja en él!", Dijo Jack. “Haremos que la aplicación sea gratuita y trabajar con ella implicará un registro obligatorio. Los ingresos reales para nosotros serán los datos recopilados ".

El capital de los inversores se gastó en una oficina de lujo en el centro de negocios de la ciudad; Los desarrolladores de aplicaciones gratuitas merecen solo lo mejor. Jack contrató a un segundo desarrollador de iOS, ciencia de datos y pasante.

"Pero no le dé al pasante ningún trabajo importante", dijo Jack a los empleados a tiempo completo.

Habiendo dominado la nueva situación, Ian comenzó a desarrollar la arquitectura de un nuevo sistema que registrará todos los datos necesarios.

Tres meses después, Jack tiró todo a la basura. "No hay aplicaciones! ¡Necesitamos una nueva dirección de desarrollo! ”

La nueva visión de Jack era crear un sitio web en el que las personas tuvieran que indicar las composiciones que escuchan en un sueño, durante el entrenamiento y otras actividades.

"A la gente le gusta hablar de sí misma", dijo Jack. "¡No debemos pagarles por el hecho de que nos dan sus datos!"

Se contrató a un desarrollador front-end para crear el sitio web. Poco después de lanzar el sitio, Jack se jactó ante los inversores de que había llegado a un millón de visitantes únicos. De hecho, solo hubo unos 300 registros, la mitad de los cuales fueron creados por una persona.

Ya puedes adivinar lo que sucedió tres meses después. Jack abandonó el sitio web de desarrollo lento en favor del bot Slack, que se suponía que respondía al comando "Play ${song} by ${artist}" , encontrando la pista en Spotify y vinculándola. Un widget de Spotify reproduciría una vista previa de 30 segundos o, si el usuario tiene una cuenta de Spotify Premium, la canción completa.

“¿Eso es todo? ¿Cómo vamos a ganar dinero? ”, En este momento, los desarrolladores ya no se contenían en sus reclamos.

"La suscripción se pagará", respondió Jack con valentía.

"¿Para el bot de chat?" "Ian se opuso. “Para que funcione completamente, el usuario ya necesita Spotify Premium. Si queremos que la gente pague más allá de esto, ¡debemos darles más oportunidades! ”

"Nos ocuparemos de esto más tarde", respondió Jack.

Jack encargó al interno que desarrollara el nuevo producto principal de la compañía, violando los requisitos de Jack hace seis meses. El interno hizo el máximo esfuerzo, pero pronto se vio obligado a regresar a la escuela; código incompleto sin ceremonia fue lanzado al desarrollador front-end para su revisión. Con la ayuda de uno de los desarrolladores de iOS, lo terminó. ¿Qué estaba haciendo Ian? Creó un tablero y un registro, porque Jack insistió en que atraen a suficientes usuarios para justificar el esfuerzo.

Pasaron tres meses más. Se agregaron muchas "características", por ejemplo, el bot le pidió obsesivamente a los usuarios en el canal Slack que lo usaran. Este comportamiento violaba los términos de uso de Slack, por lo que la aplicación no estaba permitida en la tienda; El propio Jack tuvo que enviar enlaces a las personas interesadas, para que lo instalaran manualmente. Al principio, el producto fue transferido a 50 compañías "muy amigables" que Jack conocía personalmente; De estos, solo unos pocos lo instalaron, y aún menos continuaron usándolo al día siguiente. Luego, Jack amplió el anuncio a 300 empresas "amigas", pero con el mismo resultado.

El punto de inflexión llegó para Ian cuando Jack comenzó a insistir en un tiempo de trabajo adicional, a pesar de que Ian no podía ayudar a otros desarrolladores en sus tareas. Sin embargo, Jack lo obligó a quedarse hasta tarde para "mostrar solidaridad". Esta fue la gota que colmó el vaso: Ian escribió una carta de renuncia dos semanas después. Su último día en el trabajo coincidió con el lanzamiento del bot Slack, durante el cual observó líneas muy rectas en el tablero. Cuando finalmente dejó la lujosa oficina, la startup todavía no ganó su primer centavo.

Afortunadamente, Jack tenía un plan. Después de que Ian se fue, comenzó de cero y estaba a punto de crear un nuevo producto. No, él no traerá dinero, pero primero deben saber sobre la marca.

Tercera historia: "Transportador de respaldo"


[ Original ]

"Um ... ¿puedes mirar algo para mí?"

Pat dejó de programar nuevas funciones y vio el cubo de Milton parado cerca de ella.

"Creo que estoy teniendo problemas", agregó Milton.

Uno de los principales sistemas internos de la compañía era la tubería de procesamiento de datos. Quizás la palabra "canalización" puede considerarse una exageración, porque en la práctica son solo unos pocos scripts de shell y programas de Python que extraen datos de archivos, realizan operaciones con estos datos y vuelcan los resultados en otros archivos, que luego son leídos por otros scripts. En el proceso de trabajo, la gente usualmente tomaba la última versión de los scripts del sistema de control de versiones, los modificaba y los ajustaba para que respondieran a una pregunta específica relacionada con los datos. Si parecía que este proceso en particular podría tener valor, entonces limpiaron el código y lo agregaron nuevamente al sistema de control de versiones. Si pensaban que ya no necesitaban el código, simplemente se restablecían a HEAD.

Sin embargo, algunos, como Milton, básicamente conservaron su propia copia de todos los guiones. O, como es el caso con Milton, algunas copias. Milton conocía el proceso de procesamiento de datos lo mejor de todo, pero la mayor parte de este conocimiento estaba contenido en su biblioteca personal de scripts.

"Pensé que valía la pena hacer mis cambios en el sistema de control de versiones", dijo Milton. "Tenía un script llamado por un script que fue llamado por el script, y todo dependía de un conjunto de variables de shell creadas, por ejemplo $SETUP_DIR ".

Pat asintió con la cabeza.

“Así que quería reorganizar todo esto en un argumento para que otras personas pudieran usar el código. Lo hice ... pero antes de probar, olvidé cambiar los scripts de llamada para que pasen una discusión ".

En particular, el guión de Milton contenía esta línea:

#!/bin/sh

rm -rf $SETUP_DIR/*/


Lo refactorizó a la siguiente línea:

#!/bin/sh

rm -rf $1/*/


Los scripts de shell no se preocupan por la existencia de estas variables. Milton tenía un entorno persistente por $SETUP_DIR . Pero $1 es el primer argumento, y si no pasa el argumento, estará vacío. Por lo tanto, un nuevo script de Milton, cuando se lanzó sin argumentos, se implementó en rm -rf /*/ , eliminando todo a lo que su cuenta tenía acceso.

Básicamente, esto condujo a numerosos intentos de eliminar archivos para los que no tenía derechos. Además, esto significó la desaparición de su directorio de inicio con un montón de scripts de spaghetti que eran completamente imposibles de recrear porque nunca entraron en el control de versiones.

"¿Se puede solucionar esto de alguna manera?", Preguntó Milton.

“Bueno, sí, por supuesto. Todo se puede restaurar desde su última copia de seguridad ", dijo Pat.

Aunque se lanzó una herramienta de copia de seguridad automatizada en todos los sistemas Windows, no se configuró en ningún sistema Linux. El departamento de soporte técnico consideró que si es lo suficientemente competente técnicamente para trabajar con Linux y escribir scripts de shell, tendrá suficiente conocimiento para configurar su propio sistema de respaldo. Especialmente para este propósito, había una SAN accesible para todos.

"Ah, y yo ... nunca configuré una copia de seguridad", susurró Milton. "Bueno ... al menos no empujé?"

Pat esperaba que Milton aprendiera la lección correcta de este error.

Cuarta historia: "¿Qué es un punto flotante?"


[ Original ]

imagen

Hay muchos obstáculos para los programadores novatos: la diferencia entre declarar una variable e inicializarla, la necesidad de usar a veces punto y coma para completar líneas, compensar los errores en uno ... Todos en nuestra industria nos encontramos con ingeniosos programadores autodidactas que pueden crear aplicaciones a gran escala con la arquitectura adecuada, incluso un sueño, pero vimos jóvenes autodidactas, que apenas habían dominado los conceptos básicos y pensaban que eso era todo lo que necesitaban. Al final, se necesitan diplomas y educación formal por una razón.

Esta historia comenzó cuando Olaf se graduó de la universidad y trabajó en su primer trabajo real como "programador en prácticas". La compañía se ha fijado el objetivo de mejorar la gobernanza en el sistema de salud estatal: cualquiera que tenga el dudoso placer de comunicarse con los sistemas de salud dirá que esta es una tarea noble. Sin embargo, la compañía fue fundada por un médico que solo tenía un conocimiento superficial en PHP, que estudió de forma independiente cuando se le dio tiempo.

Olaf se puso a trabajar, con la intención de aplicar su conocimiento de los patrones de diseño. PHP es fácil de aprender, pero difícil de dominar; muchos ejemplos escritos en software PHP usan objetos divinos, y el código se mezcla con la presentación, dos errores graves que, sin embargo, no se mencionan en la mayoría de los tutoriales en línea. Olaf comenzó a separar la función del formulario, crear objetos que se pueden usar repetidamente para minimizar el copiar y pegar, y se dedicó a otras tareas similares, felizmente convirtiendo el caos del código que le pasó en orden.

Y entonces se encontró en la oficina del jefe, quien hizo los arreglos para que se lavara.

"¡Otros programadores no entenderán esto!", Gritó el jefe. “El código es demasiado complicado. ¿Por qué lo estás cambiando? ¡Funciona, tenías que dejarlo!

Desalentado, Olaf volvió al trabajo y subió una versión limpia a su rama principal sin ningún cambio. Intentando evitar una colisión con malas prácticas, comenzó a trabajar en un error en el sistema de contabilidad, que tiene alta prioridad y urgencia, porque se relaciona con la facturación. Los usuarios podían cargar archivos CSV al servidor con información sobre sus gastos, y el sistema resumió los valores por categoría y creó informes de facturación. Sin embargo, en algún lugar del interior, se produjo un error de redondeo, lo que condujo en algunos casos límite importantes a cantidades incorrectas.

Olaf estudió más que sus colegas, pero ninguna capacitación es integral. Rápidamente logró determinar que se trataba de un error matemático con un punto flotante. Dado que los números decimales no pueden representarse en forma binaria con total precisión, en casos límite surgieron errores de cálculo. Comenzó a buscar las formas correctas de manejar valores decimales en PHP. A diferencia de Node o C #, las bibliotecas externas en PHP son bastante difíciles de conectar, porque este lenguaje no tiene soporte incorporado para la administración de paquetes. No sabía cómo agregar una biblioteca capaz de realizar correctamente operaciones matemáticas. Dado que el software solo calculó las sumas, Olaf decidió usar matemáticas enteras: lea el valor, elimine el punto decimal (para que el valor de 10.50 $ se represente como 1050), realice los cálculos y agregue el punto decimal nuevamente cuando se muestre.

A otro joven le gustó la idea. El desarrollador senior lo aprobó, pero el jefe rechazó rotundamente la oferta. ¿Cómo argumentó por esto? “Esto no es un error de coma flotante. Surge debido a un tipeo débil de PHP, el programa intenta sumar los valores como cadenas, no como números ".

(Para aquellos que tienen curiosidad: PHP no usa el operador + para concatenar cadenas. En cambio, usa el ".". El resultado de "hello " . "world" será "hello world" ).

Como resultado, el desarrollador senior se dio cuenta de esta decisión: separar la parte completa de la fracción, de modo que $ 10.50 se convirtieron en $ 10.00 y $ 0.50, y luego resumir cada parte por separado.

Olaf no se demoró, esperando que descubrieran que el error todavía estaba en su lugar, porque el programa aún procesaba la parte fraccional con centavos como un número de coma flotante. Encontró un mejor trabajo con un mejor idioma, y ​​dejó la empresa.

imagen

Quinta historia: "Seguridad calculada"


[ Original ]

A finales de los años 80, Karl trabajó durante algún tiempo en una empresa de desarrollo de software que se ocupaba de sistemas de aviónica y posicionamiento global para clientes militares y civiles. En los negocios, a menudo visitaba a Schlockdeed Corp, un cliente con un contrato para desarrollar una nueva generación de aviones de combate para el Ejército de los EE. UU. Debido al estricto secreto de su trabajo, era muy importante garantizar la seguridad.

Cada vez que Carl entraba o salía de la empresa, tenía que pasar por el departamento de seguridad. Allí revisó cuidadosamente su maletín, chaqueta, lonchera y casi todo, excepto un estudio completo de las cavidades corporales. A pesar de los meticulosos controles diarios en Schlockdeed, algunas de sus "medidas de seguridad" limitaban con lo absurdo.

En esta era de transmisión de información a través del disquete , los programadores a menudo se llevaban con ellos al trabajo y tomaban cajas con disquetes. Schlockdeed , , . « ». , .

, HP-41CX. , , . HP-41CX .

: «, . ». . 41CX - ? , ? «, CIO. », — .

, , , «» . , (Chief Information Officer) . , 80-. , Calculator Inspection Officer.

«, », — , . HP-41CX. : « . , , . , !» , .

, . . , . AC (Approved Calculator), . HP-41CX, , Schlockdeed . , , « » -.

Source: https://habr.com/ru/post/442222/


All Articles