Brexit – an analogy using git

One of my lectures from today was invited to a round table discussion with the secretary of state last week to discuss the impacts of Brexit within cultural heritage. The way she explained the Brexit process immediately made sense to me through a git analogy, so I thought I may write it down and share it.

Currently the laws of the UK and the laws of the EU exist in two different repositories. However, the UK repo has a dependancy on the EU repo. This is a fairly important and powerful dependancy, and the methods (laws) in the EU package have the power to override the methods outlined within the UK.

Ok – so lets break this down.
The UK repo is pretty confusing; it is an unwritten constitution and is thus in a state of continual evolution. It pulls it’s methods (laws) from statues passed in parliament (high law) and judgments from judiciary courts (common law). However, there is no one document which lays out the law, like the constitution in the USA. This is because of how the UK has evolved; absolute monarchy,  magna carter, civil war, commonwealth, the restoration of the monarchy etc. I could into great detail about the evolution of this repo and it’s dependancies but that is not necessarily the subject of this discussion.

The point, is that the UK repo is huge, difficult to imagine in full and is constantly changing.

The EU repo, on the other hand, is younger an yet more complex. The UK repo only has one organisation contributing to it; the EU has 28. One of the reasons that the UK voted to leave the EU is because of the sheer size of the EU repo; it’s complex and carries a horrific amount of technical debt. This means getting new methods implemented takes a years of never ending pull requests, which go back and forth between all different contributors who all want the pull request to do different things. It promotes this process as open and democratic but in reality the complexity of it makes the repo seem private rather than public.

Another reason the UK voted to leave is because people get really pissed that the EU methods automatically overwrite the UK methods.

So that’s the current status, what happens when we leave?

The day the UK leaves the EU, the UK will fork at the EU repo into the UK account, merging all of the methods within the UKs. Therefore, the methods will still be implemented, but we will escape the nightmarish system of creating new ones.
From this point, our forked EU repo will no longer be updated from source.

Then the pull requests will start.

Once we’ve pulled this the EU repo into our own organisation, all the UK contributors will fall upon all of the EU methods they do not like and they have not been able to change up till this point.

I am sure there will be good and bad things that come from this process, irritating and pointless legislation will be removed. However, be warned that companies with a lot of developers, with a lot of power in industries will crack down on methods they don’t like (e.g. large scale development firms will try to get rid of environmental laws and measures currently safeguarded by the EU).

Therefore it is crucial that after the repo is forked, we keep an eye on what pull requests are being made and what methods (or laws) are being changed by who.

So that is my take on the current situation – it’s is very hand-wavy and terribly vague and probably incorrect in large parts. Let me know if you found it useful, you agree/disagree with it or can find a way to improve it. Comment away!

Focusing on empowering women and girls: why it is acceptable and why it’s important

Yet again today I was faced with the comment that organisations such as Code First: Girls and Chayn were wrong and immoral. This is because they are focused only on women and girls (as well as other underrepresented genders)  which is in itself sexist. It is an interesting argument to say that in targeting one gender, you will alienate another, and thus programs such as CodeFirst:Girls, Ada’s List, Women Who Code (this list goes on…)  are a contradiction in terms and can only detriment gender equality.

It is an interesting argument, but it’s wrong. It is also something that I, along with many of my peers, often face, and so I asked around to see what their separate responses were. I was not disappointed.

So here is the argument for why female focused programs are positive for gender equality. (I warn you now – that this is my polite version)

So let us start off with this metaphor:

Imagine that you have a class, which the professor splits in two, group A and group B. For 75% of the year the professor favours group B far above that of group A. He helps them, supports them and gives them extra tuition. Suddenly, the professor has an epiphany, and they realise that they are completely wrong in favouring group B over A and that his discrimination was wrong. As a result he decides to give fair treatment and equal opportunities to all, does this lead to an immediately fair situation?

Hell no. Group A has been so discriminated against it is far behind it’s counterpart – as such the students have no way of achieving the same results in the end of year test. They will need extra tuition and opportunities to reach the same skill level as the favoured group.

And, it is the same with women and girls.

