Ajax is not a technical revolution, so much as a conceptual one, bringing with it new expectations from users and paradigms for developers. All of the technology behind Ajax has existed for several years, but it is only now that we are starting to take advantage of it in Web applications.
If you have been developing Web sites for any length of time, you probably have needed to create a login system. Such systems come in all shapes and sizes, and require different levels of security. For our example application, we assume that each user has a user name and password. Actually, as you will see, we don't care that much about the password; the key issue here is the user name, which must be unique.
The first thing to do is create a simple table in our database to keep track of users:
CREATE TABLE Users ( id SERIAL NOT NULL, username TEXT NOT NULL CHECK (username <> ''), password TEXT NOT NULL CHECK (password <> ''), email_address TEXT NOT NULL CHECK (email_address <> ''), PRIMARY KEY(id), UNIQUE(username) );
The above table, defined using PostgreSQL syntax, keeps track of our users for us. Every user has a unique numeric ID, stored in the id column. (The special SERIAL datatype in PostgreSQL ensures that each row we INSERT into the database will have a unique value for id.) For the purposes of this column, we ignore the security issues associated with storing passwords in plain text.
Next, we define three columns of type TEXT, which PostgreSQL uses to define limitless text fields. Each of these fields is also given an integrity check to ensure that the value can be neither blank nor NULL. We also define the username column to be UNIQUE.
Now, from the standpoint of data integrity, we already have done our jobs. We can be sure that no two users will have the same user name, that each e-mail address (that is, each person) is allowed to have more than one user name in the system, and that the user name, e-mail address and password cannot be blank. Everything else is just icing on the cake, right?
Well, yes—but only if we are willing to give our users database errors. Most of us would prefer to offer a softer landing to our users, telling them not only that (for example) their chosen user name already has been taken by someone else, but also shielding them from the errors that PostgreSQL displays.
This means our application is going to need to take the user's requested user name, check for it in the database, and then either display an error message (prompting the user to try again) or INSERT a new row in the database.
Here is a simple example of how we might do this in a Web page. I use simple CGI programs written in Perl for the server-side examples this month, in no small part because they tend to be simple to understand and try on any host. Listing 1 (register.html) shows the HTML form users will see when they want to register with the site. Listing 2 (register.pl) shows the CGI program that will accept the form contents, check the user name in the database and then produce a message in response. My assumption is that the form will be in the main Web document root directory, and the CGI program will be in the cgi-bin directory. Obviously, if you are using a server-side language, such as PHP, the two can exist side by side.
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!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Interview with Patrick Volkerding
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
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