The stuff I was interested in:

• Add New Row for the DataGrid
• Improved application startup performance
• Mouse wheel support for out-of-browser  applications on the Mac
• Media bug fixes
• MouseCapture memory leak is fixed
• Inline DataTemplate memory leak fixed.

Developers go get the tools:

• Windows developer runtime
• Mac developer runtime
• Silverlight 4.0.50826.0

A while back I read a couple of posts by Gil Zilberfeld (here and here) where Gil talks about the responsibility that vendors such as Microsoft plays in the role of securing the quality of the work that is produced in our industry. While I think I see the points  Gil is trying to make, I think he misses the beat a bit and I have a hard time agreeing with the conclusions he draws.

The way I see it there are two types of developers; those that are just in it to pay the bills and those that consider themselves as craftsmen. If you consider yourself a craftsman then you should already be aware that you are responsible for your own faith and actions in this industry. But, if you are just in it to pay the bills then you are probably also looking to do so by doing the least amount of work and that includes looking for information on how to solve a particular problem or how to apply a technology onto your stack.

So if you are one of the developers that are only looking towards Microsoft (or the relevant company for the technology stack you are working on) is it their fault if you implement something in a way that could be considered bad? Of course not! Sure there are a lot of outdated and down right poor samples at the Microsoft (or relevant company) website and their idea on how certain things should be solved are bound to differ from others (and that’s definitely not to say that there isn’t good contents, there are a ton of it). However, if you rely on a single source of information, you are always going to get an opinionated view. Take my word on it (right?).

Doctors reads medical journals, publishes research papers, attend conferences, network with colleagues and make sure they stay up to date with the latest in their field. I’m pretty sure you are happy that they spend all of this time to make sure they can provide the best possible care and treatment when someone are in need of their services. I know I am.

Just as with any other profession, developers are responsible for their own education, for honing their skills in the craft that they have chosen to practice. In order to keep up in an industry that evolves at the speed of light you need to invest in yourself. The code you write today should be some of the best you have ever written, while a year later you should be considerably less excited about its quality. It’s a sign of growth. That you’ve continued to move forward as a craftsman, that you skills have been honed and broadened during the past year.

So what about the tools? Do we really rely on them too much to get the work done? I would say, definitely not! But again you have to specify just exactly what you are talking about when talking about tooling. If you rely on visual designers, drag and drop, wizards and the likes to to the majority of your work, then yes you are probably relying too much on your tools. Odds are that you will have a hard time to get anything outside of standard behavior to run and there will be pain points when you need to debug.

However you would do yourself (and your employer) a huge disservice if you did not make it your goal to know the tools in your toolbox as good as possible. What’s wrong with knowing how to use the debugger, the IDE and tools like ReSharper as good as possible? Used correctly they will have a huge impact on productivity. Make sure you know the finer details of the tools and make them work for your and not the other way around. Yes, sometimes tools do get in the way of the goal, even slow you down, and when that is the case, don’t use the tools! Tools are there to help you when you need them, not to act as a crutch you always have to lean on so you don’t fall on your ass.

Well there you have my thoughts on the subject. It’s always up to the developer, not the companies. Always.

I am also around on twitter @thecodejunkie in case you need one more person to follow

Have you been hearing the chatter about Visual Studio LightSwitch? It is a new technology from Microsoft targeted at quickly building line of business apps. And for a bit more sweetness, it builds tiered Silverlight apps for us! LightSwitch is currently in Beta 1, but seems destined for being it’s own version of Visual Studio.

In this discussion with Jay Schmelzer, we go a bit beyond the typical explanation of LightSwitch and discuss how it actually works under the covers. As Jay helps us understand, we can expect actual productivity gains using this technology and well designed code along the way. My impressions of LightSwitch after this discussion are fairly positive. I can definitely see myself using the technology on my next quickie forms-over-data application.

Jay Schmelzer

Jay Schmelzer is a Group Program Manager on the Visual Studio Team at Microsoft.  Jay and his team are responsible for the Visual Studio design-time tools and runtime components used to build line of business applications. That includes the Visual Studio support for building Microsoft Office, SharePoint and Windows Azure solutions, Visual Studio LightSwitch, Visual Studio’s data binding and data consumption experiences, as well as the application programmability and extensibility available in Visual Studio Tools for Applications.  Prior to joining Microsoft, Jay was a partner with a leading consulting firm and specialized in the design and development of enterprise applications.  Jay has authored several articles and books on application development and is a frequent speaker at application development conferences.

