Composeファイルを拡張する
みなさん、こんにちは。小林です。 今年のGWはどのように過ごされましたか？ 私はコーディング三昧の毎日でした。(仕事じゃないですよ。趣味ですよ。) 新しい現場で困っていることがあったので、その回避方法を紹介したいと思います。 今回は、Dockerの話をします。 困っていること 実際に困っていることは、現場固有のものなので少しわかりやすくしていますが、こんな感じです。 本番環境を再現するために、ローカル環境に大量のデータをインポートしないといけなくて、データの入れ替えに時間がかかってしまう。 回避策 Dockerを使用しているので、volumeの設定を切り替えることができればよいのではないか、と考えました。 Git管理されているComposeファイルは以下とします。 # compose.yml version: "3" services: db: image: postgres:14.6 environment: (省略) volumes: - db_data:/var/lib/postgresql/data volumes: db_data: 案1：Composeファイルを編集する 既存のComposeファイルを使用するデータに応じて書き換えるようにしました。 # compose.yml version: "3" services: db: image: postgres:14.6 environment: (省略) volumes: - db_data_prod:/var/lib/postgresql/data volumes: db_data_prod: Git管理されている場合に差分として扱われてしまうので、気軽にgit add .できなくなってしまうので、微妙でした。 案2：Composeファイルをコピーする 既存のComposeファイルをコピーして、データに応じて使い分けるようにしました。 docker-compose -f compose.mine.yml up -d さらに、グローバルの.gitignoreに該当ファイルを設定することで、案1の問題点も解消できました。 # compose.mine.yml version: "3" services: db: image: postgres:14.6 environment: (省略) volumes: - db_data_prod:/var/lib/postgresql/data volumes: db_data_prod: もう少し上手くできないかな、と思って調べたところ、Composeファイルを上書きできるということがわかりました。 Composeファイルの内容を上書きする(compose.override.yml) # compose.override.yml version: "3" services: db: volumes: - db_data_prod:/var/lib/postgresql/data volumes: db_data_prod: Composeファイルを複数指定した際に、各ファイルの内容が上書き・マージされるそうです。 docker-compose -f compose.yml -f compose.override.yml up -d なので、最小限の設定を記載するだけ、案2と同じことができるようになります。 ちなみに、ファイル名をcompose.override.ymlにすると、-fオプションで指定しなくても、compose.ymlと一緒に読み込まれます。 参考 Compose 設定をファイルとプロジェクト間で共有
timestampsマクロとは何者なのか？
みなさん、こんにちは。 今年は久しぶりに花粉の影響が強く苦しんでいる小林です。 また一つ、Ruby on Rails(以下、Rails)の謎が解けたので、紹介したいと思います。 今回のテーマは、こちらです。 timestampsマクロは何をしているのか？ timestampsマクロは何をしているのか? timestampsマクロとは何か？ timestampsを呼び出すと作成日時(created_at)、更新日時(updated_at)を自動的に作成してくれます。 # db/migrate/2023032562631_create_products.rb class CreateProducts < ActiveRecord::Migration[7.0] def change create_table :products do |t| t.string :name t.text :description t.timestamps end end end sample=# \d products id | bigint | | not null | nextval('products_id_seq'::regclass) name | character varying | | | description | text | | | created_at | timestamp(6) without time zone | | not null | updated_at | timestamp(6) without time zone | | not null | (↑うまく整形できなかったので、諦めました。) Railsガイドにも記載されています。 timestampsマクロは、created_atとupdated_atという2つのカラムを追加します。これらの特殊なカラムが存在する場合、Active Recordによって自動的に管理されます。 引用：Railsガイド#1 マイグレーションの概要 使用する分にはこれで十分なのですが、中で何をやっているのだろうと気になってしまったのが事の始まりでした。 何をしているのか？ 結論から言うと、さほど複雑なことはしていませんでした。 active_record/connection_adapters/abstract/schema_definitions.rb#L460-L469 def timestamps(**options) options[:null] = false if options[:null].nil? if !options.key?(:precision) && @conn.supports_datetime_with_precision? options[:precision] = 6 end column(:created_at, :datetime, **options) column(:updated_at, :datetime, **options) end 要は、自身で以下のように書けるけど、timestampsマクロを使用すれば、記述量が減らせて楽ですよ。ということです。 # db/migrate/2023032562631_create_products.rb class CreateProducts < ActiveRecord::Migration[7.0] def change create_table :products do |t| t.string :name t.text :description t.datetime :created_at, null: false, precision: 6 t.datetime :updated_at, null: false, precision: 6 end end end 最後に 今回は、仕組みが複雑怪奇というよりも、どこで定義されているかが見つけられずにもやもやしていたので、読み込みが足りないなと痛感しました。
RFC2119を斜め読みしてみる
こんにちは。 株式会社ウィルドの豊田です。 いよいよ新年度がスタートしましたね。 昨年度は採用活動に注力しましたが、なかなか結果に繋げられず辛い思いをしました。 今年度は良い一年になることを願って、頑張っていきます！ さて、今回のブログはRFC2119（ちょっとだけRFC8174）を、英語力ゼロの私が読んで自分なりに解釈してみたよ。という内容でお届けしたいと思います。 RFC2119って？ RFC2119は、1997年に「Key words for use in RFCs to Indicate Requirement Levels」（RFCで使用される要求レベルを示すキーワード）というタイトルで発行されたRFCで、IETF（当時のNetwork Working Group）が発行しています。 この文書では、技術仕様やプロトコルの標準化に関する文書（主にRFC）で使用される、要件レベルを示すキーワードの定義と使用方法が説明されています。 元々はRFC（IETF）での利用を目的としたものでしたが、現在では様々な団体の仕様策定文書の中で利用されています。エンジニアの方々なら比較的目にする機会が多いのではないでしょうか。 ※ちなみに、機能の「仕様策定者」と「利用者」の観点で捉え方が変わるため、今回は「仕様策定者」の観点で解釈しています。 1. MUST まず、"MUST" 。英単語の意味そのままって感じです。 絶対に守るべき条件であることを意味します。 特にこの項目については書くこともないですね。 同じ意味で、"REQUIRED", "SHALL"も利用される場合があります。 2. MUST NOT 次に "MUST NOT"。これは "MUST" の逆ですね。 絶対に行ってはならない禁止事項であることを意味します。 こちらも "MUST" 同様、シンプルにそのままの意味です。 同じ意味で、"SHALL NOT"も利用することができます。 3. SHOULD 次は "SHOULD" ですね。 "MUST" ほどの強制力は無いものの、遵守することを強く推奨する仕様であることを意味します。 守らなくても一応動くように作ってある機能につけるキーワードですかね。 開発側は、この仕様を守らなかった場合に発生するリスクをきちんと説明し、利用者側に正しく判断してもらうための十分な情報を提供しなければいけません。 同じ意味を持つキーワードとして "RECOMMENDED" があります。 4. SHOULD NOT こちらは "SHOULD" の逆の意味ですね。 禁止...とまではいかないものの、明確な理由がない限り利用を避けるべき仕様であることを意味します。 SHOULD同様、仕様策定者は、避けるべき仕様である理由をきちんと説明しなければなりません。 同じ意味を持つキーワードとして "NOT RECOMMENDED" があります。 5. MAY 最後は "MAY" です。 これは、利用してもしなくても、どちらでも良い仕様につけられるキーワードです。 仕様策定者に対する注意事項として「利用者がどちらの選択をしたとしても、問題なく動作するように作り込まなければならない。」みたいなことが書かれていました。 同じ意味を持つキーワードとして "OPTIONAL" があります。 6. Guidance in the use of these Imperatives 一応、キーワードの定義としては "MAY" までなのですが、RFCには続きがあるので、一応サクッと読んでみます。 Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. このメモに定義されているタイプのキーワードは、注意深く、控えめに使用されなければならない。特に、相互運用のために実際に必要な場合、または害を及ぼす可能性のある動作を制限する場合（例えば、再送信の制限）にのみ使用しなければならない（MUST）。例えば、相互運用のために必要でない特定の方法を実装者に押し付けるために使用してはならない。 （Translated by DeepL翻訳ツール） （ここでいう「実装者」は利用者のことです） ここまでのキーワードの利用に関する注意事項のようです。 本来SHOULDなのに、MUSTであるかのように書いちゃダメ（嘘をついて実装方法を押し付けちゃダメ）ですよ。って感じですかね。 この文章の中で既に「MUST」が使われているあたり、個人的には洒落がきいてるなーと思います。 7. Security Considerations 最後です。 These terms are frequently used to specify behavior with security implications. The effects on security of not implementing a MUST or SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be done may be very subtle. Document authors should take the time to elaborate the security implications of not following recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification. これらの用語は、セキュリティに影響を与える動作を指定するために頻繁に使用されます。 MUSTやSHOULDを実装しない、あるいは仕様でMUST NOTやSHOULD NOTとされていることを行うことによるセキュリティへの影響は、非常に微妙なものである場合がある。文書作成者は、推奨事項や要求事項に従わない場合のセキュリティへの影響について、時間をかけて詳しく説明する必要がある。なぜなら、ほとんどの実装者は、その仕様を作成した経験や議論の恩恵を受けていないからである。 （Translated by DeepL翻訳ツール） （ここでいう「実装者」は利用者のことです） 日本語がちょっと？？な部分もありますが、基本的に「"SHOULD" や "SHOULD NOT" などの定義を守らずに実装した場合、セキュリティ面でのリスクは、それほど無いケースが多い」（本当に？）ので、そのあたりの内容は、仕様策定者（ドキュメント著者）側が丁寧に説明すべき。ということみたいです。 ちなみに RFC2119に準拠したドキュメントは、冒頭で以下のフレーズを組み込む必要があるそうです。 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 確かにSemVerやInfra Standardのページにも、このコメントが組み込まれていました。 キーワードのバリエーション "MUST"のエイリアスとして"REQUIRED"や"SHALL"が定義されているように、キーワードにはバリエーションが定義されていることがわかります。 ただ、実際のところは "MUST" , "MUST NOT" , "SHOULD", "MAY" の4つくらいで十分で、実際にそれだけに限定しているドキュメントもあるようです。（WHATWGの"Infra Standard"） ドキュメント毎の説明をちゃんと読まないといけませんね。 大文字とか小文字とか RFC2119では、キーワードを "MUST" や "SHOULD"、"MAY"など大文字で書いていますが、RFC内で「大文字で記述すべし」とは定義していなかったりします。 実はその後2017年に発行されたRFC8174で「大文字の時だけRFC2119のキーワードとしての意味を持つ」と明確に定義してたりするんですが、RFC2119ほど広く受け入れられなかったようです。 （「RFC8174が定義以前の多くの文章（大文字も小文字も混在して使われていた頃）の習慣を維持したい」という動機らしい？諸説アリ） 実際、多くの団体から参照されているWHATWGの"Infra Standard"においては、RFC8174の定義に故意に違反している旨が明記されています。 そのあたり、ChatGPTさんはどのような見解なのか聞いてみました。（有料ユーザーになったので、4.0をただ使いたかっただけ） なるほど。英語の文章として読みづらくなることを嫌ったということなんですね。 まとめ 今回はRFC2119の内容を斜め読みしつつ、他のドキュメントへの影響についても見てみました。 各団体の考えは様々ですが、その人たちが標準化してくれた仕様のおかげで、今のITの世界があると考えると、とても興味深い世界ですね。 ※冒頭のRFCの画像は e-words.jp のサイトから拝借しました m(_ _)m
谷根千を満喫してきた話
こんにちは。最近USキーボードとJISキーボードの二刀流を始めた浅野です。 先日会社の近くで面白い体験をしてきたので、今回はそれについて書きたいと思います。仕事いっさい関係なしの完全プライベートな内容になりますが、ご了承ください。 みなさん「谷根千」って聞いたことありますか？文京区と台東区に位置する「谷中」「根津」「千駄木」の3つのエリアのことで、食べ歩きグルメや東京の下町風情が楽しめるとして人気のスポットです。弊社のオフィスも台東区にあるので、遊びに行きやすいところにあります。 先日この谷根千を、着物を着て人力車で巡る、という贅沢な遊びをしてきました。綺麗に着飾ってレトロな街並みを楽しむなんて我ながら粋なことしているな〜と思いながら楽しんできました(笑) 当日は、谷中にある写真館と美容院、石鹸屋さんが１つになった「だんだん」さんというお店で、着物選びからスタート。着物はたくさんの種類から気に入ったものを選べたのですが、どれも可愛いものばかりで、かなり悩みました。着物を選んだ後も、帯や帯締めの色でまた迷う。。。でも迷うのが楽しいんですよね〜お店の人と相談しながら、一つ一つ決めていきました。洋服とはまた違った感覚で組み合わせを考えていくのは、新鮮で楽しかったです。 着付けとヘアセットをしてもらったら、お待ちかねの人力車。幸いお天気に恵まれ、日差しが暖かい絶好の人力車日和でした。とはいえこの日は12月。人力車の方が毛布やカイロを用意してくださっていました。これが下町人情！細やかにお心遣いいただいたおかげで、外でも暖かく過ごせました。 コースとしては、江戸幕府15代将軍の徳川慶喜や渋沢栄一などが眠る谷中霊園や、大仏様のいる天王寺を通って、谷根千エリアを一周するというものでした。人力車の方に街を案内してもらいながら、各所で写真を撮ってもらえます。 また道中で気になるお店があれば、立ち寄ってドライブスルーできるとのことで、私たちもクラフトビールをテイクアウトしました。のんびり人力車に乗りながら飲むお酒は最高でした^^ 1時間弱の散策が終わったら、その後は自由時間。夕方までに着物を返却すればOKとのことだったので、そのまま谷中ぎんざ商店街を楽しみました。 美容室の方おすすめのスイス料理のお店に行ったり、いつも行列ができている和栗専門店でモンブランを食べたりしてきました。こちらのモンブラン、栗の味が濃厚でめちゃくちゃ美味しい！ 他にも商店街には美味しそうなお店がたくさんありました！お腹に余裕があればもっと食べたかった。。。本当は人力車の方におすすめいただいたお蕎麦屋さんにも行きたかったのですが、「和装でスイス料理ってなんか粋」となり、今回は断念。とても美味しいとのことなので、次回リベンジしたいと思います。 こんな感じで谷根千エリアを楽しんできました。落ち着いた雰囲気の街なので、のんびり過ごすにはうってつけだと思います。 今回の着付けと人力車のイベントは、「だんだん」さんで不定期開催しているそうです。興味がある方は、お店のホームページをチェックしてみてください。
ウィルドってどんな会社？
皆さん、こんにちは。 小林です。 早いもので新年が明けて、すでに1ヶ月が経ってしまいました。 そして、次の4月になると、私はウィルドに入社して丸3年になります。 今回は、ウィルドがどんな会社なのかを紹介したいと思います。 そもそも小林ってだれ？ 私は文系大学の出身なのですが、たまたまプログラミングの授業に出会い、それ以来プログラムの虜になりました。 大学を卒業し、入社したのはSIerの3、4 次受けで仕事を行う会社でした。 最初のうちは未経験ということもあり、サーバ、ネットワーク、DB、プログラミング言語と必要な技術を勉強し、周りに追いつこう必死でした。その甲斐もあり、そこそこのエンジニアにはなれたと自負しています。 しかし、7年も働くと色々な疑問や不満が生まれてしまいました。 自分と他人(他社)とのスキルの差がありすぎる 実装に無駄が多く、最適化されていない 商流が上の会社からの意見が優先されて、現場の意見が通らない 本当に顧客のことを考えたとは思えない機能がある etc できることが多くなっていくにつれて、思うように仕事ができなくなってしまい、そんな時にかつての先輩に相談したところ、ウィルドに誘われ、そのまま入社しました。 ウィルドって？ さて、自己紹介も終わりましたので、ここからが本題です。 まず、ウィルドを一言で表すのであれば、生粋の職人です。 高い技術力を有する人たちが集まり、常に顧客の要望以上のことを達成するために、全力を尽くしていく。 ウィルドと仕事をすることが、顧客にとって最善でないのであれば、別の手段・会社を提案することもあります。 時には顧客や仲間に対しても厳しいことを言うこともあります。間違っていることは間違っていると指摘し、あるべき論を語り、そして現実的な落とし所を模索していく。 それはひとえに「より良くするために」なのです。そして、何よりそれを全員が体現しているのです！！その姿は正に職人としか表現できませんでした。 社員1人ひとりは興味・趣味・主張も様々なのですが、それらが大越社長が掲げた「期待される存在となり、困っている人を助けよう」という理念の元で同じ方向に向かって、大きな力となり、突き進んでいます。 興味・趣味・主張が違うからこそ、今までにない体験をすることができます。 私自身、IoTに興味を持ったり、3Dプリンタを触ったりするなど、今までの自分ではあり得ないことでした。 会社としても、社員を大事にしてくれており、それらへの挑戦の後押しもしてくれます。 他にもたくさんの魅力があるのですが、長くなってしまうので、ここではお伝えしきれません。 気になる方は、ぜひカジュアル面談等で気軽に聞いてください。 最後に ウィルドには、技術に真摯に向き合うエンジニアがたくさん所属しています。 置いていかれないか、追い抜かれないかと戦々恐々する日々を過ごしていますが、それでも私は楽しく仕事をしています。 私たちは一緒に働くエンジニアを募集しています。 少しでも興味を持った方は、ぜひこちらからご連絡ください。 一緒に戦々恐々する日々を送りませんか？笑