Events are user interactions with their computer, such as a mouse click or key press.
In the good ol’ days, computers handled user interactions as input of batched data. The user fed a hunk of data in, the computer did something to that data, then produced the results. With the advent of interactive devices like the GUI interface, computers could display answers to computations onscreen. The input for these interactions are events caused by the user, which could be keystrokes, button clicks, or the position of the mouse pointer.
(see Event Handler).
Practical extraction and reporting language, or Perl, is a scripting language first created by Larry Wall to be used as duct tape for programming with the Unix operating system. Due to its immense power for handling piles of text and, consequently, as a common gateway interface (CGI) scripting language, Perl became very popular among server-side scripters. Perl has a large community of contributing programmers and, what’s more, costs nothing and is free to redistribute. These circumstances have helped Perl evolve from a scripting language used to generate server stats into a language many use for database administration. All along Perl has maintained its zaniness. Most Perl documentation reads as though written by early vaudeville comedians.
PHP is an open-source scripting language that is embedded alongside HTML to perform interactive functions, such as accessing database information. PHP is similar to Microsoft’s active server page technology, but is used primarily on Linux web servers (or Windows servers with add-on software). An HTML page that has PHP script usually has a “.php” extension. Visit Webmonkey’s Tutorial:PHP Tutorial for Beginners to learn how it works.
Most developers are probably familiar with Linux founder Linus Torvalds’ motto: “release early, release often.” The reason is quite simple: Shipping something useful is better than withholding that usefulness until it’s reached perfection.
Of course, there are exceptions. If you’re developing flight control software or a heart monitor interface, we sincerely hope you do not ship imperfect software. But when it comes to web applications, getting your software to the public is often more important than making sure it’s absolutely perfect.
The reason shipping a flawed version is often better than shipping nothing is summed up nicely by blogger Jeff Atwood, who recently wrote a post entitled, Version 1 Sucks, But Ship It Anyway.
As Atwood writes, “instead of spending three months fixing up this version in a sterile, isolated lab, you could be spending that same three month period listening to feedback from real live, honest-to-god, dedicated users of your software.”
The result in that scenario is that you end up with not the software as you dreamed it, but as users really want it. There’s actually a third sentence in Linus’ motto: “Release early. Release often. And listen to your customers.” And it’s impossible to listen to your customers if you don’t have any.
While it’s become something of a joke in Google’s hands, this is where the “beta” moniker serves a real purpose — to let users know that you have something, but it isn’t perfect.
The tradeoff for users is (or should be anyway) that they have some influence on the product’s future. In this scenario, “release early, release often” means your app gets feedback when you need it most — before it’s fully baked. The end result might not be your application as you imagined it — the internet is littered with web apps that started out as one thing but became quite another in the hands of users — but you’ll have delivered something people find useful. It might be hard to let go of your vision, but sometimes your users are smarter than you are.
As Atwood puts it, “it’s saner to let go and realize that when your software crashes on the rocky shore of the real world, disappointment is inevitable… but fixable!”