何もかも自信がなくなった。憧れてるエンジニアの人と面談をした。ブログを読んでくれたり、頑張ってるのを見てくれてた人がいるんだと嬉しい気持ちになった。8月ゆっくりすることにした。音楽を聴いたり、花を飾ったり、本を読んだり、ご飯をちゃんと作るようにした。時々見かける子供とお母さんの会話をぼんやり聞いたりした。設計含めてフロントエンド開発することになった。ReactもTypeScriptもはじめてやる。既存railsアプリにreactを導入した。webpackerいれるか考えたりした。(いれなかった)10月サーバー側のデータをフロントでどうやって取得しようか悩んだりした。form送信できない...CSRFトークンとは?ってなった。boxコンポーネントのPRを出した。入社後、なんとなくReactとTypeScriptを先輩のコードを参考に書いてたけど、これじゃだめだ!と思って、朝活を始める。TypeScriptの勉強を毎日することにした。会社の人に慣れてきた。先輩が設計に関してPRを出してくれた。リリースまで12月までにできなかったけど作りきった。会社の人に心を開いてきた。Rails)今年は、ブラウザについて勉強しました。仕組みが分からないともやもやして先に進めない性格なので、ブラウザについて勉強したのは、とても良い経験になったように思います。the-super-tiny-compilerを教えてくれたので、コードリーディングしたり写経したりしました。Designについても勉強してみたり。来年は、興味のある分野についてもっと勉強していき、自分の強みを見つけることができたら、なんて思ってます。PAGEを作ったり、ポートフォリオを作り直したりしました。Reduxを使ったアプリを作りたいなあと思ってるのですが、サーバー構築に対して苦手意識があるので、来年はその辺りも含めて何か作ってみたいです。BLOG12本書きました。(その内1本は音楽について)以下の3つは書いてて楽しかったブログ。MAPを計測Webを見ているときに起きていること今年は、Web、ブラウザについての記事を多く書きました。去年は15本書いているのですが、内容的には濃い内容を今年は書いている気がするので、来年もこの調子でアウトプットしていきたいです。今年はけっこう本を読んだ気がします。就活してたときに、説明会でもらった道をひらくって本、改めて読むととても滲みました。ヘッセのアヤメという短編が今年の一番です。Apartという京都のバンドのアルバムが冬にリリースされました。大学生の頃からずっと待っていたのでなんだか感慨深いです。個人的にDIIVの新しいアルバムが衝撃でした。2020今年は本当に辛かったです。辛かった分、得たことも多かった一年のように思います。辛かったこと、得たこともしっかり受け止めて来年もまた少しずつ頑張れたらいいなあ、と思っています。来年は自分の得意領域を見つけ、深堀りして行ったり、成長を実感できるような年にしていきたいです。2020年も宜しくお願いします。TypeScriptを読んでいるので読書メモです。単行本(ソフトカバー)この商品を含むブログを見る私の知らなかったことをたくさん書いてます。tsconfig.jsonTypeScriptコンパイラーの設定ファイル。true}targetトランスパイル後のECMAScriptのターゲットバージョン。ライブラリの型定義を利用するnpmで配信されているライブラリには、TypeScriptの型定義が存在するものとしないものがある。TypeScriptの基礎TypeScriptのもっとも基本的な用語の呼称・利用方法についての章。計算の途中、数値が文字列に変換されてしまいNaNが返ってくる関数戻り値に型注釈(アノテーション)を付与。明示的に戻り値を制約。型注釈と定義内容に型不整合がある場合はコンパイルエラーを得ることができる。基本の型(私の知らなかった型をまとめてます。固定数の要素がわかっている配列を表現できる配列の要素ごとに型が違うデータ型が定義できる。型の不明な変数を扱うことがある場合に使用することで型チェックを無効にし、コンパイルを通過させるTypeScriptの恩恵を受けることはできないので、できる限りany型が現れないコードを書き、型安全なプロジェクトを目指す。unknown型any型に似ているが、型安全なanyを表したいときに利用するvoid型any型の反対のようなもの。型が全くないことを表す。Types(共用体)は複数の型のうち一つの型が成立することを示している。アサーション任意の型に変換することができる。型アサーションは2種類の書き方がある。列挙型enumを使用すると、列挙型を定義できる。TypeScriptの型安全バグを減らすことはTypeScriptを導入する大きな理由の一つであり、TypeScriptを使いこなすようになるほど、絞り込むという作業がバグを減らす上でいかに重要な作業かということに気づくらしい。制約による型安全アノテーションを用いると、引数や変数定義において、誤った値の代入を防げる。TypeScriptの型システムバグを減らすことはTypeScriptを導入する大きな理由の一つ。TypeScriptを使いこなすようになるほど、絞り込むという作業がバグを減らす上でいかに重要な作業かということに気づくらしい。型の互換性any型の互換性どんな型にも宣言・代入できる。any型は、どのように扱おうとも危険な型unknown型の互換性unknown型は、どんな型の値も受け入れることができるTopTypeであり、型の中でもっとも抽象的な型。any型とは異なり安全に扱うことができる型unknown型の値はどんな値なのか分からないため、できることが制限されている。(任意の値を代入できる点はany型と同じ、型アサーション等が無いと利用できない。型に互換性がありため、いずれもコンパイルエラーにはならない。{}という型はオブジェクト以外も受け付けてしまう。TypeScriptの高度な型GenericsGenericsを用いると、型の決定を遅延できる。>の内側に型指定をすることで、導かれる型推論を可変にできる。基本的な付与Genericsを利用する型を宣言する場合、型名称に続いて<T>のようにT型をエイリアスとして指定する。Kなどの型エイリアス名称が利用されることが多い。Number型ではない実践TypeScriptの読書MEMO2に続きます。聴いたもの音楽2019年の上半期によく聴いた、印象的だった音楽について。思ったのがいくつかあるので以下に。youtu.beopen.spotify.comノルウェー出身19歳の宅録女子らしい。「なんとも言えない不安な気持ちとか、自分は誰であるかというアイデンティティの揺らぎとか、そういった気持ちに根ざした恐怖感を表現したかった」ということらしい。open.spotify.com知り合いに教えてもらった。甘ったるい感じに歌う声が好きです。www.youtube.comここ最近で一番衝撃的な新譜でした。言葉とサウンド(メロディ?音?)が究極に美しいです。Everythingは特に綺麗。open.spotify.com高揚感に溢れます。open.spotify.com高熱でぼんやりしてるときって夢でよく京都での大学時代の夢を見るなあと思いながら聴いています。最近聴いて印象的だったもの。open.spotify.comopen.spotify.comopen.spotify.comopen.spotify.comopen.spotify.comopen.spotify.com音楽は相変わらず毎日聴いているし、何か聴いていないときの方が少ないのではないかってくらい聴いています。自分から何か探すことは減ってきていて、Spotifyが勧めてくれるおすすめの音楽を聴くことが多くなったかもしれないです。あとは、今まで好きだったバンドの新譜とか、そういうものばかりを聴くことが多かったです。2019年ではないけど、ここ最近で読んだ本、漫画についても。見るあんまり、楽しい小説は読んでいなくて、言葉の綺麗な小説を探して読んでいました。好きな話のひとつになりました。あとはスラムダンクを読みました。ここ最近はこんな感じです。なんだか疲れているような感じで、いろいろと立ち止まってみるのもいいのかもしれない。思ったりする日々です。音楽を聴いたり、ご飯を丁寧に作ってみたり、花を生けたり、好きなお茶を選んで淹れてみたり...夏休みのつもりでのんびりしています。夏休みが終わったら、また頑張れるだろうか。何が起こっているかわかる限り説明してみてください。いう問題に15分何も見ずに考えてみるというのを以前(2月くらい?)やってみたので、そのMEMOです。何もブラウザに関して勉強せず、15分考えてみた予想(結果)は以下です。チューニングを読んでブラウザのレンダリングの仕組みについて学んでみました。勉強後、同じように15分何も見ずに考えてみた結果が以下です。何が起こっているかわかる限り説明してみてください。ブラウザに関する知識が身についた感触があります。ブラウザに対して興味を持ったので、今後はネットワークやコンパイル、レイアウト、ラスタライズ等の自分の興味を持った分野に対して深掘りしていき、この問いに対しては定期的に考えてみたいなあと思っています。TILについて&どのようにやっていくかを考えてみました。WHY何かを毎日アウトプットする習慣をつけたい。毎日の気になったこと、覚えたこと、新しく気付いたこと、学んだことをどんな形でもいいからアウトプットしたかった。Github上にTILというリポジトリを作成してそこに今日覚えたことを書いていく。(githubで検索するとtilというリポジトリがけっこう見つかる)塵も積もれば山となるみたいな感じ。https://syossan.hateblo.jp/entry/2016/02/16/144305実際のリポジトリhttps://github.com/jbranchaud/tilカテゴリごとにディレクトリを作成し、勉強した内容などをmdファイルでまとめている。HOWhttps://aloerina01.github.io/blog/2019-03-22-1↑を参考に何か読んだり考えたりしたらそのログをIssueに残すブログに書くほどじゃないネタを雑にIssueにまとめるちょっとした実装を日付毎のディレクトリにCommitするという感じでやっていく。毎日アウトプットする習慣を作ることが目的なのでブログに書いてある通りかなりハードルを低くして、やっていく。github.com5月中旬からはじめて、毎日続いているわけではないのですが...毎日コツコツ小さなアウトプットをしたいと思っているのでこのブログで意思表明です。17:10毎日の小さなアウトプットTweet広告を非表示にするもっと読むコメントを書く2019-05-11ソフトウェアテスト技法ドリルを読みましたプログラミング最近、担当している機能のリリースしたのですが、リリース後のバグが多く...テスト設計やテストケースの洗い出しがきちんとできていなかったと実感しました。会社のテストエンジニアに相談したらソフトウェアテスト技法ドリルをおすすめしてくれたので読んでみました。個人的に重要だと思ったところ&知らなかったことをまとめてます。どんな本テスト技法の正しい使い方が実践的に学べるテスト技術者向けに、テスト設計および実施のノウハウを披露し、解説している本。一連の流れとは、テストの視点・観点といった「点に注意を向ける」といった話から、テストの目的の一つである品質に関する情報を提供する「多次元の品質」まで目的テスト技法の正しい使い方や一連の流れを学ぶことで、実践的にテスト設計できるようになる。境界値に関係するバグは数が多い境界値、端っこにはバグが隠れている可能性が多い。面で逃さない1〜2章は主にデータに焦点を当ててテストを減らす方法についてソフトウェア自体はデータからなるのではなく、ロジック(論理)の塊から構成されている。ロジックとは入力の組み合わせによる特別な動作。ソフトウェアの入力が系統的にロジックを網羅し、正しく動作することをテストするテクニックを身につける必要がある。offを変化させ、他の変数についてはすべてinにしておけばその変数のon/offポイントを確実に評価することができる。原因結果グラフ条件が多くなると大きなデシジョンテーブルを作成する必要がある。立体で捉える新規機能追加機能によってこれまで表にでてこなかった母体のバグが魔物のように目を覚まし、バグとなって顕在化することがある関連性を効率的にテストしていく必要がある。ソフトウェア自体は3章と同様に2次元で考えて、そこに組み合わせるべき「要因を選ぶ目線」を追加し立体で考える。一般にソフトウェアは各機能に対して、それぞれを独立してつくろうと努力し開発されるもの。実際はどこかで意図しない関連性が生まれてしまう。いう事実に基づいてテストケースを作成する方法。https://qiita.com/greymd/items/ad18aa44d4159067a627まとめ複数の要因に倫理関係がない場合。要因が直交している場合のテスト技法について。時間を網羅する普段まったく問題なく動作しているソフトウェアが何気ないタイミングで動かなくなる問題について、状態遷移の観点と並列処理の観点からテストによる対応を考える。状態遷移テスト浅く全体を確認するテストから深く詳細にテストするものがある。時間を意識したテスト設計について考える状態遷移テスト状態遷移図を書いてみる→状態遷移図から、適用不可のイベントを見つけることは困難。状態遷移表を書き、適用不可(N/A)を含め、セルの一つひとつの動作をテストすることで基本的な状態遷移のテストを実施することができる。Nスイッチカバレッジ壊れた内部的な問題の顕在化方法について考える。最初に遷移前の状態を列方向に、遷移後の状態を行方向にならべた状態遷移表を作成する。技法は上記の通りだが、実際の製品に適用しようとした瞬間に困難にぶつかる。外の世界の状態に分けて考える組み合わせテストの延長線上として捉えることができる。人間の構造は現有のどのようなソフトウェアよりも複雑な構造をもっている。ソフトウェアより複雑な構造をもつ人間のテストについて考えてみればソフトウェアテストへの糸口が見つかるかもしれない。とテストの複雑度を増やしてきた。人間に対するテストと比較することで、適切な時期に適切なテストを行うことが大切。テスト対象は一般的に複雑なので、さまざまな視点から眺めるということをする。さまざまな視点から眺めるということは多次元である。一つの方向から眺めただけでは、決してその姿は想像できない。さまざまな視点でテスト対象をテストすることが重要シナリオテストわざとちょっと変わった行動や失敗を犯すシナリオをつくり、そこから回復させながらユーザーのしたいことを継続させるようにする視点の爆発を狭く深く追うことでカバーWhen,Where,Whoを明確にする固定名詞や定数値を使う例外処理シナリオ受け入れテスト受け入れるユーザー側でのテストサンプリングテスト品質を保証する統計的テスト信頼性を確認するための統計的テスト最後に(まとめと感想)テスト技法の奥深さを感じました。テスト技術者のものの見方とは、「部分的ではなく全体・包括的に複数を捉えること、手段ではなく目的に目を向けること、企業ではなくお客様の目線で考えること、独立ではなく相互関連性を発見すること、構造に加え振る舞いを評価すること」この一文が印象的でした。今までテストについて真剣に向き合ったことがなくて、とりあえず書いてみるみたいなことをしていたので、テストを書くときに何を考えるか、とか仕様書の読み方はあまり意識していなかったなあ、と反省しました。あと、PICTは実際に手を動かして使ってみました。(テスト工数を半分以下に減らせそう...!)テスト設計やったことなくて、テストってなんだろう?テスト設計って?な人は読んでみるのをおすすめします。View1-2番目のリクエストでドキュメント本体と/maps/_/js/k=maps.m.ja.D61iS2cbkq4.O/m=sc2,per,mo,lp,ti,ds,stx,bom,b/rt=j/d=1/rs=ACT90oGu35TczZS12uUzu-2-Uu94YaAN7wというjsを読み込んでいる。このjsでDOMを生成しているっぽい(中身にdivやcssの記述があるので)3-23番目のリクエストで最初に表示される地図画像が読み込まれている。地図画像は正方形に分割されていて、最適化されている。合わせてjsとfontも読み込まれている。jsは地図上に表示される座標データ24-30番目のリクエストでmanifest.jsonとGoogleのアイコン画像が読み込まれている。31-48番目以降のリクエストで地図に必要なアイコン画像、記号画像などを読み込んでいる。max-age=0ブラウザにキャッシュさせるけど、変更ないか都度確認するようにしてるquic使用している。jsとcssを記述している最初に読み込む必要最低限なものだけ最初に読み込むまとめ初期表示を速くするために、必要最低限のリソースを最初に読み込み、スクロールして見える地図部分などは遅延読み込みをするように工夫し、最適化をしている。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。