Sounds like you had success at the trade shows, I'm about to embark on that route too.
Can I ask how you went getting the word out at the shows, and any tips converting to a sale?
Did they mind that it was still an MVP?
The trade shows were a great start. We signed up a few folks right away, and people are still calling us 2 months later.
It was a really interesting story though...
My co-founder and I had the smallest possible booth in the very back corner of the room. Our biggest competitor had a triple sized booth manned with 4 people and 2 42-inch TVs in the center of the room.
We had 5 competitors within a 6 booth radius. Everyone else had a giveaway, huge screens, backdrops, lighting... the works. We had a 60" wide banner, a 24-inch monitor, 2 iPads, flyers and our phones.
These competitors had a decade of experience selling their product and had been to all these trade shows many times. This was our first trade show ever and only had 4 customers.
The first day was OK. Generated some buzz around the hall and had a few people really spend some time chatting.
In the afternoon, I branched out (co-founder stayed at the booth). I went around and introduced myself to about 1/2 of the other vendors. Then, I started walking up to folks randomly around the conference hall. I introduced myself, smiled and told them I was with Gingr. I then asked if they had a minute to chat about their problems with software. About 80% said yes.
I learned that just going out on a limb, smiling, being polite and asking people about their problems really worked. It makes sense IMHO ... everyone wants someone to listen to their problems.
Some were concerned that we were so new and small. I had practiced my spiel for that a hundred times by then. I managed to persuade most. A few had their "IT" person call me the next week. For the most part though, if you understand someone's problem and do have a solution, being new and small small wouldn't be a "deal breaker".
As far as closing a sale goes...don't treat it like a sale! I approached every conversation as just that.
Looks good but is opening a Terminal less techy for my mum? I would argue not. She wouldn't know what a terminal was, other than perhaps something at an airport?
No offence meant by the way. I don't know of an easier way to get the required command to run, so apologies for no suggestions on how to improve it.
I'm interested in the "Version control for data" feature. How does that work? I have data that is still changing in both content and structure. As the test suite grows, it is becoming a burden to maintain every time there is a change to the data. It would be great to be able to write tests against snapshots of the database, and be able to rollback to a different point for each test seamlessly.
From my reading of the getting started guide, it looks like it treats your "working" directory as a git repository, with each run basically doing a commit & push.
This means that your data (in files) needs to be in the working directory, and is versioned along side your code. Sounds pretty cool, but I am not sure how it would scale for large / constantly changing data sets.
siganakis's explanation is correct, with a minor caveat [0]. We do some clever things (diffing, compressing), but if large amounts of data are always changing, the network transfer will take time. We have folks comfortably using Domino with about 50GB of data in their project directories. And it's only the amount of data in the current revision -- not cumulative across all revisions -- that matters. Anyway, if you have a use case with more than ~50GB, let us know, we're eager to engineer a more advanced solution -- just haven't had the need yet ;)
If your code pulls data from a database (e.g., kelv's test cases), one option is to save the DB snapshot out to a file when the code runs. After we finish executing your code, we snapshot all the new/changed files in your working directory (we call those the "results" of the run). Using this approach, you'd have a record of the DB snapshot for each run of your tests. But, again... if your snapshot is more than 10s of GB, the network transfer time could get annoying.
[0] We treat the working directory as a git repo, but since git breaks down with large files, we only use it to track your directory structure; we store actual file contents elsewhere.
Thanks! As I've been creating other examples (yet to be released), I've discovered there are always going to be little quirks with the way you want certain data pre-filtered or grouped, aggregated and then grouped again. But in general my time creating my first board went from two weeks (http://stonefinch.com/Projects/Medicare - 19mb download, it'll take a while), down to 1-2 days, then down to 4 hours. Now with machete I can knock out a new board in less than an hour. I typically spend a lot more time just munging together data.
We switched to C3, and as a charting library it is very nice to use (the declarative approach worked better for us than DC's (and D3's) imperative one) and were able to combine it with crossfilter as well as other libraries for a few missing chart types.
However, we ultimately had to switch again to a solution that was mandated by another part of the organization for IE8 compatibility and internal UI standards.
Working in an industry where Manuals and Policy/Procedure documents dictate, I would also love this.
Eg. in the heavily regulated airline industry, Framemaker still persists as standard. Changes are typically made against a PDF as comments (handwritten or PDF annotations), attached to a paper "Manual Change Request" form and signed by manual owner and passed to a Tech Writer to replicate the change in Framemaker. Turnarounds in order of months are incurred, and where the regulator is involved, I have seen years.
A Git-style version control workflow would work well:
- allowing collaboration
- change documentation and approval is built in (even better if regulator can use it)
- publishing smaller amendments while larger ones develop
- reuse modules across manuals (eg. org charts)
However, uptake will occur when the learning curve is reduced...such as a well designed web UI
