Voy a suponer que necesitas un pedazo de código que «resuelva el problema X», usas tu buscador de confianza, y descargas el fragmento más «popular» que encontraste. Dá lo mismo si el pedazo de código es para un lenguaje de programación que crees dominar a fondo, o de un lenguaje nuevo para ti.

---

Si no se te ocurrió cómo escribir la solución al problema por ti mismo, lo más probable es que todavía no tengas comprensión completa del problema, y por eso no lo puedes atacar. Por extensión, cualquier pedazo de código que encuentres que es popular porque presuntamente resuelve el problema, para ti seguirá siendo inescrutable prima facie.

---

Si no entiendes cómo hace lo que hace, es posible que haga más cosas de las que necesitas, o que haga mal lo que necesitas en determinadas condiciones (que, por Murphy, son las tuyas). Mientras más complejo es el fragmento de códico que copias, aún mayor el riesgo.

---

Entonces, está bien que busques ejemplos de código que te permitan comprender mejor el problema que estás tratando de resolver. Sin embargo, es un riesgo usarlo sin comprenderlo. Mucha gente lo hace porque quiere «resolver» y no presta mayor cuidado a las consecuencias para con su propio equipo de trabajo, ni para con sus usuarios. Es una cuestión de ética.

---

Es preferible que estudies el fragmento hasta entenderlo, y luego lo expreses usando tu propio estilo de programación. Eso es evidencia que entendiste lo suficiente del problema, como para expresar esa solución. No hay nada de malo en imitar una solución ajena después de comprenderla; después de todo, eso es lo que uno hace cuando lee, imagina, y manifiesta su propia creatividad.

---

En relación a copiar librerías o aplicaciones posiblemente consolidadas, y con una historia evidente de integridad y éxito, asegúrate que sean Software Libre, copia, usa, aprende, y redistribuye.

View more

Programar es ser capaz de expresar la solución a un problema, de manera que se aproveche efectivamente el lenguaje de programación empleado y, quizás mucho más importante, otra persona pueda entender lo que estás tratando de hacer. Esa persona muchas veces eres tú en el futuro.

---

Para eso, tienes que tener dominio del idioma en el cual recibes la definición de los problemas. Sea español, inglés, o cualquier otro idioma. Porque si no eres capaz de comprender la especificación, y hacer las preguntas adecuadas, tu programa no será una solucion completa. Para dominar un idioma, tienes que leer y escribir, con buen vocabulario, mejor gramática, y efectivamente. Nuestra inteligencia está limitada por los conceptos abstractos que podemos imaginar, y la capacidad de convertirlos en una historia. Lee y escribe, de todo. Escuchar historias acompañadas de imágenes explícitas no es lo mismo que leer una historia y construir imágenes mentales. Saber contar una historia es la destreza fundamental que demuestra la inteligencia.

---

La única forma de saber que se domina un tema, es ser capaz de explicárselo a cualquier persona, con cualquier nivel de preparación, y lograr que haya aprendizaje proporcional. Escoge el tema que te interesa, estúdialo, y trata de explicarlo a otra persona: repite hasta que la otra persona entienda. Haces eso con los temas que te interesen, y te irá bien.

---

Si bien vas a comenzar por aprender algún lenguaje de programación, probablemente el «popular» en tu entorno o sugerido por otros, o «el futuro del desarrollo» (ja ja ja) es importante que aprendas varios lenguajes de programación. Con diferentes estilos de programación: imperativo, declarativo lógico, declarativo funcional, reactivo. Eso mejora tu manera de enfrentar los problemas, de la misma forma que tener mejor vocabulario te permite expresar ideas complejas de forma sucinta.

---

Para que tus programas sean mejores, tienes que estudiar la técnica. Eso se logra estudiando y practicando estructuras de datos, algoritmos, y cualesquiera conceptos en el área de interés, por ejemplo, programación paralela y concurrente. Muchas veces, la mejor solución para un problema no es obvia, pero alguien ya la encontró y está en un libro. Es más importante saber cuál libro, que improvisar.

---

Así, programar es escribir un discurso en algún lenguaje de programación. Con el paso del tiempo, encontrarás formas que son subjetivamente mejores que otras, según tus capacidades, y métodos que son objetivamente mejores que otros, según su base técnica. La manera de abandonar lo subjetivo por lo objetivo es tener experiencia, y eso sólo se logra invirtiendo tiempo: leer mucho, equivocarse mucho, aprender cosas difíciles porque terminan siendo mucho mejores que las fáciles, y no teniendo miedo a huir de la comodidad de las chuletas.

