Thursday, October 8, 2015

(Sadly) I am so done with this...

Years ago when I first started working with Ruby on Rails (back in the version 1.0 days) I started off on a Windoze machine... and we all know what a major headache that was. It didn't take me too long to start looking for other alternatives and I settled eventually on Kubuntu.

It took a lot of work to get things up and running but I slowly learned more and more about bash, and setting up Apache, and getting Samba to work on my mostly Windoze network. A lot of work but I eventually got things working and was able to happily develop my system on that platform. I really came to love the power and flexibility that was possible on Linux.

Eventually, I started working with some older MacBooks and while they were relatively under-powered and had their quirks it was a pretty nice setup. And for the past two years now I've been working with current MacBooks and loving it. However, when starting up a new project, I decided to got back and see how Linux would work: it would be my desktop / base machine and I could still use the MacBook when I was on the road.

As usual, there were a number of glitches, not the least of which was that my last version was 12.10 and was no longer supported. Not only does Ubuntu not support the old releases, they actually take down any servers that contain the files necessary for an upgrade so you're pretty much out of luck. I didn't want to start from scratch as I had a lot of things configured. I already had my /home on a separate hard drive so I was eventually able to migrate things over and get up and running on 14.04.

I figured I was good to go... wrong.

Running Rails 4.0 turned out to be a problem: capybara-webkit refused to install so I started researching that. More hassles, more delays, but I figured it would settle down soon.

Wrong again.

I decided to do a reboot and that's when things got really, really bad. I got dropped into a grub rescue prompt, with complaints about a parameter that some well-meaning application had added. And even setting the boot drive (after even more research) didn't solve the problem.

Fortunately I don't have much on the system that isn't backed up -- there's only one small system and database that I'll need to recover but this time I'm going to do it with a live disk and then...

...I am done with Linux. I've come to the opinion that Linux is really great for two kinds of people:
  1. People that want to learn and play and don't mind re-installing frequently.
  2. People that really really know how to make this stuff work well -- sysadmins.
Unfortunately I'm not one of those two kinds: I want to use the system to get meaningful work done, I don't have time to learn everything, and I certainly don't qualify as a sysadmin, even though I've gotten lots of things working over the years.

So... sayonara, Linux... it's been good to know you. You've been a good companion -- albeit often a frustrating one -- and I've learned a lot from you, but it's time for me to move on.

Friday, April 10, 2015

git shortcuts

Over the past few months, I've developed a few shortcuts that make using git a little easier & quicker. Here are a few... I'm curious as to what others are doing. These are defined in my .bashrc

List or use the currently active branch
function gbc() {
if [ -e ./.git ]; then
  git branch | sed -n -e "/^\*/ p " | cut -c 3-99
export -f gbc
Now if I want to see what the latest branch is, I simply type `gbc` and the current branch is displayed. What's even more useful, IMO, is that I can now use that function to display the current branch in my bash prompt using something like this:
PS1='${debian_chroot:+($debian_chroot)}\u@\h:[\W-$(gbc)]\w\$ '
and now my prompt looks like this:
I've got mine color-coded (MUCH longer PS1 string) so that the branch name really stands out and I can see immediately where I am.

Quickly add modified (but not new) files
I frequently have a few untracked files in my repo which I do not want to add to the repo, so git adding everything doesn't work for me. So I created a `gadauto` command to do that for me.
function gadauto() {
  git status | ack 'modified:|deleted:' gst.txt | sed -Ee 's/modified:|deleted://' | xargs git add
export -f gadauto
Now a quick `gadauto` command adds modified or deleted files to the staging area

Quickly add to and amend a commit
We use git-review and the preferred workflow is to first create a new commit and then amend that commit until you're ready to push it for review. The command to do that is "git commit --amend". To shorten this, I created a simple alias:
alias gcamd='git commit --amend'
Now when I'm ready to add my updated files and amend the commit, all I have to do is type:
gadauto && gcamd
I could shorten that even more but I like to type just a bit more when I could make a messy mistake.

Quickly add merge conflicts that have been resolved
The gadauto command works great but doesn't handle the use case for files that have been conflicted and then resolved during a git rebase, for example. Handling this is just a simple modifaction of the gadauto commend described above.
function gadboth() {
  git status | ack 'both modified:|both added:' gst.txt | sed -Ee 's/both modified:|both added://' | xargs git add
export -f gadboth
Now Now following a `git rebase master` and conflict resolution, I just type:
and all of the files that were just resolved are added to the staging area, ready for the `git rebase --continue`.

Hopefully this will help someone; I'd be interested to know what your favorite git shortcuts are.

Update If you want to see some really cool git shortcuts, visit Thoughtbot's dotfiles.

Monday, March 9, 2015

No, it wasn't the "world's least helpful error message"

Last wee, I commented about a problem with AngularJS and an error message that I found incredibly unhelpful.  Turns out it was more helpful than I knew although there are still problems.

Here's what it looked like in Chrome DevTools:
But that's a live link, so all you have to do is click on it and you're redirected to an AngularJS page that (hopefully) provides more information. Here's the link, and here's the link text iteself: quite a mouth/link full:

What you get when you click on this link is a customized error page -- pretty neat way to handle things and sometimes it works very well -- this example was spot on:

But here's one that wasn't nearly so helpful:

So...much better than I thought, although there are still some head-scratchers.

Wednesday, March 4, 2015

Is this the world's least helpful error message?

Well... probably not. I've seen worse but this one is pretty bad.

I've been working with the MEANjs web stack lately and so far find it pretty interesting and, yes... even useful. I am, however, less than pleased with the client side of things: AngularJS. It's pretty cool and is getting a lot of traction these days (although there are detractors who point out performance problems).

That's not my issue today; my issue is with the following error message, which I hereby nominate for today's "World's Least Helpful Error Message".

Uncaught Error: [$injector:modulerr]$injector/modulerr?p0=userApp&p1=Error%3A

Apparently I've made an error injecting "something into "some module" but AngularJS can't be bothered to tell me what the "something" is it cannot inject nor what "some module" it tried to inject it into.

Apparently I'm not the only person with this problem, as there are quite a few StackOver questions here, here, and here. A bit of searching turns up some interesting approaches to dealing with this problem: Angular Batarang, Debugging Tutorial, or Debugging From the Console.

To be fair, the error message does have the text "p0=userApp" embedded in it but that could entail a wide codespace and there's nothing else to help pinpoint the problem. Why can't Angular provide backtrace information as to specifically where the problem occurred and/or what caused the problem? If you have several modules, and you're new to the framework, this makes Waldo look easy.