For the record, I wasn't just being nice. I really liked the idea of a start up specific job site where employers could search, sort and filter resumes by various criteria.

My thoughts were that the employers would pay for contact info on a per resume basis or buy packages of resumes instead of paying to post job openings.

After a quick search though it looks like there are already several people in the start up specific job space. It also looks like several have failed too.

It doesn't sound quite as good to me anymore.

We looked at: http://www.gild.com/products/gild-source/ for a bit. I think these were the guys that charge you a monthly fee and give you candidates that match your criteria based off of things like github accounts and linkedin profiles.

It seems to be a fairly common startup space. Its interesting though that lots of people don't think any of the existing products are amazing. So if you had a really great idea there's probably a good opportunity. But it has to be something really good (ala Hipmunk's visualization of flight searches idea in the travel booking space)

So the idea is that it just gives you a bunch of developers contact info based on public/semi-public info?

What happens if they're not seeking employment?

That seems kind of scary tbh. Seems like a huge invasion of privacy (guess that doesn't exist any more).

All modern browsers compile to native machine code nowadays. As you mentioned previously, a lot of extra performance will come from Java being static typed.

I think you are approaching this the wrong way. For something like this, the user should be able to decide how many entries they would like to make. I am guessing that the current limitation is because you have a column in your table for each entry:

TABLE job
job_id
...
...
...
duty_1 varchar(255)
duty_2 varchar(255)
duty_3 varchar(255)
...


A different approach to this would be to have a separate duty table with a foreign key to job:

TABLE duty
duty_id
job_id
duty varchar(255)

This way, you can have 1, or 1000 duties, it doest matter. From a UX point of view, you could show the user 3 'duty' boxes, but have a (+) sign next to them which expands a 4th/5th/6th etc This gives the user much more control over the information they are providing.

I believe so. They're supposedly pretty good at scoring people so the contacts you're getting are pretty high quality. I think we didn't go with them because unlike a traditional recruiter you're out the money even if you don't hire anyone (I wasn't that involved at looking at them).

That's never bothered recruiters.

Meh - I'm of the opinion that if you post **** publicly (and I mean real globally publicly like in a public github repo - not like Facebook friends-only public ) you can't complain if people are searching through it.

Number 72!

?

Also, AWS is down, took out Reddit, heroku and a load of other high profile sites!

I came here to complain about ****ty AWS. Their status page has this as a small minor issue...

And by "degraded performance" they mean "Not responding"

Just realised you are talking about the number of tables....

I think this is one of the big issues with using relational databases for the modern web. A relational database has a very rigid structure and is not easily expandable... resulting in situations like this where you have almost 100 db tables.

Using a non-relational database like MongoDB/CouchDB would allow you to have a much more dynamic data set.

If you are strictly limiting the resume to one page, you can present all the duties users have filled out for each role and force them to eliminate items from the resume until it reaches one page.

it also creates a great opportunity for users to have multiple variants of their resume with different duties presented for each one. So if they had 3 jobs that each involved some amount of customer service and some amount of technical work, they could target different types of positions (cs vs tech) by selecting different bullet points.

Now thats a million dollar idea!

daveT,

Congrats on shipping man. To start a project of any size in an entirely new language and get an alpha shipped in 50hrs is legit impressive.

A couple of notes:

-At the risk of beating a dead horse, I concur about using a CSS framework. I personally think a CSS framework is actually a lot like using jQuery -- it saves you from having to reinvent the wheel. Aside from bootstrap, I'd also invite you to check out HTML5 Boilerplate. There's actually an HTML5 BP version of Bootstrap as well. You mentioned something about it looking strange in IE. A CSS framework will go a long way to fix that b/c it normalizes everything at the start.

-There are a few HTML errors that may also be contributing to the appearance in IE (which is far less forgiving than FF and Chrome). Use the W3C Markup Validator to check your HTML markup. Copy and paste from the browser source, but use Firefox. Chrome has a weird bug where opening/closing brackets randomly get cut off in "View source".

-You've probably already thought about this, but if you do launch a live production version, I'd suggest using SSL for anywhere that users enter any type of identifying information. It's pretty easy, if you need help just let me know.

-You mentioned something about a "Download PDF" option. I don't know anything about generating PDFs with Clojure, but it's pretty easy with PHP. I use FPDF for that. Another option is TCPDF (also PHP), which supports some more advanced features that I've never needed. FPDF is easy, just one single PHP file to include. Just another option to consider.

So what's next for this project?

Just on the SSL point, some domain name registrars (gandi) include a free, fully functioning SSL certificate with domain name purchase

So I am doing a bit of an experiment to leverage the hand converter from the FPDB into a web service. I cannot even begin to describe how hacked together this is, and it wouldnt be possible without the changes ChazDazzle has made to his branch of FPDB (hope you dont mind me using your branch), but I have a semblance of a web service up and running. Hacked cannot even describe it.

The service is at jibe.rs.af.cm and accepts a single POST request at / with a single hand_data argument which should be a url-encoded hand history(s). It will return a JSON object of the parsed hand history. Currently, it will ONLY work for pokerstars hands (and not sure about zoom).

you can test it out using the following curl command:


curl jibe.rs.af.cm --data-urlencode hand_data@path/to/pokerstars/hand/history.txt


What you will see in the response is a whole load of JSON. It is an array of converted hands (if you posted more than one) and each one is exposed as a JSONified version of what the FPDB converts hands to internally. This will (hopefully) be super useful for anyone wishing to build applications which need to process raw hand histories without implementing their own converter.

The URL is temporary (its hosted on AppFog), but I will keep everyone updated with progress if there is interest.

There is still a bit of work to do but I would like to get to a point where I can run a reliable hand converter web service returning processed hand histories as JSON.

Credit to the FPDB guys, might have taken me several hours to get this running, but I only had to change about 10-20 lines of code to get it running.

That's awesome. I remember the last time I was trying to do something with hand histories I gave up after I realized parsing the hand histories was going to be too annoying to me.

Ye, I think a lot of people here have had some really great ideas for poker applications but got stuck at the hand converter. My aim is to create a simple web service to allow any application to easily convert hand histories.

This sounds great. And by all means hack away

Should be pretty straightforward to enable support for the rest of the sites. My pokeit branch on github has support for Bovada and Enet as well.

its a great idea, but is it fast? i mean, could a desktop app make these curl calls quick enough to make it worthwhile? might be better to just implement the python ourselves

@Chaz:

since you are using FPDB code, how are you getting around the GPL? or are you publishing the pokeit code somewhere?

i think it's value would be in web apps, you're right it doesn't make much sense for desktop apps

He's publishing his core changes back to us. We've had a good relationship for a while now

doesnt the GPL require that code be open? so if i wanted to see the code for the pokeit site, i should be able to? dont see how that can be a sustainable biz

I am about to write a benchmarking suite which will do this in a much more controlled environment, but sneak preview using curl:


So 3.416 seconds to convert a file of 28 HHs.

Basically, the speed of the conversion is 99.99% down to the speed of your internet connection and latency to the server. The application itself is running on an application server, and can process 1000s of hands a second, but the round trip from your computer->hand converter->your computer takes a bit of time (of course if I do this from a cloud server with a super fast internet connection its a lot faster).

If you application converts hands in batches (10-100 hands) then I think this service would easily be fast enough. (although there are other reasons why it may not be the best choice)

As gaming_mouse points out tho, this will be more aimed towards web applications, or people writing small apps who dont want to mess around writing a hand converter

Ye, I got stuck at trying to auto-detect the site. Might have to start off with manually detecting the site and then just passing the data off to the correct hand parser.

Hey, Mr. Wooster:

I remember using PT1 and PT2 back in the day, and both of those systems had difficulty parsing hand-histories. You also had to do manual imports: if you wanted to import Party Poker, you had to push the Party Poker icon; if you wanted to import FTP, you had to push the FTP icon. Even despite this, I think it lost about 1/2% of the hand histories. This was a problem that wasn't solved for many years, but overall it functioned pretty good.

To start, I would just make it so that the user has to manually import the files and tell the system which company they are importing. I know its not super-impressive, but I think this is the best option since it is impossible to say what the future HH formats will be (in America).