Walkman

So you suggest a couple months of work instead of a two line hack which caused huge improvement for them, because it is more "correct"?

Privacy doesn't matter in case of torrents because as soon as you download one, peers will know who are you.

> "how is RethinkDB different from MongoDB?" We worked hard to explain why correctness, simplicity, and consistency are important, but ultimately these weren't the metrics of goodness that mattered to most users.

So everybody is crying how shitty and unreliable MongoDB is, but this is exactly what makes them successful? Very interesting!

IMO Go is not a great language for Desktop automation like this. A script language, not statically typed language fits better, because it makes it possible to iterate faster. Also these kind of automation scripts are not huge usually, or if they are, they are very simple. Also don't have to be fast. The only advantage I can think of Go has here is the easy deployability for multiple platforms, but that's not even possible, because the platforms has different UI-s with different sizes, so you can't write one script and expect to work on multiple platforms.

No, they are NOT strings, they are not any kind of strings. They are bytes:

    >>> b'asd'[0]
    97
    >>> b'asd'[1]
    115
    >>> b'asd'[2]
    100

They happen to contain an ASCII DECODABLE string in this case, but to get the text back, you NEED TO decode it first:

    >>> text = b'asd'.decode()
    >>> text[0]
    'a'
    >>> text[1]
    's'
    >>> text[2]
    'd'

You don't grok it. Bytes are not ASCII strings. They are NUMBERS between 0 and 255. Strings are strings. DECODING bytes with ASCII encoding into TEXT is not "casting", it's DECODING.

Come on, you really behave differently and put yourself at risk if you have insurance? That's at least thinking backward but I think it's stupid. I don't do things when the risk of getting hurt is not acceptable for me no matter if I would have insurance or not. Also it's mostly for disasters so you don't go broke, but if you scratch your knee or something, who cares?

I love koans and I think it is the best way to learn.

Python has PYTHONPATH. I believe it's the exact same thing? The difference is that Python puts the current directory and the standard library in by default.

No. Just accept it will have bugs :) Every code has bugs except for Linus Torvalds' code, but he is not coding nowadays therefore every code has bugs.

A lot of people find "alternatives" to the OS X apps, but they don't realize the difference is so huge it's not even funny. Alfred DOES NOT have an alternative on any platform. It's so good it's unbelievable, takes job of multiple programs I need to constantly use on Linux. Also DashDoc, etc. Also there is Terminator yes, but it's feature set is nowhere near of iTerm2, it's crazy what you can do with it and how convenient is it compared to any terminal emulators.

I find this terrible. Why not face the boss and talk about the problems you have? Also if you are unhappy there you should just leave.

If you just talk to a formula 1 race car driver, does it make you a good driver if you never drive yourself? I don't think so.

OS X less than 5% ? That's really surprising!

A color picker for the base color would be handy

Is there not a single namedtuple in the entire Google codebase? That's strange :o

if you use docker from terminal, why would you need anything else than you have already? current docker commands are pretty easy and intuitive IMO.

One of the most common mistakes is delimiter in a field. E.g. comma as thousand separator...

This is nice and all but what about page load times? It can have all the bells and whistles but if you have to wait a minute for just one page to load, it's unusable.

This is a joke. The whole "library" is 200 lines, has 9 tests, Kenneth probably wrote it in a couple of hours. It is totally not necessary, because, there are a gazillion datetime libraries and still, this is on the front page?

Also:

    >>> dt = maya.now()
    >>> dt.datetime()
    datetime.datetime(2016, 12, 18, 19, 24, 50, 212663, tzinfo=<UTC>)

    >>> dt.datetime('Europe/Budapest')
    datetime.datetime(2016, 12, 18, 20, 24, 50, 212663, tzinfo=<UTC>)

I would not use it...

Why didn't you born sooner? :D

A little bit about 0-based indexing on the practical side from Guido van Rossum: http://python-history.blogspot.hu/2013/10/why-python-uses-0-...

Pyret's syntax looks far more complicated to learn than Python's for a beginner.

Sorry but this has nothing to do with the article.

Example 1: You can stop all instances and wait for sycn/migration to complete, and start all instances.

Example 2: (which is much better IMO) deploy the new version, but keep the older versions running. Sync/migrate one-by-one and start the new version when ready.

That's the worst thing you can do. The change will be forgotten and will never be properly worked out. Why should it? It just works.

I have seen a 270k loc codebase where every change has been made by this kind of thinking. Nobody ever went back to make the "temporary" changes properly.

You are right. Without multitenancy, you have to write the automation code, however, it's much better IMO, because with multitenancy, you have to think about tenancy ALL THE TIME not just that one time. So I think overall it's a better trade off and still less code and less problems to solve and easier to solve.

In my experience there is no point developing multi-tenant software nowadays, because operating large number of isolated environments is a solved problem and really cheap nowadays. You can buy VPS-es for less then 5$ today, you can automatically create them, deploy the instances easily. You can scale either horizontally or vertically (Docker can help both). It's not much more work, but much more secure and more scalable and almost as cheap as a multi-tenant solution would be.

Not at all. You can do it with multiple ways, e.g. with Docker

If you are interested in the topic of multi-tenancy, this Microsoft article is the best I ever found: https://msdn.microsoft.com/en-us/library/aa479086.aspx