Rob's Ramblings

(Google had this cached, so I am reposting since this got lost in the server crash)

For pretty much my entire career, I have always been more of a backend developer. I would rate myself as "good" to "very good" in that arena, especially in ColdFusion. I'm not the elite level that is always on the cutting edge, but I provide solutions that work with always a thought to performance.

But when it comes to design and front-end, I'm average at best. Creativity has always been a problem for me. I have passable graphics design skills, but mainly when given ideas first.

I also have been held back by my work environment. The last five years I have spent working as a contractor for the Federal Government. That means front-end design is done to the lowest common denomenator. For a long time, that meant things like tables instead of CSS, little or no JavaScript because everything had be coded to work with or without JavaScript, and often times projects couldn't afford the hours needed to code things twice. And most important, Section 508 accessibility standards and a mandate that sites must work in a lot of really old browsers (as far back as Netscape 4 and IE5) the same as they would in modern browsers.

Recently, the noose there has been loosened some. The oldest browser we have to accomodate now is IE6. Still means a lot of potential issues, but less than before. CSS-driven sites are now options. Solutions I have proposed that use jQuery and AJAX are gaining more traction, and in a few rare cases an assumption that JavaScript must be enabled in order for the site to work have been added to requirements documents. On the backend, until yesterday I was stuck using CFMX7. Now we have CF9 at our disposal!

So what does this all mean? A chance for me to start spreading my wings on the front end. I have had some chances to tinker on side work that I do from time to time, and while they like the solid backend processes that I can offer them (making sites not just a marketing brochure, but a tool for their business) they are seemingly most keen on a catchy design that is pleasing. To accomodate this, I find myself wanting to build more in my design arsenal. I look at a lot of sites I find aesthetically pleasing and I'll jump in with Firebug and figure out what they are doing.

One design style I have become drawn to are sites built around large photographs as a background. I really think this is an easy way to spice up a site, and it's become so easy to optimize photos for the web that you can get great images at very little file size cost. I've taken to using "sprites" and CSS for not just navigation bars, but headers and other common elements to allow for a more graphically pleasing site with less of a file size hit only having to load one image for use in multiple places. And since everything I design is checked for 508 compliance, and tested with all styling turned off, I know that the important information will be found by everyone no natter what (and that spiders will read the site properly as well!

I am a huge fan of jQuery, and I know I have only scratched the surface in terms of its capabilities. If it is feasible, using AJAX and minimizing page reloads is a preference of mine, one I'd like to find more uses for.

In all of this though, I try and keep one overridding thought in my head: "Is there a need for this?" and "What makes sense here?". It's my logical brain getting in the way of my creative brain, I know, but I can see how easy it is to get carried away with bells and whistles. But in the end, the goal of the site is to impart information to the users, so it is most critical that the information be easily found.

In the end, I'll never probably be an elite level front-end or back-end developer. But if I can become "good" or "really good" on both sides of it, I think that can be quite a good calling card for the long run.

Comments are moderated solely for spam-prevention purposes.

A couple of projects I work in involve using SSL in some places. For the longest time I could never get SSL to work right with MAMP PRO (I have v1.84). Today I ran across a blog post that finally got it working for me.

http://www.rockettheme.com/blog/coding/310-getting-ssl-to-work-with-mamp-pro

On a legacy application that I maintain, I have seen a rash of errors recently that are new. They are all in regards to form fields missing on a form action page. The things that make this one different is that:

1. The fields in question are empty text fields, not unchecked radio buttons or checkboxes.
2. The browser type of all these errors in Google Chrome

Now, while the fix is the same for all of these issues (CFPARAM the form fields), I was wondering if others have been seeing this with Chrome at all, and if there's any insights as to why Chrome seems to not want to pass along empty text fields, like every other browser out there does. I have not played with Chrome at all, and our applications do not officially support that browser at this time, so I can't spend much time at all investigating these errors in light of that. So I am hoping that some of y'all might have some information you would be willing to share?

A couple of things have struck me so far as I have been trying out basic tasks in PHP to get a feel for how they work. One immediate concern I have right now is database security in PHP.

The first red flag I have is PHP's insistence that you type in a username and password for the database user in the clear in your database connection code. To me this is just asking for potential trouble. Let's toss out this scenario - disgruntled PHP developer gets the boot. You now have to go and change the database username and/or password on the server in order to make sure things are secure, because that coder has the information he or she needs to get in and screw with the database, not just via PHP code, but with any client tool (assuming they have access inside your network, and let's be honest rarely is there a time when a disgruntled employee isn't that way while still being employed). Even if you code smart and just include your database connection strings in a function so you only have to make the change in one place, it's still a change that shouldn't have to be made.

Compare this to CF, which sets the database access information in the datasource creation in the CF admin. This allows a lot more internal security, as the only people that really need to know that access information are the DBA and the CF administrator (in many cases I imagine this may be the same person). The point is that you can really compartmentalize this information a lot better in CF than you can in PHP. The developers need only know the datasource name, nothing about usernames or passwords are passed along in that. In the case of the disgruntled employee, their access to teh database comes in a totally separate login that can be more quickly locked down without affect to other accounts and applications in the case you need to do so.

The other thing that so far has struck me (and I am sure that this is a pure lack of PHP knowledge on my part, but...) is that there does not seem to be a PHP answer to CFQUERYPARAM in terms of speed and simplicity for locking down your SQL queries from injection attacks. It looks like I need to dig into the mysqli() functions from what I can tell, but they don't seem as clean as CFQUERYPARAM is. File this one not so much under "PHP can't do this", but under the growing list of "PHP takes a lot longer to do this than CF".

Thoughts are appreciated on how or why this impression is incorrect.

I recently made a switch in my hosting CFML server. All my sites on Viviotech (including this blog) are now running off of the Railo v3.1.1 CFML server. Railo is one of the two main open-source alternatives to Adobe's ColdFusion, and by all accounts that I can find, the far more stable and advanced one.

The move is primarily because of budgetary concerns, and there have been some tradeoffs involved. Railo v3.1 does not contain all the capabilities that ColdFusion 8 does. What it is missing though are not tags and functions I find myself using a lot, if ever.In fact, when I tested all my sites on Railo to see how they'd work, the only tag I found missing was the CFTEXTAREA tag. Why that one is not part of the current set I don't really understand, but I have faith that they'll add it in someday, and that's really more of an inconvienence than anything else.

That being said, the one aspect Railo is missing is an answer to the CFREPORT tag, and that alone is why I could never recommend it to my day job as an option (even with PHP looming and the high-licensing costs of CF as one of the main arguments the PHP people seem to have as reason to force a CF to PHP switch. We have one major site that uses CFREPORT, and reports created through the CF Report Builder program, heavily. In talking with some of the Railo folks, I have learned that they don't have it high on their list of missing features to incorporate, not many people use it, it seems.

I'm excited about the propects of open-source CFML, it will open a lot of doors potentially for CF coders to push their favorite web development language to new clients if the large costs of CF licenses are no longer an issue. And the Railo team has some heavy hitters in the CF community supporting it, which bodes well for its future in keeping up with what Adobe is offering. Even if the end result is nothing more than forcing Adobe to lower its prices in the wake of competition, that's a win in itself.