A Web-Based Lunch Ordering System
Maybe this article should be entitled “How I Discovered Python and Ditched Everything Else”, instead. I have always wanted to write web-based applications but somehow found that getting started was quite intimidating. So, having procrastinated for years, I finally got around to writing my first application. My work required an intra-office application for which some values needed prompting on a web page. These values are sent to a CGI script, cross-verified via an SQL database, dispatched to a waiting process via sockets, and the results sent back to the web page.
By luck, I stumbled upon a scripting language called Python. I was reading a recent issue of Linux Journal (December 1999), in which they interviewed Eric Raymond, who mentioned that he now programs only in Python. At that point, I was a day into implementing the above system in Perl and was not quite finished. If Python was good enough for Eric, it was worth a try.
Well, I finished what I wanted to do in just over two hours. This was using a language that I had not heard of two hours earlier. At the risk of losing my professional advantage, I thought I would share with others how easy Python is to use, especially to do CGI (and almost everything else). As the above application would be too technical and boring to actually work through (and I'd probably get sued by my employers), I've decided to work through another, much more interesting exercise.
Work being situated in a semi-remote location (culinary-wise, except for the place next door, which has excellent food but is a bit expensive to eat lunch at every day), take-out lunch was organised to be delivered to us once a week. Each participant took turns organised the lunch orders. Being spread out over three floors, it was quite a chore, and no one looked forward to doing it. A web-based ordering system seemed to me the obvious solution but not having done any CGI programming before, it seemed quite overwhelming. The others did not seem to care. But writing CGI web systems can be quite simple, especially when one can do it using Python. (Okay, Perl gurus may disagree, but that's the whole point, i.e., a Perl guru versus a Python novice!)
I knew roughly how I wanted it structured. There'd be a web page with a pull-down list with the restaurant menu, and, by clicking on a submit button, an e-mail with the person</#146>s order would be sent to the nominated lunch organiser.
Based on hearsay and some cursory research on the Net, I decided to use the following tools:
Python for the server side
Apache for the web server, which is distributed with Linux (well, it was with my copy of Red Hat Linux 6.2); there is also a Windows version, too, if one is so inclined
Linux for the web server OS
In designing the web pages, I decided to keep it fairly simple: a pull-down box with some radio buttons (see Figure 1).
I could have used some HTML editor but decided that I could not handle learning another new package, so I did it by hand. Since what I wanted to do wasn't complicated, the by-hand method proved sufficient.
It was easy to install the web server using Linux. When I was installing Linux, the option to install Apache was ticked. When I typed in localhost as the URL to Netscape, it displayed the Apache page with the message that if I saw that page, everything was A-Okay! Whoo-hooo... so far so good. (See http://www.apache.org/ for more details). You'll probably need to be root (the superuser) to do the install.
The most tricky lines would be the ON-SUBMIT statement:
<FORM NAME="order" onSubmit="return Validate();" ACTION="http://localhost/cgi-bin/lunch.cgi" METHOD="POST">
There are two ways a web page can communicate with a CGI script: GET and POST. In a nutshell, GET sends the information as part of the URL (i.e., you might have seen some URLs which resemble http://localhost/script.cgi?param1=value1¶m2=value2 in your surfing of the Internet). When POST is used, the form information is sent via the standard input, i.e., the CGI script needs to read in standard input, and then parse the input separate out the various parameters.
It is generally accepted that POST is better (more robust, not limited by the maximum character limit of shell used). The methods used to extract the data differ according to whether POST or GET is used, but Python hides this from you (which is good).
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
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