New Job

| Comments

I am switching to go work for Dagbladet Information (again) from April.

It's been a really hard decision. I had to choose between two different kinds of Drupal awesome. I know—really a first world problem.

Reload has amazing people and great clients that are willing to work agile. I have been super happy with the projects I have been working on and I have worked with a lot of the best Drupal developers in Denmark there. Also, if you would like to work with Reload, check out this job posting!

At Information I will have freedom to travel with work and in the end the freedom won. I am looking forward to working together with Morten Wulff every day no matter where I am in the world. Luxury!


naxoc.net is now on Sculpin

| Comments

I have changed the blogging engine for this blog once again. This blog was on Drupal for a while, then on Octopress (Jekyll), and now on Sculpin. I was never unhappy with either of them—I just enjoy playing around with new stuff every once in a while.

This blog is now a custom Sculpin thing. There is a blog skeleton available to get you started, but I thought I would roll my very own with some heavy inspiration from the skeleton. I also wanted my "theming" to be custom so I could play with new shiny things like Gulp.

I probably spent the most time monkeying around with Gulp. I hadn't used Gulp before and I only had a weak grasp of Grunt, so there was some learning to be done there. I got it working great with Browsersync, Bourbon and sourcemaps. All sweet stuff that I will write more blog posts about.

Using Sculpin is really easy. I never really touched any PHP code other than pasting a little code into SculpinKernel.php to enable redirects via mavimo's Sculpin Redirect Bundle. So all I had to do was create some .html files with Twig syntax to render my markdown files. I could migrate the .md files from Jekyll format pretty easily—I just had to remove the Octopress-specific image tags I had in my markdown.

As a PHP developer I feel much more at home with Sculpin than I did with Octopress and Jekyll. Neither are that hard to use, but I really like how Sculpin is simple and doesn't do too many things I don't need.

The only downside to Sculpin over Jekyll is that hosting the site on Github Pages is a little harder. It is still totally doable, but you have to commit the generated content for Github to be able to serve the pages. I simply chose to just push the generated files to my VPS.

If you are curious about Sculpin and how this blog is created, you can check out my Github repository for naxoc.net.


Switching back to Firefox

| Comments

I have been using Firefox since it came out. I used it back when it was called Firebird and Phoenix. I went to the release party when 1.0 came out and I have advocated using Firefox to anybody that wanted to listen -- and a few that didn't.

2-3 years ago I switched to Chrome along with a lot of other people. Firefox was getting bloated and Chrome had all kinds of shiny tools. But I am back to using Firefox now, and I thought I would explain what lured me back in this post.

I didn't switch because I was tired of, or unhappy with Chrome. I still use both so that I can be logged in to work stuff in one and my own stuff in the other. But I mainly use Firefox for web development now. It should be said that I use the Firefox Beta version and I have had no problems with that. The reason I use the beta is that I really like a couple of the developer tool features, but version 29 also has nice developer tools.

These are some of the features and tools that have impressed me:

Developer Toolbar

Of all the shiny things this one was the one that made me switch. Firefox now has a developer toolbar that sits at the bottom of the page for as long as you want it around. Toggle it with Tools > Web Developer > Developer Toolbar. I just keep it around at all times. To change focus and go to it use shift+F2. You can run commands from text in the toolbar and it also shows a little red badge if there are javascript errors on the page.

So what does it do?

Well, it's a browser command line for web developers. Try typing help and get a list of commands. I use the cookie and inspect [element] most, but the resize toggle is pretty sweet too. Just like CLI it has completion and arrow up gets your history of commands. Another really cool one is media emulate print -- it will show you the page with the print style sheet (or whatever media you put after emulate).

All these things can be done with the mouse too I'm sure, but I like it that I can access these tools really fast with a browser CLI.

Firefox cookies The screenshot shows output from the command cookie list. You can find more info on the toolbar in the mozilla.org docs.

Scratchpad

The scratchpad is a 'js-editor' that lives in its own window. Invoke it from the Tools > Web Developer menu or by going shift+F4. You can write js and execute it with one of the three buttons. The code you write will be in the scope of the browser window you were in when you invoked the scratchpad so you can test your jQuery snippets or whatever does it for you. There are instructions on how to use the buttons in the comment that is displayed at the top of the file. One thing that is left out that is super helpful though is cmd+shift+r. That will reload the browser window, but keep your js code in the scratchpad.

The keyboard shortcuts are the same as for the style editor and the debugger. There are even key bindings for emacs and vim! To set key bindings, go to about:config in Firefox's location bar and set devtools.editor.keymap to "vim" or "emacs".

Pretty inspector

This one is very subjective, but I think that the inspector and the whole developer tools is really pretty. I use the light color scheme, and it just looks better than Chrome's dev tools. I know, but I had to get that one of my chest. There is a dark color scheme setting in the options (click the gear).

There is a font preview tab in the right box on the inspector tab. It's nice to have a clue about the font. I am not a designer, so most the time I don't have a clue. This helps:

Fonts

Another cool thing about the inspector is the "guides" it shows when it highlights an element. It is best illustrated with an image. I am talking about the dotted lines that helps you see if you are aligned with what you want to be aligned with.

Firefox inspector

Network tab

Like with the inspector -- I just think it's pretty. And there are some useful things too! The filtering in the right hand box is really good. There is also a view with pie charts showing the page loaded twice: once with an empty browser cache and once with a primed browser cache. It is quite interesting to compare the two when you are slimming your page weight down. To get to it click the button on the lower right hand when on the network tab: Firefox inspector

You then get this:

Primed cache

See more about the network tab at the developer docs on mozilla.org

Mobile version

I have an Android phone whose factory default browser is Chrome. Firefox can sync between desktop and phone just like Chrome and I think it is as fast. Plus I also just like how it looks.

So what?

I don't have a strong enough opinion to start a browser war. I like both Chrome and Firefox and I will continue to use both. This blog post is just to describe the new cool stuff in Firefox and once again -- whether you want to listen or not -- I encourage you to try Firefox and play around with the new dev tools.


Atom editor update problem

| Comments

I have been playing around with Github's new editor Atom for a while now. I actually quite like it, but it still hasn't taken Vim's place as my default editor yet. Maybe it will at some point, but we'll see.

Atom updates itself and that has been working great, only it stopped working a while ago. It threw some long error to the GUI editor that I can't remember and when I tried to run apm upgrade it said:

➜  ~  apm upgrade
Package Updates Available (0)
└── (empty)

-- even though in the UI it said it had an update ready.

I poked around a for a while until I found a couple of mentions in the support forums like this one saying that you should just set file permissions on your ~/.atom/.node-gyp folder. So I did

chmod -R 777 ~/.atom/.node-gyp

and restarted the GUI Atom.app. Now my update was applied and everybody was happy again!


Switch between PHP versions with Homebrew

| Comments

I am working on a few older Drupal sites that are quite insistent on using PHP 5.3 and not PHP 5.4. No problem - I'll just use Homebrew to switch between versions! But I have been running into all kinds of problems every time I have done this, so I figured I would post what I do to repair things here.

So, in theory all you should have to do is install the versions you need if you don't already have them. brew install php53 And when you want to switch just run this: brew unlink php54 && brew link php53

Apache also needs to know what version to use, so edit /private/etc/apache2/httpd.conf so that the line that looks like this has the right (major) version number: LoadModule php5_module /usr/local/opt/php54/libexec/apache2/libphp5.so

So far so good. You can check the version from the command line:

➜  ~  php --version
PHP 5.3.28 (cli) (built: May  7 2014 09:50:08)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2013 Zend Technologies
    with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

If you are not seeing what you expect, try adding add this to your .bashrc or .zshrc with the correct version number: export PATH="$(brew --prefix homebrew/php/php54)/bin:$PATH"

If things are working now thats great! It doesn't always for me. I get this:

➜  ~  php -i
dyld: Library not loaded: /usr/local/lib/libpng15.15.dylib
  Referenced from: /usr/local/opt/php53/bin/php
  Reason: image not found

Sadly the only workaround I have found is to uninstall and install again: brew uninstall php53 & brew install php53

It takes quite a long time but it does the trick.


Keyboard shortcuts in PHPStorm

| Comments

Coming from Vim to PHPStorm I use the mouse a whole lot more than I did before. Vim is amazing once you learn it and the mouse can take long naps when you do everything with keyboard commands. PHPStorm is a great IDE, so I switched because I felt like I got so much more good stuff like the debugger, easy refactoring, structural overview, and so on. In the beginning I used the IdeaVim plugin in PHPStorm so editing seemed more like Vim, but I ended up abandoning that because I found it buggy.

Anyway. I slowly learned new keyboard shortcuts for PHPStorm and I wanted to share some of my favorites. Jetbrains has a a list of keyboard shortcuts you cannot miss too, but most of the ones I find to be super useful are not on that list.

It should be said that I am on a Mac using the "Mac OS X 10.5" keymap in PHPstorm.

  • command+[ and command+] to go back to the place in the code where you just were or forward respectively.
  • command+shift+delete go back to the last place in code you edited.
  • cmd+F12 bring up a quick window with all functions/classes in the current file. Type to filter and go to. I use this one all the time. I realise that I could also just use option+command+o, but this one is much faster and narrowing down is easier.

Tools

  • command+1 toggles the project pane that shows the file tree. For extra usefulness, do this one time setting: Click the gear in the menu and choose "autoscroll from source". Now the tree always shows you where you are in the file structure.
  • command+3 toggles the "find" pane. Useful for going back to see a global search done with command+shift+f. To navigate between search results use command+option+arrow-up/down
  • commmand+5 toggles the debugger pane.
  • command+7 toggles the PHP structure pane.
  • command+9 toggles the version control pane. I don't use this a whole lot---I prefer the command line for Git, but there are some nice features in the VCS tools in PHPStorm. My favorite VCS keyboard shortcut (actually this one is kind of a sequence) is ctrl+v and then hit 5 to get a Git blame panel.

In the debugger

  • option+command+r will resume.
  • command+f2 will stop (kill).
  • F8 will step.
  • shift+command+F8 will show you a list of all your breakpoints.

These are some of my favorites. Comment and share yours!


Syntax highlighting commands with Zsh

| Comments

I started using zsh about a year ago after having resisted it with a passion. My main worry was that I would "forget how to bash" and be lost on various servers I log in to. While there are some nifty things I have gotten a little too used to in zsh, I don't think it has been a big problem.

One thing that visually tells me that I am in zsh and not bash is that my zsh terminal syntax highlights as I type. Yes, you read that correctly. If you are not familiar with the zsh-syntax-highlighting prepare to have your mind blown.

When you are typing a command you get a yellow color:

ZSH syntax

Then when you have typed something that actually is a command you get green:

ZSH syntax

When you make a typo you get red:

ZSH syntax

It also makes correctly quoted strings yellow. I find that a nice help too:

ZSH syntax

On the Github project readme there are instructions for installing the plugin.


Placeholder selectors in SASS

| Comments

When I found that you can '@extend' classes in SASS to reuse code and compile to neater CSS I was pretty excited. Here is an example of 'inheriting' code with @extend:

.speak {
  font-family: Courier New, monospace;
  max-width: 400px;
  clear: both;
  span {
    font-weight: bold;
    display: block;
  }
}
.voice-1 {
  @extend .speak;
  span {
    color: magenta;
  }
}
.voice-2 {
  @extend .speak;
  float: right;
    span {
      color: green;
  }
}

That will compile to:

.speak, .voice-1, .voice-2 {
  font-family: Courier New, monospace;
  max-width: 400px;
  clear: both;
}
.speak span, .voice-1 span, .voice-2 span {
  font-weight: bold;
  display: block;
}
.voice-1 span {
  color: magenta;
}
.voice-2 {
  float: right;
}
.voice-2 span {
  color: green;
}

So voice-1 and voice-2 get the same properties as the speak class and the code is reused. All is good, but I don't really have a class called speak. And more importantly - I want to be able to define my speak selector in a base file that is included in lots of other .scss files so that it becomes truly reusable. But here I run into the problem that every time I include the _base.scss file, the selector gets written to the file including the file. That becomes a mess of repeated code really fast.

I found out about SASS placeholder selectors recently and once again my mind was blown. So a placeholder selector is a selector just like .speak, but instead of a dot (for class) it is prefixed with a percent sign. Selectors prefixed with % don't get rendered to CSS, so I don't have to worry about duplicated code or not actually having a class somewhere called speak. Now I can define the selector in a base file and extend it over and over in included files.

So:

%speak {
  font-family: Courier New, monospace;
  max-width: 400px;
  clear: both;
  span {
    font-weight: bold;
    display: block;
  }
}
.voice-1 {
  @extend %speak;
  span {
    color: magenta;
  }
}
.voice-2 {
  @extend %speak;
  float: right;
    span {
      color: green;
  }
}

Becomes:

.voice-1, .voice-2 {
  font-family: Courier New, monospace;
  max-width: 400px;
  clear: both;
}
.voice-1 span, .voice-2 span {
  font-weight: bold;
  display: block;
}
.voice-1 span {
  color: magenta;
}
.voice-2 {
  float: right;
}
.voice-2 span {
  color: green;
}

Here is a Codepen with the placeholder selectors (and some Monty Python). If you want to play around with it, take note of the "view compiled" link in the lower right corner when you are on the SCSS tab.

See the Pen SASS placeholder selectors example by Camilla Krag Jensen (@naxoc) on CodePen.


Organizing code when using Modernizr and SASS

| Comments

The JS library Modernizr makes it really easy to write CSS with support for older browsers. What it does is put classes in the <body> tag that will tell you what the browser doesn't support. For instance IE9 in the screenshot does not support CSS gradients:

Modernizr body tag classes

I was going trough with IE9 on a rather large site that uses some spiffy CSS3 tricks to achieve awesome. It has been a pleasure to work with Compass and SASS to build the site, but when it came to making it look decent in IE9 there was some work to be done.

I started to work on it, but I quickly got frustrated with the organization of the SCSS. Where should I put the IE-fallbacks? In a ie9.css style sheet? Well, that really keeps the code scattered everywhere. I wanted to keep the fallbacks as close to the original CSS3 tricks as I could so I started putting code like this as close to the "real" selector as I could:

.some-div {
  .special-list {
    .extra-special-link {
      @include background(linear-gradient(left, rgba(242, 156, 45, 0), rgba(242, 156, 45, 1) 30%, rgba(242, 156, 45, 1) 70%, rgba(242, 156, 45, 0));
    }
  }
}
// Also support archaic browsers for the extra special link (see above).
.no-cssgradients .some-div .special-list .extra-special-link {
  background: rgba(242, 156, 45, 0);
}

While this works, it becomes hard to find out what the targets are, because the whole structure needs to be prefixed with the no-cssgradients class. I would much rather have the fallbacks in the code right next to the 'actual' CSS. I did some googling for best practices for structuring the code and found this post on Neil Carpenter's blog that showed me that the '&' ampersand used behind the selector will do exactly what I wanted! This may be really trivial, but I had no idea the ampersand could be used like that in SASS. So the above code can be simplified to:

.some-div {
  .special-list {
    .extra-special-link {
      @include background(linear-gradient(left, rgba(242, 156, 45, 0), rgba(242, 156, 45, 1) 30%, rgba(242, 156, 45, 1) 70%, rgba(242, 156, 45, 0));
      .no-cssgradients & {
        background: rgba(242, 156, 45, 0);
      }
    }
  }
}

Yay! I can now keep my fallbacks together with the actual CSS and never worry about ie9.css or other tricks that separate the fallbacks from reality.


Format json output from cUrl neatly

| Comments

Here is a short simple tip to read json output from curl in a neat formatted way:

Pipe the output to Python like this:

curl "http://url.to.call?args=hi" | python -mjson.tool

This will prettify the output and make json much more readable when testing webservices. It also validates the json, so if it contains errors you will get a warning.

It works with Python 2.6 and higher and you can find more info at the Python docs page.