Eric Holscher - Posted in 2008

Year in Review

2008-12-31T15:25:24+00:00

Well it’s been a crazy roller coaster year for me. So this post is going to be the typical recap of what’s gone on with my life and my blog over the past year. I’m really happy with where I’m at both professionally and personally, and 2008 has been an interesting year for me.

Last semester and Graduation

It’s kind of surreal to think that at the beginning of this year, I was still a senior at the University of Mary Washington, living in Virginia with some of my best friends in an awesome house. My final semester senior year was a lot of fun, I took very little in the way of course work. I was employed by CACI, which is a defense contractor at the Naval Surface Warfare Center Dahlgren. I was doing Java, Javascript, and a little Perl code for a Navy portal at the base. It was a really fun job socially, but the technology (other than Javascript libraries) was pretty dull.

At school I was finishing up my senior/honors project using Django. This turned out to have probably been the most important decision of my college career (hindsight being 20/20). I went to the National Conference on Undergraduate Research to present the ideas from my senior project. This was a really neat place, and I was exposed to a lot of interesting things other people were doing.

We had a really crazy Primary Election season, which included Bill Clinton talking at my school, which I saw. Obama also later spoke at UMW (His famous in the rain speech), which i would have died to see.

I applied for a couple different jobs all over the country after I graduated. I had phone interviews with Yelp, a Wiki startup, and a couple other places. I interviewed and was offered a job by Zope which randomly is based in the town I went to college in. I also applied at The World Company, the birthplace of Django in the middle of the country, Kansas. I got offered the Jobs at Zope and the World Company, so I had to choose which to pick. As I’ve talked about before, I chose Kansas, and it has all been a blur since. I graduated from UMW.

The epic journeys

I accepted the job right before graduation at the end of April, subsequently quitting my old job at CACI. I arranged to start in Lawrence on July 1, giving me all of May and June to enjoy summer. I had some decent savings and decided to move to Lawrence with no money, and to travel a bunch before I went.

Over those 2 months I took a bunch of different trips. I went to Boston for a week, going to Barcamp Boston, which was the first conference I’d ever been to. I met some amazing people and got really excited about the culture that surrounds the profession that I had chosen. I also just got to tour around MIT and Harvard, met some great people through friends, and just had a great experience.

I also went down to North Carolina, and to the Outer Banks. The Outer Banks are one of my favorite places on earth, and totally recommend them to anyone. They have some of the best waves on the East Coast, and a completely relaxed and beautiful beach atmosphere. I really hit the beach hard because I was moving to KANSAS!

I went to Maryland to a friends late graduation party, and to visit family that I don’t see very often, even less often now that I live in Kansas. I also went all around Virginia, to Nelson County to visit my friend Josh’s house. Charlottesville to see some music and visit friends. Virginia Beach (Home) a little bit to go surfing and visit friends and family. Berryville (where I grew up) to visit old friends and the rest of my family.

So at the end of June, I move out of my house, and leave for Kansas. Great first half of the year.

Lawrence Chronicles

I was in love with Lawrence on the first day. It’s a great town and I love it to death. I moved into a Co-op for July-August so that I could find a place to lease and have an instant social network. The people I lived with were amazing, and it turns out that one of my co-workers had lived there while she was in college! Cool.

The job at the World Company turned out to be amazing, working with lots of brilliant people. On my second week on the job, DjangoCon was announced. It’s really neat feeling like you fell right in the middle of something amazing going on. I had a hunch from afar, but it turned out to be more true than I could imagine.

My birthday was on July 9, and right around my Birthday I was added to Django’s Community Aggregator. This was the first time that my blog had ever gotten more than 20 hits a day (and all those 10+ were when I sent my resumes around). I started getting people reading the things I was writing, and actually appreciating what I was saying. It’s really neat to have a way to talk to people, and have them be excited and listen to what you say.

At the end of july, I released my first open source project, testmaker. This was met with a great response from the community. This is where I really started to appreciate and understand the value of the open source community. I got great feedback, inspiration from comments, and a great dialogue around the project. It is tiny compared to some of the things that people do, but I was floored with the response.

Djangocon was in September and was more amazing than I could have anticipated. I gave an incredibly nervous lightning talk (having broken my demo 5 mins before I went on, and fixed it). I learned so much, got to meet some amazing people, and had lots of fun. I see now that I didn’t do a writeup post, which is sad.

November was post-a-day month that was a lot of work but very rewarding. I did it with a lot of other people in the community and I think it was a great effort and it worked out really well.

December was really laid back. I started a couple more projects which are going to be getting some love in the new year. I went to Jamaica on vacation, and went back to Virginia to visit friends and family for 2 weeks.

Wow

A lot of things have happened this year, and I’m grateful for where I am and what I’m doing. It’s been an amazing ride, and I can only guess as to how 2009 will be. I’m sure it will be another great year, and things are only looking up. I want to thank everyone for reading my blog, and I want to wish everyone a happy new year full of blessings and insights.

Happy new year!!

Starting a Django Conventions Project and Reference

2008-12-03T19:45:39+00:00

During the last month I have proposed some conventions for Django, mostly in the realm of templates. In doing so I have looked around for other documented places where conventions are mentioned. I haven’t found a really good reference for Django conventions. Brian’s post was a good example of reusable app conventions, and the Pinax Project is a great reference implementation. However, I couldn’t find any simple reference for regularly used conventions in the Django world.

I don’t know if this will be useful for people, but I think this goes along the whole convention/pattern ideal. If we all use a common naming, syntax, and style in places where they can be arbitrary, then we gain a lot of value of being able to understand whats going on in others code. So I have started a project that hopefully will act as a reference for Django Conventions.

Currently it is pretty sparse, but I think that having that document in any form is a great step. I’d love to hear some feedback, and it needs a lot of work, so feel free to email me or leave comments here with your additions and criticisms. If this idea becomes useful, I would be fully in support of including it in the Django Documentation or something along those lines as well, but I don’t know how “official” this will really be. For the moment just consider it my hair brained idea of how things should be done :) Cheers.

Post a day in review

2008-11-30T17:29:05+00:00

It’s the end of the Post a day for a month. I did pretty well, but fell off about 3 weeks in because of work. First some stats.

Post stats

In [4]: Post.objects.published().filter(publish__year='2008', publish__month='11').count()
Out[4]: 23L

In [10]: for post in posts:
    cont = post.body.split()
    sum += len(cont)

In [13]: sum
Out[13]: 18517

In [14]: sum / 23
Out[14]: 805

This doesn’t really mean much, because it is simplistic len(body.split()), but it shows that I have been writing a ton over the past month. I have also gotten a ton of stuff done. I have re-written 1 project, started another, and put out some ideas into the community.

The above stats basically mean I posted 24 times (counting this one), averaged 800 words a post (with code examples probably inflating that)

I only missed my first day about 3 weeks in, and that was because of work. I was working non-stop trying to launch our main websites at work on Django 1.0, and just didn’t have enough time (energy really) to do anything else. For Thanksgiving I was also up visiting family in rural Ohio for 4 days, so I didn’t have an internet connection there, which made posting hard.

Traffic stats

Analytics stats

The day after that big spike I launched my redesign, so there are probably around 1,000 hits missing from that. I got around 30,000 Page views and 17,000 Unique visitors.

Pros and cons of post-a-day

Pros

I have certainly enjoyed doing this. It has been a neat personal challenge, and I think that the quality of my posts hasn’t really suffered. If anything, it has stayed the same, and I have just been posting more frequently. I had a couple of “cop out” posts (like this one), but they never really seemed to be much less popular than some of the ones I put some time into.

Having to do a post a day makes you do a lot more! You accomplish so much because you need something to write about. I think that this is probably the biggest advantage to doing post a day. You’re forced to do something interesting each and every day, which is something that more of us should be doing.

I also think that it’s interesting what kind of content you end up writing. I have done a lot more tutorials and things like that. I have found them to be easy to write, and really valuable for people to use.

Cons

You write blog posts instead of doing things! I spent a ton of time writing instead of coding. A lot of my posts took around an hour or more to write, so that’s a lot of time spent. However, I think that this is a good thing for the open source community, since the amount of documentation versus code produced is really unbalanced.

I really wanted to review some major django reusable apps and write up howto’s and screencasts for them, but this proved to be really time consuming. So doing a post a day really limits your drive to do longer blog posts (because you have to do one again tomorrow!).

After about 2 weeks I agree with other people, where they say it turned from being fun into a burden. Not a huge burden, but it was enough stress (along with all my other real life stuff) that it was annoying. I missed a bunch of days at the end for this very reason.

Reflection

I’m really glad that I did it. I broke down somewhere through, but I still feel that I accomplished my goal of posting a lot of good content, and getting shit done. I am so happy that the month is over, and that Ellington is now running on Django 1.0. My life has gotten a lot less stressful. I will be taking a lot of time off in December, so this blog will be a bit more quiet :)

