G'day! I'm Glen

Students in my Git Course raised an interesting and tricky challenge yesterday when we were working through the rebasing stuff:

“We accidently added a big file to our first (root) commit? And we’ve laid down a bunch more commits since. How do you rebase your root commit?”

What a great question! Normally you rebase the children of a particular commit. But what do you do when you want to rebase the very first commit? Messy.

flickr photo shared by derekbruff under a Creative Commons ( BY-NC ) license

Enter the –root

As covered in this Stack Overflow, all recent Git versions have a new --root switch to rebase for just such a scenario.

Aside from the magic --root switch, it’s a standard rebase operation:

• Change to master and git rebase -i --root to start an interactive rebase of root

• When prompted for the rebase order, set the first commit to edit as shown below

  edit 064a191 First commit with dodgy file
  pick 8a673aa Second commit with normal stuff

• The rebase will stop on the first commit which we’ve marked for edit, letting you git rm dodgy.mp4 to get rid of your file

• Once that’s done, run a git commmit --amend to update your message

• And then run a git rebase --continue to let the rebase complete normally

And you have yourself a nice clean root commit free from large mp4s!

Just writing it down so I can remind myself later!

Following on from my Git Hooks CI experiment, I thought I’d put my Digital Ocean Cloud VM to a little more work by checking out how to handle those shiny WebHooks that BitBucket provides.

What better way to do that than write your own WebHook endpoint from scratch!

What’s a WebHook?

A WebHook is just a fancy name for a URL that a service will invoke on a given event. When the event happens, the service will typically POST you a bunch of JSON about the event. All the A-list apps have WebHook support these days, including BitBucket and GitHub.

WebHooks are too cool for school.

Though, clearly, not as cool as Joe Bonamassa.

flickr photo shared by Dena Flows under a Creative Commons ( BY-NC-ND ) license

What do you get in the payload?

Glad you asked. Using my newfound passion for Yeoman, I generated a tiny express app to just listen and log a POST payload.

So what kinds of things do you get back from them? Tons of cool stuff…

For the longest time I’ve wanted to have a small VM in the cloud to experiment with random web-deployed stuff (mainly Node.js work). I’ve been using Azure for a lot of that, because it’s free with my MSDN subscription, but I’ll need a plan for when that expires.

I’ve been hearing a lot about the guys at Digital Ocean - they have some pretty great offerings starting at $5/month - and their support documentation is perfect for non-native Linux people like myself.

So now that I have my VM, I’m keen to automatically generate my staticly generated Hexo blog on each checkin to master. But what are my options?

I can think of a few options:

• Run some kind of CI server (maybe Jenkins?). Cool idea, but I only have 1Gb of RAM, so that’s not going to happen.
• Write my own WebHook endpoint that can be invoked via a BitBucket WebHook on checkin. Cool. But overkill for now.
• Keep another remote of my git repo on the vm, then write a Git Hook to generate the blog on push. Yeah. Just right!

Let’s do this!

flickr photo shared by CarbonNYC [in SF!] under a Creative Commons ( BY ) license

The magic Git post-receive hook

It’s easy to host a second git remote of my blog repo on the VM (just setup another remote via SSH), but then there’s the matter of finding the right git hook. In this case, the one I need is post-receive - which is the one that gets generated every time you push to the remote repo. Of course, you’ll have to edit the hook on the server. Bring on the vi kungfoo!

If you haven’t played with git hooks before, they live in your .git/hooks directory. Rename one of the samples in there to drop the .sample extension, and you’re good to play. The doco is kinda sketchy on these things, but the Atlassian coverage is pretty great. You’ll only find a subset of sample files in your hooks directory, but there’s plenty more events to choose from.

Alas. I have to face it. My design chops are terrible.

The design sensibilities of the A-list web apps these days are just amazing! They look beautiful. They animate and transition as smooth like butter. The colours. Oh.. The colours…And the icons.. Oh.. The icons..

I’m not sure if you’ve seen Dribbble.. but wow. There are some amazing designers out there doing some amazing work.

