There's a considerable difference between how to administer a stack and how to architect a stack.
The latter is about guessing/testing/measuring what needs to be scaled and selecting how best to implement it so that it can scale (language, client-server protocol (e.g. JSON-RPC vs RESTFul or HTTP vs sockets), backend storage container(s)). This often is dictated by the business rules--the type of data, the semantics required of the data and transactions, and the use cases interacting with the data. The former is a matter of selecting and using toolsets to make the stack manageable and maintainable--deployment tools, update tools, backup strategies and tools, how high availability is achieved, and other logistical considerations (which webserver, which os, where/how it's hosted (vm, bare, docker, jailed), data location (san/local storage/db/distributed fs,memcache,reverse proxies), where/how/of what are logs captured, etc) In either case, there's enormous room for preference--even after deciding a working set of the above there is still enormous room for preference in the millions of little implementation details. You say your focus is on both--primarily on the admin, secondarily on the performance/coding. For admin, I'd say focus on the most common current setups. Teach them how to work with the main canned environments: bluehost, rackspace, amazon, hostgator, etc. Teach them how to translate between similar setups with common distros: centos, ubuntu, rh, debian. You don't have to do all of them, but get them used to knowing where to go to figure out the differences (man pages, google, IRC). Make sure they know what all the components are at a high level, and only delve into the parts that they'll deal with most often. E.g., take them through the entire process of creating a site for a new company from DNS registration, DNS records & hosting, creating and installing SSL certificates for HTTPS through setting up a webserver with a database. Then get picky about logging, ssh keys, (no ftp!!!), troubleshooting, backups, update procedures (what happens when you have two webservers in DNS RR and only update one?, etc). Another good exercise might be having them move a complete, working site from one hosting provider to another--lots of details can be missed. Performance/coding is such a large topic I'm not sure how you could condense it in any reasonable way. Teaching how to be resourceful is probably more valuable than trying to teach the answers up front. Give them a vm that is misbehaving and have them figure out why and how to fix it. Progress it to more and more obscure problems--troubleshooting skill, experience, and ability are invaluable. Solutions can include changing the code, changing a query, or changing the stack setup (tuning a db, indexing a column, changing the # file descriptors, etc). Knowing what tools or how to look for more tools is useful (e.g. htop, mytop, dstat, lsof, etc.) PHP is not dying. It's very large and everywhere. It's a terrible language that makes it very easy for newcomers to learn very bad habits and bad ways to do things. However, it's very easy to be productive in because it's an easy language to use and is fairly well documented. I wouldn't spend a lot of time on it because they can learn it on their own later when they actually need, so long as they learn to be resourceful. If you focus on a better language such as python, they will learn better programming skills and that will translate to writing better PHP once they do use PHP. Point them at sites/articles that talk about better ways to use PHP for when they do need it. MySQL vs Maria vs Percona doesn't really matter. They all implement 99.9% the same exact SQL flavor and features. They will also require nearly the same administration. Converting from one to the other might be a good exercise though. You may also want to spend some time with MS SQL since they very likely will encounter it in the workforce. I don't know if I'd recommend nodejs--while it is gaining some popularity it is not most people's first choice for backend services. Javascript, however, is a must if they are learning to be a full stack developer--and that combined with all the other stuff you'll teach them will make learning nodejs for them later a simple exercise. Ruby is turning into a one-trick pony--ruby with rails for web apps. It hasn't seen much growth outside of that. There may be a lot of existing codebases using ruby+rails, but I don't see it as becoming an industry leader any more--I think python has taken the lead over ruby and java is still holding strong. Basic Perl would be excellent if the focus really is on admin tasks since a majority of admins use perl for maintenance scripts. There is also a ginormous body of perl code used in every corner of programming purpose that they may encounter and knowing the basics of perl, perl packages/modules, cpan, etc would give them a leg up. A crash course in java would help, especially class paths, build tools (ant, etc), and configuring/administering/tuning the servers (a big topic by itself, let alone the language). If they haven't learned regexes yet that's an absolute must. Regex with grep, egrep, perl -pie, awk are vastly transferable skills. Teach them how to search stackoverflow, project/library/language/tool-specific bug databases, and how to file good bug reports. Teach them how to ask good questions in forums and on IRC. I'm not sure how relevant any of the above is since I don't know in detail what the course prerequisites would have them ready for, nor how much of what you want them to be prepared for by just one course. About the best advice I can give to anyone in any school is that learning to be resourceful and self-taught is the most important thing in any technology job these days. Technology moves so quickly that by the time anyone has a degree in their hand they are already behind in something. Learning on the job is not an option in these fields. Very frequently a job *is* to learn and use something brand new. If they don't enjoy the learning process then that may be a big red flag that it's a poor fit of a career path for them--it's not something they can learn and then be done and set for the rest of their career. I hope you find something useful in my ramblings. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
