Tomboy notes is is a very good desktop note-taking application for Unix and Linux. It makes linking very easy and (at the time of writing) there are a few useful plugins that would be useful for reminders with Tomboy, exporting the linked notes to a graph, or posting your notes to a WordPress or Blogger blog.

Just a quick little thing that you might be interested in if you are a developer that runs Linux.

UPDATE: There is also a plugin that exports Tomboy notes to Vym (See the CodingExperiments post on Vym).

If you’re of the type that writes out math in your notes, you might be interested in the LaTex math plugin for Tomboy.

Today’s MMORPGs (Massive Multiplayer Online Role Playing Game) put you in the role of the ruler of an empire of planets,  performing quests,  or just play sports. Why not have an MMORPG where users type computer code to earn points?

There would be many ways for a player to earn points. A player could attempt to hack into another player’s imaginary "computer". A player that hacks into the "computer" of another player will be able to take all the hacked player’s points away. Other than that, nothing bad would happen to a player that had his or her computer hacked into. Code that deflects attacks can also be written. For each successfully deflected attempt on the player’s computer being hacked into, he gets 10% of the failed hacker’s points.

Code that both hacks and deflects hacking attempts can be sold to other players so they can use it. Players have to spend a certain number of points to get access to the code. The original programmer of the code that is being sold gets to decide whether or not a player that buys the code can view or modify and sell it.

Players can also place bets on the outcome of other players. A player might wish to risk a few points in a bet that a very high-ranking player will get hacked into within the next six weeks.

This idea is a bit of a work in progress and I’m probably won’t actually ever create a game like this because it would be a bit too much work to create a programming language and then an interface to play the game with.

Note, the name ModCMS has been changed to BurstCMS.

Introduction

I was writing some trigger_error (); function calls when I thought of something that could be part of ModCMS. Obviously, it would handle PHP errors. A simple error handling function is pretty useful on production-line websites that you still change the code actively to or a website that has not been thoroughly tested. The ModCMS error module would be required for any module. Here is what it would do.

Some people code user-friendly error code without considering the type of error that it might handle. For example, if there is a E_NOTICE or E_USER_NOTICE error in the code, don’t stop everything. A E_NOTICE or E_USER_NOTICE error is exactly what it sounds like, a notice. I believe that it should be used to notice the programmer. For example: I am currently writing a PHP method to one of my classes that will scan parts of the HTML document for not enough or too many closing tags. I am using an E_USER_NOTICE error to inform me when I have not enough or too many closing tags.

I believe that an E_WARNING or E_USER_WARNING error ought to be used for when something is definitely wrong, but the rest of the script(s) can continue even with the error. You might use it when something that isn’t very critical (page footer) doesn’t load.

User-Friendly Errors With the ModCMS Error Module

Errors need to be user-friendly. At the moment, because I haven’t coded the ModCMS error module yet, I just hide all errors unless I type a special GET parameter in the URL. The GET parameter is useful for debugging without having to turn on site-wide error reporting or having to move the script to a testing directory with error reporting enabled, but it doesn’t make any explanation to the user about why my website isn’t displaying properly.

I would fix that by having little alerts for even E_NOTICE errors.

E_NOTICE and E_USER_NOTICE errors

E_NOTICE and E_USER_NOTICE errors with the ModCMS error module would be displayed to the user with a red box at the top of the page telling the user that there might be some problems. The box would give no description of the error to the user and would not be too much of an annoyance.

E_WARNING and E_USER_WARNING errors

E_WARNING and E_USER_WARNING errors would either be a a larger red box to emphasize the error or (the programmer decides) a splash screen.

E_ERROR and E_USER_ERROR errors

E_ERROR and E_USER_ERROR errors are page-terminating, so they would display a user-friendly version of the default Apache 500 internal server error pages.

Developer-Friendly Errors With the ModCMS Error Module

If you’re the site developer, you need errors that explain what went wrong. It would be activated by the same sort of GET parameter that I use for my debugging, but instead of the errors being displayed all over the page, they would be displayed on the little box at the top of the screen, the splash screen, or the error page.

Brought to my consideration recently by a change in the way I use a program for school, I’ve been thinking about good and bad ways to store data in networked applications.  In normal programs, resources are stored locally on the machine that runs the application and retrieved directly by the system when they are needed.  Applications that run over the network, however, are subject to a different kind of data storage model, one where the “master” or “server” holds the authoritative copy of everything, and all data on the client machine, save in some cases for the program executable itself, is considered to be a temporary (“working”) copy.

There are some humps to overcome in the latter (network) model.  First, how does the program handle resources that are unlikely to change?  Let’s take interface sounds as an example.  It is unlikely that the sounds played when the user clicks a button or correctly answers a prompt (for e.g. educational software) will change frequently.  Thus, it does not make sense to load such resources again from the master copy every time the program is started.  The first time the application is run, it should retrieve and cache all common, static resources on the local disk, and merely query the server for updates on subsequent runs.  This saves time and network (LAN or Internet, depending on context) bandwidth.

What of resources that might change from one day to the next, or even one hour to the next?  The same principles should be applied, because it is likely that users will use the program more frequently than the data is updated.  For example, a course content delivery system I am using for a class I’m taking this quarter violates the best practice I’ve set out above.  (I came up with this post myself, with no input from any research at all.)  On each program load, it proceeds to download a fresh copy of all the resources it uses, including question databases for practice, sound files, and text.  When run locally, the application takes a few seconds to start; running over the Internet, startup times jump to over five minutes, perhaps ten or fifteen.

It is not the fact that the first load takes ten or fifteen minutes that is bad for usability.  The fact that the delay occurs at every single startup indicates that no caching at all is taking place, and that discounts the fact that a full copy of the materials on the server is present on the local machine, included in the normal installation.  All sound files, text, and course material is already loaded on the local disk, and is downloaded across the Internet on each load for no reason.  So, not only does the program not cache what it downloads, but it doesn’t even necessarily need to download the data in the first place because of the presence of a local copy.

In summary, an application that can be configured to use a central database or storage system, whether for centralized record-keeping or otherwise, should follow these points:

• Download only what is necessary. This means don’t download files that won’t be used.  Load material dynamically each time a lesson is requested, for instance; this reduces initial load time and makes the user wait less.
• Cache what is downloaded.  This further reduces load times and cuts bandwidth usage.
• Intelligently determine what is available locally.  There is no sense in downloading a copy of a file already present on the local machine.  Resources identical to those already available locally should never be downloaded.

If the program I am thinking of follows these principles, and perhaps (could it be possible?) improves on them, it would reduce the wait time of everyone in my class, including the teacher (who works in no closer proximity to the server than us students).  Currently, one has to plan on reading a chapter of a novel or jogging half a mile (or writing a blog post on how to improve network applications ) while the software loads.  Urgh.

For a more detailed explanation of the problems with the specific program that inspired this post, see my blog, Technobabbles.  For a fictional perspective, see The Queiba Wars.