Dougma (dŭg·mə) n.

A dive into needs and wants and whys.

Also see:

• Introduction – Lets make a bug tracker!
• Background – It’s not really a bug tracker!

Time to get to some use cases, requirements, needs, wants, and technology. As mentioned in the last post, I need something to replace the features we currently have in Lotus Notes. While this is a project inspired by issues at work, and I hope it will be used there, the actual needs and requirements are coming from me. Not everyone in my group would agree with what I am calling requirements. Some of my requirements are there because of specific pain points I am having, but which do not really bother others. But hey, it’s my project, so they don’t get a say.

With that, it is time for a

Disclaimer: The postings on this site are my own and don’t necessarily represent my employer’s positions, strategies or opinions. Opinions and ideas expressed here are mine and mine alone.

Objectives

The pr1mary objectives are:

• Increase visibility with ease of access (web interfaces or simple app)
• Integrate with other existing systems (Perforce, Plone, Active Directory, release processes)
• Preserve and or migrate sixteen years of history (old bugs, api discussions, etc.)
• Support existing workflows (fast ramp-up for users)
• Minimal impact on schedules (get it up and running without anyone noticing until it is done… hi boss….)

That’s about it really.

High Level Functionality

Quick summaries of the functionality we will dive into.

• Issue/Bug Management – Our needs are very simple, but specific. Multi-Project, RSS, large files, and read/unread markers being chief among them. The biggest issue here is how we manage the forks. Each bug/issue will have a status in multiple forks. There are multiple ‘active’ forks which need to have their status set. As new forks are made, the system needs to know about them. Archived forks are not set on the bug. A bug is not fully closed until it is closed on all forks. Very few issue management systems do this out of the box, though many support similar work flows.
• API/Code Review - Nicely color coded diff of changes to the API with the ability to make comments on the changes, and have multiple versions of the multi-file changes. This is key for the API review. General code review is secondary. This need not be fully integrated into Perforce via triggers. That option would be nice, but for the API review, it would be better to submit a changeset via some script (*cough* upload.py. gee… what ever system could I be thinking of for this….) Essentially we need a way to review patches which are not checked in anywhere. It would be nice to review changes which are pending or already submitted as well, but that is a want, not a need; we have that functionality in another trigger system already.
• Discussion Threads – Similar to a bulletin board, but with thread and read/unread requirements. The key features from Lotus Notes are the overview listing with read/unread status. The ‘topic’ can be changed and is modified over time with a change history. Underneath in the main list view are threaded responses. Everything has read/unread markers. Think of a threaded e-mail archive, where the initial e-mail can be edited with a change history. BBS systems come close but miss the mark on the key requirements.
• Static Release HTML Help/Docs – (sideline work) Technically not something that is in Notes and already exists internally, but we need to integrate with it cleanly so mentioning it. Adding an app to smartly serve up static files are set locations would be simple enough to add and would replace some fancy apache rewrite rules.
• Interview Management – (bonus work) special discussion system for managing resume’s, code problem solutions, etc. Has special permission requirements, and voting (+1, +0, 0, -0, -1)
• Machine Management - (bonus work) very very simple app for tracking who has what hardware specs on their machines. Not asset management. Just useful for when we have budget to get new hardware, or when a bug appears to be hardware specific.

Some of this could be moved into Plone, or just abandoned. Much of the project management occurs in Plone and integrates across projects. Different projects use different tools, but everyone integrates at the Plone level. One restriction on the Plone side is, because many groups are using it, there is a very high barrier to adding new functionality or special customization. Also we do not have the option to go with a cloud hosted solution like some groups, due to our access to medical records. Just the access to such records means we can not risk it.

Issue/Bug Management

Requirements:

• Active Directory Integration
• Perforce Integration (very minimal)
• P4M Fork integration (one bug, many forks)
• P4M Version integration (is the format valid)
• RSS Feed (cheap Plone Integration)
• Large file support
• Milti-Project
• Read/Unread Marking
• Filters (open, closed, owned by, etc.)
• Searchable

Nice to have:

