The Pulitzer Prize-winning editor of Newsweek, Jon Meacham, is negotiating to add a television job to his schedule. He is in final talks to be the co-host of a new PBS night public affairs series called "Need to Know."

Posted by Hal Varian, Chief Economist

It is widely recognized that the news industry is facing financial difficulties, but there is little agreement about the source of those difficulties or what can be done about them. The debate about the role of the web has been particularly heated: is it the source of the problem or the source of the solution? The Federal Trade Commission is exploring questions like this through a series of workshops on the future of the news industry. At the first round in December, Josh Cohen from the Google News team spoke about how we're working with news publishers to help them attract bigger audiences and generate more revenue. The next round of the workshop kicks off in Washington D.C. this morning, and I will be speaking about the economics of news -- offline and online. I first gave this talk at the UC Berkeley Graduate School of Journalism in January and wanted to give you a summary of my remarks here.

The news industry's financial problems started well before the web came along. Circulation has been falling since 1985 and circulation per household has been falling since 1947! Ad revenue for newspapers was roughly constant in real terms up until 2005, and ad revenue per reader actually increased up until that time. Since then, the drop in advertising rates due to the recession, coupled with a significant drop in circulation, has exacerbated newspapers' financial difficulties.

In the last five years many more people have been reading the news online: About 40% of internet users say they looked at online news “yesterday.” Higher income households report even larger numbers, making online news readers a potentially attractive audience for advertisers.

However, visitors to online newspaper sites don't spend a lot of time there. The average amount of time looking at online news is about 70 seconds a day, while the average amount of time spent reading the physical newspaper is about 25 minutes a day. Not surprisingly, advertisers are willing to pay more for their share of readers' attention during that 25 minutes of offline reading than during the 70 seconds of online reading. So even though online advertising has grown rapidly in the last five years, it appears that somewhat less than 5% of newspapers' ad revenue comes from their internet editions, according to the most recent Newspaper Association of America data.

There's a reason for the relatively short time readers spend on online news: a disproportionate amount of online new reading occurs during working hours. The good news is that newspapers can now reach readers at work, which was difficult prior to the internet. The bad news is that readers don’t have a lot of time to devote to news when they are supposed to be working. Online news reading is predominately a labor time activity while offline news reading is primarily a leisure time activity. One of the big challenges facing the news industry is increasing involvement with the news during leisure hours, when readers have more time to look at both news content and ads.

What about search engines? Many readers go directly to their favorite news site, but a good fraction use search engines to access news specific news topics. According to comScore, clicks from search engines account for 35-40% of traffic to major U.S. news sites. Since most newspaper ads are priced on a per-impression basis, this means that 35-40% of major U.S. newspaper online revenue is coming from search engine referrals. That is a big fraction of online advertising revenue but, as we saw above, online ad revenue is only about 5% of the total.

Furthermore, the real money in search engine advertising is in the highly commercial verticals like Shopping, Health, and Travel. Unfortunately, most of the search clicks that go to newspapers are in categories like Sports, News & Current Events, and Local, which don’t attract the biggest spending advertisers.

This isn't so surprising: the fact of the matter is that newspapers have never made much money from news. They’ve made money from the special interest sections on topics such as Automotive, Travel, Home & Garden, Food & Drink, and so on. These sections attract contextually targeted advertising, which is much more effective than non-targeted advertising. After all, someone reading the Automotive section is likely to be more interested in cars than the average consumer, so advertisers will pay a premium to reach those consumers.

Traditionally, the ad revenue from these special sections has been used to cross-subsidize the core news production. Nowadays internet users go directly to websites like Edmunds, Orbitz, Epicurious, and Amazon to look for products and services in specialized areas. Not surprisingly, advertisers follow those eyeballs, which makes the traditional cross-subsidization model that newspapers have used far more difficult.

Some have argued that the solution to the financial problems of newspapers is to charge for access. Many people place a high value on news, and there is clearly a significant social value to having a well informed citizenry. The problem is that there is a lot of competition among news providers, and this competition tends to push prices down. News sources that have highly differentiated content may be able to make pay-for-access work, but this will likely to be difficult for more generic news sources.

In my view, the best thing that newspapers can do now is experiment, experiment, experiment. There are huge cost savings associated with online news. Roughly 50% of the cost of producing a physical newspaper is in printing and distribution, with only about 15% of total costs being editorial. Newspapers could save a lot of money if the primary access to news was via the internet.

New tablet computers like the Kindle, iPad, and Android devices may encourage people to read online news at home in the comfort of their easy chairs. At Google, we certainly don't think we have all the solutions, but we are definitely keen on working with the news industry to help it attract bigger audiences and generate more ad revenue. Experiments like Fast Flip, Living Stories and Starred Stories may help pull together the at-work and at-home access to the news. Online news access on handheld device like cell phones and tablets is likely to be quite different from traditional newspapers reading, with much more multimedia content, interactivity and reader involvement. The transition to a fully online news will be difficult, but there's a good chance that we will emerge with a significantly more compelling user experience.

Adrian Holovaty, in his post “A fundamental way newspaper sites need to change,” writes (emphasis mine):

So much of what local journalists collect day-to-day is structured information: the type of information that can be sliced-and-diced, in an automated fashion, by computers. Yet the information gets distilled into a big blob of text — a newspaper story — that has no chance of being repurposed.

He has a point, and goes on to explain why we need a CMS that can hold semantic structured data because journalism on the web should be more than just blobs of text.

This is totally correct, and the rapid proliferation of news apps and data-driven news organizations is an awesome thing, especially when it lets you do stuff like put in a zip code and see if the water you’ve been drinking is toxic, or how many people have been mugged in the last week on your block. But it also negates (or rather maybe tries to actively obsolesce) something very fundamental to journalism: the story. Holovaty says in the article: “Newspapers need to stop the story-centric world-view.” My question to this is, why?

There will always be a “news blob”— the fundamental block of data that every piece of news has, and every blogging system can handle: a title (headline), a body (story) and a permalink. Bylines and photos are important too, but they can, in a sense, be subsumed into these three primary types. We’ve been so blinded by data, that we’ve lost sight of the humble blob. Why is Twitter so popular? Because they’ve figured out how to distill these elements down to just one field, and limit the amount you can put into it.

The idea of a blob is so great because it can be anything. In a version control system like Git, a blob is just a bunch of text. It doesn’t care what you’re writing or how you organize it. It doesn’t even have awareness of files, but it can handle whatever you throw at it. When you’re on deadline, you need software that thinks like Git, that can handle the blob you’re throwing at it.

Why Write a CMS?

A big skill you grapple with as a newbie software developer is how to recognize solved problems. If you squint, there is usually an opportunity for a new app in the cracks between them. A while back there was a hilarious response on StackOverflow to a user who was asking for help parsing HTML with regular expressions. While the verbose answer is incredible, the simple answer is you don’t— you use a library to consume HTML. It’s a solved problem.

From a news point of view, getting story data from a writer and keeping it in a database is a solved problem. There is excellent free software out there that does this much better than I could ever hope to. What blogware does not do well is arrange stories hierarchically. Where Holovaty is right is that these blobs (and 99% of news on the web now is in blob-form) need to be repurposed, because blogware isn’t designed with news judgement in mind. This is why I wrote Homer. Homer is for news homepages.

How it works

Homer works through XML feeds, which I, yes, use a library to parse. Stories from those feeds can then be assigned to slots which live at arbitrary places on your homepage that you place where you want and label semantically. Once there, stories can be moved between slots or unassigned into oblivion. In a sense, Homer is a blog disaggregator. It allows you to add as many feeds as you want, and cherry-pick stories from them to live in your homepage until you bump them for other stories. It is transient, where blogware plans for permanence. It is serendipitous, where blogware plans for order. It is hand-curated, where blogware rewards predictability and automation. It is hierarchical, where blogware is chronological. Homer is to WordPress as TPUTH is to TechCrunch. In short, they work well together. To steal the tagline from Underscore.js, Homer is the tie to (Movable Type|WordPress|Tumblr|ExpressionEngine)’s tux.

While you can use Homer to “curate the web” because all you need to add a feed is its URL, its newsroom use case is to serve as your homepage and hand-arranged topic pages, sitting atop a sea of template-generated back pages.

Here’s how you use it:

The home page of Homer shows lists of the two basic objects in the app, homepages and feeds. Incidentally, these two objects have a has_and_belongs_to_many relationship in the database, so they can be reused. In other words, a feed can be used on as many homepages as you’d like after entering its title and URL once. The home page shows you the raw material you’ll use to construct your pages. The edit/delete nubbins allow you to change the file paths and titles of your homepages and titles/urls of feeds.

The Manage page is where all the action happens in Homer. This is where you define slots for your homepage, assign feeds to your homepage, assign stories to slots, and rearrange stories within slots. Let’s look at each of these features in order:

