HN user
I have started to adapt https://testinfra.readthedocs.io/en/latest/, which looks similar in style to this from the verification side. Having previously used Salt, Ansible, and Chef at other companies, this looks great from a UX perspective compared to those other tools.
At least in java.time (which I believe an inspiration for Temporal) Duration (https://docs.oracle.com/en/java/javase/21/docs/api/java.base...) is a time-based measure of time. For example, 5 hours, 59 minutes, and 15 seconds.
Period (https://docs.oracle.com/en/java/javase/21/docs/api/java.base...) is a date-based measure of time. 2 years, 3 months, and 4 days.
Interval (https://www.threeten.org/threeten-extra/apidocs/org.threeten...) isn't built into java.time, however, it is in the popular threeten-extra library. The docs say "An interval represents the time on the time-line between two Instants." The main difference being that Interval is anchored to the timeline while Duration and Period are not.
You could be thinking of the Claude tool search tool [0][1], which lets it do that on-demand loading. Skills (like another comment mentioned) have a progressive disclosure mechanism built-in. Agent Skills [2] appear to be the common format across most of the tools, but I have no idea if this actually has tool provider buy-in.
[0] https://platform.claude.com/docs/en/agents-and-tools/tool-us...
[1] https://www.anthropic.com/engineering/advanced-tool-use
[2]: : https://agentskills.io/home
I had the same experience with JobScan. I felt that it helped me on my resume overhaul with some good clear suggestions, but didn't work well with editing and replacement, especially with my resume hosted in Google docs. I cancelled my subscription during the free trial.
Thankfully, this is another tool in the current arms war of job searchers versus corporate recruiting.
I've been watching a YouTube channel named Climate Town that recently did a video talking about natural gas, and leakage was a focus point in the video. It's like a documentary-style comedy channel, and I quite enjoy both the content and the format. It reminds me a bit of Jon Stewart and John Oliver.
Video link: https://youtu.be/K2oL4SFwkkw
Heads up, the https://nightwatch.io/jobs/backend-developer link 404s.
One aspect that I find discouraging is the significant opportunity cost associated with the time and effort required during the job search process. Instead of using this time for skills development, exploring new technologies, or excelling in a current role, it's consumed by:
- Tailoring resumes to suit ATS systems (now with AI/other automation) - Leetcode and study for live interviews - Identifying suitable positions on job boards for cold applications - Probing your network - Responding to unsolicited contacts - Chasing ghost recruiters
It's disheartening and frustrating to remain unemployed for an extended period, especially when I possess relevant experience and expertise, yet continually face rejections due to the challenges of navigating the recruitment pipeline.
They wrote an interesting blog some time back about how "random shuffle" isn't necessarily what people want, and how their algorithm works (https://engineering.atspotify.com/2014/02/how-to-shuffle-son... ). That was a decade ago, so maybe their approach has changed or that it does not perform well under certain conditions (like the one you mention). It works well for me on most playlists on the order of 10s.
It is indeed Project Loom - https://openjdk.java.net/projects/loom/
I agree that the usability has been declining.
The threads feature is pretty close to useful, but it still buries information and it isn't clear to other users in a channel when a thread becomes "live" again unless they explicitly follow the thread or make a comment. Both of those actions require excessive clicking on the desktop client (at least for Ubuntu).
The most frustrating part for me is that keyboard navigation for threads is nonexistent, and it forces you to weave in and out with your mouse.
I thought this was going to be similar to https://play.kotlinlang.org/koans/overview . I used that as a quick way when doing other things to slowly learn parts of the language before diving in, was hoping this would be similar.
YAML templating is something I've come to truly hate. It seems that tools and services want the configuration to be "simple" by using a format that is fairly easy for humans to parse while not trying to force a language specific tool onto the users. However, when they move into the inevitable phase of wanting to be more configurable, they can move into confusing, unintuitive, and surprising territory. It also doesn't help that everybody keeps inventing their own way to do it. A few examples of YAML bastardization that give me headaches trying to understand:
* saltstack Jinja templating [1]
* GitLab CI `include` directive for including and merging external CI files together [2]
A few tools that I have seen take a decently pragmatic approach:
* Kubernetes resources that use ConfigMap and `envFrom` that declaratively say where to resolve a value from [3]
* Circle CI commands which offer some reusability with its "commands" and "executors" type features [4]. To me, Circle CI has both good and bad aspects with some templating and some clever patterns
On the other side of things, there is essentially fully programmable type configurations like Jenkins Pipeline Groovy `Jenkinsfile`, which can be a nightmare, too.
I think it is tough to find a sweet spot between making it configurable and expressive for users while retaining a low barrier of entry and not turning the configuration into a complete program itself. Tools like Terraform are trying to find that sweet spot as they slowly introduce more programmatic ways of configuration while still being declarative, like the fairly recent introduction of if statements and soon (I think) to be released for loops. As soon as users of a tool and service have more complex use cases, there needs to be some way to solve that. The most common way (it seems) is taking the easy and familiar of introducing templating.
[1] https://docs.saltstack.com/en/latest/topics/jinja/index.html
[2] https://docs.gitlab.com/ee/ci/yaml/#include
[3] https://kubernetes.io/docs/reference/generated/kubernetes-ap...
[4] https://circleci.com/docs/2.0/configuration-reference/#comma...
`kustomize` is an interesting and useful tool, and it is cool to see it available directly in `kubectl` in 1.14. A lower barrier to entry is nice to have for tools like this. It is useful on its own, but I'm also looking forward to additional features like being able to reuse a single patch on multiple targets (https://github.com/kubernetes-sigs/kustomize/issues/720). I'd also like to see a clear schema for what the YAML needs to look like and what the keys do. I wish it folowwed a similar pattern as `kubernetes` resources where each resource had an `apiVersion`, and the `kustomization` itself had an `apiVersion`.
Some newer documentation can be found at https://kubectl.docs.kubernetes.io/ which is still a little bit barren, but I expect it to improve. Some of the older documentation can be found at https://github.com/kubernetes-sigs/kustomize/tree/a5bb5479fb... (before the tool was integrated directly as a subcommand)
I've had good experiences on the JVM using HOCON [1].
[1] https://github.com/lightbend/config/blob/b782a2d701fc2b04579...
This is one of my favorite features, too. I've found it works amazing when you generate the documentation or render it locally. Unfortunately, it doesn't work in "safe" mode sites like GitHub or GitLab where having a lightweight include feature for samples or tests would be useful.
For macros in AsciiDoc, I've made do with the little bit of support mentioned at https://asciidoctor.org/docs/user-manual/#pass-macros . Everything I found for Markdown always required an additional tool or "something else". I like that AsciiDoctor, for the most parts, has nearly everything I want built-in.
I read about the culture of Valve a few years ago and it seemed interesting. What have you seen come out that changed your opinion?
I think of this article (https://medium.com/@sdboyer/so-you-want-to-write-a-package-m...) when it comes to package management.
This is awesome and inspiring. Any thoughts on how to approach something similar for red light camera violations and accident/police data in Illinois?
It sounds like the philosophy is "don't break your consumers", which I agree with. Somebody else already linked his Spec-ulation talk, but I think somewhere in there he compares the 10 minutes a library author spends on deprecating or removing some piece of code versus the 10 minutes each and every one of your consumers spends trying to determine why a dependency they put trust in broke their application.
I do think it can be very difficult to know if you, as a producer, are breaking any consumers. I'd love to see some sort of OSS build tool and CI system that automatically rebuilds and tests all consumers of your library to give you, the library author, more information about the changes you make before releasing.
Thanks for the reply. I wrote that post earlier this morning after some other frustration, so I'm sorry for the negative tone.
Despite some of our issues with it, Conda has worked well for us both as a development team and in production for quite some time.
six million active users
That's awesome to hear, and one of the reasons we haven't seriously invested in a replacement.
Not OP, but we would like to move away from it as well.
- Breaking behavior between minor versions (https://github.com/conda/conda/issues/7290)
- Environments not actually being isolated (https://github.com/conda/conda/issues/448)
- Can't create environments in long paths (https://github.com/conda/constructor/issues/156)
Those are just a few I can remember. We unfortunately have not found a strong replacement.
Last time I tried, it also required that the target Python version be installed somewhere on the path. If pipenv used venv instead of virtualenv, something like pyenv to retrieve/install Python versions, and was distributed as a full executable (rather than requiring a bootstrapped Python) I would actually it.
SaltStack also has the JINJA2 template embedding which can make it very difficult to understand which parts of the lifecycle run through templating. I'm still not certain I understand how it works.
The most recent offenders for bastardizing YAML I have seen are the different CI services:
* Circle CI using moustache-like templating and interpolation with things like {{ .Branch }} available in certain steps [1]
* GitLab CI adding an "include" type directive to declare YAML dependencies [2]
I've also experienced this professionally. At my last company, somebody decided to add a feature to enable interpolation in some parts of the YAML deployment data. It ended up being used by a handful of people who were confused why interpolation worked in some places and not others. The weird trend of "extending YAML" seems to be going against any sort of benefits you might have by trying to use it.
[1] https://circleci.com/docs/2.0/configuration-reference/#save_...
Sounds similar to the FindBugs project (discussed here [1]). The result from that episode was a fork into SpotBugs [2].
I think you are greatly understating the difference between amateurs and top players in the NHL. Watching the players coming from the feeder leagues to the NHL, you can tell that there can be a _huge_ difference in skill.
The Blackhawks this season are a good example to look at. If you just compare the goalies this year you will see a large difference. Corey Crawford has been their goaltender for 2 Stanley Cup championships, and was injured in the middle of this year. He has not played since then, and it has forced the team to try and find a replacement. I think looking at the statistics shows the difference even between the most elite goalies and those that are close to that level.
W is wins, L is losses, GAA is "goals against average" per game, SV% is save percentage
- Corey Crawford: 16 W, 9 L, 2.27 GAA, .929 SV%
- Anton Forsberg: 10 W, 16 L, 2.97 GAA, .908 SV%
- Jeff Glass: 3 W, 6 L, 3.31 GAA, .898 SV%
- J-F Berube: 2 W, 5 L, 3.93 GAA, .891 SV%
Statistics taken from ESPN [1]
[1] http://www.espn.com/nhl/team/stats/_/name/chi/chicago-blackh...
Full interview: https://streamable.com/qkouq
The equipment manager story happened, too [1]!. In that case, he only went on to play the last 8 seconds of the game so it wasn't as crazy as this occurrence since Scott got to play 13 minutes of NHL hockey.
[1] https://deadspin.com/the-hurricanes-playing-their-equipment-...
I wasn't aware that Python3 was pre-installed on major distros, I don't believe it was by default on my Ubuntu 16.04. It is possibly I removed it, though. It does look like 18.04 is going to bundle Python 3 [1]. I agree with you that adding JVM is an expensive decision and the runtime requirements can make using them in real projects a big pain.
Thanks for the video, I'll check it out. It is exciting (and I would also say a bit worrying) to see a lot of competing tools in this area.
There's a reason Meson is winning the latest build-systems war:
What do you mean by winning? I haven't heard of Meson until the last few weeks, and I haven't seen it consumed by any open source projects on GitHub, although my search biases more towards JVM things anyways.
it only depends on python3 & ninja
I don't see how depending on both Python3 and Ninja is any less dependencies than the JVM. Python3 isn't really available by default on most distributions (maybe that is changing soon), so there is still the overhead of installing it, right? Public CI systems like Travis CI and Circle CI have images that make having a JDK easy.
The threads found on this are disappointing as well ([1] and [2]). The author(s), as far as I can tell, only make the source available for each release. They do not want a public repository and are very resistant when others ask.
They do make the source available with each release, and a user has mirrored them onto GitHub [3]. I also cannot find the source for older releases.
[1] https://sourceforge.net/p/keepass/discussion/329220/thread/0...
[2] https://sourceforge.net/p/keepass/discussion/329220/thread/b...