alexedwards

.
├── go.mod
├── handlers
│   ├── books
│   │   └── books.go
│   └── env.go
├── main.go
└── models
    └── models.go

purkhusid

# -*- coding: utf-8 -*-
# Generated by the protocol buffer compiler.  DO NOT EDIT!
# source: deployment/scripts/util/bazel-affected-targets/query.proto

import sys
_b=sys.version_info[0]<3 and (lambda x:x) or (lambda x:x.encode('latin1'))
from google.protobuf import descriptor as _descriptor
from google.protobuf import message as _message
from google.protobuf import reflection as _reflection
from google.protobuf import symbol_database as _symbol_database

ForgottenUmbrella

How to publish Python apps for human beings

So, you've created a Python app (be it a graphical user interface with Qt or the like, or a simple command line interface). Great! But how are others going to use it? Python applications often have dependencies (e.g. from third-party modules), and they also need a Python interpreter to run them. For a developer, installing all the necessary bits and bobs to make things work is okay, but that's unacceptable for a normal user - they just want to download the thing and run it.

Below are simple instructions to publish your app on the three main operating systems: Windows, macOS and Linux.

subfuzion

Overview

This gist is based on the information available at golang/dep, only slightly more terse and annotated with a few notes and links primarily for my own personal benefit. It's public in case this information is helpful to anyone else as well.

I initially advocated Glide for my team and then, more recently, vndr. I've also taken the approach of exerting direct control over what goes into vendor/ in my Dockerfiles, and also work from isolated GOPATH environments on my system per project to ensure that dependencies are explicitly found under vendor/.

At the end of the day, vendoring (and committing vendor/) is about being in control of your dependencies and being able to achieve reproducible builds. While you can achieve this manually, things that are nice to have in a vendoring tool include:

SKempin

Git Subtree Basics

If you hate git submodule, then you may want to give git subtree a try.

Background

When you want to use a subtree, you add the subtree to an existing repository where the subtree is a reference to another repository url and branch/tag. This add command adds all the code and files into the main repository locally; it's not just a reference to a remote repo.

When you stage and commit files for the main repo, it will add all of the remote files in the same operation. The subtree checkout will pull all the files in one pass, so there is no need to try and connect to another repo to get the portion of subtree files, because they were already included in the main repo.

Adding a subtree

Let's say you already have a git repository with at least one commit. You can add another repository into this respository like this:

bobbytables

#!/usr/bin/env bash
# This script is meant to build and compile every protocolbuffer for each
# service declared in this repository (as defined by sub-directories).
# It compiles using docker containers based on Namely's protoc image
# seen here: https://github.com/namely/docker-protoc

set -e

REPOPATH=${REPOPATH-/opt/protolangs}
CURRENT_BRANCH=${CIRCLE_BRANCH-"branch-not-available"}

codefromthecrypt

I've had many people ask me questions about OpenTracing, often in relation to OpenZipkin. I've seen assertions about how it is vendor neutral and is the lock-in cure. This post is not a sanctioned, polished or otherwise muted view, rather what I personally think about what it is and is not, and what it helps and does not help with. Scroll to the very end if this is too long. Feel free to add a comment if I made any factual mistakes or you just want to add a comment.

So, what is OpenTracing?

OpenTracing is documentation and library interfaces for distributed tracing instrumentation. To be "OpenTracing" requires bundling its interfaces in your work, so that others can use it to time distributed operations with the same library.

So, who is it for?

OpenTracing interfaces are targeted to authors of instrumentation libraries, and those who want to collaborate with traces created by them. Ex something started a trace somewhere and I add a notable event to that trace. Structure logging was recently added to O

sachin-kmr

// C++ includes used for precompiling -*- C++ -*-

// Copyright (C) 2003-2013 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library.  This library is free
// software; you can redistribute it and/or modify it under the
// terms of the GNU General Public License as published by the
// Free Software Foundation; either version 3, or (at your option)
// any later version.

hello-josh

package main

import (
	"fmt"
	"sync"
)

type Fetcher interface {
	// Fetch returns the body of URL and
	// a slice of URLs found on that page.

snambi

# create an UDP server using nc on port 11090
nc -ul 11090

# check whether an UDP server is listening on 11190
nc -vz -u <hostname> 11090

# send a packet to the UDP server
echo -n "hello" | nc -4u -w1  <hostname> 1118