タグ

Programmingに関するhokorobiのブックマーク (41)

  • ぷろぐらみんぐおさんぽまっぷ

    C83で配布した「ぷろぐらみんぐおさんぽまっぷ」の内容を無償公開しています。 プログラミングを学び始めた駆け出しプログラマが、これから何を学ぶべきか、どんな分野があるのかを俯瞰できるような文章です。部下や後輩を育てたいあなたにも、ぜひ読んでいただきたい内容です。 昔読んで感銘を受けたハッカーになろうの現代版(&&詳しく書いた)ともとれます。 PDFダウンロード(4MB) Webページ

  • オブジェクト指向プログラミングの教え方? | システム設計日記

    技術者仲間で話していたら、4月入社の新人に、オブジェクト指向プログラミングをどうやって教えたらよいか?、という話になった。 想定している言語は Java。 ■動物・犬・モデルの説明から ■基用語の説明から:「カプセル化とは」「継承とは」... ■サンプルコードから: System.out.println( "hello world" ) ... どのパターンでもうまくいかなかったので、今度の新人研修では何か工夫したいね、という話。 結論から言うと「これだ」というアイデアがでたわけではないが、話の内容は、いろいろ興味深かったのでメモ書き。 Java はオブジェクト指向の言語なの? Java は、ある意味 C言語の仲間。ある側面はほとんど同じ言語。 ・int, long (プリミティブなデータ型) ・配列操作 ・if/for/return ここだけ見れば、C言語のまま。つまり命令型、手続き

  • コメントについて考えてみた

    Developers Summit 2014 【13-D-7】 コミュニティLT - Story 5. 「新人技術者にどうプログラミングを教えたか」Fujio Kojima

    コメントについて考えてみた
  • neue cc - Modern C# Programming Style Guide

    C# Advent Calendar 2011、ということで、C# 4.0時代のプログラミングスタイルについて説明してみます。モダン、というけれど、某書のように変態的なことじゃなくて、むしろ基的な話のほうです。こういったものはナマモノなので、5.0になればまた変わる、6.0になればまた変わる。変わります。古い話を間に受けすぎないこと(歴史を知るのは大事だけど、そのまま信じるのは別の話)、常に知識をリフレッシュするようにすること。そういうのが大事よね。でも、だからってモダンに書けなきゃダメ!なんてことはありません。ただ、知ること、少しずつ変えていくこと、そういうのは大事よね、って。 ところでしかし、私の主観がかなり入っているので、その辺は差っ引いてください。 varを使う C# 3.0から搭載された型推論での宣言。出た当初には散々議論があって、今もたまに否の意見が出てきたりもしますが、va

  • 新人プログラマーに読ませて欲しいネーミングの大切さ - プログラマー幸福論

    Photo from Kıvanç Niş ネーミングについてまじめに長文を書いてみました。もし、あなたの会社にネーミングに疎い新人プログラマーがいたら読ませてやってください。 ちなみに、この記事はシステム開発のネーミングについて書いています。また、このブログの特性上、英語でのネーミングを想定していますが、日語のネーミングでも同様に考えることができると思います。 1. ネーミングの重要性 一般に、熟練のプログラマーほど、プログラミングにおける ネーミングに時間をかけます。それはなぜでしょうか。 あなたが付けたその変数名 data は、その時点では、自分のために付けた「目印的なもの」であったかもしれません。しかし、そのソースコードを引き継いだ担当者など多くの人が、その名前を見ることになります。 // データを取得する var data = getData(1); そしてその名前は、そのソー

    新人プログラマーに読ませて欲しいネーミングの大切さ - プログラマー幸福論
  • 定期的に繰り返し実行する簡単ではないお仕事 - やねうらおブログ(移転しました)

    いやー、この問題は当に難しい。難しすぎて、どうやって解決すればいいかいまだによくわからない。わからないので、ここに書いてみる。 最初、とあるお客さんのために「ひよこの餌やりプログラム(仮)」を作っていたんだ。開始ボタンを押すとひよこの餌が出てくる。たったそれだけのプログラム。 今回は、これを「定期的に実行する機能が欲しい」と言われた。 この要望を実現するのがすこぶる難しかったんだ。 「やねうらおってそんなプログラムすら書けないの?老害なの?」 とか言わないで欲しい。この問題、当に難しいんだよ! ■ 1度目のひよこの全滅 まず、この要望に沿って、私の会社のプログラマが当初、次のようなダイアログをつけたわけだ。 繰り返し実行のところにチェックを入れた場合、ここで指定された時間後にも繰り返し実行する。単位は分で指定する。1日ならば60×24 = 1440を指定する。そうすると、ひよこの餌やり

  • オブジェクト指向できていますか?

    3. 自己紹介 1992年~1997年 某ゲーム会社 プログラマ SFC,GB,PS1,N64のゲーム開発経験 1998年~現在 日工学院八王子専門学校 @mozmoz1972 専任講師 プログラミング教育を中心に担当 twitterもfacebookも実名です。よかったらフォローしてください。

    オブジェクト指向できていますか?
    hokorobi
    hokorobi 2012/08/29
    ここまでやるのか。
  • コードレビューについて - camlspotter’s blog

    このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや

    コードレビューについて - camlspotter’s blog
  • ペアプロ・TDDの『お題』をまとめてみた #tddbc #coderetreat #pp_con - Diary of absj31

    TDD及びペアプロを通じてプログラミングスキルを上げるべく、ネットで公開されている『お題』について色々情報収集してみました。 お題やテーマについては、見つけ次第随時追加していきます。 Stackユーティリティ from 『車窓からのTDD』 - 車窓からのTDD こちらについては自分でも試しに写経してみました。以下エントリ。 『車窓からのTDD』を写経してみた ( JDK7 / Eclipse4.2 / Quick JUnit / Mercurial / Bitbucket ) - Shinya’s Daily Report FizzBuzz問題 from TDDBC TDDBC お題 うるう年問題 from TDDBC TDDBC お題 LRU Cache from TDDBC TDDBC お題 ワードフィルタ from TDDBC TDDBC お題 以上、ここまでの4つのお題は和田卓人

    ペアプロ・TDDの『お題』をまとめてみた #tddbc #coderetreat #pp_con - Diary of absj31
  • 何故バグ報告の99%が役に立たないのかもしくは何故プロのテスターが存在するのか - oops

    テストにはプロがいます。「お仕事」で開発する場合はQA(Quality Assurance/品質保証)部門という「テストのプロ」がテストします。 バグ修正におけるテスターの役割は極めて重要で、「プログラマの手元で任意に再現可能な状態に持ち込めれば、バグ修正は8割終わっている」と言っても当に過言ではありません。詳細聞き出しに10時間、修正30分、修正確認テスト30分、なんてのも実務ではザラです。この場合、プログラマも11時間拘束される(=時給x11時間分のコストが掛かる)わけですから、バグ修正のコストは聞き出しに掛かるコストがほとんどを占めることになります。 (誤報告一発で万単位の金が簡単に吹っ飛ぶとも言える) まずそもそもの問題として「素人」がテストを行うと以下のような論外ケースが頻繁に起こります。上に行くほどクソです。 誤報告 実際に起こったことと、現象が違う、手順が違う、設定

  • 辞めていった人達が作ったシステムの保守を楽しいものにする - ariyasacca(2012-03-18)

    ▼ [Software]辞めていった人達が作ったシステムの保守を楽しいものにする はてなは「絶対すべきでないこと」をやらかしたのか? nabokov7; rehash : ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた?(下) この辺りの話題を眺めていて思うところあったので少し書いてみる。 別にはてな社やライブドア社がどうだって話ではなくて、システムやソフトウェアを開発する仕事の話です。 まず、大前提として、 新しくスクラッチから書き起こす 既にある機能と互換性を保ちながら改修する プログラマにとっては、前者の方が圧倒的に楽しい仕事だと思ってます。(最近無くなったらしいけど)グーグル社の20%ルールは、開発者の創造性を巧く引き出せるよう上手に設計された制度です。 ただ、現実問題として、IT業界では後者の仕事を行う機会の方が

    辞めていった人達が作ったシステムの保守を楽しいものにする - ariyasacca(2012-03-18)
  • クリアなコードの作り方: 意図が伝わるコミットのしかた - 2012-03-13 - ククログ

    コミットメッセージの書き方ではコミットをわかりやすくするためには以下の2つの条件を満たす必要があると書きました。 コミットの内容が分かりやすく説明されていること コミットの内容が小さくまとまっていること このうち「コミットの内容が分かりやすく説明されていること」についてはすでに説明済みです。今回は「コミットの内容が小さくまとまっていること」について説明します。 めざすところ 単純にコミットの内容を小さくするだけではわかりやすくなりません。それでは、どのような基準で小さくすればよいのでしょうか。 よく言われることは1つのコミットには1つの小さな論理的にまとまった変更だけにする、というものです。たしかにこれは重要です。しかし、これだけを基準とすると、人によっては大きめなコミットになってしまいます。人それぞれで論理的なまとまりの大きさが異なるからです。 1つのコミットでどうすればよいかを考えるの

    クリアなコードの作り方: 意図が伝わるコミットのしかた - 2012-03-13 - ククログ
    hokorobi
    hokorobi 2012/03/18
    「モジュールの中に移動する」のコミットの分け方は全然考えたことなかった。
  • 良いネーミングをするために覚えておきたい英語のルール5つ - プログラマー幸福論

    Photo by muraterturk こういった記事って、ネーミング規則や慣習の視点から書かれていることが多いんですけど、この記事では、英文法に視点を置いて、参考になりそうなことをいくつかピックアップしてみたいと思います。 「省略形は使わない」などの規約的なものは、各プロジェクトのルールに従えばいいので、ここでは書きません。あくまで英語という視点から書いているということを、ご理解ください。 Rule 1 : “検索”は名詞 一般的な英語辞書のルールでは「検索」は、動詞ではなく「検索する」が動詞になります。「検索」は、検索することの名称 だと考えられるため、動詞ではなく名詞として扱います。 英語辞書には、日語の品詞ごとに表記のルールがあります。これが理解できていると、和英辞書などで品詞を意識して検索できるようになります。以下に、一般的な英語辞書の表記ルールをまとめてみました。 <各品詞

    良いネーミングをするために覚えておきたい英語のルール5つ - プログラマー幸福論
  • テストが間違ってたら? - 日々常々

    「テストが間違ってたらどうするんだ」 自動テストの話をするとよく言われます。テストが間違ってたらわからないじゃないか。手動テストであれば、注意深く目で確認していれば間違いに気づけると言う主張です。 「目で確認していれば気づける」のは間違いではありません。必ず気付けるわけではありませんが、十分な知識を持った人が、十分な集中力と責任感をもってエビデンスを確認すれば、誤りに気付ける可能性は高いと思います。 品質(主に機能性)を目的とした自動テストでも、それを行う必要があります。それがテストコードのレビューです。 手動テストの場合、テスト実施前に手順や確認項目のレビュー、実施中の確認、実施後のエビデンス確認と、人が確認するタイミング*1が三カ所あります。 これに対し自動テストの場合、テストが書かれた時のみ。実行中は勿論、実行結果の確認に注意はありません。ただ成功か失敗かだけなので。ならば、テストコ

    テストが間違ってたら? - 日々常々
  • 「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok

    チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G

    「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok
  • Algorithm - 連想配列の実装としてのハッシュはオワコン? : 404 Blog Not Found

    2012年01月17日11:45 カテゴリアルゴリズム百選Tips Algorithm - 連想配列の実装としてのハッシュはオワコン? 珠玉のプログラミング Jon Bentley / 小林健一郎訳 つまり「終わったコンテナ」。 以前からうすぼんやりと考えて来た危惧が、すこしはっきりと見えてきた。 徳丸浩の日記: Webアプリケーションに対する広範なDoS攻撃手法(hashdos)の影響と対策 もうそろそろハッシュ(テーブル)以外の手段の連想配列の実装手段を格的に模索するべきではないか、と。 そのデータ構造は、君の魂を差し出すに足るものかい? 連想配列(Associative array)がコレクション(Collection)、すなわち数多のデータ構造をまとめるデータ構造としての覇者となったのはもはや疑いようがない事実でしょう「配列で実装されるデータ構造ではなくて、配列を実装するデータ構

    Algorithm - 連想配列の実装としてのハッシュはオワコン? : 404 Blog Not Found
  • ぐへへお姉ちゃんパンツ何色 私は黒は穿かない! - GeekなNooblog

    ちょっと気になったので突っ込みです。 カプセル化にはいくつもの意味がありますが、以下の内容はデータ隠蔽を取り上げています。 小人閑居して: 「ぐへへお姉ちゃんパンツ何色」から始めるクラス解説 http://boronology.blogspot.jp/2011/12/blog-post.html ここでは以下のようにパンツにアクセスするためのアクセッサー(setter,getter)を追加しています。 引用 お姉ちゃんのパンツの色を16進数で表示してね!というと……再びコンパイラが「お姉ちゃんのパンツの色はプライベートなのでアクセスできないぞっ」 と怒ります。そう、隠蔽されてしまったパンツの色を確認するにはどうしたらいいのでしょうか? こうしましょう。 class oneechan{ public: int get_pants_color(); void set_pants_color(i

    ぐへへお姉ちゃんパンツ何色 私は黒は穿かない! - GeekなNooblog
  • できる!並列・並行プログラミング

    現在のマルチスレッドプログラミングの抱える問題点と、代替案をわかりやすく解説いたします。最近登場したConcurrent Revisionsも解説します。Read less

    できる!並列・並行プログラミング
    hokorobi
    hokorobi 2011/12/13
    ほ~。どこかのシステムはシェルスクリプトでロックを使ってたな。
  • エラー処理を書いてはいけない

    エラー処理を書いてはいけない田中英行 tanaka.hideyuki@gmail.com 2011/12/08 @PFIセミナー 自己紹介田中英行 (@tanakh, http://tanakh.jp) PFI社でプログラマやってますJubatuspficommon検索エンジンのコアエンジンHaskell愛好家msgpack / rpc / idlpeggy (パーザジェネレータ & QQ w/ AQ)Shu-thing (シューティングゲーム) / (Monadius メンテナ)今気になるパッケージは monad-controlLearn you a Haskell 鋭意翻訳中 (春頃発売予定) エラー処理を書いてはいけない日の概要エラー処理を抽象化しようというお話です 現在のエラー処理の抱える問題どのように解決するのか実際の例エラーは処理しなければならない エラー処理を書いてはいけな

    hokorobi
    hokorobi 2011/12/13
    例外って何で勉強すればいいかわからなかったけど、そうか、Exceptional C++か。
  • もう一度身につけたい変態で学ぶオブジェクト指向 - Happy Programming!!

    コンニチハ! 変態アドベントカレンダーです。 http://atnd.org/events/22020 ※ アドベントカレンダーとは、クリスマスまでに毎日日替わりで窓を開けていくカレンダーのこと。 それにちなんで、日替わりでblogエントリを書くのがアドベントカレンダーです。 オブジェクト指向 ってよく聞きますし、実際のところ何がすごいの?? って思ったりしてる人も多いでしょう。 抽象クラスって何よ!? インタフェースとかどうやって使う? とか そういう初心者向けアーンドもう一度学びたい人達に変態を例に説明してみましょう。 うだうだですけど、最後まで読んでいただければ幸いです。。。 まず、オブジェクト指向は何が嬉しいのか?ってところですけど、 処理を共通化し、生産性をあげる!! ということではありません。 もちろんそういう一面もありますが、これぐらいならオブジェクト指向を使わなくても十分で

    もう一度身につけたい変態で学ぶオブジェクト指向 - Happy Programming!!