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