My next steps - My own project and 100 Days of Code

I finished the book Head First C#. What is the next step? I don't want to lose any of the information I was supposed to have learned. I have another book "Beginning C# Object-Oriented Programming." I look at the book every now and again and think I should start reading it. I probably will very soon. But, I also started thinking that there is no better way then to program my own personal project to help me feel invested in the programming and gain a benefit for something that I want to do.

I was invested in learning while going through the book, but maybe not as invested as I could have been. I took time to take notes while reading and really tried to understand what the exercises were trying to teach. I may have not always had an idea of where, outside of the written steps, would I be able to use the code. My new idea, using what I learned to create my own project. And what better way to stay accountable then posting on twitter every day on the progress I am making than making a commitment with 100 days of code.

I would be more invested in my own project as it is my idea and I would really like to see it come to life. Over the years I have had many ideas that I wanted an app that filled a "need" (or at least a need for me). Some of the ideas have apps out there and sometimes I have downloaded them (such as when I wanted an app that not only kept recipes, but made a grocery list for me). Others I have just looked at and said, I might try to create my own. The first one I wanted to try is a movie database.

I have a lot of movies and can always go look at the movies, but sometimes I want to be lazy and just pull out my phone to see what movies I have. I decided to jump in. Right away I jumped in and thought I need to do an API. Day 1 on my Twitter feed: Starting the API. The API would allow me to either later create a web, desktop, or phone app. I got going. I was reading through tutorials and watching videos, I felt I was learning and even got an API to send data back (although hardcoded data).

Learning is good. However, as I kept going, I was missing something. The tutorial of creating the API came with the database already created and the interactions between the API and the database were already created. I learned this quickly. The video I was watching talked about the data context, at work my co-workers talked about context on the API we are building as well, but I wasn't sure how the context was created (or really how the context interacted where it needed).

Time to take a step back. What is the context and how does it talk to the database? Luckily, I was talking to my co-worker, Peter, and he mentioned that Entity Framework is what we used at work. Eureka! Entity framework is the first step I should take. I found a Pluralsight course on Entity Framework 6. And this helped! Making sure Entity Framework got the correct relationships in the database took me a while. I think what I was missing was that each of the classes had to refer to each other. My "MoviesOwned" class had to have an object for "MovieTitles" and "MovieTitles" had to know about "MoviesOwned." Once I added all these relationships Entity Framework recognized my relationships.

public class MoviesOwned
    {
        public List MovieTitles { get; set; }

        public int MovieTitlesId { get; set; }
     }
public class MovieTitles
    {
        public MoviesOwned Movie { get; set; }

        public int MoviesOwnedId { get; set; }
    }

I was able to see that the relationships were in my model I used a tool called Entity Framework Power Tools. However, I use Visual Studio 2015 and this didn't show up in my list of Extensions and Updates. However, Julie Lerman had a great blog post on how to fix this issue.

I know know the context is the database context. It has an object from each of the classes so it knows what needs to be created. Entity Framework is then able to see what database objects you want and looks at the class of each of those objects to determine the structure of the database.The key is to have your context class inherit from DbContext (I believe this comes from Entity Framework)

After deployment, I see my database in SQLExpress (I need to figure out how to not use Express so I can host the database somewhere else).

The question becomes, is the structure really correct? And will I be able to write code that will communicate with the database correctly?

You can see daily progress on Twitter, @robertjorg.
You can see my daily log (called log.md) uploaded to GitHub: https://github.com/robertjorg/100-days-of-code/
I am being transparent and posting my work to Github. Maybe someone will see issues I am coding and plus I am blogging about what I am doing anyway. That link is: https://github.com/robertjorg/MovieDatabase

I hope to blog more because I should be coding every day and it is something I am choosing the project so I hope to be more attached to the code.

"The length of a file should be directly related to the endurance of the human bladder."
-Alfred Hithcock

DevIntersection - Day 4

