The building block of the VPS offering is a node: a discrete unit of CPU time, RAM, storage, and bandwidth. These nodes can be deployed as separate servers, or combined together to create a more powerful server. Servers can be upgraded or downgraded by attaching and detaching nodes from them. The CPU/bandwidth changes can be applied without rebooting, but to apply RAM and storage changes, the VPS needs to be rebooted so that the RAM reassignment can happen and so the VPS root volume can be rebuilt. You can bill nodes per month or per day. The daily option is more expensive, but allows you to throw an extra node or two at a server that’s being slashdotted until the traffic subsides — much cheaper in the long haul then monthly nodes. Daily nodes are also a good choice for a throwaway server you’re going to test something on and then scrap. The math suggests that if you’re going to be using the server for longer than two or three weeks, monthly nodes are a better deal.

To further sweeten the deal, nodes are portable across any of their data centers. While you can’t easily migrate deployed VPSes, you can destroy a server in one data center and create a new one in another using the same node. I look forward to the day when we’ll be able to live-migrate running VPSes across the country. Hopefully someone at VPS.NET is working on that…

Initially I had one node and this blog was about the only thing running on the server. Since then, I’ve expanded the services I host to my personal email server (hosting a few domains for friends too), a Git-based personal software forge, some services for Wikimedia, and a few odds and ends. While not a feature unique to VPS.NET, having root on your own server is really nice. Need some software? Install it. Want to tweak the firewall? Go ahead. I’m a hacker, so it’s nice to be able to use my server to just try stuff out and see what works.

Each VPS has CPU and network usage graphs so you can pinpoint busy times and optimize accordingly. There’s also a console for each VPS that connects directly to the offline OS terminal, allowing you to recover from a botched network or ssh config without involving support. While I’d like to claim that I’ve never had to make use of this feature, that would be a lie. I don’t often need it, but it’s there when I do.

Uptime has been pretty good all-around. I’ve had a few outages here and there: a SAN failure that the staff were not properly prepared for, causing a few hours of downtime; a bootloader issue with Debian caused by upgrading to squeeze (arguably not VPS.NET’s fault, as Debian decided to change the boot volume path); and most recently, volume corruption caused by upgrading my node, which the support staff remedied within minutes, but ideally should have never happened. (This makes me a bit reluctant to upgrade again without someone over there babysitting the box to make sure it boots up correctly.) However, these occurrences were not frequent. That’s three distinct issues I can recall since late 2009, two if you attribute the bootloader problem to Debian. This isn’t 100% uptime, but it’s pretty darn close to it, and support is usually quick to respond when problems happen.

I resell a few nodes to some friends and former business partners, and they’ve had very little issues getting started. It takes about 10 minutes to go from purchasing a node to having a running server. When a friend wants another server, I can deliver them their login credentials to a running server within about 15 minutes. That’s pretty cool.

There are a few network-level filtering things one should be aware of. VPS.NET monitors outgoing SMTP (port 25) connections and applies their own spam filtering, rejecting mail if it’s too spammy. Some people might like this since it can protect them from being listed on a spam blacklist if their server gets compromised. Since I run my own mail server and do my own filtering, I wasn’t pleased when this was deployed, especially since it was done so without any communication on their part. Once I figured out what was going on, I was able to opt-out of this filtering by filing a support ticket. I would have preferred more transparency about this change. Finally, as with most hosts, IRC ports are filtered bidirectionally. As I was wanting to use my VPS to run a service that collects data from Wikimedia’s real-time change notification IRC server (essentially just a data stream delivered via IRC) this was a bit of a bummer. They will not budge on this policy, which is disappointing.

Overall, I am a happy customer. Things don’t go wrong often, and when they do support is quick to respond. I’d suggest trying a daily node or two if you want to see if they are a good fit for your hosting needs; they’re only a dollar per day.

There are bound to be things in every programming language that get in the way of productivity. In this post I’ll highlight one of those things in C++: references. References are obfuscating and mostly useless. But first, why would you use a reference?

A reference is effectively a pointer, but this is hidden by the language. You use it like it’s not a pointer, and the compiler turns direct accesses into indirect accesses. For example:

#include <iostream>

int main() {
	int a = 5;
	int &b = a;

	std::cout << "a is " << a << std::endl;

	b = 6;

	std::cout << "a is " << a << std::endl;
}

The output will be:

a is 5
a is 6

Note that I did not say *b = 6;. The reference is treated as though it were not a pointer. Cool… but what’s the benefit?

The solitary benefit I’ve heard from others is that references cannot be null. When you declare a function/method that accepts an argument typed as a reference, it’s not possible to make that reference equivalent to a null pointer.

