GitHubで講義ノートを書く
はじめに 大学の講義ノートをいくつかGitHubで公開しています。 講義ノートをMarkdownで書いてGitHubで公開、というのをしばらく続けて、いろいろノウハウが溜まったので共有してみようと思います。 大学の講義ノートをどうするか問題 昔から大学の講義ノートを公開する人は結構多いです。最初期は、LaTeXで書いてPDFで公開することが多かったように思います。これはこれで良いのですが、基本的にはダウンロードして印刷して読む前提であり、ウェブで気軽に読める形ではありませんでした。その後、LaTeX2HTMLを使って、LaTeXファイルをHTMLに変換して公開するケースが増えました。これによりウェブで講義ノートが気軽に閲覧できるようになったのですが、いかにも「LaTeX2HTMLを使って変換しました」という外観になるのと、(少なくともデフォルトでは)レスポンシブではなく、スマホ非対応になる
Cloudflare PagesにNext.jsをデプロイするとSSRが動作するようになったのでどうやって実現されたのかを調べた
これまでの問題 Next.jsのEdge RuntimeはAPI RoutesやMiddlewaresのような単純なリクエスト/レスポンス変換を行う用途で提供されていてReact Componentをレンダリングする(SSR)にはNode.jsランタイム(主にNodeのStreams API)が必要だった[1]。 その上でCloudflare Workersの実行環境でSSRを実現するにはFastly Compute@EdgeのコンポーネントのようにNode.js APIの互換性問題を解決しプラットフォームに適合したグルーコードを生成することが要求された(fastly/next-compute-jsの内部アーキテクチャを調べるを参照)。 なのでCloudflare WorkersにAPI単体をデプロイ+Cloudflare Pagesにエクスポート済みの静的サイトをデプロイしてSPAで動か
ZennでRustの記事を書いたら本を書くことになった話
脱稿(執筆の完了・提出)は当初6末予定だったのですが、書いてるうちにどうしても間に合わず2週間ほど予定をずらさせていただきました。実は企画が通る前から少し書いてたのですが、それでもどうしても子育て・仕事・執筆の3つを成り立たせ続けるのは至難の業で、結果遅れてしまいました。 企画後、実際の執筆の流れもみてみましょう。 1. 調査・構成の検討 企画時点である程度方針や構成概要は検討済みでしたが、一番はWebアプリ開発を通じてRustを学ぶ本なので「何をどこまでどうやって作るか」を検討しました。 Rustの文法についてはどこまで解説するのか、マルチスレッドやメモリ周りに触れすぎると読者は離れてしまわないか RustのWebフレームワークはいくつもあり、どれを使うのか SQL周りのライブラリは何を使うのか フロントエンドはどうするのか。Rustのフレームワークではテンプレートエンジンを使うパターン
ニアリアルタイムで同期される検索基盤 ~パイプライン構築編~ - コネヒト開発者ブログ
皆さん，こんにちは！MLエンジニアの柏木（@asteriam）です． 今回は前回のエントリーに続いてその後編，パイプライン構築の話になります． tech.connehito.com はじめに 再掲になりますが，我々は以下の構成で今回の検索基盤を構築しています． 検索エンジン：Amazon OpenSearch Service データベース：Amazon Aurora データ同期（ETL）：AWS Glue ワークフロー・パイプライン：AWS Step Functions・Lambda・EventBridge 後編は，検索エンジンに定期的に安定してデータを同期するために構築しているワークフロー・パイプラインに関する内容になります（下図の全量データ同期パイプラインの部分）． 検索基盤全体のアーキテクチャー概略図 もう少し具体的には，OpenSearchのindexの管理方法について説明した後に
🌕 moonでのmonorepo管理とpackemonでのCJS/ESMのdual package
🌕 moonでのmonorepo管理とpackemonでのCJS/ESMのdual package 🌕 moon 一貫性を持ったmonorepo管理ツール for JavaScript ハッシュを使ったファイルキャッシュ プロジェクトのパッケージ間の依存関係の分析とタスク実行 Node.js/npmパッケージマネージャーのバージョン管理と一貫性 TypeScriptのProject Referendcesの一貫性 比較 Nx: The Framework + Pluginで拡張する Lerna: Nx傘下、ライブラリ公開向け Turborepo: タスク実行の最適化をする moon: monorepoでの一貫性を提供する Packemon: moonと同じ作者。ESM/CJSのライブラリ公開向け 比較(言語) Nx: TypeScript + C++[^1] Turborepo: Go
TypeScript 4.7 と Native Node.js ESM
TypeScript 4.7 がリリースされたので、Node.js ESM 対応の現状をまとめておく。 @teppeis さんの TypeScript 4.5 以降で ESM 対応はどうなるのか？ を先に読んでおくと、以降の話も読み進めやすいかも。 このエントリの中でも、teppeis さんの定義した用語をそのまま用いさせてもらう。 * CommonJS (CJS): 従来式の Node.js CommonJS で書かれたファイルまたはパッケージ * ES Modules (ESM): ES2015 で定義されたモジュール仕様。Node.js では v12 以降でネイティブにサポートされている。 * Native ESM: ESM 形式で記述されたファイルを、Node.js またはブラウザで直接 ESM として実行する方式またはそのファイル。擬似 ESM と区別するために Native と
さようならElasticsearch、よろしくElastic Cloud - Nota TechConf
by yuiseki yuiseki.icon 2022/5/19 20:25 - 20:40 （明らかに15分で収まる内容の資料ではないですが、資料はモリモリで発表はスカスカでもScrapboxで盛り上がれるか、という仮説の検証を兼ねています） yuisekiですyuiseki.icon Gyazoのプロジェクトマネージャー兼ソフトウェアエンジニアです 本日お集まりいただいたみなさん、ありがとうございます 本日お集まりいただいたみなさん ノバウサギ…？nyanco.icon ユニコーンガンダム…？issac.icon タイマーちゃん！takker.icon 12年間運用を続けているB2C SaaSの検索インフラの実態（14分まで、1分間） Gyazoは2021年、「画像の瞬間発見」をテーマに、検索に力を入れていた Nota Tech Conf 2021 Springでのyuiseki.i
Cloud Run Jobs がリリースされたので、何ができるか試してみた！
2022/05/11にCloud Run Jobsがプレビューでリリースされました！ Unlike services, which listen for requests, a job does not serve requests but only runs its tasks and exits when finished. 従来のCloud Runのserviceでジョブ的なことを実装する場合、ポートをリッスンしてリクエストを受け取り、ジョブを実行して、成功/失敗のレスポンスを返すという流れでした。 今回リリースされたCloud Run Jobsでは、ポートをリッスンする必要がなくなったということで、ついに待ち望んでいた機能がきたのか！？とさっそく動作確認し、僕が期待してたことは全部できそうでした🎉 これまでCloudBuildでワークフロー組んでたんですが、対応リージョン増えてC
検索エンジンPyTerrierを使った日本語検索パイプラインの実装 - エムスリーテックブログ
エムスリーエンジニアリンググループ AI・機械学習チームでソフトウェアエンジニアをしている中村(po3rin) です。検索とGoが好きです。 今回は社内でPyTerrierを採用して文書検索BatchをPythonで実装したので、PyTerrierの紹介とPyTerrierで日本語検索を実装する方法を紹介します(日本語でPyTerrierを扱う記事は多分初?)。 PyTerrierとは 弊社でのPyTerrier利用 PyTerrierで日本語検索 Phrase Queryの注意点 まとめ We're hiring !!! PyTerrierとは Terrierのロゴ PyTerrierは、Pythonでの情報検索実験のためのプラットフォームです。 JavaベースのTerrierを内部的に使用して、インデックス作成と検索操作を行うことができます。基本的なQuery RewritingやBM
Amplify GraphQL Transformer v2 まとめ
「AWS Amplify Advent Calendar 2021」 19日目の記事となります 記事の概要 2021/11/23に、Amplify GraphQL Transformer v2(以下v2と表記)が発表されました[1]。以前のGraphQL Transformer v1(以下v1と表記)から大幅なアップデートがいくつも入っており、Breaking Changeも少なからずあります。この記事では GraphQL Transformer v2の主な変更点 GraphQL Transformer v1からのMigration時の注意事項 の2点についてまとめてみました！ 想定読者 Amplify CLIでGraphQL APIを利用している人 これから利用を検討しているが、既存のブログ記事などがv1で記述されており差分が知りたい人 話さないこと(及び参考資料) Amplify 自体
DynamoDB の設計について考えてみる。 - Qiita
Amazon DynamoDB の特性 フルマネージド型の NoSQL データベースサービス 3つの Availability Zone に保存されるので信頼性が高い 性能要件に応じて、テーブルごとにスループットキャパシティを定義するキャパシティの Auto Scaling、オンデマンドキャパシティといった設定も可能 ストレージの容量制限がない DynamoDB のテーブル DynamoDB におけるテーブルはRDBMSにおけるテーブルと概念が異なります。 テーブルを作成する際に、Primary Key を指定する必要があります。 Primary Key はテーブルの各項目を一意に識別するために使います。Primary Key は、Partition Key および Sort Key で構成されます。(Sort KeyがなくPartition Keyのみの場合もあります) Item は R
Make your monorepo feel small with Git’s sparse index
EngineeringOpen SourceMake your monorepo feel small with Git’s sparse indexThe new sparse index feature makes it feel like you are working in a small repository when working in a focused portion of a monorepo. One way that Git scales to the largest monorepos is the sparse-checkout feature, which allows you to focus on a subset of the files. This is supposed to make it feel like you are actually in
Grafana Lokiで構築する大規模ログモニタリング基盤 / Grafana Loki Deep Dive
CloudNative Days Tokyo 2021での登壇資料です https://event.cloudnativedays.jp/cndt2021/talks/1252
SPA Componentの推しディレクトリ構成について語る
こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「Componentのディレクトリ構成」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが 株式会社ナレッジワーク というスタートアップで開発・運用しているプロジェクトにおいてうまくいっていると感じているComponentのディレクトリ構成についてご紹介していきます。 ディレクトリ構成 Componentは src/components の中にまとめていて、その下に以下の4種類の分類ディレクトリを切っています。 src/components/page src/components/model src/components/ui src/components/functional 分類ディレクトリを考えるにあたって重視したポイントは以下。 新しくco
pixivのブックマークに関する負荷対策をしました - pixiv inside
10/22(金) 追記 この記事で解説している内容について解説する勉強会を開催することとなりました。以下のconnpassよりお申し込みください。 pixiv.connpass.com 10/22(金) 追記 pixivのブックマークについて ブックマークDBの問題について 具体的な対策内容 論理削除廃止・index追加・ブックマークタグのテーブル分割 適応ハッシュインデックスの無効化 アプリケーションコードのリファクタリング・全発行クエリの列挙と見直し 大きな更新処理の非同期化 結果 あわせてよみたい pixivではサービスの成長に伴い、気に入った作品に対して付けることができるブックマークの総数が急速に増加しており、ユーザーの皆様に滞りなくサービスを提供し続けるためブックマークに関するデータベース(以後DB)の負荷対策が必要になりました。 2021年2月より対策を行うプロジェクトを発足し
The Future Shape of Ruby Objects
These are the notes for a talk I gave at RubyKaigi 2021, which is why they’re written as if we were talking and going through some slides and code together. Hello I’m Chris Seaton. I’m a Senior Staff Engineer at Shopify where I’m working on Ruby performance. I’m the founder of TruffleRuby, which is a very highly optimizing implementation of Ruby. I also maintain The Ruby Bibliography at rubybib.or
二分探索アルゴリズムを一般化 〜 めぐる式二分探索法のススメ 〜 - Qiita
0. はじめに 二分探索法は単純ながらも効果が大きく印象に残りやすいもので、アルゴリズム学習のスタート地点に彩られた花という感じです。二分探索というと「ソート済み配列の中から目的のものを高速に探索する」アルゴリズムを思い浮かべる方が多いと思います。巨大なサイズのデータを扱う場面の多い現代ではそれだけでも十分実用的ですが、二分探索法はもっとずっと広い適用範囲を持っています。 本記事では、二分探索法のエッセンスを抽象化して、適用範囲の広い「二分探索法の一般形」を紹介します。同時に無数にある二分探索の実装方法の中でも「めぐる式二分探索」がバグりにくいと感じているので、紹介したいと思います。 注意 1: 二分探索の計算時間について 二分探索の計算時間について簡単に触れておきたいと思います。例えば「$n$ 個の要素からなるソート済み配列から目的の値を探索する」というよく知られた設定であれば、 単純な
InnoDBのMVCCのガベージコレクションについて - shallowな暮らし
こんにちは、shallow1729:detailです。今回は先日MyNA会というイベントで発表したMySQLの標準のストレージエンジンであるInnoDBのMVCCのガベージコレクションについて書こうと思います。発表自体もアーカイブされているので以下から見る事ができます。 「日本MySQLユーザ会会(MyNA会) 2021年07月 -下位レイヤ勉強会-」 公開版 - YouTube まず前半ではMVCCに関連するデータ構造を見ながらガベージコレクションの重要性やlong-running transactionの問題点について解説します。後半では実際のガベージコレクション(purge)の処理をソースコードレベルで追いながら、ユーザーに提供されているパラメーターを解説をします。 これまでに比べると踏み込んだ話題なのであまり基礎的な事は解説しません。知らない単語が多いかもしれないですが、適宜調べな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PPL 2022 招待講演： 静的型つき函数型組版処理システムSATySFiの紹介
MySQLとインデックスとPHPer
