The Locker Project: Why Leave Data Tracking to Others? Do It Yourself


With companies looking to follow your data trail online, why not take possession of that information and find innovative uses for it yourself? That’s the question Jeremie Miller — the developer known for building the open-source protocol that powers many Instant Messaging programs — is trying to answer. Miller is building The Locker Project, an open-source effort that allows users to capture and archive their own online “data exhaust,” the term used for the crumbs of data we leave behind as we move around the web.

Using APIs and feeds, the Locker Project will pull in tweets, updates, pictures, check-ins, transactions, contacts and webpages, and will allow a user to store it on his or her own server or as part of a hosted service similar to the blog platform WordPress. Miller’s company will provide the support for the open-source project. Readwriteweb has a good first look at the service. The idea is an interesting one, because it will give people a repository of their online behavior, where they can see at a glance what kind of trail they’ve left online, and look for patterns inside that data. The service is one of an emerging group of companies that are aimed at helping users capture their personal data, including Statz, Greplin and

Where things could get really interesting, however, is that The Locker Project is looking to have developers build apps on top of the service. Those apps — with permission from users — will be able to analyze a user’s data and extract trends and other interesting information. A user could get more personalized recommendations or a better assessment of behavior or spending habits, or someone with a medical condition might get a pre-diagnosis based on the symptoms he or she been searching for information on.

It’s a compelling idea that builds on the power of data — something we’ll be talking about at our Structure Big Data Conference in New York on March 23. People are creating huge amounts of information as they move around the web, but it’s not being leveraged very well, or if it is being leveraged, it’s big companies and marketing services like Rapleaf that are taking advantage of it.

Citibank spun out a project called Bundle that takes millions of anonymous user transactions and builds recommendations based off of that for customers. But the future lies in taking in personal data and crafting highly customized services: BankSimple, a New York-based start-up, is poised to launch a next-generation banking service that takes in a user’s data and preferences and builds a personalized finance system for them. BillGuard,another start-up that just won $3 million in funding, also leverages personal banking data and uses that to build a fraud alert system.

The challenge for many of these services — including The Locker Project — is that it will take a certain amount of trust for a user to give up their data. But if users do believe that their privacy is protected, and the results will be beneficial, it could open up a lot of opportunities: When you apply big data analysis to personal data, you can surface unseen trends, correlations and patterns, and it can also bring consumers closer to marketers on their own terms. Kaliyah Hamlin, the executive director of the Personal Data Ecosystem Collaborative Consortium, said recently that, rather than tracking or stalking users online, marketing and advertising companies should learn to empower users to hold on to their data, then share it with them willingly:

Giving individuals choice about where they store their personal data and who has access to it, and under what terms and conditions, grows trust. This trust is hugely valuable, because over time  more and better services that combine and utilize valuable personal data can be offered. It supports new forms of advertising and marketing by enabling trusted relationships between customers and vendors that enable “relationship marketing” and opt-in, user controlled sharing of data, permissioned communications and offers, group buying, recommendations, social and viral marketing, more efficient commercial exchanges.

We’re still a ways off from something like this being mainstream, of course. Users have to get used to storing their own data, and companies will have to learn to work with consumers rather than go the easier route to track them. And the fact that Do Not Track proponents are pushing for more regulations of that kind of activity, working with consumers on a more level playing field might be the best resolution for all.

original post :

Posted in Uncategorized | Leave a comment


[互联网产品的三大要素是:服务、信息、人。之前(包括 Google 在内)做互联网的模式是“服务为中心,串联起人和信息”,Facebook 不管是有心还是无意,逐渐在把模式变成“人为中心,串联起服务和信息”。]

Written by guwendong on 2011-01-24 — Leave a Comment
本文可以任意转载,转载时请务必以超链接形式标明文章 原始出处 与 版权信息

“搜索已死,推荐上位”,这句话是去年9月份,我在 Resys Group 的一个帖子里面提的。这是典型的标题党,但我想要表达的意思,你懂的。

搜索死了吗?答案是“肯定没有”。“寻找信息”是刚性需求,搜索会 Forever Young。但它一定会变得越来越不性感,对于业界顶尖工程师会越来越丧失吸引力,大家会转去追逐更能吸引他们的事情。下面关于“Search Engine”的 Google Trends 可以说明一些问题。


如果大家关心推荐领域的话,过去一年会发现一些有意思的事情:首先,推荐的探索越来越多,各种新产品冒头的频率越来越快。然后,越来越多人看到了个性化的重要性。问 GroupOn 如何应对山寨,他说我要做个性化团购;问 FourSquare 如何应对 Facebook Places,他说我要推出个性化推荐。最后来看 Google,Google说了,“搜索的未来要靠个性化”,Google 也确实在积极地布局个性化。甚至连那个致力于搞局域网的公司,也都已经开始谈论这个话题了。

之前忘了在哪儿看到一个分析,是讲 Facebook 的开放平台,意思是说,用户更习惯去专业的网站解决特定的问题,而不是在一个大平台上解决所有问题。大平台的模式本身也不符合互联网的本质以及现代社会分工协作的基本经济准则。Resys 建组之初曾经讨论过“推荐能不能做成一种基础服务” [1]。豆瓣的推荐引擎大拿胖子也一直在思考这个问题,“个性化推荐,到底是一项技术,一个功能,还是一个产品?” [2]。这绝对是一个难题,业界顶尖的公司都或多或少在摸索这个问题,Facebook 的 OpenGraph 模式是一个大胆地尝试,Twitter 也把相关性作为最大的挑战

之前有幸听业界一位前辈老师讲课,有一点深以为然。互联网产品的三大要素是:服务、信息、人。之前(包括 Google 在内)做互联网的模式是“服务为中心,串联起人和信息”,Facebook 不管是有心还是无意,逐渐在把模式变成“人为中心,串联起服务和信息”。一个看似简单的模式中心的调换,搞不好就能让 Google 交出互联网的权杖,改朝换代。


Posted in Uncategorized | Leave a comment

Idea Collection : Project Cards — a Agile Project Management Tool

Here is a sneek preview of ProjetCards intuitive user interface. Simple and easy to use, it allows you to get control of your Agile team’s succes FASTER !


ProjectCards Dashboard

Monitor the progress of the current iteration with real-time updates. Use drag and drop to change the status of the cards! Ensure that your team is constantly working on the customer’s most important needs.

ProjectCards burndown

Monitor the progress of the current iteration, your current release or your entire project with our burndown chart.

ProjectCards Taskboard

The Taskboard displays all the cards in the current iteration and lists the tasks which need to be accomplished. Use drag and drop to change the status of the tasks.

card editor

Edit multiple cards simultaneously. Save implementation notes, set a required date and assign the card to a member of the team. Updates are broadcast to all users in real-time!

ProjectCards drag and drop

Use drag and drop to classify your user stories by themes (features) and then plan your project. Share this information amongst all members of the team: project manager, customer team, development team, quality assurance team, even management (Guest user licenses are unlimited and FREE!)

ProjectCards velocity

ProjectCards enables you to indicate the capacity of the team for each iteration. ProjectCards lets you make future — or past — adjustments to the capacity (new team members, team reassignments, etc). Using the Automatic Load Balancing feature, watch how many iterations will be required to complete the required features. Use it for your What-if scenarios!

ProjectCards tasks

Never lose track of important tasks! Use the Tasks tab to create Engineering Tasks or use it as a simple to-do list.

ProjectCards acceptance tests

ProjectCards can also be used by the Customer and Quality Assurance teams! Document acceptance tests directly in the card. ProjectCards will automatically adjust the status of the card if a test has failed or if all tests have succeeded.

ProjectCards manage roles

Use ProjectCards’ project-by-project role-based user authorization schema to secure your precious data. Assign each user a built-in role or build your own custom roles, using the detailed function list.

ConfigureFields custom fields