Slots: When you create a new homepage, you’ll first want to create your slots. There is no inherent style to default Homer homepages, so you can be free to devise your own hierarchy. A feature might be the top story. Then a subfeature. Or maybe define them by location: left, middle, right. When you get to templating, Homer will auto-generate code to surface slots based on their labels. At this point, slot labels can’t be edited.

Feeds: The feed menu allows you to assign/remove feeds from the general pool to this homepage. Once they have been assigned, they’ll show up in the left menu to be “refreshed” whenever you want a selection of stories to put into slots.

Assignment: There are two kinds of assignment in Homer: Assignment from feed stories to slots, and rearranging stories within slots. When you refresh a feed, its latest stories will show up in a yellow area on the right side of the screen. You can refresh multiple feeds at the same time, and they will all be mixed into that area. From there you can edit the titles, bodies and permalinks (click the down arrow next to the title to reveal the other fields) and assign them to slots via the dropdown menus. Once a story has been assigned to a slot, it will show up in a grey area at the top of the page with the dropdown already filled in for the slot it is currently assigned to. If you assign a story to an already-filled slot, it will “bump” that story in favor of your new story. Once your story is assigned, you can move it around by changing the slots in the dropdowns, and hitting save. Assigning a story to the “blank” option will unassign it.

The assignment system is built with transience in mind. It is built for the present, the fierce urgency of the now. Call it opinionated software. Only the last 5 entries in a feed will be available when refreshed, and once a story has been unassigned, it is all but gone from the system. But don’t be afraid of this— your blogware of choice is good at keeping archives, and hopefully it will give you an automatically generated list of your posts somewhere. Homer is for bumping stories at will. A good workflow may be refreshing your feed, then assigning a battery of stories to your slots in the morning. Then cycling stories down the slots while putting new stories in the top slot until they fall off the page a la Techmeme-style aggregators. If you must get a story back, try refreshing the feed from which it came and reassigning it. Homer doesn’t support dredging up bumped stories for reassignment because no one likes old news.

Templating: While Homer won’t style your homepages for you, it will provide you with boilerplate code to start you off. After you’ve created all your desired slots, click on the Template button at the top of the page. You should see a bunch of code already in your editor. You’ll get a stock HTML wrapper, and for every slot, you’ll get one of these, assuming your slot is called feature:

<div id="feature">
 <% @feature = Ho.new(@homepage,'feature') %>
 <h2><a href="<%= @feature.url %>"><%= @feature.title %></a></h2>
 <p><%= feature.body %></p>
</div>

The wrapper is a standard html div, and inside are slot-specific variables. Ho is the templating class for Homer, and line 2 uses it to instantiate a new slot on the page. Once you have done that, you can use the new variable, in this case @feature to output that slot’s attributes wherever you want. Homer uses ERB (Embedded Ruby) to output variables, so anything within <% and %> will be parsed as Ruby code. In the boilerplate, @feature.url is wrapped around @feature.title, followed by @feature.body in a paragraph block. You can, however, edit the code to output these variables wherever you want, as long as you instantiate the slot first. If you’d like, you can move all of the slot inits to the top of the page and out of the markup. Also, as of now, unless you have access to your server’s filesystem, you’ll need to write all your style inline much like you do with Tumblr templates.

Aside— A few thoughts (caveats) on templating and Ruby DSLs: This is really only a first stab at a good templating language for Homer. I had a few more syntax ideas, and am still mulling the best way of doing it. Admittedly my current implementation is crufty. Ruby is really good for creating Domain Specific Languages (Sinatra itself is a good example), and I need to read up on best practices. This will be a major focus for the next version of Homer.

Once you have the code the way you like it, hit Save. This will also create a file in the filesystem at homer/templates/your_homepage.erb (the path to this template is also shown at the top of the template editor to encourage you to edit in a text editor) because storing templates in a database sucks. Once you save (or save from your text editor), you can preview your new homepage design at any time and to publish it to the world.

Previewing and Publishing:

Finally, the fun part where all your hard work pays off. Previewing your homepage will give you a new window where you can see exactly what your page will look like to the outside world. Publishing will write your homepage out to the place in the filesystem you defined when creating it. This should be some place that serves static files, like an Apache Document Root. When you publish, the homepage you direct your audience to is 100% static, so load is basically a nonissue. Homer will do its best to resolve permissions issues when you set up the path, but it may not be able to publish if it doesn’t have access to the directory, so plan accordingly.

That’s basically it. It’s a fun news app for writing static homepages from feeds.

Under the Hood, and Philosophy

