Blog Archive

Monday, 23 September 2013

Public properties, getters and setters, or magic?

Opinion seems to be divided on whether it is good practice to use public properties in PHP classes, or whether to use getter and setter methods instead (and keep the properties private or protected). A sort of hybrid third option is to use the magic methods __get() and __set(). As always, there are advantages and disadvantages to each approach, so let's take a look at them...

Public properties example

class Foo 
{
    public $bar;
}

$foo = new Foo();
$foo->bar = 1;
$foo->bar++;

In this example, bar is a public property of Foo. The calling code can manipulate that property in any way it likes, and stuff any old data in it.

Public properties advantages

  • Compared with getter and setter methods, there is a lot less typing involved!
  • The calling code is more readable and easier to work with than getter and setter method calls.
  • A call to a public property (to either set or get) is faster and uses less memory than a method call - but the saving is small unless you are calling it many times in a long loop.
  • Objects with public properties can be used as parameters for some PHP functions (such as http_build_query), and can be serialized by json_encode.

Public properties disadvantages

  • There is no way of controlling what data is held in the properties - it is very easy to populate them with data that the class methods might not expect. This can be particularly problematic if the class is being used by another developer (ie. other than the author of the class), as they might not (and should not need to) be aware of the internal workings of the class (and let's face it, after a few months, the author of the class probably won't remember the internal workings either).
  • If you want to expose a public property in an API, you can't do so using an interface, as in PHP interfaces only allow method definitions.

Using getters and setters example

class Foo
{
    private $bar;
    
    public function getBar()
    {
        return $this->bar;
    }
    
    public function setBar($bar)
    {
        $this->bar = $bar;
    }
}

$foo = new Foo();
$foo->setBar(1);
$foo->setBar($foo->getBar() + 1);

Here the bar property is private so cannot be accessed by the calling code directly. The caller has to use the getBar method to retrieve the value and the setBar method to set it. The methods can perform validation processing to ensure that only valid values are allowed through.

Getters and setters advantages

  • With getters and setters you can control exactly what is stored in your object properties, and reject any values that are not valid.
  • You also have the option of performing additional processing when a value is set or retrieved (for example, if updating this property should trigger some action such as notifying an observer).
  • When setting a value which represents an object or array (rather than a scalar value), you can specify the type in the function declaration (eg. public function setBar(Bar $bar)). Such a damn shame PHP won't let you do the same thing with ints and strings!
  • If the value of a property has to be loaded from an external data source or the runtime environment, you can lazy load it - so the resources required to load the data are only used if the property itself is called. Of course you would need to be careful that you don't needlessly load the data from the external source on every call to the property. And it would be more common to make a single call to the database to populate all the properties rather than fetching them one at a time.
  • You can make properties read-only or write-only by only creating a getter but not a setter or vice-versa.
  • You can include a getter and setter in an interface to expose them in an API.

Getters and setters disadvantages

  • For developers who are used to accessing properties directly, getters and setters are a pain in the neck to use! For every property you have to define the property itself, a getter, and a setter, and to use the property in the calling code you have to make extra method calls - it is much easier to say $foo->bar++; rather than the long-winded $foo->setBar($foo->getBar() + 1); (although of course you could add yet another method such as $foo->incrementBar();)
  • As noted above, there is a small additional overhead when making a method call over using a plain ol' public property.
  • By convention, getter and setter methods start with the verbs 'get' and 'set' respectively, but these verbs are also commonly used for other methods which don't necessarily relate to properties. This is not necessarily a problem for the calling code as you might not care what the implementation is, but the ambiguity about the type of implementation you are dealing with can make the code harder to understand.

Magic method getters and setters example

class Foo
{
    protected $bar;

    public function __get($property)
    {
        switch ($property)
        {
            case 'bar':
                return $this->bar;
            //etc.
        }
    }

    public function __set($property, $value)
    {
        switch ($property)
        {
            case 'bar':
                $this->bar = $value;
                break;
            //etc.
        }
    }
}

$foo = new Foo();
$foo->bar = 1;
$foo->bar++;

Here, the bar property is not publicly exposed, but the calling code still calls it as though it were public. When PHP can't find a matching public property, it calls the appropriate magic method (__get() for retrieving a value, __set() for assigning a value). This might seem like the best of both worlds, but it has a major drawback (see disadvantages below!). Note also that __get and __set are NOT called if a matching public property exists, but they are called if a protected or private property exists but is out of scope, or if no property exists.

