Feeds:
Posts
Comments

Posts Tagged ‘software development’

There’s been a lot of churn lately over the price of Bitcoin. There’s also been much talk about uses (commercial and otherwise) for the blockchain technology that underlies it. I’ve taken an interest, as of late, in the subject and I found a promising source of information in the Michael J Casey, Paul Vigna book The Truth Machine.

If you’re looking for a book on how to write blockchain software. This book isn’t going to be of much interest to you. If you have interest in the history of the technology, its applications and societal impacts, you will find it to be a solid read.

Bitcoin and  Ethereum, and the like are discussed with enough depth to provide non-developers a good sense of use cases. This is after all the point of a technology. Otherwise you’ve got yourself shelfware. All the major players are discussed running the gamut from crypto-anarchists to Wall Street bankers. I find the dynamic of these two extremes battling over this technology fascinating.

One definitely comes away with the sense that the technology is still very much a work in progress. Personally, I find it unfortunate that the public sees it as another get-rich-quick methodology. This loops back to the volatility of the Coin markets.

Another, and arguably more important, takeaway is that the systems currently in place do not scale (or at least have yet to be proven to scale). That Bitcoin can process six transactions per second in a world where Visa processed ten thousand is quite telling.

The underlying problem of who’s in charge comes to mind. Without some form of human governance, poor programming will result in bad actors taking advantage of the system. Nowhere does the book address the issue of longevity. The thing about paper (or animal hide for that matter) is that it has a permanence that has proven itself outside of our advances in storage technology. If we did move to a blockchain-based system of ownership tracking, what happens when another, better one comes along? What will the impact of quantum computing be in a world where work is proportional to CPU expended? What happens when people decide that it’s easier to steal the resources used to mine the coin?

I only have a few issues with the book.

First, for a book on a complex technological subject, I expect extra fact checking. I noticed two rookie mistakes in this department. ASIC is defined as ‘Application-Specific Integrated Chips’ whereas it should be ‘Application-Specific Integrated Circuit.’ It also doesn’t require quotes. In the realm of techno-history, the authors attributed Public-Key Cryptography to Whitfield Diffie and Martin Hellman. This is of course incorrect. That distinction belongs to James H Ellis (at least until the NSA owns up to when they started using it). Although his work was once classified, it have been publicly recognized for some time now.

Second, the book wanders off the path of techno-history and into the realm of  conspiracy theory and political opinion when they introduce ‘speculation’ of hacking in the MH370 incident and spend the bulk of the last chapter on the latter.

On the whole, I found the book to be a very good and current survey of the landscape of blockchain technology and its history.

 

Read Full Post »

So, you’re the newly minted leader of a group of software developers. Are things really going well or have you merely ‘assumed’ control?

Have You “Assumed” Control

So, you’re now the manager / director / vice president of engineering responsible for a software development team. Are you in control or do you merely assume so? How much do you know about your process, resources, etc.?

It’s 8PM, Do You Know Where Your Source Code Is?

Do you know where your source code is? Without source there is no product. No worries you say, “it’s all in source control.” Cool. Where? Who can access it? Is your IP kept separate from the open source and third party bits you use? Do you have appropriate access control if you have dual company relationships? How much can be accessed by non-developers / contractors? Have your development and IT department worked to establish appropriate backup behaviors to prevent you from capturing third-party source into your corporate backup system in a way that will not withstand an audit? There are mainstream third-party libraries which upon termination of use require removal of all copies. Failure get you an additional year of license payments.

What’s up Doc?

How long would it take to put together a top-to-bottom explanation of any given project in your organization portfolio? Not to have someone explain it all, but simply to arrange a soup-to-nuts set of documents arranged in some kind of self-guided tree that anyone could follow should everyone in the development group be waylaid by aliens. Follow-on, how much critical information is stored only as tribal knowledge, squirreled away in the brains of your staff? How many of your processes require human intervention from a special person to  work at all? Does the documentation you do have match the process you use? Does each piece of documentation have an owner?

The Open Source of Our Disk Content

Do you use open source components? In this day and age, who doesn’t? How long would it take you to inventory your open source use on a per product release basis? Do you have an engineer who works with legal to ensure that the open source you use have licenses that harmonize? Do you have an approval process for using open source? Does you appropriately fulfill the licensing requirements? If you modify the source, do you return it to the author? Do you make the source available on your web site (on a per product / release basis)? On our site, why? In a word “abandonware.” Is this really necessary? Well, there’s open source poisoning. And let’s not forget FSF vs. Cisco. Are your developers using code they found on the web and not worrying because about it because there is no stated license? You do remember that that material is protected under copyright law under the Berne Convention (additional exposition here).

The Very (Threat) Model of a Modern Software General

Does your product ever have interact with anything else? Of course it does. Do you have a threat model for it? At every abstraction level? Do your developers know how to read and create a threat model? A good threat model will help drive your security position papers. Security should be a tangible thing and not simply a warm fuzzy. Make your security staff’s job easier. This also reduces the time required to respond to identified security threats in the wild.

Old Isn’t Gold

