学習者が、「どの資料が、どんなレベルで、どのトピックについて言及しているか」をざっくり把握できること。
ソフトウェアテスト読書マップ - Google ドライブ
学習者が、「どの資料が、どんなレベルで、どのトピックについて言及しているか」をざっくり把握できること。
再考: アプリ開発と状態遷移の管理 - ninjinkun's diary
自分が開発しているLaunchableのWebアプリがローンチされて1年半ほどになる。このWebアプリにはReduxのような状態管理ライブラリを入れないまま開発してきたのだが、今のところ困らずに開発できている。そういえば昔自分は状態管理について何か考えていたような…とブログを掘り起こしてみた。 ninjinkun.hatenablog.com このエントリは2016年にネイティブアプリを対象にして書かれているが、この後自分は2018年ごろにWebフロントエンドに軸足を移し、ネイティブアプリ開発から離れた。なのでこのエントリはWebフロントエンドエンジニアが2022年に再考した話になる。 結論としては、当時自分が管理したかった状態のほとんどは現在ApolloClientのキャッシュによって解決されている。 繰り返しになるが、自分が開発しているLaunchableのWebフロントエンドには状態
Introducing LiteFS
Introducing LiteFS Author Name Ben Johnson @benbjohnson @benbjohnson Image by Annie Ruygt Fly.io runs apps close to users by taking containers and upgrading them to full-fledged virtual machines running on our own hardware around the world. We’re also building an open-source distributed file system for SQLite called LiteFS which is pretty cool too. Give us a whirl and get up and running quickly. F
いまどきな JavaScript に入門しよう！『流麗な JavaScript』を読んで（上） - 虎の穴開発室ブログ
こんにちは。虎の穴ラボの古賀です。 9 月の連休で社内の技術書購入を支援する制度を利用して購入した『流麗（ELOQUENT）な JavaScript 第 3 版 現代のプログラミング入門』を読みました。 流麗なJavaScriptの書影 良い本でしたので、本書の前半部分の概要とその中で良かったところや気になったところをご紹介します。 どんな本か 基本情報 オススメする読者層 著者、訳者について 構成について Chapter1〜3：プログラムの基礎的なところから、制御フロー、関数など Chapter1 Chapter2 Chapter3 Chapter4 Chapter5 Chapter6 Chapter7 Chapter8 Chapter10 Chapter11〜22：未読 良かったところ サンプルコードの実行環境や練習問題がある 初心者がつまづきがちなところについて説明がある 気になった
「［試して理解］Linuxのしくみ ～実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】」が発売されます - 覚書
拙著、「［試して理解］Linuxのしくみ ～実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】」が10/17日に発売されることになりました。本記事はその宣伝のためのブログエントリです。 ［試して理解］Linuxのしくみ ―実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】 作者:武内 覚技術評論社Amazon まずは本書がどのようなものかについて説明し、その後に、すでに第一版を読まれている方向けに第一版と本書の差分について説明します。 どんな本なのか 筆者は過去にLinuxカーネル開発をしていたのですが、そのころから次のような思いをずっと持っていました。 OS、とくにOSカーネルについての広く浅い知識はOSカーネル開発者だけではなく多くの技術者にとって役立つはず 当時OSカーネルについての知識を得ようとすると、OSを作ったりサポートしたりする人用の難しくて分
開発組織の生産性を可視化するState of DevOpsとFour Keysとは(増補改訂版) / Introduction to State of DevOps and Four Keys for Visualizing Productivity in Development Organizations expanded and revised edition
以下のイベントの発表資料です。 https://phpcon.php.gr.jp/2022/ 想定課題 開発がスケールしたり、開発年数が経過すると、様々な要因で開発生産性の低下が起こります。 そこで現場のエンジニアは改善をしたくなるかと思いますが、大抵の場合、ステークホルダーと工数確保の合意が必要になります。 その際にこのようなことを言われがちではないでしょうか？ 今動いているものを直す必要ある？ 効果測定どうやんの？ 費用対効果はどれくらい？ パフォーマンスチューニングの世界には「推測するな計測せよ」という言葉がありますが、開発組織における生産性についても測定してモニタリングする必要があると思います。 本セッションの目標 以上を踏まえ、本トークでは開発組織とステークホルダーの間の共通言語を獲得することを目標に以下の内容についてお話します。 State of DevOpsとは Four K
Cloudflare で mTLS を利用する
Cloudflare で mTLS を利用するのがあまりにも簡単だったので書いておきます。 mTLS について 一般的に TLS を利用する場合は「クライアントがサーバーから送られてきた証明書を検証する」という仕組みを利用し、 信頼できる機関が発行した証明書を利用しているかどうかや証明書のドメインが一致しているかどうかなどを確認します。 mTLS (mutual TLS) というのは TLS 利用時に「クライアントから送られた証明書をサーバが検証する」という仕組みです。 つまりサーバーがクライアントがわから送られてくる証明書を確認するというフェーズが挟み込まれます。 この証明書自体は何を使ってもよく、オレオレ証明書でもかまいません。 クライアント側に証明書を設定するという仕組みです。VPN とかを利用したりする方は経験があるかもしれません。 mTLS はめんどくさい クライアント側に証明書
Wasmtime Reaches 1.0: Fast, Safe and Production Ready!
As of today, the Wasmtime WebAssembly runtime is now at 1.0! This means that all of us in the Bytecode Alliance agree that it is fully ready to use in production. In truth, we could have called Wasmtime production-ready more than a year ago. But we didn’t want to release just any WebAssembly engine. We wanted to have a super fast and super safe WebAssembly engine. We wanted to feel really confiden
ロックスターになれなくてもいい。ソフトウェア開発に長く携わる技術「メタエンジニアリング」とは - Findy Engineer Lab
Developers Summit 2020に登壇 こんにちは！ 塩谷啓（@kwappa）と申します。ヘイ株式会社（2022年10月よりSTORES 株式会社）のエンジニアリング室という部署で、マネージャーをしています。 エンジニアとしてのキャリアを家庭用ゲームソフトの開発からスタートし、SESや受託開発を経て、いくつかのWebサービスの会社で働いてきました。2011年ごろから、エンジニアリングと並行して採用の仕事も担当するようになり、現在ではマネジメントとメタエンジニアリングを主な業務領域としています。 並の腕前のエンジニアが発見した新しい適性 ごく平凡なエンジニアであることの焦燥感 突然の採用担当 メタエンジニアリングのめざめ 技術広報・採用・組織開発でそれぞれ何をするのか？ 技術広報 ─ アウトプットを実現して社外から信頼を得る 採用 ─ 公開情報のメンテナンスと選考プロセスの整備
Our journey to type checking 4 million lines of Python
Dropbox is a big user of Python. It’s our most widely used language both for backend services and the desktop client app (we are also heavy users of Go, TypeScript, and Rust). At our scale—millions of lines of Python—the dynamic typing in Python made code needlessly hard to understand and started to seriously impact productivity. To mitigate this, we have been gradually migrating our code to stati
コードレビューはつまらないから丁寧なプルリクエストでチームの生産性向上を目指す
コードレビューにずっと苦手意識を持っていた。レビューは時間がかかるし、あまり気が乗らない。 がんばってやっても、うまくできたのかどうか自信が持てない。 もちろん、世にあるコードレビューに関する書籍や記事などはいくつも読んだ。 そこには、コードレビューをするときの観点や、コードレビューで望ましい言葉づかいなど、ためになることがたくさん書かれていた。 それでも、やはりコードレビューが苦手なことに変わりはなかった。 だけど最近ようやく、こうすればレビューをうまくこなせるのではないかという出口が、なんとなく見えはじめてきた。 この記事では、ぼくなりにたどり着いた、プルリクエストのレビューを上手に行うための心構え、つまりいかにしてレビューのつらみを減らすかについて書く。 目次 なぜコードレビューはつまらないのか われわれは、なんのためにコードレビューをするのか レビューのコスト レビューの観点 文化
テキストエディタで使われがちなデータ構造 Piece Table の概要と実装 - A Memorandum
テキストエディタのデータ構造 Gap method Piece Table method Piece Table の構造 Piece Table の実装 Piece Table のメソッド まとめ テキストエディタのデータ構造 テキストエディタで採用されているデータ構造にはいろいろあります。 こちらの論文 Data Structures for Text Sequences では各種データ構造について比較検討されています。 多くは、Gap method や Piece table method をベースにしたものが多いのではないでしょうか(図で言う最下部の中心の丸印に当たります)。最近では Rope なども有名ですね。 Gap method Gap method では、現在のカーソル位置で、テキストバッファを2つに分割し Gap を間に挟み、カーソル位置に対する編集(テキスト追加/削除)を
dockerコンテナ内から /dev/stdout へ書き込もうとすると "Permission denied" になる - モヒカンメモ
PHP Laravel 5.5系のアプリをdockerコンテナにして、所定のログファイルpathから /dev/stdout へのsymlinkを貼って動かしたところ Permission denied エラーが出た。原因を調べたところそれなりにめんどくさかったので調べたことをまとめておく。 症状 dockerコンテナ内のアプリから /dev/stdout へログを吐こうとしたときに Permission denied エラーになる コンテナに入ってディレクトリとパーミンションを確認すると、パット見問題無さそう 原因 /dev/stdout の最終的な向き先が自分のpts (仮想端末) ではないことがあり (バグ？)、自分のものでないptsには当然書き込めないのでエラーとなる。 ▼ ptsってなんやねん的な人向け takuya-1st.hatenablog.jp ▼ 神記事 qiita.c
Search Engineering Newsletter vol.10
節目となる 10 回目のニュースレター配信です。 今回のイチオシ記事は ABEJA さんの「GPT モデルへの道のり」とメルカリさんの「お手軽な検索 API 構築」記事です。 Search#How we’re improving search results when you use quotes - GoogleGoogle、引用符による完全一致検索結果をフレーズを中心に表示するよう改善 - PC Watchダブルクォートを使った完全一致検索を行う際に、web ページのヘッダーや URL などは検索対象外になることで、Google の Web 検索体験を改善した。 厳格なテスト – Google 検索の仕組み Google 検索がどのようにテスト・評価を行っているか。 2021 年に、約 4000 件の変更、約 11000 件の AB テストを行っているらしく驚き。 簡単に逆算しても月間
RubyKaigi2022で発表した - スペクトラム
rubykaigi.org speakerdeck.com RubyKaigi2022で発表した。オンライン参加で、発表は録画だったので、発表したかどうかは奇妙な感じだけど、ともかくできるだけのことはやりきった。 僕にとって、RubyKaigiは2013が最初の参加だった。以来「いつかは発表を……。」と思ってはいたけど、ネタがなかったり、CFPを出したけどRejectだったりだった。 今回、"Rubyに関する国内最大級の国際会議"に初登壇できたのは万感の思いだ。本当に嬉しい。 一方、採用率(採用数 / CFP数)は実は2倍もない。つまり誰にでもチャンスはあって、やれる覚悟があるかどうかが重要なのだ。みんなも発表やってみよ。 KPI "GitHubリポジトリのスター100個"を目標にしてたけど、結果としては30くらいだった。 https://github.com/ksss/orthoses
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tech/ruby-rails/雑記/2021/09/18/Docker内Rubyプロセスdebug gemへnative Chrome Dev Toolsからアクセス
デイリースクラムいらなくなくなくなーい！？
アイリス、洗濯機みたいに回る電気鍋。から揚げや炒飯もほったらかしで作れる - 家電 Watch
ソフトウェアエンジニアとしての姿勢と心構え / Software Engineer's Survival Guide
Emacs の設定
