Wow -- Has it been this long since my last post?

I guess dates don't lie!  I wanted to drop a note explaining a oh-so-small change to my support site

For the last several months I've seen a slow but steady increase in Spam from my site.   It started out very small (maybe one spam in a few weeks) but it's recently spiraled out of control to tens or hundreds of spam posts per day!

Up until now I've used the most friendly spam filter available -- it asks you questions like "what day comes after tuesday".  It worked well but either the spammers have figured out a way to game that system or they are some poor human being somewhere to spam my support forum for items like Ugg boots (why Ugg boots?  no idea)

Anyway yesterday I turned on re-captcha (you know, the super-annnoying one that shows you two pictures that are heavily distorted).  So far it seems to be working, my spam load is down  to zero today!

This does, sadly, come at a small cost of being less friendly to ask your questions but honestly it was tough for me to keep the support site clean with so much spam.

I will continue to monitor the situation -- Perhaps in a month or so I'll turn it off and go back to the friendlier version to see if I can make it work.



Notablemeals is a finalist!

I'm happy to say that my newest iphone app (Notablemeals) is a finalist in the evernote developer competition. Please vote for it!

Comments (2)

Evernote Competition

I've been working frantically on an entry for the Evernote Developer Competition -- What I eventually came up with was an idea called "Notablemeals" An app that would let you easily capture any meals that were important for you and store them in Evernote.

This is certainly a scratch your own itch kind of app -- I've always weirdly wished I had more memories of important meals  -- A couple of time while traveling I've tried to take a picture of my food but I'm always disappointed with the results (who needs a bunch of random food snapshots mixed in with a picture of the pope -- who needs that?

Anyway I was on a crazy tight schedule (it was about 15 days until the end of the competition and I had *zero* lines of code written) and I knew that if I wanted any hope at all of  being competitive I need some help in the design department.

Fortunately  KaL MichaeL was available and after a whirlwind two weeks I'm happy to say we were able to turn out app in this last sunday evening with 'hours' to spare :-)

 I don't know how it will do in the competition but I do know that I've never felt better about an app.  It's design is great thanks to KaL, it's  code is some of the cleanest I've ever done and it's one of the more intuitive apps I've produced.

I've not submitted it to Apple yet but I hope to do so in the next day or so...  The website should be up in the next few days and I'm looking forward to getting more feedback on ways to improve it.

Google IO 2011

I'm going.



If you go to this link

You'll see what appears to be some sort of joint marketing or sales deal -- It's not.

I have no idea why Ralf thinks he can do this but I have nothing to do with it and would strongly recommend you not use this service.

Won't be on the Mac App store (for now at least)

I've been working on my first 'real' Mac App (real in the sense that it's standalone, not RapidWeaver related as such and will actually be completed)

One thing I've decided (for now anyway) is that I will *not* offer it on the Apple Mac App store.

Why?  I want to actually have a relationship with my customers -- If I go to the Apple Mac App store then Apple is in the middle without adding any real value (except perhaps for a bigger reach)-- I never have details of who my customers are and they feel 'extra removed' from me.

When you buy anything from my store I send you a receipt with (among other things) information about how to contact us if there is a problem, when you download a new version you get it from my server with my release notes (via sparkle) and if I find  a problem I can push out a fix in minutes.  -- No such luck with the Apple Mac App store.

By the way my new app syncs flickr & iPhoto, hit this if you are interested in beta testing.

Handles Content as Compound Value

Bindings in cocoa are un-freaking amazing -- You can change a model parameter and bada-bing-bada-boom the UI updates... Fantastic!

For the most part they just sort of work but I've always been a little confused by all of the options -- Honestly the only one I ever really played with was 'updates continuously' which does what it says (updates happen instantly and it doesn't depend on hitting 'return' or tabbing out of the field.)

The docs are actually here but I've mostly ignored them, until tonight.

Tonight my nemesis was 'Handles Content as Compound Value'

Why? you may ask -- it's perfectly clear what it does.  From the docs:

Handles Content As Compound Value
A Boolean value that determines if the content is treated as a compound value.
Model objects can store relationship-like data in "compound" values and it may be necessary to use a reversible value transformer to translate those compound values temporarily into smaller pieces, that can be displayed and edited individually. See “Bindings Message Flow” in “Cocoa Bindings Programming Topics” for more information.
If YES, the content of a controller is treated as a compound value and—by using a reversible value transformer—will apply changes as a single value to the master model object if anything changes (edits, additions, removals).

 Errrrr.. got that.  What the docs should have said was

Handles Content as Compound Value
Click this if you plan on binding an NSArrayController to a NSUserDefaultsController.

Yup -- That is the magic trick to get it to all work.  If you don't do that many odd things happen but mostly the bindings don't work right.  Apparently (?) the NSUserDefaultsController applies a value transformer for storing the dictionary entries.  Don't ask me why as it's not documented but that appears to be the case.

