| #!/bin/bash | |
| # Link: <https://gist.github.com/jellybeansoup/db7b24fb4c7ed44030f4> | |
| # | |
| # A command-line script for incrementing build numbers for all known targets in an Xcode project. | |
| # | |
| # This script has two main goals: firstly, to ensure that all the targets in a project have the | |
| # same CFBundleVersion and CFBundleShortVersionString values. This is because mismatched values | |
| # can cause a warning when submitting to the App Store. Secondly, to ensure that the build number | |
| # is incremented appropriately when git has changes. | |
| # |
| # The command finds the most recent tag that is reachable from a commit. | |
| # If the tag points to the commit, then only the tag is shown. | |
| # Otherwise, it suffixes the tag name with the number of additional commits on top of the tagged object | |
| # and the abbreviated object name of the most recent commit. | |
| git describe | |
| # With --abbrev set to 0, the command can be used to find the closest tagname without any suffix: | |
| git describe --abbrev=0 | |
| # other examples |
| # In order for gpg to find gpg-agent, gpg-agent must be running, and there must be an env | |
| # variable pointing GPG to the gpg-agent socket. This little script, which must be sourced | |
| # in your shell's init script (ie, .bash_profile, .zshrc, whatever), will either start | |
| # gpg-agent or set up the GPG_AGENT_INFO variable if it's already running. | |
| # Add the following to your shell init to set up gpg-agent automatically for every shell | |
| if [ -f ~/.gnupg/.gpg-agent-info ] && [ -n "$(pgrep gpg-agent)" ]; then | |
| source ~/.gnupg/.gpg-agent-info | |
| export GPG_AGENT_INFO | |
| else |
| :root { | |
| --ease-in-quad: cubic-bezier(.55, .085, .68, .53); | |
| --ease-in-cubic: cubic-bezier(.550, .055, .675, .19); | |
| --ease-in-quart: cubic-bezier(.895, .03, .685, .22); | |
| --ease-in-quint: cubic-bezier(.755, .05, .855, .06); | |
| --ease-in-expo: cubic-bezier(.95, .05, .795, .035); | |
| --ease-in-circ: cubic-bezier(.6, .04, .98, .335); | |
| --ease-out-quad: cubic-bezier(.25, .46, .45, .94); | |
| --ease-out-cubic: cubic-bezier(.215, .61, .355, 1); |
Many of us building single-page apps today use JavaScript module bundling tools that trend towards a monolithic "bundle.js" file including the full app and vendor code for multiple routes. This means if a user lands on any arbitrary route they need to wait for a large bundle of JS to be fetched, parsed and executed before the application is fully rendered and interactive.
This is a little backwards, especially when apps are used under real-world network (3G) and device
First, take a look at the ESLint rule documentation. Just skim it for now. It's very long and boring. You can come back to it later.
ESLint rules works on the AST (Abstract Syntax Tree) representation of the code. In short, this is a tree structure that describes the code in a very verbose form. ESLint walks this tree and rules can subscribe to be notified when it hits a specific node type, like a Literal type, which could be the "hello" part of const welcome = "hello";.
Go ahead and play around with some code in AST Explorer (Make sure the parser is espree). It's a great tool!
Here are some good articles on the subject (ignore the scaffolding parts):
| ################## | |
| ### config.yml ### | |
| ################## | |
| version: 2 | |
| jobs: | |
| build: | |
| docker: | |
| - image: circleci/python:3.6 | |
| steps: |
Your Service Worker script will need to import in Workbox and initialize it before calling any of the routes documented in this write-up, similar to the below:
importScripts('workbox-sw.prod.v1.3.0.js');
const workbox = new WorkboxSW();
// Placeholder array populated automatically by workboxBuild.injectManifest()
export x = 42
| #TabsToolbar { | |
| height: 32px; | |
| } | |
| #TabsToolbar > .toolbar-items, | |
| #TabsToolbar > .titlebar-spacer { | |
| visibility: hidden | |
| } | |
| #nav-bar { |