Una pequeña lista de los puertos mas conocidos

Estos son algunos de los puertos que quizá debas conocer o con los que debes familiarizarte cuando estás comenzando a desarrollar, algunos no se usan tanto, y desde luego se usan muchos mas.  Pero vale la pena conocer aquellos que son por decirlo de alguna manera «populares».


Puerto Descripción
1 TCP Port Service Multiplexer (TCPMUX)
5 Remote Job Entry (RJE)
7 ECHO
18 Message Send Protocol (MSP)
20 FTP — Data
21 FTP — Control
22 SSH Remote Login Protocol
23 Telnet
25 Simple Mail Transfer Protocol (SMTP)
29 MSG ICP
37 Time
42 Host Name Server (Nameserv)
43 WhoIs
49 Login Host Protocol (Login)
53 Domain Name System (DNS)
69 Trivial File Transfer Protocol (TFTP)
70 Gopher Services
79 Finger
80 HTTP
103 X.400 Standard
108 SNA Gateway Access Server
109 POP2
110 POP3
115 Simple File Transfer Protocol (SFTP)
118 SQL Services
119 Newsgroup (NNTP)
137 NetBIOS Name Service
139 NetBIOS Datagram Service
143 Interim Mail Access Protocol (IMAP)
150 NetBIOS Session Service
156 SQL Server
161 SNMP
179 Border Gateway Protocol (BGP)
190 Gateway Access Control Protocol (GACP)
194 Internet Relay Chat (IRC)
197 Directory Location Service (DLS)
389 Lightweight Directory Access Protocol (LDAP)
396 Novell Netware over IP
443 HTTPS
444 Simple Network Paging Protocol (SNPP)
445 Microsoft-DS
458 Apple QuickTime
546 DHCP Client
547 DHCP Server
563 SNEWS
569 MSN
1080 Socks

Desde luego algunos de estos puertos no se usan de forma obligatoria, los de http o https pueden cambiar, sin embargo los navegadores apuntan por default a estos puertos y si son cambiados se deben escribir explicitamente junto con la dirección IP del servicio al que se está accediendo.

10 consejos para programadores que empiezan, explicados uno a uno

En 2013 publicamos aquí diez consejos para quien empieza a programar, en una lista de una línea cada uno. Más de diez años después siguen valiendo, pero merecen una explicación: qué quieren decir en la práctica y qué ha cambiado ahora que un asistente de IA puede escribir buena parte del código.

Los diez consejos

1. Recuerda siempre lo que te enseñaron tus maestros. Los fundamentos envejecen mucho más despacio que las herramientas. Estructuras de datos, complejidad de los algoritmos, cómo funciona la memoria, qué es una transacción en una base de datos: todo eso servía hace treinta años y seguirá sirviendo dentro de otros treinta. Un framework de moda dura unos pocos años; saber por qué una búsqueda en una lista es más lenta que en un diccionario vale para siempre.

2. No emplees nuevas tecnologías solo porque son nuevas. Cada herramienta nueva trae su curva de aprendizaje, sus errores aún sin descubrir y el riesgo de que deje de mantenerse. En un proyecto real, elige lo que el equipo conoce y lo que tiene una comunidad grande detrás, salvo que la novedad resuelva un problema que de verdad tienes.

3. Pero sí debes probar nuevas técnicas y tecnologías. No es una contradicción con el anterior: el sitio para probar es un proyecto personal o una prueba aparte, no la aplicación de producción. Aprender un lenguaje con otra forma de pensar, como Rust si vienes de Python o Go si vienes de Java, te hace mejor programador también en tu lenguaje de siempre.

4. Lee mucho. Libros, documentación oficial y, sobre todo, código de otros. Leer el código de un proyecto de código abierto bien mantenido enseña más sobre cómo se organiza un programa grande que cualquier tutorial. Y la documentación oficial suele ser mejor y estar más al día que la primera respuesta que aparece en un buscador.

5. No acumules errores ni malas prácticas. Cada atajo que dejas «para luego» es una deuda que se paga con intereses: un nombre de variable confuso, una función de doscientas líneas, un error que se ignora en lugar de tratarse. Arreglarlo cuando lo ves cuesta minutos; arreglarlo meses después, cuando hay código que depende de ello, cuesta días.

6. Comparte tu conocimiento. Explicar algo a otra persona es la mejor forma de descubrir si lo entiendes. Escribir un artículo, responder una pregunta en un foro, documentar bien tu proyecto o contribuir a uno de código abierto te obliga a ordenar lo que sabes, y de paso te da visibilidad.

7. Ten en cuenta la concurrencia. Casi todos los programas actuales hacen varias cosas a la vez: atienden a varios usuarios, esperan a la red o reparten el trabajo entre los núcleos del procesador. Los errores de concurrencia son de los más difíciles de encontrar, porque aparecen solo a veces. Aprende pronto qué es una condición de carrera y cómo se evitan. Tenemos ejemplos en Python, Go y Rust, y uno muy claro en String, StringBuffer y StringBuilder, donde dos hilos pierden datos al escribir a la vez.

8. Prueba tu código. No basta con que funcione la vez que lo ejecutas a mano. Las pruebas automáticas te avisan cuando un cambio rompe algo que antes funcionaba, y te dan confianza para mejorar el código sin miedo. Empieza por lo sencillo: una prueba por cada función importante y otra por cada error que corrijas, para que no vuelva.

9. Cuídate. Programar es un trabajo mental y se hace mal cansado. Dormir, moverse, descansar la vista y desconectar de vez en cuando no es tiempo perdido: muchos problemas que parecían imposibles a medianoche se resuelven en diez minutos a la mañana siguiente.