Add to that all the amazing stuff happening in mobile. And.. Well..

The bar is pretty high.

flickr photo shared by ch.weidinger under a Creative Commons ( BY-NC-ND ) license

Even for guys like me who spend most of our time developing enterprise apps that are often intranet hosted, the bar is getting higher. Clients are developing an appetite for beautiful and usable.. And so are we as developers! Which is awesome, but challenging for us guys who are more comfortable writing unit tests than working with HSL colour codes :-)

So what to do to keep pace? Here’s what I’m doing…

Option Now: Template your way to success!

My current commercial project is built around JSF2. I know people have a hate/hate relationship with JSF, and it’s not for everyone, but this year I’ve done productive work on Microsoft, Node.js and Java stacks, and the JSF stuff is just as productive to me as anything else.

How much am I loving Hexo right now? I’m actually blogging again!

Turns out that working with blog posts in plain text is just so much more convenient (and fun) than messing about with databases. And having Markdown preview built into VSCode is just even more to love! (but will leave my VSCode fan-bois-ism for another post - such a great editor)…

One thing I noticed in the Wordpress to Hexo migration was that a few of my Wordpress blog posts errored out in the conversion. This morning I had a dig to see what’s going on.

flickr photo shared by “Cowboy” Ben Alman under a Creative Commons ( BY-NC-ND ) license

First, this is the error you might end up with when converting from Wordpress:

FATAL Something's wrong. Maybe you can find the solution here: http://hexo.io/docs/troubleshooting.html
YAMLException: can not read a block mapping entry; a multiline key may not be an implicit key at line 2, column 5:
    date: 2010-07-02 22:54:00
        ^
    at generateError (C:\data\web\blog\node_modules\hexo\node_modules\js-yaml\lib\js-yaml\loader.js:160:10)
    at throwError (C:\data\web\blog\node_modules\hexo\node_modules\js-yaml\lib\js-yaml\loader.js:166:9)
    at readBlockMapping (C:\data\web\blog\node_modules\hexo\node_modules\js-yaml\lib\js-yaml\loader.js:1027:9)
    at composeNode (C:\data\web\blog\node_modules\hexo\node_modules\js-yaml\lib\js-yaml\loader.js:1315:12)
    at readDocument (C:\data\web\blog\node_modules\hexo\node_modules\js-yaml\lib\js-yaml\loader.js:1478:3)
    at loadDocuments (C:\data\web\blog\node_modules\hexo\node_modules\js-yaml\lib\js-yaml\loader.js:1538:5)
    at Object.load (C:\data\web\blog\node_modules\hexo\node_modules\js-yaml\lib\js-yaml
    ...

YAMLException? Block mapping entry? js-yaml?

Turns out this is because the Wordpress import into Hexo (well, the JS-YAML part, anyway), is not happy being fed quoted entries from your Wordpress exported XML. Finally found a forum post that discusses it.

In my case it was an item like this that was causing the issue:

<title>Netbeans and solving the dreaded "unrecognized project; missing plug-in?"</title>

If you’re in the business of producing blog posts, powerpoints, or other public media, the search for relevant and powerful images is probably on your mind. I’ve experimented with a few approaches to this, and have settled on something that works for me.

Whether you use Markdown, Wordpress, or just straight HTML, there is something in this for you.

The tool that makes this painless is the Flickr CC Attribution Helper. This is a fantastic little bookmarklet that turns all of Flickr’s redistributable content into an amazing source for blog images - and making attribution completely painless.

I’ve just had a pull request accepted to the repo to do Markdown generation (thanks Alan especially for the shout out), so it’s also perfect for Github and static blog generators! (I know, all HTML is valid Markdown, but thought it was a nice touch to add)

Life is Sharing shared by cogdogblog under a Creative Commons ( BY ) license

How do I use in in my image searching workflow?

First, head over to Flickr CC Attribution Helper and choose the type of attributed link you want to consume (there are options for Markdown, Wordpress, and straight HTML).

Second, once you’ve configured the type of link you want, drag the button at the bottom of that page into you browser toolbar.

Third, search within the Flickr Creative Commons Search for amazing images - that place is full of all kinds of awesome!

It’s been a while between drinks on the blogging front, but I’ve changed blogging engines. I’m sure that was all that was holding me back :-)

I’ve finally taken the plunge to move to a static site generator. Because I’m on a Node.js bender, I thought I’d move my toolchain to straight Node, and went with Hexo. It happily slurped in all my Wordpress content and converted it to straight Markdown.

The experience has been awesome!

So what’s with the static?

Glad you asked.

I’ve fallen in love with the Web.

Again.

flickr photo shared by tacker under a Creative Commons ( BY-ND ) license

I really want to level up my html/css/js skills, and perhaps explore some of the trendier Material Design aspects. So this somewhat plain template seemed like a nice blank canvas for my explorations.

Modifying site layout and styling – even in dramatic ways – is super easy with a static site generator. And when you’re done, just regenerate.

I’m just back from an amazing couple of days hanging out in Melbourne at Web Directions’ Code 15 Conference. Awesome selection of local and international speakers talking all things JavaScript & Front End Engineering.

Coming from the Java Enterprise Dev background, this isn’t my really home space, but I’m so pumped about what I’ve been experiencing in Node.js land that I had to go and check out what the thought leaders are doing in the Front End space. It was nothing like what I’d expected, but it was totally awesome! And I’m so jazzed about the future of the web!

Super diverse crowd, but all super pumped.

 

So, what’s the new black?

There was lots of talk about React. Lots. I had no idea it was collecting so much mind share of the cutting edge. But once you wrap your head around the benefit of a Virtual DOM, it became clear why so many people are pumped about it.

After watching Mark Dalgleish demo some of the things his team at Seek are doing, I was super impressed. A rich application, all with JavaScript turned off. Crazy good!

You should definitely go check out his presentation on the “Dawn of the Progressive Single Page App“. The possibilities of server-side React, augmented by client-side React, really are a new kind of Nirvana. No most waiting for a first impression.

 

React is the biggest upgrade to the DOM since jQuery. Talking about the future of the DOM without looking like a React fanatic is hard work.

— Mark Dalgleish (@markdalgleish) June 28, 2015

I gave my first Node.js talk last night at CanberraJS. I spoke about some of the tools I’ve been learning about, introduced the Thriftebook project where I test out my ideas,  and received heaps of ideas and inspiration on new JS stuff to explore (definitely going to look into ReactJS).

If you’re in Canberra, I highly recommend you come along to the next meeting (see the Meetup page for info). It’s worth it just to check out the Entry29 co-working space the group meets in - I didn’t know Canberra had such a space for Startup Entrepreneurs. Cool!

The slides won’t be very meaningful without the human, but they might give you an idea on the sorts of topics we were chatting about. It was a great night - thanks for the input and encouragement everyone!

 

Gulp is becoming a super important part of my toolchain, as is Azure and its funky Git deploys. Wouldn’t it be awesome if you could run a Gulp job during Azure’s git autodeploy? Say, to pull down all your Bower deps and run a few transformations on your index.html? Well you can, and it’s a snack to setup!

Installing Azure NPM tools

First of all, you’ll need to install the azure npm tools. You’ll really only use this tool for generating the default deployment script (which we’re going to tweak). Let’s just install it globally

npm install azure-cli -g

With the tools install, next step it to generate a default.cmd:

azure site deploymentscript –-node ./

Note: I needed to add an explicit path to the end of the line for this command to work on windows - otherwise I would get the help message. YMMV.

You should now see a Deploy.cmd file generated in your working directory (and a .deployment file that references it).

© 2009 section215, Flickr | CC-BY | via Wylio

Customising your Deploy.cmd

Azure WebJobs totally rock! Think: “Cron jobs for the cloud”. You can write them to launch on demand, or schedule them as one-off or recurring jobs. Better yet, you can write them in a bunch of the supported languages - one of which is Node.js!

