Turning thoughts into software is what software engineers do every day. At every point along the technology trajectory technologists have created more and more powerful abstractions. When transistors where first created: print "Hello World" would have seemed a magical melding of the minds of machine and man, whereas today we can create customized eCommerce social networks with a few keystrokes.
However, as powerful as the tools get, you still have to tell the machine exactly what you want it to do. Depending on the tool, sometimes that is easy, sometimes that is hard. I feel like there should be a fundamental law of "ability to easily express" vs "flexibility of expression." I'm not sure how much machine learning can serve as our savior in this regard, even if we can eliminate "make an Amazon clone" posts on cheap-outsourced-developer.com by just using ML to classify it and spit out the boiler plate.
In order for something to be profitable it has to be customized, and when this happens the abstractions inevitably seem to break down. Based on this I think turning thoughts into software will happen around the same time thinking becomes mass-produced. How can you create, "eBay, but for car buying, with a twitter messaging component built for the Brazilian market" without first beating the Turing test as a sub-problem?
Any thoughts on when the pagination goes live? I can't find any information on it online. Memcache would be a good choice, but I am wondering, if I have a few secondary indexes with over a million indexes each, wouldn't continually recreating this cache irreparably bog down the cluster?
I have been using Riak's secondary indexes for my latest project and have generally found them a joy to use. However, I do have to have to question a bit the way they are architected.
Assuming you are using Riak's default configuration each range query hits 1/3 of the cluster, which could get pretty hairy on large clusters that have lots of requests. Also, there is no pagination, so if an index has a million objects you'll have to be prepared to wait even if you only want the first part of the query.
You could solve this by putting a sort value in the key and using a range query, but this wouldn't work if you want the most recent items keyed with time, because the items could be unevenly spaced back in time. Also, Riak, like many databases based on Dynamo, thrives on fat data which one would think would favor lists. LevelDB is also supposedly slower than Bitcask, the default backend, but I'm not sure if this is still true.
I've been trying to think of ways around these problems. A simple thought I had was to simply cache the response as pages in Riak. Although this introduces new problems like how to know how often to reset the cache, too often and I may as well not have this cache, too infrequently and users get stale data. I would also have to handle this using worker threads because I wouldn't want the odd 100th user to get a big latency hit. The database would also either have to be continually polled, wasting CPU, or potentially not have the data cached when needed.
Another solution I've been considering is to write a secondary index layer on top of Riak using a skiplist or btree to know where to add and remove data when it gets to be very large. This seems like a cool idea, but might be tricky to implement and do conflict resolutions on.
My last idea was the most ambitious, which was to implement a separate distributed database specifically for secondary indexes and range queries which would not be bound by Dynamo. The idea here is to have each node in charge of a segment of the key space (like Big Table) and then have it split and coalesce not only based on size, but also on frequency of reads and writes to handle the bottleneck problem.
I initially was going to have this paired with the Dynamo database (https://github.com/dbunker/Dynago) I was experimenting with using Go and LevelDB, but there is no reason it couldn't work with any Key-Value eventually-consistent hyper-reliable database to provide light-weight secondary indexes. Having it constantly check the core key-value database would mean it wouldn't have to be super reliable in its own right and so could be kept relatively simple.
But again the simplest solution may ultimately be the way to go, I'm not sure, all these seem to have pretty big trade offs.
Assuming you are using a distributed architecture, there is no way to verify a user without at least one database lookup because the request could be coming into any API server. So in most cases we're not avoiding cookies and sessions just for the sake of it.
Assuming you are using only "reads HN" as your a priori, all of us with below average pay should expect higher salaries. If you were to argue that those who read HN and also have high salaries are the only ones reporting however, then it would be fair to rap our knuckles with the stats 101 textbook.
People always say that remote working will be the way of the future, but humans remain extremely social animals. So much of what we do is guided by genetics and it seems to be human nature that if you don't see someone's face on a regular basis it is very difficult to create an intimate or trusting relationship.
This seems to be one of the main pain points when it comes to outsourcing work abroad, people seem to work best and collaborate the most when they interact frequently in person. In Pixar Story, I recall Jobs saying he designed the headquarters specifically for unplanned collaboration. As much as the world changes, people remain the same.
When I first read 'GitHub-maintained client libraries' I initially thought they meant built in libraries or templated stub functions, sort of like what they offer for .gitignore for various programming environments and languages. I was a little disappointed when I saw it was just for the Github API, although I expect this to still be useful.
I feel like this is something they could offer in the future though as many IDEs automatically build your environment when a new project is initialized. Assuming you use github as your IDE (i.e. not really using any IDE) project initialization might make sense.
I expect people would be reluctant to use a client not sanctioned by bitcoin.org officially, although I'm not sure how difficult that is. It may be as simple as sending an email to get them to add it to the list.
I would think that any new bitcoin wallet could be introducing a substantial security risk before it has been extensively field tested. If someone where to sneak some code in, or even just screw up a security protocol, all the stored bitcoins would be at risk.
It's a shame he doesn't mention his friend's name at the end of the piece, but if anyone has the right to refer to themselves as "beloved" I'd say it's David Rakoff.
> I see bitcoins as the storage of value, but not method of payment.
If this comes true, the bitcoin system is in trouble. Block reward is down to 25 bitcoins a block. It will half one more time then no more money for mining, it'll all be through transaction fees.
If people are just storing bitcoins and not using them, there wont be enough transaction fees and lots of miners will drop out, making the system more vulnerable to takeover by government or malicious miners.
I feel like what they are describing is more defragmentation than garbage collection. The article uses garbage collection to mean taking sparsely filled blocks and consolidating them into a single block to free the sparsely filled ones. Garbage collection in the OO context is where you free memory the program can no longer interact with. Perhaps it means different things in different contexts?
What you have described is more or less Diffie-Hellman. Unfortunately this alone wont guarantee your package's safe passage. If it did Verisign, would be out of a job.
The flaw is, you can basically just have the same scenario but replace Alice with the post office:
Bob puts the item in a box with a lock and sends to Alice. Post office intercepts the box, places their lock on it and sends it back to Bob. Bob removes his lock and sends the box back to Alice. Now the post office removes their lock and obtains the package contents.
The only way around this is to have some truly trusted third party. Even in RSA, if you aren't absolutely certain of the other user's public key, it won't work, which is why web-of-trust and other techniques are used.
Although much changes with technology, much remains the same. People have had the technological ability to communicate solely through telephone/computer for many years which easily beats face to face communication in terms of efficiency in a geographically diverse group, but people are still shelling out money for plane tickets. There is something to be said for the ability to chat to someone about a ball game without speaking and hearing through a machine.
Although I'd say human to human and human to computer communication are very different, I'd agree with you that some languages are objectively better. There are ancient tribes that don't have words for numbers above two. Esperanto seems to be one of the easier languages to learn, at least for those already fluent in european languages. But when it comes to adoption, culture and ubiquity seem to be the most important factors.
What would be interesting is if there were real online bitcoin banks that leant or invested the bitcoins to both make a profit themselves and offer their customers some interest on their savings.
with result (https://github.com/dbunker/SABR/blob/master/test/Real/Multip...). Fifth position being E.
A bit on the verbose side, but might be preferable to some since it explicitly enumerates all the possibilities for each rule.