you can see how much the same item sells for on ebay...

Yeah, but that could take multiple steps

Don't know enough about game dev to really make anything of it, but I miraculously zoomed up to where he talked about SICP.

I found it interesting how he was even more convinced that static-typing is valuable after reading that book, calling dynamic-typing "enticing." I guess I could sort of agree with that once you consider 1M LOC code bases like he is talking about. I was kind of surprised that he blamed a bug in Haskell on the fact that it do enough type-checking.

It's interesting because he and Rich Hickey both worked on very large systems, and they both walked away with wildly different opinions on how a programming language should be designed and what is ultimately important, though I guess games and telephony are very different beasts.

In 2012 his keynote spent about an hour talking about many different static analyzers and went into more details as to why static typing is important.

some possible insight from steve yegge:

https://plus.google.com/u/0/11098103...ts/KaSKeg4vQtz

https://github.com/blog/1586-identicons

Whatever their hash algorithm is, I now love it:

https://identicons.github.com/chadamiller.png

Mine sucks.

I'm generally a fan of Yegge, but that essay is horrible.

I got a crab! Perfect.

https://identicons.github.com/dt1.png

what makes you say that? it thought it was insightful.

He's always had a chip on his shoulder about Clojure, and he seems more extreme about it than he is toward any other language. The whole thing he had vs RH about the "Language of 'No'" was just silly.

Why would his blood boil about macros? Using them are generally frowned upon except as a last resort. This subject has been written about as far back as On Lisp. The idea is that people new to Lisp would likely reach toward macros first, and this is little more than a caveat that you probably don't need them when you think you need one.

If he is such a liberal, wouldn't the stench of working at a Java / C# house be too noxious for him to handle?

It is thought-provoking in its own right.

What do I know though? By his metric, I enjoy Bible-thumping on Sunday and sniffing blow off prostitutes in Tijuana on Monday.

sounds like he knows you pretty well, actually.

He seems to like it pretty well.

and let's not forget the untold hours our dear dave has spent "working" in "massage" parlors

Has anyone else had issues getting Zombie/Chai to work with Angular? The tests seem to work on our local dev environments, but then are a lot more likely to fail in our Rackspace continuous integration environment.

And they failing very inconsistent ways - which makes me think it's a timing issue of whenever Angular is crapping out within the Zombie headless browser. Supposedly Zombie is smart enough to wait for all the Ajax calls to return, but it seems like that isn't happening.

For now I guess our best workaround is I'm just going to make the Ajax calls by hand within the zombie tests and then pretend that the browser made them. The only other solution we could find was something like Karma, which doesn't even work across all of our environments. Does anyone know of any other cross-platform automated testers for Node out there that might be worth trying?

So I agreed to do some contract work for a local company. I was offered a fixed amount of money to write a ton of high level capybara tests covering the main paths of their app, as well as doing a few devops type things.

I honestly didn't know how long it'd take to get up to speed enough with their app to setup and write all the tests, and figured if the guy valued it at a certain amount of money, then it's not really super important how long it takes.

tl;dr I'm dumb and it's probably going to take like 15 hours to do what I'd imagine the guy was thinking would be like 60 hours based on the amount of money he offered. I'm going to help him for a bit after I'm done, since I do feel a little bit bad about doing it so fast, when I think we both miscalculated. I'm not used to coming into existing apps, so it could have taken longer than I thought as well.

I'm kind of new to contracting, so is it kind of normal for someone to offer say "$x,xxx for these 4 features," or do people usually have contractors estimate how long it'd take and how much they want per hour, then negotiate?

Is there a max wait time for the ajax response times on tests? CI servers are often way slower than your local retina macbook pros and they might timeout. I had that experience with inconsistent javascript heavy tests failing on a CI server.

I don't know anything about node headless browser stuff though.

Where does Karma not work?

Test'em is another JS test runner.
https://github.com/airportyh/testem

Estimating is the hardest thing ever. Always give yourself extra time. Estimating 60 hours but it taking 15 or 20 hours is pretty standard.

I wouldn't feel too bad honestly. I used to feel bad until I realized knowledge is power. In your case maybe someone with less experience would have taken 40 or 60 hours.

You are delivering the solution to the guy in half the time or less and that has high value. Your work is also likely of higher quality. It's a win/win for the guy because he was willing to pay the same amount either way.

It's weird, there's a max wait time – unless it thinks the Ajax call has already returned. So either that's happening, or angular within zombie is just throwing some kind of error that's tripping the wait to stop and move on to the next step. It's definitely not waiting five seconds, yet it's complaining that it can't find the element on the page that is dependent on the Ajax call.

I was told PCs and rackspace. But I didn't actually verify that myself, so maybe I should. Karma loads an instance of Chrome and executes within that. So I can see it having an issue on a remote environment like rackspace.

Karma works fine on Windows VMs hosted at Rackspace for us. This is a dev, not a CI environment, though I don't see how it would be much different. You can also use headless browsers (https://github.com/karma-runner/karm...tomjs-launcher) if that matters.

Are these real calls or mocks? If the latter, your tests should know how to flush the request and only run test assertions after the calls are returned. If the former, are HTTP services behaving differently in the test environment?

Real calls I guess - it's making the exact same call as a browser normally using the site. I don't know what flush the request means.

Yes, the problem is the test assertions are running before the calls are returned - but only on our angular pages. But I don't know if that's just because it's not smart enough to wait, or because there's some error happening within the headless browser. The debug isn't very helpful.

I don't think the HTTP services are different. I think it may just be a timing issue that in our local dev environments the calls are coming back so fast there isn't time for the error to occur. I think this because the calls sometimes fail on different tests further along on the same page.