I was working on a problem the other day. I was following my own best practices
- think critically
- think first
- avoid implementation while thinking
- think maintainability
I was trying to figure out the best way to solve a problem. I had given it a good initial analysis, but i was also dealing with a deadline, so i was feeling pressure to get to implementation. I gave in to this pressure, against my better judgement, and was 2 or 3 hrs into implementing a solution. The solution had me adding knowledge of one service into another via our coldspring container (which in itself is fine) and then using the new service in the old one to do a lookup of a bean to get a value that would determine which of two methods to call in a gateway. All the while, i was feeling like i was missing something easier. I just had that feeling that my solution was too complicated for what i was trying to do.
The problem in a high level nutshell was this: i had certain records in an association table that i sometimes wanted to be included in the return set of a look up, depending on where it was being called from. There were some records that i did not want included other times. It wasn't until the third day that i had been looking at this problem that i saw what i was really trying to do, which was simply to ignore certain records in the association table ALL THE TIME. I just did not see this at first. I actually opened the association table and was looking at the columns in the table talking out load through the problem when i saw the simple solution. I knew in about 10 seconds that this was the better solution.
I checked out of our repository the files that i had already updated, i think there was 3, and started back at point A with my new solution, which from a code standpoint was one single line of SQL in one function that omitted the records when a field was set to 0.
My solution was in the DB, not the code. I ended up simply adding a bit field to the table, setting it to 1 (default value for all records) since all but about 100 of the 7000 records in the table would remain in play and changing the records that i did NOT want in play to 1. Then added the line to the function that conditionally omitted the recs set to 1.
The trade off is a check on this new bit field for every look up to the table and the need to update each new record that falls into the value = 1 category. The gain is a simple, maintainable solution with little to know memory overhead.
Monday, December 1, 2008
Analysis, heavy thinking, database, software architecture
Last week was a big conference for some of my clients. Naturally, there was a fluerry of activity leading up to the conference. My customers made specific requests about some features in our flagship application that needed attention. I was reminded of the following points.
1 - Trust your design. If you have a MVC design in place, trust that it will pay dividens when you are up against timeline constraints.
2 - Break the requests down into little pieces, as much as possible. Do not look at all the requests at once. It would have been easy to get a little overwhelmed at the requests given the time constraints, rather than being overwhelmed, beak it down and trust.
3 - Communicate in very clear terms. Spell out exactly what you are understanding to your customer. I asserted to my customer what i though was asked for and they asserted back ubtil we had that cleared up.
4 - Back to point 3, Requirements are at least 1/2 the battle. My customers dont give me black and white requirements, they explain what they want, but i need to help them clarify the specifics. This is where a front to back design methodology is very valuable. A picture is worth a lot. Show the client what they are asking for - it will help inform what they are trying to say.
5 - Go to a quite place to think through the problem. Noise is a great enemy of critical thinking. I was reminded of the inverse pyramid too. When push came to shove, i was the only one who could make most of the changes being requested. Thats good and bad, good for job security, bad for organization. Picture a pyramid, now flip it upside down. At the top there is lots of room, many hands involved - clarifying the requirements, building prototypes, documenting, testing, as you move down the pyramid toward implenentation, the bottom, fewer people are involved, as your reach the very bottom, there is only one person holding everything up. This is not a statement of pride, no - rather an observation.
6 - Heavy lifting - Trust that you will see a good solution to the problem. Resist the urge to implement the first solutions that pop into your head. There is always a better idea. I like to stay on a problem for a couple days, at least two, where i can give it my best brain power. Almost, without fail, after the second day, i see a better solution that what i had at the end of the first day. Think through the problem. The more time the better.
7 - If the update involves a heavily travled or common path in your application, then think REALLY hard about what you are doing. One of the updates i made to the application was to a very public object. The initital solution i saw added too much overhead to that object. The second solution i saw after a third day of analysis was much lighter. Lighter in terms of less trips to the database.
8 - Think in terms of tradeoffs - this is a mantra that i hear a lot of smart developers saying. Everying you do is a tradeoff. If you persist a piece of data via bean, in memory - saving a trip to the DB, the tradeoff is a bit more overhead. If you keep the overhead real lean, the tradeoff is more trips to the DB. If you choose to keep lookup code in your view page for simplicity, the tradeoff is less maintainable and reusable code. If you choose to follow a mature design pattern and layer your code in a MCV pattern, for ease of maintenance and troubleshooting, the tradeoff is a bit more complexity.
9 - Document your decisions - Someone once said code your documentation. That may be a little overkill, but the point is made. Think about someone else maintaining the code you are writing / updating. Add relevent comment to the code itself. I also like to add information around the bus. logic decision that i am making. I will admit, that i am making these decisions in a vaccum, so its important to document why i made decisions the way i did. 6 months down the road, when i have to update that area of the application again, im always thankful.
1 - Trust your design. If you have a MVC design in place, trust that it will pay dividens when you are up against timeline constraints.
2 - Break the requests down into little pieces, as much as possible. Do not look at all the requests at once. It would have been easy to get a little overwhelmed at the requests given the time constraints, rather than being overwhelmed, beak it down and trust.
3 - Communicate in very clear terms. Spell out exactly what you are understanding to your customer. I asserted to my customer what i though was asked for and they asserted back ubtil we had that cleared up.
4 - Back to point 3, Requirements are at least 1/2 the battle. My customers dont give me black and white requirements, they explain what they want, but i need to help them clarify the specifics. This is where a front to back design methodology is very valuable. A picture is worth a lot. Show the client what they are asking for - it will help inform what they are trying to say.
5 - Go to a quite place to think through the problem. Noise is a great enemy of critical thinking. I was reminded of the inverse pyramid too. When push came to shove, i was the only one who could make most of the changes being requested. Thats good and bad, good for job security, bad for organization. Picture a pyramid, now flip it upside down. At the top there is lots of room, many hands involved - clarifying the requirements, building prototypes, documenting, testing, as you move down the pyramid toward implenentation, the bottom, fewer people are involved, as your reach the very bottom, there is only one person holding everything up. This is not a statement of pride, no - rather an observation.
6 - Heavy lifting - Trust that you will see a good solution to the problem. Resist the urge to implement the first solutions that pop into your head. There is always a better idea. I like to stay on a problem for a couple days, at least two, where i can give it my best brain power. Almost, without fail, after the second day, i see a better solution that what i had at the end of the first day. Think through the problem. The more time the better.
7 - If the update involves a heavily travled or common path in your application, then think REALLY hard about what you are doing. One of the updates i made to the application was to a very public object. The initital solution i saw added too much overhead to that object. The second solution i saw after a third day of analysis was much lighter. Lighter in terms of less trips to the database.
8 - Think in terms of tradeoffs - this is a mantra that i hear a lot of smart developers saying. Everying you do is a tradeoff. If you persist a piece of data via bean, in memory - saving a trip to the DB, the tradeoff is a bit more overhead. If you keep the overhead real lean, the tradeoff is more trips to the DB. If you choose to keep lookup code in your view page for simplicity, the tradeoff is less maintainable and reusable code. If you choose to follow a mature design pattern and layer your code in a MCV pattern, for ease of maintenance and troubleshooting, the tradeoff is a bit more complexity.
9 - Document your decisions - Someone once said code your documentation. That may be a little overkill, but the point is made. Think about someone else maintaining the code you are writing / updating. Add relevent comment to the code itself. I also like to add information around the bus. logic decision that i am making. I will admit, that i am making these decisions in a vaccum, so its important to document why i made decisions the way i did. 6 months down the road, when i have to update that area of the application again, im always thankful.
Monday, November 10, 2008
Flex setup and workspace
Its been a little while since i tried to do any flexing. I came across a neat little project that caught my eye, because of what it was building, a task list. Maybe i could replace some of my stickies. Anyway, ive been working on the example this am for a little bit. Here are a couple of "oh yas" that i encountered so far. http://www.ddj.com/web-development/209900484?pgno=1
Briefly, the reason we want to use flex is:
It builds better interfaces that HTML - look better, and have built in features that HTML does not.
It allows remote access to data without needing to reload the entire HTTP request. This is more responsive when there is alot of data. Remember, FLEX is an IDE that builds SWFs that play in flash player. 99% of all browers have flash player installed. Flashplayer is still a plugin and needs to be installed into a new browser, that is a one time cost, and many many sites across the web deplay swfs, so its a no brainer. SWFs allow us to get to the data layer without needing to reload the entire HTTP request. Swfs have been doing this for years, in the past couple years, swf development has become available to the programmers via FLEX.
Recall that flex uses a markup language called MXML, similar to HTML to build its UI components. There are lots of them available. It uses actionScript to build the event model that allows the UI to communicate with the user via clicks and the data layer, generally using ROing, but also can use web services and XML file consumption to speak with the data layer.
Think too about OO design, as you build UI components via MXML and ActionScript to speak to the data layer, the UI components should speak to a service. The service component speaks to an object in the model domain.
While i was playing with my little example this am, i was greatful for my previous documentation, http://jira.accelerateu.org/confluence/display/WebTeam/Flex. Very useful to remind me of some basic techniques. One of the first things i wanted to do was connect my UI component to the database via an RO call. I was able to borrow from my documentation quickly to cut to the chase. I created a new cfc with a function set to remote access and queried a random table. Then i set the applicationComplete property in the mxml file to call the function via the remote object defined in the file. The i created a function in the mxml file, via ActionScript to handle the results, binding them to a data grid control in the mxml file.
I had to perform a Project Clean workspace to get my swf to recompile, even though i was not getting any errors. Im not sure what the trigger is here, only that at some point, it stoped recomiling the swf. I could see this by looking at the compile date on the swf. I would then deploy the swf into my webroot and view it via the browser. Typically, when there are problems with the mxml or ActionScript that prevent a recompile, there is an indication in the source file.
Overall, i was able to quickly get back into the guts of Flex development. Keywords:
- Flex - IDE for building swfs
- Swfs - movie renderable in flashplayer
- Flashplayer - plugin used in browser
- MXML - mark up language used by Flex to build swfs
- ActionScript - scripting language used to program events and attach UI to domain
- Compilation - process of turning MXML file into swf.
- Deploying - process of moving swf into the web server root
- Embedding - placing swf within a CFM or HTML file
Tuesday, May 13, 2008
Interesting that i got an article from a co worker recently about flex not for every CF developer Viewpoint: Not Every ColdFusion Developer Should Be A Flex Developer".
Then another coworker asked if i had any flex books, i explained that i have been relying heavily on other flex/cf blogs to find answers to questions as i would encounter pushing the flex envelope.
He said something about wanting to connect a record set to a datagrid, which made me think a little more critically about the complexities of flex. Was he getting his recordset from an XML file, from a web service (wsdl) or was he getting a query set returned via a remoting call. Probably the latter, I did not ask. I have experimented with each technique and have found the remoting, once it was configured properly, to be the cleanest and preferred method of getting data from the back end. Since i am using ColdFusion, there is lots of detailed help about using remoting to call a CFC that returns the familiar query type and assigning the result to an ActionScript variable of type ArrayCollection. This allows a fairly painless handoff of data to then be displayed to a datagrid or other MXML control.
Sample code
Then another coworker asked if i had any flex books, i explained that i have been relying heavily on other flex/cf blogs to find answers to questions as i would encounter pushing the flex envelope.
He said something about wanting to connect a record set to a datagrid, which made me think a little more critically about the complexities of flex. Was he getting his recordset from an XML file, from a web service (wsdl) or was he getting a query set returned via a remoting call. Probably the latter, I did not ask. I have experimented with each technique and have found the remoting, once it was configured properly, to be the cleanest and preferred method of getting data from the back end. Since i am using ColdFusion, there is lots of detailed help about using remoting to call a CFC that returns the familiar query type and assigning the result to an ActionScript variable of type ArrayCollection. This allows a fairly painless handoff of data to then be displayed to a datagrid or other MXML control.
Sample code
Monday, May 12, 2008
So you wanna flex?
Flex, the ultra popular tool from Adobe that allows developers to create swfs (previously the exclusive domain of the designer folks) is here to stay but is not a back end database tool nor is it trying to replace ColdFusion. Flex is a IDE that provides developers with tools to create swfs or movies that are played by the equally ultra popular Flash player.
Flex is a GUI design tool, not a database tool.
Adobe has a real trifecta with ColdFusion, Flex and Flash player.
Finally, we have a development environment and language that allows developers, not designers, to create amazing Flash applications and front ends to their ColdFusion applications. Most CF developers will want the Flex Builder 3 IDE, which, like the traditional Flash IDE, compiles code into a SWF that must then be uploaded to your server. Flex allows programmers to use MXML and ActionScript to build code that compiles into swfs.
It should be noted that while the Flex IDE is well designed and it pretty easy to get started in, there is a pretty steep learning curve once you get going, especially with the ActionScript side of things. Find some good simple tutorials, blog spots or books and dig in.
Here is a list of Flex concepts
Flex is a GUI design tool, not a database tool.
Adobe has a real trifecta with ColdFusion, Flex and Flash player.
Finally, we have a development environment and language that allows developers, not designers, to create amazing Flash applications and front ends to their ColdFusion applications. Most CF developers will want the Flex Builder 3 IDE, which, like the traditional Flash IDE, compiles code into a SWF that must then be uploaded to your server. Flex allows programmers to use MXML and ActionScript to build code that compiles into swfs.
It should be noted that while the Flex IDE is well designed and it pretty easy to get started in, there is a pretty steep learning curve once you get going, especially with the ActionScript side of things. Find some good simple tutorials, blog spots or books and dig in.
Here is a list of Flex concepts
Flex Concepts
- Flex applications are Flash applications.
- Flex is a programmer-centric way to create Flash-based rich internet applications.
- Flex applications are rendered using Flash Player 9 or later.
- Like all Flash RIAs, Flex SWF files are processed by the client, rather than the server.
- The Flex framework contains the predefined class libraries and application services necessary to create Flex applications.
- Flex builder3 is a stand alone IDE (free to educational developers) and is also avail as a free SDK plugin for Eclipse
- Flex applications are written using MXML and/or ActionScript.
- MXML is an XML-based markup language that is primarily used to layout application display elements.
- ActionScript is an ECMAScript-compliant object-oriented programming language that is primarily used for application logic.
- MXML and ActionScript code are compiled into binary SWF files.
Subscribe to:
Posts (Atom)