Just tossing this out for to the googleverse so some person flummoxed why they can't easily bind up their NSArrayController to a NSUserDefaultsController.
Comments (1)

Evernote Power tip

Here is an idea -- whenever I pass one of those heart rate machines that are avaialble at drug stores and the ilk I jump on, get a reading and then using the Evernote  iPhone app I take a picture of the results.

Then every few weeks I go through and enter the date/time and readings into a spreadsheet (well in my case I enter it into my fitbit account but the point is to keep track of it somewhere)

What makes Evernote great about this is it syncs to all of your computers/devices so when you have a few moments you can go through and transfer the results of your measurements (I then delete them as I have no need to keep pictures of my measurements).  Evernote is also great because you can use the thumbnail view to quickly find all of the measurements you haven't entered.  

No fuss, no muss and a  hassle free way to keep long term track of your blood pressure.

Fwd: Untitled snapshot note


Snow Leopard enumerateObjectsWithOptions:usingBlock

One of the niftier things in Snow Leopard are blocks -- It's a way to encapsulate a bit of code and pass it around to do useful things.

I won't go into the hairy details but suffice to say it lets you do some interesting design.  Recently I was faced with the problem of looking through a 'large (30,000+) array of strings to find matchess.  The simple 'containsObject' feature of NSArray was "ok" but slows down as the size increases.

As an experiment I thought to write a version that use blocks and concurrent searching.  NSArray has a enumerateObjectsWithOptions:usingBlock: method that exactly fit the bill.

So... replace:

foundIt=[self.items containsObject:itemToFind]


[self.items enumerateObjectsWithOptions:NSEnumerationConcurrent
usingBlock:^(id s,NSUInteger idx,BOOL *stop){
    if ([(NSString*)s isEqual:itemToFind]) {

The results? I tried 4 experiments for a variety of sizes.

In every case the blocks version was faster for ~8000 elements or more (below 8000, the startup costs of blocks are too much) -- These results are on a 8 core mac pro so it's possible it could be worse on a dual core machine but the result would be the same -- at some point there the blocks version will win.


My first Android App

As my previous post mentioned I went to google IO -- One of the smarter things they did was shower us with cell phones so I've spent the last few weeks (on and off) doing Android development.

I just published my first app to the Android marketplace (it's a free desktop widget that monitors your Tender inbox -- Tender is a support system I use)

My thoughts?

  • Android development environment is both better and worse than Xcode.  The reasons are much too numerous to go over but the main differences are Eclipse (Android) has some amazing run time type checking and validation -- If you type something in wrong in almost any part of the IDE it let's you know and recommends ways to fix it (it's really amazing that way) but it's also kind of slow & clunky (and very un-mac like).  Xcode is closer to the metal and feels like a good mac app but gives you more rope to hang yourself (on the plus side you can do some crazy cool stuff with Xcode that I haven't seen the equivalent in Android)
  • Learning Java isn't as hard as I had feared... Partly because I used to do a lot of C++ and it's pretty close to that and partly because it's not so different than Objective C in many ways.  Java as a language is actually pretty remarkably well thought out.
  • The component model of Android development is very interesting and in many ways innovative..  You can do a lot in android with very little work.
  • Targeting Android devices is interesting -- you don't know for sure the processor, screen size, input methods, etc. that your customer has so you work at a more abstract layer (for example I had to include three pieces of artwork all at different resolutions to account for that).  At the end of the day however it's just a matter of adjusting workflows and sort of accepting that on some devices it may not look perfect (it's very similar to designing web pages where you don't know for sure what kind of browser or screen size the viewer will have).   iPhone is very targeted -- you know exactly what the user will see and can really target that experience.
  • Publishing to the marketplace is an amazingly different experience.  I finally decided I basically 'exported it', uploaded it, typed in a description and added a screenshot, hit publish and *literally* within about 45 seconds I checked the Markeplace and it was live!  If I find a bug I can re-publish it at a whim and have it live within minutes... Amazingly nice
In the end it was a pretty enjoyable experience -- I've been using Android for the last several weeks but I believe that will come to an end about June 24th.....  I'll probably not do a lot more developing in Android but the experience is pretty reasonable and the phones are getting better and better. 

Long term I suspect Android will become the market leader and iPhone will be relegated to a second or third spot -- This is partly because Android is already at more or less feature parity (actually better in features) and is fast becoming 'pretty enough'

Having said that  a second or third place spot in the Cell phone market is still pretty freaking big and Apple will continue to appeal to a certain kind of customer who really appreciates the experience they provide.

For me, as I said, I'll be in line to get  an iPhone 4 and on June 24 I suspect my Android will stop being carried around very often.


Next Page -->