These are habits of effective developers. I gleaned a lot of this from the helms and peters podcast. I listened to this a couple years ago and again today. Really good stuff.
1 - Pursue professional growth. Always make time to attend conferences, trainings etc. Use the internet and its plethora of technical podcasts, articles, and blogs. There are so many skilled smart people who have been down the same path that you are on and have documented their experience.
2 - Think Google to help narrow down the search for related resources.
3 - Blog yourself. For me, its help A LOT to internalize things by writing them. Thats why this blog exist.
4 - Think user first. Do not let your vision take precedence over the user or client vision. Try to engage them as much as possible when gathering requirements.
5 - Prototype. If its a new product or functionality build the front end first. There is a lot of smart people who advocate for this "front to back development approach". Build the prototype, involve the client actively. We used to follow a process called FLIP, that emphasized the prototype first while iterating frequently with the customer until they say "thats it". There is no thought given to the implementation, language, DB or framework during the prototype. This process takes at least half of the entire product development life cycle.
6 - As a developer, do not assume superiority. Be amiable, supportive, encouraging. Believe that everyone who you come in contact with has something to offer.
7 - Think first, code second. Try to see the entire problem or big picture. Seek the birds eye view before starting coding or database development.
8 - Document. Not document your code, but code your documentation. Think hard about what is good documentation. Consider that someone else will be maintaining this code.
Friday, August 29, 2008
Thursday, August 28, 2008
Object oriented design
Today, I was listing to Hal Helms and Jeff Peters discuss object oriented design. They were talking about inheritance -vs- composition. The main point was how composition has a is favored over inheritance, is a. Ive been hearing this for awhile, but have not always understood, probably because its a little abstract, since im not doing much in the way of new object design or at least not with extending base classes.
One concept was that base classes are really not ever instantiated, but extended. This notion was further described this way:
A goal of class programming, remember this is the model layer, not the view of controller, is to create stable reusable objects where commonality is captured in a base class that can be inherited or extended by a more specific class. Another way to describe this base class is as a super class.
The goal is to allow base classed to be easily extended (composition) to incorporate new behavior without modifying existing code. This creates designs that are resilient to change and flexible enough to take on new functionality to meet changing requirements.
Design principle:
Classes should be open to extension and closed to modification.
These concepts where discussed around the context of the Decorator Pattern.
Remember, when you abstract the differences by composition, you are adding complexity to the application. Dont forget to think in terms of trade offs. Nothing is free, when you build more extensible code, classes, by following this excellent principle, you are adding more complexity to your logic. Only apply the "open closed" principle where needed.
One concept was that base classes are really not ever instantiated, but extended. This notion was further described this way:
A goal of class programming, remember this is the model layer, not the view of controller, is to create stable reusable objects where commonality is captured in a base class that can be inherited or extended by a more specific class. Another way to describe this base class is as a super class.
The goal is to allow base classed to be easily extended (composition) to incorporate new behavior without modifying existing code. This creates designs that are resilient to change and flexible enough to take on new functionality to meet changing requirements.
Design principle:
Classes should be open to extension and closed to modification.
These concepts where discussed around the context of the Decorator Pattern.
Remember, when you abstract the differences by composition, you are adding complexity to the application. Dont forget to think in terms of trade offs. Nothing is free, when you build more extensible code, classes, by following this excellent principle, you are adding more complexity to your logic. Only apply the "open closed" principle where needed.
Wednesday, August 27, 2008
ColdFusion Frameworks, coldbox, tarten, MG, fusebox, machii
Today, i came across a number of helpful/interesting podcasts, articles. First, the helms and peters podcast on Framework Shrink is both entertaining and informative. During this cast, fusebox, MG and machii are all praised, frameworks in general are praised and people who program willy nilly are not praised. They joke about the NMM (no methodology methodology) this is characterized by the developer who thinks they are too smart to have to use someone else ideas, why use a framework when i can solve the problem myself. This brings to mind the debate between Hal Helms and Simon Horwith. This was not so much a debate as a informative discussion about the pros and cons of frameworks. With a decided edge going to the wisdom of using solid solutions created by others that follow best practices and encourage solid design for large applications that are scalable, maintainable, predictable (thats what the use of frameworks provide).
I followed a thread to coldbox, another CF framework that lead to this discussion about the value of frameworks. Who is using coldbox.
There was a mention of Tarten, which i had not hear of before. Interesting, in my brief read, Tarten encourages a service oriented architecture, where the controller speaks only to a service that acts as a mediator to the bus. logic in the model.
This is the common thread through all of the frameworks that i have been into and out of the past few months. Each promotes the
tiered architecture
MVC design pattern to achieve separation of views and bus. logic via a controller
OO design
tight encapsulation
loose coupling
reuse of small singular type classes or objects or with CF, components
the use of a controller to coordinate/direct requests made by application
pushing of bus. logic into the model layer
use of XML style controller
preference for application to speak to the model via a service (tarten).
I also found this useful cf portal site.
I really liked this part of the conversation, quoting Luis Majano.
"Most major design patterns do apply to Coldfusion and decoupling and object oriented approaches are posible. Yes, they will make your application more complex, harder to grasp, and event WEIRD!! But that is the intent, to take your application to an Enterprise level. You can continue to build procedural code for certain applications, it doesn’t mean its bad. But for high availablity and enterprise applications, I would go with a framework. The flexibiliy and architectural extensibility that it will give you, cannot be found in other approaches. It will be hard to grasp and you might think, why do all this work, all these calls. Object Oriented architecture is not easy and you also have to note, that some complexity on these approaches, will make you sacrifice speed. But the benefits will be tremendous."
I followed a thread to coldbox, another CF framework that lead to this discussion about the value of frameworks. Who is using coldbox.
There was a mention of Tarten, which i had not hear of before. Interesting, in my brief read, Tarten encourages a service oriented architecture, where the controller speaks only to a service that acts as a mediator to the bus. logic in the model.
This is the common thread through all of the frameworks that i have been into and out of the past few months. Each promotes the
tiered architecture
MVC design pattern to achieve separation of views and bus. logic via a controller
OO design
tight encapsulation
loose coupling
reuse of small singular type classes or objects or with CF, components
the use of a controller to coordinate/direct requests made by application
pushing of bus. logic into the model layer
use of XML style controller
preference for application to speak to the model via a service (tarten).
I also found this useful cf portal site.
I really liked this part of the conversation, quoting Luis Majano.
"Most major design patterns do apply to Coldfusion and decoupling and object oriented approaches are posible. Yes, they will make your application more complex, harder to grasp, and event WEIRD!! But that is the intent, to take your application to an Enterprise level. You can continue to build procedural code for certain applications, it doesn’t mean its bad. But for high availablity and enterprise applications, I would go with a framework. The flexibiliy and architectural extensibility that it will give you, cannot be found in other approaches. It will be hard to grasp and you might think, why do all this work, all these calls. Object Oriented architecture is not easy and you also have to note, that some complexity on these approaches, will make you sacrifice speed. But the benefits will be tremendous."
Wednesday, August 20, 2008
Frameworks, MG, Machii or Custom
I've been messing with MG the past couple days. I have a small application im working on, and decided to give MG a go. Things were going fine, it was taking me longer to solve the problem because i was learning the framework. This is ok, acceptable when learning a new framework. I spent a bit of time listening to podcasts, reading blogs and looking in the official Model-Glue documentation center. Once i turned the corner on getting the MG controller to set the args properly from the event - i was on my way. From this point, MG facilitating communication between my gui and model just fine.
It was about this time that i started to feel like it was a bit overkill, the framework is pretty light, lighter than machii, but i still was not feeling good about the use of it in this case. I just was not doing that much and felt like the overhead and increased complexity was not worth the cost. Like a big brick, the vision of a streamlined *custom framework hit me in the head. I could hear Simon Horwith whispering in my ear. So, i decided to scale back a bit. I used the index.cfm file to handle the bootstrapping and the rest of the setup work. It reminded me of the fusebox settings file, where application level variables and pointers are set up.
Index.cfm is now responsible for creating the object pointer into the service and also listens for actions (*events) such as insert, update or get. Thats about all this GUI is doing. Depending on which action is executed (listened for) i am calling the appropriate service method and passing along form or URL vars appropriately.
These are the following design principles adhered to:
*MVC design pattern
*separation of concerns (view just reacts to what is provided via the controller (index)
*encapsulation of bus. logic (all in CFCs)
*asynchronous calls, where helpful to user
*no SQL in the views (see above)
*safer from spammers and hackers, SQL is down stream protected by the service layer.
*no extra overhead (MG or Machii or Fusebox)
*intuitive - less complex
tradoffs
not as scalable as MG, Machii or fusebox
If the requirements dictate, and a more scalable framework becomes necessary, i can simply trade in the index.cfm with its event and listening responsibilities for a MG or MachII framework, where we can use an XML style central controller with specific listeners or messages. Since i put the bus. logic in the services and the database interactions in the DAO, Gateway - its a can of corn.
It was about this time that i started to feel like it was a bit overkill, the framework is pretty light, lighter than machii, but i still was not feeling good about the use of it in this case. I just was not doing that much and felt like the overhead and increased complexity was not worth the cost. Like a big brick, the vision of a streamlined *custom framework hit me in the head. I could hear Simon Horwith whispering in my ear. So, i decided to scale back a bit. I used the index.cfm file to handle the bootstrapping and the rest of the setup work. It reminded me of the fusebox settings file, where application level variables and pointers are set up.
Index.cfm is now responsible for creating the object pointer into the service and also listens for actions (*events) such as insert, update or get. Thats about all this GUI is doing. Depending on which action is executed (listened for) i am calling the appropriate service method and passing along form or URL vars appropriately.
These are the following design principles adhered to:
*MVC design pattern
*separation of concerns (view just reacts to what is provided via the controller (index)
*encapsulation of bus. logic (all in CFCs)
*asynchronous calls, where helpful to user
*no SQL in the views (see above)
*safer from spammers and hackers, SQL is down stream protected by the service layer.
*no extra overhead (MG or Machii or Fusebox)
*intuitive - less complex
tradoffs
not as scalable as MG, Machii or fusebox
If the requirements dictate, and a more scalable framework becomes necessary, i can simply trade in the index.cfm with its event and listening responsibilities for a MG or MachII framework, where we can use an XML style central controller with specific listeners or messages. Since i put the bus. logic in the services and the database interactions in the DAO, Gateway - its a can of corn.
Thursday, August 14, 2008
Model Glue
I ran across a ModelGlue folder on our test server today. I have been hearing about MG for a couple years. An easy to use CF framework that promotes MVC. I decided to take a look. I found a read me file in a predictable location and opened it. It had excellent instructions about how to copy a certain folder into your web root, open a controller and change a couple properties in the xml config. file. I did all this, made a silly mistake and corrected it and had the sample RD site up and running in 20 minutes. Impressive. Not me, it.
I recall the setup and initial forays into fusebox and machii and neither was anywhere near as easy as this. Granted, it looks a lot like machii with the xml controller, events and such, but still, 20 minutes from start to end. I must say, i am impressed by how easy that was. I will have to give this a ride in the future.
I sent Joe Rinehart a note saying as much.
ModelGlue, coming to a theater near you.
I recall the setup and initial forays into fusebox and machii and neither was anywhere near as easy as this. Granted, it looks a lot like machii with the xml controller, events and such, but still, 20 minutes from start to end. I must say, i am impressed by how easy that was. I will have to give this a ride in the future.
I sent Joe Rinehart a note saying as much.
ModelGlue, coming to a theater near you.
AJAX - javascript little opps
I have been using a little AJAX technique in a couple places and was having two separate problems that i worked out.
First issue: i have 2 separate html divs that were being reloaded on the same page. The problem i was having is the second call that was informing the second div on the page was sacking the first. In other words, I had come like this calling two different jscript methods
function loadQuestionsStandards(assessmentID,category,type,level){
showStandards(category,type,level);
showQuestions(assessmentID);
}
Each function showStandards() and showQuestions() contains code like this
var url="views/filterQuestions.cfm?&assessmentID=" + AID + "&showAllQuestions=" + flag ;
oXmlHttp=GetHttpObject(updateQuestionList);
oXmlHttp.open("GET", url , true);
where updateQuestionList is the name of a layer in the page called by the url var.
The results of the second call to showQuestions was polulating both divs on the page. Finally, i changed the true property to false in the first method call and it worked.
In other words, the reload of the page only occured once, not twice and it correctly reloaded both layers. I did not find any help around this problem in the blogshere.
The second problem only showed itself in our production environment. Hmmmm, did not occur in our test or staging environments. That remains a puzzle to me. The problem was in the same line of code as the first problem.
oXmlHttp.open("GET", url , true);
When i was trying to solve the first problem, i changed the GET to POST for one of the functions and forgot to change it back. Probably forgot because it did not make a difference until it made it way to production, where it failed gracefully. I got a message back from the Jscript API, i presume, that said Length Required.
I was able to trace the problem back to a specific function where i had made this GET to POST change.
Moral of the story? not sure, but both of these issued had to do with the
oXmlHttp object.
First issue: i have 2 separate html divs that were being reloaded on the same page. The problem i was having is the second call that was informing the second div on the page was sacking the first. In other words, I had come like this calling two different jscript methods
function loadQuestionsStandards(assessmentID,category,type,level){
showStandards(category,type,level);
showQuestions(assessmentID);
}
Each function showStandards() and showQuestions() contains code like this
var url="views/filterQuestions.cfm?&assessmentID=" + AID + "&showAllQuestions=" + flag ;
oXmlHttp=GetHttpObject(updateQuestionList);
oXmlHttp.open("GET", url , true);
where updateQuestionList is the name of a layer in the page called by the url var.
The results of the second call to showQuestions was polulating both divs on the page. Finally, i changed the true property to false in the first method call and it worked.
In other words, the reload of the page only occured once, not twice and it correctly reloaded both layers. I did not find any help around this problem in the blogshere.
The second problem only showed itself in our production environment. Hmmmm, did not occur in our test or staging environments. That remains a puzzle to me. The problem was in the same line of code as the first problem.
oXmlHttp.open("GET", url , true);
When i was trying to solve the first problem, i changed the GET to POST for one of the functions and forgot to change it back. Probably forgot because it did not make a difference until it made it way to production, where it failed gracefully. I got a message back from the Jscript API, i presume, that said Length Required.
I was able to trace the problem back to a specific function where i had made this GET to POST change.
Moral of the story? not sure, but both of these issued had to do with the
oXmlHttp object.
Wednesday, August 13, 2008
CF Conversation
I listened to this podcast today. This interview highlighted a couple things that i have been into and out of in other blogs, podcasts about the CF community, perception of CF as a light weigh tool, frameworks etc.
CF has come along way, especially with the last couple of releases that make CF much more object like. I can see how CF has grown up over 10 years, from its initial release which really was alot like HTML with its tag based format. It was easy to use and easy to create dynamic content. CF excels at hiding much of the complexity of what it does in the tags. This results in users being able to *just do their work. In the past couple years, i have been working more in the architectural side of things than in the front, so i appreciate the emphasis on CFCs and OO techniques.
There is a perception that many of the CF developers, because of it ease of use, do not have the traditional CS type background and consequently are sloppy programmers who rely too much on frameworks. An interesting point. CF's own efficiency has spawned lots of programmers who otherwise may have never been programmers. Folks who only dealt with static content, layout and design had access to programmatic tools that were once exclusive territory of programmers.
There is the perception among programmers that the within the CF community, there is not enough emphasis or development integrating CF with other more mature back end solutions, like Java or PHP, for example. Andrew Powell is a guy who has been working to bridge that gap. This is a good ADOBE sponsored article around this type of integration. If CF is to continue its acceptance into the *big players sphere, it must play better with other technologies. Matt Woodward posts a helpful article around Java integration.
The discussion also talks about the proliferation of CF frameworks and despite the backing of the CF *elite, are overused and are a crutch to many CF programmers. Is there a perception in the CF community that if you are not using a framework, you should be? Hal Helms and Simon Horwith have this debate about frameworks.
The frameworks include, machii, coldBox, model glue, fusebox, coldSpring. Each of these were mentioned. There was a good discussion of trade offs and what that means.
For me, i started CFing without using any frameworks. In a perfect world, CFers would have a change to program without any *overhead of a framework. This aids in the understanding of variables, scopes, and other application wide settings and how the whole bootstrapping process occurs. The frameworks hide many of these concepts and could create a programmer who does not really get some of the crucial concepts behind the code. This could result in programmers who cannot program outside a given framework. I think the frameworks are very useful in some applications and perhaps a bit overkill in others. The size of the app is a big factor. I like the idea of a framework because it creates predictability in the application. This is important for the future of the application and as new people come into it to support it.
There was also some good discussion around the software life cycle. A good reminder that we should do our heavy lifting before we start programming and that we should not start the development in the database. FLIP was mentioned, since there was discussion of frameworks. I think i heard these numbers:
50% time gathering requirements and prototyping
30% implementing the prototype
20% testing and documenting
Was a mention that Flex has really become a popular prototyping tool.
CF has come along way, especially with the last couple of releases that make CF much more object like. I can see how CF has grown up over 10 years, from its initial release which really was alot like HTML with its tag based format. It was easy to use and easy to create dynamic content. CF excels at hiding much of the complexity of what it does in the tags. This results in users being able to *just do their work. In the past couple years, i have been working more in the architectural side of things than in the front, so i appreciate the emphasis on CFCs and OO techniques.
There is a perception that many of the CF developers, because of it ease of use, do not have the traditional CS type background and consequently are sloppy programmers who rely too much on frameworks. An interesting point. CF's own efficiency has spawned lots of programmers who otherwise may have never been programmers. Folks who only dealt with static content, layout and design had access to programmatic tools that were once exclusive territory of programmers.
There is the perception among programmers that the within the CF community, there is not enough emphasis or development integrating CF with other more mature back end solutions, like Java or PHP, for example. Andrew Powell is a guy who has been working to bridge that gap. This is a good ADOBE sponsored article around this type of integration. If CF is to continue its acceptance into the *big players sphere, it must play better with other technologies. Matt Woodward posts a helpful article around Java integration.
The discussion also talks about the proliferation of CF frameworks and despite the backing of the CF *elite, are overused and are a crutch to many CF programmers. Is there a perception in the CF community that if you are not using a framework, you should be? Hal Helms and Simon Horwith have this debate about frameworks.
The frameworks include, machii, coldBox, model glue, fusebox, coldSpring. Each of these were mentioned. There was a good discussion of trade offs and what that means.
For me, i started CFing without using any frameworks. In a perfect world, CFers would have a change to program without any *overhead of a framework. This aids in the understanding of variables, scopes, and other application wide settings and how the whole bootstrapping process occurs. The frameworks hide many of these concepts and could create a programmer who does not really get some of the crucial concepts behind the code. This could result in programmers who cannot program outside a given framework. I think the frameworks are very useful in some applications and perhaps a bit overkill in others. The size of the app is a big factor. I like the idea of a framework because it creates predictability in the application. This is important for the future of the application and as new people come into it to support it.
There was also some good discussion around the software life cycle. A good reminder that we should do our heavy lifting before we start programming and that we should not start the development in the database. FLIP was mentioned, since there was discussion of frameworks. I think i heard these numbers:
50% time gathering requirements and prototyping
30% implementing the prototype
20% testing and documenting
Was a mention that Flex has really become a popular prototyping tool.
ColdFusion Growing Up
I listened to a podcast today about something i have been reading in blogs a bit the past couple months. Old news to some, but new to me and important to understand the larger picture.
Once upon a time, ColdFusion was just a little player on the larger scene. the Allaire brothers created the initial taging language way back in 98,99? It is telling now that ColdFusion has 3 different rendering engines and a couple open source projects and is in discussion with educational groups for free liscensing and curriculum, to start offering as college curriculum.
There are 3 different organizations that are offering a ColdFusion rendering engine.
Adobe - with Coldfusion
Blue Dragon - new Atlanta
Railo
I was listening to this podcast today where they discussed Railo in detail and the need to have a standard CF rendering engine, since there are now multiple players. the idea of a CF core that was implemented by each engine with plugins or addons or lib functions or something like this to allow diff. additions by diff. engines.
Its all good - the maturation of a platform like ColdFusion.
Once upon a time, ColdFusion was just a little player on the larger scene. the Allaire brothers created the initial taging language way back in 98,99? It is telling now that ColdFusion has 3 different rendering engines and a couple open source projects and is in discussion with educational groups for free liscensing and curriculum, to start offering as college curriculum.
There are 3 different organizations that are offering a ColdFusion rendering engine.
Adobe - with Coldfusion
Blue Dragon - new Atlanta
Railo
I was listening to this podcast today where they discussed Railo in detail and the need to have a standard CF rendering engine, since there are now multiple players. the idea of a CF core that was implemented by each engine with plugins or addons or lib functions or something like this to allow diff. additions by diff. engines.
Its all good - the maturation of a platform like ColdFusion.
Refactoring Bus. Logic
The past couple weeks have had me back into old problems. I had been in each of these holes before, but was back with new requirements. As i looked at both of the functions in the CFCs, i found myself struggling to add the new requirements because the way the functions were defined was not intuitive. In one case, i ended up refactoring the way the logic was working. I should say i separated the logic into two different queries and then used a union to join the result set if needed.
It took me a couple days of going into and out of this function before i was able to see the solution that i ended up using. I was talking to another developer about this and concluded that we need to see things in our own model to understand them before we can enhance something. I was temped at one time to create a new function and simply leave this one that way it was, but i fought that urge and eventually saw a cleaner way to solve the same problem. Be a technician, bot a demolition man. I added a comment in the function to the effect that i hoped the next time someone traveled down this path into this function, that the bus. logic would be clear to them.
Good code to me means clear code, not necessarily fewer lines or clever, but clear to the next person who may be coming into the code to try to enhance it.
The greatest threat to maintainable software? Complexity! Someone said that once.
Moral to the story. Be patience and if code smells, give yourself ample opportunity to re-factor the code in a way that does not smell, is easier to understand and enhance for the next Joe who comes along after you.
It took me a couple days of going into and out of this function before i was able to see the solution that i ended up using. I was talking to another developer about this and concluded that we need to see things in our own model to understand them before we can enhance something. I was temped at one time to create a new function and simply leave this one that way it was, but i fought that urge and eventually saw a cleaner way to solve the same problem. Be a technician, bot a demolition man. I added a comment in the function to the effect that i hoped the next time someone traveled down this path into this function, that the bus. logic would be clear to them.
Good code to me means clear code, not necessarily fewer lines or clever, but clear to the next person who may be coming into the code to try to enhance it.
The greatest threat to maintainable software? Complexity! Someone said that once.
Moral to the story. Be patience and if code smells, give yourself ample opportunity to re-factor the code in a way that does not smell, is easier to understand and enhance for the next Joe who comes along after you.
Blogs and Podcasts
As a developer, there are many ways to approach solving the problems that you encounter. One of the primary points i am making is where do we find inspiration and ideas for how to solve things. I have been making alot of rounds lately in the blog sphere. I cannot stress enough how much outstanding fodder is available in peoples blogs. Someone, Brian Hegeman, once encouraged me to use the blog sphere to find answers to questions but more than that to stretch my understanding of the bigger picture. I was not ready at that time, probably because i was too busy just trying to understand the code base i was working on, supporting ect. I was fortune enough to work with a couple guys who were very talented programmers/architects. There was much for me to learn.
I made a decision after the cf-objective conference this year to spend more time stretching my brain with other peoples perspectives and ideas. Over the past 3 months I have been almost daily going to blogs not looking for a specific answer to a problem, but just to listen in on some conversations. I also joined a couple specific groups, where the conversation is specific about a framework, machII and a model layer manager called ColdSpring. These are specific frameworks that the main application i support uses. As part of this blogging experience, i have created a public space trying to share the learning and organize some of the blogs i have visited.
I have found myself also listening to a few podcasts. Some people may prefer to read, but the podcasts are very useful and pretty focused on relevant topics for the ColdFusion developer. I have found that a couple different CF related podcasts have been around for a few years. Hal helms and Jeff Peters have been doing one for awhile as have Bryan Kaiser and Michael Kaynie. This format starts out discussing relevant CF related news, then typically has someone interviewed. In 2006 Matt WoodWard and Peter Ferrel of machii and CF fame started a podcast called ColdFusion Weekly.. The ColdFusion weekly has recently stopped creating new podcasts but a couple others have just began. CF conversations is more of a round-table interview format.
Here is a short list of topics that i have been plugging into the past couple weeks in various blogs and podcasts.
SQL injection and protection
Marketing CF
Creating more CF developers by giving CF away to educational institutions (ADOBE)
Creating an official curriculum for Universities to adopt
CFAJAX, built in ajax tags for CF8
Krugle.com - code search engine
FLEX -vs- AJAX debate
Framework or no-framework debate
Flex as the view layer, CF as the model layer, machii or model glue as controller
If you wanna be a developer, then pull your head out of the hole and embrace the blog sphere that has so much to offer.
I made a decision after the cf-objective conference this year to spend more time stretching my brain with other peoples perspectives and ideas. Over the past 3 months I have been almost daily going to blogs not looking for a specific answer to a problem, but just to listen in on some conversations. I also joined a couple specific groups, where the conversation is specific about a framework, machII and a model layer manager called ColdSpring. These are specific frameworks that the main application i support uses. As part of this blogging experience, i have created a public space trying to share the learning and organize some of the blogs i have visited.
I have found myself also listening to a few podcasts. Some people may prefer to read, but the podcasts are very useful and pretty focused on relevant topics for the ColdFusion developer. I have found that a couple different CF related podcasts have been around for a few years. Hal helms and Jeff Peters have been doing one for awhile as have Bryan Kaiser and Michael Kaynie. This format starts out discussing relevant CF related news, then typically has someone interviewed. In 2006 Matt WoodWard and Peter Ferrel of machii and CF fame started a podcast called ColdFusion Weekly.. The ColdFusion weekly has recently stopped creating new podcasts but a couple others have just began. CF conversations is more of a round-table interview format.
Here is a short list of topics that i have been plugging into the past couple weeks in various blogs and podcasts.
SQL injection and protection
Marketing CF
Creating more CF developers by giving CF away to educational institutions (ADOBE)
Creating an official curriculum for Universities to adopt
CFAJAX, built in ajax tags for CF8
Krugle.com - code search engine
FLEX -vs- AJAX debate
Framework or no-framework debate
Flex as the view layer, CF as the model layer, machii or model glue as controller
If you wanna be a developer, then pull your head out of the hole and embrace the blog sphere that has so much to offer.
Subscribe to:
Posts (Atom)