Vista SP1 sales video “rocks”?

<object width="425" height="355"> <param name="movie" value="http://www.youtube.com/v/sPv8PPl7ANU&hl=en"></param> <param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/sPv8PPl7ANU&hl=en" type="application/x-shockwave-flash" wmode="transparent" width="425" height="355"></embed></object>

I just don’t know what to make of this video… I guess Microsoft is trying to break the stigma around Vista as best they can (I don’t think this video is helping their case much).

Texas Instruments, my company, will not support upgrading to Vista across the entire corporation as was leaked to the inquirer back in late 06 to early 07. No Vista machines in sight here still (except in the testing labs). Everyone is running XP if they are using Windows, but you do see a lot of Mac’s running Leopard, or and few laptops running the latest Fedora, Ubuntu, SuSE, and OpenSolaris desktops for those of using in various development and engineering roles.

I’m sure TI would probably use Vista if Windows 7 isn’t out by the time that XP goes into legacy support status, but XP works and we don’t have any problems with it. We already bought our huge corporate level volume licenses for XP so I can see the logic into why really IT doesn’t want to upgrade more then 10,000 users machines here when there isn’t a significant gain (and more of a loss really) by doing so even still. Nothing in Vista (even in SP1) is really worth upgrading for.

Syndicated 2008-04-17 03:30:40 from Zac Bowling's Blog

iPhone developer program is a joke

The developer program is turning out to be bunch of hype for something stupid. The restrictions on what your application is allowed to do is total, laugh-out-loud, crap.

I was initially excited about the SDK and developer program for the iPhone. I was willing to live with Apple being only distributor of Apps and getting a cut of the profits. I was willing to live with an entrance criteria to get into the App Store.

But then I heard about the other restrictions, and if you haven’t heard yet about the restrictions placed on your applications, here are gritty details:

• “Applications may only use Published APIs in the manner prescribed by Apple and must not use or call any unpublished or private APIs.” (section 3.3.1 in the SDK license agreement) That means currently no access to IOKit
• “An Application may write data on a device only to the Application’s designated container area, except as otherwise specified by Apple.” (section 3.3.4 in the SDK license agreement). No full file system access basically.
• Your application is completely closed when the user leaves it like when they get a call or any of a number of actions happen. (specified in the Human Interface Guidelines). Only one application can run at a time basically so no background applications. (Something you can do in the current Open SDK)
• “An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and builtin interpreter(s).” (section 3.3.2 in the SDK Agreement)
• “If Your Application includes any FOSS, You agree to comply with all applicable FOSS licensing terms. You also agree not to use any FOSS in the development of Your Application in such a way that would cause the non-FOSS portions of the SDK to be subject
  to any FOSS licensing terms or obligations.” (section 3.3.14 in the SDK license agreement)
• No way to write plugins for the apps that exist on the phone right now, even for apps that openly support it plugins like Safari.
• Applications can be rejected for not meeting the Human Interface Guidelines
• No VoIP apps that work over cell network (that is acceptable, VoIP is a bandwidth hog and with unlimited data, it hurts the carrier)

Porting Firefox would be impossible because it supports downloading and running “interpreted code” with its Javascript engine. Things like Mono could only be used if you included a version Mono with your application, so basically no system wide install. No way to write a usable IM or IRC client on it, since apps can’t run in the background. Since we won’t be able to write plugins for existing apps like Safari, it means no Silverlight/Moonlight and no third party Flash support. IOKit isn’t in the list of document APIs even though its on the iPhone today, so no way to access the dock port to get to the PC or access the Bluetooth hardware. No way to tie into the data sync integration as well, so you can have it sync data with other things on your PC when docked.

What we get is so much more limited then what you can get natively in the unofficial Open SDK that is out there for the jail broke iPhones today. What annoys me is that Apple only played it off like their was only restrictions around application acceptance criteria for the application if was porn or a bandwidth hog. Not all this crap.

I think its idiotic of Apple to think this is what we were looking for. It’s pretty much a giant joke. I hope the public out cry about this is enough to knock Steve out of his black sweat-shirt and blue jeans, and have another wake up call.

Syndicated 2008-03-15 04:01:42 from Zac Bowling's Blog

T³ conference

Yesterday, I attended the first day of my company’s huge T&sup3; conference. It was something else and a little different then the software conferences that I’m used to attending. Nearly 3000 people there. So many teachers from around the world. It made me appreciated the reach our software and hardware has a bit more getting to see how large our customer base is. As a software developer, I think we sometimes get separated from our customers through so many layers, and for me it was great to get to meet so many of them. One part thing I love about our company is that we try to get everyone in just about every role out there to interact and listen to our customers. Everyone from software developers, QA testers, project managers, distribution, sales, marketing, customer service, product managers, HR, configuration management, hardware/electrical engineers, and just about everyone else in our division came out to help with the conference.

I also met up with the Vernier guys there, one of the members of the GNOME Mobile community, and I got to play with their new GNOME based LabQuest. The Vernier guys are awesome. I’ve enjoyed working with them in the past to make sure that our TI-Nspire product works with their Vernier EasyTemp®/Go!® Temp/Go!® Motion probes and sensors, so they can power the data collection features of our product. The Vernier guys are big Linux supporters which is nice to see.

Syndicated 2008-03-01 21:18:42 from Zac Bowling's Blog

Unit Testing

I’ve come across some really bad unit tests in a number of projects recently. I’m assuming that were written in the past only because someone said to the developers something like “Writting more unit tests improves code quality, so everyone write more unit tests!”. That was all the direction they got it seems (I’m assuming that from reading the code), and unfortunately, the developer and the leader wanting the developer to write unit tests wasn’t exactly sure why unit tests are important or how to write effective unit tests.

There are a few common goals that writing units help solve.

1. Unit tests provide an excellent facility for regression testing, in that help they allow programmers to easily refactor a piece code at a later date, and make sure that each module still works correctly.
2. Unit tests can be written to help simplify integration if you are working from the bottom-up in many cases. This goes well with really good planning around intergration points. In a large project you may need to separate everything out into smaller units or modules. All the pieces are probably going to developed concurrently by different developers and teams. If you write unit tests around your integration interfaces, you can flush out any issues before hand and move on to develop other pieces of the project, and that lessens the strain on your integration phases later.
3. Unit tests can also offer a form living document for others to understand how the code works and how they can use it or call it by providing a bunch of working examples. Since the unit tests are constantly being updated as code gets refactored they are usually more reliable then any static documentation which can drift and get out of date.

Another overlooked piece is when should you write unit tests. I know that in a lot of projects that I’ve worked on, the time developers would take to write their unit tests is usually delegated to the end or when they have any extra time. The unit tests usually end up the victim of procrastination and a lack of coverage usually causes more headaches later.

I believe unit tests should almost drive your development, especially when you are developing in an agile environment, defining features as you go and you are constantly refactoring your code.

Unit tests are great way of showing you where you have spaghetti code and complex environmental dependencies right away.

If you enforce unit tests on all business logic, you pretty much can enforce a clean separation of interface and implementation, and drive you code towards using better coding standards and patterns out of necessity to just be able to test your own code (like moving your code to a basic model/view/controllers pattern). It’s a great practice to get into for writing maintainable code.

You have to be smart about your unit tests though. More is not always better. You have to be practical and not walk about until you feel you have sufficiently covered everything. Anything that preforms any custom logic based on a specific input is a big candidate for a unit test. Sanity check unit tests are not usually necessary (such as writing a unit test around a property/setter-getter method that simply reads or writes to a field in a class).

One of my pet peeves is a test that knows the internals of a particular unit, not the function of that unit provides. You should pretend you don’t know how your code works internally, and write tests how other code is going to interact with it. The exception to that rule is if you know of ways that unit could easily break with specific inputs but stay within the confines of what that unit provides you. Do not write units tests that simply reconfirm that your code works exactly the way that you wrote it and would probably break if someone refactored the internals of that code.

For example, lets say I have a function called “SaveCustomer(String id, Customer customer)” that I know saves to a database underneath and another function called “LoadCustomer(String id)” that loads from that database underneath (the underlying database is not intended to be accessed directly except by the customer abstraction in this case). It would not be an effective test to write a test around SaveCustomer that calls the function and then connects to the database to see if its written, or similarly, write a test that calls LoadCustomer and checks to see if the data returned is the same as in the database. Rather a more effective test would be write a test creates a customer and attempts to store it using the SaveCustomer function and then tries to load it back out using the LoadCustomer function and verify the data in the customer objects survived round trip.

Another example that I ran into was a function called “getOffset” which was meant to return the internal position of where to read off an array returned by that same class. The previous programmer that wrote the function knew that the value would always return 16 at that time but made the function so that he didn’t have any magic numbers running his code and that he could change the value it returned to something different someday (or possibly even dynamically figuring its position at some point). However the programmer wrote a unit test to make sure it always returned 16 and sure enough when I went in and changed what the offset would was, the unit tests broke although no code did that called that function. Effectively the test was broke not the code.

It comes down to being smart and practical about your unit tests. There is no perfect setup. I try to shoot for a test around each public function and protected function (if intended to be inherited by other classes), and if applicable how the class is used as a whole (think living documentation or writing examples).

Some good candidates for unit tests are around that code that does logic in loops, contains switch statements (especially in languages that all statements to can fall through), any goto/jump statements, any regular expressions usage, any “auto-magical” features that happen at runtime, empty collections (non generic collections as well), null pointers, static position access on non-rigged arrays, and code that calls reflection features of your language.

In scripting/interpreted/dynamically typed languages, lots of sanity check tests are also more useful to attempt to test each code path possible. I wish you luck if you are writing a large application in one of these languages if you don’t have a strict coding standard and a whole bunch of tests.

Whatever you do, you can’t trust unit tests to be your only type of testing. Unit tests are not well suited for GUI testing and they can almost never do functional testing. Unit tests can only tell you if an error occurs in one particular case but not that couldn’t foresee to happen in many cases. Automated testing solutions depending on your project are really important as well in many cases.

Syndicated 2008-01-28 04:31:29 from Zac Bowling's Blog

Confessions of a Mono hacker

Mono is not just some copy of .NET. I hate that assumption. I fight it constantly. We are not helping the “.NET monopoly” (if there is such a thing). Mono isn’t out to kill Java as much as Python and Perl are out to kill Java. It’s not some massive conspiracy to infiltrate the OSS world like Stalman would like you to believe. Its just Mono. It’s a tool. While I don’t hate hate Java or Python as a platform, Mono is just better (not to mention that you can run Java and Python on top of Mono).

This is such old news, but it bears repeating. I’m not a fan of Windows (even though I develop for it and use it at work). I think Linux is the wave of the future. However Mono and what Microsoft has created doesn’t mean that it’s some how horrible thing that we can’t use on Linux.

“OOOOooooOOOO Microsoft created something cool. We surely can’t touch it because they had a hand in it. Microsoft must be the ultimate evil.”

Well if that is you or you complete agree with that statement, then you can go suck a lemon. Seriously. You need to get a life if you don’t have anything better but knock everything Microsoft does. Sure they have done somethings in the past that seem anti competive, but they have to protect their investors (if you really want something to do, go hit the FCC up on laws that can protect companies against crap and help them with trying to hit longer term goals for the greater good).

However, to Microsoft, all 70 something thousand of you: you have to know that you are public enemy number one in our world. There are zealots in the OSS world that want to see you die. While I don’t agree, I can empathize with their position. You will never win them over at this rate. There are more anti-Microsoft zealots then you have employees. The Port 25 guys are a good atempt but you need to expand the effort. Try thinking outside the box on this one. Way out side the box then normal. I mean giving up the source code to something you hold near and dear under no stipulations. Offer it up as your sacrificial lamb. Like Windows or .NET or SQL server or something like that. Give it up as Apache or BSD licensed. I guarantee that you will stop almost all the negative press you guys get. No silly Shared Source licensed. Get Slashdotted for changing the world.

Now Zune, Microsoft really needs to cut bait on and live with. Learn from it’s mistakes. That was a world class Gen Y screw up. No body has one of those that I know of. It’s a joke with my old buddies.

Syndicated 2007-11-30 03:09:15 from Zac Bowling's Blog