odoenet

I was going to title this post TDD Porn, but it seemed inappropriate, still very fitting though.

Test-Driven Development is exactly what it says it is. You develop your project with the tests driving you in the desired direction. There’s tons of material on TDD out there, so I won’t cover too many details.

The screencasts offered by The Pragmatic Bookshelf are done by Mr. Kent Beck himself. Go read about him, he knows a thing or two about this kind of stuff.

A great message I got from the screencasts is that your tests should tell a story. You compose that narrative in steps, so as to not trip yourself up. Many times you are probably required to develop against a backend service or directly with a database. So that’s how the story starts. Hello Mr. Database, are you there? May I put something in you?

In this case, Mr. Beck is using Tokyo-Tyrant as the database for this example. By the way, my OCD kicked in 5 minutes into the first screencast and I fired up my Ubuntu server, and spent a good 30-45 minutes toying with installing Tokyo-Tyrant. As there is no debian package that I could find and if you are so inclined, follow these instructions which are good for TokyoCabinet and Tokyo-Tyrant. Or you could not worry about it and just watch the videos like a sensible person might.

Back to our regularly schedule ramblings. I have read a few of the TDD books out there and I try to be a good TDD’er in my Flex Projects, but I happen to be the type of person that does well with visual aids. I can do all the reading in the world, but something about reinforcing that reading by actually watching someone do it just makes it click. This is probably why pair-programming is such an effective tool (I should try it sometime if I ever meet another Flex developer in person and can trick… I mean convince them to show me how a pro does it). It also helps that although the tutorial is done in Java, the syntax is similar enough to Actionscript that I was pretty comfortable following along. If at first you’re wondering why in the video when tests are run, the video kind of fades, they are trying to highlight the JUnit results in the lower-left hand corner. I didn’t figure this out until the second screencast, but chances are you’re not as slow as I am.

Episode 1: Starter Tests , is a good intro to the adage of TTD, Red, Green, Refactor, which you get to see in action in the screencasts. You write out a test, it fails. You write just enough code to get the test to pass, then you refactor to remove that nasty code smell. For me, the snag is usually in writing a meaning full test. We get to see first-hand how a simple test of connecting and writing to a database clarifies the intent and drives the narrative of the story being told. I know I have some tests that just check to make sure a function accepted an argument, but I don’t test what happens when it does not. I think everyone can take something away from the first screencast alone, and it gets better with each installment.

Episode 2: Isolated Tests, this is where the motto of the game is leave the world in the same state as you found it. If you’re going to test against a database, it should look exactly the same after your test as it did before you test. After all, you’re going to ideally run your tests for every refactor, so you’d hate to get a nasty phone call from your DB administrator wondering why you populated the database with hundreds of entries of a testDEEZNUTZ value (never happened to me and you can’t prove it). In this video, Kent Beck gives a good demonstration of building on your current tests, refactoring out the naughty bits and you get to see a Java Class take shape, fully supported by those tests.

Episode 3: Big Feature is all about building some complex functionality by using TDD to break it down into fun size bites. You start to get some real meat in this screencast and see how Kent Beck handles building on top of tests and the logic behind his decisions.

Episode 4: Finishing is where we clean up the code and make it presentable. This is also where Kent Beck provides a review of previous screencasts. In the first half of the video you end up with a functional map for Tyrant. The last half of the video is a summary of the series and you get some great insight and tips from a pro point of view on design decisions. Pros always make it seem so easy.

Even if you’re familiar with TDD and have been using it in your projects, I think you’d probably still be able to find some gems of information in these screencasts. You might be able to pick up some tips from Kent Becks style (the guy’s got style) and I would even say there are some great tips in these videos on refactoring your code and cleaning it up.

If you’re new to TDD, you have to start somewhere and I think these videos would be a great starting point before diving into the written material that’s available out there. I’m a kid of the 80′s, I was raised on visual aids.

One of the best things about the videos is that you get the sense that it’s not just a scripted screencast. I’m sure Mr. Beck had an outline, but as he’s writing the tests and implementations you can tell he’s working through problems in his head and is probably crossing his fingers for a passing test as much as you might. This makes the videos very personable and you almost feel like you’re sitting in the chair next to him just trying to soak in the knowledge via proximity osmosis.

The screencast are available for a reasonable price as a package deal or separately, but why bother buying just one, gotta catch them all.

I’m going to try to use the next few blog posts to go over how I use the tools I’ve provided in the FlexMapTools toolbox I put up on github.

