render :action => ‘details’ will render the details.html.erb template and or action details (the def doesn’t need to exist, only the template).
render :template => ‘details’ fails. It doesn’t run relative to the controller, so you have to run: render :template => ‘/controller_view_path/details’ for it to work.
In the end, the result is the same.
I’m sure many of you have mixed feelings about testing, and get shivers on the spine when someone mentions TDD/BDD.
Well, I’m a big adept of testing, specially TDD and its newest child, BDD.
Unit testing in general is a tricky skill to learn, and requires a lot of motivation and faith on what you are doing. I have started in the world of Unit Testing about 4 years ago, and TDD/BDD ~3 years ago and the more I learn, the more I see it’s actually an art.
I used to defend BDD religiously, and I was one of them, heck, I even looked a testless application from behind the lens of prejudice, for me, it was basically crap.
Of course, that’s how our mind works. We see the world as we are, and I was over-reacting, basing my judgement on some internalized archetyped beliefs:
* Code without tests is crap
* Rails code must be tested, if you don’t test you are a worthless and doesn’t deserve to live
* BDD is the new tendency, everyone should be using it
* Outside-in! Outside-in! Or die!
Now, don’t take me wrong. Unit-testing, TDD and BDD are very valuable disciplines, but the message is being given in the wrong way, in my opinion.
I still love BDD. Cucumber for me is one of the most well-developed pieces of software, it’s really amazing. rSpec makes unit-testing fun and clear.
Critical features should be always unit-tested, following TDD/BDD or not. However, there’s a culture out there that makes you believe you should test every freakin’ aspect and artifact of you application.
That’s insane. That’s overuse of testing. That definetly doesn’t relate to the pragmatic/agile way in my opinion.
Take Selenium, for example. Cucumber+Selenium is a killer combo, in both senses. It works nicely and you can test JS and Ajax features, but it is just too slow. Every time you launch it, it takes up to 10 seconds to launch on a modern computer, sum that with Cucumber’s startup time, and every time you want to go through it, you loose around 15 seconds.
Every successful application I have worked on have started with little or no unit-testing, and once the money started flowing, we had the time and resources to build a better testing infra-structure. That’s a point agains BDD, unfortunately. As magic as it sounds, the real-world calls, and you are forced to code for food when you are starting.
So, I think it depends on:
* Resources: Microsoft can do BDD from the beginning 
* Time: Tight dealines calls for essential things only
* Skills: If you can sing BDD in 5 languages, then maybe you can BDD
for every programming artifact you create
* Environment: The company you work for might already have a very deep testing culture that it end up being simpler do follow TDD/BDD or unit-test your stuff, however, you can still overdo it.
* Patience: Come on. Selenium is just too slow.
So, whenever I am on my pragmatic mode (I still fall to my perfectionist side sometimes) I just have one rule: Getting Things Done and well. If for that I need to test something to make sure it will work as I expect, then so be it. If I judge it might go without tests, then, so be it, too. In the end, I’m giving priority to the most important resource we all have: Time.
My life just got a little bit easier.
As you might already have noted, I’m adept of simpe solutions and openness. I like having control of my stuff and tailoring things to work for me, the way I want, and improve gradually. That’s why I fell in love with org-mode and have been using it for the last 2 years, as my only and one personal information manager.
I’m also a GTD practicioner. Org-mode is the perfect platform for GTD because it just lets you implement the model the way you’d like. I just got the collect and review phase a tad easier, by getting Mail.app flagged mails imported directly into my inbox.org file.
This might seem like a mundane thing, but given the amount of support emails and often important stuff I receive through my work’s email, it just saved me the work of copying the text and collecting it manually into the inbox. I can now just flag it and trust that whenever I review my stuff, the data will be there, in front of my eyes.
So how to do that? Considering you already have org-mode up and running, you should first add the module org-mac-mail to the list of modules for org to load at startup:
M-x customize-variable
org-modules
Search for “mac-message”, tick it and save the buffer.
Then, just add it to your .emacs (or any of its dependencies):
(defun my-mail-import ()
(let ((org-mac-mail-account "OneLog.in"))
(org-mac-message-insert-flagged "inbox.org" "Flagged mail")))
(setq org-agenda-custom-commands
'(("F" "Import links to flagged mail" agenda ""
((org-agenda-mode-hook
(my-mail-import))))))
Eval the buffer or restart emacs. When you open the org Agenda, you should see a new option:
If you type
Isn’t that nice?
Let’s say you have a form, and this form has a credit-card select with the following options:
This would probably translate to the following in HTML:
<option value=”visa”>Visa</option>
<option value=”master”>Mastercard</option>
<option value=”american_express”>American Express</option>
Say you have a view test and you want to make sure this select renders the options as you expect. You could do the following:
card_type_options = options_for_select([['Visa','visa'],['Mastercard','master'],['American Express','american_express']])
form.should have_selector('select', :id => 'credit_card_type', :name => 'credit_card[type]') { |select| select.children.to_s.should == card_type_options }
I have tried using “select.should contain(card_type_options)”, but it would fail. The approach of converting the select’s chidlren to string and testing its equality to card_type_options works fine.
When using Machinist to create your fixturish objects, be aware of errors on an associated object, it can get to weird issues where the attributes after the association definition just won’t be assigned (probably because an exception happens and it gets out of the flow of assigning the attributes, I haven’t dug deep into it as I could find a way to fix it, but if someone knows the inner-workings of machinist and could explain better than I do, feel free to comment or send me an email).
For example:
Post.blueprint {
user
title { “Sample” }
}
If an error happens when trying to instantiate the user object (a belongs_to relationship), the title attribute won’t get assigned, no matter what. And worst, in my experience, it will fail silently.
To fix that, just try to find out why the user object might be failing to instantiate. You can try to create a user blueprint and see what errors arise when you make it. If you put the “user” declaration at the bottom of the blueprint definition, you will get a kind of work around, but I don’t recommend that, since you will still have the errors and it could cause something worst later on.
Public announcement: If you haven’t checked out orgmode, you should do it. It is the awesomest piece of software I’ve ever known. It is a reason, by itself, to use emacs, even if you keep using your other favorite editor for mundane editing tasks. Check it out on www.orgmode.org.
Now onto the quick tip. Orgmode has a org-agenda-set-restriction-lock function, which can be used to restrict agenda searches to the specific subtree. After you apply it to an item, only its children will be taken into account when you make your queries through org-agenda.
If you type C-h f org-agenda-set-restriction-lock, here’s the doc you get back:
...
Set restriction lock for agenda, to current subtree or file.
Restriction will be the file if TYPE is `file', or if type is the
universal prefix '(4), or if the cursor is before the first headline
in the file. Otherwise, restriction will be to the current subtree.
While it is useful for its original purposes, I also use it as a simple focusing tool. I’m the kind of person who gets lost easily and that gets high-value from a well written todo list, and that includes a visual clue on what item I’m working on. This command sets a background color that can be used just for that.
Just put the cursor you want to be “highlighted”, and type C-c C-x <.
Keep in mind that this will restrict any subsequent org action to this item, so, don't be surprised if you agenda view breaks. To cancel it, just type C-c C-x >.
GTD is a great systematic approach for getting on top of your world. Being a systematic approach also means it is general enough to cause confusion (i.e: not be clear) and to be applied to virtually any aspect of life, and that includes any particular needs you might have.
GTD works on top of 3 models. The first one, called the Mastering Workflow is the best known, and the essence of David Allen’s first book. You’ll surely remember the Collect, Process, Organize, Review, Do steps.
The second model is the Natural Planning model – it’s basically used to clarify amorphous data into clear next actions (as wel as finding out why you are doing it at the first place).
The third model is what David calls “Horizons of Focus”, and defines the different levels — or horizons — on which we need to focus in order to get a good perspective about our world.
Anyway, the point of this article is not to teach you GTD. It is deep enough to require a book of its own (Check out the Getting Things Done and or Making It All Work books).
When developing software, we are bombarded by a constant flow data, this comes from different sources:
* Our our mind triggers it;
* Someone else asks us to do it;
Most of the time, this data is amorphous, sometimes it doesn’t even have clear goals. Not a good day to be a software developer uh?
Well, whenever you have to deal with that, you need to quickly capture. Try not to get out of the context you are. Capture it and trust that you will deal with that later. If you judge the task will only a quick while and that it is clear enough and you are not doing something already, do it. Any other notes you might have during the time you are doing the task, just take note (capture it) and forget about it for the time being.
David talks about cranking widgets. He says that there is always a set of very clear and “physical” actions that you can break down from any unclear task.
The thing is: Defining the “widgets” is very subjective. But the good news is that you just have to break it down until it has enough information in it and makes sense to you.
For example:
* System should deal with ARB requests
Is definetly too high-level. You will break your head a little bit and it will cause you anxiety if you just keep it like that. It doesn’t matter if tell me Cucumber will save your life. You will eventually finish the task, but it will take much more mental energy. So, start breaking it down:
* System should deal with ARB requests
** Create the system_should_deal_with_arb_request.feature feature file on feature/
** Write the story on the feature, check with Tommy
** Brainstorm about the scenarios, 25 minutes timebox.
Now, this is the part I told is subjective (and this is the main poin tof this post), and depends on the person. Know what ? Just put whatever you feel you need to remember. These are reminders, after all. Just try to be clear enough for your own understanding.
(You can see that most of the time, not everything will be clear, and a reminder to process something even more will be very helpful, such as brainstorm about scenarios. The point is to extend your mind and let you know what you need to do, you don’t have to clarify everything upfront, that would be crazy, and you would probably be following something akin to the watefal development methodology).
Then, to decide what’s is the next action, you can judge by time, priority, energy, and context. You can start the day looking your GTD next-actions list and decide, depending on your current circunstances, what is the best next choice. You might decide you don’t have enough information, and that’s ok, just plan on it, but be sure to set up any needed reminders for next-actions or new projects/sub-projects that might appear.
You might even modify the /delete the todo-list, or change the order, you are the judge. Be flexible, be pragmatic, GTD is a systematic approach and not a defined system. You have the whole inventory in front of you, and if you trust it (which takes some time) you will free up much more energy to actually execute.
Please, don’t fall in the same almost-infinity-loop I fell.
Firstly, an outburst of mine — Gem Bundler is true quest to setup. It is an wild adventure.
Don’t get me wrong, the tool is amazing, but the scarce and uncentralized documentation really makes it difficult to set it up, requiring you to go to Pluto, come back, stay a few minutes in the moon, a few hours in the edge of the internet and then, after a bunch of trials, get something solid.
Now, onto the issue I’ve been through, which is not really Gem Bundler’s fault.
After going through the amazing quest to set up gem bundle, I though I had it done. However, ActiveMerchant was not loading. What the heck? Every other gem was loading but ActiveMerchant.
Now, I don’t know why ActiveMerchant developers used active_merchant as the name of the main ruby file for the lib. Gem Bundler was trying to require ‘activemerchant’ (I had to debug the require method to find it out, even though I was suspecting that this was the reason) and the require was failing.
To solve it, simply declare your activemerchant dependency on your Gemfile like this:
gem 'activemerchant', :require => 'active_merchant'
Now, back to coding, more coffee, please!
Very nice article that elaborates on the tool vs language world. In the end, we all fluctuate between this spectrum, but I think the best are the ones who tend to be language mavens, which puts the focus on the language itself and not on the IDE.
Of course, there are some languages that are so damn heavy and painful, that if you happen to be one poor soul that program on it for food, it makes sense to use the tools to aliviate the pain. However, if you still insist on using all kinds of IDE and or plugins for every other language, beware, you might be turning into a lazy, useless and fat pseudo-programmer.
Check it out @ The IDE Divide, by Oliver Steele.
Food for thought!
If you find yourself wanting to make the font smaller/bigger on a buffer-basis, you can use the following key-combos for that:
* C– – make font-size smaller;
* C-shift-+ – make font size bigger;
