Well, sorry, (to myself as much as any readers) that I've not been posting regularly over the past couple of months. I got a bit distracted in October with the day-job and didn't really get to properly follow-up any of the interesting stuff that I was following through Oct-Dec.
It's been an interesting period, which I'd love to blog more about, but can't easily do without tripping over the aforementioned day-job. Still, in the time, I've had a good technical grilling, returned to China after nearly 20 years and have been astonished by the scale of change and been able to give my annual guest lecture at one of the local universities.
As Christmas and the run-up is usually a manic period, for the usual festive and other family reasons I also haven't had a quiet period until now.
So, my New Year's resolution last year was to start a blog, which I've done and been quite pleased how it works. It has been a great experience and a chance to get down some of the things I have been noodling about with and great ideas from others I've noticed in the press or otherwise.
What have I learnt? Well, writing good technical posts takes a lot longer than I'd thought. However, the discipline of getting those thoughts down is really worthwhile. I have also found myself half writing posts and sort of writing them in draft and not getting to finish them almost as a thought placeholder to myself. Useful, but also less useful in terms of sharing or getting comments. So, next year, I'm going to try and post shorter stuff more regularly.
I also thought I'd blog more about completed projects, but have found myself wanting to write (if only for myself) about what I'm finding that interests me and can see this as a series of flirting interests that are connected up myself, but not so easy to see externally without context.
Anyway, my thoughts for the lull period between Christmas and New Year was to try to get some of those drafts into finished posts, so if you've been looking, thank you! There will be a bunch of posts from over the summer and odd other points that may well just start appearing!
Happy New Year!
Tuesday, 30 December 2014
Tuesday, 16 December 2014
Sony (FES) eInk Watch Concept
I've long been a fan of eInk technology and like everyone else have been following the various offerings into the new eWatch space. The problem is that all of the Android and AppleWear watches seem to try to be being too clever and missing the main point of a watch which is to reliably tell the time. Now, when I mean reliably, I mean it has power. The problem with most of the offerings is that they have minimal life, which means that they can't meet the basic purpose without a lot of hassle.
Now, here is the FES Watch prototype that has come out of Sony. There are a couple of things I really like about this and it particularly marks a return to form for Sony with something clearly innovative and with a good understanding of what the user might want. Kind of like the first inkling that made them famous, understanding the need for personal audio and matching that.
Firstly, I love the clean design. Simple, minimalist, I could see myself wearing this. I particularly like that they have looked at what eInk and an eWatch could do that is different from a normal watch. Yes, you can choose a customised design for the face and the strap. Neat!
The battery life is purported to be 60 hours. Again, I like that. No chance of starting a 13 hour flight to Tokyo and then finding out just as the watch is about to adjust timezones that the thing is dead due to the short battery life of the 'smart' watches. Sure, I'm certain they will solve some of these loop-holes, but I really hope Sony get this out and give a sense of some alternatives at the 'low-tech' meets the purpose of the device end. Kind of like phones that can reliably make phone calls.
The other thing I liked about this and some might baulk that this was a device by Sony, is that they tried this out on the world through a separate subsidiary and looked at getting some test input via a Japanese croud-funding site. Is this disingenuous for a large multinational to do this? I'm not so sure. Does it meet the purpose, e.g. trying out something new and innovative on the market-place, yes. Does it allow steerage and feedback on the concepts much more directly, yes. And finally, does it allow companies to take a chance on such things, yes. Back in the day, some will remember the Sony only cautiously broke into the video-games market with the original PlayStation. Known as an AV manufacturer there was concern that this would potentially damage the brand, so the original PlayStation launched without a Sony logo, and the same for the original PS2.
Would I like to see more technology chances? Yes! Is is fair for large companies to try this? I think so, otherwise we're going to see concepts stifled as marketing and brand-police prevent companies taking chances..... good on you Sony..... let's hope we see more. Not so sure about the eInk bow-tie designs though.
Now, here is the FES Watch prototype that has come out of Sony. There are a couple of things I really like about this and it particularly marks a return to form for Sony with something clearly innovative and with a good understanding of what the user might want. Kind of like the first inkling that made them famous, understanding the need for personal audio and matching that.
Firstly, I love the clean design. Simple, minimalist, I could see myself wearing this. I particularly like that they have looked at what eInk and an eWatch could do that is different from a normal watch. Yes, you can choose a customised design for the face and the strap. Neat!
The battery life is purported to be 60 hours. Again, I like that. No chance of starting a 13 hour flight to Tokyo and then finding out just as the watch is about to adjust timezones that the thing is dead due to the short battery life of the 'smart' watches. Sure, I'm certain they will solve some of these loop-holes, but I really hope Sony get this out and give a sense of some alternatives at the 'low-tech' meets the purpose of the device end. Kind of like phones that can reliably make phone calls.
The other thing I liked about this and some might baulk that this was a device by Sony, is that they tried this out on the world through a separate subsidiary and looked at getting some test input via a Japanese croud-funding site. Is this disingenuous for a large multinational to do this? I'm not so sure. Does it meet the purpose, e.g. trying out something new and innovative on the market-place, yes. Does it allow steerage and feedback on the concepts much more directly, yes. And finally, does it allow companies to take a chance on such things, yes. Back in the day, some will remember the Sony only cautiously broke into the video-games market with the original PlayStation. Known as an AV manufacturer there was concern that this would potentially damage the brand, so the original PlayStation launched without a Sony logo, and the same for the original PS2.
Would I like to see more technology chances? Yes! Is is fair for large companies to try this? I think so, otherwise we're going to see concepts stifled as marketing and brand-police prevent companies taking chances..... good on you Sony..... let's hope we see more. Not so sure about the eInk bow-tie designs though.
Saturday, 6 December 2014
Spiro @ South Street and The Vapourer Moog
Had a fantastic evening just before we get into the Christmas rush to see Spiro. I first saw them at WOMAD about 6 years ago and have long enjoyed their music. And what a treat it was to listen to them in more intimate surroundings at South-Street with some cabaret style tables. Each of the members took a turn in explaining the songs and bringing about a wonderfully dream-like state of enjoyment from the musical patterns and melodies.
In the interval I purchased the one EP we don't have at home, The Vapourer which includes an int
A new six-track mini album featuring Moog synthesizer mixes by Adrian Utley (Portishead), which transport Spiro's music to an ethereal place somewhere between Sci-Fi, Bach and Kraftwerk - plus a new recording and three dazzling live tracks from WOMAD Charlton Park 2012.
Tuesday, 4 November 2014
Homemade Kora from a Drum
I had a fantastic weekend away in the Cathederal city of Wells where I saw this wonderful Kora made from a drum. He was more than happy to show off the cracking instrument and belt out a few 'Irish' folk tunes on it. Tricks of the make were to use a soldering iron to make holes in the drum skin and using zither pins on the neck as they're cheaper than buying 20 guitar tuning nuts.
The sound was fantastic and came from a similarly great retro looking amp in a radio chassis. I'm not going to give any secrets away there...
|
|
|
|
Wednesday, 29 October 2014
Simpler Silverlight/C# syntax for async web service calls using delegates
So, I've been using Web-Service calls in Silverlight for a number of years now in a bunch of different applications with the cumbersome async BeginGetResponse, callback, EndGetResponse syntax. It's all been working great, I happily have a template for this and can bash any new service integrations pretty quickly and has not been getting in the way.
For a simple Get request they look something like this:
Which is all good and I usually have some additional code here to callback to a delegate which can then do something, such as display the result asynchronously with the usual fun and games of getting this back onto the GUI thread using a BeginInvoke Dispatch.
Great. It then gets a little more complicated when you want to make a post request and have to push the XML parameters in another asynch BeginGetRequestStream function which means you're getting callback after callback. Easy enough, these can be bundled into a class for each WebService function and can use some templating to reduce the effort, but it's still pretty tedious. I've stuck with it because it works, I have a pattern and usually it's not too much trouble and once done means I can focus on the other interesting bits of the application.
Just this week though I needed to make a new little application and having some brain-space to look at this again and thinking Swift closures I thought I'd explore a bit how to get rid of the callbacks explicitly in the calls and see if this could be made into a single function. Sort-of and there are pros and cons.
What I came up with looks like this:
In this case the callback has been put in as an anonymous delegate so the code can be written in the same function. Now what is all the ManualResetEvent stuff about? Basically this is to handle the aynchronous nature. If you run this in the debugger you can see the BeginGetResponse call being made and then jumping down to mre.WaitOne() which is the normal thread flow of the operation. You can then see the debugger jump back up to the callback. The mre.Set then sets the flow to continue in the main thread once the callback has finished.
So, pros and cons.
The big pro is that the whole operation is now contained in a single function statement and local variables can be used to return the result. You can either make this synchronous now (as the synchronicity has been put into the call with the ManualResetEvent) or callback via a delegate (recommended) with the result.
The con is that there are seemingly multiple code execution entries in a single statement. Remember all those gotos and horrible code years ago. Well, lots of coding best practice is to make code more readable and the execution paths clearer and more understandable. [See also later note on calling from the GUI thread]
The nub of the question is if this is easier to read and understand and means there will be fewer problems. I kind of think so as once the template/pattern is established it's much easier to put together and therefore for me less prone to errors.
The big advantage now is if you need to do a Post, it looks sort of like this:
Which is pretty great.
Now, the additional funny. I don't like the Sleep at the end, but however I tried to work this out, I could not get things to work and the last wait just waited on for ever, so pragmatically it is working for me but is an ugly little hack.
Second thing to note with this method is that these functions cannot be called from the GUI thread directly as the callback in BeginGetResponse never comes back. That caused me a lot of headaches until I found the result. In the case of my application this is not a problem as all the service calls are running from a separate thread and updating the GUI. Still, it's messy. There are ways around this similar to the Dispatch back the other way, but it's not completely clean.
I did mess around with the new C# async keyword and using the task framework but the code really looked ugly to my eyes. Maybe a little more work on that and another post in the future.
For a simple Get request they look something like this:
public string server = "123.123.123.123"; public void GetExample() { String url = "http://" + server + "/getexample"; try { HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url); IAsyncResult result = null; result = request.BeginGetResponse(GetExampleCallback, request); } catch (Exception) { } } void GetExampleCallback(IAsyncResult ar) { var request = ar.AsyncState as HttpWebRequest; var response = request.EndGetResponse(ar) as HttpWebResponse; using (var reader = new StreamReader(response.GetResponseStream())) { string result = reader.ReadToEnd(); // now do something with this } }
Which is all good and I usually have some additional code here to callback to a delegate which can then do something, such as display the result asynchronously with the usual fun and games of getting this back onto the GUI thread using a BeginInvoke Dispatch.
Great. It then gets a little more complicated when you want to make a post request and have to push the XML parameters in another asynch BeginGetRequestStream function which means you're getting callback after callback. Easy enough, these can be bundled into a class for each WebService function and can use some templating to reduce the effort, but it's still pretty tedious. I've stuck with it because it works, I have a pattern and usually it's not too much trouble and once done means I can focus on the other interesting bits of the application.
Just this week though I needed to make a new little application and having some brain-space to look at this again and thinking Swift closures I thought I'd explore a bit how to get rid of the callbacks explicitly in the calls and see if this could be made into a single function. Sort-of and there are pros and cons.
What I came up with looks like this:
using System.Threading.Tasks;
public string server = "123.123.123.123"; public void GetExample2() { String url = "http://" + server + "/getexample2"; try { HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url); IAsyncResult result = null; ManualResetEvent mre = new ManualResetEvent(false); result = request.BeginGetResponse((cb) => { // Callback using (var response = request.EndGetResponse(cb) as HttpWebResponse) { using (var reader = new StreamReader(response.GetResponseStream())) { } } mre.Set(); }, request); mre.WaitOne(); } catch (Exception) { } }
In this case the callback has been put in as an anonymous delegate so the code can be written in the same function. Now what is all the ManualResetEvent stuff about? Basically this is to handle the aynchronous nature. If you run this in the debugger you can see the BeginGetResponse call being made and then jumping down to mre.WaitOne() which is the normal thread flow of the operation. You can then see the debugger jump back up to the callback. The mre.Set then sets the flow to continue in the main thread once the callback has finished.
So, pros and cons.
The big pro is that the whole operation is now contained in a single function statement and local variables can be used to return the result. You can either make this synchronous now (as the synchronicity has been put into the call with the ManualResetEvent) or callback via a delegate (recommended) with the result.
The con is that there are seemingly multiple code execution entries in a single statement. Remember all those gotos and horrible code years ago. Well, lots of coding best practice is to make code more readable and the execution paths clearer and more understandable. [See also later note on calling from the GUI thread]
The nub of the question is if this is easier to read and understand and means there will be fewer problems. I kind of think so as once the template/pattern is established it's much easier to put together and therefore for me less prone to errors.
The big advantage now is if you need to do a Post, it looks sort of like this:
public void PostExample() { String url = "http://" + server + "/postexample"; try { HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url); request.AllowReadStreamBuffering = false; request.Method = "POST"; request.ContentType = "text/xml"; IAsyncResult result = null; ManualResetEvent mre = new ManualResetEvent(false); result = request.BeginGetRequestStream((ac) => { // post request callback using (Stream stream = request.EndGetRequestStream(ac)) { StreamWriter writer = new StreamWriter(stream); string post = ""; post += "<?xml version='1.0' encoding='UTF-8'?>"; post += "<somexml/>"; writer.Write(post); writer.Flush(); writer.Close(); } mre.Set(); }, null); mre.WaitOne(); mre = new ManualResetEvent(false); string reply = ""; result = request.BeginGetResponse((cb) => { // callback response var response = request.EndGetResponse(cb) as HttpWebResponse; using (var reader = new StreamReader(response.GetResponseStream())) { reply = reader.ReadToEnd(); } mre.Set(); }, request); // this needs to stay in for some strange reason Thread.Sleep(100); mre.WaitOne(); } catch (Exception) { } }
Which is pretty great.
Now, the additional funny. I don't like the Sleep at the end, but however I tried to work this out, I could not get things to work and the last wait just waited on for ever, so pragmatically it is working for me but is an ugly little hack.
Second thing to note with this method is that these functions cannot be called from the GUI thread directly as the callback in BeginGetResponse never comes back. That caused me a lot of headaches until I found the result. In the case of my application this is not a problem as all the service calls are running from a separate thread and updating the GUI. Still, it's messy. There are ways around this similar to the Dispatch back the other way, but it's not completely clean.
I did mess around with the new C# async keyword and using the task framework but the code really looked ugly to my eyes. Maybe a little more work on that and another post in the future.
Friday, 17 October 2014
Silverlight Multi-Select User Control
So back to some Silverlight fun. I had a requirement for some applications I was putting together to have a multi-select drop-down that allowed typing in and selection from a list of available values. I'm sure there was some code around but I took a quick look and this didn't jump out at me immediately so I had a bit of an evening code. Here's the results. Please do take yourself and improve, please drop me a comment on this blog if you find it useful or use it for anything.
There's a demo below... try typing into the box. The version used below does not allow duplicates. This is an option in the user control.
The code files are available below:
These are paths for the right and down arrow:
And this is the path for the cross symbol used in the buttons:
There's a demo below... try typing into the box. The version used below does not allow duplicates. This is an option in the user control.
The code files are available below:
The code is a little klunky in places and could certainly be improved. I'll try to get round to that when I have some spare time. However, it met the need that I had at the time.
There are a number of areas for improvement, putting in disable functionality and allowing different colours for the selected items.
There are a couple of little tricks that are worth calling out...
In a couple of places I needed to send a message to a control to get it to have a visual interaction. The easiest way I found for doing this was to use a lambda to drop it onto the dispatcher:
Dispatcher.BeginInvoke(() => options.Visibility = Visibility.Collapsed);
These are paths for the right and down arrow:
<Path x:Name="arrowright" VerticalAlignment="Center" Margin="0" Stroke="Gray" Data="M2,8 L6,4 L2,0" StrokeThickness="2"/> <Path x:Name="arrowdown" VerticalAlignment="Center" Margin="0" Stroke="Gray" Data="M8,0 L4,4 L0,0" StrokeThickness="2" Visibility="Collapsed"/>
And this is the path for the cross symbol used in the buttons:
<Path VerticalAlignment="Center" Margin="3" Stroke="Gray" Data="M0,0 L8,8 M8,0 L0,8" StrokeThickness="2"/>
Thursday, 16 October 2014
Polifiller and Buzzword Bingo
Caught this on Radio4's Today programme driving in this morning (quote from the Beeb)...
"A new online tool, Polifiller.com, is being launched, which will supposedly automatically strip jargon and clichés out of politicians' speeches and statements - to help politicians rid their vocabulary of hackneyed phrases and give the electorate the clarity they deserve. Hamish Thompson, managing director of Houston PR developing the online tool and Robert Hutton is the UK Political Correspondent for Bloomberg News and author of 'Would They Lie To You? How To Spin Friends and Manipulate People'."
Love the idea!!
At work to keep management on their toes we always have a good round of buzzword bingo at the annual comms sessions. Which made me think, there's a ripe opportunity here for a PPT parser that takes in techno/biz-speak babble and either strikes it out or replaces it randomly with something else.... now if I have a spare evening, that might just appeal
"A new online tool, Polifiller.com, is being launched, which will supposedly automatically strip jargon and clichés out of politicians' speeches and statements - to help politicians rid their vocabulary of hackneyed phrases and give the electorate the clarity they deserve. Hamish Thompson, managing director of Houston PR developing the online tool and Robert Hutton is the UK Political Correspondent for Bloomberg News and author of 'Would They Lie To You? How To Spin Friends and Manipulate People'."
Love the idea!!
At work to keep management on their toes we always have a good round of buzzword bingo at the annual comms sessions. Which made me think, there's a ripe opportunity here for a PPT parser that takes in techno/biz-speak babble and either strikes it out or replaces it randomly with something else.... now if I have a spare evening, that might just appeal
Subscribe to:
Posts (Atom)






