nikz

Programmers are inherently encouraged to be lazy, so they'll follow the easiest path assuming you're careful to actively encourage that... if you're not really careful about exactly how "obvious" you make your intended path (Hint: It's never obvious enough) then you wander by a few weeks later and there's a giant Rube-Goldberg construct blooming in source control.

As per all generic advice, YMMV.

SEEKING WORK | Remote or London, UK

Full-stack Rails developer, been using Rails since before v1.0. I've just moved to London and I'm looking for something for ~20 hours per week.

More about me: http://nikwakelin.com

Email me: me@nikwakelin.com

Are you sure it's not more along the lines of "don't 'play' at it, do it properly?"

Perhaps I'm reading too much into it. I guess that's the problem with this sort of vague generalised advice :)

We have a similar app, Flatmin (http://flatmin.com) that's targeted more specifically at shared living situations.

We built it a few years ago, and h(ave|ad) big plans to expand into household chores and shopping lists. It's an interesting problem from a couple of perspectives. We've found the more Facebook integration we can do, the better as the target market are very comfortable with Facebook.

It's also a difficult one to make money from - we have some ads on there, but I think to really make it work you'd need integration with another app or some kind of freemium offering (daily deals?)

Yours looks nice - if I could make a suggestion, it would be great to enter email addresses of people to invite, as sending them a hex string is less common and more likely to get lost!

The source is at https://github.com/kicksend/mailcheck if you want to check it out.

Seems to have been coming for a while (http://techcrunch.com/2011/12/05/gowalla-acqhire/), but I think they just pulled the trigger judging by this tweet https://twitter.com/maxvoltar/status/178658732950040576.

Obviously it would be nice not to be rude to people who, after all, are working on something that benefits you, if you are prepared to call other people out like this:

http://rubyhitsquad.com/Ruby_Hit_Squad.html

Then I believe you should probably have a thicker skin in return.

May be slightly off-topic, but I feel a little pain behind my eyes whenever I see the hack-around-namespaces function naming (e.g tt_whatever, for "ThumbTack" presumably).

Surely a singleton class would be a nicer way to do this (or just leave the "tt_" off, why is it necessary, you're not overriding core functions)?

When aggregating stats in this manner (by Day) how do people deal with Time Zones?

For instance, if I have one user in, say, NZST, their "Tuesday, 22 February" is still "Monday, 21 February" in PST - and the real issue is that the buckets are off. So you can't just store in UTC and then move it by whatever timezone offset, as then you are grabbing different "buckets".

I don't think that explanation is very clear (I had to draw a diagram to figure it out myself). Hopefully someone smarter than I am can figure it out anyway.

We've worked around it by just storing hour aggregates, but I'm interested in case someone else has a smart solution :)

IIRC, this is actually invalid Javascript syntax that Chrome/Firefox/Safari choose to ignore.

JSLint picks it up:

  Error:
  Problem at line 1 character 22: Extra comma.

  var x = { foo : "bar", };

Be careful with this. We've used it on a number of sites, and whilst overall it's beneficial, there are a number of weird things to watch out for.

For instance:

  - Don't add rounded corners to a <table> element - this will crash at least IE7 on XP
  - Don't try to rounded corners an element you've hidden with the "left offset" technique (position: absolute; left: -9999px;). This will crash at least IE7 on XP.

I think there a few others I have since erased from my brain due to IE-induced PTSD. YMMV.

I think there's a more succinct explanation of this somewhere, but I think people usually overvalue their own contribution whilst simulataneously undervaluing that of others (see: http://books.google.com/books?id=YywIHNBn_YEC&lpg=PA147&...).

So perhaps it's the cynic in me, but I would expect people to be justifying their own importance. I do agree with you though - it should be the reverse!

It's very interesting to note the backgrounds of the various people involved in this debate.

http://www.linkedin.com/in/nathanielwhittemore would lead me to believe Nathaniel is not a "code"/execution person (I could be wrong, obviously).

Whereas the people on the other side of the debate seem to be largely execution guys - coders or self-styled "product" guys (YCombinator, Eric Ries).

It's almost a tautology - the execution guys say the execution is most important, the idea guys think it's all about the idea.

Like most things, the "best" answer probably lies somewhere between the two extremes.

That's really interesting, thanks.

We've talked about adding more information about the market in general, and that's the intent of the blog (blog.200square.co.nz), but it's not very prominent at the moment.

Thanks!

You would definitely be able to see it first! You'd just organise a suitable viewing time with the owner (you can send messages back and forth using the system)

Thanks - here's hoping they'll accelerate in the new year!

You generally get in touch with a buyer directly to book inspections.

We might develop something to make that a little easier though, so thanks for the suggestion.

We definitely don't expect anyone to buy a house without seeing it!

Hmmm - we had kept it like that to be focused on the seller - there's more buyer info under the "buy" tab. We hadn't considered the "traction" angle. I'll bring it up with the others - thanks!

You can see we've got 13 properties listed publically - there are quite a few more in the pipeline, including deals with some building companies.

We've only been live a couple of weeks, and it's the main holiday time (summer) over here, so we'll see in the New Year.

People seem to either "get it" and love it, or dismiss it as "it'll never work". We take the polarization as a positive.

EDIT: oh, and thanks for the design comments - I'll pass those on (I'm the tech guy)

Clickable:

http://200square.co.nz

"All too often a single HTTP request will have 4 or 5 database queries in it, and that is regarded as normal."

Is this really normal for a Java app? A typical Rails app (either built by myself or someone else) would have tens of queries in a request and still complete in under 1s. That was my experience with PHP too.

I get an error message (from the actual app, http://browserling.com/) - "No API resources availble for null group" (seems to be no matter which Browser/Version or URL I choose).

I'm using Chrome, as requested.

We make MinuteDock (http://minutedock.com). More of a standard time-tracking program than a clock-card machine, but serves the same purpose </shamelessplug> ;)

The API documentation is probably not where you want to look in this instance. It's more intended for looking up the behaviour or options for a specific method call.

http://guides.rubyonrails.org is the equivalent of the Python documentation you point to for Rails.

If you want Ruby-specific documentation, there are versions of the Pickaxe book online (http://phrogz.net/programmingruby/). Admittedly old versions, but well organised by-topic nonetheless.

Done ;)

Make sure you click the small music note in the bottom left-hand corner...

Interesting points, and some food for thought. Thanks for that.

I'm not sure it's a "winner take all" market - there's no real "social"/"viral" aspect, just the usual "word-of-mouth" that people aim for.

We have no money (don't need it), no YC contacts and it seems we'll be entering later - so we better have some other (big!) advantages ready.

Thanks, I guess I should say the same to you! :)

This means I'd end up with 5% of the company (if I'm lucky) according to most of what I've read (could be wrong, of course).

The theory over there seems to be that the founders keep as much of the equity as possible, and pass it out the 1st/2nd/3rd employees in very small parcels.

Normally when I build a product here, it will be more of a 3rd/3rd/3rd split (Design/Dev/Business), or at least 20%/20%/60%.

I guess that means I'd prefer to be a founder, take on the extra risk (and the chance of extra reward!)

Try getting a refund when their crappy plugin crashes your browser...

How about the printed copy that's now unusable (because it's, you know, paper, and paper has a habit of getting crumpled or ripped or wet or binned...)

Even iTunes doesn't make me pay for an mp3 again if my HDD dies...