A Microsoft employee (and former Danger employee) on development of Microsoft KIN, in The KIN-fusing KIN-clusion to KIN, and FY11 Microsoft Layoff Rumors [via rit]
Bruce Schneier, Should the Government Stop Outsourcing Code Development?
Jesse Vincent, on choice of source code management system
NY Times: “From New Jersey to Ohio to Arizona, the stadiums were sold as a key to redevelopment and as the only way to retain sports franchises. But the deals that were used to persuade taxpayers to finance their construction have in many cases backfired, the result of overly optimistic revenue assumptions and the recession.” [via Streetsblog]
Andy Hunt, Pragmatic Thinking & Learning (p 67)
Zed Shaw, The Master, The Expert, The Programmer
I was getting an error during development stating that I could not run my app on my iPhone because the executable “doesn’t have the provisioning profile with which the application was signed. Please add the provisioning profile via the Organizer or check the ‘Code Signing Identity’ build setting.”
I found this blog entry detailing a solution to the problem, but that did not work for me. Fortunately, the solution described in one of the comments did work for me. It involves editing the XCode project file in a text editor. This is the second time I have had to edit the project file to fix a problem.
Bruce Schneier, in Imagining Threats, referencing Magne Jørgense’s paper More Risk Analysis Can Lead to Increased Over-Optimism and Over-Confidence
Matt Wilson: “From a salesman’s perspective, you don’t close deals by acknowledging why the prospect doesn’t need what you’re selling. You close deals by overcoming objections. The salesman’s natural instinct is to see an obstacle and wear it down. So the key is not to feed that. Instead, stonewall them. Over time, they’ll respect you more because of it.”
Scott Berkun, Why requirements stink
I recently needed to display a link (blue, underlined text which, when clicked, launches MobileSafari) on a “settings” screen of an iPhone app which I am working on. It turns out that the way to do it that made the most sense was to use a UIWebView. I ran into a problem where the background of the UIWebView was always white, so in it did not fit in with the rest of the screen’s blue-gray, lightly striped iPhone standard background.
I ran across a number of posts which noted that a UIWebView could be made to have a transparent background by programatically setting the backgroundColor to clearColor and, in the HTML, setting the background-color to transparent via CSS. Doing this did not produce a transparent UIWebView background for me, and several posters noted that it failed for them, too, with iPhone SDK 2.2.
What did get things working for me was to make sure the UIWebView was not opaque. This was only mentioned in one older forum post I found, so I thought it might be useful echo it here.
To summarize:
theWebView.opaque = NO;
theWebView.backgroundColor = [UIColor clearColor];
[theWebView loadHTMLString:@"<html><body style=\"background-color: transparent\">...</body></html>" baseURL:nil];
Working on some iPhone code, it took a while for me to get Proxy Objects (aside from the standard File’s Owner) working correctly. In hopes of helping others, here is what I needed to do.
First, I wanted put some controls in a different NIB file from the one with the objects that deal with actions the controls send. The way to handle this is to put Proxy Objects in the new NIB that respond to the actions, rather than creating new instances of the objects by just inserting an aribtrary object in the NIB.
To get the proxy objects working on the code side of things, the documentation says to call loadNibNamed:owner:options: with an NSDictionary argument to options: which contains a key called UINibProxiedObjectsKey and, as a value, another NSDictionary with the actual objects that correspond to the proxies. The docs say the second NSDictionary should have keys of the Proxy Objects’ assigned Names in Interface Builder and values of the actual objects. I kept seeing EXEC_BAD_ACCESS errors when attempting this.
As this very helpful thread on the Apple developer discussion boards notes, the second NSDictionary needs keys with each Proxy Object’s assigned Identifier in Interface Builder, not the Name. Assigning Identifiers in Interface builder which corresponded to the keys in the second NSDictionary worked for me and eliminated the errors.
