Archive for July, 2008

CouchCast Interview with Ted Haeger

Bungee Labs’ community guy and director of Bungee Connect Developer Network, Ted Haeger, was recently a guest on CouchCast, a weekly tech and business Internet talk-radio show hosted by Robert Merrill, Thom Allen and Matt Reinbold.

If you’d like to check out the interview, here’s the direct link.

Leave a Comment

Bungee Connect named as one of the Top 10 companies to track for 2008/2009

Robin Bloor, partner at Hurwitz & Associates, and founder of Bloor Research just published a list of 10 companies to track in 2008/2009. He named Bungee Labs as number 3, right behind Twitter.

“If your looking for new start-ups that might be successful, then keep your eyes on “the cloud”. Bungee almost counts as a case study in cloud computing plays, because it takes a complete charge by usage approach to garnering revenue from its development software.”

You can read the full write-up here.

-Brad

Leave a Comment

The Learn Tab Lives!

Late Friday night, the Bungee team rolled out two changes to the Bungee Connect platform.

The first change is the much needed renaming of Adapters and Connections. Wherever the word adapter once appeared, you now find the word interface. (Except for in the Bungee Connect architectural pattern, which remains Model-View-Adapter.) Similarly, connection has been renamed to adapter. (Hence the reason why MVA did not become MVI.) Overall, this change better aligns these components to concepts familiar to most object-oriented programmers. Read the rest of this entry »

Comments (1)

@task, with Nate Bowler

The Bungee LineOverview
Nate Bowler, CTO of @task, becomes our first in-studio guest on the Bungee Line. @task provides project management, Gantt chart, workflow, and time tracking software through both traditional host-your-own and Software-as-a-Service models. As with so many companies in the providing web-based software, they provide an API.
36:25, 16.7 MB

Related Links
Here are links to some of the resources mentioned in this episode. Read the rest of this entry »

Comments (1)

Death by Refresh – Why interactivity matters

Picture 12.png

This morning I was running some reports and adding information about customers in our hosted CRM and had to click through no less than 5 page refreshes just to change a single field in each customer account. Is it just me or do we waste too much of our lives waiting for a new page to load in the browser? That’s not an isolated example. It takes just as many page refreshes to do similar tasks throughout the CRM. Take the calendar for instance, to change the start time of a meeting in your calendar it takes 6 page refreshes. Allow me to detail the insanity:

Picture 36.png

  1. open your calendar
  2. go to the day view and click on the appointment you want to change
  3. view the full appointment, click the edit button
  4. change the field and click save
  5. see the appointment again
  6. back to the day view

I’m not just picking on our CRM, the problem exists all over the Internet.

For me, Google Maps first showed me what the browser could do with rich interactivity. You know what I’m talking about—no more clicking and refreshing, just drag and drop to move the map. This interactivity is much more intuitive and makes online maps much more useful for me. I was already used to this type of interactivity inside of desktop applications, but not on the web.

Even though interactivity like Google Maps is far more intuitive and user friendly, it is still largely absent from the sites we use every day. When you consider the effort involved in adding interactivity, it is no wonder implementations have been limited and require large development projects. There are two main obstacles that I see keeping people from adding more pervasive interactivity:

  • Complexity and cost
  • Security

On the complexity side of the issue, there are many moving pieces in adding rich interactivity. Generally, the most time consuming and complex issue is ensuring cross-browser compatibility. Every browser has it’s own idiosyncrasies in running JavaScript; pages that behave one way in Internet Explorer are very different in Firefox. On top of that, the synchronization between the client and server and the connectivity to multiple data sources adds a whole new layer of complexity. This complexity adds to the development time and the size of the development team, also known as cost.

On the security front, traditional approaches push a lot of the application execution and data connectivity to the client. This approach exposes too much business logic and data on the client and opens the opportunity for malicious individuals to exploit these holes.

At Bungee Connect, we have been working to make rich interactivity a reality by removing the complexity involved in developing a web application. Bungee Connect removes the need to learn multiple technologies and languages to develop web applications. With Bungee Connect, there is no need to write any Javascript or worry about cross-browser compatibility. Also, the Bungee Connect architecture leaves the application logic on the sever, minimizing the attack surface of an application. Data is also kept secure by leaving the connection to the data source at the server and pushing only the data being displayed down to the client.

Just like my experience with Google Maps, when I first saw Bungee Connect in action I could see new user experiences would be possible on the web once you move beyond the page refresh model. You can read more about the Bungee Connnect approach here.

What do you think–is the move to a richer web experience long overdue?

-Brad

Comments (1)

Default SQLConnection Type Initialization – Required Action!

This post is to notify of a potential breaking change in our next release. This notification is for developers who have built applications that connect to a MySQL database and have initialized their connections using the SQLConnection type without explicitly choosing MySQL as the subclassed connection type. This issue will only affect a small number of Bungee Developers. This change will roll out in our next preview release on or around July 22nd and will be in the preview build for the standard two weeks.  We’re choosing to announce the change as early as possible so that affected applications can be modified if needed.

Why the change?

