skermes

The Retain keyword is similar to the effects from Treasury or Mandarin in Dominion, where you put some card(s) back on top of your deck during clean up if you meet the condition. Treasury especially is also a cantrip, so it doesn't use up space in your hand on the next turn.

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.

Yes, the fact that you can send email to people who aren't using your email system is the main thing that's keeping chat services stuck as part of a company's communication tools and not being the entire (or almost entire) thing.

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?

I don't know if it's really that rare, though. From where I sit Maciej is playing the fox/anansi/trickster character to a tee, with a healthy dose of ha ha only serious (http://www.catb.org/~esr/jargon/html/H/ha-ha-only-serious.ht...). Whether it's a character he's pretending to be or just his natural communication style is for him to say, but dude-who-wanders-in-to-fuck-up-your-ego-with-practical-jokes is a pretty well-established archetype that predates "troll".

I don't get the logic that starts with "Technology is moving fast but email doesn't change" and leads to the solution being papering over email's faults with some slick UI. It's like the whole city's water pressure is failing and everyone is complaining about faucet design instead of that we're using two thousand year old aqueducts. We need more out of online communication than email can give us at a really fundamental level. Suffice to say, my thoughts on this are longer than an HN comment: http://structur.al/articles/after-email/

1) There's nothing wrong with using a phrase (like "Your life would probably ...") instead of a word. That's kind of what they're for?

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.

You joke, but http://www.improbable.com/ig/winners/#ig2012

  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.

http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.htm... ?

When I spend all day hopping up and down through different levels of abstraction in the service of building some particular program, it's all too easy to start confusing the map with the territory. If I'm writing some code to draw a circle, I might also have the circle stored on disk in a file that lists a (center, radius) pair, and I might be passing it around in memory as an IDrawable object for someone else's code to consume and I'm putting it on the screen wit pixels and so on and so on and at a certain point it does become useful to have someone remind me that none of those things are really the same circle, or really circles at all, but all representations of some Platonic circle that doesn't actually exist in my code. This problem gets worse when more than one programmer is involved. How many arguments have we seen between two people who agree with each other, but can't tell because they're stuck arguing over whether (center, radius) or a pixel group is "the real circle"?

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.

I can't claim credit for this, but:

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

A lot of people bring up the idea of rigor when I compare prose and code, and I think it's really overemphasized. Just think of English as a language with a really flexible type system that lets you duck type the hell out of everything. In Python, I can write a method that expects a file object, and (at least the last time I used urlopen, which was a while ago) you can pass it something you open from across a network, and a lot of it will still work. Accidentally using a network resource instead of a local resource isn't particularly rigorous, but Python makes it work. English is that, but more so.

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.

The same way that it's your fault if your new building doesn't provide adequate wheelchair access, not the wheelchair's fault for not being able to climb stairs.

To expand on mrk-hn's comment,

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.

I have enormous respect for designers, and I know full well that I, a programmer, can't do what you do and that anything I might produce that puts pixels on a screen benefits immensely from a qualified designer's input. That said, those are poor arguments.

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?

I'm not sure why it'd be a goal to find a way to do code reviews that doesn't involve version control. We review everything everything before it gets merged into our mainline branch, and the process is pretty much what you described. Every bug/feature gets a branch, and when it's finished whoever's working on it takes a diff and attaches it to the issue in our bug tracker. The reviewers look at the diff (or, if they want more detail, pull the branch in question and look at the commit history with more context) and then pull the author in to discuss it. Every once in a while we consider either some more clever process or some sort of integrated tool to automate more of the process, but we always conclude that what we have works well enough that it's not that big a deal.

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.

I'll do you one better: bug reports filed as screenshots of a web page showing an exception message pasted into a word document, attached to an email. Of course, the screenshots had been scaled down to fit on a portrait page, so the text of the actual exception (the only information we actually needed) was too small to read.

Good times.

Please do enlighten us: what is the correct clothing to wear on a website when you discuss attempted suicides? Should we make sure to stick to earth tones so that we respect the solemnity of the topic, or do we want to add some bright colors in to make sure no gets even sadder? This is one area where I sure wouldn't want to make a misstep. What's your opinion vis a vis a pipe for added gravitas? I think it might go too far. Maybe when you're done with suicide-related topics, you could compose a manual for other scenarios, so that we can be sure to never again offend your sense of fashion.

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

