Softwire Blog


Using git-tfs in anger


31 August 2016, by

A while ago I wrote about how no-one should ever user TFS, ever. While I was unfortunately forced to use it I experimented with git-tfs to see if it would ease my pain, and this is what I found.
Why git-tfs
It seems to be the main git-to-tfs-bridge right now. There’s another option, git-tf, but that one hasn’t been updated since 2013. git-tfs appears to be an active project.

The Good

  • Local version control: local commits and local branches. Proper branches (not TFS folder-branches) which are lightning-fast to switch between, and you can cherry-pick between.
  • Rebase temporary dev branches back onto master instead of clumsily re-applying old shelvesets.
  • If more than one person is using it, push and pull git branches between yourselves, and keep developing even when the central TFS server (inevitably) goes down.
  • Separate source control from Visual Studio: generally a good idea in my opinion, and particularly useful if VS is already running slowly.
  • Reliable version control: TFS get-latest is a bit buggy, but git-TFS seemd to work reliably. Perhaps it abstracts away for you the tedium of always telling TFS explicitly to get the latest version of all files, not just some.

The Bad

  • You can only checkout one directory at a time so you need separate checkouts for different root-level projects in the same repo. This is pretty minor though.
  • Visual Studio gets a bit confused and integration isn’t as good. Keep it happy by using msys git (git for windows) not cygwin git if you can.
  • Changing between TFS and git-tfs, or just using visual studio with a git-tfs checkout, leads to corrupt TFS workspaces.
  • Doing things differently from the rest of the team means you lose out on their TFS knowledge and support, for what it’s worth.
  • You won’t be able to add projects to the solution properly.
  • Visual Studio will constantly try to remove the tfs element from the .sln file, which will break TFS integration for everyone else if you commit it.
  • If you need to keep local changes, e.g. for local environment config, then it’s a pain to stash the changes all the time (you need a clean checkout to rebase).
  • It’s just really slow – mainly because my team’s TFS server was slow; but git-tfs was even slower.

Verdict

For me, unfortunately the advantages don’t outweigh the disadvantages, and I probably wouldn’t use it again. it’s a bit of a pain to set it up and to use different tools to the rest of the team. On my next TFS project (and I’ll do everything in my power to make sure there won’t be one) I’ll just embrace the shelveset workflow instead.

What I might try is just to git init a local repo in my TFS checkout and get local branching that way, adding the .git folder etc to the local ignore list, although it might lead to some manual effort keeping branches in sync with the remote.

Setting up

If you do decide to use it, this is what I did to set it up:

  1. Install git, and configure it:
$ git config --global core.autocrlf true # see https://help.github.com/articles/dealing-with-line-endings/
$ git config --global core.filemode false
  1. Install git-tfs: http://git-tfs.com/
  2. Clone the repo:
$ git tfs clone http://tfs:8080/tfs/DefaultCollection $/some_project -c XXX

Where XXX is a recent changeset – you’ll only have history available from this changeset, but the further back you go the longer the clone will take.

  1. Open in Visual Studio!

Don’t bother to un-map your workspace: the Visual Studio TFS integration will go away when you open your new “git” project. And it will be easier to go back to pure TFS if you want to.

Everyday Use

Always rebase when pulling:
$ git tfs pull --rebase

To map local commits to checkins one to one, use rcheckin instead of checkin or checkintool.

$ git tfs rcheckin --no-merge

Be careful though, this makes a number of commits in a row, and because TFS is so sloooow the can be nearly a minute apart and trigger more than one consecutive CI build. If the build time is slow this might hold other people up from committing, so keep an eye on it: you can always cancel the first build(s) if this happens. You might just want to squash up the commits to save time committing!

If your project requires certain custom notes fields to be supplied, use the -n (--notes) argument to supply it from the command line:

$ git tfs rcheckin --no-merge -n 'JiraNumber' 'AA-123'

(more…)

Tips for remote working on the other side of the world.


