1. Write tests first – This is not just a good idea, it’s the law. For the past few years, I have been very interested in test driven development, but have not put the time aside to learn it. Starting to work on my current project was trial by fire. I need to quickly learn to use the tools, and learn to think about tests correctly. Without getting too extensive, I can now say that I am finally a TDD convert. While my first few weeks (months?) at it seemed very much unnatural, it is finally starting to sink in. I will probably write more about this later, but suffice it to say that; in software development, as in life, satisfaction is much easier achieved when your expectations are clear.
2. Coding standards are a good idea – I have worked on several teams where, after just a few weeks, you could tell who wrote a block of code just by looking at their style. I always thought this was just how the world worked. I thought this was just another way that we humans expressed our individuality. This actually makes code harder to read and messier for everyone involved. Memory and hard drive space are cheap. You don’t need to name a variable: tds, when total_dollars_spent is much easier to understand. Most modern IDE’s will do all the typing for you, which leads to another point:
3. IDE’s are not evil – I have used emacs for a million years. I have never really used any IDE extensively in the past decade. In talking to old school developers, most will cringe and whine if they were told that they were required to use an IDE. I decided to approach the adventure of learning a new IDE as, well, an adventure. I could write a whole article on this, too, but suffice it to say that using an IDE (RubyMine in this case) made my productivity surge. Sure, you have to learn a few other keyboard shortcuts, but it took less than a few hours. Sure, there are things that textmate, emacs, et al do better, but no system is perfect. IDE’s have come a long way in the past decade. I won’t bust your chops for using one.
4. Just because it works, doesn’t mean it’s submittable – If your code works, but it’s ugly and fragile, it’s sub par. You know that blob of code you wrote. it works. Even though it works, you pray that the day never comes where you have to edit it. When that day comes, it will drop like a house of cards. When you have this in your codebase, it is not acceptable. Fix it before you submit it.
5. Refactoring is not a luxury, it’s your duty – There is always a balance. A project has to be done. It has to work, and it has to be delivered on time. That is still no excuse to submit code that has repeated itself or that is downright ugly. Again, you know what this code looks like. It’s that messy, twisted pile of shart that you are hoping nobody will stumble onto. Chances are, they won’t. If they do, they are gonna be pissed (if they have learned any of the above lessons anyway). So, refactor your code. It will make you a better developer.
6. Developing really has nothing to do with language semantics – Anyone (within reason) can write code that works. Working is not that big of a deal. There is much more to learn than bending a language to your needs. Learning to model what is going on in the real world effectively and concisely is a much more important skill than anything else. Learning how to understand when someone explains the above, then explain your ideas to someone else is even more important. Noodling out complex ideas, then learning to model them and explain those models is the crux of the entire problem.

Okay, I have prattled long enough. I think in the next few weeks, I might expound more on each one of these points with some real world examples. Not snippets of code, but sight sights, smells, and flavors. A whole different world than I am used to. Rather than banging out code that works, learning to bang out code that is sexy.

My goal for the next few years? Learn to write code like a world class chef, rather than the grill jockey at the local burger joint.

We are getting very close to this world today, and unfortunately, I am seeing the weaknesses. In my pocket, I now carry a smart phone that can do all of the things mentioned above. Yes, my cell phone is straight from the bedroom of Elroy Jetson. So, why am I not satisfied? I think that there is still a good place for single purpose devices. I think I am falling back into love with these devices.

A few Examples?

The kitchen timer

I like to cook. I find that I am always needing to time something in the oven. The oven has a timer in it. You have to fiddle around to get it to work. The microwave has one, too, but when you set it, someone always resets it by putting something in there mid cooking. Wait! My smartphone has a timer app! Unfortunately, there is much fiddling around to get that to work.

Enter the humble kitchen timer. I need it to ring in an hour and a half. I set it, and forget it. I need to work in the garage for a bit? No problem, I can drag my timer out there. It never fails. It just rings when it’s done, and it’s totally portable.

The Wristwatch

Now, more than ever, the current time is a big deal. I seem to need to be somewhere (on time) several times a day. Yes, my smart phone can do this! All I have to do is: dig it out of my pocket (try that while driving), unlock it (i keep financial data on there), wait for it to fully wake up, and then, read the time.

With a wristwatch, I just need to turn my wrist and look at the face. In milliseconds and no fiddling, I know what time it is.

The GPS

