Openbox

I finally gave in and started using the Openbox window manager.

I didn’t want to use it for the longest time for two primary reasons:

  1. It didn’t have any like a task bar, and I couldn’t find any stand alone task bars that I liked.
  2. It’s too popular. So many Arch Linux users use Openbox!

I had an epiphany recently, and that was that I really don’t want anything like a task bar. I use window shading a lot. When I want a window to be hidden, I simply iconify it to nowhere and bring it up again using the root menu. It’s great!

I have conky setup to give my all the heads-up information I need, and a slick theme to make everything look nice.

Openbox supports full compliance with things like full screen applications and changing the screen resolution, which my previous window manager lacked.

I’m happy with Openbox so far, and look forward to using it for a long time.

Software development lessons

  • There should be clear communication about what the problem actually is.

Don’t solve the wrong problem.

  • Solve the problem to meet specifications.
  • Perform test driven design.

If you are unsure of your goals then you’ll never reach them.

  • Use debugging tools.

You can find and fix the problem much faster using debugging tools instead of print commands or, worse, randomly changing things.

  • Don’t repeat yourself.
  • Create a personal collection of software tools and libraries that I wrote.

Learn from the work you do, and keep it with you in order to use it in the future.

  • Write modules with a single responsibility.

If a module tries to do more than one thing, splitting it up will probably make the design easier.

  • Write against interfaces, not classes.

Even if it seems simple and silly to write a simple interface for a single class to use, chances are, in a big project, having it written against an interface will very likely make your life easier in the future.

  • Learn how the entire software system works.

If you can be that person on the project that knows what every part of the system does, you’ll be invaluable.

Steps for being a good programmer

Here are some general pointers I try to remember when writing code. Even though following these guidelines always helps me, I do a poor job at following them. So, I’m hoping that¬† I’ll follow them better if I write them down here.

Work from the top down

    This can be a nice way to ease into writing . Think about what you want the code to do and write a function name that represents it. (for example, play_game(…)) Then, think about what you want that function to do, and write function names that represent it. (initialize_game(…), update_game(…), draw_game(…)) Keep doing this until you have super simple functions that need to be filled in to make everything work.

    Design good data structures

      This applies to both object oriented design and not. Spend time designing good data structures and objects. Design good relationships between them. I’m not going to describe what makes a data structure good or bad here, but for some reason I can always tell the bad ones when I begin trying to use them in functions.

      Design good simple functions

        Similarly to designing good data structures, design good simple functions. For example, if you have a function name that has the word “and” in it, it may be time to reconsider the design of your code.

        Break the problem down into smaller parts

          This is a more general way of summarizing all of the points above. Writing a new application may be a daunting task. Break the problem down into smaller problems, until the problems that remain are simple and easy to solve.

            If you don’t have the data you need, move the functionality up to a higher level function

            This one’s a little tricky to describe. If you’re working in a function and you seem to need to keep sending more and more data structures as parameters, stop and reconsider if that function is really the right place for all of that logic to happen. Consider moving it up into the function that calls that function instead. This principle seems to help me pretty often.

              Code for the specific application you’re working on

              This is one of the most important points in this list! It’s easy to think it’s a good idea to make your data structures and functions work well for other programs or “future projects”. You know, making your code generic and “reusable”. Well, stop it. The future projects you’re thinking of probably won’t ever get written, and you’ll waste time making your code generic instead of just making it work well for the program you’re working on.

              Game idea: Spinbot

              I plan on learning how to use the Pyglet media library and the Cocos2d game library, along with gaining more experience with Python, by creating a simple video game. Here’s my next idea:

              Spinbot is a platform puzzle game. It involves simple puzzles related to changes in perspective and changes in gravity.

              Each puzzle takes place in a room. There are platforms scattered throughout the room. The player can move left and right and jump. Any time the player comes in contact with a surface, the screen rotates so that the surface they touches is the new “ground”. Gravity also changes to match the new rotation.

              The goal is to guide the player, Spinbot, through the room in order to find and touch a glowing power sphere. Obstacles include surfaces with oil that the player can’t grab on to, and moving platforms.

              I hate C++

              I hate C++. I will never ever use it by choice to write software again.

              C has been my favorite programming language for many years, but I never really did anything with C++.

              I’ve decided it’s incredibly wordy, error messages from the STL are really hard to read, there are so many things I need to do myself instead of having the compiler take care of them for me, there are many ways to do everything, it takes an incredibly long amount of time to compile my small application, and the standard library is so small and painful to work with. I could go on and on.

              I don’t hate pointers, I don’t need automatic garbage collection, but holy moley it feels like everything that’s been implemented in C++ has been done in the worse way possible.

              Why is this language so popular? It has almost an infinite number of features, which can be nice I suppose. If you want a fast, compiled, object oriented capable language then there traditionally aren’t too many options. Some others are Ada and Objective-C.

              I may have made a mistake. Before working on my first C++ application, I wrote my first Python application. I think Python spoiled me.

              I wish there was a language that was like Python but compiled like C. I’m sure many programmers want the same thing. Maybe one exists, but if it does I don’t think it’s very popular yet.

              For now, I think I’m going to start using Python a lot more. Throughout my life as a programmer, I’ve written software in assembly and C. I’ve learned a lot about good programming principles and managing all of the details in the code myself.

              But I’m getting of tired of it. Writing code in a language like C++ can be kind of fun, but I never get anywhere. Alternatively, with Python I can have fun and actually finish an application.

              Contributing to the FOSS community

              In what ways have I contributed to the free and open source software community? And what can you do to help? Here are some thoughts.

              I love helping FOSS projects, but it can be difficult to decide what to do.

              Keep it simple

              Choose a project where you need to learn one thing at a time.

              There are languages (examples: Python, C), libraries (examples: GTK, Qt), and programming paradigms. (examples: GUI programming, threaded programming) When you begin working on a project, you will probably need to learn something new. Try to learn only one thing at a time. For example, if you have to learn gstreamer and GTK (two libraries) at the same time then you might become frustrated. Or, if you have to C++ and Qt (a language and a library) at the same time then you might become frustrated.

              So, try to learn one thing at a time.

              Working with other FOSS developers

              I love working online with FOSS developers. When I get to talk to the lead developer of a project, it feels like I’m talking to a celebrity.

              Of course, you should join the mailing list and bug tracker for the project you want to work on. I don’t usually introduce myself. Instead, I just start helping, and people will know me soon.

              My FOSS experience

              Here are some examples from my FOSS experience.

              Many years ago, I wanted to write a new FOSS application. I couldn’t think of any new applications to make, so I decided to make a video game. There are never too many video games.

              I learned many things by making video games:

              Languages: C, Objective-C, Java, Assembly, Ada

              Libraries: Allegro, SDL, Java SWING

              I’ve submitted many bug reports to many different projects, such as wxWidgets, Allegro, Udiskie, and Haiku. I really like submitting bug reports and working with the developers to fix the problem. It’s easy to do and I get to use better software.

              I maintain some AUR packages. (very easy, but it helps FOSS)

              I helped write the documentation for some software from the Arch Linux community, such as Packer and Udiskie. I’ve contributed to the Arch Linux wiki.

              Recently, my wife and I wanted a new application for budgetting. I decided to write one. I used Python and wxWidgets. It works pretty well. My next goal is to convert it to C++ and wxWidgets, and then make a version for Haiku using C++ and the Haiku API.

              Interesting things

              You should definitely work on something that you think is interesting. To me, that’s Arch Linux, Haiku, bug reports, and documentation. Try to find things that are interesting to you!

              Lastly, don’t make your goal too big and don’t try to do too much. There are many many people helping in FOSS. If everyone does a little bit, then we can make something great.

              GNOME 3 pre-release opinions

              It was announced on the GNOME developer list that GNOME 3 won’t have minimize or maximize buttons:

              http://mail.gnome.org/archives/gnome-shell-list/2011-February/msg00192.html

              That’s a huge change. My initial reaction was “Whaaa?”, but then I started thinking about how I use my window manager (currently FluxBox). I almost never use the minimize and maximize buttons, and certainly wouldn’t miss them if they were gone.

              The mailing list message talks about helping users learn a new work flow. This reminded me of when I started using Haiku. Haiku has a powerful file manager called Tracker. Tracker is a spatial file manager, which means every folder opens in its own window. The first thing I wanted to do was change it to a navigational file manager. So, I went to the Haiku documentation.

              I found the information I was looking for, which included this comment:

              Before you switch Tracker to Single Window Navigation mode, because that may feel more familiar to you, we recommend giving the menu based browsing a try first, as that may actually work much faster for you after getting used to.

              So, I decided to continue trying Tracker as a spatial file manager, and now I really like it.

              Now, in regards to GNOME 3, it’s hard for me to express how I feel about it. Let’s see if I can summarize it:

              • There are too many things that move around the screen. Things go from the window view, which shows almost nothing but the window you’re actively using, to the activities view, which shows everything at once. And I mean everything, every workspace, every window, every running application, every recently used document, directories, and search. And those things were all designed to move and live and grow as you use your computer, which means things are shifting around a lot.
              • It forces a new workflow on users that doesn’t appear to be better than another workflow. This may not be a bad thing. Haiku kind of enforces a new workflow, but I quickly learned to like it. With GNOME 3, I have no idea how the new workflow is supposed to benefit me. Which leads to:
              • How will they train people? When GNOME 3 is released, the new design may be great for many many people, but they need to learn how to use it before they can benefit from it.
              • It requires accelerated graphics.

              GNOME 3 hasn’t been released yet, and my opinion will probably change. I hope the GNOME developers know what they’re doing, because I sure don’t know what they’re doing.

              Icons

              I’m very unhappy with the situation of icons in Linux.

              When I started using Linux around ten years ago, it seemed like every application had it’s own way of adding an application icon. Nowadays, it seems like most applications use the standard FreeDesktop.org method, but a few don’t, or something. I don’t know. All I know is, I always end up with a few applications that have icons that either look horribly out of place or simply just don’t exist.

              Haiku is another open source operating system. It has beautiful icons compared to any other operating system, and I think there are a few reasons for that:

              1. The one and only Haiku API encourages software developers to use the official method of adding an application icon.
              2. All of the other icons in Haiku look so nice that, if you don’t make a beautiful icon for your application, it will stick out like an ugly application icon.
              3. There’s hardly any software for Haiku at the moment.

              Anyway, I recently started using the Fluxbox window manager. I chose it because it has a clean and simple user interface, and I can disable all application icons.

              The return of malloc

              Should you always check the return value of malloc? There’s a heated debate over the answer.

              One group insists that, in good software development, you always check the return value of a function, including malloc. It appears that most software developers are in this group.

              The other group thinks otherwise. I’m in this group. Here’s why.

              I was taught, like many programmers, to always check the return value of malloc. This thread made me think otherwise:¬†Always check malloc’ed memory? The asker raises many interesting points.

              When thinking about checking the return value of malloc, it’s important to consider the operating system, hardware, and type of software that you are working on. Linux may behave differently from FreeBSD, a desktop computer may behave differently from a mobile phone, and a GUI application may need different considerations than a shared library. Also remember that it may not even be your application that is causing malloc to fail.

              I’m primarily concerned with the case of a GUI application running on Linux on a desktop computer, because that’s what I work on. Even so, it’ll be fun to think of the other cases.

              Failure Response

              So, let’s say you check the return value every time you use malloc. What do you when a return from malloc fails? You could simply quit your application immediately. You could try to quit your application gracefully. You could cancel the command that caused the fail and display an error message. You could loop until either malloc returned a valid result or the computer catches on fire.

              Can You Respond?

              Let’s pretend that malloc failed. Imaging the state that the computer is in that caused it to fail. Would it still be able to do any processing at all? I agree that it is extremely important for an application to never lose the user’s data, but would the computer even still be able to recover anything at that point?

              Does malloc Fail?

              In Linux, malloc may never even fail. On the malloc man page under “Bugs”, it states that just because malloc didn’t fail doesn’t mean it has enough memory.

              The Trial

              So, I wrote some code to try and make malloc fail. When it does, it tries to recover and quit gracefully.

              #include <malloc.h>
              #include <stdio.h>
              #include <stdlib.h>
              
              typedef struct NODE
              {
                int data[40000000];
                struct NODE* next;
              } NODE;
              
              int
              main(void)
              {
                NODE* node;
                NODE* first;
                NODE* last;
                int stop;
                int count;
              
                first = NULL;
                stop = 0;
                count = 0;
              
                while (!stop) {
              
                  node = (NODE*)malloc(sizeof(NODE));
                  count++;
              
                  if (node == NULL) {
                    printf("FAILED! %d \n", count);
                    stop = 1;
                  } else {
                    if (first == NULL) {
                      first = node;
                      last = node;
                    } else {
                      last->next = node;
                      last = last->next;
                    }
                  }
                }
              
                count = 0;
                node = first;
              
                while (node != NULL) {
                  last = node;
                  node = node->next;
                  free(last);
                  count++;
                }
              
                printf("FREED %d \n", count);
              
                exit(0);
              }

              The Results

              Here are the results when running it on three different operating systems.

              Arch Linux: After 55 seconds, the message “Killed” was displayed. This was a message from the operating system, not my code. My program never had the opportunity to see a failure from malloc nor try to cleanup after it.

              Haiku: Almost immediately the program stopped. The output was “FAILED 10, FREED 9″. That means that after trying to allocate about half a gigabyte of memory, it failed to allocate anymore and was able to clean up the stuff it had.

              Windows XP: The results were similar to Haiku: Almost immediately the program stopped. The output was “FAILED 12, FREED 11″.

              Conclusion

              By using this simple test, it appears that checking the result of malloc can be a worthwhile task. My conclusion is contrary to my feelings from the beginning of this post. I think I just might have to change my programming habits.

              What I do in Haiku

              This is a growing list of things I do in the Haiku operating system. The purpose of this list is to have an easy reference when people ask, “So, what can you do in Haiku?”.

              Also, this is not a list of possible examples of what I could do in Haiku. Instead, it’s specific things I’ve done while sitting down and working with my computer.

              • Update my tech blog. (WordPress, the one you’re currently reading)
              • Browse the Internet with WebPositive.
              • Use Gmail.
              • Use Facebook.
              • Chat with friends on Google Chat, Facebook Chat, and MSN with Caya.
              • Type in Japanese.
              • Download and watch a video using the Transmission bittorrent client.
              • Erase a CD-RW.
              • Download the latest nightly image of Haiku and burn it to a CD.
              • Watch and listen to the lecture video (M4V) from my graduate course.
              • Use SSH to login to my school to work on a graduate lab.
              • Read and write files to my Linux EXT3 drive.
              • Listen to a playlist of my MP3 music files.
              • Video game development using the PE “Programmer’s Editor”, GCC, and the Allegro Game Library.
              • Version control for my software using SourceForge and git.
              • Enjoy the screensavers. This may seem like a small thing, but I believe it’s important. Haiki has at least two screensavers that I think are really nice, namely “Butterfly” and “Icons”.
              • Use multiple desktops to make my workflow easier.
              • Take a screenshot using the Print Screen key and the Screenshot application.
              • Edit an image in WonderBrush.
              • View PDF files using BePDF.

              Screenshots

              Desktop 1: Programming (PE, Terminal); Desktop 2: Internet (WebPositive, Caya); Desktop 3: Music (MediaPlayer); Desktop 4: Document (StyledEdit)

              <todo>