Show Links

• Visual Studio LightSwitch
• Visual Studio LightSwitch Developer Center
• Team Blog
• Forums on MSDN

My constraints were:

1. I did not have an HTML form (the application I was working with is very “AJAX heavy”).
2. I needed to pass parameters in addition to the file (the ID of the entity that I want to associate the file with).

I used the jQuery.upload plugin too assist me with both of these. Obviously that means I am also using jQuery.

Let’s look at the code. Here’s the Content from my View:

Select File to Upload: <input id="file" name="file" type="file" />

<img id="fileView" />

<script type="text/javascript">

    $(document).ready(function () {

        $('#file').change(function () {

            var data = { ID: "b53dd6b4-f24c-4450-bf6a-246e5835a125" };

            $(this).upload(

                "FileUpload/AttachFileToEntity",

                data,

                function () {

                    $("#fileView").attr("src", "FileUpload/GetFileDataFromEntity/" + data.ID);

                }

            );

        });

    });

</script>

I am simply attaching an change event handler the the <input type=”file” /> control. The event handler does two things:

1. Uploads the selected file
2. Displays it. I am assuming that you are uploading an image (but not verifying this)

Note that the name attribute of the input control must be set and it must match the name of the HttpPostedFileBase parameter in the AttachFileToEntity Controller Action. Speaking of the Controller here it is:

public class FileUploadController : Controller

{

    private readonly EntityRepository _entityRepository = new EntityRepository();

    public ActionResult Get()

    {

        return View();

    }

    public ActionResult AttachFileToEntity(Guid ID, HttpPostedFileBase file)

    {

        var entity = _entityRepository.Get(ID);

        entity.FileData = GetFileData(file);

        return Content("File saved");

    }

    private byte[] GetFileData(HttpPostedFileBase file)

    {

        var length = file.ContentLength;

        var fileContent = new byte[length];

        file.InputStream.Read(fileContent, 0, length);

        return fileContent;

    }

    public FileResult GetFileDataFromEntity(Guid ID)

    {

        return File(_entityRepository.Get(ID).FileData, "image");

    }

}

The imaginatively named Entity could not be simpler:

public class Entity

{

    public Guid ID { get; set; }

    public byte[] FileData { get; set; }

}

In a production scenario you are using probably using an O/RM such as NHibernate. In this case you will want to deviate from what I have above and store the uploaded file in a different entity. This is to avoid having to load the binary data for the file each time you access the entity. Note that NHibernate 3 supports (to a limited degree) lazy loading properties. However even if you are utilizing this feature you still want to make sure that the binary data is stored in a different table in the underlying RDBMS so that any full table scans (for example if you are performing some type of aggregation) don’t end up reading mountains of irrelevant data.

The one thing that you are missing is the Repository. Rather than introduce the complexity of data access I am simply using a static Dictionary to store the data:

public class EntityRepository

{

    private static readonly IDictionary<Guid, Entity> _entities = new Dictionary<Guid, Entity>

    {

        { new Guid("b53dd6b4-f24c-4450-bf6a-246e5835a125"), new Entity { ID = new Guid("b53dd6b4-f24c-4450-bf6a-246e5835a125") }}

    };

    public Entity Get(Guid ID)

    {

        return _entities[ID];

    }

    public void Save(Entity entity)

    {

        if (entity.ID == Guid.Empty) entity.ID = Guid.NewGuid();

        if (_entities.ContainsKey(entity.ID)) _entities[entity.ID] = entity;

        else _entities.Add(entity.ID, entity);

    }

}

That’s everything you need. Hope that you find this useful.

Having this book on my shelf for quite some time now, I finally decided to to make my way through reading Facts and Fallacies of Software Engineering written by Robert L. Glass. As the title already implies, this well-established author lays down 55 facts and 10 fallacies about software engineering based on his half a century experience in the field.

The facts are divided in four categories: management, lifecycle, quality and research. The fallacies are split into three categories: management, lifecycle and education. Each of these categories have their own more specific sub-categories in which these facts and fallacies are classified. This way its easy to pickup the content about a particular topic of choice. Although I read the book from cover to cover, it isn’t required to do so. All facts and fallacies can be read on their own but occasionally the author refers to the discussion of other facts/fallacies in the book.

