Coding With My Voice

0

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.

image image

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.

image

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.

Jumping Development Niches – Realizing Learning

0

.Net is one of those great platforms that gives you so much value without having to re-learn everything. I recently decided to jump back into Windows Presentation Foundation, to keep my skills there sharp. What I was surprised to find is that it is evolving at break neck speeds, almost to the point of giving me migraines. Obviously Microsoft isn’t moving at this speed to overwhelm developers, but instead to give value to those developer niches. About  5 – 10 years ago Microsoft thought of a developer as a windows developer, creating applications solely for use on their platform. Everything Microsoft made was centered around rapid application development or drag and drop development. This is clearly evident when you look at Asp.Net Web Forms. Since that time the world has evolved, and so has Microsoft’s view of those developers.

Microsoft is developing niches, and although they don’t mind you jumping around from niche to niche, they want to make sure to help those loyal to those niches by continually providing new value in shorter release iterations. This can make it tough, but not impossible, to catch up in a niche like WPF or Silverlight development. So what are these niches? Well they aren’t officially defined, but there are strong lines. There is obviously some overlap, so you might see some things repeated.

p_790886.Net Niches

  • Web Development
    • ASP.NET MVC
    • ASP.NET Web Forms
    • Windows Communication Foundation (WCF)
    • Cloud Computing (Windows Azure)
  • Windows Applications
    • Windows Forms
    • WPF
    • Silverlight
  • Rich Internet Applications (RIA)
    • Silverlight
  • Enterprise Systems
    • Windows Workflow Foundation
    • Office Development
    • Cloud Computing (Windows Azure)
    • SharePoint
    • Reporting
  • Simulation and Games
    • XNA Framework
    • Microsoft Simulators
    • Robotics

These are the major niches as identified by Aqua Bird Consulting. I’m sure there are smaller niches that we’ve missed, but these are the ones that the majority of developers are involved in. So the question is, can you get one developer to know all this stuff off the top of their heads? No, of course not, these frameworks are dynamic and with shorter and shorter release cycles it would be a 24 hour a day job learning it all. So what can a developer do?

I’m No Tabula Rasa

This sadly is what some developers do, they throw up their arms and say they don’t need to learn that new stuff. They believe that Microsoft writes everything sub-standard and that they know better. This usually means these developers are entrenched in building new frameworks and systems and not leveraging the work of external developers. Building frameworks is great for developers because they get to nerd out, but terrible for the business (unless the business intends to sell this framework, but you’ll find few willing to buy). A business needs to perform its business functionality, and the longer a developer can’t provide that the longer the business losses critical revenue.

Jack of All Trades, Master of None

The second approach is to learn a little about every topic and know that it exists. In fears of sounding like a G.I. Joe public service announcement, “knowing is half the battle!” If you know something exists, you won’t spend weeks or months home rolling your own solution. This can be critical to saving time and money. The best place to start is Microsoft Developer Network (MSDN). This approach requires a lot of time surfing the internet and reading blogs. With this approach, when presented with a project, you can make the best decision about what technologies to use and learn more about it during the process of development. This approach has its ups and downs, but can help make sure that your solution is on the latest platform.

Bring in the Specialist

Pick two or three technologies and go deep. Learn everything about these few technologies and be able to talk critically and intelligently about them. This approach can work well for developers when they know what is expected of them. If you are a web developer, then you probably don’t need to read about XNA for your job (although you could read about the XNA framework for fun). This can be a double edged sword for the obvious reason that the only thing that never changes is that everything changes. Your company might be entrenched in web development one year, but decide to go into game development the next year; your skills don’t fit the job description anymore (nothing that drastic will probably happen, just making a point).

Conclusion

Doctors have used a similar approach in their profession. You will first go see a family doctor and he will attempt to diagnose your problem and treat it. If he has diagnosed your problem but cannot treat it, he then goes ahead and refers you to a specialist. Microsoft .Net is growing, both in depth and width. You can either go shallow and wide or deep and slim. You, as a developer know what’s best for you. Also you as a business owner, if you are one, know what you want your developers to be. Keep in mind that it is never too late to jump from one niche to another, but to be effective in any niche you need to do your time and pay your dues; these dues come in the form of long hours reading, learning, and doing.

Happy Thanksgiving 2009 From Aqua Bird Consulting

0

As Developers we need to take time away from our development machines and realize what is important: life, love, and family. So on this day put down your hot pockets and spend time with family members and loved ones. Also think about those less fortunate and help in any way you can.

Happy Thanksgiving 2009 from all of us at Aqua Bird Consulting.

DDD, BDD, TDD…. What’s the Difference?

1

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 fridge ecosystem 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.

Aqua Bird Consulting Blog On iPhone

0

Now you can read the latest from Aqua Bird Consulting on your iPhone. No more gesturing to shrink, zoom, and pan across the blog. As you can see from the screenshots below it is readable and syntax highlighter is supported. Oh Jeez!! I should really charge my phone.

photophoto 3photo 2

Timestamp Generator Tool For Migrations

0

On my latest project, I’ve started using migrations as a way to iteratively create my database. This helps me focus on features as they evolve. Currently everything is ok, because I am the only one prototyping the system, but I started thinking about the other developers that might work on this project. What would happen when they begin writing migrations. First let’s take a look at how my current migrations look.


[Migration(1)]
public class AddUserTable : Migration
{...}

[Migration(2)]
public class AddRolesTable : Migration
{...}

[Migration(3)]
public class AddLocationsTable : Migration
{...}

Notice how it is simply numbered 1, 2, 3, etc. What happens when multiple developers are looking at the migrations and developing their own migrations. They will want to number their migration the next number in the sequence, which will be cause huge problems when they submit their changes to source control. Luckily the migration framework I am using supports integers of any kind as schema versions. The only consideration  is that migrations are executed in sequential order based on the integer. Say hello to my little friend, the Aqua Bird Consulting Timestamp generator.

image

I hooked up the little utility into Visual Studio as an external tool, similar to the “CreateGUID” tool.

image

Now anytime I need to generate an integer for my migrations, all I have to do is click that timestamp generator button and the application will come up with a generated integer. The date and time used is UTC, which means you should be ok even if you have team members around the country or even around the world. I also allow you to select the date of the timestamp. In the instance you choose to generate a timestamp from the datepicker, the UTC time will be used of the current UTC DateTime.

Hope this helps other migration users, I compiled this to work with the .Net 3.5 framework.

Aqua Bird Consulting Timestamp Generator

A Free Year Of ASP.NET Web Hosting!!!

0

Here at Aqua Bird Consulting we want to make your web development experience as seamless and painless as possible. When you get us to develop a web application or site, then we offer optional hosting for your application, free of charge for a full year. YES FREE!!! Some hosts charge up to $20 a month for .NET hosting. In a year that can be a savings of $240 dollars, that can mean more coffee and donuts for your business. The coupon is below, but you don’t need it because we make sure to mention it to all our new customers.

image

Aqua Bird Consulting + Free Hosting = Awesome

So You Want To Build A Plug-in Enabled Application?

0

Like the title of this post asks, so you want to build a plug-in enabled application? As a developer I’ve run across this scenario at different times during my career and every time it pops up, I always seem to know a little more than I did the last time I approached this problem. This post is about helping you think about a plug-in application of your own. First, let’s look at scenarios where you would want to have a plug-in architecture.

Hammer Time!It’s Plug-in Time!

Ok before you use this hammer, you first have to know what you’re swinging at. Below are common usages for a plug-in application, but certainly not all the scenarios.

  • Job Scheduler
  • Content Management System or Blog Engine
  • Integrated Development Environment (IDE)
  • Highly Customizable Software Products
  • And Much More!!

So those are a few ideas of where a plug-in architecture could be helpful, now lets look at what you should keep in mind when developing a plug-in based application.

Shells Aren’t Just For Turtles

For any good plug-in architecture to work it will need a solid shell. A shell is that part of the architecture that orchestrates and manages all those plug-ins you want to work together. Below are some Heroes In A Half Shell!features to keep in mind when creating a shell. They are in no particular order of importance.

  • Service Location : The shell should be capable of finding services, and giving a plug-in the ability to find a service as well.
  • Strong Exception Handling: The shell shouldn’t trust any plug-in to do its job. If the plug-in is bad, that doesn’t mean the shell has to freak out.
  • Logging: The shell should let you know what it’s doing, and what it hopes to do if all goes well.
  • Instrumentation: The shell should let you enable and disable a plug-in. This could be as simple as deleting a configuration or building an admin tool. 
  • Abstract: The more abstract your shell is, the more the responsibility of functionality falls on your plug-in. This is a good thing.
  • Orchestration Theme: The shell has a theme to its orchestration i.e. executing a scheduled job, displaying web pages, etc.
  • Event Aggregation: Things happen in plug-ins, but how are you going to let other plug-ins know or the shell for that matter.

Keeping some of the things mentioned above in mind will help keep you on the right path when building the shell, but what about those plug-ins? That’s the next step.

It’s in the Contract

There are usually two approaches to allowing developers to create a plug-in. The one way is through inheritance. The developer inherits from “PluginBase” that has methods he needs to override. From my experience having a “PluginBase” has always lead to more headache than it is worth. I found that functionality would be inherited into a plug-in that I didn’t necessarily want. Any functionality I wanted in all and every plug-in usually ended up finding a better home in the shell.

The second way to allow developers to create a plug-in is through interfaces/contracts. Interfaces give developers a better understanding of what they need to implement, and with interfaces there is more room for composition. Remember .Net does not support multiple inheritance but it does allow for multiple interfaces. This allows a developer to build very specific plug-ins by only implementing the interfaces that make sense. i.e. a plug-in that has a UI might implement a UIPlugin contract, where as a plug-in that doesn’t have a UI would just neglect implementing that interface.

