Sun has been pushing Java as a server-side solution for several years now, and J2EE (Java 2, Enterprise Edition) is the umbrella for a variety of technologies that are meant to help developers create such solutions. Servlets are classes that execute code on a server; JavaServer Pages (JSPs) are Java/HTML templates that are compiled into servlets on the fly. JDBC allows you to access the database, and Enterprise JavaBeans provide you with transactions and automatic relational-to-object mapping. Entering the world of Java requires learning a huge number of acronyms and technologies, as well as learning the various versions for different standards.
I've been working with Java at various times since it was first released, and on nearly every occasion, I find myself wanting to get excited about it but being unable to do so. Java isn't bad, per se, and the different technologies it brings to the table are all rather impressive. Servlets are easy to write; JSPs (and especially the custom tags you can create for JSPs) are a mature and impressive templating system, and JDBC provides everything you would ever want in a database interface. And although EJB is undoubtedly overkill for most projects, it is extremely useful for the big enterprise development groups that Sun is targeting. In addition, multiple implementations, including fine open-source application servers and tools, are impressive and encouraging.
Indeed, Java seems to be the “big company” of the web development world. It gets things done reliably; it has an enormous array of talent at its disposal and follows a huge number of standards; oodles of development tools are available, and a lot of people are using Java. But the overhead associated with Java projects is too large for my liking. Simply learning which version of which standard goes with which version of which Jakarta subproject can take a fairly long time. Just as it's typically more fun to work at a small company than a large one, I find it more interesting to program in Perl or Python than in Java.
Moreover, J2EE suffers from problems similar to those I described with mod_perl and Mason, namely the fact that it's purely infrastructure, without any attention paid to built-in applications. Developers can create amazing things but must reinvent the wheel for each project.
Perhaps my favorite part of the Java world is the attention to maintainable and reliable software. A fair number of testing and development tools, such as Ant, Cactus, JUnit and log4j make it possible (and even relatively straightforward) for programmers to create and manage comprehensive testing of software before it is released.
So, is Java a good choice for web development? I would argue that the larger your project, the more seriously you should consider Java. But for the typical basic web application that small shops work on, the overhead associated with development is too great to ignore.
Zope is clear proof that open-source software does more than imitate its proprietary competition. Zope combines an object database with a multiprotocol server, hooking them together with a rich set of objects and a slick web-based management interface. Zope is innovative, clever, a pleasure to work with and one of the rare open-source projects designed with end users, not just hackers, in mind. Graphic designers love to hear that they can revert to any previous version of a document by using the undo feature in the web-based management interface.
Zope has a number of programming interfaces, each of which trades off simplicity for power. You can create simple DTML templates and Python scripts, use the fascinating ZPT templates that completely separate programs from the display logic, or you can go all the way and create a new Zope product. Zope products are where the real power is, and because each product is a class, you can create multiple instances of your product at different URLs. Because objects inherit via the URL hierarchy (acquisition) in addition to their native object hierarchy, the permissions, behavior or look and feel of a product instance can vary according to its URL.
So far, it sounds like Zope is the best thing that happened to the Web since HTTP. And indeed, the growing number of Zope hackers means a large number of products are available for free download, as well as a growing number of commercial products that use Zope as their underlying infrastructure.
However, Zope has a few problems, the first and biggest one being that the learning curve can be rather steep. Even if you're an experienced web developer, Zope requires that you re-learn nearly all of the concepts from scratch, changing almost all of the habits you've acquired over the years. This isn't necessarily a bad thing, as Zope implements it so well, but it can be a surprise and a reason to be wary, simply because using Zope inevitably will slow things down during the initial startup period.
The other issue I have with Zope is its object database. Object databases historically have had a lot of problems, and ZODB appears to be bucking that trend nicely. At the same time, relational databases are still pretty standard, and people expect (and often need) to work with them. In theory, this isn't a problem. Zope's built-in ZSQL methods allow you to do fascinating things with relational database queries without thinking very hard. The problem then is that your data is split across two different locations: ZODB and your relational database. I like to keep all of my data in one central location, which means this split can frustrate me somewhat.
There is also the issue of speed. Zope's sophisticated permissions and acquisition mechanism is probably faster than you or I could implement on our own, but it still can be relatively sluggish. The official Zope solution for this problem is ZEO (Zope Enterprise Objects), which allows multiple Zope servers to access a single object database. This apparently scales to one million hits per day, which is more than adequate for most of the sites I work on. But exceptionally large sites may need to worry about how quickly Zope operates or alternatively, consider investing in some high-end hardware for the central ZODB server.
Finally, Zope products tend to be relatively independent. The good news is that this allows developers to work in parallel, without slowing each other down. The bad news is that things are not as unified as they could be, with repeated functionality and a lack of coordination. This may be inevitable in an open-source project of this magnitude, but it can be frustrating at times.
Over the last year or two, Zope Corporation has been pushing the use of Zope for content management, rather than for application development. Of course, any decent content management system needs to be modified and reprogrammed for the needs of the customer, so the difference isn't that pronounced. Although Zope is not the only open-source content management system on the market, it is undoubtedly one of the most sophisticated, as well as one of the most mature.
In my own work, I pitch Zope to clients whose projects will involve a fair amount of tricky development, on those that require a relatively easy to use interface or those that require content management. I continue to be impressed by it and look forward to working with Zope quite a bit in the years to come.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide