New TED Book: A Haystack Full of Needles

Originally posted on TED Blog:

There are some questions an Internet search just isn’t so good at answering: What do I want for dinner tonight? How can I make a career change? Who is my ideal romantic partner? Asking a search engine any of these things will most likely result in a deluge of useless data rather than an excited “aha!” discovery. While we know that the “right” answer is out there, finding it can be like hunting for the proverbial needle in a haystack.

Author and venture capitalist Jim Hornthal believes that the Internet can be far more useful when it comes to big questions. In the new TED Book A Haystack Full of Needles: Cutting Through the Clutter of the Online World to Find a Place, Partner, or President, he flips our current thinking on the noisy datasphere and explores groundbreaking approaches that will help searchers find the useful insights buried deep…

View original 91 more words

GroupTogether — Exploring the Future of a Society of Devices

Originally posted on The Past and Present Future:

My latest paper discussing the GroupTogether system just appeared at the 2012 ACM Symposium on User Interface Software & Technology in Cambridge, MA.

GroupTogether video available on YouTube

I’m excited about this work — it really looks hard at what some of the next steps in sensing systems might be, particularly when one starts considering how users can most effectively interact with one another in the context of the rapidly proliferating Society of Devices we are currently witnessing.

I think our paper on the GroupTogether system, in particular, does a really nice job of exploring this with strong theoretical foundations drawn from the sociological literature.

F-formations are small groups of people engaged in a joint activity.

F-formations are the various type of small groups that people form when engaged in a joint activity.

GroupTogether starts by considering the natural small-group behaviors adopted by people who come together to accomplish some joint activity.  These small groups can take a variety of distinctive forms, and…

View original 336 more words

Clearing Facebook Share Cache

I just search for a way to clear facebook share cache and find this good article

http://fbmhell.com/2010/10/breaking-facebook-share-cache/

In case it got deleted/removed, I will quote it here.

If you’ve used Facebook’s share functionality on an external website, you have probably by now figured out that the first time Facebook accesses the shared link, it generates a cache of the preview image and the copy. Here are a few tips to break the cache.

First, I should mention that the Facebook cache is there for good reason, to better handle load from their over 500 million users. The challenge comes in when you forgot to implement the proper meta information to make your share preview look as nice as it could, and you try to add it in after it’s been cached. You’ll change or add meta information, but Facebook still shows the older, crummy version.

The easiest way to break the Facebook share cache is to use a slightly different url, such as http://www.example.com versus http://www.example.com/index.htm.

Alternately, you can tack a query string onto the end of the url to make it a slightly different url in Facebook’s eyes, such as http://www.example.com versushttp://www.example.com/?v1http://www.example.com/?v2, etc.

This is fine for most manual share buttons, since you’re able to specify the url, but the problem comes in when you’ve got a website that people have already been sharing, with or without a share button provided.

The first time any user shared that specific url on Facebook, even if you didn’t have a share button implemented yet, Facebook cached the data.Facebook cached the preview image(s), the title and the description copy.

This caching also means that the first time you test what your site looks like in a Facebook share, it gets cached – so if the result isn’t what you wanted, you’ve now been hoist by your own petard.

Maybe you were ready, maybe you weren’t. Maybe you updated some copy, or came up with a better preview image. Either way, it can be frustrating to know that you’ve added or updated meta information and it’s still showing the older version.

It’s also a problem when you’re using the share widget that tracks the number of likes and shares from Facebook users. Changing that url, even slightly, will wipe out those stats, since Facebook sees it as a brand new url, so those 91k shares your page received will be zeroed out if you start mucking with the share url.

I’ve heard unofficial reports that Facebook caches this information for anywhere from one day to a week. This can be inconvenient at best, and cataclysmic at worst (in the case where a typo or critical copy change came down from corporate.)

Fortunately, there is a well-hidden tool that can help speed that up.

Facebook provides a URL Linter that will let you preview what your page will look like in the share preview without condemning you to being stuck with it for a week.

As you can see, the URL linter offers a preview, and some helpful debugging information about your url.

One side-effect of the URL linter is that it clears the cached data for the url you’re previewing.

Oddly, it does seem to be case-sensitive, so if your share url is http://www.Example.Com, make sure you enter http://www.example.com and http://www.Example.Com into the linter.

Also be aware that, as we mentioned, http://www.example.com andhttp://www.example.com/index.htm are two different urls according to Facebook. And depending on your server configuration, http://www.example.com and example.com might also be different urls, so be sure to cover all your bases.

Because it’s Facebook, I would recommend not abusing this tool, and instead using it the way it was intended. Breaking the Facebook share cache should be a last resort, and you’ll be better served by using it to plan ahead instead of fixing things, since Facebook could remove or change this functionality at any time.

Instead, use the linter on a url before you launch to preview what the share will look like. Use it to perfect the preview image and copy, and then go live. (Note that it will not work if your website is password-protected via htaccess or IP restrictions, since the outside world can’t access it, which means Facebook can’t access it.)

Use the debugging beforehand to make sure your page is optimized for Facebook sharing, even if you don’t plan on implementing a share button on the page itself. Someone, somewhere is going to share that bad boy, so you may as well be ready.

To learn more about the meta tags to use to specify which images and copy you want Facebook to use in share dialog, check out the share docs. (Bear in mind that some reports state that Facebook stops crawling a page after a certain number of characters, so the higher up on the page this meta information appears, the better.)

Using Liferay Web Application Intigrator (WAI)

In case you already have web application (war), just put it in deployment folder ( “deploy” folder for tomcat and “deployment” folder for jboss )

After it is deployed, Liferay will see it as a portlet. To use portlet, go to your liferay homepage > add a page. Then select manage that page, your portlet will be located in “undefined” category. Add it to your page and you are ready to go.

Migrating EAR from JBOSS 5 to JBOSS 7

#1 your war in your ear has to has .war extension, even it is a folder.

#2 If you use JAX-RS for RESTful webservice, make sure you comment out 

<extension module=”org.jboss.as.jaxrs”/>

and

<subsystem xmlns=”urn:jboss:domain:jaxrs:1.0″/>  

in standalone.xml  (or domain)

 

Besides, for jersey, you have to deploy your webservice as an exploded folder in delpoyment folder ( and make sure it has .war extension )

using log4j with JBOSS AS 7.1.1

put this jboss-deployment-structure.xml to your ear’s META-INF

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
 <deployment>
 <exclusions>
 <module name="org.apache.log4j" />
 </exclusions>
 </deployment>
 <sub-deployment name="your_war_folder.war">
 <exclusions>
 <module name="org.apache.log4j" />
 </exclusions>
 </sub-deployment> 
</jboss-deployment-structure>

for war deployment, put it in your WEB-INF

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="org.apache.log4j" />
</exclusions>
</deployment> 
</jboss-deployment-structure>