TSKaigi 2024 ref: https://tskaigi.org/talks/tockn
はじめに こんにちは、ast-grepの作者ヘリントンです。 Reactバージョン19のリリースに伴い、新機能と改善が追加されました。 しかし、この新バージョンへのアップグレードには、ソースコードの一部を修正する必要があります。特に大規模なコードベースでは、このプロセスはかなり手間がかかり、繰り返し行う必要があります。 本記事では、ast-grepというツールの使用方法を説明します。このツールは、コードベース内でパターンを見つけて置き換えることを目的として設計されており、React 19への移行を容易にします。 以下の3つの主要なcodemodsに焦点を当てます。 <Context>をプロバイダとして使用する 暗黙のrefコールバックリターンを削除する refをpropsとして使用し、forwardRefを削除する 前提条件: ast-grepのセットアップ まず、ast-grepをセット
去る5月3日~5日に開催された第34回世界コンピュータ将棋選手権(以下WCSC34と略す)について、私の視点で書きたいことをいくつか書いておきたい。 今回、優勝したのは「お前、CSA会員にならねーか?」(以下、たぬきと記す)である。この作者は、たぬきシリーズの作者の野田さん(nodchip)だ。 関連記事 : その名は「お前、CSA会員にならねーか?」2024年・世界コンピュータ将棋選手権、チャンピオン決定!(Yahooニュース) : https://news.yahoo.co.jp/expert/articles/3490be9ce374b0afe114ca3d6e5a422d0db85923 今回のたぬきは、Deep Learning型の将棋AIではなく、従来型(NNUE系と言われている)の将棋AIである。 nnue-pytorchについて 今年に入ってから、NNUE系はいくつかの大き
旧知の仲である数学者 齋藤 耕太 氏(筑波大学、学振PD)が、昨日数学の未解決問題を解決したとするプレプリントをプリプリントサーバーarXivに投稿されました: arxiv.org 論文自体は「現状分かるところまで研究しつくす」という素晴らしい態度で執筆されているので主定理の記述は十行ありますが、その特別な場合をとり出した ミルズの定数は無理数である という定理(これは論文のタイトルにもなっています)が、ある程度長い期間未解決であったと思われる数学上の問題の解決を意味しています。 無理数性の証明はかっこいい 実数という数学的対象は有理数と無理数に分けられます。有理数は などのように という表示を持つ実数であり(ここでは自然数は正の整数を意味するものとします)、有理数ではない実数のことを無理数といいます。 高校数学でも証明込みで学ぶことと思いますが、無理数の典型例としては があげられます。こ
CodeBuild プロジェクトを使用して Webhook を設定し、GitHub ACtions ワークフローの yaml を更新して CodeBuild マシン上でホストされているセルフホストランナーを使用できる GitHub への認証は PAT か OAuth App を使う まとめというかわかったこと ※間違ってることや、こうすればいいよなどがあったらコメントください。 良かった点 セットアップは楽 ephemeral である 起動時間は EC2、Lambda 共に 1 分程度だった 個人的には十分速い マネージドイメージに加えて Docker カスタムイメージを指定可能 jobs.<job_id>.runs-on に -<image>-<image-version>-<instance-size> を追記すると、設定不要で様々なアーキテクチャのイメージを使える jobs.<job
making-the-most-of-local-llms.ipynb Sorry, something went wrong. Reload? Sorry, we cannot display this file. Sorry, this file is invalid so it cannot be displayed.
以前に アプリケーションを停止させずにRDBのスキーマ変更する話 を書きました。 developer.feedforce.jp 今日は、その実践編というか、実例として EC Booster というサービスで請求関連テーブルのスキーマを変更した話をしようと思います。 はじまりのテーブル 元々、 EC Booster の請求を管理するテーブルは、このような形でした。 create_table "monthly_charges", id: :uuid, default: -> { "gen_random_uuid()" }, force: :cascade do |t| t.uuid "shop_id", null: false t.integer "year", null: false t.integer "month", null: false t.datetime "created_at"
ものすごい円安が進んでいるのでハワイの物価をチェックしてきました。 私が行ったのは今年の 3月末から4月始めの 1週間。 その頃も「30年ぶりの円安!」と騒がれていましたが、それでも報道レートは 154円ほど。いまよりはマシなレートでした。 ではまず食べ物の値段から。 ビーチバーのカクテル。Tip不要のテイクアウト店で 2人分 3412円、ってことは 1杯 1700円以上! ちゃっちい使い捨てコップに入ってこの値段。なにげに高いですよね。 ランチに食べたマグロとアボガドのポキ丼。2人分なのでこれをふたつ頼んで 9267円、Tip込み。 しかもたいしておいしくない。初日のランチだったので「えっ、これが 1万円?」と、かなりビビった。 この食事のあと、友人とは「いちいち円換算するのはやめよう!」「アメリカドルで考えよう!」と申し合わせました。 翌朝の朝食。パンケーキとエッグベネディクト+飲み物
ソフトウェアエンジニアリングにおいて大切なのは、人間のことをのぞけば名付けだと思っている。言葉がなければ世界は混沌としたままだけど、そこに名前をもたらすことがものごとを切り分け、ひとつの秩序をもった視点をつくる。この秩序は唯一絶対のものではなくて、なんらかの意志によって導かれたものである。ソフトウェアはあくまでも現実の抽象だから、問題をどういう視点で見るか、という軸があるわけだ。そういう意味では人間のことではある。 適切につけられた名前は、そのことによって他のものとの自然な境界を与えられていて、その他の名付けと一貫性を持っている。そういう名前は既存の名付けの体系になじむので、同じ言葉を使う人々のあいだに受けいられれて、共通のコンテキストに追加される。そして次第に暗黙のものになっていく。 たとえばユーザのフォローがあるSNSのようなウェブサービスをつくるときに、QueueとかBrokerみた
Mackerel チームで SRE を担当している id:taxintt と申します。 はてなの SRE が毎月交代でブログ記事を書く Hatena Developer Blog の SRE 連載、3月分は私が担当します。2月の記事は id:masayosu さんの はてなにおけるEKSの運用と自動化 (2024年版) でした。 私が所属する Mackerel 開発チームでは、SaaS 型サーバー監視サービスである Mackerel を開発しています。 Mackerel は、テレメトリデータの計装・収集の標準化を目的としたプロジェクトである OpenTelemetry 対応のための開発を進めています。この記事では、OpenTelemetry のメトリックを扱うサブシステムの開発における SLI/SLO の決定・運用についてお話しします。 mackerel.io OpenTelemetry
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
こんにちは、富士榮です。 ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。 考えていると結局のところ、サービス提供側が意図していることとは全然違うことが起きている気がするので、この辺はしっかり考えて実装したいところですね。(実装ミスは問題外として) カテゴリ滅びてほしいもの実装側がやりたいこと利用者が感じること実際に起きていること代替手法認証CAPTCHAbot避けぐにゃぐにゃ文字が読めない バイクと自転車の違いとは?ユーザの離脱、カゴ落ちパスキーの利用 新しいタイプのCAPTCHA(通常は画面に出ない) リスクベース認証との組み合わせによる抑制認証パスワード誰でも使える認証手段の用意忘れる。複雑なパスワードをそれぞれのサービス毎に管理するのは無理パスワードの使い回し。パスワード
株式会社ドワンゴは2024年5月11日に開催される日本最大級のTypeScriptをテーマとした技術カンファレンス TSKaigi 2024 にプラチナスポンサーとして協賛いたします。 TSKaigi 2024 当日は弊社教育事業エンジニアが複数名参加します。スポンサーブースをいただいていますので、現地で参加される方は是非お気軽にお越しください。 スポンサーブースではN予備校内にあるTypeScriptの教材を触れる他、限定ノベルティもご用意しております! ドワンゴの教育事業とは? 私たちは、未来の「当たり前」の教育をつくるため、生徒・学生や教職員の「学ぶ」「教える」体験の最大化を日々目指しています。 日本発の本格的なオンライン大学「ZEN大学(仮称)(設置認可申請中)」や、2万名を超え日本最大の生徒数であるネットの高校「N高等学校・S高等学校」と連携し、ネットの時代に合わせた教育関連のサ
(CNN) 地球から最も遠い宇宙空間を飛行する米航空宇宙局(NASA)の探査機「ボイジャー1号」から、5カ月ぶりに解読可能なデータが地球に届いた。NASAのチームが試行錯誤を繰り返し、通信問題を引き起こした原因が1個のチップにあることを突き止めて、解決策を編み出した結果だった。 ボイジャー1号は現在、地球から240億キロメートル離れた宇宙空間を飛行中。打ち上げから46年を経て、さまざまな不具合や老朽化の兆候が見えている。 今回の問題は2023年11月に発生。飛行データシステムの遠隔測定モジュールから送られてくるデータが解読不可能になった。 ボイジャー1号の飛行データシステムは、現在の健康状態を表す工学データを科学計器の情報と組み合わせて収集している。地球上の管制室はそのデータを、0と1で構成される2進コードで受信する。 ところが11月以来、この飛行データシステムがループ状態に陥り、無線信号
言いたいこと最近はCAT6Aでフラットケーブルが登場してるが、あれ全部ゴミだ 30mぐらいまであるけどマジゴミ。 買う価値なし。 ゴミは置いといても、LANケーブルには「準拠」と「対応」があるらしい。区別して使うべし 長い文章(読み飛ばしてよい)CAT6Aで施工指示したのに5Eになってたと言う記事を読んで思い出したので吐き出しておく。 大手OAサプライヤで売っている完成品LANケーブル。これもCAT6Aが標準になってきて久しい。5Eのものはほぼ見られなくなった。 その中でフラットケーブルと言われるものが売られている。 通常LANケーブルというのは、細い線が何本か寄り合わされて、さらに保護用のチューブに入れられた構造だ。なので断面が丸いケーブルが普通である。 それを、丸くまとめるのではなく一直線に横に並べ固めたものがある。これをフラットケーブルという。また見かけから「きしめんケーブル」などと
こんにちは。Findy Freelanceの開発チームでエンジニアをしている2boです。 この記事では私が開発生産性を上げるために開発をする前に考えていることについて書きます。 ここで「開発をする前」というのは次のようなタイミングを指します。 PdMなどから新規施策の仕様について相談を受けたとき 起票された開発Issueを最初に確認するとき 自分がIssueを作成するとき なぜこのタイミングで考えるかというと、開発を進める上での方向性を間違える可能性を減らし後から軌道修正をしやすくするためです。 なおこの記事においては、開発生産性を「開発成果物の提供価値を投入リソースで割ったもの」とします。 いくら頑張って開発をしても、そもそもやるべきことの方向性を大きく間違えると提供価値が0に近づくため開発生産性が低下します。 特に開発が高速なチームで方向性を誤ると高速に間違った方向へ進んでしまうことに
はじめに 弊社マイベストでは、エンドツーエンドの機能開発チームとは別で、組織の価値提供能力を高めることを目的としたイネーブリングチームがあります。(と言ってもまだ他チームとの兼任メンバーがほとんどですが) イネーブリングチームは、バックエンドやフロントエンドなど、領域ごとに技術課題を解決すべく活動していて、自分はフロントエンド領域を担当しています。 これまで様々な活動を行ってきたので、その考え方を整理しつつ、フロントエンドイネーブリングの実践例をご紹介したいと思います。 参考:マイベストのチーム構成イメージ(記載は一部のみ・名称は仮です) 「イネーブリングチーム」とは イネーブリングは『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』、通称チートポから持ってきた名称なので、まずはチートポをベースにその役割を説明します。 https://amazon.co.jp/dp/
BARフロントえんどう #2 「CSS Library / Framework」で発表した資料です。
とあるプロジェクトでナノ秒からミリ秒への変換で四捨五入してきた人がいて、時刻を扱うときは保存精度未満は切り捨てるべきというのが常識になっていないなーと思ったので。 2023-10-01 を、何年か表示する時に、2024年に丸める人はいないだろう。 13:45 が何時か表示する時も、13時と表示するだろう。(口頭で何時?と聞かれたら14時と答えるかもしれないけれど) つまり、ある精度で表した時刻は、実際には次のような半開区間を示しているのである。 2023-01-01 00:00:00 <= 2023年 < 2024-01-01 00:00:00 13:45:00.000 <= 13:45 < 13:46:00.000 そして、そう決めたからには一貫して同じように、指定精度未満は切り捨てというルールを維持しなければならない。秒以下は四捨五入で、とかやってはいけないのだ。 一貫しないと何が問題
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く