¿Cuál es tu juego de mesa favorito?
«Scrabble»
Ask @iamemhn
Previous
Cuál sería tú configuración ideal para un servicio de envío masivo de correo?
Una máquina actuando como «caja negra», en una red que controlo y a la cual sólo yo tengo acceso via SSH, tal que:
- Esté declarada como enviadora autorizada para el dominio origen, con todos los puntos de contacto establecidos a priori y la reputación preparada ante los operadores de correo electrónico relevantes a la audiencia destino.
- Tenga un MTA que acepta conexiones autenticadas y cifradas digitalmente por mi autoridad de certificación.
- Analiza la estructura y construcción del mensaje a enviar, para impedir que se envíe y contestar al emisor con los defectos de forma y fondo que tiene. De ese modo, se detiene el «spam a priori». El MTA debe hacer ese trabajo «al pasar» porque los humanos que componen mensajes de correo publicitario creen que lo están haciendo bien, pero no.
- Que identifique cada mensaje de cada secuencia de envío de manera unívoca para poder interpretar las respuesta automáticas o no que sean recibidas a propósito de su envío. El MTA debe hacer ese trabajo «al pasar» de manera automática porque las aplicaciones de envío de correo lo hacen de manera inocente e inconsistente.
- Que incorpore a cada mensaje los encabezados y meta-datos adicionales que garanticen que cumple con todas las prácticas actuales para el envío de mensajes de correo legítimos. Sin excluir otros: certificación de origen, certificación de estructura original, certificación de punto de contacto, y declaración de evento de despacho. El MTA debe incluir todo este contenido «al pasar».
- Que intente el despacho por lotes con estrategia de «exponential backoff», registrando los errores permanentes para impedir futuros envíos a dichos destinatarios, categorizando los errores temporales para determinar si se convierten en permanantes o no, y alertando de respuestas aparentemente enviadas por humanos para que intervenga el interesado. El MTA debe relacionar a los reportes y cotejarlos automáticamente con la identificación única, y reconfigurarse para impedir que el usuario insista enviando donde no debe.
- Instrumentación para observar todos los elementos de operación, en particular de la eficiencia de entrega por destino y de incidencia por despacho, sin excluir otros necesarios para escalabilidad.
- Aplicación web/end-point para que los clientes puedan ver la instrumentación que les compete.
- Aplicación web/end-point para que los clientes puedan «pre-procesar» una lista de distribución sin hacer envíos completos.
- Integrada con mi sistema de tickets para que notifique eventos especiales de operación o de notificaciones enviadas por los operadores destino.
- Desplegable en quince minutos y obliterable de forma automática si no me pagan. Puntos extra si el disco duro está cifrado y no lo pueden leer cuando se «roban» la máquina (me pasó con un cliente que no quiso pagar y se llevó la caja para «analizarla» porque «era suya»).
Es uno de los servicios que ofrezco. Pero la gente usa mailchimp y hace mucho trabajo manual :-)
- Esté declarada como enviadora autorizada para el dominio origen, con todos los puntos de contacto establecidos a priori y la reputación preparada ante los operadores de correo electrónico relevantes a la audiencia destino.
- Tenga un MTA que acepta conexiones autenticadas y cifradas digitalmente por mi autoridad de certificación.
- Analiza la estructura y construcción del mensaje a enviar, para impedir que se envíe y contestar al emisor con los defectos de forma y fondo que tiene. De ese modo, se detiene el «spam a priori». El MTA debe hacer ese trabajo «al pasar» porque los humanos que componen mensajes de correo publicitario creen que lo están haciendo bien, pero no.
- Que identifique cada mensaje de cada secuencia de envío de manera unívoca para poder interpretar las respuesta automáticas o no que sean recibidas a propósito de su envío. El MTA debe hacer ese trabajo «al pasar» de manera automática porque las aplicaciones de envío de correo lo hacen de manera inocente e inconsistente.
- Que incorpore a cada mensaje los encabezados y meta-datos adicionales que garanticen que cumple con todas las prácticas actuales para el envío de mensajes de correo legítimos. Sin excluir otros: certificación de origen, certificación de estructura original, certificación de punto de contacto, y declaración de evento de despacho. El MTA debe incluir todo este contenido «al pasar».
- Que intente el despacho por lotes con estrategia de «exponential backoff», registrando los errores permanentes para impedir futuros envíos a dichos destinatarios, categorizando los errores temporales para determinar si se convierten en permanantes o no, y alertando de respuestas aparentemente enviadas por humanos para que intervenga el interesado. El MTA debe relacionar a los reportes y cotejarlos automáticamente con la identificación única, y reconfigurarse para impedir que el usuario insista enviando donde no debe.
- Instrumentación para observar todos los elementos de operación, en particular de la eficiencia de entrega por destino y de incidencia por despacho, sin excluir otros necesarios para escalabilidad.
- Aplicación web/end-point para que los clientes puedan ver la instrumentación que les compete.
- Aplicación web/end-point para que los clientes puedan «pre-procesar» una lista de distribución sin hacer envíos completos.
- Integrada con mi sistema de tickets para que notifique eventos especiales de operación o de notificaciones enviadas por los operadores destino.
- Desplegable en quince minutos y obliterable de forma automática si no me pagan. Puntos extra si el disco duro está cifrado y no lo pueden leer cuando se «roban» la máquina (me pasó con un cliente que no quiso pagar y se llevó la caja para «analizarla» porque «era suya»).
Es uno de los servicios que ofrezco. Pero la gente usa mailchimp y hace mucho trabajo manual :-)
Liked by:
Francisco
Carlos Torres
Cesar Rada
Marcos Mora
Muchas personas opinan que Perl esta muerto. Por que usted piensa que no es asi?
Se selecciona un lenguaje de programación tomando en consideración muchas variables. Hay una variable, «comunidad organizada» que es particularmente importante.
No hay lenguaje que tenga un catálogo de librerías organizado, curado y documentado como CPAN. Se puede argumentar que CTAN de LaTeX y CRAN de R están cerca, pero no son lenguajes de propósito general. No es casualidad que el resto de los lenguajes haya tratado de imitar ese concepto, pero están lejos... y es por sus comunidades.
Hablando de comunidad de usuarios, partiendo desde PerlMonks [2] y pasando por los canales de IRC, sólo la comunidad de Haskell me resulta mejor.
El lenguaje Perl 5, pareciera «estancado» para el que no lo sigue en detalle. Más aún Perl 6 pareciera un proyecto fallido (y podemos estar de acuerdo hasta cierto punto en eso). Sin embargo, Perl 5 adoptó ideas de Perl 6 paulatinamente en forma de librerías o de modificaciones al núcleo, de modo que el Perl 6 que «no existe», ya existe hace varios años en Perl 5 — y funciona. Perl 5 es el mejor LISP imperativo que puede tenerse, y lo seguirá siendo por mucho tiempo.
Existen librerías estables, poderosas, probadas exhaustivamente y desplegadas con éxito, para resolver el problema de Orientación a Objetos No-Jerárquica, del ORM, de MVC, y todos los accesorios habituales, cuyas funcionalidades están por encima de la de cualquiera de los otros lenguajes que usan «muchas personas» (Python, Ruby, JavaScript, Go, Switf, C#), y que continúan evolucionando. Además, suelen estar profusamente documentadas.
Las herramientas de desarrollo (debugger, profiler, bundler, ambiente virtual) siempre fueron buenas, y han mejorado mucho porque han tomado buenas ideas de otros lenguajes. Además, hay una cultura de usar esas herramientas desde que comienzas, diferente a otros lenguajes en las cuales se institucionalizó «voodoo programming & taboo debugging».
El lenguaje fue diseñado para ser simple, pero extensible, y eso es precisamente lo que ocurrió técnica y socialmente. La comunidad de Perl es más grande de lo que la gente cree, pero al mismo tiempo es bastante más refinada — es una cuestión LISP.
De los lenguajes dinámicos imperativos, no me queda duda que es el más poderoso. Claro que hoy en día prefiero lenguajes funcionales con sistemas de tipos estrictos y estáticos, pero esa es otra historia.
[1] http://www.cpan.org
[2] http://www.perlmonks.org/
No hay lenguaje que tenga un catálogo de librerías organizado, curado y documentado como CPAN. Se puede argumentar que CTAN de LaTeX y CRAN de R están cerca, pero no son lenguajes de propósito general. No es casualidad que el resto de los lenguajes haya tratado de imitar ese concepto, pero están lejos... y es por sus comunidades.
Hablando de comunidad de usuarios, partiendo desde PerlMonks [2] y pasando por los canales de IRC, sólo la comunidad de Haskell me resulta mejor.
El lenguaje Perl 5, pareciera «estancado» para el que no lo sigue en detalle. Más aún Perl 6 pareciera un proyecto fallido (y podemos estar de acuerdo hasta cierto punto en eso). Sin embargo, Perl 5 adoptó ideas de Perl 6 paulatinamente en forma de librerías o de modificaciones al núcleo, de modo que el Perl 6 que «no existe», ya existe hace varios años en Perl 5 — y funciona. Perl 5 es el mejor LISP imperativo que puede tenerse, y lo seguirá siendo por mucho tiempo.
Existen librerías estables, poderosas, probadas exhaustivamente y desplegadas con éxito, para resolver el problema de Orientación a Objetos No-Jerárquica, del ORM, de MVC, y todos los accesorios habituales, cuyas funcionalidades están por encima de la de cualquiera de los otros lenguajes que usan «muchas personas» (Python, Ruby, JavaScript, Go, Switf, C#), y que continúan evolucionando. Además, suelen estar profusamente documentadas.
Las herramientas de desarrollo (debugger, profiler, bundler, ambiente virtual) siempre fueron buenas, y han mejorado mucho porque han tomado buenas ideas de otros lenguajes. Además, hay una cultura de usar esas herramientas desde que comienzas, diferente a otros lenguajes en las cuales se institucionalizó «voodoo programming & taboo debugging».
El lenguaje fue diseñado para ser simple, pero extensible, y eso es precisamente lo que ocurrió técnica y socialmente. La comunidad de Perl es más grande de lo que la gente cree, pero al mismo tiempo es bastante más refinada — es una cuestión LISP.
De los lenguajes dinámicos imperativos, no me queda duda que es el más poderoso. Claro que hoy en día prefiero lenguajes funcionales con sistemas de tipos estrictos y estáticos, pero esa es otra historia.
[1] http://www.cpan.org
[2] http://www.perlmonks.org/
Liked by:
Carlos Torres
Marcos Mora
Walter Vargas
Cesar Rada
Related users
¿Como se podría mejorar la distribución Canaima? ¿Que le recomendaría a las personas que se encargan de ello?
No hay espacio suficiente para los detalles, sin embargo cualquiera que se sabe el Debian Policy y el Debian Developers Reference de arriba abajo comprenderá las siguientes líneas — presumo que los que están haciendo Canaima tienen esa preparación.
Hacer paquetes Debian correctos, completos y con *todas* las facilidades de autoconfiguración. Esos paquetes son para los estilos visuales, aplicaciones desarrolladas por la administración pública, en fin, todo lo que no tiene sentido que Debian ofrezca pero que otorga identidad a Canaima. Usar el instalador Debian sin modificaciones, y construir el medio de instalación (CD, DVD) con la herramienta debian-cd.y las plantillas de autoconfiguración correctas [2]. «Pero es que Canaima es una meta-distribución...»; no, Debian es una meta-distribución y Canaima debería ser una distribución derivada de la distribución central Debian (antes se llamaban «custom distributions», ahora se llaman «blends» [1]).. «Pero es que el instalador Debian no hace lo que quiero»; probablemente si, pero hay que leer un poco más, no obstante, si realmente tuvieras razón, entonces escribe un UDEB para la extensión (y contribuye a Debian tu genial mejora que nadie había necesitado antes).
En resumen, no tratar de diferenciarse de Debian reinventando la rueda o mutilando cosas de Debian porque «no sirven» (eufemismo por, «son complicadas y... ¡mira!, ¡una guacharaca!»). Mis revisiones periódicas de Canaima me hacen pensar que no hay evidencia de que estén en el camino de la integración, sino de la diferenciación forzada y llena de penurias.
Estas recomendaciones las hice desde el primer día (por escrito, porque soy ese tipo de insoportable), y fue ignorada en la siguiente versión por «razones». Considerando que una de las libertades del Software Libre es la de hacer lo que te venga en gana con el software, no soy nadie para decirles qué hacer y tampoco pretendo que me presten atención.
Nadie aprende por experiencia ajena, y no se puede ser papá de todo el mundo.
[1] https://wiki.debian.org/DebianPureBlends
[2] https://wiki.debian.org/DebianCustomCD
Hacer paquetes Debian correctos, completos y con *todas* las facilidades de autoconfiguración. Esos paquetes son para los estilos visuales, aplicaciones desarrolladas por la administración pública, en fin, todo lo que no tiene sentido que Debian ofrezca pero que otorga identidad a Canaima. Usar el instalador Debian sin modificaciones, y construir el medio de instalación (CD, DVD) con la herramienta debian-cd.y las plantillas de autoconfiguración correctas [2]. «Pero es que Canaima es una meta-distribución...»; no, Debian es una meta-distribución y Canaima debería ser una distribución derivada de la distribución central Debian (antes se llamaban «custom distributions», ahora se llaman «blends» [1]).. «Pero es que el instalador Debian no hace lo que quiero»; probablemente si, pero hay que leer un poco más, no obstante, si realmente tuvieras razón, entonces escribe un UDEB para la extensión (y contribuye a Debian tu genial mejora que nadie había necesitado antes).
En resumen, no tratar de diferenciarse de Debian reinventando la rueda o mutilando cosas de Debian porque «no sirven» (eufemismo por, «son complicadas y... ¡mira!, ¡una guacharaca!»). Mis revisiones periódicas de Canaima me hacen pensar que no hay evidencia de que estén en el camino de la integración, sino de la diferenciación forzada y llena de penurias.
Estas recomendaciones las hice desde el primer día (por escrito, porque soy ese tipo de insoportable), y fue ignorada en la siguiente versión por «razones». Considerando que una de las libertades del Software Libre es la de hacer lo que te venga en gana con el software, no soy nadie para decirles qué hacer y tampoco pretendo que me presten atención.
Nadie aprende por experiencia ajena, y no se puede ser papá de todo el mundo.
[1] https://wiki.debian.org/DebianPureBlends
[2] https://wiki.debian.org/DebianCustomCD
Liked by:
Walter Vargas
¿Puedo usar Vim como reemplazo a Word? ¿Cómo escribir poesía?
Vim es un editor de texto pensado para administradores de sistemas, programadores y personas que quieran escribir sin preocuparse por la presentación final. Si lo que te importa es fundamentalmente el fondo, y no la forma, Vim te facilitará el trabajo.
La documentación de Vim explica cómo completar las operaciones habituales de transformación de texto (agregar, borrar, cortar, copiar, pegar, «reorganizar») y cómo utilizar herramientas externas adicionales de utilidad (para el que escribe, probablemente un corrector ortográfico en muchos idiomas).
Vim no es un editor WYSIWYG (What You See Is What You Get), de modo que lo que ves en la pantalla es tu texto, sin adorno y nada más. Así, puedes sentarte a escribir todo lo que quieras, concentrándote en la sustancia y calidad del contenido, dejando el problema de la presentación para el final.
Para la presentación final tienes dos alternativas interesantes, una sencilla de aprender y aprovechar; otra más compleja y poderosa.
La alternativa sencilla es Pandoc [1]. Utilizando Vim (y en justicia, cualquier otro editor de texto), escribes el texto combinado con marcas especiales. Luego, el programa `pandoc` convierte el texto al formato que te convenga (PDF, HTML, EPUB, etc.). Las marcas son fáciles de aprender, no interfieren con tu trabajo de escritura, y Vim (o cualquier otro editor decente) las resaltarán de alguna forma. Nota que escribes una sola vez en ese lenguaje de marcas, y luego puedes producir múltiples formatos de salida, utilizando comandos sencillos que, por supuesto, puedes asociar a las teclas de función del editor.
La alternativa compleja es LaTeX [2]. Pandoc usa a LaTeX de manera simplificada para obtener un resultado generalmente bueno y suficiente. Sin embargo, cuando hace falta escribir fórmulas matemáticas, construir diagramas gráficos de alta calidad [3], o emplear tipografía especial, se termina escribiendo LaTeX directamente. Lo bueno es que con Pandoc puedes mezclar las marcas simples con fragmentos LaTeX.
Usualmente comienzas con la herramienta sencilla, y en el momento en que el formato de salida no te gusta o requiere cambios específicos, aprendes LaTeX para cambiar las plantillas que usa Pandoc, o para escribir los pedazos de LaTeX para las fórmulas o diagramas.
Finalmente, y no menos importante, como el lenguaje de marcas es texto simple, ocupa menos espacio y te permite sacar provecho de herramientas de control de versiones como Git para hacer seguimiento a la evolución de tu trabajo. Y todo esto se puede hacer sin involucrar clicks, manteniendo los diez dedos productivos encima de las teclas y no paseándose para atrapar el mouse.
En el tópico particular de escribir poesía, LaTeX tiene un estilo [4] para eso. Internet puede decirte si alguien lo adaptó a Pandoc.
[1] http://pandoc.org/
[2] https://www.latex-project.org/about/
[3] http://www.texample.net/
[4] https://www.tug.org/texlive//Contents/live/texmf-dist/doc/latex/verse/verse.pdf
La documentación de Vim explica cómo completar las operaciones habituales de transformación de texto (agregar, borrar, cortar, copiar, pegar, «reorganizar») y cómo utilizar herramientas externas adicionales de utilidad (para el que escribe, probablemente un corrector ortográfico en muchos idiomas).
Vim no es un editor WYSIWYG (What You See Is What You Get), de modo que lo que ves en la pantalla es tu texto, sin adorno y nada más. Así, puedes sentarte a escribir todo lo que quieras, concentrándote en la sustancia y calidad del contenido, dejando el problema de la presentación para el final.
Para la presentación final tienes dos alternativas interesantes, una sencilla de aprender y aprovechar; otra más compleja y poderosa.
La alternativa sencilla es Pandoc [1]. Utilizando Vim (y en justicia, cualquier otro editor de texto), escribes el texto combinado con marcas especiales. Luego, el programa `pandoc` convierte el texto al formato que te convenga (PDF, HTML, EPUB, etc.). Las marcas son fáciles de aprender, no interfieren con tu trabajo de escritura, y Vim (o cualquier otro editor decente) las resaltarán de alguna forma. Nota que escribes una sola vez en ese lenguaje de marcas, y luego puedes producir múltiples formatos de salida, utilizando comandos sencillos que, por supuesto, puedes asociar a las teclas de función del editor.
La alternativa compleja es LaTeX [2]. Pandoc usa a LaTeX de manera simplificada para obtener un resultado generalmente bueno y suficiente. Sin embargo, cuando hace falta escribir fórmulas matemáticas, construir diagramas gráficos de alta calidad [3], o emplear tipografía especial, se termina escribiendo LaTeX directamente. Lo bueno es que con Pandoc puedes mezclar las marcas simples con fragmentos LaTeX.
Usualmente comienzas con la herramienta sencilla, y en el momento en que el formato de salida no te gusta o requiere cambios específicos, aprendes LaTeX para cambiar las plantillas que usa Pandoc, o para escribir los pedazos de LaTeX para las fórmulas o diagramas.
Finalmente, y no menos importante, como el lenguaje de marcas es texto simple, ocupa menos espacio y te permite sacar provecho de herramientas de control de versiones como Git para hacer seguimiento a la evolución de tu trabajo. Y todo esto se puede hacer sin involucrar clicks, manteniendo los diez dedos productivos encima de las teclas y no paseándose para atrapar el mouse.
En el tópico particular de escribir poesía, LaTeX tiene un estilo [4] para eso. Internet puede decirte si alguien lo adaptó a Pandoc.
[1] http://pandoc.org/
[2] https://www.latex-project.org/about/
[3] http://www.texample.net/
[4] https://www.tug.org/texlive//Contents/live/texmf-dist/doc/latex/verse/verse.pdf
Liked by:
Mauro
Marcos Mora
Por que no le gusta el editor nano?
nano es una imitiación casi exacta (y no mucho más avanzada) de pico. pico era un editor inventado con el único propósito de escribir mensajes de correo en un MUA llamado pine que estaba orientado a lusers, perdón, «usuarios finales». Nada más. Es más, cualquier administrador de sistemas con experiencia te dirá que nunca usó pine, porque era frustrante no poder deshacerse del inútil pico y poner vim o emacs como editor. De manera que nano no es más que un editor de texto, orientado a ediciones rápidas de mensajes de correo y uno que otro archivo de texto.
El trabajo de programar y de administrar sistemas es mucho más que simplemente «editar texto», sobre todo cuando uno desarrolla competencias importantes y requiere que el editor no sea una muleta sino una motosierra untada en curare. Es por eso que existen editores mucho más poderosos, como vim o EMACS; el tiempo que inviertes en aprender a usar cualquiera de esos dos, será redituado con creces después.
A primera vista nano luce útil para un novato absoluto, sin embargo no es un editor pensado para administradores de sistemas ni programadores. No puedo recomendárselo a nadie.
El trabajo de programar y de administrar sistemas es mucho más que simplemente «editar texto», sobre todo cuando uno desarrolla competencias importantes y requiere que el editor no sea una muleta sino una motosierra untada en curare. Es por eso que existen editores mucho más poderosos, como vim o EMACS; el tiempo que inviertes en aprender a usar cualquiera de esos dos, será redituado con creces después.
A primera vista nano luce útil para un novato absoluto, sin embargo no es un editor pensado para administradores de sistemas ni programadores. No puedo recomendárselo a nadie.
Liked by:
Pablo Ortega
Alguna manera eficiente de construir y representar un grafo en Haskell?
Data.Graph de la plataforma y Data.Graph.Inductive del paquete fgl son los más generales.
¿Cuál es tu número de la suerte?
La gente llama «suerte» a lo que en realidad es el momento en que «preparación» y «oportunidad» se encuentran. Si llevas los dos ojos abiertos, tienes tres dedos de frente y usas el cerebro los siete días de la semana, los demás dirán que tienes suerte. Do the math.
Liked by:
Felix valois Jimenez Parada
Mauro
'Profesor, ¿Qué libros o recursos recomienda para aprender Machine Learning?
Estoy usando «Introduction to Machine Learning» de Nilson, y «Understanding Machine Learning: From Theory to Algorithms» de Shalev-Shwartz y Ben-David. Me han funcionado bien junto al venerable «Linear Algebra» de Strang.
¿Qué opinas del Machine Learning? ¿Qué lenguajes tengo que aprender para meterme en ese mundo? ¿Qué piensas del Data Science en general?
Se trata de construir modelos de regresión usando muestras, para poder predecir resultados con muestras diferentes. Si el modelo de regresión es demasiado «estricto», pierde generalidad; si el modelo de regresión es demasiado «relajado», pierde utilidad. Hasta ahora no he visto ninguna máquina que se dé cuenta de estas cosas; siempre hay un humano, que sabe del problema y del modelo, que ajusta cuidadosamente el conjunto de entrenamiento, el conjunto de control, y supervisa que las predicciones estén en el rango de lo deseable y útil. La máquina sólo saca cuentas, y si la apagas en mal momento, queda igual de bruta que al principio, y tú frustrado porque perdiste el modelo.
El nombre «Data Science» es un bonito título para análisis y predicción estadística como la que se hace desde hace años. La gente y su necesidad de cambiarle los nombres a las cosas para que sean más atractivas al público en general.
La mayoría de los modelos de regresión se basan de una u otra forma en álgebra lineal: desde un clasificador lineal hasta las redes neurales se pueden modelar usando matrices, que se suman con matrices o se multiplican con matrices. Las matrices son grandes, son de números en punto flotante y muy esparcidas. Te conviene aprender lenguajes en los cuales esos problemas estén resueltos bien: tipo de datos vector y matriz nativos, con operaciones nativas fáciles de expresar (suma, resta, multiplicación, inversa, determinante, descomposición LU, eigen-values/vectors, etc.), y preparado para manejar los diversos problemas relacionados con el manejo de números en punto flotante.
Personalmente, prefiero Octave y Julia para estas cosas, si los datos están dentro de PostgreSQL, posiblemente R. Si bien hay gente que usa Python con ciertas librerías que *NO* están escritas en Python, e incluso C++, el trabajo en escribir los programas es mucho mayor que el trabajo en refinar el modelo.
El nombre «Data Science» es un bonito título para análisis y predicción estadística como la que se hace desde hace años. La gente y su necesidad de cambiarle los nombres a las cosas para que sean más atractivas al público en general.
La mayoría de los modelos de regresión se basan de una u otra forma en álgebra lineal: desde un clasificador lineal hasta las redes neurales se pueden modelar usando matrices, que se suman con matrices o se multiplican con matrices. Las matrices son grandes, son de números en punto flotante y muy esparcidas. Te conviene aprender lenguajes en los cuales esos problemas estén resueltos bien: tipo de datos vector y matriz nativos, con operaciones nativas fáciles de expresar (suma, resta, multiplicación, inversa, determinante, descomposición LU, eigen-values/vectors, etc.), y preparado para manejar los diversos problemas relacionados con el manejo de números en punto flotante.
Personalmente, prefiero Octave y Julia para estas cosas, si los datos están dentro de PostgreSQL, posiblemente R. Si bien hay gente que usa Python con ciertas librerías que *NO* están escritas en Python, e incluso C++, el trabajo en escribir los programas es mucho mayor que el trabajo en refinar el modelo.
Últimamente veo que están saliendo varias librerías para chequeo de tipos en lenguajes dinámicos. En Python, por ejemplo, recientemente anunciaron algo llamado mypy, que introduce type annotations. Cuál es el punto de hacer un lenguaje dinámico para revisar tipos estáticos? es esto mal diseño?
Los lenguajes dinámicos también hacen verificaciones de tipos, sólo que las hacen a tiempo de ejecución. Hay lenguajes dinámicos con sistemas de tipos bastante estrictos, como Racket, Erlang o Prolog. No verifican nada antes de correr, pero si verifican muchas cosas durante la corrida. Evidentemente, esto permite que el desarrollador escriba muy rápido, pero difiere todos los problemas a la hora de la ejecución.
Hay lenguajes dinámicos con sistemas de tipos débiles, como JavaScript, Python o Perl. No verifican (casi) nada antes de ejecutar, y durante la ejecución verifican algunas cosas, pero también hacen conversiones implícitas (e.g. "42" es cadena o número o booleano o arepa de perico, según convenga).. La cosa es aún peor que en el caso anterior, pues podría haber errores de tipos que no son reportados como tales, pues hay alguna regla del lenguaje que «lo permite».
Esto, por supuesto, hace que la gente ataque el problema construyendo un nuevo problema: hacer suficientes pruebas para «garantizar» que no hay errores de tipos.
Las herramientas como las que mencionas, son herramientas complementarias de análisis estático. El lenguaje principal no va a cambiar en el futuro inmediato, pero se le ofrecen al programador algunos mecanismos para protegerse un poco más. Los mecanismos no son completos, ni sustituyen a un sistema de tipos estático de primera clase, pero son mejores que «escribir pruebas» — por supuesto que estos sistemas también son pruebas, sólo que generadas semi-automáticamente. Estos sistemas no van a prevenir errores de tipos mucho mejor que lo que hace el lenguaje, porque siempre va a venir algún idiota a poner String como tipo... después de todo String es el tipo de datos del pobre.
La idea ni siqueira es «original». Cuando se escribieron los primeros compiladores de C, no había suficientes recursos (RAM/CPU) para hacer todo lo que se podía hacer de verificación. Además, no se sabía lo suficiente de verificación estática y análisis de flujo para detectar errores que hoy en día son simples de implantar en cualquier compilador. Entonces, se inventó la herramienta `lint`: sólo hacía análisis estático de los programas en C, indicando malas prácticas, posibles errores e incluso formas no portátiles presentes en el código. Hoy en día, `lint` no es necesario porque los compiladores de C ya incluyen esas técnicas.
El atractivo fundamental de los lenguajes dinámicos es (para algunas personas), que no hay un sistema de tipos estrictos que se escandalice ante las idioteces antes de correr y que el programador es libre de (ab)usar la representación de sus datos a gusto y (ab)usar las reglas de conversión implícita. Se sabe que eso es una mala idea desde el punto de vista de mantenimiento y de seguridad del código, así que se intenta ofrecer herramientas adicionales.
Míralo como herramientas para ayudar a los que no quieren/pueden/saben cambiar sus prácticas, y creen que sus mentes son mejores que un sistema de tipos. Vicio sobre razón.
Hay lenguajes dinámicos con sistemas de tipos débiles, como JavaScript, Python o Perl. No verifican (casi) nada antes de ejecutar, y durante la ejecución verifican algunas cosas, pero también hacen conversiones implícitas (e.g. "42" es cadena o número o booleano o arepa de perico, según convenga).. La cosa es aún peor que en el caso anterior, pues podría haber errores de tipos que no son reportados como tales, pues hay alguna regla del lenguaje que «lo permite».
Esto, por supuesto, hace que la gente ataque el problema construyendo un nuevo problema: hacer suficientes pruebas para «garantizar» que no hay errores de tipos.
Las herramientas como las que mencionas, son herramientas complementarias de análisis estático. El lenguaje principal no va a cambiar en el futuro inmediato, pero se le ofrecen al programador algunos mecanismos para protegerse un poco más. Los mecanismos no son completos, ni sustituyen a un sistema de tipos estático de primera clase, pero son mejores que «escribir pruebas» — por supuesto que estos sistemas también son pruebas, sólo que generadas semi-automáticamente. Estos sistemas no van a prevenir errores de tipos mucho mejor que lo que hace el lenguaje, porque siempre va a venir algún idiota a poner String como tipo... después de todo String es el tipo de datos del pobre.
La idea ni siqueira es «original». Cuando se escribieron los primeros compiladores de C, no había suficientes recursos (RAM/CPU) para hacer todo lo que se podía hacer de verificación. Además, no se sabía lo suficiente de verificación estática y análisis de flujo para detectar errores que hoy en día son simples de implantar en cualquier compilador. Entonces, se inventó la herramienta `lint`: sólo hacía análisis estático de los programas en C, indicando malas prácticas, posibles errores e incluso formas no portátiles presentes en el código. Hoy en día, `lint` no es necesario porque los compiladores de C ya incluyen esas técnicas.
El atractivo fundamental de los lenguajes dinámicos es (para algunas personas), que no hay un sistema de tipos estrictos que se escandalice ante las idioteces antes de correr y que el programador es libre de (ab)usar la representación de sus datos a gusto y (ab)usar las reglas de conversión implícita. Se sabe que eso es una mala idea desde el punto de vista de mantenimiento y de seguridad del código, así que se intenta ofrecer herramientas adicionales.
Míralo como herramientas para ayudar a los que no quieren/pueden/saben cambiar sus prácticas, y creen que sus mentes son mejores que un sistema de tipos. Vicio sobre razón.
Liked by:
Marcos Mora
Rui
Walter Vargas
Ricardo Monascal
Israel
Es cierto lo que dicen que es mejor un mal día programando scheme que un buen día programando c ?
Suponiendo que existe un mal dia programando en Scheme (Racket o Common LISP), es cierto.
https://www.youtube.com/watch?v=5-OjTPj7K54
https://www.youtube.com/watch?v=5-OjTPj7K54
¿No le gusta java ?
Liked by:
Walter Vargas
¿Quiero aprender a desarrollar aplicaciones web que sean escalables con el tiempo y que permitan el manejo de muchas peticiones y registros en base de datos. Que tecnologías me recomienda para empezar a construir aplicaciones web de esta categoría?
Ninguna tecnología, por sí sola, puede garantizar que la aplicación sea escalable con el tiempo. Es más, las Leyes de Amhdal y Gunther *garantizan* que ninguna aplicación puede tener escalabilidad perfecta *nunca*, no importa cuánto dinero le lances a la plataforma.
Así que más allá de una combinación particular de herramientas, tienes que saber medir, via simulación, via pruebas de cobertura, y vía introspección, para construir el modelo de desempeño de tu aplicación. Eso te va a indicar cuando no te queda más remedio que botar código, cambiar de diseño, e incluso de herramientas, porque la aplicación alcanzo su límite de capacidad.
Si el lenguaje de programación que usas no te permite medir, no te sirve; si no tienes idea qué debes medir, tampoco te sirve; si no desarrollaste con transparencia (componentes desacoplados), no vas a poder identificar la causa de los problemas; y si mezclas todas las responsabilidades de la aplicación, no puedes reemplazar componentes. «Bueno, pero yo me puedo hacer esas herramientas que me faltarían...»... eso no va a pasar. Un buen lenguaje de programación se mide, entre otras cosas, por la disponibilidad de esas librerías como parte del «núcleo» del lenguaje, y que el lenguaje esté *diseñado* desde el principio pensando en eso.
Cada problema es diferente, necesitando lenguajes y herramientas diferentes, además de experiencia y comprensión sobre el funcionamiento de dichas herramientas. No se trata de manejar el carro, sino también comprender cómo funciona el motor de combustión interna.
Uso PostgreSQL como base de datos *exclusivamente*. Aprovecho el lenguaje procedural PL/pgSQL, y posiblemente PL/R, para escribir *toda* la lógica de negocios dentro de la base de datos en forma de triggers, tipos especializados, y funciones «set of rows».. Descanso en el sistema de roles y control de acceso de PostgreSQL, porque es mejor que cualquier «módulo de usuarios» que la gente inventa sin necesidad.. De ese modo, la escogencia de lenguaje para la capa de presentación es un problema secundario, porque en realidad todo lo hace la base de datos -- y es mejor así (ya he respondido esto en el pasado).
De tener que escribir algo al frente, Haskell con Yesod, Snap o Servant según me convenga para el problema específico, o bien Perl con Catalyst. Pero eso no cubre todas las posibilidades. Y no hago «front end» — la vida es muy corta.
Así que más allá de una combinación particular de herramientas, tienes que saber medir, via simulación, via pruebas de cobertura, y vía introspección, para construir el modelo de desempeño de tu aplicación. Eso te va a indicar cuando no te queda más remedio que botar código, cambiar de diseño, e incluso de herramientas, porque la aplicación alcanzo su límite de capacidad.
Si el lenguaje de programación que usas no te permite medir, no te sirve; si no tienes idea qué debes medir, tampoco te sirve; si no desarrollaste con transparencia (componentes desacoplados), no vas a poder identificar la causa de los problemas; y si mezclas todas las responsabilidades de la aplicación, no puedes reemplazar componentes. «Bueno, pero yo me puedo hacer esas herramientas que me faltarían...»... eso no va a pasar. Un buen lenguaje de programación se mide, entre otras cosas, por la disponibilidad de esas librerías como parte del «núcleo» del lenguaje, y que el lenguaje esté *diseñado* desde el principio pensando en eso.
Cada problema es diferente, necesitando lenguajes y herramientas diferentes, además de experiencia y comprensión sobre el funcionamiento de dichas herramientas. No se trata de manejar el carro, sino también comprender cómo funciona el motor de combustión interna.
Uso PostgreSQL como base de datos *exclusivamente*. Aprovecho el lenguaje procedural PL/pgSQL, y posiblemente PL/R, para escribir *toda* la lógica de negocios dentro de la base de datos en forma de triggers, tipos especializados, y funciones «set of rows».. Descanso en el sistema de roles y control de acceso de PostgreSQL, porque es mejor que cualquier «módulo de usuarios» que la gente inventa sin necesidad.. De ese modo, la escogencia de lenguaje para la capa de presentación es un problema secundario, porque en realidad todo lo hace la base de datos -- y es mejor así (ya he respondido esto en el pasado).
De tener que escribir algo al frente, Haskell con Yesod, Snap o Servant según me convenga para el problema específico, o bien Perl con Catalyst. Pero eso no cubre todas las posibilidades. Y no hago «front end» — la vida es muy corta.
Liked by:
Luiscarlo Rivera
Carlos Torres
Fernando
Marcos Mora
¿Por qué no recomienda usar PHP?
Porque es un lenguaje con un diseño fallido, con una implantación simplista, cuyo juego de herramientas intrínsecas (debuggers, profilers, analizadores de cobertura, instrumentación, componentización y despliegue) es inexistente o pobrísimo, y porque su evolución es de ensayo y error democrático. Hay que mencionar la tradición histórica de su comunidad en nunca ponerse de acuerdo para unificar esfuerzos en tener abstracciones realmente bien hechas («este framework/librería X es mejor que todos los anteriores porque no copia nada de ellos y lo hice yo»).
Es evidente que hay mucha gente usando PHP y que a una fracción de esa gente le va bastante bien, pero el costo en herramientas adicionales, la cantidad de «partes móviles» para el despliegue, dificultades de desempeño, y las «soluciones» a los problemas con componentes externos, no valen la pena a la luz de la cantidad de lenguajes mejores en esos y otros ejes que con PHP simplemente no se pueden discutir porque no existen. Popularidad y calidad son dos cosas diferentes.
Tratar de arreglar algo que está mal diseñado, sólo lleva a perder tiempo y en tener algo más grande peor diseñado. PHP fue en su momento la respuesta de los que no sabían mucho (por decir algo) de lenguajes de programación en la comunidad de software libre, a la popularidad de otro igual de malo como fue ASP. Pero PHP ha querido «arreglar» algo que desde el principio era una mala idea, agregando malas ideas encima.
Es evidente que hay mucha gente usando PHP y que a una fracción de esa gente le va bastante bien, pero el costo en herramientas adicionales, la cantidad de «partes móviles» para el despliegue, dificultades de desempeño, y las «soluciones» a los problemas con componentes externos, no valen la pena a la luz de la cantidad de lenguajes mejores en esos y otros ejes que con PHP simplemente no se pueden discutir porque no existen. Popularidad y calidad son dos cosas diferentes.
Tratar de arreglar algo que está mal diseñado, sólo lleva a perder tiempo y en tener algo más grande peor diseñado. PHP fue en su momento la respuesta de los que no sabían mucho (por decir algo) de lenguajes de programación en la comunidad de software libre, a la popularidad de otro igual de malo como fue ASP. Pero PHP ha querido «arreglar» algo que desde el principio era una mala idea, agregando malas ideas encima.
Liked by:
Carlos Torres
Walter Vargas
Marcos Mora
Que opina del framework web2py? Ha oido hablar de el?
No lo conozco. Gracias, pero no gracias.
¿Qué fruta comes más a menudo?
Aguacate. Mención honorífica: tomate.
Que opina del framework Django?
The «D» is silent, the struggle is real.
Menciona Ud. la diferencia entre programar y desarrollar. En el mismo espíritu: hay muchas aplicaciones que permiten usar nodos para crear aplicaciones internas al sistema (Blueprint en el motor Unreal). ¿Se úede aprender a desarrollar/programar bien si el objetivo es permanecer en esa esfera?
Blueprints es, por un lado, lo que se conoce como un «lenguaje de dominio específico». No es un lenguaje completo ni para propósito general, porque depende (o «vive dentro») de otro lenguaje. Por definición, un DSL se inventa para «bajarle la barra» a los programadores, acercando el problema de alto nivel hacia el lenguaje. En la mayoría de los DSL, el programador usa las expresiones del lenguaje DSL y del lenguaje anfitrión de manera combinada (es un «deeply embedded DSL». Pero en Blueprints no tienes acceso al lenguaje anfitrión directamente, de manera que es lo que se llama un «shallow DSL» — y los detalles técnicos y formales nos desviarían mucho de tu pregunta..
Por otro lado, Blueprints ataca un problema cuyo detalle es *MUY* complejo y que modernamente está increíblemente abstraído para hacerlo popular (cosa que me parece muy bien, valga decir, siempre que el programador en ese DSL comprenda que sabe muy poco de lo que *realmente* pasa «detrás de cámaras»). Además, lo hace con un estilo mixto de flujo de datos-reactivo-imperativo. Entonces, lo que aprendes a hacer con Blueprint lo puedes trasladar a otro lenguaje embebido siempre que sea similar, pero es poco probable que lo puedas trasladar directamente a un lenguaje de propósito general.
Hechas estas aclaratorias, la respuesta concreta a tu pregunta es que puedes aprender a programar bien con Blueprints exactamente el tipo de cosas que Blueprint resuelve y ninguna otra más. Si sólo te interesa hacer lo que se puede hacer con Blueprints, seguramente irás mejorando tus destrezas con la práctica y experiencia.
No puedo dejar de mencionar que mucha gente piensa que tiene que estudiar Ingeniería en Computación o Informática para ponerse a escribir videojuegos, y la realidad es que no es así. Cine, arte, música, drama, fotografía y letras te preparan mejor para contar historias, expresar ánimos, describir situaciones y proponer interacciones. Hoy en día, las herramientas para construir juegos, como dije antes, «bajan la barra» notablemente — y eso es muy bueno para que se expresen los artistas de juegos de video.
Ahora, si estudiaste Ingeniería en Computación, estudiaste Computación Gráfica (los detalles de implantación, no las herramientas) y Lenguajes de Programación, entonces puedes sentarte a escribir tu propio motor de juegos y diseñarle encima un lenguaje embebido para los artistas. Eso si sería aprender a desarrollar y programar las herramientas base, sobre la cual se apoyen los artistas.
Por otro lado, Blueprints ataca un problema cuyo detalle es *MUY* complejo y que modernamente está increíblemente abstraído para hacerlo popular (cosa que me parece muy bien, valga decir, siempre que el programador en ese DSL comprenda que sabe muy poco de lo que *realmente* pasa «detrás de cámaras»). Además, lo hace con un estilo mixto de flujo de datos-reactivo-imperativo. Entonces, lo que aprendes a hacer con Blueprint lo puedes trasladar a otro lenguaje embebido siempre que sea similar, pero es poco probable que lo puedas trasladar directamente a un lenguaje de propósito general.
Hechas estas aclaratorias, la respuesta concreta a tu pregunta es que puedes aprender a programar bien con Blueprints exactamente el tipo de cosas que Blueprint resuelve y ninguna otra más. Si sólo te interesa hacer lo que se puede hacer con Blueprints, seguramente irás mejorando tus destrezas con la práctica y experiencia.
No puedo dejar de mencionar que mucha gente piensa que tiene que estudiar Ingeniería en Computación o Informática para ponerse a escribir videojuegos, y la realidad es que no es así. Cine, arte, música, drama, fotografía y letras te preparan mejor para contar historias, expresar ánimos, describir situaciones y proponer interacciones. Hoy en día, las herramientas para construir juegos, como dije antes, «bajan la barra» notablemente — y eso es muy bueno para que se expresen los artistas de juegos de video.
Ahora, si estudiaste Ingeniería en Computación, estudiaste Computación Gráfica (los detalles de implantación, no las herramientas) y Lenguajes de Programación, entonces puedes sentarte a escribir tu propio motor de juegos y diseñarle encima un lenguaje embebido para los artistas. Eso si sería aprender a desarrollar y programar las herramientas base, sobre la cual se apoyen los artistas.
Liked by:
Marcos Mora
Eduard Lucena
Algún libro que recomiendes sobre lógica ?
«A Logical approach to Discrete Math», Gries.
¿Que opina del framework Laravel del lenguaje PHP como base para la elaboración de proyectos Web a mediana y gran escala?
No uso PHP. La ayuda que puedo ofrecer a alguien que usa PHP es sugerirle usar otro lenguaje. «Hay mucha gente que usa PHP y le va bien» es la falacia de la fuerza, pero si les permite dormir en la noche, bien por ellos.
¿Cuales son los fundamentos teóricos que debería de tener un programador o Ingeniero de software para no ser uno mas del montón?
Lógica, Matemática Discreta, Algoritmos y Estructuras de Datos (Diseño, Análisis, Comparación y Recursión), Análisis de Lenguajes y Técnicas de Compilación, Algebra Relacional, Algebra de Procesos, conceptos sobre Sistemas de Operación, y Modelos de Análisis de Desempeño.
Es buena idea aprender perl en esta época?
Si aprendes Perl en esta época te vas a sentir mal por no haberlo aprendido antes. Así que, claro.
Liked by:
williams
Libro bueno de java ?
No puedo recomendar ningún libro de Java.
Existe el libro "How to design program" en español?, es que mi ingles es nivel medio
No tengo idea.
Si tu inglés es realmente «nivel medio», no vas a tener problemas con el libro. Si no entiendes el libro, entonces tú Inglés no es nivel medio y tienes que mejorar tu inglés urgentemente. La literatura actualizada y novedosa siempre viene en inglés; si esperas a que esté en español, estás en desventaja en más de una forma.
Si tu inglés es realmente «nivel medio», no vas a tener problemas con el libro. Si no entiendes el libro, entonces tú Inglés no es nivel medio y tienes que mejorar tu inglés urgentemente. La literatura actualizada y novedosa siempre viene en inglés; si esperas a que esté en español, estás en desventaja en más de una forma.
Liked by:
Asdrúbal Iván
Next