C++ Pointers and References: Quick Reference

After watching a few hours of an Intro to C++ series on Pluralsight, this is a succinct aide-memoir for myself for C++ pointers and references.

Impersonation in .NET

Recently, I had need to programmatically impersonate a Windows account which has elevated permissions. In my case, only one step in a multi-step process required the extended permissions so the impersonation was temporary.

To do so in .NET a  P/Invoke call into unmanaged code is required. The detail of which can be found here: WindowsIdentity.Impersonate

A call into unmanaged code is made in order to retrieve a user token. The token is then passed to a framework class which facilitates the impersonation.

I've written a small class which wraps this functionality and thought it may be of use to other people:

Understanding Streams (in .NET) #2

In Part 1 we looked at streams from a conceptual point of view. We learnt that streams are an abstraction over moving data from point A to point B. A very simple example of reading from a stream can be used to demonstrate this:

The GetStream() method returns a stream object from which we can read bytes until we are told there are no more bytes to read, which is indicated by -1 being returned. The stream abstraction is already working for us here as we've no idea - and potentially don't care - about where the data is coming from: we can simply keep asking for data until we're told there's no more data to be had.

To peek behind the curtain a little here is the GetStream() method:

All I'm doing here is converting a string into an byte array where each byte is the ASCII representation of a character in the string. I then create a new MemoryStream object passing the byte array in to the constructor. Through the power of inheritance and the Liskov substitution principle we can treat the MemoryStream as it's parent Stream object.
On its own this doesn't seem terribly useful. But the data in the Stream doesn't have to be from an in-memory source. I could change the GetStream() method to the following and still read from it in the same way, even though the data now exists in a file:

I could even be reading from a stream whose bytes come over the internet:

These examples are a little contrived and not awfully useful as all I do with the byte I've read is write it out to the console and move onto the next one. That being said, bytes are the essential nature of all data, so we have an solid starting point to do more interesting things...

Understanding Streams (in .NET) #1

I'm going to attempt to explain streams - with C# as the example language - using the same tiered approach I used to explain base64 encoding previously. Caveat emptor: this series is, in part, about getting the topic straight in my head, so please don't take anything here as gospel.

Tier 1.

Current Understanding: 

You may have heard someone talk about "streaming data" or "writing to a stream" - perhaps you've even used the term(s) yourself - but you're only, at best, dimly aware of what it means.

N.B. If you have a greater understanding than the above it may make sense for you to skip over this tier.

Intro:

Moving data about is useful and we do it a lot! You requested the movement of data by asking your browser to display this website: a Blogger server somewhere has this webpage (or knows how to assemble it) and you asked for a copy of that data. Ultimately, that involved the transmission of binary digits (bits) but that's rarely the level at which anyone wishes to work. To avoid doing so we invent higher level models of abstraction to help us reason about and perform such tasks. Streams are one of these such abstractions.

Terminology & Pre(r)amble:

I completely agree that one of the two hard things in computer science is "naming thing". Two Hard Things

However... with that said, as an analogy I'm not sure a stream is the best one for thinking about this topic. It's certainly not how I think about it. The term"stream" seems to have been chosen to convey a flow of data - "river", "brook", or "creek" could equally have been used. And to that extent it has utility, however, I'm not sure its explanatory power holds out as one explores the subject further.

I've occasionally thought a more instructive way of thinking about reading from a stream would be drinking from an unseen cup via a straw. Here, you are sucking up liquid and don't know how much is left until at some point you go to suck up a mouthful and there's no liquid left. This is how reading from a stream works: you don't how much data there is to be read until you go to get the next chunk of data and there is none. Strictly speaking, this isn't always the case - we'll cover that later.

The term "stream" is both a noun and a verb in computing: you can have "a stream" of data; I can "stream data to you"; you might be "streaming data from me".

Why should I care?

Streaming, at it's most fundamental, is about moving data from one place to another; streaming is taking data which exists at A and moving it to B. It's a concept common to all programming languages, and in computing more widely, so understanding it has broad utility.

So, if you want to move data about as part of your application it may well help to know about streams!

PostgreSQL: Script to Tear Down and Recreate Database

