Saturday, February 15, 2014

Simple Git configurations for beginners (like me)

     As the shores of Microsoft disappear over the horizon, I find myself using tools that I used to think of as convoluted command line hacks and black magic.  Things like Git.  Of course, now that' I've used Git for several months in a for real multi-user multi-location environment, I love it.  Not only do I use it, but I'm comfortable enough now that I don't even use the GUI's.  I'm all CLI like the real hipster programmers.

I use Git and Github a lot these days.  It's cool and all but there were the inevitable hickups along the way.  Lots of Googling.   Here's a list of things that I wish had been all in one place when I started.  I provide this for others(my future self included) who might be new to Git/GIthub and want to lessen the learning curve a bit.  These tweaks assume you already have Git installed, a free Github account and an SSH key.  If not, create an account at Github and follow these steps to create an SSH key.  Moving on...

These are the problems I ran into early on and how they got fixed plus a few tweaks.
  1. Every time I do a git push to a repo on Github, I get asked for username and password.
    1. This is most likely because you did a git clone from HTTPS and not SSH.  I'd post a screen shot but the UI will probably change at some point.  Look on the github repo page, find the clone URL and make sure that you are copying the one for SSH.  More info.
  2. I make changes on my local branch, but when I push to Github it says, "Everything is up to date" even though it's not.
    1. Instead of doing git push, do git push origin <branch name>, like git push origin newfeature.  More info.
  3. I get asked for a pass phrase every time I do a push or pull.  More info.
    1. On the command line type:
      1. eval $(ssh-agent) <enter>
      2. ssh-add <enter>
  4. Helpful git aliases
    1. You can run this at the command line to make typing git commands a little easier.
      1. $ git config --global alias.co checkout $ git config --global alias.br branch $ git config --global alias.ci commit $ git config --global alias.st status
      2. git commit becomes git ci.  git checkout becomes git co and git branch becomes git br.  (These aliases were taken from Scott Charon's book Pro Git)
  5. Color!
    1. It's nice to have some color on the command line.  Set this so that the git diff, git status and other commands return some color variation to make things easier to read.
      1. $ git config --global color.ui true
      2. More Info
  6. Lastly, instead of doing git commit -m 'message' all the time, you can do a git commit -av which will launch the default text editor, let you view the changes that are going into the commit AND type the commit message.  I like using Sublime, so updated the git config to do so.
    1. git config --global core.editor "subl -n -w"(More Info)
If you see anything wrong, let me know.  Present and future me thanks you, but not past me.  Past me is a corner cutting jerk.

Friday, January 10, 2014

Movies I saw in MMXIII

I looked over the list of movies I saw in the theater this past year and was surprised at the total: 21.  Below is a quick one or two sentence review of each film and links to purchase on Amazon (my blatant attempt at revenue).  A couple of these were late 2012, but I'm including them on the 2013 list since this is the first time I've done this.  Some of these are over a year old so my recollection may be a tad hazy.  However this isn't going to be much more than a thumbs up/down kind of thing, so it should be fine.  Keep in mind this is very subjective.  You're opinions may vary.

Movies I saw in the theater, 2013:
  1. Lincoln - Really liked it a lot.  I'll see anything with Daniel Day Lewis.  A great director with a bunch of great actors making a movie about a great man during a pivotal time in American history. What else is there to say?  Thumbs Up
  2. The Conjuring - It was okay.  Parts of the plot seemed thrown together but a good horror movie. Surely we can find better parts for Ron Livingston.  It's alright.
  3. Argo - I had no idea what to expect.  I knew almost nothing about the plot.  Liked it a lot.  I'd watch it again.  Solid film making and story telling.  No over the top grandstanding-look-at-me acting moments.  Thumbs Up
  4. Zero Dark Thirty - My favorite of the year.  Incredible movie about a subject that brings up many conflicting emotions.  Thumbs Up
  5. The Hobbit - Silly.  I really wanted to like it but it's silly.  I'll provide a link to the book instead.  Thumbs down.
  6. Killing Them Softly - Gritty-Ugly-People-Gangster(GUPG) movie.  If you like that sort of thing (I do) you'll love it.  James Gandolfini steals the show playing the role of Mickey, a gangster who is past his prime and eats and drinks too much.  Turns out there was a lot of foreshadowing in that role, which is sad.  Overall I give it a thumbs up
  7. Django Unchained - I usually love everything Tarantino does.  This one, I'm not sure what it was but I found myself turning away from the screen during the final blood bath shoot out.  I wanted to love it, I just didn't.  What I really wanted to see was Christopher Waltz as Col. Landa trying to fit in on Nantucket Island.  Thumbs....not sure yet.  I abstain.
  8. Stand Up Guys - I'm not sure why I liked this so much.  It's a good bad movie.  Another one of those Gritty-Ugly-People Gangster(GUPG) movies.  Pacino and Walken didn't act very much, but I didn't mind.  Thumbs Up.  You can also find this streaming on Netflix.
  9. Gangster Squad - I really wanted to like this.  I didn't expect it to be life changing, but I was hopeful it'd be solid.  Didn't work for me.  Thumbs down.
  10. The Berlin File - Interesting, but I'm not 100% sure what happened.  It was this movie that made me realize I should never look at my phone during a movie with subtitles.  It was different and not bad, so thumbs up.
  11. Skyfall - Daniel Craig's physique puts all 40+ year old men to shame.  Probably most of the 30+ and 20+ men too.  Fun movie.  It was great to see Javier Bardem as a bad guy again.  Thumbs up.
  12. Side Effects - Warning, this movie may cause excessive eye rolling.  Thumbs down.
  13. Evil Dead - Walked out of it.  Thumbs down.
  14. The Place Beyond The Pines - Amazing.  I will definitely watch this movie again.   Thumbs Up.
  15. The Iceman - Another Gritty-Ugly-People gangster movie.  The acting is great but the main character is a bad guy who's...a bad guy.  There are a few scene's where he's conflicted about the things he has done but...that's what happens.  I cheered when he got caught at the end.  If you don't like GUPG movies, this isn't for you.  Otherwise, thumbs slightly up.
  16. This Is The End - This was my first Seth Rogan movie.  I'll steer away from anything else he does, but I was entertained.  I could have done without the gross-out comedy bits but that's what some people are paying to see.  I get that.  Still, thumbs up.  Like I said, it made me laugh.
  17. Monster's U - It's hard to be objective about this because it's the first movie my wife and I took my daughter to see in a theater.  She was equal parts entertained and frightened.  We had fun.  Thumbs up.
  18. You're Next - Slasher horror film.  Different.  Campy.  I enjoyed it.  Sometimes movies trick you into cheering for the bad guy but you gotta pull for Erin in this one from start to finish.
  19. Grand Master - Beautiful.  Three intertwining plots that each could have been their own movie.  Really had to pay attention (No phone during sub-titled movies!) but I enjoyed it a lot.  Thumbs up.
  20. Gravity - Fantastic.  One of those rare movies where I think to myself, "Okay, maybe 3D isn't a complete waste of time."  If you're a selective pendant about how the laws of physic are portrayed in movies, then do us all a favor and don't see it.  For me, thumbs up!
  21. Old Boy (2013) - The new one, not the old one.  Meh.  I guess I'll see the original one of these days since it is so highly regarded.  But as far as the Spike Lee remake that I saw, thumbs down.

Thursday, October 31, 2013

Learning more about pointers in Go (Golang)

I really enjoy the Go book (found here) and the concise chapters and examples it provides. Today I started reading through chapter 9, specifically the section on embedded types. Embedded types allow Go structs to have an "is a" relationship instead of just a "has a" relationship.  I changed up the examples a little so I could make sure I was learning the concept and not just typing in some one else's code.  Take a look at the code for the two structs, Person and Android.

type Person struct {
 Name string
}

type Android struct {
 Person
 Model string
}

Person has a name and Android "is a" Person because I've added the type with no name(that's the embedded type part).  Model is a standard string property just like name is on Person.

I made the method "Talk" to go with the Person struct:

func (p *Person) Talk(TalkingTo *Person) {
 fmt.Printf("%v said, 'Hello there, %v.'\n", p.Name, TalkingTo.Name)
}

By working through the exercise, I was able to understand more about how pointers work.  Everything was going great.  Bob could talk to Frank and Frank could talk to Bob:

 Bob := Person{"Bob"}
 Frank := Person{"Frank"}

 Bob.Talk(&Frank)
 Frank.Talk(&Bob)

The Talk method accepts an argument of type Person pointer and I was able to use the & to get a pointer to the instance of the Person struct.  I was getting it.  If you ask for a pointer as a parameter, you can get that pointer by putting an & in front of a struct variable.  & means "give me a pointer to what follows."

Next I had Marty (an Android) talk to Bob(a Person):

 Marty := new(Android)
 Marty.Name = "Marty"
 Marty.Model = "T1000"

 Marty.Talk(&Bob)

No problem. Marty might be an Android but since it has a Person embedded type, it can talk like a Person struct can.

Next up I created an android called Arnold:

Arnold := Android{Person{"Arnold"}, "T1001"}

I also gave the android struct its own means of communication, called "Beep":

func (a *Android) Beep(BeepAt *Android) {
 fmt.Printf("%v beeped, 101010100001 at %v\n", a.Name, BeepAt.Name)
}

