Ever wondered how to login as two different users at the same time? The situation manifests in any project where you want to be able to test a workflow involving several actors with different roles. The problem is that browsers allow only one login for a given domain at any one time. So, you are required to logout as current_user before logging in as another. One of the solution people use is install multiple browsers.
Read more »
So, I found this issue with google chrome and safari web browser and I believe this applies to any webkit based browser. When a form submit is disabled by setting the submit button to disabled=true attribute, the browser is usually expected to prevent submission when the user hits “ENTER” on any of its text fields. This works fine in Firefor, my default browser.
In my rails app, I had to do this to work around this.
We use haml rendering engine for our project and my form looks like this:
- remote_form_for @product_search, :url => product_searches_path, |
:html => {:method => :post, :id => 'product_search_form'} do |form|
Read more »
Time and again, when I’m discussing the fundamentals and foundations of agile practices, someone will bring up an obscure edge case in an attempt to show why they can’t use agile in their organization or to solve their particular problem. There are always situations where the straightforward use of any technique requires intelligent adaptation. In order to adapt to the situation at hand, we first need a solid understanding of the fundamentals lest we misapply the technique and end up in the weeds.
Take for example, the use of User Stories on an agile team. Most novice teams (new to agile) I’ve coached struggle with the shift to story-based, incremental development. Fundamental to productive adoption of User Stories requires an understanding of how they fit into the overall life-cycle of the project as well as how to identify and author good stories.
Small stories are great because they enable fine-grained prioritization by the customer. Small stories are great because they provide a continuous sense of accomplishment to the developers. Small stories are great because there is less to test at one time.
Yes, but what about the edge case where you have to integrate with a nasty old legacy app with no notion of an API. How to you break the epic integration story apart? Simple. Create small, testable stories that each support some up-stream business need and incrementally build towards a solution.
Yes, but what if I need a large framework build or installed? Again, think small. Think incremental. Think testing. But what if we make a mistake and have to re-do everything because we haven’t designed and planned everything up front? Well, we rarely if ever get software right the first time regardless of how much time we spend up front. In fact, usually when we design and plan for everything up front, we get some things right, and some things wrong. Up front thinking tends to get us locked into a solution space. After all, we’ve invested so much time and energy in designing this baby. So maybe some of the features won’t be needed. And maybe some will have to be tweaked to fit what’s actually needed.
Code is never written all at once, even when there is a up-front design. The fundamental question is, how do we know when any given piece of functionality is DONE? Stories, assuming they contain acceptance criteria (otherwise I don’t consider them stories), give us an edge. We can objectively measure when they are complete because we can test them. We can take large problems and divide them into small chunks to help us manage our work and reduce risk.
So, are there edge cases where user stories won’t work? I suppose so, but I fail to understand why. In fact, I’m not sure I understand the question. Are user stories a panacea for our development woes? Of course not. But, an understanding of decomposition, incremental development, and teams with the skill set necessary to tackle the project at hand is a recipe for success.
In Making it Big in Software, Sam Lightstone has the ambitious task of giving you “all the information you need to jumpstart your software career: the best ways to get hired, move up, and blaze your way to the top!”. It’s an ambitious claim.
Read more »
NOTICE: We’ve run into some snags still with the hudson daemon recognizing the proper environment vars. We are working on some solutions after speaking with Wayne Seguin, and we’ll keep you updated. So basically, the following is possibly interesting, but not yet entirely correctly implemented.
We’ve recently moved to Ruby 1.9.1 on a current Rails project. Since we’re still working on other projects using older ruby versions, all developers are up and running on RVM. This allows us to easily switch back and forth between different versions of Ruby. There’s a railscasts episode on RVM and Rails 3 if you’d like to learn up, but Rails 3 is NOT a requirement for RVM. We’ve seen a HUGE speed improvement running our test suite, as well as on the application itself. We’ve also upgraded the production environment to Ruby 1.9.1 to match. The problem we were now faced with is our continuous integration server, Hudson, is still running on ruby enterprise (1.8.6). We needed to run each project build on whichever ruby version was most appropriate.
RVM to the rescue!
So here’s how we did it. On the build server, as the user the server runs as, we installed RVM. We also made sure to ‘rvm system –default’ to make sure we didn’t mess with anything that was already relying on the current version. Next up was setting the environment up correctly for Hudson to recognize RVM. We added the same line RVM prompts you to add to .bashrc and .bash_profile to our hudson startup script start_hudson.sh:
if [[ -s /home/hudson/.rvm/scripts/rvm ]] ; then source /home/hudson/.rvm/scripts/rvm ; fi
The rake plugin that lets us run our tests, migrations, coverage, etc… also allows us to create and assign ruby versions for each rake task. So in Hudson’s system configuration we created entries for our rubies:
Then we can assign each rake task to the proper ruby, in this case 1.9.1.
One last snag: some things STILL appeared to be running from the default ruby, so we added two execute tasks to bookend the process. The first ‘rvm 1.9.1 –default’, and the last ‘rvm system –default’. This ensures everything runs via the proper ruby version, and we reset it when we’re finished. Is this the best process for managing CI with mutiple versions of ruby? I’m not sure, but it works!
So there was this need for providing ajax-style add/remove item-rows on the last project I worked on. What I thought might be pretty straight-forward to achieve using jQuery-fu eventually turned out to be little hairy for me.
Read more »
