Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘Apple

Performance Testing in Swift

with one comment

Introduction

A couple of blog posts ago I covered writing my first Swift program for iOS so that I could draw a Koch Snowflake on an iPad or an iPhone. Then last time I covered adding unit tests to that project. This time I’m going to add performance tests.

In the process of adding performance tests, I had to refactor the test project and we’ll also look at why that was and how it makes it better going forwards as more tests are added. I’ll also mention a few things that should be done if this project gets a bit bigger.

I put an updated version of the Koch Snowflake project on Google Drive here.

Performance Tests in XCode

Of course you could instrument your program yourself and perhaps write the performance results out to a file or something, for that matter you can drill down into the Swift test case class and have a look at their implementation. But XCode gives you a bit of support so you generally don’t need to. If you add self.measureBlock {} around code in a unit test then the time taken of the code inside the measureBlock will be recorded and reported inside XCode as shown in the following screenshot.

Screen Shot 2016-06-01 at 3.32.53 PM

Actually it does a bit more than that. When you add measureBlock to a unit test, then when you run that unit test, it won’t just be run once, but will be run ten times, so that the average and standard deviation will be recorded. Due to this it is crucial that any performance tests are idempotent. You can also set a baseline, so the percentage deviation from the baseline gets recorded. This is shown in the following screenshot that is a drill down from the previous screen shot.

Screen Shot 2016-06-01 at 3.33.04 PM

Hence XCode gives a fairly painless way to add some performance metrics to your unit tests.

Test Case Organization

Generally, you want your unit tests to run against every build or your product, so you want then to run in a second or two. Once the performance tests get longer, you will probably want to separate them off into a separate test group and then run this test group perhaps once over night. I haven’t done that, but if the project gets any bigger then I will.

In fact, the test framework inside XCode is quite good for performing integration tests (which would run against real databases and real servers), but since these may require some setup or be quite time consuming, you could also set these to run once per night.

There is also a separate framework for UI testing, which again is too slow to run against every build, but makes sense to run every night.

Refactoring the Unit Tests

For the performance test, I wanted to record the time it takes to draw the Koch Snowflake at various fractal levels. To do this I wanted to do something like the previous testInitialViewController routine, but it contained a lot of setup code. So first the unit test framework includes setUp function that is called before the unit tests are run and a tearDown routine that is called after then finished. So I moved the creating of the graphic context to this routine, along with the code to get the view controller started. Then it was fairly easy to add tests for fractal levels 3 through 7.

Last time I just had 2 unit tests, each was quite large and performed multiple things. Now we’ve split things up into more unit tests that do less, which is generally a better practice. This was actually forced on me since you can only have one measureBlock in any unit test, so I couldn’t performance test the different fractal levels in the same unit test (at least with separate timings). Really I should break up the turtle graphics tests into multiple unit tests, perhaps next time.

The reason I went all the way to fractal level 7, was that the performance reports in XCode are often 2 decimal places (or sometimes 3 decimal places) on the number of seconds the test takes. For my fractal, the drawing is quite quick so I needed go this high to get some longer test times recorded (kind of a good problem to have). I could have gone higher or put them in an additional loop, but thought this was sufficient.

//
//  KochSnowFlakeTests.swift
//  KochSnowFlakeTests
//
//  Created by Stephen Smith on 2016-05-13.
//  Copyright © 2016 Stephen Smith. All rights reserved.
//

import XCTest

@testable import KochSnowFlake

class KochSnowFlakeTests: XCTestCase {
    var storyboard:UIStoryboard!
    var viewController:ViewController!

    override func setUp() {
        super.setUp()
        // Put setup code here. This method is called before the invocation of each test method in the class.

        UIGraphicsBeginImageContextWithOptions(CGSize(width: 50, height: 50), false, 20);

        self.storyboard = UIStoryboard(name: "Main", bundle: nil)

        self.viewController = storyboard.instantiateInitialViewController() as! ViewController
        _ = viewController.view
        viewController.viewDidLoad()
    }

    override func tearDown() {
        // Put teardown code here. This method is called after the invocation of each test method in the class.
        UIGraphicsEndImageContext();
        super.tearDown()
    }

    func testTurtleGraphics() {
        // Test the turtle graphics library.
        // Note we need a valid graphics context to do this.

        let context = UIGraphicsGetCurrentContext();
        let tg = TurtleGraphics(inContext: context!);
        XCTAssert(tg.x == 50, "Initial X value should be 50");
        XCTAssertEqual(tg.y, 150, "Initial Y value should be 150");
        XCTAssertEqual(tg.angle, 0, "Initial angle should be 0");
        tg.move(10);
        XCTAssertEqual(tg.x, 60, "X should be incremented to 60");
        XCTAssertEqual(tg.y, 150, "Initial Y value should be 150");
        XCTAssertEqual(tg.angle, 0, "Initial angle should be 0");
        tg.turn(90);
        tg.move(10);
        XCTAssertEqualWithAccuracy(tg.x, 60, accuracy: 0.0001, "X should be o 60");
        XCTAssertEqualWithAccuracy(tg.y, 160, accuracy: 0.0001, "Initial Y value should be 160");
        XCTAssertEqual(tg.angle, 90, "Initial angle should be 90");
        tg.turn(-45);
        tg.move(10);
        XCTAssertEqualWithAccuracy(tg.x, 60 + 10 * sqrt(2) / 2, accuracy: 0.0001, "X should be o 60+10*sqrt(2)/2");
        XCTAssertEqualWithAccuracy(tg.y, 160 + 10 * sqrt(2) / 2, accuracy: 0.0001, "Initial Y value should be 160+10*sqrt(2)/2");
        XCTAssertEqual(tg.angle, 45, "Initial angle should be 45");
    }