It's the same as the Talk method on the Person struct, just made for the Android struct.  The problem occurred when I tried to make Marty Beep at Arnold. This code generated an error:

Arnold.Beep(&Marty)

The error was:
cannot use &Marty (type **Android) as type *Android in function argument

The "**" should have been a tip off, but it stumped me for a while. I couldn't figure out why Arnold couldn't beep at Marty. Everybody else was talking just fine. What was the difference?  To my .Net/C# eyes, all of the variables were being instantiated the same way.  Then I realized that the Marty variable of type Android wasn't created the way the others were, it was using the new keyword.  In .Net new initializes the variable and fires off the constructor logic.  But that's not how things work in Go with the keyword new.  I did some reading and here's what I found:

In Go, the new keyword, "...allocates memory for all the fields, sets each of them to their zero value and returns a pointer."

By passing the Marty variable with an & in front of Marty, I was asking Go to pass a pointer to a pointer.  The function only accepts a pointer.  Marty was a variable that was a pointer to a struct instance of type Android while Arnold was just an instance of a struct of type Android.  The fix was simple once I understood what was going on.  I removed the & from Marty and the compiler was happy.  And more importantly, Arnold got to beep at Marty.

Arnold.Beep(Marty)
Arnold beeped, 101010100001 at Marty

I don't have pointers all figured out yet, but I'm closing in on them. Full source can be found here: Til next time.

Thursday, September 26, 2013

FizzBuzz Adventures in Golang

Before I get into Go Routines and Channels (which are both really cool), I thought I'd do some more direct C# to Go translation.  So, I took a FizzBuzz project that I had written in C#(here) and converted it to Go(here).  Here's a play by play over the main differences.  Some of it is obvious with only slight syntax differences.  But other parts are pretty different from C#.  That's what I'll focus on in this post.  Again, if I get something wrong please let me know in the comments or send me an email.

First up is the .go file(below) that contains the package main and the function main.  I'm creating an executable (.exe) with this file so I have to use the main package and have a function called main.  Very similar to a console application in .Net.  The import keyword denotes the packages I'm importing, "fmt" for formatting and writing text to the console and the line to my package that contains code for my Go implementation of FizzBuzz.

The program gets started with the func main on line 9.  The first thing I do is declare a variable and assign it a value.  The value is returned from a function called GetItems which is local to this file.  One thing you'll notice is the := syntax for variables.  This is similar to implicit typing that you can do in .Net.  In go, I'm saying create a variable called fbp and assign it a value of whatever is returned from the GetItems function.

If I wanted to declare an int and give it a value of 40, I would write agesoon :=40.  In C# I would write var agesoon = 40; and in VB it would be Dim agesoon = 40.  In all cases, the type of the variable is not stated explicitely but it is inferred based upon the value assigned to it.  In Go, if I wanted to change the value later I'd just write agesoon=41.  If I tried to use agesoon:=41 I would get an error because agesoon has already been declared once.

Line 11 starts a simple for loop.  The syntax is almost exactly what one would expect in C#.  The fmt.PrintF on line 13 is doing basically the same thing as Console.Writeline.  That's our main function.  The program begins and ends here, with a few detours of course.

Let's take a look at line 19.  I'm creating a variable of type FizzBuzzNumberOnly.  Line 20 looks a little strange.  var _  = fbpno is odd.  Why is that here?  In Go, if you declare a variable and don't use it, you get a compile time error.  Not a warning.  An error.  Same thing happens if you import a package in a .go file and you don't use anything from that package.  You get a compile time error, not a warning.  This is by design.  One of the reasons for this is that compile time speed was important to Go right from the start.  Files containing un-referenced variables and packages slow down compile time and provide...nothing.  As you can expect, there are some differing opinions on this.  The _ character allows me to use the variable by assigning it the blank identifier.  The blank identifier does not create a binding.  If I want to keep this variable in my program, I have to assign it to something or Go won't let my project compile.

Let's move on to the type FizzBuzzProcessor.

This file contains some of our code for the FizzBuzz library.  This isn't an executable, so there's no package main.  It's designed to be used by other Go programs.

