泥沼プロジェクト振り返り
はじめに ちょっと前まで結構激しく泥沼化したプロジェクトにいた。 その頃はプロジェクトも僕も相当疲弊していて、何も考える時間がなかった。 ある程度、月日が経って今なら もう少し客観的にあの頃のことが考えられるかなと思い書いてみることにする。 振り返りをし、自分としてもプロジェクトとしてもどうあるべきであったかとか そういう立派なことが考えられればいいのだが。 とかく、Slide Shareとか世の中は成功事例は多く発信される。 けど、失敗事例のほうが共通して当てはまったりする。 前提 ・古典的なウォータフォール ・古典的なStruts1系ベース内製フレームワーク ・Java SE 6 ・QAとかいない ・デザイナーとかいない ・フロントエンドエンジニアとかいない アンチパターン 当時のプロジェクトを振り返って、明らかにこれは駄目だっただろというところ。 ◆プロジェクト全体 ・決定者がいない
開発者の生産性：Noと言える技術 | POSTD
生産性を維持するのは難しいことです。 特に開発者の立場では。 ゾーン（超集中状態）に入るには時間がかかりますが、入ったゾーンから引きずり出されるのは簡単です。 例えば、 * ミーティング * Eメール * 作る予定の機能や、修正すべきバグ などに意識が分散されてしまいます。確認しておかないと、気付いたら何もする時間がなくなっています。 これを解決するための秘策があります： あらゆることに” no “と言うのです。 私たちのやり方をお教えしましょう。 ミーティングは木曜日だけ ミーティングは生産性を奪います。私たちは経験から、いつもミーティングの前後に45分の時間が消えてしまうことに気付きました。さらに、Skypeでのたわいないおしゃべりでも15分間が失われます。 45分後にミーティングがあると思うと、重要なことは始められません。同じように、電話やミーティングが終わってから、即座に大きな問題
若手開発者の後悔 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
とある科学の龍退治伝説
大西科学 @onisci プログラムのミスのことを「バグ」などと呼ぶから、「つぶす」ものに思えるしバグ退治にいまいち意気が上がらないので、あれを「ドラゴン」とか呼ぶことにしていれば、ドラゴン退治に熱が入るしミスの修正者がドラゴンスレイヤーとして顕彰される感じになってよかったのではないでしょうか。 2015-03-17 17:18:43 尾野（しっぽ） @tail_y 確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました！」「Aクラスのドラゴンを相手にしてる最中だってのに！」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い 2015-03-18 10:24:55
最近のJavaScriptフレームワークの評価とか - albatrosary's blog
最近JavaScriptフレームワークについて色々指標のようなものを提示するブログが流行っているようだ。適材適所のもと、これは大規模向きとか小規模向きとか早いだの遅いだの。加え「gitなんか覚えなくたって死なない」とか、UXうえい！みたいな話だと思いきや内容がUIに限ったこととか。 一体最近のフロントエンドはどうなってるんだ？という雰囲気になってきましたので、少しメモ的に書きました。 JavaScriptフレームワークについて JavaScriptフレームワークの状況を見ると（フレームワークかライブラリかの議論は置いておき） DOM Web Components Virtual DOM に分かれます。JavaScriptフレームワーク初期の頃はDOMを直接操作するものが多く出現してきましたが、レスポンスなど扱いに難しい面もあり、他のアプローチが考案されました。それがWeb Compoent
メソッド名を考えるときに気をつけること - 亀岡的プログラマ日記
大学時代に、プログラミングだけでAO入試で入ってきて、部活に熱中しすぎて一年留年して、成績優良で某幸之助じいちゃんの会社に行った奴がいましてね。そいつにずっと言われてたのが プログラムは自然言語としてよめるべき。コメントはいらないよ。 という話で、そのときは「いやいやwww」と思ってたけれど、最近の僕の思考は、もう「自然言語として読めるか」に尽きるようになってきた。 んで、こんな話。 @ngsw_taro @yy_yank @soudai1025 なるほどー。。。booleanなメソッドなのに、is～ではないことがわりと違和感ですが。。。そうでもないんでしょうか。。。— しょぼちむ@物理 (@syobochim) 2015, 3月 16 booleanはIshogehogeなのか？ そうであることは多いですよね。でも、例外も非常に多いです たとえば、 Enumerable.Contains
偉大なコーダーが推奨する技術書まとめ - Qiita
Javascriptの生みの親であるブレンダン・アイク，memcachedの作者ブラッド・フィッツパトリック，Haskellの設計者であるサイモン・ペイトン・ジョーンズ，Googleの研究本部長であるピーター・ノーヴィグなど多くのコーダーがドナルド・クヌースの『The Art of Computer Programming』(TAOCP)を読むべき本として紹介しました。 ケン・トンプソンのおすすめ本はシンタックスとセマンティクスだけを提示する本ということですが，「言語仕様」のことでしょうか・・・。 The Art of Computer Programming クヌースは自身のTAOCPについてこう述べています。 私の本のどの5ページを取っても誰かの一生涯分の研究になっている 要は「簡単には読めないぜ」と。 実際に上記の偉大なコーダーたちでさえもTAOCPについては興味のある部分のみを読ん
C言語の開発者によるgoto文の使い方を対象とした実証研究の結果、「goto文は無害だと考えられる」 | スラド デベロッパー
Edsger Dijkstra氏がgoto文の危険性を主張したのは1968年。それから50年近く経過した現在もgoto文は使われ続けているが、Dijkstra氏が懸念したようなgoto文の無制限な使用が行われているのかどうかという点や、それがバグの原因となるような有害なものなのかどうかといった点については、よくわかっていなかったという。こういった点に関する実証研究が本家/.で紹介されている。 本家/.「Empirical Study On How C Devs Use Goto In Practice Says "Not Harmful"」より 200万近いC言語のファイルと1万1千件を超えるプロジェクトからランダムに抽出した統計的に有効なサンプルを質的および量的に分析したところ、開発者はほとんどの場合gotoの使用を適切に制限しており、Dijkstra氏が懸念したような無制限な使用は行わ
CodeIQについてのお知らせ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
「セキュリティ対策」
「不正な入力に対して脆弱性を発生させないようセキュリティ対策としてバリデーションを行う」。アホか。プログラマならセキュリティ対策とか気にするな。いや、気にするなというのは言い過ぎだけれど、ほとんどの場合においてあなたの書くコードはセキュリティ対策の必要性はない。 攻撃者の細工した入力によってSQL/HTML/JavaScriptが壊れるとかバッファオーバーフローが発生するとか、そういった脆弱性と呼ばれるほとんどのものはただのバグだ。セキュリティ対策っていうのはコードとは切り離された領域で行うDEPだったりASLRだったりX-Frame-OptionsだったりCSPだったりiframe sandboxだったり、そういうものがセキュリティ対策だ。コード上で書くのは「アプリケーションとして正しく動作するための処理」だけだ。 もちろん例外もあるかもしれないけど、それはあくまでも例外だ。日常的に書く
プログラミングフォントの決定版「Ricty Diminished」 : 作々！ -さくさく-
作々！ -さくさく- ゲーム制作、アニメ制作、グラフィックソフト、プログラミング、3DCG等、創作活動の話題全般を取り扱う(予定)。 プログラミングに最適なフォントとしてよくおすすめされるRictyが再配布可能な形で公開されていた プログラマーにとってフォントは生産性に影響する重要なポイントの１つです。lとIが区別のつかないフォント、oと0が区別のつかないフォント。残念なことにデフォルトで使われるフォントはWindows,Linux共にそういったものが多いです。もしまだデフォルトのフォントを使っている人がいたらこの機会に是非Rictyに乗り換えましょう！ プログラミングに最適なフォントとしてよくおすすめされるRictyが再配布可能な形で公開されていた | デジタネイティブ 今までのRictyとどう違うか Rictyは日本語フォントにMigu 1Mを使用していたために、フォントが統合された
プロのプログラマーになるために本当に必要なスキルとは | ライフハッカー・ジャパン
プロのプログラマーになりたいなら、コードを書けるだけでは足りません。チームでの問題解決やバージョン管理など、コーディング以外にも身につけるべき重要なスキルがいくつもあります。今回は、米Lifehacker読者のみなさまの声をもとに、プロの開発者として必要不可欠なスキルとは何かを見ていきます。 コードを学ぶための情報は世の中に溢れています。そのせいか、プログラミング言語さえ習得すれば、プロの開発者になれると思い込む人がたくさんいます。しかし、他の職業と同じく、優れたプロフェッショナルになるには、たった1つのスキルで足りるはずがありません。開発者に必要なスキルをここですべて列挙することはできませんが、以下に、本当に重要なスキルをいくつか紹介しておきます。 コミュニケーションを学ぶ プログラマーは孤高の職人である、と喧伝するメディアもありますが、実際は、他者とのコミュニケーションや共同作業が欠か
就活生がITエンジニア/プログラマを目指す前に伝えておきたい業界の真実と現役エンジニアからのアドバイス - こんにゃくマガジン
はじめに 日本のIT業界では、技術職求人に対して、ちゃんと専門教育を受けていない（独学で身につけたわけでもない）人の応募の割合がとても高く、絶大なる不幸を生み出しているのが現状です。 これから社会人になる就活生の皆さんには、できれば不幸な人生ではなく幸せな人生を歩める選択をしてほしいとの願いから、このエントリーを書きました。 注意：ITエンジニアとして就活をしてプログラマー的な仕事が主な業務になる人が多いと思うので、この記事に出てくるITエンジニアという言葉は、プログラマーのことだと思って読んでいただけると幸いです。広い括りの題名をつけてしまってすみませんが、インフラ/ネットワークエンジニアやメーカーのエンジニアの話は出てきませんので、ご容赦ください。 目次 背景 プログラミング言語を覚えよう データベースの使い方を覚えよう オリジナル作品を作ろう（ここが一番大事） IT系の勉強会に参加し
コードを削除したら喜ぶべき。知らない人がみたら意味不明なコードが残っていませんか？
昔はよくわかっていなくて、今は身にしみてよくわかっていることの一つは、追加した行数がマイナスのパッチは素晴らしいということだ。コードは削除できるなら消したいし、自分の書いたコードであれ、誰かが消してくれたらとてもよいことだと思う。 昔はがんばって書いたコードはなるべく「活用」したいと思っていた。活用というのはつまり、捨てるのはなんとなくもったいないから、そのコードをなるべく消さずにすませたいということだ。 しかし無理にコードを生かしておくことの意味など何もない。 コードの履歴などは全部いったん置いておいて、ある時点のソースコードを初めて見たものとしよう。そのソースコードが、そのプログラムが実装するべき機能を実装するために十分かつ最小限のコードであるのと、十分かつ最小限のコードに加えて何かよくわからないコードのどちらかであるとしたら、どちらのほうがいいコードだと思うだろうか？ 前者のほうがい
このコンピュータ書がすごい！2015のランキングと参加レポート（長文）（動画追記あり）
2015年1月10日にジュンク堂池袋店で開催された「このコンピュータ書がすごい！2015新春座談会 －2014年に出たコンピュータ書ならこれを読め！－」に行ってきましたのでレポートをつらつらと書いていきますね。 最初に言っておきますが、怖ろしい文量というか、紹介書籍量なので時間のあるときにでもゆっくり読んでもらうことをお薦めします。 このイベントは、日本Rubyの会代表でありプレゼンの高橋メソッドでお馴染みの高橋征義さんのマシンガントークでコンピュータ関連書籍をひたすら紹介するというもの。19時30分にスタートして、終了したのは21時45分。ジュンク堂の担当者さんが「時間、超ヤバイ！！」という泣きカンペを出すぐらい、濃密なイベントでした。 【追記】技術評論社さんの公式チャネルに動画が上がってました。 2014年すごいコンピュータ書総合ランキング 1位 リーダブルコード 2位 インフラ／ネッ
任天堂・岩田社長は40歳までコードを書いていた | スラド デベロッパー
「プログラマ35歳限界説」という俗説があるが、実際のところ30代も半ばになると、マネジメント業務が増えて実際にコードに触れなくなるプログラマも少なくない。しかし、任天堂の岩田社長は、40歳、任天堂の経営企画室長時代まで実際にコードを触る業務に関わっていたという（4Gamer）。 岩田氏はマネージメント業務に関わるようになってもしばらくは夜や休日にコードを書き、社内で見せていたという。また、岩田氏が最後に関わったのは、ゲームキューブ版の「スマッシュブラザーズ」だそうで、開発が停滞し「このままだと発売日に間に合わない」という状況になったため、開発元である山梨のHAL研究所に赴いてコードレビューやバグ修正、バグの担当者割り当てと行った作業をやっていたそうだ。 岩田氏が社長になったのは2002年、42歳のときなので、その2年前まで実際にコードを触ることができていたというのは興味深い。さすがに現在は
そのオブジェクト指向入門は間違っている（大げさ） - Webアプリエンジニア養成読本 AdventCalendar2014 25日目最終日！ - uzullaがブログ
はい、Webアプリエンジニア養成読本 AdventCalendar2014です。突然トリをやる事になってしまったので、どうしたもんかとおもいます…。 「最終日だぞ…ちゃんとかかないといけない…しかしネタはない…そうだリンク集を作ろう！」とか思ったんですが、そもそもアドベントカレンダーってリンク集だよねって気付いて愕然としているクリスマスの夜です。現在朝の4時、これを書き終えて寝たい。 さて…何を話そう ここまでWebアプリエンジニア養成読本アドベントカレンダーということで続けてきました。そして今日は25日、ついに最終日です！ Webアプリエンジニア養成読本 Advent Calendar 2014 - Qiita Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus) 作者:和田 裕介,石田 絢一 (uz
ヨーダ記法を応援します - がるの健忘録
軽く各方面とバトりそうなネタなれど。 まず。 ヨーダ記法(ないしNTT記法…って、うちのまわりではいってたんだけど、ググるとあんまりでてこない)ですが。 これは「if等の比較演算において、左辺に定数、右辺に変数を置く」記法です。 とりあえず幾つかネットで拾ってみる。 http://uchidak.net/yoda-notation このようにヨーダ記法とは、予期しない代入を防ぐために産み出された安全側へ倒すための書き方です。 しかしながら、現在はコンパイラがよしなにしてくれるため、あえてヨーダ記法で可読性を失うような書き方をすることをリーダブルコードでは推奨していませんでした。 http://qiita.com/moriturus/items/723eb17873381f94baf8 確かに、ヨーダ記法(1 == hogeのように記述する)は、発見しづらいミスを防ぐのに有用かもしれないが、
音楽分析とプログラムと教育
kazutomi @kazutomi @sinx_music あ、プログラムの分析を教えないってことないですよ。OSのコードを読んだりする授業は多分一般的です。教え方が体系的かというとそうではないかも知れませんが。 2009-12-16 23:03:30 ⛸Akihiko Matsumoto/松本昭彦🛼 @akihiko_japan 例えば音楽だと様々な分析法が確立していて、効率的に音楽の意味を理解できるのですが、プログラムには分析理論やメソッドなんかはあるのでしょうか。RT @kazutomi: OSのコードを読んだりする授業は多分一般的です。教え方が体系的かというとそうではないかも知れませんが。 2009-12-16 23:10:17
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CEDEC2014 「ライブラリを作ってはいけない ～それでも作りたいあなたへのアドバイス～」
