技術的負い目の記事がすごい - プログラマの思索
技術的負い目の記事がすごいのでリンクしておく。 【元ネタ】 16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ たくさんの負のレガシーがあり、しかも本番稼動中であり、バックアップ容量も多い。 そう簡単にリファクタリングしにくい。 そんな中で色んな対応をされている。 以下、自分が今後参考にしたいためにメモ。 【1】JDKが古い。 古いJDKはセキュリティホールもあるだろうから危険。 性能要件も低いだろう。 →JDK6からJDK8へバージョンアップ。 Gradleでビルド環境を作る。 ライブラリの依存関係はMavenリポジトリから探し、Gradleで依存関係管理させる、と。 【2】コード重複率も多く、デッドプログラムも多い。 長年運用したシステムは、デッドプログラムが多い。 でも、リスクがあるから、デッドプログラムをうかつに消去で
RedmineでGTD - プログラマの思索
RedmineでGTDされている記事を見つけたのでメモ。 【元ネタ】 RedmineはGTDにもピッタシだった | Azrael GTDを使ってみたらストレスがマッハで軽減した | Azrael GTDとチケット管理が似ている: プログラマの思索 チケット駆動開発にGTDの概念を導入する: プログラマの思索 企画や営業に携わる人は、日々のTODOリストがとても重要だ。 その日にやるべき作業を分刻みで次々に処理していかざるを得ない。 その時に、GTDのような考え方があると、タスクに押しつぶされるようなプレッシャーやストレスから逃れることができると思う。 GTDの良さは、Inboxというバックログのような概念があること、日次レビューや週次レビューのように定期的に検査するイベントを作ってフィードバックする仕組みがあることだと思う。 つまり、GTDはタスク管理のアジャイル版に思える。 そのやり方を
組織や管理職が技術革新のボトルネック - プログラマの思索
とあるBlogを読んでみて、組織や管理職が技術革新のボトルネックではないか、と思った。 ラフな感想。 【元ネタ】 継続インテグレーションは強みではなくなった：柴田 芳樹 (Yoshiki Shibata)：So-netブログ 継続インテグレーションは強みではなくなった（2）：柴田 芳樹 (Yoshiki Shibata)：So-netブログ カンファレンスは、若い人ばかり？（2）：柴田 芳樹 (Yoshiki Shibata)：So-netブログ (引用開始) 私自身が日頃から感じていて、Jenkinsユーザ・カンファレンスの参加者による質問を聞いて再認識したことは、JenkinsなどのCIツールの導入を阻害しているは、現場のエンジニアではなく、ソフトウェア開発組織の管理職でないかということです。つまり、管理職がCIツールの導入の検討を指示して、予算（工数、機材費）を認めてくれればスムーズ
業務ロジックをデータモデリングはどこまで表現できるか？ - プログラマの思索
「業務ロジックをデータモデリングはどこまで表現できるか？」について考えたことをラフなメモ書き。 業務システムでは、データが命。 データには個人情報が含まれるために管理が重要だったり、売上データやPVデータから、どの層の顧客から売上やアクセスが多いのか、を計測することもできる。 すると、それらデータを格納するRDBが必要になり、そのテーブル設計が重要になってくる。 顧客の業務プロセスをモデリングする場合、最近ならOOAが主流。 でも、DOAの方が現代は重要性を増していると考えている。 例えば、Railsのような優れたWebフレームワークがあれば、ER図さえきちんと作れば、DBマイグレーションとプログラム雛形を自動生成することによって、テーブルのCRUDのような画面はすぐに作れてしまうからだ。 日本におけるデータモデリングの歴史は意外に古い。 TH法、T字型ER、渡辺さんのXEAD Model
アジャイル開発を推し進めると組織を動かす政治力が必要になってくる - プログラマの思索
最近、いろんな記事を読みながら、アジャイル開発を推し進めると、アジャイルだけでは解決できない問題がどうしても残り、その問題を解決するには政治力が必要になってくるような気がしてきた。 ラフなメモ書き。 【1】アジャイルの「ライトウィング」と「レフトウィング」：An Agile Way：ITmedia オルタナティブ・ブログ 多分、チケット駆動開発は右寄りのツール寄り。 プログラマ出身で、プログラムにこだわりがある人は右寄りだろう。 逆に、プログラミングから離れて、マネジメント職に就き始めれば、自然に左寄りになる。 プロジェクトリーダーにもなれば、メンバーに的確な指示を出してチームを回す役割を周囲から期待されている。 100人月規模のプロジェクトになれば、プロジェクトマネージャとして、複数人のプロジェクトリーダーに的確な報告と指示を出しながら、プロジェクト全体をコントロールする役割を期待されて
スケジュールを見ればマネージャのレベルが分かる - プログラマの思索
@hatsanhatさんから「スケジュールを見ればマネージャがどこまでリスクを見通しているかが分かる」という指摘を聞いて考えたことをメモ。 【元ネタ】 Twitter / @akipii: Redmineによるチケット駆動開発を成功させるには全てのタスクを1人日以下まで分割しきれるかどうかが鍵。詳細レベルまで落とし込めれば作業手順もリリースサイクルもリスクもほとんど見通せているから。スケジュールを見ればPMがどこまでリスクを見通せているかすぐに分かる。 Twitter / @akipii: @dproject21 Redmineもチケット駆動開発も銀の弾丸じゃないんですよね。プログラミングやモデリングでシステム開発をどこまで解決できるか。アジャイル開発は作業を手抜きできると思う人がいるけど結局正攻法しかないんですよね。 【1】Redmineでチケット駆動開発を運用していると、チケットの粒度
ソフトウェア開発の工数見積もりが混乱しやすい理由 - プログラマの思索
工数見積もりしていると、同じ人月で数えているのに、コストだったり、システム規模だったり、出来高だったり意味が違っているのに気付いた。 考えたことをメモ。 間違っていたら後で直す。 【1】運用保守では、顧客に毎月の実績工数を報告して保守料金をもらう。 マネージャの仕事の一つが、月次報告のための工数集計がある。 だが、この工数集計が結構面倒だ。 普通はメンバーに毎日の日報で、どのタスクにどれだけの時間をかけたのか、報告してもらう。 しかし、普通はタスクは顧客の改善要望をWBSレベルで詳細化したタスクのため、まず要望別に集計し直さないといけない。 更に、顧客からの改善要望のステータスが未着手なのか、進行中・完了なのか、逐一記録して、追跡しないといけない。 また、それら要望は、問合せ調査だったり、定常的な運用作業だったり、障害対応や改善対応などの種類に分けて、それぞれで集計し直したい。 特に、本番
継続的インテグレーションを再考 - プログラマの思索
「継続的インテグレーション入門」を読んでみて、もっと早く読んでおけば良かったと後悔した。 内容がとても素晴らしかったので、理解できたことをラフなメモ書き。 【元ネタ】 Togetter - 「SIerは自動化する対象が違っているのでは？」 Continuous Deliveryをポチッた - watawata日記 Continuous Delivery - haru01のめも アジャイルなインフラのつくり方とデータマネジメント - メソッド屋の日記 インフラやデータ移行の自動化～アジャイル開発の最後の問題: プログラマの思索 Continuous Delivery～TDDとCIの次に現れた自動化の概念: プログラマの思索 【1】「はじめに」に、キーボードに「Integrate」というボタンが貼られていて「こんなに簡単ならいいのに」という雑誌の広告から始まる。 この挿話は、ビルド＆デプロイの
Redmineのワークフローを視覚化 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェア開発に特有な技術～ソフトウェア見積り - プログラマの思索