numist the fool

test multiplication via subclassing

2015-08-03T10:12:15-07:00

Note: This blog post may contain video or JavaScript effects that are illegal in feeds and will be removed by most readers/aggregators. Some styling may also be lost, but it should display perfectly if you open it in your browser.

Let's say I'm writing an RSS reader. (With apologies to Brent Simmons.)

And let's say that it will support a number of different services. In order to make it easier to write different implementations for each service, I might write Feed and Folder protocols to allow them to share a common interface. The Folder protocol might look something like:

@protocol Folder <NSObject>

@property (readonly, strong) NSArray<id<Feed>> *feeds;
- (void)addFeeds:(NSArray<id<Feed>> *)feeds;
/* … */

@end

With this protocol, I can implement concrete classes for each service, such as LocalFolder, FeedBinFolder, FeedlyFolder, etc.

But how do I test them?

Being Folder-compliant, all instances of these classes must maintain a common set of guarantees. For example, adding feeds with addFeeds: should cause those feeds to be accessible via the feeds property of the folder. That test could look like:

- (void)testAddFeed {
    id<Folder> testFolder = [self folder];
    id<Feed> testFeed = [self feed];
    [testFolder addFeeds:@[testFeed]];
    XCTAssert([testFolder.feeds containsObject:testFeed]);
}

I'd like to run this test against all the different types that conform to Folder, and this is made possible by test subclassing.

Here's a test superclass, filled with the tests I'd like to run on all my Folder-compliant types, configured by default to test LocalFolder:

@implementation FolderTests

- (id<Folder>)folder {
    return [LocalFolder new];
}

- (id<Feed>)feed {
    return [LocalFeed new];
}

- (void)testAddFeed {
    id<Folder> testFolder = [self folder];
    id<Feed> testFeed = [self feed];
    [testFolder addFeeds:@[testFeed]];
    XCTAssert([testFolder.feeds containsObject:testFeed]);
}

- (void)testAddThousandsOfFeeds {
    [self measureBlock:^{
        /* … */
    }];
}

@end

The interface describes the methods that subclasses should overload:

@interface FolderTests : XCTestCase

- (id<Folder>)folder;
- (id<Feed>)feed;

@end

To test the other Folder-compliant types, I implement subclasses of FolderTests like this one, for FeedBinFolder:

@interface FeedBinFolderTests : FolderTests
@end

@implementation FeedBinFolderTests

- (id<Folder>)folder {
    return [FeedBinFolder new];
}

- (id<Feed>)feed {
    return [FeedBinFeed new];
}

- (void)testFeedBinSpecific {
    /* … */
}

@end

At this point, I've written a total of three test methods. Running the test target, the console shows:

Test Suite 'All tests' started at 2015-07-31 11:30:55.855
Test Suite 'FolderTests.xctest' started at 2015-07-31 11:30:55.857
Test Suite 'FeedBinFolderTests' started at 2015-07-31 11:30:55.857
Test Case '-[FeedBinFolderTests testAddFeed]' started.
Test Case '-[FeedBinFolderTests testAddFeed]' passed (0.000 seconds).
Test Case '-[FeedBinFolderTests testAddThousandsOfFeeds]' started.
Test Case '-[FeedBinFolderTests testAddThousandsOfFeeds]' measured [Time, seconds] <…snip…>
Test Case '-[FeedBinFolderTests testAddThousandsOfFeeds]' passed (0.492 seconds).
Test Case '-[FeedBinFolderTests testFeedBinSpecific]' started.
Test Case '-[FeedBinFolderTests testFeedBinSpecific]' passed (0.000 seconds).
Test Suite 'FeedBinFolderTests' passed at 2015-07-31 11:30:56.351.
     Executed 3 tests, with 0 failures (0 unexpected) in 0.492 (0.494) seconds
