From the front page testimonial:
> in less than 5 minutes the project was fully spec'd and underway.
Honest question: why would I need a top '1% developer' for a project that can be fully spec'd in less than 5 minutes?
751 karma · joined February 27, 2010
> in less than 5 minutes the project was fully spec'd and underway.
Honest question: why would I need a top '1% developer' for a project that can be fully spec'd in less than 5 minutes?
Now, if Uber were offering a free 'lol cats apps' on the app store that surreptitiously ran this protocol in the background of unsuspecting users I think it would be a different case, but running technology that supports the goal of the main app doesn't feel out of bounds to me.
The people pikcing up those used phones are likely getting rid of a slightly older one at a higher frequency now and that will still generate more e-waste.
I just clicked through and spent a few minutes clicking around ... I couldn't find the rules anywhere without clicking through to Wikipedia.
The same thing could have been said about streaming music services and yet many artists seem not too happy about the per play $ they get from Spotify & ilk (though they are probably bound to say that regardless to some extent)
I am similar, writing the back end was easier ... front end not so much. I hated having JS bugs due to stupid typos and less than 100% code coverage in tests.
Switched to Typescript for the front end and things became much better. Doesn't have to be 'all or nothing' either, I still have some JS glue for interacting with some libraries and more dynamic bits, but generally everything is Typescript and feels much more solid.
FWIW the stack also heavily includes KnockoutJS, DataTables, Backbone's router & a smattering of JQuery plugins for this and that.
It is certainly good value, and a fraction of the price of the one I had for work a few years ago (different brand totally). It can feel a little flimsy/wobbly when raised, but certainly not dangerously so.
For the benefit it can bring someone it is a total no-brainer decision, and I'd do it again without a second's hesitation if necessary.
We are ~10Km from the nearest village that likely has decent bandwidth, though no idea on the backhaul available from there.
Still 10K @ $30 (AUD/CAD)\m would be $300K+ to put it along existing hydro infrastructure. Wonder what the likelihood of getting 100 households to put up say $3-5K in installation costs would be? That would represent a decent fraction of those reachable along that stretch, and those nearer in may already have DSL.
But not in a position to move to Montana!
Total Greek debt is €323 B [1] and there are 503 million inhabitants in the EU, making 'pay-off the debt' more like €642 per inhabitant
For context total EU sovereign debt [2] is €24,415 per inhabitant
[1] http://www.bbc.com/news/world-europe-33325886 [2] http://www.eudebtclock.org/
Seems kinda backward to me ... we'll teach you how to do this well, and if it works we'll refund you?
I get you aren't the only variable at play, but saying you'll refund if they fail the interview would be much more compelling! (But economically unfeasible I'd guess)
* how good are you at self-motivating * what chance is there of being mentored at the start up? * will the CEO provide a good reference later one: a human reference likely beats pointing out the open source contributions in many jobs in the future
If you are going to work for free anyway on open source then make sure you have the dedication to actually do it.
Being more directly accountable to someone may be a benefit.
Good luck ... it's a tough call!
Whilst storing it for your own use later makes sense in theory, it doesn't work with the current economics
But I wouldn't view letting on about other interviews a major problem -- knowing there is some competition both ways isn't a bad thing. I want great candidates to work for us, but I also know great candidates have choices.
In this case though FoundationDB's KV store was order preserving. The API supported (& efficiently implemented) ranged reads, not just individual get's.
Implementing layered architectures always looks good 'on paper' but the details often throw up performance issues that are hard to deal with without punching some holes in the abstractions.
In this case it seems that relatively few companies had a need for a massively scalable ordered KV store, and the whole SQL layer was an attempt to bridge the product to a wider audience. It would be fascinating to hear more of the story but I suspect that will never escape now.
The system could definitely do with an overhaul though the wording in some places was very confusing.
Breaking into gmail gives access to many password recovery mechanisms.
But I agree for low priority sites: my password across many forum sites is the same and very low entropy. I really don't care to think more about it!
"Thank you for your support of FoundationDB over the last five years. We’re grateful to have shared our vision of building the best database software and we strongly value your participation in this community. We have made the decision to evolve our company mission and, as of today, we will no longer offer downloads. If you have any technical questions, please email info@foundationdb.com."
Are you sure the next crash that knocks N% off the market won't come after the market has risen a further N+x% while your money is on the sidelines?
Are you sure you can time the bottom of the crash well enough to know when to jump back in?
If the answers to those questions are 'yes' then great, otherwise a steady investment strategy for the long haul can just ignore the short term fluctations.
I suspect it will be a while longer before battery technology is as useful above the 49th parallel.
For example, you generating a 1TB key before leaving on a trip you could imagine a VPN set up that encrypted 1TB of traffic in a way that was theoretically unbreakable by someone sniffing the traffic only.
"Sensors flood the device with terabytes of data every second" ... somehow I doubt the aggregate bandwidth of the device is > 1TB\s
Makes it harder to know how much of the rest of the 'explanations' are accurate.
Either the mice self-regulated this, and the shorter window mice learned to eat more when it was available or there was a fixed amount of food available then the window seems less relevant unless they tracked when the food was gone for the day.
Other benefits include not having to remember the 'interesting' rules around 'this' in pure JS (though that occassionally slips through in libraries that use it). Having saner (to my eyes) syntax for modules and encapsulation. And having intellisense support in Visual Studio reduces the effort of writing the code.
For a mobile solution something like https://cardflight.com/ would be an option which works with a number of backends