For the last few months my wife and I have tried to put together a dinner menu for the entire month, in advance. Sounds crazy, right? The reason for doing this is three-fold: We eat healthier overall, because we plan fruits and vegetables on a regular basis instead of haphazardly having whatever sounds like it will go well; we get an entire month's shopping done in one day (except for additional milk, eggs, and bread that we sometimes pick up on our way home from work), instead of going "big" shopping every other week; and we save money, because we only buy the food that we know we will be eating, instead of stocking up on 6 boxes of fish-sticks because they are on sale.
The process goes something like this:
- Pull out the list of dishes that we can make and eat frequently. This generally has about 15-20 dishes. It also has a column of our favorite side dishes (pasta, rice, crescent rolls, etc), and a column with fruits and veggies that meet with our picky approval.
- Check our social calendar for nights we know we will be out, or will want something easy (order pizza when we're hosting poker night), and fill those blocks in first.
- Then fill weeknights with easier meals, because nobody wants to come home from work and spend 4 hours over the stove. All the while, be sure not to schedule two chicken dishes near each other, and the same for beef, pork, pasta, etcetera.
- Fill in the weekends with whatever meals are left over - generally something more elegant or labor intensive.
- And finally, go back and match up side dishes and fruits & veggies to meals they would go well with.
After spending 4+ months doing this manually, we've become tired of the process.
And so, this has been a very round-a-bout way of announcing that I will be writing a tool to do this for us. So far it's working title is "CFMenuCal" - though that's the second name I came up with, and I had already submitted the project to RIAForge. Hopefully I can change the project name once it's been approved.
The original name was "CFEventCalendar" but once I started writing this post and thinking about how I was going to implement it, I realized how specialized it will need to be and thought that I had better go ahead and gear it towards creating menus from the beginning - not just as one use for it.
Posted in
CFMenuCal |
ColdFusion |
My projects
May 16 2007
Thank you for completing the Scorpio Participation Survey and for your interest in Scorpio Prerelease Program. After the Product Team reviews your responses, you will be notified with an email.
Sincerely,
- Adobe Prerelease Programs Team
When I completed this "survey" a week or two ago I was under the impression that I was too late in the game to get a shot at beta testing, but if I heard Mr. Adam Lehman correctly at the CFUG meeting, he was encouraging us to do just this, if we hadn't already. So, now the roller coaster that my hopes and dreams ride with every exciting opportunity that comes along is on its way back up another hill!
Posted in
ColdFusion |
Scorpio
May 16 2007
Of course there have been numerous blogs about features announced at other meetings (I liked this one, and this one, among many others) but tonight I attended our very own CFUG meeting, and not only that, it was my first.
Among all of the new tags and functionality announced, I think I'm most excited about the return of the debugger, the new image handling, the ability for CFLoop to natively parse files (by line, or by bytes), the server monitoring utilities, and of course the AJAX tags. I would have liked to have seen the debugger in action, but we were pushing 3 hours as it was with fairly few questions, and had to bail before they started drawing names to give away schwag (including a copy of Scorpio itself!), since my carpooling buddy was out passed his curfew.
The CFPDF tag set looks interesting and very useful, but my current clients don't do a whole lot with PDFs and my past clients only made limited use of PDF forms. I can see that it has great potential, but I don't see myself putting it to great use for a while.
One thing that this has reminded me of, for sure, is that I have become very comfortable inside my box. For the most part, the things that I've been developing could run just fine on CF5. (I blame the customer!) I have come away from the meeting inspired to learn some of the great things that MX7 made available, but at the same time, I feel like I'm already spoiled and have absolutely no motivation to try and learn AJAX "the hard way." Why should I bother, when I've seen how easy it will be in just a few short months?
I'm not sure how much of this has already been announced, but here's a list of stuff that caught my attention enough for me to write down:
- New Database drivers: SQL Server 2005, Oracle 10g, MySQL 4 & 5 (finally!), PostgreSQL 8, and more!
- Nested CFTransactions!
- <CFDBINFO> - Interrogate a database for its tables, procedures, views, etcetera.
- Even though there is a heavy (unofficial) lean towards Eclipse being the standard IDE, they are continuing to develop RDS, i.e. the new security features and user roles. Am I mistaken, or does Eclipse not work over RDS? Is this just an effort to support both, or some sort of unresolved confliction within the team?
Posted in
AJAX |
CFUG |
ColdFusion |
Scorpio
May 15 2007
As I mentioned two weeks ago, application.cfm tweaking is important, but reaching the best compromise between efficiency, readability, and functionality is highly subjective and there are exceptions to every rule.
The question of how to manage application.cfm in multiple environments or between servers in a cluster is one that every developer you asked would probably answer differently. You could have separate versions of the file for every server, you could have a flag set at the top that indicates what set of code to run, you could check CGI variables... there are a hundred ways to skin a cat.
My personal preference is to use CFFile. But before you start to criticize me based on the overhead of reading a file, hear me out. If you still disagree with me, feel free to leave a comment to that effect!
Before diving in to the code, let's consider some rules of thumb.
- You want your production environment to be the fastest path through the code, for what I hope are obvious reasons.
- You want the default case to be production, so that if all else fails, at least production will work.
- Your solution should be extensible and scalable for the addition of future environments.
I will admit up front that more overhead is required to use a CFFile tag than to check the contents of a CGI variable or request scope variable, or quite possibly any other method. But with that said, this method is set it and forget it. In order to implement this method, we need to add a small text file to every server.
C:\env.txt on my development server:
DEV
I'm sure you can extrapolate this to be applicable for your other servers, right? Test should say "TEST", Staging should say "STAGE", and so forth. With one exception: Don't create a file for Production. Or at least, you don't have to. And your code will run precisely 4.3 iotas of a second faster if you don't. Because once you've created these files, you should add this code to your application.cfm:
<cfif not isDefined("application.env") or isDefined("url.resetAppVars")>
<cfif not FileExists("C:\ENV.TXT")>
<cfset application.env = "production">
<cfelse>
<cffile action="read" file="C:\ENV.TXT" variable="application.env">
<cfset application.env = trim(lcase(application.env))>
</cfif>
</cfif>
Now, going back to my three rules above:
- Production is the fastest path through this code, assuming you don't create the ENV.TXT file in that environment.
- The default case is production: If the file doesn't exist, assume production!
- Scalable? Check! Adding a new testing server called Test2? Make it's file contents "TEST2" and you're off and running.
Now that you've defined your environment, it's time to set some environment specific variables. Hopefully you remember that you should only set your application variables when they don't exist in memory! I've already demonstrated how to accomplish this above: Check whether or not one of them is defined first. And while you're making that check, you should always give yourself the ability to refresh them at your will, which is why I included the check for the variable url.resetAppVars. Instead of restarting ColdFusion services to reset your application variables, you can simply append ?resetAppVars=true to your URL.
When setting your environment specific variables, the same rules apply: Production should be the fastest path through your code, the default case, and your solution should be easily scalable. I like this approach.
<cfif not isDefined("application.myVariable") or isDefined("url.resetAppVars")>
<cflock scope="application" type="exclusive" timeout="30">
<cfif application.env is "production">
<cfset application.myVariable = "my value for production">
<cfelseif application.env is "dev">
<cfset application.myVariable = "my value for development">
</cfif>
</cflock>
</cfif>
Posted in
Best Practices |
ColdFusion
May 09 2007