Rails 4.2.0 beta1: Active Job, Deliver Later, Adequate Record, Web Console(weblog.rubyonrails.org) |
Rails 4.2.0 beta1: Active Job, Deliver Later, Adequate Record, Web Console(weblog.rubyonrails.org) |
...but yes; thats the main complaint of any substance.
IMO it deserves bad press for favouring development speed over sensible defaults and safety. Frameworks should not be allowing SQL injection in 2014.
It took me a long time to realize that Rails' greatness isn't due to magical omakase magic - it's the community DHH (and the core team) have built over the years, and the strong product focus they've applied. Really impressive. Did Torvalds work like this? Has anyone has studied or written about organizational behavior in the open-source community?
Support for real foreign keys!
addforeignkey/removeforeignkey are now
available in migrations.
Rails is 10 years old and it has definitely changed the web development. But the unnecessary controversy always seem the same of its first year.
While in the last 10 years, many people talking Rails does not scale and ruby is slow, for many companies rails was and is a great "tool" to delivery great web apps.
Thanks Rails
I wish I could write a long post describing each of the WHY's, but I'll be more succinct, this time:
1)If you can throw money at something at something and scale, then you're as good as gold. Rails allows you to do this. Oh, and supportive statements from Pinterest guys on the same topic - [2].
2) The speed of a language has nothing to do with the success of your business. NOTHING. You can go with the world's slowest language and still be successful. Best example of this is Basecamp itself.
As a matter of fact, even many of the popular sites (heck, even popular porn sites) still run on PHP (PHP was one of the slowest from the frameworks speed comparison conducted by Techempower - [3]).
3) The actual thing you want to be able to do is quickly iterate on your product and constantly have it evolve. This is only possible if you have a complete framework that doesn't force you to re-invent the wheel. For example, when I wrote a framework by myself in GoLang, Scala, I found myself focusing too much on basic stuff like authentication, instead of focusing on the features that are needed for the actual product.
4) (P.S this is my personal opinion) I've tried all major frameworks out there and I've come back to Rails again. Why? Because its philosophy resonates with me (yes, now it does). For me, the three most important elements for a successful product are - Speed, Reliability, Consistency. Rails provides me with all these three. (And please try Puma, it's pretty impressive!).
As for me, the ability to seamlessly integrate SASS, Compass and HAML (which help me divide my product development time multiple folds) makes Rails a clear winner for me. And now Active Job, Deliver Later, Adequate Record, Web Console now make Rails much more complete than ever. (Thank you DHH!)
In the last 6 months, I've written 4 complete products for 4 different people (one of them, being mine) that is well tested and works perfectly as intended. Compare this to something like last year where I spent 2-3 months writing just a single software product (for myself) while I was trying to use GoLang (<- or insert another faster language here) (because I also had to take care of all the other things like Authentication, etc). The point is, ultimately you want to run a successful business. And if you're worried if the slowness of your language will hinder it's growth, then nope. That will not happen. I hope this helps someone.
Cheers.
[1] https://news.ycombinator.com/threads?id=neya&next=6993616
[2] http://highscalability.com/blog/2013/4/15/scaling-pinterest-...
[3] http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...
It would be nice to have a "API only" flag option when generating a new rails project. Something like: `rails new myapp -api`. This could keep Rails going for another 10 years.
I'm looking into using Napa, a Grape based API framework, for the purpose of Ruby server-side API apps: https://github.com/bellycard/napa
(Napa is to Grape as Padrino is to Sinatra)
Related reading: http://www.divshot.com/blog/opinion/every-web-app-is-two-app...
This was rejected by core and turned into http://github.com/rails-api/ , which has had some maintenance issues, but is getting back on track.
(see https://groups.google.com/d/msg/rails-api-core/8zu1xjIOTAM/1... . This is about AMS, but that's only because updating rails-api itself should be easy, and I'm going to check it out as well)
As someone coming from Django, I hate that I have to explicitly define db related validations and catch exceptions thrown by postgres instead of it just being handled by AR with the DB adapter based on the database constraints.
I love how Django handles that and I hope this finds its way into Rails one day.
It seems to me because it is such a mature framework there are a lot of Rails-specific techniques and components to learn, this seems quite daunting to me, am I correct?
http://news.railstutorial.org/
The upcoming third edition, which I hope to start publishing soon in draft form, is by far the most newbie-friendly edition yet. Indeed, it threads a rare needle: it's both easier and it covers more advanced material than previous editions. (This includes a rewritten chapter on login & authentication, an all-new section on image upload, and an all-new chapter on account activation and password resets.)
To me, the possibility to iterate fast has a much higher priority than thinking about scaling if i have a few or not that many customers.
Thinking about performance problems when you start your first project/startup is like thinking about what to buy IF you win the lottery.
WOW
The PostgreSQL adapter now supports the JSONB datatype in PostgreSQL 9.4+.
I've been interested in real ActiveRecord support for Postgres hstore, in a way that can do partial updates -- if only one key/value has changed, on save an update would be sent to postgres for only that key/value. This matters for concurrency issues where multiple clients may be accessing postgres and modifying the same values.
Does anyone know if anyone has been working on that at all?
What is AdequateRecord Pro™?
AdequateRecord Pro™ is a fork of ActiveRecord with some
performance enhancements. In this post, I want to talk about
how we achieved high performance in this branch. I hope you
find these speed improvements to be “adequate”.
Group discounts for AdequateRecord Pro™ are available
depending on the number of seats you wish to purchase.
-- http://tenderlovemaking.com/2014/02/19/adequaterecord-pro-like-activerecord.htmlIt boils down to: 1. It's a joke. 2. Enough with hyperbole.
He could have called it TurboRecord, but everything has to be "X on STEROIDS!!!!" these days, so "AdequateRecord" instead.
I too am curious how noticeable an improvement this will be in most apps. Is it a micro-optimization that won't be noticed much, or is it actually going to make a difference for real apps?
Rails versions come out quickly, and old versions stop being supported. And it's become a non-trivial part of my time running the treadmill of keeping all my Rails apps up to date, along with compatible dependencies.
I realize this kind of goes with the program. Rails all-volunteer development manages to produce a reasonably powerful and non-buggy product that for the most part is constantly getting better; the cost of this is quick evolution and a maintenance burden for users.
I don't think I'd like the tradeoff better choosing a less mature/powerful/robust framework, but it is increasingly frustrating.
(The fact that some of the things Rails adds seem unfortunate to me (turbolinks, spring), can add to my frustration too).
(The fact that some of the things Rails adds seem
unfortunate to me (turbolinks, spring), can add to my
frustration too).
The way I see it is that Rails is usually the wrong choice for a one-off project that a client expects you to deliver and be able to run indefinitely with no maintenance, but it's a great choice for a prototype or something that will see continual maintenance and enhancement.
My biggest frustration is just the general slowness of Ruby once you get to a non-trivial app size.
1) Except when you don't have the money. Not everyone trying to build a business goes the funded startup route...
2) Except when it does. There are (a small percentage of) businesses where speed does matter and caching everything is not an option. Think exchanges, ticket sales, real-time analytics off the top of my head.
3) Yes, you want to quickly iterate. Sometimes this means using readily implemented libraries for the non-core parts of your businesses. Sometimes it means avoiding readily implemented libraries that do not fit your requirements and/or overcomplicate what you are trying to do. Sometimes it means avoiding the cognitive overhead of all that cruft a framework has and you don't need. Sometimes it means using a typed language and letting a compiler do the most basic testing for you...
4) To me, this is a classical exploration/exploitation tradeoff. You will be less productive using anything new. New language, new framework, new ideas drag your productivity right now. But they may increase it in the long term, even if you end up going back to whatever you were using before. Find some budget to explore and make the most out of what you learned, but don't overspend on it.
We fool ourselves into thinking we NEED a faster language, and Hindley-Milner type checking, and everything else under the sun.
It's actually really hard to discover, whether you're fooling yourself or not here.
We're building our startup on Ruby/Rails with a clojure component for the speed sensitive stuff (which is actually a CPU bound number crunching affair). So far we're been very happy with the tradeoff. We tried building stuff in node, but the ecosystem is just so damn immature.
One of the nicest things about the Ruby community, that I haven't seen in any other language, is the cultural emphasis on good documentation. Java libs have very complete docs, that take forever and a day to read when you just want to use one damn feature, node.js projects have very pragmatic, but very incomplete docs, (same with clojure), and really, that's the case with most languages. Ruby on the other hand, seems to have instilled in its community that docs count, and its wonderful.
Rails testing and tooling is just ahead of the pack, and in the specific case of node, dealing with the irritation of async (inscrutable stacktraces, even when 'long' stacktraces are enabled, inconsistent uses of promises across libs, etc.), is a huge drag on productivity. If I needed a small highly concurrent component I'd consider it, but for general business logic Rails just kills it.
True. But even in those cases, there are likely parts of the system where speed of execution is less important than speed of iteration. So you could (if it made sense for you) use a Ruby app for the user-facing app, backed by a service written in something else.
Point being, just because you need a critical processing bit to be written in screaming-fast C doesn't mean you need to write your own HTTP router in C.
That said, one impetus of our TechEmpower framework benchmarks project was to encourage people to diversify their experience and consider performance as one metric in evaluating the broad spectrum of options. I personally feel that doing so is valuable for a variety of reasons, several of which others in this thread have pointed out.
We refer to a second dimension of "developer efficiency" that we can't measure as objectively as performance. We've had scores of conversations about proxies for developer efficiency, but haven't moved forward in earnest on any yet. That said, my strong belief is that developer efficiency is not inversely proportional to performance any more. Perhaps it was at some point in the past, but I don't feel that's the case now. I personally am just as productive, and in some cases moreso, in a modern language and framework, as I am in legacy frameworks and languages.
If it were possible to accurately and impartially measure developer efficiency and then scatter-plot developer efficiency and performance with a slope line, then yes, there may be a declining efficiency slope as performance increases. But I suspect there would be data points representing both high-efficiency + high-performance and low-efficiency + low-performance options.
It's important, but difficult, to isolate learning curve from long-term developer efficiency. But Neya is a useful counter-point to my argument, and if I might put words in his mouth, he is saying: don't trivialize the lost productivity due to the learning curve; it can be significant.
Plus, SASS/Compass/HAML integration isn't strictly part of a framework, it's the build pipeline.
* https://sourcegraph.com/blog/google-io-2014-building-sourceg...
* https://github.com/drone/drone/
* https://github.com/jordan-wright/gophish
All are reasonably sized; Sourcegraph and Drone especially so.
This also helps you "fail fast". If you have a 1-year runway, it's much better to be able to build 3-4 apps for market validation than build one performant one that nobody wants.
If one succeeds and performance is a problem, you now have good reason to optimize, possibly even to switch languages.
The fact that an example of something exists doesn't validate that something. "Shooting people has nothing to do with whether they die or not. I once shot a guy and he lived."
A little related: http://pablocantero.com/blog/2014/04/20/i-coded-a-backbone-a...
See the original discussion here: https://github.com/rails/activejob/issues/25
The discussion was then continued here: https://github.com/rails/rails/pull/16485#discussion-diff-16..., which is where the `ActiveJob::DeserializationError` comes from.
It's not full-record-serialization, and it can't bring back deleted records for you.
(See https://github.com/rails/rails/tree/master/activejob#globali... for an example.)
See the example here: https://github.com/rails/rails/tree/master/activejob#globali...
See the example here: https://github.com/rails/rails/tree/master/activejob#globali...
I'm also not sure about Railscasts for a beginner, the most suitable ones for a beginner may be pretty out of date now although there are probably a lot of useful ones still there.
Edit: I created it, so I'm biased
(I still do not choose to write my apps in PHP. Also these PHP apps did not use a Rails-like framework. If I were to do a big app in PHP again, I'd want a Rails-like framework. And indeed I wonder how much that would increase my maintenance costs.)
> Do you have any estimates on how much time is wasted, compared to the rest of the application? Profiling here is extremely important before making your program more complex. As I will often note, Reddit serves well over one billion page views a day, they use the SQLAlchemy Core to query their database, and the last time I looked at their code they make no attempt to optimize this process - they build expression trees on the fly and compile each time.
But rails devs heard our pain, and next version of Rails will let you skip turbolinks specifically too (not sure exactly which version it's slated for, and now I can't find the Github issue where I learned about it).
The modularity is nice... although the tradeoff is, ironically, code complexity to support that modularity.
Regardless, every new feature is additional code complexity in Rails, additional dependencies that may break with that feature and need to be upgraded (or that may require that features since it's now default, even though you need to turn it off), and treadmill time upgrading your apps or engines to work with the feature _or_ to disable it.
The value of type safety comes in tiny increments over time. Week after week, month after month, year after year. If your project survives 10 years I am quite confident that the effort of implementing in a strictly typed language would have paid for itself by the number of bugs prevented and the number of wiring tests that didn't have to be written/maintained. Of course if it's just a solo project and you keep the code under control it's possible this is not true, but with developer and code churn I'd say this is practically impossible. The more important question is will this code base even need to live for 10 years in the first place?
Hard to go back to dynamic or static weak after grokking the power of static strong, as you describe. Algrebra Driven Development > Test Driven Development.
I think it's a pride issue and a difficult one to manage correctly if you want to keep active/engaged developers who believe they're tackling difficult/unique issues.
I personally think Rails is great but, frequently, it is not a sentiment that is shared amongst the people I regularly work with and they see it as too elementary (for some bizarre reason).
If Rails were a for-profit with marketing dollars I would suggest that there is a perception issue with the framework among developers, but I don't know how you handle that in the OSS world.
The market for new hires is critical to success too, and using the latest and greatest tools can really help there. This is also a reason for Google X, Facebook buying Oculus, etc.
Right, the key issue is: Can I apply a security-only patch, fairly confident that it won't introduce any regressions or break anything else in my app?
With Rails, the answer is hardly ever 'yes'. If your Rails versions is too old (which can often mean only around 12 months old), there will be no security patch released -- you've got to upgrade to a new version to get a security patch, with all the treadmill time that entails. If there is a security patch release, it is often bundled with other changes that come with risk of regression (and often deliver on that risk).
I agree it's a "double edged sword"/trade-off to Rails quickly evolving nature. But the pain is very real for many of us.
I would definitely hesitate to deliver a Rails app to a customer that did not have sufficient in-house technical expertise to maintain it. I would not have nearly the same hesitation with a PHP app or an html/javascript-static-only app, even though all of them can need security patching (although the html/js only one probably only has security holes that effect the client!).
If it touches a server and a database then it has a broad attack surface, at least Rails covers a lot of the basics for SQL injection, XSS, and url manipulation.
And, you can patch a Rails app yourself in a lot of cases or go grab a gem that implements the fix for your legacy version. With Github still living on Rails 2, theres a lot of unofficial support out there.
Rails 3.2 is over two and a half years old.
...this is all ancient history now though. Come on, 2 seconds on google will find all the arguments and counter arguments about this stuff.
>>In several interviews, the Twitter developers have pointed out that Ruby on Rails was not responsible for their scaling problems. On the contrary, only the maintainability of Ruby made it possible to do such large-scale architectural changes to fix their scaling problems.
Then again, that seems to have been written in 2010. I'm sure things changed since then.
http://stackoverflow.com/questions/3514633/do-ruby-on-rails-...
Clearly, finding unofficial patches on github and applying is entering the realm of "this thing sure is painful to maintain", isn't it? Especially if you have multiple apps (at different legacy Rails versions) to maintain, and/or you are an enterprise that hired a contractor to deliver an app but has no in-house Rails expertise.
Yes, yes, then you might say "Well, then don't do that, keep your apps up to date, don't take on Rails apps without in-house expertise." Exactly, right. So we agree.
I have yet to read a major "moving on from Ruby" story where it was clear that the use of Ruby and/or Rails was a mistake from the beginning. An architecture that works for 1000 users/day will need to be revised for 100,000 users/day, but that doesn't mean that it would have been a good idea to use the 100k architecture for the 1k product.
Ruby itself has made major jumps forward in performance since then. Much of Ruby's reputation for slowness was earned on an interpreter that no longer exists. It's still not the fastest dog on the track, but it is a ton better than those earlier days.
Yes, bugs happen, in-retrospect-wrong decisions happen. This is life. And this is part of what makes maintaining a handful of Rails apps developed under different Rails versions a pretty labor intensive thing, even with no new features.
Rails maintenance policy is summarized in the OP we are discussing. Rails 4.2.0 is now in beta. Once it is released, support policy is no more security fixes for 4.0. Rails 4.0.x was the latest Rails release until April 8 2014 when Rails 4.1.0 was released. So if you developed an app against the latest Rails minor version in March 2014, within 6 months your app is on a version that doesn't even get security updates, and needs to be upgraded. Yes, it's probably not that hard to upgrade it in this case.
And, yes, when you have a handful or more of legacy apps, and upgrades happen every ~6 months, you spend a non-trivial amount of time on the treadmill. This is my only point. I am not a Rails hater. I use Rails daily. I know of nothing better. There are all sorts of reasons that lead to maintaning Rails apps being such a time-suck, and none of them are that Rails devs are mean or moronic. But it is astonishing to me that Rails inspires a level of 'fanboy'itude that has people insisting that in fact it's not hard at all to maintain legacy Rails apps. Have you done it? With more than one app at a time? With more than 5 apps at a time?