AmanziTel Blog
Amanzi Wireless Explorer: AWE Architecture Presented at Öredev
Posted at June 03, 2011 16:58
The number of downloads of alpha releases of AWE has started to accelerate, by late October we had passed 100 downloads, and considering we invited far fewer people to the early access trials, we are very pleased with the level of interest. In addition, customer feedback has lead us to expand the project plan to include an additional alpha release before the public beta:
- alpha1 (0.5.x), September '09 (35 downloads)
- General GIS, Distribution Analysis (Reuse-Analysis) and various network data imports, and a specific TEMS drive import (including distribution analysis of network and drive data)
- alpha2 (0.6.x), Sept-Oct '09 (21 downloads)
- More extensive drive data import, Star Report (relationships), Neighbour import, Delta report (network comparisons)
- alpha3 (0.7.x), October '09 (142 downloads)
- Faster drive import, better stability and performance, spatial index in Neo4j, inclusion of the new drive event inquirer
- alpha4 (0.8.x), November '09
- Re-inclusion of Amanzi Splash, the Ruby scripted spreadsheet, more use of AWEScript, prototype report builder
- beta (1.0.0), Nov-Dec '09
- Performance, stability and refinements to above feature set
Amanzi Wireless Explorer: Neo4j Spatial Project
Posted at June 03, 2011 16:58
The Neo4j Spatial Project started in February 2010 with the publication of the project wiki at http://wiki.neo4j.org/content/Neo4j_Spatial. Now in March 2010 the project has begun active coding with contributions from the developers from AmanziTel and Neo Technology. In addition plans have been initiated to mentor a Google Summer of Code project on the up-coming Neo4j Spatial framework.
Ian Vernon's Blog
Customer Experience Directly from Mobile Devices
Posted at February 15, 2012 15:57
What does this mean for us who are in the telecoms industry? Does this mean that we should now all drop our CEM solutions because of privacy concerns? To my little world I believe we should not, but we should also avoid the pitfalls that carrier IQ have gotten themselves into. Managing customer experience is important to the network operators to ensure they deliver the best service and the correct level of service to each subscriber. It is equallly important to subscribers so they do not get bombarded with advertisement and offers that they do not want aside from the satisfaction of a good mobile / cellular network service.
Subscriber activities are actually being captured by the network even without the device agents by using network probes that records everything about a subscriber activity. This solution is not only expensive but can also be considered as breaking privacy laws, since it captures subscriber activity without the knowledge of the subscriber. The question to my mind is what CEM solution is actually efficient, effective and acceptable by subscribers or mobile phone users. There is no holy grail here but I can offer an answer. Native applications.
The main problem with embedded application or network probes is that the subscriber and phone user are not aware of the records being made, there is no opt-in or opt-out possibilities. With a native app the subscriber or phone user can easily install such CEM app if they want to and can easily remove it as well. Awareness I think is the key.
For network operators perhaps the best approach is to only have device agents on the subscriber phone to solve issues notice by the subscriber instead of recording everything the subscriber phone is doing. One such application is GEOptimA.
Traditional Drive Testing is at RISK!
Posted at January 30, 2012 22:06
In drive testing we normally simulate user experiences based on calls, data sessions and other test scenarios conducted where potential subscribers are located. Now with so many smart phones in the market the focus has moved towards testing smart phone performance and user experiences where they use the mobile network services, especially data services. Since 2006, new breed of testing companies have poped out, they do not simulate tests rather they capture actual user experiences. The difference is that in traditional drive testing, low level messages such as layer 3 are captured in CEM applications it is purely user activities that are captured.
For trouble shooting purposes, drive testing is hard to replace. However for gathering customer experience, behavior and usage then drive testing is no longer the answer. To fix network issues and improve network performance then there is still a need for the traditional drive testing since the lower level messages has to be captured, measured and analyze to adjust the correct radio, transmission or core network parameters.
Having said this hybrid CEM solutions have started to emerged in the market. This employs a combination of passive testing (pure CEM, capturing user experiences, behavior and usage) and active testing (similar to drive testing but without the traditional laptop based equipment). With this hybrid solution it is now possible to deploy commercial handsets preloaded with advance firmware to thousands of subscribers supplemented with the traditional CEM to millions of subscribers By doing this it gives network operators everything they are looking for. A solution that is easy to deploy, captures actual subscriber experience and at the same time provides the low level information needed to fix network issues.
With the correct solution deployed, every subscribers contribute into improving their experiences in the mobile network they are using and at the same time ensures they are provided the best service possible.
Phones.... smarter phones and how we interact with this devices
Posted at December 27, 2011 23:14
How fast do you analyze 65,000,000 phone calls? and 7TB of data?
Posted at December 21, 2011 11:53
Blogs and Customer Engagements, do they go together?
Posted at December 13, 2011 08:09
Craig Taverner's blog
One liner multi-image cropping
Posted at October 29, 2009 11:09
A simple entry for a simple way to solve a common problem.
I often have a lot of scanned images, documents usually, that have unnecessary white-space, and other artifacts around the edges due to limitations in the scanner software or issues with the scanner itself. Normally I use the gimp, and can correct orientation problems, colour issues and cropping very easily. But this is too much mouse work in my opinion when you have 50 images and all need a similar simple cropping. So I fiddled around in the shell a little and came up with this one-liner:
for file in *.jpg ; do echo "Cropping $file" ; \
convert -trim $file trim/$file ; \
convert -crop 1692x2190+4+4 trim/$file crop/$file ; done
OK. Not really one line, but I swear I did write it on one line :-)
What it does is three things:
- loop over all image files, and for each:
- trim all white-space off the edges, bringing all images to the same basic size with the top left of the real data at the top left of the image
- trim them down to a specified size, in this case a little smaller than US letter size. I cut 2 pixels off each edge just to remove some noise commonly found on the edges of scanned images.
original image with many artifacts
first trim removes continuous whitespace
final cropped image at letter size with edges removed
It took about 10 minutes to figure out this script, 20 seconds to run it on all 50 images, and then 20 minutes to write the blog!
Complexity threshold
Posted at October 15, 2009 09:14
I've been planning to write a proper article about this for years, but inspired today by Dan Pink's excellent presentation on the surprising science of motivation, I thought I'd write a mini-version of this, as an introduction and a reminder to myself to write the real one.
Back in 2006 I wrote a blog titled 'The perception of control', dealing with uninformed decision making and the illusion of efficiency, commonly found in control-based companies. Allan Kelly gave a detailed and informative response, including the statement "The fundamental problem facing developers is Complexity. Attempting reuse simply increases complexity."
This got me thinking, and I remembered a long series of interesting experiences I had regarding attempts to scale up development teams, and the very mixed results I got. These days most people know about 'The Mythical Man-Month', but I had experienced many occasions where I needed to argue this point with people that did not. I'm embarrassed to say I was one such person for a while, and needed to learn the hard way myself. One advantage of learning the hard way is that you are forced to try to explain what happened, to yourself and others. So I though about it, and noticed a number of interesting correlations:
- Adding people to projects works to some extent for very small teams, but can quickly get out of hand. It seems as if a threshold is crossed after which the project becomes a death march.
- Assigning tasks of varying levels of complexity to a specific developer has a remarkably similar threshold. Their performance is consistent until they pass some level of complexity, after which the task goes _pear shaped_.
- New developers on old code can perform well if the code is relatively simple, and perform extremely badly if it is not. Most critically, code that is twice as complex does not half the performance. The effects can be much worse. Again there seems to be a threshold.
- Each developer has their own threshold, after which the complexity becomes hard to manage. Obviously this threshold is not fixed, and depends on many factors, including their state of mind. Dan Pink's presentation demonstrates an interesting effect where increasing motivation decreases performance for creative tasks. He says increased focus can decrease problem solving skills. I agree, and see a correlation, since decreased problem solving skills means the developer will have a much lower _complexity threshold_.
- The team has a threshold, very strongly correlated to the level of communication in the team, and most of the Agile software development approaches have a lot to say about how to deal with this problem. Usually they try to increase communication and couple that to catching problems early.
- The project can obviously range from simple to very complex. Many approaches to dealing with this complexity are to split the project into modules and build teams on each, but in many cases this merely replaces one type of complexity with another. The more modern solutions to this involve prototyping, re-factoring, TDD and BDD.
Since this blog is merely an introduction to this idea, I will end off with a short piece on how I think we can help individuals keep on the _good side_ of their personal complexity thresholds. I have normally focused on two approaches, but Dan Pink has shown me a really nice new take on this. Let's start with my classic view:
- Identify the threshold and avoid it. Ok, this sounds like a cop-out, but what I'm talking about is assigning tasks to team members based on their natural skills, and so reducing the risk of crossing the threshold. Of course, one of the best ways to do this is to get the developers to pick the tasks themselves, as common in several Agile approaches, like Scrum. This is a good start, but does not always work, because while some developers pick the easy tasks and perform well, others are suckers for a challenge. So sometimes you need to advise them. An external opinion can make all the difference. If you are the developer yourself, learning to identify when you're in trouble is a valuable skill, but you will also get help to do so in an Agile team, especially if you use pair programming.
- Adjust the developers threshold. Ok, this one sounds hard. Not really, when you realize that this might be as simple as additional training. But one area that really matters is helping the developers identify the thresholds themselves and respond to them. It can be very hard, when stuck in a complex problem, to see outside the box. Again, working in an agile team really helps here. Getting a second opinion on something, even if you might not realize you need it, can make all the difference.
- Autonony - the freedom to define your own life. In my world that can mean something as simple as allowing the developers to pick their own tasks. I also see this respecting their opinions in design meetings. In fact anything that tries to break the control-based management I described in 'the perception of control' is a good start.
- Mastery - the desire to get better and better. Obviously this can mean training, but coupled to the first point it can mean the option to develop ones career in the direction that one has a passion for. For more on the use of the word 'passion' in this context, I advise reading 'The Hacker Ethic and the Spirit of the Information Age'.
- Purpose - the yearning to do what we do in the service of something larger than ourselves. Ok, being a fan of open source, this sounds great. Of course it is both more subtle and more applicable than that. People want to do something good, or something of note. In a software project this can be as simple as assigning key features to developers. Someone constantly getting the boring stuff is bound to perform worse.
Dan finishes with a introduction to ROWE - the 'results only work environment'. I've been playing with a few ideas in this area, and I'd love to report on them, but need to do that in another blog :-)
Boolean behaviour
Posted at July 31, 2009 15:00
I recently spent a good half hour debugging some grails unit test code, only to track the problem down to groovy's boolean behaviour. As a Ruby programmer I've become spoiled by the clean and simple predictability of Ruby booleans, and since groovy is visually so very 'Ruby'esque' I was only too easily deceived.
So, I've made a little summary of different programming languages boolean behaviour. IMHO There are only two modern languages with simple boolean Rules, Ruby and Java, and the rest are unreasonably complex:
- Java - no coercion, only Boolean/true/false are valid
- Ruby - no coercion, only nil and false are false, all else is true
- Python - no coercion, a ton of rules for deciding what is true/false
- Groovy - coercion to true/false, with a ton of rules for deciding which way to go
- Perl - no coercion, a ton of rules for deciding what is true/false
- C - no coercion, 0 is false, all else is true
- Simple rules, in which case Java, Ruby and C rank high
- Simple syntax, in which Ruby and C rank high
- Enables expressive code, in which Ruby ranks high, and Python, Groovy and Perl do quite well (and Java does very badly)
a = (a == nil) ? 'default' : aAFAIK, this is possible as a direct result of the simple boolean logic, and in particular the fact that everything is true except false and nil.
a = a || 'default'
a ||= 'default'
The groovy book I read claims similar behaviour, but it in fact is not true. The book claimed the following equivalent statements:
a = (a == null) ? 'default' : aAnd if you have a=nil (a=null in Groovy) both the Ruby and Groovy code behave the same. But just try pass in a='' (empty string), or a=0. Ruby will keep the assignment passed in, while Groovy will re-assign to 'default', not what you expected, and not what the Groovy book claimed.
a = a ?: 'default'
The problem here is that Groovy, Perl and apparently Python, decided to try make developers lives easier with some convenience rules for booleans, notably that integer 0, empty strings and empty collections are all seen as false. And honestly, there are many scenarios that is useful, and I've used that fact for years in Perl. And when I first started Ruby coding, I balked at the idea that 0 and '' were true. But it did not take long to see the light. And then I began to remember the pain I had debugging Perl code where the bug was due to an unexpected false when an operation returned a numerical zero or an empty string.
Sorry, I'm convinced. Ruby got it right!
And the remaining question is: since Groovy clearly copied a lot of Ruby syntax, why did they not do it the Ruby way with booleans? Actually I think the answer is obvious once you think about it. Groovy is actually Java inside. Groovy tries to bring nice modern dynamic scripting capabilities to the Java language. Quite a paradox that Java, with the most rigid, predictable boolean behaviour, and the easiest debugging of the lot, should end up with this kind of scripted boolean. What I believe happened is that Groovy decided, quite naturally, to go with the coercion approach to scripting Java. Deep down it is all Java with strict types and strict booleans, but in between Groovy is coercing and converting all types automatically. This approach has been used all over the place.
And once you're on the coercion band-wagon, I think the end result is exactly what Groovy has.
Recruitment a'la open source
Posted at June 08, 2009 14:46
I just read Allan Kelly's blog criticising 'Foie Gras recruitment'. Allan's point is that adding developers too quickly has the opposite effect than intended, slowing down a project. In fact, recruiting always slows things down before it speeds things up, due to the cost of training up and familiarizing developers with the company processes, product vision and code.
However, there are many factors that affect this, and influence the severity of the problem as well as the teams ability to deal with the problem. Allan mentions one, the teams processes and practices. However, another really important one is the character of the developers involved, especially the new ones.
Imagine the hypothetical case where you magically recruit only developers that are actually capable of such a high level of self training that the negative impact on the team is much less than average (obviously never zero). Imagine also that the answers to the questions are usually available without another team member having to spend time. For example, the answers lie in the code itself, and any associated well written documentation, including feature specification, project goals, etc.
Obviously this is a hypothetical scenario essentially never achieved in corporate development, but it does exist in the real world, in many open source projects. Often people enter open source projects because they did their own self-training, read the code, tried things out and made working contributions that were good enough to get the attention of the project owners, and as a result received admittance to the team. This scales much better, and faster, than normal recruitment. So why does this not happen in the corporate development world? Usually because it relies on statistical factors no often achieved, related to the percentage of available developers of sufficient and appropriate skills, also sufficiently interested in the project to put in the time. This is a low number, especially when you consider that by the term 'interested' I also imply that the developer is able to make a living from this activity.
So how do corporate development projects benefit from this? Or can they? The problem being that corporate projects are, almost by definition, not interesting enough to the potential developers.
Personally I believe it is possible to find a middle ground, if you close the gap from both ends:
- move the project goals closer to the developers goals (make the project much more interesting to open source developers, make it open source, make it do things more interesting to a wider audience)
- move the developers goals closer towards the projects goals (ie. pay the developers)
Is this really hypothetical? No, I've actually been putting this into practice with my most recent recruitment drive. I recruited three new remote developers without reading a single CV or holding a single interview. Instead I simulated the open source approach by using the following steps:
- require a code contribution, which was evaluated (testing not only coding skills, but ability to read specs, work remotely, solve problems independently, do internet research, and perform self-training)
- contract for a trial period, testing their ability to perform with other remote developers, double checking their skills, notably an increasing understanding of the project itself
- contract for longer periods with tighter integration into the team
One final point. This approach does not solve the problems identified by Allan Kelly. It only serves to reduce their impact. And it does introduce another set of problems related to efficient project management of loosely coupled remote teams. That is a subject for separate blog :-)
The Secret of Googlenomics
Posted at May 25, 2009 15:16
I just read an amazing and insightful article in wired about the 'Secret of googlenomics', which was an riveting introduction to the auction based principles that have become the core of almost everything at google. And even more importantly represent a possible future for many other modern elements of the future economy.
Most of the article references a presentation given by google's chief economist, Hal Varian, who's career was inspired by Isaac Asimov's books The Foundation Series: "In Isaac Asimov's first Foundation Trilogy, there was a character who basically constructed mathematical models of society, and I thought this was a really exciting idea. When I went to college, I looked around for that subject. It turned out to be economics."
I was also inspired by Asimov's theory of 'psychohistory' when I read those books back in the early 90's, but unlike Hal, I thought the idea was entirely impossible, and so I stuck with reality and studied pure science. Perhaps I was wrong, as google's mathematicians now do take into account everything from the weather to peoples fashions and buying habits, to predict the best adverts to use on search results.
I strongly recommend reading the entire article at http://www.wired.com/culture/culturereviews/magazine/17-06/nep_googlenomics. For a taster, here is the concluding paragraph:
There's a wild contrast between this sparsely furnished residence and what it has spawned—dozens of millionaire geeks, billions of auctions, and new ground rules for businesses in a data-driven society that is far weirder than the one Asimov envisioned nearly 60 years ago. What could be more baffling than a capitalist corporation that gives away its best services, doesn't set the prices for the ads that support it, and turns away customers because their ads don't measure up to its complex formulas? Varian, of course, knows that his employer's success is not the result of inspired craziness but of an early recognition that the Internet rewards fanatical focus on scale, speed, data analysis, and customer satisfaction. (A bit of auction theory doesn't hurt, either.) Today we have a name for those rules: Googlenomics. Learn them, or pay the price.
