At first I wanted to be able to flip forward / backward as well, but on second thought, maybe only being able to add todo's for today and tomorrow is a plus ?
1,353 karma · joined August 15, 2007
Maybe in 5 or 10 years.
I wonder if this data will be made available in some form, I'm sure it could be a great source for some really nice visualizations.
Most technologies will have a local usergroup holding frequent meetups which you could attend to meet up with interesting people.
I'm from Europe, but I'd love it if you could stream these sessions too.
Maybe look into streaming via justin.tv or something ?
VOD's would be pretty sweet as well.
edit: Although your algorithm is preferable !
The whole concept of sending a robot to your job and getting it's wage is delusional.
I was arguing in favor of 'growing something' as opposed to 'designing something' with regards to a hopefully growing userbase.
Language choice may be of lesser importance as you say, but I do feel that some languages fit the growing strategy better while others have a more design up front feel to them.
This, imo, is part of having developers choose the best language for the job. They chose ruby to get their mvp out quickly and be able to grow their userbase. After that, they pinpointed trouble areas in their architecture and made pragmatic choices in fixing up those areas.
While I suppose it's possible to "let developers pick the best tool for the job" and end up with 5 different languages in your stack, most good developers are likely to steer clear of such an endgame, unless the trade-offs are very, very clear.
It allows you to focus on features and pivoting over ceremony (boilerplatey / architecture stuff) and when you finally start hitting those performance limits, you have a luxury problem.
It will also be more apparent where to invest time spent scaling your product, whereas if you try to optimize out of the gate, you may still hit unforeseen performance issues.
If anyone is so inclined, you can vote for me here: http://forrst.com/i/5cV
For example, both Hibernate and ActiveRecord allow you to just throw straight sql to your database, returning a bunch of key value data.
Which is exactly what a good solution does: provide large gains for the common cases, and get out of the way for the edge case.
For one off stuff I usually use ruby nowadays, and if mobile would not be my thing, I'd definitely be delving in to Rails (have some previous experience here) and Node.js.
I've done some projects in Django but didn't really dig that as much. There's a ton of Python frameworks out there though, and Python the language is pretty cool to work with and a breath of fresh air if Java has been your mainstay for the last decade.
a) be solved by someone else already and take half a day to integrate
b) be solved in another language / framework whatever and needs to be ported.
I find that in project mode, it's just easier to bargain and try to drop any feature which falls into the b category, at least for version 1.
This way, the customer will have a working product minus a few features in a reasonable timeframe (2 weeks to a month).
The basic gist was that designers like to keep around lots of versions and this gels well with git's easy branches.
That coupled with these kind of great tools really give me hope for a version control strategy that is useful to both designers and hackers.
Most of the stuff mentioned in the book should be covered in schools, but usually isn't.
It sounds like a large project compared to just steadily polishing the app itself and starting a second app on the side, or even as your new main project.
An added benefit in starting work on a second app is diversification, different target audience, different appspace. You say building a good app is hard, but so is building a good web offering.
I think some of the difficulties I've had in these type of projects stems from the customer not knowing where they want things to go / not having thought things through.
In this situation they seem eager to bounce ideas, which is great, but once those new ideas start affecting deadlines and budgets, the relationship can get tense.
Genuinely curious here. To narrow it down a bit, let's talk businesses who primarily operate on the web or through a mobile app.
It just seems that outsourcing the core of your business is a strategy that's destined to fail.
You need to be able to pivot, and fill in the blanks as you go along. Most freelancers and shops don't give you this option, or at least not at a reasonable cost. It feels like most businesses would be much better off hiring someone and giving that person a piece of the business as part of the deal.
Written in a way that makes it very easy to understand, especially for relative newbies, it's not technology bound, encourages good practices and fosters curiosity. In short, it's timeless.
This should be required reading for any junior hire imo.
It's also possible to turn off the autoupdates.
It's debatable what the best default setting would be, and wether or not average users:
a) know how to disable this b) care to disable it
Like you say, it necessitates a level of comfort with a company. I suppose most people don't give this a lot of thought, and thus feel pretty comfortable with any company.
Wether this is "good" or "bad" is a separate discussion imo.
mv stuffwithoutbackup tosomeotherplacewithatypointhepath
curse at typo
rm -rf tosomeotherplacewithatypointhepath
curse more vigorously
You raise a valid point about not knowing exactly what is being installed, but the flip side of the coin is that security fixes and new feature support get adopted much faster.
It's nice knowing that mom's laptop will automatically receive that security patch.