bwilliams

I think that's a factor for sure, but is less important (generally) as the price gap increases. The Steam Deck also has a disadvantage in that only some of your existing library will be playable on the device.

There's definitely a price point for some where it will make sense to rebuild your library on the Switch vs pay the higher cost of a Deck.

I love my Steam Deck aside from the quality control issues I ran into, one of which required an RMA. It's really hard to justify $1000 for it when the Switch 2 is $450 (soon $500).

I do think there's a bright future for PC handhelds, especially when (not if) ARM processors can be utilized. I'm less sure about that if prices keep rising since that quickly becomes the difference between niche hobbyist device and mainstream gaming portable.

Same. It’s the best ebook experience I’ve had so far despite its size and I’ve tried a myriad of ereaders.

The only missing feature is a backlight for reading at night.

There's definitely a number of reasons, but I vividly remember _struggling_ with Ember data at the time. The framework itself was already complicated and the data management story felt immature and rigid in addition to complex. That definitely pushed me towards and a number of others towards backbone and eventually React.

> The best part about blog feeds? It's just an idea. There's no central authority. There's no platform.

I think this is blessing _and_ a curse. I had an idea that I built a while back that centralizes RSS feeds so you get the centralized benefits of social media while authors can own and control their own content.

If anyone's curious, I built it out here: https://onread.io but I never had the time to really share it out or push it beyond the SUPER basic MVP that it currently is. I was thinking about pivoting it more into a tool that I could turn into an RSS feed for myself, but I haven't found the time, really.

Either way, I don't think RSS feeds as-is are as useful as they once were, and social media still has significant value over feeds due to conversation, sharing of content to folks with similar taste and interests, etc.

You can have a modular monolith with multiple entrypoints that enable autoscaling of independent "deploys".

I had the same thought when reading the article too. I assumed (and hoped) it was for the sake of the article because there’s a stark difference between idiomatic code and performance focused code.

Living and working in a large code base that only focuses on “performance code” by default sounds very frustrating and time consuming.

Great article, memoization is pretty complex and full of trade-offs. We recognized a lot of these same pitfalls as we worked through making memoization a consistent and common pattern in our (very large, monolithic Rails) codebase via a `memoize def...` helper. The `false` and `null` pitfall is _surprisingly_ common, enough that it (and other pitfalls) warranted us writing our own memoization DSL.

We took the opposite approach of most libraries though (and a reason we rolled our own instead of pulling in an existing gem) by avoiding handling the complex edge cases that hide trade-offs:

1. Class methods can't be memoized.

2. Methods with arguments can't be memoized (so no LRU caches, weak refs, tracking arguments, handling default args, hash/deep object equality, etc)

The thought at the time was that those more complex scenarios deserve more thought than "prefix it with `memoize`". It's been a few years since we introduced the helper and after seeing it all throughout our codebase with no issues I'm even more confident this was the correct decision.

I haven't revisited it in a while, but I'd love to add some extra niceties to it, like hooking into `ActiveRecord`s `#reload`, although I dislike memoizing in models.

I’m not sure if it changed, but Crystal was limited to a single core which I imagine made it easier to choose Go over Crystal.

That and I’ve found that folks often aren’t very receptive to Ruby like syntaxes initially.

If we can’t have native macOS on the iPad this would be the next best thing. Imagine having Linux or macOS on the iPad that is treated like any other app (sans memory limits and etc.). You could have a full blown desktop at the ready when iPadOS isn’t up to the task.

The iPad could finally utilize the m1 processor to its fullest.

I think this may miss the point of the article, which is pointing out that you can get a lot of value for very little effort by using a timestamp instead of a boolean. I don't think it's intention is to replace a complete change history/audit log implementation, which would require a significant amount more time/effort to implement.

The beauty (and horror) of Ruby is that you can do almost anything with it. I think this is a really interesting and clever use of the "can do anything" aspect of Ruby, although I think I'd prefer not to run into it in a production app.

Still, it's really cool to see how far we can push/mold the language to accomplish different tasks and patterns.

I'd even be happy with a performant VM app that I could run linux on at this point. It would be so nice to be able to swipe up and go from linux VM -> imessage, etc.

