タイムスタンプ 初回投稿日:2020年06月26日 最終更新日:2020年07月18日 対象読者 この投稿は、ちょうど20年ほど前にソフトウェアエンジニアとしてのピークを迎えていた当時30歳くらいの自分自身に宛てて書いた手紙です。 したがって、この内容は個人的なものであり、くたびれた老兵の戯言であり、ピントがずれ時代を捉えきれておらず、網羅的でもなければ他者には通じないアナロジーに溢れていて、多くの方にとって役に立たないばかりか、酷い勘違いや致命的な間違いを含んでいるかもしれません。 とは言うものの、現在の私のように、今もなお 20 年前の知見や思考パターンが生活のベースになっている方、新しい知識や用語は押さえているもののそれが今一つ自身の血肉になっていないと感じている方、最近の技術トレンドを押さえたいけれど情報の洪水に溺れそうになり何から手を付ければいいかわからないという方にとっては、あ
フロントエンドエンジニアの今村です。TypeScriptではenumを使わずunion型を使いましょう、という話を書きます。 モチベーション 何を今さら、と思う方もいるかもしれません。 TypeScriptのunion型はenum的なものを表現可能であり、基本的にenumよりもunion型を使うべき、という意識を持っているTypeScriptプログラマーはすでに少なからずいるのではないかと思います。しかし、ではenumの使用はいかなる場合も避けるべきなのか、そうでないとしたらどのような基準でenumとunion型を使い分けるべきなのか、といった点について、広く合意の取れたガイドラインはなさそうです(少なくとも私は知りません)。この結果、コードレビューなどで少しやりづらさを感じることがあったので、白黒つけてしまいたいという気持ちからこのブログを書いています。 結論としては、enumは全面的に
開発する際、タスクで上手くいかない可能性のある特定の物事を反映するために、独自のエラークラスが必要になることがよくあります。ネットワーク操作のエラーであれば、HttpError、データベース操作は DbError、検索操作の場合はNotFoundError などが必要な場合があります。 エラーは message, name 、望ましくは stack のような基本のエラープロパティをサポートすべきです。ですが、他にも独自のプロパティを持つかもしれません。例えば HttpError オブジェクトであれば、 404, 403 もしくは 500 といった値をとる statusCode プロパティです。 JavaScript は任意の引数で throw できるので、技術的にはカスタムのエラークラスは Error から継承する必要はありません。しかし、継承しているとエラーオブジェクトを識別する obj
急速なIT化の進行によってエンジニアが不足しており、情報系の学位を取得せずに独学やプログラミングスクールを通してエンジニアになる人も増えています。そうした人たちがコンピュータサイエンスを学ぼうとしたときにおすすめの分野や本・オンライン講義などが「teachyourselfcs.com」というサイトにまとめられています。 Teach Yourself Computer Science https://teachyourselfcs.com/ ◆コンピュータ・アーキテクチャ コンピュータが実際にどのように機能しているのかをしっかりとイメージできなければ、安定した抽象化を行うことはできません。この分野を学ぶのにおすすめなのは「コンピュータ・システム ~プログラマの視点から~」という本で、タイトルに「プログラマの視点から」とついている通り、高速で効率的で信頼性の高いソフトウェアを作成するという目的
I feel like I should comment some of the clams being posted as replies here. For starters, speed IS an issue with MD5 in particular and also SHA1. I've written my own MD5 bruteforce application just for the fun of it, and using only my CPU I can easily check a hash against about 200mill. hash per second. The main reason for this speed is that you for most attempts can bypass 19 out of 64 steps in
はじめに インストールすればすぐに書けて動かせるのが魅力のPythonですが、 実際に業務などでキチンと書こうと思ったら Pythonのバージョン管理ツール パッケージマネージャー エディター(IDE) リンター フォーマッター 型チェッカー くらいは最低限用意する必要があります。 しかしこの界隈、怒涛の勢いで日々新しいものがリリースされていて一概に「これがベストプラクティス」を提示するのが難しいんですよね。そこで今回は上記それぞれのツールについて「こんなものがあるよ」というのをご紹介したいと思います。 TLDR バージョン/パッケージ管理はpyenv + Pipenvがスタンダードだった時代は終わった VS CodeかVimを使うなら型解析にPyrightを導入するとよい テンプレートを用意しました 1. バージョン/パッケージマネージャー プロジェクトごとに異なるPythonのバージョ
長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。 この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。 著者について プログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています(経歴)。ここ一年は R&D 的な位置付けで形式手法もやっています。 自動テストの限界 自動テストとは 私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。 この記事でいう自動テストとは以下のようにテスト対象を実際に
本ガイドラインでは、アプリケーションを、次の3レイヤで分割する。 アプリケーション層 ドメイン層 インフラストラクチャ層 各層には、以下のコンポーネントが含まれる。
webpack を使った code splitting のベストプラクティスとして,v3 以前の CommonsChunkPlugin の時代から node_modules 以下に置かれている依存ライブラリを vendor.js という単一の chunk にまとめる方法が紹介されていました. これは webpack の公式ドキュメント Caching | webpack や Google の Make use of long-term caching | Web Fundamentals | Google Developers でも説明されている通り,「ライブラリのコードはアプリケーションコードに比べると更新頻度が低い」という仮定のもと vendor.js にライブラリコードを切り出すことで,キャッシュ効率をよくすることが主な目的でした. しかし時は流れ,いつしか「ライブラリのコー
この投稿では、値としては「文字列」なんだけど、単なる文字列ではなく「電話番号型」という意味を持たせた文字列型を定義し、それ使用する方法を紹介します。 TypeScriptで「電話番号型」みたいな、正規表現でバリデーションされるような型は作れるんかな? ElmだとOpaque Typeなんてやり方があったけど。。。 用は型をexportしないで、その型の値を作る方法だけをexportすればええんかな。 — 無職やめ太郎(本名) (@Yametaro1983) April 23, 2020 ↑上のような疑問に対する答えです。 実現方針 方針としては、以下のテクニックの組み合わせです。 公称型で、「電話番号型」を定義する ユーザ定義タイプガードで、文字列型を電話番号型としてコンパイラに認識してもらう 公称型とその実装方法についての基本は下記投稿をご覧ください。 TypeScript: 異なる2つ
コードの品質を上げることを目的として導入されることも多いドメイン駆動設計(DDD)。しかし、その本質は「モデリングでソフトウェアの価値を高める」ことです。そのためには、アプリケーション層とドメイン層を区別し、どの層に何を実装するのかを決めるのが重要です。DDDの本質、そしてモデリングから実装までの考え方を松岡幸一郎氏が語ります。講演資料はこちら ユースケース図とドメインモデル図を使ったモデリング手法 松岡幸一郎氏:モデリングのやり方は1つに決まったものはとくにないんですが、リレーションシップ駆動要件分析(RDRA)やユースケース駆動分析設計など、いろいろと紹介されているものがあります。 これらもけっこういろいろな要件定義から踏み込んでできるようなフレームワークになっていて、DDDにおける実績もあるんですが、出てくる図の種類がすごく多かったりして、この説明とかを理解するだけでも、かなり時間が
2020/5/13追記 オブジェクト指向と哲学の関係について書いた記事ではないです。せっかくだしQiitaっぽいタイトルつけようと思ったら結果的に釣りっぽくなってしまった 概要 オブジェクト指向とは何か?ということを真面目に調べていくと、オブジェクト指向には二種類ある、という話に突き当たる。sumim氏のQuora回答などを参照。 Smalltalkの設計者アラン・ケイによる、メッセージング重視のオブジェクト指向 C++の設計者ストラウストラップによる、クラス重視のオブジェクト指向 今回はこの前者のオブジェクト指向について、アラン・ケイの書きものを読んで調べた結果をまとめ、コメントを付す。 参考文献は最後にまとめて出す。参照元は「(AOO)」のように略記で示す。 アラン・ケイのオブジェクト指向 OOPは私にとって、メッセージング、状態処理の局所的な保持・保護と隠蔽、そしてあらゆる事象の徹底
自分がコーディング面接対策のために解いてよかった LeetCode の問題をコンセプトごとにまとめました。カバーするコンセプトは LinkedList Stack Heap, PriorityQueue HashMap Graph, BFS, DFS Tree, BT, BST Sort Dynamic Programming Binary search Recursion Sliding window Greedy + Backtracking です。 これらの問題が 30 分以内に実装できれば面接の準備は整ったと言っていいと思います。Easy と Medium で問題は構成されてます。進捗を管理するためにGoogle Spreadsheetを用意しました。コピペしてご自由にお使いください。 これらの問題は、LeetCode のリスト機能でも公開されています。クローンすれば自分がすでにど
この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA@IT で回答したものです。残念ながらQA@IT のサービス終了(2020/02/28)と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY(クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0) で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回
■ クリーンアーキテクチャって難しい。 クリーンアーキテクチャって難しいですよね。 この有名な同心円状の図、何度見てもよくわかりません。右下にある矢印もよくわかりません。 様々な記事を見ても、やっぱり分かるような分からないような... プロダクトに COM 通信が必要になったので勇んでクリーンアーキテクチャを採用したはいいものの、 どうにも理解しきれず泣きながら必死に試行錯誤をしていたところ、 ふと クリーンアーキテクチャは『鎖国』に例えると分かりやすい という事に気が付きました。 本記事では初心者なりにその言語化にチャレンジしてみたいと思います。 ※ なお考え方そのものに着目するため、コードは全く取り扱いません。その点ご了承ください。 またクリーンアーキテクチャは、表面的なメリット(ユニットテストしやすい等) だけを見て批判されてしまうことも有るようです。 その辺りについても少し触れてみ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く