All facts and fallacies are laid down using the following structure:

• The fact/fallacy itself is presented and discussed.
• After which the controversies about a particular fact/fallacy are presented.
• Finally, a list of books and articles are enumerated that were a source of information regarding the fact/fallacy. Some of these sources are ancient, some are more recent.

Here’s the list of facts:

People

1. The most important factor in software work is the quality of the programmers.
2. The best programmers are up to 28 times better than the worst programmers.
3. Adding people to a late project makes it later.
4. The working environment has a profound impact on productivity and quality.

Tools and Techniques

5. Hype (about tools and technology) is a plague on the house of software.
6. New tools and techniques cause an initial loss of productivity / quality.
7. Software developers talk a lot about tools, but seldom use them.

Estimation

8. One of the two most common causes of runaway projects is poor estimation.
9. Software estimation usually occurs at the wrong time.
10. Software estimation is usually done by the wrong people.
11. Software estimates are rarely corrected as the project proceeds.
12. It is not surprising that software estimates are bad. But we live and die by them anyway!
13. There is a disconnect between software management and their programmers.
14. The answer to a feasibility study is almost always “yes”.

Reuse

15. Reuse-in-the-small is a solved problem.
16. Reuse-in-the-large remains a mostly unsolved problem.
17. Reuse-in-the-large works best in families of related systems.
18. Reusable components are three times as hard to build and should be tried out in three different settings.
19. Modification of reused code is particularly error-prone.
20. Design pattern reuse is one solution to the problems of code reuse.

Complexity

21. For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity.
22. Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.

Requirements

23. One of the two most common causes of runaway projects is unstable requirements.
24. Requirements errors are the most expensive to fix during production.
25. Missing requirements are the hardest requirements errors to correct.

Design

26. Explicit requirements ‘explode’ as implicit requirements for a solution evolve.
27. There is seldom one best design solution to a software problem.
28. Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal.

Coding

29. Designer ‘primitives’ rarely match programmer ‘primitives’.
30. COBOL is a very bad language, but all the others are so much worse.

Error removal

31. Error removal is the most time-consuming phase of the lifecycle.

Testing

32. Software is usually tested at best to the 55 to 60 percent coverage level.
33. One hundred percent test coverage is still far from enough.
34. Test tools are essential, but rarely used.
35. Test automation rarely is. Most testing activities cannot be automated.
36. Programmer-created, built-in debug code is an important supplement to testing tools.

Reviews and Inspections

37. Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
38. Rigorous inspections should not replace testing.
39. Post-delivery reviews, postmortems, and retrospectives are important and seldom performed.
40. Reviews are both technical and sociological, and both factors must be accommodated.

Maintenance

41. Maintenance typically consumes 40 to 80 percent of software costs. It is probably the most important software lifecycle phase.
42. Enhancements represent roughly 60 percent of maintenance costs.
43. Maintenance is a solution– not a problem.
44. Understanding the existing product is the most difficult maintenance task.
45. Better methods lead to more maintenance, not less.

Quality

46. Quality is a collection of attributes.
47. Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability.

Reliability

48. There are errors that most programmers tend to make.
49. Errors tend to cluster.
50. There is no single best approach to software error removal.
51. Residual errors will always persist. The goal should be to minimize or eliminate severe errors.

Efficiency

52. Efficiency stems more from good design than good coding.
53. High-order language code can be about 90 percent as efficient as comparable assembler code.
54. There are tradeoffs between optimizing for time and optimizing for space.

Research

55. Many researchers advocate rather than investigate.

And the list of fallacies:

Management

1. You can’t manage what you can’t measure.
2. You can manage quality into a software product.

People

3. Programming can and should be egoless.

Tools and Techniques

4. Tools and techniques: one size fits all.
5. Software needs more methodologies.

Estimation

6. To estimate cost and schedule, first estimate lines of code.

Testing

7. Random test input is a good way to optimize testing.

Reviews

8. “Given enough eyeballs, all bugs are shallow”.

Maintenance

9. The way to predict future maintenance costs and to make product replacement decisions is to look at past cost data.

Education

10. You teach people how to program by showing them how to write programs.

Although this book has been published in 2004, the topics that are discussed in this book very much apply today and probably many years to come. I personally got the most from the facts about people, estimation, testing and maintenance. I really enjoyed reading this fascinating book and I encourage you to pick it up as well. Awareness of these facts and fallacies, whether you agree or disagree with them,  is the first step to improving our craft.

That time has long passed.

When you really only had to target IE6, you could pretend the web was platform independent.

The truth is now the web is neither, nor will ever be platform independent.  It’s just an illusion based on the simple notion that browsers basically just render HTML.

How many platforms are there then?

This is a surprisingly difficult question to answer.

Back before the web really took off there were basically 3 platforms to develop an app for: Windows; Unix/Linux; and Mac.

When we answer this question for the web, really we have to look at browsers as if they are the operating system.  Since the same browser exists on multiple base OS’s but could be different, we have to count each combination of browser and OS as a potentially separate version.

Windows: IE6, IE7, IE8, IE9 (beta), Firefox, Chrome, Safari

OSX: IE, Firefox, Safari (more?)

Linux: Firefox, Chrome

Android: Webkit

iPad, iPhone: Safari

I don’t have nearly every combination listed, but this is what I would consider a good coverage for any kind of public facing website.

Oh, don’t forget to cross this again with localization and globalization, because you might have a localization problem that only happens in a certain language in a certain browser on a certain OS.

Not just rendering level differences

It is also very interesting to consider that a web developer now has to consider how their site will not just render, but be used on a mobile platform. 

Consider how Google released an iPad version of Gmail.  And although, you may not really care if your site works on an iPhone or an Android phone, you probably should start caring about how it works on tablets like the iPad, because that market is only growing.

If you have a website that doesn’t work on someone’s iPad when they are shopping online, do you think they will get up, go turn on the computer, and go to your site to make the purchase or they will buy from a different site with a few touches?

With a phone size resolution, the considerations are even more important.

Tools help me make the web platform independent

No tool exists right now that can handle the non-technical aspects of platform independence for your web application, but let us imagine for a second that a library like JQuery really made your javascript platform independent.

If we were to hold onto that shaky assumption, we would need to make sure that we never wrote javascript that wasn’t written through the JQuery API.  (Which happens to be an extremely leaky abstraction over javascript, CSS, and the DOM.) We would still have to make sure our HTML and CSS tags were platform independent.

So even if we could get parts of our development to be mostly platform independent, we would still need to test on all of the major platforms, because we could not rely on the platform independence.

Now, don’t get me wrong here.  I love JQuery.  It makes the job of a web developer so much easier.  But, there is an important distinction.  APIs and libraries like JQuery make it easier to write platform independent web code, but they don’t make our code platform independent.

What does all this mean?

We’ve gotten to the point where the most platform independent technology you can use is either Flash or Silverlight.

I’m not sure if this is the future of development, but it very well might be.

One important point to draw from this realization is that we shouldn’t necessarily choose to make our application a web application, because we need it to be platform independent.  It seems like about 5 years ago, the web became the default choice, because it was better to have platform independence than a rich UI.

Hopefully, for the sake of web developers some of these paths die off or converge, or that standards compliance becomes so good that you could really write code for one browser and expect it to work on all the others.

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

If you think ASP.NET Web Forms automatically results in boilerplate, procedural code, this show is for you. Turns out, there are some techniques we can apply to Web Forms (like a salve) that make them creamier and delicious. Keith tells us how Pluralsight.com gets built, along with the tools, techniques, patterns, and practices that the team uses.

Okay, okay, the team really boils down to Keith, Fritz, and me, but that’s not the point! The point is, there is some coolness under the covers, and this show peals them back.

- Dave Starr

Keith Brown

Keith is a co-founder of Pluralsight where he oversees the developer security curriculum, which has an impact across all of Pluralsight’s course offerings. Keith spends most of his time researching security techniques and technologies, and has spent a decade teaching and developing course material for professional software developers. Keith is a contributing editor for MSDN Magazine, where he wrote the Security Briefs column for eight years. Keith regularly contributes feature articles to the magazine, while focusing his attention most recently on his blog.