Ok, so we trade a bit of clarity for a compile-time guarantee that we won’t be dereferencing a null pointer. That’s a good trade, right?

Maybe. Consider this excerpt:

class Foo;

void do_something() {
    Foo *foo = new Foo();
    use_foo(*foo);
    delete foo;
}

This is contrived, yes, and there’s a better way to write this code. But I’m illustrating something here. I’ve told you that Foo is a class, but I haven’t told you the prototype for use_foo(). That’s on purpose. Now, you tell me if the Foo instance is going to be copied. I’ll even tell you that Foo doesn’t overload operator*.

Do you have your answer yet? If you said yes — the logical choice — you’re wrong. If you said no, you’re also wrong. Well, actually, if you said yes or no, you might be wrong. It’s impossible to tell. If use_foo()‘s declaration is use_foo(Foo foo) then a copy will be made using Foo‘s copy constructor (if possible, otherwise it will be a compile-time error). But if the function’s prototype is use_foo(Foo &foo) then we are actually passing in the value stored in the foo variable — a memory address. The object will not be copied. In other words, while it looks like we are dereferencing foo, we are actually doing no such thing.

In C, you can tell pretty much everything you need to know from a call site. In C++, you must know how the function you’re calling is defined too, simply because you have to know when things are references and when they are not. The treatment of what is fundamentally a pointer type as a value type (at the language level) is what causes the uncertainty. You use value-type grammar around references, even though they are not really a value type.

If it weren’t for the existence references, the code above would be perfectly clear. (Well, unless you didn’t have me to tell you that Foo doesn’t implement operator*…)

Don’t get me wrong, C++ still has a lot of good features. It’s just a bit irritating that because of a bad feature (and some other features too, such as some forms of operator overloading), I must know the details of every type and function on a line of code to be absolutely sure what it’s doing.

If you don’t even know what Bitcoin is, it is a distributed and decentralized currency that operates over the Internet. There is no central bank or issuer; there are no regulators. The network as a whole decides what the rules are, and the source code for the official Bitcoin client is open. You can transfer Bitcoins to anyone, anywhere in the world, in about 10 minutes — and usually for free.

The topics I will cover in my series are:

• Basic overview: How to send and receive coins.
• Addresses: What an address actually is, and why you should care.
• The block chain: What the block chain is, and how this keeps the network secure.
• Mining: How Bitcoins are created, and why this is not “generating free money.”

If you can think of any other topics you would like me to cover, let me know and I will extend the series. If you want a bit more information right now, this video is a pretty good summary of the project:

So I was messing around with generic methods and discovered that generic constraints can be bypassed on Mono 2.6.7 and 2.8 using reflection (with the exception of the new() constraint). One of the fun results of this bug is that the String class can be made mutable without using reflection to set private members!

The following code demonstrates this; it is legal and will run on Mono up to and including version 2.8:

using System;
using System.Reflection;

public class FakeString {
    public int length;
    public char start_char;
}

public class TestCase {
    private static FakeString UnsafeConversion<T>(T thing)
        where T : FakeString
    {
        return thing;
    }

    public static void Main() {
        var a = "foo";
        var b = MakeMutable(a);

        Console.WriteLine(a);
        b.start_char = 'b';
        Console.WriteLine(a);
    }

    private static FakeString MakeMutable(string s)
    {
        var m = typeof(TestCase).GetMethod("UnsafeConversion", BindingFlags.NonPublic | BindingFlags.Static);
        var m2 = m.MakeGenericMethod(typeof(string));

        var d = (Func<string, FakeString>)Delegate.CreateDelegate(typeof(Func<string, FakeString>), null, m2);

        return d(s);
    }
}

This code outputs:

foo
boo

Smells like some fun exploits could be written taking advantage of this. Should Moonlight users be afraid? I’m not absolutely certain, but I think there might just be a way to do some damage.

I have decided to migrate away from Gmail for a variety of reasons. I figured I’d use my domain so that I have flexibility in my provider choice. For example, if I decide to change my mail provider I don’t have to get a new address. So this change should be permanent.

Now, being a tinkerer, I figured I’d set up a mail system for myself that retains the features I like from Gmail while doing away with the downsides of using Gmail. My final system is complicated, but effective. And it was a fun four days setting it up! (No, that wasn’t sarcasm. This is the kind of thing I enjoy.)

My MTA is Postfix, running on mail.chrishowie.com. It accepts mail for me and delivers mail from me. The standard security features are in place: SPF/blacklist checking and no unauthenticated relaying. I also established SPF records for my domain. I do not have a spam filter, but I might set up SpamAssassin later if I actually start seeing spam in my inbox; no spam has made it past the sender blacklist check yet.

