Group items tagged

Jugoso debate y ejemplos de como reemplazar inyección de dependencias (DI) con patrones comunes de programación funcional.

Me expresé muy mal, muy desde el punto de vista de un programador java... el asunto en realidad no es "cómo reemplazar DI" sino qué patrones de diseño hicieron que nunca fuera necesario el uso de DI en los lenguajes del paradigma funcional y cómo se pueden aplicar en scala.

Muy buena charla de Runar Bjarnasson sobre DI estilo funcional. En alguna charla lo escuché decir algo así como:   Como todos sabemos "Inversion Of Control" es solo otra forma de llamar al "pasaje de parámetros". Y eso marca el approach alternativo al "DI estilo Spring" que tomó el mundo de la programación funcional.

Este "patrón" está funcionando muy bien en navrel.

Scala macros to generate wiring code for class instantiation. DI (e.g. guice) container replacement.

"In this post I would like to make small introduction to Scaldi and show you how easy it is to use it together with Play."

"Scaldi - is Scala dependency injection library. Basically Scala already have everything you need for dependency injection. But still some things can be made easier. Goal of the project is to provide more standard and easy way to make dependency injection in Scala projects consuming power of the Scala language. "

Dick Wall explores the state and future of Java, his reasons for switching to programming in Scala, the SubCut Dependency Injection library for Scala, Scala Compiler Plugins and much more.

"Introduction In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that: Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portability between execution environments; Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; Minimize divergence between development and production, enabling continuous deployment for maximum agility; And can scale up without significant changes to tooling, architecture, or development practices. The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc). Background The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Heroku platform. This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app's codebase, and avoiding the cost of software erosion. Our motivation is to raise awareness of some systemic problems we've seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler's books Patterns of Enterprise Application Architecture and Refactoring. Who should

Bueno. Eso. Compartí el que me di cuenta que puso antes Pablo en vez del original por error, pero la idea entre ambos, si la obviedad es tolerable, es idéntica :) Está muy bien estructurado en cuanto que cada factor depende de los demás a la vez que los promueve. Permite un enfoque general que incluye prácticas de arquitectura - y de armado cotidiano de productos - que posibilitan llegar donde yo entiendo - según me voy enterando - que es el lugar a donde llegar. Sin embargo, creo que ni éste departamento en sus sistemas más nuevos cumple todos y cada uno de aquellos factores. Esto, lejos de ser una crítica, es una invitación para que revisemos si es el único método posible - cosa improbabilísima - o el mejor método - también bastante improblable - a seguir. Lo que sí sostengo como un absoluto - quien no lo haría - es que es un método practicable. Mi aporte mínimo es defenderlo como uno bueno.