I love the FireFox plugin It’s All Text – it lets me edit wiki pages, webmail, etc. in my beloved editor of Emacs and automatically refreshes the text field in FF with my new text. But I recently moved from using NTEmacs to Cygwin’s version, and things simply stopped working. And it made sense — Cygwin is just a layer on top of Windows, but it uses Unix-like paths, while It’s All Text would, naturally, use Windows-style paths.
I put up with this for a few months, mostly because I didn’t want to spend the cycles on figuring this out. I did spend a few, and they were all pretty much worthless. I’m not sure why — the idea wasn’t hard, but it seemed to be.
A while back I decided to put some dedicated cycles to this. I found this comment from the It’s All Text developer on his blog — it didn’t work , but it was a start. I took his work and built my own version. I was trying to do it with a one-script solution but seeing his I knew I needed two: one batch file and then one shell script. After some experimenting,
The following batch script should be left alone. It sets up the Cygwin environment, and then uses Cygwin’s “run” command to start a bash shell, when then runs our shell script. The “%~f1″ is actually the most important component here. It is a batch file command that says to give the full path of the first argument. Of course, that assumes that the first argument is a file but considering we are using this with It’s All Text, we are safe with that assumption.
@echo off SET DISPLAY=127.0.0.1:0.0 SET CYGWIN_ROOT=c:\cygwin SET RUN=%CYGWIN_ROOT%\bin\run -p /usr/X11R6/bin SET PATH=.;%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%PATH% SET XAPPLRESDIR=/usr/X11R6/lib/X11/app-defaults SET XCMSDB=/usr/X11R6/lib/X11/Xcms.txt SET XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB SET XNLSPATH=/usr/X11R6/lib/X11/locale rem the %~f1 is the full path name of the argument given to the script. %CYGWIN_ROOT%/bin/run.exe c:/cygwin/bin/bash.exe /cygdrive/h/bin/text.sh %~f1
The following is our shell script, which we referenced as “text.sh” above. It’s much simpler — it converts the Windows path it was given to a Unix path and then calls our editor (“emacsclient” in my case, which will load up the file in the current Emacs instance). You maybe thinking that I could have just was well as done this in the batch file above — and, you are right, I could have ran the editor but I had to also convert the file’s path first. That is really why we need two scripts — using a shell script is the only way I could find that would let me use the cygpath command in a reliable way. Note that I used “$*” at the path name — that will give all the arguments, which I need because there are spaces in the full path name (“$~f1″ above).
#!/bin/sh /usr/bin/emacsclient "`cygpath "$*"`"
So not easy, but it’s possible. Of course, I made it a lot easier now for everyone else!
Gina was busy on Saturday morning and Leah requested that we do something “fun”. It was cold outside, and we have a six-month old foster son, so the zoo was out. Leah also suggested (OK, begged) for the Children’s Museum, which would have been fine but it cost money and, frankly, I’m cheap. But I knew that our local art museum was free on Saturday mornings (10am-noon) but I thought, “What do they have for a six-year old at an art museum?” So I did some research.
We kinda walked around the special exhibits and saw some interesting things. But Leah wanted to make her own. Leah sat at the Can Do Art display, where they have paper, crayons, colored pencils, etc. Even a few games! If you know Leah very well, you know that she loves that kind of stuff. A grandfather was there with two grandkids and he started making paper airplanes. That meant we made some too.
After that, we went to the Cafe and had a little snack. Then Leah asked for something that I casually mentioned to her. I read it off the website but really didn’t know what it was. So we went and got an Art Pack and got going.
We did the “Go West!” pack. The best way to describe it is a scavenger hunt or a geocache in the museum. They gave us a backpack and it had a journal with directions, and a compass. The journal told us where to start and then gave us directions of “Walk 6 paces North then turn East . . .” until we eventually got to a painting. We read about the painting, and then reached in the backpack and got an activity out there to do (make a journal, play a bingo game, etc.) And we had a blast with it! And, while we didn’t see a lot of different art on this activity, we actually learned a lot about the pieces that we saw — and isn’t that the point.
Leah is excited to do it again and I am as well. We need to take Gina next time. And how did our foster son do? I had to feed him during our stop at the Can do Art display, and then he slept until waaay after we left.
This post is really just a rehash of my internal email response to my co-workers on this article on Dependency Injection by Robert “Uncle Bob” Martin. I like Uncle Bob — a lot. Just reading a couple chapters from his book Clean Code changed the way I think about programming. It had an immediate effect on how I think about code and making a stance on leaving it a little better than I found it. This also means that I know how Uncle Bob thinks, to a certain extent. And I know that Uncle Bob has strong opinions. And now I know he has strong opinions about dependency injection — or, rather, dependency injection frameworks.
I think what he’s saying in a round-about way is that the dependency injection framework should not be a deep dependency in our code. I agree with it in theory, but it’s not necessarily great in practice.
Sort of like the log4j example in Clean Code, Uncle Bob thinks it is good to hide the fact that we are using a library into the inner bowels of the project. In the log4j example, Uncle Bob makes his own wrapper around the log4j calls and uses his wrapper instead of calling log4j in his code. His idea is that, if they decide to change logging mechanisms, they just have to change one class. I think “why not just use commons-logging, since that is what is was designed for?”
Anyway, I think a Dependency Injection framework is much harder to abstract because your main method has to know about it just to get the container up and going. This is what he is saying here: “I can’t abstract this stuff out, so it dirties up my code. I don’t like it!!” I’m not sure like it either but it’s a cost thing. If you decide to do dependency injection, then you have a hard dependency on that library. Sort of a contradiction in terms, certainly, but then you only have one hard dependency and the framework should take care of the rest.
Of course, Uncle Bob doesn’t seem to talk about cost — for him, it’s black and white. For me, I figure you have to know what you are getting into before you start down this road. This is a good example of “What if I decide to use a Dependency Injection Framework? What are the costs?”. His post is a good example of what those costs are. In that light, it can been read like Ted Neward’s infamous The Vietnam of Computer Science. It’s OK to choose a framework for dependency injection, just know what you are getting into before you start and be ready to suffer some pain down the road.
I’m a happy user of zsh for a few years now and, while I don’t know all the subtleties of it, I find it a indispensable tool. People I know and respect keep asking me “Why not bash?” One of the big reasons is zsh’s completion system.
Bash has a add-on version of this, called bash-completion, and I used that before moving over to zsh full-time. Bash-completion feels, well, added on and slow and not always working. Zsh’s completion, however, keeps surprising me on how much it does do. As they say, a picture is worth a thousand words.
The above screenshot came with no configuration — I didn’t have to tell zsh about Django because, well, someone already did. And I’m glad for it.
It’s not just for Django, either. See what happened when I did “./configure <TAB>” in PHP’s source tree:
So note that zsh helps me figure out the right options. What I want to know the exact options for MySQL?
Again, none of this stuff had to be configured — I just told zsh I wanted completion and it gave it to me. I didn’t have to tell it that this was a configure script — it knew that! Just like it knew about the Django script.
This is just a taste. I hope you bite into zsh for more goodness.
Anyone who knows me well knows that I’m not a neat-freak. If you know me well enough, you know that I can be an out-right slob. My wife has tried to train me in other ways, and it’s sorta worked. But I still leave things laying around that need to be dealt with — including things that should go straight to the trash.
I’m that way with files on my computers as well. I let files sit around long after I need them and then, surprise!, I have a problem with hard drive space. I end up having to scramble to find files to delete, and end up finding ISO images and tarballs of forgotten installs that I could have delete months, sometimes years go.
After my clean install of Snow Leopard, I vowed I would be better at cleaning up after myself. I would delete files that I know longer needed, remove those MP3 files after I import them into iTunes, and empty my Trash periodicially. But, really, who am I fooling? I’m not going to do daily or weekly sweeps of my hard drive seeing these things. That’s where Hazel stepped into my life and made things much easier.
Hazel cleans up after you. Essentially, you tell it where to look, what to look for, and what do to. Want to import MP3 files automatically into iTunes? It will do that. Want to delete files that were downloaded more than a week ago? It will do that. Delete the Trash every month? Yep. Oh, and if the Trash bin gets large, it will delete it automatically — but only if you tell it to. What if you want to do something weird with the file? Well, you can write an AppleScript or a shell script to handle that. And you tell it all this in a nice, mostly-intutive GUI. (Click on the Screenshots link on the main Hazel page for an idea.)
And added bonus is that it can delete application files when you delete the application. What’s that? You thought OSX did that for you when you moved an app from the Application folder to the Trash? Well, look in your user’s Library->Preferences or Library->Application Support folder. Yeah, you see a lot of folders there for applications you no longer have installed. If you had Hazel installed, it would see that you have moved an Application to the Trash and it will ask you if you want to delete the user-level files as well.
I think Hazel is an application that every Mac owner should have. So, really, at least try it out. Now. Go. It’s worth far more than it’s $21.95 price tag.