3 months with Entity Framework 7

TL;DR: Mixed feelings. I don’t think EF7 is ready for public consumption.

The Good:

  • Official documentation is better than EF6. Way better.
  • Super quick to get up and running. Perfect for slapping together a quick CRUD prototype.
  • Basic functions are easy to understand.

The Bad:

  • Advertises that it can connect to many different data sources (mysql, postgres, sqlite), but actually anything other than MSSQL is a wash. In several of the databases, migrations aren’t supported. In a couple others, some functions aren’t supported. Basically, if you’re using .NET and you’re going to use EF, you’re going to use MSSQL.
  • Entity relationships start out simple, but get confusing quickly, and some relationships aren’t even possible.
  • Creating classes from an existing database is not documented anywhere. Gotta use the CLI to learn what commands are available and play around with it.
  • Migrations will fail, and the resulting error will be nondescript. Good luck figuring out what actually went wrong.

I used it for a few services I wrote and while those services were basic, it was a great tool to quickly get something out the door and ready for a demo. Now, however, I’m converting everything to Dapper. Just can’t go wrong with Dapper.

I think on future .NET Core projects, I will skip EF7. Though I guess I have to keep it around for ASP.NET Identity. Microsoft continuously fails to hook up basic SQL providers for that library…

Aurelia vs Angular 2 Comparison

Having settled on either NG2 or Aurelia, I decided to compare the two frameworks. I built an entire prototype web application using NG2 and then converted it to Aurelia. Below are my findings!


Angular 2 (NG2) and Aurelia (AU) are almost exactly the same feature-wise. My recommendation is Aurelia based on framework complexity and development speed, and a couple other minor factors. Read the dissertation below for details!

Long Version

Framework Complexity

Angular 2 is more complicated. There’s no two ways about it. NG2 comes with a lot of ceremony and explicit configuration for each component, module, pipe, directive and whatever else you want to build. The good news is that when using the Angular CLI, the configuration is usually generated when making components using ‘ng generate’ command. So a lot of the boilerplate is automated via the CLI tool. Unfortunately he CLI is in alpha stage, which becomes obvious the moment you want to configure something in the CLI config file.

Alternative way to build NG2 apps is using the SystemJS module loader, but that way is discouraged now as the NG2 team promotes the CLI tool. However the NG2 documentation still uses SystemJS… so basically NG2 despite being RTM version 2.3 now, is still in beta.

Aurelia was in beta, then RC, and came out a few months before NG2 hit RTM. It had a few breaking API changes in the beta which left early adopters scratching their head, but it has been stable since release. Aurelia is actually one of the simplest JavaScript frameworks in the wild right now, because it uses plain ES6 (and to some extent ES7, which isn’t standard yet). It stays out of the way as much as possible and uses conventions to drive the apps.

One drawback of this approach is that cool NG2 features like template switch statements are not possible (since they’re not standard compliant). There are a few other things missing from Aurelia, but they’re minor quality of life improvements that are easily countered by the fact you simply write less code with Aurelia than with NG2 in the end anyway.

All things considered, both frameworks are fully featured, so there’s definitely a greater level of complexity to them than, say, jQuery or Backbone. However, Aurelia is more approachable and thus with a look towards the future, I would recommend Aurelia.

Paul’s Note: If I gave a backend/middle tier developer either Aurelia or NG2 to work with, they would be able to get started with Aurelia almost immediately, while they would need to spend at least a couple weeks deciphering NG2’s syntax.

Development Speed

The above point about complexity drives this recommendation. It’s faster to develop with Aurelia [once you are familiar with the conventions], because it’s just plain JavaScript. TypeScript slows down development a tad because it’s a bit more overhead, but I think if we’re careful, its design-time error checking capabilities may counter the slowdown from the overhead.

Just based on JS/TS preference this is a draw since both frameworks support both, but Angular 2 MUST be written in TypeScript if you want to take advantage of tree-shaking (to minimize production payload size).

I’d give this to Aurelia by a slight edge, but almost non-existent. However take the previous section into consideration.

Paul’s Note: I am torn on using ES6/7 or TypeScript. I love the tooling and design-time error checking that comes with TypeScript, but the fact JavaScript libraries outgrow their typings very quickly is annoying. I think if we limit to using just the essential libraries and don’t venture too far into the wild of NPM, we should be good to go with TypeScript.

