Lamp

[NickFitz]

Do you think there might be a chance that some agents might not know that the acronym refers to those individual components?

I never knew, and I'm a developer. Although I don't work with PHP or Linux and never have, which might explain it.

Indeed. LAMP as an acronym involves a number of ambiguities: Linux really means Unixy systems, including Free BSD, Open BSD, and possibly OS X and Solaris too. Apache might be replaced with a lightweight high-performance server such as lighttpd, and either of them might be coupled with things like memcached which require additional knowledge. MySQL could be replaced with PostgreSQL. And, as has been pointed out, the P stands for either Perl or PHP, and some people even use it to mean Python; you don't want to get confused over those, as a competent PHP developer may have serious problems grocking a Perl script (obligatory dig at Perl: "A competent Perl developer would have serious problems grocking a Perl script ").

Generally speaking, I wouldn't trust an agent to have any grasp of what an acronym denotes at all. Given the fact that they usually think that all three-letter words must be acronyms or abbreviations ("Candidates must have experience with WEB technologies..." is one that always annoys me), imagine how confused they're going to get when an ETLA is thrown at them

[DieScum]

I love lamp.

[oversteer]

UWRL "Unix-based Webserver with Relational database and Scripting Language" doesn't quite have the same flow

[d000hg]

With my new-found LAMP knowledge, I can safely say that 'M' is the only part I don't dislike. And even then, I find the MySQL multi-engine approach very weird coming from Oracle/MSSQL background. Working in an ERD tool where I have to tick the "Inno" box when generating a DDL never feels comfortable. "Here's my DB structure" I want to say, "now generate the DDL".

Nothing against MySQL as a DB, it seems perfectly good. It just confuses me.

[NickFitz]

With my new-found LAMP knowledge, I can safely say that 'M' is the only part I don't dislike. And even then, I find the MySQL multi-engine approach very weird coming from Oracle/MSSQL background. Working in an ERD tool where I have to tick the "Inno" box when generating a DDL never feels comfortable. "Here's my DB structure" I want to say, "now generate the DDL".

Nothing against MySQL as a DB, it seems perfectly good. It just confuses me.

Go into the light... sorry, I meant lamp...

Pluggability of the underlying engine is a low-level feature; I've found that the average SQL Server dev doesn't even realise that such things are going on under the hood (although the good ones do). The majority of MySQL devs similarly stick with the defaults, but tend to have at least some idea of the options. (I've been asked about them on a phone interview, happily admitted that I couldn't remember as I just look these things up when necessary, and was then told that it wasn't important anyway and got the gig )

Still, there are some benefits that come therefrom; for example, I would assume that SQL Server offers something similar to the memory-resident engine (whatever it's called), but it's hidden a bit deeper. It sounds like your ERD tool is exposing too many details for what you need - if it doesn't have a set of sensible defaults and hide the unnecessary gubbins until you need it, a change request for the UI may be in order

Incidentally, if you have any MySQL data for which it's appropriate, the memory-resident storage engine offers blistering performance at the expense of a bit of configuration and a lot of memory. Maybe we should be using that for CUK's internal index tables; then TPD wouldn't bog things down any more