Signals Blog by Metamolecular

Foundational Cheminformatics Software and Why Chemistry May Need Something Better

2012-02-02T00:00:00-08:00

Chemistry is peculiar among scientific fields due to its use of the molecule as an organizing principle. This gives chemistry an expressive, mostly regular, often graphical language at the core of the discipline. Although apparently simple on the surface, the concept of the molecule is deep with subtleties that can take years to appreciate. Chemists in different subdisciplines (e.g., analytical, organic, bioorganic) may find it hard to communicate at times because their common molecular language blinds them to critical nuances.

Computers know nothing about this language of molecules that chemists use. To develop even the most rudimentary application in chemistry requires a foundational cheminformatics software layer that enables the easy use of molecular concepts within a programming environment.

Software developers need better foundational tools to create applications that will empower chemists to make new discoveries. This article describes one approach.

Toolkits, Oh We Have Toolkits

Most of the time, foundational cheminformatics software is referred to as a ‘cheminformatics toolkit’. The purpose of this software is to provide something akin to a domain specific language that defines and operates on molecular structure representations. The toolkit makes it possible to develop a chemistry application in a given programming environment. No toolkit, no application.

Cheminformatics toolkits can be divided into roughly two categories: (1) those distributed by commercial organizations; and (2) those distributed by informal academic collaborations and nonprofits.

Lock-In

Some kinds of software are especially ‘sticky’. Once you start using them, it’s difficult to stop because they become so intertwined with the work you do or the products you distribute. There was a time when Microsoft Office was sticky because it was the only way to share documents. If you’ve ever developed a Web or desktop application, then you know how incredibly sticky Web frameworks and UI toolkits can be.

Cheminformatics toolkits are among the stickiest of software packages in chemistry. They alone stand between a programming environment and a lot of application code. So a lot of code gets written to the toolkit’s application programming interface (API). Coupled with the time and effort of development staff to learn a toolkit’s quirks and nuances, it’s not hard to see how an organization’s investment in a cheminformatics toolkit can be enormous.

Lock-in is not necessarily a bad thing. But it can become a problem when the goals of the toolkit provider don’t match your goals.

Commercial Vendor Lock-In

The advantages of using a toolkit provided by a traditional vendor are that the vendor takes care of the maintenance and upkeep of the toolkit. This lets your development staff focus on building applications.

The flip-side of this tight control can be restrictions on how your application works or how it’s distributed. For example, to convert your successful desktop application into a Web application may require a major license renegotiation, new fees, and possibly unsavory restrictions on distribution. Similar considerations would apply to taking an application in a mobile direction, or rebuilding the toolkit to run in a hardware or software environment - or programming language - not supported by the vendor. Likewise, an API that wasn’t sufficiently flexible would require waiting (and hoping) for the vendor to upgrade.

Limitations on redistribution, recompilation, and modification are some of the tradeoffs made by application developers who base their products on traditionally-licensed commercial cheminformatics toolkits.

Open Source

Given that toolkit lock-in is inevitable when developing chemistry software, some have opted to use open source options.

However, unlike traditionally-licensed cheminformatics software, nobody is responsible for responding to bug reports, new feature requests, or lack of documentation. Furthermore, open source licenses vary significantly in the freedoms allowed to application developers. The GPL and LGPL in particular both place restrictions on commercial vendors that may ultimately be bad for business. Compounding the problem is the fact that sometimes copyright to the source code resides, not with a single entity with whom better terms can be negotiated, but with many individual contributors - some of whom may no longer even be traceable.

The problem is that the organizations or individuals behind open source cheminformatics toolkits are poorly equipped to deal with the demands of a commercial organization developing products in a competitive environment.

Why We Chose None Of The Above

At Metamolecular, we’ve developed our own cheminformatics toolkit rather than be subject to vendor or open source lock-in. Our two products, ChemWriter and ChemVector both rely on proprietary cheminformatics toolkits we’ve developed and refined over the last few years.

In addition to these activities, we’ve worked with other companies to build cheminformatics systems and services. Each of these transactions have helped refine our cheminformatics toolkit by overcoming real-world problems.

We’ve also built a number of concept products that have further improved the understanding of what a toolkit needs to do and how it needs to do it.

Maintaining and growing our own cheminformatics toolkit has enabled us to achieve goals that neither an open source nor traditional commercial vendor arrangement would have allowed.

