1. 3

    http://dynalist.io - Similar to workflowy but more feature-full. I use it for my my worklog, errorlog, and lifelog. Extended notes are in markdown so in addition to rapid logging it is alright for long form writing as well.

    1. 4

      I’m part of a two person internal on-prem apps team, without a supporting ops team. Most of our apps have single machine deployments and don’t need to scale beyond that. Given this context docker seems like a lot of infrastructure overhead. If I had to scale, were in the cloud, or had a supporting ops team, I’d reconsider. But at the moment ansible for VM builds, a gitlab’s CI for tests, and git checkouts with nginx/passenger are doing a bang up job with minimal complexity.

      One other benefit I’ve head touted is that your dev environment is more similar to your prod environment. While I appreciate the goals of that sort of consistency, rails apps come with a number of development mode features which don’t play as nicely in the docker context (e.g. anything inotify based like code reloading or livereload). With rbenv & bundler I’ve found that the environments are similar enough.

      1. 2

        I’m excited for hosting some friends for the second round of D&D with my wife as DM!

        1. 9

          Whew, that new format is repetitive:

          targets = [ "//:satori" ]
          
          [[dependency]]
          package = "github.com/buckaroo-pm/google-googletest"
          version = "branch=master"
          private = true
          
          [[dependency]]
          package = "github.com/buckaroo-pm/libuv"
          version = "branch=v1.x"
          
          [[dependency]]
          package = "github.com/buckaroo-pm/madler-zlib"
          version = "branch=master"
          
          [[dependency]]
          package = "github.com/buckaroo-pm/nodejs-http-parser"
          version = "branch=master"
          
          [[dependency]]
          package = "github.com/loopperfect/neither"
          version = "branch=master"
          
          [[dependency]]
          package = "github.com/loopperfect/r3"
          version = "branch=master"
          

          How about a simple .ini?

          name = satori
          
          [deps]
          
          libuv/libuv         = 1.11.0
          google/gtest        = 1.8.0
          nodejs/http-parser  = 2.7.1
          madler/zlib         = 1.2.11
          loopperfect/neither = 0.4.0
          loopperfect/r3r     = 2.0.0
          
          [deps.private]
          
          buckaroo-pm/google-googletest = 1.8.0
          
          1. 6

            Toml can be written densely too, e.g. (taken from Amethyst’s cargo.toml):

            [dependencies]
            nalgebra = { version = "0.17", features = ["serde-serialize", "mint"] }
            approx = "0.3"
            amethyst_error = { path = "../amethyst_error", version = "0.1.0" }
            fnv = "1"
            hibitset = { version = "0.5.2", features = ["parallel"] }
            log = "0.4.6"
            rayon = "1.0.2"
            serde = { version = "1", features = ["derive"] }
            shred = { version = "0.7" }
            specs = { version = "0.14", features = ["common"] }
            specs-hierarchy = { version = "0.3" }
            shrev = "1.0"
            
            1. 6

              TOML certainly is repetitive. YAML, since it hasn’t come up yet, includes standardized comments, hierarchy, arrays, and hashes.

              ---
              # Config example
              name: satori
              dependencies:
                libuv/libuv: 1.11.0
                google/gtest: 1.8.0
                nodejs/http-parser: 2.7.1
                madler/zlib: 1.2.11
                loopperfect/neither: 0.4.0
                loopperfect/r3: 2.0.0
              

              More standards! xkcd 792. I’m all for people using whatever structured format they like. The trouble is in the edges and in the attacks. CSV parsers are often implemented incorrectly and explode on complex quoting situations (the CSV parser in ruby is broken). And XML & JSON parsers are a popular vectors for attacks. TOML isn’t new of course, but it does seem to be lesser used. I wish it luck in its ongoing trial by fire.

              1. 1

                YAML already has wide support so it’s quite odd it hasn’t been mentioned yet

              2. 4

                More attributes are to come. For example, groups:

                [[dependency]]
                package = "github.com/buckaroo-pm/google-googletest"
                version = "branch=master"
                private = true
                groups = [ "dev" ]
                
                1. 1

                  Makes sense, I don’t see an obvious way to encode that in the ini without repeating the names of deps in different sections.