In an ideal world we would not need organisations like those mentioned above, but an internationally ingrained patriarchal system means that these organisations are sorely needed. Many women are not in a position to empower themselves because they simply do not know of the opportunities available to them, or they are unable to take those opportunities due to other factors (such as cultural based expectation).

In previous conversations with leaders of organisations there is apparently a noticeable difference in behaviours between genders. Often you’ll find men will ask for pay rises, negotiate more heavily and place a strong emphasis on skill whilst a similarly skilled women will undervalue their skills and not push for the same recognition. Why is that?

Beyond the career, children are treated completely differently according to gender. It has only been through watching my 6 nieces and nephews grow up that I have noticed how outstandingly gendered children’s toys are; Lego Friends make me feel physically nauseous. We teach our children from birth that they are to expect different things from life, pink and blue.

Organisations such as CodeFirst: Girls would only negatively affect gender equality it there was parity in the first place. Imagine it like a see-saw; if one side is heavier than the other, you don’t get balance by putting the same weight in both sides. We would all like nothing better than for there to be a time when there is no need for the charities and organisations in question. But sadly, today is not that day.

I suppose there is an argument that if you just give all genders equal opportunities, eventually it will event out. Eventually. Honey, if you expect me to sit on my laurels and wait for gender equality to just even out – you have another thing coming. Considering the centuries of disparity – it will take centuries again without direct action, and I am not going to live for centuries. I want the gender I identify with to be seen as equal now, why should I expect anything less?

Big thanks to Madeleine, Ruby, Amali , Hera, Eleonora, Chiara, Nida and Maryam for all your contributions. You fabulous inspiring women.

Code == Knitting?

“Knitting is basically coding”. Its a comparison I have heard banded around by a couple of senior tech experts and one that I frequently use myself to either tech scared knitters or craft scared coders; but how true is it?

A knitting pattern is essentially a computer program: it defines what you need to do in the correct order to achieve something. The difference between the computer program and a knitting pattern is the thing that carries out the pattern. In one it is a computer (with no knitting needles), in the other, a human (with knitting needles).

Really? It’s that simple?

Yes, and to demonstrate this, I will now write out two different knitting patterns, in pattern style and ruby style, so you can see that there is very little difference!

Knitting Pattern:
“Cast on 126sts.
Work in K 1, P 1 rib for 1.25ins.
Work in stocking stitch for 3ins, finishing at end of a P row.
Next row: K two stitches together, K across row.
P two sts together, P across row.
Rep until you have 10 sts.
Cast off.
Thread yarn through top 10 sts, pull together and stitch down the side to finish piece.”

Computer Program:
hat = Hat.new
hat.cast_on(stitches: 126)
hat.rib_stitch(length: 1.25, knit: 1, purl: 1)
hat.stocking_stitch(length: 3)
until hat.stitches == 10
hat.decrease(increment: 1)
hat.cast_off
hat.sew_up


And in human language:
Cast on 126 stitches onto your needle
Work in 1X1 rib stitch until your work measures 1.25 inches
After this, work in stocking stitch (purl one row, then knit the next) for a further 3 inches
On a knit row, knit the first two stitches together and knit to the end of the row.
On the next row, purl the first two stitches together, and continue along the row.
Repeat this (decreasing) until there are only 30 stitches left on your needle
Then cast off
Thread the yarn through each of the top stitches and pull tight to gather the top of the hat. Then stitch the two sides together to finish the hat.

The result – ONE HAT!

So – can people who knit code and vice versa?

Yes! It’s all about taking it one step at a time and not being put off by the big picture. Tell me to knit a jumper and I will run a mile – tell me to just knit one stitch – then if I repeat that a gazillion times to make a jumper – much easier to deal with!

Its the same with programming:
“Can you build me a website?” – “Errr…”
Vs
“Can you just take a couple of these lines of code and repeat them until you have a website?” “Yes!”

My Guide to Git, Part 1

EH?