Consolidation

Our products and services have been written in two main languages: Java and JavaScript. These codebases have remained separate due to the fundamentally different nature of each language and its associated runtime environment.

But in the last few months, it’s become apparent that this can’t continue. For example, some ChemWriter customers have requested SMILES input and output. The technical challenges of maintaining separate codebases in Java and JavaScript for such code made the request impossible to fill in a cost-effective way.

Fortunately, we’ve found a solution that will enable us to maintain a single Java-based codebase for all of our toolkit functionality. The key to making this work is a new Java-to-JavaScript source translation library that was developed in-house and which now works reliably.

We are now consolidating all code essential for a modern cheminformatics platform into a single Java codebase. JavaScript will be generated for products like ChemWriter and ChemVector through source code translation. Other uses will also be possible given some of the tools that have been recently developed to cross-compile Java to fast native binaries and other runtimes and platforms.

ChemCore™

Our cheminformatics platform is called ChemCore. Its foundation consists of a chemistry model designed with the future in mind. Around this has been added a layer of efficient and flexible graph operations:

Fast subgraph matching
Powerful graph query capabilities
Flexible, efficient graph traversals

Higher-level capabilities already or will include:

Fast file input/output
A complete system of atomic weights and elemental properties
Sensible handling of implicit hydrogens
Molecule validation and correctness-checking
Molecule transformations, including canonicalization and salt-stripping
Stereoisomer enumeration and checking
Tautomer enumeration
Fingerprint generation
Name-to-structure

Commercial Open Source

Given the above survey of the cheminformatics software landscape and the trouble we had with the current options, is it possible we aren’t alone?

Had a commercial software vendor offered a platform like ChemCore under an open source license and with first-rate technical support, we would have used that option. But this solution may not be attractive to many others.

Does the world need a better cheminformatics toolkit offering greater flexibility to application developers combined with dedicated technical support? Or are the existing options working well enough?

If you’d like to discuss these questions, please feel free to drop me a line.

An Introduction to ChemVector

2011-10-26T00:00:00-07:00

ChemVector is a JavaScript solution to the chemical structure imaging problem. Structure images are generated directly in the browser from source files, eliminating the need for an image server.

This video introduces ChemVector through illustrative live examples and source code.

How to run a Presentation from an iPad Using Keynote [Video]

2011-09-21T00:00:00-07:00

Have you wondered if it’s possible to run your presentation slide decks from your iPad? This video shows how.

Materials

a Mac running Keynote
an iPad 1 or later running the Keynote App
an iPad VGA Adapter

Summary

I was skeptical that this would actually work, so I created a PDF version of my presentation and saved it to a memory stick - just in case. But everything came together without a hitch.

The video output ‘just worked’ - without any futzing around, and I was able to use the timer and current/next slides on my display to keep the presentation moving along and on time.

There were other benefits as well. For one, the iPad is much lighter and more compact than most laptops - there’s just less technology in your face. For another, battery life was a non-issue.

Cross-Platform Mobile Chemistry Apps

2011-09-05T00:00:00-07:00

I recently spoke at the Fall 2011 American Chemical Society meeting on cross-platform mobile chemistry apps. This talk argues that the best answer to the question “Which platform should I choose for my chemistry mobile app?” may well be “None of the above.”

As support, I describe the creation of two mobile applications. The first, Reagents, took six weeks from concept to App Store and required no native code. The second, ChemTab, is a work in progress that illustrates how an HTML5 native app can interact with native code to access the file system for hi-performance I/O.

ChemVector 1.0: Fast Client-Side Chemical Structure Rendering

2011-09-02T00:00:00-07:00

I’m happy to announce that ChemVector 1.0.0 is now available. This first stable release offers a fundamentally new approach to the chemical structure imaging problem.

Chemical structure images for use in web pages are typically deployed from a server - either as dynamically generated or precompiled rasters. Both approaches impose restrictions related to performance, page design, scalability, and maintenance.

ChemVector takes advantage of the native vector graphics capabilities all browsers have had for years. Chemical structures are generated directly from source files (.mol or .cdx). Raster images are no longer necessary.

Here are some of the features that make ChemVector unique:

