Inspired by dannyfritz/commit-message-emoji
See also gitmoji.
| Commit type | Emoji |
|---|---|
| Initial commit | 🎉 :tada: |
| Version tag | 🔖 :bookmark: |
| New feature | ✨ :sparkles: |
| Bugfix | 🐛 :bug: |
stowball
/ remote-job-links.md
Last active
December 9, 2024 21:28
List of sites to find remote front-end developer jobs
- https://authenticjobs.com/#category=4&onlyremote=1
- http://www.workingnomads.co/jobs
- https://remoteok.io/remote-jobs
- https://www.wfh.io/search?utf8=%E2%9C%93&query=front&commit=Go%21
- https://stackoverflow.com/jobs?sort=i&q=front&r=true
- https://weworkremotely.com/jobs/search?term=front
- http://jobs.smashingmagazine.com/
- http://frontenddeveloperjob.com/
- http://codepen.io/jobs
- https://news.ycombinator.com/item?id=12405698
popey
/ Google Code-In 2018 Package Electron.md
Last active
February 17, 2021 15:30
Package an Electron application as a snap
We have identified a number of electron-based desktop applications which already have builds for Linux, but are not yet easily available in Ubuntu. The goal of this task it to select one of those applications and update the build system to add snap support.
Many of these applications require a newer version of node/npm to build than is available in Ubuntu. We recommend using Ubuntu 16.04 machine, virtual machine or container. Please do not do this task on a 17.10 system, but use 16.04.
In that 16.04 system, install node/npm from upstream nodesource as detailed at https://github.com/nodesource/distributions#debinstall
You may also want to go through the electron guide, to ensure your system is configured correctly to build electron applications successfully. https://docs.snapcraft.io/build-snaps/electron
getify
/ why-typl-instead-of-ts.md
Last active
July 20, 2022 18:26
describing my motivations for designing TypL instead of using TS/Flow
I am often asked why I don't like a tool like TS (or Flow), and by implication, if I don't like it, the assumption is that I don't want any type aware tooling. That's not true, though.
I have many ideas for what I think type-aware tooling in JS could/should be, and they just happen to diverge significantly enough from TS/Flow that I can't bend into pretzels to fit into that mold.
Instead, I've worked on designing a tool I call TypL that I think addresses my concerns. It's in progress.
Here's my main list of motivations for designing TypL instead of TS/Flow:
- I want a system that has both compile-time checking AND run-time checking. TypL's design is to compile away the stuff that it checks at compile time and can verify, and leave in the stuff that it knows needs run-time checking. That way, you don't have to write different sorts of type checking for compile-time and run-time. You get both from one set of typing annotation. It doesn't really seem tha