Magic method getter and setter advantages

  • You can manipulate properties directly from the calling code (as though they were public properties) but still have complete control over what data goes into what property.
  • As with declared getter and setter methods, you can perform additional processing when the property is used.
  • You can use lazy loading.
  • You can make properties read-only or write-only.
  • You can use the magic methods as a catch-all to handle calls to properties that don't exist, and still process them in some way (effectively allowing the calling code to decide what property names to use).

Magic method getter and setter disadvantages

  • The showstopper for magic methods is that they do not expose the property in any way. To use or extend the class, you have to 'just know' what properties it supports. This is simply unacceptable most of the time (unless perhaps you are one of those hard core programmers who think notepad is an IDE!), although there are times when the advantages mentioned above outweigh this limitation. As pointed out by a commentator below, this disadvantage can be overcome by using the phpDoc tags @property, @property-read, and @property-write. Cool.

Which option to use

Clearly there are some significant advantages to getters and setters, and some people feel that they should therefore be used all the time (especially those who come from a Java background!). But in my opinion, they do break the natural flow of the language, and their additional complexity and verbosity puts me off using them unless there is a need to do so (I find it a little irritating when naive getters and setters don't actually DO anything other than get or set the property). My choice then is to use public properties most of the time, but getters and setters for critical settings that I feel need stricter control, would benefit from lazy loading, or that I want to expose in an interface.

Another alternative?

Before I learned PHP, I used to use C#. In C#, all properties have accessor methods, but you don't have to call them as methods, you can just manipulate the properties directly and the corresponding methods are called magically. So it is similar to PHP's magic __get and __set, but the properties are still declared and exposed. This really is the best of both worlds, and it would be great to see a feature like this in PHP.

Tragically though, the RFC for a C#-like property accessor syntax feature could not quite muster up the two-thirds majority needed to take it forward: https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 Bah!

Saturday, 7 September 2013

Handling Global Data in PHP Web Applications

Almost every web application needs to handle global data. There are certain things that just have to be available throughout the entire code base, such as database connections, configuration settings, and error handling routines. As a PHP developer, you may have heard the mantra 'globals are evil', but this naturally begs the question 'what should I use instead of global variables?'

There are several different strategies available to help cope with the demand for global data - each has its advantages and disadvantages and it can be a challenge to know which approach to use for any given situation. Here I will try to outline what the options are, how they work, their advantages, their disadvantages, and examples of under what circumstances each option might be used. The code samples are not necessarily realistic, they are kept as simple as possible to demonstrate the idea. The principles and design patterns that follow are not specific to PHP - they can be applied to any object oriented language.

Global Variables

Probably the easiest solution to understand and to implement is the use of global variables. A global variable is defined using the global keyword, and that makes the contents of the variable available throughout the entire code base. Typically you declare the variable (again using the global keyword) in every scope that you want to use it, although you can just use the $GLOBALS 'super global' array to reference the value without declaring it first.

Global variable example:

global $database;
$database = new Database();

function doSomething()
{
    global $database; //This has to be declared so that PHP knows 
                      //you want to use the global variable, not 
                      //a local one
    $data = $database->readStuff();

}

Global variable example using $GLOBALS super global:

global $database;
$database = new Database();

function doSomething()
{
    $data = $GLOBALS['database']->readStuff(); //No need to 
                                               //declare the 
                                               //global first

}

Global variable advantages

  • The main advantage of global variables is that they are easy to understand, and easy to use in your code. Their ease of use makes it tempting to use them a lot, even though there may be much better options available!

Global variable disadvantages

The disadvantages of using global variables nearly always outweigh the advantages.
  • They make your code hard to read and hard to understand. It is not obvious what the variable is for, where or how it was initialised, or what is the proper way to use it.
  • They make your code hard to maintain. It is very difficult to make changes to global variables, as you have to search through your entire code base looking for where they have been used.
  • It is easy to abuse a global variable and cause errors that are hard to debug. Without any control mechanism for how the variable is used, it is easy to populate it with invalid data which can cause errors in other parts of the code (for example, if one part of the code populates the variable with an array but another part of the code expects it to contain an object).
  • It is easy to get confused regarding the variable's scope. If you forget to declare that the variable is global, you can end up unwittingly working with a local variable without noticing - until your app breaks. This can also be hard to debug.
  • If you combine your code with someone else's code (eg. by using a third party library or writing an extension for another piece of software), and both systems use global variables, there is a chance that the variable names could clash, causing errors in both systems which are hard to debug.
  • All parts of your code that use a global variable are tightly coupled and it becomes very difficult to separate out or re-use a module elsewhere.
  • Unit testing is made more difficult, as the test has to know which global variables are needed, and how to initialise all global variables with valid values.

When to use global variables

It is rarely a good idea to use global variables, especially in a large application, but there are some occasions when their ease of use and simplicity make them an acceptable option. In particular, if you are writing a short and relatively simple plugin or small app, which is going to be easy to read and understand, or perhaps a proof-of-concept or prototype script.

Static Classes (Helper Classes)

Using helper classes that just contain static members is another easy way of dealing with global data, although they share many of the same disadvantages as global variables. Classes with static members can contain both properties and methods, like a normal object, but do not need to be instantiated before use, and retain their values throughout the scope of your application. They have more in common with procedural code than object oriented code, despite the use of classes.

Static class example:

class SmtpConfig
{
    public static $host = 'localhost';
    public static $port = 465;
    public static $user = 'me@example.com';
    public static $password = 'j4a!9Sd@aKP2f';
    public static $tls = true;
}

echo SmtpConfig::$user; //This and other values from the class 
                        //are available everywhere as long as 
                        //the file containing the class 
                        //declaration has been included or can 
                        //be autoloaded

Static class advantages

  • A static helper class enables you to group several related pieces of data together.
  • Static classes are easy to to use, easy to understand, and not so prone to naming clashes as global variables (although now that PHP supports namespaces, name clashes are not really an issue except in legacy code).
  • It is easier to locate where the data was initially defined (most IDEs will automatically locate the class definition for you, whereas with global variables, it is not always possible to tell where they were first declared), although this still doesn't stop the values being initialised or changed anywhere throughout your code base.

Static class disadvantages

  • If a static class has methods which have their own dependencies, they can be more difficult to unit test than instantiated classes with dependency injection (see below).
  • The main disadvantage of static classes is that they promote close coupling - any object relying on the static members is closely coupled with the code that initialises those members (and which in turn may have its own dependencies).
  • Static classes do not have a constructor, so any static methods have to do their own dependency checking, and the calling code has to perform any initialisation beyond just using the default values. This also typically requires error checking after the method call - at which point it is difficult to ascertain which dependency failed.
  • Dependencies are not enforced, so the code execution can fail to execute with few clues as to why, and for reasons related to a dependency of a dependency of a dependency and not for reasons relating to the place in the code where the failure occurred (a debugging nightmare).

When to use static classes

Static classes are best used in simple cases where there are no dependencies, or where the dependencies are simple and fundamental enough to the operation of your application that they can be taken as read (since you have no way of enforcing them). An example of this would be your application's global error handler (although that could equally well be a singleton - see below - it is best to keep error handling as simple as possible, as it needs to be bulletproof, and static classes are arguably simpler than singletons - you could even use procedural code in a bootstrap file which is simpler still).

Static members are useful as private or protected members of an instantiated class, and provide a way of storing data once for many instances (thus reducing the amount of memory needed for each instance) - for example by holding immutable metadata such as database column information. They can also be used effectively for providing small algorithms that are never likely to need changing or overriding for internal use within an instantiated object. But a class full of just static members is a bit of a 'code smell', and there is usually a better way.

Singleton

A singleton is a class which is instantiated, but for which there can only be a single instance. A singleton class cannot be directly instantiated by the calling code (the constructor carries the private or protected modifier) - it has to be accessed through a static member which checks whether the class has already been instantiated, and if so, returns the existing instance, otherwise, creates a new one (which it holds on to in case another caller wants it). This is an effort to allow better support for inheritance, and to allow it to be passed around and treated like any other object. The intention of the singleton pattern is not really to provide a mechansim for global data, but to ensure that only one object is created (it being globally available is a side effect).

Singleton example

class Singleton
{
    protected static $instance = null;

    protected function __construct()
    {
    }

    protected function __clone()
    {
    }

    public static function getInstance()
    {
        if (!isset(static::$instance))
        {
            self::$instance = new Singleton();
        }
        return static::$instance;
    }
}

$singleton = Singleton::getInstance();

Singleton advantages

  • Ensures there is only one version of the object (allowing a resource to be shared).
  • Can be used from anywhere in the code - if it is not already instantiated, it will be on its first use.
  • Can support inheritance and polymorphism to a limited degree.

Singleton disadvantages

  • Enforcing a single instance of an object is rarely the desired behaviour (for example, whilst it might seem like you would only need one database connection in an application, requirements might change, requiring the application to access more than one database - perhaps for backup or synchronisation purposes).
  • There is no need for classes that rely on the singleton to declare their dependency on it, so it is not obvious that they rely on it and it creates a close coupling between them.
  • Inheritance and polymorphism are restricted, as there can still only be a single instance per request (but the implementation could be different for different types of request).
  • Once instantiated, the singleton will be held in memory for the life of the request even if it is not needed again (this might be desirable for objects that are expensive to instantiate and/or that are used frequently, but can negatively impact memory usage if used indiscriminately).

When to use a singleton

A singleton should only really be used if a single resource needs to be shared among different objects. It is necessary to check that even if the current requirements do not call for multiple instances of the object, any likely or potential future requirements will also not need to allow for multiple instances. A common use of the singleton pattern is for combining with a global registry pattern (see below), or for interacting with the operating system or host that the application is running on (of which there will only ever be one at a time).

Registry

The registry design pattern allows you to define an object (usually a singleton) which holds references to various other resources (typically as key/value pairs) that may be needed by your application (for example, database connections and configuration settings). Although the registry itself is usually a singleton (as you only want a single registry available to the whole application), the resources it stores are not expected to be singletons - it can store several different instances of the same class. The resources it stores do not even have to be objects - they can be primitive data types or arrays.

Resources can be stored in a hash table (array), or if you know that certain items will need to be in the registry, you can strongly type them (which will help with the code autocomplete features of your IDE). You could also have a mixture!

Registry example (weakly typed)

class Registry
{
    protected static $instance;
    protected $resources = array();

    protected function __construct()
    {
    }

    protected function __clone()
    {
    }

    public static function getInstance()
    {
        if (!isset(self::$instance)) {
            self::$instance = new Registry();
        }
        return self::$instance;
    }

    public function setResource($key, $value, $force_refresh = false)
    {
        if (!$force_refresh && isset($this->resources[$key])) {
            throw new RuntimeException('Resource ' . $key . ' has already been set. If you really ' 
                                       . 'need to replace the existing resource, set the $force_refresh '
                                       . 'flag to true.');
        }
        else {
            $this->resources[$key] = $value;
        }
    }

    public function getResource($key)
    {
        if (isset($this->resources[$key])) {
            return $this->resources[$key];
        }
        throw new RuntimeException ('Resource ' . $key . ' not found in the registry');
    }
}

//Add a resource to the registry
$db = new Database();
Registry::getInstance()->setResource('Database', $db);

//Retrieve a resource from the registry (elsewhere in the code)
$db = Registry::getInstance()->getResource('Database');

Registry example (strongly typed)

class Registry
{
    protected static $instance;
    protected $main_db;
    protected $sync_db;
    protected $config;

    protected function __construct()
    {
    }

    protected function __clone()
    {
    }

    public static function getInstance()
    {
        if (!isset(self::$instance)) {
            self::$instance = new Registry();
        }
        return self::$instance;
    }

    public function setMainDatabase(Database $value, $force_refresh = false)
    {
        if (!$force_refresh && isset($this->main_db)) {
            throw new RuntimeException('Main database has already been set. If you really '
                                       . 'need to replace the existing database, set the '
                                       . '$force_refresh flag to true.');
        }
        else {
            $this->main_db = $value;
        }
    }

    public function getMainDatabase()
    {
        if (isset($this->main_db)) {
            return $this->main_db;
        }
        throw new RuntimeException ('Main database resource not found in the registry');
    }

    public function setSyncDatabase(Database $value, $force_refresh = false)
    {
        if (!$force_refresh && isset($this->sync_db)) {
            throw new RuntimeException('Synchronisation database has already been set. If you really '
                                       . 'need to replace the existing database, set the $force_refresh '
                                       . 'flag to true.');
        }
        else {
            $this->sync_db = $value;
        }
    }

    public function getSyncDatabase()
    {
        if (isset($this->sync_db)) {
            return $this->sync_db;
        }
        throw new RuntimeException ('Synchronisation database resource not found in the registry');
    }

    public function setConfig(Config $value, $force_refresh = false)
    {
        if (!$force_refresh && isset($this->config)) {
            throw new RuntimeException('Configuration object has already been set. If you really '
                                       . 'need to replace the existing configuration, set the '
                                       . '$force_refresh flag to true.');
        }
        else {
            $this->config = $value;
        }
    }

    public function getConfig()
    {
        if (isset($this->config)) {
            return $this->config;
        }
        throw new RuntimeException ('Configuration resource not found in the registry');
    }
}

//Add a resource to the registry
$db = new Database();
Registry::getInstance()->setMainDatabase($db);

//Retrieve a resource from the registry (elsewhere in the code)
$db = Registry::getInstance()->getMainDatabase();

In these examples, the developer is allowed to overwrite existing resources, but only if they make it clear that this was their intention (by setting the $force_refresh flag).

Registry advantages

  • If there are common dependencies that are used throughout your code, you can use the global registry instead of passing an individual parameter for each one.
  • A registry allows you the freedom to store and manage your global data centrally, without restricting the implementation to a single instance, and allowing full use of inheritance and polymorphism for the resources it manages.
  • A strongly typed registry allows your IDE to help you avoid typing mistakes.
  • A registry is somewhat easier to use than dependency injection.

Registry disadvantages

  • A registry still hides dependencies and is tightly coupled to objects that rely on it (or its contents), although not as tightly as a global variable (because the resources can be replaced with different sub classes).

When to use a registry

Some developers reject the use of a registry on the grounds that it is just a global array in disguise, and (in particular with a weakly typed implementation) gives no clue as to how its contents are meant to be used. However, the generally preferred alternative (dependency injection - see below) can get out of hand when you have to inject lots of dependencies, many of which are the same ones over and over again (you can use a dependency injection container to manage this, but it is arguably more complex than using a global registry). Used sparingly then, a registry can be an appropriate vehicle for managing the most common dependencies that are fundamental to the workings of your application (typically, one or more databases, maybe a logger, and a configuration object), without requiring an unreasonably long list of parameters, or repeated use of the same parameters, for every object instantiation.

Dependency Injection

Dependency injection requires that the calling code supply all of the dependencies to an object before use. In most cases, this is done by passing parameters to the constructor - so that the object cannot be instantiated unless it has been given all of the data it needs to do its job. Optional dependencies are often injected using a separate method call. Injected dependencies are often objects but they don't have to be - any data the object requires to do its job is a dependency and must be supplied by the calling code.

Dependency injection example

class Person
{
    protected $database;
    public $title;
    public $first_name;
    public $last_name;
    
    public function __construct(Database $db, $last_name)
    {
        $this->database = $db;
        if (strlen($last_name) == 0) {
            throw new Exception('Last name required');
        }
        $this->last_name = $last_name;
    }
    
    public function setTitle($title)
    {
        $this->title = $title;
    }

    public function setFirstName($first_name)
    {
        $this->first_name = $first_name;
    }
    
    //More methods here which use the database object
}

$db = new Database('localhost', 'user', 'password');
//The database object is passed to the Person object in the constructor, along with some other data
$person = new Person($db, 'Smith');
$person->setTitle('Mr'); //Optional dependencies can be set with a separate method call

Dependency injection advantages

  • Dependency injection de-couples your code, allowing each object to exist and perform operations without requiring any particular environmental setup.
  • This makes code re-use much easier, as you can just use the same object in another application or in another setting in the same application.
  • It also makes unit testing much easier, as a test can be set up to inject real or dummy dependencies for the purposes of testing the object.
  • It is obvious to the calling code what the dependencies are - it can therefore supply everything that is needed without worrying that there might be some hidden dependency which will break the application if not supplied.
  • Inheritance and polymorphism can be used to great effect by specifying the parent class (or interface) as a dependency - the calling code can then supply any sub class and the object doesn't need to know or care what the implementation is (allowing for easy extensibility). For example, if a class has a constructor which requires a database object to be injected, the calling code can inject a MySQL database class or an SQLite database, or any other sub class of database (perhaps even one that hasn't been invented yet).
  • By passing dependencies in the constructor, any problems can be caught early - the class can verify that it has valid dependency data before it will allow instantiation. This makes debugging much easier.
  • For a lucid explanation of why dependency injection is generally superior to using statics, please see David C. Zentgraf's post: How Not to Kill Your Testability Using Statics (the article is not just about testability).

