In Git you can add a submodule to a repository. This is basically a repository embedded in your main repository. This can be very useful. A couple of usecases of submodules:
- Separate big codebases into multiple repositories.
func openbrowser(url string) { | |
var err error | |
switch runtime.GOOS { | |
case "linux": | |
err = exec.Command("xdg-open", url).Start() | |
case "windows": | |
err = exec.Command("rundll32", "url.dll,FileProtocolHandler", url).Start() | |
case "darwin": | |
err = exec.Command("open", url).Start() |
package main | |
import ( | |
"crypto/tls" | |
"crypto/x509" | |
"flag" | |
"io/ioutil" | |
"log" | |
"net/http" | |
) |
App configuration in environment variables: for and against | |
For (some of these as per the 12 factor principles) | |
1) they are are easy to change between deploys without changing any code | |
2) unlike config files, there is little chance of them being checked | |
into the code repo accidentally | |
3) unlike custom config files, or other config mechanisms such as Java |
Three comparison points: | |
Presto + RCFile vs Impala + RCFile vs Impala + Parquet | |
Note: Query time, CPU utilization, Disk read tput (KBRead) | |
Impala v1.1.1 | |
Presto v0.52 | |
================================================================================================================================ | |
Presto + RCFile: | |
select ss_sold_date_sk, count(*) from store_sales_rcfile group by 1 order by 1 limit 2000; |
One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.
Most workflows make the following compromises:
Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the secure
flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection.
Use production SSL certificates locally. This is annoying
#include <set> | |
#include "USBNotify.h" | |
USBNotify::USBNotify() | |
{ | |
} | |
USBNotify::~USBNotify() | |
{ |
package csvdata | |
// csvdata complements the csv package by allowing you to map a custom structure to | |
// the columns of data in a CSV file. The struct needs to be annotated so that each | |
// field can match a column in the data | |
// | |
// type Person struct { | |
// FirstName string `field:"First Name"` | |
// Second_Name string | |
// Age int | |
// } |
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