91–100 of 105 posts
Earlier quoted context omitted.
What are this amish posts? I've never seen them(I live in Spain)
I believe he's speaking on users in his feed that are Amish: http://en.wikipedia.org/wiki/Amish
Earlier quoted context omitted.
So, what is a good tech blog to read these days?
Personal blogs mostly, I haven't seen a for profit non-tiny organization ever not turn into a content farm when it got down to either firing people or turning on the crap firehose. Reddit and HN are great for scanning for new bloggers to follow (hence the number of posts in these places pissed about the Google Reader shutdown).
I have had a difficult reading relationship with pandodaily. After some good initial articles, they started producing trash. This article, for a change, is reasonably good.
I thought this article was ridiculously good. Well researched and well written.
Earlier quoted context omitted.
I'm not an fb developer and don't know the platform, but was that documented as the format? i.e. were you expected/allowed to destructure an id in that way or was it intended to be opaque?
You are allowed to deconstruct the id that way because it's the only way to get the information. It's not a property or value, it's part of the id. You then use these three parts to get the rest of the information. It's not documented as a format (very little is) but it's been this way since at least 2011-ish. If there is a better way to get this information it is also undocumented.
If the API has a usable purpose without providing that info, then I think I'd disagree with you - since you're reverse-engineering the implementation to get more data out.
Reverse engineering is OK, but implicitly carries the risk that stuff will change and break you without warning, in which case you can't really complain, in my opinion.
If the API's purpose can't be fulfilled without that info, then the API was probably broken as designed (you needed to parse the id to get the info, they just didn't document it).
Earlier quoted context omitted.
You are allowed to deconstruct the id that way because it's the only way to get the information. It's not a property or value, it's part of the id. You then use these three parts to get the rest of the information. It's not documented as a format (very little is) but it's been this way since at least 2011-ish. If there is a better way to get this information it is also undocumented.
> You are allowed to deconstruct the id that way because it's the only way to get the information. If the API has a usable purpose without providing that info, then I think I'd disagree with you - since you're reverse-engineering the implementation to get more data out. Reverse engineering is OK, but implicitly carries the risk that stuff will change and break you without warning, in which case you can't really compl…
Liking works, but unliking does not in cases where the post_id returned has the profile_id prefixed. So you have to remove the profile_id from the post_id to unlike.
The reason why developers have to reverse engineer is that the Facebook platform doesn't and did never work the way it is documented.
Here's a bugreport for that problem which hasn't been solved since last February! (The top comment here with a workaround for that issue was created by myself: https://developers.facebook.com/bugs/539328566085833?browse=...)
1) Just keeping up with documented and undocumented breaking changes is probably a full time job.
2) Expect that some feature of the API breaks every 2 weeks, especially login on their Android SDKs cannot be relied upon.(reliable for me is the industry standard for server uptime usually advertised - 99.99999%) If your application just uses few parts of the API it probably once every 1 or 2 months.
3) Substract 0.5 to 1.0 points from the rating of your app in the Android or iOS app store, depending on how heavy you rely on Facebook, because of the instability of their APIs.
4) Expect to spend at least a day per month writing bug reports. (Or just give up like I did)
5) You will do lots of reverse engineering to work around the bugs which they are constantly creating at a mind blowing rate.
My final conclusion after almost 2 years of working with their APIs (as a good actor) for my app (link: https://play.google.com/store/apps/details?id=com.flipster&h...) is that I will never ever ever build again something that relies that much on Facebook.
If I need a friends list in a future project, I'll just use the users telephone book, like I already did on a VoIP/Messaging app for mobile that I built for the company I work for.
If I need private messaging I'll just set up my own XMPP server.
If I need login, I will sure as hell save myself the headache of using their fucked up (and even when it is working - bad converting) login, and build one myself!
Earlier quoted context omitted.
It's odd that they chose stackoverflow for their support system, because most of the answered questions there are way obsolete by now.
They chose StackOverflow for their support system at one point . At one point, they've also chosen a web forum, a wiki lots of devs bought into (but which they later entirely blew away and replaced with Bing searches of their site), and probably a half-dozen attempts at official on-site docs. When I saw they'd offloaded to StackOverflow, I thought that was an idea that had some promise, but the big question in my min…
They seemed to have fixed it now, but for a while the search box would return results from the wiki, which had been removed, leading you on an endless tempting "the answer you want is just around the corner" unhelpful drugery.
Earlier quoted context omitted.
This is an overly simplistic analogy. No platform developer, when faced with weeds would say "let's torch it". What really happened in my opinion is that they tried a weed killer. However, as in real gardening, it turned out that distinguishing a weed from a non-weed is complex, subtle, and full of value judgments. In some cases, even if a plant has weed-like traits or capabilities, it's not a weed in the eyes of the…
I agree that the analogy is simplistic but I disagree with your weed killer analogy. I use weed killer on my own lawn and when I do I apply it in a targeted spray specifically to the weeds in question. I am still making a judgement and doing the hard work to separate parasites from useful organisms. Based on the article is sound like they sprayed everything ie removed the apis in question, and weed killer will indeed…
Doing it properly does involve understanding both what 'weed' means to you and 'desirable plant' then being careful not to poison the latter (and actually encourage it) while you try to deal with the former.
Earlier quoted context omitted.
> You are allowed to deconstruct the id that way because it's the only way to get the information. If the API has a usable purpose without providing that info, then I think I'd disagree with you - since you're reverse-engineering the implementation to get more data out. Reverse engineering is OK, but implicitly carries the risk that stuff will change and break you without warning, in which case you can't really compl…
It's not that simple, the id returned for a post should allow to like/unlike the post according to documentation. Liking works, but unliking does not in cases where the post_id returned has the profile_id prefixed. So you have to remove the profile_id from the post_id to unlike. The reason why developers have to reverse engineer is that the Facebook platform doesn't and did never work the way it is documented. Here's…
I've suffered from having designed bad/limited APIs before and watching as people dig into bits I didn't want them to dig into, limiting what I can do in the future.
Not sure on the best way to avoid it, but I guess it's a 'nice problem to have' since at least people are using your API.
Earlier quoted context omitted.
Same with Verge. A lot of sites are following Business Insider and Mashable down the high-volume shit-chute because that's how you make money when people won't pay for stuff.
So, what is a good tech blog to read these days?
Otherwise it depends on your interests. I'm most likely to check out Anandtech, Ars Technica, Wired, and some ZDNet bloggers.