Bluyah Development Blog

It’s really strange.  It seems like every start-up CEO I meet lately is sitting on a nice little war-chest of cash.  Flush from a recent A-round, or having just cashed in their freshly-vested Amazon stock options (at a strike-price that would make a grown man cry, no less), all seem extremely enthusiastic about their latest venture (as they should) and — oddly —  seemingly unconcerned with how they’re actually going to make money as a company.  Sure - I know making money is in each of their business plans.  But it’s not currently a necessity.  They have cash to operate.  They  have freedom.

Don’t get me wrong —  I don’t begrudge any of them one iota.  I wish them the best of luck.  And I fully believe that within the next two to three months (or four), we’ll be sitting pretty right beside them, having attracted the right investor(s) who believe as much in our vision for Bluyah as we do.  But all of that good will and optimism about our own future doesn’t change the fact that recently I’ve been feeling …. well ….  a bit “stuck.”

Watching my boys play outside this evening, it finally dawned on me exactly what I’ve been feeling “stuck” about.  

You can play after your chores are done

From the first through the third grade, we lived next-door to a family with 8 children.  Their 4-bedroom house sat on about 2 acres of property right in the middle of a subdivision of smaller houses on quarter-acre plots.  The family grew all of their own food in a massive garden, had chickens for their eggs, a cow for milk, and a pig —  I’m not making this up —  named “Bacon.”  Needless to say, the family was a bit of an oddity in the community.  And the middle son, Alan —  who happened to be my age —  was my best friend.

Every day after school a gang of us would tear home on our bikes, check in with our mother’s, then disappear into the nooks and crannies of the neighborhood, exploring every square inch of that desert town before the sun began to set and a gaggle of moms would begin calling us in, one-by-one, for dinner from the front porches.

And nearly every day after school, Alan would check in with his mother only to hear: “You can go out and play when your chores are done.”  In all of my recollections, I can’t seem to ever remember him being outside with us on any day except Saturday (the younger boys of the family were excused from chores on Saturday afternoons).

Seeing my boys playing outside this evening it finally hit me:  I think I now know what Alan must have felt all those years ago, watching the other boys tear off on their bikes while he went off to the chicken coop to gather up eggs.

The Uncertainty of Support

I’ve mentioned it before.  Currently, we pay our bills by doing custom development work for local companies. It’s a great way to fund development of our Bluyah application.  And it introduces us to facets of IT and all that that entails in a way that under other circumstances we would not have the opportunity to witness.  In short — it reinforces on a near-daily basis the need there is for an application like Bluyah.

But having an on-going service contract, or an on-demand support agreement with a set of customers has a way of skewing your priorities.  In short, your customers’ priorities become, as they should, your priorities.  And their emergencies become your emergencies.  And your development cycle — when push comes to shove — takes a back seat to your client’s development cycle.

Jon, one of our rock-star developers, often jokes about having to “do the chores” whenever I assign him a client development task.  And he’s right.  They are chores.  The work needs to be done — and be done well — but they are chores nonetheless.  In essence, we’re stuck inside doing all of the necessary work for our clients so we can keep the lights on and the Bluyah development cycle moving forward while, it seems, all of the other Seattle start-ups are outside playing in the sun.  If I were eight again I’d probably scream “It’s just not fair!”  

But I’m not.  

I’m 41.  I’m about a decade older than most of the other CEOs making pitches to the VCs.  I’m reinventing our company (and, I would suspect, myself to a certain extent) at an age when most people are settling in.  I’m doing my damned best to run a company that I think has a serious shot at making a meaningful impact.  And at this stage of our young start-up life, as far as I can tell,  that means that we have to do everything in our power to ensure we get to keep playing the game.  

And that means: until an investor aligns with our vision for Bluyah, we’ll keep doing our chores.

---

---

There is a never-ending stream of information on the Net about how to start your new company, or things to watch out for when talking with investors, or even how to properly shake hands if you’re an entrepreneur.  But there doesn’t seem to be a lot of day-to-day insight from the trenches.   With that in mind, I thought I’d start sharing some of the more mundane things we’ve been doing.  Maybe it will resonate with an entrepreneur out there.  At the very least, it will help me keep better track of our new company’s history and day-to-day operations.

Monday Morning Huddle

We do it every Morning at 9:30.  Don’t bother calling at this time - we won’t answer the phones.  It’s an “All Hands” meeting and the agenda is dead-simple.  Each person in the company talks about what they did last week, what they are planning on doing this week, and any roadblocks to success they may face.  We order it by Department as follows:

1. Sales and Marketing.
2. Development and Production Support.
3. Financial and Executive

The goal is to keep the meeting to under 30 minutes.  With only 5 people currently, we’re usually able to keep it under fifteen.

Running the meeting this way accomplishes several key goals:

1. Every member of the company knows at a high-level what is going on with every other group in the company. 
2. There is no ambiguity about what we as a company are working on, or what our priorities are for the coming week.
3. Everyone is aware of any roadblocks other individuals may be encountering and can provide insight or assistance.

Like I said, we do this every Monday.  So, the obvious question becomes: what did you all discuss today?  Here are the highlights.  Just a warning: I won’t name companies we’re talking with here for all of the obvious reasons.

Today’s Meeting Notes:

Sales Stats: Adam had several meetings last week with potential clients, one with a potential strategic partner.  DEV needs to provide an estimate on integrating with potential partner’s product before we can move forward on licensing negotiations.  3 sit-down meetings planned this week.  Needs to make more phone calls and emails to “fill the hopper.”   Sees a trend emerging in discussions: companies want to see more analytical capabilities in the tool.

Development Stats:  Dev just finished up code for client release (we do custom development for various companies to fund our product development).  Currently prioritizing development activities for Bluyah.  It was to be: Sharing, Online Invoices and XML Post processing - but given feedback from Sales, release 1.1.1 will now be:

1. Connector and View/Spreadsheet Sharing
2. Online Invoices
3. Pre and Post Filtering, sorting, basic analytics (to include much improved charting capabilities)

Financial Stats: It looks like an SBA loan is out of the question - we have no tangible assets to put up as collateral, and even if I put my house up, the loan amount we could get is well below the financing we need to execute on Phase I of our business plan.  CFO has a talk with a major local bank this week to talk about other loan options.   Additionally, we’re assembling a list of Angel Investors to whom we have referrals.  We need to finalize the Go-To-Market plan before we can call this group, however.  Which means we need to know a whole hell of a lot more about our pricing model margins and associated costs when under stress.  Follow-up meeting scheduled later in the week to work through break-points in the revenue model.  Lastly - as much as we hate to do so - we simply can not financially afford to execute on the excellent marketing plan that was presented to us by a colleague last week.  It’s up to me to figure out how we can get them to deliver the Marketing materials in “phases” that can coincide with when we hope to see the first round of financing.   I always get the fun jobs.

---

---

One of the things I love about Bluyah is how quickly it can solve a variety of feature requests made of an application.  As an IT professional, I’m constantly weighing the time it will take to develop an application feature against the benefit that feature will provide to the end-users.  In some cases it comes down to simple math: will it cost our company more (in terms of a developer’s salary) than this feature will return (in terms of revenue)?  In other cases it’s much more subtle - especially when dealing with web properties that don’t have a straight-forward revenue model.

Case in point: Pif Magazine (www.pifmagazine.com).  

Pif Magazine has been online for nearly 15 years now.  It is one of the oldest, continually published literary journals on the Net.  It has published original works by well-known authors like Julia Slavin, Amy Hempel, and Poet Laureate  David Lehman.  It has also introduced countless unknown, previously unpublished authors and poets who have, because of their exposure in Pif, gone on to land contracts with traditional publishers.

In short, it’s an important venue with a very dedicated following.

One thing it is not, however, is technologically up-to-date.  The content management system used by the editorial staff is a highly customized version of PHP-Nuke 5.2 (codenamed: SIDney), which was deployed in the spring of 2001 and, save a few minor visual enhancements, has not been upgraded since.  It may sport a robust publication contracting system, but it lacks basic modern features. 

So when the editorial team recently asked me to add RSS capabilities to the site so they could syndicate the newly published articles, my first reaction was: “Well, there goes my weekend.”  Then, just as quickly I realized: “Hey - I can do this in Bluyah in about 3 minutes.”

Step 1: Getting the Data

This first step is always the most difficult.  Every application has it’s own database schema and SIDney is no different.  Only with SIDney, the schema is complicated by the fact that author information is (for historical reasons) stored in a separate database from article information.  In addition, the author’s email address is stored in a separate table from the author’s first and last name.  Just to complicate matters even more, the SIDney application allows editors to control things like title wrapping with special comment tags.  

To work around all of these inconveniences, I decided that the easiest way to gain access to all of the data bits I needed for an RSS feed would be to create a database view against the articles database and then point Bluyah at this view.

The view structure looks similar to this:

CREATE OR REPLACE SQL SECURITY INVOKER VIEW PIF_RSS_VIEW AS
SELECT
    CONCAT('http://www.pifmagazine.com/SID/',s.sid) AS link, 
    REPLACE("<!--titlebreak-->"," ") AS title,
    REPLACE(REPLACE(s.hometext,"\\'","'"),'\\"','') AS description, 
    s.pubdate,
    t.topictext, t.topicname,
    us.username as email,
    CONCAT(ui.fname,' ',ui.lname) AS author,
    ui.city, ui.state, ui.zipcode
FROM ARTICLE.stories s
    JOIN ARTICLE.topics t ON (s.topic=t.topicid)
    JOIN USER.user us ON (s.uid=us.uid)
    JOIN USER.userinfo ui ON (us.uid=ui.uid) 
ORDER BY s.pubdate DESC
LIMIT 20

Once the database view was defined and created, the rest was a snap.

Step 2: Connecting to the View

In Bluyah, I already had a Database Connection created for the Pif Magazine database.  I just needed to “discover” the newly created view and user it in a report.  To discover the view, I went to the Connect tab, found the already existing connection, then clicked on the “List DB Tables/Views” link in the Action column:
This will bring up a list of all tables and database views in your database.  Finding the newly created view, I clicked on the link “Use in New Report” in the Action column:

This brought me to the Report Create screen that you’re already familiar with from other posts.  Being that the view already contained the column names I wanted to see in my report, I simply clicked the Create Report button and went straight to the Export tab.

Step 3: Creating the RSS Export

I spent the most time on this screen trying to decide what to input into the free-form fields:

Everything on the left-hand side of the screen describes the feed itself, while everything on the right-hand side of the screen describes the individual listings in the feed.  As such, everything on the left-hand side of the screen will need to be provided by you when you create the RSS export.  Don’t worry - if you don’t like what you’ve input into the fields you can always come back later and update them.

For the most part, you can see that the database view I created contained field names very similar to what they would map to in the RSS Item screen.  I did this on purpose to speed deployment - but you could name your columns anything you want to and simply map them to the RSS Item attributes as appropriate on this screen.

Step 4: Embedding in the Website

Once the RSS Export was created, I pointed my browser at the URL Bluyah provided by clicking on the “Get Link” link in the Action column:

As you can see, the results are a standard RSS feed:

     https://richard.bluyah.com/export/rss/89387b6026e5012c6ef9002241319b39

Rather than use the IFRAME embed code provided by Bluyah (above) I decided I wanted a simple RSS icon hyperlinked to the feed instead.  If you checkout the homepage of Pif Magazine you’ll see the feed icon at the top-left of the screen.  

Final Thoughts

To me, the speed at which this feature was deployed to Pif is absolutely amazing.  Rather than spend 2-3 days writing an RSS feed generator into the code base (including testing and deployment), I spent a little over 10 minutes creating the database view, another 2 connecting to that view through Bluyah, creating the report and RSS export, and finally another 2 minutes embedding the RSS image with hyperlink to the RSS feed into the side-nav of the website.  All total, it was less than 15 minutes from “soup to nuts”.  In terms of development costs, the magazine just saved itself roughly $500 - and turned around the feature far quicker.  What could be better?

---

---

Version 1.1.0 will launch on Saturday, May 16th, 2009, during the 8:00 - 9:00 PM (PSD) maintenance window.

This release introduces a major new feature: Presentation exports.  More details, as well as a screencast, detailing how to use Presentations will be coming shortly.

Contents of the release are as follows:

• Sharees are no longer allowed to disable a database view from being used by all users in the account when that connector is shared to them. [Ticket #205]
• Sharers can now limit sharing to specific database views or Google Docs spreadsheets, without the need to share the connector itself.  In addition, connector sharing has been moved from the Connector Edit screen to the DB Views/ Google Spreadsheets Details page, in order to be more intuitive.  [Ticket #203]
• Enhanced the Professional and Enterprise accounts so that all communications with Bluyah are over SSL for these account levels. [Ticket #40]
• XML Connectors now allow optional username and password.  So if you wanted to connect to your Twitter account timelime, you could do so with Bluyah, then export that data into any export format you choose. [Ticket #224]
• Fixed bug in Map Export that would prevent 1st item in pop-up bubble from being displayed if the element name contained a space. [Ticket #268]

---

---

Version 1.0.2 of the Bluyah application has been pushed to the production server.  Changes in the application include:

• Generic XML Connectors (I can hear the applause).  This has been our most-requested connector type for the past 3 months and we can say it’s finally a reality.  To walk you through how you connect to an XML feed and configure it for reporting, please see the excellent video tutorial Mike has posted.  It should answer all of your questions.
• Report against Database Tables.  Up until this release, DB Connectors only discovered pre-defined database views.  Now we’ll show you any tables you have in your database as well.  Report away!  [Ticket #216]
   
• Fixed an issue where charts would time-out if non-numeric data was encountered.  [Ticket #84]
• Column sorting has been added to Connector, Report and Export lists.  This allows you to more quickly find the item you’re looking for via sorting by name, date, or source. [Ticket #125]  
• Better visibility to default Exports.  Did you know every report you create can, by default, be exported to html, xml or csv format?  No?  Well, not to worry, we’ve now made the URLs for each of those formats easier to find.  Just navigate to the Export tab and you’ll see what we mean. [Ticket #179]

---

---

We’ve been working laboriously on a new connector type for Bluyah: XML.  On the surface, this seems like a very simple nut to crack - we’re already parsing RSS and ATOM feeds, both of which are XML-based.  But the truth of the matter is, it’s becoming more complex the deeper we dig into it.

The problem is in the XML format itself.  XML can be anything it’s author wants it to be.  It’s self-describing, sure.  But it’s not pre-defined.  In other words, there is nothing within the structure or definition itself to tell you that in the following snippet, the ‘row’ element should be treated as the rows of data to be reported upon, with the sub-elements to be treated as ‘column’ data:

<report>
    <head>
        <title>Fremont Pizza Parlors</title>
        <records_found>2</records>
        <metadata>
            <parlor length="32" source="name">Parlor</parlor>
            <street length="64" source="street">Address</street>
            <city length="64" source="city" />
            <state length="2" source="st" />
            <zip length="9" source="zip_code" />
            <phone length="10" source="telephone" />
        </metadata>
    </head>
    <data>
        <row>
            <parlor>Piecora's New York Pizza</parlor>
            <street>1401 E Madison St</street>
            <city>Seattle</city>
            <state>WA</state>
            <zip>98102</zip>
            <phone>(206) 322-9411</phone>
        </row>
        <row>
            <parlor>Pagliacci Pizza</parlor>
            <street>426 Broadway E</street>
            <city>Seattle</city>
            <state>WA</state>
            <zip>98102</zip>
            <phone>(206) 726-1717</phone>
        </row>
    </data>
</report> 

As you can see from the above sample, the data we want to loop over for reporting is contained within the ‘data’ element and that the ‘row’ elements are aptly named ‘row’.  But what if they were named ‘places_i_like’?  And what if they were parallel to the ‘head’ element?  How could an application know this without human intervention?

Well … we think we have a way to ‘discover’ the likely candidates and will be introducing that feature in 1.0.2 (See the Product Roadmap for details on several upcoming features).  

A minimal amount of human intervention will be required - but we believe we have a way to drastically reduce the technical hurdles - enough so that the tool will be easily understandably by non-technical users.  

In addition, around release 1.1.0 we will be publishing the specifications for Bluyah’s Basic Reporting Syndication (”BRS”) format, which is based upon Bluyah’s own XML export format (see this xml export for an example).  At that time, the Bluyah application will allow you to create Connectors to BRS formatted data sources as well.

Keep your eyes on this space for more details as they become available.

---

---