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.
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!
Very cool! Flatmin looks like an awesome service! Payback is definitely still feature-minimal :p Everything you suggested is actually a major item on my to-do list! Facebook integration has been brought up several times and I very much agree about the hex string scheme - the next thing I'm going to do is look into an invite by email/ join with referral link, etc. I have no intention of trying to monetize either - I made it purely as a learning experience for my own apartment, and it does seem like a difficult space to get into.
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:
He annotated a passive-aggressive annotation on a patch I made and basically hijacked a presentation I made because the library I presented did not fit his aesthetics & work style. I don't remember ever acting in an uncivil way toward him.
If you regularly act like an asshole, expect to get a reputation and to be treated like one (even unfairly).
Btw, I'm glad you are bringing civility up. For some reason the lack of a civil vibe (at least from my experience in the Ruby community) really bothers me.
I want to oppose to the impression that there is a lack of civil vibe within the ruby community. I work on the Padrino project and most of the communication with the ruby community, our committers and our users is highly enjoyable. Jerks can be found everywhere, but they are a minority.
It really depends on what projects and groups of people you're interacting with. We have a wonderful community around Ruby Mendicant University, but it's because the folks there really care about teaching and learning as a primary goal, so they self-select towards being friendly.
Ruby isn't really a community anymore, it's an ecosystem. So if the current neighborhoods you're hanging out in don't seem too friendly, look for other ones. Different projects and organizations have different culture, and even if the union of all of those distinct groups is on a downward trend, there are still new and old groups that are going strong who are nice and helpful.
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)?
We actually had a debate in our engineering dept about how we wanted to handle functions like this, and in the end decided on tt_function_name() in the global function space.
We decided against putting them in explicit namespaces, because we felt these were convenience functions and they should be convenient to use. We felt the convenience of:
if (tt/global/string/starts_with($url, 'https://)) {
}
was worth the lack of organization. We have <10 of these types of global functions in our code base and we are very careful about adding new ones. All other classes and functions are either in a namespace or class context.
We went with the tt_ prefix because we wanted to cover our bases and really explicitly ensure we never will collide with a PHP function, and we felt it isn't too unwieldy.
As for using a singleton class, since 5.3 we prefer to use namespaces instead.
Sure is, and we do organize our 'use' statements the same way one would organize 'import' statements in a python file.
However in this context again we felt that the convenience of just being able to throw these functions in place without having to worry about putting the proper use statement was worth the tradeoff.
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 :)
You're right, when your finest granularity is "per day" you lose any real sense of what a day means to the user (and when it starts and ends).
Right now we don't have a solution. As it turns out (I guess) our users don't mind. In the future we want to provide certain (or all) stats also in the "last 24 hours" (rolling) time frame, which will help. One benefit of our Redis-powered analytics is that they're live. Even if your idea of a "day" is different than ours, you can see the count/totals/averages/etc updating in realtime (relative to the "day" we decide on). So users can get instant feedback if something is happening, but for the most part only care about day over day stats (which make the TZ matter a lot less).
The simple solution is to store everything in UTC, but that means the smallest resolution you can store is 30 minutes (some time zones are :30 offset, and you ignore the Chatham islands that are :45 offset - http://en.wikipedia.org/wiki/Time_zones). It's really annoying and I have wished many times everyone would just use UTC.
Not if you're trying to save RAM (and operations to fetch said data) by storing stats per day. You'd need all stats to be per-hour in order for it work for any timezone.
They can't in their (Disqus) case because they're aggregating all the stats per day into a single value. I guess they could do it 'per account TZ' since the account name is in the key, but that means TZ calc on each write (not that that will make a huge difference in perf).
For a generic solution with easy TZ calc, you need to aggregate your stats into hourly values instead (or half hourly if you care about those wacky non-aligned timezones). The increased fetches don't matter because you can just mget them.
As per all generic advice, YMMV.