Hikaru Wada

鹿港 / 摸乳巷#GraphQL #Fragment_Colocation #Fragment_MaskingFragment ColocationとはReactのアプリケーションでGraphQLを使うときに使われるテクニックの一つです。Fragment Colocationによって、データのフェッチ処理と、データをコンポーネントに描画する処理を分離できることなどがメリットです。詳しくはこちらも参考にしてください。実装例を見てみます。なお、本記事のコードは関係の深い部分のみを抜粋したものになりますので、importや足りない部分を調整してください。code:Pokemon.tsx gql(`   fragment Pokemon on Pokemon {     number     name     image   } `);  export const Pokemon = ({ pokemon }: { pokemon: PokemonFragment }) => {   return (     <div>       <a href={/pokemon/${pokemon.number}}>         <h3>{pokemon.name}</h3>         <img width={100} height={100} src={pokemon.image} />       </a>     </div>   ); };実装時のポイントは、Fragmentの定義の側にそのFragmentをPropsとして受け取るコンポーネントを配置（colocate）することです。PokemonFragmentのような型を自動生成するのにGraphQL Code Generatorを使っています。PokemonコンポーネントはPokemonFragmentをPropsで受け取りJSX.Elementを返しますが、データの取得方法に関する詳細が書かれていません。このようにデータの取得と描画を分離することで、このコンポーネントの保守性が上がります。ただし、この書き方ではFragment Colocationを強制することができません。具体的には以下のようにデータの取得する場所でもFragmentのフィールドにアクセスすることができてしまいます。code:index.tsx const PokemonsQuery = gql(`   query pokemons($first: Int!){     pokemons(first: $first){       id       ...Pokemon     }   } `);  const Index = () => {   const data, fetching, error } = useQuery({     query: PokemonsQuery,     variables: {       first: 151,     },   });      return (     <ul>       {data?.pokemons?.map(         (pokemon) =>           pokemon && (             <li>               {/* Pokemonコンポーネントの外でPokemonFragmentのフィールドにアクセスできてしまう */}               <h2>{pokemon.number}</h2>               <Pokemon pokemon={pokemon} />             </li>           )       )}     </ul>   ); };Colocationされたコンポーネント以外でFragmentの値にアクセスしてしまうと、もしFragmentのフィールドを変更した場合に呼び出し側のコンポーネントが壊れる可能性があります。また、見かけ上Fragmentのフィールドを使用していることに気づきにくいという問題があります。これはFragment Colocationの実装が不十分で保守性を下げることに繋がります。この問題を解決するアイデアの一つがFragment Maskingです。Fragment MaskingとはRelayが提唱している、Fragment Colocationをカプセル化するための方法です。Relay のチュートリアルでは標準でFragment Maskingを使った流れが示されています。なお、Relayの文脈ではData Maskingと表現しているようです。GraphQL Code GeneratorにRelayスタイルのFragment Colocationが実装されているので、今すぐ使うことができます。ということで、今回はgql-tag-operations-presetプラグインを用いて実際に使ってみます。gql-tag-operations-presetでFragment Maskingを使ってみるgql-tag-operations-presetやGraphQLクライアントの導入自体は済んでいる前提で進めます。まずは、codegen.tsの設定で有効にします。といっても簡単で、presetConfig: { fragmentMasking: true } を入れてあげるだけです。code:codegen.ts const config: CodegenConfig = {   ...   generates: {     'graphql/__generated__/': {       preset: 'gql-tag-operations-preset',       presetConfig: {         fragmentMasking: true,       },       plugins: [],       config: {         ...       },     },   }, };Fragment Maskingを有効にしてコードを再生成すると、カプセル化が効いてフラグメントのフィールドにアクセスできなくなります。さらに、FragmentのオブジェクトをPropsに渡す部分でもエラーが出ています。生成したコードを読むとわかりますが、$fragmentRefsというキーをもつ型に変換されていて、直接PokemonFragmentへ参照できなくなりました。code:1. graphql/__generated__/graphql.ts // fragmentMasking: false（またはデフォルト）の場合 export type PokemonsQuery = { __typename?: 'Query', pokemons: Array<{ __typename?: 'Pokemon', id: string, number: string | null, name: string | null, image: string | null } | null> | null };code:2. graphql/__generated__/graphql.ts // fragmentMasking: true の場合 export type PokemonsQuery = { __typename?: 'Query', pokemons: Array<(     { __typename?: 'Pokemon', id: string }     & { ' $fragmentRefs'?: { 'PokemonFragment': PokemonFragment } }   ) | null> | null };これをカプセル化されたコンポーネントの中だけで参照できるように変えていきます。code:Pokemon.tsx import { FragmentType, gql, useFragment } from '../graphql/__generated__';  export const PokemonFragment = gql(`   fragment Pokemon on Pokemon {     number     name     image   } `);  export const Pokemon = ({   pokemon, }: {   pokemon: FragmentType<typeof PokemonFragment>; }) => {   const pokemonFragment = useFragment(PokemonFragment, pokemon);      return (     <div>       <a href={/pokemon/${pokemonFragment.number}}>         <h3>{pokemonFragment.name}</h3>         <img width={100} height={100} src={pokemonFragment.image!} />       </a>     </div>   ); };ポイントは、Propsの型をFragmentから、FragmentType<typeof Fragment>に変更していることです。この型のオブジェクトはそのままで使うことができないので、useFragment(Fragment, fragment)を使って使えるようにします。このuseFragmentはいわゆるReactのHooksではなく、ただの関数です。どのような関数かは生成されたコードを読むとわかります。非常に単純で、as any で戻り値の型を明示してキャストしているだけですね。code:graphql/__generated__/fragment-masking.ts // return non-nullable if fragmentType is non-nullable export function useFragment<TType>(   _documentNode: DocumentNode<TType, any>,   fragmentType: FragmentType<DocumentNode<TType, any>> ): TType; // return nullable if fragmentType is nullable export function useFragment<TType>(   _documentNode: DocumentNode<TType, any>,   fragmentType: FragmentType<DocumentNode<TType, any>> | null | undefined ): TType | null | undefined; // return array of non-nullable if fragmentType is array of non-nullable export function useFragment<TType>(   _documentNode: DocumentNode<TType, any>,   fragmentType: ReadonlyArray<FragmentType<DocumentNode<TType, any>>> ): ReadonlyArray<TType>; // return array of nullable if fragmentType is array of nullable export function useFragment<TType>(   _documentNode: DocumentNode<TType, any>,   fragmentType: ReadonlyArray<FragmentType<DocumentNode<TType, any>>> | null | undefined ): ReadonlyArray<TType> | null | undefined; export function useFragment<TType>(   _documentNode: DocumentNode<TType, any>,   fragmentType: FragmentType<DocumentNode<TType, any>> | ReadonlyArray<FragmentType<DocumentNode<TType, any>>> | null | undefined ): TType | ReadonlyArray<TType> | null | undefined {   return fragmentType as any; }つまり、オブジェクトにデータはあるものの、TypeScriptの型の上でFragmentのデータを隠蔽（Masking）することでアクセスできないようにしています。そしてColocationしたコンポーネント内部でキャストして使えるようにします。テストやStorybookでモックのFragmentオブジェクトを入れたい場合makeFragmentDataメソッドを作りPropsでFragmentオブジェクトを渡してあげましょう。code:makeFragmentData.ts import type {   ResultOf,   TypedDocumentNode as DocumentNode, } from '@graphql-typed-document-node/core'; import type { FragmentType } from '~/generated';  export function makeFragmentData<   F extends DocumentNode,   FT extends ResultOf<F>, (data: FT, _fragment: F): FragmentType<F> {   return data as FragmentType<F>; }code:component.ts import { Pokemon, PokemonFragment } from '../components';  <Pokemon   pokemon={makeFragmentData(     {       number: '1',       name: 'ピカチュウ',       image: 'https://dummyimage.com/100x100',     },     PokemonFragment   )} />こちらもキャストしているだけですね。※ ちなみに、本題とはそれますが client preset を使う場合はmakeFragmentData(data, fragment)が生成されるコードに含まれているため、メソッドを作る必要はありません。Fragmentの中でも外でも使いたいフィールドはどうするかFragment Colocationされたコンポーネントの中でも、クエリの呼び出し側でも使いたいフィールドがある場合は、クエリ（ミューテーション）に直接フィールドを定義した上で、参照するFragmentにもフィールドを定義してあげましょう。まとめFragment MaskingはFragment Colocationを強制するためにとても便利な機能です。自動生成されたコードを読めばわかるように、実際に行っていることは型によるFragmentデータのカプセル化だけなのでGraphQLのクエリやミューテーションに影響を及ぼすことはありません。また、現在GraphQL Code Generatorではv3のロードマップが敷かれていて、client preset という便利なプリセットが作成されています。このプリセットは既にurqlのドキュメントで使われていたりして、今後のデファクトプリセットになる可能性があります。client presetでは今回紹介したFragment Maskingがデフォルトで有効になっていることからも、積極的に使っていくことは悪くない選択肢だと思います。参考 https://zenn.dev/mh4gf/articles/graphql-codegen-client-preset https://zenn.dev/takashima/articles/4c284439135a0c < Twitterでシェア宣伝株式会社モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。https://youtu.be/mwZ_tnGKEIY会社の紹介スライドはこちらから！

Fragment Masking で Fragment Colocation を強制する

大稻埕碼頭#GraphQL #Next.js #Apollo #Persisted_Queriesこちら（GraphQL の Persisted Queries について）の続きです。はじめに私が所属するモニクルのサービス「マネイロ」では、REST APIからGraphQLへの移行を進めています。フロントエンドはNext.jsを採用しており、REST APIのデータ取得にはSWRを使っています。これをApollo Clientで置き換えています。バックエンドではRailsにGraphQL Rubyを使ってクエリやミューテーションを作成しています。なお、Apollo Serverは使っていません。さて、マネイロは資産運用に関する悩みを解決するお手伝いをするために無料でオンライン相談ができるサービスを提供しています。そのために相談予約可能な日時や時間帯を取得するAPIがありますが、このAPIレスポンスはCDNにキャッシュしています。GraphQLに移行しても同じようにCDNにキャッシュしたいのですが、GraphQLはデフォルトでPOSTリクエストするためVercelのCDNでキャッシュすることができません。また、そもそもGraphQLクエリをブラウザに露出してしまうのも避けたいところです。そこで、Persisted Queriesを使ってこの問題を解決することにしました。Persisted Queries を使う方法として二種類のパターンを考えてみました。 Next.js（フロントエンド）からNext.js（API Routes）へのリクエストにのみハッシュ値を使う Next.js（フロントエンド）からRails（バックエンド）に至るまで全てハッシュ値でやりとりする今回は前者の実装だけで目的を達成することができるため、前者の実装を行うことにしました。クエリとハッシュ値を相互に変換するテーブルを用意するまず、今回の実装に必要となる変換テーブルを用意します。前回の記事でも紹介したgraphql-codegen-persisted-query-idsを使います。READMEを読みつつインストールした後、codegen.ymlに設定を記述します。名前やファイルパスは適宜読み替えてください。code:codegen.yml overwrite: true ... generates:   generated/server.graphql.gen.json:     plugins:       - graphql-codegen-persisted-query-ids:           output: server           algorithm: sha256   generated/client.graphql.gen.json:     plugins:       - graphql-codegen-persisted-query-ids:           output: client           algorithm: sha256その後、コード生成コマンドを実行します。code:console ./node_modules/.bin/graphql-codegen --config codegen.ymlこれで、generated/server.graphql.gen.jsonとgenerated/client.graphql.gen.jsonのファイルがそれぞれ出来上がります。どのような形式になっているかは、前回の記事が参考になります。Apollo Linkの設定Http Linkを使います。以下のように設定していきます。 url  BFFへのエンドポイントを指定する useGETForQueries  クエリにはGETリクエストを利用するためtrueにする fetch  GETリクエストの場合は query をハッシュ値に置き換えるcode:apolloClient.ts import { ApolloClient, from, HttpLink } from "@apollo/client" import queryHash from "generated/client.graphql.gen.json"  const endPointLink = new HttpLink({   uri: "/api/graphql",   useGETForQueries: true,   fetch: (uri, options: RequestInit) => {     if (options.method === "GET") {       // クエリをハッシュ値に変換します       const path, queryString = uri.toString().split("?")       const params = new URLSearchParams(queryString)       // params の中身についてはこちらが参考になります       // https://www.apollographql.com/docs/react/api/link/introduction/#the-operation-object       const { query, operationName, ...others } = Object.fromEntries(params)       const hashedParams = new URLSearchParams({         q: queryHashoperationName,         operationName,         ...others,       })       return fetch(${path}?${hashedParams}, options)     }      return fetch(uri, options)   }, })  export const apolloClient = (() =>   new ApolloClient({ link: from(endPointLink) }))() 上記の例ではfetchを独自にオーバーライドしていますが、graphql-codegen-persisted-query-idsはApollo Link用のアダプタも用意されていて、こちらを使うことでApolloの仕様に沿ったリクエストを書くこともできます。API Routesでの処理最後にAPI Routesの処理を書いていきます。主な観点は以下の部分です。 next-http-proxy-middlewareを使用すると、簡単にProxyするBFFが書けて楽 ハッシュ値をクエリに戻した上で、GraphQLバックエンドにPOSTリクエストする HTTP キャッシュヘッダーをセットするcode:pages/api/grpahql.ts import type opnameHash from "generated/client.graphql.gen.json" import hashQuery from "generated/server.graphql.gen.json" import type httpProxy from "http-proxy" import { NextApiHandler, NextApiRequest, NextApiResponse, PageConfig } from "next" import httpProxyMiddleware from "next-http-proxy-middleware"  export const config: PageConfig = {   api: {     bodyParser: false,     externalResolver: true,   }, }  const handleProxyInit = (proxy: httpProxy) => {   proxy.on("proxyReq", (proxyReq, req, res) => {     if (proxyReq.method !== "GET") return     const path, queryString = proxyReq.path.split("?")     const params = new URLSearchParams(queryString)      // クエリのハッシュ値からクエリを復元する     const { q, operationName, ...others } = Object.fromEntries(params)     const query: string | undefined = hashQueryq      if (!query) throw new Error(クエリが見つかりませんでした。 ${q})      // GETリクエストをPOSTリクエストとして送信する     proxyReq.method = "POST"     proxyReq.path = ${path}?operationName=${operationName}     const bodyData = JSON.stringify({       query,       operationName,       ...others,     })     proxyReq.setHeader("Content-Length", Buffer.byteLength(bodyData))     proxyReq.write(bodyData)   })   proxy.on("proxyRes", (proxyRes, req, res) => {    // ※ req オブジェクトからリクエスト情報が取得できるので、クエリに応じたキャッシュの設定などをすると良いでしょう     proxyRes.headers"Cache-Control" = "s-maxage=60, stale-while-revalidate"   }) }  const h: NextApiHandler = (req: NextApiRequest, res: NextApiResponse): Promise<void> =>   httpProxyMiddleware(req, res, {     ..., // ※ RailsバックエンドへのProxyの設定を書く     onProxyInit: handleProxyInit,   })  export default h これで完了です。Apollo Linkを使っているため、フロント側のuseQueryフックは変更する必要がありません。これでCDNでのキャッシュと、クエリをブラウザに露出させることを防ぐことができるようになりました。まとめPersisted QueriesはApolloが提唱する仕様通りに作ることもできますが、今回の例のように自分で変換処理を書くことで、最低限の仕組みだけで実装することが可能です。一方でApolloの仕様に則ったライブラリも豊富なので、そちらに実装に合わせておくと良い場合もありそうです。いずれにしても仕組み自体は難しくないので、覚えておくと何かと便利な仕組みだと思いました。 < Twitterでシェア宣伝株式会社モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。https://youtu.be/mwZ_tnGKEIY会社の紹介スライドはこちら → https://speakerdeck.com/monicle/about

GraphQLクエリをCDNキャッシュに載せたい

林家花園#GraphQL #Persisted_QueriesGraphQL クエリの特徴GraphQLではクライアントとサーバ間のやりとりにGraphQLクエリを使うことで、一回のリクエストで必要な要素だけを取得することができます。code:sample_query  query GetCustomerQuery {    customer(id: "Customer001") {      id      email      profile {        id        name      }    }  }通常はこのようなクエリをPOSTリクエストのペイロードに含めて、{ "query": "query GetCustomerQuery {...}" }のような形でサーバサイドにリクエストします。サーバサイドではこのクエリを解釈し、必要なオブジェクトや要素だけをクライアントに返却します。このようにして、クライアントはクエリを記述することによって一度に複数のネストしたオブジェクトを最低限必要な要素だけ取得することが可能になります。なお、上記の"Customer001"のような値は引数（variables）として渡すことが一般的ですがPersisted Queriesではvariablesを取り扱わないため省略します。Persisted Queries とはPersisted Queiesは、リクエストのペイロードにGraphQLクエリの文字列を直接含めるのではなく、ハッシュ化した文字列（ハッシュ値）を使ってリクエストする方法です。クライアントはハッシュ値をペイロードに入れてリクエストした上で、サーバサイドではハッシュ値をクエリに戻し、必要なデータを返します。Persisted QueriesはGraphQLの機能を拡張したプロトコルです。そのため、Persisted Queriesに対応したクライアントでは以下のようなペイロードを送ります。code:extensions.json {   "extensions":{     "persistedQuery":{       "version":1,       "sha256Hash":"ハッシュ値"     }   } }クライアントはクエリをハッシュ化する必要があります。上記の例ではSHA256のハッシュアルゴリズムを使ってハッシュ値を生成しています。また、サーバサイドでは受け取ったハッシュ値をクエリに戻す必要があります。ここで、クエリとハッシュ値を変換する方法を2種類紹介します。クエリとハッシュ値を相互に変換するテーブルを用意するクエリとハッシュ値が相互に変換できればそれで良いので、クライアントとサーバ側でそれぞれ変換テーブルを事前に用意しておくことで対応させることが可能になります。変換テーブルはビルドステップで事前に準備したり、スクリプトを走らせて生成したりします。以下はJS環境で使うためにgraphql-codegen-persisted-query-idsという自動生成ツールを用いて作った json ファイルの例です。code:client.json {  "getCustomerQuery": "ハッシュ値" }code:server.json {  "ハッシュ値": "query GetCustomerQuery {...}" }client.jsonをクライアントで、server.jsonをサーバサイドでそれぞれ使用します。クライアントではハッシュ値をそのまま取り扱うことはしたくないですが、このツールを使えばgetCustomerQueryというクエリの名前を使ってハッシュ値を取り出すことができます。便利ですね。Automatic Persisted Queries で自動変換を行う前述したような変換テーブルを用意することなく自動的に変換を行ってくれるようにする方法としてAutomatic Persisted Queriesがあります。Automatic Persisted Queriesを使う場合は、Apollo のようなそれに対応したサーバとクライアントを使います。仕組みとしては、クエリと対応するハッシュ値をクライアントで動的に生成し、クエリの代わりにハッシュ値をサーバサイドに送ります。もしサーバサイドでハッシュ値に対応するクエリがわからない場合はエラーを返します。そこで、クライアントは再度同じクエリをリクエストするのですが、その時にクエリ文字列とハッシュ値を両方ともペイロードに含めます。サーバサイドではハッシュ値とクエリを登録した上で結果を返します。それ以降登録されたクエリはハッシュ値だけ送ればよくなります。これを自動的に行ってくれる仕組みがAutomatic Persisted Queriesです。Persisted Queries はどのような問題を解決するのかデータ通信量の削減GraphQLで複雑なクエリを使用するとクエリ文字列が長くなるため、ペイロードサイズが大きくなりネットワークのパフォーマンスが低下します。Persisted Queriesを使用すると長いクエリであっても文字列長が同じハッシュ値を送るため、ペイロードサイズが削減できます。さらに、サイズが小さくなることでGraphQLクエリをGETリクエストで送信できます。GETリクエストにできれば一般的なCDNで結果をキャッシュできるようになるため、パフォーマンスがさらに向上します。セキュアな通信の実現GraphQLのクエリはスキーマさえ正しければどんなクエリでも受け付けることができます。複雑なクエリの中には処理の重いロジックや、深いネスト、無駄なプロパティが含まれる場合があります。また、場合によってはクライアントから悪意のあるクエリや想定外のクエリ（ただしスキーマ上は正しいクエリ）を含めたリクエストがくる場合もあるかもしれません。通常のクエリであれば、このようなクエリでもあってもスキーマ上正しければ値を返すしかありません（※クエリの複雑度を計算して閾値を超える場合にはエラーを返す方法は存在しますが、閾値を超えなければ正しいレスポンスを返すでしょう）。しかしPersisted Queriesを使うことによって事前に決められたクエリのハッシュ値のみを受け付けることができるようになるため、想定していない複雑なクエリや悪意のあるクエリをクライアントから送られても破棄することができます。まとめPersisted Queriesそのものは非常にシンプルなんですが、GraphQLの拡張機能であるがゆえに体系だった解説記事が少ないなと思い今回まとめてみました。次回は、実際にやってみた例を紹介しようと思います。 < Twitterでシェア参考 https://relay.dev/docs/guides/persisted-queries/ https://blog.codecentric.de/en/2020/05/how-to-secure-a-graphql-service-using-persisted-queries/ https://developers.gnavi.co.jp/entry/frontend_improvement/ https://qiita.com/Quramy/items/b3943a0c27f3ade2c57d宣伝株式会社モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。https://youtu.be/mwZ_tnGKEIY会社の紹介スライドはこちら → https://speakerdeck.com/monicle/about

