Beta Test This!

Unique value in an array?

2011-08-03T11:41:00.000-07:00

So, someone recently told me about an interview question they heard about for some job at Amazon. I thought the question and answer were neat, so I figured I'd share it.

The question goes: "If you were given an array filled with a bunch of numbers, where every number was duplicated exactly one time except for one number, which is only in the array once, what is the most efficient way to find the unique value?"

The answer is to iterate through the array one time, performing XOR on each of the numbers. At the end, the value you have will be the unique value.

Want to see it for yourself?

Here's a JavaScript snippet I wrote to prove it on a smaller scale. This will work on arrays of any size, however.

Speaking of XOR and interview questions, I was a part of creating the team test we give people who want to join our team, and one of the questions was to have the person write a piece of code that would swap variable values without using a 3rd variable as a "value bucket". I decided to try to do this in one line using XOR, and I pulled it off.

The JS for it is:

It's been a while!

2011-08-01T23:19:00.000-07:00

It truly has been a while since I have posted anything here. To be quite honest, I have immersed myself in so much JavaScript best practices, new patterns, performance optimization, etc, that I have highly neglected this blog!

Since my last few posts, I have increased in my JS knowledge IMMENSELY, and that is no joke. I am w3schools certified (link to cert) *with excellence*. I got 69 of the 70 questions right! Woo hoo!

I have studied very carefully presentations, books, papers, etc from various JS gurus, Nicholas Zakas, Douglas Crockford, John Resig, etc. I actually printed out the current ECMAScript specification and read it on a flight to Las Vegas for a team meeting.

I am not joking when I say this, JavaScript is one of my biggest passions. If I could do nothing but analyze problems and engineer solutions in JavaScript all day long, I would do it!

Unfortunately, there isn't really that great of a job market that I can find. I don't have any degrees as of yet, and the area I live in really kind of prevents me from finding any solid JS jobs, and it'd be REALLY hard for me to relocate.

Members on my team at work think I'm really good at JS, and I think I'm pretty good, too. I'd like to be able to focus solely on that, as it is easily my biggest strength, but it's really hard to do that right now.

I'll keep it as a hobby, and maybe one day, I'll find a JS engineering job to call my home.

In other news, I am going to check out Dojo. I've been using jQuery for a very long time now, and I'm interested to dive into another JS library. I like what Dojo brings to the table. I haven't had a chance to dive into the source just yet, but at face value, it promises to offer some really neat functionality.

I am in the process of checking out the repository for the source now (it's huge). I like to dive into source code when I'm picking something new up.

I also purchased a book called Mastering Dojo: JavaScript and Ajax Tools for Great Web Experiences to read over the next few days.

I'm excited to really dig in and learn some new stuff!

My new favorite JavaScript pattern...

2010-03-10T19:57:00.000-08:00

So, I've been doing a lot of reading, and I think I've finally come to the conclusion as to what my favorite JavaScript construction pattern is.

And the winner is...

I like this pattern more than this pattern:

The reason is because I feel like the first one is a little more easy to read.

It just seems a little more intuitive to me.

The conventions I use may be a little weird to you, but I'll walk you through why I have seemingly random capitalization.

Most functions and variable names I do in camelCase:

I have all objects start with a capital letter.

I know, I know -- "technically everything's an object".

To refine my previous statement, anything that's an object literal or an object created by a constructor.

Anything else, I do regular camelCase.

I find it allows me to recognize quickly where my objects are.

I'd be interested in hearing about your favorite JS patterns.

New conventions at work...

2010-03-08T19:45:00.000-08:00

It doesn't take the smartest man in the world to know that without a good set of standards and best practices, a team of developers can have a real mess on their hands when it comes to project development and maintenance.

Last weekend, I got the privilege of being the coauthor of my team's set of best practices and coding conventions.

I am a lead JavaScript developer, so I got to write the JavaScript portion of the document. I also contributed to the ASP and HTML/XML portions of the document as well.

I am pretty excited about the upcoming release of our document, as it will really help push our team to the next level, and give us scalable, maintainable code.

We've agreed to convert any page that needs edits over to the new set of standards before rerolling it to production.

This will give us some development time increases, but in the long run, the benefit is just priceless!

Optimizing your jQuery code - fragment caching rules

2010-02-11T14:30:00.000-08:00

jQuery 1.4 really introduced a lot of cool shit. One thing in particular is the internal caching of elements. When used properly, this can drastically increase your application's performance!

A good example is one I'm currently doing. Currently, I'm working on an admin page that allows a manager to go in and add/edit/remove options, details, and other data that are used by another application front-end for our tech support partners.

I'm doing the modification via AJAX, so when they click on an option, it will grab all the details for that option, and display them, so they can be edited. I'm caching everything grabbed and holding it locally, so I only have to do one AJAX call per option.

When they click the edit button, I'm having the innerHTML of the cells of that row turn into input fields for them to type the new, edited data, and then save when they hit update, reverting back to a regular text-filled cell.

As you can tell, I will be inserting a lot of inputs.

jQuery 1.4 introduced a new way to add elements to your page.

The old way (1.3.2) was something like

or

Something like that.

Now with jQuery 1.4, you can do

This is similar to the second example, the object passed as the second parameter is an attribute object.

What makes 1.4 really awesome, though is that if you use the method of $("<input>") either with an attribute object or going $("<input>").attr(), it will cache the fragments it creates when making these.

So, when you're adding multiple elements, you're basically getting a clone of the cached fragment, and not having to recreate an entirely new element.

The speed and performance boost from this is crazy, and I'd definitely recommend messing around with it.

jQuery Meetups!

2010-02-10T08:01:00.000-08:00

Visit jQuery Meetups

Ternary Operation in JavaScript

2010-01-26T15:05:00.000-08:00

Ternary operations in JavaScript are really awesome.
It's essentially an if/then block, but on one line.

An example would be:

In this example, y would be "howdy".

You can read ternary operations as

y = ( comparison ) ? if it's true, use this value : otherwise, use this value ;

This is a very simple example, but you can see the power behind this.

An example in jQuery could be...

Again, this is a very simple example, but you get the point.

One word of advice, though: never use ternary operations if the values to be set are true/false:

Instead, just use the comparison:

jQuery 1.4 and native JSON support

2010-01-25T07:55:00.000-08:00

I was reading a post by Yehuda Katz (http://www.twitter.com/wycats), and saw how jQuery 1.4 now uses native JSON support, which is available in a lot of more current browsers (IE8, FF 3.5, Chrome 2), and when JSON support is not available, it falls back on its previous JSON parsing.

In a video by Paul Irish (http://www.twitter.com/paul_irish), he states that jQuery 1.4 will now validate the JSON (if native JSON support is not available) and throw errors if the JSON response is not valid JSON, just as native JSON parse would throw errors.

Both of these things are awesome. I am pretty excited about that.

I have been guilty of using malformed JSON simply because I could get away with it.

Now, a great standard is being pushed to the forefront!

I am going to be taking it a step further and ensure that all the JSON I use throughout my apps are valid JSON (even objects I'm passing to jQuery functions).

I'm doing this for a few reasons. One reason is consistency. I like having consistent organization and standards in my applications. This is a must at my job because different members of the team may have to go in and edit my code. If I have a consistent style of programming, they'll be able to easily go in and make changes.

Another reason is, it's just good practice. If I do ALL my JSON in valid JSON format, then I won't even have to go "oh, this is an AJAX call, my response should be valid JSON", I'll just be doing ALL my JSON in valid format, and not have to worry about it.

What are your thoughts about this?

JavaScript console

2010-01-15T07:27:00.000-08:00

At my company, I am required to support different browsers because a lot of employees here like to use their preferred browser; we support IE6+, FF2+, and Chrome. Let me start by saying I love Chrome and I love FireFox. They both have different aspects about them that are amazing.

I love Chrome because it's just really good quality. Google has never really produced any bad products to my knowledge. They're always working to be on the cutting edge and they do a damn good job at it. The V8 engine in Chrome is fan-effing-tastic.

Firefox is a well-rounded browser that has the ability to be customized out the ying-yang. It's Firebug plugin is absolutely amazing. There are also some other plugins I use that are really cool.

One thing that make Chrome and Firefox even better is the fact that they both adhere to web standards! What a concept, right? Haha.

Another thing I love about them is the fact that they have a JavaScript console, which has proved to be a priceless commodity.

IE, however, does not...unless you install something like debugbar (which is a very heavy IE plugin).

I took some time and actually created a console (written completely in JavaScript) that works across all browsers. I can throw different commands at the console, and even have a mode set up to take and interpret JavaScript commands. I use this console in a newer application I'm going to release as an actual event log for my app. It's pretty light weight, and I have added the ability for it to email my team a timestamped log of all events/responses from the application.

I have it self-truncating at 500 rows currently, just to ensure the log doesn't get overly massive.

I just bought my own website (www.matthewcmaxwell.com) and will be setting that up in the near future. When I do, I'll be putting my JavaScript console up there for you to download and try out.

Here's a small pic (bad quality, I know)

How I replaced eval for dynamic initialization

2009-12-14T10:28:00.000-08:00

So, I've been trying to steer clear of JavaScript eval() as much as possible ever since I learned how horribly inefficient it is.

On a recent project I did, titled "Shark Tank", I decided to create the application on the premise that there would be one "landing" page, and the rest would all happen via AJAX.

Well, I needed to have certain things happen on page initialization, and I try to keep my JS all in one spot at the top of the page, and not scattered throughout the page.

So, in my links table on my database, I had the columns "FriendlyName", "URL", "Initializer"

FriendlyName would display the friendly name, i.e. "Add a Lead", URL would be the actual url "add.asp", and the Initializer would be a string literal of the initialization function, which was housed somewhere in my namespace, i.e. "BAMPIT.Add.Initialize"

I started off trying to figure out how to do this without eval, but ran out of time on my deadline, so I just decided to go with eval in order to get the app out on time. Using eval on a string literal to call a function name isn't TOO bad, but I wanted to do this without eval.

So after thinking on it for a while, I came up with a way to do it 100% dynamically, and without eval.

I would personally add this to a namespace or change the function name to avoid potential conflicts with anything.

The function basically starts at the window object and drills down the namespace until it reaches the function you want to execute, and then executes the function.

As always, criticism and comments are always welcome.

JavaScript libraries are good, but be aware...

2009-12-02T04:33:00.000-08:00

So, I've been using jQuery for a while now, and I have absolutely no complaints. Looking back at when I first began using it, my code started to get more efficient, but then I realized that, in using jQuery, I was able to do things in less typed code, but was actually adding MORE things for the browser to do. If you're going to use a jQuery wrapped object more than once, and you're not chaining jQuery commands, save it to a variable.

is super inefficient. Everytime you go $("#tbody"), you're initializing a new jQuery object..

This could be chained by going:

You do add an additional .end() call, which isn't as bad as the first example.

If you didn't want to do this, you could save the initialized object to a variable:

In this example, jQuery is only initialized around the tbody once. This is a very simple example, but I think you get the point. In a large application, CPU cycles matter! Efficiency is key. Building good coding habits is never a bad thing.

5 Reasons Why Douglas Crockford is The Man

2009-09-16T07:43:00.000-07:00

Douglas Crockford is an amazing programmer and a really cool guy. He's spent a very, very long time doing some really great work. If you haven't heard of him, you need to check him out.

I like Douglas Crockford for a few reasons.

1. JSON
   Of course I had to mention it. He made JSON into a standard and because of this, it is now a widely recognized and widely used "Data Interchange Format". "JSON already existed in nature," is what he says, which is true, but it's his diligent work that brought it to the foreground of modern programming.

2. He's knowledgeable
   This almost seems like a no-brainer, but he's a really smart guy. He knows his stuff. If you ever watch his speeches or read his documentation or books, you'll see what I'm talking about.

3. He doesn't beat around the bush
   If something sucks, he'll tell you it sucks; he doesn't sugar coat it. I love this approach when it comes to talking about something because if you sugar coat it, the audience may miss the point entirely. His "in-your-face" approach to how horrible most JavaScript books are is a really good example of this. In his book "The Good Parts", he says: "If you want to learn about the bad parts and how to use them badly, consult any other JavaScript book." Genius.

4. He's well spoken and thorough
   If you've ever read any of his stuff or seen him, you'll know what I mean. He keeps on topic, he's well spoken, and thoroughly goes over every point he needs to make.

5. He responds to his email
   Ok, I know this may seem a little childish, but both times I've had questions I've asked him, he's answered within hours of receiving them, and both times, his answer has been concise and told me exactly what I needed to know. That shows a lot of character, in my opinion.

Often times, when people begin to work for large corporations, such as Yahoo!, they lose touch with a lot of people that respect and admire what they do. Sometimes they just have too much work, and sometimes they just lose interest. With Douglas Crockford, this is not the case. He is an extremely knowledgeable and thorough guy, and though he may seem cynical at times, he's pretty friendly.

If you haven't checked him out, do it now!

Scalability of Ruby on Rails

2009-09-15T17:58:00.000-07:00

I was looking through the slides from jcon today. I really wish I could have gone; it looked like it was awesome.

I noticed that Yehuda Katz was a speaker. He's also a member of the Ruby on Rails core team, and I have been hearing rumors that Ruby on Rails doesn't scale well.

That rumor is a thorn in my side because I am interested in learning Ruby on Rails, but I want to be able to use it on a potentially enterprise level...

I sent Yehuda Katz an email, complimenting his slides and asking about the scalability of Rails and telling him that I had heard it didn't.

He replied with the following, and I thought it would be a good idea to share, just so anyone else who is interested could add their input.

"People who say this don't really understand what scaling is. Scaling is not about the performance of the VM, it's about fundamental architecture. Rails uses the REST architecture, the same architecture used by the Internet itself. It provides strong mechanisms for both server-side and client-side caching. It's the only framework I know of to implement all of the server-side recommendations in YSlow. Rails is, in fact, a high-performance framework. If someone says Rails can't scale, ask them what exactly they mean."

So, let me ask you...

If you say Ruby on Rails can't scale, what DO you mean?

Sometimes the DOM IS better.

2009-09-15T07:24:00.000-07:00

I've been working with jQuery a lot lately, and, for the most part, it has never given me any issues.

I have noticed lately, though, that when it comes to using any append/remove/find function in the jQuery library, if it is on items that have a lot of data, jQuery has serious performance issues.

The example I ran into today was, I have a drop down that has a lot of users in it. It's somewhere around 4,000 options.

I normally find the selected option's text using

This takes about 2 seconds or so for jQuery to do. I believe it's because jQuery's find method isn't optimized for large traversal like that.

I wound up making a quick jQuery extension lgtext(), which is simply:

This worked A LOT faster than jQuery. In fact, it was pretty much an instant return.

The jQuery appendTo method only has a few milliseconds in lag time, so I left it in. It's enough to notice a slight pause, but not enough for it to really affect production.

jQuery's .remove() is also very slow on this select field, taking about 2 seconds to complete as well.

To combat this, I created my own extension, lgremove():

This works perfectly, and is also an instant completion.

These are the only issues I've ever had with jQuery, so that should say something about the library.

It is pretty solid.

Just to clarify, the 2 seconds of lag time was in Chrome. I was too scared to see how many times longer it would be in IE...

For you jQuery veterans out there, is there a better way for me to approach this using the built in jQuery methods?

Let's keep it DRY, folks.

2009-09-14T19:05:00.000-07:00

If there's one thing I've come to love more than anything else in programming, it's the concept of DRY (Don't Repeat Yourself).

Seems like common sense, doesn't it? I mean...really -- DUH!

As common sense as it may seem, there are a lot of people out there who do repeat themselves. In fact, I used to be one of them! I have been spending a little extra time lately sitting down and seeing what I can functionalize because what may initially seem like added work from the tried and true copy-paste method, can actually save you a ton of time not only in later stages of development, but also in instances where you need to debug and make additions to your applications.

Let's look at the run down on DRY coding in JavaScript and why it's useful.

As any programmer with even a little bit of experience can tell you, requirements for projects are normally constantly changing. It's because of this constant change that the DRY style of programming really shines. As the criteria change, if you weren't using DRY methods of coding, you would have to make changes in multiple locations. Keeping it DRY allows you to make a single change and be done with the modification.

Let's face it-- everybody hates debugging.

Imagine you're debugging an application that's a few thousand lines in code. You spend an hour or so on it and finally find the issue that's been causing it all. You tried to call the getElementById method of documnet, which is undefined.

Too bad you copied/pasted this functionality into about ten different places...

Now imagine that you utilized a functionalized method in those ten places. You find the error sooner because you're digging through less lines of code, and when you find it, you only correct it in one place and then you're done! The same goes for making changes to that functionality. You make the addition in one place and you're done!

A really good way to implement DRY programming is by creating or using pre-built JavaScript libraries.

Using a JavaScript library, you utilize reusable, functionalized code that can really decrease dev time, increase performance and make your code look a lot cleaner.

There are some really good libraries out there.

Some ones you may want to look into are (in no particular order):

I use jQuery. It was the first library I stumbled upon and it's suited my needs perfectly. Each library has its strengths and its weaknesses, so be sure to check them all out before deciding which one to use.

John Resig also wrote a very good blog about Building A JavaScript Library

The concept of DRY can easily be adapted to any programming language. The reason I chose to talk about it in JavaScript is because that is the language I am most familiar with, but the logic is sound in any language that can utilize functionalized code.

Do you have any good examples of DRY programming? All languages welcome!

Books I've read and approve Part 1

2009-09-14T17:26:00.000-07:00

Over the past few months, I have been completely enveloped in a new (to me) set of JavaScript conventions/ideas, and it's changed the way I program completely.

I went from messy global variables left and right, unorganized functions, repeating myself a TON, to neater, cleaner, easier-to-read code that relies on JavaScript libraries/namespace-like functionality.

Two books that I have read helped me make this leap, and make it a TON easier, too.

In no particular order:

Pro JavaScrip Techniques by John Resig
This book was awesome. It had a ton of information, and it taught me a lot. I like the way Resig writes. He doesn't really do a bunch of convoluted examples; he's pretty straight forward. X can be accomplished Y way, but it's more efficient to do it like Z and here's why. There were some typos here and there, but all-in-all, the book is sound. It also comes complete with a boatload of awesome Appendixes, one completely dedicated to Events! Hell yes! I would definitely recommend this to anyone, in fact, if you want to borrow it from me, hit me up!

JavaScript: The Good Parts by Douglas Crockford
For those of you who don't know Crockford, you need to watch some of his videos; the man is hilarious. I find him kind of cynical, but I love it. He's not afraid to tell it like it is, whether or not you like it. This book was pretty small, but don't let it's size fool you -- it had a lot of really awesome information. He may seem rough around the edges, but deep down, Crockford is a man after my own heart. He recognizes the elegance and power of JavaScript and really brings its beauty to light.

I am all about reading awesome books about programming, so if you have any, feel free to post them here. I am always looking for a good read.

I think it's safe to say, JavaScript has pretty much taken over.

I recently bought Agile Web Development with Rails by Sam Ruby, Dave Thomas, David Heinemeier Hansson, and I've just started it.

I am extremely interested in how programmer-friendly RoR is.

I would love to hear some opinions from RoR veterans.

I know there are rumors about how it doesn't scale well, so I'd love to hear solid conversation on that aspect as well!

Well, until next time -- have a good one!

References in JavaScript

2009-09-14T16:51:00.000-07:00

So, I've been getting more refined in my usage of JavaScript, and I've stumbled across a functionality that I knew existed, but didn't know that it existed to the extent that it does, and it's really made me kind of happy.

Since JavaScript is standard at my job, I get to use its glory in every application I create! Woot!

As many people know, one of JavaScripts flaws is that it's a language that is based on global variables.

Douglas Crockford says this is evil, and I have to agree. It gives a lot of room for libraries and plug-ins to collide with each other and make an awful mess.

In the current portion of the project that I'm working on, I am setting up an administration page to allow people with a certain level of access the ability to completely edit call records in anyway they see fit.

I use jQuery's datepicker (with a modified theme created by theme roller) for the calendar (you should check it out here), allow the user to submit a date range and an employee to pull back call records for and then list the call records out in a nice list for them to select which one they want/need to edit.

They then select the individual call, which is listed by Submit Date and Customer ID. That brings them to the view/edit page.

I pull back all the call's information via AJAX to an ASP validation page. My ASP page formats the data in a JSON format, and using Douglas Crockford's json_parse function, I am able to parse the XML into an easy-to-use JavaScript complient JSON object.

Neat.

My initial thought was to create a global variable to house the call record that was currently being edited...icky...and then it hit me. Maybe I can pass the internal object to all of my functions that edit/update, and maybe--just maybe, it will update the object, keeping all the references current, which would allow me to skate by with no additional global variables!

So, I tested it...and it worked!

I ran editStuff and then updateRecord and the new value stuck!

Just another reason why I love JavaScript.

Some reasons why I love programming (long intro)

2009-09-14T11:50:00.000-07:00

Let me preface this with the story of how I got started into programming.

So, I started dabbling in programming probably about 6 years ago. My friend, Zach, told me about it, and it peaked my interest. I thought it sounded fun. I was a little intimidated by the strict-typed object-oriented C#, so I decided I wanted to start with a scripting language that had "flexibility", so I started programming in Perl, haha.

I loved the idea that it was super flexible, and that I could say "Do it", and Perl would usually always comply.

I didn't use Perl too much. I made a few hello world applications, and my biggest project was a D&D character roller, haha. I eventually dropped Perl and took a break from programming. The language just wasn't for me, but it started something that would eventually change my life.

About 3 years later, I decided I wanted to look into programming again. I wanted a more structured language, so that I could eventually make the move to C#. Zach's friend Brad told me that I should check out Python. He said it was made to be read easily, was object-oriented, and was block structured, so it would be relatively easy to pick up on. I started messing with it, and loved it. It was really cool. I did a few hello world apps and then started messing with the TCL/TK widgets to create console-like applications. It was pretty fun.

About that time, I got a job working for my current company ( Clearwire ). I started as basic tech support. When I came on board, the company was a pretty small start-up company, and didn't have a lot of tools in place. I noticed that the process to notate a customer's account was very time consuming and not user-friendly, so I decided to make an application to help me do that. I wrote a very simple application in Python, using TCL/TK widgets to be my GUI. I didn't want to violate IT policy by installing Python on the machine, so at home, I used an application to compile Python into an executable and brought the executable to work with me the next day.

I began to notice that the application actually decreased my call handle time, which was awesome. A co-worker noticed the application and told upper management that they should check it out. Upper management looked at it, and thought it was cool. They even had plans to talk to IT to make the executable a standard in all the images for tech support partners.

Around this time, there was only one programmer for all of care. I'll call him John because I'm not sure he wants his name posted all over the internet ;P. So, John was tasked with finding someone else to help him do the programming for care because his work load was too intensive for him to handle by himself. The company was a start-up, so the demand on new tools was extremely high.

John interviewed me and two other candidates. During my interview, he asked me if I had any web application programming experience, to which I replied, "Well, I've messed around with basic HTML and CSS on my MySpace page, but other than that, no. I've only barely dabbled in Perl and Python." I walked out of that interview having completely bombed because I did not have the experience for what he needed.

Later on during the day, I approached John and told him that I knew I had bombed the interview, but rather than to go on just that, he should give me a chance to prove myself. See, I have a pretty high learning curve -- I pick up on things pretty quick, and I am able to think my way through programming logic, which is the part of programming that is the hardest, in my opinion.

He agreed, and he said "You know that application you created to help you document the calls you take? I want you to make that into a working web application by the end of the day." He sent me some example code to get me started. The basics on how to connect to a DB in ASP Classic, and a JS example on AJAX, and told me to do the rest. He didn't care if it was super pretty; he just wanted it to work.

I worked as hard as I could, Googling my butt off. Testing, debugging, testing, debugging, until I finally had a working application. I even managed to have the application talk to our documentation application and have it successfully post notes to the customer's account!

It had errors here and there, it was not efficient at all, and had a ton of overhead, but he saw the potential that I had-- I had learned enough ASP Classic, JavaScript, and SQL to make a semi-working application in less than 8 hours.

I wound up getting moved over into the programming position, and have been doing web application development for care for about 2 and a half years now.

Well, now that you know how I got started doing what I do, let me tell you why I love programming.

I love programming for many reasons, that would probably take me forever to type out. This is time I just don't have, so I'll try to limit it as best I can. (These are in no particular order)

1. I love programming because it's a fast-paced environment.
It really keeps me on my toes. As the company's needs change, so do the application's needs. I'm never bored and always busy. It's really fun.

2. There is a lot of awesome documentation.
There are some languages that aren't documented well, but for the most part, there is a lot of really cool and thorough documentation on languages. I'm almost always learning to be more efficient or use better conventions/practices. There's almost always someone out there who has done something I've done but better, and the best part is, they share it with the world! I have a chance to learn from them and implement some of their practices in my code, which makes MY applications run better and MY users happier!

3. The ability to express yourself in your applications.
This might be a little difficult for someone who's not a programmer to understand, but there is a level of elegance that comes with some programming. There's a freedom of expression. Everyone has their own particular style of coding, and it's very interesting to go through and examine different examples that they offer.

I know the intro was long, and the reasons short, and believe me, there are way more reasons why programming is fantastic, but those are just a few of the reasons I love programming. I'm not the best programmer by any means. I'm still young in the community and learning more and more every day, but maybe one day I'll be the guy that people use as examples. One can only hope! "Our rock stars are different from your rock stars" indeed!

I'll open this up to the floor, as well-- what are some reasons you love programming?

Hello World!

2009-08-31T09:32:00.000-07:00

I will be using this blog to post various thoughts on programming related items, any projects I happen to be working on, as well as any code snippets I come up with that I think you may benefit from.