Hot off the press, Play 2.0 has arrived, and has been welcomed into the arms of a fast paced community that loves new things.  The day it was released, we started a new project here, and on that particular day and on this particular project we felt particularly daring.  So we decided to use Play 2.0 for our project.  New is an understatement for Play 2.0, it’s not just an incremental improvement on Play 1.x, many parts of it have been completely rewritten.  There is still much work to do, and one of the blaring gaps that has yet to be filled is modules.  At the time of writing, there is no official listing or repository of modules for Play 2.0, in stark contrast to the rich ecosystem of modules for Play 1.x.  Furthermore, there is no documentation on how to write a module.  So, given that modules tend to be very useful, and we were starting a new project, we very quickly ran into the need to write our own module, which we did, the MongoDB Jackson Mapper Play 2.0 Module.  To help the rest of the community of early Play 2.0 adopters, I’ve decided to write a (very) short guide on writing Play 2.0 modules.

The disclaimer

So did I mention that there was no documentation on writing modules, and very little in the way of example code to copy from?  What I’ve written may well be not the right way to do things.  But with no documentation, how am I to know?  All I know is that it’s working for us, and that’s good enough for me.  So if you happen to know what the right way to write Play 2.0 modules is, don’t bother commenting on this telling me that I’m wrong.  Just write the damn documentation!

The setup

In play 1.x, writing a module usually starts with running play new-module. Slight problem here:

$ play new-module
       _            _
 _ __ | | __ _ _  _| |
| '_ \| |/ _' | || |_|
|  __/|_|\____|\__ (_)
|_|            |__/ 

play! 2.0, http://www.playframework.org

This is not a play application!

Use `play new` to create a new Play application in the current directory,
or go to an existing application and launch the development console using `play`.

You can also browse the complete documentation at http://www.playframework.org.

Ok, so that doesn’t work.  Looks like there’s no way to create a new play module.  So, I decided to simply write a vanilla SBT project.  I won’t go into the details of how to set a new SBT project up, but here’s the play specific bits that you’ll need:

resolvers ++= Seq(
    DefaultMavenRepository,
    Resolver.url("Play", url("http://download.playframework.org/ivy-releases/"))(Resolver.ivyStylePatterns),
    "Typesafe Repository" at "http://repo.typesafe.com/typesafe/releases/",
    "Typesafe Other Repository" at "http://repo.typesafe.com/typesafe/repo/"
)

libraryDependencies += "play" %% "play" % "2.0"

libraryDependencies += "play" %% "play-test" % "2.0" % "test"

Now do whatever you need to do to open it up in your favourite IDE/editor (I personally use IntelliJ IDEA, so I use the sbt-idea plugin).

The code

It’s worth first noting that the module that I wanted to write only had to load a MongoDB connection pool, according to configuration supplied in application.conf, and manage the lifecycle of that pool.  The trait that needed to be implemented to do this is play.api.Plugin.  It has three methods, onStart(), onStop() and enabled().  If you’re looking for information on how to do things like intercept HTTP calls and define custom routes, then I suspect it’s easy to do (probably by just defining a routes file in your plugin), but I didn’t need to do that so I’m not going to pretend that I know how.

There’s not really much to say now, my plugin looks something like this:

class MongoDBPlugin(val app: Application) extends Plugin {
  private lazy val (mongo, db, mapper) = {
    // insert code here to initialise from application config
  }

  override def onStart() {
    // trigger lazy loading of the mongo field
    mongo
  }

  override def onStop() {
    mongo.close()
  }

  override def enabled() = !app.configuration.getString("mongodb.jackson.mapper")
      .filter(_ == "disabled").isDefined
}

The actual code does a fair bit more than this, but none of that is specific to how to write a plugin.

The finishing touch

So I’ve written my plugin, there’s now one thing left to do… tell play framework about it!  This is done by defining a play.plugins file in the the root of the classpath (in the resources folder):

1000:play.modules.mongodb.jackson.MongoDBPlugin

The leading integer defines the priority of the plugin to be loaded.  The example I saw used 1000, so I decided to use that too.

The resolution

Now all I have to do to use this module is add it as a dependency.  Play will automatically pick it up, and it will be automatically started and stopped as necessary.  Happy hacking, and if you’re starting a Play 2.0 project, and want to use MongoDB, why not try the MongoDB Jackson Mapper Module!

Die Front-Trends Conference findet vom 26.-27. April 2012 in Warschau statt und versammelt erneut das Who-is-who der Front-Trend-Developer.

 ”THIS IS A GATHERING FOR FRONT-END LOVERS TO DISCOVER THE CURRENT TRENDS TO BUILD A PROFESSIONAL CAREER OUT OF INNOVATIVE
CONFERENCE TOPICS: HTML5 UX JAVASCRIPT WEB DESIGN CSS3 MOBILE AND MORE”

Ein Blick in die Liste der Speaker sollte jedem Frontend Enthusiasten verdeutlichen, dass es sich um ein absolutes Top Event handelt und so schicken wir von den VZ Netzwerken in diesem Jahr nicht nur Entwickler, sondern auch gleich noch ein “Sponsorship” nach Warschau. Yeah.

Let’s have a beer (or two).
Fahrt ihr auch nach Warschau? Wen treffen wir?

Though, to be honest, while the extensions themselves are simple, it wasn’t that simple to work out how to write them.  On my first attempt, I gave up after Googling and trying things out myself for an hour.  On my second attempt, I almost gave up with this tweet.  But, I stuck with it, and eventually made my breakthrough. The answer was in InjectionListener. This listener is called on every component that Guice manages, including both components that Guice instantiates itself, and components that are provided as instances to Guice.

Supporting Disposables

So, I had my disposable interface:

public interface Disposable {
  void dispose();
}

and I wanted any component that implemented this interface to have their dispose() method called when my application shut down.  Naturally I had to maintain a list of components to dispose of:

final List<Disposable> disposables = Collections.synchronizedList(new ArrayList());

Thread safety must be taken into consideration, but since I only expected this list to be accessed when my application was starting up and shutting down, a simple synchronized list was suffcient, no need to worry about performant concurrent access.

My InjectionListener is very simple, it just adds disposables to this list after they’ve been injected:

final InjectionListener injectionListener = new InjectionListener<Disposable>() {
  public void afterInjection(Disposable injectee) {
    disposables.add(injectee);
  }
};

InjectionListener‘s are registered by registering a TypeListener that listens for events on types that Guice encounters.  My type listener checks if the type is Disposable (this actually isn’t necessary because we will register it using a matcher that matches only Disposable types, but it is defensive to do the check), and if so registers the InjectionListener:

TypeListener disposableListener = new TypeListener {
  public <I> void hear(TypeLiteral<I> type, TypeEncounter<I> encounter) {
    if (Disposable.class.isAssignableFrom(type.getRawType())) {
      TypeEncounter<Disposable> disposableEncounter = (TypeEncounter<Disposable>) encounter;
      disposableEncounter.register(injectionListener);
    }
  }
}

Now I can register my TypeListener.  This is done from a module:

bindListener(new AbstractMatcher<TypeLiteral<?>>() {
      public boolean matches(TypeLiteral<?> typeLiteral) {
        return Disposable.class.isAssignableFrom(typeLiteral.getRawType());
      }
    }, disposableListener);

The last thing I need to do is bind my collection of disposables, so that when my app shuts down, I can dispose of them:

bind((TypeLiteral) TypeLiteral.get(Types.listOf(Disposable.class)))
                .toInstance(disposables);

So now when my app shuts down, I can look up the list of disposables and dispose of them:

