Seeking Serendipity

I am a Brit. I came to the USA a decent while ago, lured by the adventure of something new (okay and skiing/apres-ski in Killington, Vermont one year when the snow was good.) I’d gone from smallish country town boy to living in London, to traveling around Europe, working in Asia/Africa and living in Hong Kong. Why not see what the USA had to offer?

Computing has been good to me, I’ve traveled far & wide through it, and I got hired to work on financial data distribution for Wall St (networks, multicast messaging, etc.) 

After a few years on the east coast my wife (then girlfriend) brought me out to Colorado and I instantly fell in love with the mountains. We moved here shortly afterwards. We’ve mountain biked, skied, snow boarded, snow shoed, hiked, backpacked, camped and enjoyed Colorado significantly. The climate is amazing, the scenery inspiring, and the potential for adventures endless. 

I live “in the mountains” in a small community up Coal Creek Canyon (technically a Golden address, but my county it Boulder. I am up/behind the Flatirons.) It took folks a while to get used to me (I was harder to understand when I got here, I spoke too quickly for most) but at the end of the day “folk are folk”, and folk here are good. They might not be townies (a freer spirit in many ways) but that is part of why I love this community.

Being on the fire department for over a decade I’ve helped/connected with many neighbours. I’ve stood shoulder to shoulder with impressive fire-fighters, and seen some things I never expected to. Running the community website I get to learn about topics folks care about, and the great efforts they are making. All good. I may still speak funny, but I feel part of this community.

I’ve lived here a while now, but I still get a kick out of every day. The two foot of snow we just had in a day, the Turkey/Elk that cause traffic jams, the mountains that inspire. Driving on the wrong side of the road (most of the time.) 

Boulder is a wonderful city; with a university culture of learning, a gentle approach to the planet and an appreciation for it’s glorious surroundings. A quick jaunt down flagstaff and I can get culture, play time, good food & entertainment. If needed, Denver is not so far away. Boulder is a great balance; small enough and yet big enough. 

For this Brit, Colorado is my “big skies” and Boulder is my home base for that.

Links:

• Coal Creek: http://www.coalcreek.com
• Coal Creek FD: http://coalcreekcanyonfd.org
• Elk/Turkeys: http://wildobs.com

Here are a some of bugs/things I found after the application had been released to adhoc (beta) users. All good reasons to spend as much time in this phase as possible/neccessary:

1) I failed to ‘retain’ a property that happened to be the one locating the website. It seemed to work at start-up but (for many people, any people who had not gone into Settings to make edits which somehow made a difference) it did not after that. In short, the application failed to connect back to http://wildobs.com. Big bad bug.

2) My ‘pretty’ (ok pretty w/o quotes, they are nice nature shots) splash screen was a copy of my about page; aspens with some text over it. I knew what it said, and it looked fine to me. To new users, they couldn’t read the text in time and were left confused.

3) I believed that code in applicationDidFinishLaunching: would be called before viewDidLoad: on any views. *wrong*. Views loaded from the MainWindow.xib (and for a tab layout that can be a few) get loaded simultaneously (perhaps even before.) I started getting reports of random crashes in initialization code. I ended up moving all my initialization code (properties, databases, application-wide data) into a singleton (see Apple site for instructions on how to create one of these) to protect this. Cost me a few hours of re-work and global search/replace but now I know it I’ll design future apps this way.

4) viewWillAppear: does not get called on views loaded from NIB directly into view; i.e. it only get called when another view goes away to reveal this. Important ‘cos I’d tried to fix (3) with some of this, hoping viewWillAppear: would happen after applicationDidFinishLaunching:.

5) I was using <BACK navigations as a “cancel” when they are truly just a “back”. I removed buttons (like ’save’ and ‘done’) simplifying and making more correct against  the HIG, no doubt. Less is more.

