wildwood
Given that DynamoDB can reliably write in the 4-5ms range, a kinesis queue may not be necessary. Unless the point of the Kinesis layer is to keep the cost of DynamoDB provisioning low?
(http://www.washington.edu/alumni/columns/june07/content/view...)
It was awful, actually several "wings" in one building. It was possible to get locked out of the building on a walkway between two wings, with no other exits. You would sometimes have to go through one person's office to get to another office.
The theory when I was a student there was that university construction in the late 60s was obsessed with dealing with civil unrest - psych buildings with riot-proof windows, admin buildings with confusing layouts, an open square covered in bricks that get slippery when hosed down, etc.
Also, six foot HDMI cables. Everybody needs those.
I hope that catches on.
Edit: can't believe I got the name wrong. Fixed.
If your website is already tracking ad performance on a per-ad basis (i.e., tracking all the clicks on that ad, and keeping what you pay per click below what you're getting per click), then optimizing for only the paid search traffic that's incremental, and not cannibalistic, is pretty straight-forward, conceptually.
For a given ad's keyword, instead of optimizing only for the results you get from PPC traffic, you treat your PPC bid as an input that affects sales across PPC and SEO traffic for that keyword, and optimize accordingly.
There are a few extra steps and decisions that need to be made before full implementation, but this is the basic idea. It's actually not too bad to account for.
The right side has 4 out of 6 of the vowels and 3 out of 4 of the other sonorants, which could easily be argued to be the more sonorous or pleasing sounds in a word. 7 out of the 11 right-hand letters fall into one of those categories.
By contrast, the left side is only 3/15 sonorants. Further, the left side has all the sibilants and a strong majority of the stops.
Pointing out that right-side letters correlate with agreeability is an interesting finding. Claiming that which side of the keyboard the letters are on is the _causal_ factor for agreeability strikes me as lazy.
I read through a breakdown in one of the Basic Income books, of what it would cost just to get a $10,000/year basic income. Here's just some of the changes that would be needed:
* cut military spending by a third; * get rid of ethanol subsidies; * get rid of mortgage interest tax breaks; * get rid of "married filing jointly/separately" filing status, make everyone file just for themselves
And that's just the ones that jumped out at me. Virtually all tax loopholes would have to be gotten rid of, and more. All for just the $10K/year basic income level.
So, just as a question of the political cost to implement, Basic Income seems like a laughable non-starter.
There've always been lots of people who would say that the next wave of immigrants is unneeded, and unwanted. No matter how successful they turned out to be.
Giving this amount of money to every person in Switzerland would total almost half of the country's GDP.
Even if you exclude children and get the total amount down around 30% of GDP, you're still right around the total amount of money that the Swiss government takes in in a year.
So to get this basic income with no new taxes, the Swiss government would have to abandon all its other obligations. Or, put another way, to fund this and still function at the same level, the Swiss government would have to double its tax income.
And you're probably only paying 10% in state tax if you live in California. Most other states' income tax are around 5 or 6 percent, and some are at zero.
We just want everyone to have a good time.
DoubleDown is an on-line casual casino, currently on desktop, Facebook, and numerous mobile devices. We are looking for HTML5 mobile devs, Flash/ActionScript front-end devs, and Java/Scala server devs.
This is a fun, laid-back work environment, and we're looking (mainly) for experienced developers who pride themselves on shipping quality code.
Profitable company. ~175 people. Perks like it's still 1998. You can have a positive and appreciated impact on the company pretty much as soon as you start.
Check us out at http://doubledowninteractive.com/careers - or feel free to send me questions (my personal email's in my profile).
Thanks!
Sorry, but this is just wrong. Anyone who first learned English as an adult can improve their accent from strong to mild over time, with effort, if they choose to. If they live in an immersive English-speaking environment, this will often happen without conscious effort, as long as they value communication.
Anyone whose strongly-accented English doesn't improve after a few years in-country doesn't value communicating well. (Either that, or they just spend all their time in a native-language enclave.) And someone who doesn't value communicating well should not be in the role of CEO.
We just want everyone to have a good time.
DoubleDown is an on-line casual casino, currently on desktop, Facebook, and numerous mobile devices. We are looking for HTML5 mobile devs, Flash/ActionScript front-end devs, and Java/Scala server devs.
This is a fun, laid-back work environment, and we're looking (mainly) for experienced developers who pride themselves on shipping quality code.
Profitable company. ~150 people. Perks like it's still 1998. You can have a positive and appreciated impact on the company pretty much as soon as you start.
Check us out at http://doubledowninteractive.com/careers - or feel free to send me questions (my personal email's in my profile).
Thanks!
One way to keep the contractors separate is to only have them employed for a limited time, usually in stints of less than a year.
Of course, this isn't a limit on length of employment, just a limit on the length of someone's employment as a contractor. Plenty of companies use more of a "contract to hire" approach, and make a decision whether or not to convert employees to full time at the end of the contract.
http://en.wikipedia.org/wiki/Permatemp - scroll down to the Vizcaino v. Microsoft section.
* make a list of technologies/skills that he would like to learn;
* make a list of technologies/skills needed in his job, and in his upcoming project;
* look for any conceivable overlap in those two lists, and spend his time doing that - justify it as "prepping for the project".
Strictly speaking, though, refactoring should never require new tests, unless you're specifically refactoring to increase testability. New tests should be related to specific bugs or feature requests.
This chart says nothing about whether mobile is eating into the absolute traffic that desktops are getting. More likely mobile traffic is increasing a lot, and desktop is holding steady.
Amazon is retail. They make 12% margins in a good year. Which is one big reason why Amazon will put significant effort into a new market with a 25% margin, that the others would turn up their noses at.
This seems much closer to a code than an actual language.
hg diff -b <filename>
hg commit -m "comments" !$
2) Test enough during development to support later regression tests, and to make sure that the design is testable. This can usually be achieved with less than 20% coverage. But if you write production code that's so screwy it can't be regression tested, then you've got big problems.
3) Test any parts that scare you or confuse you or make you nervous. Use "test until you're more bored than scared" here.
It's interesting that double negation is standard in French, but not used in Germanic languages. In this case, it seems like the Germanic influences on English won.
[1] http://articles.chicagotribune.com/2006-11-08/features/06110...
This is a good example of how deceptive a percentage-change-only chart can be, without the absolute value of the portfolio also figuring in. If the system has a max drawdown of 98%, then getting 200% returns after hitting that low isn't going to do much good.