Download the XCode project (CommandLineSample.tar.gz, 48kB) – including a sample

 

The CommandLine class is very simple and offers the following functionality:

• Validates and parses the command line arguments according to user defined struture of options (NSDictionary)
• Options can be declared required or optional, followed by option value or not
• Minimum number of expected parameters (beside options) can be set
• When command line parsing fails, a message describing the error can be retrieved

A sample use of the CommandLine class:

#import <Foundation/Foundation.h>
#import "CommandLine.h"

int main (int argc, char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    BOOL parseSuccess;

    CommandLine *commandLine =
        [[CommandLine alloc] initWithArgc: argc andArgv: argv];

    // This sample expects at least one parameter (other that options)
    int sampleMinNumberOfParams = 1;

    // Define the matrix describing expected options
    NSDictionary *sampleOptionsMatrix =
        [NSDictionary dictionaryWithObjectsAndKeys:
            CL_OPTION_REQUIRED, @"a",
            CL_OPTION_OPTIONAL, @"b",
            CL_OPTION_REQUIRED_WITH_VALUE, @"f",
            CL_OPTION_OPTIONAL_WITH_VALUE, @"x",
            nil];

    // Pass on required parameters to the parser and execute the parser
    [commandLine cL_setOptionsMatrix: sampleOptionsMatrix
    andMinNumberOfParams: sampleMinNumberOfParams];

    parseSuccess = [commandLine cL_parse];

    if (parseSuccess) {
        // Display the parsed options.
        for (NSString *key in commandLine.parsedCommandLine) {
        NSLog(
           [NSString stringWithFormat: @"Option: %@ Value: %@", key,
           [commandLine.parsedCommandLine valueForKey:key]]);
        }
        //And some more processing of a successfully parsed command line:
        if ([commandLine cL_optionIsSet: @"b"]) {
            NSLog(@"Option b was set");
        }
        NSLog(
            [NSString stringWithFormat: @"Value of the 1st parameter is %@",
            [commandLine cL_parameterGetValue: 1]]);
    } else {
        //Display the error message
        NSLog(commandLine.resultText);
    }

    [pool drain];
    [commandLine release];

    return 0;
}

A few notes:

• Alternative long option names are not supported
• The options matrix appears to be somewhat verbose, hope it is not too much overhead
• The CommandLine class source code enables some documentation to be generated using objcdoc

Feel free to use and modify the class in any way. Now off to the next step: learning the Google Data APIs Objective-C Client Library.

Yes it can. It is relatively straightforward to write a simple program to retrieve real-time stock quote using just Google Spreadsheet Data API. Below is a simple proof-of-concept script which does the job. To make it work, create a new Spreadsheet on Google Docs and int the cell A1 fill in a formula for your favorite stock quote, something like:

=GoogleFinance("GOOG")

You will see the price in your spreadsheet:

The script to retrieve the quote:

#!/bin/bash

wget -O ClientLogin.txt --no-check-certificate --post-file=post.txt \
"https://www.google.com/accounts/ClientLogin" >/dev/null 2>&1

TOKEN=`cat ClientLogin.txt | grep Auth \
| sed "s#Auth=##" | xargs echo -n`

wget -O Spreadsheets.txt --header="Authorization: GoogleLogin auth=${TOKEN}" \
--header="GData-Version: 2" \
http://spreadsheets.google.com/feeds/spreadsheets/private/full >/dev/null 2>&1

WORKSHEET=`cat Spreadsheets.txt | \
sed "s#\(.*\)src=\([']*\)\([^']*\)\([']\)\(.*\)#\3#"`

wget -O Worksheet.txt --header="Authorization: GoogleLogin auth=${TOKEN}" \
--header="GData-Version: 2" ${WORKSHEET} >/dev/null 2>&1

cat Worksheet.txt | sed 's#\>#\>\
#g' >WorksheetFormatted.txt

CELLSFEED=`cat WorksheetFormatted.txt | grep cellsfeed | \
sed "s#\(.*\)href=\([']*\)\([^']*\)\([']\)\(.*\)#\3#"`

wget -O Cells.txt --header="Authorization: GoogleLogin auth=${TOKEN}" \
--header="GData-Version: 2" ${CELLSFEED} >/dev/null 2>&1

cat Cells.txt | sed 's#\>#\>\
#g' >CellsFormatted.txt

REALTIMEQUOTE=`cat CellsFormatted.txt | grep numericValue | \
sed "s#\(.*\)numericValue=\([']*\)\([^']*\)\([']\)\(.*\)#\3#"`

echo "Quote = ${REALTIMEQUOTE}"

where post.txt is something like:

POST /accounts/ClientLogin HTTP/1.0
Content-type: application/x-www-form-urlencoded

accountType=HOSTED_OR_GOOGLE&Email=__EMAIL__&Passwd=__PASSWD__
&service=finance&source=yken.org-GoogleStockQuote-0.1

A few notes on the script:

• Replace __EMAIL__ and __PASSWD__ in post.txt with your Google credentials
• This will only work when you have just one spreadsheet on your Google Docs
• The script does not parse the XML replies, it just gets the values it needs using brute force (as it is just a proof of concept).
• Three requests (four with login) just to get a quote is definitely over the top. The Google API allows batch operations, too.
• I tried this on Max OS X 10.5 only

