constructive nonconformist

Will Mobile Safari be the new IE?

Apple introduced the Macintosh in 1984 and in 2007 Apple introduced the iPhone. The case has been made that with the Macintosh, Apple squandered its technological lead by maximizing profits when it should have been maximizing market share. The $99 iPhone is why 2007 won’t be like 1984.

According to TUAW, Boingo Wireless reported that for January through May of 2009 “89.2% of all mobile devices accessing Boingo’s airport hotspots” were iPhones.

TUAW: iPhone dominates Boingo airport access study

John Gruber writes about “the heart of the revolution at hand”, that mobile devices like the iPhone will supplant portable devices like notebooks.

Daring Fireball: Meg Hourihan on the iPhone as a Computer

If I speculate that ‘mobile computing’ will become more ubiquitous (not a stretch) and that the iPhone platform is already dominating in that space (open to interpretation) and if I’m developing a web site that needs to reach the mobile computing based audience, then I need to support Mobile Safari. If mobile devices become the ‘hottest’ part of the market for computing hardware and the iPhone platform becomes unequivocally dominant then Safari will be the new Internet Explorer. (Lazy or incompetent developers There will be developers who through laziness or incompetence of their own or of others will write only to Safari — but I think, given that it’s a hardware company, Apple can be a better steward of the public interest in a robust and interoperable web.)

Mad speculation? Maybe. But Flash doesn’t make the short list of technologies I plan to continue investing time and resources in learning.

Observations on David Tucker's Observations

DavidTucker.net — Observations about Apple, the iPhone, PhoneGap, and the Flash Player

If you choose not to follow the link above, understand that David develops in Flash and AIR.

Observation #1 — Apple has proactively sought to eliminate any cross-platform development platform on the iPhone.

What David wants is to be able to develop once to Flash and target multiple platforms including the iPhone.

He also mentions PhoneGap and quotes a section from the iPhone SDK agreement that prohibits applications that install or launch other executable code and he links to an Ajaxian post about apps that have been rejected from the App Store because of their use of PhoneGap. But the PhoneGap site says the iPhone is supported and has a gallery of apps that are in the App Store.

It’s not clear that the PhoneGap approach is actually prohibited. As I understand it, PhoneGap wraps a WebKit shell around your code and I would think that WebKit qualifies as an Apple API or interpreter. Maybe it’s a loophole Apple would like to plug. Maybe the App Store rejections were based on a misunderstanding of what PhoneGap is. The PhoneGap situation seems unclear.

There is no doubt about Flash. Flash is unequivocally prohibited.

Observation #2 — The Flash Player hasn’t been approved because it is a threat to Apple’s App Store Revenue.

There has been much concern within the development community about the downward race in prices on the App Store. Some developers have expressed disappointment that Apple hasn’t taken steps to curb the downward pressure on prices. Yet in terms of prices Apple has been very laissez-faire.

Apple is a hardware company. The App Store could be a loss leader. I know it isn’t. But the primary purpose of the App Store is to sell iPhones, not apps.

Observation #3 — Apple is only interested in helping Mac developers.

By ‘Mac developers’ David means Mac and iPhone developers. He’s essentially restating observation 1.

I don’t expect a Windows version of Xcode any more than I expect a Mac OS X version of Visual Studio.

Since the iPhone was unveiled in January 2007 attendance at WWDC has risen dramatically because of an influx of iPhone developers. And there’s a growing trend of developers that started as iPhone developers moving into Mac development. It would seem that learning “Objective-C, Xcode, Interface Builder, Cocoa, etc…” is not a high barrier.

David says that performance and battery life issues with Flash on the iPhone are “just not true.” I see performance and stability issues with Flash in Safari on Mac OS X. If Abode is uninterested in resolving these issues on the ‘full-size’ OS why should I even imagine Flash is better on an iPhone? If David is right, Adobe isn’t helping themselves.

David concludes:

