Tag: delegate

Migration – Weekly Article Dump

Migration - Weekly Article Dump

Migration: Bye to the Pi

Well… it happened. If you checked in earlier this week, you might have noticed Dev Leader was completely down on Thursday. Quite a bummer… but the show must go on. Migration to a new host was necessary, but that wasn’t without some hiccups.

For me, having a site hosted was still a pretty new process. I had tried it a couple of times before, but running a web server that I controlled always felt better. Just more control I suppose. Migration started off sort of sour where I was required to re-install WordPress on my host a few times due to some technical difficulties… And of course, it was hard to sit still while I knew my site was down. Once I finally had WordPress launched, the only part of the migration that went smooth was having a backup of my site four hours before it went down. Talk about timing!

There’s silver lining in everything though, and this little migration blip was no different. My Raspberry Pi was a fun little box, but it wasn’t fast by any stretch of the imagination. Page loading times were a bit slow, and serving images could sometimes be terrifyingly slow. Now that the site is hosted, there should be a very noticeable performance improvement. Additionally, with the new host comes some additional reliability! That’s always awesome.

See? Migration wasn’t so bad after all, I guess! My list of things for any WordPress user to be doing regularly:

  • Back up your posts
  • Back up your comments if your readers are actively engaged in discussions
  • Back up the media you use on your blog
  • Export your plugin settings
  • Keep a list of plugins you have running

Even if you don’t have a plan for host migration any time in the near future, it’s always good to have the “worst case scenario” covered. The plugin BackWPup covers basically everything I mentioned above, so I’d recommend getting that setup if you don’t have any backup plan currently in place!


  • Feedback is the Breakfast of Champions: 10 Tips for Doing it Right: Anyone in a leadership position knows just how valuable being able to provide feedback is. Heck, anyone who is driven to improve themself craves feedback. Joel Peterson provides an awesome list of tips for being able to provide feedback. I’d say frequency, positivity, and confidentiality are among the top take away points from his list.
  • 10 ways to make your .NET projects play nice with others: First programming article in the list this week. I thought this one stood out because I think anyone working in a team has either heard some (most) of these or is trying to work through them. Troy Hunt has put together a list of 10 things that any developer working in a team should be conscious of to make sure their code plays well with their teammates. Number one on the list is the same as my number one. “Works on my machine” carries no validity. Why? Your customers don’t have your computer. It’s a frequent thing when working with the QA team and developers want to cover their butts… But it won’t cut it!
  • Only 13 percent of people worldwide actually like going to work: Had to share this one, because if the stat is real, it’s scary. It’s scary to think that almost 90% of people that go to work don’t actually like going. In Jena McGregor‘s article, this low rate is attributed to poor working conditions, job availability, and job engagement. On the bright side for us North Americans, we’re a bit higher at just under 30%. That’s still far too low for something we spend a majority of our lives doing. It’s important to find a company you can get behind, and I definitely lucked out with Magnet.
  • The New Science of Who Sits Where at Work: Rachel Feintzeig shared an interesting article about seating in the workplace. I’ve shared some articles before about open concept offices and that I do enjoy working in them, but the seating perspective is pretty interesting. For example, changing your org hierarchy is one thing but unless people are changing their daily interactions, it won’t have that big of an effect. However, if seating arrangements are responsible for 40-60% of people’s daily interactions, simply moving people around will really stir the pot.
  • What is the Biggest Mistake Managers Make?: In John Murphy‘s article, he points out something that is probably less obvious than it should be. The biggest mistake a manager can make is focusing on the wrong things. He provides some steps to help align managers with the goals of their company to ensure that focus is in the necessary areas.
  • 8 strategies for successful culture change: Culture is something that is dynamic and always evolving within a company, but often there are things that are core to the company culture. What happens when you need to make some work culture changes? Michelle Smith shares some tips on how to approach a work culture shift.
  • Why Inspiring Leaders Don’t Sweat: Here was an article that hit home with me because I’m guilty of it. Panicking. Why is it bad if you’re panicking in a leadership position? The biggest problem is that your teammates will pick up on it and switch to a panick state too. It’s incredibly demotivating, and it’s usually at a time when motivation and inspiration is truly needed. In Steven Thompson‘s post, he talks about how and why to keep calm and lead on.
  • 3 Proven Ways to Make Tough Job Decisions: Jennifer Dulski discusses three approaches for helping make tough life and career decisions. At some point or another, most of us will be faced with making a decision in our career path that’s going to be difficult–difficult for you to decide or difficult for you to explain to those you’re close to. I think the “Sit With” approach is my favourite of the three.
  • 4 Ways to Have a Life Outside Your Business: This one should probably hit home with anyone working in a startup or running a business. Alexa von Tobel shares four tips for how to have a life outside of work and why having a life outside of work is necessary to be successful. I think something that’s often overlooked (somehow) is “me time”. I’m guilty of it too, but you get to a point when you’re not doing anything just for yourself. It’s great to be dedicated to your company and be passionate about your work, but it’s also importnt to step back, take a breath, and do something just for you.
  • 17 Things The Boss Should Never Say: Dave Kerpen has another great article on what not to say–this time from the boss’s perspective. Some of the worst ones in my opinion? Telling your teammates it’s only their problem (or not yours, at least) or being adamant about not evolving your perspective/processes. Some gems in there from quite a few business owners.
  • 9 Lessons From the World’s Best Mentors: This one is pretty quick from Chester Elton, but there’s a few different perspectives shared in here. Sone key points in my opinion are ensuring that you’re doing what you can to help others and not getting paralyzed by risk.
  • Key Reasons Delegating Is SO Difficult and What To Do About It: Most new managers and leaders have this problem. How do you delegate work? Perhaps you acquired your management or leadership position because you proved that technically you were very capable in your position. So how do you get others to do work you think you could be doing? Judith Sherven shares some insight on why being able to delegate is an incredibly important skill as a leader. After all, being able to grow as a leader means being able to effectively delegate responsibilities.
  • Want Greater Employee Engagement? Develop Intrapreneurs: In this article, Larry Myler talks about increasing employee engagement by developing intrapreneurs within your organization. It’s inline with what Tayun’s guest post was about the other week. Provide people autonomy and let them execute on their strengths. It’s a sure-fire way to increase engagement.

That’s it for this week! Hopefully there won’t be any more emergency host migrations any time in the near future (or ever again). Follow Dev Leader on social media outlets to get these updates through the week.

Nick Cosentino – LinkedIn
Nick Cosentino – Twitter
Dev Leader – Facebook
Dev Leader – Google+
Nick’s CodeProject Articles

You can also check out Dev Leader on FlipBoard.

Example: Getting Data Back From An EventHandler


I previously wrote about why I like to use events here and here. I figured it would be appropriate to illustrate a simple case where you can delegate decisions between functionally separate parts of code (say, between an application layer and a presentation layer). If you’re well versed in C# and .NET, this might put you to sleep. If you have no idea what I’m talking about, hopefully this will help. By the end of this, hopefully you’ll have a better idea for how you can use an EventHandler to pass data/state back through an invoked event… And don’t forget to check out the code!

The Scenario

Let’s assume we have a layered application, which is usually my go to. I might have three layers: one for data persistence, one for my business logic and one for interacting with the user. I’ll call these the data, application, and presentation layers, respectively. Let’s also assume that the dependency flow works from the top layer down (so presentation layer depends on application and data, and application depends on data). Nice.

In my application layer, I have a class that can process data. Specifically, it can capitalize an input string and spit out the capitalized output. However, some input characters are not letters A-Z or a-z… So how should our processor behave? Let’s have it delegate this decision to the user (who interacts with the presentation layer) and get back our result.

The Workflow

The following is the workflow for the application:

  • Create a processor object
  • Hook on the event handler so that the presentation layer can handle the corresponding event
  • Start processing the input
  • Capitalize valid characters
  • When we reach an invalid character…
    • Call our data processor’s event to delegate the work to anyone who can make the decision for us (in this case, our presentation layer)
    • Have the event handler (the presentation layer) ask the user if we should skip the input
    • Store the result back on the event args
    • Back in the processor class, based on the result of the event args, we can skip or add the character.



It’s a pretty straight forward task really. Because event args are objects in C#, we can store state on them and pass them around easily. If they were value types, we’d have to rely on function calls to return the user’s decision as to whether or not we should skip the input. In my opinion, this is a bit uglier (but certainly still doable).

I’ve created a sample project and hosted it at Google Code, here. Check it out!

Why Events? Decoupling.


Previously, I wrote about how events provide you with flexibility in your code. If you take on an event-based paradigm, you can view your system as a group of components that have events execute when certain conditions are met, and less of a procedural view where X always must occur after Y. But what else do events let us do? Decouple your architecture! We all know decoupling is a beautiful thing, so let’s see how it’s done.


How Events Decouple Your Code

So the big question then is, how? I’d like to start by providing framing an example architecture. If we assume that we have code that is decoupled by major functionality, we might have some sort of layered architecture. This could mean that we have three layers: presentation, application, and data. These layers would be responsible for user interaction, core business logic, and data storage/retrieval respectively. Let us also assume that the knowledge of layers flows from the top down. In our example, the data layer knows only of itself, the application layer knows about itself and the data layer, and the presentation layer has access to all three. It’s essentially just the flow of dependencies. Great. So where is this going?

If you’ve structured the various components in your system to take advantage of events, C# events provide us with a pretty awesome signature: you get the sender of the event, and a little magical parcel of data called EventArgs. Now let’s recall that in my previous posting, I mention that an event is really just a type of delegate. What does it mean to delegate? Literally, what does it mean? The great Google tells me: “Entrust (a task or responsibility) to another person, typically one who is less senior than oneself”. There. The secret of decoupling. My code can’t take responsibility for doing something, so I should tell whoever is interested that now might be a great time to do something.


Let’s See An Example!

Let’s continue off of the sample architecture that I already started off with. So we have our three layers. Let’s pretend we have some sort of import process where we read in lines of a file. Every line in the file is supposed to have two values, separated by a comma. This is all done by an importer class in our data later. Sounds easy.