6) If you don’t retain the CLLocationManager (keep a reference in your own code, e.g. as application data) you’ll probably not get updates from it. Doh, kinda obvious but it happened. Testing on an iPod Touch (long story), and using the simulator, really doesn’t help navigate the complexities of receiving location information. Sure, they code is there, but you need the stream of data. [For example, I never expected to have to ask the location manager to stop trying after it reported failure to get a location. A never ending supply of pop-ups was not what I had hoped to present to the user.]

7) Numerous small bugs based on my account/test data being more well troden than others, and sometime environmental (divice) differences. Other users had empty WildObs lists, or fewer lists, or any number of different sets of data. Those differences caused different code path.

8] My initial release would not even install due to issues documented here: http://neukadye.com/blog/2009/02/19/installing-adhoc-beta-iphone-applications-via-itunes-on-microsoft-windows/

9) Data stored in an sqlite3 database was getting corrupted (cross-wired.) I learned to use sqlite3_clear_bindings as well as sqlite3_reset on statements I planned to re-use. See this: http://www.sqlite.org/c3ref/clear_bindings.html.

10) Much as the installation/start-up experience is increasingly minuscule over the lifetime of an application, it is critical for that first impression. For an application like WildObsObserver (that needs an account, then downloads data and images before it can be used) there is a lot going on at this installation time. Simplify, simplify, simplify. Spend as much time here as you can…

Not only did the adhoc testing uncover bugs and issues, but it *far more importantly* it revealed how others saw the application I’d built. Seemingly small issues that I’d grown oblivious to could be big issues to new users. Things I was sure were obvious to users, were not.

I cannot thank the users enough for how they progressed this application.

Yesterday I started a simple application and decides to utilize FMDB wrappers sqlite3. Why?

• sqlite3 function calls are low level C, and binding between Object-C types and these C function calls is a little cumbersome and ugly (converting to/from UTF8 string and such.)
• The more code, the more clutter/change for bugs & maintenance headache. Less is more.
• I found myself effectively cut-n-pasting sqlite3 calls (init statement, bind args, call, reset statement) and as such it was crying out for a wrapper.

Here are some useful links for FMDB:

• The developer’s blog posting: http://gusmueller.com/blog/archives/2008/03/fmdb_for_iphone.html
• All the Flying Meat code (FMDB plus others) http://code.google.com/p/flycode/
• Where to get the code: http://flycode.googlecode.com/svn/trunk/fmdb/src/

I couldn’t find a pre-built library, or a project to build a library, so I ended up checking out the source from SVN and inserting the few classes into an FMDB group under my classes. The file to not include (’cos it holds a main) is fmdb.m. This is good sample code/documentation.

BTW: Don’t forget to add the “Other Linker Flags” setting -lsqlite3 to bring in sqlite3.

Based on my brief experience with it, here is my initial review:

Pros:

• I like how simple it is to use, a nice Objective-C wrapper to sqlite3’s C API.
• I like the simple the interface to create/bind statements & result sets.
• I cannot believe there is significant performance overhead in this simple wrapper. (Yes, one access columns via name not position, but that is minor & developer friendly.)

Cons:

• Not sure how thread-safe it is. Code like [db do_something]; if ([db hadError] ) seems risky for anything but the simplest application. Maybe on iPhone this is not a problem, but feels wrong.
• What I really want is an “ActiveRecord” like implementation. Not fat/bloated, just simple binding of objects (using introspection, whatever) to/from database rows. I needed to add this on top and (as such) didn’t gain much from using FMDB verses sqlite3.

Things I’d like to know:

• I wish I knew how to get the last index (the auto-incremented primary key) of the last insert.

Summary:

I’ll keep using this for this application, and will keep an eye out to see if it develops, but I’ll also keep an eye out for other wrappers also. It seems there are a bunch of Objective-C wrappers to sqlite3, I need to see if some are iPhone friendly:

http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers

Since the web page I used to give out for this seems to have gone away, here is the information:

