Sporting possibly the ugliest UI I’ve ever seen, but nonetheless making it onto my list of “gotta have it bookmarked” web tools is txt2re, a RegEx generator for pretty much any language that supports regular expressions either as first class native elements or as part of the standard library (Perl, PHP, Python, Java, Javascript, C, C++, Ruby, VB, C# to name a few).  It does an impressive job of parsing sample input strings and letting you specify what parts you want to capture.  Now, about that UI.…

Earlier this year, I had an opportunity to give a talk on databases and SQL for the Bay Area Crime and Intelligence Analysts Association.  Several people asked me for the slides, and I’ve ended up using them for several other impromtu sessions, so I thought I’d post them.  Feel free to use or adapt.

Silicon Valley Geek Warning: We are all aware that SQL is no longer cool (if it ever was).  We got the memo that you’re not cool if you don’t live and breathe NoSQL.  Nothing to see here.  Move right along.…

The first in a series of “you gotta try this (if you’re a coder)” posts, this one with a hat-tip to the folks at gskinner.com for providing the most usable online regular expression (RegEx) tester I’ve found.  Yes, you can test any RegEx on a a JavaScript (ahem, ECMAScript) console, but gskinner’s is both pretty and incredibly useful.  And it has a nice sidebar of reminders for those of us who need the occasional syntax refresher.

A year ago, I would have been hard pressed to decide whether I thought the Yahoo! board or the HP board was more hopeless.   A year later, both have managed to appoint excellent CEOs–finally.  And both happen to be women–finally.   Yahoo!‘s board gets extra style points for, at least publicly, not giving a hoot that Marissa is expecting this fall (see  New CEO’s Pregnancy Was Not an Issue for Yahoo Board — Kara Swisher — News — AllThingsD).  It just shouldn’t matter.  There was a rough three months when I was both a tech company CEO and hospitalized for a bone infection (wisdom teeth are evil).  After spending more time in Stanford University Hospital than most healthy mothers do during and after childbirth, I ended up distracted with antibiotics and IVs for three months.  Other than politely checking in on my health, my board could not have cared less–and certainly they didn’t question my fit for the job because of it.  Why should it be any different for a woman expecting a baby?   At least she has the benefit of being able to plan in advance!  This qualifies as a pleasant turn of events in the all-too-often male-dominated tech world.  

Last month, I posted what turned out to be the most popular post I’ve written in years about a topic many people would consider not too terribly fascinating (or thus popular): APIs, or Application Programming Interfaces, the machine-to-machine connection protocols used by one piece of software to talk to another.  “It’s the API, Stupid!  Or How to Crowdsource Your App Ecosystem” turned out to be both popular and somewhat predictive of later events.  In short order the tech universe brought us a series of completely contradictory development in API World, but I was distracted with the birth of my second child, so here we are, a month or so later, catching up.

First, what was the big API news (until Friday of last week):  Oracle v. Google, in which Oracle, the acquirer of the Sun’s Java intellectual property including its copyrights and patents, contended that Google’s implementation of functionality compatible with the Java APIs constituted (a) patent infringement; (b) copyright infringement; or © both.  The tech world should be grateful that it was Judge Alsup, a programmer, Harvard Law School (and Kennedy School) grad, and erstwhile clerk to a US Supreme Court Justice William Douglas, who presided over the case.  We’re fortunate because Judge Alsup had both enough savvy to let the jury reach a verdict on copyright infringement and because then (after letting the jury return) had enough domain knowledge to rule the APIs were not copyrightable in the first place:

So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical.

Under the rules of Java, they must be identical to declare a method specifying the same functionality — even when the implementation is different. When there is only one way to express an idea or function, then everyone is free to do so and no one can monopolize that expression. And, while the Android method and class names could have been different from the names of their counterparts in Java and still have worked, copyright protection never extends to names or short phrases as a matter of law.   (( Order Re: Copyrightability of Certain Replicated Elements of the Java Application Programming Interface, Case 3: 10-cv-03561-WHA, document 1202, filed May 31, 2012. ))

Judge Alsup has drawn the bright line between compatibility and duplication that the industry has been tiptoeing around for years.  Writing software that works with someone else’s software?  Always been perfectly fine.  Writing software that mimics the behavior of someone else’s software?  Fine, so long as you don’t copy their implementation, as confirmed by Judge Alsup.  Translation:  open market for competition.

…until you have to actually use someone’s API.   Which brings up to last week’s big Twitter dustup.  Twitter continues to ratchet down the acceptable uses of their API, and instead of litigating, they’re simply cutting off users whose implementations they either don’t like or have grown beyond–including, notably, LinkedIn’s, as they became evident last Friday.  This isn’t the first time Twitter has taken aim at the developers who have created its much-vaunted app ecosystem.  Just a year ago, Twitter spent $40 million to acquire Tweetdeck, developed of an excellent (and eponymous) Twitter client, and in the process overtly directed developers not to attempt to compete with them on client applications.  They didn’t turn anyone off that time, but they certainly began to put a fence around their API.  The most recent changes Twitter made came with more wood behind the bat:  they turned off their partnership with LinkedIn on what appeared to be pretty short notice–thus further entrenching their position that they would control their API at all costs, including some bad press.

It seems the Cloudiverse anticipated Judge Alsup’s ruling by giving API owners the ultimate trump card:  the power to shut off users whose activities they disagree with.  If those users are individuals, there is certainly no recourse.  If they are larger companies…there is still no recourse.  Possession remains nine tenths of the law–especially when your API acts as the gateway to your platform, and you possess both.  Twitter isn’t the only tech tabloid star to tussle about APIs recently:  just yesterday, word got out that Facebook was shutting down the APIs they had promised to support when they face.com announced it was being acquired in June.  The Twitterverse was rapidly filled with developers facing API-apocalypse:

OH GOD. The face.com API is shutting down!! @jonrohan what are we gonna do???

— Vicent Martí (@vmg) July 7, 2012

So Judge Alsup looses the dogs of competition and the Cloudiverse responds with its own, possession-trumps-all rebuttal.  These are interesting times indeed to observe the API World.  Enjoy–and pass the popcorn, please.

Vikram Mansharamani, whose name you may find familiar from The Wall Street Journal, The New York Times, the Atlantic, and elsewhere, has an interesting piece about Generalists (see All Hail the Generalist, on the HBR Blog network).  As one occasionally accused of being a generalist myself (my being a coder and product guy notwithstanding), it was gratifying to read that someone else thinks the specialist era may be drawing to a close, and that generalists seem so much better positioned to make the leaps of intuition and creativity required for 21st century, Internet-driven businesses.  Enjoy the post, it’s a good one.  Hat tip to Arun Kumar, also a self-described generalist, for the post graphic (slightly modified form is my fault!).

I think I will write a more detailed post about why LinkedIn’s password leak matters so much, but in the interim, the technically inclined will find Patrick Mylund Nielsen’s post illuminating–and disturbing.  “Storing Passwords Securely.” at Throwing Fire.

All of us at SST (formerly ShotSpotter) are very proud of Erica Goode’s article which ran in the New York Times today.  “Shots Heard, Pinpointed, and Argued Over” does a great job of explaining what we do, and how we help police nationwide.  On a personal note, when I joined ShotSpotter we had five customers, not one of which had more than 2 square miles of coverage.  Now we have 70, on three continents, the largest of which is 17 square miles.  We detect anywhere from 200 to 1,000 gunfire incidents per night.  Deeply gratifying to be contributing, even in a small way, to a safer world.

Data geeks rejoice. This library is curated, gorgeous, and virtually guaranteed to pique your curiosity–or creativity. Datavisualization.ch Selected Tools.

The sheer number of new dataviz tools is just astounding. The team from Quadrigram gets points for a slick website, enough content to dig one’s teeth into, and guts for trying visual programming (again…). But leave it to the Europeans to forget that ‘data’ are plural, not singular.