tigefa4u

Writing posts from repostories Github.

© 2014 sugeng tigefa - Powered by Jekyll

Download: Fast, Fun, Awesome

Deploy Bugzilla on Openshift With SSH

How to get Bugzilla

Bugzilla and all of its source code are available for download below. Bugzilla is licensed under the Mozilla Public License, and is thus both free and open source software.

Be sure to see the Installation and Configuration section of the Bugzilla Guide (there’s also a copy included in the tarball).

If you want to know what’s changed from one version to the next, view the changelogs for Bugzilla (generated directly from the raw bzr checkin messages).

Note for upgraders: You can update to the newest release using the bzr instructions below. This is a good way to update if you’ve made local changes, as bzr will attempt to merge your changes with the current release (although you may have to do some merging yourself if it finds conflicts between what you changed and what we changed). Then, to complete your upgrade, read the “How to Upgrade Bugzilla” section in your release notes.

Login On Openshift

rhc setup

Create new app

rhc app create bugzilla perl-5 mysql-5 phpmyadmin-4

Login app via ssh

rhc ssh bugzilla

Change directory on path perl index website

cd app-root/runtime/repo/perl

Get the bugzilla source

Stable Release (4.4.1)

Bugzilla 4.4.1 is our current stable release in the 4.4 series.

wget http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-4.4.1.tar.gz && tar --strip-components=1 -zxvf *.tar.gz && rm *.tar.gz
Development Snapshot (4.5.1)

Bugzilla 4.5.1 is our latest development snapshot leading to Bugzilla 5.0. Use of a development branch is at your own risk. They receive very little testing, so expect this release to be unstable. Users of 4.4 or older 4.5 releases are encouraged to try out new 4.5 releases in a testing environment and let us know of any problems that are found with the release. A look at the new features that will be in Bugzilla 5.0 can be found in our latest Status Updates.

wget http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-4.5.1.tar.gz && tar --strip-components=1 -zxvf *.tar.gz && rm *.tar.gz

Installing perl module

perl install-module.pl --all

Create localconfig

perl checksetup.pl

Edit localconfig database connection

nano localconfig

and re run, install process it here, setting your login.

perl checksetup.pl

Adding alias dev.myproject.org for example

rhc alias add bugzilla dev.myproject.org

see dev.tigefa.org

the end

deploy redmine on openshift with ssh

frist sign in on openshift.redhat.com or sign up new one its free with 1GB storeage.

if existing member openshift know for start, using rhc setup

Creating new app

rhc app create redmine ruby-1.9 mysql-5.1 cron-1.4 phpmyadmin-4

Sign SSH

rhc ssh redmine

Change directory website root index

cd ~/app-root/runtime/repo

Get redmine stable releases from redmine/wiki/Download

2.5-stable version

wget --no-check-certificate http://www.redmine.org/releases/redmine-2.5.1.tar.gz && tar --strip-components=1 -zxvf *.tar.gz && rm *.tar.gz

2.4-stable version

wget --no-check-certificate http://www.redmine.org/releases/redmine-2.4.5.tar.gz && tar --strip-components=1 -zxvf *.tar.gz && rm *.tar.gz

Configure config/database.yml

wget --no-check-certificate http://git.io/Y_wiJw -O config/database.yml

Bundle the gem

gem install bundler --no-ri --no-rdoc
bundle install --no-deployment

Next installing redmine

Session store secret generation

rake generate_secret_token

Database schema objects creation

RAILS_ENV=production rake db:migrate

Database default data set more

RAILS_ENV=production rake redmine:load_default_data
File system permissions

Logging into the application

Use default administrator account to log in:

login: admin
password: admin

You can go to Administration menu and choose Settings to modify most of the application settings.

for more visit redmine wiki

Adding alias redmine.myproject.org for example

rhc alias add redmine redmine.myproject.org

see repo.tigefa.org

Rails url_for weaknesses

Rails helper link_to is the most famous and used any Rails developer. Usually the first argument is a link name and the second is a parameters which are used to build url. You are able to pass 4 types of these parameters: helper which is generated by routes, string, hash and since rails 3 - record. But when and which one to use for your task? This is an interesting question.

url_for

Passed to link_to parameters go to the url_for method. This method builds known url which is eventually passed to the href attribute of generated link. So to answer on this question we should answer on question what and when to pass to the url_for.

As I’ve already said url_for accepts 4 types of parameters and see how it’s possible to pass them there:

