Software Review: XAMPP

My first experience in 2010 configuring PHP on a Windows laptop was a bit of a nightmare. I not only had to run the executable file, I had to grapple with every line from php.ini. And that's not to mention running code and then testing database connections.

So image my relief years later when I discovered XAMPP, a package that would set up an Apache server, just like that.

After all the steps I'd taken to install PHP on that first laptop, not having to do it all over again, over and over, on the subsequent machines that I owned, was palpable. I soon became a big fan.

And today, I'm going to show my appreciation through this software review.

The Premise

XAMPP is basically a package comprising of an Apache server, and optionally, MySQL (recent versions use MariaDB instead). Thus if you need to run PHP or Perl quickly, this is a great solution. In fact, "XAMPP" is an acronym that stands for "Cross-platform Apache MySQL PHP Perl".

You double-click to run the installer. Subsequently, whenever you want to run PHP or Perl code, you start up the server.

The Aesthetics

Meh, it's orange and grey. The whole thing looks basic. Nothing to shout about from an artistic viewpoint, really. But at the same time, there's something about the simplicity of it all that's really attractive.

The Experience

Overall, using XAMPP was a pleasure. Compare this to the hassle of setting up and maintaining your own Apache server? Not even close. Come on.

The Interface

Starting this thing up is easy. Configuring it, also easy.

Gone are the days of hunting for the exact file. XAMPP opens that file up for you and gently warms you to be careful when changing it.

What I liked

XAMPP condenses the horribly complicated process of setting up an Apache server with a database, regardless of whether it's on a Windows or Mac platform, into a few simple steps. What's not to love? It's almost a bit too simple, if I'm being honest. But too simple is usually better than not simple enough.

Sensible conventions. Things like the default deployment path, port number, and such, aren't outlandish. I can get behind "htdocs" as a root path, even if I've been trained to recognize other conventions such as ASP.NET's "wwwroot".

Looks charmingly retro. Now, this could be seen as a negative, but this section is titled "what I liked", so here it is.

What I didn't

It would've been nice if some configurables were changeable through either a desktop or web interface rather than having to open up the config text file. On the other hand, the need to change these things doesn't come up all that often, so...

In the MacOS version, the executable is manager-osx which isn't really intuitive. 

Conclusion

If you need a quick-and-dirty Apache setup tool, who you gonna call? That's right - XAMPP! This tool has been around for the last  couple decades, and hasn't ever really gone out of fashion. That's because XAMPP doesn't pretend to be anything more than just an Apache server setup tool, and in that it's a godsend for PHP and Perl devs.

My Rating

8 / 10

An XAMPP-lary piece of work!
T___T

Three Great Virtues (Part 1/3)

Larry Wall, creator of Perl, is also the author of Programming Perl. In it, he said something that has inspired me profoundly as a web developer.

"We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris."

Now, there have been numerous interpretations of these virtues. But we're not going to bother with those; I'll be providing my own take on this. (What? Last time I checked, this is my blog.)

So the burning question - why are these virtues? In most other contexts, they would be considered sins. However, not just any lazy, impatient and arrogant SOB can be considered a great programmer. In fact, it takes a special kind of lazy, impatient and arrogant SOB to be a programmer at all. And I humbly submit that these three virtues are stated in that order for a good reason - they separate the adequate from the good, and the good from the great.

The Virtue of the Adequate Programmer - Laziness

If you remember nothing else about programming, remember this: minimum input, maximum output. All programming is about solving problems and automating tasks. Whatever fancy new gimmicks and technological advances the next twenty years throws at you, philosophically, programming does not change. This has been, is, and will always be; the one truth about programming. Whatever languages you use, whatever platform you swear undying loyalty to, it all goes back to this in the end - minimum input, maximum output.

The ultimate aim of any program is to make life easier. Because the awful alternative is more work. Not just more work - more boring and repetitive work which would be better done by machines.

Make the slaves do the work.

Programmers are always looking for the shortest, most direct route from Point A to Point B. They are always looking for a way to reduce that repetitive, monotonous task into a series of processes and outsourcing them for a dumb machine to execute. In other words, programmers are the taskmasters, and computers are the slaves. If that's not lazy, I don't know what is. The question is invariably "can this be automated?" followed by "how much can this be automated?".

Human beings get distracted. They get bored. They get frustrated. Machines don't. And therefore machines are the perfect candidates as slaves to carry out all that mindless work and in the process make life easier for the programmer. Notice how I said "make life easier" twice?

This is virtue numero uno for a good reason - not all programmers have the other two virtues (and therefore not all programmers are good, or great). But all programmers (and their cousins, the web developers) have to embrace this virtue at their core.

How not to be Lazy

Laziness comes in various forms. Not every form of laziness is admirable. If that laziness leads to more work down the road, it's counter-productive.

Copy-pasting code blindly without checking for relevance and room for improvement - that certainly qualifies. It's something I actively avoid.

If the code is going to be reused in the foreseeable future, invest a bit of time abstracting it into methods and subroutines so that it's easy to reuse and maintain. The Don't Repeat Yourself (DRY) principle is applicable here.

Sloppy code, lax security measures, incomplete test cases are all good examples, cases where the programmer couldn't be arsed to close that last loophole. Guilty as charged. Sometimes reality demands that I have to cut corners. It's not an excuse, but sometimes people have to choose between being a bad programmer who delivers, and being a great programmer who's out of a job.

In an age where many great programmers have paved the way for us by writing systems that automate even programming tasks, it's very easy to be lazy in the wrong way. Plenty of developers I know don't bother with the basics because that newfangled framework takes care of it for them. I'm guilty of this too. For instance, garbage collection and memory management is not exactly something I like to concern myself with - though in my defence, as a web developer, my priorities lie elsewhere.

Next

We examine Impatience.

So you want to be a Web Developer? (Part 2/4)

In the last segment, we discussed the front-end technologies of web development, and the things you'll need to know as a web developer. However, don't take it as an exhaustive list. Even barring the fact that technology changes - and is changing even as we speak - I'm fairly sure I missed out certain things. It's actually pretty hard to get everything. Yes, if you want to be a web developer, you'll need to know that many things, and more, on the front-end.

Intimidated? Don't be. You ain't seen nothing yet. We're talking about back-end technologies next.

Back-end

By back-end technologies, I mean server-side stuff. Server configuration and server-side scripting.

However, while configuration is important, one could actually scrape by without it unless you're in an environment where you have to take charge of your own server. Otherwise, this is pretty much the province of your vendor.

For server-side scripting, there are tons of scripting languages out there, each with their own quirks and preferred operating systems and databases as complements. Do your research. Some of them are proprietary and require licenses.

Just to list a few...

ASP.NET (http://www.asp.net/)
PHP (http://php.net/)
Python (https://www.python.org/)
Ruby (https://www.ruby-lang.org/en/)
Coldfusion (http://www.adobe.com/products/coldfusion-family.html)
JSP (http://www.oracle.com/technetwork/java/javaee/jsp/index.html)
Perl (https://www.perl.org/)

For a more complete list, see this link. (http://en.wikipedia.org/wiki/Scripting_language)

(Yes, I'm aware that ASP.NET is a framework and not a scripting language per se. This is for the layman, so bear with me.)

Pick one of these and get intimately familiar with it. And once you've reached a certain level of proficiency with it, pick up a second one. A third, if you're so inclined, but as a benchmark, most web developers know at least two.

What you must know

Regardless of what languages you end up learning, the following are a must. As with JavaScript, you'll need to know the following:
- Data types.
- Operators.
- Number and date formatting.
- Arrays.
- Programming constructs, ie. For, While, If-Else, etc.

And these as well:
- Database connections and CRUD (Create, Read, Update, Delete) functions.
- Input sanitization.
- File handling.
- GET and POST.
- Sessions and cookies.

AJAX

If you're good with your JavaScript and have picked up at least one back-end scripting language, you'll want to combine these skills to produce a totally awesome package known as AJAX. To put it simply, with AJAX you can leverage on your JavaScript skills to interface with your back-end scripting language, to produce wonders on screen.

More on AJAX (http://en.wikipedia.org/wiki/Ajax_(programming))

Good-to-haves

Again, these are optional. Companies are veering towards frameworks and IDEs, but if you haven't a decent foundation in the basics, forget about it. You don't want to be one of those developers who's totally crippled without an framework.

PHP Frameworks such as CodeIgniter, Symfony, CakePHP, Zend

Python Frameworks such as Django and Pyramid.

Ruby Frameworks such as Ruby On Rails.

For a more complete list, check out this link! (http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks)

What are my career options?

With just back-end scripting? Not good. You'll forever play second-fiddle to software developers who are the "actual" programmers. And front-end web developers are simply more highly valued. The ability to make things look pretty leverages on artistic talent, which isn't something that can simply be learned. On the other hand, programming and scripting is about logic. Anyone with an average IQ and enough interest can pick it up.

No one flourishes on back-end web scripting alone. Without databases and the front-end portion of web development, you're screwed.

Next

We're going to go even further back-end, and talk about databases.