Things to contact me for Spring `23

Transformed this leading desktop construction scheduling software into an ultra-modern SAAS.

We are self-funded and each principal contributes to all aspects of the business, including coding.

Suddenly I'm an SAAS operator, and things like customer acquisition cost, sales funnels, and customer lifetime value are no longer as abstract as they once were.

Created a cms and publishing system for the "long tail" content that is the institutional memory for Foundation for Advancement in Conservation (FAIC). cOOL is an archive of some quarter of a million documents comprised of web sites, journals, and email lists dating back to the 1980s. It's an authoritative and invaluable resource for museum conservators from around the world.

This is the sort of thing worth engaging me for and is representative of how I work these days, using free and open source software and the cloud to solve a problem simply and elegantly; along the way, giving back, improving the tools I used: gulp-awspublish and gulp-ssi.

The publishing system is based on aws hosted git, a CI/CD pipeline in CloudBuild, with CloudFront and lambda edge functions serving contents from an S3 bucket. The FAIC can more easily manage additions to the site and can operate on the corpus en-masse to better serve their community.

Elasticsearch constitutes the primary funnel for this boutique hotel site. I upgraded from version 3 to 6.8 and made much needed improvements after teasing out lessons learned from years of production use.

The upgrade was fairly straightforward, though both the ES mapping and the query syntax had changed considerably across 3 major versions. A good deal of the work was carried out at the python client level, including enhancements to the imports from the operational data store.

We made significant improvements to to the auto-suggestion performance by taking advantage of the new autocomplete analyzer, refactoring the existing queries, and increasing the use of synonyms.

Tuning ES searches is an iterative process. I provided my client with some tooling that allowed us to quickly compare different versions of queries/mappings to arrive at the best possible behavior.

My involvement with AGT began with a gift/experiment. Could tech in Itchy Knows, my hashtag aggregator improve SEO for this large scale (over 10 million pages) directory site.

Soon I was doing a lot more. My clients ability to progress and adapt was ham-strung by a legacy code-base that had been worked on by many hands over the course of a dozen years. I felt compelled to help.

It's now a modern and solid PHP MVC app running on the google cloud. I've worked with the founder to open up new lines of business and to adopt lean practices like experimenting via minimal "build, measure, learn" iterations.

Along the way, I've become schooled in issues that arise when you have a statistically significant number of web pages (especially with regard to SEO), pretty good at defending a busy site against attackers, and am now a competent PHP programmer (though if there's such a thing as idiomatic php, I don't think I write it).

AGT is large enough where it needs to maintained and evolved by an organization and a not a couple of solo practitioners. In 2022, I've begun transitioning development to a new development partner, and will continue my relationship with agt as a fractional CTO.

This "startup" within PWC moved rapidly to create a new generation of software for field service and retail sales organizations. The goal was to replace behemoths like Great Plains and home grown systems with modern applications that use big data, machine learning, and conversational interfaces.

Initially, I was to identify and enforce commonalities across the efforts of a large and fractious group of vendors.

I on-boarded teams, reviewed code bases, and evangelizing for a common set of practices around the development of micro-services, continuous integration/deployment, containerization, search, ETL, and the use of BPM engines for the orchestration and business logic.

It soon became apparent that I was only adding to the cacophony in that role.

I withdrew into one of the product teams working under the rubric of "fit-bit for work". As the main applications gathered an ever increasing amount of data, we would provide individuals and management tools for changing behavior to measurably improve performance. Working with my friends at Philosophie, I got a taste of their flavor of product development, as we designed, built, validated, and piloted several iterations of the app.

Helped this tax preparation startup get to market for the 2016 tax season. In 2022, they closed a $20mm series B round. Congratulations!

While the internal team burned the midnight oil to deliver an IOS and Android application using React Native, Alvar and I created the portal to be used CPAs to service clients. We used flux/react on the front end, which was a pleasure and a revelation after working with Angular and Backbone for the last few years. Something like react is definitely the future of front end development.

While carrying on the portal work it became clear that many of the back end apis and integrations were not as far along as they needed to be. I juggled some other obligations and and dug inl. I moved the data from a simple in-memory database to mongodb, carried out the integration with the layers chat API, created a secure real-time push APIs, a secure document sharing system using S3, and transfomed business entities for consumption by clients.

As a result, Tax-fyle was able to bring a product to market for the 2016 tax season, greatly increasing the chance they’ll be the uber of accounting.

I led the turn-around for the build of this high fashion/micro-blogging application.

Finding bits and pieces of technology with partial and often ill thought out attempts at integration, the CTO and I quickly assembled a new team and moved forward with a hybrid mobile application using ionic, python to scrape product information, and node for a RESTFUL api.

Initially, I supervised both the python developers coding the scrapers and built out the development/deployment infrastructure. As the team coalesced, I was able to focus on building out the back end domain model and api as well as evolving the the product direction with the management team. Finally, I directed the work of an off-shore data science team to put in place the product search using ES.

This is an example of the sort of work I did around the time where I would work as an extra hand helping out a team with an established code base. It also shows that I know a fair amount about django, though in fact I don't care for nanny frameworks.

I merged the code for the agencies and individuals awards programs into one and helped to create a third contest type: Shorty Awards for Social Good.

I also worked a bit on evolving the data model and administrative interface for their other business: https://muckrack.com. Primarily, I made fancy tweaks to the django administrative interface.

django-admin is great. I've used it to create internal tools many times. flask-admin is almost as nice and has the advantage of not needing django.

An educational non-profit outsourced the development of a suite of applications/web sites. The organization and applications were thriving, but they suffered mightily from vendor lock-in.

The dependencies for each application were quite complex and specified nowhere but on the developer workstations and the server deployments. My client couldn't work with responsive and less expensive resources and was being pummelled by truly exorbitant hosting fees. They were stuck!

The suite was created in symfony2 and used compose to handle dependencies. However this didn’t account for all the operating system level dependencies, not to mention the complete python, ruby, and java environments the symfony toolchain requires. That's one crazy toolchain, btw!

Putting on my detective hat, I identified the dependencies for each application and made them explicit through a series of docker and docker-compose files. A development environment, including the support database could be spun up by running a single script. We used docker and the docker-cloud to deploy to automatically deploy to digital ocean.

Hosting costs went from $10,000 to $400 per month! The organization is no longer chained to the original vendor and savings go to improvements. New developers can be on-boarded and be productive within hours.

I facilitated a series of workshops for the industry experts/founders intent on bringing efficiencies to the commercial insurance process.

We were able to forge a common understanding and vision for an initial roadmap for their risk marketing and business intelligence Platform.

I produced a vision document that enabled the development team to scope and architect the offering that was successfully brought to market last 2017. Congratulations!

I led the engineering effort for this social re-commerce marketplace. Think craigslist 3.0 where community and transparency are valued above anonymity.

The cir.cl architecture builds on what I've learned on the Exorcists VS Demons RPG and is my second iteration on a large scale full-stack javascript application. We use express and backbone. Mongo, postgres, redis, and neo4j are our data-stores. The application makes extensive use of reactive techniques like out of request loop messaging, and event sourcing.

Working along with a young engineering team, we quickly executed on the founder's vision without accruing technical debt.

With this project I realized that solid tech, a strong team, and even what seems like a great product is NEVER enough to ensure success. One has to make do with small bets (some call them experiments), learn from them, and iterate.

Bonus fact! The angel investors for circ.cl were Eric Schmidt and the rock band Metallica. We took meetings with both, but never at the same time!

Launched a number of mobile first "games" for clients like google and Publishers Clearing House using off-shore development resources.

In those days I was their CTO, though our collaboration continues to this day (2022). Now I mainly help Oren and Joe strategize new opportunities and ventures.

With a successful portfolio of free IOS and Blackberry based electronic headache diaries, our clients next move was a web based version with more sophisticated reporting and analysis capabilities that also allowed patients to share data with physicians and other health care providers.

A limited budget (after all, their software is free to use!) necessitated an approach and a set of technologies that would maximize chances of reaching an ambitious goal of building two commercial quality web applications essentially for the price of one.

Sencha Ext JS provided a rich and consistent user experience without the need to over-design and fuss with front end elements. Crucially, we saved hundreds of hours of development time using a third party calendaring control. The nature of the headache information lent itself to being stored in the CouchDB nosql database.

Perhaps our biggest win was in using Maven to generate two sites (one for patients and one for health care professionals) from the same source. This went a long way towards getting the project done within tight budgetary constraints.

Leading the build of this AA browser based RPG is part of my ongoing collaboration with DarkRoast Media.

The biggest challenges on this project was growing and managing a development team for a non-traditionally funded project (everyone took a cut in rate in exchange for points on the back end). Another was keeping the codebase responsive to changes in the creative content and game rules.

Using javascript up and down the stack reduced conceptual surface area and made new developers productive more quickly. Significant amounts of code of was shared between the client and server, largely doing away with the distinction between front and back end developers. Having nearly a thousand automated tests allowed us to to progress quickly and safely, even with a revolving cast of developers. Finally, Angular kept the team disciplined in the browser (where spaghetti code is all too frequently still the norm). Angular is an opinionated framework. It enforces coding practices and patterns that might seem harsh. But it prevents folks from going astray.

We kept up with changing creative, and game mechanics, by driving business rules from the contents of google spreadsheets which could be loaded directly into our datastore. Our creative team could experiment with game parameters and see the effects in the game world almost instantly.

Fueled by two rounds of private investment, the team made great progress for 14 months. Unfortunately we weren't able to secure more funding and shuttered the project. Many of the folks on the team have continued working together over the years.

All that remains of evd (except in my git repo) is here: https://www.facebook.com/ExorcistsVsDemonsCommunity.

My development partner was presented with the opportunity to take over a plum Internet property, gamify it and to move it over to google+. The only hard requirement was it had to run on the google app engine (GAE) . My partner had gaming, design and development chops, but no experience with the google app engine, nor with python or java, the languages supported on the GAE at the time.

I proposed a development style in which the application would be built as a single page javascript application communicating with the server via a REST API.

This happens to be my favorite way of developing web applications, maximizing productivity and demarcating a good separation of concerns. For my partner, it meant working with the tools they were most comfortable and expert with. The only change to their process was to have to run a shell script that uploaded the application to a local copy of the google app engine. A virtual python environment we built made this a snap.

I built the server side of the application using python. On the app engine, it's all about minimizing the resources used. The super lightweight flask micro-framework provided just the features we needed. Our API put most the business logic in the javascript client, allowing for the game rules to evolve without needing changes to the back-end.

There were a few challenges and reversals. It turned the social network didn't support client side sessions so we had to re-architect the initial version of the application. My partner had to learn how to architect a more complex javascript application than they were used to, but soon settled on an event publication and subscription system that allowed them to proceed quickly.

This project marks the beginning of my on-going collaborations with Dark Roast Media.

The client required a sophisticated discussion forum to help solidify a far flung and diverse community of scientific researchers. The default SharePoint 2010 implementation didn't deliver on all of the requirements, and fell especially short in delivering community building features.

After reviewing all the available third party packages, we proceeded with a custom SharePoint solution. We built out strong community building features such as voting, tracking and rewarding participation. The solution provides sophisticated taxonomy capabilities.

The application was delivered as a set of features attached to any existing sub-site. To save on development costs, SharePoint lists were used for our data store and the native editing pages were used for all administrative functions.

The look and feel is significantly different from SharePoint out of the box. A rich UI was provided using Flash and JQuery communicating with custom web services. The application also integrates with the PUBMED bibliographic database to allow researchers to share publications with others.

My involvement with the project ended before I could gauge how it would received by the research community. However, I'm pleased to have provided community building tools that anticipated the features in later versions of SharePoint. As usual, the project was completed on time, on budget, and, with a minimum of fuss.

A prominent digital movie studio needed more insight into their production process. In a dynamic, creative environment, it was difficult to know things like: “How close are we to finishing this movie?”, “How efficient are we on this movie as opposed to the last?”, or even “Is this scene done?”.

Upon review, my unambiguous recommendation was for the studio to license the market leading software for their vertical. Top management disagreed and wanted to pursue a custom system. The studio had a strong tradition of in-house engineering; their process was unique; and they hoped to, perhaps, bring the software to market.

I counseled that they would have to devote substantial resources to the project to match even a subset of the commercial product's features, and that they were committing themselves to a long-term development effort to evolve the product to keep up with the needs of the internal users, let alone bringing a product to market.

I proposed, but management disposed. The project would be managed by a studio executive. I would help them put together an internal team and handle key portions of the architecture and the development effort.

We decided to leap-frog the market leading project management software by building ours on top of a BPM engine and exposing its services to as many clients as possible with a RESTFUL API. This was necessary because the client for such a system could as well be a python or a Maya animation script as a web page.

Working closely with studio leaders, I modeled their process with a two level work flow. One at a high level to track assets (and aggregates of assets) through the big steps in production process. And another at a low level to track the more free-form nature of the work as actually done. There could be many alternate high level work flows (controlled by an external business rules engine). The system would emit and store vast quantities of business activity data to be presented by a Business Activity Monitoring System (BAM). We would display key performance indicators (KPIs) for the current film and have a wealth of historical data to analyze across films.

Internal developers produced a flex/java based asset browser. I wrote a wrapper around the JBOSS JBPM work flow engine incorporating studio specific use cases, BAM instrumentation, and the two tiered system described above. I exposed this to clients via JAX-RS REST Services (built with JBOSS ReastEasy). When development of JBPM at Red Hat ceased, we first contributed fixes to the project and then quickly rewrote the services using Activiti BPMN.

The project foundered because of lack of focus by the studio and secondarily for lack of resources.

After a year and a half of effort the studio canceled the project licensed the market leading project management software. They are happy with the results

Thinking there was value and perhaps a business opportunity in bringing some order to the chaotic world of social media, I started coding Itchy when everyone else started working on on social media aggregators , maybe a few weeks earlier.



Folks liked it and used it. They would create #hashtags for events like proms, festivals, corporate meetings, etc. Itchy would monitor facebook, twitter, and instagram for images with the tags and shunt them to a facebook page, a tumblr, or a custom website.

I worked on Itchy for two years. I would have continued, but had to shutter it when instagram discontinued it's public search API which made a big chunk of the internet go dark. Itchy left behind several hundred disappointed users.

Itchy marked my first big python based system. The python eco-system is cushy enough, but I find coding in the language not to my taste. I'm glad I was able to pivot to node/javascript about the same time.

Fortunately I was able to reuse large parts of the Itchy on a number of studio projects, including SEO enhancements for agreatertown.

My client is a startup that handles outsourced clinical study management. This highly regulated and complex process absolutely requires sophisticated software automation. Yet it is difficult for a small startup to spend what it takes to build CTMS (clinical study management systems) using traditional development methods.

I recommended building a CTMS system based on SharePoint technologies. SharePoint provides a strong foundation that supports collaboration, customization, work flow, and document management.

The bulk of our application consists in glue code that orchestrates SharePoint features such as lists, document libraries, and the permission model.

Though SharePoint is a super capable platform, there are certain aspects that make it seem a tad old-fashioned in this Web 2.0 world. We integrated technologies such as JQuery, LINQ, and the newest MS Charting control to make it even better.

Having built similar systems for other pharmaceutical clients, I was very pleased to be able to build such a powerful solution with a fraction of the effort that might be required using traditional techniques.

The group that created the on-line version of the IEEE magazine jumped ship leaving our partner in the lurch. Sometimes, the problem with java development is the abundance of riches, especially in the hands of an inxeperienced team. In reviewing the technology behind the magazine I found a snake pit: four web frameworks, two different templating engines!

It was all too much. Plus, the original application dated from 2000. Many basic functions were built from scratch (and so were hard to evolve), whereas today we would turn to any number of open source frameworks to accomplish more in a sustainable manner.

Everyone was surprised to hear that my answer to requests for features was often “let's throw some shit out”. The home-grown blogging system was the first to go. We replaced it with a hosted version of Movable Type integrated with the main application via RSS and JSON. We replaced a rudimentary caching system with Akamai, eliminating pernicious errors that would crop up under heavy loads.

I successfully the mastered a complex technology stack to allow our partner to service an valuable clients needs and to expand the engagement.

For a while, it seemed like digital technologies would change the balance of power in the music business. IDEA helped independent artists and labels capitalize on this by allowing them to distribute their own music.

Integrating their application with the various digital services wasn’t so easy, requiring substantial development and testing effort to provision a new service. My charge was to create a system by which new services could be brought on-line easily.

Publishing music to different services like iTunes and Napster involves similar steps, but with a fair amount of variation. Files must be encoded (but in different formats) and transferred (but using different protocols). Metadata must be transferred along with the music files (but each service requires a differently formatted XML file).

I encapsulated this variation by creating a domain specific language for e-music publishing. The framework handles common tasks such as error handling, workflow and provides primitive operations for file encoding, art generation, file transfer, and metadata creation. Most variability is driven parametrically, via Spring configuration files, rather than programatically, eliminating most of the code that would otherwise need to be written (and tested) to integrate with each service.

Provisioning a new service is a matter of stringing together a set of already written and tested tasks via a Spring configuration file. A new service can often be brought online in less than a day

My partner estimated the production of this large scale web portal providing localized and personalized health care information to consumers would require nine months. Their client wanted it in three.

To meet this super aggressive schedule, I drew on my relationships and assembled and oversaw the efforts of a large, heterogeneous development team.

My deep experience in developing content management and electronic publishing systems enabled me to foresee what would be required of a system that would aggregate personalized content from a multitude of sources including web services, relational databases, and even legacy formats like the Cobol extract files.

Thorough unit test coverage ensured deep changes could be made to the system in response to fluid and ill defined customer requirements. Our continued reliance on lightweight J2EE development helped mitigate the risks of a large, heterogeneous development effort. The Spring framework greatly simplified application configuration and integration of of different principal contributions. We used its aspect oriented features to greatly reduce the amount of code we had to write. The latest version of Hibernate handled the task of mapping objects to the postgres database and eliminated the need to create separate mapping files.

The site went live on schedule to the ultimate clients satisfaction. The client, unfortunately went ahead and stiffed us for a large portion of bill.

Like instagram, but for extreme sports practitioners, and 7 years too early (no really!).

Drawing on lessons learned over five years of server side java development, I'd put in place sort of service oriented stack that companies like Airbnb, Spotify, and Uber still use in 2022.

I marketed this hard to adventure travel companies for 3 years, but it turns out that I was way, way ahead of the tech adoption curve. On the plus side this tech stack and style of development served me well for almost s decade. Plus I got tax deductions for trips to Costa Rica, the Dominican Republic, and British Columbia.

I worked with the learning group at this leading software manufacturer to create a road map for integrating CBT (Computer Based Training) production with the companies global content management system.

Our goal was to create a single source of authoritative product information that could be used by both the documentation and learning groups, eliminating the cost of creating and maintaining redundant content.

Our road map detailed two approaches: the enhancement of the XMetal authoring tool to support LCMS specific features, and a path for integrating the Thinking Cap LCMS with the Vasont content management system.

Carried out custom application development for the research and development division of this pharmaceutical company along with a team I assembled.

I originally won the business away from a poorly performing vendor and carried forward work for which internal IT resources were ill-suited.

Our collaboration grew into a suite of some half dozen enterprise applications (with the technology split between J2EE and .net applications). These included project management applications (including work flow, calendaring, and document management), business intelligence dashboards, and payment and clinical trial management systems. Most notable was project.pharma, the system of record for the firm's drug development pipeline and a clinical investigator payment application that ran uninterruptedly for some 8 years.

Towards the end of the engagement, we began moving much of the suites features into SharePoint. When the company decided to move away from bespoke applications, we led the transition and engineered ourselves out of the relationship.

Created a content management/sales force automation system sold by partners such as BI Performance, Caribiner International, and Badiyan Productions to numerous Fortune 500 companies.

contentWrapper had the following advanced features:

A media library comprised of multimedia assets and Microsoft Office Documents. Item descriptions were indexed and fully searchable. Elements were easily manipulated and could be remixed while preserving brand messaging.

The ability to be “skinned” for unique branding.

Facilities for manipulating the contents of the library and Office applications, making it easy to create value added applications like proposal and presentation generators.

An authoring system that made it easy for licensees to update the media library and publish new editions of the contentWrapper.

A small team (including John Klima), Prof. David Eltis, and Cambridge Univerity press, created the pioneering Trans-Atlantic Slave Trade Database. This was the first widely available digital tools for the research and analysis of the Atlantic trade from the sixteenth through the mid-nineteenth century

This milestone project languished for more than two years when principal after principal proved incapable of producing a powerful research/teaching tool that fulfilled the vision of its compilers. The biggest challenge was to enable manipulation of a large dataset, including statistical analysis of query results, graphing, and geographical display running on the gamut of desktop computers circa 1999.

To maximize performance and minimize external dependencies we developed in Delphi using an embedded database. The resulting application ran on every version of Windows available in 1999. The ArcView component from ESRI to provided mapping capabilities. Our first foray into GIS. We completed the application in four months, on-time and on-budget. It has proven to be an invaluable teaching and research tool winning a Frederick Douglas award.

Put in place the place the people, processes, and technology that transformed this meetings company from a print/video/event business to an digital one.

Offerings included performance support, internal training materials, and sales force automation. Under my lead the business grew from nothing to eight figures ARR.

Supported the sales team in pitching new business, preparing proposals, and managing client engagements for Fortune 500 companies.

My friend Thuyen Nguyen thought that between us we could be the "Peter Norton of OS/2, the Windows killer from IBM. Things didn't work that way, but it's a BIG book, and the os did have a long run in some sectors where a real time kernel was important. They tell me ours was the definitive work on the subject and that my chapter on threading was particularlly fine.