• Strong Perforce Integration, Checkin’s and Changesets (i.e. see the code from the issues)
• Strong P4M Fork/Version integration (does a fork/version exist, active forks, etc.)
• Smart links (turn @34245 into a link to the changeset, etc)
• Colorized source code diffs
• Nice WYSIWYG Editing instead of some wiki markup
• Custom reports, queries.

API/Code Review

There is a different between how we handle the API review than other code reviews. We have a requirements, and proposals. This is can be a many-to-many relationship, but usually is just one-to-one, or occasionally one requirement to many implementation proposals. Sometimes a bug will be referenced as it may require an API change to fix. Often it is a client which will submit a requirements document, which then gets refined.

Requirements:

• Active Directory Integration
• Multi-file changesets
• Colorized changes
• Full and partial change context
• Multiple revisions of a changeset (i.e. one proposal, multiple changesets)
• Requirements document support w/ linkage to proposal
• Change history on requirements document
• Clear history on the changes to the item being reviewed
• Good comment system (duh!)
• Integration with bug/issue system (may just be a hand generated link)
• RSS

Nice to have:

• P4M Integration (submit a changeset from P4M)
• Perforce Integration (Code review of already submitted changes)
• Nice WYSIWYG Editing instead of some wiki markup
• Custom reports, queries.
• Read/Unread markers (this might be moved to a requirement)
• Searchable

Discussion Threads

Discussion threads are interesting in that they closely resemble the functionality in a BBS system, but with some very important differences. The initial topic post is edited with a change history, and then there are threaded comments below. The threaded comments are their own posts. The best way to think about it is your standard mailman archive thread view, but where the author of the initial e-mail can go back and edit their post, and the responses can have different titles. Each entry has it’s own read/unread state. This could be achieved in Plone with a single page with change history and threaded comments except that the comments are at the bottom of the post, do not have read/unread state, and can not be listed as part of an overview tree/list. So they are really nothing like that Which is why it is hard to find something which supports this mode of discussion we are so used to in Notes.

Requirements:

• Active Directory Integration (why do I keep listing this?)
• Multiple ‘boards’ or whatever (multiple databases in Noted language… just call it Multi-Project…)
• Topic listing with responses all in one list, with thread indentation (needs a picture to describe)
• Change history on Topic level posts
• RSS
• Read/Unread Marking
• File Attachments
• Filters (by date, person, etc)

Nice to have:

• Smart links (turn @34245 into a link to the changeset, etc)
• Colorized source code diffs
• Nice WYSIWYG Editing instead of some wiki markup
• Custom queries
• Searchable

Interview Management

This is a fun one. It is just a very simple Notes discussion database (actually all of these except the bug management is just a simple notes discussion database), with some extensions for voting. When a resume is approved via triage, an entry is added with it attached. We vote on resume’s with a comment. We decide who gets a phone call from these votes, and then people are assigned to make the calls. There is a ‘response’ made to the resume with notes from the phone interview. If the phone interview goes well we send out a programming test. We wash and test the response program. It gets posted unwashed as a response to the resume. The washed version with comments and notes is posted as a response to the unwashed version. Then bring the person in for the real full group interview. Then we try to hire that person. Whenever we are done with the resume, it is ‘archived’ with these notes where only the manager can see it. Very simple and a quick app to write.

Requirements:

• Active Directory Integration (blah blah blah…)
• File attachments
• Ability to ‘archive’ entries to be seen only by manager
• Voting by group members (+1, +0, 0 -0, -1) with comment.
• Status (voting, needs phone interview, waiting for program, etc…)
• Assign person to phone interview/code review
• Read/Unread Marking (see a theme here?)
• Filters (those which I have not voted on yet, needs votes, needs votes by person, a few others)

Nice to have:

• Multiple repositories for different groups (call it Multi-Project)
• Colorized source code?
• Nice WYSIWYG Editing instead of some wiki markup
• Searchable

Machine Management

It’s just a simple table with change history!!! Bah, create a Plone page and be done with it! Why is this still in Notes?

The Big Picture