For downloading mail, I set up Courier as a POP3 server. The observant will note that this would nullify one of the most useful aspects of Gmail: access to your email from anywhere. Once you download from a POP3 server and delete, your mail is gone from the server and lives in your mail client.

That’s where the rest of the rig comes into play. On my home LAN server I have a multi-piece system that provides me with this anywhere-access. I have a getmail4 cron job that fetches mail from my POP3 server, as well as from my Gmail account (so people can still reach me using my Gmail address), and some of my other mail accounts, and delivers the mail to my maildir using Dovecot’s delivery agent. From there, the agent processes my sieve rules, sorting my mail into various folders. (It’s like your favorite mail program’s “filters” only it runs on my server instead of my mail clients, so the configuration is centralized.)

For reading all this mail, I run Dovecot, an IMAP server. All my mail clients fetch mail from this server, and since it is IMAP, changes to messages (like moving a message between folders, or adding tags, or whatever) are actually pushed back to the server. So I can use several mail clients at once and they all have a consistent view of my mailbox.

The only major piece I have yet to set up is an LDAP server for centralization of my address book. The rest has been working quite well. I can use Thunderbird at home, or my mobile phone’s email client when I’m out of the house. No limiting or inconvenient web interfaces required.

Almost every IM client on the planet has the concept of a group. You create a group, give it a name, and populate it with your contacts. At first glance, this is useful.

Having used IM clients since the latter years of AIM’s domination, I have consistently struggled with the best way to group my contacts. To this day I have no solution. Why?

Because the group model is inherently broken in that every major IM client out there allows one group per contact. This assumes that each person I know has exactly one type of relationship to me. A contact cannot be a friend, coworker, family member, and developer. You must pick one.

This problem is exacerbated by multi-protocol clients. Not through any specific fault of their own, but when they support connecting to many different services, you suddenly wind up with an overwhelming number of groups with no coherent purpose. If you didn’t name your groups exactly the same, or you used a different grouping paradigm, you are SOL and must merge the groups somehow. This becomes an impossible mess when the service on the other end (Facebook, for example) allows contacts to be in multiple groups. Which group they wind up in on your IM client may as well be random, and may not even be the same each time you connect. (Edit: Since writing this I have discovered that the XMPP server operated by Facebook does actually indicate to clients when contacts are in more than one group. Pidgin honors this.)

What we need is a cross-service “tagging” mechanism that lets me say “this person is a coworker at X company, and worked with me on Y open-source project.” Then, whether I am looking for coworkers at X or codevelopers on Y, this person shows up. Rules could be established so that “coworker at X company” membership implies “coworker” membership. This may at first glance seem like nested groups, but it is very different. It is completely free-form, and allows me to model my contact structure after how I interact with people in real life. Not some bizarre mutually-exclusive set of too-shallow or too-specific relationships.

Multi-protocol clients should then support tag equivalency, so that service-mandated groups can be rolled into a differently-named tag. Or ignore one account’s groups entirely, with everyone being rolled into one tag, with the possibility of local memorization of extra tags.

But the way things stand now, having groups at all is actually a hindrance to my communication. “Did I put that person in friends or coworkers? Or are they still in the service-specific default friends/buddies/oxygen-converters group?”

In lieu of a real solution to this problem, I want to disable groups entirely. Except… whoops… Pidgin doesn’t even let me do that.

I welcome everyone’s thoughts on this issue.

In my clone, master is my “local” storage branch. I use it to version things like my .gitignore, and my commit message template. I would also use it for my dcommit/rebase scripts too, but since this is on Windows, Git becomes angry when it attempts to remove scripts that are executing.

Master is then the common root for my topic branches. I’ll do some work and commit, then do more work, as the usual Git workflow goes. The ability to create local branches and commits is great for several reasons:

First, I can commit much more often, without fearing that I will break somebody else’s working copy — I do frequently commit broken code now, because the commits don’t get sent to SVN automatically.

Second, and a side effect of the above, I am much more agile. Sometimes I’ll be working on two projects at once, and keeping separate branches for them means that the broken state of one branch does not affect my ability to build/debug another. This means I can even drop everything (after a commit or stash) and help out with an urgent QA or support issue, without either having lots of uncommitted work interfering or committing broken code to a production repository first.

Third, I can version changes I make to code that might make my life easier, but that would require approval to commit. I have not yet done this, but thanks to my local repository, it’s an option.

Fourth, I can develop against a stable codebase. If I need a specific fix from SVN to work, I can cherry-pick it into my topic branch — fetching commits from SVN does not mandate that my code must be merged with them. Along the same lines, I also have the ability to rebase all my topic branches against a specific SVN commit, which is great when somebody commits broken code that causes build errors or incorrect runtime behavior. If I were using SVN, I would either have to fix it myself, wait for the owner of the code to fix it, or revert to an earlier commit. And since commits are linear, that might mean I would lose some of my code. Git allows me to retain my commits while backing out changes made by others. And if I did already commit some of my changes after the broken code, I can still rebase master and cherry-pick my subsequent commits onto a new branch and continue my work.

And finally, I can review all my commits before pushing them out. I’ve had several occasions to fix up commit messages already.

Of course, I do eventually need to commit to SVN. I have a few scripts to help here. Obviously I don’t want to commit my local-only stuff in master. So I have one script that simply does git svn fetch && git rebase --onto git-svn master. For the Git-impaired, this fetches any new commits from SVN and adds corresponding Git commits on the git-svn branch. The rebase command then takes all the commits on the current branch since master’s latest commit, and applies them as patches to the tip of the git-svn branch, creating a new commit for each. This effectively removes the local changes I’ve made in master from the commits, as well as merges the changes in SVN into my commits. (If one of my commits fails to apply as a patch, then I have to resolve the conflicts manually, just like an SVN update. But in this case, I still retain all my individual commits.)

After running this script, I then git svn dcommit, which commits my local commits to SVN, one by one.

At this point, I usually run my post-commit script, which rebases master on to git-svn, then rebases all my other branches on top of master. I might not do this if I don’t want to rebase some of my other topic branches yet.

In closing, I leave you with my trick for changing commit messages. I used to use git filter-branch for this, which is like using a sledgehammer for surgery. (My similes are awesome, I know.) Now I use this process:

git checkout -b temp $COMMIT_TO_CHANGE (Create a new branch called “temp” at the commit I’m changing, and switch to it.)

git commit --amend (Open an editor to amend my commit. I change to message here, then save and quit. The temp branch now has the new commit, whose parent commit is the same as it was before being amended.)

git checkout $ORIGINAL_BRANCH (Switch back to the branch we are amending.)

git rebase temp (Rebase the branch on top of the amended commit. Since the original commit will be applied on top of the amended commit, it is dropped during the rebase. The other commits will apply with no conflicts. The history is now corrected.)

git branch -d temp (Remove our temporary branch.)

And there you have it. In a history with many thousands of commits, this is much faster than git filter-branch, and for those relatively fluent in Git, is also easier to remember how to do.

It’s no secret to my friends that I love to program… even more so as I’ve been developing a FarmVille client in C# and having them test it. (As much as you might hate FarmVille, you must agree that there’s a certain awesome factor in LINQ-to-FarmVille: service.Plow(from i in service.World.Objects.OfType<Plot>() where i.State == "fallow" || i.State == "withered" select i)

Well, among this project and others I consistently find myself writing the same code over and over. I know of many programmers who have developed personal toolkits for the languages they use frequently, but for some reason I’ve been programming for about 13-15 years now and haven’t ever built my own library. This application gave me an excuse to do so, and so I’ve started on the Cdh.Toolkit suite of libraries.

Here is a summary of the classes available:

• Cdh.Toolkit.Collections: Some useful collection types, all designed to be derived.
  • ReadOnlyCollection<T>, ReadOnlyDictionary<TKey, TValue>, and ReadOnlyList<T>: Wrappers around the corresponding interface types ICollection<T>, IDictionary<TKey, TValue>, and IList<T>, throwing exceptions on all write attempts. While there is a ReadOnlyCollection<T> as part of the .NET framework, it is not designed to be derived, and the other two classes do not have a counterpart at all.
  • SynchronizedCollection<T>, SynchronizedDictionary<TKey, TValue>, and SynchronizedList<T>: Wrappers around the corresponding interfaces. All accesses are synchronized against a ReaderWriterLockSlim, allowing for multiple concurrent read operations. The enumeration behavior can be specified as either lock, which holds a read lock for the duration of the enumeration, or copy, which creates a copy of the collection and enumerates it instead.
  • ObservableCollection<T>: A collection that fires events when modified. ObservableDictionary and ObservableList are currently not provided, due to some implementation complexities. However, the interfaces IObservableCollection<T>, IObservableDictionary<TKey, TValue>, and IObservableList<T> and some EventArgs classes are provided to allow developers to implement their own observable collections easily.
  • ObservableHashSet<T>: An observable and API-compatible wrapper around HashSet<T>.
  • ReadOnlyObservableCollection<T>, ReadOnlyObservableDictionary<TKey, TValue>, and ReadOnlyObservableList<T>: Wrappers around the IObservable* interfaces mentioned above. Events from the wrapped collections are forwarded. This allows one to have a read only observable collection without sacrificing the IObservable* interface, which would happen if such a collection were wrapped in one of the normal read only classes listed above.
