チケット管理のアンチパターンとベストプラクティス
主語がでかいタイトルですが、自分なりに考えようという目的です。 自分の思考の整理。 何か意見があればガンガンコメントなりツイートなりして欲しい。 前提として、 チケット管理システムは２つぐらいしか使ったことがないので、そちらに偏ってしまうかも。 ちなみにRedmineとBacklog。 （今がRedmineだから多分それに偏る気が） アンチパターン アンチパターンというのかは分からないけど 今まで困ったこと、やりにくいと感じたこと、ダメだこりゃ、と思ったこと。 ・運用フローが複雑 フローが複雑だと途端に人は面倒になる。なるべく抜け道を探し秩序が乱れる。 抜け道が見つかると割れ窓理論とかいうやつで、どんどんぐちゃぐちゃになる。 誰もフローに乗ってくれない状態になる。 ・使われていない項目がある なぜあるのかわからない項目。重要そうだけど埋めなくても良い項目。 誰かが埋めてくれるだろう、他の人
【JavaBeans】BeanとDTOとEntityとVOとFormの違いって何？- Javaプログラマーのはしくれダイアリー
色んなシステムに携わっていると、様々なJavaのクラス名に遭遇する。 ○○Beanとか ○○DTOとか ○○Entityとか ○○VOとか ○○Form。 ここらへんって 「MVCのModelのデータ部分にあたるって意味で同じだし」 とか 「ゲッター/セッターがあるクラスで意味的に一緒じゃない？なんで色々名前つけてんの？」 って思いませんか？ ってことで、今回はそれぞれの定義を改めて考えてみようと思う。 とりあえずはそれぞれの意味から ・Bean 総称はBean。あえて言うならJavaBeansの略。 Javaの初心者でも知っている。 あまりに有名すぎるが、Oracleのサイトのガイドを見ながらパクってまとめてみた。 ・Sun Microsystems社のJavaBeans仕様に準拠した再使用可能なソフトウェア・コンポーネント。 ・最低限、クラスにはプロパティが必要。 ・プロパティはメソッ
JavaのREPL、project kullaがスッゴイ便利！
※注意 本記事は2015/06/12現在のproject kullaに関する情報です。 今後のJava SE 9のリリースやproject kullaの開発状況によっては内容が変わる可能性もありますのでご了承ください。 はじめに Java SE 9ではJavaにREPLが入る予定となっています。 その名もproject kulla！！ とある記事を読み、リリース前ですが今でも使えることを知りました。 これは使ってみたい！ということでトライしてみました。 そもそもREPLとは REPLとは Read-eval-print loopの略 字のごとく読んで評価して表示して繰り返す。対話型評価環境を指す。ただし、インタープリタと同義ではない。 多くの関数型言語やスクリプト言語では利用出来る。 （http://d.hatena.ne.jp/keyword/REPLより引用） REPLについては以前に
現場ロックインが技術力さげてるのかもしれない - Javaプログラマのはしくれダイアリー
はじめに 技術を学ぶというのはすごい個人差のあることだと思います。 個人特性もあるし、興味の向く対象も違う。 組織にはいろんな人間がいる。 そんな中、いくら「技術力を学ぼう！」と啓蒙しても、 響かないことってありませんか。 最終的には人それぞれの問題にはなってくるのだけれど、 それって、現場ロックインが一因なのではないかなと思う。 現場ロックインの定義 「特定ベンダー（メーカー）の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象」をベンダーロックインという。 (Wikipediaより引用) 現場ロックインは僕の思いついた単なる造語で、 「特定のプロジェクトに特化した技術や顧客の事情を重視しており、 その他の現場に移動しても殆ど役に立たないローカルルールに依存している現象」を指す。 会社に対して
泥沼プロジェクト振り返り
はじめに ちょっと前まで結構激しく泥沼化したプロジェクトにいた。 その頃はプロジェクトも僕も相当疲弊していて、何も考える時間がなかった。 ある程度、月日が経って今なら もう少し客観的にあの頃のことが考えられるかなと思い書いてみることにする。 振り返りをし、自分としてもプロジェクトとしてもどうあるべきであったかとか そういう立派なことが考えられればいいのだが。 とかく、Slide Shareとか世の中は成功事例は多く発信される。 けど、失敗事例のほうが共通して当てはまったりする。 前提 ・古典的なウォータフォール ・古典的なStruts1系ベース内製フレームワーク ・Java SE 6 ・QAとかいない ・デザイナーとかいない ・フロントエンドエンジニアとかいない アンチパターン 当時のプロジェクトを振り返って、明らかにこれは駄目だっただろというところ。 ◆プロジェクト全体 ・決定者がいない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
