Archive for the ‘Freelance’ Category

Streaming w/ GoPro 3 + *spark d-fuser + Blackmagic Intensity Shuttle Thunderbolt + Boinx TV + FMLE

For I created a setup to switch video streams.

  • GoPro 3
  • *spark d-fuser
  • Blackmagic Intensity Shuttle Thunderbolt
  • Boinx TV
  • iGlasses
  • FMLE (Flash Media Live Encoder)

Things to do:


The GoPro is very picky on settings:
Set resolution to 720p60 (the actual framerate is 59.94 as others found out
(TODO: is NTSC relevant as well?)


Update .ini in the d-fuser to add a gopro entry: 720p 59.94
This is reference number 46 (see the support page for details how to do that)

Name = GoPro 720P60 (1280x720)
Number = 46
EDIDNumber = 5

Boinx TV

Add the BoinxTV Video Sender Package to the setup. This adds syphon output.


This package can pick up the syphon stream ffrom Boinx TV and make it available as a regular QT Camera which van be used in FMLE.

Other options to investigate:

Ralf: S3 logfile downloader and merger

Today we released a new gem called Ralf, it stands for Retreive Amazon LogFiles

Download the gem at or browse the source at



  • An S3 account (duh)
  • Enable logging on S3 (use cyberduck for example)


r = => '/my/config.yaml', :date => '2010-02-01')

Or run it in one go: => '/my/config.yaml', :date => '2010-02-01')


:config   a YAML config file, if none given it tries to open /etc/ralf.yaml or ~/.ralf.yaml
:date     the date to parse

:aws_access_key_id      (required in config)
:aws_secret_access_key  (required in config)
:out_path               (required in config)
:out_prefix             (optional, defaults to 's3_combined') Prefix the output file

You can ommit a configuration file when you supply the required parameters :aws_access_key_id_, :aws_secret_access_key and :out_path
They take precedence over the config file


  • There is no logrotation as we know it like on regular unix machines

More info: S3 Server Access Logging


  • CLI executable
  • Grouping/combinig on week/month


This plugin is created for for processing the logfiles generated by S3.

Authors: Leon Berenschot and K.J. Wierenga

Time Tracking: In Analog Style

IMG_0228.JPGAs a freelancer you need to keep track of your time spend on a account. Blech! Not my favorite task, but it has to be done. I tried several web and desktop tools, but it didn’t satisfy me.

Reading David Allan’s ‘Getting Things Done’ persueded me to follow a style of tracking items with OmniFocus but it doesn’t include any timetracking capabilities.

Searching around the web brought me to the website of David Seah and specificaly the Emergent Time Tracker.


Target Priced Contracts.

Found on Freelancing Tips via Rails Camp 4 in the comments an other way to calculate/estimate the costs to keep it fair.

Derek Winter said:

Anyway, last year when looking into how best to structure commerical agreements for Agile Development work, I came across the idea of Target Priced Contracts.

The concept is that fixed price contracts mean the developer wears all the risk and therefore will need to add a buffer to mitigate the risk (ie. 30% on top, or the other multipliers described above).

Rather than take that approach, this method shares the risk between the client and the developer

Once the work is scoped and an agreed set of deliverables defined, a price is set based on your reasonable estimate of durations (the target price, based on your daily rate). This price is signed off on by the customer. For the example, lets say 10 days, $750 per day, target price $7500.

During the project, rather than pay your full rate, they pay your “cost” along the way. In our situation, thats the salary of the developer plus a little to cover overheads. For freelancers, its the rent plus enough to feed yourself and cover general expenses. (for the example, lets say $300 per day)

This will naturally leave a gap between what you’re paid and what the target price is (10 x $300 = $3,000 :- final payment is $4,500). If the contract finishes on time, then this is the amount the client pays you at the end and we’re all happy.

If you are outstanding and find faster ways of completing the work and finish ahead of time (say 8 days), the client still pays that amount. They’re happy because they paid less overall for the project (8×300 + 4,500 = $6,900) and you’re happy because you made the same amount of profit for less work ($4,500 for 8 days work instead of 10) and can get onto the next project

If however there is scope creep, things get tricky, something goes wrong and it takes longer than 10 days (say 12 days) then the client continues to pay your costs until you’re finished (an additional 2×300), but only pays the same final payment ($4,500).

So, they pay more (12×300 + 4,500 = 8,100) and your profit margin goes down (4,500 profit out of 8,100 total payment instead of 4,500 out of 7,500). So, you both feel some pain, but its not unfairly felt by either party.

This means that both parties are focussed on getting a good result – clear requirements, efficient delivery.