Friday, December 31, 2004

Hal Helms Newsletters - OO Primer

If you're new to OO or want to solidify what you already know (or *think* you already know ...), you're going to want to check out Hal Helms' latest series of newsletters:

http://halhelms.com/index.cfm?fuseaction=newsletters.detail


Hal has a real gift to explaining OO concepts in a way that makes them very easy to understand and is very passionate about getting people to start thinking in OO, so his latest two newsletters (and the upcoming ones he's hinted at) should be considered "must read" materials for CFers looking to make the transition to OO. And that should be each and every one of you!


I'm going to be covering an intro to OO thinking, principles, etc. at our February CFUG meeting as well so I should have some thoughts over the next month or so. This will be a good way for me to get started on the series of OO blog entries/articles I have planned for the new year.


I hereby declare 2005 to be "the year of OO" for all CFers! :-)

Tuesday, December 28, 2004

Server Migration

If you're reading this, you're hitting my new dedicated server. The migration wasn't too bad, although I did change the blog database from SQL Server 2000 to MySQL 4.1.7 which was semi-challenging.


 


ere's the steps I took to migrate from SQL Server to MySQL:



  1. Ran the MySQL script that comes with Ray Camden's blog software to create the database


  2. Downloaded and installed MySQL ODBC driver for Windows on my Windows laptop that I have SQL Server Enterprise Manager installed on


  3. Created a user in MySQL to use for the migration


  4. Created ODBC datasource to the MySQL database


  5. Got an error about the authentication method when I tried to connect via the ODBC driver; this is related to the new password hashing mechanism in MySQL 4.1.


  6. Went to the MySQL command line and reset the user's password to the old hash method:

    SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('newpwd');

    You have to do this if you want to connect via ODBC!



  7. Created the ODBC connection again--worked this time


  8. Ran the Export DTS in SQL Server EM and pointed to the MySQL database as the destination



Would have been great if it worked, but there was a minor problem of some sort with the tblBlogComments and tblBlogEntries tables. SQL Server EM was throwing an error about not being able to do a BLOB insert ... not sure what that was all about. I thought maybe it had to do with the ntext datatype in SQL Server, but I experimented with changing that to just text (and nvarchar to just varchar) and it didn't help.


I then went through several iterations of exporting the data from SQL Server to a text file and trying to import that directly into MySQL. I didn't ever quite get the right combination of delimiters, text enclosures, etc. to get it to work right. (I tried 4-5 combinations of things and decided to move on--I'm sure this method is possible however.)


So finally I decided to give MS Access a shot as a migration tool. I'm pretty well-known for cursing Access's very existence, but it appears I have found a use for it after all. ;-) I exported the tblBlogComments and tblBlogEntries tables from SQL Server to Access, then used Access to create new tables and export the data to MySQL through the ODBC connection.


The data got there fine, and I just had to do some minor tweaking of datatypes, nullables, add an index, etc. to get the new tables to match the tables created by Ray's script that ships with the blog software. Then I dropped the old tables, renamed the new tables to the correct name, and bingo--everything worked.


As an aside, I like MS SQL Server, but now that I'm on a dedicated server and it's my money going for the software, I opted for MySQL. I'm a big fan and use MySQL a lot anyway, so this was a natural move for me on my personal site. I'm going to be very anxious to try out the new SQL Server Express 2005 once it's available though.

Wednesday, December 22, 2004

Exercises in Design Patterns

I had a really eloquent version of this post all worked out, but for some reason it choked when I submitted it, so this will be a less eloquent, abbreviated version.


Apologies that I've been in a cave lately. I've had the typical end-of-the-year project pileup to dig out from under, but in the course of working feverishly on some of these projects, I've taken the opportunity to take a much closer look at some design patterns, specifically in my case DAOs and how to use them better and more effectively.


 


I've been using DAOs in Mach-II projects for quite some time now, and although it's been working great I realized I've been using them a bit prescriptively without *really* digging down deep and understanding all the surrounding issues, gotchas, and possibilities. So I've been reading, researching, and reading some more over the past few weeks and I'm starting to have some revelatory insights on some things.


The purpose of this post isn't to share any insights--they're far too half-baked at this point, but you better believe I'll be sharing in the very near future. I'll be thinking out loud and talking to myself a lot over the coming weeks, so please don't be alarmed. I'm not insane, I'm just obsessed. :-) I do think it's appropriate for me to make a few general comments at this point, largely brought on by the introspective season we're in.


First, always be challenging yourself. I'm at the point now with a lot of more advanced OO concepts that I feel like I'm at least starting to "know what I don't know," and it's really inspiring me to go nuts with learning this stuff. I've already looked back and stuff I've written over the last year and seen how much better I could have done things had I known then what I know now.


Second, I'm a bit surprised at the lack of comprehensive CF-specific code samples and literature about OOP and design patterns. It's starting to emerge on some really great blogs (I'll post links later--it's late and I'm beat), but I'm going to do what I can in the coming year to contribute to this area, which I feel is pretty lacking. Since I have a Java background I've been getting a lot out of reading the Java materials, but if we as CFers are going to take our craft to the next level and bring others along with us (kicking and screaming if necessary!), then I think we need our own set of knowledge and literature.


Finally, I'm in the process of rebuilding the Dallas/Fort Worth ColdFusion User Group web site, and I'm going to apply as many of these concepts as I can to this project. For the purposes of the site a lot of it may be overkill, but these sorts of projects are perfect for applying theories I may not have put into practice yet. Once I get the site in a better state of completion I'll share the code so others can learn from it (or rip it to shreds as the case may be!).


Happy Holidays CFers, and if you haven't made the commitment to start doing OOP yet, make 2005 the year in which you do it. Seriously. Not only is it a necessity from a career standpoint, it will make your development life easier and more fun, I guarantee it.


Comments


Can't wait to see your interpretation on the patterns with CFMX ( I mean that in a good way). I also think the reason you don't see OOP Patterns discussed in the context of CFMX, is because its regarded as a "Nice Object approach to procedure code". Thats what a lot of the purists have worded to me about anyway, saying its not even *REAL* OO - debatable. So yeah, J2EE seems to be a main source of mirrored conceptulizations which sux as you kind of need to know Java in many ways to understand it. I think we should all (blogs I mean) finalize one big uber blog-fest for 2005 on the subject, and PDF for the future CF'ers heeheheh...


Thanks Scott--I've certainly gotten a lot out of your conversations in Sean's Breeze room as well as from your blog. I definitely agree with the notion that we need to ban together and blog the heck out of this stuff, and I've already thought about a series of articles (instead of just blog posts) for distribution as PDF (or FlashPaper! go MM!) so it's a bit more easy for folks to take it along, print, etc. Once we all reach a consensus on everything (or even have 2-3 "best practices" for each of these areas) I think it will prove to be a great resource for CFers. Blog posts and subsequent comments (great place for us to hash out the details) can serve as great fodder for more formalized documents, tutorials, etc. (And let's not forget those who are OO newbies, because these are numerous with CF; OO-101 stuff would be extremely valuable in addition to more advanced topics.) On that point, the other thing I think CF literature does a poor job of is indocrinating people into OO from the start. Yes, CF is intended to be easy to learn, etc. and I don't think CF should lose that strength, but I think a lot of CFers don't get into OO because it's presented as "advanced" or "that weird other thing that a handful of people do." Once people get their feet wet with CF syntax, etc., OO should be presented as "the way you should be building things." In my opinion it's not gaining traction because it's seen as unnecessary or esoteric. Opening people's eyes to the huge advantages and presenting it as how you do CF will help in this regard. As for whether or not CF is "real OO," you're right, that's debatable. I don't typically engage in that debate because there's no denying CF is missing some hallmark features of true OO, but in my mind nitpicking kind of misses the point. (Not saying you do this, but some folks do.) Let's push things and do as much as we can with what we've got rather than not doing OO at all because this or that can't be accomplished in CF.

Friday, December 10, 2004

J2EE's Growing Pains

Given the discussion some of us in the CF community have been having lately about the affect alternative CFML engines have on CF as a whole, I thought this article about what's going on in the J2EE world these days was pretty interesting:

Alternative Frameworks: Bad for J2EE ... or Good?

On one front, the commoditization of things like app servers may lead to the big J2EE players to abandon their commercial offerings if they're no longer profitable. (I don't agree with this argument at all, but it's one that's frequently made.)

On another front, many in the Java world are challenging the complexities of J2EE and coming up with alternative frameworks such as Spring (dev framework) and Hibernate (persistence framework). These alternatives are more lightweight and easier to use than their heavier counterparts, but some argue that it starts to water down the standards.

On the CF side of the world, these arguments are very analogous to the situation with Macromedia's ColdFusion and New Atlanta's BlueDragon. Some think having alternative CFML engines makes CF less proprietary and strengthens CF overall, while others feel that it bifurcates CF and therefore weakens it. What are some of your thoughts?


Comments


I work for a very large non-profit health organization in the midwest and having an alternate engine has helped CFMX when it is called a proprietary technology. Especially when compared to .Net and J2EE, not that it should be but it happens.


I think competition is good in pretty much any arena. If you've got a viable product, you can be profitable, if you don't, then you won't. Especially in the enterprise software market, there is SO much more than the actual software to consider. One example is product support (paid or community). One thing that is missing from the CFMX/BD issue is a spec. J2EE is a formal specification, as well as a certification process for the spec. CFML, on the other hand, is whatever Macromedia makes CFMX do. Thus, you can't say what a "CFML runtime" really means. That, I think, hurts both Macromedia and New Atlanta, though the latter far moreso. Until there's a spec, CFML is absolutely a proprietary system, whether there are copycats or not. If one of those copycats can make a product that competes with CFMX, more power too them, but they're still a copycat. MM doesn't want competition, and why would they? Hence to CFML specfication, because they know that always playing catch-up will eventually beat every copycat product into the ground.