It was another day filled with learning and sessions. We started the day talking about a topic that everyone needs to pay attention to, Security. Cyber security needs to be our number own priority and it can no longer be a perimeter security, we need to take security to the identity level. Almost all security breaches have come from credential leaks. There are so many tools that Microsoft, Google, and Facebook have created to help in the area of security. We should try to take advantage of what they have already built to help with our own security. We need to build security that both satisfies our IT departments, but also the customers/users. This may be hard at times, but is usually do-able. Microsoft has taken some great steps and is able to determine if you are able to paste from word into outlook based off the word document and the email address you will be sending from in outlook. If it is a work document in word, you will not be able to paste to a non-work email sending address. pretty neat stuff.

The next session I went to was called Application Debugging with IntelliTrace with John Guadagno. I will be honest, there weren't many notes that I took during this session. He did mention that his slides should be posted and that his speaker notes would be really helpful. Here are some notes that i did take. A few quick notes on IntelliTrace:

• Allows you to record events and method calls for your application. The black box for your application. See Key events and see what it is doing throughout the lifecycle. Will also keep values of variable and objects.
• Allows you to examine its state at different points in the execution.
• You don't have to have Visual Studio installed and can just have a collector on the machine to see what is going on

IntelliTrace can collect many different events. You can configure what to collect and save the environment to be used later or with certain projects. It can collect:

• Debugger Events - Value in local window, auto window, and data tips
• Exception - handled and unhandled
• .NET framework events
• Function name
• Values of primitive data types passed as parameters as function entry points and returned at function exit points
• Values of automatic properties when they are read or changed
• Pointers to first-level child objects, but not their values other than if they were null or not

The tool seemed to be really helpful if you don't have Visual Studio on a machine, but you need to see the steps that were taken to get a certain error. I could see this being useful when we have bugs on client computers but cannot reproduce the bug locally. Install the client and see the variables and steps that were taken on the clients computer. Now we just need the clients to allow us to install on their servers...

The next session I went to was Enabling DevOps in the Cloud with Steve Lange. It was great to see that most of what Steve talked about we already do at work. He mostly talked aboutt he tools that help get to DevOps, which were Microsoft tools as he works for Microsoft. He discussed using VSTS and all the tools available through VSTS. All of which we already use. I did learn about extension called the Test and Feedback extension that allows you to record the steps you take through a browser and enter a bug directly into VSTS. Pretty nice tool.