When I first started at my current company I soon discovered there is nothing more dangerous to a codebase than a inexperienced dev with git access keys. On my second day I accidentally deleted my entire days work because of some command.  Of course I have no idea how I did it and I was far too scared to admit it to my boss and so I promptly did the whole days work that night amongst many frenzied google searches and silent prayers that no one in the team would realise the fraud of a developer I was.

Of course – it was fine, after a couple of days I worked out how I had deleted everything and made several notes to never do it again. Which I did. The next day.

Undoubtedly one of the hardest things to get to grips with when you start learning to code is Git. Unlike markup and programming languages, version controlling is not visual. Therefore, if you are unused to working from a programmatic viewpoint, it is incredibly hard to conceptualise. There are tools that can make this easier (git guis – I’ll get onto them in a future post) but even these require a fairly good knowledge of what on earth is going on in order to understand.

In this post – I’m going to take you through the metaphors I developed when I was first trying to get my head go with git, and in the following posts I detail my git toolbox – a nice little dictionary of my favourite git commands.

So what on earth is going on?

So git is a ‘Versioning Control System’, (ohhh, thats some excitingly dull words right there). This basically means that it is a tool that, when you ask it to, makes note of the state of the folder or file you are working on.

So imagine you are playing a computer game – every time you reach a checkpoint, the game saves your progress to that point. That is exactly what git does – except it does more. It keeps a record of every checkpoint you have reached – which means you can go back to that point.

Say you reached a hallway in Hogwarts (yup, we are playing a HP PC game now) and saved the game, you proceeded down the left corridor. This turned out pretty well, you found a Wizard card and a caldron full of beans, but you also found a venomous tentacular and you fainted. So instead you decide to go back to the checkpoint and try the right corridor. This turns out well as you find a stamina boosting chocolate frog – giving you enough life to face the venomous tentacular.

Good that you got that frog – as getting past Peeves here is a bitch

Lets get more complex

So, we have established the idea of these check points (or ‘commits’ as they are really called) and the ability to navigate around them, however, this does not fully appreciate the ‘different version’ bit of version control!

So now lets imagine our file as a tree, with a main trunk of work with regular commits. The trunk is your ‘master’ branch, this includes all the changes are ready and safe to be in your finished website.

But say you want to develop a new part of your website? Maybe a brand new feature.

In this instance your website is a very simple site where you list your favourite people from history. Ah, but then you think: “There are simply not just enough reference to Isabella, the She Wolf of France, on the internet” so you decide to build a hall of fame for the most badass monarchs.

Centuries before Shakira there was Isabella. She was badass.

However, halfway through building your hall you realise that you don’t have a good way to assign images to entries in your website. These are two very different features your website needs, and so they don’t necessarily need to be worked on at the same time.

So – you create two branches from your master tree – a hall_of_fame branch and a better_images branch. You can work on both projects independently, switching between the two easily, then, when they are done – you can merge them into master and push it to live.

The great thing with this branch approach is that you can continue with the general day to day fixes to the site easily. Because the code for these new features is on a seperate branch – you can easily adjust the spelling mistake you made on your last entry (Joan of Arc and John of Arc are very different people) without polluting your codebase with half baked files relating to a hall of fame.

So – got that?

I hear your silence and take it as yes.

Next time – collaborating with branches!

Are we in Danger of being the Lost Generation in Tech?

I live and work as a software developer in one of the largest cities in the world, and there can be no hesitation to say that we are in the middle of a technological revolution.

But what exactly does that mean? I am aware that this is just background noise for most; London is often an intrinsically insular thinking city which pretty much fails to grasp the concept of human existence outside the M25. What does a tech revolution mean to everyone that lives outside this type of eco-systems?

Well, at least most of the time, not much. And it’s hard to, as away from the hype and the free beer, people have their own issues. Innovations in technology are pretty damn niche in comparison to ‘I have to work a double shift tomorrow and dammit I just want a G&T shut up about fancy watches already’. So why am I writing this? Because our generation has a lot to lose from not caring about tech.