for (Disposable disposable : ((List<Disposable>) injector.getInstance(
    Key.get(Types.listOf(Disposable.class)))) {
  disposable.dispose();
}

If you decide to use this code in your own app, please be very wary of a potential memory leak. Any beans that are not singleton scoped will be added to the disposable list each time they are requested (per scope).  For my purposes, all my beans that required being disposed of were singleton scoped, so I didn’t have to worry about this.

Supporting annotation based method invocation scheduling

Happy that I now had a very simple extension with very little code for supporting automatic disposing of beans, I decided to try something a little more complex… scheduling. My app contains a number of simple scheduled tasks, and the amount of boilerplate for scheduling each of these was too much for my liking. My aim was to able to do something like this:

@Schedule(delay = 5L, timeUnit = TimeUnit.MINUTES, initialDelay = 1L)
def cleanUpExpiredData() {
  ...
}

(Yep, this app has a mixture of Scala and Java.) So, I started with my annotation:

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Schedule {
    long delay();
    TimeUnit timeUnit() default TimeUnit.MILLISECONDS;
    long initialDelay() default 0;
}

The main difference this time is that I’m not listening for events on a particular type, but rather I want to check all types to see if they have a @Schedule annotated method. This is a little more involved, so I’m going to have a scheduler service that does this checking and the scheduling. Additionally it will make use of the disposable support that I just implemented:

public class SchedulerService implements Disposable {
  private final ScheduledExcecutorService executor = Executors.newSingleThreadScheduledExecutor();

  public boolean hasScheduledMethod(Class clazz) {
    for (Method method : clazz.getMethods()) {
      Schedule schedule = method.getAnnotation(Schedule.class);
      if (schedule != null) {
        return true;
      }
    }
    return false;
  }

  public void schedule(Object target) {
    for (final Method method : target.getClass().getMethods()) {
      Schedule schedule = method.getAnnotation(Schedule.class);
      if (schedule != null) {
        schedule(target, method, schedule);
      }
    }
  }

  private void schedule(final Object target, final Method method, Schedule schedule) {
    executor.scheduleWithFixedDelay(new Runnable() {
      public void run() {
        method.invoke(target);
      }, schedule.initialDelay(), schedule.delay(), schedule.timeUnit());
  }

  public void dispose() {
    executor.shutdown();
  }
}

Now in my module I instantiate one of these services:

final SchedulerService schedulerService = new SchedulerService();

I then implement my InjectionListener:

final InjectionListener injectionListener = new InjectionListener() {
  public void afterInjection(Object injectee) {
    schedulerService.schedule(injectee);
  }
}

and my TypeListener:

TypeListener typeListener = new TypeListener() {
  public <I> void hear(TypeLiteral<I> type, TypeEncounter<I> encounter) {
    if (schedulerService.hasScheduledMethod(type.getRawType()))  {
      encounter.register(injectionListener);
    }
  }
}

And then all I have to do is register my type listener, and also my scheduler service (so that it gets disposed properly):

  bindListener(Matchers.any(), typeListener);
  bind(SchedulerService.class).toInstance(schedulerService);

Conclusion

Although Guice doesn’t come with as much as Spring does out of the box, it is very simple to extend to meet your own requirements. If I were needing many more container like features, then maybe Spring would be a better tool for the job, but when I’m just after a dependency injection framework with a little sugar on top, Guice is a very nice and much lighter weight solution.

	Eclipse I don’t think we need a description here ;-) http://www.eclipse.org/	500€
	CumulusServer “CumulusServer is a complete open source and cross-platform RTMFP server extensible by way of scripting.” https://github.com/OpenRTMFP/Cumulus	500€

Thanks to the developers and keep up the good work.

The backend of our feed service is implemented in Java, and talks JSON back to clients.  If you log in to VZ and use your favourite browsers developer console to see XHR traffic, you can see the JSON that the feed service returns.  This JSON is generated from POJOs using Jackson, a very simple yet powerful, performant and flexible framework for serialising POJOs to JSON.

Looking carefully at the JSON, you’ll notice that the feed data contains more than just a list of messages, there is a mixture of objects whose data is clearly generated on the fly by the feed service, and other objects that the feed service doesn’t really care about, it just receives them from the services that generate them, and passes them to the client as is.  For example, information about a particular photo, or a gadget, or a status update, or a new friend.  This data is represented by many different POJOs in the feed, and in some cases specific processing is done on them, but mostly the feed receives them from the various services that generates them, and passes them back to the client untouched.

All these POJOs have Jackson annotations on them, and we know that they work well with Jackson.  With our old storage backend, we simply serialised them to JSON to store them.  One of the reasons for going with MongoDB is that we wanted to be able to easily query our data, to get statistics and a better understanding of how the service was being used.  What we wanted to avoid though was having to either rewrite the POJOs, or make MongoDB equivalent copies of them, in order to store them in MongoDB.  What we really wanted to do is reuse the Jackson annotations on them so that we could store them as is in MongoDB.

A google search revealed that there already was a mapper out there by Grzegorz Godlewski that did this, however this mapper had a few problems in our eyes.  For one, it required a fork of the Mongo Java Driver, and there was no indication that this fork would ever be pulled back into the stable driver.  It also said that it was experimental and not production ready, and we weren’t about to trust our feed with an experimental technology that didn’t have a clear future.  It is worth saying though that Grzegorz’s mapper is quite innovative, it serialises/deserialises objects directly to/from the BSON that MongoDB speaks with the client.  This would make it the most performant mapper out there.  But we didn’t feel that the technology was mature enough for our use case.

However, as Grzegorz pointed out, plugging in a custom parser/generator to Jackson is a simple thing to do, so we decided to implement our own mapper that parsed/generated the MongoDB map like DBObject‘s.  In addition to this, we implemented a very lightweight interface that wraps the MongoDB DBCollection, called JacksonDBCollection.  This provides all the same methods that DBCollection provides, except that where appropriate, it replaces DBObject method parameters and return types with strongly typed POJO versions.  DBObject‘s still get used for querying, because you can’t express all queries using POJOs, however when you just want to use equality in your queries, you can use your POJO as the query.

It’s open source!

We’re pleased to announce that we’ve made this library available as an open source library. You can download the source code, and contribute to it yourself, at GitHub.  If you don’t want the source code, but just want to start using it in your project now, you can get it from the central maven repository:

<dependency>
    <groupId>net.vz.mongodb.jackson</groupId>
    <artifactId>mongo-jackson-mapper</artifactId>
    <version>1.0</version>
</dependency>

The details

To give you a taste of what this framework looks like, I’ll show some coding examples.  Here is how to create a JacksonDBCollection:

JacksonDBCollection<MyPojo, String> coll = JacksonDBCollection.wrap(
    dbCollection, MyPojo.class, String.class);

The two type parameters are the type of the POJO that is being mapped, and the type of the ID of the POJO.  The reason we require the type of the ID of the POJO is for strongly typed querying by ID, and strongly typed retrieval of generated IDs.  Here is what my POJO looks like:

public class MyPojo {
  @ObjectId @Id public String id;
  public Integer someNumber;
  public List<String> someList;
}

Maybe not the best Java coding style with public mutable fields, Jackson is flexible enough to support almost anything, this keeps it simple for this blog post.  In the feed, we’re using immutable objects with private final fields, and @JsonCreator annotated constructors.

One issue that we encountered while implementing this is how to handle ObjectId‘s.  If you declare an object to have a type of ObjectId, it works without a problem.  But this is a POJO mapper, and some people may not want to have an ObjectId type in their POJO, particularly if they are reusing the POJO for the web.  So we added an annotation, @ObjectId, that can be put on any String or byte[] property, that tells the mapper to serialise/deserialise this property to/from ObjectId.

You’ll also see the use of the @javax.persistence.Id annotation.  This is really just a short hand that we implemented for @JsonProperty("_id"), which has the added advantage of not having to use the Jackson views feature if you want to use the same POJO for the web and don’t want the name of the property to be _id. You could just as easily make the field name _id with no extra annotations.

Inserting an object is simple:

MyPojo pojo = new MyPojo();
pojo.someNumber = 10;
pojo.someList = Arrays.asList("foo", "bar");
WriteResult<MyPojo, String> result = coll.insert(pojo);

or with write concerns:

WriteResult<MyPojo, String> result = coll.insert(pojo, WriteConcern.MAJORITY);

We are letting MongoDB generate the ID for us here, which begs an important question, how do we find out what the ID it generated was? With the MongoDB Java Mapper, it sets the ID on the object you passed in. This is not practical with Jackson, because you may be using a custom serialiser, or @Creator annotated factory method/constructor, in the case of the VZ feed our objects were immutable, making it impossible to do that. We supported this by implementing our own WriteResult class, which aside from wrapping all the methods from the MongoDB Java Driver WriteResult, provides a few methods such as getSavedId() and getSavedObject(), which deserialises the id/object so you may obtain the ID:

String id = result.getSavedId();

Now using that ID we can load the object again:

MyPojo saved = coll.findOneById(id);

Equality based querying can be done using the POJO as a template:

MyPojo query = new MyPojo();
query.someNumber = 10;
for (MyPojo item: coll.find(query)) {
    System.out.println(item.id);
}

And loading partial objects can also be done using the POJO as a template, by setting any fields you want loaded to be something that isn’t null:

MyPojo query = new MyPojo();
query.someNumber = 10;
MyPojo template = new MyPojo();
template.someNumber = 1;
template.id = "not null"
for (MyPojo item: coll.find(query, template)) {
    System.out.println(item.id);
    assert(item.someList == null);
}

And when this isn’t enough, you can fall back to normal DBObject‘s for both the query and the template:

for (MyPop item: coll.find(new DBObject().add("someNumber", new DBObject().add("$gt", 5))) {
    System.out.println(item.id);
}

There are more examples for some more advanced use cases, for example using custom views, on the GitHub project page.

Summary

So here we have a new POJO mapper for MongoDB that you can use, and due to the fact that it uses Jackson, it has a head start in being very powerful, flexible and performant. Some of our plans for future features include:

• @Reference annotation support, loading dehydrated referenced objects containing just the ID, with convenience methods for hydrating these objects
• Schema migration features, where the JacksonDBCollection can return option tuples containing either the old or the new object type based on what was detected

If you have any other features you’d like to see, please raise an issue in the GitHub project!

Just added scala for the first time to an existing Java project. Not too shaby.

As soon as I saw the build passed on our CI server, I went home, but it caught the attention of my product manager, and he was very intrigued.  What I had in fact done was started writing unit tests for an existing Java service that I was working on in Scala.  Why did I do this?  A number of reasons:

1. I’ve been meaning to learn Scala for at least a year.
2. I’ve seen Scala unit tests before, and they look very cool, they’re very good at minimising boilerplate, and very easy to read and understand.
3. At VZ, we are free to make sensible technology choices.  This ranges from what libraries we use, to what databases we use, to what languages we use.  Nothing is off limits, as long as we can provide a good argument as to why it’s better than the alternatives.  And when we do that, our managers trust us.

My product manager of course had no problems with me using Scala, we have another project here that uses Scala and he thought I meant I had done some work on that, and was interested in knowing why.  After explaining that I had actually added Scala to the project I was supposed to be working on, he was completely fine, and that’s one of the things I love about working for VZ, we have the freedom to make our own decisions.

For those that are not familiar with Scala, here is a quick overview of how I introduced Scala into my existing Java project.

First, I did my research.  What unit testing frameworks are there in Scala?  You’ll quickly find that there are two popular frameworks, one called specs, and another called ScalaTest.  ScalaTest supports a number of different testing styles, including TDD and BDD, while specs only supports BDD.  I only wanted BDD, so both were equal to me at this point.  Further research showed that specs has good integration with my favourite mocking framework, Mockito, so I went with specs.  I suggest you do your own research for your own purposes, my comparison here is far from complete.

Next, since I’m using Maven, I needed to add Scala to my maven project.  I found a blog post that explained how to add Scala to a maven project in 4 steps, and I was able to build my project in no time.  I also added a dependency on the specs library, and configured the Maven surefire plugin to run any classes ending in Test or Spec, as per the instructions for integrating with Maven and JUnit in the specs documentation.  I use IntelliJ IDEA as my IDE, so I searched for a Scala plugin in my preferences, found one, installed it, and after a restart IDEA had Scala support.  The IDEA instructions say that you need to install the Scala SDK, but since I was using Maven, I could just add the scala compiler as a provided maven dependency, then go to the Scala compiler preferences and point IDEA at that dependency.

Finally I had to write my tests.  Below is the first test that I wrote.  If you’re a Scala guru, I’m sure you’ll see things that I could have done simpler or that I haven’t followed conventions for, so I’m happy for you point them out to me, I’m still learning.

class WorkResultHandlerSpec extends SpecificationWithJUnit with Mockito {
  "Work result handler" should {
    val tracker = mock[WorkResultTracker]
    val handlerChain = mock[HandlerChain]
    val workUnit = WorkUnit.builder(JobType.TEST_MESSAGE, null).build
    val job = Job.builder(JobType.TEST_MESSAGE).build
    var handler = new WorkResultHandler(tracker)

    "call handler chain only once" in {
      handler.handle(job, workUnit, handlerChain)
      there was one(handlerChain).passToNextHandler(job, workUnit)
    }

    "pass the result to the tracker" in {
      val workResult = WorkResult.success
      handlerChain.passToNextHandler(job, workUnit) returns workResult
      handler.handle(job, workUnit, handlerChain)
      there was one(tracker).trackWorkResult(JobType.TEST_MESSAGE, workResult)
    }

    "return the result" in {
      val workResult = WorkResult.success
      handlerChain.passToNextHandler(job, workUnit) returns workResult
      handler.handle(job, workUnit, handlerChain) mustEq workResult
    }

    "track an exception as a failure" in {
      handlerChain.passToNextHandler(job, workUnit) throws new RuntimeException("Something bad happened")
      val workResult = handler.handle(job, workUnit, handlerChain)
      workResult.getStatus.isSuccess must_== false
      workResult.getMessage mustEq "Something bad happened"
      there was one(tracker).trackWorkResult(JobType.TEST_MESSAGE, workResult)
    }
  }
}

Aber sowas von!

Wir stellen ein:

• GWT-/ Java-Experten
• Frontend Developer
• Senior Backend-Developer

Alle aktuellen Ausschreibungen gibt’s unter: http://developer.vz.net/jobs/

The service that I’ve been spending a lot of time on at VZ is what we call the “notificator”.  It is responsible for generating all the HTML emails that the platform sends, from registration emails through to new message notifications, event invites, photo comments etc.  Each notification type shares a lot of its functionality with the other notification types, the emails all look very similar, and sometimes only differ by what resource keys are used to generate their wording.

There are many bugs that could be introduced in this system.  Here are some examples of things that I want to and can automatically test:

• All generated HTML is valid markup
• All keys that the templates use exist in our resource bundles.  When a key doesn’t exist, text like this ends up in the email: ???new.comment.action???
• All URLs in links and images are absolute URLs and are to the right platform
• Standard headers and titles in emails are correct

There are also many specific things for each notification type that I want to test.  The requirements I have mean that I can’t just run the tests for one notification type, or for one language, or for one platform, or for one AB testing variant.  I have to run the tests for every permutation of these.  Writing these tests manually would be a nightmare.  Fortunately, JUnit has a few features that can help us here.

Setting up configurations

Before we go into the details of how to use JUnit to help, we need to set up representations of our configurations. This can be most easily done using enums. For language, variants and platforms, we can use quite simple enums:

public enum Language {
  GERMAN("de"), ENGLISH("en");
  public final String abbreviation;
  Language(String abbreviation) {
    this.abbreviation = abbreviation;
  }
}
public enum Variant {
  SMALL_PROFILE_PICS, LARGE_PROFILE_PICS
}
public enum Platform {
  SCHUELERVZ("http://www.schuelervz.net"), STUDIVZ("http://www.studivz.net"), FREUNDEVZ("http://www.freundevz.net");
  public final String baseUrl;
  Platform(String baseUrl) {
    this.baseUrl = baseUrl;
  }
}

Sometimes these enums might already exist in some form in your code already, or you’ll have to make them up specifically for the tests. Using ones specific to your tests have the advantage that you can add meta data that is important to the tests to them, as I’ve done above with the base URLs for the platforms.

For the notification types, I wanted a bit more functionality, for example, code to run notification type specific assertions. There are many ways this could be implemented, I decided to do it using anonymous classes in an enum, implementing a method that accepts a jsoup Document to run assertions on:

public enum NotificationType {
  NEW_MESSAGE(new MessageData("Test Subject", "Test content")) {
    public void runAssertions(Document body) {
      assertThat("Test Subject", equalTo(body.getElementById("subject").text()));
      assertThat("Test content", equalTo(body.getElementById("content").text()));
    }
  },
  GRUSCHEL(new GruschelData()),
  ...
  public final Object testData;
  NotificationType(Object testData) {
    this.testData = testData;
  }
  public void runAssertions(Document body) {
  }
}

Using JUnit parameters

Now that I’ve got the different configurations, I can write a test that JUnit will run for every permutation of configurations. For my first attempt, I’m going to use JUnit parameters. This is by far the simplest way to do things. The first thing to do is declare the runner for the test class:

@RunWith(Parameterized.class)
public class EmailGenerationTest {

Now I can set up my permutations. The way the JUnit parameterized runner works is you annotate a method with @Parameterized.Parameters, and that method must return a collection of object arrays, each nested array being the set of arguments to pass to the tests constructor for each permutation. I’m going to implement this like so:

private final Variant variant;
private final NotificationType type;
private final Platform platform;
private final Language language;
public EmailGenerationTest(Variant variant, NotificationType type, Platform platform, Language language) {
  this.variant = variant;
  this.type = type;
  this.platform = platform;
  this.language = language;
}
@Parameterized.Parameters
public static Collection<Object[]> generateParameters() {
  Collection<Object[]> params = new ArrayList<Object[]>();
  for (Variant variant: Variant.values()) {
    for (NotificationType type: NotificationType.values()) {
      for (Platform platform: Platform.values()) {
        for (Language language: Language.values()) {
          params.add(new Object[] {variant, type, platform, language});
        }
      }
    }
  }
  return params;
}

Finally I can write my tests. Each test method that I write will be run once for each permutation of parameters that I have generated.

@Test
public void noResourceKeysShouldBeMissing() {
  String html = ...// code to generate email given the parameters
  assertThat(html, not(containsString("???")));
}
@Test
public void notificationSpecificAssertionsShouldPass() {
  Document body = ...// code to generate jsoup document of the email given the parameters
  type.runAssertions(body);
}
...

This works very nicely, I can add new notification types, variants, languages and platforms, and I only have to change my tests in one place specific to that configuration.  I can also add new general tests to one place, and they get run for every permutation. However, there is one problem. JUnit names each set of parameters with a sequential number. Working out which number relates to which permutation can be difficult, especially considering that we are dynamically generating the parameters.  Here’s an example of what such a test run looks like in IntelliJ IDEA:

You can see that I don’t get much information. Maven test runners are also similarly unhelpful. However, there is another strategy you can use to make sure you have the right information about failures.

Custom suites

This method is quite involved, if you only have a handful of permutations, it’s certianly not worth it. In my case I have many hundreds of permutations, and so it’s invaluable. The idea is that for each configuration type, we have a custom test suite. These get nested together to form our permutations. What we can do with these is give each a name according to which configuration parameter it’s for, and so we can easily work out which permutation of configurations failed. To start off with, I’m going to write an abstract runner that simply has a name and a list of child runners.  This will be the building block for my tree of runners.

public static class NamedParentRunner extends ParentRunner<Runner> {
  private final List<Runner> runners;
  private final String name;
  protected NamedParentRunner(Class<?> klass, List<Runner> runners, String name) throws InitializationError {
    super(klass);
    this.runners = runners;
    this.name = name;
  }
  protected List<Runner> getChildren() {
    return runners;
  }
  protected Description describeChild(Runner child) {
    return child.getDescription();
  }
  protected void runChild(Runner child, RunNotifier notifier) {
    child.run(notifier);
  }
  protected String getName() {
    return name;
  }
}

Now I’m going to write a test runner that will instantiate each test and run the methods on it.  I’ll extend the existing JUnit class runner because I don’t want to reimplement all the logic to do with looking up methods:

private static class TestRunner extends BlockJUnit4ClassRunner {
  private final Variant variant;
  private final NotificationType type;
  private final Platform platform;
  private final Language language;
  private TestRunner(Class<?> klass, Variant variant, NotificationType type,
      Platform platform, Language language) throws InitializationError {
    super(klass);
    this.variant = variant;
    this.type = type;
    this.platform = platform;
    this.language = language;
  }
  public Object createTest() throws Exception {
    return new EmailGenerationTest(variant, type, platform, language);
  }
  protected String getName() {
    return language.name();
  }
  protected String testName(final FrameworkMethod method) {
    return String.format(method.getName() + "[%s-%s-%s-%s]",
        variant.name(), type.name(), platform.name(), language.name());
  }
  protected void validateConstructor(List<Throwable> errors) {
  }
  protected Statement classBlock(RunNotifier notifier) {
    return childrenInvoker(notifier);
  }
}

Note that the name of this runner is the language, it is going to be the inner most runner and the language is going to be used as the inner most list.  The createTest() method is the most important to implement here, it actually instantiates the test class with the right config.  testName() is also very important, it should uniquely identify the test with its config, and it’s what things like maven will display as the name of the test.  Naming it appropiately will allow you to easily see which config the test failed under.

Now I’m going to write my custom runner that I will pass to the @TestRunner annototation, it will build up a tree of nested NamedParentRunner‘s.

public static class EmailGenerationRunner extends Suite {
  public EmailGenerationRunner(Class<?> klass) throws InitializationError {
    super(klass, createChildren(klass));
  }
  private static List<Runner> createChildren(Class<?> klass) throws InitializationError {
    List<Runner> variants = new ArrayList<Runner>();
    for (Variant variant : Variant.values()) {
      List<Runner> types = new ArrayList<Runner>();
      for (NotificationType type : NotificationType.values()) {
        List<Runner> platforms = new ArrayList<Runner>();
        for (Platform platform : Platform.values()) {
          List<Runner> languages = new ArrayList<Runner>();
          for (Language language : Language.values()) {
            languages.add(new TestRunner(klass, variant, type, platform, language));
          }
          platforms.add(new NamedParentRunner(klass, languages, platform.name()));
        }
        types.add(new NamedParentRunner(klass, platforms, type.name()));
      }
      variants.add(new NamedParentRunner(klass, types, variant.name()));
    }
    return variants;
  }
}

This is a fair bit more code than our initial attempt, and is also a lot of code for a single test class. But when you consider that this single test is running hundreds of sub tests that test the core functionality of my appliaction, it’s not so bad. And the results are really quite nice. This is now what it looks like in IDEA, I get a tree of permutations and can click to expand them to see what passed and what failed:So now we’ve seen some quite advanced methods for testing many permutations of configurations over the same code in JUnit. Since implementing this in notificator, I’ve been able to much more confidently make major refactorings of my templates, as well as add new notification types without having to worry about manually checking every platform, language and variant combination. I hope this will help you in the same way.

You can download the above example code from GitHub.

Using GreenMail with JUnit

GreenMail starts as a server listening on ports for SMTP/POP/IMAP connections, these are naturally handled by background threads. In order to use GreenMail in unit testing, you need to start it up before each test and shut it down again after.  GreenMail is incredibly fast to startup and shutdown so there’s no worries about performance of your tests here.

private static final int SMTP_TEST_PORT = 3025;
private GreenMail greenMail;
private MailSender mailSender;

@Before
public void setUp() throws Exception {
    greenMail = new GreenMail(new ServerSetup(SMTP_TEST_PORT, null, "smtp"));
    greenMail.start();
    mailSender = new MailSender("localhost", SMTP_TEST_PORT);
}
@After
public void tearDown() throws Exception {
    greenMail.stop();
}

Now I’m ready to write my tests.  Here’s an example test:

@Test
public void sendShouldSetTheRightText() throws Exception {
    mailSender.send("Hello World!");
    assertThat((String) greenMail.getReceivedMessages()[0].getContent(),
        equalTo("Hello World!"));
}

The getReceivedMessages() method returns an array of javax.mail.internet.MimeMessage, each of which contains all the mime information from each sent email. Note that in this case, I’m assuming that everything is happening synchronously, which it is. Sometimes though (particularly in integration tests) mail is put onto a queue and sent asynchronously. GreenMail offers a handy method for dealing with this, waitForIncomingMail(), which accepts a timeout and a number of emails you want to wait for, and returns a boolean letting you know whether the mail you were waiting for arrived.

Selecting a good port

The above code works fine if you know that port 3025 is free. But you don’t always know that, particularly if you’re running your tests on a CI server, that CI server may be running another job that is trying to use the same port. I’ve found the following code useful for picking a good port:

private static int findAvailablePort(int min, int max) {
    for (int port = min; port < max; port++) {
        try {
            new ServerSocket(port).close();
            return port;
        } catch (IOException e) {
            // Must already be taken
        }
    }
    throw new IllegalStateException("Could not find available port in range "
            + min + " to " + max);
}

I can now specify a range of ports and my code will choose one that is free.

Checking who the mail was actually sent to

As you know, mime headers can often lie. Just like the header on a letter might be different to the name on the envelope, the To header set in a mime header might be different to that sent to the SMTP server. This is also known as bccing, and it may be the case that your code uses this. If that is the case, you can’t run assertions on the To field to ensure that the email was actually sent to the right person (although, due to this bug in GreenMail you actually can, but you can’t know whether they weren’t added to the To header by your code). However, GreenMail provides a way to get mail that was actually delivered to a particular user. The first thing you need to do is get a reference to the object for that user, this is most easily done by setting their password, I do this in the setUp() method:

greenMailUser = greenMail.setUser("recipient@example.org", null);

Now when it comes to writing my tests, I can look up that users inbox and find the messages that are in it:

MailFolder inbox = greenMail.getManagers().getImapHostManager().getInbox(greenMailUser);
List<StoredMessage> messages = inbox.getMessages();
if (!messages.isEmpty()) {
    messages.get(0).getMimeMessage();
    ...
} else {
    fail("No email for user arrived")
}

Checking the envelope from address

A similar issue to bccing is telling the SMTP server that you’re sending from a different email address to the email address you put in the mime headers. This is also known as the envelope from or bounce address, and it’s typically used for error reporting, for example, to tell the sender that the mailbox doesn’t exist. This can be set in Java by creating an instance of com.sun.mail.smtp.SMTPMessage instead of MimeMessage and setting it using the setEnvelopeFrom() method. This is not a mime header that we can just check, however SMTP servers are required to put this address into the email in the mime header Return-Path. GreenMail does this to. So to assert that the correct envelope from address was set:

String returnPathHeader = message.getHeader("Return-Path", ",");
assertThat(returnPathHeader, notNullValue());
InternetAddress returnPath = InternetAddress.parse(returnPathHeader)[0];
assertThat(returnPath.getAddress(), equalTo("bounce-notify@example.org"));

That concludes my post on using GreenMail, if you have any other helpful tips for using GreenMail, please share them as comments here!

When I talk about backing up Voldemort, many might question whether that is really needed.  Data is already replicated across nodes, if one node dies or becomes corrupted, the data should safely exist somewhere else in the system.  This is true, with data replication you don’t need to worry about backing up for the purposes of protecting yourself against hardware failure.  However, that’s not the only reason why you might want to backup.

All software contains bugs, and our services at VZnet are no exception.  Voldemort itself is also no exception.  We can do our best to eliminate bugs through testing, but they will always pop up and we need to be prepared to deal with that.  One type of bug that could occur is a bug that corrupts data.  What if we pushed an update that, though it passed the tests, contained a race condition that under load results in the wrong data being associated with the wrong keys.  Replication won’t help you there, Voldemort will, by design, replicate the data corruption your code has caused across its nodes.  There are many other places where replication won’t help you, like if all your storage nodes use the same SAN and your SAN overheats destroying all its disks, or a dangerously under-skilled business owner decides to try to query the database er… key-value store and in the process deletes all your data.  But potential corruption due to bugs in our code was the issue that we were most worried about.

So, how do we go about backing up a Voldemort datastore?  The first question that needs to be answered is how Voldemort is storing its data.  Voldemort has pluggable back-end storage support, with the primary two back-ends available being MySQL and the Java implementation of Berkeley-DB (BDB).  We’re using BDB, so the next question we need to ask is how do we backup a BDB database?  Some answers on forums on the web point out that since BDB is an append only database, backups can be done safely by just copying its files.  This is only partially true.  BDB is an append only database, however it also has a clean up thread.  The clean up thread periodically scans through the database and removes outdated entries from the database and compacts the files.  This stops the database from constantly growing every time a record is updated.  It also means that if you copy the files while the clean up thread is running, you risk having a corrupt backup.

Fortunately, the Java BDB implementation comes with a tool that can be used to assist with backups.  In short, the tool pauses the clean up thread, finishes the current file that is being appended to, and then gives you a list of files that you can backup.  It supports incremental backups too, which is great for large databases.

My first naive attempt to use this tool was to write a small Java program that ran independent of Voldemort.  This was a failure, because an external process can’t pause the clean up thread, nor can it even access the database because Voldemort has it locked.  So I needed to implement something into Voldemort.  Controlling this feature is most sensibly done using the Voldemort admin tool, which I found very easy to extend.  The result can be found in the bdb-backup branch of my fork of Voldemort on GitHub.  I’ve initiated a pull request and hopefully the folks at LinkedIn will be happy to accept it.

The feature can be used by passing a new --native-backup command line option, information about how to use this is built into the admin clients help.  Using this new feature you can now create guaranteed consistent backups of your BDB Voldemort nodes, and you can rest assured knowing that you can recover from the many data corruption issues that replication won’t save you from.

Firefox 3.6 bis Firefox 7.0 (01.11.2009 bis 01.10.2011)

Chrome 11 bis Chrome 14 (17.05.2011 bis 17.10.2011, der grüne Graph aka “Unknown Chrome” ist dem Chrome 13 zuzurechnen)

Internet Explorer 6 bis Internet Explorer 9 (1.10.2009 bis 1.10.2011)

Was denkt ihr: Machen die schnellen Release-Zyklen Sinn, oder sorgen die nur für Verwirrung beim Nutzer?

(In der Grafik sind _nicht alle_ Browser abgebildet)

Wir unterstützen mit unserer neusten Version (GWT basierend) folgende Browser:

• Firefox 3.6+
• Chrome 11+
• Internet Explorer 7+
• Opera 11.5
• Safari 5+

Slides from April 5th:

“Differenzial Analyse in der Praxis, Wie man mit Hilfe von Differenzial Analyse die Zufälligkeit von Werten analysiert” by Florian Walther
http://www.slideshare.net/GEEKcon/differenzial-analyse-in-der-praxis-florian-walther 

“Webdocumentaries – Die Technik hinter interaktiven Domumentationen im Netz” by Jan Petzold
http://www.slideshare.net/GEEKcon/webdocumentaries-die-technik-hinter-interaktiven-dokumentationen-im-netz-jan-petzold 

• 5. April 2011
• Ab 18:30 Uhr öffnet der Roadrunner’s Club seine Pforten.
• Die Vorträge beginnen um 19:15 Uhr.

Agenda

• Multimediale Kommunikation mit dem Plauderkasten Tom Hensel (VZnet Netzwerke)
• Automatisierungstechnologien für die Infrastruktur mit Chef von Frederic Jaeckel (SoundCloud)
• WebDocumentaries: Die Technik hinter interaktiven Dokumentationen im Netz von Jan Petzold (Deutsche Welle)

PS:

Die GEEKcon ist eine Veranstaltungsreihe, mit dem Ziel gemeinsam über neue Technologien, aktuelle Projekte und Probleme und innovative Lösungsansätze im Bereich Software- und Webentwicklung zu diskutieren. Alle zwei Monate treffen sich Entwickler, Anwender, Unternehmer und sonstige Web-Interessierte im Roadrunner’s Club in Berlin Prenzlauer Berg zum Gedanken- und Ideenaustausch.

Die GEEKcon steht allen offen, die sich für die Zukunft des Internets interessieren und diese mitgestalten wollen: vom Anfänger bis zum Experten, vom Entwickler bis zum Blogger. Organisiert wird die Veranstaltung von den VZ-Netzwerken.

Zur GEEKcon laden wir in der Regel drei Referenten ein, ihr Thema in einem etwa 20 minütigen Vortrag zu präsentieren. Im Anschluss daran können wir bei dem einem oder anderem Bierchen gemeinsam diskutieren, Leute treffen, Kontakte knüpfen und Jobs finden.

Herzlich Willkommen sind auch all jene, die die GEEKcon nutzen möchten, um eigene Projekte und Produkte vorzustellen. Vorträge können mit Angabe eines Themas unter geekcon@vz.net bei uns eingereicht werden.

Größere Kartenansicht

var person = opensocial.newPerson({thumbnailUrl : 'BASE64_ENCODED_PHOTO'});
opensocial.requestUpdateViewer(person, function(response) {
   // response is either true or false 
});

When the requestUpdateViewer method is called we will ask the user if he really wants to change his profile picture to the new one. The user’s decision will be passed as a parameter to the callback function. As a developer you have to pass the new picture in the thumbnailUrl field of the opensocial.Person object. The content of this field is just the base64 encoded image in a valid Data-URL format.

For more information see http://developer.studivz.net/wiki/index.php/Opensocial_(v0.9)#opensocial.requestUpdateViewer

Mashing up JavaScript – Advanced Techniques for modern Web Apps

Bastian Hofmann,VZnet Netzwerke Ltd.

2011-05-31 | 02:15 PM – 03:15 PM

Nowadays many modern web applications are solely relying on JavaScript to render their frontend. But if you want to create mashups, load data from many different places or include external widgets into your site, you are quickly running into boundaries because of browser and security restrictions. In this presentation I will talk about techniques helping you with such problems.

For more information, tickets etc see http://phpconference.com/2011spring

Wir testen seit Anfang des Jahres Desktop Notifications für den Plauderkasten! Das Ganze basiert auf dem “WebNotifications Standard Draft” des W3C und wurde bisher leider nur im Chrome implementiert. Seit ein paar Tagen nutzt Google Mail das Feature auch. Hier wird man als eingeloggter Nutzer über neue Mails oder Chatnachrichten informiert.

Wie funktioniert das Ganze?
Der Standard beschreibt eine API, die der Browser bereitstellt und welche mittels JavaScript angesprochen werden kann. Ist das ganze korrekt implementiert werden die Desktophinweise (“Notifications”) entsprechend den gewünschten Werten dargestellt. Das war’s eigentlich auch schon. ;-)

Ein wenig Code dazu:
//gather permission through user input
window.webkitNotifications.requestPermission();


//create and show notification
notificationObject = window.webkitNotifications.createNotification(image_url, name, message);
notificationObject.show();


Aus Nutzersicht:
Initial muss man Desktop Notifications domainspezifisch aktivieren. Das geht momentan über den Plauderkasten-Einstellungsdialog. Den findet ihr beim geöffneten Plauderkasten links oben mit einem Klick auf den Schraubenschlüssel.

Ein weiterer Klick auf “Aktivieren” erzeugt im Chrome die Abfrage zum freischalten der Domain.

Nach einem weiteren Klick auf “zulassen” ist wird die Berechtigung im Broswer gespeichert und ihr solltet die erste Notification sehen.

Bei neuen Nachrichten von Personen, mit denen ihr euch gerade nicht unterhaltet, sollten nun Desktop Notifications auftauchen. Diese enthalten Namen und Nutzerbild des Absenders, sowie die Nachricht. Dazu muss der Plauderkasten allerdings momentan noch geöffnet sein (man kann ihn ja im Hintergrund auflassen ;-)).

Wir hoffen, dass auch die anderen Browserhersteller auf den Zug aufspringen und diesen Standard weiter vorrantreiben.

Quellen und weitere Links:
http://dev.w3.org/2006/webapi/WebNotifications/publish/
http://dev.chromium.org/developers/design-documents/desktop-notifications/api-specification
http://dev.chromium.org/developers/design-documents/desktop-notifications

Distributed Identities with OpenID

English session

The era of many separated logins and identities in the web is slowly coming to an end. Currently many of the big players are spurring this on with their own proprietary solutions, but open standards are starting to get more support as well with OpenID being the most promising one. In this session I will show how OpenID works for users and developers, where it currently fails and how OpenID is planned to evolve in the future.

Speaker: Bastian Hofmann

http://confoo.ca/en/2011/session/distributed-identities-with-openid

How to create social apps for millions of users

English session

Social apps have become very popular in the last years. In this session I will show you how to create an OpenSocial app which can be used by over 900 million users on many social networks around the world. After introducing you to the main concepts behind OpenSocial I will demonstrate live that it is easier than you think to develop a rich social app. Additionally to the basics like accessing the user’s social graph or integration with external APIs, I will also highlight features that will help you with a quick viral distribution, tight integration into the user’s social experience and access through mobile devices.

Speaker: Bastian Hofmann

http://confoo.ca/en/2011/session/how-to-create-social-apps-for-millions-of-users

UPDATE Die Referenten stehen jetzt fest:

• Der kleinste Computer-Cluster der Welt von Tim Lossen (wooga)
• User Centered Prozesse von Choukri Bijjou (VZ-Netzwerke)
• Google Web Toolkit von Raphael Bauer und Dominic Jansen (beide VZ-Netzwerke)

Die GEEKcon ist eine Veranstaltungsreihe, mit dem Ziel gemeinsam über neue Technologien, aktuelle Projekte und Probleme und innovative Lösungsansätze im Bereich Software- und Webentwicklung zu diskutieren. Alle zwei Monate treffen sich Entwickler, Anwender, Unternehmer und sonstige Web-Interessierte im Roadrunner’s Club in Berlin Prenzlauer Berg zum Gedanken- und Ideenaustausch.

Die GEEKcon steht allen offen, die sich für die Zukunft des Internets interessieren und diese mitgestalten wollen: vom Anfänger bis zum Experten, vom Entwickler bis zum Blogger. Organisiert wird die Veranstaltung von den VZ-Netzwerken.

Zur GEEKcon laden wir in der Regel drei Referenten ein, ihr Thema in einem etwa 30 minütigen Vortrag zu präsentieren. Im Anschluss daran können wir bei dem einem oder anderem Bierchen gemeinsam diskutieren, Leute treffen, Kontakte knüpfen und Jobs finden. Herzlich Willkommen sind auch all jene, die die GEEKcon nutzen möchten, um eigene Projekte und Produkte vorzustellen.

Vorträge können mit Angabe eines Themas unter geekcon@vz.net bei uns eingereicht werden.

Die Veranstaltung ist kostenlos und für Getränke ist gesorgt.
Größere Kartenansicht

• Revisions that have been requested for testing can be un-qued (“cancel testing”), so developers can edit the code again without being reviewed immediately or influencing the currently productive revision.

• After a revision’s approval, developers gain the possibility to put revisions online by themselves. So switching between approved revisions works using “set online”. Revisions marked as buggy by the developer flip back to development mode, if they weren’t productive already.

• If an administrator sets a gadget offline due to bugs or security issues, you can set the gadget online again by uploading a new revision and passing through the review process or contacting our developer support team.

• A common way for services to receive content, removing any and all service-specific integration requirements
• A discovery feature so services can publish themselves and their endpoints, making it possible to integrate with services you didn’t even know about at development time
• A decentralized, user-centric model for saving preferred services, making sharing more personal

Shared pages can be posted by the user into his feed or sent as a private message. Since yesterday you can now also not only add a title and description for the page you are sharing, but also a thumbnail which will be integrated into your feed post or message. This is possible by either adding this meta information as a OExchange query parameter to the VZ sharing endpoint or by implementing OpenGraph Meta Tags into your site.

You can find more detailed information in our developer wiki at http://developer.studivz.net/wiki/index.php/Bookmarking. Or you can have a look at http://www.oexchange.org/ where you can find the complete specification as well as some tools that help you with testing OExchange endpoints as well as your implementation.

To make the implementation as easy as possible we are also now providing a simple and lightweight JavaScript library, which you can include into your site. You will finde more information about this library and further code examples at http://developer.studivz.net/wiki/index.php/JS-Library.

Wir von VZnet wollen im regelmäßigem Abstand gemeinsam mit Gleichgesinnten neue Technologien, aktuelle Probleme und Lösungsansätze in lockerer Atmosphäre diskutieren.

Die erste GEEKcon findet am

7. Dezember 2010 im Roadrunner’s Club (Google Places Link), Berlin statt.

Ab 19:00 Uhr laden wir alle Interessierten ein, bei Getränken, Talk und Diskussion den Abend mit uns zu verbringen.

Agenda

• 19.00 Uhr: Eröffnung, Jan Lohmer und Sebastian Jerie
• 19.15 Uhr: VZ-ID, präsentiert von Bastian Hofman und Axel Tölke (VZnet Netzwerke)
• 20.15 Uhr: The communication revolution, präsentiert von Dr. Johannes Mainusch (XING AG)
• 21.15 Uhr: Fraud Detection bei VZ, präsentiert von Dr. Falk-Florian Henrich (VZnet Netzwerke)

Mehr Informationen erfahrt ihr auf dem GEEKcon Profil ( studiVZ / meinVZ ).

Egal was die persönlichen Beweggründe sind Anwendungen für Soziale Netzwerke zu schreiben, es gibt für all diese Netzwerke eine Hürde: Die API der Plattform.

StudiVZ ist hier den Weg der Standardisierung gegangen. StudiVZ setzt bei der Plattform API ganz auf die OpenSocial API mit einigen speziellen VZ Erweiterungen. Für Entwickler hat die OpenSocial API den Vorteil das die Apps im Prinzip einfacher auf andere Plattformen, die ebenfalls die OpenSocial API implementieren, portiert werden können.

Anwendungen für StudiVZ Entwickeln

Gadgets spielen eine zentrale Rolle in der Anwendungsentwicklung für StudiVZ. Gadgets sind XML Dokumente die als Manifest für die Anwendungen fungieren. Im XML definiert man die API die verwendet wird, die Features die von der Plattform benötigt werden und die Views die verwendet werden. Die Inhalte sind ebenfalls in diesem XML definiert und bestehen in der Regel aus HTML, CSS und JavaScript. Durch die Definition der Inhalte für einen View lassen sich unterschiedliche Darstellungen realisieren. Zum Beispiel kann ein Gadget sich auf der Profil Seite anders darstellen als auf der Gruppenseite und auch so komplett andere Funktionalität mitbringen.

Ein praktisches Beispiel

Im folgenden werde ich eine Web Anwendung schreiben und diese mittels eines Gadgets in die StudiVZ Plattform integrieren. Als Tool verwenden wir WebMatrix, eine kostenlose komplette Entwicklungsumgebung mit Editor, Webserver und Datenbank. Das ganze lässt sich elegant über den Web Plattform Installer auf dem Entwickler Rechner installieren und man kann loslegen.

Link: Installation von WebMatrix durch den Web Platform Installer

Neben PHP unterstützt WebMatrix ASP.NET Web Pages welche ich zur Erstellung der Seite wähle. Die Idee für das Szenario ist fiktiv und einfach, zeigt aber grundsätzlich alle wichtigen Konzepte.

Die Anwendung soll eine Petitionsliste für die Erhaltung des Internets darstellen. Die letzten 5 Unterschriften werden angezeigt und man kann sich direkt in die Liste eintragen. Wenn man sich Einträgt wird automatisch an die StudiVZ Pinnwand eine Nachricht erstellt mit dem Wortlaut “{name} hat sich in die Petition zum Erhalt des Internets unterschrieben!”

Die Schritte zur StudiVZ Petitions App

Die folgenden Schritte sind Notwendig um die Anwendung zu realisieren:

1. Beantragung eines Developer Accounts bei StudiVZ
2. Erstellen der Petitionslisten Web Anwendung
3. Publizieren der Anwendung bei einem Hoster
4. Erstellen des Gadgets
5. Hochladen des Gadgets und Testen

Beantragung eines Developer Accounts bei StudiVZ

Um einen Entwickleraccount zu beantragen muss man natürlich bei StudiVZ registriert sein. Genauer gesagt langt es wenn man in einem der VZ Netzwerke registriert ist. Ich habe mich bei MeinVZ.net registriert und dort dann auf der Seite http://www.meinvz.net/developer einen Antrag gestellt.

Wer sich jetzt frägt wer Zsuirad ist der mag doch einfach das Wort Rückwärts lesen. Eigentlich hätte ich keinen Alter Ego Account anlegen müssen, die Developer Sandbox bietet bereits eine Reihe an Accounts die man zum Testen der App benutzen kann. Praktisch. Der Link führt einen zu einem weiteren Fragebogen, ausfüllen und warten bis man eine Bestätigung bekommt (Dieser Schritt kann auch mal 1 oder 2 Tage dauern).

Erstellen der Petitions Anwendung

Die Petitions Anwendung erstellen wir in WebMatrix. Dazu wähle ich aus den Projekt-Templates entsprechend das Empty Site Projekt und lege eine neue Datei mit dem Namen Petition.cshtml an.

Danach wechsel ich in den Database Workspace und lege eine neue Datenbank an und erstelle dort die Tabelle Signed. Die Tabelle enthält eine automatisch generierte Id, den Namen und das Datum der Signatur.

Der Grundstein ist gelegt. Nun kann die Anwendung mit Leben sprich Code gefüllt werden.

   1: @{
   2:     var db = Database.Open("Petition");
   3:     
   4:     if( IsPost )
   5:     {
   6:         var errors = false;
   7:         var signature = Request["name"];
   8:  
   9:         if( signature.IsEmpty() )
  10:         {
  11:             errors = true;
  12:             @:Willst Du unterschreiben, dann trage Deinen Namen ein!<br/>
  13:         }
  14:         
  15:         if( errors == false )
  16:         {
  17:             var insert = "INSERT INTO Signed (Name, DateAndTime) 
  18:                             VALUES (@0, @1)";
  19:             db.Execute( insert, signature, DateTime.Now);
  20:         }
  21:     }
  22:     
  23:     var people = db.Query( "SELECT TOP(5) * FROM Signed 
  24:                                 ORDER BY DateAndTime DESC");
  25:     var totalPeopleSigned = db.QueryValue( "SELECT COUNT(*) FROM Signed" );
  26: }
  27:  
  28:  
  29: <!DOCTYPE html>
  30:  
  31: <html lang="en">
  32:     <head>
  33:         <meta charset="utf-8" />
  34:         <title>Petition</title>
  35:     </head>
  36:     <body>
  37:         
  38:         <h1>Petition zur Erhaltung des Internets</h1>
  39:         
  40:         <h2>Zuletzt unterschrieben von</h2>
  41:         
  42:         <ul>
  43:         @foreach( var person in people ) {
  44:             <li>@person.Name am @person.DateAndTime</li>
  45:         }
  46:         </ul>
  47:         
  48:         <h2>@totalPeopleSigned Menschen haben diese Petition unterschrieben</h2>
  49:         
  50:         <div id='petitionform'>
  51:             <form method="POST">
  52:                 <fieldset>
  53:                     <h4>Unterschreibe diese Petition</h4>
  54:                     <label for="Name">Name: </label>
  55:                     <input type="text" name="Name" />
  56:                     <input type="submit" value="Signed"/>
  57:                 </fieldset>
  58:             </form>
  59:         </div>
  60:     </body>
  61: </html>

Das @ Zeichen deklariert einen Razor Code Block. Razor ist die Syntax der View Engine die für ASP.NET Web Pages benötigt wird. Die Zeilen 1 – 26 greifen auf die Datenbank zu und prüfen ob es sich um einen Postback der Seite handelt. Falls ja, wird ein neuer Datensatz in die Datenbank eingetragen.

In der Zeile 43 – 46 sieht man die dynamische Erstellung der Personen die bereits die Petition unterschrieben haben. Zum Schluß folgt noch die Form die den Postback auslösen kann.

Publizieren der Web Anwendung

Damit die Web Anwendung aus einem StudiVZ Gadget genutzt werden kann, muss ich diese erst noch bei einem Hoster veröffentlichen. WebMatrix bietet hierfür eine Publish Schaltfläche, die automatisch auch noch Provider anbietet die ASP.NET Web Pages hosten können.

Nach dem Eintragen meiner Publishing Credentials publiziere ich die Anwendung mittels Web Deploy auf den Server.

Die App ist nun publiziert und unter der URL http://20313wdbv4.adhostbeta.com/studivz/petition.cshtml erreichbar.

Erstellen des Gadgets

Die Anwendung muss nun in ein Gadget gepackt werden. Hierfür gibt es entsprechende XML Schema Definitionen die auf dem Developer Wiki von StudiVZ zu finden sind. Das Gadget soll im Canvas View einfach die Anwendung kapseln und darstellen. Das ist leicht bewerkstelligt und sieht als Gadget folgendermaßen aus:

    1: <?xml version="1.0" encoding="UTF-8" ?>
   2: <Module>
   3:     <ModulePrefs title="Petition Gadget">
   4:         <Require feature="opensocial-0.9" />
   5:         <Require feature="minimessage"/>
   6:         <Require feature="views"/>
   7:         <AllowedDomain name="20313wdbv4.adhostbeta.com"/>
   8:     </ModulePrefs>
   9:     <Content view="canvas" type="url" href="http://20313wdbv4.adhostbeta.com/studivz/petition.cshtml">
  10:     </Content>
  11: </Module>

Doch bevor wir das Gadget testen wollen wir noch die Funktionalität erweitern. Das einbinden der externen Webseite im Canvas bringt zwar ein schnelles Resultat doch hat man hier nichts weiter als die Seite eingebunden und keinerlei Integration in die StudiVZ Plattform getätigt.

Den Canvas View lasse ich erstmal so. Ich erweitere das Gadget um einen Content Bereich für die Views Profile und Group. In diesem View soll sich das Gadget entsprechend in die Seite integrieren. Beachten muss man lediglich das dass Gadget mit den Maßen 390 x 400px angezeigt wird, Content darüber wird abgeschnitten. Unsere Seite eignet sich nicht direkt für die Profile und Group Views, da das generierte HTML mit der Form zusammen größer ist.

Auch die Integration mit der Möglichkeit an die Pinnwand zu schreiben muss in die Signierung der Petition integriert werden. Das erfordert ein “Refactoring” der eigentlichen Anwendung. Ich füge zur Anwendung zwei URL Endpunkte hinzu. Eine die die letzten Petitionen anzeigt und eine die als POST Endpunkt dient um neue Unterschriften hinzuzufügen.

Security über OAuth

Die Authorisierung zwischen Gadget und Web Anwendung erfolgt über OAuth, einem Standard der es erlaubt Anwendungen untereinander zu vertrauen und entsprechend Zugriffe zu gewähren. Im Gadget werde ich die Signatur Funktion von OAuth nutzen, in der Web Anwendung verzichte ich auf die Prüfung, diese sollte natürlich erfolgen damit nicht jeder x-beliebige Post einer beliebigen Seite angenommen wird. Es gibt zahlreiche OAuth Tutorials auf dem Developer Wiki, so dass diese Übung dem Leser überlassen bleibt.

Damit habe ich nun zwei weitere Endpunkte:

ListPetition.cshtml

    1: @{
   2:     var db = Database.Open("Petition");
   3:     
   4:     var people = db.Query( "SELECT TOP(5) * FROM Signed ORDER BY DateAndTime DESC");
   5:     var totalPeopleSigned = db.QueryValue( "SELECT COUNT(*) FROM Signed" );
   6: }
   7:  
   8:  
   9:         <h1>Petition zur Erhaltung des Internets</h1>
  10:         
  11:         <h2>Zuletzt unterschrieben von</h2>
  12:         
  13:         <ul>
  14:         @foreach( var person in people ) {
  15:             <li>@person.Name am @person.DateAndTime</li>
  16:         }
  17:         </ul>
  18:         
  19:         <h2>@totalPeopleSigned Menschen haben diese Petition unterschrieben</h2>
  20:

und SignPetition.cshtml

    1: @{
   2:     var db = Database.Open("Petition");
   3:     
   4:     if( IsPost )
   5:     {
   6:         var errors = false;
   7:         var signature = Request["name"];
   8:  
   9:         if( signature.IsEmpty() )
  10:         {
  11:             errors = true;
  12:             @:Es fehlt die Unterschrift!<br/>
  13:         }
  14:         
  15:         if( errors == false )
  16:         {
  17:             var insert = "INSERT INTO Signed (Name, DateAndTime) VALUES (@0, @1)";
  18:             db.Execute( insert, signature, DateTime.Now);
  19:             @:Danke f�r Deine Unterschrift!<br/>
  20:         }
  21:     }
  22:     else
  23:     {
  24:         Response.Redirect("~/Petition.cshtml");
  25:     }
  26: }

Wie schon gesagt, im richtigen Anwendungsfall sollte letztere auf jeden Fall die OAuth Signatur prüfen.

Da wir nun die Endpunkte haben können wir auch das Gadget um den Content Bereich für Profile und Group erweitern.

    1: <?xml version="1.0" encoding="UTF-8" ?>
   2: <Module>
   3:     <ModulePrefs title="Petition Gadget">
   4:         <Require feature="opensocial-0.9" />
   5:         <Require feature="minimessage"/>
   6:         <Require feature="views"/>
   7:         <AllowedDomain name="20313wdbv4.adhostbeta.com"/>
   8:     </ModulePrefs>
   9:     <Content view="profile,group" type="html">
  10:         <![CDATA[
  11:  
  12:             <script type="text/javascript">
   1:  
   2:             
   3:                 gadgets.util.registerOnLoadHandler( initializeApplication );
   4:     
   5:                 function initializeApplication() {
   6:                     showAppVersionMessage();
   7:                     retrievePeopleSignedPetition();
   8:                 }
   9:                 
  10:                 function showAppVersionMessage() {
  11:                     var msg = new gadgets.MiniMessage( '__MODULE_ID__');
  12:                     var statusMsg = msg.createDismissibleMessage("Petition Demo 
  13:                                                             Version 1.2");
  14:                     statusMsg.style.backgroundColor = "grey";
  15:                     statusMsg.style.color = "white";
  16:                 }
  17:                 
  18:                 function retrievePeopleSignedPetition() {
  19:                     var url = 
  20: "http://20313wdbv4.adhostbeta.com/studivz/listpetition.cshtml";
  21:                     var params = {};
  22:                     params[ gadgets.io.RequestParameters.AUTHORIZATION ] = 
  23: gadgets.io.AuthorizationType.SIGNED;
  24:                     gadgets.io.makeRequest( url, 
  25:                                 onRetrievePeopleSignedPetition, params );
  26:                 }
  27:                 
  28:                 function onRetrievePeopleSignedPetition( response ) {
  29:                     document.getElementById('peopleSigned').innerHTML = 
  30:                                                                 response.data;
  31:                 }
  32:                 
  33:                 function signPetition() {
  34:                     var content = document.getElementById('message');
  35:                     postToPetition(content);
  36:                     postToBuschfunk(content);
  37:                 }
  38:                 
  39:                 function postToPetition(content) {
  40:                     
  41:                     var url = 
  42: "http://20313wdbv4.adhostbeta.com/studivz/signpetition.cshtml";
  43:                     
  44:                     var data = { name: content.value };
  45:                     
  46:                     var postdata = gadgets.io.encodeValues( data );
  47:                     
  48:                     var params = {};
  49:                     params[ gadgets.io.RequestParameters.METHOD ] = 
  50: gadgets.io.MethodType.POST;
  51:                     params[ gadgets.io.RequestParameters.POST_DATA ] = postdata;
  52:                     params[ gadgets.io.RequestParameters.AUTHORIZATION ] = 
  53: gadgets.io.AuthorizationType.SIGNED;
  54:                     gadgets.io.makeRequest( url, 
  55:                                 onRetrievePeopleSignedPetition, params );
  56:                 }
  57:                 
  58:                 function postToBuschfunk(content) {
  59:  
  60:                     var params = {};
  61:                     params[ opensocial.Message.Field.TITLE ] = 
  62:                                         'Petition zum Erhalt des Internets';
  63:                     params[ opensocial.Message.Field.TYPE ] = 
  64: opensocial.Message.Type.PUBLIC_MESSAGE;
  65:                     
  66:                     var message = opensocial.newMessage( content.value + 
  67:                             ' hat die Petition zum Erhalt des 
  68:                                     Internets unterschrieben!', params );
  69:                     var recipient = "VIEWER";
  70:                     
  71:                     opensocial.requestSendMessage(recipient, 
  72:                                         message, onSendMessageComplete);
  73:                 }
  74:                 
  75:                 function onSendMessageComplete( data ) {
  76:                     if( data.hadError() ) {
  77:                         alert( "Es gab ein problem: " + data.getErrorCode() );
  78:                     }
  79:                 }
  80:                 
  81:             
</script>
  13:             
  14:             <div id='main'>
  15:                 <div id='peopleSigned'></div>
  16:                 <div id='content'>
  17:                     Unterschreibe auch Du!
  18:                     <input type='text' id='message' />
  19:                     <a href='javascript:void(0);' onclick='signPetition();'>Unterschreiben</a>
  20:                 </div>
  21:             </div>
  22:         ]]>
  23:     </Content>
  24:     <Content view="canvas" type="url" href="http://20313wdbv4.adhostbeta.com/studivz/petition.cshtml">
  25:     </Content>
  26: </Module>

Eine kurze Erklärung der Funktionen. In Zeile 3 (JavaScript) registriere ich eine Funktion die beim Laden des Gadgets angesprungen wird. Die Funktion ruft showAppVersionMessage(); auf, welche über eine Mini Message einfach die aktuelle Versionsnummer des Gadgets anzeigt und dann schließlich die Funktion retrievePeopleSignedPetition();. Diese Funktion ruft letztlich den listpetition Endpunkt auf und erhält entsprechend ein Stück HTML zurück das in den aktuellen Gadget Bereich übergeben wird.

Weiter unten ab Zeile 13 (HTML) ist dann ein Anchor Tag angegeben welches die Funktion signPetition(); aufruft. Diese Funktion schreibt nun über den signPetition Endpunkt einen neuen Datensatz in die Petitions-Datenbank, zum anderen wird postToBuschfunk(); aufgerufen, welche eine Nachricht an die Pinnwand schreibt.

Das ist schon die komplette Funktionalität des Gadgets.

Hochladen des Gadgets und Testen

Um das Gadget zu testen muss man es in ein gleichnamiges ZIP packen. Das Gadget heißt PetitionGadget.xml und die Zip-Datei heißt demzufolge PetitionGadget.zip. Zum Testen nimmt man nun die Developer Sandbox von *VZ her und lädt das Gadget enstprechend hoch.

Ist das Gadget erfolgreich hochgeladen, so kann man sich in der Vorschau die Funktionalität des Gadgets anschauen. Zuerst einen Blick auf den Canvas View:

Dort wird die Web Anwendung 1:1, wie unter der ursprünglichen URL, integriert angezeigt. Schaltet man nun auf den Profile View erhält man das Mashup von dem HTML das im Gadget enthalten ist und dem Resultat des listpetition Endpunktes.

Gut zu sehen, die Mini Message mit der Versionsnummer und die letzten 5 Petitionsunterschriften. Möchte man nun die Petition unterschreiben, so einfach den Namen eintragen und auf Unterschreiben klicken. Sofort kommt die Meldung ob man das Gadget auf die Pinnwand posten lassen möchte:

Bestätigt man mit senden, so sieht man das Resultat auch in der Pinnwand:

Fazit

Dieses einfache Beispiel hat gezeigt wie man eine bestehende Web Anwendung in StudiVZ mittels Gadgets und der OpenSocial API integrieren kann. Die Interaktion mit der OpenSocial API belief sich hierbei nur auf reinem JavaScript, es gibt sowohl noch die Möglichkeit über RPC und REST die API aus eigenen Web Anwendungen zu benutzen. Ich habe viele Bereiche nicht beschrieben die für eine richtige Produktiv-App wichtig wären, wie z.B. ein Melden Button für Custom Generated Content oder auch zusätzliche Informationen die zur Installation des Gadgets beigesteuert werden sollten. Komplett außen vorgelassen wurde das Thema OAuth Authentifizierung und Authorisierung. Das Thema ist umfangreich und mit Sicherheit einen eigenen Blogpost Wert und auf dem Developer Wiki findet man weitere Informationen zu diesem Thema. Das Gadget ist hier voll Funktionsfähig im Post enthalten und die Web Anwendung existiert noch bis mindestens Ende des Kalenderjahres 2010 unter dieser URL http://20313wdbv4.adhostbeta.com/studivz/petition.cshtml.

Autor: Dariusz Parys, Technical Strategist Web Platform, Microsoft Deutschland GmbH

Dariusz Parys ist seit 2007 als Technical Strategist Web Platform bei der D&PE und seit 2000 bei Microsoft Deutschland tätig. Sein Themenschwerpunkt liegt auf der Microsoft Web Platform und verwandten Technologien. Davor war Dariusz zwei Jahre lang bei einem Großkonzern als Enterprise Architect für Microsoft Consulting Services tätig. Sein Wissen und seine Erfahrung vermittelt er in Vorträgen auf zahlreichen Entwicklerkonferenzen und Workshops. Sie erreichen ihn über seinen Blog unter http://downtocode.net und über Twitter @writeline.

Here are the abstracts and the slides for these presentations:

Opening up the Social Web – Standards that are bridging the Islands

Speaker: Bastian Hofmann

Social networks are not closed off to the rest of the web anymore. Various standards like ActivityStreams, PubSubHubbub, WebFinger, OpenSocial, Salmon, OEmbed, XAuth or OExchange are emerging to open them up to other websites. I will introduce these protocols, show how they work together, how you can benefit from them and give an outlook on how they will change the world of social networks.

Slides: http://www.slideshare.net/bashofmann/open-5432123

Distributed Identities with OpenID

Speaker: Bastian Hofmann

The era of many separated logins and identities in the web is slowly coming to an end. Currently many of the big players are spurring this on with their own proprietary solutions, but open standards are starting to get more support as well with OpenID being the most promising one. In this session I will show how OpenID works for users and developers, where it currently fails and how OpenID is planned to evolve in the future.

Slides: http://www.slideshare.net/bashofmann/distributed-identities-with-openid

The event will focus on the use of the OpenSocial, its technologies and implementations, and will have a special concentration on the use of OpenSocial in Research and Education. This two day event is the first OpenSocial Summit held in Europe, and the first to include an industry specific spotlight.

Day one will feature prominent speakers from the OpenSocial community who will present and demonstrate the nuts and bolts of the specification, including what’s new in version 1.1, best practices for building social applications, and the emerging use of OpenSocial within the Enterprise. There will also be technical sessions on understanding Apache Shindig, the open source reference framework for OpenSocial. The first day will conclude with a broad outline of where the community is heading with future releases and a call to action to get involved.

The second day is dedicated to the use of OpenSocial in Research and Education. This will consist of both interactive workshops and presentations. Several industry experts from the Research and Educational sector will discuss their experiences using OpenSocial in their solutions. For example, SURFnet will present its project on implementing a new Collaboration Infrastructure and will demonstrate how OpenSocial plays an important role in this infrastructure by it enabling group centric collaboration in an open, platform independent way.

We’ve setup a wiki page where we will be posting the agenda. While we will do our best to accommodate all who wish to attend, please keep in mind that space is limited. Stay tuned to this blog, the OpenSocial Community list, and the wiki for RSVP information and further details.

http://blog.opensocial.org/2010/10/first-european-opensocial-event-in.html

VZnet will also participating and give a talk on advanced topics of OpenSocial app development, e.g. Data Pipelining, Proxied Content, Embedding of Gadgets or inter gadget communication.

Update: Registration is now open at http://event.surfnet.nl/first_european_opensocial_event_in_utrecht_the_netherlands_6_and_7_december_2010.html

supportsCanvas : function () {
  if (/msie|MSIE 9/.test(navigator.userAgent)) {
    return true;
  }
  var supportsBgSize = !!($('body').css('background-size')
      || $('body').css('-moz-background-size'));
  if (!supportsBgSize) {
    return false;
  }
  var canvas = document.createElement('canvas');
  if (!canvas.getContext) {
    return false;
  }
  return !!canvas.getContext('2d').fillText;
}

Wie man sehen kann, ist es leider keine reine Feature-Detection, da auch die Abfrage des UserAgents erfolgt. Dies erfolgt aus dem Grund, dass die normalen VZ-Seiten momentan im Internet Explorer noch den IE7-Document-Modus verwenden. Im HTML-Head wird dies durch die Zeile

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

definiert. Durch diesen Document-Modus würde im Internet Explorer 9 aber eine reine Feature-Detection auf HTML5-Features nicht funktionieren, da der Internet Explorer 9 im IE7-Modus die HTML5-Features auch nicht unterstützt. Also wurde die Browserüberprüfung entsprechend erweitert, um die korrekte Verlinkung der neuen Diashow und der alten Diashow (die für Browser verlinkt ist, die die HTML5-Features nicht unterstützen) zu erreichen. Die Diashow selbst verwendet natürlich im Internet Explorer 9 den aktuellen Document-Mode, entsprechend ist dort im HTML-Head folgende Zeile:

<meta http-equiv="X-UA-Compatible" content="IE=9" />

Bei den Arbeiten mit dem Canvas-Element ergab sich ein Pattern für komplexere Anwendungen. Statt Verwendung eines einzelnen Canvas-Elements in einer Seite kann man mehrere Canvas-Elemente in eine Seite einbinden (entsprechende positioniert, und mit CSS über z-index die Darstellungs-Anordnung definiert). Dadurch ist es einfach möglich, mit Zeichnungsebenen zu arbeiten, die separat gelöscht und neugezeichnet werden können, die einzeln verschoben/animiert werden können, etc. Jede Zeichnungsebene ist dabei ein Canvas-Element. Diese Technik setzen wir in der Diashow ein, indem der Hintergrund mit einem Canvas-Element dargestellt wird, der Vordergrund mit den Polaroid-Darstellungen von einem anderen Canvas-Element. Bei bestimmten Aktionen, wie dem geringfügigen Ändern der Fenstergröße wird dann nur der Hintergrund neugezeichnet, das Canvas für den Vordergund bleibt bestehen. Mit nur einem Canvas-Element wären dagegen wesentlich mehr Funktionsaufrufe/Zeichenvorgänge nötig. Folgende Screenshots zeigen die Darstellung, wenn man über Firebug nur Vordergrund- bzw. Hintergrund-Canvas einblendet (beim Vordergrund-Canvas wurde zur besseren Darstellung auch die CSS-Hintergrund-Farbe weggeschaltet):

Mit Vorder- und Hintergrund ergibt sich dann die Darstellung in der Diashow:

Die Bildschirmschoner-Animation, die in der Übersicht eines Albums momentan nach 30 Sekunden ohne Aktion gestartet wird, erfolgt entsprechend ebenfalls in einem eigenen Canvas-Element. Dadurch kann dieser Animation auch schnell wieder ausgeblendet werden, und die vorherige Darstellung wiederhergestellt werden, ohne komplexe Canvas-Malvorgänge ausführen zu müssen.

Interessante Links:
Mozilla Canvas Tutorial
Deutsches Canvas Tutorial

// newElement enthält das zu modifizierende HTML. Dabei soll "Mein" durch "<b>Mein</b>" ersetzt
// werden, aber nur in Texten, nicht an sonstigen Stellen im HTML-Code
var newElement = $(['<ul><li>Erste <a href="http://www.Mein.de/">',
    'URL anders?</a> Zeile</li>',
    '<li>Meine zweite Zeile</li><li>Dein und Mein</li>',
    '<li>Nicht Mein sondern Main</li></ul>'].join(''));
  
// Diese Zeile selektiert/filtert die TextNodes in newElement:
var textnodes = $('*', newElement).contents().filter(function(){ return this.nodeType == 3 ; });
  
// Durchlaufen der TextNodes:
$.each(textnodes, function () {
  // mit this.nodeValue erhält man den Text-Inhalt des Text-Elements im DOM
  if (this.nodeValue.indexOf('Mein')>=0) {
    //Ersetzen des TextNodes durch ein HTML-Konstrukt
    $(this).replaceWith(this.nodeValue.replace('Mein', '<b>Mein</b>'));
  }
});
  
// Anzeige des Ergebnis
console.log(newElement.html());

Now that the time is coming to migrate to the OpenSocial 0.9 spec with Shindig 2.0 we rethought our Shindig development strategy and came up with a different process:

At first we refactored the changes we did heavily to be as separated as possible from the original Shindig codebase.
What we couldn’t strip out, we extracted as diff patches into separated patch files.
This left us with the original codebase, some 20 patch files and some extra php classes and JavaScript packages.
Now this allowed us to just commit the patches and extra files into our own subversion repository. Then we added a small build script which will export the rest of the folders and files we need from the Apache Shindig Subversion server. This means that these files are not under version control anymore and subversion does not want to commit them to the Apache Shindig Subversion (for which we have no write access) if some files have changed. For this files and folders there is a svn:ignore property set in our subversion, so that these files are not committed accidentally.
After the export the build script applies all patches and we have a working shindig server in our file system.


#!/bin/bash
apache_svn_base="https://svn.apache.org/repos/asf/"
shindig_svn_base="shindig/trunk"

paths[0]="config/OSML_library.xml"
paths[1]="config/container.js"
paths[2]="config/oauth.json"
paths[3]="content"
paths[4]="extras/src/main/javascript/features-extras"
paths[5]="features"
paths[6]="php/config/container.php"
paths[7]="php/docs"
paths[8]="php/external"
paths[9]="php/src"
paths[10]="php/test"
paths[11]="php/.htaccess"
paths[12]="php/index.php"

revision[0]="965715"
revision[1]="965715"
revision[2]="965715"
revision[3]="965715"
revision[4]="965715"
revision[5]="965715"
revision[6]="965715"
revision[7]="965715"
revision[8]="965715"
revision[9]="965715"
revision[10]="965715"
revision[11]="965715"
revision[12]="965715"

ELEMENTS=${#paths[@]}

for (( i=0;i<$ELEMENTS;i++)); do
# remove local files
rm -rf ${paths[${i}]}
# export remote files to local copy
svn export -r ${revision[${i}]} $apache_svn_base$shindig_svn_base/${paths[${i}]} ${paths[${i}]}
done

# apply patches
patches="patches/*.patch"

for f in $patches
do
echo "********** load patch $f"
patch -p0 -N -i $f
done

In this solution it is necessary for us to be able to see what we changed in the original files while developing, so that we can add or modify new patch files. For this we wrote a small diff script which downloads the version of a file from the Apache Shindig SVN and diffs it to its local copy.


#!/bin/bash
apache_svn_base="https://svn.apache.org/repos/asf/"
shindig_svn_base="shindig/trunk"

paths[0]="config/OSML_library.xml"
paths[1]="config/container.js"
paths[2]="config/oauth.json"
paths[3]="content"
paths[4]="extras/src/main/javascript/features-extras"
paths[5]="features"
paths[6]="php/config/container.php"
paths[7]="php/docs"
paths[8]="php/external"
paths[9]="php/src"
paths[10]="php/test"
paths[11]="php/.htaccess"
paths[12]="php/index.php"

revision[0]="965715"
revision[1]="965715"
revision[2]="965715"
revision[3]="965715"
revision[4]="965715"
revision[5]="965715"
revision[6]="965715"
revision[7]="965715"
revision[8]="965715"
revision[9]="965715"
revision[10]="965715"
revision[11]="965715"
revision[12]="965715"

ELEMENTS=${#paths[@]}
line="==================================================================="

for (( i=0;i<$ELEMENTS;i++)); do
find ${paths[${i}]} -type f -exec sh -c '(curl -s $2!svn/bc/$3/$4/$1 | diff -w - $1 | sed -e "1i\\
Index: $1\\
$5")' {} {} $apache_svn_base ${revision[${i}]} $shindig_svn_base $line \;
done

For all folders we traverse through all files, fetch the file from the remote Shindig SVN with CURL, diff the fetched content to the local file, and print out a ready diff patch with leading Index entry and separator line like its generated by the svn diff command.

Ihr wollt den Plauderkasten über XMPP testen? Ihr dürft!

Server
jabber.vz.net (studiVZ+meinVZ) ODER jabber.schuelervz.net
Port: 5222 ODER 5223
(SSL/TLS wird unterstützt, für Legacy-Clients wird Port 5223 mit SSL-Verschlüsselung angeboten)

Login studiVZ oder meinVZ
Jabber-User: john\40doe.de@vz.net – das \40 ersetzt das @ in eurer Mailadresse
Passwort: deinvzpasswort

Login schülerVZ
Jabber-User: john\40doe.de@schuelervz.net – das \40 ersetzt das @ in eurer Mailadresse
Passwort: deinvzpasswort

Folgende Clients machen momentan leider Probleme: PSI, Empathy, Pidgin qutIM

Euer Feedback könnt ihr gern hier im Blog posten. Aber bitte denkt daran: Da steht noch ein Beta drüber. ;-)

Happy Testing!

UPDATE +++ UPDATE +++ UPDATE

Danke für eure zahlreichen Kommentare und Hinweise. Wir haben in den letzten Tagen unsere XMPP Server unter Livebedingungen ausgiebig getestet und euer Feedback zusammengetragen. Hier die für euch spannenden Informationen.

Folgende Dinge wurden schon erledigt und sollten keine Probleme mehr bereiten.
#6 DNS-Einträge (SRV-Records)
Die Einträge haben wir nachgezogen, auch für schülerVZ. Danke für den Hinweis.

#56 Mit meinVZ und schülerVZ gleichzeitig verbinden
Das ist möglich, bitte oben auf die unterschiedlichen Serveradressen achten.

#73 Ports öffnen
Wir haben Port 80 nun auch für XMPP Verbindungen freigegeben.
(Bitte beachten: Da klappt leider die automatische Server-Konfiguration nicht.)

Das wird es bald geben:
#19 Sonderzeichen im Passwort
Das ist ein Bug im xmpp und wird gefixt.

#5 /40 für @ sorgt für Verwirrung
Da überlegen wir uns eine elegantere Lösung.

# “Jid wechsel dich”
Das ist als Bug aufgenommen und in bearbeitung.

Weiterhin sorgt die Erweiterung des Standards für Probleme bei verschiedenen Clients. Wir überlegen uns gerade wie wir das lösen werden und halten euch hier auf dem laufenden!

Übrigens, wir Developer suchen noch Kollegen: jobs.studivz.net :)

Neu, frisch und ab sofort mit Plauderkasten gibt’s studiVZ, meinVZ und schülerVZ als App für alle Android Geräte ab Version 1.5.

Download direkt via Handy beim Market: VZ App für Android

oder via:

Nun auch für die größeres Displays: Download VZ App für Windows Mobile

Endlich ist sie da – die VZ App mit Plauderkasten für Windows Mobile!

Folgende Handys werden mit dieser ersten Version unterstützt:

Acer Neo Touch P400 (320×480)
Acer Neo Touch P400 (240×400)
Acer beTouch E101 (240×400)
Acer beTouch E200 (240×400)
htc HD mini (320×480)
htc Touch 2 (240×320)
htc Touch 3G (240×320)
LG GM750 (240×400)
O2 xda Guide (240×320)

In den nächsten Tagen gibt’s ein Update mit dem dann auch weitere Geräte mit größeren Auflösungen unterstützt werden. Versprochen!

Download VZ App für Windows Mobile

Mit der Bitte um Feedback in unsere Mobile Gruppe (studiVZ) oder Mobile Gruppe (schülerVZ). :)

Ein Liste der Nokia Handys mit s60 findet Ihr hier:

Nokia s60 (1)
Nokia s60 (2)
Nokia s60 (3)

Download der neuen VZ-APP

Werde Teil von Deutschlands größter Fankurve und studiVZ.

Update am 13.05.2011: Die VZ iPad-Applikation steht nicht mehr zur Verfügung. Bitte nutzt die iPhone-Applikation. 

Mit dem iPad Launch in Deutschland bringen wir jetzt auch studiVZ, schülerVZ und meinVZ auf die Wunderflunder aus Cupertino.

Wochen und Monate saß mein Team42 aus dem Engineering daran, eine neue maßgeschneiderte App speziell für das iPad zu entwickeln.

Im neuen Look & Feel wollen wir die außergewöhnliche iPad-Userexperience für unsere 16 Millionen Nutzer auf den Punkt bringen: Klar. Verständlich. Interaktiv.

So erscheint unter anderem der Buschfunk im neuem interaktiven Zeitungsstil.

Mehr seht, spürt und fühlt Ihr, wenn Ihr es selbst ausprobiert! ;)

Und Feedback gerne an uns!

]]> http://developer.vz.net/2010/06/11/kostenlos-studivz-schulervz-und-meinvz-fur-das-ipad/feed/ 28 http://developer.vz.net/2010/05/14/iphoto-plugin-fur-studivz-schulervz-und-meinvz/ http://developer.vz.net/2010/05/14/iphoto-plugin-fur-studivz-schulervz-und-meinvz/#comments Fri, 14 May 2010 10:30:32 +0000 admin http://developer.studivz.net/2010/05/14/iphoto-plugin-fur-studivz-schulervz-und-meinvz/ Continue reading →]]> Wir haben noch einmal dran gebastelt und ein neues Update zum iPhoto Plugin veröffentlicht.

