paulhodge

Zerotier is an awesome tool for this.

That argument sucks. Yes there are sites with poor accessibility, but there's also a lot of sites that are fine. It would be a huge step backwards if they switched from DOM to Canvas.

HTML isn't legacy cruft, it's an essential part of the web that will never go away. If you want to ship an app with no HTML, then use a different platform.

If you really want to talk about cities that have turned into malls, talk about Singapore.

Definitely agree about the ports. Whenever I pull out my old 2013 Macbook, it feels like a futuristic luxury to have a builtin (standard) USB port.

Yeah, that’s part of it. The attacker wants to hit a url that isn’t already cached by CDN. That might be easy or hard depending on the site. Like if the CDN just has a 30 minute TTL, the attacker will need to be the first request right after the 30 minutes expires.

Funny I just looked up this phrase too, someone said it on Succession.

Has anyone actually used json-based queries in PG in a nontrivial way, and had a good experience? I looked into it but the SQL syntax for doing json operations was crazy complicated, and I had trouble finding an ORM that did a good job of simplifying it.

Nice article. Nautilus is terrific. The research here isn’t all new though, it goes back to Erikson's stages of psychosocial development. I love checking in on the stages every once in a while, it helps me figure out what goals would make me happy. Also helps to better understand people who are at a different age range.

One of the their core values is "don't be evil", isn't that statement inherently political? I think a lot of people chose to work at Google (instead of say Oracle or etc) because of those ideals. Kinda disingenuous to advertise that reputation and then switch to a policy of "actually shut up and do the work".

async/await helps a lot, but there are still a few common errors with them...

1) Not calling promises in parallel. Easy to do because it's impossible to run them in parallel with just "await", need to use Promise.all() or something.

2) Forgetting to write "await". If you try to use the return value then now you have a Promise object instead of the actual value. But the worst is when the code doesn't use the return value. Then it has a really subtle race condition that's hard to find. Or if the promise has any errors, then you might get the dreaded "Unhandled promise rejection" with a useless stack trace, and you might need to search the entire codebase to find where it happened.

OOP was a huge trend in the 90s and I think a lot of devs have learned from experience the ways in which it kinda sucks..

- It doesn’t do great as the code gets older or more complex. Google “fragile base class problem”.

- Inheritance doesn’t do a good job of modeling most real-world problems. Most situations don’t map into a simple “class Dog extends Animal” kind of hierarchy. Steve Yegge’s “the kingdom of nouns” is a great rant on this topic.

- OOP actually requires expert-level knowledge to do right. It seems like it’s beginner-friendly but that’s kind of deceptive. If you’re using inheritance then you should understand Liskov substitution, otherwise it’s not going to work well. And if there’s generics involved then you might need to understand covariance vs contravariance, which is also a beginner-hostile expectation.

Imo, out of the newer languages, I really like Golang’s take. Interface-heavy, no inheritance, and some nice sugar around composition. Dunno if I agree with their lack of generics but I understand the choice, generics create a lot of complexity.

The article sure hypes it up but the code doesn't really solve many problems for you. It's about the same level of a framework as Backbone.js but with way less features.

Yeah, I had a huge improvement in my posture from a lifting regimen, it really counteracts the bad habits from sitting all day. Deadlifts and front squats feel like they're the most effective. The great thing about lifting is that it trains your muscles to want to hold correct posture (as in, you don't need to constantly remember to sit up straight). Wish I had gotten introduced to lifting earlier in life, it always seemed like some intimidating thing that was just for the bros club.

For me I got a great intro by doing Crossfit. They’re pretty welcoming to newbies and they include both powerlifting and olympic lifting (although they usually don’t do bench presses). The gyms use rubber weights & floors so that you can always drop the barbell, which is pretty nice while learning.

Either way, definitely find something where you have an in-person coach. Its way too easy to develop bad form habits if you’re just learning from Youtube or something.

Java bytecode is tightly coupled with the JVM.. it doesn't make sense to consider one without the other. There's bytecodes such as invokevirtual or invokeinterface which don't make sense unless you have Java objects and classes.

The benefit of WASM is that it's more general purpose because it's lower level. It's agnostic to your memory model, so you can have a not-Java object model if you want.

