Walkman

This sounds terrible. Even more terrible a lot of people (probably you also) don't find it terrible.

I have a USB stick 4G modem and I automated the connection setup; it has a web app (starts a small embedded webserver when you plug it in) which I "reverse engineered" and I wrote a small script which makes HTTP requests so I don't need to go to the web interface, login, enter PIN code and click connect every single day multiple times. I just run "telekom connect" and that's it. What a time saver! :D

Never because of Elon Musk :)

I totally agree! I like Go but this is not a field I would ever use it. Parsing the site-s will never will be the bottleneck, but following the HTML changes or making it work for multiple sites is... When it takes maybe even seconds to download a page, a couple of millisecond performance advantage of Go doesn't matter at all.

Yes, I will. That's a long overdue also :D

I have a private repo on GitHub which contains my dotfiles with SSH private keys, tokens, secrets and all kinds of secret stuff. I was uncomfortable storing it there, but my laziness/lack of time kept it there. Finally I will be able to encrypt the entire repo, yay!!

No it's not. Putting your head in a sand for the last 5 years sucks.

There is a GitHub repository full of neat tricks like this: https://github.com/GitAlias/gitalias

Exactly!

There is no such thing as "private" or "public" instance variable in Python. This guy should not teach...

    # Go parameters
    GOCMD=go
    GOBUILD=$(GOCMD) build
    GOCLEAN=$(GOCMD) clean
    GOTEST=$(GOCMD) test
    GOGET=$(GOCMD) get
    BINARY_NAME=mybinary
    BINARY_UNIX=$(BINARY_NAME)_unix

A little bit of Clean Code education is needed here :) Why on earth do you want to introduce so unnecessary abstraction? If those would use a lot of switches which you don't want to duplicate and just possibly want it to change in one place, I would say OK. But you don't even use it that way:

    $(GOBUILD) -o $(BINARY_NAME) -v ./...

    CGO_ENABLED=0 GOOS=linux GOARCH=amd64 $(GOBUILD) -o $(BINARY_UNIX) -v

So this doesn't make sense at all. You should write the commands as it is and it would be a lot easier to read an already hard-to-read syntax Makefiles anyway.

I didn't see that coming; Keybase want to be Slack 2 :D

> Python in the large is not very maintainable.

Yes, very much it is. It just need good developers, not only juniors...

Rule 5 is actually the same as Linus Torvalds said: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

Periodic merges in which nothing interesting is happening are just useless cruft. Just spam the Git history.

No, not really :D

Yes. Obviously it doesn't seem like so at the first glance, but when you have a product like ours, where there are hundreds of small things like this, it can really add up. I believe that everyone should use and improve the same, standard tools so we can have few, but high quality things. When you come up with something new which is just slightly different from the existing one (see Python3 first versions...) I think you are doing the wrong thing.

Please don't do this. It's just yet another tool which makes the same thing as setup.py yet another way with no real benefit and it's not "standard". Everyone who did some Python packaging already know at least the basics of setup.py, now they all should learn yet another file type syntax for the same problem.

Pyramid is exactly that.

Great answer! I wondered about this myself for a moment :)

If you would see our Makefile which can do literally_everything_ with the project, you would not write this article. :)

Makefiles don't scale, hard to learn because of awkward syntax.

Go does this.

When you realize and accept this, you can start focusing on your future and stop whining abut your past.

I really like 1Password's old model for a user point of view; they asked money for every new major version of 1Password, but old version bug fixes were free. This way, if you needed the new features or newer OS support, you could pay for the new major version (same as buying a new suit) or you could use the old version if it was fine for you. This model is fair, but still generates more income for the developers from loyal users who upgrade.

We actually do this. We plan the learning phase for the sprint and we time box these kind of things for 1-2 days.

I recently was thinking about 1). At my current company, I got to know agile methodologies for the first time, I liked it and started planning my side project, but it instantly started to felt like work! I just realized if I write the parts whatever interests me the most, I will be more inclined to finish it!

At my company we changed the interaction between two daemons by calling a command line script instead. It caused a 300ms delay in every single AJAX call and broke a dozens of end-to-end tests.

I just tried with Python 2.7 and 3.6 and the hello world startup time is 100ms which is awful lot.

This guy mix and match totally unrelated things.

- clean != finished

- clean != perfect

- ugly is not clean

- you can understand a code and find it still ugly

What is he actually talking about?

> Automated tests are not that important

I agree with the content of this section, but the title is bad.

Because they are not successful? :D They keep being small for a reason.

maybe CI