There’s a phrase that show up a lot in ads for stock services. You know the one. “Past performance is not a guarantee of future results.” This is absolutely true in software. Whether you’re referring to tools, processes or people, the way things have been done is in no way guaranteed to be best practice, or even supported, in the future. This mirage of stability and security may take the form of build systems without build masters, tool chains no longer available or supported, or any tools that new hires have never heard of. Software development is not a capitalized asset, but rather on ongoing expense. We expect that pens today will serve us well tomorrow, but this is definitely not the case with software tools. Strangely, many companies expect that people will want (and in fact demand) their new software products because of the added functionality. Why would the software tools used to product said software be any different. Additionally, there is the issue of support from the vendor and in some cases the very existence of vendor. It’s akin to acting offended when the doctor you had as a child retires.

Pay no Attention to the Man Behind the Curtain

Do you have projects which are the equivalent of the mystery meat you were served in school for lunch? You know the ones. Old projects or products kept around because there’s one really important customer who still uses it. The kind of projects that rely of AS400‘s or AIX cross-compilers to work. The ones where if one particular individual left the company, you’d end up having to pay them as a contractor just to do the build. This is the hardware / process analog to knowing where your software is. If you have these, they will require special attention and not in a good way.

See No Evil or Monkey See, Monkey Do?

If your software development organization doesn’t believe that there is any reason to review the full offering every two years or never looks outside the organization when setting future directions, you have a big problem. The superstars who brought the organization their last breakthrough are only as good as the last thing they learned. As was heard at GE, “Woe unto ye corporate superstars who have not this day performed a miracle, for you shall be known as bums.” If you never look outside, one day you will discover that you have not been surpassed, you have been rendered irrelevant.

Can’t Touch This

If you’re not organization won’t even consider touching sections of the code base because there might be testing impact (scheduling or resources) or the “you can only change the code if a failure has been identified via some test,” you have severe issues. There are advances in every aspect of computing every day. From the processors, to the compilers,  debuggers, static and dynamic analysis tools, to the very algorithms, someone is working to make the software development process easier, faster, safer, and less fattening. To declare a piece or vast chunk of the code base untouchable says that you don’t understand it and are afraid that merely looking under the hood will loose all kinds of unspeakable horror; or that you hold the belief that the code in question is the realm of genius and mere mortals may not intrude.

Back to the Future

In any sufficiently complex system, there is a not insignificant amount of time between design and production. When instantiated in hardware, the lifetime is further extended. Issue of support will demand that less than state-of-the-art tools be expected and managed. If your product has a lifetime of ten years and you build it with tools, techniques and targets from ten years ago, where do you think you’ll be by the time you end-of-life the product? Where will the people who can work problems be? If you’re lucky your organization will have an Office of the CTO. For those of you who just did a head tilt, the mandate of the CTO’s office to keep abreast of futures. So even if you can’t use the bleeding edge tech today, you can be aligned for when you can. These are people you can go to with the “what if” questions. They provide options and evaluations. Let’s be real, you probably have your product developers working on existing products. You also probably have a very short design phase for new features and products. It’s amazing how many products have suffered from just getting something working and calling it good. Wouldn’t you rather have something better than the top result on Google driving your product design?

Is This the Way to the Vice-President’s Office?

In any healthy organization, you can expect that your developers will want to advance. Do you have a clear, straight-forward and consistently-applied technical career ladder? It should cover both the qualifications, duties and expectations of each rung. Is it up-to-date? Do the engineers understand it? Are there soft aspects? Is it actually used? This is a hearts and minds thing. It speaks to the relationship between staff and management. Some people will reach a particular level and be completely content. Others will want to run the ladder. Having a documented path, gives everyone a basis for conversation and a way to set goals.

On the Bench or On the Beach?

So the organization you’ve assumed has the people, skills and processes to handle all your current needs. You’re golden, right? Now ask yourself how deep your bench is. Do you have an inventory of your teams skills? Is it up-to-date? How fast can you assemble an inventory? Look at it.

Are you tracking the current software industry trends in terms of desired skills, programming languages and tools? Why? Look at your bench. See the rookie end? How do you think they select what they study in school? The smart ones are being guided into the high-demand skill areas by the time they’re in their second year of school. Where is all this drive coming from? The FANG companies. They’re the cool kids. They run at scale. They have the money to explore. They’re the companies you’re competing with for new graduates. Save money and see where they’ve been, what’s worked, what hasn’t and where they’re signalling the future is. Remember, you can tell the pioneers by the arrows in their backs.

Did you notice how the TIOBE and Stack Overflow surveys differ on programming languages? They’re using two different metrics. TIOBE sample commits to open source, Stack Overflow surveys active developers.

Now look at the middle of your bench. It’ll be the biggest section. They’re your bread and butter. Are their skills fresh? This speaks to the career ladder. If you’re using a ladder with out-of-date qualifications and expectations, where does that put you? Do you have mechanisms in place to keep your teams fresh date current?