We made mud pies when the Dot-com bubble burst, we survived the millennium bug, we mis-managed the delicate politics of teenage social groups over MSN messenger, organised uni life on Facebook and graduated into the ‘Internet of Things’. Technology has utterly shaped our lives; something that on the whole we have accepted without much argument. Our generation’s IT lessons were spent flagrantly ignoring our teachers pathetic efforts to make a powerpoint presentations and fights with the rubber balls from the mice. IT was dull and pointless.

Nowadays that is not the case. Programming is being taught from primary school level, and children are being encouraged to code. Next year the BBC will give a raspberry pi to every 7 year old in the country to train them to build and break things. We are training a generation of mini super hackers. Which is great…

But not for our generation. The world of startups today offers a preview of how large swathes of the economy will be organised tomorrow. This pattern is already emerging in such sectors as banking, telecommunications, electricity and even government. The future is tech driven and in almost any sector this will be difficult to avoid. People who ‘don’t get computers’ will be left behind when the generation below us graduates.

The industrial revolution produced countless inventions that immeasurable improved many people’s lives and transformed society to the cost of multiple jobs. However, it created new economic opportunities on a mass scale, with plenty of new roles to replace those that had been made redundant.

Whether the digital revolution will bring mass job creation to make up for its mass job destruction remains to be seen, but how do we avoid being part of the jobless in years to come?… learn how to ‘get’ computers, and learn now.

(For and interesting article about this – check out this special report from the economist

http://www.economist.com/news/special-report/21593580-cheap-and-ubiquitous-building-blocks-digital-products-and-services-have-caused)

Wait, what is it you do again?

My life has taken a fairly dramatic turn in the past year, from History of Art and everything cultural heritage to web development and everything tech. To answer the increasingly bemused remarks from friends, family and passing pub randoms I have developed some particularly useful metaphors to explain what I do, what Ruby is, and how an Art Historian can change their career with such ease. I find myself repeating these so often I thought it may be good to write them down.

---

The Web App Metaphor

The web app I work on (www.woolandthegang.com) is written in Ruby, with Ruby-on-Rails and Spree frameworks, has a SQL type database whilst the front end is comprised of HTML, CSS and Javascript. This is great and could sound impressive, but lets be honest it is a sentence that means bugger all to the majority of people.

So lets think of the Wool and the Gang website as a building instead.

Ruby is the main language of the app: think of ruby as being the bricks with which the building is built. However, you need more than bricks to build a house.

This is where Ruby-on-Rails comes in. It is a blueprint that enables you to get your basic building up in no time at all, complete with roof, flushing toilets and electricity as automatic bolt ons (Sinatra is another example of this, but it builds more of a shed in comparison to a rails building). It’s a very simple, generic building and is relatively easy to build on it and turn it into whatever type of building you want.

This is where the Spree framework comes in as an optional extra. Wool and the Gang isn’t just a web app, its an eCommerce site. To translate this into our building metaphor, we don’t want a building, we want a mansion equipped with swimming pool, baroque garden and a secret passageway (which changes location every second Wednesday). Spree is the blueprint for this that can be plonked on top of our current Rails building blueprint. Remember, these things are only blueprints, so these frameworks allow you to adjust elements of the buildings, such as adding a turret or two, which will be bespoke to your building.

Then there is the database, this is the contents of all the rooms in the building. Using the database language you can ask the butler to fetch your parasol to the lawn, and he will go in, check its there, take it, bring it out, then hopefully return it when you’ve finished your afternoon tea. With luck, and if you have used the right language, he will be a very efficient butler, and make a note of your parasol at each stage of its journey to you and back, which makes it very easy to locate when you next need it to take a turn around the herb garden.

So what about the facade (front end)? Well, HTML (Hyper Text Markup Language) plots where the doors, windows, chimney stacks and columns will go. The CSS (Cascading Style Sheet) then decorates all these elements as directed. It will adjust the size of the door, the exact colour of the lawn and whether the columns are Ionic, Doric, Corinthian or even Composite (ooo, racy….). Then there’s Javascript, this makes sure the doors open, the fountain is flowing and the doorbell rings when rung.

And voila! One beautiful, stable building, bespoke to your every need and whim!

Hopefully…. because as anyone who has bought anything from IKEA knows, there always that suspicious leftover screw….