Last week I wrote about how J wants to work for the NSA. This weekend, in the middle of the National Cyber League competition, he coded a bubble sort in C in an online IDE called JGrasp. But he ran into an error in his output that he could not figure out.
His array showed extra letters after the sort. I looked through the code and nothing jumped out at me as wrong.
Bing! I had a revelation.
“Do you know what a breakpoint is?” I asked.
He said, “No.”
“Do you know what a debugger is?” I asked.
“No,” he said.
I saw this opportunity and jumped on it. At the conclusion of our meeting I had J install Eclipse on his Windows 7 machine. He got a little stuck installing cygwin on his machine – windows 7 does not come with a c compiler. He had even more trouble setting the path in Eclipse to compile and debug from within the Eclipse IDE.
His shift was just about to end as he set the path to cygwin in Windows. We were not going to have enough time to debug in Eclipse. I pivoted and had him write hello world in notepad, he navigated to the directory on the command line and gcc’d the c file to an executable 5 minutes before his shift ended.
“We’re not going to have enough time to debug in Eclipse today.” I said. “Let’s wait until Wednesday to pick this up again. In the meantime, see what you can learn about setting the path to cygwin in Eclipse and let’s start debugging on Wednesday.”
He agreed and I got up and started walking back to my office.
As I walked I thought about how best to describe the process of debugging to someone who has not used a debugger before. I thought of Mr. Freeze in batman. He has a freeze gun right?
Then I thought of Frozone from the Pixar movie, The Incredibles.
Why am I thinking of these frozen characters so much?”
I thought to myself. Then it hit me. Debugging starts with a breakpoint. A breakpoint stops all program execution. Almost like freezing a bad guy, mid-bad. Or Frozone freezing the policeman in the bank to get away.
When we debug we freeze the program. But we’re not freezing to get away from something. We’re freezing the program so it doesn’t run 10,000,000/second. We can’t see the program run if it’s going so fast. So we leverage tools, like a debugger, to see exactly what the computer is thinking at the place in code that we set the breakpoint.
Looking forward to freezing J’s C program to investigate the internals and catch this bug that is ruining his output.
I remember the first time I stepped into a function. The superpower of forcing the computer to stop. I can’t wait to see his reaction when he learns that this is possible. Looking forward to Wednesday 🙂
Welp, I did it. I put my money where my mouth is. I signed up for meetup.com and created a new group. We’re called the Hawaii iOS Developer Meetup. We’re going to meet once a month at the beautiful hackerspace HICapacity in suite 132 at the Manoa Innovation Center.
I talked to my friend James at HICapacity. “James, I want to do a meetup at HICapacity.” He responded, “Cool!”
I created the meetup on meetup.com. I wasn’t sure exactly how to structure the meetup so I talked to my friend Nick, the host of the iPhone OS Weekly Developer Meetup San Francisco.
I loved the way he structured the meetup in San Francisco. He told me he was fine with me just using his framework. Reading over the manifest I am very happy with the trajectory of this endeavor.
Can’t wait to see what the turn out is like at the first meeting on Dec 1. If you’re in Hawaii and you’re interested in attending, please check out the event and register to attend.
Here’s the manifest for the Hawaii iOS Developer Meetup:
This group was created to provide a regular meetup for iOS developers actively working on projects. The purpose is to work together to support one another in bringing our ideas to life. The goals are also to meet people in the Honolulu, Hawaii area who are doing the same type of work (programming and creating apps for the iphone, ipad, and mac) and to have fun.
This meetup is for:
- iOS Developers of all levels.
- People who are interested in getting their hands dirty in code.
- People just starting to develop for iOS who do not have much experience.
- Developers on other platforms (Android, etc) who are interested in learning about iOS development.
- Developers looking for specific help in adding functionality to their app.
This meetup is NOT for:
- People interested in hiring a developer to work on their idea.
- Marketers wishing to sell a product / service to iOS developers.
The meeting format will be evolving and dynamic but as a starting point attendees should expect an opportunity to discuss:
- What he/she is working on
- What apps they have released
- What they’re interested in or what their specialty is
- What they want to get help on.
There may also be a speaker who presents a specific topic. But everyone will have the opportunity to share and ask questions. Afterwards, there will be non-structured time, during which attendees are free to pair off or have discussions in smaller groups. If you have one, bring your laptop and any iOS devices you have. I’m hoping this meetup will serve as a launching point for barn raising groups, where all members of the group in turn have the opportunity to utilize the rest of the group to develop an app. This will most likely be done separately from the formal meetup.
While the primary purpose is to support developers of iOS applications, there will also be events in which the topic of discussion will be other platforms such as android, however they will never be presented by direct stakeholders of the platform (in other words, no pimping allowed).
When we met in the Lava Lab, I had a chance to try out the Vive. Anna and Brian talked about how great the Vive was compared to the Oculus. So I put the headset on. Anna said, “Wait, you need to hold the controllers.” So I took the headset off, grabbed one controller in each hand, and I nudged the headset back over my head. Hold on, where are my hands?!
The image above shows what I initially saw. I have no hands!
I can’t see my hands in VR. This freaked me out. The controllers are there, I can move them, and they show where my fingers are pressing the touch controllers.
But I can’t see my hands!? I can’t see any of myself in VR.
The controllers are there in VR, but there is not a single trace of my physical body in VR. I get that it’s a virtual experience but this was shocking to me.
Contrasting VR to the Magic Leap technology of AR, I can’t help but feel like this is another way that the “humanity,” the humanness of a person, is not rendered in VR.
Only our actions are represented in VR. We are not.
I don’t exist in VR.
These serious considerations will come into play when are deciding how to use this technology and determining what to leverage going forward. I’ll be thinking about this experience for a long time. We are editing out humans in the realm of computers.
We have agency but we are only representations.
The other day I met with the MemoryDump crew at the Lava Lab. Anna and Brian are taking a high level elective that focuses on VR and the’ve had access to the new Oculus, Vive, and HoloLens all semester. I was eager to try out this new tech when we met in the lab.
I’ve been watching HoloLens developer videos on YouTube for a few months now. The way the HoloLens is marketed is kind of cringe-worthy. The experience of having it on is nothing like it’s advertised to be. Putting it on made me think, “This feels like a larger Google Glass – underwhelming.”
While the build and feel of the hardware is solid and top notch, the technology is lacking in the following ways:
- Frame of view, while considerably larger than the Google Glass was limited and kind of lame.
- The touch features require you to be looking at the object you wish to interact with.
- When you pull windows to place them in 3D space, they aren’t as precise as I want them to be.
In order for the HoloLens to succeed, it needs to offer at least 180 degrees in the field of vision.