Jesse Ezell Blog

iPhone SDK

Jesse Ezell — Sun, 06 Jul 2008 23:48:00 GMT

Been playing a bit with the iPhone SDK lately. Fortunately, I bought a MacBook Pro a few months ago (with default boot to Vista since I rarely ever boot into OS X). If I could pick one word to describe the experience it would be "different." The whole Apple/Jobs culture even leaks into the developer platform. They really couldn't just pick a name like "Object" for example as the base class for various objects. Instead, they had to make it NSObject. Why the NS? It stands for Next-Step--which, as you may know, is the OS that Jobs worked on during his time away from Apple. On top of that, you can't just write an application for the iPhone. You have to get on a waiting list and be approved first. That takes about 6 months or so, after which you still don't have any promise that your app can get loaded on any iPhones. After you finish your app, you then have to submit it to Apple, who decides whether or not they want it on their iPhones. That's a hell of a lot of work to do before getting a yes / no answer (not to mention that even if you do get the app in the store, a cut of every sale goes to Apple).

While listening to the developer tutorial videos, I cracked up when they got into the discussion of naming conventions. Yeah, naming conventions are a good thing, but I almost fell off my chair when the official developer training video from Apple stated that if you don't follow their naming conventions, "your whole application will come crashing down around you." The other thing I found quite strange about the videos was that they seemed a lot more like marketing material than developer training. It took a few videos before any code showed up, and then it was useless snippets that you couldn't actually compile because there was a lot of missing glue code. They probably would have made a bit more sense had I known Objective C and been familiar with OS X development going in, but they struck me as pretty useless videos and I abandoned them as a source of information.

Back to the SDK itself... The SDK uses Objective C, which is quite a bit different than C++ and has a fairly steep learning curve IMO. Definitely not like jumping to C# from C++ or Java from C++. Technically, you can compile C++ with X-Code (the IDE), but you really want to stick with Objective C, since that is what all the libraries use. The IDE itself doesn't have intellisense. It will autocomplete, but only when you've typed enough of the method to narrow it down to a single method. It really makes you miss Visual Studio, where you can just hit "." and browse for the exact method you are looking for. The consequence is that you have to have a much better understanding of the libraries you are working with to be at all productive. There is a "class browser" to go find methods, but it is more like a treeview control plus notepad. You find the class you are interested in and it pops up the header file in a pane so you can browse it. The interface isn't tabbed like Visual Studio, so you'll quickly find yourself wishing you had one or two of those nice big 30" monitors. On the plus side, the IDE is really snappy. Much smoother than Visual Studio...but then again, it seems like it's doing a hell of a lot less in the background.

The UI libraries are strictly MVC. You have no other good option. Either you write MVC, or you go home. As far as I could tell, the interface builder doesn't really store the interface in a useful form. Early on, I tried to drag some buttons around and then go look at what it generated; but, as far as I could tell, the IDE appears to put the UI in some kind of resource file instead of generating something you can hand modify later.

My overall impression is that iPhone development is a bit on the painful side. Unlike the Microsoft tools, you don't really have a lot of options. Apple chooses the "best" option for you and you do things that way. Though there is some merit to this idea (some times Microsoft gives you a lot of rope to hang yourself with), I like having options. Honestly, I don't think most developers could get up and running with the SDK in a weekend and it's a lot to ask to have people pour a lot of effort into an application without knowing whether it will actually be accepted.

Anyway, it's really too bad Windows Mobile blows, because if Microsoft had a decent mobile phone OS, they would win hands down in the tooling department. Cross your fingers. Maybe Silverlight will make iPhone development less of a pain.

Indisposable: WCF Gotcha #1

Jesse Ezell — Thu, 03 Jul 2008 03:44:00 GMT

When you have the code behind the service ready to go, you deploy it to the server of your choice and are ready to call the service. At this point, you will most likely do one of two things to consume the service: Create a ChannelFactory and reuse your interface, or use the "Add Service Reference..." option inside Visual Studio. Either way you go, you will almost certainly get the next part wrong... even if you know your shit when it comes to the rest of the .NET framework... [1]

[1] http://www.iserviceoriented.com/blog/post/Indisposable+-+WCF+Gotcha+1.aspx

iServiceOriented.com

Jesse Ezell — Wed, 02 Jul 2008 01:48:00 GMT

I'm starting up a new blog / website over at www.iserviceoriented.com. If you are considering transitioning over to a service oriented architecture, I'll help you make the jump. I don't have an ESB to sell or a product to muddy up the conversation with, just some practical advice to get you started.