Throughout my career as a professional software developer,   I’ve spent quite a lot of my learning time to sharpen my debugging skills. I’ve always considered this as one of the required abilities of a true software craftsman. I also strongly believe that the time spent hunting bugs should be minimized as much as possible. Other required disciplines like Test-Driven Development should prevent using your debugging skills as much as possible. But when the shit hits the fan, being able to fall back on solid debugging skills is essential for any software engineer.

Long time readers of my blog know that I’m a huge fan of John Robbins’ books on the same topic. So when Paul Butcher, the author of Debug It!, asked me to give his book a read, I wholeheartedly accepted. And I’m very glad I did.

Most people automatically think about their favorite debugger tool when they hear or speak about “debugging”. This is not what this book is about. This book is about the intellectual process of fixing bugs. Just as Red-Green-Refactor, debugging is a discipline with its own core process.

The book is divided into three parts, each of which shines a light on a specific aspect of debugging as a whole. The first part both provides an overview as an in-depth explanation for each of the steps in the debugging process.   

For more experienced developers this might just be a recap of the process they already know and follow. For less experienced developers, this first part provides a treasure of information that many of us have learned the hard way throughout our career.

The second part talks about how debugging fits into the wider software development process. Topics like bug tracking, dealing with users/support staff, prioritizing bugs, software quality, etc. … are discussed in the two chapters that constitute this part of the book.

The third and final part is composed of a number of more ‘advanced’ topics. A number of strategies are discussed for dealing with special cases like patching, concurrency bugs, Heisenbugs, performance bugs, bugs in third-party software, etc. … . There’s also a chapter that describes the ideal debugging environment, basically evangelizing automated tests, source control and automatic builds which are pretty basic things for most of us but unfortunately not everyone. The chapter on self-debugging software was quite interesting as well as the final chapter on anti-patterns which is also highly recommended. I was personally intrigued by the author’s take on maintenance teams, which reinforced my opinion on the matter (this might be a future blog post). 

This book also contains a vast number of anecdotes and short stories about real-world scenarios that help illustrate the different topics and enforce the points that the author tries to make.

Again, this book is highly recommended as it contains a whole lot of wisdom and experience from the field of software engineering. It’s only 190 pages, so you should be able to get through very quickly. So, you can’t lose on this one.

I know that I’ve been posting a lot of book reviews lately. I’ve been enjoying a quiet three week vacation at home so I’m making a futile attempt to catch up on my reading. I’ll probably have one or two more book reviews coming up.  

So who am I anyway? Good question! Some of you might know me as TheCodeJunkie on Twitter or from my self-titled blog that I have been blogging on up until this point (and might continue doing, haven’t really made up my mind yet what I am going to do with it). However, my real name is Andreas Håkansson and I guess I could describe myself as a nearly 30 year old .NET developer from Sweden, with a passion for pretty much everything in the software engineering / craftsmanship department (hey, why limit yourself to one kind of cake when there’s so much to be had out there!).

I am a strong advocator of Open-Source Software and I head the MEF Contrib project, a set of community contributed extensions, tools and samples for the Managed Extensibility Framework, and I have also created the Common Service Factory, a WCF extension that enabled dependency injection in services (it’s a bit dated, but it works like a charm – probably should give it some love as soon as I can find a slice of spare time in my life).

Oh yeah, there’s more to me than being a code ninjah – somehow I’ve also managed to get married to my high school sweetheart (12 years since we hooked up and still going strong) and together we have two wonderful boys (3 and 1½ years old – boy do they know how to keep us busy hehe)

Well I guess that’s it… now you know a bit about me, and I hope to get to know a bit more about you, the readers of Elegant Code, so please stop by my posts and drop me a line or two. See you there!

The ColorPicker is pretty much self explanatory.  It allows a user to select a color using a color canvas, a hue slider, and an alpha slider for transparency.

This is what is looks like when it is in display mode:

This is what it looks like in edit mode:

It is a pretty simple control for now.  There will be added functionality in the coming future to support entering RGB and HSV values, as well as Hexadecimal values.

There is a SelectedColor dependency property that can be data bound to as follows.

As you can see, I have been hard at work trying to make the Extended WPF Toolkit a successful project full of valuable controls that can be used in your application.  But I will need feedback on the controls to make sure they are meeting the needs of the users.  So please leave your feedback, good or bad, in the Discussions section of the project site.