The first is the FMap component, which extends the ESRI Map component. This component started as a way to control the position of the ESRI logo in the application. In previous releases the ESRI Flex API and even the beta version of 2.0, the logo fit just perfectly in the layout of one of the main projects I am working on, but in the final 2.0 release it was moved slightly to fit in with the FlexViewer layout. Now, it’s easy enough to set the logo visibility to false, ESRI provides this out of the box, but I kind of like the look of the new logo. Being a little annoyed that this little bit in the API was catered to the FlexViewer rather than the other way around, I decided to just extend the Map component and move it myself.

Default logo position blocked by a toolbar in my application.

Logo position set to fit application layout.

ESRI was kind enough to give us access to a staticLayer Group component in the Map that is used to hold the navigation tool, scalebar and the logo. You could pretty much add what you want in here. So all FMap does is add a Number property called logoToBottom that will be used to position the logo.

That’s pretty simple.

The next thing I decided to do that is pretty common in a lot of applications was to display coordinates. The FMap component assumes you are working with the WebMercator coordinate system that is all the rage these days and also that you want to display normal WGS1984 coordinates, because you do not want a user filling out some permit paperwork using WebMercator coordinates, so be aware of this. If you would like to convert to a different coordinate system, you’re going to have to handle the math in your application. Sending them to a Geometry Service to process on a MouseMove event will bring your application to a crawl.

I add a showLatLong Boolean property the Map and check that in an override of createChildren.

Notice that the group has a styleName defaulted to “latLongText”. This allows you to set the style in your stylesheet. If you have not looked into really using css with your Flex 4 applications, you owe it to yourself to look some stuff up. I’ve gotten quite a bit of use out of it recently. This allows me to do something like this in my css.

Coordinates positioned under scalebar.

As you can see, css can be a valuable tool in drilling down into the components inside components to manipulate their styles. Remember all this sits in the actual FMap component and can be used from project to project. And because it extends the default Map component, it can be passed into any component/object/function that asks for the default Map component. This should include any widgets you might use in FlexViewer. I also add an eventListener to listen for the REMOVED_FROM_STAGE event, that will handle some cleanup by setting the stuff I added to null. It may be overkill, but I’ve gotten used to doing this when dealing with custom components.

If there are certain things I did in FMap that don’t fit your needs, you could always modify it to fit your project workflow. Maybe you want the logo somewhere else, add settings to modify the top/left/right properties of the logo and go nuts.

I’ll cover some of the other tools in the FlexMapTools toolbox in future postings and if you have any questions, suggestions, critiques, please feel free to share.

For a couple of years now, I have been working with the ESRI Flex API to build Flex Mapping applications at work. Over that time, I like to think I have learned quite about programming and Flex/Flash in general. I would consider myself an intermediate and I continue to learn more everyday (more like shoehorn it in my brain). Developer is not my title, but I do it anyway. I think it was in The Passionate Programmer or Pragmatic Thinking and Learning where I read that one of the tools to learn to program was to share your code and see what others have to say.

So aside from posting little snippets here and there, I decided to put portions of my library file of common tools I use to develop ESRI Flex Mapping applications on github as the FlexMapTools library.

I’ll continue to build on this library and hopefully improve my own skills as well as maybe assist some other developers with their projects. There are lots of other items I use not in the library yet, mostly because I think it still needs some cleaning up. I’m also hoping for some critique. I’m pretty much flying solo in my learning path when it comes to development, so I don’t really have a mentor. I just attempt to absorb knowledge via internet osmosis and following smart people on twitter.

One of the interesting features of Swiz 1.0 (still pre-release) is the ability to create custom metadata processors. To get more familiar with the idea, check this docs page. Note that some items from the docs has changed, such as you no longer extend MetadataProcessor, but extend BaseMetadataProcessor.

There is a Yahoo Finance Processor, a URLMapping Processor and even a MediateSignalProcessor. It all looked a bit in depth to me, I’m still what I would call an intermediate in my dev skills at this point, but I decided to take a crack at it.

Since most of what I do is based on the ESRI Flex API, I decided to try making a GeocodeProcessor. The idea is that you can set up a Processor that would act as your delegate to a geocoding service. This way, you could just move it around different projects using swiz and simplify the task. I pretty much just used the geocode example from the samples pages.

You can view an example here and I also put it on github here. By the way, my first github attempt, and I was quite lost for a bit. I’ll need to learn how to use it for future projects. As for the application, when you search for an address, click the Center Map button up top. This is a hurdle I’ll explain shortly.

