I'm really finding evernote is hitting the sweetspot: I've dumped reading and linklists in, and started tracking some task and TODO lists and it works pretty well. My only issue is that I'd like to use it at work (where we have no admin rights), and the web interface is somewhat clunky and slow (particularly when the corporate network performance is pokey), so this is hampering my take up and use of it. Otherwise, I'm finding it a great wee app.
I've been working a reasonable amount of late in dealing with considerations of software defect management and metrics to indicate "software reliability". Personally, I always think that reliability is a continuum (like trust), and that a software is only as reliable as its last failure. Software which predictably fails big and often is obviously "unreliable", but much software runs fine most of the time until something "unexpected" happens...is this software then unreliable? Well probably not until it starts failing more frequently, and more predictably, and therein lies the problem: it is difficult to know how reliable a software system is until it stops to be reliable.
There are pretty much two approaches to reliability - one is based upon trending, and the other on prediction: while I much prefer the trending approach which says check how reliable your software could be considered now, then check at now+1, take a look at the rate of change and this is the indicator as to your vector of reliability, I also think that taking a look forward with a decent prediction model, can help to set a sense of expectation.
I think this sense of expectation is best summed up in the idea of "code smell" or "defect risk", which could be considered as "is your code smelling better or worse over time" (trend) and "is your code likely to smell worse at any point in the future" (prediction). There are obviously complexity, coverage, sizing, and defect tracking rules which can be applied, but I really like the concept and approach to "volatility" as set out in the article: "Software Volatility" by by Tim Ottinger and Jeff Langr in the latest Pragmatic Programmer Magazine, since this seems to blend trend and prediction together: the code which you touch most often is the place where code is most likely to break, and the more you touch it, the more likely this is to happen.
I strongly suggest reading the article, and look to applying a similar approach in a balanced reliability metrics scorecard and inspection process. I certainly don't think that it should replace coverage (which lets you know where you have unit tested), cyclomatic complexity (which lets you know how many tests you should write, and when you might want to consider refactoring), sizing (which just gives you a volume idea of what you are looking at), code analysis (sort of spellchecking for your code), defect classification and tracking (for failure rates and densities)... but it certainly represents a tool worth sharpening and adding to the toolbox.
I was just looking through my O'Reilly digital bookcases and wondering whether it is possible to have too many tomes from this publisher:
(NB: I think the answer is no...)
Here is the list of what I found:
97 Things Every Programmer Should Know
Beautiful Data
Beautiful Visualization
Data Analysis with Open Source Tools
HTML5: Up and Running
Learning Rails
Making Software
Making Things Happen
The New Community Rules
The Productive Programmer
The Social Media Marketing Book
Web 2.0: A Strategy Guide
The Art of SEO
Beautiful Testing
Complete Web Monitoring
CSS Pocket Reference, Third Edition
Designing Web Interfaces
Facebook Cookbook
Getting Started with Flex 3
Grails
Information Architecture for the World Wide Web, Second Edition
Programming Collective Intelligence
Search Engine Optimization for Flash
SEO Warrior
Universal Design for Web Applications
Website Optimization
As part of the fallout of the Yahoo thinning out (and hoping that delicious finds a buyer), I just received the following mail:
Yahoo!
Dear MyBlogLog Customer,
You have been identified as a customer of Yahoo! MyBlogLog. We will officially discontinue Yahoo! MyBlogLog effective May 24, 2011. Your agreement with Yahoo!, to the extent that it applies to the Yahoo! MyBlogLog, will terminate on May 24, 2011.
After May 24, 2011 your credit card will no longer be charged for premium services on MyBlogLog. We will refund you the unused portion of your subscription, if any. The refund will appear as a credit via the billing method we have on file for you. To make sure that your billing information is correct and up to date, visit https://billing.yahoo.com.
Questions?
If you have questions about these changes, please visit the Yahoo! MyBlogLog help pages.
We thank you for being a customer on Yahoo! MyBlogLog.
Sincerely,
The Yahoo! My BlogLog Team
I am not the worlds greatest "Getting Things Done" guy (only got half way through the book, and just could not get around to putting it into place). In a quest for lightweight but useful "To-do" managers and "Do not forget" managers, I have been through the full gamut: I even bought Bento (and have not really done much with it). The one tool I really loved and do use is delicious, but I have the collywobbles with the Yahoo announcement (withdrawal from market, and then a quick revision to "we want to sell it) and have been looking into not losing my valuable brain estate. I've been taking a peek at evernote for a while, and so finally decided to download this and work out how to get my delicious stuff into it: easy-peasy, just follow these instructions - works a dream: Instructions to import delicious into evernote...Lovely.
So, I've started on the first chapter of "Mining the Social Web" proper, and realise it will involve much side reading, as 1) you really do need to know python (although this is already installed in OSX, joy!) 2) you really need to read all the APIs and 3) it looks like the book is going to look to install a large number of python packages. Still, using the twitter package and pulling down the timeline content in terminal is quite cool.
I think I will probably need a once through hands-off, then a once through hands-on, as the first chapter is moving pretty fast, and making some fairly heavy assumptions on development confidence.
Those nice folks at O'Reilly have started a Blogger Review Programme, and kindly let me be a part of it. Essentially you commit to write a review of an O'Reilly tome in return for a digital review copy - just like I remember it from my real journalism days!
I've been insomniac the past couple of nights (it is 3:45am in Geneva), mostly churning some Measurement & Analytics annoyances in my head, so am now sitting reading the intro. to my first Blogger Review book "Mining the Social Web" (and I suppose I should really try and write this posting in hReview (but I can't be bothered)). So first thoughts are: looks interesting - looks like social network analysis for the social web, so ties nicely into some of my usual old hobby-horses. First gripe would be that all the code is in Python (which I don't know), so I'll have to get to grips with that. It looks like it might hook in nicely with the really interesting, but slightly forbidding "Programming Collective Intelligence" (which if I remember right is also chock-full of Python) - could be a useful companion piece.
Since the O'Reilly review is a 200 worder, I'll try and run a longer review chunk by chunk as I work my way through the book, and then try to some up the overall impression.
Sitting at home, feeling sorry for myself as I am off work sick, I thought I might write a short blog post on using Behavioural Driven Development (BDD) for Requirements work with clients - a technique which I am starting to use with some (note the qualification) success.
I'm a big fan of use casing "As is" models and "To be" models to get a really nice sense of the contexts in which a system is supposed to work (and by system, I mean people, process and technologies), but this can be hugely tough unless you are working with clients who are formal, systematic, logic-driven thinkers.
And this is how I stumbled upon Dan North's BDD - as a way of reducing the formal use case methodologies (pre- and post-conditions et al.) into a very simple story formulation.
Feature: As a stakeholder, I need a something, in order to meet my goal (High level business requirement - main system "features")
Scenario: Given a starting context, when something happens to change this context, then this should be the result. (Lower-level scenario and low-level "feature" descriptions).
Note: I write "feature" as feature is a controlled word in BDD.
The greater joy of this technique is that it effectively shrinks the distance between what the client says he wants, and what your technical team is capable of delivering back to satisfy these requirements. Why? Well, as this fine blog post points out, it is because this is a business language way of describing states, event triggers and test conditions. Even more importantly, through the use of JBehave or Cucumber with Automated Testing tools like Selenium, your developers can start by writing failing tests for your requirements (requirements-driven, test-driven development), and then - if it is worth the overhead - write automated functional and acceptance tests.
I'm desperate to get this rolling from Business Contact through Business Analyst to Developers and Testers within the company I work at - but I wondered if anyone else has gone ahead and implemented this fully as an end-to-end requirements and development methodology. In the meantime, I'll get my act together and make a couple of posts (when I'm feeling better) as to a few workshop techniques which work nicely for the client-end of BDD.
Originally submitted at O'Reilly
Is your site easy to find, simple to navigate, and enticing enough to convert prospects into buyers? Website Optimization shows you how. It reveals a comprehensive set of techniques to improve your site's performance by boosting search engine visibility for more traffic, increasing con...
Diverse, related topics in one place
Pros: Concise, Helpful examples, Easy to understand
Best Uses: Expert, Intermediate
This is a hugely useful read, particularly if - like myself - you have a range of responsibilities for managing online assets ranging from design, deployment and testing to site promotion and marketing.
Much of the information on each vertical section can be found elsewhere - for instance SEO, PPC and performance optimisation - and individually, each section provides solid information which might not surprise.
The real advantage of this book is that it forces the reader to think of each of the diverse threads as being intimately related in the customer's experience. If you are a UML geek, think of it as an answer to an end-to-end use case (find site, load site, explore site): if you are a marketeer it will expand your horizon in understanding how technical, offpage elements can contribute to satisfaction, bounce rate reduction and improved conversion; if you work in application deployment or support, it will give you some useful pre-launch direction to load and performance testing and gain you brownie points with your Sales and Marketing customers.
So, short order review is that while individual sections on their own may not deliver any surprises to someone with existing expertise, the overall remit of the book will expand the horizons of most who read it.
(legalese)
I've worked for a number of blue-chips for a number of years, and am continually surprised by the fact that - since online is not a primary or secondary revenue base - sensible, value-driven approaches to managing a Web portfolio are few and far between.
Many larger companies play lip service to the concept that the Web is (or can be) a hugely important component in the process of "doing business": they show initial interest (in terms of capital investment) in a couple of pilot projects, and then seem to rapidly lose interest in keeping up with the Internet as a "going concern".
The complexity of stakeholders, risk management, the "agility" of a larger corporation, and - of course - competing (core) investment concerns all play a role in making it difficult to apply a longer-term, strategic programme approach to online activity, and ensuring that this is delivered according to best practices.
Benchmarking helps, but - funnily enough - when speaking to colleagues working in related roles for different companies, I find that this is, in fact, an endemic problem. So this is a call for comment, input and assessment from anyone working in an internet management role where the core product is not sold online, but where the Internet is "considered" a core component of business activity - correct me if I am wrong, maybe share successes and failures, and indicate the righteous path forward...
Having just been working on a project where workforce and audience acceptance of a mix of new hardware, software and content needed to be assessed & tested, I'm keen to find out the best way of gaining a blended system acceptance view without confusing the feedback for the separate elements. I know this should focus on asking precise questions, and directing users to complete specific targeted tasks, but users often seem unable to disentangle feedback in one dimension from another... (usually blaming hardware or software for eveerything). Does anyone have any helpful advice? I must confess that I'm not used to adding the hardware angle.
...just.
Having just logged into Blogger, I now realise that it is only a week shy of a year since I last posted to my blog.
In case anyone is still out there occasionally reading the blog (it's been a while since I checked out the analytics also), the main reason behind this has been moving countries, and then trying to move house.
While this isn't inline with previous post content, I suppose it does count as "information" to be shared: if you are moving to Geneva, make sure you give yourself at least 6 months to find accommodation (unless you are so wealthy, you can gazump the market!). It actually took my family 8 months to be able to move from temporary accommodation into a permanent home - and this was with sizeable local knowledge, friend networks and work & family support...phew!
If anyone is interested in knowing more, leave a comment, and I'll add some detail, otherwise, my next post will be back to normal themes of IA, KM, usability and needs analysis.
Over the past couple of years, I've dabbled around the fringes of agile programming/project management mostly looking at XP, but I have to confess that I've always struggled to reconcile agility and the structured control delivered by PRINCE2. I've always erred towards early, hands-on prototypes (whether paper or digital), prioritised requirements lists, and facilitated, collaborative meetings, so I was delighted to discover that all three of these feature strongly in DSDM. I've now taken the plunge, and am reading (the - so far - excellent) short tome on merging DSDM with PRINCE2, "Agile Project Management" by Keith Richards. I'm starting to come around to the idea that web projects might be ideally suited to a stripped-down mix of the two (perhaps something more PRIDE on the PRINCE2 side). Certainly the inherent difficulties of managing rapidly moving web projects within a PRINCE2 change management framework appear to be addressed by such an approach, as would integrating early and frequent usability tests.
I'm on holiday and paternity leave at the moment, enjoying the French Alps, and learning to live without sleep (I'd love to know when babies biorhythms start to match those of their parents). A couple of days before departing, a colleague in our Human Resources department asked me to deliver a presentation on the corporate intranet (as a communications and knowledge management tool) to our graduate work placement intake...two days into my break.
However, I hesitated to decline as there would not have been anyone to do this in my stead. So, as quickly as possible, I cobbled together a variation of the absentee acceptance common to awards ceremonies ("Kirk Douglas cannot unfortunately be with us today, but he recorded the following message...").
The limiting factors were time and the need for the presentation to be delvered in a known format (as the HR team would be delivering the presentation). However, armed with a couple of pieces of software, a headset and webcam, it was just over an afternoon's work to put together.
I haven't had the opportunity yet to write up my thoughts on KCUK, as my wife and I have been busy with our new son, Theodore, who chose the auspicious date of 07/07/07 to mark his entry into the world.
There are very few "Thristan"s in the world (obviously not including the Christian name), so I think Theodore may take us up to a count of about 15 worldwide.
I will blog on KCUK and other things soon, but in the meantime, may try to catch up on some sleep!
I was over at Ark Group's Knowledge and Content UK this week, along with a colleague, and will try to write up a lengthy post regarding this within the next few days. However, given that it's my wife's due date tomorrow, and she has already been having contractions, it may take me a few days to find time to gather my thoughts and reflections and get them up on the blog.
My presentation went pretty well, although - as I had a graveyard slot - the audience was perhaps smaller than anticipated (but appeared pretty engaged with the discussion on best practice management).
This year's conference seemed generally to mark a refocus on the "people" elements of KM with a healthy dose of social software and Web 2.0 references sprinkled in. I would have liked to hear a few more tactical KM war stories, rather than so many similar strategic approaches, but there were some excellent speakers, and I had some engaging discussions during the breaks.
