TypeScriptで学ぶ！SOLID原則
はじめに 皆さんこんにちは、株式会社エムアイ・ラボのエンジニアです！ 今回はソフトウェア設計のSOLID原則について学習したので、弊社のメインの開発言語であるTypeScriptのサンプルコードを使って共有できればと思います。 SOLID原則は、オブジェクト思考プログラミングにおいて、ソフトウェアがメンテナンスしやすく、拡張や変更に強いソフトウェア設計を行うための原則です。 SOLID原則にはSOLIDの頭文字をそれぞれとった、５つの原則があります。 単一責任の原則（Single Responsibility Principle） 単一責任の原則とは、クラスが一つの機能や責任を持つべきで、クラスが変更される理由は一つであるべきというです。 クラスが一つの機能や責任のみを持つようにすることにより、コードは再利用可能でテストが容易になります。 単一責任の原則を遵守している例 以下のBirdクラ
TypeScriptでCLIツール作りをするためのプロジェクトサンプルを作ってみた - $shibayu36->blog;
最近TypeScriptの学習をしようと思い、何でもTypeScriptで作ってみている。今回はCLIツールを作ろうと思ったのだが、ビルド環境やeslint環境など考えることが結構あった。そこでTypeScriptでのCLIツールのプロジェクトサンプルを作りながら勉強してみた。 作成したのは https://github.com/shibayu36/typescript-cli-project 。 npm install -g shibayu36/typescript-cli-project でtypescript-cli-projectというコマンドがインストールされ実行できるようになった。 このプロジェクトサンプル作成を通して学んだことをメモしておく。 参考文献 以下2つの文献が入門として非常に参考になった。この2つの文献を参考にしつつ、公式ドキュメントを追いかけながら作成していった。
Webpackを一歩一歩確実に理解してReact + TypeScript環境を作る - おじんブログ
動機 毎回 npx create-react-app で React アプリを生成していて Webpack の勉強から逃げていたが、いい加減向き合いたいと思ったため。 昔 Webpack に入門しようとしたら難しいという先入観を抱いたので、できるだけシンプルに、一歩一歩づつ入門する。 最終的に、React + TypeScript の環境を作れるようにする。 リポジトリ 各ステップごとにコミットしているので逐次さかのぼってください。 github.com 前提 最低限の yarn または npm コマンドの使い方がわかること。 npx create-react-app で React プロジェクトを作成した事があること。 ※VSCode 使用を前提としています。 Config なしで実行する 最低限の構成で Webpack が何をするのか理解する。 準備 # run at project
さようなら、TypeScript enum - 株式会社カブク
フロントエンドエンジニアの今村です。TypeScriptではenumを使わずunion型を使いましょう、という話を書きます。 モチベーション 何を今さら、と思う方もいるかもしれません。 TypeScriptのunion型はenum的なものを表現可能であり、基本的にenumよりもunion型を使うべき、という意識を持っているTypeScriptプログラマーはすでに少なからずいるのではないかと思います。しかし、ではenumの使用はいかなる場合も避けるべきなのか、そうでないとしたらどのような基準でenumとunion型を使い分けるべきなのか、といった点について、広く合意の取れたガイドラインはなさそうです（少なくとも私は知りません）。この結果、コードレビューなどで少しやりづらさを感じることがあったので、白黒つけてしまいたいという気持ちからこのブログを書いています。 結論としては、enumは全面的に
AWS CDKのTHE TYPESCRIPT WORKSHOPをやった - $shibayu36->blog;
AWS CDKについて学んでおこうと、https://cdkworkshop.com/20-typescript.html をやった。 CDKめっちゃいいやん今後絶対使っていきたいという感想 CloudFormationでは、IAMのロールをドキュメントをにらめっこしながら作って、そのロールをこのLambda Functionに付与して...みたいに結構難しく思いながらやっていたのが、CDKだと直感的に書き下せてよかった あるLambda Function AからLambda Function Bのinvokeを許可するとかだったら、funcB.grantInvoke(funcA); って書くだけで、いい感じにIAM Roleとか作って付与してくれる コード化されていて補完が効くため、ドキュメント見なくても出来そうなことが分かるし、定義ジャンプすると型定義にドキュメント載っている cons
TypeScriptのMap<K, V>をJSON.stringify()に食わせると空のオブジェクトになって困るんですけどって時 - その手の平は尻もつかめるさ
（TypeScriptに限らずJavaScriptでもだいたいこのような感じだと思いますが） 例えば以下のようなコードを書くと，出力としては {"body":{}} が得られます． const body = new Map<string, string>().set("foo", "bar"); console.log(JSON.stringify({body})); 本当は {"body": {"foo": "bar"}} のような構造がほしいところにこれでは困るわけですね． そこでどうするかと言うと Object.fromEntries() を利用すると良い: developer.mozilla.org 2019年11月現在だと比較的新しい機能ですね． const body = new Map<string, string>().set("foo", "bar"); console.l
README - TypeScript Deep Dive
I've been looking at the issues that turn up commonly when people start using TypeScript. This is based on the lessons from Stack Overflow / DefinitelyTyped and general engagement with the TypeScript community. You can follow for updates and don't forget to ★ on GitHub 🌹
サーバーレスでもユニットテスト – TypeScript 製 AWS Lambda を Jest でテストする | DevelopersIO
最近は Lambda Function を TypeScript で実装することが多く、テストツールとして Jest を選択しました。導入から基本的なテスト、カバレッジ出力までやってみたので、その手順を記録します。 ユニットテストのモチベーション 変更に対する心理的な安全性を手に入れるため、という理由が大きいです。 たとえば API Gateway のバックエンドを Lambda Function で実装する場合。実装だけであれば、可能な限り any 型を使用せず、 interface や type の有効活用によりデータ型に起因する実行時エラーは大幅に少なくできます。 TypeScript を使うメリットのひとつですね。ではサーバーレスならではの難しいポイントはどこかというと、私の場合 前作った Lambda Function の挙動をすぐ忘れる ということがよくありました。それで、 L
TypeScript再入門 ― 「がんばらないTypeScript」で、JavaScriptを“柔らかい”静的型付き言語に｜ハイクラス転職・求人情報サイト AMBI（アンビ）
TypeScript再入門 ― 「がんばらないTypeScript」で、JavaScriptを“柔らかい”静的型付き言語に JavaScriptプロジェクトでTypeScriptを導入する際には、“柔らかい”静的型付き言語とするのがおすすめです。藤吾郎（gfx）さんがまとめた「がんばらないTypeScript」のガイドラインです。 TypeScriptは、すべてのJavaScriptプロジェクトで採用する価値のある技術です。TypeScriptとこれに対応したエディタを導入することで、補完や型ベースの整合性のチェックにより、すべてのプロジェクトで生産性が上がります。またリファクタリングも容易になるので、長期あるいは大規模なプロジェクトでも品質を保ちやすくなります。 この記事では、TypeScriptについて最低限の知識とともに、サクッと（どちらかというと既存のプロジェクトに）導入するための
Google Apps ScriptsでTypescriptが超簡単に使えるようになった！ - アクトインディ開発者ブログ
morishitaです。 Cloud Functions と並ぶ(?)Google のサーバレスな JavaScript 実行環境といえば Google Apps Scripts（GAS）です。 GAS ってあの Excel で言う VB スクリプト環境のようなものでしょう？ と思ったあなた！ このエントリでその認識が変わると思います。 以前は使いやすいとは言い難かったGASですが、最近は使いやすくなってきました。 といっても、GAS 自体がアップデートされたのではなく周辺ツールが整備が進み開発・運用しやすい状況が整ってきたからです。 そして、なんと最近Typescript でとても実装しやすくなったので、それをご紹介したいと思います。 google/clasp 以前の GAS は Web エディタ上でしか実装できず、コードを VCS で管理することもままならない状況でしたが、Google
TypeScript で Google Apps Script を書く環境を整備する | Hori Blog
無料で自動化環境を整備できることで有名な Google Apps Script ですが、以前はブラウザで JavaScript を用いて開発する必要があったため辛い部分もありました（人による）。 現在は公式からローカル開発をするための公式 CLI ツールが提供されているので、静的型付けの恩恵を受けるべく TypeScript を用いて開発できるようにしてみました。 公式の CLI ツール G Suite Developers Blog: Advanced Development Process with Apps Script danthareja/node-google-apps-script: The easiest way to develop Google Apps Script projects インストール自体は Node.js が入っている環境であれば npm install
TypeScript 日本語ハンドブック | js STUDIO
このサイトについて TypeScriptのハンドブックを日本語に翻訳してまとめています。 GitHubのMicrosoft/TypeScript-Handbook の内容を参考に作成していますが、非公式で個人による作成物であるため、誤りがあると思います。その点についてはご了承ください。 もし、間違いを見つけましたら、 @tomof まで教えていただければ幸いです。 このサイトではGitHubのドキュメントを元に翻訳していますが、同じ内容のドキュメントがTypeScriptの公式サイトに公開されています。 Back to top © https://github.com/Microsoft/TypeScript-Handbook このページは、ページトップのリンク先のTypeScript-Handbook内のページを翻訳した内容を基に構成されています。 下記の項目を確認し、必要に応じて公式の
TypeScriptでのフロントエンド開発環境作成総まとめ - $shibayu36->blog;
これまで自分のブログで、TypeScriptを使ったフロントエンド開発環境についてブログをいくつか書いてきた。ひとまずこの辺りで、TypeScriptでフロントエンドを開発するための最低限の環境を構築できるようになったので、総まとめとしてブログエントリを書いておく。 今回のサンプルコードは https://github.com/shibayu36/typescript-project-sample/tree/4653cd002eef3ee1946a2ca1da344e0076b2844f に置いたので参考に。 これまでの記事 EmacsでTypeScript環境を整える - $shibayu36->blog; JSをbrowserifyでビルドし、ライセンスコメントを適切に残す - $shibayu36->blog; gulp + browserify + tsifyを利用してTypeSc
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to Test Your Microservices to Make Sure They Are Production Ready
TypeScript in Wantedly // Speaker Deck