jasha.eu

WidgetGap: a Wookie & Cordova (PhoneGap) mashup widget

Jasha Joachimsthal — Wed, 17 Oct 2012 06:30:03 +0000

I knew PhoneGap as a tool to make native mobile apps from HTML, CSS and JavaScript, but had never used it myself. When I had to debug a PhoneGap application I read that the project you’re uploading is basically a W3C widget. I should have known from Scott’s blogpost, but apparently I forgot. I did remember that Apache Wookie is responsible for rendering W3C widgets in Apache Rave.

I decided to make my own demo widget called WidgetGap, that can be used for making both a mobile app and a widget in Rave. Then I started a new iOS project for Apache Cordova (the open source project behind PhoneGap). If you don’t develop in OSX, pick a getting started guide that works on your machine.

I copied the result of a JSON call to the REST API of the Hippo Go Green demo in a Javascript variable to process that into the HTML. I chose this local variable because I didn’t want to call the REST interface over and over again just to get my markup right. After modifying the CSS it was time to replace the local resultset with a real AJAX call. The app and Wookie widget refuse to fetch the data because it’s a call to a different domain. Luckily there are solutions for this. For the mobile app you should add the following entry to the config.xml

For the iPhone simulator you also need to add this domain to the “External Hosts” entry in Resources/Cordova.plist file in the Xcode project.

For the Wookie widget I still didn’t get the data, but a few extra lines of Javascript made it work:

var loc = productLink;
if (window.widget && typeof window.widget.proxify == 'function') {
    loc = widget.proxify(loc);
}

Apart from issues with DOM manipulations in Javascript (not my expertise), I was able to create the widget that displayed a list of products from the Go Green REST interface with more detailed information when you click on the title.

Try it

The mobile app is available on PhoneGap (except for iOS because of Apple’s licensing policy).

To see the widget in Wookie, download and start the standalone version of Wookie.
In a different shell clone the WidgetGap repository from Github and go to the www folder. Package the contents and move this package to the deployment directory of the running Wookie instance:

git clone git://github.com/jashaj/WidgetGap.git
cd WidgetGap/www
zip -r widgetgap.wgt *
mv widgetgap.wgt ~/apache-wookie-0.11.0-incubating-standalone/build/webapp/wookie/deploy/

In the shell where you started Wookie you see the feedback about the deployment. If you see “‘WidgetGap’ – Widget was successfully imported into the system as WidgetGap” in the shell, you can view the widget it in your browser on http://localhost:8080/wookie/demo/.

The code is not optimised at all and maybe there is a better way to create this widget, but I wanted to show that you can write a single widget for the web and build a mobile app from it.

Fronteers 2012

Jasha Joachimsthal — Sun, 07 Oct 2012 10:25:36 +0000

Even though most of the web development I do now is in the backend, I started with HTML in 1995 before I learned programming Java. In 2010 I attended the Fronteers conference and came back excited about the new CSS and Javascript tricks. This is why I wanted to go to the Fronteers 2012 conference this year. Instead of giving a full coverage of the conference, I’ll give my tweets a little context where needed.

General

Saving a lot of interesting links from #fronteers12 presentations on delicious.com/jashaj

RT @sjoerdly: Still great work on the collaborative notes j.mp/RezoFp top initiative by @hayify #fronteers12 even with @alexgraul talking speed.

The beautiful venue of #fronteers12 Tuschinski twitpic.com/b16dgt

Thanks @FronteersConf for a great conference. @codepo8 you’re not only an inspiring speaker, but also a good MC.

A Pixel is not a Pixel by Peter-Paul Koch

Pixels and viewports explained by @ppk #fronteers12 Finally learning what the meta tag means I’ve been copy pasting the last 2 years.
PPK explained the difference between various widths you browser uses to calculate the size of boxed. You’ve probably used something like in your HTML to let your (mobile) device render the HTML nicely.

Interesting: (over-)usage of javascript libraries for just a few simple tasks eat up your mobile phone’s battery life. #fronteers12
The lazy way to handle simple tasks like selecting a specific DOM element or doing an Ajax call is to include a framework such as jQuery. This brings in a lot of code your site is not using. For a desktop device behind a broadband network this is not a real issue. For the mobile web it means not only a long loading time over a 2G network, but also a shorter battery life for your device because it has to process all that code.

