`1 + 1` in Ruby is syntactic sugar for `1.+(1)`. Nothing wrong about it at all, it's just different from what you're apparently used to. This type of thing isn't even unique to Ruby or even OOP.
The last time I went to Steve's Music Store (Toronto, Canada) they were still using the green on black terminals. This was pre-pandemic. Maybe someone can confirm if they still are.
Interesting, I love Minecraft's music. I do listen to it intentionally outside of the game, but it's not quite the same as having it suddenly start up during gameplay. The first I heard of someone "obviously turning off the music" was, I kid you not, yesterday, and now I'm hearing it for a second time today. Would woulda thunk!
There are soundtracks I listen to outside of their games: Castlevania Symphony of the Night, Chrono Trigger, Shadowgate,... but Minecraft would be way near the end of the list. The music is too generic to be worth the attention, yet too present to work as ambiance. It kinda reminds me of Silent Hill's soundtrack.
I turn off the in-game music while playing. I prefer to listen to my own stuff, including video essays etc, but I do still enjoy a lot of the music, and I've listened to it standalone a decent amount. I would tend to the same in most sandbox games, like factorio
I like this approach. The only problem (or at least one of the problems) is that many people do not have suitable personal projects, as in they might be 10 years old. If one of the goals is to filter out people that don't work on projects in their free time, then this works, but I know many good programmers who don't, or at least they don't anymore due to having kids and other responsibilities outside of work.
As this article touches on, I'm big into pair programming interviews. I was part of the pair programming step at a past company and we'd always use StringCalc [0]. It's starts out super easy and gets gently progressively harder. The goal isn't to finish but to just to see how people think. We would do pretty legit pairing where we'd help if they got stuck on anything or thought we had a better solution. This shows so much about how someone thinks, collaborates, and responds to feedback. Often within 10 mins I could tell how it was going to go. We always had to finish, though, just in case.
Of course it depends on what type of app you have and how your company works and so on and so forth.
As a fan of both, the LiveView DX is simpler than Hotwire's (though of course there are trade-offs both ways). With Hotwire you have the think about frames whereas LiveView is more like React where you just change the state and the appropriate diff is patched in without having to think about much else. This is not to say that Hotwire's frames are complex, LiveView is just that much simpler in that regard.
Yep, that's the whole thing, these technologies have strengths and weaknesses for different application. But of course most people just want to learn only one (and I don't blame them).
Ya, this was not worded well at all (and more likely just not well researched (in the article, I mean). The difference between hotwire/livewire and LiveView is that with LiveView you get a "live" connection to persistence BEAM process which comes with benefits like not having to rebuild things (like the current user) on each request and storing ephemeral state on the server (if you need it). Of course there are trade off like PWAs are not fun in LiveView (you likely just wouldn't do it, I never have).
This particular bit does seem interesting and would make sense to take advantage of the BEAM's cheap green threads. Couldn't find any info on LiveView's GitHub landing page nor the Phoenix website (haven't dug too much), do you happen to have a link?
The guides are the best place to learn about LiveView itself. Since guides are always included as part of the docs (reference docs) people always tend to shy away from them (not saying you are, it's just a thing with people it seems):
Oh also wanted to point out that while there has been an ongoing effort for LiveView Native, it is not there yet (I actually haven't heard anyone talking about it in quite a while). I'm not too in the Rails world so I don't know how good Hotwire Native is, but I assume it's much further along than LV Native, so that's a big thing if you need that. No idea about LiveWire as I've never even been in the Laravel world.
I'm not sure what you mean. This is the vanilla Substack layout.
EDIT: Removed the video because a bug in Substack causes the space bar to play the video instead of scrolling down. Sorry for the unintentional jumpscare.
Exactly this. I really wish browsers would use semantic html to make content more accessible for me, a sighted user! Why does my browser not give me a table of contents I can use to navigate a long page?
I think the parent has a good point: browsers don't do anything with these tags for sighted users, who are unfortunately the majority of developers. If they were to notice benefits to using semantic tags, maybe they'd use them more often.
It’s interesting, because if you imagine sites actually using these tags to be maximally compatible with reader mode and other accessibility modes, they’re setting themselves up perfectly to be viewed without ads.
I use reader mode by default in Safari because it’s essentially the ultimate ad blocker: it throws the whole site away and just shows me the article I want to read.
But this is in opposition to what the website owners want, which is to thwart reader mode and stuff as many ads in my way as they can.
It’s possible good accessibility is antithetical to the ad-driven web. It’s no wonder sites don’t bother with it.
Reader mode seems to still work if you have a div with article text in it. I would be interested to see a comparison of what works and what doesn’t if such a reference exists though!
Reader mode is based on a whole slew of heuristics including tag names, class names, things like link-to-text-content ratio, and other stuff I can't recall. IIRC it considers semantic tag names a stronger signal than e.g. class names, so having <article> in your page isn't necessary but helps a lot.
