A programming blog covering C/C++, Java, Perl, PHP, Python, Ruby, Ruby on Rails, and UNIX/Linux shell scripting.
I have been watching the Berkeley Webcasts of Brian Harvey's CS61A lectures and I wanted to run the same version of Scheme that he is using in his class. I got it running, and I thought I'd share how to get it working if you already have Cygwin installed on your Windows system.
To that end, I made some notes on how to intall the University of California Berkeley's distribution of Scheme, UCB-STk on Cygwin, which runs in Emacs. The short of it is that you simply need to extract the STk packages from the UCB Cygwin distribution. The STk download is somewhat misleadingly labeled. It presents itself as the STk installer, when in fact it is an entire set of Cygwin packages. Once I did this, I was rockin' along with Brian as he argues but first of sentence....
Labels: education, emacs, ide, lang:scheme, programming, software
7/23/2008 01:26:00 AM | Installing UCB-STk on Cygwin
I recently stumbled upon some sample videos from "Ruby on Rails Essential Training at Lynda.com.
Ruby on Rails has enjoyed really huge buzz all over the Web the past few years, but I've never really looked what that buzz was about--at what it is and what it offers. If you don't know already, Ruby on Rails is essentially a web development framework based on the Ruby programming language.
I highly suggest that anyone involved in web development at least check out what Ruby on Rails has to offer. There are a number of excellent screencasts of Ruby on Rails in action at the Ruby on Rails site, particularly "Creating a weblog in 15 minutes."
Labels: introduction, lang:ruby, programming, ruby, rubyonrails
8/12/2007 04:47:00 AM | An Introduction to Ruby on Rails
"Some might argue that this test is unfair to the backtracking implementations, since it focuses on an uncommon corner case. This argument misses the point: given a choice between an implementation with a predictable, consistent, fast running time on all inputs or one that usually runs quickly but can take years of CPU time (or more) on some inputs, the decision should be easy."Russ Cox
This paper by Russ Cox is a very interesting discussion of efficiencies in regular expression matching.
(Vim has joined Google Summer of Code 2007, and one project idea is to increase the efficiency of Vim's syntax highlighting and regular expression matching.)
Labels: google, lang:c, lang:perl, programming, regex, summer-of-code
3/18/2007 12:46:00 PM | Regular Expression Matching Can Be Simple And Fast
I am currently taking a Statistics class—a subject I was not at all thrilled to have to study. Typically, when I have to take a class that I don't enjoy, I force myself to find some personally applicable good in it so that I not only perform better in the class, but in order that I find the value in the subject. I told myself that Statistics is a subject heavily applicable to Computer Science and that I should look for ways that I could apply the general concepts I am learning to specific problems in Computer Science. So, over the past six weeks I have attempted to look for those things, I am surprised (though I shouldn't be) to find just how many times I find myself stumbling over Statistics in computing without even looking.
I happened upon this Google Tech Talk today and I ended up watching all 50 minutes of it. Two students from UC Santa Barbara give a presentation on a project they have begun to statistically measure programmer productivity—specifically in MPI and UPC, programming languages used in HPCS.
While the presenters, Viral Shah and Vikram Aggarwal, admit that the project is still a nascent effort, they were eliciting the suggestions of those attending in the hopes of building a "better mouse trap" and perhaps writing some tools that could be used for statistical analysis of programmers elsewhere, using additional programming languages.
And indeed, there were a number good points addressed. One listener addressed the questions asked of programming students in the study. This lead to interesting ideas regarding the comparison of how a programmer perceives their productivity versus how productive the statistical data shows them to be.
There are a number of fascinating issues related to this idea of programmer productivity, not the least of which is the age old debate of which programming languages are more efficient than others for human productivity or for computing productivity. I hope to see more on topic this in the future.
Labels: google, hpc, productivity, programming, statistics
2/18/2007 02:16:00 PM | Measuring Programmer Productivity
I've always been interested in what it takes to work at Google, specifically as a programmer. So I decide to do a little research to see just what Google is looking for in a Software Engineer. Below is a Google Spreadsheet containing a list of search results from Google's Job Search engine.
I must preface all of this by saying that this is a very informal analysis. The precision of the information is subject to a number of factors including the scope of the search engine, the search terms themselves, and the time the searches were performed—to name a few. Search terms that yielded no results are not included.
What is interesting is the amount of Free Software included in this list. Searches for proprietary technologies yielded virtually no results, or results that did not apply to Engineering. If you were paying attention, you noticed that the URL for Google's Job Search is a "py" file. So even it is written in a free programming language (Python).
So if you plan on working for Google someday, well, there's your hit list. Stay in college—particularly a Software Engineering/Computer Science program—and learn to code programs that integrate with databases for POSIX systems.
Labels: google, programming, statistics
2/13/2007 07:28:00 AM | So you want to code for Google?
|
| Subscribe to treehead.net |
| Visit this group |