Why is [Flash] not approved? In reality – because of Apple’s revenue stream.

The revenue David is talking about is revenue from the App Store and revenue from developers. I think this conclusion is wrong.

Time for a little history. Once upon a time there was a small computer company named for a piece of fruit. It developed and marketed a wonderful new peripheral for its computers. It was called a laser printer. The laser printer created a new market segment known as desktop publishing. Part of the magic of the laser printer was a built-in interpreter for a specialized language. The language and its interpreter were developed by an even smaller company. The even smaller company was able to leverage its technology into a lingua franca and take a large piece of the desktop publishing market for itself.

Apple doesn’t want Flash on the iPhone because they don’t want to repeat the ‘mistake’ of PostScript on the LaserWriter.

So yes it is about revenue but not on the tactical scale of App Store revenue today; it’s about long term strategy.

Apple is supporting HTML 5 in Safari. It’s not about being against cross-platform development. It’s about not ceding control to another company. Everything critical in the stack must be either proprietary to Apple or be an open standard. That’s why there’s no Flash plugin and no Java VM on the iPhone. And I don’t expect there ever will be.

Software Professionalism

One of the few cogent points to have emerged form the recent spasm of interest in so-called Software Craftsmanship is the idea that a “craftsman” has a line that they will not cross, things that they will not do. I tend to agree.

— Keith Braithwaite
peripatetic axiom: Seduced by the drama?

It’s not the point of his piece (please read his whole post) but Keith makes a nice summation.

I consider myself a software professional. My professionalism includes my skills, experience, and judgement. My professionalism is one of my assets. It is not conferred by my employer. When I change positions or jobs, my professionalism stays with me. I’m accountable for the state of my professionalism as an asset of my personal self. It is in my self interest to improve and grow but also not to perform in a manner that is harmful, destructive, or unethical as a software professional.

What is constructive nonconformist?

When I graduated high school I was awarded the Anne Peters scholarship which is given

“to a graduating senior who intends to further his education and demonstrate the qualities of independent thought and activity that identify the constructive nonconformist.”

Raganwald and Obsession Times Voice

Daring Fireball - Obsession Times Voice
43 Folders - 43f Podcast: John Gruber & Merlin Mann’s Blogging Panel at SxSW

I continue to be inspired by Reg’s raganwald blog. Thank you Mr. Braithwaite. But Reg has moved on and is no longer actively posting to raganwald.

I miss his blog but if I’m serious about my own blog (and there’s doubt about that) then I’m glad my blog is not competing with an active raganwald (and I don’t compete with raganwald in any literal sense.) In the audio of Mann and Gruber’s talk, Merlin says something like your blog needs to be better than 80% of the other blogs that are focused on the same obsession. I recall Scott Adams, creator of Dilbert, writing that he greatly admired Gary Larson’s The Far Side and Bill Watterson’s Calvin and Hobbes and was consequently very glad when those strips ceased and ‘left the field.’

My blog, this blog, is not raganwald but like John Gruber’s New Yorker, it is a point of inspiration.

Now go read raganwald and see what you missed.

Software Design is not Quantitative

The most contentious point between software engineering culture and visual design culture is the question of whether important things can be always seen in absolutes. The engineering approach values measurable, reproducible results which can be represented in a graph or a checklist. Unit tests and benchmarks illustrate progress.

[…]

Visual design is often the polar opposite of engineering: trading hard edges for subjective decisions based on gut feelings and personal experiences. It’s messy, unpredictable, and notoriously hard to measure. The apparently erratic behavior of artists drives engineers bananas. Their decisions seem arbitrary and risk everything with no guaranteed benefit.

— Scott Stevenson
Theocacao: Measuring the Design Process
(writing about Doug Bowman’s stopdesign : Goodbye Google)

