Todd Parker – jQuery Mobile Keynote

Todd Parker talked mostly about one of the hottest parts of jQuery from last year: jQuery Mobile, a framework built to put mobile devices first.

Todd talked merrily about building the framework on principles of progressive enhancement and responsive design. I think most people walked away from this talk excited about the stuff we’re able to do now and I’m looking forward to a project where we can have a play with it.

Dion Almaer and Ben Galbraith – Web vs. Apps

A fascinating talk about the future of native mobile applications. As modern browsers get better and better developers can do pretty much anything they like, so will native applications eventually die out? Dion and Ben felt that they wouldn’t for quite a while but we’re starting to see hybrids of native applications and web applications (for example the Facebook application) where developers have more control over forcing users to upgrade and writing core components just once.

Haymo Meran

For a company that works with CMSs a lot it’s fascinating for us to see things we could leverage to make our users’ lives easier. This was a talk that did just that. Haymo talked about Aloha Editor, a WYSIWYG editor that has the potential to extend the TinyMCE. It works quite a lot like Sitecore page editor but looks even more advanced.

Paul Irish

Paul works on Google Chrome development. He was  a great speaker and his talk featured loads of geeky goodness, covering a whole range of recent technologies we should all be playing with, such as CoffeeScript, LESS and HAML – it’s way too much to cover here but you can get grab his slides here.

I had to run off for babysitting duties before the evening do kicked off but even missing some free drinks does not take away from what an interesting, inspiring and well-organised event this was. Many thanks to the organisers White October and I look forward to next year’s event.

Before joining Eduserv in 2010, Steve developed internet banking applications for the financial sector. He enjoys Eduserv’s relaxed work culture, interesting projects and the wide variety of technologies that the web development team uses. His recent projects include the JISC, NHS Direct and Victim Support websites. Outside work Steve can usually be found cycling, pottering down to the coast or just happily sitting around enjoying tea and biscuits.

It’s great that Government is thinking about a common domain for its services – and although I’m not sure this is causing too much lost sleep for UK citizens right now, the government – like many commercial organisations – will reap the benefits of simplicity both in terms of user experience and further application development.

A common, modern look and feel with integral personalisation and an intuitive, compelling user experience is a major improvement which will make it simpler for users to interact with government and encourage repeat use of government services online, fewer support calls and simpler transaction handling.

Saving money on the delivery of online services is a great benefit and it’s this message that occupies most of the column inches that have already been written about the whys and wherefores of gov.uk.  But this isn’t the most profound impact that a successful online national service will have.

The underlying challenge that gov.uk and the “digital by default” agenda sets  for the rest of Government is to understand their role in the delivery of modern Public Services.

At its very core, the creation of gov.uk challenges the structure of (what is increasingly) the Government’s back office.  Is now the time to start moving away from  functional silos to structures that are more effectively organised around the citizen and the business?  In rethinking how Government works, there are some dominant themes:

The shift from retailers of public services and information to wholesalers
Departments need to think of themselves as wholesalers working with an extended supply chain – providing information through the channels that public consume including the wider traditional, online and mobile channels .

Gov.uk provides a Government-own brand for service delivery but will be part of a richer tapestry of delivery mechanisms (through the media, as integral part of private sector services etc.). With richer options for collecting data and for service delivery, departments need to think about how they orchestrate delivery – pushing interactions to the most effective and efficient channels.  This is an area in which we anticipate significant innovation, service improvement and cost savings in the ways that Public Services can be rethought, repackaged and delivered.

Changing the nature of relationships, redefining the architecture of Government
By using tools like getsatisfaction.com, gov.uk is demonstrating how you can get greater participation in the creation and delivery of Public Services.  It is pushing  departments to work in new ways with their stakeholders and wider audiences when developing services.

Much of the raw material of Government services exists in the modern world in a readily-consumable format. The days of the blank form should be over.  That raw material (for example, details about earnings flowing through payment networks) should form the basis of service provision reducing the touch that Government has on citizens and increasing the accuracy and timeliness of service provision – and reducing the support burden on Government itself.  Much of the new world is “bottom-up” and to effectively harness and play its role in the modern world, Government needs to work out how to interface with, use and deliver services into this environment.  The cultural and organisational change that’s needed after the dominance of traditional command and control models should not be underestimated.