3rd Party Package Dependency

Aurelia’s dependencies in their shipping product are limited to Aurelia-specific packages. The team even went to the length of writing their own browser polyfills instead of using existing npm packages. So when shipping Aurelia projects, unless using 3rd party stuff like moment, numeral, bootstrap and such, we are shipping just Aurelia. However, modern projects will be using all those libraries and possibly some other ones to speed up development and add modern flair to the experience.

Angular 2 on the other hand leverages existing npm packages like rxjs for state management (it’s baked into the framework). Reactive eXtensions is the new kid on the block, though reactive programming has obviously been around for a long time. Side note: The JavaScript community is kind of a bubble though and developers like to migrate to the latest and greatest instead of sticking to the tried and true. Angular 2’s team did not reinvent the wheel, which is why it took half a year less to ship NG2 than Aurelia (though one could argue NG2 is still in beta).

Aurelia wins here by the virtue of giving users their own way to manage state instead of promoting just one way. Also, it’s much, much, muuuuch easier to include 3rd party dependencies in the Aurelia build process. It took me 5 minutes to get mapboxgl hooked up vs half a day in Angular 2… and they’re using completely different build processes so it’s not like I could just carry my knowledge over. This also adds to development speed!

Paul’s note: RX is actually pretty cool, and the rxjs library comes with a lot of handy functions for working with ajax like map and debounce which are not present in the current ES spec. The library is independent of ng2 (since it’s just a pattern library) so it can be incorporated into Aurelia as well. A single source of truth in a singleton class is a pretty standard way of doing things that’s been around for ages (using pubsub pattern). RX, and especially its implementation in JavaScript via rxjs is not something that can be grasped in 5 minutes or even 5 hours.

Standards Compliance

NG2 is not standard compliant. It introduces its own markup into the HTML and makes use of ES7 decorators for metadata extensively (they’re not a standard yet). Aurelia also uses decorators though, but they’re optional. Now that I think about it, decorators aren’t really a big deal, but the non-standard HTML is. That means porting an NG2 app to or from another framework becomes a rather annoying endeavor.

Aurelia is 99% standards compliant when using ES. The binding syntax in Aurelia makes it 1% non-compliant, but every framework is going to have data binding. Basically any JavaScript developer will be able to write Aurelia, because Aurelia components are just JavaScript classes.

Paul’s note: Angular 2’s popularity is undisputed so finding devs who know NG2 might not be that hard. Lastly, if we use TypeScript, we’re going to deviate from standards, because we’ll be introducing types, variable scoping and other features not present in the current ES spec. Probably a toss-up, really.


Frameworks render stuff at over 100fps in the browser now and over 50fps on phones. Unless rendering giant amounts of data in tables, there isn’t gonna be a clear winner here.

Besides rendering, there is load time to consider. However, as when building apps there will be a required download at least once. Whether the app is 500kb or 1000kb makes no difference in this age of [bandwidth] plenty.


I recommend Aurelia using TypeScript. There are a lot of loud voices these days, each evangelizing their own framework, but ultimately it is up to the developers which one they go with since they’ll be spending the most time in the code which later compiles down to ES5 anyway. The business* and the end user doesn’t care, as long as the end product is awesome.

Front-end Framework Comparison

Along with the last article about ASP.NET, I also did some research on which FE framework I’d wanna use for projects going forward. Below are my unedited findings. I considered:

Angular 2 https://angular.io/
Aurelia http://aurelia.io/
Ember http://emberjs.com/
React https://facebook.github.io/react/
Vue https://vuejs.org/

Important Things to Consider

  • Performance
  • Learning curve
  • Development speed
  • Standards-compliant (future-proof)
  • Stability
  • Testing

Less Important Things to Consider

  • Syntax legibility
  • Documentation
  • Community
  • Longevity (2 years at least)

Framework Summaries

Angular 2

Angular 2 is the successor to Angular 1, though a completely different framework at its core. Angular 2 is a “modular monolith” framework which provides users with every tool in the shed required to build a full SPA application. Angular 2 is an on-site project at Google.


Aurelia is a brand new “all in one” framework focusing on standards compliance and readability. The tag line is “convention over configuration”. It is backed by a company called Blue Spire founded by Rob Eisenberg, author of Durandal and an employee at Microsoft.


Ember is a heavily opinionated “all in one” framework done in the open by Yehuda Katz and Tom Dale of Tilde. If you follow the Ember way, productivity skyrockets. It’s backed by LinkedIn and used by quite a lot of companies. Ember has been around for a while and recently saw version 2.0 which brought it closer to modern web standards.


React is a view engine developed in-house by Facebook, which saw a surge in popularity in 2015. Since it’s only a view layer, it does not come with a router, http client, or state management. For these, other JavaScript libraries must be used. React is used by Facebook throughout their namesake.


Vue is a hybrid framework which combines elements from all the other frameworks and focuses on component architecture and rendering performance. Vue is developed by Evan You, formerly of Google and used throughout the small business and startup community. It’s backed by JSFiddle, Laravel and a few other communities.

Comparison Table

  Angular 2 Aurelia Ember React Vue
Performance 8 8 6 6 7
Learning Curve 4 9 6 8 9
Development Speed 8 9 9 5 10
Standards 5 10 7 4 8
Stability 7 7 8 10* 9
Testing 10 10 8 10 10
Syntax legibility 6 10 7 5 9
Documentation 10 10 8 6 10
Community 8 6** 9 10 6**
Longevity 10 10 10 7 8
Total 76 89 78 71 86


* – React is only a view engine, thus stability is excellent. However, when adding other components to orchestrate the entire application, stability may suffer.

** – Aurelia and Vue’s community are smaller due to the fact they’re not widely known. However, both are growing and have active gitter channels. Both Aurelia and Vue have developers routinely respond to questions and requests, which is not the case with the other frameworks.



To stay nimble and performant, Angular 2 employs a technique called tree-shaking to shed extra modules from the framework during the production build process. This results in a smaller package size. However in order to use that feature, TypeScript must be used. TypeScript sometimes gets in the way of development, especially with lesser known libraries which have no typing and have to be globally declared with an ‘any’ type resulting in no typings at all.

Angular 2 is fully featured. It comes with a router, animation and http libraries. It also has excellent documentation, albeit in flux as the framework is evolving consistently. Angular 2 strongly encourages a reactive design pattern by sprinkling the rxjs extensions everywhere (namely their http client).


Aurelia, like Angular 2, comes with a router, animation library and an http client. However, Aurelia does not enforce a design pattern and you can use any AJAX library you want. Aurelia comes with a pub-sub pattern baked into the framework instead of rxjs, but it’s not obligatory. Most Aurelia applications use a shared singleton class as the source of truth in the application, and subscriptions to that class’s properties.

Aurelia can be written in ES7 or TypeScript. Like Angular 2, it supports both, but actually promotes ES7 which is more standards compliant. Aurelia stays out of your way and promotes convention over configuration, so you’re writing plain JavaScript most of the time while the magic happens inside the framework. Probably the most obvious drawback of Aurelia is its “newness.” Although it has been in development for 2 years and it’s based on Durandal which has been around for 6 years, the community around Aurelia is still rather small. This results in less documentation beyond the official docs.


Ember is a heavily opinionated framework which definitely enshrines convention over configuration. It’s a mix between Angular 2 and Aurelia in that it will force users to use the HTTP and state management that comes with it, but if you do, productivity skyrockets. Ember is a more traditional framework using the MVC pattern with custom components.

Ember suffers from a rather steep learning curve due to its heavily opinionated approach to building apps. Additionally, the rendering performance is not as good as the recent arrivals on the scene.


React is a view engine. It houses the view logic, the structure and the style in one component using a custom language called JSX. This component is transpiled into plain JavaScript before being deployed to the browser. Since it’s just a view engine, additional libraries are required to make it work like a web application – react-router, redux/flux for state management, and any http client.

React is very modular so users can pick and choose the libraries to handle non-view aspects of building web applications. This is both a blessing and a curse due to the fact incoming developers may not be familiar with the libraries used by the team resulting in longer ramp up. Additionally said libraries may become deprecated or mutate over time creating a discrepancy between our code and the current releases that other devs may be familiar with. Did anyone say Node?


Lastly, Vue is a library with a component architecture and prides itself on its approachability. Truly, it is possibly the easiest framework to get started with, and it is also modular like React. Unlike React, however, the author of the framework created core modules for routing, http and state management, so no need to look to 3rd parties. Vue is also extremely fast and has very small overhead.

