Disqus - Latest Comments for DavidBerlind

Re: Introducing the 1.0 Perl Driver

David Berlind — Thu, 01 Oct 2015 09:36:00 -0000

yes, totally understand the history there.

Re: Introducing the 1.0 Perl Driver

David Berlind — Tue, 29 Sep 2015 18:02:24 -0000

personally speaking (and actually on behalf of ProgrammableWeb.com), it's very confusing to the developer community when so many different terms are used to describe what is essentially the same thing. "Driver" is a new one to me. I've heard "binding" and "client." Based on our observations, "SDK" is the most often used nomenclature when referring to a language/platform (PERL, Node, etc) specific library offers access to an underlying resource (whether through a publicly documented API or something less API-esqe). For that reason, we're going with SDK so that our site users know exactly what's behind the button (there's no mistake in their mind what they're going to get when they click SDK). Libraries is a tougher one, but we're not using the phrase to say "SDK" but rather a resource for some other language specific purpose-built objective (ie: standing-up an API).

Re: Introducing the 1.0 Perl Driver

David Berlind — Mon, 28 Sep 2015 11:31:15 -0000

Is this really a driver or is it an SDK?

Re: Podcasting 2.0

David Berlind — Thu, 16 Apr 2015 11:20:09 -0000

ps: I'd love to give the beta a try as well. Is it possible that from within facebook, if someone recommends a podcast, that I can just click a button that says "Podcatch" and it will take care of the rest?

Re: Podcasting 2.0

David Berlind — Thu, 16 Apr 2015 11:18:26 -0000

One reason media companies might not have gone for the idea is that podcasts have proven difficult to monetize. When you consider the amount of destruction in the media business over the last decade, most media companies found themselves in a cash negative situation and, not being tech companies, drifted towards cost control (aka: layoff your journalists) vs. innovation as means to black ink. So, investing in something like podcasting without a clear path not just to ROI, but to profitability during a time when the mantra was (and still is) about controlling costs was very much off the table.

Re: Why you still need backups when moving to the cloud Q&A

David Berlind — Tue, 31 Mar 2015 10:49:43 -0000

API stand for Application Programming Interface... not "application performance interface" as stated in this article.

Re: The Ultimate Guide to Mobile API Security

David Berlind — Fri, 27 Mar 2015 20:49:32 -0000

I don't have much more feedback. I'm no SSL expert. But this blog post is called the Ultimate Guide To Mobile API Security and builds a house of cards on top of SSL which has been proven to be the Achilles Heel of mobile API security. The name of the column is why I opened it. I though maybe I might learn of a new solution to what appears to be an intractable problem.

Re: The Ultimate Guide to Mobile API Security

David Berlind — Fri, 27 Mar 2015 20:29:41 -0000

Describe validate. One answer is certificate pinning. But the problem is that you're tightly-coupling client to server when APIs are supposed to do the opposite, and you're dispensing with DNS. It's not a solution. It's a workaround that undermines core concepts of both the Internet and Web/mobile app development.

Re: The Ultimate Guide to Mobile API Security

David Berlind — Fri, 27 Mar 2015 19:48:44 -0000

Randall, a MITM attack obliterates SSL as a form of protection. It fools the client into thinking think it's dealing with the real server when it's not and the tools to pull off an attack are downloadable for free. All I have to do is load up a mobile app on my own smartphone, run a MITM on myself, and all of that apps secrets are easily exposed.

Re: The Ultimate Guide to Mobile API Security

David Berlind — Fri, 27 Mar 2015 19:33:59 -0000

And what happens when there's a MITM attack (easily perpetrated on any mobile app)?

Re: When You Are Ready For Nuanced Discussion About Who Has Access To Your API I Am Here

David Berlind — Fri, 06 Feb 2015 18:21:52 -0000

Crap! What? There's no controversy? LOL! @GB, thanks for reminding me to check this month's unique visitors for ProgrammableWeb. Whew! Not zero (you had me worried for a second). @Kin Lane, now *this* analysis equating all mobile apis to public apis (tangentially relevant to this thread) is something I could not agree with more: http://apievangelist.com/20...

Re: In The Future There Will Be No Public vs. Private APIs

David Berlind — Fri, 06 Feb 2015 11:35:02 -0000

Since I'm not in agreement, I've written a rebuttal on ProgrammableWeb; http://www.programmableweb....

Re: Swagger, APIs.json, And Review For The New Developer.Trade.gov

David Berlind — Thu, 14 Aug 2014 16:59:35 -0000

Ah, OK, that makes perfect sense. Under what circumstances does it make sense to list or group non-authoritative listings once authoritative is already listed? I guess the end-user could have the option to filter (provided the search engine U/X allows for that).

Re: Swagger, APIs.json, And Review For The New Developer.Trade.gov

David Berlind — Thu, 14 Aug 2014 16:38:54 -0000

Thanks for this post Kin. Could you explain in more detail how publishing via APIs.json+Swagger results in more authority and prominence? For example, more authority and prominence than what? And in what search engines? We (ProgrammableWeb.com) are of course contemplating APIs.json support in our API search engine. But I'm curious to know why APIs.json-sourced records would be given more prominence or authority over other records in our search engine (or others). Thanks!

Re: New BYTE bitten by link bait - Apple 2.0 - Fortune Tech

David Berlind — Mon, 18 Jul 2011 10:15:05 -0000

For the record, we at BYTE have no interest in publishing link bait. If that were the case, I think there would be a pattern of it, and if you check BYTE out, you'll notice that this was an isolated case. I've been doing this long enough to know that you can't delete a story from the Web. The story lives on in Google's cache where those who are dedicated to keeping the controversy alive can easily point to it, or republish it (sure, it's our copyright, but the truth is it's so difficult to chase after violators all the time).

By taking the article down completely, you end up with an even deeper challenge to your editorial integrity than the one that was originally raised by the article itself (clearly implied -- and I agree -- by what CNN Money's Philip Elmer-DeWitt said above). When we realized our error in publishing the original piece, it took all of one minute for us decide what to do next -- and that's what you see now.

We hope that given the two possibilities raised here by Mr. Elmer-DeWitt, that readers will agree with our rationale, and go with "a rare display of after-the-fact editorial integrity." My only regret is that the practice is considered "rare." As far as I'm concerned (and unless some legal issue supersedes the best practice), strikethrough-style redaction (along with an editor's note) should be the default response for any editorial organization that publishes something on the Web that it wish it hadn't.

Thanks for hearing us out.

David Berlind
Chief Content Officer
UBM TechWeb (fomerly CMP Media, and parent to BYTE)

Re: Google Wave: You need to pay attention to this.

David Berlind — Tue, 22 Sep 2009 10:50:29 -0000

Jason,

Hairsplitting over the technical details aside, I think your post sheds some light on the practical applications of the technology and how we all need to be thinking creatively about the impact of something like Wave. If I read this correctly, a bunch of federated Wave servers could displace Twitter. As much as I like Twitter, my main complaint about it is that there's no competition to keep them innovating. I've argued that Twitter should be turned into a protocol in a way that solution providers could comply with the standard and compete on implementation. The existing Twitter.com could be one implementation but there could be others that sit both inside and outside the firewall. From the description above, it sounds like a bunch of federated wave-compliant servers could do the same thing, perhaps providing far richer content. Perhaps Google gave up on Jaiku because it knew something far more robust was in the pipeline?

Jason, any thoughts on what media companies might do with Wave? (I'm imagining the CMS being a wave server that could contribute content to some meme, er, wave).