10. Diviértete. La programación tiene mucho de oficio, y los oficios se aprenden con horas de práctica. Esas horas son mucho más llevaderas si disfrutas con lo que haces. Busca proyectos que te interesen de verdad, aunque sean pequeños: un juego, una herramienta para tu día a día o un programa que automatice algo aburrido.

¿Y con la IA? Los diez siguen en pie, y algunos pesan más que antes. Si un asistente escribe el código, tú tienes que entenderlo, revisarlo y probarlo: los fundamentos (1), las pruebas (8) y no acumular malas prácticas (5) son lo que te permite hacerlo. Escribimos sobre ello en aprender a programar cuando la IA ya escribe el código: diez consejos para quien empieza.

Por dónde empezar

Si estás dando tus primeros pasos, elige un lenguaje y quédate con él el tiempo suficiente para hacer algo útil. En decodigo.com tienes cursos completos y gratuitos de Python, Java, Go y Rust, y una guía de Git para guardar tu trabajo desde el primer día.

Los gurús y el trabajo en equipo

Sin duda, siempre existen personas brillantes que se distinguen por su buen sentido común, curiosidad y capacidad para resolver problemas difíciles. Pero siempre he sospechado que la imagen del gurú está sobrevalorada.

Algunas malas experiencias me dicen que esto podría ser así.  En cierta ocasión, durante el desarrollo de un proyecto mas o menos grande y en una demostración de capacidades, el líder del equipo, que se sabía muy bueno en el desarrollo de software (el gurú), comenzó a utilizar una serie de tecnologías y frameworks de moda para impresionar al cliente y al administrador de proyecto.  Como resultado, los que tenían menos experiencia comenzaron a sufrir con la curva de aprendizaje y se enfocaron mas a conocer las nuevas tecnologías que al modelo de negocio. El desarrollo se terminó con una aplicación robusta tecnológicamente, pero poco amigable para el cliente y por supuesto en mas tiempo del que se esperaba. Un pequeño desastre.

En otras ocasiones, me he topado con el típico personaje que es capaz de resolver problemas difíciles, pero que cuando tienes que dar mantenimiento a su código o simplemente necesitas usarlo, este te parece tan desordenado que te dan ganas de hacerlo de nuevo.

Otro de los riesgos de tener a una persona que tiene todo el dominio sobre cierta tecnología, herramienta o el conocimiento mas crítico de un proyecto, es que puede simplemente irse, con el todo su conocimiento.

Me agradan mas los equipos de trabajo donde los problemas difíciles o algunas decisiones tecnológicas se resuelven entre varios.

Los gurús se equivocan como cualquier otro.

Además, cuando te autoproclamas gurú, puedes quedarte solo a la hora de resolver problemas difíciles.  Creo que no hay necesidad de que esto sea así, porque el criterio para resolver un problema crítico se reduce al de una sola persona y no creo que esto sea muy conveniente.

Cuando alguien te hace una pregunta complicada sobre algún problema o error, es probable que ella misma tenga mas capacidad para responderla, ya que conoce mejor el contexto del problema.  Por lo que mas que tratar de dar una solución es mejor dar un punto de vista o pistas sobre como resolver el problema.

El protagonismo es algo que nos puede seducir a todos, pero yo me lo pensaría mucho antes de adoptar una postura de este tipo. Sobre todo cuando de lo que se trata es hacer mas agradable y profesional tu trabajo.  Desde luego no estoy diciendo que todos los gurús son malos, de hecho también he conocido a algunos muy buenos. Pero son los menos.

Un hábito que recomiendo a todos es que cuando encuentras la solución a un problema difícil, la comentes a tus demás compañeros. Esto permite tener una base de conocimiento colectiva y evita tener que investigar demasiado sobre un problema que ya se ha sido resuelto con anterioridad.

Tómate con calma eso de ser gurú, puedes serlo sin hacer alarde.  🙂

Suele pasar…

Texto sobre fondo gris azulado: «Suele pasar. Llevas horas buscando un error en tu código y cuando comienzas a explicarlo a alguien más para que te ayude… ¡lo encuentras! :)».

«Suele pasar»

Tiene nombre: depuración con patito de goma. Al explicar el código en voz alta, línea por línea, te obligas a revisar lo que das por supuesto, y ahí suele estar el error. Funciona incluso explicándoselo a un patito de goma.

Talento

Texto sobre fondo oscuro: «Para ser un buen programador se requiere 3% de talento y 97% de esfuerzo para no distraerse con Internet».

«Para ser un buen programador, se requiere 3% de talento y 97% de esfuerzo para no distraerse con Internet»

El talento ayuda, pero lo que marca la diferencia es la constancia. Y la mayor amenaza para la constancia está a una pestaña de distancia.

Complejidad

Texto sobre fondo claro: «Controlar la complejidad es la esencia de la programación», cita de Brian Kernighan.

Brian Kernighan, coautor del libro El lenguaje de programación C, resume en una frase buena parte del oficio: dividir los problemas, ponerles nombres claros y evitar que todo dependa de todo.

Debes programar…

Un joven ilumina su cara con la pantalla del portátil, asustado. Texto: «Debes programar como si supieras que el tipo que continuará dando mantenimiento a tu código es un psicópata violento que sabe dónde vives», cita de Martin Golding.
Por si las dudas…

Una forma exagerada de decir algo muy serio: escribe código pensando en quien lo leerá después. Muchas veces esa persona eres tú mismo, seis meses más tarde.