Really everything currently in Lotus Notes, sans the bug tracker, is based on the basic Notes discussion database. It is best to look at all of these existing pieces of functionality and see if the lines drawn between them are real or artificial. What I mean by that is, much of the code commentary need not be done in discussion threads, but instead as part of a generic code review application. The distinction between API review and code review is important due to who gets input and when, but not much beyond that. The discussion threads are a catch all for many different types of design resolution that do not fit in the API discussion, or the bug tracker. Plone is most likely the best place for much of what is currently in the discussion database, with the code, and file format stuff moving to a code review app. The machine management database is nothing but a poorly implemented Plone page with a table. The real things which are needed are a strong issue tracker, a powerful and configurable code review tool, and a very simple voting app for resume’s (another voting app? *sigh*).

So next up is evaluating existing technologies to figure out which fit best, while taking into account both the background and the big picture. Just in time for me to go back to work in a few hours too… So much for getting it done over vacation. Failure #1 took long enough. 

In the introduction I covered the concept of blogging a new project from beginning to end. The reason for the vagueness of ‘project’ and ‘experiment’ is because I have not even decided on a name for the project yet. That is part of the entire ‘from concept to end result’ thing. If I had a name already it would not really be from the beginning now would it.

Now it is time to give the concrete context in which this project is being done. This could be considered the pre-requirements. It is important to know how your project is going to be used and the environment it is going to be used in. If you want your project to succeed, this information is crucial. this is where you find out what is really needed over what is requested; especially when the person declaring what is wanted is yourself.

This is going to be a very long post, but I will be touching on almost every sentence later on as this all needs to be taken into consideration. It is crucial to looking at these big picture issues when designing some tool or application which will be used in that context. To properly understand the why behind decisions I later make, I would rather dump it all here and refer back later. I hope it will be interesting to some at least.

As the background for this project is going to delve into the processes and development procedures at my day job, it is time for a,

Disclaimer:

The postings on this site are my own and don’t necessarily represent my employer’s positions, strategies or opinions. Opinions and ideas expressed here are mine and mine alone.

Who we are

My title is ‘Principal Research Engineer, MREC’. “MREC” is the modular speech recognizer project. We are a development group within research, in charge of productizing the algorithms and features needed by our extensive research teams, and deliver a core speech recognizer. We are a small team of 8 developers. There are many internal clients with technology built on top, and we are not the only engine in the company. Everyone on the team wears many different hats. We are all developers, researchers, operations engineers, QA engineers, release engineers, technologists, and much more. Everyone works on everything, down to the build, release, deployment, and source code management tools. No one is irreplaceable.

How we Work

There has been a wave of ‘agile’ going through the company which I personally find both invigorating and frustrating. At issue here is that we are really talking about ‘agile-but‘ at best. What is frustrating is that our team has been agile sense before agile existed. We release often, and not all releases are used by all our clients. Some are only really used by our team. Most often releases are only used by our researchers, and never see a product. A release is made either because we would release on a date (irregardless of what is in the release) or because a feature or set of features were just completed. It has always been that way.

We do mainline development with continual integration. That is we have one single branch which all the work is done. When a major release occurs we fork the project, and the newly created fork is a maintenance fork which only has bug fixes. Any bug fixes are first implemented in the mainline and then back-ported to the forks which we determine need it. We try to only keep one or two forks live; which means sometimes forcing clients to upgrade to a newer version even when they only think they care about a single bug affecting them.

Notice I have not mentioned branches or branch development. We don’t do that. Check in, and check in often. Update with the mainline multiple times a day as needed. All tests must pass before checking in. Every bug is really two bugs, the bug and the missing test for it, both must be fixed to consider the issue resolved. This may sound like it slows down development, but just the opposite is true, and I would never work any other way now. We do have the ability to branch and work in isolation, but we prefer to keep that type of thing very short, and to be honest I can’t think of a time it has been needed. The point is not that you need to integrate with other people changes, but that you need to get your changes in to the mainline immediately so that everyone else can integrate with you.

There are code reviews. We only implement what is needed to solve the underlying problem or request. We do not implement what is requested, but what the requester needs, and rarely go beyond that. We do not implement features that are not used. We love to remove code and unused features. Over the past sixteen years we have removed three times more code than the current size of the project. We have competitions to see who removed the most code. That is the only code metric we look at with any seriousness. Our client facing API is reviewed by the entire team and all clients, and is approved before checked in. The documentation for the API is in the API headers. We bikeshed on the API endlessly; or at least it sometimes feels that way.

None of this should look surprising, revolutionary, or out of the norm. All the major open source projects I know of work this way; more or less.

Communication is the Problem

As I said, there has been this wave of ‘agile’ in the company. Recently someone said to me, “I saw this months sprint document for MREC. It is great to see that MREC is going agile too!”; and I bite my tongue. I want to say, “You keep using those words. I do not think they mean what you think they mean.” When a term like ‘sprint’ is used is does not have the meaning I expect it to have. Let me be clear here: the problem is me, not everyone else. The problem is not inherit in the systems, but in the communication. My communication and the communication between our group and the rest of the company.

Our group has been operating somewhat like a black box. Different clients would file requests and our manager would work with the clients and put together a general schedule for getting features in, and re-prioritize as needed. This is a group effort to figure out what needs to get done and in roughly what order. Our clients do not talk much to each other for prioritizing our work, as we do the prioritizing. The end result is, while we have advertised what we are working on, and what goes into a release, these things have been very hard for our clients to track. They know when a feature they need is in a release, but then they have to accept all the other features for all the other clients, which they have not been tracking. One could argue that this is not our groups fault, as we do make all this information available in one form or another; but that is not really fair and as we will see ‘one way or another’ hides a multitude of sins.

Communication is the Solution

Much of this is old news and we have changed much in what it appears we are doing. In truth we have not changed the way we develop at all. We instead are exposing what we are doing and allowing our clients more control over our priorities. The end result is that while there is no real change in our priorities, our clients understand them much better and feel like they can predict things better using agreed upon terms like ‘sprint’. In truth it is just a change in perception; instead of not reading internal web pages and e-mails with text attachments, they are not attending meetings, not not reading different internal web pages, and not reading different e-mails with excel attachments. But these are meetings, pages, and e-mails they asked for and we designed together, verses things our group dictated; which makes all the difference in the world. Yes, I am being hyperbolic.

Even with this added communication, which is real and effective, there are still problems. They center around our tools and environment. We are in the late parts of migrating to new systems, but all this has done is highlight the flaws and weaknesses in the systems we have yet to migrate.

The Environment

The different teams have different development styles which best fit their needs. Same goes for the tools used. The source code management we use is an in-house wrapper on Perforce called P4M. This is open sourced as part of the DevTools project; which is woefully out of date and we will be releasing a new version of soon. We have multiple projects hosted on a single server. Our team has four projects including MREC, and other teams have projects as well. P4M enforces a directory layout including forking and branching. We choose Perforce over SVN or a DVCS for many reasons. We need to deal with huge files (>2Gig) and a basic install takes up >32Gig. The MREC tree alone has 300GB of history. We need to be very careful of permissions. Our engine is used in many medical transcription applications, so we must be very careful. We try never to check in unwashed data which might contain any PII. In the off chance that some does get through we need strict centrally controlled permissions. At any time we need to know who has what on which machines. For patent and litigation reasons we need everything centrally managed with strict backup rules. Perforce really is the only affordable system out there which can handle this. The entire 16 year history of the project is maintained and with proper dates and attribution.

Our project planning is managed external to the source code management, and the bug tracking and issue management. This at first might sound odd, but with so many internal clients, the priorities are often changing. In our issue management system, we have 3 severity levels (low, med, high), and a fourth level called ‘request’, for all features and improvements. Requests are automatically lower than any bugs. This has caused some friction with client, especially research. The problem is, the person filing the request really has no clue what the real priority is for a request. That is unless they are a project manager and have consulted all our other client product managers, and want to take on the task of updating the priority over time. As such the real priorities are managed in another system which links back. Known bugs on the other hand are always more important to fix than a new feature or improvement. This is a royal pain to try to communicate, and still results in heated discussions; we will get to this in a later post.