A (unique) device identifier is required (by Apple) to allow adhoc (or beta) testing of applications; the developer builds the version of the application provisioned for a given set of identifiers. This is mechanism is how Apple allow developers to release an application to a small (<=100) set of users before going through App Store submission.

The mechanism for getting the 40 character hexadecimal device identifier is somewhat obtuse.

• Connect your device to iTunes
• Select the device, and view it’s “Summary” information (the first tab)
• Click on the “Serial Number:” label to see it change to “Device Identifier:” Note: This is the obtuse part … it is the “Serial Number:” label you click on. No visual indication is given that this is possible, you just have to know (hence this posting.)
• To copy-n-paste the device identifier double click it (it will not show as selected) and CMD-C to copy and CMD-V to paste into (say) an e-mail.

Serial Number Mode

Device Identifier mode

Note: I have been told…

• This does not work whilst iTunes is downloading content.

Note: If you are a developer and you have XCode/Organizer you have a far easier way to get the device identifier.

I attended iPhoneDevCampCO #3 on Saturday, and was pleased to see a bunch of new as well as old faces. Joe Pezillo (aka Metafy), Danny Newman, Kendall Gelner, and bunch of other good folk.

Many folks were there to learn about iPhone Development, some to learn about iPhone Developer marketing (how to promote one’s app), and some to meet developers. As with many of these meet-ups the energy/enthusiasm was high, and the hopes for what iPhone Development will lead to … higher.

Before index titles

After index titles

For me, once again, the best part was meeting other folks and watching them work/seeing their work. Watching Bruce’s walk though on sqlite3 (from his Bible App) I learn about UITableView index titles (the contacts-like A-Z index down the right side.) Sure I’d read the class documentation, and reviewed the samples, but seeing another developer do it quickly helped me learn this simple capability. Nice free side-effect. The serendipitous aspect of such camps/meet-ups is an important benefit for independent developer solopreneurs.

Before I’d left the event I was able to get a generic set of utility classes built into my WildObs Observer application for all list views, with alphabetic and date indexes. I’d gone with the hope to find “ways to polish a functional app” and this definitely fits that category.

