テストコードの期待値はDRYを捨ててベタ書きする ～テストコードの重要な役割とは？～ - Qiita
はじめに みなさん、DRY原則はご存知でしょうか？ DRY = Don't repeat yourselfの略で「繰り返しを避けること」という意味ですよね。 良いコードを書くための重要かつ基本的な原則なので、みなさんよくご存知だと思います。 ですが、DRY原則はテストコードを書く場合は必ずしも最善にはならない場合があります。 他の人が書いたテストコードを見ていると、テストコードにDRY原則を適用したために、かえって悪いコードになっているケースをときどき見かけます。 この記事ではなぜテストコードをDRYにすると良くないのか、ということを説明します。 追記：タイトルを変更しました @t_wada さんのコメントを受けて、タイトルを見直しました。 「テストコードはDRYを捨ててベタ書きする」 => 「テストコードの期待値はDRYを捨ててベタ書きする」 【注意】この記事は画一的なテストコードの書き
初学者に教えたい、MicrosoftがGitHubで公開している教材が最高だった！ - Qiita
はじめに エンジニアやデータサイエンティストの人材育成のためのオープンソースな教材を探していたらMicrosoftがGitHubでかなり質の高い教材をweb開発、データサイエンティスト、機械学習、IoTの四項目を対象に提供してるのを発見したため共有したいと思う。 正直、マイクロソフトと聞くとGoogleやらFacebookに比べていけてないイメージを持っていたけど、実際にMicrosoftのGitHubレポジトリを見て、彼らはここ数年で大きく変わったように思える。特に人材育成や学習教材に関しては世界一かもしれないなんて思っています。本記事では筆者が自信を持っておすすめするMicrosoftのオープン教材を紹介するのでぜひ自身の勉強や人材育成に生かしてもらえれば本記事を執筆した甲斐があります。（もちろん僕がお勧めしているだけでなくてGitHubのスター数も多く世界的に認められています！） こ
PHPのオブジェクトは参照渡しではないし、変数リファレンスは全然別物 - Qiita
まだ参照渡しで消耗してたの？ 僕はPHPerなのでPHPのことしかわからないけど、だいたいPHPで参照渡しのことを気にしても時間の無駄だし積極的に利用するべき場面が極めて限定されることはPHPのリファレンス(参照&)の傾向と対策、あるいはさよならに書いたので読んでほしい。 それとPHPマニュアルでは「参照渡し」ではなく「リファレンス渡し」と呼ぶが、どちらにせよ、わざわざ「渡し (call by-)」を付けて呼ぶ意義は乏しいので、これからは「変数リファレンス」として覚えてほしい。もうちょっと具体的なことはPHP: リファレンスとは? - Manualを読んで。 端的に言うと、PHPでは「オブジェクト引数はデフォルトで引数渡しされる」「オブジェクトのプロパティ(メンバー変数)は参照渡し」のような理解は誤解であり、完全に嘘です。 ふしぎなふしぎなオブジェクト PHPの配列とオブジェクトは、似たよ
Pythonでも簡単にGUIは作れる - Qiita
PythonだってGUIを作りたい Pythonで書いたプログラムを実行して使う場合、『GUIで入出力できたら便利なのに…』と思うときはありませんか？ 誰かにプログラムを配布する場合でも、CUI(コマンドラインから入出力)はあまり親切とは言えません。 特にITスキルの高くない人にとっては、CUIは拒絶反応を起こすこともあります。 Pythonでも簡単にGUIを作れたら… そんな場合、PySimpleGuiを使ってみてはいかがでしょうか？ PySimpleGuiは誰でも簡単にGUIを実装できるのが特徴で、PySimpleGui公式ドキュメントによると、PySimpleGuiはすぐに習得でき、コード量も他のGUIライブラリ(Tkinter、Qt、WxPythonなど)の1/2～1/10程度で済むとのこと。 百聞は一見にしかずなので、まずは下記のコードと実行結果をご覧ください。 import P
真偽値を返す関数のネーミング - Qiita
みんな exists を使ってます。 納得できようができまいが、exists なのです。 ソフトウェアの世界では、Apple と Microsoft と Google が黒と言ったら黒です。 黙って従いましょう。 このように、関数名の表現に困ったら、世の中の API を参考にすると良いです。 非ネイティブの我々では思いつかないような的確な表現が見つかることもあります。 関数の名付け方 真偽値を返す関数は if 文で使われることが多いので、頭に if を置いて最もしっくり来る表現が良いと思います。 個人的には、真偽値を返す関数名を考えるときは以下のフォーマットに当てはめるようにしています。 if オブジェクト名 関数名 「項目が選択中だったら」なら "if item is selected" なので関数名は item.isSelected() となります。 同様に「項目が存在したら」なら "
PHP: fgetcsvでもSJISのCSVをUTF-8として《安全》に読む方法(ストリームフィルタ使用) - Qiita
fgetcsvでShift-JIS文字コードのCSVを読むと、文字列がShift-JISのままの配列が返ってくるため、UTF-8を基本的な文字コードに据えたシステムでただ不便というだけにとどまらず、SJISのCSVをfgetcsvで直接読み取るのは「5C問題」のため危険である。 本稿では、ストリームフィルタを使ったSJIS CSVの安全な読み込み方法を紹介する。なお、本稿で作るストリームフィルタの完成形はGitHubで公開する。 5C問題とは よく見かける次のような実装は5C問題のため、データによっては読めないものが出てくる危険性がある: $fp = fopen('sjis.csv', 'r'); while ($row = fgetcsv($fp) !== false) { // fgetcsvで読み取った後に、文字コードを変換している mb_convert_variables('UTF
gitのmerge --no-ff のススメ - Qiita
2015年も終わりになって、gitの基本的な使い方の話に更なる需要があるとは思っていないのですが 本日が私のAdventCalender担当日であることと、本日偶然遭遇したトラブルの都合上、もしかしたらまだ需要が微レ存かもしれないと思い記事を書いていきたいと思います。 まとめ 皆しとくといい。 git のデフォルト設定はどうなっているか gitはデフォルトではmergeコマンドを使った際に、mergeコミットを発生させる必要がない場合mergeコミットを発生せずにmergeを行うfast-forwardでのmergeを行うようになっている。 --no-ffというオプションを付けることで意図的にfast-forwardを行わないコミットをすることが出来る。 どういうトラブルが起こるか 仮にmasterにtopicAブランチをmergeしたとする。 fast-forwardであるmergeの場
Railsのcontrollerにおいて、メソッド外で初期化したインスタンス変数を参照すべきでない理由 - Qiita
Railsのcontrollerにおいて、メソッド外で初期化したインスタンス変数を参照すべきでない理由RubyRails 背景 Ruby on Rails を利用した中規模以上のプロジェクトにおいて、 Fat な controller を解消するために、処理を分割することはしばしば行われます。例えば、サブメソッドへの一部処理の切り出し, before_action, concern への処理の委譲が行われます。しかし、処理を分割する際に、メソッド外で初期化したインスタンス変数を参照してしまうような例を時々見かけます。 このような実装は、一見DRYでシンプルに見えてしまうかもしれませんが、実際には開発効率の低下につながったり、バグの原因になる可能性が高くなります。 この記事では、メソッド外で初期化されたインスタンス変数を参照することの危険性と、それを避けた方が良い理由を考察してみたいと思いま
Backbone.js入門 「View と Model と Collection の連携」 - Qiita
閲覧上の注意 この記事で対象としているバージョン0.5.3は結構古いので注意してください。 その他の割りと新しい情報は Backbone.js Advent Calendar 2012 などにあります。 （追記ここまで） Backbone.js入門シリーズも佳境に差し掛かってきました。 View と Model の連携は既に取り上げたので、今回は特に Collection と View Model との連携に主眼を当てて記述したいと思います。 View と Collection の連携 復習の意味も込めて、View と Model の連携方法をもう一度記述すると、大枠として次のようになります。 // モデルの定義 Hoge = Backbone.Model.extend({}); // ビューの定義 HogeView = Backbone.View.extend({ events: { "
Qiitaで何があったのか
Qiitaで起きたちょっとした騒ぎについて、事情を知らない人たちが混乱しているみたい。 自分が知っている範囲で、何があったのかを書いておくことにする。� 登場人物については、具体名を出すと迷惑かと思うのですべて伏せる。 知りたければ調べれば分かると思う。 ちょっと前の話何ヶ月くらい前だったか、Qiitaでちょっと�話題になった投稿があった。 Swiftについての話だったからWWDC2014よりは後の話。 この投稿をしたのが今回の騒ぎの中心人物。名前を言ってはいけないあの人。以下Kとする。 で、何が話題だったかって、ものすごい分量のテキストでそれっぽく書いてあるんだけど�内容は�(というかタイトルからして)デタラメ。 でもものすごい分量でそれっぽく書かれていると信じてしまう人もいるようだった。 コメント欄には正しい指摘をする人もいたんだけど、Kは否定的な指摘(客観的に見て正しい指摘なのだが)
Swiftで面倒なJSONの取り扱いをさらに10倍便利にするclass JSON - Qiita
Swiftで面倒なJSONの取り扱いを10倍便利にするSwiftyJSONをもってしても、まだJavaScriptよりも面倒だったのが悔しかったので書きました。 https://github.com/dankogai/swift-json/ Synopsis AnyObjectなSwiftオブジェクトも、こうして JSON Stringにできます。 let obj:[String:AnyObject] = [ "array": [JSON.null, false, 0, "",[],[:]], "object":[ "null": JSON.null, "bool": true, "int": 42, "double": 3.141592653589793, "string": "a α\t弾\n?", "array": [], "object": [:] ], "url":"http:/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
