Time Catcher Usage Demo

http://www.youtube.com/watch?v=H_UhIJah398

So I made a quick demo of timecatcher today out of boredom. Well, actually, I installed Simple Screen Recorder and wanted to try it out on anything at all, so I made the tutorial 3 times and then chose this one as the best out of all of them and uploaded it.

Granted I forgot to show the finish command, but it functions the same way as the pause command does, and to be honest I don't use it that often. A programmers work is never done after all.

Time Catcher

 I've begun work on a new project and so far it's coming along nicely. I've been using some software at work to keep track of my hours, it's called office time. It works fine, simple interface, easy to manage for the most part, and at least 20 features I don't use. Ever. So being the kind of guy I am, I decided that I could probably make a simple to use task tracking utility. Here are some of my motivations.

• I spend about 60-80% of my day in a terminal. So I should be able to access the utility from there
• I need to keep track of a task per day, and then be able to display it meaningfully later on
• I want to be able to add notes to myself about the task as I work on it
• I should only be active on a single task at a time

So let's see. I'm going to working in the command line, well that means I'll want an executable file. I could write a bash script, but bash syntax is not the best for anything complicated. So I want a higher language. I want to sit low, and I like C. So I'll do it in C.

 Keeping track of a single task, well that's simple. Give it a name. I'll have to be able to have it be permanent, and I even have a process running in the background (no) or I make an object of some kind in a file and use that to keep track of things. Now that sounds easy. If it works for git, it will work for me. 

If I want to keep track of my tasks per day, I should store these object files into their own folder, named after the current date. The benefit to this is that if I want to generate spreadsheets or information later on, I can do it by date with these folders. 

Adding a note, well that's easy too, keep track of it in the file for the current task. Being active on only a single task at a time? Now that seems hard to enforce. Because I'll be able to start a task, then end a task with a command. So I could fire off a bunch of tasks then finish them when I wanted to and the timing data would be complete garbage. Ah! So I'll keep track of the last created task in some type of master file. Easy! When a new task is created, the other task will be 'paused' or for starters I won't let a user switch tasks unless they finish one first.

 And this is my first plan. So far it's coming along and I've got the directory to hold this information all good and am writing out the usage documentation, as a guide to me and a guide to anyone else who wants to use it.

FrankenCode with Rails and Xemark

I've recently created a markup language called xemark. You can find the repository here or the Backus Naur Form grammar here

I've been using it to generate my github pages site which as of the time of this writing is about 75% done.

One of the beautiful things about xemark is that it output's to the console / stdout. Which means you can pipe or direct it's output anywhere you please. Because it prints out it's language to html, this means you can serve up xemark to anything that will pump out html for you.

I just franken coded a rails application to do this.

Now in no way, shape or form, is this good code or practice. But here are the simple steps:

