1. 2

    I personally hate the implementation and code generated by gRPC Java in particular. My problem with the whole philosophy is that gRPC tries to hide the fact that it’s built on top of HTTP/2. Accessing headers, and capability to modify headers/trailers, weird way to attach context are all just tell tale signs of it was not thought through and all these concepts around protocol were after thoughts.

    1. 2

      Your problem with the whole philosophy is strangely misfounded. I’m not a gRPC apologist by any stretch, but it seems strange to state (much less base your entire disagreement on the idea) that gRPC “tries to hide the fact that it’s built on top of HTTP/2” when it’s not just clearly described up front but in great depth

      1. 3

        Hide as in abstract away from the developer, not as in trying to hide that fact from people’s awareness. But yeah, being an RPC protocol, ideally everything should be abstracted away.

        What is confusing is: what exactly is the advantage for Java developers when compared to RMI? The fact that one is 25 years old and subject of mockery by fellow developers and the other one is relatively hip?

        I frankly find gRPC philosophy extremely flawed if not completely inexistent.

        1. 2

          If you are in a Java only environment RMI might just be fine for you, but the point about any RPC framework is a way to make remote procedure calls independent from your language, and hence are able to include new consumers and services that are written in other languages down the line. The reality is, projects often live longer than expected and requirements change and a new project with a new language might help you solve the new problems, and that’s where RMI and ecosystem-bound RPC falls short and gRPC, Thrift & Co help.

          1. 2

            Well, the same argument applies to this one (DRPC) then, because it has only a single (Go) implementation, and no specification docs.

      1. 1

        Same

      1. 4

        That is kind of interesting, but not in the way I expected. Like the author, I can only speculate, but I wouldn’t be surprised if it wasn’t just the case that Steam felt TLS wasn’t secure enough but that someone thought it would be a fun project to harden login even further and because it’s Steam, why not?

        1. 9

          It protects the password from network level SSL (passive - an active MitM could provide a fake public key or serve a compromised rsa library) interception employed by AV tools and ad frameworks (like that Lenovo superfish cert a few years back)

          I have a feeling that Steam’s target audience lives in that dangerous group of people who are capable of installing whatever crap they want, who are also not versed in security enough not to do so and who have a very valuable asset (the steam account with all games)

          Any bit of additional protection helps at that point

          1. 1

            I’m not quite grasping the threat model you’re trying to show.

            Passive SSL MITM isn’t, someone has to encrypt with a new cert – either your network administrator because all your traffic goes through a MITM proxy, or software on your box. But for that to work your machine already has to trust a non-standard CA root, which means your adversary already did something arbitrary on your box.

            So in that world what does an extra layer of RSA get you?

            1. 1

              I imagine the point pilif was trying to make is that it’s not outlandish to consider users who’ve unwittingly allowed a malicious CA root and new cert on their machine. So, security in layers. That said, anyone who has done so is effectively vulnerable to mitm attacks on every website they visit and probably reuses their password, so their steam account might as well be considered compromised.

            2. 1

              That’s kind of a funny threat model, but why does Steam not just do CA or cert pinning like a lot of mobile apps do nowadays?

              1. 2

                They do. But they also offer a website where people can log in. And they offer OAuth “login with steam” services, all of which happening in browsers and not supporting cert pinning

                1. 1

                  Ah right, the browser. I wonder if they’d have done this if Chrome was market leader back then.

          1. 7

            On the confusion of what a scripting language is, there is a ton of overlap and it’s not always clear which to choose.

            A lot of my own projects started out as bash/zsh because it seemed small and the project fit a shell script well. But as they grow and become more critical, I regret not having things like tests and more robust error handling. Several times I tried starting such projects in Python, but converted to Bash when I found I wasn’t making as much progress as I wanted.

            I recall that Git also started out as a collection of Bash & Perl scripts, which is why it took so long to port to Windows.

            1. 2

              If that bit about Git is true, it isn’t in its own git history. The first commit is a few c files.

              1. 9

                I never questioned it because my terminal would report the current process as bash or Perl most of the time during a checkout

                Edit: I found it. Linus describes commit as being a few calls to Linux utilities, and push as being just rsync.

              2. 1

                There are a couple of different testing tools for shell, FYI.

                1. 2

                  I have written my own simple test runner (example). The actual tests go into a test file (such as this). It works in a very simple way. If the test function fails with a non-zero exit code, it is a test failure, otherwise it is a success. It has served me pretty well so far.

                  Also, since I don’t target bash alone but target sh instead, so that the scripts can run on more number of shells, I run the tests with bash, ksh, and zsh on Debian and Mac as well as with dash, posh and yash on Debian (example) to weed out any Bashisms.

                  1. 2

                    Nice work. It’s good to see someone else considering shell portability too.

                    While I generally target sh, I’ve added a configure argument to set the target shell, which gets used for invocations throughout the Makefile. A little wrapper script then loops through, tests in a series of shells (currently only dash, bash and mksh though), runs the test suite, and also compares the sha1 sums of all built files. The last part is mostly because the project is a shell library/toolset and part of that is a tool to “build” more distributable scripts from a source project, which it uses to build itself.

                  2. 1

                    I’m aware of bats, and by relation, the Test Anything Protocol. I think I’ll be digging into both of those a little more in the new year.

                    1. 2

                      There’s also https://github.com/kward/shunit2/, which I find quite helpful.

                1. 25

                  If the goal is being minimal then I really don’t see why you’d include features like coloring.

                  1. 8

                    I imagine the title meant something more like “minimal complete”, taken to an extreme a minimal template would be empty. Nevertheless, I found this post useful for the reasons they mentioned at the start. Everytime I write a bash script, I have to relearn basic bash things. I bookmarked this for future reference.

                    1. 3

                      That’s fair.

                      I think though that there is some level of a “minimal bash template” that isn’t entirely empty. For instance, the set options at the beginning as well as having a cleanup function and setting it up with trap is pretty applicable for nearly every script, and would belong in a minimal template.

                      1. 4

                        Yeah, I agree. Still, it’s nice to have a template where I’d begin by paring it back rather than by scrambling to find things it’s missing. That said, this is probably missing some things too. I guess I won’t know until I need them. :P

                  1. 28

                    1: I want to stay in the terminal

                    2: When I edit code, I don’t want anything on my screen except the code.

                    3: I don’t want to use a mouse.

                    4: I want to be able to fully customize everything.

                    5: The default Vim keybindings are already super awesome.

                    I like a system to be composed of parts that do one thing well. When it comes to editing text, Vim does this better than any other software I tried. For everything else, I have other command line tools that are at my fingertips.

                    Regarding keybindings: I don’t know, how most developers translate something like “Ok, I want to cut out this line and put it at the end of the file” into something their “IDE” understands. In Vim, you type ddGp and are done. It takes a blink of an eye. After a while, most text editing tasks just roll of your fingers without you thinking about it. It is a magic feeling of productivity I never had in any other editor.

                    1. 8

                      Vim is my goto text editor, so this isn’t a hit job. But Vim is not good at composing third party tools to create an IDE like experience. Vim is painful to extend and script but a pleasure to drive.

                      1. 5

                        Vim is painful to extend and script but a pleasure to drive.

                        That’s part of what keeps the default experience at least moderately sane.

                      2. 3

                        Personally, I’ve always felt examples like “Ok, I want to cut out this line and put it at the end of the file” a bit contrived. I have never wanted to do that with my code. It would break my code. It sounds more like an easy vim golf exercise. Typically, at least for me who is at best a vim novice, navigating a project and global search and replace are things I’ve found vim to suffer on and among the main reasons I continue to use VS code.

                        1. 5

                          In my experience, it applies to all text editing task. Not only to contrived examples.

                          Moving lines (or larger parts of a file) around happens pretty often. And its not just easy to reach the end of the file. Say you want to move the current line below the line with “hello” in it. Then it becomes dd/hello[enter]p which means:

                          dd = cut the current line
                          /hello = search for hello
                          p = paste below
                          

                          And you quickly learn to use it like a language. Want to cut the current paragraph instead? “dap” = “cut the current paragraph”. Cut the current word? “daw”. Cut the current block? “daB”. etc etc. Want to copy instead of cut? Use “y” instead of “d”. Want to paste above instead below? Use “P” instead of “p”. With just a handful of these verbs, you start to communicate with the editor like you could have never imagined before.

                          1. 2

                            Cut the line, find “hello”, escape, move down, paste line.

                          2. 2

                            No particular example of Vim usage is a massive time saver. Sure, copying stuff to the end of the file can be done pretty fast without vim. Sure, you can change the code in parentheses pretty fast, too. And you can delete a couple of arguments from a function just fine in any editor. But with Vim, these actions are nearly instant:

                            • dGp
                            • ci(
                            • 2df,

                            The last two are examples of the actions that I personally commonly perform when editing code. The real benefits start appearing because you can do everything this fast. Most actions require only a couple of keystrokes. And the keystrokes are arranged in such a way that you can come up with actions appropriate to any situation. Because of this, you don’t even have to think about what you’re doing: you’re editing text at the speed of your own thought. There’s no “press the left button to expand selection until the comma”, there’s no “drag mouse to select line”. It’s just… done. And that’s what makes me reach for vim key bindings even in other editors.

                          3. 1

                            I don’t know, how most developers translate something like “Ok, I want to cut out this line and put it at the end of the file” into something their “IDE” understands.

                            Home, Shift + End, Ctrl + X, Backspace, Ctrl + End, Enter, Ctrl + V (or press right arrow after the Shift + End while holding Shift, then you can skip the Enter as well). Not as efficient as vim, but it’s easier to learn in my opinion (I’m a vim user myself).

                            1. 1

                              You can remove Home, Shift + End and Backspace keys. Almost all editors default to copying/cutting the whole line if there’s no active selection.

                            2. 1

                              Cut (or yank) the line, move to bottom of file, paste (or unyank).

                            1. 7

                              I always found the batteries-included frameworks like Rails to be overwhelming (when they should have the opposite effect) - for me, Phoenix still invokes that feeling enough that I have to use Plug directly. I wish I could get over that feeling, because Phoenix does look very useful.

                              1. 2

                                The way I see it, Phoenix is absolutely okay with you using Plug directly. Rails/Django feel much more “punishing” when you try to do something that was not predicted by maintainers.

                                1. 2

                                  We’re using Phoenix on my team full time, and I agree. Plug lets you insert your code anywhere in the pipeline without much hassle.

                                  1. 1

                                    Well, I’m not using Phoenix - I’m using just Plug with Phoenix.HTML.

                                    1. 1

                                      I see. What do you use for routing, for example? Just pattern matching on path_info?

                                      1. 2

                                        The macros for get were enough and pretty close to what Express does - those are a part of Plug, at least.

                                    2. 1

                                      Using Rack directly in Ruby is actually quite nice, IME.

                                      1. 1

                                        Well, if we talk about Phoenix.Controller then in fact it is just Plug generator. You can easily implement such controllers with plain behaviour and keep most of the functionality.

                                      2. 1

                                        i agree, i wrote a small app in phoenix and what i found overwhelming was the sheer volume of generated code. i wish it had some sort of sinatra-like mode where ‘hello world’ could be a single file and gradually expand as needed.

                                        1. 3

                                          That is why there is Plug, which is almost exactly that.

                                          1. 1

                                            i still want things like channels and presence from phoenix though. i’m not looking for a superminimal framework, i just wish there were a clearer separation between my code and the framework code.

                                            1. 3

                                              Well, for presence you can use phoenix_pubsub directly. Despite it’s name it do not depend on Phoenix nor any of it’s components, it is really sad that they dumped the name firenest and instead decided to namespace it under Phoenix. For channels unfortunately you cannot go around it as it is very Phoenix-y specific thing. However nothing stops you from using Phoenix only for sockets. It is perfectly valid approach.

                                              i just wish there were a clearer separation between my code and the framework code

                                              Well, it all depends on you. Recent Phoenix generators highly encourage such approach by encouraging domains separation and split between your_app and your_app_web.

                                              1. 1

                                                Recent Phoenix generators highly encourage such approach by encouraging domains separation and split between your_app and your_app_web.

                                                ah, that sounds awesome! i’ll have to take a closer look at the current best practices.