Releases are made to network directories which are accessible from the same path on all our grids. There is a ‘current’ symlink for the latest supported version, the version is always increasing, and the directories are named with the version number. Each checkin to a codebase get’s its own unique increasing version number (managed by P4M). The release includes built static html documentation. This documentation is served up by an apache instance, or can just be accessed directly. We are migrating away from a hodge-podge of doxygen, pydoc, and other inhouse hacks over to a standardized sphinxdoc system. this includes taking the help from our API headers and generating sphinxdoc which is cross references with our Python interface. The overarching project planning, and release information is in a plone instance which is used by all of research and development. This is all magically cross linked and searchable; or will be once the sphinx stuff is done, some of which will be tackled by this hear project. Our sphinx extensions will be released as part of DevTools, and some of the release exposure stuff will be dealt with this new project.

Lotus Notes

There are some pain points which have been hitting me over and over again now that the other parts are so much better and fully integrated. Specifically the way we review changes to our API, discuss architecture and format changes, and issue tracking. All three are managed in a 16 year old Lotus Notes system which has not changed much in 10 years. Very few groups in the company still use notes, and most can not be bothered to install the client. Most have other tools for these things which have web interfaces, or similarly, are causing communication problems. Requiring a tool like Lotus Notes does not sound like it would be much of an issue at first, especially as Perforce is required for code access. But when you realize that this includes a new e-mail address which is not integrated with your ‘real’ exchange address, and you need help to set it up to make sense, and that we have no IT staff which know or understand Notes, nor a support contract; heck for all the nice things we have in it, I don’t want it. There is 0 chance of getting a web interface as well. In short it is an isolated island which plays well with it’s self, and can be linked to externally with some contortions (on windows only, with specific OLE/ActiveX plugins), but does not play well with others; and playing well with others is the point.

I do want to give a shout out to Eric Ochieng who set up the Notes infrastructure years ago and which has been working flawlessly sense with no real support or maintenance.

What this project really is

This project really is not a bug tracker. What it really is, is something to replace all the functionality we currently have in Lotus Notes, with other things which integrate into all the other things we do. Part of that is indeed issue tracking, but focusing on just that would be a failure from the outset. We could go with something like CearCase+ClearQuest+Replication+Send-All-Our-Revenue-To-IBM, and spend months trying to get it all working, but that is just silly. There are a number of open source and pay for solutions which almost fill our needs. It is that ‘almost’ which is the problem. There is nothing out there which does the things we need, let alone cover the things we want. This project is to dive down into what the real needs are verses the wants. Find the solutions out there which come closest while integrating together and with what we already have. the pieces which are still missing, I will create from whole cloth of some type. Python is not a requirement, but I will be leaning towards it, as I am the only person on our team which knows Ruby or Java well enough to support those languages; we are allergic to .NET for reasons I will go into later.

Up next: The Big Picture – a dive into needs and wants and whys.

Ok, maybe ‘grand’ is a bit much. For a long time now I have wanted to blog a project. That is blog the progress of working on a project from initial concept all the way through to the completed result. I wanted to do this for the old PyCon website, but the time pressures for that work did not allow for it. I have yet to write one line of code, or create the code repository, or anything; though I have been doing continual research for the past eighteen months. To be honest I have no time for this new venture, and no way on earth do I have time to blog it. I will be spending twice the time blogging it as coding it. Thus this is doomed to failure. But that is part of the point.

The point is not to watch as some ‘master’ weaves a new project and does things in the ‘best’ way. It is not for me to impart some special wisdom. Oh, no… The point is for me to fall on my face. Hard. Repeatedly. In full view of everyone. When I see something done right I rarely learn anything from it. The most revolutionary concepts often go completely unnoticed because they just work. And no one remembers things that just work; until they don’t. So this ‘Grand Experiment’, I hope, will fail many times over.

Another reason why I have not done this before now, is that I have not really had a project which will work with this concept. Oh I have some small utility projects (django-app-plugins chief among them) which desperately need my attention, but I am not actively using them for anything. I have found that when you work on a project like that without an actual site using them, something driving the development, you end up having to envision how you would like to use it. Then when an actual use case comes up it does not quite fit what you thought you might use it for. So this is going to be driven by real use cases for a mission critical application which will be used by a small development team.

