I really like the general idea, but accuracy was underwhelming. The biggest critique would be the note values / durations.
HN user
lgreiv
—— [ my public key: https://keybase.io/lagr; my proof: https://keybase.io/lagr/sigs/5H6nsNcDwLz6KbTbRDQgVSFzPU9IWKJoiSoCsH3jR0c ]
I let my wife (degree in vocal performance) sing into it and what was transcribed was not accurate at all.
I am mostly using it for hobby projects by now, but for me it is the very transparent yet mighty type system in addition to the aforementioned aspects. Its macro system is a sweet spot in comparison Ruby’s metaprogramming, which can easily be taken way too far. Also, if you do it right, you can build containers from scratch that are small in size and boot really fast. It has a really well curated and extensive standard library that lets you get away with including a lot less dependencies. It comes with a linter, a test runner, docs generator and quite useful debugging features.
I am looking forward to what AI can do to port Ruby gems to the ecosystem.
Slightly different approach, but appears to have the same overarching goals: https://github.com/bullet-train-co/magic_test
„Magic Test allows you to write Rails system tests interactively through a combination of trial-and-error in a debugger session and also just simple clicking around in the application being tested, all without the slowness of constantly restarting the testing environment.“
I will keep an eye on both now, probably they will compliment each other at some point in time.
Since trying it on a dev conference in Amsterdam, I am severely hooked on Tony‘s Chocolonely, which usually rates quite high in labor protection reviews [1] and has started to introduce traceability for the supply chains of its various ingredients. It also tastes unbelievably good.
A relevant (WIP) standard in this context could become 802.11bf „WiFi Sensing“ [1]. If plenty of common consumer devices will support it (maybe even some with an on-board camera), it may become hard to avoid.
[1] https://standards.ieee.org/beyond-standards/ieee-802-11bf-ai...
You should be able to organize accounts hierarchically using AWS Organizations, which allows to have cost centers and centralized billing (and some imposed policies over all accounts).
Very handy tool for sure. I really appreciate the efforts you made on in-line, repo and website documentation.
It’s a bit of legwork, but it’s there.
https://github.com/amberframework/docs/blob/master/examples/...
Nim really looks awesome too! If I came from a python background, I could see me reaching for Nim rather than Crystal.
While it may be possible to onboard Ruby developers fairly easy, it is still easier to find talent for an „established“ language. For my personal projects, I gladly use Crystal, but in my professional role as a technical decision maker I need to factor aspects like this in.
I wish Crystal would take off. It has so many things going for it (many of them mentioned in the article): performance, useful tooling such as an opinionated formatter, an integrated RSpec-like test framework, a powerful standard library, an awesome type system that gets out of the way most of the time, a familiar syntax.
So far I have been building some smaller personal CLI tools and a few web apps (with the Lucky framework). I’ve also tinkered with running it in AWS lambda functions in a custom (albeit unfinished) runtime.
Coming from a decade of Ruby, due to the similar syntax and mindset Crystal is my go to for cases where I need performance or runtime-less execution (e.g. in containers from scratch that contain only the binary and dependencies, if needed).
Crystal's standard library provided enough functionality for me in the past to get away with only few dependencies per project, which is great for supply chain security and complexity. Some of it's highlights are:
- an ergonomic HTTP::Server and client
- OAuth / OAuth2 clients with token refresh
- JSON/YAML/XML parsing/generation/mapping
- JSON/YAML mapping to classes
- native templating similar to ERBI have some bad news for you. They are not updating their browser integrations for <= v7 and the newer ones will not work with local vaults. De facto, they are already deprecating standalone licenses/local vaults.
Thank you for the suggestion, I’ll check it out.
This is my stance as well. I have not chosen a successor yet, but I’ll have a look at Bitwarden, Keepass and the recently released Proton Pass.
Trusting Dropbox for sync (which I did) meant trusting a cloud service, too, but IMO it is a less lucrative target for hacks than a server that stores _nothing but_ credentials. Also, using DB made me less dependent on connectivity (LAN sync) and would let me switch providers quite easily.
I was just listing the goals I gave it in temporal order, but I’ll include a weak task for the giggles in the future when talking about the POC. Good suggestion!
I've built a proof of concept myself in Ruby, an agent that extends itself with new abilities at runtime based on code suggestions from ChatGPT until it deems itself capable of fulfilling an arbitrary task given in natural language. It then persists that „specialized“ version of the task was completed successfully.
So far it was able to add an API to fetch me the local weather, return the capital of Venezuela, control brightness and volume of my MacBook and replicate itself at random locations (but tell me where, after).
That being said, I added multiple human-in-the-loop points in the assess/suggest/patch/execute cycle and (given the nature of LLMs) would never use it outside of a sandbox without these safety rails.
History really rhymes. This is another step in Replit reproducing the path of Heroku (which is a good thing to say IMO).
A next generation of IaaS with great DevX would be a relief to everyone burnt by AWS‘s complexity overhead (for a great bunch of customer’s needs).
I have seen several variations that I found consistent with the metaphor of a switch.
Broadly, these could be divided in implementations that offered a loading state (switch goes transparent until persisted, overlaid spinner etc.) and implementations that flicked the switch back when the request failed and provided a very noticeable status update (hint, animation, growl).
My preference for systems that work with unreliable persistence is the former, albeit that is purely personal and not founded in a deeper rationale.
Exactly this is it.
It is the metaphors that they apply, a toggle mimics a switch (e.g. a light switch) while a checkbox mimics it’s own paper counterpart.
To me, the semantic difference between the two is that I expect a toggle to cause an immediate effect whereas a checkbox merely holds the value to be applied later.
Applied to a client/server web application, I would expect a toggle to immediately cause a request to the backend. I’d expect a checkbox to be used in a form which is sent as a whole on submit.
It should be consistent in its use of idioms in order to reduce the number of lookups required. Still, it should be documented extraordinarily well, because it then can serve as an on-ramp to best practices for novices. Further, it should be tailored to the intended use case of the language to stay lean but usable to carry an application as far as possible without needing a heap of dependencies.
I appreciate these qualities in the standard library of Crystal [1], to name an example.
Ruby 2.7 is reaching its end of life come next March. While other runtimes received updates, there is none in sight for Ruby. Mind you, Ruby recently had its annual Christmas release, gifting v3.2 to the community.
There is a short thread at the issue tracker of the official Docker image repository over at GitHub [1], which has a tumbleweed-y feel to it.
Is this a signal for everyone still rocking Ruby lambdas to either plan a migration to another language or to roll their own custom container image?
Awesome portfolio! It’s always impressive to see what can be achieved with this little thing.
As an avid user of the same camera, I share this recommendation. While my iPhone sure is able of capturing some moments pretty well, the Ricoh is still way more capable and ergonomic. It is built by people who understand how do design that follows the need of their users and seems to be less concerned with bigger-is-better-marketing-number-games. Basically any parameter can be controlled with the same hand that holds the camera (I really tried it, shooting a moving target with pretty dynamic lighting while riding my bike [1]). I think that phones are lacking the haptic feedback is prohibitive to building muscle memory.
Also, people tend to react differently to a point-and-shoot camera than to a phone camera or a DSLR in my experience. That is because it feels less likely that the pictures end up on social media I’ve been told on request.
[1] https://44hz.de/assets/img/generated/R0001096-2-1200-9e3a59a...
This person knows what they are talking about. Although I have been pretty successful in obtaining realistic hands by prompting photographs and including make of a camera, lens and film [1][2]. Somehow this seems to narrow down the model to mostly produce realistic output. Still, some variants will occasionally feature Chernobyl-levels of fingers.
[1] https://cdn.midjourney.com/6f52a6e9-b3f2-4830-81b1-84c8f8ca4...
[2] https://cdn.midjourney.com/361e143f-5121-4bff-ada9-069c2e400...
Yes, that’s what I heard, too. I’d probably give it a try, though, as I know similar structures from my work in FinTech, where we integrated with quite „conservative“ banks as well. I kind of have a knack with finding the right knob on such people to get to the desired goal.
I actually like the idea of becoming a public servant and bringing innovation to places that really matter for basically everyone around me, but salaries are not even in the same ballpark even with IT-Zulage.
Actually, immutability may probably not even required/desired given the surrounding legal construct and the described processes.
Disclaimer: I am not a lawyer and the previous post is my understanding of the described as a layman. I am pretty firm on the technical concepts surrounding blockchain solutions, though.