Now, I’m not suggesting this is something you’d actually want in your application, it’s simply to demonstrate my point. So let’s pretend that the source of our data could sometimes be poorly formatted. Our import function can easily know about this (i.e. it splits the line on a comma, and finds out that there are not exactly two values). But does it know how to resolve it? Is it supposed to skip it? Is it supposed to magically figure out how fix it? Does it crash and burn? Wait… Maybe it’s not responsible for making that decision… So who is?

Invoke that event! If your importer class has an event, let’s say, LineFormatError, then someone on the outside can subscribe to it. Maybe my presentation layer can subscribe to it and, through event args, tell the invoker of the event (my importer class reference, of course) how to handle it. The flow could look something like this:

  1. Hook your necessary events up, so something in the presentation layer hooks on to my importer’s event for line format errors.
  2. Start your import.
  3. Upon hitting a poorly formatted line, invoke the LineFormatError event.
  4. The presentation layer receives the event (so now we’re in the “event handler”).
  5. The presentation layer could use information provided in the event args to ask the user if they want to skip the line.
  6. Based on the user’s decision, the presentation layer sets some information on the event arguments that says whether or not to skip it.
  7. The control goes back to the data layer where it checks the event args for what to do–skip or abort.
How is this decoupled? Well, quite simply, you don’t have your data layer directly showing message boxes to the user to decide what to do. It has absolutely no idea that there’s even a message box being shown… it doesn’t care! It simply agrees that it’s not responsible for making the decision of whether or not to skip or abort, but let’s someone else handle it. It delegates the decision through an event.



Events are beautiful things. Leverage them, and you can take advantage of some really decoupled code. Your various components often can’t be responsible for certain tasks, but using events, these components can delegate the decisions to other parts of your code that are certainly responsible for making the decision.

Why Events? Flexibility.


There are many different approaches to developing software, but in my opinion, the opposite ends of the spectrum end up being:

  • Knowing how the whole system looks, feels, and operates before coding a single line.
  • Having an idea of what the user wants and coding to make it happen.

Although I’m generalizing a lot here, it’s sort of like the battle between Waterfall and Agile. Okay, great. So what am I rambling on about here?

Well, in the first case, you know all the ins and outs of the system. You can structure your system so that almost no matter how complex it is, you can ensure that method A is always run immediately after method B which is etc… The design is completely controlled. You have a spec for how all the components work together. The problem? Well, most of this will be reserved for another write-up, but in our case there’s no flexibility. If that spec changes after your complicated system is already in place, how much code do you have to go change?


Enter: Events

Okay, so I hinted at why something like Waterfall might cause some headaches, but you don’t need to develop your software in an agile fashion to have flexibility. Events can help you with that!

If you’re not already familiar with what an event is, it’s simply a delegate that one would call when some particular criteria is met. In C#, which is what I’ll be assuming for this write-up, you add event handlers to an event so that when the event is invoked, the event handlers get called (and they get called in the order that they were “hooked” onto the event). Splendid.

So what’s great about events? How are they going to fix your brittle code? Well, if you approach software design in terms of components in a system and how they interact, it’s really beneficial to think about how certain things react to each other. If you’re planning your whole system out ahead of time, you could just always call method A, then method B, and then method C in order every time you want something in particular to happen. But is that flexible? What happens when method B now calls an additional method, let’s say method D, due to some architectural changes that had to be made. Well… That’s all fine and dandy unless you have scenarios where you don’t want to run D in your A,B,C method calls you have everywhere.

So, what if you had thought about it this way:

  • I want B to run once A is run.
  • I need an event for A
  • I need to call method B in my event handler for event A
  • I want C to be run once B is run.
  • I need an event for B
  • I need to call method C in my event handler for event B
And then someone comes along and throws method D into the mix. Well, you know that there is at least one particular case where you want D to be run after B is run… So make another event handler! Your listing now changes to:
  • I want B to run once A is run.
  • I need an event for A
  • I need to call method B in my event handler for event A
  • I want C to be run once B is run.
  • I need an event for B
  • I need to call method C in my event handler for event B
  • I want D to be run when condition X is met after B is run
  • I need an event for B (which I already have!)
  • I need to call method C in my event handler for event B
    • I can add a whole second event handler for event B (so I get C then D called)
    • OR I can modify the existing event handler that calls method C to conditionally call method D when necessary

And now how do you check the condition? Pass in some fancy event args with your state.



Events can help you keep your code flexible when your structure is changing because they provide hooks into the code when certain conditions are met. You don’t need to rely on a firmed-up design for how methods are required to be called in some particular order. If your design changes because you want something to execute under different conditions, just hook up to the event that meets those conditions instead and re-write minimal code.

I’m huge on using events in my architectures, so I’ll try to write up a few more posts on events and why I like them. The flexibility I just described is only one very small part of it, and it certainly requires that you shift your perspective on how components in a system interact.

  • Copyright © 1996-2010 Dev Leader. All rights reserved.
    Jarrah theme by Templates Next | Powered by WordPress