New Media Development

Photo Provided by Wicho via Flickr

Well it has been a couple of months now since I have switched from using a PC Notebook to a 17″ Mac Book Pro and things are still going well. As I mentioned before I used to be a die hard Mac fanatic about 10 years ago but switched to PCs due to the lack of decent software on the Macs at the time. My recent switch back had to do with my desire to pick the right tool for the new media and technology development I currently do. As promised, here are my top of the head observations over the past two months.

• When I bought the Mac I knew I was going to be running certain PC software and games. I started to go down the path of using Parallels but found that transferring my XP license off my existing notebook would basically make it impossible for me to sell it as a low end PC. After a month I broke down and bought CrossOver instead. CrossOver is the OSX port of WINE which does not require that you have a full version of XP/Vista to run your software. You will need a Mac with an Intel chip to run the software properly. All of my PC games run flawlessly under it and most of my PC software runs as well. Unless you absolutely need XP on your machine for some obscure reason like your network doesn’t play well with Macs, I would opt for CrossOver first for any windows software emulation.
• I am just amazed by how much free software is out there to help make a transition between PC and Mac easy. I did break down and buy some tools I use all the time like the Adobe Suites. However, things like NeoOffice, FireFox, AppFresh, QuickSilver, and TweetDeck have become invaluable tools. Even the free Apple software like Safari, Mail, and GarageBand have revolutionized how I use the notebook.
• One thing I forgot about Macs and missed was that things just work. I plug a microphone in, it recognizes it and records from it. I plug a camera in, it finds it and lets me control it from the software. I want to record a video, iSight comes on with the mic and just records without a loss. On the PC side you can make things work but it takes time and is never 100%.
• My co-workers often complained about how they HAD to be PC based for all of the development they do. After a bit of searching I found that the Mac could do all of the things my PC could do for development and more. It was just a matter of taking the time to seek out a solution for a specific problem. For example, I thought I would be totally at a loss for remote desktop connections to PCs until I found that Microsoft wrote a RDC client for OSX. It’s not widely publicized but if you look for it, you can find it. Major problem solved.
• Web development is like night and day. On the PC I got into the habit of developing code and pushing it to a testing server. On the Mac, everything was not only included but pre-installed. Apache, PHP, Virtual Hosting. All on my box and ready to roll. The only thing I needed to add was MySQL and that was very easy. Granted I will need to break some old development habits but given the fact I can now test and code anywhere without having to be dependant on a connection is just amazing.
• Slowly over this time I have noticed something very significant for me. I haven’t turned on my notebook in the past 2 months at all except to transfer a file or two. I am significantly using my desktop PC less and less. The Mac has actually help me do things like rebuild my 9000 song music collection, clean out software I don’t use, and make it easier for me to backup my work and life.

Do I regret the purchase? Absolutely not! Apple has come a long way to address software, hardware, and just confidence concerns. Under Steve Jobs this company has finally moved forward enough to really be the company they always should have been. I understand why so many people are converting now. This is one seriously sexy and powerful piece of kit. Apple also puts so much information online and makes it so easy to just find things like software and solutions that I can’t imagine going back to the “pay for everything” world of PCs. And it looks like things are only going to get better with the Apple announcements tomorrow.

I do need to break some old habits like calling it a Mac when I am talking about OSX. I also know I am grossly underusing the machine’s true power. But that will come with more time. I am just incredibly happy with this rather expensive purchase and can see getting a lot of use out of this machine for a very long time.

Related articles by Zemanta

• ‘Cool factor’ swells Macworld ranks
• A new day for Macs in the enterprise?
• Apple slates laptop event for next Tuesday

One thing I try to do from time to time is clean up old content on my sites. Because of this, I find gems of knowledge I forgot I had and should share with the wider programming communities. This is just such a case.

A while back I was tasked with writing a program that took content out of a database and reformat it as a PDF document with a specific layout. I found this nice CPAN module for perl called PDF::API2 which allows you to write PDFs on the fly. After some database giggery pokery I had a program in place that created the 500 PDF files in about 2 min.

After I wrote the program I wanted to address the complete lack of documentation for the module. I ended up writing an article that never got linked anywhere. I am correcting that issue now and hopefully this will help someone else with a similar problem.

I have been mulling this question over in my head the last couple of days because of a very annoying conversation with a colleague. Their opinion is that if you work in languages like PERL or PHP you are a ’scripter’ and not a true ‘programmer’. They feel that scripting is more hack and slash programming to solve an issue and not true development. I am obviously in the other camp for many reasons.

First, I have never been the type of developer who lets a language define my application development. I have moved from C, to PERL, to PHP, to Java, to ASP, to C# .Net with relative ease but varying results. You see, I don’t really care what the language or the structure of a programming language is to complete a task. What I am more concerned with is the results and the speed at which I reach them.

Most self proclaimed programmers I have run into tout the structure and organization of their programs as far superior to anything a scripter could create. However, these same people refuse to document their code in a way that makes it understandable. They trust that their programming skills will speak for themselves and code documentation just won’t be needed. In the real world, however, it always helps to have a map to see what is going on. Documentation is that map that ‘programmers’ skip. Scripters can fall into this same trap but since most linear programming is done this way at least it is somewhat easier to follow.

Second, programmers are under the belief that only complex code can solve complex tasks. This is not true. Efficiently written code can solve any task. If code is overtly complex for the sake of complexity or standardized structure, you are either trying to dupe someone into thinking you work harder than you do or you are so embedded in the belief of absolute adherence to code structure is needed that you are missing the point of effcient programming. When a Zen Archer shoots an arrow, they only expend as much energy as is needed to accomplish the task. No more, no less. If the arrow is traveling 100 yards or 1 inch, it does not matter. The energy is the same. Programmers and Scripters need to adopt this philosophy. Code should be written to do what it’s intended task is. If it is written otherwise, it either lacks power to sustain itself or has unneeded levels of code or structure.

Finally, look at the major web sites out there and you will find a curious thing. Google: running on Linux with open source custom code written mostly in Java. Amazon: running on Linux using SOAP interfaces to their back end. Digg: running on Linux with a completely PHP back end. CNet: Linux servers with PHP and MySQL back ends. Yahoo: Linux based systems using a mixture of Java, Javascript, PHP, AJAX, and MySQL to drive their network of sites.

Now I ask you this, if you couldn’t write complex solutions with a “scripting” language like PHP, why would so many dynamic and technology driven sites be using it? Could it be that “programmers” need to stop worrying about their programming and should focus on their solutions no matter what language they use?

Everything in life has a cycle. You are born, you live, then you die. It is the only true truth we know that everything will one day end. So why wouldn’t the same be true of software? The idea is formed, plans are made to create it, programming begins, testing commences, and finally it is launched. Then, for most programs, it is left to it’s own devices. Over the life span of piece of code 90% of the energy involved is used for planning, development and launch. 9% is devoted to ongoing maintenance. 1% or less is spent on sunsetting.

Why is one of the most important parts of code life-cycle given so little attention? Usually this is because most programmers can get excited about starting something new and do not get excited about letting something go. The other reason is many developers associate sunsetting with tedious tasks like documentation. However, planning for the full life cycle of a piece of code can actually make the code function better and more stably over the use of the code.

Sunsetting can actually refer to two things. First, a scheduled checking of components or content in a system for pruning. This type of review should be standard after the launch of any piece of large code. Content placed into a system will eventually get old and be inapplicable. By looking at it now and setting a date to remove it from a system you are doing two things. One, you are creating an area where content is viable and fresh. Two, you are not bogging down your system with extra information people may not access. This pruning is like when you prune a plant. Keeping the important parts will make it more useful and prevent it from slowing down.

This also applies to objects in system. You may program a system to support online banking as an example. But after 4 months you find that no one uses the online banking components and you intend to turn them off. Instead of just masking them in system, consider removing them. This will reduce confusion by developers down the road as to which part of the system and active and which are not. It will also speed the functionality of the overall code set by removing needless tasks.

Second, the retirement of a piece of code for the replacement of a new piece of code is the other way the term ’sunsetting’ is used. Programs have a life span. Usually this is due to advances in code, hardware, software, or business lessons learned along the way while using this code. Every year you should make a short evaluation of the code to see if it still lives up to expectations and can deliver properly. If not, start to consider retiring the code and replacing it with something else. Retiring the code is a good thing because you want to bring current quality to your users and not keep them stuck in something that may no longer fit their needs. Your consumers change so your code should match with it. You can usually plan the sunsetting steps soon after launch to make this process easier.

In any case, do not expect your code to live forever. It has a time and a place and will eventually move on. Think of programming as art and life. What you create is an expression of your style to solve a problem. That expression will grow, live, and eventually sunset. Hopefully, it will be reborn anew to start the cycle again.

A common question I get asked is ‘Which is better, Windows or Mac?’. The programming version of this question is ‘Which is better .Net or Open Source?’. Both of these questions are just hard to answer because it really is determined by what you know and what you want to do with them.

I started out as a PERL based programmer but not by design. It just happened to be the right language for the task at hand. Programming as a task actually is rather tedious to me but something I enjoy once over the hump of getting started. As time has progressed, my jobs have transferred me into more of an ASP mindset of programming as I hang on to my PERL roots. All linear scripting languages pull on the same roots in just different ways. As they transition to Object Orientated Programing structures they start to differ greatly.

Some programmers swear by .Net for it’s rapid implementation and large set of pre-programmed classed. PHP programmers are quick to point out the huge cost of getting .Net running and the similar class and object structures in PHP5. But something is getting lost along the way.

As we all look at the holy wars of code, some programmers are forgetting the task at hand. Their blind devotion to .Net may lead them to not consider the advantages that PHP may offer. PHP zealots are quick to dismiss .Net but sometimes don’t realize the large set of objects might speed their production along.

My view on either language is that they are just that; languages. Stop looking at them as solutions. Look at the problem at hand to fit the best language solution to them. As much as I can say ‘I Love You’, ‘J’amie vous’ just sounds better and works as more of an all encompassing concept for me when I use it. It’s solves my problem of what I want to express. Apply that thought to your programming skills and you will find that new and varied ways of programming will open up to you.