I use a GPG key to sign my git commits.
An error like this one might be a sign of an expired GPG key.
error: gpg failed to sign the data fatal: failed to write commit object
import fs from 'fs' | |
var path = require('path'); | |
const FileHound = require('filehound'); | |
import { project as projectProcessor } from '@seleniumhq/side-utils' | |
import { emitTest, emitSuite } from '@seleniumhq/code-export-java-junit' | |
const filesPath = '.' // path to the folder containing SIDE files | |
const downloadPath = path.join(filesPath,'Junit') // Will by default create a JUnit folder in {filesPath} | |
const filesType = 'side' | |
function readFile(file) { |
#!/bin/bash | |
# | |
# Add the script to your crontab, e.g. | |
## */20 6-22 * * 1-5 $HOME/bin/slack-status/slack.sh >> $HOME/bin/slack-status/cron.log 2>&1 | |
set -o nounset | |
set -o errexit | |
set -o pipefail | |
STATUS_VAILD_FOR=1260 # 20min cron + 1min puffer |
<?xml version="1.0" encoding="UTF-8"?> | |
<project xmlns="http://maven.apache.org/POM/4.0.0" | |
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | |
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> | |
<modelVersion>4.0.0</modelVersion> | |
<groupId>org.enner.samples</groupId> | |
<artifactId>packager-with-shade-jar</artifactId> | |
<version>1.0-SNAPSHOT</version> | |
<packaging>jar</packaging> |
(page "index.html") | |
(defc people | |
[{:name "Alan" | |
:age 32 | |
:nickname "Coolpants"} | |
{:name "Felix the Cat" | |
:age 8 | |
:nickname "Cuddles"} | |
{:name "Steve" |
Install HomeBrew first
brew update
brew tap caskroom/cask
brew install brew-cask
If you get the error "already installed", follow the instructions to unlink it, then install again:
# URI of the local (caching) HTTP proxy | |
LOCAL_HTTP_PROXY = 'http://192.168.33.200:8123' | |
# Configures vagrant-cachier and vagrant-proxyconf. | |
# Should be called only on "local machine" providers. | |
def configure_caching(config) | |
if Vagrant.has_plugin?('vagrant-cachier') | |
config.cache.enable_nfs = true | |
config.cache.enable :gem | |
config.cache.enable :npm |
language: java | |
env: | |
global: | |
- SONATYPE_USERNAME=yourusername | |
- secure: "your encrypted SONATYPE_PASSWORD=pass" | |
after_success: | |
- python addServer.py | |
- mvn clean deploy --settings ~/.m2/mySettings.xml |
# source: http://st-on-it.blogspot.com/2010/01/how-to-move-folders-between-git.html | |
# First of all you need to have a clean clone of the source repository so we didn't screw the things up. | |
git clone git://server.com/my-repo1.git | |
# After that you need to do some preparations on the source repository, nuking all the entries except the folder you need to move. Use the following command | |
git filter-branch --subdirectory-filter your_dir -- -- all | |
# This will nuke all the other entries and their history, creating a clean git repository that contains only data and history from the directory you need. If you need to move several folders, you have to collect them in a single directory using the git mv command. |
I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.
I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real