188 karma · joined February 23, 2012
I find it to be sort of halfway between Notational Velocity and Evernote. Like nv it stores everything as flat files, but like Evernote you can add some structure to how your organize things.
[1] http://lesswrong.com/lw/9t8/the_singularity_institute_needs_...
It's easier than ever to graze on low quality, tabloid journalism -- "linkbait," if you will. Sensational headlines and puff pieces have always existed, and has always helped sell both tabloids and even more respected publications. But the web and social media make it easier to indulge in this sort of thing, and once you've clicked on one bit of linkbait -- or even a serious news story -- you're presented with a list of additional linkbaity stories.
Given the high demand, and low cost to produce, it's little wonder we see more and more churnalism and linkbait.
Perhaps the person writing the job ad was embellishing by calling it a major piece of the core database infrastructure.
[1] http://www.wired.com/wiredenterprise/2012/10/salesforce-orac...
I'm speaking for myself and not from either company. But I can tell you though everyone in the industry is aware of the problem and trying to get away from re-writing to produce more original content.
The problem, as I see it, is that volume drives most online publishing. Making money depends on having updates throughout the day. That means every writer needs to post something every day -- usually more than one thing a day.
Even though most of these quick hit stories don't get many pageviews individually, they add up, and occassionally even a quicky will become a "blockbuster" that gets a huge number of pageviews. Original stories get a more consistently high number of hits, but they take much longer to produce.
I'm not sure people appreciate how much time it actually takes to write this stuff. Even doing quick hit journalism takes time. For example, I spent a couple hours this week on a post about Solr 4.0. It's short, and it's based entirely on the announcement/feature list but it still took a couple hours to write.
I have a bunch of original stuff I'm working on, but quick hit posts cut into the time I spend on those stories. At least part of that is a time management issue on my part -- and I'm a slower writer than many of my colleagues -- but I expect that juggling the needs to publish daily with longer form work is an issue for many tech bloggers.
(You should also not underestimate the amount of time we spend filtering information and looking for new -- e-mail, briefings, competitors sites, Twitter, etc.)
Anyway, I think things are slowly changing for the better thanks to reader demand for better content. But there's also a need to balance completeness of coverage with original work.
It's funny that Wired was singled out because I think they/we actually have a really good original content to re-write ratio (though yeah, Wired's always been known for sensationalist headlines). TechCrunch and Business Insider both have lots of original content as well. Because BI does so much volume I think people overlook the original stuff.
Another note about rosy retrospection: I don't want to defend the rewrite churn, but I do want to point out that even most daily newspapers have a significant amount of non-original content. Instead of re-writes though they tend to rely on newswires and syndicated columns and comics.
Re-writes aren't just done to get a quick post, they're also done to point readers to stuff they might not otherwise read -- as jbrodkin points out, not all TC readers read TorrentFreak. There are otherwise of getting this sort of stuff out -- like maybe just doing a linkblog that points directly to a story run elsewhere. In some cases it's possible to just call the original source and get the story so you don't have to link to/re-write a competitor's work -- I do this when I can but it slows things down (example: my story on Elbrus Technologies for Wired ran two days later than all our competitors because I waited for people from the company to get back to me instead of just basing my story on the EETimes report).
So yeah, it's getting better, everyone's worried about it but it's not simple to fix.
I met Jeff Atwood while I was in San Francisco last month and thought he had a good story that hadn't gotten much mainstream press (for example, StackExchange was covered by the New York Times, [http://www.nytimes.com/2011/02/07/technology/07question.html...] but that story didn't go into the origins of the company or Atwood's "secret agenda" of tricking developers into being better communicators). The story wasn't assigned, I pitched it to Wired because I had the opportunity to interview Atwood.
I think of Atwood were to pay for press (which I very much doubt he would do) I assume he'd do so when he actually had something to announce.
The difference is that you don't have to run your own server to edit or otherwise participate in Wikipedia. You don't need your own server to have a blog on Tumblr or WordPress.com.
And since Simplest Federated Wiki requires either Ruby/Sinatra or Node.js/Express, you need more than just a shared hosting account to run it, which raises the barrier to entry (though the one-click installer, or PaaS providers, help lower it again).
It may eventually be a non-issue if someone builds a "wordpress.com for federated wikis."
As I said elsewhere, I (nor the people I quoted) meant to represent this as an alternative to Wikipedia itself. I'd see it more as some that a wiki farm like Wikia could use to allow editors to put more of their own perspective into an article (that's my opinion, not the Smallest Federated Wiki developers' opinion).
An alternative approach would be to give one publication an exclusive, and then as soon as the story runs send out the copy of a blog post from someone within the company (preferably a founder or the CTO, assuming it's a tech company) to journalists and say "we're going to run this on the company blog in an hour, but feel free to run a story with quotes from it now." That way we have something other than the competitors' story to quote from and we don't feel totally shutout.
My advice:
1) We're not all the same, no one can speak for all journalists.
2) Edward Bernays, a spin doctor so good he convinced the world that he invented PR, told Stewart Ewen that the job of PR is to instruct clients on how to "just interrupt... the continuity of life in some way to bring about the [media] response" (Ewen's book PR: A Social History of Spin) In other words, your job is making news. Easier said than done, but worth keeping in mind.
3) Read William Zinsser's book On Writing Well and apply it to all your communications. Specifically, write what you mean as simply as you can. Look at this for an example of what not to do: http://boingboing.net/2012/02/06/edward-norton-and-daria-wer...
What does that Norton quote actually say? "I liked working with these companies." That's not revealing or funny or interesting. The vast majority of executive quotes I see in press releases are like this. All they really say is "We think we have a good product." Yawn
4) Speaking of which, we hate quoting from press releases. Get someone important, like the CEO or CTO, to write a blog post that we can quote from.
5) I'm pretty technical for a journalist, but don't assume even the most technical of us are going to be able to decipher your string of buzzwords and jargon. Knowing what each word means individually doesn't mean we'll know what they mean when you use three or four of them together as a noun. Keep it simple.
6) Think about your subject line as a headline. Why would a reader read want to read your story? If a reader would want to read it, I as a journalist will want to read your e-mail. I get too many e-mails that just say "News from [some company I've never heard of]" or "big data announcement, time to talk?" I'd also throw a specific date into the subject line. Examples: "New open source operating system launches Tuesday" or "Data Released Today Shows MindFuck is the Fastest Growing Programming Language on the Web."
6) Even tech blogs want people stories. If you're stumped on how to pitch something in an interesting way, think about people. Things like ERP and tape backup are inherently boring. Find a fresh human angle. "How a big customer avoiding disaster with our solution" is a boring story. "How Dr. Steve Made a Medical Breakthrough by Studying Archival Data" or "How an Average Jane Worker Catapulted Her Career with a Simple Manufacturing Process Tweak" could be interesting stories.
As inthewoods wrote, the reason for hiring a PR person is for their contacts. Agencies will make a lot of claims about how many contacts they have, but I've heard they'll often stick low-priority accounts with junior PR people or even interns (and the quality of pitches and press releases I've seen from well known agencies about unknown companies seems to confirm this).
Jagermo wrote: "i get a lot of mails from marketing people who think they know what journalists want. Most of them do not."
I get a lot of e-mails from PR people who think they know what I want, and few do. I get a lot of the same from marketing, but a lot of journalists end up in PR or marketing at some point in their careers and they often do know what other journalists want. Some people just seem to get it, whether they've been journalists or not, and some don't. I imagine it's easier to keep track on who's doing what and how good they're doing if they're internal and not outsourced to an agency, but I wouldn't know.
FWIW, some of the best pitches for startups I've gotten have come from investors.
Here's a bit that was cut from the article, originally right after the part where I write that Duff gave couriering one last shot after moving back to Toronto:
"It was humbling," Duff says. "I only lasted four months before I decided it wasn't worth it." When he was 22, if Duff had a bad day and only brought home $70, it was OK. He shared a house with three roommates and had cheap rent and few expenses. But now if he makes only $70 in day, it's barely enough to cover child care.
"I wouldn't recommend anyone who has a family consider leaving their white collar job for couriering," Duff says. "But I think it's a very reasonable decision if you hate your job and you're in your 20s and you're single and have relatively few expenses."
Originally everything was done on dumb terminal connecting to mainframes. Then we got PCs and workstations that could run client-server applications where there UI lived on the workstation but the data still lived on a server. So let's say you have an inventory app with a desktop client. When you search for an item, the application does a query and returns a list of results from the database. You then select the one you want, it does another query and downloads some more data from the database. Then you makes some changes to the item and commit them to the database. The client uploads the change to the database by performing another query. This all works pretty well over a LAN because the server.
If something goes wrong with the server, or if your network switch or network card stops working, then the app stops working. But if you have good gear and a good IT team, that's relatively rare. You can get your work done.
Then along came Web applications. These made IT's life easier because instead of deploying a desktop client to everyone's machine, they can just install the software on the server and everyone can connect to it. It still works mostly the same way your desktop client did, except now the UI elements are downloaded to your browser when you visit the site rather than being permanently stored on your desktop.
Where things get hairy is when you're trying to access these types of systems over the Internet. There's more latency, everything seems slower. Then suddenly everyone wants access from a smart phone, where their connection speed is slower and it can drop in and out. So you start using AJAX to put more UI elements on the client side, but you're still making database calls for each action you perform.
So one thing that's new in these tools is that more data is cached locally. So your inventory app would actually download a whole bunch of data all at once so that you can query it locally, without having to hit the server each time. That creates a bunch of new problem, like handling conflicts, authentication, etc.
Another thing that's new is that there's a thinner, or perhaps non-existent, layer between the client application and database server (in the desktop client-server model, you might also have been able to connect directly to the database, depending on the architecture, so that's not necessarily all that new. I don't know enough yet about how Lotus Notes databases work, but I know that they're the direct ancestor to CouchDB).