Ok… I’ll Jump on the Daily Lit Bandwagon

August 13, 2007 · by Scott Fradkin

If it’s good enough for Wil (http://wilwheaton.typepad.com/wwdnbackup/2007/08/the-coolest-thi.html) and Cory (http://www.boingboing.net/2007/08/13/dailylits_library_of.html) then it’s good enough for me.

DailyLit (http://www.dailylit.com/) is actually pretty slick.  They send you snippets of books that are in the public domain or Creative Commons licensed.  These snippets are sized to take about 5 minutes to read and can be sent to you on a regular (or slightly irregular) schedule.  If you choose you can read over an RSS feed instead.

While I have yet to try it out, this certainly seems pretty darn cool.  They don’t have an enormous selection of books yet, I can only assume that they will.  They should be able to take the entire Project Gutenberg (http://www.gutenberg.org/wiki/Main_Page) library and put it on their website.

I’m still a big fan of the printed word, though.  There’s just something about having the hard copy of a text in front of you.

Now if only someone rigged this up but with audio books…

Filed in: Developer Blog Comments (0)

The Latest New/Old Language: Erlang

July 31, 2007 · by Scott Fradkin

I was poking around the interweb for some interesting technical books to purchase.  I decided to head on over to the Pragmatic Programmers website because I’ve purchased their books in the past and have, in general, been quite happy with the books they put out.  One of the most recent books they’ve released is called “Programming Erlang: Software for a Concurrent World” (http://www.pragmaticprogrammer.com/titles/jaerlang/index.html).  I was intrigued, so I bought the book.

It came in the mail the other day and I started to read it.  I’m not that far into it, but a few things really strike me about the language.

• It’s been around for awhile.  The Wikipedia entry (http://en.wikipedia.org/wiki/Erlang_%28programming_language%29) indicates that it first appeared in 1987 and was created at Ericsson, the cell phone company.
• It’s designed for concurrent, highly parallel, and fault-tolerant systems.
• Syntactically, it feels somewhat like Ruby and Scheme (or Lisp).
• It’s a functional language.  It feels more purely functional than Ruby does.
• Arbitrary length integers.  Ahh… finally, no need to worry about overflows!
• Variables are single-assignment.  You cannot change the value of a “variable” once it has been assigned a value.
• The equals operator (=) is NOT an assignment operator.  It’s a pattern matching operator.  But, when used with a variable that has not been assigned a value, the value gets assigned.  This one got a “Whoa” (insert Keanu Reeves here) from me.

I really think that I’m starting to enjoy dynamically typed, functional languages.  It’s quite a departure from standard object-oriented imperative programming.  It’s really interesting to not have to deal with objects all the time and to work with the elegance that functional programming brings to the table.

The little devil on my shoulder that likes to keep me programming in Java keeps asking me “But what is it good for?” to every new and old language that I encounter.  It’s a question that I like to keep in mind when evaluating different languages.

I can’t answer that question about Erlang yet.  I’m not that far into the book.  But, it’s definitely an interesting language.

Filed in: Developer Blog Comments (0)languages

Linux on the Desktop is not a Failure

July 24, 2007 · by Scott Fradkin

Sometimes it’s much more interesting to just read the comments on Slashdot rather than the articles. Today is an article titled “Why Linux Has Failed on the Desktop” (http://linux.slashdot.org/article.pl?sid=07/07/24/1432245&from=rss). The comments are quite interesting.

Personally, I don’t feel that Linux has failed on the desktop. I think it’s just fine. There were all kinds of comments about the actual article about how the kernel is really built for servers which value high throughput over low latency, about how the desktop UI just isn’t responsive, how it can be a pain to configure devices, etc. These are all great points. But, I don’t believe that any of these things point to the failure of Linux as a viable desktop OS.

Part of the problem stems from the open source approach of Linux. The kernel itself is open source and most applications people use are open source. Because of this, there tends to be a do-it-yourself viewpoint of using Linux as a desktop OS. If you use Linux, you pretty much need to know it inside and out. Can there really be an easy to use version of Linux that performs and has the ease of use that other operating systems have? I’m not certain.

One of the unusual things about running Linux is that a distribution is just a bunch of different applications cobbled together in a semi-coherent manner using whatever packaging and distribution system the distribution creators decided to use. When you use something like MacOS or Windows, the vendor locks you into one specific desktop UI and their suite of programs.

I’ve used large Linux distributions in the past and got really turned off by them.  Sure, they seem simpler and easier to use because they have all kinds of nice GUI programs with them, but they all turned out to be awful for me. Eventually they got all kinds of application crud on them that performed poorly and caused crashing issues. That’s why I turned to a distribution like Gentoo. Gentoo gives me the flexibility to install whatever I want, compile my kernel however I want, use whatever desktop UI I want. All of this adds up to machines that run fantastic.

I purposely compile my kernel to be low latency (it’s a configuration choice). I use a very minimal desktop UI (Fluxbox, I think it’s something like 4 MB in memory). The other Windows-esque UIs (KDE, Gnome) tend to be memory hogs and really heavyweight (much like another suite of operating systems from a company whose name starts with ‘M’ and ends with ‘T’). I have a 2 Ghz AMD box with 256 MB of RAM that Gentoo runs great on. Sure, loading apps is a bit slow, but once programs are up I have absolutely no problems speed-wise. Firefox runs fast, Eclipse runs fast, even running Win2K in Vmware runs faster than Win2K on a similar machine in my house where it’s the installed OS.

So, my feeling is that Linux is definitely NOT a failure on the desktop. Will Linux ever gain the kind of popularity that Windows or Mac have? Probably not. Maybe that’s OK, though. I’m fine with being one of a small minority of users that actually use Linux as their primary OS. I’m fine with dealing with the issues that come with being a Linux user. It’s not for everyone, that’s for sure, but I’m hoping to convince others that it’s OK to make the switch.

Filed in: Developer Blog Comments (0)linux

Long Term Data Storage

July 11, 2007 · by Scott Fradkin

I ran across a thread on Slashdot (http://science.slashdot.org/article.pl?sid=07/07/11/217218&from=rss) about the collection of glass photographic plates that is stored at the observatory at Harvard. It’s apparently about 25 percent worth of all the world’s currently existing photographic plates. There are over half a million of them covering the sky of both hemispheres with images from the past century. Definitely sounds like some very important history is stored in these photos, and they’re considering digitizing them for long term storage.

The problem is how to store the data for the long term. I don’t know about the best way to store glass photographic plates, but I’m not certain that anyone has come up with viable long term digital storage. It’s estimated that the total amount of data contained within these photos is a petabyte. That’s an enormous amount of data even by today’s standards. 1000 gigabytes is a terabyte. 1000 terabytes is a petabyte. There is a fascinating article at Wikipedia (http://en.wikipedia.org/wiki/Petabyte) about the petabyte.

I can certainly picture vast arrays of hard drives or stacks of optical discs, but for long term storage? Hard drives are prone to failure (although I do seem to have some ancient drives that still do the job), and today’s optical discs degrade in merely a few years. So what can we do to store information that is historical in nature? Hard copy? Back up data onto fresh devices every few years? I don’t have the answer. Hopefully someday someone will come up with the answer so we don’t lose things like books from the beginning of printing and these photos of the night sky.

Filed in: Developer Blog Comments (0)

Code Analysis with JavaNCSS

July 2, 2007 · by Scott Fradkin

One of the things that I’ve been getting into lately is the usage of various code analysis tools as part of a standard build. There are numerous tools that can be very helpful when used as part of a continuous integration process.

One of the most common static analysis tools is JavaNCSS. It’s a simple tool and it doesn’t do all that much, but I think that it can be beneficial to use.

You point JavaNCSS to your source files and it will output the number of NCSS (Non-Commenting Source Statements) per package, class, and function. Just for kicks, it also calculates the CCN (Cyclomatic Complexity Number) for each function and displays the number of Javadoc comments per package, class, and function. Some of this may seem a bit useless and even pointless, but I think that there’s value to all the information that it calculates.

Most people would look at the number of lines of code and say “whoop-dee-doo!”. Yeah, it is kind of hokey. “Look! I coded 1000 lines today! Bonus time!” Seriously, though. The number of lines of code probably makes more sense to track at the function and class level. If the number of lines of code for a function is large or has been increasing over time, there might be an opportunity to take another look at that code to determine if extra functionality is creeping into the function that shouldn’t be there. If the number of lines of code in a class seems large, then perhaps the class has functionality inside of it that would be better in a different class.

The CCN can be used similarly. The CCN (aka, the McCabe Metric, http://en.wikipedia.org/wiki/Cyclomatic_complexity) is a number that describes the complexity of the code. There’s a whole complex discussion about it on the Wikipedia entry, but basically it’s a measure of how much branching there is in the code. If the number is low, then the code is very straightforward and does not have many decision points. If the number is high, then there are a lot of decision points (if/then/else statements, loops, switch statements, etc.). Generally, if the number is high for a method it could possibly be a candidate for refactoring. Take a look at the method to see if the decision points can be compressed together, or if some of the branching is unnecessary, or if the method could be logically split up into other reusable methods. Many times, however, despite a large CCN there is a reason the method is written how it’s written and that’s ok.

Lastly, I actually like the Javadoc counter. Looking at the counts per function makes it really easy to spot which functions are lacking documentation.

JavaNCSS is a nice little tool to help out with some basic static code analysis. It can be found here: http://www.kclee.de/clemens/java/javancss/

Filed in: Developer Blog Comments (0)java

Hello World

June 1, 2007 · by Scott Fradkin

Because I like to do strange things sometimes I thought it would be fun to start a Hello World archive.  As I get interested in checking out other languages, writing a Hello World program is the first and easiest thing to program.  I figured that archiving all the programs would be a nice thing to do as a point of reference.

I may expand the archive to include more advanced programs for comparison, but for now Hello World is a good start.

Feel free to check it out at http://tech.fradkin.com/helloworld/index.html.

Filed in: Developer Blog Comments (0)languages

Factorial Fun

May 28, 2007 · by Scott Fradkin

I just got back from Narglethorpe; at least I’m pretty sure it wasn’t a dream. One of the most spectacular animals on the island is called “The Beast of Narglethorpe” or TBON. Now, local legend has it that TBON has some interesting properties. If a person were to come upon this ferocious beast and call out a number, the beast will undergo a miraculous transformation in which it splits up into numerous other (albeit smaller) TBONs based on the number called out. Facing the possibility of being eaten by the beast, I decided that there was scientific merit in trying to verify the legend. So, armed with a machete, some camouflage, and a camera, I wandered into the jungles of Narglethorpe. The foliage was so dense that it was quite dark, but this did not deter me in the slightest. I went further and further into the jungle hoping to catch a glimmer of this monster. After a bit I heard a noise to my left. I turned, but saw nothing. I went on. Soon, I came to a clearing. I got to the middle of the clearing when I felt as if I were being watched. I turned around slowly and I saw that most amazing sight Ii had ever seen! Before me was the magnificent TBON!

Ten feet tall! Giant floppy ears! A cute puffball of a tail!

Terror inched across my body. I was paralyzed with fear. Until I remembered… “One!”, I managed to blurt out. Nothing happened. I thought for sure I was a goner. “Two!”, I shouted. The fearsome TBON split into two identical TBONs before my eyes. Identical beings, but each half the size of the original. Within a few seconds the two turned back into one.

Its eyes gleamed with hunger. Not undaunted, I cried, “Three!”. This time six smaller copies sprang forth. I was beginning to have an inkling as to what was going on. After some time, but longer than before, the six turned back into one. I quickly called out “Four!” Lo and behold, 24 copies appeared. I was quite excited and was ready to make things interesting. I quickly wrote down the following:

public class Factorial {
    public static void main(String[] args) {
        System.out.println(fact(new Integer(args[0]).intValue());
     }

    public static int fact(int factnum) {
        switch(factnum) {
            case 0:
                return 1;

            default:
                return factnum * fact(factnum " 1);
        }
    }
 }

Nice and easy recursion. Something about this seems a bit pedestrian, however. What if we tried this a different way?

if ARGV[0].to_i == 0
  puts "1"
 else
  puts((1..ARGV[0].to_i).inject(1) {|total, num| total * num})
 end

Nice and concise.

Another just for kicks:

(begin
  (define fact
    (lambda (n)
      (if (= n 0)
        1<br>
      (* n (fact (- n 1))))))
 (display (fact (string-&gt;number (vector-ref argv 0))))
 (newline))

Ahh… Very helpful. Three different ways to calculate a factorial in three different languages.

I figured that I didn’t have to go past the number five. Any more than that and I would not be able to see the TBONs that split. So I called out “Five!”. As the TBON split into 120 identical (much) smaller TBONs, I broke out into a huge grin. I thought, “This TBON isn’t too scary.” I pet a couple of the TBON clones. After a few minutes, the TBON reassembled itself into the regular, giant TBON. It glared at me again. I became afraid once more.

“Hey!”, said a voice behind me. I did a little jump and turned around slowly. A man stood behind me.

“He really won’t hurt you, you know.”, the man said.

“Oh, really?”, I answered. “He looks quite angry to me.”

“Nah, he’s harmless. I’ve lived here all my life and the Beast has never harmed a soul. He’s looking at you like that because of what you’ve got in your pocket.”

“My pocket?” Oh, how embarrassed I was.

I grinned again, reached into my pocket and pulled out the carrot and tossed to the TBON. The TBON caught the carrot, wiggled its nose, then bounced off back into the jungle. I turned around said thanks to the local and decided it was time to head home.

Authors note: The code samples in this post are all executable. The first is in Java, the second is in Ruby, and the third is in Scheme. They are setup to take a command line argument of the factorial to compute. Save the Java example to a file called factorial.java, compile it using "javac factorial.java" and execute it using "java Factorial n" where 'n' is the factorial to compute. Save the Ruby example to a file and run it using "ruby file.rb n". The Scheme example should be saved to a file and run using (I use MzScheme) "mzscheme -r file.scm n".

Filed in: Developer Blog Comments (0)languages