Dec 8 2008

My Visual Studio Color Settings

Category: Software Developmentemilioc @ 17:59

I am really surprised that there isn't a community site for sharing Visual Studio settings.  If there is one, let me know because I've looked and couldn't find anything.  I thought it would be nice to share my font and color settings for the people interested.  It's a version of Ragnarok Grey that I tweaked a little to fit my personal taste.  I uploaded some screen shots below to give you a preview.   The download only contains font and color settings so it will not change any of your other VS settings.  You should still back up your current settings just to be on the safe side. 

Dark-Colors.zip (1.97 kb)

You can find more color settings by Tomas Restrepo here including the original.

C#



HTML

JavaScript

Tags: , ,

Dec 2 2008

ToFormattedList Extension Method

Category: Software Developmentemilioc @ 05:54

Forgive me if this incorrect, but I believe the ToFormattedList() IEnumerable extension method was part of the early ASP.NET MVC previews.  If you’ve used the method then you are aware of its usefulness.  You pass in a format string (ex. “<li>{0}</li>”) and you get back a string of all the objects that were in your IEnumerable individually formatted ("very nice" -Borat).  This is perfect if all the objects in your IEnumerable have an acceptable ToString() method. What if you are working with POCOs or business objects and you would like to use a property instead of an objects ToString() value?  This is exactly the scenario that prompted me to create a ToFormattedList() extension method for IEnumerable<T>.  

To satisfy this new requirement I needed to add a new parameter.  My version of ToFormattedList() takes a Func<T, string> parameter to access the appropriate property (we need the func, we gotta have that func).  Below is the simple code that makes this work and example of its use.

Code

    public static string ToFormattedList<T>(this IEnumerable<T> list, string format, Func<T, string> func) {
        var s = "";

        foreach (T item in list) {
            s += string.Format(format, func.Invoke(item));
        }

        return s;
    }

Usage

    var output = companies.ToFormattedList("<li>{0}</li>", c => c.Name);

Tags: , ,

Nov 27 2008

Lazy Init VS Constructor Init

Category: Software Developmentemilioc @ 01:18

One of my favorite things about programming is also one of the most frustrating things about programming. There's always more than one way to solve a problem.  Software developers are faced with many choices.  There is much to consider at every phase in the process.  Efficiency, deadlines, performance, maintainability and scalability are all important topics to consider.  So what criteria should you use to choose the correct convention or pattern?  I'm here to let you know, there is no definitive answer (surprise).  Also, this versus article is not meant to declare a victor.  I wanted to use this example to illustrate my point on the choices developers have to make and the criteria that affect those choices.

Let's take on lazy init first.  Below is a simple class with a Names property.  Instead of initializing the list when the object is created, initialization is delayed until the property is needed.  The if block is there to protect against the creation of a new list every time you retrieve the Names property.  Performance is the most common argument I hear for using lazy init.  Performance is a very good reason to use lazy init.  As you can see, there is quite a bit going on for a simple object initialization.  At minimum, you need a field and a property, not to mention the null object precaution.  If you've been developing for a while, it is easy to get in the habit of starting with optimized code.  Shouldn't the goal be to start simple and refactor as required?  Is this common convention needless complexity?

 public class SimpleClass {

        private IList<string> _names;
        public IList<string> Names {
            get {
                if (_names == null) {
                    _names = new List<string>();
                }
                return _names;
            }
        }

        public SimpleClass() {

        }

    }

And in this corner we have the challenger, constructor init.  Using this approach, the Names property will be initialized when SimpleClass is initialized.  One benefit of constructor init, as seen in the example below, is simplicity.  There is no need for a field or an if statement.  What about performance?  Performance is a valid concern but it should be weighed against code efficiency.  Simply put, a developer has a lot less code to write when using constructor init.  The need to optimize for performance may never arise.  In fact, if lazy init improves your code's performance, you might have a problem with SRP (zing).

    public class SimpleClass {

        public IList<string> Names { get; private set; }

        public SimpleClass() {
            Names = new List<string>();
        }

    }

It's probably obvious that I prefer simplicity over complexity.  I acknowledge that complexity has its place in development and is appropriate at times.  I believe the priorities and factors that lead to code complexity are an important and overlooked part of software development.  If you're not sure why you need it, maybe you don't.  The complex solution should answer the why.

Note: a similar comparison can be made for Service Locator and Constructor Injection but I will save that for another post.

Tags:

Nov 13 2008

Strongly Typed Model Object Without Code-Behind (Sort of)

Category: Software Developmentemilioc @ 20:21

Are you using ASP.NET MVC?  Do you want a strongly typed ViewData.Model object without a code-behind file?  Tough, who said life was fair?  I am just kidding ;p. 

After reading Look Ma, No Code-Behind! by Chad Myers, I was inspired to share my approach.  In my approach, I swap a code-behind file for an ordinary class file.  I create a file per view folder named _ViewDataModelType.cs.  The file name is optional and can be changed per view folder.  I like to use the same name over and over because I am lazy.

Setup

In this file I declare all the ViewPage and ViewUserControl subclasses needed for this particular view folder.  Use your namespaces wisely because if you're not careful you can run into naming collisions.  Below is an example of what one these classes might look like.

namespace NoCodeBehind.Views.Employee {
    public class EmployeeIndex : ViewPage<IEnumerable<Employee>> {
    }

    public class EmployeeShow : ViewPage<EmployeeViewModel> {
    }

    public class EmployeePartial : ViewUserControl<EmployeePartialViewModel> {
    }
}

Usage

All you need now is to wire up your .aspx page.  The Inherits attribute is the important piece.  Below is an example.

<%@ Page Language="C#" AutoEventWireup="true" Inherits="NoCodeBehind.Views.Employee.EmployeeIndex" %>

After that, you are done.  You now have a strongly typed model object at your finger tips. 

Conclusion

Using a code-behind file for every view page is a non-option for me.  This is a simple work around and helps keep my project slim around the waistline.  I am definitely open to other solutions to this issue.  I hope this helps if you are wrestling with the same issue.

Tags:

Nov 12 2008

jQuery and The Amazing Selectors Part 1

Category: Software Developmentemilioc @ 21:54

If you are looking around for a JavaScript library or looking to switch libraries, you should give jQuery a sample.  If you have been doing web development for any period of time, then I am sure you've heard of it.  From my experience, jQuery is an incredibly easy library to learn.   I made the decision to learn jQuery several months ago and it has been a godsend.  It has dramatically improved my relationship with JavaScript; a strained relationship, at best, no thanks to IE.  But those days are history along with the days of getElementById.  This brings me to the topic of this post.  I wanted to take a little time to talk about jQuery selectors and showcase a few of my favs.  When using jQuery, IDs are optional.  You can select elements using class name, DOM position, attribute value and IDs (if you feel like being all precise and stuff).

Keep in my mind this is not an exhaustive list of every possible selector.  It is, however, a list of my most used (read favorite) selectors.

1.  var value = $('.fields:first input:hidden').val();

Selector number 1 will find the first instance of the fields class (.fields:first) and then select all hidden inputs (input:hidden) found within the containing tag.  Since there is only one hidden input that matches the selection, only one will be returned.  Making the retrieval of the hidden inputs value a snap.

    <div class="fields">
        <input type="text" id="textBox1" name="textBox1"  />
        <input type="text" id="textBox2" name="textBox2"  />
        <input type="hidden" id="Hidden1" name="Hidden1"  value="Hello"/>
    </div>

    <div class="fields">
        <input type="text" id="textBox3" name="textBox3"  />
        <input type="text" id="textBox4" name="textBox4"  />
        <input type="hidden" id="Hidden2" name="Hidden2"  value="Goodbye"/>
    </div>

 2. $('.fields input, .fields select, .fields .someClass').click(function() { alert('hello') });

Numero dos on the list is the multi-selector.  I am not sure if that is the official name but that's what I like to call it.  Using this selector, you combine multiple selectors into one separating each selector with a comma.  This will allow you to manipulate the matches of three selections as one.  It can be very useful if you need to assign an event to multiple elements of different types. 

<div class="fields">
    <input type="text" id="textBox1" name="textBox1"  />
    <select>
        <option>opt 1</option>
        <option>opt 2</option>
        <option>opt 3</option>
    </select>
    <input type="text" id="textBox2" name="textBox2" class="someClass"  />
</div>

3. $(this).nextAll('ul').toggle();