Steve also talked about Azure App Insights (can be used by non-Azure apps to get data and do analytics on the apps.

I then jumped around from The Intro to Xamarin and ASP.NET MVC - Development to Deployment. Neither one of these sessions provided any real new information. The Xamarin session was talking about how to load Xamarin onto the your computer, but wasn't about creating any apps.

I then went to ethe ASP .NET MVC class. This was maybe a mistake. I walked in and was a little lost on what her was talking about. there were pieces that I did know form working on our applications at work, but it seems I should have been in the session the entire time.

We finished the day with a key note on Angular 2. It was called Angular 2: Released, Greased, and Increased. This was a repeat of what I was told on Monday and Tuesday in the workshops. Really, the only new information was how come Google took the direction they did on Angular 2 and the performance benchmarks they used to increase the speed of Angular 2 (which is much faster then Angular 1)

Tomorrow is the last day. I hope the sessions are great and we get to end strong.

DevIntersection - Day 3

Today was the first day of the sessions at DevIntersection. It started with a keynote session by Scott Guthrie of Microsoft. The title of the talk was "Movile-first, Cloud-first Development." It was a good speech by Scott. I always feel the keynotes are more about a quick glance of what the speakers can do without much team to show you what was done. I guess it leaves questions and will have you go experiment more on your own. Microsoft is coming out with some great products and I will definitely look at more information on the Microsoft products.

Then the sessions began. The first session I attended was Understanding the Windows Desktop App Development Landscape by Brian Noyes. The first topic, the mortality of the different UI frameworks. The question when looking at the frameworks that we need to ask is, what do we consider dead vs. matured. The different frameworks may be at different stages in their lives. The frameworks we currently have:

• Windows Forms - Many will think that windows forms are dead. There are many projects that are built on Windows Forms and should not just be dropped due to thinking Windows Forms are dead, just mature. Forms are just mature. However, Brian would not start a new project using Windows Forms.
• Silverlight - This also not dead...yet. The browsers are the ones that are killing Silverlight. It is not yet yet, but it is in the trauma unit on life support. Definitely do not start a new project using Silverlight.
• Windows Phone - Bloodied on the battlefield. Survival: questionable. Only time will tell.
• WPF, UWP, Xamarin, Single Page apps are all alive and well.

WPF is mature, it has been around for almost a decade. In computer time this should be gone. However, it still lives on and probably will for a long time to come. There are many features WPF that are great. Some of them:

• Data binding validation
• Implicit Data Templates
• Dynamic Resources
• Custom MarkupExtensions 
• Multi-Bindings
• and more!

UWP allows you to develop for many different platforms, like the desktop, mobile, and XBox. Great for touch, pen, or keyboard/mouse. UWP provides a better app security and provides isolation from other apps on a computer. You are able to sell these apps in the Windows Store. Great features available such as:

• Cortana integration
• Low power consumption
• Ability to move apps into UWP using wrappers

Xamarin is a great crossplatform tool using C#. You can write an app and share it across platforms including iOS and Android. The logic code can be reused across platforms and only UI will have to be written for each platform you would like to include for your app. Finally! Windows can develop for iOS (although to develop for iOS you still are required to have an Apple computer).

Single Page apps are cross platform are well. All they require is a browser. This can be written in HTML, CSS, or Javascript (hey! My workshops were about typescript and Angular 2 which compile into JavaScript!). The single page apps can use the same architectural patterns as a well designed XAML desktop app, just using different syntax. With a responsive design you can create an app that will work on desktop and on mobile web browsers beautifully, or at least sufficiently.

The next session I attended was How to Be a Good Community Member by Contributing to OSS with Brian Clark. Apparently, I like the sessions by the Brians. Throughout college I was involved in the community and did many hours of community service. Open source allows companies to use their products/frameworks for free. Why would anyone want to do this? They probably build something they needed to solve a problem and sent it out into the world for consumption. Should companies pay to use open source? Maybe the payment should come in the form of allowing employees to contribute on work time (my own thought, not own that Brian brought up).

Well there wasn't much I didn't already know or think in this session. It actually was a shorter session and we got out a little early. I think the main take-away from this session was the resources for doing your first contribution to Open Source. Below are some resources shared:

• github.com/code52 - starts a one week project that is easy to jump into at any point
• upforgrabs.net -
• firsttimersonly.com - aggregate certain projects
• yourfirstpr.github.io
• issuehub.io - allows you to focus on the language you are looking for
• github.com/mungell/awesome-for-beginners

Things to think about before starting on an Open Source project: the process for the project, the rules, what are the guidelines of the project, is there a code of conduce, can you run the project locally, is it in a language you are familiar (maybe you don't want to stretch on your first pull request), and more.

Really, think about the project and find one that fits for you to contribute. Communicate with the team and make sure they know who you are and what you are doing. And, start simple to get your name out there to allow people to see you can be trusted and you do work well with others.

My third session was Create an Angular 2 app from Scratch with Dan Wahlin and John Papa. I probably should have skipped this session. It was much like the workshop I did on Tuesday. I hoped that they would start from a blank sheet and add everything we needed. Well, they started with a project that already had the needed files for an Angular 2 app to start working. In fact, they already had a page, Hello World that would pull up. I stayed to see if any new information would be given. There was no new information and I was disappointed. Still Dan and John did a good job.

The final session I went to was Automatic UI generation in .NET by Mark Miller. Mark is a great presenter and had a lot of, shall we say, love for UI. There was a lot of code that Mark had done before the session. He then went through what the code he put in before did, and showed the code a little bit. The dynamic response of the UI is pretty cool and what showed was dependent on what you clicked and the properties on the UI. It was nice to see, I just wish he would have gone more into the code of how to build the responsive UI. 

Onto the sessions for tomorrow. I hope I pick a good set of sessions.

DevIntersection in Las Vegas - TypeScipt, ES6, and Angular 2

Last year I started my Twitter account while I was at Visual Studio Live! in Orlando. I blogged at the end of each day. I meant to do that this year while I have been at DevIntersection in Las Vegas this year. We got to Vegas yesterday for the pre-session workshops and will be here until Friday. There is a little different feel in the Las Vegas vs Orlando environment, but I am not here for the city, I am here for the conference.

Day 1:

Yesterday I went to a session called Making the Jump to ES6 and TypeScript with Dan Wahlin and John Papa. I thought this was an ambitious decision as everything I have done has been done in C#. I was afraid that I would not be able to keep up or understand what was being said. I was in for a pleasant surprise! I was very surprised at how close ES2015 and TypeScript have many features that are very similar to C#.

First, John and Dan talked about the tsconfig.json file and how you can set sourceMap to true in order to enable debugging in TypeScript. How do you get TypeScript to work? You transpile TypeScript to JavaScript or ES. You want to use ES2015? Transpile your TypeScript to ES2015 and you have ES2015 version of your code. I guess the good news is, that if TypeScript is ever not supported, you just transpile it to ES2015, or ES5, or even ES3 if you wanted.

We then started talking about ES 2015 and some of the features now available. These are not all the functions available but the main ones that were covered. I understood most of these. Maps/Sets are like dictionary pairs you can use so that you no longer have to use arrays and splice and slice the arrays. Maps store a collection of key/value pairs with unique keys. Sets can store a collection of items where the items must be unique.

What about those classes? HEY! I use those all the time in C#. There are some that probably don't like this, but it sure helps me understand what is going on in TypeScript. And those Arrow Functions look real familiar! A few weeks ago (maybe two months, who knows) I learned about LINQ  statements and Lambda funcitons. The Arrow functions look close to the same as LINQ statements

Other features we talked about template strings (embed a variable in a string literal), destructuring (create multiple variables, along with their values, in one line of code), default parameters, and rest parameters. All look close to stuff I have done in C#.

We then went to a TypeScript playground at http://www.typescriptlang.org/play/index.html which allows you to type TypeScript and immediately get the JavaScript equivalent back. We then went into types in TypeScript. For example, you can now go:

var age: number = 5;

This will set a new variable age of type number with a default value of 5. Very similar to how variables can be set in C#.You can also used inferred types, where the variable will either be a type any or the actual type if TypeScript is able to infer what the type should be. You can do Enums, again similar to C#.

The next piece I liked talking about where the classes. They  classes look just as they do in C#. Helpful for me!

One piece I really liked in the auto generated properties. These are a little different then auto properties in C#. For TypeScript you create the auto generated property in the constructor. An example:

class CoolCode {

  constructor(public greeting: string)
   {
      this.greeting = greeting;
   }
}

This creates the property greeting in the class CoolCode and also has the value of a string in the constructor called greeting. You can also create gets and sets on properties. This is almost the same as  and auto property in C#. Here is an example in TypeScript:

class Address {
  _houseNumber: string = 0;

  get houseNumber() {
     return this._houseNumber
  }

  set houseNumber(houseNumber: number) {
    this._houseNumber = houseNumber;
  }
}

You can now do class inheritance and interfaces just as you can with C#. In order to use inheritance you need to use the keyword extends. For interfaces you have to have a class with the key word interface and then your class that is implementing the interface will do something like:

interface KillerGame() {}

class AwesomeGame implements KillerGame{}

Other things that are similar to C#:

• Generics are now available
• You can know use namespaces - if you use modules do you still need namespaces?

Day 2:

Today I went to Building Single Page Applications with Angular 2, again by Dan Wahlin and John Papa. The discussion started with the differences between Angular 1 and Angular 2. Since I have never used Angular 1 I did not have any reference. They then touched on what we had gone over the first day in the TypeScript and ES6 workshop.

There was not much more added from what we learned in day 1. We used a tool called Plunker (in order to avoid having to get the correct setup on all the machines in the room) to enter TypeScript and use Angular 2. What was added to our knowledge for Angular 2:

• How to build components - importing and exporting
• Creating and using templates
• Angular Modules
• Binding and Directives
• Services and Dependency Injection
• HTTP and ReactJS
• Routing

Ok, I type it out and it is a little more then I thought. This post is getting really long already, maybe I will have to write another post after I have been able to research them a little more. The workshop today was nice, but they moved so quick that I would like to understand them a little better.

We went through many examples using TypeScript from the day before to create/change single page websites. Of course, we started with Hello World and went from there. I learned today that Dan and John went pretty fast while editing the code and a few times I fell behind getting to a state where my pages weren't working. Luckily, they would save their Plunker and I was able to get to a good state before we moved on too much.

In addition to examples from examples using TypeScript from the day before, I got to learn a little HTML. I did HTML years ago in a college course but nothing big. It was nice for a little refresher.

We were pointed to a tutorial on angular.io that will help getting more familiar with Angular 2.

The progress I make...and forget to blog about

My great friend and co-worker posted a comment tonight asking when I would finish The Quest and post it for all to see. Well, I have been sitting on it for a while. There are some bugs and I moved on in the book thinking I would go back and fix the bugs. Overall, the game works. Some places it is easier for the player and other parts are harder for the player.

I believe I can find out why I have bugs and how to fix them, it is just about finding and taking the time to debug and fix it. Lately, I have been taking on bugs at work and debugging which has given me great experience on what debugging looks like. While fixing the bugs I have learned pieces of C# and .Net that the book hasn't talked about yet.

One example is that while testing and fixing bugs in our API I have learned how to use LINQ statements. In the book this aren't mentioned until chapter 15. By the way, I am now in chapter 10 which is further then I got before in the book. It is amazing how much LINQ statements help. I understand at the surface, but will save trying to describe them until chapter 15.

Chapter 9 talks a lot about streams and how to interact with files within a program. When you are using streams make sure to close the stream or you may lock the file. That can cause problems. Hey! There is a great way around having to remember closing the stream. You can wrap your stream in a using statement. (These are different from the using directives at the top of your files).

You have a lot of If/Else statements? There is an easier way to do this! Use a switch statement. Switch statements provide a mechanism for writing the variable to check once and then say what to do with each different possible output of that variable. Switch simple example:

switch(variabe)

{

case enum.value:

// code to happen

break;

case enum.value2:

// code to happen

break;

default;

// code to happen. Case statements can have the default case which will apply if none of the other cases apply.

break;

}

I also learned about serializing and deserializing your files. Serializing is like flattening your output so it can be desearialized (reanimated) later. Opening a serialized file and trying to read it is...well...impossible for me. It writes it in Binary. Actually, just write a stream reader that deserializes the file and there you go!

I ran into a collision of work and my book while reading chapter 9. At work last week, I was debugging an issue and my team lead asked if I knew what an attribute was. Deer in the headlights. Okay, not really, I did fess up and said I wasn't sure what those were. So, Ben described them to me and walked through the example in the code that we were seeing the issue. A few days later that exact topic came up! Dear Headfirst C#, I actually already knew this before reading! I felt knowledgeable! I may feel that way when I get to chapter 15 too!

Chapter 10, exceptions. I have only read the first couple pages, so not much to report here.

Brett, here is the buggy game The Quest. The github repo is located on my general github.

Hey if you need an excuse manager for work on why you can't come in, chapter 9 has you create an excuse manager so you can remember what worked with your boss and when you last used it. Get your very own excuse manager here!

Sorry for the long read. No excuses, they never go well with the readers...

It is better to offer no excuse than a bad one. - George Washington

Second Time through the Quest

I just wanted to put an update out there. It has been a while since I posted, I procrastinate and if you have read any of my prior blogs you already know that.. I keep telling myself not to do this, but old habits are hard to break. Plus, I listened to a podcast today that mentioned procrastination can be good in some circumstances....posting a blog? Maybe not, but hey, let's go with it.

Anyway, the update. I am almost done with the Head First C# second lab called the Quest. If you will recall, I got frustrated last time and moved on. This time, I am getting closer. I am almost to the point where I could run the program and test what is happening in it. Maybe by the end of the week I will have a version of the game that I could post...I'm trying! (Okay, maybe not the end of the week, the first football game of the season is tomorrow so I am missing one night)

The joy of a pull request

Well, I have finally stopped doing most of my work for the old Sustaining team. I am now doing most all of my work for the Core Services team. That means I am writing code and tests. This week I have been working on writing acceptance tests that will test our implementation of a rest API.

A few things. I have been doing some Pluralsight videos to try and understand what it was we were actually implementing. I think I have a better understanding of what and API is and how we are actually going to use it (although there is always more learning I can do on this topic).

Next, acceptance tests.I have never written acceptance tests and needed to understand what acceptance tests were and what they test. Happy Path. You know, make sure the code is doing what we expect without the weird scenarios (other sets of tests should make sure that these scenarios are caught).

On to the writing of tests! Well, it was more pairing with one of the developers on the team for the first few tests (get, post, and patch) to make sure I understood the framework and what I was doing. After working with Jason on the tests, I took what we wrote and changed them a little, added a few scenarios, and added the delete tests without help.

All the tests were working! It was a total of seven tests, so not many, but the most code I had ever written and it felt good. The green check when running the tests makes you feel great! The code you wrote is actually testing functionality of your code and will add to the program by ensuring it doesn't get broken. What's next? Send in a pull request (I hope I have all my terminology correct, but a code review for Git). That is when it happens.

This is my first code review for anything greater than one line of code. Once Ben was done with the pull request he turned to me and said, "Sorry I was brutal." Really? I think Ben was just prepping me for all the comments he was giving me.

The pull request was great. I don't think it was brutal, but it was a learning experience for me. Should I have known and coded some of the suggestions before I sent the pull request? Maybe. Okay, the answer is yes. One of the comments was to move some code to a shared base class with the tests I wrote and the tests another tester/engineer wrote. I should have read their pull request the week before and known that there was code in both of our classes. Remember to read others pull requests or ask more questions in our daily standups to make sure I am not duplicating code. Something for me to work on, make sure I am more aware of what everyone on the team is doing.

The moral of this story is that Ben thought he was being brutal. I think he was being very helpful. I am still refactoring the tests to implement all of his comments (I already have a few of the tests working again using the new initialization from the base class). Everyone needs to be continuously learning. That is what helped get me from finance to the software industry (although I still feel I am lucky and maybe don't belong in a coding role). The pull request is a learning tool. As I continue to grow the comments will come back and be different then the "brutal" comments I got from Ben. I hope they are all brutal and continue to help me improve my coding ability.

I saw a great quote today on Twitter. It said, "It takes time to get good at coding." And it does. I will get there, eventually, and the pull requests that are rejected help me see how I can improve and help me get there quicker.

P.S. My wife goes back to work on Friday. No more morning C# on the treadmill at work! I hope to still wake up early enough to get some learning in before I take my daughter to day care.

100% Yes. Great quote via @FreeCodeCamp. #learntocode #tech #inspiration pic.twitter.com/lcVKOZAJNK

— Kedar Joyner (@kedmasterk) August 11, 2016