The Perl Goddess

I bet you think that I'm kidding, right? Perl allows programmers to build extremely bad habits, doesn't force discipline, encourages shortcuts that simply aren't possible in other languages. But I'm actually serious.

I had a conversation with my new boss a few weeks ago that went something like this:
Boss: Do you know what data driven design is?
Me: No.
Boss: (google it if you don't know :-)
Me: Oh. That's how I code.
Boss: Good

So it occurred to me to wonder why it was that I code that way, what with my lack of formal education and all. I went to the Pittsburgh Perl Workshop last weekend (my OpenID presentation went great, thanks for asking - I used sock puppets to describe the user/website/server interaction) and spent a great deal of time thinking about how perl people write code and why, and I realized that I code this way (with reusable, modular, configurable code) *because* I work in Perl.

The easiest way to get started doing something with Perl is to pull down some helper code from CPAN. All of that code (ok, not all of it, but most of it... well, ok, the parts I actually use) was written in a modular way, designed to be configured to work for multiple applications. The more time someone spends writing Perl code, the more likely they are to approach each new problem in a modular way (I need something to do A and B, and then C to tie them together) - this makes it easier to use CPAN to reduce your workload, but also means that when you write the code you're likely to avoid hard coding anything in the program itself.

When I started working in Flex, I was a little frustrated that it was so difficult to find examples where developers had pulled the configuration information out into a separate file, but the truth is that's not terribly surprising. First, there simply aren't nearly as many examples of Flex code out there, so it's harder to find any specific thing. Second, without the external community pushing developers to think beyond their current application, it's easy to fall into the habit of taking the shortest path to "done." Working with Perl (and some seriously critical programmers) for (ack!) thirteen years has given me an allergy to hard coding *anything* in my programs. Which makes it harder for me to spit out something quick and dirty, but makes the things I *do* make much more powerful.

The entry "Perl Makes Good Programmers" is tagged: perl, pragmatic programmer Posted by Synedra at 6:58 PM | Permalink | Comments (0) | TrackBacks (0)

Today I had one of those days you get as a programmer, when everything coalesces in a perfect way to shine a happy light on the universe. I had a list of bugs and a single feature I wanted to add to my Flex program. The single feature (dynamic filtering based on values in a set of arrays) took me a long time, and I wrestled with it mightily for several hours. I wanted desperately to make a filter which was extensible, which was easy to add new fields to, and passing variables around in Flex is not something I've become comfortable with.

So there I was, pounding my head against the thing, frustrated and feeling incompetent, until 4PM when a light shined down upon me from the sky, the scales fell from my eyes, whatever cliche you want to use... and the feature was complete. And when the dust cleared, I realized that 3 of the bugs on my 'to-do' list had gotten fixed in the process of creating this feature.

It's an awesome day when you feel "done" with what you're working on. I wasn't even tempted to start on something else... I just basked in the glow of having gotten it done.

For anyone wandering here from flex land who wants to see the code, here it is:

private var filterObj:Object = {this:filterThis,that:filterThat};

// These arrays are populated elsewhere with a list of strings to filter on

private var textObj:Object = {this:"",that:""};

private function filterAll():void {

            	var filtered:Boolean = false;

            	var filterType:String; 

       

            	for (filterType in filterObj) {

            		if (filterObj[filterType].length > 0)

	    			filtered = true;

            	}

            	

            	if (filtered) {

     			dataSet.filterFunction = filterGeneralSet;

            		dataSet.refresh();

 	       } else {

            		dataSet.filterFunction = null;

            		dataSet.refresh();

            	}

private function filterGeneralSet(item:XML):Boolean {

            	var filterType:String;

            	var element:String;

            	var myArray:Array;

            	

              // This is an 'and' filter where everything has to match for the element to return true

            	for (filterType in filterObj) {

    				if (filterObj[filterType].length > 0) { 

    					myArray = filterObj[filterType];

	    				for each (element in filterObj[filterType]) {

	    					var itemFilter:String = item.child(filterType)[0];

	    					if (itemFilter != element) {

	    						return false;

	    					}

	    				}

	    			}

            	}

            	return true;

            }

The entry "Now I remember why I do this job..." is tagged: filtering, flex Posted by Synedra at 9:00 PM | Permalink | Comments (0) | TrackBacks (0)

I've been fussing with Flex this week (as I threatened earlier) and even with my fabulous experience of the tutorials, I have to admit that I've been seriously spoiled by working with Perl for so long. It's such a mature language that someone else has *always* done something similar to what I'm trying to do, so I can find something to crib off of and get most of the work done. Even outside of CPAN, folks have code samples and examples and conversations on mailing lists explaining why things work (or don't).

Flex is not so much with the easy documentation. I consider myself an expert on finding the answer to puzzling questions, and this week I've been faced with many, many puzzling questions which are not easily answered in the book(s) I have nor on any site I can find. Sure, someone has generally answered the basic question but I never seem to need help with those.

For example, yesterday I tried to figure out how to coerce an XMLList into an Array. Seems like it should be simple. I have a list of XML things. Please tell me what their labels are. Thank you. Perl wouldn't have any trouble giving me an array from something array-ish. But no. I spent a couple of hours trying to shove the square peg into the round hole, and at lunch went by Borders to peek at one of the books there and discover that the only way to make an Array out of XMLList entries is... to iterate over the list and shove them in one by one. Ick.

Turns out I didn't really want to put an array in there anyhow, since I want to be able to change the list on the fly and do magical things with it - so passing in the collection itself was the right thing. But hey, the yak needed shaving, so I spent the time to do it right.

And this morning I wanted to do something fairly simple. I wanted to make a button glow when you push it, and unglow when you push it again. This is not hard. I want to maintain the state of the button in a variable which I'll use elsewhere. Surely someone has wanted to do this before... but I couldn't find any examples.

I did, however, figure it out, so I'll put it here in case anyone else is trying to glow and unglow buttons in Flex.

The entry "Perl Docs vs. Other Docs" is tagged: button, documentation, flex, glow, perl Posted by Synedra at 7:01 AM | Permalink | Comments (0) | TrackBacks (0)

I need to learn Flex so that I can throw together a demo of an application in the next couple of weeks. I know what I need to do, some other kind soul has done the programming and even published the source for the hardest element in the application, so I just need to ramp up on the language so I can take that code and run with it.

Being a research queen, I headed over to Amazon to look at the reviews for Flex books. I read all of them and decided on Programming Flex 2... forgetting, apparently, that I have the attention span of a gnat and so a conceptual programming book is doomed to fail to teach me something new.

I did make it through 100 pages before MEGO (My Eyes Glaze Over) set in and I stopped being able to understand any of the words on the page. I shook the cobwebs out of my head and went back to Amazon and discovered that I probably wanted this book instead, since it's in a tutorial format instead of the bone-dry lecture format of the other one. I was going to head down to Borders to get it, but my daughter called to be picked up from school so I didn't get the chance.

Having returned home, I hunted for reasonable online FlexBuilder tutorials and found that Adobe actually has some really good tutorials in their documentation. Turns out that there's also a special deal with their training provider for 30 days free, so I signed up for that. In fact, these two training courses map almost exactly to the book I didn't end up buying and I'm probably going to get more out of an online presentation.

So, having read 5 chapters/100 pages of a perfectly good reference book in 3 hours this morning, I had a vague understanding of the overall application and how it worked, but no idea at all how to do anything in the application. Doing 11 tutorials later in the day (about 2 hours) got me much closer to where I want to be - I finally said "uncle" when my brains started dribbling out of my ears. I plan to spend the next couple of days doing more tutorials and then I think I'll have more than enough experience to do what I need to do. Heck, a goodly part of my job is going to be making prototypes - I might as well learn this one really well before trying out OpenLaszlo.

What did I learn? O'Reilly makes really good reference books, but I just can't learn from them. I need someone to tell me how to do various things and I'll pick up all of the intricacies from that. I'm good at identifying when my kids aren't learning something with a particular method, but it's harder to remember that I have the same limitations. On the other hand, the O'Reilly book will be a good reference, so it wasn't a waste of money.

The entry "Conceptual Reference Books vs. Tutorials" is tagged: flex Posted by Synedra at 3:44 PM | Permalink | Comments (0) | TrackBacks (0)