Ten things I didn’t know about HTML by Mathias Bynens

<3 legacy in HTML5

Chuck Norris rules

#fronteers12

HTML5 specifies how browsers should behave in case of incorrect markup. In case of bgcolor=”chucknorris” it finds 2 valid hexadecimal characters and adds four 0′s to get a valid value. The result is the same as bgcolor=”#CC0000″> (red)

Browsers are just (too) kind for people creating webpages. Try omitting a ; in Java code and it won’t compile. #fronteers12
Mathias was talking about a discussion on github whether to add an optional ; at the end of a Javascript statement. Browsers have always accepted invalid HTML and this is IMO the main reason everyone was able to create their own webpage.

Accessibility panel with Bram Duvigneau, Antoine Hegeman and Bor Verkroost

Very useful to hear what issues people can have wrt accessibility of websites. #fronteers12
When the video of this discussion panel becomes available, I’d recommend you watching it. Not everyone can handle menus with a lot of items or a list of links too close to each other.

RT @rubenbos: Blind developer (!) demoing how he browses the web at #fronteers12. We can/should learn from this. #accessibility pic.twitter.com/n6ntQQTk

More CSS secrets: Another 10 things you may not know about CSS by Lea Verou

The result of the circling smiley is that I get hypnotised with a smile on my face . Very cool CSS tricks #fronteers12
We saw 10 (amazing) effects you can create with modern CSS3 without Javascript. One of them was a smiley circling on the page.

The biggest devils in the smallest details by Marcin Wichary

Apparently there is a team of designers and developers that work on the Google doodles for a living. As I write this, Google shows the doodle for Niels Bohr‘s 127th birthday.

my aunt called me when she saw the Pacman doodle. She thought her computer was infected by a virus. #fronteers12 and RT @flurin: Pacman doodle scared people because their computers suddenly started to make noise. They fixed it during the day. @mwichary #fronteers12
During the day that doodle was changed because my aunt wasn’t the only one.

Presenter’s MacBook drops and survives #fronteers12
550 hearts skipped a beat when the presenter’s MacBook fell off the lectern during the presentation. Surprisingly it wasn’t damaged.

Building the web platform by Anne van Kesteren

LOL: What the WTF: wtw.tf #fronteers12

I can smell your CMS by Phil Hawksworth

Next on #fronteers12: Phil Hawksworth, I can smell your CMS. Very interested if my former employer smells nice or not.
My former employer did very well actually. It lets you create your own URL scheme so you can migrate from/to an other platform without being forced to use other URLs. It doesn’t enforce HTML output. Its WYSIWYG editor is outdated but eat least it has a means to clean its output so you won’t leave empty paragraphs or font elements.

Hey, someone with a laptop that is not a MacBook #fronteers12
The vast majority was using devices that were designed in Cupertino. After 1,5 day I saw the first laptop from a different vendor. Later that day there turned out to be 5 of them in an audience of 550 people. Who thinks different?

OMG this really smells: instead of burton.com -> eur.burton.com/on/demandware.store/Sites-Burton_EU-Site/default #cmssmell #fronteers12
This site has a ridiculously long URL for this site’s homepage that also contains the name of the CMS vendor in it.

That view state is default behaviour of ASP.Net (still ugly) #fronteers12 #cmssmell
An enterprise CMS vendor has this very long hidden input field on its own site. My .NET knowledge is a bit outdated because someone says Microsoft changed this default behaviour years ago.

WYSIWYG is danger, but customers demand it #fronteers12 #smellcms

If people still think a post processor to clean WYSIWYG crapTML is not necessary, watch the video of this talk #smellcms #fronteers12
We saw traces of empty paragraphs with a non-breaking space wrapped in a font element to give it a smaller size.

Please speak up a bit during the #fqa #fronteers12
Instead of passing a microphone through the audience, the MC did the QA based on tweets in a 1-on-1 session. Because the MC and the speaker were close to each other, they forgot to speak up for the rest of the audience.

RT @philhawksworth: 149 stinking slides from my #smellCMS session at #fronteer12 are now available at speakerdeck.com/u/philhawkswor…

Shameless plug

Turn a banana into an input device for your computer makeymakey.com #fronteers12

What the legacy web is keeping from us by Alex Russell

