Tag: reflection

Charity Water – Weekly Article Dump

My 24th Birthday Wish - Charity: Water

Charity Water

We have a lot of pretty awesome people at Magnet Forensics, and every day I’m reminded just how awesome. A colleague of mine, Danielle Braun, had what I thought was an incredible idea for her birthday. For Danielle’s birthday, she’s not asking for more new clothes, for her parents to get her a car, for help with paying off tuition, or for some new fancy tech gadgets. But she’s not asking for nothing. Danielle is asking for your support with Charity: Water this year.

Charity: Water is a non-profit organization with the goal of bringing clean water to people in developing nations that don’t have access to it. Reading their mission page probably opens your eyes a fair bit about the lack of access to drinking water in other countries. They’re not about some complex and elaborate plan to revolutionize access to clean drinking water. However, they do have a simple and straight forward approach. Donate a little bit of money and they can install wells, rain catchments, and filters in areas without access to clean water. Your small contribution can make a huge impact on other peoples’ lives.

Please consider helping Danielle out with her goal of raising money for clean drinking water. A little bit goes a long way with Charity: Water.

Articles

  • Guest Post: 7 Deadly Sins: How to Successfully “Cross The Chasm” By Avoiding These Mistakes: In Geoffrey Moore’s article, we get to revisit some of the great learnings in Crossing the Chasm. If you haven’t read the book, although it’s a bit old now, it’s still a solid read. This post was a great reminder of a lot of the things the book talks about. It’s important to know where your business sits in the chasm model so that you know what you should be focusing on. Too many companies focus on the right things at the wrong times and have terrible missteps. Check it out (and the original book too)!
  • Holiday Gifts EVERY Employee Secretly Wants: Dharmesh Shah is a guy who always seems to have an awesome perspective to share. There are a few things that despite someone’s level of performance, length of employment, or amount of skill should be deserved.  Often these are overlooked either by grumpy managers or because perhaps the person may not have been a top performer. In Dharmesh’s opinion, that shouldn’t be a factor. The holidays are a perfect time to remind ourselves to recognize all of our employees’ accomplishments and treat them with respect. If you aren’t already, maybe this article is the little wake-up call you need.
  • 6 Things Really Thoughtful Leaders Do: Nothing groundbreaking here, but like the article says, this time of year is great for reflecting. Do you consider yourself a thoughtful leader? Do you observe the people around you, how they interact, and how things are flowing at work? Do you take the time to reflect on things you’ve done, how you’ve acted, or even how employees may have improved in areas you’ve discussed with them? There’s a handful of great reminders in this article that I would suggest you check out!
  • 14 Code Refactoring smells you can easily sense and What you can do about it?:  This week’s first programming article! Except… Well… This one is about the management side of programming. How do you know if your software team’s code is in a real stinky spot? This doesn’t necessarily mean your developers write bad code. It could just mean that you need to hit the brakes a bit and go revisit some problem areas in the code. This article talks about some of the warning signs.
  • What Makes A Good Manager? 7 Things To Ask Before You Promote: Does it make sense to give anyone you’re promoting a management position? Probably not. Seems obvious when you ask it like that, right? The unfortunate truth is that a lot of companies take the simple path and for anyone they want to promote, they throw a management position their way. Some people just don’t make great managers. This article talks about the qualities you want to look for in managers. Maybe the person you’re looking to promote won’t make a good manager *now*, but if it’s something they can put time and effort into building the skills and experience towards, it could still happen.
  • 10 Major Causes for Failure in Leadership: While lists of things to do are always nice, having a list of things to definitely not do is also helpful. Here’s one of them. Some of the leadership-don’ts I liked on this list were being too good to serve your followers, using your “authority”, and fear of competition. I think those are a few that are easy for people to forget, and there at the top of my list of leadership-don’ts. Read some more great points in the article!

Please take some time to help Danielle out with her goal. Any contribution helps. Remember to follow Dev Leader on social media outlets to get these updates through the week. Thanks!

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


My Team Triumph Canada – Weekly Article Dump

My Team Triumph Canada - Inaugural Race

All of the captains with their angels after the race! What a blast!

My Team Triumph – Canada

