Hacker News new | past | comments | ask | show | jobs | submit | b14ck's comments login

To me, wikis just seem 'lazy'. Projects that use wikis as a primary form of documentation make users feel like the project is un-cared for, and not worth documenting.

I have absolutely no stats to back this up--but having officially written documentation gives projects a really good 'feel', and makes it a lot simpler for users to get started (IMO).


That seems strange to me. It's possible to do a really nice job with it, as evidenced by (at least) the Blueprints project: https://github.com/tinkerpop/blueprints/wiki


SHUT UP AND TAKE MY MONEY!


There are some other small countries / territories also on NANPA, but yeah, sorry!


Well, I guess it might be useful in Jamaica.


Hey krrose27, we basically pull the information from a variety of sources, all publicly available. If we can get the caller ID name information, then it means any call made from those numbers to a caller ID capable phone (with caller ID service) will be able to see it also.


Hey Adley, thanks for the comment! I'll update the page shortly.


When I tried it I got this:

"Sorry, not implemented yet. Please append "?format=json" to your URL."

When I did that it worked.


You must have tried it in a web browser. Using curl sends different request headers. When you are using a web browser, it asks for text/html. Try ?format=text


It must be Tastypie thingy. Nice to see Django-powered site.


Hi there. So, I'm the author of this article. Anyhow, for our free-tier users we don't provide realtime lookups.

Basically, we'll only return a result if we have a caller ID in our cache. So, if you get a 404 (no output), then try again a few seconds later after we've had time to do the lookup via our backend.

Sorry about that! Realtime lookups are currently restricted to API key users only.


Is there any way to tell the difference between "try again" and "no data available"?

And you should have made this MUCH more visible on your website. I initially tried your service, got zero results and dismissed it as a failure.

Only after reading here did I realize your service actually does work, I just have to try each query twice.


Hey ars, thanks for the feedback! After reading the comments here on HN (which are incredibly valuable), I'll be making those changes ASAP.

Sorry for the confusion, but thanks again for the feedback. I greatly appreciate it.


> you can't get something working within 5 minutes of vising our website, we've failed our mission.

It took me five minutes on the website ... and I had to come back to HN and read the comments to get this working. Don't want to be discouraging, but maybe you should provide this information in the blog/website otherwise you have failed (for me atleast).


Hey samirahmed, thanks for the comment! I'll definitely be updating my blog post and improving the documentation on the website.

Appreciate the feedback.


You might make this more obvious. Also, you might state how to distinguish between "sorry we need more time to look this up" and an actual 404 or error.

HTTP code 202 Accepted seems appropriate for this (http://en.wikipedia.org/wiki/List_of_HTTP_status_codes)


504 Gateway Timeout would be the obvious one, since if I'm reading this correctly it's essentially a timeout of zero; 5xx status codes are indicative of retriability later on.

But I think that sort of performance would make the free tier essentially worthless. “All you have to do is hit our API endpoint, and BAM, you get results back.” Except you really don't. Analogy: a caching DNS resolver that returned an instant SERVFAIL if the results weren't already in memory wouldn't be considered acceptable even for demo purposes anywhere that I've seen.


Hey premchai21, thanks for the feedback! You're completely right. I'll be making some adjustments to the way this operates over the coming days to make things much simpler.

Thanks for taking the time to check us out!


I guess I disagree here (but who doesn't with HTTP status codes...). I try to reserve 5XX codes for actual errors. In this case, no error occurred, the response is just delayed.


> But I think that sort of performance would make the free tier essentially worthless.

Not at all. It lets you try out the API, figure out if it works for you, and get back "best effort" results. That seems perfect for a free tier.


I suppose being able to try out the API on the software level is useful, yes. I'm not sure how one is supposed to figure out whether results are likely to be good enough for a given application if they're so unpredictably degraded. I do suspect my perception is being colored by the website text, as quoted above.


Hey mike, thanks for the feedback. I'll be working on this tomorrow to get a fix out.

After all the feedback here, I realize how crazy it is to be returning a 404.

Thanks for checking us out, and thanks for the feedback!


I can see why you want to do this, but this just makes people send 2 requests instead of 1 for each number they look up.

Not sure if this is the better way.


Thanks, this looks like a really great list. I'm adding these to my reading queue :)


You should add Eloquent Javascript to the list really good JS books, if you haven't already read it: http://eloquentjavascript.net/


Google voice blocks our exchange numbers in Pennsylvania for some reason :( We're currently expanding into multiple datacenters--so we'll have new exchange numbers shortly. But it seems that our 610-XXX numbers are all blocked by Google.


"In order to avoid paying high connection fees to traffic-pumping carriers, Google Voice has blocked calls to some of these carriers." - http://en.wikipedia.org/wiki/Traffic_pumping

Looks like you are traffic pumping after all.


They're at our datacenter in Pennsylvania. We get paid from termination (like freeconferencecall.com).

We're not traffic pumping or anything--it's a legitimate conferencing service.


Can you maybe elaborate on how you're getting paid from termination? Perhaps I abused the term "traffic pumping", but this definitely sounds like the sort of of thing I was picturing being exorbitantly expensive to the carrier initiating the call to your service.

I previously worked as a telecom engineer at a VoIP startup and we definitely characterized http://freeconferencecall.com as a service monetized by traffic pumping and denied connecting to its NPA in our dialplans. While by no means absolute truth, the concern I'm voicing is further reinforced should it be true that Google Voice is refusing to terminate to your DID as described below.


Hey again-- I've actually made a response on the related reddit posting to a similar question. I typed out a fairly in-depth response, so I'm going to paste it below.

I hope this clears things up.

-----

Basically--we partner with telephone companies who colocate our equipment (servers, etc.) which we use to run our software. We purchase phone lines from these telcos (to support incoming calls), and then provide free services for public consumption to make money off the termination cost.

Imagine that you have a T-Mobile cell phone, and your friend has a Verizon cell phone. When your friend calls you, Verizon pays T-Mobile a small amount of money for every minute that your call lasts (this fee is to pay for the physical infrastructure that T-Mobile invests in--telephone polls, switches, service monitoring, etc.). That's why cell phone plans cost money and aren't free.

We operate the same way, except we partner with telephone companies (like T-Mobile in my example above), and split the termination fees with them.

So the more people use our services, the more we can profit from it.

Hopefully this clears it up. There's been a lot of discussion in the internet recently about traffic pumping and companies attempting to get fraudulent traffic to make money. We are by no means doing anything illegal or illegitimate here.

-----

Also: our motivation for building confnow is to basically to make conference calling as simple as humanly possible. I've personally used the other sites out there (namely: freeconferencecall.com), and nothing is more frustrating to me (as a user) to want to make a quick call and have to go through hoops (setting up accounts, waiting for verification, listening to ads, etc.) when you just want to get into a room as quick as possible and move on with your life.


Thanks. Here's the reddit post you were talking about, I believe:

http://www.reddit.com/r/startups/comments/qjgkk/show_reddit_...

Could you comment on what proportion of the CLECs you partner with are allowed to demand higher access rates from the IXCs?


Yo! Thanks for giving it a test.

If you add a security pin, then after you enter your conference room number, it'll prompt you for the pin you entered (think of it like a conference room password).

Also: we're in the process of getting more numbers. :)


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: