HN user

lgreiv

248 karma

—— [ my public key: https://keybase.io/lagr; my proof: https://keybase.io/lagr/sigs/5H6nsNcDwLz6KbTbRDQgVSFzPU9IWKJoiSoCsH3jR0c ]

Posts3
Comments72
View on HN

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.

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 ERB

I 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.

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'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.

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.

[1] https://crystal-lang.org/api/1.7.0/

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?

[1] https://github.com/aws/aws-lambda-base-images/issues/54

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...

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.