How the blogging will work.

There will be an introduction (i.e. this post), background post, big picture post, and then breakdown posts. the breakdown posts will cover the work as I do it. There will be no overarching organization beyond whatever I have had time to do and get checked in. The breakdowns will cover the work which was done in the interim commits, and or new use cases. Each use case will also include research done on options on implementation details. Things which do not work will be highlighted. Even things which do work will not work perfectly. The entire reason for this project in the first place is because nothing in existence works well enough.

So why now?

Good question self. Well there has been a pain point at work which keeps coming up. I have a mandate to specifically NOT work on this. I also am on vacation, and have not done any programming for me. But I have seven days, a wake, a funeral, games night, home owners association management company migration, PyCon issues, three parties, two kids, and a none to happy wife. Did I mention that I do not have time to do this?

So why blog it at all?

Another good question self. Because doing this in public will produce better code. At the last Django Meetup it was commented by someone unnamed that they produce much better code when it is open sourced than when it is done for work, or just to scratch that itch. Everyone present agreed that it was the case for themselves as well. And finally, by doing it this way, it is clear that while this project may end up being used at work, it is done by me, on my own machines, on my own time, and is completely tangent to technology my company cares about. It is related to another piece of software which my group at work is already open sourcing. Oh and the entire falling on my face thing… that is just too much fun to pass up.

So what is it?

It’s a bug tracker.

Wait WAIT!!! come back… don’t stop reading!

The background and overview posts will go into the research behind all the alternatives, and this project will be more about leveraging existing technology, extending existing projects, writing the few apps which are needed to fill in little bits, and more than anything else, gluing it all together. The emphasis will be on the use cases and work flows which our group uses and dealing with less than enjoyable requirements. I do not even know if this will be used by my group at work in the end, but that is not really the point after all. There is going to be sphinx, django, jquery UI, rietveld, Perforce, DevTools, and much, much more. I was told specifically not to work on it; which has almost the same effect as telling me something is impossible.

So there are two new computers in the house. One is my new MacBook Pro, and the other is Josh’s new XO. Josh and I were going to share the XO, but to date I have spend a whole 15min on it.

Read the rest of this entry »

Well it has been a 10+ year wait for some and a ~6 year wait for me, but there is finally a Dragon Naturally Speaking TV Commercial! It’s just being shown on some basic Cable channels (CNN, Discovery, History, Fox ***). There are not that many spots purchased, but it’s something! I remember being told back in 98 that we would have a commercial for VoiceXpress, never to see it happen. I was more than a little jaded when it was announced internally a year ago, that it was finally going to happen. It is a little surreal to see something that I have worked on (that is not Open Source) hawked on TV. Now I am am just hoping we can get a GOOD commercial for the product, I would settle for merely not bad at this point.

My god, I wish I had something good to say about this piece of advertisement. Lets decompose.

1. The product

They somehow took a product that is fun to watch people use, and has a very cool, minimal, embedded interface, and made it a chore to watch. Worse yet, they misrepresented it’s capabilities. It works better, faster, and easier than is portrayed. It is a continuous speech recognizer, why is that kid talking discreetly (one word at a time, and slowly?). It looked like he was using Kurzweil Voice or Dragon Dictate from 1995! Even the executive is talking as if he is reading a cue card (which is most likely the truth of it). This software is used by stenographers in court rooms. The fastest speaker can be recognized. I thought the most precious thing in a commercial was time? Why is there so much filler?

They never actually show the software clearly. The dragon bar is just a yellow blurry blob on the screen. Granted you can hide the bar, but the end result is, the system appears to be very slow and unresponsive. Even the cute typing text in the add is a misrepresentation. We do not send one letter at a time to the screen; that would be annoying after 2 seconds, not to mention slow. At least the womans use of the product is a little closer to reality. Oh and yes, you have full command and control over your PC ala Star Trek, but by saying ‘listen to me’ and ‘stop listening’ instead of ‘computer’; though you would never get that impression.

2. The script

