Friday, January 17, 2014

The 8 most essential Git commands

This time last year I could taste blood in my mouth, my front teeth felt loose, and I was so angry I had just been kicked in the face by a donkey whose feet I was trimming. It happened so fast it took me a couple seconds to really understand what had happened.

Well it's been over 5 months since the last time I have touched a horse. I no longer make my living shoeing horses. Over the past 5 1/2 months as a junior developer I have learned 8 Git commands that have saved my butt countless times and that I deem absolutely essential especially starting out as a new developer in the field. The first rule of development is just like in medicine: "First do no harm".

There are basic git commands, like 'git push' 'git commit' and stuff like that, but these 8 rules while simple are the keys to becoming trustworthy and responsible to not screw anything up on your development team.

1- 'git status'

I used to "sometimes" check what I was committing, when working on my own projects. Now after working on a development team I ALWAYS 200% of the time do a 'git status' or 'git st' as I have it for short on my machine. I then do a...

2- 'git diff' or use the GUI 'gitx'

I know some "purist" developers would never consider using ANY sort of GUI but I have to say using 'gitx' from the command line has helped me SO much to make darn sure of exactly what I am committing. Without 'gitx' installed, the next best thing is to type 'git diff '. I think it's personally a little harder to read, 'git diff ' will show you what was changed in the files about to be committed.

3- 'git log'

Now don't jump the gun, we still are not ready to commit anything yet, one last step I like to do is to check the log, just to make sure that I am paying attention and know exactly what branch I am on and what has been committed before, I do a quick 'git log', if every think looks fine and I am sure that I am on the right branch, then I go to...

4- 'git add  filename'  WITHOUT the ' . '

Yes it's fun to just do 'git add . ' which then adds EVERYTHING all the files at once. A much safer way is to manually do a 'git add filename' it's the same thing, just you have to type in each file name as you add them to git. I think for me that it helps me to establish good healthy work flow patterns so that I am less likely to make a mistake when under pressure or stressed. I will have a good mentally strong git work flow.

5- 'git commit --amend'

You then of course do a 'git commit -m "my first commit" ' but what is really cool and helpful as long as you are working on your own branch and haven't released your work to any other developers is to use: 'git commit --amend' after making your first commit to a project. It basically just keeps stuffing each commit into the next one so that you don't have a lot of different commits for small tweaks to files or in tweaking a CSS rule or something. The more important less routine the work, the less I will use 'git commit --amend' but otherwise a really handy command to know.

6- 'git reset HEAD-1' or 'git reset HEAD^'
If even after being as careful as possible you do add a file or something you didn't mean to, you can simply undo the last commit you did by either doing: 'git reset HEAD~1' or if you prefer 'git reset HEAD^'. This command is worth a million dollars when you are brand new and make a mistake as all new young developers will, not an excuse for not be careful, but definitely a git command life raft.

7- 'git branch -d  branch name'

When deleting lots of branches in my case usually 10 - 15 branches every week, I ALWAYS use the lower case '-d' versus the '-D' to check if the branch can be safely deleted. It's basically a built in git safety, use it.

8- 'git rebase -i HEAD~4'

I never thought I'd care about how many commits it took to complete a task or project. I thought as long as it was done and worked correctly, that was good enough. Well actually no, when working on a code base with thousands and thousands of commits, development teams like to keep commits as clean and meaningful as possible. Which means if you took eight commits to do something that should have taken one then you will need to interactively 'squash' your commits and then re push your work back up to git as one nicely formatted commit. Pretty complicated the first time you do it but it's really too hard once you get used to it. Something you should probably practice on your own project the first few times. Take a look at interactive rebasing and don't be scared.

Keep coding!



Sunday, January 12, 2014

Garbage Collection

I used to believe there was no difference between a software developer and a computer scientist, and when I read things online that said differently I chalked it up to people wanting to stroke there ego and just wanting to have a cooler sounding title.

I was wrong, recently I have been seeing the error of my ways more and more. I love the fact that I can make things using Ruby on Rails, and that Rails has all this magic that I don't understand. I also like the low barrier of knowledge required to start to make things, but I am also realizing that I don't know ANY computer science.

Take garbage collection in Ruby, sounds fairly boring till you read more about memory management and memory allocation and find that Ruby uses a mark and sweep method for garbage collection and that is one of the reasons Ruby can be slower in doing some things.

I am finding previously "boring" subjects are actually more interesting when you start to understand them and what they do little bit better. I guess the biggest difference between a programmer and a computer scientist is a programmer can use a language and a framework, to solve a problem. The computer scientist looks at the problem and decides which language or framework to use if any, while weighing out many factors and possible solutions that the average developer who just knows a certain framework or language would even consider.


The lesson I am slowing starting to understand is that I have about 300 years worth of learning to actually become a computer scientist and that is daunting as well as exciting. No longer do I just want to learn a specific language or framework.

By the way it's simple to see garbage collection at work in Ruby. Just type 'irb' and press enter into your terminal. Once irb is running, type ' GC.stat' to see garbage collection information. You can also run: 'GC.start' which will return nil, and then run ' GC.stat ' again and see the difference like this screenshot shows:




Yes, this could be boring, but I am actually finding it kind of cool to learn more and more things of what goes on under the hood. Keep coding peeps!

-Josh

Tuesday, January 7, 2014

Udacity CS 101 Lesson 1 of 11

Well that took a while but lesson 1 is done, only 10 more to go :-) The course is supposed to take 7 weeks but we'll see. Here's the link to my Udacity Github Repo Udacity-CS-101 if you want to clone the repo and  run it on your local machine. The purpose of the repo is just for me to document what I'm doing and to keep honest with completing all of the assignments.

The course is done in Python, but I really want to learn Ruby so I'm doing everything twice, once in Python and once in Ruby. Already I've noticed some differences between Ruby and Python the biggest difference so far has been indentation. When I am using Haml I am SUPER careful on how I nest and indent elements, but in Ruby I guess I'm a little sloppy or just don't think about it.

I had 4 errors while doing the exercises in Lesson 1 and I looked through my code I couldn't find anything wrong. Then I realized I had one more space in front of one of the lines of Python. It's funny how you don't think about that when using Ruby.

I was going to go on and do another Udacity course after this one, but after looking around, I think I will take either one of these 2 courses here: Stanford CS 101 or Harvardx-cs50x . I really am enjoying the slow no pressure pace of the current course, and I just am thinking to myself that Stanford is the number CS school in the world at least according to the Huffingtonpost: best university computer science.

Who am I trying to impress? Why not take my time and get a really good solid computer science foundation by taking a couple different CS 101 courses, especially considering they are free. As long as I am learning new things everyday, and am able to take care of my family I'm a happy camper.

One day (many years from now) I want to be the Michael Jordan of software development. Today I had a small taste of what it would be like to REALLY  have an advanced skill set. I was able to use an advanced Css skill to solve a problem I was having while making a site. NOTE: I am not a Css expert, I have only been doing Css for the past 6 months, however it felt really good to know how to fix something using an advanced skill.

Anyway enough bragging, I'll let you know how the course goes, so far I highly recommend it!

-Josh