タグ

コードに関するanatofuzのブックマーク (10)

  • レビューしやすいプルリクエスト | DevelopersIO

    普段レビューをしていて、レビューしやすいプルリクエストに対して個人的に感じている特徴をまとめてみました。 普段レビューをしていて、レビューしやすいプルリクエストに対して個人的に感じている特徴をまとめてみました。 割と大きめなソースコードに対するレビューの話が主となります。 ざっくりまとめ 記事では以下のようなトピックについて記載しています。 差分の目的が1つ レビューをしながら「私はいま何のレビューをしているのか」のコンテキストスイッチが発生しないので嬉しい 何を達成したいのかがわかる レビューの多くは「やりたいこと」と「実現方法」のすり合わせなので、前者の精度を上げたい 分割されすぎていない 他のコードとの関連性や構造についてのレビューがしやすい レビューの強弱をつけるための情報がついている 機械的な変換の差分だったりした場合、それが事前にわかると嬉しい 検証結果が書いてある コードだ

    レビューしやすいプルリクエスト | DevelopersIO
  • VM命令ディスパッチ手法: Context Threading - Qiita

    2005年のそれほど新しくないものだが、Context Threading: A flexible and efficient dispatch technique for virtual machine interpreters という論文を読んだので、内容について少しまとめておく。 前提知識: 既存のThreading手法 http://www.complang.tuwien.ac.at/forth/threaded-code.html にまとまっているが、この論文では以下の2つが関係している: Direct threading: ラベルのアドレスを取得するGCC拡張などを使い、VMのprogram counterからVM命令の実装のアドレスをディスパッチしてそこにジャンプする Subroutine threading: VM命令の実装を関数にしておき、それをcallする命令を並べたネ

    VM命令ディスパッチ手法: Context Threading - Qiita
  • マネーフォワード社内PRに見られるRubyの書き方について - (3) 文字列の生成や検証 - Money Forward Developers Blog

    エンジニアの澤田です。 この連載では、マネーフォワード社内のRuby (on Rails)コードで気になった箇所の問題点やそこから発展して関連事項を議論しています。 前回の『マネーフォワード社内PRに見られるRubyの書き方について(2)』ではハッシュの生成を扱いました。 概念的な話で始まり、また長かったので、読んだ方は少し疲れたかも知れません。 今回は内容の特性により、用例を並べて手短に問題点を指摘して、文字列(String)の生成や検証を考察します。 題材とするコードは、マネーフォワード社内のGitHubプルリクエストで実際に見かけたコードから問題点に関係する部分を抽出し、抽象化したもので、見かけたものそのままではありません。 社内のコードに限らず、文字列に関わるRubyコードで問題のあるものの多くは、必要もないのに正規表現を使ってやろうとしていたり、特定のメソッドに固執してそれを乱用

    マネーフォワード社内PRに見られるRubyの書き方について - (3) 文字列の生成や検証 - Money Forward Developers Blog
  • JITあれこれ | κeenのHappy Hacκing Blog

    κeenです。遅刻してしまいましたがこのエントリーは 言語実装 Advent Calendar 2018 1日目の記事です。 最近私の観測範囲内でJITが流行っているのですが一口にJITと言っても色々あるよなーと思ったので私がJITについて知っていることをグダクダ話します。 このブログでも何度がJITや周辺技術について取り上げてますが話の流れがスムーズになるので最初から説明していきます。 2018-12-03: 加筆修正しました。差分はこちら JITって? Just in Time(コンパイル)のことで、日語にすると「間に合ってコンパイル」になりますかね。 インタプリタの高速化テクニックの1つです。 最初はインタプリタのようにコードをコンパイルせずプロセスが起動しますが、メソッドを実行するまでにはメソッドをコンパイルして、ネイティブコードで実行する方式です。 来ならJITはこのような意

    JITあれこれ | κeenのHappy Hacκing Blog
  • 第5章 ガ-ベージコレクション

    プログラムの実行時イメージ 突然だが、章を始めるに先立ち、プログラム実行時のメモリ空間の状態につ いて予習をしておこうと思う。この章ではコンピュータの低レベルな部分にか なり踏み込んでいくことになるので、あらかじめある程度の知識を仕入れてお かないと太刀打ちできないのだ。それにこの後の章になればいずれ必要になっ てくる。ここで一回やってしまえば後が楽だ。 セグメント 一般的なCプログラムではメモリ空間の中に以下の部分を持つ。 テキスト領域 スタティック変数やグローバル変数の置場 マシンスタック ヒープ テキスト領域はコードが置いてあるところ。二番目は見ての通り。マシンスタッ クには関数の引数やローカル変数が積まれる。ヒープはmalloc()で割り当てて もらうところだ。 三つめのマシンスタックについてもう少し話そう。マシン「スタック」と言う くらいだから当然スタック構造をしている。つまり

  • プログラマが知るべき97のこと

    プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中!すべてのプログラマにおすすめのがウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する(あなたはユーザではない)コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず

    プログラマが知るべき97のこと
  • コミットメッセージアンチパターン: コメント対応 - koicの日記

    コミットメッセージには、変更に対する「なぜ」を書く。 週末の余暇のうちに以下のツイートについてもう少しテキスト化しておく。 「コメント対応」というコミットメッセージへの指摘がめんどうなので、クライアントサイドでの git hook を用意した。配置を求めるのがなんだけど。 https://t.co/rbpS0DF2Cw— Koichi ITO (@koic) November 14, 2016 Git など使うことで、ソースコードへの変更理由について、5W1H に沿った変更履歴を知ることができることが理想。 「いつ (When) 」コードに対していつ変更を加えたのかはタイムスタンプを見れば分かる 「どこで (Where) 」コードに対して何を変更を加えたのかはリソース (file/dir) 名で分かる 「誰が (Who) 」コードに対して誰が変更を加えたのかは author を見れば分かる

    コミットメッセージアンチパターン: コメント対応 - koicの日記
  • ファイルオープンの罠 - Journal InTime(2017-12-15)

    _ ファイルオープンの罠 僕が書いたNet::FTPのコードに脆弱性報告があり、修正版がリリースされた。関係者のみなさん、ありがとうございました。 CVE-2017-17405: Net::FTP におけるコマンドインジェクションの脆弱性について 問題があったのは以下のようなコードだった。 def getbinaryfile(remotefile, localfile = File.basename(remotefile), blocksize = DEFAULT_BLOCKSIZE, &block) # :yield: data f = nil result = nil if localfile if @resume rest_offset = File.size?(localfile) f = open(localfile, "a") else rest_offset = nil f

  • 有限オートマトンを実装してなんとなく挙動をつかむ - 私が歌川です

    前置き みなさんは、チューリングテストに合格していますか? 題 有限オートマトンとは、内部状態を持ち、入力によってさまざまな状態に遷移し動作する機械を抽象化したものです。 これは、有限オートマトン - Wikipediaから引用した図です。このように、状態を表す図形と矢印を使った状態遷移図や、状態遷移表によって表されることが多いです。 さて、しばしば私たちは有限オートマトンをペンで書き下ろすのですが、それがどのように振る舞うのか、逐一入力を変えて確かめてみたくなります。しかしそれは大変な苦痛を伴います。 そのようなときには実装してしまいましょう。 gist.github.com コンストラクタに、アルファベットの集合(ここでは 01 のどちらか)と、状態遷移表に対応する辞書型のリストを渡します。 {'0': 0, '1': 1, 'accepted': True} は、この状態にあるとき

    有限オートマトンを実装してなんとなく挙動をつかむ - 私が歌川です
  • 静的単一代入 - Wikipedia

    静的単一代入(せいてきたんいつだいにゅう、英: Static Single Assignment form, SSA)形式は、コンパイラ設計における 中間表現 (IR) のひとつで、各変数が一度のみ代入されるよう定義されたものである。もともとの中間表現における変数は「バージョン」に分割され、全ての変数の定義がバージョンを表現できるよう、通例新たな変数は元の名前に添え字を付けて表現される。SSA ではuse-def 連鎖が明示的であり、連鎖は要素を一つだけ持つ。 SSA はRon Cytron、Jeanne Ferrante、Barry Rosen、Mark Wegman、Ken Zadeck および IBM の研究者たちにより1980年代に開発された。 Scheme、ML、Haskell などの関数型言語のコンパイラでは、Fortran や C などのコンパイラで SSA の利用が期待され

    静的単一代入 - Wikipedia
  • 1