Here's a little snippet:

double Add(double x, double y) { return x+y; }

If you don't understand the above block of code you are in over your head. Stop reading. Google was not your friend today. If, however, you do understand the above block of code, this is where our discussion shall begin.

At a basic level, a service oriented architecture allows you to take code and place it on another machine. Actually, I just made a gross oversimplification. Service oriented architecture helps you do this, but the key is that it reduces the chance of everything blowing up in your face.

Take a look back at the code block up top. It's time to lay some groundwork. Quite a few web service introductions start by turning this block of code into a web service. In ASP.NET, this was as simple as adding an attribute:

[WebMethod] double Add(double x, double y) { return x+y; }

Boom! You're done! At least in theory...

[1] Continued at: http://www.iserviceoriented.com/blog/post/Introduction+to+Service+Oriented+Architecture.aspx

.NET 3.5 SP1 / Visual Studio 2008 SP1 Details

Jesse Ezell — Wed, 09 Apr 2008 20:22:00 GMT

"It's settled! The Entity Framework (and the Entity Designer) along with ADO.NET Data Services will RTM as part of the Visual Studio 2008 and .NET 3.5 SP1 releases!

Unfortunately, we don't have official release dates at this point, but stay tuned. You'll also want to keep an eye out for the upcoming SP1 Beta 1, which will be your next chance to check out updated bits for both of these products.

Elisa Flasko
Program Manager, Data Programmability"

[1] http://blogs.msdn.com/adonet/archive/2008/04/09/entity-framework-ado-net-data-services-to-ship-with-vs-2008-sp1-net-3-5-sp1.aspx

Flash Lite on Windows Mobile

Jesse Ezell — Mon, 17 Mar 2008 18:43:00 GMT

Lots of people are pointing to the release of Flash "Light" on Windows Mobile by Microsoft and claiming that this is to "hold people over" until Silverlight gets here. That is just utter BS. Who the hell has ever used a Flash Light site on their phone? Hell, who really uses Windows Mobile to do any web surfing? Come to think of it, I don't think I've ever used a Flash "Light" site. Ever. From ANY device. This is certainly not something that is happening because users are demanding it and it sure isn't going to sell any more phones. More likely, this is a reflection of two things. First, Microsoft under Ozzie is making it a higher priority to support other people's products. Second, this could help limit the chances of another lawsuit over in EU land should Silverlight get big. By providing support for Flash "Light" well ahead of the Silverlight for mobile release, Microsoft is showing that it wants to win this fight fair and square.

[1] http://www.techcrunch.com/2008/03/17/microsoft-adopts-flash-lite-for-windows-mobile-as-a-stopgap-measure/

Silverlight on iPhone

Jesse Ezell — Thu, 06 Mar 2008 02:21:00 GMT

Jobs says Flash just doesn't cut the mustard and won't show up on the iPhone [1] [2].

Does that mean we will see Silverlight running on the iPhone first? There are some rumors... [3] [4]

[1] http://money.cnn.com/news/newsfeeds/articles/djf500/200803041742DOWJONESDJONLINE000829_FORTUNE5.htm

[2] http://www.appleinsider.com/articles/08/03/05/steve_jobs_pans_flash_on_the_iphone.html

[3] http://www.psynixis.com/blog/2008/03/05/scott-guthrie-hints-at-silverlight-on-iphone/

[4] http://www.techcrunch.com/2008/03/05/microsoft-mix-keynote-one-live-from-las-vegas/

Silverlight and N Tier Architecture

Jesse Ezell — Tue, 04 Mar 2008 18:00:00 GMT

Ryan van der Kooy asks:

"I've been beginning to try to find out how a good architecture will work using silverlight 2.0. I've read that Silverlight 2.0 could possible offer a 6 tier design. However, having a bll in your silverlight app could possibly be exposed by anyone decompiling dlls in the client bin. Is this true?

I've also thought about how Business Objects will work in an app when they would (for the most part) be built, then serialized to be passed through a webservice. Perhaps i'm looking waaaayy to deep into it. Perhaps a simple client/server model will be best for a silverlight app? DAL connected directed Silverlight through a webservice? "

Sliverlight 2.0 applications should be "service oriented" applications. The fact that an application calls a web service does not make it service oriented. You should never have a business logic dll in a Silverlight application. Instead, expose business services on your web server. Business services expose the logical operations that your application is capable of performing... remember, the logical operations, not the physical operations (ie. PlaceOrder, not CreateOrder). These operations many times contain many physical operations like Create Order, Create Line Item, Send Confirmation Email, etc., but leave these details to your service. Generally, this will mean that your clients are telling you what to do, but not how to do it. By not having your application explicitly request that each minor step in the order placement process is performed, you are free to make fairly large changes in how you process orders without updating the client.

[1] http://weblogs.asp.net/rvanderkooy/archive/2008/03/04/silverlight-n-tier-architecture.aspx

Silverlight for Symbian

Jesse Ezell — Tue, 04 Mar 2008 15:01:00 GMT

"The two companies on Tuesday at Microsoft's Mix '08 conference are scheduled to announce that Microsoft will write a version of Silverlight for Nokia's Series 60 (S60) smartphone software that runs on Symbian OS. The software, which will be available later this year, will also run on Series 40 devices and Nokia Internet tablets. "

One more step toward the demise of Flash ;)

[1] http://www.news.com/8301-10784_3-9884398-7.html?part=rss&subj=news&tag=2547-1_3-0-5

Cue the Scoble Tears

Jesse Ezell — Fri, 29 Feb 2008 12:45:00 GMT

"Cue Scoble tears. This is one hell of a technology from Microsoft Research that I think will have a huge impact on how amateurs and hobbyists write music. The technology and software prototype is called MySong.

In a nutshell, the software records your singing (preferably in tune) through a microphone, and it systematically generates an instrumental accompaniment for your song. The quality is even comparable with a professional accompanist, not to mention the cost and time involved."

[1] http://www.istartedsomething.com/20080229/mysong-microsoft-research-singing-sound-a-lot-better/

Abstraction: A Condom for Your Code

Jesse Ezell — Wed, 27 Feb 2008 12:31:00 GMT

"Why should you put a 10 foot pole between yourself and technology?

Well, because Microsoft (or insert vendor of your choice here - they’re all equally guilty of this) tend to deprecate (as in kill) the technology they evangelised just last year/month/week.

Microsoft Sql Server Notification Services are the latest victim.

I hope you don’t have any application code tied to that technology." [1]

Here is yet another example of why you need proper abstraction. When designing your application's layers, expose as little of the implementation details as possible.

For example, if you are going to be using Windows Workflow Foundation to handle the workflows for a complicated system, that is fine... but try not to expose the workflow instance or activities directly to clients. If for some reason you need to ditch Workflow Foundation, you don't want to have to rewrite every component that utilizes workflow for it's operations. Instead of a method like this:

void ShipProduct(SequentialWorkflowActivity shipmentWorkflow);

Have a method like this:

void ShipProduct(IProductShipmentProvider shipmentProvider);

Behind the scenes, you might create a framework for handling these shipments using Windows Workflow Foundation, but keep the implementation details behind the scenes instead of exposing them to your callers. Then, not only are your clients protected, but your server code is protected as well. If at some point you decide that you really need to be using Biztalk for your workflow, you can start using Biztalk immediately for new implementations without rewriting all your current workflows first.

This also applies to communication with external systems. If you need to interact with an external system, provide a service that accepts data in a format that your system is familiar with, let the service implementation deal with mapping between your data structures and the external system's data structures. This way, you are free to roll out fixes to your communication or support for new systems without rolling out anything else.

[1] http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist

Using WCF endpoints with SQL Reporting Services

Jesse Ezell — Thu, 21 Feb 2008 12:39:00 GMT

Consuming WCF endpointpoints with SQL Reporting Services can be difficult. Most of this difficulty is for two reasons:

1) SQL Reporting Services XML and web services support is slightly better than a piece of crap.

2) Documentation for the XML query provider in SQL Reporting Services blows.

One of the big problems with SSRS is that you can't just point it to a WSDL document and have it generate a proxy. In fact, the way you use web service data is virtually the same as querying off a static XML document. However, it is possible to get the two working together. Here are the steps:

1) Expose your WCF service using BasicHttpBinding.

2) Select XML data source and enter the url of your service, ie. http://myserver.com/service.svc

3) Enter the XML for your query:

<Query>

</Parameters>

</Method>

<SoapAction>http://tempuri.org/MyService/MyMethod</SoapAction>

</Query>

4) Make sure your WCF proxy is set up properly to work with SSRS:

[MessageContract(IsWrapped=true)]
public class MyMethodRequest
{
[MessageBodyMember]
public string Param1;
}

[ServiceContract]
public interface MyService
{
[OperationContract]
MyMethodResponse MyMethod(MyMethodRequest request);
}

Notice a few things. First, you will want your request to be wrapped. By default, the method name in your SSRS query must match the class name of your request. If you want to change your wrapper name, that is ok, but make sure to keep the wrapper name / namespace in sync with the Method element in SSRS. If you specify a custom action on your OperationContract, make sure that the soap action matches that action.

If you get an error message when you try to connect, remember these two things:

1) The error dialog has a details button where you can drill down and get more detailed information about the error that occured on the server, rather than the generic useless error it gives you.

2) If the details on the error dialog aren't giving you enough information, enable message tracing on your WCF service. If you aren't familiar enough with the WS specs or WCF to know what is wrong with the communication, create a quick app that calls the service using WCF and then compare a trace between the SSRS call and your sample app.

As a final note, watch out for missing or extra trailing slashes in namespaces and make sure everything is cased properly. One missing or extra slash or one improperly cased character can hose the entire request.

XNA on Zune and X-Box Live

Jesse Ezell — Thu, 21 Feb 2008 12:12:00 GMT

Two pieces of news today in the "damn that's cool" category.

First, Microsoft has announced that you will now be able to use XNA to create games that run on Zune.

Second, XBox live will have a "XBox Live Community Games" section where you can upload your own games for purchase / download / etc.

Both of these are huge.

[1] http://blogs.msdn.com/johan/archive/2008/02/21/games-on-the-zune.aspx

[2] http://blogs.msdn.com/xna/archive/2008/02/20/announcing-xbox-live-community-games.aspx

WCF: Getting ServiceAuthorizationManager and IAuthorizationPolicy to Work Together Properly

Jesse Ezell — Fri, 08 Feb 2008 22:38:00 GMT

When using WCF, you may want to integrate your security model into your application using claim based security. At this point, you will come across ServiceAuthorizationManager, which is responsible for evaluating policy statements to determine if the user is authorized to perform the requested operation. There is an interface, IAuthorizationPolicy, which you can implement to add your own claims to be evaluated by your ServiceAuthorizationManager implementation... there is one problem with this approach: the documentation you will find will most likely tell you to override CheckAccess in ServiceAuthorizationManager. However, if you merely override CheckAccess as in most of the provided samples, you will never see the output of your IAuthorizationPolicy implementation. As it turns out, the default implementation of CheckAccess sets up your security context as expected, but overriding CheckAccess will prevent this setup code from happening. Instead, override CheckAccessCore and your Security Context will be set up properly (the default implementation of CheckAccess sets up the context and then calls CheckAccessCore), or call base.CheckAccess as the first line in your handler to ensure that the basic setup of the security context happens before your code executes. This will save you hours of frustration.

Why in the world Microsoft didn't just split this up into two distinct methods such as InitializeSecurityContext and CheckAccess is beyond me. Generally Microsoft does a great job of Framework design, but this case seems to be an exception.

Hard Code

Jesse Ezell — Thu, 31 Jan 2008 00:44:00 GMT

"The trouble is that qaulity and value are wrapped in perception. Even if we built a product that precisely matched the spec with zero bugs, customers and reviewers might still hate it. If it doesn't work the way they think it should, it's junk. If it doesn't solve the problem the way they expect, it's trash.

At the same time, I-Puke can produce a buggy piece of glorified plastic that crashes twice a day, and it will get showered with praise and command premium pricing just because it reminds people of their pet rocks. Life isn't fair. The markey isn't fair. And customers are fickle." [1]

Never forget that the most "flawless" code in the world can still fail to meet customer expectations. At the end of the day, your goal is to meet customer expectations, not to write "flawless" code. As important as clean code may be, spagetti code that meets customer expectations is far better than beautiful code that fails to do so.

[1] Hard Code by I.M. Right (Eric Brechner)

Silverlight Supercomputer

Jesse Ezell — Mon, 28 Jan 2008 23:18:00 GMT

Dan Fay pointed to an interesting article on CodeProject about building a grid computing framework that runs on Silverlight. The proposition is really interesting. Imagine someone like the folding at home (http://folding.stanford.edu/) project providing and embeddable Silverlight widget that people can place on their sites to help speed genetic research... or how about a little widget on your page that takes some of the load off of your server to help offset high traffic volumes? Just imagine how many teraflops a site like MySpace could output on a given day. Google could potentially use something like this to index the web or calculate page ranks via MapReduce and eliminate a large chunk of their server farm.

Pretty interesting possibilities here... the question is, what are the ethics of "stealing" bandwidth and CPU cycles from viewers?