¿Qué password manager usas? O qué usas en su lugar?
KeePass
¿Por qué si systemd rompe tanto con la filosofía de "do one job and do it well" fue adoptada por las distribuciones? ¿Crees que ya no hay vuelta atrás? ¿Cómo crees que evolucionará?
Porque quiere hacer muchas cosas, y no las hace bien. Sin ir más lejos, en áreas en las cuales tengo mucha experticia (resolución de nombres), el resolver provisto por systemd tiene un diseño incorrecto, hace suposiciones inocentes, y exhibe una ignorancia profunda en relación al funcionamiento del resolver. Encima, los autores dicen que lo que ellos hicieron es mejor porque «simplifica» la complejidad de un resolver.Necios y soberbios.Ha sido adoptado por las distribuciones por muchas razones. Una razón es que el ambiente de escritorio más popularizado depende de systemd para muchas cosas -- eso es otro ejemplo de diseño peligroso. Si combinas eso con la democracia, tienes la receta para lo que está pasando.Creo que tendrá que mejorar mucho, que habrá una fase de adaptación, y que sus desarrolladores van a tener que prestar atención a la experiencia. No es la primera vez que un equipo impetuoso, inexperto y aventurero, introduce un fork o un proyecto que «es mejor porque es nuevo y revolucionario» y luego termina siendo absorbido por la experiencia que, sin prisa, pero sin pausa, los pone en su lugar.La evolución requiere de errores y experimentación para que el más apto se perfeccione. En todo caso, hay que estudiarlo muy bien para poder criticarlo, alejarse de las partes muy malas (como el resolver) y ser precavido de las partes no tan malas. Hay ideas que son interesantes (como por ejemplo, los generadores) pero que tienen una implantación relativamente frágil.En un sistema sin ambiente de escritorio, se puede quitar buena parte de las cosas malas y quedarse con lo esencial.
¿Qué lenguajes considera usted necesarios y saber por qué para tener una carrera exitosa como desarrollador? (Sabiendo que hay que estar en constante aprendizaje en un ambiente tan cambiante como este, que no va a recomendar lenguajes "populares" y que el éxito depende más del programador que del le
Tienes que saber usar lenguajes imperativos y declarativos. Tienes que saber usar el esitlo funcional, el estilo lógico, el estilo reactivo, el estilo orientado a objetos jerárquico, y el estilo orientado a objetos no jerárquico.Para eso tienes que usar todos los lenguajes que puedas, aunque no los vayas a usar profesionalmente. Los lenguajes que domino hoy, no existían cuando estudié; si me hubiera quedado con los que me enseñaron cuando estudié, hoy no podría trabajar. Afortunadamente, decidí aprender cómo funcionan los lenguajes (cualquier lenguaje) en lugar de quedarme con aprender a usar algunos lenguajes. Eso me permite aprender cualquier lenguaje mucho más rápido, comprender sus fortalezas y debilidades, y adaptarme más rápido que alguien que sólo conoce lenguajes, básicamente porque comprendo cómo se hacen y no hay «sorpresas».Aprende a usar la versión moderna de LISP (Racket), aprende a usar Smalltalk, aprende a usar C, aprende a usar un lenguaje ensamblable detestable (Intel) y uno hermoso (MIPS, Sparc), aprende a usar Haskell, aprende a usar todo lo que puedas.Es muy peligroso ser un programador que sólo sabe usar un lenguaje que aprendió por ejemplos pero que no sabe cómo funciona internamente. Aún más peligroso es un programador que cree que sólo con un lenguaje puede escribirlo todo.
Como podr'ia implementar un predicado que se cumpla si un elemento no es miembro de una lista, sin usar cut, fail, \+ ..
Los predicados «triunfan» o «fracasan». Así, para hacer un predicado que triunfe si un elemento no está contenido en una lista, es necesario revisar todos los elementos de la lista. Una solución directa y de mentalidad imperativa, seríais_not_in(_,[]).is_no_tin(E,[P|R]) :- E \= P, is_not_in(E,R).La primera respuesta al consultar este predicado siempre será correcta. No obstante, en virtud del backtracking, la segunda respuesta podría ser incorrecta. Se puede argumentar que no tiene sentido pedir otra respuesta, cuando ya se ha revisado toda la lista, de modo que sería un caso perfecto para incluir un «cut verde», pues la respuesta es única, en cualquier caso de uso. Así, si sólo puedo usar ISO Prolog sin cuts, esa es la mejor solución posible, y es responsabilidad del programador usar ese predicado correctamente aguas arribas; y con correctamente quiero decir usar un «cut rojo», que es muy mal estilo.Ahora bien, hecho el análisis anterior, puede argumentarse que sé exactamente lo que estoy haciendo, así que podría utilizar el predicado ->/2. El que no sabe, lo llama «if-then-else», pero en realidad se llama «soft-cut», pues incluye un «cut verde» implícito después de la primera decisión.Así, quedaríais_not_in(E,L) :- (L = {} -> true ; L = [P|R], E \= P, is_not_in(E,R)).que sólo ofrece una respuesta, siempre correcta, pues el backtracking queda anulado en virtud del «cut verde» implícito.El predicado ->/2 no forma parte de ISO Prolog, pero es una extensión común en GNU Prolog y SWI Prolog. Extensión que usualmente prohibo en mis cursos porque necesito estar seguro que saben usar un «cut verde».
Cuáles son las formas más rápidas de procesar una gran cantidad de datos (con una sola pc)?
Dividir el trabajo en tantos grupos de tamaño similar de cómputo, como núcleos tengas, multiplicado por el factor derivado de la latencia del sistema de I/O.Por ejemplo, si tienes dos núcleos y todo cabe en RAM, entonces no puedes tener más de dos hilos de cómputo, porque el problema es CPU-bound. Si tienes dos núcleos, pero tienes que ir leyendo/escribiendo hacia disco, entonces quizás puedas tener cuatro y hasta seis hilos de procesamiento, porque el I/O es mucho más lento, y un hilo puede sacar cuentas mientras otro hilo espera por el sistema operativo para leer/escribir.Si los cálculos son más o menos iguales para cada conjunto de datos, generalmente es suficiente. Pero si los cálculos son notablemente diferentes por «razones», entonces tienes que usar la creatividad para particionar el problema -- no hay recetas.Si los cálculos son vectorizables, entonces te conviene utilizar un GPU, y aprender a programar computadoras que son diferentes a las computadoras generales. Un GPU tiene centenares (o miles) de CPU especializados que ejecutan la *misma* instrucción sobre *diferentes* datos simultáneamente -- requieres un estilo de programación especial para que los algoritmos sean eficientes allí.Hay muchos libros de programación concurrente y paralela que puedes encontrar por allí, además de tener una buena base en sistemas de operación para analizar los cuellos de botella (CPU, I/O, caché, etc.).
Quiero aprender smalltalk, creo que puede ayudarme a entender mejor POO porque de allí se originaron muchos conceptos que están en los lenguajes modernos. Hay como mil implementaciones distintas: Dolphin, Pharo, Squeak... Cuál me recomienda?
Uso GNU Smalltalk para enseñarapt install gnu-smalltalk gnu-smalltalk-docSupongo que Squeak también estaría bien. No conozco ninguno de los demás.Ahora bien, Smalltalk no es exactamente origen de la programación orientada a objetos (el origen es Clu). Se encargó de asentar varios términos y organizar varias experiencias de programación. Sin duda alguna, es el punto de inflexión hacia lo que la mayoría de la gente comprende como Programación Orientada a Objetos hoy en día.Smalltalk te muestra los conceptos de programación orientada a objetos *jerárquica* y sin herencia múltiple (la tuvo alguna vez). Ese estilo de programación tiene unas cuantas limitaciones que aparecen en problemas prácticos, y que se han resuelto mucho mejor con Orientación a Objetos No-Jerárquica basada en roles y composición horizontal. Entonces, una vez que hayas aprendido los conceptos de Smalltalk, sería bueno que aprendas Common LISP Object System, para completar aspectos como despacho múltiple, roles, delegación parcial, y métodos genéricos.
Me tienen sin cuidado. Sólo uso y ayudo a perfeccionar .deb, porque no tengo tiempo para andar mirando mutantes. A menos que sea Mystique...
¿Qué opina de Mojolicious como reemplazo de CGI?
Mojolicious hace mucho más que el venerable CGI.pm, pero mucho menos que Catalyst. Habrá quien argumente que es más fácil aprender Mojolicious que Catalyst, y eso es verdad, pero también es verdad que Mojolicious no llega (ni pretende llegar, al menos hasta ahora) a la flexibilidad de Catalyst.Para alguien que quiere aprender a hacer aplicaciones web sencillas con Perl, me parece un buen punto de partida. Para los que usan Catalyst y les parece que es demasiado complejo para el problema que están atacando, me parece un buen compromiso.
¿Te fuiste demasiado?
Estoy haciendo algunas escalas productivas.
What did you have for breakfast today?
Home-made banana oat-meal blueberry pancakes with bacon infused maple syrup, pomegranate juice, and two squares of 87% dark chocolate.
Tengo en una gran duda sobre si volver a la universidad y terminar la carrera (ing de sistemas ), la deje en 4to semestre pero me retire porque la calidad de la institución es muy mala, tengo claro que tener un título es un agregado importante para diferentes situaciones (para algunos trabajos, tram
Si quieres emigrar u obtener un trabajo de alto perfil, un título facilita las cosas. Si quieres aprender, entonces sigue estudiando por tu cuenta.Conozco muchas personas que aprendieron informalmente, y acumularon tanta experiencia, que el título no les hace falta. Pero no son la mayoría.Conozco muchas personas que aprendieron formalmente, y su título es más un certificado de constancia que de destrezas. Pero no son la mayoría.Al final, tú eres lo que hagas de ti mismo, título o no, y el trabajo que te guste hacer lo harás en el lugar donde haya espacio y se reconozcan tus habilidades.En última instancia, si no sabes decidir, puedes usar probabilidades. Lanza una moneda al aire para decidir si quieres o no quieres volver a la universidad:cuando la moneda esté en el aire dando vueltas, sabrás exactamente lo que quieres hacer.
El libro «Security Engineering» de Ross Anderson es lo mínimo. Si tu interés va más hacia la criptografía, entonces sigue con «Applied Cryptography» the Bruce Schneier.Si quieres ser realmente mole^H^H^H^Hbueno, estudia Programación Neurolingüística, Lenguaje Corporal, Micromovimientos, y un poco de Psicología: saber quién es manipulable y cómo es manipulable, permite evaluar mejor los riesgos y ponerte en posición de ventaja en escenarios de intercambio de datos (digitales o no). Eso implica que además tienes que estudiar Etica (y posiblemente defensa personal).
Qué le recomiendas a alguien que dejó la carrera en la USB en Algoritmos 2, Discretas 3 y Operativos. Para aprender lo importante que le faltó (Redes, Lenguajes, Bases de datos, etc), suponiendo que su opción es iniciar Ing. de Software con un enfoque muy fuerte hacia la gerencia con C# y Java
Para la parte de bases de datos te sugiero que estudies PostgreSQL, el diseño objeto-relacional, y la construcción de aplicaciones 100% dentro de la base de datos. En el mismo tópico, que no pierdas tiempo en explorar NoSQL ni cualquiera de las «novedades» que inventan los que no saben usar SQL o no saben que PostgreSQL puede operar con JSON eficientemente. Tampoco pierdas tiempo con MySQL.En cuanto a lenguajes, si tu deseo es trabajar en el ámbito «corporativo» con los lenguajes «corporativos», ojalá no lo hiceras, porque es sumamente frustrante. Ojo que también es frustrante el ámbito «de moda» con los lenguajes «populares».En todo caso, es importante que aprendas todos los lenguajes que puedas y cubriendo todos los estilos de programación.La programación orientada a objetos no-jerárquica (es decir, ni Java, ni C#) es mucho más flexible para construir sistemas complejos; puedes explorarla con Smalltalk, CLOS, Perl 5 Moose o Perl 6, y en un nivel menos exquisito con Ruby y Python.Un tópico de moda es «machine learning» y «data science», en particular porque se pueden hacer muchas cosas con Python y hay mucho código para hacer copy&paste de internet. No lo hagas. En primer lugar, para hacer prototipos de ML es *muchísimo* más eficiente usar lenguajes como Octave o R (este último incluso corre *dentro* de PostgreSQL), y si necesitas altísima velocidad, lo escribes en Julia.El futuro inmediato de la programación concurrente y paralela es el uso de construcciones funcionales. Tienes que aprender programación funcional lo antes posible, de lo contrario vas a perder la carrera. En este sentido, mi recomendación es que vayas «all in» y aprendas a usar Haskell y Erlang. Hay montones de lenguajes que dicen ser funcionales porque tienen funciones de orden superior y algunas construcciones funcionales tradicionales, sin embargo en su núcleo son lenguajes imperativos: eso, aunque útil, no es programación funcional verdadera (no importa lo lindo que se lea en el blog). Una vez que los aprendas, o progresas usándolos en serio, o regresas a los lenguajes imperativos y tratas de aplicar las técnicas funcionales hasta donde te alcance la cobija.Dedícale algún tiempo a aprender Prolog. Aún si no vas a trabajar en procesamiento de lenguaje natural, sistemas expertos, ni de inferencia, la manera de organizar un problema en Prolog tiene cierto parecido con la manera de organizar consultas en SQL. Transforma tu manera de pensar acerca de algunos problemas centrados en datos y no en transformaciones.En todo caso, tienes que mantenerte estudiando y probando nuevas cosas todos los días.Nunca he servido ni serviré para ser gerente de nada, mucho menos para supervisar un equipo de desarrollo, así que no tengo nada que comentar al respecto. Pero si experimenté ser parte de un equipo donde el gerente no sabía ni de lo técnico, ni de lo humano, y fue una experiencia muy desagradable (para el gerente).
Dice que no es bueno confiar en teléfonos Apple o Android con firmware stock. Qué teléfono usa usted y cómo modificó el firmware para poder confiar en él.
No uso dispositivos Apple porque son un descarado «vendor lock-in with forced updates». Tengo una MacBook asignada por el trabajo, a la cual le instalé Debian GNU/Linux y listo.No uso teléfonos Android con firmware stock *de fabricante* ni de *operadora*. Esto es, no uso no recomiendo Samsung ni LG, ni aquellos que tienen firmware de Movistar, T-Mobile, etc. porque además de un montón de aplicaciones inútiles y sospechosas, tienen un «final de vida» anticipado para obligarte a comprar el más nuevo.Sólo uso teléfonos Android con el firmware puro y simple directo desde Google (como el Nexus 6 que tengo en la mano), o aquellos en los cuales puedo instalar Cyanogen (como algunos Samsung que tuve en el pasado). Cómo ya pasó mi interés por instalar firmware en teléfonos, el próximo teléfono será, naturalmente, un Google Pixel.
No lo aprendas porque alguien lo dice, pero cuando lo aprendas, asegúrate de decirlo siempre.Cada quien aprende las cosas porque le causan curiosidad, le hacen mejor persona, le hacen mejor profesional, y le permiten mantenerse descubriendo.Sí a estas alturas no estás trabajando con programación funcional, estás llegando a la fiesta y se acabaron los tequeños. Aprender Haskell (e Idris) te hará apreciar mejor lo que es la programación funcional completa, y te abrirá los ojos a maneras mucho mejores de hacer las cosas que en los «lenguajes industriales».Yo lo aprendí porque no hacerlo habría sido incivilizado.
Buenas noches, profe.
Me tocó emigrar por la situación en Venezuela.
No pude terminar la carrera (Ing. en Computación) en la USB por los paros y protestas (sólo pude completar once trimestres).
¿Podría darme algún consejo? Por favor.
Reserva parte de tu tiempo libre para continuar aprendiendo, con disciplina, tanto lo que te interesa como lo que necesitas.La mejor manera de aprender es haciendo cosas fuera de tu área de confort. Instala Debian por tus propios medios, prepara un ambiente de trabajo, explora tópicos, lee, organiza tus ideas en un blog (que tú mismo instalas en tu máquina).En la vida, el uso del cerebro no es opcional. Descubre y ayuda a descubrir.
¿Nombres de tablas de base de datos en plural o singular?
Singular casi siempre. Sólo uso plural en los detalles que a su vez no tienen detalles y nunca se consultan individualmente. Pero cada vez lo hago menos.
Que recomienda para empezar a aprender Prolog?
Prolog es un lenguaje muy simple, así que cualquier libro o tutorial que encuentres en línea te va a servir para aprender la sintaxis y los predicados estándar.La diferencia en el estilo de programación es lo que resulta difícil para algunas personas, particularmente si están viciadas por el estilo imperativo. En Prolog no se escriben «procedimientos», ni «rutinas», ni «funciones»; se escriben predicados que deben comprobarse. Entonces tienes que pensar en los problemas como una serie de relaciones entre valores, en lugar de transformaciones sobre esos valores, o (peor aún), «pasos» para calcular el resultado. Uno no «llama» los predicados en Prolog, «pasándole» argumentos; solicita comprobarlos.Cuando enseño Prolog invierto mucho tiempo en explicar los predicados member/2 y append/3. Son predicados cuyo uso «obvio» es fácil de explicar, pero sus usos alternativos, consecuencia del comportamiento del lenguaje, son complicados de apreciar de primera mano. Es muy importante comprender por qué se puede usarmember(42,[23,69,42])para determinar si 42 es miembro de la lista o no, pero más importante es comprender por quémember(X,[23,69,42])tiene *tres* demostraciones, cada una de las cuales instancia X con 23, 69 y 42, respectivamente, usando exactamente la misma definición. Ser capaz de escribir predicados como member/2 es lo que identifica al programador Prolog.Por otro lado, tienes que saber aplicar al menos dos técnicas de estructura para tus programas: la técnica generar-probar y la técnica de búsqueda controlada. En ambas técnicas juega papel fundamental el backtracking que provee el lenguaje, y necesita que el programador sea astuto en cuanto a «no generar de más» y «no recortar de menos».Estas cosas se aprenden mirando ejemplos, suponiendo que ya tienes base de conocimiento sobre algoritmos como DFS, BFS, A*, y técnicas de programación dinámica o greedy.Finalmente, hay ámbitos en ciencias de la computación en las cuales Prolog tiene mucha ventaja, precisamente gracias a que es homoicónico, provee backtracking, y el parser es modificable por el usuario con razonable flexibilidad. Esto permite que sea mucho más fácil de aplicar a reconocimiento de lenguajes ambiguos, creación de sistemas expertos basados total o parcialmente en sintaxis, problemas de búsqueda con manipulación simbólica (MiniMax Alpha-Beta para juegos, exploración de árboles/grafos dinámicos muy grandes o infinitos), y creación de pequeños lenguajes embebidos en Prolog para expresar problemas de búsqueda o configuración.Hay muchos ejemplos introductorios a Prolog en mi página académica para el curso CI3661 que sirven de complemento a la lectura de libros y tutoriales, así como la práctica, que puedes comenzar con «99 Prolog Problems»
¿Qué recomiendas para aprender sistemas distribuidos?
Trabajar con sistemas distribuidos.
En el aula nos conocimos,
en una oficina compartimos y
en muchos eventos coincidimos.
Gracias por compartir tus conocimientos
que se han convertido en mis cimientos
donde quiera que me lleva el viento
En el mas puro contexto de esa sagrada relación entre alunmo y maestro: Gracias.
Gracias por tus amables palabras. Se hace lo mejor que se puede con lo que se tiene.Ahora es tu turno de continuar la tarea de compartir y multiplicar el conocimiento.
Si defino una aplicación web con Yesod y persistence, ¿estoy renunciando a usar procedimientos almacenados y definir detalladamente mi esquema en PostgreSQL?
Depende como uses las herramientas.La manera adecuada de construir una aplicación sobre PostgreSQL es que puedas mantener los datos sólo con INSERT, UPDATE y DELETE, y todas las consultas se hagan con SELECT o SRF (set returning functions). Nada más. Si lo haces así, quiere decir que el lenguaje para desarrollar los Front-end es irrelevante, como debe ser, porque la lógica de negocios está toda controlada por la base de datos, usando el mejor lenguaje posible (SQL, PL/pgSQL).Si toda la lógica está dentro de la base de datos en forma de triggers, vistas, SRF, y lanzas excepciones cuando se violan las reglas del negocio, puedes usar persistent para hacer las consultas y Yesod para los controladores, y no tener nada de lógica de negocios en la aplicación. Eso es lo que yo haría.Hay gente que escribe toda la lógica de la aplicación en el lenguaje del frente (y a veces en dos lenguajes, porque el rancho es una actitud), usando a PostgreSQL como si fuera un manejador de archivos que habla SQL. Eso está mal incluso si el lenguaje del frente es Haskell. No seas esa gente
«Led Zeppelin II», Led Zeppelin «Dark side of the moon», Pink Floyd «Trick of the tail», Genesis «Childhood's End», Témpano «Close to the edge», YesHonorary mentions«Meddle», Pink Floyd «Hot Rats», Frank Zappa «Misplaced Childhood», Marillion