url_for("/events/#{@event.id}") # string
url_for(event_path(@event)) # generated helper
url_for(controller: 'events', action: 'show', id: @event.id) # hash
url_for(@event) # polymorphic

All there calls of url_for generate the same result /events/:id, for example /events/1.

The most convenient seems the last call - you just pass @event record and that’s it. There is no any brainstorming or surfing generated routes with rake routes task (this task shows all available routes for your Rails application, run it if you still hadn’t done this yet). It really convenient not only that’s why but it will be useful when you change controller or route which serves the event. You won’t have to change all your entire code in Rails application where you used old route helpers or string urls, hashes and so on.

The most complicated seems the hash variant. It looks the biggest and there is no doubt that why it is silently deprecated by Rails community. Rails developers avoid to using it at all. The reason is not only in this reason but in one more which I will tell you in a few seconds.

There is no any rule which method of proposed to use and of course you are not restricted to use any of these call types.

But let’s see what is their speed. I wrote the benchmarking test especially for this case:

class EventsHelperTest < ActionView::TestCase
  def setup
    country = Country.create(name: 'Belarus')
    state = State.create(name: 'Minsk')
    @event = Event.create(country: country, state: state, name: 'Drinking bear')
  end

  def test_url_for
    n = 10000
    Benchmark.bmbm do |x|
      x.report('string') { n.times { url_for("/events/#{@event.id}") } }
      x.report('helper') { n.times { url_for(event_path(@event)) } }
      x.report('hash') { n.times { url_for(controller: 'events', action: 'show', id: @event.id) } }
      x.report('polymorphic') { n.times { url_for(@event) } }
    end
  end
end

And these are results of their running:

rake test test/helpers/events_helper_test.rb
Run options: --seed 23668

# Running tests:

Rehearsal -----------------------------------------------
string        0.010000   0.000000   0.010000 (  0.019028)
helper        0.480000   0.010000   0.490000 (  0.498942)
hash          1.250000   0.000000   1.250000 (  1.253836)
polymorphic   0.920000   0.010000   0.930000 (  0.924670)
-------------------------------------- total: 2.680000sec

                  user     system      total        real
string        0.010000   0.000000   0.010000 (  0.013747)
helper        0.480000   0.000000   0.480000 (  0.478646)
hash          1.200000   0.000000   1.200000 (  1.200571)
polymorphic   0.890000   0.000000   0.890000 (  0.892464)
.

Finished tests in 5.542858s, 0.1804 tests/s, 0.0000 assertions/s.

1 tests, 0 assertions, 0 failures, 0 errors, 0 skips

As you see the slowest here is a hash style. And then polymorphic generating goes. Helper style on the 3rd place and it’s not surprise that string generating wins.

Conclusion

For my opinion the most convenient style here is polymorphic. But it’s 2x slower than helper style. String style is the fastest but we can’t use it because if you change your routes your tests may not show you that there is an error in generating routes - string will be generated as before but helper method won’t be presented and page will fail that’s why.

So my conclusion is to use helper methods everywhere where it’s possible. If you have some place in your application where you have to define which helper to use by record type or any other sign the polymorphic way is more preferable.

And the last conclusion - avoid using hash types of generating url at all.

Agnostic Application Generators

Agnostic Application Generators (padrino-gen)

Overview

Padrino comes preloaded with flexible code generators powered in part by the excellent Thor gem (incidentally also used in the Rails 3 generators). These generators are intended to allow for easy code generation both in creating new applications and building on existing ones. The generators have been built to be as library agnostic as possible, supporting a myriad of test frameworks, js libraries, mocking libraries, etc.

See the guide for Padrino Generators for a more in-depth look at the system.

Project Generator

Padrino provides generator support for quickly creating new Padrino applications. This provides many benefits such as constructing the recommended Padrino application structure, auto-generating a Gemfile listing all starting dependencies and guidelines provided within the generated files to help orient a new user to using Padrino.

One important feature of the generators is that they were built from the ground up to support a wide variety of tools, libraries and gems for use within your padrino application.

The simplest possible command to generate a base application would be:

    $ padrino-gen project demo_project

This would construct a Padrino application DemoApp (which extends from Padrino::Application) inside the folder ‘demo_project’ at our current path. Inside the application there would be configuration and setup performed for the default components.

You can define specific components to be used:

    $ padrino-gen project demo_project -t rspec -r haml -m rr -s jquery -d datamapper

You can also instruct the generator to skip a certain component to avoid using one at all (or to use your own):

    $ padrino-gen project demo_project --test none --renderer none

The available components and their default options are listed below:

test:: rspec (default), bacon, shoulda, cucumber, testspec, riot, minitest renderer:: haml (default), erb, erubis, liquid, slim stylesheet:: sass (default), less, compass mock:: none (default), mocha, rr script:: none (default), jquery, prototype, mootools, rightjs, extcore, dojo orm:: none (default), datamapper, mongomapper, mongoid, activerecord, sequel, couchrest, ohm, mongomatic, ripple

In addition, you can generate projects based on existing templates:

    $ padrino-gen project demo_project --template sampleblog

To learn more about the project generator, check out the guide to Padrino Generators.

Plugin System

Padrino provides support for plugins to be executed within your application. For example:

    $ padrino-gen plugin hoptoad

would install the hoptoad middleware into your application automatically.

To learn more about the plugin system, check out the guide to Padrino Generators.

Sub App Generator

Unlike other ruby frameworks Padrino is principally designed for mounting multiple apps at the same time.

First you need to create a project

    $ padrino-gen project demo_project
    $ cd demo_project

Now you are in demo_project and you can create your apps:

	$ padrino-gen app one
	$ padrino-gen app two

By default these apps are mounted under:

  • /one
  • /two

but you can edit config/apps.rb and change it.

To learn more about the subapp generator, check out the guide to Padrino Generators.

Model Generator

Padrino provides generator support for quickly creating new models within your Padrino application. Note that the models (and migrations) generated are specifically tailored towards the ORM component and testing framework chosen during application generation.

Very important to note that model generators are intended primarily to work within applications created through the Padrino application generator and that follow Padrino conventions. Using model generators within an existing application not generated by Padrino will likely not work as expected.

Using the model generator is as simple as:

    $ padrino-gen model User

You can also specify desired fields to be contained within your User model:

	$ padrino-gen model User name:string age:integer email:string

To learn more about the model generator, check out the guide to Padrino Generators.

Migration Generator

Padrino provides generator for quickly generating new migrations to change or manipulate the database schema. These migrations generated will be tailored towards the ORM chosen when generating the application.

Very important to note that migration generators are intended primarily to work within applications created through the Padrino application generator and that follow Padrino conventions. Using migration generators within an existing application not generated by Padrino will likely not work as expected.

Using the migration generator is as simple as:

	$ padrino-gen migration AddFieldsToUsers
	$ padrino-gen migration RemoveFieldsFromUsers

To learn more about the migration generator, check out the guide to Padrino Generators.

Controller Generator

Padrino provides generator support for quickly creating new controllers within your Padrino application. Note that the controller tests are generated specifically tailored towards the testing framework chosen during application generation.

Very important to note that controller generators are intended primarily to work within applications created through the Padrino application generator and that follow Padrino conventions.

Using the controller generator is as simple as:

   $ padrino-gen controller Admin

You can also specify desired actions to be added to your controller:

    $ padrino-gen controller Admin get:index get:new post:create

To learn more about the controller generator, check out the guide to {Padrino Generators}[http://www.padrinorb.com/guides/generators].

Mailer Generator

Padrino provides generator support for quickly creating new mailers within your Padrino application. Very important to note that mailer generators are intended primarily to work within applications created through the Padrino application generator and that follow Padrino conventions.

Using the mailer generator is as simple as:

  $ padrino-gen mailer UserNotifier

To learn more about the mailer generator, check out the guide to Padrino Generators.

Create Own Calepin site

Quickstart

    $ git clone https://github.com/jokull/calepin.git or svn co https://github.com/jokull/calepin/trunk calepin
    $ cd calepin
    $ virtualenv --distribute venv
    $ source venv/bin/activate
    $ pip install -r requirements
    $ pwd > venv/lib/python2.7/site-packages/app.pth

Environment

Now add .env with the development environment and source it. It should include values for the following values:

    SECRET_KEY=
    CALEPIN_ADMIN= # Admin email
    CALEPIN_THEME= # See github.com/jokull/pelican-themes
    CALEPIN_ROOT= # The place where user files are synced and served from
    SQLALCHEMY_DATABASE_URI=postgresql://calepin@/calepin
    DROPBOX_APP_KEY=
    DROPBOX_SECRET=
    SENTRY_DSN= # Optional but good for production
    REDIS_URL = redis://

Components

  • PostgreSQL
  • Redis
  • Flask api and frontend

Source on Github