Nerds Central

C++11 Makes Competitors Go Rusty

2012-02-01T19:38:00.000Z

Rust is breaking free, but does it have any real world value?

C++11 is out (has been for a while) and brings many things from Tr1 into the standard. Things like managed memory (shared_ptr) and lambdas and template meta programming (TMP) bring new paradigms to the beating heart of C++. So much so, I would argue, that C++11 makes some of the 'new kids on the block' (think Go and Rust) look pretty pointless.

'Go Rusty' as in go old, look old, corrode and otherwise become less good. This is really just a play on words because both Google and Mozilla have been playing the 'new object oriented native language' game recently. I can really see the motivation, especially from organisations which want to create highly stable, performant, cross-platform systems like browsers. The issue I see with both Go and Rust is that they are solving yesterday's problems. C++/Tr1 has also solved many of the same problems without needing a new compiler, for teams to learn a new language and introducing all those compatibility issues with existing code.

So Boost and Tr1 are cool, but not part of the standard... Well, no longer, a large proportion (if not all) of what Go and Rust are trying to do with a complete new language C++ has done by adding to an existing one via the 2011 standard.

From Wikipedia:

Rust is an experimental, concurrent, multi-paradigm,compiled programming language developed by Mozilla Labs.^[1] It is designed to be practical, supporting pure-functional, concurrent-actor,imperative-procedural, and object-oriented styles.

The main developer is Graydon Hoare, who began work on the system in 2006; Mozilla became involved in 2009.^[2] In 2010, work shifted from the initial compiler, written in OCaml, to the self-hosted compiler written in Rust itself.^[3] It successfully compiled itself the following year.^[4] The self-hosted compiler uses LLVM as its backend.

Version 0.1 of the Rust compiler was completed in January 2012.^[5] Mozilla described it as an alpha release, suitable for early adopters and language enthusiasts.

Go is a compiled, garbage-collected, concurrentprogramming language developed by Google Inc.^[6]

The syntax of Go is broadly similar to that of C: blocks of code are surrounded with curly braces; common control flow structures include for, switch, and if. Unlike C, line-ending semicolons are optional; variable declarations are written differently and are usually optional; type conversions must be made explicit; and new go and select control keywords have been introduced to support concurrent programming. New built-in types include maps, Unicode strings, array slices, and channels for inter-thread communication.

I can totally get why people want to write new programming languages. Sometimes it becomes very annoying dealing with some seemingly stupid, repetitious and just plain awkward aspects of many main stream languages. However, I learned from Robert Sales and Micro Focus that a much more productive solution to annoying syntax is to make the compiler able to work out what you mean with better syntax and leave in the old syntax as well. Why is this better? Here are some (but not all) the issues created by introducing a new language into an existing echo-system (which all projects are these days):

Massive but ineffective - lots of engineering does
not make something worth while or work well. Normally
the reverse is the case!

Compatibility: The new language will have to talk with older languages. Types will have to be translated; memory models will need to be aligned and compilers will need to 'play nice' together. This is not just as the compiled object level but at the ABI level during linking etc.

Performance: This new language is super fast. Great, but it will have to work with existing systems. The interface between the two will slow stuff down a lot. Either that interface will have to be messy (see Compatibility above and/or JNI) or via a marshalling system (Protocol Buffers, Avro etc). The problem with marshalling between dissimilar systems is that it is really slow. It might seem like a good idea (just like the steam gun right) but it is a stupidly expensive and complex way to solve a problem of one's own invention. Such protocols are great for clustering, cloud processing and client-server work; they are just wrong headed for gluing systems together to work around using different languages in one system.

Keep it simple.

Build: Build system complexity has been one of the biggest headaches in all the major projects I have seen over the last few years. Build systems are getting more and more complex as the demands of heterogeneous programming and dependency management push technology beyond the sane. Frameworks like maven, msbuild and even good old make work fine if a project uses one language; they generally degenerate into a big ball of mud otherwise.

Debugging: Debugging across languages is really tricky. I should know, I have spent a lot of time doing it over the last few years. For example, even debugging from COBOL into Java and back on the same JVM is tricky because a Java debugger does not understand COBOL and the same is the case in reverse. Jumping between native languages can be even harder when their internal data structures, interpretations of indirections (pointers etc) and (shudder) interpretations of thread state are completely different.

Team Training: Assembling a team of people who know one language well is hard enough; doing so across multiple languages is extremely challenging. Some people will be prepared to learn new stuff but not all will. Time pressure, as we all know and love it now, generally does not leave time to learn a language up front in a project.

Team Embedded Knowledge: It is very hard to keep the knowledge of a multi-language project spread throughout a team. It is even harder to keep that knowledge 'live' as team members leave and join. Because language interoperation patterns are less well known and less standardised that intraoperation patterns, unique embedded knowledge tends to build up in teams.

Version Management (language/runtime): Different languages frequently have slightly different life-cycles and dependency management issues. These accumulate to cause challenges in revision control.

Tooling Costs: Good tooling can be expensive. Tools like profilers, code complexity analysis systems and test coverage checkers can all be pretty costly to buy. Whilst some have good open source alternatives, these have the embedded cost of maintenance and installation. Again, multiple languages usually means that a team needs more tools and hence more cost.

Licensing Of Runtimes And Libraries: We often get complacent thinking all libraries and runtimes will be free. This in not the case. Even if they are 'free' as in they cost no money, their licensing requirements might complicate commercial arrangements. If they are commercial and have enforced licensing this introduces a whole new level of complexity. One really nasty situation is when two completely different forms of code hardening in the licensing systems do not play nicely together. I have seen it happen and it is not pretty.

Lifespan And Sundown: All things come to an end. Support for a language or, more often, a version of a language will come to an end. Managing these life cycle events can be challenging in a single language environment. When more than one language enters the picture, the cycles will almost certainly not coincide. The less common a language is, the more likely that is will be sundowned whilst the products using it are still current. It is fairly easy to get into a situation when one can never actually release on a completely stable, current set of components.

Startup And Shut-down Sub-Systems: A programming language is just the code right? Wrong - generally there is a lot more to it than that. It can be tricky even to mate up C with C++ projects because C++ has to initialize statically referenced objects before main is called. Many other languages have even more complex issues to do with threading, signals and loaders which all get in each other's way when building a mixed language system.

Paradigm Contamination: Seeing Java written in the in style of COBOL is quite an eye opener. I am not a COBOL bigot either way; it is a solid language that is really good for some things. Java is also a solid language, but it really should not be programmed in the style of COBOL. However, where the two languages touch the chances are the COBOL will look like Java and the Java look like COBOL. I have seen exactly the same thing with C# and C. If a programmer is working in C and writing a bit of Java, the chances are the Java will be C like. Equally, the natural paradigm of a cross language API tends to be a hybrid of both languages. Whilst these things are to be expected, they are horrid. The code looks bad, smells bad and is hard to test or maintain.

Brain Strain (the bilingual problem): Children which are brought up from babyhood as bilingual usually learn to speak more slowly than their monoglot contemporaries. Can the analogy be brought over to programming? In the absence of hard evidence from psychologists, it seems at least likely and reasonable to assume that coding progress will be slowed down by the extra cognitive burden of working in more than one language.

... and so on ...

So what am I saying?

I hope I have established that in modern environments, introducing new languages carries with it a lot of down sides. To put it another way - there has to be an overwhelming need before there is an overall benefit in introducing a new language rather than using a well established general purpose language. Go and Rust are compiled straight to native and so the existing candidate as an alternative is C++. C++ has huge pre-existing libraries and is (with the possible exception of C) the most likely language in which other native code will be written. Even if there is a large legacy C library set, C++ to C is a well know interoperation with some issues from the list above but not too bad.

So, is there an overwhelming need to replace C++ with Rust or Go?

I would definitely say NO! Simple paradigm following within the pantheon of C++ allows this language to behave just as well as Rust or Go - or at least that is what I fully expect.

Let us think about the big ideas behind Go: It is simple, clean and has garbage collection. Well, one can write simple clean C++ and use share_ptr. Just because C++ can be super complex does not mean it has to be.

Let us think about the big ideas behind Rust: Type inference, static assertions (checks), simple constant rules to facilitate reasoning about multi-threaded execution. These are nice things indeed. However, using lambda's correctly along with other templating techniques makes C++ straightforward for multi-threaded reasoning. Template Meta Programming should be able to perform most of the type reasoning which the compile time checks are performing in Rust. C++11 has type inference. It does not use clever code branch analysis like Rust, but it is there (auto and decltype).

The ideas in Rust are definitely more tricky to implement in C++ than those in Go; however, the effort required to do so is , IMHO, trivial compared to creating, using and maintaining a new language. Further, the effort to replicate Rust's good features in a C++ paradigm is much less than the effort of dealing with a new language (as described above).

Here is a very trivial bit of C++ with which I was playing this morning:

// VSPL.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <boost/spirit/include/qi.hpp>
#include <iostream>
#include <iterator>
#include <algorithm>

namespace client
{
  namespace qi = boost::spirit::qi;
  namespace ascii = boost::spirit::ascii;
  template <typename Iterator>
  bool parse_numbers(Iterator first, Iterator last)
  {
    using qi::double_;
    using qi::phrase_parse;
    using ascii::space;

    bool r = phrase_parse(
      first,             
      last,              
      double_ >> *(',' >> double_),  
      space              
    );
    return first == last;
  }
}

int main()
{
  typedef std::istream_iterator<int> in;
  std::string code = "1,2,3,4,5,6";
  std::cout << (client::parse_numbers(code.begin(), code.end())?"All is well":"It barfed") << std::endl;
  auto exiter = [] (const int v) { if(v==123)exit(0); } ;
  for_each(in(std::cin),in(),exiter);
}

Here we can see a lambda being used as an immutable first order entity. The for_each could be parallel or serial, it really does not matter. We can also see type inference where the type of the lambda is inferred from its internal code (in this case void).

I did not include this here because it is a clever bit of code; Indeed, my motivation is quite the opposite! I am working on a parser for my research language VSPL using the Spirit library in Boost. The above was just a play thing to make sure the project was set up correctly. However, easy features like type inference, lambdas, name spaces and internal DSLs are so accessible in C++ now that they are just natural in the most trivial coding example. I just don't see a strong enough argument for new languages to replace C++.

ParkView Guest House Cambridge: Try It!

2012-01-30T20:47:00.000Z

Off road parking in a quiet area, just one of the A+ features of
this unusually pleasant guest-house.

"Having ridiculous amounts of money extracted from your bank account for tatty rooms and generic food." That is the experience of most traveller's accommodation in Cambridge. Fortunately, after some time and effort, I have found a better way: The ParkView.

This small, family run place is my home one night a week. I am currently working on a fascinating project for General Electric in their geographic information systems based in Cambridge. The drive from my home in Oxford is tedious and tiring to say the best of it (and expensive when considering my merc's considerable appetite for petrol). As a consequence, I stay over in 'the other place' once a week.

Now Cambridge is expensive. Staying in Cambridge is a world apart from most of the rest of the UK. I know a forensic psychologist who has been able to stay in a 5 star hotel in Cardiff at a rate for which one could, maybe, rent a shack, on a rubbish tip in Cambridge (if you did not mind the leaking roof and rats).

Quiet and pleasant (and er. flat).

The 'B&B' places in the North of Cambridge have it too easy. This is the natural stomping ground of visiting academics and business people hoping that hobnobbing with the intellectual elite will make them seem less like the pointy hair boss. As a consequence the cost is high and the service low.

'Anonymous money extraction machines' is a kind description of the post-apocalyptic concrete monoliths which pass for hotel chains on the A14 running around the north of the flat city. The Premier Inn is plastered with signs promising rooms from £26 (or some such) but never has anything for less than one arm and several toes.

Yes - there really is a park

So it is that I recommend this Park View and its bubbly land-lady, her yummy bacon and egg breakfasts and the over all pleasant, reasonably priced, quiet and comfortable environment from which I am writing this post. Oh, and do not forget that pub just down the road and to the left; nothing fancy, just a good, solid steak and chips washed down with a couple of pints. Pure joy.

01223 247287 - say Alex recommend it ;)

Phase: The Secrets Of Stereo Recording

2012-01-29T08:51:00.000Z

There is a lot more to stereo than the simple idea of volume differences between the left and right. In this video I discuss, explain and demonstrate the effect of phase and how the human hearing system can discern the direction from which sound is arriving even when the volume reaching each ear is identical.

This video is recorded in HD 1080p and uses my new 'franken-phone' microphone for video recording!

The Video On Youtube.

Or The Video Embedded Here.

Ode To A Mid Life Crisis

2012-01-28T18:27:00.000Z

Just in case you don't get the joke - that is a picture of the engine in my recently acquired car. It is a (now a few years old) 279 horsepower V8 in a CLK 430. It has an amazing ability to put a huge gin on my face!

Vintage Microphone With A Modern Twist

2012-01-27T20:07:00.000Z

Sometimes looks trump everything else. This is the case with this gem of a microphone. The Claricon 38 would appear to be cosmetically identical to the Calrad DM-21. I suspect they were made by the same company in Japan in the late 1960s or around 1970.

These look just amazing. Below I have an image of one being used as a prop in a pop video by the English singer Paloma Faith. If only they worked one tenth as good as they look! The design is a clear rip off of the classic Electro Voice microphone. Whilst the EV mikes have the highest audio engineering standards, the innards of these cheaper devices were always rubbish and do not stand the test of time. So - why did I buy one and have it shipped from the US?

Very similar (almost identical) to this one used as a stage
prop in a Paloma Faith video 'Something Beautiful'.

There is loads of space inside these cases. So, my plan (which seems to have worked quite well) was to put a modern dynamic cardioid capsule into the case of the the old Claricon thus making a fully functional desk microphone with a knock out retro look. The capsule I put in the case is from a Yoga D727. That is a little, cheep, instrument mike; for some reason I just like the sound of the D727 so I had hoped the franken-claritron would be similarly smooth and 'voice over - ish".

The look of the thing is just unlike any modern microphone. There is something wonderful about the solidity
of this vintage kit. Not very practical but somehow holding great vidual and tactile appeal.

The mike in the video by Ms Faith has wider spaces in the fluting but I am completely
happy wth the look of this model.

So far the sound quality does seem to be where I want it. The vintage case produces a vintage sound; microphone engineering is complex. Time will tell, but for now I am quite excited about the tonal quality of the mike.

I did not wire up the switch. To be honest it was of low quality
and I was concered that it would add crackle to the audio.

That joint is not just for show. It is held in place with a spring
washer and so really makes it easy to point the mike at the desired
angle.

The microphone and user were created at about the same time!

Behind the plate is a space in which the impedance transformer was
placed. The transformer is no longer required as all (any good) modern amps
use balanced low impedance which is how I wired the capsule.

I mounted the capsule using a synthetic foam mat wrapped around it to fit snugly
in the barrel of the casing. This left the front and rear entry ports to the capsule
well forward of the screw for the cap. I covered the capsule with the wind-shield
(as we can see above) to help reduce pop sounds from plosives.

This is the cap which screws over the capsule.

Finally, here is the final product.

The biggest challenge was running the wires through the microphone body. I started by trying to use the original wires but it just did not work out so I just took the lot out and started with an empty case. I then rewired it using the cable form an AKG D109. The wires have to go up through the base and through the hinge - which is fiddly. However, it was all well worth it. I will be releasing the first video using this as the recording microphone in the new few days :)

Systemic/Reflective Agile Teaming

2012-01-23T13:36:00.000Z

A team is like an olympic athlete. Once we have gotten
everything out the way of success we need to support the
athlete to operate at peak ability.
Image Wiki-Commons: accreditation here.

Agile has revolutionized the effectiveness of software development. At the core of Agile is the team; agile methodologies have improved team working massively but, in my view, we are less than half way there. With the help of modern psychology we can start to go from removing impediments from teams to tuning them for maximum performance.

Here are 10 key factors to success in agile (there are some more but this will do to illustrate the point).

Stand-ups
Planning sessions
Goals
Retrospectives
Burn up/down
Close customer association
Pair programming
Continuous integration
Continuous delivery
Meeting Moderators

Each one helps remove impediments:

Stand-ups: We do not work at crossed purposes, alignment is easier.
Planning sessions: We do not continue doing the wrong thing; we can react rapidly.
Goals: We don't 'just do stuff' we aim at what the customer really needs.
Burn up/down: We don't get caught out by losing track of progress.
Close customer association: We don't build something the customer does not want.
Pair programming: We avoid knowledge being restricted to one person and avoid poor quality code being missed by the review process.
Continuous integration: We avoid broken code and rotting tests.
Continuous delivery: We avoid drifting away from our customers by getting hard feedback on the real product.
Meeting moderators: We avoid arguments and getting stuck on one topic meetings.

An Olympic marathon runner is a viable analogy for a top performance team. Using this as a metaphor, what have we done with these agile techniques?

The running shoes are the best.
The roads are cleared.
There is water where there should be.
The clothing is the very best.

In other words, we have gotten everything out of the way of the team, but we have done nothing to get its fitness up! We expect the team members to just magically work out how to interact better with one another. We rely on hiring people with 'good people skills'.

We can help teams function at a human interaction level just as we can at the programming level. We just need the right tools.

Note: NLP is complete pseudo-scientific bull-shit! So, if you think you have learned anything from that corrupt branch of non-sense, the first thing you are going to have to do, before reading on, is forget it all.

Don't just listen to me - check out the sources on Wikipedia:

Reviews of empirical research on NLP indicate that NLP contains numerous factual errors,^[11]^[13] and has failed to produce reliable results for the claims for effectiveness made by NLP’s originators and proponents.^[5]^[14] According to Devilly,^[15] NLP is no longer as prevalent as it was in the 1970s and 1980s. Criticisms go beyond the lack of empirical evidence for effectiveness; critics say that NLP exhibits pseudoscientific characteristics,^[15] title,^[3] concepts and terminology.^[6] NLP is used as an example of pseudoscience for facilitating the teaching of scientific literacy at the professional and university level.^[7]^[16]^[17] NLP also appears on peer reviewed expert-consensus based lists of discredited interventions.^[5] In research designed to identify the “quack factor” in modern mental health practice, Norcross et al. (2006) ^[18] list NLP as possibly or probably discredited, and in papers reviewing discredited interventions for substance and alcohol abuse, Norcross et al. (2008)^[19] list NLP in the “top ten” most discredited, and Glasner-Edwards and Rawson (2010) list NLP as “certainly discredited”.^[20]

Nerds Central Has Commissioned Advice From Modern Psychology

I write computer programs; it would be pretty stupid of me to pretend to understand the science of psychology. So, to tune teams to operate like a peak performing athletes, Nerds-Central has turned to a BPS (British Psychological Society) accredited psychologist. What follows is based on a report created for Nerds Central by our resident psychology consultant.

The document is now divided into four sections:

Setting The Scene
Creating A Shared Understanding Of The Team
Creating A Forum For Reflection
A Note On Motivation

Setting the scene is an expansion upon fairly well known Agile principles. The next two sections then talk about how to get the team to the peak of performance and so enhance the effectiveness of those principles.

The last section 'A Note On Motivation' is key to the ethics of this approach and must be read before any actions are taken based on ideas contained in this approach.

Section One: Setting The Scene:

Let use set standard agile practices into a larger context. The diagram below shows the standard agile model inside the context of a reactive learning system:

The agile optimisation cycle. The inner blue cycle is our standard
method of moving to a local optimum. The outer cycle is how
a team can move to the global optimum. See Agile: Being A Star.

The inner circle is what we generally accept as the agile process, though its description here comes from a different field of Systemic Team Working:

Working systemically means working with a system and recognizing that you are part of a system. Systems are multi-component interacting and interdependent structures/organisms. As a team you are part of a system consisting of elements such as individuals members, other teams, the organization, a community (consisting of other individuals and organizations) and society. It is useful to think of working systemically as working across 3 domains: Who, What and How.

Levels (Who?):
1. Between individual members.
2. Between other teams
3. Between our team and the organization
4. Between our team and other organizations

Does your team currently include planning and retrospectives for all four of the elements of 'who'? Do you consider the interactions between team members as well as the actions of the team as a whole? To you often make plans or discuss interaction with the other teams - all 360 degrees. This means service suppliers, fellow development teams and management teams. Does your team plan and consider its position in the organisation as a whole? This might get discussed casually, but do you have a plan? To you 'Study, Try And Rate'? Similarly, your team should be considering its interactions with other organisations like customers, the programming community and standards bodies.

Components (What?):
1. Resources
2. Standards
3. Policy
4. Products

It is funny how the first 3 of these come up sporadically at best and often only in retrospectives. Products are the life blood of the Agile development process and so at least this tends to be well discussed. However, how often have you been in a scrum planning session where the question 'do we have enough resources to meet these goals?' gets asked. Yes, the time/effort resource is always discussed; however, subjects like computer hardware, network bandwidth and time with key stake holders often get left to the 'what went wrong' discussion in the retrospective.

The four components of 'what' should be key framing concepts for all planning meetings.

Skills (How?):

1. Adapting to Change.

2. Meeting deadlines

3. Being consistent.

4. Working coherently

5. Building relationships

6. Supporting professional development

Achieving effective Systemic Teaming requires skills to be acquired by the team members and nurtured by the team itself. In IT we can easily think of (as I mentioned before) skills as being technology skills plus some undefined entity called 'people skills'. The next sections will look at how psychology can help with core people skills which benefit the team. Nevertheless, there are a number of basic 'doing' skills which can be acquired and acted upon. There is no point having a skill and not using it.

For example, there is only limited benefit in saying that the team as a whole should support the professional development of all the team members. There is a little bit more benefit in adding that the team actually does something about it. There is a lot of benefit when we take the saying and the doing then add in learning how to do.

