I only just now finished reading through the manual of my GF1 - more than one year after I bought this camera.
Previously, I did only read parts of it, because I thought there was not much to learn. After all, I have been shooting with my Nikon D40 for three years before. I know it very well, and things seemed to work very similarly on the GF1. While this is still true for the very basics, I was surprised by how much clearer some of the settings got after having read through the whole thing. And I also learned things I didn’t know about at all. For example, I discovered shortcuts to useful settings that are otherwise buried somewhere in the menu.
Why is this important?
Because when you know your camera well, there’s a greater chance you’ll be able to use it to its full potential. When you’re out shooting, you can stop worrying about your gear and completely concentrate on the photo you would like to take. And the manual is the best head-start you can get.
I recently got a new MacBook Air at work.
Thanks to the increasing number of tools like iCloud, Dropbox and GitHub I can store and backup more and more of my digital stuff online. This makes setting up a new Mac from scratch pretty effortless. And so I did.
I thought it would be interesting to write down what third-party apps are essential for me to get work done. Here’s the list:
Dropbox
Apart from music, photos and code, I store all my documents here. This also includes my bash profile and gitconfig dotfiles to set up the respective tools.
I recently subscribed to Rdio. What an amazing new(ish) music service.
For NZD 13.90 a month - less than the price of one album on iTunes - I can pretty much listen to anything. I don’t have to own it and everything is streamed in excellent quality (256 kbps MP3 files) to my MacBook, my iPad and my iPhone. I can even download albums and songs to my mobile devices to enjoy offline or on-the-go.
The software is great, too. Signing up, setting up, navigating, discovering, listening, using - everything is top notch. I regularly catch myself listening to music on Rdio, although it’s in my iTunes library and I wouldn’t have to stream it. It’s just more convenient.
What I particularly like is the “Queue”, to which I can constantly add new albums to and don’t have to worry that it stops playing.
Of course, there are things that could be better. My biggest complaint is the unavailability of quite a few albums due to licensing restrictions. Although I very rarely find an album they don’t have in their catalogue at all, sometimes albums are just not available in New Zealand at this point. I really hope that gets better over time.
Other features I would like to see are the ability to rate/like/favorite songs as well as Airplay support for the Mac Desktop app.
But all in all, Rdio is amazing value for money. And for me, it makes discovering and listening to music fun again without having to ponder on what albums I am going to spend money on next.
Creative Commons offers three licenses that allow others to re-use your material for non-commercial purposes. That material is mostly photos in my case.
It turns out, the least-restrictive one of those three - Attribution-NonCommercial (BY-NC) - is all you need if you only care about the “non-commercial” part.
That sounds kind of obvious, but I was confused by one other non-commercial license.
Here are the three licenses as described on the Creative Commons homepage, ordered from most-restrictive to least-restrictive:
Attribution-NonCommercial-NoDerivs (BY-NC-ND)
This license is the most restrictive of our six main licenses, only allowing others to download your works and share them with others as long as they credit you, but they can’t change them in any way or use them commercially.
Attribution-NonCommercial-ShareAlike (BY-NC-SA)
This license lets others remix, tweak, and build upon your work non-commercially, as long as they credit you and license their new creations under the identical terms.
Attribution-NonCommercial (BY-NC)
This license lets others remix, tweak, and build upon your work non-commercially, and although their new works must also acknowledge you and be non-commercial, they don’t have to license their derivative works on the same terms.
I want my photos to be available for the widest range of use-cases and people/institutions possible, as long as these use-cases are non-commercial and I get credited.
I am fine with modifications of my work, so I didn’t need to use the most-restrictive BY-NC-ND license.
For my photos, I chose the middle one: BY-NC-SA. The reason for choosing this one over the less-restrictive BY-NC license was, that I was not sure about this line from the description of that license:
[…]although their new works must also acknowledge you and be non-commercial, they don’t have to license their derivative works on the same terms.
I thought this meant, someone could use my photos, modify them the tiniest bit and then release it under any other license, including one that does allow commercial re-use.
After some research, I discovered that this might be a myth, as Terry Hancock writes:
The only real reason most people care about using “ShareAlike” with “NonCommercial” is because they think it protects them from commercial exploitation of the derivative works.
However, this isn’t necessary. Deriving from a work in order to make commercial use of the derivative is considered “commercial use.”
Noncommercial means:
You let others copy, distribute, display, and perform your work - and derivative works based upon it - but for noncommercial purposes only.
From SquidooHQ:
You let others copy, distribute, display, and perform your work - and derivative works based upon it - but for noncommercial purposes only.
You can also remix, tweak, and build upon the image, use it non-commercially, and license the new version under a different Creative Commons license if you so choose. The new license must be non-commercial.
Now I finally feel comfortable using the least-restrictive BY-NC license without having to worry about that derivatives of my work might get re-licensed for commercial purposes.
Recently, I upgraded NZ Walks Info to Rails 3 and Ruby 1.9.3. In order to run this new setup successfully, I needed to upgrade the Ruby version on the server. I chose ruby-build and the rbenv Ruby Version Manager to do so and would like to share some simple instructions that worked for me.
The Setup
I am running the site on a Linode server running Ubuntu Linux 10.04. Here’s the software I use:
Ruby 1.8.7: installed system-wide using apt-get, located in /usr/lib/ruby
Ruby was going to be upgraded to version 1.9.3 while the other parts stayed the same. However, Passenger 3 needed to be reinstalled to work with the new version of Ruby installed via rbenv.
Installing Ruby 1.9.3 on Ubuntu 10.04 using rbenv
I found this Gist by Ben Woodward with instructions on how to install rbenv system-wide. I figured, when installing it like this I would less likely run into permission problems.
Here’s the essential part of the Gist, adjusted to install Ruby 1.9.3:
Now I needed to update Passenger to work with the new version of Ruby. All there was to do was to install the passenger gem, following the instructions on their website:
At the end of the installation, I got the configuration lines to paste into the Apache2 config file. I replaced my old settings with these updated ones:
The only thing that was missing to be able to deploy my Rails 3/Ruby 1.9 version of my app was to install Bundler:
gem install bundler
Done
This was all that needed to be done to upgrade the Ruby version on my Linux/Ubuntu system using rbenv. I hope these instructions will help someone else, too.
Knock Out Rails & Rack Apps Like a Superhero.
Pow is a zero-config Rack server for Mac OS X. Have it serving your apps locally in under a minute.
Usually, there’s no configuration needed at all, but in order to get my old Rails 2.3.x apps running, I needed to “rackup” all of these. Following the Rails Guides instructions, I had to create a config.ru file with the following contents:
# RAILS_ROOT/config.ru
require "config/environment"
use Rails::Rack::LogTailer
use Rails::Rack::Static
run ActionController::Dispatcher.new
Then I was good to go.
Unless…
When I tried to symlink the app in the ~/.pow directory - as described on the pow homepage - I got the following error:
~/.pow $ ln -s /path/to/myapp
ln: ./: File exists
But that was easy. I just had to add the name of the symlink explicitly:
~/.pow $ ln -s /path/to/myapp myapp
Now, I was really up and running with my Rails 2.3.x apps and pow. Bye bye Passenger.
(Be sure to have a look at the documentation. It’s the best source code documentation I’ve ever seen.)
We have been lucky. We weren’t in Christchurch when the 6.3 earthquake hit just before 1pm on Tuesday, Feb. 22nd 2011. We were hiking through the mountains near Glenorchy/Queenstown (approx. 400km away to the south-west).
A hut warden was present on this track and he told us on Wednesday morning what has happened. He also offered us to make one call via radio (there’s no cell-phone coverage in NZ’s mountains). The connection was short, but we managed to reach our neighbours to ask if they are ok and if their and our houses are still standing.
Everything was ok, and so we went ahead with the normal plan and continued walking for the next couple of days.
Only after we came back on Saturday, we realized the degree of destruction this earthquake caused. It was terrible to see all the pictures.
We drove home on Sunday only to grab a few things and then leave again. We didn’t feel safe in our house on the hill, although it wasn’t looking bad on the outside. The inside was a bit of a mess, but we expected things to be worse.
At first, we spent two nights on a campground in western Christchurch, before my company organised flights for us to Auckland. We ended up staying there for almost 3 weeks in an unfurnished flat. It was not exactly comfortable, but still more comfortable than being in Christchurch, having no running water and sometimes no power. No shaking was a big bonus, too.
We returned last Sunday. Wednesday evening I went out with my GF1 to take some pictures of the visible damage in Sumner, the suburb we live in.
I need to say that most buildings are looking ok and that you don’t see lots of obvious major damage everywhere. But you certainly won’t overlook it, either.
Recovering after the earthquake: The time on the Sumner clocktower is the one when the earthquake happend. Just before 1 PM.
You see quite a few of these Port-a-loos in the street. Water was not available first (it is restored now), and the sewage system is still not running properly again.
Sumner Church had some considerable damage after the quake in September, and the Febuary one made it worse.
Water tank: before running water was restored, you had to get water from one of these tanks.
A huge rock came down from the cliff in the background.
The Cornershop Bistro. Awesome restaurant where we spent a lovely evening not long ago.
“The Ruptured Duck” restaurant was heavily damaged after the September quake and this one now put it over the edge. It was still standing after the quake, but got demolished now.
zrick buildings are often hit worst.
Some properties are now a bit too close to the edge.
When I am creating a new feature for an app, I sometimes realize halfway through that the way I am building it, is not the proper way to do so. Or the specification changes. Or there was a misunderstanding. Or there’s an unexpected bug that needs to be fixed and go onto the production server as soon as possible.
Then, when you did all development on the main branch (we use Git, so that’s the master branch in that case), undoing things and/or doing a quick deployment can get very inconvenient. You can’t just deploy a quick bug fix, because all other half-finished features and fixes would have to be deployed, too. You can’t easily revert the existing commits for that feature, especially if the commits are mixed with all the other commits of unrelated features.
A good way to get rid of this problem is to create a local feature branch every time you want to work on a new feature. That branch doesn’t need to be pushed to the remote repository on the server. It’s just for you.
Then, all development for that feature happens in this branch exclusively. For every new feature a new branch is created. After a feature has been implemented completely, merge it back to the master branch (or whatever branch is appropriate). With Git, that’s super easy:
# create a new branch new_feature based on master and switch to it
git checkout -b new_feature master
# when you're done, merge it back
git checkout master
git merge new_feature
# when you are sure everything is working properly
# and no further work needs to be done for this feature,
# you can delete the feature branch again:
git branch -d new_feature
Too often I thought, “I won’t need an extra feature branch for that”. But all it takes is one simple Git command to create one (and it’s probably equally simple in other modern DVCSes). It will make your life easier when coding new features.
Bonus tip
If you decide you want to discard all the development on a particular branch, except for one or two commits, you can cherry pick these commits from the discarded branch:
# say, you have a commit 'bd42c4e7' you would like to keep
# switch to the branch you want to copy the commit to
git checkout master
# copy it
git cherry-pick bd42c4e7
The Mix and Mash competition is about creating useful and beautiful mashups and remixes with open data from New Zealand institutions.
My entry is a website to find information about all NZ walking/tramping/hiking tracks: http://nzwalksinfo.co.nz/.
Motivation
The minute I saw that the Department of Conservation made available all the geo data of their walking tracks and huts, I knew I wanted to build a website with this data.
The main idea of the site is to get relevant information on walking tracks in a very visual way. While there are lots of tramping websites already (including the excellent website of the DOC itself), I always found it quite tedious to get to some important information quickly - if it was provided at all.
Here are some of the questions I ask myself quite often and that I think are tedious to answer with existing sites:
What tracks are available near my current location or a location I’m interested in visiting?
Will it be stressful with a lot of ups and downs?
Will I only walk through forest or will I have some nice views along the way?
While I haven’t answered all of these question to my full satisfaction, yet, I think this first version is a very good starting point.
The elevation profile for example was a top priority for me, because it’s so important in my opinion. But yet I can’t find this information most of the time. The DOC makes some elevation profiles available, but only for very few tracks and then you have to get a brochure from a DOC office or download the PDF file.
Future development
Of course, I wanted to do more for this entry, but I ran out of time. I think the site is useful already (eh… obviously ;-)), but it can become a lot more useful in the future while sticking to a simple, uncluttered user interface.
I have lots of ideas and I hope I can implement them in the months to come. Winning the competition definitely is plenty of fuel for my motivation.
Mix and Mash is great
I love the idea behind the competition and I think all entries show that it’s a brilliant idea for NZ institutions to make their data available freely. I think it is a great success. Please check out all the other exciting entries on the Mix and Mash website.
Thank you for this awesome competition. It makes the internet better.
During the weekend of October 16th and 18th, I participated in the Rails Rumble 2010 coding competition. The exercise was to build a web app from scratch in 48 hours using Ruby and Rails.
Our team consisted of 3 people: Tim, Falk and myself.
The app we produced: Pianrra - An online keyboard with recording and playback functionality.
It was a rather spontaneous decision to participate. Falk and I joined Tim - who had registered ealier - only one week before the competition started. Then the planning and prototyping started.
The main reason we participated was to have fun, build something interesting and get smarter (although a little fame and a prize wouldn’t have bothered us, either). That’s also the reason why we chose to implement this particular idea of an online keyboard. It was the most unusual, risky, and exciting idea of all the ones we discussed in the week before the Rumble.
The Rails Rumble is a great exercise in collaboration - especially when you work with a team as distributed as ours. Tim and Falk were working from two different cities in Germany while I was hacking away in New Zealand.
Here are some of my insights.
Plan ahead
You can plan a lot of your project beforehand. This is crucial. When all of the planning is done before the competion, you can fully concentrate on the implementation during the 48 hours.
You aren’t allowed to produce any production ready code or graphics, but there is still plenty you can do. Here are some suggestions of what to think about:
What app are you going to produce?
What technologies/plugins are you going to use?
How’s the user interface going to look like? Create Sketches!
How are your users going to interact with the site? What’s the workflow?
What is your database model going to look like?
What name do you give your product?
Everything you can plan in advance, should be. Unfortunately we didn’t have the time to do so and decided a lot of things during the competition. So there is definitely much room for improvement next time.
Write it down
When you plan all this stuff, write it down! Use a tool of your choice where your team can collaborate easily. This is especially important if you’re not sitting in the same room during the competition.
We used Basecamp to do so and I think it helped a lot. Writing it down helped to clarify the vision for the project (‘What exactly are we going to build?’) and helped to agree on the technologies we are going to use. It definitely eliminated most (if not all) of the existing misunderstandings among the team members.
Additionally, create a list of to-dos and assign each of them to a specific person. It helped us to stay focused, agree on features and - this might seem obvious, but really isn’t - everybody knows what everybody else is doing. (Again, this is especially important if you only collaborate online).
For me, in order for a project to be successful, good communication is essential. And writing down goals, tools, features, to-dos etc. was and is an important part.
UI is important
Rails Rumble confirmed to me again, that the UI is the most important part of the software. What are all your amazing features worth when almost nobody can figure out how to use them? Right. Not much.
I won’t say that it was that bad in our case, but we certainly had quite a number of confused users. We made quite a few quick decisions during the competition (especially towards the end) and these obviously weren’t the best. We also struggled with finishing on time and so certain features and improvements didn’t make it. Additionally we also had to deal with more or less unexpected browser and OS incompatibilities. If we had planned beforehand, this would have been less of on issue.
So: get your UI, workflow and copywriting right!
There’s a lot of competition during Rails Rumble and people simply don’t have the time and/or energy to figure stuff out for every app. I know this from myself: I looked at every of the other 179 apps, and when something wasn’t clear to me, didn’t work etc. I just moved on to the next one.
Conclusion
Altogether it was great fun. Sometimes stressful and exhausting, but still fun. We learned a lot and successfully delivered a working application. I am really looking forward to next year’s edition.
I had some problems installing the heroku gem on Leopard:
$ sudo gem install heroku
Building native extensions. This could take a while...
ERROR: Error installing heroku:
heroku requires json_pure (>= 1.2.0, < 1.5.0, runtime)
So I tried to install the json_pure gem first (sudo gem install json_pure), but this always seemed to install/update the json gem instead of the json_pure gem.
I eventually managed to install the correct gem by providing the version number on installation:
sudo gem install json_pure -v 1.2.4
This installed the json_pure gem and I was also able to install the Heroku gem afterwards.
This movie contains a lot of these long scenes without cut. Two of those immediately got my attention. But first, here’s some context on what the movie is about:
Set in the United Kingdom of 2027, the film explores a grim world in which two decades of global human infertility have left humanity with less than a century to survive. Societal collapse, terrorism, and environmental destruction accompany the impending extinction. Meanwhile, the United Kingdom—perhaps the last functioning government—persecutes a seemingly endless wave of illegal immigrant refugees seeking sanctuary. In the midst of this chaos, Theo Faron (Clive Owen) must find safe transit for Kee (Claire-Hope Ashitey), a pregnant African “fugee” (refugee).
The first scene, I’d like to share is the 'roadside ambush’:
[Director Alfonso] Cuarón’s initial idea for maintaining continuity during the roadside ambush scene was dismissed by production experts as an “impossible shot to do”. Fresh from the visual effects-laden Harry Potter and the Prisoner of Azkaban, Cuarón suggested using computer-generated imagery to film the scene. [Cinematographer Emmanuel] Lubezki refused to allow it, reminding the director that they had intended to make a film akin to a “raw documentary”. Instead, a special camera rig invented by Gary Thieltges of Doggicam Systems was employed, allowing Cuarón to develop the scene as one extended shot. A vehicle was modified to enable seats to tilt and lower actors out of the way of the camera, and the windshield was designed to tilt out of the way to allow camera movement in and out through the front windscreen. A crew of four, including the DP and camera operator, rode on the roof.
Even longer is a scene “in which [main character] Theo is captured by the Fishes, escapes, and runs down a street and through a building in the middle of a raging battle”:
The creation of the single-shot sequences was a challenging, time-consuming process that sparked concerns from the studio. It took fourteen days to prepare for the single shot in which Clive Owen’s character searches a building under attack, and five hours for every time they wanted to reshoot it. In the middle of one shot, blood splattered onto the lens, and cinematographer Emmanuel Lubezki convinced the director to leave it in. According to Owen, “Right in the thick of it are me and the camera operator because we’re doing this very complicated, very specific dance which, when we come to shoot, we have to make feel completely random.”
Now watch this. It’s one take until the 6 minute mark.
That’s just amazing, even if you read that the final product doesn’t seem to be one single shot:
However, the commonly reported statement that the action scenes are continuous shots is not entirely true. Visual effects supervisor Frazer Churchill explains that the effects team had to “combine several takes to create impossibly long shots”.
Very rarely, I need to create my own global settings inside my Rails apps. If you want these settings to be different for each environment (development, test, production), you can use a YAML file to do so.
As I always need to look up how that works, I finally created a Gist, so I can look it up more quickly.
I have collected some initial tips for this blog now and thought it would be time to write something about the blog itself. So, here we go…
Do you know these moments when you talk to fellow programmers, read a blog article or book and suddenly discover a neat, new trick you haven’t seen or used, yet?
This blog is all about this! It’s meant to collect all those little new Ruby & Rails commands and tricks you have learned about.
Don’t expect this blog to teach you about Ruby and/or Ruby on Rails from scratch, though; it’s random and intended to be used as way to quickly discover new snippets of Ruby code.
All the tips are quicktips, which means they are short, practical and mostly lack some context and detailed explanation. However, I always link to sources which explain the commands of each tip in more detail.
I constantly learn new stuff about Ruby and Rails from the sources mentioned above and I thought it would be a good idea to share what I learned with the public, so you can benefit, too. While this is totally awesome already, it’s even better when more people participate…
Submit your tips
Let’s make this site the most awesome collection of Ruby and Rails Quicktips on the web! Your help is essential and very appreciated!
And don’t be afraid to submit something you think is trivial or maybe too complicated or specific; Ruby Quicktips is for developers of all skill levels! All you have learned is worth sharing and will probably help some of your fellow programmers, too.
You can comment on every tip on this blog. Please do so, if you discover an error, have an improvement to en existing tip or just want to leave a nice comment.
