03 Dec

Harbour Front Monthly #4

Time flies and it’s almost the end of the year… Still we have planned the 4th edition of Harbour Front Monthly to send you off into the new year with some more practical take aways. This time our speaker Kristin Low will focus on learning UX by doing UX.

How do you learn UX? As a teacher of UX, I’m often tasked with helping to impart a designer-ly view of the world into the mind of students. Although each student learns differently, one common factor applies to all students: learning by applying.

The event will take place on Wednesday, December 17th in our usual location at the Hive in Wan Chai. You can register here and we’d love to see you there.

18 Nov

The Difficult Has Become Too Easy

I just read this post by Jonathan Stark called ‘Mobile Last?’ about his experience at the Rails Rumble hackathon and having come across the same assumptions from various people on a frequent basis, I wanted to write down a few thoughts on it.

In case you haven’t read the article yet, you should really do so, but here’s the quick gist:

The Rails Rumble is a distributed programming competition where hundreds of teams from all over the world have 48 hours to build an innovative web application.
However, there’s one thing that really sticks in my craw: only one of the top ten winning entries was even a little bit mobile friendly. That’s right… 90% of the entries were virtually unusable on even the most modern smartphone. My reaction to this ranged from shock to frustration to sadness.

As I have mentioned, I hear the point of building mobile-first (or even) responsive in general being more work quite often. I find this being the same sort of myth as saying that responsive sites can’t be fast (they can!). It always depends on how you do it and what you’re after. There’s no question that responsive websites can be a lot of work, depending on the level of detail you want to put into it. But for now that’s not the point.

What I have noticed over the last years, is that web design in general has become a lot harder and as we know, especially building responsive sites can be a very daunting task. At the same time, building websites has nowadays become very easy. Maybe too easy.
Today, we have a lot of tools on hand, that make building websites easier. Frameworks and plugins make building websites so easy, people have to think less about what they are doing. The web has become a plug-and-play playground. Are we losing our craft to build for the web?

By doing it this way, understanding underlying paradigms, languages and technologies isn’t mandatory anymore and I believe that this might be part of the problem. Don’t get me wrong, I believe that it’s great that everyone can create for the web. But as developers, we should know our tools, as much inside out as possible. Many people advertise their sites as being responsive; in reality they are just plugged together by using different frameworks which are spitting out 3 different fixed-width screen size layouts that adapt for the assumed ‘most common’ screen sizes. I’m not arguing that adaptive design is wrong, but you need to first know the rules before you can break them – meaning to understand what’s right for you.

To get back on the topic of building mobile-first and why it is considered so much more work: only practice makes ‘perfect’.
The more you do it, the better you get at it. The more you get used to the underlying thinking, understanding and applying the processes involved in doing things mobile-first over and over, you will gain experience and at some point it will all feel normal to you. And this is when you’ll start to agree that building mobile-first isn’t that much harder than you might initially have thought.

No single framework can teach you how to build great sites, you only learn and become better by understanding the basic skills and concepts first, there’s no fast-forward. When you have this down, you can control the tools and not let the tools control you. Once you’re in control, you’ll be faster to apply and work with these techniques & tools and will find building mobile-first responsive sites just comes natural to you.

03 Nov

Harbour Front HK Monthly #3 (and #3.5)

The next Harbour Front Monthly event is coming up and because it’s during StartmeupweekHK we’re running two events in a row this time.

The first event will take place on Tuesday, November 11, 2014 from 7:00pm to 9:00pm at the Hive in Wan Chai. We will feature 2 speakers with a ~30 minute talk each, covering web design topics in a practical approach for greatest take-aways.

Our second event will be held on Thursday, November 13, 2014 from 7:00pm to 9:00pm and is also hosted at the Hive in Wan Chai. What’s on? A workshop, the ‘Big Front End Quiz’ or something else, we won’t tell, yet.

Come and join us for two fun evenings with drinks and a little banter afterwards, all for free. You can register via Eventbrite here.

02 Nov

Escaping an Issue with Grunt ‘string-replace’

Since I started using Grunt, I have found more and more cases where Grunt tasks turn out to be very useful and a huge timesaver. That is, timesaver once you got whatever you’re trying to do up and running. In the most recent case, I ran into an issue with using Grunt string-replace to replace background-image URLs in my CSS file with a different path to prepare them for use with Rails’ asset pipeline.

I needed to search for : url(img/imagename) to then be replaced with : url(<%= asset_path 'img/imagename' %>).

As the first replacement pattern I used ':$1url(<%= asset_path \'$2$3\' %>)’. This failed with an error message. Since I was using the < & > characters in the pattern, I figured these characters might need to be escaped.

I tried ':$1url(\<%= asset_path \'$2$3\' %\>)’ and various variations, all without any luck. Eventually I found a hint on Stack Overflow, that this might not work this way at all and needs to be processed with two passes.

After checking back with the author of string-replace, this problem seems to be related to Lo-Dash‘s template security.

The final working code looks like this now and works pretty much as well as it would with running it in one pass, I believe.

'string-replace': {
  inline: {
    files: {
      'dist/css/app.css.erb': ['css/app.css'],
    options: {
      replacements: [{
        pattern: /:(\s*)url\((img)(.+?)\)/ig,
        replacement: ':$1url(\<%= asset_path \'$2$3\' CLOSETAG)'
        pattern: /CLOSETAG/g,
        replacement: '%>'

18 Oct

Mac OS X Yosemite Upgrade & PostgreSQL

Even though I am currently deep into a project which is coming closer to launch and despite trying to not upgrade yet, I couldn’t wait to install Yosemite on my main machine. So I did. Luckily everything works and it was an easy upgrade process. The only thing that needed a little bit of work was a problem with PostgreSQL not starting anymore, which I found after getting an error trying to start the rails server.

Disclaimer: PostgreSQL is one thing which I don’t know much about at all, but this fix doesn’t involve anything that could break your machine, so I thought it might be worth posting.

$ rails s
/Users/foobartel/.rvm/gems/ruby-2.1.2@ik/gems/activerecord-4.1.4/lib/active_record/connection_adapters/postgresql_adapter.rb:888:in `initialize': could not connect to server: No such file or directory (PG::ConnectionBad)
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

I checked the log file (/usr/local/var/postgres/server.log) and found these lines:

FATAL:  could not open directory "pg_tblspc": No such file or directory
FATAL:  could not open directory "pg_twophase": No such file or directory

I did a Google search for these two lines and found this article on StackOverflow, which seemed to provide the fix. Since this was an easy one to try, I just created these directories.

mkdir /usr/local/var/postgres/pg_tblspc
mkdir /usr/local/var/postgres/pg_twophase
mkdir /usr/local/var/postgres/pg_stat_tmp

Starting the PostgreSQL with pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start then worked. Problem solved. If you ran into the same thing and see the same fatal errors in your log file, I hope this solution works for you as well. Just to be on the safe side, don’t forget to create a backup if you haven’t done so already.

29 Aug

Mac OS X: Open With… Duplicates

This is the problem: You want to open a file using something other than the default application. You right-click its icon in the Finder, choose Open With, and a submenu pops up with an absurd number of duplicate entries.

This is one of my favorite Mac OS X tips to know, even though it doesn’t seem to happen too often anymore, but when it does it can be quite annoying, because the list of possible apps to open your file with can get pretty long. So this one let’s you quickly tidy up and remove the annoyance.

The contextual menu for Open With… including duplicates

You can find the detailed instructions on how to remove the duplicates here: Getting rid of Open With… Duplicates. For me this solution has always worked like a charm and it helps to clean up this mess every once in a while.