There is still a long way to go from the gov.uk beta to the dynamic, mobile, relevant, personal interface to Government to which the gov.uk team aspires. But you feel that the journey for the rest of the civil service towards adapting to the change may be far more profound. What will emerge from this transformation will be a model for stable, effective governance for the next millennia.  Bring it on!

Jonathan Sowler is Government Client Director at Eduserv. Follow Jonathan on Twitter @jonsowler

Dart is a structured, single-threaded, single inheritance Object Orientated  language with a lot of familiar syntax if you have been developing in either JavaScript or a C based language in the past.

Objectives and rationale behind Dart

Google has designed Dart to be a flexible and structured web programming language that works across multiple platforms and interfaces such as mobile devices. A core objective is to reduce bandwidth usage over an equivalent JavaScript based function. Google hopes that it will be familiar to web programmers and that they can migrate to it with little fuss.

Dart targets compatibility with multiple device types that allow you to view the web, including laptops, servers, smartphone, tablets and so on.

The overall goal for Google was to take JavaScript and make it more flexible, faster to run code, easier to learn, more secure and other general improvements to bring an all round better version of JavaScript. Google is hoping that Dart will replace JavaScript as the default web language that is automatically built into web browsers.

Google will soon be rolling out Dart in future versions of Google Chrome and it’s in the testing phase at the moment. Google has made some claims about the code’s performance, which in tests has demonstrated faster loading times of  up to 90%. When speed is key to running web-based code, this is a big factor for developers and users alike.

Assuming Dart lives up to the hype and Google statements then as far as I can see Dart will easily be adopted as the web programming language of choice and certainly over time replace JavaScript within future web browsers.

For anyone wanting more information and developer tools to try please visit Google’s site for Dart.

Authored by James Spencer, Web Development Team. (@JSPhotographyUK on Twitter)

Get in touch

We have a number of new exciting projects for 2012 and will be blogging about these in the coming weeks and months. However we’d like to know if there are any topics that readers would be interested in hearing about. We’re primarily .NET developers that specialise in Sitecore CMS and Umbraco CMS solutions, integrating with products such as SOLR, WordPress, Payment engines, Google products and other third party web applications.

If you have a suggestion for an article please leave a comment below or email us.

On behalf of the team I’d like to wish you all a happy and safe Christmas.

James Spencer is a Manager within our Web Development Team. You can follow him on Twitter at @JSPhotographyUK.

Get in touch

Over the last few months there’s been a great deal of change in the marketplace, including the popularity of these platforms among users.

iPhone iOS used to be the most used mobile Operating System (OS) some 9-12 months ago but the situation has changed and continues to evolve each month.

Market information for October 2011 shows that:

• Android continues to grow in popularity and is up 4.4 points to 46.3% of market share
• iPhone iOS has 28.1% (up 1.0 point)
• Blackberry has slipped with its share dropping from 21.7% to 17.2% in the last three months alone. This drop is widely attributed to the technical issues experienced with the recent Blackberry server outage and also the greater variety of services and application available on iPhone and Android.

Rougly 75% of smartphone users download applications so this gives a company a huge potential market of mobile users to tap into for their own application.

When considering which platform you’re going to develop for, obviously Android and iOS from Apple still continue to have the most market share. Blackberry seems to be slipping fast and I predict this continuing to drop with Android taking on most of this business from RIM devices. So in effect you should always develop for Android and iOS and then consider Blackberry and Windows phone 7 as either later development or exclude them completely from your plans.

Also consider these practical and usability factors before committing to a certain approach or design:

Decide between a generic application to work across all platforms or platform specific development approach. Should the generic approach be taken then this will obviously work out cheaper and provide a fairy standard look and feel application across all platforms. Should you go down the native platform development approach, this will cost a lot more and take longer to implement but at the same time you get platform and device specific functionality available to you through this approach which you don’t always get with the more generic methods of development.

What are you trying to achieve? List your objectives and workflow involved and then consider if a mobile application is the right way to go.

Do you need design help to achieve a good user interface design?

Do you need access to the core website to ensure the application works i.e. is the application reliant on the core website?

