Modifying CSS in the LightWord theme for WordPress
The theme that I am currently using on my website, LightWord, is generally very nice and I love it. However, there are a few issues with it, luckily, LightWord offers a nice way to correct some of the formatting issues without actually having to update the theme itself through the LightWord Settings page.
To access the LightWord Settings page, go to the Appearance -> LightWord Settings choice on the left side menu in the WordPress admin dashboard.
In this page, scroll down to the Custom CSS settings text box. At this text box you can enter any additional CSS and it will be inserted into every page on your blog. I've used this to fix a few issues that I have with LightWord. First, I wanted my blog title to appear in a different color. I changed this, with the following bit of CSS:
h1#logo,h1#logo a{color:#FF6600;}
Secondly, I wanted a different background; which was solved with this snippet:
body {background:url('wp-content/themes/k3290370.jpg') repeat;}
Lastly, the drop down menu background was too small for some of the titles it was displaying so it would cause them to overflow. I did a quick change that expanded the size of the menu drop down background, like this:
#front_menu ul {width:300px;}
Of course, you can override all the CSS you want within this text box, so if you wanted to change the color of links or whatever, you can do it right here without modifying the actual LightWord theme. In addition to the Custom CSS, the settings page also allows you to add in additional scripts, headers, and footers.
Your workspace could be hazardous to your health
If you're like me, you spend a lot more time than you should sitting in a chair in front of a desk typing on a computer keyboard looking at a computer screen programming, writing technical specification documents, leading demos, doing email, or just surfing the web. The one thing you're not thinking about is your workspace, and I have news for you -- you should be thinking about it. Chances are, you're slouching in your chair right now, surrounded by a lot of paper, books, speakers, or you're sitting with a laptop on your lap reading. I've got news for you, it isn't good for you. There are few things you can do to help clean up your workspace and be more productive and in better health for it.
The first item I'd worry about is a nice chair. You spend so much time in, why skimp on something that is going to last you at least 10 years if not more? For the longest time I'd been sitting in a chair that I'd had since high school and it wasn't very comfortable. It was downright annoying to sit in, then I read this article from Coding Horror and realized I agree with his three main points:
- Chairs are a primary part of the programming experience
- Cheap chairs suck
- Chairs last
As an additional point of reference, I finally gave up on my old chair and purchased a HumanScale Freedom Headrest chair after sitting in many other chairs to see what felt the best to me. For me, the Freedom chair works perfectly because it allows me to recline while working, yet keeps my spine, arms and neck in alignment though its ingenious "second spine" down the back of the chair. It also has very few adjustments which I really like. I want to sit in a chair and be comfortable in a few minutes, not spend a week to a week and a half tweaking every setting.
When sitting in a chair you should have your knees, hips and thighs all in the same plane while your feed are flat on the floor. If you want armrests (I advise you to get them), they should position your elbows close to your waist when used. Finally, the seat of the chair should be slightly wider than your hips and thighs and slope downward in front leaving a 2 to 3 finger gap between the seat and the back of your knees when sitting correctly. Remember, however, a chair is a personal choice and I would suggest you sit in as many chairs as possible since what is good for one person might not be the best for another. It's your rear end in the chair for the next 10+ years 
so make it count. Again, go out there, sit on a lot of chairs then make your choice.
Now that you've attained chair nirvana, it is time to get that proper seating position. An improper seating position can lead to a whole host of problems: numbness in the fingers, lower pack pain, sore wrists, eyestrain (leading to headaches, blurry vision and a mess of other nastiness), and general fatigue in the arms, legs, shoulders and thighs. Hopefully you're sufficiently scared enough to work on making changes to your seating position.
The proper seating position consists of a few settings: chair, table or workspace, monitor and posture. The proper seating position for the chair, which was discussed in about a sentence previously, is that your feet should be flat on the ground, knees, thighs and hips horizontal to the ground and your back straight. The workspace should have your keyboard a centered on your body and a few inches above your thighs such that the angle at your elbows is "open" or around 90 degrees so you get circulation to your fingers, your upper arms should be perpendicular to the floor and your wrists nearly straight. The monitor should be placed about an arms-length away from you and the top of the monitor should be at eye-level and out of any light that will cause reflection or glare on the screen. Finally, a few pointers on posture in addition to everything else. Your ears, shoulders and hips should be in line. Your arms should hang relaxed from your shoulders and your wrists and hands should be in line with your lower arms.
A clean, quiet, and efficient workspace. I've found (as have many other people) the clearer and quieter your workspace is, the easier it is to concentrate and do work. I'm not saying there should be nothing on your desk except the bare essentials (I'm not that Zen), a knick knack here or there won't hurt any -- just don't go overboard. There are numerous examples of how to clean up your workspace, so I won't bore you with my ideas of cleaning up the workspace.
Debugging JavaScript in a browser
Debugging is one of the most time consuming tasks one can do while programming in my opinion. Debugging JavaScript that runs within a browser is the most time consuming and annoying tasks one has to do, period. Which is why I'm all for finding better ways to debug JavaScript within a browser. Here I'll talk about some of the tips and tricks that I use to make debugging JavaScript within a browser a little less tedious and annoying (I'm not going to say fun, since debugging is rarely fun:)).
The first technique I employ is using alert statements. The alert statement pops up the dialog box with a message, that you as the programmer have inserted into the code. I use these to pinpoint where in the JavaScript code the script is failing so I can quickly get to the problem segment or method within the code. This makes a great first pass since you don't need any specialized tools or add-ons to your browser for this to work. The problem is, you're always rerunning your code in order to see where it fails once you make a change or in order to further pinpoint the problem section.
The second method I use is the Web Developer tool bar add-on for FireFox and Google Chrome. The Web Developer tool bar lets you inspect each element in the HTML and see all of its properties. This is extremely handy when scripts are changing properties of HTML elements; using it you can see if an element has changed it's properties or not or if the property you've added has actually been added. The only downside to the Web Developer toolbar is that it doesn't seem to work in real time. If you've made it display form details then run a JavaScript script that modifies the form details programmatically, the updates won't be shown until you hide then redisplay the form details.
The third option, and the one I've grown most fond of recently, is using Safari and WebKit add-on. I've found this to be the nicest real-time debugger for JavaScript. With a simple selection of Develop->Start Debugging JavaScript from the menu button, a fully functional debugger is added to the bottom of the window and it allows you to set breakpoints, see the call stack and inspect all the elements being used within the JavaScript code being run. This has been the most helpful when I've located the method in which a problem is occurring, but can't figure out why exactly it is happening. All it takes is setting a breakpoint, running the code to the breakpoint, then stepping through the code line-by-line and watching all the scope variables to see if one does not have the value I think it should. More often than not, I find out a variable is null or undefined when I thought it should have had a value.
The fourth option, I've used when debugging AJAX methods within my code. Using a tool called Fiddler, a web debugging proxy, I can intercept all messages being passed between the server and the browser and see exactly what is being passed in the AJAX commands. I've found Fiddler to be the most helpful when used in conjunction with another tool, like WebKit's JavaScript debugger.
These four options do a very good job of helping me determine where errors are within the code and fixing them. When it comes to speeding up JavaScript, a JavaScript Profiler is what is needed. Safari with WebKit has a nice one that can be started with the Develop->Start Profiling JavaScript menu choice and FireFox has a nice one with the YSlow plugin. In the case of profilers, I find YSlow to be a bit nicer since it will profile the page and return hints on how to speed up the loading of the page. However, that doesn't mean that Safari's JavaScript profiler is worthless -- I've used it an awful lot too. It does a very good job as well. Lastly, Fiddler has a very good profiler for determining the time it takes for various elements within the HTML to be transferred from server to client.
Hopefully these four options I've shown will give you a better idea of tools that can be used to debug and profile JavaScript in order to have bug-free code with a swiftly loading web page. If there are any other tools that I've missed, or debugging methods that you've found helpful, let me know in the comments section and I'll update this page accordingly.
Thoughts on teaching programming
Do programming courses in college really get you ready to code in the real world? Unless you're a pie-in-the-sky optimist the answer is definitely "No." How does one teach a programming course in order to have one ready to work in the real world? I think there is a very simple way on how this should be done, but let's look at what someone coming into the industry should know how to do:
- Code competently
- Dissect the problem and map it to the programming language (classes, etc.)
- Generate readable code
- Understand testing, debugging and multiple debugging methods
- Code deployment
- Understand refactoring and code clean up
- Converse competently with other developers
- Algorithms
- Programming lingo
- Design patterns
- Work in a team
- As a leader
- As a follower
- Use a version control system
- CVS, SVN or some other source code control at least in the context of an IDE
- Be able to learn another language and transfer knowledge of algorithms, etc. to the new language
These five goals are the foundation for a competent coder and someone who can "talk shop" with any other developer in any other group, department or company. Unfortunately, as a fresh out of college coder, you're not going to have experience in any of these and you should. Jobs change, technologies change, but certain things always remain constant: clean code is better than messy code, algorithms, teamwork, and version control. The fifth point I put up there is the holy grail, so to speak of learning; where you can make the jump of what you know in one language and apply it to another language.
Lets look at each of these points and see how they should be integrated into a programming curriculum. Competent coding and its five main points should be taught at a beginning level class. As the student is introduced to the syntax of the language incorporate readability as part of the assignments. Formatting, comments, appropriate use of methods, function, variables, etc. should all be considered. When a program is returned the student must refactor their code to fix all of the problems found with it. If the program doesn't work, use it as a time to teach them how apply various debugging techniques. Dissecting the problem into classes, methods and various other sub-problems won't initially be an issue since a beginning level class has to start at the bottom of complexity and go up, but beginning to introduce the ideas and thought process in examining problems should be introduced as well.
Conversing with other developers; as with everything new, they'll have no idea of the lingo of programming. The beginning level class should focus on teaching them on discussing their problems with other students in order for them to become acclimated with discussing problems. In later classes algorithms can be introduced and at the top level: design patterns.
Working in a team should also be stressed. However, it doesn't make sense in a beginning level class to have people working in teams. Teams need to be done in a class with more difficult problems where it will take all people on the team to complete the problem. In an entry level class: they'd work as teammates; but, as the classes move to the intermediate and advanced the roles should become more defined such as: one architect and three developers or one lead developer and three junior developers and allow enough projects to have the team of three get a feel for each position.
Version control system, the fourth point, I believe should be harped on from day one in every class. It might take a little bit of time for the students to get the version control system working (I'm not suggesting they set one up, just they use one defined for the class or one that is tied to their account through out their time at college). Forcing them to understand how important a version control system is in real life is needed. As the classes being taught become more complex, the usage of the version control system can be increased as well. Begin with the simple things: checking files in and checking files out; then move to the more complex items: versioning and branching; and finally, the more complex operations like merging, back-porting, etc.
The final item: knowledge transfer. The very last class taken by the students should be in a language completely different than what they've used before. Such as, you've been using Java, use C++. The assignments should be of the same difficultly level of the last Java class such that they must adapt to using the new language in a short amount of time. Of course, they'll have to learn the nuances of thew new language, but part of the knowledge transfer is also learning about the new language.
Of course, none of these changes will make the students completely ready for the work environment, but it will give them enough experience to know what to expect as to coming into the job market with no clue at all. I know I've left things out like software methodologies and speaking to management, but I feel those would be best put in other courses and not in the core programming courses. Perhaps a 4th course called Software Methodologies where it will cover the various programming styles and touch on topics such as speaking with management and other people not directly involved in programming.
Am I off my rocker thinking that this is what people should be learning in college programming courses? Is there something I missed that you think should be added? Let me know in the comments below. I look forward to eventually making a part 2 where I can destroy everything I've written here and have a new improved vision of teaching programming in the future .
Programming Classes in Javascript
After mucking around in all sorts of Javascript problems, I've come to the realization that not many people know how to write Object-oriented code in Javascript. Initially I had written out a fairly simple Math class in Javascript that people could see how to do all of it. Then I saw this article on Mozilla's web site, which pretty much made my attempt worthless. So, even though it is a few years old, it is definitely worth the time to read the article.
Mac OS X 10.6 and all the wonderful peripherals
After receiving my new desktop machine, I've been working on getting all of my peripherals working on the new machine. Of course, with it being a Mac, you should just be able to plug all the stuff in and rock and roll, right? Well, the answer is "Wrong" when you're using an HP Deskjet 995c with Mac OS X 10.6 because HP no longer supports any piece of hardware over 5 years old and politely tells you to buy a new printer.
The largest issue with looking for a new printer is the fact all printers are now apparently these all-in-one monstrosities that do everything except the dishes in the dishwasher. Whatever happened to a nice quality printer with bluetooth or wireless capabilities? Am I asking too much of the printer companies to make a quality inkjet or laser printer with bluetooth or wireless and none of the other frivolities they normally throw on the printers now?
Along with what appears to be my search for a new wireless printer, I have an Iomega network storage device that likes to be seen on the network, but not actually usable. Of course, this just isn't a Mac issue, it isn't working with the PCs as well. Just another thing to troubleshoot. At least all the other devices work just fine with the iMac so I can't complain too much.