In some industries, this trend is being supported by the establishment of frameworks which divide industry operations into a series of standard processes. The individual processes provide a convenient framework for the study of organisational processes to provide a basis for best practice implementation.

So how can you get started and get going and take the operations of your business to the next level?

A Business Process Review

A simple way to achieve this, is to conduct a Business Process Review. Common Vision provides a process for performing a Process Review for a nominated business function and is something we would provide as part of our Accelerator Service.

The primary purpose of the Common Vision Business Process Review is to undertake a coarse level analysis of a business function in order to identify gaps or opportunities for major improvement rather than to conduct exhaustive documentation of an organisation’s existing processes.

How Long Does It Take?

While the duration depends upon the size and complexity of the area being investigated, the end-to-end activity typically takes in the order of 6-8 weeks from initial planning to delivery of the Process Mapping report.

What Does It Involve?

There are 4 key steps to delivering the review:

1. Initial Planning
Successful execution of a Business Process Review requires effective planning and Preparation (it also ensures the most effective use of time of the participants). Initial Planning involves a workshop with the Project Sponsor and nominated Stakeholders in which the scope of the Process Review is agreed along with the participants and Source Material.

2. Preparation
Preparation involves initial analysis of available material along with an investigation of available “best practice” references for the relevant domain. An output of the preparation phase is an interview schedule (and sometimes a questionnaire) to be completed by participants prior to interview. The interviewer will begin to compile an inventory of available material to be used as input to interview preparation.

3. Interviews & Workshops
A key element of the information gathering exercise is the in-person interviews with the nominated customer representatives with the greatest knowledge of the existing processes. Each interview will typically last in the order of 90 minutes. Follow-ups will be required with some individuals.

4. Business Process Mapping
The final stage in the Business Process Review is the creation of a Process Model describing the processes currently being performed. This activity necessarily involves the services of an individual with expertise in the problem domain under investigation. Apart from the inventory, there are three principal outputs from the business process review as follows:

CUSTOMER PROCESS MODEL SUMMARY – The Customer Process Model describes the processes currently being performed along with a mapping to an industry recognized Process Model.

PROCESS GAPS – The mapping exercise will identify any areas within the industry model which are currently not being managed within the organization (e.g. no formal process for addressing customer feedback).

OPPORTUNITIES FOR IMPROVEMENT – A summary of process gaps and identified departures from recognized best practice, which represent opportunities for improvement. Items may consist of both short and long-term suggestions for change and include both changes to process and/or the introduction of new IT systems or systems changes.

What Is Delivered?

Apart from the inventory, there are three principal outputs from the business process review as follows:

CUSTOMER PROCESS MODEL SUMMARY
The Customer Process Model describes the processes currently being performed along with a mapping to an industry recognized Process Model.

PROCESS GAPS
The mapping exercise will identify any areas within the industry model which are currently not being managed within the organization (e.g. no formal process for addressing customer feedback).

OPPORTUNITIES FOR IMPROVEMENT
A summary of process gaps and identified departures from recognized best practice, which represent opportunities for improvement. Items may consist of both short and long-term suggestions for change and include both changes to process and/or the introduction of new IT systems or systems changes.

So if you’re looking to review your Business Processes, then contact us.

For a Rails developer, isn’t this just a matter of adding a gem to your Gemfile, and running bundler?

If only it were that simple.

For this post, I’ll go through some of the steps that I took to get HTTPS going on a Rails application running locally under POW. Hopefully, it’ll be of use to somebody.

What’s POW?

So you have a rails application, which you typically fire up using:

rails s
open http://localhost:3000

What happens if you have multiple rails applications? Or for that matter sinatra, merb or any other Rack-based application? Do you fire them all up with separate ports?

Here’s where POW comes in really handy. POW! is a zero-config rack server for Mac OS X. It’s dead easy to install and get running, and makes it possible to host multiple Ruby Rack applications without each Rack application having to run in a separate web server on a separate port.

POWer me up!

To install POW, run the following in the terminal:

echo "export POW_DOMAINS=dev,local" > ~/.powconfig
curl get.pow.cx | sh
cd ~/.pow
ln -s /path/to/myapp myapp

open http://myapp.dev

Here’s a trap that I found. The documentation for POW typically tell you to download and install POW with one command, namely; curl piped to sh. However, in my experience, this did not (for some reason) configure OS X’s system resolver properly so requests were not being forwarded to POW. I had to specify the Top Level Domains (TLD) in a config file and reinstall POW. So, save yourself the trouble and set it first with the POW_DOMAINS variable in the .powconfig file before you install.

