Ones and Zeros

I spend my working days analyzing, designing, writing, and testing software.  But I’m not a software programmer, I’m an engineer.  Just like a writer isn’t a typist, I’m not a programmer.  A writer’s job is to communicate effectively, not to type.  But typing on a keyboard is what a writer does when working. Programming is a tool I use in my job to create software, but the goal is to make the software to fit a given need.

Just don’t call me a programmer, my title is software engineer.  Just wanted to get that straight.

Most software people consider themselves either developers or perhaps programmers. I try to be an engineer. Some basic engineering principles are:

1. Each project should have a set of defined goals as it’s purpose. Ultimately, the success of the project is tied to how well it matches these goals.
2. Software should be replicatible and trackable. Source code control systems allow tracking of changes and regeneration of older versions.
3. Testing should be able to match the project’s features with the project’s goals or requirements.
4. A project should not use any more computing time and space resources than necessary to achieve those goals.
5. Projects should be documented at a architectural level and at a detailed level so that future software engineers will be able to takeover the project.

Practical realities of time, budget, and managerial pressures pull us away from on or more of these principles. I don’t live in a dream-world of engineering.  I’m in the same real world everyone else is with funding issues, project changes in midstream, and schedule overruns. But that shouldn’t keep us from remembering what the process is actually supposed to be and to work toward that process.

Neophila: The trait of being excited and pleased by novelty. Common among most hackers, SF fans, and members of several other connected leading-edge subcultures, including the pro-technology ‘Whole Earth’ wing of the ecology movement, space activists, many members of Mensa, and the Discordian/neo-pagangeek). All these groups overlap heavily and (where evidence is available) seem to share characteristic hacker tropisms for science fiction, music. The opposite tendency is neophobia.

- New Harper’s Dictionary (via Wikipedia)

Yup, I’m a neophile. But I’m also seasoned enough to know that the new - while exciting and intellectually interesting - isn’t always better. The question is to use the right tool for the job at hand. That may be the newest thing, but it may be the old and familiar too. This requires some assessment of quality of the tool for the task. Unfortunately this is a step often skipped in the software world.

For software engineering to become a real profession, we need to recognize the following:

[Engineering is] The profession in which a knowledge of the mathematical and natural sciences gained by study, experience, and practice is applied with judgment to develop ways to use economically the materials and forces of nature for the benefit of mankind.

- Wikidictionary on Engineering

Software engineering can’t just be using the coolest and newest things. Instead it is building software that satisfies goals in a measurable way, uses scientific and mathematic principles, and economically and efficiently uses those principles to benefit us as software users. Using the right tools at the right times is a key step in moving from software developers to software engineers.

As software geeks, we can experiment and test the new tools. That’s fine. But we need to draw a clear line between experimentation and research vs deliverable production software. Not all software is - or should be - production grade software. But for production software, an engineering approach is key. The software techniques and tools used need to be subservient to the goals of the project. It’s hard to remember that in the heat of writing code.

I’ve been working on an application for the iPhone but it’ll never be on the app store. Courses and reading are all good, but if you’re going to know how to build something you ultimately have to learn by building. So when I learn a new system I always make sample projects. This one comes from the Stanford iPhone applications course (via iTunesU) that I’m doing.

This application makes polygons with user-variable number of sides. A slider or buttons control the number of slides, other buttons control a dashed or solid line around the polygon. There are various other features for drawing and updating text, etc. (A screen capture of the app is to the right. )

An interesting extra item in this exercise was to allow the user to drag a finger on the polygon and rotate it. This is my thinking behind the software development for this one feature.

It took me a bit of reading and experimentation to figure out that the rotate operation (CGContextRotateCTM) always rotates around the origin of the UIView. In the iPhone the origin is the top left of the coordinate space. But I wanted to rotate the polygon around it’s center, not the orgin. I ended up doing this:

CGContextTranslateCTM(context, self.bounds.size.width/2, self.bounds.size.height/2);
CGContextRotateCTM(context, rotateAngle);
CGContextTranslateCTM(context, -self.bounds.size.width/2, -self.bounds.size.height/2);

This translates the center of the polygon to the coordinate space origin, rotates that space, then translates the polygon back to its starting location, but rotated now. There are other ways to do this transform and I’ll have to learn them at some point, but this seemed the best for now.

Figuring the angle to rotate was interesting too. First, I had to refresh my trig knowledge as I don’t use it much. I have several points: the center of the polygon, and the position that the user has their finger on. When I touch my finger to the polygon I get the “touchesBegan” event. Then when I drag my finger on the polygon, the app gets a series of new finger positions as “touchesMoved” events. When I lift my finger, the app gets the “touchesEnded” event. All the events have their location as a parameter.

Given these positions I needed to calculate the starting angle of the finger drag from the center of the polygon, and the successive angles as new events came in. The new angle of rotation (rotateAngle above) is the difference of those two calculated angles.

I used the right triangles as shown here in the square polygon to find the angles. The center of the square has the blue dot, the first event (”touchesBegan” event) locations is red, and the second is green (”touchesMoved” event). I used the formula of opposite side length/hypotenuse side length to find the sine, then used arcsine to find the actual angle.

Due the way I was calculating the angle, I had to adjust the sign of the angle value and it’s magnitude depending on the relative location of the center and the touch points. My calculation gave angles 0-90 degrees only. The triangle would be upright or upside down in the example here. Or it would be reversed if the touch point was to the left of the center. (All angle calculations were in radians though.)

In my code I’d be saving the cumulating angle of rotation, I initialized this to zero. The new angle of rotation was this old saved angle plus the difference of the two angles I’d calculated above. Then, I redrew the UIView to show the polygon rotated. When the “touchesEnded” event happens, then the old saved angle plus the current angle difference is saved as the new cumulative angle of rotation.

So now the polygon turns under my finger as if I were moving a real physical object mounted on a turntable.