Categorías
Open Data

(open) data.europa academy

Pilares de Data Europa Academy

you can find all available courses, which are structured along four themes: policy, impact, technology, and quality. These four themes cover topics ranging from the open data basics to new trends and challenges in the open data landscape. You can search for and filter courses based on your interests.

The curriculum is constantly updated with new courses and new learning material based on research and best practices.

data.europa academy

¿Qué es data.europa academy? Una serie de videotutoriales en inglés que explica los conceptos básicos de Open Data.

Licencia de la imagen utilizada: CC BY 4.0

Categorías
Diseño

André Ricard: diseñar lo indispensable, lo necesario vs. lo superfluo y lo inútil

Enrique Alpañés: El capitalismo y la rapidez de los tiempos actuales hacen que consumamos más cantidad y que los objetos sean más efímeros, que duren menos. ¿Cómo afecta esto al diseño?

André Ricard: Depende de qué entendamos por diseño. El diseño mal entendido puede fomentar que haya más consumismo. Si proyectas cosas que son inútiles, innecesarias, pero atractivas, porque son divertidas o están de moda, eso es carne del consumismo desbordado. Si tratas el diseño como yo entiendo que tiene que ser, creas soluciones que mejoran la vida de la gente. Ambos tipos de diseño se diferencian muy claramente. Creo que hemos de diseñar lo indispensable, lo necesario. No lo superfluo y lo inútil.

André Ricard: reflexiones del rey del diseño

Categorías
Programación

Como denominar número de versiones correctamente

Dado un número de versión MAYOR.MENOR.PARCHE, se incrementa:

  1. la versión MAYOR cuando realizas un cambio incompatible en el API,
  2. la versión MENOR cuando añades funcionalidad que compatible con versiones anteriores, y
  3. la versión PARCHE cuando reparas errores compatibles con versiones anteriores.

Hay disponibles etiquetas para prelanzamiento y metadata de compilación como extensiones al formato MAYOR.MENOR.PARCHE.

Versionado Semántico 2.0.0

Toda la vida haciéndolo mal 🙂

Categorías
Programación

Principios de diseño de Python (El Zen de Python)

  1. Beautiful is better than ugly.
  2. Explicit is better than implicit.
  3. Simple is better than complex.
  4. Complex is better than complicated.
  5. Flat is better than nested.
  6. Sparse is better than dense.
  7. Readability counts.
  8. Special cases aren’t special enough to break the rules.
  9. Although practicality beats purity.
  10. Errors should never pass silently.
  11. Unless explicitly silenced.
  12. In the face of ambiguity, refuse the temptation to guess.
  13. There should be one– and preferably only one –obvious way to do it.
  14. Although that way may not be obvious at first unless you’re Dutch.
  15. Now is better than never.
  16. Although never is often better than right now.
  17. If the implementation is hard to explain, it’s a bad idea.
  18. If the implementation is easy to explain, it may be a good idea.
  19. Namespaces are one honking great idea — let’s do more of those!

PEP 20 — The Zen of Python —Tim Peters

Nota sobre el punto 14 (Although that way may not be obvious at first unless you’re Dutch): Guido van Rossum, creador del lenguaje de programación Python, era holandés.

Observación: el punto 20 de este Zen of Phyton nunca se llegó a escribir.

Categorías
Diseño

Principios de diseño sobre la complejidad cero en negocios TIC

  1. ¡Poner a las personas primero!
  2. Usa solo lo que entiendes.
  3. Defina criterios específicos que sean tangibles para medir la complejidad.
  4. Crea un modelo de tu solución.
  5. Separación de asuntos
  6. Reduce todo lo que no aporta valor.
  7. Los problemas deben solucionarse mediante soluciones simples.
  8. Diseña para el cambio.
  9. ¡Asegúrese de poder gestionarlo!
  10. Privacidad por diseño.
  11. Evita las soluciones complejas

Fuente: Welcome to The Zero (0) Complexity Business IT Design principles