Vue does, however, introduce some custom markup to the HTML which breaks standards compliance. Components are also (realistically, though not necessarily) stored in .vue files which like React JSX have to be compiled down into browser-readable code. Additionally, Vue’s community is not so large, and the framework does not easily take in custom components (none of the frameworks do, except Aurelia). Thus, there may be additional development time required for custom controls if they’re not present already.

All Frameworks

All frameworks suffer from tooling issues, but that’s the [Front-end] world we live in these days. The TypeScript compiler generally takes care of bundling modules and transpiling modern syntax to browser-readable JS. There are multiple build systems and every year there’s a new one, no joke. 2014 was Grunt, 2015 was Gulp, 2016 was Webpack and 2017 will see the advent of Rollup.

All frameworks also often suffer from the “todo syndrome.” Documentation showcases generalities like event binding, routing and templating, but never goes into state management or other advanced topics. That information is listed in the API, but it’s not tutorialized anywhere except possibly StackOverflow by a smart JavaScript developer. Angular 2 actually does the best job of mitigating this – their documentation is legendary.


Having recently built with Angular 2, React and Vue, I would really like to give Aurelia a shot. I played with it when it was in Beta, but that was a year ago when exploring routes to take with the Microsoft Academic project. If I were to make the call today, I would go with Angular 2 simply because I know it the best. However, I am leaning towards Aurelia just because it’s extremely standard compliant, which means any random JavaScript developer will be able to jump in and code without any training. That cannot be said for any of the other frameworks except maybe Vue with limited time spent in the docs.

ASP.NET Core and Node JS

Since starting my new gig at Kymeta, I’ve done a lot of research on… well, lots of things. One of the things I’ve researched was ASP.NET  Core vs NodeJS as a hosting platform for web applications. I built a fully functional prototype on both and summarized my thoughts in a report. I figured I’d share the neutral part of that report here, as others may find it useful as well.

Platform Comparison

A high level tech and service comparison of the two web platforms.


  • There are several similarities between NodeJS and ASP.NET Core:
  • Both frameworks use libuv (Kestrel is a fork of libuv) to manage threading, loops, I/O, etc
  • Both frameworks enshrine the asynchronous programming model
    • NodeJS via Promises
    • ASP.NET Core via Tasks (also present in older versions of .NET)
  • Async/await model
  • Both frameworks (on NodeJS, Express and Hapi) use the OWIN pipeline model, allowing for easily pluggable middleware
  • Both frameworks have excellent learning materials and available documentation


  • NodeJS has a single thread for executing sync JavaScript and many worker threads for background async operations
  • ASP.NET Core has multiple threads for executing sync .NET code and many worker threads for background async operations
  • NodeJS apps written in weakly typed JavaScript (possibly TypeScript, which has community-driven typing support)
  • ASP.NET Core is written in strongly typed C#, where typing is enforced by default
  • Company support for NodeJS modules is usually non-existent, because packages are developed by individuals and not marketed
  • Microsoft provides support for ASP.NET Core
  • Front end developers can quickly get started with NodeJS since it uses the same programming language – JavaScript. This expands the pool of available engineers to hire. ASP.NET Core’s C# and .NET library language, while easy to learn, is not as ubiquitous

The main difference is that ASP.NET Core does not enforce the async programming model due to its ability to spawn multiple threads (and then each thread potentially also having several worker threads).

ASP.NET Core Overview

Let’s take a look at an overview of the framework.


  • .NET Core is a complete rewrite of the ASP.NET framework
    • Pipeline, hosting model
  • Completely open source, hosted on github
  • Cross-platform – Linux or Windows!
    • Thus, it can be hosted either in AWS, Google Cloud Platform or Azure, or all 3!
  • Can run either on .NET Core or the full .NET 4.6 Framework (full .NET is only Azure)
  • Not tied to IIS. Can be hosted behind any web server via reverse proxy
  • Can use any OWIN compatible server, not just Kestrel
  • Modular, can run inside containers (Docker)

.NET Core was rewritten from scratch, because .NET Framework was too large and sluggish which made developers weary of working with it. A lot of features of the original .NET Framework made it over to Core, but ones which were Windows-specific were cut (WCF, System.Web, etc).


A good bit to read about ASP.NET Core’s performance is at the techempower blog which measures web server performance across over 200 different implementations. It can be found here: https://www.techempower.com/blog/2016/11/16/framework-benchmarks-round-13/