Going forward, I will try and post at least once a week, and hopefully some more screencasts and longer form content. I think that the kind of content that was produced during this shows what’s hard and what’s not. Simple tutorials are great for things you know, but doing the research to do a screencast (that doesn’t suck) or other kind of content like that takes a lot of time!

Hope everyone enjoyed these posts, and I’ll try and keep up.

The value of conventions, aka testmaker for template tags.

2008-11-27T05:00:00+00:00

A couple posts ago, I talked about how we should have conventions for the names that we use in Django Template Blocks. Today I will be talking about the value that is gained from this kind of structure.

Use Cases

Template Tags

My use case for Template tags is what started me thinking about this. Some of you may know that I have created a testmaker application for Django. This allows you to automatically test your view code, based on a browser session. Once I got most of the kinks worked out in this code, I started thinking about what the next best thing to test would be. I came up with template tags…

This is where I ran into a problem. With no context associated with a template tag, there is no way to create a tool which tests template tags well. At first I simply started out trying to test the template tags by pulling them out of the template verbatim.

{% load blog %}{% get_latest_posts for blog.post as posts limit 10 %}

However, when you try and test this, it doesn’t work. That is because all this code is doing is settings a context variable, and not outputting anything. You can create tests for trivial template tags that just output a string, but a lot of template tags set context variables. So without some kind of convention here, it is impossible to write a tool that will automatically write a test for you. That sucks!

Luckily in Django, the above test is representative of a kind of convention in django template tags. Most template tags use the syntax as [context_var] to set a variable in the context. So I went ahead and wrote some code that parses template tags for these kind of strings.

This code is valuable for some people, but is worthless if people use another syntax for defining context variables. This I think is a really good example of where syntax (or convention) allow you to do more than you previously could.

You can take a look at the source code here. It’s still a bit rough, like most of my first releases it is more of a proof of concept.

Template Blocks

So if we create a convention for Template blocks like I proposed in my previous post, this gives us some really neat possibilities. We can now create a base template that “knows” what will be included in each of it’s sections. So in turn we create a way to provide skins or themes for Django Sites, that would be portable between Installations.

Of course, how far we take these conventions will limit how portable, powerful, and easy to replicate the designs will be. If we say that all items in a menu block have to be <ul class=menu_item>, then we can provide more functionality in our portable base template. This is a bit too specific though, because not all menus are lists. However, even with just a simple structure around your base template, you can create some really nice portable templates. You can create 1 and 2 column layouts, simply based on where the menu, content, header, and footer are for example.

I think it will be interesting seeing where we can embrace conventions where possible, for the betterment of all. I think that having Django Skins would be really neat :). Also, having tests automagically generated for template tags is a big win. For no other reason than because it does the boilerplate stuff for you.

Other places

I think that there are more places where conventions could benefit us. I think I’m going to create a section in my projects on this site dedicated to conventions for Django. Hopefully serving as a reference for other people who are trying to use conventions in their Django apps.

Testmaker 0.2: Rewritten and improved

2008-11-26T20:41:05+00:00

About a week ago, I went ahead and re-wrote testmaker and moved it into my django-test-utils project on github. The syntax is now a bit different, and the whole thing is much improved. This is version 0.2. The screencast from the last release still shows the gist of the project, except for the changed syntax.

Also note that my projects have permanent pages for documentation over at my projects page. This will stay up to date with the most current version of the software, and basically be a copy of this post for now.

Testmaker

What is does

Django testmaker is an application that writes tests for your Django views for you. You simply run a special development server, and it records tests for your application into your project for you. Tests will be in a Unit Test format, and it will create a separate test for each view that you hit.

Usage

Step 1: Add test_utils to your INSTALLED_APPS settings.

Step 2:

./manage.py testmaker APP

This will start the development server with testmaker loaded in. APP must be in installed apps, and it will use Django’s mechanism for finding it. It should look a little something like this:

eric@Odin:~/EH$ ./manage.py testmaker mine
Handling app 'mine'
Logging tests to /home/eric/Python/EH/mine/tests/mine_testmaker.py
Appending to current log file
Inserting TestMaker logging server...
Validating models...
0 errors found

Django version 1.0.1 final, using settings 'EH.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Then, as you browse around your site it will create unit test files for you, outputting the context variables and status code for each view that you visit. The test file used is in APP/tests/APP_testmaker.py. Once you have your tests written, you simply have to add them into your __init__.py, and then run your tests.