You can extend the attributes of your cards with the Custom Fields feature. There is no limit on the number of fields you can add to your project, and there are many field types to choose from. For example, some teams that are developing a product for a number of customers will add a multi-select field listing all of their customers. They can then filter their cards by customer and generate reports for review.

ProjectCards filters

The powerful filter facility helps you navigate through large projects. There are a number of pre-defined filters as well as filters that are dynamically generated based on your project’s Custom Fields. Filters can be applied independently on the Themes view and the Planning view. The current filter is applied to reports that are generated.

ProjectCards Eclipse plug-in

Integrated Eclipse plug-in, you can run ProjectCards at every developer’s workstation, right in the IDE.


Posted in Uncategorized | Leave a comment

Tasktop Agile Planner


  • Agile is promising big returns, yet few have the ALM integration necessary to realize measurable productivity gains.
  • Due to a lack of integration with their work processes and tools, too many developers are resisting the move to Agile.
  • Managers continue to struggle with the lack of visibility between planning and production.

Agile Planner

The Tasktop Agile Planner leverages Mylyn connectors to address these pain points by giving Agile teams the ability to manage existing defect and project management systems directly from Eclipse, making it effortless to maintain project status awareness and keep plans up-to-date. Tasktop uniquely provides planning support that spans across multiple vendors’ solutions. For example, a story in Rally can be associated with defects in external systems such as JIRA and Bugzilla. The planner is available as both a rich desktop client and Eclipse plugin with support for Tasktop Certified Agile project management solutions including ThoughtWorks Studios’ Mingle, IBM Rational Team Concert, Rally, CollabNet’s ScrumWorks, Atlassian’s JIRA and VersionOne.


The Task Board view provides a visual representation of project status right in the IDE

Key Features

  • Task Planner. Create and update release and iteration plans directly from the IDE. Link stories and defects across external ALM solutions with a Tasktop Certified Connector.
  • Task Board. View a graphical presentation of backlog items and stories in “Defined”, “In Progress”, and “Completed” state. View progress for the entire team or highlight items assigned to one person.
  • Burn Down Charts. Maintain awareness of outstanding work over time with in-IDE burn down charts.
  • Time Tracking. Automates the tracking of time spent on stories view actual time tracking information recorded in the IDE on the plan.
  • Offline access. Access and update plans while offline. Synchronize changes with the server later when connected.
Rich editors embed web content from ALM solutions directly in the IDE


Posted in Uncategorized | Leave a comment

Tutorials of Opensocial

OpenSocial gives you several approaches for developing apps, depending on your project requirements. However, most social application designs have the same structure: application datasocial data, and a template are combined to provide a rendered view to the end user.

In the OpenSocial ecosystem, these components can come from several places. Client-Side apps can use JavaScript to render data into a template. Social Networks can store both social and application data, and Server-Side applications can take advantage of databases and server-side frameworks to produce rendered output.

Social Design Patterns

The documentation in this wiki has been arranged in a series of tracks, grouped by the style of development they describe. Depending on what type of application you want to write, one of the following patterns should fit your needs.

Social Mashup

A social mashup is a lightweight OpenSocial application which runs inside of a social network. Because such applications do not rely on a server, they typically scale extremely wellbut may be limited in terms of data storage and/or processing. A social mashup is typically created using HTMLJavaScriptCSSOpenSocial Templates, and/or Flash.

The Social Mashup Tutorial will walk you through creating a simple application from start to finish.

To write your own mashup from scratch:

Start by reading the Gadget Developer’s Guide to learn the basics about gadgets.
Define application views to render in profile or canvas pages.
Learn how to request social data from the site hosting your app.
Mash up other APIs in your gadget by requesting data from other sources on the web.
Reduce the amount of JavaScript you need to write by adding OpenSocial Tags and Templates.
Get global with Localization.

Social Application

A social application runs inside of a social network but relies on an external server for processing and rendering data. These applications can provide advanced functionality but may run into scaling problems when they become very popular. Social applications can be created using a variety of technologies, including HTMLJavaScriptCSSOpenSocial Templates,FlashPHPPythonJavaPerl.NET, or Ruby.

