Wednesday, July 6, 2016

Angular 2...

I'm grinding my way through Angular 2 and I keep hitting some bumps along the way.
I've been trying to create a dashboard app for my company that I can quickly spin up forms and data. The hope was with Angular 2 and JavaScript I could accomplish this faster than a .net application. I wrote a medium sized application in Angular 1 at the beginning of the year and it went very well. For the back-end services I changed from a monolithic service gateway to more of a microservices using Service Stack api. I can now spin up a quick database and connection in a hour or so with a RESTful api. With the front end I wanted to do something similar so for the past month I've been working on the previously mentioned dashboard. I started with RC 1. Since it was new to me, I didn't miss out on some of the breaking changes and I knew routing and forms would be changed in the coming months/weeks. As I messed around with some newbie projects while I was implementing my microservices and other tasks RC 2 came out. Everything became a learning curve and it took me a bit to get back up to speed. I downloaded a dashboard templateAkveo admin 2 desktop and shortly thereafter RC 3 came out and then last week RC 4 was released. Routing, Forms, and other changes/bug fixes and learning how to implement the dashboard set me back a bit. I created my own local git repository and set off to updating the routing to the beta router. I didn't have time for akveo to update it and I wanted to stay with the Angular team as they released the product. I also had to learn about form builder (akveo did implement this..). The problem with the forms and binding is there are multiple ways to do this and lots of opinions and examples to choose from.
Since I was implementing authentication I picked one and was wondering how to force each page to be required to authenticate and low and behold auth.gaurd came to the rescue:
export class AuthGuard implements CanActivate {
    constructor(private authService: AuthService, private router: Router){}

        next: ActivatedRouteSnapshot,
        state: RouterStateSnapshot
        let user = localStorage.getItem('user');
         if (user === null)
            return false;    
        return true;
Simple but effective for the time being. Okay I got that all working and needed to actually get a user object from the service once the user was authenticated. Well, now I get to dive into the world of observables. In reality, there isn't that much difference, but Angular 2 team almost makes it more difficult on how to decide on what to use. Promise or Observable with other variations on observable. For example if you have Pluralsight watch the John Papa and Ward Bell play by play video and they discuss all the different ways in which they could be used in different situations. If you want to look at the code he has examples of both in the component and service. Now back to getting the user data from the service before render. I couldn't figure out how to populate the object before render in which it would be undefined. Here is how I accomplished it: Here is one of my routerConfig ts files:
export const PagesRoutes: RouterConfig = [
     { path: '', redirectTo: '/pages', terminal: true },
      { path: 'pages',
            component: Pages,
            resolve: {
                  teamMember: MemberResolver
            canActivate: [AuthGuard],
            children: [
                        path: '',
                        component: Dashboard,
                        canActivate: [AuthGuard]
                        path: 'Dashboard',
                        component: Dashboard,
                        canActivate: [AuthGuard]
                        path: 'Charts',
                        component: Charts,
                        canActivate: [AuthGuard],
                              path: 'ChartistJs',
                              component: ChartistJs,
                              canActivate: [AuthGuard]
Notice the resolve in the pages component. It uses the resolver from the router and you create a class like this:
import { Resolve, ActivatedRouteSnapshot, RouterStateSnapshot } from '@angular/router';
import { TeamMember, TeamMemberService } from './index';
import { Observable } from 'rxjs/Rx';
import { Injectable } from '@angular/core';

export class MemberResolver implements Resolve {
      constructor(private _teamMemberService : TeamMemberService) {}
      _teamMember: TeamMember;
      resolve(route: ActivatedRouteSnapshot, state: RouterStateSnapshot):Observable {
            let userName = localStorage.getItem('user');
           return this._teamMemberService.callService_RxObservable(userName);
And now to retrieve the observable data:
export class Pages implements OnInit {
  constructor(private route: ActivatedRoute, private _teamMemberService: TeamMemberService) {
   ngOnInit() {
     this._teamMemberService.teamMember =['teamMember'];
The ink on the Resolve documentation on still wasn't dry when I discovered this. It took me a bit to understand it and I was using the activatedRoute along with the snapshot to retrieve the observable data.

Monday, March 4, 2013


I hate (opps told my kids that we should never use that word), writing comments in my code.

I'm not talking about API comments that people can use in intellisense to understand the method and it's parameters. I'm talking about comments in the code that are supposed to describe private methods or logic flows. It shouldn't need to be done in this day and age of programming. We are well past the age of days past when programmers used a,b and c as variable names and then reused the same variable for a new contextual meaning.

I read blog posts over and over talking about the correct rules and syntax of using comments. What to comment in or out of methods. How about we write code that explicitly states what we are doing. If it doesn't make sense to you, then how about your simplify it so you can explain it to a teenager.

Developer: I can't understand the code when I read it.
Me: Do you have unit tests written against the code?
Developer: No.
Me: I bet when you write them your code will change to a more readable state.

I'm so tired of fighting battles I had as a software engineer ten or fifteen years ago. I want to be pushed on the complexity of doing things even more simply. I'm tired of reading nested if and case statements scrolling through my IDE and wondering what JR developer was allowed to write such crap only to find out it was the companies most senior developer. And he was the favorite of the managers because he just got shit done.

Yeah he got shit done. Five hundred line methods with more cyclonic complexity than can be measured. I'm supposed to add a feature without breaking the existing functionality.

Now is the time I wish he had written comments!!!!

Thursday, February 21, 2013

Shotgun post!

It's been a while.

I've been working as a part-time game developer. I'm using the Havok Engine for an MMO called Embers of Caeruswhich at this time is a volunteer position. If funding gets approved who knows if I'll be offered a full-time position since I'm not sure where the main office will be located in the U.S. or not. It's some nice experience and gives me something fun to do.

Ruby (Rails), Python and Java is really what I've been messing with on my own time. I've done a couple of sites in Rails, a couple of stupid Android Apps for my kids to keep up with the "in crowd" of development. I wish there were more companies around Green Bay that would examine their I.T. and use the right tool for the job instead of forcing it with .NET or RPG. Even then I don't know a decent sized company up here yet that has implemented .net 4.0 let alone writing some Rails site!

I really am into the NO_SQL movement. I've used ORM's in the past, but I've worked with Entity Framework 5.0 in VS2012 and I really like the automation it provides especially for decent databases. I created a little project to hold stock market data and I thought I would give VS12, SQL12 and EF5 a run through it's paces. Compared to what I'm doing in my day job it was so nice to have the db created, the models/mapping created and the calls ready to get and set data ready for my use. It makes me cringe each time I write my mapper class at my day job (even though it is abstracted as far as I can take it).

Speaking of Python, I have a cool idea for a game. I was looking at the Pixar python 3D engine. My daughter is a budding artist and I thought she could learn to use Maya or a similar tool to create my objects and I would exercise my Python muscles more. Heck Python works for Eve Online I guess I could try it!


Thursday, July 1, 2010

The Refactoring March

I’ve been hired to help refactor code. The lead developer and project owner know they have a code mess and they want it fixed. Rewriting the application is not an option, but the code base is tightly coupled and has turned into a ball of mud. Where does one start?

At first (and still am to a certain degree) perplexed about the process. Core features are intertwined in a whimsical manner where no thought of abstraction or single responsibility has ever taken place. Procedural code runs rampant among threads, inherited classes (abstract or not) and a myriad of if statements. And as developers have tried to “improve” the methodology of making calls into the bowels of the communication layer it has quickly become a congealed mess.

While I have faced similar issues with code in the past, I’ve never been given the green light to really fix the problems and make it work. I’ve argued unsuccessfully to rewrite projects because the code base is so messed up that only a proper burial into the sea of electricity was fitting. This does not sit well with people who have many years of time and money invested into the project(s). It requires more creative thinking to get the code base into a true usable state.

I’ve told the project manager that we need to stop current development. Adding more features will only serve to create more threads of illegitimate code. The second step I’ve taken is getting the source code repository into a better managed state so we know what code is getting developed, tested and in production. I wouldn’t say the previous state of source control was horrible, but it lacked the ability to exist in these different states independent of each other.

Next I traversed through the code and began to pick at the low hanging fruit. Simple things like removing needless comments (almost all of them), unused variables, unused methods and classes, clean up using declarations and other tidying refactors to make the code a bit better to read. In Fowler’s book, “Refactoring: Improving the Design of Existing Code” he indicates that code not placed with unit testing is considered legacy code and thus needs to be refactored. This means the start point for refactoring is getting the code wrapped in unit tests.

This means the developers need to have the ability to write unit tests. This also means we need to have good coding standards and reviews as we move forward. Since the company is hiring real Sr. Developers we have a nice core team that understands these principals. We now need to get the existing team to understand these are not suggestions, but requirements if we are to bring the code base back to life.

My fear is that while we might do a good job of cleaning up the cuts and bruises we will need to use the electric paddles a couple of times in this process to keep the pulse going.

Wednesday, June 9, 2010

New Job...

I finally started my new job today, about 3 weeks later than I really expected. I'm not sure what the real hold up was, but involved lawyers, insurance and I'm sure money. No matter, I was able to start at 1pm today and had an interesting discussion with the PM and the Lead developer.

They are committed to making this development group one of the best in Wisconsin and they want me to be a pivotal player in this development. They want to hire 5 developers in the next few weeks. They have already have two others on board, they are needing IT to help with equipment and such.

We talked a lot about design and moving the application in the right direction. They have a developer in Colorado who phoned into our room and I got a chance to see the code he was working on. Not very good, but then again I expect that in most applications. Even when developers are well meaning a lot of bad code slips through the cracks as release dates are nearing and it needs to be done now.

It is going to be interesting working with them. I already warned them that I usually come with both guns blazing wanting to make the software better, but I believe my recent experiences has taught me to temper how I go about it. They responded that they welcome the input. Be careful what you wish for!

This could be a gold mine of opportunity for me. I think the goals, the conditions and the software that is wanting to be written has the potential to be really neat and exciting.

And I'll be able to post about something more than a file copy system!

Expect to hear more in the near future.

Saturday, May 22, 2010

Yesterday (every time I type that word I think of the Beatles song...) I had an interview with the PM/Lead. I was given the opportunity to complete a calculator program. I had two hours and while I didn't complete it (I was too worried about removing the dependency from the UI to the BLL (Core) layers. If I wouldn't have been so anal I would have been able to implement an abstract class for the base methods for the operators and completed it easily. I think sometimes I get all caught up in the details I forget to get it working and then re-factor.

I used tests to help me along, but when I got side-tracked in my writing I also got side tracked in my tests. I'm learning more and more to trust the tests and not myself. As I learned from my music project, the tests will tell me what I need to do. Testing will then find the missing implementations or the erroneous errors that exist in computers that one doesn't always think about. But then you fix it with a test, then fix the code and you are back riding into the sunset again.

I had a quick code review of what I had written and it made sense to him. I was at least able to show him that the calculating worked, there was error handling and undo functionality, but I had the framework completed for that, just needed about 30 more minutes. I think I was too stressed to work efficiently. Not having a job and needing one does that I believe.

Sooo... we talked about the team. Right now it is pretty small, but they have a ton of work that needs done. The lead told me the code base wasn't pretty, but they have done a good job of removing some technical debt. He also discussed doing code reviews and weekly technical lectures where the team is teaching each other.

I had told them that I started that kind of program at my previous employer and even put the lesson notes on a wiki. I offered they should start video taping it. I think people are more often willing to watch something rather than read something.

We talked about source control as they are currently using SubVersion but are looking at Team Foundation System which I had installed and configured at said last place of employment.

I was given a tour of the software. It's some pretty impressive stuff (a WPF/C# program that uses USB to chat to modules inside of boat engines). They have a ton of features that are needed and are looking to add (hence why they were interviewing me).

On the way home, I was called an told I got the job if I wanted it. Pretty cool software system, working on boats (yes going on the lake with them!) and a team lead that is pushing the team towards software craftsmanship. I can handle a place like that.

Wednesday, May 19, 2010

How I solved it.

The other day I asked the blog world about TDD. And while I didn't get many comments in the blog :P I did get some private feedback statements about how I could handle it. I swear developers are teachers at their heart, because rarely does any give a straight answer to a question. It is always something abstract (no programming pun here). So I banged my head against the keyboard and came up with my approach.

TDD is about letting the tests help you design. If you toss the tests away then the design doesn't really matter because it is untestable. I'm not going to discuss what should be testable or not, but I believe if you are doing TDD in the 'logic' part of your program then it should be wrapped in tests. If I change the behavior of the method how then would I know if my tests pass at the individual function level? Again this is where the Agile manifesto comes into play, I'm not scared of change because if I change something I know where it breaks.

My solution was to understand what I wanted from the facade class. You could call it a controller class really so it is going to handle all of the dependencies and while I'm a fan of cutting them down as much as possible, you have to have dependencies someplace. Since this is such a small program I'm fine putting them there because now I can test the underlying functions in a more precise way. I'm not just testing a return value, but I'm testing the intent of the function.

So I created an interface to the Tag.cs file. This will allow me to write to the interface and open it up for testing. I also removed the dependency in the tag file for the MP3 reader and put it in the facade. By doing this I opened up my testing to mocking that object. I was then easily able to test that the function was returning the correct data and formatting it in the way I wanted.

Before I wrote any UI code, I knew my files where getting renamed in the manner I wanted and they were going to get copied to the correct network share based on the Artist's name. All before ever copying a single file to the media server.
Clicking he button calls the facade and it simply worked.

After I realized I wanted to change the way I had named the mp3 file, I simply changed the test to the output I wanted and ran the test. Obviously it failed. But without running the debugger I knew exactly which function failed, fixed the format and ran the test again. This time it passed.

As I tested the program through the interface I realized that I had illegal characters in my file name and pathing since music artists have to be weird.
Write some tests with some embedded in the title and artist and bam I now have tests against them.

The only issue I'm having now is that the mp3 tagger library I'm using doesn't support v2.4 of ID3. I think I have some older mp3's that have different versions of ID3 and so I have to do some manual fudging with iTunes to convert the tags to the right version.

I didn't learn much more with TDD, but I did learn more about interfaces, abstract and OOP.