It seems like this information hasn’t been disclosed quite enough as it should: Makey Makey’s version 1.2, produced by JoyLabz, cannot be reprogrammed with the Arduino software. In previous versions, you could customize the firmware — remap the keys, access the AVR chip directly — using an Arduino sketch.

🙌 NOTE: Dedokta on Reddit demonstrates how to make a Makey Makey.

Now, this isn’t necessarily bad: version 1.2 has a very nice way to remap the keys. This page here. You use alligator clips to connect the up and down arrows of the Makey Makey, as well as the left and right arrows, then plug it into the USB port. The remapping page then communicates with the Makey Makey through keyboard events. (See Communication.js.)

This is all very neat, but it might be nice to see warnings on firmware projects like this one that they only support pre-1.2 versions of the Makey Makey. (I realize the page refers to “Sparkfun’s version” but it might not be clear that there are two Makey Makeys floating about—it wasn’t to me.)

⛺ UPDATE: The text on the chip of the version 1.2 appears to read: PIC18F25K50. That would be this.

Some Notes About Connecting to iPads

Now, how I came upon this problem was while experimenting with connecting the Makey Makey to an iPad. Instructions for doing this with the pre-1.2 Makey Makey are here in the forums—by one of the creators of the MM.

With the 1.2 version, it appears that the power draw is too great. I received this message with both an iPad Air and an original iPad Mini.

Obviously a Makey Makey isn’t quite as interesting with an iPad — but I was messing with potentially communicating through a custom app.

Anyway, without being able to recompile the firmware, the iPad seems no longer an option. (The forum post should note this as well, no?)

Interfacing the Sparkfun Makey Makey with Arduino 1.6.7

If you do end up trying to get a pre-1.2 Makey Makey working with the latest Arduino, I ran into many problems just getting the settings right. The github repos for the various Makey Makey firmwares are quite dated.

One of the first problems is getting boards.txt to find my avr compiler. I had this problem both on Linux and Windows. Here’s my boards.txt that finally clicked for me:

############################################################################
menu.cpu=Processor
############################################################################
################################ Makey Makey ###############################
############################################################################
makeymakey.name=SparkFun Makey Makey
makeymakey.build.board=AVR_MAKEYMAKEY
makeymakey.build.vid.0=0x1B4F
makeymakey.build.pid.0=0x2B74
makeymakey.build.vid.1=0x1B4F
makeymakey.build.pid.1=0x2B75
makeymakey.upload.tool=avrdude
makeymakey.upload.protocol=avr109
makeymakey.upload.maximum_size=28672
makeymakey.upload.speed=57600
makeymakey.upload.disable_flushing=true
makeymakey.upload.use_1200bps_touch=true
makeymakey.upload.wait_for_upload_port=true
makeymakey.bootloader.low_fuses=0xFF
makeymakey.bootloader.high_fuses=0xD8
makeymakey.bootloader.extended_fuses=0xF8
makeymakey.bootloader.file=caterina/Caterina-makeymakey.hex
makeymakey.bootloader.unlock_bits=0x3F
makeymakey.bootloader.lock_bits=0x2F
makeymakey.bootloader.tool=avrdude
makeymakey.build.mcu=atmega32u4
makeymakey.build.f_cpu=16000000L
makeymakey.build.vid=0x1B4F
makeymakey.build.pid=0x2B75
makeymakey.build.usb_product="SparkFun Makey Makey"
makeymakey.build.core=arduino
makeymakey.build.variant=MaKeyMaKey
makeymakey.build.extra_flags={build.usb_flags}

I also ended up copying the main Arduino platform.txt straight over.

Debugging this was difficult: arduino-builder was crashing (“panic: invalid memory address”) in create_build_options_map.go. This turned out to be a misspelled “arudino” in boards.txt. I later got null pointer exceptions coming from SerialUploader.java:78 — this was also due to using “arduino:avrdude” instead of just “avrdude” in platforms.txt.

I really need to start taking a look at using Ino to work with sketches instead of the Arduino software.

Right now the spotlight is stolen by lovely chips like the ESP8266 and the BCM2835 (the chip powering the new Raspberry Pi Zero). However, personally, I still find myself spending a lot of time with the ATtiny44a. With 14 pins, it’s not as restrictive as the ATtiny85. Yet it’s still just a sliver of a chip. (And I confess to being a sucker for its numbering.)

My current project involves an RF circuit (the nRF24l01+) and an RGB LED. But the LED needed some of the same pins that the RF module needs. Can I use this chip?

The Rise and Fall of PWM

The LED is controlled using PWM — pulse-width modulation — a technique for creating an analog signal from code. PWM creates a wave — a rise and a fall.

This involves a hardware timer — you toggle a few settings in the chip and it begins counting. When the timer crosses a certain threshold, it can cut the voltage. Change the threshold (the OCR) and you change the length of the wave. So, basically, if I set the OCR longer, I can get a higher voltage. If I set a lower OCR, I get a lower voltage.

I can have the PWM send voltage to the green pin on my RGB LED. And that pin can be either up at 3V (from the two AA batteries powering the ATtiny44a) or it can be down at zero — or PWM can do about anything in between.

My problem, though, was that the SPI pins — which I use to communicate with the RF chip — overlap my second set of PWM pins.

You see — pin 7 has multiple roles. It can be OC1A and it can also be DI. I’m already using its DI mode to communicate with the RF module. The OC1B pin is similarly tied up acting as DO.

I’m already using OC0A and OC0B for my green and blue pins. These pins correspond to TIMER0 — the 8-bit timer used to control those two PWM channels on OC0A and OC0B. To get this timer working, I followed a few steps:

// LED pins
#define  RED_PIN   PA0
#define  GREEN_PIN PB2
#define  BLUE_PIN  PA7

Okay, here are the three pins I want to use. PB2 and PA7 are the TIMER0 pins I was just talking about. I’m going to use another one of the free pins (PA0) for the red pin if I can.

DDRA |= (1<<RED_PIN) | (1<<BLUE_PIN);
DDRB |= (1<<GREEN_PIN);

Obviously I need these pins to be outputs — they are going to be sending out this PWM wave. This code informs the Data Direction Register (DDR) that these pins are outputs. DDRA for PA0 and PA7. DDRB for PB2.

// Configure timer0 for fast PWM on PB2 and PA7.
TCCR0A = 3<<COM0A0 | 3<<COM0B0 // set on compare match, clear at BOTTOM
       | 3<<WGM00; // mode 3: TOP is 0xFF, update at BOTTOM, overflow at MAX
TCCR0B = 0<<WGM02 | 3<<CS00; // Prescaler 0 /64

Alright. Yeah, so these are TIMER0’s PWM settings. We’re turning on mode 3 (fast PWM) and setting the frequency (the line about the prescaler.) I’m not going to go into any detail here. Suffice to say: it’s on.

// Set the green pin to 30% or so.
OCR0A = 0x1F;
// Set the blue pin to almost the max.
OCR0B = 0xFC;

And now I can just use OCR0A and OCR0B to the analog levels I need.

TIMER1, 16-bit is Better, Right?

Most of these AVR chips have multiple timers and the ATtiny44a is no different — TIMER1 is a 16-bit timer with hardware PWM. Somehow I need to use this second timer to power th PWM on my red pin.

I could use software to kind of emulate what the hardware PWM does. Like using delays or something like that. The Make: AVR Programming book mentions using a timer’s interrupt to handcraft a hardware-based PWM.

This is problematic with a 16-bit timer, though. An 8-bit timer maxes out at 255. But a 16-bit timer maxes out at 65535. So it’ll take too long for the timer to overflow. I could lower the prescaler, but — I tried that, it’s still too slow.

Then I stumbled on mode 5. An 8-bit PWM for the 16-bit timer. What I can do is to run the 8-bit PWM on TIMER1 and not hook it up to the actual pin.

// Setup timer1 for handmade PWM on PA0.
TCCR1A = 1<<WGM10; // Fast PWM mode (8-bit)
                   // TOP is 0xFF, update at TOP, overflow at TOP
TCCR1B = 1<<WGM12  // + hi bits
        | 3<<CS10;  // Prescaler /64

Okay, now we have a second PWM that runs at the same speed as our first PWM.

What we’re going to do now is to hijaak the interrupts from TIMER1.

TIMSK1 |= 1<<OCIE1A | 1<<TOIE1;

Good, good. OCIE1A gives us an interrupt that will go off when we hit our threshold — same as OCR0A and OCR0B from earlier.

And TOIE1 supplies an interrupt for when the thing overflows — when it hits 255.

Now we manually change the voltage on the red pin.

ISR(TIM1_COMPA_vect) {
    sbi(PORTA, RED_PIN);
}
ISR(TIM1_OVF_vect) {
    cbi(PORTA, RED_PIN);
}

And we control red. It’s not going to be as fast as pure PWM, but it’s not a software PWM either.

Why Not Use Another Chip?

