TeamSnap is a new web 2.0 application for managing/organizing sport teams. Since I am on a softball team here at Webmail.us, I figured I should give it a try. As it turns out, it’s pretty nice. It has all the features I want and very little that I don’t.
Since it seems to be a Rails based application, it has some similarities with applications like Group Hub. Very clean, intuitive, and simple. It is still in beta testing, so not all the features are complete, but its still very usable. Unfortunately, once it is released, the free version is going to have ads and possibly less features, although I don’t know what those are.
Definitely worth trying right now though.
Thanks to Jon H., I can now do find and replace in files on Linux machines from the command line. Its pretty simple, but I had never bothered to figure it out.
Here are two examples. The first is for just one file, the meat and potatoes are in the second example, which does a find and replace in all PHP files.
1
2
| sed -i -e "s/TOREPLACE/REPLACEMENT/g" temp.txt;
sed -i -e "s/TOREPLACE/REPLACEMENT/g" `find -name '*.php'`; |
Super helpful.
Even though I have been a PHP programmer for 4 years or so now, I still discover new things every day. While looking at different ways to split strings based on regular expressions I learned an important lesson.
explode() isn’t the same as split()!
Since I learned Perl before PHP, I prefer using split() and join() instead of explode() and implode(), respectively. To my surprise, split() is not an alias of explode() while join() is an alias of implode(). Almost since I started using PHP, I have used been using Perl syntax for these functions, thinking they were just aliases of their PHP equivalents.
The biggest difference is explode() takes a delimiter to split by, while split() takes a regular expression. This means that explode() is going to execute faster. Also, the PHP documentation says that preg_split() is faster than split(), so really there isn’t much of a reason to use split() at all.
Well, I came across another Safari bug dealing with forms today. Unfortunately, I discovered this problem months ago and compeltely forgot it. So I figured I should document the issue so when it arises again, I won’t waste any time searching for the solution.
Basically, like most other issues with forms on IE and Safari, this issue deals with setting values of elements before they are on the document. Before today, I thought that checkboxes and radios in IE were the main problem, but textareas also have issues.
Here is the hack I did to solve the problem:
1
2
3
4
5
6
7
8
9
10
| //While populating the form
var form = Element.createHtml('<form><textarea name="some_textarea"/></form>');
form.some_textarea.value =
form.some_textarea._value = 'Hello world';
//When appending the form to the document
document.body.appendChild(form);
//Safari fix
form.some_textarea.value = form.some_textarea._value; |
If I am feeling chipper, I may even search through WebKit’s huge list of bugs to see if it needs to be reported. Hope this helps someone out there.