HN user

IdahoEv

58 karma
Posts2
Comments29
View on HN

By category:

1) Heavy Strategy: Eclipse and Terra Mystica (tie)

2) Strategy Cardgame: Race for the Galaxy & expansions

3) Abstract: Arimaa. Runner up: tie between Go and Hive.

4) Real-Time Co-op: Damage Report. Runner up: Space Alert

5) Co-Op: Mysterium

6) Wargame: War of the Ring. Runner up: Twilight Struggle

7) CCG or LCG: Lord of the Rings LCG

8) Party Game: Time's Up Title Recall Runner up: Concept

9) Reaction time: Jungle Speed.

10) Most disliked game: Catan or any spinoff thereof

It's Angular 1.4 at the moment - the project was started well before A2 had anything like a coherent direction for its API. Releasing an Angular 2-compatible version is one of our top priorities for the next surge of development.

That said, Xing uses Hannah Howard's module A1Atscript (https://github.com/hannahhoward/a1atscript) to add a very Angular 2-like TypeScript annotation syntax, including A2-like component architecture.

That should make Xing apps much easier to translate to Angular 2 than other Angular 1.X apps.

What I really want to see is Gigster's contract. What terms do they make their clients sign?

To do any kind of fixed-price work, you need absolutely ironclad protection against scope creep. Said protection against scope creep usually must start with an extremely detailed specification - the kind of thing that takes weeks to develop, not a 10-minute phone call.

I would imagine Gigster's terms looks something like: • Client gets no input beyond the 10-minute phone call • Interpretation of the specifications given in that phone call is 100% up to Gigster • Any revision of specifications whatsoever results in a change order

I've built or managed the teams that built over 50 software projects, ranging from small up to about half a million dollars.

With all that experience, my estimate process is now extremely honed. It takes me, quite consistently, 4 to 8 hours for a typical web startup MVP. And that's assuming I can build the product completely with technologies my team has used before.

... and predictably, the first comment proves her point.

You see two or three examples of comments in the article, and feel comfortable dismissing her point entirely as a result. But of course a written article has only room for two or three examples.

She wouldn't have written it if there weren't an absolute nonstop stream of this sort of crap over the course of years. A point she made abundantly clear, and an experience that would be oppressive to anyone.

(Not to mention the numerous things that can't possibly be read as "nice or funny", like having all your contributions ignored in favor of equivalent contributions from men. That makes me wonder if you actually read most of the article, or just skimmed and cherry picked a couple things that left you feeling justified in dismissing her.)

When you learn to listen to people who are struggling instead of dismissing them, your life will be better. I promise.

This insistence on political correctness

It isn't "political correctness" - the phrase implies that the language has no real effect and changing it is merely for show, or as a political statement.

Using male pronouns as gender neutral has a measurable effect on comprehension that has studied and reproduced repeatedly. Using "he" pronouns as generics does in fact lead both men and women to exclude women in their comprehension of the sentence a statistically significant fraction of the time. See for example http://www.jstor.org/discover/10.2307/27784423?uid=2&uid=4&s....

Revising language not a "thought barrier", it's an actual real benefit.

Your entire premise is false.

He's been mendacious as all of them, sure. That's not the important difference.

The important difference is that there are now millions of black American kids no longer growing up in a world where they just "know" as a first principle that "black people can't be president". That sort of example simply changes people's outlook. Inspiration and aspiration matter.

OTOH, I've experienced a lot of people who know basic computer science but don't grasp any software engineering. Nor do they even realize that it's a thing.

Those sorts of people tend to be very focussed on clever algorithms and data structures, and frequently miss the larger picture and coding best practices. I've seen far too much code that had extensive CS cleverness at the root but was spaghettified, untested, undocumented, poorly performant, and not even tracked in a version control system. Such people often don't value writing code that other developers can read and maintain. On a team, clarity matters more than cleverness.

Good developers need both sets of skills.

> on the African savanna, where humans evolved

Um... answer's right there. Indeed this was the case on the African savannah, pre-agriculture.

We're no longer living in that environment. In the 21st century it's trivial to get sufficient calories, vitamins, and a balanced diet without eating meat.

Other points about our environment: (1) Relative to the African savannah, most of us burn many fewer calories per day. Fat asses in front of a computer instead of chasing down antelope, yanno. (2) We live 3x as long now, so our health concerns are different. That high-calorie blob of fat is tasty because it meant not freezing to death at age 16 and hence those taste buds were strongly selected for. Today we don't have that concern, and all those fat blobs may mean living to 60 instead of 80.

The survival needs of proto-humans on the savannah 100kya are not a very good guide to nutrition and health in the 21st century.

Wharrgarbl. Economists frequently state this as a fact, with zero recourse to empirical analysis.

It's a theoretical statement based on microeconomic reasoning which itself has flawed assumptions (assumptions like "people make rational economic decisions" and "consumers and employees are well-informed about their options). The econ 101 supply and demand model is an extremely poor model of most real-world economic systems, employment included.

When it hits the real world and a standard of evidence, it doesn't hold up. The wealthiest countries in the world with the highest employment rates and the lowest poverty all have minimum wages. Implementation of minimum wage laws is highly correlated with improved standards of living among the poorest, and is not correlated with significant increases in unemployment. (Empirical studies show things like a 0.6% decrease in employment, and only among teenagers, for a 10% increase in the minimum wage.)

I'm coming around to that view, myself. I've long since switched to playing most games on "normal" difficulty or below, because ratcheting up the difficulty really only adds tedium, not challenge. Once you figure out how to beat the bad guys, you just have to work at it longer on nightmare difficulty. And very quickly, the repetition is not fun.

I've definitely had games where I was enjoying the story and every once in a while I would totally have used a "fast forward combat" button if I had it.

Would be curious to see the other end of the coin: given a complex web app with dozens of controllers and hundreds of templates, what's the amount of developer time required to build it with each of these frameworks.

Rather harder to automate that, though. :)

Oh right, I remember adventure games. Ten minutes in I've clicked every dialog tree and tried every button on every visible object, and nothing seems to indicate what to do next. If I click every possible combination I might eventually find the right thing that unlocks the next part of the story.

This is fun because...?

In case anyone's curious, the game concept is a sandbox (a bit Dwarf-fortress-like) in space. Instead of excavating Moria, you're constructing Niven rings, Dyson spheres, and other megastructures.

Shit, I hope he's okay; he's one of the best faces this country has for the popularization of science.

I just saw him recently at a talk on exoplanet discovery. He was there as one of the introductory speakers in his role as Executive Director of the Planetary Society.

I figured this out eventually. However, when I first switched to git (and before I had tools to show my branch in my prompt), I managed more than once to make 3-4 commits on a detached head, and finding out how to fix that between the documentation and/or Google was essentially impossible. Once I simply gave up and re-did the work. The other time I figured out how to fix it, at the cost of about 3 hours of research and (eventually) questions on the IRC channel.

It's a powerful tool, and the docs are fine if you are an expert who already knows what you're looking for. I'll submit that it can be incredibly hard for a noob to learn to use correctly.