---

Si estás buscando una receta corta para programar bien, me temo que después de casi 40 años programando, no la conozco. Escribe programas, lee e insiste -- es divertido.

View more

Para mi es una necesidad, considerando el tipo de control que quiero tener sobre la red. La mayoría de los firmwares «de caja» suelen tener limitaciones impuestas por las regulaciones de la FCC en USA, sin contar deficiencias de seguridad o desempeño que no habían sido detectadas cuando se ensambló el equipo.

---

En el caso de las regulaciones, lo habitual es que la potencia de transmisión este limitada artificialmente. Con un firmware abierto, puedo subir la potencia de transmisión al máximo, con lo que la señal llega bastante más lejos.

---

En el caso de las deficiencias, los vendedores de AP apuntan al usuario que sabe poco y nada de redes, y sólo quiere «WiFi y compartir internet». Por ejemplo, no tienen caching DNS (desperdicio de tráfico), no tienen (buenos) mecanismos para QoS, o tienen mecanismos precarios para VPN o S/D-NAT.

---

Cuando compro, o recomiendo comprar, un AP, lo primero que verifico es si puede correr OpenWRT. Si no puede, no lo compro. Si puede, lo primero que hago es instalar OpenWRT porque incluye las capacidades adicionales para VPN, caching-DNS, mejor manejo de filtrado y control de tráfico. usar el USB para ser servidor de archivos/medios...

View more

Si vas a particionar por fecha, no tiene nada que ver el tipo de la clave primaria. Particiona por el campo que tiene la fecha y ya está. La decisión de usar BIGSERIAL o UUID es ortogonal.

---

En cuanto a usar SERIAL o UUID, la diferencia en espacio puede resultar importante a gran escala: el UUID que se almacena ocupa 16 bytes, y un BIGSERIAL ocupa 8. Aunque el espacio en disco sea barato, cuando haces consultas que involucran esos campos, hay que leer y comparar los valores. Eso cuesta más tiempo de CPU y RAM: si los índices se hacen tan grandes que no caben en memoria, perdiste.

---

El UUID tiene una «presentación» visual tal que sirve como «código para entregar» y no revela ningún orden implícito. No es lo mismo poner Código de Cliente 42 que Código de Cliente 11c0f127-0f1c-4eab-aa82-2cc78f67ed72. El segundo es completamente opaco, y así deberían ser las claves primarias sintetizadas.

---

Así mismo, el UUID tiene la garantía de unicidad en la creación, mientras que con un BIGSERIAL necesitas una secuencia. Consultar la secuencia para tomar el siguiente número compite con otros procesos; generar un UUID no. Si el sistema es masivamente concurrente, podría ser mejor usar UUIDs en lugar de BIGSERIAL. No es un argumento suficientemente fuerte porque son muy pocos los sistemas masivamente concurrentes que tengan problemas como ese.

---

Los BIGSERIAL son simples números, con sus ventajas y desventajas. Para el humano es más fácil hacer «debugging» cuando las claves son números. Al mismo tiempo es fácil asociar orden implícito usando esa secuencia, que en realidad no tiene nada que ver con la naturaleza de los datos. Más de un desubicado piensa que el serial de la tabla Factura es el número de factura, pero no es, y hay otro campo que lo tiene y ¿por qué no lo usaste de clave primaria natural?

---

La clave primaria natural tiene que provenir de los datos reales (número de factura, número de parte, placa del carro, coordenadas del objeto, etc.). Si la fila no tiene una clave primaria natural, sintetizarla con UUID puede ser más fácil por su opacidad, que forzar usar números.

---

No tengo una preferencia particular. Te diría que uses UUID cuando lo necesites (ausencia de clave primaria natural, que deba mostrarse al usuario final), y (BIG)SERIAL el resto del tiempo.

---

Es probable que el tiempo de CPU adicional necesario para calcular el UUID sea más o menos equivalente al tiempo esperando por I/O para obtener el siguiente número de la secuencia, así que el desempeño debe ser similar. El espacio si te va a costar, así que no lo desperdicies si no lo necesitas.

View more