The Bird Is The Word
Posts tagged Methodologies
Coding With My Voice
03 years ago
I was exploring some screen casting software the other day and I noticed that Windows 7 has speech recognition. It probably was there in Vista, but I never really played around with it. I wondered how easy it would be to program a “hello world” program while keeping mouse and keyboard strokes to a minimum. I started by starting my voice recognition on my instance of Windows 7 machine.
The next step is to announce to my computer to start Microsoft visual studio 2010. That command is “Open Microsoft Visual Studio 2010”
This is where it goes down hill for me. Visual Studio 2010 doesn’t have voice support for actions. I tried to say something like “File > New> New Project” but Voice recognition just ignored me. The second approach was to remember what the shortcut was to start a new project. Since I know it, I said to my computer “Control Shift N.” Soon after, I was presented with the New Project dialog. Another painful experience. I had to tab my way to a new project, and tabbing with your voice is not fun. Below is a play by play of my tabs.
Not exactly fun. The next step was to get into the code. I cheated here and had to click into my code. After some painful, painful, painful yelling at my computer I got this code. It took me about 10 minutes of backspacing, and fixing things to get a simple application.
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World");
Console.Read();
}
}
So you might be thinking, why would anybody do this?
Well I started thinking about scenarios where programmers could leverage their voice to program. Before we know where we want to go, we have to know where we are. Obviously we are not very far when it comes to programming with your voice. Below are some things that need to change for developers to start programming with their voices.
Context Switching
Programming languages are created to crudely mimic human language. A phrase could mean two different things to a word processing application and a development environment. Theoretically, when I enter Visual Studio my voice context should be switched to a developer context. This means that voice recognition is listening for different keywords to perform functions. Below are some examples of actions that could be present in a developer context.
- “Add New Class”
- “Add New Project”
- “Lambda x comma s executes s equals x” (x,s) => s = x
- “Console Write Line String Hello World End String”
- “Select Current Method”
- “Select Class”
- “Rename Function/Class/variable”
- “Comment Above Line ….”
In addition to knowing actions in this context, the voice recognition could know you programming preference and make appropriate decisions for you. This is primarily for casing variables, functions, and classes. When you say “Calculator Service,” The voice recognition should know that you mean CalculatorService.
Programming Language Hooks
The voice recognition software should be able to recognize keywords and namespaces of the programming language you are using. So if you say a class name, the voice recognition software should know if you are creating a new class or talking about an existing class. This approach could be achieved two ways: create an API that the voice recognition can call in an IDE, or create a dictionary that you could place into a location for the voice recognition. Either way, you are building an API to allow developers to extend the voice recognition for their particular programming language.
Fingers-Voice Hybrid
Right now you are able to type while you talk to your computer. I would expect that you could do the same when programming with your voice. Some things just might be faster using your fingers.
Conclusion
These are the first step to voice recognition for developers, they are obviously large steps to take. Clearly the current voice recognition in Windows is made to server the greater population of users, who are interested in word processing, email, and chat applications. It would be great if you could take the voice recognition in Windows and specialize it to be used with Visual Studio and other IDEs to boost the efficiency of developers. Microsoft, I hope you are listening.
DDD, BDD, TDD…. What’s the Difference?
13 years ago
For me software development has become more than just writing code, although ultimately that is what it’s about; a developer writing applications that work and serve a function. As I’ve progressed through my development life, I have picked up techniques and methodologies to help me develop a better application. Some of these techniques are Domain Driven Design (DDD), Behavior Driven Development (BDD), and Test 
Driven Development (TDD). Jeez that’s a lot of D’s! What’s the difference between all of these methodologies and when to use them? Well I’m about to tell you where they fit into my development ecosystem. Again, this is where I’ve found these methodologies to work the best for me.
Domain Driven Design (DDD)
I’ve always thought of DDD as a mindset rather than a code writing methodology. DDD’s main focus is create a dialogue between developers and the domain they are attempting to develop in. For example, if I were writing a blog, then my discussions and inevitably my code would include words like “posts”, “tags”, and “categories”. I’ve always found DDD to be easy for developers to understand. It doesn’t require any tools except for a good whiteboard and some developers willing to talk to each other and their business partners. Below are the necessities that I perceive to properly implement DDD.
DDD Necessities:
- Whiteboard
- Open dialogue
- Domain experts
- An open mind
Behavior Driven Development (BDD)
I use BDD to express my application’s intent (with code) within my project. The specifications are written using stories and scenarios, and it is my job to make sure that those stories are true through functionality. BDD is cool because intentions are visible, and all your BDD stories are written in English that is understandable to your domain experts. BDD and DDD are tightly interlocked because your stories will most likely come out of your DDD sessions with your domain experts. Below are a overview of the tools needed to implement BDD.
BDD Necessities:
- BDD Framework (For .Net : MSPEC, StoryQ, SpecUnit.Net, SpecFlow)
- Story (Test) Runner
- Discipline of Steel ( the most important thing)
Test Driven Development (TDD)
I still use test driven development, but in a different scope. TDD has turned into my debugging approach of choice when dealing with a client’s code. I attempt to write a unit test to isolate issues. During this process, I can re-factor and learn more about the newly presented code base. Once I can reproduce the bug through a unit test, I can start thinking about what I need to do to solve the issue. This method of debugging only works with code based bugs, and not things like memory leaks.
TDD Necessities:
- TDD Framework (For .Net : NUnit, xUnit, MbUnit)
- Test Runner
- Ability to reverse engineer
Conclusion
As you see above, all these methodologies are alive and well in my development ecosystem and they all play overlapping roles. The thing to keep in mind is that there isn’t a point where I say “I am going to do BDD now!” or “It’s time for some DDD!” These methodologies are applied fluidly but precisely. I cannot stress enough that self discipline is at the foundation of any methodology you use. If you don’t believe enough in the methodology to follow it’s main tenants, then you’ll find yourself undermining your own efforts. At the end of the day, a methodology is a system, a series of steps that you take to develop an application; respecting that system can yield great results.