Dependency injection disadvantages

  • The calling code may have more work to do to initialise an object, especially if the dependencies you are injecting have dependencies of their own (if this gets out of hand you could look into using a dependency injection container).
  • If there are lots of dependencies, you could end up with a long list of parameters in your constructor which makes the code difficult to read and understand.

When to use dependency injection

In most cases, dependency injection provides more advantages than disadvantages, so it is becoming common practice to use it by default and only avoid it if it is causing problems. Where certain objects are used extensively throughout the code base (such as a database or configuration object), injecting them into every object can become laborious and inelegant. In such cases, it might be better to just accept a certain amount of close-coupling for the sake of code readability (and writability!), and to use the setup and teardown features of your unit testing software to initialise and destroy the most common dependencies.

Increasingly though, dependency injection containers are used to handle multiple object dependencies. Using a container allows the dependencies to be defined just once instead of at every instantiation, and the dependencies can even be defined in a config file or in annotations rather than in the code itself. There are various frameworks available that provide dependency injection containers, some of which are very lightweight and specialise in just providing containers.

In conclusion

The developer has to make a judgement call about when to use which approach for handling global data. Each approach has its advantages and disadvantages, and whilst some (dependency injection) are clearly more desirable than others (global variables) in most situations, it is not helpful to make blanket rules (like 'singletons are evil').

