What is a Build System?

Just a quick introduction for those who are uninitiated into these rgb(0,0,0) arts.  A build system offers a relatively easy way to automate building and packaging of a software system.  While something as simple as a one-line shell script could supposedly be written for smaller projects, this has several problems.  Firstly, it would tend to redundantly and naively recompile objects that have already been built and have not been changed.  Secondly, this has no portability system; that is, it has no way to analyze the host system and find the appropriate utilities and libraries on differing platforms.  There are more reasons, of course, but these are the crux of the matter.

Current Build Systems

Make

Make is one of the oldest build systems, having its first release in 1977 at Bell Labs.  It is extremely simple, but pays the price; it has no configuration system, nor any automatic dependency analysis.  This makes it a decent choice for smallish projects with any advanced portability needs, but most likely you’re better served by a more powerful tool.  However, it should be noted that various projects such as Autoconf (see below) serve to expand this utility.

Autoconf

Autoconf and Automake together form a framework for generating Make scripts.  Autoconf provides the portability configuration system, while Automake will automatically analyze your program structure to determine the order that things need to be rebuilt in.  Unfortunately, on some level, this is merely lipstick on a pig (which is an idiom I used to be able to use without shifting my eyes), and due to the obscure language (m4) used to write Autoconf scripts, this is both a finicky and difficult option to use.  Configuration is slow, and is extremely awkward if you wish to target Microsoft Windows.  Last but not least, it is legendary for being extremely difficult to learn.  It is, however, the most common build system on the Free Desktop.

SCons

I’ll get my bias off of my chest now: SCons is my current favorite build system.  The scripts are written in Python, so you have a very powerful programming language to work within.  The API is a bit less than ideal in some ways, but is still quite usable.  Compilation is fast and portable, as well as being in one step (as opposed to the two-step compilation as used in Autoconf).  The GNOME project is currently considering switching to it from Autoconf.

Waf

Waf is a descendent of SCons, and thus shares the power of Python.  However, it is expanded in several ways: the API is retooled and is more intuitive in design in some ways; the configuration stage has been spawned into its own step; and compilation is quite pretty.  Despite all of this, it does suffer from a lot of API irregularities and absolutely intolerable documentation.  It is also important to note that Waf is unique in the build systems that I’m aware of in that the preferred way to use it is to actually ship it with the application itself instead of using a system-wide installation

CMake

CMake is the build system for KDE 4, and is a very nice and simple build system for projects of any size.  However, this clean and simple design is detracted from by the simplistic (though not to the Make extreme by any means) language used to develop for it.  If you can get past this weakness, however, very nice things lie inside, such as an integrated unit testing framework.  It is worth noting that rather than being a base build system, it instead generates files for the native build system (Microsoft Visual C++ on Windows, Makefiles or KDevelop on *NIX, etc.)

Others

This is where the real dragons are; the previous build systems I have at least some experience with, but these are build systems I have only heard of.  Despite this, I would feel remiss in my duties to you the reader if I did not at least mention some of the lesser-used options.

• Apache Ant is a build system is aimed at Java projects, and has its project files written in XML.
• Perforce Jam appears to be a C/C++ build system with a syntax reminiscent of Make, but with portability features, control structures, and automatic dependency ordering.
• QMake is a Makefile generator not unlike Autoconf, only with a much easier-to-learn syntax.  It is part of the QT toolkit.

This list is by no means complete.  If you have a favorite build system, please do mention it in the comments.

I disagree.

Open source desktop software is significantly more flexible than a closed source web application in terms of giving what users want. Desktop applications have extensibility through plugins, extensions, themes, and so forth. Web applications currently have only a weak extensibility through Greasemonkey.

Facebook Apps are closer to true extensibility, but Facebook remains in control over Facebook Apps, which results in rumors that Facebook is going to close down third party apps. Developers creating extensions of desktop applications usually do not have to worry about their extensions being wiped off the face of the Earth.

Also regarding Facebook, some users are not happy with Facebook’s transition to a new user interface. There is even a petition for the old user interface to return. I suggest you compare Facebook to Wordpress. Nobody is going to force a blogger to upgrade to the latest version of Wordpress, but there is little one can do if Facebook decides to switch to a different (and worse, in the mind of the user) UI.

Does my blog post ring a bell? Oh yeah, this blog post sounds roughly similar to Richard Stallman’s opinions on cloud computing. Stallman is dead right. One should only truly trust open source software on hardware within the ownership of the user.

So where does the whole “keep Web 2.0 apps in permanent beta” idea come into play? My point is that Web 2.0 apps ought to keep themselves in permanent beta as a reminder to users that no Web 2.0 app outside of the user’s control is as safe as an application within the user’s control.

Use Web 2.0 apps responsibly™.

Last week, I dug out the old Compaq Presario 4508 again to install Linux on it. I booted up the Slackware CD, and found that none of the kernels on the CD would work on the Presario. Rather than spending time debugging error messages or creating a custom kernel, I moved onto FreeBSD, which succesfully installed the first time around. Because of the very limited RAM that the Presario had, running xorg wasn’t, and still isn’t, an option. So I peacefully went to work trying to install Python and a terminal web browser.

Yesterday, when I successfully installed the web browser, the issue hit me. I sacrificed a somewhat ancient operating system with a working GUI for a more modern, stable, and secure operating system without a graphical user interface. Did I make the right choice? Most software that I care about is available or can be easily compiled on FreeBSD, but I cannot use anything that requires a GUI. With Windows 95, I had a graphical user interface, but a limited set of modern applications that still can be run on Windows 95.

So what choice would you make? Would you go with the old OS with a GUI or the modern, stable, secure, and graphics free OS?

Not counting this footnote, the blog post is exactly 248 words long.

Why?

Because I actually managed to publish an email interview with Kwippy CEO Mayank Dhingra . That’s right! An email interview, like those big A-list bloggers do all the time! Yeah!

So, what improvements have gone into Kwippy? How is Kwippy better since last July?

The Kwippy team made it easier to invite Twitter friends to Kwippy, but got some negative publicity. The Kwippy folks quickly modified the feature so it would not spam Twitter users, and then wrote a blog post apologizing.

Kwippy also made some user interface improvements, including the ability for Kwippy users to customize their page with themes. Below are two screenshots comparing the old Kwippy with the current Kwippy interface.

You will notice that in the newer screenshot, Kwippy has the word “Friends” visible in the sidebar. This is part of a new feature that allows you to define who is your friend and who you are just interested in. Think of Kwippy’s “Friends” feature as a primitive version of FriendFeed lists.

Kwippy also added an employee. Matthew Phillips, known as Kestrachern, is Kwippy’s community manager. You can find short bios of (currently, the four) Kwippy employees.

I conclude this (very) quick glance at Kwippy with a note on the small, vibrant community that has appeared there. The lack of a character limit for messages on Kwippy (called kwips) or comments on kwips has led to a manner of discussing that is a bit of a hybrid between a forum and Twitter.

You have seen those extremely brilliant ant-Linux anti-Linux trolls that demonstrate their brilliance on IRC channels, message boards, and blog posts, right?

(No, I’m not talking about the Linux Hater. He is a different kind of animal. The Linux Hater is actually useful to the Linux community.)

Now, I bet that you’ve always wanted to become one of those trolls. You probably think it is grand to spread around misinformation, right? If you didn’t, you probably shouldn’t be reading this post.

General tips

1) Study the work of other trolls.

Other trolls have done a lot of fine-tuning of their flamebaiting skills, and you should observe their techniques in order for you to become a top-notch troll.

2) Be an anti-Mac OS X troll too.

GNU/Linux and OS X are both Unix-like operating systems. It is difficult to be a hater of Linux, a lover of Max OS X, and still look like a realistic troll. Loving Mac OS X and hating Linux is something that you might get to graduate to when you become a more advanced troll.

Though, should you ever become among the trolling elite and decide to be pro-Mac and anti-Linux, remember to register new accounts at all your favorite websites and chat rooms, or people will notice your change.

3) Be knowledgeable about Linux, but not too knowledgeable.

If you clearly know nothing about Linux, people aren’t going to listen to you. If you know a ton about Linux, then people are going to wonder why you know so much about Linux when you clearly hate it.

The goal is to get to a happy medium where people trust your opinions on Linux, but don’t suspect you to be secretly pro-Linux.

Account-related tips

1) Use multiple accounts.

People on the Internet aren’t very likely to listen to just one anonymous commentor, so remember to register at least five accounts per website or IRC server. You should also be registered on at least ten different websites/IRC channels, which hints at a total of at least 50 accounts per troll. Really good trolls, though, might need more accounts.

2) Choose strong, unique passwords for each of the accounts.

You might be tempted to choose the same password or same pattern for the passwords to your (at least) 50 accounts. This, of course, is very bad behavior because it would be catastrophic if even one of your accounts was accessed by a pro-Linux or even OS-neutral person.

Choosing long, unique, and hard to predict passwords is a good strategy to make sure that all of your trolling accounts are kept safe. Try using password managers such as Keepass to keep track of all the passwords you will have.

3) Aim for high or low karma.

Many websites and social networks have the concept of karma. That is, users can vote the comments of other users up or down. Comments with high karma are sometimes more visible on certain websites. Comments with low karma are usually hidden.

If your comment has high karma, other users like how you phrased your point, which means that you are a good troll. If your comment has low karma, it means that people do not like what you are saying and wish that you would not say it. Having comments with low karma is a sign that you are a good troll.

Website-related tips

1) Get your own websites (and domain names).

While posting comments or sending messages on other websites/IRC channels is a good strategy, there is always the chance that your comments will get deleted and/or you will get banned.

Having your own website is a better strategy. Getting a domain name is not necessary for having your own website, but it makes your website look more believable, which in turn makes you a more efficient troll.

Getting a website at Freewebs or another host is not recommended, due to the lack of control you have over the webpage. Buying shared hosting, and some domain names too, is the best way to create a troll website.

2) Remember to use SEO tactics on your websites.

Getting your websites into high ranking positions in search engines maximizes your visibility as a troll. The ultimate goal of an angry anti-Linux troll is to have every major search engine return anti-Linux webpages when the keyword “Linux” is searched.

3) Remember to follow usability guidelines on your websites.

Making sure that your website works well when it is read by screen readers and such seems like a waste of time, but it is necessary for the troll that wants everybody to hear the anti-Linux message.

Conclusion

While the life of a troll isn’t for everybody, these tips can make it easier for beginning anti-Linux trolls to get started.

No trolling in these comments, though.

Adobe Flash, while it appears to be buggier on Linux, is a neat thing. I can watch animations and play games right through my web browser. Now, I would prefer that Adobe Flash not be put to the use of making entire websites, or even major parts of websites, such as a navigation menu.

Flash usability hasn’t had major improvements in eight years, as evident by Jakob Nielsen’s similar article on Flash and usability.

Why too much Flash is bad

1) The user interface is nonstandard.

Flash websites have a tendency to make their own (shinier) scroll bars to help me navigate large amounts of text.

A web designer creating his or her own scrollbar, and then refusing to let me use the browser’s scrollbar is like the web designer poking holes in my car’s tires and replacing the tires with cardboard boxes. Well, perhaps I’m being a bit dramatic with the metaphor.

Interaction with the user interface also totally gives the user unexpected surprises. Most Flash websites do not allow me to right-click*, middle-click, or use my web browser’s scroll bar.

*Whenever I say, “no right-click”, I mean that the user cannot access a context menu from right-clicking.

2) Flash websites often take longer to load.

Oftentimes, I want good ol’ fashioned text coming down the pipeline to my screen. I do not want:

• text animations.
• animations of somewhat related images.
• sound.
• a screen that tells me that the above three are loading.

3) Ctrl+F doesn’t work on Flash websites.

I cannot use text manipulation tools to edit or search the webpage. I cannot type Ctrl+F and then search the text of the page. Greasemonkey would not work well in all-Flash websites. Neither would bookmarklets or Firefox extensions that allow me to manipulate the page.

4) OS-specific Flash Player bugs

I recently visited a website that had a bug with an embedded Flash slideshow. The bug was only visible when using the Linux Flash Player. On Windows, even on Firefox, the Flash slideshow worked perfectly.

The bug was that the Javascript drop down navigation was being hidden under the Flash slideshow on Linux, which made most of the menu inaccessible.

Designers shouldn’t have to test on multiple operating systems, because the vast majority of designers probably do not have the time or resources to do so.

5) Redundancy

Plenty of website designers will provide a plain HTML version of the content on the website for users that do not have Adobe Flash. I just don’t understand why there needs two versions of a webpage, with one being flashier than the other.

The main usability issue here is that any text or link pointing to the HTML version is often in very small text and sometimes only visible to users that do not use Flash. Users that do have Flash and want to use the text version might have a hard time finding the text version.

6) Redundancy

Sorry, I couldn’t resist.

Conclusion

I would rather visit an ugly webpage full of HTML hacks that were inserted by a poorly coded WYSIWYG editor than an impressive looking (but completely unusable) Flash website.

Why?

Because in an HTML website, the defaults are more usable because defaults in HTML pages are what most users are used to. In an HTML page, developers would have to go out of their way to create some of the annoyances that are common on Flash websites.

The vast majority of people that create HTML pages don’t have an impulse to disable right-clicking in the browser, or to make their own scrollbar when the browser has a scrollbar that works just fine.

So, please. I beg you to start an HTML page with a DOCTYPE tag, end it with </html>, and make sure that the only uses of Flash in between are not for displaying text and images.

“Listen. Easy now,” said the old man gently. “I know, I know. You’re afraid of making mistakes. Don’t be. Mistakes can be profited by. Man, when I was younger I shoved my ignorance in people’s faces. They beat me with sticks. By the time I was forty my blunt instruments had been honed to a fine cutting point for me. If you hide your ignorance, no one will hit you and you’ll never learn. [...]”

–Fahrenheit 451

Newbie programmers, when set to complete task, will often complete the task in the worst way possible. Of course, most programmers graduate beyond newbies. This post will detail some questions that newbies can ask in order to build better programs.

The below questions are things that all newbie programmers should be asking themselves so they can produce good programs. The questions can also be used as a very simple litmus test to see whether a programmer is a completely lost newbie or not. The Five Essential Phone-Screen Questions has a set of questions that help find good programmers.

<insert image here>

Photo credit: Flickr user anomalous4

When coming up with ideas for solutions

1) What patterns or algorithms can help me solve the problem?

Computers work well with numbers, and numbers are full of patterns and sequences. A simple example of a sequence is the Fibonacci sequence, where every number is the sum of the previous two numbers (1, 1, 2, 3, 5, 8, 13…).

A simple and useful algorithm is the Sieve of Eratosthenes, which is used to create lists of prime numbers.

2) Has somebody else already solved this problem or a similar problem?

Google called; they said they have the answer to your problem.

For those that can handle looking at the possibly messy code of others, looking online for open source code that can partly, mostly, or completely fill a need is a good idea.

A somewhat recent example is that I was looking for an open source Digg clone in PHP to make slight modifications to, and managed to find Pligg. Unfortunately, Pligg didn’t manage to fit my needs, but I managed to find PHPDug, which I like better.

3) What are potential issues I could run into when solving this problem?

It is important to think ahead about what issues could be faced when solving a problem.

For an important website, the power of the hardware, the power of the software, and the precautions taken for data loss and downtime, and more should be considered.

When looking at possible solutions

The first group of questions are things that newbie, or n00b, programmers should ask themselves when looking at a source code or a way to solve a problem.

1) Is this method fast as it can be?

Writing fast programs is a very important thing. Too many people are not patient enough for slow programs, and writing programs that can easily be made faster is not going to make users happy.

2) Is this method secure?

I sometimes wonder if it would be more beneficial to beginning developers Baller shouted “Security!” instead of “Developers!”.

Some common, but dangerous security mistakes that n00bs make are:

1) not escaping user input

2) not using file permissions properly

Chmodding everything is 777 is bad. Very bad.

3) using improper encryption to store things

3) Is there a simpler way of solving this problem?

If a person has two solutions to solve a problem, that person should always choose the simpler solution. The more complexity there is in a system, the more difficult it is to use and maintain that system.

4) Is this method scalable?

Creating software that works perfectly, with the exception it not being scalable at all, is setting up the programmer(s) for some major headaches down the road. A classic example is Twitter’s severe instability a few months ago.

Final notes

All programmers ought to subscribe to Coding Horror, a blog with far more useful content than you’ll ever find in this waste of disk space.

Also remember to ask questions on mailing lists, forums,  and so forth, but only after several hours of experimenting with Google keywords.

While plenty of people say that producing good content is more important than posting regularly, plenty of new bloggers, including me, feel guilty when they do not post regularly.

Now, there have to be exceptions to this rule. Bloggers that write mostly time-sensitive material, then following this rule could possibly hurt them by delaying the publishing of the posts. Taking a look at this blog’s archives will show that whenever I try to cover something time-sensitive, I always end up covering it a few days later.

Also, if you would like more extremely obvious (or extremely brilliant, depending on your perspective) tips on blogging, you might like reading some of this blog’s other posts covering bloggi–oh don’t bother, I know nothing on blogging.

I shouted to the Internet that I am unhappy with existing RSS readers. Now, let’s use our prediction skills to see what will happen next.

Hmm… Programmers like to solve problems. I appear to have a problem with RSS readers. The title also gives a hint that I’m making plans for an RSS reader. Considering all that evidence, it is pretty likely that I’m going to make an RSS reader, right?

Yup. You guessed correctly. I’m going to build an RSS reader.

Because I want to access my RSS reader from anywhere, I will be creating a web RSS reader.

Below is the list of features that I have planned for the RSS reader.

• Tagging of feeds as well as individual posts.
• A recommendation engine for posts.
• Integration with:
  • Google Reader
  • FriendFeed
  • Delicious
  • and possibly more
• The ability to experiment with possibly dozens of user interfaces.

Wait, “experiment with possibly dozens of user interfaces”? Now why would I want to do that? The main reason that I want to experiment with a large amount of user interfaces is because no user interface for an RSS reader (both desktop and web-based) have ever satisfied my need for large amounts of data to come down the pipeline and be displayed in a good looking manner.

I am also interested in getting feedback from users to see which user interface is the most easy to use.

Now all I have to decide is what language to write it in. I’m thinking of either writing it in PHP or Python. I’m leaning towards PHP, as I haven’t actually done any real web programming in Python. I might try Ruby on Rails, as I know a small amount of Ruby.

Because of my limited resources, my RSS reader would be restricted to private alpha, though making the RSS reader open source would allow other folks to try it out on their own servers.

Any comments and suggestions on my RSS reader? Comment below.

I’m not that great of a singer, but I don’t think that the song is *too* bad for a silly parody that I came up with in an IM conversation.

EDIT: If you didn’t see the original post, you can find the lyrics to my parody song here.

Well, to fill up space, I think I’ll advertise the guest posting offer. Email me at possible248@gmail.com if you would like to write a short, tech-related guest post. If you wish, you can read up more on why you should guest post on this website.