100% JavaScript. No browser plugins are necessary.
Runs with all commonly-used browsers on Windows, Linux, Mac, and iPad. This includes Internet Explorer 6-9 in addition to Firefox, Google Chrome, and Safari.
Renders structures directly from individual molfiles hosted on a server, or inline.
Renders structures directly from ChemDraw™ (.cdx) binary files.
Declarative syntax replaces tags with analogous tags, making it easy for both developers and designers to work with the resulting markup.
Non-blocking implementation makes it possible to render dozens of structures on a single page while maintaining UI responsiveness.
Structures can be magnified programmatically or through the browser UI with no pixellation.

We have big plans for ChemVector in the months ahead, including still more performance optimizations and extensions. Your input can play a part as well. If you’d like to discuss ways that ChemVector can help your organization build better chemistry web & mobile applications, please feel free to get in touch.

The ChemWriter Special Tools Palette: Selectively Hiding Complexity in Chemistry Software

2011-08-24T00:00:00-07:00

One of the biggest challenges in creating a sophisticated drawing tool like ChemWriter is how to support more advanced use cases while maintaining a streamlined, simplified user interface for everyone else. Over the last several months, we’ve been doing this through the Special Tools Palette (STP). This short article introduces the STP, explains the functionality it currently contains, and how to activate it.

About the STP

The Special Tools Palette will only appear after one or more of its tools have been activated. This is done by passing the id of the tool into the config object on deployment. The following deployment script will deploy all of the STP’s tools available to date:

wildcard-atom-bond Converts any atom or bond into a wildcard atom or bond. Useful for structure-based searches.
atom-list Allows multiple elements to be specified. Useful for structure-based searches.
increase-r-group Increases the R-group number of an atom, or adds one if a symbol is already present.
decrease-r-group Decreases the R-group number of an atom.
crossed-bond Converts any bond into a “Cis or Trans” double bond.
wavy-bond Converts any bond into a single bond with ‘Either’ stereochemistry.

Customer-Driven

Every tool in the STP was created in response to a customer request. When these requests intersect the capabilities of the V2000 molfile spec, the new capability has generally been added. These tools appear in the STP, rather than the main palette because they are either useful to only a small set of customers, or they only apply in some situations.

Why Hide?

There are many situations in which displaying the full range of tools to a chemists would result in outcomes ranging from inconvenience to outright error. Few editors on the market treat this topic with the care it deserves. Regardless, it’s essential that ChemWriter not just be an ergonomic tool, but a tool that integrates well with the larger software frameworks it’s deployed with.

For example, many structure search system back-ends don’t support wildcard atoms or bonds. If ChemWriter were to always display the Wildcard tool, most chemists would assume that wildcard searches were supported - even when they were not. The results would range from confusion/frustration, to outright deception.

Likewise, there are only a limited number of situations in which adding R-groups to a structure makes sense syntactically. One of those situations might be a library enumeration tool. But in a single-substance registration system, the availability of an R-group tool would give those chemists wanting to register libraries the false belief that variables were allowed during registration.

In each case, leaving the decision to show an STP tool puts the developer in control of the user experience.

Conclusions

The Special Tool Palette hosts a growing collection of less frequently-used tools. By segregating these tools and disabling them by default, ChemWriter can both enable and communicate the capabilities of the system it’s deployed with.

Fast Chemical Structure Rendering on All Browsers with ChemVector

2011-08-10T00:00:00-07:00

Any web application dealing with small organic molecules must solve the problem of showing images of these structures to a chemist. As more scientific organizations discover the flexibility and cost-savings of web applications, tools to address the chemical structure rendering problem cleanly and efficiently will become more important. This post introduces a new solution to this longstanding problem.

What is ChemVector?

ChemVector™ is a pure-JavaScript solution to the chemical structure rendering problem. Although other tools are capable of generating chemical structure images client-side, ChemVector is the only solution designed and optimized to efficiently produce great-looking structures across all browsers in current use.

Simple to Use

Athough the tag suffers from many limitations as a way to display chemical structures, one of its advantages is ease of use on the client. We wanted to bring this same ease of use to ChemVector. This means you won’t need to write a line of JavaScript to get structures to display.

Declarative Syntax

Sacrificing valid HTML markup for the sake of simplicity is a terrible tradeoff. To enable declarative structure syntax with valid markup, ChemVector uses , an element supported by all browsers in use today.