The veteran end of your bench represent your heavy hitters. These individuals have depth or breadth of experience in domain or technology. If you’re extremely lucky you’ll have a few who have both. There may be a tendency to let them get a pass when it comes to their staying current. Don’t ever give them a pass. With great experience comes great expectations. It’s far too easy to simply trust the word of experience without making sure that they aren’t simply recycling knowledge they gained decades ago. Remember that your organization is competing in a global arena. These are the people who should be spending a large amount of their time exploring both the state-of-the-art and the competitions; and also digesting and disbursing that knowledge within the organization. If you’ve got insular vets setting direction, you’ve got a recipe for failure. Maybe not today, but rest assured, the piper always gets paid. Choice of processor, operating system, development language, communications protocol, user interface all come with cost not only today, but downstream. Finally, are your veterans creating information silos in order to ensure their position or do they make sure that knowledge is spread as far as possible within the organization? The former creates an environment of dependency, the latter spurs innovation. The rookies and mid-career developers must never believe that the views of the veterans are unassailable.

View to a Skill

We’ve explored the experience axis of the bench, but what about the skills axis?

If you speak with your development staff about a new technology / methodology / language and you hear, “that’s cool, but here we …,” it’s time to get those wagons out of the circle. This is sure sign that developers are either unwilling to work on their skills or have been beaten down by management in the past. The former is a one-on-one issue, the latter is a systemic problem.

Back to your skills inventory. Does your organization have the right skill sets to accomplish your mandate? If not, can you get there from here? If you can’t what will you do? If you can, how will you engage and implement? Do you have individuals with skills who aren’t being engaged where they could have a positive impact? It shouldn’t matter their tenure. Do you have team members with skills your teams need? How can you uplift the teams with their knowledge? What if they don’t have skill in the area of teaching others? Your organization should have an active mentoring program in place. If you can mentor one person, you can explain to someone who can train others. Your mentors can be brought into group teaching as domain experts. Your team members with teaching experience already know how to extract information from various sources. To them domain experts are a source capable of answering questions.

The Grass is Always Greener

What is the flow of the development staff? Do developers see sustaining and current projects as a dead end? This may be indicative of the shiny ball syndrome. If developers are climbing over one another to get to the greenfield project is it because there’s the perception that only the shiny and new get resources and the attention of management? Does every greenfield project manifest the same patterns of behavior as the sustaining and current only with newer tools? Are greenfield projects used to reward performers rather than being staffed based on background? When a developer moves to a new project, is sufficient knowledge transfer done to ensure no loss of continuity? This information is particularly indicative of the nature of the organization and is a way that management communicates the value and priority of various projects.

Princely Behavior

Is your organization a minefield of fiefdoms and politics? Allocate half your time to dealing with it. Few things will run your development teams into the ground faster than time lost for engineers trying to please two masters. Many people would like to believe that software development is a democratic process. That’s a very naive view. If that were the case, we’d vote on every decision and everyone would have equal weight to their opinion.

And, Action

Keep in mind the words of Brian Kernighan and P. J. Plauger in their book The Elements of Programming, “Write and test a big program in small pieces.” Make your plan with modest, attainable, measurable goals. It’s no different than creating a software project plan. As you proceed, beware individuals with an all-or-nothing attitude. No large undertaking will cover all the bases regardless of planning. Don’t let the desire for a mythical über-solution stand in the way of a good partial solution. Solve problems in the priority order of the problems, not the perceived importance of individuals or groups.

Homework


Image credit: Four Worlds. Creative Commons.

Read Full Post »

I’ve been reading Isaacson’s DaVinci biography (that’s another post) and thinking about metaphors, analogies, teaching and learning.

Teaching is hard. The world is a complex place, so that’s to be expected. Learning is hard, although many people expect it to be easy. I mean, really, like, you can just Google things.

Well, really, not so much.

For me teaching is all about the group and the motivating example. Humans learn best by metaphor, going from the known to the unknown. Kind of like having one foot firmly planted on the lip of the hot tub and testing the temperature with the other. Just jumping in might work. Not something to rely on though. If you give people a framework they can relate to, it affords them a place from which to extend what they know.

On my high school senior physics class final was a problem that began, “A rock explodes into three pieces …”. Really? Why? It’s been a lifetime since that event and yet the premise of the problem still sticks with me. During my undergraduate studies, I had a physics professor whose motivating examples were based on James Bond situations. As contrived as physics problems tend to be in order to tease out a self-contained use of some specialized equation, at least contextualizing thing via James Bond gave them a veneer of reason. Mostly. Sort of.

During my graduate studies, I dropped a class in neural networks because the professor presented the material in such an abstract fashion that I couldn’t anchor it. It wasn’t until I took Andrew Ng’s first Machine Learning class on Coursera (which was one of two first offered) that neural networks actually made sense to me. He presented the material in the context of real-world use cases.

I’m not say that everything can be learned by simply having a good story. If you work with computer software long enough, you’ll have to confront numbers represented in binary, octal or hexadecimal. You’ll just have to memorize the conversions. The same is true for operator precedence.

Let’s look at learning for a minute, lest everyone think that I’ve forgotten it.

In order to learn something, assuming that it’s not rote memorization, you must accept the framework within which it exists. Unless you put can do that, things won’t stick. You will forever be condemned to Google it hell. I can usually tell the people who will have difficulty learning a programming language when they complain that it’s not like the language they’re used to. As I like to say, “you can program C in any language.” Some people never get past that point. And we all suffer because of it.

