Bungee Connect development video by Bear454

The illustrious Bear454 gave a presentation at LFNW09 on browser-based web development and deployment. With hands-on experience in Bungee Connect and Heroku’s HerokuGarden Bear454 knows first-hand the types of applications you can build and the tools available to build them.

Bear454 took the material he gathered for his presentation and  posted two videos detailing browser-based development in both systems. In less than 20 minutes Bear454 shows you how to build an application on both platforms. Check out both videos and let him know what you think. We already think Bear454 is pretty darn cool.

-Brad

Leave a Comment

End of January Update

Last week we updated the Bungee Connect system with a couple small bug fixes.  Those who were directly impacted by the issues are already aware of the fixes, but it still merits an update to the broader community so that everybody is aware of changes as they roll out.

What got fixed:

Bug# 7889 Redux: We added the ability to specify an authentication type up front. Previously we were always using “probe” mode which would send the request without any authentication, expect the server to reject the request with a 401 and specify the types of authentication it supported.  Now you can specify your authentication type up front, avoiding the extra round-trip to discover the authentication types supported by the server you are hitting.  It also makes it possible to speed up each request by a few hundred milliseconds, since we can now avoid the probing round-trip.

The second bug we fixed is around DWA (Delegated Web Authentication). As part of our DWA package, we supply the getStandardCallbackUrl() method that returns the URL needed to merge a session back into the existing session. An application uses this URL to pass to the authentication service. The authentication service then redirects the user to that URL after the authentication request has completed. The bug with the getStandardCallbackUrl()  method was that it always returned a URL prefixed with “https://webauth.bungeeconnect.com/” which only worked during simulation. We fixed the method to return a URL prefixed with the same prefix as the current session. This solved the problem for applications that needed to use the getStandardCallbackUrl() method in production, which is only an issue for developers of new DWA drivers.

Thanks to all our community of Bungee Connect developers.  As always, if there are questions about this update or about Bungee Connect in general, don’t hesitate to ask them either as a comment on this blog post or ask them in our getsatisfaction.com channel.

David Brooksby
Director, Product Management & Development
http://www.bungeelabs.com
daveb at bungeelabs dot com

Leave a Comment

Updated Basecamp API for Bungee Connect

Bear454 has just released an update to the Basecamp API Library for Bungee Connect. Thanks for the contribution Bear454.

Brad

Comments (2)

November Update and Planned Down-Time

Don't look at me, just read the post!

Happy Holiday season to all!  I hope the winter is treating all of our Bungee Developers well.  Except of course, if you’re sitting in the northeast and are still without power.  In which case, how on earth are you reading this post!?

It’s time to update our users on a recent system update, as well as notify you of some planned down time for an upcoming system change.

November Update:

On November 24th we rolled out a small system update to address a couple of issues.:
4563:  eBay wsdl now imports properly
7893: HTTP is no longer stripping authentication from URLs
7889: HTTP PUTs are now authenticating correctly

Like I said, it was a small update, but the changes were needed.

Planned Down-time – Need to Log Off Dec. 22nd

We’ll be making an infrastructure update that will affect DNS resolution for the Bungee Builder starting at around 10PM PST Wed. December 22nd (that’s 1 AM EST Dec 23rd).  We don’t expect the outage to be for very long, but considering that the change is primarily related to DNS it may be longer than planned—that type of change occasionally has unpredictable results around the world.  As a precaution, we’d like to ask that all Bungee Developers log out of the system before that time so that the update can take place without any risk of a loss of your work.  It’s been several months since we’ve needed to do this kind of update, so we appreciate your patience.  If you have questions about the change or timing, please contact me directly with a comment to this post.

How will the DNS changes affect your applications?

There are a small number of users who will need to make their own infrastructure changes  as a result of this change.  Please pay special attention if you have whitelisted (either on your own firewall or through an ISP) the Bungee Connect Data Center IP address so that your application can connect to your own DB or REST/SOAP/SMTP service.  The IP address you whitelisted will no longer work and you’ll need to whitelist a new address.  The new address to whitelist is 174.129.251.38.
We’ll be updating our documentation accordingly.  Additionally, we’ll be contacting several developers personally to let them know that they need to update their infrastructure in order to continue functioning beyond the 22nd.  If you have questions about updating your whitelist, please contact me directly with a comment to this post, or post a topic in our GetSatisfaction.com portal.

As always we appreciate all the effort, patience, and feedback from our beta developers.

David Brooksby
Director, Product Management/Development
Bungee Labs
daveb at bungeelabs dot com 

Leave a Comment

We’ve moved to MindTouch Deki…Here’s Why.

PictureWe’ve moved the documentation for Bungee Connect from MediaWiki to Deki.

As a web-based development platform provider, mindtouchwe chose to host our documentation. Originally we chose MediaWiki; it being the de facto wiki platform. You might ask, why take the time and effort to move to a different wiki? And why Deki? We were attracted to Deki for its complete, RESTful API. In fact, the Deki PHP application only talks to the Deki API. 

As we investigated Deki further, we found that Deki has some significant improvements over MediaWiki:

  • Better UI
  • WYSIWYG Editing
  • Rights Management
  • Better CSS
  • Programmatic Access
  • I used the How To guide from MindTouch and our migration went smooth and easy.

    Also check out the interview with MindTouch CTO Steve Bjorg about Deki on our web API podcast, the Bungee Line, from June 2008.

    Amy Ballard
    Community Program Manager
    Bungee Labs

    Comments (2)

    To Optimize or Not To Optimize

    corey602Developing an on-demand platform that must deliver speed, scalability and stability requires a lot of thinking about performance. While working on Bungee Connect, I’ve done enough code optimizations, tweaks, hacks, anything really to squeeze more performance to know that I need to pay attention to the details up front. Not to poke the “don’t optimize until it’s done” beehive, but I’ve learned enough to know that there are some things you can learn from experience and you don’t have to wait for the performance guys to laugh at your code.

    Have you ever debugged a crash where a null pointer was being dereferenced and when you tracked down the individual responsible their defense was that checking for null would slow down the system?  Have you ever found someone that wrote their own atoi function because they swore that the standard c runtime’s implementation was bad?

    If you read my previous post you’ll know that I’ve been playing with the V8 JavaScript engine by Google.  I’ve enjoyed learning a new system and gleaning tricks from other programmers that you don’t get from reading a book or taking a class. But something has been gnawing on my mind for the last little while and that is how fast or slow is the bridge between the v8 engine and a c++ application that embeds it.  I wondered whether or not a developer should be worried about the performance of this bridge or if they should forget about performance for now and just start turning the crank on features. So I wrote a little performance test to see how long different areas of the V8 integration into an application take. By the way, the Google engineers that wrote this system are very solid in terms of coding standards, efficiency and readability.

    These benchmarks aren’t the most scientific in nature but they do give me something to start kicking around.  Here’s the JavaScript test that I wrote and embedded into my test:

    var count = 0;

    function timed_dispatch() {
    count += 1;
    }

    start = new Date();

    // Test 1
    for (i = 0; i < 1000000; i++) {
    count += 1;
    }

    // get the time and print the results
    end = new Date();
    print(end - start);

    // reset the counter and the start timer
    count = 0;
    start = new Date();

    // Test 2
    for (i = 0; i < 1000000; i++) {
    timed_dispatch();
    }

    end = new Date();
    print(end - start);

    // Setup for Test 3
    timed_obj = new TimedCPPDispatch();
    start = new Date();

    // Test 3
    for (i = 0; i < 1000000; i++) {
    timed_obj.empty();
    }

    end = new Date();
    print(end - start);");

    The first for loop measures how long it takes V8 to do some simple arithmetic on a variable.  I started with 10,000 iterations but the numbers were too small so I bumped it up to 1,000,000.  The output of the first print statement was 16ms.  Pretty quick.

    The second for loop looks at how long it takes to do a method dispatch that increments the same number.  Adding the overhead of the function call took the time up 4ms for a grande total of 20ms.

    The last for loop uses a C++ class that I created that has a function called empty.  This function literally does nothing except for return.  What I’m looking for is how long the act of dispatching a method from the javascript to the c++ application takes.  It took a total of 1500ms or 1.5 seconds to call 1,000,000 times.

    Obviously, if you can avoid crossing the boundaries between your application and the V8 engine you will be saving some overhead.  Two orders of magnitude difference is nothing to sneeze at.  However, 1.5 us (microseconds) per function call is not bad for an embedded vm.  And, I don’t expect anybody to be doing a million of those. On top of that, once you cross the boundary you’re still running in c++ code, which isn’t too shabby with performance either.  If you have some complicated c++ algorithm that you are calling then a 1.5 us boundary becomes noise and is not an issue.  So, the old adage of not optimizing too soon would appear to still hold a lot of water in this argument and I should hold off on looking to outsmart myself before that’s really necessary.  I should probably be looking to add features to my application rather than trying to figure out a priori where my code might be slowing down.

    If you’re interested in checking out V8’s performance numbers for running straight JavaScript head on over to http://code.google.com/apis/v8/run.html or download the V8 engine and run them on your machine.

    Leave a Comment

    Basecamp API for Bungee Connect from Bear454

    The illustrious BCDN member Bear454 has contributed a Basecamp API for Bungee Connect. Bear454 outlines how you can use this api in your own project and promises to maintain it until a better one is contributed. Go check it out.basecamplogo-small.png

    Brad

    Leave a Comment

    Older Posts »
    Follow

    Get every new post delivered to your Inbox.