Software design is not data-driven engineering. Unit tests and benchmarks are about testing an implementation and certainly what’s learned needs to feed back into and inform the design but strictly speaking these are not design activities. There is a myriad of decisions in a software design that are made on qualitative grounds, not quantitative data. Maybe Google tries to make even those decisions driven by data. I’d like to know if it’s so. Most places I’ve worked there was someone with a bigger paycheck and the word ‘architect’ in his/her job title who was expected to pass judgement on the software design. Generally this person did so based on her/his skills, knowledge, and experience. A visual designer who’s aware of that may be all the more vexed when asked to defend the choice of pixel width for a border with data. Where’s the supporting data for the choice to use MVC? How come the debate over WS-* versus REST hasn’t been agreeably resolved with a graph?

If something is a ‘religious debate’, like choice of text editor or choice of programming language or choice of OS, does that mean it’s a question that is not (currently) answerable with data? Or does it mean there are different values and needs and experiences, qualitative things, that lead to different answers?

There’s all kinds of inexact unpredictable squishy messy issues, questions, and decisions that go into software development even without considering the visual interface. Scott is right on when he says:

Data and measurements are essential in software, and can take you a long way on their own. But feelings and instincts are necessary too if you want to do something remarkable.

The Only Way To Improve Software Is To Change It

One place I worked had a major release of their enterprise software and following the release a bug appeared. A serious bug. The business was not happy. The Director of Software Engineering was under pressure. The bug had never been reported before and the system processed a large volume of activity every day and had done so since the last major release six months ago. The Director was confident the bug was introduced with the new release. Because of the sense of urgency he didn’t wait for a full analysis. He made the decision to rollback to the prior version. But he was wrong. Rolling back didn’t fix the issue. The bug was pre-existing. It was unfortunate timing that the first time conditions were right to trigger the bug was the day after a major release.

People sometime refer to software as ‘hardening’ in Production. There’s a pervasive presumption that working Production software is generally safer and less risky than newly developed software. The idea is that the longer the software has been in use in Production without change the less likely it is to have unknown bugs. But hardening is a misnomer. Software doesn’t cure like concrete.

The assumption behind ‘hardening’ is that Production is the ultimate test. That the volume and variety of a Production environment is more comprehensive than any test regimen could be. But how good of a test is Production? What if 80% of typical Production activity exercises only 20% of the code? What happens when the unusual occurs? Many organizations test for load and scale issues but I don’t hear of organizations commonly measuring (or inferring) code coverage in Production. Could the unit tests and QA tests actually be more comprehensive than typical Production scenarios? Could ‘hardening’ represent an unsafe assumption?

A colleague pointed out there can also be an anthropomorphizing factor at work. Who do you trust more — the new recruit or the veteran? Even with known flaws the veteran can seem like a safer choice than the unknown recruit. “The devil you know is better than the devil you don’t.” But software releases are not people and you may not know the devil you know as well as you think you know it.

Program testing can be used to show the presence of bugs, but never to show their absence.

— Edsger W. Dijkstra

I once wrote the Dijkstra quote on a whiteboard as part of a presentation. The technical folk in the room nodded in recognition and agreement. The non-technical manager became agitated and vehemently disagreed.

To manage risk an organization working with the supposition that ‘hardened’ Production software is safer, may place strict controls on Production releases. Because of the effort involved in a release, releasing quarterly may be considered a fast schedule. Because of the amount of time between releases, each release tends to be large which increases the perceived risk.

If the potential for regression issues can be minimized (say through automated unit tests), which becomes the greater risk — introducing new bugs with a new release or not fixing latent bugs in the existing Production code? If the risk is in not releasing, than releases need to happen faster. Instead of quarterly what if releases were biweekly? The work would be chunked into smaller more frequent releases. Bugs which aren’t critical enough to require a special immediate fix could be fixed in production in 2 weeks instead of 3 months. The software could potentially adapt more quickly to changing needs and user feedback.

Build unit tests. Release often. The only way to improve software is to change it.

Hacking SLN Files to Improve Visual Studio/Visual Source Safe Integration

