GoRuCo 2012 Hexagonal Rails by Matt Wynne
Confreaks1 HN recommenders · 2012–2014
17K views · talk · dated · Uploaded 2012-07-01
Matt Wynne's GoRuCo 2012 talk on why Rails apps get hard to change as they grow, and how a ports-and-adapters hexagonal architecture separates application logic from the framework.
HN cites it as a resource for decoupling Rails code and for faster tests.
53:22Ruby Conf 12 - Y Not- Adventures in Functional Programming by Jim Weirich
Confreaks
2:25:52The spelled-out intro to neural networks and backpropagation: building micrograd
Andrej Karpathy
49:55How Python was Shaped by leaky Internals, Armin Ronacher, Flask framework
Видео с мероприятий {speach!
38:47RailsConf 2014 - All the Little Things by Sandi Metz
Confreaks
1:01:39"Simple Made Easy" - Rich Hickey (2011)
Strange Loop Conference
26:53What the heck is the event loop anyway? | Philip Roberts | JSConf EU
JSConf
25:06"Making Impossible States Impossible" by Richard Feldman
elm-conf
1:00:19How To Design A Good API and Why it Matters
Google TechTalks
3 comments from Hacker News
Was going to say the same thing. Models should not know or care about background queues or mailings, and callback use has always caused problems for me later on. Nothing against the OP, it does explain a common edge case that many people will run into and for that it's a good article, but I wish more people would see the violations of SRP going on here and try to lead people away from this trap. I'd recommend watching [VIDEO] (Hexagonal Rails GoRuCo talk) for one way to re-architect to get away from these inter dependencies.
Am I only the only one that doesn't find 'All tests in 4 minutes, all model tests in 80 seconds' very impressive? It sounds like a really long time to me. You know what could increase the speed dramatically.... decoupling. I also think decoupling phrased in the context of the Rails 2 to Rails 3 upgrade, where pretty much everything changed, makes perfect sense. Imagine just having a few wrapper classes that spoke to Rails and only having to adapt them. Sounds good to me! Bernhardt: Boundaries [LINK] Weirich: Decoupling from Rails [LINK] Wynne: Hexagonal Rails [VIDEO]
Rails used as intended can be a real pain to upgrade, I agree. Recently I have been developing applications in the "thin-model, thin-controller, with a service layer and external API wrappers" style, as espoused by Gary Bernhardt [1] and others [2] [3] [4] [5]. I upgraded to the latest Rails this morning on one app, and apart from swapping the Money gem to use the git repository, until they have a new version out with compatible dependency, it went smoothly. All the specs and acceptance tests passing with no alteration required. [1] [LINK] [2] [LINK] [3] [LINK] [4] [LINK] [5] [VIDEO]