Feeds:
Posts
Comments

Archive for the ‘Computers’ Category

The early years of computing were a like a Renaissance dance, lots of people who somehow manage to get to dance with each other at least once. A Mind at Play: How Claude Shannon Invented the Information Age gives us yet another place to stand and watch that dance.

Claude Shannon is one of those people who fundamentally changed the way we look at the world. The problem with fundamental change is that we tend to be on one side or the other of it. Today we speak of information theory as though it’s as obvious a concept as making paper. Kind of the same way we obsess over software developers being able to write code to sort numbers or reverse linked lists. At some point, the fundamental reality of the existence of high-quality libraries and data structures will make these queries as relevant as requiring people to explain a tape sort. But I digress.

He was a researcher, tinkerer, teacher, juggler, and for all appearances didn’t seem attached to labels. He had Vannevar Bush looking out for him. As an MIT professor, he had Danny Hillis and Ivan Sutherland, among others, as doctoral students. He worked with Alan Turing during World War II. And the box-switch-thing that turns itself off. That was him.

Reading the book, you get a sense of possibilities explored. So often people either dismiss or defer possibilities. He literally had a basement full of them. If only he’d know Ron Popeil, every home might have a few of them.

I don’t know how well he would fare in the world today. In his time, Bell Labs basically paid to have him around. He had cachet. He also helped focus people’s ideas. He brought this sensibility to MIT with him as a professor. We get so terribly wrapped up in being hyper-specialized, in know the what but not the why. To often we come across the proverbial Gordian knot and turn away. People are either unwilling to try, or believing themselves to be special, simply act as though the problem does not exist. (Treating people poorly and flaunting violations of the law fall into this category.) Few people are willing to question the fundamentals. What do you need? What do you have?

The interesting people are those who solve problems and help other people solve problems, not by merely telling them what the answer is, but by enabling them to see that solutions can come from places that aren’t necessarily rooted in the past ways of doing things.

In our day and age, when we focus on special skills and special languages and special hardware, it would behoove us to remember that there is no best skill or language or hardware. There is only the universe of problems. It is far more valuable to be able to help others see the shape of the solution than to be an individual capable of providing a answer to a well-defined question whose value will in time expire.

Read Full Post »

When I was asked to create and teach a Python class, I had to ask myself, “where is the starting point for this language?”

When it comes to computer languages, I like them logical, powerful, compact and fast. The language currently at the top of my list is Swift. When it comes to longevity, C++ wins hands down. Python is neither compact nor fast. It is, however, very popular. It’s also very flexible.

The C language has so many children that it’s easy to use analogs. What about Python?

I’ve taken intro CS courses from Harvard, Rice and Stanford all of which use Python. They all teach C programming in Python in my opinion. I get where they’re coming from. You’ve spent years using FORTRAN then Pascal then Java.

Happily, my first language was FORTRAN. You think you need to build all your own data structures if you use C. Consider yourself lucky. But that’s a story for another day. My second lanugage as APL. Go ahead try to teach APL the way you teach C. Knock yourself out. A bit later I picked up BASIC, which after FORTRAN was trivial. Next came Forth. That took a bit to wrap my procedural head around. My experience with APL had taught me that it’s perfectly fine to focus on the data and not the process. Forth’s focus on the stack is strangely intriguing. The fact that it lives on in UEFI and Postscript is a testament to the fact that there is value in that view of the world.

So my approach was to start with data representation. In Python the world is all objects and references. But for some reason, people don’t want to approach the language from that standpoint. They like to talk about how easy it is to write ‘hello, world’ programs or how it’s more readable than Perl. Aside from APL, I don’t know anything that’s less readable than Perl. Except maybe TECO macros.

Now that I had a place to start, life should be a hop, skip and a jump to classes, yes? Not so fast pilgrim. It’s easy to explain that everything is an object and that integers are a sub-class of rationals. It’s easy to explain that 0 takes 12 bytes of storage. You can even justify the lack of a character object. But I think you do a true disservice if you don’t address the fact that strings are Unicode based. I’ve dealt with enough internationalization issues to know that to gloss over this would be a disservice to the student. I probably spent more time working on the string section of my class than any other.

The reason? It’s one thing to present information that raises obvious questions like, “so you’ve told me that there as multiple ways to represent the same grapheme and that these strings will have different code units, but what am I supposed to do about it?” Or “how am I supposed to sleep knowing that a Vai 4 digit isn’t the same as an Arabic numeral 4?” You might as well throw them under a bus if you honestly believe that you’ve discharged your duty as a teacher by telling the students that there are land mines out there and that they should bring an umbrella. You’ve essentially just given them a compelling reason to never use the language.

