More code checked in. Prototype to be available this weekend (hopefully)

[Jason Stirk]

Howdy folks,

Things have died down a little huh? I'm almost expecting a tumbleweed
to roll past in here!

I've been nursing a server migration tonight, of which the up side has
been that I've been chained to the desk with time to kill. So, I've
just checked in more code for the DB prototype that I started.

It now processes education and experience information, and stores geo
information if anyone includes it in their hCard.

Whilst I've tried to follow the hResume spec. as much as possible,
I've only actually tested against LinkedIn profile pages thus far.

I've also hacked together a very, very primitive web interface. I hope
to have that hosted in some form over the weekend. It will give folks
the ability to register their resume with the system, and view some of
the data it spits out. I figure that by doing that we can start to
collect a variety of hResume pages which we can verify the code
against.

Speaking of verifying the code - if anyone wants to cast their eyes
over what's in github, I'd be very much obliged. So far it's been very
much hacked together as a prototype / proof-of-concept, but any
comments will be valued.

Code is available at http://github.com/jstirk/silicon-beach-database/tree/master

I'll drop another post once there's something there to see.

All the best,
Jason Stirk
http://griffin.oobleyboo.com/
http://twitter.com/j_stirk

[Jason Stirk]

Hi again,

As promised, I've deployed the current code. You can have a play at
http://sbdb.oobleyboo.com/

Thanks to Rob (quannum) who added in a few files and directories I'd
missed. Thanks to him the code on github should now run out of the
box.

Please feel free to register your resume URLs. New resumes should be
fetched every 5 minutes, so you shouldn't have to wait for too long to
see some data.

If you notice your resume is horrendously broken, give me a shout so
as that I can check it out.

Cheers,
Jason

http://griffin.oobleyboo.com/
http://twitter.com/j_stirk

On Aug 23, 2:17 am, Jason Stirk <jst...@gmail.com> wrote:
> Howdy folks,
>
> Things have died down a little huh? I'm almost expecting a tumbleweed
> to roll past in here!
>
> I've been nursing a server migration tonight, of which the up side has
> been that I've been chained to the desk with time to kill. So, I've
> just checked in more code for the DB prototype that I started.
>
> It now processes education and experience information, and stores geo
> information if anyone includes it in their hCard.
>
> Whilst I've tried to follow the hResume spec. as much as possible,
> I've only actually tested against LinkedIn profile pages thus far.
>
> I've also hacked together a very, very primitive web interface. I hope
> to have that hosted in some form over the weekend. It will give folks
> the ability to register their resume with the system, and view some of
> the data it spits out. I figure that by doing that we can start to
> collect a variety of hResume pages which we can verify the code
> against.
>
> Speaking of verifying the code - if anyone wants to cast their eyes
> over what's in github, I'd be very much obliged. So far it's been very
> much hacked together as a prototype / proof-of-concept, but any
> comments will be valued.
>

> Code is available athttp://github.com/jstirk/silicon-beach-database/tree/master

[Elias Bizannes]

Good work!!

 

My apologies for not driving this - been doing some 10-15 hour days on paid work last few weeks. Dead to the world for another two weeks, but after that, I'll put more energy into this effort.

 

[Elias Bizannes]

I like the work on the prototype, but my only concern is that we are
thinking too much about the resume model as opposed to something more
granular than this.

take for example my profile. I tend to write a lot, which is a pain
in the arse considering we want to database as much as possible. We
need a way to structure information as much as possible. At the same
time, we need to kill of the extra bits of fat and focus on the core
data points we wish to collect.

two guiding principles we should ask ourselves with each data point:
1) it should identify people.
2) It should connect people

Clarity on what that means
1) Identifying people. We want to know who exists. Where they exist.
Where they can be contacted.
2) Connecting people. If someone wants to tap into some expertise,
organise an event, get word out to a subset of the community - we need
to be aware. this is not to say we build some social networking
functionality (e-mail and other services can be the actual pipes of
communications), but what we need is for people to be able to query
the database and get results of "x,y,z live in the Adelaide region".

As opposed to my LinkedIn profile, where I go on a self-congratulatory
um...I'll watch my language as there are ladies here...which is full
of unstructured information. So we should only use linkedin where the
data points can be structured into something specific (like employer
name) but there is no value extracting "description" - simply put a
link to the source for that.

> --
> Elias Bizanneshttp://liako.biz