I’ve been working on a rebooting a little app I wrote years ago called Thriftebook, which aggregates publishers “Deal of the Day” stuff, but this time in Node.js and Angular (repo here). It’s pretty scratchy at the moment, but worth a look to get the idea. Well, the heart of an aggregator is a regularly polling job to go out and look for fresh data. Enter the Azure WebJob!

© 2010 Florin Gorgan, Flickr | CC-BY-SA | via Wylio

 

Packaging Up Your Node.js WebJob

The Node.js support for Azure WebJobs is first class - including support for npm dependencies. Just zip up your *.js files, with your root js file containing the code to run on schedule, and you’re done. I know very little about gulp, but decided it was probably worth putting together a gulp task to create my  little feedFetcher.zip for WebJob uploading:

https://gist.github.com/glenasmith/fcfe171dc79b5ad87de5

If I knew a bit more about Azure, I would probably launch a Powershell script to deploy the Webjob directly from gulp, but that’s for down the track.

Note that these days you don’t need to zip up your node_modules directory - you’ll get that stuff for free from package.json - which means your deployed zip will be nice and tiny.

Using the Right Portal

As my Node.js obsession continues, I’ve been on the hunt for home hobby projects that explore areas which don’t current have an application in my daytime consulting work.

Last week I spent a bunch of time exploring CouchDB.

© 2014 Toms Baugis, Flickr | CC-BY | via Wylio

 

What’s to love about CouchDB?

If you haven’t had reason to play with CouchDB before, you should definitely put it on your “experiment” list. There is plenty of amazing packed into this Db , and it doesn’t seem to get the profile of Mongo or Cassandra.

So what have I enjoyed in the first experience of working with Couch? I’m still a noob, but first impressions are..

• Couch really gets the web. All of its API happens via standard JSON over RESTful endpoint, and so it’s a pleasure to work with from Node. Just need to throw some JSON around and store it? Couch is outstanding. You don’t need any special client, just install a copy of Postman and start tinkering.
• A great Node.js client lib (if you want it). Whilst you could happily just use request.js to interact with Couch if you want to go bare metal, there’s also a wonderful Node.js client library called nano which wraps the basics without getting in the way.
• Excellent web admin console. The Futon web admin tool that comes with Couch is a great to quickstart. Need to experiment with map/reduce scripts? It’s got your back. Keen to replicate a remote Couch db? Yup, that’s straight from the Web UI too. Even bundles a full copy of the manuals for offline work! Nicely done.
• Great manual. Speaking of manuals, the ones that ships with Couch is excellent. Seems to be basically the O’Reilly CouchDB book in manual form. Really good coverage and example.
• Replication is first class. Couch has a great multi-master setup where you can easily replication things between instances. Perfect for tinkering on your dev box, then pushing changes to the cloud.
• Versioning is built in. You update documents by providing a new version of the existing document. The replication model is all constructed around reconciling those versions, and it all works very sweetly.
  That sounds like a pretty glowing first impression? True. But there were a few hairy bits that put me off, though..

© 2008 Mark Walz, Flickr | CC-BY | via Wylio

What I’d need to grow to love?

I’ve been on a JavaScript/TypeScript bender of late, and I’m really having a ball! It’s not really like either Java-land or .Net-land. It’s a whole new stack to learn (Gulp.js, node.js, Express.js, Mongodb, Angular.js, Mocha.js, Chai.js, wowsers! Not in Enterprise Kansas any more!).

I’m new to the whole space, so I don’t have an even basic set of patterns to draw on yet. So I figured I’d outsource that expertise to a decent framework, and see how I went. Enter Sails.js.