Nutzer, welche die Vorgängerversion bereits installiert haben, erhalten automatisch ein Update. Alle anderen können sich das aktuelle Plugin für iPhoto hier holen:

Download iPhoto Plugin für studiVZ schülerVZ und meinVZ

- Embedding auf Pinnwänden, in Gruppen und im Nachrichtendienst für externe Seiten
- Embedding Dialoge für Fotos, Videos, Apps, Pinnwandbilder, Gruppen und Profile
- Meldefunktion für einzelne Pinnwand-Posts und Foren-Posts
- Vorschau-Funktion für Pinnwand-Posts und Foren-Posts

Apps:
- Vergrößerung des Integration Views auf 800px Breite
- Überarbeitung Visitenkartenverwaltung

We are happy to announce that VZ-Netzwerke will sponsor this conference. Additionally we will be present with a booth on the small conference fair where you will be able to meet up with some of our developers, product and partner managers. Be prepared to get your adrenalin up and running at our VZ-Racing-Competition.

On the conference itself we are holding a session on Social Apps at VZ-Netzwerke:

Day: May 12, Track 3
Time: 11.45am – 12.15pm

Session topic: Openess
Topic of talk: Social apps done right

Speaker:
Bastian Hofmann (Software Developer, VZnet Netzwerke Ltd.)
Kristian Raabe (Manager Strategic Partnerships, VZnet Netzwerke Ltd.)

