はじめに 「テストコードを書きましょう」とはよく言われるし、テストコードが大事だってことも理解できるんだけど、何をテストしたらいいの？どんなテストを書いたらいいの？と迷っている初心者プログラマさんは意外と多いのではないでしょうか？ そんな方たちに向けて、この記事では僕が普段意識しているテストコードの方針を紹介します。 おことわり 本来であれば具体的なコード例も豊富に入れたいところなのですが、かなり時間がかかってしまうので、いったん文章メインで記事を公開します。 もしかすると、そのうちコード例も一緒に盛り込んだ「リッチバージョン」を公開するかもしれません。 この記事の前提条件 この記事ではあくまで、「今現在、筆者が仕事で書いているテストコードの方針」です。 そのため、状況が異なると適用しづらい方針も出てくるかもしれません。 筆者は以下のような現場でコードを書いています。 月額定額で、お客様と

オラクル、JavaやJavaScript、Ruby、Pythonなど多言語対応を単一ランタイムで実現する「GraalVM」をオープンソースで公開。Twitterが本番環境で採用 JavaやJavaScriptなどには、それぞれその言語を実行するためのランタイムが存在します。JavaならJavaVM、JavaScriptならJavaScriptエンジンといった具合です。 米オラクルがオープンソースで公開した「GraalVM」は、これまで言語ごとに個別に用意されていたランタイムを統合し、単一の高性能なVMにするという同社の研究の結果開発された汎用仮想マシンあるいは汎用ランタイムです（米オラクルのブログ、日本語訳）。 GraalVMのWebサイトには、次のような説明が記されています。 GraalVM is a universal virtual machine for running appli

はじめに コードレビューを受けている時,これは修正が必須なレビューコメントなのか,出来たら修正した方がいいものなのか,判断に迷う時ってありませんか？ 付き合いの長いチームや, メンバー同士でレビューをしていると感覚的に分かることもあるけど, 新しいチーム, 新しいメンバーなど関係性が出来上がる前だと, 温度感が分からず判断に迷うことがありそうです. 結果, 全てを対応しようと頑張りすぎてしまい, 修正に恐ろしく時間がかかってリリースが遅れるなど本末転倒な不幸なケースも起こりえそうです。 例）先輩がいってるし全部直さなきゃ...! [must] 必ず対応してほしい！ [imo] 自分の意見や提案・好み。 自分ならこう書くけどどうかな？ [nits] 些細な指摘。 ほんの小さな指摘だけど出来れば直してほしい。インデントやタイポ [ask] 質問,確認。 コードの意味や背景が分からないから教えて

2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod

こんにちは、エンジニアアルバイトの koki-satoです。 今回、Qiitaで使用しているシンタックスハイライトのライブラリを変更し、対応する言語の種類が増えました。これにより、今まで対応していなかったJSXなどのシンタックスハイライトにも対応するようになります。 背景Qiitaでは、これまでシンタックスハイライト用のライブラリとして、PygmentsのRuby用のラッパーライブラリであるPygments.rbを利用してきました。その後、Rubyで書かれたシンタックスハイライトライブラリであるRougeが登場し、今回以下の理由からRougeに変更することに決めました。 ラッパーライブラリであるPygments.rbと比較して、Rougeは他言語のプロセスを起動する必要が無く安定しやすいRougeがPygmentsの対応していない言語にも対応している残念ながら逆のパターンも存在するため一概

概要 以前、JSで書いた(ファミコンのエミュレータを書いた - undefined)ファミコンのエミュレータをRustで書き直してみた。 また、技術的な内容はQiitaの方にも書いているので興味のある方は参照してみてください。(まだ Hello, World!までしか書けてませんが。) qiita.com もともとファミコンのエミュレータって新しい言語を習得するのにちょうどいい題材だったりするのでは、って話しからスタートしてて、よくわからないのでJSで書いてみて、ようやくRustで一通りは実装できた感じ。まだバグや未実装（音声周りやマッパー）も多いんですが、ひとまずはお腹いっぱいな感じ。 成果物 github.com あと、いくつかのROMは以下で遊べるようにしてます。音が出るので注意してください。 またAPUの実装にまだバグが残っているのDCMチャンネルが未実装なので音が変だったり出てな

のようなイメージではないでしょうか？ (灰色と橙色の分け方は作者のおすすめ度（匙加減）な気もしなくないんですが） はい…まさにこの通りですのでこれを参照頂ければなと思います。隅まで目を通していないのがバレますね。 では早速本題 🚀Introduction これが2017版 2018版 左の奴らが軒並みチョーヤバいです。雑だな！ まあここは導入みたいなもんなんで深くは追及しません。最早OSSや仮想鯖、クラウド環境化での開発は必須なんだってことが言いたいんだと思います。（適当） デザインパターンってのはGoF(Gang of Four)というおじさん４人がソフトウェア開発に取り入れたオブジェクト指向プログラミングにおけるこう書くとオブジェクト指向的にええと思う！っていうパターンの集まりです。全23種、知らず知らずのうちに使っているものも多いです。 なんで今追加されたのか僕にはよくわかりません

本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション

はじめに クラウドワークスの初期バージョンを作ってから早6年。後任のエンジニアたちには様々なdisりを受けてきました。 システムアーキテクチャや設計（命名は除く）に関するdisりについては、何よりもビジネスを軌道に乗せることが優先されるタイミングでどこまで「ちゃんと」やるべきか、という議論の余地が常にあります（自分のスキル不足については、いったん棚に上げます）。 一方、「命名」については、サービス立ち上げ期であっても「ちゃんと」やるべきと断言できます。 なぜならば、 システム外（例えば、非エンジニアとのコミュニケーション）にも関係してくる、ある意味ではシステムの最も基礎的な部分と言えるため、ここでしくじると影響範囲がでかい ネーミングをがんばったからといって、それ自体にかかる時間はたかが知れているし、その後の開発速度に悪影響を与えることもほとんどない すなわち、命名を「ちゃんと」考えるとい

※ 本記事は自分が運営しているブログに転載しています。 株式会社LITALICOでWebエンジニア（Rails）を担当しています、@YudaiTsukamotoです。 この記事は『LITALICO Advent Calendar 2017』14日目の記事です。 今回は、実務でペアプロを導入したことで、ペアプロへの考えが180度変わった話について書こうと思います。 はじめに この話は、弊社のとある新規プロジェクトの立ち上げで実際にペアプロを導入した話です。 プロジェクトでは初期メンバーとして私を含めた4人の開発者がアサインされました。過去のプロジェクトで比較的うまく機能していたアジャイルの導入や、ソフトウェアテスト・静的解析ツール等を徹底してコードの品質を担保するなど、アプリケーション開発する上での準備を入念に行いました。 そんな中、同じプロジェクトにアサインされた同期の@Takuan_Oi

「ユーザー目線」のシステムを目指して RDBが従来の階層型DBに比べて優れていた点はいくつか挙げることができますが、シェアを伸ばすうえで最も大きな影響は、ユーザーが使いやすいデータ構造とインタフェースにこだわったことです。すなわち、「テーブル」と「SQL」の発明です。 RDBでは、すべてのデータを「テーブル」というただ一つのデータ形式によって表現します。テーブルは、見た目が「二次元表」に似ているため*3、Microsoft ExcelやGoogle ドキュメントなどのスプレッドシートを使い慣れた人が見ると、データを格納する方法が直観的にイメージしやすいという利点があります。実際、こうした二次元表によるデータ管理は、Excelなどのソフトウェアが登場する前から一般的な方法だったため、RDBが登場した当時の人々にとっても受け入れやすいものでした。 テーブルが画期的だった点は、もう一つあります。

Cognitect社のNygardさんが10年ぶりに改訂したRelease It! 2nd Editionがまもなくリリースされます。内容は現在のベータ5版で全て書ききっておられるようなので、是非読んでみてください。 https://pragprog.com/book/mnee2/release-it-second-edition その中から4章の安定性パターンの概要をご紹介し、実際JavaのFailsafeライブラリを使った実装例を示したいと思います。 安定性のパターン Stability Patterns 分散システムや後続をブロッキングしてしまう重い処理は、システム全体がスローダウンしたり、無応答になってしまう危険にさらされています。クラウド時代になって、これらの安定性を保つための設計はより強調されるようになりましたが、わりと昔から様々な工夫がされてきたものでもあります。以下、Rel

※この記事は「ソフトウェアテストの小ネタ Advent Calendar 2017 - Qiita」用の記事です。 ソフトウェアテストの小ネタ 2日目担当のオムそばです。 実はちゃんとした(?)記事を書くのはこれが初めてなので、生暖かい目で見ていただければ。 そんなわけで早速表題の件、市場バグを引き起こした優秀なデータたちをご紹介します。 今回は、よくある「半角記号」、「空白やスペース」などは割愛させていただきます。 (2017/12/26追記)"市場バグ"という言葉に違和感や疑問を持たれた方は、こちらの記事をどうぞ。文言について整理してみました。 ■日時に関するデータ ・1969/12/31、2038/1/20：UNIX系のシステムに有効なデータ。UNIXのシステム時刻は1970/1/1 開始なので、それ以前のデータを打ち込むと予期せぬエラーが発生する可能性がある。また、同様に2038/

セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い

テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま