Posted by Nick Sieger
Fri, 12 May 2006 03:25:00 GMT
In this podcast from minnebar 1, Jamie Thingelstad, CTO of
marketwatch.com, describes a real-world, scalable application of
asynchronous javascript that uses an event-driven model rather than
polling.
I enjoyed the session and think it’s worth a listen – there are some interesting approaches discussed, including a back-off strategy that helps give the server a chance to tell its javascript clients to not hit it so hard when it’s under duress.
Download the podcast here, or put my feed in iTunes or another podcatcher to have the podcast downloaded for you. I should be posting more minnebar podcasts in the coming days.
Posted in random | Tags minnebar, podcast | no comments | no trackbacks
Posted by Nick Sieger
Mon, 08 May 2006 03:17:00 GMT
It’s going to take me a while to recover from minnēbar. I met some great people, got motivated by some new noble ideas, and generally had a blast. A thousand kudos to Ben as well as the sponsors for making the event a smashing success.
But, let’s not stop there. We made some initial contact, hit it off well, vibed off of the energy in the venue. I’d be disappointed to say the least if I didn’t hear from anyone for another six months until the next event gets planned and scheduled.
So, can we make a concerted effort to keep in touch? May I suggest a monthly (or so) geek dinner, drinks or something similarly informal (e.g., the Friday night get together? I wasn’t there) where we can keep some momentum going and build our relationships? Find out where our own strengths are and how we complement each other?
If there’s one thing coming out of Saturday’s event where I hope we have a shared vision, it’s for increasing the amount of innovation in the technology sector in the Twin Cities. This group of people has the talent to make that real.
On a side note, I recorded four sessions of audio from Saturday, and at first listen they appeared to come out pretty well. I hope to post them in the coming days.
Another side note: the “ē” in minnēbar is represented in HTML as unicode entity ē. Don’t let your minnēbar posts suffer encoding issues on the highway!
Posted in random | Tags minnebar | 1 comment | no trackbacks
Posted by Nick Sieger
Fri, 05 May 2006 14:24:00 GMT
Spotted on ruby-talk today was this anecdote on a Ruby
hacker/father and son, and I just had to share here.
I trotted my 11 year old son over to the Poignant Guide and he
laughed like crazy at the Cartoon Foxes and did a little
programming, but soon got bored. Wait a minute Alex, let’s try one
more thing, Dwe.. Array. Wow, how do I make my R kill big time (He
knows all about cheats). I showed him the character’s values and he
promptly put in a hugh number for the Rabbit’s strength. He was
delighted to see the larger and larger negative life values appear
whenever he attacked. Dad, is this how all my Gameboy programs
work? Yes, son. Hey, dad I want to do 6dof animation too, can you
teach me? Yes son, here’s a few books for you – Computer Graphics,
Foley et al and Physics for Game Developers, Bourg. Not sure he’ll
read them right away, but the whole episode saved me another $49.95
Game Cube cartridge.
Posted in ruby | no comments | no trackbacks
Posted by Nick Sieger
Tue, 02 May 2006 18:56:00 GMT
I had a chance to dabble around with Python a tiny bit today, building the XSV XML schema validator. Got it working fairly easily on my MacBook Pro after a minor detour. Later, I needed to build another copy on a shared linux dev box where I didn’t have root access. Now how does this work in Python? Fortunately, the answer was close at hand: a virtual python instance. Nice! You can create a replica of the main python install, and add your personal site-packages there. The only thing that gets copied is the python executable plus a bunch of symlinks to the main libraries and packages. After that point all you need to do is put your virtual python executable ahead of the main executable on your PATH.
If I were to install local packages/gems with Ruby, I’d probably either build my own Ruby or maintain a local packages directory and constantly customize RUBYLIB. Seems like a suboptimal solution. Has anyone attempted a virtual-ruby.rb that does the same as virtual-python.py?
Posted in ruby | 3 comments | no trackbacks
Posted by Nick Sieger
Sat, 29 Apr 2006 03:43:00 GMT
Short bio moment: I am a jazz musician. I have not been actively
playing in recent years as my dual life as information economy worker
and father have dominated, but the essence of jazz as a form of
communication, interaction, problem solving, patterns, repetition, and
creativity have remained in the core of who I am. Whenever I’m having
a down-cycle in my life, it always seems like it’s because I’ve gotten
away from listening to jazz.
So, with that as background, imagine you’re me and go read Garr
Reynold’s recent post on Jazz and the art of connecting.
Even if you’re not a jazz lover, many of the quotes there resonate so well
with any aspect of a creative profession. My favorite (and Garr’s):
“Anyone can make the simple complicated. Creativity is making the
complicated simple.” – Charles Mingus
Now, 37 signals may appear to have the recent trademark on “embracing
constraints” and its relation to creativity, but it sounds like
Charles beat them to the punch! Time to go dig around in some jazz
biographies again!
Posted in random | no comments | no trackbacks
Posted by Nick Sieger
Wed, 26 Apr 2006 18:39:00 GMT
Just stumbled upon this interview with Bill Joy from a couple years ago and it’s full of quotables. This one caught my eye:
What about the open source idea in general?
Open source is fine, but it doesn’t take a worldwide community
to create a great operating system. Look at Ken Thompson
creating Unix, Stephen Wolfram writing Mathematica in a summer,
James Gosling in his office making Java. Now, there’s nothing
wrong with letting other people help, but open source doesn’t
assist the initial creative act. What we need now are great
things. I don’t need to see the source code. I just want a
system that works.
It’s a good reminder that just because something is “open source” that doesn’t make it a great idea. Brilliant ideas are created in the minds of a few – the wisdom of the crowds usually just ends up diluting a good idea.
Posted in random | no comments | no trackbacks
Posted by Nick Sieger
Sun, 23 Apr 2006 04:02:00 GMT
IRB (Interactive Ruby Shell) is one of those tools that a hacker
learning Ruby hopefully discovers right away. It’s an extremely
useful way to learn the language, verify hunches, test assumptions,
and get immediate feedback. IRB promotes learning by doing, which is
the best way of making something stick in your head. (You can even
try an online version of irb without even installing Ruby!)
The first order of business when using IRB is to setup your
preferences. If you haven’t done so already, create the file
~/.irbrc (%USERPROFILE%.irbrc on windows native ruby). .irbrc
is just a regular ruby script where you can run arbitrary ruby code at
the start of your IRB session. Add the following to .irbrc:
require 'irb/completion'
ARGV.concat [ "--readline", "--prompt-mode", "simple" ]
This sets up usage of readline in your session and turns on TAB
completion, making IRB feel as comfortable as regular old bash. Now
you can type Kernel::<TAB> and get a list of available methods!
Good.
Next, the thing that you find yourself doing after using IRB for a
while is cutting and pasting code from your console buffer over to
your text editor. Don’t have Ruby’s reflection rules down yet? Not
sure whether to use instance_eval or module_eval when working on
that metaprogramming hack? Working inside Rails’ script/console and
searching for the right ActiveRecord finder options? No matter how
good your terminal program, you probably have to use the mouse to
select text out of it to copy to your text editor, and hackers hate
having to switch from the keyboard to the mouse when in the flow of
programming.
So here’s a technique that will append commands entered in your IRB
session to a file in your home directory (idea from
ruby-talk:58931). Put the following in your .irbrc:
module Readline
module History
LOG = "#{ENV['HOME']}/.irb-history"
def self.write_log(line)
File.open(LOG, 'ab') {|f| f << "#{line}
"}
end
def self.start_session_log
write_log("
# session start: #{Time.now}
")
at_exit { write_log("
# session stop: #{Time.now}
") }
end
end
alias :old_readline :readline
def readline(*args)
ln = old_readline(*args)
begin
History.write_log(ln)
rescue
end
ln
end
end
Readline::History.start_session_log
Now every line typed into IRB will immediately be saved into
~/.irb-history. Exercise left to the reader to bind a custom
keystroke and macro to yank the last line out of that file and
automatically paste into your text editor.
Long-time bash users know that the shell maintains a history of
commands across sessions so that you can access commands you typed
yesterday. Wouldn’t it be nice to do this in IRB as well? Wish
granted:
require 'irb/ext/save-history'
IRB.conf[:SAVE_HISTORY] = 100
IRB.conf[:HISTORY_FILE] = "#{ENV['HOME']}/.irb-save-history"
Happy ruby hacking! If you find any more handy IRB tips leave them at
rubygarden, and let me know about them.
Footnote: I realize there is duplication and non-DRY happening here
with two copies of your IRB history, but I came across these
techniques at two different times, and the functions they serve seem
different enough to potentially use them both. If you don’t like
that, choose whichever is more appropriate for your needs.
(Hope this post serves your needs Dan.)
Posted in ruby | 2 comments | no trackbacks
Posted by Nick Sieger
Fri, 21 Apr 2006 04:00:20 GMT
Hello there, gentle reader! Thanks for stopping by and helping me re-establish my own corner of the web.
My name is Nick. I’m a hacker originally from and currently located in Minneapolis, MN. I experimented with blogging for a while at my Radio weblog, Klactoveesedstene and finally decided that I need to reset and try this thing again.
My current interests are fairly broad, but to list a few specific examples:
- Ruby and dynamic languages
- Language design, domain-specific languages, and expressiveness in programming
- Less code and DRY
- Javascript as a serious programming language, AJAX, Rails, Greasemonkey
- SCM, continuous integration, build tools (maven2, rake)
- Testing methodologies: developer testing, TDD, BDD, web testing (watir), FIT
- and (the famous) much much more…
A bit about the setup here. First, a plug for the folks at Rimuhosting – I’ve got a VPS with Rimu. They set it up for me within about an hour of placing an order (on a Saturday, no less!), and I was off and running. I chose Ubuntu Breezy for my distro, and it came spanking clean – extremely minimal, so that I can practice additive rather than subtractive security on my server and install only what I need. I contemplated going with shared hosting for a little while but given that I like to tinker with stuff I’m really glad I chose a setup with root access.
First order of business when setting up the server is to get Subversion, Trac, and ruby. Building my own Ruby 1.8.4 proved a bit of an extra challenge since things you’d think were pretty essential in a distro like openssl, gdbm and zlib were actually missing, but they were easily apt-gettable. By the end of the weekend I had purchased domains from Go Daddy, assigned the DNS entries in Rimu’s control panel, had Apache2 up and running with my very own svn, trac and typo instances running. Very slick!
And now in the words of Guy Kawasaki, I hope to use the word “I” a lot less if possible on this blog. Back to your regularly scheduled hacking…
no comments | no trackbacks
