jkkramer

As a customer, I'm happy. I loathed the idea of maintaining separate queues, to the point where I started writing a unified queue web app in preparation.

As a developer, I wonder if they're still sticking to their plan to make the API streaming-only? [1] As much as I didn't like the idea of Qwikster, I was hoping it would provide a dependable DVD API.

http://developer.netflix.com/blog/read/Upcoming_Changes_to_t...

I don't know if it uses "event sourcing" per se, but doesn't HN use in-memory & serialized Lisp data structures instead of a DB?

Using the no-DB approach is particularly tempting with a language like Clojure. Clojure can slice & dice collections easily and efficiently. It has built-in constructs for managing concurrency safely.

I actually have a couple Clojure apps that rely on a hefty amount of in-memory data to do some computations. Even the cost of pulling the data from Redis would be too expensive. The in-memory data grows very slowly, so it's easy to maintain. Moving faster-growing data in-process would be trickier, but this article makes me want to try.

After 5+ years in the salsa scene, most of the best male social dancers I've met work in a technical field -- software, engineering, etc. It requires tremendous mental acuity.

EDIT: I should add that it does not come naturally most of the time. It still requires hard (physical) work and persistence.

I found this interesting because, in the HN bubble, we mostly talk about monetizing solutions for the problems of privileged folk. For example, Paul Graham's "Startup Ideas We'd Like to Fund".

Bill Gates argues that solving the problems of the less-privileged doesn't have to be purely philanthropic -- there's actually profit to be had if you know how to find the right market.

This was written in 2008. Have there been notable examples of creative capitalism since then?

> Simplify the git fetch, pull (--rebase), push interaction. Synchronize — don’t make the user figure out what they need to do to get their local commits remote and remote commits local.

What about conflict resolution? That's one of the hairiest, least-user-friendly scenarios in my experience.

3000 lines of spaghetti code is one thing. But this code is pretty-well modularized. The author obviously knows what he's doing.

Maybe he finds it easier to jump around the file that way. I know I've built up projects like that. When it starts to transition from tech demo to real product, I would probably break it up into different files (util.js, lexer.js, etc). But no harm in the meantime.

A simple web app spread across 42 files might actually be terrible and over-engineered. Or it might not. The moral is: don't judge code quality by isolated metrics.

Allowing subscriptions to be charged yearly would be nice.

In Clojure, hash maps are functions of their keys. If you use keywords as keys, then keywords are also functions of maps.

    ({:a 1} :a)
    => 1

    (:a {:a 1})
    => 1

    (map {2 4} [1 2 3])
    => (nil 4 nil)

    (map {:a 1 :b 2 :c 3} [:a :b :c])
    => (1 2 3)

First impressions:

- Pretty nice. It's something I might use.

- Scrolling is a bit choppy (OS X Chrome). I'm not a fan of re-inventing scroll bars.

- I wish the meta info was displayed on the page rather than having to click to reveal it. There's more than enough room.

- A button to create a new pastebin would be useful

- Needs support for Clojure (or even just Lisp)

Returns are always a pain in the butt. No matter how easy you make it sound, people are going to be anxious about it. But even assuming returns are effortless, they're a HUGE money sinkhole for online retailers (Zappos returns average 35%).

There's a startup that does 3D scans of shoes and allows users to determine the perfect fit by asking about shoes they already own (can't remember the name). IIRC, they plan on doing clothes, too. That would be the ideal.

I once tried comparing official clothing measurements from various vendors online and came to the conclusion that they were all lying. Short of 3D scanning or painstaking measurement by hand, there isn't an easy solution. It certainly seems like a problem ripe for the picking.

Finding clothes that fit is an important part of looking nice/stylish. It's also a serious hurdle to shopping online and why I never do it. I think a service like dress.me will need to address this in some way or the process will remain somewhat anxiety-laden.

Neat idea. Minor nits:

- Would be nice if custom background images tiled

- Not clear whether to enter usernames or URLs for accounts

- "Add an Technology" typo

- No cancel buttons on the forms

- Popup forms feel a little sluggish to open. Any way to have their HTML preloaded?

- List of tech, etc could use some typography/color to make it more readable

I like how it keeps going even after it finds the solution.

Almost. Record types are checked as part of full equality. So record Foo{:x 1} is not equal to Bar{:x 1} or to {:x 1}.

Records and structs can grow at runtime (insofar as immutable data structures grow).

    user> (defrecord Foo [x])
    user.Foo
    user> (assoc (Foo. 1) :y 2)
    #:user.Foo{:x 1, :y 2}

    user> (defstruct foo :x)
    #'user/foo
    user> (assoc (struct-map foo :x 1) :y 2)
    {:x 1, :y 2}

Cooking has become a pretty important part of my life. It's a great change of pace from sitting in front of the computer. Acquiring a very sharp knife helped me enjoy it even more.

Here's what I've cooked recently, plus other recipes I've saved:

http://yumtab.com/sarah-justin

(I actually created YumTab specifically to keep track of this stuff.)

Quick thoughts:

- You've clearly put a lot of effort into this. You seem to have a big collection of useful features. Congrats on that.

- I checked out the site before reading your post. I didn't really get what it was about -- something to do with bands or something. You wrote in your post, "It takes care of all the boring, tedious number-crunching aspects to being a professional in the industry." That kind of concise tagline is missing from your site. I would put all those boxes with features and stuff below the fold and summarize your service above the fold with a heading and maybe a short paragraph. E.g., https://www.wepay.com/

- The video, which should be featured more prominently, is way too long. It's clear you put a lot of work into all the features, but it's too much to show off all at once. Give a "big picture" view of the service and skip over the details. I'd aim for no longer than 1-3 minutes, the shorter the better. The video's job is to give people a taste, and get them excited.

- I tried going back to the site after writing some stuff here. It immediately took me to the video page and I didn't know how to get back to the homepage. Really confusing.

- I now see that when I click on "Bands" it gives me more of an overview video. I didn't expect that. That video still has a lot of details. Needs more summarizing to tell you what you're seeing and why it's the solution to your problems.

- The design could use some spunk. It may be handling "boring, tedious" details but you don't want people to think your app is boring and tedious. Not sure what to suggest other than maybe getting a designer's input.

Nice job so far, good luck!

Fingers crossed that they do it right this time. Right now I informally group browsers to test into four groups: IE6, IE7, IE8, and all the rest (where it's rare to find inconsistencies or WTFs). It would be great if IE9 went into the "all the rest" category.

Most of the complaints I hear about crowdsourced design services come from people who don't participate in them (just for the record, I don't either). It seems kind of presumptuous to say the designers are desperate and being taken advantage of. Maybe the long-term value is worth it for them (e.g., winning 10% of contests)? Maybe they find it a fun way to build experience?

In what way, specifically, is it shady? Is using a crowdsourced design service inherently shady?

Maybe there's a way to rally the students and get them to petition their universities to switch to something better? They pay the bills, after all.

I originally envisioned this as a replacement for delicious, and have been thinking about instructions as nice-to-have but not essential (I don't bother adding them myself, I just open the original recipe). However, your goal is probably common, so I'll see about catering to it. Thanks again.

Thanks. I'm investigating the image issues (seems you bumped into it right off the bat).

There is tagging & tag/ingredient-based searching, though it's not integrated with the planner per se. I'll think about that. EDIT: FYI, tags are in the Your Notes section if you didn't notice

I know. They launched half-way through my development, to my chagrin.

YumTab has a number of advantages:

- Automatic ingredients capture (no copy & paste)

- Planner, shopping list

- Easier to show off recipes you make, follow others

EDIT: oh, I see it's your site. Nice work on it, I don't mean to belittle your efforts. I was pretty unhappy to see the name similarity when I saw it a couple months ago, but I had already committed to my name.

The culprit is apparently FlashHeed, an otherwise helpful script which helps lightboxes show above Flash content. Are you using something to suppress Flash? I attempted a fix, which may require a cache clear (haven't put in static file versioning yet).

Thanks for tips & for submitting random non-recipe links, which gave me an idea about how to handle them :)

Great input & tips, thank you. I added a note about missing instructions as you suggest.

Re the edge case, what browser are you using?

Scraping is as you might expect: it has to go fetch the page if it hasn't yet (URLs are only fetched once). One thing I can do to help here is pre-fetch/parse pages from popular sites. I'm already doing this for Food Network and Allrecipes.com.

The machine learning aspects aren't too bad. Most of the time is spent parsing the HTML DOM. I've done some micro-benchmarking but am very curious to see how it will handle under real load. I have a plan for moving from VPS (Linode) to AWS if necessary.