Some Background
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:
- 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.
- Go to your /status page, and clear all sessions.
- 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.
My Weaknesses as a Developer
Some Background
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.
Some Background
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.
Some Background
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.
Facebook “Like” button for PierCMS sites
Every site should have a like button
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
- Add a system component for html to your site. I called mine “facebookLike.”
- 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+"&layout=standard&show_faces=true&width=450&action=like&colorscheme=light&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:
- Grabs the current URL.
- 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.
- 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.
