Playing in the Cloud s

So I’ve been working for a startup that is knee-deep in the latest Microsoft tech stack, and thank God they don’t wrap everything in their own proprietary frameworks (see my last post…I’m still damaged). One thing that I’ve been able to do is work in-depth with cloud-based hosting providers Microsoft Azure and Amazon Web Services (AWS). This is just a purely editorial opinion, but hopefully might serve useful when considering to run your application on – premise or on the cloud.

First to dispel myths. Based on my company’s usage of AWS and the monthly bill I see each month, I’m not convinced cloud-based hosting saves you any money in the long run. In fact I believe it most probably costs you more. Where it might save you some cash is if you’re doing highly experimental type things for shorter periods of time. In that case I can see some definite cost savings by paying Amazon for some large horsepower for only a few days when compared to having to purchase that same hardware, only to not fully utilize it and outlay all that cash. However, if you pay for an EC2 vm, say an m3.large every month for a year, I would venture to say the cost of that same-sized server would be paid for, but you get to keep paying for it the following year with AWS. Really the key benefits seem to be when you’re a startup project and you know you’ll need to scale, and optimistically you hope you have to scale quite a bit. However, once you’ve hit that plateau, it might be time to look at going the non-fashionable route and bringing hardware on-premise.

One exception to this that I can see might be Microsoft’s Platform As A Service (PaaS) product lines on Azure. I mean, you can get a 2GB SQL Server database for $5 per month. If they can pull off the scale they’re advertising at the price they’re currently offering, you might be able to hit a nicely-sized web application / user base and still be under on-premise costs over a much longer period of time.

I know this may not be the fashionable thing to be preaching, I mean look at Netflix! I love how people instantly compare themselves to such a niche company while they know so very little about the architecture or processing involved in order to be an online video provider. What’s more is that business has almost nothing to do with almost any other business out there on the internet. Yet, with the cloud being all the rage, engineers, architects, and CTOs are chomping at the bit to elevate the cloud on a pedestal and will at some point invoke the Netflix card to help make their case. This is nicht git.

The cloud is a very powerful, flexible, kickstarter that is also an equally powerful money killer. Be thoughtful as to whether or not you truly need the flexibility the cloud offers, otherwise you’re just over paying a premium to be one of the cool kids.

{ Daniel: out }


Proprietary Frameworks and Why They Hurt

So this is probably going to be potentially a divisive topic and I will be first to admit that my reasoning and evidence is purely anecdotal, but please allow me to vent a bit by stating my thesis of custom frameworks suck and you should avoid them like the plague…ok…thanks. I do feel better now.

So just for clarification, I’m not talking about the quadrillion JavaScript or MVC frameworks that are out there on the Open Source market (although I do think there are some fair criticisms there of too much noise in this arena…but I digress). Open Source frameworks like JQuery, Bootstrap, Angular, etc. are fantastic. They help you reach a level of productivity that you most likely might not otherwise have hit. There are frameworks that are baked into your platform (e.g. in .NET we have WPF, WF, etc). No no…what I’m ranting about is much more sinister. I’m speaking of the completely closed, homegrown, proprietary framework that your company (or most likely somebody within your company that thinks of themselves in a very high regard) has created due to some “requirement” or [state unchangeable party line of rhetoric here]. The use of this type of proprietary framework is also usually part and parcel to the company “standard” and is in no way to be spoken of in a negative light as it should always be considered good and best…ALWAYS. </sarcasm>

Sorry…call me an antagonist, but in more than one company I’ve done work for (who shall all remain nameless), I have seen and felt first hand the pains of these frameworks and the mindsets that drove them. In the most extreme case, there was a custom framework for every layer of the stack, with some proprietary frameworks that did only one thing…wrapping other frameworks. My favorite was the proprietary framework that simply wrapped Microsoft’s Unity IoC and enabled dynamic configuration of the class injection by virtue of configuration information stored in XAML files (yes XAML…even in a WebAPI service there were XAML files for configuration and therefore a reference to PresentationCore.dll and PresentationFramework.dll… a formidable amount of code JUST to read in configuration information). If you’re creating frameworks that simply wrap other frameworks, you may need to seek help as it’s possible you’re addicted to narcissistic framework creation.

So what I’m basically advocating and evangelizing is to NOT create custom frameworks when there’s a perfectly or even near-perfectly suitable framework that’s available out on the Open Source market or is already given to you by your platform (if you MUST store configuration info for some reason, Microsoft has settled on a standard of storing configuration information using XML and made it stupid obvious by sticking a file extension on it of .config!). I’m additionally advocating to NOT wrap frameworks with your own. My basic rule is that I will only consider creating a custom framework when I am doing something so unique, most people if anyone has had to accomplish the same situation and there’s value in it being reusable. There are a number of reasons I avoid custom frameworks unless just absolutely necessary…and even then still try not to.

