EM Hernández-Novich

Los DNS públicos más populares tienen ICMP activado, de modo que puedes hacer una prueba muy simple con `ping` para determinar cuál tiene el tiempo de respuesta más corto. Ese no es el único criterio, pero es el más accesible para cualquier persona porque `ping` está en cualquier sistema operativo.

---

Las consultas DNS se hacen sobre UDP, así que tu siguiente prueba sería hacer consultas de nombre via UDP para determinar el tiempo de respuesta. Esto tienes que hacerlo por un tiempo considerable, porque la congestión de la red en la cual participas (tu red local, la de tu ISP, la ruta intermedia) afecta. Puedes escribir un script que haga consultas de diferentes nombres (usando `dig`), pero siempre el mismo nombre, para que excluyas el tiempo de consulta que el servidor público tiene que hacer.

---

Los DNS públicos suelen usar la técnica AnyCast para que siempre te atienda el «más cercano, menos ocupado» de un conjunto muy grande. Si bien tus consultas van hacia un IP particular (1.1.1.1, 8.8.8.8, 4.2.2.1) la realidad es que esa consulta se enruta a servidores que tu no puedes escoger, dependiendo del estado actual de la red.

---

Finalmente, la manera en que se consulta a los DNS depende de la librería resolver de tu sistema operativo. El resolver de libc para Linux trabaja diferente que el resolver de FreeBSD, y aunque MacOSX deriva de FreeBSD, su resolver también es diferente. En algunos casos, una consulta se hace al «primer DNS» y se *espera* por timeout antes de intentar el segundo; a veces se hacen tantas consultas como DNS estén definidos y se toma la primera en regresar.

---

Si estás en Venezuela, cualquiera de los DNS públicos tiene más ancho de banda que TODO el ancho de banda de Venezuela sumado, así que el cuello de botella siempre va a ser tu ISP en Venezuela.

---

Es mucho más eficiente tener un caching resolver en tu red local que haga forwarding a los públicos. Si no tienes red local, sino que llevas tu portátil de red en red, lo mejor es instalar un caching resolver en tu máquina.

---

En el estado actual de las cosas, 1.1.1.1 es muy superior a 4.2.2.1 y 4.2.2.2, que son marginalmente mejores que 8.8.8.8. Hay criterios adicionales: por ejemplo, si te interesa que hagan verificación DNSSEC, o si quieres DNS sobre TLS -- en ese caso tienes que probar esas cosas por tu cuenta ajustado a tus necesidades de validación.

View more

FreeBSD.

---

Es el más refinado al lado de OpenBSD o NetBSD, el libro que lo acompaña es muy completo, y es la base sobre la cual MacOSX montó su «dry wall tecnológico», así que ayuda a entender mejor lo que en principio, hacen las máquinas Apple detrás del maquillaje.

---

Debian es mucho más amplio en variedad de paquetes, consistente en configuración, estricto en control de calidad, rico en herramientas para extender la distribución, y disponible en más plataformas de hardware. Encima, Linux tiene mucho más y mejor soporte nativo para dispositivos de hardware que lo que ofrece FreeBSD.

---

Siempre escojo Debian. Usé FreeBSD porque era la plataforma presente en dos de mis clientes, y en el alcance del trabajo no estaba cambiar la plataforma. Se puede discutir si `iptables/ipset` es mejor (o no) que `pf`, pero es necio: el que sabe construir firewalls, los hace con cualquiera de los dos sin problemas, y el que sabe ajustar el stack TCP para mejorar el desempeño, lo hace por igual en el kernel Linux o el de FreeBSD siempre que lea la documentación.

View more

El canal principal es público, en el sentido que todo el mundo escribe al mismo tiempo, y puedes leer todo lo que ocurre. Eso favorece que el recién llegado observe cómo es el intercambio antes de participar.

---

Si dos usuarios se ponen de acuerdo, pueden mantener una conversación privada. Cualquier cliente IRC ofrece alguna forma de mantener esa distinción: los clientes para interfaz gráfica te pondrán una ventana separada, mientras que los clientes sólo texto utilizarán un color diferente o una marca de texto especial para que diferencia el mensaje privado.

---

En general, es muy mala educación pedir conversación privada de entrada. Mucha gente ni siquiera te va a contestar, mientras que otros te van a «ignorar activamente» indicándole a su cliente que no quieren saber nada de ti ni privado ni público.

---

También es posible tener canales en los cuales puedes leer todo, pero sólo puedes hablar si te dan permiso (tener «voz»). Esto sirve para coordinar reuniones.

---

https://wiki.debian.org/GettingHelpOnIrc

View more

JavaScript es la más reciente re-implementación imperativa e incompleta de LISP. Pasa en todas las generaciones, y continuará pasando.

---

Para entender las cosas que hacer JavaScript, tienes que entender cómo funciona un lenguaje funcional interpretado (puro o de máquina virtual), que tenga clausuras léxicográficas, y continuaciones. LISP hace *todo* lo que JavaScript trata de hacer, pero de manera más consistente y ordenada... desde hace 30 años. Pero como tiene muchos paréntesis debe ser «feo» o «raro» y por eso la gente se la pasa reinventándolo parcialmente (y mal).

---

No creo que haya una materia que te enseñe eso en la USB, porque el énfasis en lenguajes funcionales, es en aquellos que son disciplinados y con tipos fuertes. Además, no se estudia la implantación.

---

Aprende a usar Racket, aprende a usar continuaciones (para hacer excepciones, co-rutinas, hilos, evaluación parcial, e invocación asíncrona), y luego mira la implantación de Racket. Eso te enseñará cómo se implanta un lenguaje con esas características, y podrás construir tu propia opinión en cuanto a la imitación que JavaScript hace al respecto.

