Thinking more and more that spec/support is an anti-pattern. I don't want everything required for every test.
I came to this thought when I was working on sharing testing support code
between an engine and an application, for an example in Chapter 4 of
Multitenancy with Rails. What I had
originally was a file in spec/support called SubdomainHelpers, defined like
this:
module SubdomainHelpers
def within_account_subdomain(&block)
context "within a subdomain" do
let(:subdomain_url) { "http://#{account.subdomain}.example.com" }
before { Capybara.default_host = subdomain_url }
after { Capybara.default_host = "http://example.com" }
yield
end
end
end
This module is then used to extend the RSpec describe blocks, like this
describe "User sign in" do
extend SubdomainHelpers
...
end
And then we can call within_account_subdomain whenever we need it.
My problem with this is that this file is required all the damn time, even in
tests which don't use Capybara. The culprit is this default line in
spec/spec_helper.rb
Dir[File.dirname(__FILE__) + "/support/**/*.rb"].each {|f| require f }
This line is used for requiring all the files in spec/support so that you
don't have to. Seems like a good idea, but isn't once you have a ton of things
in spec/support.
Making it easy to require the file defining SubdomainHelpers in both the
engine and the application involves moving the helper in to the lib directory
of the engine, and then requiring that file in the appropriate places:
require 'subscribem/testing_support/subdomain_helpers'
Even if we weren't using an engine and an application and just had the application, I would much rather just be requiring just the files I need for a test, like this:
require 'support/subdomain_helpers'
Than having the full range of spec/support files loaded all at once on the
off chance a spec might need it. I wouldn't expect this to dramatically increase a spec suite's
run time, but it's got to be helping somewhat.
The idea for the book has been around for a while. A couple of friends (Phil Arndt, Josh Adams, Rob Yurkowski and Andrew Hooker) and I had been talking in our secret IRC back channel about what a more advanced Rails book might cover. Through I don't know what process, we came up with this idea and I'm putting it into book form.
For now, all the book is covering is what we're building, which is a hosted forum application, how to build a foundation for the subscriptions engine and then how we're going to accomplish the database scoping necessary to separate the accounts' data.
The engine is what the book's application is going to heavily rely on. This foundation building deals with adding things like accounts which have subdomains, and then authenticating users for those accounts using Warden, and not Devise. To find out why, you're going to have to read it.
The chapter on scoping first of all covers using a database field, which is the typical way
that people have been dealing with this problem for years, and then covers the
"new" way of doing it: by using PostgreSQL schemas and the apartment gem.
The next chapter, Chapter 4, will cover building the application which will combine both the subscriptions engine we build in Chapter 2, as well as the Forem forum engine that the aforementioned folk and I build and maintain.
Chapter 5 will cover subscriptions, where each account could be subscribed to the application for an amount such as $29/month and that allows them to create 5 forums. That sort of thing. It'll also cover taking payments for those subscriptions using Stripe's wonderful API, and then what to do if somebody decides to do a dodgy.
Testing (with RSpec and Capybara) is throughout, just like with Rails 3 in Action.
So if you're looking for a book that covers all of the above, please buy a copy of Multitenancy with Rails right now.
]]>One of the things that allowed you to get up and running so quickly was the scaffold feature of Rails. You would run rails generate scaffold posts and there you would then have a scaffold for posts that would allow you to perform CRUD (Create, Read, Update and Destroy) actions on these posts. Back in Rails 1 days, it was a simple one line in your controller: scaffold. In later Rails releases (can't remember right now which one specifically), this was changed to generating the familiar scaffold controllers you see today that provide a HTML and XML response, or even more recently, a HTML and JSON response.
Scaffolding is great for getting something that will allow you to perform those CRUD actions on it. However, the moment you need to step outside that safe cocoon, you run into trouble. You want to add a new field to your database, say an author field if we're sticking with the Post scaffold idea. So you do that, but then you don't realise that you need to add the field to the attr_accessible list^1, and you'd need to add it to the form partial as well. Newbies don't learn how to do these very, very basic things first off if they're using scaffolding and that's why it's a bad thing.
If you begin using scaffolding, you can indeed see exactly what functionality Rails is capable of. Goodo, you can create, read, update and delete things. The problem, however, is that you end up not learning how any of it works, and it seems like "a wizard did it". Of course, as you get more knowledgeable about Rails you'll know that there's no such thing as wizards.
Learning from the ground up that in order to be able to display even a list of posts on a page that you need a Post model, that the model responds to an all method, that is then called in a thing called PostsController and then that information is stored in an instance variable which is then accessed by this thing called a "view" which has the same name as your action... that may seem like hard work at first (hint: it is), but it's worth it. That is because the moment you want to step outside the cocoon of a CRUD resource and do something differently, you'll probably know how to.
Scaffolding doesn't teach you the extreme basics of Rails development. Building things from scratch does. This foundation is absolutely critical to understanding how Rails works.
[^1]: attr_accessible is going away in Rails 4, being replaced by https://github.com/rails/strong_parameters
This decision has been a long time coming. Ever since I started working for Manning I've had issues with their tooling. I covered these in posts like "Don't print hard-copies" and "The Writing Process"). They've been saying now for two years that they were going to fix it and... nothing much has been done.
I got so frustrated with their system two weeks in, I decided to write my own. I demonstrate part of Manning's system and part of my own, in this short video. I wrote my own review system in a relatively short period of time.
The writing tools are something that I need to use everyday and if they're just getting in my way, it totally kills my vibe to write. I don't want to hate writing, because I love writing. I love the feeling I get when I can clearly explain something to someone the first time in writing and they just get it.
So, no more writing for Manning because their tools for doing it are terrible. The people at Manning are nothing short of excellent.
Rails 4 in Action will be published by Manning -- they have the rights to the book, not me -- meaning they will need to source another author to do it. For any questions related to that process, contact support@manning.com. They'll know more about it than I do.
All of that doesn't mean I've stopped writing Rails material completely. Oh no no no. You just wait.
]]>Honestly: I can't think of a single thing that I think would be entertaining for a wide audience to listen to me talk about. I don't want to submit a talk based solely on the notion that I'm supposed to be a mildly-famous member of the Australian Ruby community. What a crap premise to submit a talk on! What on earth could I possibly give a talk about and make informative for a large audience?
I'm not going to talk about writing a book because I already moan and bitch about that enough on Twitter. Plus, the actual act of writing a book isn't exciting.
I'm not going to talk about documentation because nobody gives a crap about proper documentation, save for a very small select group of people and the people who are reading it. Don't bullshit me. You know it's true.
I'm not going to talk about engines in general because there's already a great guide that covers 95% of what a conference audience needs to know. Chapter 17 of Rails 3 in Action covers it and a bit more also. No point giving a talk about something that's already been written about. Personally, I go to conferences to see new, cool and interesting stuff. Not things that I can read about or watch on the Internet.
I'm not going to talk about my work on Spree because -- and I say this without intending an arrogant tone -- the work itself is self-evident and you don't need to hear about it at a conference. I'm especially not going to talk about my thoughts on how to split up a monolithic engine such as Spree into smaller, easier to manage components. That checkout state machine work that I did? Excuse my brashness, but that was fucking awesome and I'm so damn proud of it, but I'm not going to talk about that either. Allowing Spree stores to choose their authentication backend? Please. It was just this thing I did. It doesn't deserve a whole conference talk.
I'm quite happy, this time, to sit there and be an audience member who is learning about all the new, cool and interesting stuff other people are doing.
]]>What was happening was that in Google Chrome, the page was giving an "aw snap!" error. So I went to Firefox, where the page didn't "aw snap", but instead hung for a moment then asked if I wanted to stop the script.
What could that JavaScript be doing? Well, it's not that hard to understand now, but it didn't click the first couple of times I read it.
The script initializes a new JavaScript array, like this:
var variant_prices = new Array();
Fairly innocuous. We would've also accepted var variant_prices = [];.
Next, it uses some ERB to go through all the inventory units for an order and then assigns each variant to the array, using the variant's id as an index in the array. If a variant has an id of say, 1, this is not a problem. Why? Because JavaScript is smart enough to know that it should create a two element with variant_prices[0] being undefined, and variant_prices[1] being whatever value is assigned.
However, if the variant's id is something a little higher, like 1,013,589,413, then you start to run into problems. In that case, JavaScript would create a one billion, thirteen million, five hundred and eighty-nine thousand, four hundred and fourteen element array. All to store one value in, right at the end.
Obviously, this is not very efficient and would lead to some performance degredations. Smart browsers would detect this early on and show a vague warning screen and dumber browsers would ask politely if you'd like to stop the script. Which script? Well, they won't tell you that. You have to play guessing games, like most of the time with the beautiful language that is JavaScript.
The now obvious solution to this problem is to not use a JavaScript Array for creating what is obviously a key-value store. Instead, the variable should be initialised like this:
var variant_prices = {};
Then you would be assigning keys to the JS object, rather than values at specific indexes in an Array which could have a billion elements.
]]>AWESOME! " Also, I’m 24. What makes you think I have any damn right being a Chief of any department?" - @ryanbigg
— Federico Soria (@fedesoria) May 24, 2012
@ryanbigg that's just... Wow. Thanks for sharing.
— Robert Pitts (@rbxbx) May 24, 2012
@ryanbigg haha made my day. The hype for programming has ppl heads spinning #ittakestime
— Marcell Purham (@Marcellpurham) May 24, 2012
Others were humourous:
“@ryanbigg: What happens when a scummy business guy tries to hire me: ryanbigg.com/2012/05/how-no…” Rubydramas.com about to be reset.
— Tom Meier (@pommytom) May 24, 2012
And others really hated it:
You're neither clever or elite when you're rude to recruiters, you're just a dick.
— Ben Schwarz (@benschwarz) May 24, 2012
.@ryanbigg just so you know mate, you're a front for our community - a popular person. Don't be a douche - be like matz, be nice.
— Keith Pitt (@keithpitt) May 24, 2012
@ryanbigg "Do you have any idea who you’re writing to?" is the most douche baggy comment of all time. And you started with it…
— Keith Pitt (@keithpitt) May 25, 2012
@ryanbigg oh I'm sorry that you expect that. He should known. You're a fucking idiot mate. I'm thankful for the hard work you've done.
— Keith Pitt (@keithpitt) May 25, 2012
@ryanbigg You fuelled that conversation. Results would have been much different with a simple, polite "no thanks", or even by ignoring.
— Justin French (@justinfrench) May 25, 2012
@ryanbigg @keithpitt Well, to be fair, it isn't hard to just politely reply "thanks but no thanks." We all get these emails...
— Fred Wu (@fredwu) May 25, 2012
Others suggested I just hit ignore:
@ryanbigg Long term, your biggest regret will be wasting your life conversing with the fellow.Learn to just hit "Archive" and move on.
— Mike Perham (@mperham) May 25, 2012
@ryanbigg "No thanks."
— Justin French (@justinfrench) May 25, 2012
Everyone's entitled to have their say about this, and I'm sad that so many people took offense to something that I genuinely believe should have been done.
To make it clear, I don't like being cold-called. I think it's invasive and generally a waste of everyone's time. In the case of hiring, for a business person to cold-call a whole bunch of programmers shows that they don't care about who they hire. They just want somebody to fill their position.
I think that they should care. Why? Well, the business person is going to spend months, perhaps years of their life with this person. How do you know that person is going to be the right fit for your job? What if that person is a complete douchebag who will post most of the conversation on his blog and laugh about it?
All I ask is that people who are looking to hire other people do their research first. Find out what they love doing and appeal to that, if you can. Invite them out for a lunch discussion or if that doesn't work, a post-work drink or two. Cold-calling just anybody is most likely not going to land you the right person for your job. Go to meetups, programming events and meet people. Don't meet them just for the sake of seeing if they're wanting to go work for your company, but meet them to understand what their type is like.
To not do the research first shows a blatant disregard of care for the person that you're contacting, and I honestly think that contacts made in this fashion cannot work out. Find common interests, discuss them in polite ways and see if you're a fit. If you're not, move on. Do your research on the next person.
I agree that I started the email thread wrong. As I said before, I felt invaded by this email. Sure, I could've ignored it and sent it to the Archive/Trash, but that's not my style. If I am sending an email to a person, I expect a reply. Not an instant one, of course. Perhaps it would take a week or longer. But still, a reply is always nice.
Replying in the way that I did was most certainly wrong. Cold-calling someone without doing any level of research before is wrong also. We were both wrong. Replying to somebody validates that "Yes, you are worth my time". That's the essence of why I reply to every single email that is personally addressed to me.
I want to make it so that recruiting in programming doesn't suck as much as it does now. Companies just want bodies, and while that makes sense in a business fashion, how do you know if the new hire will be a good fit for the team or not and secondly if the work is interesting to them. If the new hire doesn't fit with the team, then there'll be conflicts and inevitably someone will have an ego bruised, or worse. If the person doesn't enjoy the work, then they're probably not going to work as hard as they could. Both of these things are absolutely vital to making someone fit in at a company, in my opinion.
I know all too well how fucking great we have it in this industry. I can announce on Twitter that I'm leaving my current job and within the day I have at least 5 companies saying "Come work for us, please". I know how well we have this because I've seen what happens in other industries, in a second person fashion.
Recently, both my mum and her husband were out of work, and were struggling to find jobs. They weren't able to put out on Twitter (or Facebook) that they were looking for a job and get picked up by a spectactular company within the same day. They had to work damn hard to find new jobs, and they've done just that. Even with all their experience (they're in their 40s), it was still a struggle for them to find a job.
So yeah, I know how great we've got it in this fantastic industry of ours.
I'll practice not being an arrogant asshole, and I'll expect people who are in the business of hiring others to practice doing their research. Together, we can make this thing work and keep building this great industry.
]]>Hi, blah blah blah seed funding blah tech startup blah blah blah no programming experience blah blah blah advertising platform blah blah you will be CTO blah blah blah blah blah*. Thanks, M.
I've obviously taken the liberty here to modify his wording slightly, but you get what he was trying to say.
I was a little upset because he didn't do his research. So I emailed back in my best arrogant famous person impression:
Do you have any idea who you're writing to?
To which he replied:
Yeah I think it was intended at you, that's why the email was addressed to your inbox...
It was at this moment that my hand went to my face in a rather quick fashion. The next thing I can remember is only feeling half my face and laying on the floor. I picked myself up off the floor and wrote a longer email:
I am not "open minded to the possibility of also becoming CTO later down the track" because I already work at a company called Spree Commerce as the Community Manager. This email does not represent them, because it's my personal email. I wrote a book too, called Rails 3 in Action. I'm actually writing the second edition now. Also, I'm 24. What makes you think I have any damn right being a Chief of any department?
Do not think that you can simply pull people away from a company with buzzwords and hand-waving. In today's industry, you need to "court" people and make them want to work for you. Cold-calling them is at the exact opposite end of the "What to do and what not to do" scale.
He then asks:
In response to your statement "In today's industry, you need to "court" people and make them wanting to work for you. Cold-calling them is at the exact opposite end of the "What to do and what not to do" scale". How can I go about courting people in a way that I can gain their trust and attention without looking like some other annoying business guy? However I must say your advice is flawed in some ways because either way I can't just wait for people to come to me, so there has to be some element of cold calling whether it's emailing or approaching them unannounced.. Unless you have better advice and I'm all open to hearing it
Regarding the "annoying business guy", he's gone past this point at this stage.
I reply back suggesting things like user group meetings and Railscamps.
Anyway, this kind of goes on for a couple of emails and Mr. M does his research eventually. He then goes into full-sleazy-business-dude mode:
... but if you wanted to work with me full time I would give you a meaningful amount of equity (at the cofounder level) I would also make sure your rent, internet connectivity, beer and basic essentials would be covered;
You cannot buy me out with equity, suggestions that you'll pay my rent, internet connectivity, beer (even though I don't drink beer) and basic essentials. So I tell him that:
No, absolutely not.
You would be dealing a great blow to Spree if you did that, and honestly your work doesn't interest me. I hate advertising, because most of it is pure crap. I'm actually considering paying $6.99 each month for Spotify not because I want access to new music, but because I want to get rid of the ads.
Your equity offer would be paltry, no doubt. Do you have any idea what I earn at Spree? Do you have any idea what I charge per hour for consulting gigs outside of my daily work?
Yes, you say you would pay for rent, internet connectivity, beer (although I don't drink it) and basic essentials. That is, in combination with the equity, not even coming close to the emotional compensation I would need for selling my soul to an advertising platform.
The last part about "emotional compensation" is a joke, by the way.
He also said this:
In under just three months you would be able to figure out whether it would be worthy or not putting more of your time in this startup since from the launch date for the website to function we need direct money inflow.
So no direct money inflow at the moment. This is a huge red flag to me. "Yes, please work for a pittance but I promise we'll be making money hand over fist any time now!". I'm not a business guy, but I think this guy is a little crazy by this point.
Oh, he also said I could "influence millions of people". I replied:
I have made my decision. I am sticking with Spree and no amount of equity, technical challenges, narrowest possibility of influencing millions of people or money will change that.
Then the biggest email from this whole saga arrives in my inbox. It begins with:
I'll try to make this quick so that I don't continue wasting my time as well as your time..
It's nine-hundred-and-ninety-five words long. This many words is not quick.
I told him this in a previous email:
You most likely will not change the world. Fact
He replied with:
The fact that you added "most likely" infront of will not change the world, expresses that there might be a slight possibility of it happening, which contradicts the "fact" part at the end. But to answer your statement, I will be very happy one day when things do work out and that everyday when you are browsing the net, you will be faced with a constant reminder of how pessimistic and truly wrong you were, as well as receive an email from me saying "I told you so"... Thank you for giving me another reason to be motivated..
I honestly believe that he wouldn't change the world with an advertising platform, so I said so. I would rather be honest with people than to support their broken dreams. For him to reply in such a passive aggressive way threw up the biggest red flag of all of this so far.
Then he leads with this doozy:
Plus I think I'm starting to agree with Tyler Menezes, I do think that the Ruby on Rails community is run by a bunch of arrogant narrow thinking developers who are too important to show any optimism or support for outsiders..
Up to this point, I have been as nice as I can be to somebody who cold calls me. Which is actually really nice. I was being painfully honest with this guy, and he took it as arrogance. Oh well.
Then he drops this other bombshell:
Therefore I'm choosing python, I've already started to learn the basics, I think it has so much more potential in terms of quality and scaling capabilities than ror.. Plus i'm finding it a lot more fun to learn (but it's still very challenging and definitely not easy, but who cares, within six months I'll be good enough to lead a team of developers, even by learning part time).
HOLY SHIT. This guy is going to learn Python in 6 months and then lead a team. If I were a self-respecting programmer (hint: I am) I don't want to be in a team that's led by someone who's got only 6 months experience in my programming language. And by only learning part-time? Please.
He also claimed that I drink beer:
You don't drink beer, oh ok well I didn't know that you just said false things for the fun of it, why would you make multiple references to drinking beer at railscamp if you don't drink any beer? Or do you just put out a different appearance in public then you do in private?
Not once in our email correspondence did I ever mention drinking beer. He later brought up and said that in my RubyC talk at around 14:53 I mentioned drinking beer, but this is not true. This whole passive aggressive tone of the email was extremely off-putting, and exactly the opposite direction of how you would go about hiring someone.
He finishes off his version of the Iliad with this:
Ps. this isn't over, within a year you can expect an email form me saying "I told you so"....
I've actually put a reminder in my calendar for next year to remind me to go back in my inbox and find his email and ask him how it's going. I'll be genuinely curious to see how far he's gotten with this idea.
I was extremely offended by his bravado and passive aggressive tone. I replied over two emails. The first was:
I am bored of this game. Never email me again.
The second:
Also, I never mentioned anything about drinking beer. Just thought I'd clear that up.
He replies with a single line:
I'm pretty sure you did
I am still extremely frustated at this:
And now you've just devolved to basic trolling. Fucking long sigh. Seriously dude, look through the emails. Not once did I mention drinking beer.
He replies back:
I don't know why you're only focusing on this one beer drinking thing, that was the least important comment throughout my email... I'm not saying you mentioned beer drinking in our emails, you mentioned beer drinking during your how to be awesome at rails presentation [at RubyC]...
I was never trolling, I reached out to you for help and advice and the entire time your responses have been filled with criticism, dream crushing statements, profanity and just fucking plain hypocrisy.
Not filled with criticism at all, besides the mentions that I would prefer if he used paragraph breaks and didn't cold call people. I suggested alternatives, like Railscamps and user groups. You know, actual actionable, effective advice. My statements weren't intended at all to be "dream crushing", just my traditional honesty. The only time I used profanity was the word "Fucking" in my email before. I was also never a hypocrite in my emails.
And then a little later on he replies for the final time:
Nah but I seriously wish you all the best, Hopefully there aren't any lingering hard feelings. That is that last thing I would have hoped for...
I wish no ill feelings on this guy. The tone of his emails was exceptionally off-putting and I can't believe that people think that they can get away with things like this. A little bit of courtesy on both sides of these types of discussions goes an exceptionally long way.
]]>I recorded it again at home last week and You can watch/download the video here. It's a little over 30 minutes long, but I think it teaches you valuable lessons about engines in Rails.
]]>Then my dentist suggested that I stop drinking drinks containing that much sugar, and so I did. I switched to Pepsi Max for a couple of years after that. Then, one day, I stopped. I can't remember the exact reason why I stopped drinking it, but I did. This was back in 2009.
The first couple of days were interesting. I had trouble focussing for long periods of time. I never got the caffeine headaches that people talk about. But then it got gradually better and I've been basically caffeine-free for close to 3 years now. Then it kept getting better. I found myself sleeping more solidly each night and being able to concentrate for longer and longer periods. I very rarely now have moments where I feel completely exhausted. When they do happen, having a some sugar helps for that last little bit.
Then there was the change in sleeping pattern in 2010, when I started writing Rails 3 in Action. I swithced from getting up at 7:45am to getting up at 6:00am. And I did this every day, except where I stayed out late the night before. That extra time in the morning allowed me to do some internet catch up, do some writing, have a shower and get ready for the day and then still have more time to do even more writing. After a late night out, there's that buffer there that I can use to catch up on sleep that I've otherwise missed. I can also use this time for exercise, which is awesome.
When I get to work it's no longer just over an hour since I woke up. It's more like three hours. With me not being a morning person by nature, this is wonderful. I come in to work and I've already woken up fully and I can just get to doing everything.
Tim Riley wrote about his experiences with getting up earlier too.
However, I've found this new approach to be very effective. The early mornings are a good time. It is quiet. The day has just begun and my mind is clear of any distractions, so it is easy to concentrate. Because the time for work has a definite ending, it also encourages me to pick discrete and achievable goals for each morning. Rinse and repeat, and before long, I have demonstrable, consistent, incremental progress towards my goal.
So, my thing I want you to try is to go the whole month of May by changing one of these two habits. Either cut out caffeine completely from your diet, or start getting up early in the morning. If you want the "Hard Mode" variety, try both. It's really improved my life and I reckon it'll do the same to yours.
]]>To be perfectly honest, I am probably bitter because I was going to submit a talk about engines and then decided to submit another talk instead which ultimately didn't get accepted. Nevertheless...
The first thing that I can recall disagreeing with is Andy's suggestion to draw routes for the engine on the Rails.application.routes object, by putting
this code inside the config/routes.rb file of the engine:
Rails.application.routes.draw do
resources :people
end
The problem with this is that if the application's routes file has a catch-all route at the bottom, the route for the engine won't get matched because it is drawn after the application.
This leads to additional complexity as well, as by drawing these routes on the application like this, they would also correspond to a controller that's at the
top-level of the namespace, i.e. PeopleController. This can lead to confusion as to where the controller is located. How can someone know if PeopleController is inside the engine or is inside the application? Furthermore, the more engines that get added to this application, the more confusing such a thing would get.
By namespacing the routes properly (as we do in Spree and Forem) , like this:
Spree::Core::Engine.routes.draw do
resources :products
end
And by using isolate_namespace inside your engine, the routes will be a completely separate entity for each engine, rather than one big "ball o' mud". In
Spree this namespace isolation is to the Spree module (i.e. isolate_namespace Spree), so that the controllers will be Spree::ProductsController and not
Spree::Core::ProductsController and the like.
By using a completely isolated namespace like this, your controller would end up being correctly namespaced and then there's no confusion as to which engine
the controller is located within. You can then mount your engine at whatever path you want inside your application by explicitly defining the mount point
inside config/application.rb like this:
mount Spree::Core::Engine, :at => "/"
By mounting it at root, it will seem as if the engine were a part of the application itself. If you wanted to change where the engine was mounted, it's a
simple matter of changing the :at: option and you can carry on like normal.
There's a whole bunch of other stuff that isolate_namespace does as well, like namespacing of models and tables. It's absolutely important that you namespace
your engine to avoid confusion.
Oh, and one more thing: by doing this namespacing, if you want to get to an engine route from inside the application, you'll need to call the engine's routing proxy method, like this:
spree.products_path
If you attempted to do products_path it would go to the application's products_path, which may be undefined.
Similarly, to get to the application's routes from inside the engine, use main_app:
main_app.people_path
The second thing that I disagreed with during Andy's talk was that he said that when developing an engine you needed to constantly switch back and forth between the application and the engine. This is simply not true. If you are developing your engine correctly, the development of it can be done in complete isolation from a real application and instead depend on a dummy application. It should not be a requirement for you to have two separate projects coupled together like this so you can test one or the other.
How we do it in Forem is that we have a dummy application inside spec/dummy which is generated by running bundle exec rake forem:dummy_app. This
command creates a new dummy application with things like
User model already set up inside it. Inside Spree, there's a similar command called bundle exec rake test_app which does basically the same thing.
With the dummy application inside the engine, the engine is mounted onto that application and the tests are then run against that application. No need to switch back and forth from application to engine.
If you have modifications for the engine inside your application, there's also a way to test that. With Spree, we provide a module called
Spree::Core::UrlHelpers that you can include into your RSpec.configure block like this:
require 'spree/core/url_helpers'
RSpec.configure do |c|
c.include Spree::Core::UrlHelpers, :type => :integration
end
Then in your integration tests it's simply a matter of referencing the Spree routes like this:
visit spree.products_path
Now for when you want to test that a customization to a Spree controller is behaving as intended, we've got a module for that too. It's called
Spree::Core::TestingSupport::ControllerRequests and you can include it like this:
require 'spree/core/testing_support/controller_requests'
RSpec.configure do |c|
c.include Spree::Core::TestingSupport::ControllerRequests, :type => :controller
end
Then you can write your controller specs like this:
describe Spree::ProductsController do
it "can see all the products" do
spree_get :index
end
end
This will then allow you to make requests to the Spree engine from inside your application's tests.
There's absolutely no reason to mount engine routes directly on Rails.application.routes, nor is there a requirement to switch back and forth. Integration
testing an engine is extremely easy once you know how to do it.
redirect_to :controller => "posts", :action => "show", :id => @post.id
What this would do is dutifully redirect to the show action inside the PostsController and pass along the id parameter with a
value of whatever @post.id returns. Typical 302 response.
Then Rails 1.2 came along and allowed you to use routing helpers, like this:
redirect_to post_path(@post)
And the people rejoiced.
This would do effectively the same thing. post_path here would build a route using the @post object that would look something
like /posts/1 and then redirect_to would send back a 302 response to that route and the browser would follow it.
Then later versions (I can't remember which one), allowed syntax like this:
redirect_to @post
And the people rejoiced a second time.
Any sufficiently advanced technology is indistinguishable from magic.
While this seems like magic, it's not. What this is doing is actually very, very neat. The redirect_to method, much like its cousins link_to and form_for all use a common method to build URLs, called url_for. The url_for method takes many different
varieties of objects, such as strings, hashes or even instances of models, like in the example above.
What it does with these objects then, is quite neat. In the case of the redirect_to @post call above, it inspects the @post
object, sees that it is an object of the Post class (we assume, anyway) and checks to see if that object has been persisted in a
database somewhere by calling persisted? on it.
By "persisted", I mean that a Ruby object has a matching record in the database somewhere. The persisted? method in Active Record is implemented like this:
def persisted?
!(new_record? || destroyed?)
end
If the object wasn't created through a call such as Model.new then it won't be a new record, and if it hasn't had the destroy method called on it won't be
destroyed either. If both of these cases are true, then that makes the object has most likely been persisted to the database in the form of a record.
If it has been persisted, then url_for knows that this object can be found
somewhere, and that the place it can be found is most likely under a method called post_path. So it calls this method, and passes
in the to_param value of this object which is usually the id.
In short, it's effectively doing this:
#{@post.class.downcase}_path(@post.to_param)
Which comes out to being this:
post_path(1)
And when that method is called you would get this little string:
"/posts/1"
Lovely!
This is called polymorphic routing. You can pass an object to methods like redirect_to, link_to and form_for and it will
attempt to work out the correct URL of what to use.
Now, when you're coding Rails you may have used form_for like this a very long time ago:
<% form_for @post, :url => { :controller => "posts", :action => "create" } do |f| %>
Of course, with advancements in Rails you could simplify it to this:
<% form_for @post, :url => posts_path do |f| %>
Because the form is going to default to having a POST HTTP method and therefore a request to posts_path is going to go to the
create action of PostsController, rather than the index action, which is what would result if it were a GET request.
But why stop there? Why not just write this?
<%= form_for @post do |f| %>
Personally, I see no reason not to... if it's something as simple as this. The form_for method uses url_for underneath, just like
redirect_to to work out where the form should go. It knows that the @post object is of the Post class (again, we assume) and it
checks to see if the object is persisted. If it is, then it will use post_path(@post). If it's not, then posts_path.
The form_for method itself checks to see if the object passed in is persisted also, and if it is then it'll default to a PUT HTTP
method, otherwise a POST.
So this is how form_for can be flexible enough to have an identical syntax on both a new and edit view. It's becoming more and
more common these days for people to even put their whole form_for tags into a single partial and include it in both the new and
edit pages.
So form_for is fairly simple for when you pass a normal object, but what happens if you pass an array of objects? Like this, for
instance:
<%= form_for [@post, @comment] do |f| %>
Well, both url_for and form_for have you covered there too.
The url_for method detects that this is an array and separates out each part and inspects them individually. First, what is this
@post thing? Well, in this case let's assume it's a Post instance that is persisted and has the id of 1. Second, what is this
@comment object? It's a Comment instance that has not yet been persisted to the database.
What url_for will do here is build up the URL helper method piece by piece by placing each part in an array, joining it into a routing method and then calling that routing method with the necessary arguments.
First, it knows that the @post object is of the Post class and is persisted, therefore the URL helper will begin with post. Second, it knows that the @comment object is of the Comment class and is not persisted, and therefore comments will follow post in the URL helper build. The parts that url_for now knows about are [:post, :comments].
The url_for method combines these individual parts with an underscore, so that it becomes post_comments and then appends _path
to the end of that, resulting in post_comments_path. Then it passes in just the persisted objects to the call to that method, resulting in a call like this:
post_comments_path(@post)
Calling that method results in this:
"/posts/1/comments"
Best part? form_for will still know to use POST if the @comment object is not a persisted object, and PUT if it is. A good
thing to remember is that the form_for is always for the last object specified in the array. The objects prior to it are just its
nesting, nothing more.
The more objects that are added, the more times url_for will do the hard yards and build the path out... although I recommend that
you keep it to just two parts.
Now that we've covered using an array containing objects for form_for, let's take a look at another common use. An array containing
at least one Symbol object, like this:
<%= form_for [:admin, @post, @comment] do |f| %>
What the url_for method does here is very simple. It sees that there's a Symbol and takes it as it is. The first part of the
url will simply be the same as the symbol: admin. The URL that url_for knows of at this point is just [:admin].
Then url_for goes through the remaining parts of the array. In this case, let's assume both @post and @comment are persisted
and that they have the ids of 1 and 2 respectively. Same classes as before. url_for then adds post to the URL that it's building,
and comment too, resulting in [:admin, :post, :comment].
Then the joining happens, resulting in a method of admin_post_comment_path, and because both @post and @comment are persisted here,
they're passed in, resulting in this method call:
admin_post_comment_path(@post, @comment)
Which (usually) turns into this path:
/admin/posts/1/comments/2
You can use the array form of polymorphic routing with the redirect_to, link_to and form_for methods. There's probably other
methods that I'm not remembering right now that can do it too... it's generally anything in Rails that would normally take a URL.
There's no need to build your URLs in any Rails version greater-than 2 using hashes; that's pretty old school.
Instead, experiment with your new knowledge of polymorphic routing and use it to the best of your advantage.
]]>Hi Tyler,
I've been doing Rails since I was your age. I'm now 24. You do the math. Not once have I ever considered quitting it due to anything outlined in your blog post.
Your blog post appeared on my Twitter timeline from MikeG1 who is known for his extreme grasp of .Net, Ruby (and Rails) and sarcasm. I couldn't exactly tell if his post was intended as sarcasm, but a follow up tweet clarified that for me. I have massive respect for Mike for reasons that I won't go into here.
Still, I feel like I need to reply to your blog post. It contains things that I disagree with on a personal level and I would much rather address these this way than posting it as a comment on your article.
So, here we go. Comments are inline.
tl;dr: Assholes are everywhere. Ignore them. They feed on your attention.
You start with this explosive line:
I will not learn Rails: I don't want to be associated with a community who call themselves "rockstar developers".
Within the Rails community, I find that the people who call themselves "rockstar developers", aren't. These people pretend to be much better than what they are. The true fact about this is that no matter what programming community you associate yourself with will have these people.
The developers that I admire and respect do not call themselves "rockstar developers". They are humble, courteous and all around good people to be around. It's my very, very strong opinion that you will not find a community more open and welcome than the Ruby and Rails communities that isn't a religious organisation. It's seriously that level of zealotry and passion about making the community a better place that keeps me within the Ruby community.
"Matz is nice so we are nice" is an expression you'll probably hear a lot, if you stick around.
Yet at every event, there's someone who apparently believes the information is wholly inaccurate, or perhaps that sitting through a presentation without challenging everything is the mark of a weak man. There's nothing wrong with questioning things, but when your questions are disruptive to the point of forcing the presenter to skip sections of their talk for time, you're an asshole. If I'm going to an event, I'm going for a reason: the event. Not you.
Again, these people are everywhere. I can't speak for your own events, but the events I go to such as local Ruby groups back in Australia and conferences all over the world, I have probably encountered somebody like this twice. That's over my entire Ruby community experience. These people are usually "dealt with", by members of the community talking with them, or in a more explosive manner, such as a huge Internet-wide backlash that sometimes comes up.
Point is: you will see these people everywhere too. Ignore them. They mean very, very little.
Zed Shaw wrote an extremely controversial blog post, “Rails is a Ghetto,” in 2009 in which he pointed out the tendancy of the rails community to behave like a fifth grade classroom after he closed commits to his project because people behaved like a fifth grade classroom:
A small correction here: Zed wrote this post on 31st December, 2007. Not in 2009. This makes this blog post a little over four years old. The people that are mentioned in that blog post, such as Kevin Clark, are not involved with the community any more. They've moved on to other things. Also, the Rails community has evolved dramatically over those four years. My personal aim for the Rails community is to make it nothing like the PHP or C communities, where you're told to "RTFM" whenever you ask a question. You'll probably get that kind of thing occasionally in the Ruby community, but 99% of the time you'll get linked to the perfect spot in the documentation. Then, if you still don't understand, people will take the time and help you to understand. All for free.
Yet personally twice I've seen these "rockstars" completely killing the passion in young developers. It's "tough love", they may argue.
I used to get insulted when peoeple would simplify what I did. It's generally these young developers that do that kind of thing. They would say "Oh, you just sit there and write code all day. All I need to do is learn everything there is know about Ruby and Rails and I can write code just like you". Well, actually, you can't do that. Ruby and Rails are too big to keep all in one brain at one time, and so that first point is improbable, and secondly: there's so much more to writing code than just putting characters on a screen.
These rockstars that you're talking about probably don't acknowledge that those young developers are exactly as they were X years ago. These young developers may have such a passion for wanting to learn a language, that they don't realise that the more senior developer just can't "get it" that the younger guy doesn't just understand.
I used to hate on people who just wouldn't go out and learn. Now, I'm more patient. I recognise that they are just trying to learn and that if I spend some time teaching them, showing them whatever it is they want to know, they'll be so much more appreciative and passionate of both the language and my help that they'll probably stick around longer. If I dismiss them, then what is there perogative to stick around? There just isn't one. They would be crazy to do so.
From presentations full of porn and jokes at the expense of women ...
I remember this incident well. The enormous backlash against Matt Aimonetti was of a scale that I had never seen before. I have never seen that many people from the Ruby community be so united against any particular thing that one individual has done. This incident was the reason that Mike Gunderloy stopped contributing as much as he used to the Ruby community.
Since this incident, the Ruby community abhorrs any kind of sexism. Yesterday, at Mountain West Ruby Conference, a person gave a talk on "Pinterest for Bros". Afterwards, some standout members of the community such as Josh Susser messaged him on Twitter and told him off. I haven't seen his replies, but I don't think he meant it as much as Matt did.
... DongML ...
Again, sometimes you'll encounter assholes. This is one of them. Ignore, move on. They will be dealt with by the community at-large.
... to refusing to acknowledge design flaw [semi-colons in URLs] ...
This one was a mistake from 2007. It was a silly thing to do and written by a developer who was eventually corrected. There's so many examples of this happening in Rails: a developer does something stupid, the community corrects it. It ends up being net positive.
... design flaw [mass-assignment]
This is a tricky problem to solve. Rails champions convention over configuration and so having all attributes blacklisted by default means that there would need to be some configuration to whitelist specific attributes. There are other problems which are covered elsewhere. I won't go into detail here other than to say it's a problem that's being addressed by the smartest minds in the community right now.
... then freaking out when they turn out to be bad choices. [Egor Homakov's post]
Mr. Homakov is not representative of the Rails community at all. He is, to me, an outsider who spends his time trying to show that he's an "uber l33t hacker" by breaking GitHub or any other Rails site.
The rails group curated the atmosphere of immaturity.
While it is true that we take ourselves much less seriously than other communities (see: C# developers, the end of Aaron Patterson's talk at Railsconf in 2011, etc.), I wouldn't go as far as to claim that we're immature. Rails has been around for 8 years now and is growing more and more mature by the day. Yes, there is some outliers in the community who are immature, but as I keep saying: they are not representative of the masses AND you will find them elsewhere as well.
Rails isn't actually good.
This is where I went "OH NO HE JUST DINNIT". Then I chilled out some.
I think Rails is excellent. Of course I'm a little biased, having done it for 6 years, written a book about it and contributed heavily to its documentation.
The framework is exactly what I personally want in a web framework.
Anyway, to address your points that follow:
A successful framework which runs on Ruby, a language which they didn't develop.
I don't see how this is a problem. There are many other languages and frameworks that are built on top of other things. Like Django, for instance.
That, in turn, is usually run on a server running a flavor of Linux, which they didn't develop
Again, not sure why this is such a big deal. Rails is designed to be cross-platform and so should work on many different operating systems. Whatever system Ruby works on, there's a very, very high chance that Rails will work there also.
What Rails actually did was create some classes which simplified repetitive code. They designed something, wrote some pretty simple code, and became more arrogant than the people who did the bulk of the work.
To be honest, I actually find this a little offensive; almost like you're trying to start a flamewar. I'll ignore that and address the points.
Rails is not simple by any means. To understand exactly how Rails works you need to understand quite a lot of things. The code that has been written for Rails is "simple" once you understand it, but that isn't to say that all parts of Rails are trivial to the uninitiated. For example, explain to me the function of ActiveSupport::Dependencies succinctly. That shit is messed up.
Certain members of the core team are indeed highly arrogant. This mostly comes from them also being highly opinionated. Most of the time, this is not a problem as they are usually right about things. You learn to deal with their arrogance, stroke their ego some and work together on making the world a better place. Yet again, Rails core is not indicative of the community as a whole. No particular group is, really.
And it doesn't even run well! The framework+server takes on the order of a gigabyte of RAM
I would like to disagree here. While a Rails application may use that much RAM, RAM is cheap. Developer time is not. Rails is not designed to operate on a small cluster of RAM, but is designed for developer productivity and happiness. At the end of the day, what's more important? A small memory footprint or a framework that justs gets out of your way and lets you develop?
Early rails applications needed to be restarted tens of times a day.
You are addressing an ancient problem here, almost near the beginning of my Rails career. This was due (to my knowledge) to particular problems within how Rails was configured on a server and has been addressed in more than one way since then. This is most definitely not a problem these days, and is therefore a moot point.
They ignored the vast number of users who were on shared hosts, requiring very specific configurations which a majority of their target markey do not need.
Time and time again it is proven that users on shared hosting suffer, I'll admit. Just the other day somebody couldn't install a gem onto their Dreamhost server because Dreamhost was still using a 1.3 version of RubyGems. In this case (and many others), it's generally a configuration issue with the shared hosting provider that causes the problem (such as not staying up-to-date with software releases), not anything in particular to do with Ruby or Rails.
If you can find a case where I'm wrong about this, I would absolutely like to hear about it.
But the core team are hardly the gods of programming they often purport to be.
The core team are not gods at all. They are simple human beings just like you and me. The purporting going on is mostly just posturing.
Rails isn't even special. The idea of simplifying development has been around for ages ...
Simplifying development has been around for exactly how long? Rails was the first framework of its kind that gained a huge following and other frameworks followed after it. Django was one (I think, I'm in the air right now and can't connect to the Internet), CakePHP another.
The Django community, for instance, has, in my experience, been filled with nice people who enjoy chatting about development.
I have no personal experience with this, but I have heard reports from people who have switched that the Ruby community is nicer and more welcoming than the Django community. I'm sure there's nice people in both communities.
I'd rather not be part of a community which seriously thinks dick jokes are hilarious.
The truth is that 99.99% of the Rails community thinks dick jokes are immature. There's a small portion who just won't give it up, and that's just in their nature.
Thank you for taking the time to read this far.
I would encourage you to check out the Ruby and Rails community again, even if it is just to see that we're not all arrogant assholes making dick jokes every chance we get. I think you could really benefit from learning more about the language and the framework.
Thanks! Ryan Bigg
]]>My name is Ryan Bigg and I booked flights to Salt Lake City with a layover in Denver on the 14th of March. I'd never booked you before. How did I find out about you? Well, there's a handy site called Hipmunk which is an aggregator for flights, hotels and whatnot. You were ranked as the cheapest, and I figured what harm could there be in booking? The flight was a perfect time, arriving at 4:25pm in SLC. Nobody else had flights arriving at such a perfect time as you.
First, a little bit of background on why I was going there in the first place. I'm a programmer. There's a conference there called Mountain West Ruby Conference which I booked tickets to go to right before booking flights with you. By arriving early in SLC, I hoped to catch up with some other programmer friends of mine and have a pre-conference dinner.
I arrived at San Francisco airport at 9:40am and checked in for the 10:45am flight. I was told there would be a delay of one hour and that I would miss my Denver connection. I would then have to make a later one at 9:20pm to go to SLC, arriving somewhere in the vicinity of 11:25pm. Too late to catch up with my friends.
At 11:45am, the screens still flashed "Delayed". I didn't want to approach the counter and ask about times because the hostesses were already seemingly pushed to their limits. I truly, truly pity them in situations like this where they have to deal with indignant customers. A very long time ago, I used to work in a similar role and know how bad people can get.
At around 1:30pm, I decided to go have lunch with the screens still flashing delayed. The line for the restaurant nearby was too busy, so I went over to the store next door and bought some Pringles and a bottle of water. I then moved to one of the charging stations next to Gate 41, which is right across from Gate 43. There, I waited for the flight. Still flashing delayed.
So I decided I would do some work to pass the time while waiting for your flight. I completely missed the announcement due to one reason or another, and looked up to see the flight board had changed. Not once was I notified of a departure time for the plane, either by PA or screens.
I approached the desk and was told that I had missed my flight. The really helpful air hostess with the patience of a monastery (who wasn't wearing a name badge, so I couldn't tell you her name) rebooked me on the next available flight, one that was supposed to be leaving at 2:45pm but was delayed until "Around 5". This would mean that I would be cutting it fairly fine in my layover for Denver, but could still probably make it. (I later checked, the flight actually departed at 5:56pm, meaning I would have missed my connection and had to stay the night in Denver, and I would've missed the first day of the conference tomorrow)
As 5pm approached, I checked the flight status on Google. Originally, it told me 5:15pm. Then it told me 5:35pm, with an arrival time within 19 minutes of my layover. Yeah, nah. Wasn't going to make that.
Not once did I receive an email telling me that the flight was delayed. No notification over the PA at all. Not a single, iota, of anything.
I contacted one of my programming buddies and he advised me that there was a SouthWest direct-to-Salt-Lake-City flight leaving Oakland Airport at 8:40pm that was being sold for $267. I bought it. I approached the desk again and asked how I would go about getting a refund, and aI was told (again, super politely!) that I would need to call Frontier. That's very hard for me to do here, because I don't have a mobile phone that works in this great country.
I caught a cab ($125, including tip) to Oakland airport. Checked in at SouthWest who informed me that their planes had no such delay and would depart on time. Yay!
So here I sit, at Gate 31 in Oakland airport, writing this to you in the ultra-vain hope that you'll improve your systems. When your flights have delays, PLEASE email your customers. I was constantly on the WiFi in SFO checking for notifications. Notify them over the PA that a flight may be arriving at a specific time and to not go anywhere.
One final thing: I don't know where my large suitcase is right now. The suitcase that has all my good clothes, some souveniers and some other things. It could be in Denver, it could be in Salt Lake City. I don't know. I can't call anybody to ask. I will need to go to Baggage Claim in SLC and hope that they have it there. If they don't have it, then I'm out around $900 of equipment.
Your @FrontierCare account contacted me earlier and offered me a $50 voucher on future Frontier flights, but I don't think that I'll be using it. I'll be looking to get a refund (or at least, a partial one) for the flights that I've missed today. $50 is a paltry figure compared to how much I could have potentially lost today.
Please, please, please improve your customer service experience. It is not rocket science.
]]>At both of these conferences, I gave a talk about Rails Engines. In this talk, I covered a lot of the lessons that I learned about developing an engine, and the one of them that I would like to expand on today is about how an engine should deal with authentication.
Put simply, the engine should not deal with authentication at all. You can stop reading now, this blog post is over and you've learned everything you're going to learn. Go forth and develop engines without authentication. Thanks for reading!
If you're staying for after-the-fold, then let me explain my reasonings for this.
When we (Phil Arndt, Josh Adams and I) were developing Forem, we talked about what authentication engine we would support inside Forem. The issue was that different people have different opinions on what authentication system is "best". Some like Restful Authentication, some like Authlogic, others like Clearance, others like Sorcery, and finally others like to build their own custom solution. That was something made easier with the inclusion of has_secure_password in Rails 3.1.
That's a lot of fragmentation!
Therefore, picking one authentication solution means that we would isolate a large group of people. This is what the "auth" component of Spree does, spree_auth.
The way that spree_auth deals with authentication is that it uses Devise. It has a Spree::User model in it, and there's also some
Devise setup inside config/initializers/devise.rb. The Spree::User model is how Spree deals with authentication inside the
engine.
By having this authentication inside Spree, we are expressly stating that you must use Devise and have it as a dependency of your application, even if your application uses something completely different.
A bigger problem comes up when your application is also using Devise. spree_auth's configuration combined with your application's configuration for Devise may cause slowdowns or conflict with each other. This may not happen though, because the railtie's (i.e. spree_auth's) initializers are run before the application's, and so it would take precedence.
For instance, we've had a couple of reports where the Devise configuration in RefineryCMS have been conflicting with Spree's authentication.
Finally, by having two different User models (one in the application and one in the engine), it doesn't allow users to be shared across the two components. This means that you would need to modify Spree to work with your application or your application to work with Spree, which is not the ideal situation.
How we deal with this in Forem is that we simply do not include an authentication engine of any kind. This means that you can use Restful Authentication or Authlogic or Devise or Clearance or Sorcery or something custom and we couldn't care less.
The way that this works inside Forem is that we ask two questions when rails g forem:install runs. The first one is effectively
"What is your User class?" and the second one is "What is current_user inside your application?". Forem then takes these values
and inserts code into config/initializers/forem.rb for the Forem.user_class setting and defines a method in the
ApplicationController class of the application called forem_user that simply calls the current_user method inside your
application.
The Forem.user_class setting is used in a couple of places. Firstly, it's used in the Post and Topic models to set up the
author/user associations so that we can track who created what topics or posts. Secondly, it's used in Forem::ApplicationController for
the current_ability method for the CanCan-backed authorization system that Forem uses.
The forem_user method is used to get at the current user of the request and allows Forem to check permissions and determine if a
user is logged in or not.
The application, not the engine, is what is providing the authentication engine. The application is God and should always have final say on what is happening, not the engine itself.
I personally think Forem's approach is the best that we're going to get with engines now. This method allows an application to provide the authentication engine and for the engine to hook into it easily enough.
It's my thinking that we should remove the spree_auth gem entirely and then rely solely on the application to provide a User (or
similar) class. The authentication parts of RefineryCMS (and engines in similar situations) should also be removed. The application is
what should have the say on what authentication engine to use, and not an engine.
Yesterday, I received a 1,063 word email from a non-profit organisataion asking me for advice on whether or not they should use Rails or Django for their new project. They begin with:
We found your answers and profile on Stack Overflow. We're reaching out to you because we'd like your advice on a new nonprofit project, [name], and the language/app framework we should use to develop it.
We have a fairly small budget to build the framework and to do betas of the first seven sites, so it's crucial we pick the right framework. We are trying to choose between Django and Rails, and we want to make the right choice.
Quite obviously, my answer is going to be heavily biased in one direction. I'm sure you can guess which one.
Before yesterday, I'd never even heard of this charity, nor spoken to the person who sent me the email. Basically, up until this point, we've done nothing for each other. Their questions obtusely relate to Rails, and definitely doesn't relate to what I get paid to work on.
So I read the email anyway. It explains what the charity does and what they'd like their new platform to do. Then at the bottom, they ask if I could "take a look at the high-level requirements" and link me to a Google Docs Spreadsheet. Inside this spreadsheet, there's 32 very wordy questions, like this one:
We need the front ends and backends to run fast. Many of the backend pages will have fairly intensive reports drawing on lots of data from user pages, such as nonprofits being able to run reports of total donations over periods of time, recent donations, etc. We think speed is a top priority.
Each question, by my estimates, would take one hundred to five hundred words to answer adequately. So at a minimum, around 3,200 words of mine to answer their questions. This is from a complete stranger in a private conversation between myself and them. Do you know what other situation this happens in usually?
Oh yeah, paid consulting. But there's nothing in the email that indicates that I will get anything more than a warm and fuzzy feeling from answering it.
Like I said before, this is not related to anything that I do. This is extra work. It's in a private conversation, so my answers won't benefit anybody else. If this question pops up again, chances are that I will have to answer it again, and that's not cool.
These kinds of emails are basically a three-times-a-week deal, and I'm over it. While I enjoy helping people for free, I will only do so in a public forum where other people can benefit from the answers. If you want to contact me privately, then I will ask for some sort of reward for it, because very few people are going to benefit from it.
These kinds of questions have no regard for my time, and all I get from them is a feeling of being used for my talents. Kind of like a whore, just without the money changing hands thing.
No more.
]]>One year, four months ago I moved out of a place in Camperdown in Sydney to a more remote suburb called Narwee. If you don't know where that is (and judging by the conversations I've had with many of you, nobody does), it's a South-Western suburb of Sydney, best described as "Go south to the airport, then about as far west". You could Google Maps it if you like. I'll wait.
It was there that I moved in with a guy called Tim and basically rented a room and shared the house for $200. It suited me fine, as I spent quite a lot of that time in there writing a book. The trainline nearby got me into and out of the city every single day that I needed it, bar one or two times where somebody decided to fight one of the trains.
When I came back from Adelaide recently, Tim arrived back also and told me that he has a friend who he would like to move in and so he asked me (very nicely, might I add) to move out by the end of January. Fair enough, it's his place. This was on the 28th of December.
So then I needed to find a place. If I stay until February this year, then it'll be two years in Sydney. During that time, I've always heard Melbourne compared to Sydney favourably. Things like "Melbourne's like Sydney, but with more fun". It also helped a bit that my friend Tom (who I caught up with over Christmas) was suggesting that I should move to Melbourne as well so that we could hang out.
I was cooking dinner on the 29th and felt like I was doing nothing to further the situation. I needed to move out, but my weekend plans weren't exactly conducive to that. So I thought "fuck it" and sent out a tweet asking if anyone had a place for me to (temporarily) stay in Melbourne.
Tom replied with a half-joking, half-indignant tweet that I should have messaged him first and asked if I could stay there. I sent him a message and he replied and said I could stay at his. The very next day I drove the ~900km down to Melbourne to stay at Tom's house.
At that point, I had no fucking clue what I was doing in Melbourne. It was one of those spur-of-the-moment things. The drive flew by, thanks in part to the Hume Highway dual-carriageway upgrades and the most-excellent Back to Work podcast.
Then, I got to see Melbourne for the first non-going-through-in-a-bus-to-the-airport-for-railscamp time. This city reminds me so much of San Francisco, from the cafés, to the over-population of hipsters (which is a con, not a pro) to the amazing food and friendly people. Ross Hill actually wrote about these things, and I can totally agree with him. I'm actually writing this from Inspire9 right now!
I got to experience NYE in Melbourne with some great friends and all of those things combined are what sold me on Melbourne. So I'm moving there (which is "here" right now, but let's not get technical).
I still had no fucking clue where I wanted to move, but at that point it had to be Melbourne. Some point after that, Tom and I are talking and he brings up that the guy who sold him his apartment (that he shares with two others) had another that he was looking to rent out also.
I got in touch with him, and he showed me the place. It is the best place I've ever had the pleasure of looking at. Wooden floorboards, a nice upstairs area, two bathrooms, four bedrooms (one will be used as a study / storage area), gas stove kitchen, nice patio, and so on.
On Friday, I looked it over again with two other prospective housemates and they both agreed that it was nice. One of them backed out due to how long it is out of town, and the other one doesn't mind. So I told the agent that I would absolutely love to lease the property.
This morning, I went into the agent's office, handed over the first month's rent and signed the lease agreement.
I'll be moving down and in on the 21st of January. See you around!
]]>You may remember him from that little hosting company called Site5 he started when he was 15. You know the one that was one of the, if not the first, hosting company to offer Ruby on Rails support.
I had the pleasure of working with Matt around September last year and ended up visiting him in San Francisco. We went to Antonio's Nut House where we drank and played darts (and ate way too many free peanuts). Then we went back to his apartment where I got to sleep on an air mattress. That morning we went for bagels at a place not too far away from the Nut House. Those are my favourite memories of San Francisco.
He was such an amazing guy and will be terribly missed.
]]>RSpec supports the shoulda-matchers gem and I see a lot of people using this to test validations on their models, and this is the first test that they're writing. I personally think that this is the wrong way of doing things.
The first test should be one that follows the exact steps that the user would need to do in order to approve this functionality.
In the example test (written in Capybara's syntax) below, the user fills in the form (ignoring one of the required fields) and then should see that there's an error on the page.
visit root_path
click_link "Posts"
click_link "New Post"
fill_in "Title", :with => "Deciding what tests to write"
click_button "Create Post"
within("#flash_alert") do
page.should have_content("Post could not be created.")
end
within("#post_form .errors") do
page.should have_content("Body cannot be blank")
end
Or if you prefer Cucumber:
Given a user is creating a new post
And the user leaves the post text blank
When the user clicks "Create Post"
Then they should see a validation error:
"""
Body cannot be blank
"""
You can imagine the steps that Cucumber would use, they'd use the Capybara methods just like the original example.
The point is, this test is testing the user's interaction with the page, which I think is the most critical part of the application. If the user cannot see this error message, why does it matter if the model validates the presence of this field? It doesn't.
Testing that the model contains the validation is a secondary thing, and is generally something I skip doing. The
test for at least one of the form's validations goes into the request spec. If I'm feeling pedantic I'll write
another for the other validations, but I can assume that dynamic_form (the thing that provides
error_messages_for is doing the right thing when it comes to its own methods. If one error message is showing
up, good chance the others are.
In the case where validation error messages don't show up then I write a specific test for that inside the request spec before going on to fix it wherever I need to.
In Spree, there's complex logic involved around orders and tracking inventory. This is something I could test with a request spec, but how the system works is made up of so many little parts it makes it slow to test the whole thing:
A huge portion of these steps aren't even required to test the count on hand decreasing. What we care about is that when an order is placed in the system that the count on hand decreases by one. And so this is where a unit test would be better.
This unit test would check that when an order is created, a method such as unstock_items! is called. There would then be another unit test for the actual function of the unstock_items!
call, ensuring that it goes through the line items for the order and depletes the stock on the products as necessary.
The unit test is going to be much lighter (and quicker to run!) than the request spec, which is just a massive win.
At the final retrospective at the CodeRetreat event on Saturday in Sydney, it was brought up that there's no "right" way to test. Some people thought that testing from the "bottom-up" (unit test first, request specs or similar later) was better, but then they saw the merits of testing "top-down" (request specs or similar first, then unit tests for the fiddly bits) as well.
I think liberal applications of both of these methodologies is one "right" way to test. The more I test, the more I find myself getting better at knowing what to test and how to test it. I can see the merits of both ways. I'm preferring top-down though, as that's, in my opinion, testing what the client is going to be seeing, and that's what matters most. If there's a bit of gnarly code in there, like the order inventory tracking, then that's when I'd dive down into unit testing.
What are your thoughts on this?
]]>You may know that I wrote a book. I may have written during the process about the difficulties faced and also about how much it fucking rocks to have a book published. I've never felt so damn good for so long.
That's a topic for another day. Today's a rant kind of day. Tonight, I feel like shit.
Let the rant begin.
Let's start with the authoring tools that Manning provides.
To author a book, you use Manning's DocBook format, which isn't actually all that bad once you get used to it. Alternatively you could write in Microsoft Word, but I honestly hate it. The documents just feel... unstructured to me. DocBook appealed to me because I obsess about ordering and structure.
I created all kinds of macros in TextMate for DocBook and was fucking awesome at it towards the end of it. If there were world championships in DocBook, I would place high. Mum would be proud.
Once I had a chapter ready, I had to upload it to Manning's system. This is done through an SVN repository. I hate (and I mean, truly hate) very few things in this world. Microsoft Word's one of them, and SVN is another. Years of abuse have me close to suffering post-traumatic stress disorder attacks every time it so much as conflicts on a damned file.
Anyway, once the file's uploaded to Manning's system through the version control system from Hell, you get to use the authoring tool also from the same locale. I shit you not, this thing takes 4 clicks to update a single chapter. You need to click on the gear icon, click on a chapter, scroll down to the god-damned bottom of the page listing all the revisions EVER for the chapter (for God knows what reason) (p.s. there's 80+ for some of the earlier chapters, with each revision taking 4 lines of 12pt text) and then click on the radio button for "Latest" (the text next to this field doesn't trigger it, of course) and then click "Update".
I got majorly annoyed with this process in about June of last year and created my own system in twelve hours. It's goal was to a) allow me to publish updates to all the chapters with one command and b) to provide other people with a super-easy way to review the book, and it did both of those things, but it looked like shit. I fixed that with version two, with the help of a friend.
In total, I received ~1,600 notes on the review systems that I built and they contributed back in major ways to the book. Want to know why the book's so damned good? Not me. I was just the dude who typed things and put in terrible jokesas footnotes. It's the reviewers. They did all the hard work. Honestly. They read the same chapter again and again and hhounded me about problems. One guy and I even used to chat regularly on Skype.
Those guys rock. Over 30 people contributed something to the book. Could've been "missed a comma", could've been "Prototype sucks!". I love them all.
Manning's counterpart to this review system also looks like shit, but only allows for the author and Manning staff to have access to the book. On one hand, this is great because it stops the inevitable piracy (which, as far as I know, never happened on my review system), but on the other hand it really sucks because you don't get reviews of the book as you go along from people outside your little circle.
So yeah, authoring tools are... depressing to use. I don't think that any publisher has this nailed yet, although I suspect PragProg has gotten the closest to it.
When I started writing the book, I was given a choice. You know this already, but let me refresh your memory just in case you dont: it was DocBook or Microsoft Word. I chose DocBook because it's a lovely structured format.
I also thought "Sure, these guys probably have the tools to convert this into PDF and ePub and Mobi and monetary notes that I can give to people to buy things".
Man, I can be naïve sometimes.
When we went to review, they went through the XML document with this tool I can't remember the name of and it seriously messed with my obsessive formatting. I was non-plussed. I asked them to fix it, and they did, which was nice of them. Still, this tool basically crapped all over the XML document.
My review system did not. Notes were kept separate from the content and not stored as fucking metadata inside the document itself. Why did I do it this way? Because it's sensible. Down the other path lies madness. I know, because I had to live with that.
That was nothing compared with what happened next. To typeset the book they converted the text into a Word document. I don't know how exactly they did this (but I suspect it involved the C & V keys on the keyboard, along with a bit of Control). Seriously.
So now what we have is Word document copies of each of the chapters. Word's review system is very lol-worthy itself also. As an author, I only really care about one note at a time, not the gazillion that the editor has left on the page and Word loves to display.
This means that to update a chapter, I need to ask Manning for a copy of the chapter as a Word document, which they'll email to me, make the fix myself and then email it back to them. Or I use their document management software which was, I'm sure, designed by people who hate their jobs.
Eventually, enough of these changes will be made and there will be the next for a second printing. When that is, not even I know.
So that lovely little DocBook format I got used to, created all the macros and muscle memory for is now toast. My future is Word documents.
See, with printed books, it's really hard to update them. You may have noticed this if you have a copy of Rails 3 in Action on your shelf and open to any page listed in the Errata. Has yours been updated? No? Neither have the three sitting on my bench right now.
There's also the problem of this book becoming quickly outdated due to how quickly Rails moves. We actually upgraded the book to Rails 3.1 in May (the book was printed in September), which was practically "danger close" to the printing time. I'm so happy that we got this change in, but I fear for the future.
If the book was kept in a proper, structured electronic format and never printed on dead trees, then we wouldn't have this problem. We wouldn't have "Sydney" misspelt as "Syndey" on the back cover because someone could have fixed it and everyone would be happy. Actually, we wouldn't have had that if someone didn't do a rush-job on the cover, but people make mistakes. It's an OK thing to do.
We wouldn't run into issues like when Cucumber decides it wants to divorce web_steps.rb and it breaks the whole
book. You know why? Because we could update the damn thing. We could release a new update every week if we
needed to and people would be happy that it's a constantly improving, amazing book.
But instead, we print to dead trees, disabling us from updating it efficiently and easily and it stagnates within 6 months.
Now that we finally (just this week) have the ePub and mobi formats available for the book. I suspected they had to use the afore-mentioned C+V keys to do these too. Updating these is easy in comparison: alter the source, compile a new version, put it on a server and let people know. Done.
And hey, it would be super easy if the source was DocBook and there was a tool to read that XML and convert it into ePub friendly HTML. But there's not one in this process.
That's how tech publishing should be: electronic only. If you want a dead-tree copy, well, I'm sorry, but you're going to have to print it yourself.
Yeah, we probably did fail at creating The Best Book Ever. But that was never the goal. The goal was to create a book that was easy for noobs to read and learn Rails (and to be the best at that).
I think we succeeded, but I also have a ginormous ego.
Yes, there are mistakes but we will fix them. I will do everything in my power to address any and all (reasonable) concerns you have with the book. I want it to be perfect for you.
There will be updates. Even though Manning's tools are not that great, the people who work there are some of my favourite people in the world. I will work with these wonderful people and we will release a wonderful Version Two.
Promise.
]]>