Section Two: Creating A Shared Understanding Of The Team

Questions for team members to reflect upon and discuss:
1. How do we each view the ‘team’?
2. How do we define ‘our team’?
3. What makes our team, ‘a team’?
4. What is the purpose of our team?
5. Where does the team fit in the organization?
6. How does this team compare to other teams?
7. Are there dominant/leading members – how and why?

The aim here is to work out a number of exercises which can be easily performed in retrospective meetings which focus on some or all of these questions. Some options:

Pick three from the list for each meeting and place them as heading sticky notes. Let the team write some ideas for answers on stickies and place them under each heading. Discuss the outcome.
One drawback of approach 1 is that some team members might be willing to participate in general (see A Note On Motivation below) but hold back in the actual exercise. An alternative is to create some sheets with questions and sections blank to be filled in as the answers and then get the team members to fill in their sheets in pairs.
Another suggestion is a classic brain storm where a facilitator writes down ideas which team members shout out. The facilitator can help encourage answers from the quieter team members with this technique.

Section Three: Creating A Forum For Reflection

Generally groups function better when they are good ‘containers’ for the anxieties and concerns of members. Alfred Bion wrote extensively on the topic of ‘containment’, which he describes as the ability of a person(s) to take in the negative feelings of another and reflect them back in a processed, less disturbing form. In order for teams to be good containers, team members must be allowed to voice their concerns and listen those of others. Below are some guidelines to prompt reflection upon team meetings and functioning and facilitate open discussion of each team member’s concerns.

Guidelines for small Group Reflection following meetings:
1. How did I feel in the meeting?
2. What might have lead to me feeling that way? (Try and think of at least 2 alternative reasons).
3. What were my expectations of the meeting – were they met? In what way?
4. Did I say what I wanted/needed to say? What helped and what was a barrier to this?
5. What feedback have other team members given about me?
6. What does this say about me/other team members/the team?
7. Are there any recognizable patterns in our functioning as team/individuals?
8. What meaning does this have in terms of my working practices?
9. Is there anything that might benefit from me changing and in what ways?
10. How will I incorporate all of this into the way I function in my team and in the next meeting?

These items can be used as questions just like those in Section Two. However, regular reflection from every person in the team on all ten of these towards the end of meetings may well be a very good idea. if this were to be encouraged with handouts etc., then team members could then take these are a prompt for raising concerns at retrospectives. I shall write more as more experience with these techniques in the Agile process is gathered.

Section Four: A Note On Motivation

Some individuals may be unwilling to engage in reflective practice initially for a variety of reasons. Motivating individuals to change is a complex process and one not to be hurried or forced. Useful strategies to encourage change are:
• Building rapport
• Reflective listening (listening to what the individual has to say then reflecting back to them what you think they are trying to communicate to you e.g. “I don’t think this will work, nobody wants to be honest, its more than our jobs are worth.” Reflecting back >> “it sounds like you have some real concerns about saying how you really feel about some things.”)
• Giving reassurance (e.g it’s not about blaming and shaming but building a great team”).
• Listening to resistance talk and emphasizing choice.
• Expressing a belief that the team can change and improve.
DO NOT:
• Try and talk people into participating in reflective practice
• Argue until people feel uncomfortable and angry.
• Judge people because they do not want to participate.
• Use authority to insist upon participation.
• Give advice on how to feel better about participating in reflective practice.

(Fuller, C. and Taylor, P. (2008). A Toolkit of Motivational Skills: Encouraging and Supporting Change in Individuals. Wiley-Blackwell, London.)

How Fast Is A Chromebook?

2012-01-22T08:53:00.000Z

Chrome 18 on the Samsung S5 seems plenty fast enough to me but many say the Chromebook is very slow. I recorded this video showing gmail, g+, facebook, docs and even youtube all on a 1080p resolution monitor.

Now you can make your own mind up as to if the Chromebook is fast enough for you. I was very pleasantly surprised that it was able to run Youtube at 1080 HD resolution on the 1920x1080 monitor. It did better than it used to which indicated that Google are improving the software. I have to say that I have found the last few releases on the Dev channel - and especially the new Chrome 18 one - very stable and fast; the memory usage has dropped a lot as well and so many tabs can be open at the same time. For me, the Chromebook is my most used device when doing web related stuff at home. I would not recommend it as someone's only machine, but I cannot argue that mine as had a lot of use.

Or the video embedded:

Review: AKG Perception 220 vs AKG C900 vs Behringer C3

2012-01-20T09:44:00.001Z

AKG Perception 220 (P 220) and Capacitor 900 (C900) along side one
another. The P 220 (bottom) looks a similar size but is very much heavier
indeed.

This post is a complete indulgence and basically pure microphone porn. I have a bunch of programmer and software stuff in brewing in the background - but if you love microphones or are just curious about buying options in the 'pro-sumer' end of the market - read/list/look on :)

Confession time, the last couple of years have been a wonderful time as my children are now all growing up and so I can go back to hobbies I had as a young person. One of those was electronics, another audio and a third making music. Right now I want to get back into playing the Sax but electronics and audio are definitely in full resurgence. Wow - what fun there is to be had with modern recording equipment and how much there is to learn, build upon and be creative with microphones!

I bought an AKG Perception 220 large diaphragm capacitor (aka condenser) microphone to be my 'go to' podcasting mike. Then I bought a second hand AKG C900. What is odd is that the C900 has proven to be my 'go to' mike! In the podcast (below) I explain when and view the pros and cons of both microphones for podcasting and recording guitar at home. Also, I throw in a quick comparison to the super low cost Behringer C1 and C3.

The porn:

The C900 behind a Roxdon pop filter. The C900 has a built in pop shield but this is not quite good enough
for the completely pop free sound one wants for a podcast or studio recording. Here I am using a low
level floor stand as a desk stand to give me more robust and flexible microphone mounting than a traditional
desk stand.

The Roxdon filter is very effective indeed and can be close to the microphone and still work. This is not the case
for some lower cost nylon mesh style pop filters I have used. As you can see here, the C900 has a very robust
spring steal basket over the element. I am not going to say this is as strong as a SM58, but you would need to
try very hard indeed to break it.

The capsule for the C900 is a thing of engineering beauty. The whole thing is gold plated. It is mounted on a flexible
disk with no part of it touching the rigid parts of the microphone body. Not only does this reduce handling noise to
a minimum, it also ensures that knocks and vibration on the microphone body are damped before they reach the capsule
and so the delicate capacitor element is defended from damage.

As I mentioned above, the Roxdon is an excellent pop filter. I would very highly recommend it to anyone. At first glance
one might think that the wider spacing of the wholes in the metal mesh compared to the more normal fabric would let pops
through, but the reality is that it just does not. Because the membrane does not deform, its performance is better than the
traditional design.

Unlike then C 900, the P 220 has no protection against handling noise in the microphone its self. As is traditional
with large diaphragm mikes, it relies on a spider mount to shield it against vibration from the microphone stand and is
not intended to be handled.

The Behringer C3 is a similar size to the P220 but might lighter and because of that
more practical. It is a shame that the sound quality is nothing like as good as either
of the AKGs. Note that both the Behringer and P 220 have base roll off and a pad
switch which are not available on the C900.

Here we can see the C900 (centre). Also there is a Little Dot MkIII headphone amp (bottom right) an AKG D109 (middle left) the
case for the P 220 (top left) and the mixer and some audio processors (top to middle right). Note that the pop filter is attached to
the microphone stand with gaffer-tape; some things never change.