---

LISP es un lenguaje que tienes que explorar para poder pasar al siguiente nivel «aha» de cómo funcionan las cosas. Uno de los efectos es que comienzas a darte cuenta de la farsa que son muchos lenguajes dinámicos modernos, demasiado tímidos para imitar a LISP como se debe, pero demasiado valientes para decir que «lo tienen todo».

View more

Puede que sea correcto en casos muy específicos, pero a la larga termina siendo peligroso. El problema de almacenar Unix Epoch es que te falta la información de zona horaria, para poder corregir según la región en la que estás y tomar en cuenta segundos bisiestos y otros detalles. Si agregas la zona horaria a la época, estás trabajando de más por no usar cosas mejores.

---

Si vas a guardar una fecha en un campo de base de datos (que es PostgreSQL), la manera más conveniente es TIMESTAMP WITH TIMEZONE, para luego aprovechasrlas funciones para manipulación de fechas de PostgreSQL (que son mejores que las de cualquier lenguaje por delante), para extraer la forma particular de representación que necesites, en particular Unix Epoch.

---

Si sólo te interesa almacenar una fecha en una bitácora, lo que sea equivalente a ISO-8601 con zona horaria, i.e.

---

$ date --iso-8601=s
2018-05-04T20:04:28-07:00

---

Es trivial hacer un parser, el orden lexicográfico coincide con el orden numérico, y tienes todo el contexto necesario para hacer correlación temporal.

---

Finalmente, el Unix Epoch es de 32-bits, así que en el 2038 vas a tener problemas.

View more

Inglés y español.

---

Haskell
Perl
Prolog
C
Erlang
C++
Smalltalk
LISP - Scheme - Racket - Common LISP
Standard ML
LaTeX
Octave
R
PL/pgSQL
Shell Unix (el estándar, porque si se complica voy a Perl)
Povray
LOGO

---

Conozco muchos otros lenguajes de programación (eso es lo que hago). Los pruebo hasta el punto en que no me enseñan nada nuevo, son aburridos, o evidencian su rancho, y así me doy cuenta que no sirven para mis propósitos o atentan contra mis capacidades. También están los lenguajes que son para explorar nuevos conceptos (como Agda, Coq o Idris), pero que no voy a usar en la práctica.

---

Cosas como

---

Ruby
Golang
Rust
Elixir

---

son cuchis, pero no aguantan el aguacero. Del resto, que ni los nombro, prefiero que sea otro el que tenga que escribirlo, porque la vida es muy corta.

---

De todas formas, más importante que los lenguajes que conozco es el hecho de que estudié cómo funciona cualquier lenguaje. Hay lenguajes que uso hoy, que no existían cuando estudié, pero que me resultaron accesibles rápidamente porque: estudié compiladores, estudié los estilos de programación declarativa, y estudié teoría de la computación.

---

Un buen programador de Fortran va a programar Fortran en cualquier lenguaje. Y eso es malo. Pero peor aún es un programador que sólo sabe usar un estilo de programación y cree que hay UN sólo lenguaje de programación que sirve para resolver todos los problemas. No seas ese programador, porque vas a quedar para «echar código» hasta aburrirte, pero te perderás de resolver problemas con menos esfuerzo expresando las soluciones con más claridad.

View more

A weakly typed language like Perl, where there are only three types (scalar, array and map), where a scalar can be a number, a string, a reference, or a file-handle; an array can become a map, or viceversa; and you can use globs to manipulate the symbol table, requires a thorough test suite written on top of an equally thorough test harness provided by the language. If the language provides instropection, and you use it in the «duck typing» or «interface» way, it becomes even harder.

---

Look at the Test:: module hierarchy for Perl and try to fathom how seriously testing is done. In fact, the TAP format and the test harness architecture many «modern» languages provide, is nothing more than an adaptation of what Perl has been providing since the early 1990s.

---

For a dynamic language with reasonably strong types, like Racket or Common LISP, you need to program defensively and follow a set of practices as described in both SICP and HtdP that apply to pretty much all modern LISP-wannabes like Ruby, Python and JavaScript.

---

Don't take me wrong. Dynamic languages with relaxed typing are great for many things and I use them a lot, but they become a liability when working in complex systems. No development team is better at catching mistakes than a good static strongly-typed language; the team is only going to work harder and never converge to the coverage a good compiler provides.

View more

Type Driven Development > *

---

Just use a static strongly-typed language or bust.

---

The compiler will catch WAY more errors (both the idiotic and the «oh wat?» kind) and it's cheaper than Test Driven Development. The testing can be split for pure and non-pure parts. For the pure parts, choose a language that provides what Haskell's QuickCheck provides. For the non-pure parts, use invariant-based strongly-typed testing if you've got it, or plain old unit tests -- this is Behavior-Driven on steroids.

---

Leave the testing to the compiler. People writing compilers are way better and telling you what you did wrong in your code. And in your tests, which are just more code you wrote thinking you got all the corner cases.

---

By the way, do you test every exception is thrown when it should, even asynchronously, and simulate «every bad thing» that could go wrong when you run your program? I didn't think so. Chose a language where you can do that with tests easily without having to write specially crafted tests every time -- I can do that with Racket, Perl and Haskell.

---

But since Haskell is oh so hard, and Perl is oh so ugly, and Racket is oh so old, people prefer to spend their (sad) day writing tests and adding tests for every bug... «It is what it is» for many colleagues.

View more