Yeah, I agree there’s value to learning and using Promises before async/await, since you often need to think in terms of promise vales when using async.

I don’t think there’s value in teaching a beginner about the prototype chain. It’s kind of obsolete knowledge at this point. ES6 classes work great, and will be very familiar to people coming from other languages.

I mean.. if someone was a beginner in Python would you first teach them about the metaclass system? (I wouldn’t)

Use Typescript. Use async/await. Use ES6 classes, don’t do the other class-like patterns. Oh and use ES6 features in general, like fat arrows. And don’t write “var”.

Don’t use unnecessary compile-to-js syntaxes like Coffeescript since they will just be a burden in the long run. TS and JSX is an exception, those are worth it.

Don’t write “undefined” in your code, just write “null”, and treat those values the same. Some programmers will assign different meanings to “undefined” versus “null” but usually these meanings are arbitrary and silly. In most situations you don’t even need one kind of null, let alone two.

> For 11 minutes a day, 5 days a week, they sat completely still and focused their entire mental effort on pretending to flex their muscles.

Maybe it depends on the person, but that actually sounds more difficult to me than just lifting the weights.

I can't find the link right now, but there was a similar study that found this effect for golf. The study had 3 groups: one control group that did nothing, one group that spent time thinking about playing golf, and one group that actually played. At the end of the study, the "actually played" group had the most improvement, and the "thinking" group improved almost as much as the "actually played" group.

It's not just a matter of switching your brain, it's also about reusing code across projects, and being able to use the same toolset for everything.

But on the topic of switching your brain, you have to know that not all developers can switch between languages as easily, they aren't all special geniuses like you.

Even after 10 years or so, when the tooling is good enough to match the debugging experience we have now, it won't be a moot issue. There will be a much more common problem where you want to examine/modify the source code for a site, and you can't, because that site only published the non-debug WASM. One of the things that keeps the web platform healthy is the way that client-side sources are pretty visible.

In response to "But JS can be obfuscated/minified" - Minified JS is still much easier to examine/modify than WASM, and it's really rare for a site to deliberately obfuscate their JS beyond minification.

I have a pet peeve whenever people bring up the old "Billion dollar mistake" quote. Calling it a mistake means that it could have been avoided. But we couldn't have avoided null pointer errors (or some other name for the same thing) any more than humans could have avoided the bronze age. In the 60s and 70s we didn't have the "technology" to avoid null errors. By technology I mean production-ready languages with a static typing layer sophisticated enough to implement a Maybe/Optional type. Those languages weren't production ready until maybe around the 80s. And most of those compilers were themselves implemented in unsafe-null languages like C.

But anyway, that's history, now we have nice languages that have safe nulls, so the interesting questions moving forward are: why are people still creating new languages that have unsafe nulls (looking at you Go), and why are people still choosing to use languages with unsafe nulls?

A lot of these “lists of lists” are just “Something A-M” and “Something N-Z”. That’s just a paginated list!

You don't need Bitcoin to have a process like that.

Or to say it another way... considering that they didn't have any extra checks on this transaction, what reason is there to think that they would actually use that multi signature thing, if they were on Bitcoin?

Just last night I tried using A-Frame with a Vive but was disappointed by the performance. The framerate is fine but there seems to be a tiny lag, between the time when the headset position changes until the worldspace camera is updated. Made me feel a little nauseous.

The challenge is when there are multiple observers that have a different opinion on what order the commands happened in. Redux and Vuex don't have that problem, that's why it's a nonissue there.

Yeah, people talk about necessary complexity vs unnecessary complexity.

"Unnecessary complexity" is all those arcane coding rituals that we do, that our users don't know or care about, but we have to do because our current tools demand it.

We can't get rid of necessary complexity and so we probably can't design a programming interface for someone that is completely illiterate in math & logic.

But what we can do is 1) Eliminate unnecessary complexity, and 2) Provide helpful, structured, interactive, learnable tools, which help guide the author as they do all the "necessary" steps. If we just did that then that would be a huge improvement from the state of the art.

If only he had come up with a catchy name and a logo, we would have listened.

I think the branch predictor can be primed with well-crafted data? (start off with a long series of 0s for X)

For the other aspects like getting the cache timing, that does seem harder. I don't really know if it's feasible in practice.