Thursday, August 30, 2012

Learning a New Language

Today I'm going to share something about myself that most developers probably don't want to admit about themselves, but I suspect I'm not alone.  If I'm not alone, this might be able to help someone, so here it is.

I find that the hardest part of learning a new language is starting.  I find that my competence in most languages follows a curve along time that looks like this.
This demonstrates that the really challenging parts of the language are early on.  When first starting out with a language, it usually takes me a crapload of time just to get to the point of a working "Hello World".  Now there are exceptions to that rule (Ruby comes to mind), but I find that this early time is important to my understanding of the language.  I am learning compiler/parser tricks and understanding little nuances like the need for semicolons, or that every method must be in a class (C# but not C++) even if namespaces aren't necessary to get the application to compile.

I'll admit, I find this slow progress time to be extremely frustrating.  I like to see the progression of my skills, and when I can spend 5 minutes in C# and learn some major defining principle or spend 5 minutes in assembly and learn whether to use a backtick(`) in a certain location it seems like very minimal progress and can grind on me over time.

That said, there are times, like now, when I'm in the zone of slow progress.  I'm ok with reading 10 pages of a book and typing 8 lines of code.  I feel like I'm growing as a developer in just as many important ways.  Still, it would be nice to writing some complex GUI and spending more time learning about UX tricks, but that doesn't make this less nice.  This is more of a zen coding feeling.  I'm very mellow as I read little lines of stuff and understand everything about them, wrapping my head around each side of everything before moving forward.  If learning == enlightening, then this could be considered a feeling of enlightenment.

Still, it's important that I note here that this feeling was not brought on by some mysterious magic.  I didn't drink some magic energy drink or sit under a tree for months.  This was brought on by something much simpler than that.  My home laptop has become unusable for some reason or another.  For the past 2 months I've been saving up for a new one, a really nice one.  It's exciting, but it's also painful.  I've spent 2 months unable to code at home, which is a big part of my release and so I've been stressed, pulling my hair out in agony thinking of the things I want to code.  After two months unable to code, unable to get that quick satisfaction, I've gained an appreciation for the slower, stable satisfaction of reading through books and coding small amounts in a new language.

Of course, any zen teacher would say that's the trick.  By taking away your instant-satisfaction you will suffer for a while until you gain an appreciation for slow, long-term joy.  Anyway, that's how I got myself to delve deeply into C++ and start really understanding it.  I'm hoping to gain a lot from it, given that it's the basis for two of the most popular languages out now: C# & Java.

For those of you struggling in the early part of that timeline.  Trust me, it gets better.

Wednesday, August 29, 2012

CTW - Black Hole Ripples

First, some background.  Wednesday is "Conspiracy Theory Wednesday" around my house.  We pick a conspiracy theory and research it.  If there's documentaries, we watch it.  If there's articles online, we dig them up.  The idea of CTW is simple.  Treat the conspiracy theory as though it were fact for one day.  Try to find every way to make it fit reality.  By doing this we can get a better understanding of the angles people will try to defend it from, and then it also makes it easier to debunk the conspiracies on any other day.

So I'm going to try to start putting up my Wednesday posts as CTW posts.  It's representative of something I do 1 day every week, that's 52 days a year.  So it's a big part of who I am.  It's not exactly programming related, but it's a little bit of fun and a decent break.

Today's conspiracy is Black Hole Ripples.

Calling it a "conspiracy" isn't exactly accurate given that the link I just posted is from NASA.  But they aren't 100% proven and no one has really looked into the consequences of what they mean.

Black Hole Ripples are the energy waves that emit from a black hole as it absorbs other objects.  They are like ripples in an pond when a rock is dropped in, except there's no matter in space to ripple.  The Black Holes are creating ripples in space and time.

Deja Vu and Seeing the Future

Since space and time are physically being shifted in a ripple style pattern, we can examine lots of other possibilities.  If you consider these ripples to be like the crest and trough of an ocean wave, then you might consider that we are constantly shifting in space and time on an elliptical pattern as these waves pass over the earth.

Without looking into the "space" part of that equation, we have to note that this means that we're shifting back and forth in time.  If these waves can cross-section the earth at different angles and from different directions, then it's likely that occasionally we'll see entire groups of people having similar time shifts at the same moment.  In practice, however, we generally see individuals, not groups, who experience any sense of time having changed.  If this is the case, we must also include the possibility that some human beings are more sensitive to time than others.

Time is already affected by gravity, as we've discovered by leaving the planet.  Our clocks in our satellites are slightly faster than those on the ground.  So exploring time shifts as a result of something as massive in terms of gravity as a black hole should not seem strange.

Rogue Waves

In oceanography, a rogue wave is just a matter of waves crossing.  Basically, a wave with a long trough may overlap a wave with a short trough, and then their troughs and crests combine and make the occasional larger wave.  If enough cross just right, you might get one really massive wave.

The question is, what might happen if this were to occur in space-time?  that massive of a shift in space could do odd things to the earth itself, but what about in time?

In any case, that's CTW.  Do your research and enjoy.

Tuesday, August 28, 2012

Know What You're Working With

When teaching programming, every teacher has his or her own custom style.  The difficulty is that, when learning about programming, you need to understand the teacher's style, and that's the bit their less likely to explain, sometimes because they can't and other times just to avoid arguments about how they should change.

So I'm going to go over a stylistic trick that a lot of teachers use.  When learning to program, some teachers tend to live in the IDE.  They don't discuss the background stuff that's going on, which can leave you in the dark when you try to understand how everything attaches to the computer as it exists.  So the teacher will be discussing programs inside the IDE but may never even show you the output directory.

I'm using Visual Studio in this walkthrough, but the purpose here is to show you that you should look at the output directories of your own programs, even your toy apps.  Here's the output directory of a tiny hello world app.
Notice first the directory itself is set deep inside the project folder structure in a binaries folder called "bin" and in a folder titled with the build type, in this case "Debug".

My application isn't complicated, it's 16 lines, including unnecessary usings and whitespace, but Visual Studio output 4 files here.  All of the files are named after my solution, so the only way to tell them apart is by the text after the first dot, so let's stick to that text.

First, the "exe" file.

This is the actual application.  I'm sure your professor told you once that your application is producing an exe file, but it's important to note that all of your code was compiled and put inside that exe file.  That's the compiled code.  Different project types may produce different output, but in this case, all of our code is put into one exe file.

Second, the "pdb" file.

This file is used for debugging.  It's purpose is so that visual studio knows what line of your originally written code corresponds to what line of compiled code inside the "exe" file.  It's only purpose is in debugging and it has nothing to do with your actual application when it runs.

Finally, the "vshost.exe" and "vshost.exe.manifest" file.

VSHOST is a feature enhancement to Visual studio to make the Debugger faster.  It creates a hosting environment so that your file can be debugged easily.  This is also only used in debugging and has nothing to do with when your application runs.

It's important to understand what your IDE is doing, because you will some day end up working with other people's code.  If you see that someone else's application has some code you would like to call from your code, you only have a few ways to do it.

If you use the app that the other person wrote, then you have to call an Execute method, wait for the Operating System to spin up the application, and then wait for the application to process your data.  However, if there's a way to call the application through an API, then you have the flexibility to call it directly from your code which can be loads faster.

The reason I mentioned this is because I have seen teachers use the API pattern when working with outside code, but never note it to the students.  Not only are the students missing out on the valuable reason the teacher is doing things in that way, but some might even have missed the very brief sentence in the lecture where the external code was written.  It can be extremely confusing trying to write code that comes from an external API being unaware that you're supposed to have downloaded an external API.

Thursday, August 16, 2012

Source Control Branching and Merging

It is something that is so common that it's unsaid most of the time, but the entire professional software world relies on Source Control.  When I was a young newbie developer, I didn't even know what Source Control was.  It's easy for us to forget those old days and look at new developers when they ask us questions and not mention anything about how they should be using some form of Source Control aka version control.

There are a lot of different version control systems out there these days.  There's even heated debates about which is best.  The point of this article is not to tout one or the other, but I will anyway.  Git is awesome, but their Visual Studio plugin sucks!  Team Foundation Server integrates perfectly with VS, but tries to do to much, having an entire Agile system built in and fails as a version control system.  Everything else is not as good at Git and also has crappy VS integration.

Seriously though, this article is about Branching and Merging.  Do your research.  With the exception of Git, best practices with any version control system are "branch rarely".  In fact, at many companies the only "branches" you see are just markers for production release versions of software.  It can be entertaining when they then bug fix this branch and never check the code into the trunk, but I digress.

As a result of a consistent distaste for branching (mostly because of merge conflicts and slow merge processes) there are a lot of developers out there who don't understand the concept of branching at all, or if they do, they understand it vaguely in the form of "I work in this branch, then my Team Lead pushes my code to production somehow".  In the interest of dissemination of knowledge, here is how I understand branching and merging.
That living code base is simply the folder you work in when you write or change code files.  As you know already from using Source Control, you then check in any changes you make, and you can bounce around that line to go back in time to old versions of files in case you screwed something up.  This is the Source Control every professional developer works with daily and it's enough to get by at most companies.

That living code base can be considered the Trunk, or Master code base.  Branching this code is a matter of taking a copy of that folder at a particular time (or version of the files) and starting a new living code base with that new copy.
As you can see, in the diagram, it looks kind of like a tree branch from the Trunk and that's a reference to the point in time at which the code was split.  The reason we need to know when they split is because some developers may continue working in the trunk while you're working in the branch, so we need to be able to remember all the changes they've made while you were working in the branch to ensure a smooth merge.
When  you merge code, you take the two living code bases and merge the code together.  In the image above, all of the changes in the branch had to be re-integrated into the trunk.  In this example, I actually stop all work in the branch and put all of the code into the trunk, essentially deleting the branch after the merge.

Merging is the real power of source control.  Instead of overwriting the files that exist, it is able to execute each of the changes made to the files as if it were a developer.  Merging, however, is the main reason that most developers hate branching.  In every Source Control system except Git (and Mercurial, I know), it's an extremely intense process which takes a long time.  Not only that, but it's during a merge that you find out that a developer working in the trunk made changes to the same file as a developer working in the branch, and you encounter conflicts, which have to be resolved (much like when two developers try to check-out and edit the same file).

Courtesy of Git
As you can see from this image, you're not limited to one branch, or even one merge.  In a good version control system you can branch as many times as you like, and merges should be efficient.  This allows for code flexibility.Additionally, while the image above only shows merges in one direction (toward the master) since each living code base is treated the same by the version control system, we are able to merge code from the master/trunk into the branches (for example code fixes) and we can of course branch out for releases.  I'm particularly fond of this image, courtesy of nvie even though it's complex.
Notice how he has a few branches that are open all the time.  The master branch, which has tagged production builds in it for the exact versions that were pushed out to production.  He has a branch explicitly for bugfixes to the master, a branch for staging releases, the developer code branch, and then he branches for each feature.  I like this model, because it keeps the master clean, and it allows flexibility to work with different branches and experiment without negatively affecting other developers.  In any case, if you understand what's going on there, then you've mastered what it means to branch and merge in Source Control.  Take care.

Wednesday, August 15, 2012

Document it!

Anyone who's been in software development for any amount of time will know that a common issue in any team is a lack of documentation.  If you've been in the industry for more than a year, it starts to feel like "beating a dead horse" when talking about how we need more documentation.

You can try to appeal to people's emotions expressing frustration and a need for sympathy and empathy in the process, but that's just not how Software Developers work.  If you want to appeal to people like me, you need facts, and lots of them.

That's not enough though.  If you can convince your programmers to write the documentation, then you still have to convince management that it's worth the money.  The truth is, no one is on your side here.  What's worse, the guy who's touting documentation now, probably was against it last week.  It's a really hard sell.

This is my generous gift to you.  I'm going to give you the selling points that I've used right here.  I will note that these have worked for me in such a way that I am not losing my job while I spend the time writing documentation, but not necessarily on the level that the entire company is wildly encouraged to write documentation.  So it's only a start (I only started at this company a month ago), but I honestly couldn't give you the end-game solution unless I was in your shoes, so I'll get you started here, and you will have to be motivated to do the rest.  Fortunately, if you're reading this and haven't fallen asleep yet, you've got that motivation.

First, sell the developers

If the developers aren't on your side, then management doesn't matter.  Management doesn't code.  They barely know what the word code means.  If you want to get documentation in your company, your developers need to be on your side.  Ultimately, we make the decisions anyway (do I use a for loop or a foreach loop here?).  You're not going to get lazy developers to jump on the idea of writing documentation, but you can get even the laziest developer to tout how wonderful the documentation he uses is, so in order to sell the developers you need to write a bit of documentation to begin with.

It doesn't have to be much.  I spent about half a day yesterday talking with 10 different people trying to get the information I needed.  Once I had the info, I was able to document it in about 10 minutes.  So the half-day worth of research was a necessary part of my job, and the 10 minutes of documenting stuff was the work that I have to sell.  In terms of numbers, this bit of info is very nice for a developer.  But this isn't the cream of the crop.

It took me half a day to figure it all out because one of my team members had already gone through the process of figuring it out on his own and because one other team had actually written the API and was able to give some insight.  So the real numbers to compare are these, and this is the selling point.

It took one developer an entire week to figure out how to implement the API, which took another half-day for him to duplicate the work, which then took only ten minutes to document a list of instructions that takes 5 to 10 minutes to follow.  So now, all you have to tell them is that using your documentation to complete the same task saves them a week of work.  Once they use it and see how easy it is, they'll be jumping up and down about the value of documentation.  They may never write it themselves, but they'll always have your back when management asks that fatal question.

Then, sell management

Let's face it, Managers aren't that hard to sell on things.  If you put emotions in front of them, they'll laugh at you, but when you put money in place of those emotions, they get emotional.  Sticking with my API example from yesterday, I'll put money to the numbers.  We have 12 teams (I think).  Given that one team wrote the API and can likely implement it quickly, the documentation won't benefit them.  The second team, mine, who's already implemented it won't benefit from it either.  However, 10 other teams will.

An average developer in my area makes $80k per year which means $80k/52 = $1538.46 is what they get paid for 1 week of work (and if you include vacations that goes up, a lot).  So if we save each of those ten teams one week of work, we've saved the company approximately: $15,384.62.  Give those kinds of numbers to your managers and see if they think that 10 minutes was worth it.

Monday, August 13, 2012

Javascript - First Class

It may or may not surprise you to know that I have a heavy Javascript background. While my first language was VB6, I don't think I've ever delved into any language quite as deeply as I have with Javascript. I used to use a gnome back-end to build very complex projects in Javascript. Therefore, you might know how cool of a concept it is to me to use Javascript as a First Class Language.

Much more exciting however, is that Microsoft is doing just that, and in Visual Studio no less!  This means that we not only get intellisense and other features.  But now we can code entire applications in Javascript as if it were .NET at its core.

It may not seem like much, but it means that you could theoretically code pure Javascript from Logger to Server to Front End and it could seriously simplify programming in the future.  This is something I'd like to see available in more languages, but if Javascript is the start, then so be it.  Hoorah for JS!

Friday, August 10, 2012

yield return in C# 4

OK, so I've been watching pluralsight videos lately and you would not believe how much they seem to love this "yield return" in C# 4.0.  Let's take a look at it in a small implementation.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication2
    class Program
        static void Main(string[] args)
            var numbers = new List<int>()

            foreach (var number in GetLargeNumbers(numbers))


        static IEnumerable<int> GetLargeNumbers(IEnumerable<int> numbers)
            foreach (var number in numbers)
                if (number > 10)
                    yield return number;

You can see that it saves some code.  For one, I don't need to build an enumerable and then return it at the end, I can just put a yield return and C# now builds it on the fly.  It kinda violates the O in SOLID to me, but that's not what its' value is.  It's value is that it only executes the code as it's needed.  This means that the numbers in the list are being evaluated each loop in the Main method, rather than all at once and then looped through.

I could show you changes to this program to test it, but I'll leave that for you.  Instead, I'll show you the really sexy part of this.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication2
    class Program
        static void Main(string[] args)
            foreach (var number in GetRandomNumbers().Take(10))


        static IEnumerable<int> GetRandomNumbers()
            var random = new Random();
            while (true)
                yield return random.Next(30);

Since yield return only executes as needed, we can deal with enormously large data-sets, even infinite, by only working on small pieces of them at a time.  In the example above, I create an infinite loop, that only executes for the number of random numbers I choose to Take (in this case 10).    Try it out, notice that it doesn't stack overflow on you!  Neat stuff.  I could get to like this yield return thing.

Thursday, August 9, 2012

Useful Links

As an apology for not keeping up with posting this week, I provide you with cool & useful links.

Console Emulator, good one!

Crapload of Free E-Books from Microsoft

Temporary Phone Number App

New Network Security tool I found

View the source code you're using in these obscure libraries from Microsoft et al

Tabbed Remote Desktop

Programming Jokes, in code

Node.js is cool, but stack Meteor on top and you can do other cool stuff

How I set up blogger syntax highlighting

Trello, agile/scrum/kanban tool that's better than JIRA IMO Now there's even an android app!

Take "accordion" to a whole new level on your site

For those of you just getting into JQuery

And my most valuable tool when helping friends and family with tech support

Hopefully I'll get to post again soon.

Monday, August 6, 2012

Uploading a File in ASP.NET MVC3

I've done my research on this.  I've seen the literally hundreds of tutorials on how to upload a file in Microsoft's MVC platform.  So, let's do the bit that all of them show first.

@using (Html.BeginForm("Upload", "Home", FormMethod.Post, new { enctype = "multipart/form-data" }))
    @Html.Hidden("id", Model.Id)
    <input type="file" name="file" />
    <input type="submit" value="Upload" />

So the first thing to note here is that this is Razor.  There isn't an HtmlHelper for a file input, so we have to add one manually.  Same for the submit button.  Then we notice that I'm using Html.BeginForm, not Ajax.BeginForm.  Everyone loves AJAX right?  Well, AJAX doesn't allow file uploads by default, so if you want to do uploads via AJAX you'll need a plugin for jquery.  I'm submitting via POST for obvious reasons, you do not want your file's byte array in your URI.  The encoding type matters here for two reasons.  First, any misspelling or incorrect case and the whole thing breaks.  Second, multipart/form-data is the only way to pass a file via a form.  Finally, you might ask why I'm passing an ID.  After all, the purpose here is just to upload the file, right?  Since this form is self-contained, we have no way to associate the file with any other data, so you need to pass some identifier of the model you're dealing with in order to make this whole thing work.  For good measure, here's what the action method should look like in the Home controller.

public ActionResult Upload(HttpPostedFileBase file, int id)


    // Do stuff with file  


This is all you need, according to those other tutorials, in order to get file uploads working.  Of course, when I put this into my project and tried to run it, I ran into something odd.  When I tried to upload a file, it went to the Upload URL, but never hit the controller action.  When I clicked upload without having selected a file, it went to the controller action, but naturally would fail.  I couldn't figure it out, so after an hour I got to the point of opening fiddler and got myself a nice clean 504 error.  Ah yes, my web.config wasn't yet allowing the larger quantity of data to pass over the wire.  I'd be upset with myself, but I was more upset with all the tutorials that ignored this obvious bit.
<httpRuntime maxRequestLength="102400"/>
That's what I was missing.  Add it to the system.web node of your web.config and the uploads won't mysteriously disappear.

Wednesday, August 1, 2012

What Kind of Web Host Do I Need?

Let's call this the newbie guide to starting a website.  I've always hosted my own sites, so the reason I'm doing this research is because I'm considering a move to hosting off-site.  There are probably hundreds of tutorials out there, so for those of you browsing, this is purely about hosting, not about actually making a website.

This post was also inspired by a question.  First thing's first, you should decide on a hosting provider based on your needs.  So this tutorial will be broken up based on the levels of need.

Minimal Need - $5/month

So the first level of need is minimal.  This type of site is something your mom is using to present photos of her ebay sales.  It's probably something Wordpress can handle.  If you think it's going to need to handle traffic, many providers also allow for PHPBB on these.  All of this is called Content Management System, and you can use any host that will allow you to FTP and upload documents for your website for this.  Most of the time, you won't be making changes to the site itself in this case (though it is possible).  This is designed around using web-based tools to make and edit your site, not changing the server side documents.

Moderate Need - $10+/month

The second level of need is for the hardcore developer who just wants to code.  You need full access to an operating system that you can remote into and edit settings so that you can do everything from trying out different technologies to hosting video game servers.  This is going to require a Virtual Private Server.  This is the option I'm exploring at the moment and I'm not 100% sure what level of control I get over the machine.  This server is, in reality, a Virtual Machine running on someone's massive server sharing hard drive space, bandwidth, RAM, and processing power with other similar Virtual Machines.  In order to allow for this, they allocate portions of each of the above (HD space, RAM, etc) to each Virtual Machine so that you don't run into issues with someone trying to do something really weird.  I found a $10 VPS host, but the pricing varies greatly depending on what Operating System you want on it, and I've heard upwards of $310 per month for decent servers.  It clouds your data and forces your host to deal with backups and updates, but it also ties your server to a particular operating system and can get very expensive dependent upon your needs.

Serious Need - $??????

This is the level I'm currently at.  I host my own server.  It's doable, but the cost is based purely on what kind of resources you need.  If you need a dedicated internet connection for your server, you're going to be paying a lot for bandwidth and the initial installation.  If you're running a large number of RAID drives, then you're going to be paying a lot for electricity.  If I want to host off-site so your roommate doesn't trip over a cord, then you have to rent space in a warehouse.  The cost of this can vary by great margins.  On top of that, you're completely responsible for your own backups, your own updates, your own maintenance, and of course, your own setup.  No one is going to make IIS or Apache run magically for you.  You have to really know your stuff.  That said, it gives you extra flexibility.  Upgrading your storage space isn't an extra $20 per month, but just the flat cost of a hard drive.  If you want to switch over to hosting in OSX for a while, then it's within your ability.  If you then decide that you'd prefer to try hosting on Ubuntu, it's up to you to do, and no one is going to stop you.  The extra flexibility is quite nice to have.  It's up to you if the cost, in both time and money, is worth it.