Technology Radar Group Rebooted

Last night the Technology Radar Group "rebooted." It had been many months without meeting, due to having lost a sponsoring location to meet! Luckily, iRise was gracious enough to take it over, and the first meeting at their location had a number of developers, who stayed late to catch the Meetup.

TheHackerCIO gave a tutorial on using the javascript software to produce your own Radar. The graphic isn't the most important part of a Technology Radar, but it's fun, nice, and easy enough to do.

The side-bar conversations, as is often the case, were very interesting. One of them centered around the accelerating pace of technology change. Notice I didn't say speed. The speed of change has been felt for some time. But now, it seems like I'm actually aware of the acceleration of change, which is to say, the 2nd derivative of change!

As merely one illustration of this, take the tutorial itself. I knew there was software out there to produce Radars. I knew it from reading the post by Neil Ford, called Build Your Own Technology Radar. In it, he mentions this:

Brett Dargan, one of my former colleagues, created (and open sourced) the code to create the radar visualization using JSON and JavaScript at https://github.com/bdargan/techradar.

I played with this a bit a year or so ago, so as I started preparing the tutorial/presentation, I naturally went to Github, to clone the software.

I was in for a surprise. I went to Gihub and searched on "technology radar." I did find the repo I wanted, written by Brett Dargan. But I also found 19 others! So what do you do? Go ahead and build the tutorial/presentation around the one you knew, or stop and spend an hour or two reading/learning/evaluating to determine which one is the best/easiest, and *then* spend an hour or two playing with that one to get a tutorial together? And, then, possibly, find out you got stuck and/or there was an issue with using it, and have to spend another hour or two falling-back to the first option? What if you don't *have* a presentation by the deadline? I took the easy way out and stuck to the one I had played with before.

As we experience the velocity of change, the acceleration of change, and possibly even the "jerk" of change, we need to balance conservatism against challenge. Otherwise we're going to get left behind. Everyone in technology is feeling this acutely, these days.

I Remain,

TheHackerCIO

Cassandra Last Night at the TRG

Cassandra was the topic at TRG last night.

That is to say, Apache Cassandra. I'm not clear why the project chose to refer to themselves by the name of a Greek prophetess who was doomed to always prophesying correctly, but also to never being believed.

Perhaps the the eventual consistency model?

Still, it doesn't seem like the greatest PR approach and it doesn't seem like the Big Data initiatives would like to think of their correct insights always being disregarded.

But such is the name of the product.

Our presenter, Adrian Rodriguez, did a nice hands-on tutorial where he built up a data model for a Social web application centered around dog photos. He provided a github account where the full blown application can be browsed.

He also pointed us to a very helpful consistency calculator website, where the implications of your consistency level choice are clearly shown: Cassandra Parameters for Dummies.

Adrian recommended the very sound policy of defining calls in quorum and then relaxing this only where necessary, in keeping with the dictum: "don't prematurely optimize."

I also liked his way of explaining that Cassandra databases grow out left to right, with everything attaching to the primary key as a new column, and with all the join overhead done upfront at update time in all the other relevant rows; in contrast to the Relational Model, where databases grow top to bottom as new rows are added. This is an excellent way for beginners to start wrapping their heads around this NoSql database.

Tonight is the Java Users group, so a report will be in order tomorrow on Groovy.

Full details of the presentation may be read here.

I Remain,

TheHackerCIO

The Half-Hour, High-Availability Cluster!

Last nights Technology Radar Group tutorial was awesome! Kevin Epstein guided us through the live process of spinning up a load balanced HA cluster with an elastic growth of between 2 and 10 instances. He began with a slide presentation classifying all the many products that make up the Amazon Web Services constellation of products. Then, he used the AWS Console to create a base instance with a MySql database and quickly set up a WordPress blog. An awesome blog, that the whole world will want to view, which will result in performance problems for the server!!! Well, OK, you have to use your imagination for that part, but he did set up a basic blog page and displayed the IP of the underlying instance, so we could verify what was going on in the demo.

