soveran

I use it daily. I run a slightly modified version: I added line editing capabilities with linenoise and I use EREs. The most common use case for me is editing with :g/re, which allows me to see only the matching lines. If I want to keep only those lines, I type :v/re/d, and so on. I also invoke it regularly from my main editor when I find it more efficient for modifying some file or some region.

For an alternative solution, describe the directed graph by listing the nodes and using whitespace to represent the arcs:

  $ cat riddle
  Vixen Rudolph
  Vixen Prancer
  Vixen Dasher
  Dancer Vixen
  Comet Vixen
  ...
  Vixen Dasher

  $ tsort riddle
  Dancer
  Donder
  Comet
  Vixen
  Blitzen
  Dasher
  Rudolph
  Cupid
  Prancer

I've always used MessagEase (both on Android and iPhone). It is a keyboard layout that was originally designed for the Palm Pilot, and it is optimised for typing with one finger. I don't use any sort of autocompletion, yet I'm usually the fastest typist in the room. More info: http://www.exideas.com/ME/index.php

I don't think the paper assumes a many worlds interpretation.

Did you read the paper I linked to?

All the paradoxes disappear if we use Quantum Field Theory instead of Quantum Mechanics. I would really like someone with deep knowledge on Quantum Theory to explain if something is wrong with a theory that otherwise makes a lot of sense to me. A good read on the topic is the paper "There are no particles, there are only fields" — https://arxiv.org/pdf/1204.4616.pdf

The ten sample games:

Sample game 1 https://lichess.org/VMe0gfa2

Sample game 2 https://lichess.org/Zqwn4Gzk

Sample game 3 https://lichess.org/G2fPHci8

Sample game 4 https://lichess.org/LLt8wyYp

Sample game 5 https://lichess.org/3r6CXx3H

Sample game 6 https://lichess.org/sbdyUYS4

Sample game 7 https://lichess.org/88vsAftE

Sample game 8 https://lichess.org/1uvCwaeB

Sample game 9 https://lichess.org/743quCXj

Sample game 10 https://lichess.org/SkCjxXkb

For scripting, I recommend the rc shell from plan9, which is the one I use for my shell scripts. It is only when I want to share a script with other people that I consider using /bin/sh, and even then more often than not I've gone for rc.

I invite you to read about it: http://doc.cat-v.org/plan_9/4th_edition/papers/rc.

I find the control structures simpler and more elegant, and overall its design feels more consistent. For example, consider an if statement in bash:

  if [ condition ]; then
    ...
  else
    ...
  fi

  if (condition) {
    ...
  } else {
    ...
  }

  case $1 in
    "bar")
      ... ;;
    "baz")
      ... ;;
  esac

  switch ($1) {
    case "bar"
      ...
    case "baz"
      ...
  }

In most platforms you can install the rc shell from plan9. It's what I use exclusively for my shell scripts. It is only when I want to share some script with other people that I consider using /bin/sh, and even then I've gone for rc nevertheless. Here you can read about it: http://doc.cat-v.org/plan_9/4th_edition/papers/rc

We started openredis in 2011, and we reached the 1k customers mark a year later. It's a Redis hosting service for EC2, also available as a Heroku add-on. Aside from the fact that the Heroku add-ons program could be considered some sort of marketing, we've never paid a single ad. For us, the key to getting customers was word of mouth. In 2014, at the three year anniversary, I wrote a blog post about how we got started: http://soveran.com/turning-three.html

I love the idea, thanks for the tip!

I just updated the README with a gif of that video. Thanks for the idea!

That's interesting: commands that consume everything in the stack. About saving/loading words: I have plans to work on that, it could be a very useful feature.

I'm not the author of the post, I just wrote the tool. I agree with you that it's not groundbreaking technology :-)

In fact, the code is extremely simple. As I mentioned in the README, I've used dc a lot and what I propose with clac is an improvement (for my taste) regarding the UI, as there's an always-visible representation of the stack that gets updated as you type. I recorded a short video to show it in action: http://files.soveran.com/misc/clac.mov

Some years ago I wrote a tool called mailcat, which is a fake SMTP server that prints the incoming emails to stdout. I use it to this day when I need it in development. It's available at https://github.com/soveran/mailcat

For the original go proverbs, see https://en.wikipedia.org/wiki/Go_proverb.

The author of the article declares his incompetence at building and maintaining software projects for which he's not the target user, and thus concludes the same applies to the creator of Redis and Disque. Based on that he instills a lot of FUD around a project that has proven very useful for me so far.

Also, from the article:

The other reason I don't foresee using Disque is alluded to in the author's own comments. He observes that many people are using Redis as a message broker, and decides that maybe there is a need for a "Redis of messaging". I would say the opposite is true, and that instead of another message server, people want to use Redis!

I disagree. I've been using Redis for queues for a very long time, and I'm in the process of migrating all those queues to Disque.

My experience is the opposite, I agree it may vary from person to person. Care to elaborate what went wrong in those projects?

The way you put it, it looks like it's a matter of trust rather than understanding. If you don't understand what X does and how, if you don't want to invest the time to analyze it, then you are gambling. The fact that a lot of people use X makes it look like a safe bet, but the point is that even if it turns out to be a safe bet, it's still a gamble. Isn't that cargo cult programming?

An extended version of the quote would be "Don't just believe that because something is trendy, that it's good. I would go the other extreme where if I find too many people adopting a certain idea I'd probably think it's wrong. Or if my work had become too popular I probably would think I have to change." I took it from this video: https://www.youtube.com/watch?v=75Ju0eM5T2c

It can be simplified even more:

    megalotto = MegaLotto.new
    megalotto.draw(10)

Not quite what you want, but you can restrict the search to filenames matching certain pattern with the -G option. For example, ag <pattern> -G \.c will only search on C files.

You may run into race conditions when two processes end up saving an object with the same hash_id. The check and the object creation should both happen inside a transaction.

> I always felt that "it's up to the developer to do the right thing" violates the normal Rails convention over configuration principles, but I also weigh breaking a large % of existing Rails apps in a way that is not easy to quickly fix heavily.

It can be argued that those apps were already broken. Nobody should complain against a security fix.

Are you sure the clients want that? I has never happened to me. Besides, it is terrible for the developers.

The same in Cuba (http://cuba.is):

    Cuba.define do
      on "blog/:id" do |id|
        blog = Blog.get(id)

        on(get) { res.write blog }
        on(put) { blog.update(req.params); res.write :ok }
      end
    end

Don't you care if _every_ call to render does ~20 unnecessary checks?

I agree, not only because I've run benchmarks myself but because simpler and faster code is possible. Just a comparison of everything Sinatra does when rendering (http://goo.gl/6U7yr) vs what Cuba does (http://goo.gl/z1Oes) can shed some light on this issue.

Hopefully we will add more info in the next few days, truth is we had way more signups than we expected (a good thing!) and we have to take care of a lot of things. Future is bright and reliability is the are where we want to put more effort.