Vanilla Rails is plenty
This post is about Rails, but applies to Laravel as well
Read more [dev.37signals.com]
Posts tagged with ruby
This post is about Rails, but applies to Laravel as well
Read more [dev.37signals.com]
Ruby veteran Chris Oliver explained to me the basics of how to create a Ruby Gem (aka a Ruby package) for Ray. After I explained how Ray works internally, he coded up the foundation of the package. You'll find the code in this repo on GitHub.
You can watch our entire live code session here:
Join 9,500+ smart developers
Every month I share what I learn from running Spatie, building Oh Dear, and maintaining 300+ open source packages. Practical takes on Laravel, PHP, and AI that you can actually use.
No spam. Unsubscribe anytime. You can also follow me on X.
A cool talk by John Cinnamond, on how you can create a pure OO language and why you shouldn't do that.
The team at Kickstarter made a simple, synchronous event sourcing library implemented in Ruby.
We’ll go over a high level introduction to Event Sourcing where we will highlight the four components that make a (minimal) Event Sourcing system: Events, Calculators, Aggregates and Reactors. We will then talk about how we implemented a (minimal) Event Sourcing Framework at Kickstarter for d.rip. And finally we’ll reflect a bit on the ah-ha moments and the challenges that we’re going through with this approach — 9 months after having started to work on d.rip and 4 months after launch.
https://kickstarter.engineering/event-sourcing-made-simple-4a2625113224
Like at most previous editions, DHH delivered a keynote at RailsConf 2017. This year he spoke on the importance of belong to a group, programmer values, and belief systems. I love being in the Laravel community, but one thing that annoys me sometimes is the "us" vs "them" mentality you feel here and there. What I find great about DHH's talk is that is a positive approach to the values of Ruby community. He doesn't say that the other communities are bad, or lesser then them.
Anyways, go watch this keynote, it's great.
Jerome Dalbert on his blog:
Splitting your Rails controllers when they have a very specific scope, too much logic, or too many mixed concerns can have a lot of good side effects in your code.It doesn’t mean that you never abstract. It just comes later down the road. At some point some logic needs to be shared by several controllers. Sometimes even a splitted controller with only one public method gets too big. Et cetera. This is where concerns, model methods, possibly background jobs, and even sometimes service objects (hopefully not too many) come into play.
The more your app grows, the more time you will need to spend to understand it, no matter how clean the code is. But splitting your controllers makes things easier.
http://jeromedalbert.com/how-dhh-organizes-his-rails-controllers/
Phil Sturgeon, who has contributed to numerous valuable PHP related projects, is doing Ruby nowadays. In an article he wrote for Sitepoint compares Ruby with PHP.
... I thought it would be interesting to have a slightly more fair comparison, from the perspective of someone who really enjoys writing both PHP and Ruby, and has done so for years. The aim here is not to find out which is “better”, but to point out a few key things I like about Ruby and its ecosystem.http://www.sitepoint.com/php-vs-ruby-lets-all-just-get-along/