I was talking to another DonationCoder member recently about offering web services to people on the site, and it struck a cord with me that I'd like to share, that is relevant to Mewlo and coding in general.

If I have learned one lesson over and over again in my 7+ year experience with DonationCoder, it's to fear maintenance costs.

Now as a programmer, this should not be news to me -- the famous "Mythical Man Month" book talks about maintenance costs quite a bit, and how a substantial amount of time is spent maintaining code.

But different projects, attitudes, and lifestyles may put you in very different positions in terms of how much you have to worry about maintenance.  Sometimes we are in positions, by choice or fate, where we do not feel the pain and fear of maintenance issues directly or often.  Other times we find ourselves almost accidentally committed to supporting a system the requires near constant maintenance and care.

When we decided to upgrade the server that runs this website, we had the swell idea of pooling together money from people on the site, and then providing hosting services to our members.  We hosted websites, email, etc.  It's really not too much trouble to set up -- and we had a brilliant site administrator who was gung ho to set up any kind of custom setup people would want.  What I didn't anticipate was how much work would be involved in the maintenance of such things, and how difficult it would be to walk back from such an idea.  Whether it's worrying about operating system upgrades, dealing with outages, worrying about backups and failures, worrying about malicious users, etc.  It gives me cold sweats just thinking about it.

Some people are intuitively suspicious of doing anything -- adding any feature, because they have a voice in their head that tells them that any added feature or service brings with it the potential for maintenance headaches.

Now by nature I'm the kind of person inclined to add features to software if I think it might be a useful addition.  I tend not to worry too much about the increase in complexity of code to maintain, or the increased complexity of the configuration options.  But I'm increasingly aware of the price to be paid for such decisions -- a price in terms of complexity of configuration dialogs, and a price to be paid for the growth of the code base.

I'm not suggesting a course of action here -- just advocating for a very healthy fear of maintenance costs -- and of keeping such things always in the forefront of your design decisions.

---

I can say that such fears are foremost in my thoughts when thinking about the DonationCoder site and in thinking about the Mewlo web framework.  Over the last couple of years I've talked with people on DC about setting up a standalone "Self-Teaching Programming School" to replace the one that we have now on the site.  And talked and experimented with moving the site over to a proper content management solution.

In such discussions I find myself in the regular position of having to throw water on a proposed idea that, to the person suggesting it, seems like "not too much work to set up".  The problem of course is not that some new solution would be too much work to set up, but that the maintenance costs and risks associated with it are unbearable in the long term.

I'm particularly skeptical of solutions that involve connecting up multiple independent components made by different parties.  My experience is that the more moving parts, the more frequent the incompatibility problems come up.  And I've learned that even minor manual tasks (like merging in some changes into some source code) soon become painful and error prone when they have to be done over and over again, or after long delays when one has forgotten the steps needed.

And I'm especially skeptical about anything that requires specialty knowledge to do, because it means that the people involved in maintaining the system become indispensable.

That's another lesson I've learned -- avoid any solution where the steps required to maintain it are not codified into a document that can be passed on to a replacement maintenance person.

---

So let me wrap up by relating all of this to the Mewlo web framework. I think these lessons effect the framework in two very different ways..

The first way is in the design of Mewlo itself.  Clean, documented, maintainable code has to be the primary organizational principle for the entire system.  That's mostly common sense.

Slightly more controversial is my skepticism about the risks associated with interacting components maintained by different groups.  That has led me to a fairly broad classification of certain "modules" in Mewlo as being part of the core system.  Mewlo includes core "official" modules that many web frameworks delegate to unofficial, interacting (and often existing as multiple implementations written by different teams, and often abandoned).  These are things like user groups/messaging/profiles/etc.

But the second way in which Mewlo is driven by this concept of a healthy fear of maintenance is in the role Mewlo is trying to play on the web.  It would be fair to say that the primary mission of Mewlo is to ease the job of maintenance for creators of community-driven web services.

Supporting maintenance is exactly the thing that Mewlo is trying to do better than existing frameworks.  The goal is to implement all of the support structures that are key to maintaining a site and keeping it running smoothly.  This means extensive support for logging, upgrading, detecting and alerting on problems, monitoring operating conditions and detecting bad behavior or performance problems, and it means providing tools for moderators and administrators so that they can do their jobs easily.

You might say that Mewlo is designed for the Maintainers, and those who have a healthy fear of the cost of maintenance.

Mewlo Web Framework Blog Entry #1 - August 12, 2013

For my first entry in the Mewlo blog, it probably makes sense for me to discuss history and motivations.

I've been programming for 30+ years.  My "native" programming language is C++, and I'm an unabashed proponent of object-oriented programming.

As much as I enjoy traditional application/desktop coding, more and more I find that the large project ideas I come up with involve creating custom "community" web sites and services -- that is, services where users sign up and create accounts and profiles online, create and share projects and interact with one another.

The primary roadblock to creating a novel, custom community website, is building the "boring" foundational structures to support the site.  The user and group accounts, the infrastructure to deal with spammers and logging, moderators, performance issues, etc..  There is an absolutely astounding amount of foundational work required to build a non-trivial community website -- in fact this foundational code vastly exceeds the "custom" new code that one would write for most custom sites.

This foundational code is not just massive in size, but is full of difficult design decisions that effect efficiency, maintainability, and extensibility.  It's code that is frequently implemented poorly in custom sites precisely because its the "boring precursor" work, not the heart of the new interesting ideas being implemented.  It's code that gets reinvented over and over and over again on the web.

---

Now, there are a great many web "frameworks" and extensible content management systems in active development, and these frameworks are attempting to provide SOME of this common infrastructure.

Unfortunately, I have not found anything in existence which I have felt really good about using.

That is not to say that there aren't some truly excellent frameworks available.  The closest to my interests is probably Django, but Pyramid (also Python) is another strong choice.  Php also has some strong contenders, like Drupal (a content management system but also arguebly a web framework), CodeIgniter, and Yii (which I was so fond of that I used as the starting point for my first version of this project).  I'm less familiar with the Java, C#, and more esoteric frameworks.  And of course there is Ruby on Rails.

It's not that these frameworks aren't excellent -- it's that they have different philosophies and different goals.  For the most part they are designed to be general purpose web frameworks that could be used to produce any kind of web service.  And because of that, the user/group/moderator stuff does not get treated as a first-class concern.  Such features are relegated to multiple competing plugins and addons, which are often out of date and don't work well with each other.  Or they go too far in the other direction, and are primarily content management systems that are designed for non-coder administrators.

What I have in mind is a framework that is somewhere in between these all-purpose lower-level web frameworks on one end, and dedicated content management systems on the other.

---

Furthermore, my experience using frameworks and libraries has taught me that if you are coding something where the library can be used without modification, then it can be a huge time saver.  But as soon as you need to make changes to the framework/library to bend it to get it to do things it wasn't strictly designed for, you pay an enormous cost in terms of code maintenance effort and code clarity.

There is a real benefit to starting from scratch and building a framework with a singular vision and focus and consistency.  While the initial coding task is huge -- I believe there is a very real potential reward in terms of producing a framework that is better designed to solve this particular program -- providing the foundational infrastructure for custom user-driven community web services.

I also know from experience that even when there are some good existing tools, as a project matures it tends to find a useful niche and naturally differentiates itself from the alternatives.  I am confident that over time, a new web framework like the one I am describing would find a place for itself separate and apart from the other web frameworks.

Creating such a large project from scratch, and being able to control exactly how things are structures and organized, is one of the most enjoyable things a programmer can be involved in.  A good part of the motivation for working on this project is the pure enjoyment of that.

As a programming project -- this is a huge challenge and a giant project.  This is the second time I've actually started working on it.  The first time I started was about a year or so ago, under the name "Yumps", written in PHP.

For the last month or so I have restarted the project, this time in Python, under the name "Mewlo".  I don't love Python -- but I think it's currently the best choice for a large web framework (one of the aims of this project is to create not just the code base for this framework, but the object structures and API so that it could be ported to a new better language in a few years).

---

I have created a GIT open source code repository for the Mewlo project and have begun uploading code there (see this thread for more info and links).

What I would really LOVE to do is find some more serious Python coders who are interested in being part of the team creating this.  It's a huge project and it's going to need all the help it can get.

1. Newsletter Editorial

Greetings readers.  This is the first edition of our newsletter that is being sent out since we did a major pruning of the newsletter mailing list.  So if you're receiving this newsletter by email, we're glad to have you still with us!

In fact, if you are receiving this newsletter and haven't yet posted on our forum -- this is the perfect time for you to make a post and say hello!  We are a super friendly site and we always like hearing from new people, and you don't have to have any special skills or background to join our discussions.  Everyone is welcome.  If you look in section 2 of the newsletter, you're sure to find a forum thread that is perfect for your first post.

Anyway, We've got a slightly unusual newsletter for you this month.  While we normally focus on software, this month there seems to have been a flurry of security-related posts on the forum.  So we added a new section at the end of this month's newsletter collecting some of the more interesting security-related posts on forum.

We also have a ton of new beta updates to DC software to report.  If you use one of our programs there is a good chance we have a new beta version for you to try.  And if you have any feature requests for one of our programs, now is the time to post it.

I've also started posting about a big new programming project I've started on -- a new open source web framework called Mewlo.  You'll find a few posts about it listed in section 4 below.

And lastly, DC member Jibz has uploaded a new release his very popular bitmapped font "Dina", which now includes 6pt and 8pt versions (see Section 3 below).

Our friends over at MakeUseOf asked us to help spread the word about some very nice resources on their site, and I'm more than happy to do so.

The MakeUseOf.com site regularly posts unique, fun and cool DIY articles.  They were one of the first sites to do a real exploration of my Flipbook Printer software.

Anyway, they've put up a terrific collection of guides and cheat sheets on a huge variety of topics -- there's something for everyone there -- experts and beginners alike. Well worth a look.

http://www.makeuseof.com/pages

Note that all of these are free to download but makeuseof requires you to sign up to get a download key (similar to the way we do things).  The MakeUseOf homepage is also a daily blog that is definitely worth putting on your daily visit or rss watch list.

So I have had this very simple little gadget idea for years: A "Timestamper Disc"

And i cannot for the life of me understand why it doesn't exist yet.  It seems like it would make a perfect kickstarter project.

---

The Timestamper Disc:

The device would basically be like the watch face of a digital watch -- small, round, thin, powered by watch cell battery.

In its simplest form it would have a single "NOW" button on the front, and would simply display the date and a time that the button was last pressed.



If you had room you might display an additional line showing an natural approximation of the time since the last button push, like "13 days ago" or "6 months ago." If space was tight, you could have the button that cycled through the display of last pushed date, time, approximation, and hold button to trigger the NOW timestamp.

---

So, what would this device be used for?

You'd want to have several of these around the house -- you could use them to keep track of the last time you changed your water filter, the last time you took your medications, the last time the dog was walked, the last time you called your mother, the last time you used the exercise machine, the last time you cleaned your room, the last time the smoke detector batteries were changed, the last time you ate a snack, the time you woke up, the time you went to sleep, how long ago you put on the last coat of paint, when the lassagne was baked, etc.

You'd just place one of these Timestamping discs on or near the object you want to keep track of (velcro, magnet, band, etc.), and just hit the button when you use the object or perform the task.  Now whenever you come back to it, you can see how long it's been since you last performed the event.

They'd be cheap enough that people would buy them in packs of 5 or 10.  With watch cell batteries they would last decades.  You could probably use watch parts and manufacturing machinery.  It's basically a glorified simplified, half-watch.

---

Additional features:

If you wanted to get fancier, you could put a micro-usb port on it and let users connect to pc/mobile and get historical timestamps of every button press.. And i'm sure you could come up with additional ideas, like being able to set alarms to trigger automatically after the elapse of X amount of time since last press.

Thoughts?

From a few years back, but just read through Mixing Games and Applications -- slides from:

talk [was] on building an application that rescued princesses. The goal was to give interaction designers some insight into how game design might be applied to the domain of more utilitarian applications.

Took about half an hour to go through but was quite interesting.

I wonder if anyone who has seen this material has been inspired to apply some of the content to an existing app...