渡くんの××が崩壊寸前(7)

石原さんのお母さんが二人を別れさせようとするのは予想通り。ただ、渡くんの身の上話を聞いて、健全なお付き合いなら OK と譲歩したのは意外だった。もっとモンスターでも面白かっただろうに。怖いもの見たさな意味で。そんな石原さんのお母さんが、二人が今付き合うことに反対する原因に少し関係している徳井は、過去に何があったんだろうな。

梅澤は個人的に好きなキャラなんだけど、報われない感アリアリ。というか渡くんから恋愛対象として見られていない感じだ。女の子とは認識されているみたいだからセーフ(?)。渡くんにアプローチを試みるも、結果的に渡くんの背中を押してしまう形になってしまうあたり不憫だ。

石原さんは渡くんの良い彼女になろうと奮闘するも、それが結果的に渡くんを試すような形になってしまっているな。暴走ぎみ。沙月の存在が影響しているのは間違いない。まぁ、心穏やかにはいられないわな。沙月との関係を試されることになった渡くんは、次巻で沙月の両親に会いにいくんだろうか。過去の事件の真相が明かされるのを期待してしまう。

WEB+DB PRESS Vol.109

特集1 最新CDN入門

CDN で今一番勢いがある Fastly について知ることができて勉強になった。 Fastly ではキャッシュのパージが 200ms で完了するのか。 よほどリアルタイム性を求められるものでなければ、適用できるパブリックコンテンツは多そうだ。

ただ、仕事で携わってるサービスが返すのはプライベートなコンテンツばかりなので、CDN を活かせることは当分なさそう。個人開発では Netlify 使ってるから、CDN の恩恵を受けているといえば受けているな。

個人開発だと、キャッシュよりも関心があるのは Lambda Edge や Cloudflare Workers といったエッジコンピューティング。CDN のエッジで Server Side Rendering とか出来るようになれば…。夢が広がりまくり。個人開発で試してみたい。

特集2 実践 Kotlin

Kotlin は実用性を重視した言語という印象。Java の資産が使えるだけでなく、プロジェクト内で Java と Kotlin のコードを共存できるとかもう反則。

Spring Framework が Kotlin に対応したので、サーバーサイドを Kotlin で開発するのは選択肢として十分アリ。クライアントサイドは、Android アプリの開発言語として Google に認められたし、 Kotlin Native で iOS や Web まで視野に入れていて野心的だ。

サーバーサイドとクライアントサイドを1つの言語で開発する Kotlin 大統一理論をどこかが実践するかもな。

特集3 速習 Puppeteer

今 React でフロントエンドを開発していて、ヘッドレス Chrome を使って正常系のインテグレーションテストを書きたいと思っていたので、タイムリーな特集だった。

ページ遷移など待機が必要なコードが async/await のおかげでかなり書きやすくなった印象。

at the front 【第3回】作家/プログラマー 結城浩さん

結城氏の本やコラムは読んだことあるけど、インタビューを受けている記事は初めて読んだ。

結城氏の本だと、この業界に入った当初に読んだ『Java言語によるデザインパターン入門』が印象深い。非常に読みやすい本で、読者のことを徹底的に考えたからこそ到達できた読みやすさだったんだろうな。

自分も数学をちゃんとやり直したいという思いは燻り続けていて、 数学ガールシリーズは一巻(?)しか読めてないので、 財布に余裕ができたら秘密ノートあたりから読んでいきたい。

WEB+DB PRESS Vol.109

WEB+DB PRESS Vol.109

  • 作者: 佐藤歩,加藤賢一,原一成,加藤圭佑,大塚健司,磯部有司,村田賢太,末永恭正,久保田祐史,吉川竜太,牧大輔,ytnobody(わいとん),前田雅央,浜田真成,竹馬光太郎,池田拓司,はまちや2,竹原,原田裕介,西立野翔磨,田中孝明
  • 出版社/メーカー: 技術評論社
  • 発売日: 2019/02/23
  • メディア: 単行本
  • この商品を含むブログを見る

create-react-app で .env.staging に記述した環境変数を使うようにビルドする方法

まず env-cmd をインストール。

yarn add env-cmd

ステージング環境用の環境変数を記述した .env.staging ファイルを用意。

REACT_APP_BASE_PATH="https://testapi-staging.example.com"

React アプリ内では process.env を使って環境変数を参照しておく。

const basePath = process.env.REACT_APP_BASE_PATH;

package.json の scripts に、ステージング環境用のビルドを行うスクリプトを追加。

{
  "scripts": {
    "build": "react-scripts build",
    "build:staging": "env-cmd .env.staging npm run build"
  }
}

あとは

yarn build:staging

でビルドすれば、.env.staging に記述した環境変数が埋め込まれた JavaScript ファイルが出力される。

GraphQL と CQRS

C# で GraphQL.NET を使って GraphQL API のサンプルをいくつか書いてみたわけだけど、 クエリのリゾルバは Entity Framework Core の DbContext を使ってデータを取得するように実装するのが、開発効率考えると現状一番良さそう。クエリはネストできるし、その時 N+1 問題対策で DataLoader を使うことになるだろうから、規模が大きくなってきても DbContext 直のままで行けそうだ。

一方でミューテーションのリゾルバでは、サンプル程度ならこちらも DbContext を直に使って登録や更新をすればいい。ただ、こちらは規模が大きくなってくると DbContext だけではツラくなる。 参照と違って登録や更新はドメインロジックが入ってくるから、ユースケースを実装してリゾルバから呼び出す形になっていきそう。

…って書いていて思ったんだけど、これってコマンドクエリ責務分離(CQRS)だよな。 クエリは DbContext (というか IQueryable)に対し、ミュテーションではユースケース。ミューテーションはコマンドに相当するわけだ。 CQRS 脳になって、クエリスタックとコマンドスタックに分けて考えて実装するといいのかもしれない。

五等分の花嫁(8)

三玖と一花による風太郎争奪戦にニ乃が本格参戦。面と向かって告白し意識させている時点で、3人の中ではニ乃が一歩リードか。風太郎みたいなヤツには、押しが強い二乃みたいなタイプが合うような気がする。

一花は三玖と二乃の板挟みになって、ちょっと不憫だった。長女だからと遠慮してしまいがち。そんな気持ちなんてつゆ知らずな恋の暴走列車・二乃の攻勢によって涙目になった一花だったが、四葉のファインプレーによって復調したみたいでよかった。個人的には一花推しなもんで。

さっき 3 人の中で二乃が一歩リードと言ったな。あれは嘘だ。もしかしたら本当にリードしているのは三玖かもしれない。五つ子全員が五月に変装する五月の森で、風太郎が正体を唯一見破ることができた相手が三玖だから。四葉?分かりやすすぎてノーカンで。

相手の仕草・声・ふとした仕草でわかったのだから、それはもはや愛と言えるのかも。

五等分の花嫁(8) (週刊少年マガジンコミックス)

五等分の花嫁(8) (週刊少年マガジンコミックス)

mapStateToProps で Props にマップした値を mapDispatchToProps 内で利用したい人生だった

例えば、アクセストークンを Redux のストアに保存していて、そのアクセストークンを使って Web API を呼び出したい。 アクセストークンを受け取って Web API を呼び出すアクションおよび ActionCreator は既にあるとする。

Redux のストアで管理しているステートからコンポーネントの Props にアクセストークンを渡すのは、mapStateToProps でやればいい。 Web API を呼び出す ActionCreator を dispatch する部分は、mapDispatchToProps で書きたいところ。 ただ、mapDispatchToProps 内では mapStateToProps で Props にマップした値を取得できない。 気を利かせて、ownProps に渡してくれたらよかったのに。 さて、どうしよう。

救世主は、connect が受け取る 3 番目の引数、mergeProps だった。 mapStateToProps が返したオブジェクトである stateProps、mapDispatchToProps が返したオブジェクトである dispatchProps、 そして ownProps を受け取り、3 つをマージしたオブジェクトを返す。 mergeProps 内なら、mapStateToProps でマップしたアクセストークンが stateProps から取得できるので、 そのアクセストークンを使って Web API を呼び出すアクションが dispatch できる。

こんな感じで。コードは TypeScript。

import React from 'react';
import { Dispatch } from 'redux';
import { connect } from 'react-redux';

import { AppState } from './reducers';
import { callWebApi } from './actions';

interface IndexPageProps {
  dispatch: Dispatch;
  token: string;
  onLoad: () => void;
}

class IndexPage extends React.Component<IndexPageProps> {
  componentDidMount() {
    this.props.onLoad();
  }

  render() {
    return (/* 本題ではないので省略 */);
  }
}

// アクセストークンを Props にマップ
function mapStateToProps(
  state: AppState,
  ownProps: IndexPageProps
): IndexPageProps {
  return {
    ...ownProps,
    token: state.login.token,
  };
}

// mapStateToProps でマップした値を使うアクションを dispatch する処理は、
// mapDispatchToProps で書かないでおく
function mapDispatchToProps(
  dispatch: Dispatch,
  ownProps: IndexPageProps
): IndexPageProps {
  return {
    ...ownProps,
    dispatch,
  };
}

function mergeProps(
  stateProps: IndexPageProps,
  dispatchProps: IndexPageProps,
  ownProps: IndexPageProps
): IndexPageProps {
  return {
    ...ownProps,
    ...stateProps,
    ...dispatchProps,

    // mapDispatchToProps ではなく mergeProps で実装する
    onLoad: () => {
        // mapStateToProps で props にマップしたものは
        // stateProps から取得できる
        const token = stateProps.token;

        // mapDispatchToProps で props にマップしたものは
        // dispatchProps から取得できる
        const dispatch = dispatchProps.dispatch;

        // mapStateToProps でマップしたデータを使って
        // アクションを dispatch できる
        dispatch(callWebAPI(token));
    },
  };
}

export default connect(
  mapStateToProps,
  mapDispatchToProps,
  mergeProps
)(IndexPage);

からかい上手の(元)高木さん(4)

4巻では西片くんの出番が激増。家族3人での回も多かった。 それにしても西片くんは良いお父さんやってるな。 もちろん(元)高木さんも良いお母さんやっているんだけど、 ついつい、西片くんを自分、ちぃを自分の娘に重ねてしまう。

西片くんとちぃの父娘タッグで(元)高木さんに挑む回が特に印象深い。 西片くんは娘と良い関係を気付けているみたいで、 自分も娘から頼られる父親でい続けたいもんだ。 なんでか、いじられキャラになってしまってるんだよなぁ。 現実はマンガのようにはいかない。