The Social Application Tutorial will walk you through creating a simple application from start to finish.

To write your own application from scratch:

Start by reading the Gadget Developer’s Guide to learn the basics about gadgets.
Define application views to render in profile or canvas pages.
Learn how to request social data from the site hosting your app.
Interact with your own server from the application.
Process data in the background by using an OpenSocial Client Library and 2-legged OAuth.
Optimize caching by using the Invalidation API.
Secure your application by using OAuth to validate requests from the social network.
Add OpenSocial Tags and Templates as shortcuts for rendering social data.

Social Website / Social Mobile Application

Social websites and social mobile applications run outside of social networks but consume social data through REST or RPC APIs. Users of these apps can grant access to their data using 3-legged OAuth without needing to add an application on a social network. This design pattern grants the most flexibility – almost all languages and platforms can take advantage of this data.

The Social Website Tutorial will walk you through creating a simple application from start to finish. custom writing service

To write your own website or mobile app from scratch:

Read the OpenSocial REST Developer’s Guide to learn how to access social features from your server.
Use an OpenSocial Client Library to speed up your development.
Understand the difference between 2 and 3-legged OAuth and when to use each one.

Articles List

Here is a list of the articles essay help available on this site, grouped by category. Professional Resume writing services



OpenSocial Tutorial Building a complete social gadget from start to finish.
Social Mashup Tutorial Write a simple gift giving app using OpenSocial templates.
Social Application Tutorial Write a gift giving app which relies on an external server.
Social Website Tutorial Write a gift giving website which allows users to log in with OpenSocial accounts.

JavaScript API

Developer’s Guide Learn the basics of writing OpenSocial-based gadgets.
Requesting Social Data Fetch social data from inside a gadget.
App Data Read and write persistent data without needing a database.


Gadgets API Developers Guide Learn the basics of writing non-social gadgets.
Gadgets XML Reference Reference for the gadget specification XML.
Localization Display locale-appropriate content based on the user’s country and language settings.
Views Render your gadget in different sections of the container.

Remote Content

Remote Data Requests Fetch remote content.
Introduction To Signed Requests Securely transmit OpenSocial IDs to a remote server.
Validating Signed Requests Validate that information from a container has not been modified.

Templates and OSML

OpenSocial Templates Simplify your display code by using templates.

Server-to-server Protocols

OpenSocial REST Developer’s Guide Access social data from your server.
Client Libraries Use PHP, Java, Ruby, Python, and ActionScript or other languages to access social data.

Best Practices

Social Design Best Practices Follow best practices for designing social applications.
Unobtrusive Alerts Avoid the use of the alert() function.
Latency Measurement Learn how to measure the latency and performance of your app.
Improving Latency Reduce the latency of your app.
OAuth Use Cases Learn how OpenSocial uses OAuth authorization.
Performance comparison on Programming Models Including the comparison on first-time gadget rendering performance, and the data requesting performance.

Tools and Utilities

OpenSocial Dev App Experiment with social JavaScript calls inside of a social network.
OSDE Tutorial Learn how to build social gadgets locally, using the OpenSocial Development Environment
Gadgets i18n Tool Automatically translate gadgets using this Windows tool.
Partuza An example social networking site based on PHP Shindig.
SocialSite An example social networking site based on Java Shindig.
Silverlight Kit for MySpace An Open Source Silverlight 2 Kit for the MySpace Developer Platform.

Integrating OpenSocial with other services

Google App Engine Build an OpenSocial application using Google App Engine.
Amazon S3 and App Engine Build a photo-sharing application on Amazon S3 and Google App Engine.
Google Data APIs Access the Google Data APIs from a gadget, using the Google Accounts APIs for authentication.
Google Friend Connect Integrate OpenSocial and Google Friend Connect on your PHP website.
Posted in Uncategorized | Leave a comment

(转贴)Common REST Mistakes

When designing your first REST system there are a variety of mistakes people often make. I want to summarize them so that you can avoid them. If any are unclear, ask for more information on rest-discuss.

  1. Using HTTP is not enough. You can use HTTP in a Web service without SOAP or XML-RPC and still do the logical equivalent of SOAP or XML-RPC. If you’re going to use HTTP wrong you would actually be better off doing it in a standard way! Most of these other points describe ways in which people abuse HTTP.
  2. Do not overuse POST. POST is in some senses the “most flexible” of HTTP’s methods. It has a slightly looser definition than the other methods and it supports sending information in and getting information out at the same time. Therefore there is a tendency to want to use POST for everything. In your first REST Web Service, I would say that you should only use POST when you are creating a new URI. Pretend POST means “create new URI as child of the current URI.” As you get more sophisticated, you may decide to use POST for other kinds of mutations on a resource. One rule of thumb is to ask yourself whether you are using POST to do something that is really a GET, DELETE or PUT, or could be decomposed into a combination of methods.
  3. Do not depend on URI’s internal structure. Some people think about REST design in terms of setting up a bunch of URIs. “I’ll put purchase orders in /purchases and I’ll give them all numbers like /purchases/12132 and customer records will be in /customers…” That can be a helpful way to think while you are whiteboarding and chatting, but should not be your final public interface to the service. According to Web Architectural principles, most URIs are opaque to client software most of the time. In other words, your public API should not depend on the structure of your URIs. Instead there would typically be a single XML file that points to the components of your service. Those components would have hyperlinks that point to other components and so forth. Then you can introduce people to your service with a single URI and you can distribute the actual components across computers and domains however you want.
    My rule of thumb is that clients only construct URIs when they are building queries (and thus using query strings). Those queries return references to objects with opaque URIs.
  4. Do not put actions in URIs. This follows naturally from the previous point. But a particularly pernicious abuse of URIs is to have query strings like “someuri?action=delete”. First, you are using GET to do something unsafe. Second, there is no formal relationship between this “action URI” and the “object” URI. After all your “action=” convention is something specific to your application. REST is about driving as many “application conventions” out of the protocol as possible.
  5. Services are seldom resources. In a REST design, a “stock quote service” is not very interesting. In a REST design you would instead have a “stock” resources and a service would just be an index of stock resources.
  6. Sessions are irrelevant. There should be no need for a client to “login” or “start a connection.” HTTP authentication is done automatically on every message. Client applications are consumers of resources, not services. Therefore there is nothing to log in to! Let’s say that you are booking a flight on a REST web service. You don’t create a new “session” connection to the service. Rather you ask the “itinerary creator object” to create you a new itinerary. You can start filling in the blanks but then get some totally different component elsewhere on the web to fill in some other blanks. There is no session so there is no problem of migrating session state between clients. There is also no issue of “session affinity” in the server (though there are still load balancing issues to continue).
  7. Do not invent proprietary object identifiers. Use URIs. URIs are important because you can always associate information with them in two ways. The simplest way is to put data on a web server so that the URI can be dereferenced in order to get the data. Note that this technique only works with URIs that can be dereferenced so these URIs (http URIs!) are strongly preferred to URN or UUID-based URIs. Another way is to use RDF and other techniques that allow you to project metadata onto a URI that may not be under your control.
    If you use URI syntax with UUIDs or something like that then you get half of the benefit of URIs. You get a standardized syntax but have no standardized dereferencing capability. If you use an HTTP URI then you get the other half of the benefit because you then also have a standardized derferencing mechanism.
  8. Do not worry about protocol independence. There exists only one protocol which supports the proper resource manipulation semantics. If another one arises in the future, it will be easy to keep your same design and merely support the alternate protocol’s interface. On the other hand, what people usually mean by “protocol independence” is to abandon resource modelling and therefore abandon both REST and the Web.

Overall, the thing to keep in mind is that REST is about exposing resources through URIs, not services through messaging interfaces.


Posted in Uncategorized | Leave a comment

First draft of new UI design for InsightG2

I upload my first draft of  new UI design for InsightG2.

Posted in Uncategorized | 1 Comment