To make the script actually useful, it would be good to modify it to take some parameters, for instance at least the desired stock symbol and then to use that stock symbol to write the =GoogleFinance() formula to A1. Google Data API allows it. This way, the script could be used for retrieving any quote (available on Google Finance), not only just the hardcoded one. Also, there are many Google Data API Client Libraries available, allowing to rewrite this script into something proper. I will try both and will post the result here.

Important note: all stock data obtained by the above script can be used for personal informational purposes only, see the Google disclaimer.

It turned out hat the cause of getting the 401 error was in the way I set up the Authorization header sent with my requests. Unlike with AuthSub Authorization header used for web applications, the token value for ClientLogin authentication must not be enclosed in (double-)quotes. This is a mistake easy to make when switching from AuthSub to ClientLogin, resulting in HTTP status 401 reply for any Data API request. Remove the quotes around the token and the Data API request will work fine.

A small sample:

#!/bin/bash

if [ -e ClientLogin ]
then
  rm ClientLogin
fi

wget --no-check-certificate --post-file=post.txt \
https://www.google.com/accounts/ClientLogin

TOKEN=`cat ClientLogin | grep Auth | \
sed "s#Auth=##" | xargs echo -n`

wget --header="Authorization: GoogleLogin auth=${TOKEN}" \
http://finance.google.com/finance/feeds/default/portfolios

where post.txt is something like:

POST /accounts/ClientLogin HTTP/1.0
Content-type: application/x-www-form-urlencoded

accountType=HOSTED_OR_GOOGLE&Email=__EMAIL__&Passwd=__PASSWD__
&service=finance&source=yken.org-learningGoogleAPI-0.1

Replace __EMAIL__ and __PASSWD__ with appropriate value. When the script is finished, you will have the relevant portfolio information saved in the “portfolio” file.

1. Install Ruby programming language and Rails framework

$ sudo yum install ruby
$ sudo gem install rails  --include-dependencies

2. Install header files and libraries for building extension libraries for Ruby

$sudo yum install ruby-devel

3. Download and install Passenger, an Apache module for deployment Ruby on Rails applications on Apache. When running “passenger-install-apache2-module”, follow the instructions on the screen to solve any problems (the installer is friendly and helpful).

$ sudo gem install passenger
$ passenger-install-apache2-module

4. Create a sample Ruby on Rails application

$ cd ~/public_html
$ rails  demo

5. That’s it, you should now be able to access your Ruby on Rails application on localhost using web browser

At Desktop & Services department at TomTom we have been practicing the agile approach to developing software for a while already. Morning stand-up meetings, timeboxed sprints… our team worked like this for nearly nine months. While we did get the basics more less right, some essentials we were still missing. So we started working on resolving them. Besides resolving the major issues, we also started changing small details of how we worked. One of such changes was the way we visualise a sprint. Seemingly a trivial change proved to be a quite important one. Until the last sprint, I’ve always been wondering how to administer the sprint tasks the way that (1) all team mebmers could get easy overview of the status of all tasks, (2) the product owners could review the status without having to talk to the Scrum Master, (3) Scrum Master could avoid mailing the information around or engage in daily task list printouts.

We used to use the MS Project to plan the sprints. Using the MS Project proved to have many limitations: the waterfall Gantt chart being generated for anything we planned, sharing the status of the sprint always involved printouts and the printouts which were becoming obsolete in matter of hours. Editing the source file by more than one person at time was impossible. With the developers starting to use various flavors of operating systems on their work stations, we finally decided to ditch using this proprietary tool (and to save a tree, too!). A brief experience with using the MS Excel brought exactly the same problems. Jira served us well all that time to work with bugs, using it for documenting the spritns didn’t really work either.

The answer to all above problems was… the Scrum Board! Jeff showed us some sample photographs and we also found great inspiration in Henrik Kniberg’s “Scrum and XP from the Trenches”. We’ve confiscated an unused white board and turned it into a Scrum Board in no time. The result? Everyone can now clearly see the status of the work items. No print outs or status reports needed anymore. This really saves us a considerable deal of time. The burndown chart is a great velocity indicator and a good source of motivation, too. And last but not least – the developers are having fun working with it.

We completed our first sprint using the Scrum Board. It is clear that we will continue using it for time being!

This week, I was lucky to be able to attend the Scrum sessions by Jeff Sutherland, agile systems architect and one of the co-creators of the Scrum software development processes. Jeff, currently travelling the globe with the Scrum Certification World Tour, proved to be a skilled expert and a charismatic speaker. There is no point to enumerate here what everything we’ve learned during the sessions – there are numerous books and papers out there. For me personally, two things were important to learn:

(1) The success of using Scrum by a development team highly depends on whether the business (the product owners) understand how team works and why the team works the way it does. If the agile way of making software was introduced bottom-up, go ahead and talk to the business, educate them, argument, involve them! (2) A great deal of the agile methods is about people and about transparency. Enpower the people, forget about being directive, become the facilitator. Do not assign tasks, make the team to be hungry for them.

Jeff had demonstrated that it might take as little as just a single Scrum Master to spark the rebuilding of whole organization to work in an effective, agile way. I wonder how successful can we be in such transformation of development processes at TomTom where I work, I look forward to the challenge.

At the end of the Scrum sessions we learned one more important thing: the Scrum Master secret handshake. Now I can no doubt recognize the great Scrum Masters around. To learn what the secret handshake is, you’ve got to attend some of Jeff’s sessions – I highly recommend!