Friday, February 6, 2015

Avoiding the information madness

A while ago, a colleague asked how I tracked all the information that's coming in: Twitter, RSS, Facebook, blogs, podcasts,... It's easy to drown in all the information if you want. I won't pretend I have the ultimate strategy, but here's what I do.

Facebook

I'm not on Facebook for a variety of reasons (mainly this), but I don't miss it. So that's one information-source less to deal with.

Twitter

This has been my usage of Twitter:
  • Ignore the hype
  • Check out the hype, follow a handful of people
  • Love it and check it everyday picking up where I left of the day before
  • Start following more people; create lists
  • Whoa, too much! Just check it now and then to pick up anything interesting that was posted that last hour or so. Plus, use it when I write a blog post (self-promotion yay!) 
So I gave up any hope of keeping up with Twitter. Twitter is like entering a newspaper-shop. There's all sorts of magazines, newspapers, books, comics, etc. And you can't go there everyday and read it all. Just go there when you feel like it and read some stuff, check out any favorites, then move on.

RSS

Since Google Reader was discontinued, I briefly used The Old Reader, but after a while, I switched to Feedly. I can't really remember why I made the switch. Possibly because the Old Reader was experiencing load problems at the time (because thousands of developers were moving from Google Reader to the Old Reader). I hear it no longer has these problems, but in the mean time, I'm happy at Feedly.

I use NextGen Reader on my devices to connect to my Feedly. Great app.

Podcasts 

After following blogs for a while you collect a large amount of blogs to follow and read. Lately, I notice I don't take as much time to read them as I used to. Also, reading blogs is subject to ups and downs based on how busy work is, how busy home is, how I feel, etc.

Podcasts are my new information source. While you can't follow as many podcasts as you do blogs, the good ones provide a wide range of information. My commute is about 45 minutes which is perfect to follow several podcasts throughout the week.

Here's my selection, in no particular order:
There are definitely episodes that I skip, but not all too often. Here, again, you have to be able to skip content without feeling bad or getting the feeling you'll be missing life-or-death-crucial stuff.

Must read but have no time 

A final tip is to have a way of setting things aside for later. I use Pocket, but there's also Instapaper, and possibly others. I find it's easier to add stuff than it is to actually read any of it later, but now and then I do take the time to catch up.

Conclusion

It is hard/impossible to keep up with everything in our fastly-evolving world. And that is exactly why you shouldn't try. Just have a steady stream of information via the channels you are most comfortable with. You might miss out on the most minute details, but anything remotely important will be repeated by so many sources, you can't miss out.

Thursday, January 29, 2015

Wrapping an old-school callback-javascript method in a promise

When you have an older javascript library that supports asynchronous calls via callbacks, you might want to wrap them in a promise instead. Particularly if you're using Angular. For my own reference, this is how to do it. I'm using Angular's $q, but I suspect it should be more or less the same with Q.

Let's assume this is the method with the callbacks:

function goAsync(input, success, error) {
    try {
        // do something here
        success(result);
    } catch {
        error();
    }
}

Wrapping this in a promise is quite easy:

promiseObject.go = function(input) {
    var deferred = $q.defer();
    oldSchoolObject.goAsync(
        input,
        function(result) {
            deferred.resolve(result); 
            $rootScope.$apply();
        },
        function(e) {
            deferred.reject(e); 
            $rootScope.$apply();
        }

    return deferred.promise;
}

Notice how I call $rootScope.$apply after resolving or rejecting the deferred. This is so Angular starts its digest-cycle and the UI is updated.

Now you can use the promise:

promiseObject.go(input)
    .then(function() {})
    .catch(function() {});

You can see a live example of this in one of my GitHub repositories.

Friday, January 16, 2015

Synchronizing multithreaded incoming messages and unit testing

I'm currently developing a Windows service application that receives data from multiple sources. It isn't a highly concurrent application, but the incoming messages are come fairly fast after one another.

Incoming messages enter the system via WCF and that part is multithreaded. But these messages must be handled sequentially. What's more, certain pieces of our application must run at regular intervals.

We can experience problems if component A is running and changing objects in memory, and component B is triggered and starts using these same objects.

That's why we introduced a simple command queue:

public interface ICommandQueue : IEnumerable<Action>
{
    void Add(Action action);
    void CompleteAdding();
}


The implementation uses a BlockingCollection:

public class ThreadSafeCommandQueue : ICommandQueue
{
    private readonly BlockingCollection<Action> _actions = new BlockingCollection<Action>();

    public void Add(Action action)
    {
        _actions.Add(action);
    }

    public IEnumerator<Action> GetEnumerator()
    {
        return _actions.GetConsumingEnumerable().GetEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }

    public void CompleteAdding()
    {
        _actions.CompleteAdding();
    }
}

This means another class can loop over it and execute every action that is added. If the queue is empty, it will wait until a new item is added. You can read more on BlockingCollections for the ins and outs.

This is our implementation:

Task.Factory.StartNew(() =>
{
    foreach (var action in _queue)
    {
        action();
    }
}, TaskCreationOptions.LongRunning);

So, what happens is we add stuff that needs to be executed safely to this command queue:

_commandQueue.Add(() =>
{
    _something.Do(_input);
});

As you can see, you have access to private fields, as you're just passing in the entire Action to be performed.

Now the cool thing is this is entirely unit-testable. Because we're using a DI-container (Autofac in our case), we can inject a different implementation when we're testing. Because we don't want our Assert methods to start asserting if the Action hasn't been executed yet, we can inject the following when we're testing:

public class ImmediateCommandQueue : ICommandQueue
{
    public IEnumerator<action> GetEnumerator()
    {
        throw new NotImplementedException();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }

    public void Add(Action action)
    {
        action();
    }

    public void CompleteAdding()
    {
        throw new NotImplementedException();
    }
}

When an Action is added, it is immediately executed. So when we've done the 'Act'-part of our tests (see AAA), we can be sure there aren't any Actions still waiting to be executed.

But what this also allows us to do is control when the Actions are executed. Take this method:

public void Process()
{
    _a = new List<int> { 1, 2, 3 };
    _commandQueue.Add(() => { _innerProcessor.Process(_list); });
    _list.Clear();
}

This is of course a silly method, but bear with me. The point is that, at runtime, the innerProcessor might receive en empty list because we're clearing it immediately after we added the Action. But in our tests, this isn't very clear because we're immediately executing the Action.

So we can introduce yet another implementation of ICommandQueue, purely for testing purposes:

public class ManuallyTriggeredCommandQueue : ICommandQueue
{
    private readonly IList<Action> _actions = new List<Action>();

    public IEnumerator<Action> GetEnumerator()
    {
        throw new NotImplementedException();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }

    public void Add(Action action)
    {
        _actions.Add(action);
    }

    public void CompleteAdding()
    {
    }

    public void ExecuteNextAction()
    {
        var action = _actions[0];
        _actions.RemoveAt(0);
        action();
    }
}

Now, in our tests, we can call the Process method first, and only then execute the Action by calling ExecuteNextAction. This way we can get a failing test (because _innerProcessor.Process was called with an empty list instead of a list with 3 integers). And after a failing test, we can turn it into a green test:

public void Process()
{
    _a = new List<int> { 1, 2, 3 };
    _commandQueue.Add(() => 
    { 
        _innerProcessor.Process(_list);
        _list.Clear();
    });
}

I'm very happy with this solution. It's geared towards our domain, as we're not going to flood our queue because we won't be getting thousands of messages every millisecond. But it allows us to avoid threads getting in each others way, and our code remains testable.

Wednesday, December 31, 2014

2014 is so 2014

Another year has past, and I suspect many bloggers will be making lists of what happened in 2014 and what will happen in 2015. And so will I, but I'll keep it short.

These lists are actually quite handy, because they allow you to keep track of what your goals are and whether or not you met them. Depending on your situation, you might decide you slacked too much, or maybe you had too many goals. Or unrealistic ones. Or maybe you met all your goals and in that case, good for you!

Revisiting my post from the previous year, I can list what I achieved and what I didn't.

Didn't achieve:
  • Acquire 2 Microsoft certifications: this is a subject for a future post, but those who know me, know I'm in the non-believer-camp regarding certifications.
  • Finetune pwa.js, FlitsLogo: these are still on the mental to-do-list, but aren't very high in priority.
  • Migrate my blog: still very much want to do this.
  • Finish my course on beer: I've actually read and studied the material, but I still need to plan the exam.
  • Kitesurfing: oh well :)

Achieved:
  • Find and follow a good training: I attended ngEurope this year where I really learnt a lot. Also Techorama, but ngEurope was more interesting for me because it's outside of the traditional Microsoft-world where I'm in most of the time. (Though I will most likely be attending Techorama again this year)
  • Write a Drupal module: I did write a Drupal module for my frisbee team. Actually, I wrote several custom modules. There's still a lot of work to be done there, but I'm happy with what I have already. Also, it's already being used on a site with 140+ users.
  • Write a SPA: I wrote a web application to have a small contest with some friends during the World Cup. The code isn't pretty, but it worked and wasn't meant to be a long-term project anyway. But I did learn Angular that way.
Didn't plan, but achieved:
  • Start my own company: I am now a freelance developer, so that's exciting. More on that later.
  • Learnt Cordova: but I still regard myself as a beginner.
 And finally, plans for 2015:
  • Finish the Cordova mobile app I'm writing for my frisbee team
  • Push out some changes I've made to my 8cam Windows Phone app.
  • Maybe: rewrite FlitsLogo in HTML5 and javascript (using Cordova) so I can put it on multiple platforms
This list is definitely shorter than my 2014-list. But with starting my own company I suspect there might be a little less time, plus there are also personal/private goals I have set. And I tend to avoid putting too many private stuff on the internet.

So there is my list for 2015. Let's hope I can achieve these things.

And with that, I wish you a great 2015 and good luck with your goals!

Wednesday, December 3, 2014

