Stuffed System is a Perl framework that I have been working on for the past 8 years (since 2002!). It has just gone open source and is available now in full on github.
Stuffed Sync will follow soon.
Also — open source Stuffed Guys mini-site.
Added a 24 inch display to my Macbook Pro to increase the productivity. Like its size, resolution, colors and sound quality.
I thought I’d try to do a test post in the blog from iPhone and post a just taken photo along with it as well. Sounds good?
Finally, Jason Fried of 37signals has confessed —
We don’t have big, long-term plans, because they’re scary…
http://www.inc.com/magazine/20091101/the-way-i-work-jason-fried-of-37signals_pagen_2.html
I’ve just spent a few very frustrating and completely unproductive hours trying to understand why the Ajax requests that worked in almost all browsers refused to work in all versions of IE (tested from 6 to 8) with some vague error which IE itself refused to debug properly:
Microsoft Script Debugger which you normally use for this kind of stuff in IE6 showed me absolutely nothing (a blank white screen to be precise). Thank god that IE8 got a built in very nice debugger now. At least it was able to show me a particular line in my Javascript code. Better then nothing although the line itself didn’t explain anything.
Thanks to my natural powerful investigation skills I was able to finally narrow down the problem to the HTTP header with the charset that was sent back to the browser by the server (ie. my code on the server). I’ve used “utf8″ to specify the Unicode charset, which still looks perfectly ok to me. But since this place started to look suspicious, I looked at how other sites specify the same thing in the same HTTP header and damn — they all used “utf-8″ (with a mother effing dash!).
After I’ve changed the charset in my code to “utf-8″, all versions of IE stopped complaining. What a bizarre, bizarre thing! And even the latest and greatest from Microsoft – IE8 was also prone to this nonsense. Unbelievable.
There is a big number of apps now that have both an iPhone version and a desktop version. Usually you want to have the data in sync in both versions.
If the app doesn’t have its own web service as well (like Evernote, for example) then it usually resorts to various quirks that let you sync the data between the devices via wifi. That really is not convenient at all — you have to launch the app both on the desktop and the iPhone before the sync will happen.
So, what would be the most natural way to do the sync then? Of course, through iTunes, which already syncs all kinds of data between your desktop and your iPhone.
What Apple needs to do is to create an API for the developers to hook into this whole sync operation both on the iPhone and the desktop sides. An app can register itself in the sync framework and then an option to sync that app’s data would appear in the usual place in iTunes, you check it and it’s done — next time you connect your iPhone to your desktop the data for the app would be automatically synced.
Just completed a survey for Apple regarding the quality of the repair service for my Mac. One question in particular caught my attention –
What aspect of your repair experience had the greatest impact on your responses to this survey?
Isn’t that pure genious? All that questions they also asked like how quickly the laptop was repaired, etc might not really represent what is important for me and thousands of other customers.
For example, why try to increase the speed of repair if majority of customers would indicate that all they care about is when they are updated about the state of repair in a timely fashion?
If asked directly to rate the speed of the repair, they can answer that it was not good, for a higher level manager such answer might indicate that there is a problem. But the manager in this case thinks that he knows what’s important for the customer when in fact without that additional question in the quote above he doesn’t have any clue.
What seems obvious might easily be wrong.
Having a good program manager is one of the secret formulas to making really great software. And you probably don’t have one on your team, because most teams don’t.
We called this position a product manager instead in Stuffed Guys, but otherwise, it was exactly as Joel described with an addition of doing support as well (since we are a small company, plus support allows to be closer to the actual users and understand better what they need).
At first I was a product manager, then Ivan. But we desperately needed a separate person for that, who will not program and only manage (these two activities don’t mix well). Hopefully next time we will be more lucky and have a good product manager from the start.
This is more a note to myself to use the Joel’s article as is to describe to a person what we need from him or her.
And again Eric Sink writes things that I tend to agree with –
Do you work as part of a software team? Here’s a piece of advice for you:
Read the diffs.
Every morning before you start your own coding tasks, use your favorite diff tool to look at all the changes that everybody else checked in the day before.
via Read the Diffs.
We, in the Skoosh development team use this quite a lot. Our code is in CVS and we use a neat tool called CVSSpam which emails colored diffs of all commits submitted to the repository to all the developers.
So many times I’ve discovered bugs (including my own) just by reading the diffs in the email after the commit. It’s really a nice (and easy) way to review the code.
Listening
