PHRASE OF THE MINUTE


While this page is being built check out this great .NET and development site - CTRL313373.com
CTRLALT313373.com

Codeine .Net

Connected Home – Garage Door

If you haven't been living under a rock lately then you have probably heard the term "The Internet of Things" getting thrown around to refer to non-computer items that are getting hooked up to the Internet. Conceptually this seems great, but it made me think about what items I can and what items I would even want to connect to the internet. That's when I remembered this little thing from Liftmaster.

Liftmaster 828LM Garage Door Opener Internet Gateway

For about $30 this little box allows you to never have to turn your car around again to check if you left your garage door open. More specifically, it allows you to connect your newer Liftmaster garage door opener(s) to the Internet and then check the status of your garage door(s) from you IPhone or Android device. I had originally came across this when we first moved into our house, when I was looking up the garage door opener model that we had, but at the time Liftmaster wanted $1 a month for the service. Now they have made it free once you buy the device.

Setup is pretty easy. It plugs into your network via a built in ethernet jack and then links up to your opener(s) via Liftmaster's MyQ technology. You need to make sure that your opener is compatible, but if it is then its a simple task to set it up. I downloaded the IPhone app and it easily walked me through the setup. The most annoying part was needing to pull out a ladder to press the button on my garage door opener in order to link the two devices. Once all is setup you can now check whether your garage door(s) are open or closed from anywhere with internet access along with opening and closing them. You can also setup alerts to notify you of various states, like if your garage door has been left open at night.

Chamberlain, which is a sister brand of Liftmaster has what looks like the exact same product for that line of openers (the CIGBU) and based on the screenshots I have seen of the phone application and website it works exactly the same.

Chamberlain CIGBU MYQ Internet Gateway


Analyzing Jpgs Byte By Byte

I have been doing a bit of work lately analyzing images from both video streams and static pictures and apparently I have found the process interesting enough to write about it. It's not very often that I can get away from the standard CRUD type application and I really found it interesting to dig into the basics of image analysis.

For the tasks I have been working on I've needed to get down to the individual pixels of an image. There are various ways to do this, some of them possibly easier than what I am going to be walking through, but due to the circumstances of what I needed to do this was then best method for me to accomplish it.

First you need to get the jpeg into a BitmapImage object. It's a pretty simple task, especially if it is coming from a file.

BitmapImage sourceImage = new BitmapImage(new Uri("TestImage.jpg"));

Next we need to get the image into a byte array. This is a bit more complicated, but really isn't that bad

int stride = (sourceImage.PixelWidth * sourceImage.Format.BitsPerPixel + 7) / 8;

int size = sourceImage.PixelHeight * stride;

byte[] pixelData = new byte[size];

sourceImage.CopyPixels(pixelData, stride, 0);

The most complex thing here is understanding what the stride is. Stride is the number of bytes in each row of the image. We basically take the number of pixels wide and multiple that by the number of bits per pixel which is a property off of the image. Since there are 8 bits in a byte we divide by 8 to get the number of bytes. The next key thing is the size of the byte array that we need which can be calculated by the PixelHeight multiplied by the stride. Finally we copy this into an array. We now have an array of bits that constitute the image.

Let's assume for explanation purposes that our image is a 32bit image. That means that each pixel is "described" using 4 bytes. 1 byte is for the alpha channel, and the other three are for the RGB values. To loop through each pixel we do the following:

for (int i = 0; i < pixelData.Length; i += 4)

{

byte blue = pixelData[i];

byte green = pixelData[i + 1];

byte red = pixelData[i + 2];

}

It's basically your standard for loop except we add 4 on each iteration of the loop. This is because we are looping though each pixel, but 1 pixel is represented by 4 bytes. Byte i is the blue channel, byte i + 1 is the green channel, byte i + 2 is the red channel, and finally byte i + 3 is the alpha channel. The table below represents the array for a 2 pixel wide by 8 pixel high image where each cell is a byte in the array and every four cells in 1 pixel. Hopefully this helps to visualize the layout of the data.

B

G

R

A

B

G

R

A

B

G

R

A

B

G

R

A

B

G

R

A

B

G

R

A

B

G

R

A

B

G

R

A

B

G

R

A

B

G

R

A

B

G

R

A

B

G

R

A

B

G

R

A

B

G

R

A

B

G

R

A

B

G

R

A

Finally while in the loop you can set each byte to the proper RGB color values to manipulate the image how you want and then you convert the array back into an image using the below code.

WriteableBitmap wBmp = new WriteableBitmap(sourceImage.PixelWidth, sourceImage.PixelHeight, sourceImage.DpiX,

sourceImage.DpiY, PixelFormats.Bgr32, null);

wBmp.WritePixels(new Int32Rect(0, 0, sourceImage.PixelWidth, sourceImage.PixelHeight), pixelData, stride, 0);

That's the basics of how to access the individual RGB values for each pixel in an image. It's pretty simple once you wrap you head around how each pixel relates to a byte.


Big Changes, New Opportunities

Well, it has been pretty quiet on this blog for a while. It has been a busy year, including getting married, and I just haven't had the time to sit down and write up some posts. As you can see from my past postings I like to break things down with code samples and walkthroughs that let even the most inexperienced person understand what is going on, which can take some time to do. Hopefully in the future I can get a few posts up about Azure as I have been working in it a lot lately as well as some fun posts on working with the MS Kinect SDK.

This blog post is actually about my latest venture, Risiti. Our goal with Risiti is to begin streamlining the retail process buy building on the relationship that is established between a merchant and a customer at the time of purchase. The first step in building this relationship is creating an electronic receipt from the merchant for the customer. This first step is complex, but extremely beneficial to the customer allowing them to no longer worry about the frustration of paper receipts. I don't know about you, but when I make a purchase the paper receipt goes directly into my wallet, then once my wallet gets too thick they move onto the top of my dresser (see the picture below of my latest pile). Finally once the top of the dresser is covered with receipts I sort them, keeping the ones that I think I still may need, and shred the rest. Rarely do I ever buy anything that I need to return, but there is always that chance, especially around the holidays. On top of that I am a small business owner and I need to keep any receipts from business expenses, not to mention needing to save them for insurance and warranty purposes.

We're tackling this problem on two fronts. Our ultimate goal is direct integration with the merchants you shop at. We realize this is the best user experience for the customer, but unfortunately businesses, in general, can be slow to adopt new technologies like this so as we work on building our merchant network we are giving customers the ability to upload their receipts into the system themselves via email. If your receipt is already in an electronic format, say an email from your latest Amazon purchase, simply forward in the email to our system and it will take care of storing it for you. For paper receipts, just pull that camera phone out of your pocket, snap a picture of it, and email it in as an attachment from your phone.

Whereas storing your receipts electronically is a great goal, we want to go beyond that. We want to use that information to help you build a relationship with the merchants you shop at often. From the merchant standpoint, statistics indicate that it is much more difficult to gain a new customer than it is to retain an existing customer. Based on that, we want you to be able to let a merchant know if you received a poor shopping experience so that they can correct the situation before they lose you as a customer. Beyond that we would like to work with the merchants you shop at to offer you deals and discounts that may interest you based on what you have already bought from them. Don't worry; at no point will we be giving out your personally identifiable purchase information. We want our friends and family to use Risiti and that isn't how we want to be treating out friends and family.

It's a big venture that we see as being beneficial to everyone and we would really appreciate your feedback on the process. We'll be slowly sending out beta invites and making improvements based on your feedback. If you're interested in participating in the beta then head on over to the website and sign up for updates as we will be using this list to send out beta invitations. If you're not interested in participating I would still appreciate hearing your feedback on why you aren't interested. If you like the idea, head on over and like us on Facebook and follow @RisitiUSA on Twitter. Finally, when you're shopping at your favorite merchant ask them why they're not using Risiti!


Creating a SQL Server Alias with Code

I've been working on a fairly large project the last few months which required SQL replication where the server that hosted the publication didn't run on the default port. I don't know what SQL Server 2008's issue is with replication on anything besides the default port, but my windows service that handled the syncing would always error out. (I'm doing a pull subscription with SQL Express 2008 so there is no SQL Agent to handle the syncing for me.) My work around for this was to create a SQL Server Alias during installation of my application. You need to reference the dll Microsoft.SqlServer.SqlWmiManagement.dll to do this. (It's possible you may need to reference another dll, but I already had several SQL Server dlls referenced for the actual replication code I had written). This dll can be found in the SDK which you get installed when you install SQL Server 2008. Look for it in the folder that was created in your Program Files. The name space you will be working with is Microsoft.SqlServer.Management.Smo.Wmi. Below is some example code on how to do it in C#.

using Microsoft.SqlServer.Management.Smo.Wmi;

public void CreateAlias()

{

ManagedComputer mc = new ManagedComputer();

ServerAlias alias = new ServerAlias();

alias.Parent = mc;

alias.ServerName = Server Address;

alias.Name = Name for your alias;

alias.ConnectionString = Port number as string;

alias.ProtocolName = "tcp";

alias.Create();

}

public bool DoesAliasExist()

{

ManagedComputer mc = new ManagedComputer();

bool result = false;

foreach (ServerAlias serverAlias in mc.ServerAliases)

{

if(serverAlias.Name.ToUpper() == Name for your alias)

{

result = true;

}

}

return result;

}

I tried using a completely different name for the alias, but couldn't get replication to work until I created the alias name as the server name, then things started working nicely. That seemed a bit strange to me as you would think I should be able to name the alias whatever I wanted. Hopefully someone else will find this helpful and it will save them some searching.


dasBlog and MetaWebLog

I know this blog has been pretty quiet for a while. Hopefully some new posts are coming soon based on getting inspired from the latest Iowa Code Camp on May 1st. For now I am just testing to verify that I can post from Word 2010 to dasBlog using the MetaWebLog API. For future reference for myself the url to use for dasBlog to access the MetaWebLog API is {url}/blogger.aspx


Upgraded DasBlog

Unfortunately for you this post isn't very interesting.  I'm just testing things out after upgraded DasBlog to version 2.3 an moving everything to my hosting provider.


Updating Channels in MythTV

This is one of those blog posts that is getting written mostly for my future reference, but someone out there may possibly find it useful as well. Recently Mediacom, the local cable provider, decided to move around a few channels and I found myself needing to update my MythTV box so that it knew the proper channels to record my shows from. This turned out to be fairly simple. I logged into the box via ssh and executed a su command to elevate myself to the root account. Then I executed the following command:

$ mythfilldatabase --do-channel-updates

After a few minutes of updates, everything was taken care of. There was no need to reboot the computer and my records still existed unharmed.


The framework is dead. Long live the framework!

Over the last couple of years I have been involved with companies that have built their own frameworks using the .Net Framework to encapsulate such functionality as data access, security, and even UI elements such as page management and common list box controls. In their purest forms I think frameworks are great to have and can bring a lot of positive things to a project and a development team, but in practice what I seem to be finding is that frameworks turn into a brick wall to getting things done, a crutch for bad habits, and a roadblock to innovation.

Here are a few positives that come from a framework when done right:

  • Concise code where common functionality exists in one place.

    Duplicate code means duplicate bugs, more lines to dig though, and more lines to tests.

  • A strong foundation for projects that allows milestones to be reached quicker.

    Time is money in every industry and what ever gets you in the right direction the fastest will save you money. (Notice I said the right direction.)

  • An abstraction layer so that new developers don't need to learn everything before getting started on a project.

    It can take new developers time to get up to speed and contribute to a project. If they have a framework that abstracts the details of certain areas away from them to start out they can more quickly begin adding value.

  • A standardization that guides projects in a consistent manner.

    Assuming the framework is consistent, then the way you interact with it helps to structure your program and give projects a similar look and feel.

  • A time tested code base that evolves to be trusted and bug free.

    Well maybe not completely bug free, but overtime and use we start to trust code more and feel more comfortable deploying it. If a framework gets a good work out on multiple projects then it tends to become fairly stable.