    func testPerformanceLevel3()
    {
        // Test that the storyboard is connected to the view controller and
        // that we can create and use the view and controls.

        viewController.fractalLevelTextField.text = "3"
        self.measureBlock {
            self.viewController.textChangeNot("dummy")
            self.viewController.fracView.drawRect(CGRect(x:0, y:0, width: 50, height: 50))
        }

        XCTAssertTrue(viewController.fracView.level == 3)
        // This next line is just to get 100% code coverage.
        viewController.didReceiveMemoryWarning()
    }

    func testPerformanceLevel4() {
        // This is an example of a performance test case.
        viewController.fractalLevelTextField.text = "4"
        self.measureBlock {
            self.viewController.textChangeNot("dummy")
            self.viewController.fracView.drawRect(CGRect(x:0, y:0, width: 50, height: 50))
        }
    }

    func testPerformanceLevel5() {
        // This is an example of a performance test case.
        viewController.fractalLevelTextField.text = "5"
        self.measureBlock {
            self.viewController.textChangeNot("dummy")
            self.viewController.fracView.drawRect(CGRect(x:0, y:0, width: 50, height: 50))
        }
    }

    func testPerformanceLevel6() {
        // This is an example of a performance test case.
        viewController.fractalLevelTextField.text = "6"
        self.measureBlock {
            self.viewController.textChangeNot("dummy")
            self.viewController.fracView.drawRect(CGRect(x:0, y:0, width: 50, height: 50))
        }
    }

    func testPerformanceLevel7() {
        // This is an example of a performance test case.
        viewController.fractalLevelTextField.text = "7"
        self.measureBlock {
            self.viewController.textChangeNot("dummy")
            self.viewController.fracView.drawRect(CGRect(x:0, y:0, width: 50, height: 50))
        }
    }
}

 

Summary

I found adding performance tests to my fractal iOS application quite easy. XCode gives quite nice support to perform these tests painlessly, hopefully motivating more programmers to include them.

At this point I’m not going to optimize the code as it is running fast enough. But if I ever take on drawing more sophisticated or complicated fractals, then drawing speed becomes really important. Some things to consider would be how efficient in the recursive algorithm used, and whether I’m efficiently using floating point and integer arithmetic (or are there unnecessary conversions or perhaps too much precision being used).

Written by smist08

June 7, 2016 at 2:15 am

Adding Unit Tests to My Swift Application

with 3 comments

Introduction

Last time I blogged on creating my first Swift application that would display a Koch Snowflake fractal on an iPad or and iPhone. This time I’m going to look at adding some unit tests to that program to see how that works in XCode and Swift. It appears that Apple has built some nice unit testing support into XCode so doing this was actually quite easy.

I put the Koch Snowflake Swift project on Google Drive here. Feel free to download it and play with it. Refer to this project or the previous blog post for the code we are actually testing in this article.

Test Driven Development

If I was following proper Test Driven Development (TDD) then I should have written the unit tests before I wrote the actual code. This would force me to think about the design of the APIs and the testability of the program first, and then would force quick cycles of writing tests, writing code so the tests pass and then refactoring the code to make it all better. However, in this case I ported an old Objective-C program to Swift to play with Swift and now that I’m getting more familiar with Swift, I’m finally looking at the unit testing framework. So what I’m doing is perhaps not a good practice, but adding the unit tests later is better than not adding them at all.

The danger I could have run into is that the program could have turned out to be quite hard to test due to perhaps some bad design decisions and then required quite a bit of refactoring to make it properly unit testable. Fortunately, in this case the program is fairly simple and adding a good set of unit tests was fairly straight forward and didn’t require any changes to the program.

One criticism of TDD is that there is a perception that it interferes with good program design and architecture. This isn’t true. The misconception is that the first tests need to be truly useful, whereas the first tests usually just call the API and set how the API to the various classes is used. The classes are just skeletons and the unit tests pass as long as everything compiles. Getting everything to compile is the first step and thinking about all the APIs before writing the real code that does stuff is the first step to getting a good modular design.

Apple has adopted TDD for a lot of their own projects, for instance their Core Data module was developed this way. Since Apple developers use XCode and now many are using TDD this means that a lot of good support for TDD is being baked into XCode. It also means that newer Apple technologies are much easier to use in a TDD environment than some of their older ones. But even for the older ones there are lots of clever examples on the web of how to work around the various challenges they introduce.

Screen Shot 2016-05-31 at 10.41.21 AM

Testing Turtle Graphics

When you create a project with XCode you have the option to include unit tests (which I did) and this gives you a test project that you can run with some dummy tests in it. So I figured first let’s add some unit tests to my TurtleGraphics class. This is pretty simple you move the turtle and turn the turtle and it leaves a trail behind it. For drawing fractals turtle graphics makes the algorithms very easy since it fits in well with the recursive algorithms typically used.

The turtle graphics class uses Apple’s Quartz2D library to draw on the screen. Perhaps the first possible design flaw is that when I instantiate the turtle graphics library I need to pass its constructor a valid graphics context. The underlying Quartz2D library routines certainly don’t like this being nil and throw an exception if you try that (ie my first try). So I thought I would just create a graphic context object but after battling with Swift a bit, I found I couldn’t do this because the underlying class doesn’t have any constructors. This also prevented me from mocking the class (at least using the real class and replacing just a few methods). This is because Apple wants to make sure you get a valid graphics context from one of their factory methods. If you are actually in the drawing routine this is passed to you by the system, but as a unit test, we aren’t running in a screen drawing context. Fortunately there is a way to get a graphics context to draw on an in-memory image file, so I used that.

To solve this, I could have refactored the drawing routines into another class and had this class accept nil for the graphics context and just return when this happens. This is basically just making a new class that pass through to the real class when the program runs, or acts as a stub class when running unit tests. I didn’t like this so much since then if the real program did pass nil, it wouldn’t get caught and the program just wouldn’t work properly. Even though I’m not testing the actual placement of pixels on the screen, it makes me feel good to know the actual real drawing routines are being exercised during the unit tests, so if they do get an invalid argument or something the problem will be caught.

The unit test framework lets unit tests get at variables in a class to help you set up the asserts to prove correctness (you import the module via @testable import KochSnowFlake rather than just import), so to test it, I just did some simple move and turns and then tested that the internal state of the turtle graphics module was correct. Notice when I turned 45 degrees I used trigonometry to calculate the new position, for testing its usually good to test against a calculation, rather than running the program to see what the value is and then using that. Notice the use of XCTAssertEqualWithAccuracy, since we are using floating point arithmetic, rounding errors creep in, so the equals will never be exact. You can configure XCode to either stop on each error or run to completion just recording all the errors, its up to you. For this I usually just stopped on an error and then fixed the problem.

func testTurtleGraphics() {
 // Test the turtle graphics library.
 // Note we need a valid graphics context to do this.
 
 UIGraphicsBeginImageContextWithOptions(CGSize(width: 50, height: 50), false, 20);
 let context = UIGraphicsGetCurrentContext();
 let tg = TurtleGraphics(inContext: context!);
 XCTAssert(tg.x == 50, "Initial X value should be 50");
 XCTAssertEqual(tg.y, 150, "Initial Y value should be 150");
 XCTAssertEqual(tg.angle, 0, "Initial angle should be 0");
 tg.move(10);
 XCTAssertEqual(tg.x, 60, "X should be incremented to 60");
 XCTAssertEqual(tg.y, 150, "Initial Y value should be 150");
 XCTAssertEqual(tg.angle, 0, "Initial angle should be 0");
 tg.turn(90);
 tg.move(10);
 XCTAssertEqualWithAccuracy(tg.x, 60, accuracy: 0.0001, "X should be o 60");
 XCTAssertEqualWithAccuracy(tg.y, 160, accuracy: 0.0001, "Initial Y value should be 160");
 XCTAssertEqual(tg.angle, 90, "Initial angle should be 90");
 tg.turn(-45);
 tg.move(10);
 XCTAssertEqualWithAccuracy(tg.x, 60 + 10 * sqrt(2) / 2, accuracy: 0.0001, "X should be o 60+10*sqrt(2)/2");
 XCTAssertEqualWithAccuracy(tg.y, 160 + 10 * sqrt(2) / 2, accuracy: 0.0001, "Initial Y value should be 160+10*sqrt(2)/2");
 XCTAssertEqual(tg.angle, 45, "Initial angle should be 45");
 
 UIGraphicsEndImageContext();
 
 }

Testing the View Controller

Now let’s test things at a higher level. Generally, we don’t do UI testing in unit tests, but we can do some basic tests to ensure everything is created properly and is more or less hooked up correctly. XCode does have built in support for UI testing and perhaps we’ll have a look at that in a later blog post. In this case we are going to create the storyboard (where the UI is defined) and from that instantiate our View Controller. Then we do a dummy access for the view to get the delay loaded elements loaded and start calling the View Controllers methods starting with viewDidLoad(). For our test we set the fractal level to 3 in the text box and then call the notification methods and see if it then updated properly in our View.

func testInitialViewController()
 {
 // Test that the storyboard is connected to the view controller and
 // that we can create and use the view and controls.
 
 let storyboard = UIStoryboard(name: "Main", bundle: nil)
 
 let viewController = storyboard.instantiateInitialViewController() as! ViewController
 _ = viewController.view
 viewController.viewDidLoad()
 
 viewController.fractalLevelTextField.text = "3"
 viewController.textChangeNot("dummy")
 XCTAssertTrue(viewController.fracView.level == 3)
 // This next line is just to get 100% code coverage.
 viewController.didReceiveMemoryWarning()
 }

Test Coverage

The big questions that is usually asked about unit tests, is how much code to they cover (or exercise). XCode can give this report which you can see in the screenshot:

Screen Shot 2016-05-31 at 10.42.53 AM

Amazingly we nearly get 100% coverage. The only module with poor coverage is AppDelegate.swift which is code generated by XCode and then I never use it. The reason we get such good coverage is that this is a fairly simple program and it draws the snowflake when it initializes. But the key point here is that I am testing a lot of things fairly easily and fairly quickly. It tests the functionality of the turtle graphics library and it tests that the UI is all hooked up properly and working.

A true TDD adherent would delete all the code in AppDelegate.swift, since code shouldn’t be written unless it is to make a unit test pass. But I tend to give an exception to code generated by the tools like XCode, to me this code is Apple’s responsibility and not mine. Plus, if I ever do add code to this class then I would need to start adding unit tests and take it a bit more seriously.

Harder Cases

This program is pretty simple, so I didn’t need to do anything too fancy to unit test it. This is mainly because there is no database access, no hardware access (beyond drawing and one text field) and no communication with a server. If you add these then you would need to add mock, stub and/or fake classes to assist in testing. You want your unit tests to be fast and run on every compile. You don’t want to require databases be setup or that servers are running somewhere in a certain state. Fortunately, Swift is a very powerful object oriented language and creating all of these is fairly easy (extensions are especially helpful). The main problems you run into are in using the Objective-C libraries like UIKit, but again you aren’t the first to run into these and there are tons of sample code, blogs and lessons on how to deal with these.

Another tricky area is with asynchronous calls. When you make a call to the server, the response will be returned asynchronously. What this means that as soon as your unit test sends the server request, it will complete. Since the asynchronous request comes back on a separate thread later, you need to ensure your main thread doesn’t just end and you wait for the results, or the tests in the callback will never be executed. There are lots of examples on how to do this, but it definitely adds some complexity to your tests.

Continuous Build Server

If you have a team, then you will probably want a continuous build server that monitors your source code repository (probably Git) and then does a build and test each time something new is checked in. Apple has an XCode Server that you can purchase if you are a registered developer. Or you could use the Jenkins Build Server which is open source and free. Jenkins also has an XCode plugin to make life a bit easier. Though XCode is quite good at letting you control it from the command line. This way you can be notified as soon as something breaks and ensure problems get fixed right when they are caused, which is the easiest time to fix them.