This selector is kind of a stretch.  Inside an event you can pass in the this keyword as a selector and get instance access to the element that fired the event.  If you need to find some related DOM elements you need a change in strategy.  The this keyword can't be concatenated with string selectors.  One possibility, is to grab the ID attribute of the element that fired the event ($(this).attr('id')).  But what if your element doesn't have an ID?  That's where jQuery's traversing methods make an entrance.  The nextAll() method will get all sibling objects that appear after the currently selected object.  You can optionally pass selectors in to the the nextAll() method ...

<div>
    <h3 class="toggleButton">Text</h3>
    <ul><li>text</li></ul>
    <ul><li>text</li></ul>
    <ul><li>text</li></ul>
    <ul><li>text</li></ul>
</div>

 $('.toggleButton').click(function(event) {
    $(this).nextAll('ul').toggle();
});

Conclusion

With three short examples I am only scratching the surface of jQuery's amazing selectors.  I hope this post makes you hungry for more and at the very least, gets the uninterested interested in jQuery.  I will be back with more soon!

Tags: ,

Oct 28 2008

Are You Agile?

Category: Agile Project Managementemilioc @ 05:35
How do you know if you are an agile software developer?  How do you know if your team is agile?  It is easy to say you are.  It is easy to intend to be.  It is easy to lose agility if not continually maintained.  On long projects focus shifts often.  Success is a moving target.  Agile practices have to be retuned and reapplied periodically.  That’s how it was intended to work.  That’s what makes it beautiful.  It’s a solution to be implemented later.  

The Agile Manifesto is a guideline for writing better software.  You could say it is a loosely coupled collection of best practices.  The Agile Manifesto does not contain a significant amount of detail and I believe that’s intentional.  It’s composed of a dozen flexible recommendations.  It’s not a script or a rigid doctrine of rules.  There is room for interpretation.  This freedom allows for easy adoption.   It also allows for radical variations.  Care should be taken not to let freedom become an evil mutation of agile practices.  If in doubt or debate, remember, “Working software is the primary measure of progress.”

It’s easy for teams to allow existing bad habits to remain when moving towards a more agile environment.  Understandably, old habits die hard.  Agile teams should actively identify their bad habits and discuss ways to eliminate them.  Allowing bad habits to evolve and masquerade as an agile practice is an evil mutation.  To avoid this, a team should continually improve their process.  Review the Twelve Principles of Agile Software as a team.  Eliminate rigid and strict processes.  Remove unnecessary steps in processes.  Find new ways to improve efficiency.  In short, tailor your process to best serve the team and your users.  Determining how best to implement the Agile Manifesto is up to you.

The Agile Manifesto has a lot to offer software developers.  Being agile in your profession is not limited to the software industry.  Many teams can learn lessons from the guidelines put forth.  Just as the software industry gained inspiration from a patterns book written on architecture.  The Agile Manifesto makes good sense in the work place.  So, if you strive to be agile, you should ask yourself often; self, are you agile?

Tags:

Oct 22 2008

Write Code

Category: Software Developmentemilioc @ 07:09
The title of this post is not a command to readers but more of a request to myself.  I believe strongly in starting any project, any feature, with a simple approach.  Correction, the simplest approach.  I write code to satisfy requirements.  I know my first attempt is not the final solution.  I promise myself, with every line I write, I will improve this code when I have more time.  The time stipulation is the kiss of death.  Improving your code should be a personal priority.  Time constraints can be overcome with discipline.

Help Yourself, Help Your Team
Start your sprints with code, start your sprints with tests.  You cannot refactor code that does not exist.  Write code! It will probably be bad; even the gurus write bad code.  This is why alphas and betas are so prevalent in the industry.  No one gets it right the first time and if they did--we wouldn’t need refactoring or TDD.  Developers need to combat writers block like a traditional novelist (keep coding).  Strive for improvement, ask your team to review your code. It’s okay.

Experienced programmers should encourage their inexperienced counterparts to code.  Let them drive when pair programming.  Resist the urge to interrupt the linear learning process.  Programmers tend to be hard on themselves and even harder on their peers.  This is an extremely anti-agile practice.  Agile programmers succeed together and fail together.  That is the precious gem that makes ‘Agile’ more than just a buzz word.

Tags: ,