Innate of course doesn't have a precedent in Dominion, since you don't keep your deck around between games. Ethereal could - there's no technical reason you couldn't print a Dominion card with text like, "During clean up, trash this card if you would discard it from your hand". I don't think there are any such cards, and I suspect they'd be generally worse in Dominion than Ethereal is in StS. Actually, having a deck of cards using in junking attacks with that text separate from ruins and curses might be interesting - curses that trash themselves, so you could hand them out a lot more aggressively without destabilizing the entire game.

Dominion's traveler cards were Donald X's attempt to make cards that change during the game, though of course Slay the Spire can push that idea much further.

Artifacts and States are a little bit like the Watcher's stances, but less deck-defining. You generally don't build a deck around having a particular artifact or state, but you can use them to get a little extra juice.

I agree, limiting your plays each turn (either with mana or dominion's limited actions) does a lot to change the texture of a game. The Ascension family of deckbuilders where you can just slam your whole hand down every turn tend to leave me underwhelmed.

I don't mean to rag on StS for being unoriginal, quite the opposite, it's great.

I actually wrote the easy 50% of email back compatibility for a chat app once - it wasn't as hairy as I expected it was going to be. Everyone has a unique username (or at least username+org pair) so use that to generate an email address for them. Similarly, generate an email address for every group/room. When you receive an email for one of those addresses, use the from headers to find/create a new pseudo-user and dump the body of the email in as a chat message. When someone writes in chat that has a pseudo-user as one of the people watching that chat, send them an email with that text and throw in a few previous messages as a fake reply chain for context.

There are a lot of hairy details about thread management and making sure you don't send pseudo-users too many emails and dealing with all the messed up headers that different platforms send you and trying to only extract the actual message and not the signature/replies from an email and attachments so on that I only worked on a little before the whole thing was shuttered. But it was really cool. Email users tended not to notice that anything was different (they're used to email looking weird from various services) and chat users got to stay in chat that was a little awkward instead of having to switch to a different tool entirely to talk to people outside the organisation. (And, if all the different chat services started doing it, you'd get really janky chat federation for free!) And it lets you get a lot of stuff that gets made as Slack integrations for free, too. Why bother setting up a bot to post to chat when a Jenkins build fails when you can just give Jenkins your dev chat's email address and let it send emails?

2) What about "can"? It's not a drop-in replacement for "should", but it has a lot of what you're going for. "Non-programming skills every programmer _can_ have" is about aspiration not judgement, possibilities not failures.

  LITERATURE PRIZE: The US Government General Accountability Office, for
  issuing a report about reports about reports that recommends the preparation
  of a report about the report about reports about reports.

Comments URL: https://news.ycombinator.com/item?id=4576132

Points: 1

# Comments: 0

So no, it's not of much value in that it doesn't tell us anything that we don't already know. But it can be of value to frame our understanding or discussion of the problem.

  Knock, knock
  Who's there?
  Interrupting coefficient of friction
  Interrupting coeff -- MUUUUUUU

The key line for me is "... it's hard to use metaphors in writing. It's simply more abstract." I have this working theory that abstraction in programming language is more or less equivalent to metaphor in person language. The core idea behind metaphors is to create a convenient lie that helps expose some aspect of what you're talking about by comparing it to some other domain. Consider my last paragraph. English has no type system. Telling you that it's duck typed is a lie, in the sense that it isn't true. But as a metaphor, it's convenient because lets me unify two ideas (programming languages and regular languages) under one aspect (things that have degrees of rigor). Similarly, having an abstraction over local files and network files lets me take two things that are accessed very differently, and let me pretend they're the same. It's a lie, but it works.

I'm not really sure how the abstraction==metaphor relation holds under closer scrutiny. I'm also not certain that it's particularly useful in terms of helping me make better programs, but I like it.

I don't think the comparison is entirely without merit. From what I can tell, a lot of the scorn directed at hipsters (or at least the "hipster" archetype/strawperson) stems from fact (or perception) that they value cultural artifacts based on the social status that they can leverage those artifacts for, rather than for any intrinsic value they might have. Compare someone who tells their friends about a band because they like the lyrics of that one song they listened to all the time in high school, vs someone who tells their friends about the same band because they want to be the first to do so, gaining some reputation in the process. (Obviously there are more subtle gradients of behaviors and motivations here, but lets stick to broad strokes.)

Apple's branding and advertising tends to exhibit a similar focus on how their products will improve your status, rather than on the capabilities of the actual hard/software. Consider the 1984 Mac ad, or the iPod silhouette ads. They weren't telling you to buy an iPod because it could hold more songs, they were telling you that if you had an iPod, you could be one of the happy beautiful people dancing on a soundstage. Compare that to a run of GeneriCo (seriously, I've seen it like ten times but I can't recall the brand) ads that have been running for back-to-school PCs on Hulu. The whole thing is a laundry list of features without any context for why they're going to make your life better. And there's a creepy guy hanging on the wall of a girl's dorm room. They haven't even grokked JWZ's level of marketing savvy (http://www.jwz.org/doc/groupware.html) let alone Apple's.

