You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If you write non-trivial code, inevitably you'll run into a situation where setting up a test is not super readable. Maybe you have to mock a bunch of things, or the input data is a data structure that spans dozens of LOC, or maybe you are testing with a large-ish fixture that was defined in another file because linting or whatever.
Due to the nature of my job, I happen to read a lot of other people's code, so you can imagine how mildly annoying it is when I'm code reviewing something, and the test looks something like this:
test('codemod does what it needs to',async()=>{
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Friday Fun: Svelte-like variable reactivity in 7LOC with with Proxy
Friday Fun: Svelte-like variable reactivity in 7LOC with with Proxy
Every once in a blue moon, I like to hack up some crazy toy proof of concept to get away from everyday's stiff serious production-ready coding. This morning, I decided to mess around with an idea of implementing something similar to Svelte's reactive variables, but using pure Javascript.
So here's that godawful eye-bleeding fun hack: a 7-line "svelte" (needless to say, it doesn't do nearly enough to be useful in the real world and breaks just about every best practice rule in the book because why the hell not)
Dear Javascript developer, OOP and FP are not opposites
Dear Javascript developer, OOP and FP are not opposites
In the Javascript community, I sometimes hear people say they prefer FP over OOP, and that FP is good and OOP is bad. The line of argument implies there's an FP vs OOP dichotomy, and that one should aim to use one and avoid the other.
I like to quote the Qc-Na parable because it illustrates a subtle but important insight about the two paradigms: they are not opposites and in fact have a lot in common. Here's the parable for those who haven't seen it:
The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."
Chastised, Anton took his leave from his master and returned to his cell, int
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters