The Next Step

The two year experiment is over.

Did I learn C?

I think so. Maybe. It's complicated. In hindsight it was foolish to set out learning C. I should have started out simply learning to program with C as the medium for doing so. I spent way too much time getting involved in the particulars of C programming. I don't regret doing so, but I've found that programming is not a matter of language only.

Did I learn to program?

Yes, but I have a long way still to go. I'm at a point where the language isn't in my way anymore. Any language. For example, I'm currently struggling with finding a way to talk to my Arduino over the serial port using C. There's already a Python module for doing this that knocks out the hard part of that process in a few lines. I want to do it in C because I want to learn the internals, but it's not C that's giving me fits - it's the UNIX API for serial communication, termios. It's just a matter of reading the documentation and tutorials while bringing it all home with some test programs. Again, it's not the language I struggle with, it's reading other people's code and plowing through documentation. I have a feeling like that struggle is what programmers at any level do a lot of!

I have a dozen projects to tackle, two dozen if I count non-programming projects.

To that end I've started a new online journal at www.chrisheydrick.com so that I can have a place to document all of my hobbies. That's where I'll be from now on. I've been a Blogger user since before it was bought out by Google. I'm going to try Wordpress out for a while just for a change of pace. I might be back, who knows.

Work stuff will be dominating my time for the next few weeks.

The refactoring of the case reporting library was successful. The whole project was successful, actually - it proved that more elaborate case reporting and analysis tools were needed, and now I'm looking into commercially available options. I guess once the higher-ups got a taste of what's possible it opened up the option to spending money. I'm more than happy to put this project behind me. It was a valuable learning experience, but extremely dull.

Now I'm looking towards what's next. I started this journal to keep a record of my progress in learning to program in C, but what wound up happening is that I laid a foundation for learning to program in anything for whatever reason.

I've spent some of this evening researching microcontrollers. There has been several times in the past few years where I've almost purchased an Arduino, but I didn't go through with it because I was worried that it was too high-level to be a good taste of real microcontroller programming. Now that I have a better understanding of the tool chain (as well as what being an Arduino really means) I realize that's not necessarily the case, so I might pick one up soon.

I started reading Charles Petzold's Code. It's absolutely brilliant. I picked it up because I wanted to learn more about assembly programming (specifically for the fictional DCPU-16 that will be featured in Notch's Ox10c game). The book starts with things like Morse code and Braille, telegraph machines, and relays. It then bridges those concepts with (I believe it's called) set theory, and then on to combinatorial logic and gates (AND, OR, NOT, XOR, etc). That's where I am right now - right at the part where all these gates are combined to make half and full-adders. It goes into a decent amount of detail about how to use these to add and subtract binary numbers, but I'm afraid I'm getting a bit lost with the subtraction and I'll need to work it out on paper before moving on. I think that soon the book will transition to flip-flops, memory, and then eventually how it all combines into something that can be programmed.

I have a good idea for a next project to stretch myself, but I need to plow through more of the Objective-C book first.

Refactored case report program

I decided to just bite the bullet and reorganize the program I'm writing to make some reporting easier at work. Python project organization is a pain.

http://stackoverflow.com/questions/391879/organising-my-python-project

http://stackoverflow.com/questions/1642975/folder-and-file-organization-for-python-development

http://www.python.org/doc/essays/packages.html

I think I have it figured out, and some of the problems I had with importing my modules last night might have been operating system specific. I'm doing the development in OSX since I don't want to boot into my Linux VM every time I want to bang out an idea.

I'm using Excel for 90% of the reporting right now due to time constraints. I'd LOVE to do it 100% in Python so that I can do much more elaborate and flexible reporting. The last 10% is yanking out some numbers based off how long a case takes to close so that I can make a histogram. I spent way too long trying to get Excel to do that and failed. It's going to be much easier using Python, but I'm making it harder than it needs to be so that I can set up a solid library of functions I want to use in the future.

Excellent post on function pointer uses

http://vickychijwani.github.com/2012/03/22/function-pointers-in-c-are-underrated/

adding PE projects

I've been working to consolidate my Project Euler solutions into one big program, and so far using Git and GitHub have been working out splendidly. I added the first 4 projects, and now I'm working to add the next 6 or 7 which I have scattered between several computers.

Luckily the next several are on my Macbook, which has Git and GCC and is completely identical to the Linux box (at the level I'm working with it anyways). So, I have been trying to find a Git workflow that allows me to add and commit to the remote repo from OS X, and put the finishing touches in Linux.

Pre-step (did once): Clone the master git repository.

Step 1: Find file in OS X, verify it works in the original XCode project I made it in.
Step 2: Go to the local OS X repo directory and run "git pull", which gets all the latest changes I have made
Step 3: Copy over the existing PE solution to the local repo directory, and rename it appropriately
Step 4: Add, commit, then push to the remote repo
Step 5: Go to the local Linux repo directory and run "git pull"
Step 6: Make changes, add, commit, push.

Now what I've outlined is a very simple case. Typically I make a new branch on the OS X side, push that branch to the repo, pull that branch (with "git fetch") in Linux then merge to the master after I make changes. I'm still figuring out when to use "git pull" and when to use "git fetch". I think the work I'm doing is so trivial it doesn't matter.

A reminder about character array sizes

char *charpointer = "iameight\0";
char array[9] = "iameight\0";

The strlen size of charpointer is: 8
The strlen size of array is: 8

The sizeof size of charpointer is: 4
The sizeof size of array is: 9

The above is the result of a small "sanity check" program I keep around. It's super helpful.

grip gotten

Ok, I think I have a handle on basic Git (branching, merging, fetching from remote repos into a branch, pushing a remote branch, pull requests).

I'm somewhat back into C mode now. I should dust off some old forgotten projects, or maybe take the time to hack on some GTK stuff again.