Tuesday, 14 May 2019
1. As a guest in Russia, it is vitally important to keep moving at all times. This is because if you stop moving for more than, say, fifteen seconds, your hosts will assume this is because you have run out of roast pork and sausages. It is impossible to sit down at a table in Saint Petersburg without somebody serving you a massive plate of meat. My hosts explained that the Russian phrase for 'no thankyou' is 'nyet, spasiba" but based on my experience I think this literally translates as "please bring me roast duck and cabbage now, and after that some more sausages".
2. Sausages in Russia occupy the culinary niche that is normally reserved for, say, some carrots in Western cuisine. You will find sausages chopped in a salad, boiled, fried, steamed, and served as accompaniments to all sorts of things.
3. Saint Petersburg is BIG. The average street here is wider than most London postcodes. If you have to walk three blocks, wear good shoes and take a bottle of water with you. Monuments and war memorials here are built to such a scale I can only assume they are intended to leave civilisations in neighbouring star systems in no doubt as to the nobility and sacrifice of the Russian military. We should give a special mention to the churches, which are not only huge, but we can conclude from the style of their decorated domes and minarets that the builders thought God had a bit of a thing for cupcakes.
4. Riding the Saint Petersburg metro will seem uncannily familiar to anybody who has read Jules Verne's "Journey to the Centre of the Earth". After buying your metro token from the ticket machine and passing through one of the metal detector arches - for which you are not required to empty your pockets or anything, meaning that they go off constantly and are consequently ignored by everybody including the police - you step onto an escalator approximately fourteen miles in length. The tunnels and station interchanges suggest that tunnelling machines in the former Soviet Union were available in two sizes - Extra Large and Stupidly Extra Large - and the interchanges are so big that the connected stations have different names. If, say, the Red Bull Air Race ever needed to be held indoors due to inclement weather, the pedestrian interchange tunnel at Spasskaya/Sadovaya would provide an ideal venue.
5. For typography enthusiasts, the Cyrillic alphabet is an absolute delight... except when it comes to handwriting. Cursive Cyrillic is a minefield of hilarity and ambiguity. Any doctors who feel they have exhausted the possibilities of the Latin alphabet when it comes to writing illegible prescriptions will find Cyrillic a rich seam of possibility.
6. The Russian people are lovely and friendly... once you get used to the fact that a Russian telling you a joke will initially sound like they're interrogating about some war crimes you may or not have committed. It helps to keep a Polish person with you, since they seem to know the correct point to start laughing, thus giving a handy cue to the slightly baffled English speakers participating in the conversation.
7. An English person trying to speak Russian is the funniest thing that has ever happened. The Russian equivalent of the Edinburgh Festival consists entirely of English people attempting to pronounce the names of Saint Petersburg metro stations whilst the audience drink vodka and roar with laughter.
8. Vodka must be served no warmer than -273.1499 degrees Celsius. To offer someone vodka that is merely refrigerated could cause a serious diplomatic incident.
9. Most consonants in Russian have a 'hard' and a 'soft' pronunciation, which, like tonal Cantonese or the tongue-clicks of the Khoisan language family, is completely impenetrable to foreigners. It is very important, however: based on my attempts to speak Russian to waiters, I have concluded that the elusive hard vs soft 'T' sound must be the difference between saying "no thank you, I have eaten so much food I think I need to to go the hospital" and "could I please have some more roast pork and boiled sausages"
10. There are a lot of Chinese tourists in Saint Petersburg. Local regulations prohibit them from travelling in groups of fewer than fifty. If you arrive to check in to your hotel moments after a Chinese tour party has arrived, you may wish to pass the time whilst you wait by reading the collected works of Dostoyevsky or walking to Vladivostok and back.
11. Every single car in Russia has a dashboard camera recording video footage of the journey, presumably so that when your cab gets cut up by another one and causes a six-car pile-up, the driver can pay the repair bills by sharing the crash footage on YouTube and hoping it goes viral. Most cab drivers keep their radio tuned to the local high-energy Europop station, so when they do inevitably have a massive crash, the resulting YouTube footage already has the appropriate soundtrack.
In short... it was AWESOME. The city is beautiful and vast and unlike anywhere I have ever been, the people could not have been more welcoming and friendly; arrival and departure was an absolute breeze thanks to the brand new, hyper-modern airport terminal building, and the metro is a great way to get around (and clearly signed in English throughout.) And if you don't fancy jumping through the administrative hoops of getting a Russian visa, you can visit SPB on a cruise ship from Tallinn or Helsinki and stay for up to 72 hours without having to get a visa, which is kinda cool.
Just don't stay up drinking vodka the night before your 5am departure. Trust me on this. :)
Friday, 22 March 2019
One of the best ways to keep the rest of your team up to speed with what your dev teams are doing is release notes - even if all you're doing is gently reassuring the rest of the organisation that yes, you are patching security vulnerabilities, fixing bugs and quietly making things better.
I love using Slack for this - set up a channel where you post a friendly summary of everything that's being released whenever you deploy to production. Now, here at Skills Matter we're not quite doing continuous deployment yet - we work off short-lived branches that merge to master several times a day, but then once master has passed regression testing on our staging environment, the actual deployment to production is a manual process - we open a master > production pull request in GitHub, merge it, and Heroku does the rest.
We track work in progress using Pivotal Tracker, and we use the various ticket state transitions as:
- Start > a developer has created a branch and begun coding the features
- Finish > the code is done; time for code review
- Deliver > the code has been reviewed, merged to master and deployed to the staging environment
- Accept > the code has been tested on staging; stakeholders know it's ready, and we're good to go live.
Now, this definitely isn't the best branch/merge strategy in the world, but it's the one we've inherited and the one we're using until we've made enough changes to the codebase to be able to deploy PRs directly to review environments.
Select the stories you want in Pivotal Tracker, click the bookmarklet, and it'll copy them to your clipboard as Markdown-formatted bullet points with the story IDs linked to your Pivotal project.
The JS code is here - add a bookmark, paste this whole lot (including the
And here's what it looks like in action:
Tuesday, 20 November 2018
So here it is. You'll need to get the host, port, username, password and database from your Heroku dashboard - and don't forget that if you're connecting from apps that aren't attached to Heroku directly, you'll need to manually update the configuration if you rotate your Heroku database credentials.
|herokuConnectionString @ ;|
Wednesday, 29 August 2018
We’ve all come across design patterns, right? Common solutions to common problems, more specific than a language or a platform, less prescriptive than a component or a framework. The pattern movement originated in building architecture, and in the years since the Gang of Four published their groundbreaking work Design Patterns: Elements of Reusable Object-Oriented Software, we’ve seen patterns embraced right across the spectrum of software development. We’ve got architectural patterns and infrastructure patterns and organisational patterns. We’ve even got anti-patterns.
Patterns are intentional. They have purpose. Even anti-patterns generally involve some element of premeditation. But patterns aren’t the only things in software where you’ll see familiar structures and characteristics playing out across different systems and organisations… There are also the emergent phenomena. The creeping horrors that we’ve all unwittingly summoned in the course of our illustrious careers. Things that don’t happen on purpose, that nobody ever set out to do, and yet which keep spontaneously manifesting in organisations all over the world. Here, for your education and entertainment, I present a bestiary: a field guide to the monsters and the creeping horrors that are lurking somewhere in your IT systems.
1. The Reliquary
The reliquary is that one repository full of really good ideas. Clean code. Brilliant algorithms. The OpenID implementation that you optimised until it shone. Classes so beautifully designed and perfectly documented that they’d make a senior architect weep.
You remember the big rewrite? The project that was going to fix everything, only you never worked out how to actually launch the thing, or get any revenue from it? The reliquary is where you’ve preserved it, pickled in revision control like a fabulous museum specimen. A treasury of good code and good ideas; maybe even an entire codebase that was “a couple of weeks” away from shipping before somebody finally looked at the number of critical features the team had somehow forgotten to include and discovered — to everybody’s surprise — that validated XHTML, normalised data models and 95% test coverage are not actually features any of your end users cared about. Like Buran or the Spruce Goose, the surviving artefacts stand as a testament to the quality of your engineering… and a poignant reminder of just how much fun engineers can have building high-quality stuff that nobody actually wants to use.
2. The Doctor Gonzo
Named for the attorney in Hunter S. Thompson’s ‘Fear and Loathing in Las Vegas’, the Doctor Gonzo is that application that’s “too weird to live, and too rare to die”. It’s written in Visual Basic 6, or Delphi, or maybe even Microsoft Access. Your dev team has to keep a couple of antique-grade virtual machines around to fix the occasional show-stopping bug — with instructions that the machines are absolutely not to be Windows Updated on pain of immediate defenestration.
Of COURSE you’ve tried to replace it. Team after team, project after project has come up with a plan, hired some contractors, captured some requirements, and shipped a couple of prototypes. And, as inevitably as night follows day, they have failed… all of their engineering brilliance powerless against the unholy triumvirate of bureaucracy, Stockholm syndrome and undocumented use cases.
In fifty years time when we’re all running genetic algorithms on bioengineered quantum hardware that eschews physical user interfaces in favour of superimposing consciousness patterns directly into our brains by inducing cross-dimensional electrical fields in a neighbouring parallel universe, at least one company will have made a fortune creating a post-singularity hosting environment for running Visual Basic 6 line-of-business applications in the quantum realm.
3. The Epic of Gilgamesh
You know this one. It started out as a simple database query — something that pulled out the sales figures for the last quarter. Then somebody tweaked it to account for currency fluctuations. Somebody else cross-referenced it against website traffic logs. Somebody else added a half-dozen LEFT OUTER JOIN statements so you could find out which web browsers the customers who created the accounts who raised the invoices that generated the revenue were using.
Sometime around 2008, the SQL query in question surpassed Queen’s Bohemian Rhapsody in length and scope. By 2012 it was longer than Beowulf - and about as readable. It now stands as one of the great literary epics of our generation, a heartbreaking work of insane genius that is as incomprehensible as it is breathtaking.
4. The Chasm of Compliance
“It is a truth universally acknowledged that a profitable organisation in possession of a rigorous security policy must be ignoring a few things”
— Jane Austen.
Some friends of mine used to work in the software division of a company that made scientific instruments. Big government clients, universities, hospitals, research laboratories. As part of the conditions of doing business with these kinds of clients, they had a very strict policy that forbade sending email attachments — which was backed up with a set of firewall rules that would block incoming and outgoing mail with any files attached to it.
If you needed to share a file with a colleague who was working from home or away on a business trip, standard operating procedure was to attach it to a draft email in a Hotmail mailbox and then invite your colleague to download it and delete it when they were done. I believe they learned this particular trick from al-Qaeda. It satisfied the letter of the policy — after all, nobody ever SENT an email with any confidential material attached to it — and it got around the firewall blocks and restrictions.
You see that chasm? That gulf between ‘playing by the rules’ and ‘getting caught’? In there is a rich, thriving ecosystem of free-tier AWS accounts, Dropbox folders full of Excel spreadsheets and SSH proxies running on port 53 so the firewall thinks they’re DNS queries.
It would terrify you how much of your operating revenue comes out of that chasm.
5. The Shibboleth
Once upon a time, there was The Password. Being entrusted with The Password was a rite of passage. The Password was the nuclear launch codes, the keys to the city. Maybe it was the root password to the production web server. Maybe it was the sa password to the main database stack, or the master account password for the COBOL mainframe that handled all the financial records.
Of course, in these enlightened times, we have much, much better ways to restrict access to our systems. Federated authentication, PEM keys and one-time codes and 2FA. Single sign-on, cross linked to Sarbanes-Oxley auditing mechanisms so sensitive that if you so much as exhale whilst you’re logged in to production, it’ll analyse your breath content and record the fact that you had a beer with lunch, just in case they ever need to throw you under a bus in court.
Naturally, when you rolled out your new GDPR-compliant single sign-on, you changed the password. Of course you did. And then, when every single piece of software in your organisation went into a screaming panic, you immediately changed it back. And somewhere, there’s a backlog of the applications that need to be updated before you can change The Password. You’ve done the easy ones, obviously. But you haven’t got around yet to remoting into the VM where the Doctor Gonzo (qv) resides, and even if you could, you’ve no idea what algorithm the developers used to encrypt the connection string before pasting it into the INI file that’s eventually got transplanted into the Windows registry. And besides, you’re going to be replacing the Doctor Gonzo any day now, so you can change the password once that’s done.
The shibboleth is a powerful incentive to ensure that your tech staff leave on good terms. They know full well that if they give you any reason to doubt their integrity and trustworthiness following their departure, it’ll be a lot cheaper and easier just to have them killed than it will be to change the master password.
6. The Masquerade Column
This one’s a doozy. Somewhere in your organisation there’s a text column in a database. It was designed for your staff to make notes. It’s probably called something like ‘Comment’ or ‘Description’. 250+ characters of beautiful, unvalidated text. And, for many years, that’s exactly what it was used for… until that one fateful afternoon, when a couple of developers were sat around trying to plan a feature. And one of them said ‘can we add a field to the database to store the order type?’ And somebody else said ‘we COULD — but then we’d need to update the stored procedures and regression test any apps that are using column indexes and… it’ll turn a three-point ticket into a couple of weeks of work’.
At which point some bright spark says ‘hey, what if we use the Comment field? We can parse it, and if there’s a pipe character in there, anything after the pipe indicates the order type. And we’ll just tell the sales team not to edit anything in there that looks funny.’
Of course, it’s not always a pipe. Sometimes it’s a comma-separated list of product IDs, that your code knows to split, parse, translate back into orders and use those to populate the invoices. Or maybe you decided a comma was too obvious so you used a backtick instead — clever, huh? Sometimes, if you’re REALLY smart, you’ll use a newline character because you know full well that the UI element that’s bound to the field is a single-line textbox and so your users won’t see the hidden data you’ve stashed on line 2.
Note that if you’ve gone as far as storing actual JSON or XML in a free text field, that’s not really a masquerade any more, that’s just creative repurposing. The whole point of the masquerade is that your code has to run half-a-dozen different parsing and validation routines on that little piece of text before deciding whether it’s doing anything special or not.
Back in the glorious days of the first dotcom bubble, I once proposed using the description field on a table to store a SQL statement that needed to be generated when an order was raised, but not actually executed until the order was confirmed. I may have used the phrase ‘continuation passing’ to make it sound impressive. Fortunately the client pulled the plug on the entire project before it went anywhere.
7. The Folly
This is probably linked from your homepage. It definitely features prominently in your sales literature. Maybe you even ran a campaign about it. It’s a massively complex feature that was designed, built, shipped… and in the five years since it went live, it’s been used by exactly nine people. The folly is normally built as a sweetener. Like the senator who won’t sign off on a nuclear power bill unless they put a clause in it about reducing the excise duty on liquor sold in golf clubs, it was some weirdly specific scenario that one of your key stakeholders was absolutely hellbent on pushing through to production. Eventually, your team gives up trying to sell them on the idea of an MVP, and builds the whole damn thing just to shut them up.
To be a genuine folly, the system in question needs to be so inextricably wired into the rest of your software platform that shutting it down would be a major undertaking in its own right, and so it quietly purrs along in production, using up a couple of hundred bucks a month of cloud hosting and not really hurting anybody.
8. The Slow Loris
The slow loris is a nocturnal primate that’s indigenous to south-east Asia. Slow lorises have big round eyes and curious furry faces, and grow to about 30 cm long. They’re small, they’re cute, they’re not remotely threatening. And if you touch them, they can literally kill you.
Does that remind you of anything in your software? Sure it does. You know. That one innocent-looking database table that if somebody adds a row to it the entire website crashes. The button in your intranet dashboard that says something like ‘download CSV’ and if anybody clicks it the main database server instantly hits 100% CPU and stops accepting any more connections for a good twenty minutes or so. The DLL that has to be installed into C:\Users\Temp\ (because Reasons) and if it’s not there it’s a toss-up as to whether the phone starts ringing before the website goes down, or immediately afterwards.
That file that can’t possibly be doing anything? Probably best not to touch it. No matter how cute and fluffy it might look.
9. The Phantasm
Somewhere in your organisation, there’s a piece of critical physical infrastructure that is so well hidden it’s indistinguishable from magic. We call this the phantasm. And a true phantasm always starts out with somebody trying to make things look nice.
Back in the days of wired networks, a really good phantasm was hard to accomplish — you could always follow the wires. But in these days of wireless networks, it’s the easiest thing in the world to stick a wi-fi access point up above a ceiling tile somewhere and forget about it. Ten years later, your successors will thank you when they get asked to find out why the internet has stopped working. After furiously arguing for three or four hours that the internet NEVER worked because there’s clearly no wi-fi points anywhere on that floor, they end up ripping the entire ceiling down in a desperate attempt to work out what’s going on — and find a dust-bunny the size of a basketball with the last few inches of a wifi antenna forlornly poking out of it.
10. The Paradox
The paradox is a rare and beautiful artefact in modern software systems. It’s something that can’t possibly exist according to its own rules, and yet it does. The classic paradox is a table full of customers with no email address, in a system that (a) defines a customer as invalid unless the email address is populated, and (b) rejects any update to objects that are not valid. This can lead to HOURS of fun chasing your own tail up and down the aggregate graph trying to work out why you’ve managed to get seventeen validation errors without changing a single value.
There are other paradoxes as well. There’s the server that appears to be responding to pings despite the fact you’ve switched it off, removed the power supply and disconnected all the hard drives. The misconfigured IAM security policy that eventually turns out to serve absolutely no purpose other than preventing it from knowing about itself. The dashboard that’s reporting 100% availability because every single other system in the organisation has failed, including the systems that are supposed to report downtime to the dashboard aggregator.
A really good paradox will vanish without trace when you begin investigating it, like some sort of quantum phenomenon that can only exist until an observer attempts to measure it. This shouldn’t be confused with a Heisenbug, which is a bug that only becomes invisible whilst actively being observed. No, the paradox doesn’t just hide — it vanishes, leaving you sat in a retrospective meeting insisting that you really saw it whilst your team-mates look at you with raised eyebrows and wonder whether it’s time you took some holiday. The experienced paradox hunter doesn’t even run a database query until they’ve loaded Camtasia with silver bullets and started a screen recording.
Survival Tips for Aspiring Code Archaeologists
As you explore the canyons and catacombs of an unfamiliar codebase, keep your eyes peeled, for these are just a few of the weird and wonderful creatures you’ll find lurking in the dark places. You may seek to understand them. You may even seek to catalogue a few of your own — but be wary as you study their ways, for to familiarise yourself with these beasts is to walk a narrow and dangerous path. For as the great systems architect Nietzsche once said:
“Beware that, when fighting monsters, you yourself do not become a monster… for when you gaze long into the abyss, the abyss gazes also into you, and when you truly understand the legacy codebase, only then will you realise you yourself have become part of the legacy.”
Monday, 2 July 2018
Around ten years ago, a bunch of developers got together in London under the banner of ‘alt dot net’ to talk about code, the universe and everything. Ten years doesn’t sound like much, but it’s actually quite amazing to look back on how much has changed. Back at that first alt.NET unconference, a handful of people in the room had a first-generation iPhone. I don’t think anybody had an Android device yet. Stack Overflow didn’t exist. Most of us weren’t on Twitter yet — In fact, my first-ever blog post was a writeup of that first alt.NET UK unconference and I didn’t join Twitter until three months later…
Most .NET developers in 2008 were still running Windows XP, apart from the unlucky few who’d upgraded to Vista and couldn’t work how to go back. Visual Studio 2008 was the new shiny. Lots of shops were still hosting on Windows 2003 or even Windows 2000 Server. That first wave of alt.NET was a bunch of developers who found C# and Visual Studio to be a powerful and productive platform for building software, but a platform that came bundled with a particular set of ‘best practises’ that weren’t necessarily the way we wanted to be working. The .NET community, such as it was, was heavily concentrated around Microsoft’s own conference and events, and there was very little discussion in that community around ideas like extreme programming, agile, model-view-controller unit testing, browser automation, dependency injection… you know. Ideas that are widely acknowledged here in 2018 to be, if not magic bullets, then well worth knowing and understanding how they might apply to the work you’re doing.
And now here we are, ten years later, on a glorious sunny day in Birmingham. Twenty-odd developers getting together on a Saturday under that same Alt.NET banner to talk about… well, whatever we want to talk about. That’s the beauty of the unconference format. The attendees create the schedule on the day. There’s no prepared presentations, no speakers, no keynotes or programme committee — you come along, you bring your questions and ideas and the things you want to talk about, and we see what happens.
An hour of spirited discussion and a LOT of post-it notes later, and we had an agenda — and what a wonderful range of topics:
One of the great things about the unconference format is that you’ll end up with a bunch of curious people in a room wanting to learn about something… but ‘cos there’s no speakers and no ‘experts’, we’ll just fire up a laptop, find a quickstart or a ‘hello world’ tutorial or something, and start hacking on it. So we started off the day with a mob programming session on Blazor — one of the gang had a half-finished experimental chatbot they’d been working on, so we got that up on a big screen and played around with it for an hour until we had asynchronous callbacks and model binding working.
The next session I went to was one I’d proposed about quantum computing — I saw an intro session from Anita Ramanan and Frances Tibble at DDD13 in Reading last week, and I’ve been itching to download Q# and try it out… and so, in the absence of any quantum computing experts to tell us the answers, we had another group hack session with a laptop plugged into a big screen. What I found really remarkable about this session was how easily we got the whole thing up and running. I’m running the .NET SDK on macOS, using VS Code and JetBrains Rider, and it only took a few minutes to download the quantum computing preview, install it, fire up a ‘hello world’ app (or the Q# equivalent thereof) and start playing around with simulating quantum entanglement.
Next up was a freeform discussion all about command line tooling — gulp, grunt, yeoman, yarn, bower, npm, the dot net cli templating system — how did we get here, what did we like, and why the hell does running ‘dotnet new mvc’ drop a bunch of .something.bower files into your repository? We talked a lot about boilerplate code — about the days when File > New > Project would drop a few hundred lines of .designer.cs and .csproj files into your solution, which was never intended for human consumption, but you could guarantee that eventually SOMETHING would go wrong with one of those files and you’d have to roll your sleeves up and work out how to fix it. And we talked about how for people that have experienced this, Microsoft’s move towards a far more minimalist project file syntax is a Good Thing — but that alongside that, there’s a whole bunch of complexity that we’ve adopted wholesale from the npm ecosystem for managing web assets and front-end dependencies. We talked a bit about Andrey Taritsyn’s BundleTransformer, and the idea of treating SASS, SCSS, TypeScript et al as part of your solution and relying on the .NET pipeline to compile them at request time, and how the npm/node mindset has encouraged developers to regard these sorts of concerns as compile-time rather than runtime operations. The consensus — amongst our small and opinionated but by no means authoritative group — was that there’s still a pretty steep learning curve for the old-school .NET developer trying to understand modern web build tooling, but that it’s generally all getting a lot better.
I also made an honourable mention of the latest .NET CLI tooling by describing how an hour previously I’d installed the Quantum Computing SDK on macOS and got a couple of demos up and running, without having to reboot into Windows or fire up Visual Studio, and how that was actually quite awesome.
We broke for lunch — which was entirely thanks to Ian Russell, who I gather ended up not only organizing but also subsidising quite a lot of the event. For which we are all eternally grateful, but if there’s anyone out there whose company might be interested in supporting this kind of event, here’s a bit of advice for you. Community groups and events like this can make a few hundred pounds go a long, long way, but if your corporate sponsorship process means filling out forms, signing waivers and NDAs, submitting corporate investment opportunity proposals… the sort of people who run events like this are unlikely to appreciate your ‘support’. Work out how to support this kind of event with £500 out of petty cash, or offer to pick up the bill for lunch or something, and we’ll just say nice things about you and tell everyone on Twitter how grateful we are. You can get a lot of good will and positive buzz (not to mention sandwiches!) for less than it costs to hire a .NET contractor for one day — but when it comes to this kind of thing, please remember that your accounting procedures are your problem and not anybody else’s.
But I digress. Lunch was delicious and Ian, next time you’re down our way, the London .NET gang are taking you out for dinner to say thank you.
And on to the afternoon. First up was a session about functional programming — what is it, why does it matter, and how do you do it in C#? Partly inspired by some of Mike Hadlow’s blog posts about refactoring object-oriented C# into a more functional style, it was a great discussion; with some folks in the room who have very much embraced the functional paradigm, some folks who have spent years dabbling in F# but still prefer C# for everyday development, and some folks who haven’t really encountered functional programming but have heard a lot about it and would love to know why it sounds so important. Ian Cooper shared the ‘devil’s argument against F#’ — “I’m not sure I agree with all of this, but I know it well and I think it’s useful to share it” — about how pure functional programming is never going to cross the chasm from the bleeding edge to mainstream adoption; about how a lot of the ‘textbook’ benefits of functional programming are that it scales easily across multiple cores but that as an industry we’ve very much embraced the idea of scaling using services and containers rather than building monolithic applications that scale effectively on high-performance hardware. I pointed out that this notion of ‘scaling’ is very much rooted in ideas around scaling straightforward CRUD processes to cope with massive volumes of users — the predominant computational model of high-traffic web applications — and that there’s still lots of challenges around simulation, video rendering, gaming and machine learning where scaling a local process across multiple cores is still the most compelling route to improved performance. We also briefly discussed the dynamic that exists between the F# community and the rest of the .NET ecosystem (TL;DR: it’s mostly very friendly and lovely, but there’s still a perception that the functional community can be a bit elitist when it comes to sharing ideas with their object-oriented cousins).
There were also several recommendations to check out Scott Wlaschin’s book ‘Domain Modelling Made Functional’, both for an excellent overview of domain-driven design covered in the first few chapters, and for some worthwhile insight into the value of using functional programming patterns in your domain models.
Next was a session that ended up on the board as a combination of ‘diversity’ and ‘attracting new speakers’ — but ended up running a broad gamut from conferences and community, to speaker tips, suggestions and ideas for encouraging more people to get involved in what we do. I’m the first to admit that .NET has a massive problem with diversity — the vast majority of .NET developers in the UK are middle-aged white guys, and whilst there’s many brilliant speakers, engineers and evangelists on our platform who don’t conform to that particular stereotype, if you turn up to a .NET user group pretty much anywhere in the UK, it’s going to be overwhelmingly white males of a certain age. We talked about this at some length, including the observation that a lot of the people who are still passionate about .NET as a platform are people who have been here since the beginning, since the days of Visual Studio .NET and C# 1.0, and there’s not a whole lot of people who have made a conscious decision to embrace .NET as a development platform who didn’t already have some kind of investment in the Microsoft/Windows/SQL Server platform. The session convened around a question — how do we get more people looking at .NET as a development platform? It’s free. It’s open source. It’s cross-platform. It runs on macOS, Linux and Windows, it’s got excellent hosting and infrastructure support from multiple cloud providers… so why aren’t we seeing more interest in it? (When we figure out the answer, I’ll let you know. Promise!)
Finally, we wrapped up with a park bench discussion about “The .NET Renaissance — Where Are We?”. Following on from a series of blog posts and conference talks (and at least one DotNetRocks podcast) that various members of the .NET community have shared over the last eighteen months or so, and overlapping a lot with some of the questions and ideas from the session on diversity and inclusivity, we talked about .NET — past, present and future. Ian Cooper shared some slides, graphs and stats based on various metrics — recruitment websites, TIOBE — along with a healthy disclaimer that all programming language metrics were probably wrong and there’s “lies, damned lies, and percentages”. We talked about how Unity is creating a path into programming for a lot of first-time developers who are interesting in creating games and immersive 3D environments, and how the increasing interest in devices like GearVR and Hololens is only going to encourage this. Jim Bennett (who I should point out was here sharing his own opinions and not any official Microsoft position) spoke about how the diversity of platforms and runtimes almost guarantees long-term investment in C# as compared to platforms like Flutter/Dart, which are still tightly coupled to specific hardware and OS platforms. .NET has got some absolutely first-class tooling support. It runs on a huge number of devices — not just Windows, Linux & macOS, but thanks to Xamarin it’s now running on Android, iOS, Samsung’s Tizen platform (yeah, did you know your Samsung smart TV can run .NET Core applications?) — and with companies like AirBnB talking openly about the challenges they’ve had trying to use frameworks like React Native to deliver cross-platform solutions across web and mobile, it’s clear that there’s still a big unsolved problem around building cross-platform consumer apps, and that .NET Core and Xamarin Forms is working really hard to offer a compelling solution to that problem that could turn out to be the incentive that attracts a new generation of developers and startups onto the platform.
We took a few moments to plug a couple of other .NET events that are coming up in the UK over the next few months — the ProgNET conference and tutorials that we’re running at Skills Matter in September, and DDD East Anglia, which is another free community event that’s taking place in Cambridge in September.
And then, after eight hours of inspiring conversations and insightful observations, we went to the pub to reflect on how the day had gone. One thing that stood out was that, asking people how they’d heard about the event, there was very little correlation. Many of the people who came along today heard about it through word of mouth, and despite promoting the event widely on Twitter, email and social media, we probably knew a few dozen people between us who would have come along if they’d known it was happening. Asking people to give up a Saturday to come along to an unstructured conference is a bit of a big ask, sure — but actually, I think it’s one of the things that makes the unconference format work well. If you ran an event like that on a Friday, you’d probably get a lot more signups from people who persuaded their boss to give them a day off to go to a free conference… but you’d probably also get a lot more people turning up late, sitting quietly without really contributing anything, and I daresay sloping off the pub at lunchtime and not coming back. Most of the people who came along today weren’t based in Birmingham, and even though the event itself was free, somebody who gives up a day of their time and pays out of their own pocket to travel to an event like Alt.NET is exactly the kind of person you want involved.
One thing was overwhelmingly evident, though. If you’d taken today’s agenda back in time to 2008 and showed it to the people who came along to that first Alt.NET UK event, they wouldn’t have understood half of it (“coober-netties? What the hell is coober-netties?”) — and there’s no way they’d have believed the other half. C# running on an iPhone? HA! ASP.NET on Linux? HAAA! And when you sat down an hour later and worked out how install a quantum computing simulator on macOS and then hack together a quantum entanglement demo using a free open-source code editor with support for an experiment language for writing quantum algorithms, they would not have believed for a second that Microsoft and .NET was the driving force behind all those amazing innovations.
It was one of the most positive and inspiring events I’ve been to in a while — and when I think of how many excellent conferences and meetups I’ve been to in the last few months, that’s really saying something. Huge thanks to Ian Russell and Dave Evans for putting it together, to ImpactHub for the venue, but most of all to everyone who came along. An event like this is only as good as the people who show up, and today was absolutely awesome. See you all at the next one.
Oh, and the session on ‘are microservices dead?’ Yeah. Nobody turned up. I guess that makes it official. RIP microservices. It’s been… emotional :)
Various things that were shown, shared, discussed or mentioned:
- The Blazor project site at https://blazor.net/
- Layla Porter’s experimental Blazor chatbot on GitHub (work in progress and VERY experimental — but we had fun playing around with the code!)
- The Microsoft Quantum Computing SDK
- The Hitchhikers Guide to Quantum Computing — a blog written by Anita Ramanan and Frances Tibble at Microsoft Research, all about Q# and quantum computing
- Scott Hanselman’s post about dotnet new templates
- Getting started with Samsung Tizen
- Scott Wlaschin’s book ‘Domain Modelling Made Functional’
- Impact Hub Birmingham, the co-working space that hosted us
- AirBnB’s series of posts about their experience using React Native for cross-platform development
- ProgNET 2018 — the ninth annual progressive .NET conference hosted by Skills Matter, and organized by many of the same people who’ve been involved with the alt.NET movement since those first UK alt.NET events way back in 2008.
- DDD East Anglia — which is currently open for sessions, so if you fancy going along and doing a talk, now’s the time to submit something!
Tuesday, 9 January 2018
Over the past couple of years, I’ve spoken at quite a few conferences in Russia, Ukraine and Belarus – DotNext in Saint-Petersburg and Moscow, BuildStuff in Kyiv and Odessa, and .NET Summit in Minsk. Later this year, I’ll be heading back to Saint-Petersburg for DotNext, and travelling to Novosibirsk in Siberia for CodeFest. All these events have open calls for papers, and if you’ve ever wanted to visit these places, tech conferences are a great way to do it. Lots of people have asked me what’s involved and whether it’s something they should look into - so here’s what I did, how it all worked for me, and some tips that might be useful.
Please remember I’m not an immigration lawyer. This is all based on my own experience, and I’m a straight white British cis male with no special dietary or medical requirements who is quite happy travelling alone in strange places. Laws, customs and cultures can vary wildly, so do your own research if you’re concerned about anything.
First up – yes, do it! I’ve had fantastic experiences on all these trips. The conferences I’ve spoken at have been first-class, professional events, with excellent facilities and really attentive, engaged audiences. Travelling in a country where you can’t even read the alphabet can be a bit of a culture shock at first, but I’ve had no problems navigating hotels, public transport and conference venues as an English speaker. Apps like Uber are great for this: being able to call a taxi and see exactly where you’re going and how much it’ll cost is hugely reassuring when you’re somewhere unfamiliar and can’t speak the language.
If you’re up for a challenge, have a go at learning to read the Cyrillic alphabet. The Russian language is hard, but you’ll find lots of the words on things like street signs and restaurant menus are familiar words, once you can read the language they’re written in. Being able to recognise things like Банка (banka – a bank), Гамбургер (hamburger) and Феттучини (fettucine) will get you a long way. (Russian, Ukrainian, and Belarusian are distinct languages with some broad similarities, but being able to recognise familiar English words in Cyrillic will stand you in good stead throughout the region.)
Visiting Ukraine and Belarus
If you’re a British passport holder, visiting Ukraine is easy; you can enter Ukraine without a visa for up to 90 days. Belarus has an interesting visa waiver: British citizens can enter without a visa as long as they stay less than five days and they enter and leave via Minsk international Airport. You need to show proof of medical insurance to clear passport control (and the authorities don’t consider a PDF on your phone to be documentary evidence). If you don’t have insurance, you can purchase it at the airport. It’s priced in euros, and you can pay in cash in Belarusian rubles, Russian rubles or “freely convertible currency” – I paid in euro coins without any problems.
Visiting Russia is more complicated. British citizens will need a visa to enter Russia, which means you’ll need to apply through VFS Global, the agency that handles Russian visa applications in the UK. (Note that Russian embassies in other countries often won’t process visa applications for British nationals living abroad – if you’re a Brit living elsewhere in the EU you’ll probably need to travel to London to apply for and collect your visa.) There’s a dizzying array of visa types – tourist, private, student, work, business – and you’ll find various opinions online about what kind of visa you need if you’re speaking at a technical conference. Given this ambiguity, I’ve always insisted on a business visa for my trips to Russia; I’ve never been asked anything on arrival other than when I’ll be leaving, but your experience may differ.
Here’s how it works. The whole process takes about two months.
- Ask the conference organisers to prepare your visa invitation
- Fill out the form on the VFS Global website
- Wait for confirmation that your invitation has been issued
- Go to the VFS Global office in London with your passport, form and documents
- Submit your application
- Wait 5 days (or 24 hours if you've paid for overnight processing)
- Go and pick up your passport and visa
- Go to Russia!
Your hosts (normally the company organising the conference) will issue you with a visa invitation. This can take a while, particularly if there are public holidays in Russia; they won’t do it more than a month in advance so you need to time everything quite carefully – especially if you have other travel commitments for which you’ll need your passport. The invitation will be sent by telex from the Russian Ministry of Foreign Affairs, to the Russian consulate in London. Your first application must be for a single-entry visa; if you’ve already done one trip and it looks like you’ll be doing a lot more you can ask them to prepare an invitation for a multi-entry visa valid for one year.
Meanwhile, take a look at the online application form on the VFS Global website. You can’t submit the form electronically – once you’ve finished filling it in, it’ll produce a PDF that you need to print. It asks for things like your parents’ dates and places of birth, details of every country you’ve visited in the last 10 years, information about your marital status (and, apparently, current contact information for your former spouse if you’re divorced or separated). It might take a while for you to dig out all the details you’ll need, so make sure you look at it well in advance. You won’t be able to complete your application until you’ve got your invitation, but you can make a start and save your progress.
Once your invitation has been issued, your hosts (or their travel agent) will send you an email with a ‘telex reference’ on it, which you you’ll need in order to complete the visa application form. Take the printed form, along with your passport and supporting documents, to the VFS Global application office in Gee Street in London, just north of Barbican tube station. There is a PDF on their website that lists the supporting documents you’ll need – passport, application form, passport photo, invitation (telex), introductory letter, and certified bank statements if you’re self-employed. I’ve never been asked to show the introductory letter or the bank statements, but take them with you anyway, just in case.
The VFS Global office is open 08:30-15:00 Monday to Friday, but if you turn up to submit a business visa application between 12:00 and 14:00 they’ll ask you to come back later – they’ll need to phone the Russian consulate to confirm receipt of your telex before they’ll accept your application, and they can’t do this between 12:00 and 14:00 because the consulate closes for lunch.
They’ll take your passport and all your paperwork. You’ll get fingerprinted, and pay the visa application fee and service charge. Cash or credit/debit card is fine, but they don’t take Amex. It’s about £120 total for a single-entry visa ready in 5 working days; if you’re in a hurry, they have an express overnight service which costs more. They’ll give you an application receipt. Don’t lose it – you can’t get your passport back without it.
When your visa’s ready, you’ll have to go back to pick it up – the office is open for collections between 16:00 and 17:30. Check that your visa details are all correct – it’ll be a full-page colour sheet stuck in your passport. One thing I’ve noticed is that names may not be transliterated into Russian consistently – I’ve got two visas in my passport right now; one says I’m Дилан Битти and the other one says I’m Дилан Бети (that’s roughly ‘bitti’ and ‘beti’ written in Cyrillic), but this doesn’t appear to be a problem.
That’s pretty much it. When you arrive in Russia you’ll be given an immigration card at passport control, which you’ll need to show when you check into your hotel to prove you’re in the country legally, and which you’ll need to go through passport control when you leave. Take a picture of this card on your phone (or ask the hotel to photocopy it for you), so you can keep the original with you and leave a copy in the safe in your hotel. The UK foreign office says you must carry your original passport with you at all times in Russia, and can be fined if you don’t produce it when asked. I’ve never been asked to produce mine, but I keep my passport, visa and immigration card on me, with printed photocopies of them all in the hotel room safe and digital copies in Dropbox, just in case.
Most hotels will change major foreign currencies into local currency. There are also foreign exchange bureaux everywhere, but I’ve always changed money in my hotel or used an ATM. If you’re planning to change money, carry cash in a combination of euros and US dollars, since these are most widely accepted by foreign exchange bureaux. It’s easy enough to get Russian rubles from a UK foreign exchange bureau before you leave for your trip, but you probably won’t be able to get Ukrainian hryvnia or Belarusian rubles. There are also ATMs everywhere and most restaurants will take Visa and Mastercard. If you’re using something like a Monzo card or other prepaid payment card, remember you may not have roaming data on your phone so top it up before you leave the hotel.
Roaming data outside the EU is seriously expensive. It’s a lot cheaper than it was a few years ago – during my first visit to Ukraine in November 2015, roaming data was £8/MB – but it’s still not cheap; in Russia, EE currently charges £7.00 for 100Mb, valid for 24 hours. Public wifi is widely available; in Kyiv it’s pretty ubiquitous and often completely unsecured (although you’ll need to know how to accept the terms and conditions in Ukrainian!) but in Russia and Belarus you’ll often find you need a local mobile phone number to register on public wifi spots. Make sure your phone’s unlocked before you go, pick up a local pay-as-you-go SIM card, and ask one of the conference organisers or a friendly local to help you activate and register it (remember that all the confirmation messages from the phone network will be in Russian or Ukrainian).
It’s also worth caching Google Maps offline using the “ok maps” feature, and downloading the Google Translate app and the language files for Russian to your phone so that even if you’re not online you’ll be able to navigate and translate some basic phrases.
And finally – don’t forget to actually see the place! It’s all too easy to travel halfway around the world for a conference and never see anything except the inside of the Radisson Blu, so if the conference organisers have arranged a tour of the city or any excursions, go along – you’ll get to see some really interesting things. Or head out on your own. Moscow, Saint-Petersburg, and Kyiv have fast, efficient metro networks, with stations and maps in English as well as Russian/Ukrainian. The metro is great for travelling around without having to talk to anybody – buy tickets at a machine, use the automated barriers, watch the locals when it comes to navigating around the stations and do what they do. There are metal detectors everywhere, which go off constantly. It looks like they’re being ignored but apparently they give the police probable cause to search anybody they don’t like the look of - personally I’ve never had any problems at all.
The great thing about being at a tech conference is that many of the attendees will be locals who know the city and will be perfectly happy to take you their favourite bar or a good place for dinner or some live music or whatever you fancy doing with your spare time. Enjoy the conversations, soak up the culture, try the local food, and remember not to stay up drinking vodka until 2am when your flight is at 06:30... unless you really, really want to.
Sounds like fun?
If all that’s piqued your interest... awesome! Here are a few events that are accepting papers at the moment.
- DotNext, Saint Petersburg, Russia, 22-23 April (CFP)
- .NET Summit, Minsk, Belarus, 2-3 March (CFP)
- CodeFest, Novosibirsk, Russia, 31 March – 1st April (CFP)
Tuesday, 5 December 2017
If you work in software – or even if you don’t – it’s likely that, at some point, you’ll find yourself working with a team who are completely unfamiliar with your systems. A management consultancy, a development partner, a new supplier. A team of smart, capable people who are hoping to work with you to deliver something, whether that’s process improvements or a reduction in costs or some shiny new product.
A common pattern here is that, at the start of the engagement, they’ll appoint some business analysts to spend a whole lot of time talking with people from your organisation to get a better idea of what it is you do. They sometimes call this ‘gathering requirements’. You’ll know it’s happening when you get half-a-dozen invitations to four-hour ‘workshops’ from somebody you’ve never met, normally with a note saying something like ‘Hey everyone! Let’s get these in the diary!’
Now, there’s a problem here. Asking people what’s happening is almost never the best way to find out what’s actually happening. You don’t get the truth, you get a version of the truth that’s been twisted through a series of individual perspectives, and when you’re using these interviews to develop your understanding of an unfamiliar system, this can lead to an incredibly distorted view of the organisation. Components and assemblies aren’t ranked according to cost, or risk, or complexity. They’re ranked according to how many hours a day somebody spends dealing with them. And when you consider that in these days of scripted infrastructure and continuous deployment, a decent engineer can provision an entire virtual hosting environment in the time it takes to deal with one customer service phone call, what you end up with is a view of your organisation that ranks ‘phone calls’ equal to ‘hosting environment’ in terms of their strategic value and significance.
When you factor in the Dunning-Kruger effect, the errors and omissions, the inevitable confusion about naming things, and the understandable desire to manage complexity by introducing abstractions, you can end up with a very pretty and incredibly misleading diagram that claims to be a ‘high-level view’ of an organization’s systems.
There’s a wonderful example of this in neurology – a thing called the ‘cortical homunculus’; a distorted representation of the human body where the various parts of the body are magnified based on the density of nerve endings found therein. Looks like this:
It’s recognisably human, sure. But it’s a grotesque distortion of what a human being actually looks like – brilliant for demonstrating neurology, but if you used it as a model when designing clothes or furniture your customers would be in for one hell of a shock. And we know it’s grotesque, because we know what human beings are supposed to look like – in fact, it’s the difference between the ordinary and the grotesque that makes these cortical homunculi interesting.
The problem with software is that it’s made out of invisible electric magic, and the only way to see it at all is to rely on some incredibly coarse abstractions and some very rudimentary visualisation tools.
Imagine, for one second, that we’ve hired some consultants to help us design an aircraft. They send over some business analysts, and book some time with the ‘domain experts’ to talk over the capabilities of the existing system and gather requirements. The experts, of course, being the pilots and cabin crew – which, for a Boeing 747 like Ed Force One, is three flight crew and somewhere around dozen cabin attendants. They spend a couple of very long days interviewing all these experts; maybe they even have the opportunity to watch them at work in the course of a typical flight.
And then they come up with this: the high-level architectural diagram of a long-range passenger airliner:
Now, to an average passenger, that probably looks like a pretty reasonable representation of the major systems of a Boeing 747. Right? Take a look. Can you, off the top of your head, highlight the things that are factually incorrect?
That’s why this diagram is dangerous. It’s nicely laid out and easy to understand. It looks good. It inspires trust… and it’s a grotesque misrepresentation of what’s actually happening. Like the cortical homunculus, it’s not actually wrong, but it’s horribly distorted. In this case, the systems associated with the cabin attendants are massively overrepresented - because there’s 12 of them, as opposed to three flight crew – so 400% more workshop time and 400% more anecdotal insight. The top-level domains – flight deck, first class, economy class – are based on a valid but profoundly misleading perspective on the systems architecture of an airliner. The avionics and flight control systems are reduced to a footnote based on three days of interviews with the pilots, somebody with a bit of technical knowledge has connected the engines to the pedals (like a car, right?) and the rudder to the steering wheel (yes, a 747 does have a steering wheel), the wings are connected to the engines as a sort of afterthought…
Now, when the project is something tangible – like an office building or a bridge or an airliner, it won’t take long at all before somebody goes ‘um… I hate to say it, but this is wrong. This is so utterly totally wrong I can’t even begin to explain how wrong it is.’ Even the most inexperienced project manager will probably smell a rat when they notice that 20% of the budget for a new transatlantic airliner has been allocated to drinks trolleys and laminated safety cards.
But when the project is a software application – you know, a couple of million moving parts made out of invisible electronic thought-stuff that bounce around the place at the speed of light, merrily flipping bits and painting pixels and only sitting still when you catch one of them in a debugger and poke it line-by-line to see what it does – that moment of clarity might never happen. We can’t see software. We don’t know what it’s supposed to look like. We don’t have any instinct for distinguishing the ordinary from the grotesque. We rely on lines and rectangles, and we sort of assume that the person drawing the diagram knew what they were doing and that somebody else is looking after all the intricate detail that didn’t make it into the diagram.
And remember, nobody here has screwed up. The worst thing about these kinds of diagrams is that they’re produced by competent, honest, capable people. The organization allocates time for everybody to be involved. The stakeholders answer all the questions as honestly as they can. The consultants capture all of that detail and synthesise it into diagrams and documents, and everybody comes away with the satisfying sense of a job well done.
That’s not to say there’s no value in this process. But these kinds of diagrams are just one perspective on a system, and that’s dangerous unless you have a bunch of other perspectives to provide a basis for comparison. A conceptual model of a Boeing 747 based on running cost – suddenly the engines are a hell of a lot more important than the drinks trolley. A conceptual model based on electrical systems. Another based on manufacturing cost. Another based on air traffic control systems and airport infrastructure considerations. And yes, producing all these models takes a lot more than arranging a week of interviews with people who are already on the payroll, which is why so many projects get as far as that high-level system diagram and then start delivering things.
And why, somewhere in your system you almost certainly have the software equivalent of a hundred-million-dollar drinks trolley.
Thank you for flying Analysis Airways.