By delivering cross-platform performance alongside their development toolset, Microsoft has made C# and ASP.NET one of the most interesting web development platforms available. We have a brief message to those developers who have avoided Microsoft’s web stack thinking it’s “slow” or that it’s for Windows only: ASP.NET Core is now wicked sick fast at the fundamentals and is improving in our other tests. Oh, and of course we’re running it on Linux. You may be thinking about the Microsoft of 10 years ago.
The best part, in our opinion, is that Microsoft is making performance a long-term priority. There is room to improve on our other more complex tests such as JSON serialization and Fortunes (which exercises database connectivity, data structures, encoding of unsafe text, and templating). Microsoft is taking on those challenges and will continue to improve the performance of its platform.

Out-of-the-box Features

  • Incredibly easy to use Dependency Injection baked into the framework
    • No need for third party libraries like Unity, but can use those too
    • Easy to swap out implementation of key app services at any point, since when using DI, coding is done against an interface, not an implementation
  • Fully modern HTTP request pipeline
  • Apps are easy to configure with a pluggable configuration system (JSON, CLI, Environment variables, custom…)
  • Can be self-hosted on any system, because dependencies come bundled with the app!
    • Everything is a Nuget package, including the framework
  • OWIN pipeline allows for easy use of already existing OWIN-compatible middleware, as well as writing your own should the necessity arise.
    • ASP.NET Core comes with (as separate packages) Routing, MVC, Logging, Error Handling, Static File Server, Identity (authentication), EntityFramework (data access), Logging, Caching and more!
  • Easy to host front-end code without having to embed in CSHTML files. Supports all modern front-end tech stacks like Angular 2, React, Aurelia and others
  • Kestrel implementation out of the box, but can use any OWIN-compatible hosting solution

Core Benefits

Aside from the features listed above there are other benefits to using .NET Core over its competitors:

  • C# 6 language
    • 1000% better than JavaScript in almost every respect
  • This warrants repeating: a lot of solutions to common web development issues and tasks are already built by the ASP.NET team to work with ASP.NET Core
    • Don’t need to use 3rd party solutions that may or may not have support beyond a single github issues page
    • No conflicts between 3rd party packages
  • Microsoft’s backing and support
    • They dogfood this on internal projects
  • The .NET Core pipeline provides interfaces (OWIN style) for various app features like Logging or Caching. It’s up to the developer then to choose whether they want to use Microsoft’s solutions, or 3rd party (like cachemanager, nlog) or write their own. Writing custom providers is pretty easy, too.


Choosing DotNetCore: http://mode19.net/Posts/DotNetCore

Deploying to AWS EB: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/dotnet-core-tutorial.html

Life & Tech Update

After my contract with Microsoft ended in late August, I took a month off for vacation. I traveled to Japan for 18 days, and took two weeks off afterwards to get over the jetlag and take care of some personal matters. Last month, I started seriously looking for work. I’m also brushing up on the newest technologies, and working on my own side business.

Lately, I’ve really been into NodeJS, specifically Hapi. I love it. It is as bare bones as it gets, yet provides all the functionality you’d want in the way of plugins. It’s incredibly quick to get started with and easy to understand. Hapi’s documentation is also pretty solid, so anyone with any sort of programming experience can get up and running in minutes.

In addition to Hapi, I’ve been writing Node stuff in TypeScript (using Visual Studio Code). Hapi is (mostly) covered by typings so I get intellisense and code completion for JavaScript… which is amazing. It took a bit of adjusting to get used to TypeScript, and to get the build process going, but now that I have it down, I’m very hapi with it. I started working on a side project to further learn the framework and get used to ES2015 syntax.

I’m happy to see strong types, classes, methods and interfaces come to JavaScript (though their implementation deep down is apparently a bit misleading). When I code in JavaScript, sometimes I miss the cleanliness of C#. Now, I can feel less dirty with the aforementioned programming constructs. And lastly…

On the note of programming constructs, I’ve been hitting the books refreshing Design Patterns (singleton, repository, etc) and Design Principles (SOLID). Although no interviewers generally ask for these, I feel like whatever job I work at next, I want to employ these coding practices and write spectacular code. Maybe it seems trivial… but something about dependency inversion just makes me warm inside.

So yeah, looking for work, studying and working on side gigs.

JS Framework Thoughts 08/16

It’s been a while since I’ve posted. I’ve been busy.

Besides having been working with Knockout at my day job every day, and consequently learning its ins and outs, I’ve also dabbled in other big frameworks out there on the side. In chronological order:

  1. Knockout is great. It’s easy to understand and very easy to get started. However, it’s not very easily testable and it’s not “modern”. I think it’s probably on its way out, unless there’s a major re-write.
  2. React was easy to get started with, but complexity escalated very, very quickly. When you want to build just one component on a page and follow the Hello World guide, it’s not bad. But when you want to grow your application, forget it. There are better choices out there such as…
  3. Vue is a great, small framework which combines the best of Angular, React and Knockout in one. It’s modular like Angular2, it’s blazing fast like React and it’s super easy to get started like Knockout. One problem with Vue is that the build process for it (like for React) kinda sucks to get running.
  4. Aurelia is a phenomenal framework. It’s really straight forward, uses ES2015, has all the new, cool toys like dependency injection, decorators and module support. However, in my several week stint with Aurelia I learned that they’re just not yet ready for production-level applications. There’s been a lot of API upheaval in the development process with things getting renamed and apps breaking in the process. When RTM 1.0 is out and the dust settles, I might come back and have a look unless…
  5. Angular 2 keeps its tendrils in me. I’ve just started working with it a few weeks ago, but I can already see how powerful it is. I’m literally eager to go home and keep building in Angular 2. That sounds weird, I know. Angular 2 RC4 seems pretty much ready except for a couple minor bugs. Its router is powerful and easy to understand. The documentation is phenomenal. It runs on TypeScript. One complaint I have is that the http module is not intuitive.

Before starting on my current contract, I worked with Backbone for 9 months and wasn’t a big fan. In the future I would like to give Ember a go. If I recall, Ember, like Angular 2 was super opinionated.

Bottom line is, most of the frameworks running on ES2015 syntax are all converging into the same direction -> components. I think Vue, specifically, is exceptionally good at it, but it’s not really a full app framework like Angular 2. I think whatever I build now on my own time will be using Angular 2.

Personal Finance Win10 App Update 1.1

After about 2 months of  パーソナルファイナンス being out we’ve had about 100 downloads and about a dozen sales! Unfortunately there’s been zero feedback on the Windows Store and being a one-man team leaves a lot of open holes in the development process — especially QA. I figured I need to find out when / if things go wrong so in this new release I threw a lot of things into try-catch blocks, and sprinkled some minor instrumentation throughout the app. I also just recently did this at work (on a much larger scale), it’s fresh on my mind, so I figured why not!

There are a few bug fixes too. Two big ones which I’m surprised nobody complained about, was terrible performance on adding expenses after a couple dozen are already in the app. Not sure how I didn’t catch that before, but fixed now. The problem was that the table is dynamically calculated from an array, and every time an item is added, the table is repopulated and recalculated. The computation procced with every addition to the table, which slowed rendering to a crawl. Adding a delimiter on the subscription unblocked it and it’s now near-instant.

Another interesting bug was with entering numbers in Full-width Kana. JavaScript (or rather, the Chakra engine that powers UWP Apps) didn’t know what to do with it, and so it thought it was an empty string. I found a parseUniInt library that someone built, and used that to turn full-width kana into regular numbers that Chakra can understand. Unicode… it’s gonna get ya…

Lastly, I added a few new features!

Settings Page:

Settings Page

In case you can’t read this… the top purple header says “Export and Import Data.” You can now export and backup your data into a CSV file, and import it back! In the future, I plan on adding an option to enable this backup feature to fire off automatically when you exit the application. The bottom section allows you to choose your app’s color theme. As you can see here, it’s purple!

I also added a way to view your budget for the entire year, rather than just individual months, a way to favorite accounts so that they show up at the top in the transaction input screen, and also a “weight” to each account so that the most used accounts always show up at the top (below any favorited accounts).

Overall this 1.1 release I feel is pretty stable now and should give users a bit more information about and control over their data, as well as improve the experience with the app overall. I’m pretty proud of this product, and I want to keep building on it in the months and years to come!

Personal Finance Win10 App – Part 2

In the last post I wrote about the initial framework decisions and some challenges I came across when building the app. Here I’d like to tackle the individual parts of the app and the logical challenges I encountered while writing the code.

The app in its initial version is split into five sections: Overview, Transactions, Budgets, Reports and Categories. The last one on that list, Categories, is simply a way to give users an ability to add custom transaction categories such as Shopping or Groceries and use them in the app. Nothing challenging there beyond filling out a database table.

Overview is the landing page when users open the App. Here, they can see their account totals, cash and debt totals and spending by category in a pie chart. Remember, it’s in Japanese…


Adding and removing accounts is pretty straight forward. They’re just simple database operations. When adding an account, you’re asked for the name, a type of account (bank, cash, credit or loan) and the starting balance. Initially, adding and removing transactions modified the balance in the database, but after a while I noticed it started getting convoluted. I re-wrote the math calculating the balance for each account and now the balance is dynamic based on the transactions attached to that account. So if you start with 10000, and add a transaction for 1000, the transaction gets written to the database, but the account balance remains as is.

Another fun exercise was getting the data for the graph all formatted correctly. Thankfully UnderscoreJS has a lot of handy functions that deal with filtering out objects and arrays. The graph can be shown annually or monthly, and you can scroll through months or years. The data is calculated dynamically, because all transactions are stored in memory, not read from the database. This was another conscious decision, though my feelings are somewhat mixed here. Storing transactions in memory makes the app extremely responsive, but reading from a database might have been a better option given performance down the line. The database, btw, is SQLite.

The transaction screen is a list of accounts as categories which allow you to sort and view your transactions. Since they’re all loaded into memory at boot, paging is super fast. There is a list of 10 pages maximum right now, but transactions are all loaded regardless. I think down the line I might add the ability to view transactions in chunks sliced by date ranges.


There was nothing particularly challenging about coding transactions. Hidden here under the ‘Add Transaction’ screen is the ability to edit, which looks similar to the add screen, but has the information from the record already pre-filled. Paging was pretty easy to put together, and sorting by date simply reverses the array. Selecting the account or the transaction type (income, spending) on the left, filters all transactions by that account or spending type only.

In Part 3, I’ll cover the last two sections: Budgets and Reports. Budgets was probably the most challenging conceptually, as well as logically, from a coding perspective. More on that later!

Personal Finance Win10 App – Part 1

Before I write another word, let me just list the JavaScript libraries I used for this project: Knockout, Pager, Moment, Numeral, Underscore, CanvasJS, jQuery. I am now intimately familiar with Knockout, Pager and Moment. I spent probably several hours fiddling with Moment’s formatting, parsing and setting methods to get the right settings for Japan. Oh yeah, this app is for the Japan market, so it’s entirely in Japanese.

Alright so…

I started out with WinJS. Microsoft’s JavaScript offering is actually pretty cool … if you’re building Microsoft-looking apps and want to use Microsoft-looking controls in your app. They’re great when you want to get a prototype of something up and running quickly. I’m guessing these controls also pretty much the default a lot of developers go with when coding their apps in C# with XAML. I, however, opted for JavaScript, because I feel a lot more comfortable in that world than C#.

Ultimately, I ended up dropping WinJS and going with the tried and true jQuery UI with Knockout bindings. However, I dropped those too after a couple days and defaulted to my own solutions, because I needed more granular control over how content was being rendered. I’ll mention this now and probably again later in this article, but rendering Kana/Kanji is totally different than English or any other Latin-based alphabet. Buttons suddenly go from being 150 pixels wide to 50 and look weird. It really didn’t work with any of the jQuery UI widgets very well since they use pretty tiny font to achieve good usability.

To get the widgets I needed, I had to write my own components. I wrote my own datepicker, because the way date is displayed in Japan is different; not just the order of day, month, year, but they also display the actual Kanji for the day, month and year after the number. I wrote my own dropdown, because I needed the font to be bigger without breaking wrapping inside the controls. I also wrote my own filter, styled all inputs and wrote a few other custom components tailored specifically to Kana/Kanji.

Another thing I needed to write that doesn’t exist anywhere is a Knockout binding wrapper for CanvasJS. I actually started out with ChartJS as my graphing library of choice, but after a week of fighting with it, I dropped it like a bad habit and dipped my toes into CanvasJS. Love it. Awesome library, 5/5 stars would visit again. While the app currently only has one pie chart graph, I plan on adding two more in future releases, and I know CanvasJS can build them for me.

Last thing I want to mention in Part 1 is about mobile. Before I even wrote one line of code, I did a bit of market research. My goal was to target a market that wasn’t flooded with Personal Finance apps. Android and iOS are full of them for all languages (even Afrikaans). Windows 10, or actually Windows in general is theoretically a platform with a potentially wider audience, despite the [currently] smaller install base. Thing is, Windows Phone is a joke pretty much everywhere except Seattle where Microsoft basically slips them under your pillow while you’re asleep. So to sum it up: Android and iOS are flooded and Windows Phone is non-existent. Desktop Windows however … is nearly barren in this category, especially in foreign markets. Bam!

In the next part I’ll cover some of the logical challenges I encountered while writing the app both from design and coding perspectives.

Investing, 4 months

This post is a short primer on my experience with the investing world after just a bit over 4 months. I’ve done a significant amount of research and learning in July and part of August in an effort to establish a base understanding of how the investing world works. After all, this is money – my money – that I’m playing with, so having a good idea of where it’s going and what’s going to happen with it in a month or a year is a good strategy.

Before investing anything, I started out by reading a pretty good write-up about investing in general. Why do it, why it’s good for you, where to start, and some key terms you’ll find in the investment world. You can check out this write-up here.

I googled a lot more, but I don’t have all the links saved anywhere, because I just absorbed the knowledge and didn’t think I’d need to refer back to it. At the top level, it’s not really that complicated. I learned about individual stocks, mutual funds, options and other various ways to distribute your capital. After I knew what all the different options were, I looked for advice on what to invest in and how to get started. This is the tricky part, because everybody’s got an opinion and these opinions vary with risk tolerance. Since everybody’s got a different risk tolerance, these ways to invest will differ from person to person.

I started reading Financial Samurai to get accustomed to the lingo and the general notion of putting your money into, seemingly, the void. Non-tangible investments seem a bit scary after all, because you don’t actually get anything physical to hold in your hand when you deposit that money. That said, it seems a lot easier to spend money “virtually” … though maybe that’s because I’m so used to it as a gamer… buying up virtual goods with virtual money, or sometimes real money.

Lastly I perused Bogleheads, but other than mutual fund recommendations I wasn’t able to find anything immediately interesting. There’s a lot of chatter on there, not necessarily related to traditional investing (also the interface sucks, but that’s just my UX spirit aflame). I did find good recommendations for mutual funds to invest in, so that’s good!

After about two weeks of reading about stuff, I opened a Fidelity account and bought my first set of mutual funds. I don’t recall what my risk estimates were, but I ended up going with…


10% in US bonds (safe), 65% in US stock and 25% in foreign markets.

Unfortunately, Fidelity’s user interface is rather unintuitive. After wrestling with it for 3 months and investing all over the place, I got fed up and opened an account on Wealthfront. Before you click that link, I must warn you that it’s an invite link to open an account on Wealthfront. If you use it, you get a free $5000 bonus added to your pre-fee cap (ie. they charge a fee for after $10,000, but if you use the invite link, you get to hang out fee-less for $5000 more, so $15,000). Now, what is Wealthfront?

It’s a robo-adviser. Pretty much someone wrote an algorithm to invest people’s money based on risk tolerance as an input parameter, and now they’re selling that service. As of this writing I believe they manage over $2.5bln, so .. given their fee structure I would imagine they’re making a very healthy profit. This in turn makes me feel a bit more secure about the future of the service.

Finally, what type of accounts should you open? The common wisdom (which makes perfect sense) is to open and fill up your tax-free accounts first: IRA, 401k. Everybody has access to an IRA and you can start filling it up today. 401k is something that’s offered through your employer (or in my case, I have my own business, so I have a 401k through that). There are other options too, if you’re self employed, such as a SEP-IRA, which has a few limits on it, but worth investigating if you’re in that boat. Once you have your tax-free accounts filled up (say, you don’t have access to a 401k and you’re not self employed, so you only have an IRA account), you can open a regular brokerage account which is taxed just like any other income. Obviously only your capital gains are taxed, so if you make $1000 in interest, you pay $150, etc.

Investing is a complicated endeavor, but I strongly suggest you start as soon as you can. With the power of compound interest, you, too can be a millionaire. Start with $1000, add $1000 monthly, with a conservative 7.5% interest rate, compound every month… after 10 years of that you will have $180,000… Now imagine you’re putting away $3000 every month instead, that’s $535,000 after 10 years. It’s never too late to start, and it’s basically free money!