Step 3:

./manage.py test APP

Things to notice

This fixes a lot of complaints that people had about previous versions of test maker. This allows you to test apps that are anywhere on your Python Path (and in your INSTALLED_APPS), which makes life a lot easier. Each view also has it’s own test name, which is a slugified version of the request path and the time when you hit it (because I needed something unique :)) You also may notice that there is rudimentary support for template tags; this will be explained upon in my next post. However, for now know that it only works for template tags that don’t set a context variable, or use the format as <context_var> to set one.

Improvements over 0.1

Each page request is in its own test, for easier debugging
It will append tests if your APP_testmaker.py file already exists.
You can now test admin views
POST support is improved
The code is cleaner and more readable
Git!

Options

-f –fixture

If you pass the -f option to testmaker, it will create fixtures for you. They will be saved in APP/fixtures/APP_fixtures.FORMAT. The default format is XML because I was having problems with JSON.

–format

Pass this in with a valid serialization format for Django. Options are currently json, yaml, or xml.

–addrport

This allows you to pass in the normal address and post options for runserver.

Future improvements

Force app filtering

I plan on having an option that allows you to restrict the views to the app that you passed in on the command line. This would inspect the URLConf for the app, and only output tests matching those URLs. This would allow you to fine tune your tests so that it is guaranteed to only test views in the app.

Better test naming scheme

The current way of naming tests is a bit hackish, and could be improved. It works for now, and keeps names unique, so it’s achieving that goal. Suggestions welcome for a better way to name things.

Improve template tag testmaker

It is a total hack at current, but it works. Certainly a first, rough draft.

Django Aggregator v2 now has tagging, and you should too.

2008-11-22T16:09:35+00:00

I have been doing some more work on my Django Community Aggregator / Django People v2 project. A big feature that I want to incorporate is tagging. I want people to be able to sort data by tag, among other things. I think that this is a pretty killer feature.

This allows someone to say “I want to get all of the data about testing or debugging that the Django community is doing”. However, if nobody is tagging their posts, then only services that provide tags will be available in those views. A lot of people are using django-tagging on the backend of their blogs, but they just aren’t exposing that data in feeds.

Note: Yes I know the data can’t be edited yet (on the aggregator). That is because it is a project that is just living on my site for the moment. Once it gets moved off and the Uber community of Django gets more off the ground, all of those issues will be solved.

Luckily, it is really easy to expose your tagging data in your Django feeds. This assumes you are using Django Tagging, however, it’s really easy with anything else.

Say we have our feed class that looks like this.

class BlogPostsFeed(Feed):
    title = 'My awesome blog'
    description = 'My awesome blog"

    def link(self):
        return "http://mysite.com"

    def items(self):
        return Post.objects.published()[:10]

    def item_pubdate(self, obj):
        return obj.publish

That is a pretty basic feed, but much akin to what most people have. Now lets add some tagging in there! Assuming that you have the Tag model imported from tagging, you can simply do this:

def item_categories(self, obj):
    return [tag.name for tag in  Tag.objects.get_for_object(obj)]

You can test to make sure that your feeds are working by using feedparser

In [1]: import feedparser

In [3]: p = feedparser.parse('http://ericholscher.com/feeds/posts/')

In [4]: p.entries[0].tags
Out[4]:
[{'label': None, 'scheme': None, 'term': u'lawrence'},
 {'label': None, 'scheme': None, 'term': u'mediaphormedia'},
 {'label': None, 'scheme': None, 'term': u'philosophy'},
 {'label': None, 'scheme': None, 'term': u'post-a-day'},
 {'label': None, 'scheme': None, 'term': u'ramblings'}]

That’s it! Now everyone go do that to their feeds, so that I can harvest your tags and make them useful :)

Luck and a New Life in Lawrence

2008-11-21T19:58:49+00:00

Note: This isn’t a technical post. If you don’t want to be getting posts like this, you can sign up for just my Django feed. This is my personal blog, so stuff like this pops up from time to time :).

Most people believe in luck. If you believe in luck, presumably the chance of luck happening is 50/50 on the side of good or bad luck. Each theoretically has an equal chance of happening, if luck is an abstract quantity.

However, a big part of luck is being in the correct position to embrace it. There are a lot of lucky breaks that people have encountered that they have said ‘no’ to. Even more where they could have had an incredibly lucky thing happen but it just wasn’t right. There are a lot of people who say that they have bad luck, but perhaps they aren’t setting themselves up to be able to be lucky.