Abstract:
One year ago we were faced with the task of providing an app platform for the 16 million users of our three Social networks studiVZ, meinVZ and schülerVZ. Our aim: to create the best social app platform out there based on OpenSocial. Today, five month after launch, we want to share the story of how we accomplished these aims. We will show how apps are performing on our platform, as well as introduce our plans for further improvements of the developer and user app-experience which are being developed right now.

If you would like to attend, there are still tickets available.

Auf unseren Plattformen verwenden wir an mehreren Stellen Eingabefelder, bei denen ihre zugehörige Beschriftung im Eingabefeld selbst angezeigt wird. Dies ist platzsparend und dem Nutzer können zusätzliche Informationen gegeben werden.

Die technische Umsetzung, die Beschriftung in den Wert des @value-Attribut des input-Elements bzw. den Inhalt des textarea-Elements zu setzen und per JavaScript aus- und einzublenden, ist jedoch problematisch:

• Beschriftung und wirkliche Nutzereingabe im Feld müssen unterschieden werden; der Textstil (Farbe) muss mit JavaScript geändert werden. Sollen auch vorbelegte Felder verwendet werden, muss die Unterscheidung auch im Markup (HTML) erfolgen.
• Wenn das JavaScript zu spät ausgeführt wird, gibt der Nutzer schon etwas ins Feld ein, bevor dessen Beschriftung gelöscht wurde. Dadurch wird der Beschriftungstext unerwünscht zu einem Teil der Eingabe.

