Mopidy is
If you speak enterprisey:
a music integration platform
Slide 3
Slide 3 text
Mopidy is
A program that connects
all your music stuff,
so that you can use it from
any computer or smartphone
Slide 4
Slide 4 text
Six months
has passed
Slide 5
Slide 5 text
Changes
MPD server
From 40% to 80% complete
Now works 98% with most MPD clients
Spotify integration
From 2x 50% complete to 1x 80% complete
We've dropped despotify in favour of libspotify
Slide 6
Slide 6 text
Changes
License
From GPLv2 to Apache License 2.0
You are now free to build anything on top of Mopidy
Releases
From 0 to 5 releases
0.1.0 released August 23
0.1.1 and 0.2.0 in the works
Slide 7
Slide 7 text
Changes
Developers
From 0 to 3 active contributors
Users
From 0 to 5 active users reporting bugs
About 400 downloads from PyPI
Slide 8
Slide 8 text
Changes
Code
More than 1100 new commits
From 2700 to 6200 lines, including tests
Tests
From 200 tests in 0.4s to 550 tests in 0.8s
55% of the code is tests
Slide 9
Slide 9 text
Changes
Design
We still create the design as we walk
Refactoring early and often with the
confidence provided by the tests
Slide 10
Slide 10 text
The result
Slide 11
Slide 11 text
WARNING
The following script
actually works
Slide 12
Slide 12 text
1.Slide finger on Android or iPhone
Slide 13
Slide 13 text
1.Slide finger on Android or iPhone
2.Watch the volume knob on your
NAD or Denon amplifier turn
Slide 14
Slide 14 text
1.Slide finger on Android or iPhone
2.Watch the volume knob on your
NAD or Denon amplifier turn
3.Hear the sound of your music,
either from Spotify or local storage
Slide 15
Slide 15 text
Concurrency
Slide 16
Slide 16 text
We need to
respond timely to clients,
get data from Spotify,
play sound,
turn physical volume knobs through serial links,
all at the same time
Multiple processes
respond timely to clients (frontend),
get data from Spotify (backend)
play sound (output),
turn physical volume knobs through serial links (mixer),
all at the same time
Slide 19
Slide 19 text
Communication
Generally, parallell processing is known to be
hard to get right, and harder to debug.
These processes are not independent,
but need to communicate.
How do we manage this?
Slide 20
Slide 20 text
Solution
No shared state
Communication through
messaging
Slide 21
Slide 21 text
Solution
Actors reacting to messages
Multiple processes/threads (actors)
that are working together by sending
serializable messages to each other
Slide 22
Slide 22 text
Messages
The messages are
Python dicts
{'command': 'play_uri', 'uri': uri}
Slide 23
Slide 23 text
Messages
A message is a command with attached data
Think of it like a method call with arguments,
which can be serialized and passed around
Slide 24
Slide 24 text
Actors
The message reactors are if/else statements
(for now)
def process_message(self, message):
if message.get('to') == 'output':
self.output.process_message(message)
elif message.get('to') == 'frontend':
for frontend in self.frontends:
frontend.process_message(message)
elif message['command'] == 'end_of_track':
self.backends.playback.on_end_of_track()
...
Slide 25
Slide 25 text
Loose coupling
Ignorance is bliss
Most of our code is
ignorant of the concurrency.
We call regular methods,
which do the multiprocessing work.
Slide 26
Slide 26 text
Loose coupling
If we wanted to, we could replace said methods,
and make the processes run on different machines
Communicating over the network
Nice, eh?
Slide 27
Slide 27 text
Next release(s)
Last.fm scrobbling
Submit your played tracks to Last.fm
Multi-backend
Tracks from Spotify and local storage in the same playlist
OS X
Support intentionally broken in 0.1.0
Slide 28
Slide 28 text
Later
WIMP backend
DNLA/UPnP frontend/backend
REST WS frontend
with JavaScript client
Audio streaming over HTTP