Archive for the ‘Smibs on Code’ Category
Smibs on code: Upgrading to Git
Friday, August 14th, 2009A few days ago, our code repository server froze. Nothing a restart couldn’t solve, but this was the fourth time this month. The computer has been running continuously for a couple years, with a few developers constantly committing and pulling changes, uploading files, etc., and it had apparently had enough. Seeing this as an opportunity to fix up our development process a bit, I wiped the drives, and re-installed the OS.
The first thing I wanted to change was our code versioning system. Our office has been using Subversion (SVN) as our code repository for a couple years now. It’s done the job well, and has saved our butts on more than one occasion, but there were a few things I didn’t like. As I’ve mentioned in previous posts, I like moving around when I work; hitting a coffee shop in the morning, or taking my laptop to the local bookstore on a hot day. Subversion forced me to always have an internet connection to commit changes or make new branches. As a result, I would perform larger commits, or have branches pulling double duty, which is far from ideal. Further, setting up and maintaining the permissions with ssh and multiple developers is quite a pain on Subversion.
A few of our developers have used Git for some open-source projects, and we all quite liked it. We’ve been talking about changing for months, but we couldn’t justify the effort until we had to re-install everything anyways. We decided to use Gitosis to manage the Git server, setup the permissions, and manage users (good tutorial here). This proved to be fairly simple. I then imported all of our previous projects with git-svn with some help from this post. Next, our system was configured to send out a summary e-mail every time a developer pushed a change. Finally, I modified our deploy files so the servers read the code from our new Git server rather than our old SVN server. The entire process was completed in under two days.
While many of us had used Git before there was still a learning curve. I found a very useful guide called “Git Magic”. It starts off with the basics that all developers should know, but moves all the way to “Git grandmastery” in chapter 7.
Final thoughts:
Git has more of a learning curve than I expected, and is more complicated than Subversion — but it is so much more flexible, that I think it’s worth it. You can really use it however is best for you. For some developers, it won’t be much different than working with svn, but I’m really appreciating the differences. I read an interesting analogy comparing clones, branches, tags, etc. with multiple desktops, windows and tabs. The more options available, the longer it will take for a person to come up with the best system for them, but once they figure it out, they can really fly.
I would love to hear your thoughts on Subversion vs. Git (or any other systems you recommend for that matter). Why do you think one is better than the other?
Smibs on Code: Filtering user data
Wednesday, April 29th, 2009There is a major security concern when it comes to displaying text provided by a user. Ruby on Rails does a good job of keeping your MySQL code sanitized, but web browsers are still a source of concern. It is VERY easy for a hacker to write HTML or JavaScript into a text field. You don’t want them to be able to execute arbitrary code on other users machines. It could do all kinds of nasty stuff, like reading the session key, sending it to a different server, and letting a hacker hijack your secure connection. It could scrape data off your screen or prompt you for additional data, in an attempt to get your credit card information. The point is, displaying user data without any kind of filtering is VERY bad.
XKCD - Exploits of a mom: A perfect example of not filtering SQL code.
The real question is when to filter the data. There are two trains of thought on this: filter the data right when the user gives it to you, before you store it in the database or store exactly what the user supplies and filter the data when it needs to be filtered.
Rails is designed more for the latter approach and there are a number of good arguments for post-filtering. It makes mass-assignment much easier (storing a large amount of data from a form into a database). More importantly, it lets you store exactly what the user wants to store. Obviously, you don’t want to be altering the users data. Depending on how the data is being read, it may not need to be filtered. An RSS reader is a perfect example of this. In the RSS stream you can display an unfiltered version of what the user entered, but a filtered version can be shown in the browser.
Despite these benefits, the method I eventually chose was pre-filtering data before it was stored in the database. This has better performance, because you filter once, and display the data many times. I still have various unfilter functions, which can restore the parts of the data we need in situations when we want an unfiltered, or partially unfiltered string. Finally and most importantly, I feel it is more secure. If your data is safe, you don’t have to constantly be remembering to filter when you are displaying your data. Doorbell and Smibs are large applications, with plenty of spots where you could forget to place the all important “h†in front of your variable. It just seems safer to me to store a string that can do no damage, and convert that to a dangerous string in the few instances when you need it, rather than the reverse.
In my next post I’ll go into the code and show how I implemented the pre-filtering in our applications.
______________________
What are your thoughts on pre-filtering vs. post-filtering? Did I miss any important points?
Smibs on code: JavaScript lines
Friday, March 13th, 2009This is going to be another short post where I share some code, and much more importantly provide a demo to play with. There have been a number of times when our team has an idea that would require some creative drawing & lines in a browser. This is traditionally Flash territory. There has been lots of work with canvases to allow drawing in Javascript, but these are still exploratory and are not really ready for the lime-light.
It is actually quite possible to draw lines on the screen. An excellent explanation of an efficient method can be found at http://www.p01.org/releases/Drawing_lines_in_JavaScript/ (I believe it was written by Mathieu ‘P01′ HENRI) I recently turned this method into a Prototype class with some useful functionality.
My demo is at http://lines.live2code.ca (Tested on IE7, IE8, FF3 & Safari)
or you can check out the code at http://github.com/forrest/javascript-line-class
Smibs on code: JavaScript windows
Wednesday, March 4th, 2009This is going to be a short fun post. It’s about a JavaScript library that I wrote a month ago. We wanted to see how easy it would be to develop multipurpose JavaScript windows to run inside the browser. The goal was to create a simple window model that could handle all the windowing functions. We could then develop more complex windows and have them inherit the basic window class. It was quite successful. Keep an eye on your Smibs account and you will see some very neat changes coming soon 
Basic window features: Layering of the unfocused windows, faded unfocused windows, resizing, full screen, semi-transparent while dragging.
We decided to make the code open source so you can:
view and download the code
or play with the DEMO!!! (IE7+, FF2+, Safari)
The demo has three types of windows: the basic window class which doesn’t do much, the hello world window which demonstrates a simple extension to the window and an IFrame window which will open an IFrame to our Smibs homepage inside your browser window.
Credits: This was a quickly developed prototype and as such a large number of images, as well as general style was taken from EyeOS. EyeOS is a very cool browser based operating system and I suggest you check it out.
Enjoy