There are some who think Microsoft Visual Source Safe (VSS) is great. There are some who think that it’s not great but it is pretty good. And there are some who think Source Safe is just good enough. I am not among any of those groups.

One pain point with Source Safe in a Microsoft tool chain is integration with Visual Studio. Historically Visual Studio has stored source control information directly in the solution and project files. This reveals itself to be a really terrible idea the first time a project or solution file is shared in Source Safe. Checkouts from within the IDE will use the the source control bindings in the solution or project. If the solution or project file has been shared and not changed the bindings will be pointing to the original location in Source Safe. Checking out through Visual Studio will checkout the wrong file.

Yes, the solution and project files can be branched and the bindings updated. That’s sub-optimal. It means branching just to fix a tool problem and not because of any actual divergence in the code base. Any non-divergent changes to the solution or project must then be manually propagated to all the branched versions. Ugh.

The problem has not gone unnoticed at Microsoft. Over time and new releases of VStudio and VSS, improvements have been made.

My current position of employment is not using the latest and greatest. We’re on Visual Studio 2005 and Visual Source Safe 2005. The code base is in C#. I worked out a way to have shared solution and project files for non-web projects. Web projects in 2005 are different beasts and don’t follow the same rules. If you are using different versions of Visual Studio or Visual Source Safe your mileage will vary.

When getting files from VSS into a working directory, Visual Source Safe 2005 will create or update a mssccprj.scc file if any of the files present include a solution (.sln) or project file (for C#, .csproj). The mssccprj.scc file is a text file and it will contain the VSS bindings for the solution and project files that are in the same directory as the mssccprj.scc file.

In Visual Studio 2005, project files by default use the special ‘SAK’ string in the project file settings for VSS bindings. SAK indicates to Visual Studio that the bindings in the mssccprj.scc file should be used. The mssccprj.scc bindings are based on the directory retrieved from Source Safe. This means that shared project files just work. Yay.

In 2005 the problem is with solution files.

More specifically the problem is with solution files that include project files that are not in the same directory as the solution file. Creating a MyHelloWorld project will create a MyHelloWorld.sln and a MyHelloWorld.csproj in a MyHelloWorld directory. The .sln will reference the .csproj by name only and both files will have bindings in the mssccprj.scc file in the same directory and that all works without issue. But create a blank solution and add multiple existing projects to it and Visual Studio 2005 reverts to storing specific VSS bindings for the projects in the solution file.

There’s a work-around but it doesn’t work for parenting paths. Any time a solution references a project where the path to the project file starts with ‘..’, Visual Studio will revert to storing a VSS binding in the solution file. Because of this limitation it becomes convenient to have a convention that solution files generally go in the root of the code base tree.

The goal is to get the VSS bindings out of the solution file and have Visual Studio rely on the mssccprj.scc file. I haven’t found a reliable way to do this from within the IDE with existing projects but the solution (.sln) files are just text files, so I hack them.

Here’s a snippet from a .sln file. In Source Safe, the solution file is in “$/CodeBase v1”. There are two projects: a class library and a windows application. The SccProjectName<N> values are bindings to specific locations in the source safe repository. These are the bindings that need to be removed.

Global
	GlobalSection(SourceCodeControl) = preSolution
		SccNumberOfProjects = 3
		SccLocalPath0 = .
		SccProjectUniqueName1 = ClassLibrary1\\ClassLibrary1.csproj
		SccProjectName1 = \u0022$/CodeBase\u0020v1/ClassLibrary1\u0022,\u0020TAAAAAAA
		SccLocalPath1 = ClassLibrary1
		SccProjectUniqueName2 = WindowsApplication1\\WindowsApplication1.csproj
		SccProjectName2 = \u0022$/CodeBase\u0020v1/WindowsApplication1\u0022,\u0020WAAAAAAA
		SccLocalPath2 = WindowsApplication1
	EndGlobalSection

The .sln file can be edited to remove the SccProjectName<N> values but the SccLocalPath<N> must be updated to ‘.’ and a new property, SccProjectFilePathRelativizedFromConnection<N>, must be added with the old local path value and an appended directory separator.

Global
	GlobalSection(SourceCodeControl) = preSolution
		SccNumberOfProjects = 3
		SccLocalPath0 = .
		SccProjectUniqueName1 = ClassLibrary1\\ClassLibrary1.csproj
		SccLocalPath1 = .
		SccProjectFilePathRelativizedFromConnection1 = ClassLibrary1\\
		SccProjectUniqueName2 = WindowsApplication1\\WindowsApplication1.csproj
		SccLocalPath2 = .
		SccProjectFilePathRelativizedFromConnection2 = WindowsApplication1\\
	EndGlobalSection

Reference: Alin Constantin’s blog: The SAK source control strings in Visual Studio’s project files

Installing Git

This is a ‘note to self’ about Git and how to build and install on Mac OS X and how to install on Windows.

Building and Installing Git on Mac OS X (specifically 10.5 Leopard)

I haven’t been won over by Fink or MacPorts. There is the git-osx-installer project on Google Code which provides a DMG. But I’m comfortable with Makefiles and I have the Developer tools installed, so I build and install from the source.

Here are the steps I follow:

1. Get the ‘latest stable GIT release’ from http://git.or.cz/. As of this post the latest stable Git release was v1.6.1. Get the tar.bz2¹ file, for example: git-1.6.1.tar.bz2.
2. Unpack the tar file. I have a ~/Projects directory. In the Finder I typically move the tar file to ~/Projects and then double-click the tar. The Mac OS X 10.5 Archive Utility will handle the file. git-1.6.1.tar.bz2 will be unpacked into a directory named git-1.6.1.
   
   From the command line the tar command would be something like:
   tar xjf git-1.6.1.tar.bz2
3. I want to install Git to /usr/local. I also want to be able to easily mange new Git installs and Git has lots of parts so I create a subdirectory for Git in /usr/local.
   1. Create a directory in /usr/local for the Git release, for example:
      sudo mkdir /usr/local/git-1.6.1
   2. Create a subdirectory for the Git release man pages, for example:
      sudo mkdir /usr/local/git-1.6.1/man
   3. If this is the first install of Git on the machine, create a symbolic link to the release directory:
      sudo ln -s /usr/local/git-1.6.1 /usr/local/git
      
      Going forward, /usr/local/git should always link to the release you currently want to use.
   4. Add /usr/local/git/bin to your PATH.
   5. Add /usr/local/git/man to your MANPATH.
   
   
4. Change directory into the unpacked source code, for example:
   cd ~/Project/git-1.6.1
5. Configure the build. Set the prefix to the directory the release should be installed into. For example:
   make configure
./configure --prefix=/usr/local/git-1.6.1
6. Build Git.
   make
7. Install Git.
   sudo make install
8. Don’t bother building the man pages. Get the matching man pages tar from http://kernel.org/pub/software/scm/git/.
   

   For example: git-manpages-1.6.1.tar.bz2.
   

   From the command line, unpack the tar into the install location, for example:
   sudo tar xjf git-manpages-1.6.1.tar.bz2 -C /usr/local/git-1.6.1/man

9. If needed, update the /usr/local/git symbolic link.

Resources for Git on Mac OS X:

Compiling git on OS X Leopard — GitHub Guides — GitHub
Compiling Git for Mac OS X Leopard (10.5)
A Funkaoshi Production :: Building Git on Mac OS X

Windows

I don’t build from scratch on Windows. I’m currently trying out the msysgit package from Google Code.

¹The bzip2 compression is more efficient than the older gzip compression.

Empirical Challenges

… fundamentally empirical challenges cannot be addressed successfully in a traditional predictive or planned manner.

— from a description of “Scrum”

Related: Theory P: Software Development is Probabilistic