はじめに Linux 5.1に新しい非同期IOの仕組みとしてio_uringがマージされてから既に1年以上経ってしまいましたが、これまでのLinuxにおける非同期IOの使い方や実装を見ていきながら、io_uringが登場した背景やLinux AIO(libaio)の問題点をどのように解決しているのかについてまとめました。アプリケーションの書き方については大まかにしか説明していないので、それについてはmanページや別の記事を参照してください。 またIOという範囲が広いのですが、ここではブロックデバイス上のファイルシステムにおける通常ファイルに対するread/writeについて考えています(ネットワークは考えていないのでepollの話はないです)。 前提知識 簡単に前提となる話をおさらいします。 同期IOと非同期IO IOを行うシステムコールとしてすぐに思いつくのはread(2)/write(

GitHub上でプログラムを公開するとき、 どのライセンスを使えばいいのかわからない どうやってライセンスを設定すればいいのかわからない ライセンスというもの自体が難しそうでよくわからない などの理由で、ライセンスを設定しないままになっていることはないでしょうか？ この記事では、個人の開発者によるプログラムにライセンスが設定されていなかった場合にどのようなことが起きるのか、という観点からスタートして、ライセンスについての理解を深めていこうと思います。1 注意1: この記事の執筆者は法律に関する専門家ではありません。法律やライセンスに関する言及や解釈は不正確である可能性があります。実際の問題に対しては専門家による助言を受けてください。 注意2: この記事の内容は執筆者個人の見解であり、所属企業・部門の見解を代表するものではありません。 ライセンスがないということ プログラムのソースコードは、

この記事はGo Advent Calendar 2020 16日目の代打記事です。奇しくも16日目にGo1.16の話をすることになりました。 【追記】タイトル改題しました 状況が落ち着いてだいぶ経ったのと、未だに多くの方にこの記事を見ていただけていることから、Go1.16での変更というより、今を生きる私達がどうすればいいか、という点にフォーカスしたタイトルに改題しました。本文に変更はありません。一応注記すると、go get が廃止になったわけではなく、普段の開発フローで使うことはまずなくなった、という意味です。（一通り読んでいただければお分かりいただけるかと。） 【追記】Go1.18について ついに待望のGo1.18がリリースされましたね！ https://go.dev/doc/go1.18#go-command そして予告通り go get によるインストール機能は削除されました。どうし

git では通常、リポジトリと作業ディレクトリとが一組になっています。git clone をすると、作業ディレクトリの中に .git ディレクトリ（＝リポジトリ）が作成されます。 そして、この作業ディレクトリの中でブランチを切り替えて作業するのが一般的かと思います。 さて、作業ディレクトリの中で何かの作業中に、別の割り込み作業が発生して、一時的にブランチを切り替えたくなったとしましょう。そんなときは、いったん現在のブランチに作業中の変更をコミットしておいてからブランチを切り替えたり、作業中の変更を git stash を使って保存してからブランチを切り替えたり、という操作をすることになります。 そういった操作が簡単に素早くできるのが git の特徴ではあります。しかしそれでも、そういった切り替えが多くなってくると、作業中の変更を失ってしまったり、現在のブランチを勘違いして作業してしまったり

この記事は Chapter I: A Primer on Go Assembly を翻訳、加筆したものです。 この記事では以下のような人を想定しています。 Go言語の文法を理解している サブルーチンコール時の一般的なスタックの挙動を理解している 環境 擬似アセンブリ Goコンパイラが出力するアセンブリは、抽象化されたものであり、実際のハードウェアにマッピングされていません。 Goアセンブラはこの擬似アセンブリを対象のハードウェアに沿った機械語に変換します。 Javaのバイトコードのようなものを想像するとわかりやすいかもしれません。 このような中間層を設けることの最大の利点は新しいアーキテクチャに対応するのが楽になることです。 詳細を知りたい場合は、Rob Pike氏著の The Design of the Go Assemblerを見てください。 Goアセンブリを知るためにもっとも重要なこ

はじめに エンジニアには、アウトプットの文化があります。 僕自身、社外でLTメインの勉強会を２年近く運営していました。 みなさんも日頃から大小さまざまな形でアウトプットをされていると思います。 ですがそのアウトプット、「エンジニアだから」「みんながやっているから」「なんか良さそうだから」といった、なんとなくの理由でやってはいませんか？ どんなことにも言えることですが、目的意識があるかないかで得られる成果は大きく変わってきます。 アウトプットの目的、つまりはメリットを理解することで、アウトプットから得られる成果はより大きくなります。 今回はその「アウトプットで得られるメリット」について、経験を少し交えつつ、お話ししていきます。 なぜアウトプットするべきか それはアウトプットに多くのメリットがあるからに他なりません。 その中でも、僕が特に大きいと感じるメリットはこの４つです。 インプットの質を

間もなくRFCとして公開される、TLS 1.3。 （追記：公開されました！->RFC 8446） 利用できる暗号アルゴリズム（※）を押さえておくことで、 高速ハンドシェイクにいち早く移行したいものです。 ※ 2018年7月23日時点の情報 では早速見ていきましょう。 ★：TLS1.2から新たに追加 or 変更 鍵交換 OK DHE 楕円曲線：secp256r1 ECDHE 楕円曲線：secp256r1 PSK NG DSS（DSA） RSA ★ ROBOT攻撃などに対する脆弱性 前方秘匿性の考えによる安全性向上（static RSAを利用しない） ECDSA ★ 前方秘匿性の考えによる安全性向上（static RSAを利用しない） DH ★ 前方秘匿性の考えによる安全性向上（static DHを利用しない） ECDH ★ 前方秘匿性の考えによる安全性向上（static DHを利用しない）

現代のプログラミング言語ではポインタは単なるアドレスではなく，provenanceを伴った参照として扱われています． 世界は既に変わっています． 概要 ポインタは単なるアドレスではありません． ポインタにはprovenanceという，どのオブジェクト由来かの情報が含まれています． Provenanceを使うことで，最適化が効きやすくなったり，堅牢なプログラムを書きやすくなったりします． 追記: 次の英語記事を読むとprovenanceが必要な理由についてもっとよく知ることができます．クリックしよう！！！！(2020-12-15) https://www.ralfj.de/blog/2020/12/14/provenance.html ポインタはアドレスではない 次のCプログラムを見てみましょう． #include <stdio.h> #include <string.h> int main

概要 sedは、入力ストリームに対して様々なテキスト変換をおこなう、ストリームエディタです。 cut, grep, trといった基本的なフィルタコマンドと比較して、柔軟なテキスト処理が可能です。 このsedの機能の1つとして、パターンスペース・ホールドスペースがあります。 高度なテキスト処理が可能になる反面、パターンスペース・ホールドスペースは、動作が理解し辛いという難点があります。 ですが、sedのパターンスペース・ホールドスペースの動作を丁寧に解説した記事は、私が探した限りでは見つかりませんでした。 そこで、sedを深く学ぶ方への助けとして、また私自身の復習として、sedのパターンスペース・ホールドスペースの動作を、記事としてまとめました。 本記事では、sedのパターンスペース・ホールドスペースの動作を、図示して解説します。 実行環境 Arch Linux 4.8.8-2-ARCH G

コミット日時を上書きしたい Gitのコミットの、差分とコミットメッセージは維持しつつ、コミット日時を書き換えたいことが稀にある。 こないだあったのは、テストのためにローカルホストの日時を未来に変更したままでコミットしてしまい、「未来のコミットになってますよw」という指摘がコードレビューで出たとき。 普通にamendしても上書きされない 通常のamendでは日付は書き換わらない。 $ GIT_PAGER= git log -1 commit 64c414eaa5084c765c79d2e061ced3d5724d00dd (HEAD -> master) Author: foo <foo@example.com> Date: Sun Sep 29 09:59:00 2019 +0900 an example $ date 日 9 29 10:02:03 JST 2019 $ git comm

会社では通知したい情報をIncoming Webhook経由でSlackに通知しているのですが、項目を変更しようと思ってドキュメントを調べたところ、Webhook周りの方針がいつの間にか変更になっていたようです。 思ったより苦戦したので（とりわけドキュメントが英語しかなく）、把握できたところをまとめてみました。 1. Webhookの設定方法の変更 まず全体的な方針変更として、Incoming Webhookの設定方法が「Webhookアプリによるインテグレーション」から「個別アプリからの登録」に変更になったようです。 旧方式 これまでWebhookは https://{workspace-name}.slack.com/apps のアプリ画面からWebhookアプリにアクセスし、各チャンネルに対してカスタムインテグレーションなるもので設定するようなフローでした。 この方式ではインテグレー

こちらの記事は、Jonathan Saring 氏により2019年12月に公開された『 11 Must-Know FrontEnd Trends for 2020 』の和訳です。 本記事は原著者から許可を得た上で記事を公開しています。 ランチ中のフロントエンドトークでスマートに見られる方法！ チームのランチトークでスマートに見られることは、最新のフロントエンドのトレンドを常に把握しておくための大きな理由であることは言うまでもない。 それは、あなたがより良い開発者になり、より良い技術とより良い製品を作るのに役にたつかもしれない。 たぶんね。 だから、いくつかの興味深い方向を示すことで、この名誉あるクエストを君が簡単に達成できるように少し時間をもらいたい。 すべてのコンセプトについて1から10まで説明するのではなく、そのコンセプトとそれがどのように有用であるか紹介しよう。最後にはさらなるリソー

reack-hooksの１機能である useCallback はパフォーマンス改善の文脈でよく登場しますが、どうもその利点や使い方には分かりにくい部分があるように感じます。私も少し前まではまでは「コールバックを子コンポーネントに渡す場合に使ったほうがいいらしい」くらいにしか理解していませんでした。 実際 useCallback は単体で利用してもその効果を発揮しにくく、注意しないと「意味のない useCallback 」が生まれてしまう可能性があります。 本記事ではあえて「意味のない useCallback 」になってしまう例を用意し、その理由の考察と解消を通してuseCallbackの基本的な利用方法を説明します。 (紹介するのはあくまで useCallback 利用の１例になりますが、useCallback の基本的な役割を理解するのに役に立つはずです) 想定読者 useCallbac

はじめに この記事では、OAuth 2.0 のアクセストークンの実装に関する考察を行います。本記事の執筆者本人による動画解説も『OAuth & OIDC 勉強会 【アクセストークン編】』で公開しておりますので、併せてご参照ください。 English version of this article is here → "OAuth Access Token Implementation". 1. アクセストークン実装方法の分類 OAuth のアクセストークン※１の実装方法は認可サーバーの実装依存です。 実装依存ではありますが、RFC 6749 の『1.4. Access Token』にある次の記述が示唆するように、 The token may denote an identifier used to retrieve the authorization information or may

tl;dr git grepやgit ls-filesなどでのパスの絞り方にはpathspecという共通仕様がある :に続けてmagic word/signatureを使うことができ、ディレクトリの除外など高度な検索ができる # リポジトリルート上のファイルでtestという文字列を含むものを検索 $git grep -w test ':(top)*' ':(top,exclude)*/*' きっかけ @laiso さんの「git-grepで特定のディレクトリを除外する」が便利でよく使うのだが、 git grep word ':!exclude/' .という記法がなかなか覚えられず、都度記事を見てしまう。 なぜ:!で除外を表せるのかを理解しないとダメだと思い、仕様を調べてみた。 glob(7)の仕様? helpで仕様を確認してみる。optionがずらりと並ぶが、引数の最後に[<pathspe

この記事は Go3 Advent Calendar 2019 の21日目です。 本日(12/21)時点でのGoの最新バージョンは1.13.5ですが、次バージョンであるGo1.14が2020年２月頃にリリース予定です。 ここ数バージョンで急激に発展してきたGo Modules周りにもいくつか変更が入る予定です。 そこでGo1.14ではどのような変更が入るか簡単に追ってみたいと思います。 Vendoringまわりの変更 vendorディレクトリが存在する場合の-modフラグの挙動 Go1.13時点ではgo mod vendorを行うとプロジェクト配下にvendorディレクトリが作成され、そこに全ての必要なパッケージが配置されます。 Go1.14ではvendorディレクトリが存在し、go.modファイルによるGoのバージョン指定がgo1.14以上である場合、goコマンドがデフォルトで-mod=v

タイトルは「Linuxの「かな漢字変換」」です。ひらがなの文字列を普通の漢字かな混じり文にするソフトウェアの話です。 はじめに この記事ではLinuxの日本語入力を歴史の中で特にかな漢字変換の部分の歴史についての概要です。その時代に広く使われていたと筆者が独断で思う物のみに触れます(触れてない物の中には筆者の友人知人の作品も含まれていて心苦しい点もありますが…)。 Linux以前 - 国産ワークステーションの時代 80年代後半から90年代前半にかけて国内の複数の会社がワークステーションを製造販売していました。各社ではそれぞれのアーキテクチャにUnix系OSを移植し、何社かはそこに搭載する日本語入力のシステムを自社で開発し、さらに素晴らしい事にほぼオープンソースな条件でソースコードを公開していました(NECのCanna, オムロンのWnn, SONYのSj3)。 その中ではCannaやWnn

「経年劣化に耐えるコード」というのは、だれもが目指すものでしょう。「そもそもフロントエンドのコードは、今ある技術で最良のものを書き捨てるべき」という意見も理解できますが「備えあれば憂いなし」ということもありますので、ここにメモを残します。あくまで、私なりのベストプラクティスですのでご了承ください。 5層に別れた SFC 私はレイヤーによる技術の分離で、ReactComponent の経年劣化に備えています。ここでいうSFCとは「Stateless Functional Component」の略称ではありません。Vue.js の文脈にある「Single File Component」を指します。 // (1) import層 import React from 'react' import styled from 'styled-components' // (2) Types層 type

はじめに この記事では、メインフレームでは異常時の処理でどのようなことをやっているのか、また、Linuxの異常処理との違いなどについて話してみようと思います。 この記事を書くに至った直接的なきっかけは、とある人からリクエストがあったからです。が、日ごろからメインフレームの異常処理の考え方については、PCサーバーやクラウドによるシステムがメジャーになった現代であっても、参考になることは多いと感じていてはいました。 筆者は今でこそLinux Kernel周りの仕事をしていますが、20年ぐらい前のころはメインフレームのOS開発部隊に配属されていて、メインフレームのとあるコプロセッサのドライバを書いたりしていました。この際、その異常処理における考え方を体験する機会が多々あり、当時のその経験が20年後の現在でも大いに役にたっていると感じていたからです。 そもそもメインフレームは、これまで長年にわたっ

GitHub の "Allow edits from maintainers" 機能は Organization アカウントからのプルリクエストでは使えないGitHub TL;DR GitHub の "Allow edits from maintainers" 機能は Organization アカウントに fork したリポジトリからのプルリクエストでは使えず、個人アカウントでの利用に限定されているようです。 プルリクエストの右サイドーの1番下（Notifications の下）に表示されるものです。 背景 ある OSS に改善点を見つけたので、自分が所属する Organization アカウントにリポジトリを fork して修正した後にプルリクエスト（spiffe/spire#1468）を作成しました。OSS のメンテナーからレビューを受けたところ「"Allow edits from