Homer is written in Ruby with Sinatra and ActiveRecord. Since starting the TPM PollTracker, I’ve been smitten with Rails-style development. ActiveRecord, for database interaction, might be one of my favorite pieces of software ever. One thing I hate about Rails, though, is how it does routing. Sinatra connects controller actions directly to URLs, which is much easier for me to wrap my head around. It also doesn’t impose a filesystem structure for your app. In fact, the only thing it assumes is that you are writing something in Ruby that uses URLs. That’s just the right amount of opinionation for me. Maybe Rails 3 will allow me to pick and choose how much framework I want, but for now Sinatra + AR gets me 90% of the way there.

With Homer, I’m also putting my stake in the ground for a few principles and (what I believe to be) best practices in CMS design:

First, you host it yourself. Movable Type and WordPress have blazed the trail for casual users to self-install server-based web apps, and the fact that this has been catching on is a Good Thing for a number of reasons: less reliance on third parties to be good stewards of your data, demystification of how web-based software works, and more agency given to the end user are a few of them. Mint and Fever are good examples of how this is becoming a viable distribution method with PHP and mySQL apps. My hope is that the Ruby stack will continue to evolve, so Ruby-based software will become as easy to install as WordPress.

Second, it’s open source. Homer is built on open source software, and the Ruby community lives on free open source software. I’m a big believer in it.

Third, it generates static pages. Caching sucks. I’ve spent an inordinate amount of time on PollTracker working on caching, and even moving hosts over it. While most people agree that static pages are the best way to serve content (no one can disagree that it is the fastest), there are different approaches on how best to generate them (and how to expire them). For sites with a large number of pages, I like the Rails page caching method: expire data when it is changed, and give the brunt of caching each page to its first visitor. This makes deployment easy, and allows you to roll out a global change instantly. Movable Type does the opposite: it generates static pages at time of publish. This puts the brunt of publishing wait on the author, and also makes it very difficult to roll out template changes across an entire site. For one page, though (one that is assumed to be constantly changing), I prefer this method. It also means that the outward-facing server doesn’t have to run the slow Ruby stack at all, and no caching has to be done within the app itself.

Fourth, the templates are files. They aren’t stored in the database. This is one area where WP (and most web frameworks) have a leg up on MT and EE. The database should be used to populate template variables, and store as little markup as possible. Storing templates in the database makes them tough to republish, and makes it really difficult to edit them in a text editor, unless you want to do a lot of copy and pasting.

Inspirations

Where did I get this idea? A couple different things gelled into me needing to write this app. The first was a lunch I had with Scott Klein of ProPublica a few months ago, where we talked about CMS design and basically agreed it is a mistake to develop against your CMS. ProPublica uses ExpressionEngine for their stories, and spins up EC2 instances for their Rails apps. They integrate the two mostly through style. Homer works along these lines, and Scott got me thinking down that path.

Secondly, I was inspired by two Movable Type plugins from SixApart. The first, SqueezePlay (which unfortunately has not been open-sourced) is a homepage manager that uses the story assignment/slot metaphor, and is what we use at TPM to handle our front page. The other is Reblog, an awesome MT plugin that parses RSS feeds into MT entries. Homer is kind of SqueezePlay + Reblog, but outside the CMS.

Thirdly, a group of my friends from the University of Chicago are starting a new (as of yet unreleased) online magazine, albeit a “deconstructed” magazine which will collect content from a wide variety of sources and contributors and mash it together. This provided an initial use case that spurred development. Since I was developing Homer for free, I decided to open-source it as a community journocoding project. I hope it will prove useful to others!

Get it!

To install Homer, first make sure you have a newish version of Ruby— 1.8.6 and higher is required for the current version of Rubygems (1.3.6). Then install Rubygems, and gem install sinatra activerecord sqlite3-ruby feedme. Now you’re ready to install Homer.

If you have git, just

git clone git://github.com/ashaw/homer.git
cd homer/bin
./homer init //to set up SQLite db and templates dir
./homer run

then open a browser to http://localhost:4567

or grab the tarball or zipball, uncompress and start at step 2 above.

To install on an Apache web server, the best way is to install the Phusion Passenger gem, follow the instructions to set it up, and make a VirtualHost for Homer, like so (I recommend setting up a password in htpasswd for Homer since the app doesn’t support authentication):

<VirtualHost *:80>
     ServerName homer.yourdomain.com
     DocumentRoot /var/www/homer/public
     <Directory /var/www/homer/public>
        AllowOverride all
        Options -MultiViews
        AuthType Basic                  
        AuthName "Restricted"
        AuthUserFile /var/www/yourpasswords
        Require user youruser
     </Directory>
