Archive for the ‘Development’ Category

Comparision of 4 approaches to playing audio in iOS

Published by Rob on September 20th, 2012 - in Development

There are at least four different ways of playing audio in iOS.  Each has their own wrinkles and advantages. In this article I briefly compare and contrast some of the differences between the options.  For the TL;DR version skip to the table at the end which compares the approaches. (actually, to be honest, I’ve had this post in my drafts for a very long time, and just wanted to get it published. The body of the article isn’t as good as the table — skim the article and go to the table :) )

  • MPMusicPlayerController(using the iPodMusicPlayer)
  • MPMusicPlayerController(using the applicationMusicPlayer)
  • AVAudioPlayer
  • AVPlayer

 

The MPMusicPlayerController using the iPodMusicPlayer is the highest level player, and matches closely to the iPod.  The actual iPod music player can be accessed and used with the factory method:

+[MPMusicPlayerController iPodMusicPlayer];

The nowPlaying item property will expose the current playing item in the iPod when using the iPodMusicPlayer. Changes to the current item in your application will also update the main iPod music player.

To load your own music player with the same API, use:

+[MPMusicPlayerController applicationMusicPlayer];

In iOS 5.1 and below it is not easily possible to use the AVAudioPlayer to play items from the iTunes library.  While it is possible to retrieve the url for the object, it doesn’t really do what you want. When trying this you will see a somewhat unhelpful error:

Domain = NSOSStatusErrorDomain
Code = -43
Description = Error Domain=NSOSStatusErrorDomain Code=-43 “The operation couldn’t be completed. (OSStatus error -43.)”

The AVPlayer however, allows access to the  iTunes library, playing in the background, custom background behaviour, and playing non-Library audio.

Of the accesible API’s this is the most functionality.  For the hard-core/determined developer, there are lower levels to dig down into, but these 4 options provide a decent set of options to play audio in iOS.  The table below outlines the highlights.

iosMediaPlayer applicationMusicPlayer AVAudioPlayer AVPlayer
play library Y Y N Y
access iPod play location Y N N N
Play in Background Y N ? Y
Custom Background behaviour N N/A ? Y
Play non-Library Audio N N Y Y
No Comments »

Writing Beautiful RSpec Matchers

Published by Rob on September 4th, 2012 - in Development, RSpec, Ruby

thoughtbot have created a really nice set of custom matchers for RSpec.  The Shoulda matchers make writing tests for rails models beautiful and clean.

Shoulda matchers make it possible to write specs of the form:

1 2 
it {should have_many(:items).through(:order_items)}
it {should have_db_column(:description).of_type(:string)}
view raw gistfile1.rb This Gist is brought to you using Simple Gist Embed.

It’s easy to do this for yourself using the friendly matcher DSL that ships with RSpec. Let’s take a look at how.

In the simplest form, all you need to do is to call the define method, passing a name, and a block which in turn calls out to match. The simple case might be:

1 2 3 4 5 
RSpec::Matchers.define :be_less_than do |expected|
  match do |actual|
    actual<expected
  end
end
view raw gistfile1.rb This Gist is brought to you using Simple Gist Embed.

We’ve just defined a matcher :be_less_than which allows us to do the following:

1 2 3 
specify "5 should be less than 10" do
   5.should be_less_than 10
end
view raw gistfile1.rb This Gist is brought to you using Simple Gist Embed.

If we use the describe auto subject feature of RSpec we can also write:

1 2 3 
describe 10 do
  it {should be_less_than 11}
end
view raw gistfile1.rb This Gist is brought to you using Simple Gist Embed.

and

1 2 3 4 
describe 10 do
  it {should be_less_than 11}
  it {should_not be_less_than 5}
end
view raw gistfile1.rb This Gist is brought to you using Simple Gist Embed.

With that example we can see that we are getting close to the shoulda matcher syntax.  There’s still an extra level that helps make the shoulda matchers nice, chaining. Happily this is easy to do as well. The dsl provides a chain method.  The chain methods are called before the match, so you can use the chain calls to collect up additional information to validate.  Using our example above, we might want to add in an :and_greater_than chain.

