Intel XDK – a nice development environment for mobile apps

Intel XDK

I’ve started using Intel XDK which I find a nice environment for developing mobile applications.

It’s based on developing mobile apps using existing web technologies, such as HTML5, Javascript and CSS.

This has the advantage that the apps can easily be deployed on different platforms, such as iOS for the iPad / iPhone, Android, Windows Phone, etc and you don’t have to learn specialized languages such as Objective-C for iOS.

The environment includes Phonegap/Cordova, which allows the apps to access the mobile device’s hardware (such as camera, accelerometer, etc) and its software (such as contacts, file system, etc).

The environment includes a graphical application for the design of GUIs, which, unsurprisingly is called “App Designer”. When a new project is started with App Designer, the user is given the choice of one of four frameworks (App Framework, Bootstrap, jQuery Mobile, Topcoat) for the GUI elements you wish to use.

The environment is well presented with a good help, including videos and forums. The Intel XDK is obviously being actively developed by Intel, as can be seen from the forums. The Intel developers themselves often answer the questions on the forums.

If you would like me to develop an application or other technical projects, you can contact me.


Canny Compare – Find Booking Information for Hotels, Guest Houses and Rentals

Software Consultant, Real-Time Embedded, Test, Quality Assurance, DO178

Software Consultant, real-time embedded software (also MISRA, “DO-178B”)

I am a software consultant, currently working from my office in France.

I offer consulting services in the areas of software requirements, software design, programming, testing, quality assurance, validation, documentation and translation.

My experience is mainly in the area of technical software, but I offer my services for all types of software.

My experience has been in avionics (military upgrade programmes for EADS), communication systems (first at Racal and later at Rohde and Schwarz in Munich).

I worked in several areas at Siemens in Munich, including an air traffic control system, vehicle navigation using GPS, network systems where I worked on an ATM-Switch, in particular the integration of the pSOS real-time operating system.

Recently I worked at MTU Aero Engines on a project to test the software of the engines of the A400M military aircraft. This involved unit testing of the software to “DO-178B” Level-A.

Have experience with many different tools for software development. In the area of software requirements this is mainly DOORS, a requirements tool from IBM.

In the area of software design and architecture I have experience with the UML tools Enterprise Architect, Rational Rose and Rhapsody.

For software development I have experience with Microsoft Visual Studio, Eclipse, Green Hills Multi and others.

I also have a lot of experience of debugging, both on host computers and with the Lauterbach “trace-32” emulator.

I have experience with “DO-178” (also written DO178 or DO178B). This is an important specification for the procedure of developing software for airborne systems. It is also applicable to many other military systems.

I have used tools for software test and quality assurance. These tools include the tools from LDRA and VectorCast. I have used these tools for testing according to “DO-178B” (DO178B).

There is now a new version of the “DO178” specification which is “DO178C”. This DO178C was introduced recently and is a long overdue update to DO178B.

Have also been involved with traceability for “DO-178B”. This involves tracing of requirements to code, to tests, to design, etc.

I have experience of software quality assurance for DO178B. This also involved using the tools from LDRA. I also have quality assurance (QA) experience using tools such as PC-Lint.

I also have a lot of experience with technical documentation, ranging from writing software requirements to test procedures. I can also offer my services for translation of technical documents from German into English.

I lived in Germany for 24 years (and I miss living there!).

I offer contract software services, mainly from my home office with occasional visits to the customer. If you are interested, please use the contact form.







Phonegap – develop cross platform mobile apps the easy way

I had been investigating how to develop software for mobile applications. I took a look at the development environment XCODE and Objective-C for Apple (iOS) devices.

At first I thought that developing code in Objective-C should be easy, because my programming background is in C/C++.  But on closer inspection this turned out not to be the case. Objective-C is significantly different to C and developing applications using it involves a steep learning curve.

There is no point in developing an application for the iPhone or iPad if you don’t put it in the Apple App Store. The process for getting an application accepted by Apple is not so easy.

What would happen if you spent months learning Objective-C and developing an application and then Apple reject your application to have the app put in the App store?

In that case you would be really up the creek without a paddle, because you would have nothing that you could reuse. The only option would be to throw it all away.

There is an alternative to using XCODE and Objective-C and it’s called Phonegap.

Wait, things get even better. Phonegap allows you to create apps for all of the popular mobile platforms including iOS and Android and the less popular platforms such as Blackberry and Windows Phone.

There are even more positive things. Phonegap is completely free and is relatively easy to use because it allows you to program with the same technologies used for web site development. These technologies are HTML, CSS and Javascript.

It gets even better: because you are using these technologies, all of the plug-ins which are available for website development are immediately available for your mobile application.

This means that software such as jQuery, jQuery Mobile, Moo Tools, Dojo, Prototype, YUI, etc are immediately available for use in your application.

Phonegap is available for download at

Of course, if you want to develop mobile applications for iOS, you still need a MAC and XCODE, but the nut is now easier to crack.

Applications developed with Phonegap are accepted by Apple in their review of applications for the App Store. It’s possible that they could change this, but I think that it’s unlikely.

The disadvantages of Phonegap. Not many, but your application will probably run a bit slower than a native application, so it’s probably not the direction to take to develop games apps, but apart from that it seems like a great solution.

If you develop an application with Phonegap and it doesn’t get accepted into the Apple App Store, it’s not the end of the world, because the same code can be used for Android and other devices and with different CSS styling it can be used as a web page.