1. Get a copy of xemark. (You can fork the repository, download it, or whathave you, then just compile parser.c with the -o flag set to xemark
2. Make yourself a xe file. Heck, use the example.xemark file and rename it example.xe it's up to you.
3. Next hop to your console and run the commands
1. rails new railsmark
2. rails generate controller page showit
4. Next we need to put in some code to show call xemark so throw this into your page_controller.rb
   

   class PageController < ApplicationController
     def showit
      p = `./xemark < #{params[:page]}.xe`
   
      respond_to do |format|
       format.html {render :text => p}
      end
     end
   end
   

5. Finally, move the xemark executable and the example.xe file into the root directory of your rails install.
6. run rails s or rails server
7. Navigate to localhost:3000/page/showit?page=example

Tada! You've just served up a xe page through rails. Note that this is a toy example, primarily because if you try to include any style to the xe page they won't link well, and not to mention this doesn't make use of the asset pipeline at all in rails, so no styling for you. Still. It was a fun quick and dirty experiment that turned out surprisingly well.

UPDATE:

I made it serve up my style as well. This is assuming that the xe file links to a stylesheet called style.css (by using ~style in the xe file under the @title)

First off. Change the controller code to have a new function

def style
   p = `cat ./style.css`
   respond_to do |format|
    format.html {render :text => p}
   end
end

Next, add the following to your config/routes.rb file

get "page/style.css", to: "page#style"

And finally, move a file called style.css to the root level of the directory.

And bam. You have style being served.

If I feel like playing more with this, I might make it scan the asset pipeline for the file instead of having it need to be in the root level. For more security, you could do something like this in routes.rb:

get "example", to: "page#showit" , :page => "example"

Once you do that though, you'll have to change your style get to be just style.css instead of page/style.css though.

How to grep a log file in realtime / continuously

When hunting down errors and debugging problems that plague a system. Your log file is your best friend. It lets you know what's going on in your application if you've really put the effort into logging all the idiosyncrasies  in your code.

One of my friends once told me: "You have to love your logger" and there's really on true-er statement than that.

Now it's easy to grep a log and look around for what you want. But continuously monitoring a log often poses a problem to people new to the debugging scene. They try out this first:

tail -f logfile | grep "pattern" 

And then they wait 4 days for something to show up. Why? Because of line buffering and the output of tail being buffered before being piped to grep. So how do you get around that? 

I've seen solutions like this:

tail -f logfile | grep --line-buffered "pattern"

but sometimes, depending on the system, they buffer as well and you have to wait.

To get continuous. real time logging you can employ the following shell script fu:

tail -f logfile | while read line ; do echo "$line"| grep "pattern" ; done

A 'proper' use of GOTO

Ever since Knuth criticized goto people have been spouting that GOTO is the worst language construct to ever use.

I'm fairly sure that 80% of them have never used a GOTO statement in their life, nor understand why sometimes it is the most logical thing to do.

For example here is an example:
  It really is logical here and I'll tell you why. Lets look at what I'm doing here in pseudo form:

read in a character:

 read in the next character

  Does this match a comment statement?

    Eat the input until the end of the comment

  No? Then just output it and keep going

Now you might be asking me, why didn't you write it with functions and fully modularize your code and encapsulate all the functionality? Simple. This is an exercise from a book. It is mean to be a simple one script that handles a low level functionality of removing comments. It's code is simple and it doesn't benefit from encapsulation (A point that's arguable but only if you're playing devils advocate)

Also, even using functions and all that to encapsulate each portion isn't going to save you the real trouble here unless you place the second while loop into the function. Now why do I have to use goto here? People unfamiliar with scoping rules should be aware that your instinct to throw a continue statement in in order to skip out of the loop will only skip the current block scope you're in. In other words, a continue in the second while will not break you out of the first while like you need to in order for this algorithm to work. A goto statement ignores scope since it's an unconditional branch.

Let the haters commence:
You might ask me, well obviously that scoping thing makes sense, but the program can be rewritten with functions to be clearer. In which case I'd tell you that Occam's razor holds true for small one off programs like this.

But, just to convince you that the use of goto is a "neccesary evil".  Take a look here I don't know about you, but I trust the kernel programmers. Considering they wrote your operating system, your drivers, and all the things that make your shiny web applications run smoothly.

Book Review: The C Programming Language

The C Programming Language by two really smart guys

The C Programming Language by Brian W. Kernighan, Dennis M. Ritchie is one of the best books I've ever read.

The manner of instruction and the pace it sets is great. There are good explanations on pretty much every subject covered and gotcha's are pointed out whenever there is one. Considering that Ritchie is the creator of the C language and Kernighan is one of the contributors of the original Unix system it's not surprising that the book is so thorough.

The book is small, it's not meant to teach you everything about programming in C, but it's meant to teach you how to use C to express your programming needs. And it does a damn good job of it. The exercises it gives as problems after code listings aren't crap one off programs that you'd write because it's just in the book. But some of them are actually rather useful. For example, The Word Counting (listing 1.5.4) example is a program existing on unix and it's great to see a program that actually exists in the 'real world' of Unix.

I've done a couple of the Exercises out and I've enjoyed it thoroughly so far. I highly recommend purchasing the book or downloading the pdf from the link I provided above.

https://gist.github.com/EJEHardenberg/5931082

The knapsack problem and Budgetting.

I created a prototype for my budgeteer program in my last post, and now I can show you the next stage of the application.

Because the other one was implemented in PHP, html, and javascript it suffered from the fact that PHP scripts are meant to die. While I didn't have any trouble with the script timing out, it seems like a better idea to not have to worry about that at all if I don't have to. Therefore, I moved the application to it's new home in a recent project of mine.

In order to figure out if you can afford your budget there are a few thing's to take into account.

Are your fixed expenses greater than your income?

If your rent cost more than your paychecks for the month combined, you have a problem. Hate to tell you, but you simply can't afford wherever you live. If this is the case, then there's no need to attempt the calculation that would figure out what you're able to purchase from your wish list.

Are your expenses covered?

If you're going out to eat every night with friends and spending twenty dollars each time, unless you have a very nice job and a very affordable living situation, it may be a good idea to stop. In fact, if you can't afford your expenses, it makes no sense for you to even try to determine if you can afford anything on your wish list. It makes more sense to keep your wish list, a wishlist.

Finally, what from your wish list can you afford?

If you've managed to get to the point where all your expenses are covered and you can start eyeing your wishlist for possible treasures, then, and only then is your wishlist going to come into the budget calculation.

How do you do it?

So how do you determine if you can afford all these things? Well, it's a pretty well known problem in computer science called the 0-1 knapsack problem (as long as we're not looking into the date's on the budget, as that will elevate it to a job scheduling problem in addition to the knapsack problem -- which is in the works and might be the subject of my next post) that is actually an NP-complete problem. Or at least, part of it is. Luckily for us, there exist approximation algorithms as well as dynamic programming solutions to the problem.

The problem definition is this: I give you a bag that can hold a certain amount of weight, and a list of items that are heavy and have some value. Your job is to get as much value into the bag as possible without going over the weight limit. If you're curious about the solutions to the problem you can check out the Wikipedia page and read all about them. I found that Mikes Coderama was the most useful source as it was fairly easy to use his code as reference and the Wikipedia pseudo code as a guide as I coded my solution.

Now you might ask, how do you translate my budget into a knapsack problem? We simply define the following mappings:

• Weight Limit becomes our Total Income
• Item Value becomes the Price of any expense
• Item Weight is also the Price of any expense

It's perfectly acceptable to have two properties be the same, if you think about it, it makes perfect sense.  If we wanted to get really fancy, then we could allow a user to order the items in their wish lists or expenses by how much they wanted them and use that as a sort of value multiplier, but to be honest, if you're turning towards budgeting software to help out with your finances, you probably shouldn't have too much of an impact on how valuable you find that extra large big mac over paying your rent. 

Let's talk high level strategy.

Our application breaks up a user's finances into three categories. Checkbook, Bills, and Wishlist. The Checkbook is the only source of Income as well as a source of expenses. Bills are expenses which we absolutely must pay no matter what. The wishlist is self explanatory. 

So first off, we deduct the bills from the income. I thought we were using an algorithm? Don't you worry, we're getting there. But if a user can't afford their bills, then they really shouldn't be spending anything else now should they? Plus, bills tend to be rather high in price, and since our knapsack problem is trying to maximize value of our bag, it's more likely that we'll drop one of our bills in favor of smaller expenses if we have to. And we can't have that since we' need to pay our bills. 

This new quantity of income - bills (let's call the resultant lambda), is our weight limit on our first knapsack problem. First? Yes, first, we're going to solve it twice. Once for our expenses, and once for our wishlist. Why you ask? Because if we can't afford our expenses, then we most certainly are not going to look into purchasing anything from our wish list. Agreed? 

So lambda becomes the weight limit on our knapsack, and we then feed all of the expenses from our checkbook into the algorithm and wait for it to churn out information. Luckily for us, the algorithm will run in O(nW) time with O(W) space where n is the number of items and W is the maximum weight we'll allow in our bag. This is pretty good for an NP problem, and plus, the number of items in our budget will hopefully be rather small considering it's a monthly budget. (And we're assuming we don't go shopping every other day) 

After we've solved the first knapsack problem we can collect the items we included in our bag, and figure out how much money is left over from lambda. Let's call this left over money lambda prime (lambda`) and say it's equal to lambda - (the sum of the values of the items in the previous bag). 

Now, we'll construct our second knapsack problem with lambda` as our weight limit and the items being the wishlist items only if we managed to use all the items in our bag. If so, we'll perform the same calculation again and have plenty of information to send back to the user. 

It works like a charm.