oftenwrong

9 ms·

121.
by oftenwrong 2y ago
>Lightweight Java has always been a thing for those who appreciate Java-the-language but despise Java-the-ecosystem. I always disliked Java until I was converted by some developers of that group in a past job. I suppose it is fair to jud
122.
by oftenwrong 2y ago
Also, see this project that is in a similar space as Coursier: https://github.com/bowbahdoe/jresolve-cli https://github.com/bowbahdoe/jresolve
123.
Bazel 8.0(github.com)
137 points by oftenwrong 2y ago|46 comments
124.
by oftenwrong 2y ago
This went over my head in some spots, but I learned a few things while looking up some of things mentioned. I respect the deep knowledge reflected in making this work, especially in such a seemingly elegant way. I see the appeal of a minima
125.
by oftenwrong 2y ago
Shenandoah was deemed production-ready in OpenJDK 15, but G1 remains the default collector in 23.
126.
by oftenwrong 2y ago
It would be hard to compile a comprehensive guide on such a vast topic. It would be more like an entire library. Consider that there are many areas where cultural differences preclude concensus. The closest thing available is probably publi
127.
by oftenwrong 2y ago
I still use a debugger for much of my print debugging needs by setting non-suspending breakpoints. This is useful because it allows me to change the printing dynamically, set breakpoints in library code, attach to running processes, and mor
128.
by oftenwrong 2y ago
An approach I've used is to use https://github.com/newren/git-filter-repo (amazing, versatile tool) to put the tree into a subdirectory, and namespace its tags, and then merge that into another tree with --allow-u
129.
by oftenwrong 2y ago
This is generally seen as a feature. Most developers won't need to confront the messy reality of the deployed "world". They can work within the relatively pure world of the code history. Of course, some will have to do the wo
130.
by oftenwrong 2y ago
This Spring hater (me) thinks that's a fair summary. It also eliminates much of the safety the compiler can give you for free. You will only find out during Spring init, or even later, that your program is broken.
131.
by oftenwrong 2y ago
I once worked for a startup that used Rails for building their web app. I would say around 50% of all development was in Rails. For things that demanded more performance or correctness on complex tasks, there were some Java services and som
132.
by oftenwrong 2y ago
This is one of the interesting benefits of https://www.unison-lang.org/ . A codebase of immutable functions inherently cannot have merge conflicts.
133.
by oftenwrong 2y ago
https://openjdk.org/jeps/8312611
134.
by oftenwrong 2y ago
The JSR 354 API can provide access to exchange rate services via the ExchangeRateProvider interface. The reference implementation (Moneta) includes a few implementations of ExchangeRateProviders that connect to online services to look up ex
135.
The Hose Clamp Story [video](youtube.com)
2 points by oftenwrong 2y ago|0 comments
136.
MTA Open Data Challenge(new.mta.info)
221 points by oftenwrong 2y ago|77 comments
137.
Urban Roadway in America: The Amount, Extent, and Value(tandfonline.com)
2 points by oftenwrong 2y ago|0 comments
138.
by oftenwrong 2y ago
These massive companies do employ a significant reliance on test automation. This approach is paired with sophisticated build tools and supporting infrastructure to make it possible to meaningfully test proposed changes, and ensure that the
139.
by oftenwrong 2y ago
Seems like an approach that is superficially similar in architecture to what Google uses: Piper <-> Mononoke CitC <-> EdenFS Obviously, the immense scale of these companies constrains the possible solutions. I would be intereste
140.
Grenfell Tower Inquiry Phase 2 report(grenfelltowerinquiry.org.uk)
2 points by oftenwrong 2y ago|0 comments
141.
JetBrains Workspaces aims for benefits of monorepos without the downside(devclass.com)
1 points by oftenwrong 2y ago|0 comments
142.
by oftenwrong 2y ago
The monorepo vs many-repos discussion often hits upon so many implied factors, but it's only really about how source code is stored. It doesn't necessarily indicate much about the deployment model. You can have many separately rel
143.
by oftenwrong 2y ago
The key point is "If ... the registry is available", and the dependencies contained therein. We take on risk by relying on NPM to always be there and always provide us the dependencies we have already invested in. I'm arguing
144.
by oftenwrong 2y ago
To put it in the most general terms: It provides the same value that using a VCS has for a project, but applied to the entire company. In a standalone project, would you accept a change that is incompatible with other code in the project? F
145.
by oftenwrong 2y ago
The primary cause of the left-pad incident was that left-pad was removed from the npm registry. Many libraries depended on left-pad. The same could have occurred with any popular library, whether micro or not. To reformulate the statement m
146.
by oftenwrong 2y ago
There is a Greg Young talk about this called 'The Art of Destroying Software'
147.
You can run Java like Python now(mccue.dev)
3 points by oftenwrong 2y ago|0 comments
148.
by oftenwrong 2y ago
Which of these is easier to search for in a book or web page? Which will allow for clearer oral discussion? I prefer using long options in shell scripts for similar reasons. Easier for future maintainers to search for.
149.
by oftenwrong 2y ago
>but this could still easily happen by mistake. I have yet to see this ever happen, despite working in Java shops using Optional heavily since it was included in the JDK. I would guess that this is due to developers using better tooling.
150.
by oftenwrong 2y ago
Maven is the de facto standard for open source Java projects, and it still has a reserved seat at that table, but it falls short of what other build systems provide. For example, multi-module projects and incremental builds are more like bo

More ›