Taking the best from what I've seen around, firelist takes inspiration from Jake Knapp's Burner List Concept and the Pomodoro Technique. Additional tricks might follow.
- Commit to short term (1-3 day) focus topic and one secondary topic
- Add rest of ToDos to Dumpster Fire
- Start timer to work on topics in maintainable speed
- Check in regulary on how fcking unfocused you are working on dumpster fire distratctions
- Get better
- The space on page represents importance. Main topic half of the space, dumpster fire 1/4
- If after 10h you are still mainly on the right side of the page you have either a -- focus problem (you/I work on the unimportant) -- goal setting problem (you/I have unrealisitc expectations of what is important)
Minimalistic, very easy to understand boilerplate for Electron runtime. Tested on Windows, macOS and Linux.
Make sure you have Node.js installed, then type...
git clone this repo
cd dfirelist
npm install
npm start
...and you have a running desktop application on your screen.
The application consists of two main folders...
src - files within this folder get transpiled or compiled (because Electron can't use them directly).
app - contains all static assets which don't need any pre-processing and can be used directly.
The build process compiles the content of the src folder and puts it into the app folder, so after the build has finished, your app folder contains the full, runnable application. Treat src and app folders like two halves of one bigger thing.
The drawback of this design is that app folder contains some files which should be git-ignored and some which shouldn't (see .gitignore file). But this two-folders split makes development builds much faster.
npm start
Build process uses Webpack. The entry-points are src/main.js and src/app.js. Webpack will follow all import statements starting from those files and compile code of the whole dependency tree into one .js file for each entry point.
Babel is also utilised, but mainly for its great error messages. Electron under the hood runs latest Chromium, hence most of the new JavaScript features are already natively supported.
Environmental variables are done in a bit different way (not via process.env). Env files are plain JSONs in config directory, and build process dynamically links one of them as an env module. You can import it wherever in code you need access to the environment.
import env from "env";
console.log(env.name);Remember to respect the split between dependencies and devDependencies in package.json file. Your distributable app will contain only modules listed in dependencies after running the release script.
Side note: If the module you want to use in your app is a native one (not pure JavaScript but compiled binary) you should first run npm install name_of_npm_module and then npm run postinstall to rebuild the module for Electron. You need to do this once after you're first time installing the module. Later on, the postinstall script will fire automatically with every npm install.
Run all tests:
npm test
npm run unit
Using electron-mocha test runner with the Chai assertion library. You can put your spec files wherever you want within the src directory, just name them with the .spec.js extension.
npm run e2e
Using Mocha and Spectron. This task will run all files in e2e directory with .e2e.js extension.
To package your app into an installer use command:
npm run release
Once the packaging process finished, the dist directory will contain your distributable file.
Electron-builder is handling the packaging process. Follow dosc over there to customise your build.
You can package your app cross-platform from a single operating system, electron-builder kind of supports this, but there are limitations and asterisks. That's why this boilerplate doesn't do that by default.