I built portrayal[1] (a much simpler replacement for those dry libs), and was also experimenting[2] with runtime-enforced types based on this lib.
My general thoughts is that declaring types in Ruby is unnecessarily complicated, because you're basically just running values through pieces of boolean logic, and nothing else. Might as well make that explicit, which is what my experiment did. I didn't however publish the types library, but the concept was proven.
I wrote this controversial thought[1] once, but for what it's worth, it applied to me just as much as to anyone else. Projects like these type gems are incredibly fun and satisfying to build. Your vision is clear, you've seen types before, you're proficient enough with Ruby to do clever things. The work seems cut out for you. Go nuts!
Problem is, these kinds of solutions (I also see this in "service objects" world) take Ruby away from you, and offer you a whole new vocabulary. With time I started appreciating libraries that avoid solving a problem that plain Ruby can solve, because Ruby is incredibly clear and concise already. If you leave more opportunities for people to write plain Ruby, you will solve everything with much less library code.
I think that's where the fun of building goes against the end developer experience. Builders love "owning" everything. E.g, "No, don't write `&&`, I have a special way for you to compose types!"
These are general thoughts, but I'm happy to get concrete with specific examples too.
I like Ruby on Rails + Postgres, GoodJob for background Jobs, sveltejs for complex widgets, bootstrap as CSS framework, vite for "compiling" the assets, deploy on Fly.io
Hi, I have been building https://babelfu.com, a translation service on top of Github; it fetches the translations from your GitHub repo and commits them back, so the source of truth of the translations is the repo itself. You can forget about sync tasks, collisions between branches, etc. In the end, if there are conflicts, you manage them on Git as the rest of your code.
It is available in a very early open-source version, which I will update at some moment if I see someone interested in it.
I would be very grateful if someone gave it a try to setup a project and provided some feedback.
I am doing nothing, but I was wondering if it would make sense to combine a small LLM and SQLITE to parse date time human expressions. For example, given a human input like "last day of this month", the LLM will generate the following query `SELECT date('now','start of month','+1 month','-1 day');`
It is probably super overengineering, considering that pretty good libraries are already doing that on different languages, but it would be funny. I did some tests with chatGPT, and it worked sometimes. It would probably work with some fine-tuning, but I don't have the experience or the time right now.
LLMs tend to REALLY get this wrong. Ask it to generate a query to sum up likes on items uploaded in the last week, defined as the last monday-sunday week (not the last 7 days), and watch it get it subtly wrong almost every time.
>>It is probably super overengineering, considering that pretty good libraries are already doing that on different languages, but it would be funny. I did some tests with chatGPT, and it worked sometimes. It would probably work with some fine-tuning, but I don't have the experience or the time right now
yeah, could you share those libraries please?
Anyone around have actually succeeding in solving this in a way it works? Would appreciate any hints.
This is my #1 use case now that something's been vacuuming my floor for 15 years, and washing for ~3. Add this labour saving device and I'm immediately buying, and selling to others.
reply