Making Lemonade

Lemons in a colander on a blue table

I live in a wooded area, and have fallen behind in my yard work. Again.

So, there is an enormous pile of leaves in my backyard, with a lot of raking yet to be done. Over the weekend, I hoped to make some progress on this chore.

My town allows residents to burn leaves, and when you have as many as I do, that is by far the most efficient method of dealing with them. So, on Saturday, I went to the fire department to get a burn permit.

I have learned from experience that they don’t allow us to burn when it is too windy, too dry, or if there is even a threat of rain. Saturday morning seemed like a perfect day to burn leaves: there had been some rain recently (it’s April in New England after all) so the ground and vegetation were still a bit damp. It was sunny, with nothing but a few small, white clouds in the deep blue sky, and no rain in the forecast. And, there was just a very slight breeze. So, I was fairly confident that if I went to the fire station, I’d be granted a permit.

However, I remembered that burning is only allowed during certain times of the year. I could not remember what those times were. On my last visit to the fire station, I was told that I had missed my opportunity, and no more permits would be granted for the remainder of the year. That was in November. They told me I’d have to come back in the spring, but I did not remember whether they had given me a date, so I checked the town website.

What I found there was disappointing: Burn permits are issued only if it is after Columbus Day or before April 30. So, when I went in November, it was the right time of year per the town ordinance, after all. As to why they refused to issue the permit, I do not know.

Whatever their reason for refusing the permit in November, I was now in a bit of a bind. It was April 18, and permits are only issued until April 30, and they allow a maximum of 2 per month (each permit is only good for the day it is issued). So I was determined to get as much done as possible.

As noted, I was pretty sure they’d give me a permit on this day. I had printed out the ordinance from the town website, so if they argued with me about the date, I could show them that it was still within the range. And the weather could not have been better.

However, I was disappointed yet again. When I arrived at the station, a sign in the window read:

NO PERMITS TODAY DUE TO WEATHER CONDITIONS.

I got out of my car, looked up at the blue sky with the puffy clouds, felt the barely-existent breeze on my face, and went inside to ask what it was about the weather that would make it unsuitable for burning.

Experience has taught me to go easy when dealing with government officials at any level. They have a tendency to be a bit touchy, and they can make life more difficult for you if you get on their bad side. So, I was as friendly and matter-of-fact as possible when I asked why permits would not be issued.

“Let’s see… Why are we doing this? Oh yeah. The National Weather Service is calling for very dry conditions. And the National Forest Service, which is what we go by, has put out a red flag, because they expect it to be dry later.”

What to do? With so few days left in the burning season, it was not likely that I’d get another opportunity; after all, there are only certain days when I have time available to do yard work, and the likelihood that any of those few days would just happen to have the right kind of weather seemed exceedingly small.

If I fail to rake the leaves, it’s not just that my grass will die. If that were the case, I could just rake the leaves off the grass into the woods around the edges of my property and be done with it. The problem is, if I don’t rake, then the leaves in the woods at the edge of my property pile up and provide harborage for ticks. Three members of my immediate family, plus our dog, have suffered from Lyme disease, so I really don’t want more ticks.

Well, there are always bags. If I put leaves into those large, brown paper bags made for the purpose, then I can place them by the side of the road for the town to pick up, or I can bring them to the town garage myself.

Why don’t I just use bags all the time? Because they are wasteful. Remember, I have a LOT of leaves. Putting them all in bags is wasteful on several counts:

  • It wastes time. It takes much more time to put the leaves in bags than it does to rake them into a pile and burn them.
  • It wastes money. The bags are not very expensive, but they are far from free, and for the quantity I need, it really adds up.
  • It wastes paper. The paper on one of those large bags could make multiple grocery bags, or yards of wrapping paper, or something else useful.
  • It wastes fuel. Hauling dozens of large paper bags to a facility miles away will require the use of some fossil fuels. Maybe a small amount, but whatever it is, it’s that much more than would be used by just burning the leaves in place.

As you can see, I really think leaf bags are a bad idea for my yard.

But what is my alternative? Provide more tick harborage this summer!

What did I do? I started putting my leaves in bags.

As far as I am concerned, it is far from optimal. In fact, I think it’s a pretty bad idea. However, it’s the only tool left me to get the job done. So, I do the best job of raking I can. I’m careful to stuff the bags full, but not so full as to weaken them, in order to not be any more wasteful. And, I am thankful to be out in the fresh air and sunshine.

Why is this on a blog about programming?

Depending on where you are in your career, it may not have happened to you yet. But if you pursue a career in software engineering, you are bound to experience it at some point – most likely multiple times: You will be forced to work with sub-optimal tools. In fact, you may be in a situation where the only tools at your disposal are really not suited to the task at all.

There are many factors that go into any organization’s technology choices. Budget considerations are certainly at or near the top of the list in most cases. But there are other things that factor in as well:

  • What technical skills do we already have in house?
  • What skills can our current resources be expected to acquire given time and budgetary constraints?
  • Given the current job market, what skill sets can we hire, and what will they cost?
  • What existing third-party and/or legacy systems will our new software need to integrate with?
  • Do any of our very senior people (all the way up to c-level folks in some cases) have preferences for certain technologies (e.g. .Net vs. Java)?

If you’ve been doing this for a while, you’ll likely think of other factors not listed, and that just makes the point more clear: software development and deployment tools are not chosen based solely on their technical merits, and there will be many times when you are convinced that the choices made by your organization are not the best ones.

What do to? Make lemonade.

Take the tools that are given to you and build the best product you possibly can within those constraints. Make it as beautiful, usable, robust, maintainable, secure, and scalable as the tools, time, and other imposed limitations allow.

And when you have deployed it, enjoy the satisfaction of a job well done.

Will it be perfect? Unlikely. But if you’ve done the best that could be done with the lemons you were provided, then you’ve done your job.

Am I saying that you should not try to influence the technology decisions? Not at all. By all means, if you have a well-considered opinion, make it known. If your organization is open to such input, then I encourage you to fight for the technology you believe to be the best. Fight hard, and don’t give up until the final decision is handed down.

But once the decision is made, make the best of it. Don’t waste a bit of your time or energy fretting about how much better your software could be “if only.”

Share:
facebooktwittergoogle_plusredditlinkedintumblrmail

Getting a Handle on Recursion

Recursion is a concept that is fundamental to programming, and yet there are engineers with Master’s degrees in Computer Science and multiple years of experience who have trouble wrapping their minds around it. Classic textbook examples such as finding the nth number in the Fibonacci sequence are certainly simple and illustrative, but they are also somewhat subtle, and not everyone has an easy time applying them to real-world problems.

So far, I have had little success in helping people with this issue, but recently I stumbled on a recursion sample in the MDN JavaScript documentation that, it seems to me, could be an ideal tool to help programmers wrap their minds around how recursive function calls behave. It doesn’t do anything remotely useful, except to clearly illustrate what happens when a function calls itself repeatedly.

Here is the sample, with only minor adjustments by yours truly:

function recurse(num) {
    if (num < 0)
        return;
    // Do something before the recursive call
    document.getElementById('output').innerHTML += 'Before: ' + num + '<br>';
    // Make the recursive call
    recurse (num - 1);
    // Do something after the recursive call. We won't get here
    // until after the above call to recurse() has exited
    document.getElementById("output").innerHTML += 'After: ' + num + '<br>';
}

recurse(3);

Here is the output:
Before: 3
Before: 2
Before: 1
Before: 0
After: 0
After: 1
After: 2
After: 3

The key to understanding this output is to remember that whenever a function is called, the program execution will not proceed to the next line until the function exits. Let’s walk through it.

First, we call the recurse() function with num = 3. This will produce the output, “Before: 3” and then call recurse() with num = 2.  This will print out “Before: 2” and then call recurse() with num = 1. This will print “Before: 1” and call recurse() with num = 0. Here is where it starts to get interesting: It prints out “Before: 0” and then calls recurse() with num = -1.

Because num < 0, the function simply returns without printing anything. This allows the code that called the function to continue to the next line, which prints “After: 0” and exits. This allows the calling code to continue to the next line and print “After: 1” and exit. And so on.

Here is a short video walk-through:

I’ve also set up a JSFiddle with this same function so that you can play with it yourself and get a feel for it. Once you feel comfortable with that, then it’s time to  take it to the next level with a slightly more complex example on JSFiddle.

If you’re looking for inspiration, you might also enjoy browsing through the discussions of real-world recursion on StackOverflow and Quora.

 

Share:
facebooktwittergoogle_plusredditlinkedintumblrmail

Taking AWS for a Spin

Amazon Web Services console
Amazon Web Services Console

I’ve been planning to deploy something to the Amazon Web Services cloud for some time now, so when I started thinking about options for hosting the new blog, and looked at Amazon’s “Free for a year” offer, I couldn’t resist. Well, maybe I could have; I really didn’t try.

So what’s it like? So far, it’s great. I was able to set up the entire site without a single issue. To understand why this is remarkable, you need to take a moment to consider all of the steps involved:

  • Stand up a Linux server
  • Install Apache, PHP (including MySQL extensions), and FTP
  • Configure the DNS servers
  • Stand up and configure a MySQL database server
  • Install and configure WordPress

There are plenty of opportunities for something to go wrong in a list like that, but nothing did. Why was it so painless? Three reasons:

  1. The AWS console is easy to use, and everything seems to just work
  2. The AWS documentation is clear and easy to follow
  3. As for the one item that I did not immediately find in the AWS docs, this Stack Overflow Q&A came to the rescue

Now keep in mind I’m not a server or networking guru. I’ve had to set up development environments plenty of times, but when it comes to setting up production environments, I leave all of the server and networking stuff to the experts whenever I can. So for a simple software engineer like yours truly to be able to set up and configure all of the aforementioned stuff in an unfamiliar environment without so much as one significant difficulty is really quite a feat. A feat for which I take no credit whatsoever.

The only issue that I found with the AWS console is that it’s not always easy to tell whether you’re remaining within the bounds of the free account. Sometimes, it is easy to tell; for example, when setting up a new EC2 server, the options are clearly marked to enable you to identify what is available for free and what isn’t. However, not all parts of the console are so clearly marked.

I ran afoul of this when setting up the DNS servers. It turns out that these are not free. I found this out because the console provides a way to set up various warnings, and one of these is a warning to let you know if your cost is going above a certain threshold. I had set up a warning with a threshold of 0.00, and within a day received an email telling me that my cost was now $1.00. It did not tell me what exactly the $1 was for, however.

So, I created a support ticket to find out what was costing money, and to my pleasant surprise, received a clear and professional response within a couple of hours. The support person informed me that the charge would be removed, and all I needed to do was to delete the DNS servers. On the one hand, it’s a bit disappointing that the free-vs.-not-free paths are not more clearly defined; on the other, the alarm worked perfectly, and the support was excellent.

As you can infer from the above, the free options are designed to prevent any kind of production application from being deployed. I realized this well before I got the $1.00 email, because of other limitations that were clearly marked in the console. Most fundamentally, the amount of storage and RAM available on the free servers is not sufficient. No problem; this makes perfect sense, and I don’t fault Amazon for this at all.

As a result, however, the blog you are actually reading is not hosted on AWS. Amazon’s free options are not designed to support a production site, and their full-fledged EC2 service is overkill for a simple blog, so I opted for a conventional hosting solution for this site.

Meanwhile I’m keeping the Amazon account for R&D. I look forward to digging deeper and learning more about AWS as I deploy some of my own apps over the course of the year. As you can see from the screen shot above, there is much more functionality in the AWS console than I’ve even touched as yet. Of course, I don’t expect things will always go smoothly – I’m bound to get frustrated with AWS at some point – but what I’ve seen so far is encouraging.

Share:
facebooktwittergoogle_plusredditlinkedintumblrmail

Why a New Blog?

New Beginning: Opening the MacBook Pro to start work on something cool

If you are at all familiar with my existing programming blog, you may wonder why I decided to start a new one. Moreover, since programming blogs aren’t exactly all the rage these days, you may wonder why I’m bothering to write one at all. Well, here is your chance to get the answers to these questions.

As to why I’m writing a blog about programming, there are two reasons: 1. I like to help people, and 2. I like to write. I hope to present some useful information (and perhaps some insights, but don’t count on anything profound) while at the same time enjoying the pleasure of writing.

As for my old blog, well… it’s old. The domain name has the word “design” in it not because I thought of myself as an artist or graphic designer, but because of the way the term “Web Designer” was used when I procured that domain. For those who don’t know (or don’t remember), “Web Designer” was often used as a title for a person who did it all: create graphics, design page layout, choreograph and develop interactive features, build the web services, design the database schema, write the SQL, etc. So, when I first started robsondesign.com, I considered myself a Web Designer.

Over time, a number of things happened to change this. First, the technology grew to be more sophisticated, which meant it also grew more complicated, and so it became increasingly difficult for one person to do everything well. Moreover, as the capabilities of web technologies increased, so did the end users’ expectations. With people expecting faster response times, better graphics, more usable layouts and information architectures, more sophisticated functionality, and more information at their fingertips, the field of web development grew, and multiple specialties arose to meet the demand. In addition to that, enterprise application development moved to web-based, service-oriented architectures, and corporate intranets developed into vast suites of specialized business software. Throughout this time of amazing change, I have pursued an engineering path focused on enterprise application development, and it has been quite a few years since I thought of myself as a Web Designer.

With all of that in mind, it was past time to come up with a name that better describes what I do.

So that, in a nutshell, is why I’m starting this new blog. The goal is to make it fresh, modern, and relevant. I hope you enjoy it, and that you find some useful information here from time to time.

Share:
facebooktwittergoogle_plusredditlinkedintumblrmail