You probably haven’t heard of it, but I can assure you that will change. Today I was fortunate enough to participate in the first My Team Triumph race in Canada. My Team Triumph is a program that allows people of all ages with disabilities to participate in endurance events. With a great volunteer staff, a few angels, and all of the amazing captains, this was made possible.

My Team Triumph takes their inspiration from Team Hoyt, whom you’ve probably heard of.  Now I can’t do the Hoyt story any justice, so I suggest you head over to their site to get the full details. Team Hoyt is a father-son team that has competed in over a thousand races; however, their team is slightly different than your average racer in these events. Dick Hoyt, the father, pushes his quadriplegic son, Rick, in a wheelchair during these events. It started in 1977 when Rick told his father that we wanted to be able to participate in a benefit race for a paralyzed rugby player. Dick agreed to it, and they finished their 5 mile race. That night, Rick told his father that it felt like all of his disabilities went away when they were running together. Honestly, you need to read the story.

So today at the My Team Triumph race, I was grouped up with Captain Vernon of “Vernon’s Maple Leafs” and two angels Nadine and Blair. It was exciting to get to meet the team, and Vernon was incredibly enthusiastic about the whole thing. For anyone who knows me personally, I’m not a runner at all. People actually joke around with me about any time I have to run (because we all know those calories could be put towards squatting, obviously). When we were sharing our running experiences with each other, I had to let the team know that I had never actually ran a 5 km race. That didn’t discourage Vernon though. He told me he was going to make me run, and he wasn’t lying. In the end, we were the second chair team to cross the finish line, which is absolutely amazing in terms of where my expectations were.

My Team Triumph Canada - Nick and Steph

Steph Hicks-Uzun and I bright and early before the run! I’m all smiles here because my lungs and legs haven’t yet endured the 5 km!

Once it was all said and done, my lungs and legs were on fire, but it was an incredible experience. Wes Harding has done an amazing job in putting My Team Triumph Canada together, and everyone at the race was incredibly supportive. Please check out their site to read about their inspirational stories. Way to go, team!

Articles

It’s a pretty short list this week, but it doesn’t mean there’s a lack of quality!

  • I like, I wish, I wonder: A teammate of mine, Christine, brought this to my attention on LinkedIn. In this post, Akshay Kothari talks about a different approach to what our typical sprint retrospectives look like. For some background, in our development life cycle we work in “sprints”. Sprints are typically one or two week units of time where we claim we can get X units of work done. These units of work are often “stories” or “tickets” that we’re essentially taking full responsibility for getting done by the end of the iteration. At the end of the sprint, we do a retrospective where we discuss what went good, what went bad, and how we can improve them. More often than not, there’s less than ideal amounts of input and it seems pretty forced. This article suggests taking a slightly different approach where people can make a statement that starts with “I wish”, “I like”, or “I wonder”. I’m hoping to try this out at our next retrospective and see if it’s the little switch-up that we need.
  • The 17 Qualities And Views Of Great LeadersAndreas von der Heydt put together this awesome list of 17 qualities that great leaders possess. Among them is the idea of failure (and doing it early and often), which you’ve probably seen my write plenty about now. There’s nothing wrong with failure as long as you’re learning and moving forward. Over communicating and keeping a positive attitude are also right up there on my top picks from that list.
  • How To Uncover Your Company’s True Culture: When I shared this on LinkedIn, I had a lot of positive attention from it. I’ll assume that means that it hit home with a lot of people! I this post, Dharmesh Shah, the founder of HubSpot, discusses what company culture really is. Some key take away points are that it’s really easy to say “this is what we think our ideal culture is, so this will be our culture”, but that means close to nothing. Your real culture is not what you say you want it to be, it’s what your company lives and breathes every day. You can say you want your culture to be anything, but it means nothing unless you’re all living it out at work. There are some great points in the article with specific cases to what you might say your culture values. For example, if you value customer service highest of all things, then when you have an opportunity to improve ease of use for your customer(s), what’s your first reaction? “That’s going to be a lot of work?” or “Let’s get it done for the customer”. Neither is wrong, but those answers are the ones that define your culture, NOT what you think you want the answer to be.
  • Forget a Mentor, Build a Team: In this article by Jim Whitehurst, he talks about an alternative to the mentor approach. It’s becoming increasingly more common for professionals to try and set themselves up with a mentor who has been there, done that, and has a lot of insight to offer. This is great, and there’s nothing really wrong with it. However, Jim proposes an alternative where instead of setting yourself up with a mentor, why not surround yourself with team members who all bring something to the table? It’s a great idea, really. I’m sure we all have close friends, old classmates, or old colleagues who would be great to bounce ideas off of, share our hard times with, and share our victories with. They’ll keep you grounded and hopefully bring some of their own personal insights to the table.
  • 5 Things Super Successful People Do Before 8 AM: I thought this article by Jennifer Cohen was great. Some things I definitely want to start doing are mapping out my day and visualizing what’s ahead. I’m already pretty good for eating well, and I favour exercising at night once my body and nervous system has had time to wake up, so those ones aren’t at the top of my personal list. Another great tip from Jennifer: Get that one big ugly thing off your list as soon as possible in your week. Awesome.
  • Scrappiness = Happiness: This article really hit home with me. The company where I work, Magnet Forensics, is still considered a startup but we’re making the transition into small business. The rate at which we’re developing and growing all aspects of the business makes it hard to remain in a complete “startup mode”. In his article, Tim Cadogan talks about a meetup between “originals” of the company where he worked. The key take away points are that the initial years of your company where you’re facing hard times and dealing with less than ideal circumstances are going to be the times you remember later on. This is where the memories are made. Being able to share these stories with each other (and new people you bring onto the team, for that matter) is what lets your company culture continue on.