(https://farm8.staticflickr.com/7626/16912357032_90e77236ef_z.jpg)](https://www.flickr.com/photos/weyes/16912357032/) © 2015 Alessandro Caproni, Flickr | CC-BY | via Wylio

So.. how much JS do you need to know?

So, let’s be clear, my JavaScript experience it pretty rudimentary. I’ve written some very basic Angular.js SPA stuff, done lots of jQuery, and had a look at a few “intro to Node.js/Express.js” type courses on Pluralsight.

So how was the Sails.js experience for a Node newbie? Excellent. Just excellent. To be fair, I’ve done a lot of Grails work in my time, so all the Railsy stuff in Sails.js made perfect sense. In fact all the same view/model/controller/routing conventions are in there - just with a bit of JS-centric flavour. It even had dynamic finders!

I started working off a basic template Angular.js/Twitter bootstrap sample client app, created a basic Sails.js template on the backend, and I had RESTful CRUD stuff happening on the first day - due to Sails.js awesome RESTful Blueprints (think scaffolding). There’s the standard route config stuff you’re already sorta used to, and an integrated build setup that’s turnkey. All super familiar to the Grails guy. The early docs are good too.

And how productive were you?

The app was a basic RESTful testing endpoint with some augmented custom actions, supporting by an Admin SPA UI that let you configure and inspect things stored in a MongoDb backend.  I probably spend four days on the app Soup-to-Nuts, and had a basic Angular.js SPA, served up by some fancy RESTful services that interacted with our real domain system.

It was a very productive experience. Considering I hadn’t used Sails.js, Node or MongoDb in serious anger, it was pretty awesome. All the conventions made it seem nice and familiar - even if this isn’t homeland territory for an enterprise guy.

Ok. While I wasn’t looking, some of you people went and….

Made. JavaScript. Awesome.

It used be like this…

(https://farm5.staticflickr.com/4054/4439062727_52444dd185_z.jpg)](https://www.wylio.com/credits/flickr/4439062727/) © 2010 alikins, Flickr | CC-BY | via Wylio

 

That was two years ago - the last time I was doing hardcore JavaScript as part of a commercial product. Back then I was doing tons of jQuery, jQuery-UI, Backbone.js, qUnit, and was just starting transition to shiny new AngularJS. Then I got sidetracked by some other work.

In the meantime, I’ve been doing tons of JSF/Primefaces, and more recently, lots of Microsoft Tech (including Azure). But since getting crazy-excited about TypeScript, I’ve put more and more JS-related technologies on my learning plan for the year. And boy is there lots to learn!

So what’s changed in two years?

Well.. Everything! The entire landscape has moved. There are now mature build tools, mature package management infrastructure, great bootstrapping tools, some very cool Model-View-Whatever frameworks. Boy, even the IDE tooling has come forward in leaps and bounds (presently playing with Webstorm and really enjoying it). And don’t get me started on how awesome cloud hosting is!

 

I’m not a JavaScript hater. Really. But I just haven’t really found a lot of connection with the language. Maybe because idiomatic JavaScript (at scale) is a long way from the Kansas of strongly type Java/C# that I’m used to. It’s even a fair way from idiomatic Groovy.

Whatever the case, after having worked on a few medium-sized JavaScript projects (10k+ JS LOC), I find myself getting into a pretty negative headspace whenever I end up writing JavaScript. Maybe partly because I haven’t made the leap to Functional. Maybe partly because the whole toolchain is a re-invent. But whatever the reason, JavaScript never found a place on my Christmas Card list.

But I actually think that’s about to change because…

Yup. TypeScript. If JavaScript was written by someone with a Java/C# background, it would look like TypeScript.

A strongly-typed JavaScript with all the features that modern Java/C# devs are used to: strong types, modules, interfaces, classes, inheritance, access modifiers, generics, lambdas, mixins. Totally. Sold.

Best of all, it compiles down to relatively idiomatic ES5 (and even ES3 with some caveats - so you can run it on the XP/IE7 setup that your enterprise clients have :-( ).

And all JavaScript is valid TypeScript - so you’re not sacrificing anything.

And it runs just great on Windows, Mac, Linux with tooling support in all the popular IDEs, editors, and build tools. What’s not to love?

It’s ECMAScript 6, Today!

I’ve just finished reading a cracker of a little book called The Checklist Manifesto (about $5 on Kindle).

Super interesting read about how a surgeon worked with the WHO to dramatically decreased post-operative complications and fatalities. The answer: a checklist!

I know what you’re thinking…

“Fine for noobs, useless for senior devs.”

And that’s the thing…

In their early observations that found experienced surgeons skipped a basic step of their normal mental checklist often. Often.

So people smarter than you who do these operations every day often skip basic steps that lead to people dying or having major complications. That’s a sobering thought! Your stakes are much lower. I wonder what are you skipping?

Key Idea: Checklists are not for noobs. They are for people who care about consistent, reproducible awesomeness.
 

(https://farm1.staticflickr.com/190/443737978_83a41823e2_z.jpg)](https://www.wylio.com/credits/flickr/443737978/) © 2007 Jeff Kubina, Flickr | CC-BY-SA | via Wylio

 

Gosh, I had a great year in 2014! Aside from shipping the wonderfully-improved second edition of Grails In Action, I exited two companies, developed and launched a completely rewritten Git Quickstart course into the Aussie market, hacked some really fun JSF and .Net apps for clients, and started building some awesome minihabits into my life.

One of my journeys last year was into accelerated learning techniques, and I stumbled across a really important idea that is probably old news for some, but was totally new to me:

You have a learning style - a preferred way of taking in new concepts! When you find out what it is, you will learn more efficiently, and retain it more effectively.
According to Wikipedia, the whole field of learning styles is pretty unsubstantiated - “although there is ample evidence that individuals express preferences for how they prefer to receive information”. On that train, I’ve found Neil Fleming’s VARK  (Visual, Auditory, Reading/Writing, Kinesthetic) model stuff super helpful. Here’s why…

Why learning style matters..

When you optimise to your preferred learning method, you can retain tons more. Tons.
My previous learning methods centred mostly around reading tech books. eBooks mostly. But I’ve found that eBooks haven’t been all that efficient for me.

Good for reference, for sure, but how many times have you read a entire book only to discover you’ve only retained a tiny fraction of what they covered?

 

(https://farm5.staticflickr.com/4106/4984567320_a04af76c77_z.jpg)](https://www.wylio.com/credits/flickr/4984567320/) © 2010 Sean MacEntee, Flickr | CC-BY | via Wylio

So how do you determine your learning style?

Here’s where things get a little meta. You have to start working out how you like to learn, and what kinds of learning have been most efficient for you and your brain. You can do a questionnaire if you’re stuck. But you’re a software developer, so you get meta more easily than most. Have a think, and work out how you best learn!

This post continues from Part I and Part II in assimilating a few insights that I have collected from running Git Training in Canberra, Australia. Depending on your students, and courseware, YMMV.

Insight #5: Run your training in a team context

If you’re getting into Git, you’re probably already into team in a big way. So why not teach git in the context of team?

We moved a lot of our exercises in our last course into “collaborative mode” - where you work through examples with the person next to you. Need to do a tricky merge? Why not create a tricky merge situation for the person beside you, then swap seats. Not only do you get the benefit of easily accessible peer support, you adopt a team mindset from the get go (and learn why it’s bad form to setup tricky merges for your colleagues).

Building team into every aspect of the course is a great way to install not only the tools but also the culture of Git.

The last exercise for the course is a major exam which incorporates all the essentials of a software release process with Git. Doing it as a team really makes it feel that you’re in a real-world scenario.

Insight #6: Timebox your exercises

I did my first lot of Agile training with Rowan Bunning (a Scrum Guru in these parts). One of the thing I loved about Rowan’s training style was how he timeboxed everything. We’ve taken a leaf out of his book and things work better in the classroom.

Don’t just set an exercise, set a timeboxed exercise! Again, adds a level of real-worldness to things since most orgs operate in some kind of timeboxed Agile manner these days.

This post continues a series (part 1) looking at some things I’ve learned running Git training in Canberra, Australia. YMMV in your own cultural and technical contexts :-)

Insight #3 - The GUI is nothing to be feared

Some guys I know are really “thingy” about not using a GUI for anything when showing Git to their team. I get that… and it’s a good idea to not start there… for a while. Our course is two days, and for 80% of the first day it’s all commandline and index cards. By that stage you are grokking the DAG deeply,  and at that point, it’s time to get productive by introducing a GUI.

At the end of Day One, we do a “Follow the Leader” exercise using SourceTree to perform everything they’ve learned so far in the day from the commandline. Then we unleash them on a tricky review exercise on their lonesome. Doing all that stuff visually in a GUI is a huge visual consolidation of the day’s learning - and a powerful demonstration of how much faster working with a Git Gui can be (but only when you know what you’re doing).

Don’t fear the GUI. If you’re not using one professionally, it’s worth revisiting to see what modern tools can do. There is nothing in my regular Git workflow that Sourcetree can’t do - and that includes interactive rebasing, amended commits, rebased pulls, annoted tags, stashing, multiple upstreams, branching, merging and resolving conflicts. All that stuff is there, and it’s all super productive. If someone told you GUIs were for noobs, the world has changed, and you’re missing out.

Insight #4 - Team Context is Super Important

We spent plenty of time on Day 2 talking through workflow models with Git. This is something we hadn’t done enough of in our early courses, and this time we set it right. We talk about how the students currently do their release flow (in whatever revision control they use), and we talk about their aspirations and pain points for release management.

We also talk about the reality of release constraints in enterprise shops (Canberra, as Australia’s capital, is a big Government town!)

We then break out the index cards and work through:

We’ve just hosted our freshly minted two-day Git course in Canberra, Australia (which was a major overhaul of a one-day Git course we’re run several times). I’ve learned so much from running these courses - and I thought I’d jot down a few things we’ve discovered teaching git that might be helpful when you’re working with colleagues and other git students.

Insight #1 - It’s all about the DAG

It’s understandable that most Git training centres you on the PC doing git commands. But we’ve found that’s been inefficient for us. Using Git productively relies on your have a solid mental model of how it works - and with Git, how it works is all about Directed Acyclic Graphs (DAGs).

The Think Like A Git site takes this DAG-centric way of teaching, and we’ve adopted that pretty hard. We even adapted one of their teaching tools, The Seven Bridges of Königsberg, as a group activity. This is a great tool for helping people get the idea that there are only “Places to go, and ways to get there”. If you nail that idea, a lot of the hard work is done.

Once they have a little bit of an idea about Git as a directed graph, it’s still not time to get near a PC.

Insight #2 - Going Tactile: The Computer is not always your friend

We’ve found that PCs can actually create clutter in understanding what is happening in the early stages.

I’ve been spending a lot of time with Sharon Bowman’s book Training from the Back of the room (if you develop courseware, or give training, just go buy it. It’s gold). I’ve learned a lot about getting creative with training exercises, and about doing a lot less talking, so for this course, before we do any Git exercise on the PC, we do it on Index cards. Together. As a team.

If you look at the picture below.. Yes, that’s moving commits from the working directory, through staging, and into the repo.

Never let it be said that I don’t swim against the stream…

Just as the latest IDC numbers show Android eating up the Mobile Smartphone market, with even Apple numbers slipping, and Microsoft 3rd by a long, long margin…. I decide to take a sojourn into Windows Phone for a while. What could I be thinking?

A few things actually. The first is that I’m presently engaged on doing a consulting gig where I’m constantly switching between JEE (my heartland) and Dotnet. After drinking deep of the MS dev stack on Windows, I was pretty impressed. Embracing MVVM as a UI pattern, and adding a super slick design tool like Blend turns out to be pretty darn productive - even for an Enterprise Java guy!

I’ve come to really love this “other” enterprise platform. In particular I’ve come to love C# as a language. First level support for properties and events is absolutely game changing. And having a unified UI markup language (XAML) that works across PCs and mobile is, well, just awesome. All platforms with deep support for data binding always impress me (looking at you Grails and Angular).

So I figured I’d buy the cheapest Windows phone I could find, take the SIM out of my Samsung Galaxy S4, and see how the Winphone platform is tracking.

 

 

I

“How do you drown a hipster?”… “In the mainstream” .. or so the Dad joke goes..

Well, these days, I have to be counted among the uncoolest programmers on the planet. Aside from the odd bit of Grails consulting work, and a few training ops, my current gigs have me moving between webapps apps written in JEE6 with JSF2/JPA and rich client apps written in C# with WPF/XAML.

These, my friends, are not the calling card of the hipster developer. They are, separately and together, some of the uncoolest stacks in the enterprise. But I consult in a Government town, integrating with some very disperate systems, so such mainstream-ness is to be expected.

And here’s the weirdness of this season of tremedous uncool-ness….

I’m currently enjoying programming more than I ever have!

And for the gold star, I think I’ve actually worked out why. In both environments (JSF2 and WPF), I’m working exclusively in components. Proper components - with properties, events, listeners and the like. This abstraction is gamechangingly productive for me! I think they call this encapsulation. You know, loose coupling, strong cohesion and all that. Why did I miss this component thing when it was all the rage? (though to be fair I did program VB for a while in the 90s… but that wasn’t quite the same!).

Primefaces is an astoundingly good JSF library, and WPF/XAML, whilst having quite the learning curve, is insanely flexible for rich client anything. The engineering backing both is first class. I’m certainly not leaving Grails behind, especially since the paint is still drying on the book.

So for the next season,my life is all about components and, for now, I’m loving every second.

Anyone else doing component stuff these days? Now where was that Bon Jovi cassette…

I’ve recently been doing a fair bit of Selenide for web functional testing at work, and have found it a lot more accessible than raw Selenium. I’d been looking for an opportunity to share my experiences when along came a “Lightning Talk” night at our local Canberra Java User Group.

Peter McNeil put together a fantastic night of talks, and the sponsorship team of Redhat, Nerderg and Peoplebank put up some absolutely fantastic prizes (I walked away with a $100 gift voucher for third place!).

Anyways, I did a quick five minute screen recording on the night to give you a very rushed live coding session showing you the basics of getting a Selenide test up and running. Selenide is a fantastic piece of engineering and an incredible time saver in getting Java functional testing happening in your workplace. Awesome work guys!

If you’d like to grab the source code, it’s all up on github. Enjoy!

I really love JPA’s EntityListeners feature - a really lightweight way of doing AOP, but without all the bytecode shenanigans at compiletime.  But under EE6 there are a few gotchas - and one of the big ones is that these EntityListeners are not subject to CDI injection. Eeek!

So what do you when you want to get a handle to a CDI Bean? Or what about if you want to raise a CDI Event?

The answer to all your questions is the humble BeanManager. This cheery fellow gives you ways of firing events, grabbing handles to Beans (or creating them), and doing other CDI magic. But chicken and egg time: how to inject the BeanManager without CDI? Well, while you can’t inject it into an EntityListener via CDI, you can actually look it up through your ancient friend JNDI. Behold the magic of Stack Overflow:

public static BeanManager getBeanManager() {
    try {
        InitialContext initialContext = new InitialContext();
        return (BeanManager) initialContext.lookup("java:comp/BeanManager");
    } catch (NamingException e) {
        log.error("Error in EntityListener resolution of Bean Manager", e);
        throw new IllegalStateException(e);
    }
}

And once you have yourself a BeanManager, you have the trivial job of raising your events for which the BeanManager’s [fireEvent](http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/spi/BeanManager.html#fireEvent(java.lang.Object, java.lang.annotation.Annotation…)) method will work nicely:

@PrePersist
void onCreate(Object object) {
    getBeanManager().fireEvent(new AuditEvent("create", object));
    // your other secret sauce..
}

And all your other CDI Event Observers will work as you expected. Simple, yet profound.

Go forth and raise events from your Listeners!