PHP/LAMP developers, please chime in

Mods, please move this with my apologies if this is in the wrong forum.

Also, I don’t want this thread degenerating into a Microsoft/Linux fight, so please be mindful.

I’m a 14 year vet of the Microsoft asp/.net web application engineering field, and I believe that I am a competent developer and have progressed through the ranks to a quasi managerial role, but still have development duties.

However, I know almost nothing about Linux web development, namely LAMP development and would like to venture into it.

Over the past 10 years or so, I’ve tried a dozen or so flavors of Linux and barely got it past the initial functioning stage let alone get it to a usable development environment. It’s a very difficult OS to learn.

With that being said, can anyone give me an developer’s overview (sort of like an executive overview with many technical details) of a LAMP system and development in general?

Cross-trained C# and LAMP developers are a plus! Please let me know the hurdles you had to overcome in the differences.

All, please include the one resource that you have found to be the most helpful.

I ask because there’s a Management position that’s become available at a company that’s super close to home, only it’s a Linux/PHP shop. Do any of you think I could get up to management speed on this in a few months?

Thanks all in advance.

I’m not a professional, but I have a little experience in both worlds – enough, hopefully, to at least give you a very broad overview before somebody chimes in with more detail.

So you have an OS, a web server, a database, and a scripting language – LAMP.

The biggest thing to keep in mind, I think, is the overall LAMP philosophy: Open, modular and decentralized. There is no monolithic experience a la Microsoft, but instead a bunch of tools written by a bunch of different people. They try to adhere to standards where available and compatibility where possible, and for the most part this works. At first glance this may seem daunting and fragmented, but in day-to-day use there is ample support and documentation available. Most, if not all, of it is free. A plus for you is that many low-cost webhosts run on the LAMP stack and so many beginners’ guides are written for this environment; finding tutorials shouldn’t be hard at all.

You’re essentially trading ease of initial setup for more power down the line.

L:
The many flavors of Linux share the same underlying kernel and differ mostly in their GUI, bundled programs/drivers, security modifications, etc. For a web server, the particular distro doesn’t quite matter as much as for desktop users (except that you most likely want a distro with a reputation for security – FreeBSD, though not Linux, comes to mind). Most of the UNIX-like OSes function more or less the same when you use them on servers. There will be some differences in commands and available bundled programs, but they’re minor and easily overcome.

Keep in mind that your development environment does not necessarily have to mirror your web server environment. All my (hobbyist, admittedly amateurish) websites run on LAMP but I develop for them on Windows with Dreamweaver and UltraEdit because I find the interfaces much better than the Linux equivalents I’ve tried. OSX is another good choice thanks to its Unix underpinnings coupled with a usable GUI. Where necessary, you can SSH (remote login) to the server to pull up a command prompt (shell, in *NIX terms). You should know that LAMP is heavy on the command-line stuff and much of your administration will be done with configs file and not GUIs. Again, daunting at first but there is so much documentation available it’s easy to find very specific answers to very specific things.

In a web server environment, you’ll likely be dealing with file/user permissions often. Like Windows, *NIX lets you assign files and programs to specific users and/or groups.

That’s the thing to remember: For web development purposes, Linux is just a way to securely store files for the rest of the stack to pull up and serve. (Unless your company also runs its own data center, in which case somebody – maybe or maybe not you – will have to deal with Linux networking, which is a different deal altogether, what with firewall rules and load balancing and all).

A & M:
Beyond initial setup of your web server and database, I don’t think you’ll be spending much time here beyond tinkering with Apache config files (both on a serverwide level and a directory/file level) and maybe managing the occasional database issue… but for the most part, most of this should be abstracted to the P layer, below.

P:
PHP, Perl, Python, Ruby on Rails, whatever: You’ll be doing most of your work here. Scripting languages abound and you’re free to choose any one (or mix and match them). When a visitor views a page, Apache receives the request, scans the page for any scripting and sends it off to the relevant interpreter, which returns HTML back to Apache and the visitor’s browser.

This is the one area where, IMO, LAMP has the biggest advantage over Microsoft. So much prior work has already been done, with most of it available as open-source and free/low-cost software, that you can usually find an existing project and adapt it to your use. Your basic website can easily be run off of a content management system like Joomla, Drupal, or even Wordpress, with custom needs met through their extension systems – instead of writing the whole thing from scratch, you can often just write a module or plugin for a particular CMS. You don’t have to go this route, of course, and you’re always free to design something in-house from the ground up, but even then you can use other peoples’ code to supplement yours.

The downside is that you’ll have to learn a new language and syntax, but if you’re a programmer of 14 years, that probably won’t too big of an issue.

You might miss Visual Studio and .NET – Eclipse, one of the most popular IDEs, is nowhere as pretty or as easy to use – but you trade ease-of-use for security, expandability, and probably power. Again, there are so many open-source projects out there that you can freely use as long as you abide by their licensing, whether it’s just a code snippet that you wouldn’t have to write yourself or support for an entire scripting language in Eclipse.

As mentioned above, for simpler projects, you can also use Windows-based tools like Dreamweaver. But Dreamweaver is a web editor first and a coding environment second.


Anyway, that was just a very basic overview. Not very technical, but hopefully at enough to at least get you thinking about the specifics. Somebody more experienced will have to explain beyond that.