I've used this as either a either PowerShell or Bash script when in a development environment. You'll need the postgres user's password. The .sql file is the file I keep in order to be able to generate the structure of my database (and seed it) in an empty database.

It connects as the postgres user to the postgres database, drops the specified database, if it exists, creates the new database, connects to the new database, and executes the schema & seed SQL file.

The Zen of Python - Programming Aphorisms

I was linked to the below Zen of Python today. And although Python is in the name the aphorisms are good for all languages. Simplicity, Explicitness and Readability are hard to achieve but pay dividends when implemented.

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

https://www.python.org/dev/peps/pep-0020/#id3

Visualising and Understanding Recursion

As someone who learns best visually, recursion (recursive functions in software) can be a bit of a mind-bender and I periodically have to go back and refresh my understanding of it. A great video to do so with is this:

Computerphile is a brilliant YouTube channel generally and anyone with an interest in computing should subscribe to it. 

Understanding Base64 Encoding #5

Tier 5

This tier is aimed at filling in a few gaps, showing the wider applicability of base64 encoding, and pointing to further reading.

Padding: The Trailing Equals Character

When I first looked at the characters used in base64 encoding I noticed there was a cheeky 65^th character (‘=’) sometimes appearing once or twice at the end of encoded data. It’s actually a special character used for when source binary data doesn’t divide neatly into three byte blocks. A quick example to illustrate.

Imagine I want to base64 encode the following four 8-bit bytes:

01000001 01100100 01100001 01101101

I take the first three octets:

01000001 01100100 01100001

Represent them as four sextets:

010000 010110 010001 100001

And encode using my encoding key, producing: QWRh

But now I have a lonely, final octet left to encode: 01101101

In base64 encoding it’s simply padded out with trailing zeros until we have another three octets:

01101101 00000000 00000000

And converted it to sextets as normal:

011011 010000 000000 000000

Any sextet which contains nothing but padded zeros gets represented as ‘=’.

So the rest of the encoded data becomes: bQ==.

The ‘=’ character is a bit of a courtesy and not every implementation of base64 encoding uses it; it is possible to recreate the original binary data without using ‘=’ for padding, it’s is just more explicit to include it.

Other Uses:

Base64 encoding is typically used in scenarios where representing binary data as a limited set of ASCII characters is desirable. This could be when using an 8-bit (or greater) character encoding isn’t viable, or when you wish to embed binary data in a explicitly text-based medium, or when sending non-alpha-numeric characters could be an issue.  

Attachments to emails are base64 encoded, as are the username and passwords sent for basic HTTP authentication. The specifics of why base64 encoding is used in these scenarios is beyond this series, but reading about https://en.wikipedia.org/wiki/8-bit_clean and https://en.wikipedia.org/wiki/Email_attachment gives you a good idea of why this is the case. The below quote taken from the Email Attachment Wikipedia page gives a good sense of the history:

“Originally Internet SMTP email was 7-bit ASCII text only, and attaching files was done by manually encoding 8-bit files using uuencode, BinHex or xxencode and pasting the resulting text into the body of the message.”

Further Resources:

Once you grasped the basics of base64 encoding the Wikipedia article actually becomes useful. To my mind it’s missing a Tier 1 style explanation but it otherwise quite passable.

There’s an Oracle blog post which is also good – again, if you’ve got some base knowledge to work from.

And when you want to go full nerd there’s the IETF spec!

https://en.wikipedia.org/wiki/Base64

https://blogs.oracle.com/rammenon/entry/base64_explained

https://tools.ietf.org/html/rfc4648

Understanding Base64 Encoding #4

Tier 4

For this tier I’m going to start to push the strained and sanitised analogy into the background and, hopefully, bring the hard edges of base64 encoding into focus.

First, a quick recap on what we’ve established:

• Base64 encoding is a methodology by which we can represent arbitrary binary data (an image, in our example) as a string of ASCII characters.
• The 64 characters used when base64 encoding are a subset of the full ASCII character set. In our case: A-Z, a-z, 0-9, +, and /.
• 64 characters can be neatly represented by a block of 6 bits.
• When base64 encoding, the binary source data is broken into 3 octet blocks (24 bits) which is then parsed as 4 sextet blocks (also 24 bits); 24 being the first common multiple of 8 and 6. 

