zembly blog

I love hearing back from users, good or bad, because it just helps us get better, and that’s why we’re here. One question has come up several times recently: Are there docs, tutorials, or samples for zembly?

The answer is yes, there are docs!

Admittedly, we didn’t do much to make the docs easy to find, because we thought we’d be moving to our wiki very quickly. That hasn’t happened yet, so instead, tucked away in the right column of our blog (right over there //—>) is a link, called docs, where you can find lots of information, including:

• An in-depth description of the basics
• A getting started guide, including a couple of simple tutorials on building services and widgets
• An extensive tutorial for building a Facebook application with zembly

We’ve also added a link to the docs in the header of zembly.com, right next to the link for samples:

Many of you may not realize, but samples at zembly are not just interesting to look at, but you can clone and then tweak them to do whatever you want. Think of them as templates–find a cool app as a starting point, and then extend it and make it your own.

We’d love to hear more ideas about docs and other information that would make getting started at zembly easier, so please drop us a line over at Get Satisfaction, on the forums, or in the comments here.

Jesper Anderson has written a very nice piece about zembly on O’Reilly Radar.

A short excerpt from Jesper’s post:

I was able to demo zembly, which attempts to lower the barrier of entry to writing applications for social platforms such as Facebook, Meebo, OpenSocial and the iPhone by sharing services and widgets - and came away impressed with its focus on ease-of-use and belief in a new development process. zembly is working to create a social setting for developers to share components between applications - a “wiki for live, editable code that is more than just about trivial widgets, but rather about full-fledged social applications that can tap into the social graph and reach millions of users”.

…

zembly hopes that network effects will kick in, as the service will be most successful if users trust others on the system, and share components freely - something that has been hard to accomplish even in large corporate development teams. If successful, it will be this feature that distinguishes zembly from Google App Engine and other competitors.

He goes on to mention some great points, which I hope to have some time to discuss further in an upcoming post. Until then, please be sure to check out our docs for detailed info on building social applications.

A quick update to let you know that three of us–Ryan, Jirka, and me (Todd)–are at the Graphing Social Patterns (GSP) East conference this week.

We’ve already had some interesting conversations with potential partners while we set up the booth today, and we’re looking forward to talking to a crowd of 500 developers, bloggers, partners, and others.

From talking to the other people in the space, it’s clear that zembly is doing something unique when it comes to creating and delivering social applications to the masses. The ability to not just create non-trivial social applications easily, but to easily create them together with others in a collaborative way–thus raising the level of abstraction and capability available to social application developers–is something that we think is revolutionary. We’d like to hear your thoughts on the topic, so let us know in the comments.

We’ll have more to say as we talk to people this week. Stay tuned for updates!

We are extraordinarily proud to announce the beta release of zembly at http://zembly.com!

zembly lets you collaboratively create and host social applications of all shapes and sizes, including Facebook apps, meebo apps, OpenSocial apps, iPhone apps, Google Gadgets, embeddable widgets, and other social applications, using just your browser and your creativity.

We are still in private beta, and will be adding a lot more beta users over the coming days and weeks. We’re releasing a significant block of invitations today, so hurry over to the home page and click the big, shiny, yellow button!

We’re proud to be working with our partners, dapper and Meebo. Jon Aizen, co-founder and CTO of dapper, had some very cool things to say: “zembly is truly disruptive. It has the potential to fundamentally change the way developers create portable web applications and widgets. Its collaborative approach, emphasis on reuse of common code, and web-based interface dramatically reduce the barrier for developers to implement and realize their creative ideas. We’re excited that our users can now take the feeds they create using Dapper and immediately put them to use in new ways with minimal effort using zembly.”

This is an exciting time for us. We’ll have some more announcements forthcoming soon, so please stay tuned.

In our ongoing endeavor to suck less over time, we’re now Get Satisfaction enabled! Check it out over there on the right, in the sidebar: ———>

Get Satisfaction is a cool and highly popular site for people-powered customer service and support. In short, it makes it easier for you to interact with us, whether you’re looking for answers, submitting RFEs or bugs, telling us how much we suck, or just saying something nice to make our day.

With Get Satisfaction, you can search, vote, and add to topics that others have created, create topics of your own, and keep informed of comments and conversations by us. If all this sounds interesting to you, please check out zembly on Get Satisfaction.

Facebook.com has several sample applications written in PHP that can be used to learn Facebook programming. One of those applications is called Footprints. I’ve created a new application based on Footprints that’s called footfalls. You can click the image below to try it out on Facebook.

The application works the same as Footprints. It’s similar to poking a friend, only you step on them to let them know you’re thinking about them or you’re still around and using Facebook. The next time your friend logs in to Facebook, they’ll be notified that you stepped on them.

Typically, a developer on Facebook.com has to know (or learn) a lot to get this application going: download the PHP code, set up a web server (Apache), install and learn php and MySQL, and create a MySQL database, none of which is documented with the PHP code. Frankly, I wasn’t able to get all of this working.

I was able to emulate Footprints behavior in footfalls fairly quickly. Instead of MySQL, I used the new Facebook Data Store Admin UI to create and edit the database schema. That part took the longest because there wasn’t much information available on this new API. After I got it working, one nice discovery was that it was easy to create and reset the schema programmatically. Adding new columns and attributes to an existing Object definition was easy, and I was able to do it here either by using the Admin UI or the API.

Now that footfalls is available, you can clone the application and customize its services (GetSteps, CreateDataStore, DoStep, FBMLService, SendNotification) for your applications. For instance, you could add a counter to count the number of steps, find out who got the most steps, and send the data with your steps. You can query received steps, sent steps, and more!

I bet you know meebo - the website that lets you chat through the most widely used instant messaging networks from a browser. Perhaps you also know that it’s not just chat, but they also have a bunch of games and applications that launch right in the chat window.

Today, we put in the last bits of the initial support that let you build meebo apps - right here from the browser as you are used to. Just get a meebo account and try it yourself. When you create a new meebo application, and a new widget, it will have some code with callback functions that are automatically registered for you. You will need to peek into the API documentation to learn about functions that you can call.

Now, this is just the initial release of this feature. We want to hear from you what could be improved!

The hints for executing a service versus showing the service page and rendering a widget versus showing widget page are currently based on the extra query parameter that gets passed in the URL. For example:An HTTP request to the following URL actually executes the Hello World service:

http://…/HelloWorld?exec,&name=world&language=en

The following URL shows the service page:

http://…/HelloWorld

The same way for widgets, the following URL renders the widget in an iframe:

http://…/dde7e989aa2a4122aef8a6e53f29e9fb?iframe

The following URL shows the widget page:

http://…/dde7e989aa2a4122aef8a6e53f29e9fb

Unfortunately, using the query parameter for hints about executions and renders doesn’t work very well. For example, your service cannot accept a parameter named exec because it has special meaning in the platform itself, and certain publishing platforms don’t accept URLs with query parameters. We also added platform specific parameters like debug recently, which have the same issues.

To fix these issues, we’ve moved platform specific hints to matrix parameters as opposed to query parameters. Matrix parameters are interpreted by the platform. Services and widgets do not get access to them. This way, platform specific hints don’t bleed into the service and widget space.

Matrix parameters are specified as name-value pairs using the “;” separation character at the end of the URL, before query parameters.

The grammar for the URL is:

<path to resource>[;name=value]*?[&name=value]*

Here’s how you will invoke Hello World service:

http://…/HelloWorld;exec?name=world&language=en

And this is how a widget-render URL request looks now:

http://…/dde7e989aa2a4122aef8a6e53f29e9fb;iframe

http://…/dde7e989aa2a4122aef8a6e53f29e9fb;iframe;debug (with widget debug flag on)

Facebook applications will not be impacted by this change.

IMPORTANT NOTE: This change impacts the code that renders the widget. So, if you have embedded your widget in a blog or elsewhere, you need to change the embed code. Please refer to your widget page for the correct embed code.

If you’ve been debugging widgets with Firebug, chances are you’ve been logging messages with Firebug’s console.log. And after you finished debugging, you were removing all the logging statements, because otherwise the script would just fail for users who don’t have Firebug.

We’re providing some help. You can now start using the Log API in widget code (the same as you used in services). For example:

Log.write("myVar = " + myVar);

This code writes messages to Firebug if it’s installed. If not, we will load Firebug lite to get you started (use F12 to bring it up). Isn’t that cool? Now logging is enabled by default when you preview drafts, and disabled for published versions. You can keep your Log.write() statements in the code, and they will just go to null unless you enable debugging of published versions with the debug query parameter.

We just deployed another change to the site that only requires SSL where sensitive data is being exchanged (login and keychain), so don’t be surprised if you some of the pages are no longer encrypted.