Lösung mit label

Markup: Besser realisiert man die Beschriftung mit dem dafür vorgesehenen HTML-Element label. Dieses wird zusammen mit dem Eingabefeld in einem Containerelement der Klasse “labelinside” gekapselt. Auch vorbelegte Felder sind möglich:

<p>
  <span class="labelinside">
    <label for="foo">Label inside</label>
    <input id="foo"/>
  </span>
  <span class="labelinside">
    <label for="baz">Label inside</label>
    <input id="baz" value="vorbelegt"/>
  </span>
</p>
<div class="labelinside">
  <label for="bar">Label inside</label>
  <textarea id="bar"></textarea>
</div>
<div class="labelinside">
  <label for="quz">Label inside</label>
  <textarea id="quz">vorbelegt</textarea>
</div>

Stylesheet: Damit die Beschriftung im Eingabefeld erscheint, wird das label-Element per absoluter Positionierung aus dem Fluss genommen und im Containerelement oben links positioniert. Dazu muss das Containerelement selbst auch positioniert sein:

.labelinside
{
  margin: 3px 0;
  position: relative;
}

.labelinside label
{
  color: silver;
  cursor: text;
  display: none;
  font-size: 0.8em;
  left: 0;
  line-height: 0.8em;
  padding: 6px 3px;
  position: absolute;
  top: 0;
}

.labelinside input,
.labelinside textarea
{
  margin: 0;
}

JavaScript: Wir verwenden auf unseren Plattformen das jQuery-Framework. Damit lassen sich recht einfach alle input- und textarea-Elemente selektieren, die Kindelemente eines Containerelements der Klasse “labelinside” sind. Beim Seitenaufruf sollen die Beschriftungen aller dieser Eingabefelder eingeblendet werden, die nicht vorausgefüllt sind; die anderen bleiben ausgeblendet. Beim Fokussieren eines Eingabefeldes wird dessen Beschriftung ausgeblendet; beim Verlassen wird dessen Beschriftung eingeblendet, wenn kein Eingabewert im Feld steht.

Außerdem wird die display-Eigenschaft von inzeiligen Containerelementen auf “inline-block” geändert, damit die Beschriftung auch bei diesen passt; dies jedoch nicht für Internet Explorer < 8 (Abfrage per conditional compilation und document.documentMode).

var $inputControl = $(".labelinside>input, .labelinside>textarea");

$inputControl.each(function (index, domElement)
{
  /*@cc_on if (document.documentMode && document.documentMode >= 8) @*/
  if ($(this).parent().css("display") == "inline")
    $(this).parent().css("display", "inline-block");

  if (!$(this).val())
    $(this).parent().children("label").show();
});