My phone can even be a GPS! It can route me where I need to go, and give me turn by turn directions. The only problem is, it KILLS the batteries, so i need to make sure I keep my charger with me. Every time I turn it on, it takes a few minutes to figure out where I am. When someone texts or the phone rings, my directions stop working. This is not very good when this happens as I am negotiating an upcoming offramp.

Enter my TomTom GPS. I just turn it on, select a destination, an go! It sits there, doing its thing without any other interaction from me.

The Camera

My smart phone even has a camera! It has a video and a still camera! If i want to make a video or take a photo, all I have to do is: unlock my phone, wait for it to wake up, turn on the camera, wait for that to wake up, select the proper mode, and wait for the camera to be ready to shoot. Oh, and I have to make sure that everyone stays still long enough for the camera to actually take the photo.

I also carry a nikon point and shoot camera. When I want to take a photo, I just turn it on, and shoot! I don’t have to wait for anything to wake up and start up. It is a camera. It was made to take pictures, and that’s all. It does so brilliantly.

The Kindle

My phone can also pull all of my kindle books into it. I can even do this on my computer. They all sync, so I can keep my place wherever I go. Unfortunately, the same rules apply. I have to fire up the app, wait for it to start up, and then be subject to all the other distractions of a smart phone. Texts, emails, phone calls, etc. All of these take an incredible toll on my concentration and patience.

A Kindle device, on the other hand, just reads books. You can turn it on, and it’s exactly where you left off. It doesn’t try to remind you that life is out there, ready to assault your leisure time. It doesn’t try to send you messages from your peeps. It just reads books.

Am I Old Fashioned?

I think the jury is still out on that one. I think I am just growing weary of the endless fiddling that goes along with doing something as simple as timing a loaf of bread in the oven or taking a quick photo of something that is interesting.

What about you guys? have you grown weary of the fiddling yet?

It also served as a place for prospective students to learn more information about their educational pursuits, including the closest locations to take required courses.

The site provides an innovative system that allows users to quickly drill through courses of study and examine the requirements of each. This is followed by the generation of a map that pinpoints the location of each class requirement.

Technologies Used:

• Ruby on Rails – Of course this was a great candidate for rails. The backend required some (but not a ton) of ajax magic. The URLs were well defined, and most of the actions of the site consisted of manipulating scads of interrelated data. We used rails on this one so that we could quickly take advantage of the advanced scaffolding abilities of rails.
• RedCloth – Since there was a great deal of text to lay out, and on one REALLY uses html (do they?) to layout static text, we used textile to make text layout more sane.
• Git – Once again, a ton of people were going to be editing the code and assets. One day, I might write an article on why I have chosen git over the other SCM’s out there. I have used them all (except mercurial) and found that git makes source code management much more clean.
• Ajax(programming) – There is a great deal of data moving through the pipe, but not much need for UI updates on this site. This made it a great candidate for ajaxifying many of the UI elements. You really have to fiddle with the site to get a feel for what is going on.
• Google Maps API – There are lots of nifty tricks going on in this one. We found a list of lat/long points that defined the counties, so there is a county overlay on the map. There are custom markers. Once again, if you poke around on the file, there are surprises everywhere.

I worked with Carl and Maryanne Nestor on the design.

The site currently:

• Lets users sign up for an account and add their own sightings.
• Comment on the listings of others.
• Search by free form string.
• Built in Ad system. Allows a repository of Amazon ads to be served on the front page.

Some plans for the future:

• Allow users to sign in via facebook.

Technologies Used

• Google Maps APIs – All of the mapping and geocoding of addresses uses the Google Maps API. The fact that this API is free for anyone to use is incredible.
• Ruby on Rails – I initially wanted to use Seaside to build the project, but the deadline was too close to mess too much with a technology I hadn’t done a full scale project in yet.
• Git – We used git to keep the CSS and HTML templates updated.
• Blueprint – There are too many bonuses to using blueprint to list. Most importantly, no fiddling with finicky CSS rules to get it to work across the different browsers.

We have recently launched the Catholic Athletics website for the guys over at The Saint Sebastian Fund.. The site serves as a clearinghouse for Catholic schools to list their current needs for athletic gear.

Once a need has been listed and approved (via several manual and automated checks), the project goes live, and users can make donations to the listing of their choice. Donations are made via paypal. When a project is fully funded, the school receives the funds and is able to purchase the equipment.

This project was a little different than most any of the projects I have recently worked on in that as it was a project for a non profit, a great deal of care went into developing the flow of the project status and associated legal issues.

It is currently alive and well and generating funds.

Technologies

This site was developed using:

• Ruby on Rails – As there was an incredible amount of object data being held for donors, schools, and projects, we decided that an object based solution would need to be implements from inception.
• Git – All designs were implemented by Jeff Davidson. This meant that the CSS files and templates were scattered a bit. In pretty much all cases (even cases with a sole developer), we use Git to track revision changes for the site.
• Blueprint – when developing informational sites, it’s a very bad idea to rely on css rules to build the site. We always use a template system of some sort. We try to use blueprint when possible, as it’s quick and easy.
• Prototype – Yes, we are well aware of jQuery but the functions we needed were native to rails and prototype, so we decided against loading up another library. Should our needs expand in the future, we might decide to work with jQuery.

If you have any other questions or comments on the development of this site, we’d love to hear from you.

One of the by products of using PierCMS is that it includes the data (GET vars) in the url that connect the browser instance (or tab instance) to the session on the server. For awhile, I thought it was just a cosmetic thing. Seeing that URL bugged me. It just seemed ugly. I thought that I was just being OCD about the whole thing, until I started seeing other repercussions of these URLs.

What I found was that since adding the session data to the URL, by its very nature, makes the URL unique. I didn’t think too much about it until I started adding features to the site. The two that I found were:

Using Bit.ly

In using Bit.ly, one of the things that is ultimately important is being able to accurately account for how many people are forwarding your link. I started to make a habit of clipping out the session data from my url before I shortened them. Then, I started to see that not only was I sending my URLs around twitter, but so were others.

I then saw that while my stats should show links to the same story linked to the same URL, it wasn’t the case due to the extra unique variables at the end of the url.

Facebook Like

While I have not done any testing on this, I have noticed odd behaviors with the facebook “like” button. Since the Facebook “Like” button operates on the URL, I have a sneaking suspicion that this is at play with the facebook like button. In the past, I wrote a component for PierCMS that would insert the Like button into a story, I clipped the variables from the URL, but unless you think about it, you might not do that.

One BIG gotcha

There is one gotcha in all this. Pretend you just published a story on your blog/podcast. You are excited about it, so the first thing you might do is: send it to twitter, facebook, and hacker news. You most likely do this within minutes of writing your post.

Unless you think about it, your first instinct would be to swipe out the url, and send it along on its way. You do this, and continue working away on your site.

Here’s where it gets scary.

Since you sent the full url, anyone who clicks on that link will have full access to your session. This means that they will be logged in as you (probably with admin privs). This will be true of that link as long as that session stays alive on the server.

How to fix all of the Above

While I haven’t fully tested it (working on that now) it seems like an easy enough fix. Here’s what you do:

1. Update your Pier Image to use cookies – Go into your /config/pier (or wherever your pier instance is mapped) and scroll down to the “Use Cookies” option. Click “Override” and set it to true.
2. Go to your /status page, and clear all sessions.
3. Clear all the cookies in your browser.

This will store the session data in your cookies. The one thing to keep in mind is, any other views of this url in this browsing instance will use the same credentials. Keep that in mind if you are used to using different windows for testing.

Last year, I discovered the podcast Techzing. If you have any interest in entrepreneurship or startups, and have a more than average technical background, you really must listen to this show. It discusses all of the above in an incredible amount of detail. I have found that I go back and listen to shows again, just so I can take notes.

One of the questions they ask guests is to list off technologies that they are embarrassed that they don’t know. At first, I thought it was interesting to hear what people were unfamiliar with. Then, I realized that it was pretty scary to make this list for myself. But I did. It’s even scarier to share it with the world. But I am. I am doing so in the hopes that it will force me to fill these gaps in my knowledge.

So, here goes, the list. The list of things that I am embarrassed that I don’t know, or don’t know well enough:

The List

Scaling

In a good deal of cases, the first thing everyone wants to discuss in an initial meeting about a project is scaling. What do we do when this project becomes the size of facebook or google? My first instinct is squelch this conversation. Why? Not only because I don’t know the answer, but because I am certain that no one in the room knows the answer. There are no scaling gurus in the room, so it’s pointless to use up our time on this conversation without a guru around.

I must also confess that I have never worked on a project that blew up to be as big as facebook or google. I would guess not many of us have.

While I do have a vague idea of scaling and how it works, I have never put my nose in the books and made it happen. I have never load balanced 35 web servers and 45 database servers because so many people loved my project. It has just never happened.

My guess is that until this happens, I will never go further than read the odd article on scaling and tuck it somewhere in my brain. Hopefully, soon, I will need to address this weakness.

Test Driven Development

Sure, I have gone through all of the tutorials in every possible language about test driven web development. I have watched the videos, and compiled a bunch of tests. The problem is, as of yet, I have not incorporated it into my daily life. Why? I really can’t say. Every time I try to start a project out using test driven development, I seem to feel like I am contriving tests that I know will pass or fail, just for the sake of writing a test.

I am sure that the ingredient I am lacking is the ability to mentally compose what would be a good test. When that happens, I am sure I will be right on it. Alas, this day has never come. I am sure it will happen one day while talking to another developer, and I will feel like a giant heel.

HTML5/CSS3

Yes, I have read all the websites, done all the tutorials, and sorta kinda keep up with it. In the back of my mind, I know I should get on this. In the front of my mind, I just keep thinking that I will spend the time to learn it when more browsers adopt it. I have a suspicion that when everything does catch up, it won’t take me long to figure it all out, but I am just not obsessed with the technology.

Sure, I love it, and I understand its importance. I think that since I am not a designer, I don’t really spend too much time trying to figure out the potential. But yes, I do understand that I am lacking by not being super hot on this technology.

NoSql Databases

I love the idea of NoSql databases. When they first started arriving, I installed them, did some testing, wrote APIs in a couple languages, but I never did anything fun with them. The sad part is, I actually like the technology. I just don’t have the time to devote to getting mighty with them.

Worse yet, I haven’t used them enough to even have a feel for when then would be a better tool in a situation than a sql database. Maybe this summer, I will launch a project just for fun to become more immersed in the technology.

Javascript

I’ll admit it. I haven’t used javascript in years. With the plethora of awesome javascript libraries, when I needed to do something javascripty, it was always pretty easy to implement using one of the libraries. Especially with Ajax, it saved me from a bunch of fiddling around trying to get every browser out there to bend to my will.

Pre Ajax, I wrote a good deal of javascript. I can still do it, if I have to, but my javascript coding usually involves referencing the book a million times. I can’t fly through it. Post Ajax, the tools out there were just too great. Lately, I haven’t had any javascript heavy projects, so I am hoping I will be okay until it’s time to hook JS, HTML5, and CSS3 up.

Nodejs

Every time I look at this project, it makes me want to start a project with it. Unfortunately, I still haven’t heeded that call. I really need to, as this technology really fixes a great deal of things that were a pain to do without it.

After hearing how Jason Roberts uses nodejs, in his limo tracking program, I am so intrigued, yet so embarrassed that I don’t know it.

Java

I used to be a good java developer. That was many years ago, before the advent of mobile devices. To develop for the Android device, I need to get my java game back on. I have let my java skills slip into a terrible state of disrepair. I know that it would just take a weekend of piddling around, but I just haven’t done it yet. I think the biggest reason is that I am unsure of how profitable it would be to launch an Android app.

If I could convince myself that this would make me a killing, I would definitely hit the books.

In Closing

So, there you have it. The list of things that I am embarrassed that I don’t know more about. Maybe this year is the year I get my game on.

Now that my weaknesses are out of the bag, you can go here for a list of things that I do know how to do.

I have worked on several development teams over the years, and while I understand the reluctance to try new and exciting things on the part of management, I have still never gotten over this reluctance in young developers.

I should preface this by saying that I am not bashing younger developers, I am just sometimes disheartened to see that sometimes they aren’t as obsessed with it as I am. Maybe I am just too obsessed, and I take this all too seriously. Then again, it’s what I do for a living.

If there is a new technology or idea that will save me even five minutes a day, I am totally willing to learn it and adopt it until it deprecates.

So, here are some things that I have found lacking in the arsenal of a good deal of younger developers I have worked with:

The List

They don’t know more than one language

When I suggest that a problem might be tackled much more effectively using another approach (another language), it becomes quickly apparent that the developer doesn’t know any other languages, and while they might be a little interested in looking at another language, they are in no way serious about learning anything new.

Many times, they will make fun of other languages, and poopoo the stereotypical programmer of that language (or poopoo very important language concepts!). This is very unfortunate.

As a developer, you really should expand your horizons into other languages. Seeing how other languages tackle problems encountered in programming and understanding why those problems exist is monumentally important in developing the mind of a programmer.

They Don’t Know a Web Framework

Web frameworks are incredibly productive tools. There are lots of problems in trying to impose state on a stateless protocol. There are lots of novel approaches to mapping data models to databases.

The biggest reason I hear for not working with a framework is that they already have a pack of scripts they wrote, or worse yet, their own framework that they use.

There are some VERY smart people out there working on the problem. The ability to look at their code and their methods for solving the problem is very much worth the price of admission (free!). I you are in this boat, I would really suggest you take a look at a web framework. Try a small project in it, and see what you think.

One of the things that worries me about this is that these people usually have an employers who (even though indirectly) is paying them to reinvent the wheel every project.

They Don’t Use Version Management Tools

I have worked on teams where everyone worked on live code. I will get into why this is a HORRIBLE idea in a minute, but when there are three or four people working on the source code, you really need to have a version control system in place.

The biggest reasons cited for bypassing source code management are drive space and conflict management. In all reality, a source code project is tiny. It doesn’t take much space on each developer’s system at all. It’s most likely a negligible amount of space. If you are really worried about managing conflicts in your code, you are absolutely in danger of having problems with a team of developers working on live code.

Editing Live Code

This is probably the scariest thing I have ever seen, and I have seen it a few times. Here’s what it looks like: A production codebase sits on a server. Multiple instances of that application run on that same server. As changes are required to the code, the production codebase is edited directly.

Well, if there is one thing I have learned is that a great deal of the time, code I write doesn’t work on the first iteration. I write it, test it, and see if anything breaks. A lot of times, it breaks. Working on live code, if you break anything, all your clients’ code gets broken too. All their visitors are subject to your errors.

If anything happens to the system it’s running on, or any other hiccup happens, the whole system is in jeopardy. Words can’t express what a terrible idea this is.

They are Slaves to the Mouse

Maybe it’s because I learned all this stuff in the beginning with emacs. Maybe it’s because I have always learned the keyboard shortcuts for every app as soon as I started to learn it. I can just work MUCH faster with the keyboard. It seems to take up a bunch of extra time every time I have to fumble with the keyboard.

Maybe it’s because I am getting old that I can’t stand to watch someone pressing mouse buttons for every task that happens when developing and application. Whether it’s uploading code, compiling, or anything else. You really can move around much quicker by learning the keyboard shortcuts.

This also applies to the command line. There are lots of tasks in development that are just much faster when using the command line. Sure, there are lots of gui tools for pretty much everything, but there is an inherent cost in time for using those tools.

Unfamiliarity with Linux and Server Tools

When you develop a web application, chances are very strong that you will be using a slew of tools that you can run on your own development machine. These include programming languages, web servers, database servers, and the like. Believe it or not, it is much simpler to go bananas on your own machine, forking the codebase and testing out your ideas in a sandbox than it is to edit live code on the server.

If you want to be really efficient, you should take a look at starting up a development environment on your development machine.

In Closing

I really hope I haven’t offended anyone. That was not my intention. I think my intention was really to point out some very dangerous or inefficient practices that I see almost daily. To document them in the hopes that if your company or project is using some of these practices, you might think about changing them.

If you need any help or guidance, let me know.

This has many benefits in the realm of taxes and paperwork, but it causes other problems. Each user needs to run their own cash drawer, each user has to run their own books, and do their own sales tax reporting. This means that there is alot of overhead in the management of each stylist.

I have tried to think of as many different ways to attack this problem programmatically, but I have found that there are many different facets to the problem. Part of the reason I am writing this entry is so that I can think this through and come to a conclusion. The other part of me hopes that someone will give me a good answer and ease my pain.

So, the problem is, I would like to write a software solution to the above problem. A solution that allows stylists to take care of their scheduling, their appointment histories, take photos of client’s styles, and in the background, generate reports for taxes and income.

The trick is, how to proceed.

It Must Make Money

In the end, I provide for my family by writing computer software. While I love to write software, I still need to make money at the end of the day. I also think that my skills are valuable, and that providing a tool that provides value to a user should provide financial value for me.

At this point, I need to decide a few things. First off, the pricing model. I would much rather charge a monthly fee. This would allow me to keep the initial expense low (somewhere around $10 a month). If I were to charge enough to make my money up front, the initial expense to the user would be much higher.

I need to think this through, but I think this might be the way to go.

Which Platform to Develop for?

Like everyone else, I have heard that the iPhone is coming to Verizon next month. This is what got me to initially start kicking this idea around again. That, and the advent of the Apple App store.

While I do think it would be best to develop for all the platforms at once, there is no way I can do this all at once. As a test for the viability of the product, I would like to write one solution, then, if there is sufficient demand, write for the rest of the platforms.

So, I am compiling a quick pros and cons list to help me decide.

Develop a Web Application

Pros:

• I already know how to develop web apps. I wouldn’t have to learn anything new.
• Easy to implement. It would be be really easy to deploy a first crack at the problem, and update the the site in real time. As feedback was received from beta testers, it would be easy to change the codebase and have everyone access the new changes immdediately.
• There is a lot of screen real estate. You have lots of room to play around with.

Cons:

• The salon would have to have an internet connection. While I am guessing that most do, it still means an extra expense of $25 a month for those salons who don’t have wifi already.
• It would be less messy if the salon only had one machine running a web browser on site. This would mean that the users would have to log in and out of their accounts every hour or so. If someone else was running their clients through the system, that would mean they would have to wait. In a salon of more than five people, this could be a real pain.

Develop and iPhone / iPod Application

Pros:

• I already know how to develop iPhone apps. I wouldn’t have to learn anything new.
• Users who didn’t want to run with a data plan could run the program on an iPod touch. This would allow for most all of the same functionality, and keep the cost of entry (and the monthly data plan costs) to a minimum. Should any functionality require access to the net, it could be done via wifi when available.
• With Verizon picking up the iPhone, there is a huge user base coming to the iPhone.
• The hardware platforms are extremely limited. This means that the user experience is easy to predict.

Cons:

• Most of the stylists I know do not have apple products. Most of the smart phone owners are using Android. At least in this area.
• There is a good chance that an application could be denied for inclusion in the google marketplace.

Develop for Android

Pros:

• Lots of people I know who could be potential beta testers have Android phones with data plans.
• There is no waiting period for submitting apps in the Android market place. They can even be downloaded directly from the developer.

Cons:

• I don’t know how to program for the Android. While I do like the android OS, and I do know java, I don’t know much about what goes on under the hood.
• There are lots of variations of Android running around. It’s really hard to predict what the app is going to look like for an end user.
• While there are some products on the horizon, there is no Android device in circulation that can live on its own, without the need of data plan.

In Conclusion

So, there you have it. These are the things I have been mulling over for the last few months. While I am still not sure exactly how to proceed, I think I might start with the iPhone/iPad, and go from there.

But! I would still like to get more input from the outside world.

Without going into too much detail and stirring the pot, I will just say that it’s a very good idea for your site to have a facebook “Like” button if you are looking to gain traffic by reference. So, if you agree, and you are running a PierCMS site, try this trick to include like button.

How to set it up

1. Add a system component for html to your site. I called mine “facebookLike.”
2. Into that component, add the following between script tags:

var url= (document.URL);
var base_url = url.split('?',1);
base_url = escape(base_url);

fblike="<iframe src=\"http://www.facebook.com/plugins/like.php?href="+base_url+"&amp;layout=standard&amp;show_faces=true&amp;width=450&amp;action=like&amp;colorscheme=light&amp;height=80\" scrolling=\"no\" frameborder=\"0\" style=\"border:none; overflow:hidden; width:450px; height:80px;\" allowTransparency=\"true\"></iframe>";

document.write(fblike);

How to use it

Wherever you would like it to show up, just include:

/system/components/facebookLike

I put it in my environments right before the /system/components/contents tag on each page, so it automagically shows up everywhere.

What it’s doing

There is really nothing to this, and it can really be used on any site that doesn’t send over a pile of GET vars to render a page. But for those who are using PierCMS, it just:

1. Grabs the current URL.
2. Strips the extraneous session vars (anything after ‘?’). This is more important in PierCMS as it’s Seaside based, and retains a bunch of stuff in the url that can be left off for a cleaner url.
3. Inserts a correctly formatted like button according to the FaceBook Like Button API .

So far, it works great. Let me know if you run into any troubles. Note that you can make several adjustments to the button, but it might be easier to just go to the like button page and get your iframe script, and substitute it for the fblike var above. Just make sure you note that there is a cleaned up (escaped) url hidden in there. base_url is the one you want to replace.