Joel Hainley

I was building out some .NET based web services for a Flex project I’ve been working on and bumped up against something that gave me a bit of trouble. When you create a .NET Web Service there is a namespace attribute associated with the service. Here’s an example (in c#) :

namespace HelloWebService
{
[WebService(Namespace = "http://www.examplenamespace.com/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[ToolboxItem(false)]

public class Service1 : System.Web.Services.WebService
{

// implementation …

}

This value is required by .NET for a web service, or at the very least .NET gets VERY upset if this value is not set.

You will then need to let Flex know about this namespace in order to access the results. To do this you simply add the following lines to Flex:

private namespace lh = “http://www.examplenamespace.com/”;
use namespace lh;

Not much to it, but it can be a bit of a pain when you’re not aware of this. Flex doesn’t complain, it just gives you empty values when you try to access the values.

The first time I did some work with PHPUnit I was writing out tests in preparation for some refactoring. So I put together a bunch of tests for my utility classes, and pure logic classes etc, database access classes, etc. So everything was trucking along wonderfully, things are falling into place and then I run a test that tests some database stuff.

The application was setup with a configuration file that defined all of the database connection information, this file is included by the database library providing a single set of database routines to be shared by the application. Pretty standard stuff here. Perhaps in a nod to the rails/java crowds it could have been put in a non-code file and read in by the application but as far as I’m concerned that’s just personal preference. At some point you’ve got to have some configuration information somewhere and this works as well as anything.

So now that you know how things were setup, we’re back to the PHPUnit test…it bombed, failed, crashed, whatever. After digging into it a bit I discovered that PHPUnit has a problem with munging the global namespace when it runs. Things that are global variables can’t be pulled down into local scope because they don’t exist there anymore. I did some reading and found numerous complaints about this in the PHPUnit bug system, all of them closed with “this issue resolved” when the issue most assuredly had not been solved. I even found a conversation where one of the developers stated that it was not a bug, that the user simply needed to modify their code to work with PHPUnit. Huh? Modify the architecture of your code to work with a testing framework?!?

I spent some time thinking about this and I think it could be said that he’s right, but for the wrong reasons. First off, if this is a technical limitation of PHP then just say so and let it go. If it’s an implementation problem with PHPUnit then say so and try to put together plans to fix it. However, I think in this particular instance the problems that I was experiencing with PHPUnit could indicate a larger problem in my application.

Here’s how..One of the things that I hated when I first started using PHP was having to pull things out of the global namespace into the local namespace to use them. When PHP5 came out and the object model finally had a good amount of maturity I moved to utilizing classes for most of my code and this allowed me to start using the $this operator for accessing a lot of variables that I needed to deal with. In fact, the only place I was really using globals was in my library routines. After thinking about this for a bit I realized that it was much more convenient to wrap all of the configuration data into Singleton then I’d have a single object that I could use to get all data instead of having to pull in everything I needed one variable at a time.

It was at that moment that I realized if I had a singleton that housed all of the configuration data I could instantiate it in all of the routines where I needed to access configuration data and it would avoid the problems that PHPUnit had with the global namespace. When I looked in the todo’s for the configuration file there was an item at the top “Maybe I should turn this into a singleton”…two birds with one stone? Ten minutes of work and I had everything setup and ran my tests and “bingo” everything worked.

So in the end, modifying the way that configuration information is disseminated throughout the system by using a singleton has been “the right thing”. I had some heartache over the responses from the PHPUnit developers about the “solution” to the problem their users were having mostly because the solution involved a lot of extra crap with addressing the global namespace in a particular way. Using a singleton ended up providing the needed functionality, didn’t do anything retarded with variable access, and ended up making the application much cleaner to work with.

One of the things that you notice if you are around development/engineering teams enough is that there is normally the existing solution, and the “next iteration”. Much has been written about the “second system” phenomenon and all of the pitfalls and failures that have resulted by second system thinking. Today I just want to talk about the importance of maintenance work to the growth of a developer towards understanding the hard problems within their chosen problem domain.

It seems like maintenance programming is, according to some developers, the lowest form of development on the planet. If you’ve ever been on a team in the role of maintenance programmer you have probably noticed that it’s not considered “sexy” by most of the team. Everyone is glad that you’re the designated maintenance programmer because that means that they AREN’T. Everyone wants to be working on the second system where “things are cleaner”, “we’re using better technology”, etc.

I’ve never agreed with this mentality, and here’s a dirty little secret, I LIKE maintenance work. There are few things as challenging as debugging a problem in a system you haven’t designed and fixing the problem in such a way that you leave the code better than it was when you got there. Here’s another amazing benefit of maintenance development, you learn the system and you learn how other people think and approach problems. In a similar way that Rorschach and Perceptive Aptitude Tests work, code is a projective tests for the thought processes of the developer who wrote the code. The other amazing benefit of supporting an existing application is that within a VERY SHORT amount of time supporting an existing application, a new developer is going to learn the system backwards and forwards. The developer will end up having a very deep understanding of the problems inherent in the existing design from a very realistic standpoint.

See new development is easy, you’re just trying to hit the 80% mark. If you’re in development you know what I’m referring to. “80% of the functionality is solved by 20% of the work.”. I’m willing to argue that the real work involved in a new application is done after the application is in production, that’s when you start to work on the last 20% of the application.

Maintenance work ( debugging production problems, adding new features, etc ) is when you start to solve the really hard problems that were not seen, or deferred, by the team creating the application. You often have to be creative in how you quantify the problems you are seeing, and you have to be a bit of an artist in terms of how best to quickly and easily ascertain what the hell is going on. The great part though is that you start to see how the choices made during the implementation of the system impact your ability to respond to certain things. This is the reason that I think solution architects should be in the trenches writing code with everyone else. They need to understand the results of their decisions at a very fundamental level, and the only way to do that is to keep their head in the game.

The other great thing about doing maintenance development is how easy it is to measure your contributions to the team. It normally goes like this, Tuesday morning the big client calls, he has found a bug that needs to be resolved by Friday or else they are going to have to leave the team. Tuesday, just before lunch, a meeting is called, and bad pizza is ordered. You are brought into the meeting and asked how in the world this can be fixed before Friday. If you just built the application but haven’t spent time doing maintenance since it’s release, you’re going to have to look into the application and reacquaint yourself with how it works, and see what new things have been added since you last saw the code. However, if you’ve been doing the maintenance work you can speak with authority right there in that meeting about what it is going to take to deal with that issue, and with any luck it’s already something that you have thought needed to be dealt with and have an idea about the best approach to take. So you grab two extra cokes and the last box of pizza and go back to your desk and solve the problem, test it, get it through qa and into production. A specific measurable result for your efforts, and something that others will remember.

Obviously I love to do maintenance work, I am VERY often called by clients to deal with legacy situations. I can’t count the number of times that I have had a client call up and tell me that the only person who knows anything about the application has left and “they have a huge bug and he’s trying to charge them $400 / hr to deal with it”, or they “have fired their consultant and are now left with a huge mess on their hands and could you help us”. I love this work, it’s real, it’s necessary and it’s often challenging and interesting. If you need maintenance work done feel free to contact me, I’m always looking for chances to sharpen my debugging, and code-reading skills.

There’s no doubt that today web services are hot, all of the commercial platforms ( J2EE, .Net, etc ) have tools that make the development of web services very easy. There are also a bunch of tools that are out there that help people generate their WSDL’s and can generally ease all of the difficult parts of developing web services. The great thing is that with the release of PHP 5 we now have tools that allow us to quickly develop web services in PHP. The great thing about this is that you can stub out api’s and start to have different solutions speak easily among themselves, share business logic to languages and technologies that are “not native”.

Within this article I’m just going to hit some highlights about creating your own web services using SOAP and PHP. I will also provide a URL to a web service that I have written for people to fiddle around with their first SOAP client. Please note that I’m not providing an exhaustive example of all of the details of wsdl’s/SOAP and the like, this is the SOAP equivalent of a “hello world” program, but with parameter passing included since most “Hello Worlds” don’t have parameters passed into them. We’re going to be building a little service that will support 2 operations, rot13 of a supplied string, and the mirroring(reversing) of a supplied string. Nothing terribly fancy, but certainly more interesting than “hello world” .

You can see the WSDL for this service here . There isn’t much to note with the WSDL it is a simple service and I’m not trying to get too crazy here. So take a look at it and see if it makes sense, if not, try to compare it against the code samples below and see if you can determine how it all relates.

Now that we have the WSDL defined it’s time to build the SOAP server to support this WSDL. Here’s the full listing for the server :

Pretty easy to understand, you’ll notice that we are just defining the functions at the top, then once we have created the soap server using the WSDL we simply associate our php functions with the functions defined in the WSDL by passing the function name to the addFunction message of the newly created SOAP server. Note that we have turned off the caching of the WSDL, this is something you’ll wanna do while you’re developing. When you don’t do this and make changes to your WSDL and they never seem to take, it can get frustrating .

Ok with the server out of the way let’s turn our attention to the client. Here’s the listing for a simple client :

I’m sure you could write a fancier example, but it gets the point across. First, You turn off the WSDL caching on your client as well as the server. Then you create a new soap client using the wsdl. Then you just start calling methods that you defined in the server. That’s about all there is to it.

Note, I’m going to keep the Soap Server referenced in this article up for you all to use. Please feel free to use it for testing your clients as you’re getting up and running. Eventually you’ll wanna start using your own servers for more interesting things though

Last time I talked about setting up logging for your Flex applications using the debug version of the flash player and configuring it to write to a text file. This is can be useful for debugging, but it’s not always the most efficient route for quickly getting to the bottom of a problem within Flex. Thankfully there are a few other useful tools that we can utilize to help us in our debugging. One of these tools is a project put out by Google called ReflexUtil.

For this article I’m gonna be using Adobe Flex Builder 2 to describe the process for  setting up ReflexUtil in your project. It should be relatively obvious how to add this to your project if you’re building everything using the flex sdk for development, if not let me know and I’ll post a note here about setting it up.

The process for setting this up is really well documented on the ReflexUtil website but if you haven’t used third party libraries in your Flex projects before you might spin your wheels for a few minutes. So here’s a step by step for getting things setup :

1. Download the appropriate version of ReflexUtil library from google code – there are versions for Flex 2 and Flex 3 so make sure you get the latest version for whichever version of Flex you are running .
2. Unzip the file and place it in your libraries folder – I have a master directory for all of my libraries, 3rd party and custom libraries, and I drop them into subfolders of this folder so that I have everything in one place.
3. Open up your project in Flex Builder and add the library to your project. If you’ve not done this before you just go to Project->Properties in Flex Builder then click on “Flex Build Path” on the left, once there you click on the Library Path tab on the right hand side. Then click “Add SWC” then browse to the location of the file for version I have installed in the project it is called ReflexUtil2.swc . Once you select the project a bunch of options will be availble for how to link the library to your project etc. You can get more details on things over at the Adobe documentation page that describes how to use SWC files in your Flex project
4. Now open up the application’s MXML file
5. Add <reflexutil:ReflexUtil /> tag within the application tags. ( in XML speak : make it a child node of the application element )
6. Add the ReflexUtil namespace to the application tag by adding the following : xmlns:reflexutil=”net.kandov.reflexutil.*”
7. When you run your application right click on a control and you will see some new options in the pop-up menu. Links to the ReflexUtil homepage, Open Reflex util and an option to inspect the control that has focus, and perhaps options to inspect a few more controls.
8. Click on one of the Inspect options. This will bring up a dialog bog that allows you to drill down through what could be thought of as the Flex DOM and actually modify things at runtime, layouts, values, etc. It’s pretty impressive.

That’s about it, there’s a lot of things you can probably think of that this might be useful for in your own projects. The ability to get in and muck with the UI in this way is really convenient, instead of constantly incrementing layout parameters, then recompiling, checking, then tweaking again. You can now  just pop up your ui and make adjustments until you have it the way you like, then just make a note of your settings.  It might be kinda useful to modify ReflexUtil to have the ability to write out all parameters to the debug file so that you wouldn’t have to write things down, perhaps the developers will do this.

The only other thing that really comes to mind at the moment is that you probably would want to remove ReflexUtil from your project when you put your Flex application into production. The ability of users to muck with things could be catastrophic