ngEurope: recap

I've finished all my posts on ngEurope, so here's a small recap.

The conference itself was very decent, with some minor hiccups. Kudos to the organizers, and I hope to be able to attend it again. The sessions and speakers were very good, and it was really interesting (dare I say inspiring?) to see all the things that are happening in the Angular, javascript, and web world.

Here is an overview of my posts, which is an overview of what I found most interesting:
I think it's safe to say the web (both 'normal' and mobile) has a bright future. There are many promising projects being run by smart and enthusiastic people.

Of course, ngEurope focussed on Angular, and there are so many other frameworks and libraries out there. Will Angular stick around long enough for that long-term project? Or should you try another option? Or will all this javascript-nonsense fade away sooner or later?

Nobody knows the answer to this, but these questions can be asked about any technology stack. I'd be willing to bet the web will be around for quite some time. If Angular will too? I don't know. But it's been around for some time now (released in 2009) and has a growing community around it. At the moment, it seems a pretty safe bet to me. But of course, it depends on the specifics of your project, which might be something I discuss in a separate post in the future.

Tuesday, December 2, 2014

ngEurope: $q and promises

If you've dabbled with AngularJS, it's very likely you've encountered $q. At ngEurope, there was a session devoted to $q, which gave a good overview of what it can do.

The 'old way' of doing asynchronous programming in javascript, is to use callbacks. But when your application becomes more complex, this leads to nested callbacks, which are ugly, unreadable, hard to maintain,... But they're also not parallelizable, composable or dynamic.

With $q, you can stop the callback-madness. Instead of passing callbacks as parameters, you can start returning promises.

Using $q can seem a little confusing at first, but it is actually quite simple. Start by creating a deferred object with
$q.defer();
Then call
deffered.resolve()
when you're done.
A user of your API (which could be yourself) can then call:
getSomething().then(function() {});
But $q can do more than just that. It can run functions in parallel:
$q.all([getA(), getB()]).then(function(responses) {});
The all-function returns a new promise and will only resolve when all functions are done. The responses-argument contains the responses of both functions. Or, if you prefer to have the different responses as separate arguments:
$q.all([getA(), getB()]).then(spread(function(a, b) {}));
Promises can be composed:
var promise1 = foo();
var promise2 = promise1.then(...);
var promise3 = promise2.then(...);
The then-function returns a new promise every time.

Because promises don't force you to chain at write-time, you can make all this dynamic. For example, based on if-else statements, different arrays of promises could be built and executed.

Promises can also notify when something went wrong. The 'notifier' doesn't call deferred.resolve, but deferred.reject() instead. The receiver then has its second argument called:
getSomething().then(function() {
    alert('success');
}, function() {
    alert('error');
});
There is also a third arguments to indicate progress. This is a function that can be called multiple times, while resolve and reject can only be called once:
deferred.notify();
The when-function allows you to wrap functions/objects in a promise and return it. For example:
getMovies: function() {
    return $q.when(cachedMovies || fetchFromServer());
}
This allows for easy client-side caching. Even better would be to use this piece of code:
getMovies: function() {
    return $q.when(cachedMovies || p || fetchFromServer());
}
The 'p' variable should be set in the fetchFromServer-function and it should get the value of deferred.promise. This will avoid multiple http requests when we try to get the movies but haven't yet returned from the previous call.

$q is not the same thing as Q, although it is based on it. $q is aware of the digest loop and is used throughout Angular.

I encourage you to start using promises as they are used everywhere, not just in Angular. Plus, native promises are coming soon.

Friday, November 28, 2014

ngEurope: Software Patterns and Design

This session went into some of the patterns you see out there. A quick summary:
  • Services: these are injected singletons. They're an ideal place to cache application-level data, as a facade for the browser and third-party API's, or factories for instantiating other objects.
  • Databinding: this is just an implementation of the observer pattern.
  • Inheritance for services & controllers: Standard prototypal inheritance can be used with services and controllers, but it's recommended to avoid inheritance for page controllers.
  • Thick models: for example, instead of having a method isActive(item) on the controller, put the isActive method on the item itself. Prefer thick models with methods and behavior over having this in your controllers. This way, you can encapsulate your domain logic.
  • Directive proxy object: how can you communicate with a directive from a controller? We want to avoid coupling the directive tightly to the controller. With this pattern, the controller creates and owns a proxy. It doesn't need to know the directive. The directive can then bind to the proxy object.
  • Polymorphism and directives: move responsibilities that normally are in the directive to the model. The model can be switched for another, as long as it has the same interface.
Then some anti-patterns:
  • War & Peace controllers: very large controllers that do too much. Split it up in more controllers, services,...
  • Link Function of Doom: all code of a directive in its link function
  • Forgot About Dialogs Global state: services storing per page state and clearing upon route change. This is not what services are for.
  • Magical Prototype Chain Dependency: relying on properties up the chain, making refactorings/changes harder/more scary.
Don't ask yourself if it's "the Angular way". Ask yourself if it's good software (refactorable, testable, readable,...).