I’m not limiting this to C-based languages. The interpreted world has more than their fair share of people still programming BASIC in any language. I like to think of them as the Python without classes crowd. I’m not sure where the whole “classes are bad” mentality came from, but it seems to have a strong following.

For a less software example, consider using a word processor. Do you still type two spaces after the period? Unless you’re using a typewriter, all you’re doing is messing up the formatting software (technically hyphenation and justification (H&J) system). Try this experiment. Take a word processing document and look at how it formats the text with both a single and double space. This becomes especially evident when full-justifying paragraphs.

All well and wonderful, but what about the pretzels?

Yeah, about those. I struck me that this whole teaching / learning thing can be likened to making pretzels. You know the big, soft, knotted, salt-covered ones. Consider the dough as the learner, the salt and shape the material to be learned and the kitchen equipment the methodology. The cook is the teacher. If the dough is frozen or dried out, it can’t be shaped. This is a refusal to accept the rules of the material. If the equipment is inadequate or the cook lacks an understanding of how to use it, the results will be inconsistent. Likewise, if the cook doesn’t understand how to handle the dough or when to apply the salt, things will probably not be the best. It is only when all three elements are brought together properly that the expected outcome is achieved consistently.

In the realm of teaching this means that the teacher needs to be able to create a motivating example and framework that works for the learners. This changes over time. Just as the world changes. The teacher should be always looking for signs that a student is frozen and be ready with additional material they may more readily relate to. The most difficult cases are the dried out students. They see no need to learn the new material and are at best taking up air. At worst, they are disruptive. These individuals should be given to understand that their presence is optional and that others should be allowed to learn.

Finally, as a teacher, always, always be looking for what you can learn from the students. The world is bigger than you little pretzel shop.

Read Full Post »

I’m big on education, think Swift is a great language, and believe games can be a practical way to motivate learning. So, how did I put this into practice?

What’s My Motivation?

During my career, I’ve had the opportunity to teach programming and software development (two distinctly different things) to both teens and adults. One thing that’s always struck me is the disjoint nature of the material. Not in terms of the subject matter, but rather with respect to the examples being used. I learning a spoken language, you don’t abandon a part of speech as you acquire another. Learning is both cumulative. As we learn, we revise our approach.

In teaching programming, we seem to be so focused on being focused, that we divorce ourselves from the actual processes that go on when we solve real-world problems. In the past few years, I’ve noticed that people are producing programming language courses reduced to five minute info-bites. Here’s the thing, software development is a long-form practice.

Early Insight

I put together my first programming curriculum in 1981 when I was a instructor at Computer Camp, Inc. in Santa Barbara, California. The students were teens and the problem in my mind was motivation. Unlike adults, most of the teens I’ve taught over the years don’t approach programming from experience. They have a beginners mind. This is both good and bad for a teacher. The good is that they don’t have bad habits yet. If properly taught, they will think in the language. The bad is that we, as experienced developers, have come to see programming languages as a collection of “computer language components” and not as a methodology for solving problems as expressed in a specific syntax. As a result, the vast majority of software written today would have the spoken equivalent of transliteration. All the words are there and a native speaker could probably make sense of it, but they would suffer greatly.

In 1982, I found myself tasked with teaching an advanced BASIC programming class. It was then that I hit upon the idea of a dungeon crawler. The students were interested from the outset. They appreciated that everything they were spending their precious time on was leading to the outcome. They looked at the language as a means to solve a problems and not a way to take a solution from another language and reapply it.

So, now I understood that it was possible to motivate and teach people how to think in a programming language. Could I leverage this understanding?

Teaching Revisited

In 2008 I had the opportunity to teach electrical engineers C++ and SystemC. These were individuals who’s software development experience was grounded in C programming. Their code and indeed, approach to software development, was procedural as once might expect. In order to teach them SystemC, people must first learn C++ (the language SystemC is written in). After working with the materials we had been using, I felt strongly that we weren’t motivating an appreciation and understanding of object orientation. I had the opportunity to participate in the creation of an entirely new C++ curriculum. From the beginning it introduced object orientation. There is a interesting shift that takes place when the responsibility for the data shifts from all the code that touches it to objects that manage it.

The Stanford Way

I’ve been watching Stanford’s iOS development course (CS193P) since it was first made available. It has undergone an interesting evolution over the past decade. Initially, it taught Objective-C development and iOS programming. This included pure (non-GUI) Objective-C and test driven development. With the fundamentals in place, the model-view-controller paradigm was taught as the foundation of iOS development. Then the class shifted into the standard piece-part methodology we see everywhere, albeit with a distinctly iOS bent.

Over the years, both the pure language and test driven development aspects went away. These were relegated to reading material. Objective-C was supplanted by Swift. More sophisticated areas were covered as the iPhone evolved. By the end of the course, students can build complex apps. But it feels like people are learning APIs rather than the language. But what can you do in 10 weeks? Would people actually pay for a college course to learn Swift and then another for iOS development?

Enter Wumpus