In a recent release we updated our SQLConnection type to support connections to PostgreSQL databases. In the future we plan to enable connectivity to even more SQL databases. As a result, we’ve designed the SQLConnection type as a superclass for the specific database connection type that you’ll be using, whether it be MySQL or PostgreSQL or some other database in the future. By keeping the SQLConnection as a superclass you can connect to multiple data sources as well as dynamically swap the supporting database in your application.

What’s different?

Here’s the scenario where you run into this issue. If you have created a field of type SQLConnection – either explicitly or as a VAR – and have either allowed it to be nullable and not initialized it; or initialized it as SQLConnection; then by default the system would connect to a MySQL database without any issue. This is actually incorrect behavior and caused a bit of a loophole that developers have potentially been using for the past couple months. The breaking change is that a simple SQLConnection type can no longer connect to a MySQL database by default – it must be explicitly initialized as a MySQL connection type.

What do I need to do?

What you’ll need to do is go through you database connection code and look for any types that are initialized as SQLConnection that haven’t been specifically initialized as MySQL. In the builder you would see the following:

Note in the green area that the MyDBConnection field is set to be of type SQLConnection, and is nullable. However notice in the red box that the default value has not been set. See the following screenshot for the correct settings:

The Default Value has now been set to Object and the type is a new MySQL.

Another scenario where you could have an un-initialized SQLConnection is in a variable definition inline in the code. See the following screenshot:

See how I have created a new var named DBConnection2 and it’s of type SQLConnection but in the red box, I haven’t defined the default value. See the following screenshot for the correct setting:

Again; the Default Value has now been set to Object and the type is a new MySQL.

To re-iterate, the changes above are for those users that have been using the SQL connection up till now and have been connecting to a MySQL database without initializing the connection type specifically as MySQL. I would anticipate that there are only a small number of you that are affected. If you use a MySQL database, take a look at your code and double check.

How should I do this in the future?

So, going forward what should you do as a best practice for creating database connections in Bungee? Well, as I mentioned before, the reason we have the base SQLConnection type is to enable dynamic and easy swapping of the underlying database for your application. In all reality, this is most likely a very un-common scenario. The most efficient way to create the connection is to create your connection objects or vars directly as type MySQL or Postgres rather than SQLConnection.

 

Hopefully this is helpful for those of you currently connecting to a MySQL database. If you have any questions please post a comment directly to me on this post, or post on our forums.

Comments (1)

Early July BCDN Preview Now Open

We’re putting out a special preview release this holiday weekend. This release is not about new features, but about making a long-overdue name change in Bungee Connect.

Adapter == Interface, Connection == Adapter
As we continue on the path to defining the Bungee Connect language specification, we realized that we needed to adjust some terms to align better with standard nomenclature that object-oriented programmers expect.

For some time, two components in Bungee Connect have been referred to as “Adapters” and “Connections.” In Bungee Connect, the component named Adapter works in much the same way as interfaces in many other object-oriented languages. So to make it easier for new developers to learn the system, adapters will now be known as interfaces … there … much better.

Well, almost … there’s this other thing that we have been calling a connection that actually maps closely to a familiar OO pattern named … wait for it … the adapter pattern. So, connections really should be called adapters!

We won’t go into the whole history for why the names weren’t this way from the start. Suffice to say that the previous justifications aren’t as relevant, and the time has come to set the names right.

So, in summary, the change you will see in the preview now, and in the release on July 16 – and forever more in Bungee Connect is this: Wherever in Bungee Connect you once saw the name adapter, you will now see interface. And wherever you once saw connection, you will now see adapter.

Incoming Learn Tab Content
In the 24 to 48 hours following the rollout of the preview release, you will find that we have replaced the Start tab with the new Learn tab. Over the next two weeks, you will see active additions to the core curriculum portion of the Learn tab, building out Units 1 & 2. We aim to have Unit 3 in place by the end of July, and then to begin delivering many short “extended learning” modules about various features from August onward.

We would very much like feedback from BCDN Developers about both the content and the functionality of the Learn tab.

Logistical Details

Developers in the Bungee Connect Developer Network can now test out the next release of Bungee Connect by using the following URL:

We provide the preview release so that BCDN developers can test out the new features in the release, especially those that were directly requested by our top developers. This also gives you a chance to ensure that your code works as expected on the new version. Barring discovery of a major issue, we will end the preview and roll out the new version two weeks after opening the preview.

Also, make sure that you read Deploying on the Preview Release.

It’s Not Production (Yet)
You will find a snapshot of your current solutions available on the BCDN Preview release of Bungee Connect. It is only a snapshot taken on July 2, just before the opening of the BCDN Preview.

Reminder: Because the version of your code on the BCDN Preview is separate from your production code, any changes that you make to your code on the preview will not be reflected back on the current production version of Bungee Connect. This includes when the update goes live to production. In short, don’t expect to keep code changes that you make on the BCDN Preview system. (We are investigating how we might be able to save changes made on the Preview.)

Reporting Issues
If you find an issue with your code in the BCDN preview, please report the issue to us immediately. You can email support at bungeelabs.com, contact us in the BCDN Forums, or through IRC.

Leave a Comment

Older Posts »