And our encoding key looked like this:

So far we’ve been using a contrived example – a world with no digital communication – in an attempt to remove the contextual complexity of base64 encoding, concentrating on the essence of subject instead. But this only takes us so far. Let’s take a real world example of where base64 encoding could be used: embedding images in XML.

Occasionally, it may be useful to be able to create an XML document which contains images – not references to images stored elsewhere, but the actual images themselves. I’ve seen this kind of thing done when archiving orders in an e-commerce context: a business wishes to archive orders made over five years ago, however, it also wants some reasonable level of access to that data should a pressing need to retrieve it arise.

One approach to take could be to create an XML document for each order, one which contains a complete record of the transaction: top-level order details, items details, invoice address, delivery address, etc. All this is relatively straightforward. But the company may also decide, for completeness sake, that they wish to store a copy of the primary product images alongside the order. This causes a problem for a developer who doesn’t know about something like base64 encoding. For one who does, it’s fairly trivial. It could look something like this:

Here you have co-opted a medium which is designed to carry text to also carry binary data, although it doesn't even necessarily know it! Those characters between the image nodes are just text characters as far as the XML is concerned. But if the reader knows they're base64 encoded binary data, then the images can be retrieved.

Tier 5 will look to fill in a few of the gaps we've glossed over, briefly give a couple of other examples, and point at some further reading.

Next Understanding Base64 Encoding #5

Understanding Base64 Encoding #3

Tier 3

In Tier 2 I found myself with some binary data (a 10 x 10 pixel image) and a text-based medium (pen and paper) with which to communicate that image to another computer. The image is about a thousand bytes large and I didn’t fancy having to write down eight thousand ones and zeros in order to communicate that image. I’d decided I need to encode the raw data to save myself some pain.

My initial instinct to encode the raw data is that I’ll use a character to represent each possible byte value. This means I can reduce the characters I have to write out from 8000 to 1000. i.e. instead of having to write the byte value ‘00000000’, I could instead write ‘A’. As long as the recipient of my encoded image knows the encoding, e.g. ‘A’ = ‘00000000’, then they can decode the image. I start to write out my encoding key:

00 | 00000000 = A

01 | 00000001 = B

02 | 00000010 = C

…

24 | 00011000 = Y

25 | 00011001 = Z

26 | 00011010 = a

27 | 00011011 = b

…

50 | 00110010 = y

51 | 00110011 = z

52 | 00110100 = 0

53 | 00110101 = 1

…

61 | 00111110 = 9

However, as you might be able to see, by the time I’ve covered byte values 0 to 61 I’ve run out of standard alpha-numeric characters (A-Z, a-z and 0-9). I’m going to have to start using some less recognised characters – and/or possibly even fabricating new ones – in order to get all the way to 256 (the distinct values which can be represented by an 8-bit byte: 0 to 255). This gives me pause for thought. It feels like there’s potential for confusion if I start using arcane or made-up characters.

I stop and have a think. I’ve got 62 alphanumeric characters I’m confident any decoder can easily recognise. I also suspect I could probably be fairly confident using a handful of other characters, e.g. ‘=’, ‘!’, ‘+’, ‘:’, ‘&’, ‘/’, ‘\’, ‘%’, etc. But that doesn’t bring me anywhere near to the 256 characters I’d need for this encoding method.

While I’m ruminating on the problem a thought appears: 62, the number of easily recognised characters I have, is close to the binarily-significant number 64 – the distinct values which can be represented by 6 bits: 0 to 63 or 000000 to 111111. Perhaps I can use this? If I picked a couple of my additional characters at random, say ‘+’ and ‘/’ that would bring me up to a encoding set of 64 easily recognisable characters. I bank the thought.

Then comes the flash of inspiration! Ultimately, I’m just trying to communicate a series of ones and zeros from A to B. When thinking about those ones and zeros I’ve always naturally separated them into 8-bit bytes, but for the purpose of transmission there’s no inherent reason to do so; as long as the correct sequence of ones and zeros reaches the other end the interpretation of that data as 8-bit bytes is the receiving computer’s decision.

I start to jot down my thinking. Imagine the first 3 8-bit bytes of my 10 x 10 image are as follows:

00000010 – 0011011 – 00110100

For transmission, I could split those 24 bits any way I like. Into two bit chunks, for example:

00 – 00 – 00 – 10 – 00 – 01 – 10 - 11 – 00 – 11 – 01 – 00

Or - going back to my previous thinking! – as 6-bit chunks:

000000 – 100001 – 101100 – 110100

And with 6-bit chunks, I can use my recognisable character encoding key!

A – h – s – 0

I could send you "Ahs0" and, as long as you knew the decryption key, you could reverse the encryption and retrieve the bits.

And this is the bare bones of base64 encoding. I’ll fill in the gaps and attempt to extricate the tortured analogy from this explanation, applying the real world, in Tier 4.

Next >> Understanding Base64 Encoding #4

Understanding Base64 Encoding #2

Tier 2

If Tier 1 is about establishing the scantest familiarity with a subject – hoping to avoid looking glassy-eyed whenever it’s mentioned – then Tier 2 is about beginning to understand the topic; perhaps a cursory interest has been kindled and/or you’d like to be able to do a bit more than just identify the subject by sight.

To that end, one of the first questions I like answered when getting to grips with a new topic is “why does this thing exist?”. I’m going to begin to attempt to answer this question for base64 encoding by giving a disingenuous, rather long-winded, somewhat tortured analogy. I promise I’ll make amends in later tiers.

Imagine a strange parallel universe in which inter-computer communication has never happened. The parallel universe’s computers work in the same manner as ours, just no one ever bothered to invent the technologies which allow computers to communicate: no Internet, Bluetooth, portable digital devices – no floppy discs, CDs, DVDs, USB drives, etc. Essentially, each computer is a lonely digital island.

In this reality, if I create a super-cool bitmap image in the alternative universe’s version of MS Paint, you’d physically have to come over to my house and look at it on my screen; I have no digital means by which to transmit the data to you. To add to my misery, you live on the other side of the country and, despite my enthusiasm and entreatment for you to come visit, you’re not going decamp for the sake of one bitmap image.

So, scratching my head, I begin to think about the problem and in a fit of pique I come up with my first – and worst – solution to this problem: I’m going to write the binary code out on pieces of paper and send the code in the post to you. Every single one and zero. And then when you receive the paper full of bits you can key them all in at your end and recreate the image. Perfect!

However, I soon find, even if I only wanted to send the small 10 x 10 pixel image from Tier 1 it’s ~1000 bytes. And given there are 8 bits in a byte that’s ~8000 ones and zeros I’ll have to transcribe! I’m not so keen on this and imagine you’re even less keen about having to key 8000 binary digits in at your end. We need a shortcut.

I’m convinced the part about mailing you the code still has merit but I’m also certain that raw ones and zeros aren’t the answer. What I need is some sort of shorthand way of representing the same raw binary data; I need to encode it.

This is the essence of the problem base64 encoding looks to solve: how can a text-based medium, in our case pieces of paper, be re-purposed to effectively transmit binary data.

Tier 3 will, hopefully, begin to straighten this all out…

Next >> Understanding Base64 Encoding #3

Understanding Base64 Encoding #1

Disclaimer: I’m writing this blog post in an attempt to present a tiered approach to learning a new subject. It's also to solidify my understanding of the topic of base64 encoding as well as to act as an aide-memoire. I’m not presenting this information as infallible fact.

                                                     

Preamble: Personally, learning a new programming concept (or any complex topic for that matter) requires me to take a very particular approach if I want gain and maintain a comprehensive understanding of it, and I don’t see resources which represent and facilitate my learning process very much in evidence.

Learning for me involves moving from the general to the specific and for my sources of information to assume as little as possible while establishing context and purpose quickly. Producing this type of learning resource usually manifests in tiered levels of explanation. To my mind, Tier 1 is where the biggest shortage of good resource on a topic generally is. It should be what the opening paragraph of the Wikipedia topic strives to attain: a succinct and clear overview of the topic that someone immersed in the relevant field can read and feel more illuminated right away. Further tiers of explanation should elaborate on what previous tiers have established.

