Por lo general, no se necesitan algoritmos complejos para el desarrollo web, ya que el desarrollo web está construyendo principalmente interfaces de usuario. Los algoritmos generalmente se encuentran en el código de fondo. Pero el código de fondo no necesita estar relacionado con la web.
Podría haber algunos algoritmos complejos que tendrías que escribir en JavaScript para ejecutarlos en el lado del cliente, pero serían raros. Por ejemplo, un algoritmo de cifrado que cifraría una contraseña antes de enviarla al servidor. (Además de SSL, si eres paranoico). Otros algoritmos complejos del lado del cliente podrían relacionarse con los gráficos del lado del cliente donde el visitante manipularía los gráficos del lado del cliente.
El algoritmo más complejo que he escrito (¡en 2003!) No estaba destinado a una aplicación web, sino que fue utilizado por una aplicación del lado del servidor. Esta aplicación era un programador de tareas complejo que se ejecutaba desatendido en un servidor y tenía una aplicación cliente en un sistema remoto desde donde se podía configurar.
- ¿Aprender Python es completamente imprescindible para continuar con un marco web Django?
- ¿Quiénes son los proveedores de servicios de desarrollo de temas de WordPress recomendados a nivel mundial?
- ¿Cuál es el alcance del lenguaje php?
- ¿Cuáles son algunas formas en que uno puede renderizar LaTeX en la página web?
- ¿Debo usar mi propio CSS o Bootstrap?
El principal desafío era que este programador necesitaba asegurarse de que todas las tareas se ejecutaran sincrónicamente y verificar el estado de retorno de cada tarea, ya que eso determinaría qué tarea tendría que ejecutarse a continuación. Y cada tarea era básicamente otra aplicación. Cada tarea también generaría salida a la consola, por lo que necesitaba capturar esta salida y no se permitió que ninguna tarea tomara más de 4 horas. Si tomaban más tiempo, mi programador estaba destinado a matar la tarea.
Ahora, el desafío era que el planificador tenía que usar un mínimo de tiempo de CPU para que otros procesos tuvieran muchos ciclos de CPU para funcionar a su máxima capacidad. Sin embargo, también tuvo que verificar continuamente la hora actual y la tarea actual en ejecución (si la hubiera) para determinar cuándo era el momento de comenzar la siguiente tarea o finalizar la tarea actual. Y tenía que ser consciente de cuándo terminaba una tarea. No es fácil si cada tarea es un proceso separado.
Todo requería una comprensión profunda de la API de Windows (ya que el servidor usaba Windows 2003) y usé un sistema de mensajería con temporizadores para activar varias cosas siempre que fuera necesario, por lo que todo esperaría cualquier mensaje antes de comenzar a hacer algo. Ningún mensaje significaba que no tomaría tiempo de CPU. Como resultado de un pensamiento inteligente y algoritmos adecuados, me las arreglé para asegurarme de que este programador nunca tomaría más del 10% del tiempo de la CPU en el momento más activo mientras permanecía muy por debajo del 1% mientras está inactivo. Y se aseguraría de no perder ninguna memoria.
Este programador se ejecutó durante meses seguidos sin pérdida de memoria significativa. Tampoco fallas serias o choques duros. Si una tarea falla, entonces no hay problema, ya que el planificador simplemente continuó. Era una cosa hermosa de ver. Pero la complejidad detrás de todo esto fue demasiado para mis colegas que lo vieron básicamente hacer magia. Necesitabas un conocimiento profundo de la API de Windows, que en aquel entonces era bastante raro entre muchos desarrolladores de Windows.
Si la empresa no se hubiera arruinado unos años más tarde, probablemente habría tenido que habilitarla para la web. Pero el único material web que hizo fue en el lado del cliente, lo que podría generar informes como páginas HTML simples con imágenes incrustadas. ¿Por qué? Porque HTML era más práctico que los archivos RTF o Word …
