Tag - programming

Entries feed

Monday, August 8 2011, 10:35 am

Yearning to Learn Computer Programming?

Controlling the flow of electricity inside your computer is a phrase that sounds better than the noun I will blab about today: programming. Sure, you could read a "How-to Program in 30 Minutes!" book or Google search another blog for a lesson or two, but if you want to understand why instead of how programs function then please pay attention.

What programming language should I learn first?

Say what again. I dare you. Wrong question to ask. Understanding concepts and having common sense are far more important than the language. Those two qualities will carry over across multiple languages unless the language itself is poor. Specifically you must understand that your code must be generic and modular. These are not new concepts, but they are easily overlooked or not mentioned any more. Modern texts teach specific language techniques that get you running a basic program quickly, but when you attempt your own program you end up with something that will not compile.

Programming: think, design, analyze

Please be prepared to spend hours on a simple problem. If the first solution you think of involves a globally accessible variable and calling it directly across three functions there is probably another solution that puts the variable in a restricted name space. Never take the easy way out until you are certain it is the only way out. If in doubt speak out! Ask questions among other programmers and see if your idea is worth the bytes used to store it.

Redesign is fine

It is rare for me to accept the code I write the first time as good code. With this in mind, you should be prepared to see the code you write in the future. Don't become too attached to it as you may find out it has serious bugs that may require you to completely rewrite the code. Plan ahead by not only leaving good comments, but clearly defining test blocks. I have seen older code blocks with tests that are not obvious until I study three other source files. It should never take longer than a few minutes to catch up on code you have not seen in a while.

Show me the money

Ready to start programming? Start with globally used, free tools. The C and Python languages have large open source communities with tools that work on Windows, Linux, and OS X. Don't forget to save any code you write into a version control system. Git is a good start. Using git alone is a good test to see if you can make it as a programmer or not.

Thursday, October 28 2010, 12:01 am

Cross-Platform Graphical Library Maddness

An application that provides the user a window with buttons and input boxes is a given in today's graphically driven computer universe. Operating systems of all shapes and sizes provide a programmer the tools and libraries to accomplish their goal of providing such an application. Most of them are pretty boring or are too specialized to be worth taking time to study. The libraries that people should familiarize themselves with are those that can be utilized across operating systems, which include being able to run across multiple types of hardware devices. Two libraries come to mind - GTK+ [has a very interesting history] and Qt (pronounced "cute").

library-maddness

Today, both libraries offer very simple methods of creating a GUI. So, depending on what language your project requires, either one would be able to provide you with a robust and full featured set of options. The current drive to use Qt is entirely commercial driven - by Nokia - who owns Qt. It's the same drive that Sun made with Java. There's no logical reason to use Java. People have just be taught that it [Java] is the best and there is no other language that can do the same job (read: subjective).

I believe the "Qt hate" or "GTK+ hate" stems from the past when Qt didn't offer as many cross-platform routines as Glib (from GTK+) did or vice versa. It has been my observation that people have not spent any time with both libraries and make rash statements about the other library out of ignorance. Most Qt developers view GTK+ as a legacy library that should be abandoned. Don't tell them that there is still active GTK+ development (GTK+ 3.0 is coming soon) driven by a large community, which includes Red Hat.

Need a simple OpenGL widget in your window? There's GtkGLExt, or Clutter for GTK. Starting with Qt 4.0 a similar API for OpenGL handling was implemented.

Need video/audio capability? GTK+ apps can use GStreamer. Qt has phonon.

Need XML or HTML handling? GTK apps can use libxml or GtkWebKit while Qt apps would need to use the Qt APIs.

Nokia is also attempting to drive Qt as a "write once, run anywhere" library. This is great in that it some-what promotes FOSS, but if you wish to use GTK+ you can write once and run anywhere, too. I have done so with a GTK+ app for my $DAYJOB that can compile under Fedora and Windows and does advanced things like TLS encrypted XML packets over a TCP connection and scanning documents (using SANE). Neither library has an advantage.

More recently, Nokia has tried to push the mantra that you can write a Qt app quickly and simply. GTK+ developers can also use Vala to write a GTK+ app quickly and simply. The amount of code to write to accomplish the same goal in each library also ends up being about the same.

I can come up with any more number of examples, but those are ones I have seen used in arguments lately. The person arguing for using Qt has no idea about the matching GTK+ API and vice versa. I think it's great that both Qt and GTK+ offer such a wide range of features that are easy-to-use. You can choose a language (C, C++, Vala, Python, PHP) and write a program that could be used by thousands or millions of people across many different types of devices. Now get out there and start programming.

Thursday, August 5 2010, 05:43 pm

Thirty Ways a Software Grows

The following recount is rather generic in nature so I do not have to worry about stepping on any toes, but it is all true.

yeah

Everyone has a workplace story to tell and I've finally gotten around to writing about my own. I have had a rare opportunity to write and maintain software for a company that has plenty of history. The company I, still, work for has been around almost as long as Microsoft to give you a point of reference.

In The Beginning In traditional fashion of the time, which still holds true today, the company started by buying the rights to a software that someone else wrote. The country of origin: Canada. I do not know much about the company or who were the original authors besides a few names I've seen in copyrights, so unfortunately I do not have any juicy stories to tell about them. They wrote to Minix, which surprisingly still exists today. The data was stored in ISAM databases (Google it), which unfortunately still exists today. The program displayed via a terminal-based text screen with support for input fields and displaying different types of screen layouts, which, also unfortunately, still exists today. The only saving grace was that it was written in the C language.

Abraham Lincoln The company originated in a log cabin, now turned historical landmark. I heard the winters were cold, and the summers were hot. The size of the cabin is about the size of a traditional living room with two whole stories. There was also the shift from Minix to UNIX and DOS operating systems to keep up with growing demand.

Enterprise Split Eventually the software became outdated, in a sense, for the customer base the company wished to sell to. Enterprises wanted a more robust and fully featured software. The solution? Rewrite! The company moved to a different city, but left behind the original software - to live in its own filth.

Dungeon Upkeep Keeping the software maintained to a point people could still use it was the job of a fellow I only met once when I was being interviewed (for an unrelated position!) so I can't tell you any juicy stories about them either. However, I can tell you the software essence remained the same. They continued to use the original UNIX compiler and coding techniques. These techniques include typedefs to normal C keywords and functions. Numerous programs that simply copy & paste code from other programs. Global pointers ruled the entire source code base from top to bottom. Return values were rarely checked. Instead of calling the standard rename or delete functions, system calls were made to the operating system's shell tools. The source control system involved cloning the main source directory per release - some of which I did not find when I took over. Take this scenario for instance: One customer was given a compiled program on Monday but changes would be made to the same program and given to a different customer on Tuesday. Every customer had a unique compiled version of the software. Let that settle in your mind for a moment.

Change of Hands A friend of mine, who has moved on to greener pastures, took over a few years ago. He began a very important and rigorous job of evolving the software into a state that a guy off the street could come in and program to. The code went from 1980s leftovers to 1990s l33tsauce. It was now source controlled in CVS and macros were removed. Some of the copied code were moved into libraries that were compiled against. A small set back to the improvements happened when another programmer was hired and began transforming perfectly good code into obfuscated and over coded code. String pointers were turned into "static const char *const variable;" nightmares. Functions were rewritten to be twice as long and contained bugs that I had to find and fix for about a year.

Modern Tools After I took over we released a major version. This version was the first version where all of the software was released in one update. It was all source controlled, and I implemented a sane update system that insured customers would all be on the same software level. Lately we've moved the code into git and I have been loving every minute of it. The software is slowly emerging from its colorful past.

Over the Rainbow GUI, SQL, Cross-platform. These three words are the embodiment of the future of the company. If I get a chance to finish the project, it should provide the company and its customers with a fresh breath of life.

Saturday, February 6 2010, 10:23 am

Developing Openly on Proprietary Land

My programming adventures continue. Nokia's experiment into Linux with Maemo is very alluring and since I've applied myself into a few Linux projects, I felt it would be worth looking into what Nokia has put together.

The Maemo SDK runs under Scratchbox, a virtual environment created in part by Nokia. The Scratchbox toolkit can run under any Linux distribution, and it requires it. If you wish to run the SDK under Windows, your only option is to use a virtual machine. Once your SDK is running, it is nearly identical to a running Maemo device. In order to use the SDK, basic knowledge of Linux goes a long way, but since Maemo is derived from Debian there are some distribution specific programs. I've been using Red Hat based distributions for years, so it took some time to get used to using dpkg and apt-get to handle packages. After a few months of using my N900, creating and handling packages takes less work under an RPM system, but it's adequate.

Since Maemo is Linux, any Linux application has a chance of life. This makes building new applications or porting existing Linux applications a walk in the park. You can literally compile any Linux program for ARM and run it, however, the necessary screen space and physical size of a N900 can make it difficult to use a large application such as Open Office, which has dozens of menus and toolbars. This is where Maemo ports come in. A finger-friendly UI can be designed and added, even sent to the upstream authors, and makes the app you port usable everyday on your device.

I started with building a brand new application. A stopwatch seemed like an easy first project. I noticed several stopwatch applications already existed, however they were written in Python or were not maintained in a long time. The Maemo Garage is a center for Maemo projects, so I created my own project page and began work. I decided to write in C, the native language of many Linux core libraries, and use GTK for the UI, a cross-platform, and the native toolkit for Maemo 5. During the programming process, I learned the Hildon additions to GTK made by Nokia, and the dbus methods to activate and listen for accelerator changes to allow my applications to turn into portrait mode when the user turns their N900. Here's the first incarnation: Stopish 0.9.0

Other programming projects are endless. I wanted to look at fixing a few usability issues. One was the RSS reader, which used a slider that was too thin for a finger. I submitted a patch to Nokia and it will be included in the next major firmware update. The second was the lack of FLAC tags in the media player. I now enjoy FLAC as my music format of choice, and it's possible to use since the Maemo media player uses gstreamer for media codecs and tracker for tags. In order to add FLAC tags, I had to extend the tracker program to be able to read them. Someone had already created such a plugin for vorbis, and so using it as a template, I made one for FLAC.

There are two Maemo repositories for projects, Maemo Devel and Maemo Extras. Finalized applications live in Maemo Extras, while developers can play with new applications in Maemo Devel Adding my projects to Maemo's repositories was a breeze. Just create a Maemo account and request upload access. I can use scp (SSH CoPy) to send my source code to the Maemo build server and it will package my projects and makes them available on the Maemo Devel repository. From this repository a developer can choose to promote it to Maemo Extras. During this promotion, other Maemo users vote on the application and if enough positive votes are made the project is automatically pushed into Maemo Extras.

Although most of Maemo is open source and source provided through gitorious, there's still a lot left closed - such as the phone, contact, and media player. Nokia's plans include more open source goodness in Maemo 6. The future of Maemo definitely looks bright even if they are forcing Qt down everyone's collective throats.

Saturday, January 17 2009, 09:43 pm

Recreational Programming

Usually the best products come about when someone is fed up with the current process of operation. Something like that happened when I was fed up using the command line interface for "uvcdynctrl," which is a tool to manipulate the settings for my Logitech QuickCam 9000 Pro. Fortunately Logitech was kind enough to provide a developer for building an open source library called "libwebcam" that would allow me to build my own interface using GTK+2. Here's the result:

Download: uvcdynctrl-gtk-0.1

I used the git source code management tool for this project so you can grab the latest source (LGPL'd) from my gitweb interface. You will need libwebcam, GTK+2, and gstreamer development libraries and headers to build it.

Please feel free to add any feedback. I also have RPM spec files for Fedora to build libwebcam and my program if you want them. Thanks should really be given to the GTK, gstreamer, and Logitech folks for making this possible.

Wednesday, August 6 2008, 02:55 am

Nokia and Python, a Tight Pair [Part 2]

Woo hoo!? I read my battery voltage. Take that $300 OBD readers. Success is brewing on the application front. I took some time today to rewrite more of the garmon "port" and got some positive feedback. All that really remains is to write the UI part that will display each sensor reading. Hm...

P.S. Don't mind the "RPM" text, I was going to do an RPM reading first, but a battery reading was much easier. >.<

UPDATE: I posted a much nicer screenshot.

Thursday, July 31 2008, 04:21 am

Nokia and Python, a Tight Pair [Part 1]

Little, neat gadgets are sometimes necessary to keep life from being a complete drag. That's where the ELM327 OBD-II device comes in. A mouthful? OK, sue me. It's a chip that can read your car's information, such as MPH, RPM, air temperature, water temperature (yes, your car uses water), and all sorts of other goodies. The chips sell for around $60 on eBay for Bluetooth versions. Normally OBD-II readers sell for hundreds of dollars and are standalone products, which are very limiting in what you could do. The catch? It's just the chip - no software. However, since the chip has open specifications there are a dozen or so different softwares that are ELM compatible. Garmon is one such software.


When I first got the device I had a dilemma. I could either drag my desktop computer out to my car and ran a long extension cord for power, bought a laptop, or borrowed a friend's laptop. I chose the third option, thinking I was looking to buy a laptop in the future. But wait! I have my Nokia N95 don't I? The only thing that kept me from thinking of my phone is that I would have to write a program in Symbian C++ - a task I wouldn't do unless I was paid a cool mil or two. So for a while I could only use my ELM reader when I was with my friends.

A few days ago my brain finally clicked into gear: Garmon is written in Python and Nokia has released Python libraries for their phones. I could certainly port Garmon to my phone. No need for a stinking laptop! After installing the libraries and running a "Hello, world!" program I knew it would be possible, with a little help with Google, seeing as this was my very first Python program (I'm a C junkie). Stay tuned for the results...