itsbruce

Shun is not archaic, Graham is entirely wrong about that. You can find it in Sun newspaper headlines and articles. collinsdictionary.com/dictionary/english/shun It's less commonly used than it was, but if you can find it in the Sun then a large part of the U.K. population are not going to blink when you use it. @JanusBahsJacquet the Sun newspaper is not grandiloquent. You're making incorrect assumptions abut a simple Anglo Saxon word.

Well, the code is fugly and a dictionary would be an improvement. But he wants the suggested improvement (as yet unwritten) approved, not the existing code reviewed. So it's an SO or Programmers question

@Mast CR is primarily a knowledge-sharing thing. But it's entirely dependent on team culture. Funnily, the Operations people had no interest in the team culture.

What they don't seem to understand is that CR does nothing, in itself, to assure code quality. That needs a whole culture of which CR is just one minor part.

Making the auditable CR meaningless even if anybody checked

First thing I found when I got here was that most delivery teams were simply working around it and batching up everything to submit to Gerrit

The operations dept on this project insisted on code review and specified the tool (Gerrit) because they wanted CR to have an audit trail. Having done that, they never audited it nor set up any process for such an audit.

@MathiasEttinger But pre-release or build metadata labels are still just one-offs in a single history. These idiots are forking their code, once per environment.

Anyway, that's enough off-topic ranting from me.

Next up he was talking about their Ansible code. So they don't know how to manage the configuration of their configuration management tool.

There are many ironies there. Starting with the fact they don't know what "semantic" means (which is so meta it might recur infinitely).

Took me a while to pick my jaw up off the floor and even longer to form a reply which was polite while also expressing how stupid that is.

Said to me by a senior "devops" engineer on this project: "We use semantic versioning: major number, minor number, patch number - and the name of the environment we're going to deploy to."

Monking

@Pimgd Reference equality triumphs again. Dark Lord that it is.

@DanPantry Not the Jar Jar Binks candy tongue?

@DanPantry More than one way to parse that

Some OpenBSD guys used to run rt.fm - which always made me laugh - but it went inactive over a decade ago.

Friend of mine registered dot.at so he could have the email address [email protected]

@DanPantry Depends. Do you want to register dontblame or eie as a domain?

Amusingly, the only good tests for their code were the ones written by the devops automation engineers seconded to them ;-) Who are my responsibility.

@skiwi The code does things, but of course we can have no confidence in how well or whether it's the right thing

@Mast Definitely. I've been complaining about single agency teams since I got here. Causes all kinds of problems beyond fraud. But the fraud is spectacular.

@skiwi Quite. But a chunk of blame also goes to the recruiting process here. It's been clear form a while that that agency's people were substandard. We're all on a week's notice here, so nobody that shit should be retained.

Almost everybody here is a contractor, but those teams were entirely from one agency, including the scrum masters and the like. So loads of ass-covering to try and hide the fact that none of them know agile, let alone basic competency.

Over a dozen people. Teams were too big in the first place.

Also, tests which targeted spring containers and not the code, code copied and pasted out of app code into tests... unbelievable.

Some tests just consisted of system.out.println("Break me")

Interesting morning, here. Two whole delivery teams have been suspended for not knowing how to write tests and faking it.

Monking

And that's waaaay too much language nit-picking for this chat room. ;)

But you have to be careful with your code to see the real benefits of that. Particularly wrt closures. Groovy closures are dynamically scoped (boo) which was a hack to make it easier to write builders (which would otherwise have required extra language features). But that means idiomatic use of closures seriously undermines the potential benefits of static compilation.

Groovy performance has improved a lot with Java7 and with static compilation. which also helps Grails performance some.

@skiwi I don't think it's going to go away. I think it missed a chance and growth slowed.

It's also lost serious financial backing and I don't rate the core dev team.

@skiwi It's lost mindshare. I don't see much Groovy work outside of Grails and Gradle.

And I think Groovy missed its chance as a serious contender. Play/akka (with or without Scala) and the like are much more serious tools than Grails. And Groovy has lost out to Scala.

Same goes for Grails all over

I liked Gorm

Groovy, certainly. I was impressed by how Grails used groovy builders to hide the horror of Spring configuration/complexity.

@skiwi Grails? Spent a while training inexperienced Java coders in Groovy/Grails. Was depressed by how few of them got it.

So when I see that present, I'd vote the question up twice if I could.

Example inputs with corresponding outputs. Constraints. Seen so many ambiguous questions where that extra information would have saved everybody much time.

@Zak If you keep the db design clean, transitioning to an Access front-end and sql server back-end shouldn't be hard - if it ever comes to it.

Even then, it's hardly a great front-end, ofc.

As I recall, Access can be a front-end to a proper db. But I guess that's not how Zak's being allowed to use it.

And, from the comments in the code and the question, is clearly just a hypothetical question

codereview.stackexchange.com/questions/91093/… Stub code, doesn't compile.

Been away from SE for a couple of months. Hats have quite passed me by.

I know not many people pay attention to Scala questions here but that one shouldn't have made it to review. Surprised at Seth Tissue, of all people ;)