Collide that with some long-standing geek ethics (function over form, a hard-won appreciation for the inner beauty of seemingly ugly tech, etc) and a backlash isn't all that surprising. The hipster thing is just convenient. Hating on them is already a popular internet pastime, so throwing that (as above, somewhat spiritually appropriate) label on Apple is a nice shorthand for showing how much you don't care about how big bezels should be or whether your corners are rounded. It doesn't help that there are a fairly substantial core group of Apple devotees who engage in some absurdly irrational behaviors for status-seeking reasons (which is pretty much what "hipsterism" is all about). Why, our enraged geek wants to know, would anyone stand in line at an Apple store for hours for a new iPhone? THAT IS WHAT THE INTERNET AND FEDEX IS FOR SMAAASH

So, yeah. Extending that to accusations of overpriced-ness is left as an exercise for the reader.

1. Tough? Learn to think better. What would we tell a programmer who doesn't want to use recursion because they "think in loops"? What would you tell a carpenter who didn't want use screws to put your new furniture together because he "thinks in glue"? Units of measure are a tool, and your facility (or lack thereof) with a tool doesn't affect how good it is.

2. I actually admit to some ignorance about browser scaling algorithms, so you may be entirely right here. In any case, I think it's the least important of the issues at play.

3. I submit that it's more important to make sure that your users can use your websites in a way that's comfortable to them, rather than that they should be able to bask in the glow of your unsullied brilliance. I don't mean that I should be able to randomly change fonts around because today I like Georgia and tomorrow I'm going to like Chicago. I'm wondering what happens when your site suddenly starts getting traffic from Israel, and all your new users are using Google Translate to turn it into Hebrew. Not only do your font choices go out the window, but all your ragged right just became ragged left, and some page elements may have have spontaneously rearranged themselves. (See http://translate.google.com/translate?js=n&prev=_t&h..., for example.) Or what if some of your users are colorblind or elderly or dyslexic, or just have trouble reading your type selection for any of a myriad of reasons? Is it more important that your design should remain just how you like it, or that they should be allowed to read it? Before you answer, read this: http://tigerbeatdown.com/2011/07/14/harry-potter-and-the-oh-... It's not about web accessibility, but the major themes are still there.

One of the incredible things about the web is that not only do we have the power to make the content we're producing available to an extraordinarily diverse population, we have the power to make it so that they can all read it in a format that works for them, as individuals. When you have to design a poster that's going to get sent to a printer and plastered over bus stops, everyone waiting all over town is going to see the same poster. When you design a web page, everyone who sees it gets a separate stream of bytes and a separate display to see it on. Why not let each user find the best web page for them, instead of forcing them all to see the best web page for you?

If your source control makes branching/merging painful enough that it's going to get in your way to do it on a regular basis you might want something different, but that seems like an argument for better source control rather than a need for clever reviewing strategies.

Good times.

tl;dr, cut the fucking body policing, jackass.

http://keznews.com/3308_Adding_fonts_to_cmd_exe

Some of these tests are from the 'before times', and they test functionality that was already in production when we got serious about not having failing tests. We want to keep a record of the fact that there's something wrong, but it's not a high priority to fix them right now (since there aren't any customers complaining). As we do more development on things that are priorities, it's easier and less error-prone to make sure that we always return to 0 failing tests, instead of 27 or 115 failing tests, so that we can ensure that everything we do from now on is solid, even if there are older bits that are a bit shaky.

There are also some tests that pass, but we don't want to run on a regular basis. We have a bunch of tests specifically to make sure that we don't fail when you do something that takes ten minutes to run and eats up three gigs of ram. These tests rarely fail in any sense that a test framework would notice, and they slow everything down considerably if you run them during normal development. So we ignore them, and know that if you do anything that has perf implications (or if it's a slow Friday afternoon and you don't think they've been run in a while) you should run those tests to make sure they haven't gotten worse.

Those are the two reasons why we ignore tests that I can think of off the top of my head. It's about what lets you get work done, not about always having everything be perfect all the time.

As a final note, expectedFailure (which I assume is analogous to NUnit's [ExpectedException]) isn't really addressed outside of the title, but its use is completely orthogonal to [Ignore]. Especially for those of us writing APIs, there are cases where we're expected to fail, and it's important that we fail in the right way. If you ask me to save to a file that's locked by another process, I'd better throw an exception, and I might as well write a test to make sure that I throw an exception with a useful type and message.

As literary devices, robots don't have much to do besides rebel. If they just did what we told them to do, there wouldn't be much story to tell. (Note that that's part of why _I, Robot_ was so mind blowing - a lot of it was about things going wrong when the robots did exactly what we told them.)