4 July 2016, by

Like lots of people I’ve always liked the idea of remote working in exotic locations, but I recently had the opportunity to give it a go. I travelled halfway around the world and continued working for Softwire from New Zealand.

I enjoyed the experience, especially the 100% flexibility of knowing my team were all in bed: as long as I’d done a day’s work by the time they woke up, I could drop what I was doing and hit the beach or go for a long bike ride whenever the whim took me. On the downside there was almost complete isolation, access to the rest of the team was very limited and the brief period of overlap when I could actually talk to people became very valuable, even though it was at highly inconvenient times of day.

If you’re interested in more detailed advice about working remotely as a developer, see my original post on my personal blog: http://swilson.co.uk/blog/2014/09/11/working-remotely-in-a-dev-team/

WDCNZ Web Dev conference, Wellington: Part 3


16 October 2014, by

At last, the long-awaited final part of my WCDNZ experience, following part 1 and part 2

Building Your Own Tools

The highlight of the day was James Halliday (@substack), creator of browserify and other things, giving us a whirlwind talk and demo live from his laptop. Unfortunately it went so blisteringly fast I didn’t take many notes, so I’m not really going to do it any sort of justice here at all.

The theme was about writing tools which work together nicely. There were two main arenas discussed: the command line, and node. We started with a general note: don’t be afraid to write your own tools, but you should probably first check that there isn’t already just such a tool out there.

  • First example: examining pull requests from github
    • James gets a lot of pull requests
    • Tip: if you add .patch to the end of the URL of a github pull request, you get a patch that works with git-am
    • git-am is a git tool which was apparently made by Linus Torvalds for his own personal use – so the tradition of building one’s own command line tools is an illustrious one
    • You can use the pipe to send the patch to git am, either by using curl to get the patch, or copying it from a browser and using xclip, maybe something like
      • $ xclip -o | git am
    • So here we have useful command line tools that you can chain up using the pipe, and even swap tools in and out depending whether input is from the web (curl) or clipboard
  • James then showed us some command line tools of his own, along similar lines, which provided the various parts of a time tracking mechanism. I can’t remember much detail but I think it went something like this
    • There was a tool that generated some JSON for one timesheet entry
    • There was a tool that accepted this json did something else with it
    • There was a tool that took a bunch of these timesheet entries and saved a timesheet file, or something
    • Another tool took the same input but emailed a timesheet
    • One tool took lots of timesheet entries and combined them according to task code
    • … or something. Anyway all these tools ate and returned json and so could all be piped together in different combinations depending what you wanted to do
  • A pattern emerges: each tool is very small and does one thing well, and they share a common input/output
  • Finally we turned to some of James’ tools on NPM: browserify (bundles up node server modules into modules that will run in a browser), tape (a node test harness) and some pieces of accountdown (user management and authentication). I don’t remember enough detail to say much useful about this, but I thoroughly enjoyed it.
    • We had a great demo where browserify and tape were used together to great effect on the command line
      • One interesting takeaway is that tape outputs in a language called TAP, which makes it compatible with various testing tools (like testling) and swappable with other test harnesses (nodeunit has a TAP reporter plugin)
    • Similarly, the node demo where some of the accountdown functionality was built incrementally from scratch went pretty fast but the gist was to isolate little bits of functionality, e.g. creating a user, authenticating a user, into their own node modules.
  • Some choice quotes:
    • If you’re going to build your own tools, please please test them. That way you can convince other people that they work.
    • I use my own test harness [tape]. Everyone should write their own test harness, but if you like you can use mine, it’s pretty good.
    • The people who know what they’re doing can make a little module that encapsulates that knowledge, then everyone can benefit.

Miscellaneous Tips

  • Check out the persistent in-memory key-value store levelDB – it’s easy and unlike some other in-memory DBs, it’s very fast.
  • If you have a project with some usage examples, you can bootstrap tests for that project by copying all the examples into a new “tests” folder and converting them into tests.

