バグの原因は何か?はやくバグを潰す観点

本記事の目的 完成したとおもったコードが期待通りに動かず実装していた時間よりデバッグをしている時間の方が長くかかることがあります。 大抵の場合、デバッグに夢中になるあまり手当たり次第にバグの原因を探しており、気づく頃には時間が溶けていて、消費した時間を憂いてさらに焦って失敗します。 そのような悲しくて辛いことを繰り返さないようにすることが本記事の目的です。 バグの一番の原因は、「冷静さの欠如」です。デバッグに時間がかかって「焦り」「イライラ」を感じたら一旦手を置いてください。 あなたが悩んでいるそのバグは実は簡単に潰すことができます!あなたが苦しんでいるのは冷静さを失っているからです!さあ冷静さを取り戻すために次の質問に回答しましょう! 実装箇所のコードが達成したい目的は何ですか? 焦るあまりに元々のコードが達成したかった目的を見失っていることがあります。修正を加えていって当初のコードの目的を見失うとデバッグどころか1から再実装なんてことにもなりかねません。 もう一度、あなたが実現したい機能は何だったのか言葉にしてみましょう。達成しなければならないものが思っているより簡単だったことを思い出すかもしれませんよ。 筆者は、そもそも目的を見失わないように開発する手段としてテスト駆動開発をおすすめします。 簡単にテスト駆動開発を紹介すると、コードを実装する前にユニットテスト(UT)を書いてコードに期待する動作を明確にし、テストが通るように実装する開発手法です。 コードの期待動作をUTで明確にすることで実装の間違いはコンピュータが素早く正確に伝えてくれるのでコードの目的からずれることを防ぎます。 また、一通り実装が終わりリファクタリングをする場合もUTが通ることを守れば自信を持ってリファクタリングができます。 さらには、UTを実装することが大変であればそもそも関数の定義が悪いことにも気づくことができます。 詳細は、こちらの記事がおすすめです。 テスト駆動開発(TDD)とは?TDDの進め方をステップ毎に解説! テスト駆動開発って何だろう またテスト駆動開発はamazonで買えるので一読をおすすめします。 エラーメッセージの意味を日本語で他人に伝えられますか? エラーメッセージは大抵の場合、英語で出力されます。その英語のメッセージを正しく理解しないことが原因で沼にはまることがあります。 筆者はどうしようもなくなり、助けを求めようとしてメンバーにエラーメッセージの意味を説明しようとし始めると「あ!」と気づいて、すぐに解決できたことがあります。 カタカナを使わずにエラーメッセージを日本語に翻訳してみましょう。なにかに気づくかもしれません。 例えば、“Unauthorized” とエラーメッセージ中にあったとしましょう。 カタカナにすると「アンオウソライズド」です。聞き馴染みのある音なのでなんとなく意味はわかると思います。 しかし、デバッグ中になんとなくは危険です! "Unauthorized" - without authority or permission 日本語にすると「権限が無い」という意味になります。「権限が無い」と「認証されていない」を勘違いしていませんでしたか? 2つの意味は大きく違います。正しく日本語でエラーメッセージを理解することで、あっけなくデバッグできることも多々あります。 おすすめ記事:よくわかる認証と認可 動作環境に問題がないでしょうか? ローカル環境で実装したコードを開発環境、ステージング環境で動作を確認しようとしたらなぜかコードが動かない。訳のわからないエラーが出ている。この現象は、マイクロサービス構成を取っていると起こりやすいかもしれません。 あなたが実装したアプリケーションだけ最新のコードがデプロイされており、連携するアプリケーションのデプロイは1週間前で止まっている、開発途中でデプロイされたアプリケーションと連携している、かもしれません。 依存するアプリケーションのコードをすべて最新にしてデプロイしなおしてみましょう。 また外部のアプリケーションと連携する機能を試験したいときにローカル環境では動作しないということもあります。開発環境かステージング環境へデプロイしてみると、動くやないかい!ということもあるかもしれません。

Webアプリ作るなら必須!Cookieを徹底調査

Cookieについて改めて勉強しました ぼんやりと理解していたCookieを正しく知ろうと思い立ちいろいろと検索をしていたらCookieとCacheの違いを説明している記事が多く、純粋にCookieについて教えてくれる記事が少なそうだったので書くに至りました。 勉強して思ったのは、Cookieを正しく知らないでWebアプリケーションを開発することは非常に危険だということです。Cookieの理解が曖昧だとセキュリティ問題に繋がる可能性が高いです。 Cookie起因のWebサービスの脆弱性は、ユーザーのログイン状態が奪われるなど影響が大きく、万が一、発生すると会社の信頼がどん底に落ちてしまいます。 Cookieについて正しく理解して防げる脆弱性は潰していきましょう! 本記事では、Cookieとは何か、どんな使われ方をするのか、Cookieが絡むセキュリティ問題について書いています。 RFC6265に世界標準のCookieの仕様が載っているので適宜参照してください。 まず、ひとことでCookieとは? ステートレスなHTTP通信でも一人ひとりに違う内容のページを表示させたり、前回のアクセスの続きとして対応することを可能にするために個人を識別する会員証のように扱われ、 Webサーバーからユーザーのwebブラウザに送られる、ユーザーのデータを保存しておくためのファイルのことです。 ステートレス:サーバーなどのシステムが現在の状態を表すデータ(ログイン状態等)を保持せず、入力の内容によってのみ出力が決まる方式です。同じ入力に対する出力は常に同じになります。 (出典)ステートレスとは - IT用語辞典 e-Words どんな使われ方をするのか? 個人を識別できることから以下の利用方法が代表的です。 Webサービスへのログイン状態の保持 ECサイトの買い物かご機能 広告の最適化 Cookieはログイン状態の保持に使われることから攻撃者は、そのログイン状態を奪いにかかります。ログイン状態を奪われるとあなたのログインしているWebサービスを勝手に攻撃者に使われることになります。 Cookieの属性 Cookieはサーバーからブラウザへと送信され、Cookieをブラウザ上でどのように扱ってほしいか指定する「属性」を付与することができます。 注意点としては、ブラウザからサーバーへのリクエストでは、属性を指定できません。つまりCookieの属性が指定していできるのは、サーバー -> ブラウザ の一方向のみです。 Path パス毎に異なるセッションIDを発行したいというときに有効な属性です。例えば、pathによってサービスが違う場合に使えます。 ただし、異なるパスへのCookie付与はできてしまうため、安全性は保証されません。 Domain デフォルト状態であるこの属性を指定しないCookieが一番安全と言われています。 CookieのDomain属性は 指定しない が一番安全 Domain属性を指定しないCookieは、Cookieを発行したホストのみに送信されます。サブドメインへは送信されません。 デフォルト状態が送信される範囲が最も狭く安全であると言えます。 逆にDomain属性を指定すると、サブドメインを含むホストへ送信されます。 Domain=hoge.com を指定したCookieは、foo.hoge.comへも送信されます。 Domain属性なしのCookieは、hoge.

「レガシーコードからの脱却」を読んでまとめました

レガシーコードからの脱却を読んだので勉強になった点や感想を書きます。 最初から、ちょっとネガティブなことを書くと、本書のタイトルは「レガシーコードからの脱却」なので、レガシーコードから脱却できる方法を書いていると思っていましたが、どちらかというとそもそもレガシーコードにさせないための「べからず集」「ベストプラクティス集」といった内容でタイトルに沿っていないと思いました。 既にレガシーであるコードは「手遅れだよ」と言われているようでした。 個人的にレガシーコードから脱却するためには、本書に書かれているベストプラクティスを少しずつ取り入れて、少しずつ改善していくしか無いと思います。 例えば、ユニットテストを書いたり、タスクの進め方を変えてみたり、少しずつレガシーコードから脱却するしかありません。 話を変えて本書からは、他の業界に比べて発展途上なソフトウェア業界全体を成長させていきたいという筆者の気持ちが伝わりました。 ソフトウェアは顧客の問題を解決するものであり、その顧客の要求は使われる限り変わり続け、増え続けます。 それに応え続ける必要があるソフトウェアには完成が無く、最初の設計時に理想の姿なんてわかりません。その業界の特殊性に応えるベストプラクティスを紹介し、それに従う利点を紹介しています。 全体的に開発者寄りのベストプラクティスの紹介が多かったですが、プロジェクトマネジメントも活かせるものを紹介されており、明日からの開発方法やタスクプランニングのやり方に取り入れようと思うものばかりでした。 特に気に入った本書中の例え話は、一晩に200皿以上の料理を作る凄腕料理人が「汚くする時間がない」と言って作業台を常にきれいに片付けて清潔に保っているという話です。 最速で開発したいならタスクを細かく小さくして整理し、コードにはユニットテストを書いてリファクタリングができるようにコードの振る舞いを明示するなど一見すると時間がかかって面倒だと思うことが清潔を保ちながら素早く開発することだと伝わるいい話でした。 僕も明日から本書で学んだことを意識して品質の高いコードを書いてきたいです!! 下記に本書で大事だと思ったことをまとめました。個人の振り返りように何度も読み返したいです。 第1章:何かが間違っている レガシーコードとは何か 何年も前に書かれた、ドキュメントもなく変数名も適当なシステムを見ると、失われた古代文明の謎を考古学者が陶器の破片から解こうとしているかのように感じることもある。 ウォータフォール開発の欠点 要求 > 設計 > 実装 > 統合 > テスト > インストール > 保守 統合フェーズまで開発者が動作を確認できないので後から多くのバグが見つかる、それまでは見つからない 再テストと再統合に多くの時間を費やすことになる ソフトウェアを作るときに私達が行うタスクは刻々と変化し、日ごと、月ごと、そしてプロジェクト毎に大きく異なるので、特定タスクを見積もることが難しいのだ。 第2章:CHAOSレポート再考 ここではCHAOSレポートという過去に行われたソフトウェア開発のプロジェクトを分析した調査結果を紹介していますが、筆者の意見からは重要でないと感じたため割愛します。 しかし、個人的に本性で重要だと思ったことをまとめます。 コードの変更 ソフトウェアが使われている限りコードは変更することになる。大抵の場合、保守を行うチームは開発したチームとは異なるので、コードを書くより読むことに時間を費やすことになるが、変更が大規模になるとコードを読んで書き足すのではなく、コードをまるごと書き換えようとすることが多い。 その書き換えに伴う新機能の開発がバグ生むことになる。

良いコードを書くために必須なオブジェクト指向について学べる本を紹介します

Heads First オブジェクト指向分析を読みました オブジェクト指向に対する理解を深めたいと思って探していたら、図やイラストが多くて読みやすくて内容もいいといろんなブログやレビューでおすすめされていたので買ってみました。 Heads First オブジェクト指向分析を読んだので勉強になった点や読書した感想を書きます。 僕の感想では、「買ってよかった」です。顧客が解決したい問題を聞き出して要件をまとめ、コードに落とし込み、ソフトウェアを運用していくための知見を本から学び実務にすぐに活かせたので買ってよかったと思います。 本で一番伝わってきたことは、「ソフトウェアに求められる機能は日々変わっていく」ということです。お客さんに使われる限り、ソフトウェアに完成というものは無く、新たな機能が求められます。その要求に応え続けるためにどのよう設計していけばいいかを学ぶことができます。 本書は図やイラスト、写真がふんだんに使われていて読んでいて飽きないように作られていることに感動しました。大事なことは何度も出てきて絶対に見落とさないように強調されています。また、なぜ大事なのかというのもQ&A方式で書かれていて読みやすく頭にすっとはいってきました。 下記に本から学んだことをまとめました。 オブジェクト指向を理解するのに必要な単語 柔軟性 顧客が満足するために必要です。ソフトウェアが解決するのは顧客の課題です。 そして、顧客の課題は毎日変わっていくものなので柔軟性が無いと期待に応えることができません。 カプセル化 再利用を確実に行い既に誰かが解いている問題を再び解かないようにします。 また再利用をしないといことは、重複するコードが散らばっており柔軟性が阻害されている状態です。 低結合 コードの変化する部分を分離します。コードの変換に影響を受ける箇所を減らします。 デザインパターン 毎回作り直さなくともソフトウェアの変更と成長が可能になるようにします。アプリケーションが脆弱になるのを防ぎます。 またデザインパターンを説明の際に使うと他の開発者はあなたの考えている設計を迅速かつ正確に理解できます。 さらにパターンレベルで話をすると議論を設計レベルに留めることができ、オブジェクトとクラスの実装の細々とした詳細を話す必要がなくなります。 委譲 ある作業の責任を別のクラ スまたはメソッドに手渡すことです。 他のクラスの機能を使用しなければならないが、変更をする必要がない時、継承ではなく委譲を検討するべきです。 また振る舞いを変更する必要がなく、自分で実装する責任がオブジェクトに存在しないのであれば、他のクラスに振る舞いを委譲します。 なぜ重要なのか 委譲によってコードの再利用性が容易になります。オブジェクトの振る舞いを処理するコードがアプリケーション全体に広まることがなくなり、オブジェクトは自分の機能だけを処理すれば良くなります。 オブジェクトはソフトウェア内の他のオブジェクトで発生する実装上の変更から遮断されます。 なぜ委譲することで再利用可能なコードになるのか 委譲することでオブジェクト間の独立性が増して疎結合となります。疎結合のオブジェクトは、他のオブジェクトと強く結合していないので、別のアプリケーションにおいても再利用することができます。 ちなみに疎結合とは、オブジェクトが自分の仕事にだけ専念している状態です。単一責任の法則。 オブジェクト指向の原則 変動するものはカプセル化する(変更が容易になる) 実装に対してではなくインターフェイスに対してコードを作成する(拡張が容易になる) アプリケーション内のクラスは、変更される理由を1つだけにする 要件とは正確に何なのか システムが期待通り動作するために実行しなければならない特定の事柄です。 顧客目線であることが重要です。なので要件は常に変換します。

Githubアカウント切り替える方法(鍵作成〜アカウント切り替え)

はじめに 早速質問ですが、Githubのアカウントを会社用とプライベートなアカウントを持っている方は多いと思うのですが、 どうやってアカウントの切り替えをしていますか? 今回は、鍵の作成・登録から仕事用とプライベート用のアカウントの切り替え方法を可能な限り丁寧にお届けしたいと思います。 記事の構成 ① ssh用の公開鍵と秘密鍵の作成 Githubとssh通信するために必要な認証情報を作成します。 秘密鍵は絶対に人と共有してはいけません。 Githubのリポジトリと通信してプルやプッシュとかやりとりするために必要です。 ② 公開鍵と秘密鍵をgithubへ登録 鍵のイメージ 銀行口座に例えると、 公開鍵は口座番号です。お金を振り込んでもらうために公開します。 秘密鍵はATMを操作するときに使用する暗証番号です。自分1人しか知りません。 ③ 鍵とGithubアカウントを紐付ける ④ アカウントを切り替えて git clone する ⑤ ssh-agent に鍵を登録する(パスワードの入力を省略する) ① sshの公開鍵と秘密鍵の作成 まずはsshを管理しているディレクトリへ移動します。 1 cd ~/.ssh 会社用、プライベート用の 公開鍵と秘密鍵を早速作成します。 ssh-genkey というコマンドを使用します。 ssh-keygen [オプション] -t 鍵タイプ [-N 新しいパスフレーズ] [-C コメント] [-f 鍵ファイル] ssh-keygen -p [-P 古いパスフレーズ] [-N 新しいパスフレーズ] [-f 鍵ファイル] ssh-keygen -i [-f 鍵ファイル] ssh-keygen -l [-f 鍵ファイル] 下記を実行するとパスワードが求められます。 この鍵を使用してsshをするとき(git push)とかにこのパスワードを使用します。 また -fに指定した名前で2つファイルが作成されています。 hoge hoge.