</VirtualHost>

To start and restart the app, just touch tmp/restart.txt from your Homer root directory, don’t homer run, Passenger will take care of the rest.

Obviously, this is still very much alpha (perhaps pre-alpha) software, so act accordingly. I’d love to get your feedback, bug reports, comments, etc. And you should follow me on twitter here.

Foursquare, a location-based social network, is rolling out new tools that will give businesses more information about their customers and allow them to target special offers.

Thanks to lobbying, Congress chooses to subsidize foods that we're supposed to eat least of.

The entire family of devices built on the iPhone OS (iPhone, iPod Touch, iPad) have been designed to run only software that is approved by Apple—a major shift from the norms of the personal computer market. Software developers who want Apple's approval must first agree to the iPhone Developer Program License Agreement.

So today we're posting the "iPhone Developer Program License Agreement"—the contract that every developer who writes software for the iTunes App Store must "sign." Though more than 100,000 app developers have clicked "I agree," public copies of the agreement are scarce, perhaps thanks to the prohibition on making any "public statements regarding this Agreement, its terms and conditions, or the relationship of the parties without Apple's express prior written approval." But when we saw the NASA App for iPhone, we used the Freedom of Information Act (FOIA) to ask NASA for a copy, so that the general public could see what rules conrolled the technology they could use with their phones. NASA responded with the Rev. 3-17-09 version of the agreement (it has reportedly been revised somewhat since—please send us the current version if you are able).

This "license agreement" is particularly relevant right now, given the imminent launch of the iPad and anytime-now issuance of the U.S. Copyright Office's ruling regarding jailbreaking of the iPhone.

So what's in the Agreement? Here are a few troubling highlights:

Ban on Public Statements: As mentioned above, Section 10.4 prohibits developers, including government agencies such as NASA, from making any "public statements" about the terms of the Agreement. This is particularly strange, since the Agreement itself is not "Apple Confidential Information" as defined in Section 10.1. So the terms are not confidential, but developers are contractually forbidden from speaking "publicly" about them.

App Store Only: Section 7.2 makes it clear that any applications developed using Apple's SDK may only be publicly distributed through the App Store, and that Apple can reject an app for any reason, even if it meets all the formal requirements disclosed by Apple. So if you use the SDK and your app is rejected by Apple, you're prohibited from distributing it through competing app stores like Cydia or Rock Your Phone.

Ban on Reverse Engineering: Section 2.6 prohibits any reverse engineering (including the kinds of reverse engineering for interoperability that courts have recognized as a fair use under copyright law), as well as anything that would "enable others" to reverse engineer, the SDK or iPhone OS.

No Tinkering with Any Apple Products: Section 3.2(e) is the "ban on jailbreaking" provision that received some attention when it was introduced last year. Surprisingly, however, it appears to prohibit developers from tinkering with any Apple software or technology, not just the iPhone, or "enabling others to do so." For example, this could mean that iPhone app developers are forbidden from making iPods interoperate with open source software, for example.

You will not, through use of the Apple Software, services or otherwise create any Application or other program that would disable, hack, or otherwise interfere with the Security Solution, or any security, digital signing, digital rights management, verification or authentication mechanisms implemented in or by the iPhone operating system software, iPod Touch operating system software, this Apple Software, any services or other Apple software or technology, or enable others to do so

Kill Your App Any Time: Section 8 makes it clear that Apple can "revoke the digital certificate of any of Your Applications at any time." Steve Jobs has confirmed that Apple can remotely disable apps, even after they have been installed by users. This contract provision would appear to allow that.

We Never Owe You More than Fifty Bucks: Section 14 states that, no matter what, Apple will never be liable to any developer for more than $50 in damages. That's pretty remarkable, considering that Apple holds a developer's reputational and commercial value in its hands—it's not as though the developer can reach its existing customers anywhere else. So if Apple botches an update, accidentally kills your app, or leaks your entire customer list to a competitor, the Agreement tries to cap you at the cost of a nice dinner for one in Cupertino.

Overall, the Agreement is a very one-sided contract, favoring Apple at every turn. That's not unusual where end-user license agreements are concerned (and not all the terms may ultimately be enforceable), but it's a bit of a surprise as applied to the more than 100,000 developers for the iPhone, including many large public companies. How can Apple get away with it? Because it is the sole gateway to the more than 40 million iPhones that have been sold. In other words, it's only because Apple still "owns" the customer, long after each iPhone (and soon, iPad) is sold, that it is able to push these contractual terms on the entire universe of software developers for the platform.

