Myself and EMW have a site called Rocket Propelled Badger for film reviews.
Its based on Ruby on Rails scripts running from a SQL backend, pretty standard. Matt wrote it a fair while ago, and its been running fine since then.
Our hosting provider has just updated to Ruby on Rails V 2.0.2. This broke our site. Firstly there are some mods you have to make to get an older app running on the new environment. That I don't have a problem with.
What I do have a problem with is that the original RoR offered a "Pagination" method. This automatically split the results of your queries into pages, and damn useful it was too. We used it in a fair few pages.
Pagination is apparently depreciated because it is not the fastest way of achieving these results. However, not only is it depreciated, it has been removed and there are no methods in the stock toolset that can be easily used to achieve the same.
The solution they give?
"Of course, if you’re using, say, pagination, you’ll need to install the classic_pagination plugin"
OK, fine. How do we do that? Well, we can't. It requires terminal access to the server. We can pester 34sp to do it, and to be fair they probably would in realtively short order. What if we didn't have a provider who gives very good support?
Basically we'd either have to turn off pagination or write our own methods.
In my opinion, that is bollocks. I have (politely) told them so.
Comments
OK, we can install plugins as its simply a matter of uploading them to the right place.
I still say removing functionality from the core and requiring third party code is poor practice though.
Ruby on Rails isn't the only guilty party for this. PHP4 and PHP5 are vastly different in places and they were not backwardly compatible. 34sp haven't put PHP5 on their servers as standard because of the amount of broken code that will occur. You now have to specially get your account changed using some sort of CGI system. It's a bastard because PHP5 is where all the powerful XML and class stuff is.
Fortunately Bullet Systems has PHP5, so the Icar site can run using it.
Hang on, .NET did the same but they had a nice deprecated system, where the compiler tends to tell you what's wrong and where to fix it.
Well, RoR 1.3 or so did have depreciation warnings on build, but given it just worked we didn't rebuild it. V2 doesn't even detect that you're using depreciated stuff I think...
Sounds like its fairly widespread, but I'm convinced its bad practice...
It's not really bad practise if the developer is interested in keeping the code base up to date. If you're using the framework, then you need to keep up with the latest framework. If you're going to code in C, you'll never have this problem but then you'll have to do a lot more work.
If they didn't redefine the framework every once in a while, then it will become huge and bloated and will have loads of methods that aren't good at all. It's best to revise and improve each time, not just to extend but to cut away some of the chaff that might have seen like a good idea at the time. How your framework deals with deprecation is important as is release features. It's always up to the application developer (you and EMW) to keep up todate with releases. It's a bummer but it's the way the industry is and I think it's healthier for it.
If there were any way to recreate the same functionality within the framework I might agree. As it is one of the selling points of Ruby has always been the small amount of code needed to set up a system with it. Given it runs from a database back end/query system, removing the only way to sensibly display a medium amount of results is ridiculous IMO.
As it is now it makes sense for intensley cross-referenced but sparsely populated data, but not for large tables. They've really limited the amount of applications that the base framework will cater for. Given a lot of web apps are large table systems (comments, forums, newsposts, etc) I think its a very bad move.
Sometimes, if you've created something that's a cancer, you should remove it and have it as a plug in, which is what they have done. You can then choose to have it if you want it.
I think cancer's a bit strong ;)
Its inefficient. That's the only issue they have with it. But its highly likely to be required by sites that use database backends IMO, and that's what RoR is for after all...
I think its an odd thing to do. Especially as its a foreground thing... if someone didn't need it, they wouldn't call it and the only impact it would have on the system is the marginally larger scripting language footprint.
If RoR wasn't as "code efficient" and didn't integrate so much functionality I'd probably agree mate, but it does so many things with one line of code to remove something so fundamental to database -> web I find truly bizarre.
Didn't this happen with DirectX a while back, where they broke backwards compatibility as there was getting to be such a performance hit with continued backwards compatibility that it was hard to make any more advances?
That did happen with DirectX, but in that case they were supporting a huge amount of the old way of doing it, and in all cases they were replaced with new ways of doing it.
Here they just ditched something from the core and stuck it in a plugin.
It did, which is why Interstate 76 won't run on modern XP systems.
As part of the ethos pagination is something it should support out of the box. It's a standard feature of the app's that rails is designed to produce and since the whole point of rails, it's raison d'etre if you will, is it works with little or no code to support a standard table based app.
It's also worth pointing out the replacement is not some official rails plugin it is a replacement made by someone else who needed pagination and found it suddenly absent.
But then I'm a C++ developer and that has been pretty static for years, about the only change has been the meta code and template and stl stuff that came in early 2000's even then that is leveraging existing stuff to make the compile and link work harder.
You're living in a dream world. Everything I currently code in changes at least every 6 months, so refactoring is an almost constant process. Either .NET changes or SQL changes. SQL Server 2000 and 2005 are not directly compatible and what's worse it changes the manner in which is serves XML, which is a stupid thing to change. You have to run 2005 in compatibility mode.
However, in the long run, the applications we write will be better, more efficient and run faster.
I doubt we're going to convince each other.
The whole idea of Ruby On Rails is low code development for web sites from a database backend. IMO pagination is an integral part of that toolset. Removing it makes the toolset incomplete.
Writing a pretty standard webpage (anything that uses pagination. Anything with comments that limits the page length, anything with a frontpage that shows X number of items. Anything with a list that only shows the five newest) is now impossible without using third party tools. I think that is incredibly stupid.
It was the only framework with pagination. PHP doesn't have it, neither does ASP.NET, nor does Java (last time I looked, a while ago). TSQL (Microsoft) does, MySQL does (I think). But they are on the database side, not on the framework.
Pagination should be handled carefully because of the order of which the database performs its queries. You can't just get all the result from the database into memory and then perform pagination on them. That would be a huge memory hit. Much better to select the records you need. What about if you need to sort them? What about if you need a subset of those? Simply paginating the data coming back is not a good use of databases or memory. Pagination should be done on the database server, not in the framework. I'm not sure why Ruby has removed it but that's why it doesn't exist in the others. It's a function of a database, not a code framework.
I'm happy to agree to disagree.
I know the stuff I do is radically different to most developers, embedded systems being somewhat of an odd duck. All programs are measured in k as is memory and I'm dealing with high performance custom hardware at the metal where a few extra uS or clock cycles can make or break something.
I'm also using a very mature language that has had most of the crap hammered out to make it one of the most optimum programming languages ever designed in my humble opinion. As they say C++ is the second best language for any task, you'll often find one that will be slightly better for a specific app but never one that is so universally applicable and powerful.
As such my perspectives on things may well be quite different.
Some of the changes they made to rails I could accept changing round a few functions streamlining the ones that were there, even the rather odd decision to rename the file type for all the template files.
However the decision to remove pagination entirely would be akin to finding the latest version of gcc had removed the while statement for being too slow and require you to make your own version out of a combination of for and if's. It's a fundamental part of things that has been stripped out.
Fair enough.
(The perspective of a Web App Developer)
To be fair, a quick review of my posts does show some shifting of footing. I started off arguing the general case and switched to the specific. In the general case, I'm no longer arguing, I can see there are times when you would drop long-depreciated methods for efficiency.
In the specific case, I think we're fairly happy. It was indeed the only one to do pagination. This was part of the appeal though, so taking it out is a bit of a kick in the nuts for people drawn in by it ;)
I have every confidence that the Badger will be fully functional once more in the near future. I feel confortable saying that as its Matt that actually does all the work :P
Seems to me that the problem here is obvious:
"Our hosting provider has just updated to Ruby on Rails V 2.0.2"
Rob's right, it's not reasonable to expect language specs and standards to remain the same over time. In any environment. Java 6 broke backwards compatibility with some of our apps here at work, and different versions of g++ exhibit radically different behaviour in some areas. That's why we have very a strict policy about qualifying our various products on every possible combination of OS and compiler version we expect to ship to. I'm sure Matt will agree that while c++ is ostensibly a stable language (c++ '0x notwithstanding) his company wouldn't just randomly switch to a different compiler without serious forethought and testing.
What you can expect, though, is that the runtime environment of a production system will remain constant. The reason it doesn't matter that g++ and the standard libraries change is that you know new versions will be installed alongside the old, and that your apps will stay linked to the version they were compiled against (I'd love to be able to say Java had a similar feature, but no - you're stuck with fucking about with environment variables ffs,) and there's no reason you should expect any less from your web-app framework.
If RoR 2.0.2 isn't backwards compatible with RoR 1.x, then there is an implicit requirement on RoR that the two can run side-by-side on the same server, and on 34sp to make sure that they make use of that capability to avoid breaking their customers websites.