Monthly Archives: November 2016

Windows 10 is a great alternative

Marco Arment: “Microsoft is boldly experimenting with PC hardware, but Windows and everything around Windows is woefully inferior to macOS and the Mac software ecosystem. Even if Microsoft did everything right, it would take Windows at least a decade to catch up — and they won’t do everything right.”

Bringing in the HarvestI doubt Marco will see this, and this is definitely not an attack, this is something I’d say to my friends. In the nicest of ways, to say it would take Windows at least a decade to catch up, is a bit hyperbolic.

I’m a fan of Microsoft’s Windows, I have been for years. It helped me get my start in this industry. I switched to the Mac around 2006 and haven’t looked back, I really do love the experience.

If we’re talking about performance, which seems to be the point of your piece, keep in mind that Windows can run on all kinds of hardware. Windows 10 can support up to 256 cores and 512GB of memory. That’s pretty nice. We know that some high end video production shops are abandoning the Mac in favor of Windows boxes because they need the horse power, another great example of why we need a new Mac Pro. But Windows as a tool of choice is very viable.

The development tools on Windows are quite good. Visual Studio is a great IDE. Microsoft’s .Net has become the standard way to develop for Windows, especially for backend services, but you can create beautiful client applications with it all the same. If you’d like you can still write C++ code to the Windows API, like Photoshop or the Microsoft Office apps.

I’m not sure what Marco’s primary complaint about Windows is? Is it just the general usability? Is it a stylistic thing? Maybe he can’t easily run his favorite tools on the platform? That’s a really big deal. I’d love to hear him go into detail about the issues with the platform.

I tell folks all the time. Microsoft’s NT Kernel is a beautifully designed Kernel. It can, and does, underpin different hardware. When it began life it ran on Dec Alpha, MIPS, x86, and eventually came to the PowerPC. Since that time the other architectures fell out of favor and it mainly became an Intel based platform, but it still powers other architectures.

In the end I’d never attempt to tell someone which platform they should choose, it’s all a matter of personal preference. Apple and Microsoft both provide great solutions in software and hardware form. This is great for us, the customer.

Passion Project: Mixing C++, Objective-C++, and Swift

I know a lot of folks have had to go through the process of bridging to C++ so you can use it from Objective-C or Swift. In my case I’m using it from Swift, so I thought I’d share what the middle Objective-C++ layer looks like. If you’ve done any Objective-C it will look like straight Objective-C, until you look a little closer. That’s when you’ll notice a C++ namespace, new, and delete statement. This code is a straight passthrough to the underlying C++ code — it’s here so Swift code can communicate with the C++ code.

Here’s the code that bridges to our Creatinine Clearance calculation.

You’ll notice a class called PKMConvert that has a class method called genderFromPKMGender. I created a set of mirror enums. One on the iOS side the enums use NS_ENUM syntax, on the C++ side they’re straight C style enums, so this code converts between the two. It’s just a simple mapping.

Another thing you’ll notice is I’m still using “old” C++ syntax to create and destroy objects. I’ve been thinking about updating the syntax to C++11 so I’d use unique_ptr instead. We’ll see if that happens. It’s not a big deal.

Something I’ve been mulling over is releasing the entire PKMath C++ Library as an open source project once I have it working for iOS/Mac, Android, and Windows. I don’t know that it would be overly useful for anyone, but there you go.

Since I haven’t actually written any Swift code in the new RxCalc to use the Objective-C++ code I thought I’d share one of my unit tests for the Creatinine Clearance example above.

Here’s how the different layers look from 30,000 feet. I like pictures, don’t you?rxcalc2layers

Passion Project: Update One

I’ve made a couple runs at the freelance iOS developer life. The first time things went really well, but I was offered a gig by one of my clients and it too good to pass up. A couple years into that position — leading a team developing a Windows video decoding SDK — I got the itch to go back to iOS and the Mac. Around the same time our oldest daughter decided she wanted to move back to California. I took a week off to help move here, and think on this idea of going back out on my own. I decided to give it a go. This time around I failed, miserably.

My attempts to go indie have always been predicated by a desire to develop a product. I thought I could bootstrap my indie life doing freelance work. This was definitely a mistake. Once you start doing client work you’re on that hamster wheel of how do I get my next client? Drumming up work is difficult. I failed at that and I’m also a slow developer. I don’t crank out code quickly, which you need to be an effective freelancer. Get it done so you can move on to the next deal.

When I finally found a full time job I decided I’d work on passion projects and see how that worked out. I’ve had many starts and stops on various projects, but I keep coming back to RxCalc. It was my first iOS app. My brother, Jerry, and I worked on it together. Jerry is a clinical Pharmacist and wanted an iOS app to help him do Pharmacokinetics Calculations. He did all the math and designed the workflow and I turned both into Objective-C. We shipped in June 2009 and RxCalc went live in the store July 4, 2009 (nice bonus.)

I’ve been slowly working on a rewrite of RxCalc. My first iOS app was messy, but it has proven stable — I haven’t had a crash report since the 1.0 release in 2009 — but the code is cringeworthy. I’ve cleaned it a bit over the years as well as shipping a 1.2 release that included some new functionality. That release included much cleaner code, but I’ve wanted to add IAP to it for additional calculation models and port it to Android, and maybe even a Universal Windows App.

When Jerry and I originally started developing what was to become RxCalc it began life as a Palm app in C++ and the Pharmacokinetics math library was portable C++. It built on Palm, Windows, and iOS — it built first time on iOS with zero change. When I was learning Objective-C I decided it would be best to port PKMath from C++ to Objective-C. That was really easy. It didn’t take long at all.

Here we are in 2016 and I decided I’d better get started with my grand plan to make PKMath portable, again, and build for iOS, Android, and Windows. Why? Just because. Remember, this is a passion project. I don’t make any money on RxCalc, but I do have a plan to change that with this new version.

Will write C/C++ for foodThe new C++ PKMath library is written. I’ve built a small layer of Objective-C++ over the top of it so I can write the new UI in Swift. The old RxCalc was 100% Objective-C, the new one will be a mix of C++, Objective-C++, and Swift. That sounds kind of weird, but there is a means to an end.

Android is my next target. I’ve started working on JNI wrappers around the PKMath library. This has proven to be extremely difficult. It’s going to take some time to wrap my brain around how this all works. I’ve managed to write a simple sample that uses PKMath to calculate an Ideal Body Weight and display it in an Android view, but that’s as far as I’ve gotten.

As for Windows it’s the thing I’m most familiar with. I’ve spent most of my 25+ years as a developer building Windows applications. The downside is I’ve never built a Universal Windows App and I’m not sure how to properly build PKMath for it. I’ll figure that one out and I imagine it will be as easy as wrapping C++ in Objective-C++.

Progress is slow and I’m easily distracted. We’ll see how it goes. More updates to come.

P.S. — I find Swift to be the most enjoyable language I’ve ever used. Doing the new RxCalc UI has been a lot of fun.

Project Management

Signal v. Noise: “Once a six week cycle is over, we take one or two weeks off of scheduled projects so everyone can roam independently, fix stuff up, pick up some pet projects we’ve wanted to do, and generally wind down prior to starting the next six week cycle. Ample time for context switching. We also use this time to firm up ideas that we’ll be tackling next cycle.”

Get your tools!One of the benefits of having a successful product is not having to hustle work. I always loved this about my early days at Visio. We were on a one year cycle. We would release a version, spend the next few months going over what was next, working casually on fixes or new features, then we’d launch into building the next version. It felt perfect and as a company we were always on time.

I love what Basecamp is doing. They’re obviously a highly capable team that understands what they’re able to deliver in a six week cycle. A lot of us attempt to practice Scrum and fail miserably at it, so we never know how long something is going to take. This team is actually pulling it off with their own “methodology”, and that’s all that matters.

I would encourage you to read the entire article. It’s full of all kinds of little gems.

Swift, on Windows?

Brent Simmons: “What if — and it’s a big if — Microsoft made Swift a peer with C# and provided some good app frameworks?”

When I published What Ifs and Why Nots I hadn’t read Brent’s piece. He’s actually asking the same questions. What would it take to pull Mac developers to Windows? It would take more than Swift, I’m pretty certain. In a Microsoft .Net world where would Swift fit? Would Microsoft just create a version of Swift that works with the .Net garbage collector, or would it be a compiled language? I’d bet on the former given Microsoft’s all-in on .Net and garbage collection.

The bigger questions is Frameworks. Let’s just say Microsoft does a .Net version of Swift. To create a Windows application you’d have to embrace WinRT. You could use your knowledge of Swift, but you’d have to learn a completely new way of writing applications.

Think about all the things Foundation does for you. If you were to move to Windows and Swift on Windows was all .Net based you couldn’t even reuse your non-UI based classes. You could, of course, reimplement your shared classes to use .Net stuff and maintain your interfaces, but you’d have to do a considerable amount of coding to fit on the platform.

Maybe you don’t make Swift a .Net language. Maybe you bring Foundation over to Windows using the Windows API, which is very different from a development standpoint, and not the preferred way to code new apps on Windows. This could also work. You would have a compiled Swift that could natively link to Foundation, which in turn uses Windows API’s to do any platform level stuff. You could then reuse some of your code investment, like those shared non-UI classes and work on creation of a native Windows UI for your application.

Also, of note. Microsoft already has a great set of Frameworks to use, just use them. It would be like coming to the Mac from Windows and saying “Apple needs to provide some good app frameworks.” They already do, you just need to learn to use them to make the best experience for your users. That is the biggest hurdle for any developer.

Learning the new frameworks and a new OS can be quite daunting. When I came to iOS from doing Windows and Linux based UI’s (using Qt mind) I fought with Interface Builder and decided I had to do everything in code because I couldn’t figure it out. Later I made my peace with it. I still think Visual Studio is the better development environment, but Xcode is a very close second, maybe tied, at this point.

Eat your own dog food.I’m kind of a knucklehead. I spent almost 20-years doing native Windows API based applications so I was very comfortable with Visual Studio and that entire ecosystem. If I can learn to write iOS Applications and embrace the tools, then anyone doing Mac or iOS apps could learn to do Windows based stuff today. Just embrace it, don’t try to force your tools into the platform. Now, if you have some code that can easily come over, you might as well use it, but we all know the best apps feel right on the platform. Embrace the platform.

The new Surface Studio is the first bit of Windows based hardware that has excited me this much about the platform in a very long time. I’d love to work on a new design app for Windows, if I could. Maybe even one that works on both platforms; Windows and Mac. Why not? I mean besides time and money, what else does one need to do something so ambitious? 😀