タグ

2023年5月28日のブックマーク (9件)

  • 息子が工業高校生に憧れているらしい

    息子5歳は、ほんの少しでも環境が変わるとかたまって動けなくなって泣いてしまう。幼稚園での行事もいつも1人だけずっと泣いて何もしない。4月になり、クラスが上がりお昼寝がなくなったこと、お箸で給べるようになったことなどが不安で、夜泣きをするようになった。幼稚園にも泣きすぎて吐いたりするので、いけない日も多々あった。週末は家から一歩も出たがらず、自分の好きな車のおもちゃを分解して過ごす日々だった。 そんな息子をなんとか誘い、近所の大きな公園でしてるフェスタみたいなところへ行った。バザーや出店が出ていて、そこに工業高校の展示のようなスペースがあった。息子が少し離れたところで、展示されている1人用の車をみていた。「図鑑でも見たことない車」「1人しか座れない」などと喋っていた。 高校の生徒さんが、こんにちはと声をかけてくれたけれど、息子はもちろん返すことがで気なかった。それでも生徒さんはニコニコ

    息子が工業高校生に憧れているらしい
  • 『ゼルダの伝説 ティアーズ オブ ザ キングダム』にて“自作ロボ”技術がどんどん進化。ゾナウギア活用ユーザー発明の歴史 - AUTOMATON

    『ゼルダの伝説 ティアーズ オブ ザ キングダム』では、発売直後からさまざまなロボットやメカが制作されてきた。立ち上がって移動するだけのものから始まり、今や“ハイテク”な機能を備えた脅威のメカが開発されている。稿ではSNS上に投稿されてきたメカたちから、発売後約2週間に起きた技術の進歩を辿っていく。なお稿では多数のゾナウギアの機能や活用例を紹介しているため、注意されたい。 『ゼルダの伝説 ティアーズ オブ ザ キングダム』は、Nintendo Switch向けに発売中のアクションアドベンチャーだ。『ゼルダの伝説 ブレス オブ ザ ワイルド』の続編にあたる。新作においては、ハイラルの地が突如として天変地異に見舞われる。城は宙へと浮かび上がり、空からは謎の遺跡群が降り注ぐ。大地と大空が広がった世界にて、“右手”に力を宿したリンクがハイラルの異変に立ち向かう。なお作は、発売後3日間で売上1

    『ゼルダの伝説 ティアーズ オブ ザ キングダム』にて“自作ロボ”技術がどんどん進化。ゾナウギア活用ユーザー発明の歴史 - AUTOMATON
    lepton9
    lepton9 2023/05/28
  • HTTPキャッシュを使いこなして、Webアプリを快適に(1) | IIJ Engineers Blog

    セキュリティセキュリティ情報統括室に所属 システム開発者。2000年問題で「2038年問題は定年で対応しなくていい!」とフラグを...。 cats_dogs開発者のヒラマツです。 HTTPキャッシュをうまく使う技術、HTTPキャッシュ制御を解説します。 HTTPキャッシュは、WebアプリなどのWebサービスの通信を最適化する技術です。 HTTPのCache-Controlヘッダーの使い方の話でもあります。 HTTPキャッシュ制御と言っても、Cache-Controlヘッダーの設定だけなので、簡単そうに思えます。 しかし、正しく設定しようとすると、案外、複雑で苦労します。 また、理解なしに使うと、情報漏えいの問題を起こす可能性もあり、適当に設定するのは危険です。 ぜひ、この文章を読んで、理解した上で、Catch-Controlを設定してください。 cats_dogsの仕様を書くときに、

    HTTPキャッシュを使いこなして、Webアプリを快適に(1) | IIJ Engineers Blog
  • リーダーっぽい人が忙しくても、忙しいって言ってると感じが悪い - hitode909の日記

    すみません、私から発表があります!忙しくて、マジむかつくんですけど、とかチームの朝会で発表してしまうと、一緒にやってるメンバーからすると、そんなに忙しいのなら声かけるのを遠慮しとこう…となり、会話タイミングが減ったりして、それによってあとで来月そのリカバリでさらに大変なことになり、さらに忙しく、こんなことなら先月のうちにしっかりやっておくべきでしたな、ということがありえるので、あまり、忙しくしていても、忙しすぎる、って言えない、という問題がある。 よく、ここは問題VS私たちでいきましょう、とか言うけど、主にメンバーたちと仕事している場合は、問題←→私たち←→私、で、私は直接問題と繋がっていない、私たちの手助けをしている、ということがあって、問題の先が私たちにいきつくので、あまり具体的なProblemを連発しづらくて、毎日の会話の実りが少ない、とか、ペアプロの進捗が悪い、とか言うと、個別のメ

    リーダーっぽい人が忙しくても、忙しいって言ってると感じが悪い - hitode909の日記
  • 【C#】SOLID原則を学ぼう - Annulus Games

    今回の記事はオブジェクト指向プログラミングにおける設計の基、「SOLID原則」について。 ある程度プログラミングの文法を知っていれば、動作するコードを書くことは可能です。しかし、より良いコードを書きたいのであれば、文法の知識だけではなく、設計に関する知識も必要になってきます。 特にUnityでは、適当にコードを書いていくと目も当てられないようなスパゲッティーコードが容易に出来上がります。「とりあえずシングルトンにすりゃいいや!」みたいなノリで「何とかManager」クラスを作りまくった結果、「あれ?この処理どこに書いたんだっけ?」という状況になったこと、誰しも一度はありますよね…? 今回は、そんなクソk…良くないコードを書かないための設計原則である「SOLID原則」について紹介します。記事内のコードはC#で記述しますが、言語に関わらずSOLID原則は広く応用の効く考え方なので、是非とも覚

  • 皮肉記号 - Wikipedia

    皮肉記号(ひにくきごう、英語: irony punctuation)とは、文章中で皮肉(irony)や嫌味(sarcasm)の意味合いを表現するために使用することが提案された各種の約物である。項目では、約物以外の表現法も含めた、文章中で皮肉の意味合いを表現する各種の方法についても説明する。 皮肉を表す文章には、疑問符(?)や感嘆符(!)のような、皮肉表現であることを示す標準的な方法がなく、いくつかの形式が提案されている。それらの中で、最も古く、最もよく使われるのは、1580年代にイギリスの印刷職人ヘンリー・デンハム(英語版)によって提案されたパーコンテーション・ポイント(percontation point)と、19世紀にベルギーの新聞出版者マルセリン・ジョバール(英語版)とフランスの詩人アルカンタ・デ・ブラーム(ポルトガル語版)によって使用されたアイロニー・マーク(irony mark

  • 久しぶりのPython環境をRyeで整える

    はじめに よくAWS仕事をするので、開発環境をAWS Cloud9(以下Cloud9)で用意することがある。 IAM Roleが使えるのでAWS内の開発は便利なのだが、そのままPythonで開発しようとすると、2023/05/27時点でこう表示されるので、ちゃんと開発環境作らなくちゃね。という気持ちになる。 久々にLangChainやLlamaIndexやらで盛り上がってるし、Python環境でも作るか! と思い立った筆者。じゃあ何を準備すればいいんだっけ、と軽く調べただけでもpip, venv, pyenv, pipenv, poetryなどの選択肢がありすぎて、もうこの時点でげんなりする。Pythonのパッケージマネージャの周辺事情はずっと混沌としていたんだった…… ただ最近は比較的よさげなプロジェクトのRyeがあるので、今回はこれで環境を整えてみる。 Ryeとは 上で書いたような「

    久しぶりのPython環境をRyeで整える
  • 【C#】C# の async/await は実際にどうやって動いているか。 - ねののお庭。

    はじめに 登壇版 Taskの質 C# のイテレータ async/await Compiler Transform ExecutionContext builder.Start() の重要性 IAsyncStateMachine.MoveNext おわりに はじめに C#er は呼吸するように使っている async/await。 そんな async/await について、先日 Stephen Toub 氏 (.NET の中の人。中心人物の一人。) が How Async/Await Really Works in C# という非常に面白い記事を投稿していました。 この記事では Stephen 氏の記事をベースに、C# において async/await は実際どうやって動いてるの?というお話をしていきます。 以前に C#での非同期メソッドの分析。 という翻訳記事を書いたのですが、元になった記

    【C#】C# の async/await は実際にどうやって動いているか。 - ねののお庭。
  • PostgreSQLで多数のパーティションを持つテーブルに対してPrepared Statementを実行した際の性能劣化について調べてみた | DevelopersIO

    ※実行時間の単位は全てmsです パーティション数が1,000になると汎用プランの再検証で1000パーティションへのスキャンが発生するため、bindが遅くなっていることが分かります。気になっていたunnamedなPrepared Statementについては名前付きのPrepared Statementに比べて早いような気もするし、誤差のような気もするし...ここはもう少し計測回数を増やして詳しく見ていきたいところです。 WHERE句をリテラルで記述した非Prepared Statementの場合は1000パーティションかつforce_generic_planの場合でも6.2msで処理できており、汎用プラン再検証のオーバーヘッドが発生していないことが伺えます。 1000パーティションのテーブルに対して1000回クエリを発行してbindのオーバーヘッドを確認してみる 先程の検証結果から 100

    PostgreSQLで多数のパーティションを持つテーブルに対してPrepared Statementを実行した際の性能劣化について調べてみた | DevelopersIO