Below are a few of those reasons:

  1. Custom frameworks incur a potentially huge code debt which are inherently difficult to maintain (how do you search on StackOverflow for support on your closed / proprietary framework? Oh that’s right…YOU DON’T because YOU CAN’T).
  2. Custom frameworks to do things that are already being accomplished by more ubiquitous frameworks keeps your developers dumb. For example, if you have a hand-rolled data access as opposed to say Entity Framework, or you roll Ninject IoC into your own framework, thereby shielding developers from learning how to properly use it; your developers will not be learning the most commonly used technologies that their peers are, which will make their skills less marketable and keep them frustrated and less satisfied (which will have a negative impact to the quality of your software). “Train people well enough so they can leave, treat them well enough so they don’t want to” – Richard Branson.
  3. Your custom frameworks are inherently weak. Despite how proud we are of anything we create that we feel is clever…it has not been, nor will it ever be, scrutinized by the development community at large. This scrutiny is what makes the more ubiquitous and commonly used frameworks as solid as they are. You may claim to have a solid proprietary framework (and that may be a true statement), but it cannot claim the battle-hardening that the Open Source frameworks or platform technologies have.

These are just some of my thoughts based on frustrations that I have dealt with from an architectural / software engineering perspective. At the end of the day, I’m not religiously anti-proprietary framework, I’m just a believer in following the crowd when you are doing something commodity and only forging your own path when you are truly and honestly doing something unique or have a unique problem.

{ Daniel : ‘out’ }


It’s been a while…still working on Node.js project and adventures in hosting.

So it’s been a while since I posted anything to here, but I didn’t want it to seem as though I still haven’t been making some progress on my love affair with Node.js. Since my last post, the Microsoft plugin for Visual Studio 2013 for node.js development has improved tremendously, but alas, I’ve still gone ahead and purchased the developer’s edition of WebStorm (which also had a nice upgrade). Several of the node modules I was using in my project, including the express framework and even node itself, all had new releases that I upgraded to. This caused only a minor issue in the module connect-mysql as they introduced some breaking changes for how to setup the provider for session storage for use with the expression session interface. No matter. I updated the requisite code and now all is updated and happy.

One thing I also did was attempt to publish what I had so far to Heroku using the one free “dynu” that they offer. In order to accomplish this, I had to migrate my database from a locally hosted instance to something cloud-based that Heroku could talk to. This led me to ClearDB. While the single free processor that Heroku offers for free, they handicap it so that it’s not “on” by default unless there has been some recent activity, and the only way I can see to give it activity before it shuts down after one hour is to go into the configuration and change a setting and save it. Since I’m not prepare to shell out any more money on this experiment quite yet, I haven’t done much else with Heroku at the moment. The ClearDB host has been pretty nice, however, because I can run my node project locally or on the cloud, and it doesn’t matter, the backend database is on the cloud so it’s always there. The only thing they handicap there on you is the scheduler from running. On the free option that I’m currently configured with, this creates the side effect of accumulating session records in the sessions table that the connect-mysql module produces. For now this is a small price to pay since it doesn’t affect real functionality and it still keeps me in a free scenario.

Outside of this activity, I haven’t added much in terms of app functionality. I did mess more with the sessions and ensured they were properly expiring and thus behaving like a public website should. You can check out the current version and progress of what I’ve got out on GitHub at .

Time to start adding some more meat to the project and get something of a workable product from A to Z. Stay tuned!

{ Daniel : ‘out’ }


Node.js plugin for Visual Studio…Buyer Beware (it’s still alpha so…yeah).

My excitement for this has waned almost immediately after checking this out. I will say this is still an alpha product, so I’m confident it will be a bang-up plugin once it’s past beta. I unfortunately cannot continue to develop with it since as soon as I attempt to debug my solution it bombs on the await npm module as it appears as though Visual Studio looks like a browser to one of the await.js files, and it of course doesn’t support what I’m using await for inside a browser (even though in fact I’m not in a browser at this point in the code as I’m back in Node.js on the server using await in various data persistence circumstances). So it looks like VS is doing some sort of emulation that is freaking out at least the await module within Node.js, which for me is kind of a showstopper for this plugin until it progresses further along. Back to JetBrains WebStorm for now.

{ Daniel : ‘out’ }


Making Progress…SlickGrids, Bit Fields, and Await

I’ve made some major progress since my last post. I’ve ditched Recline.js in favor of SlickGrid. Recline was wrapping SlickGrid as it were, and the abstraction layer above it introduced so many dependencies that I couldn’t quantify any tangible benefit for a semi-broken data grid.

In my quest to keep with an OR/M, I’ve also switched to Sequelize from the standard node.js orm as a result of my journey to debug why bit fields from MySQL were always coming over as true. Sequelize allows you to define custom getters and setters. however, I’ll spare you a lengthy and frustrating dissertation about my discoveries in that area. Suffice to say that my bit fields are now simply int(1). This seems to make SlickGrid just as happy as true/false Booleans, so yeah…whatever.

Now that I’ve wired a save button to my Manage Homes page, I’m handling classic create/update/delete logic. This is where something that is both powerful and unique with Node.js kind of came to a head for me in that most every function call of significance is asynchronous. As asnyc-hip as I try to be, there are still just some times where I need to not begin something until something else has finished. This is what caused me to discover the npm module ‘await’. This allows you to register promises that you can fulfill in your async methods in order to not start something until you’re good and ready. It’s actually pretty slick. I got the idea from C#’s newer await keyword that was introduced in .NET Framework 4.5 (I believe).

So now if you look at my GitHub repo for nHOAPro, you’ll find a perfectly working Homes Management page using a client-side data grid. Long ways to go still to finish the app, but now it’s more of just rinse and repeat. Here’s a ‘pretty’ picture:

{ Daniel : ‘out’ }