In short, no competition among app stores means no competition for the license terms that apply to iPhone developers.

If Apple's mobile devices are the future of computing, you can expect that future to be one with more limits on innovation and competition (or "generativity," in the words of Prof. Jonathan Zittrain) than the PC era that came before. It's frustrating to see Apple, the original pioneer in generative computing, putting shackles on the market it (for now) leads. If Apple wants to be a real leader, it should be fostering innovation and competition, rather than acting as a jealous and arbitrary feudal lord. Developers should demand better terms and customers who love their iPhones should back them.

Excruciating up-to-the-minute coverage of some irrelevant bullshit story that has no ramifications whatsoever.

Rebecca Zook is an online female math tutor who has been helping students get math into their brains for seven years. She blogs about learning at Triangle Suitcase.

Over half a million votes were cast to decide Barbie’s newest career. But even though Computer Engineer Barbie was developed in consultation with the Society of Women Engineers and the National Academy of Engineering, the new doll’s appearance has sparked controversy.

While some have embraced coder Barbie, others have attacked the concept, saying that her pink laptop, sparkly leggings, and trendy glasses are “too feminine” to be realistic.

The critics imply that real coders aren’t feminine, and feminine coders aren’t real. But women shouldn’t feel like they have to stop being feminine to work in technology.

---

The First Computer Programmer Was a Fashionista

---

That’s right. The first coder was a lady. Ada Lovelace, over a century ahead of her time, is widely considered to be the first computer programmer. She was the first person to conceptualize and articulate what computers were capable of doing, and the first to foresee that computers could create artificial intelligence, generate graphics, and create music.

So, is Barbie’s outfit really that unrealistic? If the very first person to conceptualize a computer did so while wearing a girly up-do and a frilly gown, why can’t someone write great code while wearing pink platform crocs and a t-shirt that spells “BARBIE” in binary?

---

Women and Tech Today

---

This false dichotomy — that you have to choose between being feminine and “looking the part” of a mathematician or scientist — might be part of what turns girls off from math and science in the first place.

Or maybe girls don’t aim for careers in math and science because they don’t see role models. Even Ada Lovelace had role models. Her mom, the “Princess of Parallelograms,” loved math and gave Lovelace a very intensive math education. And Lovelace was also mentored by legendary female science writer and polymath Mary Somerville.

Or maybe girls are afraid of being the only woman in their technology courses or workplaces. If that’s the case, their concerns are certainly warranted. Not only are fewer women entering the information technology field, but more women are leaving the field mid-career.

A recent Harvard Business Review report, The Athena Factor, notes that “52% of highly qualified females working for SET [science, engineering, and technology] companies quit their jobs, driven out by hostile work environments and extreme job pressures.” These women report that they lack mentors and feel intense isolation in the workplace.

---

Coder Barbie and the Future

---

In 2010, maybe Computer Engineer Barbie would feel uncomfortable writing code on a pink laptop that matched her glasses in a workplace where she was outnumbered by men 25-to-1. But perhaps we should aspire to create a world where Computer Engineer Barbie and her gloriously pink accessories could realistically exist. Allowing a vision of an ultra-feminine computer engineer might, even subconsciously, open girls — and the rest of society — up to the possibility.

As a female math tutor, I used to feel the need to “tone down” my feminine style. I’d wear black slacks when working with my students for fear of appearing “unprofessional.” But then I decided to show my true fashion colors and wear my homemade dresses and sparkly barrettes when tutoring.

Since then, some kids have been openly relieved when they met me and found I didn’t look like their stereotype of a math tutor. The “math geek” stereotype in their brains was more intimidating and less fun than the real-life tutor wearing fuzzy pink boots.

You don’t have to choose between looking feminine and being good at math, science, and engineering. We need all kinds of people, all kinds of minds, and all kinds of geeks to solve our technology problems.

---

More tech resources from Mashable:

---

- 10 Essential Chrome Extensions for Web Developers
- 10 Popular Firefox Add-ons for Web Developers
- 5 Must-Have Geek Collectibles

Tags: barbie, careers, coder, computer engineer, girls, Kids, mathematics, programming, Science, tech, trending, women

Facebook’s move into location has seemed inevitable for some time, and it now appears that the company will officially reveal its plans at next month’s Facebook developer conference – f8.

According to The New York Times, the social network will incorporate location in two ways: (1) its own features for sharing location and (2) APIs to let other apps – like Foursquare and Gowalla – offer location services to Facebook users.

