Category Archives: Proto

I hope their intentions are honorable…..

I’ve said before that these two would make an ideal couple, I see the courting flirting has begun …..

RSSBus

Proto

Proto

In the two months since I first came across Proto I’ve worked my way through most of the tutorials and sample applications and I’ve come away with a very positive impression of the product. I hadn’t however managed to the find the time to create a VBA based component; that is until last weekend. It was the choice of VBA as the product’s macro language that first attracted me to Proto – that and its close integration with Excel – and to celebrate this victory of practically over fashion I decided to build something real (i.e. might just be useful in the real world not just another map mashup demo – I’m just jealous of the fact that Google Maps for my part of the world consist of major roads and nothing else;-)).

So what to build for my Proto debut? Well looking at Proto one of the things that struck me was the lack of a relational join feature. In a previous post I explained that other mashup tools tend to use XML as their “pipe transport protocol” rather the table-oriented nature of EntrySets. But these entrysets cannot be manipulated using relational operators, not even the ability to join two tables by a shared key. Although the tool doesn’t offer this facility it does offer the flexibility to create a component to solve the problem and somebody has already done so; simulating an Excel VLOOKUP “join”. But I wanted the full power of a relational engine, INNER and OUTER joins, UNION and MINUS, aggregations via GROUP BY, access to very large datasets and I already had the answer; an Excel VBA module, xLite.

To say that xLite is a standard generic piece of code would be to exaggerate, it is like most operational VBA code, a template of ideas that are manipulated from project to project to serve the needs of the day. It had started life as an excel-to-Oracle tool (when it was called xORA), morphed into a SAP master data extraction tool (by the name of xSAP), finally getting a bit of structure when I discovered SQLite as the ultimate desktop database (having occasionally being seduced by that grand old dame, MS Access). Its further transformation into a Proto module required more renovation work; replacing Excel Range objects with variant arrays and replacing the excellent but COM based LiteX SQLite wrapper with the simpler but more flexible PSSQLITE.DLL thus allowing registry-free deployment.

By why SQLite, why not MS Access or SQLServer? See “What’s So Good about SSQLite” for why I use SQlite but in this case two reasons stand out;

  • Manifest Typing:

SQlite doesn’t enforce column based types (i.e. VARCHARS,TEXT,INTEGER etc.) like Excel (more or less) it’s the content of the cell that determines its type – SQLite calls this manifest typing. This allows excel Ranges and Proto entrysets to be filtered through a relational join without type-conversion errors arising but at the same time allowing the database to recognise types where useful. For example;

Month SalesThisMonth
Jan07 1000
Feb07 2000
Mar07 Accounts not available!!!
Total 3000

Excel and SQLite will both give a Total of 3000 for SalesThisMonth column, most databases would choke on the accounts-not-available value.

  • In-Memory database:

SQLite does not need to be “installed” before it is used. Like MS Access the data resides in a single file but unlike MS Access even that single file can be dispensed with by using a “:memory:” database as I do within xLite.

The transformation from Excel to Proto VBA for both myself as the programmer and the code as the programmed proved to be trivial and rewarding. In this occasion I did most of the work and testing from the Excel IDE as I hadn’t yet fully comprehended the event firing mechanisms within Proto but I think in future I might develop and test under Proto and then port the code to Excel.

So any negatives?

With the development experience any negatives were generally to do with my inexperience with the platform (e.g. the above mentioned event firing causing me to “hang” the program once or twice) or features such as non-Excel “asset” management which are, I believe, on the product’s roadmap (e.g. I have to download my DLLs from the web rather than including them in the .PROTO manifest file as I would prefer).

My main two “problems” with Proto are not technical as such but market positioning misgivings:

  • Treating Excel as the add-on;

Proto will not run without Excel being installed. Excel is the prime piece of data-manipulating real estate on users’ desktops. They trust it and depend on it. It would be much easier to “sell” Proto to end-users if Proto was marketed and packaged as an add-on to Excel (see for example Palo OLAP ).

  • The Price;

