I think ActiveJob is a great thing, a real step forward to have a Rails-endorsed API for this others can hook into on both sides. Awesome.
But am I the only one who gets a sort of pit in their stomach every time they hear about a new Rails version? So many things to upgrade, so many dependencies that might break, and then Rails 5 coming in less than 12 months when I get to do it again, I have to admit the Rails treadmill is exhausting me.
> But am I the only one who gets a sort of pit in their stomach every time they hear about a new Rails version?
Welcome to modern software. I'm not on the Rails treadmill, but arbitrary breakage every month/quarter/year, possibly enforced by a hard-to-disable automatic update system, seems to be the new normal. Heaven help you if you write or use software that depends on "modern" software.
Hard to disable? Most of the dependency tracking tools I'm aware of, spanning from system level to application level, require you to intervene by default, even in the case of security releases and/or even have nice version pinning features.
As the maintainer of an internet facing application, it's part of your ongoing responsibility to, for security reasons, continuously integrate upon your dependencies.
Nothing's fire and forget, it's not sensible not to stand on the shoulders of all these giants around us, but when we do we have responsibility to integrate their security fixes and not break our apps.
Not sure where you draw your line of what"modern" software is when not even system packages and package managment are safe when we have Heartbleeds and ShellShocks, Kernel Vulns et al.
Unless you just mean the bros pumping out new NPM modules/Rubygems/etc, half-assing SemVer, disregarding compatibility as a goal, and only releasing fixes (security-related even) for the latest major version that came out several months ago, or abandoning them. Yeah, that's some serious BS and I hope things mature.
Just today I learned that a version of requests from August broke compatibility with a version of pip from February, which is packaged in ubuntu 14.04. (I was installing dependencies with apt and pip as root in a docker image.) (http://stackoverflow.com/questions/27341064/how-do-i-fix-imp...)
Meanwhile, openssl and bash, while getting security updates very recently, are in their very latest versions still compatible with programs from probably over 8 years ago.
"Meanwhile, openssl and bash, while getting security updates very recently, are in their very latest versions still compatible with programs from probably over 8 years ago."
You have obviously never worked with OpenSSL.
Also, the problems with `pip` is entirely due to Ubuntu not updating their dependencies properly. Upstream `pip` vendors their dependencies so that this precise situation does not occur.
That does make sense. Since pip is managed this way, Ubuntu should probably classify pip as "not system software, actually flaky web-app-dev software" and not package it.
> half-assing SemVer, disregarding compatibility as a goal...
Like Chrome and Firefox, which toss out something-or-other every few months, call it a "major version," and force-update users by default? Or Windows and Mac OS, which by default offer some kind of "udpate now or remind me in 30 minutes" dialog for both backward-compatible and breaking changes? It's all just complete disdain for users.
Oh, certainly. I was thinking we were speaking developer experience within the realm of building/hosting network services, not so much end-user experience for client software.
That space is still a special hell for lots of reasons. Auto updaters that steal your features away being quite inexcusable but yet also not chief among them for most users.
It seems it still takes a software engineer to work the average client OS and not get it infected with crap. Maybe the average child can operate a shared walled-garden device without exposing their family's sensitive documents to untold numbers of developers of third party software on accident (or on purpose, yay Minecraft Mods!), but that's certainly not true of general computing devices.
Lots of paid (or ad-bloated) software that's lower quality than free alternatives but with cash to spend on a marketing budget, and that's not a high bar given that generally FOSS for end-users performing day-to-day tasks on client devices is still really sad.
I've had luck with a stock Ubuntu install for the parents on both sides of the family. I set it up some eight years ago, installed printers and such, set it to auto update, and help them run the LTS uprgrade every other christmas. YMMV of course, and neither run minecraft mods or install crap from the Internet as they are basic web/office/audacity(!) users.
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.
I don't. I feel like the deprecations and API changes have mostly been quite minor since 4.x. A lot of this is shedding weight from supporting Ruby 1.9 and 1.8.7, so if you've been up to date on that front (gem and code wise) you've been okay.
I'm looking forward to 5, but I'd like to see what the feature set is. Namely building real time and concurrent apps in _Ruby_ doesn't feel natural on _Rails_ and I hope it can be.
I get excited about every stable release and try to switch as soon as possible. When you keep up with the incremental updates then the upgrade process isn't too bad IMO.
That's easy when you have just one, or a handful, of production projects to maintain. When you have hundreds it's a vastly different story. But that's where I think https://railslts.com/ comes in.
Upgrading between from 2.x to 3.x or 3.x to 4.x can tend to be tricky but I have not had many, if any, issues upgrading from 4.x to 4.2.
Typically if a functionality is removed or deprecated from the framework, you will find a gem will popup that can be included so your legacy code still functions. I often take this approach since we maintain mountains of Rails apps from 2.x to 4.x.
If you are working on a handful of apps or a single app, I think it is worth it to stay as current as possible and update with every new release. Your knowledge of the framework and the quality of the product will increase with every iteration.
Usually if I have a production project I avoid to step out through major releases.
As you have seen they do bug fixes for previous stable releases, which is awesome and IIRC the security one go even deeper to the tree.
No one force us to upgrade, but I do love upgrades, usually (if well done like this one) are full of things that may help our coding life and speed performances? Are always well welcome!
I'd love for Rails to have some incremental LTS releases. Not that the Rails organization itself has to provide support, but rather the community decides which releases are most suited for LTS support. This would force gem providers (and automated CI's) to test on those releases.
> "Rails LTS is a commercially supported fork of Rails 2.3 (and soon Rails 3.2) that continues to receive security patches now that official support has ended."
Unless you need one of the new features on offer, there is no reason why you would need to upgrade right away. It's perfectly okay to give a new Rails release a couple of months to settle, including gems that need to be compatible with it.
I've found the best way to make upgrading easier is having good test coverage. I think one of the biggest fears when upgrading is having something break but not knowing that it is now broken. Although tests won't always catch everything they are a great start to ease the upgrade process.
To have tests (and particularly integration tests) is a big help; as has already been mentioned.
Another thing is to use staged deployments: dont deploy to production-env from you development-env, but to a staging-env (if possible using the same or a copy of the live database). Then have a look with some (possibly non-technical) humans if the app still behaves as expected.
While it can be laborious for a large app, it should make a deployment to production a lot less scary.
As mentioned by others: upgrading is part of running a web app that depends on popular libs.
Why does it scare you? It's good to be wary of the upgrade process.. but this is why you have (I hope!) database backups and source control (as a minimum). Then at least you can roll back. Then it's just extras after that, test coverage, staging servers etc. etc.
Anyway, upgrading is a fact of life once you're using a framework (unless you want to get hacked) so best to get used to it :)
The Rails team make so many developers happy worldwide, it's incredible. Thank you from the bottom of my heart for making my job suck less.
---
A quick questions regarding Foreign Key support, in the past I would use these concepts normally but does this mean that before Rails did not use Foreign Keys (in the strict rdbms sense)?
Does this mean that there are now easy performance gains if you're using their new -real- foreign key support?
Using `belongs_to` or `references` in a migration is simply an alias for an integer column (that conventionally holds the id of another row) without any foreign key constraints.
Foreign key constraints aren't about performance - they are about maintaining [referential integrity].
previously...
pet.id # => 4
owner.update_attribute(:pet_id, 4)
pet.destroy
owner.pet # what should this equal?
Now this will throw an error.
pet.id # => 4
owner.update_attribute(:pet_id, 4)
pet.destroy # <= raises Error:trying to destroy a record that is referenced by the owners table.
owner.update_attribute(:pet_id, nil)
pet.destroy # no problem now.
To your first question, Rails tried to enforce some constraints at the application level, but it was lacking. I worked in a large production system and for extra safeguards their were DB level foreign key constraints. They are kind of a pain to unwind and make changes, but they can save your butt if you accidentally delete something.
It looks like there were initially quite a few performance regressions in the new release. Adequate Record looks great for rails scaffolds, but (at this stage) doesn't look like it will very useful for production apps that probably have more complex queries. For example, it stops working if your query has a `where`.
Big thanks to Sam et al for their work in speeding things up.
I have been using rails for many years now and I'm sad to say I'm leaving it behind in my current/new project :( I will miss the familiar patterns and want to express my gratitude to the team that makes everything work so seamlessly.
> Postgres9.4 has JsonB, Json, Hstore and Array fields. Rails4.2 fixes the dirty-tracking for JsonB/Json/Hstore.
Oh, I hadn't caught that, awesome! Can you link to docs and/or commit?
I'm wondering if it will do "partial updates" yet -- postgres supports, I think for Json too but definitely for Hstore, a statement that says "just update these keys with these values, leave the other key/values alone".
The reason you'd be interested in this is multi-client concurrency, so one client updating some keys doesn't overwrite changes made at about the same time by another client updating only other keys. Lets you use hstore/json in certain circumstances of multi-process concurrency that otherwise you'd have to use normalized separate rows for.
When I had tried to look at ActiveRecord on my own to figure out if I could get it to do this, it seemed like it oughta be possible (AR is already tracking the original value for dirty tracking, I think) but I never quite could figure it out, how to hook into the SQL-generation to do it.
But am I the only one who gets a sort of pit in their stomach every time they hear about a new Rails version? So many things to upgrade, so many dependencies that might break, and then Rails 5 coming in less than 12 months when I get to do it again, I have to admit the Rails treadmill is exhausting me.