Sunday, April 24, 2011

Escaping Reality (Critique)

I was reading this morning when I came across an interesting article on Science Daily

Clumsy Avatars: Perfection vs. Mortality in Game Simulation

It's an interesting concept--The idea that users create these avatars to represent perfection and physical characteristics that never change. I myself play a few online games, such as Lord of the Rings Online from time to time. From the moment I log in, I'm immersed in a different world that requires my full attention: Interactions with other player, quests, battles, and tasks that need doing. I even cease to exist as myself altogether by referring to myself as my character's name. My character is tailored to my specifications--from the armor to cosmetics, the avatar embodies my ideals.

The problem (in my opinion) arises when people can't separate themselves from their online aliases because, as the article states, "frailty and mortality" is what makes us human. The roles of reality and virtual fun have been swapped. Recent trends show that more and more people go to work in order to spend their money on virtual lives, lavishing their avatars with the latest in-game merchandise.

What Chang, one of the contributors, suggested was that video games incorporate human qualities that develop over the character's "lifetime". Again, This makes me wonder why anyone would delve into an online world if they change the same as reality.

It's a fascinating article and I would love to read your input on the matter. Please post your comments below!

Wednesday, April 20, 2011

Study Habits of a Programmer

As a programmer, I tend to connect seemingly unrelated topics with the world of computer languages. Allow me to explain:

 The world runs on logic, so if I am required to think in logical and abstract terms for my Computer Science track in college, why not apply what I'm good at to the rest of my life? For example, In order to remember the complex process of Meiosis for my Biology I class, I decided to organize my thoughts into a combination of flow control loops and conditional statements (for, if/then, while, etc.) This process may seem absurd, but why not!?

Life has rhyme and rhythm to it—there is always some sort of explanation or process to the way things play out. Is this really any different from the programming terms that I typically tend to think in (mostly Java-based)? The answer is no, they are not different. Programming requires a process to be laid out step by step in painfully detailed fashion. Computers know absolutely nothing but 1's and 0's, so the steps must be laid out for the task to be executed properly.

The only difference between the user/computer and life/human relationship is that life continues to function in is processes regardless of human understanding. We in turn, have become the dumb machines forced to read and decipher the code that life has issued to us. Thinking in code is almost natural for me, since I am faced with it many hours out of each day. It would be a waste for you to repress what you’re good at when it can help you in almost any situation. The ability to think in a logical and orderly way is never a wasted talent.

Monday, April 18, 2011

Java GUI Builders: To Use or Not To Use

Picture a kid riding a bicycle on the highway in first gear... He has to make it 40 miles and he's traveling at about 5 miles an hour. 8 hours to get to the destination--Totally inefficient, right? Why not just shift into a higher gear so you can travel at 18 miles an hour, reaching your destination in a little more than two hours? Unlike VB.NET or Visual C++, there is no acceptable visual editor for Java!

I'm here to explain why you should avoid it at ALL COST!

Reason #1: It's not all

The Netbeans (A popular IDE) does the best that it can to create a GUI to your liking with it's drag-and-drop approach, but it takes 3X the amount of code to accomplish this feat. 3X the code is usually accompanied by 3X the inefficiency. For a programmer (at least for me), It's kind of like a punch below the belt when you realize you could have made your program 3X more efficient if you would have taken a different approach. This is something that no programmer likes to hear (and definitely shouldn't tolerate).

Reason #2: It's a MONSTER to maintain

Going off of Reason #1, since there is 3X the code, there is 4X the unnecessary clutter. Not only that, but because of the way in which Netbeans organizes the code, it is impossible for a mere mortal to comprehend what is going on. For those of you who have posted erroneous code, this isn't good news for you. The more experienced coders won't even bother sifting through the jungle of disaster to find the errors you are experiencing, simply it's because it is a BEAST to understand and keep organized in your thoughts. It's not that GUI Builders are reserved solely for the genius's use, but that it is unwise to use such a product in the first place. There is absolutely no rhythm to the code that Netbeans produces.

Reason #3: It's downright lazy

No offense to those of you who use it because you were never told otherwise--I'm telling you now. It's a fact that GUI Builders encourage lazy coding habits. It seems very simple on the surface of things--drag the different components into place AND... presto, a working application( if only it were so simple). But you are left with the problems described in Reason #1 and #2. It's better off to study the GUI classes and components then piece together an efficient, manageable version of your program in which you understand every single detail contained within it. This is the pinnacle attribute of a good programmer. Not only will you understand your own code, but if you have small problems, other experienced coders will understand how your program should work at a brief glance.

Wednesday, April 13, 2011

6 Guidelines For Programming

6 Essential Guidelines for Programming

1.) Learn your subject
2.) Make a game plan
3.) Keep you API open in the background
4.) Break the program up into manageable pieces
5.) Name your variables meaningfully
6.) Debug and thoroughly test your program for loopholes and bugs

1.) Learn your subject
How can you go half-assed into a project? You can't. If you want to make a really good application, then you must know what you are going for as a final result. Sit down and learn the ins and outs of the process you are replicating. For example, let's say you are making a mortgage calculator--Shouldn't you understand how the formula works before sitting down to slap together some code that probably won't work?

2.) Make a game plan
After you understand the subject, draw out your program's structure on a white board or paper. Not only will this give you a direction of travel, but also a reference to look back on while coding. Being able to look back on your ideas that are listed in a single location is extremely beneficial in the long run. Lots of beginning programmers tend to skip this step and don't make it in the real world where programs are thousands of lines long.

3.) Keep you API open in the background

The best reference you have at your disposal is the programming language's API. It explains how all the thousands of classes and methods provided work. These are the tools that you will need to build your program. For example, in Java, let's say I have a String. How do I know all the methods associated with the String class? You would open the API and scroll down to "String", where there is a list of every single method. You see, programming isn't about remembering every trick in the book--It's about knowing where to find the relevant information.

4.) Break the program up into manageable pieces

This is probably the most important tip! So take note! You aren't going to produce a program that works perfectly on your first attempt. The best way to attack large projects is to get one piece of the puzzle to work at a time. Take it slow and build it up--In the end, you'll have a functional program. =)

5.) Name your variables meaningfully

Since the last tip was the most important, this one cures my biggest peeve. NAME YOUR VARIABLES! Is "int x" or "int mortgageRate" more descriptive? Let's face it, if you leave your program sitting for a few months then come back to modify something, chances are that you won't know what the heck is going on unless the code explains itself.

6.) Debug and thoroughly test your program for loopholes and bugs

After you think you're done, you're probably wrong. A program requires rigorous testing in order to perfect it. What if someone enters a letter instead of a number for a calculation? How will the program handle it? It has two choices: crash or react to the bad input with some modifications that you have written. In the real world, if the program crashes and you don't care to modify it, you'll be fired!

Following these few guidelines makes programming in any language much less tedious and time consuming, making you into a more productive individual.

Monday, April 11, 2011

The Blame Game (Opinion)

In any big business, there are deadlines to meet. Tasks are piled on and heads roll when deadlines are missed. In the Computer Science field, I believe this is most prevalent. Big business has always been about doing things in the most effective and cost efficient way and with the current state of computer programs, the brunt of this optimization falls into the lap of programmers. The bottom rung of the developmental tree are the developers themselves.

What I mean by this is that the ideas flow down from the top-- These higher-ups are in charge of putting a deadline on something that they probably know very little about. Let's say they want the pen and paper system to be overhauled to implement a user-friendly database. So, they know what they want and they know when they want it by (let's say two weeks from now) but they don't consider the how that needs to be figured out in order to achieve functionality. Programming is a black box affair where the user interface makes the program simple to use but has thousands of lines of code running in the background to make it all work. There is no appreciation for the complexity of the process

Before a developer can overhaul a system, he/she must fully understand the functionality of the current system at hand and are given not so much as a flow chart outlining how it should work. If the higher-ups aren't willing to take the time to outline the system, how can the blame for missed deadlines be placed in the laps of the developers? It takes time to not only learn the current system better than anyone, but then to implement the required changes to the system and thoroughly test and retest for bugs. Instead of making an "executive decision" on how long a project should take, maybe the boss should sit down with the developers and work with them to contrive a game plan based on the programmer's opinions

Friday, April 8, 2011

About Me

My name is Dakota and I am a Junior of Computer Science at Armstrong Atlantic State University. I taught myself the basics of programming when I was 15 years old and have stuck with it ever since. It's a hobby and a passion of mine because there is no right way to program, only wrong ways. I've continued my pursuit of programming by becoming a part of the Dream In Code community under the guise of Luckless. I spend most of my free time there: answering questions, writing code snippets, you name it. I am employed by the Computer Science department as a Student Assistant to Dr. Ashraf Saad and am currently apart of the CREIP project, which I have spent the last few months modifying to make it a more robust platform. When I'm not in class, at work, or helping on the forums, you can typically find me riding my motorcycle around town or in the gym working up a good sweat =) That's about it!

If you have any questions for me, please post them and I will be more than happy to answer them. If you have a job that you would like me to program, please post your email address and I will get back to you.