Test Suite 'FolderTests' started at 2015-07-31 11:30:56.351
Test Case '-[FolderTests testAddFeed]' started.
Test Case '-[FolderTests testAddFeed]' passed (0.000 seconds).
Test Case '-[FolderTests testAddThousandsOfFeeds]' started.
Test Case '-[FolderTests testAddThousandsOfFeeds]' measured [Time, seconds]  <…snip…>
Test Case '-[FolderTests testAddThousandsOfFeeds]' passed (0.259 seconds).
Test Suite 'FolderTests' passed at 2015-07-31 11:30:56.611.
     Executed 2 tests, with 0 failures (0 unexpected) in 0.259 (0.260) seconds
Test Suite 'FolderTests.xctest' passed at 2015-07-31 11:30:56.611.
     Executed 5 tests, with 0 failures (0 unexpected) in 0.752 (0.755) seconds
Test Suite 'All tests' passed at 2015-07-31 11:30:56.612.
     Executed 5 tests, with 0 failures (0 unexpected) in 0.752 (0.757) seconds

I wrote three test methods, but XCTest ran five tests. If I wrote the most basic FolderTests subclass possible for FeedlyFolder, the effective test count would go from five to seven. If I then added a testRemoveFeeds test to FolderTests, it would be inherited by the test subclasses as well, raising the count further to ten.

This approach takes advantage of a powerful yet little known feature of XCTest; creating a test case subclass causes that class to inherit and run all of its ancestors' tests. This is really useful pattern for testing functional protocol conformances, such as our working example, or high level black box testing for classes that support configuration, like a database engine or compiler.

The example code behind the snippets in this post can be found here.

do it for the love

2014-09-11T10:23:21-07:00

am • a • teur noun ORIGIN late 18^th cent. : from French , from Italian amatore , from Latin amator ‘lover,’ from amare ‘to love.’

traits

2014-05-16T13:34:43-07:00

concrete protocols

I didn't know the term "concrete protocol" until fairly recently, but it was pretty easy to understand: a concrete protocol comes with default implementations for some of its methods. Foundation already flirts with the idea of concrete protocols with its collections' subclassing strategies—if you want to build your own array, you only have to implement -count and -objectAtIndex: in your NSArray subclass in order to support all of the other instance methods provided by the class. Written as a concrete protocol, it might look something like this:

@protocol NSArray <NSCopying, NSMutableCopying, NSSecureCoding, NSFastEnumeration>

@required
- (NSUInteger)count;
- (id)objectAtIndex:(NSUInteger)index;

@provided
- (NSString *)componentsJoinedByString:(NSString *)separator;
- (BOOL)containsObject:(id)anObject;
- (NSString *)description;
- (NSString *)descriptionWithLocale:(id)locale;
- (NSString *)descriptionWithLocale:(id)locale indent:(NSUInteger)level;
- (id)firstObjectCommonWithArray:(NSArray *)otherArray;
- (void)getObjects:(id __unsafe_unretained [])objects range:(NSRange)range;
- (NSUInteger)indexOfObject:(id)anObject;
- (NSUInteger)indexOfObject:(id)anObject inRange:(NSRange)range;
- (NSUInteger)indexOfObjectIdenticalTo:(id)anObject;
- (NSUInteger)indexOfObjectIdenticalTo:(id)anObject inRange:(NSRange)range;
- (BOOL)isEqualToArray:(NSArray *)otherArray;
- (id)firstObject;
- (id)lastObject;
- (NSEnumerator *)objectEnumerator;
- (NSEnumerator *)reverseObjectEnumerator;
// two dozen more methods…

Compared to subclassing, a concrete protocol lacks state of its own, but allows for multiple inheritence. To make the effects of this more obvious, let's look at a class that would obviously benefit from multiple inheritence: NSOrderedSet.

Today's NSOrderedSet is (almost) API-compatible with both NSArray and NSSet. It supports the fast membership testing and single-instance-storage semantics of sets, while also providing array-like indexing and iteration. It's perfect for things like Switch's window list interface. Yet NSOrderedSet inherits from NSObject.

In a world with concrete protocols, the declaration of NSOrderedSet would look like this:

