61–70 of 225 posts
WebSockets would have been a cool addition four years ago. There is little compelling case for new development. Sorry to be so harsh.
Earlier quoted context omitted.
I use jRuby, which is great and an amazing piece of engineering. However, with Rails, you're only see about a 20% speed bump and out of the box it uses too much memory to run on Heroku's free tier. You'll also miss out on the gems with c extensions (for now I think that's about to change). Additionally, there seems to be a performance regression around includes and case statements. Your devops story can also be a bit…
Interesting we saw about a 50% performance hit when trying jruby and also a 15% hit on memory usage- it was a no go for us
We've moved all of our backend offerings from Rails to Elixir/Phoenix. Despite some questioning the value of anything below 100ms response times there is a lot of data backing up the idea that Elixir/Phoenix can lead to a more maintainable and more economical solution. I spoke about this recently at RailsConf: https://www.youtube.com/watch?v=OxhTQdcieQE Don't get me wrong, I think Rails is an amazing technology but i…
Every time I've explored alternatives to try to get those kinds of numbers, it seem the bottleneck is more in the database than the application server.
On one project my team was convinced that Redis was our bottleneck. Profiling was showing that Redis calls were where the most time was spent. I spent some time looking at the redis-rb source and it does a lot of block nesting (4 or 5 levels for every call, IIRC). So, I tried replacing the redis-rb client with something a bit lower level and our throughput doubled. It turned out that all that block processing cost as much as the network call did.
I suppose this isn't all that new: many performance issues are really a "death by 1,000 cuts" situation. Oftentimes your profiler can lead you astray.
This has been long awaited: Post.where('id = 1').or(Post.where('id = 2'))
Seriously, .or() always felt like a glaring omission.
I wish I had API mode 4 years ago
Earlier quoted context omitted.
Seriously, .or() always felt like a glaring omission.
It's not an omission per se, it's actually a challenging thing to implement. I'm sure they'd have done it sooner if it wasn't so hard to get right. Think of how the precedence rules would work: especially since the queries are composable, tacking on another .or() can do funny things semantically.
Looks like a solid and and relatively straightforward upgrade from Rails 4.2. It's hard not to feel Rails has become a bit of a slow-moving behemoth though, with this release four years after 4.0. I've still got a couple clients using 3.2 from 2012 and things aren't that different. Smart money at this point seems like a significant portion of the Rails community could begin moving to Elixir/Phoenix over the coming ye…
I feel bad for Sean Griffin. He spent over a year overhauling the internals of ActiveRecord to add this attributes API. His work dramatically improves coercion and type enforcement for ActiveRecord users. Seems weird for this to only get a non-descriptive bullet point in "other highlights." Here are the docs if anyone is interested: http://edgeapi.rubyonrails.org/classes/ActiveRecord/Attribut...
I'd love to read more about it. Do you know if he has written anything about this work?
You can also just ping me on Twitter and I can talk about it more. :)
I feel bad for Sean Griffin. He spent over a year overhauling the internals of ActiveRecord to add this attributes API. His work dramatically improves coercion and type enforcement for ActiveRecord users. Seems weird for this to only get a non-descriptive bullet point in "other highlights." Here are the docs if anyone is interested: http://edgeapi.rubyonrails.org/classes/ActiveRecord/Attribut...
I'd love to read more about it. Do you know if he has written anything about this work?
http://confreaks.tv/videos/railsconf2016-rails-5-features-yo...