I probably would have been better off to use the ATtiny2313 (which has PWM channels on separate pins from the SPI used by the RF) but I needed to lower cost as much as possible — 60¢ for the ATtiny44a was just right. This is a project funded by a small afterschool club stipend. I am trying to come up with some alternatives to the Makey Makey — which the kids enjoyed at first, but which alienated at least half of them by the end. So we’re going to play with radio frequencies instead.

I imagine there are better other solutions — probably even for this same chip — but I’m happy with the discovery that the PWM’s interrupts can be messed with. Moving away from Arduino’s analogWrite and toward manipulating registers directly is very freeing — in that I can exploit the chip’s full potential. It does come with the trade off that my code won’t run on another chip without a bunch of renaming — and perhaps rethinking everything.

Whatever the case, understanding the chip’s internals can only help out in the long run.

If you’d like to see the code in its full context, take a look through the Blippydot project.

I often have the students concoct their own story problems. Lately, I’ve been using a tablet-based drawing tool along with some stickers from Byte. (I would love to use Byte—but it doesn’t live up to COPPA.)

One kid came up with the pictured story problem. Pardon the grammar—we didn’t proofread these.

To clear this up: the lemon is struck by lightning 117 times each day! This lemon also appears to be alive, unlike the unfortunate turtle and teacup that found themselves stuck on the same hillside.

He is also probably actually a lime. How would that be—to have your key identity discarded during this defining moment? Maybe this is that elusive lemon-lime that the soft drinks always talk about.

Clearly we are dealing with a tough fellow here—an affluent, though morose, lemon-maybe-lime. We all hurriedly dashed out the answer so that we could know exactly how many strikings this poor citrus had endured! It was a tough four days.

---

Now for this one.

I asked the student, “Will the hobo still blow the monkey up after he spends his $40,000?”

He said, “He’s going to blow him up no matter what.”

Wealthy monkeys, don’t do business with hoboes! Especially hoboes trafficking 18 mil in explosives! That seems suspicious to me.

---

The last story problem I want to mention never actually materialized, but this next one is a math-in-feelings problem.

It went like this:

(Student who has been at the counselor’s office arrives late for the activity.)

Me: “Ok, (Student). We’re coming up with story problems.”

Student: “Oh, I know what mine is!”

Me: “Let’s hear it.”

Student: “Ok. There are two guys. And they’re neighbors.”

Me: “Sounds good.”

Student: “And they hate each other in a hundred different ways.”

Me: “Oh, wow.”

Student: “But they love each other in a hundred different ways.”

Me: “So they cancel each other out.”

Student: “No, so you take all of their feelings—how many feelings all together do they have for each other?”

One of the kids next to us goes, “Four hundred feelings!” jubilantly.

At the beginning of the year, the principal came to me and said, “I’m going to have you help with the after-school computer club. It’s a club for fourth- and fifth-graders.”

I was like, well, yeah, I’m the computer teacher, that makes sense.

She tells me the first grade teacher is in charge and I’ll just help her.

Perfect. This particular teacher is a close friend and this probably means we can do what we want.

“And code.org is going to give you all the stuff.”

Ok, no sweat. We’ll take a look.

---

A month ago, I walk into the first grade teacher’s room and she’s got this little pile of stuff on her desk.

I go, “What’s all this?”

It’s the stuff from code.org. A cup. A packet of seeds. A gumball. Dirt.

She’s like, “I don’t get this.”

I clear a space and start to look over the paper she’s got—it’s this lesson plan that goes with the cup. And the dirt. (Wait—is that real dirt?)

Now, I’m just a computer teacher at a public elementary school—meaning I am absolutely the bottom of the chart on Career Day—like you do NOT bring up my job as some kid’s future—I am next to the guy selling Japanese dexterity games out of a kiosk at the mall—same guy who dresses in gold spandex and gets to be the Snitch in college Quidditch games—you don’t see him for two hours until you notice him above the quad, scaling the political science building—so, yes, a paltry elementary school computer teacher, but I have to tell you: I would never teach computer programming with a cup of dirt and a gumball. Nut uh. Not the way they’ve got this.^[1]

So we bag that.

“Ok, good,” she says. “So I’m not crazy.”

She is. All humans are. But now’s not the time.

She seems relieved at first. Until she goes on. “So the next thing is: zombies.”

Couple clicks and her Macbook is showing the zombie lesson. In this lesson, all the kids get a zombie.^[2] You basically control a zombie with code. You make it walk. Lurch forward, lurch left, lurch forward, lurch left, lurch left, lurch, lurch, lurch, then lurch right. That kind of thing.

“It’s not bad,” I say.

“I just don’t get why,” she says. “What is this for? Like: is this really teaching code?”

I’m thinking that, well, it kind of does—I guess?

“Code.org is like a million-billion dollar thing, isn’t it?”

“Well, Mark Zuckerberg,” she says. “And I think President Obama is in the video. Or he’s on the site or something.”

We look. Yeah, that IS Obama.

“So we’ll work for an hour and the kids will have made a zombie walk around a bit.”

So we bag that.

Fortunately—meaning this is where our fortune left the realm of mere dirt and a little bit of zombie walking—I had recently played a game called HIGH END CUSTOMIZABLE SAUNA EXPERIENCE. And somehow my thoughts turned toward this game, of which I recalled two things. For one, I remembered something about hacking into a cupcake in the game, which was certainly a fond memory. And then, the other thing, of course, what also came to mind, is that the game was a Twine game. A hypertext game. Made by Twine—some kind of neat way of building these games.

I pulled it up on her Macbook. Fifteen minutes later, we were like: “This. We are doing this.”

---

So we covered Twine for the first three weeks of the club. The first day we just showed them how to link.^[3] This was actually plenty. I think this could have gone on for three weeks alone. One of the kids came up with this game THE BLOOD FLOOD. And, in his game, everywhere you went, THE BLOOD FLOOD showed up. Like this tsunami of gore.

Another girl came up with this game where you just lose. Over and over, you just lose. First you die. Then you lose a hundred points. Then your mom traps you and you lose. And then you die and you’re broke.

Great game. Pretty lifelike.

I expected the crazy stories. What really surprised me was: a kid showed me his project and it was a map of his family, done using Twine links. So he had links for his sister and mother and father and grandparents. And you could navigate his whole family and learn about them.

The creative story side didn’t appeal to him. He wanted to use the information housing and organization aspect of programming. It was a database.

So the kids universally loved the first week. (Kids love a lot of things, though.)

---

Second week we ran into problems getting everyone’s pages loaded. Not everyone was using the same laptop that they used the first week. So that can be a bit of a setback when using Twine—you’ll need to archive your stories and put them on a USB stick or something. Technically, the district’s user profile sync stuff should have brought down all the Chrome settings. However, I guess it doesn’t do anything with Chrome’s LocalStorage. So some kids had to start over. It was okay—they’re a resilient bunch. All humans are. But this problem, coupled with the time required to subsequently be resilient, meant we couldn’t cover as much.

We talked about the set: command and the if: command. The point was to help them see how to pick up things and how to give the player coins, swords and other trinkets one might take a-questing.

One kid wrote this dungeon where you could pick up a sword—and the sword is at 100%—so it’s like (set: $sword to 100).

And then, as you fight through the dungeon, the sword wears down.

So: (set: $sword to $sword - 5).

And then when it’s at zero, it’s useless.

(if: $sword > 0)[Take another [[swing]]?]

I was blown away by how much they could do with a simple variable and a conditional statement. I mean how. How are we spending time drawing shapes, lurching left, lurching right, when you can do all this great stuff with a variable and an if? I realize Papert did it this way—with shapes, with lurching—not with zombies but with turtles. Who am I to question Papert? Look him up on the career chart.

To me, this is incredible. On our first day, we were making actual games—text games, yes, but fun ones. I should have known better. I mean this is the generation that plays Minecraft for fun.

They were actually building the game logic. Like in a meaningful way—by turning these abstract constructs into concrete, actual iron swords that wear down.

The beauty of Twine is that your variables persist—they last the whole game. Doing this with straight JavaScript and HTML would be such a hassle to teach. There’s no need to understand scope or storage or anything like that. You’re just putting stuff in little cups. Not irrelevant dirt or gumballs. But REAL imaginary coins.

Initially I had planned to write some macros to help with inventory in Twine. I’m so glad I didn’t. By forcing the kids to use the basic constructs directly, they were able to grasp the rudiments and then apply those throughout their games.

Too often I see sites (like codecombat.com comes to mind) which give a kid an API to use. Like useSword(), turnRight(), openDoor(). I can’t understand this. It is teaching the API—not the simple constructs. Anyway, should we really be starting right into objects, methods, arguments and all that?

---

Our third lesson covered adding images, music, colors and text styling. I’m not as happy with Twine’s absence of syntax here—you’re basically just doing HTML for most things. But I also felt it would be good for them to dip their toes in HTML. For some kids, they didn’t care to take the time to use this tougher syntax just to put a picture in there.

They also struggled with stuff like (text-style: “rumble”). They loved the effect—esp. the two girls doing a graveyard adventure—but they didn’t like having to get everything perfect—the double-quotes, the colon, the spacing. This kind of syntax is a hurdle for them. Typing skills are still needed. This is a generation of iPhone users.

