ade is currently certified at Journeyer level.

Name: Adewale Oshineye
Member since: 2002-07-06 12:55:15
Last Login: 2010-01-02 17:07:17

FOAF RDF Share This

Homepage: http://www.oshineye.com/

Notes:

I program mainly in Python and Java.

I'm currently playing around with an RSS/Atom aggregator called Aggrevator, a code duplication detection tool (which I inherited from the original developer) called Same and a Wiki called KwikWiki.

I use delicious to track and organise the my wanderings through the noosphere. http://del.icio.us/ade is a window into the contents of my mind.

My interests revolve around:

  • Wikis
  • Syndication i.e. RSS, Atom and Atom Publishing Protocol
  • Large scale collaboration
  • Modelling complex financial instruments
  • Software system longevity
  • Collaborative filtering, trust metrics and reputation/recommender systems
  • Photography
  • Go
  • Software Craftsmanship
  • The views expressed on these pages are mine alone and not those of my employer. Just in case there was any doubt.

    Projects

    Recent blog entries by ade

    Syndication: RSS 2.0

    Implications of being post-PC

    At last night's OSJam I gave a lightning talk about the implications of being post-PC.

    Those implications were:
    Identity: a post-PC device needs to know its owner's identity since it can't rely on obtaining that information from a PC. At the moment all the devices are building their own identity platforms but eventually they'll start to take advantage of existing identity systems like Webfinger and PGP.

    Personalisation: a post-PC device can be uniquely personalised because it's not predicated on the idea that it will be a shared device. The classic example is the experience when you buy a Kindle from Amazon. It will be preconfigured with your name and the books you've already bought. It's a small step from there to a future where the moment I bought a device in a shop it would automatically know that it belonged to me.

    Kindle personalisation

    Cloud: post-PC devices tend to be heavily dependent on the cloud in order to store persistent state and to perform sophisticated processing. The definition of the cloud that this implies comes from Simon Meacham. He says that the cloud means treating the union of all those servers/networks/services as if they were one machine available to be used by everybody. In this vision the physical devices we own are merely portals to and caches for this metaphorical "one machine."

    Mobility: if our data and services live in this cloud then all the devices I can log in to are equivalent. At this point the ability to take a device to the place I wish to use it (for instance the Kindle screen is supremely legible in bright sunlight unlike the screens of most mobile phones) and the fact a given device is ready-to-hand will trump all other considerations. Photographers have long had a saying "the best camera is the one you have with you" and the rest of the world will soon experience something similar.

    Devices: new kinds of devices become possible, if not inevitable, in a post-PC future. Technology will migrate to the most convenient form and place in your life. That means computers, cameras and music players will start becoming features of watches, jewelry and clothing. That's partly because people actually like their watches, jewelry and clothing whilst they mostly tolerate their computers. The early examples of this are Nike+ and the increasing variety of smart watches. In fact several of the people attending OSJam were wearing the precursors of the smart watches of the future. Furthermore once people stop expecting technology to be delivered to them in a beige box it opens the doors to new innovators such as Arduino enthusiasts and the open source hardware community.

    From OSJam 19 - Post-PC: gadgets of the now

    Personal Area Networks: The logical culmination of this is the personal cloud or personal area network. This is not merely a network of devices that are physically close to one person. Instead it is a network of devices that are geographically distributed but which can connect to each other (via a variety of networks and protocols including Tthe internet, wifi and bluetooth) and prove that they belong to the same person. The devices are tied together by the fact that they belong to a single person and therefore they can seamlessly share each other's functionality.

    These are merely my guesses about what's likely to happen as a consequence of these post-PC devices. Ultimately Alan Kay is right: the only way to predict the future is to invent it.

    Syndicated 2011-07-29 22:03:00 (Updated 2011-07-29 22:03:45) from Ade Oshineye

    What is #devexp?

    Developer Experience (#devexp) is an aspirational movement that seeks to apply the techniques of User Experience (UX) professionals to the tools and services that we offer to developers. Developer Experience can be boiled down to 4 main ideas.

    Lab

    1. Apply UX techniques to developer-facing products.

    These techniques and ideas include:
    • Personas
    • Lo-fi prototyping and sketching
    • Usability testing by watching people try to use your products without interfering so that you can get a realistic understanding of how people will actually respond. Some companies set up usability labs or run hackathons in order to get this kind of data.
    • A wider range of techniques from UX research practitioners
    • GOMS

    2. Focus on the '5 minute Out Of Box experience'

    The idea here is that if you provide a library, developers should be able to go from downloading to "Hello World" in 5 minutes. You should test this with a stopwatch or even a screencast to prove this is possible. Ideally they should then be able to take the code from this 5 minute experience and evolve it as their requirements grow in sophistication without having to start over. Making a library that supports the same user from unsure novice to sophisticated expert is hard but pays off in terms of increased adoption and fewer questions on the mailing list.

    3. Use convention over configuration

    This was most clearly stated by the Ruby On Rails community but is rooted in a simple insight. When someone first starts using your API or library they have the least knowledge so that's the worst time to ask them to make lots of complicated decisions with far-reaching implications. This is why you, the developer of the library or API, should make the initial decisions for them by establishing conventions that can be overridden with configuration options.

    4. Try to "design away" common problems rather than documenting workarounds

    For instance if your users struggle with getting OAuth working then create abstractions that handle it for them rather than documenting the 6 most common problems or writing up the 'simple 12 step process' for getting it working.

    This is inspired by Don Norman's work on perceived affordances which says that things should be designed in ways that immediately suggest how you should use them. If you walk up to a door it should be obvious without reading any signs, whether you should pull, push or slide the door to open it. If the door needs to be documented with a sign then it was badly designed.

    This theory of affordances applies just as well to developer tools and APIs. They should be designed to have affordances that encourage correct usage rather than documented to make up for deficiencies in usability.

    Push Pull


    The phrase (developer experience) and the hashtag (#devexp) comes from Michael Mahemoff but it's not a new idea. Its roots are in ideas and practices such as:
    It's a set of ideas we would like to see more people, projects and companies adopt. We don't claim to be paragons and we're looking to learn from other people's examples.

    That's why we've set up http://developerexperience.org/
    We hope to use it to point to examples of great developer experiences as well as aggregating relevant tweets using the #devexp hashtag.

    Please join us. You can start by using the tag "devexp" whenever and whereever you write about developer experience. Over time this will help us build up a body of knowledge that will do for developers what UX has done for users.

    Add comments on Buzz

    Syndicated 2011-05-08 12:55:00 (Updated 2011-05-08 13:00:22) from Ade Oshineye

    The irony and the tragedy of OAuth scopes

    Overly broad permissions

    I was taking a look at my PeerIndex profile when I got the above screen. I was surprised since the button I clicked said "sign in with Twitter" and didn't mention anything about updating my data. I did a little digging and it seems that I'm not the only one who has this reaction.

    In my case it was especially ironic since one of the things that I've been trying to do with the Buzz APIs is encourage developers to ask for the minimum set of permissions that they need.

    The idea is that an app which is just going to use its access to your account to gather metrics shouldn't also be able to post messages on your behalf. That's why we expose 3 different scopes. These are read-only, read-write and a special scope for photos because those tend to be especially sensitive.

    However developers will often just ask for the maximum set of scopes in order to give themselves the freedom to implement new features later on without having to ask the user to re-authorise them. They do this because it's easier for them and because they believe it results in a better user experience since the user isn't constantly being asked to give permission.

    Unfortunately what many developers don't notice are the users who get to the authorisation screen and then close the tab because they don't understand why your app needs write-access to their account. The point is that asking for overly broad permissions, just like the password anti-pattern, repels users.

    In the case of the Twitter API the problem seems to be that any HTTP POST API call is considered a write and so services like PeerIndex end up needing to ask for read-write access even though they're well-behaved.

    The tragedy is that all parties are trying to create the best possible user and developer experience (by avoiding complicating the user interfaces with lots of options and removing the need to constantly ask the user for new permissions) but the end result is bad for all concerned.


    Add comments on Buzz

    Syndicated 2011-03-29 11:34:00 (Updated 2011-03-29 11:37:13) from Ade Oshineye

    27 Jan 2011 (updated 16 Feb 2011 at 13:18 UTC) »

    Release 5.0 of Universal Feed Parser for Python

    We've made a new release of the Universal Feed Parser. The new version is 5.0. It fixes dozens of bugs and adds backwards-compatible support for Python 3.

    Over the last 5 years since the last release we've worked our way through lots of obscure corner cases in specifications like Atom, RSS 2.0, and RDF so that you don't have to. If you're writing anything in Python that parses any kind of feed then you should definitely be using this.

    Our official announcement is here. Enjoy.


    Add comments on Buzz

    Syndicated 2011-01-27 18:36:00 (Updated 2011-02-16 13:05:01) from Ade Oshineye

    63 older entries...

     

    ade certified others as follows:

    • ade certified ade as Apprentice
    • ade certified rossigee as Journeyer
    • ade certified RhysJones as Apprentice
    • ade certified danf as Apprentice
    • ade certified dotSphinx as Apprentice
    • ade certified pabos as Apprentice
    • ade certified mwh as Master
    • ade certified jdybnis as Apprentice
    • ade certified cmiller as Journeyer
    • ade certified ploppy as Apprentice
    • ade certified cm as Apprentice
    • ade certified robocoder as Apprentice
    • ade certified mjw as Journeyer
    • ade certified Sunir as Journeyer
    • ade certified duncan as Journeyer
    • ade certified apm as Journeyer
    • ade certified mx as Apprentice
    • ade certified pfremy as Apprentice
    • ade certified azz as Journeyer
    • ade certified nat as Journeyer
    • ade certified dwragg as Apprentice
    • ade certified awu as Journeyer
    • ade certified demoncrat as Journeyer
    • ade certified clarkbw as Journeyer
    • ade certified shapr as Journeyer
    • ade certified benno as Journeyer
    • ade certified ged as Journeyer
    • ade certified timbacon as Journeyer
    • ade certified tcopeland as Apprentice

    Others have certified ade as follows:

    [ Certification disabled because you're not logged in. ]

    New Advogato Features

    New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

    Keep up with the latest Advogato features by reading the Advogato status blog.

    If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

    X
    Share this page