Entries for April 2006

Last night Josh Butler came across mxna saying that labs.macromedia.com was redirecting to a form to sign up for notifications about the flash player beta. At the time it was still working fine for me, but this morning I am noticing the same thing. Whats up I wonder? Could they be loading up Flex Beta 3? ;) p.s. Dont you love rumors! UPDATE: As of 8pm Central Time its back up for me. No beta 3 yet though... but I guess I can wait.

Posted on Tue. April 25, 2006 by Ryan Guill #
I was really hesitant to post about this, because so far I have been using it for about an hour and its quite slow and I dont really want all of you guys slowing me down even more, but I just had to share. So here is an hour's full of impressions. First impression: While slow, this thing has a TON of potential. I used to use outlook at my old job quite religiously, and while I still use it where I am, gmail has long since taken over as my primary email client. While I did use my outlook calendar a long time ago, I really haven't missed it too awful much since then. But when you do need one, you really need one. This, as it is refined and improved will quickly become my calendar of choice, that is certain. It already has all the features I need. A very sharp, familiar interface (if you are used to gmail), a great notification system consisting of emails (you can even get a daily morning reminder in your email of the days appointments), sms and even a popup if you keep the interface up in your browser, which I will. (although what is up with verizon wireless not being in the list of sms providers?!?! they are like in the top three providers in the country!). It has a great recurrance interface, which is very importaint, and the ability to have multiple calendars. You can share your calendars, which I haven't really tried yet, but seems like an excellent feature. And with my eventual move to Mac (its coming, I promise) I am really excited about the iCal integration. Its such a simple thing on the surface, but having built web calendar applications in the past, I know how difficult it really is. But they have really leveraged AJAX and other technologies really well to provide an all around solution. It is dreadfully slow for me so far (although I don't assume that its not my internet connection here at work either) but so was gmail at first. So overall, im quite excited and really looking forward to seeing this thing mature. So to try it out for yourself, go to calendar.google.com, and you might also want to check out this sitepoint blog post. Then again, this note from sitepoint does seem quite appropriate.... "And then [google will] know not only who you know, but also where you are. You may now choose to be afraid."

Posted on Thu. April 13, 2006 by Ryan Guill #
I have tried several times in the past to get subversion set up personally and never quite understood how the whole flow needed to go. But I think recently I figured it out and I want to share it with you in hopes that someone else might have an "ah ha!" moment like I did. Disclaimer: I am absolutely no expert. The flow I am about to talk about is most likely not best practice. It could screw up your stuff. Make sure you have backups. I claim absolutely no responsiblity for you losing your code... be warned! I think the biggest thing that has helped me start to understand this flow is eclipse with the subclipse plugin (and of course cfeclipse). The flow I am going to talk about is using those two components. I am not going to talk about how to install subversion, that is a whole different topic that has been discussed before so if that is your trouble point then I suggest commenting on those entries instead. Basically what I have learned is that you need to have a workspace (in both the eclipse and the general sense of the word) that is seperate from where you are actually storing the files. The tipping point is that each person that will be working on the code needs their own workspace, a place to pull the code into, work with, test against, and then commit from that point back up to the repository (from now on referred to as repos). So you will take the code you already have, wherever it is, and initially commit it to the repos, then pull out of the repos (checkout) into your workspace. Where we had a decision to make was where these workspaces would be in a multi-developer environment. Subversion was built with more of a traditional coding language in mind such as java (maybe it didnt, but it seems that way to me) and not really with web-development in mind. In Java, you are used to writing and testing code locally that you just put somewhere else to run later, with few dependancies. Well with web development, different webservers and application servers, this is a little harder to do. Initially we thought that we would just set up coldfusion and iis on each of the developers machines. They would code and test locally and then commit to the repos, and then we could pull a working copy out of the repos into our consolidated dev environment. But even with three developers currently this was going to be a major headache. We have many many datasources, many of which are seperate for dev, qa and production. This would be a maintenance nightmare alone, not even including mappings. It could definately be done, but even for one developer with a server that you were eventually going to deploy to, that is at least two seperate instances of cf that you have to maintain. Add in dev and qa environments and it just grows. A simple datasource addition becomes a major pain. Plus, you have the wories of your web server itself, in our case iis. If one thing is set up wrong with what you test against, your code may work fine locally but not on the server. So let me describe our setup here and then I'll let you know how we decided to go. Because our web department is relatively small so far, all we have to work with is one server. We have to use the same server currently for our dev, qa and production environments. Its not optimal by any means, but we have made it work. We are very careful with our cf settings to make sure we dont use many "dev" features. What we decided to do is to set up three different sites in iis, DEV, QA and PROD. They all use the same IP address and nat name (all of our work is internal by the way) and PROD just uses the standard port 80. DEV runs on 8001 and QA runs on 8000. So all of our urls are the same except for the port difference to switch between the different environments. Under our inetpub/wwwroot, we created a dev, qa and prod folder. So currently we have all just been working out of the dev folder, testing, and then when its good enough, we move it to qa and then eventually to production. Its actually worked pretty well, we aren't usually all working on the same thing so we dont have many conficts. We all have a mapped drive to the server and can just work off of the files as if they were local. But we want to switch to subversion and get all of its benefits. Like I already discussed, we dont want to have to go to developing on our local machines, so what can we do? What we decided to do is to create folders, on the same level as our dev, qa and prod folders, for each user. Mine is RGUILL. Then we set up another website for each user, with thier own port numbers. So now my port is 8005, and I know thats the environment that I can test in. In all of our applications, when setting up my application variables, we have logic that figures out what port the request is coming from and selects the right datasources and mappings accordingly. So for the user sites, we will just use the same datasources as dev, but we will still have to make seperate mappings for each. This is still much much better than having to maintain the datasources. Eventually we will have close to 300 datasources and that was our biggest worry. So now, we still have our dev, qa and production environments, and then we have each prospective users environment, like a pre-dev. We initally committed all of our projects, and then we check them out to our respecitive environments. We commit back to the repos and then we check out a working copy into our dev environment for our consolidated testing. Then we do the same thing for our QA environment when it gets that far and then eventually to production. So thats our setup. If there are any subversion experts in the audience, please let me know if you see anything wrong with this setup or have any suggestions. Or if this helps you, let me know that too! P.S. This way should also make it the easiest to work with when we move to seperate servers eventually. The subversion aspect wont change at all, we will still be pulling out of subversion into our respective environments, but we will have the multiple installations of cf. But it still wont be nearly as bad as having a cf setup for every developer, which hopefully we will have more and more of as we go along.

Posted on Tue. April 11, 2006 by Ryan Guill #
Everyone else seems to be doing it, and everyone keeps telling me I need to update my blog more, so heres a win-win... Four jobs I have had in my life (the most recent four-ish): 1. Cook - Whaler's Catch (Cajun / Seafood) 2. Web Developer - Schroeder Publishing Company 3. Private Consultant 4. Consultant - TruGreen Chemlawn / Servicemaster Four movies I watch over and over: 1. Blade (I, II or III) 2. Rounders 3. Godfather (Any of them) 4. Office Space Four places I have lived (really only three, although I have lived in several houses in most of these places): 1. Paducah, KY 2. Reidland, KY 3. Collierville (Memphis), TN Four TV shows I love to watch: 1. Grey's Anatomy 2. American Idol 3. House 4. West-Wing!!! Four places I have been on vacation: 1. Destin, FL 2. Washington DC 3. Biloxi, MS 4. Heber Springs AR Four websites I visit daily 1. MXNA 2. Google Homepage 3. Flickr 4. Kottke.org Four of my favorite foods: 1. Spaghetti (sketti), (anything italian for that matter) 2. Steaks/Chops (I love to grill) 3. Tater-tot Casserole 4. Chili Four foods I dislike: 1. Coconut 2. Pineapple 3. Lima Beans 4. Kraut

Posted on Thu. April 06, 2006 by Ryan Guill #
For those of you interested, I have set up a quick and dirty create script for MySQL 5 for Ray's Canvas Wiki. You should see the download link on this entry. I dont know enough about the wiki be certain that there is nothing wrong with it, but at first blush it seems to be working fine. Let me know if you have any trouble with it.

Posted on Wed. April 05, 2006 by Ryan Guill #
One of the things you see a lot in open source php applications is "installers". Basically, the first time the application is run, the application knows it needs to be set up, and so redirects to a setup page that asks you to fill out a lot of settings and such. But you don't see that very often in cf applications. This is something I am probably going to try to work on soon, and try to figure out some of the best ways to tackle the various situations you have to deal with. Does anyone know of any open source applications that have a "setup script" or installer? And would there be anyone interested in a blog post or article describing how to create one? Some of the things you could do with an install script would be to set up the database (if you knew the admin password), you could even have it where you could choose your database type, it would set up the database and run the appropriate sql, it could set up any configuration or ini files for you, it could set up any basic users, as well as other things. I will be working on this mainly for internal uses for applications that we have to install on several servers, but I will probably be incorporating this into some of my open source projects, current and upcomming. Anyone interested or have any insight?

Posted on Wed. April 05, 2006 by Ryan Guill #
Design, Photograph, Work © Ryan Guill, aDeepBlue 2013: All Rights Reserved. | Contact | RSS Feed