Simple terminal application for generating a hash (MD5) of an arbitrary directory tree structure.
It will walk the entire structure and successively hash each file, in a deterministic order, cumulatively building a running hash of whats it has seen so far.
Most importantly it will walk the tree in the same order across Windows and Linux.
Great for verifying that a large number of files were all copied to a remote server correctly.
Usage: required argument of path to root folder
Updated (Oct 20, 2016)
>Download
A "mostly" commandline tool for keeping a second (mirror) directory in-sync with a main (polling) directory.
Until I actually did any amount of serious "web" development I never really minded copying changes manually to a remote server. It does, however, get old fast. Like the ubiquitous Adobe Dreamweaver which I've seen used to push changes made to a local directory over to a server, seamlessly, this tool basically replicates that behavior.
Upon starting and selecting the polling/mirror directory the program will first attempt, if directed, to synchronize the mirror dir to match the contents of the polling dir. After doing so ANY changes to the polling dir are watched, and after a few seconds wherein the directory stops changing the program goes to work synchronizing and will start efficiently adjusting the contents of the mirror directory to match, minimizing data flow where possible.
This program was originally designed to keep a server (which could have its drives mapped to your workstation via sshfs/smb/ntfs etc) up to date with as little copying over the network as possible, while at the same time keeping it as up-to-date as possible so you can see your changes. That said, the targets must be paths on the local filesystem as this is NOT a protocol client.
Probably the most useful case for this tool is switching branches locally in the polling dir, and having it quickly mirrored to the server. This is helpful as the server need not have any source control client set up, it merely receives files from your workstation.
If arguments are supplied, as listed below, the program will start and run entirely headless, otherwise it will attempt to open a directory picker for the dirs, and prompt you to do the initial sync.
Usage: $java AutoPathSync <pollingDir> <mirrorDir> <init sync "0"|"1">
Updated (Jan 26, 2021)
>Download
A Vector Display Program
Current Version: 1.0
Written In : Java (build 1.6.0_11-b03)
Updated (June 23, 2009)
>Download
This program grew out of a curiosity to become more familiar with Java's original graphical API, AWT.
While browsing through rtfm.mit.edu I became intrigued with a set of vector map files which had been saved from board discussions dating back to the mid 1980s. (supplied as WorldMap.tar) All the files consisted of line segments, vectors, where each text line represented a segment in the form of (x1, y1) to (x2, y2). After perusing the files for awhile, it became evident that they all belonged to a global coordinate space which could be rendered simultaneously.
What has resulted is my attempt at a small fixed-width windowed application which will display a supplied vector image consisting entirely of line segments. It will render to an area of 830 by 605 give or take, converting all of the coordinates to the new coordinate space, preserving the file's original systemic aspect ratio. The image is drawn in the upper-left most area of the palette.
Initially my interests in doing this resided solely on learning the differences between Java's two graphical APIs, but I would add that I've grown fond of the elegance in vector imagery, and have already noticed a lot of areas where I could improve upon the design.
Future Improvements:
- Create a pan/zoom feature
- Allow for resizable main window
- Create a "render to static buffer" feature
- Add support for a host of other vector primitives, at least ones easily supported by java's paint
- Perhaps support for boolean intersection operations... coloring?
Upon completion I can say a few things about Java's two APIs. Swing will definitely give you more options and methods to control program flow and appearance right up front. However, from my experience it seems that nothing can match AWT's stability, reliability, and speed, especially during program launch. For instance I initially used Java's JFileChooser to select the input upon loading the program. This caused the jvm to hang several times, unpredictably, and inconsistently. It would occasionally fail to appear if it was called initially after the main window was drawn. This forced me to use the much less feature-rich FileDialog, but at the same time sped up the program considerably on load.
The program reads UNIX/Windows formatted text files (LF, CR/LF), in the format of the ones supplied above in the "WorldMap.tar". Input coordinates can be anything that a double precision floating point can be. Spaces delimit the coords, and negatives are welcome. The file coordinate space origin is interpreted to be in the lower left for (+,+) coordinates, this is the same as the traditional 2d coordinate space.