great! Thanks. Just what I needed. The actual coding of the page is the easy part. As well as learning a new syntax. 'Twas the same with the jump from asp 1.0 to .net and VBS to VB to C#. Although I’ve got to tell you, the person/people who wrote the PERL interpreter needs to be collectively put against the wall.

It’s the Linux configurations and manipulations that’s the daunting part. I almost threw the laptop out the window because the early versions Suse, Ubuntu, et al had issues with wireless, and the various package dependencies.

I’m going to apply for the position and see what comes. Thanks again.

It’s Perl.

And now I’m not going to help you. :stuck_out_tongue:

I’m glad that helped.

FYI, Linux on the desktop is an entirely different beast than Linux on the server.

For over a decade I’ve tried various Linux distros, looking for something to replace Windows. I’ve never found an acceptable experience.

[rant]
There will likely never be a “year of Linux on the desktop” unless Google or some other big company with a centralized, mainstream vision brings something that’s usable to your typical GUI-raised consumer. “Open and decentralized” almost never equals “easy to use” and the most successful open-source projects are the monolithic ones (Mozilla, OOo, BitTorrent, etc.) that aren’t as subject to fragmentation. Anyway, that’s a whole separate discussion.
[/rant]

The good news is that you don’t have to deal with any of this if you don’t want to. Forget your wireless woes and just stick with your present OS. You never have to touch Linux (beyond SSH) on your workstation if you don’t want to. Eclipse is available for Windows, and most of the other things you’ll be working with are plaintext configuration files that you can tinker with using any text editor you like. It is even possible to work on LAMP architectures with Microsoft tools like VS or Expression Studio, though that seems a bit silly with so many purpose-made suites available from companies that are vested in, not merely paying lip service to, LAMP.

On the other hand, Linux on the server is a very mature technology, leaps and bounds beyond the consumer desktop stuff, and it’s very, very good at what it’s supposed to do: Staying out of your way so your applications can shine.

Hmm, I should be a bit clearer: If it’s web development you’re primarily doing, the backend stuff shouldn’t matter as much… as long as there’s a separate sysop successfully taking care of network maintenance and such. I’m hoping that any LAMP company already in business would’ve taken care of wireless issues and such long before they think about developing web apps.

As to how much you have to know to be an effective manager, well, that I can’t tell you… except that you should at least know enough to not be another PHB :wink:

PHB!!!

Must.Control.Fist.Of.Death!

You weren’t kidding, were you?

OK, OK. I’ll tell you a bit about what I do.

I work a lot with Perl, though I use a lot of other tools as well. Perl is my favorite. It has a reputation as a “write-only” language, mostly because it has a lot of tricks that allow you to write very terse or obfuscated programs, and there is a history of weird experimental features that turned out to be mistakes but remain there for backwards compatibility. However, using a bit of common sense and good habits, it’s very easy to write clean, succinct, easy-to-maintain Perl code.

Perl is great because of CPAN, which contains roughly infinity open-source Perl distributions for accomplishing all sorts of tasks from interfacing with various C libraries to doing image manipulation to financial calculations to web programming to symbolic computation, and so on. That said, anybody can upload stuff to CPAN, and there’s a fair bit of crap there. So you have to be careful and look for recommendation about what you’re using. The nice thing about CPAN is that Perl comes with a fully-automated toolchain for installing and testing CPAN distributions, which helps ensure that CPAN stuff runs on the widest variety of platforms possible. (Seriously, Perl runs on something like 250 platforms; many of them OSes you’ve never heard of.)

Another thing I like about Perl is the relatively new Moose object system, which is built on top of Perl 5’s native OO system, and provides a number of very cool features, such as metaobjects and traits. (People have been building extensions to the rather limited but very flexible Perl object system for years, but Moose finally got this really right.)

Perl also has a proper implementation of lexical closures, which Python and PHP have yet to get right. (But I like Python a lot, despite this. PHP is a giant pile of shit, though.)

OK, so that’s why I like Perl a lot. Now, in terms of LAMP development, I write a lot of Perl-based web applications. These run on your typical Linux machines, and – sorry to say this – if you want to do any serious work on Linux you’re going to have to learn to type commands. Lots and lots of them. Once you start working in a shell, though, you pick stuff up pretty quickly. And the manual page for every command is easily accessible via ‘man foobar’.

One way to write LAMP-based web applications is with CGI, a very simple standard interface that web servers use to talk to external processes. Any program that can read environment variables and talk to STDIN and STDOUT can be a CGI program, so Perl can naturally do this very easily. The problem with this approach is that it causes the web server to spawn a new process for every incoming request, which is very inefficient. So I use an extension to Apache called mod_perl, which puts a persistently running Perl interpreter inside the Apache process, and gives your Perl programs complete access to the Apache API. This means you can write handlers for every phase of the Apache request cycle in Perl, including not just HTML-generation but the authentication, authorization, logging, URL-mapping, etc. phases as well. That also means all your Perl code is compiled once when Apache starts up and stays in memory so it can run repeatedly.

On the Perl side, the two most important tools I use for web development are the excellent DBIx::Class ORM for talking to databases, and the superb Template Toolkit for my display layers. There are also some popular web application frameworks, like Catalyst, although personally I don’t like Catalyst.