The Perception 220 definitely looks the part. It is a very elegant piece of equipment with the highest of machining and production
standards. This mike is cardioid (as are the C900 and Behringer) with the peak of sensitivity in the direction of the AKG badge.

SQL - A Failed Experiment?

2012-01-18T21:44:00.000Z

Stars eventually explode to form clouds. It is the way of things.

Actually, it is the Relations Data Model which might well prove to have been a failed experiment or at the very most a brief distraction.

Relational data was first formulated and proposed in 1969 by Edgar F. Codd. The idea is very powerful when considered in the abstract. It is its very power that has become its downfall in many ways. I am not going to go into what relational data is exactly - wikipedia does that - but I will discuss some of its properties. If you understand relational data very well, I would still suggest you skim what I am saying here because I am framing the concept in slightly non standard (yet correct) terms:

To Subscribe: Feeds And Subscription

We define groups of data which have a one to one relationship with one another. For example, we know the SIM card inside a telephone will have one telephone number. This is a key feature of the relational model as all major databases use it now.
We say that other data have more flexible relationships to one another. These groups of 1:1 data can relate to any other group of one to one data. In the example above, we can consider a customer group which might have customer number and name and date of birth. One customer might no telephones or many telephones. This means we can relate the customer groups to the telephone groups in a 1 customer to Some telephones (for some reason we say Many where Some or even better some U none is actually correct).
It has become common practice to refer to these groups of 1:1 related data as TABLES and each individual group in a table as a ROW.
The individual data in a ROW are called FIELDS and the set of one particular FIELD in a TABLE is a COLUMN.

Kick back and relax, a job well done - if only!

How it should have worked

The above model works perfectly in theory. However, the reality of computer hardware gets in the way. The result of a relational model like that I have described should be:

Any system of data can be represented with maximum efficiency, i.e. no data redundancy.
Changes in data structure could be allowed for by altering the members of a group (IE the COLUMNS in a TABLE) or but introducing new TABLES.
Data can be read from the system by aggregating across any number of relationships in any order to create a result TABLE which we generally call a RESULT SET.
The life time of the RESULT SET need only be as long as it is being read because it is derived from the persistent tables.

So what went wrong?

You might expect me to start talking about performance now. I will, but the biggest problem is not performance. Real world data is the huge problem with the relational model. In the real world data has properties which cause terrible issues with the relational model:

It is labile
It is sparse
It is dirty
It is poorly defined

Let us take a look at each of these in more detail:

Data Is Labile
At the heart of the standard relational model is the idea of these 1:1 related groups. We call them tables most of the time. The snag is that a table structure locks in one description of the data. It becomes hard to define what should be in a table and that definition frequently changes. For example, how many fields should one for for a person's name? One answer would be 1, and other 2, a third 2 plus one for an initial; none of those are 'correct' and the whole lot is not exhaustive. If you go for a large number or say 4 name fields, then a lot of the time some will be empty. Does that make sense? Is it really modelling the data? Finally, what ever chose we make for the name fields, it is likely to change as demands on the data change. For example, if the system is used in a new country or a new marketplace.

"Why does this matter?" one might ask. There a number of reasons. They all come from considering what the point of a table is in the first place. By having tables we make retrieving the one to one related fields as a group very fast. This also make the storage and querying of the data more straight forward. However, all that comes at a cost. Those speed-ups are available by physically placing the fields near each other in whatever storage system is being used and by allowing their spatial arrangement to be computed with very little effort. Consequently, when we change the field definitions (add, remove, change) a lot of re-arrangement has to be done in the storage and this can disrupt the data system's performance or even destabilise it.

OK, so our data system has tolerated having a field added. Unfortunately, our application code might not be so lucky. Now records are larger and this could cause buffer overflows. Also, some code might make assumptions about table structure. These are not necessarily good coding practice (actually - they definitely are not) but they are a reality.

Data Is Sparse
Remember when I was talking about how many names a person has? That is a trivial example of sparse data. The truth is that data tends to be very sparse. We can try and force data to behave in a dense way, but the effort it completely artificial. To make peoples' names fit into dense data we have to pretend they fit some set of rules which they really do not. Names are a simple example, a lot of data is a lot more sparse. Consider that you use Facebook or Google+. How many of the features do you use? What settings to you have turned on for the features that you use? This is very sparse data because there is no point holding configuration data for all the hundreds or thousands of apps and/or features which you do not even use.

Some dirt!

Data Is Dirty And Poorly Defined
Real data is not clean; it has inconsistencies and irregular relationships. This comes from the underlying source of the data or errors in its collection. Consider a data system for modelling the relationships people have with one another. Can children be friends with their parents? How about conjoined twins - are they one or two people? We can keep asking such questions and keep answering them but the result will be either an artificially restrictive data model or a ridiculously sparse data model. Then, as I said, we have errors which creep in during collection. How about number plate recognition? That is imperfect so not all number plates as read by the system will match real number plates. Other read plates will be misread so they match to a different car which will produce the same results as someone using stolen plates.

To get real world data into the rigid model of traditional relational data is:

Very hard.
Very expensive.
Causes information to be lost.
Causes mistakes to be made.

However, this cleaning of data is completely essential because a traditional relational model either cannot cope with or will not work properly in the face of dirty data.

Star Schema And Materialised Views - Close But No Cigar

A higgledy piggledy mess of entities growing upon
one another,

When I say 'star schema' I am really talking about the snowflake. However, let's keep things simple. From wikipedea:

"In computing, the star schema (also called star-join schema, data cube, or multi-dimensional schema) is the simplest style of data warehouse schema. The star schema consists of one or more fact tables referencing any number of dimension tables. The star schema is an important special case of the snowflake schema, and is more effective for handling simpler queries.^[1]"

The idea is to have a central table of core entities and then a bunch of 'satellite' entities. These satellites are referentially associated with the centre and so represents dimensions of the data describing the centre. However, because of the flexible nature of the joins [Centre Dimension Some : Dimension Some] it is completely reasonable to have no records in a dimension table which relate to a given centre record. I.e. star (and snowflake) schema are storage efficient for sparse data. There two ways of defining a star. One can put foreign key in the centre (fact) table which relate to dimension items. It is possible to turn the model inside out (for which I will probably get flamed) where the dimension tables also act as fact stores them selves and have a primary key which matches the primary key of the fact table. Either was has similar benefits as described below.

Star schema are more stable in the face of data structure change as well. Where a wide table approach requires restructuring the table to add data columns to a result, the star schema can often achieve this by the addition of a new table or even just a new data type of an implicit enumeration (this subject is a bit beyond my discussion here).

The problem with the approach is that relationships are expensive to compute in real world computers. To put another way 'the relational model is too far from the machine' as I explained in this video/podcast. Because of this, the star schema approach is more flexible but much less performant than the more traditional wide table approach. The classic work around for this is to create materialised views.

A materialised view is where the database automatically (via DDL or triggers) updates a stored table with the results of a joining query every time the source tables are updated. The effect is that the cost the join is born at update time and not query time. Not only that, optimizations can be performed by the database management system to avoid a full join being performed for every update. This approach works very will in the face of the experience that data systems tend to be queried very much more often than they are updated. This holds true even for many on line transactional processing systems where a bunch of queries are required to gather the information necessary to formulate and process an update.

Click to feeds and subscriptions