@interface NSOrderedSet : NSObject <NSArray, NSSet>
@end

Unfortunately, this example also reveals a flaw in concrete protocols as tools for composition: conflicts. Among other methods, both protocols provide -containsObject:. There are a number of solutions to this problem, including using the protocol ordering in the class declaration for precedence, or assigning efficiency factors to the implementation of each provided method to be resolved when the class is registered with the runtime.

Luckily, there's a better way.

traits

The paper on traits—which is super readable and not very long—was published in 2003; it provides a solution for conflict resolution and also explores how traits compare to multiple inheritance, single inheritence, and mixins. The conflict resolution is pretty simple: conflicting method implementations in inherited traits get aliased and the method becomes required. Classes resolve the conflicts by implementing the method and either forwarding the call to one of the aliased methods or providing their own implementation. The net of this for something like ordered sets is that an ordered set for Objective-C can be written in less than 150 lines, a third of which are conflict resolution.

Traits—like protocols—can inherit from other traits, so the NSArray and NSSet traits could inherit from NSFastEnumeration, which could inherit from NSEnumerable, which could provide map, reduce, and filter. This represents a case of the diamond problem that is trivially resolved with traits because of the absence of state; the methods are the same, so the conflicts that would arise from their need for state are managed at the level of the required state accessors.

This makes traits really powerful for building tools. Want a priority queue that supports all of the methods of an immutable array? 80 lines of code. Future possibilities for traits that aren't elucidated in the paper are also really exciting—what if you could write a category for the NSSet trait that returned a new set representing the union, minus, or intersection with another set¹? You'd be extending not only NSSet, but also any type that wants set-like behaviour.

learning by doing

In order to explore the effects of traits, I wrote Traitor. It is a basic implementation for Objective-C that performs all of the safety checks that traits support as early as possible in the execution of the application². This means that classes that are dynamically registered with the runtime can't use traits, but otherwise there should be no problems at runtime due to problems with traits. Reinventing arrays and sets was annoying, but the power of being able to leverage them both in new classes was eye-opening, especially when all the collection classes gained list comprehension methods just from adding a single trait to the hierarchy.

¹ NSMutableSet implements set operations already, but they are destructive. Why doesn't NSSet implement set operations, anyway?
² Trait correctness can be statically checked, but Only Apple Can Do This™.

a new kind of timer

2014-04-22T12:24:01-07:00

Subscriptions and locks commonly come with APIs that require balanced calls, but they represent a subclass of a larger pattern of managing resources that must be freed. In the case of global notifications, the observer causes system resources to be allocated for notification dispatch, and that all needs to be cleaned up when the observer is no longer interested.

Another pattern of resource allocation is when dealing with file descriptors, which are easy to forget to close in sufficiently complicated codebases. A solution to this problem is an idiom known as Resource Acquisition Is Initialization, which NSFileHandle implements¹. There are still some areas where this paradigm isn't present in Apple's APIs, such as NSDocument and NSMachPort, but today we're going to look at NSTimer.

From the perspective of RAII, NSTimer is a disaster. Instead of maintaining an unsafe reference to its target like NSNotificationCenter, an instance of NSTimer retains its target until it's invalidated. Furthermore, the timer itself is retained by the run loop to which it is registered. Since a reference to the timer must be maintained in order to manually invalidate it, the resulting object graph is strong back references plus a retain cycle:

Since NSTimer is responsible for allocating scheduler resources on behalf of its target, and anything involving the run loop should be an implementation detail of the timer itself, the object graph from the perspective of the client should look like this:

We could solve this problem with a proxy that stands in for the target to avoid the reference cycle, plus another proxy that stands in for the timer and invalidates it in the pattern of NNSelfInvalidatingObject. The resulting relationship graph would look like:

This still sucks, and doesn't change the fact that NSTimer also has awkward API issues. Clients shouldn't have to know about run loops in order to be called after a delay² or on a periodic basis. In fact, there's a lot that can be safely removed from NSTimer's API:

invalidate: Even though the timer won't necessarily be destroyed immediately, it has to be retained somewhere during its lifetime and checking if (self.timer != timer) { return; } is already a common and safe pattern for target-action style method invocations in Objective-C.
isValid: It's tempting to argue that non-repeating timers need this API, but its purpose in NSTimer is mainly to ensure that the timer isn't retaining the target anymore. The purpose of non-repeating timers is to cause side effects. One of those side effects should be to dispose of the timer.
Non-repeating timers: If a timer should only fire once, the method that it invokes can clean it up. If it's important that a timer existed in the past and did fire, then it's best to admit the extra bit of state as a property than to prolong the in-memory lifetime of an invalid, useless object.
Run loops: Timers shouldn't make threading guarantees. Since we're not in a perfect world, a good compromise is to offer the option for the timer to fire on either the main thread, or on a background thread.
NSInvocation: NSInvocation is an implementation detail of NSTimer and long-lived invocations are the root of its strong reference issues, since they only store argument and target references either strongly or unsafely. We could rewrite it to reference its target weakly, but invocations aren't used often enough to be worth it—NSTimer should support blocks instead.
fireDate: NSTimer supports this for irregular timers, and the same mechanism can be achieved by making the time interval a mutable property of the timer, further reducing the scope of the API.

These changes leave a simple new API that easily replaces NSTimer:

@interface NNTimer : NSObject

+ (NNTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)seconds
                                      block:(dispatch_block_t)block
                                      queue:(dispatch_queue_t)queue;
+ (NNTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)seconds
                                     target:(id)target
                                   selector:(SEL)aSelector
                                   userInfo:(id)userInfo
                                      queue:(dispatch_queue_t)queue;

@property (nonatomic, assign, readwrite) NSTimeInterval timeInterval;
@property (nonatomic, strong, readwrite) id userInfo;

- (void)fire;

@end

GCD and weak references didn't exist when NSTimer was created, so the resulting implementation is super simple:

#import "NNTimer.h"

@interface NNTimer ()

@property (nonatomic, readwrite, assign) NSUInteger mutationCounter;
@property (nonatomic, readonly, strong) dispatch_queue_t queue;
@property (nonatomic, readonly, strong) dispatch_block_t job;

- (void)_enqueueNextJob;

@end

@implementation NNTimer

+ (NNTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)seconds
                                      block:(dispatch_block_t)block
                                      queue:(dispatch_queue_t)queue;
{
    NNTimer *result = [NNTimer new];
    
    result->_timeInterval = seconds;
    result->_job = block;
    result->_queue = queue;
    [result _enqueueNextJob];
    return result;
}

+ (NNTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)seconds
                                     target:(id)target
                                   selector:(SEL)aSelector
                                   userInfo:(id)userInfo
                                      queue:(dispatch_queue_t)queue;
{
    NNTimer *result = [self scheduledTimerWithTimeInterval:seconds
                                                     block:nil
                                                     queue:queue];
    
    __weak id weakTarget = target;
    __weak NNTimer *weakTimer = result;
    result->_job = ^{
        __strong id strongTarget = weakTarget;
        __strong NNTimer *strongTimer = weakTimer;
        if (!strongTarget || !strongTimer) { return; }
        
        // Calling the IMP directly instead of using performSelector: or
        // performSelector:withObject: in order to safely shut up the compiler
        // warning about potentially-leaked objects.
        IMP imp = [strongTarget methodForSelector:aSelector];
        void (*imp1)(id, SEL, id) = (void *)imp;
        imp1(strongTarget, aSelector, strongTimer);
    };
    
    result->_userInfo = userInfo;
    
    return result;
}

- (void)setTimeInterval:(NSTimeInterval)timeInterval;
{
    self->_timeInterval = timeInterval;
    self.mutationCounter++;
    [self _enqueueNextJob];
}

// -fire makes two mutually-exclusive promises. One is that the job is executed
// synchronously, the other, less-obvious, promise is that the job is run on
// the same queue (or in NSTimer's case, run loop) as the scheduled firings.
// NSTimer opts for the simplest solution of keeping the synchronicity
// guarantee, and so does NNTimer.
- (void)fire;
{
    self.job();
}

