I found these to be really helpful. This takes the contents of the
HEAD of your development tree and archives it in a zip or tarball with
the same name as the directory that you're currently in (e.g. if
you're in /home/user/foo it'll create foo.tar.gz). This also sets the
prefix to the same name-of-current-folder so when unzipped it will be
in a tidy subdirectory and not all over the place.

 
alias gitz="git archive --format=zip --prefix=\"$(basename $(pwd))/\" HEAD > \"$(basename $(pwd))\".zip" 
alias gitar="git archive --format=tar --prefix=\"$(basename $(pwd))/\" HEAD | gzip > \"$(basename $(pwd))\".tar.gz" 

Plus I like the name "gitar" (guitar).

 
# obfuscating an email address (for posting on web) 
# idea: f generates a "one time pad" that's XOR'd with my email 
# address. give the attacker f, (but not the values of f) and 
# the xor'd integer sequence they compute 
# p_i = f(n+i) XOR c_i 
# where p_i is the ith plaintext and c_i is the ith munged char. 
# This works if there's no practical way to get f(n+i) other than 
# computing and computing it is *hard* (in the computability sense) 
 
f = lambda n: # (some expensive function of n) 
encode = lambda string, strength: map(lambda c, x: ord(c)^x, string,\ 
 [f(n) for n in range(strength,strength+len(string))]) 
 
# [list, of, nums] 
 
decode = lambda nums, strength: "".join(map(lambda c, x: chr(c^x),\ 
 nums, [f(n) for n in range(strength,strength+len(nums))])) 
# [original text] 

To provide my email address, I just give a python command line that
invokes decode on the embedded data (also must provide f). Like:

 
 
$ python -c 'f=...' 

Cranking up (via property 3) the toughness of the decoding should be a
nice deterrent. Also nice would be a script that replaces all
instances of email addresses on a site with encoded versions.

I wrote some code in clojure to play around Kaprekar's Operation:
 

 
(defn fix 
 "Finds a fixed point of a function." 
 [f init-val] 
 (loop [last-val init-val 
  curr-val (f last-val)] 
  (if (= curr-val last-val) 
  curr-val 
  (recur curr-val (f curr-val))))) 
 
(defn sort-digits 
 "Sorts the digits in a number, default is ascending." 
 ([n] (sort-digits n true)) 
 ([n ascending?] 
  (let [cmp (if ascending? 
  #(.compareTo %1 %2) 
  #(.compareTo %2 %1))] 
  (Integer/parseInt (apply str (sort cmp (str n))))))) 
 
(defn kaprekar-operation 
 "Run one iteration of the kaprekar operation (e.g. 4321 - 1234)" 
 [n] 
 (- (sort-digits n false) (sort-digits n)))


(defn kaprekar-fix
 "Report on the fixed point of the Kaprekar operation starting
 from the INITIAL value (should be 6174 for 4-digit nums)" 
 [initial] 
 (fix kaprekar-operation initial)) 

(kaprekar-fix 2315)

Click here to download:

hexclock_visual.jar (592 KB)

This is the second installment of my Clojure ( http://clojure.org )
hex clock postings. I think I covered most of the discussion in the
last one. This post is just for my other design. This version
represents the time visually, as a series of colored squares. The MSB
is in the upper left and represents a half day. Read it just like the
(English) newspaper, left to right top to bottom. The LSB is in the
lower right and changes every 1.3 seconds. This makes it easy to
orient the clock.

Click here to download:

hexclock.jar (553 KB)

I've been meaning to "release" a clojure program into the wild. Partly,
I want to take advantage of how nice it is to be able to deploy via jar
file, and partly because I've been wanting this application.
 
So, without further ado, here's my hexclock (as an executable jar file).
Source is included and is covered by the GPL
http://www.gnu.org/copyleft/gpl.html
 
Just FYI
sha1sum: ac0b67fa8252bf06f00d627dfc3f2975b1c45a30 hexclock.jar
 
Here's some explanation if you're confused. The basic idea is to divide
a day into half, so now we can say if it is AM or PM; easy but, I would
say, a little too coarse of a measurement. With the AM/PM clock, you'd
only need one bit ("is it morning?"). Continuing, next we can divide our day
into 4 equal parts, now we could (using two bits) say whether it was the
first part of the morning "early morning" or the second part of the
morning "late morning." Likewise we could talk about whether it were
late or early PM. These chunks would be 6 hours long. You can see that
we can keep dividing our day like this as much as we want, with each
division we need one more bit to talk about the time and we get twice as
many (and twice as short) chunks. In fact, if you wanted to keep going
until you got something like a second, it just so happens that you'd be
using 16 bits (though, it is a pretty close call (about 32% error versus
34%)). Which just happens to work really nicely for binary arithmetic as
we'll see.
 
Make sense doesn't it? While I have you agreeing with me (if you are),
stop and think about this for a bit, the steps to divide up time into
hours, minutes, and seconds are not at all constant. You must divide a
day into 24 hours, then an hour into 60 minutes and then again a minute
into 60 seconds. Quick, how many seconds in a day? The answer isn't
anything in particular, 86,400 (24*60*60). A fun number for us physics
nerds to memorize as an undergrad, but just that, an arbitrary constant.
 
The way that the clock works is just to represent the day as a 16 bit
number (0 through 65535), if you are accustomed to hexadecimal, this is
0x0000 through 0xFFFF. Hex has the nice property that each digit is four
bits (sometimes called a nybble, half a byte, get it? Well, I like it).
Numbers go 0-9 like usual but then we use A, B, C, D, E, and F for 10
through 15. I somewhat arbitrarily (and somewhat not) divide this number
into two parts the "high" byte (two hex digits) and the "low" byte (the
last two hex digits). I separate the time with a vertical bar like this:
"AB|CD", if you are a programmer this is meant to evoke logical OR. You
can imagine that the time is 0xAB00 | 0x00CD and they get smushed
together with the or operator.
 
When I implemented this in Python:
http://twopoint718.blogspot.com/2008/08/hex-clock.html I talked a bit
about the scale of the digits on the clock. The last digit changes every
1.318 seconds, the next most stable digit changes just about every 21
seconds. The next (the "B" in my example above) switches once every 337
seconds or about 5 and a half minutes. The most stable digit changes
only 16 times a day, since both 24 and 16 are divisible by 4 this makes
that digit equal to 90 minutes (1.5 hour). My proposal is to talk about
the first, most stable digit as hex hours, the second as hex minutes,
and the last two digits are hex seconds. My coined terms for these are
"hexours" (HEX-zours), "hexinutes" (HEX-inuts), and "hexeconds"
(HEX-econds). There are 256 hexeconds in a hexinute and 16 hexinutes an
an hexour. Alternatively, you could just say there it is AB "in the big
byte" and CD "in the little byte". I imagine people would just call out
the time "it is ABCD." To avoid confusion, I think all digits should
always be pronounced "zero, zero, zero, one," though maybe we could all
use the English "z" sound of "zed-zed-zed-one" because it cuts down on
the syllables. But when in doubt, if fewer than four digits are
announced, we should assume that they are talking about the most
siginificant digits first (much in the way that we say "it is 3
o'clock").
 
You can read the post that inspired this idea here:
http://halcanary.org/vv/2007/10/31/706/
 
You can read more about hex time here:
http://www.intuitor.com/hex/hexclock.html (this clock is really similar
to mine, we just group the digits differently, either one is fine).
Wikipedia has an entry about it here:
http://en.wikipedia.org/wiki/Hexadecimal_time (maybe I should change my
digit grouping?)
 
Don't confuse this method of marking time with other binary clocks.
Often they are using binary coded decimal:
http://en.wikipedia.org/wiki/Binary-coded_decimal
Until recently this clock was an example (they added a "true binary"
switch):
http://www.thinkgeek.com/homeoffice/lights/59e0/