Browsers build in a security feature which stops a web page from submitting ajax requests from another domain. So if a page is running on jamesstarmer.com/example.html it can only call pages on the jamesstarmer.com domain, requests to google.com/some-api/whatever.json will fail. The best way to get around this is to use JSONP which loads json using a script tag which is ok by browser security standards.
Back before JSONP was a “thing” I had a need to get and ajax request from domain a to domain b. At the time I was writing the server side code in PHP and I quickly found a “proxy” script. The script is extremely simple. You run the script on the domain that the page is on, you pass in a URL that isn’t in the current page’s domain that you want to load, it reads that page on the server side and then spits out the result.
I recently ran into a need for this while working on the dashboard project. A bamboo server was upgraded to a new version and JSONP stopped working. Instead of waiting for an upgrade / fix, I just implemented a simple proxy similar to the one I had used in PHP many years ago. The following code is for rails but it could easily be ported to sinatra, etc.
class ProxyController < ApplicationController
url = request.fullpath.split("/proxy?url=")
render :text => open(url).read
In a recent retrospective a question came up about morale. That triggered a memory about an activity for tracking the mood of a team. I tried to recreate the activity as best as I on the spot. This is how it went. We passed around sticky notes, everyone drew a smile, meh, or frown face to capture their overall mood from the previous sprint. The papers were folded / crumbled to keep them anonymous. The votes were then tallied and then we discussed the results.
Obviously this method of capturing morale can lead to skewed results. It’s hard to sum up or even remember all of the things that affect your mood during a sprint. If someone is really happy or mad on the day of the retrospective, that might lead to an overall mood that doesn’t take into account the other days of the sprint.
Since I’m a Software Engineer my mind naturally jumps to solving this problem with software. So I wrote up a little application to track my team’s happiness. The code is available at github. A demo is available here.
The inspiration for this comes from the niko-niko calendar. One major difference is that this project is designed to “anonymously” track moods. Data is captured at a cookie level to link a single users stats over time, but there is nothing that will identify that person beyond what the put in their notes field.
My team just started using it halfway through this sprint so it has yet to prove itself useful. However it turns out, it was a fun bit of code to hack on.
This function will echo a command it’s about to run, run it and exit if the command failed. This will allow a script to execute many commands but if a single command fails, the script will stop. The echoing of the command provides feedback while the script is running and it also makes it clear when failures occur.
echo "running: [$@]"
(( $? )) && exit $?
try echo "testing"
try echo "this won't show up"
running: [echo testing]
./test.sh: line 3: commandthatwillfail: command not found
There are two things that I run into that I think xargs should easily handle, changing the position or order of the arguments it adds and acting like a loop over multiple lines of inputs. Typically I’m in a rush and I’ll just figure out another solution instead of opening up the man page or searching the internet for a solution. After running into the need again, I decided to stop being lazy, figure it out and document what I found so that I won’t have an excuse in the future.
Given that we have a directory with a few files in it
When I want to use each of those files as a argument to a command I could use a loop like while or for, or I could use xargs with -I like this
ls | xargs -I@ echo @ "is a letter"
a is a letter
b is a letter
c is a letter
The -I in this case means, for each input line, replace the @ symbol with the line and carry on with the rest of the command.
If you only want to run the command once, but the arguments need to be at a specific position in the call you can use -J
ls | xargs -J@ echo @ "are at the beginning of the alphabet"
a b c are at the beginning of the alphabet
And if you want the arguments to fall at the end of the call, you can just use the default behaviour
ls | xargs echo "the first three letters in the alphabet are"
the first three letters in the alphabet are a b c
There is still a lot more to xargs, but these are the typical uses I’ve found a need for.
I’m part of an agile team that’s committed to process improvement. When we first started working together, my team followed a mostly traditional Scrum method, but we have found that limiting the number of stories that can be worked on at one time, has boosted productivity and improved the team’s ability to work together.
Using the traditional Scrum method, over a two week iteration stories traveled across the four columns of our board: Ready, WIP, Test and Done. This is still largely how things work, but until recently there were no limits on any of the columns.
The beginning of a sprint would usually start with every developer pulling a story into WIP. There were cases where more than one person would work a story, but typically a developer would “own” a story, and if the set of tasks were large enough, it might be shared with another developer. Sprints in this scenario looked like two week long mini waterfalls.
The precursor to adding WIP limits was a sprint when my team had great success with intentionally “swarming” on a set of related stories. The understanding of the feature was greatly increased across the team, and the collaboration was unlike anything we’d seen before. There was a real sense of collective ownership of the feature.
This experience set the stage for trying out WIP limits. We knew that we wanted to pair and swarm more, but old habits are hard to break. Adding a rule that limited the number of stories that are allowed to be worked on at one time seemed like a logical way to force the issue, so we established parameters and gave the process a trial period of a sprint.
During the two week test run, if WIP was full and a developer had nothing to do, they couldn’t just pull something from the ready column into WIP. They had to talk to the other people on the team and find out where they could jump in and help on a story already in progress.
My team still hasn’t achieved continuous flow, but already we have seen the level of teamwork shoot through the roof, thanks to limited WIP. We continue to test out different amounts for the maximum number of stories that can be in WIP at one time. Getting the number right is important. Too low and there isn’t enough work to go around, even if everyone is pair programming. Set the limit too high and it’s the same thing as having no limit at all. The process of finding the optimal number of stories allowed in WIP can take some time and adjusting, but it is well worth the effort in the long run.
Although continuous flow is still a goal for my team, the initial test period of limiting WIP has been a great success. Not only has it stimulated collaboration and knowledge sharing, it also exposed bottlenecks and helped to fine tune the process of how to get to a sustainable continuous flow of work through the system. Already there is a greater sense of ownership and success across the team, so it’s clear that limiting WIP is a worthwhile tool for fostering a collaborative and productive development environment.