Let me try presenting the first couple of tiers for base64 encoding in the style I'm talking about.

What I assume: you have a programming background and that you’re looking to better understand base64 encoding.

Tier 1:

Okay, Tier 1 explanations might be relevant if you’ve just heard someone say “base64 encode” in a meeting and you’re thinking “I should probably have some idea what on Earth they’re talking about”; you’re googling about for five minutes to see if you can shed some light on the topic.

Wikipedia’s Base64 opening salvo is: “Base64 is a [...] binary-to-text encoding scheme that represent[s] binary data in an ASCII string format”.

This isn’t particularly illuminating on its own but there are a couple of clues in there: it’s something do with binary data being represented as ASCII characters.

Warning: rather unhelpfully, it is possible to immediately jump down the rabbit hole with base64 encoding and you may be thinking, as I was, “hang on a minute, everything eventually boils down to binary data - including ASCII characters - so that seems like a bit of a nonsense”. Or perhaps you have come across an example whereby someone is showing you how they converted a sentence (one string of characters) into base64 encoded text (another string of characters) and are thinking “what could possibly be the value in that!?”. If you’ve done either (or both) of these things, please, for the moment, put those thoughts on ice – don’t worry, I’m with you comrade, I feel your pain.

A concrete example might help. Imagine I have an 10 x 10 pixel jpeg image (some binary data) and I want to represent it (for some ungodly reason) as ASCII characters. Up steps base64 encoding. In fact, here is a base64 encoded 10 x 10 jpeg:

/9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAATU0AKgAAAAgABAEaAAUAAAAB

AAAAPgEbAAUAAAABAAAARgEoAAMAAAABAAIAAAExAAIAAAAQAAAATgAAAAAAAABg

AAAAAQAAAGAAAAABcGFpbnQubmV0IDQuMC45AP/bAEMAAQEBAQEBAQEBAQEBAQEB

AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB

Af/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB

AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAAoACgMBIgACEQEDEQH/xAAfAAAB

BQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0B

AgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygp

KjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImK

kpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj

5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJ

Cgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGh

scEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZ

WmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1

tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEA

AhEDEQA/AP5/fg7rH7M+nWv7EPjn4nfsT/ACH49fsz/D/wDZbvPgR+xr4R+Hf7Qn

x1tf+C7/APwvX9o7x3D4p8R+Ivi14A+I3jn4ZeAviB8FbK8Xw/P4K8QeGfil/bn7

R3hz4i/sufEfwBqngX4ZaX+xF8FPxB+LFn/Z3xT+Jen/APCN/D/wd9g+IHjKz/4R

H4T+Nf8AhZXws8K/ZfEepQf8I58NPiL/AMJ/8V/+E++H+h7P7M8G+Nf+FpfEr/hK

vDlrpuu/8J/4x+3/APCRaj6B4A/ax/an+FHws8a/Av4W/tLftAfDX4JfEr/hI/8A

hYvwd8AfGT4i+DvhZ4+/4THw5Z+D/F3/AAmvw+8O+I9O8JeKv+Eq8Jadp/hbxH/b

ukX/APbnhyws9E1P7VplrBap8/0Af//Z

Sceptical? If you copy that text and save it into a new text file (called, say, “encodedJpg.txt”) and then navigate to the folder the file is saved in from a Windows command prompt, you can run the following command certutil -decode encodedJpg.txt 10x10.jpg and you should see the jpg recreated.

You can turn the jpg back in to the text above by running the alternative certutil -encode "input" "output" command.

And that’s Tier 1. For the moment we’re not going to worry about the mechanics of the operation, it’s enough to know that base64 encoding changes binary data into text that looks like the above. Why you'd want to do such a thing and how it's achieved are Tier 2 explanations. N.B. the binary data doesn’t have to be a jpeg image, it could be anything: an executable, a zip file, a Word document, etc.

Next >> Understanding base64 Encoding #2

Visualising Sorting Algorithms