Summary

That turned out to be quite a long posting on unit tests. XCode and Swift have a very powerful and easy to work with unit testing framework built in. If you are developing a new application, certainly consider using TDD for your development methodology. If you are porting or doing a new version of an app, then certainly try adding some unit tests. Unit tests will help you greatly over the lifetime of your product, making it more reliable, bug free and easier to maintain.

Written by smist08

May 31, 2016 at 8:17 pm

Wearable Devices and Sports

with 2 comments

Introduction

I happen to be on holiday this week on the Sunshine Coast (in BC, not Aus). I’ve doing a lot of running and cycling so I thought I would blog a bit on how new devices like GPS watches, step counters and Phone Apps are helping track sports. I have a Garmin GPS watch and an iPhone 4s. So what can I do with these and what is the potential as these devices improve?

The GCC

This year Sage is again participating in the GCC (the Get the World Moving Coporate Challenge). Basically you form teams of 7 co-workers and each of you wears a pedometer for the duration of the event. You then enter your steps, meters swam and km cycled into the website each day.

You then are tracked as you walk around the world and compete with other teams, either generally, within your company or within your area. The website is quite good, provides lots of useful information and tips on how to improve your health and fitness levels.

gcc

To do this tracking just requires a pedometer and their website. No other high tech gadgetry required. It will be interesting to see if more low tech solutions like this one (though the web site and pedometer are both fairly sophisticated) or solutions requiring more hardware like smart watches and extra devices will become the norm.

Garmin GPS Watches

There has been a lot of talk about Apple, Google and Microsoft coming out with smart watches this fall. Further several manufacturers like Samsung already have devices on the market. Then there have been a number of failures like Nike’s entry in this field. I think a lot of these companies have been looking at the success Garmin has had here. Garmin has transformed itself from manufacturing standalone GPS’s (which have now largely been replaced by functionality built into every phone) to making quite useful GPS sports watches.

The watches tend to be a bit bigger than a normal watch but still not uncomfortable to wear when running. Perhaps not the greatest fashion accessory, they are really quite useful. Besides recording your speed, location, distance and elevation in great detail, they also have heart rate monitors to give you quite a bit of information. Then they have a web site that is no extra charge to store and share all your routes and runs. For instance here.

garminconnn

The info is collected by the watch and then you upload it to your PC when you get back and then from there to their web site.

Generally this then gives you all sorts of metrics where you can see how you did, your pace every kilometer, how you did on uphill’s and downhill’s, etc. You can then track your progress and have a good idea of how you are doing.

Runtastic

There are quite a few fitness tracking apps for the iPhone. I just chose Runtastic because I liked the dashboard display in their app store ad. But otherwise it’s been fine, except for a bit too much promotion for the pro version. There are ads in the app and web site, but at a reasonable level, I think for the service you are getting.

There are a lot of attachments available to mount your phone on your bike; however, I’ve found that doing this really drains your phone’s battery quickly (i.e. in about an hour) and so isn’t really all that practical.

Runtastic Road Bike

More typically it’s better to leave the display off since then it doesn’t seem to use that much battery. Also if you stop to take pictures or something, make sure you switch back to the app first. The iPhone doesn’t have good multi-tasking, so unless the app is the active one, it probably won’t be doing anything.

Once you are finished your ride, the app uploads the data to the website and allows you to share what you are doing via social media (as any of my Facebook friends know). For instance this one here.

runtastic2

Like the Garmin website, this one gives you lots of information and makes it easy to track your progress as you try to improve your sport.

The Future

I think that companies like Apple are looking at this market and hope it is a bit like the early MP3 music player market was. Then a company like Apple could come along, redefine the market, make it dead simple and create a much larger market than what the early technology startups could achieve.

Whether Apple can repeat the iPod success in this market is yet to be seen. And they are certainly going to face a lot of competition as Microsoft and Google are hoping they can do the same thing.

Garmin type devices have better battery life and better durability than phones. However phones have better apps and greatly benefit from continuous Internet connectivity. So what are successful future devices going to need? From my perspective they will need:

  • Better battery life. Operating with only a couple of hour’s batter life is insufficient. This should really be a week.
  • Better durability. They can’t just fry when they get a little wet in the rain. Cycling and running are outdoor sports performed in any weather. Athletes don’t want extra clothing or gear to keep their watch dry. Further it would be great if these work for swimming. After all there are already a great many regularly triathlon watches that work great while swimming.
  • Intelligent support for more sports. Useful metrics gathered while golfing for instance. What about soccer, football or hockey?
  • Do not require a separate data plan. If you have to pay $50 per month to a cell phone provider then they are dead in the water.

Another area where there is great research going on is developing more sensors that measure things like blood glucose levels, blood pressure, etc. It will be interesting to see how tracking these additional metrics can help athletes.

There are also appearing apps that intelligently use the Phone’s camera to do things like analyze golf swings and tennis strokes. As these improve we may reach the stage where casual players can get real professional coaching and feedback right from their phone.

On the flip side, there is a lot of concern about the possible privacy implications of these devices. For instance if I record heart rate monitor information and it starts detecting abnormal behavior, could an insurance company find out and cancel my insurance? Could it be used in other adverse ways? Generally this sort of medical information is very protected. Will these devices, services and web sites offer the necessary levels of personal privacy protection? Will I find out I have a heart condition because suddenly I start receiving ads for defibulators and pace-makers? There is certainly a lot of concern about this out there and there have been many Science Fiction stories about the possible abuses. Hopefully these won’t all turn out to be prophetic.

Summary

By Christmas shopping season we are going to be inundated by new intelligent watches and other form factors that can help us track and improve our fitness levels. They will track all sorts of metrics for us, provide feedback and even professional levels of coaching. It will be interesting to see if this sparks a greater level of interest in fitness and sports. Maybe these will even help with the current epidemic obesity levels in our society.

