Redmineリプレースメモ
Redmineのリプレースで見たところメモ
bitnami redmineのWindows向けパッケージを使っていたが、 これのインストーラの提供が終わっていた。
linux環境に移すため、redmine自体のバージョンアップも実施するため、 移す必要のあるデータを絞り込んだ。
Redmineサービスの構成イメージ
Redmineサービスは、ざっくり3つのプログラムが連携して動作している。(はず)
- Remine本体
このRedmine本体が、Webサーバ、DB(データベース)と連携してサービスを実現する。
- Webサーバ
Webアクセスを受け付けて、Redmineプログラムを呼び出すためのプログラム。
Webサーバプログラムは、大抵、Redmineとは別のプログラムとして実行される。
Apache2とか、nginxとか。
- DB(データベース)
Redmineは大量のデータ(大量のユーザ情報、大量のチケット情報、etc)を制御し、表示する。
これら大量のデータは、データベースにアクセスする形で管理される。 データベースプログラムは、大抵、Redmineとは別のプロセスとして実行される。
移す必要があるデータ
上の図で色をつけたデータが、リプレースに必要になる。
- DB データテーブル
ユーザ情報やチケット情報は、ほとんどDBのデータテーブルに保存されている。
これはmysqlコマンドなどでアクセスして、エクスポート/インポートを実行できる。 ※新たに立ち上げるRedmineのバージョンが変わる場合は、マイグレーションのスクリプトを実行する必要がある。 マイグレーションのスクリプトは、Redmineプログラムに付属している。
- Redmine設定ファイル(config/database.yml)
redmineプログラムがDBにアクセスするための、ユーザID/パスワードを設定ファイルに書き込む必要がある。
※新規でDBを立ち上げることになるので、リプレース情報というよりは、新規DBで作った新しいユーザID/パスワードを記入する。
- Redmine設定ファイル(config/configuration.yml)
redmineプログラムが外部プログラムにアクセスするための、ユーザID/パスワードを設定ファイルに書き込む必要がある。 例えばRedmineがメールサーバにアクセスするための情報など。
※機能を使う予定が無いなら、不要。
- Redmine添付ファイル群(files/***)
チケットに添付したファイルや、wikiページに書いたWebページなどは、添付ファイルとして保存されている。 そのままコピーする。
Redmineはプラグインによって機能を拡張することができる。
後から追加したプラグインは、ここに格納されている。 そのままコピーする。
※新たに立ち上げるRedmineのバージョンが変わる場合は、プラグインごとのサポートバージョンをチェックする必要がある。
参考
Rustのhelloworldほか
rustのhelloworldを作って動かしてみる。
プロジェクト作成
1.空のプロジェクトを作成
>cargo new helloworld
Created binary (application) `helloworld` package
>cd helloworld
2.自動生成のコードをチェック
>type src\main.rs
fn main() {
println!("Hello, world!");
}
通常実行
1.コンパイル&実行
>cargo run
Compiling helloworld v0.1.0 (C:\...\helloworld)
Finished dev [unoptimized + debuginfo] target(s) in 0.70s
Running `target\debug\helloworld.exe helloworld`
Hello, world!
cargoの機能を試してみる
ひとまずcargoの機能を見てみる。 通常のrunのほか、いくつか立ち上げ方があるようなので試してみる。
>cargo help
Rust's package manager
USAGE:
cargo [+toolchain] [OPTIONS] [SUBCOMMAND]
OPTIONS:
-V, --version Print version info and exit
--list List installed commands
--explain <CODE> Run `rustc --explain CODE`
-v, --verbose Use verbose output (-vv very verbose/build.rs output)
-q, --quiet No output printed to stdout
--color <WHEN> Coloring: auto, always, never
--frozen Require Cargo.lock and cache are up to date
--locked Require Cargo.lock is up to date
--offline Run without accessing the network
--config <KEY=VALUE>... Override a configuration value (unstable)
-Z <FLAG>... Unstable (nightly-only) flags to Cargo, see 'cargo -Z help' for details
-h, --help Prints help information
Some common cargo commands are (see all commands with --list):
build, b Compile the current package
check, c Analyze the current package and report errors, but don't build object files
clean Remove the target directory
doc Build this package's and its dependencies' documentation
new Create a new cargo package
init Create a new cargo package in an existing directory
run, r Run a binary or example of the local package
test, t Run the tests
bench Run the benchmarks
update Update dependencies listed in Cargo.lock
search Search registry for crates
publish Package and upload this package to the registry
install Install a Rust binary. Default location is $HOME/.cargo/bin
uninstall Uninstall a Rust binary
See 'cargo help <command>' for more information on a specific command.
機能がいくつもありそうだが、ひとまず手ごろそうなdoc, testを試してみる。 多分 docがドキュメント作成、testがテストコードの実行 ？
cargo doc
1."cargo doc"を実行してみる。
> cargo doc >dir target\doc\helloworld all.html fn.main.html index.html sidebar-items.js
2.出てきたindex.htmlを開いてみる。
>target\doc\helloworld\index.html
→*.htmlに紐づけたブラウザでindex.htmlが開けた。
3.コードをいじってみる。
+/// これはmainです
fn main() {
println!("Hello, world!");
}
> cargo doc > target\doc\helloworld\index.html
cargo test
1.cargo testを実行してみる
>cargo test
Compiling helloworld v0.1.0 (C:\...\helloworld)
Finished test [unoptimized + debuginfo] target(s) in 0.52s
Running unittests (target\debug\deps\helloworld-2f37b4d133137ab4.exe)
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
2.コードをいじってみる(正常)
+#[cfg(test)] +mod tests { + #[test] + fn my_test() { + assert_eq!(2 + 2, 4); + } +} + fn main() { println!("Hello, world!"); }
> cargo test
Compiling helloworld v0.1.0 (C:\...\helloworld)
Finished test [unoptimized + debuginfo] target(s) in 0.52s
Running unittests (target\debug\deps\helloworld-2f37b4d133137ab4.exe)
running 1 test
test tests::my_test ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
3.さらにコードをいじってみる(異常コード追加)
#[cfg(test)] mod tests { #[test] fn my_test() { assert_eq!(2 + 2, 4); } + #[test] + fn my_test_case2() { + assert_eq!(2 + 2, 3); + } } fn main() { println!("Hello, world!"); } fn main() { println!("Hello, world!"); }
>cargo test
Compiling helloworld v0.1.0 (C:\...\helloworld)
Finished test [unoptimized + debuginfo] target(s) in 0.17s
Running unittests (target\debug\deps\helloworld-2f37b4d133137ab4.exe)
running 2 tests
test tests::my_test ... ok
test tests::my_test_case2 ... FAILED
failures:
---- tests::my_test_case2 stdout ----
thread 'tests::my_test_case2' panicked at 'assertion failed: `(left == right)`
left: `4`,
right: `3`', src\main.rs:9:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
tests::my_test_case2
test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--bin helloworld'
→エラーが検出された .. かな？
rustインストール
公式ページの手順に従う
公式ページにアクセス https://www.rust-lang.org/ja/tools/install
rustup-init.exe(64bit)をダウンロード
ダウンロードしたrustup-init.exeを実行
コマンドプロンプトの表示から、インストール方法を選択。(Proceed with installationを選択)
The Cargo home directory located at:
C:\Users\<USERNAME>\.cargo
This can be modified with the CARGO_HOME environment variable.
The cargo, rustc, rustup and other commands will be added to
Cargo's bin directory, located at:
C:\Users\<USERNAME>\.cargo\bin
This path will then be added to your PATH environment variable by
modifying the HKEY_CURRENT_USER/Environment/PATH registry key.
You can uninstall at any time with rustup self uninstall and
these changes will be reverted.
Current installation options:
default host triple: x86_64-pc-windows-msvc
default toolchain: stable (default)
profile: default
modify PATH variable: yes
1) Proceed with installation (default)
2) Customize installation
3) Cancel installation
>1
- cargo ( rustのパッケージマネージャ )のパスが通っていることを確認する。
>cargo --version cargo 1.52.0 (69767412a 2021-04-21)
スケジューリングを無理やり分類（メモ）
OSのスケジューリングメモ
OSのスケジューリングは、少数のCPUで、多くのプロセスをこなすために実施される。
wikiとかみても、スケジューリングを比較できるような要素に切り分けては書かれていないようなので無理やり分けてみる。
プロセスの処理単位を適切に区切り、次のプロセスを実行する。
プロセスの処理単位を区切る方法として、以下2種類の方法がある。
- プリエンプション
- ノンプリエンプション
プリエンプション
プロセスを割り込みによって中断させる。
割り込みの種類は、例えば時間割り込みなどである。
ノンプリエンプション
プロセスへの割り込みを許さない。
プロセスの終了は各々のプロセス自身が管理する。
よって短い間隔での処理完了が求められたりする。...はず。
次のプロセスを実行する方法として、以下の方法がある。
FIFO/ラウンドロビン
実行可能キューにプロセスが到着した順番にプロセスをキューイングし、先頭から順に実行する。
FIFOはノンプリエンプション方式。
ラウンドロビンはプリエンプション方式。時分割でプロセスが切り替わる。
最短ジョブ優先（SPT）/最小残余時間優先（SRPT）
キュー内で残り処理時間の推定値が最も短いプロセスをスケジューラが選択する。
SPTはノンプリエンプション方式。短いプロセスが終わるまで長いプロセスは待ち続ける。
SRPTはプリエンプション方式。短いプロセスが来た時、実行中プロセスの残時間と比較する。より短い方を先に実行する。
優先度順
プロセスに優先度をつけ、優先度が高い順にキューイングする。
だいたいこんな感じだと思う。
こういう話をベースに、OSごとの仕様を読まねば。頭入らん。
参考
スケジューリング - Wikipedia
sched_setscheduler - システムコールの説明 - Linux コマンド集 一覧表
Man page of SCHED
AndroidStudioでのgitバージョン管理方法
既に作成済みのandroid studioプロジェクトをgitに登録し、リモートリポジトリを作成、内部で公開する。
▼手順
1.windows上にgitをインストールする
2.android studioのプロジェクト内でgitリポジトリを作る
3.公開フォルダでリモートリポジトリを生成する
4.公開フォルダにandroid studioプロジェクトをpushする
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
1.windows上にgitをインストールする
gitツールをダウンロード、インストールする
Git
- >Download
- >Windows, 64bit, 非portable版
2.android studioのプロジェクト内でgitリポジトリを作る
2-1.gitリポジトリを有効化
android studioでプロジェクトを開く
メニューバー>[VCS]>[Enable Version Control Integration]
- >Select a version control～ > [Git], [OK]
バージョンコントロールが開始され、画面下部TODO, Android Monitor,...の中に
Version Controlが追加される。
2-2.gitリポジトリにファイル一式を登録
VersionControlタブを選択し、登録したいファイルを選んでDefaultにドラッグ&ドロップする。
（とりあえず全部貼り付け。）
Defaultを右クリックし、Commit Changes...を選択。
ポップアップが出るので、Commit Messageを入力して、Before commit欄のチェックをすべて外して、commit。
さらにgitのユーザ名を聞かれるので、とりあえず適当に無効な名前、Eメールアドレスでも入れてcommit。
2-3.commit内容の確認
Android Studioプロジェクトの実ファイルがあるフォルダをエクスプローラで開く。
右クリックしてコンテキストメニューから[Git Bash Here]を選択。
MINGW64のターミナルが起動するので、以下コマンドを打つ。
$ git log
2-2で入力したCommit Messageを含んだログが出ることを確認する。
3.公開フォルダでリモートリポジトリを生成する
他所の適当なフォルダで右クリックしてコンテキストメニューから[Git Bash Here]を選択し、ターミナルを起動。
（ここではc:\work\に作る。）
以下コマンドを実行する。
$ git --bare init --shared $ git log
フォルダにgitの各種ファイルが出来上がったことを確認。
また、gitのコミットログがないことを確認しておく。
4.公開フォルダにandroid studioプロジェクトをpushする
2のAndroid Studio プロジェクトフォルダに戻って以下コマンドを実行する。
$ git remote add origin /c/work/ $ git push origin master
3のリモートリポジトリに戻り、以下コマンドを実行する。
$ git log
この時点で、Android Studioプロジェクトのものと同じログが出てくることを確認できる。
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
3の公開リポジトリをsamba上のフォルダや、ssh接続のフォルダに変えれば、
一応アクセス範囲を絞って公開できているはず。
未調査の点
・リモートリポジトリの作成オプションはbareとsharedがあるが、それらの意図。
参考
第24回 バージョン管理 ─GitとGitHub連携：Android Studio最速入門～効率的にコーディングするための使い方｜gihyo.jp … 技術評論社
android api level
android APIレベルのサポートレベルが変わる話メモ。
2017年のどこかで、google play service libraryがサポートするAPIレベルが変わる。APIレベル14以下がサポート対象外になるらしい。
（google play serviceを利用したアプリをビルドするとき、最新版を取り込めなくなるってだけの話？既存の機能追加もないアプリは影響なし？）
APIレベル14は、イコールAndroid4、Android4.0.1、Android4.0.2。
AndroidStudio apkファイル名プロパティ探し
AndroidStudioで [Build -> Build APK]を実行した際、apkファイル名がデフォルトのものになってしまう。
これを自由なファイル名に変更する。
appのbuild.gradleに以下のプロパティを追記する。
android{
applicationVariants.all {variant ->
variant.outputs.each{ output ->
def fileName = "output.apk"
output.outputFile = new File(output.outputFile.parent, fileName)
println output.outputFile
}
}
}どういう意味か。
たぶん以下の内容だと思う。
Gradle Plugin User Guide - Android Studio Project Site
- >Manipulating tasks
- >All three variant classes share the following properties
表中 "outputFile"。
ApplicationVariantに含まれるパラメタのうち、outputFileが出力apkファイルの情報を表すFileクラスと思われる。
Fileクラスは多分これ
Project - Gradle DSL Version 2.2-20140924021627+0000
>File file(Object path, PathValidation validation)
ちょっと調べたけどよくわからなかった点。
１．上ではApplicationVariantsの中のApplicationVariant１つだけを見ている。ApplicationVariantsは他に何を含むのか。
２．Gradle pluginの記述ではApplicationVariantの中にoutputFileがあるはず。
だが実際にはApplicationVariant.outputsの下にoutputFileがある。この差異はどこから来るものか。
