Using Roundup to avoid information overload

Roundup Issue Tracker helps prevent information overload by:

1.    Stopping ALL spam.  If an addressee is not known to Roundup the email is silently dropped.
2.    Only privileged users can create a new issue, so if an existing external user's email account is hacked, they still cannot spam you with a new issues.
3.    All superfluous email signatures and graphics are purged, just the plain text component and file attachments are retained.
4.    If a message gets through that does contain superfluous material, you can edit the message directly on disk or retire the message so it is no longer visible.
5.    As soon as you decide that a message thread is no longer current you simply retire it.  While it remains visible to searches, it no longer appears on your list of current conversations.
6.    A number of different views of your issues can be saved.
7.    File attachments aren't retained with the individual message, they are retained at the email conversation level.

These Roundup features mean that:

1.    The excessive broadcaster.
2.    The quote everything replier.
3.    The spammer.

can be stopped in their tracks.  The one problem that Roundup can't solve is the file attachment abuser.  Frequently the excessive broadcaster and the file attachment abuser are one and the same, so by preventing excessive broadcasting, hopefully file attachment abuse will decline too.

Classmaker on Linux

Recently, I spent the day recommissioning an ancient Windows 2000 box that has lain unused in the back of my office for years.  Periodically, it get's fired up for some experiment or other.  Last time it was used as the database server for ClassmakerLite, but, as none of you were using ClassmakerLite, it went back to sleep again.

This time it was supposed to be used by my children to play Minecraft, but I quickly discovered that nothing much is capable of running on Windows 2000 these days. None of the current crop of Web browsers can manage it except Qupzilla and it was painfully slow.  Earlier versions of Mozilla Firefox work, but they are also too slow.  The only browser that has any speed is Internet Explorer 5.0, but it can't render modern pages properly.  When I found the current release of Java wouldn't install... I gave up.

Thought I might give Classmaker a whirl while I had the box running.  I knew it would run quickly without any issue on Windows 2000 and it did.  But, I wondered, how might it run under Linux using Wine?  I've mused about this before, because I know that Fox-Toolkit uses emulation rather than native operating widget calls to build its GUI and Classmaker's GUI uses Fox-Toolkit exclusively, so in theory, Classmaker should be making very primitive calls into the Wine emulator - calls to routines that must have been present in Wine almost from it's beginning.

I installed Puppy Linux and then installed Wine. Puppy Linux is my favourite Linux distro.  Very easy to install and when you want to get rid of it again, which I invariably do with Linux distros, its a snap.  Took a while to understand how Wine works, but once I did, I had the client side of Classmaker running just fine.  As I already know that Isectd and FirebirdSQL work natively on Linux, although it's been many years since I've run them that way, I can now say that Classmaker as a whole can run on Linux without any code changes being necessary.  Not that I'm going to bother as I've never come across a teacher that uses Linux!  Apple Macs, yes, but I'm not interested in Macs.

The point of this post is to explain what this kind of portability across operating systems means:

1.    Your code base uses external libraries sparingly. The more external libraries your application depends on the higher the probability that the application won't port.
2.    Your code base isn't tied to a vendor specific library that is operating system specific.
3.    Your application uses common fonts and graphic formats.

So what did I have to do to get Classmaker working on Linux?

1.    Copy the following files to a directory somewhere on Linux... Classmaker.exe, isdio_dll.dll, Classmaker.ini  In my case, I just left them in C:\Classmaker\Remote since you usually install Linux on top of an existing Windows box.
2.    Edit Classmaker.ini so that it points to the remote server where Isectd and FirebirdSQL reside.  Here's what my file says:

[Readme]
This file is required so that clients know where the Isectd daemon
is located and what service they are requesting on it.

[IPConfig]
Host=robert-pc:5501
DatabaseService=aotea

3.    Open a Bash terminal and write the following line:

wine start /Unix /mnt/home/Classmaker/Remote/Classmaker.exe

Classmaker starts.

4.    The only thing that had me stumped for a while is Exporting and Importing Unit Plans.  These get written to and read from C:\Classmaker\Transfer.  Found out that Wine emulates the C: drive under /home/$USER/.wine/drive_c  Linux directories preceded by a dot are invisible directories, so I had to go into my home directory and press Ctrl H.  Immediately I could see ~/.wine/drive_c.  Once I added the directories Classmaker/Transfer below ~/.wine/drive_c importing and exporting worked fine.

Email wants & needs

In my previous post I noted that in the long term you really NEED to have a local copy of your emails and not rely on the Cloud for everything.  What follows then, is a search for an email client not a Cloud client.

I started to become disallusioned with my current email client for the following reasons:

1.    To prevent downloading spam, most of the time I was using the web browser interface, but that only stores my emails for a short time before they are automatically purged.
2.    Frequently I look at emails and think, I will get back to that or refer to it later, but I have no way of tagging it for future recall.  Sure..., I could use folders and filters, but it all seems like a lot of administration, just to order my emails as they arrive.
3.    Lot's of corporate email users these days encumber their emails with fancy signatures using graphics.  I don't want any of that.  Just the text of the message is all that's needed.
4.    It would be nice to have email conversations linked together in the same way that mailing lists have, so that they can be searched by thread.

Could there be a better way to handle my emails?  I began looking around at open source solutions and came across Roundup Issue Tracker  (http://www.roundup-tracker.org/).  It refers to itself as issue tracking software, which is just another name for bug tracking software. Still there's a number of things I like about it from an emailing perspective.

1.    Written in Python it's easy to customise.
2.    It uses a Web interface.
3.    It stores it's file attachments and messages on disk in id order separate from the database, so in future they can easily be purged.
4.    It can be customised so that all inward emails are automatically dropped if they do not match an existing email address.
5.    It has several levels of users.  I have customised it so that only privileged users are allow to create new issues.
6.    It uses multiple keywords, and three additional sort options called priority, status and user assignment to search for issues.
7.    It automatically threads email conversations.

What Roundup is most well known for is it's concept of the nosy list.  Nosy lists behave in a similar way to CCing somebody into a conversation and from then on always using Reply To All.  The difference is that Roundup keeps track of the recipient list rather than having to use Reply To All.  Just CCing someone into an email conversation means they will always remain part of the conversation until it finishes, typically in less than ten email exchanges.

The nosy list, automatic conversation threading and user assignments make Roundup a good candidate for workflow software, but what attracts me is Roundup's potential to limit information overload.

Email usefulness

Emails are, in my opinion, still the most effective piece of consumer oriented communication software technology that we have. The reasons for this are many:

1.    Emails use stable standards, so that anybody can build the appropriate clients and servers to transmit them.
2.    Emails are asynchronous.
3.    Emails use push/pull technology, so that users receive notification without needing to do anything except set their email client running.
4.    File attachments can be included and this, combined with the text message, means that any kind of information can be transmitted.
5.    Emails can be broadcast.
6.    Filters can be applied to them as they are received, due to their detailed header information.

Such a popular form of communication was bound to attract free-loaders and time wasters.  These users fall into four categories:

1.    The file attachment abuser.
2.    The excessive broadcaster.
3.    The quote everything replier.
4.    The spammer.

Spammers in particular have done enormous damage to the usefulness of email, but all four of these users, are doing just one thing - creating information overload.  Spammers have forced many users to switch to web browser interfaces for their emails because by using a web browser interface, spam and other unwanted emails can be deleted from the email server without the hassle of downloading them to an email client.

Nevertheless in the longer term your emails are a useful resource and you really NEED to have copies of them locally, not just in the Cloud.  This was brought home to me the other day when one of my supplier's email mailboxes would no longer receive emails because it's mailbox quota had been exceeded.  I had to resort to faxing to get the message through.

Multiple entries in the same time slot

Calendars cells can be either mutually exclusive or allow intersection between plans.  Most lesson planning packages have mutually exclusive cells.  I think they should allow intersection.  Here's why.

1.    Real life doesn't nicely partition events.  Overlapping is common.  For instance, you have duty periods during your lunch break.
2.    Bulk copying of records isn't possible with mutually exclusive cells.  Where are the copied plans going to go?  You don't want new records replacing existing records or new records inserting themselves into the display.  Instead they must go into a holding area from where they must be individually assigned to a new time slot.
3.    Being able to duplicate records in the same cell can have real advantages as previously noted when using Rotating Schedules.
4.    Template copying relies on record duplication.  If you want to copy a new record from an existing one its much easier to take a complete copy of the record and then delete the parts you don't want, than to cut and paste to make up a new record.

Real world Web browser development

Have just completed a small static Web browser application.  It is a bi-directional data capture application.  In my case it is a stock order system.  It works like this.  You fill out a single page order form (which is an HTML form with external CSS files and external Javascript files) and email it as an attachment to the wholesaler. The wholesaler opens the attachment and prints it off. They wander around their warehouse ticking off the stock items as they are picked.  When they are finished, they tick off the items on the HTML form, add any notes about the order (perhaps not all the stock is available and some of it has been placed on back order), regenerate the HTML form as text, which they cut and paste back into the email as a reply.  When the email reply is received, the recipient copies and pastes the email body back into an HTML file on their desktop and views the revised form. This process can be repeated as many times as necessary until the stock order is complete.

What have I found out?

1.    Javascript is so popular it's easy to find a solution to just about anything with a quick search on the Internet.  Due to the nature of the language the explanations and solutions are very straight forward and easy to understand.
2.    Using CSS for layout can be tricky.  Content boxes don't always do what you would expect.  I found myself using them on a trial and error basis most of the time.  After a while I began coding most things in pixel sizes and using id selectors for everything.  In Fox-Toolkit, text never exceeds it's content box boundary, but with CSS, sometimes it did.
3.    Having a separate external CSS file for printing was fantastic.  In every other software development environment I've used, with the exception of Microsoft Access, printing has always been a major problem.  With CSS all I had to do was create a new style sheet and make everything invisible except for the stock table.  It was done and dusted in 30 minutes.
4.    The DOM (document object model) is another great feature of Web browsers and Javascript.  It allowed me to easily create a dynamic table where new rows could be added and removed at run-time.
5.    JSON too proved to be huge time saver, serialising and deserialising my Javascript data storage array with a couple of functions.  In Classmaker, I had to write and debug my own lightweight tokenised string data structure (which by the way has been a wonderful thing - lightweight tokenised strings for data transport rock), which incidentally is very similar to JSON.  With JSON it was all done for me. As argued by the proponents of JSON, XML is just too markup heavy for decent data transport performance.
6.    My application has relied heavily on include files.  The core HTML file is as small as I could make it.  All the HTML markup code is located in an external Javascript file. With just 15 lines and 760 bytes in size, it is easy for core HTML file to be copied backwards and forwards as text in the email body.  All the include files which are doing the heavy lifting are located on a Web server. Without include files the HTML file would have been too large to copy around as text.

After reading this you might be asking why?  Why not create a spreadsheet and email that backwards and forwards?  I didn't choose the spreadsheet route for three reasons:

1.    I wanted the end users to have no software dependencies to worry about.  By using a Web browser that is avoided.  The only hiccup would be users who do not have Javascript enabled on their browser.  To be frank, they would be a rare breed these days.
2.    Printing was very important to me.  I needed to be certain that printing out to hard copy would be painless for users.
3.    I wanted the stock table rows to be created dynamically at run-time, with no opportunity for data to be loaded into unexpected places.

Have Web browser apps finally come of age?

In the past, I've evaluated Web apps and discarded them as being a waste of time for the following reasons:

1.    They are very slow.
2.    They were hard to print from.
3.    They didn't have adequate window controls.
4.    They didn't have an adequate window layout system.
5.    They mixed data and presentation together.
6.    The web browsers weren't standardised.
7.    They didn't have a powerful client side language.
8.    They didn't allow the use of include files.

All of these things, with the exception of slow response times are changing.

Web browsers today have:

1.    Fast rendering engines.
2.    Intelligent printing e.g. modern browsers will automatically split a print job across a table by splitting on the row and printing the table headers on the new page.  In the past a row would be chopped in half.  They also have useful options like page counters and date of the print job.  Firefox is leading the pack in the printing department.  I use it to print the invoices I generate from GNUCash (if you're looking for small business accounting software, check it out.  After evaluating a number of desktop and Internet based packages, I chose GNUCash, due to it's maturity and customisability.  It uses Scheme for it's embedded language).
3.    The introduction of tabs has been a major development, but they still don't have the sophisticated controls available to desktop developers.
4.    The introduction of Cascading Style Sheets is one of the main reasons I'm now looking more closely at Web development.  CSS means that a developer can now completely separate presentation from content.  Pages can now be coded up in basic XHTML with no formatting of any kind.  They will appear on the page sequentially.  With the liberal use of <div></div> content boxes and CSS the content can appear anywhere in the browser window. This still isn't as easy to do as it is in Fox-Toolkit, but it's getting close.
5.    Before CSS, web development was a mess.  HTML tags had to contain all sorts of markup for font-sizes, font-styles, dimensions for the control and colors just to mention a few.  Now all of this presentation markup can be removed and all presentation can be organised from the external style sheet.
6.    Web browsers weren't standardised and there were lots of different client-side binary formats competing for attention e.g. ActiveX, Java applets, Flash applets.  Thankfully, these have gone away and Javascript has largely won the battle for client-side control.
7.    As mentioned above Javascript has now been accepted as the default client-side scripting language.  It has come ahead in leaps and bounds.  Two areas in particular deserve mention, DOM and JSON.  DOM provides a reference for all elements on a web page using a tree structure.  The entire tree can be quickly navigated using Javascript to locate, add, delete and manipulate elements at run-time.  JSON is a text based data format, that naturally co-exists with Javascript.  It is a simple matter to create and parse JSON objects using Javascript.
8.    Web browsers can use include files as a matter of course.  Your web page can include any number of CSS and Javascript files.  Three advantages accrue from this remote coupling.
    a)    Web pages can be kept small.
    b)    Multiple CSS files enable presentation to be customised for different devices.
    c)    The Javascript code files which rarely change can be minified and cached locally by the Web browser.  This will speed up web applications substantially.