graue

Cool! How do you plan to deal with theft? Most bike lights are trivial to steal. I tend to avoid the fancy ones since in my experience lights disappear immediately as soon as the bike's parked (unless I remove them and put them in a bag every time I park, but that's a pain). Curious how you're addressing that.

I'm not aware of a good reason to prefer ClojureScript+Node.js in general. Maybe if you wanted interop with a specific Node library, but otherwise, Clojure on the JVM will tend to have vastly better performance, and the tooling is better.

For example, until recently ClojureScript's :keywords were just strings under the hood and it required a string compare to test equality. Apparently this is no longer the case due to this commit 2 months ago: https://github.com/clojure/clojurescript/commit/2cef52840fcd... but it shows you the kind of stuff you might run into. In a recent talk I saw by David Nolen, the lead maintainer of the ClojureScript compiler, he brought up multimethod dispatch as something that can still be as much as 100 times slower than the JVM.

As a tooling example, Clojure gives you helpful errors if you initialize records the wrong way:

    user=> (defrecord Thing [foo bar])
    user.Thing
    user=> (Thing. 1 2)  ; correct usage
    #user.Thing{:foo 1, :bar 2}
    user=> (Thing. 1)    ; wrong number of fields
    
    CompilerException java.lang.IllegalArgumentException: No matching ctor found for class user.Thing, compiling:(/tmp/form-init7089728177345913731.clj:1:1) 
    user=> (Thing 1 2)   ; forgetting the dot
    
    RuntimeException Expecting var, but Thing is mapped to class user.Thing  clojure.lang.Util.runtimeException (Util.java:219)

That's good! Especially if you're new to the language. You see where you messed up right away.

But ClojureScript just silently gives you nils:

    ClojureScript:cljs.user> (defrecord Thing [foo bar])
    cljs.user/Thing
    ClojureScript:cljs.user> (Thing. 1 2)  ; correct usage
    #cljs.user.Thing{:foo 1, :bar 2}
    ClojureScript:cljs.user> (Thing. 1)    ; wrong number of fields
    #cljs.user.Thing{:foo 1, :bar nil}
    ClojureScript:cljs.user> (Thing 1 2)   ; forgetting the dot
    nil

This should be a bug report against the CLJS compiler (edit: now it is[1]), and it's probably not that hard to fix. I could fix it. You could fix it. (The CLJS compiler is very approachable and needs contributors, by the way.) But, especially as a newbie, this kind of stuff can bite you. JVM Clojure is more polished.

1. http://dev.clojure.org/jira/browse/CLJS-639

Published in February 2012, revised in June 2012, according to this:

http://www.davidreiley.com/papers/SpamEconomics.html

It's perfectly practical. GIMP did exactly that for years. The 2.8 release notes[1] mention removing the warning now that save and export are separate.

The stated goal was to make it harder (still? I guess people clicked through the warning without reading) to accidentally save in .png or .jpg and lose the layers. But the result, for someone whose usual workflow is to open a .png/.jpg, edit, and save back to .png/.jpg, could not be more user-hostile and obnoxious.

In response to a complaint, someone on the forums wrote[2]:

> This is the way Gimp now works. Of course you can consider this a PITA. But for other folks, losing work because they saved as JPG instead of XCF is also a PITA. The philosophy is that people that are impacted negatively by this change are people with very simple work-flows who would be better off using simpler software (XnView, Digikam, Lighttable...)

In other words, all of you people with simple workflows, that worked just fine in Gimp for years? Now you have to go off and learn some new software, because Gimp is for Serious Graphic Design™ only. Ugh.

I got excited researching this because I found a changelog for Gimp 2.8.4 that mentions patching the behavior to be sane[3], but then I realized that's only a patch in the unofficial OS X build. On Linux, the same nonsense in the latest version.

1. http://www.gimp.org/release-notes/gimp-2.8.html

2. http://registry.gimp.org/node/26273

3. http://gimp.lisanet.de/Website/News/Eintrage/2013/3/21_GIMP_...

That's a recent change, and yeah, one of the worst examples lately of open source developers' contempt for their users. Apparently, those of us who've used Gimp for over a decade to edit .jpg and .png files and save them back to .jpg or .png, were Doing It Wrong, and the devs wanted us to know. :(

Mind you, I've never contributed the tiniest bit of code or funding to Gimp, so I can't really complain.

That's different. Browsers need to show your password to external websites to prove to others that you're you. This requires storing the actual password. They expose saved passwords in the UI because if they didn't, it would create a false sense of security. There's always going to be some way to get the saved passwords, or the feature wouldn't work.

The router admin interface only needs to check your password. It can do that by storing only a cryptographic hash, not the password itself.

That couldn't be a less accurate description of Firefox OS.

aimed solely at content consumers: No. FxOS phones can't do as much as a Nexus 4 or iPhone, but they aren't meant to compete with those. Mozilla's targeting emerging markets where most people don't have smartphones or maybe even computers at all. At $80 unsubsidized, the ZTE Open is approaching feature-phone price and it can do a lot more than a feature phone (and will do more still once FxOS matures).

neutered only to run web browsers: It has full-fledged apps. Using web technology under the hood isn't the same as running in a browser.

NIH development environments: You can't get much less NIH than adopting the web itself, which everyone already uses and develops for, as your platform. If you look in the Firefox Marketplace, many of the apps you see now are web apps, written without FxOS in mind at all, with maybe 15-45 minutes of effort to package them for the marketplace.

tied down to specific languages: There are hundreds of languages that compile to JavaScript[1], and some, like ClojureScript, are already seeing real-world use in commercial apps[2]. With Emscripten, you can use any language that compiles to native. There are performance and debugging challenges but they're getting addressed with efforts like Asm.js and source maps. In 2013 you don't have to write JavaScript to use the web as a platform.

1. https://github.com/jashkenas/coffee-script/wiki/List-of-lang...

2. http://keminglabs.com/blog/angular-cljs-weather-app/

I actually have seen complaints about Go's performance relative to other compiled languages, like C++, D and Java. I don't think it's coincidental that most of the Go converts come from a dynamic-language background. If you're porting from Ruby, 2-3x slower than Java still seems blazing fast.

For me, Go misses the sweet spot entirely. A year ago I was curious about both Go and Clojure, my interest piqued by the strong concurrency support each has. I picked Clojure and have grown more and more confident in that choice.

Why not Go? In a language with nil pointers (Tony Hoare's "billion-dollar mistake"), no generics, and sub-JVM performance, static typing just doesn't seem worth it. Also, poor interop with other languages means Go can only draw from its own small community for libraries (contrast Clojure which makes using mature, well-tested Java libs trivial).

When Rust is more mature, it may be what I hoped Go would be: the safe language, with lightweight threads, that makes me never have to write C or C++ again.

I disagree. It's not idiomatic in, say, Python, to catch every possible exception, only the specific ones that the programmer thinks are likely to occur in practice.

I love how there's a thorough "what's new" document for a still-in-progress release, and terms like "provisional API" are linked to a glossary that tells you exactly what they mean. While Python is not the most interesting language to me anymore, it still sets the standard in clear, comprehensive, newbie-friendly documentation.

> 3. Move closer to work – a short commute is worth more than a big house

I disagree with this one. It's possible to live too close to work. If the commute is less than 15 minutes or so, or perhaps more to the point, if it isn't far enough to feel like a separate place, I'm less happy. I need the separation.

I've experienced this both in college — I was happier when I moved across the river from most of my classes and classmates — and recently at a job, where it was about a 7 minute bike ride to work. You'd think that's ideal, but I felt trapped, like my home was nothing but an extension of the office.

One of my happiest times, in fact, was when I had an 11 mile bike commute (or an hour and 15 minutes on two trains). It wasn't very practical, and was logistically difficult (and I was often late), but I felt amazing.

I've never owned a car, though, so maybe the guideline about shorter commutes is correct if you drive. I've always either walked, biked (exercise) or taken the train (opportunity to read, meditate, relax).

Interesting. I had a different experience in Montreal (and my mother when she visited Paris): we would try to say a few words of French, and people would immediately realize we were American and switch to English in response. Maybe your French isn't quite as rotten as you think.

I've found NYC almost as bad. Just being able to afford the rent isn't enough. Here, yearly income 40x rent is standard, and sometimes even that's not enough.

Since I'm doing contract work and don't have a regular salary, one landlord told me outright that even though I had demonstrated I could pay, he wouldn't rent to me because he "wanted a more stable tenant".

It feels terribly insulting to be told that, and makes me long for a humbler city like Chicago or Minneapolis, where if you have money, a landlord will take it without nearly this level of nonsense.

Or Berlin. I looked at apartment prices there and began to feel quite jealous of the Germans :)

Unfortunately, Firefox and Safari still don't provide column numbers in error stack traces, only line numbers, which are next to useless if your code is minified. Here's the Firefox bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=762556

Not much discussion about fixing it :( This caused a lot of pain at my last job. When we got Chrome and IE10 stack traces, we had a script run them through our source maps and show us the exact, full stack trace through the unminified source. Firefox's and Safari's traces remained impenetrable, short of manually inspecting the minified line of code and guessing.

This one is my favorite so far :) Very sleek. But I wish it distinguished "tar" and "snap" to give a subtle cue as to pronunciation. What if the "tar" part were set in a slightly heavier weight?

Airbnb would make recognizing that it's your property nontrivial. They don't show a specific address until a reservation is accepted; the point on the map is randomized and can be a few blocks away; photos are supplied by the host and may not match photos the landlord has (if the place is sufficiently well decorated and not distinctive, it may be hard for even a human to determine it's the same place).

If however you licensed some good facial recognition technology, perhaps you could compare the face in the Airbnb host's avatar with that on the ID each of your tenants supplied when applying for an apartment. It would be far from bulletproof, but could get you somewhere. In a less-densely populated place maybe you could even get away with "notify us if someone named Bob offers a new room within 0.5 miles of 622 Cedar St", perhaps hiring low-paid humans to sanity-check the results before passing the notification on to the landlord.

Worked fine for me too. I think it might do that if you've already been logged into a Google account and signed out. Try deleting your Google cookie(s) entirely.

I mean the font, not the overall design. While I admit I can't rule out the possibility that the design on the left side of the image unconsciously influenced my reaction, I tried hard to only look at the font.

I imagine Comic Sans fits, but you may want to include a fallback to sans-serif for non-Windows users. I'm getting the default serif font, which is not a great match.

Why does that matter if bar.org doesn't and isn't supposed to support HTTPS, and if there are no links to bar.org via HTTPS? In either scenario if someone manually types in https:// bar.org it's not going to work.

We're not discussing whether or not you should have SSL at all. We're discussing whether it's worth getting Extended Validation, displayed as a green bar in browsers. E.g. currently at https://twitter.com you get a lock icon and a green bar that says "Twitter, Inc. (US)" — that's EV. At https://www.facebook.com you only get the lock icon — no EV.

Not to my taste — looks really stodgy and conservative to me.

Agreed. The "r" looks heavier weight than the others to me. (Though I can't be sure if I'm only noticing because you mentioned.)

Nice. It looks like I was misinformed, and I now have much less reason to avoid the Bay Area. Thanks for clarifying.

Though biking a 5 mile long bridge with no bike lane on half of it sounds terrifying, so I'd probably consider it still not bikeable for now.

However I hear that because BART shuts down early every night, you can't go to a nightclub, or even out to dinner, or work late(!) on the other bay, because once BART's closed, you're out of luck. No bike or pedestrian access on the bridges.

Is this true in practice? How big of a hassle is it if you don't have a car (and don't want to spring for an expensive taxi/Uber ride)?

(This reputation is a big reason why I don't want to ever move to the Bay Area. I currently live in Brooklyn, and can easily get home from Manhattan in 20 minutes... at 3am if I want to. In Cambridge/Boston the T shuts down, but not until around midnight and you can still bike or walk.)

(Edit: I was misinformed. I'd heard the BART shuts down at around 10pm, but it seems it's actually more like midnight, similar to the Boston area, and I didn't know there were all-night buses providing service between SF and Oakland when BART is closed.)

Might be less obtrusive to favorite instead of retweeting.

(Edit: This assumes you can get a list of favorited tweets ordered by when they were favorited. I just noticed the web interface orders them by time posted, not time favorited.)

There's nothing crazy about that. I've known lots of people who dumpster-dive. A college roommate of mine lived on nothing but free and dumpster-dived food for several months when he was broke. Even when he had money he liked to do it and would bring back vegetables to share. One time we feasted for weeks on a huge grocery bag full of (normally expensive) avocados, eating around the bad spots... at least ¾ of it was good.

If you think it's crazy, I'm gonna guess your broke college-kid days (if you had them) are long behind you. :)

You misread. They make a mobile app that streams stuff from their cloud. Therefore, to calculate actual delays in their app, they must add network response times and touch latency.

Did anyone else do a double take reading this?

> If you’re a JavaScript programmer, chances are you’ve seen (and done) something like this before:

    var listener = node.addEventListener("click", function(event) {
        let _target = event.target;
        this.handleClick(_target);
    }.bind(this));

I had to go look up `let` in JavaScript[1]. It appears to still be a bleeding-edge feature not widely supported[2] outside of Firefox... not even in Node with the --harmony flag. I wonder if this is meant to be subtle pro-ES6 propaganda, or the author really takes `let` for granted and doesn't realize most JS programmers have never seen it :)

1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

2. http://kangax.github.io/es5-compat-table/es6/#let

This is only semi-on-topic, but it's really cool how Ghost is a non-profit organization:

http://ghost.onolan.org/what-it-means-to-be-non-profit

and the post does a good job explaining what that means and why it was chosen. I definitely want to see more mini-Mozillas :)