BASEにおけるVue.jsのこれまでとこれから - BASEプロダクトチームブログ
前書き こんにちは、BASEのフロントエンドチームでエンジニアリングマネージャーをやっている松原(@simezi9)です BASEではフロントエンドエンジニアの積極採用を行っています。 その過程で、面接を受けに来られた方によく「BASEはVueとTSを採用しているとのことですが、相性がいまいちじゃないですか？なんでVue＋TSにしてるんですか？」 という感じの質問をいただくことがあります。 この記事は、そんなBASEのフロントエンドにおける、技術・・・というよりもVue.jsに対するスタンスについて嘘偽りなく答えてみよう、という記事になります なぜVueを採用したのか、その後 過去にも「次世代の管理画面を作るフロントエンドの取り組み」というエントリでVueを採用した経緯には軽くご紹介させていただきました。 それは端的に言えば「HTML/CSSを書いてきたデザイナー陣にも見た目がとっつきやす
TypeScriptの型エラーを踏み潰すときのお作法 - Qiita
TypeScriptは、型の合わないプログラムに対して型エラーを出すことを主な役目としています。 もちろんプログラムを正しく修正すれば型エラーは消えるのですが、TypeScriptを書いている方ならばそれ以外の方法で型エラーを消したことがある人がほとんどでしょう。すなわち、as、any、// @ts-ignoreその他諸々です。このような手段を使うことで、本来の問題を解決せずに型エラーを消すことができます。 もちろんこれらを濫用するのは勧められたことではありません。それは筆者の過去の記事『敗北者のTypeScript』で解説した通りです。プログラムの修正でasなどを使わずに型エラーが消せるのならばそうすべきで、そうしないのは敗北者です。 しかしながら、asなどをどうしても使わなければいけない場面はあります。それは、TypeScriptの型推論能力や型の表現力が足りないために型エラーが出てい
吾輩はバグを出す 〜Mapped typesでミス対策〜 - Qiita
ある日、某システム会社にて ワイ「カタカタカタカタ・・・」 ハスケル子「やめ太郎さん」 ハスケル子「さっきから一生懸命、何を書いてるんですか？」 ワイ「小説や」 ワイ「これで一発当てて、会社なんて辞めてやるんや・・・！」 ハスケル子「へえ〜、それは凄いですね（棒読み）」 ハスケル子「ちょっと読ませてくださいよ」 ワイ「ええで」 ハスケル子「ええと、タイトルは」 ハスケル子「・・・吾輩はバグを出す・・・？」 ハスケル子「なるほど」 ハスケル子「ノンフィクション小説ですね？」 ワイ「どういう意味やねん」 ワイ「フィクションや、フィクション」 仕事をしろ ハスケル子「それよりやめ太郎さん」 ハスケル子「今日から新しい仕事が始まりますよ」 ハスケル子「株式会社ジャンケンポンさんの、コーポレートサイトを作るお仕事です」 ワイ「ああ、せやったな」 ワイ「どんなサイトを作るんやったっけ」 ワイ「仕様書を
TypeScriptの型演習 - Qiita
この記事は、TypeScriptの型を使いこなすための演習として、TypeScriptの型に関する練習問題を提供する記事です。解いて自分のTypeScript力を確かめてみましょう。 問題のレベルは、筆者の既存記事「TypeScriptの型入門」「TypeScriptの型初級」を完全に理解した人なら全部解けるという想定で作られています。記事を読んでいない人が腕試しに解いてみるのも問題ありません。また、記事を読んだけど全部は理解していないという場合でもご安心ください。解ける問題はありますから、ぜひ挑戦してみましょう。 問題は20問あり、4段階の難易度別に分かれています。同じ難易度帯の問題は思いついた順で並んでいるので、後のほうが難しいわけではありません。問題は執筆時点の最新版のTypeScript（TypeScript 3.3.3333）で--strictオプションありの状態で動作を確認して
レイヤードアーキテクチャ - kawasima
POSAでの定義 レイヤードアーキテクチャを、体系だって書いたのは「Pattern-Oriented Software Architecture, Volume 1, A System of Patterns」だろう。まずはその原典に立ち返って、レイヤードアーキテクチャとは何かをみてみる。 コンテキスト ソースコードの変更がシステム全体に波及させたくない。それが1つのコンポーネントに閉じられ、他に影響を与えないようにすべきだ。 インタフェースは安定している。標準化団体によって規定されている場合もある。 システムの一部は交換可能である。コンポーネントはシステムの他の部分に影響を与えることなく、実装を入れ替えることができる。 現在設計しているシステムと同様の下位レイヤの課題をもつ他のシステムを、将来構築することがあるかもしれない。 理解のしやすさと保守性のために同じ責務はグルーピングしておきた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
体系的に学ぶ 安全ではないWebアプリケーションの壊し方 - ニート向けソフトウェアエンジニアリング塾