$inputControl.bind("focus", function(event)
{
  $(this).parent().children("label").hide();
});

$inputControl.bind("blur", function(event)
{
  if (!$(this).val())
    $(this).parent().children("label").show();
});

Und so sieht’s aus: Beipiel 1

Automatisch fokussiertes Eingabefeld

Besondere Beachtung erfordert das beim Seitenaufruf automatisch fokussierte Eingabefeld (HTML5: @autofocus), denn für dieses ist das initiale Ausblenden der Beschriftung nicht ratsam, wenn der Nutzer dadurch keine Information bekommt, was er in dieses Feld eintragen sollte. Auf unseren Plattformen betrifft dies bspw. das Login-Feld.

Hier wird die Beschriftung anfangs eingeblendet. Im Internet Explorer ist dabei eine kurze Verzögerung notwendig (per conditional compilation eingebunden, damit die Ausführung in anderen Browsern nicht verzögert wird). Die Beschriftung wird ausgeblendet, sobald Text eingegeben wird oder wenn mit der Maus in das Eingabefeld geklickt wird.

var $autofocus = $inputControl.filter("[autofocus]");  // oder Selektion per ID

$autofocus.focus();  // setzt den Fokus auch in Browsern, die @autofocus noch nicht interpretieren

if (!$autofocus.val())
  /*@cc_on setTimeout(function () { @*/
  $autofocus.parent().children("label").show();
  /*@cc_on }, 0); @*/

