Saturday, June 11, 2016

Git and GitHub in 5 Minutes for Windows


This is Git in Five Minutes for Windows

After this, you should be able to

  • Create a git repository on the command line
  • Add files for staging
  • Commit files
  • Push files to a remote, ex. GitHub

0. Download Git for Windows Here

1. Configure Git

git config --global "Full Name Here"
git config --global "Full Email Here"

2. Creating a Git Repository

git init

3. Create a File, Stage and Commit It

echo $null >> text.txt
git status
git add .
git commit -m "Initial Commit"

4. Create a Profile and Empty Repository on GitHub

5. Get the URL from GitHub and Push Code to GitHub

git remote add origin url
git push -u origin master (you may be prompted for GitHub login + username)

See the file successfully on GitHub!

Future Steps

1. Learn what a branch is (the whole point of DVCS - distributed version control and Git!)
2. Learn what a fork is (the whole point of GitHub!)
3. Fork an existing open source project with an issue you can solve 
  • Pick a language, or learn a language! (JavaScript / C# / Java / C++ / C / whatever!)
    • If you don't know ANY programming, play around with this then take some "intro to programming" or "learn programming" course (preferably one that's fun)
  • Start small, change one line or handful of lines of code!
4. Commit and push your change to your own fork, then issue a pull request!



Hope this tutorial was helpful

~ B

Sunday, February 21, 2016

Advanced MVVM Concepts - MVVM Practical Theory and Experience Part 1


This is Part 1 of short series of blog posts about practical MVVM and its usage. The goal of these posts will be to give information not readily available through documentation or examples, mainly how to construct a complex data-driven application with non-trivial issues.

This post will discuss the practical theory about MVVM and it's application in real-world applications. For theory and an introduction, look Martin Fowler's article, or look at any introductory textbook to Software Engineering/Software Architecture.

We will waste no time introducing what MVVM is and simply dive into the details (with a short refresher).

What is the Problem we are Solving?

I am not a fan of learning or increasing complexity of an application just for the sake of software purity or self-edification. Hopefully you are not either. Therefore, the question must be asked, what problems does MVVM actually solve? What is it's use? Is it worth the additional complexity? In corporate/Software Architecture parlance, what is the "use case" that MVVM applies to?

I am assuming we are solving a business problem. Business problems have a specific purpose, use and scope. In particular, we are not looking to reinvent the wheel and demonstrate technology or do technology for technology's sake (although valid reasons, we aren't talking about the technical merits here). What we are wondering is how we can solve business problems in a fast enough, maintainable enough and quick enough way that the business continues to be viable, extensible and expandable.

( of Business)

So, what types of problems are we trying to solve?

1. Business problems are data problems. Data is the business, moving data from point A to point B. However, the days of simple data-entry are gone. Dumping data from the database onto the screen and saving it is a trivial, simple task. In order to create a product of any value, the relationships between data points must be maintained, because without relationships there's no meaning for the data.

2. Increasingly, data visualization is just as important as data processing. Without reports, without diagrams, without charts, without Key-Performance-Indicators, data entry is useless. This is beyond the scope of this series of blog posts, but is obviously the next step after mastering data integrity.

3. More increasingly, the interface has to be attractive enough to provide a superior user experience. Business users are now computer experts, unlike years or decades ago and expect the same experience from top-notch consumer software in their business products. Things like milliseconds of delay, buggy interactions and non-standard interactions are unacceptable. In addition, this is not the heyday of the Internet -- the market is now mature, and mature markets demand superior customer experience as the key (and sometimes only) differentiator. This is again, beyond the scope of this series of blog posts.

We will focus on problem 1, non-trivial relationships between data points. In particular, we will focus on how to represent data points with multiple relationships between data points and a hierarchical relationship (since most business problems are hierarchical) and how to create and architect software which takes this reality into account.

What does all that mean for the Developer?

In general, what that means for the bog-standard Software Developer in his day-to-day tasks is three things.

1. The primary task of a backend Software Developer (and increasingly frontend developers as well) is to create tools, or user-interfaces. This immediately directs us to some sort of design pattern (after all, UI problems are a solved problem) and immediately to MV***, *** being the question mark. The model is a given, since we are solving business problems and all business problems are modelled. The view is a given, unless we are creating backend data processing software with no user interface.

2. Unless you are lucky enough to work somewhere you can do whatever you want, you are under the gun. Particularly for a business, time is money and time is lost market-share or lost revenue. Therefore, you can't take forever reinventing the wheel from the ground up. Luckily, a lot MV*** frameworks already exist.

This is a good introduction to the differences between MVC, MVVM and MVP. In particular, we will select MVVM, because the business problems we will try to solve are non-trivial (advanced relationships between data points).


We will use technology meant to solve a business problem. This immediately leads us to -- you guessed it -- Microsoft. However, the solution we will select is KnockoutJS, the Microsoft-recommended way to accomplish advanced UI binding. However, the concepts and code samples should be clear enough to port to any framework or programming language.

The next blog post will start with a practical example of MVVM (the trivial/kitchen sink example) then discuss the problems developers immediately face when trying to implement realistic business solutions.

(Link To Be Released)

Sunday, January 3, 2016

JavaScript - Converting JSON to XML

This post discusses how to convert between a JavaScript object, XML and JSON (not the same as a JavaScript object).

(Un)Surprisingly there is no native function to do this. There's various implementations of conversion like JXON or jQuery's parseXML, but no official standard. So chances are every developer will have to work with converting between these data interchange formats (and native JavaScript objects) depending on the use case or circumstances.

JavaScript Object to JSON is the most straightforward. Just use the browser's native JSON.stringify (or use a shim if you need to support older browsers). Or is it? Consider the following case:

var obj = ["lightsaber", "blaster", "vibroblade"]

All of these are Star Wars weapons. But this data structure has no idea what's inside it. It doesn't know that these are weapons, or star wars weapons.

So the conversion then, is not trivial to XML. So care must be taken when converting between a JavaScript object and JSON, to send the metadata of the JavaScript object along.

The notation I've seen most used is the $metadata attribute. It has the added advantage of $ not being a valid XML tag character, which means you won't accidently create a node with the metadata.

So instead, obj becomes this

var obj = {
     $weapon: [

The following is a sample implementation of JavaScript object to JSON

And another sample implementation of JSON to XML

Hope this gives someone ideas, or helps someone