mxavier

When I code in Haskell, the first and most important step I make is to create rich types for the domain I'm working in. If you disambiguate your types, your code becomes more readable and the compiler is a lot better able to help you out when you make a mistake.

For example, rather than having an Invoice with a status field of Text or String, I have a type InvoiceStatus = Paid | Unpaid | Void. From there, you can write a very precise parser that takes exactly what you want and nothing else. When I apply this approach to each component of the thing I need to parse (or do it generically even), I don't really find myself having to munge javascript types into my data structures.

I own the original inPulse and the charge lasts about 1 day. That's the main reason why I stopped wearing it. Definitely interested in something I can let go longer with an always-on screen. I'm not a fan of thinking about my watch's charge level.

While I'm not disagreeing with this, I wonder if it will impact the users of Milk Inc tools' willingness to participate in future projects. For services which run off of user's submitting content (reviews in the case of Oink), I'd imagine users may become hesitant to contributefor fear of the project (and thus their work) getting shot in the head.

I'm not saying terminating a project that didn't meet expectations is wrong, I'm just curious about the lasting implications.

I'm having a hard time understanding the intent behind "You shouldn't need to know Haskell". Do you mean in order to complete the tutorial and understand what Yesod does? That's probably true. Being someone who's been studying and using Haskell in personal projects for the past maybe 10 months or so, Haskell's syntax and fundamental design decisions (while spot on, in my book) are different enough from most programmers' skill sets that I don't think they'll make it very far writing a non-trivial Yesod app without knowing Haskell. I'm fairly proficient/enamored with Haskell now but I'm certain I would have crashed and burned if I got my start trying to learn Haskell from Yesod.

My first dose of Haskell was attempting to write an XMonad config. That turned out to be a frustrating, several hour long ordeal for me that had me write off Haskell as undecipherable, alien hieroglyphics for quite some time after that. I'd urge anyone reading the tutorial who likes what they see to put in the hard time to get a handle on the language, understand what its good for and what it isn't and then return to web programming with it.

There's a 2009 Documentary called Vanishing of the Bees that covers this. It was quite alarming to see the impact it had on beekeepers in the US. If you have netflix, the doc is available for streaming and is well worth the watch.

Like this email, I've noticed Louis' personality permeates the whole experience. An interesting little tidbit: the password emailed to me after purchasing to access my content didn't work. I clicked the button to reset my password. I received an email with the text:

Apparently you forgot your password? Ok, so here's your new one, stupid:

My generated password was prefixed with "idiot.THENEWPASSWORD". It's little touches like this that I find really nice.

Also, needless to say, I would buy one of his specials in a heartbeat should a similar offer come up in the future. I watched the special last night and it was outrageously funny.

This service may serve a purpose for men as an early indicator that their SO has communication issues. I cannot speak for anyone else but I for one would not want to be in a relationship where my SO was spying on me like she was my probation officer.

I'm fairly new when it comes to working with Erlang. We've developed an application we use internally for essentially doing distributed, fault-tolerant timers.

I, however, would caution against some of the platitudes you use about it being the future of concurrency. I also think it is kind of silly to imply that a coder isn't "worth their salt" if they aren't learning Erlang. It isn't a panacea. If you read some modern Erlang guides like Learn You Some Erlang, for example, you'll note that a responsible advocate of Erlang will caution against drinking too much kool-aid. Erlang, for example, is admitted as being a poor choice for lots of string manipulation because of the way strings are implemented in the language. I believe that same guide mentions that it may not be the best choice for heavy number crunching.

Developers worth their salt will not just hear the word concurrency and start writing everything in Erlang. It is much better to consider the problem and ensure that the problem domain matches Erlang's particular strengths.

I also want to mention that in my experience, Erlang applications are pure hell to deploy for people who don't have years of OTP deployment under their belts. So much of having a manageable Erlang app depends on the developers being well versed in a lot of subtle, and very easy to get wrong conventions. We actually ended up needing to start a support contract with Erlang Solutions themselves to help us demystify getting a sane deployment process going for our app. This was an expensive endeavor. Yes, it was primarily because we were new to the language, but it also had a lot to do with a lack of community documentation/discussion about deployment procedures. I won't even get into the joy of trying to decipher Erlang's famously cryptic crash reports/stack traces.

tl;dr: Erlang isn't concurrency pixie dust. A developer isn't a failure if they aren't currently learning it, nor are they a success if they just decide to use Erlang for every class of problem. It is an interesting language to work with and solves certain problems very well, others not so well.

I'm sure Google considered this but I hope that by default, my feed subscriptions are shared with nobody in my Google+ circles and that I have to opt those people in. Doing otherwise would be the equivalent of dumping the contents of your browser bookmarks for all your friends to see. There may be some things people subscribe to that they'd prefer others didn't know about.

Our company gives them money but the main thing is that we have a lot of small private projects that are more like prototypes and will never see the light of day. We are not permitted to open source them and probably wouldn't if we could because they'd be worthless to everyone but us. The pricing plans for additional private repos is pretty steep with github so we had to pay for a crappy repository hosting service to dump all of our second tier projects. GitLab would be pretty neat to allow us to store our second rate stuff on our own servers and the stuff we use every day on github.

Maybe I'm misinterpreting. Are there really contracts that say that any code you write, even if it is unrelated to your work and off-hours is the property of the company you work for? If so, that sounds like a horrible arrangement. That would be like a chef making a sandwich for himself at lunch and having to give it to the restaurant where he works instead.

I opened the tab and then forgot about it while reading other stories. Scared the shit out of me when I got around to this tab.

I knew this would happen. I bought a Thinkpad T420s which has a non-standard (or new standard?) 7mm hard drive caddy instead of the much more common 9.5mm. I bought a 64GB Crucial M4 because it could be modded to 7mm and the price was right. I'm happy with the performance. It feels noticeably faster than a standard magnetic drive, but the 64GB is in tier 10 on this comparison. I guess as long as I'm happy with the performance it doesn't really matter. I wish this article was around 2 weeks ago.

Exactly. I only really lob softball queries at DDG. I use ! to go to the first result on queries I know are going to have the right match first. Everything else I proxy to google through !g. DDG is great but the search quality (or perhaps the size of the data they index) is just not nearly up to par with Google.