Earlier today, I posted some considerations on readify.net for those people who work in Microsoft-centric organisations.
Fortunately or unfortunately, Git won over Mercurial. I placed a few bets on Mercurial at the time, so I have a bit of a tail of repositories left to convert.
Converting on Windows with full fidelity isn’t really possible. None of the scripts work well, and the case insensitive file system can cause issues. Luckily, Windows Azure makes it super easy to borrow a small Linux instance quickly.
I’ve documented what I do in this post. Anybody with a web browser can follow these steps, on any platform. There looks like a lot of steps, but that’s just because I’m spelling out every last detail for clarity.
Create a Linux VM in Windows Azure
- Sign in to https://manage.windowsazure.com
- Create a new VM from the gallery:
- Choose an Ubuntu release. As of this post, I chose Ubuntu Server 13.10.
- Name the VM anything you want
- Untick “Upload compatible SSH key for authentication”, unless you know what you’re doing there
- Tick “Provide a password”
- Leave all the rest of the defaults, and just keep clicking Next
- Wait a moment for the VM to get provisioned
Connect to the VM
For this, we’ll just be connecting to a command line via SSH: no GUIs will be harmed.
Because SSH is so prevalent, there are tool chains available for every platform. I’m actually writing this post on my Surface RT (not Pro), using an app called SSH-RT from the Windows Store.
- Connect to the DNS name for your new VM (mine was
- Use the username and password you established during the wizard
- You should now be at a command line like
Install Git and Hg on the VM
Ubuntu doesn’t ship with Git or Mercurial installed by default, but it does have an awesome package manager called apt-get.
sudo apt-get install git
sudo apt-get install mercurial
sudo prefix is a command to elevate your permissions, kind of like a UAC prompt on Windows.
hg-fast-export on to the VM
We’ll be using a tool called
hg-fast-export to convert the Mercurial repository to Git, without having to replay each individual changeset like some tools do. This tool is in a Git repo, so we’ll just clone that repository down in order to get it onto the VM.
git clone https://github.com/frej/fast-export.git
Clone your Mercurial repository on to the VM
For the sake of simplicity, we’re just going to use HTTPS instead of SSH.
hg clone https://your/hg/repo/address
Export your Mercurial repository to a new Git one
- Create a new folder for your Git repository:
- Change to that folder:
- Initialize an empty Git repository there:
- Do the fast export:
../fast-export/hg-fast-export.sh -r ../your-repo/
Upload your Git repository to your Git hosting
- Add the remote:
git remote add origin https://your/git/repo/address
- Push up all branches and tags:
git push -u origin --all
Convert Hg-specifc config to Git
Take the opportunity now to convert your
.hgignore file to an equivalent
.gitignore one. You can go and do this back on your own machine.
Delete the VM
Back in the Azure Management Console, delete the VM. When you do this, choose to “delete the attached disks”. (It will ask you.)
You’re all done. Wasn’t that just a perfect, easy use of the cloud?
Lately, I’ve been reading One Strategy: Organization, Planning, and Decision Making. It’s a collection of Steven Sinofsky’s internal blog posts while he ran the Windows division, with some light analysis by Marco Iansiti. (The blog posts are so far more interesting than the analysis.)
This quote stuck with me (page 30, Kindle location 746):
We are still not sending around (locally) enough meeting notes and not sharing information more freely. And part of that is asking people to be more receptive to “raw data” and less demanding of “tell me what is important” because with empowerment comes the need to process more data and manage the flow of information. For our process to work smoothly we do need more communication.
Within Readify, we’re seeing a fast growth of shared OneNote notebooks. They’re like wikis on steroids: near real-time multi user editing, ink, images, audio, no save button, multi-device, offline support, web app, deep linking right down to a specific paragraph, and more. They’re an insanely useful part of our information flow, and deserving of their own post another time.
The ease of access that comes with these pervasive notebooks has lowered the bar for content capture. And it’s great.
Instead of some formal documentation requirement that gets missed, we’re now able to capture the as-it-happens notes. After 10 years of consulting, we’re finally seeing a really rich knowledge base about our engagements get synchronized back into SharePoint instead of living in the heads of individual consultants. Call notes, meeting notes, architecture diagrams, sprint reviews, pre-sales meetings, org charts and whiteboard photos all end up in the notebook now. When I go to a presales meeting, the account manager and I are both recording our different notes straight into the same page of a notebook in real-time, then one of us can snap a pic of the whiteboard as we leave. (SharePoint + 4G enabled devices are the back-end plumbing here.)
These notes don’t provide the full context of a project, but they capture a series of events that cumulatively provide much of that context. They aren’t an analysis of the events either; they’re a summary, closer to a transcript. But that’s all ok, because they create visibility across our teams and open conversations we weren’t having before. Seeing this transition sweep across our business, I have to say that I wholeheartedly agree with Steven’s views.
Special thanks to fellow Readifarian Richard Banks, who actually had the slides already.
Because this is being posted to the Big Bad Internet™, I feel the need to disclaim up front that these terms are not my own, nor are my definitions necessarily the canonically ‘correct’ ones. If you get to the end of the post though, you’ll see that that doesn’t matter. This post is one of hopefully a few, where I capture some known ideas but with my own style and analysis. This is primarily being driven by a desire to give some common concepts that I discuss a home that I can link to, where existing descriptions around the internet may not capture my exact personal views.
A mark of maturity that I’ve noticed in effective teams is an evolved language: they have their own catch phrases, and shortcuts that make communication so fast and efficient within the team. Intention is clear, ambiguity is reduced, and people spend less time analysing subtext that isn’t there.
This culture of communication is heavily rooted in strong interpersonal relationships, which do take some time. However, I’d like to argue that we can actively develop some of this communication culture.
Last month, I spent a week with a software engineering team in New Zealand. Their organisation is in the early stages of trying some big, bold, new ideas, and this team needs to support these somehow. The roadmap is still a little fuzzy, but everyone appreciates that they have a lot of work ahead of them. Success will be heavily influenced by spending the just the right amount of time on the right things, but this is a perilously thin path to success with cliffs and chasms everywhere they look.
To stay in check, everyone on the team needs to feel comfortable to question the validity or extent of a task. Equally, they need to still feel comfortable when on the receiving end of such a question. In many teams, this question might come across with phrases like “Isn’t that enough already?”, or “Is this gold plating?” These often come across as confrontational though, seeming to cut away at the value of the work that somebody has been doing. There are nuances open to interpretation, because as obvious as they may seem, the intent of the phrases is not necessarily clear.
I introduced the team to two new phrases:
Your home office chair is making an annoying creaking sound because of a loose bolt. You could tighten it easily, except it uses a hex head and you lent your bit set to your neighbour. You can’t ask for them back, because you first need to return something to him: a special anti-allergy pillow that you borrowed for a friend who was staying last week. But you can’t just return the pillow either, because the dog got into it and ripped half the stuffing out. You don’t want to tell him, because it’s filled with a special yak fur that’s hard to come by, which he needs for his son when he visits: you want to fix it yourself first.
The next thing you know, you’re down at the local zoo, shaving a yak, all to stop a squeaky chair.
All of the decisions to get there were individually justified, but at some point you drift too far away from the original goal for them to still make sense as a whole chain. Just buy a new bit set, or give him some money for a new pillow. Or both. But don’t go and shave a yak.
This yak shaving phenomenon tends to hit some people more than others, but what makes it particularly perverse is when groups of people get involved. It’s bad enough when one person gets all up in arms yak shaving, but when you try to get a group of people together, you’re just as likely to end up giving the yak a manicure.
Parkinson observed that a committee whose job is to approve plans for a nuclear power plant may spend the majority of its time on relatively unimportant but easy-to-grasp issues, such as what materials to use for the staff bikeshed, while neglecting the design of the power plant itself, which is far more important but also far more difficult to criticize constructively.
Back with the Team
These two phrases each provided distinctly nuanced versions of the original question.
In the way I try to introduce these phrases, “Are we yak shaving here?” says “I can see all the decisions you’re following, and they all seem legitimate. Standing back here though, with a fresher set of eyes, do you think we are drifting a bit too far from the original goal?” Slightly differently, “Are we bike shedding?” is an explicit call of triviality, but recognizing that it’s an easy trap.
Your team’s definitions can vary; what’s more important is that we had a conversation about how we’d communicate. We took a funny story about yaks, and used that to define some phrases that were relevant to the team. Now, when the team hit these scenarios, they can use one of these phrases knowing that the nuances have been pre-discussed and agreed on.
In truth, in this scenario I actually only told these stories to two members of the team. Within a few hours though I heard them describing their own variants of the story to others. That’s another thing that’s great about these types of communication devices: humans communicate better with stories than dry, independent facts. (You might notice, that for this entire blog post, I just told you a story. J)
Related reading (manually curated by me):
This is what happens when you phone me up at 6am on a Saturday morning: you get a surprisingly energetic Tatham
babbling about discussing Neo4j and graph databases for an hour. There are even some nice bird sounds in the background towards the end, as they finally woke up too.
We discussed what graph databases are (as opposed to charts!), some domains where you might use one, how they relate to other stores like document and relational databases, query performance, bad database jokes, my obsession with health data (go.tath.am/weight, go.tath.am/fitbit, go.tath.am/cycling, go.tath.am/blood), the Cypher query language, ASCII art as a job, Readify/Neo4jClient for the .NET folks, and some Neo4j+NewRelic.
Useful? Help the Children.
If this podcast was useful to you, perhaps you could donate to my next charity cycle? I’ll be cycling the first leg of the 26 day, 3,716km Variety cycle. Variety, the Children’s Charity is a a national not-for-profit organisation dedicated to transforming the lives of children in need. Variety’s vision is for all children to attain their full potential; regardless of ability or background – and their mission is to enrich, improve, and transform the lives of seriously ill, disadvantaged and special needs children.
Besides just being a cool domain name, it’s actually quite a useful tool. Wondering how your code responds to an HTTP 418 response? Point it at httpstat.us/418 and find out.
Aaron and I originally built this as a way of learning Ruby, Sinatra, HAML, Sass, Git, Heroku and other funky tool chains. Several years on, left unmaintained, something about our app finally made it incompatible with Heroku’s hosting layer and it all shutdown. Our singular name really rang true here: every request returned a 503. Oops. We already had an ASP.NET-based re-write waiting in the wings, so we pushed that up to Windows Azure Websites and everything came humming back to life.
Want to learn a new tech stack or tool chain? Skip the contrived examples and actually build something simple. It’s amazing how often these turn into cool little tools that stick around for time to come.