5 posts tagged with code
Coders are Creative

September 18, 2014
Programmers are Creative

Programmers are often not the first profession which comes to mind when considering creativity. Everyone likes to mention the designers, and the front-end UI/UX people when they talk about being creative. And while those roles are certainly the most visible and visually creative roles there is a certain level of creativity involved in programming as well. And so for all the programmers out there – here are 3 reasons why programmers are creative.

1. Programmers Solve Problems Creatively

I know, you were expecting this for the first point weren’t you. This is what we always tend to laugh about. Programmers doing whatever to “make it work”. Or the famous code comment which says, “Don’t touch this, it works.” Of course we consider this to be a bad form of creative programming and yet it hints at something deeper. Obviously there must be some level of creativity. I’ve seen some examples of code which look beautiful on the outside and function but when I dig deeper into the code I’m amazed. The creative “workarounds” (that’s an affectionate and oft-used name for this type of coding) which are in place sometimes leave me speechless.

But there are plenty of great examples of solving problems creatively. Programmers have a unique way of analyzing and solving problems that others would leave others completely stumped. They are able to analyze and determine alternate methods for getting the results they need and often times won’t take no for an answer. It’s highly creative.

2. Programmers See Code As Beautiful

One of my favorite movies of all times is the Matrix. It’s a classic movie and one which holds a special place in my heart. I remember with great fondness watching the coders stare at the screen and “see” the world. They no longer saw the code but instead they saw the world as it existed around them. I loved that idea. I have always wanted to be like that and while there is a level of science fiction involved I have also seen some coders who exhibit a creative and unique ability to see what the code does. These programmers see the very lines of code as beautiful and through the code they see what the outcome is. They are able to experience the end result, what the application will do without ever seeing a user interface.

When a programmer is able to look at code and view the finished product through just the code I believe they see the code as beautiful. Good well-written code is indeed beautiful. I will often tell people the work we do at WebSpark is more than just make great applications. We make beautiful code. We see beauty in the code. And that makes us creative.

3. Programmers Are Uniquely Gifted

Code engineers are accustomed to several aspects of their work which make them unique. As you’ll find with other more well-known creative types – good creatives cannot be rushed. They work at the right speed to accomplish what everyone else will see as creative genius. They have a vision in their mind and they work towards that vision in a manner which suits them.

Secondly programmers focus on a variety of aspects of a system which to others may seem disparate and unrelated and yet in the end tie back in together perfectly to create the final product. I’ve watched firsthand as expert programmers will create a bit of code in one file, navigate three folders away to an unrelated file add additional code and then 30 minutes later will write an additional function which fits perfectly between the two and makes everything work together a cohesive whole.

Lastly, coders as other creative types work crazy hours (most of the time). You’ll find them up at all hours of day or night feverishly working on their ideas or projects. Sometimes its deadlines, but other times they do it because they love what they are doing. They are passionate about their work and work with a frantic excitement.


There’s no doubt in my mind that programmers are creative and they demonstrate this creativity through a number of ways. I’ve picked out just three (five if you count the last point as three separate ones). The next time you find yourself questioning a programmer’s ability to be creative stop yourself and think about this post. It’s possible you’ll find they are just as creative as another.

 

importance of indexing database directory

June 4, 2014
The Importance of Indexing

I wanted to write a short article on the importance of indexing your database tables when creating an application. This may sound like a small thing but the time savings you’ll see as a result are much larger.

More Than Code

If there is enough interest I may create several articles on the subject of database improvements and ways to increase efficiency in your application due to following best practices in your database layer. I mentioned it a bit earlier that it’s sounds like a small thing, but many developers neglect this step when they are creating their applications. There never seems to be a shortage of interest in improving page load speeds, increasing efficiency in the code which runs the various functions and conditionals for retrieving the data. However, it seems increasingly rare to find good developers interested in improving their application from a properly architected database.

I find this diminishing focus disturbing as the database interactions, queries, searches, and general structure account for a good amount of the processing time required when a page is loaded or data is retrieved.

Database Indexes

In this article I want to look at the value of indexing your database columns, when you should use indexes, and what value they provide.

Let’s begin with a quick definition of the term. Indexing a database table means you are marking a particular column within a particular database table to be stored for use later. It may be helpful to think of the index as follows: When you insert a row into your table you are essentially adding that information to the end of every row and all the data currently existing within that table (that’s easy enough to understand). Now, consider the situation where you have a table consisting of a couple thousand rows (that’s not even a very large table). When you go to look up a particular piece of information you must perform a ‘table scan’ of every row and every value in every column of that table.

Example:
Let’s assume you have a database table to store all your contacts information. You collect 20 pieces of information on each person (first name, last name, company, address, city, state, facebook, twitter and so on). And you’re religious about entering information so you have now acquired 10,000 contacts. Congratulations you’ve done a fantastic job, but now you need to find that one person whose name you can’t quite remember but you know it has a wa in the last name somewhere. You perform a search on your contacts to find those contacts with the last name having a wa in it. Tick Tick Tick…that is an intensive search.

Now let’s look at that same situation only this time let’s imagine you have an index on the last name field. This means every time you insert a new record your index is updated and the new last name value added to the index. When you perform an index, this will typically be an alphabetical index with a list of corresponding row ID’s where that value is found. This is where it gets exciting.

The Math Behind The Scenes

Your index can be searched incredibly quickly by using a binary search. When performing a binary search you essentially can reduce your time by half (or more) with each row search.Rather than an “N” based search where N is the number of rows in your database table you can follow a much more efficient log(n) search instead. Math is so much fun! Here’s a wikipedia definition:

A binary search halves the number of items to check with each iteration, so locating an item (or determining its absence) takes logarithmic time.
Wikipedia

 

Here’s a simple comparison: You can compare this to how you look a name up in a phonebook. If you know you’re looking for a name that starts with Hu, and you flip open the book to Kr and on a second row you find Ed then you know the result you want is roughly halfway between the two. You continue “splitting” the pages like this until you find the page and the number you need. Your database works much the same way. Instead of requiring you to search each and every row completely to the end, you can instead search only the indexed column (which has been sorted) and search much more quickly for the exact row you need.

The Downside of Indexes

Nothing is perfect in life and just as with other software architect choices there is a tradeoff you will need to consider when implementing indexes in your code. The process of adding a new row to an index does increase the time involved when storing a row. This is because it must add the new value to the index and then re-sort it. It’s a minor expense but one you should consider as you implement indexes. Be somewhat selective on what fields (columns) would be most benefited by adding an index.

The More You Know

Database architecting is a vitally important part of the designing phase of any application. If you are a programmer and focus most of your time working on creating cutting edge code you should take the time to also learn how to best create your database structure. There are many other opportunities for improving your development skills and your applications by examining your database schema and your query building. In future articles we’ll explore more of these techniques and way they can increase your skills. The more you know the better you’ll be.

Remember, we’re all in this together!

 

dependency injection service locators slide

May 13, 2014
Dependency Injection, Service Locators, Testing, and Life

This is a talk I gave recently at OpenWest in Utah as part of their PHP track.

Below are the slides for the talk. When the video is posted I will link to that as well. I realize the slides lack some of the information shared in person.

Please note: I am not choosing sides in the battle over which is a better design pattern. :)

joomla development getting started

May 10, 2014
Joomla Development Tutorial Series

Introduction to Joomla Development. This Joomla development tutorial short video serves only to introduce the course and the material to be covered in future videos. We’ll start easy.

Below is the initial video for a series I’ve begun on Joomla CMS third party development. Depending on the interest I receive I’m going to continue demonstrating how to develop code for the Joomla CMS. I’ve decided to start with plugins, then modules, and finally a component.

I can’t stress enough, if you like these – I need to know. Otherwise I will assume everyone is already an expert and there’s no need to continue the series!

This video is very short and only serves as course introduction.

Joomla Development 101: Introduction

Joomla Development 101: Lesson 1 from dbhurley on Vimeo.

Associated Slides

April 2, 2014
Lessons in Coding: Don’t Repeat Yourself

image

I’m a parent. That tends to sound a bit like a confession. But most people who know me also know that I love kids. I have three children right now, and hope to add more in the near future.

I’ve learned many things from being a parent. I learned there is a strange phenomenon with children where they cannot hear something they are told unless I tell them multiple times. It’s interesting because it doesn’t seem to be all the time, only certain times, and usually only those times when they need to do something they don’t particularly want to do. And I really get tired of repeating myself. It gets quite annoying after a while.

Ok, so now everyone’s wondering, what does this have to do with coding and best development practices. Today I want to talk about the principle of Don’t Repeat Yourself.

Definition

Wikipedia defines the Don’t Repeat Yourself Principle as follows:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Let’s take that definition and break it down into some easy-to-understand pieces. And then let’s apply it to code.

Every piece of knowledge: In development that could be a class, a function, or merely even a block of code within a function.
single, unambiguous, authoritative representation: code should exist only once and it should be clearly written.
within a system: inside your component, module, plugin, application etc.

If we take those pieces and re-write the definition in our new terms it would look more like this:

Any code written and used within your component should exist in only one location and be clearly written.

That seems to make more sense. Now that we have a good working definition of what is involved in the principle of Don’t Repeat Yourself let’s look at some examples of how you would do this within your code.

Example of Bad Code

function getSingleItem($id) 
{
   // assume all variables needed
   $query = $this->db->getQuery(TRUE)
            ->select($this->db->quoteName(array('i.*', 'c.name', 'a.something')))
            ->from($this->db->quoteName('#__myitems', 'i'))
            ->join('LEFT', $this->db->quoteName('#__categories', 'c') . ' ON (' . 
              $this->db->quoteName('i.category_id') . ' = ' . $this->db->quoteName('c.category_id') . ')')
            ->join('LEFT', $this->db->quoteName('#__attributes', 'a') . ' ON (' .
              $this->db->quoteName('a.item_id') . ' = ' . $this->db->quoteName('i.item_id') . ')')
            ->where($this->db->quoteName('i.item_id') . ' = '. (int) $id);
   $this->db->setQuery($query);
   $item = $this->db->loadObject();
}

function getManyItems($ids) 
{ 
   // assume all variables needed 
   $query = $this->db->getQuery(TRUE) 
            ->select($this->db->quoteName(array('i.*', 'c.name', 'a.something'))) 
            ->from($this->db->quoteName('#myitems', 'i')) 
            ->join('LEFT', $this->db->quoteName('#categories', 'c') . ' ON (' . $this->db->quoteName('i.category_id') . ' = ' . 
              $this->db->quoteName('c.category_id') . ')') 
            ->join('LEFT', $this->db->quoteName('#__attributes', 'a') . ' ON (' . $this->db->quoteName('a.item_id') . ' = ' . 
              $this->db->quoteName('i.item_id') . ')') 
            ->where($this->db->quoteName('i.item_id') . ' IN '. implode(',', $ids)); 
    $this->db->setQuery($query); 
    $item = $this->db->loadObject(); 
}

Does that code look similar? It should. I created the second function by copying the first function and then changing a single line. (Hint: Look at the “where” clause). So what would this code look like if I re-wrote it but did so without duplicating any lines of code? Here’s one possible example.

Example of Better Code

function getSingleItem($id) 
{ 
   // assume all variables needed 
   $query = $this->getQuery(); 
   $query->where($this->db->quoteName('i.item_id') . ' = '. (int) $id); 
   $this->db->setQuery($query); 
   $item = $this->db->loadObject(); 
}

function getManyItems($ids) 
{ 
   // assume all variables needed 
   $query = $this->getQuery(); 
   $query->where($this->db->quoteName('i.item_id') . ' IN '. implode(',', $ids));
   $this->db->setQuery($query);
   $item = $this->db->loadObject();
}

function getQuery() 
{ 
   $query = $this->db->getQuery(TRUE) 
            ->select($this->db->quoteName(array('i.*', 'c.name', 'a.something'))) 
            ->from($this->db->quoteName('#myitems', 'i')) 
            ->join('LEFT', $this->db->quoteName('#categories', 'c') . ' ON (' . $this->db->quoteName('i.category_id') . ' = ' . 
              $this->db->quoteName('c.category_id') . ')') 
            ->join('LEFT', $this->db->quoteName('#__attributes', 'a') . ' ON (' . $this->db->quoteName('a.item_id') . ' = ' . 
              $this->db->quoteName('i.item_id') . ')');
   
   return $query;
}

Instead of re-writing the query function twice, once inside of each function, I have extracted the repeated code and written it as a third function which I can now call from either of the two other functions. It seems simple. In fact, many developers are probably already implementing this type of coding to make their code better.

Benefits

Why is it important to not repeat yourself? There are many benefits to writing your code only once. Sure, nobody like to waste time writing code over and over again, but even more importantly you reduce the chance for bugs to occur. Less code means less chance of failure points. I am sure we’ve all had those moments when we can’t find the problem until after wasting an hour or more looking you find a missing semi-colon. I know it’s happened to me. There are other benefits too. When you later realize you need to add another table on to the query because your client needs more information from the database you only need to update one query now!

I hope many developers are already aware of this principle of Don’t Repeat Yourself. If this is a new concept, congratulations you have now learned what it means to write DRY code. I wanted to start this series with an easy topic and though this doesn’t cover every technical detail of this principle it does focus on a strong aspect of it. In the coming releases I look forward to looking at more principles of good development.