It’s a lesson I learnt early in my engineering career but often it can be hard to get the message across to others and something that I need to stay disciplined on adhering to myself.

Integration, whether it be system or data, between components in an organisation, is exclusively about collaborating with everyone (I mean literally everyone) you can think of who may have any interest in the components in play. I’ve seen situations where collaboration between many of the impacted groups is had but not all are included. The risk is somewhat diminished with each group in the mix but there is always a residual risk while ever all of them are not included.

The reality is that you need to start with assuming that all these groups need to be consulted:

• Architecture
• Security
• Risk and Compliance
• Infrastructure
• Operations
• Application Delivery teams of impacted assets
• Related Business Owners of the impacted assets

Not engaging with ALL these groups increases your risk of something coming unstuck in your integration approach. And there is every chance that the problem with the solution may not come to light until you are in production and then you can be a real pickle with a lot of frustrated stakeholders.

Important to note that working with all these stakeholders doesn’t guarantee successful integration, but it does ensure that you have awareness and buy-in from all so when things don’t appear to be working out how everyone hoped, you have a cohesive working group to help find the way forward.

It is not always practical and appropriate to involve all these stakeholders. You should pair it back based on several factors:

• Integration pattern usage
  • The less common this type of integration pattern is between these components means more collaboration required!
• Usage of published APIs
  • If the producer has published and well documented APIs along with SLAs and an acceptable use policy then the consumer has little need to engage with the producer directly - but they need to ensure that they have consumed and understood all the information provided. Organisations are getting better at this type of approach even for internal APIs (spurned on by the advent of Micro Services) but you would need to judge just how mature your organisation is at doing this.

And finally, this needs to be complimented with smart engineering practices like up front Consumer-Driven Contracts, continuous integration testing, and lots of ongoing communication during the SDLC.

Our concerned UX Design Manager stumbled upon this now infamous article:

The sad state of web development

The author copped a lot of flack about this but ultimately the web community has been acknowledging that the new world of front end web development is still too hard. There have been efforts to lower the barrier. No doubt if our teams started their journey into Node and React now as opposed to 9 months ago, it would be easier already to adopt.

I can appreciate the complexity of the front end now but what the JS community in particular has not done well is provide opinionated approaches and frameworks which ultimately drives adoption and a level of common understanding. Infact they have done almost everything they can to avoid it (very web really, always a bit punk) but the result is ultimately ambiguity, complexity, duplication and confusion. It feels to me that the tide is starting to turn and opinionated approaches and frameworks are starting to come through but there are still gaps where developers just need to work it out.

I still struggle to see the positive trade-off of the high quality outcomes of the node/react world vs the productivity of the Rails/jQuery world. Rails always prided itself on being opinionated, complete and incredibly simple to use. Node and React pride themselves on being incredibly flexible, un-opinionated and capable of doing the most amazing things. What is the ideal? Well, like most things it’s probably somewhere in the middle!

… and by that I mean Rails 5 with React

Upgraded to Mac OS X Mountain Lion yesterday and it wasn’t a big deal on many fronts:

• Using the App Store, its so simply to upgrade – Second time round and its now becoming the de facto standard for how large install-base commercial operating systems should be upgraded
• It only costs $20 (AU$21) – Such a small price to pay to upgrade your OS X, but…
• It isn’t a huge upgrade – Nice features and all, nice moments of joy but no wow factor. The social aspects of the OS are really baked in now and the incorporation of iOS features (like Notification Centre and Messages) show Apple’s convergence strategy coming together for the two platforms. Mind you, I was really hanging for AirPlay mirroring only to find out that my October 2010 purchase of a MacBook Pro was not compatible. You need 2011 hardware for that feature. There is always AirParrot I suppose, but now that ABC iView supports AirPlay in their iPhone app, I may be able to live without this feature until my next laptop upgrade.
• It happens every year – Frequently making major upgrades to the OS takes the excitement, risk and price out of it. I’m starting to look forward to Christmas in July now. And like most Christmas presents nowadays, it is always well received but rarely takes my breath away.

Mountain Lion is not a big deal on many fronts and that’s the point.

(I starting writing this entry on the train trip home yesterday from North Sydney to Newcastle)

Today is my last day at MLC (NAB). After nearly 9 years with the company I am pulling up stumps as my family and I make the sea change to Newcastle.

I am incredibly excited about the move to Newcastle and starting with my new company on Monday. Having said that, there has been plenty to reflect upon over the past couple of weeks. The event of leaving a company has only happened once before in my professional career. It feels profound, not so much for the legacy that I am leaving behind but more because I won’t be interacting on a regular basis with the people that I spent so much time growing and learning with over an extended period. I won’t be sharing experiences any more, working together, getting through challenges, making improvements, experimenting, laughing!

In more recent times, I was fortunate to be part of a great team led by a brilliant manager who taught me much about what it means to really lead. We implemented a step-change in the way our team operated, pushed the boundaries, shook things up, got ourselves into a bit strife every now and then, learnt heaps and came out the other side with a fantastic outcome… Hopefully a sustainable approach to doing things better.

It is also the place that I met my wife, subsequently got married, and had children – all significant life events! The same place where I got myself fit again, gained a taste (and need) for coffee and lost most of the hair on top of my head (… the kids may have a bit to do with that)!

So this is a formal goodbye, but I know we’ll stay in touch!

Pre-requesites:

• RVM on your local machine with Ruby 1.9.2
• Heroku account

Switch to the 1.9.2 version of Ruby, install the rails and heroku gems, create your rails 3.1 application

$ rvm 1.9.2
$ gem install rails
$ gem install heroku
$ rails new tickets
$ cd tickets

Add in the nifty-generators gem:

/Gemfile gem “nifty-generators”, :group => :development Terminal $ bundle install Generate the layout

Terminal $ rails generate nifty:layout Now make compatible with Rails 3.1 asset pipeline (assuming this is only temporary until gem is updated for Rails 3.1)

Rename /public/stylesheets/application.css to nifty.css and move to the /app/assets/stylesheets dir Delete /public/stylesheets Update javascript to use “application” instead of :defaults

/app/views/layouts/application.html.erb <%= javascript_include_tag “application” %> Generate the scaffold for a ticket, migrate the schema, and start the server to test locally at http://localhost:3000

Terminal $ rails generate nifty:scaffold ticket name:string description:text

$ bundle exec rake db:migrate

$ rails server Point to our tickets controller as default Remove public/index.html Update root route in routes.rb

/config/routes.rb root :to => ‘tickets#index’ Initialise the git repository and perform first commit

Terminal $ git init

$ git add .

$ git commit -m “Initial commit” Create the app on heroku using the cedar stack (its the only stack that currently supports Rails 3.1)

Terminal $ gem install heroku

$ heroku create –stack cedar Notice that there is now a new remote on our git repo

Terminal $ git remote -v Heroku uses postgresql by default, update gems

/Gemfile gem ‘sqlite3’, :group => :development

gem ‘pg’, :group => :production Terminal $ bundle install Commit changes

Terminal $ git add .

$ git commit -m “Updated database gems to cater for postgresql on Heroku” Push app to heroku, migrate the schema on the server, and open a browser to see it running

Terminal $ git push heroku master

$ heroku run rake db:migrate

$ heroku open Installing the custom domain Add-on

Notice that it has a unique subdomain, lets give it our own sub-domain name through the Custom Domain add-on

Terminal heroku add custom_domain

heroku domains:add tickets.passbyvalue.com Add a CNAME record on the DNS for the preferred subdomain (note that top level domain DNS rules are different) that we want to use and now try it out!

http://tickets.passbyvalue.com

Tutorial: http://devcenter.heroku.com/articles/custom-domains

Jump into the console and see under the covers

$ heroku run console

Wow! How cool is that! My goal now is to give up my own VPS for hosting my Rails apps. I’m thinking that it come out cheaper using Heroku.

Note: there are some limitations that you need to be aware of. For example you have limited write access to the file system so if you want your users to upload images then you need to incorporate different cloud offerings for this to work, like Amazon S3. The paperclip gem has support for this. This gives an insight in how your thinking has to change when you start to leverage cloud services and augment them together. Something to discuss further another time…

So you’ve written a Rails app and you want to show it off to your boss at work because you know that it will impress them. Problem is that your company only uses Java and won’t consider it for their production environment if it can’t be deployed under a JVM. Let’s go:

• Install JRuby
• Install the required gems for Ruby on Rails to work with JRuby

jgem install mongrel activerecord-jdbcsqlite3-adapter rails

• Install the gems particular to your application

jruby -S rake gems:install

• Update your database.yml file, prefixing your adapter with jdbc

development:
  adapter: jdbcsqlite3
  database: db/development.sqlite3
  pool: 5
  timeout: 5000

• Start your JVM

jruby script/server

• Demonstrate
• Sit back and wait for promotion
• Some notes on whats going on above:

Detailed installation instructions for JRuby can be found on their wiki.

The jruby -S rake command is very important as the -S switch ensures that the rake command is sourced from the JRuby home, not the system path which would contain a native Ruby install

ActiveRecord-JDBC can handle most any database you can think of in a corporate environment.

If you wish to use another database, there are some gems already pre-packaged, more details on the github page.