Posts Tagged “Programming”

03 01 2010

3 Technology Components to Learn in 2010

Posted by: Justin in Programming, Rails, tags: , ,

Sass/Compass

I spent a good chunk of the last few months of 2009 completely immersed in Haml, and having spent time using both ERb and the templating language that ships with ASP.NET MVC, I have no intentions of ever turning back.  That being said, Sass seems like the next logical choice for cleaning up my html/css, and while I was a bit confused as to the point of Compass (other than being a Sass compiler – which I already get for free through the Haml gem), Chris Eppstein finally gives up the goods about 15 or 16 minutes into his Compass screencast (the first 15 minutes are great too, but if you already have a grasp on Sass, they’re a bit redundant).

Long story short: I’m tired of sucking at CSS, and short of completely immersing myself in the spec, learning the idiosyncrasies of which browser supports which feature, and then somehow retaining all of that information, Compass with Sass seems very appealing.

Related Technologies: Blueprint, YUI

RSpec

While I’m still not quite a ninja in Test::Unit, I finally feel at least proficient in it, and though I’d like nothing more than to proclaim my love for Shoulda from the highest peak of the highest mountains, I feel that I at least owe it to myself to check out RSpec before I consider the book closed on testing frameworks in Rails.

Related Technologies: Cucumber, Factory Girl, Mocha

Hudson

I spent the first three or so years of my professional life completely immersed in the .NET world (ignoring that first year spent looking at COBOL mainframe code), and in that world, CruiseControl .NET is king of the continuous integration castle.  So, when I came into the Rails fold, I naturally turned to cruisecontrol.rb for my continuous integration needs.  Unfortunately, either I haven’t yet fully grasped the extensibility of cruisecontrol.rb or the community simply hasn’t yet matured to the level of CC.NET, but I am so far underwhelmed by the Ruby version of this popular continuous integration solution.  Luckily, while first learning Rails, my initial confusion over cruisecontrol.rb led me to stackoverflow where someone suggested checking out Hudson … six months later, I think I just might give it a try.

 

Runners Up

Git – Git is an incredibly popular SCM solution in the Rails world, so I will eventually need to learn it.  For now, I think I’ll wait and hope that the tooling matures a bit more.

E-TextEditor – If it weren’t for the need to drop down into Cygwin to run rails apps, this would have been a no brainer.  Unfortunately for e, Netbeans still has a much, much shallower learning curve.  Unfortunately for Netbeans, it can be very, very slow, so e is something else that I will eventually need to learn.

 

Additional Resources

This list is still (by far) the best resource I have found for identifying new technology avenues to pursue.

Comments 6 Comments »

28 04 2008

Building Collections Using List<T>

Posted by: Justin in C#, Programming, tags: , , ,

Our main application at work was primarily built using .Net 1.1.  That being said, most of the collection objects inherit from a base class that gives support for things like adding to, removing from, and enumerating through the collection.  We have since migrated the application to .Net 2.0 but there has been little incentive to go back and update these collections to use the support for generics that was added as part of the .Net 2.0 framework.

 

Recently I took on the role of lead developer for a smaller, internal project that will live independently from any of our other apps.  The fact that this app will not use any of the business objects or the same database meant that I was free to utilize whatever technology I thought best suited for the project.  Eventually, I settled on developing the application in the newly released .Net 3.5 framework using C# 3.0 mainly due to the fact that I was anxious to start using Linq (I know, probably not the most solid reason for choosing a platform, but it is a reason, and that’s really all I needed).  When I started building up my business object layer, I eventually came across the need for collections.  The base class that was ported over from .Net 1.1 would have been more than adequate, but I knew that if I wanted to use Linq, I would have to inherit from something that implemented the IEnumerable interface.  After looking around the web and playing around with a few different methods, I eventually decided that the easiest way to build up the collection would be to inherit from the List<T> generic class (where ‘T’ is the type of object that will live in the collection).

 

Here is an example using a widget object to populate a collection of widget:

 

The widget object:

public class Widget
{
    /// <summary>
    /// The Widget ID
    /// </summary>
    public int WidgetID { get; set; }

    /// <summary>
    /// The Widget Name
    /// </summary>
    public string WidgetName { get; set; }

    /// <summary>
    /// The default public constructor.
    /// </summary>
    /// <param name="ID">The widget ID</param>
    /// <param name="Name">The widget Name</param>
    public Widget(int ID, int Name)
    {
        WidgetID = ID;
        WidgetName = Name;
    }
}

 

The widget collection:

public class WidgetCollection : List<Widget>
{
    /// <summary>
    /// The default public constructor.
    /// </summary>
    public WidgetCollection()
    {
        Reload();
    }

    /// <summary>
    /// Load the collection.  This would normally be done from the database.
    /// </summary>
    private void Load()
    {
        this.Add(new Widget(1, "Widget1"));
        this.Add(new Widget(2, "Widget2"));
    }

    /// <summary>
    /// Clear out the collection and reload it.
    /// </summary>
    public void Reload()
    {
        this.Clear();
        Load();
    }
}

 

This gives me the ability to then bind dropdowns within the program as well as the ability to manipulate the collection using Linq (which is what I was after all along).

 

So, how about you?  Is inheriting from List<T> a pretty standard way of building up collections, or have I stumbled upon one of those programming faux pas that more experienced developers know to avoid?

Comments No Comments »