Brian On Software

Some readers were asking me about the status of my self-imposed challenge to achieve the MCPD-EAD (Microsoft Certified Professional Developer: Enterprise Application Developer) certification before the end of the year.  Well, it turns out that I’ve completed and passed the last exam of the series this morning.  When I first started out with this insane challenge of doing one certification every three to four weeks, I had no idea of the amount of time I would have to dedicate to complete it in the initial timeframe.  So just to recap, I passed 70-536 (Fundamentals) back in June, 70-529 (Distributed Applications) in July, 70-528 (Web Applications) in August, 70-526 (Windows Applications) in September and 70-549 (Design and Development) this morning (October).  All of these exams focus on various technologies targeting .NET 2.0.

For each of these exams, I have used the “self-paced” book series (the same series used for 70-536 and 70-529), which are:

• MCTS Self-Paced Training Kit (Exam 70-528): Microsoft .NET Framework 2.0 Web-Based Client Development
• MCTS Self-Paced Training Kit (Exam 70-526): Microsoft .NET Framework 2.0 Windows-Based Client Development
• MCPD Self-Paced Training Kit (Exam 70-549): Designing and Developing Enterprise Applications Using the Microsoft .NET Framework

Now, I’m going to say it straight and simple: all of these books suck.  The only good thing about them is that the authors have done a pretty good job copy/pasting the right MSDN documentation so that we wouldn’t waste our time doing it ourselves.  The major drawbacks I have against these books are the really poor coding style of the authors towards their examples.  A big portion of the examples contain errors, are sometimes misleading and some of them clearly won’t compile if you copy/paste the code in Visual Studio.   It’s sad to see so many mistakes like these, especially when each book is written by so many authors, because the credibility of these individuals take a pretty bad hit in the public’s eye.  I’m sure they were pushed by the deadline, but I wished they’ve polished the examples a little bit more.  I know…I know…Nobody’s perfect…I know.  But that’s still no reason to deliver mediocre products.

All right.  So just in case you’re thinking (or already started) to get your MCPD-EAD credentials, I am going to tell you how I’ve managed my time to pass each of these exams in hope that it might help you to pass them successfully.  In average, I dedicated about 40 hours per exam:

• 15 hours to read the book (1 hour in the morning and 1 hour in the evening should be enough for you to read the whole book within a week.  You don’t have to read EVERYTHING.  If you’re proficient in C#, then skip all the VB.NET examples.  Same idea goes if you’re more proficient in VB.NET than C#.   Whenever the authors mentions something in a box with the title “Real-World Scenario” you SKIP it.  It doesn’t matter.  The “real-world scenario” isn’t in the book…it’s in the REAL WORLD.  Don’t waste your time.  Also, don’t do all of the activities at the end of each chapter.  Just get through the book because you don’t want to waste too much of your time.  Here we’re really trying to cram our brain with tons of information.  The exams are roughly 80% based on memorization of the content and 20% on actual thinking.  Feel free to write notes and underline important ideas as you read along.  I used to write “EXAM” in red ink on the margin so that I can review it at a later time.)
• 20 hours to practice with Transcender or MeasureUp exams.  I have only used Transcenders, so I can’t say much about MeasureUp.  I’ve heard they’re quite good too.  Whichever you decide to do, I strongly suggest you to do all of the questions more than once.  Then when you’re confident enough about the material, take a moment to answer the questions in the “certification” mode to give you a better feel for the exam.  By the way, none of the questions of either Transcenders or MeasureUp were in the exams I’ve taken.  To be honest, the mock exams’ goals are to deepen your knowledge with the various technologies.  That’s it, that’s all.  Don’t put too much confidence in them, because what I’ve concluded at the end of each real exam is that the mock exams only helped me about 20% on the “knowledge” stuff and 80% on the actual “feeling” for the exam.  Take a week or two to practice these.
• 5 hours to practice some things I didn’t fully understand (proper use of some class, understanding the use behind some interfaces, getting comfortable with the security model, etc.) inside Visual Studio.  I strongly suggest you use Reflector to assist you in quickly discovering the information behind some objects in the framework.

I also suggest you to book your exam in advance.  For example, suppose you start studying for an exam today, then you will book an exam date four weeks from now.  This should motivate you to stay on course and respect your schedule.  And if that’s not enough, then mention to your boss and your fellow co-workers that you intend to pass this exam by that date.  Feel free to also share you exam date as a comment on this post! That should put enough pressure to get the job done…wouldn’t it?

In closing, I found that the 70-526 (Windows Applications) exam was the easiest exam of the bunch.  As for the hardest, I must say that it was the 70-529 (Distributed Applications) exam, mostly because I’ve never done .NET Remoting in the past.  And now that WCF is in the neighborhood, I doubt I’ll even have to touch .NET Remoting in the future!  It all depends on your experience with these technologies.  The more you practice and learn, the greater your chance in passing.

This is the third and last installment of lessons learned from reading “The Big Moo”.  The first lesson learned was about compromise and the second one was about being why being extreme is necessary sometimes.  This lesson is about knowing the importance of being proactive rather than reactive in a position of management or leadership.  It’s important, in order to be successful, to know how to trust and delegate work to people.  To be great at that, you must treat your co-workers/employees first of all as humans, and also take time to know them on personal/professional level.  What do they like to work on?  What are they passionate about in their job?  What motivates them to spend their energy, intelligence and experience to help your organization achieve its goals and drive its strategy?  Discovering the values behind these variables will make you more remarkable in your organization.  Furthermore, this lesson teaches you to stop being a fireman and instead be an innovator.  You have too much smarts to indulge your time in putting out fire caused by other people.  It’s important to realize that you simply can’t handle every single situation at work.  Sometimes when there’s just too many fires to put out, the best thing to do is build some brick walls to isolate your from them, but also to help you set a path that will guide you to success.  That being said, I present you the last essay for this lesson.  This one is entitled “Juggling Is Not What You Think” and (yep, you’ve guess it) and its author is unknown.

Juggling Is Not What You Think It Is

“Sometimes, I teach juggling classes.  Everyone wants to get the learning process of how to juggle three balls over with as quickly as he can.  The universal approach people take is to devote all their attention and effort at catching the calls.  They just throw ‘em up and rush around trying to catch them.  Extraordinary efforts are justified to catch the balls, because after all, if a ball hits the ground, you’ve failed.  The nascent juggler expects that with enough practice, they’ll get really good at catching balls.”

“Lots of your peers think that they’re good at juggling.  They rush this way and that, dealing with emergencies, handling multiple priorities, and never letting anything fall through the cracks.”

“But that’s not juggling.  That’s rushing around like a madman.  Let them be good at that.  There are plenty of people out there who are great at rushing about and handling emergencies, and frankly, they don’t need your help.”

“It turns out that juggling is about throwing, not catching. The way to learn how to juggle is not to focus obsessively on not dropping a ball.  No, the way to get good at juggling is to focus on your throw instead.”

“If you are good at throwing, the catching will take care of itself.”

“Once you’ve got three or four or five projects in the air at work, no amount of rushing around is going to keep them from crashing to the ground.  No amount of effort can help you catch the misthrown balls.  It’s physically impossible.”

“On the other hand, if your balls are well thrown, the catching is effortless.”

“That’s part of the secret of becoming remarkable.  Don’t spend any time at all worrying about catching.  Let your co-workers do that.  Instead, become the best thrower there ever was.  If you become good at throwing, you’ll find that you’re irreplaceable.  Organizations need really good throwers.”

This is the second installment of lessons learned from reading “The Big Moo“.  It goes inline with the first lesson learned about compromises.  This time, we’re talking about being “extreme” in the sense that you shouldn’t accept status quo if there’s no value, no growth and no opportunities associated with a given situation that you’re involved in.  I hope that the following essay taken directly from the book will inspire you to be different, to be realistic, but more importantly to be remarkable in taking sound actions to push the barrier for excellence a bit higher even when the crowd shouts differently.  It’s important that you realize when “enough is enough” and realize that your integrity and credibility is on the line every time you’re doing something that violates your set of values and principles.  Here is the full text from (once again) an unknown author:

They Say I’m Extreme

They say I’m extreme.
I say I’m a realist.

They say I demand too much.
I say they accept mediocrity and continuous improvement too readily.

They say, “We can’t handle this much change.”
I say, “Your job and career are in jeopardy; what other options do you have?”

They say, “What’s wrong with a ‘good product’?”
I say, “Wal-Mart or China or both are about to eat your lunch.  Why can’t you provide instead a fabulous experience?”

They say, “Take a deep breath.  Be calm.”
I say, “Tell it to Wal-Mart.  Tell it to China.  Tell it to India.  Tell it to Dell.  Tell it to Microsoft.”

They say the Web is a useful tool.
I say the Web changes everything.  Now.

They say, “We need an initiative.”
I say, “We need a dream.  And dreamers.”

They say great design is “nice”.
I say great design is necessary.

They say, “Effective governance is important.”
I say bold, brash boards that are representative of the market served – more than a token woman or two and an empty seat for the “forthcoming Hispanic” – are an imperative.  Now.

They say, “Plan it.”
I say, “Do it”.

They say, “We need more steady, loyal employees.”
I say, “We need more ‘freaks’ who routinely tell those in charge to take a flying leap…before it’s too late.”

They say, “We need Good People.”
I say, “We need Quirky Talent.”

They say, “We like people who, with steely determination, say, ‘I can make it better’.”
I say, “I love people who, with a certain maniacal gleam in their eye, perhaps even a giggle, say, ‘I can turn the world upside down.  Watch me!’”

They say, “Sure, we need change.”
I say we need revolution now.

They say, “Fast follower.”
I say, “Battered and bruised leader.”

They say, “Conglomerate and imitate!”
I say, “Create and innovate!”

They say, “Market share.”
I say, “Market creation.”

They say, “Improve and maintain.”
I say, “Destroy and reimagine.”

They say, “Normal.”
I say, “Weird.”

They say, “Happy balance.”
I say, “Creative tension.”

They say they favor a “team that works and lives in harmony.”
I say, “Give me a raucous brawl among the most creative people imaginable.”

They say, “Peace, brother.”
I say, “Bruise my feelings.  Flatten my ego.  Save my job.”

They say, “Basic black.”
I say, “Technicolor rules!”

They say, “We need happy customers.”
I say, “Give me pushy, needy, nasty, provocative customers.”

They say, “We seek Harvard M.B.A.s.”
I say, “I seek certificate-free ‘Ph.D.S’ from the School of Hard Knocks.”

They say they want recruits with “spotless records.”
I say, “the spots are what matter most.”

They say, “Integrity is important.”
I say, “Tell the unvarnished truth, all the time…or take a hike.”

They say diversity is a “good thing.”
I say diversity is breath of fresh, creative air – absolutely necessary for economic salvation in perilous times.

They say it’s “daunting.”
I say it’s “a hoot.”

They say, “Zero defects.”
I say, “A day without a screwup or two is a day pissed away.”

They say, “Think about it.”
I say, “Try it.”

They say, “Plan it.”
I say, “Test it.”

They say, “Radical change takes a decade.”
I say, “Radical change takes a minute.”

They say, “Times are changing.”
I say, “Everything has already changed.  Tomorrow is the first day of your revolution…or you’re toast.”

They say, “We can’t all be revolutionaries.”
I say, “Why not?”

They say, “We can’t all be a brand.”
I say, “Why not?”

They say this is just a rant.
I say this is just reality.

A couple of weeks ago, some guys from work invited me to participate in a video contest for our region.  Little did I know was a $1000 cash prize to be won…which we did won, ladies and gentlemen!  So the four of us equally divided the prize which allowed us to earn $250 each for a half an hour activity.  Not bad!  I was wondering what I could do with that easy earned money.  Invest it in a retirement funds? Nah.  Give half to my wife? Nah. Since I’m an avid reader of books, I thought that it would be nice to get a hold of some good books on software development.  Even though I’ve got over thirty books on software development and engineering, I wanted to get some dealing with patterns and principles in software design because those kind of books transcend time and technology.

Here are the books I bought with the easiest and fastest $250 earned in my life:

• Agile Principles, Patterns, and Practices in C# by Robert C. Martin
• Working Effectively with Legacy Code by Michael Feathers
• Refactoring to Patterns by Joshua Kerievsky
• xUnit Test Patterns by Gerarld Meszaros
• Object Thinking by David West

I’ve actually started reading one of them, “Object Thinking“, and I have to tell you that it’s by far one of the best book I’ve read on object design.  What books would you have bought had you be given a similar amount of easy money?

As promised in my review of The Big Moo, I will share with you three different lessons learned from reading the book.  The first lesson deals with compromise.  The field of software development is full of stories about products being bloated with unwanted or unnecessary features, costs overrun, late delivery dates, etc.  One reason that explains the cause of this is the lack of courage (that’s right, the same courage that Kent Beck preaches in Extreme Programming) from developers, analysts, managers or any serious project stakeholder to say “Hey, wait a minute!  I seriously we should think about this before we go on!” for example.  Lacking courage in such situations can make place for compromise to settle in and take more space than it should be allowed.  Once compromise is leading the project, the product will suffer, your team will suffer, your organization will suffer, your customer(s) will suffer, and this profession will suffer.  So why should you keep an eagle eye on compromise?  How can you avoid it?  Why should you avoid it?  This first lesson is well told in the essay title “The Problem With Compromise“.

Here’s the full text of this essay (author unknown):

The Problem With Compromise

“Any organization with more than one person in it is a place of compromise.  If you want to get something done, a project okayed, a budget approved, a product sold, you’re going to have to compromise.”

“Most of the time, it seems as though half is better than none.  If you refuse to compromise, nothing happens.  And this desire to make it happen explains why so many things are mediocre.  It tells us why it’s so hard to make something remarkable, and why the remarkable succeeds so easily.  Because everything is a compromise, everything is sort of mediocre, isn’t it?”

“The wireless Internet access at the Denver airport has compromise written all over it.  I’m sure that when it was first designed (probably by a lone engineer in a cubicle), it was simple and fast and easy to use.  Today, however, it takes at least a dozen clicks to get started.  You need to enter a username and ID not once, but twice.  And your ID must be at least eight characters long and include numbers and a special character like $, %, or #.  So, something like “$3eVh!” is not secure enough because it’s too short.  Huh?  This isn’t your credit rating you’re protecting…it’s just the right to spend nine dollars and go online.”

“At every step along the way, each compromise to the sign-on system seemed reasonable.  At each step, the evolution of the design was simple: Either the project manager had to go along with the needs of this or that person (and the boss) or risk having the project canceled.  What would you do?  All those compromises may have made each person happy, but the final product was something that absolutely no one liked.”

“The first step to fighting back is understanding how compromise corrupts the things you’re so busy building.  More often than not, half is actually worse than none.  More often than not, you’re better off doing nothing than shipping something that is just average.  The project manager in Denver should have just stopped the project and let the chorus of complaints from passengers sink in to make the case for doing things the right way from the start.”

“Twenty years ago, Japanese car companies solved their quality control problem using a technique called Kanban.  Instead of following the American technique of having plenty of spare parts on the assembly line (workers were told to just discard a screw if it didn’t fit right), the Japanese adopted a fundamentally different strategy.  They kept only one necessary part at a time on the assembly line.  If the part wasn’t perfect, the entire assembly line stopped until a new part arrived.”

“The Americans said that this was insane.  Everyone knew that keeping the assembly line moving was the only way to make a car efficiently.  If a finished car wasn’t good enough, then you fixed it after it was assembled.”

“What Toyota and Honda understood was that the act of stopping the assembly line would send a powerful signal to every worker and to every supplier.  Sure enough, the line didn’t have to stop very often.  Every part improved in quality, because no one wanted to be responsible for shutting the operation down.  As a result, better parts improved every car as well.  With Kanban, very few cars left the assembly line in need of later reworking.  It turned out to be cheaper and faster to build cars right the first time than it was to fix them later.”

“You might try the same thing in your organization.  Refuse to compromise.  See what happens.  For a while, the assembly line will slow down or even stop.  Things won’t ship, products will get stuck in development.  And then a funny thing will happen: People will begin to understand that compromising the product just to keep the system working is stupid.  The only reason the system exists is so that you can make the things you make, right?  So if the system is demeaning your work, change the system.”

What do you think?  Are you currently in such a situation where compromise has settled in your project team?  What did you do to get out of the situation and prevent it from repeating itself?  Your comments are encouraged for this first lesson learned.

After reading The Dip: A Little Book That Teaches You When to Quit (and When to Stick) from best-seller author, marketing guru and prolific blogger Seth Godin, I couldn’t wait but to read another one of his writings.  This time I settled for The Big Moo, a collection of over thirty essays focused on showing you how and why you and your organization should thrive to be remarkable.  In Seth Godin’s words: "Stop trying to be perfect and start being remarkable".  At first, I was hit by the book’s title, but after reading a few pages, it all made sense.  Here’s what the front cover has to say about what the big moo is all about:

As Seth Godin said in his widely quoted best-seller Purple Cow, first you need to stop being a brown cow – in a field of hundreds of other brown cows – and dare to be purple.  But after a while, that’s not enough.  You need a big moo, an extreme purple cow, an innovation that completely changes the game.

With the collaboration of "33 of the world’s smartest business thinkers", including Malcolm Gladwell, Tom Peters, Guy Kawasaki, Marc Benioff, etc., this book is truly a collection of 21st-century wisdom for any organization that’s looking for a way or a purpose to reach a higher plateau in the way business is done with people.  As stated in the back cover:

The Big Moo tells their stories.  Stories that will stick to your ribs, light your fire, and give you flashes of inspiration.  Stories about memorable customer service, amazing dedication, daring design standards, and legendary leadership.  The Big Moo will help you drive growth and change in your organization, from the mail room to the boardroom to the front lines.

No doubt that being remarkable (in the eye of the customer) will give you an edge over your competition that’s simply doing business.  But The Big Moo is not just for growing and differentiating organizations.  It’s also a valuable asset to help YOU grow both on a personal and professional level too!  In case you haven’t noticed, you are also in competition with other people when it comes to signing a contract for a job, a music record, a part in the school’s play, etc. 

I don’t want to say too much about this 177-pages book because I rather let you discover its fruits on your own.  While reading it daily on my way to work and back home, I realized that each single essay had something inspiring and concrete that could easily apply to my personal and professional life.  Speaking of essays, you never know which collaborator wrote an essay because each one of them is anonymous…neat, huh?  Also, we are recommended to share some of these essays publicly without any legal constraints.  Therefore, I will share with you three essays that struck me profoundly in further posts so that you can get a better taste of what the book has to offer.  So stay tuned! 

Meanwhile, I highly recommend anyone in your organization that has a role of leadership to get a copy of The Big Moo and share the stories with the rest of the organization.  Even better…Get some people in your organization to participate in writing their own remarkable stories and publish them either on your intranet or on the Web.  Let the "purple cow" in you run free from any boundary!

If you’re looking for a solution to store and retrieve a picture from a table in a SQL Server 2005 database, I hope that these two functions (StoreImageInDatabase at line 4 and RetrieveImageFromDatabase at line 72) will satisfy your requirement. I had to implement such functionality in a project and decided to keep it here for further reference. It’s heavily commented for those developers that are taking their first steps with ADO.NET. Feel free to share your own implementation too. There are so many ways to do this.

/// 

/// Stores an image to the database
/// 
private static void StoreImageInDatabase( string imageFilename, ImageFormat imageFormat )
{
    // Make sure the image file exists prior to proceeding with the storage.
    // Note: The File.Exists method will return false whether the imageFilename parameter is null or empty.
    if ( !File.Exists( imageFilename ) ) throw new FileNotFoundException( "The image file was not found", imageFilename );

    // Load the image from the filename received as a parameter.
    Image image = Image.FromFile( imageFilename );

    // Holds the byte representation of the image.
    Byte[] content;

    // Use a MemoryStream to store the image representation as stream of bytes.
    using ( var stream = new MemoryStream() )
    {
        image.Save( stream, imageFormat );

        // Convert the stream into an array of bytes because that's the value we'll pass to our SQL parameter.
        content = stream.ToArray();
    }

    // Our connection string (put it in your configuration file if needed)
    const string connectionString = "INSERT YOUR DATABASE'S CONNECTION STRING HERE";

    // Create an SQL connection based on a connection string pre-defined (the using statement will close/dispose the connection on our behalf even if an exception should occur).
    using ( var connection = new SqlConnection( connectionString ) )
    {
        // The SQL statement/stored procedure used to store our image.
        // Just make sure that you have a parameter named '@PICTURE' of type Image as well as a column named 'PICTURE' of type Image too in the table.
        const string sqlStatement = "UPDATE SOME_TABLE SET PICTURE = @PICTURE WHERE SOME_CONDITION";

        // Create an SQL command based on our stored procedure and SQL connection.
        using ( var command = new SqlCommand( sqlStatement, connection ) )
        {
            // Explicitly state that we'll be using a SQL statement or a stored procedure (CommandType.StoredProcedure).
            command.CommandType = CommandType.Text;

            // Define the SQL parameter which will hold our image to store.
            var parameter = new SqlParameter( "@PICTURE", SqlDbType.Image )
                            {
                                    Value = content
                            };
            command.Parameters.Add( parameter );

            try
            {
                // Open the connection.
                connection.Open();

                // Execute the stored procedure to store our image in the database.
                command.ExecuteNonQuery();

                MessageBox.Show( "Image stored successfully", "Image storage", MessageBoxButtons.OK,
                                 MessageBoxIcon.Information );
            }

            catch ( SqlException ex )
            {
                MessageBox.Show( ex.Message, "SQLException", MessageBoxButtons.OK, MessageBoxIcon.Error );
                // Other error handling, logging, etc.
            }
        }
    }
}

/// 

/// Retrieves an image from the database
/// 
private static Image RetrieveImageFromDatabase()
{
    // The image that will be retrieved
    Image image = null;

    // Our connection string (put it in your configuration file if needed)
    const string connectionString = "INSERT YOUR DATABASE'S CONNECTION STRING HERE";

    // Create an SQL connection based on a connection string pre-defined (the using statement will close/dispose the connection on our behalf even if an exception should occur).
    using ( var connection = new SqlConnection( connectionString ) )
    {
        // The SQL statement/stored procedure used to retrieve our image.
        // Just make sure that you have a column named 'PICTURE' of type Image.
        const string sqlStatement = "SELECT PICTURE FROM SOME_TABLE WHERE SOME_CONDITION";

        // Create an SQL command based on our stored procedure and SQL connection.
        using ( var command = new SqlCommand( sqlStatement, connection ) )
        {
            try
            {
                // Explicitly state that we'll be using a SQL statement or a stored procedure (CommandType.StoredProcedure).
                command.CommandType = CommandType.Text;

                // Open the connection.
                connection.Open();

                // Execute the query and build a DataReader with the results.
                var reader = command.ExecuteReader();

                Debug.Assert( reader != null );

                // Since we only have one image stored in the table (this is an example after all...), we'll only have one image to retrieve from our table.
                // If you have to retrieve one specific image (or more) from a collection of images in the table, then you can precise which one to retrieve via a parameter.
                reader.Read();

                // Since the only column of our table is used to store/retrieve an image, its column index is zero.
                // We simply cast that column into an array of bytes.
                var content = (byte[])reader[0];

                // Create a stream based on the entire content of our buffer.
                using ( Stream stream = new MemoryStream( content, 0, content.Length ) )
                {
                    // Write the content (array of bytes) to our stream.
                    stream.Write( content, 0, content.Length );

                    // Create an image object based on the stream.
                    image = Image.FromStream( stream );
                }
            }

            catch ( SqlException ex )
            {
                MessageBox.Show( ex.Message, "SQLException", MessageBoxButtons.OK, MessageBoxIcon.Error );
                // Other error handling, logging, etc.
            }
        }
    }

    return image;
}