About five years ago, someone asked me to teach them how to make iPhone games. They had no software development experience and little desire for the traditional approach of learning via classes or books. They understood the ins and outs of game play and had a keen sense of what made a game playable.

The process that followed was the condensation of forty years of writing code and developing software. Today, when we work with just about any OS API, we have to deal with a context. But how do you motivate the very idea of the context. How do you teach people to work effectively with the net result of over fifty years of software development practices without just expecting that people will simply accept that this is the way it is and you just have to accept it? You can easily create an animation, but what is happening behind the scenes? Being able to understand and explore these questions is what will determine if someone will be capable of working beyond the software equivalent of writing pulp fiction.

In the end, I settled on teaching software development through the very old game of Hunt the Wumpus. This game appeared in the original Unix distributions. It has simple rules, a bit of action, some random elements and is, on the whole, able to be understood by a nine-year-old. It’s implementation can be used to demonstrate multi-dimensional arrays, randomization, object-orientation, internationalization, error handling, data visualization and testing.

As this was before Swift, it was implemented in Objective-C.

Personally, I used my implementation of Wumpus to experiment with iOS. Specifically, I was tinkering with storyboards in Xcode. I wanted to see if it was possible to implement the user interface of Wumpus entirely using scenes representing the rooms within the game. This is, of course, a horrific abuse of the scene concept and is the equivalent of unfolding an array of objects into individual routines. It did, in fact, work. And I would not ever recommend that the technique be used for production code.

Enter Swift

Two years ago Apple announces Swift. Immediately, I started working with it. Like many languages before it, Swift incorporated lessons learned. In the case of Swift, many lessons were learned. You can look at my earlier posts to see my past musings on the language.

In May, I found myself with sufficient time on my hands to undertake a rewrite of Wumpus in the soon to be released (now just released) Swift 3. Concurrently, iOS 10 was to come out and would be supported by Xcode 8. Changes all around. My initial Wumpus model was readily brought over from Objective-C. Over time I realized that many of the things in that implementation could be completely folded down to a single line of Swift code. Swift wasn’t an extension of an older language. In fact, as the language evolved from version 1 to 3, many elements initial present were removed or replaced. Today’s Swift is much more consistent as a result.

I knew the pieces of the user interface that would be required and set about recreating them. This time is a sane fashion. Once this was done, I began the process of connecting the view to the controller layer and eventually the model. All the while, adopting the Swift 3 and iOS 10 idioms.

At this point, I had a playable version of Wumpus. There was a main scene that took you to the rules or the game. The rules were a static chunk of text. The credits was static attributed text. You could navigate the maze and be moved (scene with alert) or die (scene with alert). Shooting came in and initially used a scrolling picker with the room numbers. Dull stuff.

Just Add … Everything

Now came the interesting bits. The iOS-specific bits.

It’d be dull to cover this in detail, so here’s a rough sequence.

  • 30+ background images
  • danger annunciator images
  • tint overlay to gray scale backgrounds
  • ambient sound across scenes (looped soundtrack)
  • incidental sounds within scenes (looped for danger and one-shot for events [moved, died])
  • added settings controls for all audio volumes
  • asset catalog used for both image and sound management (simplified access)
  • rebuilt settings using a table with dynamically constructed cells with action handlers
  • saved statistics using class-based archiver
  • rebuilt statistics using dynamic data generation from the statistics data
  • segues and segue unwinding (navigation control)
  • timers (scene auto-transition from title scene)
  • tap gestures (eliminating navigation buttons)
  • replaced static rules text with chunked pages and swipe gestures
  • custom font (Kalam)
  • parallax (titles, danger annunciators and event imagery)
  • dynamically constructed attributed text (credits)
  • endless scrolling text loop (credits)
  • dynamically constructed tables from plist data (statistics field names)
  • static collection view replacing lame picker interface (shoot scene)
  • app analytics (Firebase)
  • ad support (AdMob)
  • JSON processing (credits source import)
  • core data (credits attributed string construction)
  • built to work with both iOS 9.3 and 10.0 (core data had a major change)
  • social network (Facebook / Twitter) posting

Testing, Testing

An important part of creating an iPhone application is being able to ship it. But before that you should really test it. A lot. Really.

To do that you need to do the dance of getting certificates and creating an app instance. With these you can push builds to Apple’s servers where they can be accessed by internal testers (all builds) and external testers (specific builds, after review [sort of]). Then comes the great fun of prodding the testers.

Collateral Damage

It’s been tested. All the features (for this release) are present. And it’s time to ship, right? Actually, no. You can’t ship an app without creating a bucket and a half  of collateral images (screenshots) for the app store. There’s also the small matter of the web site that will support the app. And no self-respecting app would go up without a game play video.

About those images. You technically only need one set at the highest screen geometry. The others will be generated by scaling. Now, you’ve gone to all the trouble of adopting an adaptive user interface so things look reasonable on all the various screen geometries, so not generating imagery for every size would just be lazy. Happily, all these can be generated from simulator screen capture. Image having to round up half a dozen devices just to do screen caps. Did I mention that video? Well, you can’t video capture from the simulator. So, for those of you who look at my app on the store, there’s just the one from my current iPhone.