GraphQL の Persisted Queries について

林家花園#Deno #Fresh 前回の記事で使ってみたFreshについての特徴と所感をまとめてみようと思います。もし前回の記事を読んだことがない場合は、先に読むことをお勧めします。Denoを初めて触ろうと考えている人やFreshを使ってみたい人に参考になればと思います。Fresh は Preact 依存のフレームワークFreshは内部実装でPreactが使われています。そのため、後ほど紹介するパッケージ管理システムの中にデフォルトで組み込まれているPreactを外すことはできません。前回はRSSフィードを作るだけだったので、特にPreactやJSXを使うシーンというのは無かったのですが、Preactを外してしまうとFreshサーバの内部実装でエラーになってしまいました。そういう意味では、今回はよりシンプルなHttpフレームワークを使うだけでも良かったのかもしれません。ゼロコンフィグでTypeScriptが使える私は普段から専らTypeScriptを使っていますが、Denoは何の設定をせずともTypeScriptを使うことができます。つまり、Node.jsでTypeScriptを書く際には必須となるtsconfig.jsonが必要ありません。この辺りの仕組みとしては、まずDenoを使うときに必須となるdeno-cliにTypeScriptが内包されています。そのため、下記のコマンドでどのバージョンが使われているのかを知ることができます。code:console deno --version  # deno 1.24.3 (release, aarch64-apple-darwin) # v8 10.4.132.20 # typescript 4.7.4tsconfig.jsonをカスタマイズすることもできます。カスタマイズする場合は、deno.jsonまたはdeno.jsoncというファイルを作成します。ただし、カスタマイズできるのはcompilerOptionsのセクションのみに限定され、そのほかは無視されるようです（Denoには無関係の機能や不完全な動きをするものが含まれるため）。Freshの新規プロジェクトにはdeno.jsonが含まれるため、そのままcompilerOptionsセクションを作成すれば良いですね。ちなみに、デフォルト値については公式ページにまとまっているため、目を通しておくと良いかもしれません。デフォルトでstrict: trueなのは最高ですね。ビルドステップがない昨今のNode開発環境ではほぼ確実に必要となるWebpackやesbuildなどのビルドツールも不要です。僕自身はビルドツールの設定に拘ったり全ての設定の意味を調べて必要なものを吟味することが好きなんですが、サクッとアプリを作りたいときにはそれが時間泥棒になってしまう場合があるので、何も設定が必要ないのはプロダクト作成に時間とエネルギーを割くことができて良いですね。Freshで作成したアプリをDeno DeployにデプロイするようにGitHub連携しておくと、mainブランチをプッシュした直後にアプリケーションがデプロイされReady状態になります。よくみてみると、Deno Deployのプロジェクトページにビルドの画面はありません。これがゼロビルドステップの力か〜と感動しました。Next.js風のファイルシステムルーティングFreshはNext.jsと同じようなファイルシステムをベースとしてルーティングを採用しています（Fresh公式でもそのように謳っています）。例えばroutes/hoge.tsxを作成したら、/hogeにアクセスできるようになります。Next.jsであればpages/配下ですが、Freshではroutes/配下であれば、APIリクエストをハンドリングしたり（一般的にはrouters/api/配下に定義しますが任意です）、JSXを返してHTMLのページをレンダリングするすることができます。公式ドキュメントの表がわかりやすいので参考にしてみると良いでしょう。import map を使ったパッケージ管理システムDenoではimport時に直接URLを書いてしまう方法の他、パッケージ管理を行う手法としてdeps.tsを使う方法とimport mapを使う方法の二種類があるようですが、Freshの新規プロジェクトではデフォルトでimport mapを使った方法が採用されています。これはプロジェクト内にimport_map.jsonファイルを置いて依存を解決する仕組みです。code:import_map.json {   "imports": {     "$fresh/": "https://deno.land/x/fresh@1.0.2/",     "preact": "https://esm.sh/preact@10.10.0",     "preact/": "https://esm.sh/preact@10.10.0/",     "preact-render-to-string": "https://esm.sh/preact-render-to-string@5.2.1?external=preact",     "rss-parser": "https://esm.sh/rss-parser@3.12.0"   } }インポートしたいESモジュールのURLに対して、任意の名前をキーとしたJsonを定義します。このようなファイルをプロジェクトルートに配置したのち、deno.jsonにファイルパスを明記してあげると、このファイルを使って依存を解決してくれます（実行コマンドの引数に--import-map ./import_map.jsonと指定する方法もあります）。code:deno.json {   ...   "importMap": "./import_map.json" }実際のコードでは以下のようにインポートして使います。code:main.ts import { HandlerContext, Handlers } from "$fresh/server.ts"; // https://deno.land/x/fresh@1.0.2/ import Parser from "rss-parser"; // https://esm.sh/rss-parser@3.12.0DenoはNodeとの互換性がないため、現状はNode用に作成されたnpmのパッケージをそのまま使うことはできません（3ヶ月以内には80%〜90%のnpmパッケージを簡単に使えるようにする計画がブログで公表されました）。そこで、npmパッケージを使いたい場合は以下の順番で試してみると良いです。1. https://deno.land/x にホスティングされていないか調べるdeno.land/x はDeno用モジュールのホスティングサービスです。lodashやdayjsなどの人気なパッケージはすでに公開されているようです。今回使ってみたFresh自身もここにホスティングされています。import_map.jsonのURLにhttps://deno.land/x/{パッケージ名}@{バージョン}と書いて使います。2. ESM形式で、Deno用にビルドされたパッケージを配布してくれるCDNを使う前回のRSSフィードを作成するときは、rss-parserというnpmパッケージを使うために https://esm.sh というCDNを利用しました。ブラウザでhttps://esm.sh/{パッケージ名}にアクセスすると、https://esm.sh/{パッケージ名}@{バージョン}にリダイレクトされるので、それをURLとしてimport_map.jsonに書いてあげましょう。実は、DenoにはNode互換のパッケージが存在しており、Node専用のモジュールをNode互換のモジュール呼び出しに置き換えることにより使える場合があり、その仕組みを使ってDeno用モジュールを配布できるCDNのうちの一つがesm.shです。ちなみに、依存パッケージの更新管理はdependabotやrenovateがよく使われますが、Denoではuddというツールがよく使われているようです。しかし、現状はesm.shのURL形式を完全にサポートできていないため、今回は使いませんでした。今後のアップデートが待たれるところです。クライアントサイドJSを動かすための仕組みFreshはインタラクティブなページを実装するための仕組みとしてアイランドアーキテクチャを採用しています。基本的に全てのコンポーネントはサーバサイドでレンダリングされますが、islands/配下に定義したコンポーネントだけはクライアントサイドで埋め込まれレンダリングされる仕組みです。動的なコンポーネントだけはファイルシステムで孤立・分離させることでクライアントサイドJSの量を最小限に抑えられますし、影響がそのコンポーネントに閉じるように工夫されています。まとめ一部の内容はFreshというよりDenoの良いところを語ってしまいましたが、Freshは軽量で薄いフレームワークのため、初めてDenoを触ってみたい方には最適なフレームワークのうちの一つではないかと思いました。次はislands/をゴリゴリ使ったアプリやPreactをガッツリ使うもの、ある程度大きめのページも作ってみたいです。Freshに関してより詳細な情報を知りたい方は、https://fresh.deno.dev/docs/concepts を眺めてみてください。Freshの考え方が簡潔にまとまっています。 < Twitter でシェア参考 Fresh - Deno の 次世代 Web フレームワーク Effective Deno Deno v1.15で導入されたNode.js互換モードについて宣伝株式会社モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。https://youtu.be/mwZ_tnGKEIY会社の紹介スライドはこちら → https://speakerdeck.com/monicle/about

Fresh - DenoのWebフレームワークを触ってみた特徴と所感

大稻埕/迪化街#Deno #Fresh #RSS #Deno_Deployはじめに私が所属するモニクルでは、開発チームの各メンバーが書いた技術ブログをまとめたサイトがあります。https://developers.monicle.co.jp/まとめサイトを作るに至った経緯や、作成の流れについては同僚の/wadata/nkzn.iconnkznさんが書いたこちらの記事が参考になります。さて、私はScrapboxのまさにこのプロジェクトに記事を書いているのですが、オーナー（つまり自分自身）のアカウントでログインしていると、一般的に他のブログページにある、いわゆる「閲覧モード」が存在せず、記事の閲覧と編集を常に行うことができます。それがScrapboxのいいところの一つではあるのですが、カジュアルに記事を修正して行った時に起きてしまった悲劇と、それをDeno Freshで解決してみた話を紹介します。wada-blog が上位を独占？！ある日、ふと技術ブログまとめサイトをみたところ、自分が過去に書いた記事がすべて新着記事として上位に上がってきてしまう事態が起きていました。なぜこんなことになってしまったのかと考えてみたのですが、一つ心当たりがありました。それは「過去に書いた記事を一気に編集してしまった」ことでした。ちょうどこの時Scrapboxでカスタムのスタイルを当てて見た目を変更していたため、古い記事のタグの配置を変えたりしてレイアウトを整えていました。それが仇となり、過去記事が上位を独占してしまいメンバーに申し訳ない気持ちになりました。そこで、まずは根本的な原因を調査することにしてみました。Scrapbox の RSSフィード は RSS 2.0 ベース技術ブログまとめサイトでは、各個人のブログページのフィードを登録して新着記事を取り込むようになっています。RSS 1.0/2.0, ATOMの仕様が存在しますが、どの仕様に準拠したRSSでもパース可能なrss-parserを使ってJS Objectに変換した上で記事の発行日時にソートしています。また、ScrapboxのRSSはRSS 2.0を使っているようです（wada-blogのRSS）。RSS 2.0 の仕様を読んでみると、各記事を表現するitem要素の中にある日時はpubDate(発行日時）しかありません（ちなみに、ATOMの仕様には作成日時と更新日時という項目があります）。また、Scrapboxの記事を更新した場合はpubDateが更新されるということも判明しました。これを根拠にしてデータを定期的に都度作成している技術ブログまとめサイトでは、Scrapboxで編集した記事の発行日時が更新されて新着記事に上がってしまうということがわかりました。pubDate だけを上書きしたRSSフィードが欲しいここで、まずはこの問題を解決する方法を考えてみました。ScrapboxのRSS自体は、自分ですぐに触れるものではないのでどうしようもありません。また、技術ブログまとめサイトのロジックを変えることも検討しましたが、まとめサイト側で作成日時がわかるデータを保持していないため、すぐにはできそうになく諦めました。そこで、ScrapboxのRSSのうち、pubDateだけ作成日時に差し替えたRSSサーバを別途立ち上げることを検討しました。Scrapboxには、RSSとは別にAPIも存在していてページの一覧をGETで取得することができます（wada-blogのAPI）。このAPIレスポンスには各記事の情報の中に作成日時が含まれるため、発行日時だけ差し替えたRSSアプリを構築することができそうです。Deno の Fresh を使って爆速でRSSフィードを実装するそこで、今回はDeno用のWebフレームワークであるFreshを使ってRSSフィードを実装してみることにしました。Freshは2022/07/28 に1.0がリリースされたばかりの新しいフレームワークで非常に軽量です。クライアントに送信するJSはデフォルトで0KBで、リクエストに応じて edge サーバでレンダリングをして返すのが特徴です。まだ安定版がリリースされたばかりのため、プロダクションで使われているケースはあまり多く知りませんが、フレームワークの特徴からしても静的なLPや動きの小さなWebページには適していて、実際にDeno公式ブログでは使われているようです。今回作成するアプリは1ページのみで xml を返すだけなので、フレームワークとしてはなるべく小さくて開発体験が高速なツールがいいなと思っていました。その点でFreshはWebpack等のプレビルドを行う必要がないためアドバンテージがありました。また、ファイルベースルーティングを使用している点も気に入りました。私は普段Next.jsベースのアプリケーションを開発しているため、同じシステムを採用しているのは馴染みやすいです。もちろん、ただ単純にDenoやDeno Deployを使ってみたかったという理由もかなり大きいです。そして、です。https://rss-proxy.deno.dev/api/scrapbox/wada-blogソースコードはこちらにアップしています。https://github.com/sugoi-wada/fresh-rss-proxy作り始めてから数時間で無事に最低限の実装が出来上がりました。本当にpubDateを差し替えただけのミニマムな実装です。デプロイ先にはDeno Deployを利用しています。プッシュした後にビルドステップを踏まずにデプロイが終わるのは凄くいい体験ですね。RSSを切り替えてまとめサイトを再度確認してみると、wada-blogが元々あった場所に収まってくれていました。これで一安心。まとめ今回は、意外なところからRSSフィードを作ることになった経緯とその結果を中心にまとめてみました。次回は、Freshを使う上で調べたことについてまとめていきたいと思います。それでは！宣伝株式会社モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。https://youtu.be/mwZ_tnGKEIY会社の紹介スライドはこちら → https://speakerdeck.com/monicle/about

技術ブログまとめサイトに wada-blog が上位独占してしまったので Deno Fresh で直した話

七海: https://ccklibrary.org.tw/w/zh_tw/index#Homebrew #Brewfileはじめに今まで利用していたPCはIntelのMacBookPro16インチでしたが、今回新たにM2のMacBookProを入手したので、セットアップについての備忘録を残したいと思いました。最近では多くの方が、タイムマシーン等を使ってSSDの中身を丸ごと移動するような方式をとっているかもしれませんが、私は綺麗な環境からスタートしたい気持ちが強く、そのような方法はとっていません。また、Intel版とApple Sillicon版の違いにより、別々に配布されているバイナリは丸ごと移行して欲しくない場合もあるでしょう。ということで、今回は Homebrew の Brewfile を使ったアプリの管理方法について紹介します。なお、初回の執筆時の環境はこちら。 旧: Intel MacBookPro 新: M2 MacBookPro Homebrew 3.5.9Homebrewのインストールはこちらから済ませておいてください。旧Macで準備することBrewbundleを使って新Macを使うためにはその元となるBrewfileが必要なので、それを準備します。Homebrew でアプリをインストールするまずは今使っているMacでインストールしているアプリをなるべくHomebrewでインストールしておくと良いでしょう。また、Macアプリの場合は--caskオプションをつけることでHomebrewにアプリを管理させることができます。code:zsh brew install app_name brew install --cask mac_app_nameちなみに、Macアプリの場合はUIからアップデートしないようにしておくと良いでしょう。Homebrewの管理が外れます。アップデートしたい場合は--greedyオプションを使います。code:zsh brew update && brew upgrade --greedyMac App Store のアプリについてmasというツールを使うことで、Mac App Store のアプリもBrewfileで管理できるようになりますが、認証面の問題で少し使いにくく、コツがいるため今回の説明からは省きますが、興味がある人はやってみてください。Brewfile の作成使っているアプリをHomebrewで管理することができたら、あとはbrew bundle dumpコマンドを使ってダンプファイルを書き出します。code:zsh brew bundle dump --global --forceホームディレクトリに .BrewfileができていればOK。中にはテキストでbrew installされているファイルが書かれています。ちなみに、masを使った人はMac App Storeのファイルも書かれています。GitHubのリポジトリ等に保存.Brewfileの保存先はどこでもいいですし、ファイル共有ソフトで管理するだけでもいいですが、今後も定期的にダンプして差分を更新していくことを考えるとGitでどこかのリモートリポジトリにプッシュしておくのがおすすめです。また、本題からはそれますが.zshrcや.gitconfigなども入れておくと良いでしょう。私はこれらのファイルを.dotfilesディレクトリに置いて、シンボリックリンクを使ってホームディレクトリに配置しています。Gitを使う場合は~/.dotfilesをコミットしてリモートリポジトリにプッシュすればOK。code:zsh mkdir ~/.dotfiles mv ~/.Brewfile ~/.dotfiles/.Brewfile ln -s ~/.dotfiles/.Brewfile ~/.Brewfile  # .zshrc 等を含む複数の隠しファイル（.から始まるファイル）をシンボリックリンクする場合は以下 ls ~/.dotfiles/.* | xargs -I{} basename "{}" | xargs -I{} ln -s ~/.dotfiles/{} ~/{}新Macで準備することさて、ここから新しいMacでのセットアップを始めます。Homebrewのインストールは済ませておいてください。Brewfile の取得と配置まずは保存した.Brewfileを新しいMacで取得します。git cloneをしたり、zipでダウンロードしたものを解凍したり、どんな方法でも構いません。その後、旧Macと同じ状態を作るため、ホームディレクトリ直下に.dotfilesを置いて、その中に.Brewfileを配置するのが良いでしょう。その後、同じようにシンボリックリンクを貼ります。Brewfile を元にアプリをインストールこれで準備は完了です。あとはbrew bundle dumpコマンドを使ってインストールしていきましょう。code:zsh brew bundle --file=~/.Brewfileネットワーク状況にもよりますが、相当な時間がかかる場合があります。またたまにパスワード入力を求められて止まるので気にしてあげてください。以上！宣伝株式会社モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。https://youtu.be/mwZ_tnGKEIY会社の紹介スライドはこちら → https://speakerdeck.com/monicle/about

新しい Mac を手に入れたらまずやること [Brewfile編]

#ベロシティ #スクラム #見積もり #アジャイル #ストーリーポイントはじめに私が所属するチームではスクラム型のソフトウェア開発（アジャイル開発と呼ぶかもしれません）を行っています。具体的には、各スプリントを始める前に、作業チケットにストーリーポイントで見積もりをしてスプリント内で終わらせることができそうな範囲を見極めます。見極めのためには過去のベロシティが参考になります。なぜなら、チームがこれまでのスプリントでどの程度のストーリーポイントを消化できたのかを確認できるからです。さて、今回はそんな指標として用いられるベロシティや見積もりについての考え方や、チーム内で実践していること・工夫していることをまとめます。この話は私が所属するチームにおける内容であり、一つの考え方・事例として参考にしてください。ベロシティは実績であるそもそもベロシティとは何か？というと、スクラムチームが1回のスプリントでDone（完了）にしたストーリーポイントの合計値です。言い換えると、1回のスプリントで見積もりした作業がどのくらいできたかの実績をあらわします。そして、各スプリントごとのベロシティを見てみるとある程度の傾向が見えてきます。安定・上昇・下降・乱高下くらいのパターンに分かれるでしょうか。この数値や傾向を見ると何がわかるのでしょうか？ベロシティを計測するワケは、不確実性の削減にあるベロシティの見方を考える前に、ベロシティを測る意味について考えてみます。その答えはズバリ「未来の予測可能性を高めること」にあります。ある機能を追加するとき、それが1週間で終わるのか、1ヶ月で終わるのか、3ヶ月で終わるのかは誰もが知りたいことです。アジャイル開発では、ベロシティがその役割を担っています。例えば、過去のベロシティ平均が15だったチームでは、各スプリントで15ポイントのタスクを消化できるので、ある作業を見積もった時に30だったのであれば、おそらく2スプリントかかるだろうと予測できます。私のチームでは1スプリントが1週間なので、2週間かかることが推測できます。このようにして過去の経験から未来の不確実性を少しでも削減するためにベロシティを計測します。この内容から以下のことがわかります。 ベロシティを計測するためには、見積もりが不可欠である ベロシティ（平均）が安定していなければ意味がない  ベロシティが乱高下している場合、次のスプリントでどのくらいのポイントが消化できるかがわからないベロシティは価値提供の速度である日々の業務をこなす中で、緊急対応を迫られる場合があります。クリティカルなバグが発見されて調査や修正が必要になったり、データの修正や集計が必要になった場合です。また、緊急ではないけれどリファクタリングをしたり簡単なバグ修正をすることもあるでしょう。このような作業チケット（ストーリー以外のチケット）にはストーリーポイントをつけないようにしています。この背景には、ベロシティは（顧客への）価値提供の速度であるという考えに由来しています。前提としてアジャイル開発ではバグの発生やリファクタリングの必要性を最小限に抑えるようなコーディングを心がけるように考えられているため、バグ修正やリファクタリングの作業は負債であると考えます。もしも、ベロシティが毎週のように下がっていた場合はストーリーチケットが消化できていないことになります。その理由をチームメンバーで考えます。例えば以下のような原因が考えられます。 バグが多く、バグの調査や修正に時間がかかっている  → アプリケーションの品質が下がっているなら、上げる工夫ができないか考える  → 設計に問題があるなら、改善案について話し合う  → 調査に必要なログ基盤が不完全なら、ログ基盤の強化について考える リファクタリングや設計の見直しをするのに時間がかかっている  → ベロシティを下げてもやることに理解が得られるように話し合う  → スプリントにどのくらいの割合で、直接価値提供をするわけではないが、後の業務が楽になるなどの利益があるチケットをやるべきかを話し合い合意する 見積もり以上に時間がかかっている  → 実際にやってみないと（調査してみないと）わからない作業チケットについては調査自体を別チケットにして、解像度を上げてから再度チケット分割する  → 影響範囲が見積もり時より広く時間がかかりそうな場合は、メンバーと共有した上でチケットの分割や再見積もりについて検討する スプリント中に作業の差し込みが多すぎる  → 作業の優先度に変更がないか確認する  → 差し込み作業をやることでスプリントの目標が達成できない可能性が上がることについて確認する  → スプリントを閉じて仕切り直しを検討する  → スプリントの期間を短くしてみるベロシティからこのような問題点を発見し原因を追求して改善していくことによってベロシティの安定化（障害が取り除かれ、自然と緩やかに上昇することも良いでしょう）に繋がります。終わりに元々は社内向けにまとめていた記事を改めて整理して大幅に加筆しました。ベロシティを考える上では見積もりも重要なトピックなのですが、また機会があれば書いてみようと思います。まだまだ手探りな点もありますが、一つの考え方として参考にしていただければ幸いです。

ベロシティを測ることの意味と見方の考察

#Ruby #Rails #トランザクションはじめに説明の内容や開発環境は Rails 7、PostgreSQL を前提としています。with_lock についてRailsには、モデルに行ロックをかける（クエリレベルで言うとSELECT ~ FOR UPDATEをする）方法として、model_name.with_lock(&block)というメソッドが用意されています。これを使うことによって、ブロックの内部では行ロックがかかり排他制御された状態で処理を記述することができます。code:with_lock_sample.rb book = Book.first book.with_lock do   # このブロックはトランザクション内で呼び出される   # bookはロック済み   book.increment!(:views) end引用: Rails ガイド - 悲観的ロックただし、引用した上記のサンプルコードにもコメントで書かれている通り、ブロック内部はトランザクション内で実行されることに注意してください。code:with_lock_sample2.rb book = Book.create!(title: "Book 1") pp "start" book.with_lock do   pp "with_lock start"   book.update!(title: "Book 1 Updated")   Paper.create!(title: "Paper 1")   pp "with_lock end" end pp "end"上記のサンプルコードを見ると、bookオブジェクトに対してwith_lockブロックを囲っているため、ブロック内部ではbookレコードに行ロックがかかり、それとは関係のないPaperモデルに関してはPaper.create!の直後にコミットされるように見えますが、実際にはそうではありません。実行結果は以下のようになります。code:with_lock_sample2_result.rb TRANSACTION (0.1ms)  BEGIN  Book Load (0.4ms)  SELECT "books".* FROM "books" WHERE "books"."id" = $1 LIMIT $2 FOR UPDATE    "with_lock start"  Book Update (0.2ms)  UPDATE "books" SET "title" = $1, "updated_at" = $2 WHERE "books"."id" = $3    Paper Create (0.5ms)  INSERT INTO "papers" ("title", "created_at", "updated_at") VALUES ($1, $2, $3) RETURNING "id"    "with_lock end"  TRANSACTION (0.3ms)  COMMITRailsのソースコードを読んでもトランザクションが作られていることがわかります。https://github.com/rails/rails/blob/04972d9b9ef60796dc8f0917817b5392d61fcf09/activerecord/lib/active_record/locking/pessimistic.rb#L92-L95試しに、with_lockのブロックが終わる前に別のスレッドからPaperレコードをクエリで呼び出してみると、コミットされていないのでエラーになることがわかります。code:with_lock_sample3.rb book = Book.create!(title: "Book 1") book.with_lock do   book.update!(title: "Book 1 Updated")   paper = Paper.create!(title: "Paper 1")   Thread.start {     pp Paper.find(paper.id)   }   sleep 1 endcode:with_lock_sample3_result.rb TRANSACTION (0.1ms)  BEGIN Book Load (0.5ms)  SELECT "books".* FROM "books" WHERE "books"."id" = $1 LIMIT $2 FOR UPDATE   Book Update (0.4ms)  UPDATE "books" SET "title" = $1, "updated_at" = $2 WHERE "books"."id" = $3   Paper Create (0.5ms)  INSERT INTO "papers" ("title", "created_at", "updated_at") VALUES ($1, $2, $3) RETURNING "id"   Paper Load (0.4ms)  SELECT "papers".* FROM "papers" WHERE "papers"."id" = $1 LIMIT $2   #<Thread:0x000000010a917480 (irb):5 run> terminated with exception (report_on_exception is true): /Users/username/.anyenv/envs/rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/activerecord-7.0.3.1/lib/active_record/core.rb:284:in `find': Couldn't find Paper with 'id'=6 (ActiveRecord::RecordNotFound)         from (irb):6:in `block (2 levels) in <main>' TRANSACTION (0.8ms)  COMMIT => 1 まとめ行ロックはトランザクションがコミットされるまでの間維持されるため、トランザクションを作ることを知っていれば当たり前のことですが、Railsのコードを読む時にはついついモデル単位でそのオブジェクトを捉えてしまい、思わぬ勘違いをしてしまうことがあります。今回はその一例を紹介しました。それでは楽しいRailsライフを！

Rails: with_lock のブロックはトランザクション内で呼ばれる

#Ruby いきなりですが、TypeScript で以下のような関数を書いてみました。実行結果はどうなるでしょうか。code:sample1.ts function sample1(array: number[]): { result: string[] } {   const result = array.map((num) => {     if (num % 2 === 0) return ${num} は偶数     if (num % 2 === 1) return ${num} は奇数      return ${num} は偶数でも奇数でもない   })      return { result } }  console.log(sample1(Array.from({length: 10}, (v, i) => i)))実行結果は以下のようになります。resultをキーとした、文字列配列（10件分）のオブジェクトが入っていますね。{"result": ["0 は偶数","1 は奇数","2 は偶数","3 は奇数","4 は偶数","5 は奇数","6 は偶数","7 は奇数","8 は偶数","9 は奇数"]} さて、これをそのまま Ruby に置き換えて書いてみました。しかし、一つ大きなミスを犯しています。どこが間違いかわかるでしょうか。また、実行結果はどうなるでしょうか。ちなみに、本記事の Ruby バージョンは3.1.2を使用しています。code:sample1.rb def sample1(array)   result = array.map do |num|     return "#{num} は偶数" if num % 2 == 0     return "#{num} は奇数" if num % 2 == 1      "#{num} は偶数でも奇数でもない"   end      { result: } end  p sample1(10.times)実行結果は以下のようになります。"0 は偶数"この実行結果を見るとわかることとして、10件分の文字列配列が出力されておらず、引数に渡した文字列配列の1件目のデータである 0 が map ブロックの引数に渡され、 return "#{num} は偶数" が呼ばれたところで処理が終わっています。つまりreturn句を関数内・ブロック内で呼び出した場合は、その時点でブロックと関数を中断してreturnに渡された値を返します。Ruby のreturn句はブロックも関数も抜けてしまうので、breakで書き直してみます。以下の実行結果はどうなるでしょうか。code:sample2.rb  def sample2(array)    result = array.map do |num|      break "#{num} は偶数" if num % 2 == 0      break "#{num} は奇数" if num % 2 == 1        "#{num} は偶数でも奇数でもない"    end        { result: }  end  p sample2(10.times)実行結果は以下のようになります。{:result=>"0 は偶数"}先ほどとは違い、resultをキーとしたハッシュオブジェクトが出力されるようになりました。ただ、値は相変わらず0は偶数という文字列のみです。つまり、break句を関数内・ブロック内で呼び出した場合は、ブロックを中断してbreakに渡された値を返しますが、関数は引き続き実行されます。中断する範囲がreturn句とは異なることに加えてbreak句が値を返すことができるというのも特徴的なポイントと言えます。break句で一歩前進したものの、依然としてresultの値が文字列配列になっていないのでnextで書き直してみました。code:sample3.rb  def sample3(array)    result = array.map do |num|      next "#{num} は偶数" if num % 2 == 0      next "#{num} は奇数" if num % 2 == 1        "#{num} は偶数でも奇数でもない"    end        { result: }  end  p sample3(10.times)実行結果は以下の通りです。{:result=>["0 は偶数", "1 は奇数", "2 は偶数", "3 は奇数", "4 は偶数", "5 は奇数", "6 は偶数", "7 は奇数", "8 は偶数", "9 は奇数"]}ようやくresultの値が10個の文字列配列をもつハッシュオブジェクトになりました。この実行結果を見るとわかることとしてnext句はブロックのループ処理は中断せず、呼ばれた際にブロック内部の後続処理をスキップします。また、breakと同様にnextも値を返すことができます。ここでわかったことをまとめます。 return: ブロックのループ処理も関数も中断して値を返す break: ブロックのループ処理を中断して値を返す next: ブロック内のループ処理結果として値を返し、次のループを開始する（ループ処理は中断されない）さまざまな言語に触れていると、このような微妙な条件の違いに混乱し時に思わぬ結果をもたらします。このようなミスを犯さないように、実務ではテストコードを書いていくことが大切です。冒頭のTypeScriptの例で言えば、breakやcontinueに渡せるものとしてラベルがあります。ラベルを使うことで、どの範囲のブロックを中断するかを明示的に指定することができます。TypeScriptのラベルについてはこちらを参照してください。Rubyには、breakやnext句にラベルを使って中断先を明示的に指定することはできませんが、代わりにcatchとthrowを組み合わせて似たようなことができます。code:label.rb catch (:done) do   5.times { |i|     5.times { |j|       puts "#{i} #{j}"       throw :done if i + j > 5     }   } endhttps://stackoverflow.com/a/1352143 より引用あまりこのようなコードを目にする機会は多くないかもしれませんが、覚えておくと良いかもしれません。

Ruby の return に注意しながら next と break をうまく使い分ける

去年末ごろから台湾中国語（台湾華語）を真面目に勉強するためにレッスンを受けています。オフラインのマンツーマンレッスンが中心ですが、オンラインのZoomレッスンも受けたことがあります。オンライン・オフラインに関わらず、データは録音して保存していて、自分で聞き直して発声練習をしたり、文字起こしをして読み直すことで効率をなるべく高めようと努力しているのですが、今回はその「文字起こし」に関して最近自分がやっている方法について解説します。なお、オフラインレッスンにおいては、スマホやレコーダー等でなるべく高音質に録音したらいいだけなのですが、オンラインレッスンでの録音はなかなか簡単にはできず、一本記事にできるくらいの内容です。また後日記事にしたいと思っています。さて、自分かこれまで行っていた文字起こしの方法は、聞きながらメモアプリに入力するだけのとても非効率なものでした。しかも、外国語なので聞き取れない単語や聞いたことがない言葉・表現が出てきます。それを耳だけでやるのは限界がありました。そこで、文字起こしのサービスを使って無駄な入力時間を短縮し、自分が知らない言葉を文字にできたら（漢字さえわかれば）簡単に理解できるのではないか？と考えました。今回行うのは Google Cloud の Speech-to-Text （STT）を使った文字起こしです。STT はGoogleが良いした機械学習モデルを利用して文字起こしをしてくれます。ネットで調べてみると、日本語の記事を文字起こししてみた記事が多く出てきますが、英語はもちろん、台湾中国語でも文字起こしができます。ということで早速やってみます。録音データの整形とフォーマットまずは録音したデータをきれいにしなくてはなりません。いくつかのサポート形式がありますが、推奨されている形式で試します。サンプリングレートを16,000Hzにする。モノラル にする。音声ファイル形式を flac にエンコードする。非可逆圧縮の mp3 で録音すると、変換時に劣化するので録音時点で wav か flac で撮るように設定するのがおすすめです。wav や mp3 で録音しても最終的には flac に変換します。変換には Audacity を使っています。Audacity が読み込めないファイル形式の場合は、先に ffmpeg でエンコードしてから利用してます。この辺はまた別の記事でかけたら書きます。無音部分のトリミングノーマライズ前後の余計な部分のカットこれも文字起こしのために大切な処理となります。無音部分のトリミングは、利用料金を多少抑える役割を果たします。Google Cloudの利用準備利用方法として、Web 上の GCloud コンソールから行う方法もありますが、今回はローカルのターミナルから Python クライアントライブラリを使って実行するためのセットアップをします。なお事前にpython3が実行できる環境を用意する必要があります。クイックスタート: クライアント ライブラリの使用  |  Cloud Speech-to-Text ドキュメント  |  Google Cloudcloud.google.com利用準備に関しては、書いてもUIが更新されたりしてノイズになってしまいがちなので、公式のクイックスタートのURLを貼っておきます。手順は以下の通りです。Cloud Console プロジェクトを作成する。APIがデフォルトで全て無効になっているため、プロジェクトに対して Cloud Speech-to-Text API を有効にする。サービス アカウントを作成し（Cloud Storage の閲覧権限があれば良い）、JSON 形式の秘密鍵をダウンロードする。環境変数 GOOGLE_APPLICATION_CREDENTIALS を、ダウンロードした JSON ファイルのパスに設定する。GCloud SDK をインストール。追加コンポーネントは不要。gcloudコマンドがどこでも使えるように PATH を通しておきます。Speech-to-Text と Cloud Storage の利用準備ライブラリを使うための準備をします。録音データのサイズが非常に大きい場合、ローカルからのデータを読み込ませるとAPIがエラーを返しますので、Cloud Storage（GCS）も準備します。pip install --upgrade google-cloud-speech google-cloud-storageスクリプトの準備ドキュメントにあるサンプルコードは古いものが混ざっています。なのでGitHub上のpython3で動作するサンプルコードから、GCS のファイルも対応できるように改変しました。コードは以下の通りです。ダウンロードして保存します。キモとしては、language_codeにzh-Hant-TWを設定することで繁体中国語（台湾）の設定になります。speech_transcribe_async.pyGitHub Gist: instantly share code, notes, and snippets.gist.github.com料金料金  |  Cloud Speech-to-Text ドキュメント  |  Google Cloudcloud.google.com月ごとの請求で最初の1時間は無料です。それ以降はデフォルト設定の場合 $0.006/15 秒 です。拡張モデルとして通話に特化した学習モデルもあるのですが、料金がやや高くなります（利用したことはありませんが、今後試してみたいと思います）。実行方法ローカルファイルの場合まずはローカルファイルで試すのが簡単です。サイズオーバーのエラーが返ってきた場合は GCS を使ってみると良いです。python speech_transcribe_async.py --file_path path/to/file.flacこれで、現在のファイルに.txtファイルが新しくできていると思います。感覚値ですが、40分の音声で10分程度の時間がかかります。GCS の場合GCS 上にバケットを作り、中にデータをアップロードします。バケットの設定はロケーションをアジアに、それ以外はデフォルトでOKです。{{ blogcard “https://console.cloud.google.com/storage/create-bucket" }}その後、バケット内に音声ファイルをD&Dでアップロードしたら準備完了。ターミナルで以下のコマンドを実行します。python speech_transcribe_async.py --file_path gs://bucket名/file.flacこれで、ローカルファイルの時と同様に現在のファイルに.txtファイルが新しくできていると思います。まとめ準備がやや大変ですが、一度設定しちゃえば音声をエンコードしてスクリプトを実行して待つだけでできちゃいます。対話の被りや日本語があると翻訳されなかったり、。や、がないので手動で補正してやる必要はありますが、初めて聞く単語が漢字で確認できたり、全体像が把握できるので非常に役立っています。この方法はレッスンに限らず好きな動画の音声を入れて勉強に役立てるなど、様々な使い道がありそうです。

語学のための文字起こし

HugoとAcademicテーマを使ってブログを構築したのはいいのですが、すぐに欲しい機能がないことに気付きました。それは「ブログカード」です。ブログカードというのは、以下のようなURLの埋め込み表示形式のことをいい、これがないとURLの文字列の表示だけになってしまい（またはマークダウンで文字列リンクとするだけ）、なんとも寂しい表示になってしまいます。Wada NotesSoftware Engineerwada.pageこのブログカードを作る方法についてですが、Hugoのデフォルト機能には入っておらず、基本的には自作するほかありません。また自作するにあたっては、Hugoの機能であるShortcodeを用いて解決することが可能です。ShortcodeとはShortcodeというのは、マークダウンテキスト内に書けるSnippetのことで、ビルド時にSnippetのテンプレートからhtmlを生成して埋め込んでくれます。デフォルトでもTwitterのツイートやinstagramの投稿などいくつかのソーシャルメディアに対応するShortcodeがあります。今回はこのShortcodeを使ってブログカードのSnippetを作ろうという試みです。仕組みまず、ブログカードを作るために必要なものとして、metaタグの解釈があります。URLそのものから遷移先のページタイトルや画像などを取得する必要があるためです。幸い、Shortcodeに対応するテンプレートhtmlを作る際、テンプレート内で getJSON というJsonリクエストをできる関数が用意されているためこれを使えば特定のURLからogpのmetaタグをパースしたJsonを返してそれを用いることができそうです。URLにアクセスしてタグをパースしてJsonで返却するAPIは、今回はNetlify Functionsを使うことにしました。理由はデプロイにNetlifyを使っており同じサービス・同じアカウントで機能を使った方が楽だと思ったからです。また、利用するのはビルドする時だけで、一度要素が取得できればキャッシュされるということで、無料枠の範囲内で十分事足ります。実装手順本記事では、Hugo+AcademicテーマをNetlifyでデプロイしている前提で説明します。また、執筆時点のNetlify Functionsは NodeJS12.x が対応していますので、NodeJS12 の環境を作っておく必要があります。Netlify Functions環境のセットアップまず、執筆時点でのNetlifyのデフォルト環境では NodeJS10.x で実行されますので、それを12にするために環境変数を設定します。Netlifyにログインし、Site dashboardから、Settings > Build & deploy > Environment > Environment variables の順に進み、以下の環境変数を入れておきます。他の方法を知りたい方はこちらを確認してください。Build environment variablesNetlify builds, deploys, and hosts your front end.Learn how to get started, see examples, and view documentation for the modern web platform.docs.netlify.com今回は、 src/functions/ にFunctionsのソースファイルを置き、 functions/ にビルドしたFunctionsファイルを置く設定にします。まずはファイルだけ作っておきます。mkdir -p src/functions functions#名前はhoge.jsとしていますが、任意のもので構いません。touch src/functions/hoge.jsルートディレクトリにある netlify.toml を編集します。以下のようにfunctionsのディレクトリ指定と、hugoコマンドの実行前に後ほど設定する yarn run build を追加します。[build]command = "yarn run build && hugo --gc --minify -b $URL"publish = "public"functions = "./functions"Netlify Functionsのビルドと、Fuctions内でOGPパーサーを利用するために netlify-cli　と netlify-lambda と open-graph-scraper をインストールします。yarn global add netlify-cliyarn add --dev netlify-lambdayarn add open-graph-scraperさらに package.json に以下のscriptsを追加しておきます。{"scripts": {"build": "netlify-lambda build src/functions/","serve": "netlify dev"}}$yarn run build を実行すると、src/functions/ 内のファイルをビルドして functions/ ディレクトリにjsファイルを配置します。$yarn run dev を実行すると、WebサーバとFunctions双方のローカルサーバが立ち上がりますWebサーバ: http://localhost:8888Functions: http://localhost:34567/<Function名>例通りにやると、Function名は hoge.js です。netlify-lambda serve　という別のコマンドがありますが、legacy commandとされており、現在は上記のやり方が推奨とされています。Functionを作成するsrc/functions/hoge.js を以下のように実装します。exports.handler = (event, _context, callback) => {if ('url' in event.queryStringParameters === false) {console.error("parameter 'url' is necessary!!");return;}const url = event.queryStringParameters.url;const options = {'url': encodeURI(url)}const ogs = require("open-graph-scraper");ogs(options).then(function(data) {const metadata = data.data;console.log(metadata);let ogpData = {};ogpData['siteName'] = metadata.ogSiteName;ogpData['title'] = metadata.ogTitle;ogpData['description'] = metadata.ogDescription;if (Array.isArray(metadata.ogImage)) {const jpgUrl = metadata.ogImage.find((image) => image.url.endsWith('.jpg') || image.url.endsWith('.jpeg')).urlogpData['image'] = jpgUrl} else {ogpData['image'] = metadata.ogImage.url;}console.log(JSON.stringify(ogpData));callback(null, {statusCode: 200,"headers": { "Content-Type": "application/json; charset=utf-8"},body: JSON.stringify(ogpData)});}).catch(function(error) {console.error(error);});};event.queryStringParameters.url でブログカードに利用するURLを取得open-graph-scraperを使ってURLのmetaタグをパースパースしたデータから最低限必要なデータを取得し、Jsonを返すこれで、metaタグを解釈するAPIが完成します。Functionsサーバを立ち上げて、 curl http://localhost:34567/hoge?url=<任意のURL> とするとJsonデータが取得できるようになります。Shortcodeを作成するまずはFunctionのエンドポイントを設定しておきます。 config/_default/config.toml に設定しておくのがわかりやすいです。ローカルでのテスト時はlocalhostにしてください。[params]# OgpApiEndpoint = "http://localhost:34567/.netlify/functions/hoge?url="OgpApiEndpoint = "https://<netlifyのhost名>/.netlify/functions/hoge?url="次にacademicテーマ内にある shortcodes ディレクトリにhtmlを書いていきます。ファイル名がShortcode呼び出し時の名前になります。{{ $url := .Get 0 }}{{ $jsonData := getJSON $.Page.Site.Params.OgpApiEndpoint $url }}{{ $siteName := $jsonData.siteName }}{{ $title := $jsonData.title }}{{ $description := $jsonData.description }}{{ $image := $jsonData.image }}{{ $urlInfo := urls.Parse $url }}{{ $host := printf "%s" $urlInfo.Host }}{{ $prefix := "https://www.google.com/s2/favicons?domain=" }}{{ $favicon := printf "%s%s" $prefix $urlInfo.Host }}<div class="box"><a class="box-content" target="_blank" rel="noopener" href="{{ $url }}"><div class="box-content"><div class="box-left"><h2 class="box-title">{{ $title }}</h2><div class="box-description">{{ $description }}</div><div class="box-host">{{ $host }}</div></div><div class="box-image-container" style="background-image: url('{{ $image }}');" ></div></div></a></div>対応するCSS（SCSS）はこんな感じ。div.box {margin-top: 16px;margin-bottom: 16px;box-shadow: 0 1px 4px rgba(0, 0, 0, 0.1), inset 0 0 0 1px rgba(0, 0, 0, 0.1);}.dark div.box {box-shadow: 0 1px 4px rgba(255, 255, 255, 0.1), inset 0 0 0 1px rgba(255, 255, 255, 0.1);}a.box-content {-webkit-tap-highlight-color: transparent;text-decoration: none;color: rgba(0, 0, 0, 0.8);}.dark a.box-content {color: rgba(255, 255, 255, 0.8);}a.box-content.hover {text-decoration: none;}.dark h2.box-title {color: rgba(255, 255, 255, 1);}div.box-content {display: flex;align-items: center;}div.box-left {flex: 1;padding: 16px 20px;}h2.box-title {font-size: 18px;font-weight: 600;line-height: 20px;margin: 0;}div.box-description {font-size: 16px;line-height: 20px;margin-top: 8px;}div.box-host {margin-top: 12px;font-size: 15px;color: rgba(0, 0, 0, 0.54);line-height: 20px;margin-top: 12px;}.dark div.box-host {color: rgba(255, 255, 255, 0.2);}div.box-image-container {width: 160px;height: 167px;background-position: center center;background-repeat: no-repeat;background-size: cover;}Shortcodeを利用するここまでできたら後は呼び出すだけです。新しく記事を新規作成して、その中で上のshortcodeを呼び出します。仮にファイル名が blogcard.html とすると{ {% blogcard "<URL>" %}}のように書くことで呼び出しができます（{}のスペースは無くしてください）。という感じになります。そしてファイルを保存しビルドするときにHugoサーバがFunctionosをリクエストしてJsonを取得し、ブログカードの表示に置き換われば完成です。デプロイするここまでできたら、コミットしてプッシュします。Netlifyのデプロイタスクが自動的に実行され、Functionsの設定まで行われるので、特別にやることはありません。終わりに気になっていることとして、URLによっては望まない画像が表示されてしまうことがあります。これはまた今後Functionsに手を入れてなおしていきたいと思います。下記のサイトが非常にわかりやすく、参考になりました。Netlify Functionsでブログカードを埋め込むHugoのshortcodeを実装しました - A1 BlogはてなブログのようなブログカードをHugoで実装した話。blog.a-1.dev

Hugoにブログカードを埋め込む

今年に入ってから、新型コロナウイルスの影響が思った以上に猛威を奮っていて、外出制限や人との接触を限りなく少なくしなければならないような状況になりました。さらに私は転職の時期がちょうど重なり、この影響でオンライン面接をしたり、データでのやりとりを余儀なくされたのでした。また、4/1から入社することに決まった新しい会社にも出勤することがリスクという状態に陥り、初日からリモートワークでの入社を会社に相談したところ、PCを送ってくださり、入社関連の手続きも含めてすべてオンラインで行ってくれることになりました。さて、そんな中で、3月に「リモートチームでうまくいく」を全文公開します という記事をみて、4月の入社直前に読んでみました（4月現在は購入する必要があります）。入社後のゴタゴタとこのブログの設定に時間がかかって遅れてしまいましたが、ここで印象的だった部分を書いておきたいと思います。読んでから時間が経っているため、主観も含まれることをお許しください（またはご指摘ください）。リモートワークとは何か？リモートワークと一言にしても、いくつかの方式に分かれます。オフィスに一定の人数集まって作業しながら、ある人・ある部署のみ自宅などで作業をする形式複数のオフィス（支店のイメージ）で、それぞれ一定の人数が出社して作業をする形式全ての社員が単独で作業をする形式基本的にはリモートワークをする場合には全ての社員が単独で作業をする形式が好ましいです。何故かと言えば、後述するリモートワークをする上での難しさに対応するのが非常に難しくなるからです。また、全員が平等にリモートワークを実践することによって、リモートワーカーの気持ちを理解するのに役立つでしょう。何に気を付ければ良いのか？リモートワークをする上で重要なのは、「とりあえずやってみる」でうまくいくほど簡単ではないということです。やる上で守るべきこと、協力し合う姿勢が非常に大事になってきます。当然これはオフィスワークでも同じように互いに協力し合う必要があって、チームワークを作っていく努力をしなければなりません。それがリモートになったからといって変わるものではありません。その上で、リモートワークの特性としてとくに気をつけた方が良い点についてまとめていきます。情報格差をなくすリモートワークをしていると、無自覚のうちに情報格差を産んでしまう場合があります。とくに拠点間のリモートだと、例えばドキュメントや議事録が会社にいる人しかアクセスできない場所に置かれていたり、現場の話し合いでコトが先に進んでしまう場合があります。このような情報格差は情報を持ってない人には気付きにくく、後になってトラブルになったり仕事をしにくい状況が生まれてしまいます。情報格差をなくすために、以下の事柄を意識してみると良いです。ドキュメントを社内の人が誰でも閲覧できる場所に置くドキュメントを残すミーティングは誰でも傍聴可能なものとするチャットツールでのコミュニケーションから始めるオンとオフの切替は人によって自由でありそれを許容する自宅での作業をしていると、オフィスではあり得なかった様々な割り込みが入るようになります。家族からの割り込み家事を手伝って欲しい子供の割り込み宅配荷物がくる上記のような問題は、家族への協力をお願いすることである程度の解消が見込まれます。しかし、子供の世話や宅配などの突発的な問題は自分だけで制御できるものではなく、実際に私の同僚の家庭では仕事中に泣いた子供をあやしに行ったりおむつを交換しにいくことがあります。このような問題は、一見するとけしからんと言われるような出来事かもしれませんが、リモートワークの働き方として、時間に縛られないというのは大きなメリットであって柔軟な働き方を尊重するべきです。例えば、10分中断しなければならないとなれば、代わりに10分別の時間を確保すればいいだけです。人によっては中断によって集中力が切れてしまう場合もあるでしょう。その時は仮眠をとったり、いっそ別のことをして気分をリフレッシュした後、仕事に戻って集中すればいいのです。当然長期中断の場合は先に報告するなど最低限のマナーは必要です。そのような心がけがあれば、お互いが気持ちよく自由な時間に作業をするということが実現できます。リモートワークをする上で大切なことリモートワークを始めると気づくことがあります。オフィスに出勤していた時は挨拶をし、休憩中は雑談をし、何気ない話で盛り上がったりします。オフィスをひと目見れば誰が会社にいて誰が会社にいないかがすぐにわかります。しかし、リモートワークをすると基本的に仕事の話以外はしなくなりがちです。また周りを見渡しても誰が働いているのかがすぐにわかりません。これら2つの事柄は人間同士のコミュニケーションを阻害し、孤独感を生みやすくなります。つまり、リモートワークにおいても雑談が行われる環境を作り、存在感を出していくことが重要なのです。雑談とは、ここでは目的や結論を決めない会話のことを指します。普段思っていることを話したり、誰かに聞きたいことを聞いたりします。このような会話は一見無駄のように見えますが、実はこう言った何気ない雑談の中から思わぬアイデアが浮かんだりするのです。そして、それがビジネスにつながったり、イノベーションを起こすヒントが生まれます。成功しているビジネスの半分以上が雑談から生まれているということでその大切さがわかります。そのほかにも、雑談そのものがその人の存在感を生みますし、チームの助け合い文化が作りあげられます。雑談を推奨する企業文化を醸成する方法として以下のような方法をとっています。勤怠を習慣づける（挨拶や日記などを書く）物理出社と論理出社を定義するなるべく同じような時間帯にする日記やポエムがチームの課題を早期発見するのに役立つリモートワークでは出社時に直接顔を合わせることがなく、自宅でなんとなく仕事を初めてなんとなく仕事を終わるということができてしまいます。しかし、それだとチームメンバーには今誰が働いているのかということが伝わらないので、声をかけて良いのかどうか戸惑ったり、来るかどうかわからない返信を待ち続けるといった問題が発生することがあります。そういうエラーを防ぐために、論理出社を定義するとよいです。例えば、作業開始時にSlackで挨拶するとか、Google MeetsやZoomなどのビデオ通話ツールで顔を見せて挨拶をしてから作業に取り掛かるのです。そうすることで誰がいるのかということは見ればわかりますし、ビデオ通話ツールであればすぐに会話することが可能です。最後に4月から新しい会社に完全フルリモートで働き始めましたが、過去にリモートワークを失敗した経験のある自分にとっては、不安でいっぱいでした。しかし世の中の現状と鑑みれば、その波に逆らうこともできず、また家族を持つ同僚のことを考えればリモートワークという働き方には大きなメリットがあるのも確かで、ならばせめて成功体験者の話を知ってからでないとと思った矢先に本書籍の無料公開記事を見つけたのでした。現在も多くの方が同じような状況で働いておられるのではないかと思います。そういう方のために少しでも役に立てればいいなと思います。また、本記事を読んで気になった方はぜひ書籍を購入してみてください。リモートチームでうまくいく | 倉貫 義人 |本 | 通販 | AmazonAmazonで倉貫 義人のリモートチームでうまくいく。アマゾンならポイント還元本が多数。倉貫 義人作品ほか、お急ぎ便対象商品は当日お届けも可能。またリモートチームでうまくいくもアマゾン配送商品なら通常配送無料。amzn.toまた、しばらくは弊社で現在行っているリモートワーク関連の話について書いてみようかなと思います。

リモートワーク導入のノウハウ

今回新たにBlogを立ち上げてみました。過去にはJekyllを使って、独自ドメインをとってGitHub Pagesで公開していましたが、ドメイン失効や環境移行を忘れいろいろなものを失って、諦めてエイヤと捨ててしまったりして、過去の資産が消えてしまいました（無論、その当時書いていた技術記事は今となってはほとんど参考にならないものではありますが…）。その後、月日が経ち今回新しく全てを作り直して立ち上げることにしました。そして今回採用したのはHugo+Academicです。HugoはStar数が執筆時点で★43094と非常に人気があり、JekyllのStar数を超えています。Goで実装されており活発な活動も行われているため困ることはないだろうと思い確定しました。Hugoと決めたら次はThemeで悩みました。そもそもおしゃれか、とか、日本語はCJKの問題があるのでフォントが簡単に変えられるか、または特殊なフォントを用いていないか、更新が活発に行われているかなどを念頭においていくつかデモを試してみましたが、どれも不安要素が拭えず、難儀しておりました。しかし、ここは長いものに巻かれよう、ということで最終的にはStar4000超えのAcademicテーマを使うことにしました。Academicの魅力については公式ページに書いてありますが、主に自分が使ってみて良かった点を挙げてみます。ポートフォリオやプロフィールも簡単に書けるテンプレートが用意されているSEO対策・OGPタグが正しく設定されている（できる）スタイルがカスタムできて、Google Fontを簡単に設定できる。なのでCJK問題も対応できるおしゃれNetlifyとの親和性が高く、Pushして自動デプロイするまでのCI/CD・SSL化を超簡単に導入できる最後にホスティングの場所ですが、元々はFirebaseでやろうと思っていました。HugoはFirebaseもサポートしているため使えます。しかし、AcademicではNetlifyを推奨しており、また個人的には一度もNetlifyを触ったことがなかったため、今回初めて使ってみることにしました。NetlifyはHugoとの親和性が非常に高く、アカウントを作成してGitHubとの連携をするだけですぐにCI/CD環境が出来上がります。その後、ドメインの購入とDNSの設定もNetlify内で手軽にできるようです（今回はGoogle Domainsでドメインを購入しました）。またSSL化はボタンをタップするだけで自動的に設定されます。超便利。終わりということで、今回はBlogを新たに立ち上げた時に使ったものを書いてみました。技術的なセットアップは公式が一番わかりやすいと思うので書きませんでしたが、需要があれば書いてみようと思います。この手のブログ記事は続けることが一番難しくて一番大事なことだと思っているので、小さな記事でもちょこちょこと書いていけたらなと思っています。また書評も書いていきたいと思ってます。参考概ね情報が日本語でまとまっている記事https://qiita.com/peaceiris/items/ef38cc2a4b5565d0dd7c