Wow. I mean wow. When it comes to emerging trends, technology, and what the ‘hip’ kids are doing, our upper management is fairly on top of things. They also understand the products they sell at a level I have not seen at any other company. I guess the same can not be said of our hired marketing firm (or whoever produced this thing)! The things wrong with the script (from both a technical and substantive perspective):

• The woman writing an e-mail: Even my Mom knows what a signature is and how to set her mail program to include it automatically. Who in their right mind would use a voice macro to do that? There are much better ways to show off macro’s. And form filling would be better for multiple signatures. That is a killer feature!
• The history report. I know adults think teenage boys are stupid and cannot write a decent report, but this poor actor must have been choking back bile when he saw this script.
• The IM interaction. This is just abysmal: ‘Are you in’? Every IM client from hour 0 has had the ‘away’ feature, so yes, he is ‘in’, you know that already. I guess ‘in’ is the hip new lingo all the kids are using these days.
• The executive. This is how a teenage boy pretending to be an executive talks.

3. The acting

All I can say is I really hope we got a good deal here. In some cases I think it is the material. There is not much you can do to make it palatable, so why waste the effort. It is a cut rate commercial for a few basic cable channels after all. What is interesting is we have many commercials for our vendors and resellers, and the acting there is top notch. You can find most of those on youtube, or on our website (though this is a demo, not a commercial).

4. The Direction and Cinematography

Ok, its a commercial. The sets were believable. the lighting spot on, the sound perfect, and the basic camera work was good. But please show the product. You never got a good look at what was going on, on the machine. The product is supposed to be the star of the commercial. Here it appears to be a character off screen being talked about.

What would I have done?

Well I would do a rip off of the HP ‘talking hands’ commercials. This was actually my idea back in 1997 when I first started working with speech. Show the apps swapping around like you do in real life, only by voice. Show the real speed of the product. show the people, but not their heads. Show their feet propped up on the desk in front of them. Put the product first, and make it interesting. Have them standing there, and the transparent screen in front doing all the cool things they do in the HP commercials, only they have their hands behind their back. Show people really using the product, not selling it. I guess that is why I am an engineer and not in marketing.

Additional Notes:

No you do not need to speak punctuation. There is auto-punctuation, but before it is accurate the system needs to have been used for a number of hours to collect enough statistics on how you use punctuation and inflection. Having DNS inspect past e-mails and documents can help, but gathering the inflection data is the key part. For that reason it is turned off be default. More research and data will fix that.

No you do not need to spend hours or even minutes training the system. You can use it right out of the box, and it will get better with time. To be honest the learning curve is more on the user end, than on the software end. Talking to a computer is just like any new means of input, like cell phone SMS tapping, or pen tablet. It takes time to become comfortable with it, but not as much time as other input devices.

This blog post dictated with Dragon Naturally Speaking 9.5 Professional.

I have not had much time lately to make posts, but one issue has risen to the top. At work we are hiring.

This is nothing new really, the jobs listing is 5 pages long for our Burlington Ma. office alone. What is different, is that the group I work in is hiring. That would be the MREC (Modular Recognizer) Group, which does the development on the core speech recognition engine for a multitude of product lines, including Dragon Naturally Speaking, Mobile Solutions, and Medical Transcription Services to name just three. Yes I know the ‘demos’ suck, you can search youtube and find better examples of the products.

The Core MREC team is has always been a small core group of less than 10 engineers working with research and the product groups. Speech experience is not a requirement (and is actually the exception) for our group. We work with research to develop new features and productize new algorithms. The work is primarily C++ on windows and linux. The code base is the cleanest one I have ever worked on (and I have worked on over three dozen in a number of fields). The code is not old either, as we are continually rewriting parts of the engine, removing obsolete features, and adding in new ones; that is where the ‘M’ in MREC comes into play. Python experience is a big plus. The primary research framework is all python and the core engine is instrumented in python.

If this sounds interesting to you, send in your resume, either via the official nuance form, or by e-mailing me (doug at this site). You can also ask questions in comments to this post.

This post was dictated directly into wordpress using Dragon Naturally Speaking 9.