Stumbled across a few really good videos for visualising sorting algorithms. I've seen a few which show the sorting happening but not the logic behind it. I think these convey both aspects really well.

Stack and Heap Refresh

Brilliant refresher on how the stack and heap are used. Also gives an insight into when and why variables are and are not thread-safe.

Commenting Code

My rules-of-thumb for code commenting:

Don't. If you find yourself writing a comment ask yourself "why am I writing this comment?". Most of the times I've found myself writing a comment is because the code isn't self-commenting: the method/class wasn't small enough; naming - at class, function and/or variable level - was poor and obscured intention; I'd written code which could have been written in a more expressive fashion. I was adding a comment to something which should have been extracted to its own method.

Why not What. As far as possible it should be patently obvious what your code is doing, even at a glance. You may not immediately know how it goes about it, but you often won’t need to: a properly named function in a codebase you trust will tell you what it’s doing; a properly name variable will tell you what is it and what it’s being used for. If the domain logic is a bit peculiar, it might be worth documenting why the thing is being done. But be careful and always take a minute to reflect on whether the domain logic truly is peculiar or whether you are just doing something a bit odd.

Is TDD Dead?

A brilliant and informative discussion for anyone who's interested in TDD and its utility: https://www.youtube.com/watch?v=z9quxZsLcfo

oAuth2: A Conversation

I sometimes try to view protocols as conversations between actors in order to aid my comprehension - the anthropomorphising of computer interactions, if you will. I imagine oAuth2 to go something like this (in the context of a web server)...

The actors:

• You
• A Desired Service (ADS) - a service you'd like to use
• oAuth2 Implementer (oAI) - a service you've trusted with your details

You to ADS:  Hello, I'd like to use your service

ADS: Okay, in order to use the service I provide I need you to create an account. I can make this easier for you if you already have an account with (Google | FB | Twitter | etc.) - someone who already knows the information I need to know.

You: I have a Google account, we can use that.

ADS: Cool, in that case I'm going to send you to over to Google to login and they'll send you back to me when you're done.

ADS to oAI: Hey, Google, it's ADS, I'm sending you someone and I want to know their email address, name and phone number. Send them back to this address when you're done.

 ~ you arrive at the oAI (Google)~

aOI: Okay, so who are you?

You: I'm me, I'll login to prove it.

aOI: Hello You. The service that sent you here wants to know your email address, name and phone number, is that cool?

You: Yes, that's fine.

aOI: Alrighty.  When ADS registered with me they specified after people have logged in successfully and agreed to the things it wants access to, there are a predefined list of URLs I can send you back to, of which https://ads.com/oauth2-return-page, which arrived alongside you, is one. I'll send you back there with this authorisation code which ADS can exchange for an access token in order to ask me about your email address, name and phone number.

~ you arrive back at ADS ~ 

ADS: Nice to see you again. I can see you've logged in with Google successfully. I'll just use that authorisation code to request an access token which I'll use to request your details, then I'll create you an account.

ADS to oAI: Hey, I've got this authorisation code, can I get the associated access token.

oAI to ADS: Sure, here you go.

ADS to oAI: Hey, I've got this access token. Can you tell me the email address, name and phone number associated with it?

oAI to ADS: Yup, here you go.

And that, crudely, is how I understand oAuth2 works when web servers are talking to each other.

The Why of the Kilobyte (and data sizes generally)

I am a Computer Science graduate and a developer of ten years. Embarrassingly, it took me until last night to jump down the rabbit hole of the terminology used when describing quantities of data. As usual, I didn't find exactly what I was looking for on the internet, so here are my thoughts:

I like to think I understand binary, in a rudimentary fashion at least. I can explain that it's a base-2 number system, having two symbols to represent its numbers: "0" and "1". I can show you how to count in a base-2 system and show you why it works that way. I can contrast it with a base-4, base-10 or a base-16 system and show how those works. I can perform basic binary addition. Essentially, I'm trying to establish my credentials as someone who isn't a complete binary dullard.

I also understand that one bit (Binary digIT) isn't an awful lot of use on its own. It can be on/off, high/low, true/false - however you choose to describe it - but only in context and combination with other bits does it become interesting and useful. And this is where my journey down the rabbit hole began...

