emacsen's journal
[Recent Entries][Archive][Friends][User Info]
Below are the 5 most recent journal entries recorded in the "emacsen" journal:
|
07:59 am
[Link] |
The API-enabled web and a better browser
All the cool hipsters have seen Ubiquity- the new Mozilla Labs project.
If you haven't seen the video, you should. The easiest way to explain Ubiquity seems to be that it's command line + firefox command functions + greasemonkey.
If you don't know, firefox can already do simple functions on the command line. You can type "google foo" into the address bar and it'll do a search for you.
Greasemonkey is one of the best tools a programmer can have on the web. I've used it for simple things like making certain web sites at work easier to use. If you spend a significant amount of time in other people's web applications, you may find Greasemonkey can save you some precious sanity points.
Ubiquity appears to take both concepts a step further by making the entire browser aware of itself, and able to not only modify single pages but work with APIs.
It all looked a bit flashy until I thought of a few examples of common tasks I deal with that could be made easier via a command line. For example, why either pull up Remember The Milk or (at home) use Tasque when "rem Return that book to Susan" would work just as well.
I briefly read the tutorial on making a new vocabulary and it seems relatively straightforward so long as the service APIs you're using are straightforward as well.
One hope I'd have is that something like this becomes standardized enough that local applications have APIs that work with it, or conversely that local applications would have a simple hook into the Ubiquity system that would allow them to share the data in both directions.
I'm leaving for a few days but I guess I'll need to throw Ubiquity on the pile of nifty new tools to look at.
Tags: programming, web
|
|
05:51 pm
[Link] |
End of Life for Pea
Then I started writing the Pea podcast aggregator, it was a very
different time. There were a total of four aggregator that ran on
GNU/Linux that I could find, and each of them was severely broken. At
the time I wrote down a page of features I'd want from a podcast
aggregator and wrote Pea 1.0. Soon after writing an early version of
Pea, I abandoned the use of SQLite and I wrote Pea 2. Pea 2 has been
in development for about 8 months, and the more I work on it, the less
I like it.
As of October 1st, I'll no longer be supporting Pea. Pea users (if
there are any other than myself) are recommended to move to
hpodder. The only feature that you may miss is some of the naming
templates I created (specifically the smart extensions). This is a
feature that I've discussed with hpodder's developer and with luck, we
should see in the next few months, along with trigger events.
So- that's it. No more pea. Long live hpodder.
Tags: computers, pea, programming
|
|
06:00 am
[Link] |
Python, I'm sorry but you cause me pain
My work on Pea has picked up again lately. My plan was to fix up the major bugs and make a release which I'd turn into a Debian package (learning both distutils and debhelper).
The major bugs I'd found have been largely addressed:
There was a bug where newly subscribed feeds had the podcast numbers in reverse. That's fixed.
There was a bug where some of the configuration options in the local file weren't overriding the defaults. That's fixed.
There was a bug where the temporary file names didn't match what I thought they should be. That's fixed.
But suddenly this week I started getting a very odd bug. Some of the podcasts casts weren't being moved from the temporary file location to the permanent one. The odd part was that it wasn't all podcasts not being moved, just some of them, making the problem hard to debug.
In hindsight, the right answer would have been to do an svn diff against old versions of the code until I found the bug, but since I hadn't touched the part of the code that handles downloading, that I was seeing a deep bug which was only being expressed now. In the end, I spent several hours looking at the various podcasts which were stored and trying to find a commonality, along with debugging the code.
I eventually found the problem. I must have accidentally indented a single line in the code.
From this:
if not isdir(dirname):
makedirs(dirname)
rename(tempfilename, filename)
cast['filename'] = filename
To this:
if not isdir(dirname):
makedirs(dirname)
rename(tempfilename, filename)
cast['filename'] = filename
Lessons learned:
1) Python's spacing is often problematic.
2) Don't assume bugs are deep
3) Use your version control diffs to find bugs, assume new bugs are new
Tags: computer, programming, python, rant
|
|
09:37 am
[Link] |
How tight is too tight: Coding in Lisp
I've been finally writing non-toy programs in Lisp. They're tiny, but they're still larger than the very simple examples you'd get in the beginning of a book.
One pattern that I've seen emerge is that my coding style has become a lot tighter, for good or ill.
Because Lisp has tight lexical scoping of variables. Each variable exists within the scope of its assignment block, and disappears afterwards. The result is that most Lisp functions are very clean, with variables disappearing after they're used (and then picked up by the garbage collector when the time comes).
The downside to this is that as a programmer, new variables must be declared within a scope, eg a let statement.
This brings us to a programming pattern that most variables are only used once. This is especially true in Lisp, which encourages small functions and uses the value of the stack as the default return value. Declaring a new variable requires using the let statement and creating a new level of code. Because of this inconvenience, I find myself not bothering.
The result is that code is "tighter" but that statements become longer.
I don't see this as a problem because I comment my code thoroughly but I was discussing this with a friend over lunch and he pointed out that on large projects, comments often become out of date as code changes.
For folks who work on Lisp on a large scale, do you see this dilemma?
Tags: computers, lisp, programming
|
|
07:25 am
[Link] |
Emacs on Rails
There's been talk lately about concepts like "Gnome On Rails". The
premise is that with Rails, you can create a web application in just a
few lines, and the hard work of the infrastructure is done for you,
where in a desktop application, the bar is a lot higher. I think
there's a great deal of merit there.
What's missing from the discussion is what Emacs does, and why Emacs
is still a superior system in many ways. It's often difficult to
explain that to non-Emacs users, especially because Emacs has its own
vocabulary. For the purposes of this discussion, let's say that all
major Emacs modes are applications.
( Read more... )
Tags: computers, emacs, programming
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
emacsen's journal