Here are a few of the negatives that I see that really happen with frameworks:

  • Too much stuff gets put into the framework that doesn't get used.

    People start rolling stuff into the framework because it has potential to be reused, but even if the item can be reused, it involves so much customization for a particular client or project that it is no longer the original piece.

  • Items go into the framework that aren't documented and in turn the functionality gets reproduced somewhere else.

    I'm starting to see this one over and over again and it is partially a side effect of frameworks getting too big. People don't know what's in the framework, whether it be because they are new or simply because the framework is so big and has so many people working on /with it. People end up reproducing the same functionality someplace else.

  • Existing framework functionality is not maintained well and becomes a hindrance down the road when new technology comes around that doesn't mesh well with the framework.

    A framework in .Net 1.1 becomes a framework in .Net 2.0, which then turns into a framework in .Net 3.5, but the code stays the same. Technology advances and the framework elements need to as well, but the mentality of "if it ain't broke, don't fix it", seems to hang out with frameworks.

  • Developers never learn how to code outside the framework.

    I actually worked with a young developer at a previous employer who, when it came time to leave the company, realized that he didn't really know how to get data out of a database without the framework. I considered him a decent developer for his level of experience and a person with a lot of potential, but he'd been stuck using the same framework for all of his short development career so there were many things he never needed to know how to do.

  • Old, Fat, whiny people get worked up even at the thought of making a change to the framework. (They're not always old or fat, but they tend to always be whiny.)

    Really is there anything else that needs to be said here? You know the exact type of person I mean and if you don't then say hi to them in the mirror while brushing your teeth in the morning.

  • The framework becomes the solution to every project even when it shouldn't be.

    This is the using a sledgehammer to kill a fly type problem. People get a one track mind and big or small the framework is the solution to every project's needs. Worst yet, project specifications start getting tailored to what the framework can and can't do.

  • New developers don't feel empowered to make changing or additions to the framework.

    This doesn't even necessarily need to be new developers either. Frameworks seem to take on this bigger than life image that makes people feel like they are unworthy to make a modification. Either the developer modifies their code in a way they didn't want to in order to interact with the framework, or they do something crazy like copy the functionality out of the framework into their custom project and make changes to it. I've seen classes that were directly copied, with the namespace even duplicated and then minor changes being made to the copy to handle functionality that the developer wanted.

  • The framework is rigid.

    Come on; mark a few methods virtual people!

Well I know I listed a lot more negatives than positives, but the positives definitely score highly. Having a reusable framework that handles a lot of common scenarios that come up with your projects can really help shorten the time to delivering a milestone. At each employer that I have worked at the projects during that time were fairly similar, needing the same type of functionality, and these types of scenarios benefit from a quality framework. Projects can get from point A to point B much faster, which translates into less money. Client and managers always like things to cost less.

I think the best solution to the negatives is to have individuals that have the key responsibility to maintain and grow the framework. Without individuals that have defined ownership in the framework it becomes a tool that is neglected. The "regulation" of the framework needs to fall someplace between a communist leadership and a capitalistic society. An individual utilizing the framework needs to have input into what is going on and provide feedback into what is needed, but in the end there needs to be a smaller group of individuals who decide what should be included and what shouldn't be. The framework in general is going to be driven by what developers need for a project and a client, but the framework needs to expand beyond the needs of a single client and project. Contrary to what some people believe, I've noticed in my career that if there isn't someone to go to that provides the firm yes or no, then nothing tends to happen. Problems get discussed, solutions get discussed, but nothing goes forward. Either no one feels empowered to take the reins or no one wants to be the fall guy if things don't work out.

Overall, I really do think a framework can be a positive thing, but it needs to be managed and budgeted for just like any other project the company works on, especially if it starts to become an integral part of most projects that are being done.


Email, it’s the new phone call….

Hello Mr. Osborn, how are you today….How's the weather there in…Iowa"….Please hold while I look up your information…Sorry sir, my computer is really slow today….Hold on while I go talk to my supervisor…..

Okay, I'm an introvert, I'll admit that, but isn't it time that email is elevated to the status of the phone call? In my opinion an email is simply an asynchronous phone call when it comes to business related conversations. I'm busy throughout the day and I'm sure everyone else is too, but I do have a few minutes of down time here and there when I'm waiting for data to load or a project to build and I utilize that time to get some other tasks done. What I don't have time for during a build process is to sit on hold or wait for a receptionist to look up some information. The weather is either too hot or too cold and I'm sure your kids are great. Oh, you're computer is slow? No, I don't want the credit protection plan. Half the time I am probably going to get someone's voicemail anyways, so why not just send them my questions in an email in the first place. Sure in some cases a phone call can be quicker or the urgency requires a phone call, but in most cases a few emails will suffice and it allows me to space out the time into the random free minutes I have throughout the day. Sure I could just put you on hold every time my build finishes and take you off hold when I am waiting on data to load, but most likely you would find that extremely rude.

The problem I am running into is that apparently other individuals don't consider an email on the same level as a phone call. Don't get me wrong, I don't expect an immediate reply, but there are a few things that I would like to be able to start expecting.

  • If you're out of the office for more than a day, I would like to receive an out of office reply.
  • If I send you an email before 2pm on a work day, I would at least like to get an email before 5pm saying that you are looking into it and when you will be getting back to me.
  • If there's a document you need me to sign, then scan it and email it to me. If I don't have the time to call you then I sure don't have the time to stop by your office.
  • Don't send any data like a credit card number or social security number to me in an email unencrypted. If you need that information then you won yourself a phone call (or I'll decide it wasn't that important).

Is that too hard to expect? Obviously there will always be exceptions, but I would say that they are pretty simple to adhere to. The great thing about email is that people don't really want to type very much, which is great because I don't really want to read very much, so they keep their answers as concise as possible. I think most people want that phone call initiated because they feel they are going to have to do a lot of explaining, but it is most likely the case that I'm not going to retain the big long explanation you provide over the phone, so just answer my question via email which I have most likely phrased in the form of a yes or no question and save us both some time.

Seriously, am I way off base here?


$12,500 Twitter Client

Well I got a little bored this evening and started to play around with the Microsoft Surface SDK. Nothing too exciting in this first iteration, but I wired it up to my Twitter account and started pulling down new tweets every couple of minutes. With a little styling I was able to get each of the messages to look like a handwritten Post It note. The messages are created using the ScatterView control which is a Microsoft Surface specific WPF control that allows each item to be picked up, dragged, resized, and even thrown around the screen. Microsoft uses this control a lot during demos of the Surface, wiring it up to pictures to provide a table full of photos type environment. Why is this a $12,500 Twitter client? Well because that is how much it is going to cost you to get a MS Surface, or $15,000 for the developer version. Though, if you buy one in the next 15 minutes, I'll throw in this nifty Twitter client for free.






SENSELESS SURVEY    RAMBLINGS    THE LIST