Archive for category Software Development

Fun with C#: Create a handy calendar using Iterators

Here’s something fun with can do with C#. Imagine we need to work with dates within a given year. For instance, I want to list out all days within the year of 2017. A little Calendar class like the one below would be handy:

var calendar = new Calendar(2017);
var days = calendar;
foreach (var day in days)
{
    Console.WriteLine(day);
}

The output looks somewhat like this:

What if I wanted to list all days in january, like so:

var days = calendar. Where(d => d.Month == 1);

The output:

Last but not least, maybe I want to list all Saturdays in january:

var days = calendar.Where(d => d.Month == 1 && d.DayOfWeek == DayOfWeek.Saturday))

The output:

One could think that under the hood the Calendar class uses some sort of Collection, Array or List of DateTime objects. In reality, it uses an iterator, implemented using the yield return keywords:

public class Calendar : IEnumerable<DateTime>
{
readonly int _year;

public Calendar(int year)
{
_year = year;
}

public IEnumerator<DateTime> GetEnumerator()
{
var firstDayOfTheYear = new DateTime(_year, 1, 1);
var lastDayOfTheYear = new DateTime(_year, 12, 31);
var daysInTheYear = (lastDayOfTheYear - firstDayOfTheYear).TotalDays;

for (int i = 0; i <= daysInTheYear; i++)
{
yield return firstDayOfTheYear.AddDays(i);
}
}

IEnumerator IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
}

Ain’t that fun and handy? 🙂

I really like this combination of IEnumerable<T>, iterators, and LINQ.

Leave a comment

Speaking at the North Houston .NET User Group this week

I’m speaking at the North Houston .NET User Group this week, on Feb 16 at 6:30pm. This is a new session I’ve put together. Check this out:

Code Review: I mean no harm

As part of the work I’ve been doing for many years, I get to do a lot of code review. I usually document things that come up doing a code review so I can share it with other developers in the teams. In this session, I share some of the code I’ve looked at, the reasons why the code raised yellow or red flags in my head, and possible solutions I’ve proposed.

Leave a comment

Speaking at the Houston .NET User Group this week

I’m speaking at the Houston .NET User Group this Thursday, February 9, at 6:30pm. Click here to find out about location and other details.

I’ll be delivering a brand new session. Check out the title:

The Software Does Not Work? Rewrite it!

What’s this session really about?

Outdated technology? Unmaintainable codebase? Politics? Those are just some of the reasons that cause software rewrites. Whether a rewrite is really what is needed or not, chances are we all work in such projects.

Do we rewrite the entire software? Can we rewrite just parts of it? Where do we start? Can we automate the process?

In the last 15 years, I’ve worked in a variety of such projects. I’d like to share the most important lessons I’ve learned in these projects. In this talk, I’ll share the different types of rewrites and techniques, what I learned from it, and how it changed my way of approaching both software rewrites as well as greenfield projects.

I want your feedback!!

I hope to see some of my readers there! If you do show up there, please rate my session afterwards and provide me some feedback here! Like I said, it’s a brand new session, so I’m looking forward to constructive criticism so I can improve my material.

Leave a comment

Fun with C#: Using delegates to get rid of switch-blocks

I’m starting a new series here: Fun with C#! The idea is to post a couple of things I do in this cool language. 🙂

When I talk about Clean Code with developers, an example that I always use is switch-blocks. Every bad code out there always features abusive use of switch-blocks. In most cases, those blocks start off very simple, with one-liners, like the sample below:

public void DoStuff(DayOfTheWeek dayOfTheWeek)
{
    switch (dayOfTheWeek)
    {
        case DayOfTheWeek.Sunday:
            Console.WriteLine("Do stuff for Sunday...");
            break;
        case DayOfTheWeek.Monday:
            Console.WriteLine("Do stuff for Monday...");
            break;
        case DayOfTheWeek.Tuesday:
            Console.WriteLine("Do stuff for Tuesday...");
            break;
        case DayOfTheWeek.Wednesday:
            Console.WriteLine("Do stuff for Wednesday...");
            break;
        case DayOfTheWeek.Thursday:
            Console.WriteLine("Do stuff for Thursday...");
            break;
        case DayOfTheWeek.Friday:
            Console.WriteLine("Do stuff for Friday...");
            break;
        case DayOfTheWeek.Saturday:
            Console.WriteLine("Do stuff for Saturday...");
            break;
    }
}

It always start off simple like that. Next thing you know, there’s another “simple change” that comes in, and now the code looks somewhat like this:

public void DoStuff(DayOfTheWeek dayOfTheWeek, TimeOfTheDay timeOfTheDay)
{
    switch (dayOfTheWeek)
    {
        case DayOfTheWeek.Sunday:
            Console.WriteLine("Do stuff for Sunday...");
            if (timeOfTheDay == TimeOfTheDay.Evening)
            {
                Console.WriteLine("Go to bed early!");
            }
            break;
		...
        case DayOfTheWeek.Saturday:
            if (timeOfTheDay == TimeOfTheDay.Morning)
            {
                Console.WriteLine("You may stay a little longer in bed...");
            }
            else
            {
                Console.WriteLine("Do stuff for Saturday...");
            }
            break;
    }
}

Then comes an if-else, a for-loop, a switch-block (yes, inside the other switch, of course), and that one method becomes a terrible mess.

Well, whenever I see a case like that, I consider changing the switch-block into a dictionary of actions. I populate a dictionary with the individual blocks of code I need executed, and then I get the delegate out of the dictionary and invoke it whenever needed. The updated code would look like this:

readonly Dictionary<DayOfTheWeek, Action<TimeOfTheDay>> _dailyActions =
new Dictionary<DayOfTheWeek, Action<TimeOfTheDay>>();

public FamousSwitch()
{
_dailyActions.Add(DayOfTheWeek.Sunday, DoSunday());
_dailyActions.Add(DayOfTheWeek.Monday, DoMonday());
_dailyActions.Add(DayOfTheWeek.Tuesday, DoTuesday());
_dailyActions.Add(DayOfTheWeek.Wednesday, DoWednesday());
_dailyActions.Add(DayOfTheWeek.Thursday, DoThursday());
_dailyActions.Add(DayOfTheWeek.Friday, DoFriday());
_dailyActions.Add(DayOfTheWeek.Saturday, DoSaturday());
}

Action<TimeOfTheDay> DoSaturday()
{
return timeOfTheDay =>
{
if (timeOfTheDay == TimeOfTheDay.Morning)
{
Console.WriteLine("You may stay a little longer in bed...");
}
else
{
Console.WriteLine("Do stuff for Saturday...");
}
};
}

Action<TimeOfTheDay> DoFriday()
{
return timeOfTheDay => Console.WriteLine("Do stuff for Friday...");
}

Action<TimeOfTheDay> DoThursday()
{
return timeOfTheDay => Console.WriteLine("Do stuff for Thursday...");
}

Action<TimeOfTheDay> DoWednesday()
{
return timeOfTheDay => Console.WriteLine("Do stuff for Wednesday...");
}

Action<TimeOfTheDay> DoTuesday()
{
return timeOfTheDay => Console.WriteLine("Do stuff for Tuesday...");
}

Action<TimeOfTheDay> DoMonday()
{
return timeOfTheDay => Console.WriteLine("Do stuff for Monday...");
}

Action<TimeOfTheDay> DoSunday()
{
return timeOfTheDay =>
{
Console.WriteLine("Do stuff for Sunday...");
if (timeOfTheDay == TimeOfTheDay.Evening)
{
Console.WriteLine("Go to bed early!");
}
};
}

public void DoStuff(DayOfTheWeek dayOfTheWeek)
{
_dailyActions[dayOfTheWeek].Invoke(TimeOfTheDay.Morning);
}

I like keeping the smaller individual methods for each operation. Most often than not, I’ll end up moving those separate methods into one separate class, and very often, will turn that one separate class into several separate classes.

Anyway…

  • I like using a dictionary of delegates instead of using switch-blocks;
  • I like having small methods a lot better than having one long method

Leave a comment

Houston Tech Fest 2016: Feedback Requested!

To those of you who’ll attend to my sessions at Houston Tech Fest 2016 this Saturday, September 24, please make sure to let me know how you liked it by going to the following links:

Software Development is a Joke

Want to Build Software? Get Your Act Together First!

These are two of my favorite sessions, and I’d love to receive feedback so I can keep improving them.

Leave a comment

Speaking at the Houston Tech Fest 2016 on Saturday

I’ll be speaking at the Houston Tech Fest 2016 this Saturday. If you haven’t heard of this event, it’s a huge 1-day conference, free of charge, with tons of sessions (11 tracks!).

I’ve presented sessions there for at least 5 editions of the conference, and after a 3-year hiatus, I’m happy to be back, as I’ve known so many people there and have always had a great time.

Below you find information about the sessions I’ll be delivering and the panel I’ll participate, so make sure to come by and say hi. 🙂

Oh, also, if you come attend to my sessions and enjoy it, you can also contact Improving and request I come to your company for a Lunch and Learn! Check out the list of sessions available and spread the word out: Free Improving Lunch and Learns.

Software Development is a Joke!

Room 305 (SoftDev) at 1pm

Several of my technical presentations introduce some kind of humor, but sometimes people end up learning the joke and not the concept. So I decided to do a humor presentation based on software development, introduce some technical stuff, and maybe people won’t laugh, but rather learn the technical stuff!

After so many years writing software, I can’t help but laugh at so many (good and bad!) experiences myself and other developers have had. Not to mention things that just can’t make sense to normal people: how can this ˆ[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$ be called a regular expression? (If you know by heart what that expression means, you are probably the kind of people who’ll try to explain to me why zerobased arrays are kinda cool…just don’t!).

The Business of Software (Panel)

Room 306 (Mobile)

Want to build software? Get your act together first!

Room 300 (Mixed) at 4:10pm

Software developers are supposed to create applications that make people’s life easier, automating tedious tasks, encouraging users to get their work done, organizing complex workflows into digestible information and actions, helping them separate the most important information from the least important.
But still, most developers forget to automate their own boring tasks. We forget to organize our information. We sometimes use tools that do not help us get our work done. So how can we build software that fits our client needs, if we don’t understand those needs ourselves?
This session is not only about software development; this session is about things we can do and tools we can use to organize ourselves, so we can free up our minds to more important things. Tools covered in this session include (but not limited to): Evernote, application launchers, screen capture tools, tablets, smartphones, etc.

Leave a comment

The topic of testing never gets old

At the last Virtual Brown Bag we talked about Test-Driven Development (TDD), Behavior-Driven Development (BDD), and related subjects (you can watch it here).

I’ve been very fortunate in the last 5 years working on projects where I simply write the tests as part of the work. It’s just something I do.

Is it a new feature?

If I need to work on a new feature, I write the tests to spec out my understanding of the feature. If I can’t write the test, most likely I don’t understand what the feature is, and if that’s the case, I shouldn’t write any code to begin with. Instead, I should pair up with the QA guys and/or the business analysts (or work directly with my client), and make sure I understand not only what the feature is, but also why it is important to the business.

Is it a defect?

If I need to work on fixing a defect, I’ll do my best to write a test that reproduces the issue. Granted, some issues (such as multi-threading issues) are really difficult to reproduce in test, but hopefully those types of issues aren’t the core of my projects. Whenever there is an area that’s hard to test, I’ll try to isolate as much of the code as possible, decreasing the surface that’s hard to be tested.

The biggest lessons I’ve learned from testing

While I think I’ve learned quite a bit about the technical aspects of writing tests, and have been harvesting so many positive outcomes, such as writing better code, I don’t think that alone makes me a better developer.

I believe that the act of taking a step back to think about how I’m going to write tests has made me take an extra step back to understand what it is that I’m building. This has made me collaborate a lot more with people who actually understand the business. I don’t really care much anymore about using this or that framework/language/etc just because it’s cool; I care much more about building features that will bring value to my client. Seeing a client smile because you gave him or her the feature needed is very rewarding.

A recent experience

In the last 3 months I’ve been working part time on a project where I’m the only developer, and I have no QA, no business analyst, no project manager. Here are some bullets from my personal project notes:

  • The first phase of this project has gone into production two weeks ago
  • The client is beyond happy
  • Very few defects were found in production (and corrected immediately)
  • There are close to 400 tests
  • I do NOT have everything under test. I’m keeping Controllers very thin, calling out to Commands, Services, etc. Things the controllers call ARE under test.

The whole testing thing…

As I finished writing this post, I just remember I actually wrote another post about the whole testing thing 8 years ago! Time sure flies by…

Leave a comment