Location: Portland, OR
Remote: Remote only
Willing to relocate: No
Technologies: JavaScript, TypeScript, React, Svelte + SvelteKit, NodeJS, GraphQL, Go, Docker, PostgreSQL, MongoDB, Ruby on Rails, Scheme
Résumé/CV: https://benaiah.me/assets/resume.pdf
Email: [email protected]
My name is Benaiah Mischenko, and I am a senior/staff level full-stack developer with 13 years of experience as, at different times, an individual contributor, full-time open-source-maintainer, and team lead. I like to work on interesting and difficult data + UI problems that cross the backend/frontend divide. Both team lead and individual contributor opportunities interest me currently, but I do not wish to move into management.
In the past five years I've worked as a full-time maintainer of Netlify CMS, an open-source project with using React and TypeScript; then worked on the backend of the Netlify build service that runs all of the builds on that service using Go, Docker, Ruby on Rails, NodeJS, and Kubernetes; and since then led an engineering team to an on-time and well-received delivery of a new open-source website for a major department of the state of Louisiana using TypeScript, Svelte + SvelteKit, GraphQL, Contentful, and Vercel.
I'm passionate about project automation, thorough documentation, relieving pain points for other developers and finding ways to accelerate my team as a whole, and being able to contribute across a large stack of technologies to solve problems that involve a full vertical slice of an application. I strive to always grow as a developer and help those around me do the same, whether that be in a formal role as a team lead or as a peer and collaborator.
I'm happy to field any further questions over email, and am available to start immediately.
I have over a decade of experience working at all levels of the stack. After nearly five years at Netlify, I took some time off to work on authorship projects and I'm now finally ready for another opportunity. I've worked on a very complex entirely front-end application allowing you to do content management for static sites (https://netlifycms.org), build infrastructure powering the sites of hundreds of thousands of users, and many other projects. I'd love to join a team doing socially meaningful work at scale with interesting technologies. Please reach out if you are looking for someone with my experience or know someone who is.
The message of "Slaughterbots" (https://www.youtube.com/watch?v=9CO6M2HsoIA) seems both more prescient and more urgent than ever given this news. Our continued reckless development and deployment of autonomous weaponry without thought to the consequences is deplorable, and its consequences could be staggering.
There's no such thing as an unbiased source. Having actually read the linked article, it's a detailed, well-cited, and effective piece. Indeed, it seems the bias you complain about is based on the political stances of the publication and not any merits of the piece itself, as if critiques of capitalism are only valid when written by proponents of capitalism.
Further, this kind of vague belly-aching about the supposed "bias" of an article is very much against the spirit of the board. It casts aspersions, intentionally or not, not only on the article that was linked, but on the commenter who linked it. If you'd like to criticize the article, please do that instead.
> which isn't even the same since it returns `false` if something is null
That's not the case AFAIK - checking in both node and FireFox, `true && null` evalutes to `null`, `true && undefined` evaluates to `undefined`, and `true && null && true` again evaluates to `null`. In what scenario does `&&` coerce the returned value to a boolean?
That sounds really similar to Netlify CMS, especially the use of Git for content storage+version history and the focus on a decoupled UI for editing content. It's really cool to hear from somebody exploring the same space! Git as a backend for content is a really interesting concept that's worked very well for us so far, and I'd be interested to hear how you're implementing that and what issues you've run into. The internationalization approach you describe on the features page is pretty intriguing as well - that's a feature that we should improve our support for in Netlify CMS.
Feel free to ping me using the contact info in my profile or at @benaiah in our Gitter room (https://gitter.im/netlify/NetlifyCMS) if you're interested in discussing this elsewhere.
Yup, improving backend support (and refactoring the backend API to make developing custom backend support easier) is currently my top priority. Initial GitLab support (without the editorial workflow) is very close to being complete - I hope to be releasing an initial PR this coming week if all goes as planned. My latest update in that thread is here: https://github.com/netlify/netlify-cms/pull/517#issuecomment...
The project I work on, Netlify CMS (https://www.netlifycms.org/), is almost precisely what you described in your last paragraph.I say "only" because it only officially supports GitHub as a backend at the moment, from which you can deploy to a host. (I'm also currently working on supporting more backends, so that will change soon.) The CMS is an open-source (MIT license) CMS built as a static web page which connects to an API for an arbitrary backend from your browser and edits the content stored there - from there, you can build the content with whatever static site generator you want. This lets you build sites that non-technical users can keep up-to-date without tying yourself to a specific tech stack for the actual website.
This is a bit aside from your main point, but stopping on a road in a whiteout snow storm is _incredibly_ dangerous due to the cars behind you being unable to see you until it is much too late to stop. I grew up driving two-lane highways in Alaska with frequent semi traffic, several times in blizzard conditions (to the point where the only way to follow the road was to drive on the flat part of the just-fallen snow). You could pull over to the side of the road, but you may not be able to get back on the road depending on your vehicle and the snow level (and in remote, cold areas this may be deadly itself).
You could say "just don't drive in blizzards", but on a long drive you may often end up in a blizzard when you started in clear weather. Frequently this happens in areas where there are no safe places to stop for miles.
I'm not an expert on self-driving car sensors, but it's not hard to imagine that they could be made much less weather-dependent than the human eye. Driving through blizzard conditions is incredibly disorienting and terrifying, so the potential of better-than-vision detection of roads and traffic is IMO the most promising way for self-driving cars to handle snowy conditions.
Netlify continuous deployment is triggered by a Git commit, but you can run arbitrary Node scripts (though not _just_ Node scripts, of course) as part of your build process. I don't know of a way you could trigger deploys based on changes to the Google Sheets app without some code on your end (maybe IFTTT could work?), but everything else should be feasible if I'm understanding you correctly.
Netlify supports running a build script automatically whenever you push to one of our supported Git providers (we also have a CLI tool for those who prefer to do that manually). This includes creating deploy previews for branches other than your main deploy branch (such as PRs).
This is actually how the project I work on, Netlify CMS[0] works - the CMS is a completely open source, front-end application that pushes to GitHub using their REST API. If you’re using Netlify‘s continuous deployment, GitHub’s webhook system notifies Netlify of the push and Netlify’s buildbot builds and deploys the update to your site automatically.
We do indeed offer free HTTPS and custom domain support (as well as the two together) on our free plan. I haven’t used GitLab Pages myself, so I couldn’t compare further off the top of my head.
Your post seems to demonstrate _exactly_ what the post you're replying to is saying: most of the speed has to do with I/O strategy (buffering and syscall usage), not the actual speed of the involved language. Maybe I'm missing a distinction you're making, but I'm not following how your previous comment leads to what you're saying here.
Determinism is indeed a major benefit of the structure I described. I'm curious about your objection, though - where else could the logic be other than in the game loop? In this architecture, your game loop is basically three steps - collect actions, reduce actions, render, repeat.
You can have that kind of flat, global structure without mutability. One way to do that would be to collect all actions done in each frame (instead of mutating) and then apply them all to create a new frame in a single step (a "reduce"). Then you call the game loop function with that frame to create another frame, etc. The issue isn't just global state, it's global and mutable state. Say that your game has a debuff that reduces the damage of an enemy, and your player debuffs an enemy in the same frame that it attacks him. If you're mutating everything, it can be very difficult to figure out or specify what order things like that happen in, since anything can mutate anything else at any time (concurrency makes this much worse). If you're using mutable state, there's no way to tell all the places that could be changing the enemy's damage, because it could be anywhere in the program. If you're passing everything through as arguments, it's very easy to see exactly where state changes occur and make code modifications in isolation without worrying about affecting unrelated behavior.
My name is Benaiah Mischenko, and I am a senior/staff level full-stack developer with 13 years of experience as, at different times, an individual contributor, full-time open-source-maintainer, and team lead. I like to work on interesting and difficult data + UI problems that cross the backend/frontend divide. Both team lead and individual contributor opportunities interest me currently, but I do not wish to move into management.
In the past five years I've worked as a full-time maintainer of Netlify CMS, an open-source project with using React and TypeScript; then worked on the backend of the Netlify build service that runs all of the builds on that service using Go, Docker, Ruby on Rails, NodeJS, and Kubernetes; and since then led an engineering team to an on-time and well-received delivery of a new open-source website for a major department of the state of Louisiana using TypeScript, Svelte + SvelteKit, GraphQL, Contentful, and Vercel.
I'm passionate about project automation, thorough documentation, relieving pain points for other developers and finding ways to accelerate my team as a whole, and being able to contribute across a large stack of technologies to solve problems that involve a full vertical slice of an application. I strive to always grow as a developer and help those around me do the same, whether that be in a formal role as a team lead or as a peer and collaborator.
I'm happy to field any further questions over email, and am available to start immediately.