Whilst these are a very clever ideas, they quickly become a huge mess of views growing off other views with complex update rules. Materialized views are in direct conflict with the benefits of sparse data and data structure flexibility so the work around removes some of the benefits of the star schema. In short, the lack of clean structure and the fact that materialised views are a definition of a query built into the data model moves they whole thing a million miles from the original ideas of Relational Modelling.

Give Up
Face it, the relational data model and SQL as the language for it have just failed to live up to their promise. As with many computational ideas, if the hardware was designed specifically for that idea (think a Lisp machine) then it would rock. Sadly, for the relational data model, this never really happened. Relational Databases (i.e a database with a relational model) uniformly used highly sequential storage systems (basically - Turing machines with a finite tape speed). Even modern memory architectures nearly always use multi-level cache systems which work on the principle of spatial locality in the main memory system and so exhibit somewhat linear access behaviour.

Cloud computing then came along and levelled a Magnum 44 at the relational model and said 'do you feel lucky?' It did not work out well.

The old idea of tables is a major problem in the cloud. For massively distributed storage we need to have just that - distribute storage. Systems like Oracle's RAC (real application cluster) are far to costly and heavy weight and to be honest do not seem to scale enough. The next solution is view partitioning where a materialized view or even the underlying tables are partitioned into 'shards'. This is just another one of those works-around which does not work that well.

The future appears to be the non relational, or No SQL, column oriented hash table style data stores. These became IT headline news with the publication of a paper by Google on their BigTable system. At one point I was of the view that a mixture of No SQL and SQL databases would be the future, but I am no longer convinced of even this. The reason that one might think a hybrid makes sense is that a commonly held belief exists of relational databases being good for or even necessary for transactional support.

As it turns out, neither of these propositions is true. The key to transactional support and transactional integrity is to have a single transactional arbitrator. Indeed, it is quite possible to have transactional data models writing in pure VBScript using a simple text file as the transactional arbitrator. As technologies like HBase and BigTable mature the support for transactional processing matures with them.

Loosely associated columns which can be efficiently stored even when very sparsely populated fits much closer to real data which is highly labile and sparse. The flexible ability to add and remove columns addresses the poorly defined nature of data; these are two of the key features of the cloud centric No SQL data systems.

As for dirty data, this can also at least be ameliorated using these systems. Because of the flexible and massive storage abilities of such data store it is possible to manage the data with loose integrity and then use flexible querying to mine information from them later.

New No SQL Cloud Storage Systems Are Actually Very Like Star Schema
What BigTable and the newer systems like HBase and Cassandra do is accept that data has a labile structure and so orient storage around a very flexible column model. They also accept that abstracting too far from the machine is not a good idea and so expose quite a bit of the machine's requirements into the data model (see Google's original paper).

Nevertheless, there are strong parallels between what star (and snowflake) schema are trying to do, and even how they do it, and these modern No SQL systems. Very wide, efficiently stored, highly sparse tables are a lot like a classic star where we have flattened a query across the fact and dimension tables.

Column families show the closer binding to the machine. In general, column families are stored temporally or physically close to one another. However, they also often require substantial data storage mutation to have columns added or removed. This does not reduce flexibility as much as one might expect because one can simply add columns in a new family. If the performance of using only family is required for a particular query, one can migrate to a new, combined column family and phase out the use of an previous ones.

What are my conclusions
I expect SQL and the relational data model to be around for a very long time. Just like IMS, they are unlikely to be going anywhere soon. However, the growth in storage in relational databases management systems (RDBMSs) will drop and will fall below the growth rate in data storage in general. In the mean time, storage in wide, sparse column based storage systems like HBase and BigTable will continue to balloon. In time, most people will think of these as the go-to data storage approach and such technologies will rapidly evolve and specialise.

Java: Threads Managed By Reference Counting: Avro and Netty

2012-01-17T21:55:00.000Z

'cause it made me laugh.

A client recently needed a good client server technology for high performance stateful communications. One option was Apache Avro and JBoss Netty. But - how to very quickly and easily test the non functional requirements?

We had a simple gate requirement before any further work would be performed. This was "it can handle 100 simultaneous clients on a developer class machine".

One combination I have looked at is Apache Avro with JBoss Netty. Avro doing the data serialization and Netty doing the communication handling. I wanted to try this combination and see if it could handle 100 simultaneous clients at the same time. This meant, 100 clients actually processing messages sent the received. By far the easiest way to test that was with a multi-threaded Java application.

This is where light weight reference counted thread management comes in. I wanted to:

Start the server
Wait till it was up
Start the clients
Show all of them had process at least one message and response before the first one ended.
Shut down the server when all the clients had finished

The first challenge was the waiting for the server to come up. I could have used thread wait and notify but I am far too lazy for that and it requires quite a bit of engineering to handle the thread interrupt states etc. So, the solution I went for was notification via a volatile boolean. This works great as a pattern where there is one thread writing and one or more thread waiting. It works especially well if there is just one thread writing and one threading waiting (reading the boolean) because a simple spin lock is not too wasteful in this case.

