I feel like this is a pretty big fumble for Anthropic. I don't mind waiting 30 minutes or so for a service that's having issues. But, around the 2 hour mark, I start researching alternatives. I think like almost every other developer I've been working on my own AI assisted project management system. It was built around Claude Code, but now I'm using my down time adding in support for Gemini and Codex.
Yeah, I had heard about Renovate supporting Bun. I guess I was reluctant to start working with another 3rd party dependency management system when I already knew how to setup and use Dependabot, and I assumed Bun support was coming soon-ish. But maybe the benefits of moving over to Renovate and getting to use Bun now outweighs the costs. <thinking-about-it>
Bun seems really compelling. I tried it out for a couple of small example projects and I like the speed and the fact that it combines package management and a JS runtime. However, I use Dependabot on most of my serious projects. I know work is under way, or at least there is some discussion in a couple of repo issues, for Bun support in Dependabot. I'm kind of holding off on using it until support for it has been rolled out.
I really like using Tailwind. But I mainly only use it for personal projects. I have some design and front end development background and I feel comfortable creating a design system from scratch. But, for professional projects I pretty much always use Bootstrap because it has a predefined design system that a lot developers feel comfortable with. I'm not quite sure why the Tailwind team has steered clear of having a prefab design system that gives you classes like `btn`. It seems like a major piece of the puzzle they're missing.
Even for a Teenage Engineering product, I have sticker shock over this and their field mixer. They're nice products, but the premium is so high. I mean, I kind of get it. Their original OP-1 remains the top selling synth after 10 years. And the product is much loved and used (at least on Youtube). But, for the price of an OP-1 Field you can get a couple of Elektron digi-boxes, with a bit of money left over. This is certainly more portable... but wow $2,000 is a bit steep. I mean, I still want it, of course.
Yeah, I have a BlueBox and it works great. You can also add tactility with an external controller like: https://intech.studio, and you're still in the ballpark of like half the price of the TE mixer. I mean, I still want one, though. LOL.
I agree with @tinco. If you're doing Ruby development that is not Rails, you probably want to create a gem with Bundler. I'd check out their documentation on the subject which has some good information: https://bundler.io/guides/creating_gem.html. I'd also checkout https://www.learnenough.com/ruby. I haven't walked through the course, but Michael Hartl has been providing Ruby related learning materials for a long time and is a fairly trusted name in the community. I'm sure it's solid.
I find comments like "I've been using <the tool> forever and never noticed <this> problem" a little annoying. But, I fall into this camp here. I'm not trying to dismiss other people's criticism that the slowness has had a negative effect on their workflow. But, here it goes, I use exa as my ls replacement and I've never even noticed it was slow. And, for me, the chief value really comes down to exa's color coding of results. It helps me see the information more easily which I feel has a cumulative effect of speeding up my workflow.
I totally agree with this. This may be an unpopular opinion, but I feel like Electron is really helping here. I've been a Mac user since 2003, but built an Ubuntu based desktop recently. The fact that I can run Figma, VSCode, Slack, etc. means it's actually a workable solution. I know Electron is slow, but I don't think producing native software for Linux is economically viable or commercially interesting for a lot of companies. But if a company is building with Electron, I get the impression that it's not a lot of extra work to support Linux and it means the platform actually gets an app. Ironically, I think this will make Linux a more reasonable choice for day to day work and will eventually result in increasing the economic viability of producing software for the platform.
I started messing with Heroku back when they were trying to be an online Rails editor. When they started getting more seriously into hosting I was relieved to have a company dedicated to making Rails hosting easy. But, every time I tried to host a professional project with them I ended up leaving early on because of slow performance, high pricing, and the fact that their system had limits that there was always some third party around to help solve for a fee. The fees add up. I started rolling my own configurations with Chef. It was painful. Then I tried Ansible, and it was easier to use, but I was still responsible for devops. I've come to realize that I will never be good at devops. I'm spending all of my time in application code. It just isn't what I do. And, most of my professional projects really don't have scale issues. They're mostly apps with small user bases that run great on a couple of servers. There's a sweet spot for Heroku here. Yeah, they're still slow, they still have limitations, they're still expensive... but on the low end of their price scale, it's hard to beat not having to worry about devops. (Saw a reference to https://render.com in the comments. Maybe I'll give them a try.)
I don't know. It's so easy to just create a random Gmail address and forward email from it. Maybe this makes it easier, but Gmail is one of the few Google products that I feel pretty confident will be around for a long time.
I don't think that's entirely accurate. Lots of Rails users went the SPA route the second stuff like Backbone came out. Wycats was big in the Rails community at this time and he spearheaded Emberjs. The Shopify guys were (and are still) big in the Rails community and they created their own Batman.js. It's just that the Rails core devs made a decision to not go that route. They were even working on their own front end framework at one point and after some time they decided to kill it in favor of just using pjax/turbolinks. You can get your 80% case accomplished with these technologies with substantially less effort. There are definitely reasons to go SPA, but the dev community at large has jumped on the hype train here without really identifying that using these technologies are a good idea for their use case. I mean, there's a lot of people doing CRUD with React. That's crazy.
As a long time Ruby developer I frequently hear older developers talking fondly about their experiences working with Smalltalk long ago. When I saw this post, I was curious enough to watch a video just now by a respected Ruby dev (who's admittedly new to Smalltalk and using an older version of Pharo): https://www.youtube.com/watch?v=HOuZyOKa91o. The video is short, but it looks to me like the advantage of developing in this environment is mainly that you can write a test, run it in a kind of debug mode, and when the environment encounters something it doesn't understand it gives you some options for creating something new like an object or a method to solve the problem. This seems kind of cool, but I feel like there must be more to it. Can anyone better explain the selling point, or share a video that highlights how this environment is so cool?
This is the first thing I noticed when I opened it up. Whoa, fuzzy text, no retina support? I'm guessing this isn't important to the Pharo developers, or at least, it isn't a top priority for one reason or another. I guess I'm a bit of a resolution snob. I find it off putting. But, hey. It's open source.
You're not alone. Stripe has been working on adding types to Ruby with their static type checker, Sorbet: https://sorbet.org/. This seems to have a bit of momentum at this point. Assuming it continues in popularity I'm excited to see how this helps to improve Ruby work in an IDE.
As dgellow and kawsper pointed out, Rubymine is a good IDE, or Intellij with the Ruby plugin, which is functionally the same thing. Also, vim support for Ruby is amazing. Tim Pope has dedicated a chunk of his life to ensuring this (thanks, Tim). Also, a lot of the core team members have been using Emacs since the beginning. I haven't spent a lot of time with Emacs, but from what I've seen, the Ruby support is pretty great.
I’m excited about this work. Having a faster Ruby would be some wonderful icing on the cake. But, for me, using Ruby (and Rails) has always been about optimizing for developer hours over system performance. IMO Ruby is not a race horse, but it’s plenty “fast”. The real value is how quickly my team can iterate, and how enjoyable the process is.
It's pretty rare that I watch a movie on Netflix these days. I pay for the original content they produce and some of the documentaries that end up there. For my purposes, there is enough content along these lines to justify the expense. Once in a blue moon I see a movie there that I want to watch, but I consider that a bonus.
Right... sorry. I didn't make my point very well. What I was trying to say was that this is sort of an ORM, which makes sense to me. I see a need for that on the front-end. I see your other comments about how this isn't exactly an ORM, which I see as a semantic discussion. It's ORM enough for my purposes. I bring up Ember Data because it's an example of battle tested and feature rich front-end ORM. I'm thinking it would be more popular if it wasn't tied to Ember so closely.