Tuesday, December 15, 2009

Monday, December 14, 2009

DevEvening CodeFest

One of the things I've been keen to do at DevEvening is to see what would happen if we did a session where everyone came and wrote code.

For this reason we had an event and called it the 'Christmas CodeFest'.  (Yes, the name wasn't very good but the event was.)

From the original event advert:
We all learn in different ways. While it can be good to learn by hearing people present and demonstrate new techniques, it can also be good to learn by seeing how different people solve the same problem.  That's what we hope to do at the CodeFest.

The plan is for everyone to write automated players for a simple game.  Don't worry if this sounds complicated, it will only involve implementing an interface containing 4 methods (and one of them just returns your name!).  The logic therein can be as simple or complicated as you want to make it.  It will be practical to achieve something good in the time frame available and plenty of examples will be provided to get you started.

In addition to having each persons 'player' compete against each other we'll also look at the way each person approached the problem and how successful that was.

My initial expectation was that this may not be a popular event - after all I'm not aware of any other user groups having done an event like this before.  Perhaps there's a reason why?

Writing something productive and fun in about 2 hours is actually quite hard. If you want to make it possible for people with varying skill and experience to be able to achieve something in the time limits things further.

If you've scanned down to the image below you'll see that the game used was Connect 4.  This was deliberately not made known before the event so no-one could get a headstart on working out any game logic or tactics.

What I provided for those who came along to use:
A solution containing:
  • A WinForms 'host' application which displayed the board, managed 'players', etc. (This host also allowed manual playing of each player.)
  • A WPF user control to represent the game board.
  • A set of tests to verify the logic in detecting wins, etc.
  • A library containing the interface that each player was required to implement
  • A copy of MEF Beta 2 Preview 8 (which was used to load players from the individual DLLs)
  • A sample player written in C#
  • An identical sample player written in VB.NET
What each person had to do to implement their 'player':
  1. Open Solution
  2. Add new class library
  3. Add reference to ComponentModel (project)
  4. Add reference to IConnect4Player (project)
  5. Create a class that implements IGamePlayer (make sure to include necessary export attributes)
  6. Write some code to implement your player!

The competition
The aim was simple: everyone has about 2 and a quarter hours (including a break for food) to write the code to implement their player.  We then allowed each player to compete against the others in a knock out tournament (using the sample random players to make up the numbers - so no one got a bye). 

2 players were beaten by the random player in the first round. Boo!

The games were played projected onto a screen so everyone could see what was going on.  The host app automatically called each player in turn until there was a winner.  There was a slight pause (500 milliseconds) between each each move.  This gave everyone a chance to see what was happening and allowed for some audible reactions as people were blocked from winning moves or failed to make winning moves.  The host app I had developed required manually loading the players each time. In practice it would have been useful and saved time if the players could all be loaded at once and it take care of managing who played who and recording the results.

The final came down to a best of three between Jeremy and Mark. Mark won the best of 3 games by taking the first 2.


A selection of swag as prizes from our generous sponsors (http://www.devevening.co.uk/links.aspx) was available on a winner gets first choice style.  People who found bugs in my code also got a choice of prize.

Speaking of which. Unfortunately a couple of bugs were found in my host app code.

Both of the people who were using VB.NET found a bug (now fixed) in my host code where I didn't handle the player returning the 'GiveUp' move correctly.  At the time I was happy to dismiss this as a bug in the way I had done something which affected interacting with VB in some way.  They were both certain that they were never returning a GiveUp result.
In my subsequent analysis of their player code I discovered that for one 'player' there were valid paths through their code to determine which move to make next which returned the default value for an enum. Sneakily of me this default value was 'GiveUp'.  I looked at working out where the error in the code was but it was highly complex (lots of conditionals and recursion) and used lots of single letter variable names so I decided to pass.
After a bit more digging in the other VB player's code I found that on certain passes through multiple nested loops it tried to access an array element which didn't exist and then threw an error.

Both of these issues show me the importance of making code easy to read and follow. Also to be very wary of complex nested loops.  I actually used nested loops in some of the host code which checks for wins.  During the evening I had a discussion about this issue.  I chose to use nested loops only once I had a large number of tests in place and beccuase it allowed me to massively reduce the amount of code I had to work with. Nesting loops is definitely a tick in the negatives column so to use them they must provide a benefit which puts a bigger tick in the positives column.

A bug was also found where it sometimes reported the wrong person winning. Oops.

One of the players was not developed with the instructions I gave. Instead they customised one of the sample random players.  This caused problems when the developed player was drawn to play against the random player.  Based on my very limited knowledge of MEF the problem experienced was one that shouldn't be possible as both players were loaded in different containers.  I'll definitely investigate this further when I have the time. Maybe we've found a bug in MEF?!

What I learnt from organising the event

Unsurprisingly it was a very different DevEvening to 'normal'. Part of me was expecting that I'd be running around answering questions, etc.  I hadn't expected that most of the time everyone would be quietly working.  In theory this is a good thing.  In practice it's something to be aware of for the future.

Analysis of what people did (a random collection of observations - not marking any code)


  • Some people still use Apps Hungarian notation for variable naming.
  • The people who used TDD had code that was really easy to follow.
  • The people who used detailed, explicit names created code that was easier to understand.
  • Some people use properties for things that I assumed would always be constants.
  • I'm more positive about opening a code file for the first time if there is an accompanying test file (even when I haven't seen the tests)
  • Assumptions documented in comments in the code are reassurring that the original coder has thought about what they are doing and have to do.
  • Seeing lots's of TODOs in the code is reassurring that the original coder has thought about what they are doing and have still to do.
  • I've learnt that there's a 'Assert.Inconclusive'
  • I've seen some people default "unwritten" tests to return true. I'm not sure this is a good idea.
  • Some people, seemingly, started by using using the sample random code and replaced this bit by bit as they wrote their own. - Seems like a good plan.
  • Code is easier to read when spread across multipel lines.
  • I find use of the conditional shorthand operator (? :) difficult to read when all on one line and I'm not familiar with the code.
  • 2dimensional arrays seem to lead to code that is just as complicated to understand as a number of Lists (or equivalent) - at least when there are a small number of 'Lists' in use.
  • Hooray for amusing comments!
  • Comments which add no value are disappointingly common.
  • Lots of people wrote code which they didn't use - presumably because they thought they would need it later. This seems a bad but understandable thing to do when very limited with time.


What I got from the experience
  • I got to exposure to the way some other people work.
  • I got new ideas for how to solve a problem.
  • I had an excuse to do some practical development with MEF.
  • I had an excuse to do some more work with WPF (embedded in a Winforms app)
  • I had an excuse to use T4 in an actual project.


Some random/assorted statistics I gathered on the night:
  • Teams/people who made notes on paper before starting: 1
  • People who used the internet for reference: 0
  • People who looked at the code I wrote for reference: 0 (assuming everyone was honest when asked.)
  • Teams/people who wrote tests (of any sort) for their code: 4
  • Which external libraries did teams/people use: only NUnit
  • Teams/people who felt they had "finished" in the time allowed: 0
  • Players developed by pairs fo developers: 3 (of ten players)
  • People who used a black background in Visual Studio: 5


If I can come up with another suitable task/game/project we'll definitely do this again.  The feedback from the people who came was very positive that they'd come again.  I'm not sure how well this would work with much larger groups or how we'd fit many more people in

If you're interested in knowing more or running this or something similar at another user group drop me a line.

Thursday, November 19, 2009

Monday, November 16, 2009

Assorted mobile web notes

Another assorted collecction of notes from some old notebooks - including some from Mobile Web 2.0 Summit.

mobile: point of inspiration & entertainment & need
users value dependent on relationship with other users
value in getting data from device
* combine knowledge of users across different screens
valuable data can't easily be replicated/recreated
who owns data? - Key Q

Monetisation is complex
- getting the right, loyal customers
contextual advertising doesn't work in socail media
value is in context + contacts
target people, not content/context
profile based on demographics/behaviour/social interaction
how to calcualte the value of mobile marketing?
Privacy - users must be able to utilise data themselves

1 billion people own a Nokia phone
Nokia make - 450M devices a year / 15 per second
1/2 sale price goes on R&D (£6B) - Europes largest - workd 3rd largest researchers
Devices are all alike - what it does for the user is the differentiator
unlimited is the key to packaging services
Nokia want mobile web browsing at same speed as desktop
- Users want it now
Must make service work across devices

The real battle for real estate is in users pockets!

Users expet the ability to do desktop stuff on mobiles
Younger people want more from/on mobiles
make it REALLY easy for uesrs to do things

people communicate with those closer to them with their mobile.
- content changes in context

people would do more on mobile if it was faster

Most important features on mobile:
1. Internet
2. SMS
3. voice

targeting marketing based on device > which are targetted at demographics

users want to buy via operator portal as they trust it

mobile apps for social networks
- 2 times as often
- 4 times the page view

Make advertising/marketing social graph friendly

apps are hard to change - the web is easy

massive users volumes only come from operator portals

focus on what is key of service - not the platform optimising for.

UX is harder to get right - 10x harder on mobile (as screen is 10x smaller?)

software is the future of differentiation
- software will become key for operators

optimising for more powerful devices is likley to become an issue in the near future.


75% of Africans will never have a PC!
Businesses, not consumers willing to pay for content when consumer has very low disposable income.

turn customers into fans

reexamine business practices - don't just evolve

web browser as runtime
- reuse web developers skills for mobile.
mobile web - moving to apps, not just pages

widgets at epicenter of mobile and web convergence
widgets -for social applications(?)

do we need standards? - who benefits?

 You don't have to be a destination - e.g. Twitter.

Turn users ito a community:
- Engage - reason
- Content - useful or entertaining
- Convergence - acknowledge cahnges in user behaviour
- Loyalty - GREAT experience
- Analytics - Use them - to understand audience need.

"digital" connecting web & mobile.

lots of scope for sponsored experiences/apps
mobile advertising has little opportunity to do big things
where's the value of ads in social networks where content has little or no value.

need for local/regional/national variations of global systems
- things won't be the same across cultures but may be able to learn something

league tables as loyalty drivers
Get users doing something, not just watching
realtime feedback enhances participation
showing location of other users  builds community & loyalty
people want to be part of something - don't need to have a conversation
everyone likes to play - "underappreciation of frivolity"

the thing people want to do mpost with their phones is communicate
8 year mobile adoption curve
netbook as biggest mobile web usage device
mobile - a world of fads

communities may/can/do live longer thna the event/product/property they were created for

make payment simple - tightly integrate with app store / payment channel

will governments end up paying for essential infrastructure?
- if no long term business model to provide it at a price people are willing to pay
- would we want that?

captured informaiton is enriched by knowledge of context

look at web and mobility at the same time

charge for more than just the web - depth of network interaction

converged address book =? defacto social network

where data is physically located affects legal access to that data

open not necessarily free

Digital dividend - mobile opportunity based on digital divide

smart objects
sensorconomy

devices drive everything!!
people will pay for
- new types of devices
- deep integration of services

customers understand and will pay for services

use of web as a platform is accelerating
browser as client for the cloud

OS not a differentiator

dConstruct notes

Just been going through some docs and found my notes from dConstruct.

Please be aware that this is unlikely to be of use or interest to anyone but me.


Elements of a Networked Urbanism
People blame themselves - when usability is poor.
Ubiquitous computing - the future!?
Networked urbanism - but surely not everywhere?!
sustainability - empowerment - privacy
City: "a layered representation of experiences over time"
More than half the world live in cities (including slums & favelas)
squallor & vitality
Component / Resource
- Everything: addressable -> queryable -> scriptable
Consistent / Variable
- static > fluid
Latent / Explicit
- information revealed/available:
-- now actionable responses
-- know more than you want to?
Browse / Search
- choice drives option
-- less happenstance/chance
-- removing personal/local/insider knowledge
-- democratization of information
-- expertise becomes harder
Held / Shared
- possibly easier
- contribute back
Expiring / Persistent
- history reamins and becomes available in new ways
- including new levels of personal information
-- personal reinvention becomes harder
Deferred / Real Time
Passive / Interactive
Wayfinding / Wayshowing
Object / Service
- improved utalization of objects
- increased abstraction
Vehicle / Mobility
Ownership / Use
- change in understanding of consumerism
Schelling / Schoaling
- location of common meeting / soft appointment place/time
Community / Network
- changes in level of minimal acquaintance
- society & community based on levels of not knowing
- association by choice / association of circumstance
-Beware:
-- speed of change
-- changing what don't understand
-- what don't understand (almost certainly more than you realise!)
Consumer / Constituent
- Variation
- require: sensitivity/intelligence/tact
Privacy of information
Serendipity is good - you don't want to remove it


Let's See What We Can See (Everybody Online And Looking Good)
Show you/user and others on a map
- creating a virtual community is a good thing
Social is more important than visual (MySpace?)
Indicate:
- Importance
- Popularity
- Relationship
Holisitc views / Peripheral viewing
Include textual representation of what is being shown
Highlight specific information amongst complex screens
From language to behaviour
- experiencing daat
A physics of information
- applying a dynamic display
- visual models
Indicate possibility
- "sculpt the data into the statue of your choice"
Tuning in patterns
Synesthesia
- one input/experience triggering memory of another
Medium = message - depending on representation
Experience!


What’s Next? How mobile is changing design 
What is our perception of the future?
- Influence
- Bias
Now
- everything is touch
GenY - do things collectively
Mobile generation = born after '91
- have greatest buying power
iPhone - fastest consumer ramp up since DVDs
Touch - 4th largest OS (by popularity)
WebKit - 95% of devices accessing the web
Universal language: HTML + CSS + JS + APIs
Are we already designing for the web of tomorrow?
AppStores - more iPhone apps than Mac apps
Mobile apps are now moving to the desktop (Tweetie)
Constraints of mobile design - lead to greater focus
Design for medium or context?
Context = circumstance/settings
The era of single context web is over
web widgets on TVs
Neurolinguistic programming
Audity|Visual|Kinesthesic
Design is a multifaceted experience
what's next?
- anything
- everything
The future will come from investments made in mobile today!
people/user driven
We are the gatekeepers to the information age
portable + personal + always connected
- collaboration
-(-) "we already know the answer"!

Make It So: Learning From SciFi Interfaces
research behind anthromorphism attempts in software
sound is enought to represent something
- audio interfaces
- can create empathy/emotion with sound
behaviour good - likeness better
- giving more than expect
representaiton embodies/implies additional information
constraints ease learning curves
Inputs should know affected stated
- don't respond to something unusual when users wouldn't really want you too



Loving Your Player with Juicy Feedback
Unpredictability
Variability
Aiming for desirable emotional response
emotional investment
challenge - fellowship
Perception of achievability
Mechanics -> dynamics -> Aesthetics
meaningful activities
avoid clutter
create iteration
avoid feature driven design
Don't fix what isn;t broken
QWAN - Quality Without A Name
Juciness
- constant feedback
- No goal (task)
- Responsive audio feedback
- Aim to produce an emotional response from user
Bubble wrap
Make user care and think it's cool.
Not for it's own sake (feature)
Interpreting more than what's shown
remove arbitrary constraints



Experience and the Emotion Commotion
It's often counter intuitive
Play - in everything(?)
Experience v object
work/play
prickles/goo
Dialectic - no dualism
embedded intelligence in objeccts
embedded emotion in objects
simple questions = complex answers (& vice versa)
emotion = a mental reaction to physical experience/responses
system output > user input


Materialising and Dematerialising A Web of Data. (Or What We’ve Learned From Printing The Internet Out)
"the front of the train is less crowded"
post digital
real objects - digital identities
beyond digital infatuation & analogue nostalgia
"things I would rather read on paper"
new combination of existing things = all new things
victory/success is a dnagerous thing
screens are a cliche
are we just solving the problems we are causing?
- what about entirely new things?
stuff takes up space and is expensive to move
physical things have more importance
redomaining!

Thursday, November 12, 2009

Everyware: Adam Greenfield



 A few quotes and notes that caught my attention while reading "Everyware: The dawning age of ubiquitous computing".  I was inspired to finally get this after hearing Adam speak at dConstruct earlier this year.

Present IT development practices as applied to everyware will result in unacceptably bad user experience.

"If computers are everywhere they had better stay out of the way."

Build it as safe as you can, and build in all the safeguards to personal values that you can imagine.

"in dreams begin responsibilities."

It will not be sufficient simply to say, "First, do no harm."

We're not very good at doing "smart" yet, and we may never be.

"some problems routinely put forward [in ubicomp] are actually AI-hard."

Ubiquitous systems must default to a mode that ensures users' physical, psychic, and financial safety.

ubiquitous systems must not introduce undue complications into ordinary operations.

Tuesday, November 03, 2009

WMRM DisableOnClockRollback

I've been working on a project which involves using Windows Media Rights Manager (WMRM) Digital Rights Management (DRM).  As part of that project I have been applying rights to specific content (movies in this case)to meet the rules specified by the client.

Unfortunately I was receiving an error and searching on the error message returned exactly no hits.

{"Error HRESULT E_FAIL has been returned from a call to a COM component."}

at WMRMOBJSLib.WMRMRightsClass.set_DisableOnClockRollback(Int32 pVal)


In case anyone else runs in to this in the future, here's what the bug actually was.


I was setting a DisableOnClockRollback value of true, but was getting the error when I did so.  A short MSDN search later and and I found http://msdn.microsoft.com/en-us/library/bb649390(VS.85).asp. In it is the line:

This property works only if you have set an expiration date first.


That'll be the problem then.

DevDays CountDown App: My Analysis

I promise, this'll be the last time* I post about my DevDays CountDown App.

Now it's all over, it seems a suitable time to do some analysis:
  • Why did I write it?
  • Why did it get picked?
  • What helped me develop the application?
  • What did I learn from the process?
  • What would I do differently next time?

Why did I write it?
 A few reasons:
  • I thought it'd be cool to write an app that got used in quite a cool, high profile event.
  • I had an idea that I thought was quite good.
  • I thought it'd be a good opportunity to build some experience with WPF and particularly with WPF animation.
  • To prove to myself that I was able to produce a good piece of software that meets a clients requirements.

Why did it get picked?
Officially:
"... because of the twitterfeed and because the graphics are actually appropriate"
I think there are several reasons:
  • Because I actually produced something that met the requirements. - I was surprised by the number of entries that didn't. (Users won't [usually] use[/buy] a product that doesn't meet their needs.)
  • Because I actually delivered something. - There were a lot of comments from people who said they were working on something but never posted anything. (There's no reward for not showing up.)
  • Because the graphics were appropriate. - While I also had some novel. alternative, ideas I knew these wouldn't tie in with the StackOverflow or DevDays brands. (A bit of marketing knowledge helps in software development.)
  • Because I did more than was asked. - The twitter element wasn't part of the original requirements. (Having something unique is always a good selling point.)


What helped me develop this application?
  • I made sure I understood what was wanted. - I read the requirements thoroughly. I asked questions and madde sure I understood the answers. I read other people's questions and answers.
  • I understood the domain. - I go to quite a few conferences and am keen on understanding their organisation and how they are put together. (This partly ties in with my experiences of organising DevEvening.) Knowing the application domain is essential to good software development!
  • I've seen lots of different ways twitter has been used at conferences and other comparable events. - This guided how I incorporated the twitter element.
  • I have a desire to only do things well, or not at all. - Loads of people can do average. Fewer people will put in more effort to make something really refined and polished. - Good enough isn't good enough!
  • I focused on my strengths, not my design skills. - By basing the design on an existing layout, colour scheme and images.



What did I learn from the process?
  • Make the first user experience great. Optimise for it. (User input handling wasn't brilliant in the first version.)
  • Visually stunning (slick?!) and different is good for creating a good first impression. Animation is a good way of adding something new, different and visually appealing to traditional desktop apps.
  • Make user input handling really solid, smart and tolerant.
  • People love seeing their own contribution/thoughts (tweets) on screen.
  • TweetSharp is cool (despite a few temporary problems) and fluent interfaces are really nice to use. 
  • There are a lot of ways user input can get into an application. Consider all of them and 3rd party libraries and APIs as external input and treat them with caution.

What would I do differently in the future?
  • Better caching of tweets retrieved from the twitter API. So can download many at once and then stagger their display.
  • Better error logging. - Currently swallowing quite a few exceptions with no logging. - It didn't really matter for this case but could help with debugging.
  • Better messages to display if no new tweets to show.
  • Add unique images for fake tweets.
  • Add processing rules for tweet inclusion. Possibilities to consider would include: ignoring retweets; profanity filtering; spam detection and ignoring.
  • Ability to play music?
  • Better validation of all input.

Right. Must be time to go back to some of my other projects.


*This year! - who knows about the future.

Monday, November 02, 2009

Getting IIS6 working in 32bit mode on a 64bit machine

I had a server up and running hosting various sites.  One of those sites needed to be able to apply DRM wrapping to movies (WMV) files.

Unfortunately the DRM libraries are only available in 32bit versions and it's not possible to call 32bit DLLs from 64 bit processes.  The way round this is to have IIS run in 32 bit mode.

The same applies if  needing to reference any other 32 bit DLLs ffrom 64 bit ASP.NET/IIS.

Based on what I read on the internets, making this change should be quite straight forward.  Despite all the instructions on the web saying ti was just one script to run to make this change I found that more needed to be done.  Incase anyone else has the same problem, here's what I did to get it working.

Uninstall the 64bit version of ASP.NET 2.0.
c:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -u

Configure IIS to run in WOW64 mode.
cscript.exe C:\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1

Install 32bit version of ASP.NET 2.0
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i

Enable 32bit version of ASP.NET 2.0 in IIS WebService Extensions

Recreate the existing websites in IIS using same setings as before.  This will use the 32bit versions of ISAPI extension executables, etc.  I tried changing these manually but that didn't seem to be enough.  I assume that there's more to change than I'm aware of. Recreating the web site takes care of all that for me.

Done.


IIS is all or nothing when it comes to using the 32 or 64 bit version.  Yes this meant that all websites on that server needed to be changed to run at 32 bit.  We therefore lose the benefits of the 64bit OS.  If the site becomes as big as the client is hoping we'll move the site doing the DRM wrapping to a different box and put everything back to 64bit so we can make the most of the 12GB of memory installed.

Saturday, October 31, 2009

Stack Overflow Dev Days: London

As promised previously here's my review/notes/random thoughts from DevDays London.  Plus I'm keeping this positive this time.


As I was slightly invested in seeing the countdown app in all it's massive screen glory. I was trying my best to arrive in plenty of time.  Unfortunaltely my 3 year old son had other thoughts on me leaving early.  Fortunately I arrived in the "great hall" with a sign on the screen saying "Dev Days starts in 43 seconds". Nothing like cutting it fine!  Seeing all the elements on the screen slide out during the fade to black on a screen the size of my house was definitely cool.


In good tech conference tradition the day started with a comedy video.   I lost count of the in jokes and I've never seen a punchline coming from so far off as the 6 to 8 week deadline estimate.  Plus I'm looking forward to HTML6 and the tag.  Hopefully they'll post the video somewhere, but in the mean time you'll have to make do with this: http://www.youtube.com/watch?v=H3slPNJdbF4.

Pair programming: "You're born alone. You code alone. You debug alone. You die alone."
The first session of the day was Joel (complete with Union Jack flag and I <3 London tshirt) Initially I was concerned that this was just going to be the same presentation he gave at Business Of Software last year. Fortunately there were some new twists on things and some new ideas. My notes:
  • Always search everywhere. Never ask the user to say which fields to search.
  • Decisions are about balancing simplicity and power.
  • Do you do one thing well v/s have lots of features
  • More features mean more choices.
  • Choice is attractive but too many choices prohibit purchases.
  • "The paradox of Choice"
  • Less features v/s a defining sense of self
  • Don't ask questions the user can't answer.
  • Users blame themselves when selecting the wrong option.
  • Most people need more than simple.
  • Sales increase when features are added
  • Power = features; options; capabilities; $
  • What do users really care about? - Make something that responds to that. Either directly or indirectly.
  • Computers shouldn't set the users agenda.
  • Not all features are created equal. There are good & bad features.
  • Good features come from or are the result of good design.
  • Help users achieve goals v/s interrupt users
  • Elegance: don't go on about how good/clever you are.
  • [Having to make] decisions waste[s] users time.
  • Elegant code is not the same as clean code.
  • Elegant code is more than clean. If elegant it "doesn't look like there's enough code".
  • Elegant UIs take more work.
  • Not requiring user confirmation requires users be able to 'undo' the decisions you make for them.


Didn't pay much attention to the Python talk as it didn't seem that appealing and I was exploring helloapp. - Until my phone died that is.


Due to a last minute reorganisation of speaker order. Joel was back with the rundown on FogBUGZ 7. I already use this at work and for my personal projects but was prompted to investigate some features I wasn't using: integrated crash reporting; the backlog plugin; subcases & tags.  Joel also introduced Kiln.  I'm a beta user for this already but it was nice to see someone else using this.  The surreal side to this whole presentation was that Joel was using the example of developing the countdown app used at each devdays and how you could use FogBUGZ in that process.  I did. Very Deja Vu.


Android
Things that caught my attention:
  • No app review process - suprising!
  • Home screen widgets
  • Background services
  • Interprocess comms 
  • Universal (in app) search
  • 2.0 introduces:
    • Bluetooth support
    • Integrating contacts from multiple accounts
    • Camera APIs
  • Device targeting via custom device specifying via IDE plugin - create your own emulator
  • Tried to claim that a slow emulator is a good thing. - It forces you to make it fast on the emulator thereby ensuring that it's definitely fast on an actual device
  • Form/window/control layout is XML based
  • Activities = forms
  • Intents (really must find out what these are)
  • Native support for SQLite - can share stored data with other apps via a content provider
  • New GoogleMobile Analytics tools can be included in apps
  • Registered developers can buy developer phones (fully unlocked and available with no contract.)

jQuery
  • Uses TestSwarm - for cross browser testing
  • Find something > do something
  • Create something > do something
  • $ is an alias for jquery method
  • test code at jsbin.com
  • Don't select by just a class name as very inefficient in older browsers (which are slower anyway)
  • It fails silently - so if it seems to be doing nothing...
  • use single methods for setter and getter
  • .live() - allows updating selector for changed/added DOM element
  • a plugin is a custom function that's reusable and distributable
  • Mobile version coming


Jeff Atwood


Qt
Note. Ducked out of demo (second) part of this session to get some lunch/
  • Nokia's solutions for native development
  • "Being able to debug is the most important thing for developers" - the reason for the need for Open Source
  • Lowering the entry barrier for developers is the key for driving adoption
  • Success comes from 3rd party Innovation
  • Claims to be "the Java we never got"
  • Less code needed to achieve the same as lower level languages (C) - Saving money in maintenance phase
  • FREE
  • Has it's own IDE - QtCreator

Jon Skeet (& Tony the Pony)
  • Users want programs that do what is simple and obvious to them, at that particular time.
  • Architects design/create systems that are just as complicated as the real world but slightly different.
  • Evolution has cheated us by not giving us 16 fingers. I would have made us better at counting.
  • We (developers) struggle with the difference between continuous and discrete numbers.
  • We (developers) struggle with Text: multi-byte chars; combining chars; Turkish
  • We (developers) struggle with Time: 12/24 hours; date formats; timezones; Daylight Savings Time.
  • Know a bit more than you need to. What problems are you likely to have if the app/code was extended.

iPhone
  • Objective-C is like marmite.
  • "and that's why we have to say the same words twice" - WTF?!?
  • Obj-C is opinionated and includes a lot of historic baggage. :(

How not to design a scripting language
  • Don't read the dragon book. Recommended alternatives: Engineering a Compiler and Modern compiler implementaion in X
  • Foreign Function Interfaces: bad in principle but allow calling out to C libraries when need code that executes faster.
  • "A good rule for life in general: Don't expose yourself!"
  • Things that are bad: eval() and dynamic include/import

Yahoo! Developer Tools

"every browser is a bastard"
Some browser are "differently-abled"
JS Libraries are edge cases
YUI - looks useful, especially CSS grids
YQL - WOW! (see http://www.youtube.com/watch?v=SA4Et1DiVbE)



MISC
A couple of quick notes on the organistaion of the event and applicable to any such event:
  • Have a countdown that the speaker can see so that they know when they running out of time, or out of time.  - This is always preferable to someone coming on to the stage to tell them they have X minutes left.
  • Have a backup microphone on standby.
  • There's no excuse for having unprepared speakers.
  • There's no excuse for having unreheased speakers. Speakers need to know how long they will take and what they can do in the time they have.
  • Text and code must be visible on the screen to everyone watching (if that's what you're trying to show) - zooming in is fine to highlight a specific thing. Staying zoomed in and having to keep scroll around while zoomed in is not good for anyone. 
  • If doing a talk introducing a subject cover:

    • What can you do?
    • What do you need to do it?
    • What are thre fundamentals people need to know?
    • What gotchas should people be aware of?
    • What recommendations/tips should people know about?
    • What are the answers to the frequently asked questions?
    • Show a few cool and easy examples.



Thursday, October 29, 2009

StackOverflow DevDays - sad rant :(

Yesterday I was fortunate to be able to attend StackOverflow DevDays London.  I'm planning to do a detailed write up about the event shortly.  But just wanted to have a quick moan about a couple of bad points about the day.

Firstly, my phone did this very early in the day:

Phone = paper-weight!

Fortunatley I also had my blackberry with me so was able to take this picture but it only had a little bit of battery left to only allow me a couple of tweets during the rest of the day.  This meant I couldn't be my usual twittering self at a conference thereby missing out on what I find to be a useful part of such events.  This was further compounded as it meant I couldn't engage with helloapp.  I had heard about this when FOWA was on and was keen to see it in action.  On top of not being able to interact via twitter, I didn't take a laptop so couldn't use the web based site.  There was no dedicated mobile interface and the AJAX requirements of the site meant it was unusabel on mobile devices.  I noticed a lot of other people trying and failing to get it working on various mobeil devices. If Carsonififed are interested in adapting helloapp for greater mobile interaction and thereby allowing more people to use it and engage with other attendees I'd love to have that conversation.

Second issue of the day;
At the start of the lunch break I had a chance to talk to Joel about the CountDown app I wrote and he used at the start of the day and during breaks.
  • Yes this is the code he used in his Fogbugz/Kiln demo. I had a strong sense of Déjà Vu during this as I used FogBugz to track features and fixes during it's development and also hosted the source in Kiln, as an early beta user.
  • Yes this is the app I've written (banged on?) about before.
Anyway, because I was talking, I joined the lunch queue late. Before I got to the front of the queue we were told that food had run out but more would be available in 4 minutes. About 10 minutes later we were told some food would be available shortly. A few minutes later the lunch break was over and it was back to business - but still no food available.

Yes, I could have raced to get food when the lunch break started but that wouldn't have helped the 50 or so other people (my estimate) who were still queuing and also didn't get food during the break

I gave up waiting when Jeff came on to give his talk. I then skipped the Qt talk to get a sandwich.
All very disappointing.


Proper review and details of all the good bits will follow. Promise!


Note to self for future conference attendance:
1-Take loads of phones (not a problem - but must make sure they're charged!)
2- Get a netbook so can get online while there. This will allow doing things which don't have mobile support - (Boo!). Plus, anything larger than a 10" screen seems to big to carry around all day.

Friday, October 23, 2009

Tuesday, October 20, 2009

Monday, October 19, 2009

Thursday, October 08, 2009

Friday, October 02, 2009

DevEvening: MvcContrib & Developing for Windows7



As Alex Mackey has now moved to Australia, I've taken over the running of DevEvening.  Our next event is on October 22nd and, to celebrate my new responsibilities, I'll be talking about developing for Windows 7.  Also on the night Jeremy Skinner will be talking about MVCContrib.

If this is something that interests you whay not come down.

More information and to register to attend at http://devevening12.eventbrite.com/.

Thursday, October 01, 2009

11 approaches to mobilising your website

Here are some approaches to creating a mobile version of a website. Plus some notes on each approach.


1. Display different pages for different devices.
- Can be problematic when needing to make changes and/or when the number of devices you are supporting increases.

2. Display the same page(s) with different contents when viewed on a mobile device.
- Can be awkward to manage different versions of content. Especially if that means having different size versions of lots of images.

3. Have the same page(s)/view(s) for mobile but use different master pages.
- Obviously only an ASP.NET solution.

4. Use the same page(s), but with different CSS.
- Normally doesn't allow adequate ability to support the difference in context which should usually be applied to a mobile version.

5. Force redirection to different (sub)domain with mobile specific pages.
- Essentially requires maintaining multiple sites and can dilute brand and make SEO harder.

6. Do nothing - and fail
- The site may just not work at all on the mobile browser.

7. Do nothing - and have a poor quality site
- Some things may work but others not. This will very likely lead to frustrated visitors.

8. Rely on network transcoders or transcoding browsers
- Good luck with that. Do you really want to pass up control of what actually gets displayed to the people visiting your site?

9. Don't display anything to mobile users.
- You may have a reason for this but it's probably a bad idea to automatically exclude more than half the people in the world with access to the web.

10. Build a site which works on all platforms
- Beware attempting to implement this ideal and ending up only serving the lowest common denominator

11. Use automatic mobilising tools (instant mobiliser, mobify.me, etc.)
- Could be a good, quick and easy way to get a good mobile version of a site. Possibly as a temporary measure until mobile visitors require and justify something more.


What do I do/use?
A combination of some of the above. Varying on the requirements of a specific project.

11 Mobile web gotchas

Another list I had lying around which better serves the world by being somewhere viewable.

In no particular order:
1. URL lengths
Keep em short:
- because people may have to type them in
- because some devices/browser have issues with long ones (256 char limit in some cases)
2. Image sizes
Should be appropriate to the size of the screen on the device. - Don't include something which won't fit on the screen.
Keep the file sizes small too.

3. Javascript
There are varying levels of support with mobile browsers and some interactions won't work (e.g. there's no mouseOver - as there's no mouse.)
4. Select don't type input
Entering text on a mobile can be difficult. Don't make users have to enter anything they really don't have to. That means (as a general rule) select (from a list, or radio button, or ...), don't type whenever possible.

5. Not all devices support all image formats
You're pretty much safe with PNGs except on older devices.  Be aware if you want to use something else else, e.g. JPGs.

6. Header rewriting
Beware of trying to display a page's content based on headers whihc may have been changed by some proxies or operators.

7. Scroll vertically, not horizontally
It's easy to get lost on a page when you scroll in both directions.  Use vertical scrolling only as no one

8. Varying CSS support
Beware anything other than basic styles on older devices.
Be aware of massive variations in levels of support across older devices.

9. Can't get identical output on ALL devices
You may spend a fortune trying.  Aim for a consistent look and feel instead.
10. Keep page sizes small
General rule: Total page sizes should be < 20KB
Keep all asset (images, CSS, JS file) sizes as small as possible too.

11. Validation is important!
Really helps with trying to ensure cross device support
- http://ready.mobi/launch.jsp?locale=en_EN
- http://validator.w3.org/mobile/

Tuesday, September 29, 2009

My StackOverflow DevDays countdown app - Version 3

We'll now I'm at version 3.0 of my countdown app for DevDays it should be ready for use ;)

For reference:Version 1 - Version 2

This version was created to address the follwoing issues:
  • Optimized for screen resolution of 1024x768
  • Fixed issue with calculating displayed tweet display height
  • Removed hardcoding of sponsor images - they're now loaded from a 'Sponsors' folder on startup. This is to enable easily adding new ones.
  • Removed hardcoding of tweets displayed when nothing new tweeted or no internet connection available. - These are now loaded from an XML file. This allows customisation of the displayed messages.
  • Defaulted start time to countdown to 9am if started before then. If started after then the timer defaults to 5 minutes. (This only applies if no cmdline parameters passed.)
  • Fixed the order that tweets are loaded so oldest are shown first.
  • Fixed positioning of twitter profile images.
  • Also a few other minor fixes.

Source - Compiled binaries - Installer

Now it's even better, please vote for it. ;)

Thursday, September 24, 2009

Ten reasons web developers should be considering developing for the mobile web

Excuse the roughness of these notes but I thought I'd post this list I had hanging around.

1. More people using it
  • More than before
  • And they're using it for longer than before
  • Globally more people access the internet from a 'mobile' than a 'PC'.

2. Bigger screens
  • Have made mobile browsers easier to use
  • Enable a better experience by allowing the viewing of more than just simple text.

3. Better browsers
  • Can render as well as some desktop browsers
  • Even with flash support
  • Silverlight mobile coming (apparently)

4. Can get 95% of devices with a single output format
  • XHTML-MP

5. Cheaper & easier to do than probably think
  • It's not as complex as having to develop WAP (anymore)
  • Tooling makes it easier

6. Transcoders aren't good enough as don't consider context

  • You can create a better experience if you target specifically to the mobile environment, rather than just rely on a machine trying to guess at what would be best.

7. Wide variety of tools to help you

8. Big companies thing it's important
  • Eric Schmidt (Google) - "Mobile devices are the most important technology of all."
  • Eric Schmidt (Google) - "Google's future depends on the next internet, on cellphones."

9. Provide new ways of interacting with existing users and opportunity to reach new ones
  • New ways to build community
  • New ways to build loyalty
  • New ways to make money

10. You already do (or should) variations of your site(s) (for accessibility)
  • WCAG
  • Section508

Unit testing has it's place

Joel just published this: The Duct Tape Programmer
Go read. I'll wait.

Ok?

Good.

In it, amongst other things, he seems to come across as saying that unit testing isn't worth it because it doesn't help you ship code/a product/a feature in a really short time frame.

But that's not the point.  Unit testing helps improve code quality by preventing bugs over the long term.  The value of unit testing is in the long term.

In the short term it's often better to have software with bugs in than no software at all.  This can help you beat a competitor to market or win that big new contract.
In the short term you're not worried about making a change to one part of the system and inadvertently breaking something else (which automated testing is really good at identifying) because you're not making changes, yet. You're just writing the initial version.

But, in the long run, if you want to keep that market share and avoid losing customers to a competitor with a more reliable product you need to make your software more reliable and contain fewer bugs.

In the long run unit testing will save you time (well maybe not you directly but the development/testing/QA team as a whole). That's the value of unit testing - over the long term.


I've previously written about the value of unit testing here.

Wednesday, September 23, 2009

I should hope you think it's slick - I was aiming for F***ing Amazing!

WARNING - this is likley to be controversial. But I aim to promote discussion as much as anything else.


I responded to a request for an application to do a simple task.  One of the comments on my app was "Very slick".  This is of course flattering, but it says a sad thing about software development in general : mediocrity is standard. Fortunately this, hopefully, won't remain the case:





Why would I (or anyone) submit an application which was adequate? What would be the point of half hearted effort?
  • Seriously, I don't know.




Yes, with version 2 of my DevDays app, I've gone beyond the original requirements. But why would I (or anyone) do this?
  • Because just doing enough isn't going to stand out!
  • Because just doing what anyone could do isn't going to stand out!

But isn't that doing unnecessary extra work? Who's going to pay for it?
  • The trick is to provide a lot of value for a little extra effort. It's paid for when that work gets you great recommendations and future business.


In my app I've added 'Twitterfall' type functionality. This was relatively simple to add through the use of the TweetSharp library.  The value it adds to the application is great. It turns a passive application into an interactive one. Plus it's a boost to me: I got to try out a new library; I got to interact with Joel and received a boost in confidence that what I had created was good; plus I got some subject matter for a blog post.


Before I go on:
  • Yes, I know there are times when there really is no need to do more than the absolute minimum.
  • Yes, often there are other external pressures.
  • Yes, often a client may have a limited budget.
  • Yes, a client may want a very specific thing and not be interested in it being the best it can be.
  • Yes, there are probably lots of other resons not to do this - but I'm being idealistic and this is my blog so I'm allowed.




Anyway, what was the point of all this? Oh yeah.







I want to make applications that are truly great and people enjoy and want to use.


I want to immitate someone who was actually a master craftsman who worked with wood. (He was more than just a famous carpenter.)


I want to put effort into what I'm doing and do the best possible job.


I don't want to make software people complain about at work when they compare it to the software they use at home.


I don't want to make a second version of a piece of software for someone because there was a clause written into the original contract that means they have to come back to us for future versions. I'd much rather write the first version of a piece of software and hand over the source code to the client (so they can get anyone they want to make the second version) but still have them come back to me to make the second version because they were impressed with what they received the first time.


I don't want to make commodity software. I don't want to be a commodity developer!


I don't want to make average software. I want to make great software!




This isn't just idle claims. I've actually been putting this into practice with a recent project.  It was a common scenario: Large project and only a fraction of the time needed to complete it to a decent standard.
I saw two options: 1. Work at a reasonable rate and if everything went well end up with something that may be barely acceptable. or 2. Go above and beyond and create something I could be proud of.


Due to a unique set of circumstances (mostly my wife having arranged to visit her parents for two weeks with our son - so I was home alone) I was able to select option 2. Also, fortunately, the requirements of the project were an almost perfect fit with my skills (Windows Mobile, WinForms (desktop), ASP.NET & WebServices) so I stood a reasonable chance of being successful.
I decided that if I was going to undertake the project it was going to be as good as I could make it. This was as much to prove to myself that I could make some thing great in the time available as it was to deliver a great solution.


Yes - I made it very clear that the extra effort was a one off and not indicative of what could be expected in the future. That this was an exceptional level of effort was repeated back to me subsequently by the appropriate parties so I think I got this across.


I should also point out that the project (which I'm not allowed to talk about) was something very cool and something I wanted to see succeed.  The deadline was for a pilot/demo which would be visited by many potential customers. The purpose of the demo was to prove that the technology worked and win, potentially, very large contracts.


So for the 2 months up to the demo I lived the project. It seemed like every waking moment was spent thinking about it, and even now find myself thinking about the next stage - which isn't what I'm working on. And I did loads of overtime (over 100 hours - all unpaid). This included an all nighter after the event when the client moved the deadline for the post event data analysis. I worked through the night (well I had one hours sleep before going in to do anohter full days work) because I didn't see the point in goign to all the effort before hand to make the demo work only to not be able to prove what we'd done.  If you can't (accurately) report on what the system did, did the system really do anything? Was it all just smoke and mirrors?


When it came to the demo:
  • the customer was very impressed as what I delivered was better than they had hoped for.
  • there were a couple of minor bugs, but because I was there I managed to find workarounds - so no big deal, considering.
  • the users of the software were initially wary but after a short time prefered working with the application and didn't want it taken away after the demo.  They were also more productive with it.
  • the potential customer we wanted to impress, were very impressed.


So was it worth it?
  • I was happy with what I achieved.
  • The client was impressed.
  • The potenital customers were impressed (and some have already signed some big deals).
  • I think, my boss was impressed.


But was it worth it?
I think so. I wanted the project to succeed and was only interested in being involved if it could be really good. (In retrospect I think I only managed to reach the level of 'barely acceptable' by my standards - but these are very high.)  Yes I had to work very hard, but it was better (in my mind) than having just created something average - again.


What if I hadn't gone 'beyond the call of duty'?
- Because of the tight schedules I was keen to see how much I actually got done in a realtively short period of time. I was also keen to know exactly how much time I spent on the project. So I recorded (admitedly only in a basic way) how I spent my time.
In my estimation, if I hadn't put the extra time and effort in, the amount I would have got done would have meant that: there would have been some fairly essential functionality not there; the look and feel of the applications would have been much poorer; there would have been more bugs; the last minute changes that were necessary to actually do the demo couldn't have been made. All of which means (by my reckoning) that if I hadn't put the extra effort in the demo wouldn't have gone ahead.  This would mean that the sales people wouldn't have had anything to show. They would have had a much harder job convincing the potential customers to but their business in the hands of a system they couldn't even see demonstrated.


Yes, I'm sure that if it was necessary some kind of limited demonstration could have been put together - instead of the full working system I created.
No, this isn't a dig at the sales people - it's just an observation that it's much easier to sell something if you can show it working, and working well.




So what did I learn from this:
  • Making something great was worth it to the business.
  • I am actually very clever and can make the applications I always knew I could.
  • I REALLY don't want to work to that level again. (At least not without some serious reward* and only if the impact on family life can be minimized)
  • Some other things it doesn't make sense to talk about here.


* Part of the reward in this case is me being able to say "I made that". - At least I will be able to say that when I'm allowed to talk about the project. ;)

Other thoughts:
  • This is only possible if developing for someone who wants to make a great system
  • I suspect it would be MUCH harder to create a truly great system without a very itterative process.
  • Part of the reason that the client was so happy with what was delivered was "exactly what they wanted" not what they actually/initially asked for. I can see 3 reasons this was possible:
  1. I had good knowledge of the application domain. (Another reason I was excellently suited to the project.)
  2. I spent a lot of time talking direclty with the client to confirm exactly what they wanted and discussing possibilities.  I suspect that if these communications had gone through other parties at least some of information would have become confused or lost. (Time constraints meant that there wasn't time to formally spec everything prior to development. - For the demo version only. This isn't a good way to build large, long lasting, reliable software.)
  3. The original 'spec' had reporting as a 'wish list' item. My experience taught me that it was actually essential and internally I promoted this to an 'essential' deliverable.  - I was working on the basis that if you're going to be showing & trying to sell something to people who are only interested in the data that comes out the backend it helps to be able to show that data.  Not only did I show the data but also put it in nice graphs (which everyone deemed was more than they could hope for - I consider that a Saturday well spent).  As I sat in on some of the sales demos, I saw jaws drop in amazement and wonder as we were easily able to show and explain trends in data that no-one had previously been able to even capture.  - I suspect that making sales is much easier when you've been able provoke that response.



Side thought: Is making boring, unremarkable software one of the reasons that many developers don't stay in the industry for a long time?


Yes, I have been influenced by Hugh Macleod and his book.

My StackOverflow DevDays countdown app - Version 2

Based on the announcement that my devdays app will be used in an environment where there is internet access available, I've updated to include the TwitterFall-esque feature that I originally removed.

It now looks like this:



The difference is the twitter messages displayed at the side.  These are looked up based on a search term specified in the config file.  If there are no new messages to display or it's not possible to reach the internet (network down, etc.) then one of an assortment of programmer related quotes is displayed instead.

The processing of commandline parameters is also improved.

Now it's even better, please vote for it. ;)


Source - Compiled binaries - Installer

Tuesday, September 22, 2009

Monday, September 21, 2009

Holiday scam? - 0800 988 9900

Incase anyone else receives a call saying they have won a holiday after completing a questionnaire over the phone:

Just had a phone call telling me I'd won a holiday after answering a questionnaire over the phone - I never do and find polite ways of hanging up on market researchers.

Using a technique which just sounds really suspicious, they told me I'd won a holiday for 4 to a European destination which I could take in the next 18 months. I just had to call a number they gave me (0800 988 9900) and quote a reference. When asked why, they said they weren't legally allowed to ask for my address!? and I had to call some other department who would take my address details and send me some information. They also (indirectly) said I had 5 minutes to make the call as the department closed shortly (called at 19:55 and said shut at 20:00). - This may have just been coinsidence though.

It sounded REALLY dodgy - so I did what all geeks would!

From the results of the search here: http://www.google.co.uk/search?q=08009889900 I won't be following up and I'd think twice before you did too.

Do people really go for this? - The psychological tricks seem so basic!
Are people more likley to fall for this in a recession?

Monday, September 14, 2009

My StackOverflow DevDays countdown app


In response to Joel's request for an application to use as a countdown timer for StackOverflow DevDays, I have created this little app.

Here's a screenshot:



Obviously the design is highly inspired by the website. But I never claimed to be a great designer.

I had a couple of other thoughts about a screen design but liked the simplicity of this one and the ability to maintain the branding.

Obviously, I like the idea of this app being used at the conference but I also saw it as an opportunity to try and do some animation with WPF. (I've only written minimal XAML previously.) While I'm sure that this could be written in much less XAML I'm quite happy with it.

What the above image doesn't show is that the black and white city images scroll in the background and the sponsor images slowly fade in and out - showing one at a time. Also when it starts the different screen elements slide and/or fade into position. Then, when the timer runs out they slide back out as the screen fades to black.

Originally I was going to have a twitterfall type element showing latest tweets at the side of the screen where speakers are shown on the site. Unfortunately as there is no guarantee of internet access when used I left this out.

Here's a video of it in action:



Hopefully you like. If you do and are a StackOverflow user why not vote for it. ;)


Source - Compiled binaries - Installer

Friday, June 12, 2009

10 Firefox Add-ons for Mobile Developers

The following add-ons are invaluable for anyone developing mobile sites.

XHTML Mobile Profile
This add-on allows FireFox to support the XHTML Mobile Profile mime type

WMLbrowser
This add-on allows FireFox to support WAP 1.0. Just in case you are unfortunate enough to need it.

FireBug
Just as essential for developers of mobile sites as those viewed on the desktop.

HTML Validator
Because validation is even more important on mobile as some browsers really struggle or even throw errors with invalid markup. 

Web Developer
An essential tool for all web developers.

YSlow
Yahoo's tool for identifying ways to improve the performance of a pages load time (Requires FireBug)

Page Speed
Google's tool for identifying ways to improve the performance of a pages load time (Requires FireBug)

User Agent Switcher
Allows testing how a site will be displayed on various devices. (Assumming that pages are adjusted for sites based on the UA.)

Modify Headers
Because sometimes you need an easy way to test, and change, headers other than just the User Agent.

Live HTTP Headers
Another way to see what headers are being sent.

Wednesday, June 03, 2009

It's M. R. not mister

Not that it really matters, but...

With the domain www.mrlacey.co.uk (and .com and .net and .mobi) and the twitter name @mrlacey it might not necessarily be obvious, but the 'mr' refers to my initials, rather than my title.

Yes, my full name if Matthew Robin Lacey.
Yes, this makes me Mr M R Lacey.
No, this isn't a reference to a certain pop act.

Notice over, please carry on.

Tuesday, June 02, 2009

In C#: generate a class for an XML file

For my own reference as musch as anything.

Often it's useful to have a helper class to work with a complicated XML document. Unfortunately, I seem to most often need to do this for documents for which there is no official schema.

Here's a quick way to get things done using xsd.exe.

"C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\xsd.exe"
config.xml

"C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\xsd.exe"
config.xsd /classes /language:CS /namespace:MyNamespace
/out:"C:\path\to\desired\dir"

Monday, June 01, 2009

Friday, May 29, 2009

Thursday, May 28, 2009

Every Developer Should Know ... no more

I had this grand idea for blogging. I'd blog about all those things that it amazes me that other developers don't know.  The things that I thought every developer should know, but, it seems so many don't.

In amongst some other grander ideas it was also intended to encourage me to blog more and more frequently.

Unfortunately having 'another blog' didn't motivated me to blog more frequently, it just became an extra pressure.  It therefore seemed an excellent candidate for things to face the cut when I decided to rationalise what I spend my time on.

Until the domain expires it will point here and the original posts are at http://everydeveloper.blogspot.com/

I've also imported most of the posts into this blog (http://blog.mrlacey.co.uk/search/label/evdevshokno). Hopefully I finish some of the draft posts too. - Perhaps.

Wednesday, May 27, 2009

DDD South West

Last weekend I attended DDD South West.  It was a really good day and I recommend it to anyone.

I once again took the opportunity to give a grok talk on Mobile Web 2.0 and MDBF. The slides from this can be seen below.
Again this talk was well received and I had lots of positive feedback.

Here's a few pics from the day:

 
Quite a venue.
Guy looking like he's talking to an empty room


He wasn't!

Some people enjoying the sunshine in a break.

crowds for snacks

Cream teas in the afternoon!

The main room

More people relaxing outside

Another of the rooms.