Features IE7 users are missing. It has been 6 years since that browser has been released. #fronteers12 twitpic.com/b19nmg

Don’t blame the corporate users for their outdated browsers. Blame the IT department and CIO #fronteers12 #fqa
As web developers we’d like users to upgrade to the latest browser versions to use CSS instead of Javascript or images for cool effects. Employees of larger corporations are usually stuck with outdated Internet Explorer version and they cannot upgrade themselves. It’s the IT department that is afraid to roll out updates of software or they don’t get the time to work on it. There’s also Microsoft to blame to be so slow releasing new versions of IE. It’s easier to roll out small updates than the big-bang upgrades Microsoft comes with.

Apache Rave Hackathon

Jasha Joachimsthal — Mon, 18 Jun 2012 18:43:39 +0000

Last Wednesday was the first Apache Rave Hackathon in Utrecht, The Netherlands. We started with a little exercise because the fire alarm went off. There was a small accident in the railway station, so we had to leave the adjacent office building. Luckily we were allowed to enter it again.

After defining the schedule and introducing ourselves I gave a short presentation and demo of Apache Rave. One of the new features is sharing a page with other users. In the demo I showed the chat widget in a shared page. Both users had the same set of widgets now, but they used them under their own name.

This was a nice bridge to the next presentation by Dominik Renzel and Sten Govaerts of the ROLE project. We were happy to hear that the ROLE project members are going to contribute to Apache Rave. They showed widgets that were able to communicate with each other using XMPP. This made it possible to play a (Youtube) movie at the same time in different browsers (or on different computers) or cooperate on documents. They also showed their meta-data of the events in the portal by which we could trace who was making fun of the Netherlands – Germany football game in the drawing gadget.

Niels van Dijk (SURFnet) presented a comparison of several portals and web applications that are using OpenSocial gadgets like Liferay, Atlassian Jira and Sakai. Although Apache Rave is a relatively young project, it supported most of the features the Dutch universities and research institutions want.

Matt Franklin, PMC chair of Apache Rave, is also heavily involved with the OpenSocial specification. OpenSocial was initially driven by social networks like MySpace and Orkut, which left its trails in the specification. Now the enterprise is using OpenSocial to exchange data about persons and groups it’s time to clean up and simplify the specification.
A new addition will be the so called “embedded experiences”. As an example your activity stream can contain gadgets which can be rendered aside from the activity stream. Sometimes a video can say more than a thousand words.
Matt finished his talk with examples how The MITRE corporation will use Apache Rave as their intranet solution. It was a mix of data displayed directly on the page and gadgets. Some of the gadgets were seamlessly integrated into the page design.

Ard Schrijvers showed how Hippo solves the issue of page management. In many MVC frameworks like Spring MVC a controller has to collect all the data and then calls the view. A lot of elements are shared among different pages, while only a few “blocks” on a page change per page template. The Hippo Site Toolkit breaks up the configuration of a page into a hierarchy of components which can be reused in different page templates. In the future Apache Rave can profit from this model.

After the lunch my colleague Alle Veenstra showed the extensions on top of Apache Rave to run it on the SURFconext platform. He has built an OpenSAML module for Spring Security which makes Apache Rave a SAML service provider. If the visitor isn’t authenticated yet, he is redirected to the SURFconext Where Are You From (WAYF) page from which he can choose his own IdentityProvider to log in into the portal. New users are automatically provisioned. He has also made a well documented example project that uses this module.

Scott Wilson showed the edukapp white label widget store. It is using Apache Solr to index and query the available widgets and suggest other widgets that are similar to the chosen widget. It uses JSON to expose widget meta-data which makes it possible to exchange widgets between organisations. This can be a very valuable addition to the existing widget store in Apache Rave.

After all these talks about projects that are related to Apache Rave it was time for a talk about the Apache Software Foundation. Matt held an enthusiastic talk about the Apache Way. A project cannot exist without a community and contributions from the community. Questions (and answers) from users can also be valuable contributions. It’s important to see those questions and answers on the public mailing-list, so others can profit from them as well.

After Matt’s talk it was time for discussion in smaller groups, helping others set up their development environment and even applying patches. It was a great day and a pleasure to see the faces behind the email addresses on the Apache Rave users and dev lists.

Automated testing with JBehave