I do keep referring to Wumpus as an iPhone app. Well, it is. I designed it for portrait-only. Now this doesn’t prevent you from putting it on an iPad. The problem is that Apple has never updated the screen size used from iPhone apps on an iPad. It’s this pointlessly scrunched up screen size. It looked brain dead. So, I went back and tweaked the layout to be less egregious. It’s not pretty, but why are you running it on an iPad in the first place?

Can I go now?

What could possible be left to do?

  • specification of age rating
  • description for the store
  • verification that you own or have license for all the bits you’re using
  • text for alerts presented to the user, if certain features are used

About that whole licensing point. Wumpus uses a lot of images and audio tracks. They all need to be acknowledged properly. That was a driving factor in using Core Data to track them. All the ones I used were either public domain or minimally encumbered. The biggest problem I had was not finding them, but selecting from among them.

And yes, now it’s ready to ship.

Ship It

So, about two weeks ago, submitted Wumpus for review. Well, I tried to. Apple will only review apps built against finalized OS libraries. Wait. Wait. So I added a few more bits to fill the time. On Monday 12 September 2016, I was able to submit Wumpus for review. After a brief diversion of trying to find out how to answer new privacy questions related to the use of Firebase and AdMob. Then came the wait. Did I forget something? Was there some horrible error condition lurking waiting for the mystical Apple auto application checkers to detect. Would the review be delayed by more relevant applications (honestly, that’s just about every other app)? Nah, it was all good.

On Wednesday 14 September 2016, I got an auto-generated email informing me that my app was available for sale. Pretty anti-climactic really. If you have an iPhone/iPad, you can download it today. The related web site is also online.

And?

So where’s the tie-back to the teaching programming / software engineering? That was the point, right? Absolutely. I’m not done. Although Wumpus represents an interesting résumé piece and I’ll be extending it with additional technologies (such as web, Apple Watch), my take away is an example that I know I can use to teach both Swift and iPhone development. Like all good stories, this one leaves me wanting more.

Read Full Post »

iOS 10 ships on September 13th. Apple has changed their generated code for Core Data. It doesn’t compile if you set your deployment target to iOS 9.3. What’s a developer to do?

For a very long time now, Apple has be proud, and deservedly so, that their users are overwhelmingly keeping up-to-date with the latest releases of their operating systems. As such, Apple’s messaging to developers is to support the current and previous OS version. Most of the time, this isn’t a big deal. Sometimes, it is. With the latest changes related to Core Data, it’s a problem.

If you create a new Xcode project that will being using Core Data, you get some useful code bits in the AppDelegate. In Xcode 8, you get the following (comments removed for brevity):

lazy var persistentContainer: NSPersistentContainer = {
    let container = NSPersistentContainer(name: "coreme")
    container.loadPersistentStores(completionHandler: { (storeDescription, error) in
        if let error = error as NSError? {
            fatalError("Unresolved error \(error), \(error.userInfo)")
        }
    })
    return container
}()
 func saveContext () {
    let context = persistentContainer.viewContext
    if context.hasChanges {
        do {
            try context.save()
        } catch {
            let nserror = error as NSError
            fatalError("Unresolved error \(nserror), \(nserror.userInfo)")
        }
    }
}

This works great if you’re only going to build for iOS 10, but if you try to set your deployment target to iOS 9.3 as recommended, you’ll get the following error:

AppDelegate.swift:49:35: 'NSPersistentContainer' is only available on iOS 10.0 or newer

Well, that’s not good.

As users of Core Data know, operations using it use a database context. You can see it being used in the saveContext function above. Here we see that the context is a member of the persistentContainer. Since this doesn’t exist in iOS 9.3, we’ll have to get it some other way.

Let’s look at what used to be supplied with Xcode 7 (udpated to Swift 3):

lazy var applicationDocumentsDirectory: URL = {
    let urls = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)
    return urls[urls.count-1]
}()

lazy var managedObjectModel: NSManagedObjectModel = {
    let modelURL = Bundle.main.url(forResource: "bfoo", withExtension: "momd")!
    return NSManagedObjectModel(contentsOf: modelURL)!
}()

lazy var persistentStoreCoordinator: NSPersistentStoreCoordinator =
{
    let coordinator = NSPersistentStoreCoordinator(managedObjectModel: self.managedObjectModel)
    let url = self.applicationDocumentsDirectory.appendingPathComponent("SingleViewCoreData.sqlite")
    
    do {
        try coordinator.addPersistentStore(ofType: NSSQLiteStoreType, configurationName: nil, at: url, options: nil)
    } catch {
        let dict : [String : Any] = [NSLocalizedDescriptionKey        : "Failed to initialize the application's saved data" as NSString,
                                     NSLocalizedFailureReasonErrorKey : "There was an error creating or loading the application's saved data." as NSString,
                                     NSUnderlyingErrorKey             : error as NSError]
        let wrappedError = NSError(domain: "YOUR_ERROR_DOMAIN", code: 9999, userInfo: dict)
        print("Unresolved error \(wrappedError), \(wrappedError.userInfo)")
        abort()
    }
    
    return coordinator
}()

lazy var managedObjectContext: NSManagedObjectContext = {
    let coordinator = self.persistentStoreCoordinator
    var managedObjectContext = NSManagedObjectContext(concurrencyType: .mainQueueConcurrencyType)
    managedObjectContext.persistentStoreCoordinator = coordinator
    return managedObjectContext
}()

I’ve left out the saveContext function as it’s only distinction is where it gets the context from. Above, we see that the context is a separate variable.

Now without a doubt, the iOS 10 code is much simpler, but, if we want to be able to do the right thing and support both current and last version, we need a bit of a mash up. It’s a bit tedious, but you only have to build it once (hint, hint Apple). Here’s what I’ve come up with.

// MARK: - utility routines
lazy var applicationDocumentsDirectory: URL = {
    let urls = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)
    return urls[urls.count-1]
}()

// MARK: - Core Data stack (generic)
lazy var managedObjectModel: NSManagedObjectModel = {
        let modelURL = Bundle.main.url(forResource: modelName, withExtension: modelExtension)!
        return NSManagedObjectModel(contentsOf: modelURL)!
}()

lazy var persistentStoreCoordinator: NSPersistentStoreCoordinator = {
    let coordinator = NSPersistentStoreCoordinator(managedObjectModel: self.managedObjectModel)
    let urls = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)
    let url = self.applicationDocumentsDirectory.appendingPathComponent(modelName).appendingPathExtension(sqliteExtension)

    do {
        try coordinator.addPersistentStore(ofType: NSSQLiteStoreType, configurationName: nil, at: url, options: nil)
    } catch {
        let dict : [String : Any] = [NSLocalizedDescriptionKey        : "Failed to initialize the application's saved data" as NSString,
                                     NSLocalizedFailureReasonErrorKey : "There was an error creating or loading the application's saved data." as NSString,
                                     NSUnderlyingErrorKey             : error as NSError]
        
        let wrappedError = NSError(domain: "YOUR_ERROR_DOMAIN", code: 9999, userInfo: dict)
        fatalError("Unresolved error \(wrappedError), \(wrappedError.userInfo)")
    }
    
    return coordinator
}()

// MARK: - Core Data stack (iOS 9)
@available(iOS 9.0, *)
lazy var managedObjectContext: NSManagedObjectContext = {
    var managedObjectContext = NSManagedObjectContext(concurrencyType: .mainQueueConcurrencyType)    
    managedObjectContext.persistentStoreCoordinator = self.persistentStoreCoordinator    
    return managedObjectContext
}()

// MARK: - Core Data stack (iOS 10)
@available(iOS 10.0, *)
lazy var persistentContainer: NSPersistentContainer = {
    let container = NSPersistentContainer(name: creditsModelName)    
    container.loadPersistentStores(completionHandler: {
        (storeDescription, error) in
            if let error = error as NSError?
            {
                fatalError("Unresolved error \(error), \(error.userInfo)")
            }
        }
    )
    
    return container
}()

// MARK: - Core Data context
lazy var databaseContext : NSManagedObjectContext = {
    if #available(iOS 10.0, *) {
        return self.persistentContainer.viewContext
    } else {
        return self.managedObjectContext
    }
}()

// MARK: - Core Data save
func saveContext () {
    do {
        if databaseContext.hasChanges {
            try databaseContext.save()
        }
    } catch {
        let nserror = error as NSError
        
        fatalError("Unresolved error \(nserror), \(nserror.userInfo)")
    }
}

I’ve introduced databaseContext as the context variable to be used throughout. I think it’s more clear and now saveContext doesn’t have to care which OS you’re targeting. With this change in place, you can now safely target 9.3 and still build for 10.0.

Read Full Post »

One of the challenges in learning a new language, be it human or computer, is learning to think in the language. Learning Swift is no different.

I’ve been spending the past several months working on the first iOS (iPhone) app that I’ll be releasing through the Apple app store. I’m writing it entirely in Swift 3, the latest version of the language. Yesterday, I was looking over the code to see if there were any places where I’d been thinking in a non-Swift fashion. This moment of reflection was triggered by my viewing of a very recently released class in Swift from one of the major online education sites. I was disappointed that the instructor was using an idiom that I knew was easily simplified in Swift. My disappointment made me wonder if I had similar issues.

The following is actual code from my upcoming app. I had originally created it’s core in C as an extensible example for teaching that language. The setup is as follows:

  • the map is an array of connections from each room
  • the number of connections from each room is fixed
  • we are explicitly tracking the number of a given type of hazard

We want a function that returns true if there is hazard in one of the connecting rooms. Here’s the original code:

var hazardNear = false
        
if hazardCount > 0
{
    for nextRoom in 0 ..< numberOfConnections
    {
        if hazardRooms.contains(exits[room][nextRoom])
        {
            hazardNear = true
                    
            break
        }
    }
}
        
return hazardNear

Pretty conventional C-esque stuff. The first thing that jumped out at me was the reliance on knowing the number of connections. Swift arrays are true collections. Let’s treat them as such.

var hazardNear = false
        
if hazardCount > 0
{
    for nextRoom in exits[room]
    {
        if hazardRooms.contains(nextRoom)
        {
            hazardNear = true
                    
            break
        }
    }
}
        
return hazardNear

When viewed this way, it’s obvious that we’re just filtering the collection based on a condition. So, just do that.

var hazardNear = false
        
if hazardCount > 0
{
    hazardNear = exits[room].filter{hazardRooms.contains($0)}.count != 0
}
        
return hazardNear

We’re filtering the array of rooms for ones that contain the hazard and checking for a non-zero count. But this is still a bit clunky. Let’s examine what we’re really asking.

var hazardNear = false
        
if hazardCount > 0
{
    hazardNear = !exits[room].filter{hazardRooms.contains($0)}.isEmpty
}
        
return hazardNear

It’s far more clear to simply ask if the filtered array is non-empty directly. What’s left is one final simplification.

return hazardCount > 0 && !exits[room].filter{hazardRooms.contains($0)}.isEmpty

One might ask whether having an explicit count is necessary as the hazard array has a count. True. Although the hazard array is built based on the number of hazards, so I still need it to be around.

Overall, I fairly pleased with the results of the exercise. In the end, the code is much clearer in intent.

Read Full Post »

One of the nice things about taking months or even years to finish reading a book is that it gives me plenty of time to reflect on it. Sure, I could binge read, but the material is far less sticky. The longer I spend with a book, the more connections I can make. “Failure Is Not An Option,” which I just completed a few days ago, is a good example of this.

The book itself is a retelling of history of the manned space program from the point of view of someone intimately familiar with the events. At first blush, it would appear to have nothing to do with the process of software development. The Apple Pencil I’m using at the moment probably has more computing power than anything available at the time. So, what is the connection?

It is absolutely true that when dealing with matters of human life that failure is not an option. When you look at the history of American manned space flight from the outside, the only thing you see is the ultimate expression of this. You see successful execution, even in the case of unforeseen situations. And that’s the key, it’s from the outside. Success was not achieved because perfect people perfectly executed perfect plans using perfect equipment under perfect conditions. Yes, there were times when the execution, equipment or conditions were perfect. Most of the time, success was ensured inspite of less than perfect conditions. For me that’s the story.

During the space program, failure was a mandate. When you exist in a world of constrained resources, the best way to ensure that you will be successful is to see how you respond when the resources that you depend upon are available. But, wouldn’t you always being everything you needed and have it on hand? One would hope so, but let’s say, for the sake of argument, that you didn’t. What then? If something bad happens, how much time do you have to get things back on track before it’s game over? Well, that depends on what happened, when it happened and how important it was.

Okay, sure, fine, but what did they do and what does it have to do with software development?

In the case of the space program, failure was ensured before the mission. Every possible they could conceive of. Teams of people had the sole job of enducing failures during mission simulations. We’re not talking SimCity or Second Life here. These simulations were conducted in physical hardware as identical as possible. The difference is that this user interface was driven not by physical sensors, but computers. Crews were made to experience failure over and over until their responses were second nature. When you think about it, this is no different from any physical endeavor. The more you train yourself to respond to situational changes, the better your performance becomes.

As of late, I believe that many of the problems with software and hardware have been coming about because of a focus merely on the “happy path.” The idea that we should worry first about making it work and then later about failure conditions. Unfortunately, once management sees something that “works,” they  are unlikely to allocate time to break things. The situation has been made worse by the attitude that software will be tested in beta.

As a result, not only is inferior quality software being produced, but the software is being used in environments which expose their data to exfiltration. We see this is malware infecting point-of-sale systems. We see it in OpenSSL and other open source code. Software being widely adopted under the assumption that someone else must be testing it. Entire generations argue for speed over safety.

So, why has this attitude taken hold? Is it harder to design for failure first? Not really. In fact, it makes unit testing easier as it builds in the failure paths before the actual implementation. But doesn’t this make the code slower? Not implicitly. Between the use of modern tool chains and profile guided optimization, the cost of fail first, fail fast is minimal. Why don’t we do privilege segregation? For the same reason we don’t apply principles of  MVC, MVVM or VIPER. People sit in front of a screen and type. They use the excuse of doing “agile” development on short cycles for not properly planning. Now, I have nothing against short cycles, but to be used properly, you have to accept that not every problem can be evaluated, solved, implemented and tested in 2 or 3 weeks. Some things are hard. Some things can only be accomplished by specific individuals. Some tasks have dependencies on outside resources. Software isn’t building IKEA furniture. There are high level of indeterminacy that can and do crop up.

Neither can we pretend that the software we create lives in isolation or that security is the responsibility of the user. Holding onto data simply because it would make the developer’s job easier during development is not enough of a reason. Not using OS provided encrypted data storage because it makes it harder to debug is simply lame. Transmitting data in the clear or without access control just invites both data exfiltration and command-and-control injection.

Here’s the thing. If you want to succeed, you must fail. You must fail first and you must fail fast. Failure helps to characterize the system. It helps in the creation of documentation. It helps validate the design. Failure makes gives you a better understanding of the problem space. In short, failure is not an option; it is a requirement.

Read Full Post »

Older Posts »

%d bloggers like this: