programmingに関するdai1741のブックマーク (16)

  • コードレビューのベストプラクティス | POSTD

    Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上

    コードレビューのベストプラクティス | POSTD
  • How to name things: the hardest problem in programming

    Developers can get better at their craft by learning from the great writers who mastered theirs. Writing software isn’t the same as writing a novel, but there are parallels. Besides, advice from writers is better because writers have been struggling with their craft for many centuries, not just a few decades. It’s better-written as well. This talk shares great writers’ best advice for coders: Step

    How to name things: the hardest problem in programming
  • プログラム技術的に凄いと思ったゲームソフト : 哲学ニュースnwk

    2015年05月02日16:00 プログラム技術的に凄いと思ったゲームソフト Tweet 1: 名無しさん必死だな@\(^o^)/ 2015/04/28(火) 16:48:14.37 ID:/WxOF07n0.net 俺はMGSPWが凄いと思った。PSPでよくあのグラフィックを出せた。 次点は同じくPSPのMHP2Gかな。 3DSの鉄拳も立体視で60fps出してたよね。 転載元:http://anago.2ch.sc/test/read.cgi/ghard/1430207294/ 日のヒーローが幼稚でアメリカのヒーローが幼稚じゃない風潮 http://blog.livedoor.jp/nwknews/archives/4866969.html 2: 名無しさん必死だな@\(^o^)/ 2015/04/28(火) 16:50:18.91 ID:yPXagsl30.net これはLBP しか

    プログラム技術的に凄いと思ったゲームソフト : 哲学ニュースnwk
  • CEDEC2014 「ライブラリを作ってはいけない ~それでも作りたいあなたへのアドバイス~」

    社内ライブラリを8年間に渡って作り、サポートし続けてきた講演者が、1~2年で完成するだろうという当初の想定とは裏腹に、なかなか進まない作業、得られないサポート、バグの押し付け合い、それら数々の修羅場から得られた、技術面およびサポート面でのノウハウをお伝えします。 http://cedec.cesa.or.jp/2014/session/ENG/8073.html ※2014/9/4にCEDEC2014@パシフィコ横浜で行った講演です。Read less

    CEDEC2014 「ライブラリを作ってはいけない ~それでも作りたいあなたへのアドバイス~」
  • 再考: GoF デザインパターン - Qiita

    投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代にカタログ化された 現代のプログラミングと合致しないものが多い 「オブジェクト指向における~」と断っている以上、OOPに絡める必要があった パターンのいくつかに「多態性を用いると便利」という蛇足がついている 挙げたパターンに根拠がない 「とりあえず、23個ほ

    再考: GoF デザインパターン - Qiita
  • 書いたコードが一発で動作するとなぜ不安なのか : akiyan.com

    書いたコードが一発で動作するとなぜ不安なのか 2013-04-21 プログラミングにおいて少なくないコードを一気に書き上げたとき、そのコードが一発で動作 or テストケースに通るとなんともいえない不安を覚えるのは、プログラマーなら誰でもあるあるネタだと思う。「当にこれ、一発で動作しちゃっていいの? 俺、そこまでミスしないプログラマーだっけ?」なんて自分を疑ったりする。 このあいだもそんなことがあったんだけど、ふと気になった。不安になる理由は、自信のなさからくるものだけだろうか? ちなみに、書いたコードが正しく動作しないとき、コードを修正すると不安になることはない。一体、なぜ? 一発で動作したブラウザの画面を見ながら、考えてみて、閃いた。「コードの修正は、書いたコードを見直す機会にもなっているから」じゃないだろうか。コードの見直しは「リファクタリング」といっていもいい。 一発で動作してしま

    書いたコードが一発で動作するとなぜ不安なのか : akiyan.com
  • おそらくはそれさえも平凡な日々: たとえばgetを避ける

    プログラムでは複数の意味を持ちうる単語は避けるというのがある。noとかrightとかが良い例だ。個人的に最近はgetも気をつけたほうが良いと思っていて、メソッド名にgetを使いたくなったときは大体間違えている。 Javaなんかのgetter/setter的なやつは、オブジェクト指向以前のパラダイムの名残でしかないと思ってる。手続きの内容をメソッド名にしているという、手続き型のパラダイムを引きずっている感。 例えば、 user.get_money みたいなコードがあった場合に、ユーザーがお金を獲得するのか、ユーザーの所持金額を取り出したいのかが分からない。オブジェクト指向的には前者が正しいのだけど、歴史的経緯から後者の意味合いで使わえる事が多い。プロパティの値を取り出すことが期待されてしまう。それが気持ち悪いので、getは極力使わないようにしている。 オブジェクト志向では、メソッド名はオブジ

  • オライリー本の原書をフリーで読む - minus9d's diary

    (2011/12/18, 2012/10/15, 2013/03/07, 2016/09/12 追記あり) 現在、オライリー・ジャパンが、Ebook Storeの商品を期間限定(2011年3月26日の午前0時まで)ですべて半額セール中。どれを買おうかと色々探しているうちに、いくつかのの原書はフリーで公開されていることに気づいたので、それをまとめておく。 O'Reilly Japan - ソフトウェアアーキテクトが知るべき97のこと →97 Things Every Software Architect Should Know - The Book - Softarch 97Things ただし、日語版には11編が追加 O'Reilly Japan - プログラマが知るべき97のこと →http://programmer.97things.oreilly.com/wiki/index.p

    オライリー本の原書をフリーで読む - minus9d's diary
  • http://fumieval.tumblr.com/post/28324791101

  • highscalability.com の Tumblr のアーキテクチャについての記事を読んだ - @kyanny's blog

    High Scalability - High Scalability - Tumblr Architecture - 15 Billion Page Views a Month and Harder to Scale than Twitter を読んだ。すごく面白かった。 Kindle で引用したところを中心にメモ。 Tumblr のソーシャルグラフの特徴 The graph for Tumblr users has hundreds of followers. This is different than any other social network and is what makes Tumblr so challenging to scale. Tumblr だと follower が数百人いるユーザーはザラにいる。 follower の多いユーザーの post は多くのユーザ

    highscalability.com の Tumblr のアーキテクチャについての記事を読んだ - @kyanny's blog
  • 目grep入門 +解説

    2019/10/16 初心者向けCTFのWeb分野の強化法 CTFのweb分野を勉強しているものの番でなかなか解けないと悩んでいないでしょうか?そんな悩みを持った方を対象に、私の経験からweb分野の強化法を解説します。 How to strengthen the CTF Web field for beginners !! Although you are studying the CTF web field, are you worried that you can't solve it in production? For those who have such problems, I will explain how to strengthen the web field based on my experience. (study group) https://yahoo-osa

    目grep入門 +解説
  • 言語女子会: undefとnullは両方必要? - 西尾泰和のはてなダイアリー

    Twitterのタイムラインが面白すぎて、ついうっかり言語を擬人化して脳内で言語女子会なるものを開いてしまいました。なお、登場人物と実在の人物は1対1に対応しません。 undefinedとnullの両方必要なの? とあるプログラミング言語が集う女子会にて: Perl: そういえばさ、なんでJavaScriptちゃんってundefinedとnullの両方もってるの? JavaScript: えっ、未定義の変数にアクセスした時undefined返したいじゃない? Python: 例外投げて死ねばいいじゃん Ruby: 例外投げて死ねばいいよね Python & Ruby: ねー♡ Java: いやそこは参照型ならnull、数値型なら0で初期化すべきでしょ C: これだから最近の若い子は…初期化にだってコストが掛かるんだからね!デフォルトで初期化するなんて無駄遣いよ!必要な人だけが責任をもって初

    言語女子会: undefとnullは両方必要? - 西尾泰和のはてなダイアリー
    dai1741
    dai1741 2012/03/18
    そこでCoffeeScriptの存在演算子ですよ。リストにundefined入れられるのには対応できないですけど!
  • 技術系メーリングリストで質問するときのパターン・ランゲージ

    目次 はじめに メーリングリスト —— サポートセンターではなく互助会です 表題 —— あいさつではなく用件を書きましょう 自己紹介 —— 自分の知識・技能・経験を簡潔に書きましょう 書き出し —— 最初に問題の要旨を書きましょう 肩書き —— 会社の名前を背負っていることを忘れないように 実行手順 —— 手順は箇条書きで書きましょう 結果の予想 —— 期待した結果を書きましょう 実際の結果 —— 実際に起きたことを書きましょう ステップ明記 —— どこからうまく行かなくなったかを書きましょう 実際の値 —— 条件を具体的に書きましょう エラーメッセージ —— 必ずコピー&ペーストしましょう 判断理由 —— そのように考えた理由を書きましょう 文献の引用 —— 読者の手間を省くように書きましょう ソース —— 関連する部分を抽出して示しましょう スレッド —— 関連する話題なら「返信」しま

  • クラスタリングの定番アルゴリズム「K-means法」をビジュアライズしてみた - てっく煮ブログ

    集合知プログラミング を読んでいたら、K-means 法(K平均法)の説明が出てきました。K-means 法はクラスタリングを行うための定番のアルゴリズムらしいです。存在は知っていたんだけどいまいちピンときていなかったので、動作を理解するためにサンプルを作ってみました。クリックすると1ステップずつ動かすことができます。クラスタの数や点の数を変更して、RESET を押すと好きなパラメータで試すことができます。こうやって1ステップずつ確認しながら動かしてみると、意外に単純な仕組みなのが実感できました。K-means 法とはK平均法 - Wikipedia に詳しく書いてあるけど、もうすこしザックリと書くとこんなイメージになります。各点にランダムにクラスタを割り当てるクラスタの重心を計算する。点のクラスタを、一番近い重心のクラスタに変更する変化がなければ終了。変化がある限りは 2. に戻る。これ

  • いやなブログ: 配列操作の比較表: Ruby, Python, JavaScript, Perl, C++

    配列操作の比較表: Ruby, Python, JavaScript, Perl, C++ プログラムを書いていると、他のプログラミング言語の記憶とごっちゃになって、「配列の後ろに要素を追加するのは push だっけ、 append だっけ」などと混乱することがあります。特に Ruby, Python, JavaScript はコードの書き方が似ているので、この問題が起きがちです。 そこで、備忘録として、 Ruby, Python, JavaScript, Perl, C++ の配列操作の比較表を作りました。一番慣れている Ruby を基準にしています。間違いなどがあったらご指摘いただけると助かります。他の言語のもあるといいなあ。 Ruby (Array) Python (list) JavaScript (Array) Perl (@) C++ (std::vector)

  • ひしだまのコンピューター関連技術メモ(Hishidama's Programming MemoPage)

    S-JIS[1998-01-11/2024-03-10] 変更履歴 ひしだま's 技術メモページ 自作ソフトを作った時などに気付いた事などをメモにしています。(自分のノート代わり) Access [/2005-03-15] Ant [/2015-12-28] Apache [/2007-09-28] AsakusaFW [/2021-12-21] awk [/2014-05-01] AWS [/2021-07-13] C言語 [/2016-04-09] Cassandra [/2010-10-21] CMake [/2016-04-27] CVS [/2007-10-04] Cygwin [/2016-11-26] DigDag [/2021-10-30] Docker [2023-10-07] DOS [/2016-12-10] Eclipse [/2018-09-22] Embulk

  • 1