Technology

Network hickups

This morning we had some routing problems to our datacenter, so some users might have had problems reaching us between 7 a.m. and 9 a.m. EDT.
Seems like the backup routes were not all configured correctly... by now everything should be back to normal.

Sorry if you were affected by this outage, though this is something we couldn't prevent on our side.

 

Downtime of our 21Classes System

Due to some technical problems the 21Classes System was down for about 1 hour. We apologize for the inconvenience. The system has been restarted and is up running. In case you experience any problems, please contact our support team.
 

Some trouble at our datacenter

In case you were trying to access our systems last night around midnight (eastern time), you probably did receive an error message about a proxy error or an unreachable host. That's because our hoster did suddenly have problems with their uninterruptible power supplies at some of their racks, requiring them to power off some machines and repair the problem. While this lasted around 2 hours, it took our automated recovery processes another 2 hours to get all systems back up and running again.

We apologize for this inconvenience, though we hope with the new UPS at our datacenter there won't be such issues anymore.

 

Choosing a web development platform

When starting a new web project, one of the most important decisions to make is to choose the platform or programming language. It's not so much about how difficult a specific language is, yet there are more important issues you have to think about:

  • Available frameworks and libraries for the given task: do you have to develop everything from scratch, or are there frameworks and scripts supporting your task
  • Expected complexity: Is code of the selected language easy to maintain? For larger projects, is there support to create a basic component structure out of some modelling language such as UML? What documentation standards do exist?
  • Performance: interpreted languages tend to be slower in execution than compiled ones. Also, are the frameworks that are being used optimized with respect to performance? Are there any potential bottlenecks due to a specific implementation or framework?
  • Scalability: if the load increases, can you distribute it over additional servers, and if so, what overhead does this impose to your application?
  • Skilled workers: how large is the market of available programmers, and what is there average skill level? If you only have a few developers available, you'll probably have a problem if you run out of resources.
  • Security and robustness: How susceptible is the selected language against all sorts of attacks? How fast are security issues in the language and/or its compilers solved? How severe are such issues?

Our application is written in Java, and we had our reasons for choosing the framework we're using. Also, I've a strong Java background, so while speaking Java fluently, its slightly more difficult for me to assess potential complexity and security issues with PHP, for example. However, during the last couple of years, things have become different. PHP turned object-oriented for a couple of years now (we were already on our framework then, so please don't remind me quite some time has passed since), Ruby on Rails surfaced, D is in its early stages. Does it suffice to say "we've always used x, so we should stay with it"? No. Of course there are languages that are out of the question for us. Any .net related stuff is something we won't use, since we're running only Linux machines (Debian Etch right now). But for the others its difficult to assess. Ruby seems interesting, though many of its features (easy database scheme evolution, DRY principle, their MVC architecture) are already inherent to our framework. PHP seems interesting as well, though you have to watch the security issues more closely (see MOPB).

There is some research going on in that area. Recently, Lutz Prechelt published a comprehensive analysis where teams using Java, PHP and Perl had implemented solutions to a specific task within 30 hours at the Plat_Forms contest. I think the idea is great, though since this has been the first time ever the event took place, he himself identified some ideas that could be improved for future re-runs.

We'll keep an eye on this. And continue improving our existing framework. Maybe we should offer it to others some day....

 

Some insights into our technology

Many people have asked us what software we're using for running this blog service. So I'm writing a few very technical words about our system.
It is written completely in Java, yet we're currently not running it within a servlet container such as Tomcat. It's running as a stand-alone server compiled with the Java SE 6 Development Kit. The architecture is based on the model-view-controller pattern (MVC), like other frameworks such as Ruby on Rails are. The HTML template language we are using is our own, so we could do some performance optimization targeting specifically on our requirements. Some information about our template language is available right here.

We have a modular extension structure, which means we can develop plug-ins that can be loaded specifically for our customers, while still keeping the core system. This allows us to upgrade our main system and provide customers with the newest releases without further costs. So if you want to have your own installation on a dedicated server, be assured we won't charge you for providing updates. Of course you can stay out of the update process if you want to. Interested? Let us know!

There are already various modules available, starting from virus scanners for uploaded files, single-sign-on (SSO) connectors, up to session migration management for distributed installaionts on multiple servers. On our main installation here at 21publish.com, we are running many, but not all modules (SSO isn't required, for example).

On the database side, we can attach different sources - although it's quite some time that we have used our Oracle connector... We can even use a RAM-based store oder use a file for saving data - which we'd never recommend for a productive environment, of course.

For performance reasons, we're also using an Apache as a proxy server - maybe there are faster solutions, but we just love our Apache!

Guess I'll keep posting some tech updates over time, though if you've specific questions, just leave a comment.