I no longer actively teach, but I continue to use Classmaker for all sorts of things. It's been used as a rudimentary cashbook, a holiday diary, for Cub and Scout planning and lately as a document management program in my electrical business. Today it's been successfully implemented as a data source for Microsoft Word's mail merge.
As an electrician, I'm required to supply every customer with a official document called a Certificate of Compliance (CoC) when doing electrical work. Until recently, these forms have been sold in triplicate books of twenty. A form was completed manually, whenever new electrical wiring was done on a job and a copy posted to the customer. The yellow copy of the triplicate had to be retained for three years.
The world moves on and now we are allowed to create electronic versions of this form, but they must be stored for seven years rather than three years. Furthermore the CoC has been renamed to a Compliance and Electrical Safety Certificate (CESC) and one must be supplied for all electrical work. The Electrical Workers Registration Board (EWRB) created a new version of the CESC using Adobe PDF, but their PDF made completing a CESC more onerous than the old manual method, because I had no way of automatically populating the PDF's fields and typing is much slower than writing.
I felt that unless this new electronic method could deliver the following benefits there was no point having it:
1. The form had to be much quicker to fill out than before and avoid any re-typing of existing information.
2. The form had to be easy to store and retrieve in future with no chance of it being misplaced or the information originally supplied on the form being changed accidentally.
3. The form had to be capable of being both emailed and printed.
4. The form template had to be able to be edited in future as the legislation and/or my business changed.
5. The form had to be able to go multi-page if the certified design for the installation was large.
The EWRB PDF form delivered on points 2 and 3, but failed miserably on points 1, 4 and 5.
Based on my previous efforts with Classmaker and Microsoft Word mail merge, it seemed to me that I could deliver on all five points above by doing the following:
1. Recreate the EWRB CESC form in Microsoft Word and pre-populate all the fields that will never change in the Word document, including my signature.
2. Use some of the fields in Classmaker as fields on the CESC form.
3. Print the Lesson Plan in Classmaker to HTML file.
4. Use mail merge to populate the CESC form with variable data from the HTML file.
5. Print the CESC form as a PDF.
6. Save the PDF back into Classmaker as a file attachment.
Once I decided to recreate the EWRB CESC form from scratch in Microsoft Word, the rest of the process proceeded quite smoothly and after a morning's work I had a presentable CESC.
Instead of typing out a CESC all I have to do is cut and paste a customer's address and contact details from GNUCash, my accounting package, into Classmaker. Nothing else is duplicated and due to my CESC form's ability to go multi-page the certified design description can be much more detailed than is possible on the EWRB PDF.
Once again Classmaker has proved to be a decent jack of all trades due to:
1. It's ability to write out it's reports underlying recordsets to HTML tables, one table per report. The HTML table retains CRLF's but removes all other formatting enabling me to cleanly separate data from presentation.
2. It's ability to store file attachments inside the database. I've only got to worry about backing up one Classmaker database file for my business. Everything I need is stored in there.
3. In the future, if I have to retrieve a CESC, it will be no problem. Either I type in any part of the customer's address as a search key inside Classmaker, or I export the whole lot to disk and use Windows Search to find what I want.
4. Having multiple users inside the same database with different subjects for each. Decided to create a new user from today for my electronic CESC's. Having many different users is no hardship, because Classmaker remembers the id of the last one you used and opens up with those settings when you restart it.
5. Classmaker's automatic information aging using it's calendar screens, you only see the current information you are working on - older information automatically disappears.
Classmaker - Lesson planning software
Sunday, 14 July 2013
Tuesday, 18 June 2013
Lost in Database
We have a problem Houston! I want to find a record inside my database, but I'm not exactly sure what that record is. The record I'm looking for might be plain text inside a table field, but it could also be in some other format eg. a spreadsheet. I'm afraid the best I can do to begin my search is to provide you with a two consecutive letters eg. "sa". From here we will narrow the search iteratively.
Faced with a problem like this most database systems can't cope. That's because all database types, regardless of their design, trade-off searchability vs maintainability. Let's look at this question for the three main database types.
BUT, through a happy coincidence with Classmaker, we get the best of both worlds, because when I implemented Classmaker I chose to structure the data hierarchically inside a relational database. Most planning packages use tags to aggregate similar records together. This produces a similar effect to a network database where there are multiple routes to the same record. I chose instead, to arrange my records hierarchically with Long Term plans above Unit plans above Lesson plans and Binary file attachments. This hierarchical structure means that while Classmaker can't slice and dice it's database like one with tags could, it was not a hard job to EXPORT the entire database structure to disk, because the directory structure on disk is hierarchical too. There's a further problem with tags. If you don't attach the correct tags to your records, you're NEVER going to locate them!
I have used Windows Search many times since I discovered it. It's great knowing that no matter what I load into Classmaker, I will always be able to retrieve it again. No more lost records. No more calls to Houston!
Faced with a problem like this most database systems can't cope. That's because all database types, regardless of their design, trade-off searchability vs maintainability. Let's look at this question for the three main database types.
Navigational (hierarchical and network)
Navigational databases comprise linked lists written to disk. They generally have a root entry point and from here searches are conducted down branches and a list of addresses is returned that meet the criteria. Used with indexes, searching navigational databases is very fast. Their major downfall is that they have no pre-defined structure, so cannot be searched using a computationally complete query language. Instead a domain specific query language must be created for each database.Object-oriented
Object-oriented databases are really navigational databases dressed in sheep's clothing. Their main point of difference from navigational databases, is that they can store any type of data because the instructions required to interpret that data are stored in the same object as the data. Consequently, object-oriented databases are very good at storing multi-media files. However, just like navigational databases, object-oriented databases cannot be searched using a computationally complete query language. They also grow very large quickly as the instructions required to interpret their data is replicated unnecessarily many times over in each object instance.Relational
Relational databases use a quite different approach to data storage than navigational and object-oriented databases. Instead of linked lists, relational databases use a collection of tables. The tables are not connected together directly as a linked list is. Instead, the linkage between tables is an indirect one, where the id field of one table is stored as a field in another table and referred to as a foreign key. The advantage that relational databases have over the other databases is that the query language used to join these tables (relations) together is computationally complete. That's why it's called SQL (STRUCTURED query language) folks! SQL is not a domain specific. It can be used on any relational database, regardless of it's design. Unfortunately for us, the table structure found in relational databases is not suited to binary data such as our spreadsheet, since SQL is optimised to traverse tables with fixed length fields.Summary
While navigational databases and object-oriented databases can return search results quickly, to do so they use domain specific query languages. In other words they trade-off maintainability for searchability. Conversely, relational databases are slower, but anyone can query them using SQL, their universal query language. Having SQL is a real bonus for maintainability, but it comes at the cost of not being suitable for manipulating binary data.Solution
How does any of this help me to find my lost record? Neither navigational databases nor relational databases are very promising. At face value, object-oriented databases look like they'll do the job, providing they have the correct code available to search through the spreadsheets stored inside them. The truth is they don't. It can be done, but we are back to that maintainability problem again.BUT, through a happy coincidence with Classmaker, we get the best of both worlds, because when I implemented Classmaker I chose to structure the data hierarchically inside a relational database. Most planning packages use tags to aggregate similar records together. This produces a similar effect to a network database where there are multiple routes to the same record. I chose instead, to arrange my records hierarchically with Long Term plans above Unit plans above Lesson plans and Binary file attachments. This hierarchical structure means that while Classmaker can't slice and dice it's database like one with tags could, it was not a hard job to EXPORT the entire database structure to disk, because the directory structure on disk is hierarchical too. There's a further problem with tags. If you don't attach the correct tags to your records, you're NEVER going to locate them!
Windows Search
Windows Search is an interesting facility. It comes with the IFilter plug-in. This is an API that lets third party binary file formats expose themselves to Windows Search for indexing. Using Windows Search we can look for all spreadsheets, or in fact, any file that contains the phrase "sa".Conclusion
Classmaker uses Windows Search indirectly to let you examine every record in it's database whether plain text or binary format for the phrase "sa". Simply export all Classmaker's data to your local Documents directory. Windows Search automatically indexes all files written there.I have used Windows Search many times since I discovered it. It's great knowing that no matter what I load into Classmaker, I will always be able to retrieve it again. No more lost records. No more calls to Houston!
Sunday, 26 May 2013
IsectMP
IsectMP is a middleware multiplexer written in ANSI C that uses blocking RPC's in a single threaded select loop. The goal of IsectMP is to solve the client/server concurrency problem using collections of identical processes rather than threads with the following constraints:
1. Keep the API as simple as possible to promote language agnosity.
2. Impose no record structure on the data being exchanged.
3. Have all data transfer move through a central broker (Isectd).
4. Be able to stop and start remote processes via Isectd.
1. IsectMP only wants to solve the Request/Response model. This is the classic client/server problem where you have a single static server and many clients that come and go.
2. IsectMP deliberately uses blocking I/O on a single thread in Isectd. It solves concurrency by breaking down responses from workers into a stream of discrete chunks which must be concatenated at their destination. Requests from clients can be chopped up too, but this is unusual when dealing with databases as requests are usually small while responses can be very large.
3. IsectMP deliberately forces all communication to pass through Isectd. While some may argue this is creating a bottleneck, the advantage of having a central broker is that administrators know the health of the entire application by querying Isectd's registers.
4. Isectd comes supplied with a command language that lets you adjust its state dynamically.
5. IsectMP comes supplied with a parent daemon (Execd) that can start child processes locally from an instruction sent remotely via Isectd.
It turns out there are lots of other open source libraries out there doing similar things, but they all have different goals in mind from IsectMP. I freely admit to only knowing IsectMP well, but from what I can see, if you stick with open source:
1. IsectMP is the only one that uses ANSI C and compiles on Windows without issue.
2. IsectMP deliberately uses a central broker. The others frequently try to avoid using a central broker.
3. IsectMP has the smallest API of any, just five function calls.
4. IsectMP comes supplied with its own console client that can configure and control the central broker remotely.
5. IsectMP's two daemons are tiny, the largest daemon weighs in at < 250kB including DLL's.
Certainly IsectMP has it's failings:
1. It is not asynchronous.
2. It will only cope with hundreds of clients, since each client gets it's own dedicated socket.
3. The only transport mechanism it can use is TCP.
4. It is single threaded.
5. It's API relies on a C struct which causes headaches when creating new language bindings (2021-08-22 This is no longer true. A lot of reworking to the internals of Isectd has been done since this post was written).
I would not attempt to use IsectMP for an enterprise size application, but for a department size application, IsectMP works very well indeed (2021-08-22 It also does a grand job acting as the middleware behind web sites).
1. Keep the API as simple as possible to promote language agnosity.
2. Impose no record structure on the data being exchanged.
3. Have all data transfer move through a central broker (Isectd).
4. Be able to stop and start remote processes via Isectd.
1. IsectMP only wants to solve the Request/Response model. This is the classic client/server problem where you have a single static server and many clients that come and go.
2. IsectMP deliberately uses blocking I/O on a single thread in Isectd. It solves concurrency by breaking down responses from workers into a stream of discrete chunks which must be concatenated at their destination. Requests from clients can be chopped up too, but this is unusual when dealing with databases as requests are usually small while responses can be very large.
3. IsectMP deliberately forces all communication to pass through Isectd. While some may argue this is creating a bottleneck, the advantage of having a central broker is that administrators know the health of the entire application by querying Isectd's registers.
4. Isectd comes supplied with a command language that lets you adjust its state dynamically.
5. IsectMP comes supplied with a parent daemon (Execd) that can start child processes locally from an instruction sent remotely via Isectd.
It turns out there are lots of other open source libraries out there doing similar things, but they all have different goals in mind from IsectMP. I freely admit to only knowing IsectMP well, but from what I can see, if you stick with open source:
1. IsectMP is the only one that uses ANSI C and compiles on Windows without issue.
2. IsectMP deliberately uses a central broker. The others frequently try to avoid using a central broker.
3. IsectMP has the smallest API of any, just five function calls.
4. IsectMP comes supplied with its own console client that can configure and control the central broker remotely.
5. IsectMP's two daemons are tiny, the largest daemon weighs in at < 250kB including DLL's.
Certainly IsectMP has it's failings:
1. It is not asynchronous.
2. It will only cope with hundreds of clients, since each client gets it's own dedicated socket.
3. The only transport mechanism it can use is TCP.
4. It is single threaded.
5. It's API relies on a C struct which causes headaches when creating new language bindings (2021-08-22 This is no longer true. A lot of reworking to the internals of Isectd has been done since this post was written).
I would not attempt to use IsectMP for an enterprise size application, but for a department size application, IsectMP works very well indeed (2021-08-22 It also does a grand job acting as the middleware behind web sites).
Tuesday, 30 April 2013
Spreadsheet madness
Today, a large business (X) accidentally emailed me all their clients' data inside a spreadsheet. This is not the first time this has happened in New Zealand. Recently EQC, a government department, emailed a spreadsheet containing thousands of clients claim records to one client.
Apparently, X sends spreadsheets routinely to it's staff for further manipulation. Why?
For X, I believe, it's because they've purchased a number of other smaller businesses recently and the small business units' systems are not integrated with X's centralised accounting system. The small businesses units aggregate their monthly figures into a spreadsheet which they then email to X's receivables department.
The problem X has, is that its small business units are aggregating their data too early in the process. As soon as data is aggregated it is at risk of being divulged. I contend that the solution to their problem is that the data aggregation should be delayed until just before it is posted to the centralised accounting system. In fact, I suspect there is no value to aggregating it at all. Most accounting systems require data to be keyed into them manually and I imagine X's accounting system is no different.
What X really needs, is for its small business units to be posting their individual transactions as they are created onto a searchable queue that can automatically be purged once the data is committed inside the accounting system.
X is partway there already since it's email system is already a queue. Problem is, that queue isn't secure and isn't visible to all its relevant staff. What they need is a single email address that multiple internal users can subscribe to, but not a message list, rather an issue list. There are plenty of these about - we usually call them bug tracking software. The one that I'm most familiar with is Roundup Issue Tracker. There are many others.
And what content gets posted to Roundup? The spreadsheet sent to me would be fine as long as it contained just one client's details, but I still don't like spreadsheets much, because they bundle data, business rules and presentation together in a single file. I would prefer instead to use a static Web browser application for the reasons outlined in my post called Real world Web browser development.
Apparently, X sends spreadsheets routinely to it's staff for further manipulation. Why?
For X, I believe, it's because they've purchased a number of other smaller businesses recently and the small business units' systems are not integrated with X's centralised accounting system. The small businesses units aggregate their monthly figures into a spreadsheet which they then email to X's receivables department.
The problem X has, is that its small business units are aggregating their data too early in the process. As soon as data is aggregated it is at risk of being divulged. I contend that the solution to their problem is that the data aggregation should be delayed until just before it is posted to the centralised accounting system. In fact, I suspect there is no value to aggregating it at all. Most accounting systems require data to be keyed into them manually and I imagine X's accounting system is no different.
What X really needs, is for its small business units to be posting their individual transactions as they are created onto a searchable queue that can automatically be purged once the data is committed inside the accounting system.
X is partway there already since it's email system is already a queue. Problem is, that queue isn't secure and isn't visible to all its relevant staff. What they need is a single email address that multiple internal users can subscribe to, but not a message list, rather an issue list. There are plenty of these about - we usually call them bug tracking software. The one that I'm most familiar with is Roundup Issue Tracker. There are many others.
And what content gets posted to Roundup? The spreadsheet sent to me would be fine as long as it contained just one client's details, but I still don't like spreadsheets much, because they bundle data, business rules and presentation together in a single file. I would prefer instead to use a static Web browser application for the reasons outlined in my post called Real world Web browser development.
Sunday, 24 March 2013
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.
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.
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.
Wednesday, 30 January 2013
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.
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.
Thursday, 3 January 2013
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.
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.
Subscribe to:
Posts (Atom)