Welcome to Open@Adobe!

This month marks the fourth anniversary of the Open@Adobe initiative,  a site presenting a view of  the openness efforts at Adobe. We'd like to take this opportunity to reflect on how Adobe has taken an active and leading role in helping to enhance, expand and make the Web open over the past few years.

Active Participation

Being active is an important part of driving innovation. These innovative new concepts continue to power the Web, making it a rich and exciting experience for all. Be it desktop or device, Adobe has continued to increase its active participation in standards and in open source. Our involvement has naturally been widespread, and over the last 10 years has grown into various areas, actively adding new concepts to standards. Over the past few years, we have built a large roster comprised of active members, chairs/co-chairs and authors of numerous W3C standards like CSS, WCAG and ARIA. In addition, we co-fund the current HTML 5 editor along with Google and Microsoft and contribute to the W3C's Test the Web Forward activity to help deliver a robust and interoperable Web. We are also an editor for Canvas 2D, work with SVG and co-chair the TPE specification. We are constantly releasing new technologies under open source terms to allow others to continue to drive new innovations.

Standards Bodies

Adobe also plays a major role contributing to an open and expressive web by participating in various standards bodies such as IETF, ECMA, ISO. While Adobe has always taken an active part in driving standards development forward, over the last few years we have taken  those efforts to a new level in Web standards as well as related standards. Several of these are long time Adobe specifications, such as XMP and  PDF.  PDF, otherwise known as ISO 32000, is one of the most popular and widely used, a key component of HTML 5 and is a recognized  international standard. Other examples of Adobe contributing to opening technology through standardization include involvement in ICC, Unicode, OpenType and JPEG.

Open Source Technologies

Open source as a development philosophy is recognized to both increase innovation and drive adoption. Adobe recognized this early, starting with the contribution of Tamarin to the Mozilla Foundation. We have released more than 150 pieces of technology under open source licenses. On GitHub alone, there are currently 177 public repositories, more than 10 GB of code and represent 13 organizations within Adobe. Open source projects such as Brackets, Source Code, Topcoat and snap.SVG are all top-rated projects on GitHub and actively extend the capabilities of the open Web. Our teams also continue to contribute to open source browser applications, such Gecko, Blink and WebKit. The Adobe Web platform repository is a great resource that highlights a number of significant open source contributions  for such capabilities as CSS shapes and regions. Adobe has been equally active and ambitious in our release and support of open source technologies and communities. We are extremely active in the Apache foundation including the Apache Web server, as well as active involvement and heavy contribution to Apache Felix, Apache Oak, Apache Aries, Apache Jackrabbit, Apache Sling and Apache Stanbol. Additionally, such projects exist within Apache that originated with the larger Adobe, such as Apache Flex and Apache Cordova.  At Adobe,  the Web is not only about the technology and code but also about the content and its delivery. The benefits of an "open" Web that it allows content providers to choose what and how they wish to delivery content, and we hope to move this needle even further in the years to come.
link

Recently, Adobe released Theseus 0.4, a JavaScript debugger extension for Brackets. The above link will lead you to its home in Adobe Research organization on GitHub, which is home to a number of seriously cool projects.  Theseus is released under the MIT license.

I sat down with Adobe intern Tom Lieber, the developer for Theseus. Tom is an MIT grad student and intern working with Adobe Research on problems relating to the development and understanding tools for software engineering, end-user programming and user interface design.

--

So, what is Theseus?

Theseus is a debugger for JavaScript that tries to make debugging as easily accessible as possible. It's part of a collaboration between the User Interface Design Group at MIT CSAIL and Adobe Research.  

The goal of Theseus is to let you see what your program is doing by looking at the code, without having to make as many guesses by simulating the code in your head.

--

How does someone get started with Theseus?

First, grab the latest version of Brackets. Then, in Brackets, click the menu item File, choose Extension Manager. Pick the Available tab, type Theseus in the search box and click the install button in the search results for Theseus. There are also a couple of great videos demonstrating Theseus on the Brackets blog.

And starting with version 0.4, you can use Theseus to debug Brackets itself, as well as any extensions Brackets has loaded, in just two steps:

1. Open the source code for Brackets or the source code for your extension, in Brackets.
2. Click the menu item Debug > Debug Brackets with Theseus.

There are additional places to learn more about Theseus:

_Theseus v0.4 Announcement_

Theseus intro video

Extended Theseus video demo

Brackets Blog introduction

The Theseus README

Theseus paper from CHI'13

--

How does Adobe use this?

Well, one of the goals of this release was to get the code robust enough for debugging the Brackets editor itself. Since Brackets is written in HTML and in JavaScript, there is a natural synergy in having  Theseus support a significant piece of code. In fact, we've already seen bug reports that use the debugger to debug the debugger.

--

Why did you do this?

Part of it is a personal desire. It's always fascinated me how we can interact with the application by poking at, trying things out. However the code itself is rather stagnant and somewhat arcane. My goal was to make it as easy as possible to work with the code. In fact, I want people to be able to play with the code as if it was the live application. This is part of my goal to create more usable programming environments.

--

How would you like others to get involved?

The best way to get involved is to use Theseus on your own projects and give me feedback. I'm looking for when/where it is useful as well as when/where it isn't useful. The feedback will help me expand my academic research and make Theseus better for everyone.

Contributions to the code are quite welcome. It is a research project and thus, research code, but it's fairly robust. I'm more than willing to support anyone who'd like to extend the code, or use it for their own purposes.

It would be great to see Theseus expand to project level discovery and project scope exposure. It would be useful to see events, or be able to ask questions like "What modules were involved in initialization?" It would be great to have visualization of data and elements so when things go out of range you understand the cause and impact.

Theseus was created for JavaScript, but the code is written in small modules, and separates the language specific items out so it would be possible to create debuggers for other languages. 

--

Anything to add?

Well again, this is a research project and I would particularly enjoy hearing back from anyone who's using it. We need to get a clearer view of how people want to use it and what people are doing with it to make sure Theseus expands and matures to make it an even better tool for asynchronous language debugging. I can be reached at tom@alltom.com, so feel free to drop me a note to let me know how you are using Theseus. (Tom is also on Twitter and on Github.

Thanks for your time Tom and good luck with your continuing studies at MIT. We are quite taken with the capabilities of Theseus and look forward to seeing how it grows in future releases.

--

For more information on open source projects at Adobe, please visit our github portal and the Open@Adobe information page with links to even more open source from Adobe.

Please follow OpenAtAdobe on Twitter
link

Recently, Adobe released GCview, a web application that was developed to visualize and monitor memory usage in the V8 JavaScript engine, as an open source technology. The above link will lead you to its home in the Adobe Research organization on Github, which is also home to a number of seriously cool projects. GCview is released under the Apache Software License.

Recently, I sat down with engineering director John Pampuch and engineering manager David Cox. The major developer, Tony Printezis, was unfortunately unavailable.

--

So, what is GCview?

John: GCview  is a tool for people to look at virtual machines like V8 to analyze internal heap operations.

David:  It's a framework to monitor and visually percent any memory management technology like garbage collection.

In discussion, it seems that GCview is a generic and easily adaptable visualization and monitoring framework targeted (but not limited) to memory management systems (garbage collectors, malloc/free implementations, hardware caches, etc.).  A  system can be visualized by mapping its operation, data structures, heap layout, and other attributes onto GCView abstractions.

David: Its roots come from a similar tool known as GCspy, of which Tony was the original author. GCview is a  new design and a completely separate code base.

--

What is GCview  used for?

David: It's for VM developers to get a deep dive into the activities of garbage collection. It allows knowledgeable developers to also help understand performance aspects of web applications.

John:  It's important to note that this tool does require some level of expertise to make the best use and looking at memory management systems. It helps identify the underlying causes, but the memory management system itself is responsible for offering the tweakable parameters to improve the identified problems.

In some ways, GCview  seems (to me) similar to the Check Engine light on my car. When it appears, I understand I have a problem but may not know what the problem is. A monitoring tool allows me to see the diagnostic code that caused the problem, but doesn't necessarily allow me to directly correct it. That may take expertise and tools that I may not have available.  GCView shows me more than just simple diagnostic code, but fixing the problem still requires expertise and tools.

--

Why did Adobe build GCview?

John:  We believe there is a need for deeper understanding of how memory management systems work in browsers today. We also think that there is room for significant improvement in web VMs.

David:  It's in everyone's best interest to see the performance of web applications improve. Building GCview, particularly in tying to open source will allow this to innovate and grow for improvement of the web.

--

So, what's inside GCview?

David: *The GCview core consists of three parts which can be hosted in the same place and be easily adopted in the required system:*

A) Data Stream Spec - A JSON specification that defines the format of a data stream representing the state of the system being monitored over time as mapped onto GCview abstractions. The data stream can either be written to a file for future analysis or transmitted over the network for online monitoring.

B) Visualizer - A visualizer, written in HTML and JavaScript, that interprets and displays the above data stream.

C) Data Tracking Code - C++ code that keeps track of the data needed to monitor a particular system after it has been mapped onto GCview abstractions along with facilities to export this data in the  appropriate format.

--

How do I get started?

David: Well, the easiest way is to grab the source and point your browser at the index.html file. That will  start GCview where you can load one of the sample traces in the source as well and begin to play and understand what GCview  is showing you.

--

What's next for the project?

John:  We hope the open source community will help improve and expand the GCview features and capabilities. Some obvious directions would be inclusion into the Chrome dev tools. Perhaps a great next step would be to see this picked up and baked into Chrome together data on V8. The area covered by GCview today is just the beginning and we can't wait to see what innovations other developers can bring to it.

--

Any final comments?

John:  Releasing GCview under open source makes this tool and framework available for all sorts of interesting memory management systems.

David:  We can't wait to see what this develops into and where the community will take it.

Thanks for your time today guys. We appreciate the effort behind GCview and, honestly, the coolness factor that GCview offers to the web application community.

For more information on open source projects at Adobe, please visit our github portal and the Open@Adobe information page with links to even more open source from Adobe.
link