public class MyNettyServer {
public volatile static boolean started = false;

...

public static void main(String[] args) throws IOException {

Thread tserver = new Thread() {

... launch the server here

};

tserver.start();

while(!MyNettyServer.started);

Above we can see the pattern. The main thread starts the thread which launches the server. Once the server is up the while loop will exit and the rest the the code in the main thread will execute. Using a volatile this way is safe because the Java Memory Model guarantees the consistency of read and write across all threads on a volatile.

That was all fine and easy but what about checking all 100 clients are simultaneously working and then shutting down the server when all clients have finished? For this I used AtomicInteger. This does not use classical synchronisation. It uses a special hardware instruction (usually this is CAS - compare and swap) to ensure the value of the integer it represents is consistent under read,update and write conditions across all the threads (note the 'update').

The difference form a volatile can be illustrated thus: To increment a volatile we need to read it, increment the read value and write it. In between the read and write another thread might have updated the value. With AtomicIncreament, this cannot happen; the value is increased in place by trying to update it using the special hardware instruction and if that does not give the expected result - trying again until it does (hence: compare and swap).

Here is the final code in which I use two AtomicIntegers. One is used to count (reference count) the number of client threads. When this hits zero the server is shut down. The other is used to count the number of clients which have managed to send a request and get a response. If that number goes to the required level before the first client closes, then the test is passed (I have marked in bold the places that AtomicInteger is used):

package avrotest;

import java.io.IOException;
import java.net.InetSocketAddress;
import java.util.concurrent.atomic.AtomicInteger;

import org.apache.avro.AvroRemoteException;
import org.apache.avro.ipc.NettyServer;
import org.apache.avro.ipc.NettyTransceiver;
import org.apache.avro.ipc.specific.SpecificRequestor;
import org.apache.avro.ipc.specific.SpecificResponder;
import org.apache.avro.util.Utf8;

public class MyNettyServer {

    public volatile static boolean started = false;
    public static AtomicInteger refCount = new AtomicInteger(0);
    public static AtomicInteger clientCount = new AtomicInteger(0);
    public static NettyServer server;
    
    // A mock implementation
    public static class NubLookupImpl implements DogLookup {
        public Response send(Request request) throws AvroRemoteException {
            Response r = new Response();
            r.setKennelId(100);
            return r;
        }
    }
    
    private static class TClient extends Thread {
        public void run() {
            NettyTransceiver client = null;
            DogLookup proxy = null;
            try {
                client = new NettyTransceiver(new InetSocketAddress(
                        server.getPort()));
                proxy = (DogLookup) SpecificRequestor.getClient(
                        DogLookup.class, client);
                Request req = new Request();
                req.setName(new Utf8("Hector"));

                long x = 0;
                int i = 0;
                for (; i < 1000; ++i) {
                    x += proxy.send(req).getKennelId();
                    if(i==0)System.out.println("Client " + clientCount.incrementAndGet() + " is started");
                }
                long t1 = System.currentTimeMillis();
                x = 0;
                i = 0;
                for (; i < 10000; ++i) {
                    x += proxy.send(req).getKennelId();
                }
                System.out
                        .println("Took: "
                                + (((double) (System.currentTimeMillis() - t1)) / ((double) (i - 1))));
            } catch (IOException e) {
                e.printStackTrace();

            } finally {
                if(refCount.decrementAndGet()==0){
                    System.out.println("Closing server");
                    server.close();
                }
                client.close();
            }
        }
    }

    public static void main(String[] args) throws IOException {
        Thread tserver = new Thread() {
            public void run() {
                MyNettyServer.server = new NettyServer(new SpecificResponder(
                        DogLookup.class, new NubLookupImpl()),
                        new InetSocketAddress(7001));
                MyNettyServer.server.start();
                MyNettyServer.started = true;
                System.out.println("Server started");
            }
        };
        tserver.start();
        while(!MyNettyServer.started);
        for(int c=0;c<200;++c){
            refCount.incrementAndGet();
            System.out.println("Count is: " + refCount.get());
            new TClient().start();
        }
    }
}

By the way, it did pass with flying colours. On my Dell E6410 it managed 200 simultaneous connections. I will write more on the performance of Netty and Avro another time.

5 Reasons: Relational Data Failed

2012-01-16T13:16:00.000Z

Looking at things from a different angle.

Many think that the relational data model became the go-to solution for data storage and persistence. Actually, that was something of a fashion which never fully took hold (think of IMS) and is now in sharp decline.

To Subscribe: Feeds And Subscription

In this podcast and video I discuss the 5 top reasons for why relational data and the relational data model has never fulfilled this promise it had and why now it can be seen as a failed experiment:

The Podcast [accelerated form for fast listening]
The Podcast home page
The Video on Youtube
The video embedded:

Technical Note: The the audio was recorded using an AKG C900 microphone, a value pre-amp and a Behringer compressor plus some electronic effects. The video was recorded using a Logitech Webcam Pro 9000 HD and then the two were knitted together in Sony Vagus.

Video: How To Record Acoustic Guitar At Home

2012-01-16T09:48:00.003Z

A few days ago I posted a text and audio version of this here. Now there is a brief video tutorial showing what to do, how to save money and generally make your life as easy as possible:

The video is embedded below or you can watch it on the nerds-central video channel.

No Quarter - Page And Plant

2012-01-13T20:41:00.000Z

The source of this image is
wikipedia and not Nerds-Central. This
is an embedded version.

This is an amazing album. I just love how different it is. The skill of the two musicians shine through but they are prepared to experiment and try new tonal patterns, rhythms and temperaments.

It was released by Atlantic Records on 14 October 1994 but is still available from Amazon.

If you are expecting Led Zeppelin then you are looking in the wrong place. These two guys went and grew up and so did their music. This is a much more interesting affair. I love Led Zeppelin, don't get me wrong, but it is young men making testosterone soaked music with massive talent. This is grown men making amazing music with massive talent and huge experience.

Some tracks:

"Since I've Been Love'n You" is almost a straight replay of the original. However, the guitar work puts the original recordings to shame. Jimmy Page is proving he still 'has it' in does so with flying colours. Listening to this track is exhausting because it is so powerful.

"Friends" is amazing because it mixes the musical styles of Morocco with those of Anglo/American tradition. This works very well as Page and Plant are sympathetic to the different keys and temperament of the Moroccan music. The effect is hypnotic and moving.

I love this album. I bought it as mp3s and have now also bought the CD to squeeze those last few bits of resolution from the music. I would highly recommend this to anyone interesting in very good music.

*018-End Of The Gold Rush* The PC/Internet 'Gold Rush' is coming to an end. The digital land is grabbed and business is returning to the more normal forms of competition and consolidation. I compare this to previous tech' gold rushes.	62.9 MB
*019-P-ing-Around-With-Dubstep.mp3* Dub-step via direct wave form synthesis from Audacity. I show some ideas as to how to do this. Just for fun!	10.4 MB
*020-Drums-From-First-Principles.mp3* This is closely related to the previous podcast. Here I demonstrate how to use waveform generation in audacity to make drum sounds from first principles. I found this a very exciting project to work on because it became apparent that I could create some really interesting drum effects without a drum of a drum machine.	22.3 MB
*021-Software-Success-Bites.mp3* Some quick and punchy advice on how to really be successful writing software. Some of these are counter intuitive and run against accepted dogma...	14.9 MB
*022-Non-Visible-Disability.mp3* I have a non visible disability and so do some of my loved ones. This is a personal view on how people can and should think about the impact such disabilities have on people and be less prone to assume not being able to do a thing, or doing it slowly, is a sign of laziness of lack of application.	16.4 MB
*023-Doing-The-Square-Dance.mp3* An introduction to a very fast and powerful technique for decision making.	45.1 MB
*024-Behringer Virtualizer* A review of the DSP2024 from Behringer.	10.5 MB
*025-Capitalism-Needs-Net-Neutrallity.mp3* Quite often subjects like net neutrality get painted as right against left, restriction against freedom. However, capitalism requires net neutrality just as much as social democracy.	11.3 MB
*026-JVM-And-The-Dynamic-Revolution.mp3* Java 7 is the far side of the tipping point. Real-time, dynamics support, optimization and performance are all coming together. In ten years time we will look back and say 'that was when it all started'.	53.6 MB
*027-New-Media-And-Emancipation-Of-Knowledge-Workers.mp3* New media is an amazing 'place' for highly technical people to liberate themselves from their traditionally highly controlled role in the commercial world.	12.8 MB
*028-Why-Thorium-Matters.mp3* My son asked me if all this chatter on the internet about Thorium reactors is for real. Yes - it is for real and it could be a huge step forward for humanity.	23.8 MB
*029-The-Three-Pillars-Of-JNI.mp3* JNI can be tamed. Here I introduce the three pillars. Building all JNI coding on these is the key to successful, pain free, reliable code.	21.1 MB
*030-Heat-Death-Of-Programming-Languages.mp3* Does the very success of a language spell its doom. Is the heat death metaphor appropriate for large, popular languages like C#, and C++. I suspect it is and that it helps us understand why there is always a new kid on the block.	18.8 MB
*031-wav-vs-mp3.mp3* No doubt you have read about the difference between mp3 and wav (or flac). Mp3 is 'lossy' and so what you get out is not quite what you put in. Here I actually demonstrate what the difference sounds like.	7.8 MB
*032-5-Counter-Intuitive-Ideas.mp3* A lot of what is said about software development and how to be successful in it is wishful thinking. Sometimes real success comes from techniques and ideas which run counter to common sense.	25.4 MB
*033-Wind-Farms-Are-Evil.mp3* Following the honesty of Prince Phillip, I would go further. Wind Turbines are not just a stupid idea, they are actively evil.	7.3 MB
*034-Behringer-SX3040-Review.mp3* A review of the SX3040 sonic exciter.	24.6 MB
*035-The-World-Is-Amazing.mp3* Next time you hear someone spouting doom and gloom just think about these facts and figures!	14.5 MB
*036-equal-and-just-temperment.mp3* Temperament is a music term relating to the tuning of music. There are many temperaments, however, western music has settled on a very mathematical one called "equal temperament".	24.9 MB
*037-Autism-And-Criminal-Justice-Research.mp3* We must improve the way people with Autism and Autism related conditions are treated by the justice and health systems. The only we can get better at this is to learn more about it! Please, please please support the research being done by Birmingham University here in the UK for the benefit of all autistic spectrum individuals, the carers and families .	49.5 MB
*038-Why-Learn-C++* In this Podcast I explain 5 reasons why the best bet is C++.	12.2 MB
*039-Recording-Acoustic-Guitar.mp3* It is all very well talking about recording with baffles, expensive software and a full 'home studio'. How can you lay down a good acoustic guitar recording in a normal home?	8.6 MB
*Cut-The-Climate-Bull.mp3* This podcast covers some of the 'Bull 5h1t' spoken about how we as individuals should respond to the climate change issue - and it also suggests what we should really do. (note that this pre-dates my podcast on Thorium which takes the concept further and also see "why wind farms are evil".	8.6 MB	6.6 MB
*Filters-Podcast.mp3* I have moved on a lot since I recorded this podcast on filtering voice with Audacity. However, there are some tricks and pointers in there which are quite relevant.	50.9 MB
*From-Facebook-To-Placebook.mp3* "Insights into the next few years of IT revolution based on events of 2010." Was I correct?	22.5 MB
*How-2-Podcast-1.mp3* An early explanation of how to podcast. I have not listened to this for some time so I am not sure how good the advice is!	18.0 MB
*Inovation-And-Success.mp3* Success is the enemy of innovation; know thy enemy!	55.4 MB
*Internediation-Via-Money-Wrecks-Countries.mp3* Our current habit of intermediating all human interaction via its monetary value is wrecking the country and the lives of its citizens.	9.9 MB
*Niceness-First.mp3* Before all things be nice - why not?	17.0 MB
*Podcasting-Fun-And-Powerful.mp3* I recorded this because my experience at Micro Focus showed me just how effective internal podcasts were at helping bring together large organisation and pass information around. Somehow more effective than even videos.	22.8 MB
*Russian-Roulette.mp3* Business dogma, education, analysis and literature is fatally flawed in many, many cases by a simple yet fatal error in sampling. This error is so serious that I believe it to be a contributing factor in the resent meltdown in the financial markets and banks.	27.6 MB
*Signal-Processing-With-Multiple-Mikes.mp3* Some tips and tricks for processing with multiple mikes. Honestly, my technique as move on quite a bit since I recorded this.	12.5 MB
*State-Power-And-Privacy.mp3* Thoughts on the balance of power between the state and the individual and in the arena of privacy.	16.0 MB
*Stop-Wikileaks.mp3* I recorded this at the hight of the massive Wikileaks scandal. I describe how, even though each document is unimporant, the release of so many is very dangerous and undermined the very principles Wikileaks stands for.	10.3 MB
*The-Tsunami-Revolution.mp3* The Tsunami Revolution was what I called the revolution just starting at the time I was recording this but getting well under way now. The revolution caused by cellular communication and super small computational platforms.	29.5 MB
*Thoughts-On-Positive-Feedback.mp3* Based on real internet experience, but the feedback culture of the internet and (ever more so) other media can massively distort what we think is good and what ends up being famous and successful.	10.3 MB	7.4 MB
*Tonal-Effects.mp3* Some tips and tricks for processing tone in Audacity.	7.6 MB
*Tsunami-Part-Two.mp3* More insights into this revolution, then starting now upon us.	46.3 MB
*Wiki-Leaks-Part-2.mp3* More on the Wiki-Leaks scandal. Wow - that seems like a long time ago now!	13.6 MB

Project	Luck	Center	SD	Response	Initial	Risk %	At Risk	Output	Profit	Tax	Result
A	0.14	1.10	0.50	0.55	1000.00	25.00	250.00	138.47	-111.53	4m0.00	888.47
B	0.88	1.20	1.20	2.64	888.47	25.00	222.12	586.09	363.97	0.00	1252.44
C	0.65	1.50	5.00	3.36	1252.44	25.00	313.11	1052.44	739.33	40.00	1991.77
D	0.14	1.50	0.20	1.28	1991.77	25.00	497.94	638.96	141.01	40.00	2132.78
E	0.13	2.40	0.60	1.74	2132.78	25.00	533.20	925.23	392.03	40.00	2524.81

Interval	Ratio to Fundamental Just Scale	Ratio to Fundamental Equal Temperament
Unison	1.0000	1.0000
Minor Second	25/24 = 1.0417	1.05946
Major Second	9/8 = 1.1250	1.12246
Minor Third	6/5 = 1.2000	1.18921
Major Third	5/4 = 1.2500	1.25992
Fourth	4/3 = 1.3333	1.33483
Diminished Fifth	45/32 = 1.4063	1.41421
Fifth	3/2 = 1.5000	1.49831
Minor Sixth	8/5 = 1.6000	1.58740
Major Sixth	5/3 = 1.6667	1.68179
Minor Seventh	9/5 = 1.8000	1.78180
Major Seventh	15/8 = 1.8750	1.88775
Octave	2.0000	2.0000

Note	Just Scale (Hz)	Equal Temperament (Hz)	Difference (Hz)
C4	261.63	261.63	0
C4#	272.54	277.18	+4.64
D4	294.33	293.66	-0.67
E4b	313.96	311.13	-2.84
E4	327.03	329.63	+2.60
F4	348.83	349.23	+0.40
F4#	367.92	369.99	+2.07
G4	392.44	392.00	-0.44
A4b	418.60	415.30	-3.30
A4	436.05	440.00	+3.94
B4b	470.93	466.16	-4.77
B4	490.55	493.88	+3.33
C5	523.25	523.25	0

Nerds Central

C++11 Makes Competitors Go Rusty

ParkView Guest House Cambridge: Try It!

Phase: The Secrets Of Stereo Recording

Ode To A Mid Life Crisis

Vintage Microphone With A Modern Twist

Systemic/Reflective Agile Teaming

How Fast Is A Chromebook?

Review: AKG Perception 220 vs AKG C900 vs Behringer C3

SQL - A Failed Experiment?

Java: Threads Managed By Reference Counting: Avro and Netty

5 Reasons: Relational Data Failed

Video: How To Record Acoustic Guitar At Home

No Quarter - Page And Plant

ASD/Aspergers Research: Thanks And More Support Needed :)

Using The Internet Archive To Store Podcasts

How To Record Acoustic Guitar At Home

Nerds Central Images

Elastic COBOL: The Future Of IDEs Is Here

5 Reasons: What Language Should I Learn?

Hadoop: Quant Calculations With Distributed Excel - 1

Research-asd.org.uk Interviewing Researcher

ASD/ASC: Please Support This Vital Research

Currying: Big Decimal Internal DSL For Java

IKey M3 Review

Off The Chart Epic Sound

Equal And Just - Temperament Demonstrated

Chromebook: Long Term Review

Agile Meetings And Anchoring

Proof Apollo Images Faked!