Jasha Joachimsthal — Fri, 13 Apr 2012 13:15:09 +0000

What do developers like most? Build new software! What do developers hate most? Testing and writing documentation! Why would you write tests? It slows down your process of making new software. If you can write that new feature in an hour, why spend another hour on writing unit tests and integration tests for them. You don’t make mistakes and if some user does something you didn’t expect he would, blame him first, then think of fixing it. If you had written tests before then they suddenly break because of your new feature and you need to modify those tests again because you now need to add another condition or the webpage has changed intentionally. Doesn’t that slow you down?

Okay maybe you did actually break functionality because of your new feature. You had not written tests before and the broken functionality is in a different part of the application so you didn’t see it when clicking through your website. Now your customer discovers the bug and thinks you’ve done bad job (which you did). So you start adding unit tests and for new features you switch to Test-driven development.

You develop new features, let all the tests pass and ship the new version. Will it be perfect? Unfortunately not. Your unit tests may cover isolated functionality. One tests checks if you can retrieve all countries your webshop ships to. The other test checks what happens after submitting a registration form. But there is no test that goes to the actual registration form and selects a country to find out that the list of countries is empty because it had not been uploaded to the server.

Recently my team wrote tests that go through the front end of the platform to check if it still works as expected. We chose JBehave to write stories that are human readable, map them in Java code and execute them in a real browser as if a real user is performing the tests. For Apache Rave we also needed to write integration tests because our list of features is growing and unfortunately we ran into a blocking issue despite a high unit test coverage.

As an experiment I started a test project on GitHub. I started with the JBehave Spring archetype, deleted the sample test and added my own test case:

Scenario: User creates a new account and logs in into the portal
When I go to "http://localhost:8080/portal"
Then I see the login page
When I follow the new account link
Then I get the new account form
When I fill in the form with username "newuser" password "password" confirmpassword "password" email "newuser@example.com"
And I submit the new account form
Then I see the login page
And A message appears "Account successfully created"
When I fill in the login form with username "newuser" password "password"
Then I see my portal page with the add new widgets box

With annotations in Java classes you cover these steps like

public class NewUserSteps {

    @Autowired
    Portal portal;

    @When("I go to "$url"")
    public void goTo(String url) {
        portal.go(url);
    }

    @Then("I see the login page")
    public void isLoginPage() {
        final WebElement title = portal.findElement(By.tagName("title"));
        assertThat(title.getText().trim(), equalTo("Login - Rave"));
    }

    /* Other methods that cover steps */
}

As you can see, the annotations can handle parameters from the story. For readability of the story I wrapped the parameters in quotes, but that is not necessary. From the step a “Portal” class is called. This class extends WebDriverPage which triggers actions in the browser like going to a url, clicking links or filling in form fields:

@Component
public class Portal extends WebDriverPage {

    @Autowired
    public Portal(WebDriverProvider driverProvider) {
        super(driverProvider);
    }

    public void go(String url) {
        get(url);
    }

    public void pressNewAccountButton() {
        final WebElement newAccountButton = findElement(By.id("createNewAccountButton"));
        newAccountButton.click();
    }
    /* Other methods */
}

Within an hour I had written the first automated test which can be run over and over again. Really? Not yet; you need to manually delete the user before running the test a second time. This can also be automated in an @AfterScenario or @AfterStory annotation to revert the state of the application.

After running the test, JBehave generates a report of how many stories, scenarios and steps it has run and how many were successful. I have recorded the run of this scenario in this video:

Does it mean I suddenly like writing integration tests? No, but I hate doing all these tests manually even more.

What is bundled with Apache Rave?

Jasha Joachimsthal — Tue, 13 Mar 2012 17:27:50 +0000

When you download and run the demo binaries of Apache Rave you see the demo portal in your browser on http://localhost:8080. The demo portal is built using Spring MVC for the request handling, Spring Security to manage access to the portal and OpenJPA for persistence. There are also other services running in the demo binary. In this blogpost I’ll give you a short overview of the bundled services.

OpenSocial container

Most of the demo widgets you see in the portal are OpenSocial gadgets. In order to render these we bundle Apache Shindig with Apache Rave. The Apache Shindig server runs on the root context. We’re working hard to implement all necessary OpenSocial calls. As an example you can retrieve all people connected to “canonical” user: http://localhost:8080/social/rest/people/canonical/@all

