Archive for code
February 2, 2007 at 8:33 am · Filed under Uncategorized, code
You know the one.. It goes da da da dum da da da dumm dum da…
No I don’t know the lyrics, no I don’t know who its by. Oh well I guess we can’t find out what the song is.
Well not anymore! Previously if you had a song stuck in your head going over and over and over again, the only real way to find out what it is, even who its by would be to hum it to someone around you (assuming you don’t know any of the lyrics that is). But what if you have no friends, or worse, you have lots of friends but their all deaf and thus unable to help you on your musical quest.
INTERNET TO THE RESCUE!
A new site (still currently in beta) called midomi. It lets you hum, sing or whistle your tune to it and it will run off and try and match the melody. Hell, you can even just concentrate hard and it will pick up your thoughts and find it for you. Ok, it can’t really do that but it’d be cool if it did huh? Lets hope thats in a future release.
More than just a site to help you find that single song stuck in your head, it lets you listen, rate and even download the song once its found it. And if it can’t find a match for your hummings in it’s database - it will save it and when (and if) it eventually finds it in the future it can let you know. Great stuff.
The site uses something called MARS - short for the catchy titled Multimodal Adaptive Recognition System, developed by the company Melodis to figure out what on earth it is your singing to them. Its only the first trial run of the system but if it goes well, I’m sure that we’ll end up finding it all manner of places before too long.
January 12, 2007 at 5:51 am · Filed under code, projects
Drag and Drop reordering is a really useful thing to have. The original motivation is to let merchants using Karova Store reorder the way in which articles, products display on their sites, but as I was implementing it we found it easier to basically let them reorder anything that could be displayed in a table.
Theres lots of examples and guides online to show you how to us the scriptaculous libraries to do this, but they all seem to deal with li’s within ul’s not tables.
The tech I’m using for this is pretty simple stuff. The html is coming from an xslt, the data’s going to be held in an xml file, the client side scripting is basic javascript and the server side ajax post back is being handled in c#. All of the things we’re going to do here can be done in lots of different languages, as its likely your setup is going to be different from this.
So heres what we want to do:
- Display the items in a table,
- Be able to reorder them by just dragging and dropping them
- Record what the new order is whenever it changes
- Use this new order when displaying them to the end user
Follow the white rabbit
1. We need libraries
No, we’re not going to be writing this from scratch, so we need the real engines that are going to do most of the work. So run off and get the latest version of the scriptaculous libraries. We’re using version 1.6.5, but anything recent should work.
Assuming you’ve got them now, just include the the prototype and scriptaculous libraries in your header, making sure the prototype reference is before the scriptaculous reference. They’ll import everything else they need as long as they’re in the same directory.
2. Make up your mark up
For the libraries to work properly we need to have our table to have the right id’s and so on. To use the default markup that works with the scriptaculous libraries mark it up with the tbody having an id of ‘item_list’ and the individual tr’s having id’s of ‘item_{ID}‘.
Basically all you need for it to work is the container to have an id of item_list (you can change this later on) and the individual items with and id of the form item_ID. If you really want to change structure of the individual id’s on the ’s you can, but you’ve got to go and change the scriptaculous libraries, so if I were you, I’d stick with this, at least for now.
3. Initial Dragging and Dropping
Before we go ahead and get all the ajax posting sorted, lets just check it works in its current form. Somewhere in your code you need to put the following javascript to tell the libraries to work their magic.
Sortable.create('item_list',{tag:'tr',
ghosting:true,constraint:'vertical'})
Oh, and this needs to be put in AFTER the table. Otherwise it won’t work. Got that? After, as in further down, later, nearer the end. Ok?
Its the Sortable.create() that does the magic, the first argument is just the id of the thing your reordering, while the things inside the braces are optional arguments. You can find a list of the extra options you can add on wiki page for sortable.create.
Basically the three we’ve got here do the following things:
- ‘tag’ - the tag, by default its taken as li, so this only needed if its different, as it is here for use in a table
- ‘ghosting’ - setting this to true displays a transparent version of what you are moving under your mouse
- ‘constraint’ - tells it house we’re moving the elements. Here its up and down, thus vertical, simple really
We’ll add some more later but for we just need to see that it works.
4. Recording the Reordering
What good is it if the user moves all the items around and but we have no record of what’s changed. No good. Thats how much good it’d be. We could have the user hit a confirm button when their done reordering, but thats and extra click. Of course we could just record what the new order as and when it changes.
Which is what we’ll do. Don’t panic, it’s surprisingly easy.
All we need to do is add a new argument to our sortable.create. This ones called ‘onUpdate‘, and we use it like this:
Sortable.create('item_list',{tag:'tr',
ghosting:true,constraint:'vertical',
onUpdate : updateOrder});
With the updateOrder function looking like this:
var options = { method : 'post',
parameters : Sortable.serialize('item_list') };
For some reason this didn’t work for me. It did return a serialized list yes, but not one in a format I could use. But don’t fret. If this has not worked for you either, try this (longer more scary looking) version.
var ampcharcode= '%26';
var serializeOpts = Sortable.serialize('item_list')
+ unescape(ampcharcode)
+"key=item_list;
var options = { method : 'post',
parameters : serializeOpts };
For this to work totally right we also need to add this new part to our sortable.create function…
Sortable.create('item_list',{tag:'tr',
ghosting:true,constraint:'vertical',
onUpdate : updateOrder,
tree:true})
There, that bit at the end. Don’t ask me why it helps it work, but it does. Just take it and be thankful.
Hold Up! Wheres this ajax you were promising? Oh wait, here it comes, I was just building it up a bit.
So, we now have all the information, all we need to do is pass it along to our server so it can do some tricks with it. For this we need to add the line ‘new Ajax.Request(’reorder.aspx’,options);‘. Where ‘reorder.aspx is the name of the this you’re posting to.
This is what our finished bit of javascript should look like:
function updateOrder(){
var ampcharcode= '%26';
var serializeOpts = Sortable.serialize('item_list')
+ unescape(ampcharcode)
+"key=item_list;
var options = { method : 'post',
parameters : serializeOpts };
new Ajax.Request('Reorder.aspx',options); }
Sortable.create('item_list',{tag:'tr',
ghosting:true,constraint:'vertical',
onUpdate : updateOrder,
tree:true})
If you want to debug at this point, all you need to do is add an alert(options.parameters) before the ajax request.
Now - onward onto the server side fun!
6. Actually using this stuff
Remember, we’re doing this in c#, so if you’re not doing it in c#, you don’t really need to follow all this too carefully.
The posted things come through to the c# as a form, but for safety, lets check it the form has keys with a simple test.
if(System.Web.HttpContext.Current.Request.Form.HasKeys())
{
//do some stuff here
}
Simple. Child’s play. Now lets fill it up with everything.
The stuff we get out of the seriazable comes back in the form ‘item_list[1][id]‘ with the key being the position. To get out exactly what we need lets use a regular expression to get out the numbers and leave everything else.
System.Xml.XmlDocument docO
= new System.Xml.XmlDocument();
docO.LoadXml("");
string itemKey
= System.Web.HttpContext.Current.Request.Form.Get("key");
foreach (string key in
System.Web.HttpContext.Current.Request.Form.Keys)
{
if(key.IndexOf(itemKey) > -1)
{
System.Text.RegularExpressions.Match m
=System.Text.RegularExpressions.
Regex.Match(key,itemKey+@"[(?d+)][]");
if(m.Groups["position"]!=null)
{
System.Xml.XmlElement posEl
= docO.CreateElement("position");
String itemOrder
= m.Groups["position"].Value;
posEl.SetAttribute("pos",itemOrder);
Sring itemId
= System.Web.HttpContext.Current.Request.Form.Get(key);
posEl.SetAttribute("id",itemId);
docO.DocumentElement.AppendChild(posEl);
}
}
}
As you can see here, the c# takes the parameters that are passed and puts them into an xml document, ending up with some xml of the form:
7. The Finished product
So we’re done. Quickly, lets go over what we’ve got.
Using the prototype and scriptaculous libraries we can reorder lines in a table. When ever we do, a function called ‘updateOrder‘ gets called. This serializes the new sequence in our table and posts it through to some waiting c# for some server side handling. On the server side we take the serialized sequence, do some reg ex clean up then generate some xml with it, which can then be used however we want.
Its all good.
As ever, if you notice any problems with anything above, let me know and I’ll go through and fix it. Let me know if this was useful to you.
You can a working example of what we’ve done here all packed up nicely for you. Have fun!
January 9, 2007 at 4:22 am · Filed under code, comics, random
The world of developers can be divided into four groups. No! Before you start skipping to end looking for a punchline, this isn’t the lead up to some corny joke about how some like star trek, while others prefer star wars, with the Babylon 5 group being left out into the cold.
No. This is about the 4 stages in a developers life cycle.
Unconscious Incompetence (Innocence)
This is the one we all start off at. Your rubbish and you don’t even know it. We’ve all been there so don’t be too hard on those young developers that are still there. This is how developers come into the world.
The good news is that very few people stay like this for too long. Just being around a good developer shocks you into the next stage.
Conscious Incompetence (Dejection)
The second stage up the ladder is possibly the lowest ebb in the developers life cycle. You’ve graduated from the innocence and freedom of stage one where you didn’t realize how much you had to learn, and now you’re stuck in the deep hole of depression with the realization of just how meaningless your skills really are. Come on, you didn’t really think that your HTML Skillz would carry you through.
If you’re in this stage now, and don’t want to stay in this stage forever, expect to be doing a lot of reading. Cover yourselves in books. Make a fort. Swim in the knowledge of our ancestors, though in reality it might help if you stick to tech books for now. After reading countless books and working though problems one day. BAM!! You’ll accend to the next stage…
Conscious Competence (Confidence)
You’ve graduated from stage 2. You still have the books but now when a problem rears its ugly head, you not only know how to solve it, you know why its come up, where its documented, even what part of what book is relevant to the issue at hand.
Developers at this stage, if you’re working as part of a team, need to develop great levels of patience. Expect to be interrupted for the most trifling issues. The smallest problems. The silliest mistakes. There are two ways to deal with these interruptions.
The first way is to solve the problems as they are presented to you. If you value your sanity, DON’T DO THIS. At least, not every time. If you solve peoples problems in a few seconds, yes they bother you less the first time, but the next time there is a problem, they come back, expecting an equally quick resolution. And the the whole situation just snowballs. You turn from being a developer to the resident problem solver. And no-one wants that.
Instead, take a bit of XP methodology. This isn’t possible every time, but if you can, try and do a spot of pair programming. Yes its not always enjoyable to sit behind someone as they slowly work a problem when you could solve it in seconds, but do it now and see it as an investment in time.
Most problems don’t stem from the developer coming against something they simply cannot do. Hell, for most of us, a quick google every now and then is an accepted part of our programming day. So teach your co-workers/protégé/desk buddies not how to solve the problem in front of them, rather, teach them how to go about finding a solution to the problem. Give a man a fish and he’ll eat for a day. Teach him how to google and he’ll eat for life.
For many developers this is the end of their life cycle. By the time they’ve risen to the top of their game, an new flashier more exciting language has come along and they feel the tug of peer pressure to move on to newer shores. However, for the precious few who stick the course, we come to the fourth stage…
Unconscious Competence (Mr Developer)
You’re not just good, you’re great. Not only can you solve any problem thrown at you, you look good doing it. The books that once were so important for reference now become just a comforting reminder of yesterday, and you’ve gone from reading the books, to writing them.
Watch out though! Developers at this stage can tend to lose contact with where they came from. Little questions that before you would of answered now become tiresome. Its even possible to forget that everything is not instantly obvious to all those around you.
So those are the four stages of developerdom. Of course you may go through these stages many time, with every new language you pick up you have to go through them all again. Luckily for us, the more you do it, the quicker you can move through them until you reach the point where you can pick new languages in roughly 25-32 minutes. No seriously. You can. Trust me on this.
December 29, 2006 at 9:04 am · Filed under code
According to this article, there are two types of people in this world.
-
Those who understand that software will never be perfect and every good (and bad) software company ships products with known bugs
-
People who don’t
It goes on to recount how those of us from the the first group often forget what it was like when we were once part of group 2, and we often don’t understand when people react with horror and dismay that we would release a product before we fixed every know bug.
I have to say I agree.
Working as a developer for an e-commerce company I’ve come to realize bugs are a part of life. Its probably different for developers working on a single product where bugs are found, and the fixes are released, but in this area, while a lot of the process is the same, there are differences.
The vast majority of our work is bespoke. We make e-commerce sites for people. People want different things. Thats just the way of things.
When a client want the system to be able to handle multiple images for products, we put it in as a new feature of our default store. No problems. All future customers will have that option. Then again, what if they want something more bespoke to them? Maybe they want the checkout process to do something different to what it does at the moment?
These are the types of changes that cause the longer term problems for you see if there is a bug in the default store (and yes - there are bugs in the default store, come on, you’re not from group 2 are you?) it becomes part of this bespoke store.
Fixing the individual bugs may not be the problem, moving the fix across all sites is.
Firstly we need to find out if the site is affected by the bug. This depends totally on the site. If their bespoke development affected the area we’re going to be playing around with then we’re either home free or in trouble.
Case 1. We’re home free. This happens when the bug occurs in such a place the either the site specific coding has caught the problem and replaced it, or it was already fixed for this site (and not integrated back into the default store) during the development process. This is what we always hope for.
Case 2. We’re in trouble. Unfortunately this is far more often the case than case 1. The client has asked for some strange functionality and this has changed the specifics of what happens for this site. Now not only do we have to fix the bug, we also have to re-engineer the fix for this site so as not to break it anymore.
So thats the problem. Its never a simple case of fixing a bug then releasing it into the world. For every bug we have to go through possibly hundreds of sites manually. Not what we want by any means. Which brings me back to the original article.
choosing your (bug) battles
To reduce the amount of bug fixes and free up time from just fixing bugs all day to do some actual work we need to ask the following four questions about every bug:
- When this bug happens, what is the impact? SEVERITY
- How often does this bug happen? FREQUENCY
- How much effort is required to fix this bug? COST
- What is the risk of fixing this bug? RISK
The first two questions are questions for the customer (or someone assuming their view) and the last two are for the developers.
From the article, the author suggests plotting the first two on a graph of severity, with the vertical axis the severity, the horizontal the frequency. So a bug that happens every day and causes the user actual physical pain would be in the upper right corner, while a bug that is only noticeable to a developer’s trained eye and only when running a whole suite of obscure browsers to test with would be on the bottom left.
Allow me to illustrate with a lovely graph.
This is what is meant about choosing your (bug) battles. In this instance the blue dot (the very bad frequent bug) would be fixed, while the red (the rare tiny bug) would not be fixed.
If we decide to proceed with fixing a bug the last two questions come into play. Cost and Risk. Cost can be best measured in time, ie. how long would it take one developer to do the work? Risk is a sort of catch all. Its the wild card here.
What if the bug is in a part of your code that you know is full of loop holes and, for want of a better word, hacks. These loops and hacks aren’t necessarily bad. They’ve been put in over time to fix real problems, and they work. They fix the problems. If you go along and start playing around with it - even rewriting it from scratch you enter a very dangerous area. As developers we must learn to leave well alone at times due to one simple truth:
Every code change introduces the possibility of new bugs.
That very fact should weigh on your mind every time you go crawling around old code. I know it does on mine. So if the part of code your bug is in is a dark and dangerous place, take that into consideration before ‘fixing’ it. Every change you make brings up the possibility of more problems, more bugs to fix, and so the cycle repeats.
Considering these 4 questions on each and every bug you come across may seem extreme but luckily the experienced developer can usually run through these decisions in only a few seconds without ever consciously thinking about it. Of course there are occasions where it will take a grouping to solve it and decide the course of action, but then again, thats just what its for isn’t it.
So thats it for now, at least till I go through and correct some of the spelling.
November 14, 2006 at 10:38 am · Filed under Uncategorized, code, comics
So you’re writing a system that runs through xml files huh?
And does it dynamically each time you load the page.
Sounds like you should do some load testing.
Well heres a lovely baby small python script that helps you do just that. It makes 10,000 files for you. Oh so pretty.
s= """
---the test data---
"""
for i in range(0,10000):
f = open ("%d-%d.xml"%(i,i),'w')
f.write(s)
f.flush()
f.close()
(and if your interested the system passed - 2 seconds to run through 10000 files isn’t bad)
November 13, 2006 at 11:26 am · Filed under code
Consider the following -
You want the user to enter a date into a text field. When the page intially loads you want the field to default to yesterday. Simple yes? Well getting the page to display it is, yes. But what about the code behind it?
Well in C# you can use the DateTime class to handle this kind of thing, so we’ll do that.
System.DateTime.Today;
Thats fine if you want your DateTime object to be today. But what if you want it to be yesterday? An interesting question.
Ill give you a hint - this doesn’t work
System.DateTime.Yesterday;
Well, after some searching through the api’s I could see no simple way of doing it. There is no .RemoveDay method. You could play around with ticks and all sorts of other fancy things but there is this very simple way of doing it.
System.DateTime.Today.AddDays(-1);
Simple huh?
Initially I was thinking its kind of counter intuitive but now that I’ve been using it for while it makes sense.
Just another thing to put down to experience.
November 6, 2006 at 4:20 am · Filed under code
Have you ever needed to save something to a file in c#?
You have you say.
Well heres a nifty trick I just found. Its old and simple, but its new to me so I’m going to share it anyway.
If you were doing this -
...
System.IO.FileStream fs=new System.IO.FileStream("test.pdf",System.IO.FileMode.CreateNew);
...
and the file already existed it would throw an exception. My initial reaction would be to wrap it in something that checked whether the file was already existent and then change what happens as appropriate.
But no! There is another way.
Thanks to some thoughtful developers you can do this instead…
...
System.IO.FileStream fs=new System.IO.FileStream("test.pdf",System.IO.FileMode.OpenOrCreate);
...
Now isn’t that just lovely. What a clever little function, System.IO.FileMode.OpenOrCreate - Thanks Microsoft!
October 26, 2006 at 9:48 am · Filed under code, mathematics, projects
A while ago I completed my Mathematics BSc from Bangor University. Its a course they’ve stopped doing now, but at the time, it was a most excellent thing. For those that are interested I did my final year dissertation on Flocking Autonomous Agents. That is, the order that appears when groups of supposedly simple agents congregate.
Its the sort of thing that you see in the wild with swallows flying about. Theres no master plan of where they’re going, nor any central command to the system. So how do these simple creatures manage to form cohesive flocks that can travel, with what seems, singular purpose?
It was just this question I proposed to answer in my dissertation (and I thought I did that rather well) as well as explaining the deceptively complex maths behind it.
Long story short. The system works like this:
- The individual agents are only aware of whats going on in an area directly around them (their vision range).
- The individual agents will try to adjust their direction to that of their neighbors.
- They won’t always do this right.
- There is 4th rule.
It seems almost counter-intuitive that the fact that a agent makes mistakes in their headings would actually help the flock as a whole but, after some rather intense mathematics, you can prove that, up to a point, it helps the system.
The crux of the matter is this - If there is group of agents flying together in sync and none of them ever makes a mistake as to their heading or position, their relative positions will conceivably never change.
If however they do make mistakes something wonderful happens.
Mistakes that have a negative impact on the flock as a whole get naturally canceled out while mistakes that bring the flock together are reinforced. Over time a very tight, cohesive, resilient flock is formed.
I even wrote a lovely java applet for it and ill post it up here when i figure out how to embed it properly. Ill even give you the source code, cos I’m nice like that.
« Previous entries ·
Next entries »
