I got away with setting up with authentication without having to set an API for our app. Rack::Auth::Basic made it dead easy to ask for credentials and verify users. Since we are doing everything over smart http protocol of git, user can verify themselves just with their username and password. I think I still have to add the part where user can use either his username or email, but that shouldn’t be too difficult.
We support addition of files from our web UI as well, so it was bit tricky to sync the bare repository and the non bare one (we use later for web UI intraction). A lot of things goes on after user does a push. First the obvious, we update the bare repository, next we do a fetch from non-bare one and merge the new changes (how to link), then we go through each commit and generate thumbnail for them and finally if image for inspiration page has not been generated yet then we create that too.
Now there is just one thing left to do, integration of sparkleshare.
We people of GlitterGallery have been trying to figure out how we can add local repo support #161. Until now if a user wanted to put his awesome work for everyone to see and admire, he would have to use our web interface. Which can get really cumbersome, really fast.
Unfortunately there isn’t much documentation about how one should go about setting up gitserver with rails app. We will be running on openshift so no poking around with apache config files either. I got started with reading these two chapters: Git Internals – Plumbing and Porcelain and Git on the Server of Pro Git Book (If only all good things were free). Just when I was trying to figure out how on earth I am going to implement git-http-backend without having access to server, nice guy Marek pointed me to Grack. So next up was learning more about rack, and I got to do it while hearing the pleasant voice of Ryan Bates: #151 Rack Middleware, #222 Rack in Rails 3 and #317 Rack App from Scratch!
We have our push and pull working now, however we need to work on authentication. I am thinking Rack::Auth::Basic and grape.
In the last fedora-infra meeting, Kushal pointed out that it is important that the gems I am using on my project are packaged in Fedora. I was taken aback by this, because I had no idea that such a thing as rpm package of ruby gem existed. Others were quick to guide me to resources to get me started: Infrastructure/AppBestPractices, Packaging:Guidelines and Packaging:Ruby
I decided to contact the people who must have been through all of this – Ruby-SIG. You can imagine that the ruby community on Fedora must be small, we are all python people here. However, the response I got was just overwhelming. Each one of them so detailed and resourceful in their reply. Ken Dreyer made me a complete road map which I should follow if I plan on packaging ruby gems. He is the maintainer of quite a few ruby gems. Then there was Dominic Cleal, who explained how he dealt with this issue on his project foreman.
The reason why GlitterGalley would benefit from packaging is the distribution of the application. People could easily install it and run it (by starting SystemD unit for instance). The other one is that those people would get security updates for their application automatically with system updates (yum update) which they have to run anyway… so its a lot of work for the maintainer and least effort for people running it. With packages you can also easily ship SELinux policies, properly state all system dependencies etc.
That would be Josef Stribny, who explained why should I care that the gem I am using comes as rpm package.
Obvious problem with all this is that packaging takes a lot of time and it will end up delaying the deployment of GG in production. I hope we will find a middle ground.
Coming to things I worked in the last one week: I added responsive images for the desktop and the mobile site. RMagic’s resize_to_fill came really handy in generating different sizes of images. I also finished my work on authorization. We change our landing page to exploration page, so now our site is quite engaging even for the guest users. I also added sourcemap for sass files, otherwise it was really difficult to work with a single 1k lines long stylesheet file.
Broken pipeline, an outdated bundler and a worthless ISP had all made their plans to bury me. In spite of everything, I am glad I was finally able to deploy on openshift. You can check out the latest demo here
I have been working on the exploration page. I have added sorting options to the page. Now the user has options of sorting them based on most rated, most forked, most followed etc. I wish I could tell you that it was easy to join three tables, group them with project id, order with issue count and comment count, where issue is closed and created at time is less than 10 days. It wasn’t! In case you are wondering what might be the length of the query:
I made a few more improvements like adding image of projects and links to fork, follow and blame. It needs some more work. I have to add testing and possibly fix the layout.
I am also working on authorization. We decided to go with cancancan.
Oh did I mention that my contribution is almost 6k lines now? And today is only the second day of the official coding period.
My past one week has mostly been wasted on deployments. Sometimes I just couldn’t find the right documentation, when at others I was just too frustrated to even try. I am going to write the steps of deployment both on heroku and openshift in this one, I hope someone will find it useful. First Openshift!
- You will need an account, so go ahead and sign up if you haven’t already. I will be using GG as example app to deploy.
- Pick ruby on rails 4, it uses ruby 2 and mysql 5.5 as default, just name your app and you are good to go.
- Get source code url of the app you just made. It will look something like this:
- Open up your terminal and clone it:
git clone ssh://email@example.com/~/git/ruby.git/
- Get inside the app you just clone, in my case it is will be
- You would want to remove following files:
git rm public/index.html app/views/layouts/application.html.erb -r app/assets/
- Now you can pull the repository you want to deploy
- git remote add glitter -m master http://github.com/glittergallery/GlitterGallery.git
- git pull -s recursive -X theirs glitter master
- It is most likely that you will be safe if you ignore the merge conflicts, so just go ahead and commit:
- git add .
- git commit -m “merge glittergallery with ruby example app”
- Change the mirror from ‘rubygems.org’ in your gemflie to ‘mirror.ops.rhcloud.com/mirror/ruby/’, precompile your assets and commit them as well:
- rake assets:precompile
- git commit -am “change mirror and precompile assets”
- I hope you have set your rhc by now. If not, you can find how to do it here. You will be better off if you don’t install gems of test and development:
rhc env set BUNDLE_WITHOUT=”development test” -a ruby
- Thats it! You can push your code to openshift now:
git push origin master
Moving on to Heroku. Just sign up and jump into terminal. Make sure you are inside the directory to app you are trying to deploy.
- Install heroku toolbelt and login from your terminal:
- Heroku doesn’t support sqlite3 or mysql so you will need to go to your gemfile and replace them with
- While you are at it, why don’t you add rails_12factor as well. It is just something they use to integrate rails with heroku
gem 'rails_12factor', group: :production
- Install the gems you just added:
- You will need to replace content of database.yml file with:
- Add Postgres addon to your app
heroku addons | grep POSTGRES
- Go to heorku and check your databases, a new one with your app name must be created. Copy host, database, user and password from that to your database.yml file under production.
- We use rugged and it has cmake as dependency. You will need buildpack of cmake and ruby:
- heroku buildpacks:set https://github.com/rcaught/heroku-buildpack-cmake
- heroku buildpacks:add https://github.com/heroku/heroku-buildpack-ruby
- Precompile your assets and commit everthing:
- rake assets:precompile
- git add .
- git commit -m “add gems for heroku and precompile assets”
- Now you can push your code to heroku
git push heroku master
There are a few gotcha with heroku. We use delayed jobs, for which we need worker but heroku provides limited hours of free worker. Start the working only when you have to. Besides that, public directory will be reset every time you push to heroku so anything you are saving there will be lost. Same will happen each time the application shuts down and restarts after being inactive for x minutes.
Talking about things added on glittergallery, I fixed a bug I had in tagging. Tags were not being added in context of project. I just need to define an association between tags and projects. I have started my work on exploration page. My mentor suggested that we should add rating system to the projects. I found ratyrate, but it was really buggy. I tried to fix it and thus I made my first contribution to any ruby gem. I am really hoping I will be done with this as soon as possible. We are getting serious about adding push and pull features to deployments.
This would be the time when I thank everyone for believing in me and show how grateful I am. But I am pretty sure you have no interest in reading all that, so lets just skip it! If anyone would like to read my proposal they can find it here.
We are off to a relatively slow start, I don’t like slow. I really hope soon enough it gets to the point where I don’t want to go to bed anymore. Hey, no one remembers the night they slept a lot. I am trying to find other fedora projects to keep me busy but force is not with me these days.
I recently fixed markdown support of issues. Any 90s kid here?
However, I had to disable html tags support. That would have brought up security issues. We would need to parse the input and filter everything harmful. Too much of work for very little gain.
Beside that I got to work on something really cool! Expandable comment box!! Remember how input fields on Facebook expand their length instead of adding a scroll bar? It was Sarup, my mentor’s idea and I glad he asked me to have at it. I followed Neil Jenkins‘s blog. I think I got to learn quite a few things. That’s the most fun part about doing something you don’t know, you get to learn a lot of new things and of course the sense of accomplishment.
These days I am working on this awesome project GlitterGallery. We call it GG in short. I don’t know why but I have this weird obsession that I want to be the top contributor on this. “268,858″ lines!! Sounds way too far. hmm! May be I can snuck in a PR with with invisible lines 😉
Anyway, It is suppose to be Github for designers and I am really excited about it. I really hope I will get to work on this under GSOC. I have a huge list of features we need to work on. Best part is that I won’t have to worry about advertising or finding user of the site. What can I say, I am not a big fan of working on SEO.