1972 Canada-Russia Summit Series Hockey Game 8: A Social Network Analysis Part One (1st Period)

The 1972 Canada-Russia Summit Series to some is a defining moment in Canada’s history. At the height of the Cold War, 28 hockey players went into a tournament thinking they it was an exhibition series that no one would take seriously. By the end, the 28 were defenders of Canadian hockey against the surprising hockey prowess and political power of the Russian bear. The final game, number 8 in the series of 8 was particularly dramatic. After a closely-fought first period, the Canadians fell 5-3 in the second, but came back to tie it in the third until 19:26 of the third period when Paul Henderson … well if you don’t know the story, you probably aren’t Canadian and don’t care anyway. Well, here’s the game on YouTube if you want to see more.

Game 8 is a good case for social network analysis centrality at work. A hockey game is a network where people pass a puck to and from each other over the course of 60 minutes. Each time the puck passes from one player to another, we can create a directed tie. We may also be able to make some statements about the game. For instance, is it more important to give or receive a pass from a diverse group of players? Who passes to the biggest passers? Who receives passes from them? Rather than going through all this preamble how about I just get to it?

The Roster

Maybe later I will add the last names, but right now I’m going with the numbers.  You can use this roster as a key to find your favourite players.

Team Canada

  • 02: Gary Bergman
  • 03: Pat Stapleton
  • 05: Brad Park (if it weren’t for Bobby Orr, the greatest defenseman of his era)
  • 06: Ron Ellis
  • 07: Phil Esposito (big goal scorer and captain of the team)
  • 08: Rod Gilbert
  • 10: Dennis Hull (Brother to Bobby)
  • 12: Yvon Cournoyer (The Roadrunner)
  • 17: Bill White
  • 18: Jean Ratelle (One of the great Rangers, amazing goal scorer)
  • 19: Paul Henderson (A very good player, but the hero of the series)
  • 20: Pete Mahovlic (Overshadowed by his brother Frank, but actually very good)
  • 22: J.P Parise (Great player, but got thrown out early for threatening to slash the refs)
  • 23: Serge Savard (Eventually became captain of the Habs)
  • 25: Guy Lapointe
  • 27: Frank Mahovlich (Big “M” – hero of the Toronto Maple Leafs)
  • 28: Bobby Clarke (was chosen last for the team, but brought the Broad Street Bully element to the game.)
  • 29: Ken Dryden

Team Russia

  •  02: Alexandre Gusev
  •  03: Vladimir Lutchenko
  • 06: Valeri Vasilev
  • 07: Gennadey Tsyganov
  • 08: Vladimir Vikulov
  • 09: Yuriy Blinov
  • 10: Alexander Maltsev
  • 12: Yevgeni Mishakov
  • 13: Boris Mikalov
  • 15: Alexander Yakushev
  • 16: Vladimir Petrov
  • 17: Valeri Kharlamov
  • 19: Vladimir Shadrin
  • 22: Vyacheslav Anisin
  • 25: Yuri Liapkin
  • 30: Alexander Volchkov
  • 20: Vladimir Tretiak

Getting the Data Using R’s iGraph Library

The data were created using edge lists separated by spaces. Here is a sample of what it looks like:

Off16 Can07 
Can07 Can23 
Can23 Rus26 
Rus26 Rus22 
Rus22 Can29 
Can29 Rus22 
Rus22 Rus26

A few things that may be added in the future are the times of the pass, goals, steals (although this could be calculated on its own), power-play information and so on. But for now, I just have the edge lists. The first entry is the “from” player (Rus=”Russia”, Can=”Canada” and Off=”Official / Referee”) and the second is the “to” player.  You can enter the information in to an R graph object pretty easily using iGraph. You can assign descriptive values to the hockey players (vertices) by using V(df)$description.  In this case, I’ve used color to easily identify the Russians from the Canadians in the graph plots (igraph will automatically plot the colors if there is a descriptor available).

library(igraph)
el <- read.csv("summitseries.txt", header=F, sep="") #sep="" means any whitespace
df <- graph.data.frame(el) # create a graph from the dataframe el

#Create a color vertex trait so that Russians are red; Canada is white and the Refs are black.
V(df)$color <- ifelse(substr(V(df)$name,1,3)=="Rus", 
               "red", ifelse(substr(V(df)$name,1,3)=="Can", "white", "black"))

Overall Degree

Degree refers to the number of different people a person passed/lost the puck to, or received/stole the puck from. It’s basically a count of the number of “sticks” for each ball.

The code to calculate the values is this:

V(df)$degree <- degree(df) 

Each player gets a value based on the total number of pucks received or sent.  To plot:

plot(df, vertex.size=V(df)$degree, layout=layout.kamada.kawaii)

This is what the graph looks like:

Screen Shot 2015-02-16 at 11.21.54 PM

This graph is not particularly meaningful, but it does offer a few insights. For instance, Phil Esposito (#7) was out a lot in this game and managed to both take passes away from the Russians as well as lose them. It kind of speaks to his garbage can approach to hockey – his play in this period, like most days was gritty and he found himself in the midst of almost every play. This also shows quite a bit of the classy Russian style of play with a lot of quick passes and fancy footwork. Almost every player on the Russian team had the puck quite a bit. Vladimir Shadrin (#19) is mostly ignored in the English world today, but he was amazing in this series, scoring more than even the Russian hero Valeri Kharlamov (#17) who barely shows up on the charts.

Out Degree

V(df)$outdegree <- degree(df, mode="out")

“Out” degree is the same measure, but only counting “outgoing” passes. These represent passes made or intercepted.

Screen Shot 2015-02-16 at 11.28.23 PM

Like I said earlier, Phil Esposito (#7) was finding himself giving the puck away quite a bit in this first period, but also making some pretty strong passes. Brad Park was also pretty busy. Both these guys happened to score goals in the period by the way. On the Russia side, Lutchenko (#3) and Yakushov (#15) are nothing particular special in the pass department even though they scored goals as well. That could be because the Russians were much more team players.

In Degree

V(df)$outdegree <- degree(df, mode="in")

Screen Shot 2015-02-16 at 11.51.10 PM

Not too much more to say about this one, except that it’s not too different from the outdegree measures. This is not that surprising given that if you have the puck either you are going to pass it or someone will steal it from you. I should also note that goalie Ken Dryden (#29) was pretty busy in this period. Not good for Canada.

Bonacich Power (Beta=0.5)

Now we can look at some eigenvector-like centrality measures. There are a variety of them, but I’ve decided to use Bonacich in this case. Bonacich uses a beta value that assigns a weight to the degree centrality of the neighbours. In the case of a positive value (cooperative networks), the more “passy” your neighbour, the more power you have. Unfortunately, this method produces both positive and negative values which is a little challenging for plotting.  So I have a little linear mapping function that I borrowed from here:

linMap <- function(x, from, to)
          (x - min(x)) / max(x - min(x)) * (to - from) + from

And then assign the values and plot.

V(df)$eigen <- bonpow(df, exp=0.5)
plot(df, vertex.size=linMap(V(df)$eigen, 0, 25)

Screen Shot 2015-02-17 at 12.16.15 AM

The picture is a little bit different in this case. Now we see the great New York Ranger, Jean Ratelle (#18) finding his way into the largest influencer position along with Bobby Clarke (#28). On the Russian side, Yakushev (#15), Karlamov (#17) & Mishakov (#12) find themselves in their rightful place as the elite members of their team. Phil Esposito, on the other hand shrinks to almost nothing.  Why? Well, he tends to find himself taking and losing the puck from defensive players more than picking up passes from his line-mates Yvon Cournoyer (#12) & Frank Mahovlich (#27).

Bonacich Power (Beta=-0.5)

V(df)$bonpow <- bonpow(df, exp=-0.5)
plot(df, vertex.size=linMap(V(df)$bonpow, 0, 25)

The picture is also quite different when looked at from a negative Bonacich power perspective. Usually negative bonacich power is used for networks that are competitive in nature, when it’s much better to have less powerful neighbours.Screen Shot 2015-02-17 at 12.17.12 AM

In this case, it’s pretty obvious that its the defensemen that have the least powerful as neighbours.  This makes sense because defensemen usually end up playing with a wider variety of forwards than other forwards do. Canada’s top defenseman, Brad Park, certainly found himself passing to and from the lesser lines in the first period, and likely stealing from Russia’s lesser lines as well!

Conclusion (for now)

This post goes to show that you can get a different answer from a social network analysis depending on how you decide to measure it. There are no mind-blowing revelations here (likely because the game was somewhat even at this stage) but still quite a bit of diversity among the different graphs that it gives pause. At the end of the day, this is why it is important to think clearly about your research question before you start looking at your data.  If you don’t, you’ll probably find yourself getting the answer you want just by rolling through different measures. I haven’t even gone through all the possibles – betweenness, closeness, clustering values and alpha centrality are all measures I’ve decided to leave out just for now (but may revisit later).

Another thing that might be interesting to look at is what the centrality values look like when I separate the Canadians from the Russians – from that perspective you could see how well the teams play with each other. Also, we could look at the edges where the puck changed hands from one team to another. In this case the negative bonacich power may be quite telling as per who was really coughing up the puck to the wrong people.

The data is not up in my git site yet, but I will share it eventually. I’ll keep the data open so that people can add or edit it as needs be. Certainly there may be problems with the way I coded everything. It was not always easy to see who was touching the puck. Sometimes I just had to guess based on position and the usual line-ups.

Six Ways to Do a Presentation

People get anxious about making presentations. There are ways to manage this anxiety, but part of the reason people have this anxiety is that they think there is a formula for a “good” presentation and that they have to somehow fit the mold of that formula. It’s kind of like trying to be a rock diva without the sequins or a tech guru without the black turtleneck and jeans.

Too bad for these people that they watch too much mainstream news.

The reality is that the “good” presentation format is only “good” because a whole bunch of people have packaged it into a brand of sorts. People who are not part of that club have to think of other ways to get their message across. If you are doing a presentation for the first time, chances are your audience is not everyone in the world. More likely, you have a smaller niche audience with more specific needs. That means you have to think about your presentations a little bit differently. While I can’t give you a strict idea about how to reach  your audience in the right way, I can offer ten ways you could do a presentation and see if this gives you an idea about how you might approach yours. Here they are:

Lecture with Script

When you have done a lot of research, it is easy to get nervous about the details. Do not try to explain a mathematical algorithm in the middle of a presentation. You will draw a blank. Instead look to a script. You do not need to follow it 100%, but scripting it can help you get through the details without making a mistake. Tanya Boza has some interesting things to say about being a good lecturer, but advises against using a script. Well, I say scripts have their place depending on the situation. Although Tanya is right – it is much better if you can use your script without looking as if that’s what you are doing.

ADVANTAGES: You can script the details. Will go off very well if you are a good writer. Tends to be formal, and usually rhetorical. Great if you are a politician or have to explain things in a very specific way so not to offend people.

DISADVANTAGES: Can be boring and/or un-engaging. You can lose personal contact with the audience if not rehearsed well. Can be over-prepared. Difficult to do ad hoc presenting within a script.

Lecture with Notes

If you are teaching a big picture concept without getting into the details, it may be better to go without a script. Instead, just quick notes will do you well. This is especially good if you have props to show, are teaching English, expect questions about the material. Johnathan Fields gives a great overview of how Martin Luther King used improvisation in his speech and changed the world.

ADVANTAGES: Great for an overview topic. People may feel more comfortable to ask questions. Good for abstract concepts that are hard to display visually. Excellent for people who like to perform and/or do improv. Can be especially good for a dramatic topic.

DISADVANTAGES: Tends to cover topics too generally. Information can be hard to retain if the lecture goes on too long. Can appear disorganized or unprepared, especially if people ask for details.

Power Point Presentation

Like it or not, the Power Point is a mainstay for presentations. I wish generally that we would not rely on it so much, but so be it. The key to remember is that power point should be a support and not a crutch. However, if you are so nervous about presenting that power point is your crutch, I have a few tips to offer you on the issue.

ADVANTAGES: Great for people with an eye for design. Visuals can really help support the topic if done properly. Easily shared on the Internet. Best option for sharing graphs and charts.

DISADVANTAGES: Waaaay over done. Gets tedious if the visuals are uninteresting; gets distracting if the visuals are overpowering. Appears “salesy” at times due to its prominence in the field of marketing. People ask you for your notes so they don’t have to watch the lecture.

Present Over Sound

It’s not often thought of, but it can be very effective to use sound to illustrate a point. This is the essence of podcasting, in fact, although sound does not have to be digital. If you have your own instrument, that can be even more fun. Take a look at Anna Russell explain Wagner’s Ring using music, for instance:

ADVANTAGES: It is not using powerpoint. Sound is a great way to describe emotions, tension etc. Obviously it is excellent for showing music. It’s an excellent way for musicians to show their talents while making an argument. Very effective with visuals, perhaps removing the need for a script or notes.

DISADVANTAGES: Requires a lot of preparation. Can be distracting to try and speak over a music set. Queues can be missed, causing awkward breaks in the performance.

Q&A

I once did a presentation by simply asking the same question in three different ways. This may seem lazy (and it is) but the reality is that the audience collectively often has much more information and knowledge than the person speaking.

ADVANTAGES: Almost no preparation required. You need an eye for facilitation to ensure as many voices as possible are heard. Crowd wisdom often brings amazing insights.

DISADVANTAGES: Need excellent questions. Always the threat of no one having any thoughts (although this is rare if you are patient). People looking for something unique will often be disappointed. Can come off as overly “new age” or maudlin. You need to be comfortable with a bit of awkward silence.

Structured Alternatives (AKA “Large Group Methods”)

There are a variety of presentation structures that can open the door to more audience participation. Fish Bowls, Talking Circles and World Cafe are some examples, although there can be many more.  These can range from very easy to facilitate (talking circle pretty much just needs a stick or other object to make happen) to very challenging (World Cafe is pretty complex to organize). Either way, they all represent different ways of providing something a little different from lecture-style.

ADVANTAGES: Can be very inspiring. Can open up some voices who otherwise would not want to speak out. Self-coordinating while happening.

DISADVANTAGES: The structures can be a little difficult to explain. Not everyone is free to be honest and open, so these styles can leave them vulnerable. There can be a “musical chairs” kind of effect, so you need to be comfortable with moments of chaos.

So here are six examples of alternative styles of presentations that you can offer your audience. Not everything has to be a power point! What kinds of presentations have you encountered that seemed just a little outside the box?

Part III: How Haskell Monads are Like a Muppet

< Part II: How not to Start Your Haskell Program Part: IV:  If This is a Case of Functional Programming, Then I Am Switching to Lazy Evaluation >

In previous tutorials, I talked about some assumptions about Haskell programming, and how to overcome them.    I suggested that someone coming from an imperative background (more than likely) is going to go about functional programming all wrong.     I fretted that no one creating documentation for Haskell seemed to notice this and that this was a problem for the future of Haskell and functional programming in general.

Non-academic coders want to make their programs *do* something as soon as they can.      Academic programmers are more fascinated by making their code solve complex problems.     Making Haskell do something is possible, but you’d never know it by reading through the documentation and most tutorials.    Here I will make our Haskell program actually do something, all the while giving an inkling about how state monads / MVars / IORefs work (without ever bothering to explain the math-ese behind them).    Again, I am assuming you’ve read and have been confused by at least one or two tutorials on the subject.

Because imperative programs rely on mutable variables (of which functional programming has none), programmers usually start by creating controls mechanisms (eg. an array in php) to prevent mean side effects from creeping in to their software.    Functional programming does not have side effects.    That’s good.   However, it also does not have the ability to store values inside a variable.    That’s bad.   That’s why I suggested starting with input and output and filling in the gaps.   Then I gave a sample:


main :: IO() main = do
                        x <- getChar
                        if x == 'q'  then putStrLn "Thanks for Playing"
                            else pmove x >> main  

move :: Char -> String
move a
    |  a == 'w'       = "UP!"
    |  a == 's'       = "DOWN!"
    |  a == 'a'       = "LEFT!"
    |  a == 'd'       = "RIGHT!"
    |  otherwise      = "HANG AROUND AND DO NOTHING!"  

pmove = print . move

So far, this program doesn’t do much more than a basic “Hello World!” program.     It accepts an input that get stored in x and based on that input it prints out a word.   Pretty disappointing.   What we want is the ability to change things.    What would be really nice is graph coordinates indicating a plot on a map, for instance.    Then we could establish our character’s position that could be displayed graphically and used to analyze the characters position against (say) a wall, or a monster.   Then the real fighting can begin.

Except you can’t really do that.    If you create a variable ‘place’ that contains a tuple (5, 5), it will always be (5, 5).   Your character is stuck in the quicksand!

You *can* create a function ‘up’ that will increase the ‘y’ value when your user presses ‘w’.    Maybe it’s something like this:

up :: (Int, Int) -> (Int, Int)

up x = (fst x, (snd x) + 1)

However, you are still stuck because you have no declaration of a starting point unless you declare a variable.    If you declare a variable, then your starting point is unchangeable, so you can only move one spot and no more!      This is where you start questioning if Haskell is just some practical joke that some prof wanted to play on his or her students.   In academic terms, this is the ‘problem of state’ and is one of the main reasons why functional programming has not had much influence in its first 30 years of being in existence.

To avoid a surprise ending, the solution is actually to create an MVar, which means ‘mutable variable’ and can be found in the Control.Concurrent.MVar module.    But I am getting ahead of myself.   An MVar isn’t exactly a mutable variable, although it does a really good job at pretending it is one.   Let me use some of my mad working-with-kids librarian skillz to show you how it works.

Grover is a Monad

Since you are somewhat familiar with the Haskell tutorials, you know what a monad is.    You are also a little bit confused at how it works.   I am not going to explain it.   It’s too mathy.    Much better to talk in Muppets.     I like to read a book called Grover’s own alphabet to my kids.     In it, Grover moves his arms and legs around to shape himself into all of the letters of the alphabet.     Believe it or not, this is your solution to the mutable variable problem.

As discussed, I cannot create a function that will store a value in a variable that can be changed later.    However, I can ask a function to return a type.    I can call this type “Grover.”     So, if I’m looking for a letter of the alphabet, I can ask Grover to move his arms and legs so that he is in the shape of a letter, let’s say “G.”    He will stay in “G” until I ask what shape he’s in.     Once he says “I am in shape G”, then he will stand up straight (no shape) until I ask him to take another shape.   This is basically how Monads (more specifically, state monads) work.

(Incidentally, the idea of using Monsters as an example of the Monad type is not new.)

Now is the hard part – going through the documentation.     I am going to save you alot of time.   For our Rogue-like game, we need MVars.    Before figuring this out, I had to go through a whole lot of confusing reading and mess.     If you want some pain and suffering, look up the State Monad, State Transformers, IORef, Arrow notation and the like.    Now look at what you really need.   MVars.    Go ahead and read the documentation on that.   You’ll find out that MVars are used for supporting concurrent processes.    Then you’ll go back to IORefs because this isn’t a concurrent program.    That’s a pointless exercise – IORefs are unnecessary.    And, hey – maybe our Rogue-like game will need to be an MMORPG down the line, who knows?

Here is the code.      I will go through it in more detail in the next tutorial later, but basically this program will start with x = 0 & y = 0, and output a location or a message depending on what you hit on the keyboard.     Note, however, at this stage that you’ll need to hit ctrl-z to make the program stop.



import Control.Concurrent.MVar
import Control.Monad

main = do
           x <- newEmptyMVar
           y <- newEmptyMVar
           putMVar y 0
           putMVar x 0
           forever (do
                    char <- getChar
                    if char == 'q' then putStrLn "Thanks for Playing!"
                        else if char == 'w' then up y >> output x >> output y
                        else if char == 's' then down y >> output x >> output y
                        else if char == 'a' then down x >> output x >> output y
                        else if char == 'd' then up x >> output x >> output y
                        else putStrLn "you did not type a correct entry")

up, down, output :: MVar Int -> IO()
up y =  do
             v <- takeMVar y
             putMVar y (v + 1)

down y = do
             v <- takeMVar y
             putMVar y (v - 1)

output y = do
             g <- takeMVar y
             putMVar y g
             putStrLn (show g)


It’s not the prettiest code in the world, but that’s how you have to do it with Haskell.   Start out ugly, and make it pretty as you go along.

Part II: How not to Start Your Haskell Program

< Part I: Is There a Such a Thing as ‘Real World’ Haskell? Part: III   How Haskell Monads are Like a Muppet >

My last Haskell post had me thinking that I might as well create a really bad tutorial outlining my own strategies to deal with Haskell in the real world.    Some of the issues I outlined were:

  • Tutorials for Haskell focussed on solving problems, rather than getting it to ‘do stuff’ which is what alot of users expect from their computer software.
  • Haskell is emerging as an important player in the future of code.   Both as a type of code itself and as a way of improving skills in such languages as Java and Python.   However, it will not make the mainstream unless ‘regular folk’ start using it.
  • Functional programs (in theory) are apt to be more sustainable, less buggy and more consistently documented.   Regular folk, working with imperative and/or objective and pseudo objective languages probably don’t realize this -> not until their code breaks and they have to re-install the wheel.

While I have some experience in other languages like Ruby, and Python, I’ve decided to approach Haskell as if I were a PHP developer instead.     There are some very good reasons for this:

  • PHP is a ‘do something’ language.    Basically, it takes dynamic data and outputs it to a web page.   While math problems and recursion-like methods are possible – it’s usually input and output (ie. taking data in and out of a MySQL database) that is the most important.    Anyone expecting to use Haskell for primarily I/O related stuff is going to die from frustration.
  • PHP code can get very messy, even in the hands of an experienced coder.   Documentation of code is all dependent on comments and external manuals.     Haskell can help your average PHP coder, because its type-system offers a kind of in-source documentation.
  • PHP is a ‘regular peoples’ code.    It is adopted by alot of people with varying skills and experience with computer software, many of whom have very little understanding of its long run limitations.
  • Well into its 5th release, alot of the work has already been done for your average PHP coder.       It’s almost not even necessary to create your own objects and functions with all the pre-created libraries available.     Unfortunately, it’s also widely assumed that you are going to create a web application ->  what if you want to turn your code into an App?    or a desktop application that uses data from a php created api?   or an intense web universe ala Second Life or World of WarCraft?
  • As an interpreted program,   it’s pretty simple to solve problems through trial and error.    Just keep hacking away at php, and eventually you can make some convoluted function do what you want it to do (in an unscalable way, of course).

I am also going to make a number of assumptions:

  1. That you have read through at least some of the Haskell Wikibook.    I do not intend to explain what a Monad is, or impress everyone with my knowledge of complex mathematical theory.    This tutorial is an inquiry about how to approach a Haskell applications, not learning Haskell itself.
  2. You have a fair knowledge of some imperative-style computer language (possibly PHP).

As suggested, I am going to look at developing a one-level ‘rogue-like’ RPG game.      If I were to start such a game in php, I might start with something like:

$playerChar = array ("name" => 'Bob', "class" => 'fighter', "STR" => '18', "DEX" => '14', "WIS" => '11', "INT" => '15');

I suggest this because PHP coders want to get to the action as fast as possible.   The PHP coder (let’s call her PHiP) will know that her first problem is making data output in some consistent manner, so will create a variable that mimics a possible set of data that will eventually be displayed to the screen (likely a webpage).   Knowing that things like the name and class of the character will change, PHiP will put some variables inside the array.    Then PHiP will include some other ideas about what a character will need, and a print_r statement to watch the action as she lashes out blindly for the right outputs:

$playerChar ['traits'] = ("name" => $name, "class" => $class ...); $playerChar ['equip'] = ("weapon" => $weapon, "armour" => $armour ...); print_r ($playerChar);

If you are a Haskell coder, you probably already see countless disasters in store for PHiP if she uses this approach with Haskell.    Here are a few:

  • variables in Haskell are always constant.     Once called, the values will not change.   Believe it or not, functional programmers will see this as a good thing (see side effects in Wikipedia).
  • playerChar [‘traits’] would be seen as a function with an input [‘traits’] that, using Haskell syntax, is a list containing one string value ‘traits’.   Haskell would be wondering what to do if it encountered other lists containing one or more other string value(s).
  • All of the variables inside the associative array $playerChar  are irrelevant in Haskell.  Unless they are constant.
  • Deciding what to do with the array would be overwhelming.    A list could be used, but would require that all values inside be strings.   Or it could be a huge tuple of various kinds of values, or a list of tuples.
  • Without being sure what types of values are needed to create the playerChar, there are almost sure to be problems letting PHiP’s player character switch its weapon from a sword to a mace and back.

In short, PHiP is using the wrong paradigm to code effectively in Haskell.    The issue is not a problem of syntax, or even understanding a problem.   The issue is the approach.

As the tutorial goes along, we will deal with PHiP’s player character.    But, to work in Haskell, I propose that you do not start with the data you want to put in and out.    Instead, you start with input and output itself – inside main – like this:

main :: IO() main = do x <- getChar if x == 'q' then putStrLn "Thanks for Playing" else pmove x >> main move :: Char -> String move a |  a == 'w'       = "UP!" |  a == 's'       = "DOWN!" |  a == 'a'       = "LEFT!" |  a == 'd'       = "RIGHT!" |  otherwise      = "HANG AROUND AND DO NOTHING!" pmove = print . move

Right now, this code is pretty useless, but it offers a few nice things to help make sure you don’t lose steam in your coding.

  • It creates an output that will work (sort of) like PHiP’s print_r string.
  • It offers a practical demonstration of point notation, which, in laymen’s terms creates a function pmove that prints (using print) the results of move.    Essentially, it keeps me from having to write “print (move x)” all the time.
  • I accepts an input ‘a’ that is a character.
  • It creates a strongly typed function ‘move’ that takes a Character and returns a String.   As we move forward, we can chain a series of functions together that will help PHiPs make her Haskell program to do more interesting things such as fight a monster.

(as it turns out, this code works slightly differently in Windows than it does in Linux.    Use the Linux version, because it makes me seem a little more competent.   If anyone can explain why Windows wants the CR for the getChar command, please  add it to the comments.)

I am not absolutely sure this is the very best approach to a rogue-like game, but I can guarantee it is better to start this way than it is to begin with creating variables.     As you read this tutorial, I hope you continue to use other documentations elsewhere to help you get your mind around my use of ‘do’, ‘getChar’, ‘putStrLn’ and guards ‘|’ here (pretty rudimentary Haskell code right now).

The next tutorial will look at shaping our dungeon and establishing where our player as he or she moves across the board.

Incidentally, as of writing this, I am working on a rogue-like game with my son called Rasghiosse (my son named it).    I have a public Darcs repository on Patch-Tag that you are free to join in on if you like.   As of writing this tutorial, I am not much further ahead than the above code, so I would appreciate your help.

Why “The Clash City Rockers” is a Well-formed Song

UPDATE:

It seems that I converted Mick Jones to librarianship after this video.    (Yeah, that’s the ticket.)   Actually, he really just opened up his own collection to the public library.   Bottom line is, Mick understands the importance of making knowledge of all kinds and formats available to the public.   Thanks Mick!

(July 3, 2009)

A long time ago, I used to be a Tutorial Assistant for a Listening to Music course put on by Adrian Hoffman.   Usually at the time when we discussed the “Classical Era” (ie. Mozart, Haydn, early Beethoven) there was a lecture on form.   Often, form was expressed as a tool for absolute music (ie. how to give a song a structured feel to it).    I always itched at doing a lecture on how form can impact program music (music that tells a story or paints a picture) – and especially I wanted to do this lecture using a piece of popular music.

So I did an explanation of form using “The Clash City Rockers” by The Clash.   I should note that I believe that the brief samples I use here qualify under fair use policies, in particular because I am using them in a tutorial about music, adding considerable amount of my own knowledge and material in the process.    Got any other good examples of how the form of a rock song really suits the lyrics/content well?

UPDATE:

You can go through all the verses of the song and perform the same exercise, actually.     Third verse has “everybody gone dry” on the “down” section” and “plug into the aerials that poke in the sky” in the “up” section (sky/up works really well, don’t it?).    Then, the suburbs are down, and the “you won’t succeed unless you try” get the up.   Very simple “up-down” technique that does alot to help the song makes sense.   I’m always impressed when I see this amount of craft put into a song.

UPDATE July 5, 2009

Just watched this with my wife and must admit that the front needs considerable editing.   (yeah, I’m babbling alot about whatever and whatnot – I think I couldn’t decide whether this was a video blog post or a tutorial on music).

Skip to about 1:30 to get to the fun part (where I use the “W” to show how the song is well-formed).   I’m going to spend some time editing this down shortly and I’ll repost it.

Doing a 15 Minute Presentation in 10 Easy Steps

Thanks Formication!Presentations are not easy to do well even if you are a designer or professional speaker.   Understanding your audience, having a catchy topic, being loud enough to be heard are all things that require practice.    Designers and professional speakers have the bonus of experience (and pre-set slides) on their side – you probably do not have any of the above.

After the Computers in Libraries conference, I got to see all kinds of styles of presentation.   There is one style that always stands out, no matter what.   I like to call it the “Scatter-Drone.”   That is the presentation that has 50 bullet points scattered on every slide with a long-winded drone of a voice wavering in the air saying something, but nobody really knows what because catatonia has already taken over.

 

There are simple things you can do to prevent being a total bomb in your presentation, though.   Here is one step-by-step process you can use to create a half-decent 15 minute presentation out of your typical Scatter-Drone.

What Do You Have to Say?

  1. Create 12 blank slides using your favorite presentation software.   
  2. The last slide should say “questions” or have a nice question mark graphic on it.
  3. The second slide should provide an agenda consisting of three sections.   Nice if you can offer a “promise” – something that you can assure will be worth taking away from your presentation.
  4. The third slide will offer three “big picture” points — you will repeat these things three times throughout your presentation.
  5. Fill in the rest of the slides with as many bullet points as you want.

How Will Your Audience Understand You?

 

  1. Print off your presentation as is.   Yes, it does stink right now – now you must fix it for your audience.
  2. Think of a single word or phrase that describes each slide (remember, each probably has 5-6 bullet points).   Go to Flickr’s Creative Commons and use that word or phrase to find a picture that will suit the bullet points you have on your slide.   Replace the bullet points with your nice picture.   As you put your pictures onto the slides, take a look at how other people do their presentations and adapt accordingly.   I appreciate that you are not a designer – but grab some ideas from people who are.
  3. Use the original presentation print-off (the one with all the bullet points) as your notes and the slide show with the pictures is what your audience will see.   Now you can just “read your slides” without anyone ever knowing that that’s what you are doing.

 

Feeling Confident and Prepared

 

  1. Start by acquainting yourself with the audience somehow.   Poll them.   Ask them what they expect from you.   Crack a joke to test their level of seriousness.   Maybe even throw them a bit, by offering an alternative presentation style.
  2. Give yourself an idea of where you are going to repeat your three key messages.    You should do this somewhere in the middle (slide 7 or 8) and again near the end (10 or 11).

 

That’s it.   A generic procedure for creating a half-decent presenation if you are not a designer or professional speaker.    It’s not too difficult to get a passing grade from your audience.   Remember, the audience *wants* you to present well and share your ideas in a meaningful way.   It just takes a bit of preparation, and some way of getting feedback from your audience.

What is a Database, really? Data Storage for Librarians

When a librarian talks about a “database” he or she usually means a website that will let you search for information not normally found in Google.   A techy would probably correct on this and say “actually, Google is a database too.”    And a real pedant would say something horrible like “actually, both of you are wrong.   What you are talking about are interfaces that USE a database to store, modify and retrieve data.”

*** Yawn! ***

The problem is that we have jargon based on jargon that gets passed around until it means nothing to nobody.    Here is my attempt to explain my pedant for you, and I will do it by answering the question:  “What are my options for storing data?”    Ooops, I’m hearing my inner pedant again.   What are my options for storing electronic data?” would be more precise.   Then I will explain why a relational database is one of the best options available for doing so.

So, how can you store data?   Here are the options:

A Text File

Good old text is still not a bad way to store data.   In fact, if you count scripting code like PHP, a heck of a lot of data is actually stored as plain text.    It’s all pretty simple.   You type some information in a text file and then save it on your harddrive.

If you want to retrieve that information, you can use a script to tell the computer to organize the information in a particular way.   This is called parsing aka manipulating data according to specific rules.

There’s only one problem:  you need ways to separate some kinds of information from others.   Here are some possibles:

  • spaces — this is not bad, except you will not be able to distinguish phrases from plain words.  (eg. “cracker jack in the box of tissues” parsed using only spaces would not help us make sense of the data).
  • commas — this is precisely what csv (comma separated values) does — separate each data cell with a comma.
  • indents/carriage returns — this is slightly better than the others, but still quite inadequate.   How will distinguish a paragraph from a list of things, for instance?

Text is good for basic data storage, but it does not give us much flexibility in its use.   For instance, what if we wanted to classify the data into groups like cats (siamese, manx, tabby)?   In order to do this, we need a more complex structure.

Structured Text

As you climb the data food chain, complex systems get developed to organize information.   Basically, this means you use symbols to help a computer understand how the data can be structured.   There are many subsets to structured text.

  • Mark-up:   Marked information is data that has marks or signals to let a computer distinguish one type of data from the other.   Python and C computer languages use a # to indicate that the information in the line following is intended to be read by humans only.  Javascript Object Notation (JSON) uses quotation marks to encase data, and squiggly brackets {} to show datasets that should be grouped.
  • A variable:   A variable happens when you give some data a name.   In PHP, $pie = 3.14; would assign the value 3.14 to the name “pie” which could be manipulated later on.
  • A string:   A string is a kind of variable that has text.   For instance in PHP you can say $myName = “Ryan”;.
  • An array:   An array is a type of variable that includes a list used by computer programs for later manipulation.     $myBooks = array(“the blue one”, “the red one”, “the yellow one”); would provide a numbered list that could be manipulated and organized.
  • An object:   Explaining objects in full requires that someone read up on object-oriented programming.   But one thing you can do with an object is store a broad taxonomy like animals->[cats->[siamese, manx, tabby], dogs->[collie, poodle->[toy, miniature, standard], doberman]].

Tree-based  Structures

Tree-based structures, or cluster models are a subset of “structured text” data storage models.   XML is probably the best example.   In tree-based stuctures, data is organized in “parents”, “siblings” and “children”.   Library-thesaurus addicts might understand these better as “broader, related and narrower” terms.   Take the following code:
<libraries>
   <library>
     <libraryname>Halifax Public Libraries</libraryname>
     <librarybranch>
       <librarybranchname>Alderney Gate Library</librarybranchname>
     </librarybranch>
   </library>
</libraries>

In this example, “librarybranch” is a child of “library” which is a child of “libraries.”  Conversely, “libraries” is the parent of “library” and so on.   If I wanted, I could add another child “library” within “libraries” and call it “New York Public Library” or “Ann Arbor Library” or whatnot and then add some respective branches.

The benefit to this kind of framework is that I use an XML parser to extract information such as “tell me all the branches of libraries that begin with the letter “A.”   It is useful because the information is grouped into nice categories (like “Libraries” and “branches”).

The downside to all this is the sheer verbosity of it all.   Say I add a parent to this tree file and call it “organizations.”   Then I add a whole list of other organization types like “hospitals,” “businesses,” and “schools.”   Depending on the scope of my data, this file could be huge in size and, even if you just want to find information about “libraries” you’d have to load up the entire file everytime you did a search (yes, programmers, I know there are ways around this, but they are generally quite complicated ways).

Also, tree-based structures do not always account for data anomalies.   For instance, a library could be a branch department in a hospital, business or school.   So, do you put the “library” underneath “school” or leave it on its own.   Or maybe you do both?    Ahh– but then you have to spend alot of time maintaining data in two, three or even more places.   In database terms, this is called redundancy.

The Relational Model

The relational model is better than a tree-model when your dataset is large and complicated.    The way it works is, instead of thinking in terms of “parents, siblings and children,” you think in term of relationships.   This provides alot of flexibility for your database design, and helps to reduce the amount of “places” where you will have to keep information updated.

How does it work?

I won’t go too far into database design, but there are some basic principles.   The first is called the “Primary Key.”   This means that every data object (such as a library) has a way of identifying itself in a unique way (usually through a number).    The second is called a “Foreign Key.”    The Foreign key is a way to associate one dataset (eg. libraries) with another dataset (eg. library branches, hospitals or businesses).   This association is called a relationship.    Once each entity/data object has its own unique identifier, you can make just about any relationship you want, either by creating a foreign key within your table.

Take the example of this table I’m going to call “Libraries”:

| ID   |  Type            |   Name                   |
______________________________________________________
| 1    | 1(public)        | Halifax Public Libraries |
| 2    | 1(public)        | New York Public Library  |
| 3    | 2(academic)      | Dalhousie Killam Library |
_______________________________________________________

And a related table “libraryTypes”:

| ID   |  LibraryTypeName            |
_____________________________
| 1    | Public                      |
| 2    | Academic                    |
| 3    | Special                     |
______________________________________

By using the unique identifier from table “LibraryTypes,” we are able to create a relationship between a library and a libraries purpose or type.    Once we have this relationship established, any data we include in the “Library Type” table, will automatically be associated with the library.   For instance, we could add a bit of data that defines what an “academic,” “public” or “special” library is, or define library associations that support/govern them.    Then, everytime a library is called “public” all the information pertaining to the “public” librarytype also belongs to that library.   This really helps reduce the amount of maintenance required for updating your database.

In more complicated relationships (called the Many-to-Many relationship), you might have to create a third table to associate two entities.      I won’t go into this too far, but the principle is the same — you create relationships among entities using the unique identifiers among the tables.

Within the relational database model, there are at least two different kinds of databases:

TEXT/XML Based

Text files can be organized in such a way as to accommodate some of the benefits of the relational model.   This is done by constructing keys within the XML files and associating two or more files together.    Once very popular, this is not very common anymore.   The advantage of this model is that text files are quite easy to share with others across a network.   Text files are also readable by humans.    The disadvantage is that, because the computer has to parse the text as well as compute the relationships among files, text models tend to be slower to operate, update and maintain.

Two examples of XML-based databases include Xindice and Sedna.

SQL/Binary-based Databases

The more common relational database type is a piece of software running on a server, rather than a set of text files.   They are generally accessed using a standard language called SQL (Structure Query Language), or more specifically SQL as supported by a popular scripting language like PHP, Python or Java.

What you choose in terms of an SQL-type database will depend on your needs.   Here are some examples of popular Open Source databases and why you would use them:

SQLite:   SQLite is excellent for a database that is updated by only a few people.    It is the simplest of all SQL database types, requires very little configuration and is stored in a single file, which makes it easy to backup, secure, share and manage.   Also, it is a public domain database, meaning there are hardly any restrictions on how it can be used and/or modified.    It’s major drawback is that because it comes in a single file only, it will not permit many updates from different people.   In short, SQLite would be horrible for a large scale wiki project.

MySQL:  MySQL is probably the most popular of open source databases.   It takes a little more effort to configure on a server, but it also provides more power for people to manage and update information.   MySQL handles multiple updates easily, so it is the database of choice for most CMS systems, including wikis.   THe Koha ILS uses MySQL as well.

PostgreSQL: PostgreSQL is the most powerful of databases IMHO, providing just about everything MYSQL does, with some added back-end configuration options that make it better for maintaining very large projects.   I highlight this one because it is the database behind the PINES Evergreen projects. 

 

Final Thoughts + It’s Not All Mutually Exclusive!:

This intention of this article has been to identify the ways data can be stored and to explain a little about why the Relational Database Model is so important.

That said, I neglected one important thing.   Almost any major web application will have a combination of all these types of data storage methods!    For example, a website may store its data in a MySQL database, but offer part of that database in an XML file that can be accessed by other websites.   This is called a “Web Service” or, more popularly, an API.    Configuration information for servers and computer languages like PHP is almost always stored in a plain text file.   In short, each data storage method has its own benefits and sacrifices — and that’s why it’s almost always better to diversify your data storage method.

Finally, for those who are interested in learning a little bit more about how a relational database works in the real work, I recommend the SQLZOO tutorials.  They cover SQL in pretty straight-forward ways, covering a wide range of services from Oracle to SQLlite.

Search Engine Optimization (SEO) Tips for Libraries

After seredipitously encountering an Search Engine Optimization (SEO) victory (my wife searched for events happening on a major street in my city and our events page turned up #1), I’m feeling pretty good about the library website.   That does not mean that we cannot improve however, so I thought I’d blog about it a bit.

Now, I am not going to cover the basics of SEO, because there are plenty of resources out there that can help with these things.   If you have money, maybe you’ll want to spend some on an SEO consultant who understands the basics.

But even if you hire an SEO consultant, you still need to understand the basics of website architecture from your company’s perspective if you want them — and you — to be successful.  You do not want the people you hire to bring traffic to your website by guessing how your customers do searches.   You need to be ready to identify your user needs online and how best to put the library at the forefront when people have those needs.

So, here are a few tips that I’ve learned about how users search for their libraries:

Sometimes users will search for the system; sometimes they’ll search for the branch

If you look at your website stats, I’ll bet any money that your top searches will be for “library” “[city name] library” “library [city name]” and so on.   The next bunch (I bet) will be “[branch name] library.”

But let’s go even further, if someone is searching for a branch, they may be looking for a specific service or event at this branch.    If this is the case, you want to be sure they don’t have to look for you.

Solution(s):

  • For one, you want to have a page for each of your branches with the branch name in the <title> tag.   Make sure basic location, hours and etc. are on this page.  That will make sure people find your site when they search for a specific branch.
  • If you have a database of programs & events, make sure you have a way to feed upcoming programs to specific branch pages.    If not, make sure you have a link to events from each branch page.
  • Make sure you have locations mentioned (in text or as image names) when you promote specific programs on your front page.

Don’t Let Enthusiastic Branding Get in the Way of Common Sense

As companies, like banks and software companies move from names (Hewlett-Packard) to acronyms (HP), so will many libraries.   This is all great and fine, but you want to be sure that your brand does not get in the way of your SEO strategy.    Take the Acronym for Halifax Public Libraries, for instance:  HPL.   “HPL” can refer to any of the following:

  • Hamilton Public Library
  • Halifax Public Libraries
  • Human Performance Lab (at York University)
  • Human Performance Lab (at Calgary University)
  • Human Placental Lactogen
  • Huntsville Public Library
  • High Performance Linpack
  • Hewlett-Packard Labs

If you are ‘the’ HPL (in my case, Hamilton Public Library) then all is fine and dandy.   However, if you are HPL number 4, 5, 6, 7, or 8 — then there is some trouble.      Also, are you sure that it is an acronym that people will type into Google or another search engine when they are searching for you?

Solution:

  • Make sure all images and acronyms have a plain-english explanation for who you are as well.  For one, the title should include the full title of your organization.
  • As a general rule, favor plain language over jargon on your website.   “FindIt” might be great for print promotion on your catalogue, but “search” is what most people look for online.
  • For your URL, consider including the word “library” somewhere.   This is especially true if your library’s acronym could be confused with those belonging to other organizations.  Remember that the word “library” is the best brand that we have.

Consider Your Users’ Needs, and then Make Pages that Respond to Those Needs.

It shocks me how many libraries have websites that do not include the words “reading” “books” “computers” or “wireless” somewhere on their pages.    We want people to think about the library when they are searching for books, along with all those publishers, used book stores and etc.

When someone is looking for wireless connections in your town, does a search for “wireless [your town]” have your organization up and front?    Why not?

Solution:

  • Build your website according to user needs, using simple language.   You want the keywords that people will use to appear on your website.
  • Assuming that you have the following services, you should include the following terms somewhere on your site:
    • Wireless (wifi)
    • Computers (and computer lessons)
    • Events & programs
    • Books, Bookclubs, DVDs, Authors
    • Reading, Read, Readers
    • Kids, Parents, Teens, Seniors

Don’t Buy into the “Front Page is Everything” Philosophy

Whenever you start a website project, the first thing almost everyone is going to tell you is that their particular interest/service/whatever needs “a big button saying “[insert service here]” on the home page”.    While it’s true that being on the front page will draw more traffic to that page, it does not follow that you will have more visitors to your site.   It is much, much better to have a logical pathway to each service, with clear labels and a simple interface.

From an SEO standpoint, this also matters.    If someone is looking for something specific (eg. How to sign up for an Literacy program), they are going to want to hit the “sign up for Literacy” page on your website when they search, not the home page.

Solution:

  • People will click a few times to get where they want to go.    While you do not want people to get lost, you also do not want to schmush your front page with content simply to give exposure to pet projects.
  • Consider other marketing techniques to draw attention to smaller projects.  For example, you could try viral marketing instead.
  • Spend more time developing useful content that will get people clicking on your website after a search, rather than worrying about from-the-front-page navigation.
  • Make sure that you have search engine-friendly Urls turned on if you are using a content management system like WordPress, Joomla, or Drupal.

These are a few tips I have.   There are many more, of course — maybe you want to share some?    In the end, libraries spend much too much time worrying about the design of their webpage without considering other pathways that customers will take — including search and external links (which I have not covered here).

APIs: Who? What? Why? How?

APIs (Application Program Interfaces) are among those things that most presenters talk about with the caveat: “You do not have to know how to do it; you only need to know they exist.” You have to be fair to the presenters — an api is not really something you can explain without actually demonstrating how to use it.

Well, since I spouted a challenge to all those Learning 2.0-ers out there, that they can and should learn a little bit about what goes on under the hood of Web 2.0, I thought I’d give explaining apis a shot. I’m going to do this using four questions: Who? What? Why? How?

Who? :

APIs are most often released by web-based companies that host data created by users. Offering an api in this context is rather obvious: if users create the data, they might want to use it in other places around the web. Business-to-business web services may also offer apis to partners so business can happen more quickly and efficiently (think VISA, PayPal & eBay).

The most popular apis are released in such services as Google Code, Flickr, Del.icio.us, Facebook, and MySpace.

Two apis that I’m going to describe today (with limited detail) are the Twitter, & Twitter Search apis. If you are a beginner, I think the Library Thing api is also quite nice and simple to play with.

What?:

This is where you are free to doze. Just a few acronyms to get you through your day.

  • REST (Representational State Transfer) : This basically means “getting XML data from an api using Http and a URL.” It is the most popular because it is easy.
  • GET/POST : Http commands to do stuff with an api. A “GET” usually means you are just going to output data to the screen. A “POST” usually means you are going to store the data somewhere (eg. in a database).
  • cURL : A popular way to get api data without being worried that the data will cause bad things to happen to your server. Using cUrl is often mandatory with web-hosted servers (like Dreamhost).
  • XML/JSON : Two different ways to markup data. JSON is faster and more friendly when using AJAX. XML is slower, but easier to read, and more easily handled by server-side scripts like PHP.
  • SOAP (Simple Object Access Protocol) : A harder and more particular way of using data in an API. I’m not going to talk about it much, but suffice it to say that it uses an XML-based protocol to make api requests.
  • WSDL (Web Services Description Language : A complicated standard a Web Company can use to make SOAP a bit easier to use for the rest of us. It meticulously describes every command someone can use in the api.

In general, simple services offer simpler (REST) apis. Get into large, complicated services where money gets exchanged or whatnot (eg. Business to Business data exchange, eBay) and you are going to find SOAP and WSDL.

Why? :

You would use a API for the following reasons:

  • to create a widget for your website or blog.
  • to create a Mashup (a combining of two different services).
  • because you want to store or organize data in a service for your own personal use.
  • to do something cool without having to build a service from scratch.
  • to provide a unique way to show a service’s data (eg. tag clouds, visualizations etc.)

How? :

My 10 Step Program:

  1. Read the api instructions and find out what you can and cannot do with the api. For instance, the Twitter api does not (as of today) offer a “search” for twitter. For that you need the Twitter Search api, which is an entirely different web service.   UPDATE:    Twitter now offers its own Twitter Search api.
  2. Choose your coding method. Yup! APIs require coding ability — that’s why conference presenters don’t want to spend too much time explaining it to you. AJAX is the client side api tool. PHP, JAVA, PYTHON & RUBY are probably the most common server side tools. (Don’t stop here just because you do not know how to code. I can at least explain the process of how apis work!)
  3. Use Curl (PHP etc.) or the HttpRequestObject (AJAX) to grab information from a URL. What you want to do is usually indicated through the URL. For instance, to get the last 20 statuses from one of your friends (MYFRIEND) in Twitter you would use
    http://username:password@twitter.com/statuses/friends_timeline/MYFRIEND

    (using your username and password from Twitter).

  4. Use your coding skills to manipulate the data you receive from the URL. PHP has a nice tool called SimpleXML to do this. AJAX uses the XML DOM. XPath is another way to get your way around an XML file. Or maybe you just want to template the data using XSLT.
  5. Output the data to the screen or a file for later storage. Html is usually quite nice.
  6. Run the page and find out you have a gazillion errors. Go back to #4 until you have them all fixed.
  7. Share with your friends to show how geeky you are.
  8. Clean up your code and provide lots of comments so you can understand what you did later.
  9. Find ways to make your script run faster.
  10. Secure the code (hiding that username and password might be a start).

That’s the basics behind using an api.

Final Words :

API is a buzz word in many circles. I have seen it bandied around by all sorts of people who have no true understand about what it is or what it does. Knowing what an api is will help you make better decisions about products. Here are some api axioms for librarians:

  1. Demand an api. Web-based products that store data you own should have an api of some sort. Look to the competition or an open source product if your product people say “no.”
  2. You need to know what you (or your coders) can do with that api. It ought not be enough for a vendor to say your desired product has an api. Creating an api is easy. Creating a useful api is more challenging.
  3. Respect the rules of the api. Each time you call that URL for the api means you are using the service’s web resources. Most services create limits on the number of request you make per second (usually no more than one per).
  4. Expect alot, but not the moon. Apis cannot do everything. Expecting to be able to search gazillions of items from an http request in an XML file is not going to do you or the service favors (especially if that search includes an “OR,” a “NOT” or any regular expression. Expect to get a limited amount of data in a single request. If you want more, store it on your own server (with permission or license) and work it that way.
  5. Mash-it-up! Working two apis together is really, really fun. Possibilities are (almost) endless.