To illustrate, this markup produces a 200x150 pixel image from the file called “histamine.mol”:

Notice that no JavaScript needs to be written to get a structure to display. Loading the molfile and rendering the contents are taken care of by the ChemVector system loaded in the document’s tag.

Dynamically-Resizable Images

One of the benefits of vector graphics is that images can be resized without pixellation. This is particularly important due to wide variation in molecular sizes in most databases. ChemVector makes it possible to rescale structure images after page rendering to any dimensions without any client-server round-trips.

Supported on Legacy Microsoft Browsers

Despite widespread migration away from Microsoft’s browsers in the consumer sector, large research organizations continue to depend on Internet Explorer versions 6-8. ChemVector runs, unmodified and without plugins of any kind, on these browsers.

ChemVector also runs on modern, HTML5-enabled browsers like Chrome and Internet Explorer 9.

Chemical Stylesheets

Appearance matters a great deal in chemical structures, just as fonts matter in publishing. Consistency is key, something for stylesheets are well-suited.

To enable consistency across an entire suite of web applications, ChemVector introduces chemical stylesheets. These work like traditional CSS, but are coded in JSON. For example, this HTML fragment, placed in a document’s tag, will load the stylesheet called ‘chemistry.json’:

The stylesheet is both human readable and easy to adapt:

Responsive JavaScript

ChemVector is designed to be used on pages containing dozens of structures, which may take a few seconds to load entirely. During load time, it’s unacceptable to block the UI thread - the browser must remain responsive. This is particularly important on older browsers such as IE6. ChemVector splits its rendering into small chunks, between which the user interface remains responsive to scrolling, page updates, and the back button.

Built for Speed

Although ChemWriter is capable of rendering chemical structures, it lacks most of the design and performance optimizations that ChemVector has. The reason is that ChemWriter and ChemVector are designed to render structures under very different constraints.

ChemWriter’s renderer is optimized to allow redrawing only small portions of a structure that change as a result user interaction - deletion of an atom, or modification of a bond type, for example. This means that every bond has a counterpart in the document object model (DOM).

ChemVector, in contrast, is optimized for single-use structure display, with no need to quickly redraw portions of a molecule. As a result, all bond lines are combined into a single vector graphics shape. This greatly reduces the number of DOM elements required to display a structure and increases the speed of rendering many-fold on some browsers.

A number of optimizations like this have been made to ensure the fastest-possible structure rendering without sacrificing quality.

Why ChemVector?

Isn’t the a good enough solution to the problem of rendering structures in web pages?

There are many cases where the need for a dedicated ‘imaging server’ prevents the development of what would otherwise be straightforward in a technical sense. For example, consider a Wordpress blog modified as a synthetic organic lab notebook.

Without ChemVector, this system might require interfacing a PHP plugin to server-side imaging software written in Java or C++. It can be done, but at a high cost in time, money, and flexibility.

ChemVector makes is possible for the Wordpress lab notebook to display structures using nothing more than plain-text molfiles, which are easily stored in the database back-end. There are other examples in which widely-used, off-the-shelf software can be easily adapted to work with chemical structures using ChemVector.

Then there are situations where an imaging server is simply out of the question - for example, a mobile application that must work even when disconnected from a network.

Eliminating the imaging server and the tag’s limitations makes it possible to deliver applications that would otherwise have been considered impractical.

Learn More

ChemVector eliminates a major pain point in building fast, great-looking chemistry web applications. If you’re interested in learning how ChemVector can work in your web application, please get in touch.

Five Tools for Managing Complexity in Large-Scale JavaScript Projects

2011-08-08T00:00:00-07:00

JavaScript lacks many of the tools and culture that define a clear ‘right way’ to approach large-scale projects. Yet it’s still possible to build and maintain complex software with JavaScript. But how?

For the last year, I’ve been involved in the development of a chemical structure editor written in JavaScript. ChemWriter is an interactive, graphically-oriented component that combines many characteristics of a drawing program with chemistry domain knowledge.

In the course of developing ChemWriter, we’ve experimented with many tools and approaches for managing complexity as the capabilities of the software increased. Below is a short list of what we’ve found essential:

Google Closure. JavaScript offers neither a bundled standard library nor any practical means to split source into simpler units and then efficiently re-assemble them. Closure addresses both of these needs extremely well. The definitive guide by O’Reilly is a must-read.
Test-First Development If you don’t yet test your code first, the single best point I can make is that it greatly reduces time and frustration in debugging sessions.
Jasmine. A good, fast testing environment is essential if you’re serious about test-first development. It turns out that JavaScript’s dynamic nature and support for closures make it a great fit for BDD, but only with the right tool. Our initial forays into this area lead to Screw.Unit, a slow, buggy tool to say the least that is no longer actively developed. A few months ago, we re-wrote all of our Screw.Unit tests in Jasmine, which has proven itself to be indispensable in its performance and functionality. Jasmine routinely runs over 1,600 automated ChemWriter tests in about one second. This means that every change we make to the ChemWriter source can be validated by running the entire test suite in realtime.
Autospec. Having to re-run tests is no fun. More importantly, it’s easy to forget to do. A far better workflow is to write software while having tests run automatically (on a separate monitor) after every file save. Thanks to a little Ruby, I’ve been using this approach for several months now.
Git Submodules. If you’ll be basing your code off of another JavaScript library, you’ll quickly find that keeping both codebases in sync to be a major problem. Unlike languages such as Ruby and Python, there is no package manager for JavaScript (at least not the client). Git submodules offer a pretty good solution. For example, we’re using major sections of ChemWriter source in ChemTab, a native tablet app under development. Submodules have made it possible to keep both codebases separate, yet cleanly synchronized. Each project that uses Closure includes it as a submodule through our public Closure GitHub repository.

ChemWriter is a component consisting of over 14,000 lines of JavaScript code spread over 112 source files and 14 packages, and is backed by over 1,600 automated tests. Constant experimentation with tools and techniques for managing this codebase has led to a system that works very well for this project and others in progress.

Saving the Last-Drawn Chemical Structure: Using HTML5 Local Storage with ChemWriter

2011-07-28T00:00:00-07:00

If you draw a structure in the ChemWriter editor above and reload the page, your structure will be re-loaded as well. This article explains why this capability might be useful and how to implement it.

The Problem

Drawing a chemical structure can take a lot of valuable time and effort. There are some situations in which a chemical structure editor that remembers the last structure drawn by a user would be helpful:

Structure-searchable database A user frequently searches for related structures - a family of steroids for example. Always starting the editor with the structure s/he last drew means that the next query structure can be entered by editing the last one, not drawing from scratch.
Lab notebooks and registration systems A user repeatedly enters structures bearing the same core. Displaying the last structure drawn at startup lets the user edit, rather than draw from scratch. This promotes efficiency and consistency. If a completely new molecule needed to be drawn, the editor’s ‘clear’ button would start the canvas from scratch.
Back button protection The developer wants to ensure that in the event the browser window should be accidentally closed or navigated from, the user will be able to pick up where they left off with their structure drawing.

HTML5 Local Storage

All modern browsers support a helpful new feature called Local Storage. In contrast to cookies, which suffer from size restrictions and other undesirable performance characteristics, HTML5 Local Storage is ideal for client-side storage of larger bits of data such as chemical structure representations. This storage persists across browser sessions.

Source Code

The demo above takes advantage of HTML5 Local Storage and the onbeforeunload event:

Conclusions

HTML5 Local Storage makes it simple and easy to save the last-drawn structure from a ChemWriter editor. The same technique described here can be used to persist additional ChemWriter state, such as drawing preferences and other settings.

3D ChemWriter Buttons with CSS3 Gradients

2011-07-26T00:00:00-07:00

ChemWriter is unique among client-side chemistry toolkits due to its tight integration with the browser. This makes many things possible that were previously not. For example, using simple CSS, ChemWriter’s look can be be customized to a very high level of precision. This article shows one way to use CSS to give ChemWriter’s buttons a 3D metal look without resorting to background image hacks.

CSS3 Gradients

If you’ve ever used background images as gradients you’re probably aware of the limitations. The process of creating the right gradient is slow and error prone due to the need to match the dimensions and colors of a static image (created in an imaging program) to dynamic web content (created in a separate application). Once the site is live, changing these gradients requires revisiting the entire process anew.

CSS3 introduced new functionality around gradients that renders much of this busywork unnecessary.

ChemWriter CSS

The following CSS will streamline the look of ChemWriter’s editor and give its buttons a more 3D metal appearance:

Notice the use of filter, which is how gradients are rendered on legacy Microsoft browsers.

Conclusions

CSS3 makes possible many new and powerful visual effects with relatively little effort. ChemWriter’s focus on web standards makes it possible to take advantage of these new capabilities in a straightforward way.

High-Performance Chemical Structure Image Rendering in JavaScript

2011-07-25T00:00:00-07:00

ChemTab is an iPad application I’m developing for visualizing chemical structure datasets. The user interface is based around a scrollable grid of chemical structures. A screenshot of the work in progress can be seen here:

Performance Lessons from a Java Application

Because ChemTab will be running on devices with reduced speed and memory compared to most desktops, performance is critical to achieving a usable application. Fortunately, I’ve had some experience in building a high-performance chemical structure dataset viewer with ChemPhoto. Written in Java, ChemPhoto solved a number of tricky problems relating to the display and manipulation of very large chemical datasets. Although many of these lessons will translate to ChemTab, some will not.

Painter Rendering: Fast, But Not Fast Enough for ChemTab

One area requiring a lot of optimization is chemical structure rendering. ChemTab uses ChemWriter, our chemical structure editor and rendering package, to draw its chemcial structure images directly from molfiles. Back in April of this year, we introduced browser-side chemical structure depiction with Painter.

Although ChemWriter’s Painter rendering has been fast enough in most cases we and our customers have tested, it’s not fast enough for ChemTab, where many more structures need to be drawn in real-time in response to scrolling events.

Imager: High Performance Structure Rendering for the Browser

To improve structure rendering speed, we’ve developed Imager, a component that will be making its way into a future ChemWriter release.

Imager works quite differently from Painter. If you imagine ChemWriter’s Editor without buttons, panels, or dialogs, that’s a fairly accurate description of Painter. In addition to generating SVG, Painter allocates a lot of extra memory and processor cycles to services that are unnecessary to simply view a structure: cached objects; event handlers; containers, and UI handles. Painter retains almost all of the latent interactivity that Editor has, and could be very useful in situations where user events on a structure need to be synchronized with another page element (more on this later).

Imager, in contrast, is designed to do one thing only - create an SVG DOM tree representing a 2D chemical structure. There is no possibility of detecting events on a given atom or bond on the resulting image. The tradeoff is much faster image creation. To push performance even further, Imager uses a custom Graphics context instead of the SvgGraphics object provided by Google Closure.

The result is noticeably faster image generation in ChemTab. In a future article, I hope to discuss benchmarking studies to quantitate the improvement.

As a bonus, Imager introduces a capability previously unavailable in ChemWriter: the automatic scaling of chemical structure images. Think of a DOM element in a web page that the user can resize. Imager makes it trivial to automatically scale and center this image as the user resizes the containing element. This applies equally to a single image or to a collection of images, as in a table or grid.

Conclusions

This post introduces Imager, a new chemical structure imaging component that will be appearing in a future ChemWriter release. Although developed to solve a performance problem in an iPad application called ChemTab, Imager should also be useful for a variety of high performance chemistry web applications.

Cheminformatics for iPad: ChemTab Now Running on iOS Simulator

2011-07-21T00:00:00-07:00

The last article described the achievement of one of the first major ChemTab development goals - to display a grid of chemical structures from an SD file. We’ve now met the next milestone - running the current version on an iPad simulator:

For those not familiar with iOS development, one of the useful tools offered by Apple is an iPad simulator. This software was used to generate the screenshot above, and we’ll be using it for future ChemTab screenshots.

Notice that there’s nothing in the screenshot to indicate the presence of a browser - no address bar, no toolbars - just the app itself.

You may have also noticed the Navigation bar at the top of the screenshot. Although we’re using HTML, CSS, and JavaScript to build ChemTab, one of our goals is to match the standard native iPad app look and feel. We’ll return to this topic in future articles.

Four Speculations on Future Enterprise Software Demand

2011-07-20T00:00:00-07:00

Roger McNamee, cofounder of Elevation Partners recently gave a talk in which he offered some hypotheses about the present and future of information technology. Although the entire video is well worth watching, four of his hypotheses are relevant to scientific software and the companies that create and buy it:

The Decline and Fall of Windows Unlocks Revenue. Windows no longer provides measurable ROI to enterprises, who will eventually reallocate tech spending.
HTML5 is Game Changer for Publishers. First major upgrade in a decade to infrastructure of the web will be disruptive, enabling monetizable differentiation of content.
Tablets are Hugely Disruptive. Apples’s iPad will be even more disruptive than the iPhone.
“Next” Web architecture = Cloud + Lots of Screens. Proliferation of Smartphones + Tablets will accelerate need for an value of cloud services.

If McNamee is correct, there are big changes ahead in the ways large organizations allocate their IT budgets. Small, nimble technology companies will be presented with a rare chance, if prepared. Larger players will face significant problems adapting to the new normal.

Building ChemTab: Displaying a Grid of Chemical Structures in a Browser

2011-07-19T00:00:00-07:00

As previously mentioned, I’m building an iPad application called ChemTab to visualize chemical structure data. Development of this app has been proceeding fast enough that I can now show the first of what will hopefully be many screenshots of work in progress.

You may be wondering why, if I’m creating iPad software to be distributed in the App Store, would I be using HTML? The answer is simple: ChemTab will be a native app built mainly with HTML, CSS and JavaScript. If that sounds impossible, stick around and I’ll show you how it’s done.

A few words about the screenshot may be useful. Behind the scenes, I’ve written an SD file parser with be beginnings of a high-performance I/O system to work with potentially very large Structure Data (SD) files. The entire table is generated dynamically using JavaScript together and ChemWriter for structure depiction. The table can be programmatically scrolled up and down, just like a spreadsheet or table of images.

There’s still a lot more work to be done on every level, but hopefully this first look at ChemTab offers a better idea of where we’re going.

ChemBot: Batch Convert ChemDraw CDX Files Into PNG Images Using AppleScript

2011-07-18T00:00:00-07:00

If you’ve ever worked with a large collection of ChemDraw™ (.cdx) files, you may have needed to convert them into images for publication on the web or elsewhere. You may have concluded that the only way to do this would be by through liberal application of elbow grease, or finding someone willing to do it.

If you’re working on a Mac, I have good news for you. As part of an iPhone chemistry application my company is helping to develop, we needed to convert a large number of CDX files into PNGs. Read on to find out how we automated this process and saved a bunch of time.

Downloading and Running ChemBot

ChemBot is a small Mac application written in AppleScript. It can be downloaded from GitHub, and the source code is also available there. ChemBot requires ChemDraw Ultra 12.

To run ChemBot:

Open ChemDraw Ultra 12.0 or later.
Double-click on the ChemBotApp icon and follow the prompts.

Faster execution is possible by launching ChemBot through the AppleScript editor:

Open ChemDraw Ultra 12.0 or later.
Double-click on the ChemBotScript icon.
Click the “Run” button and follow the prompts.

How It Works

ChemBot is written in AppleScript, Apple’s built-in application scripting language for Mac. Although conceptually a very simple piece of software, one of the hard things about creating ChemBot was the surprising scarcity of real-world AppleScript examples.

Our starting point was Chris Swain’s excellent AppleScript tutorial series. One of his tutorials proved especially useful: Convert ChemDraw to TIFF. Although it wasn’t quite what we were looking for, it was a start.

After some experimentation, we hit a major problem. Although we could get ChemDraw to open CDX files automatically and recurse folders, we couldn’t get PNG files to be saved. Chris Swain very quickly came back with an answer to my email: ChemDraw apparently can only save images files to an existing alias. Attempting to save to a filename that doesn’t exist won’t work.

Making the needed change allowed us to finish ChemBot and solve the problem of automatically converting CDX files into PNG images.

Source Code

ChemBot is distributed under the MIT License. For completeness sake, here is the source code:

Other Ways to Automate ChemDraw

Although I didn’t find many other examples of ChemDraw automation, one worth noting is Rajarshi Guha’s use of Python in ChemDraw scripting. This approach has the advantage of working on Windows. Finally, CambridgeSoft (now Perkin-Elmer) also offers a scripting language for ChemDraw called ChemScript.

Conclusions

AppleScript is a useful piece of technology, although good examples of its use are in short supply. In addition to solving our specific problem of converting CDX files into PNGs, ChemBot could be used as a starting point for more complex ChemDraw automation workflows.