The Right Technology Stack

The success of your architecture depends on the technology you choose. As like any other development project, you have to choose the right tools for the job. If your plug-in architecture needs to span across networks and live on multiple machines, storing your configuration in files might not be a good idea. If your plug-in architecture exists on one machine, then you probably don’t need WCF or any other kind of remoting. That being said, you should build your architecture so that you can change major parts of your architecture without major effort or overhaul of the entire architecture. Using patterns like IoC can help make this less earth shattering.

Conclusion

Plug-in Architectures are very powerful. They can be the solution to a lot of problems, but I would not advise going down this route if you just want to flex your development muscles. A good exercise to do is to whiteboard the different aspects of your architecture. Draw a large circle in the middle of the board and label it “Shell,” then draw little circles connected to the larger circle for each plug-in. This will help you visualize what your plug-ins are, and what your shell needs to accomplish for these things to work together. Once you realize what the shell is and more importantly is not, you will find your plug-in architecture will fall right into place.

Good Luck,

I know these kind of projects can be really fun

Visual Studio 2010 : Surprise Feature

0

image

I’m trying this new method of programming where I can only see one parameter at a time. This approach allows me to stay focused on what I’m doing. Just kidding, but the screenshot you see above isn’t Photoshop. The picture is legit, apparently its a new feature in Visual Studio 2010 that lets you resize your font on the fly. I accidently stumbled upon it when I was resting my arm on my keyboard and was holding the the ctrl key and begin scrolling the mouse wheel up and down.

Surprise Feature:

CTRL + Mouse Wheel : Instant font size manipulation.

Pretty cool, especially when giving code demos or showing people code while they stand over your shoulder.

My First Week with Behavior Driven Development

0

nerd I sat down last week to start a new project with ASP.NET MVC 2. The project was something simple in theory, but I knew the details would get me. I have been a long time advocate of Test Driven Development or TDD, but wanted to give this thing called Behavior Driven Development (BDD) a chance (again). A long time ago I explored BDD frameworks but I was always too busy to really give it the chance to sink in to my brain. This time I decided to buckle down and give it an honest go. Below are the things I’ve noticed with my first serious week experience with BDD.

Tests Take Longer To Think Up

This might sound like a bad thing, but it isn’t.  Before with TDD, I would pick a service and then write a test for a particular method within that service. My tests would come together pretty fast, but there was always a disconnect. Why did I choose to write the test first and that way? The answer to these questions would be in my head, but other developers can’t see into my head. Think of it this way; if TDD helped me figure out the WHAT, BDD helped me clear up the WHY. My BDD tests are a lot more specific about their intention and the context the test exists in. If another developer would come along and read my specifications, they can read them and know what the WHY behind my code is.

All My Knowledge Still Applies

Although I am taking a different approach to developing an application, I still use all the knowledge I have accumulated up to the point I turned to BDD. I am still using NUnit, IoC, Moq, Domain Driven Design, and all my other conventions. With BDD, you are simply just reframing your existing tools and skills and not changing them. When I first started, I felt like I was entering a new arena, but it soon became comfortable when I noticed it is not a lot is different.

I Totally Need A Context

A BDD test is called a Story, and each story has scenarios. Scenarios follows the form of “Given X When Y Then Z”.  With most frameworks I’ve looked at, each part of the scenario is an independent method that is executed. So to link the scenario up you need a context that is passed to each step of the scenario. Without a context you’ll find it really hard to link each aspect of the scenario.

Lambdas Are My Friends

BDD thrives in the new .NET 3.5 and 4 frameworks. If it wasn’t for lambda expressions my tests would be a lot less readable and a lot longer (my fingers would fall off).

People Might Think I’m Crazy

I find myself talking out loud, trying to find the best phrasing for scenarios. People might look at you weird if you do this in an office environment, but the more you talk to yourself the more fluid scenario creation will be.

It All Comes Together

I’m amazed at how stuff just works the first time when it’s all wired up. I know that’s the point of writing specs and passing them, but it really is amazing. If something fails in my application it is usually because I forgot to register a type in my IoC container or I mistyped something in the View. That saves me tons of frustration, and I like it.

Conclusion

Is BDD better than TDD? I feel that both TDD and BDD are two sides of the same coin. My main goal should be to test functionality and both approaches do that. That being said, I feel that BDD has made my development process a lot more thoughtful. Is BDD the silver bullet? Not even close, at the end of the day you, the developer, are responsible for the quality of your code. Using a process like BDD or TDD challenges my discipline, and if I don’t have it then any approach to software development will be filled with frustration and hurt. On the bright side, I feel it is never to late to learn something new and improve my skills, so give something new a chance and happy coding.

Go to Top