お知らせ
現在サイトのリニューアル作業中のため、全体的にページの表示が乱れています。
- 投稿日：
WSLのUbuntuにRedmineを建ててnginxを通して適当なバーチャルホストでアクセスするまで
確認環境
| Env | Ver |
|---|---|
| Ubuntu | 20.04.6 |
| Ruby | 2.7.0 |
| Redmine | 5.1.0 |
| nginx | 1.18.0 |
インストール方法
基本は公式の通り
DB作成
CREATE DATABASE redmine CHARACTER SET utf8mb4;
CREATE USER 'redmine'@'localhost' IDENTIFIED BY 'my_password';
GRANT ALL PRIVILEGES ON redmine.* TO 'redmine'@'localhost';
インストールコマンド流す
wget https://www.redmine.org/releases/redmine-5.1.0.zip
unzip redmine-5.1.0.zip
cd redmine-5.1.0
cp config/database.yml.example config/database.yml
# DB接続は公式ドキュメントに沿って適当に設定する
# nano config/database.yml
sudo apt install -y ruby-full make gcc libmysqlclient-dev
sudo gem install bundler
bundle config set --local without 'development test'
sudo bundle install
bundle exec rake generate_secret_token
RAILS_ENV=production bundle exec rake db:migrate
RAILS_ENV=production bundle exec rake redmine:load_default_data
bundle exec rails server -e production -p 9999 -d
nginxから繋ぐ
普通にリバプロするだけ
server {
listen 80;
client_max_body_size 100m;
server_name redmine.test;
access_log /var/log/nginx/redmine.access.log;
error_log /var/log/nginx/redmine.error.log;
location / {
proxy_set_header Host $http_host;
proxy_pass http://127.0.0.1:9999;
}
}
トラブルシューティング
An error occurred while installing redcarpet (3.6.0), and Bundler cannot continue.
makeとgccがない
sudo apt install -y make gcc
An error occurred while installing mysql2 (0.5.5), and Bundler cannot continue.
MySQLの開発ライブラリがない
sudo apt install -y libmysqlclient-dev
"/usr/bin/ruby2.7: warning: shebang line ending with \r may cause problems" redmine
無視してよい
デフォルトポートを3000から変えたい
以下のように-pで指定
bundle exec rails server -e production -p 9999 -d
デーモンにしたい
以下のように-dで指定。殺すときはpkill rubyで行ける
bundle exec rails server -e production -p 9999 -d
Windows側のスタートアップで起動したい
不明。少なくとも以下の形式だと上手く動かない。
wsl -d Ubuntu -u root -- <command>
systemdを有効化すると色々不具合があるのでinit.dで起動できれば解決できる気はするのだが、上手くいかなかった。
- 投稿日：
特定ブランチ以外を全部消す
Git 2.25.1で確認
# マージされてないのは残す
git branch -d $(git branch | grep -vP <PCRE pattern>)
# 強制削除
git branch -D $(git branch | grep -vP <PCRE pattern>)
参考：git-branch - List, create, or delete branches (git-scm.com)
マージコミットをリバートする
Git 2.25.1で確認。基本-m 1で問題ないと思われる
git revert -m 1 <commit>
コミット間のハッシュを見る
Git 2.25.1で確認
# 新しい順
git log --pretty=format:'%H' <commit>..<commit>
# 古い順
git log --pretty=format:'%H' <commit>..<commit> --reverse
- 投稿日：
TypeScriptで関数を書いているときに戻り値の型を書くケースがあるが、個人的にはあれは基本書かないほうがいいと思っているので、その理由を書いていく。
コード記述が冗長になる
まず型を書くと記述が冗長になる。以下のコードを見ると戻り値型が長く読みづらく、書くのも面倒だ。まずこんな長い命名をやめたほうが…というのはあれど、現実問題として長い命名は存在するので仕方ない。
export const getCampanyAndDepartmentAndEmployeeFromPrefectureCode = (
param: VeryveryLoooongestParamTypeNaming,
): VeryveryLoooongestReturnTypeNaming => {
return param.db.con.execQuery(
"SELECT * FROM foo WHERE id = :?",
param.dbParam.foo.id,
);
};
しかし以下であれば戻り値型がない分すっきりしていて見やすいし、書く手間も掛からない。更に型推論によって正しい型が返るので理想的だ。
export const getCampanyAndDepartmentAndEmployeeFromPrefectureCode = (
param: VeryveryLoooongestParamTypeNaming,
) => {
return param.db.con.execQuery(
"SELECT * FROM foo WHERE id = :?",
param.dbParam.foo.id,
);
};
実装と異なる戻り値型を暗黙的に記述できる
例えば以下のように書けば戻り値の型は'foo' | 'not foo'となり、常に正しい型が返る。
export const foo = (isFoo: boolean) => {
return isFoo ? 'foo' : 'not foo';
};
しかし以下のように戻り値の型を定義すると実装上存在しない'bar'が返る。これは実装時に無用な混乱を生む。一般的にこのようなケースは仕様削除やリファクタなどで生まれることがあると思うが、そういうメンテ漏れにもなるので書かないほうが安全だといえる。
export const foo2 = (isFoo: boolean): 'foo' | 'not foo' | 'bar' => {
return isFoo ? 'foo' : 'not foo';
};
他にも次のケースでは戻り値がstringとなり、何が返ってくるのかが実装を見ないと解らなくなる。特に理由がないなら書かないほうがよい。
// 'foo' | 'not foo'になるはずだがstring扱いになる
export const foo3 = (isFoo: boolean): string => {
return isFoo ? 'foo' : 'not foo';
};
型記述が混乱する
ここは基本的に前項の内容と重複する内容となる。
例えば次の二つの実装は同じだが、戻り値の型だけが異なる。こういう実装が混在すると実装の一貫性が失われ無用な混乱を生むので、指定しないほうが望ましい。
const IndexPage = (): JSX.Element => {
return (
<Layout title={'Hello Next.js'}>
<>
<h1>Hello Next.js 👋</h1>
</>
</Layout>
);
};
const IndexPage2 = (): ReactElement => {
return (
<Layout title={'Hello Next.js'}>
<>
<h1>Hello Next.js 👋</h1>
</>
</Layout>
);
};
書いてもよいと思うケース
例えば依存関係を持たせたい時など、インターフェースとして型を共通化したい場合は書いてもよいと思う。これはどこでそれを使うのかが自明になるからだ。改修時にも型によって関連処理が見出しやすくなるので意識しやすくなる。
export const createPostMessage = (
channel: string,
username: string,
message: string,
): PostMessage => {
return {
channel,
username,
message,
};
};
export const postMessage = async (param: PostMessage) => {
try {
return await fetch('https://example.com/api/postMessage', param);
} catch (err) {
return err;
}
};
但しこのようなケースではUnit Testを書いて、実装された戻り値型を満たす値が返ることを確認するのが望ましい。
戻り値型を書かないことによるデメリット
TypeScriptの公式リポジトリによると、型推論の速度に悪影響を及ぼすとあるので、型推論の速度が落ちるという点だ。
もし型推論の速度が非常に遅いと感じた場合は書いてみてもよいと思うが、公式でも以下のように案内があり、和訳すると「型推論は非常に便利なので、これを普遍的に行う必要はありませんが、コードの遅いセクションを特定した場合に試してみると便利です。」とあるので、余程複雑なことをしていない限り不要だとは思うし、そんな複雑な型を返すような処理は必要がなければ書かないほうがいいだろう。
Type inference is very convenient, so there's no need to do this universally - however, it can be a useful thing to try if you've identified a slow section of your code.
少なくとも私は実務上、型推論の速度に困ったことがないのと、tscでビルドすることも稀であるため、ビルドに影響することもない。よって基本書いていない。
- 投稿日：
開発時に一々rootが持ってるフォルダを触るのが嫌でホームディレクトリ配下で作業したいというのは往々にしてあるので、それを楽にやる方法。
以下のようにnginxのルートディレクトリに適当なパスを切り、パーミッションを777にした上でシンボリックリンクを張ればよい。
sudo mkdir /var/www/html/hoge
sudo chmod 777 /var/www/html/hoge
ln -s /var/www/html/hoge hoge
ホームディレクトリをnginx設定のrootとして指定すると上手く行かなかったので、そのアプローチは諦めた。（755指定してても読みに行けない、777ならいけると思うがそれは避けたい）