Let me start with good old, recognisable base-10. It has ten symbols to use when representing numbers: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. We - people - have chosen to assign special names to particular, neat representations of quantity in this system:

1 = one = 10^0
10 = ten = 10^1
100 = hundred = 10^2
1000 = thousand = 10^3
1000000 = million = 10^6
1000000000 = billion = 10^9 (old British billion: 1,000,000,000,000 = 10^12)

I haven't worked out quite why we decided those particular representations were worthy of their own name; it feels like an addition chain, especially if you go with the old British billion: 0, 1, 2, 3, 6, 9|12.

With this in mind we approach base-2, where the ground appears to completely shift. We start by giving names to collections of bits, seemingly more interested in the range of numbers a collection of bits can represent than the numbers themselves. So..

0 = bit = 0 to 1
0000 = nibble | nyble = 0 to 15
0000 0000 = byte = 0 to 255

You think "okay, well it's a different world, things area different here... maybe a different pattern is used". Once you get your head round it's collections of bits (ranges of numbers) are given names, rather than numbers themselves, then maybe you can work out the pattern. Maybe 16 bits or 32 bits have a special name? Nope. It's all madness from here on in!

0000 0000 0000 0000 = 2 bytes | 16 bits
0000 0000 0000 0000 0000 0000 0000 0000 = 4 bytes | 32 bits

What appears to have happened is that someone decided bits are no longer interesting and that... wait for it... quantities of bytes are interesting (completely eschewing the lowly bit) and decide either 1000 or 1024 (depending on your stance) is an interesting quantity of these byte things to be concerned about. I can only imagine being interested in ~1000 of these thing is the spectre of base-10 hovering over the decision making.

1024 x byte = kilobyte
1024 x kilobyte = megabyte
1024 x megabyte - gigabyte
etc.

If someone can explain the why behind this thinking I'll be greatly appreciative. I can only imagine that "kilo" and "mega" are impositions from the world of base-10 and that multiples of bytes is interesting because 8 bits can represent a character (as per ASCII or some machine instruction).

Nomenclature

I agonise over naming things when it comes to coding; names convey intention and purpose and are one of the first things you rub up against when trying to figure a out new concept or someone else's code - or your own from longer than a few days ago.

It's in this spirit I want to rename Closures as Captors (or Captures). When you read into it and discover that the term "closure" is used in reference to "closing over variables", I submit you immediately think "what?" and then "I wonder if them mean capture a variable?".

Thoughts?

http://www.blackwasp.co.uk/CSharpClosures.aspx

IT Recruitment Agencies

I'm unlikely to say anything original in this post. I'm trying to work out what exactly my opinion of recruitment agencies is and whether not they can be bent so as to be useful.

N.B. I'm a permanent, full-time employee. I always have been. My experiences of recruitment agencies have always been in that context; I've never dealt with recruitment agencies from a contractor's point of view.

The sheer volume of IT recruitment agencies in Brighton (and surrounding areas) is staggering yet completely understandable: they want a piece of the relatively well paid developer's pie. A recruitment agency introduces you to a prospective employer and typically, providing you pass probation, gets a lump sum (~20% of your first year's salary) for doing so.

Traditional free market principles do not seem to apply to IT recruitment agencies, that is, myriad agencies do not appear to have created a survival of the fittest situation in which only the leanest, highly-skilled, astute agencies / agents survive. Rather, there's a roiling mass of incompetence and greed from which no front-runners emerge, presumably because there are non to do so.

I imagine a recruitment agent's job must not feel too dissimilar to that of a 419 scammers: sending innumerable emails off to potential victims (LinkedIn members who wonder was there ever a time giving LinkedIn all your personal work history felt like a good idea...) hoping for that one hit in a thousand to make them rich.

It feels like mine and my potential agent's interests are fundamentally misaligned: I want the right job; the agent wants me to take any job, preferably one I can only stick out for a year before returning to them to try again.

This has merely turned into a rant. What are the benefits or a recruitment agent for a full-time, permanent employee? There must be some...