Oh, a human definitely needs to be there for maintenance. You can't automate fixing up a screwup in the automation.

I just see no reason why maintenance windows have to be done at 1am. In today's world of redundancy and failover, there is just no reason for it. Every upgrade my team has done for as long as I can remember has been at 10am local time because we don't allow downtimes anyway. Why work at 1am?

Then stop using Oracle if you can't afford RAC/GoldenGate/TAF/whatever. Use what you can afford in order to architect a proper redundant system. Running a database on a single instance is malpractice in 2014.

Even our network upgrades we do in the middle of the workday. After all testing is done, we just take a whole datacenter down and upgrade it. Once it's back online, we do the next datacenter until it's all done.

There's really no reason in 2014 to do 1am maintenance.

I agree with this, but who does maintenance at 1am anymore? What's the point in it? Users are worldwide, and 1am in the US prime business hours in Asia, so why bother patching/upgrading in the middle of the night?

I haven't done a late-night maintenance in at least a decade. It's all about rolling upgrades. Any problems? Rollback. Need to upgrade infrastructure? Take the entire datacenter offline and serve from your other datacenters. Every single upgrade I've done for as long as I can remember has been at 10am, which is the earliest I can get my lazy-ass junior devs to stumble into the office.

OP needs a process upgrade.

Jewish immigrants after WWII came here because they had nowhere else to go, not because they wanted the hassle of moving to a country on the other side of the world where they didn't speak the language, didn't know anybody, etc. Their homes had been taken when they were transferred to death camps, and very few countries were willing to take them in. They seem to have turned out OK, though.

And less cooking liquid vs. non-pressurized applications since very little steam is lost once the cooker as achieved pressure. Once the desired pressure is reached, you turn the burner onto its lowest setting while the food cooks.

There are a few other things that add to pressure cooking's efficiency. This is from a person who uses a pressure cooker (me), not an expert in heat transfer nor any other discipline of physics.

1. Most pressure cooker applications other than soup are steaming applications, and since the pressure cooker traps the steam in, you don't use nearly as much liquid as you would in traditional cooking. Less liquid = less energy to heat it up.
2. Less loss of heat through the top. After a pressure cooker reaches the desired pressure, you actually turn the burner down to its lowest setting (or whatever the lowest setting is on your stove to maintain pressure--on my stove, it's the lowest).

That's all I can think of for now, but I will say that a pressure cooker is a neat cooking tool. Especially if you live in a hot climate, like I do. Most of my summer cooking is on the grill, naturally, but I use the pressure cooker a bit, too, and it doesn't heat my house up too badly.

That's just not true. I bought my pressure cooker after the Boston Marathon bombings, and nobody gave me a second look. Anyway, modern pressure cookers have multiple safety mechanisms so they don't go boom like your grandma's pressure cooker did.

I'd use jruby over grails. You get to code in ruby but run on the JVM. Best of both worlds.

Easier to find ruby developers than grails developers.

I agree that server code is moving toward being an API for a client-side presentation layer, but it's hard for me to recommend a specific JS framework at this point if OP wants the thing to stand the test of time. Angular is certainly the flavor of the month, but jquery was the next big thing not too long ago.

I also see some of my clients moving to Jade templates. It's in a bit of a state of flux.

I have not seen an applet at any of my clients in over a decade. Server side java, however, is very common.

I've never tried to maintain PHP before, but really, if you used Debian Stable or an Ubuntu LTS, you had trouble with PHP security patches? That surprises me.

Sounds like you need a better test suite.

Honestly, I think that most people who know Perl also know not to sign up to slog through some unknown Perl codebase. I've seen Perl code that is well-written and easy to understand, and then there's the other 90% of Perl code that looks like Q-bert cursing up a blue streak.

I've long-since removed Perl from my resume.

Like it or not, nonprofits can already have religious beliefs and opt out of the contraception mandate. So applying the same rules to for profit companies just makes sense. Why should a nonprofit Christian charity be able to hold religious beliefs, yet a for-profit Christian bookstore cannot? That doesn't make any sense.

Ugh, I hate magic builds. You know, the kind that only build on a single developer's workstation using code that's not pushed to the central git server. Unacceptable. The only solution is to insist that all software be buildable on a vanilla machine, but most cowboy devs don't like edicts too much.

The way to fix the cowboys is to give them a gift. A gift that takes away their goddamn high horse. That gift is an automated build tool that automatically builds and deploys their pushed changes to the dev environment. That way, their laziness can override their egos and they accept the tool, but in order to use the tool, they have to spend the extra few minutes scripting their builds properly and an extra few seconds pushing their code.

The effects at my current client have been awesome. No more, "Oh, Bob has to do a build because he's the only one who can do it." Or "only Frank has the latest changes." Or "Oh, the build script is this word doc that might be up to date, but then, it might not be." Or "Oh, the production code isn't quite committed to git yet. It's on Chuck's laptop."

Yuck.

It seems to work in most of the rest of the world.