huffstler's comments

I believe they're showing an example of where people would use (incorrect) regex patterns to validate. That's the whole thrust of the previous paragraph. `hadc0ffee` is not valid hex, but the function says it is due to, I presume, an incorrect regex pattern. I'm not familiar enough with regex to know why it's wrong though.

Edit: I was curious, so I looked through the linked docs for regex. They have the exact same pattern for checking hex in there as they do in this one. I guess it was just an error after all?

Does anybody know of a good place to get seasonality information for fruits and veggies?

I found an open source application[1] for showing that stuff, and have been looking around to be able to add information for the North America region. [2]

The FDA database is good and this one is too, but they don't offer any seasonality about fruits or veg :/

[1] https://flunzmas.com/seasonal-foods-calendar/

[2] https://github.com/seasoncalendar/seasoncalendar/issues/115

Maven, Hibernate, Jersey, Jettison/Jackson. All developed on Java 7 I believe, so the jump is rather large.

That assumes we have (any) tests, or benchmarks to refer to. Plus, we have a decent amount of legacy java apps (java 6 - 7) and we'd be going straight to 11. On the project I'm on now, it's not a smooth transition.

Pretty much right on the nose. As I mentioned elsewhere, testing is not required where I work. As such, there's no guarantee that upgrades to JDK won't break something behind the scenes now only to blow up later in production.

Ideally if I had any say in the matter, I'd also choose to continue the upgrades. I'm unfortunately not in a position to be able to make decisions for the company, or even team really.

The culture for us leads to more problems imo. Tests aren't required. We have > 100 legacy applications (most C#, but some java). I'm currently working on porting a webapp developed 5 years ago, written on jdk6 (I think) using Hibernate 4.x.y, to java 11. There's no tests for the webapp. The majority of the code was written by contractors. I've removed hundreds (if not 1-2 thousand) of lines of commented out or dead code before I even started refactoring. In this case, which I agree is probably an outlier, updating takes too long. Or maybe I'm too inexperienced.

In my managers eyes, they see how long it's taking to migrate to JDK 11, and they don't want that for every new "major release" (12, 13, etc)

I work in an organization that has bought support for Java (11, I think). Your comment is technically correct, but doesn't capture the whole situation I believe.

We use OpenJDK11 currently. The reason we're buying support is because bug fixes and backports END for JDK11 once JDK12 is (already was) released. If you want security/bug fixes, you'll need to upgrade your application to the new JDK every 6 months. For a team like ours (~8) people, it's simply not viable for us to be in a state of continual upgrading. We wouldn't get anything else accomplished. Our job is to provide value to the business, not be stuck in perpetual runtime upgrades. Buying the license allows us time between upgrading JDK versions so that we can target jdk11 for new applications.

For quite some time after jdk11 was released there was also a prevalent opinion by some of the more senior members on the team that Oracle was going to be gimping the OpenJDK release in some way or another. Even after being shown that that wasn't the case we had _multiple_ meetings where it was discussed that we shouldn't migrate to OpenJDK because of bugs that "existed in there, that don't in Oracle build". This is most certainly due to historical reasons, and I don't blame them for thinking it.

I can't speak to why we don't rely on other LTS options, I was not a part of the meetings that decided our actions. Ideally, we would rely on something like adoptopenjdk, but the powers that be decided to pay Oracle instead.

While gits documentation might not lay out the model at the start, they certainly have documentation showing how everything works, complete with diagrams and such. As such...

> Then it will be the user's fault if they can't be bothered to read it.

can be applied to you about git technically. I think that's just me being a "little" pedantic though.

It sounds like the issue you actually have is that the documentation isn't easily readable in one or two sittings, and you don't have the time (or can't be bothered) to go through it and learn it. Which I totally understand, everyone has different things they need to spend time on, most of the time learning Git isn't one of them.

As someone who also works at a bank (though not a large national one) I get the same feeling, though I understand it to an extent. Not complying to bank standards means you get dinged if you get audited. Getting dinged means you will most likely get your budget cut by an amount next quarter. Or get the group "reorganized".

I made an account just to comment on this link as I have personal experience in the matter.

I graduated from a relatively good school with a degree in Computer Science, yet wasn't admitted into the major until 2 weeks before graduation. I spent my entire college career in Computer Engineering while taking Computer Science courses and (thankfully) was able to complete the curriculum without actually being a part of it. I lucked out as at my school Computer Science isn't locked down like many of the other engineering majors, so anyone can take a CS course as long as they meet the pre-reqs. It would be an understatement to say the experience was harrowing.