About Bookmarks Contact Library Map Photos Search Talks
October
2
2007
1:14 am
Tags:
Post Meta :

Byte Level Research sells two very cool looking maps of Internet TLDs (Top-level Domains). The maps show the two-letter country codes (e.g. ‘.ca’, ‘.ru’, ‘.uk’) for the countries of the world, which each code shown on a geographical map over the country it represents. The map also includes an index that maps the country codes to actual country names for handy reference.

map of DNS TLDs

September
28
2007
9:48 am
Tags:
Post Meta :

Built With is a web application that assigns a rating to websites based on the technologies the site is built with. It analyzes things like how you use javascript, if you employ specific frameworks, the character encoding you use, how you use stylesheets, what type of HTML you employ, etc. It takes all these into account to assign a 5-star rating.

Paranoid Agnostic scores 4 out of 5 stars. Why did we score so high? Well, in part because we didn’t leave anything out! Sites score low on the “built-with” scale if they use few different technologies. On this site we use two different javascript libraries, we have widgets, RSS feeds, we make use of good character encoding, CSS is used extensively, and we have a few gimmics.

Sites that score low on the built-with scale seem to have fewer technologies. This is not neccassarily a good rating. A very effective, standards-compliant website (XHTML strict, CSS, and RSS) would score quite low. Whereas a really error-prone messy site (lots of different widgets, bloated javascript libraries, too much privacy invading analytics) would score very high.

So what does this score mean? My interpretation is that the score is trying to measure how “mashup-able” a site is. If a site is built with many different components it scores high. A site that is a mashup, a site that can be mashed-up, a site that wants to flexible over the long term, needs to use the technologies that score highly on this scale. That is not necassarily a bad thing. There is just no measure of how effective those technologies are employed yet.

August
31
2006
10:52 am
Tags:
Post Meta :

About Blog Day

I am told that today is Blog Day and that on Blog Day bloggers are supposed to blog about five blogs that they believe their readers will find interesting.

is getting pretty big, and ever since becoming a graduate student in Library and Information Science, I have been mostly adding library/infosci blogs. Thus, I find it strange that when I made this list of “five blogs that I think you should know about” there was just one library blog that made the cut.

Five Interesting Blogs That I Think You Should Know About

CogNews

News about Cognitive Science. This is the slashdot of cognitive science, with infrequent posting but excellent selection of content.

All In The Mind

Podcast from ABC (Australian Radio Station) about psychology. Really interesting 30 minutes podcasts. I highly recommend checking the archives for the recent interview with Daniel Dennet on Evolutionary Psychology and Religion and another recent episode on Stalking.

Junk Charts

I usually don’t like sites that just criticize other people’s work. However Junk Charts is special. It is a thoughtful and very productive criticism of data visualization (i.e. charts and graphs that are misleading or deceptive or just plain bad)

Statistical Graphs and Data Visualization

Despite the title sounding dull, this is a very exciting topic. If you have ever heard of or read Tufte, then you will undoubtedly find this site useful and interesting.

Unit Structures:: Fred Stutzman

Fred Stutzman is a Ph.D. student in Library and Information Science. He is by now becoming famous for his work on the adoption of Facebook by college students. If you search Google Video you will find that he has given a talk at Google about his research on facebook. His site also has some links to MP3 files of recent interviews he gave. His postings about his research are well worth reading.

March
11
2006
11:40 pm
Tags:
Post Meta :

This evening we had a wonderful treat!  We were invited to see the musical Little Shop of Horrors presented by Strathcona High Schools Drama. Our friend Merran is in the production and plays a “Doo-Wop” girl (”Ronette”).  I won’t bother recounting the plot as it is so well known.
Had I not been told in advance that this was a high-school production I would not have guessed. The entire production was excellent: excellent talent,  excellent sets, excellent venue, excellent stage managment, and even special effects.

The female lead character, Audrey, was played by Breanna, who has an incredible and obviously well-trained voice.  Breanna’s singing was stellar and her New York accent was quite fun.

The male lead character, Seymour, was played by Matt.  Matt really looked the part and played it well. I quite enjoyed the comical “Mushnik and Son” number. Mr.  Mushnik was played a big bear of guy and looked huge compared to Matt (Seymore) who is quite skinny and shorter. The two together made a great comedy team.

While the lead characters were certainly held by talented players, the productions was really made grande by a super supporting cast. There were a LOT of people on the stage during the big numbers and it really built a great energy. Now, in a production like this, having a lot of people on stage can mean diaster. It is hard to find a place for everyone, and it is even harder to give each person something to do on stage, and then to make it all work together and not seem chaotic would seem nearly impossible. In this production the impossible was accomplished.

Three trios of “Doo-wop” girls provided excellent support in each number. The trios really provided the glue in every scene, and without them the performances, though talented, would have been merely interesting rather than brilliant.  For example, at any given moment there was usually one on stage left or right, another in the balconies at microphones, and another scattered in the background.  This really made THE difference. It help the audience stay involved because no matter where you looked there was always on of the Doo-wop trios drawing your attention and keeping your imagination in the scene at hand.  There were some terrifically comical moments provided by these Doo-wop trios, not the least of which was a scene where one trio acted as three potted plants interpreting the lyrics sung by Seymore.

One thing that impressed me was that with all the people on stage at any time, the energy always stayed with the main action.  That is a big accomplishment. Sometimes a stage play can get an uneven feel, with attention drifting from the main characters to the supporting cast in an uncomfortable way. In every scene, all the people on stage seemed to focused, organized, and they fed the audience.  The extras that lounged on benches didn’t distract but added to the scenes. The Doo-wop girls never upstaged anyone and kept the energy flowing in every scene.

This is not just an accomplishment for the talent young men and women on stage. Clearly there was some well organized stage managment and creative coreography.

The sets blew us away. There was a good attention to detail without it becoming too much of a distraction. In many ways that is a strenght of the whole production. Lots of detail, but well focused.  The sets were attractive, and technically quite sophisticated. Since the set was constructed in a solid manner and the stage was not extremely large, this made it impossible to have any whole-scale set changes. The set designers were very creative however. The bulk of the action takes place in the flower shop or on the street (”skid row”) in front of the shop. One scene has to take place in a dentist’s office, and there isn’t room for a separate set for the office.  Instead the office was hidden behind one of the walls of the “skid row” street.  The wall was rotated and inside was the office.  It was brilliant and delightful.  Another thing about the detists set was that they had actual dental equipment. You know that monstous thing that holds the little sink you spit in and has the arm with the light and drill?  They had one of those!

The fact that this production had special effects cannot go unmentioned. The Little Shop of Horrors revolves around the ever growing man-eating monster flower “Audrey II.”  This production had several different props for the Audrey II at different stages of growth and each model was setup to seem like it was alive.  Honest too goodness special effects. The larger versions were well made: attractive but monstrous as well.  In several scenes Audrey II has to swallow characters, and the large versions were constructed so that the actors could slip inside and disappear.  This extra effort in the design of the plant makes much more entertaining.  In the final scene when Audrey II eats Audrey the devouring of the lead actress looked so smooth and so graceful that the audience spontaneous applauded.  It was wonderful.

Perhaps the only weakness in the entire evening was in the second last number.  The singing of “The Meek Shall Inherit” had a good beginning but got a bit chaotic near the middle. Fortunately, the cast pulled it together toward the end of the number and that made a smooth segway to the final scene giving them a strong finish.

Hours later I am still so impressed.  This evening was such a treat!

December
3
2005
11:53 am
Tags:
Post Meta :

Over at Scary Ideas” there is a brilliant cartoon about information technology projects and how they go wrong. The cartoon is funny but also a clear and concise commentary of project management. In ten separate panels, the artist describes how various people involved in an IT project can misunderstand the deliverables. What makes this cartoon brilliant is that it can be used to explain how to avoid such pitfalls.

In frame 1, we see “how the customer explained it.” A tree with a swing in it, but the swing inexplicably has three seats. In my experience it is common that customers do not know their own need, especially in relation to information technology. They are able express that they have a need, but not necessarily what the need is. That is, of course, why they hire consultants. But projects go wrong for many reasons, and the customer is not entirely to blame. This cartoon analogy rings true for me. Customers typically express their need in a rough way but tend to try to specify the solution as well, and they usually get that part wrong. In this case the customer knows they need a swing, but thinks the solution involves lots of seats on the swing. They don’t understand that the extra seats don’t solve their problem, and probably prevent it from working at all.

In frame 2, we see “how the project leader understood it.” The project leader figured out the swing should have just one seat but didn’t really understand the “swing” concept and has the swing attached to the tree in a way that would preclude “swinging.” This is worse in some ways than customer’s explanation. The customer at least captured their need. Hear the project leader “doesn’t get it” but manages to capture some of the characteristics the customer described. Project leaders make mistakes like this because they are responsible to the “project” and responsible for delegating work to team members. The focus is on the parts, not the whole.

Compare that to the perspective of the business consultant in frame 5. Business consultants interface with the customer directly but are motivated to make a sale. They have to communicate to the customer both that the customer’s need is understood and that the solution offered will be the best available. Sales people and consultants tend to over promise, setting up everyone else to under deliver. Over promising also sets up the premise for frame 8, where the customer is over billed. Customers will always feel over billed if you promise the moon and don’t deliver.

In frame 3 we see the perspective of the analyst. The analyst interfaces with the project leader. He “gets it” put takes an engineering approach to the problem. He works within the constraints of the problem that the project leader has proposed and comes up with a solution. In this case the swing will swing, but it is not a straight forward solution. The analyst is not solving the customer’s problem, the analyst is solving the problem invented and interpreted by someone who just didn’t get it. Worse yet, in frame 4 we see how the programmer delivers what the analyst asks for. All the parts the analyst described are there, but when put together they just don’t do the right thing. If you made up a checklist for the deliverables, the programmer has indeed done his job… all parts accounted for. But it doesn’t meet the customers need.

In frame 4 we a source heavily linked with all the other frames. The documentation describes a mere shadow of the customer’s need. If the documentation were written first, and resembled the business consultant’s view, then the analyst might have been able to pass on something better to the programmer. The lack of documentation probably explains frame 7 as well. Operations often does not install what is needed to meet the customer’s need. Operations is so far divorced from the customer that they don’t know what the deliverable is supposed to do. They don’t know what the parts are for or what is important and what is not.

In frame 9 we see what ultimately happens after an IT project goes wrong. Everyone stops taking the customers calls, and refers them to support. Support, has to figure out how to make the best of a bad situation and deliver something, anything, of value to the customer. Support people are emergency workers. They conduct triage on the deliverables and decide what is worth saving and what is a write-off. In frame 9, we the tree has been cut down. There is no swing, but there is a nice stump to sit on.

In frame 10 we see what ultimately would have suited the customer’s needs. A nice tire swing. Not what the customer described exactly, but pretty close. Not as elaborate as what the business consultant recommended, but roughly the same idea. It does the same thing the analyst designed, but is much less complicated.

There are some lessons to be learned here. Of all the view expressed, the business consultant’s was the closest to the customer’s need. But typically business consultants are involved at the beginning of the process and are removed from the project later on. Some methodologies require that the customer be involved at all stages. I’m not sure that is realistic in many cases. However, it is clear that IT projects need customer advocates. I believe that business consultants, as expensive as they are, should be those advocates. Business consultants should not be sales-people but expert generalists with development and management experience. They should not be the project manager but should work directly with the customer and the project leader. The role of the business consultant should be to create the documentation, understand the big picture and the details, and assist the project leader.

I think this poster assumes the project leader is a technical team-leader or manager and not a professional project manager. That is a fairly good assumption in most cases. The technical project leader’s job is to make sure that the right resources are allocated to the project, that the job is getting done. The leadership role involves keeping things on track; its a difficult balancing act. While the project leader needs to understand the big picture, we need to be realistic and assume he will not be given the opportunity to reflect on big picture aspects. The team leader is too busy worrying about details. That is why the business consultant/advocate needs to work with this type of leader.

Most development methodologies now emphasize artifact creation at all stages by different participants in the project. I think if the the business consultant’s job is act as the “big picture” thinker and to interface with both the project leader and customer, then it is the business consultants job to ensure that the right documentation has been created. At least three levels of documentation need to exist: A high-level documentation that the customer can understand that explains what problem is being solved; A technical specification that describes the various parts that must be created and how they fit together to create the solution. This would include step-by-step user documentation for each component of the system; and low-level documentation create by and for the analyst and programmers. The low-level documentation is meant so that the system can be installed by operations and so that it can be maintained. In the end support and operations will need all of this documentation and without it they cannot be expected to deliver what the everyone else built and expected.

I’m not optimistic that much can be done about the customer being over-billed. IT projects are expensive, however if we assume they will be expensive that gives us a constraint to work within and we can concentrate on building value within that constraint.

You can get the cartoon printed on a t-shirt at cafepress.com.

older »