Our current best for a recycling “tower” is around 90cm, probably need to specify some criteria for base dimensions etc (if anyone was serious about competing).

Recently I needed to create a script to make a single movie from static images and existing movie files. I hacked this together with ruby, ffmpeg and ImageMagick. Note, it will function under windows with little code change.

Putting it up in case someone finds it of use!

#!/usr/bin/ruby
require 'fileutils'

# !! Script requires image magick to be installed (for convert) and ffmpeg !!
#
# This was *hacked* up quickly, apologies for the general cr*ppy style, its
# functional but not beautiful!
#
# Note: I pipe ffmpeg output (STDOUT/STDERR) to /dev/null - If ffmpeg fails to
# convert you might want to remove this "feature".
#
# Also note you will have to change jpg_to_mpeg() to alter how long static
# images play for.
#
# Also, also note, its hardcoded to look for specific file extensions, you
# might want to alter these as well.
#

# For a given folder, find a unique filename of random string + post_fix
def unique_filename_at(folder, post_fix)
  name = nil
  begin
    name = File.join(folder, ((1..8).map{|i| ('a'..'z').to_a[rand(26)]}.join) + post_fix)
  end while File.exists?(name)
  name
end

# Resize all image files in env[:src] writing them to env[:dst]
def resize_images_as_jpg(env)
  resized_names = []
  images = Dir.glob(File.join(env[:src], '*.{jpg}'), File::FNM_CASEFOLD)
  images.each do |image|
    resized_names << unique_filename_at(env[:dst], ".jpg")     `convert -scale #{env[:width]}x#{env[:height]} #{image} #{resized_names[-1]}`     `identify #{resized_names[-1]}` =~ /(\d+)x(\d+)/     # Scale attempts to best fit (based on image aspect ratio), it doesn't guarantee the exact size, so     # add extents (pad) the image to one which has the desired dimensions     if (env[:width] - $1.to_i) > 0 or (env[:height] - $2.to_i) > 0
      `convert -gravity Center -extent #{env[:width]}x#{env[:height]} #{resized_names[-1]} #{resized_names[-1]}`
    end
  end
  resized_names
end

# Resize all the movie files in env[:src] writing them to env[:dst]
def resize_movies(env)
  resized_names = []
  movies = Dir.glob(File.join(env[:src], '*.{mpg,mp4,flv}'), File::FNM_CASEFOLD)
  movies.each do |movie|
    resized_names << unique_filename_at(env[:dst], ".mpg")     `ffmpeg -i #{movie} -s #{env[:width]}x#{env[:height]} -sameq -r 25 #{resized_names[-1]} > /dev/null 2>&1`
  end
  resized_names
end

# Convert the given file (must end .jpg) to an mpeg
# !! Hard-coded to create movies of length 10 seconds
# !! 25 frames per second and 250 frames in total
def jpg_to_mpeg(file)
  movie_name = File.join(File.dirname(file), File.basename(file, ".jpg") + ".mpg")
  `ffmpeg -loop_input -qscale 1 -f image2 -vframes 250 -r 25 -i #{file} #{movie_name} > /dev/null 2>&1`
  movie_name
end

# Usage: tomov src_folder dest_folder
# src_folder contains images/movies
# dest_folder will contain the final result
if __FILE__ == $0

  # Change this to set the resultant video size
  env = { :width => 640, :height => 480 }

  # Get src/dest folders - I didn't care about fancy argument checks at the time...
  if ARGV.length != 2
      puts "tomov in_folder out_folder"
      exit(-1)
  end
  env[:src] = ARGV[0]
  env[:dst] = ARGV[1]
  exit(-1) unless File.exists?(env[:src])
  exit(-1) unless File.exists?(env[:dst])

  # Get the movie files to be consistent
  movies = resize_movies(env)

  # Get the image files to be consistent and convert to movie files
  resized_images = resize_images_as_jpg(env)
  movies.concat(resized_images.collect {|resized_image| jpg_to_mpeg(resized_image) })

  out_tmp = File.join(env[:dst], "movie.mpg")
  out_final = File.join(env[:dst], "final.avi")

  # Concat individual movies into a single movie
  # (the sort tries to ensure video's and images are mingled (not guaranteed though))
  `cat #{movies.sort_by{rand}.join(" ")} > #{out_tmp}`

  # Ensure the final movie is consistent and the format I want...
  `ffmpeg -i #{out_tmp} -sameq -vcodec mpeg4 -an -r 25 #{out_final} > /dev/null 2>&1`

  # Clean-up intermediate files
  File.delete(out_tmp)
  resized_images.each {|i| File.delete(i) }
  movies.each {|i| File.delete(i) }
end

A random script I hacked together (through searching and experimentation) for pulling down videos from YouTube with ruby, its only guaranteed to last along as the current YouTube html formatting lasts.

Will work under windows, with some minor changes (and installation of curl and ffmpeg). Usage should be obvious, it takes the YouTube url (with watch? in it) as an argument (try quoting “”)

#!/usr/bin/ruby
require 'rubygems'
require 'hpricot'
require 'open-uri'

USER_AGENT = %{Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3}

def parse_youtube(url)
  youtube = "http://www.youtube.com/"
  url =~ /watch\?v=(.*)/
  doc = Hpricot(open("#{youtube}watch\?v=#{$1.split("&")[0]}"))
  doc.search("/html/body/").each do |foo|
    matches = URI.unescape(foo.inner_html).scan(/\|(.*?http.+?),.*?\|/)
    matches.each do |match|
      match.each do |item|
        return URI.unescape(item) if item =~ /videoplayback/
      end
    end
  end
  nil
end

if __FILE__ == $0 and ARGV[0]
  url = parse_youtube(ARGV[0])
  `curl -o \"foo.flv\" -L -A \"#{USER_AGENT}\" \"#{url}\"`
end

I liked the way this presentation style really forces you to be precise and deliver the real message, it took ages to produce for such a small presentation time, this I guess is the point, i.e. deliver maximum value in the shortest time period.

The content blends my recent ramblings based on the “trousers of reality” book as well as a few other insights.

The exercise has given me an insight into how I would like to structure a book on this subject, pictures one side and words on the other, all forming a Koan – Practical “how to’s” at the end – Need to work more on this.

You can find the raw material here (note in terms of the slides, the first slide was triggered on a mouse click, the remainder on a twenty second timer – The last slide filled a question and answer section – I stuck to the “rules”).

I can supply a power-point version (on request), also I have higher resolution images available.

SoftwareCosmos_Presentation_Notes and SoftwareCosmos_Presentation_Slides

I.e. write code in the wiki, configure the build similarly, i.e. which pages will be compiled. Modern wiki’s have configuration management built in, so bye bye svn, git etc. (ok, wiki’s don’t handle this well enough, but again this is an idea not a real product).

The environment by itself supports cross linking, so it self documents and people find it easy to document! The compiler and automated tests can update a build/test result page! With a little thought I think a wiki could manage code better than current IDE’s and integrate the social side. I guess execution of code might be an issue, but one which some more thought would overcome. Possibly this could be integrated into Google Wave?

It’s worth some discussion and further thought – Somewhere, off to bed!

By adding the scientific method I’m trying to demonstrate that simply inspecting and adapting isn’t enough, you need to know where you intend to go and have the ability to assess the true impact of any proposed changes.

Personally I’m finding the creation of these diagrams a useful tool for reflection and understanding, I’m approaching the point where a single canonical diagram could be made.

One key point related to software engineering – That I missed until recently, was the fact that process, material artefacts etc. are all just aspects of the software product, they represent the current paradigm, it isn’t possible to point at any of them and see the whole product, in fact nobody can, again you are staring into the globe of knowledge!

Enjoy the reflection.

Deep Structure & The Scientific Method

I will be starting to look at feedback next – The core (in my mind) principle within software engineering and one which is cunningly (or not so) disguised and dressed up all over the place. My intent is to describe the model of feedback and how changes alter it, then to look at all that LEAN, Agile etc. have built around it – For the most part a change in words and the addition of context (a word which crops up quite a bit).

I was lucky enough to find the initial (or as close as I could get) source. Version: 1.4.1 and commented “–Jim Aspnes, December 9th, 1989″. I eventually managed to get the code compiled again, it wasn’t too bad a job, hampered by the fact I hadn’t been near C for quite some time! After spending some time playing I noted that the accompanying documentation “Three’s Unabridged Dictionary of Commands” (Last Updated Thu May 31 13:37:43 CDT 1990) had commands which the 1.4.1 version didn’t recognise.

More trawling of the Internet… I found the Islandia source, last change comment: “–Michael Mauldin & Russ Smith, June 25, 1990.    1.5.4f”. This (after looking through the code) had the extra commands and a whole lot more “features”, wonderfully #defined in/out. Anyway, tonight I finally got this running, I suspect I need to revisit some of my changes, I whacked GCC up to maximum on the warning levels etc. and I probably perverted some of the logic on the way!

Its a shame, I cannot find the sweet spot of code where it had less adventurous features added, specifically in/around the “1.5.3″ version, ho hum. I guess it might be out there? Anyway, its running and I’m probably one of a small number of people who has seen its output since 1990, so here it is:

TinyMud: Islandia

Now I just need to play with it and see whether I should run the really early version or this. I’m so used to unit tests etc. I’m paranoid something is broken and the later code is really fragile. For now I will just sit with the warm glow of seeing a bit of computing history re-awakened.

Fundamentally we need principles and feedback!

This is starting to ring bells with my current journey into lean thinking and the roots of lean and agile. I’m beginning to think they all come back to these two items, at the micro or macro scale they all involve getting a feedback loop going (or developing an existing one), guided by some simple practices/guidelines. So, if I could think of a snazzy name for it I would start a new software development methodology(?) which consists of just these elements.

Get everybody nodding at the notion that feedback is the fundamental principle on which to operate, define or pick some simple practices/guidelines, choose appropriate information to analyze and use to modify the input, keep testing and evolving the system. It seems to me the only difficult part is seeding, some activities are easier than others, unit testing has this cycle and books to hand out, whereas getting say a monolithic waterfall development process changed when your say an outsourced part is harder – But I think achievable so long as you get them to agree feedback is good and start showing them some useful big visible charts?

This new methodology, is just really a principle, a foundation, on which lean and agile are built, so its a meta-principle or a deep principle? The bit I like is its really obvious (or it is to me now I see it) and cuts through all the endless material written on these subjects, allowing people to develop systems suitable for their needs. Essentially its all about continuous improvement, get grounded principles and iterate/evolve, apply this principle to anything (software or otherwise).

As mentioned in the trousers of reality, its all recursive and fractal in nature, I’m starting to sound a bit like an insane hippy these days, maybe I am! Here are my pictures: