In your command-line run the following commands:
brew doctor
brew update
In your command-line run the following commands:
brew doctor
brew update
//oauth2 auth | |
chrome.identity.getAuthToken( | |
{'interactive': true}, | |
function(){ | |
//load Google's javascript client libraries | |
window.gapi_onload = authorize; | |
loadScript('https://apis.google.com/js/client.js'); | |
} | |
); |
#!/usr/bin/env bash | |
# --------------------------------------- | |
# Virtual Machine Setup | |
# --------------------------------------- | |
# Adding multiverse sources. | |
cat > /etc/apt/sources.list.d/multiverse.list << EOF | |
deb http://archive.ubuntu.com/ubuntu trusty multiverse | |
deb http://archive.ubuntu.com/ubuntu trusty-updates multiverse |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
I was chasing down another issue (slow "Save As") and thought these two issues may have been related (with QuickLook being the common broken link). Unfortunately, my "Save As" dialog is still miserably slow on the initial load; but IconServicesAgent hasn't gone above 30MB and he rarely makes an appearance in the Console!
Some of these steps may not be necessary, but here are all of the steps I took that inadverdently put IconServicesAgent back in its place. Note: all commands are a single-line, if they appear to be multiple that's just the forum formatting.
Check for any QuickLooks related .plist files. In a terminal: mdfind com.apple.quicklook. -name .plist
I only had files at the system level (specifically within /System/Library/LaunchAgents/). If you have others, modify the directions below to take that into account (re-introducing plist files from the system level back up to the user).
Make some temporary directories to store these plist files, just in case: mkdir ~/tmp-quicklook
/* | |
* Licensed to the Apache Software Foundation (ASF) under one or more | |
* contributor license agreements. See the NOTICE file distributed with | |
* this work for additional information regarding copyright ownership. | |
* The ASF licenses this file to You 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 | |
* |
// URL for Jira's REST API for issues | |
var getIssueURL = "https://[Your Jira host]/rest/api/2/issue/"; | |
// Personally I prefer the script to handle request failures, hence muteHTTPExceptions = true | |
var fetchArgs = { | |
contentType: "application/json", | |
headers: {"Authorization":"Basic [Your BASE64 Encoded user:pass]"}, | |
muteHttpExceptions : true | |
}; |
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