In all, my experiment using Twine went great—super great—they could do this every week and be content. There are a lot of movements out there to try to teach computer hacking, but they all really miss the mark in a way that Twine doesn’t. They don’t get railroaded into solving mazes. The kids come away with a real game.

---

1. In case you don’t believe me: Real-life Algorithms. ↩︎

2. Right here. ↩︎

3. Twine kind of follows the wiki-style of linking. You simply surround a phrase by double square brackets. Like so: [[Johnston St.]] Now it’ll create a new story page for Johnson St. ↩︎

This is a speech I like to give my students about my beliefs with regard to Nicolas Cage, to clear up any misunderstanding. Please contact my office if you would like me to give this speech at your school or at a civic meeting.

Let’s get right to it.

I believe in Nicolas Cage.

I believe he is real.

I believe that he is not a projection of my mind. I could not have invented Nicolas Cage—that much I know.

I believe he lives.

I believe that he believes that he lives. Which I find even more convincing.

I believe in him—that he’ll go far in life. He already has gone far, yes, but he will go far again and again.

I believed him in National Treasure when he said he would be stealing The Declaration of Independence. He did.

I believed him in National Treasure 2 when he said he would be kidnapping The President of the United States of America. He did.

I believe in the “nouveau shamanic” style of acting that this man employs.

And so I believe that there was no script for the National Treasure movies. I believe we are simply watching a man go about his daily routine. I believe that, right now, Nicolas Cage is solving national mysteries and nerding out over rare coins. He could be travelling back in time to kill Betsy Ross. He could be fighting a giant lizard-enhanced Benedict Arnold and walking on a bridge made of rare historical documents—a bridge which he himself made using a power like Iceman has—but with rare historical documents in place of ice.

I believe Diane Kruger is with him on these escapades.

I believe the quiver-like document case that he has slung over his shoulder, and which he often carries The Declaration of Independence in, except when he’s faking out Sean Bean’s character, is made from the hollowed out wooden leg of President Zachary Taylor. I believe that, at the time of his presidency, people suspected that Zachary Taylor had a wooden leg—but they said nothing, because it was possible he was using it to traffick state secrets and important rare and historical documents.

However, I believe that President Taylor NEVER COULD HAVE imagined that his leg would one day carry The Declaration of Independence. I believe this information would have been too much. I believe he would have turned away from his destiny and began a new quest to destroy the leg, in a misguided attempt to save The Declaration of Independence.

But I believe you can’t change the timeline. I believe everything happened as it should. I believe in the vindication of the Gates family. I believe Diane Kruger should have rightfully had the missing 1789 button for George Washington’s inauguration and that part of Nicolas Cage’s destiny was to help her complete the full set. It makes sense and I believe Diane Kruger collects masonic aprons as well.

I believe that they DID heat up the back of The Declaration of Independence together with their breath, though I believe Nicolas Cage’s breath accounted for more than two-thirds of that exhalatory heat. I believe that Diane Kruger’s breath was very hot as well, though, considering that it only took them one breath—and not even a particularly strong one at that—though not a bad one either—a good breath—a generous but not strengthful breath—just one breath to heat up the whole corner of The Declaration of Independence. I mean that’s pretty good!

I believe the “national treasure” referred to in the title of the film series is not The Declaration of Independence, nor is it The President of the United States, nor is it the sweet steampunk glasses of Benjamin Franklin—I believe it’s Nicolas Cage duh.

It was Christmas—and I binged on Piaget videos. And later that week, the grainy Seymour Papert documentaries where he has kids acting like robots in a field. Left! Left! LEFT! And I made several meals of Susan Engel’s essay on Curiosity. And then had it all dashed apart by Vygotsky.

Okay. Good. However—how should I teach? All this theory swimming around so impressively. What to actually say and do?

I was recommended The Educated Mind by Bret Victor at the 20 minute mark in a talk of his^[1]. Turns out this is truly a lovely book. It attempts to sum up all the theory. Everything from Plato to Piaget, Vygotsky to Carl Sagan. (Even devoting a hearty portion to irony—a virtue which never seems to get its due.) After half the book mulling over the theories, we move into practical discussion of how to materialize all of this lofty thinking into teaching our real classes. Much like the real classes I teach in one corner of an old brick elementary.

Now, it’s funny. At the same time that I find myself troubled with how to teach, I realize there is almost no other way to do this. As the King of Hearts said, “Begin at the beginning and go on till you come to the end: then stop.”

We recapitulate. We take a young one through the alphabet and all the numbers and symbols, the great novels and how to sketch with perspective and how to disassemble a frog—all that we once went through. We relive a history with them.

It is through this interiorization of historically determined and culturally organized ways of operating on information that the social nature of people comes to be their psychological nature as well.^[2]

This interiorization happens through understanding. Kieran Egan covers the many ways of understanding—he lists his five most crucial types—like Mythically, in which we deal with binary concepts and construct imaginary beings that dwell at the extremes. Romantically, in great stories that pretend to have some grand purpose. As well as Philosophic, Somatic and Ironic.

These are not mere gimmicks. We often rely, in small children, on their mythical understanding. We don’t need to explain Hansel and Gretel.

The narrator does not explicitly discuss and explain the concepts of opposition—in this case, security and fear. We presuppose that in some profound way children already know these concepts; the narrator is using their familiarity to make events in some distant forest at some distant time meaningful.^[3]

These early chapters on mythical and romantic understanding are wonderful. The mythical section studies the import of fairy tales and Peter Rabbit to toddlers; the romantic part studies both Herodotus and The Guinness Book of World Records, the appeal of high drama and human limits to adolescents. I found so many of his questions to be top notch.

[B]y far the most common learning principle urged on teachers is that children’s learning moves “from the known to the unknown,” and that, to engage their interest and make new knowledge meaningful, one must begin with something relevant to their everyday experience and connect the new knowledge to that. If this indeed is how children learn most effectively, one must wonder what does the fattest person who ever lived have to do with their everyday experience, or the most expensive postage stamp, or the longest beard?^[4]

So the theory isn’t too detached from practice. Find the extremes in the subject you’re teaching, the soul of it. Play to the bizarre and the novel. It’s not quite as simple as that, of course—leave room for a touch of irony.

By preserving the earlier kinds of understanding as much as possible, we may develop a kind of irony that enables its users to recognize validity in all perspectives, to believe all metanarratives, to accept all epistemological schemes, to give assent to every belief. […] we do have other pursuits than understanding, and for some of the more exotic amoong them magic will trump science.^[5]

Wow, this kind of thing has got to be a heresy in today’s society! The predominant notion today is that our goal is progress, our goal is a perfect truth and knowledge. To be brought back to Socrates and Nietzche—who suggested that the pursuit of truth is only driven by “wanting to be superior”^[6]—gives the feeling of an old great truth: that we are really just working with scraps of the universe here. Not the keys to ultimate truth that we pretend.

As a technology teacher, this helps remind me that maybe technology is more of a magical substance than it is a great medicine for society. A realization that cannot come quick enough now that our ideals about social media have been dispelled by the absence of the interpersonal advances we were promised. No, it was all just a trick of getting messages from here to there, not a new form of living.

The final chapters take apart how to structure actual lessons. He falters a bit here—I feel there aren’t quite enough good examples given. But he does give a few very good ones. Such as when he discusses teaching about the air around us in a mythical way.

All in all, though, very near five stars here. I read books not to agree with the authors, but to think. To mull over someone else’s thoughts, in order to find where mine stand. But this book very much influenced me. I know I will be staying close to it from now on.

---

1. The Humane Representation of Thought. ↩︎

2. Luria, A. R. (1979) The making of mind: A personal account of Soviet psychology. p. 45. ↩︎

3. Egan, Kieran. (1997) The Educated Mind: How Cognitive Tools Shape Our Understanding. p. 42. ↩︎

4. Ibid., p. 84. ↩︎

5. Ibid., p. 162 ↩︎

6. Nietzsche, Friedrich. (1968) The will to power. p. 249 ↩︎

OpenFL is good. It is pleasing. This we know. It makes computer programs. However, it is itself one of these programs. Gah! So it is actually very bad and frustrating! But oh how we love it still—we needn’t be primates.

Okay, let’s see how good it is with the new Xcode. This new Xcode 7 lets us sideload. Yes, it’s true. It lets us put our mobile programs into our mobile computers without anything special—without a premium account of any kind or any permission—as if we were now in control.

How it does this is by granting us little licenses through a plain, average Apple ID. We will need to tell Xcode about our account. And we will need to create these things called provisioning profiles for each one of our apps. And we will need to click the Fix Issue button many times. More to come on that.

For this, you must have OpenFL installed for Mac. Download the latest Haxe from that page and then run, in a Terminal:

$ haxelib install openfl
$ haxelib run openfl setup

Now, let’s get a sample going.

$ openfl create NyanCat iNyanCat
$ cd iNyanCat

OpenFL already has a number of sample programs—we’re copying the built-in NyanCat sample for our purposes. It’s true that Nyan Cat is not as funny as it used to be, but it is funny enough for Xcode to at least compile.

Edit the project.xml file in there.

<meta title="NyanCat" package="org.openfl.samples.nyancat" 
  version="1.0.0" company="OpenFL" />

Best to change the Bundle Identifier. (The package setting above.) This has to be globally unique (as in one-of-a-kind on all of planet Earth) so put something in that’s peculiar.

<meta title="NyanCat" package="com.kickscondor.nyancat" 
  version="1.0.0" company="OpenFL" />

I am also using the beta release of Xcode 7. So it was necessary to use xcode-select to point OpenFL in the right direction.

$ sudo xcode-select -s /Applications/Xcode-beta.app/Contents/Developer 

Right ok. Back to trying to get this thing to come up.

$ openfl test ios

The openfl test ios command will be very chatty—screens and screens for several minutes. It is making something for us.

⛺ Plug in the iPad or iPhone at this point. If this is your first time connecting it, tell it to Trust this computer.

Hold up.

=== BUILD TARGET NyanCat OF PROJECT NyanCat WITH CONFIGURATION Re
lease ===
Check dependencies
Code Sign error: No matching provisioning profiles found: No prov
isioning profiles with a valid signing identity (i.e. certificate
and private key pair) matching the bundle identifier “com.kicksco
ndor.nyancat” were found.
CodeSign error: code signing is required for product type 'Applic
ation' in SDK 'iOS 9.0'
** BUILD FAILED **
The following build commands failed:
        Check dependencies
        (1 failure)

It’s true—this thing it’s saying about the provisioning profile is true. We have no provisioning profile. This isn’t confusing. All error messages are repellant, so, no, you can’t look directly at it, but it’s speaking the truth to you.

Normally, if your program is in Apple’s store, you would go to Apple’s site to fix this. You would follow something like these steps. But we want to use Xcode 7 for this.

If you haven’t intuited this already, you must install Xcode 7.

Go into the Export/iOS folder under the iNyanCat folder. Open the iNyanCat.xcodeproj file.

Clicking on the bolded NyanCat project name on the left side of Xcode will show a page with this at the top:

And now we create the team profile. From the Team selector, choose Add an account… and enter your Apple ID credentials.

A Fix Issue button will appear. Press it.

You may also want to be aware of the Deployment Target area.

Sometimes upping the version on this will get you through problems.

At this point, you could just run the project from Xcode. (If you want to do that, just click on the arrow in the toolbar—the one that looks like a Play button—but be advised that it will take FOREVER to build.)

So, no, let’s not—let’s head back to the Terminal, as our build was almost complete when we had the provisioning profile problems.

$ openfl test ios

And it should appear on the iPad.

[ 60%] InspectingPackage
[ 60%] TakingInstallLock
[ 65%] PreflightingApplication
[ 65%] InstallingEmbeddedProfile
[ 70%] VerifyingApplication
[ 75%] CreatingContainer
[ 80%] InstallingApplication
[ 85%] PostflightingApplication
[ 90%] SandboxingApplication
[ 95%] GeneratingApplicationMap
[100%] Installed package /Users/kicks/Code/iNyanCat/Export/ios/bu
ild/Release-iphoneos/NyanCat.app

And So Now It Just Works?

Yes, so basically now you can just stick to the Terminal and rebuild your app without needing to do anything with Xcode again.

The only issue that arises is if you want to create another new app.

You will need to edit the project.xml and change the Bundle Identifier in the new project. It’s a different app, it needs its own Id.

You will need to load the xcodeproj file into Xcode and hit Fix Issue again. This will assign this Bundle Identifier to your account. It’s like reserving a spot with Apple.

And then you should be in business for that project.

Problems Unforeseen

I had my share of problems—I will now relive these with you.

First, this one.

[....] Waiting up to 5 seconds for iOS device to be connected
[....] Using (null) (679c2f770cab0a8d8dc691595a8799b6aee88ca0).
------- Install phase -----
[  0%] Found (null) connected through USB, beginning install
Assertion failed: (AMDeviceIsPaired(device)), function handle_
device, file ios-deploy.c, line 1500.

This means your iPad needs to trust. Unlock the iPad and you should see a popup: Trust this computer? Yes, please.

Next problem:

[ 60%] TakingInstallLock
[ 65%] PreflightingApplication
[ 65%] InstallingEmbeddedProfile
[ 70%] VerifyingApplication
AMDeviceInstallApplication failed: 0xE8008015: Your application
failed code-signing checks. Check your certificates, provisioning
profiles, and bundle ids.

I opened Xcode and discovered that the iPad Mini I had hooked up was listed as “ineligible.”

If your device is listed as “ineligible” then this means that the Xcode you’re using doesn’t include a Developer Disk Image for that specific version of iOS. In my case, I had 8.0.2 on the iPad Mini. What on earth causes a missing Developer Disk Image, though? Well, let’s see what’s included in my Xcode 7 installation:

$ ls /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS
.platform/DeviceSupport
6.0/            7.0/            8.1/            8.3/            Latest@
6.1/            7.1/            8.2/            9.0 (13A4280e)/

These are the versions I can sideload on to. As you can see, 8.0.2 is not present. The simplest way to solve this is for me to upgrade my iPad Mini to one of these versions.

You may also need to look for a newer Xcode release. I had problems with this because I had upgraded to iOS 8.4 on an iPad, but—as seen above—Xcode didn’t support iOS 8.4 yet. My device was ineligible because it was way too upgraded.

This problem also persisted when I hadn’t loaded symbol files onto the iPad Mini. Return to Xcode and load the xcodeproj file and ensure you can deploy to the device from there—once again, “Fix Issue” is your friend.

Here’s another one that plagued me for awhile.

[ 52%] CreatingStagingDirectory
[ 57%] ExtractingPackage
[ 60%] InspectingPackage
[ 60%] TakingInstallLock
[ 65%] PreflightingApplication
AMDeviceInstallApplication failed: -402653058

I tried upgrading the ios-deploy tool that comes with OpenFL. No good. I tried entering device information into the project.xml. Not that either.

I believe it went away when I started using Xcode to setup the provisioning profile. Xcode will connect to the device and put symbol files on it. You might try using Xcode’s arrow button (looks like a Play button on an audio player) and select your iPad in the area right next to the button. It will take a long time—but it only needs to happen once.

There also was this troublesome error that appeared while openfl test ios was running.

clang: error: -fembed-bitcode is not supported on versions of iOS
prior to 6.0

There are two possible solutions here. First, this is fixed in lime 2.4.8. So run haxelib list and ensure that lime is at least more recent than that. If not, run haxelib upgrade. 👈 Do this anyway—seems intellegent.

Second option is to simply open the XCode project and change the deployment target to (at least) iOS 6.0. (Bitcode enables the Apple Store to optimize your binary, at the cost of losing access to iOS 5.)

chmod: Unable to change file mode on /usr/lib/haxe/lib/lime/2,4,8
/templates/bin/ios-deploy: Operation not permitted
sh: /usr/lib/haxe/lib/lime/2,4,8/templates/bin/ios-deploy: Permis
sion denied

This one can be solved by manually making the file executable using sudo:

sudo chmod 0755 /usr/lib/haxe/lib/lime/2,4,8/templates/bin/ios-deploy

Mongo Bonus Mongo

I also had difficulties getting the MongoDB driver for Haxe going under iOS. It worked fine for local testing (openfl test neko) but not for the device. I got compiler errors.

I forked the driver and made some alterations. Try this.

$ haxelib git mongodb-kicks https://github.com/kickscondor/mongo-haxe-driver

Add then add to your project.xml:

<haxelib name="mongodb-kicks" />

It is nice little touches like this, such as being able to bring in forked code from Github, that make OpenFL such a pleasure—even when it’s in a somewhat crabby mood about having to move itself onto such a suffocating platform such as Apple’s.

⛺ UPDATE: Recent versions of Xcode (7.2, for example) have a few different error messages that I thought I would cover also.

------- Install phase -----
[  0%] Found XXX 'DeviceName' (...) connected through USB, beginning install
Assertion failed: (AMDeviceIsPaired(device)), function handle_device,
file ios-deploy.c, line 1500.

This one is a trust issue. Unlock your iPad or iPhone. You should see a dialog box asking if you want to trust this computer. Tap Trust.

You may also need to unplug the device and then plug it back in. This error can persist even after tapping Trust.

[ 65%] PreflightingApplication
[ 65%] InstallingEmbeddedProfile
[ 70%] VerifyingApplication
AMDeviceInstallApplication failed: 0xE8008016: Unknown error.

This is a code-signing issue. You want to use the Fix Issue button in Xcode. (See the And So Now It Just Works? section above for some instructions.)

Lastly, there’s a new popup on iOS that will block your app, with the title Untrusted Developer. The message continues: Your device management settings do not allow using apps from developer “iPhone Developer: [email protected] (XXXX)” on this iPad. You can allow using these apps in Settings.

The solution to this is in iOS Settings. Go to the Settings app. The General settings > tap Profile > tap [email protected] (or whatever the e-mail address was in the warning above.) Now trust [email protected]. And click Verify app. Go back to your app and it should run.