Keep the POWer on

When you start using POW, you may notice that some refreshes take a really long time to come back. This happens because POW tends to spin down the rails instance after a timeout, making it painful when you refresh your page as this causes POW to reinitialise the rails application from scratch (and we all know how long rails 3 takes to initialise). To fix this, edit your ~/.powconfig to include the following:

export POW_TIMEOUT=30000
export POW_WORKERS=3

The POW_TIMEOUT sets POW to keep the process running for a long time, which is typically what you want, given that in development, rails will automatically reload (mostly) the altered files.

So now, you can throw away the rails s command as POW will fire up the instance when you need it.

How Do I Bolt On HTTPS To POW?

AFAIK – you can’t. I looked, and I couldn’t find any way to install a certificate to get HTTPS going. So, the easiest way to bolt on HTTPS is to setup Nginx as a reverse proxy. And although it sounds hard, it isn’t.

Nginx is fast HTTP server. And like any capable HTTP server, it is able to accept HTTPS connections and can be configured to proxy requests through to POW.

Bolt In Nginx

To install Nginx on OS X, you have two choices:

1. Install it via Brew
2. Install it the old fashion way

Brew me an Nginx

The easy way is to use Brew. Just run

brew install nginx

Done.

I Don’t Have Brew

If you’re like me, and you’re already using MacPorts and haven’t made the switch to brew, then you have to do things the hard way. I followed instructions on Kevin Worthington’s Blog but specifically, I had to do the following:

1. Install XCode(I already had XCode installed previously so I didn’t have to do anything). Installing XCode is a matter of downloading it and installing it. In fact, if you’re running Snow Leopard or Lion, you can download it and install it directly via the Mac App Store.
2. Install PCREThis required me to download the source and install it manually. The steps I took were as follows:

   sudo mkdir -p /usr/local/src
     cd /usr/local/src
     sudo wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.12.tar.gz
     tar xvfz pcre-8.12.tar.gz
     cd pcre-8.12
     ./configure --prefix=/usr/local
     make
     sudo make install

3. Install NginxInstalling Nginx is a matter of downloading the source, building and installing it. I followed the following steps:

   cd /usr/local/src
     sudo wget http://nginx.org/download/nginx-1.0.4.tar.gz
     tar xvfz nginx-1.0.4.tar.gz
     cd nginx-1.0.4
     ./configure --prefix=/usr/local --with-http_ssl_module
     make
     sudo make install

Intermission. Time For Certificates.

Ok. Time for a break. Time to break out openssl to generate some certificates.

HTTPS sits on top of Secure Sockets Layer (SSL). For this to work, the encrypted communication requires certificates to be installed at the web server end. In production, you would purchase the certificate from a Certificate Authority (CA) like Verisign or Digicert. The CA’s role is to issue you with a certificate that verifies the identity of the entity the certificate is for (e.g. the domain name owner).

But for development, you don’t need a certificate from a CA. All you need is openssl to generate a certificate which is self-signed. There are countless articles on the web describing this process in detail. www.akadia.com’s article seems to be pretty self explanatory.

Once you’re done generating the certificates, you will need to either copy or symlink them to the appropriate Nginx location so that Nginx can find them. To do this, I did the following:

cd /usr/local/conf
mkdir ssl
cp server.crt ./ssl
cp server.key ./ssl

I Have Nginx. Now to configure it.

If you followed my install instructions above, then Nginx’s conf file is located in

/usr/local/conf/nginx.conf

You will need to edit the nginx.conf file to configure Nginx to:

1. Use the certificates you generated
2. Listen to port 443 to handle the HTTPS protocol

Here’s what I added to the nginx.conf file to configure Nginx as a reverse proxy.

[text]
server {
listen 443 ssl;
server_name myapp.dev;

ssl on;
ssl_certificate ssl/server.crt;
ssl_certificate_key ssl/server.key;

keepalive_timeout 60;

ssl_session_timeout 5m;

ssl_protocols SSLv2 SSLv3 TLSv1;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
ssl_prefer_server_ciphers on;

location / {
proxy_pass http://127.0.0.1;
### force timeouts if one of backend is died ##
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;

### Set headers
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

### Most PHP, Python, Rails, Java Apps can use this header
proxy_set_header X-Forwarded-Proto https;

### By default we don’t want to redirect it
proxy_redirect off;
}
}
[/text]