1 2 3 4 5 6 7 8 9 10 
RSpec::Matchers.define :be_less_than do |expected|
  match do |actual|
    result = actual<expected
    result &&=actual>@low_value unless @low_value.nil?
    result
  end
  chain :and_greater_than do |low_value|
    @low_value=low_value
  end
end
view raw gistfile1.rb This Gist is brought to you using Simple Gist Embed.

This now will give us the ability to write:

1 2 3 
describe 10 do
  it {should be_less_than(11).and_greater_than(5)}
end
view raw gistfile1.rb This Gist is brought to you using Simple Gist Embed.

Unfortunately the default descriptions don’t quite work as nice when there are chains in place. You’ll find that you’ll want to write a description in the matcher definition.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 
RSpec::Matchers.define :be_less_than do |expected|
  match do |actual|
    result = actual<expected
    result &&=actual>@low_value unless @low_value.nil?
    result
  end
  chain :and_greater_than do |low_value|
    @low_value=low_value
  end
  description do
     result = "should be less than #{expected}"
     result += " and greater than #{@low_value}" if @low_value
     result
  end
end
view raw gistfile1.rb This Gist is brought to you using Simple Gist Embed.

Unfortunately the description doesn’t automatically get used in the error messages when the matcher fails, so you’ll want to specify a failure_message_for_should. Basing it off the description is an ok starting point.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 
RSpec::Matchers.define :be_less_than do |expected|
  match do |actual|
    result = actual<expected
    result &&=actual>@low_value unless @low_value.nil?
    result
  end
  chain :and_greater_than do |low_value|
    @low_value=low_value
  end
  description do
     result = "be less than #{expected}"
     result += " and greater than #{@low_value}" if @low_value
     result
  end
  failure_message_for_should do |actual|
    "expected #{actual} "+description
  end
end
view raw gistfile1.rb This Gist is brought to you using Simple Gist Embed.

Happily RSpec does the right thing with the should not description, so with the details above the matcher will be good. There might be a case where you want a different failure_message_for_should_not, which can also be specified.

That covers how to write simple reusable RSpec matchers to make your test code look as beautiful as your production code. Go ahead and try it yourself.  I’d love to see comments or questions you might have on this.

5 Comments »

A vocabulary for product licensing

Published by Rob on April 14th, 2011 - in Development

Getting a shared vocabulary for conversations is always useful. Here’s a pattern/vocabulary that I’ve recently been introduced to for thinking about software product licensing.

  • Product Key
  • License
  • SKU

Product Key

A product key is the cryptographic software control used to control who/what can use the software

License

A license is the concept encapsulating that a customer is allowed to use the software. A customer is licensed to use software. This probably aligns with the legal contract that is used.

SKU

The SKU/stock keeping unit is how sales people can talk about the product. They sell a SKU to a customer.

The customer licenses the SKU (product), and then they are issued a product key which enables them to use the software.

The precise definitions for product keys, licenses and SKUs is valuable when communicating between product, sales and marketing teams. The list above seems to work pretty well. Let me know in the comments if you’ve got better ideas.

No Comments »

A Version Labelling Scheme for Software Product Development

Published by Rob on March 31st, 2011 - in Development

Computer software typically has a . separated version number. These numbers have value in helping to understand which version is being used. There is a shared understanding that things go from the most significant part of the version to the least. Having some precision around talking about a version labelling scheme is useful for setting up product lifecycles and communicating the details of a product.

I’ve heard numerous ways of thinking about the build numbers, normally involving terms like major and minor. I’ve never quite been able to keep the terms and distinctions clear in my head, so was pretty excited to recently hear a different approach, which I’ll share below.

Version.Release.Modification.Build

In numbers this will look something like:
3.4.5.1234

The idea is:

Version — a major product version. Customers care and know about versions. Versions are where potential breaking changes might happen.

Release — a major product release. Customers will care about releases. New functionality and bug fixes are introduced in releases.

Modification — a publicly available bugfix modification to the software. Users should be able to safely move between modifications of a product without breaking things. Modifications are focused around fixing problems in software.

Build — the internal build number for the software. A build is useful for the unique identifier of the software by development. The build number will be incremented automatically by the build system. Typically an officially released modification will only have one build number.

Another factor to consider in the system above is that the first two numbers are typically controlled by the Sales and marketing arms of a company, and the last two should be controlled by engineering. In fact if the last two numbers are being done correctly they should be automatically incremented, not being changed apart from automated systems and well defined rules.

For the first sets of numbers, engineering should be able to suggest that new functionality should be increasing at least the release, but it is a sales and marketing decision as to how much of an increase these might get.

2 Comments »

A Thought On Dynamic Languages

Published by Rob on January 7th, 2011 - in Development

Reading http://www.codecommit.com/blog/ruby/monads-are-not-metaphors got me thinking on a tangent not related to the article. The examples start in ruby then move to Scala. Daniel points out the difference between some of the scala and ruby code which led me to the following thoughts.

Duck type code encourages reading the source of methods to see the type requirements of params. This is  a good thing.

For this to work well methods need to be short and well written, another good thing. While this doesn’t negate the value of STRONG types, it does make the case for dynamic languages better.

No Comments »

4 Tips from the Unix Greybeards

Published by Rob on September 28th, 2010 - in Development

So I’ve been using Unix for a number of years, and think of myself as relatively competent in using Posix based operating systems. I’ve recently had the great pleasure of working with a few guys who’ve been using Unix for longer than I’ve been able to read, and I’ve been able to add a couple of more commands that are extremely useful. It’s always great to watch a master using their tools, and to learn while working with them.

The commands below are a mix of ones that I’ve just learnt. I probably should have known these already – but they are lovely, and you need to add them to your arsenal.

  1. !!
  2. locate
  3. look
  4. xargs

    1. !!

    re-execute the last command.

    !! also has friends like !COMM where it will execute the last command in your history that starts with COMM.
    e.g.

    1
    !find

    will re-execute your last find.

    2. locate

    With a locate database setup, locate is magic. Think spotlight for the commandline.

    3. look

    The man page for look talks about it searching a file, then mentions about the default location being /usr/share/dict/words. The default location is the key for the best usage. It’s a great little dictionary for looking up how to speel words.

    4. xargs

    The most masterful developers that I work with have advanced beyond xargs to the next level, but for people continuing on their pathway to true unix mastery, xargs is a great tool to add in.

    I commonly end up using variations of find and xargs together to search the contents of files, or to find out information about a project. If nothing else, the command:

    1
    find . -name "*.java" |xargs wc -l | sort

    is your friend.

    Tags: ,
    4 Comments »

    Eleven reasons to use the Play! Framework for Java Web Development

    Published by Rob on April 10th, 2010 - in Development, Java, Play! Framework

    The Play! Framework is a great tool for rapidly building Java web applications. Play! takes many of the ideas from the dynamic languages world (Rails and Django), and provides them to Java web development. Reasons to conside Play! for Java Development are:

    1. Rapid development via a local development server that automatically compiles your java code for you. It’s amazing how good it is to develop like this, and what a difference the rapid feedback loop makes.
    2. A good clean MVC famework.
    3. Nice testing support baked in.
    4. A useful routing table to make clean urls easy to work with.
    5. A focus around REST, but no slavish observence of it.
    6. built-in simple JSON support.
    7. A good module framework with useful modules including a “CRUD” module, and a Scala module currently under development
    8. An interesting mix of Java class enhancement that makes it easy to work with code, and then have the enhancer provide some of the hard work for ensuring that multiple threads are handled well.
    9. Deployment to a range of platforms, including JEE Servlets (Play! 1.0.2 has been tested on containers such as tomcat, jetty, JBoss and IBM WebSphere Portal 6.1), and the GAE.
    10. Enhancements to the JPA which make it really easy to work with.
    11. An active and supportive community. There is the right balance between having strong opinions about the “Play!” way of doing things, and helping people to get things done.

    Play! makes Java web development fun and productive. The feedback loop is really quick, and much of the boilerplate code is removed. It’s well worth considering for any application you want to write in Java.

    Take a look at the video, and work through the tutorial to get a feel for what development with Play! is like.

    Tags:
    9 Comments »

    Notes on Installing the Connections 2.5 Pilot

    Published by Rob on November 24th, 2009 - in Development

    The installation of the Lotus Connections 2.5 pilot looks easy. Unfortunately the out of the box experience was not at all pleasurable for me. Here are some of the issues that I encountered while doing the install. I’m not sure how many of these were specific to my environment, but they did all hurt.

    1) Don’t install from a directory with spaces.

    If you download the pilot to your desktop and try and install from here, things will crash and burn

    2) Don’t expect the VM to be easily moved around networks

    I started my second installation on my laptop at home, then brought it to work. This crashed and burned.

    3) Use fully qualified hostnames

    While the installer said that you could specify a short hostname or a fully qualified hostname, the short hostname did not work for me.

    4) Connections 2.5 is RAM hungry

    1.5 GBytes is not enough 2.5 GBytes is. Not sure of the exact threshold for it to work, but I can confirm that 2.5 GBytes is enough RAM.

    2 Comments »

    Making the Home and End Keys work in Eclipse 3.4 on Apple Mac OSX

    Published by Rob on June 12th, 2009 - in Development, Java, OS X Tools, Tips and Tricks

    Hidden in the comments of the article of Starry Hope – Mac Home and End Keys are some instructions for how to make the home and end keys work well as begin and end line in eclipse.  I've done all the other tricks to make this work on my Mac, so was getting really frustrated with Eclipse.  double home and double end are common key combinations for me in IntelliJ and Eclipse on Windows, so the current behaviour of going to the beginning or end of the file drives me crazy.  The details of doing this differ slightly in Eclipse 3.4.1, so I'll list the steps I followed below.

    1. open the eclipse preferences pane
    2. general->keys
    3. in the filter type line start and note that there will be existing bindings when editing text.
    4. select line start type home, and ensure that the "when" field stays with Editing Text
    5. apply
    6. follow this process for select line start, line end, and select line end.

    After doing this, expect your anger at eclipse on Mac to decrease to much more manageable levels.

     

    16 Comments »

    Port forwarding with iptables and debain

    Published by Rob on June 2nd, 2009 - in Development

     

    Subtitle: 

    Avoid Remembering that VMWare Server Listens on Port 8333 

    Alternate subtitle:

    Make Tomcat Listen on Port 80

    It's increasingly common for applications to have web front ends.  These all tend to run on their own port, which is nice in that it stops services from running into each other (and means that they can run as non-root), but is somewhat painful in that there are always a whole heap of different ports to remember.  Exposing a service over port 80 makes it much easier to use (especially on ie which is dumb, and doesn't know to make requests to non standard ports default to port 80, generating much rsi, and many hours logged into the IE Waste Recorder).  Making services listen on port 80 on Debian is pretty straight forward.  Follow the process below (which I pinched from someone somewhere in the blogosphere a while ago, put on a server as a part of some work with SSH Tunnelling, and only remembered recently when we were getting some VMWare servers setup). So here is the script. In your /etc/network/if-up.d add a script with the following:

    #!/bin/sh

    PATH=/sbin:/bin:/usr/sbin:/usr/bin

    # Flush any existing firewall rules we might have
     iptables -F
    iptables -t nat -F
    iptables -t mangle -F
    iptables -X

    # Perform the rewriting magic.
    iptables -t nat -A PREROUTING -p tcp

    1
    --

    dport 80 -j REDIRECT

    1
    --

    to 8222
    iptables -t nat -A OUTPUT -o lo -p tcp

    1
    --

    dport 80 -j REDIRECT

    1
    --

    to-port 8222

    This forwards requests from port 80 to port 8222, and will work for local and remote requests.  I keep this in a script called /etc/network/if-up.d/firewall, because iptables is firewallish, and I believe this is the standard place for this to live.  Remember to chmod +x the script. 8222 is the http port for vmware, and will redirect to 8333 using https. By putting the script in the /etc/network/if-up.d it will automatically be run when the networking layer of your debian installation is brought up.

    As per the NewInstance post, this will work for Tomcat as well (Luigi put the iptables rules in a different spot, but that was in 2005, and /etc/network/if-up.d is the right place for this).

    So with the above iptables rules, it will be easy to make any service available on port 80.

    Tags: ,
    No Comments »
    © Rob@Rojotek