Further reading

Writing Better CSS

Toni Barret (@toni_b) tells us that good CSS is:

  • Maintainable
  • Understandable
  • Well-planned

In particular, good CSS need not be highly optimised for performance. How to do it:

  • Plan
    • Decide which browsers you will support
      • And decide what “support” actually means. For example you may have different levels of support: “full”, “mainly works”, “functional but not pretty”, “only if time”
    • Decide on a set of standards
      • For example, don’t nest more than three layers is a good rule to have. Doing so often leads to bad selectors…
      • …where a “bad selector” is one which is reliant on the html structure, too specific, and/or not reusable.
    • Decide which tools you will use and set them up from the start
      • Concatenation, minification, pre-compilers, etc etc
      • You don’t want to retro-fit this stuff later on if you don’t have to
  • Use Comments
    • Don’t avoid commenting CSS: you comment your code when you need to, and yet people rarely comment CSS.
    • In particular that big Table of Contents comment at the top (that comes with bootstrap and other libraries) is very useful: if you are using it then make sure you take the time to maintain it
  • Divide and group you CSS logically into files and sections
    • avoid the common everything-is-appended-to-the-bottom-of-main.css problem
    • and avoid the each-developer-has-their-own-css-section-with-different-styles problem
  • Use a “pattern library
    • Exactly what this means went a bit over my head, but checkout http://pea.rs/ for an example, and I think it also provides a way to bootstrap your own pattern library
    • In a bit team or a big/long project, this will make development easier and lead to a more consistent style

Further reading:

That’s it!

WDCNZ Lanyard

WDCNZ Web Dev conference, Wellington: Part 2


9 October 2014, by

A round up of some more of the talks from WDCNZ

Coder Decoder

Katie Miller (@CodeMiller) explained some of the mysteries of functional programming using pictures of cartoon snails. I won’t be able to define them here any better than wikipedia will do for you, but below are the ideas she demonstrated. Haskell was the language of choice, not because it’s particularly better than any other functional language, but because it’s just so canon.

  • Referential Transparency
  • Higher Order Functions
  • Currying
  • Closure
  • Functors
  • Monads

Yes, Prime Minister

A bit like something out of Flight of the Conchords, The PM John Key casually popped in over lunch (totally unscheduled) and gave a talk about tech needing to be at the centre of the government, and how he played golf with Obama once.John Key

The Panel: A Technical Education

A panel of speakers debated the state of computer science education, why kids aren’t interested in programming, and why students aren’t being prepared for a career in web dev. I don’t think very much of interest came out of it, other than Tanya Grey’s (@Tanya) experience that if high school students actually get the chance to try out some coding, they will always be interested in finding out more (every single time, apparently).

Sara Chipps claimed that because there is no degree course in web development, we all must be self-taught, which I think is only partially true because while self-education is a big part of working in tech (see the first talk in the previous post), it’s also true of every other career (except maybe academia and law) that you didn’t learn your trade at uni directly, your first employer taught you.

Tanya also pointed out that high schools are full of teachers without a computer science background doing their best to teach a syllabus that is starting to include more and more IT, and your local teachers would probably appreciate some help from pro coders like you in the way of backup such as being available on email to help them answer some of the more difficult questions from students. So, particularly if you have a child in school, why not get in touch and offer your services?

AngularJS Powered By SilverStripe

AngularJS is a front end framework which looks quite similar to Knockout to my eye, and can make it much quicker and easier to build web pages that change dynamically based on your data. James Pluck (@PapaBear) likes it. SilverStripe is an open source CMS and web framework in PHP that reduces the amount of boring boilerplate you have to write. That’s it really.

Building Your Passion With Hardware

Sara Chipps (@SaraJChipps) rounded things off by talking about how she started a programmable jewellery company as a means to try to get young girls interested in programming. Her reasoning was that she didn’t get into programming because someone told her it was cool, but because she needed to to solve a problem she had (when she was 12 she was maintaining some sort of BBS chat room website that she used to find friends). So she’s giving young women a problem that they need to code to solve.

