Akkuma
Remote: Yes (only)
Willing to relocate: If you make selling my house painless perhaps or pay enough to justify it
Technologies: JavaScript, Node, TypeScript, React, Solid, Bun, AWS, CI/CD
Resume/CV: https://akkuma.github.io/resume
Email: JS for my email atob('Z3JlZ29yeXdheG1hbitobkBnbWFpbC5jb20=')
My personal site: https://akkuma.github.io
17+ years in engineering (staff/principal) with 17+ years in JavaScript, Node since Ryan Dahl was working on it, React before it had a major version. Check resume for full list, which includes using lots of TypeScript, .Net, minor Elm, minor Ruby, minor Python, minor Elixir) with interest and willing to learn other languages like Rust.
Remote: Yes (only)
Willing to relocate: If you make selling my house painless perhaps or pay enough to justify it
Technologies: JavaScript, Node, TypeScript, React, Solid, Bun, AWS, CI/CD
Resume/CV: https://akkuma.github.io/resume
Email: JS for my email atob('Z3JlZ29yeXdheG1hbitobkBnbWFpbC5jb20=')
My personal site: https://akkuma.github.io
17+ years in engineering (staff/principal) with 17+ years in JavaScript, Node since Ryan Dahl was working on it, React before it had a major version. Check resume for full list, which includes using lots of TypeScript, .Net, minor Elm, minor Ruby, minor Python, minor Elixir) with interest and willing to learn other languages like Rust.
I've only started to think about this and I'm thinking the hardest part will be dealing with cross-cutting concerns (in a non-auto sharded world manually creating multiple database) and trying to find a way to keep each database isolated without extra burden compared to using a hosted Postgres.
As an aside, that lan optimized house was a gaming dream. Hope your new house is as awesome.
Remote: Yes (only)
Willing to relocate: If you make selling my house painless perhaps or pay enough to justify it
Technologies: 15+ years in engineering with 15+ years in JavaScript, Node since Ryan Dahl was working on it, React before it had a major version. Check resume for full list (includes using lots of TypeScript, .Net, minor Elm, minor Ruby, minor Python, minor Elixir) with interest and willing to learn other languages like Rust.
Resume/CV: JS for my linkedin atob('aHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2luL2dyZWctY2FuLXRoaW5rLw==')
Email: JS for my email atob('Z3JlZ29yeXdheG1hbitobkBnbWFpbC5jb20=')
I'm currently a Staff Engineer who has and can work the entire stack (architected most of the current frontend I work on, write APIs, can work with databases, have created CI pipelines, etc.), but I've been wanting to become some form of Engineering Manager. I've found mentoring and helping others extremely rewarding and I've been told my passion about technology inspires others. I'd be interested in a purely IC job only at a place that really proves it is worth changing from my current company and job. I'm more interested in either a pure manager position or a "50/50 position (the 50/50 cannot be a paid for one job, doing two jobs 100% & 100%).
Remote: Yes (only)
Willing to relocate: If you make selling my house painless perhaps or pay enough to justify it
Technologies: 13+ years in JavaScript, Node, React, check resume for full list (includes using TypeScript, .Net, Elm, Ruby, Python, Elixir) with strong interest in FP and other languages like Rust
Resume/CV: https://stackoverflow.com/cv/akkuma contains all my technologies I've used
Email: Run this js to decode my email atob('Z3JlZ29yeXdheG1hbitobkBnbWFpbC5jb20=')
If you want a full stack engineer or an expert frontend engineer/UI engineer then I fit that quite well.
Remote: Yes (only)
Willing to relocate: If you make selling my house painless perhaps
Technologies: 13+ years in JavaScript, Node, React, check resume for full list
Resume/CV: https://stackoverflow.com/cv/akkuma contains all my technologies I've used
Email: Run this js to decode my email atob('Z3JlZ29yeXdheG1hbitobkBnbWFpbC5jb20=')
React made writing frontends generally better, but often slower and as rich_harris points out that it entails a lot of developer work to build and use optimizations to speed it up.
I work at Virtru. The short summary is that we make a client-side encryption extension for the content of your email. There are certainly things we can do to reduce the file size. However, the business value of doing so is limited, particularly in the context of an extension. It is also much more limited when Firefox itself is vastly less popular than Chrome today and we have no issues from Chrome.
We use webpack, so all our dependencies, which may not be optimized for file size for browser usage get pulled in as well.
As I previously stated, so not sure why I'm having to repeat this, that the entire process due to the minification creates a huge barrier for any business that is trying to fix things in a reasonable amount of time. You get thrown into an admin queue, which moves at a snail's pace, EVERY time you upload a new version you have to add instructions again, EVERY time there is a different reviewer with the same question you have to answer them again. Mozilla isn't sitting there actually reviewing your source code in an intelligent way. We were dinged on 2 uses of eval. What is hilarious the uses came from within very well known libraries, jQuery, and Bluebird. If they were really reading the source code, they would have known that we didn't write that, 1 of the uses we never call the function that contained it, and bluebird is using it as a de-optimization strategy to prevent a function optimization that make objects fast.
The worse part is that uglify is required for us to even get the extension signed, due to Firefox's arbitrary individual file size limit.
Prior to Mozilla getting their act together it literally was over a month of waiting for them to review our extension, so we just bailed altogether as their entire process is terrible for pretty much no real gain. I then tried again once the queue had dropped from ~400 to ~150 and the wait time finally became reasonable.
I mean the process was/is so bad, they literally had an issue on github to just automatically approve extensions based on some criteria due to the huge backlog. I cannot get an unlisted extension released with the same version as a listed extension, so we completely bailed on using Mozilla's hosting at all, since all it does is cause a liability until we can push out fixes the same day without manual intervention.
To top this off, every single time we make a new release, we'd have to explain the extension, how to build it, etc. and provide sources to the code. Our extension is also a regular web extension.
Ok not really your mother, since I doubt your mother's beard is as luxurious as my own, but we need a call to catch up.
I'll be more concerned once leading technologies that are used by the rest of the world come out of China and not from the US.
In any multithreaded application the Ryzen 1600(x) are just as good if not better. The 1800x to 1700 are even more multithreaded performance and the 1700 is priced a little cheaper than 7700k and able to be OC to the same performance as the 1800x (the entire Ryzen lineup seems to be capable of the same OC, but also capped pretty heavily). The only place that is showing Intel winning are in single threaded scenarios and in gaming scenarios. The gaming scenarios are interesting as one of the more recent benchmarks I saw (https://www.youtube.com/watch?v=3VvwWTQKCZs) was showing in many cases the worse case FPS is better than the 7600k. Additionally, several games have received engine updates that seem to put Ryzen on par with Intel now.
If you call function x with a callback you either handle it immediately via your callback or you have to use some other paradigm to make it compose with other async code. You get no return value allowing you to write code that looks synchronous and forget about the beauty of async/await you've completed abandoned it with callbacks. If you use Promises you can do as you wish and combine them as you wish as they hold values and you can use them multiple times trivially with other Promises,