First off, thank you to those who already created some custom processor examples. I would have been scratching my head for a while trying to find what works and what doesn’t. First, part of the need to do something like a Geocode Processor requires that you be able to send a new address request to get updated information. I thought of using the idea of copying objects from the Mediate tag that was used in the URLMapping processor, but I couldn’t figure out how to do that AND send an updated object back to the application.

I went a different route, and one that is probably not recommended and that was to make a public getter/setter in the GeocodeProcessor to hold the Address object that could be updated from my application. In my case, I added the object to my Swiz via binding as can be seen here. Then my processor would listen for changes on the object and run a new geocoding task as can be seen here.

As I mentioned before, I had an issue that required I add a Center to Map button. For the life of me, I could not figure out how to let the map know that an address had been added to the map. I’m sure this is just a matter of finding the proper events to listen to or maybe setting my Swiz initialization, but I couldn’t figure it out. I thought I should at least mention it.

I was actually a little surprised it worked, but also pretty happy with how simple the concept of using a custom processor is once you go through the process of writing one. For geogeek ESRI Flex devs, I can think of a couple of uses such as maybe a processor for creating a GraphicsLayer set that is commonly used in your organization or possible some other tasks. Like I said earlier, I’m still not completely happy with having a public variable on the processor that needs to be updated manually, but this was mostly just a proof of concept for me and a learning experience.

So if you’re interested in the idea of custom processors, I say give it a shot. Go grab your source for Swiz here. Now that I’ve done it once, I think I may like to try doing some more.

So, previously I had talked about using Swiz and AS3-Signals (Swignalz!). My example was crude and honestly, it was not good. Ben Clinkinbeard did a much better job of showing how easy it was to drop some AS3-Signals around with Swiz.

This past week, I have been tinkering around with a project that will be redone and figured out that if you create a named Bean for a regular Signal, you can then Inject/Autowire that Bean into any Signal in your application.

This turns out real nice because then all I have to do anywhere in my application is the following.

There’s no need to create a custom Signal in your application, even if you are going to dispatch a payload. No more signals folder for me. I’m not sure if there is a performance hit for not defining the type of Object that will be dispatched with your Signal, but so far this has turned out pretty well for me.

I threw together a quick example with source here. I’d also like to point out that Swiz 1.0 metadata Injecttion into view components is really nice and lets me do cool things like this.

That is so cool.

Recently I decided to take a crack at AS3 Signals. Robert Penner has done some really nice work putting signals together. AS3 Signals is basically meant to replace using custom events to dispatch your payload around. I’m not sure I’m entirely sold on the concept of introducing another API into my apps, but I was intrigued enough to give it a shot.

Some good resources of getting started with AS3 Signals is this video by John Lindquist. I don’t know about you, but I have found that these screencasts are a great way to get a grasp on an idea. There has also been some testing to show that Signals can actually be quicker that Events. This could appeal to you if you are writing a large application that could benefit from the increased performance.

As I see it, you would use Signals in place of creating custom events that would be dispatched to carry a payload. In trying out signals, I began to think of how much I might want a signal to do. Most examples I have seen treat them as value objects, but I suppose you could turn them into full blow mini-controllers. One area I might try playing with signals is in processing raw data from a service into something the rest of my application could use.

Joel Hooks already  put together a cool AS3 Signals/Robotlegs example that showed how you could leverage Signals with Robotlegs. So I figured, hey, I’m going to try Signals with Swiz.  I haven’t really tackled Swiz in a while as my current project uses RobotLegs, but with Swiz 1.0 Alpha out and 1.0 beta coming up, I thought I’d give it a shot as I anticipate using Swiz 1.0 in a couple of upcoming projects. I tried some stuff out in the available examples and then put together a small demo app.

Application

Source

It’s not a pretty example, but it shows a couple of ways that you can treat signals in your application.

I use a couple of value objects with signals in my application model. This way, I can Autowire (the Inject tag is supported in the latest builds, but I already had this alpha build on hand) my model into my controller and assign the listeners that way. With this method, you have the ability to keep your listeners private, which some people might find appealing. A disadvantage here is that some people might not like tying the controller in this manner. I haven’t tried unit testing a controller like this yet, so I’m not sure if it would pose a problem.

Another method is to drop a value object with a signal directly into my BeanProvider and assign a function from a Controller as the listener when you initialize the Bean. The rest is pretty simple, I added some comments where I thought they’d be useful.

Swiz 1.0 offers some cool new features like custom metadata processors and virtual beans, which may be able to manage signals is a more efficient manner, but I have not had the opportunity to dive into that much detail in Swiz to be comfortable saying if it would work or not. As for my opinion of Signals, I’m not sure I’m entirely sold yet, but as I built the example, I began to think of the possibilities of mapping them out with a decorator pattern or similar. The fact that it got me thinking about it seems like a good sign. I’m always a little hesitant to add APIs to my applications, but when it comes to being used in the context of the framework of my application, I think I’d be a bit more comfortable. I expect I’ll take AS3 Signals for a test drive in the near future.

Recently, I have been using Swiz on a couple of smaller projects that are in the works. Swiz is a great little framework that is incredibly light weight. You can see some great examples using Swiz as well as some good discussion in the google groups. I am still using 0.6.4, but the 1.0 alpha is out and offers a new direction for Swiz, especially one that I welcomes that eliminates the need to instantiate Swiz. As I understand it, you just need your Beans and SwizConfig. All other code can be written with the simple use of metadata tags, that Swiz 1.0 alpha will also be offering some neat features.

So as I was working on some items, I remembered a 20-minute Swiz video that Joe Rinheart had posted that helped me out when I first started looking at Swiz. In that video, as a shortcut, Joe had simply binded a service to a delegate inside his BeanLoader to eliminate the need to Autowire an object in a Delegate. This got me thinking about the need to use Autowire with the metadata tag in my applications. When you Autowire an object using Swiz, the object has to be public anyway. The BeanLoader is already an IoC container. So why use it? After I had read Clean Code, I began to look at keeping my code as minimal as possible to get the job done. Although, an Autowire metadata tag was no big deal, I just felt like it was one more item I could eliminate from my code.

You could accomplish this in your BeanLoader.

Now I have eliminated the need to Autowire the mockDelegate object in my RequestController.

I have built a simple example that can be found here, with view source enabled. You’ll notice that I don’t use the Autowire metadata tag anywhere, allowing the BeanLoader to do the Autowire for me. Well . . . not quite true. I was not able to get away from using Autowire in a Mediator for my views, even if I tried to add them to my BeanLoader and bind them in there. I used a simplified version of an AbstractMediator class that Brian Riley used in his Swiz Passive View example. If anyone has any ideas as to why I had to Autowire this view, I would love to hear it, it was driving me nuts. Anyway, as you can see, all I used in my example was the Mediate metadata tag to mediate my events. That’s what I call simple and clean. As an aside, I am also using the ESRI Flex API, with some mock data that is built using the FeatureSet.convertFromJSON method, which comes in real handy. This is the main API I use for day to day work.

Now is this really necessary? Probably not, but it does keep my MVC code lean. That’s a great strength for Swiz, is the ability to adapt it to your style. This allows me to really focus on building my custom objects that will really do the grunt work that my MVC will simply delegate.

This is my new blog, ripe for world domination. Actually, this is where I will catalog my many attempts at developing applications. More specifically, at developing mapping applications.

Old blog was imported from blogspot, some errors came over that will need to be fixed.
http://odoenet.blogspot.com/

>Well, I’m not really one to leave well enough alone and I just had to give another Flex framework a try for my ESRI Flex mapping needs. My latest victim was Robotlegs. If you look at my earlier blog postings, you might have seen me mention that my first Flex framework was Cairngorm. I didn’t really dislike Cairngorm, but after some conferences and reading around, I felt like I should expand my Framework horizons. Most recently I have been using Swiz with a lot of success. I think I use Swiz in the most minimal way possible, which is actually something for a future blog posting.

I was inspired by this posting on the ESRI ArcGIS Server Blog filed in the Flex tag, that linked your graphics on a map with a DataGrid. This is a useful function and one I thought could be encapsulated into it’s own task. In my case, I just had a need to highlight a graphic on my map that was associated with a list. I did not need to highlight the list when I hovered over the map because I have designed my Graphics with tooltips and felt that two-way binding would be “too much” flash for business purposes. You certainly encapsulate that function and if I were to do so, would probably build it into a utility type of class. With that said, here is the code.

I have made the functions in here protected, as I found a need at a later time to extend this class and override the protected function findGraphicByAttribute to recognize a particular attribute field (i.e. graphic.attributes.Name == attributes.Name) and not just all attributes.

I made an example of the function just like the one on the ESRI ArcGIS Server Blog using my class.

It can be found here with View Source enabled. Hope this benefits someone.