Once all the ‘core’ data types are out of the way, it’s time for some core data structure like list, tuple, and namespace.

Functions, generators, and lambdas come next. These are relatively straightforward. The trick to generators is to show the equivalent implementation in C++. Yes, they are different beasts, but you can get close enough. Similarly with lambdas.

Now, you’re in a position where classes can be reasonably explained. A point to mention here is that back before embarking on a exposition of data types, keywords and variable conventions were addressed. Now, for most students, this goes in one ear and out the other. Having arrived at classes, all those naming conventions come back like an overeager Sheltie wanting to play. Ignore them at your peril. Enumerations are also introduced here.

For many, all the object bits will now come into focus. This is a good thing. I’ve never liked the approach where students are taught how to use bits and pieces of libraries without the foundation to understand what’s actually happening. They end up with a false sense of accomplishment and may never seek to build an accurate model of the languages world. They’re like Jeff Goldblum’s character in ‘The Fly’ having no clue how things actually work since he just specified what he wanted a given part to do and plugged the parts together. We all now how that worked out for him. It also emphasizes their importance of debugging you system.

I’ve never understood why some people shy away from classes in Python. They act as though organization is an inherently evil thing. They also probably have all their laundry in two piles in the middle of their bedroom (one dirty, one clean).

Classes point us to resource management, but we can’t do that discussion until input / output is covered. That gives us the idea of using classes (file streams) and their methods to process data. Here’s where string formatting and core data conversion comes in.

Up until now, exceptions have been alluded to. Now there’s enough structure to not only address, but give meaningful examples of their use.

At this point, you’re done with the core language. So we’ll address unit testing. We’ve done bits of this along the way since the introduction of classes, but now we can talk about the unit test library.

What remains are sections on sequence and associative containers. An important aspect of this is teaching how to select the appropriate container. Yes, you can use list and tuple alone, but there are better things to do with your life than reinventing the wheel. Technical interviews insisting that people be able to balance binary trees notwithstanding.

Finally, a brief introduction to the standard library. Before Googling, how about being aware what’s already in the box.

You’ll note a distinct absence of web browsers, GUI applications, client-server systems, etc. Just the language here.

Would my class make you a Python expert. By no means. As with all things, you become proficient through years of study and practice. It is my hope that my Python class would give you a good start on that journey.

Read Full Post »

I’ve just finished reading Code Warriors: NSA’s Codebreakers and the Secret Intelligence War Against the Soviet Union by Stephen Budiansky. It tells the story of the US National Security Agency (NSA) up through the end of the Cold War.

Given the number of dry histories of the people and agencies who deal with cryptography and spying, this book is reasonably readable. If you’re looking for a less arch, and more human view on how things got to where they are; you’ll like this book.

The takeaway from the book is that the biggest hindrance in the world of security is people. People who are control freaks or don’t believe that rules apply to them, or believe that the “other side” is stupid, or are just too damn lazy to do the simple things that would avoid issues are the problem. You can’t design your way around them. If you try, you’ll only make things worse.

You can’t pretend you have the moral high ground when you’re collecting enough information to make the US National Archives, the Library of Congress, Google and Facebook look redundant. I’m not picking sides, I’m just saying that if you’ve got a hammer and you use the hammer, own up to the fact and don’t go around telling everybody and their brother that they shouldn’t use hammers and that in fact that hammers either don’t exist or are illegal (or would be if they did actually exist, which they don’t).

Along the way, you’ll be introduced to a cast of well-intentioned, clueless, brilliant and ruthless individuals. There are miscommunications, denial of responsibilities, bruised egos, moments of insight and face palm moments.

Please keep in mind Hanlon’s razor.

 

Read Full Post »

The Chrysanthemum and The Sword is an exploration of what makes the Japanese tick. At least from the standpoint of a early 20th century scholar. Ruth Benedict was one of that era’s foremost anthropologist.

I could go into the interesting discussion of how the American and Japanese cultures are compared and contrasted. Or how she describes the Japanese approach to Buddhism as being free of non-corporeal entanglements. I’ll leave those to the earnest reader.

What made the greatest impression on me was the lengthy and detailed exploration of on (恩) and giri (義理). These can broadly thought of as debt and obligation. In the west, we have a fixation on equivalent exchange. We like to pretend that there is nothing which cannot be fully bought and paid for. The Japanese fully recognize that this is not the case and have build a society around the concepts of overlapping obligations.

One that I have always found difficult to explain is that of shogimu (諸義務) or obligation to one’s teacher/mentor. This is always an asymmetrical relationship. The apprentice has nothing to offer in exchange in comparison to what they are given. In the west, we, as they say, “just take the money and run.” This is especially true in regard to the attitude of Googling for the answers. People have come to believe that they can monetize the collected knowledge of the world without cost to themselves. The problem comes not to this first generation, but to the second and finally fully realized in the third generation of internet users. The problem is that of who supplies the knowledge.

One of the big complaints of the pre-internet era was how big companies hoarded knowledge, making it available only at a premium. Should it not be free to all? Between the small band of developers (relatively speaking) who contributed to open source, the internet and google, we find ourselves in a place where you don’t need a master to monetize. And so rather than having to pay for software as a function of complexity and craftsmanship, we tolerate mediocre software because it’s free (with ads or in exchange for our personal information).

Meanwhile that high quality software we wouldn’t pay for when it was $400 with a year of updates, we will pay for when it’s a $120 annual subscription to a cloud service. Except that now if we stop paying, we lose access.

But back to the thorny question. Do we really believe that the Google-for-code and I-built-it-all-from-other-people’s-stuff crowd are going to give back to the community? What will happen when those who made all these goodies possible and available retire? If we take the C++ community as an example, there are hundreds supporting millions. This doesn’t scale.

Answers? Nope.

Thoughts? Some.

Personally, I’ve got a bucket full of on, so I should get back to it.

Read Full Post »

A quick check of my iOS app Wumpus Hunter Neo-classic shows me that I’ve got some updates to make before iOS 11 releases. There’s been some changes to the way the UI handles scene transitions. The app itself seems to be otherwise behaving itself.

Read Full Post »

The thing about teaching a class is that it can’t actually be done. You can only teach an individual.

I’ve been teaching since I was in middle school. Hard to believe, but true. That effort, to teach my younger sister (by six years) how to do addition was an utter failure. My next major outing was to create a one week segment for my 12th grade physics class on black holes, including a test. I believe that one fared better, although I don’t believe my endeavor to expose my classmates to then cutting edge cosmology was necessarily appreciated.

Throughout college, I was a TA and grader for various CS classes. I spent a summer a the Nature and Conservation director at a Boy Scout camp and two summers teaching programming to teens. By the time I entered the professional arena, I knew teaching (tech transfer) was in my DNA.

A decade ago, I worked for a company where teaching C++ was part of the job.

Fast forward to my current position. I’ve had the opportunity to create and present Modern C++ (C++14) training within my company. This has come in two flavors, one to jumpstart them into C++ (C developers) and one to bring them up to speed on the start of the language (C++98/03 developers). Both classes have about 15 hours worth of material.

The first challenge in teaching modern C++ is that of linearization. C++ has a wonderful breadth. Unfortunately, It can be challenging to present the material in such a way as to be both meaningful and at the same time not resort to appeals to Oz-ian “pay no attention to the man behind the curtain.” My success in this area I attribute to years of exposure to the materials of James Burke.

The second, far more interesting challenge, is hitting that Goldilocks zone where everyone is learning. Even when teaching C++ to C developers, there will be those who immediately take to its conceptual frameworks and there will be those who probably never will. It would be easy to cater to the former and simply write off the later as Luddites. Alternately, one could obsess on the later group and end up boring the former to tears. A fundamental balance can be achieved by using labs which build upon a coherent problem and lead the student to embrace ever more abstract aspects of the language.

In the case of my modern C++ for C++98/03 developers class, I take an entirely different approach. With them I use a progression from changes in the language, to important element of the standard library, to useful Boost bits and finally to the contributions made by the GSL. Within this progression, I give attention to each feature or class using a presentation / discussion format. Unlike the jumpstart class, I can’t use the labs to modulate the pace of the class. Each group I teach will progress at their own pace. (I limit my class size to about 20). In this advanced class, I also find myself researching answers to specific, real-world issues that the students are encountering. I then fold these results back into the materials I present.

As with any modern company, there is a mix of platforms under development. This has necessitated my doing a bit of bounds checking to be sure that the materials I present will work in a Visual C++ / gcc / VxWorks world. With the advanced class, I present not only the modern (C++14) methods (with a bit of C++17 previews), but also the pre-C++11 mechanisms as not everyone has the luxury of constantly upgrading their tool chains.

Overall, it has been an enjoyable experience. One I’m sure I’ll be repeating in the future.

Note: As a nod to an interesting Stanford professor (Mehran Sahami) and in the voice of Starfire, I have taken up the habit of “the throwing of the candy.”

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 »

Older Posts »

%d bloggers like this: