Lately I'd say I've been reading roughly 1 out of every 20 Slashdot articles that come through my feedreader. And when I say "reading" I mean reading _all_ the comments. As any other Slashdot aficionado can tell you, there are often hidden diamonds of anonymous nerdiness buried within the rough of fanboy excrement that can be found in no other place. That's what keeps me
coming back I guess.
Yesterday an article mentioned Ioke which caught my attention mostly for being a brainchild of Ola Bini. To no surprise of my own, the best part of this post was the comments.
In one corner you have Ola Bini, a prolific self-trained hacker, author and speaker, talking about what he does in his spare time and how he has a a roughly working new language that has some interesting features (for some definition of "interesting"). In the other you have a sea of nerds who Just Don't Get It. Ola is not trying to create yet another language whose documentaion will clutter blogs and a bookstore near you. He's just having fun.
While he is a promenent member of the Ruby community, I definitely wouldn't label him as a Ruby programmer any more than I would label him a Blub programmer. He, like most of the people I know in the Ruby community, loves computer languages. I started to understand this at RubyConf last year when Matz showed off his Python shirt during the keynote. This year he spoke again of his love for (almost) all computer languages while Dave Thomas proclaimed that now is the time to fork ruby (for reasons no Slashdot pundit would understand). I highly recommend Dave's keynote to anyone who's interested in why we program computers. I suspect it will eventually be available at this link: http://rubyconf2008.confreaks.com/
Tuesday, November 11, 2008
Tuesday, August 12, 2008
Ruby 1.8.7
I must say I'm a bit worried by the 1.8.7 release. The only reason I even care out about it is because I recently was bitten by a bug in 1.8.6p230 that, as of the time of this blog entry, is the latest version in Fedora. Quite frankly I am surprised whenever Fedora decides not to ship the latest "stable" upstream package which is why I took the time to understand the state of 1.8.6.
I think the main problem is that the goal for 1.8.7 is unclear, at least from the community's perspective. Contrast this situation with 1.9--a release I'm actually excited about. There are plenty of people telling you what to expect from 1.9. Matz talked about it at RubyConf last year. There's even a beta book out about it now.
In short, 1.9 represents the correct way to work with the community to move a platform forward. Namely, coupling core changes that likely break the killer apps with features that entice developers to go through the effort of porting their code. 1.8.7 needs as many eyes looking over it as possible and it's just not attracting them in my opinion simply because the community doesn't see a reason to upgrade.
I think the main problem is that the goal for 1.8.7 is unclear, at least from the community's perspective. Contrast this situation with 1.9--a release I'm actually excited about. There are plenty of people telling you what to expect from 1.9. Matz talked about it at RubyConf last year. There's even a beta book out about it now.
In short, 1.9 represents the correct way to work with the community to move a platform forward. Namely, coupling core changes that likely break the killer apps with features that entice developers to go through the effort of porting their code. 1.8.7 needs as many eyes looking over it as possible and it's just not attracting them in my opinion simply because the community doesn't see a reason to upgrade.
while(burn :me)
desire_to_upgrade = ignore(:version => :latest_stable)
raise if desire_to_upgrade.nil?
end
Wednesday, April 9, 2008
Shell History Meme
/me is thrilled svn isn't anywhere on this list.
[bleanhar@tumbolia ~]$ history | awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
418 git
166 ls
95 cd
72 exit
58 vim
19 screen
19 rm
16 pwd
14 tig
13 sudo
Tuesday, March 25, 2008
My ctags lightning talk
Last week at the Raleigh.rb we had an evening of lightning talks. I presented
a handy utility called exuberant ctags for indexing source code and showed
how nicely it plays with Ruby and Vim. Here's a recap of my 5 minute lightning
talk (along with a few points I failed to mention).
Setup:
# From the top level of your project
ctags --recurse
Once it finishes there will be a file called 'tags' in your working directory.
In my case vim loads tag files automatically if it finds them in the same
directory from which it was launched. If for some reason your version does not
do this for Ruby files you can type the following in command mode:
set tags=[path to your tags file]
To make the change permanent add the following to your vimrc:
# Look for a tags file in vim's working directory.
au BufRead,BufNewFile *.rb set tags=tags
In both cases a comma separated list is accepted. This is nice if you are
working on multiple projects.
Usage:
ctags works with most real text editors though I'm only experienced with the vim
integration. Basically, once vim has loaded the tags file you can place
the cursor on top of any word and press cntrl - ] to jump to the
declaration. In some cases users will notice their terminal also has that
specific key combination bound. Under gnome-terminal I have to press cntl-shift - ] to
access my tags. In the case where more than one tag matches a selection
mode will be displayed. Usually it's fairly obvious which one you want.
Also worth mentioning is vim's tagstack. It works pretty much as expected. You push down as far as you
want and then use cntrl - t to pop back.
Limitations:
Obviously this sort of indexing faces challenges when working with a language
as dynamic as Ruby. Things that trip it up are method aliases and any fancy
metaprogramming.
ctags vs rtags
There is a Ruby ctags alternative called rtags. In my opinion ctags works better:
a handy utility called exuberant ctags for indexing source code and showed
how nicely it plays with Ruby and Vim. Here's a recap of my 5 minute lightning
talk (along with a few points I failed to mention).
Setup:
# From the top level of your project
ctags --recurse
Once it finishes there will be a file called 'tags' in your working directory.
In my case vim loads tag files automatically if it finds them in the same
directory from which it was launched. If for some reason your version does not
do this for Ruby files you can type the following in command mode:
set tags=[path to your tags file]
To make the change permanent add the following to your vimrc:
# Look for a tags file in vim's working directory.
au BufRead,BufNewFile *.rb set tags=tags
In both cases a comma separated list is accepted. This is nice if you are
working on multiple projects.
Usage:
ctags works with most real text editors though I'm only experienced with the vim
integration. Basically, once vim has loaded the tags file you can place
the cursor on top of any word and press cntrl - ] to jump to the
declaration. In some cases users will notice their terminal also has that
specific key combination bound. Under gnome-terminal I have to press cntl-shift - ] to
access my tags. In the case where more than one tag matches a selection
mode will be displayed. Usually it's fairly obvious which one you want.
Also worth mentioning is vim's tagstack. It works pretty much as expected. You push down as far as you
want and then use cntrl - t to pop back.
Limitations:
Obviously this sort of indexing faces challenges when working with a language
as dynamic as Ruby. Things that trip it up are method aliases and any fancy
metaprogramming.
ctags vs rtags
There is a Ruby ctags alternative called rtags. In my opinion ctags works better:
- ctags is several orders of magnitude faster that rtags. On my laptop a 100,000 SLOC project is indexed in less than one second. rtags takes about a minute to do the same.
- ctags supports dozens of languages. Run ctags --list-languages to see them all.
- rtags has trouble parsing files on most Ruby projects I work on. This is what led me to switch back to ctags in the first place.
- rtags claims to be more aware of Ruby syntax though in practice I find it indexes many things I just don't care about.
Saturday, March 8, 2008
GEB part two
I finished the second (and final) part of "Godel, Escher, Bach" last weekend. Originally I was thinking about all the clever things that could be said about the book but now I don't think there is much value in doing so. The one thing I can say is that this book was vital in luring me out of my mental rut of technical reading. In short, I recommend this book to everyone.
It's hard to express in words exactly why I believe this book is such an important read. Ironically, that is one of the major themes from the book. It deals greatly with holism vs. reductionism. I can see quite patently that the whole of GEB is greater than the sum of it's chapters.
Should you decide to read GEB I suggest that you read the entire work. Due to its length it's probably one of the most half-read books of our time. Many of the people that recommended the book to me said things like, "It's a great book! Though I only read the first (x) pages". Strangely enough I did meet one person who said they read the entire work in 18 hours straight.
No matter how long it takes if you stick with it you will be rewarded many times over. It took me 3 months and I confess there were indeed times in which I felt I was understanding very little. However, time after time, I would reach a point where things started weaving together in the sort of "Eternal Golden Braid" that I believe Hofstadter intended. I venture to say that, while you may indeed walk away with completely different insights about the book's "meaning", your experience will be quite similar.
It's hard to express in words exactly why I believe this book is such an important read. Ironically, that is one of the major themes from the book. It deals greatly with holism vs. reductionism. I can see quite patently that the whole of GEB is greater than the sum of it's chapters.
Should you decide to read GEB I suggest that you read the entire work. Due to its length it's probably one of the most half-read books of our time. Many of the people that recommended the book to me said things like, "It's a great book! Though I only read the first (x) pages". Strangely enough I did meet one person who said they read the entire work in 18 hours straight.
No matter how long it takes if you stick with it you will be rewarded many times over. It took me 3 months and I confess there were indeed times in which I felt I was understanding very little. However, time after time, I would reach a point where things started weaving together in the sort of "Eternal Golden Braid" that I believe Hofstadter intended. I venture to say that, while you may indeed walk away with completely different insights about the book's "meaning", your experience will be quite similar.
<obligatory_Reading_Rainbow_quote>
"But you don't have to take my word for it..."
</obligatory_Reading_Rainbow_quote>
Wednesday, February 27, 2008
Success with gstreamer
A few weeks ago I nearly threw my laptop down the hallway at work out of frustration with Kino and Pitivi. All I wished to do was create a simple screencast using open source software. I later tried some tips I found on the Fedora Screencasting wiki only to find the recommended splice script out of date.
Though the script was broken on F8 it did give me insight into the power of the gstreamer framework. I knew that whenever I had the time I should dig in a little deeper. With the help of this Linux Conf Austrailia talk I was able to figure out what needed to be changed in order to get the splice script working again on F8.
Here's how I spliced my theora video (made with istanbul) with a wav file recorded in audacity:
gst-launch oggmux name=mux ! filesink location=ldap-gst.ogg { filesrc location=ldap.ogg ! decodebin name=v } { filesrc location=ldap-audio.wav ! decodebin name=a } { v. ! queue ! ffmpegcolorspace ! theoraenc ! queue ! mux. } { a. ! queue ! audioconvert ! vorbisenc ! queue ! mux. }
As a big fan of golfing on the command line I can appreciate convoluted oneliners. The big trick to getting the fedora-av-splice.sh script running was:
Though the script was broken on F8 it did give me insight into the power of the gstreamer framework. I knew that whenever I had the time I should dig in a little deeper. With the help of this Linux Conf Austrailia talk I was able to figure out what needed to be changed in order to get the splice script working again on F8.
Here's how I spliced my theora video (made with istanbul) with a wav file recorded in audacity:
gst-launch oggmux name=mux ! filesink location=ldap-gst.ogg { filesrc location=ldap.ogg ! decodebin name=v } { filesrc location=ldap-audio.wav ! decodebin name=a } { v. ! queue ! ffmpegcolorspace ! theoraenc ! queue ! mux. } { a. ! queue ! audioconvert ! vorbisenc ! queue ! mux. }
As a big fan of golfing on the command line I can appreciate convoluted oneliners. The big trick to getting the fedora-av-splice.sh script running was:
- Remove the version number from the 'gst-launch' executable (why hard-code that anyway?)
- Corrected syntax (honestly, I mostly cargo-culted this from examples I found on the interweb)
- Changed 'rawvorbisenc' to plain old 'vorbisenc'. The talk mentioned 'gst-inspect' which for me was the key to finding out what my system could do.
Sunday, February 10, 2008
Getting your parents to run Fedora: Challenge 1
Problem 1: Remote system administration
As other people in the session shared their similar philanthropic tech support stories we soon discovered our first problem. A problem which has led to much headache for all involved and marred the name of open source. The issue we speak of in this entry is that of remote system administration.
You can't be serious
It definitely seems odd that a group of people consisting of either developers or system administrators would face challenges with remote administration. I mean, just about every machine I work on is "remote". It's typically a Xen guest whose physical host location is both unknown and unimportant to me. But the fact of the matter is that, when dealing with our family, we're often thrown into a world (almost) completely unfamiliar to us; the world of people who do not attend FUDcons.
"Oh, but I am serious" or Phone support for the inlaws
To make things a little more concrete I'll share a little about a strange tradition in our household. Each year my wife and I fly out to visit her relatives. With impeccable regularity, during our vacation one of their Windows machines goes up in flames due to some mixture of bugs and malware and, with similar predictability, I install Fedora on their machine. The sad part to the story is that every year they end up having to remove Fedora and switch back to Windows simply because we fly back home and they don't have anyone else nearby that can help them. The truth is they have equally as many problems with Windows. It just happens to be the case that they have had years of experience with 'workarounds'. I can't tell you how many times we've had conversations on the phone like this:
I was quite surprised when several people from the Fedora project actually suggested not installing Fedora in this particular case. After talking a bit more what they really meant was, "don't install Fedora, yet". In certain cases it can be almost traumatic to have their entire digital world flipped on them. Find _good_ open source solutions to the areas where they are locked in. Once successful the switch to Fedora will be a lot smoother. After all, it's typically the case that a person only uses a handful of rather basic apps and they only have one or two apps where they are truely 'locked in'. In my mother-in-law's case it's Sibelious. Sadly, GNU Denemo didn't work well for her.
For remote support we really need something better than
Wish list for remote tech support
The second challenge: Usability
As other people in the session shared their similar philanthropic tech support stories we soon discovered our first problem. A problem which has led to much headache for all involved and marred the name of open source. The issue we speak of in this entry is that of remote system administration.
You can't be serious
It definitely seems odd that a group of people consisting of either developers or system administrators would face challenges with remote administration. I mean, just about every machine I work on is "remote". It's typically a Xen guest whose physical host location is both unknown and unimportant to me. But the fact of the matter is that, when dealing with our family, we're often thrown into a world (almost) completely unfamiliar to us; the world of people who do not attend FUDcons.
"Oh, but I am serious" or Phone support for the inlaws
To make things a little more concrete I'll share a little about a strange tradition in our household. Each year my wife and I fly out to visit her relatives. With impeccable regularity, during our vacation one of their Windows machines goes up in flames due to some mixture of bugs and malware and, with similar predictability, I install Fedora on their machine. The sad part to the story is that every year they end up having to remove Fedora and switch back to Windows simply because we fly back home and they don't have anyone else nearby that can help them. The truth is they have equally as many problems with Windows. It just happens to be the case that they have had years of experience with 'workarounds'. I can't tell you how many times we've had conversations on the phone like this:
mother-in-law: The internet is broken on my laptopCurrent recommendation for my inlaws:
me: Opps, that was probably my fault. Remember that thing I mentioned to about Ogg Vorbis? Well when I ssh'd into your machine this morning to make it so that you could view our family videos I accidentally upgraded your kern...
*mother-in-law* interupts,
mother-in-law: Uhh... what can I type to fix this? I need to check my email.
me: Press alteff too. Then type 'nome terminal'. Then type 'pseudo sue dash enter'. Then type 'yum update eye dubya...'
(I'm trying my best to faithfully represent the role poor mobile phone connectivity plays in to these scenarios.)
I was quite surprised when several people from the Fedora project actually suggested not installing Fedora in this particular case. After talking a bit more what they really meant was, "don't install Fedora, yet". In certain cases it can be almost traumatic to have their entire digital world flipped on them. Find _good_ open source solutions to the areas where they are locked in. Once successful the switch to Fedora will be a lot smoother. After all, it's typically the case that a person only uses a handful of rather basic apps and they only have one or two apps where they are truely 'locked in'. In my mother-in-law's case it's Sibelious. Sadly, GNU Denemo didn't work well for her.
For remote support we really need something better than
- explain how to activate desktop sharing
- reverse an ssh connection
- port forward to their vino server
- launch vnc viewer over lousy internet connection and try to couch family member on what button to click on to fix their problem
Wish list for remote tech support
- An effective way to securely establish connections with nontechnical users and their trusted, penguin-loving friends. When connecting two people that are both on networks with some form of NAT you are frequently forced to use a third, internet addressable, machine in order to establish a connection. Obviously you can get around the use of a third party if you control the router on your end, but that's not always the case. Say my mom calls from home and I'm at coffee shop or at work.
- A disaster recovery strategy that protects our family members from being forced to return closed source alternatives. With my inlaws some unrecoverable (at least over the phone) situation always comes up and they are forced to do the only thing they know how to--pay someone to install Windows.
- Use a service to spin up secured Fedora virtual machines over the internet. From there have an applet on their dock to request a connection from their trusted friend. Some form of remote desktop connection is then made over a tunnel ssh connection that is brokered by the VM. Of course using such a service would always require money. In the case of the EC2 it's pretty cheap in comparison to the cost of paying some Geek Squader to fix things. With Amazon's DevPay (A service that allows people to pay for usage of VMs) it would be possible to even have a system for Fedora community members to raise support for the Fedora project by volunteering to fix people's machines.
- Koan/Cobbler to allow remote provisioning. Profiles could be created for sundry machine configurations that would lay down a working machine.
- Customized LiveCDs or recovery DVDs. This shouldn't be too hard with the Fedora tooling and fits quite well with Koan/Cobbler.
- Another interesting use case for a live CD would be to have an automated method to back up their data before wiping everything and starting over. In the post installation their data could be restored.
The second challenge: Usability
Subscribe to:
Posts (Atom)