To take a personal example, I feel incredibly lucky to be where I am at the moment. There is not a lot of luck involved in it really; I did a lot to get where I am. First off, I had to do a lot of work by myself in college. Nobody taught classes in Django or anything like that. I was incredibly lucky (in the real sense) to have an adviser and professor who was amazing. He taught a Perl/Python class, an Ajax class, and lots of other great classes that have contributed to my knowledge. But if I hadn’t taken those classes and seized the opportunity to learn about web development, I wouldn’t be here.

The next big step was moving to Kansas! From Virginia, by the ocean, having lots of friends, working in the same town I went to college in, for a Python shop. That was the offer that I received after college…Or move to Kansas and work for a Newspaper of all things! Doing tech at a newspaper, how horrible…But this was no ordinary newspaper, and this wasn’t Kansas. It was Lawrence, a long time stronghold for liberals since the Civil war. It was the newspaper that invented Django, and was one of the first to integrate the newsroom. A great place to work and a great place to live.

Plus I had to be in a place in my life where I could up and move. Had I had a girlfriend or some other commitment then I probably would have stayed. There are a million things that could have kept me from achieving what I know I should. From fear of the unknown, being a thousand miles away from any family and a beach, to many other things. But I knew it was the right thing to do, for my career, and for my personal growth. That was it, and it was decided, but it certainly wasn’t easy, and a miraculously lucky event didn’t just fall into my lap. It was brooded over many a night and weighed against the easy and obvious. Who knows what kind of Luck I would have had, had I chosen the other path?

Speaking of moving to Lawrence, it’s amazing how a change in life (moving, new job, new friends, new everything) sends one’s mind thinking into the depths of existence. Ever since ending up in Lawrence without any old friends and lots of time to think, I’ve been re-evaluating a lot of things in my life, and my mind has been working overtime.

Upon dramatic change in life simple assumptions no longer hold true. I get to choose my entire life all over again. Do I want to keep the same personality, same type of friends, same type of lifestyle; or do all of these get changes (for the better, or for the worse). Who knows, but it will be a hell of a ride trying to figure it all out. And I’m going to enjoy every second of it, because that’s all I can do.

I have a great new group of coworkers that I have been spending a good amount of time with. Good people, and they have a lot of similar interests. My co-workers have an amazing depth and breadth of geek knowledge, while managing to maintain a social ability that is above par for a lot of geeks. It is quite impressive and says a lot about the town and people of Lawrence that they are able to keep such quality programmers employed, inventive, happy, and productive.

I think that progressive places have always been the breeding ground of great ideas. The company that you keep says a lot about you, and a town with such progressive and forward-thinking ideas and ideals about the way things should be; allows us to simmer in the creativity that abounds in many forms.

I was having a conversation with a new-found friend the other day. He was talking about the brilliance of the people in Lawrence, about how you can’t think less of people. A simple example was that when we were eating he mentioned the server of our food was an amazing guitarist. In fact, we talked to him about it and apparently he was playing that night at a venue downtown.

In most situations and other places that I have lived, I tend to assume the worse of people. “People tend to suck” is one of my phrases that I say. Lawrence really gives me an appreciation of the ability of my common man, and the fact that they are impassioned and striving for something (anything) is highly inspirational. Surrounding yourself with people that are passionate about anything is a great way to develop passion within yourself.

Is it lucky that I’ve ended up in such a cool place. Or is it because it is such a cool place that I moved halfway across the country to live and work here? These are the kinds of things that I have been pondering as of late…

Now back to your regularly scheduled geekery.

Gentlemans agreement on Django templates

2008-11-20T20:24:01+00:00

There are a lot of reusable apps out in the Django Ecosystem. I wrote a previous post about why I think that reusable apps should come with templates. There is a problem about distributing templates that I want to address with this post: the problem of Django Template Block names.

There are already some unwritten conventions in the community in regards to block names, and I think that talking about it will help. I don’t think that we’re going to be able to come up with a way that everyone will follow, but I think it would be nice if we could create a way to easily redistribute templates.

The main reason that I have been thinking about this is because of Pinax, they use some different template block name than my apps. So in order to use PInax and my app, I needed to change all of the blocks of my templates! That is a lot of work that could have been avoided by some standardization.

There are a lot of different ways to think about the content of a page, but I’m going to propose some basic template blocks that most pages will have, and then talk about some more ‘extended’ blocks that might be useful.

Blocks we need.

{% block title %}

This will be the block where you define the title of the page. Presumably your base.html will define your Site’s name (perhaps even using the Sites framework) outside of this tag, to be places on all pages.

{% block extra_head %}

I think that this is a good one that most people are already using in some form or another. In your base template you have a set of things in your <head> that every page will have. However, a lot of other pages need things that they also want to put in the head of a document, like RSS feeds, Javascript, CSS, and all the other things that should go in the head. You can and probably will have other specialized blocks (like title above) that will fill in other parts of the head too.

{% block body %}

This tag will be placed around the entire body section of the page. This allows you to create pages in your app that replace the entire page, not just the content. This won’t be used a lot, but it’s a really handy tag to have when you need it. If you haven’t noticed, I’ve been trying to keep tag names consistent with their html tag names whenever possible.

{% block content %}

This will be the place where you define the content on a page. This will presumably change on every page. It will not include any site navigation, headers, footers, or anything else that would belong in a base template.

Other possible blocks

{% block content_title %}

This would be where the “title” of a content block would be. It includes the title of a blog. It can also include some kind of navigation between content, or other things like that. Presumably something that isn’t the main pages content. I don’t know if this should go inside the content tag and have a main_content as opposed to the content tag proposed above.

{% block header %} {% block footer %}

Any text area in the header of footer that might change on a page-by-page basis.

{% block body_id %} {% block body_class %}

This would be used to set the class or id of the body tag in the document. This is useful to set for styling and other properties.

{% block [section]_menu %} {% block page_menu %}

This would be opposed to the menu block proposed above. It would be for the section or page.

Edit: Updated back to include _’s. Because I think thats more pythonic and looks better. The Django Admin isn’t meant to be a reference implementation of the templates.

A lot of these ideas have been taken from Nathan and his base.html for basic-blog. I’m sure that he and Christian have put way more thought into this than I have. I’m just curious what people think, and if there’s something crazy that I have missed..

Busy Busy

2008-11-17T18:42:55+00:00

So at work since I started for Mediaphormedia, currently World Online, and the birthplace of Django, I have been tasked with porting Ellington. Ellington is the CMS that we create and sell, and is what Django originally was. Django was pulled out of Ellington and Open Sourced.

So when I got here, my first job was tasked with porting Ellington. We have a version running on Revision 1290 and .91. Aka, really damn old, pre-magic removal old. We were tasked with porting this to Django 1.0 (which is around revision 9300). That is a whole 8000 source code revisions, and 600% more revisions than the base. That is a whole lot of code.

So today at work, we are launching our 3 main sites; Ljworld, KU Sports, and Lawrence.com. These will be running all on Django 1.0, which is a monumental task.

That is the reason today’s post is short. Was bug fixing all day, and I have to be up at 5am to go in and put out the fires that will surely happen once users start hitting the site.

I will have an updated post afterward about the experience.

A start to the uber community

2008-11-16T06:34:57+00:00

Well I spent all day Saturday, and all night. Into Sunday morning hacking on some code. Probably the most productive 24 hours of my life. I have a couple of announcements, but in the spirit of post-a-day, I’ll spread them out over a couple days :).

The big one, is that I basically wrote an entire Django application last night. You can check it out over here. It is basically an aggregator for the Django Community Feed. I seeded the data with the people who were on Django’s Community Feed, and then I grabbed as much of their social networking information as possible.

All of this code will be shown at some point over the next couple of days. However, I don’t have the energy to write it up quite yet. However, please play around with the data, there’s some really neat possibility in there for something cool…

At the moment there is..

A river of data for every user, all of their services
A river of data for every user, for each service
A river of data for each service for all users combined
A river of data for all services for all users combined
Atom feeds for all of the above (it says RSS but I lied)
A permalink to every item a user has
A profile page, listing each users username at each network that I could find.

Feeds should be updating hourly, but I haven’t tested them. This model is currently pulling data, and will always have to for some data. However, I plan to be open for pushing as much of this data as possible. Most people have tumblelogs on their sites, so it would be pretty easy for them to push all their data in, with more metadata than I can apply from outside.

I’d love to hear some comments, feedback, and ideas for future directions. With a solid OpenID server and distributed identity, I think that we could really make something special.

Note: I also added the ability to combine (only) 2 tags in the user and everyone views. See http://ericholscher.com/django/river/friendfeed+twitter/ and http://ericholscher.com/django/profile/Eric%20Holscher/friendfeed+twitter/

PPS: If your info isn’t showing up in your page. Add some rel=”me” links to your profiles on your blog’s homepage. Person profiles get updated daily.