I wasn’t able to access Twitter during most of the event (I half wondered if Danny had blocked the DNS entry for productivity benefits so I wasn’t able to share as much as normal. Also, having been doing iPhone Development full time for a while now, less was shiny and new. Perhaps the most important thing to share is the attendees themselves. Any attendees wanting to share Twitter accounts, perhaps tweet using #iphonedevcamp.

I wish I could’ve stayed longer and had more of a general question and answer session. I would have really benefited for a group discussion around this view issue I’d like insights into. As time goes on I think we need to branch off iPhone newbie presentations at the DevCamp and separate our more group working sessions.

Thanks again to the organizers of this event.

First a shout out to the blog posting I followed when I was performing this for the first time:

Craig Hockenberry, Beta Testing on iPhone 2.0
http://furbo.org/2008/08/06/beta-testing-on-iphone-20/

Then some additions/re-emphasis:

#1When Craig Hockenberry says:

Now that you have setup the entitlements, you’ll want to create a new configuration for your beta builds. I found it easiest to make a copy of my existing App Store distribution configuration and change the code signing setup:

1. Make sure that you new beta configuration is the Active Configuration. Xcode has some problems if you try to modify Code Signing parameters on a configuration that is not active.
2. Use Project > Project Settings to open the build settings. Change the “Code Signing Provisioning Profile” to be “Any iPhone OS Device” and then select the name of the provisioning profile you chose in the Program Portal. If you don’t see the name listed, make sure that the .mobileprovision file is located in ~/Library/MobileDevice/Provisioning Profiles and that the “Code Signing Identity” is set to “iPhone Distribution”.
3. Use Project > Edit Active Target to open the target settings. Change the “Code Signing Entitlements” to be “dist.plist”.
4. Clean the build and you should then be able to build a beta release.

Xcode can get confused when changing provisioning and other code signing settings, so don’t be afraid to quit and restart to get things synced up.

follow these instructions to the letter. Especially on step #3 use Project > Edit Active Target and NOT Project > Project Settings … or you’ll find yourself shipping a development version of your supposedly adhoc (beta) build. When Craig says Xcode gets confused that is right, it might display that you’ve set these settings for the project at your new target’s “level” (i.e. for it only) but the build doesn’t seem to work that way. So (1) set the adhoc build as the currently active target then (2) edit that active target.

Tip: When you’ve done your build look inside the build directory at the embedded.mobileprovision to ensure it is your distribution one, and not your development one.

#2When Craig says:

Xcode can get confused when changing provisioning and other code signing settings, so don’t be afraid to quit and restart to get things synced up.

I had to. Organizer was complaining about the provisioning file, and (sorry) but I don’t recall the error message it gave. Something about the provisioning profile not having an associated certificate or something. I did an online search and received lots of complex ideas for solving it, and in the end a simple exit/restart of xcode was what did the trick.

#3To install the adhoc application on Windows:

Initially none of my beta testes could get this working. They could install the provisioning file by dragging it over the applications pane on iTunes, but never received a “+” (plus) for ‘ok to drop’ sign when they dragged the WildObsObserver.app folder (unzipped from WildObsObserver.app.zip) over the same place.

It turns out that inside the WildObsObserver.app folder was another WildObsObserver.app folder (parallel to an underscore Mac directory) and dragging that folder works. Some quirk of ZIP on Mac verses ZIP on PC? Whatever, that inner folder is the one you want.

Tip: I’ve found that the finder option to ‘compress “WildObsObserver.app”‘ option occasionally generates a corrupted (and way too small) zip file. Ensure the ZIP file size is within the ballpark of the original application.

#4 I’ve found that adhoc applications seem to get a generic logo when shown in iTunes, yet the real logo shows when the application is installed. I’m told that this is not a problem when deployed via the app store, so ought be a cosmetic issue to ignore. [Let me know if you know otherwise, please.]

Good luck beta testing your iPhone applications…

I recently switched to a Mac platform (for pleasure) and started developing on it, and even more recently started iPhone application development. I’d never seen (or heard of) xcode, cocoa, and those things. I’ve found the experience at times trivially easy (e.g. download/run/launch a sample in seconds, then learn from it’s code. Awesome) and sometimes frustratingly painful. Knowing what I know now, and wanting to help others avoid some of my mistakes, I’m planning a few simple postings.

Here are some tips I have for the newbie starting out:

• Do bookmark and visit/re-visit the iPhone Dev Center. It is the place to start.
• Do spend time on the Apple getting started videos, even though they do only scratch the surface. You need to get into the mindset that is iPhone before you start developing, and these videos help.
• Find screencasts and/or  people to watch. I learned more useful tips (configurations, tool, keyboard shortcuts) by watching Kendall & Joe develop at iPhone Dev Camp, than I did from documents (however well written.)
• Download and run/learn from the Apple Samples on the iPhone Dev Center. They are great. Not every one gives you perfect real-world examples but they help enormously.
  • UICatalog — examples of useful controls/transitions. Invaluable.
  • SQLiteBooks — sqlite, for those who want hand on DB examples. A bit bloated (with dehydration) but a solid. That said, I hear there are abstraction layers now.
  • GLPaint — good ’shake’ detection, and sound effects.
  • I could go on, I’ve downloaded 20 or more. Thank you Apple Developers.
• Pick your style of application (e.g. utility one pager, tab based) carefully because what it sets up for you (including MainWindow.nib) is not fun to re-work. If you decide to change consider starting a fresh app and bringing in your existing code. [I went from non-tabbed to tabbed and got cranky w/ Interface Builder in the wasted hours that ensued.] This advice is good for Interface Builder editing also, especially when adding tabs i.e. delete and start a fresh tab don’t hack one.
• Become comfortable with Interface Builder. Let me repeat that, no  increase it … conquer Interface Builder. It is your best friend, so long as yo don’t allow it to become your nemesis. My bad days were often spent ‘cos I hadn’t. It can be awkward at times so learn it’s quirks, and learn how to work happily with it. This excellent tutorial helped me: iPhone Interface Builder Tutorial.
• Find other developers. Watch them, develop along side them, learn by osmosis. When your app is crashing (and it will) talk it through with somebody else (including your dog) it’ll likely help.

Some random comments:

• Take time to learn Objective-C. It is C with more, and not C. It is C++ with less, and not C++. It is it’s own beastie. I’ve come to like it (I am glad it now it has @properties) but it isn’t like other languages and needs you to convert to it’s way of thinking.
• Learn the rules for when to release an object. Learn retain/autorelease/release & be comfortable with them … before you do too much. You don’t want to be chasing memory leaks/memory corruptions. [My simple understanding of autorelease is that the object is released once that events stack unwinds to the top, and the thread goes back to a waiting state. Meaning it is there for a brief period, so if you need to stash something on a longer lived class (e.g. a view) remember to use retain & release in the view destructor. @property (retain) is your friend here.
• You can (and usually do) have properties of the same name as the variable. Using self.x calls a property (and will do automatic release/retains for you if requested) whereas x calls the variable, and does not. Big difference.
• Put a global breakpoint on objc_exception_throw, it'll give you a view of the stack before the crash occurs (i.e. as exception is being thrown) which is helpful for debugging.
• Learn OPTION/COMMAND/UP ARROW to go from the implementation (.m) to the declaration (.h).
• Visit the online class documentation when you work, it is well done.
• Utilize completion via ESC, it helps you learn the available methods (messages you can send).
• Create a view (controller) in Interface Builder, create the view controller classes, then immediately go back set the File owner as this class (COMMAND 4) and then (as immediately) set the view outlet on the file owner to point to the view. See the above tutorial. Forgetting to do this causes confusing crashes when you use the loaded view/view controller.
• Never create two .NIB files with the same name in different groups. I did (by accident, one was empty) and I suffered with random crashes (in some cases the empty one would load.) Ugh, that cost a day or more & was miserably to debug.
• Start simply, stick to UI classes, avoid things like threads until you've made good progress on the UI. I didn't, and had random crashes for a long time until I removed that code. Background threads can wait, leverage the existing Threads/Run Loops the I provides (e.g. your main loop.) KISS.
• Go look at the UICatalog sample (run it) when you are designing your views.
• Avoid UIButton and use the Apple build in icons/buttons and UIToolbar. Much nicer effect.
• Create a Default.png splash screen for your app by taking a screen shot with Organizer once it is running. [I created my about page as a Model view, with no buttons but touch to hide, so I could screen shot it.]
• When testing “shake” add a sound effect so you know it is occurring (even if your code does not show it yet.) Otherwise, like me, you might inadvertently try to hard and launch the device across the desk. Ouch.
• Don’t ever (by mental slip) unplug the cable to the iPhone when you are installing an application, or (if you are unlucky, like me) you’ll have to spend the next period wiping it, restoring backups, and other non-fun stuff.
• Do spend a lot of time on the Apple site (and Apple forums) but don’t forget to Google, and visit sites like Stack Overflow. More and more helpful content is coming out.

So, if you avoid the traps/pitfalls, have fun.

Please feel free to let me know if there are glaring mistakes in this. Remember, I am a newbie at this.

Here is what I am having fun developing…

WildObs Observer iPhone Application

This evening I attended the TechStars first HackSpace. Thanks to the kind folks at TechStars for hosting, and Gnip for feeding.

I saw a lot of computers and some studious activity, but wasn’t sure how much coding was achieved. Some corners seemed heads down, but with roughly 50 people in the room the easier opportunity was for socializing.

I chatted with a few folks I’d met before (e.g. at iPhone Dev Camp) and then met some new ones. What I found fascinating was their ideas, their apps, their sites. What they were doing was more than just interesting to me, it helped me fit my thoughts (and a few feelings) into place. Others with hopes for a site, intentions for an app or plug-in. Progress, lessons learned, challenges. Having fun and serious business. Being amongst others in similar situations was powerfully ‘right’. I learned more than I suspect I realized.

I had a great evening with wonderful people & am grateful for the event.

But, I couldn’t easily walk the whole room and check out what was occurring (I’m not the party crasher @penguin is ;-)) and hence I didn’t learn from everybody in the room. I didn’t learn all the projects, and maybe I missed some ones I’d have stopped and coded for. I didn’t know who was looking for help (if anybody) and who was offering help. What I’d like to see for the next one is this:

• A consistent Twitter hashtag for the next event (#hackspaceboulder was too long, some used #hacknite, some #hacknight but both lacked location.) Perhaps propose a short unique tag with the announcement.
• Folks to post (tweet/blog/whatever) their intention to attend, but also mention their project and their needs/wants. e.g. Anybody interested (or experienced with) OAUTH for Rails want to blah, blah…
• Folks to post their learnings (the serendipitous insights that spring from the conversations.) During and afterwards.

Again, great event, thanks…

I went to iPhone Dev Camp in Boulder yesterday.

I’d not been to anything like this before, and I really didn’t know what to expect. I was apprehensive and concerned that I was way too much of a Mac newbie (let alone iPhone newbie) to be able to keep up, and that I had no right being in that room. I was more a of newbie than most, but the group was patient/open & welcoming, the presentations clear, and I found the “day of awesomeness” so awesome that I ended up rearranging firm plans to allow me to stay all day. I’d recommend this event to newcomers and experts alike.

Joe Pezzillo gave a “Hello World” introduction talk (three small versions of the same app in 1 hour) to give folks an introduction to Xcode, the iPhone SDK, and working with each. Okay, so I already felt comfortable that I knew enough to participate in the day, and went to the “performance tools” talk by Kendall Gelner. There I was quickly brought back down to earth as I couldn’t keep up, but I was at least exposed to what tools to use for what problem solving, and hopefully the things learned will return when I need them.

Kendall’s presentation on how to use the Interface Builder to created a TableViewCell UI using the graphical interface builder was practical and immediately useful. I was able to wire this technique into my application while watching him on the big screen, (monkey see/monkey do), and I was done as the presentation was over. I’d found this Interface Builder tutorial useful in the past, but watching usage live & interactive was excellent. Thank you Kendall!

I was worried I was lowering the IO in the room when I asked a lot of my memory management questions during Joe Pezzillo’s talk on the topic, but I do think it was valuable to cover for a number of the others (this simple things has some complications.) I understood the concepts of an incrementing/decrementing a “retain counter” but hadn’t picked up on autorelease draining the pool at the end of a run loop cycle. That mental picture really helps.

Kendall’s talk on debugging was more than just informative, it was fun. Having the debugger talk values using the voice synthesizer (log, ‘ignore’ to not stop, ‘talk’ the values) was both ‘annoying’ but fun, and possibly useful; one could watch the app run quickly & know values/changes w/o having to stop/view the console log. The technique of break/do something/ignore [to log values & keep going] was valuable, and “po” (print object) useful.

Kenji Hollis spoke on tools for agile development, and it was good to see the openness to sharing general tips/tricks/tools. Maybe this is something I can contribute at future camps.

Kendall’s sqlite3 presentation was a good basic introduction although I had to leave before it was running. I suspect that the “copy database from root to a writable copy in documents” was the cause of the problem (i.e. an empty DB had already been copied) ‘cos I’ve hit problems like this before. Otherwise the presentation was much nicer (simpler) than the SQLiteBooks sample on the iPhone Dev Center.

Throughout the day I picked up as much from seeing how other folks used and configured their development environment, and worked with the tools, as I did from the talks. A double whammy of value. That, and the small (sometimes throwaway) comments that just made things click. Properties w/ retain automatically “release old, retain new”, I’d not picked up from the docs. Valuable. Debug log @(unsigned int)[self retainCount]@, simple but valuable. Remove your code from what it is a delegate for [say in viewWillDisappear] to reduce risks of unintentional circular retains. Autorelease pools are pools of pointers, not a chunk of memory; one could retain something in a pool, yet release that pool, and it is still valid. Put a global break point on objc_exception_throw to get stack traces on exceptions. Things like __weak are Mac not iPhone (so be careful when porting or reviewing code from Mac for iPhone.) There were more…

I had to leave before the random Q&A session which I really wish I could have stayed for. If anybody reading this was able to stay for that please let me know what I missed.

I’d really like to thank all of the (roughly 15-20) participants of this day for their time, their patience, their expertise and their enthusiasm. Joe Pezzillo (who stayed late to help us with core animations) and Kendall Gelner presented the most, and for that I am very grateful & thank them. Thanks also to Danny Newman and TechStars for organizing/hosting.

I’ll be going to coming events in the hope that by then I can pay back some of what I gained. I also know I’ll learn something & meet some good people.

As an operator of a user generated content site I’d like to warn my family/friends/users and others to what I suspect is a big, and likely growing, security problem. Not every username/password system is as secure as the big ones you are used to (e.g. Gmail, Yahoo, AOL, etc.) so do NOT re-use your  ”usual password” at all sites. All sites are not secured equally (however clean/crisp their front page might look) and you need to recognize the risk. Yes, this is common sense, but I suspect it is also common mis-practice.

Think about it … you create your username at some rinky-dink little web 2.0 website (like mine), and you use something you are comfortable with/you remember, perhaps based upon your e-mail address or your typical login. For recognition (yours and other folks) you use what you know. You use your e-mail account username, or your FaceBook username. Perhaps all are the same (or close enough.) Chances are a quick web search will connect your username to your true identity pretty quickly, or the username is identity enough.

Then you have to chose a password. Who can remember so many, especially with so many piddly little sites? You think “why take the time to remember one for that site?” … and proceed to enter your “usual password”. That password has just been given to somebody who might not be secure, who might not encrypt, who might have been compromised. (Heck, they might’ve created a simple site purely to capture username/password pairs and sell them on the black market. That is not out of the question, it is likely a  cost effective scam.)

Giving your secure passwords to anything but the biggest sites is crazy. You just possibly gave away *all* the access credentials needed to access your privates accounts to someone/something you cannot trust. You might use that same username/password combination for their online banking information, for your e-mail, for any number of truly secure & important sites.

It is that simple. I suspect a large percentage of “average users” are giving their most private credentials to totally untrusted organizations. In short: create a new password for each site, and never trust your “secure passwords” on non-secure sites.

Why am I thinking this is a rife/growing problem? Recently … I’ve seen folks trying to log into my site with usernames of folks I know, who (when I ask) were not attempting to log in at that time. Basically someone (or something) was trying to log in using their credentials. In these cases they failed to log in (the credentials were different on this site) and I received a log message notification. It would seem that somebody perhaps thinks they may have stolen the credentials of these users and are seeing how much access they get with it. Maybe they’ve logged into their bank, maybe they’ve been reading their e-mail address & stolen their address book & are spamming their friends. Maybe they are just biding their time with full access.

BTW: I added “Open ID authentication” to my site  in the hopes of easing this problem of memorizing passwords, except that the folks that truly need it aren’t comfortable using it, and so don’t. As such, the best defense is best practices.

Don’t re-use passwords. Don’t, not ever. Never, never, never..