Pricing software products is not easy (see this if you’ve never given the subject any consideration) and the last thing the good folks at Proto need is somebody on the other side of the ocean telling them they need to charge less per seat for their software. But I think they do if they intend to sell this software to individuals rather than to corporate IT purchasing departments. By individuals I mean the SMB owners/accountants/salesfolks, the large company departmental power-users, the freelance ‘data smiths’ like myself. Selling software into SMBs is not the same as selling to large companies (for some of the problems see http://supplychainventures.typepad.com/my_weblog/2006/04/tackling_the_sm.html) but equally selling something “new” into large company IT departments has in many cases become impossible unless that “new” product comes with a MS,Oracle,IBM or SAP badge on it.

But let’s not end on a negative, with its feet firmly on the ground where business computing currently operates (i.e Windows/MS Office, behind-the-firewall company intranets) but with an eye to the opening up of IT to the economics of the wider internet, Proto is one to watch.

UPDATE:

Byron Binkley CEO of Proto has pointed out in the comments below that the current dependency on Excel is temporary and will be removed in a future version. But he also reponds to my pricing concerns by offering ….

….a total of 50 licenses over the next 90 days (through July 13th 2007) at $79.50, a 90% discount to the listed price for Proto Individual (http://www.protosw.com/products/purchase)…

…this offer applies to anybody mentioning this blog post. This is pretty typical of my dealings to date with this young company; you raise a problem and they respond with a solution. Takes all the fun out of complaining.

Habemus Proto

I’ve just uploaded my first Proto module; a rewrite of a VBA module I’ve been using for many years to provide me with a bridge between the ease of use of desktop user-focused tools and the power of a SQL enabled database. In the past that database was Oracle (and occasionally MS Access) and the desktop tool was of course Excel; now the database is SQLite ,the client tool is still Excel but this time in a supporting role to Proto. Over the next few weeks I’ll document and publish both the Proto and the pure-Excel version of the this code, in the meantime check-out the work-in-progress project page for xLite (http://gobansaor.wordpress.com/projects/xlite).

VBA & JavaScript – glue languages

What have Javascript and VBA in common? Not much on the surface and their respective user bases rarely if ever overlap. What they do share are their roles as the imperative (the-if-then-else-loop-etc) programming languages of the “I’m not a programmer” programmers, the great unwashed, the “normal” people out there who are just trying to get something done. VBA adds that “something special” to millions of Excel spreadsheets and MS Access databases. JavaScript does likewise for millions of web pages. Most of the code is copied from existing examples or generated by macro recorders. Often the code is not pretty, not well structured, not adequately tested but it is usually “good enough”.

Both languages can also transcend their “ugly duckling” status. If you want to take VBA development to a new level have a look at Professional Excel Development by Bullen et al. GMail, Google Docs & Spreadsheets and the other AJAX powered applications of Web2.0 show the power of JavaScript. Both languages are now starting to move beyond their original home bases, particularly in the case of JavaScript.

VBA has been used in the past as the scripting language for corporate applications such as Siebel; now in an inspired move, Proto opted to use VBA as the scripting environment in their corporate focused mashup tool.

JavaScript is however showing the real expansionist streak. Along side its traditional client-side role in web page DOM manipulation, Mozilla Firefox extensions, widgets and within Flash applications under its ActionScript implementation, it can now be found providing the imperative flourish to many client and server side declarative tools (e.g. Kettle ETL, OpenLaszlo and Grazr). You can even use JavaScript to provide the complete server-side logic for a web application/service by using Zimki.(deadpool)

My decision to spend time to improve my JavaScript skills was as a result of my experience with Zimki. I initially created a web service to sign requests for uploading files to my Amazon S3 account; allowing me to give clients a small executable (developed in VBA’s big brother VB6) with which to securely upload data to S3 without the need to expose my Amazon account credentials. This turned out to be so simple and elegant with Zimki’s Rhino based JavaScript environment that I decided this language deserved some quality time. I had I guess, like many others, confused the mess that is the browser-wars scared DOM with JavaScript (or more correctly, EMACScript) the language. Having looked further, I’ve discovered an elegant,simple yet powerful language that I’m tempted to think may become the universal glue-language.

UPDATE:

As Tom from Fotango (the Canon Europe company behind Zimki also in deadpool) points out, Zimki uses Mozilla’s C implementation of JavaScript, SpiderMonkey rather than Rhino.

UPDATE: Sep 2007

Cannon Europe are to close the Zimki service on Dec 24th, 2007

UPDATE: June 2010

See how I combined VBA and JavaScript, to make JavaScript an Excel scripting language http://blog.gobansaor.com/2010/06/04/javascript-as-an-excel-scripting-language-via-jsdb/

Mashup Match Making

I’ve been watching and trialing RSSBus since its initial public beta last May but had of late began to wonder had /N Software lost interest in the project.  But there appears to be light at the end of this particular beta tunnel with the announcement of the integration of the RSSBus engine into News Gataor’s NewsGator Enterprise Server (NGES), still no pricing info on either NGES or RSSBus server.

Another potential partnership that the folks at RSSBus should investigate is a link up withProto.  Both products are firmly positioned behind the corporate firewall with their emphasis on commercial data sources i.e. – dare I say it – mashup tools for adults. 

Proto is visually appealing (like Yahoo Pipes) and is Excel centric in both its table-based design philosphy and its choice of macro language, VBA; both sound design decisions in the market the product is aiming at – the power user.   It is however, lacking in some of the ‘heaving lifting’ tools that power-users depend on but are usually supplied to them by IT; this is where RSSBus comes in.  With its XML scripting language and its extensibility capability provided by C#/VB.NET its natural user base is the corporate IT developer.  RSSBus’s impressive list of pre-built connectors and the ease with which developers can add new ones, makes it an ideal partner to Proto’s more approachable user-focused front-end.