I didn't build out an account page for https://ipinfo.io until we had about 500 paying customers. If you needed to update your credit card or make other account changes you had to email me, and I'd update the database manually. Only after I was spending at least an hour every day dealing with those sort of requests did we go and build out a full account dashboard, where users could manage their accounts themselves, plus also do bulk uploads, see a graph or request volumes, and interact with the API via a UI. Before that the focus had been 100% on the API and the data quality.
IPInfo | Senior Software or Data Engineer / PM | Remote (or Seattle)
I started https://ipinfo.io as a small side project a few years ago, and it has since grown to now handling over 12 billion API requests a month, we have thousands of customers, and we're used by hundreds of thousands of developers. See https://ipinfo.io/about for some more details, or read this interview I did a couple of years ago that has some of the backstory: https://getputpost.co/from-side-project-to-250-million-daily....
I've recently started expanding the team, and I'm looking for more people with an interest in what we're doing to join the team, part-time or full-time. If you're interested I'd love to chat. Shoot me a mail at ben@ipinfo.io
These sort of rates were real in the past, but regulatory changes have decreased them dramatically. In general, much less than $0.01/mi at wholesale rates.
> Each region is completely independent. Each Availability Zone is isolated, but the Availability Zones in a region are connected through low-latency links.
I started https://ipinfo.io as a small side project a few years ago, and it has since grown to now handling over 12 billion API requests a month, we have thousands of customers, and we're used by hundreds of thousands of developers. Here's an interview I did a couple of years ago that has some of the backstory: https://getputpost.co/from-side-project-to-250-million-daily...
I've recently started expanding the team, and I'm looking for more people with an interest in what we're doing to join the team, part-time or full-time. If you're interested I'd love to chat. Shoot me a mail at ben@ipinfo.io
Jonathan's been doing a great job of ipdata.co! I'd like to also shout out to my own service https://ipinfo.io here though, where we've recently launched new plans that include company details, carrier details, and IP type - we have a custom classifier that labels each IP as isp, business, or hosting, which can be really useful for a bunch of use cases. Here's sample output from the pro plan:
I think it's always appropriate. May the best service win in any Show HN. Feature disparity quickly reaches equilibrium when missing features are highlighted, making all products better (in theory).
Everyone's just trying to do the best they can with what they have.
Welcome! RedRock is a nice place to work out of, although it gets busy and hard to get a seat if you turn up after ~10am, but gets quiet again in the afternoon. I also like working (on https://ipinfo.io) from the library, which has tons of desks and great wifi.
Not to take away from your interesting comment, but it's not written "70-ties", just "70s" - the first one reads as "seventy-ties", which is odd :)
EDIT: Updated "70's" to "70s" because of the great child comment that links to an article showing that while 70's is technically correct it's much more usual to exclude the apostrophe.
As long as we're exploring punctuation, the apostrophe in that case is valid and correct, but it's growing obsolete as it becomes more normal to write "70s".
Almost all the style guides recommend no apostophes on the end. Rather, apostrophes are reserved for numerals that are lefts out, i.e., '60s or 1960s, but not 1960's.
I guess it depends on how you define acceptable usage.
Only a generation ago, it was widely taught to include the apostrophe. Even then it wasn't universal, but it was one recommended way to do it.
For example, I have on my bookshelf "Webster's NewWorld Dictionary, Third College Edition" (copyright 1994) which says on p. 1560: "An apostrophe is used ... to show certain coined plurals. ... Figures may take either an apostrophe and an s or an s alone. 1990s or 1990's".
It also mentions a rule about using apostrophes with plurals of abbreviations if the abbreviations include internal periods, and it gives the examples of "Ph.D.'s" and "ICBMs". I guess internal periods have fallen out of favor too.
Anyway, the overall point here is it was taught this way relatively recently, and I don't think language moves so fast that what was taught a generation or two ago isn't considered acceptable usage. I'd call it correct but archaic.
Of course IP geolocation is terrible for language selection, but that doesn't make passive rough location information useless in general. What if, for example, you want to show someone nearby flights? You could ask them to enter their zip, or you could save them a step and make suggestions based on their geolocation. They could update the location if they wanted information on somewhere else or if you got the location wrong, and that's worse case 1 step, and best case no steps - you improved your UX!
The problem is when people fail to distinguish "helpful assumptions" from "actual facts"... I have just today gutted some worse-than-useless GeoIP functionality from a form that was facing customers of our organization so it could guess at their country, language, and city without asking.
BI guys put in the feature request some years ago so they could make pretty maps (but ultimately take no actionable steps based on these), and call center were then taking these guesses as facts (think getting a call and having someone chummy ask "Hey, how's the weather in <city you don't live in>" in the wrong language...). What's worse is we then added some user-facing fields asking for the location information, and it was impossible to tell apart user-supplied info from the IP-derived info!
It took fighting with BA and BI, but we finally decided it was stupid and were able to simply remove it. (BI will have to "fix their maps" by doing their own assumptions, outside of the application)
