Karl Marx said ‘Life is struggle’. I believe that this misconstrues the point. Life is pursuit, and it is in pursuit that we find struggle. You cannot have pursuit without struggle, but to focus on the struggle is masochistic.
Karl Marx said ‘Life is struggle’. I believe that this misconstrues the point. Life is pursuit, and it is in pursuit that we find struggle. You cannot have pursuit without struggle, but to focus on the struggle is masochistic.
I’m currently in the process of trying to migrate from MacVim to a terminal based version of Vim on OS X. There are several motivations for switch (which I won’t go into here), but one of the frustrations I was encountering was lack of a functional asterix or ‘*’ register in Vim, which according to ‘:help registers’, is ‘… for storing and retrieving the selected text for the GUI.’
One solution to this problem is to use the version of Vim that comes bundled with MacVim. For my version of OS X (Mountain Lion) and MacVim (Snapshot 65) this was possible by setting the following alias:
alias vim=/Applications/MacVim.app/Contents/MacOS/Vim
While the MacVim solution fixed my clipboard problems, I felt a little dirty using MacVim’s version of Vim. Looking around I found an alternative solution; installing the homebrew version of Vim. This assumes you already have homebrew installed (if not, see homebrew’s homepage.)
brew install vim
Hopefully one of those solutions works for you if you were struggling with the same problem.
This idea was actually exposed to me while reading a Pivotal Labs post on pair programming over tmux. The idea of autosaving in MacVim hadn’t occurred to me previously, though in retrospect it makes perfect sense. I had a veritable nervous twitch before I would switch focus to another application (iTerm, chrome, etc.) from MVIM. “:wq!” ,possibly a few ctrl-]’s and a few more “:wq!”‘s. It seems like a small thing, but given that this is a keystroke I hit probably hundreds of times in a day small things add up.
I searched chrome for “MVIM auto saving”, and came across this Stackoverflow post which gave me just the snippet I was looking for:
autocmd BufLeave,FocusLost * silent! wall
I dropped this into my gvimrc, restarted my MacVim, and quickly added a few lines to a file. I then (without saving!) went over to my terminal and cat’ed the file, and sure enough there were my changes! I’m greatly looking forward to the extra keystrokes this is going to save me, hopefully in turn reducing another little piece of the friction slowing down my ability to create great code. An important caveat is that this is dependent on the FocusLost command, which to quote the help “Only for the GUI version and a few console versions where this can be detected.” This makes me a little worried about the need to teach my fingers to auto-save again under certain contexts (like when working in tmux), but hopefully that doesn’t prove to be too challenging.
namespace :alertzy do
desc "Populate June 2011 data"
task :populate_june => :environment do
generate_june_data
end
end
def generate_june_data
mondays = [6,13,20,27]
tuesdays = [7,14,21,28]
wednesdays = [1,8,15,22,29]
thursdays = [2,9,16,23,30]
fridays = [3,10,17,24]
mondays.map! {|day| DateTime.parse("June #{day}, 2011 7:00:00")}
tuesdays.map! {|day| DateTime.parse("June #{day}, 2011 7:00:00")}
wednesdays.map! {|day| DateTime.parse("June #{day}, 2011 7:00:00")}
thursdays.map! {|day| DateTime.parse("June #{day}, 2011 7:00:00")}
fridays.map! {|day| DateTime.parse("June #{day}, 2011 7:00:00")}
mondays.each do |date|
[{:zone => "D", :day => 5},
{:zone => "D", :day => 6},
{:zone => "D", :day => 7}].each do |zone|
GarbagePickup.create(:zone => zone[:zone], :day => zone[:day], :pickup_date => date)
end
end
tuesdays.each do |date|
[{:zone => "E", :day => 7},
{:zone => "E", :day => 8}].each do |zone|
GarbagePickup.create(:zone => zone[:zone], :day => zone[:day], :pickup_date => date)
end
end
wednesdays.each do |date|
[{:zone => "A", :day => 1},
{:zone => "A", :day => 2}].each do |zone|
GarbagePickup.create(:zone => zone[:zone], :day => zone[:day], :pickup_date => date)
end
end
thursdays.each do |date|
[{:zone => "B", :day => 2},
{:zone => "B", :day => 3},
{:zone => "B", :day => 4}].each do |zone|
GarbagePickup.create(:zone => zone[:zone], :day => zone[:day], :pickup_date => date)
end
end
fridays.each do |date|
[{:zone => "C", :day => 4},
{:zone => "C", :day => 5}].each do |zone|
GarbagePickup.create(:zone => zone[:zone], :day => zone[:day], :pickup_date => date)
end
end
end
There seems to be a theme the dynamic co-CEO duo of Jim Balsillie and Mike Lazaridis are going for in the media lately. Techcrunch just ran an article discussing the somewhat unfavorable early reviews for the playbook where they quote Jim Balsillie, and the BBC is airing clips from an interview with Mike Lazaridis where issues of security in India and the middle east are discussed. In both cases each half of the duo seemed to think they are not being treated fairly with Balsillie responding to statements about the playbook with “I don’t think that’s fair", and Lazaridis responding to questions with "that's just not fair". This comes across to me as somewhat comical. Why this pair thinks that the rest of the world has some obligation to treat them in a "fair" manner is beyond me, and further more why they think the appropriate way to respond is by calling the world out is even more confusing.
This is a simple thing, but it took me some digging to find some straightforward instructions. For my own future use and hopefully to save some others the same searching here they are:
git pull origin master
git checkout -b [local branch name]
git push origin [local branch name]
git push origin [local branch name]:[remote branch name]
git push origin :[remote branch name]
This is not intended to be a well researched in-depth post; if I have a chance I’ll look into these trends further and offer some more in-depth insight, but right now I just wanted to share an observation.
If you follow my blog than you’re already aware that I entered an application called Alertzy in the City of Edmonton‘s Apps4Edmonton competition. Tomorrow Chris Moore (@chrisj_moore), Edmonton’s CIO will be announcing the winners to the competition. I thought this would be a good time for me to express some of my personal views on the competition, so that it’s clear that my opinions aren’t influenced by any of the outcomes. I’d also like to take this opportunity to express my gratitude to the City of Edmonton for holding the competition, and for all the developers involved in the competition for showing what a creative and vibrant development community Edmonton has.
What worked!
Lots of submissions
I’m sure I’m not the only one who was both surprised and impressed with the number of applications submitted into the competition. There are a wide variety of applications, on a wide variety of platforms. Some of them showed some great creativity, and I’m sure will continue to grow into successful applications.
Great prizes
This was likely one of the contributing factors to the number of submissions into the competition. I really applaud the City of Edmonton for their progressive IT policy, and the vision to take a risk and invest $50,000 in prizes into the competition. It would be nice to believe that the same quality and quantity of applications would have been possible without the monetary incentive, but there’s nothing like a little cash to motivate!
Good use of social media
For those active on twitter there was an almost constant flow of traffic on the #apps4edmonton hash tag both by administrators, developers, users, etc. It was great to see this temporary community pop-up around this competition.
Where things might be improved
Community Voting System
Having community voting as part of the competition might have seemed like a good idea on paper, but didn’t really seem to pan out in reality. Due to the limited size of the sample size of votes, it really did devolve into a “popularity contest”. For Alertzy I can testify that we beat the pavement to recruit anyone and everyone we knew or used to know in Edmonton to vote for us. I can only assume other competitors went through similar processes. I would suggest that having a separate mini-competition with a small prize for the “community favorite” to be awarded to the App with the most votes would have removed the “popularity contest” from the main competition.
Categories
The current contest used categories consistent with the plans of the City of Edmonton’s new City Vision. This was a cool idea, but unfortunately we only had access to certain data sets, and consequently it was much more difficult to develop applicable apps for many of the categories. I think categories aligned along other lines (for example technology such as Web App, iPhone App, Android App, etc) would allow for a more balanced distribution.
Clarity of Rules
The rules for the competition in regards to dates were often somewhat vague, and adhered to. The community votes are the best example of this issue. The voting was said to end on “FRIDAY, SEPTEMBER 10, 2010″, without clearly specifying when during this day this voting would end. This time also came and went without any indication of a closing of voting on the site. There was also no clear indication that the “likes” on the contest website were the “community votes” referred to in the rules.
Another issue of contention was whether modification of applications during the two weeks of voting and judging was allowed within the rules. For those who looked closely the following could be found in the FAQ:
Feel free to change the app through the course of the competition. Just remembered that you will be judged on the app that exits at the close of the competition (11:59:59 a.m. MDT on Friday, August 27, 2010).
However, the ability of the judges to be able to judge an application based on what was there exactly at a given time is questionable.
Conclusion!
I want to make it cear that I’m not complaining about the competition. I applaud the City for it’s efforts and for providing this platform for Edmonton developers to create and share. I hope that my feedback can help improve the competition if the City chooses to offer a similar event again, or that it may help other city’s or organizations in similar competitions.
Best of luck to all entries. I’ll see everyone at the event tomorrow evening!
As I explained in my earlier post berating HostingRails, I built a project for the City of Edmonton’s Apps4Edmonton contest in Ruby on Rails called Alertzy. In order to make our project live, we needed to find a host for it. Our initial host fell incredibly flat, so in our second iteration we made sure to perform more research into our available options. We were initially looking for what I would call a “Rails Host”, as in a hosting provider who gives you an out of the box solution ready for rails hosting. Under this criteria we found a few potential options, but then we stumbled upon SliceHost.
SliceHost Review
I’ll summarize my impressions of slicehost here:
Pros: Very fast setup, very good performance, very professional
Cons: Start from a blank image on a VPS
Our intention was not to use a VPS provider who didn’t provide an out of the box rails compatible solution. The reviews for SliceHost, however, were just too good to ignore. All the reviews which we were able to find for this hosting provider were positive, so we decided we had to give them a shot.
It is important to understand that SliceHost is not so much a Rails hosting provider, as a generic VPS hosting provider. They simply provide you with a “slice” which has certain performance metrics and a blank OS install on it, and then it is up to you to configure the server to do what you would like it to do. This has the advantage of complete freedom (SliceHost would prove as effective a PHP host as they are a Rails host), but comes at the cost of configuration.
With our decision to give SliceHost a try, we proceeded to go through SliceHost’s registration and payment process. Their cheapest slice starts at $20, but we opted to go for their $25 plan which got us 384 MB of RAM, 15GB of storage, and 225GB of bandwidth. For some reason we flagged something in their system and had to go through an additional verification step. This process was completed promptly by SliceHost, and our account was online and operational within 45 minutes of the start of the process.
With our account in place we now had access to their control panel, where you are able to configure your DNS as well as choose an operating system for your Slice and launch it. The speed with which a new slice comes online impressed me greatly. From the time of choosing the operating system and launching it, it takes only ~20 seconds before you are ready to start connect to and start configuring your slice.
Unfortunately the next step of this process involving configuring our Slice to run Rails proved to be very difficult. This was in no way SliceHost’s fault as this process is exactly the same as configuring Rails to run on any system, but the convenience of having a ready made image to use would be an advantage of using another Rails specific host. The tutorials that I was able to find for configuring Rails to run on a SliceHost VPS were out of date and didn’t work with the more recent versions of Ruby and Rails. (I will try and put a tutorial outlining my own experiences online in the near future). I opted to use Capistrano and Deprec to deploy Rails on the new server, and due to the same shifts in versions this proved to be quite a headache to deploy on the Ubuntu 10.04 server we had opted to run. It took me approximately 10 hours to resolve all the bugs in the deprec scripts to where the deployment could fully run.
Once I had Capistrano and Deprec functioning I was able to deploy our site to SliceHost. Finally being able to access our site on a good host with great performance was more than sufficient reward for the past day of struggle deploying Rails! The difference between HostingRails and SliceHost was truly night and day, and we’ve received very good feedback on the responsiveness of our site.
In conclusion, I had a hard time deploying Rails, but in no way was this the fault of SliceHost. In everything that is their responsibility, SliceHost has so far delivered either up to, or more often exceeding my expectations. I intend to use them as my default host for similar projects going forward. If you would like to check the responsiveness of our site, go check out www.alertzy.com which is running off our slice.