The things that you may need to alter are:

• server_name – enter the domain that matches what you would enter to hit POW
• ssl_certificate – enter the location of your server.crt file. If you copied the certificates
  to /usr/local/conf/ssl, then enter ssl/server.crt since the
  nginx.conf resides in /usr/local/conf
• ssl_certificate_key - enter the location of your server.key file. This should be similar
  to that for ssl_certificate

The rest of the configuration tells Nginx to proxy the request to localhost on port 80, which is where POW will
kick in and handle the request for you.

Configured!

Once you're done, fire up Nginx using /usr/local/sbin/nginx and test it by navigating to https://myapp.dev.

"You gotta blog about this man..." cried Alan after I checked in. In acknowledgement, I nodded. Fast forward four weeks later, after CrowdHired has launched... I now have some breathing space to really blog about it. So hopefully this has been of help to you and saved you some time along the way.

For any professional services company, the quality of people is a key factor in the value of the service which that company is able to provide. Graduate recruitment will become an increasingly important component in that equation for Common Vision along with existing fundamentals we apply to personnel selection and development as follows:

1. Recruit and develop highly-skilled Professionals in strategic disciplines with a solid understanding of “best practice” IT delivery techniques
2. Develop internal practice-specific collateral, practices and Intellectual Property for IT delivery
3. Continue to develop all staff on a “best you can be” basis through training, mentoring and encouragement to participate in best practice forums within the industry
4. Grow our practice through an annual graduate recruitment program with an emphasis on high-potential individuals with Common Vision providing training and mentoring in Common Vision disciplines and practices
5. Focus on the motivation and desire to “grow” their professional capabilities (depth and breadth).

While I’ve previously been involved in co-ordinating graduate recruitment at other organisations, this is the first year Common Vision has instituted a formal graduate recruitment program. I wasn’t sure how many candidates would be sufficiently motivated to make the trek over from the University to check out the 130 or so employers who exhibited on the day but we expected that Jason, Lorena and I would be sufficient to handle the queries. As we are only hiring 2 graduates for our 2012 intake, this year we only attended the Melbourne University Careers Fair (for the simple reason that we were most familiar with that University’s curriculum).

For those of you interested in the practicalities of the fair, exhibition set up was conducted between 9 and 11am with an opportunity to meet the other exhibitors from 11am. Doors open to candidates at midday with a nominal close time of 4pm. We provide a standard graduate brochure to anyone who expresses an interest in applying after we have discussed our company and their studies. As an indication of the level of interest received, 46 application brochures were requested by candidates. While any of our impressions of candidates on the day are necessarily brief and imperfect, my personal assessment is that there no less than 25 individuals whom we met that would have a chance of success. Five of these individuals might reasonably be considered “very strong” candidates. Our brochure provided all candidates with an online puzzle that they can complete to demonstrate their programming capabilities so any response from that exercise might give us a better idea.

While it wasn’t possible for us to spend more than 10 minutes or so with any individual on the day (interviews come later) we were able to confirm that there are some excellent candidates with a diversity of skills and interest who are now considering an application for employment with our company. Given that most of these individuals would never have heard of us previously, our participation in the graduate fair can be considered an unmitigated success.

Meeting other exhibitors before the event

Jason brought along a camera to take pictures during the day. He took a few pictures before the doors opened but the level of interest was such that the 3 of us were kept busy for the 4 hours and beyond. If we look a little lonely in the following picture it’s because it was taken after the fair had closed and just as our last students were heading off on their way.

After the Fair

While we remain unconvinced of the merits of the new “Melbourne Model” introduced in 2008 http://uninews.unimelb.edu.au/news/4155/ we could only be pleased with the organisation, preparation and communication for the careers fair. Next year we shall extend our graduate program to Monash University and RMIT and would like to involve members of our consulting staff in one or more of the sessions. We shall also arrange for an additional exhibition banner and “Common Vision Graduate Recruitment Team” t-shirts for staff representing the company on the day.

If you have any interest in participating in future graduate recruitment activities, please indicate your interest to Lorena with a cc to recruitment@commonvision.com.au.

So your rvm is up to date. And now you have to roll with ruby 1.9.2.

In my previous post, I went through how I got around a ruby 1.8.7 install error. And that error had to do with readline.

Well, if you ran

rvm install 1.9.2

And go the following error:

ruby-1.9.2-p0 - #fetching
ruby-1.9.2-p0 - #downloading ruby-1.9.2-p0, this may take a while depending on your connection...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 8296k  100 8296k    0     0  23037      0  0:06:08  0:06:08 --:--:--  8643
ruby-1.9.2-p0 - #extracting ruby-1.9.2-p0 to /Users/jasonn/.rvm/src/ruby-1.9.2-p0
ruby-1.9.2-p0 - #extracted to /Users/jasonn/.rvm/src/ruby-1.9.2-p0
ruby-1.9.2-p0 - #configuring
ruby-1.9.2-p0 - #compiling
Error running 'make ', please read /Users/jasonn/.rvm/log/ruby-1.9.2-p0/make.log
There has been an error while running make. Halting the installation.

If you examine the make.log file, the last few lines may show the following:

compiling readline
gcc -I. -I../../.ext/include/x86_64-darwin10.5.0 -I../.././include -I../.././ext/readline -DRUBY_EXTCONF_H="extconf.h" -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE   -fno-common -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch x86_64 -fno-common -pipe  -o readline.o -c readline.c
readline.c: In function ‘username_completion_proc_call’:
readline.c:1292: error: ‘rl_username_completion_function’ undeclared (first use in this function)
readline.c:1292: error: (Each undeclared identifier is reported only once
readline.c:1292: error: for each function it appears in.)
make[1]: *** [readline.o] Error 1
make: *** [mkmain.sh] Error 1

Fortunately, this is exactly the same problem as before. All you need to do is tell the compiler where the readline library is. If you setup is similar to what I indicated in my previous post, then all you have to do to install 1.9.2 is:

rvm install 1.9.2 -C --with-readline-dir=/usr/local

So if you’re like me, and was wondering how to do custom validation on a field, it turns out that it is simply a matter of adding logic to the validate block like so…

class MyModel
   include Mongoid::Document

   validate do
      errors.add(:atttribute, message) if attribute_is_invalid?
   end

end

You might be tempted to start hacking a string message in your errors collection, but there’s good reason to externalise your error messages to a separate locale.yml file. The sooner you start externalizing them, the easier it will be later to support other languages. So how do you generate an appropriate i18n message?

On first go, you might think that the easiest way is to use:

I18n.t('mode.attribute.error')

However, this doesn’t quite fit how other ActiveModel errors are namespaced. Typically, they follow the following convention:

en-us.activemodel.errors.models.[MODEL].attributes.[ATTRIBUTE].[ERROR]

As I was looking to an answer to this question, I stumbled on ActiveModel::Errors.generate_message(). It looks like all you need to do is to meet the following signature:

generate_message(attribute, type = :invalid, options = {})

So this transforms the above validate block into something like this:

class MyModel
   include Mongoid::Document

   validate do
      errors.add(:atttribute, errors.generate_message(:attribute, :error)) if attribute_is_invalid?
   end

end

Hopefully this will help somebody else out there to save some time trying to crack this nut.

One important thing to start realising on a green-field project is to always take time to improve. And one area that developers should always focus on is the build.

The importance of builds

Builds are an important safeguard in any project. On most projects, developers typically run builds before they checkin. Indeed, it is good practice to make sure everybody gets into this habit. If your team takes a “don’t care” attitude, checking in regardless of whether the continuous integration server is green, this can quickly lead to massive development pain.

So, let’s assume that your team is building before checkins. Great.

Pay attention to your build times

If you’ve been on a sizeable project (duration, scope, people), most people suffer from bloated builds. Sometimes they take 2 hours to turn around, from commit to deploy. When that situation occurs, most of us start loathing the build.

Which is why on any new initiative, you may start out with every intention to minimise build times. But when do you start factoring this activity in?

In my opinion, as soon as you can.

Why? Because you will start to learn something new. You will begin to learn what makes the build take too long, and start rolling in steps to stop them from occurring in the future. You will also learn what testing methods are slow, and therefore take the effort to use them only when needed.

And the sooner you do this, the faster your team will be in addressing these problems. It’s much easier to address these problems earlier (when you have 50 tests) rather than later (when you have 5000 tests, and your build is taking 1 hour).

Learning is the bottleneck

Many lean/agile books will promote the idea that “Learning is the bottleneck”. Note that this isn’t coding. If it was coding, then we should be optimising our practices to code faster. The problem here is that coding faster is entirely predicated on how quickly your team learns and adapts. So focus on giving your team the learning opportunity it needs to avoid pitfalls and problems.

And a key to that is learning how to write good tests in the environment. Learning to make sure that the feedback you get is appropriate and quick, which drives the next cycle of learning.

Case study: 161 tests taking 5 sec

On a recent project I am on, it was a new initiative. So I had built up a stead suite of specs. Thing is, I realised that the 161 tests I had was starting to take a little too long ~ 5 seconds.

Now 5 seconds for a build isn’t long at all by any means. You could put up with it. But I know, that on an large project in the same environment, they ran 9,000 or more tests within 45 seconds. If you do the math, that’s 200 tests per second.

Here, I was taking 5 seconds for 161 tests. If I project it out, at 9000 tests, that would take me 80 hours to complete!

Step 1: Profile your tests

The first thing you should do, is profile your tests, and get an idea of the tests that are taking the longest. With a small number of tests, this is easier to find out, and you can quickly focus on a cluster of tests that are doing similar things. Most unit testing libraries have some means of timing how fast tests take, so getting this information shouldn’t be difficult.

Step 2: Experiment, and validate

Then, experiment. Think about what could be causing the issue. Try something, and re-profile the test. Make sure that what you’re doing leads to an improvement. Don’t just guess and hack. You need to validate as well.

Step 3: Commonize and disseminate

Once you have a “fix”, codify it. Write it into a helper method/class and refactor your tests that have the problem to use the new solution. Then socialise it. Announce it at a standup. Send out an email. Talk about it.

This last step is really important. The time you have invested into learning and fixing an issue is now going to help you many times over. By codifying it, you’re encoding the knowledge into the code repository, which will stick around long after you have left the project. Codifying it also helps others out, so they don’t have to walk into the same pit-hole you did.

Socialising it helps your team establish a general guideline around how tests should be written/approached. In may mean that that particular kind of test isn’t warranted under all circumstances. Establishing a baseline in your team for how this is approached is key to ensuring you have the right kind of tests.

Summary

Here’s the 3 point summary:

1. Pay attention to your build times, even with a few tests.
2. Aim for a 200 tests per second (or better) test/rate
3. Profile, experiment, validate, codify and disseminate the information

What are your test rates? Can you beat 200 tests per second?

A big thank-you in particular to all who assisted us in our Market Research activities just before the Christmas Break. Of the 25 specific survey requests we sent out across the 3-categories we had 24 genuine responses which is pretty remarkable given the surveys were issued in the 10-days leading up to Christmas. I trust it didn’t interfere with anyone’s Christmas shopping.

Jason and I were very grateful for your time in providing the input. All of the information provided from the survey responses has been assessed and was used as an input to a series of workshops leading up to the break. It is now being used to assist business model planning and validation in January and we expect to be in a position to provide an update on the initiative in early February via this forum.

In addition to assisting Common Vision, the survey respondents also indirectly assisted disadvantaged children. Due to the responses of the survey participants, Common Vision was pleased to donate $150 to the Starlight Foundation www.starlight.org.au on Christmas Eve. “The Starlight Children’s Foundation is part of the Australian Children’s Charities Forum, a group of national children’s charities dedicated to directly helping seriously ill, disabled or disadvantaged children.”

Since this is relatively new, Heroku and MongoHQ have very little “official” documentation. So this post is a collection of various “learnings” and experiences that I have found across the internet. Hopefully it will help you out if you’re intending to do the same.

Step 1: Add the Heroku MongoHQ Addon

As per http://docs.heroku.com/mongohq, the first thing you need to do is add the MongoHQ addon. To do this, you can either use the Heroku web interface or run the following command

heroku addons:add mongohq:free

Once you do this, a brand new MongoDB database is automatically created. In addition, the MONGOHQ_URL environment parameter will also be set, which contains the connection string that is used to access your MongoDB instance hosted by MongoHQ.

Step 2: (optional) Configure MongoHQ’s MongoDB Remote Connection

NOTE: the following instructions came from:
http://support.mongohq.com/discussions/community-tips/2-logging-in-to-mongohq-for-heroku-users

MongoHQ provides a simple way to view and manage MongoDB instances. So to use what they offer, you will need to “Add a Remote Connection”, and populate that with the MONGOHQ_URL connection string. This is entirely optional, but the web interface is a very neat way to view, manage and see your MongoDB instance.

To do this, first extract the MONGOHQ_URL connection string. Run

heroku config --long --app <app_name>

Where –app <app_name> is entirely optional but may be required depending on your setup.

What you see is a list of environment variables, and one of them should be the “MONGOHQ_URL” value. Copy it.