• Cdh.Toolkit.Extensions: Extension libraries designed to ease the use of many classes in the .NET framework.
  • Collections: Extensions specific to collection classes.
    • TValue IDictionary<TKey, TValue>.GetOrDefault(TKey key): Returns default(TValue) if the key is not present in the dictionary.
    • TValue IDictionary<TKey, TValue>.GetOrValue(TKey key, TValue fallback): Returns fallback if the key is not present in the dictionary.
  • ComponentModel: Extensions specific to the System.ComponentModel namespace.
    • void ISynchronizeInvoke.AutoInvoke(Action action): Executes the action delegate on the ISynchronizeInvoke object if required, otherwise does so on the current thread.
    • object ISynchronizeInvoke.AutoInvoke(Delegate method, params object[] args): Executes the delegate on the ISynchronizeInvoke object if required, otherwise does so on the current thread, and returns the return value of that method in either case.
    • AsyncCallback AsyncCallback.Invoked(ISynchronizeInvoke obj): Returns a wrapper around the AsyncCallback delegate that will invoke it using the AutoInvoke extension above. Useful for async callbacks that need to operate on a Winforms GUI.
  • Enumerable: Extensions to enumerable objects.
    • IEnumerable<T> IEnumerable<T?>.NotNull() where T : struct: Returns all values from the non-null nullable objects in the sequence.
    • void IEnumerable<T>.Walk(): Enumerates the sequence, discarding all values obtained. Useful as an alternative to .ToList() when you need to make sure that a query executes, but do not need to use the result.
    • void IEnumerable<T>.CopyInto(IList<T> list): Copies a sequence into a list.
  • Events: Extensions that make writing event logic easier. All of these extensions return if the event handler in question is null, making event-firing code simpler and easier to read.
    • void EventHandler.Fire(object sender): Uses EventArgs.Empty as the event arguments.
    • void EventHandler.Fire(object sender, EventArgs args)
    • void EventHandler.Fire(object sender, Func<EventArgs> argsFactory): Calls the factory function only if the event handler is not null. Useful when construction of the event arguments can take a long time.
    • void EventHandler<T>.Fire(object sender, T args)
    • void EventHandler<T>.Fire(object sender, Func<T> argsFactory): Calls the factory function only if the event handler is not null. Useful when construction of the event arguments can take a long time.
  • ReaderWriterLockSlim: Allows these kind of locks to be used in a using() block, which makes code easier to read and maintain. They will also return a no-op IDisposable if a compatible lock is already held by the current thread, which makes non-recursive lock objects simpler to code with. (The return type is actually a value type that implements IDisposable, which means that usage of these methods does not incur any object allocation overhead.)
    • IDisposable ReaderWriterLockSlim.Read(): Returns an IDisposable that will release the read lock when disposed. This method returns a no-op IDisposable instead if the current thread already holds a read, upgradeable read, or write lock.
    • IDisposable ReaderWriterLockSlim.UpgradeableRead(): Returns an IDisposable that will release the upgradeable read lock when disposed. This method returns a no-op IDisposable instead if the current thread already holds an upgradeable read or write lock.
    • IDisposable ReaderWriterLockSlim.Write(): Returns an IDisposable that will release the write lock when disposed. This method returns a no-op IDisposable instead if the current thread already holds a write lock.
  • Reflection
    • T ICustomAttributeProvider.GetCustomAttribute<T>(bool inherit) where T : Attribute: Returns a typed attribute, or null if there is no attribute of type T.
    • IEnumerable<T> ICustomAttributeProvider.GetCustomAttributes<T>(bool inherit) where T : Attribute: Returns a sequence of attributes of type T present on the attribute provider.
  • Reflection.Emit
    • void ILGenerator.EmitTypeOf(Type type): Emits the IL sequence that will leave the same Type object on the execution stack.

  The amount of code is slim, but I’ve found at least one of the classes or extensions invaluable in every project I’ve worked on since starting the toolkit. It’s an interesting case where coding for a game actually winds up improving my productivity working on other software too.

  Eventually these libraries will be released under the MIT license, so stay tuned for another blog post with a link to the Git repository.

  (And yes, the above list will be converted into real documentation. Someday.)

  ]]> http://www.chrishowie.com/2010/01/27/when-farmville-productivity/feed/ 11