senex

Does anyone have experience making tests against real databases fast?

I resonate with the sentiment of this article, but have struggled to find an alternative that’s fast enough as the test suite grows, isn’t flakey in CI, and is able to share the production schema definition for relevant relations.

I’d love to hear more from anyone that’s solved for some of these constraints!

You could “yield” the record instead of constructing the list. This makes “read_portfolio” into an iterator instead of returning a list. Use a list comprehension or list constructor to convert the iterator to a list if needed.

would old be something like: implementation is no longer relevant (the software itself is obsoleted), but the idea is seminal -- a basic conceptual building block upon which current systems are implemented? Example: Lambda Papers (https://en.wikisource.org/wiki/Lambda_Papers)

This is really interesting. What kind of metrics is the culture focused on? How were they established. Can you think of examples when critical/deliberate decisions were made to pursue the integrity of the culture (rather than shifting or broadening focus)? Has cultural orientation or measurements changed over time? How and why?

Are there other examples of cultures focused on particular metrics that have flourished? Or faded away?

Super curious...

I work for a global / English-speaking company in Japan. We don't have futsal and basketball instead of vball, but it's pretty easy to get started. PM me if you're interested.

A related market for some of this tech: remote interviews. I've seen lots of solutions for this: collaborative code editors, hangouts, Skype etc. There are frequently problems with bandwidth and friction with coordination (handoff to other interviewers).

Solution to "frictionless" remote work / collaboration among teams (not just engineers) seems similar to interview problem. The target market may also be distinct (teams don't remote work, but remote interviews are common).

moocs might benefit too?

I really like: daemontools + static binary + setuidgid and maybe chroot.

Or mesos where everything needs to be in a tarball, which is extracted and sole program run.

If stuff is statically linked and related files (config, assets, ...) are part of bundle that can be chrooted, what is the value add of a container?

Yep, you're absolutely right. I guess that maybe if you care about inventing new kinds of loops (e.g. a DSL that wants to loop as a specialized kind of `fold` construct), there's more flexibility with TCO.

But Clojure shows that there's tons of mileage and composability that can happen by using runtime protocols and tasteful language-design decisions even without TCO.

Capturing continuations is another interesting theoretical outcome of TCO, although as various scheme implementations show: the approach to supporting TCO also imposes some performance constraints on call/cc.

Another thing to mention: having guarantee of TCO supports higher-level control-flow abstractions (capturing continuations), which is also an interesting outcome...

Yep, and the same can be implemented in any language that supports functions-as-objects (for example, javascript).

It's a practical solution/workaround, but isn't quite composable/generalizable as first-class support for TCO (unless the community is willing to follow some convention like "TCO-like behavior is a 'good thing' and so libraries should try to support and interface compatible with `trampoline`".

This is a little bit like `function` / yield in newer versions of Javascript. It's not TCO, but it is a strong community convention (with the assist of special syntax to enforce the semantic).

Clojure is a great example of how practical/tasteful decisions by language author can create re-usable abstractions that are really powerful (even while at the same time working around limitations of the underlying technology).

Some might also argue that TCO is "bad" because it's less debuggable (e.g. when an exception is thrown, the stack trace is gone). We can see the same phenomena with non-blocking IO, for example. So maybe it's a Good Thing to have "less general" semantics in a language (e.g. function, trampoline, and loop/recur may be good-enough while at the same time preserving debuggability).

There are always tradeoffs. What's nice about general TCO is that the composibility of unrelated libraries/DSLs is more probable whereas with conventions like trampoline, DSL/library authors need to understand the advantages and design the DSL/library in a compatible way in advance. As Clojure shows with lazy sequences, this can absolutely work given enough community awareness of the convention.

When TCO is "lexically scoped" like loop/recur, the compiler can handle it.

When HoF are involved, you may have a case where a procedure calls a procedure-parameter, which calls another, and another... Something about the runtime has to recognize this or else the compiler has to accept more constrains.

See, for example, how Gambit-C implements tail calls by compiling modules to single C functions and how there is a trade off for procedure calls across module boundaries versus Chicken Scheme's approach to essentially garbage-collecting the call stack.

An interesting thing about general tail recursion is that it's composable.

Closure's loop/recur is a special case implementation of a common pattern. That's Ok, but it can't extend.

Any higher order function in scheme can be parameterized with methods that should be tail recursive. No special language support needed. That's why for-each is a procedure instead of a special form in scheme.

This allows libraries (like SFRI-1) or DSLs to be created that expect callers can conform by contract instead of by using special forms. Callers, in turn, can create abstractions over the libraries and DSLs that are equally general, instead of being strongly influenced by what they're built on.

Clojure does a really nice job of creating reusable abstractions. From what I understand, tail-call optimization isn't possible in the JVM, so we have iterators and lazy evaluation first-class instead; which has other nice advantages for creating abstractions.

I've been tracking the beta for a while. I'm confused about this announcement. These issues still seem unresolved?

(1) docker can peg the CPU until it's restarted https://forums.docker.com/t/com-docker-xhyve-and-com-docker-...

(2) pinata was removed, so it can't be configured from CLI scripts https://forums.docker.com/t/pinata-missing-in-latest-mac-bet...

(3) it's not possible to establish an ip-level route from the host to a container, which many dev environments depend on https://forums.docker.com/t/ip-routing-to-container/8424/14

(4) filesystem can be slow https://forums.docker.com/t/file-access-in-mounted-volumes-e...

Are these fixed in stable? I'm personally stuck transitioning from docker-machine and (from the comments) it seems like other folks are as well...

I use Duo Mobile for some accounts; it supports push. Definitely nicer than rushing to type a number in before the timer expires :)

Besides karma, I wonder if users will be motivated by career opportunities? Contributing to documentation could be a good signal to recruiters that are looking for experts in a particular technology.

There are frameworks that run on Mesos capable of running Docker containers. Check out Singularity, for example.

Does anybody know how they'll be funded over the next few years?

Congrats on this release, Sam. Pow just keeps getting better!

I bought a burger from a mobile restaurant (large truck) the other day. They swiped my card through a Square reader. I appreciated not having to find an ATM. I'll eat there again next time it shows up near my office since the experience was so convenient (and the food was great :)

Thanks, we'll take a look!

Thanks for the feedback! We'll tweak the payment form to make it more usable.

Hey johnrob, that's a good question. Showoff is currently implemented in three parts: a Ruby client that's essentially a lightweight wrapper around SSH, a custom unix shell implemented in Node.js, and a server written in Node.js.

When a client connects to the showoff server, the custom shell is started. It only supports a showoff-specific API, so there's no way to execute arbitrary commands. It's similar in spirit to custom git shells like gitosis.

Hey maheswaran,

Showoff doesn't touch the body of the requests, so you'd need to use relative URLs, change the "domain" config variable each time you make a new showoff tunnel, or set up an unlimited account where you can choose a permanent subdomain like "myserv.showoff.io".

Ah, interesting. Thanks for the feedback!

Yup, try using something like `show --host=mysite.local 80`.

Yup, this is basically what showoff is doing. Showoff is nice because it gives you:

* HTTPS * Works without access to public-facing server. * Pretty URL * Eventually will support more stuff besides just port-forwarding :)

We're planning to make more "normal" installation scenarios if we see good interest. Using gem was a quick way for us to get the idea out.

We're going to add CNAME support soon. Thanks for the feedback about the color scheme.

If you sign up for an unlimited account and you're _really_ unhappy, send an email to support@showoff.io and we can talk about a refund :)

Hey crikli, could you send an email to support@showoff.io with any extra details that seem relevant? We'd love to track this down!

Thanks for bringing HTTPS up, that's another good use-case for Showoff. If you're developing a web app that needs to be tested with HTTPS and don't want to mess with creating a self-signed cert, Showoff can help you out.

It's also really nice for testing web hooks or API callback URLs against a local web server (e.g. ecommerce sites with IPN, &c). If you sign up for an unlimited account, you can choose a permanent URL to use for your tunnel (e.g. "my-name.showoff.io").