Note also that HTML5 is the norm if you are taking this direction, so you have to be careful if you want to write code that works both on mobile devices and websites which could be accessed by those using older browsers which do not support HTML5.

Phonegap makes it easy to access the mobile device’s lower level features (camera, accelerometer, file system, network, etc) in an easy an generic way by calls to Javascript functions.

If you would like me to develop a Phonegap application for you, I would be pleased to hear from you.





Microsoft Expression Web 4 is now free

The application Microsoft Expression Web 4 is now available as a free download.

Download Expression Web 4

I only realized this when I was recently googling around for a suitable IDE for doing some web development. I had looked at a number of products, but hadn’t found any of them really suitable.

I tried out Aptana Studio which is an Eclipse based IDE. I don’t like Eclipse much anyway, although I know several programmers who think it’s great. Aptana doesn’t seem to offer any real advantages over using Eclipse with the plugins for web development.

I also had a look at NetBeans which seems a good environment for the serious Java programmer. But, although I like Java, I’m going to do web development for the traditional environment using JavaScript and PHP.

One of my favourite IDEs for web development is PhpDesigner which I bought a while ago. Although it’s called PhpDesigner it’s not just for development of PHP code, so its name is a bit unfortunate, but it’s a great application. It’s not free but it’s low price.

Most web development professionals use Adobe Dreamweaver, but that’s rather expensive just for doing a bit of web development.

JavaScript libraries

When using Javascript there are several libraries available, so that you don’t have to start programming from scratch.

The most popular of these is jQuery. I have also been taking a look at a library called Dojo, which seems good and is well documented. However, it’s almost essential these days that the IDE supports automated code completion (intellisense) and I tried to add this to Aptana studio, but it was out of date. Expression Web supports jQuery intellisense, but not Dojo intellisense. I tried jQuery intellisense in Expression Web and it worked straight away, so that’s the environment I’m going to use.

If you are interested in reading more, refer to my main page at





Why you should subcontract more software development

Most companies develop their software in-house using a team of engineers. Your company should probably subcontract more of its development work.

Many managers like it that way; they can see whether the team members are working and they like the fact that their colleagues can see that the manager is responsible for a large team.

However, it’s often not an efficient way to work. The teams are often made to work in an open plan office (or cubicles in America) where everyone bothers everyone else, with conversations, telephone calls, meetings, etc.

It doesn’t have to be this way. Some of the work can be sub-contracted to engineers such as myself, working at their own premises. The contract engineer can then get on with the work each day, with no travelling time to work and few disturbances. Of course, this means that the work is judged by results, not by the amount of time, like a team member in the office.

The two major problems with software development projects are that they are often over budget and are delivered late. Large companies often accept this situation – but there are alternatives. If some of the work is sub-contracted, it’s possible to specify a fixed delivery date for each work package. The company also has more control over the costs.

There are a few preconditions for successful subcontracting:

  • has to be a certain level of trust between the contractor and the company
  • it has to be the sort of work which can be performed externally
  • it can’t be classified (secret) development
  • the manager has to be prepared to write a statement of work
  • the contractor has to do the work
  • the company has to pay on time

Visit my site at:

Why software development projects go wrong

Why software development projects go wrong

There are basically three types of software development projects:

  • those which are a success
  • those which struggle, but eventually come to a successful conclusion
  • those which fail

This article considers some of the factors which determine where projects go wrong.

In my experience, projects often go wrong right from the very beginning. It’s rarely caused by lack of skills. Most software development teams contain highly qualified, intelligent people, but things still sometimes go drastically wrong. Let’s consider why this could be.

Poor requirements

This is probably the major reason why projects go wrong. If the top-level requirements are not correct, it’s almost impossible for a project to succeed. In some projects, it’s fairly easy to determine the requirements. In others, especially projects which are particularly innovative, in can be very difficult. There is a lot of skill required in writing good software requirements.

Some reasons why the requirements are sometimes poor are described below.

Not considering the needs of all stakeholders

The stakeholders are all the people who will have contact with the product in some way. It’s easy to completely forget some stakeholders. For example, the people who are going to maintain the product are stakeholders, so their needs should be considered from the very start. It’s necessary to get the stakeholders to state their needs themselves. It’s not sufficient that the project members or team leader attempts to guess the needs of the stakeholders, because they almost certainly don’t have the specific knowledge of each stakeholder.

Gold plating – over engineering – adding too many features

It’s a tendency of many engineers (perhaps including myself in the past) to add too many features to the product. Most engineers want he customer to be happy with the final product and it is often assumed that this means adding as many features as possible. This is often not the case – the customer would prefer something simpler, which is easier to use. Occasionally, the customer himself is to blame for requesting too many features. I’ve experienced this in cases where the customer is requesting technical bids from several companies – they keep asking the supplier to add new features, without increasing the price, with the threat that the competition will win the tender if the extra features are not added.

Other reasons are listed below

  • Requirements which do not correspond to features the customer wants
  • Making the requirements too detailed
  • Mixing what should be separate requirements into one requirement
  • Mixing requirement levels, e.g. mixing up high and low-level
  • Missing requirements
  • Requirements which are not implementable
  • Requirements which are not testable
  • Teams which are too large
  • Giving programmers the task of writing requirements
  • Adding more people to a project which is already late
  • Not giving enough responsibility to individuals
  • Performing “big bang” integration
  • Not testing enough
  • Unrealistic time scales
  • Not taking the deadlines seriously