Advogato blog for zbowling

Vista SP1 sales video “rocks”?

Thu, 17 Apr 2008 04:07:37 GMT

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.

iPhone developer program is a joke

Sat, 15 Mar 2008 04:07:39 GMT

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.

T³ conference

Sat, 1 Mar 2008 22:09:39 GMT

Yesterday, I attended the first day of my company’s huge T³ 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.

Unit Testing

Mon, 28 Jan 2008 05:07:00 GMT

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.

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.
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.
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.

Confessions of a Mono hacker

Fri, 30 Nov 2007 05:10:48 GMT

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.

Coke machies that take credit cards

Sun, 25 Nov 2007 09:06:53 GMT

What the hell is the world coming too. I found this in my local grocery store tonight. $1.50 + credit card interest is totally worth the convince of not having to handle a dollar bill.

Top 10 pages on Conservapedia

Thu, 22 Nov 2007 13:12:07 GMT

This is the best thing that I have seen all day! http://www.conservapedia.com/Special:Statistics. Not gay at all.

Phalanger on Mono (part 2)

Wed, 21 Nov 2007 22:09:30 GMT

I blogged earlier about getting Phalanger running on Mono and the missing feature missing being the native extension support because the bridge was written in Managed C++.

Well I came up with an all C# solution. It’s not close to being done, more just a proof concept. I’m not sure the willingness of the upstream with supporting this method because it probably means a lot more work to maintain this method then the managed C++ version. With the managed C++ version, its less complicated because at least you can reuse the headers from PHP to help out with all the function declarations, typedefs, macros, structs (that break ABI compatibility from sometimes from version to version), and the utilities it provides. With the all C# solution, it means reversing all those headers.

There are also a few typedefs in the headers that compile to two different sizes on 64bit platforms so I have to declare two versions of the same p/invoke call and use one or the other if the code is running on 32bit or 64bit.

The way the code works on the managed C++ side is that the code will iterate through all the plugin dynamic libraries. All the libraries have to expose a standardized set of common exports. The library will dlopen them (I’m using Unix terminology here, LoadLibrary on windows), use dlsym to get the function pointers for that library, store all the known function pointers in to a struct, and stick the struct on to an array where it holds references to all the extensions. (I’m way over simplifying what it does, as phalanger also does some neat isolation tricks by loading the extensions into a different memory spaces/processes to keep buggy extensions from crashing the process phalanger is running in).

This same type of doing “dlopen” and “dlsym” can be done from .NET natively using P/Invoke, but it requires some really cute System.Reflection.Emit code. (Cecil maybe able to help me here later for what I’m doing). Basically, it means I emit an class for each library on the native side, all of which inherit from a interface that matches the same method signatures of the exports I’m p/invoking in each lib. The class I emit each time is almost identical except for the given library name each of the p/invoke calls call out to. Poor mans dynamic p/invoke. This entire process can be at runtime, or done before hand, where I can generate assemblies or even exes that remote into a parent process for poor mans process isolation.

From there, in the managed C++ code will then do some “System.Reflection.Emit” of its own to generate a wrapper assembly around the functions provided by the php extension library. This is done using the reflection information provided by the extension to emit a similar call in the .NET side that proxies down to the extension. PHP has setter and getter methods, overloading, purely dynamic functions, well know functions, etc. Thankfully this managed C++ code converts to C# without to much trouble. Still have a lot of structs to rebuild.

In all, its about a 6 to 8 week project if I had the time. (which I don’t)

Phalanger on Mono

Mon, 19 Nov 2007 19:10:56 GMT

In my free time, I’ve been trying to get Phalanger working better on top of Mono. Phalanger is a PHP implementation for the CLI and ASP.NET. It runs like a champ with the basic features on top of Mono.

One of the greatest features, and also biggest missing feature with running Phalanger on Mono, is native support for PHP extensions. The extensions in PHP are basic dynamic libraries, exposing a common set of standard C exports. In Phalanager, they have written a wonderful bridge between them, but unfortunately for me though, this bridge is written in Managed C++ (icky) and does a lot of Win32 specific things. They are also doing a lot with named pipes and running things in separate memory spaces, and worst of all, a good portion of the managed C++ code is doing Reflection.Emit. No easy way to get around this it looks like. *sigh*

Apple no longer on the Java bandwagon

Sat, 3 Nov 2007 22:09:41 GMT

Apple seems to have given up with supporting Java on the desktop. They have really been pulling back hard on any desktop Java related technology.

It’s only on the desktop. Apple’s J2EE based WebObjects technology doesn’t look like its going anywhere for now (Apple’s store and .Mac server are still powered by it) but that is a server side technology that was created back in Job’s NeXT days which is included in Mac OS X Server.

Apple slipped and didn’t ship Java 6 with Leopard like they implied they would. They also pulled the developer previews of Java 6 from the Apple developer site. What is left for Java 5 support in Leopard is sadly broken around everything AWT and Swing related. Not that I’m horribly sad to see it going but years ago, Apple was excited about supporting Java. I remember claims that Mac OS X would become the platform for Java on the Desktop a few years ago at an Apple Developer Conference.

About a year and a half ago, Apple still supported Java bindings to Cocoa and Java was treated as a first class citizen in Xcode for developing Cocoa apps. That was depreciated, and Apple’s solution was to tell people to migrate to Swing instead and publish articles on the ADC on how to embed the JRE and use JNI with Cocoa and Objective-C code. Long ago, Apple had bindings for Quicktime that fell into depreciation in Jaguar. They also had bindings for other libraries but they are long since gone.

You also don’t see Java on the iPhone, which isn’t a huge surprise. Jobs was quoted as saying right before the iPhone’s release, “Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain.”

There has been a lot of talk about porting OpenJDK to the Mac, but I don’t really believe its worth the effort to take on that beast. Why not instead take the opportunity to embrace something already supported on Mac like Mono (or maybe Python) ?

Tag: Mono & .NET