This is an example of how it’s achievable to get stuck into hardware and make something interesting, and also of how it’s possible with a little time, money and effort to kick off a business in some new field that you don’t know much about.

Things that might be of further interest

  • Spark – like a tiny arduino, I think
  • www.instructables.com – a load of DIY hardware (and other) recipes to follow

One more part still to come…

WDCNZ Web Dev conference, Wellington: Part 1


3 October 2014, by

WDCNZ is in its fourth year. It’s a smallish conference (by London standards) with only 1 or 2 speakers on at any given time but the speakers were passionate and the atmosphere was great, and I came away even more excited and inspired than I usually do from the big boys JAX and QCon. Videos of the talks are available here. IMG_20140731_085721

Recurring themes

I don’t think any of these were planned but the themes that kept popping up throughout the day were

  • Build things in small pieces. Be they components, modules, packages or plugins, you should architecture your things in a way that allows bits to be easily added and replaced. In javascript (the language of the moment), this is made easy by NPM, requireJS and commonJS. Microservices weren’t actually mentioned, but they’re very popular at the moment and another example of the same philosophy.
  • Everyone is using Node.JS. In a city of .NET and Java, almost every speaker was using Node either for their job, their side projects, their robots, or in some cases just for their slides. Browserify means node modules can work on the browser too, so “javascript” means “node” now.
  • Get some hardware, build something awesome and program it. This was made to look easier than you might think. Get some random lights or motors, connect them to an Arduino, glue on a Rasberry Pi to provide a wifi link and/or web interface, and the rest is just code. We saw programmable jewellery, nodebots, door opening devices, etc etc.

How not to be an expert

Jen Myers (@antiheroine) kicked us off with a talk about what it means to be an expert, and how we probably shouldn’t pay too much attention to it. Instead we be willing to just jump in, and keep the attitude of a beginner for our whole careers.

  • You don’t need “special powers” or anything else to be an expert, or a developer – anyone can learn
  • “Unlearning our expectations” is often harder than the actual learning: a lot of the time people need to get out of their own way and drop their ideas of what they can and can’t do in order to achieve new things
  • An “anti-expert” is someone who is always learning (instead of claiming to have all the knowledge already)
  • Jen challenged us to go away and try something new, be it the flying trapeeze, fire breathing or learning a new language (she didn’t specify whether she meant Spanish or Ruby). Fortunately the next talk provided inspiration in this regard…

Javascript, robots and me

Sarah Hui (@sehsarah) took us through her journey from seeing a conference talk about building a robot to actually completing her own. In particular as a javascript dev she was inspired by the fact that you can program a robot with JS.

  • At first, obviously, nothing happened. Where do you find the time? Where do you even start?
  • “Start with something shit” – just make any old crap then you’ll be over the first barrier and away. This applies to art, writing, anything really, but also hardware. Get an LED and make it flash.
  • Longer term though you need a vision to work towards. Sarah decided she wanted something she could drive around, wirelessly, controlled via a browser, with a camera on board.
  • Other than getting stuck a few times, she really made it look rather simple
    • Some Node.js code, using libraries to do all the hard work
    • A pre-built tank robot kit
    • Glue on a raspberry pi and an extra battery pack to power it (this involved some fiddling to connect the usb port to some batteries) to run a node.js web server on the pi, connected to an iphone’s wifi hotspot (or other local wifi)
    • …. and that’s it?
  • Some useful things to look at:
    • johnny-five, the NPM library which lets node talk to arduinos and other hardware
    • Arduino
    • Raspberry PI
    • Mind Kits – ready made kits for driveable tanks and other bits, based on arduinos. Like an arduino on catapillar tracks.

On Front End Modularity

