Entries Tagged 'phrack' ↓

splitr

I was trying to dig through some log files the other day which aren’t log-rotated with any regularity and so were of a size that would have made a viewer choke on them had I tried to open them. After a little digging I came across the Unix tool ’split’ which did exactly what I wanted it to, take a file and chunk it up into smaller files based on some criteria you provide. Well, after diddling with it for a bit I was unhappy with some things, notably the output names and that there doesn’t seem to be a way to tell it “split on some number of lines, but not if you’re in the middle of a paragraph” so errors to my logs (with their stack traces) were often getting cut off. After a little noodling on the problem I wrote this quick script that will do the same thing as split but with additional features.

1. Go grab the file here: splitr
2. Copy splitr into whatever directory on your system contains executables (I don’t remember what it is for Windows, but for OS X put it in /usr/bin)
3. Make it executable (chmod a+x on OS X or *nix)
4. Start splitting files.

Introducing phrack

Meet phrack, my completely unimplemented rack based web framework (I’m hoping to have a basic implementation done by the end of the week).  It is entirely a pet project to learn more about the implementation of a web framework, to better understand the application stack while not getting too attached to any one implementation (Merb and Ruby being the heavy-weights in my day-to-day right now).  I’d like to thank Pratik Naik for his great articles on the subject (Ruby On Rack #1, Ruby On Rack #2).  If you want to start digging in and working with Rack they are a great place to start.

Two other items.  I’ve pushed some updates to my fork of the Screw.Unit Server javascript testing framework.  You can grab the code here.  My changes include the ability to pass spec names to your before/after blocks for debugging purposes (this combined with Blackbirds profile debugger can give you awesome performance metrics on your javascript code), and top-level describe blocks now collapse if all of its contained specs pass (except when running a focused spec, for obvious reasons).  It’s a good first pass, but I’m going to shift around some code to improve performance when I get a chance.  The other item is that I’m officially starting to work on my book (finally), tentatively titled “Test-Driven Development with Javascript”.  This is something that I feel very strongly in as a development practice, and I think is an area that could use some guides to help developers see that a) yes, you can test your javascript and b) that there are several options for doing so.  I’ll be putting updates about the status of the book here as I make progress.  Also, interested parties may be tapped for helping review my early drafts to make it as useful as it possibly can be.