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.

	#include <iostream>
	int main() {
	int ten = 10;
	int fifty = 50;
	int* pointer; // pointers can be null
	pointer = &ten; // they hold memory addresses (&ten = the memory address of variable 'ten')
	pointer = &fifty; // and pointers can be reassigned
	std::cout << pointer << "\n"; // this writes the address pointer holds
	std::cout << *pointer << "\n"; // this writes out the value of the address pointer is pointing to
	int& reference = ten; // references are non-null, assigned-once aliases for other variables
	std::cout << reference; // this is the same as std:cout << ten
	}
	// Output:
	// 0xfff000bcc
	// 50
	// 10

view raw ReferencesAndPointers.cpp hosted with ❤ by GitHub

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:

	using System;
	using System.ComponentModel;
	using System.Runtime.InteropServices;
	using System.Security;
	using System.Security.Permissions;
	using System.Security.Principal;
	namespace ImpersonationTesting
	{
	public class Impersonate : IDisposable
	{
	private const int LOGON32_PROVIDER_DEFAULT = 0;
	private const int LOGON32_LOGON_INTERACTIVE = 2;
	private readonly string _domain;
	private readonly string _username;
	private readonly SecureString _password;
	private IntPtr _userToken;
	private bool _isDisposed;
	public Impersonate(string domain, string username, SecureString password)
	{
	_domain = domain;
	_username = username;
	_password = password;
	}
	[PermissionSet(SecurityAction.Demand, Name = "FullTrust")]
	public void RunAsImpersonatedUser(Action action)
	{
	_userToken = IntPtr.Zero;
	bool logonSuccessfull = LogonUser(_username, _domain, _password.ToPlainString(), LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, ref _userToken);
	if (logonSuccessfull == false)
	{
	int error = Marshal.GetLastWin32Error();
	throw new Win32Exception(error);
	}
	using (var impersonationIdentity = new WindowsIdentity(_userToken))
	using (WindowsImpersonationContext context = impersonationIdentity.Impersonate())
	{
	action();
	}
	}
	public void Dispose()
	{
	DisposeOfUserToken();
	}
	private void DisposeOfUserToken()
	{
	if (_isDisposed)
	{
	return;
	}
	_isDisposed = true;
	CloseHandle(_userToken);
	}
	~Impersonate()
	{
	DisposeOfUserToken();
	}
	#region P/Invoke Methods
	[DllImport("advapi32.dll", SetLastError = true)]
	private static extern bool LogonUser(string lpszUsername, string lpszDomain, string lpszPassword, int dwLogonType, int dwLogonProvider, ref IntPtr phToken);
	[DllImport("kernel32.dll", CharSet = CharSet.Auto)]
	private static extern bool CloseHandle(IntPtr handle);
	#endregion
	}
	}

view raw Impersonate.cs hosted with ❤ by GitHub

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:

	static void Main(string[] args)
	{
	using (Stream stream = GetStream())
	{
	int byteRead;
	while ((byteRead = stream.ReadByte()) != -1)
	{
	Console.WriteLine(byteRead);
	}
	}
	}

view raw streams.cs hosted with ❤ by GitHub

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:

	private static Stream GetStream()
	{
	byte[] bytes = Encoding.ASCII.GetBytes("Hello, World!");
	return new MemoryStream(bytes);
	}

view raw memorystream.cs hosted with ❤ by GitHub

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:

	private static FileStream GetStream()
	{
	FileStream fileStream = File.Open(@"C:\HelloWorld.txt", FileMode.Open);
	return fileStream;
	}

view raw filestream.cs hosted with ❤ by GitHub

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

	private static Stream GetStream()
	{
	var webRequest = WebRequest.Create("http://www.google.co.uk");
	var webResponse = webRequest.GetResponse();
	Stream responseStream = webResponse.GetResponseStream();
	return responseStream;
	}

view raw webstream.cs hosted with ❤ by GitHub

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.

psql --username=postgres --dbname=postgres --command='DROP DATABASE IF EXISTS DATABASE_NAME;' --command='CREATE DATABASE DATABASE_NAME;' --command='\c DATABASE_NAME' --command='\i create_schema_and_seed.sql'

view raw postgres_db_init.txt hosted with ❤ by GitHub

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.