$autofocus.bind("click", function(event)
{
  $(this).parent().children("label").hide();
});

$autofocus.bind("keyup", function(event)
{
  $(this).parent().children("label").hide();
});

Und so sieht’s aus: Beipiel 2

Vorteile dieser Lösung

Bei dieser Lösung genügen wenige Codezeilen für alle Eingabefelder auf einer Webseite. Für neu hinzukommende Eingabefelder ist kein zusätzliches JavaScript erforderlich.

Präsentationsschicht (CSS) und Verhaltensschicht (JavaScript) sind sauber voneinander getrennt. Beschriftung und Nutzereingaben sind sauber voneinander getrennt; eine ungewollte Übernahme des Beschriftungstextes als Eingabe kann nicht erfolgen. Zur Unterscheidung von Beschriftung und Nutzereingaben in den Feldern sind keine Flags oder gar Stringvergleiche des value mit dem (für jedes Eingabefeld anderen) Beschriftungstext erforderlich. Der Stil für den Beschriftungstext steht im Stylesheet; mit JavaScript muss lediglich die Sichtbarkeit geändert werden, nicht jedoch die Textfarbe o.a. Dadurch ist die Lösung nicht nur einfach, sondern auch schnell.

Therefore, we will change the OpenSocial User ID Prefixes as follows:

• www.studivz.net:abcdefg → www.vz.net:abcdefg
• www.meinvz.net:abcdefg → www.vz.net:abcdefg
• www.schuelervz.net:abcdefg → www.schuelervz.net:abcdefg
• sandbox.developer.studivz.net:abcdefg → sandbox.developer.studivz.net:abcdefg

The ID suffix will not change!

We won’t change the hostnames of the different endpoints, but if you have an www.vz.net id it won’t matter if you request the meinVZ or studiVZ endpoint. This means, that the following endpoints are
available:

• http://meinvz.gadgets.apivz.net/social/rest or http://studivz.gadgets.apivz.net/social/rest
• http://schuelervz.gadgets.apivz.net/social/rest
• http://sandbox.gadgets.apivz.net/social/rest
• http://meinvz.gadgets.apivz.net/social/rpc or http://studivz.gadgets.apivz.net/social/rpc
• http://schuelervz.gadgets.apivz.net/social/rpc
• http://sandbox.gadgets.apivz.net/social/rpc

Our migration plan has two steps:

April, 13th – May, 18th:
While we still send the old OpenSocial Ids in our requests to your backend an in our API responses, our REST and RPC API will accept both old and new Ids as request parameters. In this timeframe you have to change your backend, to replace the old prefix with the new prefix in all our requests and responses (see example code below) and only store the new ids in your database.

May, 18th:
We will start sending out the new ids in our requests to your backend in in our API responses. Your backend should be ready for this after phase one, because while the replace logic is still applied to every request and response, it won’t find any matches. You can now remove this replace logic from your backend if you want.

Example source code for replacement logic:

When your backend receives request from the gadget (makeRequest):

$viewerId = str_replace('www.studivz.net', 'www.vz.net', $_GET['opensocial_viewer_id']);
$viewerId = str_replace('www.meinvz.net', 'www.vz.net', $_GET['opensocial_viewer_id']);
$ownerId = str_replace('www.studivz.net', 'www.vz.net', $_GET['opensocial_owner_id']);
$ownerId = str_replace('www.meinvz.net', 'www.vz.net', $_GET['opensocial_owner_id']);

When your backend receives a response from our REST or RPC API (example for receiving a list of users):

foreach ($decodedResponse['entry'] as $id => $user) {
$decodedResponse['entry'][$id]['id'] = str_replace('www.studivz.net', 'www.vz.net', $decodedResponse['entry'][$id]['id'])
$decodedResponse['entry'][$id]['id'] = str_replace('www.meinvz.net', 'www.vz.net', $decodedResponse['entry'][$id]['id'])
}

If you are a developer and have an app live, that has its own backend, you will be contacted in the next days by our support team in order to coordinate your personal migration process.