My Github Streak

After a few weeks of working on my Adaptive Web Design Using Device Detection project, I got tired of seeing my current github streak get reset every weekend.

So I decided that instead of just working every day and calling myself a “lifelong learner” — and letting people think what they want to think — I would make a point of committing something to github everyday, so I can prove my dedication and desire to develop.

Now that I am getting close to the 300 day mark, keeping the streak going has only increased in importance best way to lose weight quickly. Given that the green graph only shows a year’s worth of changes, will it get “stuck” at 365, or increase to infinity?

At this point the only thing I can think of that could possibly keep me from answering this question would be an extremely challenging full-time job, one that requires every ounce of my energy. And actually, finding something like that would not be a bad thing.

Well played,, well played!

My Efforts Pay Off

Because of previous experiences, I always take great care to try to write clean code that is easy to maintain.

These efforts have paid off; I have always received positive feedback, at worst a helpful pointer, from colleagues on my code, regardless of whether I ask for it — and I do appreciate code reviews, whether they are formal or informal.

As this short essay and this page on Stack Overflow demonstrate, there are plenty who agree with me in this respect.

Run These Sites From My Home

One of my favorite sites is BuiltWith.Com. It will tell you plenty about this site, but one thing it doesn’t know is that I run it, and several others, from my home.

Geek Pride and Land Lines

I am very proud of the fact that I have a static IP address and run these sites out of my home. My internet provider is Forethought.Net, and the ability to host sites is included with my internet connection and land line.

Land lines may be old-fashioned, but this is the sort of offer I cannot refuse.

Well-Rounded Cheapskate

I assure you that in running these sites I do everything that needs to be done. This is partly because I like to be well-rounded, but mostly because I am a cheapskate.

I also assure you that I do not consider myself an expert in any of these tasks. For one thing, I dislike the term “expert” in any context, and for another, I am always open to ways to improve on my processes. One reason I dislike the term is because an “expert” would never question their own abilities….

If you’re interested, some of my more important processes and tools are available in my jmws_accoutrements repository on github.

“Everything” Means Everything

In case you do not run any websites out of your home, here is a list of what I mean by “everything:”

  • obtain static ip
  • conceive the types of sites I want to host
  • purchase domain names
  • buy the requisite hardware
  • configure the home network
  • install requisite operating systems and software and keep it up to date
  • learn the technologies needed to create these sites
  • actually do the work of creating these sites
  • create databases and site users with sufficiently secure credentials
  • imagine, organize, write, format, and post content
  • keep up-to-date backups of code and content
  • configure the server, ensuring it is secure
  • deploy sites to server, along with updates as they become available
  • design, write, test, and maintain programs to add any functionality that is missing out of the box
  • keep up-to-date with industry trends
  • document programs written
  • document deployment and other important processes
  • register the sites with google
  • comply with any requests google makes concerning security and searchability

If this looks like a lot of work, I can assure you that it is.

Favorite Practices

In addition to saving me money, a big advantage to doing things this way his lets me find out first hand what type of work I like best.

I like the programming best, and the writing and design tasks are close behind that. Testing and deploying are not quite as fun, but I don’t have to do them much, and I am too much of a cheapskate to be willing to pay someone else to do it, so we do what we have to do.

I greatly enjoy writing little scripts to help with deployment-related tasks, and am currently porting my bash scripts to python. (You can see these scripts in the bin directory of my jmws_accoutrements repo.

Because I am the only one using these experimental extensions, at this time it’s not really worth it to me to automate testing for this work. Kudos go to Drupal though for integrating automated testing out of the box.

Flow Is the Best

Ultimately, as I have learned in some of the online classes I’ve taken MOOCs, I love any type of work that involves flow. The linked-to article at defines flow as being in a “state of effortless concentration and enjoyment.”

As you might imagine, working on my own for free can lead to occasional procrastination. That’s actually fine, because I always find that once I get going and into the flow of things, it can difficult to stop.

Moreover, “it’s all good,” and I greatly prefer any of this sort of work to at least 99% of the other occupations out there!

“Words to Avoid”

Recently I was looking at articles about the various Open Source Software Licenses on Gnu.Org, and I stumbled upon this list of words to avoid. It’s an interesting list and I encourage you to look through it, especially if you think everything on the internet should be free.


The case for avoiding LAMP in favor of GLAMP (GNU/Linux Apache MySql PHP) is one interesting entry; I would expect that LAMP makes the list is because the “P” is ambiguous (possibly standing for Perl or Python rather than PHP). Instead, it is the Linux part of the acronym that the author, Richard M. Stallman (“RMS”), finds inaccurate.

Many if not most of the entries are mostly if not totally pedantic. And I admit that is something I find myself being guilty of from time to time, so it would be hypocritical for me to complain about that.

PC or WC?

But I found some humor in the entry for “PC.” RMS takes issue with the term because he asserts that some people assume all PCs run Windows.

Even if the computer is running something other than Windows, it is still a “PC.” So to prevent confusion, the list suggests using “WC” for computers running Windows.

I found this to be quite funny, because I always thought that “WC” stood for “Water Closet.”

Front or Back End?

I remember the first time recruiter asked me if I was a front or back end developer. It took me by surprise and I was unsure how to answer.

Full Stack

A short time later I learned the term “Full Stack,” and liked the sound of it. I am by nature a very curious person, always looking to learn more, and limiting myself to either the back end or front end is not appealing.

As it turns out, “Full Stack Web Developer” is the most popular term used for Developer Occupations (28.0%) in the Stack Overflow Developer Survey, with the closest runner up (“Back-End Web Developer”) coming in at a distant 12.2%.

Increasing Complexity

Staying up to date on all the technological developments going on these days is very challenging, and these challenges increase daily.

Given this, I have come to think that, these days, expertise is the enemy of the good.

I prefer to focus on knowing enough to get things done, and take the time to learn how to do things well when working on important projects.

Important Fundamentals

Essential knowledge of important fundamentals will always be transferable to other domains. For example, keeping things simple (KISS) and reducing redundancy (DRY) are important keys to high quality and success, no matter what sort of project you are working on.

AWD & RSS, and the Three CMSes

Integrating device detection into the three popular LAMP CMSes is a great way to exercise and add to knowledge of the full stack. But working on this project has made me realize a few things:

  • I enjoy programming, and make a point of doing it every day
  • I enjoy programming in JavaScript, and writing JavaScript programs that will run in a browser requires a certain amount of knowledge about the DOM, HTML, and CSS
  • With all due respect to designers and front end developers — heart you guys, seriously! — in my mind, writing HTML and CSS is not really what I would call “programming,” because those languages do not lend themselves to well-established organizational techniques1
  • So although I am knowledgeable about front end work I am more comfortable working on the server side of things, and that type of work fits well with my experience

Lesson Learned

The take-away for me is, I would definitely be happy doing back end development 100% of the time, but would not be happy doing front end work 100% of the time.

Full stack work is definitely challenging and totally engaging. So my ideal job would have a focus on back end work, and perhaps allow me to help out with front end work if and when the opportunity to do so arises.

But a job doing only back end development would be perfectly acceptable.


1 These organizational techniques include Object Oriented Programming (OOP) and even just breaking reusable code out into functions that are preferably parameterized. All modern programming languages like PHP, Java, JavaScript, Python, C++, Perl, and Ruby support OOP. And note that even ancient languages like Assembler, COBOL, LISP, and the more recent but still primitive shells (ksh, bash, csh, etc.) support breaking out reusable code into some kind of function, where as HTML and CSS do not, at least not yet.

Denver Startup Week 2015

Having just learned about Denver Startup Week the year before, back in 2014, I was better prepared for this one.

I attended sessions every day and worked two volunteer shifts. With all the publicity, presentations, parties, positive energy, and free food, I find it puzzling that more of my friends are not interested in this event.

Some of the Sessions

Following are a few of the sessions I attended:

Virtual Reality 101
Mark Schell, founder of Denver’s Google Development Group, gave a talk covering the basics of Virtual Reality (VR). Among many other things, described why he thinks it will be huge in the coming years.
How Denver Is Leading the Internet of Things
This was a panel discussion featuring a wide variety of members. Among other things, it was interesting, but not really surprising, to learn that the Internet of Things (IoT) has actually been around for a long time, known by the much less catchy term Machine-to-Machine (M2M) communication.
How to Work Remote, Effectively
This session featured a round-table discussion of tips on how to work from home (WFH) better. A few of the topics discussed were:

  • balancing availability with the need to focus
  • being mindful about working too little or too much, and
  • the importance of wearing pants

It should come as no surprise that as time goes on, more and more tools are available to help with working like this.

The Art and Science of Finding Customers for Your Startup
One of the best sessions I went to was this one, presented by Chris Franks. The room was packed, and I and several others wound up having to sit on the floor. If you are interested in this topic, you are definitely in luck, because he has been gracious enough to put the entire presentation online. In it he goes over New Rules, Tools, Tactics, and Voodoo. The last one, “Voodoo,” is not magical by any means but simply well-informed and hard work. This included an example of how to get started by targeting ads and using A/B testing to improve their effectiveness. It was very cool to learn about some of the new tools that google and facebook make available for free, and Chris mentioned some tactics for making the best of them. It looks like he might be back next year!

If you are interested in more information, visit the Denver Startup Week FAQ.

Volunteer Shifts

I signed up to volunteer at the event and was granted two shifts, working the Job Fair on Tuesday and the Soirée on Thursday.

My job at the Job Fair was initially to greet people on their way in, and ensure they got their name tags and the handouts that were available, while they lasted. As the night wore on, there was less and less to do, so I got to visit a few booths and make some new friends.

The Soirée was quite a bit more interesting. The company hosting it, in Denver’s up-and-coming RiNo district, actually had a Bouncy House inside the office! It became my responsibility, and my job was to enforce the standard rules:

  • No shoes
  • No smoking
  • No drinks
  • No more than five people at a time
  • Thank you for your cooperation

As you might imagine, this made for a very fun and memorable evening!


Here are a few highlights of the week:

  • There were probably more people at the kick-off breakfast than at any of the other events I attended. It marked the first time I saw Governor John Hickenlooper in person, and I believe this was the first time I saw any governor of any state give a talk. It was, for the most part, a whirlwind of speakers giving brief shout-outs and stoking the crowd for the week ahead.
  • The talk by Marcus Lemonis was well-attended and inspiring. I did not know who he was prior to this evening. You may be surprised to learn that he considers himself to be “unemployable.” Right. Seriously, I heard him say this; you had to be there to believe it. (In case you have never heard of him, he has his own prime-time TV show.)
  • A common theme running through the IoT sessions I attended was concern about security. We take the ability to easily update our phones and other computers for granted. Will it be so simple to send newly developed and essential security releases to our things?
  • In addition to volunteering at the Soirée, which offered a bunch of free booze btw, I also attended one of the parties at Denver’s Union Station on Monday night. Lots of people were having a lot of fun, but I for one had the nagging sensation that I should be doing something more productive.

There’s much more, of course, such as the personal branding sessions at MetroBoom, the Closing Party on Friday — where we volunteers were given free food — and my own personal mentoring session, which for me was the single most useful event of the entire week.

Looking Forward to the Next One!

Are you inspired, or at least intrigued? If not, I have failed to describe it accurately, because Denver Startup Week is definitely inspiring and intriguing.

Here’s to hoping I see you there next year!

O’Reilly Webcast: Maintainability

From time to time O’Reilly.Com offers technical webcasts. Like their books, they are consistently excellent.

Recently I viewed one about building maintainable software, by Rob van der Leek and Zeljko Obrenovic. In it, they acknowledge that doing so is difficult. Everyone must buy in to the goal and maintainability be built in to the source code from the start this website.

Eight Guidelines

In the webcast, Rob and Zeljko present eight best practices for writing maintainable programs. The guidelines, which follow, are measurable and make sense.

  1. Limit length of code units to 15 lines of code
  2. Limit the number of branch points per code unit to 4
  3. Limit the number of parameters for each code unit to 4
  4. Prevent duplication of blocks of code that contain 7 or more lines
  5. Limit the size of modules to 400 lines of code
  6. Try to have 6 to 12 components of approximately equal size
  7. Avoid cyclic dependencies
  8. Keep the code base to 200,000 lines of code or fewer

Experience and Discipline

In conclusion, they state that

“It takes a lot of discipline and experience if you want to write consistently maintainable code.

As someone with a bit of experience, I agree most heartily.

Denver Startup Week 2014

I first learned about Denver Startup Week through Denver’s Google Development Group in late summer of 2014.

I went to only a few sessions in 2014, but they were enough to pique my interest to be ready for the next one,
in 2015.

Women in Tech

The first session I went to was Women in Tech, led by Ingrid Alongi and Wendy DuBow.Watch Full Movie Online Streaming Online and Download

As Science-turned-Math major in undergraduate school at Virginia Commonwealth University (VCU), I could not help but notice that there were very few women in the Math and Science classes I took — with the exception being Biology. Taking some art classes several years later, I noticed that those classes were biased the other way, having mostly women and very few men in them.

Because I was still very young, this seemed to be just “the way things are.”

Flash forward to Denver Startup Week in 2014, and I finally learned that just because this is “the way things are” does not mean that everyone likes “things” this way, or that it is the best way for “things” to be, or that “things” need to stay this way. So this session was extremely enlightening, to say the least, and it made a lasting impression!

One could fill a book with details about these “things.” Rather than expand on how change is finally happening, I will just offer this link to a site I learned about at the end of Wendy DuBow’s talk, NCW&IT.

You might also consider attending similar sessions at the next Denver Startup Week. I anticipate they will have similar sessions, because it is obvious that this sort of gender bias is definitely a “thing.”

This year I also attended sessions on Building Teams and Pushing Back.

Building Teams

The Building Teams session was a round-table discussion, with participants from Send Grid, Solid Fire, and Photo Bucket, and a few other companies that did not make it into my notes. The topics discussed by members of the panel included:

What was your biggest mistake?

Interestingly, hiring the wrong person and waiting too long to hire someone can both be wrong moves.
What is a Startup?
Although tech companies get a lot of attention, Denver Startup Week is about all types of startups. The intent is for it to appeal not only to technology companies but also to restaurant owners, landscapers, and anyone else interested in going their own way.
How to maintain a Corporate Culture?
One recommendation is to embrace qualities that can scale, and that will still be relevant as the company grows. And one caveat is that a single person can ruin the entire culture, so it is important to listen to employees.

Pushing Back

The last session I went to was about Pushing Back. Here we learned that startups go through the following phases:

  1. Idea
  2. Launch
  3. Validation
  4. Growth
  5. Transition

Pushing Back is most relevant to the Validation and Growth phases.

The take-aways from this session include the need to listen to customers, perhaps by watching them as they use a new app. Relying on experimentation, and being aware of and not trusting your assumptions and biases, is also extremely important.

When a problem surfaces, one technique for finding the root cause is to use a technique known as the “Five Whys.” This may seem a bit childish, but it is effective.

It looks like this:

  1. Why?
  2. Why?
  3. Why?
  4. Why?
  5. Why?

Sure it may be difficult to do this, but I guess that’s why it’s called “Pushing Back.”

Next time you have a problem, try solving it using this technique see here. You might be surprised at what you learn.

Sign Up Already!

So what are you waiting for? Head on over to the Denver Startup Week Website and sign up for the next one.

It’s totally free and I guarantee there is enough variety for it to offer something for everyone!

A Passion for Maintainable Code

Thanks to a book, named Code Simplicity, I finally realized one of the main things I love about programming so much.

Finally, after many years, I have discovered my passion! And that is: writing code that is easy to understand and maintain, and this boils down to keeping code as simple as possible.

The book analyzes the value of software, the effort needed to maintain it, and the desirability of the changes, even though we cannot be sure what the nature of these changes might be.  And it comes to the conclusion that all code needs to change eventually, and the future cost of making these changes is more significant than the initial cost of development lose weight quickly.

The book made me realize that the real cost in software is not in the development of it, but in the maintenance.  By taking a little extra time and ensuring that code is maintainable, in the long run we save money.

And that is what I really enjoy about writing software.  Once I get a program to work once, I don’t like to stop there, the way some people do.  Instead, I like to take the time to look at what I’ve written and ask:

  • Does it make sense?
  • Could what it does be done any more simply?
  • Is there any cruft, any dead, unused code?
  • Will a new person understand it, quickly and easily?
  • Will a new person fix or enhance it, quickly and easily?
  • Will I understand it, quickly and easily, if I need to change it, in the middle of the night, a few years from now, or both?

To tell the truth, I actually have at times felt guilty about taking this extra step.  After all, the program works, why spend more time on it?  And of course there are times when I haven’t been able to take this extra step, and have regretted delivering something that I am not very proud of, something I know could be better, if only there was a bit more time.

This blog contains stories about the benefits of well-designed, easy to maintain code, and the hazards of poorly-designed, difficult to maintain code.

But I still encourage you to buy the book.