- (void)_enqueueNextJob;
{
    NSTimeInterval nonNegativeTimeInterval = self.timeInterval >= 0.
                                           ? self.timeInterval : 0.;
    int64_t delta = nonNegativeTimeInterval * NSEC_PER_SEC;
    dispatch_time_t delay = dispatch_time(DISPATCH_TIME_NOW, delta);
    
    NSUInteger mutationsAtSchedulingTime = self.mutationCounter;
    __weak __typeof(self) weakSelf = self;
    dispatch_block_t block = ^{
        __strong __typeof(self) strongSelf = weakSelf;
        
        if (!strongSelf) { return; }
        if (mutationsAtSchedulingTime != strongSelf.mutationCounter) { return; }
        
        [strongSelf fire];
        [strongSelf _enqueueNextJob];
    };
    
    dispatch_after(delay, self.queue, block);
}

@end

Something shaped very much like this is going to land in NNKit soon. Stay tuned!

¹ NSFileHandle also implements close, the use of which leaves a useless dead object. If you find yourself using close, you have architectural problems.
² Before anyone says it, if you don't need invalidation, such as with delayed initialization, just use dispatch_after.

destroy dealloc

2014-04-09T13:33:23-07:00

ARC obliterated entire classes of bugs by automating memory management in acyclic contexts and providing zeroing weak references. Thanks to this, many classes no longer need to perform any cleanup during object destruction. The most common reason for dealloc these days? Notifications.

Broadcast messaging is vital to today's applications, but NSNotificationCenter has resisted modernization. Among its modern failings, its API enables fragile usage and it stores unsafe references to observers.

Karl and I were discussing the error-prone nature of APIs that require bracketed calls, like mutexes that conform to NSLocking¹ and addObserver:selector:name:object:/removeObserver:name:object:. He posed the question: how do we get rid of bracketing APIs? To start with, how can we make NSNotificationCenter support weak observers?

The answer, of course, is a proxy whose lifetime is tied to the observer using object association:

The only API the proxy needs to provide is an initializer:

@interface NNWeakObserverProxy : NSProxy

- (instancetype)initWithTarget:(NSObject *)target
                      selector:(SEL)selector
                          name:(NSString *)name
                        object:(id)sender
       addToNotificationCenter:(NSNotificationCenter *)notificationCenter;

@end

The implementation is pretty simple: the proxy adds and removes itself from the notification center in its own initialization methods, the target is stored weakly so in the time between target and proxy destruction the message is safely dispatched to nil, and the message forwarding machinery is minimal.

@interface NNWeakObserverProxy ()

@property (nonatomic, readonly, weak) NSObject *target;
@property (nonatomic, readonly, assign) SEL selector;
@property (nonatomic, readonly, strong) NSString *name;
@property (nonatomic, readonly, strong) id sender;
@property (nonatomic, readonly, strong) NSNotificationCenter *notificationCenter;

@end


@implementation NNWeakObserverProxy

- (instancetype)initWithTarget:(NSObject *)target
                      selector:(SEL)selector
                          name:(NSString *)name
                        object:(id)sender
       addToNotificationCenter:(NSNotificationCenter *)notificationCenter;
{
    _target = target;
    _selector = selector;
    _name = name;
    _sender = sender;
    _notificationCenter = notificationCenter;
    
    [_notificationCenter addObserver:self selector:_selector name:_name object:_sender];
    
    return self;
}

- (void)dealloc;
{
    [_notificationCenter removeObserver:self name:_name object:_sender];
}

#pragma mark Message forwarding

- (id)forwardingTargetForSelector:(SEL)aSelector;
{
    if (aSelector == self.selector) {
        return self.target;
    }
    
    return self;
}

@end

Lastly, a method in a category on NSNotificationCenter to tie it all together. Its primary responsibility is encapsulation, ensuring that the proxy's lifetime is tied as closely to the lifetime of the observer as possible:

