redmineをLinux(Ubuntu)に導入する

windowsXPで数ヶ月Redmineを使ってプロジェクトを管理していましたが、
思っていた以上に使い勝手の良い素晴らしいアプリケーションだったので、Linuxに移行して本格的に使うことにしました。

以下は、忘れないための導入メモです。

導入環境

• Ubuntu 9.10


• Mysql 5.1.37


• ruby 1.8.7

参考にしたHP

• http://redmine.jp/guide/RedmineInstall/

まずは現在のRuby on Railsを確認。

gem env

gemのバージョンは1.3.5。
Redmineの導入に必要なのは、RubyGems 1.3.1以上なのでOK。

rails -v

コマンドでrailsのバージョンを確認。しかし、コマンドが動かない…。
/var/lib/gems/1.8/bin
にrailsを発見。パスが通っていないようである。

PATH=$PATH:/var/lib/gems/1.8/bin
export PATH
rails -v
Rails2.3.5

railsのバージョンが無事確認できた。問題ないようだ。

次にMySQL

後でwindowsXPで使用しているデータを移行したいので、他のDBは選択対象外。

/etc/init.d/mysdql start
mysql -u root -p

mysqlが無事起動。versionは5.1.37

続いてRedmineのインストール

cd /var/www 
mkdir rails
cd rails
wget http://rubyforge.org/frs/download.php/70486/redmine-0.9.4.tar.gz
tar zxvf redmine-0.9.4.tar.gz
mv redmine-0.9.4 redmine

これで、/var/www/rails/redmine/以下にファイルが展開されたのを確認。

再びmysqlを起動

create databse redmine character set utf8;
create user 'redmine'@'localhost' identified by 'redmine';
grant all privileges on redmin.* to 'redmine'@'localhost';

ここはwindowsと同じ。これでredmineのデータベースが完成。

さっくりと書いてあるが、ここまでで約2時間。現在夜の2:30。
明日も仕事があるので、今日はこれで終了。平日の仕事終了後に夜だけで導入するのは厳しいですね・・。

さて、再開。redmineのDBを作成する。

cd /var/www/rails/redmine/config
cp database.yml.example database.yml
vi database.yml
production:
  adapter: mysql
  database: redmine
  host: localhost
  username: root
  password: rootpass

redmineのDB設定が終了。ここもwindowsと同じ。

続いて、セッションストアの作成

cd /var/www/rails/redmine
rake config/initializers/session_store.rb

成功すると、config/initializersフォルダの中に、session_store.rbが作成されている。

そして次にデータベース上にテーブルを作成する。公式HPには「$RAILS_ROOTで実行」とあるが、$RAILS_ROOTは
アプリケーションのルートディレクトリのことである。つまりここでは、/var/www/rails/redmineとなる。

rake db:migrate RAILS_ENV="production"

コマンドを叩くと、mysqlのドライバーがないと注意される。調べると、Rials2.2以降は個別にインストールする必要があるようだ。面倒だな。

sudo apt-get install libmysqlclient-dev
sudo gem install mysql

windowsXPの時のように、No Difinitionが大量に出るが無視。windowsはそれで動いたし～。

cd /var/www/rails/redmine
rake db:migrate RAILS_ENV="production"

成功。続けてデフォルトのデータのLOAD。windowsXPで使用している既存データを移行する予定だが、とりあえずは作成しておく。

rake redmine:load_default_data RAILS_ENV="production"

成功。最後にパーミッションの設定。lsで見ると755になっているので華麗にスルー。

mysqlとWEBrickを起動

/etc/init.d/mysql start
ruby script/server webrick -e production

起動。http://localhost:3000にアクセス。すると、

Mysql::Error: #42S02Table ‘bitnami_redmine.settings’ doesn’t exist: SHOW FIELDS FROM `settings`

なるエラーが発生。なんじゃこら、windowsXPじゃこんなことなかったのになあ。で、調査。どうやらMysqlにRedmineの
スキーマがないのが原因のようである。miggrateの処理に失敗していたみたい。

cd /var/www/rails/redmine
rake db:migrate RAILS_ENV="production"

色々とメッセージが流れる。今度は間違いなく成功だろう。再びhttp://localhost:3000にアクセス。成功!!
あー長かった。全部で作業終了までにだいたい3時間くらいはかかったかな。もっとLinuxに慣れないといけませんなあ。

これでひとまずはOKだが、まだデータ移行が残っている。その作業内容の公開はまた今度で。

では。

この記事がお役にたちましたらシェアをお願いします

Tweet

日本人総経済評論時代がきていることについて その4

今回は、今後の日本が進むべき道を考察してみたいと思います。
今、日本で一般的に語られている日本の将来像は、イノベーション、もしくは公共事業の増加で財政を立て直し、国力をあげていこうという考えが一般的なようです。そしてきたるべき高齢者社会に備え、介護や福祉分野に移民を受け入れ、さらには消費税をあげていくべきだという考えがあるようです。

しかし、上記のような考えは、私は全く賛同できませんし、理解できません。
まず、高齢者社会についてですが、これはそもそも60歳以降は働かないで年金生活を送るという考え方そのものがおかしいと思います。
　体を使った肉体労働から、頭を使った知的社会に移り変わっているのに、この考えは完全に時代錯誤です。
　頭を使った労働なら、普通に70歳までは働けます。体のケアと頭のケアを怠らなければ75歳まで現役で働くことができるでしょう。もちろん女性・男性の区別も不要です。
　ただし、知的社会では、経験で劣る若者が高齢者より不利になるという問題点があります。
なので、今与えている高年齢者の数々のインセンティブを、若者に移すべきです。今は、若者が高齢者を支えるという考えが一般的でしたが、これからの時代は力を蓄えた高齢者が若者を支える社会に移行すべきです。
　知的労働がメインの社会に完全に移行すると、経験の浅い若者は、豊富な知識と経験を蓄えた高齢者より不利になります。（現在日本にあふれている老害は別）
　なので、社会に投げ出されても自立できるような力を得られるまでは、基本的に会社と社会が両輪となって若者を育てていくべきです。学校を卒業したばかりの18歳や22歳で一人前という考えは、20世紀の古い考えで、これからの高度知識社会では、社会に適応するために3年間ほどの期間を若者に与えて保護するべきでしょう。それほどに、現在の仕事・世の中は複雑化・多様化しています。

　また、介護分野へ若者の就職を促すのも賛成できません。高齢者が増えてきたから、若者は高齢者を支えるべきだという考えは間違っています。若者は若者の生きたいように生きるべきで、社会が若者にが高齢者を支えるように強制するのは愚の骨頂です。規制は国力を落とします。
　若さは武器です。新しい文化を生み出し、社会に根付かせるのは若者です。高齢者が足手まといとなり、若者の芽を摘むべきではありません。基本、高齢者は高齢者同士で支えあうべきです。それが無理なら、イノベーションを起こし、高齢化社会を支えられるような社会の仕組みを作り出すべきです。
　情報化社会がさらに発達すれば、個人の行動情報をリアルタイムで収集・分析し、常時健康を監視することも可能になるはずです。医療と情報技術をさらに高度に発達させて新・高齢化社会を成り立たせる社会を目指すべきであり、若者に依存するのは大反対です。
　そして、公共事業の増加です。これは介護分野の充実以上に反対です。
競争の働かない分野はなるべく排除すべきです。人権の保障・最低限の生活を支えるセーフティネット以外に官が介入してはいけません。貧困や社会不安を軽減するのが政府や官の役目で、市場の競争を阻害すべきではありません。

　つまり、今後の日本が進むべき道は、より強いイノベーションを起こすため、さらに市場の自由化を強め、競争を促すことです。
　福祉を充実させるために税金を高額にし、国民に配分しても、全員が今よりさらに不幸になるだけです。それよりは、能力の高い人間・企業に富と力を集中させ、高齢化社会に対応できる技術を生み出だしてもらったほうが、結果として全員が幸せになれるはずです。

次回はこれまでの総集として、１０年後の日本を予想してみようと思います。

この記事がお役にたちましたらシェアをお願いします

Tweet

日本人総経済評論時代がきていることについて その3

今回は、今後の世界で経済が発展して景気が回復しても、庶民は景気回復の実感を得られない世界がきているということについての考えを述べたいと思います。

なぜ、今後の世界では、ほとんどの庶民は景気回復の実感を得られないか。
それは、人材の二極化、つまり個の時代が本格的に到来するからです。

個の時代では、これまでの常識が通用しなくなると思います。
もうすでにその兆候は表れています。
これまでは、企業が消費者に向けて製品を作成し、一方的にメッセージを発して消費者が利用するという形態が成り立っていました。
しかし、これからは企業と消費者が直で話し合い、製品を作りあげていくことになるでしょう。そして、そのツールとして、今はソーシャルメディアが使用されています。
今後、個の時代を迎える有効なツールとしては、

Blog
Twitter
UStream
Skype
Youtube
FaceBook
クラウドサーバー

等が現在ではあげられると思います。
他にも様々なコミュニケーションツールが作成されていき、
今後はより個の力が強まっていくはずです。
そして、多くのスモールビジネスがたちあがり、一部の個人・少数グループが一企業に匹敵する富を得ることが可能になります。
　逆に、これまでに企業が独占していた仕事は個人に奪われます。
当然、個の時代に参加できない人達は、仕事の減った企業の中でさらに仕事を奪い合うことになります。収入などあがるはずがありません。むしろ大多数の人の給料は下がり続けます。

そして、たちが悪いことに、景気の指標を示すGDPはあがるでしょう。
世界に影響を与えるような個人・少数グループが数多く現れ、GDPを押し上げることが想像できるからです。なので、政府は景気は着実に良くなっていると発表します。
しかし、大多数の人は実感することができません。むしろ、下がっていると感じることになるでしょう。「実感なき景気回復」というやつです。
そして、今より多くの人が複雑な経済論を語り、政策を提言していくことになるでしょう。
これは、世界がある程度フラット化するまで繰り返される可能性が高いです。
私の予想ではあと20年後、つまり2030年くらいになって、ようやく現実を認識しはじめるようになると思います。

上記が、私が庶民が景気回復の実感を得られない世界がきていると思う理由です。
次回は、今後の日本が進むべき道を考察してみたいと思います。

この記事がお役にたちましたらシェアをお願いします

Tweet

日本人総経済評論時代がきていることについて その2

前回の日本人総経済評論時代がきていることについてその1では、現在の不況対策として、国債を刷って公共事業を行うべきという意見と、法人税を下げて国際競争力をつけて企業の儲けをあげ、税収を増やすべきだという意見には賛同できないと記述しました。

なので、今回は賛同できる意見について述べたいと思います。

まず、一番合理的だと思ったのは、ベーシックインカムの導入です。
べーシックインカムとは、簡単にいうと総国民基礎年金制度です。
一定の金額(7～8万程度)を全ての国民に支給し、最低限の生活を保障するのが目的です。
たとえば、ベーシックインカムが月7万円で、子一人の3人家族なら21万円が月の最低世帯収入になります。さらに父親・母親が月10万ずつ稼げば、41万円になります。
当然インフレも発生するでしょうが、最低限の生活を維持するのは問題ないでしょう。

なにより、ベーシックインカムの導入に賛成する一番の理由は、現代に労働の必要性を感じないからです。「働かざるもの食うべからず」というのは旧時代の発想だと思います。現代はテクノロジーの発展で食料を大量生産できるようになり、各国で農業の量を規制している状態です。農業人口は飽和なのです。今後は、さらに少ない人手で、大量の食料が生産できるようになるでしょう。他の国では水が問題となりますが、日本では問題ありません。そのうち、他の国でも改善されるでしょう。

近い未来、人間が生きていく上で必要な食料の維持に、これまでのような労働は不必要となります。つまり、生きていきためには働かないといけないという既存の概念が崩れて、なんのために生きて、何をして働いていくのかという新しい概念に変わっていくのです。

これは幸福であるともいえますが、不幸であるともいえます。とはいえ、ここで幸福論について語っても仕方ありません。ただ、ベーシックインカムというのは、これからの時代に適した考えだということが言いたかっただけです。

長くなったので、これでベーシックインカム導入賛成論はこれで終了したいと思います。
次回は、今後の世界では経済が発展して景気が回復しても、庶民は景気回復の実感を得られない世界に移行しているという考えを述べたいと思います。

でわ、また次回。

この記事がお役にたちましたらシェアをお願いします

Tweet

日本人総経済評論時代がきていることについて その1

最近、様々なお気に入りのブログを回っていて少し気になっていることがあります。
それは、やたらと経済について語る人の数が増えてきているということです。
これは長く続いている不況が原因でしょう。マルクスやハイエク等の経済学が取り上げられ、様々な政策提言が素人によってされています。
しかし、個人的には、経済や政策の視点から世の中を見るのは間違っていると思います。
でも、ネタとしては面白いので、この流れに私ものっかってみようと思います。
人気ブログのコメント欄を読むと、色々な意見や策が提示されていますが、自分が読んだところ、おおまかな意見は大きく二つに分類されています。

ひとつは、「今の不況は供給が需要を上回っているのが原因なので、国債を刷って政府が仕事を作るべきだ。借金は問題ない。」
という意見です。

もう一つは、「足りない税収をあげるために、企業がもっと金を稼げるようにするべきだ。法人税を下げろ、消費税をあげろ。」
という意見です。

イメージとしては、前者は今の民主党政権、後者は過去に行われた小泉政権での政策のことでしょう。
正直、自分はどちらの意見もピンときません。特に前者の意見は問題外であるとしか思えません。
この意見を主張する人達は、BS（バランスシート）不況だとか、日本国債は海外の債権保有率が低いから国債をいくら刷っても大丈夫と言っています。
はっきりいって、「何をいってるんだお前は」と言いたいです。
供給が需要を上回っているのなら、需要に供給を合わせればいいでしょう。そして、需要が増えたら、供給も増やせばいい。(BS)バランスシートとか、経済学なんて視点から物事を判断するから正常な判断が下せなくなるのです。供給=需要が一番分かりやすい。
単純に考えれば、「お金がないなら刷ればいいじゃない」なんて、幼稚園児のままごとでも発言しないと思います。
需要がないから失業者が増えるという意見が多いのですが、そもそもこれからの時代、勤労する必要がある人は限られてくる時代に移行するはずです。その意見はまた後で述べます。

後者の意見は、金が足りないから稼ごうという発想です。これは前者よりは良いです。個人的な嗜好として、前向きな意見は嫌いではありません。
しかし、日本が法人税を下げて不況からの脱出に成功したとしても、他の国も同様にまねするだけでしょう。そして、最終的にはどの国も同じような税率になります。結局は人材の勝負となり、今の日本では勝てないでしょう。

こう発言すると、ではお前はどんな意見なら納得できるのかと思う方もいるでしょう。
長くなったので、その意見は次の更新でお話します。

この記事がお役にたちましたらシェアをお願いします

Tweet

Androidアプリケーションのユーザーインターフェース(UI)の整え方～その1～

ユーザーインターフェース(UI)の作成で色々と苦労したので、作成方法のメモを残します。

例えば、以下のようなTextViewオブジェクトをxmlに記述したとします。

    <TextView android:id="@+id/page_title_label"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:layout_marginLeft="10px"
        android:layout_marginRight="10px" 
        android:layout_marginBottom="10px" 
        android:text="@string/page_title_top" />

上記は、指定した位置にTextViewオブジェクトを配置するxmlです。

表示される文字は、valuesフォルダ配下のstring.xmlのpage_title_topタグ内に記述された文字になります。

さらに、textSizeやtextColorなどを指定していくことになります。

しかし、textSizeやtextColorなどは配置位置とは異なり、共通で使いまわすことが多いと思います。

しかも、変更が起きることもあるでしょう。そのたびに、全てのtextSizeやtextColorを変更していたのでは面倒です。

こういった場合に対応するには、style.xmlを使うと便利です。

style.xmlには、以下のように記述します。

    <style name="page_title">
        <item name="android:textSize">12sp</item>
        <item name="android:textColor">#000000</item>
        <item name="android:background">#FFFFFF</item>
        <item name="android:typeface">monospace</item>
        <item name="android:textStyle">normal</item>
    </style>

上記で指定しているname属性は、あらゆるViewのオブジェクトで指定するべきです。

属性typefaceとtextStyleの指定はしない人が多いと思いますが、指定するべきです。

typefaceはテキストの書体を指定します。

日本語の場合はmonospaceを指定しましょう。日本語は等間隔のmonospaceが読みやすいとされているからです。

英語の場合はsansもしくは、serifにしましょう。英語は等間隔のmonospaceは読みにくいとされています。

textStyleは、テキストのスタイル（通常、太字、斜体）を指定します。
デフォルトはnormalです。他にbold（太字）、italic（斜体）も使用できるので、見やすい
ユーザーインターフェースをつくるためにも利用したほうが良いでしょう。

上記のstyle.xmlはTextViewの記述されたxmlに追加することで、適用できます。

    <TextView android:id="@+id/page_title_label"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:layout_marginLeft="10px"
        android:layout_marginRight="10px" 
        android:layout_marginBottom="10px" 
        android:text="@string/page_title_top" 
        style="@style/page_title" />

上記のように指定することで、style.xmlに指定した属性が反映されます。
他のオブジェクトで流用も可能な上、変更しても一発ですべて直せます。

というわけで、とりあえず基本的なxmlの使い方の説明でした。
他にも色々と公開していきたいと思います。でわ。

この記事がお役にたちましたらシェアをお願いします

Tweet

Androidアプリケーション Junitテストの作り方 ～その1～

オリジナルのAndroidアプリケーションの作成がほぼ終了し、テストの段階に入りました。
せっかくなので、Junitを使ってテストを書こうと思ったのですが、全然情報がありません。
他のみんなはJunitを使ったテストを作成しないで、リリースしているのでしょうか？？？
ちなみに、私が仕事で携わった(っている)Androidアプリケーションプロジェクトでは、Junitテストは通していませんw
まあ、そんなわけで、ブログ上に情報を逐次UPしていきたいと思います。
こういった知識はみなさんで共有しましょう。
iPhoneに勝つために！W
では、まず第一回目です。

手順

1. Eclipseを使ってTest用のアプリケーションを作成します



2. ファイル → 新規 → Android Test Projectを選択します



3. Test Project Name欄に作成したいテストアプリケーション名を入力します。アプリケーション名+Testが良いと思います



(例)アプリケーション名 : Sample

テストアプリケーション名 : SampaleTest




4. Test Target項目のラジオボタンで
   An exsiting Android projectを選択します


5. 参照ボタンを押下して、アプリケーションを選択します



自動認識されて、ビルド・ターゲット欄とプロパティ欄が埋まります。




6. 完了ボタンを押下します



テストアプリケーションプロジェクトが作成されます。




7. プロジェクトを開くと、パッケージフォルダが作成されています



8. まずはここに、全てのテストクラスを実行するAllTests.javaクラスを作成します




import android.test.suitebuilder.TestSuiteBuilder;
import junit.framework.Test;
import junit.framework.TestSuite;

public class AllTests extends TestSuite {

   public static Test suite() {
       return new TestSuiteBuilder(AllTests.class)
               .includeAllPackagesUnderHere()
               .build();
   }
}




9. 次に作成したいクラスのテストクラスを作成します



以下のサンプルでは、アプリケーションのTopページActivityのTop.javaの
テストクラスを作成しています





import java.text.SimpleDateFormat;
import java.util.Calendar;

import jp.co.dietrecorder.R;
import jp.co.dietrecorder.Top;
import android.content.Context;
import android.test.ActivityInstrumentationTestCase2;
import android.test.suitebuilder.annotation.MediumTest;
import android.widget.TextView;


public class TopTest extends ActivityInstrumentationTestCase2 {
 
 public TopTest() {
  super("jp.co.Sample", Top.class);
 }
 
 @Override
 protected void setUp() throws Exception {
  super.setUp();
 }
 
 /**
  * アプリケーション初期立ち上げの時のデータ確認
  */
 @MediumTest
 public void testAppicationInit() {
  assertTrue(true);
 }
 
}





この時、上記で注意しないとならないのは以下の通りです。

• コンストラクタの引数は第一引数が「アプリケーションのフォルダ名」
  
  第二引数が「テスト対象クラス名」
  
  であること
  


• テストメソッドはtest～で開始すること(アノテーションはなくても動きます)


• publicメソッドであること


• assertのメソッドを利用していること

になります。




10. 以上がきちんと設定されていると、JUnitの緑色のバーが現れるはずです。

追記

テストクラスで継承しているActivityInstrumentationTestCase2クラスは
機能テストを行うクラスです。
単体テストはAndroidTestCaseで行えるようです。
ActivityInstrumentationTestCase2を継承すると、Activityをlaunchしてテストを
行いますが、AndroidTestCaseだとlaunchせずにテストが行えます。

私は、今回のアプリケーションではActivityInstrumentationTestCase2を利用してJunitテストを行う予定なので、
AndroidTestCaseを使ってテストをすることを考えている人は申し訳ありません。

では、次からは本格的なテストクラスを作成していきましょう

追記2
そのうちレンタルサーバーを借りてきれいにまとめます。自分でも確認したいのでw

この記事がお役にたちましたらシェアをお願いします

Tweet