Mark Dalgliesh (@MarkDalgleish) talked to us about his experiences building and enhancing Bespoke.js, a platform for building presentations. A sort of open source, javascript powerpoint (only better, obviously). His message is to avoid creating a monolith style product by instead creating an ecosystem which others can contribute to easily, in this case by creating a plugin system, and generators to help people get started.

  • He deliberately wanted the core thing to have minimal features (it actually now only has three, because he removed two recently) but a plugin architecture which lets you pick and choose which features you want to use, and write your own.
  • Plugins are just node modules,
  • and in fact, plugins are just functions
  • Small modules!
    • Are easy to view the source of, to understand. No big scary black boxes here
    • Can be your experiments: no need to change and release experimental changes to core code
    • Bugs are minimized if each module is small and does one thing an an obvious, transparent way
    • And bugs are generally reported to the right place/project/person – much less wasted time
  • He wrote a Yeoman generator to make it easy for people to bootstrap bespoke.js presentations (this sounds a bit like using rails to bootstrap a web server)
    • Learning from this success, he wrote a generator to make it easy for people to bootstrap their custom bespoke.js plugins!
    • You should consider writing a generator for any tool you make
  • He chose Jade as a templating language (I’ve been using this recently too as it happens, it’s quite nice)
  • Having CSS in your JS module is ok – it’s ok to mix languages. After all, you have html templates in your production JS right? So don’t be afraid to ship CSS in a node module or whatever.
    • Concentrate on separating your concerns, not necessarily your languages or technologies.
    • In fact some node modules are ONLY CSS.
    • And, with browserify, you can use your node packages on the front end too.
  • When he got to writing themes for presentations
    • He realised a theme is a collection of features, or a plugin made of other plugins (apparently)
    • BUT we are familiar with the flat plugin structure from jquery, and early grunt. Something different is required: a sort of nested tree of plugins I think, but this bit of the talk passed me by a bit
    • Grunt actually had to change their plugin system for this reason, but they failed to change their API, unfortunately
    • Obviously, Mark also wrote a Yeoman generator to generate themes

Much more to come…

Copying SHA-1 hashes from gitk to the clipboard


7 August 2014, by

I don’t know if anyone else has this problem, but gitk with cygwin gives me the following headache all the time: I can’t copy more than one SHA-1 hash from it to the clipboard.

The problem

Say you want to diff between two commits, or cherry pick a range or something. Find the first commit, select the hash (like other cygwin/unix tools, selecting is enough to copy, so there’s no need to mash ctrl-c), paste it into the command line or wherever you want it.

Why won’t it copy?

So far so good. You needed two commits to diff between, so you select the other commit, select the SHA1 hash, paste it… and it pasted the first one. Even though you copied a new hash. The clipboard hasn’t updated, no matter how much you frantically click on the commit, the hash, select all or part of the text.

(more…)

Friday Lunch and Learns: TDD and Clean Code


10 September 2013, by

Every Friday lunchtime at Softwire we all get lured into a meeting room with the promise of free food, and one of our colleagues gives a talk on something they’ve been working on recently.

We filmed this talk on TDD and clean code, by David Simons, so that others can enjoy it too.

Friday Lunch and Learns: Contributing to GitHub


16 August 2013, by

Every Friday lunchtime at Softwire we all get lured into a meeting room with the promise of free food, and one of our colleagues gives a talk on something they’ve been working on recently.

We filmed this talk on contributing to GitHub, by Will Pragnell, so that others can enjoy it too.

Bristol to London Bike Ride


28 January 2013, by

As you may know, a group of us were recently inspired by the opening of the new Softwire Bristol office and decided to cycle from one Softwire office to the other! Conveniently Action Medical Research provided an organised cycle from Bristol to London and also provided a worthy cause to raise money for in the process, so we entered. The route was to be 116 miles. By way of preparation, some of us put in the odd bit of training here and there, Mike and Jenny bought themselves brand new racing bikes, and Jonathan briefly considered riding a bike with more than one gear (nah). And so on one bright weekend in August, we were ready.

(more…)