私の頭の中のソースコード
私の頭の中のソースコード 今いちばん興味があるのは頭の中にある設計図を できる限りそのままプログラムに書き出すことなんだよね。 多くの場合はプログラミング言語の書き方に引きずられて、 設計図がそのままプログラムにならない。 コンパイラでソースをアセンブリ言語に変換することができたりするので、 それを比喩に使うと、 真のソースは頭の中にしかなくて、 プログラム書いたよと言ってる「それ」は コンパイル済みのアセンブリコードであり、 読もうとすれば読めないこともないけど、 ソースじゃないよね、という感じです。 つってもこれって個人的な技能の域を出ない話なんだよなあ。 設計の技能、つまり頭の中にある設計図をよりよいものにする技能の方が、 よりプロダクトに貢献するだろうし。 いやもちろん、設計図がそのままソースコードになっていれば理解しやすいから、 メンテナンスコストが下がるとか、 重複コードを書か
プログラムの出来がわかるのは半年後
プログラムの出来がわかるのは半年後 「渋日記: きれいなソースコードを書けるようになるためには」を読んで連想したこと。 プログラムって書いたときには「わかりやすくて、きれいなソースコード書いたぞー」 って思ってるはずなんですね。 最初から出来が悪いと思ってるコードを本番環境にマージしたりはしないはず。 ところがですよ。 半年くらい経つと、新機能を追加しなければならなくなったりして、 このコードに手を入れることになるんですが、 このときに、はたして「わかりやすくて、きれいなソースコード」かというと、 そんなことなかったりするんですね。 そもそも何をやってる関数なんだ、これ？ どこに手を入れればいいんだろう？ 直すべき箇所はわかったけど、 ここを直すと関数名と処理が不整合になっちゃうよな。 直したはいいけど、既存の機能に悪影響を与えていないかな？ 短かった関数がどんどん長くなるよー 最初にプロ
ユニットテストを書こう
ユニットテストを書こう 自動テストなので一度書いておけば「めんどくさいからテスト省略」→省略したところに不具合あった、のコンボを阻止できる。 関数を大きくしすぎるとテストしにくくなるので、 適度なサイズに保つ働きがある。 クラスを大きくしすぎるとモックが使いにくくなるので、 適度なサイズに保つ働きがある。 新機能追加のときにエンバグする可能性が減る。 新機能追加のときに、最初にテストの方に手を入れれば、 コードのどこを直せばいいかすぐわかる。 デバッグのとき、バグが再現するようなテストを書いておけば、 直ったと自信を持って言える。 テストしやすくしようとすると、自然に疎結合になる (cf. 疎結合: ソフトウェアの依存関係を緩和してアプリケーションの柔軟性を高める)。 クラスや関数について、 通常の使い方とテストでの使い方の2種類を最初から用意するわけなので、 以降の拡張で3種類、4種類と
ToDo管理と記録のしかた
ToDo管理と記録のしかた たまにはライフハックな記事も書く。 ToDo管理とか、今日何やったかとか、今日やったことについてのメモとか、 今日やるべきことについてのメモとか、どうやって管理するかということについて。 就職したときに考案して、 その後特に変更もなく1年ちょっと使っているわけなのだけど、 こんな感じです。 log2008-06-01.txt のようなファイルを作る。 一番上に出勤時刻・昼休み開始・終了・退勤時刻を書く。 やったことは「●何々のコード書く」のように書く。 補足があれば「(tab)・何々だけ書いた」のように書く。 やることは「ToDo:」のコーナーを作って 「・何々のコード書く」のように書く。 メモは「●何々」のコーナーを作って「・何々に注意」のように書く。 毎朝、昨日の分を今日の名前にしてコピーする。log2008-06-02.txt 昨日やったこと、昨日のための
夢見るSIerと虚構 - GeekFactory
たまには実情を書いてみる。愚痴大会なので読み飛ばしてくだしあ。 SIer の経営方針としては、｢どんなカタチにせよ、生産性を高めるのである｣という方向に行くと思います。生産性を高める要因は２つしかなくて、｢開発プロセスの改善｣と｢ソフト生成の自動化｣です。要するにワンタッチでポンでシステムが出来ればすげぇじゃんっていう発想。でも、そもそも要件定義が終わると全部終わるので、どうにかして改善されたプロセスを最大限に働かせるアジャイル的プロセスへの移行は不可避だと思う。 http://d.hatena.ne.jp/gothedistance/20090723/1248331426 「開発プロセスの改善」はどこのSIerでも施策に挙げていると思いますが、成果を上げているところはあるのですかねぇ。要件定義と開発はまったく別の仕事だから、両者で改善方法はまったく異なるはず。まずは後者のウォーターフォー
プログラミング知らないHTMLコーダーがダメな理由｜増田にゃんねるβ
1 名前:以下、はてなにかわりまして元増田がお送りします。 投稿日:2009/02/22 10:02:51 web業界にも様々な職種があり、最近では分業化も進んでるみたいだが、 だからって「自分はHTMLコーダーですから、プログラミングには興味ありません」は通用しない。 HTMLコーダーやデザイナーも、プログラミングは勿論サーバーやネットワークの知識を持つべき。 まぁデザイナーは別業界でもある程度潰しがきくかもしれない。 一番危ういのはHTMLコーダー。 HTMLコーダーって、HTMLしか書けない人が多い。 プログラミングは分からない、とか、勉強する気はない、とか言っちゃう人もいる。 HTMLなんて所詮静的なものだから、webっていう分野の中で見たときその重要度は最底辺である。 webは動的でこそ意味があるからね。 HTMLコーダーという職業が未だ成立しているのは、単にプログラマがHTML
デバッグという基礎素養 - みねこあ
経験の浅いプログラマーがデバッグにてこずってるのって、 これと似ていて、 むやみやたらにクリックするのだけど、 自分の知ってるパターンに収束させることができない、みたいな。 これについては、経験を積めば、 自分の知ってるパターンが増えてきて、 バグだ、と思ったときには既に自分の知ってるパターンだから直せる、とか、 ちょっと試行錯誤すればパターンに落とし込めるとか、 そうなるんじゃないかな、と。 経験の浅いプログラマーがデバッグできない理由 については、コンパイラの吐くエラーが実は直接的が原因を示していない、とか、そういうレベルの話では実感だな、って思います。 「そうそう、コンパイラがこんなこと言うときは実際にはあんな事が起きてるんですよ」みたいな知識データベース。そしてコンパイラが検出出来ないタイプのバグについても、現象に「あれ？、どこかでみたぞ、これ」となる。そういう「良くあるパターン」
2つの逆引き本「Ruby逆引きレシピ」「Ruby逆引きハンドブック」 - きりかノート 3冊め
最近出版された、2冊のRubyを冠した"逆引き"本。「似たような本で、どっちか買えばいいかな〜」と考えている人もいるかもしれないけれど、ぜんぜんちがう。「レシピ」はプログラムを書く前に見る本、「ハンドブック」はコード書くときに見る本、という位置づけになる。たぶん。 Ruby 逆引きレシピ すぐに美味しいサンプル&テクニック 232 (PROGRAMMER’S RECIPE) 作者: 島田浩二,設樂洋爾,村田賢太,前田智樹,谷口文威出版社/メーカー: 翔泳社発売日: 2009/07/25メディア: 単行本（ソフトカバー）購入: 16人 クリック: 349回この商品を含むブログ (77件) を見る Ruby逆引きハンドブック 作者: るびきち出版社/メーカー: シーアンドアール研究所発売日: 2009/05/25メディア: 単行本購入: 24人 クリック: 263回この商品を含むブログ (72
あの「レガシーコード改善ガイド」が出るよ - 木曜不足
翔泳社さんから 7/14 に いよいよ出版される「レガシーコード改善ガイド」。 レガシーコード改善ガイド (Object Oriented SELECTION) 作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義出版社/メーカー: 翔泳社発売日: 2009/07/14メディア: 大型本購入: 45人 クリック: 673回この商品を含むブログ (157件) を見る 昨年、原書の "Working Effectively with Legacy Code" を読書会に参加してずっと読んでいたが、その邦訳だ。 第２回 第３回 第４回 第５回 第６回(最終回) 読書会というと通常はもっとスローペースなのだろうけど、あのボリュームの洋書をわずか６回*1で読み切ってしまった。みんな続きが早く早く読みたくて興奮していた、のかもしれない。 で、この読書
チェックされる例外とチェックされない例外について - じゅんいち☆かとうの技術日誌
例外の扱いについてあれこれと調べてみました。 まず、既存のエントリから。ふむふむ。ごもっとも。 Error callerによるリカバリは不能(原因はcalleeにある or 特定不能)である為。 RuntimeException リカバリの可否はcalleeに判断不能である為。callerはリカバリ可能ならばcatchすれば良いし、不可能ならばスルーすれば良い。 Exception(非RTE) 第三者異常を想定することは必須。callerにも同様の想定を強制させ、リカバリ処理を書かせなければならない為。 特にAPI設計者として、気を使うのはどういう場合にリカバリ可能とするかどうかですね。リカバリというのをどう定義するかってところ。 で、先人たちはどう例外を扱っているんだろうということで、Seasar2とかSpringを調べてみる。 Seasar2はRuntimeExceptionですね。2
成功するネットサービスの十分条件の一つ : ひろゆき＠オープンSNS
【教えてくん】コミュニティーなのです。 なんかニュースとかあったらここに書こうかと思ってますよ。とりあえず、おいらのブログ 成功するネットサービスの十分条件の一つ mixi、gree、はてな、2ch、ニコニコ動画と、 わりと有名どころのサービスの中の人から話しを聞いてて、だいたい共通してるけど、 あんまり言及されていない事実。 スタート時もしくは現在にもわたって さくらインターネットの専用サーバを使っている。 スタートアップにコストをかけずに、 ある程度の規模のサービスをしようとすると、 さくらインターネットの専用サーバは安い。7800円。 ただ、root権限で自分でいろいろいじらなきゃいけないので、 素人には敬遠される。 んでも、root権限でいろいろ出来るぐらいの人じゃなければ、 サービスの改善が出来なかったり。 また、安価なコースの専用サーバのハードウェアのスペックは あんまりよくな
hontsuna.net
このドメインを購入する。 hontsuna.net 2018 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
何故「多重下請け構造」がなくならないかというと、お前らが営業をサボってるからだよ!! - 消毒しましょ!
こいつもshi3zとかいうバカgeekと同じで、定期的にバカな持論を開陳しないと気が済まないらしいので、再度disることにするw ここにあるのは業界外の人間から見れば非常識極まりない戯言ばかりであり、それが何に起因しているのかと言えば、徹底した自己中心性と幼稚な甘えに他ならない。 この不景気をきっかけに、発注側のユーザ企業に変わってもらいたい。丸投げではなく、基本、SIは自分たちで行い、手が足りない部分を技術のプロフェッショナルに手伝ってもらうやり方。 「SIerは、どうやれば生き残ることができるのか」を考えた末の結論が「この不景気をきっかけに、発注側のユーザ企業に変わってもら」うことだというのだから、相変わらず信じられないくらいのバカというか、空恐ろしいまでの甘えと幼稚さである。「多重下請け構造こそ、SI業界の最大の問題点」であるなら、さっさと自分で営業して仕事を取って来りゃいいだけの話
最近SIerがだいぶヤバくなっている件 - GoTheDistance
via IT業界から思ったことを。 Twitterでつぶやいたら結構こんな感じで厳しい状態になっているSIerが増えているようなので、僕なりに現状をまとめてみる。 よくわかるSIer涙目の構図 サブプライム、金融危機でSIerのお得意様の金融・メーカー様が大打撃を食らう。 2008年はとりあえず様子見で予算編成は据え置きだったが、今年に入って財布にチャックがかかる。 先行き不透明なので、GW明けぐらいの今期のIT予算が相当カットされた数字になった所が続出。 計画していた新規案件を中止するなどする。運用でなるべくカバーする方向へお客様が動く。 その結果SIerは新規案件がなくなる。案件自体がなくなっていく。予算が無いから当たり前。 大手がプロパーの仕事がなくなってきたのでプロパーで人数減らしてまわし始める。 プライムで食い込んでいるお客様の仕事が減ってきたので、外注に仕事が依頼できる余裕がな
第1回 W3Cとその標準化プロセス | gihyo.jp
「Web標準」や「XHTML+CSS」といった言葉がでてくるWeb制作の本には、必ずといっていいほど「W3C」という言葉が登場します。今回はそのW3CというWeb標準化団体について、またW3Cが策定する仕様がどのように作られているのかをとりあげます。 そもそもW3Cって? W3C（World Wide Web Consortium）とは、Web技術の標準化を行う団体のひとつです。「Webの可能性を最大限に引き出す」ことを目的とし、Webの発明者であるTim Berners-Leeによって1994年に組織されました。W3Cは今日までにHTML（3.2以降）やXML、XHTML、CSSといった、数々の仕様を公開しています。 W3Cには、IT関連企業をはじめとする400近くの会員が参加しています。Apple, Google, Microsoft, Mozilla, Operaといったブラウザベ
Integer.toString( i ) に見る数値から文字列への変換 | mwSoft
Integer.toString( int )の動作例 Integer.toString( int )はこんな感じで動きます。 /** 100の場合 */ String str = Integer.toString( 100 ); System.out.println( str ); // => 100 Integer.toString( int )の中身 では、Integer.toString( int )の中身はどうなっているのでしょう。 覗いてみました。けっこう長いです。 public static String toString(int i) { // Integer.MIN_VALUEは正の数に変換することができない // 下の処理で正の数への変換を行う箇所がある為、固定の結果を返す形で逃がしている if (i == Integer.MIN_VALUE) return "-214
新人研修 - yojikのlog
新人研修の講義を、ヒトコマだけやりました。テーマは「オブジェクト指向について何か」。広すぎる。。 考えたあげく、3時間ほど、BlueJで遊ぶという形にしました。BlueJは一見UMLツールっぽい学習用開発環境です*1。実際BlueJは、クラスを定義したらすぐにインスタンス化して右クリックでメソッド呼び出し、さらにインスペクトしてオブジェクトの内容を確認する、という作業をダイナミックに行うことができるIDEです。 もちろんSmalltalkでは普通に出来ることですが、言語がJavaなのがオモロイところです。 他のオブジェクトに対してメッセージを投げるというメタファはJavaみたいな言語だと理解しづらいですが、こういう環境で補うことによってイメージすることができるようになります。クラスとインスタンスの違いという初心者が嵌まりやすいポイントもツールで視覚化することによって一発で説明できます。また
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MSDN ホームページ
Amazon.co.jp: アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技: ロバート・C・マーチン (著), 瀬谷啓介 (翻訳): 本
達人プログラマー
IBM Developer
Amazon.co.jp: ダンジョンゲームプログラミング: 森山弘樹, 鷲見健二: 本