(disqus.com/people/tommorris)

tommorris

• Show comments:
• From tommorris
• From people tommorris is following
• From Everyone

• 

  • tommorris  There *is* a divide between the BusinessWeek types and developers. SXSW is predominantly a developer conference - all the people I know there (with the exception maybe of Scoble) are designers, web developers, software developers, W3C staff/standards people and so on. The reason developers go to SXSW is because they can't stand the self-serving nonsense that goes on at Web 2.0 and similarly over-priced VC fodder. Just as a complex discussion of tech standards or APIs would be inappropriate at an event for VCs and business types, BusinessWeek questions aren't appropriate at a developer/geek event.
  • • 4 months ago
    •   Interview with Scoble (Scripting News)
    •   Scripting News
  •   Jake McKee  Tom, there may be a "divide" but to say that the 8000 person strong audience at SXSW is just "developers" is ill informed, to be honest. If we're going to play the "all my friends are ______, therefore that's how it was overall" game, then SXSW was made up of developers AND authors, videographers, writers, designers, artists, strategists, and community folks.
  • • 1 point
    • 1 reply

  

  • tommorris  Amend 'RSS feed' to 'RSS feed and API' and it's a very important point. Significant amounts of drama has been heaped on situations where people have used the API in ways that photographers don't expect - see this thread on flickr.com - http://www.flickr.com/help/forum/50508/ It'd be helpful if the people who run sites like Flickr and Twitter (etc.) could actually inform their users that people will build mashups, software and services that reuse their content in ways they might not expect.
  • • 6 months ago
    •   Recommendation for Flickr (Scripting News)
    •   Scripting News
  • • 1 point
    • 0 replies

  

  • tommorris  Dave, one thing that's made me love programming again is unit testing. It avoids the "morass of patches and workarounds" to some extent. Google 'test-driven development'. The idea is really simple. You write a test that determines whether or not a function, method or class works properly before you write the code. Then you run the test, see that it fails, write the code and run the test again. You know that the code works when the test works. Then as you build the system bigger and bigger, you can keep track of whether one piece breaks another piece, because your tests show you that. I haven't done much with Frontier for a while - I've been using Python and Ruby which have unit testing frameworks, but it'd certainly be interesting to see if a Frontier/UserTalk testing framework could be written.
  • • 7 months ago
    •   Programming less (Scripting News)
    •   Scripting News
  • • 1 point
    • 0 replies

  

  • tommorris  Kosso: if you want to build a Semantic Social Multimedia Network, I'd suggest you simply publish XML or HTML and use GRDDL to turn it into RDF. It's quite simple, and useful. I'll be giving a talk about it at BarCamp this weekend, and there should be slides, examples and maybe even audio of the talk soon afterwards.
  • • 8 months ago
    •   Newspapers and url shortening (Scripting News)
    •   Scripting News
  •   kosso  yup. RDF looks useful. But it also look complicated. (Or at least more than an idea I have) Best thing about RSS is the 'Really Simple' bit. Easy to 'get' I already have a Semantic Social Multimedia Network' :) - podcast.com it's 'treedia' (but only for audio/video podcast feeds on that domain) one day treedia will support every file type in the world - shame it won't be based on OPML though (now) :) I'm really impressed with the stuff you've done Tom ;)
  • • 1 point
    • 1 reply

  

  • tommorris  Cool URIs don't change, and are well-designed. That's why "twitter.com/davewiner" is a better URI than "twitter.com/user.php?u=1234191723647ff848318273773af9". Shame the vendors didn't do that when designing the CMSes of yester-year. Oh well. In an ideal world, short, well-designed, persistent URIs would be the norm. Until then, URI shorteners will exist. An alternative is to not put all one's URI shortening into one basket - have a simple API which would be available in all frameworks (REST, XML-RPC, SOAP/WS, JSON, Flash etc.) which would take a URI and farm it out to a random provider and return that. Decentralise and distribute the blast so a future TInyUrl would be less problematic. Of course, using short, well-designed URIs would solve the problem in the first place.
  • • 8 months ago
    •   Solving the TinyUrl centralization problem (Scripting News)
    •   Scripting News
  • • 1 point
    • 0 replies

show all comments +