Friday, May 22, 2009

Google Gears for 64-bit Linux

While this isn't really news at this point, I figure spreading the word can't hurt. I use Gmail and several of the other Google applications (calendar, reader, docs, etc). Google has added offline support to a few of these apps via their Google Gears Firefox addon. This can be great news unless you are running 64-big linux. There is not an official release of Google Gears of 64-bit linux. There is, however, an unofficial and totally sweet build available [1]. The builder does a great job of staying up to date with the builds usually within a release or two of the official builds. If you travel or just like to handle email and such when offline, this can be a great help. Enjoy!

[1] http://tinyurl.com/gears64

Wednesday, May 20, 2009

Fun Wolfram Alpha Queries

I was just introduced to Wolfram Alpha earlier this week and am already enamored. Below are some interesting queries that were shown to me.

General Information
Standard Math
Physics
Air Flow
Imaging
Science
Language
Genealogy & Names
Salaries


For even crazier queries, take a look at Something Awful.

Tuesday, April 7, 2009

Rename a git remote branch

While my previous post does detail how to remove remote branches from your repo, I fear that it mistakenly sends you down that path as a means of renaming branches from a remote repo. Like most other functionality, if you think Git should already have it, it probably does.

To rename a remote repo to something else just use (following previous example):
git remote rename origin moe
Tada!

Sunday, April 5, 2009

Git rid of a remote branch

I keep having to look this up so I figured I'd blog it to save the Google search.

I sometimes clone repos from another git repo and from svn. This allows me to publish to both and do whatever I want locally. The default prefix for the first cloned git repo is "origin". As I sync more repos to my local repo, I like to rename the prefix to something more indicative of the branches origin.

To rename the prefix "origin" to "moe", start with something like this:
[remote "origin"]
url = moe:src/howler
fetch = +refs/heads/*:refs/remotes/origin/*

and change it to this:
[remote "moe"]
url = moe:src/howler
fetch = +refs/heads/*:refs/remotes/moe/*

After this, call "git fetch moe" to fetch the list of remote branches. The same approach can be taken to rename branches fetched from svn. The important thing to note is to look for the name to change after "remotes" in the config line. Adding something before "remotes" will do nothing for you.

The problem you're left with, however, is that if you fetched the remote branches before and after the change, you'll now have some branches that need pruning. To clean up all the now useless branch names, use a command like this:
git branch -a | grep '^ origin' | xargs git branch -rd

This should remove any remote branches that begin with 'origin'. If you delete the wrong remote branches, you can always get them back by fetching again.

Monday, March 16, 2009

JCR Properties and Mixins

The more I learn about JCR the more I realize I need to learn about JCR. Today's lesson: adding any property to an nt:file node.

In k2, we use nt:file as the node type for most everything we store especially anything stored by the user. There comes a time though when the node needs to have more characteristics than nt:file implies. This is where mixins come in handy. For more on mixins in general, read the 1st and 4th paragraphs of the wikipedia article.

We already have a mixin defined that allows a value be set to any property of a node (sakaijcr:properties-mix). Something to note here. I said a value to be set to any property. A. Why is this so important that I had to use 3 sentences to make my point? Because I spent several days trying to figure out why I couldn't save to a property I wanted to create even though the appropriate mixin had been added to the node.

A basic definition for allowing a value to be assigned to any property on a node looks like this:


<propertyDefinition name="*" requiredType="undefined"
    autoCreated="false" mandatory="false" onParentVersion="COPY"
    protected="false" multiple="false" />


See that multiple attribute there on the end? That tells if you will allow multiple values to be assigned to a property. This obviously does not allow multiple properties per the tell-tale "false" value.

More interestingly with this piece of configuration is that changing multiple to "true" disallows single values to be stored. I need to store either. What to do in such a quandary? Why, create another property definition, of course! Don't read it too fast or you may miss the subtle differences.


<propertyDefinition name="*" requiredType="undefined"
    autoCreated="false" mandatory="false" onParentVersion="COPY"
    protected="false" multiple="false" />
<propertyDefinition name="*" requiredType="undefined"
    autoCreated="false" mandatory="false" onParentVersion="COPY"
    protected="false" multiple="true" />


That's right. I changed the value of one attribute. This is how you can allow a property to have either a single value or multiple values. I feel a little dirty for duplicating so much for such a little change but the architects of JSR-170 felt it necessary to do so.

For those keeping count at home, I duplicated 153 characters between the 2 lines with the first having 1 more character than the second (158 vs. 157). If anyone knows a better way, I'm all ears.

Monday, March 2, 2009

Linux seen through different Windows

I'm a sucker for new features. I love to see new gadgets, widgets and UI updates but shy away from bells and whistles. After the shininess has dulled and the day-to-day functionality is what I'm left with, I tend to go with function & performance over form. For that, I tend to try a new window manager or desktop environment about every 6 months on my linux installations. I've just recently moved from LXDE to KDE (4.2) to Gnome (2.24.1). Here are my thoughts for what they're worth

LXDE

After a resource battle with an older version of Gnome, I decided I needed a slimmed down, more responsive window environment. I looked around but didn't want to go with something terribly barebone. Ratpoison is for crazy people but I wanted something a little more updated than Fluxbox. This led me to Openbox. After tinkering with it for a bit I found someone had created a nice little desktop environment based on Openbox called LXDE. This gave me a few nice little applications but was largely disconnected in that it only supplied the applications and didn't integrate them like the bigger desktop environments.

My usual six month trial went well and I generally enjoyed LXDE. It's very responsive, didn't feel buggy or missing features. This is not an environment for everyone though as it is pretty minimal but that is what I was looking for. I was never quite able to get startup scripts to take affect as I had in Openbox alone but that wasn't a big deal since I wanted only a couple and they were optional. All in all, LXDE was a good experience.

KDE

After hearing all the hoopla over KDE's big release of the 4.x series, I decided to finally give it a shot. Now, when I say hoopla, don't misconstrue this as all cheers or all jeers; the response was pretty mixed but overall positive even through Linux dumped it. The new menu options looked pretty nifty and some of the UI changes and methodologies were nice as well. My biggest problem with KDE 4.2 is its missing attention to details. Menus don't properly change text color when hovering which can make for unreadable menus when you have black text and a dark blue highlight. Another issue is the clunky feel and slowish response of the menus. There might be a setting for this but that's another lack in KDE of late: configurability. Basic things in a windowing environment should be quick and crisp but I didn't find this to be the case. I didn't even bother with the wacky effects so I think it is something more integral to KDE.

I was on KDE 4.2 for a month or two and decided to move to something else. Many of the things I have issue with are being addressed in 4.3 but I need usability today. I'm sure I'll keep updating my KDE libs as time goes on and switch back over to test usability now and then.Link

Gnome

A perennial favorite of mine. Gnome's focus on stability is very appealing to me while its rate of change in UI can be liked to that of watching paint dry but that keeps it very familiar. This is the desktop environment I'm in now and have been for only a day or two. So far the environment is very crisp, no funky loss in the details and even handles startup script failures very nicely which neither of the previous environments handled at all. Ubuntu has poured a good bit of effort into Gnome which keeps it advancing without losing stability. Some Ubuntu features have created more problems than helped (indexing) but those are usually easily disabled.

The big difference between roll your own setups and true desktop environments is the creature comforts they give you. LXDE is really just a gathering of applications while KDE and Gnome really try to greet you with nice things. Sound configuration, extra keyboard buttons detection, network manager and device detection are just some of the niceties you get with the big guys. Along with that comes system overhead but I just upgraded to 4GB of RAM so I can afford it for now.

All in all, I tip my hat to Gnome for being the wife of desktop environments. It has great stability, will be there when you need it and communicates well with you. KDE is the old girlfriend that you drunk dial from time to time and alway like to talk about how hot she looks (Opera hangs out here, too). LXDE is something you did in Vegas and only tell a few people about. You might do it again if you go back to Vegas but you can't really talk to anyone about it except the people that were there. While stability is great, ogling that old girlfriend can be fun and Vegas is exciting but draining. The beauty of this comparison is that these are analogies and you don't lose have of your personal worth by trying different things.

Monday, February 2, 2009

Follow through less

For linux users, there's a huge toolbox of things out there to allow us to perform our job more efficiently. With so many tools, there's bound to be some overlap and while some of that overlap is perturbing, some of it is really useful! I already maintain a project for following log files but this is such a common need that other projects have implemented the same functionality.

I use 'less' whenever I need to quickly take a look through something or keep something from blowing past me in some long output. It's recently been brought to my attention that not only will 'less' allow me to page the contents of something, it will also actively follow something. When you're in 'less' just press 'F' (uppercase F) and you'll be following right along. Use Ctrl+c to stop following and go back to a standard 'less' session. Pretty cool, huh?