Went to NFJS recently. Awesome conference that I'd highly recommend you attend if you can, especially if you're into server side stuff though it was kind of nice to see the mobile additions here and there. The signal to noise ratio is always excellent. I actually used to present at the conference a loooong time ago (like, 10 years ago :). Anyways ...
Venkat should be a stand-up comedian in my opinion. He had a couple of really good talks. I especially liked his talk on features in jvm based languages (traits in scala, metaprogramming in groovy, etc) though he didn't talk much about my favorite JVM language - jython. He even mentioned tail call recursion which brought back some memories from the good ol college days :) There was an interesting side conversation on dynamic vs scripting languages but that's a never ending argument in my opinion.The concurrency talk on actor and STM based models was interesting. The Java memory model came up a few times during that talk.
As someone who has worked on both sides, the management talk was quite interesting and a bit of a refreshing change from the torrent of tech. The final shots of juice to the cortex were the sessions on Clojure and Datomic. It's always nice to brush up the state of affairs wrt lisp'y implementations.
Some other interesting items mentioned at the conference included:
I found an old writeup I had done for the deployment process I helped setup at a large health organization a few years ago. It worked really well for deploying an architecture consisting of apache/tomcat based multi-instance applications which integrated with multiple back-ends and provided a portal style interface to the end user. We were able to know exactly what version of what software was deployed in which environment and tomcat instance, when it was deployed and by whom and track it back to the source that was used to build it. We could also deploy at will anytime of the day due to the stateless architecture of the applications. All automated via Puppet (except for staging/production which was not fully baked when I moved on from the consulting gig).
Core Deploy specifies the model and process whereby a software artifact from a binary repository built by software developers is propagated through various environments in an automated fashion until it runs in production to meet the user requirements. Some of the benefits of this controlled process include:
Creating packaged build artifacts which can be deployed in various environments in an automated and repeatable fashion.
Creating a 'pipeline' for software development which includes steps such as quality assurance testing, performance testing, etc. The subsequent “Release Rhythm” section touches on this in more detail.
Providing some level of auditing to track software artifacts as they move between environments.
Initially, the software development organization has to agree on the environments that the artifacts progress through. This may consist of some of the following in order of progression:
Shared Dev – enables developers to test their built artifact to ensure that it will deploy correctly and integrate with any back-end services which they may have mocked out in their local development.
Shared QA – provides an environment for the Quality Assurance department to validate the software meets the functional requirements.
Performance – an environment to ensure that the software meets performance requirements.
Stage – basically production but which is not accessible to end users. Provides the ability to do final production validation of software artifacts before they run in production. This environment can also enable stateless automated deployments to production when paired with a load balancer.
Production – end users use the software from this environment.
Once the environments have been defined and the order of the progression of the built artifacts defined between them, the organization has to select tools to support the automated deployment of the artifacts between the environments.
Initial deployments will most likely be manual to help flesh out the deployment process. The manual steps can then be automated to provide as close to a push button experience as possible.
The deployment process specifies guidelines for who requests deployments for the environments above, how to request deployments, the notification process while the deployment occurs and some typical steps in a deployment.
Developers request deployments into the “Shared Dev” environment. Deployments to the “Shared QA” and “Performance” environments are requested by QA testers. Once software artifacts are tested and ready to be release into “Stage” and then “Production”, the Product Owner and/or the Project Manager request the deployment.
It is important to have a standard deployment request process in place. This can be something as simple as an email template or a file which contains the necessary information that needs to be filled out or something more sophisticated. Paired with archival software such as Source Code Management software, this mechanism can be used for auditing deployment requests.
A robust notification process is necessary to disseminate information as a deployment occurs. This will generally consist of emails which are sent out to the software development organization before, during and after the deployment to indicate progress. Note that this may result in a lot of emails so it would be beneficial to use filters or some other feature of email clients to archive them. The notification process should be incorporated into the deployment process in an automated fashion.
Sometimes deployments will fail for various reasons ( bugs, performance issues, unanticipated software interactions, etc). In such cases it is extremely important to have a rollback strategy which ensures that software is restored to the previous working version as soon as possible. This is extremely important if any issues are found in production, especially after some time.
This may consist of rolling back the application to a previous version and/or rolling back schema changes in a database. It could also involve a coordinated rollback if multiple services or applications have dependencies between them and need to updated or rolled back together.
Environment Configuration Changes
Most software applications have some mechanism to externalize configuration information. It is recommended that such configuration information be maintained in a Source Code Management system to enable auditing. Requests to modify configuration information should follow the same deployment process as updating application code. The configuration changes should be tested via existing automated test suites.
Been trying to get a handle on the iOS and Android versions of the OptionsHouse app. The first thing I always like to do is to look into automation for any kind of a project. It's useful for testing and just doing general lazy programmer type of things.
My first attempt was to use http://www.sikuli.org/ which is a general purpose image matching based test automation framework. It worked well enough with the simulators on Android and iOS but what I really wanted was to be able to run on the device.
So next on my list was http://appium.io/ which has really impressed me so far. I have it working with my Galaxy S3 and in the iOS simulator (fighting Apple's cert-provisioning-hoop-process atm) though it's been a learning curve and the still in development nature of the project coupled with the lack of docs is somewhat challenging.
I really ought to go to sleep .. but this is so much fun! =)
You may enjoy reading this presentation if you're into API design:
A good read and something I've experienced in some projects which sometimes need addressing:
We've got a great presentation lined up for the Seattle Java User's group on 5/21 at Expedia on Spring tech in case you are interested. Check out http://www.seajug.org for more details.
I had blogged about my awesome made for linux system76.com laptop a while back. But the support they have exhibited in providing detailed painless upgrade instructions to the latest version of ubuntu just reinforces my belief that they are one of the better choices if you're looking for a linux laptop. They seem to have upgraded some of their hardware choices too!
It appears that this year's TED conference is happening in my wife's hometown -Vancouver, BC. I'd highly recommend going to it if you can.
Some of the best talks from the conference:
heads up - http://linuxfestnorthwest.org/ is happening in April up in Bellingham in case you're interested. I've given some talks at previous ones on things like python, java and android. It's actually a great litle grassroots style weekend conference and makes for a nice road trip to scenic Whatcom county.
Used to be back in the day you cut your linux teeth by buying a desktop, dual booting ( or VM'ing later on) windows and working out all the kinks to get a lean mean linux machine setup. If you really wanted a challenge you bought something like a sony laptop ( totally proprietary hardware) and spent eons of time building custom kernels with the correct modules to get everything to work right. It was a very enlightening experience to say the least. Ah, to be young with lots of free time on my hands again :)
Anyways, since I don't have the time anymore and Linux is way more mainstream now I highly recommend buying laptops from https://www.system76.com/. I've been extremely please with my super duper all decked out box from them which runs an OS which can actually take full advantage of all that juice!
I've been a very long time Netflix user, especially streaming since I rarely get the luxury of watching movies on TV. Hollywood and other players make it a little difficult to watch netflix on Linux machines. Apparently they're more scared of the small minority who want to abuse the system rather than genuine end users.
So I run Windows XP within a VirtualBox VM ( those factory installs of Windows come in handy despite the fact you're forced to buy them). But running Windows XP was causing all kinds of audio twitching and the video would stop playing after a minute. Quite annoying.
Turns out all I had to do was to dedicate 1 CPU to it instead of the 2 that I had. Everything's been working fine after that.
I am working on a little project to setup a tool to index, x-ref and provide search to multiple source repositories running in the gigs and came to know of this awesome little server side java project which uses lucene under the hood called opengrok. I must say I am very very impressed with it so far. I am still in the process of setting it up but the search engine genes ( I worked on one in the early 2000s) and excitement for the potential are pretty cool!
I've been playing around with Android pretty much since the start ( almost got hired at TMobile a couple of years ago when I wrote a yelp app for the G1 while interviewing there - in retrospect, probably a good thing that I didn't end up there :). Luckily for the last few months it's been a day job and not just for weekend side projects.
The trajectory of this Linux based OS is nothing short of amazing: http://goo.gl/BlxQe
Some dev friendly links:
Really cool x-platform software kvm switch:
Remember to RTFM otherwise you'll waste time figuring out why the client cannot connect to the server :)
I've been planning a motorcycle trip with some folks for quite a few years now. The stars finally aligned and we were able to do it! Left Seattle for Surrey on friday, spent the night at my uncle's place and started out Sat morning. Dad had rented a Honda Shadow from CycleBC( highly recommended btw!), my uncle was on his Suzuki and I was on my Sportster custom. I think this was Dad's first motorcycle trip in the west. The last motorcyle he rode was probably his Royal Enfield back in the day in India. He started out carefully as he always does but by the end of the trip he was tilting the Honda like a pro on the curves coming down from Whistler.
The first stop was at Chilliwack for some yum yum Tim Hortons goodies :) Then onto Hope where we stopped for gas and some grub. The drive up from Hope to Lilllooet via the Fraser Canyon was really nice. Tunnels on the way, the river on the side and mountains all around. Lots of nice curvy roads. Spent the night at the Reynolds Hotel which was recommended by a young fella at Lytton while we were gassing up. Btw I would recommend Dina's place for food.
The next day we rode down to Whistler via Duffey Lake and Pemberton. A couple of hours and a really nice ride with lots of beautiful mountains all around. But I think the best ride was down from Whistler to Vancouver along the coast via the Sky to Sea highway. Simply gorgeous curves!
Finally back to Vancouver and Surrey via Richmond on Sunday evening. Then I headed out back for Seattle that evening itself making it back by around 11 pm. It was a really fun weekend motorcycle trip!
I am in the process of putting together a crack ( no, not the smoking variety :) team to work at the intersection of android, java & c/c++. If you or anyone you know is interested in working with me on a really cool project utilizing productive agile/xp techniques please contact me at nimret at nimret dot com.
Some key learnings from a past project utilizing puppet to do infrastructure management in case you're interested :)
- puppet's DSL is imperative and not procedural. This can be somewhat frustrating to folks who are used to procedural languages.
- It can be quite "interesting" to do loops though a later version of puppet does have the ability to write manifests in ruby.
- watch out for some puppet gotchas.
- use hiera for configuration management.
- buy a good book.