Phonegap and Sprockets sitting in a tree
— follow @abhishiv
One thing that you hear a lot from people developing Phonegap applications is that the Xcode/Eclipse workflow is too tedious. You are forced to launch the emulator over and over again to test, and not to mention that lack of good javascript debugging tools.
I have been playing around with Phonegap for a few weeks now, and the first thing that I did was to setup a rack server to test my application in chrome. That got me started, but I was still missing coffescript and sass goodness all of us have gotten used to. There are ways to get around this, using gems like guard or applications like livereload. However they didn’t seem right to me.
I quickly came to conclusion that the best thing would be to use sprockets in my development workflow. For deployment I thought I could use a rake task - similar to rake assets:compile that rails provide.
Ok, so let’s start by creating a new Phonegap project in Xcode. If you absolutely can’t stand Xcode you can skip this step and use build.phonegap.com
Let’s create a Gemfile in the www folder of our project and run bundle install
Now we need a Rack server that integrates with sprockets
The last thing missing is a rake task to compile our assets so we can run the application in the simulator or push to build.phonegap.com. I simply copied the Sprockets:: StaticCompiler class that comes with rails and wrote a compile task using it.
That’s it! now just run rackup from the root of www folder and you’ll have a rack server running. Don’t forget to run rake compile before you deploy your app to the simulator.
What we are doing here is mounting sprockets on /build to facilitate rapid development, while for deployment using the rake task to place the compiled files in the build folder. This way we don’t need to change the reference paths of out assets in index.html.
6:13 am • 17 January 2012 • 34 notes • View comments
Document level permissions with permissible
— follow @abhishiv
One of the most impressive features in Highrise is its ability to set permissions on objects. I was looking to implement something similar and thus wrote Permissible to solve the problem of implementing instance/document level permissions in ruby.
Permissible make it easy for any Mongoid::Document to have a blacklist or whitelist of users.
post = Post.last
u1 = User.last
u2 = User.first
post.whitelist [u2.id]
post.add_to_list [u2.id]
post.permissible?(u1)
Find it on github
6:31 pm • 7 March 2011 • View comments
There are places where words cant go. Where they stop. The mysteries of the soul, reopened for the good. Fantasies, wishes, lies, dreams, nightmares - the world beneath the world, true words beneath the false. The secrets of how desire and guilt upsets and terrorizes. Of what we want and what we fear the most. Mysteries that burn a hole in the self, and leave it crippled.
2:29 pm • 5 March 2011 • View comments
Introducing acts-as-taggable for Mongoid
— follow @abhishiv
Almost every application benefits from having some sort of tagging functionality. For Mongoid, there’s Mongoid::Taggable, however if you have a multi-tenant application, you need to ensure tag ownership as well, making sure that tags for each tenant are kept separate. Unfortunately the awesome acts_as_taggble_on gem is tightly coupled with activerecord and doesn’t work for those of us using Mongoid.
Enter acts_as_taggable
Initialization:
class Organization
include Mongoid::Document
include ActsAsTaggable::Tagger
end
class Contact
include Mongoid::Document
include ActsAsTaggable::Taggable
end
Usage:
org = Organization.last
person = Person.last
org.tag person, ['tag1', 'tag2']
The code is released under BSD license, so feel free to modify as you wish.
8:14 pm • 3 March 2011 • View comments
“When the night is bled, And the day is fled
And the earth is dead, How shall wayfarers fare?
Who shall be there to dare?”
— Mikhail Naimy, Book of Mirdad
12:39 am • 20 June 2010 • View comments