- Delete unused or obsolete files when your changes make them irrelevant (refactors, feature removals, etc.), and revert files only when the change is yours or explicitly requested. If a git operation leaves you unsure about other agents' in-flight work, stop and coordinate instead of deleting.
- Before attempting to delete a file to resolve a local type/lint failure, stop and ask the user. Other agents are often editing adjacent files; deleting their work to silence an error is never acceptable without explicit approval.
- NEVER edit
.envor any environment variable files—only the user may change them. - Coordinate with other agents before removing their in-progress edits—don't revert or delete work you didn't author unless everyone agrees.
- Moving/renaming and restoring files is allowed.
- ABSOLUTELY NEVER run destructive git operations (e.g.,
git reset --hard,rm,git checkout/git restoreto an older commit) unless the user gives an explicit, written instruction in this conversation. Treat t
Error
The authenticity of host 'github.com (140.82.113.4)' can't be established.
Fix
ssh-keyscan github.com >> ~/.ssh/known_hostsTo convert animation GIF to MP4 by ffmpeg, use the following command
ffmpeg -i animated.gif -movflags faststart -pix_fmt yuv420p -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" video.mp4
movflags – This option optimizes the structure of the MP4 file so the browser can load it as quickly as possible.
pix_fmt – MP4 videos store pixels in different formats. We include this option to specify a specific format which has maximum compatibility across all browsers.
| /** | |
| * Copyright 2018 Google Inc. All rights reserved. | |
| * | |
| * Licensed under the Apache License, Version 2.0 (the "License"); | |
| * you may not use this file except in compliance with the License. | |
| * You may obtain a copy of the License at | |
| * | |
| * http://www.apache.org/licenses/LICENSE-2.0 | |
| * | |
| * Unless required by applicable law or agreed to in writing, software |
| /** | |
| * Inspired by ebidel@ (https://gist.github.com/ebidel/1b418134837a7dde7d76ed36288c1d16) | |
| * @author surma@ | |
| * License Apache-2.0 | |
| */ | |
| function* collectAllElementsDeep(selector = '*', root = document.all) { | |
| for (const el of root) { | |
| if (!el.matches(selector)) | |
| continue; |
| 'use strict'; | |
| const admin = require('firebase-admin'); | |
| module.exports = function (app) { | |
| app.get('/api', function (req, res) { | |
| res.json({ 'version': '0.1' }) | |
| }); |
The trend of using monorepos makes a lot of things easier to manage. However, when you want to fork a single package inside a monorepo, you'll have to chose one of two options:
- Fork the entire monorepo (meaning you get all those extra boilerplate you don't really care about)
- Manually copying the package files into a new git repo (meaning you'll loose all git history and have a lot of work to do when there's a new version of your base package)
The good news: There's a solution for this! And it's actually built in to git.
One of the lesser-known (and vaguely documented) features of git is subtree. It's intended for this purpose, working as a great alternative to the criticized submodules.
There are very few resources about using this in practice, so here's a guide for this specific use case.
| // async/await"able" DOM event handlers | |
| async function getMeSomeData() { | |
| // ... | |
| return data | |
| } | |
| document.addEventListener('DOMContentLoaded', async () => { | |
| const someContainer = document.getElementById('someContainer'); |
The code here captures some of the patterns I used in the "real estate" demo app discussed in my talk End to End Apps with Polymer from Polymer Summit 2017.
There are many ways to connect Redux to custom elements, and this demonstrates just one pattern. The most important aspects are to try and lazily-load as much of the otherwise global state management logic along with the components that need them (as shown via the lazyReducerEnhancer and addReducers calls in the connected components), and to consider the tradeoffs you make in terms of coupling components to the store.
The pattern shown here of creating a stateless component and then a subclass that connects it to the store addresses a potential desire to reuse app-level stateless components between more than one application context, so the subclass provides a degree of decoupling from the concrete store, at the expense of more boilerplate. If app com
| <!DOCTYPE html> | |
| <html lang="en"> | |
| <head> | |
| <title></title> | |
| <meta charset="UTF-8"> | |
| <meta name="viewport" content="width=device-width, initial-scale=1"> | |
| </head> | |
| <body> | |
| <h2>Hello from outside the Shadow DOM!</h2> | |