amix

While localStorage is blocking it offers A LOT better performance than IndexedDB, at least based on my experience.

There's also some benchmarks here: http://jsperf.com/indexeddb-vs-localstorage/6

I donated $50, but I really wish US (and other countries) would reconsider their broken healthcare systems. My dad died of cancer a few years ago and I am really glad we lived in Denmark when he got it - - with a great public healthcare system. He lived 2 years with his cancer, which is a lot when you are counting days. Not many normal people can afford these things (as each of my dads treatments cost about 20.000USD+ and he had a lot of them).

Also, just yesterday DHH posted this: "Top income tax rate for California residents is 51.6%. Top for Danish residents is 51.7%. (Kicking at $500k+ vs $70K+, though)."

Which puts things in perspective.

Europe is ~800million people with very different cultures. You can find geniuses here. You can find entrepreneurs. You can also find people that are sloppy. You can find people that have built billion dollar tech companies. Stop generalizing.

I don't agree with the premise. Software isn't a static thing, it's something that is constantly evolving and creating great software, like creating great anything, requires a lot of effort, a lot of time and a lot of dedication. This is what you pay for when you pay for software. You don't pay for the actual copying of software, you pay for the effort that went into creating it.

Also, designing software and features by "crow-sourcing" is a terrible approach. Why? Henry Ford said it best “If I had asked people what they wanted, they would have said faster horses.”

As I see it, the biggest current threat is bruteforcing of this service, at least based on the recent snapchat attack. And implementing rate limiting would solve this issue.

And given that this is a very hard problem to solve this kind of solution could be a good bandaid. Anyhow, this is at least my 2 cents on this issue.

I don't really think you need to solve this problem using crypto. I think a simpler solution would be to use the "hash it" solution, but restrict how many lookups each client can do. You can either do this by the using the client's phone number, IP or other unique information etc. This way an attacker would have a very hard time brute forcing this.

Additionally you could use captchas (or other humanity tests, such as SMS verification) to limit hackers creating automated accounts (in order to fight automated bots spamming and polluting the network).

I don't think there's a huge differences serving 1 million daily users or serving 100 million. In both cases you need highly scaleable systems. In 100 million case you need a lot more computers, but I think the overall structure of the systems could be very similar (e.g. sharded databases, auto fail-overs, extensive monitoring etc.) Of course you need a larger team serving 100million users, but I don't think you need to scale the team as much as Twitter has done.

I have actually built and scaled a system similar to Twitter called Plurk (which has millions of users, billions of data items and similar use cases as Twitter). We built this with a team of a few developers and one sys-admin. While Twitter is at a much larger scale, I really doubt you need 1000 engineers to solve that problem, because even at Plurk's scale we built automated systems for scaling, monitoring, backups etc. (e.g. sharded the databases, used master-master MySQL setups that supported auto-failovers, nagios for alerts etc.)

You may say: but they have mobile apps? But so do a lot of other companies that don't have 1000 engineers. You need a few really great mobile devs to build great mobile apps, again based on my experience.

I think what has happened for them is that their structure isn't that good and they have scaled too fast (and in this process they have hired a lot of B and C people that aren't that good). It's a least my conclusion based on the limited information I know about them.

While Twitter a is cool service I can't imagine what 1000 engineers can do all day long? Based on this maybe they are building their organization wrongly and following their footsteps isn't the correct way to follow.

For OT to work you would need the ability to track all the changes and mirror them to the other users. React appears to have the ability to track changes, but I am unsure how easy it would be to mirror them over the network.

There's a great article here that describes how OT and other synchronization algorithms work (OT is event passing): https://neil.fraser.name/writing/sync/

The terminal isn't that well supported right now. I only use the terminal version on servers or when editing configs. Not when writing code/documentation.

Would love if someone improved this ;-)

I have just published https://github.com/amix/vim-zenroom2 - - it's based on goyo.vim and seems to work better. Thanks bilalq for the tip :-)

goyo.vim seems to be the real deal, at least it seems to fix problems I have with vimroom (for example, the centering will be wrong if you update the font).

Still tho' it would be awesome if Vim had better native support for window margins, so you don't have to revert to hacks.

No dyslexia :-), it was simply a copy and paste gone wrong and I wrote that in a hurry.

The idea is to remove all the distractions (tabs, status bar, split screens etc.) and just focus on one thing. It also centers the content (which is non-trivial to do in vanilla vim) and includes special colors and settings to make Vim look like iA Writer when you are editing Markdown or reStructuredText.

Of course, it's not for everyone, but I like it when I am writing text or just editing one code file.

JavaScript solver: https://gist.github.com/amix/8063003 ;-)

One of the problems I see with Github structure is firing people. One of the tips you see most successful companies follow is hire slow and fire fast. I think it's unrealistic that every hire you do will be the perfect match and a lot of times things just don't work out. The question is: how does Github handle this case?

I read this article today: "How Google Sold Its Engineers on Management" 1), which seems to be a much bigger study of how managers affect work and performance. The general conclusion of Google's study is that management matters if it's empowering workers (and not micro managing them).

Github is definitely an interesting experiment in a totally flat structure. Google tried a similar flat structure in 2002, but concluded that it did not work that well. Will be interesting to see how it works for Github as they grow even bigger.

1) http://hbr.org/2013/12/how-google-sold-its-engineers-on-mana...

Here's some great commentary of game 6: http://www.youtube.com/watch?v=pvToX22oG8s

This is really awesome! Congrats to the team!

We have a ton of JavaScript/CoffeeScript code and I really wish we could use something like Dart. JavaScript is great for smaller projects, but once you get a ton of code it really becomes a unmanageable mess.

I think tho' it would be amazing if Dart could run on the server side as well. This way you could just have one language on both the client and the server.

And you base this on what? MySQL is used to scale some of the biggest Internet properties in the world and it has been doing that for many years. Stop spreading FUD.

Postgres got proper non-hackable replication in version 9... And it still isn't that great.

MySQL was a great database that solved a problem. It did not solve it in a 100% complaint way, it did not have all the features that "dbms experts wanted", but in the early days it was very easy to started. In version 5+ they have fixed a lot of the issues and it is now on-par (or better) than most other databases. I also think they have focused on the right stuff: ease of use, easy way to fix performance issues, great ways to setup replication, great ways to take backups, not losing data, optimized to be used for the web etc. Also, most bigger properties (including Facebook and Google) use extensively MySQL.

If Mongo is going to be like MySQL, then great!

One of my employees rents a 1BR in near the main square (Aliados) for ~360euro/month (~480USD), but you can find something much cheaper a bit more far away.

Porto, Portugal: It has a river, sea and beaches, lots of history, nice weather, great food, nice people and it's inexpensive. It also has Ryan Air, which means that you can visit other parts of Europe cheaply (<100 euros for a roundtrip in most cases). I am at least living here now and I enjoy it.

If you like a little bigger city then Lisbon, Portugal is also an option.

Scaling DropBox is not only about sharding the data; it's a huge operation that requires management of thousands of machines, complex and fault tolerant algorithms and management of a lot of people (from database administrators, to sys-ops, to very smart developers). It's also not something that you can Google the answers to as very few companies have handled 100+ millions of users, billions of daily updates and petabytes of data.

Comparing this to wolf3d is comparing apples to oranges as scaling DropBox and implementing wolf3d are entirely different problem domains . But I would say that wolf3d is a much easier problem that's solved by just one man (John Carmack), while DropBox requires tons of resources and hundreds of people with different skill-sets.

Location was important some years ago, but I think it's less and less relevant now. I think you can create amazing technology anywhere (in Latin America, in Europe, in Asia etc.)

Skype is a great example of this: they created a billion dollar company in Europe; and most of the development was done in Estonia (a country of about 1.3 million people, much less than most bigger cities).

Asia, especially Taiwan and South Korea, have some amazing examples as well (like HTC, Samsung, Asus etc.)

Dropbox does about 1 billion file updates pr. day across millions and millions of active users, petabytes of data and millions of devices. I think it's very ignorant to think that their problem is just solved by using powerful machines and caching...

I remember reading "Hire the Right Customers"1), which kind of goes against this notion to try to please everyone. Some customers are just the wrong customers and not worth collecting.

1) http://gettingreal.37signals.com/ch04_Hire_the_Right_Custome...

If you like this remember to donate some money to the project on http://pypy.org/ [I am not in any way affiliated with PyPy, only supporting the project].