The "mansion" is a 3br 2ba, real estate is just kind of expensive in LA. My Bay Area home is actually worth more than that, and I don't see why she shouldn't be allowed to make real estate investments or have a nice-ish house. There's no evidence any funds have been misappropriated, and if it comes to light I'll join you in complaining, but until then it just kinda sounds like an attempt to discredit BLM-the-movement by discrediting it's leaders and organization without any real evidence.
At one point, the web and API team were a little more intermeshed, but this had the unfortunate side effect that the web was a de-facto a "privileged" client, while the other clients were like second-class citizens. These days, the Rails app serves no human-readable web interface, only a RESTful JSON API. In fact, the Web app uses CORS to speak to the API on an entirely different host! There's literally no overlap whatsoever between the codebases, deployments, or teams now; the web client has exactly the same status as the Mac, Windows, iOS and Android clients.
It's a nice, pithy answer to give, and in general you shouldn't rewrite a backend "just cause". However, Wunderlist's backend was built with the intention of being a bit of a prototype, and the skills on the team are vastly different from when it was written (in PHP) compared to where we are now (using mainly Rails with a little Node.js in the backend).
In addition, contrary to Spolsky's claim, unmaintained code does rust, or "rot". Libraries you were using might go unmaintained in newer versions of a framework that fixes critical vulnerabilities. Code that held up well to thousands of users doesn't necessarily when you're talking about millions of users. Fighting code/app entropy is a real thing.
But we're taking steps to make sure this backend neither suffers from the "second system effect" (we got that out of the way with Wunderkit ;-)), nor simply needs to be rewritten again in a year or so. Spolsky is correct that in general, code is harder to read than write - which is why we're writing Wunderlist 2's backend to be easier to read at the cost of extra work up front. Strict conventions, enforcing documentation, challenging any code that isn't the clearest way to express the problem it's solving - well, we'll have an engineering blog post to discuss our "Pull Request Parties" and other related process improvements in depth at a later point in time/
The short version, though is that the WL2 backend is probably the most beautiful, readable codebase I've ever had the privilege of working with. Of course I'm more than a little biased, but hopefully the proof will be in the pudding when we launch it out into the world.
Unless you said something like "I'd love to see you, but I don't have the energy to go out or make big plans", they might have thought the reason you weren't making plans with them was that you didn't want to see them.
An adage I really like is "never attribute to malice what can be equally well explained by stupidity". And then, never attribute to stupidity what can be equally well explained by miscommunication. They probably had no idea that what you needed was for people to put in that effort - they may have thought "well, she hasn't made plans with us, maybe she's bored with us?" They may have just not wanted to bother you.
I don't live in Austria, but I live in Germany, which I suppose has a similar property. Notice how in restaurants, the servers don't bother you unless you get their attention, while in America they're constantly hovering and asking "how is everything? everything fine?" I think Germans in general treat people's personal space as more sacrosanct, while Americans are very... attentive, maybe? The negative way would be to say Germans are aloof and Americans are nosey. Or maybe Germans are askers and Americans are guessers?
Either way, I think you're probably being too harsh on your Austrian friends. They'd probably have been more than happy to be the ones to make the effort - if they knew that's what you needed. And, not being telepathic and with a bit of a culture gap, that one small piece of effort to mention it sort of... ends up being something only you can do.
Yeah, I think people may be overthinking this, although there's something to be said for "two great tastes that taste great together". It's kind of silly, but I actually wrote a "git dropbox" command to just stuff a bare repo of what I'm doing in my Dropbox so I don't have to think about it... and I kind of like it. Maybe it's overkill, but if I only have to type one command, it's easy enough I won't think about it :-) (https://github.com/agnoster/git-dropbox/ for what it's worth)
Agreed it's a dangerous idea for collaboration, unless you are the only one pushing to it and everyone else just pulls. That could work as a simple way to make your git repo pull-accessible to others without using a separate service or server (assuming you both have Dropbox already, of course).
Ditto this - the idea of having the bare repo in Dropbox, but having my frequently-changing stuff (especially, as you point out, with branch changes) locally seems to me to be the sanest alternative.
I hacked together a quick script to facilitate this (http://github.com/agnoster/git-dropbox), since it seems like one of those things where less friction potentially leads to significant changes in behavior.
I like the simplicity of the center part, but the polka dots on the edge are killing me. But if you like them, don't change it just because I don't like 'em, design by committee never goes well.
I don't really have to make that clear, because I'm the target market ;-)
No, but seriously: it's a tool I wrote for myself (and other people can use it if they like) - I've optimized for the only case I actually know well, which is What I Want. If you want Something Different, man, there's like 430 billion domain search tools out there, most of which are more focused on pleasing other people than mine.
That's not to say you should shut up or anything - your feedback is great, and I may even act upon it, but I don't want to give anyone the illusion that this is a product intended for mass consumption. It's like I made some brownies, and other people should feel free to take one if they want, and you're even free to say "You know what? These brownies would be better without the almonds," but I'm not necessarily gonna take the almonds out. I like almonds, and you don't have to eat them, and people make brownies without 'em all the time, and I think that's swell. Or maybe it's just that it would be better if I used "real" chocolate instead of Hershey's - but meh, it was there and cheap, so I used it.
(On that subject: it's using NodeJS's built-in `dns.resolveNS`, whatever that means. Didn't see anything referencing SOA, but maybe that's the thing to check? In practice I'm not really bothered with the rate of false +/- at the moment, it seems to work ok for my purposes. If it's a matter of changing one function call, I'd do it, but I'm not going to hack my own DNS wrapper just to get a specialized query. At least, not while I'm in the middle of exams.)
Yeah, in practice I always run this in its own tab, so it's not a thing that has ever bothered me. I put that in because it did bother me that I couldn't Cmd-(L+C) to get a paste-able URL to show other people. In the long run, I might change it to have a time-out, maybe use `history.pushState` where available to make cleaner-looking URLs? It's not high on the priority list, though. Ultimately it's just about making a tool that does exactly what I want it to do - if it works for other people, they're welcome to use it, if not, there are only 500 million other sites that do almost the same thing, but with a slightly different take on it.
Yeah, I wrote this as my own tool for similar reasons (actually I just wanted to use it locally, http://domainzomg.com/ is for when I'm not on my own computer and for friends who want to use it).
But it's soooo much faster if you run it locally, it's not even a comparison. Maybe I'll open-source this so other people can just run it locally and not worry that I'm stealing their BRILLIANT DOMAIN NAME IDEAS. ;-)
I'm tempted to actually do a quick test, but I think it probably comes down to something like whether you're closer to the duostack servers or the instantdomainsearch servers.
The reason this is with WebSockets isn't because I needed the speed of them - it's because I wanted to play with [socket.io](http://socket.io/), which provides a really nice abstraction for bidirectional communication, and I wanted to play with Nodejs. It seemed like The Thing To Play With.
The original domainzomg actually loaded hidden images and used onLoad and onSuccess handlers so in theory you didn't even need XMLHttpRequest support in your browser for it to work. So that's the opposite end of the spectrum. Then I figured I'd try rewriting it for ease of maintainability. It's really just a tool I use myself, and a couple friends started using. I'm going to use whatever technology I feel like playing with at the time.
Also, I'm not technically versed in how multiple requests on an HTTP 1.1 connection would work, it's possible that it may even be slightly faster if you just have one XHR request rather than 3 WebSocket requests. WebSockets should be used when you need to push data to the client that isn't part of a direct request-response loop - if you have the request-response loop, XHR is just fine.
tl;dr: 100% right that WebSocket doesn't always get you performance improvements (it might even be slower for some use cases), but socket.io is a super nice abstraction layer that makes programming more fun.
Domainzomg is really a brainstorming tool, so it just uses DNS lookups and a fairly permissive list of TLDs. Red definitely means "taken", but green doesn't necessarily mean "available", it just means "this domain doesn't seem to have a DNS entry". Check with a real registrar for availability, use domainzomg for brainstorming.