vroombaprime

Everything you said matches my experiences - the complexity has to be watched closely, but otherwise it's a huge boon.

The custom tasks are never reusable - they are specific to that one build. If they ARE reusable they become gradle plugins, same as in maven.

Effort of banging out a custom task to make a tar in a particular way and get it published: gradle=a few lines of groovy, maven=a full plugin in java?

To be fair my maven experience is the lowest of all (between gradle/ant/make/maven), but I was being honest in that I would never want to go back to maven (or ant) - I get more things done faster in gradle.

What MrBuddyCasino mentioned about mediocre teams though, that is a real risk. I'd nominate one or two skilled people to create and maintain it, but be sure to crosstrain and use comments liberally. The initial learning curve on gradle can be brutal for complex projects.

Things I love having in gradle:

* custom tasks AND up-to-date checks for them (for when you invariably need special tasks like custom generated code, filtering only some resources in a certain way, calling other build systems like grunt/gulp, etc)

* up-to-date checks in general

* better task exclusions

* better dependency version resolution abilities, including custom strategies

* groovy syntax

Things I think maven does better that matter to me:

* classifier handling (it is really frustrating gradle still has a lot of messed up handling of them)

* way less magic is possible in the buildscript - makes it easier to trace through

End result: I could never go back to maven, every single project I've worked on has desired custom tasks and maven just makes it painful every step of the way. The only thing I worry about in gradle is making things easy to understand so someone else can follow behind - can't use too much magic.

General case (if you are at a startup this doesn't apply): Getting a raise and promotion are different things, though sometimes promotions happen at "raise time" (yearly review cycle). There are also "out-of-cycle" raises but those are generally for special cases where you need market adjustments or are a star performer.

You _need_ to be getting a raise every 12 months just to keep up with inflation. If the company is doing fine and you are a top-50% performing employee you should be getting inflation+extra - if not, that is a bad sign. The 'extra' seems to vary a lot by industry, I've seen 1-10% from friends in other industries.

We're talking about yearly review cycles here, so when it's approaching that time you need to be noting all the concrete work you've done, why it was great, and why you need to be in the "above/way-above average" raise bucket. You need to be managing your manager ahead of time so they think well of you and have already allotted a nice raise to you in the spreadsheet. Your negotiation is in the prep work with your manager: generally once the review happens things are already in motion and not much will change course.

This would make a lot of sense. I would /never/ make a build using maven again, but having maven central around is a huge plus for the jvm ecosystem and I'm happy it survives. (plus lots of people continue to make new builds with maven and legacy maven builds will be around basically forever)

"Our capacity to cause harm is a tiny fraction of that of a car."

By rolling lights/stops you're making it harder for cars to notice and avoid you, making it more dangerous for yourself. I hope you don't find out that truth, though.

What is reliable email worth to you though? $40/yr is a pittance for something I use every day...the analysis is harder when you have more data though, like you say.

You guys do a great job with HN moderation and I've always been curious what ratio of mods:numComments is sustainable and still keep quality high and mods not burned out - do you think HN is a good datapoint or just special?

Good luck getting email to work with that setup though.

I'll be the first to lament the spread of javascript, SPAs, and the huge hit to accessibility that the web has taken over the years.

None of that changes that js adds incredible power to what webpages can do and there is zero chance of rolling back browser-delivered applications at this point.

I also don't understand why you think html+css doesn't have the same fundamental 'code execution' flaw - you're accepting unseen input from a remote source and feeding it into an execution engine which will have exploits - whether that's css or html or js or xml or *.

Back to your question though: yes, 98% of web users want remote code execution on because they want spotify, facebook, and youtube to work. They would be upset if they even had to manually go in and enable it. And I'm not even sure you could make a quality version of those sites without js.

Browsers/webapps have only become this crazily successful because they allow seamless delivery of applications to run locally. I haven't seen anything to build "code-less" apps that can implement the complex features people want and isn't a complete nightmare to build and maintain. Until then everything you're talking about is just a pipe dream.

You can still make the apps you're talking about with html+css and enforce js=off in your user browsers, but there is a reason no one wants to do that these days.

And unless I'm not mistaken, there have been plenty of exploitable bugs in the core rendering engines that involve only html/css, so your utopian world STILL depends on a secure sandbox.

Funny you mention airbnb and uber, two of the worst offenders that I avoid because they won't follow the rules. You are 100% correct on the punishments not having impact for the winners, a scaling system of some sort is probably needed and smarter people than I are needed to figure it out. It's also frustrating because the end goal - in uber's case, I can't stand 99% of taxi services and they deserve to lose business even in locations the regulation isn't an outright racket - is noble.

Zenefits _knew_ they were breaking the licensing laws and had a huge number of violations. It wasn't accidental, which would a totally different discussion.

No group I've talked with has any concern for being sued over implementing java applications. The actual concerns are mainly whether oracle will continue supporting the ecosystem - security and features.

Naughtiness, rule bending, finding loopholes...there is a lot of gray area that we can all debate endlessly about.

Likely the automated test software they made falls in that area - and isn't what concerned me personally.

Willingly using unlicensed or wrong-state-licensed brokers though? Lobby for reciprocal/no licensing, work on a study course to make time-to-license faster, or just, you know...get your people licensed. As a business you follow laws even if you don't like them. Your hand waving an acceptance of fraud by zenefits - when they could and should have been in compliance - seems very worship-y and disruptors-know-best.

Regardless of how true that is or isn't, a business built on breaking the law is not ok. 59nadir is right, you can build a great product while following the rules. Disruption is awesome, but 'disruption' is not - and it worries me how often the latter gets unabashed praise.