hmeh

5 ms·

1.
by hmeh 3mo ago
A custom one is worth it in my opinion. Mine feels quite nice. Not 100% of a gasket mount heavy keyboard, but pretty darn close. Took a while to find the switches that worked for me, but I love it. Also, I have lots of sound deadening in it
2.
by hmeh 7mo ago
I've tried a handful of 4k HDR/Mini-LED monitors. I think something that folks are missing on this is that HDR on this display will likely actually work for desktop usage, similar to how it does on a MacBook Pro. With any other
3.
by hmeh 7mo ago
[THIS POSITION HAS BEEN FILLED] Substantial | Senior/Staff Software Developer | REMOTE (US) | Contract (potential for full-time) Substantial is a technology consulting company. I'm looking to add someone to my team working with a
4.
People jumped to conclusions about this RubyGems thing (Justin Searls)(justin.searls.co)
3 points by hmeh 11mo ago|1 comments
5.
by hmeh 2y ago
Same. So far so good.
6.
by hmeh 2y ago
Hah. Yes, --init-directory is very useful. I think Doom is a fantastic way to get started and know what's out there. I do suggest folks to eventually dive into building their own config. Having that much control over your work surface
7.
by hmeh 2y ago
evil on Emacs has been great for me. I’ve been using vim for 20 years (vim, visual studio, vim again, now Emacs) and Emacs/evil for at least 5 years or so. I’ve heard someone say that Emacs with Evil is a better vim than vim. I’m incli
8.
by hmeh 2y ago
> Well sure, but in that case it's no longer "it's solving a problem we don't have". It's solving a problem that may be low on your priority list, that you maybe choose to tolerate, or solve in a more cumber
9.
by hmeh 2y ago
> I've found that even if the page is, like, tax forms, latency changes the feel of it and affects how the user feels about your site, even if they wouldn't consciously say anything about the speed. I agree with this, but proba
10.
by hmeh 2y ago
> but developers "fixate" on it because it matters to users Then it's not a fixation. If, for your application, the difference between a 1-50ms interaction and a 150-400ms interaction matters, then you have reason to for
11.
by hmeh 2y ago
Indeed. I think an important concern is what constitutes a "full application". I think that's where the community (I've even seen this at my own agency) has lost the plot a bit. > I am the TL of all the setting pages
12.
by hmeh 2y ago
Right on. I definitely resonate with the first two. The third is somewhat arguable for me, but I've historically appreciated it and probably did much more when React first came to my attention. And yes, I ended up falling for React for
13.
by hmeh 2y ago
To be fair, 4 years ago I would have too. The cracks started to show with Phoenix LiveView and turbo and I took a leap of faith on the alternative I describe in my other comments. I haven’t looked back. I’m not sure I would rely on obviousn
14.
by hmeh 2y ago
Human perceptibility is only relevant in certain contexts. Are you in one? Ok, maybe you need client side interactivity. This is what I mean by "highly interactive" applications like Linear, Miro, Superhuman, etc. Having to wait f
15.
by hmeh 2y ago
> As soon as you have any kind of interactive UI, either you do sever roundtrips for everything (which is usually unacceptably slow) or you have client-side state. Tabbed form section? State. Two-level dropdown? State. Radio button enabl
16.
by hmeh 2y ago
Not a Rails shop. We did React and Node almost exclusively for 6 or more years. My first React project started in 2014 or so. I mentioned this in several comments. We had done Rails in the distant past, but using Rails was actually a risk f
17.
by hmeh 2y ago
I hear you. I reached for React for 6 year or so. I built the first application for the client I've been working for for the last 4 years with React. We built the next 20+ w/ server rendered Rails. The interactivity was the same.
18.
by hmeh 2y ago
> So now you have two, entirely separate worlds that don't compose in any way, and you have to create "DTO"s to convert from one to the other and back. "Now" being what specifically? The technologies I mentioned
19.
by hmeh 2y ago
> The problem is building a front-end UI with compositional components (essentially the only way to build anything substantial) Server-rendered front end frameworks (like Rails) have units of composition as well (partials, helpers). >
20.
by hmeh 2y ago
Meh, indeed :) Thank you for your response, it's a fair question and critique. It'd be rather challenging to write guidance on which technology to use to build an application. Thorough guidance would need to consider far too much.
21.
by hmeh 2y ago
I know what analogies are. I was extending yours. I was just saying that there are tradeoffs. You don’t think there are, and that’s fine. I can see them and I make my choices accordingly.
22.
by hmeh 2y ago
HTML, specifically react-dom. It’s built with JavaScript
23.
by hmeh 2y ago
Have you heard of HTML, CSS and forms? They are even more boring, more mature, more stable, often faster, have a huge community, massive resources and ecosystem. React is even built on one of these technologies!
24.
by hmeh 2y ago
You literally cannot. You can bake two cakes. You can’t have your cake and eat it too. Server and client rendering? You must concern yourself with both. The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. Whe
25.
by hmeh 2y ago
Ironically the first question you ask is the question people should be asking about React. Specifically, what problem does it solve, and do I have that problem? The problem most teams tend to face, and I believe part of the authors argument
26.
by hmeh 2y ago
The confusion in the article is so complete that I'm left wondering whether or not the author is aware that what they are writing is not, in fact, HTML.
27.
by hmeh 2y ago
Substantial | Senior Software Developer | REMOTE (US) | Contract or Contract-to-Hire We're a software consultancy originally based in Seattle. I lead a team that has been working with a client for the last 4 years building software to
28.
by hmeh 2y ago
Believe it or not, the problem is likely that they are consulting UI "experts". Many designers responsible for this stuff (at least the ones I've worked with, and I can extrapolate based on what other companies have release
29.
by hmeh 2y ago
You may be conflating microservices and horizontal scaling. You don't need to have multiple (disparate) microservices to scale. Microservices have absolutely nothing to do with scaling. That's a myth started by people who never un
30.
by hmeh 2y ago
For what it's worth, what you are describing is a pretty well known failure mode. It was known in the days of CORBA and DCOM, and then again in the days of SOAP web services. Microservices as a distributed monolith is not how you parti

More ›