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.
Sunday, 24 March 2013
Monday, 11 March 2013
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.
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.
Thursday, 7 March 2013
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.
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.
Sunday, 3 March 2013
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.
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.
Friday, 1 March 2013
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.
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.
Subscribe to:
Posts (Atom)