September 10, 2009
For those interested in Clojure programming (and yes Thomas, I know that’s not you :)), I have posted an entry on the blog of the Danish Clojure Users Group:
April 16, 2009
Finally solved an issue has been driving me crazy for weeks! If I can help one other poor soul out there with this writeup, it’ll be worth it. Even if not, I need this entry to make sure I never forget how to fix this problem.
At work, I’m running Ubuntu 8.10 on my workstation. I also have an XP VM running most of the time, so when I need to do Windows work, I can just RDP into it.
I’m using rdesktop as my RDP client, and it is working great, mostly. Very lightweight and fast. So when running it in fullscreen mode, the user experience is pretty much as if I had XP running locally.
Except…there was one small but extraordinarily annoying issue.
Sometimes, after pressing the left Alt and Shift keys simultaneously, the keyboard would get into some state where it acted as if the left Windows key was depressed. The effect was that subsequent keypresses would pop up windows with dogs in them (“f”), Explorer windows (“e”) or similar. It would stay this way until I actually pressed the Windows key to somehow reset it.
It turns out that when the Alt key is depressed before the Shift key, an ALT_L window event (or whatever it’s called, I don’t even want to know) is generated for the Alt key.
But when the Shift key is depressed before the Alt key, a META_L event was generated instead!! How lame is that?!?
So this was what tripped rdesktop, and it was really a bitch to find. It seemed to pop up randomly, the randomness being caused by whichever key I happened to strike first…
Almost forgot to mention the trick I found to fix the issue. Simply put this in your .profile:
xmodmap -e "remove mod1 = Meta_L"
This causes the left Alt key to always generate an ALT_L event. Problem solved.
Seems the above method didn’t quite cut it… I also needed to add this to “.profile”:
xmodmap -e "keycode 64 = Alt_L"
For some reason, I think this has become necessary since upgrading to 9.04…?
March 4, 2009
I’m posting this mostly so I’ll know where to look the next time I forget…
This is definitely the king of obscure Emacs key combinations. To change the encoding of an existing file, use C-x RET f <encoding> RET.
Tab-completion works for the encoding. “utf-8” is the one I use most often, but “unix” and “dos” are also useful.
To make Emacs open files in UTF-8 per default, use the following snippet in .emacs:
(setq locale-coding-system 'utf-8) (set-terminal-coding-system 'utf-8) (set-keyboard-coding-system 'utf-8) (set-selection-coding-system 'utf-8) (prefer-coding-system 'utf-8)
December 14, 2008
A colleague of mine recently introduced me to Project Euler, and I am slowly becoming hooked.
Project Euler is a collection of mathematical challenges that usually require some programming to be solved. Some are relatively simple (eg. “Find the 10001st prime”) while others are complex (“Using up to one million tiles how many different “hollow” square laminae can be formed?”).
Since I did not study mathematics, most of these problems seem intimidating to me at first. However, a lot of them can be solved with programming skills, simply by doing a more or less brute force search for the answer.
Solving the problems in order, they become progressively harder. But the beauty of it is that a problem often builds on the skills acquired while working on a previous problem.
So if you’re a programmer and you like puzzles involving maths, I highly recommend that you check it out. You can use any programming language you like, only the answer matters, always expressed as some big number.
October 27, 2008
This weekend, I was at the first Danish Rails Camp near Svendborg.
(Photo by wa7son)
The camp was Fri-Sun (unfortunately I could only attend Sat-Sun), and we ended up being 12 attendees. A little less than we had hoped for, but this also meant that we could all fit comfortably in the living room of the cabin.
Saturday afternoon, many of us went for a run in the beautiful countryside. This was an excellent way to kickstart the brain and kill the legs, grounding us for a serious round of hacking.
Thomas took some very good pictures. Not from the run, thankfully.
It’s always nice to meet new people and learn new stuff, and it was especially great to hear more about the Ruby and Rails work that people do professionally in Denmark. The landscape seems to have changed a lot since I last considered a Rails career about a year ago. It seems that both dynamic languages and opinionated frameworks are still gaining ground, even in conservative Denmark (with Rails still leading the crowd). Great news!
All in all, it was a great trip. That being said, I think we should consider how we can make the camp even better next year.
For some reason, software developers have an ability to sit for hour after hour, totally absorbed in whatever they’re working on. I am certaintly no exception.
And there’s nothing wrong with that. On the contrary, that is how we learn new stuff.
But we can do that at home, each and every day if we want to. Many of us probably do, more days than not. When we go through the trouble of renting a cabin in the middle of nowhere, we should really make the most of the time we have together.
I definitely learned new stuff at the camp, but I’m sure I could have learned much, much more.
Stop bitching and get to the point
I have been thinking of a few ideas for improving the learning-from-each-other part next year:
We should prepare a stack of small assignments in advance. Just very simple tasks that take no more than 2-6 hours to complete.
A few examples:
- Create a simple battleships game (Laust and Jakob, that was a great idea).
- Create a super-simple Wiki server using Sinatra and CouchDB.
- Review and compare a few search libs (eg. Ferret, Sphinx) with regards to features and performance. A suitable dataset is provided with the assignment.
- Design an internal DSL for creating SQL queries.
- Compose the ultimate Ruby blogroll, briefly describing each entry.
The assignments should generally touch on something that most attendees find slightly exotic (eg. CouchDB, Haml, Shoooes), but not completely alien or Ruby-less (eg. Fortress, Emacs Lisp).
They should be solved in groups of 2 or 3, preferably consisting of people who don’t know each other in advance.
Personally, I know that having a concrete goal would help me maintain a sense of direction. So would splitting the days into chunks.
A laptop will consume any amount of time you throw at it. In my experience, this often happens because software development is inherently both interesting and complex. When working on anything non-trivial, you’re bound to go of on a tangent every now and then.
Again, this is perfectly normal, and it is an important part of how geeks work and learn. But it is not social, and the guy next to me learns nothing from it.
Given hard deadines for all assignments, we would all be forced to stay focused for a few hours, share our gained knowledge, then refocus.
Each assignment should result in a demo or some other kind of presentation.
Briefly presenting the work done should be mandatory. If everything failed, it’s no big deal. Just tell us why, and we might avoid some pitfalls in the future. Anyway, only a few hours were lost.
The big picture
What I’m suggesting here is that we aim for a more conference-like atmosphere on next year’s Rails Camp.
I think the great thing about conferences is the feeling of enthusiasm they imbue. A good conference should leave you with:
- Lots of half-baked ideas
- A handful of email addresses and half-ass business proposals
- A craving for more knowledge about a dozen new frameworks and several new languages
- Vague thoughts about possible career moves
Conferences should inspire, not teach. I think the Rails Camps could provide the perfect small scale setting for achieving the same goal, if that is what we want.
Your comments, please
Obviously, you’re all very welcome to share your thoughts on this. Do you agree, or am I way off?
Drop me a comment and let me know what you think.
By the way
Francesco, I hope you had (or will have) a nice trip back to Florence. I still can’t believe you came all the way to Denmark to attend…! But I’m glad you did, it was nice talking to you.
October 21, 2008
I had been blogging on blogger.com for a while, but the last few months, I have been increasingly annoyed with the service. Little things, mostly, like the way the editor works and how the Preview mode is very far from the appearance of the published entry.
However, the main reason for the switch was the fact that I simply could not get Emacs support working. g-client took me some of the way, but it wasn’t nearly good enough in its current state.
Just one example: To create a new blog entry, I needed to specify a “post URL”. And to obtain that, I needed to invoke some method (forgot the name) which created a temporary webpage on my harddisk and launched Safari to show it to me! On that webpage, I could then see an overview of the blogs I had on Blogger (a list with 1 element), copy the link to the “post URL” of the blog and paste it back into Emacs.
Also, to save my new entry as a draft, I had to modify the template used for new entries to include some XML snippet that I had to look up in the Google API. And after saving or publishing an entry, the buffer was completely garbled for some reason.
OK, that was a few more examples 😉
I’m not sure if it was just me who completely misunderstood how to use this library, but it seemed extremely rough around the edges.
As I have described in another entry, blogging from Emacs works beautifully with WordPress. And Emacs is where I want to spend my time, also when blogging. I like it here, it’s comfy.
Actually, I was planning on doing a thorough comparison between Blogger and WordPress, but I have realized that this would be pointless, because hundreds of others have done just that. So just google for it if you’re considering which to choose.
October 20, 2008
After switching to WordPress, I can now post entries from Emacs, thanks to weblogger.el.
Note that there seems to be several “weblogger mode” packages for Emacs. Follow the link above to see how I got it working.
weblogger.el had a few problems, most of which were fixed by ciju. Thanks for that! However, it did require a few additional hacks to get it working in the way I wanted to.
Below is the diff between ciju’s version and mine.
2a3,6 > ;; NOTE: Modified by ciju as described here: > ;; http://ciju.wordpress.com/2008/06/06/twiddling-with-webloggerel-emacs-wordpress/ > ;; Also, further hacking by Chopmo > 584c588,589 ; (list "Subject" title) ; fixed by chopmo > (list "Subject" (or title"\n")) 938,939c943,945 < (if (buffer-modified-p) ;; modified by ciju, disabled by chopmo > ;; (if (buffer-modified-p) > ;; (weblogger-prepare-and-send nil nil)) ;; ciju's modification
You can also download the patched weblogger.el here.
The diff above tweaks the weblogger feature in two ways:
- Fixes a small bug which caused the newline after “Subject:” to be missing when starting a new entry.
- Reverts a change made by ciju which caused the current entry to be saved as a draft when navigating to the next (with C-c C-n) or the previous (with C-c C-p) entry.
The second change means that published entries stay published and that navigation between entries is very fast, but also that you need to actively save a modified entry before leaving it. This is done with C-c C-s to save it as published or C-c C-c to save it as draft.
Both commands simply overwrite the previous published/draft state of the entry, so there’s not explicit “publish” step. You just save the entry as published. Also, both commands can be used for initially saving the entry.
Another small tip: Note that after initially saving an entry, the URL to the entry is displayed in the header:
As long as you’re logged into your WordPress account, you can use this URL to see a preview of the entry as you work on it. The preview is updated as soon as you save the entry in Emacs.