Saturday, May 28, 2011

Typing Alt text on a Mac

I don't know how this works on a PC. But I found how to type alternative characters on a Mac. I kept reading about Ømq, aka ZeroMQ. I did a View Source on my browser cuz I thought Ø was some sort of HTML entity like & . Now I know you just type option-shift-o. This all started cuz a friend typed a tempature as 72º and I thought it was an o in superscript tags (it is option-0). Now I plan on using it all the time cuz the Web is UTF8 not the ASCII I am used to. „´‰ˇÁ¨ˆ. Oooh just discovered  neat.

P.S.
Oh here is Table of many the Characters Mac & PC

P.S. P.S.
And more with links to PDFs listing this stuff

Git ROCKS!

I can totally see using Git just for my personal use; much less all the fancy distributed version control stuff. I already can see me throwing up a Git fork of a Ruby EventMachine lib for using Ømq. There was a method for sending a multipart message as one single call to zmg.send_msg(). I added another call that allowed multiple calls, to zmq.send_more(), for a multipart message before completing the message with zmq.send_msg(). I could put up my simple extension on github.com; send a note to the author; and let him use it or not.

Thursday, May 26, 2011

I am learning Git now

I am reading an online book Pro Git.

It is pretty cool. I can see the Kernel Hacker mentality in it's design. For example, files are stored in .git/objects/ as files with the name is the SHA1 hash. The name of the file exists in a directory like file. This is like files on filesystems stored by iNode number and the name of a file only exists in the Directory file. This makes renames fast and hard links possible in filesystems. It has a similar usefulness in Version Control.

There is a lot more to learn about Git than, for instance, learning how to use Subversion. That is due to the fact that Git does so much more. Git runs completely locally. Switching branches is fast, like renaming a directory; as compared to recursively copying a directory.

I am only up to branching right now. I can definitely see there is coolness behind all the hype around Git. It is not just the Linus Torvalds(tm) brand name. Even for private projects, it looks like it will be useful.

Sunday, May 15, 2011

Things I got right but didn't describe in such detail.

I've read a couple things or three lately that justified some of my strongly held intuitions in the past.

  1. Javascript is really like LISP (and tcl as well).
  2. Event Driven code is not hard; stop complaining you whiner!
  3. Simulating non-blockingness just papers over how dramatic IO is.
  4. Code correctness and Resource contract testing is the Right Thing(tm).
1 & 2 are dealt with in Crockford's Javascript lectures.
3 is sorta dealt with in the Crockford lectures, but I want to write an example of papering over read/write in Ruby/EventMachine.
And 4 was justified in the long winded talk by J.B. Rainsberger Integration Test are a Scam

1 is an observation that Javascript is a Function oriented language and so is LISP. You could probably map Javascript into some LISP-like derivative easily.

2 is a simple argument to make. Browser programming in Javascript is an EventLoop; look at all the total newbies that code Javascript in the Browser.

3 is comes down to the Marx quote "A sufficient change in quantity is a change in kind". IO takes many orders of magnitude more time to execute than all the code that looks like z = x + y or even a1 = sort(a2). If it is so different in time to execute, then it shouldn't be represented as just-one-more-line-of-code.

4 boils down to two parts. One, your basic APIs do what is expected. And Two, your components implement mutually agreed upon contracts. One and Two are easy to test, and they expose the real source of the remaining bugs: Design flaws.

Update:
Here is a table I found.
I/OCyclesOrder
L13100
L214101
RAM250102
Disk41,000,000107
Network240,000,000108

Thursday, May 12, 2011

I have been experimenting with ZeroMQ

It is a good library in several ways:
  • It generates regular sockets and uses the unixy socket APIs.
  • It handles connections automatically. What you really do is announce your desire to have a connection with ctx.connect(type, link, handler). If there is no accepting socket at that location(link) then it will continue to try to establish a connection in the eventloop. Hence, it doesn't matter whether the server or client starts first.
  • The link description contains three items in a URL style string. link = proto://address:port ie "tcp://localhost:3000". Protocols include 'tcp', 'udp', 'inproc', 'ipc', 'pgm' and 'epgm'. 'tcp' and 'udp' are obvious. 'inproc' is an internal to a process memory space pseudo-socket (for thread interop). 'ipc' is Unix file sockets ala /tmp/mysql.sock. And the 'pgm' types are named for a library that does multicast sockets.
  • Then there was framing. All messages are sent a arbitrarily sized opaque blobs. Each message on the wire is a length and a stream of bytes. sk.send("foo") sends 3 bytes (no null term unless you intentionally send that). There is a small addendum to this method, in that it can send many parts inside a single "message", there is a SENDMORE flag with each lowlevel send() call and no SENDMORE flag on the last send() call. send()
  • Lastly there is a type argument of the ctx.connect() call. This sets the "Messaging Pattern" used on the socket. The messageing patterns determine where and how many copies of the message are sent, which messages are recieved versus ignored, and Queueing policy. This is the area I need to delve into deeper. But some patterns are intuitively usable; for instance REQ/REP, PUB/SUB (subsciption topics are trival to the point of lame).
It was created as the simple alternativ to AMQP.

Wednesday, May 11, 2011

I have added Node.js to my Adventures

I have been exploring Node.js. Node.js is intrinsically event driven. I love that it is event driven only. There is no blocking; neither I/O blocking nor even sleep() blocking. The only way to simulate blocking is to use while (true) {}. There is also non-blocking MySQL and PostgreSQL clients.

I have had a series of Jihads concerning Computer languages over the decade. "Threads are Evil" is one such jihad. Of course that is hyperbole. Threads have a good and honorable place it the world o' computing. My beef is that they are used to compensate for blocking I/O and the usual programmer inertia about new things. Additionally, threads have several well known deficiencies. Another is the need for unsigned integers in Java.

Node.js is exceptionally fast compared to other languages. It is based on the Google V8 JavaScript interpreter.

I've liked JavaScript since I had to create a dynamic metrics graph display tool. Now I've found a series of talks by Douglas Crockford that delve into the goodness in JavaScript. The Crockford series were very illuminating for any computer programmer generally, regardless of the Javascript focus. I then realized that Douglas Crockford was the author of an Oreilly book I had purchased recently: Javascript: The good parts.