The only package we import is the built in strconv so that we can convert things to strings.  First look at lines 11 through 13.  We are creating an interface called IFizzBuzzItem.  I used I for the first letter of the interface to keep with the convention that is widely used in .Net.  After the name we specify that this interface contains one method called GetResult.  It takes in a single int parameter called num and returns a string.

What's cool about interfaces in Go is this:  Any type that has a method called GetResult with an int parameter called num that returns a string automatically implements the interface IFizzBuzzItem.  We don't have to manually tell our other types to use the interface.  How cool is that?  It works kinda sorta like the poor man's interface I described in this post.

On line 15 we make a type called Items that is a slice of types that implement IFizzBuzzItem.  See the article arrays, slices and maps for more info.

See, I didn't name it anything.  Often times in a struct you have a name and then a variable type like, maxnum int or lastname string.  But you can also just create a field and call it a type.  So, my FizzBuzzProcessor has one field, that's a slice of IFizzBuzz items and one method called GetResult.  You'll notice that the method GetResult is declared separately from the struct type.  It's a part of the FizzBuzzProcessor type because it accepts a pointer to a FizzBuzzProcessor variable.  So any FizzBuzzProcessor type will have access to this method.  This is one of the things that will throw a .Net developer.  We're used to having fields and methods that belong to a class all in one place (even if it's split across files using partial classes).  Not so in Go.  However, if you are familiar with Extension Methods in .Net, you'll see some parallels.  If you're not familiar with extension methods in .Net, now we be a good time to read up on that.  If you use Linq you're using them all the time.

GetResult is going to accept a number, loop through all the instances in Items and see if the num parameter meets any of the conditions.  Let's look at the conditions themselves to see how this works.

There are several types that can be used, but I'm just going to cover the FizzBuzzDivisor type since it meets the requirements for the classic FizzBuzz problem.

I define three instances (covering Fizz, Buzz and FizzBuzz) like this:

fbdiv15:=sfb.FizzBuzzDivisor{15,"FizzBuzz"}
fbdiv5:=sfb.FizzBuzzDivisor{5,"Buzz"}
fbdiv3:=sfb.FizzBuzzDivisor{3,"Fizz"}

Here, I'm declaring and assigning three variables.  I'm also setting the properties after it variable is instantiated.  This isn't a constructor, it's assigning property values after the fact.  C# sharp allows the same thing.  For example, you can do:

var person = New Persion(){LastName = "Smith"}

Go doesn't need me to name the properties (although it's allowed) since I'm matching the order and type of how the are declared in the type.

Again, the GetResult method that meets the requirements for the IFizzBuzzItem interface resides outside of the type definition.  In this case, I'm passing a value to the instance and not a pointer.  I don't know enough yet about pointers to know why I'm doing it one way here and another way with the other type, but I'll figure that out.  I just know I had to do it this way to get the code to compile.  The main thing is, methods are declared outside of the types they belong to.  You get used to it pretty quick.

So that's about it.  I have a few other types that make use of the IFizzBuzzItem interface so that I can test for the ultimate answer, palindromes and perfect squares.  I make sure to add them in the order that I want them to be checked and that's that.  If a number meets more than one condition, only the resulting string of the first match will be returned.

So, that's my FizzBuzz in Go.  I learned a lot about the Go as I wrote it.  I like how it's teaching me new things about software development.  I still like C# a lot, but I hope to get better with Go, get up to speed on Postgresql and be able to write complete applications that aren't on Windows or Azure (yes, I know about Mono/Xaramin, it's great stuff).

So there you have it.  I have a few more programs in mind that I'll write in Go, one of which will help me check code as I write it.  It's fun stuff.

If you want to get started with Go yourself, read this and get...uh...going.
http://golang.org/doc/install

Friday, September 20, 2013

I'm going to learn Go

I'm going to give it a shot anyway.  I've read enough about Go to find it really interesting.  I want to learn something outside of the .Net world so I can actually call myself a polyglot programmer.  I'm sure I'm going to get lost at times, but I'll start small and see where this takes me.  I do think it's important to learn to think about code differently and Go seems different enough to help with that.

So for the first several Go posts, I'll just write some C# code and the equivalent Go code.  I'm sure I'll be "doing it wrong" since the languages are so different, but it's frustrating to start working in a new language and get stuck on, "how do I this simple..."?  I want to know how to build types, make function calls, do loops and if/else type things.  I'm sure it'll be obvious that I'm using Go with a C# mindset, but that will change with time.