Wookie Widget Server

One of the goals was to render any kind of widget and not just OpenSocial. Since version 0.9-incubating we also bundle Apache Wookie to render W3C widgets. You can access the Wookie Widget Server on http://localhost:8080/wookie/. You can log in into its adminstration menu using “java” as username and password.

When you want to deploy the portal on your server, you can configure the host name for both the Shindig server and Wookie server.

Database

The demo setup uses an H2 database that is configured to store its database in /tmp (Windows users will find it in c:tmp). You can look inside the database on http://localhost:11111 to see which tables were created by OpenJPA or modify the database contents. The web console locks the file that contains the database, so log out when you want to use the portal. For deployment on a server we have documented how to configure the database with MySQL, PostgreSQL or Oracle.

LDAP

Apache Rave supports multiple authentication sources to access the portal. In the demo portal we start up an embedded Apache Directory Studio (ApacheDS) to demonstrate LDAP authentication with Spring Security. When you log in with “johnldap” as username and password, the portal looks up the credentials in the embedded ApacheDS and uses the LDAP response to create a user profile in the portal. The embedded ApacheDS is meant for the demo, but you can configure Apache Rave to use the existing LDAP server within your own network.

Apache Rave (Incubating) demo: add user and widget

Jasha Joachimsthal — Mon, 23 Jan 2012 08:00:00 +0000

Apache Rave (Incubating) is rapidly evolving to a production ready web and social mashup engine. This demo video shows you how a user can sign up, add existing widgets to his pages and add a completely new widget. reCAPTCHA and fetching the widget metadata were added recently.

Apache Rave presentation at the ROLE developer camp

Jasha Joachimsthal — Wed, 30 Nov 2011 17:30:41 +0000

This is the presentation I gave about Apache Rave during the ROLE project developer camp in Leuven, Belgium:

Can’t see the presentation? You can download the PDF (1.1 MB).

Apache Rave on your iPhone

Jasha Joachimsthal — Mon, 14 Nov 2011 18:21:08 +0000

One of the newest features in Apache Rave (Incubating) is a mobile view for the portal. Using Spring Mobile, the portal detects that the visitor uses a mobile device and renders a more lightweight view. The title bar is bigger to make it easier to expand or collapse a Widget on a touch screen. Drag and drop is disabled in the mobile view.

Preview of Apache Rave on an iPhone:

Apache Rave demo video

Jasha Joachimsthal — Sun, 06 Nov 2011 13:12:47 +0000

I’ve been working a lot on Apache Rave lately. Apache Rave is a new light-weight, open source portal that uses OpenSocial gadgets and W3C widgets to render content. You may have already used OpenSocial gadgets in iGoogle or Atlassian Jira without being aware of it. I can write a blogpost about Apache Rave, but a video can say more than words:

Direct link to the video

Google+ minus 1

Jasha Joachimsthal — Wed, 02 Nov 2011 20:21:59 +0000

A social network is like the new hip club in town. The innovators start a place that is hip, maybe a bit underground. They invite their friends who are not mainstream but know how to create a good atmosphere. Those early adopters invite their friends who are a bit more mainstream. Then the club becomes popular for the mainstream audience. The first innovators may leave the club but a large crowd has fun. This is how social networks like Facebook or Hyves started and became popular.

Imagine there’s an investor who is very jealous. He opens a new club, very large and hands out invites to make the entrance exclusive. He makes the big mistake to advertise with those invites on a campus of a large IT company. The geeks all want to go into the club on the night it opens. Once the club opens they discover nothing is happening there. Some try to hang around the bar, order a few drinks, start to dance, discover the dance floor is empty and then leave home disappointed. The innovators avoid the new club because they didn’t “discover” it themselves and they can’t create their own setting there.

The investor also owns some successful small but specialist shops in town. Suddenly the customers of the shop can only check out through the new club nobody wants to hang out, just because the investor wants to attract more visitors to his new club. Do the customers accept that or will they also ignore the shops they used to go?

Yes Google, this investor I’m talking about is you. You tried to hype Wave and later Google+ but don’t know how to build up an active community. You are closing down some very valuable niche services like sharing blog posts in Reader or the social features in iGoogle just because you want to force your users into Google+.

You’ve just lost a Google+ user: me.