Wednesday, 4 September 2013

Using Procedural Code in PHP

Object oriented programming (OOP) in PHP has become increasingly popular since PHP 5 was released, and especially from PHP 5.3 onwards. Without doubt, writing a large application using OOP in PHP has a lot of advantages over using purely procedural code (and if you are new to PHP I strongly advise concentrating your efforts on OOP). But despite the advances PHP has seen in OO support, it is still a procedural language at heart, and there are times when procedural is the way to go. Here are some examples...

When to use procedural code in PHP

  • All PHP scripts have to start with procedural code! Typically you have an 'index.php' file as the entry point to your application, and before you can use any objects, you have to instantiate them, and the first instantiation has to be done procedurally - there is no other option.
  • In most cases there are certain 'bootstrap' tasks that have to be carried out before you can process a request. This might include registering an autoload function, setting up error handling, and checking that the system is capable of running your application. All of this is typically done procedurally (perhaps also using static classes) because it is impractical to do it using OOP (for example, if you do not control the deployment environment, you might want your app to die gracefully even if someone tries to run it on PHP 4 - but if you try to use OO features from PHP 5, it will not be possible to die gracefully).
  • You could use procedural code to provide alternatives or additions to the built-in PHP functions (although you should first consider whether OOP would be better). For example, your script might or might not have access to multibyte string functions - it could be useful to have your own alternative functions that use multibyte functions if available or the standard PHP functions if not (you can use namespaces to override default PHP functions in PHP 5.3 and above, but this might not be very wise as your code will no longer behave in the way it would be expected to behave by any other PHP developer! Better to write separate functions with a different name).
  • If you are just writing an example script, a proof of concept, or a very simple script or plugin, there is probably no need to go OO.
  • If you prefer to write procedurally and feel you write better code that way, there is no reason why you shouldn't do so! Procedural code is not 'wrong' per se, there is just a tendency for it to lead to code that is difficult to test and difficult to maintain. But some great applications have been written procedurally, and it can be an acceptable choice, especially if you don't need to collaborate with anyone else. Better to write good procedural code than bad object oriented code!

When not to use procedural code in PHP

  • Pretty much any other time! Of course, I might not have thought of everything, so there are probably other occasions when procedural code is the right choice.

Other considerations

Object oriented vs procedural is not the be-all and end-all of programming models. I found this post about the 'messaging' programming model very helpful (at least the first part - it gets more biased towards MS Windows later on): Drastically Improving Your Code With Messaging as a Programming Model.


First Post

I'm always learning new stuff. Sometimes stuff is worth sharing, or at least recording so I can find it again later. So I decided to start a blog. And here it is.

I'll try to make sure I know what I'm talking about before posting, but I'm always learning and always happy to be corrected. I'm interested in a lot of subjects, so my posts might seem a bit random, but I appreciate any feedback on whether posts are useful or not.