I have several posts in the hopper that I was going to do with C# code, but I'm going to push those back and re-write them in Go.  This will help drive the "C to Go" posts and help me to learn more about the language.  I imagine I'll get in over my head pretty quickly.

Three things I like about Go already.


  • If you bring a package from one go library into another, it's included so you don't have to have access to the source package once you compile to an .exe.  I remember way back when I was getting started with .Net, I was frustrated that in order to have an object that inherited from a base object, my final program had to have access to both the base object and the new object.  Now, Go doesn't have inheritance like C#/VB but it does have dependencies and it's nice how those dependencies are brought into the final .exe.  You can take that .exe, deploy and not worry about bringing all the dependencies with you.
  • You can take your final .exe and copy it to another computer with the same OS and it just runs.  You don't have to have any Go stuff installed.  I know this is a "duh" for lots of programmers but for .Net developers, it means there is no need for the right .Net Framework or any .Net framework for that matter.  No Java run time stuff.  Again, I know this is a no brainer for lots of developers but for me, it was a reminder that there are ways of writing code that don't require pre-installed frameworks.  Other than an operating system.
  • My favorite thing is that, the entire Go spec is fifty printed pages.  You can read all there is to know about Go in an afternoon.  That gives me the hope that I can understand and really use Go.  This podcast goes over the reasoning behind Go and specifically mentions that you can become productive in Go in a weekend and get really good in a few months.  This is one of those opportunities to get in on the ground floor with a language.  As it grows and changes it'll be much easier to understand what those changes bring since it's possible to hold the entire language in your head.  Well, possible for some, we will see if it's possible for me.
Next up, Go FizzBuzz.

Tuesday, September 3, 2013

Object Mapping With ConvertAll

Sooner or later there will come a time when you have a collection of one type of object that you want to map to another type of object.  There might be a user object that contains many properties about the user but when displaying a list of users, you might only need the user name, real name and  userID.  I mean, <snort> why would you return the user's credit card in the JSON if you didn't really want to display it?

You can use tools like AutoMapper (which is great) but for simple one off conversions you can make use of .ConvertAll.  Keep in mind that ConvertAll is a method on the List class itself.  It is not an extension method on IEnumerable.

One scenario I've come across is when two different methods return objects that describe the same data, but in slightly different ways.

Let's say you have a Person class and a Human class.


These two classes are essentially the same, but there are a few nagging differences.  Human has a LastName and a FirstName property while Person just has a Name property.  Human stores height in inches while Person stores height in centimeters.  Lastly, Human stores the date of birth as a string in a property called BirthDay while Person stores that information in a DateTime property called DOB.

How does one convert a typed list of one kind to the other with ConvertAll?  Like this:


We could refactor this further so that we can directly map just one Person to a Human and vice versa in cases where we aren't dealing with a List.  These functions allow us to pass either type to the method and get back the other type:


Now the lines of code are adding up.  And if you want to run unit tests that make sure converted objects really are equal, you'll have to overload the Equals operator AND the GetHashCode method to get that to work. The more you write this code by hand, the better looking a tool like AutoMapper becomes.

So, if you are dealing with typed Lists and you only need a basic one off type conversion, it might be quicker to roll your own.  You can do the whole thing in the ConvertAll statement.  If the objects are more complex or you have several different mappings to worry about, you can still roll your own but, there are libraries out there to make life easier.

Source code for the entire project can be found here:
https://github.com/genghisjahn/ConvertAllExample

Thursday, August 29, 2013

Poor Man's Interface With the Dynamic Keyword.

While creating a demo application for an upcoming blog post, I found myself with a method where I copy pasted the same code to work with three different types.  I looked at the code and thought, "I should just create an interface for these small classes and rewrite this as one method that's called with three different types."  But, one type was a reference to an asp.net 2.0 web service type, one was to a local type and one was a dictionary return from a call to a ServiceStack REST call.  If there's  a way to have those classes implement an interface after the fact, I don't know about it.  But without even google/bing-ing a solution, I realized I could make this work by using the dynamic keyword.  If all three types had the same method of interest and same signature, I could get away with passing them to the general use method even though they did not implement a common interface or inherit from the same base class.

Let's illustrate with some code:



I know, I know. It's bad code, but the save button isn't a lock button, so we can refactor. Furthermore, by using the dynamic keyword, we can refactor to this:

Much better right? And now you can call each the method like this:
Keep in mind, none of these objects inherit from the same base class or implement the same interface.  By convention I made sure that the AddThis method would be called the same way every time.

Nothing magical here, but it might get you out of a bind.  I'm not sure that I'd want to put this in production code, at least not for every long, but it works.