Um, one small difference, you have to be a resident of Alaska for at least a year, intend to remain a permanent resident and not be absent more than 180 days without a valid reason. [1]
[1]: http://pfd.alaska.gov/Eligibility/EligibilityRequirements
1,081 karma · joined June 18, 2012
[1]: http://pfd.alaska.gov/Eligibility/EligibilityRequirements
I thought it played normally, and it does for a while, but it always eventually seems to randomly revert your high tiles (I verified that I had at least 1024 by checking the debugger).
[edit:] Ah, I found the code. It's possible to win but you have to survive the small chance that it will perform a random merge and destroy your tile:
// 0.005% percent chance that we will merge a cell anyway
if (next && Math.random() > 0.995) {
next.value = tile.value;
}The website looks great, too, however it has one big problem for me: I felt frustrated to have to sit down and listen to a 4 min. video to even find out what the product was.
In the first 10-15 seconds I was on your site, I actually couldn't figure out exactly what it was (there are so many variations on standing desks these days).
I scrolled way down and I can see there are tons of benefits, but no description of the desk. I had to eventually click play on the video[1], and then when it didn't visually get to the point immediately either, I had to put on my headphones and go and find my music player to pause.
I think it would be great if it had at least one of A) a short intro video that shows the whole desk and automation within 1-2 seconds or B) just some headlines describing it ("An electric adjustable standing desk for under $400") and pictures of the product.
P.S. There is a weird, loud audio glitch/background crowd noise in the video at 2:01. :)
[1]: To be fair, the Hacker News title does say [video]. But still, it's the home page, it should get immediately to the point.
If new users are not taught by existing users what the existing users like and think should be upvoted, then what is upvoted will naturally shift over time.
Long-time members may consider that a deterioration in "quality". Quality is of course subjective, but I suspect in this case it actually means more like "not as close in alignment to the way things used to be, which I liked".
I'm fairly new here, and as a newbie, I haven't ever been taught what the existing community thinks I should upvote, whether in submissions or comments. Beyond the guidelines, which state:
> Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity.[1]
Why do I /need/ to upvote the post?
- Yes, initial payload size matters. But where's the true comparison about what each app is loading? How are the features and the UX? Would a power user be satisfied with Fastmail (e.g. search, filters, etc.)? (It looks nice, but none of this was discussed at all).
- The disparate email count comparison is excused way too quickly. Have you done a similar test with a brand new Gmail account?
- Anecdata. I've never had the page load problems as bad as described. 2-3 seconds, and I reload once every week or less. "Sluggish" is a weasel word -- what is sluggish? Searches return in ~1 second for me (~7000 emails, I'm not a saver.)
- You can turn off chat.
- Switching is never as simple as described, and forwarding is a fairly messy solution (and will only get messy as the author creates new login accounts and further forks his usage).
- Ugh, the "Google suggest" argument. For the record, the only suggestion for Fastmail is "Why is Fastmail down"
I clicked on "Goodbye Gmail" hoping for some substance or an interesting story but instead got feelings, anecdata and glossing over the problems of a real migration or search for a qualified alternative.
The best part of this article was seeing what they did wrong, how they listened to the feedback and made changes.
Maybe a bit wordy, but I would have gone with something like, "What we learned we were doing wrong when our Show HN landed on the front page."
I think you've made positive changes, but don't forget that your organic audience is much different than the burst traffic from a link aggregator like Hacker News.
Not that your conclusions are necessarily wrong, but it's easy to make false correlations when more than one variable changes.
I'm not going to claim it was first try. Probably my tenth. However, I got much better at avoiding the key mistakes:
- Always keep your highest number in a corner
- Use the rest of that edge as a "staging area" for the components that can next double the highest tile. Work the other tiles toward the opposite corner on that side and then double them upward into the highest corner.
- When you double the highest corner, you'll expose the "staging area" side. During this time, quickly work number back to fill that side so you avoid being forced to move the highest number out.
- NEVER let yourself fill a 3x4 grid. This will force you to move the highest column away from the edge and will probably end the game in a handful of turns.
It's the lower-case 'i' that does it for me.[3]
Fewer serifs in general allow me to read more quickly, I feel. 'i' has 1 to Consolas' 3, while lower case 'l' (L) has 2 to Consolas' 3.
One negative is that I much prefer Consolas' 0-with-slant to Source Code Pro's 0-with-dot.
By the way, the first link below is from a very cool resource I just found with votes and comparisons of many of the most popular choices: http://www.slant.co/topics/67/~what-are-the-best-programming... (It seems the web has become more informative on this topic than the last time I surveyed all the font options.)
Finally, this is what the designer of Source Code Pro, Paul D. Hunt, had to say about the two[2]:
> Consolas is narrower than most monospaced fonts at 55% of the Em square, where I stuck with 60% for Source Code. If the narrowness is a top selling point for you, then Consolas is definitely king.
[1]: http://www.slant.co/topics/67/viewpoints/5/~what-are-the-bes...
[2]: http://blogs.adobe.com/typblography/2012/09/source-code-pro....
[3]: http://blogs.adobe.com/typblography/files/2012/09/Confusable...
- Verdana (the font of this very comment: "I")
- Tahoma
- Officina Sans
- Bell Gothic
- Apple Monaco [3]
- Adobe Source Code Pro [4]
[1]: http://www.typophile.com/node/45715
[2]: http://typophile.com/node/50393
[3]: http://myfonts.us/td-LJbtZv
[4]: http://blogs.adobe.com/typblography/2012/09/source-code-pro....
This made a drastic difference in how early we were able to assess a design direction. Previously we would have only made 30% progress but that 30% would have been polished. Making it an "end-to-end" demo allowed us to get that kind of rough feedback on the whole feature. And if we needed to, tuning our direction at that point wasn't that painful.
The result was that we no longer had to throw away work that was polished but didn't deliver the goals we wanted -- or worse, continue to force the path because of sunk cost bias, ignoring the feelings that something wasn't right.
It's sort of close, but we're still talking about a swing of >30% there -- $5 billion dollars in WhatsApp's case.
There are many things missing from "cost per user" but I think the first thing to ask is "user doing what"?
Is that loose of a search not actually desirable in "find in page" instances?
In other words, are there many words where 'e' matching 'é' would actually generate a false positive? This is the only case I could see that would be problematic.
And even then "find in page" is usually used as quick navigation to the minimum matching search (high recall) and not about excluding all possible mismatches (high precision).
My earliest memory of a hard drive capacity -- about 21 years ago -- is 130 MB (although that most certainly wasn't the upper limit). So you could have told me "This card is 1/2000th the size and has 1000 times the capacity."
2,000,000 times the data density! That's doubled almost 21 times!
I feel like Reinhardt is complaining about the term "minimum VIABLE product" when most people emphasize it "MINIMUM viable product".
In that emphasis, the two mean almost the same thing. However, I see another difference:
- "viable" makes you think about what users want. Sure, you can get carried away, but that's why "minimum is there to reign you in.
- "testable" could mean anything -- you can test anything, in any direction -- it doesn't make you think about what users want.
This is problematic.
Viable is a good word. It points you in the right direction. "Testable" helps to limit you, but "Minimum" is already there to do it.
I say stick with MVP, but if you, or team, start getting carried away, just remember - Minimum, minimum, minimum!
This doesn't seem very strange to me at all, certainly not Kafkaesque -- for large companies that are very selective, always in need of new candidates, and do a huge variety of things, I imagine most would want to have the chance at anyone who qualifies.
Anything else seems less scalable and less efficient for both recruiters and candidates. The recruiters or candidates need to do all the matching up front, instead of doing it only once the candidates and company are found to be right for each other. It saves everyone's time to go through the effort to match up for a specific team -- as long as there are plenty of options to avoid disappointment at that stage.
If you master everything in Yegge's article, but yet fail to show you know how to learn, lead, show ownership and humility, you'll still probably not get the job. And I'm sure this fact baffles a lot of technical experts out there who don't pass their Google interview.
Of course Yegge's advice is indispensable on the technical side. But Lazlo's advice is intentionally more broad than that.
So even though at the two end points we see the addition of only one line in a block (which is being touted as the justification for this accusation), the intermediate steps could have included the addition and subtraction of other lines in that block.
(A plausible example might be the addition of another hash updating if statement + goto fail, then the removal of only the if statement.)
You're assuming:
A) Their growth stays the same as it is now.
B) Users on year-long free trials will convert to paying users.
These are crazy assumptions absent years worth of data.
Not saying WhatsApp doesn't have something good going, but in what world have either of the above things ever been predictable in this short of time?
Especially to validate the claim "revenue should exponentially rise"...?
The only real way to win on price is to find employees who don't know any better, and then, well, you have employees who didn't know any better. Did you really win?
I can't imagine Scott Adams being OK with this.
[1]: http://imgur.com/kBHJ0eq (thanks to another commenter for the image)
But that isn't the case here. When something like jQuery comes along, hiding so many gory details, and has been tested to death both in development and in production use all over the world, we are all better off because we remove so much failure surface area from our code.
The premise of the examples list seems a bit disingenuous.
Very few of these things take into account the full convenience of jQuery. It's much more than saving a couple lines of code or knowing the native way to accomplish the most basic version of a task. jQuery's real benefit is preserving simplicity as your needs grow more complex.
Right off the bat I feel like the getJSON[1] example is a bit simplistic. Almost anyone using ajax needs to serialize data, handle errors, prevent caching, etc. jQuery has thought about all this[2].
Don't get me wrong -- most of my work has been without jQuery, but that means I know exactly how much work it is.
The Good:
The format is a nice way to show people (who really don't know otherwise) the native JS plumbing.
"The number of people who don't know that jQuery != Javascript is too damn high". So to help combat that, I really appreciate the idea behind this site.
It's great to show side-by-side how jQuery isn't "magic", since many people seem to learn jQuery these days without even knowing the first thing about Javascript, but I just think it should be presented with a slightly different premise.
[1]: http://youmightnotneedjquery.com/#json -- side note, why did they set the handler after the `send`? It seems like that could cause problems if the result was returnable quickly, such as from cache, though I haven't tested it.
[2]: http://api.jquery.com/jQuery.ajax/#jQuery-ajax-settings
- You have a row of credit card icons. By default they are in full color.
- These icons react like buttons (hover shows clickability) and act like radio buttons if clicked -- all the others gray out.
- When a user starts typing a credit card number, it selects the appropriate icon if not already selected (graying out the others).
Because they aren't radio buttons (or a dropdown), it doesn't force people through the step, but because they can act like radio buttons (providing only visual feedback), they don't confuse anybody who thought they were supposed to be there.
The forms I've used that feel the most natural do something like this.
Credit card numbers are not secure. Therefore, they should not ever be accepted as authentication. Especially only 6 digits of it! This is by far the most shocking part of this story. As if I needed another reason to despise GoDaddy.
[Edited to add] I would sure love to see a scarlet letter list of companies which allow such practices, so I can never use them.
"Protection of intellectual property is what America is built on?" Hyperbole much?
"Smart people invent things. Then they get to protect [...] what they invents." Oversimplification much?
Not exactly a home-run defense of patents by Mr. Altucher.
[1]: As admitted by the article, there was no "stealing" here anyway.
http://google.com/url?q=http://online.wsj.com/news/articles/...