The advantages you listed are potential advantages but the reality is often different. Those features don't come for free, and given the number of SPA's out in the wild it's rare that functionality like offline mode or gracefully degrading when running into faulty network connections are actually built, let alone maintained.

Most of the time SPA's degrade very poorly and instead of breaking they often appear as if they're somewhat working but the site is actually in a broken state and will need a complete refresh to become usable again.

It's also worth mentioning the Enumerable module that can be mixed in to classes, which gives you `map`, `select`, and much more for free by implementing `each`.

https://ruby-doc.org/core-3.0.2/Enumerable.html

I don't disagree, and that lack of common interpretation can be both good and bad. Good because it lets you apply your own understanding and experiences to it, and bad because it introduces the potential for conflict when two people have different understandings.

I read the article and didn't really feel that they disagreed with, or debunked any of the principles. It reads like they formed their own understanding of each principle and maybe disagreed with how they were taught, or how the principles are sometimes presented.

This change in outlook of existing thoughts/ideas is how many crafts grow, such as martial arts, painting, philosophy, etc (instead of stagnating). Sometimes we need to frame things in a more modern manner, and sometimes we need to discard them completely. In this case, I think re-framing the concepts is helpful, and I found it to be an interesting point of view. I agreed with a good amount of it, but I don't think we need to discard SOLID principles just yet.

Feels somewhat abandoned at times, but Apple Books is okay.

> You can write something and be done with it, then move on to the next thing.

That's part of the problem, you really can't. Requirements change. You have to update that service, and hope it's backwards compatible because if not, have fun updating all the services that interact with it.

I 100% agree it's all trade-offs. I think cost is important, but in that scenario it's going to cost them a lot more in time to split out and maintain several services. Devops was only one example. Their development speed will also likely slow down by a good margin as they now have to worry about inter-service communication and all that comes with it (keeping schemas aligned, making sure the services can actually talk to one another, etc.).

I think services are a useful tool but for most problems you can get incredibly far with a monolith. I think a solid approach is to identify where there's a bottleneck in your monolith and extract that instead of splitting the application up for the sake of having separate services.

Rewriting piecemeal is a great idea but extracting microservices adds a whole new set of problems that likely aren't worth the tradeoff, especially when your team is just you or only few other people. eg: Now your devops responsibilities aren't just deploying and keeping 1 app up and running, it's all of them.

I've tried a few out like todoist, things, wunderlist, etc. and none of them really clicked with me despite my efforts.

My new killer app is a tiny muji notebook and a decent quality pen or marker. I find it easier to remind myself to track, check, and create goals with the physical medium right next to me.

https://www.muji.us/store/stationery/note-books/high-quality... super thin, portable, and cheap.

That's an option, but I can't imagine many folks would want to learn Delphi and continue to invest their time into it unless the money is worth it.

If your API is down who cares if your app is being served or not? In the majority of cases it won’t work because the API is down.

> A bug in one "page" of the app can cause the whole application server to go down.

That doesn't seem like a valid issue. If a bug in a single page could take the application down then the same could be said for the API powering the front-end.

> If you leverage client-side rendering then it's easier to decouple your front-end from the back meaning you can take advantages of things like segregated micro/serverless services and progressive web apps

Your PWA point is valid but I don't think the microservices point is. Microservices add a ton of complexity and can easily become overwhelming. If you get to the point where your application can benefit heavily from microservices then congrats, you've made it.

> I think that server-side rendering is on it's way out.

If anything I think its on its way back in. So many companies bought into the benefits of client side apps and are now seeing the trade-offs that aren't very favorable.

> comments like these

I strongly disagree specifically about comments like these throughout an active code base. A well named variable or method can act as a much better descriptor of what’s happening and doesn’t have the same maintenance cost.

I think we both agree that comments are valuable, just not the scope. Comments are valuable when you’re doing something unexpected or where the code fails to explain what’s happening.

For what it’s worth I mostly work with Ruby, JavaScript, and TypeScript which definitely color my views.

I think that’s fine as a choice for a personal project, especially since your committed to it. It’s a totally different story when working with a team though. Comments become outdated, files get larger, and it becomes more of a hassle to maintain while providing little to no value most of the time.