| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <meta charset="utf-8"> | |
| <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=0"> | |
| <title>Test Page</title> | |
| <script> | |
| // early compute the vw/vh units more reliably than CSS does itself | |
| computeViewportDimensions(); |
I'm writing this quick post to respond to a recent twitter conversation where claims were made about the merits (or lack thereof) of transducers, as they relate to composing list comprehensions (map, filter).
For comparison sake throughout the rest of my post, below you'll find three (actually four!) implementations of a simple list operation demo:
| var mockData = getMockData(); // mock API response data | |
| var movieIDs = [ 627, 699, 378, 92, 933, 725, 528, 3, 156, ]; | |
| var movieListings = []; | |
| for (let movieID of movieIDs) { | |
| if (validMovie(movieID)) { | |
| let movieData = lookupMovie(movieID); | |
| if (recentMovie(movieData)) { | |
| movieListings.push( |
Think of a language model as working kind of like a giant database with an index—but let’s start with what a database index is first.
Imagine you’re reading a long book, and as you go, you use post-it notes to mark important words or ideas—like “apple,” “recipe,” or “Paris.”
| var filterReducer = pf => cf => (acc,v) => pf(v) ? cf(acc,v) : acc; | |
| var mapReducer = mf => cf => (acc,v) => cf(acc,mf(v)); | |
| var compose = (...fs) => v => fs.reduceRight((r,f) => f(r),v); | |
| var concat = (acc,v) => [ ...acc, v ]; | |
| var sum = (x,y) => x + y; | |
| // ************************************ | |
| var onlyOdds = v => v % 2 == 1; | |
| var double = v => v * 2; |
| // .. | |
| self.addEventListener("periodicsync",onPeriodicSync); | |
| // .. | |
| await registerPeriodicSync(); | |
| // .. |
| function foo(x) { x = (typeof x != "undefined") ? x : 10; .. } | |
| function foo(x = 10) { .. } | |
| function foo(x,y,z) { .. }; foo.apply(null,[1,2,3]); | |
| function foo(x,y,z) { .. }; foo(...[1,2,3]); | |
| function foo() { var args = [].slice.call(arguments); .. } | |
| function foo(...args) { .. } | |
| var o = { x: 2, y: 3 }, x = o.x, y = o.y, z = (typeof o.z != "undefined") ? o.z : 10; |
This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.
I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.
But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.
If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.
| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <meta charset="utf-8"> | |
| <title>Worker Polyfill</title> | |
| <script src="polyfill.worker.js"></script> | |
| </head> | |
| <body> | |
| <h1>Worker Polyfill</h1> | |
| <script> |
| // Adapted from: https://www.geeksforgeeks.org/find-length-largest-region-boolean-matrix/ | |
| "use strict"; | |
| var M1 = [ | |
| [ 0, 0, 1, 1, 0 ], | |
| [ 1, 0, 1, 1, 0 ], | |
| [ 0, 1, 0, 0, 0 ], | |
| [ 0, 0, 0, 1, 1 ] | |
| ]; |
