Redmineのプラグインを入れてみた
このサイトのコメント多いプラグインから使えそうなやつをチョイスして設定。
設定方法はだいたい
- プラグインダウンロード
- %REDMINE_HOME%apps/Redmine/htdoc/spluginsに配置
- $ rake redmine:plugins:migrate RAILS_ENV=production
の3ステップで行ける。RedmineのDB定義を変更しない場合は3はいらないっぽい。
注意事項
%REDMINE_HOME%はそれぞれの環境に応じて。
環境変数Pathを設定していないとエラーになるが
移動してからやればPath設定してなくてもエラーにならず実行できる。
%REDMINE_HOME%apps edminehtdocs
Redmineのバージョンに応じたプラグインのバージョンを入れるのがポイント。
bitnamiのRedmineの場合、commandToolsから全部再起動すると上手くいかなかった。再起動した後、3をやったらうまくいく。再起動だけやとInternal Errorとかいうのになって冷や汗書くことになるので、あせらずもっかい3やればいける。
リーダブルコードを読んでみて vol1
リーダブルコード読みたいなって思ってたんやけど、専門書ってちょっと高いんよね。んで、amazonとかで中古探してもそんなに安くないし。たまたま図書館でみつけて、そく借りました。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/06/23
- メディア: 単行本(ソフトカバー)
- 購入: 68人 クリック: 1,802回
- この商品を含むブログ (117件) を見る
とりあえず今日時点でひっかかったとこ。
20 値の単位をつける。delay_secs size_mb
_φ(・_・ #komebook
— 米将軍 (@komeshogun) November 2, 2014
変数名に単位つける発想はなかった。
— 米将軍 (@komeshogun) November 3, 2014
コメントを書くことで、コードの品質や状態を知らせたり、さらには改善の方向を示したりできる
#リーダブル #米読
— 米将軍 (@komeshogun) November 3, 2014
これ、やりたい!ToDO入れるのと同じかと思うけど、あんまりやったことない。改修しててなんか汚い。でも今回触るとこちゃうし、テスト考えたら触りたくないって時にコメントだけ残しておくのもありかも。
ひどいコードに優れたコメントをつけるより、優れたコードのほうがよい。
#リーダブル #米読
— 米将軍 (@komeshogun) November 3, 2014
行数を短くするよりも、他の人が理解するのにかかる時間を短くする
#リーダブル #米読
— 米将軍 (@komeshogun) November 4, 2014
所詮コメント。コメント書くならコード書けよって話です、ごもっとも。
「ソフトウェアアーキテクトが知るべき97のこと」も読んでみた
ソフトウェアアーキテクトが知るべき97のこと
っていう本もあるのをたまたま見つけて
読んでみました。
結論としては、「プログラマ」のほうが響いたので、まずはそっちをよむことをオススメします。
- 作者: 鈴木雄介,Richard Monson-Haefel,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2009/10/05
- メディア: 単行本(ソフトカバー)
- 購入: 17人 クリック: 362回
- この商品を含むブログ (82件) を見る
2 新しくてクールなソリューションを使ってみたい誘惑は大きいが、正しいものを選んだほうが、チームも顧客も幸せになる。_φ(・_・ #komebook
— 米将軍 (@komeshogun) November 2, 2014
新しいものはついつい使ってみたくなりますが、安定しているところに無理やり、「ただやってみたいだけ」でやるのはビジネスではないですね。ただの趣味です。目的があり、顧客と合意がとれているのであれば、「やってみなはれ」ですが、理由なきは、ただの趣味です。
何を求めているのかをたずねれば、アーキテクトは本当の問題を考え出せる。クライアントがいう解決策よりも安くてより良い方法を考え出せる _φ(・_・ #komebook
— 米将軍 (@komeshogun) November 2, 2014
お客さんで少しITのスキルを持っている人ほど、最終結論だけで依頼をなげてくるけど、なぜそういう話が出てきたのか?という源泉な話は絶対にしたほうがいい。たとえ最終的に顧客からの提案が答だったとしても、それは結果論。その場合でも源泉は聞いたほうがいい。ってか聞くべき。
42 同じ日程で元の予定よりも多くの仕事をしてくれとか、仕事量を減らさずに日程を短縮してくれというような話。_φ(・_・ #komebook
— 米将軍 (@komeshogun) November 2, 2014
あるある。これをどれだけ交渉できるかが腕の見せどころ。別に期間を伸ばしてくれ!っていう交渉じゃなくて、今回はのむから、次はよろしくねっていう信頼貯金にする方法だってある。とにかくこういう事が起きるのは至極当然な社会なので、それを無くすのではなく、それをどう活かすかって考えるほうが現実的。でももちろん、少しずつ無くす方向にも持っていかないとね。
Redmineをなんとなく使っていたらわからなかったこと
Redmineをなんとなく勉強もせずに、なんとなく使ってたら気付かなかった機能を紹介します。
チケットにコミットログが紐付けられるのは知っていたのですが、すんなり表示される時と、リポジトリページを一回開かないと表示されない時があるなーってなんとなく思ってたら、そういう仕様だったんですね。という話。
「リポジトリ」を開くまでSubversion等のリポジトリへのコミットが「活動」に表示されません — Redmine.JP
コミットしたらチケットのステータス更新とか出来るんや!フェーズごとにブランチ切っててデプロイしたらチケットをポチポチ更新してたのに。今度からコミットログでいけるやん!って話。
使いこなせてなかった機能たち。
とくにバージョンは便利ですね。STEP1開発とかよくある話。わざわざ「バージョン」ってカスタムクエリ作ってたよ(T_T)
ロードマップ画面に特定のトラッカーのチケットが表示されない — Redmine.JP
勢いで他にもないかなぁって調べてみた結果。いろいろあるね。
目からうろこは「Redmineの右クリ。」
さっきのマージしたチケットを一括でステータス更新も右クリ使えばいいやん。
コミットログでの自動ステータス更新とどっちがいいかな?
Redmine、知れば知るほど便利です。プラグインも全然入れてないから便利なのあったら使おうかな。
その前にバージョンアップせなアカンねんけど、それも重そうなタスクです。
「プログラマが知るべき97のこと」からの7つのこと
毎朝仕事を行く前に10分こつこつ読んでは
気になった所をツイートしてた。
とりあえず7つ集まったので、まとめてみた。
願いが叶うといいな。
- 作者: 和田卓人,Kevlin Henney,夏目大
- 出版社/メーカー: オライリージャパン
- 発売日: 2010/12/18
- メディア: 単行本(ソフトカバー)
- 購入: 58人 クリック: 2,107回
- この商品を含むブログ (339件) を見る
イエスから始める。最終的に要望に応えないとしても、何故その要望が合致しないのかきちんと説明すれば実りのある会話ができる。
依頼を受けた時は結論を急がず、要望の源泉、背景を聞くようにしてる。違った結論を提案出来ることもある。
— 米将軍 (@komeshogun) 2014, 10月 31
プロフェッショナルの最大の特徴は、自分の責任をとるという態度、責任感。自分の力で自分の価値を高め、成長する。
責任感ある人は、真摯的で交換がもてます
— 米将軍 (@komeshogun) 2014, 10月 30
学び続ける姿勢。本当に身につけたい技術は、コードを自ら書き、手を動かして学ぶ。常に自分よりレベルの高い人と仕事をするようにする。
_φ(・_・ #komebook
— 米将軍 (@komeshogun) 2014, 10月 30
出来てはならぬことを禁じるのではなく、はじめから出来ていいことだけを出来るようにする。
_φ(・_・ #komebook
— 米将軍 (@komeshogun) 2014, 10月 28
他人よりも自分を疑う。
その姿勢が大事で、すぐに責任転嫁しようとすると信頼を損ねる。ミスは誰もがあるので、その後の態度が人の価値を決める。反面教師で学んだ。
— 米将軍 (@komeshogun) 2014, 10月 27
ボーイスカウトルール。
来た時よりも美しく。は誤るとデグレになり、怒られるパターン。それを踏まえて美しく出来るかどうか。腕が試されるね。
— 米将軍 (@komeshogun) 2014, 10月 27
ユーザが何をするかを観察する。
どれたけ設計が整然として、コード綺麗でも運用にのらないシステムは意味がない。ユーザにとって価値があり、役立つシステムを作ることが判断基準にしてる。
— 米将軍 (@komeshogun) 2014, 10月 27
続 WeblogicServerでGC出力の設定
前回の続き。
コマンドファイルを直接編集するとこまでは良かったけど
\\Oracle\Middleware\user_projects\domains\base_domain\bin\startWebLogic.cmd
設定するパラメータがまずかった。
Unknown option or illegal argument: -Xloggc
って言われて、GCログをファイル出力できなかった。
↓こんな感じに変えたらはいてくれた。リダイレクトしている前提で、していなかったらログ出力じゃなくてコンソールにはかれると思う。
変更前
%JAVA_HOME%\bin\java %JAVA_VM% %MEM_ARGS% -Dweblogic.Name=%SERVER_NAME% -Djava.security.policy=%WL_HOME%\server\lib\weblogic.policy %JAVA_OPTIONS% %PROXY_SETTINGS% %SERVER_CLASS% >"%WLS_REDIRECT_LOG%" 2>&1
変更後
%JAVA_HOME%\bin\java %JAVA_VM% %MEM_ARGS% -Dweblogic.Name=%SERVER_NAME% -Djava.security.policy=%WL_HOME%\server\lib\weblogic.policy %JAVA_OPTIONS% -verbose:gc -Xverbosetimestamp %PROXY_SETTINGS% %SERVER_CLASS% >"%WLS_REDIRECT_LOG%" 2>&1
参考にしたのは
JRockitをもう少し勉強しないとね。
とくにログファイル出力が出来るようにしないと使いものにならないかも。