Remember to 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.


Dependency Injected Singletons… What?

Background

Previously I wrote a bit about singletons. I’m not afraid to say that I think singletons have a time and a place… Okay, I’m afraid to say it, but it’s actually how I feel 🙂 After learning more and more about inversion of control design patterns and programming by interfaces, I started to notice just how inflexible singletons are. When you consider using a singleton, you should be considering both the pros and cons without jumping right into it. Here’s an example of my approach for mixing singletons, programming by interfaces, and a bit of inversion of control.

The Setup

I’m actually surprised you got this far. I’m sure you’re probably just sticking around to see how messed up this could possibly be. I’m actually proud that this little pattern has worked out so well when I’ve used it, so it can’t possibly be that bad.

One major drawback to singletons is that they are often implemented as concrete classes. That is, you ask some class X for it’s instance (via a static property/method) and it provides you it. This doesn’t mix very well with programming by interfaces. So, the first step is to have your singleton return an interface instead of a concrete class. Unfortunately, this on it’s own only provides a few benefits, and it’s really only a minor abstraction layer. You can change your singleton class around all you want, but the only dependencies people are going to see are what’s exposed on the interface. As long as your interface isn’t changing, you’re in a good position. With this change alone, we’ve managed to tackle a bit on programming by interfaces, which makes me just a bit happier.

So, what’s the problem now then? Well, now that I have my singleton returning an interface, the unfortunate truth is it’s always going to be the same class backing that interface. It’s incredibly risky if I start putting some sort of logic in my singleton’s property to get the instance that will return different references that could implement the interface. I mean, once your code is running, you want to make sure you’re always getting the same reference back… or else you’re not using a singleton! The drawback to this is that it completely ruins inversion of control and dependency injection!

 

An Example

Consider that I have a singleton that has information about my application. (If you don’t like my example, then you’ll surely hate using WinForms, because Microsoft does it with their Application class. So, it’s a fair example!) Okay, so if we pretend that we need something just like the Application class in our project, we might create some interface IApplication and create a singleton that returns an instance of an IApplication.

Suppose in one implementation we have, we really want to be using reflection and the assembly information to figure out our application’s information. Our concrete class would implement the IApplication interface but the methods would revolve around using reflection and querying the assembly for what it wants. If we built up a whole framework that used this singleton… We’d be tied to that implementation!

What happens if we go to make another application that wants to use this same framework, but it needs to be able to provide the application information through a configuration file? Well… We’d be pooched! Our singleton that’s used everywhere (and yes, please continue crying about the use of the singleton… Just remember Microsoft’s Application class) and we can’t really do anything about it!

Or can we?

The “Solution”

Okay, so here we are. I’ve demonstrated the problem with a scenario that isn’t too far fetched. How do we fix this crappy situation we’ve got ourselves in by using the dreaded singleton pattern? We use my other best friend: events. Except we use them in a way that makes me cringe. Static events.

Here’s my solution the the above problem:

The Interface:

    public interface IApplication
    {
        string Name { get; }

        string Version { get; }
    }

The Singleton:

    public static class Application
    {
        private static readonly object _instanceLock = new object();
        private static IApplication _instance;

        public static event EventHandler<QueryTypeEventArgs> QueryType;

        public static IApplication Instance
        {
            get
            {
                if (_instance == null)
                {
                    lock (_instanceLock)
                    {
                        if (_instance == null)
                        {
                            _instance = CreateInstance();
                        }
                    }
                }

                return _instance;
            }
        }

        private static IApplication CreateInstance()
        {
            var handler = QueryType;
            if (handler == null)
            {
                throw new InvalidOperationException(
                    "Cannot create an instance because the QueryType event " +
                    "handler was never set.");
            }

            var args = new QueryTypeEventArgs();
            handler.Invoke(null, args);

            if (args.Type == null)
            {
                throw new InvalidOperationException(
                    "Cannot create an instance because the type has not been " +
                    "provided.");
            }

            // NOTE: here's where things get weird. you need to define your own
            // sort of "contract" for what type of constructor you will allow.
            // you might not even use a constructor here... but you need to
            // define what mechanism the provided type must have to provide
            // you with a singleton instance. i'm a fan of providing a type
            // with a private parameterless constructor, so i'll demonstrate
            // with that. your requirements will change what this section of
            // code looks like.
            if (!typeof(IApplication).IsAssignableFrom(args.Type))
            {
                throw new InvalidOperationException(
                    "Cannot create an instance because the provided type does " +
                    "not implement the IApplication interface.");
            }

            const BindingFlags FLAGS = 
                BindingFlags.CreateInstance | 
                BindingFlags.Instance | 
                BindingFlags.NonPublic;

            var constructors = args.Type.GetConstructors(FLAGS);
            if (constructors.Length != 1)
            {
                throw new InvalidOperationException(
                    "Cannot create an instance because a single private " +
                    "parameterless constructor was expected.");
            }

            return (IApplication)constructors[0].Invoke(null);
        }
    }

The Program (With two types to inject!)

    internal class Program
    {
        private static void Main(string[] args)
        {
            Application.QueryType += (sender, e) =>
            {
                e.Type = typeof(ApplicationB);
            };

            Console.WriteLine(string.Format(
                "Application Name: {0}rnVersion: {1}",
                Application.Instance.Name,
                Application.Instance.Version));

            Console.WriteLine("Press enter to exit.");
            Console.ReadLine();
        }
    }

    internal class ApplicationA : IApplication
    {
        private ApplicationA()
        {
        }

        public string Name
        {
            get
            {
                return "Application A (Pretend this was from the assembly info)";
            }
        }

        public string Version
        {
            get { return "1234"; }
        }
    }

    internal class ApplicationB : IApplication
    {
        private ApplicationB()
        {
        }

        public string Name
        {
            get
            {
                return "Application B (Pretend this was from an XML file)";
            }
        }

        public string Version
        {
            get { return "9876"; }
        }
    }

So, if you were to run the program, what outputs would you expect in either case? What happens when you forget to set your event handler? What happens when you set your event handler and don’t provide a type? What if it’s a bad type?

 

Summary


I’m not claiming this is the best approach to solve this problem, and I’m not even encouraging that everyone go ahead and use it. Some of the pros of this are:

  • Advantages of programming by interfaces! You’re only exposing interface definitions to others.
  • Dependency injection capabilities. Inject your “singleton” into other applications.
  • All the goodies related to singletons
  • Easy to use. Just hook up your type to a event handler when your program initializes.

Some of the cons are:

  • All the things people hate about singletons. All of them.
  • Static events are absolutely hideous.
  • You’re giving some other class control of creating your singleton instance.
  • There is no compile time checking or contracts for how your singleton needs to be created.

And now that you know some of the good and some of the bad, can you leverage a design like this? You can check out a working solution I put together for the code and example I described above over at Google Code. Hope you were able to learn something (either good or bad)!


  • Nick Cosentino

    Nick Cosentino

    I work as a team lead of software engineering at Magnet Forensics (http://www.magnetforensics.com). I'm into powerlifting, bodybuilding, and blogging about leadership/development topics over at http://www.devleader.ca.

    Verified Services

    View Full Profile →

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