Presumably, Facebook will make sure to address privacy issues with its location features — for example, perhaps with settings that allow you to share your location only with a select group of friends. The Times’ report doesn’t detail the specifics of such features, though it notes that the social network updated its privacy policy late last year in preparation for a location launch.

Facebook will be rolling out its location features to an enormous user base — there are now more than 400 million users of the social network in total, 100 million of which access the site via mobile regularly. The company also has its own native apps for all of the major mobile platforms. All of this gives Facebook’s location features an enormous edge over the competition.

The Times’ report suggests that the competition isn’t the likes of Foursquare and Gowalla, however, but rather Google and its huge base of local small business advertisers. Of course, the startups aren’t ignoring this opportunity either — earlier today, Foursquare shared details of upcoming features it plans to release to help local businesses utilize checkin data.

With Facebook entering the space though, the other players will need to look to create value in ways beyond check-ins and knowing where your friends are located at any given point in time. That’s why Foursquare seems to be so focused on partnerships and gaming, while Gowalla is making moves (as recently as last night) in virtual goods.

In any event, location remains the huge trend so far in 2010, and literally each day seems to bring new indications of which way it will all play out.

---

Reviews: Facebook, Foursquare, Google, Gowalla

Tags: facebook, foursquare, social networking, trending

The Huffington Post removed a 9/11 "Truther" post from former Minnesota Governor Jesse Ventura. According to their editor's note, "The Huffington Post's editorial policy, laid out in our blogger guidelines, prohibits the promotion and promulgation of conspiracy theories...." Oh, really? More »

He acknowledges exercising poor judgment, recalling tickling an aide during a birthday party.

When I started posting my new series of Facebook data points, one of the most requested graphs was the days of the week (and times of day, which is coming soon) that are best to publish on to get lots of Facebook shares. What I found when I looked at days of the week is at first a little unexpected, but upon further thought fairly logical.

While I found less articles posted on the weekends (notice the gray bars at the bottom of the graph which indicate volume of URLs analyzed for each day), those stories that were published on the weekends tended to be shared on Facebook more, on average, than stories that were published during the week. The reasons for this probably include the fact that more than half of companies in the US block Facebook, so people can only use the social network at home, on the weekends. Additionally, the mainstream Facebook audience does not use Facebook for work.

The takeaway? If you want your article to be shared on Facebook by your readers, try posting it over the weekend.

For information on my methodology, start with this post. For this data point I’m using over 5000 stories and “average” is the interquartile mean which is less sensitive to outliers. The 0% line indicates the average number of “shares” stories from each site in my study get, when the line is above 0% it means that stories on that day are shared more than the average, and when it is below, they’re shared less. If you’re curious why it appears most of the stories in the data set are above average, this is because of the difference in the volume of published stories on various days.

---

Buy The Social Media Marketing Book here.

Download the Science of ReTweets Report here.

Don't forget to follow me on Twitter

.

New location-based social search tool FourWhere shows Foursquare tips and comments using Google Maps so you can search and discover what everyone is saying about nearby places.

Users simply input a location or address into FourWhere, right-click (control click) on the map and select display preferences. The map can display all comments nearby, all venues in the vicinity and/or remove venues without tips.

It’s a simple app with a powerful purpose. For those of us preparing to journey out to Austin for SXSW, FourWhere’s release couldn’t have come at a better time. A search around the downtown area yields comments with insightful information about restaurants and bars. Essentially the application offers a map-based search experience for socialites looking to plan a fun night out.

FourWhere currently only pulls in data from Foursquare, but Sysomos, the company behind the app, has plans to integrate more social data in the future.

---

Reviews: Foursquare

Tags: foursquare, fourwhere, location-based, sysomos

The company is using its network to push the limits of translation technology; its free service has become the favored source for millions.

Newport News Daily Press | Chicago Tribune
The Daily Press will pink-slip most of its copy editors and designers as their functions move to the Chicago Tribune. "I think this eventually could add $1 million to the bottom line," says publisher Digby Solomon.

I feel for Google – Steve Jobs threatened to sue me, too.

In 2003, after I unveiled a prototype Linux desktop called Project Looking Glass*, Steve called my office to let me know the graphical effects were “stepping all over Apple’s IP.” (IP = Intellectual Property = patents, trademarks and copyrights.) If we moved forward to commercialize it, “I’ll just sue you.”

