grosskur

Congrats on the launch! It's great to see more innovation and choice in the protobuf/gRPC space. Definitely planning to try this out.

For personal projects, I typically have a single Go binary that serves (1) gRPC, (2) grpc-web (using the Improbable library), and (3) gprc-gateway. Along with protobuf-ts for the client, IMO it's quite a pleasant stack. Glad to see timostamm involved in protobuf-es :)

I'm curious: Can you say more about why you ported the code generator from Go to TypeScript (https://github.com/bufbuild/connect-web/commit/8002c2696aad0...)? Was it is easier to generate code this way, or did it just get too unwieldy to package Go binaries in NPM modules?

sqlc can do this: https://sqlc.dev/

Awesome! I've always wanted something like this. Thanks for sharing.

Also:

- Basscss [ http://www.basscss.com/ ]

- Tachyons [ http://tachyons.io/ ]

Could this be a good use case for NSQ? It seems simpler to operate than Kafka, and somewhat more durable than ZeroMQ.

http://nsq.io/

I'm really enjoying using Cask to manage my Emacs packages:

https://cask.readthedocs.org/

You maintain a list of packages in a Cask file and run "cask" to automatically download and install them from a repository like MELPA. Like Gemfile or requirements.txt, but for Emacs.

I found this really reduced the number of elisp snippets I've had to write or grab from around the web. Most popular packages are on MELPA, and there's usually a more polished way to accomplish things I was hacking together myself.

Starting with systemd 219, you can download a Docker image from a registry with "machinectl pull-dkr", and run it with "machinectl start":

http://www.freedesktop.org/software/systemd/man/machinectl.h...

Hi! I'm the creator of Shipway. I'd love to get any feedback folks have. I'm also happy to answer questions.

The overall idea is to make it as easy as possible to go from source code in a Git repository to a running application. Shipway makes heavy use of the GitHub API and tries to act as a thin layer on top. It sets up a GitHub hook to trigger a Docker build when you push commits. It hosts the resulting Docker images in its own registry, and can execute webhooks after successful builds.

There are a few similar products out there, namely Docker Hub and quay.io. Both are interesting in their own way, but neither allows you to carry over your GitHub organizations and teams and use them with Docker repositories.

I'm excited about all the container hosting options that are starting to mature. Once the Kubernetes API stabilizes, it seems like it could become a standard interface for running containers on any cloud. The EC2 Container Service also looks interesting.

Anyway, thanks for checking it out!

You might be interested in the virtual-dom and vdom-thunk NPM packages, which are used in mercury:

https://github.com/Raynos/mercury

See also Raynos's "NPM-style Frontend" presentation:

https://www.youtube.com/watch?v=8w0_Xw7PPFQ

Ryan Smith's "Building Metrics From Log Data" is an interesting talk about this:

http://vimeo.com/68183624

Also check out Heroku's Lumbermill project, which handles extracting router metrics on their platform:

https://github.com/heroku/lumbermill

If you're on AWS, CloudWatch is capable of ingesting log data and extracting metrics via pattern-matching:

http://docs.aws.amazon.com/AmazonCloudWatch/latest/Developer...

When I used Graphite with Nagios, I bypassed all the Nagios data-collection and graphing features. Instead, I funneled all the data into Graphite and used check-graphite to alert on it:

https://github.com/pyr/check-graphite

There's also otto, a JavaScript interpreter written in Go:

https://github.com/robertkrimen/otto

Here's an example Go app using otto for React server-side rendering:

https://github.com/101loops/go-reactjs

Take a look at confd, a single statically-linked executable that can expand config file templates using environment variables:

https://github.com/kelseyhightower/confd

Basically, you add confd into your Docker image and execute it at runtime to do just-in-time config file generation. Here's an example for nginx:

https://github.com/grosskur/nginx-confd-dockerfile

You can create separate environment variable files for beta/staging/prod and pass --env-file to "docker run".

This lets you use the same Docker image across all your environments and avoid the operational complexity of mounting config files in Docker volumes.

You could also try virtualenvs inside Debian packages:

https://github.com/spotify/dh-virtualenv

One reason to keep virtualenvs is that the system Python (VM or container) includes extra Python packages that your app may or may not need. If you use a virtualenv, you exclude these system-installed packages and guarantee a clean starting point.

That was my initial thought, too. But it looks like the Docker-related news they hinted at is still coming:

https://twitter.com/jeffbarr/status/529493907839533056

The Heroku platform team has a good document about their API design guidelines:

https://github.com/interagent/http-api-design

You can simulate this with so-called "Bernstein chaining". Basically, each program takes another program as an argument, and finishes by calling exec() on it rather than exit(), which preserves the environment. See:

http://www.catb.org/~esr/writings/taoup/html/ch06s06.html

Or write environment variables to stdout in Bourne shell syntax so the caller call run "eval" on it. Like ssh-agent, for example.

xmlstarlet is also handy for command-line XML parsing:

http://xmlstar.sourceforge.net/

Looks awesome! I'm actually working on a SaaS product along similar lines. Right now it can build RPM and Debian packages directly from GitHub sources:

https://www.packagelab.com/

Sort of like a cross between Launchpad and Travis CI. If anyone's interested in trying it out, I'd love feedback.

Most people agree HVM is the way to go on EC2:

http://www.brendangregg.com/blog/2014-05-07/what-color-is-yo...

Forcing an HVM guest to use only PV drivers sounds like PVH, which is coming in Xen 4.4:

https://blog.xenproject.org/2014/01/31/linux-3-14-and-pvh/

I'm working on something along these lines:

https://www.packagelab.com/

The idea is to have a common UI and REST API for building packages and managing repositories across packaging toolchains. Right now it supports rpm+yum and deb+apt. Packages are built in isolated Linux containers using Heroku's buildpack interface. (Would love feedback from anyone who's interested in beta testing.)

Also, have you seen the Omaha protocol?

https://code.google.com/p/omaha/wiki/ServerProtocol

It's used by a lot software, including Chrome and ChromeOS. Recently, CoreOS has built infrastructure with it and they offer a SaaS product for rolling updates. I think they're planning on using it to update Docker containers, too:

https://coreos.com/products/coreupdate/

Actually, when you NOTIFY a channel in Postgres it gets delivered to all clients who have previously run LISTEN on that channel. And you can send an optional payload (up to 8000 bytes):

http://www.postgresql.org/docs/9.3/static/sql-notify.html

Nice, thank you. I've been looking for exactly this---SQS and DynamoDB seem like a good combination.

Anyone know why they use two layers of pgbouncer? The speaker mentions this briefly in the Q&A but doesn't go into detail.

Nice work. Are the metrics collected using lumbermill?

https://github.com/heroku/lumbermill

There's also Buildbox, which is a hosted CI engine and web interface. It uses agents that you run and control yourself:

https://buildbox.io/

My understanding: If you provide an image then, yes, you're supposed to build a new image every time there's an OS security update. Users of docker containers aren't supposed to run 'apt-get upgrade' themselves inside containers. In fact, people build who build app images on top of base images aren't even supposed to run 'apt-get upgrade' in their Dockerfile---it's the responsibility of the base image to be up-to-date. See:

http://crosbymichael.com/dockerfile-best-practices-take-2.ht...

This does seem to get a bit cumbersome. I'm at DockerCon today and Fabio Kung mentioned in his talk that this is one difference from Heroku's container platform---they provide the base image and can update it without requiring you to rebuild your application slug. He said there's been some discussion of a possible "docker rebase" command that would produce new images by replacing lower-level layers while keeping higher-level layers the same.

DJB already wrote his own crypto library, NaCL:

http://nacl.cr.yp.to/

It's been packaged up as libsodium:

https://github.com/jedisct1/libsodium

That said, even DJB doesn't trust himself to write bug-free C code:

http://cr.yp.to/qmail/qmailsec-20071101.pdf

PrivateCore has a product to do this for OpenStack:

http://privatecore.com/vcage/

Not sure if any IaaS providers are offering services based on it yet, though.