Then, in MongoHQ (http://www.mongohq.com), after creating an account, you can “Add a Remote Connection”. You will need to provide:

1. A name (call it anything you like)
2. A URI (this should be the value provided by the “MONGOHQ_URL” connection string)

After creating the link, you should be able to navigate and see what’s in the mongodb instance. Importantly, the application shows how much space the database is taking up, which makes it easier to monitor your database size/growth. This latter point is important given that MongoHQ doesn’t currently (2010.12.30) support email alerts to tell you if your DB is getting close to the maximum size permitted by your current plan. Once you do hit that limit, the support documentation indicates that writes will begin failing.

Step 3: Configure Mongoid In Rails 3

Over at http://mongoid.org/docs/installation/, you will find fairly clear instructions for getting Mongoid going. However, at the time of writing, there are few things I have found that you will need to do.

The first is that the Gemfile instructions specify bson_ext version of 1.1.2. At the time of writing (2010.12.30), I found out that the mongo gem (which is a dependency of mongoid) had already moved to 1.1.5. The bson_ext and mongo gem must match in version… so enter the following instead:

gem "mongoid", "2.0.0.beta.20"
gem "bson_ext", "1.1.5"

Then configure mongoid in your rails by running

rails generate mongoid:config

This will create a file under config/mongoid.yml.

Now, there are a couple of gotchas here. There’s a stackoverflow post which details some problems in getting mongoid to run under the Heroku + MongoHQ stack. Basically, if you specify host in your mongoid.yml file, it overrides the value you specify as uri.

So my example mongoid.yml configuration looks like this…

defaults: &defaults
  allow_dynamic_fields: true
  parameterize_keys: true
  persist_in_safe_mode: true
  raise_not_found_error: true
  reconnect_time: 3
  use_object_ids: true

development:
  < <: *defaults
  host: localhost
  database: myapp_development

test:
  <<: *defaults
  host: localhost
  database: myapp_test

# set these environment variables on your prod server
production:
  <<: *defaults
  uri: <%= ENV['MONGOHQ_URL'] %>

The key point of note is that host is specified for the development and test environments. For production, set the uri value with the ‘MONGOHQ_URL’ parameter.

Step 4: Test, Test, Test

The simplest way to test this, is to run

rails generate scaffold User email:string

If you have mongodb installed locally, then fire up your rails app, and check that the user resource can be added, deleted, modified and listed.

Then add everything and deploy directly to Heroku to see if everything is ok.

After this great big hack, you’re free to go back to the land of TDD/BDD and resume the normal course of development.

Judging by the numbers in attendance, YOW 2010 in Melbourne was a huge hit. Not only was there an all-star lineup of guest speakers, including Rod Johnson from Spring, Erik Meijer from Microsoft (architect of LINQ), Corey Haines, J. B. Rainsberger, Guy Steele, Oren Eini (of Rhino.Mocks and NHibernate optimisation fame), Michael T. Nygard and Mary and Tom Poppendieck, but the event was heavily attended by the who’s who of the Melbourne Software Development scene.

The topics presented were wide and varied. Some were case studies, others were instructional and even some were entertaining.

Of particular note was a talk delivered by Richard P. Gabriel and Guy Steele – who created a mosaic survey across 50 computing languages (entitled “50 in 50″ which you can see on the JAOO blog). Their composition was entertaining, witty and down right nerdy.

Much thanks goes to the conference organisers and speakers and even attendees. It was a great event, and one which we hope will continue in many years to come.

Thankfully Twitter has actually thought about this, though information is rather scarce. If you go to http://twitter.com/search and keep hitting refresh you get a few useful tips. You can try advanced search (http://search.twitter.com/advanced – though I can never find this link on the main site and instead I have to use google) to get an idea of just what is possible. However if you use a twitter client on your desktop or your phone then this is a bit tiresome. You could try the operators, see http://search.twitter.com/operators. But again nothing immediately obvious until you remember that a lot of the retweets are normally prefixed with a RT or VIA (an alternative way to retweet) and notice that Twitter have supplied an exclude option via the minus(-) operator.

Thus armed you can prune the retweets by adding -rt (and also -via) to your searches and remove all the repeated twitterings e.g. to search for all tweets that have been tagged with azure or cloud but to ignore the repeats I would use:  #azure OR #cloud -rt -via

Now the amount of information is reduced and, assuming your search is limited in scope i.e. does not involve a trending topic or major celebrity, manageable.