La idea es compartir librerías que nos gusten, a ser posible código libre de github.
Ejemplo de una buena contribución:
Nombre de la librería, link y una descripción breve.
[ Akka ] ( https://github.com/akka/akka ) - Actors made easy para JVM.Repositorio Awesome Mediavida
Decenas de miles de peticiones por segundo en JVM?
https://github.com/netty/netty
Actors made easy para JVM
http://www.typhoonframework.org
Dependency injection library. Desarrollo frameworks para iOS, y algunos de mis frameworks tienen dependencies en otros frameworks. Typhoon es perfecto para este tipo de trabajo ya que siempre uso dependency injection
#13 ese es el equivalente de dagger2 en ios?
aprovecho y pongo una:
https://github.com/andrew--r/channels
YouTube (mostly, but not only) channels for frontend developers
Podéis poner al menos en que os salvó el culo o por que es tan genial, más que nada porque googlear librerias sabemos todos y pegar aquí el enlace a github no nos aporta nada.
#9 Para escribir unit tests en C++. Es bastante JUnit-like (o unittest de Python, por si te suena más).
Si digo que está OP es porque la verdad, considero que no hay mejor manera de implementar los unittests en C++ que con eso ahora mismo.
Devuelve datos aleatorios de personas: nombre, foto, email... En distintos formatos: JSON, XML, CSV, o YAML.
Muy útil para maquetar previews.
#24 Anda que no tiene bugs ni nada la librería completa de PHPOffice, hace poco tuve que usarla para una implementación y estuve más tiempo arreglando bugs que haciendo la implementación.
#26 Seguro, yo la he usado y no he tenido ningún problema. Pero el caso es, ¿Hay alguna otra alternativa?
Por que no veas la que tuve que liar para generar un CSV y los saltos de linea pasarlos de linux a windows. Al final no pude 
#27 Para mostrar cualquier documento de microsoft office(excel,word,ppt) pequeño tardaba eones y mal formateado si es que mostraba algo sin dar errores. Lamentablemente poca alternativas vi.
Cuando tengo que hacer gráficas me tiro de cabeza a esta librería. Aunque hay algunas librerías (muchas tiran de d3 como base) que te crean gráficas con dos líneas, cuando quieres hacer algo más personalizado puedes sudar sangre. Pero con D3 puedes hacer lo que quieras. Es una pasada.
Pues para lo de Jackson.
Lo "normal" es que las librerías usen las propiedades directamente con reflection (o con Unsafe, si se es un valiente) para sacar las propiedades en vez de los getters/setters. La cosa es que como esto la gente no lo sabe pues te llega el novato de turno a agregar un inocente método del tipo
public boolean isAwesome() {
return this.awesomeString.equals("awesome");
}
Y la próxima vez en el JSON te va a meter la propiedad "awesome" y "awesomeString" porque todos sabemos que los getters/setters son la manera cool de hacer las cosas. El caso es que cuando lo vayas a deserializar te va a decir que no conoce el setter de la propiedad awesome porque es calculada y te hará explotar todo.
Que no quieres que pase esto? Añade @JsonIgnore a todos los métodos (getters calculados) que quieras o a la clase, suerte intentando reescribir algo de código que no soporta Jackson desde el principio (y si, me ha pasado y está pasando ahora mismo)
La alternativa? Pues sinceramente hace tiempo que directamente no uso JSON en proyectos personales como tal, para mierdas de configuración puede venir bien (aunque prefiero HOCON) pero para todo lo demás (g)RPC. Y si no queda más remedio porque es una api que consumirán otras personas que prefieren json pues lo que venga con el framework de turno, shit happens.
