技術的負債とどうやって戦うか - Qiita
プロジェクトが進行するにつれて増える『負債』 長いプロジェクトに携わっていると、技術的負債をいつ返すのかが課題になってきます。 リファクタリングはいつの時点でやるのか、これは長いプロジェクトを運用していく上で問題になっていきますが、今回は負債の種類を整理し、それぞれどう対応をしていけばよいかを考えていきたいと思います。 私達の開発では常に時間が足りない 最近読んだ、「アジャイルサムライ」という本には下記のようなことが書いてありました。 (開発における)3つの真実 プロジェクト開始時点にすべての要求をあつめることは出来ない 集めたところで要求はどれも必ずと言っていいほど変わる やるべきことはいつだって与えられた時間と資金よりも多い 以上のことからわかるように、私達の開発には時間が無いということが常だということがわかります。実際、技術的負債が多いプロジェクトほどこの傾向が強いのではないでしょう
エラーメッセージは 2W1H がいいんじゃないか
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
読みやすいREADMEを書く | Yakst
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
エンジニアのハマり時間とその技術的難易度の相関関係 - Qiita
めちゃくちゃにハマったからと言って、その問題は技術的難易度が高い訳ではないんじゃね？という話。 ここで言う「ハマる」とはなにかに夢中になって没頭することではない。バグとかエラーがあって、なかなか解決できなくてそのために時間を割かれてハマる、の「ハマる」。 先日、ハマった問題が解決した時の感情は「ついに解決したぞ」という安堵感と「しょーもないハマりポイント作りやがって、あのボケが！」という前任者への怒りが混ざった状態だった。 サイトのSSLの有効期限切れが２週間後にせまっていた。やる事は証明書の更新、新しい証明書をAWSのELBに入れること。ただこれだけ。しかしハマった。どうやってもELBから「あなたのキーは無効です」みたいなエラーメッセージが返ってきた。２年前にSSLを設定したエンジニアは退職してしまって、もう居ない。その前任者とほぼ同じことをすればOkなはずなのに、なぜかできなかった。
【事前公開】【第7回redmine.tokyo勉強会】RedmineのFAQとアンチパターン集～WBS駆動からチケット駆動へ #redmineT - プログラマの思索
【事前公開】【第7回redmine.tokyo勉強会】RedmineのFAQとアンチパターン集～WBS駆動からチケット駆動へ #redmineT 第7回redmine.tokyo勉強会で予定している講演資料を事前に公開します。 勉強会のオープンディスカッションの元ネタになるので、参加される方は事前に読んで頂いて、自分なりの意見を持参してくれると嬉しいです。 【元ネタ】 第7回勉強会 - redmine.tokyo 第7回redmine.tokyo勉強会 - PARTAKE 【1】議題にしたいテーマ 第7回redmine.tokyo勉強会のテーマは「Redmineのアンチパターン集」です。 披露するアンチパターンは、私が過去6年、Redmineをいろんな現場で導入して運用した時、こうやればもっとうまくできたのに、と後で気づいたノウハウです。 おそらく他の人も同じように頷いてくれるアンチパター
独学でプログラミングを勉強しても実務に通用しにくい理由 - 25歳ニートが35万円で上京を企むブログ
独学でプログラミングを勉強してIT業界に就職したけど、やはり独学で得た技術だけだと通用しないと思う局面が幾たびもあった。 今は本はたくさん出てるし、動画もあるし、生のコードを読みたければGitでいくらでも読めるし、独学で勉強する土台はかなりできていると思う。 それでもなかなか実務に通用しない。 その理由はいろいろあるんだけど、自分が強く感じた３つの理由をこの記事では挙げたい。 １．独学では妥協をいくらでもできる 独学で作っているプログラムだと、使い勝手が悪い機能を見つけたとしても「ま、ええか」で済ませてられてしまう。 誰に命令されて作っているわけでもないから。極端な話、バグがあっても放置できる。「小さいバグだしいいでしょ」と。実務でそれをやったら殺される。 「ま、めんどくさそうだしこれでええか」で済ませてしまうと、めんどくさい実装をすることで得られる技術の向上がなくなる。 実際、現場だと仕
未来では全てのプログラミング言語が1つになる？
何だか名前が無駄にかっこいいんですが…。 HTML5やJavaScript、PHPにCSS、XMLなどなど…挙げだせばキリが無いプログラミング言語。分野ごとに違ったものがスタンダードをとっている為、プログラマーは複数の言語を学ばなければならないケースが多いです。そんな問題を解決するため、アメリカ国家安全保障局(NSA)がカーネギーメロン大学に出資して、1つの統一言語を作るプロジェクトを進めているんだそう。 伝説上のドラゴンの名前を取って、その名も｢Wyvern｣(ワイバーン)と名付けられたこのプロラミング言語は、アプリケーションやウェブサイト作りにおいて複数の言語が入り乱れている状況を改善するべく、開発が進められているんだとか。 開発者は以下のように語っています。 今日のウェブ・アプリケーションは全く統一性のない複数の言語で書かれており、ごちゃまぜ状態です。例えば、1つのウェブ・アプリケー
単体テスト（画面単位のテスト）がクソらしいので思ったことを書いてみる - うさぎ組
なんか2週間くらいずっと画面単位のテストを単体テストと呼んで、手動テストをする現場についていろいろ文句がSNSで流れていた。それについて思うことをバカスカ書く。 これは、誰かを批難したいわけでもなく、ただの感想である。言うなれば街の風景をみたときの日記だ。そうだよ。これは日記だよ？ 要約 だいたいの話は僕が2,3年前にTwitterで言いまくった単体テスト/結合テストなんて存在しない - Togetterまとめに似ていると思ったけど、僕の狭い観測範囲では生産的な結論を迎えずに文句の固まりで終わって、こう非常にあーあっていう気持ちが残った。 あと、観測結果として 同僚や上司に加えてkyon_mmに「なぜその手法でテストをしたいの？ねぇ？なんで？」って聞かれても答えられるか。が相手を評価する目安だと僕自身が自覚した。 というのが大きかった。 単体テスト まず、最初に思ったのはTwitterで文
フルスタックエンジニア講座 http://fullstack-engineer.com/ の集金口座っぷり - いろいろやってみるにっき
出遅れた感ｗ(挨拶)。 フルスタックなスキルを身につける即戦力エンジニア養成講座「フルスタックエンジニア」 最初見掛けたときは暇つぶしにiPhone5cを見てた電車内だった。トップページでフルスタックさが伝わってこなかったので、[ネタ]タグだけでブックマークして忘れてたｗ。 今までフルスタック話は極力スルーしてきたのだが、こういうネタには参加しておきたいｗ。スルーの理由は、フルスタックエンジニアって結局これといった定義も無いバズワードなんで、色々文句や突っ込みは入れやすいけど、だからどう？っていう話。 以降の話は「フルスタックエンジニア」なる技術者を求めるプロジェクトは、ベンチャーなどのコンシューマ向けサービス構築プロジェクトだと仮定する。少数精鋭の。 B2Bはちょっとプロジェクトの組成も金の出方も違う気がするし、B2Cでも金融機関などのプロジェクトではSIer仕切りで人がわさわさいるから
37signalsの創設者が語る「求職者が見せるべき資質」 | ライフハッカー・ジャパン
Inc.：筆者のジェイソン・フリード氏は、プロジェクト管理ツール『Basecamp』などで有名なソフトウェア開発企業「37signals」の共同創設者です。また、同社の成功について記した『小さなチーム、大きな仕事』の著者でもあります。今回はそのフリード氏に、同社の採用において重視する資質についてお聞きしました。 スキル以前に重視する資質 37signalsでは、1つの採用枠に優秀な候補者がたくさん集まります。 最近、37signalsでは、『Basecamp』のプロダクトデザイナーを1名募集しました。プロダクトデザイナーとは、プロジェクトのビジュアルデザインを統括するポジションです。また、チームの方向性をまとめる役割もあります。37signalsはあまり頻繁に採用を行いません。採用は、候補者と私たちにとって貴重な出会いの機会です。 私は、プロダクトデザイナーの候補者を選ぶとき、基本的なデザ
開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例 - 達人プログラマーを目指して
まったく個人的なモチベーションの問題から、前回の最終更新から2年以上が経過してしまい、多くの読者のみなさんにはご心配をおかけいたしました。「プログラミングに関して調べたことや日々感じたことをメモとして残していきたいと思います。」というもともとの原点に立ち返って、あまり気負わずに、また今後も時々更新していけたらと思います。今までこのブログの主なテーマとして、JavaEEやSpringといったような、いわゆる業務開発で使われるような技術を中心としてきたわけですが、最近Springを使ったJavaの開発に（アーキテクトではなく）プログラマーとしてちょっと参加する機会があったので、その時気づいたこと、感じたことを書いてみたいと思います。 さて、皆さんはアーキテクチャやアーキテクトという言葉に対してはどのようなものをイメージするでしょうか。システムのセキュリティを確保するための方式であったり、大量の
管理職って本当に必要？全社員がフラットな会社を運営するCEOにインタビュー | ライフハッカー・ジャパン
米Treehouse社の株主総会で、1人と投資家が同社CEOに質問しました。「社内では誰が誰に報告することになっていますか？」 「思わず笑ってしまいました」Treehouseの共同創業者のカーソン氏は言います。「誰も仕事の報告はしないんです」Treehouseの投資家は同社のこのような「職場環境の実験」に慣れっ子です。さまざまなプログラミング言語を学べるオンライン学習プラットフォームを提供するTreehouse社は、従来の形式に捉われない新しい仕事環境を採用しています。多くの業務は遠隔勤務が可能で、週4日間の労働時間などです。最近では組織体制を完全にフラットにし、すべての中間管理職を撤廃しました。 トップダウンによる意思決定方法を採用するのではなく、社員から提案のあったプロジェクトを共同作業ソフトウェアを使いながら進めています。社員は進めたいプロジェクトを提案し、十分な人数のメンバーが参加
リファクタリング―プログラムの体質改善テクニック読んだ - 銀の人のメモ帳
リファクタリング―プログラムの体質改善テクニック (Object Technology Series) 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史出版社/メーカー: ピアソンエデュケーション発売日: 2000/05メディア: 単行本購入: 94人 クリック: 3,091回この商品を含むブログ (307件) を見る 残念ながらピアソン桐原から出版されていたので、現在は手に入りにくいんだけど、読んだ。 内容的には、リファクタリング手法のカタログみたいな感じだと思う。５章くらいまでは、導入とか、リファクタリングの心構えみたいな事が書いてある。 リファクタリングをするときに「いつすべきか？」というのが問題になると思うんだけど、この本では、機能を実装するときにその周辺をリファクタリングするといいと書いてあった。これは「動いてるものは触るな」っていう考
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
がんばるあなたがプロジェクトを殺す - haradakiro's blog
あまりに暑いのでちょっと怪談を。 今のような仕事のやり方をする前、いわゆるシステムインテグレータに所属していた。まあ、呼び方はいろいろあるのだろうけれど、一番長いこと仕事にしていたのは、いわゆる「火消し」。問題プロジェクトにがあると、プロジェクトに投入されるという役どころだ。まあ投げ込まれるのは大変だけれど、いろいろなものを見ることができた。 投入されたプロジェクトは多種多様だけれど、たいていの場合、すぐに問題があるようには見えない。みんな忙しそうに働いているし、大きな開発プロセスの問題もない。粛々と作業がすすんでいるように見える。でも、クライアントと管理職は怒っている。怒っているから、いろいろな作業が追加されて、メンバーはどんどん忙しくなる。 しばらく見ていると、プロジェクトには必ずある種類の人がいることに気がつく。みんなに頼りにされていて、なにかあると彼(彼女の場合もあるよ、もちろん)
Jenkins がもっと便利になるおすすめプラグイン 8 つ
こんにちは、開発担当の松本です。 今回は、Jenkins にたくさんあるプラグインの中からおすすめのプラグインをいくつか紹介します。 ジョブ一覧にアイコンを追加できる: Custom Job Icon 今年8月にリリースされた比較的新しいプラグイン。名前の通りプロジェクトごとにアイコンを登録できて、それがプロジェクト一覧に表示されるようにできます。 利用するには、プラグインインストール後にアイコンを登録する必要があります。 「Jenkins の管理」→「システムの設定」ページに「Custom icons」セクションが追加されていますので、そこでファイルを追加しておきます。追加しても「Refresh icon list」をクリックしないと表示が更新されない点に注意。 なお、画像の拡大縮小あまりきれいに行われないので、アイコンのサイズは 24 x 24 にしておくのがよいみたいです。 アイコン
レガシーPHPプロジェクトあるある - komagataのブログ
プロジェクト名に愛が無い そしてリポジトリ名がncrm（多分New CRMの略）。だったら更に新しいの出たら何になるのか。nncrmか？nnncrm、n5crmとかschemeの仕様みたいになっていくのかと小一時間（略 テストが無い テストぉ？そんなお上品なもんなんざぁ、とんとお目にかかったことねーなぁ？ バリデーションが無い バリデーション？そんなお上品なもんなんざぁ（略 サーバーがrootログインの許可＋IP制限している セキュリティを高めたいのか低めたいのかどっちなのか。使い辛いわ。 バージョン管理システムがよくわかってない なぜトップにぶち撒けられてる？trunkはどこ？branchesとtagsはなぜ空？ メソッドが大文字から始まる あんた絶対Windows畑から来たね？同じ調子でPHP書かれても困るんだヨォ。 全テーブルに共通のプレフィックスが付いている いや、データベース名が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CEDEC2014 「ライブラリを作ってはいけない ～それでも作りたいあなたへのアドバイス～」
Private Site
IDEA * IDEA
