After a decade of exploring various mechanical keyboards (a few form factors, but mostly exploring the switches), I settled on a Topre Realforce around 2016 and fell in love. I later learned of the Topre silent switches (often branded as "Type-S"), and have used those ever since over many few boards: a HHKB, a Leopold FC660C with a PCB swap for programmable layers, various revisions of the Realforce.
I used a friend's ErgoDox a few years ago, and quite liked it, but what holds me back is the Topre switches. If only it was feasible to acquire individual Topre switches and put them onto a custom PCB...
Here's hoping someone on HN will swoop in and tell me "It's totally possible! Just _____!"
I am also struggling to see what clicking any of the options in the demo changes. I don't consider myself advanced in design knowledge, but I'm pretty average in visual perception.
Perhaps some or all of them don't work in Firefox for Android, and I'm just seeing a fallback behavior that does work?
Edit: Just tested in Chrome desktop and Firefox desktop on Linux, still struggling to see a difference in any of the demo regions (which I assume are supposed to demo the option when selected?). Also scroll behavior is graphically laggy/jumpy in Chrome, but not Firefox.
Played with this a while, and the metaprogramming supporting this is fun :) Once again proving that you can dream up a wild idea, and Ruby will support you in achieving your dreams.
Looking at Syntropy::ModuleLoader, "modules" get to pretend they are in some main-like flat scope, but actually are executing in the instance scope of a Syntropy::ModuleContext. A consequence of this is that it is difficult to imagine these modules (and their exports) interoperating with plain Ruby code that doesn't have access to the `#import` (or needs to eschew it for some reason).
This seems fine in the context of a "closed loop" framework: expect to only ever consume a Syntropy module's `#export` in another Syntropy module, and only using Syntropy's `#import`. That seems like the happy path, but it is a tradeoff: you really need to buy into this "module" system all the way.
There might be an escape hatch, if plain Ruby code (i.e. not another Syntropy module) has access to the instance of ModuleLoader. With that, you can grab an export value via `#load`, which seems fine as long as the thing you need to `#load` isn't a module or class.
Specific to exporting a module or class, it feels natural for me to want to assign it to a capitalized constant when importing. I expected this not to work, as Ruby will reject instance scope `SomeModule = 'some_value'` if I write it as source code (SyntaxError, dynamic constant assignment). However, when I `#instance_eval("SomeModule = 'some_value'")` it as a string (as Syntropy::ModuleContext does), Ruby accepts it? I'm surprised!
The downside is that these end up as some kind of shadow constants, relative to each instance of Syntropy::ModuleContext? That is, they can only ever be accessed by name inside of a string passed to `#instance_eval`. I need to think longer about what the implications are. It's certainly interesting.
Always cool to see a fresh approach to organizing Ruby projects!
Like the author, I have experimented with app structures that better suit my project needs than Rails' conventions (having spent more than half my career partially-or-mostly using Ruby, and most of that using Rails). Sometimes that meant building within Rails and bending it to my desires. Sometimes that meant a blank-slate project layout of my own with some glue bits to talk to Rack. Most of the time the juice was not worth the squeeze, but hope springs eternal.
The one-to-one URL-path-to-folder idea feels neat. I think it would be neat for smaller and/or strictly-API-based projects, but I'm not sure I would prefer it as a strict requirement for large projects. It definitely got my noggin joggin'!
Eschewing one-psuedo-namespace-constant-per-file as a unit of encapsulation and orchestrating your own import and export also got me thinking, but more skeptically. Working in languages that embrace a free-form import/export, I have found that I prefer the one-encapsulated-unit-per-file style. I am going to dig into the Syntropy implementation and see if it inspires me to feel differently about this.
Additionally:
>A further disadvantage is that since everything is global, you might risk touching or referencing classes you shouldn’t, and since dependencies are implicit, those “references by error” may go unnoticed and cause some unexpected (read: undefined) behaviour.
I suspect the author knows this, but it is not the full story to say that "everything is global". Constants are global in that the Ruby VM's has only one hierarchy that for constant lookup. And because Ruby doesn't have namespaces (yet; we'll see what comes of Box), people reuse the constant hierarchy to approximate a namespace.
Local variables and instance variables in your "main" object scope are not global, either. Not only are the isolated from other object instances, the variables of the "main" object are not accessible from the class/singleton scope when declaring a class or module!
And none of these were decisions made by Rails.
>This approach automates the loading of dependencies, using the directory structure as a representation of the app’s namespace (i.e. classes and modules).
If only this were true! The file at app/models/user.rb is not required to declare the constant App::Models::User or even Models::User. One of Rails' three original sins is the layout conventions of the app/ folder, and the conventions built on that.
Yes, technically almost all of it can be configured with some difficulty. My experiments with alternative project layouts using Rails have had mixed success. When you place models and associated core behavior `domain/core/` instead of `app/models`, it's a coin-flip as to whether another developer sees that and says "Oh neat!" or is annoyed. Or when you place pairs of Ruby "view models" and ERB "view templates" in the same directory (e.g. `views/posts/show.rb` alongside `views/posts/show.html.erb`) it throws some people off, even though to me it feels obviously and unquestionably more organized.
EDIT: Removed my comment, as I was referencing the HN article's link. It seems to incorrectly link to a separate comic that is coincidentally also about "surprise".
I agree with bazoom42 in the context of the correct comic:
>Don't you think they have a legit skill issue here and should they be better off upskilling themselves?
Absolutely agree! Just because I understand how they got there doesn't mean I think it's a good state of affairs ;)
My post was already quite long, and I didn't want to append a treatise on what one should do when encountering those engineers. It depends on many details. Avoid hiring them, if that's a power you have. If you are stuck working with them, depending on your authority, encourage them to learn or force them to learn. If you're coming in to clean up after them... well, hopefully your comp is worth the annoyance.
We are all simultaneously in the position of encountering "the world as it is", understanding it, and doing what we can to improve it.
Starting a few years ago, I realized some junior and medior engineers never once considered the possibility of building a website (app, experience, etc.) in anything other than a heavy SPA framework. But they're not stupid people! If you directly asked "Can you build a website without React?" they know the answer is obviously "Yes." However, if you asked them to build a new website, they would unthinkingly start a new React project, mostly out of familiarity and a desire to get the job done.
A few of them would outright not know how to do anything else. No knowledge of how to stand up a boring HTTP server to send pure HTML. No experience building a form that validates or submits without JavaScript. These are not the people who post here on HN. They are not engaged in online discussions of new tools and skills (or old tools and skills!). These are people who learned just enough from a bootcamp, or their uni's single "web apps" course, to get a job. Since then, they have just-in-time learned whatever their employer required, or whatever particular tools someone else on their team chose for a project.
As an old, it took me a while to recognize/realize it, but I understand them now. Depending on their career path, someone will encounter the simplest aspects of HTML, CSS and vanilla JavaScript after they learn the complex, framework-specific aspects of each. It feels (to them) like more esoteric, advanced, or tertiary knowledge.
Tying it back to to the quote "that’s a lot more work for us", that's not necessarily an intentionally false claim. It probably does feel like a lot more work to perform a task using unfamiliar tools, even if they are less-complex tools.
Having gone this route in the past*, once I accepted that I needed a second GPU dedicated as owned by the VM, most issues went away. No SR-IOV battles, just the simplicity of "Linux owns GPU A, Windows VM owns GPU B".
If I am remembering my build from the time, I had an RX 580 for Linux, and a GTX 1070 as passthrough to the Windows VM. At first, it felt like I was "giving up" on solving some problem that felt like it should be solvable, but it worked so well that I couldn't argue with the results.
It also assumes you have a motherboard with the right slots and enough PCIe lanes to get the performance out of two GPUs, and assumes you have a PSU with the power budget to support both GPUs. It definitely was a compromise, not perfection.
*Approx 2017 to 2020, before Proton or when it was was still new/immature. I now no longer care enough about games to play one when it doesn't just work on Linux. I assume the author does not feel this way.
There's also much more to Shopify than just Ruby feature work. I've heard tales of their infrastructure and it seems like it would be very exciting for the right kind of person.
Never worked there, probably never will, but they have my respect for the things I have seen, read and heard.
I have taken applications from 2-to-3, 3-to-4, and so on, through 8.X.
If anything it has gotten better/easier over time. The most challenging upgrades were 2.X to 3.X (for reasons I can't recall), and then 6.X to 7.X (for an application that had issues adopting zeitwerk). In both of those situations, there was a lot of rote legwork, but once tests were passing, the application was working reliably. The other upgrades (3-to-4, 4-to-5, 5-to-6, 7-to-8) weren't happy-fun-rainbows-and-unicorns, but they weren't catastrophically complicated? Not even in fairly large codebases.
For each of these, a strong test suite was the best tool, which it sounds like you already know?
In my experience, the other impactful factors were:
(1) Reading the CHANGELOGs and knowing enough about Rails to know what they meant for the application.
(2) Using test fixtures (or fixtures with only some factories) for a quicker feedback loop for engineers.
(3) Having a true QA function in the company that isn't just engineers testing their own code.
>one could also expect a functioning city to not have flooded streets
In some cities, certain streets are designed to flood during heavy rain, and are an integral part of routing the water away from neighborhoods and businesses, and into the drainage systems.
>The Times was also in the midst of a leadership transition, and new management tends to want to move on from the old regime’s pet projects, even if they were successful.
Learning about B2B sales over the years, the size of this leadership-change factor has been among the most eye-opening (and among the most disappointing).
It cuts both ways: You can have a successful pilot that doesn't proceed because this-or-that VP was replaced, and to show off their bold new direction, the new VP cancels almost everything novel the previous person started. Or you can reach out just at the moment the new guy or gal comes in, right when they're looking for the pieces of their bold new direction, and you become part of that.
I would love to have later learned that leaders who evaluate opportunities separate from personal attachment are seen as more efficient, better, and selected favorably; that more successful companies are less subject to this sort of political/careerist whimsy. Alas. At least I have been fortunate enough to experience both directions in quantities that roughly balance out.