- (void)nn_addWeakObserver:(id)observer selector:(SEL)selector name:(NSString *)name object:(id)sender;
{
    NNWeakObserverProxy *proxy = [[NNWeakObserverProxy alloc] initWithTarget:observer
                                                                    selector:selector
                                                                        name:name
                                                                      object:sender
                                                     addToNotificationCenter:self];
    objc_setAssociatedObject(observer, (__bridge const void *)proxy, proxy, OBJC_ASSOCIATION_RETAIN);
}

This was simplified to fit in a blog post so it has a few limitations, such as the inability to remove the observation without destroying the observer itself, but it offers a glimpse into a future topic. Stay tuned!

edited on wednesday april 9^th, 2014 at 13:33 (PDT):

Dave Lee pointed out that the proxy can use forwardingTargetForSelector: instead of forwardInvocation:. This is not only much faster, but also eliminates the need to cache the method signature. The code has been updated to take advantage of this. Thanks Dave!

¹ Less error-prone approaches for mutexes include @synchronized and the modern APIs that take blocks

derry

2014-03-15T20:11:23-07:00

It's been a while since a photo post from our Europe trip, and the Derry portion would be best shared with a story. Especially like it because it illustrates how we travel. Not in vacation, but in life.

We arrived in Derry by bus, and made our way to the hostel to drop off our backpacks before exploring. An old city by anyone's standards, Derry was a focal point for The Troubles, during which time the original city walls were augmented with solid metal and chain link spans to keep the nationalists and the unionists apart, with checkpoints at the openings. If you're paying attention to your surroundings, it's an unsettling place. The banners celebrating the "City of Culture's" upcoming events struck me as an intentional distraction to attract tourism, a veneer over a far more interesting place.

While walking around the old walls that encircle the old city, we came across some youths that were burning a car. A fire truck had responded, and they'd forced it to turn back with thrown rocks. One of them threw a bicycle through the windshield, pulling it out soon after but not before the grease in the bearings had ignited. The others were kicking at the doors and body panels, jumping on the horizontal surfaces, and generally enjoying the destruction. I was carrying a 50 at the time, so I had to go down the hill and get a closer look. I made myself obvious before shooting, and they took the opportunity to cover up their faces.

Shortly after taking that photo my camera and I almost got taken out by a kid armed with a stick, and that emboldened the rest of them. I got out of there as calmly as possible to avoid inciting a chase as they yelled and threw rocks at me. Back at the top of the wall, one of the locals introduced himself to us, having decided from his vantage point that we were his kind of crazy. He worked as a community youth organizer—he recognized some of the kids from his program—with the goal of peacefully bridging the boundaries in the city. Basically, reducing the incidence of this kind of stuff. We got a walking tour from him that easily beat the other walking tours of the city.

Night fell, we ate and returned to the hostel to sleep. Morning came, and we descended the stairs to the lounge to discover that it had been ransacked. The hostel had been burgled and all of the electronics stolen, including the phone I'd hidden behind the computer to charge. Everyone was a bit off-balance, and we got to talking about our experiences the day before. Someone recommended a pub for us to visit. We noted it, and walked to the police station to file a report first.

We went to the police station to file a report and it was one of the oddest complexes I've ever visited, a modern fortress. If you arrived by car, you were allowed through an armoured blast door and wedge barrier into an enclosed space with another armoured blast door, which you weren't allowed through until the police were sure the vehicle was safe. The history of the Irish car bomb suddenly felt viscerally familiar. Walk-ups were subject to slightly more relaxed security, though I noticed that there was always a minimum of bulletproof glass between us and the officers on duty. We filed an unremarkable report that would never help us get any closer to our stuff.

The pub that we'd been directed to was fairly deep in a nationalist area of the city, and it fell silent the moment we entered. The bar was dark wood, the wall behind it mirrored, and the barkeep and clientele decidedly Irish. A massive flag of Ireland hung on the wall opposite the bar. There were two free stools, so we sidled up and ordered pints of Guinness and Smithwick's. The man sitting next to me broke the silence once we'd had a sip, and asked where we were from. Cognizant of our experiences over the last 24 hours I said, "I'm Canadian," to which he immediately replied, "oh, happy day!" and everyone in the pub fell back into easy conversations with each other. They paid for our drinks.

We shared our travel experiences thus far in Ireland, having visited both the nation and the territory, and got a local's perspective on things in return. The kids were mostly upset because they'd grown up in angry households, but the parents were violent for a cause; kids these days are angry, but the violence is senseless, untargeted. People were still fighting for nationalism, and a new form of IRA was coming about, but they were extremists and the real fight was being waged mostly with currency and politics, not weapons. As we asked questions, they increasingly responded with not answers, but stories. They made a point to note that they were all peaceful these days. What a strange thing to say. My instincts told me that we were onto something; at this point the parlance was especially curious, authoritative. Having made enough hints without a negative reaction, my new barmate took us to the flag on the wall and moved it aside, revealing a collage of photos from the 70s, 80s, and 90s. Promonently placed was a photo of him, a lit Molotov in one hand as he ran towards a British tank to scoop a child from its path. It looked like an image search for The Troubles in Derry, and the faces in those photos were recognizably sitting at the bar behind us. We learned history from the people who made it.

sunset piano

2013-09-02T09:18:53-07:00

a t o

2013-03-11T16:59:09-07:00

trailing governments

2013-02-04T11:58:23-08:00

“It’s really hard for the government to censor things when they don’t understand the made-up words or meaning behind the imagery,” said Kevin Lee, COO of China Youthology, in conversation at the DLD conference in Munich on Monday. “The people there aren’t even relying on text anymore It’s audio, visual, photos. All the young people are creating their own languages.”Mike Isaac, AllThingsD via Bruce Schneier

Combined with an earlier article written by Schneier, speak to an unsurprising and systematic lack of understanding of technology by the government, and I think this scales well to any person in a position of leadership who doesn't really care about the issues at hand. Cybersecurity initiatives are a great way for representatives to gerrymander benefits for their constituents, but I'm not convinced that many of them actually understand what they're talking about.

My dad, a professor of engineering at SJSU, does care about the topics he teaches, and I'm often the target of his questions. Some time ago, he asked me to formalise a definition for The Cloud. First, my father is a more advanced troll than I ever realised.Second, exploring this was a journey though people's misunderstandings of technology—as you'd expect from formalising any buzzword.

The cloud used to be the server side of a client-server relationship, with an emphasis on server clusters and massive scalability. As the term caught on and became a buzzword, and as many of my friends and I were working at VMware at the time—a company that was in a unique place to provide private cloud solutions—we quickly started using The Cloud as an expletive when something was broken or someone was making buzzword gumbo. Thus I can now define The Cloud as:

The component in a product or service which, when broken, cannot be fixed by even the most competent end user.
Magical marketing fairy dust.

visiting cities in ireland

2013-02-02T20:54:38-08:00

Our next stop was Ireland, so there was a lot of travelling. By foot IMG_0387.jpg By rail IMG_5853.jpg And by plane (not pictured). We found Ireland very welcoming to travellers, even the children were happy to see us. IMG_0092.jpg In Dublin, we stayed at a place we'd booked via AirBnB, partially due to the promise of tea and soda bread every morning. IMG_5889.jpg In the spirit of underpromising and overdelivering, our host was fostering A KITTEN! IMG_0125.jpg Until visiting, I didn't really appreciate the importance of music in Irish culture. Music is everything and everywhere in this place, and it's great. Even the buskers were talented and well-practiced. IMG_5909.jpg And obviously a visit to the capital of Ireland wouldn't have been complete without some dancing. IMG_0356.jpg Unfortunately, we discovered that foreigners outnumber Irish folk in Dublin. One night, the only Irish in our pub were the waitstaff and the musicians, so we decided we should move on to get a better feel for the country and its people.