Goodbye, MongoDB - <AUTHOR> http://www.zopyx.de/blog/goodbye-mongodb <comment><USER3> How tiring. We can litter the internet with posts like this, but it would be a _lot_ more useful to post reasoned, factual and detailed posts when discussing the merits or pitfalls of a given technology.

I've launched very high traffic websites using MongoDB, where it was the least of my worries. I've also launched very high traffic websites using MySQL, where it was my primary source of pain.

Shall I now run around screaming loudly about how badly MySQL sucks? On the surface you might assume so, but with reasonable effort to consider all the facts, it becomes clear that there's more to this than just "this database is better than that one because I hate it."

This post is more of an angry payback rant from someone who got banned from IRC for being abusive to newcomers and greenies. On top of that, it is factually incorrect in some spots, and misleading in others. Not impressed.

That said, NoSQL databases are evolving extremely quickly, and have reached a point of maturity that they can excel in the right scenario. Just like relational databases, they can provide big benefits, given that the user takes the time to learn how to use them, as well as making sure they have a use case that merits the strengths of their chosen tech.

I really enjoy working with MongoDB and Redis, and have been a community cheerleader of sorts for PostgreSQL for years. It _is_ possible to have multiple tools in your toolbox, and use them when appropriate. No tool is perfect, and no tool is perfect for every job.

Complaining bitterly that your shiny new piano makes a lousy boat, on the other hand, simply adds to the noise.

<comment><USER4> would love to hear specifically what was factually incorrect

<comment><USER5> Here's one I noticed: I have a small app running on 2.0.1 and there are _two_ prealloc.X files in the journal directory, each one is 256mb. Not quite 3GB unless my math is wrong. (There's a third file in the directory named `j._0` which is also 256mb)

</comment></comment></comment><comment><USER6> It seems like ranters against MongoDB often don't really understand how it works and thus what it is good for.

My simple mental model for MongoDB is: indices (should!) fit in memory and documents are stored contiguously on disk. That is it in a nutshell. A query involves in-memory lookups and maybe only one disk seek. Writes in place are usually possible.

I have been happiest with MongoDB in two different scenarios:

The first is in developing small web applications where there is no scaling issue, and the fact is that MongoDB is so easy to develop against and simply provides a great developer experience. As needed, I use a cron job to do a mongodump a few times a day; or, if I really need high availability (which, frankly, often I don't: if a system is unavailable one or twice a year for an hour it is no big deal) then replica sets are OK.

The second scenario where I have really liked using MongoDB was doing analytics on a modestly large stream of social media data. A single Mongo master on a large EC2 instance was adequate to handle writes and slaves on other large EC2 instances each fed a different analytics application. This setup of apps reading from a slave on the same server worked really well for me. This was a low hassle experience.

I do have one customer with really large MongoDB setups on multiple data centers, and I am working around right now on some hassles, but we haven't found anything else as cost effective for the customer's applications.

All that said, when I can use it, just using a single (no horizontal scaling) PostgreSQL server is for me the most hassle free developer experience, but I have always used PostgreSQL for small or medium sized applications - <USER2> that needed to scale.

<comment><USER7> You mention two different scenarios that use MongoDB effectively, and both are not what MongoDB purports it's supposed to be used for.

The first is a small setup. MongoDB is called that because it's supposed to be for "humongous" data sets. Also, in what case is 3GB of data preallocated for journalling, which is one of the points in the article, good for a small installation?

The second is "modestly" sized stream of social media data. Having myself worked with a much larger stream of social media data in Mongo, I can attest that the second you leave the land of a single Mongo server, you have a much bigger problem, sharding. Sharding is terrible in Mongo, writes are _shard_ locked, not collection, your shard keys are immutable (imagine having an indexed field you can only set ONCE), and fraught with data loss. Did you have a drop in network connectivity between your mongos and you config server? You just silently lost data. Safe being on doesn't matter, if the config server doesn't get the write it isn't able to report where the data is for a read, even if it is confirmed it was written to disk.

To your point about mongo ranters not understanding what it's good for, MongoDB tells everyone it's good for "big" and "fast" data. However, it fails at both of these, because it doesn't easily scale up from one node, and it doesn't write quickly when you actually want to make sure that your data is there. What's the point with writing data quickly to something that looses it quietly? Might as well pipe it to /dev/null/

</comment></comment><comment><USER8> I feel like 1 - 2 years ago I was reading a slew of blog posts with the title "Why We Chose MongoDB." Now it seems like all of the blog posts are some sort of "We Just Finished Migrating off of MongoDB, Here's Why."

I know nothing about MongoDB and have never tried it. But the message seems pretty clear.

<comment><USER9> The message is, just like every technology, there's an initial period where a vocal minority loves it and tries to use it for everything. Then, there's a backlash where a vocal minority hates it and thinks anyone who uses it is clearly an idiot. All the while, the silent majority go on getting work done. It's been this way for as long as I can remember.

<comment><USER10> I fully agree here. A couple of years ago, when I went on interviews at startups, they were all using nosql db's and were proud of it. More recently, I've been interviewing at startups that are now bigger, need to mine the data that they've collected over the last few years, and now are migrating off of nosql db's to rdbms' (or creating strange amalgams of the 2). I did see this coming, but it was very hard to make them understand back when it was the coolest thing.

<comment><USER11> The reality is that developers are maturing in their understanding of different technologies and they are learning how to apply them in correct use cases.

There continues to remain a "golden hammer" syndrome where white horses and unicorns run free, but it doesn't exist.

Instead, the vision of "NoSQL" was to tell developers that they did not have to use relational data for everything, but could, instead, use the right tool at the right time. Why is this such a hard concept?

If you are a developer and you don't understand the tool you are wielding (it's pretty clear the author of this blog didn't), then you will incorrectly use the tool and experience pain.

That is the fault of the developer, not the tool.

<comment><USER12> Care to specify at which point the author of the blog post misunderstand MongoDB? Its not pretty clear to me about that.

Are you saying that one of the way he is using MongoDB is incorrect? If yes, what point did he say reflects that?

His rants seems quite specific.

</comment></comment></comment></comment></comment><comment><USER13> While some of the author's criticisms are valid, some of them are completely wrong:

> Having no option to perform an operation comparable to UPDATE table SET > foo=bar WHERE....

What? db.collection.update does exactly this. See: [http://www.mongodb.org/display/DOCS/Updating#Updating- update...](http://www.mongodb.org/display/DOCS/Updating#Updating-update%28%29)

MongoDB fit a nice niche for a read heavy mid-scalability db solution. Every DB has it's niche. Trying to use it outside of what it's good for is going to get you burned. If people just did their research before blindly committing to a platform, we'd see a lot less posts like this.

<comment><USER14> Agreed. I found the mapreduce criticisms to be a little off:

> Now instead of fixing a bad implementation or fixing the underlaying > architectural issues, MongoDB is moving to Hadoop.

I don't think that's accurate. They have a new "aggregation framework" coming that is meant to replace mapreduce. It could be a wrapper around hadoop, but I couldn't find anything documented about that. I completely agree that a blocking mapreduce is annoying, however, does any framework have a non- blocking mapreduce? I haven't tried many mapreduce implementations out, so this is a genuine question.

<comment><USER15> I don't believe RavenDB blocks. Instead, it returns the results along with a flag to indicate if any of the source data may have been modified while the operation was running.

<comment><USER16> You're right, all RavenDB indexing operations (including Map/Reduce) are done on background threads. When you query, it returns a flag (as you say) indicating if the index is currently stale or not.

</comment></comment></comment></comment><comment><USER17> > Leaving memory management to the operating is nice idea - in reality it does > not scale and does not play very well.

This is why I think that Linus's tirade against O_DIRECT is misguided: <https://lkml.org/lkml/2007/1/10/233>

Here's the thing: the kernel is a library. It took me a long time to fully understand this deep idea. The kernel is just a library that has a different and more expensive calling convention (syscalls) and runs at a higher privilege level.

It's also much less flexible than user-space libraries. Its interface is an unholy mix of syscalls, ioctl(), /proc, vdso, etc. There is a high bar to adding new interfaces. Removing or changing existing interfaces is basically not allowed.

The resources that the kernel uses are much harder to account for or predict. How can you ensure that a process always gets at least X MB of page cache, and that some enormous "cp" that some sysadmin is running won't evict all your MongoDB pages that are caching your database? Sure you could mlock() your pages, but now you're basically side-stepping all of this smart kernel cache management that was supposed to be helping you so much in the first place.

User-space management of buffers and caches is more flexible, easier to account to its owner, and more predictable. It can't handle page faults with Linux's current interfaces, but the L4 guys have figured out how to let pagers run in user-space and handle page faults. I hope that someday this work becomes mainstream. Our 20-year-old OS design is showing its age.

<comment><USER18> This is why most DBMS products do their own memory management. They just suck up as much memory as you will allow and use it for their own devices. Specialized, tunable, application-level memory management will probably always beat a general-purpose, application-ignorant OS-based scheme.

But, there's something to be said for the simplicity - for most folks you don't need to manage the memory yourself. When you need it though, there's really no easy substitute.

<comment><USER17> > But, there's something to be said for the simplicity - for most folks you > don't need to manage the memory yourself.

Yes, and most people don't need to implement printf() themselves, which is why there is libc. Just because you're doing it in-process, in user space, doesn't mean you're rolling your own!

</comment></comment></comment><comment><USER19> _There is no single way to control the memory usage using system tools except maintaining mongod instances on dedicated virtual machines without running further services. There are numerous complaints from people about this stupid architectural decision from various side and 10gen is doing nothing to change this brain-dead memory model._

Can someone explain to me why this is actually a big issue? Except for really tiny apps, I imagine that having dedicated VMs for your MongoDB actually would be perfectly fine? Probably even preferred?

<comment><USER15> I was wondering the same. It's pretty standard for databases to not be very good about sharing with others, memory-wise. That's why having a dedicated server is such a popular best practice for non-puny applications. And MongoDB says it's not designed for puny applications right there in its name.

<comment><USER11> There are fairly straight-forward ways to control memory usage in MongoDB, especially if this is a concern for you. All you need is a bit of OS know-how and it works just fine.

We run both large (multi-shard clusters) and small memory (500MB - 2GB) use instances of MongoDB and have no problems.

It would be good to have developers acknowledge that, perhaps, they may not have all the information instead of declaring that something can't be done.

<comment><USER20> Care to explain how, say in linux?

<comment><USER21> Either jason has something really interesting up his sleeve or he simply doesn't know what he's talking about.

Last I checked linux had no interfaces to partition the pagecache in a meaningful way, short of rather extreme gymnastics involving kernel-patches or tmpfs abuse.

If that has changed then I'd certainly also be curious to hear about it.

</comment></comment></comment></comment></comment><comment><USER22> Hell yeah.

From what I've seen of MongoDB I'm not impressed at all. In some carefully controlled cases, performance would be acceptable, but change anything at all (even the order that data is inserted) and it just sucks.

For one particular application, the performance difference between MySQL and Mongo was like the difference between the Space Shuttle and a Chevy Sonic.

<comment><USER23> I think it's important people understand WHY this is the case, because it's not simply an issue for MySQL vs Mongo.

The simplest way to get really good performance for multi-row queries (even if you fall out of cache) is to physically order your data in query-order. (that is, if you are going to ask for the most recent 100 blog comments, order the comments by (blog-post-id, reverse comment-date).

MySQL -Innodb makes this really easy (your data is physically ordered by primary key). In MongoDB it's not possible.

Here is a more elaborate explanation...

MySQL-Innodb stores record data in primary-key order (it puts the data right into the b-tree). This means that if you want to access 100+ records in primary-key order, it's pretty darn efficient. Even if it's out of cache, it could be just one or two disk seeks (depending on how many records fit in a block)

MongoDB stores record data in a heap-table in a semi-random order based on insertion and freespace, with each document receiving a "doc id". You can make an index on whatever you want, but when Mongo fetches multiple records, it cross-references every index entry with the doc_id. If your data is out of cache, this means a seek for _every single document_. AFAIK, as of 2012, there is no way around this, because there is no way to get mongodb to store the document data directly in the b-tree. This is a big part of why Mongo is super-slow if you fall out of cache.

HOWEVER, there are some other systems that also have this problem, including some ORMs that sit ontop of MySQL. Ruby-on-Rails forces you to use an auto_increment primary key for every record -- which means even if you use MySQL, you are forcing your data to be in a semi-random insertion order. Django does this as well. If you want to efficiently fetch a bunch of records (like 100 comments on a blog post), then you want them to be in primary key order.

In the SQL world, Oracle, MS-SQL, and Postgres also normally use a form of heap-table for records... This allows records to have a physical "ROWID" which can be used to directly look them up (it's a physical block address with an O(1) lookup). However, it also means they are in semi-random order. The ROWID was an important join and foreign-key optimization back in the days of nightly SQL jobs on machines with very little RAM. Today, it's not a good optimization. B-tree indirect blocks are always in RAM, so direct ROWID lookups have little benefit over b-trees, and the huge drawback of no natural primary key ordering. One can workaround this problem with fully-covered- indicies, table-in-index, and key-clustering -- all of which have their own frustrating tradeoffs.

Does primary-key ordering have downsides? References to records are bigger (They have to contain the full primary key), there is no guaranteed stable way to reference a record (for foreign key constraints), and if you change fields in the primary key, the entire record must be moved. In the "old days" there was another big drawback, b-tree O(log-n) lookups are much slower than ROWID O(1) lookups.. Today this is not an issue because all b-tree indirect nodes fit in RAM always.

Bottom line, if you want the easiest way to order data properly, use MySQL- Innodb, and choose your primary key wisely. If you are using another storage system, study up on how you can control physical ordering becuase every system is different.

<comment><USER24> Does MySQL(InnoDB) allow you to cluster on something other than the PK?

Big advantage in that option (Postgres, MSSQL, Oracle).

</comment></comment></comment><comment><USER25> "My essage to companies building applications on top of MongoDB: assigned smart people to MongoDB and don't leave the database work to people that can hardly spell their name or that can just count to three. Yes, this paragraph is harsh and does not comply with diversity but it is true and reality. The number of people that should not do any database related work, people without reasonable background, people lacking basic skills in understanding databases is extraordinary high."

Isn't that true for _any_ database? What point are you trying to make? That a large MySQL deployment can be flawlessly be maintained by people that can "hardly spell their name"?

<comment><USER26> I also like "essage" and "assigned smart people" instead of "assign smart people" in a sentence talking about intelligence and spelling. He's probably not a native speaker but that only excuses the second bit, and only partly.

</comment></comment><comment><USER27> This is kind of a strange list of complaints.

MongoDB memory management is a legitimate concern... but not because it's hard to control memory usage of a single mongod.

"More granular locking" is a temporary, non-scalable solution?

I've run out of energy, actually, but really?

<comment><USER28> Ya, there are lots of well reasoned complaints about MongoDB out there. This is...not one of them. It's weird that this is getting voted up.

</comment></comment><comment><USER29> This reads more like a rant then an actual discussion of problems the company was having with MongoDB. There is a place for valid criticism, but this is the polar opposite. I am actually more interested in the fact that this made it to the front page so fast tehn the actual content of the article. Are there so many people upset with Mongo that even something as poorly done as this rant can get publicity ?

</comment><comment><USER30> We dumped Mongo for a lot of the same reasons listed in the article. Their python driver isn't great either.

<comment><USER31> In favour of...?

<comment><USER32> In my case, Redis. Really good choice for my project

<comment><USER33> I don't understand how you would switch from mongodb to redis. They don't do the same thing, at all.

<comment><USER34> I think your second sentence answered your first.

<comment><USER33> How does someone mistakenly choose mongo for a job fit for redis?

</comment></comment></comment></comment></comment></comment><comment><USER35> Wow, how many "Goodbye, MongoDB" stories are coming? The last days had several ones. Not sure if this is already a trend?

<comment><USER36> The trend is this: any loved technology that's been around a little while (Rails, Node, Mongo, etc) makes for dramatic farewells on hackernews. It's not unlike supermarket tabloids.

<comment><USER37> I disagree. The trend is this: any hype has an equal and opposite anti-hype. 10gen have spent (probably) millions of dollars and countless hours representing MongoDB and singing its praises in various media (conferences, user groups, Web, etc.). If you do so, you need to expect equally fierce reactions when people realise your claims are unsubstantiated (or, at the very least, not as universal and problem-free as you originally portrayed).

<comment><USER24> I wonder where all those millions come from? All venture capital, or is 10gen gaining paying customers?

<comment><USER38> As a former Aol employee, I know of a large support contract between them and 10gen. I think a lot of money comes from large companies who have teams that want to use MongoDB, and the large company buys a huge support contract for that team and any other possible team who wants to use it. Maybe that was just Aol, but I'm guess that pattern is that same in other large tech companies too.

</comment></comment></comment></comment></comment><comment><USER39> But.. but.. MongoDB is web-scale: <http://www.youtube.com/watch?v=b2F-DItXtZs>

(Note how the video raises some of the same concerns as the blog post)

<comment><USER40> Because nothing adds to the cogency of one's argument like cartoon animals...

</comment></comment><comment><USER41> I'm amazed at all these (excuse me) idiotic articles. People/projects have different requirements, so there are many databases around(relational and nosql and key/value). Just because your needs do not match MongoDB's (or MySQL's or ...), does not mean the technology is useless.

</comment><comment><USER42> The biggest problem with mongoDB IMO is that BSON dictionaries are ordered. Let that sink in for a sec: the hash data structure must be ordered.... The solution most drivers run with is to just alphabetically order each dictionary.... a ineffcientcy I'm not really happy with.

</comment><comment><USER43> Look, someone else realizing that Codd was right.

<comment><USER44> Right about what, exactly? The relational model certainly has its advantages, but it is not without its disadvantages, either. When it comes to databases, there's no one model that caters for every situation.

</comment></comment><comment><USER45> This is completely unrelated to the subject, and I have not used mongodb, have no idea if it's good or bad, and I don't even know how to spell it, but isn't it ironic that this post shows up on the day when the top HN post's title is "Please learn to write"?

As I said, no idea how good or bad mongo is, but I'm guessing, if you are as sloppy in your code as you are in your English, I'll be happy to give mongo the benefit of the doubt...

</comment><comment><USER46> Its unfortunate that right now none of the 3 major document stores seem to be doing all that well or are easy to use straight out of the box. I use and like mongodb but only for prototyping. I havent decided what to go with longer term if my projects have a need. Couchdb is interesting but seems to be going through some serious growing pains right now with the couchbase product being very confusing to figure out and use. Riak is also interesting but it seems more specialty then a general purpose tool.

Kind of a bummer.

<comment><USER38> I've done a lot of research and testing with Riak (not had the pleasure of using it in production yet), and although some of the things that are easy in other DBs are backwards (like listing all records, for instance), I have a secret love affair with it. MongoDB claims to have simple scalability, but I've worked with it on a large project at Aol and found this to not be true at all. We basically had to implement our own sharding on top of it since its auto-sharding was so poor, and only needed to shard in the first place because of the global write lock. Riak, on the other hand, is an operations dream, and if you're a dev and ops guy in one (like me) I stay up at night thinking about using it for every project.

That said, a lot of people have started to use Riak for a general purpose tool. There are some development growing pains associated with this (and you have to think _very carefully_ about your keys and data structure) but it's only getting easier with things like secondary indexes and Riak search. If there was a non-expensive way to enumerate all the data in a bucket, I think that'd be the one last item on the checklist before I jumped on it.

</comment></comment><comment><USER47> I keep reading about how mongo's use of memory mapped files is real bad. Isn't that the same technique used by varnish cache and that's what makes it awesome? Can someone explain please?

<comment><USER21> Varnish has a much simpler access pattern (which happens to fit the page-cache semantics like a glove in almost all use-cases) and was developed by a drastically more competent team.

Comparing varnish to mongodb is akin to comparing a precision Rolex from Swiss to a plastic mickey mouse watch from a gumball machine.

</comment></comment><comment><USER48> Actually, using mmap-ed files is a great idea. It's precisely what Varnish does too.

<comment><USER49> That was exactly what my thoughts were too: letting the OS do all the memory management, caching, is a strategy many great projects use, among which PostgreSQL and Varnish.

However, I do feel there is something "wrong" about the approach MongoDB is taking. They need to allocate new files in huge buffers, which completely take up all I/O while being filled with zeroes. There is no logical hierarchy in the files, and it just feels a bit weird.

Perhaps they should've taken the approach PostgreSQL did, which is to simply use files and read from them instead of using mmap. The whole reason they went for a global lock instead of more granular lock is because the whole mmap'ed area is one big blob, and it was the most "obvious" approach.

<comment><USER38> Thanks for the insight on the global write lock. I've searched and searched and wasn't able to find anything on _why_ they have the global lock.

Out of curiosity, is there a simple way to explain why someone would mmap instead of just reading files directly (I've never done any programming with mmap, so I'm a bit ignorant of its use cases)?

<comment><USER49> This SO entry seems to answer your question fairly well: [http://stackoverflow.com/questions/258091/when-should-i- use-...](http://stackoverflow.com/questions/258091/when-should-i-use-mmap-for- file-access)

</comment></comment></comment></comment><comment><USER50> So what is the new solution? Back to relational? Or another type of document store?

<comment><USER51> MongoDB is fine at the conceptual level. The problem is that the architecture and implementation are consistently poor in myriad ways. It is a case study of what can happen when well-meaning individuals with little experience in database architecture and implementation attempt to build a scalable database engine.

That said, a competently engineered RDBMS can do everything NoSQL databases can, particularly limited databases like MongoDB. The caveat is that you have to learn how to use those databases; they are very feature rich and powerful but that flexibility makes them more complicated. PostgreSQL is a very good choice from the open source world and is just as fast as NoSQL du jour in the hands of someone that knows it.

I currently design extreme-scale real-time analytical database engines, so I have no vested interest in any particular solution (we are not really competing with the current market). If I was going to build a large-scale web app today and needed a backing database, I would go with PostgreSQL -- it is very capable and well-engineered.

<comment><USER52> ...a competently engineered Turing Machine can do everything NoSQL databases can, particularly limited databases like MongoDB. ... Emacs is just as fast as NoSQL du jour in the hands of someone that knows it.

FTFY.

The difference between using a good competently engineered distributed database and PostgreSQL is that when your prime concerns are horizontal scaling and operations costs, the distributed database can be an order of magnitude simpler and faster than PostgreSQL given the same amount of effort.

</comment></comment></comment><comment><USER53> Blame yourself before blaming MongoDB. If you've been around the software industry you should always be mindful of fads and vaporwares. When you make a decision to use MongoDB you better have done your homework first or do some testing yourself. Given the low cost of renting bunch of EC2 machines for a few hours, it's idiotic to build a business around MongoDB or any other system that has not been fully proven without doing bunch of stress testing yourself. Yes, and don't trust software vendors, get independent advice or test it yourself.

</comment><comment><USER54> A good read. I'm working on a relatively large project now, written in Node (whee), and I was considering going full-koolaid with Mongo. I think I may stick to MySQL.

<comment><USER55> Give PostgreSQL a shot if you're still considering databases.

<comment><USER54> I love Postgres, but I'm building something for OSS use and most unzip-and- deploy devs don't know how to set up Postgres.

Any additional information that you might be able to give me that might convince me?

<comment><USER55> Ah. If your target is people who aren't going to be reading docs, I don't think any DB is really preferable. :)

Any more details about the project, or is it under wraps?

<comment><USER54> It's basically a simple blogging platform, going to be released OSS.

Most devs know how to get MySQL running without too much thought, but many don't even know what Postgres is.

<comment><USER34> It might be worthwhile educating them. It shouldn't be that much harder to show them how to setup Postgres than MySQL :-)

If it's only a simple blogging platform, it might well be that MySQL will do the job just fine though.

</comment></comment></comment></comment></comment></comment><comment><USER32> My Xen VM crashed several times by day during several weeks. And, this problem disappears when I removed my mongodb database...

<comment><USER56> Some kernel version had issues with block devices causing kernel panics, a minimum of 2.6.36 is needed.

</comment></comment><comment><USER57> _using JSON as a query language was a bad decision. The current JSON query language works for standard queries but the functionality of the operators is limited._

These two things don't go hand in hand. JSON _could_ be used to elegantly represent complex queries. A problem with the query system isn't necessarily a problem with JSON.

<comment><USER58> >JSON could be used to elegantly represent complex queries

I think it could be used to represent complex queries, I don't think elegantly would be it. I'm thinking it would be a small step up from an XML representation.

</comment></comment><comment><USER59> We started out with just MySQL. Then added MongoDB + replicasets. Then added Cassandra. And now we just finished adding Elastic Search. All of this for the same Web Application. Use the right tool for the job. The pattern i've noticed is that indeed we started migrating DATA out of MongoDB, mostly to Cassandra.

</comment><comment><USER60> is there any replacement for mongodb?

<comment><USER24> PostgreSQL: [http://nosql.mypopescu.com/post/14114368488/postgresql- hstor...](http://nosql.mypopescu.com/post/14114368488/postgresql-hstore-the- key-value-store-everyone-ignored)

</comment></comment><comment><USER61> tl;dr We LOVED MongoDB (<http://www.zopyx.de/blog/plone-using-highcharts-and- jqgrid>) but we got burnt so it's USELESS and BRAINDEAD!

<comment><USER62> That's the common pattern. MongoDB is easy and convenient when you first start using it, but you hit the limitations pretty quickly. I had the same experience.

<comment><USER38> I really think if they had document-level locking, it would be a much more successful DB. 10gen's answer to this is "just shard!!1" except that sharding in Mongo really isn't as easy as they make it out to be...not to mention what database makes you shard just so you can support more than a few hundred writes per second? Maybe this has improved a bunch since I got burned by it on v1.6, but I believe it's very misleading to claim scalability of a product that has a global write lock. Being forced to shard when you reach the small- medium size is just sad.

All other aspects about it I love, though. It really makes development and deployment so much faster. Replica sets aren't perfect, but setting up MySQL replication w/ automatic failover on three or more machines is a recipe for disaster unless you have a DBA to sit there and baby sit it full-time.

<comment><USER63> Locking in particular has improved substantially since 1.6. For example, 2.0 introduced yielding in some cases where MongoDB would go to disk rather than page-faulting with the lock held[1]. This has been extended and improved for 2.2, along with increasing the granularity of the lock from process-wide to per-db. There are plans to increase the granularity further in future releases.

[1] To see an example of the difference this makes see <http://blog.pythonisito.com/2011/12/mongodbs-write-lock.html>

</comment></comment></comment></comment><comment><USER64> mmap files and sharding...

It seems like the problem is that you're not using MongoDB in a sharded setup to begin with. For good or bad, MongoDB targets the scale where you need sharded and replicated setups. In other words, a large enough operation to require multiple servers for data storage. If you need the opposite of that, which is multitenancy, MongoDB is not going to be a good fit.

On the other hand, MongoDB has always been sold as a rapid prototyping and easy to iterate datastore, which is attractive for people working on small projects. Then they have an "oh shit" moment when they run into operational issues.</comment>


3D Computer Graphics: Software Revealed - <AUTHOR> http://www.cores2.com/blog/?p=204 <comment><USER2> Sigh, the canonical reference on 3D graphics "in software" has been the Foley and Van Dam tome "Computer Graphics: Principles and Practice in C" [1], followed closely by "Principles of Interactive Computer Graphics" [2] by Newman and Sproul. Followed closely by the Graphics Gems series, and then Watt's eponymous "3D Computer Graphics" [3] and "Real Time Rendering" [4] by Moller and Haines.

All wonderful texts and can tell you everything you want to know about doing 3D graphics in software. They won't help at all (generally) for GPU based graphics sadly.

[1] [http://www.amazon.com/Computer-Graphics-Principles- Practice-...](http://www.amazon.com/Computer-Graphics-Principles- Practice-2nd/dp/0201848406/)

[2] [http://www.amazon.com/Principles-Interactive-Computer- Graphi...](http://www.amazon.com/Principles-Interactive-Computer-Graphics- McGraw-Hill/dp/0070463387)

[3] [http://www.amazon.com/Computer-Graphics-3rd-Alan- Watt/dp/020...](http://www.amazon.com/Computer-Graphics-3rd-Alan- Watt/dp/0201398559/)

[4] [http://www.amazon.com/Real-Time-Rendering-Third-Tomas- Akenin...](http://www.amazon.com/Real-Time-Rendering-Third-Tomas-Akenine- Moller/dp/1568814240/)

<comment><USER3> There's some good information in those books, but I don't think this one is redundant with them (admittedly, I've only skimmed it so far). Differences: 1) open-access; 2) interactive HTML5 demos of most of the concepts.

<comment><USER2> My opinion is that the killer project would be to combine them, which is to say put together interactive text/exercises around each concept so that you could read all the theory then see it in action.

</comment></comment></comment><comment><USER4> Direct Link to the contents: <http://www.cores2.com/3D_Tutorial/>

</comment><comment><USER5> This is interesting and probably quite useful for a beginner, although I would have to say some of the techniques diverge from what more experienced graphics programmers use, e.g. working out the lighting with acos, instead of normalising the light and /normal/ vectors. Also the coding style, e.g. local variables LikeThis drove me a bit nuts. I think with refinement it could be really good though.

<comment><USER6> Hi Andrew, I'm Jeremy - the author of the book. So yes, I immediately agree with everything you say, and would even like to ask you to clarify more on some of the technique divergence. Optimisations (such as acos vs. normalization) was done on purpose to make the math and code crystal clear to the reader. I've really been frustrated with great books that explain one equation but then implement its optimized form without any clear transition or derivation. I'm also aware that my texture system is very different than the standard approach; this was done for my own sake since I felt more comfortable with the Barycentric system, though (correct me if I'm wrong) that is rarely used in comercial applications. I'm always looking to make things better for the reader, so do tell me what other professionals think!

As for coding style - PLEASE do comment on it! I'm pretty anal about formatting and standards, and wrote this tutorial over a few months so things might of broke down over time. I'll be posting the book's code on Github tonight and allow several users to modify some code as requested by users here and on Reddit.

</comment></comment><comment><USER7> > _What's notably interesting about this book is that it works through all > programming lessons in HTML5 Javascript, using the new Canvas tag._

 _Definitely_ taking a look at this one. Thanks!

edit: if the creator is reading this, you have a stray "might of" part way through. It's "might have" - sometimes shortened to "might've" which sounds similar, hence the unfortunately-frequent mistake.

<comment><USER8> Unless you're talking about the strength of something - then, it's "might of". This would be most applicable in bad fantasy.

</comment></comment><comment><AUTHOR> Wish this had existed a few months earlier. I taught a 3d game engines class this year, for which I wrote up a concise tutorial of how to write a wireframe renderer from scratch [1], plus some additional conjured-up lecture material, but I might've used this textbook instead if it had existed at the time.

[1] <http://www.kmjn.org/notes/3d_rendering_intro.html></comment>


How geeks fight discrimination - <AUTHOR> http://www.miller-mccune.com/culture_society/the-revolution-will-be-mapped-1650?article_page=2

<comment><USER2> This is great, but can we avoid the self congratulatory wanking in the title? Way to downplay the role many non-techies no doubt played in this.

</comment><comment><USER3> The article starts here: [http://www.miller-mccune.com/culture_society/the- revolution-...](http://www.miller-mccune.com/culture_society/the-revolution- will-be-mapped-1650?article_page=1)

<comment><USER4> Even better, the print version: [http://www.miller- mccune.com/culture_society/the-revolution-...](http://www.miller- mccune.com/culture_society/the-revolution-will-be-mapped-1650.print)

</comment></comment><comment><USER5> all the truly intelligent people I know realized at some point that they were getting diminishing returns with more technical knowledge and devoted some of their time to refining their people and business skills.</comment>


OpenTransact a tiny payment standard - <AUTHOR> http://stakeventures.com/articles/2010/02/11/opentransact-a-tiny-payment-standard <comment><USER2> Unfortunately, there's a reason why banks and other financial institutions tend to batch transactions together and settle them overnight: liquidity requirements.

Basically, the shorter the settlement period, the more cash the banks need to keep immediately accessible. The increased liquidity requirement carries with it the opportunity cost of keeping that cash available at-hand instead of in more productive investments. With end-of-day settlement, each bank only needs to transfer the _net_ amount (outgoing transfers minus incoming transfers), which is -- barring a really nasty run on one of the banks -- an order of magnitude smaller. So there's a tradeoff between settlement speed and transaction cost.

But this doesn't prevent the bank from immediately notifying the recipient of the funds that a transfer has been made. It's just that the funds aren't available for use until after settlement.

For some interesting details about the tradeoff between settlement delay and transaction costs, I found <http://ideas.repec.org/p/bca/bocawp/06-20.html> to be an interesting read.

<comment><AUTHOR> You are absolutely right about that. Which is another reason why traditional banks are a not likely to jump on this straight away.

Liquidity is not an issue for most of the applications I hear planed using OpenTransact as they typically operate with 100% reserves.

I am very particular personally to the Narrow Banking <http://en.wikipedia.org/wiki/Narrow_banking> ideas as a replacement for the traditional monolithic multipurpose banks, where again this would not be an issue.

Taking a hypothetical narrow banking world to it's extreme using OpenTransact a typical everyday bank consumer needs could be split by functionality into 5 different narrow companies with each their function:

* A financial supermarket end that only resells financial services to replace the traditional bank branch * A narrow banking cash account structured as a cash mutual fund. 0% interest, 100% reserve. * A money market mutual fund for savings * A card issuer linked to your cash account offering a visa debit card service * One or more exchanges for transferring funds between banks instead of ACH

I am not even mentioning credit here, but credit and insurance can all be offered by different institutions like <http://prosper.com> again using the Narrow banking model.

Obviously the above example assumes that our financial needs are all going to be the same as today. More than likely we will see financial products that are completely different than what we see today. In particular because the existing banks are not likely going to give up their existing revenue sources.

</comment></comment><comment><USER3> I'm not sure what problem this solves.

Go look at the spec for FIX. This is what's necessary to specify modern financial transactions.

I'm not sure that naming endpoints is really that helpful to any particular problem. You've replaced a CUSIP with a URL, I guess.

</comment><comment><USER4> Very clever. I hope this works out.

</comment><comment><USER5> Some nice demos of how it works:

<http://www.opentransact.org/usecases.html#simple>

</comment><comment><USER6> Too simple. The banks will never adopt it.

<comment><AUTHOR> Innovators dilemma. If the banks want to adopt it then cool, if not more opportunities for innovators.

The regulators though are the real issue, but we have some ideas for dealing with them as well.

<comment><USER5> This is awesome work, congrats. Have you been in contact with some banks about it already?

<comment><AUTHOR> Thanks. I am probably not going to talk directly with banks, but I know there are people from the traditional banking and payment card world on the Agile Banking list and I'm hoping one or two smart banks might use the economy as an excuse to innovate.</comment></comment></comment></comment>


Yahoo Publisher Network (YPN) closing down. One less competitor for AdSense - <AUTHOR> http://snippets.com/is-ypn-yahoo-publisher-network-really-closing.htm

<comment><USER2> Is this part of the deal that Yahoo signed with Microsoft?

<comment><AUTHOR> I dont think so... my understanding was that that was strictly a search deal. Yahoo is going to continue to sell ads against Bing results on yahoo.com.

<comment><USER2> This <http://news.cnet.com/8301-13860_3-10298303-56.html> seems to say both companies will use adcenter.</comment></comment></comment>


Ask HN: How do I improve my handwriting? - <AUTHOR> Has anyone successfully hacked handwriting improvement? I write left-handed and my left hand hooks so that it's above the line when I write. <comment><USER2> I won't say I hacked it, but I did improve my handwriting. It took deliberate practice over a period of months.

I'm right-handed, though, and so for English and other left-to-right languages my experience is different than yours will be. I have noticed that my boss (left-handed) writes top-to-bottom which may be a useful trick for you. She has the top of the page turned to her right and essentially writes the characters "sideways" as she goes down the line. This may help with the way you hook your hand (you wouldn't have to focus on changing your hand position, just the direction of movement as you write and how you draw the characters).

</comment><comment><USER3> When I was a child, I had to do what we called at home "les pages d'écriture" ("the writing pages"). Before I was "allowed" to go out and play (a figure of speech, I had every liberty to roam anywhere), I had to write the alphabet on ten pages, following a canonic form. All had to look good, no cheating or I had to write two good pages for one bad page.

This is the "process" my siblings enforced with me, as our parents enforced with them before I was born.

I had new teachers in primary school accuse me of not being the one who did my homework because it was an adult's handwriting. I had to write in front of them to disculpate myself. My handwriting now is not fabulous, but it's legible.

My point is that you can find a canonic form and go at it as you would everything. Systematic improvement, tight feedback loop, continuous corrections.

PS: The "process" was adapted and writing was just a part of it: I had to read texts from books and magazines, look up words I didn't understand in a dictionary (Larousse 89), write them down and learn them, then write a summary of the text, and present it in front of one of my siblings, my sisters (oral summary) and they would test my understanding (the articles were from Science & Vie and dealt with science and engineering, the books were classics in French, and I would try to the best of my ability to summarize and reason by analogy and share my mental model).

This started before going through K-12 and was in addition to homework.

</comment><comment><USER4> There's a subreddit where users give feedback.

"Is your handwriting terrible? Tired of being embarrassed by your penmanship? Come here and trade tips on ways you can improve your handwriting, talk about italics vs cursive, or share your progress pics."

[https://www.reddit.com/r/penmanship/](https://www.reddit.com/r/penmanship/)

</comment><comment><USER5> I found it helped me to slow down a bit, and to think about (focus on) the movement of the head of the pen/pencil.

If you're left-handed, you might try a left-handed pen. (No, really. There are such things. They are geometrically identical to normal pens, but they contain faster-drying ink.)

</comment><comment><USER6> try train via look at the fonts at fonts.google.com :)</comment>


The Mailman of Kabul - <AUTHOR> https://www.nytimes.com/interactive/2017/08/11/world/asia/100000005352749.html <comment><USER2> page not found</comment>


Notch to take down Minecraft and Mojang in SOPA protest - <AUTHOR> https://twitter.com/#!/notch/status/157865002177536001 <comment><USER2> What does 'silently take down' though mean? And note that he actually said 'minecraft.net' and not 'Minecraft'. Does this include the login servers, preventing anyone from playing, or just the public having web site?</comment>


Mongrel2 - <AUTHOR> http://mongrel2.org

<comment><USER2> _Use sqlite3 as its configuration storage_

What a horrible idea.

<comment><USER3> What a great idea. Most processes use internal and inaccessible memory as configuration storage. When they start up, or when you issue a special command, they reload some of their configuration from a file in some custom dialect. Sometimes, configuration is exposed with some custom interface to hosted code. Django, for instance, lets you manipulate settings from your application, but there is no external interface for it.

Mongrel2 has exposed it's internal configuration storage for programmatic manipulation in an easy and standard way. If you would prefer configuring it with a file, you could create your own configuration file format and loader. Good luck doing that with, say, apache.

<comment><USER2> Umm. Yea. Right.

Good luck putting your sqlite db under version control, templating it, modifying it easily from the commandline, etc.

The idea is just idiotic, especially considering how little configuration is needed in first place for something like a mongrel.

There's a reason why almost all services expose their configuration in a more or less human readable _file_.

</comment></comment></comment><comment><USER4> Zed is doing some cool stuff at the moment, loving his work.</comment>


This French Fry Vending Machine Is Poised for Global Domination - <AUTHOR> http://www.grubstreet.com/2013/11/french-fry-vending-machine.html

<comment><USER2> My wife would kill to have this nearby our home.

</comment><comment><USER3> Anyone know what they cost?</comment>


Show HN: Geosnitch - <AUTHOR> https://github.com/Jkillelea/geosnitch <comment><AUTHOR> Geoclue uses sub-providers to get accurate location info. The best one I've found so far is Skyhook, which can get my location to within a dozen yards. The choice of MQTT was simply in order to have something lightweight and generally config-free. I'd like to have alternative location services and remote listeners at some point, or depending on whether other people like the idea.

Feedback welcome, and all that jazz.</comment>


Zoom: The curious case of reputational risk - <AUTHOR> https://medium.com/@matuzg/zoom-the-curious-case-of-reputational-risk-a174b8f3babd <comment><USER2> Article implies Zoom servers are still in China, but as of April 28, they transitioned all US service to the Oracle US cloud.

[https://www.oracle.com/corporate/pressrelease/zoom- selects-o...](https://www.oracle.com/corporate/pressrelease/zoom-selects- oracle-to-support-growth-042820.html)

<comment><USER3> Hey, I'm the author, good point! Fixed to language to make it clearer. Thanks for pointing it out</comment></comment>


SQSH – *Nix CLI Tool for Sybase/SQL-Server - <AUTHOR> https://sqshtips.blogspot.com/ <comment><AUTHOR> See also the FreeTDS User Guide[0] page for more info.

0 - [https://www.freetds.org/userguide/software.htm#SQSH](https://www.freetds.org/userguide/software.htm#SQSH)</comment>


Online, ads-free, open source search engine - <AUTHOR> http://trokam.com/

<comment><USER2> Nice interface. How does Trokam index pages?

<comment><AUTHOR> Thanks!

Web crunchers ask the server for a task to do. The server reply with an URL. The cruncher download the page, look for relevant words and links. The cruncher send the report to the server. The cruncher ask the server for a new task to do.</comment></comment>


Bounding Viral Impact in Experiments - <AUTHOR> http://juneandrews.com/2015/02/27/bounding-viral-impact-in-experiments/

<comment><AUTHOR> Good Morning! I'm the author of the post and tried to highlight the salient points. Please feel free to ask questions for a more indepth explanation of application, derivation, etc!

I will be actively checking and answering questions today.

</comment><comment><USER2> Great post. Quick question: Is there a way to artificially bound virality in an experiment so that you don't need to partition the network without destroying the signal?

<comment><AUTHOR> Ah! In some situations it is possible at the cost of a degraded user experience.

Let's say we have an experiment that encourages sending likes. There are two users here, the user sending the like and the user receiving the like. A traditional a/b test flips a coin. If the coin turns up heads, then the user receives the treatment. To control viral spread we want to flip a coin on the interaction of the like. To implement with a traditional experiment framework flip two coins, one for the user who could send the like and one for the user who could receive the like. If both coins turn up heads, then the interaction of the like receives the treatment.

A benefit is it allows us to test 2 hypothesis:

* Sending more likes is good for users

* Receiving more likes is good for users

However, the cost is an inconsistent user experience. If each coin is a 50-50 coin, then for a user sending the likes a random half of their network will be featured. Similarly for the user receiving likes, they may not understand why the sudden upturn in likes from some people when they may feel closer to others in their network.</comment></comment>


List of Computer Science courses with video lectures - <AUTHOR> https://github.com/Developer-Y/cs-video-courses/blob/master/README.md <comment><USER2> Previous discussion: [https://news.ycombinator.com/item?id=13000158](https://news.ycombinator.com/item?id=13000158)

<comment><AUTHOR> Sorry for the replication. It seems that HN should have a better duplicates removal algorithm.

<comment><USER3> You posted the link to the README, which is different from the link to the repo itself. Since these two aren't really duplicates, I don't think it's a fault of HN's algorithm.

<comment><USER4> Since the root page of a repo renders the README, the two URLs are not very different. A sophisticated duplication detection algorithm could recognize that.

<comment><USER5> The algorithm would have to examine the HTML returned by the URLs to determine they are duplicate pages. There is no way to determine they are duplicate pages by just analyzing the URLs. It is not impossible to have two different posts to HN that are legitimately different content that have the same domain and even partially matching paths. In order to work in a dependable way, the algorithm would have to examine the HTML returned by the URLs to determine they are duplicate pages. In this case, that wouldn't even work because they aren't actually duplicate pages. In order to mark these two URLs as duplicate I think you might need to use some machine learning and then it would only yield some level of confidence that these were indeed duplicate pages as a result.

<comment><USER4> Or they could just special-case GitHub repos and their readme files. But what is duplicate detection if not machine learning? One can't be sure the same URL is the same document if submitted at different times.

</comment></comment></comment></comment></comment></comment><comment><USER6> That's more lectures than a student could see. Now we need a full concept chart dependency tree and an adaptive content suggestion system to guide students through this sea of lectures.

I'd like to have a system where you take tests to rate your understanding level and decide where to start.

<comment><USER7> It depends a lot on what you want to specialize in. There are a few entry level classes that are good at preparing you for one of many paths you can take. For the very basics, I've heard good things about harvard's cs50. For an intro to systems, I'm currently going through CMU's 15-213 which I think should be a class in all CS departments.

<comment><USER8> Thanks, that is good insight. It's hard to know what to refer someone to when there are so many "intro to CS" classes listed.

</comment></comment></comment><comment><USER9> One of my biggest complaints about a lot of the stuff found in YouTube is the lack of preparation.

Those without teaching experience think it is enough to fire-up the screen recorder and go for it. Sure, that can work, but it often results in a bad or mediocre product.

The most egregious of issues being when they destroy your concentration because they are making mistakes live as you follow along. "No! Wait! That was a period. No a slash. No, I forgot to define the class. Oh, yeah, the import was wrong. Wait, a database table is missing." ... and more.

Some could argue that this can be interesting because you see errors. Point taken. This is the wrong way to teach about errors. It destroys the student's train of thought and detracts from learning.

The right way to teach about errors it to explicitly teach them. In other words, you do it correctly and then say "let's see what happens if we delete this column in the database". You can then expose the issues and how to deal with them. To unexpectedly run into issues during a tutorial due to lack of preparation only confuses students. Imagine a Calculus professor fumbling as he/she explains course material, it would be maddening.

If you want to teach, please take the time to prepare the material and the script. Have at least a second monitor on your machine so you can view the script as you record your lesson on the main monitor. Never take students down a path you have to reverse from, it can be very confusing.

EDIT: By "script" I don't mean "code" but rather what you are going to say and do and when. Yes, you need to have your code visible on a separate monitor as well just to make sure you don't make mistakes.

</comment><comment><USER10> I highly recommend MIT's 6.006 for a good intro to data structures and algorithms. My college's course wasn't great, but watching the MIT lectures and working through CLRS helped me gain a really solid intuitive understanding of complexity and approaches to different classes of problems. At the very least it helped a lot with interviews!

<comment><USER11> Can you an example of a real world problem you'd use that as a programmer besides surprising your interviewer?

<comment><USER12> I made an Elasticsearch querying tool that lets you construct multiple dependent queries.

If I hadn't taken an Algorithms class, I wouldn't have thought to use a directed acyclic graph, and to topologically sort the different queries so that they are resolved in order.

That was actually the first time I'd used something from a theory class on the job! It was pretty exciting, though probably mundane for most engineers :).

</comment></comment></comment><comment><USER13> Excellent resource. I'm almost at the end of Andrew Ng's ML course on Coursera and was looking to learn more about convex optimization. I will definitely try out some of the links there (Machine Learning > misc machine learning topics)

</comment><comment><USER14> Thanks for posting this. As a bootcamp grad, I just bought a Intro to CS textbook to start learning the basics, but I can't wait to look at some of these too

</comment><comment><USER5> This is cool. I think "visual learners" or whatever it's called are a bit on the fringe in CS but we do exist. When starting something new, I learn much more easily by video or discussion with people. As I become more comfortable with a subject, technical documentation becomes progressively more useful.

<comment><USER10> I'm the same way, I find a good series of lectures to be the best way for me to wrap my head around something. I think it's a combination of "visual" and "global" learning styles. A global learning style means you work your way from the big picture down to the details as opposed to "sequential" style where you are better off diving into a detailed problem and building your knowledge outward from there [0].

[0] [http://www4.ncsu.edu/unity/lockers/users/f/felder/public/ILS...](http://www4.ncsu.edu/unity/lockers/users/f/felder/public/ILSdir/styles.htm)

</comment></comment><comment> surrey-fringe I'm glad Onur Mutlu's stuff is listed here. Best lecturer I've ever had.

<comment><USER10> Yes! I've been watching his lectures as a supplement to my own comp architecture class.

<comment><USER15> Can I ask you how much difficult or advanced find you those lectures ? are those graduate level ? upper ungraduated/first year graduate ? Or material is only bachelor level ?

<comment><USER10> I'd say it's bachelor level. It definitely requires some prior knowledge of digital logic and general computer systems concepts. Here's a link to the course page where you can find the prerequisites and a syllabus and some other info:

[http://www.ece.cmu.edu/~ece447/s14/](http://www.ece.cmu.edu/~ece447/s14/)

</comment></comment></comment></comment><comment><USER16> I'm excited to go through this. I plan on completing a degree in a few years but I'm always hungry for information. Thanks for posting.

</comment><comment><USER4> I guess this shows how much of a commodity video lectures are. It's difficult to know the quality in advance of watching a video.

Teaching is a market for lemons. Worse, the student who buys a lemon will often not realize it, nor the employer who hires the lemon-trained student.

Most of the videos listed here are from reputable institutions. I guess we're lucky that the lemon-sellers are trying to profit from their videos.

</comment><comment><USER17> I'd love a list like this with reviews/some sort of curation alongside.</comment>


Ask HN: Who is not betting on Elixir and why not? - <AUTHOR> It's easy to find people talking about why they took the gamble to switch to Elixir. I'm interested in those who have tried out Elixir in production (or a serious prototype, not just dabbling) and then decided not to use it. Why not? <comment><USER2> I'm a bit biased in my development perspective and a bit jaded with the state of back-end development, but here goes:

I've done a decent amount of Elixir in prod over the last year and a bit and I've found the lack of a decent, modern static type system pretty frustrating. I love the idea of failing fast, but most of the time we're throwing 500s from trivial developer mistakes (and yes, we do TDD). Lazily evaluated libraries like Streams or Ecto.Multi explode in weird, non-local ways because the types are not checked at the call-site, making refactoring and iterating a chore.

I have tried out Dialyzer, but it lacks many things you would expect from a modern type system (eg. parametric polymorphism). While experimenting with it I've been able to get it to accept trivially broken programs without complaint, which means I've never been really be sure it's got my back, so have given up on it. And yes, this is with the flags ratcheted to their highest settings. Not to mention all the third party libraries who forget to keep their typespecs up to date.

I realise designing a type system that can handle hot-reloading in a cluster is still an open problem (interesting work in progress on this front though), but most folks aren't really at the scale where that is a problem. They'd probably be far better served using a more traditional deployment process while getting the immediate benefits of the improved iteration speed, refactoring confidence, and data modelling that languages with modern type systems provide. The front end is beginning to 'get it' with the likes of Typescript, Flow, Elm, Reason, Purescript, etc, and I can only hope that their good work and excitement will eventually flow back to us on the back-end...

<comment><USER3> > excitement will eventually flow back to us on the back-end

Like e.g. Java, Scala, C#?

<comment><USER2> Scala maybe, but it has its share of problems, alas. On a purely features level I'd definitely be looking for something with null safety, disjoint unions, pattern matchin with exhaustiveness checking, local type inference, and parametric polymorphism (ie. generics). These are what set a modern, nicely typed language apart from the more constrained, frustrating kind that caused many to escape to PHP, Ruby, Python, and now Elixir in the first place. We need a richer experience beyond that though in terms of ecosystem, compiler performance, teaching materials, etc. in order to really drive things in that direction though and get more back-end devs on board. Obviously something in our approach is not working - and it must be partly our failings. It's going to take a while to turn the ship around, but I still have hope!

</comment></comment></comment><comment><USER4> Coming from the banking industry, nobody looks at using unproven languages or frameworks unsupported by a large community or major vendor. If you "guess wrong" on a language you're looking at a multi-million dollar rewrite down the road which is an unacceptable risk. It's also very difficult to find staff or contractors who are familiar with new or unpopular tech. Basically any industry that deals with "real money" or "life and death" intentionally does not follow developer fads.

<comment><USER5> Would you consider Erlang to be a proven language?

[http://www.erlang.org/about](http://www.erlang.org/about)

<comment><USER6> Erlang != Elixir. They run on the same VM, and you can reference Erlang code in Elixir but that doesn't make them equally production ready.

<comment><USER5> Yes, I understand, I was just wondering if Erlang would be considered a "proven language".

From my (limited) Erlang experience, Erlang & Elixir have the same core functionality. Elixir has a "nicer" syntax (I prefer Erlang's syntax but most devs I've talked to like Elixir's).

So if Elixir isn't proven but the concurrency model & programming paradigms make sense, maybe Erlang is a good choice.

* WhatsApp Scaling to 1 Billion users in erlang: [https://www.youtube.com/watch?v=c12cYAUTXXs](https://www.youtube.com/watch?v=c12cYAUTXXs) * [https://www.erlang-factory.com/upload/presentations/395/Erla...](https://www.erlang-factory.com/upload/presentations/395/ErlangandFirst-PersonShooters.pdf)

<comment><USER6> > "I was just wondering if Erlang would be considered a "proven language"."

Erlang is proven in production for server and telephony apps.

> "From my (limited) Erlang experience, Erlang & Elixir have the same core > functionality."

Depends on what you mean by 'core functionality'. If you mean the functionality provided by Beam VM or OTP, then there's a case to be made for that. However, the library ecosystem for Elixir is separate from the one for Erlang.

To use an alternate example, Java is definitely a 'production ready' language for enterprise software. However, if I write a new language for the JVM, it's not automatically 'production ready'. In most cases it's the library ecosystem which is under evaluation, not the platform the language runs on.

<comment><USER7> Just saying, but so far, there have been more critical bugs in erlang solved due to the Elixir community than Elixir critical bugs solved... so well...

<comment><USER8> Can you give some examples?

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> I _love_ elixir, but it's just a language. There are other great languages, too. Use what fits your brain. Don't listen to what others carry on about. The only downside I can see for me is that there are fewer, less battle-tested libraries available as compared to, say, ruby. The most unexpected benefit of getting into elixir has been the community--it's a positive place to be, and I feel it has made me a better, more confident programmer. <3

<comment><USER10> One of the great things about using different languages on my off time is that the number of things that fit my brain has grown over time. It doesn't actually take that long for an experienced polyglot programmer to pick up a new language.

I think use what fits your brain is the kind of advice that sounds good but does most people a disservice. At work use what allows you to ship high quality code, on time, within the business constraints that you have. But you'll have much better options in your career if you take at least some time to expand your brain so more things fit in it.

<comment><USER9> I guess what I meant by "use what fits your brain" is more along the lines of, "try a bunch of languages first, then use the one you like most". Without experimenting, you'll most likely be lulled into thinking your first language is the one that fits your brain best. I would disagree with the notion that a language fits one's brain after you've picked it up. I really don't like javascript, for instance, and I've used it quite a bit.

</comment></comment></comment><comment><USER11> As someone who spent a long time in Ruby land, the last thing I want right now is another dynamically typed language.

I'm a big fan of Erlang and OTP, and really wish for that style of concurrency, failure tolerance and distributed computing. For me, the lack of static typing in Elixir struck me as a missed opportunity from the outset. The Ruby-like syntax isn't enough to change the game for me (I find it significantly less attractive than Ruby, but that's not important), even with macros.

Since I don't use Elixir, the above isn't necessarily a criticism of it -- I'm sure it's great. Just not for me.

Go is what I'm using now, and I've been playing with Rust and will probably start using that when I have a new project. I've been using Haskell for some side projects. I like OCaml a lot, but I won't touch it until multicore support lands and matures. For web projects, my plan is to transition everything from JavaScript to TypeScript, precisely for the type system.

No more dynamically types languages except for scripting.

</comment><comment><USER12> Deployment is by far the biggest pain point I've seen in new Elixir developers. Developers use Mix in development, but then build releases using Distillery for production. There are a few gotchas and pitfalls that almost everyone falls into when using Distillery like using `System.get_env` and forgetting `server: true` in their `prod.exs`. Hot upgrades can also be a source of a lot of confusion. Configuring distributed clustering in production can be tricky especially if you're running on Docker/Kubernetes/etc.

That said, I built [https://gigalixir.com](https://gigalixir.com) to try and help with some of these issues and improve the deployment story for Elixir.

</comment><comment><USER13> We are using Elixir in production for a site with traffic that can spike in a short period of time.

Elixir has helped us reduce our costs by 1/3 and improve our API response times from 50ms to 5ms. (Ruby -> Elixir)

Using erlang/Elixir processes forced us to reevaluate the way we handle state and were able to find many ways to optimize.

I believe our code is now more organized, extensible and powerful. Our infrastructure is also more complicated, but much more fault tolerant as we have fallbacks for fetching data etc.

Deployment was pretty terrible but a simple scaleable solution with AWS is build with a docker container, push to ECS and launch ECS + ElasticBeanstalk and you're good to go.

</comment><comment><USER14> All my new server-side code is in Go (where all my old code was in Elixir) because I wanted something I could build locally and deploy easier. The deployment story for elixir is... substantially worse than ideal, for, seemingly, no reason at all. At the time I was writing the deployment scripts, not only was the hot-code-replacement not going to work, even AOT compiling to .beam files was broken, with multiple 3rd party tools not helping.

<comment><USER15> Elixir seems to have better abstractions at building CRUD apps (and websockets) than Go. Are you building CRUD type apps? Have you writing lots of SQL vs using ecto to be painful?

<comment><USER14> Not exclusively CRUD apps, but some. I've not minded the DB work I've done so far, but I also don't mind SQL. Changesets are a smart API, but fundamentally aren't much different than normal SQL. Ecto is nicer for loading lots of joined data, but... eh. Hasn't bothered me not having it. So I'd be hesitant to say Elixir has lots of amazing APIs -- good, but not indispensable.

</comment></comment></comment><comment><USER16> We wrote a few small services in Elixir at work and I loved it. I had been using it at home and reading all the books, and would have been happy to commit 100%.

However, I don't think anyone else was getting excited about Elixir, or more broadly about functional programming. When it came time to choose a stack for a much bigger project, Go won out. The only specific complaint about Elixir I'm aware of is that ramp up time would be too long every time we bring a new dev onto the project. In hindsight I don't think Go is any different in that regard. A Ruby/JS dev either needs to learn pattern matching, macros, list comprehensions, and a bit of OTP for Elixir, or they need to learn static typing, pointers, goroutines, and idiomatic error handling for Go.

Personally, I'm happy either way. I'd still probably choose Elixir if it were my choice to make, but I'm loving Go too.

</comment><comment><USER17> I'm pretty strongly on the Elixir train, but here's where I see its greatest weakness:

On many platforms, the best practice is to have stateless application servers, with separate stateful data stores. On the other hand, the big advantages of Erlang/Elixir are in managing state along with your application logic.

In a vacuum, that can be a big win. But I'm worried that the advantages are not enough to overcome the weight of tooling, services, and best practices built around the stateless model. For example, Heroku explicitly tells you to avoid application state, and Docker is built around a destroy-and-rebuild ethos.

For my project, Elixir/Phoenix is great as a "better Rails", but I know I'm only scratching the surface of the platform's strengths.

<comment><USER12> I don't want this to feel like an ad, but [https://gigalixir.com](https://gigalixir.com) should help in this area. Its a platform-as-a-service, like Heroku, but it's designed to encourage stateful application servers by not doing daily restarts and supporting hot upgrades. Disclaimer: I'm the founder.

<comment><USER18> Very cool! Where do your servers run, and is there any callback planned in case your service gets discontinued?

<comment><USER12> Right now, the servers are on Google Cloud Platform in the us-central1 region. It's in multiple availability zones for reliability.

I highly doubt the service will be discontinued ever since traction looks good and we have plenty of funding, but Gigalixir and Heroku are almost interchangeable. The only difference really is that Gigalixir doesn't require a Procfile. However, if you fallback to Heroku, you'll lose clustering, hot upgrades, etc.

</comment></comment></comment></comment><comment><USER19> 99% of software developers haven't heard of elixir

<comment><USER20> Given the extent of coverage on HN I would say there are very few devs. on HN who haven't heard of Elixir.

<comment><USER21> I've been reading HN for years, and this is the first time I've seen/heard of Elixir.

Sample size of 1, self selected, your mileage may vary, things in the mirror are closer than they appear. That is, it isn't really meaningful as a data point in isolation.

I only clicked this link out of morbid curiosity, on why someone would make such a presumptuous statement. Put another way, the question asked is heavily loaded. I was more interested in the discussion around the statement, to see what people thought, than the content of the question.

You may have what you and others consider the greatest thing since sliced bread. And you might not fathom why others would not see it that way. After all, it is the greatest thing since sliced bread. It is a dessert topping and a floor wax (obligatory SNL skit reference).

Even with all this, the criteria for success, oddly, rarely has being "the greatest thing since sliced bread" as part of the core elements of being successful. You don't need to be superior to be successful (though I am not stipulating that Elixir is superior, I've never seen it, used it, etc.)

The question is why would people choose this over others? What benefit would this language provide that others simply cannot?

I've used many languages during my professional and educational life. I've never seen one that was universally appropriate for all tasks. I some that fit the majority of tasks I worry about, very well. I've seen others fit very poorly. I have no opinion on Elixir, other than to note a small vocal group wondering aloud how anyone could not use it.

Reminds me of Python in the 90s.

<comment><USER20> That is a very lengthy reply to a very simple observation :) If you are genuinely curious why people are interested the short version is all the power of Erlang VM made available via way more conventional syntax. There are a lot of very unique properties of BEAM (Erlang VM) that are truly not available elsewhere: preemptive scheduler, per process GC (no STW crap), all the OTP goodness for dealing with failures, node transparency hard to list all the pros to be honest

</comment></comment></comment></comment><comment><USER22> Erlang and Elixir are both fine languages, but the BEAM is slow and not suitable for anything computationally intensive. Extending your program whether via NIFs or Ports is a PITA. It's great for anything requiring many active connections like front controllers and P2P, but outside of that you're better off with Clojure if you want an FP with immutability IMO. I think that you need to be working on a niche concurrency-focused application, or have engineering manpower to burn, to justify using a different language for such a narrow case. Erlang library support still is not very good except for, again, concurrency-focused ones (gproc for instance).

</comment><comment><USER23> Personally I am a happy Python developer and I don't feel it's worth it for me (in terms of time) to learn another language. Maybe once Python starts to be obsolete I'll switch but in the meantime I can't afford spending time learning something new just for the sake of it.

<comment><USER24> That's a really interesting (and, in my opinion, negative viewpoint)

I have been a Python developer since 2006/2007 and every time I depart to another community for a while, I return with a ton of new ways to think about problems. Not only that, you'll usually have a newfound appreciation for things in Python you might not have really cared about before (eg decorator syntax)

\- Becoming a Rails developer was a game changer. The Pythonistas tout it to be 'magic', but it's really not. It's easy to understand what is going on. Once you use a tool like Rails in more advanced situations – every Python web framework looks like a horse drawn carriage.

\- On a related note, reading Eloquent Ruby was one of the most epic nonfiction reading experiences of my life. After reading that book, I rarely see "programming magic" to be magic anymore. I understand it all. A lot of the knowledge from that book translates well to Python too, since Python and Ruby are very similar.

\- Learning Clojure and using it day-to-day at FarmLogs has made me think more functional than I did previously.

It's usually not just the language that is going to open your mind - but the frameworks, tools and communities that grow around the language. It's like visiting a new country. You're gonna love certain customs and dislike others.

Anyway... saying you don't have time for something that will open your mind and make you a better programmer sounds like a grumpy old man who's missing out on the world.

<comment><USER25> If I saw your reply before writing mine, I wouldn't have bothered responding :) Absolutely agree with every single word

</comment></comment></comment><comment><USER26> I think this a great discussion topic. I am really glad that everyone loves elixir on HN but I would like to hear both sides to analyze the weakness and strong points of a given technology. This makes more a balanced discussion instead of just praising a language. Honestly I would personally enjoy a more technical scrutiny of a language / framework, especially from a technical site like this one. Does anyone have a good write up on something like this for Elixir?

</comment><comment><USER27> Personally I'm waiting for Alpaca :)

[https://github.com/alpaca-lang/alpaca](https://github.com/alpaca-lang/alpaca)

</comment><comment><USER28> The deployment can be difficult to automate especially if you are attempting to inject application properties at runtime.

There are solutions out there,though documentation may not cover every use- case, especially if you are deploying to something like AWS or GCP (Not everyone can adopt Docker just yet).

The Hot-Upgrade is a great idea though you will have to do your research to integrate this with your Cloud Provider.

Overall I'm betting adoption will be niche, and primarily via Teams coming from Rails. Until a major cloud provider starts offering native support + the community grows to a sizable percentage, it will be slow to catch on.

</comment><comment><USER29> Don't use. You're gonna be in big troubles to recruit developers who knows that tech.

It's already an issue with Erlang. It's made 10 times worse with Elixir.

<comment><USER15> Are you hiring developers who can't learn new languages?

<comment><USER30> Learning languages and using them to develop an actual production-grade product are two different things.

Pick something proven.

I worked in a Scala shop and people spent tons of time flailing about arguing over syntax, dealing with bad IDE plugins / slow tools, etc. They'd have been better off just sticking with Java.

<comment><USER31> I would say Erlang VM is already proven.

<comment><USER30> I agree. So use Erlang VM and Erlang language, don't use Elixir yet...

<comment><USER31> Elixir and Erlang have similar symantics, compiles to same byte code. You can use any Erlang library in Elixir without any overhead, all the tools (debugging, profiling) which works with Erlang works with Elixir.I don't see why you can use Erlang and not Elixir.

</comment></comment></comment></comment></comment></comment><comment><USER32> After reading the second paragraph the headline should be rephrased "Who has tried Elixir and then decided not to use it and why not?"

</comment><comment><USER20> Lack of comments can be interpreted in positive light for Elixir I guess :).

<comment><USER33> I doubt everyone chomps at the bit on a Saturday morning (for most of them) to remind others on the internet that, yet again, there are no silver bullets.

</comment></comment><comment><USER34> Elixir is just an AST transform for erlang/otp. I like erlang and there are features that I wish it had sometimes, but elixir couldn't be further from what I'd come up with if I decided to fix it myself. It takes all the bad parts of lisp, shoves them into a bad ast format, and crunches it all down to beam code. It's just a terrible implementation of a terrible idea.

I am actually moving components of my apps away from erlang to f# to shield it from the destruction of beam that elixir will bring about.

2/10

<comment><USER5> What is elixir doing that's so bad to .beam format?

<comment><USER6> I wouldn't worry about it, the GP is clearly trolling, there's nothing of substance in what they're suggesting.</comment></comment></comment>


Pauli Effect - <AUTHOR> https://en.wikipedia.org/wiki/Pauli_effect <comment><USER2> Its opposite is the "technician effect", whereby your malfunctioning system always works when the technician (who is going to fix it) is present.

Incidentally, the antidote to the Pauli Effect is to tape a raw sausage to your circuit. Everyone knows that your circuit always works when you put your finger on it, and the sausage emulates your finger. (There is actually some truth to this joke, as the sausage/finger provides a little parasitic capacitance, which can make an unstable RF circuit become stable.)

<comment> martin-adams And of course there are the demo fairies, who magically make your fully working prototype stop working only when presented in front of an audience.

<comment> david-given Have you heard of quantum bogodynamics?

The theory is that there's an elemental particle, the bogon. When this is absorbed by a piece of equipment, it frequently malfunctions.

Good engineers, over time, become bogon sinks, so that when there's an engineer around the bogon absorption rate of the equipment they're working on drops. Meanwhile, managers tend to become bogon _emitters_. So, give a device to them and it instantly fails. Pauli, here, sounds like he was a massive bogon source.

This handily explains the effect where the device will reliably fail but when an engineer shows up to look at it, it works fine. It also explains why demos are so flaky: all those people watching the demo are emitting a massive bogon flux...

<comment><USER3> I read the first line as: "Have you heard of quantum Bogeyman"

Going to get a second cup of coffee now...

<comment><USER4> "Our lord and saviour."

</comment></comment></comment></comment></comment><comment><USER5> Pauli was one of many physicists at the time who were totally disinterested in experiments and equipment. This put Heisenberg in some hot water during his doctoral exam:

"When an angry Wien asked how a storage battery works, the candidate was still lost. Wien saw no reason to pass the young man, no matter how brilliant he was in other fields"

[https://www.aps.org/publications/apsnews/199801/heisenberg.c...](https://www.aps.org/publications/apsnews/199801/heisenberg.cfm)

</comment><comment><USER6> This actually happened in our lab when the experiment only worked when a grad student stood in a specific location far away from the control computers. Turns out he was blocking a stray laser beam, and now we have a curtain that replaces him.

<comment><USER7> Stray laser beams? I'm glad I don't work in your lab...

</comment></comment><comment><USER8> This is probably a result of the same bias that when you buy a new car you see it everywhere (confirmation bias?) so when Pauli is present and an experiment goes wrong its another point on the tally of Pauli Effect anecdotes. When he is present and it all works OK no one cares. But obviously this is meant as a bit of fun.

<comment><USER9> Bader-meinhoff effect

<comment><USER10> Appropriately enough, I just mentioned the Baader-Meinhof effect in a discussion only a couple of days ago.

</comment></comment></comment><comment><USER11> Would be interesting to see data on conditions with and without Pauli present to remove biases. Pity we don't have him anymore.

If we have a guy like that again to suspect of such effect, then we could try the isolation of parameters to see if there was in fact just a bias or it could lead to deeper issues. And interference from quantum biology might not be completely out of the question [https://en.m.wikipedia.org/wiki/Quantum_biology](https://en.m.wikipedia.org/wiki/Quantum_biology)

</comment><comment><USER12> so even the smartest of us are susceptible to magical thinking and superstition it seems... :)

<comment><USER13> Once you start looking for it, it becomes fairly common :)

August Kekulé's work on the structure of benzene came to him in a dream: [https://en.wikipedia.org/wiki/August_Kekul%C3%A9#The_ourobor...](https://en.wikipedia.org/wiki/August_Kekul%C3%A9#The_ouroboros_dream)

Ramanujan credited his mathematical skills to a Goddess: [https://en.wikipedia.org/wiki/Srinivasa_Ramanujan#Personalit...](https://en.wikipedia.org/wiki/Srinivasa_Ramanujan#Personality_and_spiritual_life)

When Einstein met Tagore, "Einstein: Then I am more religious than you are!": [https://www.brainpickings.org/2012/04/27/when-einstein- met-t...](https://www.brainpickings.org/2012/04/27/when-einstein-met-tagore/)

Pierre Curie: "There is here, in my opinion, a whole domain of entirely new facts and physical states in space of which we have no conception." [https://en.wikipedia.org/wiki/Pierre_Curie#Research](https://en.wikipedia.org/wiki/Pierre_Curie#Research)

Kurt Gödel proved God exists: [https://en.wikipedia.org/wiki/G%C3%B6del%27s_ontological_pro...](https://en.wikipedia.org/wiki/G%C3%B6del%27s_ontological_proof)

And take a look at the recent popularity of Discordianism and Thelema among programmers.

</comment></comment><comment><USER14> nice !!

</comment><comment><USER15> Thanks, Obama

[http://knowyourmeme.com/memes/thanks- obama](http://knowyourmeme.com/memes/thanks-obama)

<comment><USER15> Not sure I understand the downvotes.

<comment><USER13> It's a low effort meme-like post that adds nothing to the article or discussion. Those are frowned upon at HN.

It's not impossible to make joke-y replies to posts and receive upvotes, but it takes a lot of practice (or authority).

If a 100 people would post one-liner memes then the comment section would be no fun to read. It used to be a strength of HN to have an incredibly resourceful comment section with good debate. It was not uncommon for the author of a programming language to chime in on a discussion about said language.

See: [https://news.ycombinator.com/newswelcome.html](https://news.ycombinator.com/newswelcome.html)

> The most important principle on HN, though, is to make thoughtful comments. > Thoughtful in both senses: civil and substantial.

> The test for substance is a lot like it is for links. Does your comment > teach us anything? There are two ways to do that: by pointing out some > consideration that hadn't previously been mentioned, and by giving more > information about the topic, perhaps from personal experience. Whereas > comments like "LOL!" or worse still, "That's retarded!" teach us nothing.

Edit: I see that your account was created 1499 days ago. This may make my reply seem silly (also coming from a newly created account). It was a sincere attempt at answering your downvoting concerns though.

<comment><USER15> I know this. More than a silly post it was pointing out the similarity between the thanks Obama meme and the Pauli effect. Yet something like this made it to the front page.

<comment><USER16> I think if you actually made clear that you were mentioning the meme in order to make a comparison, as opposed to "merely" invoking it, the comment would have been received better.

<comment><USER15> Very likely.

Also, groupthink. [https://en.m.wikipedia.org/wiki/Groupthink](https://en.m.wikipedia.org/wiki/Groupthink)</comment></comment></comment></comment></comment></comment>


Receive your Facebook photos through your letterbox every month - <AUTHOR> http://www.memoreez.co.uk <comment><USER2> Oooooo this looks like a good idea</comment>


My Ultimate To-Do List Hack  - <AUTHOR> http://andrewbryk.tumblr.com/post/48697409366/my-ultimate-to-do-list-hack#.UXarAyspYhM

<comment><USER2> Despite its exorbitantly hyperbolical title, the article contains an important advice:

Having a DONE list in addition to your TODO list is a good way to stay motivated.

I'm using Emacs / Orgmode for my TODO list, and instead of removing accomplished TODO items from the list, I mark them as DONE (shift+rightarrow). That way, it is a lot more fun (and also more informative) to look at my TODO list.</comment>


Ask HN: Best way to be able to touch type - <AUTHOR>

I am a programmer and feel very bad that I cannot touch type. The reason probably is that I never picked it up as a kid and in my initial days of programming I got by with looking at the keyboard and typing.
I can type decently fast while looking at the keyboard - but the bad part is that I only use my index fingers and the thumb. I want to move away from this and be able to touch type using all my fingers.
Any suggestions from someone who has faced a similar problem. <comment><USER2> Look at the screen and don't look down. It'll feel awkward at first, but it's supervised learning: you'll make mistakes at first, which your eyes will detect, and the keep trying keys until you get it right. Touch typing requires proprioception (knowing where your body is without looking), and vision completely overwhelms that if you're looking at your hands.

Give it a week, and don't get discouraged if you don't seem to make any progress inside typing sessions: most improvement happens in the off time after you've practiced for a while (sleep is especially good here).

</comment><comment><USER3> I learned it by switching to Dvorak. I put little stickers on my keyboard indicating the letters. So I started typing with hunt-and-peck. After some time, some stickers came loose. The keys I used the most, lost their adhesion the first. These were also the characters I remembered the first. The reminders let go in perfect order and never too soon. The rest was just a matter of putting your fingers in the right spot. Everything else came naturally.

Probably not the answer you're looking for though, but I like telling the story :)

</comment><comment><USER4> Practice, practice and more practice...

There are plenty of apps that will teach you the techniques and give specific drills for improving your speed and preciseness.

</comment><comment><USER5> get a cardboard box or something, and use it to cover up your keyboard. make sure to cut a hole or area for your hands to go in. put an image of a keyboard next to your monitor, so that if you need to look at something, you look at that instead of the keyboard itself.

type away.

</comment><comment><USER6> Spray paint your keyboard black.

</comment><comment><AUTHOR> thanks guys. I am going to use these tips :-)</comment>


Performance is a Feature - <AUTHOR> http://blog.codinghorror.com/performance-is-a-feature/ <comment><AUTHOR> Very enlightening post about performance. I now feel like I have a framework to tackle this.

</comment><comment><USER2> From 2011...

<comment><AUTHOR> Still seems useful to me.</comment></comment>


NASA's Dawn Mission to Asteroid Belt Comes to End - <AUTHOR> https://www.jpl.nasa.gov/news/news.php?feature=7275 <comment><AUTHOR> For more on what the Dawn probe might have done as its propellant ran out, see this from the Planetary Society [1]

[1] [http://www.planetary.org/blogs/guest-blogs/marc- rayman/dawn-...](http://www.planetary.org/blogs/guest-blogs/marc-rayman/dawn- journal-denouement.html)</comment>


After 3 Years of Work, Chrome Killed My Extension and Won't Tell Me Why - <AUTHOR> https://medium.com/@miko_89964/after-3-years-of-work-chrome-killed-my-extension-and-wont-tell-me-why-83a3f8d65cbc <comment><USER2> {Google, Apple, Steam, etc} all do this with their walled gardens. It's sad, but it's not unique.

Perhaps if there were way to make the rules more programmatic and less ambiguous, these might be easier to resolve (like writing code to fulfill unit tests). But I suppose it probably still gets evaluated by humans on a subjective judgement, even if there is an objective rubric for most of the requirements.

<comment><USER3> Initially I was a fan of the curation approach, particularly for Apple and iOS since it was a new platform. Sadly, it's obvious that none of them can keep up with all the reasonable edge cases. Curation just doesn't scale and I don't see AI/ML or anything else closing the gap any time soon.

</comment></comment><comment><USER4> This made me even more depressive.

I stopped developing browser extensions when Mozilla killed their only competitive advantage over Google and allowed Webextensions only.

</comment><comment><USER5> This happened to me as well, and my extension was quite popular and very lucrative.

What I ended up doing was uploading it to the store under a new category and hoped it would be reevaluated under different people or constraints and it worked. Has been up and running for over a year.

</comment><comment><USER6> And this is why I stopped developing for Google's platforms. Extensions? Android? Forget it. Been abused by their rancid practices too many times, and heard too many similar horror stories. Not worth it.

</comment><comment><USER7> Surprised this got no comment traction. This is outrageous. Why on earth can't Google just identify the exact infraction? Absolutely ridiculous.

</comment><comment><USER8> What rejection message ae ou receiving? Maybe I can help Amy</comment>