One particularly interesting twist was his use of Route53 for a simple failover mechanism. He configured this so that it was checking for the health of the server, which in the beginning, had not yet been created! Since non-existence is kind of a "bad health" state, the Route53 failed over to an S3 bucket, and displayed some static content. Once he started the instance, this  no longer failed over and the static content was no longer displayed, since the actual blog replaced it.

Next on the menu was replacing the database embedded in the instance with a Amazon Services database -- that is to say, an RDS service. He used the same MySql database engine for this, and used MySql utilities to dump the data to a flat file and then import it into what was now a clustered, backed-up database!

After the break he configured an ELB and an autoscaling group.  His comments throughout this presentation were most helpful. For instance, he commented on the phenomenon of "flapping," where  the failure heartbeat is set to too short a period. In such cases, one can produce a worse outcome than the brief outage that comes from failover, by repeatedly failing over, and failing back, with the user still experiencing a repeated loss of transactional state.

He also, most helpfully, pointed out that in creating the "Gold Image" instance, from which the cluster would be initiated, you NEVER want to choose the "No Reboot" option! In the normal case, you want to ensure a consistent state on the image you are copying, so it has to be an unbelievably weird scenario where you would want to save the tiny bit of time possible by taking a snapshot without a reboot first. If anyone knows such a scenario, please send it on in, so we can take note of that rare, exceptional condition. In the meantime just leave that checkbox alone!

The cluster he defined was a "Multi-AZ" or Multi-Availability Zone cluster, which in AWS terms is an High Availability cluster. He noted that this was one area where the AWS console was insufficient, and the one had to resort to either the command line, or use a third party tool. The tool he preferred was called ElasticWolf. But there was some kind of issue in seeing the instances and we were under time pressure, so he resorted to using ezautoscaling, which is another third-party tool, and a good one, but one that charges.

I like complex live presentations precisely because they often run into problems: you get to see a problem arise, and a work-around employed! That's invaluable experience, and to get it vicariously is a tremendous boost  -- it gives a beginner some inkling of how to work/struggle with a new product. And what do we do every day, but struggle with technology? Nothing comes easy in the tech world!

For anyone interested, I highly recommend the Los Angeles AWS Users Group, which joined together with the Technology Radar Group us for this tutorial presentation. We are also very lucky to have Eric Hammond's blog Alestic. Eric is a member, and regular attender at the AWS Users Group. If you haven't read Eric's blog, you're missing out! And special thanks go to Kevin Epstein for a masterful presentation. One commenter claimed this was our best Meetup presentation yet, and I agree with him!

Presentation Slides
Screencast of Tutorial (Will be provided a link here, when available)

Technology Radar Group Tonight!

Tonight at 7pm, will be the third meeting of the Technology Radar Group Meetup. We're anticipating over 30 attendees -- pretty good for a Meetup only a few months old!

Tonight will focus on Amazon Web Services. It will be a showcase/tutorial on how to spin up a load balanced server using ELB.

This is really just an announcement blogging -- if you're local to LA, please drop by. We'd love to have you, and it promises to be an exciting session. If you can't make it, we're attempting ... (no promises) ... attempting, that is, to get a screencast to post on the Web.

Details, and the signup for further announcements may be found here:

http://www.meetup.com/Technology-Radar-Group/

I Remain, Faithfully,

TheHackerCIO

Lightening the Load Testing

Load Testing was the topic at this morning's Los Angeles CTO Forum. Two presenters showed the goods. Apica has their own proprietary tool, which they demonstrated. I thought it was way cool when they picked up nodes to run their server off balloons on a World Map! The tests are then run off these nodes, using their rackspace datacenters. Apica are partners with Rackspace, so they can come in on your project if your using them for your cloud.

The other presenter was Andrew Cholakian, a local hacker who also likes Clojure and wrote his product in it. His product is Engulf and you can spin up AWS AMIs as nodes to run your loadtests.

Finally, I spent a few minutes plugging the Technology Radar Group. It's a key tool for keeping up with the dizzying pace of technology. TheHackerCIO is far too busy to do without the Technology Radar Group! Between that and Hackathons, they are crucial for keeping current. Slides are here.

Where is Your Technology Radar

Today TheHackerCIO is preparing presentations. Tomorrow he'll present on "Your Technology Radar" to a gathering of Chief Technology Officers in Silicon Beach, held monthly at Clearstone Venture Parners. If you're a CTO in the greater LA area, the LA CTO Forum is a great place to learn from colleagues and to get advice about problems or pointers to resources.

Technology Radars are an important tool to keep up with Tech. Invented by Martin Fowler of ThoughtWorks, they are produced twice a year. Lots of developers I work with await the latest Radar release with considerable anticipation. Our local Los Angeles Java Users Group has a weekly book club / study group, which sometimes spends a session discussing Radar items.

The idea, in essence, is to take inventory of all of the emerging technology that the consultants are seeing and getting interested in as part of their field work and recreational work. :-) Then the list is reviewed by the participants and assigned to one of 4 quadrants on a circular graphical display:

• Techniques
• Platforms
• Tools
• Languages & Frameworks

A circular graphic lends itself naturally to the notion of a Bulls-Eye. Accordingly, the outer ring represents an assessment of "hold", and successive inner rings progressively become more positive, ranging from 

• Assess
• Trial
• Adopt

The Bulls-Eye, therefore, consists of those Techniques, Platforms, Tools, Languages, & Frameworks that should be adopted. A further graphical device is used for each "blip" on the Radar screen, to show change by placing a triangle around those "blips" that have changed since the last issued Radar. A circle, by contrast means the item has remained at the same level. To put it all together take a look at an example of one quadrant of a Radar:

And spend some time reading the May 2013 Technology Radar from ThoughtWorks.

The real point is, you shouldn't be depending on ThoughtWorks Technology Radar. Where is your own personal Radar? You need to be the one actively driving this process of systematic evaluation. To read more about this, read this article and, if you're in LA, join the Technology Radar Group and start working on your own Radar. 

Coding Play Makes it Fun

Coding is always fun and sometimes play. But "Play" is also a framework. It's a fun framework, so Alexandros Bantis demonstrated at last nights Technology Radar Group Meetup.  His hands-on tutorial on the Play Framework and it's Akka messaging infrastructure, was delivered as a GitHub Repo of code demonstrating the use of Play both in Java and Scala.

Theoretical points of interest were how "Actors," "Futures," and "Promises" make life easier for the developer.  The Actors are implemented by a messaging infrastructure -- I gather that this is built into Play, via the Akka package, which is incorporated into Play. Play is a bundle of lots of cool technology into a bundled rapid-development stack. I particularly liked the way Play uses Websockets to monitor the code and incrementally compile it as needed, so that the hacker doesn't need to reboot a server (as with Tomcat, in the bad old days) in order to see his new code changes at work. Just a refresh of the browser and you can see what you have done -- whether it be good, or ill .... :-) In the modern code development world, jRebel is getting built in out of the box!!! And that's a good thing.

Another extremely cool point was how in Play even your HTML get's bound up with Static typecasting. So you can catch all the nasty errors up front even though you're developing client-side display. I'm not quite sure how it works in Java, but in Scala the type of the parameters to be passed seems be combined into a function. And if you pass a faulty type as an argument, low and behold, the browser reveals your type-error.

Finally, the evening was rounded out by a presentation of TechStacker by Rick Parker. A Heroku hosted tool written by a friend, this handy little site is a first stab at creating a crowd-sourced tool for the evaluation of software products. Rick is already using it to do his own evaluations, which are part of his day-job, and I'm certainly going to start putting in materials and experimenting with how Social Networks can be part of software evaluation. I might even go do the Play framework as my first eval on TechStacker! If you want to join in on this, please join in and sign up at http://tech-stacker-staging.herokuapp.com/dashboard

By the way, please don't complain to me about the TechStacker UI. Rick admitted that it's the worst imaginable. But hey, we'er geeks. We'd rather have a command line anyway, right? Who needs GUI?

Thanks to everyone for making the evening enjoyable as well as enlightening.

I remain faithfully,

TheHackerCIO