AMPコンポーネントでLTS版指定orビルドバージョンを固定する方法(LTS or lock versions AMP components) - Qiita
AMPのLTS指定とバージョン固定する方法 AMPのマイナーバージョンにおけるアップデートはcdnファイル上書きで行われるため、AMPコンポーネントで予期しない不具合が発生した場合に、LTS指定する方法と過去のビルドバージョンに固定する方法をまとめました。(English versin: here) AMPコンポーネントでLTS版を指定する方法 最新のバージョンではなく、LTS（Long-Term Stable)版を指定する場合は以下のように、https://cdn.ampproject.org/lts/下のv0.jsとamp-carousel-0.1.jsなどのコンポーネントのjsを指定することができます。 - <script async src="https://cdn.ampproject.org/v0.js"></script> - <script async custom-ele
useReducerの本質：良いパフォーマンスのためのロジックとコンポーネント設計 - Qiita
React Hooksの正式リリース（2019年2月）からそろそろ一年が経とうとしています。Hooksの登場によってReactのコンポーネントは関数コンポーネントが一気に主流になり、クラスコンポーネントが新規に作られる機会は激減しました。 また、React 17.x系ではConcurrent Modeの導入とともにさらに2種類の新フックが追加される見込みであり、いよいよ関数コンポーネントの能力がクラスコンポーネントを真に上回る時代が来ることになります。 この記事では、フックの一種であるuseReducerに焦点を当てて、どのようなときにuseReducerが適しているのかを説明します。究極的には、useReducerによって達成できるパフォーマンス改善があり、ときにはそれがコンポーネント設計にまで影響を与えることを指摘します。 useStateの影に隠れたり、なぜかReduxと比較されたり
VO, DTO, POSO, DAO, Entity の違い - Qiita
はじめに try! Swift ではじめてDTO、POSOという言葉を聞いて、Entityとの違いとかよくわからなかったので調べてみた。 すると、類似の用語が5つでてきた。 VO (Value Object) DTO (Data Transfer Object) POSO (Plain Old Swift Object) JavaだとPOJO (Plain Old Java Object) DAO (Data Access Object) Entity いずれもシンプルに関連するデータをまとめたobjectだが、微妙に性質が異なる。 VO (Value Object) getterのみ 不変 DTO (Data Transfer Object) VO + setter 可変。外から変更可能 異なるレイヤー間（モデル層、ビュー層など）でデータを受け渡すのに使う POSO (Plain Old
NestJS - Qiita Advent Calendar 2019 - Qiita
NestJS についての情報を発信するための Advent Calendar です。アドベントカレンダー枠の譲渡は可能なので、 @potato4d および @euxn23 にご連絡ください。
NestJS の DTO と Validation の基本 - 型定義とデコレータで安全にデータを受け付ける - Qiita
この記事は NestJS Advent Calendar 2019 3 日目の記事です。前日は @euxn23 による Module と DI の話でした。 これまで NestJS のはじめかたと Module と DI の話をしていきました。3 日目となる本日は、もう少し実際の開発に身近な機能である、DTO と Validation について紹介いたします。 tl;dr NestJS にはコアに Request Payload の型定義とバリデーションの機能が備わっている クラスベースの型オブジェクト DTO の定義によって、 Request オブジェクトに触らずに受け付ける型定義ができる DTO にバリデーションを敷くことによって、 Controller のメインロジックより前の段階で不正なアクセスを弾ける リクエストデータの検証について Web API を構築する場合、リクエストのデ
触って覚える NestJS のアーキテクチャの基本 - Qiita
この記事は NestJS アドベントカレンダー一日目の記事です。 記念すべき一記事目ということで、今回は NestJS の基本的な構造について、概念を理解し、実際に触ってみるまでを紹介したいと思います。 NestJS の概念的な部分においての概要は下記スライドをご参照ください。前提知識として一読いただいた上で、手を動かしていただけると はじめに 実際の開発に入る前に、いくつか共有事項があります。 検証環境について macOS 上で、執筆時点での Node.js の LTS である v12.13.1 を前提とします。 この記事で学ぶことについて NestJS は非常に多くの機能を有しているので、今回は核となる一部の機能と実装例のみを紹介します。 具体的には、 CLI で初期化時に生まれる Service / Module / Controller だけで簡単な GET リクエストを返却する
GraphQL と N+1 SQL 問題と dataloader - Qiita
この記事ではハイパフォーマンスな GraphQL サーバを実装するのに避けて通れない N+1 SQL 問題について解説します。 TL;DR GraphQL は resolver を個別にかつ再帰的に実行していくため、 RDB のリレーションを効率的に先読みすることができません。そのため一般的に遅延読み込みを行います。 Facebook 社は GraphQL で遅延読み込みするために dataloader という npm パッケージを公開しており、各種言語にその移植版のライブラリが存在しているので、それを使って N+1 SQL 問題を抑制しましょう。 （復習）N+1 SQL 問題とは N+1 問題は「1 つの SQL で N 件のレコードをフェッチしたあと、それぞれ対して関連するレコードを個別にフェッチするのに N つの SQL を発行している」状態を指す言葉です。言葉で書いてもよく分からな
Apolloでの綺麗なAPI実装（GraphQL）を試す - Qiita
はじめに 今回のサンプルは以下に用意しました。 Apollo Server & Apollo Clientサンプル 以前こんな記事を書きました。 React(+Redux)+gRPCで実現するクリーンアーキテクチャ＋マイクロサービス構成 BFFのフロントエンドAPI部分に関して、次の記事を見てクライアント通信の部分をGraphQLで実装できるとより柔軟で堅牢な気がしたので試してみました。 世のフロントエンドエンジニアにApollo Clientを布教したい REST API、 GraphQLの違いに関しては下記を参考にしてください アプリ開発の流れを変える「GraphQL」はRESTとどう違うのか比較してみた GraphQLを導入するメリットはざっくり以下の通りです。 APIのインタフェース定義(送信パラメータのデータ型定義)ができる（それにともない、データの型定義によるAPIパラメータの
脱・Atomic Design - HTML+CSSコーディングの粒度分類法（HTML Parts） - Qiita
はじめに HTML+CSSコーディング専用の粒度分類を紹介します。 この仕組みは、デザインやワイヤーフレームなどの視覚情報を分解することに焦点をあて、分解した対象を部品化する流れも併せてガイド化した汎用手法です。 世の中には、コーポレートサイト / ポータルサイト / サービスサイト / システム管理画面 / ブログサイト… といった様々な種別のサイト、Webページがありますが、これらの「完成予想図（視覚情報）」を同じ方法で分解して、コーディング用の部品にできます。 粒度と言えばAtomic Designが有名ですが、この「HTML Parts」も粒度そのものの考え方についてはAtomic Designの踏襲です。その上で「思考の入り方・捉え方」や「名称と定義」をコーディング側に寄せることで、CSS設計やコーディング業務を標準化しやすくしています。 ※この記事は標準化ノウハウ公開の一環とし
IE11のサポートを切ると使えるようになるCSSとか一覧 - Qiita
Windows7のサポートが終了し、今後は動作対象にIE11を含めないことも増えるでしょう。 IEをサポートしないことにより、使えるようになるHTMLとCSSをまとめました。 JavaScriptはきりがないので調べてません。 Can I Useをもとにまとめています。 分かりやすいように簡単な説明をつけています。厳密に正しい説明ではありません。 『使いやすさ』は利用頻度が高そうなものを勝手にレベル付しています。 この記事は2020年3月に作成したのものです。 HTML rel=“noopener" リンク元の文書へアクセスできないようにすることをブラウザーに指示します。 これを指定しないと、target=”_blank”利用時にJavaScriptで元のページにアクセス出来てしまうので脆弱性に繋がります。
react-apollo と next.js を使った最速 GraphQLアプリケーション(+モックサーバー)実装 - Qiita
react-apollo を試しながらガチャガチャやっていると、モックサーバーなどを含め、なかなか体験が良かったので、紹介します。 こっちも参照 世のフロントエンドエンジニアにApollo Clientを布教したい - Qiita 今回書くコードの動いてる例は https://github.com/mizchi-sandbox/graphql-playground を参考にしてください。 git clone して yarn install; yarn start で動くはず。 ゴール 最終的にこんな感じのクライアント実装(next.js)が動くようになります。 import React from "react"; import { Query } from "react-apollo"; import gql from "graphql-tag"; const GET_USER = gql
2020年20年目を迎える IE6 に対応した SPA を TypeScript で作る - Qiita
現況 Internet Explorer 6 は 2001/8/27 にリリースされまして、ブラウザシェアは現在 0.01% となっております。 ちなみに2年前に調べた時は0.1%強だったのでかなり減っています。 使ったもの Lang: TypeScript UI: Hyperapp v1 i18n: i18next HTTP client: jQuery 1 CSS: Cascade Framework Icon: Material design icons Hosting: Google App Engine IE6 に対応することとは IE6 環境を用意する TypeScript を ES3 ベースに独自の実装を加えた JScript に変換する バージョン毎に実装が異なるスタイルと向き合う Web API を JSONP で作る TLS 1.0 に対応したサーバに設置する というこ
Storybookの新しいアドオン addon-docs がいい感じ - Qiita
Storybookのv5.2 で入る予定の新しいアドオン addon-docs を試してみたら、なかなかいい感じだったので布教記事を書きます。 実物はGitHub Pagesで公開しています。 https://y-takey.github.io/storybook_docs_example/ (リポジトリ: https://github.com/y-takey/storybook_docs_example ) addon-docs は (既存のアドオンである) addon-info をほぼ置き換える新しいアドオンで、従来のストーリー形式に加えて MDXも使えることが一番の特徴だと思います。上の画像のようなドキュメントを手軽に書くことができます。 MDXを使えることが理由で、 Styleguidist や Docz を選んだ人もいるんじゃないかと思いますが、これからは Storybook も
GraphQLの全体像とWebApp開発のこれから - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL;DR GraphQLはクライアント側とサーバー側の双方の複雑化を解決するために利用されてる フロントエンドにとってGraphQLはHTTP上で動く信頼できる唯一のリソースとして振る舞う フロントエンドの状態管理のベストプラクティスとしてのApollo Client クライアントファーストなAPI, GraphQLはWeb APIのベストプラクティスになり得る クラシックアプリケーションを改修することなくGraphQLとモダンフロントエンドで今どきのアプリを作れる はじめに GraphQLは非常に良く出来たソフトウェア(の仕様)です
プロジェクトリーダーというお仕事 - Qiita
たとえば、詳細設計から結合試験までを行う場合なら、 13sp + 13sp + 13sp + 19.5sp = 58.5sp と計算します。 スクラムでやるなら1スクラムあたり何sp消化できるか、ウォーターフォールなど日数を見積もりたい場合は、そこから1spが何人日かを予め定義しておいて、実際の工数を割り出します。 (1スプリントで10sp消化できるとした場合は6スプリントかかる計算になるし、1sp=0.5人日とした場合は、29.5人日≒1.5人月となります) なお、この比率は求められる品質レベルから算出します。 たとえばドキュメントをかっちり書く必要があるのなら設計の比率を上げる必要がありますし、メモレベルでよかったり、GitのPullRequestなどに記載する程度でいい場合は比率は下がるでしょう。テストの工数も同様です。なお、上記のは「ある程度かっちりやる」場合の比率です。 比率を算
Next.js 9.3: 新世代の静的サイト生成、Built-in Sassのサポート - Qiita
本日、Next.js 9.3 がリリースされました。本リリースの特徴は次のものです。 Static Site Genration のサポート プレビューモードのサポート ビルトインの Sass サポート 404 ページの静的化 ランタイムの縮小 各トピックごとに簡単に説明します。詳しく知りたい場合は公式のリリースノートが公開されているのでご確認ください。 Static Site Generation のサポート Next.js では 9.0 から Automatic Static Optimization というコンセプトを打ち出し、getInitialPropsでデータを取得しない場合はビルド時に HTML ファイルを生成していました。（また、getInitialPropsでのデータ取得はnext exportで生成した場合であっても、クライアントのルーティング変更時に実行されるため、完
styled-components（CSS in JS）をやめた理由と、不完全なCSS Modulesを愛する方法 - Qiita
styled-components 画像は styled-components ツライっていう顔です。 Angularのようにスタイリングまで面倒を見てくれるUIフレームワークならまだしも、Reactの場合はコンポーネントのスタイリング方法も自身で選択しなければいけません。CSSのスタイリング方法/設計はいくつか存在しますが、どれも一長一短で、やはり銀の弾丸は存在しません。スタイリング方法を選択可能なUIフレームワークは、この混沌とした選択肢の中から価値を見出す必要があるわけです。 僕はBEMによる人力CSS管理（Sass/Less/Stylus）から、 { fontSize: 14 } のようなJSオブジェクト形式のCSS in JS、 styled-components のようなTemplate Stringsを利用したCSS in JS、そしてCSS Modulesまで幅広く公私とも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
依存性注入(DI)の解説とやり方 - Qiita
TypeScript3.4 の const assertion - Qiita
Get started Express + TypeScript する - Qiita
