Hacker News new | past | comments | ask | show | jobs | submit login
Rails 4.2.0 beta1: Active Job, Deliver Later, Adequate Record, Web Console (rubyonrails.org)
322 points by jyunderwood on Aug 20, 2014 | hide | past | web | favorite | 132 comments



Rails gets a bit of negative press these days, but its nice to see the framework moving forward. Rails is still a great choice for a large percent of web apps. There is a fairly big community even in smaller cities, a very complete framework, a large ecosystem of gems, open source and still improving.


Yes it is nice to see continued progress! Could someone explain to me what this negative press is about? I understand that Rails and Ruby by default are not as performant as Node/Go/the JVM but it supposedly functions quite well for relatively large websites (~10K users).


Here are some Rails sites: Basecamp, Github, Shopify, Airbnb, Soundcloud, Indiegogo. All have millions of users.


Here's a list of about 35 popular Rails sites I've compiled: https://onemonth.com/ruby-on-rails-example-sites


This list says little about Rails' productivity benefits without also stating how much is hidden behind it (in terms of queues, caches, async workers, etc.) to let those services handle their job.


I think you mean 'relatively small websites (~10k)'

...but yes; thats the main complaint of any substance.


Which is confusing. I thought some huge websites (Twitter and Hulu come to mind) use Rails?


Twitter is particularly notorious for once being an extremely heavy user of rails, then in ~2010 for abandoning ruby for the JVM and reporting the result was substantially faster.

...this is all ancient history now though. Come on, 2 seconds on google will find all the arguments and counter arguments about this stuff.


Twitter is also particularly notorious for blaming Rails when it is/was blatantly obvious their architecture at the time was a total mess. Including using Rails for stuff that should have been factored out into a separate shared-nothing backend service regardless of the frontend language/framework. They could have rewritten in pretty much anything and made it faster/more reliable.


LinkedIn also had a "Rails->Node" success story where their original architecture used a Rails app as a thick proxy to (apparently relatively slow) backend services. It should be unsurprising that Rails was a bottleneck in that case.

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.


Twitter's experience was also on pre-1.9 Ruby, ie. before YARV.

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.


I've spent more than 2 seconds on Google for this topic. This StackOverflow post[1] was actually very informative. See the answer by Jörg W Mittag, specifically this quote:

>>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-...


yellowpages.com now yp was a large rails shop, and subsiquently moved to node.


Do you have a reference for this? I did a Google search for "yellow pages rails node", but it turns up your comment as the #1 result.


Knowledge from having worked there.


Here's why I will not touch Rails: http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-...

IMO it deserves bad press for favouring development speed over sensible defaults and safety. Frameworks should not be allowing SQL injection in 2014.


I've been working on a Django project for the last few months. In past gigs I've used Drupal, and even talked community with one of Drupal's corporate overlords at Acquia. I enjoy working with Ember and follow its releases. But I've never grinned and cheered for new features the way I do with Rails.

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.
Awesome! Despite the naysayers, I still feel incredibly productive in Rails, and am so happy it continues to improve.


Agreed. Having recently worked on an implementation using nodejs/express/angular going back to plain old Ruby/Rails is very nice.


Totally! And I sorely miss cool and helpful guys like Ryan Bates in the scene lately.


Chris Oliver's running some good-looking screencasts to fill those shoes: https://gorails.com/


Thanks! Great to hear someone's taken up the good work.


This is great, and it looks like it was modeled after the foreigner gem (https://github.com/matthuhiggins/foreigner).


Totally agree, still funny how long foreign keys have been absent from vanilla Rails ;) But I guess their lack just didn't cause enough pain for someone to add them (at least it didn't for me)


Rails lover here, but the original argument against used to be "you don't need foreign keys"


Here a rails committer.

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


There was a time when I used to advocate my fellow folks here at HN (and possibly even reddit) to go for a framework built on faster languages like GoLang or Scala or even using platforms like Node.js and avoid slower ones like Rails. Now, it's time for me to apologize to the community for giving you wrong advice [1]. Turns out I could never have been more wrong.

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...


My biggest frustration with Rails at the moment is maintenance of my Rails 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).


I feel you on the treadmill pain!

  (The fact that some of the things Rails adds seem
  unfortunate to me (turbolinks, spring), can add to my
  frustration too).
For those reading this, just wanted to add that the Rails team puts a lot of effort into making things fairly modular. For example, disabling "turbolinks" is as easy as removing one single line from your .gemfile (the config file in which your gems are listed)


And remove `//= require turbolinks` from your application.js. And remove `"data-turbolinks-track" => true` from your stylesheet_link_tags and javascript_include_tags.


Or rails new hello-world --skip-javascript


But maybe you don't want to skip all javascript.

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.


A friend of mine focuses on just this: Keeping Rails apps up to date and maintaining existing projects:

https://www.linkedin.com/in/alsnow

http://rails-uptodate.herokuapp.com/


Does he enjoy that work? It sounds miserable to me.


Sounds like teams might pay a lot to have someone else do it :)


It's definitely a double-edged sword, but I don't think Rails could have staid relevant without being one of the most aggressive frameworks in terms of breaking backwards compatibility.

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.


I don't really see on Rails being wrong for a one-off project. It should keep running just fine as long as you don't update anything. The only thing they'd be missing out on is security patches, but what language/framework doesn't have security patches that requires updating something? It usually isn't too important anyways, as long as the app isn't externally accessible.


> The only thing they'd be missing out on is security patches, but what language/framework doesn't have security patches that requires updating something?

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!).


>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.


Sure, you can do lots of things to try to maintain your old Rails apps, but none of them are easy and reliable, especially for those who aren't Rails experts (but may be developers).

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.


Holding Rails to a minor version is quite easy (just specify it in your Gemfile) and updating patch levels shouldn't break any of your code. And security updates are still being released for Rails 3 where applicable, although 4.1 and 4.0 have already come out since then.


Updating patch levels _has_ broken my code, several times, over the past ~18 months. Sometimes it's acknolwedged as a regression and another patch is released fixing whatever went wrong; there has been at least one time that did not happen (I could find it if you really don't believe me).

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?


I second this. I recently did a port from Ruby 1.8.7 to 2.1.2 for a large Rails app (approx. ~350kloc between test and app) and in the process I was forced to update lots of dependencies. In a few places so called "minor" patches had big effects. It became clear to me that when your app gets to a significant size juggling the interactions of constantly moving versions of your Gems, Ruby, and Rails causes things to become complicated quickly.


If your Rails versions is too old (which can often mean only around 12 months old), there will be no security patch released

Rails 3.2 is over two and a half years old.


What forms of software development don't involve maintenance and upgrades?


It's a matter of degree. I have PHP apps which have run for years with minimal hands on them. All they need is an upgrade to PHP, which sometimes doesn't require touching the app source code at all, or sometimes requires relatively minimal (compared to my rails experience) updates to the source.

(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.)


I guess they all do to an extent although I've been mucking about with web2py partly because of their "We have not broken backward compatibility since version 1.0 in 2007, and we pledge not to break it in the future" stuff.


I understand your points and mostly agree with them, but there are valid situational counter-arguments for them too:

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.


And herein lies the issue. As engineers we long to solve 'special' problems, and fool ourselves into thinking we need to do something novel and hard when something simple will do.

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.


Re: Hindley-Milner, this one is really really tough and I am not convinced either way yet. The problem is that it's so easy to whip something up in Ruby and then write a slick rspec suite that ostensibly shows that it does what its supposed to. At the time you launch this there is no value in strict type safety because it's easily testable and self-evident that it works.

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?


Completely agree. There's a continuum of, to simplify - dynamic typing -> static weak typing (C, C++, Java) -> static strong typing (Hindley-Milner, Haskell, etc).

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.


Totally agree! FWIW, I'm betting on Hindley-Milner in the long run. The thing is, is it as important as something like library availability, good docs, etc.? Often times the answer is no.


Hindley-Milner + library availability + good docs => F#


If I could upvote you twice, I would. The number of times I've had to argue with developers over how unique their situation is and why they've had to go and re-invent the wheel for situation X is disconcerting.

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.


There can actually be business value in novelty for novelty's sake. For a startup there are two markets: those of customers and those of employees.

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.


To answer your criticism to the original criticism: 1) Rails is not really THAT expensive, especially when you're just trying to build a small business website. The people who complain are actually the ones who are exactly working on those "funded startup" you mentioned. 2) There are tons of huge apps out there that run on rails just fine. You hear about stuff like Twitter switching to other language because rails is "too slow", but Twitter is like the rarest exceptional case you'll ever find. I mean, do you know of any other web app where realtime is as important as Twitter AND is at such a huge scale? Most websites don't. 3) It's actually more like "Most of the times you use readily implemented libraries and in rare cases you need to use your own". You can't iterate fast when you have the mindset of trying to fix everything. You need to pick the most important problem you're trying to solve and do whatever it takes to reach product market fit as quickly as possible. I have played around with node, express, etc. to build webapps and was at first very intrigued. I did that for a while, and then got frustrated with the lack of convention i can just mindlessly follow as well as all the convenient tools rails provide. So I came back and couldn't be happier.


> 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.

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.


While I totally agree with your main points, I suspect that a large part of the difference in productivity you describe is a result of your familiarity with Rails and its ecosystem. If you've done many projects in it, have established workflows you're comfortable with and know the framework inside and out, of course you are going to be more productive compared to using a less familiar technology.


Precisely. I respect Neya's point of view, but I interpret it as not specifically about Rails or other specific frameworks, but rather as a cautionary tale warning against needless branching out and exploration of other languages and frameworks. In other words, his experience seems to be a data point suggesting that you stick with what you know unless you have a strong need to diversify.

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.


Yeah, the same logic could be used to argue for using Java or PHP frameworks.

Plus, SASS/Compass/HAML integration isn't strictly part of a framework, it's the build pipeline.


Can you point to what you think is an example of a good open source web application written in Go? I'm curious to see what non-trivial web applications in Go look like. I've tried Go for web applications a couple times, but I ended up feeling the same way you do about it. I've really liked it for backend things, however.


> Can you point to what you think is an example of a good open source web application written in Go?

* 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.


We made https://github.com/sourcegraph/thesrc as an example large open-source web app in Go because we also wished we had examples like this when we were starting.


> The actual thing you want to be able to do is quickly iterate on your product and constantly have it evolve.

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 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.

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."


You are mainly talking about web development. Golang is young and we dealt with the same problems at earlier versions of ruby and rails. But, outside web development, in most of my needs, golang was a better choise than ruby. Saved some servers running golang instead of ruby and had cut significantly the month cost of my startup.


> If you need to deliver faster (and in most of the cases BETTER), go with the language and tools you know more!

A little related: http://pablocantero.com/blog/2014/04/20/i-coded-a-backbone-a...


So what if you are giving bad advice again? In six months are you going to come back here and say 'Oh sorry I said you should use Ruby. What I REALLY REALLY REALLY meant was that you should be doing all of your coding in Perl'. Nuts to you man.


You are definitely wrong about item 2. The speed of the language may not be the only deciding factor but it should be one of the deciding factors. Saying it has NOTHING to do with success is short-sighted and shows that you are giving bad advice again.


i fail to understand why you would want to rebuild everything when using scala, we use it successfully with spring. Or rather just use grails and at least have the jvm. Rails is slow, yes it scales well, but other things scale as well (or better) and will cost you less to run.


Truly impressive. I'd also like to see the Rails team focus on Rails-as-API for those of us who have moved on from the asset pipeline (splitting the server side from client side).

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...


> It would be nice to have a "API only" flag option when generating a new rails project.

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)



So GlobalID means instead of doing `SomeJob.enqueue(instance.id)` (and then `Model.find(id)` in the job) you just do `SomeJob.enqueue(instance)`, and presumably reference something like `object` in the job?


Yes - there is a good example on the ActiveJob README (https://github.com/rails/activejob#globalid-support).


We frequently ran into the issue of the object having been deleted while sitting in the job queue, so Model.find(id) would blow up. I'd be curious to hear if GlobalID did anything about that.


We had a bit of a discussion about that, finally settling on adding `rescue_from` which you'll know from ActionController and raising a `ActiveJob::DeserializationError` wrapping `ActiveRecord::RecordNotFound`, allowing you to handle this lookup failure however you see fit.

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.


This won't do anything for you there; it just collapses a Class and a record ID down into a string for you (and then pulls it back out of your database later with a GlobalID::Locator.locate(string) call).

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.)


You do GlobalID.locate(gid) in the job.


That's incorrect. The global ID sent along the wire is transparently looked up at deserialization.

See the example here: https://github.com/rails/rails/tree/master/activejob#globali...


Yes, exactly. It is an interesting/cool idea to create an object URI to make this possible!


Beware, this behavior lets you shoot yourself in the foot because when you conduct your job, you might be working with a stale object that's changed since the job went on the queue.


That's incorrect. This is not YAML-style full object serialization, but rather a global ID being sent along the wire that is transparently looked up at deserialization.

See the example here: https://github.com/rails/rails/tree/master/activejob#globali...


Is it? I assumed it worked like delayed_job which gave me issues due to the problem I mentioned.


It is! That's the exact problem ActiveJob+GlobalID tries to solve.


I suppose I was mistaken then, thanks for helping me understand.


why bother spreading false information without even taking a minute to read into what it actually does?


My biggest gripe about Rails are the model validations and DB adapters.

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.


Sorry to 'hijack' the thread but I was wondering, as a newcomer to Ruby and Rails, what would be the best way to learn it? (without spending too much money).

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?


The Hartl book is considered one of the best introductions, and covers all the major Rails features and conventions. It's free to read online, and there is also great support for it via Stack Overflow.

http://www.railstutorial.org/book


Thanks for the plug. Be sure to watch for an upcoming announcement, too:

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.)


+1 start here


After reading the official guides (http://guides.rubyonrails.org) the next place to go is Railscasts (http://railscasts.com). Make sure you only watch the episodes for Rails version 3.2 and greater. Each episode is linked to a github project featuring complete Rails apps - read and modify those apps.


The Hartl book others have mentioned is better than the guides if you need to know what todo not just how to do it (if you are new to web development rather than switching frameworks).

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.


GoRails.com has new railscast-style videos.


I have to second the official guides. They're mostly great.


If you're a total beginner or at least relatively new to it, the Odin Project is comprehensive and free: http://theodinproject.com.

Edit: I created it, so I'm biased


This popped up recently and seems to be updated regularly: https://gorails.com/


Nice to see some of the features from better_errors make it in - I always figured it'd just replace the standard exception page.


You don't need to make everything scalable right from the start. If your business is profitable you should have enough money to think about scaling later.

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.


<%= console %> is a godsend


I was able to run bash and vim inside the browser console. And Tmux. And I could run vim inside of Tmux. Split windows, multi-tabs, htop. Guard, rspec, pry-debugger. Everything worked.

WOW


I'm quite surprised by removing `respond_with` to a gem.


I'm pretty sure that 90% of my controller actions use respond_with. I don't understand the desire to remove that from the rails core.


A big thank you to all the contributors who keep making Rails better and more polished at each release. Rails 4.x is great.


What's the difference between the Web Console in this release, and the IRB console that comes with Better Errors?


I had issues with better_errors where, if I would make a dumb-ass syntax mistake somewhere, better_errors would send me up to the superclass of the error stack, whereas the regular error page made it easier to decipher exactly what the mistake was.


For one, web console is built in. Other than that, I imagine not much.


I see. Should check it out, then.


I'm excited for the ActiveJob abstraction layer. This means I can start building things out for background work before even deciding what I want to have handle them.


Oh God yes, at last, 4.2. Real foreign keys, active jobs, deliver_later, etc. I guess it's true, Overlord DHH really does hear our prayers.


Just saw this in the release notes:

    The PostgreSQL adapter now supports the JSONB datatype in PostgreSQL 9.4+. 
Indexable/queryable JSON - so fantastic.


Along with that, one of the hidden gems is that dirty tracking now detect inline changes correctly. This means things like JSON/JSONB columns Just Works™ out of the box.


Nice!

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?


One of the things I like best is the pre-announcement that Rails 5 will be built for Ruby 2.2. I appreciate the role that DHH and Rails play in keeping the community moving forward.


Yes, this should clean up a ton of the code in rails. Can take use of exception causes and all the other things.


will there be a 420 celebration when it comes out?


Well I'm glad someone beat me to making this kind of comment.


I love Rails, it's been my tool of choice for the last six years, but "Support for real foreign keys!" shouldn't be a thing in a change-log in 2014.


So you don't want support for real foreign keys?


He probably means that foreign key support should have been added in a far earlier version of Rails.


"Adequate Record" does not exactly fill one with confidence regarding rails. This says "our last versions had inadequate performance,this one is just ok"


It's all tongue in cheek from tenderlove, someone with a long history of contributing to ruby and rails.

  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.html


Sorry you felt that way. That project was sponsored by http://adequatehq.com/, so we don't really have much controll over that. Try emailing their marketing department maybe?


Oh, this reminds me of that Bill Hicks clip.


If you watch the closing keynote to RailsConf 2014, Tenderlove talked about that.

It 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.


It's kind of silly to judge new features on their name, no? Adequate Record caches lookup strings, which increases AR performance considerably.


I feel rather underwhelmed by the performance improvement touted by adequate records. Perhaps someone from the rails community can do something like this: http://techspot.zzzeek.org/2010/12/12/a-tale-of-three-profil...


100% speedup is underwhelming?


100% speedup to certain queries, not all queries. How many queries it covers will depend on the app; as well, of course, how much of app wall time is taken up on queries.

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?


(And the queries that are speeded up by this optimization are probably the _fastest_ queries in your app to begin with--simple one column lookups on one table, including probably most commonly lookups by pk. I am definitely not assuming this will make any measurable performance difference to real world apps. Although it may. I don't know if anyone knows yet.)


Also from http://stackoverflow.com/a/16553503 by the author of SQLAlchemy:

> 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.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: