このコーナーでは、2014年から先端テクノロジーの研究を論文単位で記事にしているWebメディア「Seamless」（シームレス）を主宰する山下裕毅氏が執筆。新規性の高い科学論文を山下氏がピックアップし、解説する。 X： ＠shiropen2 普段感じている時間は、過去から未来へと一方向にしか流れていかない。このような時間が一方向に進む概念を「時間の矢」と呼び、物理学の未解決問題の一つとしている。この時間の矢を説明する新しい考え方を提案したのがこの研究である。 この論文では、宇宙が始まったときには「量子もつれ」は少なかったと主張（宇宙の初期状態が非常に低いもつれエントロピーを持つ状態であったという仮定）しており、これを「量子もつれの過去仮説」（Entanglement Past Hypothesis、EPH）と呼んでいる。 「量子もつれ」とは、2つ以上の量子がどんなに遠く離れていても互いに強

この記事は Vim 駅伝 の 06/05 の記事です。 前回の記事は thinca さんによる、 06/03 の「Meguro.vim #23 を開催しました」という記事でした。 次回は 06/07 に投稿される予定です。 はじめに 本記事は以下の記事のオマージュです。 Vim の基本操作のうち、比較的マイナーながら汎用的に使える機能や小技を集めました。プラグインや複雑な設定が必要なものは含まれておらず、いずれも Vim と Neovim の両方で使うことができます。気になったものがあれば使ってみてください。 ノーマルモード編 検索結果を次々と置き換える Vim で文字列置換を行う最も有名な方法は :substitute コマンド （短縮形: :s） ですが、ノーマルモードの cgn というイディオムも便利です。これは c オペレータと gn テキストオブジェクト (:h gn) を組み合

公益財団法人日本デザイン振興会は、各都道府県や企業、行政などのデザインに関する多様な取り組みを網羅的に取りまとめたレポート「デザイン白書2024（WHITE PAPER ON DESIGN 2024）」を2024年6月4日（火）に公開しました。 背景・経緯 経済産業省と特許庁は2018年に『「デザイン経営」宣言』を発表し、日本の産業競争力強化のために、デザインを企業価値向上のための重要な経営資源として活用する「デザイン経営」を推進することを提言しました。その後、大企業や中小企業、スタートアップ、官公庁などでデザイン活用が進み、経済産業省デザイン政策室はデザイン活用をさらに拡大するために、2023年に「これからのデザイン政策を考える研究会」を開催しました。研究会では、2023年度・2024年度グッドデザイン賞審査委員長の齋藤精一氏が座長を務め、当会からは深野弘行理事長、柴田文江理事、田川欣哉

口座開設に関するお問い合わせは、はじめてのお客様専用ダイヤル（0120-566-166）へお問い合わせください。 平日 8：40～17：10 土日 9：00～17：00（祝日・年末年始を除く） ご利用の際には、電話番号をお間違えのないようご注意ください。 手数料等およびリスクについて 当社で取扱う商品等へのご投資には、各商品等に所定の手数料等（国内株式取引の場合は約定代金に対して最大1.43％（税込み）（20万円以下の場合は、2,860円（税込み））の売買手数料、投資信託の場合は銘柄ごとに設定された購入時手数料（換金時手数料）および運用管理費用（信託報酬）等の諸経費、年金保険・終身保険・養老保険・終身医療保険の場合は商品ごとに設定された契約時・運用期間中にご負担いただく費用および一定期間内の解約時の解約控除、等）をご負担いただく場合があります。また、各商品等には価格の変動等による損失が生じ

このコーナーでは、2014年から先端テクノロジーの研究を論文単位で記事にしているWebメディア「Seamless」（シームレス）を主宰する山下裕毅氏が執筆。新規性の高い科学論文を山下氏がピックアップし、解説する。 X： ＠shiropen2 普段感じている時間は、過去から未来へと一方向にしか流れていかない。このような時間が一方向に進む概念を「時間の矢」と呼び、物理学の未解決問題の一つとしている。この時間の矢を説明する新しい考え方を提案したのがこの研究である。 この論文では、宇宙が始まったときには「量子もつれ」は少なかったと主張（宇宙の初期状態が非常に低いもつれエントロピーを持つ状態であったという仮定）しており、これを「量子もつれの過去仮説」（Entanglement Past Hypothesis、EPH）と呼んでいる。 「量子もつれ」とは、2つ以上の量子がどんなに遠く離れていても互いに強

SPAのアプリケーションで、外部のIdPを使ってOpenID Connect によるログイン機能を開発しようと考えています。IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。調べた限り、サーバーサイドで持つべきという意見が多いように見えますが、以下のような背景がある中で開発しても、ブラウザのCookieでは持つべきなのではないのでしょうか？ - IDトークン自体にも、個人の属性（氏名等）情報は無いことを確認している - サーバーサイドでIDトークンの署名検証をして、IDトークンの改ざんが無いか確認する - Http Only属性：JSによるCookieへのアクセスを防ぐため - Secure属性：流出防止のため - SameSite=strict：CSRF対策のため 結論から言えば、「どちらでもよい」となります。しかし、恐らく話は

コンテナをリクエスト処理時間ベースの料金体系で実行できるサーバレス環境としては、Google の Cloud Run（2019年11月GA）と AWS Lambda（2020年12月にコンテナに対応）が特に有名でしょう。 これらの環境は、一度起動したコンテナインスタンスをしばらく生かしておき、その後のリクエストに使いまわします。しかし、生きているインスタンスが足りない場合は新たなコンテナの起動から始めるいわゆる「コールドスタート」となり、応答のオーバーヘッドが大きく増加します。用途によっては、このコールドスタートにかかる時間が問題になります。 Cloud Run と Lambda でのコールドスタートの様子を観察するため、いくつかの言語で "Hello, World!" を返すだけのWebアプリコンテナを作り、コールドスタートの時間を「雑に」観察してみました。 注意: コストや性能は考慮し