Will the phone need to store local data or not for the application?

Would you prefer a standard look and feel across all platforms, or do you require a platform-dependent design?

What mobile services might you need to make use of? Eg. 3G, WIFI, GPS, camera phone use etc. and then build these into your design and workflow.

Why not contact Eduserv to discuss your mobile application requirements and see how we can help you tap into the ever expanding mobile application market.

Statistics source: Information week Nov 2011

Authored by James Spencer, Web Development Team. (@JSPhotographyUK on Twitter)

get in touch

The Bristol Sitecore User Group is fast becoming a welcome regular event that gets the cream of south west Sitecore developers together in a dark room and feeds them some useful titbits of technical information.

Organised and hosted by Sitecore, it’s something we Eduserv developers look forward to and this month was no exception, especially as ex-colleague and Sitecore MVP Stephen Pope was due to speak for the first time since joining Sitecore.

The talk was made up of two parts, the first from Raul Jimenez about the improvements to the Page Editor in Sitecore 6.5, the second from Stephen Pope on ‘Custom Fields’.

Page Editor – Raul Jimenez

The page editor has always been a contentious issue with developers. Whilst we like the idea of users using a WYSIWYG environment there are always a host of technical and security issues to worry about.

Sitecore 6.5 seeks to address these issues and Raul rattled through a host of new features and changes that actually made the Page Editor look quite fresh and exciting. It seems to have matured into a really good product in 6.5 and any new sites we build will certainly be designed with the Page Editor first and foremost in our minds.

Custom Fields – Stephen Pope

Stephen Pope talked us through creating ‘Custom Fields’ in Sitecore. Custom fields are basically a way for developers to extend the field types that Sitecore currently offer to do something exciting – you can find out more on the Getting to Know Sitecore blog.

In this example ShowDown.js and MarkdownSharp to create a rather whizzy Sitecore field that allows users to write markdown code and render it on the frontend, all very impressive.

Overall it was a great event. We got to see a couple of good demos, had a chance to chat to fellow developers and we even ate some meatballs, lovely.

Want to join our team of Sitecore developers and work on projects for high profile clients in the public sector? We’re looking for a new web developer. 

Developers take to their laptops for GiveCampUK

On Friday 21st October, some fellow Eduserv devs and I headed to UCL Bloomsbury campus to participate in the first GiveCamp event to take place in the UK. And what an event it was!

After an introduction from Rachel Hawley, everyone gathered in the main hall to talk to project leads and decide which project they were working on.

We had already discussed prior to arrival that we would work on the requirements from The Prison Phoenix Trust, a charity that encourages prisoners in their spiritual lives through meditation and yoga, working with silence and the breath.

The project brief:

We’d like a new database to replace our three current partly-linked ones; integrating the data, and presenting a more usable and friendly interface. We’ve seen and used sites like Ebay and Kayak, and would like to get information out of our database as easily, or as near to it as our data will let us.

By 22:00 that evening we had a team of twelve discussing the key points of the system;

• a new database schema with a much more robust/normalised design,
• a core application for data entry and modifications,
• and a reporting system that allowed custom reports to be created and viewed.

It was clear that the changes to the database schema were paramount and part of the team (Jon and Mike) began development on this straight away. Naeem Sarfraz developed a cracking data scrambling tool due to the sensitive nature of the data. Liam Westley provided some excellent information on the pros and cons of SQL Reporting Services and began investigating how much functionality that would provide. Later on Ellie would begin working on how we would take current reports from the Access databases and reproduce them in the new reporting tool.

We needed to bake (tenuous cake link) the client's existing data model into the solution

One of the more difficult aspects was deciding on the tools to use for data entry and modification. Since taking on his role as Consultant Systems Supervisor at PPT, David Kennedy has made several changes to the data model and we didn’t want to remove this capability from him. We wanted to provide a solution that would be flexible to his requirements now and in the future.

We discussed an Umbraco solution, using the back-end to structure a loose schema which David could modify by simply adding in new items as needed. We also discussed a simple MVC 3 application and finally the use of LightSwitch. All three had their problems; we felt Umbraco would take too long to develop a working result in the tight time frame, the MVC3 application would be too restrictive on future data model changes, and no one had developed in LightSwitch before.

Early Saturday after a quick stand-up meeting and a LightSwitch overview from David Whitney, we decided to run with Lightswitch. Even though we hadn’t coded in it before, it provided the key pieces to David’s future PPT requirements. LightSwitch provides the ability to add new columns and tables to the data schema as well as create new input and search screens for that data – all with minimum development effort.

No sleep till check in

The front end guys (David Whitney, Sam Salisbury, Naeem Sarfraz, Adam Christie, Craig Stevens, Jason Mitch and our own David Peel) got their heads down and hammered on. The Saturday development consisted of a lot of highs and lows, delving into the inner workings of LightSwitch, issues with broken builds (which in hindsight weren’t the fault of LightSwitch itself, rather trying to use LightSwitch with a version control system), and further database work.

By Sunday morning  we had the key parts of the system in place. Some areas of the LightSwitch app still needed work and some parts of the data migration needed finalising but the reporting system looked robust and a process for tying all the components together needed to be completed. Liam knocked up an extensive deployment document for the reporting services, Naeem, David Peel, Jason and the other front-end guys managed the LightSwitch documentation.

Eduserv developers among the PPT dev team at GiveCampUK Credit: Bert Craven

At 12:00 on Sunday, with the data migration tool just about finished, it was down tools. We joined the other attendees outside for some fresh air and a hog roast!  We all took a few hours to relax, chat and talk with other teams about their projects. take a few pictures and take stock of the weekend.

It was hard to miss the smiles on everyone’s faces. Sure, everyone looked tired, but there was a real sense of accomplishment and excitement over what had been achieved in the last few days. At 15:00 the accomplishments of each team were confirmed as we gathered for some brief demonstrations and talks. The work completed was fantastic and every team had come up with something to help their charities move forward.

I think it’s safe to say that the inaugural GiveCampUK event was one of the most stressful, tiring, but exciting events I’ve ever been to. Paul Stack deserves a huge amount of credit for bringing the event to the UK and Rachel Hawley no less for being his right hand throughout.  The pair of them pulled it off spectacularly!

Also a huge thank you to Eduserv and all the sponsors who delivered swag and kept us fed and watered.  An even bigger thanks to UCL London for providing the venue completely free.  To get such a high level of support from so many, the event is in good standing for the future.

Finally a big thanks to all the guys that we worked with over the weekend, we wouldn’t have made it through without you:

At Eduserv we’ve adopted a couple of methods to help achieve more realistic estimates.

One that revolutionised our process is the “burn-down chart”. Taken from Scrum, it requires developers to re-estimate remaining effort on a daily basis. The results are plotted on a chart of remaining effort over time, powerfully showing whether the original effort estimates were on target. Under- or over-estimates are flagged early in the project, allowing project managers to re-allocate resources or re-negotiate priorities as appropriate.

Another method we use is “three-point estimation”. For each component to be developed, the developer provides minimum, maximum and most likely effort values. The distance between the minimum and maximum values is an indication of the developer’s uncertainty, with wider intervals indicating greater uncertainty; useful information in itself.

It is a common mistake just to tot up all the “most likely” figures and plug them into a project plan. Not only should the uncertainty be taken into consideration, but the ‘expected’ effort of each component is actually the mean of the three estimates (ie. sum the minimum, maximum and most likely and divide by three). This might seem strange, but to take the example of heights of people, the most likely (read: most common) height of a person is not necessarily the same as the average. (It’s all to do with skewed distributions, but that’s another story.)

In conclusion, using the two techniques of burn down charts and three-point estimates can allow developers to form estimates they feel more comfortable with. Errors in estimates are flagged up early in the project, allowing for early tweaks to the plan. The result: greater chances of delivering on time and to budget.

Neil Pullinger is a member of our highly experienced team of .NET developers, specialising in Sitecore CMS development. You can follow Neil on Twitter @dotnetnutty

GiveCamp came to my attention through a short talk from Paul Stack at this year’s Developer Developer Developer South West day.  He highlighted the huge amount of time and effort that has gone into making the program a success in the US; helping deliver over $1 million of developer time and resources for free.  Over 150 charities and not-for-profits have benefited within the four years the scheme has been running.

I felt the event would be as rewarding for the developers as it would be for charities and quickly requested that a team be considered to take part in the inaugural event.

I’m glad to say that a team of five from our Web Development and Application Support teams will be taking part!  We’re a keen team with a wide range of experience in dealing with .NET and Open Source solutions, CMS development and a host of other related technologies.  The team has worked on a wealth of high-profile projects including DfE, NHS 24, NHS Direct, JISC, Victim Support and many others.

The event kicks off with a gathering of developers and charities, discussing plans and ideas over dinner before getting down to business. The limited time frame to develop a solution means team work and high spirits are paramount. To keep those spirits high we will be joining several others, pitching tents and camping out!  It is GiveCamp after all.

We will be tweeting videos, images and probably some mumbled text (when sleep deprivation kicks in) to chronicle the weekends events under the hashtags #teameduserv and #givecampuk.  Hopefully we’ll get some time to grab a few words with Paul himself and a few others taking part.

Each team member will be tweeting under their own account and may also be blogging both before, during and after the event.  You’ll be able to follow the noise at:

• Kieran @kieranties / kieranties.com
• Mike @mikeedwards83 / experimentsincode.com
• David @peelybird
• Jon  @jon_p_david
• Ellie @realityisbuggy

Of course, it’ll also be worth checking out the offical GiveCampUK twitter stream and blog as well as the Eduserv twitter stream for further updates.

What is it? Unit testing, of course.

Many of us dev types have seen the consequences of not doing enough unit testing: bugs crop up that aren’t spotted until later, fix times increase and overall confidence in the code drops. Several of us in the web development team here at Eduserv are interested in this topic and have resolved to fix the shortfalls.

What’s the big deal with unit testing?

Want to relax on your hols? Unit test your code

For me, it is about enforcing the contract of the developer’s original intentions. When I develop a method, everything is (usually) fine if I’m the only developer going to use that method or redevelop it later. But what if a colleague does some refactoring while I’m on the beach at Bognor? Everything recompiles all right, so it must be fine, right?

Of course not! While the compile-time conditions might have been met, the run-time conditions might not have. Your method might now, for example, be being passed a null, causing a bug somewhere in the chain. How long would it have been before this had been noticed? Your faithful unit test, on the other hand, would have flashed a bright red light, much to your embarrassment in front of your developer peers watching the same build. (See, I told you there was a reason I left my DoSomethingUseful() method in that library.)

Our tools of choice for testing

Typically, for testing .NET code, we’d use NUnit to run the tests, Moq to stub out methods and mock interfaces, and NCover to check code coverage.

On the subject of code coverage, reaching 100% coverage is probably not good enough. Yes, you read that right. If you’ve developed a method that accepts a parameter or two, thorough testing would check output against every conceivable input value (nulls, empties, invalid values, negatives, positives, etc). This might result in the code of a comparatively short method being tested numerous times. The code coverage statistic does not reflect this; it might be 100% after just your first test. So, what good is a code coverage statistic? Use it just to alert you to code you haven’t tested *at all*.

The question of whether to go “test-driven” or not is a side issue. “Test-driven” refers to the practice of writing your tests upfront to define the requirement, before you write the code that does the actual work. In practice, I’m not sure it matters too much. I tend to develop both organically and in parallel. Having said that, I recently demonstrated SpecFlow to the team. It’s a tool that generates unit tests from a set of requirements written in a particular format. I’d love to see us adopt this; and if we did, I still suspect the majority of our (or my) test code would be written in parallel.

I’ve not touched on automated UI testing tools (eg. Selenium). This is mainly due to my personal lack of experience with such tools to date and I hope to investigate them further in the future.

I also intend to finish reading Roy Osherove’s book “The Art of Unit Testing” and implement some of his suggestions. From what I’ve read so far, it’s a really well-written book and I should note my esteemed colleague, Kieran Marron (@kieranties), zoomed through it in a matter days. I try not to be bitter about this.

To conclude, unit testing is an essential part of software development and needs recognising as such. Time spent investing in it is rewarded later with fewer bugs and increased confidence in the code. It encourages the developer to think about what he or she is trying to achieve and protects against those Bognor beach moments. Start small and build on it.

Happy testing.

Neil (@dotnetnutty)