Written by smist08

July 5, 2014 at 4:17 pm

Apple Mobile Trends

with 2 comments

Introduction

With Apple’s WWDC conference just wrapping up, I thought it might be a good time to meditate on a few of the current trends in the mobile world. I think the patent wars are sorting themselves out as Google and Apple settle and we are seeing a lot more competitive copying. Apple added a lot of features that competitors have had for a while as well as adding a few innovations unique to Apple.

The competitive fervor being shown in both the Google and Apple mobile camps is impressive and making it very hard for any other system to keep up.

ios8_large

Cloud Storage

Apple has had the iCloud for a while now, but with this version we are really seeing Apple leverage this. When Google introduced the Chromebook they used this video to show the power of keeping things in the Web. This idea has been copied somewhat by Microsoft. But now Apple has taken this to the next level by allowing you to continue from device to device seamlessly, so you can easily start an e-mail on your phone and then continue working on it on your MacBook. No having to e-mail things to yourself, it all just seamlessly works.

Apple also copied some ideas from Google Drive and DropBox to allow copying files across non-Apple devices like Windows as well as sharing documents between applications. So now this is all a bit more seamless. It’s amazing how much free cloud storage you can get by having Google, Microsoft, Apple and Dropbox accounts.

Generally this is just the beginning as companies figure out neat things they can do when your data is in the cloud. If you are worried about privacy or the NSA reading your documents, you might try a different solution, but for many things the convenience of this outweighs the worries. Perhaps a bigger worry than the FBI or NSA is how advertisers will be allowed to use all this data to target you. Apple has added some features to really enable mobile advertising, whether these become too intrusive and annoying has yet to be seen.

Copying is the Best Compliment

Apple has also copied quite a few ideas from Google, Blackberry and Microsoft into the new iOS. There is a lot more use of transparency (like introduced in Windows Vista). There is now a customizable and predictive keyboard adding ideas from Blackberry and Microsoft. Keyboard entry has been one of Apple’s weaknesses that it is trying to address. Similarly the drive option in the iCloud is rather late to the game.

Apps versus the Web

There is a continuing battle between native applications and web applications for accessing web sites. People often complain that the native mobile application only gives them a subset of what is available on the full web site, but then on the other hand the consensus is that the native mobile apps give a much better experience.

True web applications give a unified experience across all devices and give the same functionality and the same interaction models. This is also easier for developers since you only need to develop once.

However Apple is having a lot of success with apps. Generally people seem to find things easier in the Apple App store than in browsing and bookmarking the web. Apple claims that over half of mobile Internet traffic is through iOS apps now (but I’m not sure if this is skewed by streaming video apps like Netflix that use a disproportionate amount of bandwidth).

Yet another Programming Language

Apple also unveiled a new programming language Swift for mobile development. One of the problems with C, C++ and Objective C programming is the use of pointers which tends to make programming harder than it needs to be. Java was an alternative object oriented extension to C with no pointers, then C# came along copying much of Java. Generally most scripting languages like Basic, JavaScript, Python, etc. have never had pointers.

Rather than go down the road of Java and C#, Swift has tried to incorporate the ease of use of scripting languages, but still give you full control over the iOS API. How this all works out is yet to be seen, but it will be interesting if it makes iPhones and iPads really easy to program similar to the early PCs back in the Basic days.

swift-screenshot

The Internet of Things

Apple introduced two new initiatives, their Health Kit and Home Kit. Health kit is mostly to encourage adding medical sensing devices to your iPhone, whereas Home Kit is to extend iOS into devices around the home and to control them all from your iPhone.

The Health Kit is designed to centralize all your health related information in one central place. There is getting to be quite a catalog of sensors and apps to continuously track your location, speed, heart rate, pulse, blood pressure, etc. If you are an athlete, this is great information on your fitness level and how you are doing. Garmin really pioneered this with their GPS watches with attached heart rate monitors. I have a Garmin watch and it provides a tremendous amount of information when I run or cycle. I don’t think this is much use for the iPhone, which I always leave behind since I don’t want to risk it getting wet, but this might really take off if Apple really releases a smart watch this fall like all the rumors say.

Home Kit is a bit of reaction to Google buying Nest, the intelligent thermostat. Basically you can control all your household items from your phone, so you can warm up the house as you are driving home, or turn all the lights on and off remotely. We have a cottage with in-floor heating, it would be nice if we could remotely tell the house to start heating up in the winter a few hours before we arrive, right now it’s a bit cold when we first get there and turn on the heat. However with zoned heating we would need four thermostats and at $250 each, this is rather excessively expensive. I think the price of these devices has to come down quite a bit to create some real adoption.

There is a lot of concern about having all of these hacked and interfered with, but if they get the security and privacy correct, then these are really handy things to have.

Summary

Apple has introduced some quite intriguing new directions. Can Swift become the Basic programming languages for mobile devices? Will Health Kit and Home Kit usher in a wave of new wonderful intelligent devices? Will all the new refinements in iOS really help users have an even better mobile experience? Will native apps continue to displace web sites, or will web sites re-emerge as the dominant on-line experience? Lots of questions to be answered over the next few months, but it should be fun playing with tall these new toys.

Written by smist08

June 7, 2014 at 4:27 pm

Data Entry Through the Ages

with 4 comments

Introduction

Last weekend I visited my parents in Victoria and my mom mentioned that she had finally used up all the computer punch cards I had left her when I graduated U-Vic. She likes them because they are more solid than paper but lighter than cardboard and are ideal for using as shopping lists and such. To have lasted this long shows how many cards I needed to do all my first and second year Computer Science courses back then at U-Vic.

This got me to thinking on how entering data into computers has changed over my career. Data entry is changing at an even faster rate these days, so I thought it might be fun to look back and to look forwards as well.

I’m not sure if this makes me appear very old, or shows how slow educational institutions adopt new technology. Not only was I the last first year computer science class to have to use punch cards, but I was also the last year when you weren’t allowed to use calculators in the Provincial exams and had to use a slide rule.

slideruls

Dec LA36

My first experience of computers was in Computer Science 11 at Oak Bay Secondary in Victoria. The school had a Dec LA36 terminal connected via a 300 baud modem to the PDP-11 at Camosun College.

la36

Basically the terminal printed what you typed and sent it to the computer when you hit enter and then would echo anything sent back. Rather primitive. Certainly was different editing files this way. Back then Basic used line numbers and you edit lines by specifying what you wanted done to a specific line by number.

IBM Punched Cards

Then I went to the University of Victoria, which was a step backwards. Rather than a nice online terminal like the LA36, we had to enter data via punched cards and then receive the output later from a managed line printer.

IBM_card_punch_029

You had to be careful what you typed since each run took quite a bit of time and used up money from your account. You got good at using functions like duplicating cards up to a point and were always very careful not to drop them. Given the nature of the medium, it was surprisingly robust, in that the cards were actually pretty reliable.

Video Terminals

Once I hit third year, we were allowed to use video terminals to do our Computer Science work. Some people were lucky enough to use very compact languages like APL to program. Others of us had to manage rather slow editors using cursor keys. Admittedly a huge improvement over the LA36 or punch cards.

vt100

Personal Computers

For my first Co-op work term, I worked at Island Medical Labs and programmed a Radio Shack TRS-80 computer to do a number of calculations and to print a number of reports for the lab. This was my introduction to personal computing and I was so happy to have a computer all to myself, rather than the time sharing systems I was used to. It had disk drives and a daisy wheel printer. Lots of fun programming in Basic for this.

trs80

After my first co-op work term I used much of my earnings to buy a brand new Apple II+. Since I mostly took Numerical Analysis type CS courses, I was actually able to do quite a few labs off my Apple II+. I had to take a cassette tape downtown to get a print out at a computer store since I didn’t have a printer yet (or a disk drive).

Apple-II

Lisa/Mac

A big innovation came when the Apple Lisa came out and introduced the world to the mouse and the GUI Operating System. This was a huge leap forward. I never owned a Lisa or Mac, but eventually started using Windows, a rather pale copy in those days.

lisamac

Touch

Along the way there were quite a few devices that used touch as an input mechanism. But none of them were popular until the iPhone came along. Like GUIs and the mouse, Apple brought this into the mainstream. I have an iPhone 4s and really love it. Using this device is very easy and once used to it, I don’t miss the keyboard from my previous Blackberry at all.

smokedemo

Voice

Voice input is finally starting to work properly. Tools like Apple’s Siri are actually starting to be useful. I blogged on this previously here. Certainly people are relying on this in their cars to dial phone and to select music. Even to ask Siri trivia questions as you drive along.

scotty

Gesture

Gesture is still fairly controversial. It’s not clear whether Kinect helps or hinders Xbox. People like the concept but are put off by an always on video camera into their living room. We aren’t quite at the level of Minority Report yet, but we are getting there. I’m not sure what this will do to the cube office environment once this goes mainstream.

minreport

VR

Although not really an input device, Virtual Reality and VR Goggles are closely related. In these immersive worlds they combine voice and gesture input with providing an immersive complete visual view. The Oculus Rift was quite popular at CES this year. It will be interesting to see if these can successfully be productized and achieve a mass appeal.

oculus

Glasses

I blogged previously on Google Glasses here. These are fairly controversial. Google is just in the process of releasing these into the mainstream market. It will be interesting to see if they are accepted. They are expensive, and wearers are commonly called glassholes. I’m not sure everyone else likes being filmed all the time, so it will be interesting to see how this evolves.

google-glasses-2

Mind Reading

We are starting to see devices that can interpret and act on the electrical signals generated from the brain. Right now it takes a fair bit of concentration and training to use these, but as these get more refined, how long before we can practically control our computers via thinking? How long before we have a USB port embedding into our neck where we can read USB sticks directly?

mindcontrol

Summary

We’ve come a long way from punched cards to Google Glasses. We’ve adapted input devices from all sorts of innovative techniques from keyboards to mice to touch to voice to gestures and R&D into new techniques is progressing at a breakneck pace. It will be really amazing what comes out over the next few years. Which experimental technologies go mainstream, which mainstream technologies die out?

Written by smist08

January 11, 2014 at 9:14 pm

Google Forks WebKit

with one comment

Introduction

WebKit is the underlying HTML rendering library used primarily by the Apple Safari and Google Chrome browsers. It is used in a lot of other projects like the Blackberry Browser, Opera, Tizen, Kindle and even some Microsoft e-mail clients. Even Nokia was a big WebKit user before switching to Windows Phone. Generally it’s been considered a great success, rallying the web around standards and making life easier for web developers.

webkit

WebKit is a solid open source project with lots of support. This is one reason it’s so successful. Currently in Internet browsers there are three main HTML rendering engines: the Internet Explorer Trident engine, the Mozilla Firefox Gecko engine and then WebKit.

The big news around the Internet on this front recently is that Google is forking WebKit (meaning starting a new open source project based on WebKit) and then taking it in its own direction with a project called Blink. This raises all sorts of questions: like what it means to web developers? What is Google’s real agenda? Will this damage web standards? Will this slow WebKit development? In this blog posting I want to give my perspective on a few of these questions.

History

Actually WebKit was started out of a similar controversy. Back in 2001, Apple forked the KHTML/KJS HTML rendering engine used by the browser that is part of the KDE Linux User Interface system. Basically Apple wanted something better and more tuned for its OS X project. The result was the Safari browser built on the first WebKit HTML engine. At the time no one in the Linux community was happy about this, but in the end looking back, success makes everything all right.

So now that Google is forking WebKit, claiming that it’s for the same reasons that Apple forked KHTML, will history repeat itself and a much better HTML rendering engine will emerge? Or will this just fragment the market into more slightly different HTML rendering engines making life more difficult for web developers?

WebKit’s Mobile Success

In recent years, now that Android and the iPhone have completely taken over the mobile phone market, developing web sites with HTML5 and JavaScript has become much easier. This is because WebKit is used in both of these families of devices. This means to cover 95% of the mobile market you just need to target WebKit. This greatly simplifies development and testing. Further WebKit follows web standards diligently, it keeps up with evolving standards, has great performance and great quality.

I think that WebKit has been a major contributor to the combined success of both Android and the iPhone. You can easily browse most websites from these devices. Plus when Apps incorporate browser controls they are using WebKit.

Further both Apple and Google are contributing actively to WebKit. It’s been an interesting combination of co-operation and competition. When new hardware devices come out, initially it tends only be accessible for Apps. But Google tends to very quickly add JavaScript APIs for the device to WebKit. Then Apple tends to follow suite quite quickly. Further each is driven to keep incorporating the latest version into their devices since they don’t want to let the other get ahead of them.

One of the worries of Google forking WebKit and going its own way is that we will lose the competitive nature of Apple versus Google that has been driving WebKit forwards.

Why Fork?

So why is Google forking WebKit? A lot of opinion on the Internet is that this is a strategy to sabotage Apple. I guess Google could be egomaniacal enough to think that WebKit will fail without them participating. But Apple is such a big company with so much money and talent, I think they can do just fine with WebKit, after all they did start it without Google’s help. Further I suspect the army of independent open source programmers that contribute to WebKit will continue to do so and won’t switch to Blink.

Google’s official reason is that the code in WebKit is getting too burdened with supporting code for Safari, Chrome and all the other various things it does. That if they take WebKit and remove anything that Chrome doesn’t use then they will have a smaller, faster and easier to develop code base. Basically they claim they want to move the HTML engine forwards more tightly coupled with their multi-processor architecture to improve security and performance. That doing this while supporting competing architectures within the same code base is getting harder and harder.

When Apple started WebKit and later when Google joined it, both Google and Apple were primarily worried about Microsoft and wanted to have Browser technology clearly superior to Internet Explorer. Now with their success, Microsoft is now pretty well non-existent in the mobile world. I think as a result Google isn’t feeling threatened by Microsoft anymore and is turning its attention to Apple. Generally relations between the two companies have been getting colder and colder in recent years.

Actually Google currently only uses the HTML and CSS rendering part of WebKit called WebKitCore. They stopped using the JavaScript component JavaScriptCore in favor of their own V8 JavaScript engine. The V8 JavaScript engine has been blowing away the competition in JavaScript benchmarks for some time now. In fact the V8 JavaScript engine is also the heart of Node.js the highly successful JavaScript server side processing framework. I think Google is looking to get the same sort of success out of Blink that they got from V8.

What’s the Problem?

The problem is for developers. Right now developing good web pages that run nicely anywhere means targeting IE, FireFox and WebKit which then covers the main HTML/CSS rendering engines. Unfortunately HTML and CSS are very complicated and quite subtle. Although all adhere to the published web standards, there are differences in interpretation. Also there are emergent properties that get exploited as features, things that aren’t really in the standard but have appeared in an implementation.

In the mobile world right now, developers have it easier since they can target Android, iOS, Blackberry, Tizen and Symbian by just targeting WebKit. This makes life much easier since you really can develop once and deploy pretty much anywhere. It will be a pity to lose this, and potentially quite expensive for smaller development organizations.

I imagine that many source code files will continue to be shared by WebKit and Blink. But for how long? When will we have to pay attention between differences between Blink based browsers and WebKit based browsers?

Summary

Although I find it appealing that Google is hoping to do for HTML/CSS rendering speed what it did for JavaScript execution speed with V8, I’m really worried that this is going to fragment HTML5 development for mobile devices. I tend to think this will cause more web developers to decide that if I need to develop Android and iOS separately then I may as well do both natively in Apps. To me this will be a sad further fragmentation and polarization of mobile developer communities.

Written by smist08

April 13, 2013 at 3:40 pm

Welcome to the Post-PC World

with 2 comments

There were quite a few announcements this week about forthcoming operating systems from Apple and Microsoft. iOS 5 and Windows 8 have quite a few interesting aspects that show how the computing landscape is changing. This blog posting will talk about the various announcements and then provide a fair bit of personal speculation on what this means for ERP, CRM and business computing.

Apple

Steve Jobs

Apple had its WDDC 2011 conference this past week in San Francisco. At this conference they unveiled a new version of iOS, the operating system used by iPods, iPads and iPhones. They introduced a new version of Mac OS and they unveiled a new service called iCloud.

One of the key features of iOS 5/iCloud is that a PC/Mac is no longer required to operate an iPad or iPhone. You can now upgrade the operating system and sync files entirely from the cloud. You are no longer required to ever tether your device to a PC or Mac. This means you can buy and get the full functionality from these devices without owning either a PC or a Mac at all.

Is this the downfall of the PC? Is Apple sacrificing the Mac to eliminate Windows? I suspect PCs and Macs will be around for a long time to come. But if you only need to browse the Web and perform simple computing tasks, is a simple to use, inexpensive Tablet fine for you. Or can you do everything you need to do from your phone all by itself? Will many consumers and businesses just buy phones for everyone and no more PCs or Macs?

Another way to look at this is that the PC (and Mac) have been downgraded to just another device that connects to the cloud. They are now on an equal footing with tablets and phones. Now you can choose the device that is best for the tasks you want to perform. If you need a number of large screen monitors to do programming in many Windows, then a PC Workstation is best for you; but for most other uses a Tablet is better suited and much handier. Some of the advantages that Tablets have is extreme ease of use, very long battery life, light weight, and are actually useful in economy seats on airplanes.

Google

Larry Page and Eric Schmidt

Google has had a very similar plan to Apple all along. Android devices generally don’t require a PC or Mac to operate and Google’s business has always been offering cloud based services. From the beginning Google has been trying to move the world to Browser based clients. Google deserves much of the credit for developing JavaScript into a fully usable and performant platform for development. If it wasn’t for the Google Chrome browser starting a performance war among all Browser vendors, we wouldn’t be able to do what we do today.

There is a fundamental difference in how Google and Apple currently view the cloud. Apple sees it as a synchronization mechanism where the cloud is used to share your files across all the various devices you own. The main point being that the files primarily exist on the devices. Whereas Google sees your files as living in the cloud and being operated on from your devices and never really residing on your devices. I suspect over time these two approaches will become much more blended into a hybrid, since each approach has merits and not one size fits all. For instance the Apple model works even if your device is disconnected from the Internet; whereas, the Google model doesn’t have to worry about conflicts from multiple devices editing the same file locally.

Microsoft

Steve Ballmer

Microsoft has been showing off early previews of Windows 8. My key take away from these videos is that Microsoft is finally adopting open web standards like JavaScript, HTML5 and CSS. They are no longer so heavily promoting a Microsoft only proprietary Internet running Silverlight, XNA or XAML. .Net is just turning ten years old and is moving into the legacy category of MS offerings.

This is really recognition on Microsoft’s part that they are no longer a monopoly and can no longer dictate how developers write their programs. If you are a developer that is starting to write a program today, are you really going to start from scratch and write a program that won’t run on an iPad, iPhone or Android device?

For software developers, this is a huge win. Now there is one clear programming paradigm where you can develop programs that will run on any device whether PC, Mac, iPad, iPhone, Android phone, Blackberry, Touchpad or something that isn’t released yet. That standard is HTML5 combined with JavaScript and CSS. Now you can write once, very rich client applications that run well on all these diverse platforms. Since IE9, Microsoft Windows devices are finally part of the fold and with Windows 8 and IE 10, it looks like MS is now firmly part of this world.

Microsoft is following IBM’s lead and concentrating on selling to IT departments of large companies. Beefing up its IT consulting wing and concentrating on out-sourcing IT datacenters with its Azure platform. Microsoft realizes that huge investments in Windows and Office are no longer worthwhile and that it needs to diversify the devices their software run on, while concentrating on the server side of things. The main problem MS has now is promoting Azure against its main competitors Google, Amazon and Rackspace which are already established and have much simpler to use offerings.

Microsoft is a huge company so there will always be exceptions, for instance at the recent E3 show, MS showed off many quite innovate improvements to the Xbox platform. But many of these are around connecting  the Xbox as another device into the cloud as we’ve been talking about.

Other Vendors

Other vendors, such as RIM and HP are trying to keep pace. At least with the WebKit browser engine which is at the core of the Safari and Chrome Browsers being open source, means that RIM and HP can incorporate this into their Playbook and TouchPad devices and play in the same clouds as all the iPads and Androids. How much room there is there is yet to be seen, but with standards based software, the key to competing is going to be hardware innovation.

Sage

Guy Berruyer

Sage is a business application vendor and not a platform vendor. Sage wants to ensure that all our applications run where and when our customers need them. It isn’t in Sage’s interest to promote any given devices or platforms, it is in Sage’s interest to listen to the market and ensure all our applications can be used where they are needed by our customers.

Sage would like to play in all the platforms and cloud mentioned above. Ideally anyone should be able to access their business application from any computing device, whether to look up information or enter an order. When someone asks if they can run their CRM or ERP application in a certain context, perhaps on a Mac in their design studio, on an iPad at home or on a PC at the main office, we really hate to have to answer with no to what the customer wants to do.

People may not realize that you can run most Sage applications from an iPad already. Most Sage applications support running on Citrix and there is an iPad client for Citrix that lets you access any application on your Citrix desktop from the iPad. Solutions like this along with many new virtualization technologies are opening up standard desktop applications for use anywhere.

It’s in Sage’s interest to work for the best interests of our customers rather than the best interests of any given platform vendor. For the cloud, if say Amazon.com is the best and most cost effective platform today then we should use Amazon.com today, if it’s someone else next year then we need to ensure we have the ability to move and aren’t locked in to higher prices or lesser functionality.

Sage already has a number of cloud based applications like Sage One, SageCRM.com. AccpacOnline.com  or Sage Spark. Then Sage is moving many Windows desktop applications over to being Web based and optionally cloud hosted such as Sage ERP Accpac 6.1A. The key point being that Sage is already operating in these worlds and expanding our presence there aggressively.

With Sage it’s all about freedom of choice. Freedom to deploy locally or to access via the cloud. Freedom to access your applications from anywhere on any device. Freedom to choose the best infrastructure and platform. Freedom to select databases and middleware.

As Sage moves forward we are looking to make our applications far more Service Oriented. You can access our applications through their native Forms, or you can access them through Web Services based on SData. All our Business Logic is encapsulated as a service and can be access via our forms (which use SData) or via any application anywhere utilizing our REST based web services.

Sage will still support on-premise installations for most of our applications for a long time to come. But more and more customers want to move to the cloud for the cost savings and convenience. We want to offer the choice and make the transition (in either direction) as painless as possible.

Of course things are never black or white. Sage will be offering many “connected services” which are web/cloud services that provide the benefits of the cloud to customers running on-premise applications. This way customers can pick up many of the benefits of these new cloud services without having to abandon their investment in learning and customizing their on-premise application. For instance functions that make the most sense to run on phones or tablets could move to the cloud, but still be connected to the on-premise application, syncing data via SData web services.

Summary

Welcome to the Post-PC world. I hope many people are reading this blog from an iPad or other tablet. Perhaps many are reading this from their phone. The point being that you certainly don’t need a PC to perform most computing tasks anymore and in fact there are many tasks that phones can do that PCs can’t.

Written by smist08

June 11, 2011 at 5:18 pm

Posted in Business

Tagged with , , , , ,