You can actually add more fonts, though it requires editing the registry and doesn't work for all fonts, I think. It does let you at least get Consolas, which is good enough for the time I spend in cmd.

http://keznews.com/3308_Adding_fonts_to_cmd_exe

We have a number of failing tests that we've marked ignored at work. There are a couple reasons we don't remove them from the test suite entirely:

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.

It's not actually that ironic. Robots tend to be symbols for an oppressed underclass - their masters have (or think they have) a high degree of control over their every thought and action, they're often tasked with menial or dangerous labor, and frequently considered 'other' and 'less' than their squishy human overlords. And what's every slave driver's worst fear?

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.)

In my more expansive moments I've even used 'trip dub' to cut it down to even fewer syllables than letters.

People with dyslexia apparently find Comic Sans substantially easier to read than many other common computer fonts: http://www.dyslexic.com/fonts

It would be interesting to have something similar to CSS media queries for screen size for accessibility flags. Making it easier to change fonts for dyslexic people or color schemes for colorblind people would be great.

Not quite, I'm afraid: http://www.snopes.com/photos/military/pearlharbor.asp

Yes! I was just looking for an app to reinforce my unimaginative opinions about heteronormative lifestyles and socially regressive gender roles! Void in my life: filled.

It seems like the best response to both that mistake and that situation would have been to have a policy of pulling any error messages (or other text that'll be visible to users) from a resource file. If you made the resource file use a simple enough format, you could just pass the entire thing off to the docs team before each release and let them edit it directly. It'd also make future i18n efforts far simpler.

The obvious reason not to make color part of the syntax is that it precludes me from having different colors from whoever designed the language. In my case this is just inconvenient, but for color blind programmers, it could actually be a serious impediment to doing their job.

Of course, the solution to this would be to instead provide a UI (presumably in your editor) to change which colors are associated with which syntax bits... which is exactly what we have in any reasonable editor. So... what's the problem?

Beyond bull, the article doesn't even come close to making sense. They predict a 3% drop in 'computer programmer' jobs over the next decade, but a 32% increase in 'computer software engineer' jobs over the same timeframe. Futher confounding the issue, the distinction they draw between the two is "computer software engineers [are] the guys who write the software" while "computer programmers [are] the guys who write the instructions for the computer to use that software". I have no idea what they think that means their version of a programmer does, or how it's supposed to be different from a software engineer. At worst, it looks like 3% of the programmers in the US will have to change their job titles to software engineer and start writing software instead of writing instructions... or something.

(As a side note, did anyone else notice that programming was the only profession in the list that was explicitly gendered in its description?)

Based on the prose examples the article gives (the chess/lunch story and the crucifixion/bike race story), it looks like a truly 'pataphysical system wouldn't need IO at all. Instead, you'd have a program of some sort, that was simultaneously doing 'pataphysical computation and mundane computation. In the story of Jesus and the bike race, the narrative never shifts between the story of racing up the hill and the story of Jesus being killed on a cross, the story is both at the same time throughout. By analogy, I suspect the article would like us to consider what kind of system we'd need to construct in order to, I suppose, be a story about a bike race (or something else equally removed from programmer's usual domain) and an application to serve web pages at the same time.

Of course, given 'pataphysic's status as "the science of imaginary solutions" I won't be holding my breath for a 'pataprogrammatical Rails-killer anytime soon, but it's a fun idea.

http://www.madebysofa.com/ maybe?

It looks like the problem the author is struggling with is vocab-as-meaning vs vocab-as-etymology. She complains that english creates new words for everything; "bus", "envelope", etc, but we really tend to re-use words for different but allegorical meanings all the time. I'm sure all the readers here are familiar with at least one meaning of 'bus' that has nothing to with wheels. And the noun 'envelope' would be, I think, a pretty easy word to guess if you saw it in context and were already familiar with the verb 'envelop'.

It looks like C# 3+.