My response was simple. “Steve, I was just watching your last presentation, and Keynote looks identical to Concurrence – do you own that IP?” Concurrence was a presentation product built by Lighthouse Design, a company I’d help to found and which Sun acquired in 1996. Lighthouse built applications for NeXTSTEP, the Unix based operating system whose core would become the foundation for all Mac products after Apple acquired NeXT in 1996. Steve had used Concurrence for years, and as Apple built their own presentation tool, it was obvious where they’d found inspiration. “And last I checked, MacOS is now built on Unix. I think Sun has a few OS patents, too.” Steve was silent.

And that was the last I heard on the topic. Although we ended up abandoning Looking Glass, Steve’s threat didn’t figure into our decision (the last thing enterprises wanted was a new desktop – in hindsight, exactly the wrong audience to poll (we should’ve been asking developers, not CIO’s)).

As in life, bluster and threat are commonplace in business – especially the technology business. So that interaction was good preparation for a later meeting with Bill Gates and Steve Ballmer. They’d flown in over a weekend to meet with Scott McNealy, Sun’s then CEO – who asked me and Greg Papadopoulos (Sun’s CTO) to accompany him. As we sat down in our Menlo Park conference room, Bill skipped the small talk, and went straight to the point, “Microsoft owns the office productivity market, and our patents read all over OpenOffice.” OpenOffice is a free office productivity suite found on tens of millions of desktops worldwide. It’s a tremendous brand ambassador for its owner – it also limits the appeal of Microsoft Office to businesses and those forced to pirate it. Bill was delivering a slightly more sophisticated variant of the threat Steve had made, but he had a different solution in mind. “We’re happy to get you under license.” That was code for “We’ll go away if you pay us a royalty for every download” – the digital version of a protection racket.

Royalty bearing free software? Jumbo shrimp. (Oxymoron.)

But fearing this was on the agenda, we were prepared for the meeting. Microsoft is no stranger to imitating successful products, then leveraging their distribution power to eliminate a competitive threat – from tablet computing to search engines, their inspiration is often obvious (I’m trying to like Bing, I really am). So when they created their web application platform, .NET, it was obvious their designers had been staring at Java – which was exactly my retort. “We’ve looked at .NET, and you’re trampling all over a huge number of Java patents. So what will you pay us for every copy of Windows?” Bill explained the software business was all about building variable revenue streams from a fixed engineering cost base, so royalties didn’t fit with their model… which is to say, it was a short meeting.

I understand the value of patents – offensively and, more importantly, for defensive purposes. Sun had a treasure trove of some of the internet’s most valuable patents – ranging from search to microelectronics – so no one in the technology industry could come after us without fearing an expensive counter assault. And there’s no defense like an obvious offense.

But for a technology company, going on offense with software patents seems like an act of desperation, relying on the courts instead of the marketplace. See Nokia’s suit against Apple for a parallel example of frivolous litigation – it hasn’t slowed iPhone momentum (I’d argue it accelerated it). So I wonder who will be first to claim Apple’s iPad is stepping on their IP… perhaps those that own the carcass of the tablet computing pioneer Go Corp.? Except that would be AT&T. Hm.

Having watched this movie play out many times, suing a competitor typically makes them more relevant, not less. Developers I know aren’t getting less interested in Google’s Android platform, they’re getting more interested – Apple’s actions are enhancing that interest.

Sun was sued numerous times – most big companies are sued almost constantly by entities or actors whose sole focus is suing others. Groups with no business focus other than litigating patent suits are affectionately known as trolls – pure litigation entities. (For good humor, read this, an application to patent the act of trolling. If granted, it would give the patent holder a reciprocal claim against a patent troll.)

The most egregious of such suits was filed against Sun by Kodak (yes, the film photography people).

Egregious, because Kodak had acquired a patent from a defunct computer maker (Wang) for the exclusive purpose of suing Sun over an esoteric technology, Java Remote Method Invocation (“Java RMI” – not exactly the first thing that comes to mind when you hear “Kodak”). Given how immature Kodak’s technology business was (they were just starting out in the digital world), we had little we could respond with – I suppose we could’ve hunted for a Wang-like opportunity to hit at their core, but Kodak was a customer, which certainly complicated things, and the time and expense involved would’ve been prohibitive.

Their case was eventually heard before a jury in Rochester, New York, famous for being home to… the Eastman Kodak company. Lo and behold, the local jury decided Sun should pay Kodak more than a hundred million dollars. So here’s something I could never say as Sun’s CEO.

I prefer SmugMug.

__________________________

*To see a Looking Glass demo, click here - it starts at the ~2:00 minute mark.