Listening to programmers complaining about the markup used to implement HN is a perfect example of tech folks not focusing on the users.
Could you elaborate? I assume you are criticizing HN or the complaining programmers but I can't tell which.
Hacker News API
71–80 of 315 posts
Re: Hacker News API
#72I hope they'll add an article search (by keyword) feature soon.
Re: Hacker News API
#73This... is cool, but also kinda sucks for me. I've invested dozens of hours into writing an extremely complicated scraper for my Android version of HN. https://play.google.com/store/apps/details?id=com.airlocksof... The newest version (still under development, probably a month or two from release) adds support for displaying polls, linking to subthreads, and full write support (voting, commenting, submitting, etc). I…
just wanted to let you know that I love your application!
Re: Hacker News API
#74I always thought HN was more of a one man job. I didn't realize there is an entire team working on it (full time?). Honestly there doesn't seem to be much to work on here. It's a simple site that rarely changes (at least on the front end).
'Simple site' that gets probably tens of thousand if not hundreds of throusand unique visitors a day.
[deleted]
Re: Hacker News API
#75Earlier quoted context omitted.
UNIX time is actually much easier to parse and more accurate. Almost all platforms (even Windows[0]) have a way to convert a UNIX time into a culture specific local time. What you're asking for is a string you have to parse. That's a lot more work and there is a lot more that can go wrong. [0] https://stackoverflow.com/questions/249760/how-to-convert-un...
Um, how about, no? var time = new Date(" ") // in Javascript time = DateTime.iso8601(" ") # in Ruby Aaaand it's human readable! Aaaaand it works before the Unix epoch! EDIT: Changed DateTime.parse to DateTime.iso8601, to be even more retentive. Look, parent claimed that parsing ISO strings is hard (it's not, especially if you're consuming a web api on a modern web language ) and that it was more readable (which is so…
> and that it was more readable (which is so clearly wrong I have no words).
I never claimed that. In fact I didn't address readability at all. So I have no words for your "no words" relating to a claim that literally didn't appear at all.
> The range is worse (lol wraparound if you're using a 32-bit int), there isn't explicit support for fractional seconds, doesn't map onto UTC cleanly, doesn't handle leap seconds, and so on.
Fortunately we're already well on our way into a 64 bit world, and aside from legacy systems it won't be a problem by 2038. According to the Steam hardware survey [0] over 80% of Windows machines, 100% of OS X machines, and 90% of Linux machines are already running a 64 bit OS.
Leap seconds can be handled during the cultural conversion.
> It's only "easier" if you don't actually care about a human-readable timestamp that is robust and if you desire to do date parsing yourself instead of using any of the well-established libraries out there. Ugh.
I don't care about human readable timestamps for an API used in automation. More robust is subjective, particularly as parsing it is more technically complex (particularly as most of the parsers support several different but similar DateTime formats).
Most well-established libraries support UNIX time natively or use it internally.
Re: Hacker News API
#76Earlier quoted context omitted.
Um, how about, no? var time = new Date(" ") // in Javascript time = DateTime.iso8601(" ") # in Ruby Aaaand it's human readable! Aaaaand it works before the Unix epoch! EDIT: Changed DateTime.parse to DateTime.iso8601, to be even more retentive. Look, parent claimed that parsing ISO strings is hard (it's not, especially if you're consuming a web api on a modern web language ) and that it was more readable (which is so…
That's two programming languages. Not all languages have a nice ISO-8601 parser built-in. Human-readable is a slight advantage, agreed.
It's not a slight advantage if you've ever had to parse through logfiles by hand or debug APIs with curl--it's a great deal more than that.
Why not, let's have some more examples:
In PHP (with a bug, because PHP is stupid and doesn't handle decimal fractions):
$dateTime = DateTime::createFromFormat( DateTime::ISO8601, '2009-04-16T12:07:23Z');
DateTime time = DateTime.Parse("2010-08-20T15:00:00Z", null, DateTimeStyles.RoundtripKind);
import dateutil.parser
dateutil.parser.parse('2008-08-09T18:39:22Z')
~
Interchange formats, say JSON blobs over a wire, should very clearly express what's in them, perhaps by using a very well-known standard which is human-readable, whenever possible. The fact that some languages haven't yet realized that this is an important-enough feature to put in their standard libraries compared with whatever esoteric academic shit they think is necessary (C++1x, for example!) is not the format's problem.
Hint: if you're consuming a web API, you are probably using one of the languages I gave examples for, or a very close relative. Just because your Haskell-on-M68k package doesn't know how to 8601 doesn't mean that using a nondescript number is a good idea.
Why, in the year of our Lord 2014, is this even a fucking question?
EDIT:
I'm sorry to be so mean in my language about this, but I've had to fight a lot of raging stupid with regards to storing timestamp data. I do not wish to see anyone else suffer unduly.
Re: Hacker News API
#77I always thought HN was more of a one man job. I didn't realize there is an entire team working on it (full time?). Honestly there doesn't seem to be much to work on here. It's a simple site that rarely changes (at least on the front end).
I hope not - what if that one man gets hit by a bus?
I always assumed HN was more of an operations challenge rather then a purely algorithmic one. Lotsa traffic I assume. Not sure about the scope of user/comment moderation around here but something tells me their item ranking system just might be that good.
Re: Hacker News API
#78I built a scraper around 3 years ago (been through a few usernames since then), and I've had to change it once 3 months ago because the HTML output added quotes around HTML attributes.
Even though it's read only, I'll continue to use my scraper rather than the API simple because it's one request, rather than the API would require one request for the top IDs and then one call per story, so it would be 31 calls instead of just 1.
Unless I'm missing something, it seems fairly poorly designed for top stories, and non existent for new stories.
------
EDIT: Looks like I missed the text about updating to a new rendering system in 3 weeks time, and to iterate designs faster to allow mobile friendly theming. Looks Like I WILL be updating to use the API
Re: Hacker News API
#79Why do you have all the times in Unix time instead of ISO-8601 UTC? EDIT: Also, the "about" value in the users api appears to be truncated. Compare... https://hacker-news.firebaseio.com/v0/user/angersock# ...with... https://news.ycombinator.com/user?id=angersock EDIT2: Note that the JSON is correct, but the preview in the firebase API seems to be broken. EDIT3: No issue tracker on the Github? Laaaame.
[Firebase Dev Advocate]
@angersock - the "about" value you're seeing on the Firebase Dashboard isn't broken, it's just a truncated preview. The HN team is using email for issues, so you can send them any feedback at api@ycombinator.com.
Re: Hacker News API
#80This... is cool, but also kinda sucks for me. I've invested dozens of hours into writing an extremely complicated scraper for my Android version of HN. https://play.google.com/store/apps/details?id=com.airlocksof... The newest version (still under development, probably a month or two from release) adds support for displaying polls, linking to subthreads, and full write support (voting, commenting, submitting, etc). I…
I'm sorry you just invested a lot of time in scraping. I know from experience what a pain that is. We said several times that the API was coming, and I've made it clear to anyone who asked, but there's just no way to reach everybody. All: in the future, please get answers to questions like this by emailing hn@ycombinator.com.
Re write access and logged-in access, if that turns out to be how people want to use the API, that's the direction we'll go. But we think it's important to launch an initial release and develop it based on feedback. There are many other use cases for this data besides building a full-featured client: analyzing history, providing notifications, and so on. It will be fascinating to see what people build!