memo.yammer.jp

トイカメラで、写真の荒さを楽しむ

Tue, 16 Dec 2025 00:10:00 GMT

2025年も残り2週間、いかがお過ごしでしょうか？

最近私はトイカメラを買いました。

トイカメラを買った

トイカメラとは安価な素材で作られた簡素なカメラを指し、チープな見た目やうつり具合を楽しむもののようです。スマホで高画質な写真が撮れる昨今、細かいところまで綺麗に映るのはありがたいものの、いいと感じる写真を撮るには素人にはどうも腕が足りず、イマイチだなあと感じてしまう機会も多くあります。そこで、あえて逆張りで荒い解像度でトイカメラで撮るなら、細かいことを気にせず写真を楽しく撮れるのではないかと思い、、買って試してみることにしました。

買ったのはImpress Watchの記事でも紹介されているKODAK Charmeraというカメラです。

手の中に収まる小さな筐体で、重さも軽く、まさにキーホルダーのようなサイズで、ポケットやバッグの隙間にするりと忍ばせることができるコンパクトさが特徴。

充電と転送はUSB Type-Cで行えます。私はキーホルダーサイズの短いケーブルを買って、iPhoneから取り込んで使っています。

届いて1週間ほど、それまでの間に取ってみたいくつかの写真とともに近況を紹介します。

近況

筐体は小さく、そしてとても軽いので、ポケットに入っていてもあまり存在を感じないこともあるぐらいです。

ふと観葉植物を買うことになり、家の中にフェイクグリーン以外の緑色が増えました。買ってみると結構見栄えが良いので、部屋の中を生い茂らせたくなってきます。冬だからか水やりの頻度はずいぶん少ないらしく、まだまだ土が乾きません。

Charmeraにはいくつかのフィルター機能があるっぽく、ハイキングの帰りの農道ののどかなところをさらにのどかにしてみました。

というように、日常のなんともない写真でも自分の中で楽しむ機会が増えた気がするので、購入してよかったです。そのうち飽きそうな気もするが、まだ飽きていないのでしばらくは楽しむことにしましょう。

画像の投稿場所

さてさて、こういった画像を振り返られるようにどこかに上げておきたいのですが、このブログは画像をあげるのには少し億劫なところがあります。画像はAmazon S3においているのですが、アップロードは手動でCLIかマネージドコンソールからあげるという温かみのある運用なのです。というわけで、新たに投稿できる場所を用意しました。

https://toycamera.yammer.jp/@yammer

画像を投稿できる場所はSNSの他にもawkで作ったブログだったり、OSSのmemosというアプリをホストしているマイクロブログだったり、すでにいろいろあるわけだが、いくつ作っても捕まるわけではないので、もう一つぐらい良いでしょう。 DynamoDBに馴染みがなかったのだが自分の道具箱に入れておきたく、素振りもかねて、カメラが届くまでの間にAIにコードを書かせていました。

どう作ったかと要素技術の感想を以下に少しメモしておきます。技術の話をスキップするには、次の節「締め」へ！

S3とDynamoDBにつながるTypeScriptで書いたアプリをHonoで組み立て、Lambdaに上げてFunction URLs + CloudFrontで配信しています。管理画面は@hono/oidc-authでGoogleアカウントで入れるようにしているので、私以外も使えるように広く公開できるのですが、OAuth 2.0アプリの公開が面倒で自分に閉じたままになっています。

ちいさなCRUDの機能があるだけですが、入門としては大体こんな感じかというのを一通り試すことができました。 HonoのLambda向けのボイラープレートがよくできていて、そしてLambdaをNode.jsランタイムのまま使うとデプロイが超早くて体験が良かったです。ただし、Function URLsとCloudFrontの組み合わせは、OACでPOST/PUTを受け付けるには、ヘッダにsha256sumをつけなきゃいけないというのが結構謎で、完全なMPAにするわけには行かなそうで、ここは少し使いづらいと感じます。

DynamoDBは、シングルテーブル、パーティションキーとソートキーの指定、GSIあたりの存在を知り、スキーマの検討の時に、どう引くかを想像しながらやっていくと良さそうな感触を得ました。従量課金でスケールするということで小さな個人のアプリなら特に考えることはないのですが、商用環境でのトラフィックのスパイクは、RDBよりはよっぽど捌きやすいとはいえ、流石に何も考えなくていいなんてことは全然なさそうで、ある程度のキャパシティプランニングや、スパイク幅の考慮が必要そうというのも見えてきました。それはそう。

締め

本記事は、GMOペパボ EC Advent Calendar 2025の5日目の記事でした！遅くなってしまってすみません！

前日(概念)のtichiseさんのDevinが得意なこと・苦手なこと - 7ヶ月の運用から学んだことは、特に力を発揮するタスクの規模の要件や内容が具体的だったのが、再認識できて学びになる記事でした！翌日(概念)のkarugaさんの2025 アルコールカラーミーショップ検索、URLがシンプル sake で美しいですね！たくさんのショップ様に使っていただけるのはありがたく、身が引き締まる思い出もあります。

そのほかばなさんやちょりーさん、おみきさんの記事を見ながら、私も一年を振り返らねばという気持ちになりました。年末は時間に区切りをつけて振り返り、次の振る舞いを改める良い機会ですね。山のことを振り返ったり、仕事のことを振り返ったりもしたいのですが、なかなか収まらなそうなのでまた別の記事にすることとしましょう。

それでは、良いお年を！

メール送信者認証技術の整理

Fri, 04 Jul 2025 18:52:00 GMT

SPF, DKIM, DMARCをはじめとするメール送信者認証技術のトピックが時々必要になるので、自分用のメモとして書き出しておきます。覚えていないところはRFCを見たりしていますが、記憶の中を書き出しているだけので、間違っているところがあったらご指摘ください。

メール送信者認証技術はなぜ必要なのか？

SMTPで送信元を表すのは、IPアドレス、エンベロープFrom、ヘッダFrom

メールは、SMTPというプロトコル上でやり取りされます。この時、送信者側がどのホスト名からの接続か宣言されることとなっており、これがいわゆるエンベロープFromと呼ばれます。SMTPプロトコル上ではメールの内容(メールヘッダ+メールボディ)を合わせてテキストとして送信し、メールヘッダの中には送信者を表すFromのヘッダ(いわゆるヘッダFrom) が書かれています。

SMTP上でエンベロープFromとヘッダFromを検証する仕組みはない。どのメールを受け取るかは受信者が決める

SMTPのプロトコル上は、エンベロープFromとヘッダFromは特に縛りがなく、何を書いても規格上は問題ないメールとして取り扱われます。これが問題で、メールは送信者が好きに自分の身元を名乗りたい放題のプロトコル¹になっており、送信元のアドレス (=ドメイン) が本当にその人の所有しているものかを確認する術がありません。このような性質から、スパムメールと呼ばれる正当な送信元ではないメールも多数流通し、それに対応するために、インターネット上のメールというエコシステムでは、基本的に受信者が受信するかどうかを決めることでコントロールしている、というふうな構図となっています。

大手の受信者が公開しているポリシーに、送信側は実質的に従う必要がある²

特に影響力のある大手の受信者(GmailやMicrosoft(outlook.com)、iCloud等)に受信してもらえるよう、送信者側がその基準を満たすようなメールを送る必要性が、昨今高まっています。明確に方針として示されたのが、2024年から適用されている、いわゆるGmailガイドラインです。Gmailに向けてメールを送る全ての送信者に一定の基準を設け、また大量送信者には、より厳しい基準を設け、満たさないメールは受信拒否すると宣言されました。後述する、メール送信者認証技術 (DMARC=pass) への準拠が求められるようになったことで、メールの送信者、特に大量送信者にはその対応が求められました。また、現在や今後も、大手受信者のポリシー変更があれば、追従する必要があります。

個々のメール送信者認証技術

メールの仕組みに話を戻しましょう。

受信者側が、そのメールに書かれている送信元が正当かどうかを確認する等のための仕組みとして、メール送信者認証技術があります。これが SPF, DKIM, DMARC (そしてBIMI！) などの各種規格です。

DNSレコードに書かれていることは、ドメインの所有者の意思で書かれているはず

どのプロトコルも基本的に、DNSを信頼の元としています。ドメインの正当な所有者だけがDNSにレコードを登録でき、世界にその情報が正しいと伝えることができるはず、という点が起点となっています。DNSのTXTレコードに書いてあるを信頼し、受信したメールがそれと一致するかを、受信者側で検証することで、メール自体も信頼できるかを判断できるようになっています。

SPF (passならば、エンベロープFromのドメイン所有者が認めたIPアドレスのサーバから送られたとわかる)

SPFは、次のようなDNSレコードを公開するものです。ドメインの所有者が、メールを送出するサーバのIPアドレスをTXTレコードとして宣言することで、それ以外のメールサーバから送出された場合は不正であると判断できるようになります。SMTPはTCP/IP上で成立していますから、送信元のIPアドレスは通信時にわかるので、それと比較して問題ないかを確認できます。

example.com. IN TXT "v=spf1 ip4:192.0.2.100 ~all"

ただし、ここで受信者が引くドメインは、エンベロープFromのドメインです。ヘッダFromに書かれた内容は検証されません。一般的なメールクライアントで送信元メールアドレスとして表示されているのはヘッダFromですが、全く違っていても検証されず、SPFはpassしたと判断されます。

DKIM (passならば、署名したドメインの所有者がそのメール内容を送信したとわかる)

DKIMは、次のようなDNSレコードを公開するものです。ドメインの所有者が、公開鍵を公開します。メール送出時にドメインの所有者(か権限を委譲された者。以下略します)しか知らない秘密鍵でメールの内容に署名することで、署名を検証すれば、ドメインの所有者の送出したメールの内容(ヘッダやボディ) が正しいことを検証できます。

default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD3JbLw...（公開鍵の文字列）...AQAB"

ただし、ここで署名したドメインは、ヘッダFromやエンベロープFromでなくても良いことになっています。

DMARC

DMARCは、次のようなDNSレコードを公開するものです。メールの受信者に対して、受信したメールの取り扱い方法を宣言するものです。SPFやDKIMをどの程度厳格に検証すべきか、また検証失敗時にその旨をレポートする先を示しています。

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-report@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1; adkim=r; aspf=r"

DMARCには、SPFやDKIMを組み合わせて、メール送信元の確からしさを判定する基準の一つである「アライメント」を定めています。また、DMARCの基準を満たしていない場合に、それをレポートする仕組みがあります。順に見ていきましょう。

アライメント

SPFアライメントはエンベロープFromとヘッダFromが一致している時に、満たしていることとなっています。SPFがpassしている状況下では、送信者として表示されるヘッダFromのドメイン所有者が、そのメールが送出されたメールサーバ(IP)を信頼しているので、その点で確からしいメールだと言えるでしょう。

DKIMアライメントは署名ドメインとヘッダFromのドメインが一致している時に満たしていることとなっています。DKIMがpassしている状況下では、これを満たすメールは送信者として表示されるヘッダFromのドメイン所有者がメール本文に署名していることから、その点で確からしいメールだと言えるでしょう。

なお、SPFまたはDKIMのいずれかにpassし、かつSPFアライメントもしくはDKIMアライメントのいずれかをpassしているとき、DMARCにpassしたと判定されます

ポリシー

DMARCにpassしていないメールがどれくらい流通しているかを、ドメインの所有者が知るために、ポリシーを宣言することとなっています。 none , quarantine , reject があり、各受信者に、そのポリシーに従ってメールを取り扱うことや、 DMARCをpassしないメールがあったときに、その内容をレポートするメールを送信してほしい旨を宣言します。

送信者としてのポリシーであり、仕組み上受信者が従わなければならないような制約はないですが、成り立ちからして受信者の事情からできてきたものであるからこのようになっていると理解しています。

BIMI

BIMIは、次のようなDNSレコードを公開するものです。メールの受信者に対して、送信元のブランドロゴを宣言します。

default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/bimi.pem"

BIMIは、DMARCのポリシーが quarantine 以上であり、かつロゴが VMC (Verified Mark Certificate) と呼ばれる証明書で署名されている必要があります。VMCでの署名を受けるには、各国の機関による商標等の知的財産権の登録が必要となっています。

BIMIがサポートされる環境で、確認されたメールには、送信元を表すロゴが、メールクライアントに表示されます。

というわけで、メールを専門に取り扱わないWebアプリケーションエンジニアにとっては、HTTP以外のプロトコルのことを考える時間は珍しいでしょうし、SMTPとそれをもとに構成された多層のメールエコシステムに関する理解は、忘れてしまうと面倒そうなのでメモとして書き出しました。

メール技術のキャッチアップ

私が2024年や2025年にメールに関する学びを得た書籍とWebサイトを紹介して終わります

実務で使えるメール技術の教科書 ... 2025年現在で、メールに関連する技術を、その分野に詳しくないソフトウェア開発者がゼロから知ろうと思った時に事前知識なく読み始められる丁寧な書籍
azumakuniyuki/feb-2024-no-auth-no-entry ... Gmailガイドラインをはじめとする、2024年以降の大手メール受信者プロバイダの公開するポリシーを時系列で記録したリポジトリ。過去に公開されていた内容との差分や、特定の事業者に閉じない大手メール受信プロバイダの動向に気づくことができる
古い技術について SMTP現代事情つまみ食い ... SPF/DKIM/DMARCの関係性を説明してくれている
ISPmail GUIDE ... Postfixの設定や運用として2025年に求められるものを最小範囲で実現し、手元でメールサーバを動かしてみることができる手順を解説したドキュメント。Postfixに関する書籍や入門書は最近見かけておらず、このリポジトリを読み進めながら触るのが結構良さそうという感触を得た。
RFC7208: Sender Policy Framework (SPF) ... SPFのRFC
RFC6376: DomainKeys Identified Mail (DKIM) Signatures ... DKIMのRFC
RFC7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) ... DMARCのRFC
Internet Draft: Brand Indicators for Message Identification (BIMI) ... BIMIはまだRFCになっていない
Generic IP Warm Up Schedule ... (メール送信者認証技術と直接関連ないが)新しいIPv4アドレスを使ってメールを送るにあたっての具体的なIPウォームアップの指標をSendGridが示してくれている表

ここでは2025年現在の視点から、現時点でわかりやすく理解するために「名乗りたい放題のプロトコル」と表現していますが、実際にはインターネット技術の発展とともに、現在のメールエコシステムを構成するパーツが一つずつ構成されていったのであって、SMTP自体は、シンプルな文書通信のためのプロトコルであるでしょうし、その成り立ちや技術に対する対する批判等の意味合いは持っていません。ただ、パーツが色々あるので、新米Web技術者が今からキャッチアップするのは、普段メールシステムに馴染みがないとなかなか大変だという感想を持っています。 ↩
ここでは送信者の視点で「従う必要がある」などと書いていますが、実際には受信側からするとそのような方法でしかメールの確からしさを確認したり、大量受信による負荷を抑制することができませんし、メール全体のエコシステムとしてそのようなポリシーの公開や適用は必要である、と前向きに捉えています。 ↩

GMO Developers Day 2024に登壇した

Sun, 01 Dec 2024 14:59:05 GMT

昨日、11/29, 30に開催されたGMO Developers Day 2024の「EC決済開発責任者対談」というセッションに登壇した。

Developers Dayの登壇は昨年に続き2回目で、前回に引き続きGMOグループとして力入れてるなというのを感じる。

今年も、去年私が登壇した枠と似たようなパネルディスカッションに近い形式で、 @inamoly によるモデレータ+3人での対談を行った。事前の打ち合わせで何を話すか多少擦り合わせていたが、そのときに出てない話も本番では話していたり、対談の臨場感が現れた発表になったと思う。

対談形式の発表は特定のメッセージを強く伝えるようなものではないが、当日聴いていただいていた参加者の層はけっこうバラエティ豊かだったようなので、日頃考えていることや実践していることがどのようなものであるか、等身大で知ってもらうという意味で、会場の雰囲気にマッチした発表になったのではないだろうか。

今年はあまり緊張せずに望めたのだけど、発表がおわってから「他の人の2倍の時間2倍の速度で話していたので情報量4倍」「身振り手振りで全身使っているのがいつもどおり」などのお声をいただき、 (それはそれでよかったのかもしれないが) もうちょっと緊張するぐらいがよかったかもしれない。

昨年もそうだったのだけど、このイベントはグループ横断でやるので対談する我々も打ち合わせで初めて出会うといったところがあり、近いセグメントの他の会社でどのようにやっているのかを聞けて私も新鮮な気持ちで学びになった。

聴いていただいた方ありがとうございました。

アーカイブはこちら: GMO Developers Day 2024【Day2 Track A】

この記事は、GMOペパボ EC Advent Calendar 2024の1日目、そしてGMOペパボエンジニア Advent Calendar 2024 (🎄会場)の1日目の記事でした。

GMOペパボ EC事業部CTOに就任しました

Mon, 07 Oct 2024 02:00:00 GMT

2024年10月1日付で、GMOペパボ株式会社 EC事業部CTOに就任しました。

事業部CTOとは

事業部CTOは、ペパボのエンジニアリングマネジメントラインのなかで、部門の技術領域の責任者として設けられていたSEL(シニアエンジニアリングリード)¹を、2024年2月に再定義²した役職です。

部門ごとに異なる事業を運営するペパボは、事業部門のなかに開発組織を含む様々な職種のパートナーがおり、それぞれ様々なサービスを提供しています。事業部CTOという役職は、技術と技術組織の責任者として部門を成長に導くという点は以前のSELと変わらず、部門をひとつの会社として見立てたときのCTOの果たすべき役割を、より強く明確にしたものといえます。

ところでCTOとはどのようなものでしょうか？これを端的に説明したものとしては、次の文章がわかりやすいでしょう。

CTOとは、その会社が現在の成長段階で必要としている戦略的技術系幹部

(エンジニアのためのマネジメントキャリアパス p217 - オライリー・ジャパン発行)

これを事業部に当てはめると、いまの事業部の成長段階に求められていることを技術の面からとらえ、長期的な視点で、成果を実現するための策を立案し実行すること、その枠組みが運用された状態をつくることが求められています。

やっていき

事業部CTOとしての私の仕事は、カラーミーショップをはじめとするEC事業部の事業をより一段と成長させ、ショップオーナー様に喜んでもらい、EC事業部の目標を達成し、そしてECの多様性をひろげること、それを実現するために技術と技術者組織としてできるあらゆる戦略をたて実行すること/それを支援し実現することです。

既にEC事業部には前任の@kenchanを中心に積み上げてきた、システムを支える様々な技術、そして素晴らしいパートナーのみなさんをはじめとする技術者組織がありますが、現状に満足しない私たちには、次なる挑戦が待っています。

EC事業部を中心にパートナーのみなさんにはこれまで以上に頼ることが増えるでしょうし、皆さんの力を借りて前に進むことになると思います。いままで支えていただき感謝しています。今後ともどうぞよろしくお願いします。

バーンとやっていくぞ〜！

お隣さん

同日にホスティング事業部CTOに就任した@takumakumeのポストはこちら。

GMOペパボ株式会社ホスティング事業部CTOに就任しました

kumeさんはあらゆることをバリバリ進めていて、話していると「負けていられないぞ」という気持ちになります。

お誘い

ペパボとペパボパートナーの話ばかりしていてきになったあなたにはこちら！いま絶賛採用募集中です。

GMOペパボ株式会社採用サイト

仕事中の私とのカジュアル面談も、とくに関係ないご飯や飲み会の誘いも歓迎してます！XのDMかなにかで連絡ください。

また、26卒の新卒採用やってます。私も21卒で新卒で入ったので、ペパボやエンジニアリングマネジメントラインの仕事がきになるという方いたら声をかけてください、お話ししましょう！

そして！特に大事なこちら！EC事業部としても採用してます。Webアプリケーションエンジニアもデザイナーも！今がチャンス！まってます

当初2016年に設定された時はCTL(チーフテクニカルリード)という名前でした。 ↩
ある種CTOに近い役割が求められていることはCTLができたその時から意識されていたわけですが、名前としてそれを表すことで期待と責任を示したことを、ここでは「再定義」と呼んでいます。 ↩

財務3表一体理解法を読んだ(2024年8月)

Sun, 22 Sep 2024 14:44:08 GMT

8月に読んだ本のメモが下書きのまま眠っていたので投稿しておく。また当方は会計の専門家ではないので、この感想にツッコミどころがあったらこっそり教えてください。

はじめに

企業における会計のことを少しはわかっていなくてはと思い、友人に薦められた財務3表一体理解法という本を読んだ。

学生時代も入社してからも会計のことを学んでおらず、PL (Profit and Loss Statement / 損益計算書) やBS (Balance Sheet / 貸借対照表)、CF (Cash Flow Statement / キャッシュフロー計算書) というのを名前は知っていても実態は正直わかっていないという状態だったが、本を通して全体感を知ることができた。

知りたいことがまさに書かれていて、一冊目に読む本がこれでよかった。(正確性をとるとおそらく大胆に削っているところがあると本の中で但し書きされているが) PLとは？BSとは？というレベルの会計素人が、まず最初に雰囲気を知るにはとてもよいと思うので、同じ境遇の人がいたらぜひお勧めしたい。

印象に残ったこと

前提

冒頭に前提として、すべての会社に共通する3つの活動は「お金を集める」「投資する」「利益をあげる」の3つからなるということがかかれている

これらを数字で表現するのが財務3表であるとして、財務3表の概略的な説明が冒頭になされている。

財務3表の関係

93ページには、3表がどう関連してどう動くかが示されている。その後、本の中頃では、表題の通り財務3表を一体に理解できるよう、かんたんな仕分けをいくつか、常に財務3表にどう反映され、それらがどう繋がっているのかを示しながら説明が続く。各例をもとにそれぞれの関係を常に意識させながら説明が続くので、全体感を把握しやすい。

会計を専門にする気が今のところない物としては、全体としてそれらがどういう役割で、ざっくりどういう意味を持っているのかということを知りたく、それが説明されていてとても良かった。

その流れというのは、ざっくりと次のようなものだ。

PLによって資産の出入りが表現され、その積み重ねによってBSの利益剰余金が積み上がる
前年度のBSをもとに今年度のPLをあて、CFをあてたら翌年のBSになる

そのほか印象に残ったこと(メモ)

前提として、PLとBSの数字は必ずしも現金の動きを表すものではない
BSのBalanceというのは「残高」という語から来ていると筆者は考えている
りし ... 借り方と貸し方という表現は、現代におけるそれぞれの言葉の意味に紐づくというよりも、慣習的にそうなっているという側面が強い

身近な会計

本の中で直接触れられているわけではないが、この本を通して内製ソフトウェア開発をしている事業会社における、ソフトウェア資産計上と原価の違いを知ることができた。¹

おわりに

PLといわれても学園と言わないように、BSと言われても衛星放送と思わないように、CFといわれてもコンパクトフラッシュと聞き返さないように、この本を起点に会計に関する理解を少しずつ深めていきたい。

ちなみにこの本はシリーズになっていて、分析編や発展編というのもある。とても良い本だったので早速発展編を買ったのだが、買ってから中を開くと今知るべき内容かは判断がつかなかったので、積んでおいて技術書のあいまに気が向いたら読むことにする。

友人にこの話を聞いた時に、最初にソフトウェア資産計上の目的 (会計の原理原則として、投資家等にその会社の状況(ここでいえばソフトウェア資産)を正しく伝えるためにある) を教えてくれたことで、より理解が深まった ↩

私と技術カンファレンス 2023 (雑文)

Sun, 31 Dec 2023 14:51:18 GMT

技術カンファレンス Advent Calendar 2023、11日目の記事をお送りします。今は2023/12/31な訳ですが、今年中に出し切るということで先ほどから書き始めました。推敲していない雑文をお許しください。

私がカンファレンスにはじめてちゃんと参加したのはPHP Conference Japn 2022であった。これはスポンサー枠で登壇したもので、緊張もしたけれど思ったよりもたくさんの方に聞いていただいて嬉しかった。

社内のレビューによってとても良い発表ができたが、いっぽうで会社の代表なので、会社としての取り組みを紹介するというのが主だった。自分でプロポーザルを書いて出して自分のやったことを話したい、という気持ちを強くし、次は自分でプロポーザルを出すことにした。

PHPerKaigi 2023ではLTのプロポーザルを出して、登壇できたのだけれど、とにかくこのイベントは楽しかったのを覚えている。カンファレンスは自分が普段能動的にキャッチアップするより少し外のことを知る機会になるし、会社に閉じない技術的なトピックについて話したり確認する場にもなるし、出会った人と談笑したりと、他では得られない経験を得られる。

RubyKaigi 2023は、言語を作る人たちのお祭りというところで、規模もそうだが、ランタイムに関する話題がたくさんあったのが印象的だった。自分は言語を使う人なので全然ついていけない話題ばかりだけれど、学校の授業で習って教科書的なトピックだなと思っていたLALR(1)構文解析の今をしれたり、JITの今をしれたり、とても刺激的だった。Webというのはソフトウェアエンジニアリングの中でも一部の領域を扱っているだけなので、それよりも外の部分に視点を持つことを忘れずにいたい。

PHPerKaigiのLTに登壇できることになったので、次はもっと長い枠の登壇をということで、PHP Conference Japan 2023にプロポーザルを出してみたけどこれは残念ながら通らず、このイベントは参加者とブース運営の人として参加した。セッションはあまり聞けていないのだけど、カンファレンスに参加し始めて1年くらいということもあって、少しずつ顔を見知った友人や知り合い、以前話したことのある方もいるというので、また話すのが楽しかったりした。(カンファレンスに限らず、今年は都合で行けなかった勉強会にも、来年は行きたい。)

プロポーザルはその後も継続的に出していて、来年はいまのところ、YAPC::Hiroshima 2024とDevelopers Summit 2024で採択いただけて話すことになっている。これに限らず、参加者、発表者、またもしかしたら別の形でも、カンファレンスに参加したり盛り上げたりして、会社に閉じずに、技術者として技術の向上に励んだり、楽しんだり、知見を広げたりしていきたい。

カンファレンスという場を作ってくださっている皆さんにはいつも感謝しています。自分も少しでもより良い場所になるように、関わっていけたらと思っています。

それでは、良いお年を。

ISUCONに初めて参加した(2023年12月)

Fri, 08 Dec 2023 14:43:12 GMT

(2024/09/22記) 去年のISUCON13に参加したときの記録が下書きのままになっていたので、いまさらですが公開します。

同期の @homirun @yukun と一緒に、ISUCON13に参加しました。

結論はこれ。

くやしい、おもろい！
— やんまー (@yammerjp) November 25, 2023

最後のスコアは1万点にギリギリ届かず満足できないけれど、何もわからんという感じにはならずやることはたくさん見えていたので、次回(が開催されるならば)ご期待ください！

やったこと

前日まで

夏頃から、毎週1時間くらい業務後にあつまって練習していた。ISUCON本を読んでprivate_isuをいじってみたり、APMを入れてみたり。1時間でできることは限られているけれど、なんもわからんというところからちょっとずつ全体感をつかむことができた。

前々日には、本番の半分くらいの時間でISUCON12の予選問題を解いた。ベンチマーカーのCLIの引数にIPアドレスを指定できることに気づかずベンチマーカー内の名前解決に困ったり、初手でSQLite -> MySQL移行をしようとし詰まったり、ほぼ何もできなかった。この経験はおそらく当日に生きていて、この日に先にハマっておいたおかげで、当日無理にロードバランシングに手をつけずに済んだ感がある。

前々日と当日は、渋谷某ビルの(勝手)サテライト会場で開催した。物理的に集まってホワイトボードに構成を書いたりしながら同期的に進めるのは、結構楽しさがあった。

当日午前

当日の出来事は以下のような感じ。(全部覚えていないので、自分以外のメンバーがやってくれたことは書かれていないことも結構あると思う)

初手は競技とアプリケーションのドキュメントの読み合わせ
次に、Cloud Formationで起動してそのままベンチマークを一回回してもらった
最初はMySQLの中身をdumpして保全したりした。(これはあんまりいらなかったかも)
Datadogをさくっと導入してくれたので、一番上に出ていた/api/user/:username/statisticsのうち、ランク算出のN+1を直す。GROUP by user_idでSUM/COUNTするクエリにして、一番重そうなところを直したらボトルネックが他に移った。N+1がまだ残っているのを横目に見つつ、呼ばれる回数が少ないエンドポイントなので他を優先するために無視。
裏ではPowerDNSをやめたりMySQLを分離したりタグ周りのN+1を潰したりしてくれていた

当日お昼頃

コードをローカルで編集しても試しづらいので、途中で占有できる実行環境が欲しくなり、Cloud Formationをつかって競技外のインスタンスを開発用に用意してもらって、そこで自分だけのVMを手に入れた。
このあたりでサブウェイにみんなでランチを買いに行った気がする。エビアボカドを頼んだ。フットロングにはしなかった。
Datadogの合計実行時間の長いクエリを上から眺めて、貼っていった。ORDER BY created_atがいくつかあったけど主キーがAUTO INCREMENTだったから主キーでソートすることにしたりした。
ここまでのVM分離とN+1とインデックス追加で10000点ちかく行っていた気がする。(合ってるっけ) このあたりまでは結構順調だった気がする

当日夕方

/api/livestream/:livestream_idのN+1がひどいので直そうとしたが、バグらせてしまって元に戻すなど。ベンチマーカーがエラーを吐く状況をつかめなくて、再現できずに結局最後までこの変更を入れることはできず。
裏では重そうな箇所をメモリでキャッシュする戦略を試してくれていたっぽい。詳しくはみていないがキャッシュのパージタイミングがむずそうっぽかった。
MySQLのパラメータチューニングや、DNSとアプリのVMの分離で、+1000点弱あがっていそうだった

振り返り

よかったこと

ローカルに開発環境を用意しようとしなかったのは良かったと思う。しゅっとできないと時間が食われてしまうので。

チームメンバーが自分ができないことをバンバンしゅっとやってくれてとてもありがたい限りだった。yukunがDatadogをさっと入れて、なんなら競技時間中に全然わかっていない私にDatadogの使い方を説明してくれたり、homirunにミドルウェアまわりを完全に任せっきりにしていたが勝手にいい感じにしてくれていたり。

Datadogが最強すぎて、スロークエリログもエンドポイントごとのalpでの解析もみずに、Datadogみておけばいいじゃんという感じだった。これのおかげで、次何やればいいかわからんみたいなことにはならずに「明らかにここらへんをやったほうがいい」がわかる状態になれた。

改善したいこと

設定ファイルやスクリプトなどは持ち合わせていなかったので、viキーバインドでないbashターミナルや、コミットメッセージを入力するときに起動するnanoに困ったりしていた。共有環境にdotfilesをそのまま流し込むと他の人も影響を受けるので、自分だけ効くような初期化スクリプトを用意しておく方がいいかも。

明らかにN+1なのはすぐにみつかるけど、それをユニットテストもローカルの開発環境もない中、短い時間でコードを一気に書き換えきるみたいなことに慣れておらず、なかなかうまく直せなかった。

コードを書いてから動作確認までのフィードバックループが長くなりがちなので、たとえばGETの正常系の動作確認などでもいいから、簡単なものはさっと動作確認できる環境を整えておいた方が良かったのかも。変更前と変更後で同じcurlコマンドの結果が一致することを確認する、みたいな。

後半に取り組んでいた改善は結局入れられなかったので、バグらなそうな変更方針を建てて、走りきれそうな範囲を決めて直す、というふうにしたほうがよかったかもしれない。全部直すのは時間的に絶対無理なようなので。

おわりに

とてもおもしろい会を開催してくださった運営の皆様に感謝します。一緒に戦ってくれたチームメンバーに感謝します。くやしい、そして楽しかった！

チームが気付き、変化する

Sun, 03 Dec 2023 10:42:23 GMT

GMOペパボ EC Advent Calenderの2日目は、yammerから、私の所属するチームについての話題を紹介します。

1日目の記事は、@kenchanの『「炭鉱のカナリア」になる』でした。自分が今年、消防車を呼べたとき、呼べなかった時はいつだっただろうか？と思い出しながら読みました。3日目の記事は@tatsumi000の、「開発環境.nvim 2023」です。Vimmerでありながら就業時間中はVSCodeのVimプラグインに甘んじている身として「1週間くらいNeoVimだけで生活してみようかな」と心が揺さぶられるトピックでした。¹

私が今いるチームは2023年の年初に発足し、はじまってからおよそ1年が経ちました。1年の中ではさまざまなことがありましたが、チームの中で違和感を感じるたびに、問題を発見し、解決策を見出し、一つずつ変化が加わっていったと感じています。今回は、そういった変化の中で一つ、コードレビューに関する変化を紹介します。

半年ほど前、Pull Requestのコードレビューが溜まりがちだったあるとき、チームに「良い環境で働く大切さ、良い環境を作り出すためには」という記事が持ち込まれました。課題感と、その参照としてこの記事のURLがチームのSlackチャンネルに投稿されたことは、コードレビューに各々が課題間を抱えていることが言語化され、共通認識となるきっかけになりました。課題にチームが気づき、変化した瞬間でした。

その投稿の後、コードレビューの速度を上げるために、別のドキュメントなども参考に、いくつかの点が整理されました。

コードレビューは素早く行われる必要があること。少なくとも1営業日以内に返答すること。
コードレビューが難しい時には、コメントを返す以外のアクションをとると良いこと。たとえば「コードレビューが難しい状態であることを伝える」「Pull Requestの内容や周辺領域の知識について口頭で説明を受ける」「ペアプログラミングをする」など。

こういった整理と認識合わせが行われてから、コードレビューレビューの速度が改善し、滞留することが少なくなったと感じています²。レビュワーが早く返答するだけでなく、レビューのしやすいPull Requestや開発手順にするといった変化を含めて、半年経った今も、上記に示された速度の基準を満たし、ボトルネックになることが少ない状態を維持できていると考えています。

この変化の重要な点は、チームのSlackチャンネルに、課題に対する呟きがあったことです。チームが問題に気づいて改善するためには、まず、誰かが違和感を感じ、それを共有することが必要です。コードレビューの他にも、たとえば実際にあった以下のような変化も、誰かが課題を共有したからこそ起こったものです。

スプリントゴールの定め方を見直す
見積もり会を定期開催にする
ふりかえりの進め方を変える

チームが発足して時間が経ち、成熟してきましたが、これからも、違和感に気づき、仕事の進め方に変化をもたらせるチームでありたい/あってほしいと思っています。今日までのチームはメンバー全員がつくってきたもの³で、明日からのチームもメンバー全員が作り出すものです。

チームのみんな、そして一緒に働いてきたパートナーの皆さん、2023年もお世話になりました。ありがとうございました。来年もどうぞよろしくお願いします。

この記事が2日目のものなのに、3日目の記事の感想がかかれているために、時空が捻じ曲がってしまったのではないか？と心配したそこのあなた。その通りです(嘘です)。話がまとまらずに1日遅れてしまったことをどうかお許しください。 ↩
私自身もコードのレビューをする機会が多いので、自分の認識がアップデートされ、レビューの速度に注意を払うようになったという変化も含みます。 ↩
もちろん、チーム外からのたくさんのサポートや、コラボレーションによって作られてきたものでもあります。 ↩

人月の神話を少し読む

Thu, 13 Jul 2023 05:40:00 GMT

人月の神話 (Frederick Phillips Brooks, Jr. 著、滝沢徹訳、牧野祐子訳、富澤昇訳、丸善出版発行)を、いくつかの章は流しながら読んだ。

この本は1975年に初版がでたもので、そろそろ発売から50年になろうとしている。記事の中に書かれている個々の事象は「お、まじか」と驚くような (しかし当時としては妥当であっただろう) How Toも多数ある。50年経つことを前提に置いて、細かい事象にはあまり深入りせずに読むことにしていた。

本の中で語られる「人」と「月」の常に等価交換できないということは、2023年の私の身の回りではありがたいことに当たり前に認識されているように思う。当たり前になっていることが、この本の功績なのだろう。

本の主張の本質はそのあたりだと思うが、それ以外に本を読んだ中で気になったトピックをいくつか記す。

ソフトウェア実体は、どの2つの部分をとっても似ることが無いので (少なくとも文レベルより上では)、大きさの割にはおそらく他のどの人口構造物よりも複雑なものだ。似通っている部分があれば、2つの類似部分を1つ - 外部または内部サブルーチン - にする。この点においてソフトウェアシステムは、重複要素 (部品) が、豊富なコンピュータやビルあるいは自動車などとは全く異なっている p171

ソフトウェア実体は、どの2つの部分をとっても似ることが無いと言い切れるかはわからないが、同一では無いとは言えると思う。ソフトウェア製品やソフトウェアデータの良いところの一つに、複製のコストがほぼかからないという点があるが、これをプログラムの内部構造に置き換えると、同一の操作を繰り返す場合はforや、関数、オブジェクトなどで処理をまとめられてしまう。¹

建築物や機械製品の場合は同一のパーツというのが多数含まれており、それらの組み合わせで製品が成り立つ。つまり、設計図の中に記述されるコンポーネントは重複がある。プログラムの場合は、重複がないように構造を変えてしまうことができるので、設計図の中のどれも同一のコンポーネントではない。²

悲しいかな、自由形式で生成された英語のコマンドを確実に解釈する機能は、コマンドが音声であろうと文字であろうとも、現在の技術を超えてしまっている。p254

これは初版にはなかった章で、おそらく1995年などが文章中の「現在」にあたるが、この記述はいま大きく変わろうとしているように思う。たとえばスマートスピーカーのようなものはそれを一部示していたし、LLMの台頭により、今後のユーザインタフェースは自然言語をベースにして複雑な、プロ向けの操作も実現可能になるかもしれない。

プログラマは自分の担当でないモジュールの内部については、見せられるよりも隠蔽された方が非常に効率が良いのだと言う。p265

これは、例えば一例として低級言語を使う時と高級言語を使う時の違いに近いところがあるだろう。コンピュータのなかで行われている抽象化を自分のプログラムの中でも実装せよ、ということだ。高級言語でメモリアロケーションやメモリ上のデータ配置について考える必要が減るように、OSの提供するシステムコールを使うことでハードウェアの制御を考えなくて良いように、APIを介して外部サービスを使うことで、細かな挙動を気にせずに機能を利用できるように、ということと本質的には一緒に思う。自分が書くプログラムのなかで、どうやると違和感なく理解できる、使いやすいインタフェースになるかを考え、試し、うまい抽象化の方法を見つけるしかない。

何をまとめて何をまとめないべきかはここでは考えないこととする ↩
ここまで書いてみて思ったが、実際のところ何が違うのかは建築物や機械製品に詳しくないのでわからないな、という気持ちになった。ソフトウェアも、サブルーチンの実体は定義が一つだが、その呼び出しは多数の箇所で記述される。非ソフトウェアのコンポーネント自体の設計図が一つで、そのコンポーネントの利用箇所が多数ある、という構造と何が違うのだろうか？わからなくなってきた。 ↩

エンジニアのためのマネジメントキャリアパスを読む

Mon, 10 Jul 2023 23:50:38 GMT

書籍「エンジニアのためのマネジメントキャリアパス」(Camille Fournier著、武舎広幸、武舎るみ訳、及川卓也まえがき、オライリージャパン発行)を読んだ。

私は一介のジュニアエンジニアで、今はシニアと呼ばれるような能力を身につけることを目指しており、マネジメントのキャリアを主軸に考えているわけではない。ただ、組織に対する視座や解像度が低いと感じることがあり、将来マネジメントのキャリアを拒んでいるわけではないので、気になってこの本を読んでみた。

この本は、いちメンバーから上級のマネジメント職位に、順を追って話が進む。最初は自分自身が管理される側としてどのようにあるべきか、インターンのメンターに関する話題が取り扱われているので、自分のようなものも読んで得るものがあった。後半の高い職位に関する説明は「そういうふうにやっているのね」というのを俯瞰して流し読みしたという感じで、すぐに自分の知識として生かせるようなものではないが、解像度を読む前よりも多少高めるのに役だったと思う。

これ以降は、本を読んで気になったところを、フレーズと共にいくつかピックアップして紹介する。

部下としての心得

第1章「マネジメントの基本」のなかで、マネジメントをするまえに、マネジメントをどうされるべきか、どのような立ち振る舞いが部下に求められているか/マネジメントがしやすいものかが説明されている。

上司に求めることの第1ですが、それは「1対1で行うミーティング(以下「1-1」」です。 p2

上司に求めることの第2は「フィードバックの提供」です。 p4

自分自身が何を望んでいるのか、何を学びたいのか、何が自分を幸せにするのかを考え抜いて明らかにする責任はひとえにあなた自身が負っているのです。 p9

似たような話はあとがきにも書かれている。

人の管理がうまくなりたければ、自分自身を管理できるようにならなければならない。 p279

本を読んだ中で、説明されている職位と自分の職位が最も一致する章だと思うが、自分自身が上長とどのようにやっていくべきかというのを改めて振り返る機会になった。1on1を、自分と上長の双方のより有意義なものにしていくために、自分が望んでいることを明確にし、そのために必要なことと現状を照らし合わせてフィードバックを得たり、それらを考えるための補助を求める、という行為をあらためて整理してやっていきたい。

メンターとしての傾聴

第2章「メンタリング」では、インターンやメンターのメンターとしての務めが書かれている。特に、メンターには傾聴が求められているとして、そのうえで以下のように触れられている。

「傾聴」とは、指導相手が「口にする言葉だけを耳でとらえる行為」ではないこと。 p17

メンターとしての役割を果たす時は(もっと言うと実際それに限らず人とコミュニケーションするときは)、メンティーの些細なしぐさや表情も含めて、相手が何をどのように考えているかを汲み取ってコミュニケーションしていく必要がある。

上記の点を含め、メンターとしてどういうことが求められているかが文章としていくつかの項目で示されていることはとてもありがたい。自分がサポートを受ける立場のときどうであったか、自分がサポートをしたときどうであったか、これからサポートのための準備やサポートをしていく上でどうするべきであるか、というのを見つめ直すことができる。

テックリードに求められるプロジェクト管理のスキル

第3章「テックリード」では、エンジニアチームの技術上のリーダーとしてどのように立ち振る舞うかが説明されている。そのなかの一つの「プロジェクトの管理」についての説明は以下のようなものだ。

プロれジェクト管理に必須である「プロジェクトを分割する作業」には、システムを設計する作業との類似点が多々あるため、プロジェクト管理のスキルを習得するという経験は、人的管理を任されることを望んでいないエンジニアにとっても有意義であるはずです。p38

テックリードが最優先しなければならないのは「プロジェクトを推進するための大局的な視点を失わないこと」です。p41

テックリードの果たすべきプロジェクトプランナーとしての役割は「作業をデリバリ可能な単位におおまかに分割する」というものです。p42

企業としてソフトウェアを開発していくには、長いプロジェクトを俯瞰して、ある程度の進め方やスケジュールの算段が必要になる。

普段の開発は、アジャイルやスクラムの枠組みの中で、設計し、作業を見積もり可能な粒度に分割し、見積もって、優先順位順に並べ替え、ベロシティを元にして、現時点でどれくらいかかるかなどがわかるように仕事を進める。

とはいっても、そういう見積もりがすぐにはできないような先の見通しづらいプロジェクトや、年単位のプロジェクトの計画や管理、まだやるとは確実には決まっていない粒度の大きいプロジェクトの検討材料を集めるなどの仕事も必要で、それらは「見積もり」してやるわけにはいかない。

テックリードといわれる職位の人が、そういったことに直面し、それをうまくやる術を仕事の中で身につけていっているということが説明されており、なるほどという気持ちになった。(つまり実際の方法は、本の中には書いていない。本の中で書き切れるような単純なものではないかもしれないのだろう。)

文化の構築

このの最後の章は「文化の構築」となっていて、この章も気になった。文化を形作る上で、意思決定のプロセスから個人的要素を排除するための具体的な方法に、ポストモーテムやアーキテクチャレビューを挙げており、それらを実践する上でのアドバイスが示されていた。

事後検証の成果は、現実的な視点で取捨選択する p276

問題が起きた時のポストモーテムに対する実践的なアドバイスの一つに、上記の事柄が紹介されている。起こった問題を完璧に解消できればいいが、現実にはそんなに暇ではないし、解決策が無限に時間のかかるような非現実的なものであれば形骸化してしまう。ポストモーテムが血の通ったものとなるために、現実的な視点で、効果的な次のアクションを定めていく必要がある。

アーキテクチャレビューの価値は、その準備段階にある p277

言語やフレームワークストレージシステムやデベロッパーツールなど、システムやツールの大きな変更に対して行うべき「アーキテクチャレビュー」の実施方針のアドバイスとして、準備段階の重要性が求められている。アーキテクチャレビューに限らず、誰かに説明して納得してもらうために、それを言語化して資料にまとめることは、その行為自体が自身のセルフレビューの一つになりうるし、準備段階が重要であることは納得がいく。

ポストモーテムやアーキテクチャレビューに関する説明を読むことが、自分の会社の類似の事柄について、自分が取り組む上での実践的なコツのほかに、それらが企業においてどのような立ち位置でどうして重要とされているのか、そのしくみが用意されているのかを考えることのヒントとなった。

以上。

dotfiles管理の推しツール「yadm」の記事を寄稿しました (Software Design 連載最終回)

Fri, 16 Jun 2023 01:45:00 GMT

yadm の紹介記事を、本日発売のSoftware Design 2023年7月号に書きました。昨年12月から続けている連載「開発環境探究の道」の最終回として、dotfilesの管理をより便利にするための方法を説明しています。

yadmについて / 記事の紹介

yadmは、シェルスクリプトで実装されたdotfiles管理ツールです。可搬性に優れ、dotfiles管理に必要な多数の機能と、gitに準じたコマンド操作体系をもっています。私も普段からyadmを使っており、容易に導入できて、とても気に入っている¹ものであり、ぜひみなさんに知っていただきたいと思って記事にしました。

記事の中では、yadmの概要と使い始める方法以外に、管理対象のファイルをより柔軟にする、sparse-checkoutとの組み合わせの例も紹介しています。 dotfiles管理にこれから入門する人も、dotfiles管理を普段から別の方法でしている人も、ぜひこれを読んでyadmを試していただけると幸いです。

連載について

7ヶ月間にわたる連載²も、今月が最終回です。初めての技術雑誌の連載を無事終えられたのは、たくさんの方々に支えていただいたおかげでした。全ての記事を毎月レビューしてくださったpyamaさんと、編集を担当してくださった西原さんをはじめとするSoftware Design編集部の方々には大変お世話になりました。また、連載開始時に相談にのってくださったkenchanくんさん³にもお世話になりました。

そして、読者の感想の投稿や、Web上での言及をしてくださった方、記事を読んでくださった皆様がいるからこそ、続けることができました。本当にありがとうございました。

連載は、開発環境を中心に、以下の内容を扱いました。開発環境という言葉はひろく、人によって指す範囲が異なるため、連載では「LinuxやUNIXにおける、ソフトウェア開発をはじめとするテキストベースのファイル編集やターミナルでのコマンド実行の環境」を指すこととしています。

回	号	タイトル	内容
第1回	2023年1月号	dotfilesを管理して、再現可能な開発環境を作る	Gitとシンボリックリンクを用いたdotfilesの管理構成、設定ファイルの分割と分岐
第2回	2023年2月号	シェルをカスタマイズする	シェルの文法、bashとzshの設定ファイルのカスタマイズ(エイリアス、シェル関数、プロンプト、フィルターコマンドの活用)
第3回	2023年3月号	ターミナルをカスタマイズする	ターミナルエミュレータAlacritty、ターミナルマルチプレクサtmux
第4回	2023年4月号	環境構築を自動化する	設定の自動化とパッケージのインストールの自動化を行うシェルスクリプトの実装
第5回	2023年5月号	テキストエディタをカスタマイズする	VSCodeとVimの、基本操作と設定変更
第6回	2023年6月号	拡張機能やプラグインを使う	VSCodeとVim、zsh, tmuxの拡張機能やプラグイン、Language Serverによる開発支援
第7回	2023年7月号	dotfilesの管理を発展させる	dotfiles管理ツールのyadmと、その活用方法

初回にdotfilesの説明をし、その上で、周辺のトピックへ広がるよう、進んでいきます。一方で、各号はそれぞれ独立しており、どれかの号だけでも読めるように書いています。気になるものがあれば、ぜひお読みください。(記事を読んだよ！という声を聞くと、さらに嬉しいです。)

開発環境の探究はひろく深く、今回は扱わなかったツールや、私の知らないツールやHowToもたくさんあることと思います。ぜひみなさんがよいツールや方法を見つけたりつくったときは、ブログ、登壇やLT、記事、Twitter、他の人との会話、どんな手段でもそれを広げて共有いただけると嬉しいです。私はそのような話が大好きですし、きっと好きな方がたくさんいる話題です。

おわりに

Software Design 2023年7月号は、私の記事以外にも、第一特集のgRPCで始めるWeb API開発や、第二特集のSvelteの話など、たくさんの技術情報が詰まっています。全国の書店もしくはWebで、ぜひお買い求めください。

シンボリックリンクを使った管理の抱える問題を解消できる点などが魅力的で使い始めました。連載の中でも今回の内容が一番書きたかったもので、yadmの良さが伝われば幸いです。 ↩
準備なども含めると、企画が始動してから10ヶ月くらい経っています ↩
今回の連載に繋がった、2022年6月号の特集記事のレビューでもお世話になりました。また、yadmはそのレビューの時にくんさんから教えていただいて使い始めたもので、今回の記事につながっています。 ↩

LlamaIndexを使って、gawkプログラミングの相棒を作る

Tue, 13 Jun 2023 05:10:00 GMT

LlamaIndexを使って手を動かしてみようということで、gawkプログラマーが使える、質問回答アプリケーションを作ってみた。

gawk-rubber-duck

LlamaIndexとは

LlamaIndexという、LLMアプリケーションのためのフレームワークがある。 Pythonで書かれたプログラムで、内部でOpenAI APIを実行するが、その前後の処理なども行ってくれるものである。

LlamaIndexがどのようなものかの説明は、次の記事がわかりやすい。

Llamaindex を用いた社内文書の ChatGPT QA ツールをチューニングする - GMOインターネットグループグループ研究開発本部（次世代システム研究室）

記事の中程の、LlamaIndex 処理フローに丁寧に書いてある。主に以下のことをやっているようである。

事前に与えられた知識となる文章を適切に分割し、embeddingでベクトル化しておく
質問文をembeddingし、ベクトルの類似性を元に、関連の文章を取り出して、LLMに一緒に渡す。

LlamaIndexを使うと、モデルが学習済みで無い、かつ、一度に与えられる上限を超えた沢山の文章をベースに、文章生成ができる。

公式ドキュメントにチュートリアルが用意されているので、それを動かして雰囲気を掴んだ。

gawk-rubber-duck

LlamaIndexをつかってみたいということで、一つアプリケーションを作ってみた。

最近趣味でgawkのコードを書いているのだが、そのとき、gawkの公式マニュアルである、The GNU Awk User's Guideをよく参考にしている。このマニュアルは分量がそこそこある英語の文章で、これをLlama-Indexと組み合わせて、gawkに特化した文章生成ができたら面白いのでは無いかと思ったのが、発想のはじまり。

ラバーダック・デバッグという言葉があるように、プログラマーの相棒といえばアヒルだろう。今回は賢いアヒルを用意したつもりでgawk rubber duckと名付け、gawkの質問に答えるWebアプリケーションとして作成/公開した。

作り方

以下、どのように作ったかを記録しておく。

インデックスの作成

まず、事前準備として、gawkの章ごとに分割されているHTML版のマニュアルをダウンロードし、HTMLタグを取り除いてプレーンテキストにする。(プレーンテキスト版も配布されてはいるが、全セクションが1つにまとまったファイルなので、意味のある単位で最初から分割されているHTML版のものを使った)

次に、これをLlamaIndexに渡すと、入力が一定の粒度に分割され、それぞれがembeddingによってベクトル化された上で、JSONファイルとして出力される。

gawk-rubber-duck/pipeline/save.py at main · yammerjp/gawk-rubber-duck · GitHub

なお、多数の文章をOpenAI APIに渡すので、事前に金額感をつかむために、tiktokenというライブラリを使って、トークンの消費量を計算してから行った。

gawk-rubber-duck/pipeline/guess-token.py at main · yammerjp/gawk-rubber-duck · GitHub

JSONに保存された文章やベクトルを元に、回答生成するのも数行でかける。

gawk-rubber-duck/pipeline/query.py at main · yammerjp/gawk-rubber-duck · GitHub

Webアプリケーションにする

Flaskを使って、HTTPリクエストを受け付けるようにする。

gawk-rubber-duck/web/main.py at main · yammerjp/gawk-rubber-duck · GitHub

リクエストごとにOpenAI APIを実行するので、IPアドレスベースのレートリミットを導入した。Flask-Limiterと、記憶領域には、無料枠のあるMongoDB Atlasを、パスワード認証で使っている。

できたアプリケーションはDockerでまとめて、Cloud Runに載せた。OpenAI API Keyと、MongoDBへの接続情報は、シークレットマネージャで環境変数から差し込んでいる。

gawk-rubber-duck/web/Dockerfile at main · yammerjp/gawk-rubber-duck · GitHub

感想

実際のところ、今回のアプリケーションはひとまず作って公開してみた、という程度で、どこまで実用かはまだ未知数。

LlamaIndexを使って試してみる、というのはそれこそPythonのプログラムを10行程度書けばできてしまった。入力を分割したり、ベクトル検索したりという部分も含めて何もしなくてもいいので、とりあえず試してみる、というのがとてもやりやすい。

求めていた回答が出ているかといわれると、ちょっと微妙で、今回でいえば以下がみえている課題

適切な文章を探せるか
LlamaIndexは、与えた文章を、最初にベクトル検索で絞り込むので、そのときに目的のものが絞り込めなければ、良い結果が出ないようである。例えば入力を日本語で与えると、そのままembeddingしても関係のある文章を引っ張って来れないようで(ここ間違っていたら指摘してください)、英語に翻訳してからLlamaIndexに渡すようにしてみたりしている。
文章から知見を抽出できるか
今回入力に与えたThe GNU Awk User's Guideはおそらく昔からネット上に公開されているもので、言語モデル自体がこの情報を学習していると思われる。なので、LlamaIndexで情報を与えずとも、元々多少なりとも回答してくれるので、今回の方法が効果的かは疑問がある。
品質の評価ができるか
上記を含め、作ったものや仕組みがどれくらい実用に耐えうるか、方式を変えると改善しうるかというのは、評価する必要があるが、こういった具体的なユースケースにおいてどのように評価すればいいのかがわかっていない。作ってみたが、いまのところは作ってみて終わり、となっている。

というわけで、以上、今回は作ってみたという記事。実用的はどうかは疑問があるが、デプロイまでできると一区切りした感があっていい。

awkで実装するUnion-Findと、ABC177 D

Mon, 05 Jun 2023 17:15:00 GMT

最近、業務時間後のオフィスで「競プロもくもくわいわい会」というのをやっている。そこで@purple_jwlさんよりUnion-Findを教えていただいたので、それをawkで実装して、ABC177のD問題を解いてみる。

Union-Findとは

ここでは深く解説しないが、Union-Findについては、以下のサイトなどが参考になる。

Union-Find とは - アルゴ式

Union-Find はグループ分けを効率的に管理する、根付き木を用いたデータ構造です。 Union-Find を用いると、次の各クエリ(要求)を高速に処理できます。

N 個の要素 0,1,⋯,N−1 があり、初期状態ではそれぞれ異なるグループに属しています。各クエリでは次のどちらかの操作を行います。

issame(x,y) : 要素 x,y が同じグループに属するかを調べる。

unite(x,y) : 要素 x を含むグループと要素 y を含むグループとを併合する。

複数のグループを統合して1つのグループにする操作(上記のunite)と、複数の要素が同じ要素に属しているかを確認する操作(上記のissame)ができるもので、これを使うことで、グループ分けの問題を解くことができる。ABCだとD問題などで出てくるらしい。

Union-Findのawk実装

これを、awkで実装すると以下のようになる。¹

# Union-Findの内部のデータ構造は、各グループごとの木構造である
# ある根を他の根の子にすることがUnion、ある頂点の根を求めることがFindにあたる。
# Findした結果が同じ頂点なら、同じ木に属するとわかる

# グラフは、次の変数に保持する
# - uf_parent[x] ... 値xの親となる値
# - uf_size[x] ... xが根のとき、その木の頂点数

# 新しい頂点を登録。辺はなく、自身が根になる
function uf_add(x) {
  uf_parent[x] = x
  uf_size[x] = 1
}

# uf_parentを再帰的にたどり、rootの値を返す
function uf_root(x) {
  if (uf_parent[x] == x) {
    # 根
    return x
  }
  # 再帰的に辿りながら、木の深さが浅くなるように辺を付け替えて高速化 (パス圧縮)
  return uf_parent[x] = uf_root(uf_parent[x])
}
 
# xとyを同じ木に統合する
function uf_unite(x, y,        rootX, rootY) {
  rootX = uf_root(x)
  rootY = uf_root(y)
  if (rootX == rootY) {
    # 既に同じ木ならば、何もしない
    return 0
  }
  # 片方の根を、もう片方の根の子にする
  #   木の深さが浅くなるよう、深い木の根の子として、浅い木の根を生やすことで高速化 (ランク結合)
  #     ここでは、ランクではなく木に含まれる頂点数を測って深さの代わりとしているが、
  #     これで本当に高速化されるのかは定かではない
  #     次のページなどが参考になるかもしれない
  #     ref: https://37zigen.com/union-find-complexity-1/
  if (uf_size[rootX] > uf_size[rootY]) {
    # rootXを根とする
    uf_parent[rootY] = rootX
    uf_size[rootX] += uf_size[rootY]
  } else {
    # rootYを根とする
    uf_parent[rootX] = rootY
    uf_size[rootY] += uf_size[rootX]
  }
  return 1
}

Union-Findのawk実装を実行してみる

この実装の挙動は、以下のBEGIN句を動かすと想像しやすいだろう。

# 先ほどのUnion-Findの実装は同じなので省略
BEGIN {
  uf_add(1)
  uf_add(2)
  uf_add(3)
  uf_add(4)
  uf_add(5)
  uf_add(6)

  uf_unite(1,2)
  uf_unite(3,4)
  uf_unite(4,5)

  printf "uf_parent[1]: %d\n", uf_parent[1]
  printf "uf_parent[2]: %d\n", uf_parent[2]
  printf "uf_parent[3]: %d\n", uf_parent[3]
  printf "uf_parent[4]: %d\n", uf_parent[4]
  printf "uf_parent[5]: %d\n", uf_parent[5]
  printf "uf_parent[6]: %d\n", uf_parent[6]
  printf "\n"

  printf "uf_root(1): %d\n", uf_root(1)
  printf "uf_root(2): %d\n", uf_root(2)
  printf "uf_root(3): %d\n", uf_root(3)
  printf "uf_root(4): %d\n", uf_root(4)
  printf "uf_root(5): %d\n", uf_root(5)
  printf "uf_root(6): %d\n", uf_root(6)
}

実行結果は以下のようになる

uf_parent[1]: 2
uf_parent[2]: 2
uf_parent[3]: 4
uf_parent[4]: 4
uf_parent[5]: 4
uf_parent[6]: 6

uf_root(1): 2
uf_root(2): 2
uf_root(3): 4
uf_root(4): 4
uf_root(5): 4
uf_root(6): 6

この時の木構造は以下のようになっている。

1; 4-->3; 4-->5; 6;">

ABC177 D問題を解く

D - Friends - Atcoder Beginner Contest 177

Union-Findの練習問題としてお勧めされた問題。問題文中のグループではなく、友達関係を辺としてUnion-Findに落とし込み、木ごとの頂点数の最大値が答えになる。

# 先ほどのUnion-Findの実装は同じなので省略

NR==1 {
  N=$1
  for (i=1; i<=N; i++) {
    uf_add(i)
  }
}

NR>1 {
  uf_unite($1, $2)
}
 
END {
  max = 0
  for (i in uf_size) {
    if (max < uf_size[i]) {
      max = uf_size[i]
    }
  }
  print max
}

というわけで、awkでもD問題が解けることが示されてしまいました。言語ではなく、解く人の能力が求められる、ということですね (頑張りましょうという自分へのメッセージ)。

ここではuf_parentとuf_sizeという配列をハードコーディングしているが、これらの代わりにvec["parent"]、vec["size"]などとして、vecを各関数の第一引数に渡せるようにすると、Union-Findのデータ構造を、複数扱えるようになる。 ↩

OpenAI API Embeddingsを使った、関連記事の表示・検索

Sun, 04 Jun 2023 16:35:00 GMT

このブログに、お試しで2つの機能を追加してみた。ひとつは、関連記事の表示。もう1つは、検索。どちらもOpenAI API Embeddingsを使って、記事の文章をベクトル化し、Pineconeを使ってベクトルの類似度の近しいものを得ている。

以下は、これをどのようにして作ったか、どのようにして動いているのかを説明する。

構成

作ったものの全体像は以下の図のとおり。

以下のようなことをやっている。出てくる要素は、「要素技術とロール」の項で後述する。

STEP1: インデックス作成すべての記事に対して、それぞれ、記事全文をOpenAI API Embediingsに渡してベクトル化し、それをPineconeに登録する
STEP2: 関連記事の探索ある記事のベクトルをPineconeに渡し、それと類似度の高いベクトルを得る。そのベクトルの表す記事を、関連記事としてページ生成時に埋め込む。
STEP3: キーワード検索ユーザが検索したキーワードは、CloudFlare Workersが受け取り、OpenAI API Embeddingsでベクトル化してから、Pineconeに渡して類似度の高いベクトルを得る。そのベクトルの表す記事を、検索結果として表示する。

要素技術とロール

作ったといっても、次の2つのサービスのAPIを叩いているだけである。

OpenAI API Embedding
Pinecone API

これらへ、以下の2つの箇所からHTTPリクエストを発行している。

CloudFlare Workers
手元のPC (Macbook)

OpenAI API Embeddings

OpenAI API Embeddingsの使い方は簡単。例えば「今日はいい天気です」をベクトル化するならば、以下のようになる。

$ export OPENAI_API_KEY=ここにAPIキーを入れる
$ curl https://api.openai.com/v1/embeddings \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "input": "今日はいい天気です",
    "model": "text-embedding-ada-002"
  }'
{
  "data": [
    {
      "embedding": [
        0.0011353685,
        0.0045190547,
        -0.0039041303,
        ...1536次元の実数のベクトルが出力される。長いので省略
      ],
      "object": "embedding",
      "index": 0
    }
  ],
  "object": "list",
  "model": "text-embedding-ada-002-v2",
  "usage": {
    "prompt_tokens": 8,
    "total_tokens": 8
  }
}

あとは、ここで得られたベクトル同士の類似度を計算して、近しいものほど、より関連があるとして出力すればよい。

Pinecone API

類似したベクトルを探すのは、今回の例であれば総当たりで計算しても良いが¹、マネージドサービスを使うことにする。最初にみたのはGoogle CloudのVetex AI Matching Engineだったが、個人で小規模に使うには高いので、無料枠のあるPineconeを使うことにした。

まずIndexを1つ作る。次に、記事ごとのID (今回はURL末尾。この記事でいえばembedding-and-vector-similarity-matching)をキーにして、先ほど得たベクトルを登録していく。すべて登録すると、関連記事や検索結果を得る準備が整う。

関連記事を得るには、ある記事のベクトルをPineconeに渡して、類似のベクトル(とそれに紐づく記事ID)を得れば良い。キーワードや文章による検索は、文字列を予めOpenAI API Embeddingに通してベクトル化してから、類似のベクトル(と記事ID)を得ればよい。

CloudFlare Workers

検索ページ https://memo.yammer.jp/search から受けた検索クエリを元に、OpenAI API EmbeddingsとPineconeへリクエストを発行するのに使っている。このブログはNext.jsを使っているが、SSGなので、APIキーを隠すためになんらかのバックエンドが必要だった。

ブラウザから実行される公開されたエンドポイントなので、IPアドレスベースのRate Limitを実装した。CloudFlare KVベースの実装を説明したブログ記事があったので、これをそのまま真似た。作ったものの中身はGitHubにある。(yammerjp/memo-yammer-jp-similarity-matching)

OpenAI APIもPinconeもNode.js用のクライアントライブラリがあるが、CloudFlare Workers内ではFetch APIを直接使ってリクエストを発行している。余談だが、curlの実行例をChatGPTに渡したらFetch APIの実装をやってくれて便利だった。

手元のPC (Macbook)

現在は、以下の2つのことを手元のMacbookでやっている。継続的に使うようならGitHub Actionsに載せる予定。

記事の内容をベクトル化 (bin/embedding.js)してPineconeに登録する (bin/genIndex.js)
関連記事を得る (bin/queryRelatedArticles.js)

上記の2つは、すべての記事に対して処理を実行するスクリプトになっている。本当はすべての記事に対してやる必要はなく、差分更新すればいいのだが、Gitで記事管理しているSSGのサイトは、差分更新と相性が悪いので、どのようにやるか考えあぐねている。Pinecone以外に何らかのデータストアが外部に欲しい。

おわりに

便利なものが揃っていて、それらを繋ぎ込むだけで割と簡単に作れてしまった。

関連記事は、記事によっては²、結構いい結果が出ているようにみえる。検索も、まあまあいい感じではある。ただ、検索ワードを検索欄に自分で入力するUIは、単語ベースの完全一致の検索を想起するので「記事のどこかに検索ワードが出てくるのではないか」「だとしたらどこに出てくるのか」などが気になってしまう。何か他のものと組み合わせるのがよいのかもしれない。

同様のことをやっている@kisさんの先行事例では、Javaで内積を計算する処理を自前で書いているようです。 GPTのEmbeddingを使った近いエントリを探す処理がVector APIなどで10倍高速になった - きしだのHatena ↩
この記事の関連記事は微妙だが、これはそもそもあんまり似た記事を過去に書いていなかったのだと思う。 ↩

rtxはじめました

Tue, 30 May 2023 17:00:00 GMT

ランタイム管理ツールasdfと互換性のある、rtxを使い始めた。

asdfのプラグインエコシステムに乗っかっていて、できることはasdfと基本的には同じのようだが、はやい¹などのメリットがある(後述)。

切り替え

切り替えは以下のような手順で進めた。dotfilesの差分はこんな感じ yammerjp/dotfiles 6a6951c。

シェルの設定ファイル(.zshrcなど)に書かれているasdfの読み込みをやめる

私の場合はsheldonのプラグインにしていたので、~/.config/sheldon/plugins.tomlの記述をひとまずコメントアウトした。

rtxをいれる

Apple SiliconのmacOSを使っていたら以下のような感じ。

$ curl https://rtx.pub/rtx-latest-macos-arm64 > ~/.local/bin/rtx
$ chmod u+x ~/.local/bin/rtx
# ~/.local/bin/はPATHが通っている前提

rtxの読み込みをシェルの設定ファイルに書く

複数端末で同じシェルの設定を書いているので、rtxをインストールしている端末だけに反映させたい。以下のような内容を.zshrcに追記

if (which rtx > /dev/null); then
  eval "$(rtx activate zsh)"
fi

rtxの設定ファイルを配置

~/.config/rtx/config.tomlに、以下のような内容のファイルを置く

[tools]
awscli = ['latest']
go = ['latest']
# heroku-cli = ['latest']
nodejs = ['latest', 'lts']
ruby = ['latest', '2.7.8']
php = ['latest', '7.4.33']
terraform = ['latest', '1.0.5', '1.3.1', '1.3.3', '1.3.4', '1.3.6', '1.3.7']
[settings]
jobs = 4
experimental = true

各種ランタイムをインストール

rtx iとすれば、設定ファイルを見て足りないものを全部インストールしてくれるらしい

$ source ~/.zshrc
$ rtx i

いいところ

設定ファイルがXDG Base Directoryに従っている。すっきりしていい。
rtx iとだけ実行すればいいので良いので楽。わかりやすい。
設定ファイルに複数バージョンを記述できる。
インストールが早い。並列で実行してくれる。
シェルの起動時に、設定ファイルにあるのに未インストールのものがあったら警告してくれたりする。

なやみ

rtxに限らないが、他のツールを使うための基盤となるツールが増えていくと、それのセットアップが面倒になるという問題をはらんでいる。rtxはRust製なので、OSとCPUに合わせたバイナリを手に入れなければならない。

shelldonに, rtxに, ... 気をつけていても、だんだん増えていく。asdfはシェルスクリプトでできていて、どの端末でも切り替えなく入れられるのでその点はいいのだけど、rtxはさきに書いたメリットがあるので使っていきたいところ。

妥協案として、dotfilesリポジトリにバイナリをcommitしてしまって、yadmのalternate filesで環境ごとに実行ファイルを切り替えつつ使う、みたいにすると楽なのかもしれないとも思った。私の用途ではarm64のDariwin、x86_64のLinux、arm64のLinuxがあれば十分なはず。

この場合、バージョンが上がるごとに違うバイナリをcommitすることになるので、dotfilesリポジトリの容量が増えてセットアップ時のダウンロード容量が増えるけど、そこはshallow cloneするなりしていくといい、のだろうか？...。長期的には微妙だろう。

セットアップ用のシェルスクリプトを育ててもいいが、環境や状況によって必要なものの最低ラインが変わるので、区分けやセットアップ手順が煩雑になっていく。なるべくシンプルに、でも便利にするラインのせめぎ合いである。手動でbrew installなりcurl > なりを、コマンド一つ打てばいいというのはその通りなんですが、開発環境の構築はそれの積み重ねなんですね〜

最後はrtxにあんまり関係ない話を書いてしまったが、なにはともあれrtxはいまのところ(まだ1日目)快適に使えている、もっとはやく入れればよかった。

この記事に書かれている「はやい」「早い」はすべて体感です ↩

エンジニアのためのドキュメントライティングを少し読む

Fri, 21 Apr 2023 00:55:17 GMT

前回に引き続き、全部読まない読書の感想とメモを書いていく。前回記事では1週間で読み切るといいつつ、気づけば2週間経っていることには一旦目を瞑りたい。

2冊目は「エンジニアのためのドキュメントライティング」。

ユーザの問題解決とプロダクトの成功を導くエンジニアのためのドキュメントライティング - Amazon

一週間読書の方法

本の感想に入る前に、どのように一週間読書をやっているかを紹介する。なお、ここで扱う書籍は技術書を中心としたもので、小説などは当てはまらない。

目次から読むところを選ぶ

全部読むことが目的ではなく、短い時間で読みたいところを読むのが目的である。そこで、最初から読み始めないようにしている。ついつい最初から読み始めてしまい、読み切るまでなかなか次の本にいけなくなることを避けるのが狙いである。

目次のページをざっと眺めて、いくつか章を決めて書き留めておく。そして、決めた章のページに飛んで、そこから読み始める。この時、必ずしも数字の若い章から読み始める必要はなくて、読めそうなら一番読みたいところからどこでも読み始めて良い。

最初に決めた章を読み切るか、読むのに一定時間が経ったら(ここで言えば1週間)、その本は完全理解()したとして終わりにし、次の本にいく。

今回でいえば、3, 6, 9章を中心に読んだ。

まとめを活用する

途中の章から読むといっても、前後の文脈がないと難しいときもある。そういう時は、他の章の末尾にある「まとめ」だけを読む。数ツイート分くらいの分量でまとめてくれているので、他の章を読むための概要と文脈が把握できて、読み進めやすくなる。

ここでまとめを読むのはあくまで次の章を読むためで、その章の知識を吸収することはまとめでだけでは大抵難しいことには気をつけておきたい。

メモをとって、感想をまとめる

必須ではないが、感想や学んだことをまとめておきたいので、読みながらページと気になったフレーズをメモしておく(付箋でもよさそう)。読み終わったら、このブログ記事のようにまとめる。

必須にしてしまうと、読むスピードを落としたり、読む障壁になったりするので、メモや感想は必須とはしない。

読みながら感想を書くのも、読む速度を律速してしまうので、単語や1文くらいに留める。一週間後には読み終えるので、その場で丁寧にメモしなくても思い出せるだろう(思い出せなかったら大事ではないだろう)とする。

このような方法で読んでいる。他の方がどのように読書しているかも知りたいので、ぜひアンサーブログで教えていただけると嬉しい。

以降は実際に読んだ書籍の感想が続く。

書籍「エンジニアのためのドキュメントライティング」の感想

免責

上述の通り、この感想記事は本の全部を読んだわけではありません、適宜読み飛ばしながら読んだ人の感想です。
ドキュメントライティングについて読んだはずなのに、この記事の文章は微妙だな、と思ったら、チラシ裏のブログ記事として見逃してください。

全体を通して

この本は、全体を通して、ドキュメントを書くときの標準的な方法を、最初から最後まで網羅的に説明している本にみえた(斜め読みだが)。自分の行為が言語化されて体系的に示されるというのは大変よい。これを通して、作業を客観的に捉えられるようになるだろう。

普段やっていることは言語化されて再認識できた。逆にあんまり得意でないところは、書かれていることを順番にやることで、ドキュメントライティング力を底上げしてきたい。

白紙からの脱却

白紙を脱してドキュメントを書き始める方法として、以下のような方法が示されている。

これまでに集めた情報をドキュメントの冒頭にリストアップするところから、ドキュメントを作成開始できます。

読み手

目的

コンテンツパターン (p72)

文章を書くとき、白紙の状態から何を書くかまでのアウトラインを決めるところが腰が重い。このフェーズでは「文章を書くぞ」ではなく「リストアップするぞ」と思うことにして、書き始めのハードルを下げるのが大切だと思った。

どんな書き手でも

書き手によらず執筆は難しいものであると、以下のように述べられている。

どんな書き手でも行き詰まります。執筆は創造的で難しい仕事であるため、ときに継続が難しくなりま。行き詰まるのは執筆が下手だからではないのです！アウトライン濁声の最初の段階だったとしても、ドラフトを完成させる途中のどこかであったとしても、行き詰まるのは執筆プロセスの一部です。 (p85)

このあとに続けて、いくつかのTipsが紹介されている。例えば以下のようなものである。

完璧であることを意識せずにとにかく考えを書き出す
TODOコメントを活用し、書きづらいところは飛ばす
冒頭ではなく書きやすいところから書く
メディアを変える (テキストエディタを変えてみたり、ホワイトボードに書き起こしたり、音声文字起こしを試してみたりする)

「どんな書き手でも行き詰まります。」という言葉はとても勇気づけられる。自分自身、文章を書いていてうまく書けずに行き詰まったとき、「自分はあまり執筆が得意でないのかもしれない」と自分の能力の問題にしてしまうことがある。真偽はおいておいて、それは自分が求めているクオリティを一発で導き出そうとしているのが問題なのではないかと思う。

一発で完璧な完成形を作る必要はない。ソフトウェア開発と同様に、少しずつ改善することで文章を仕上げていけば良いという前提で、執筆に向き合っていきたい。同時にそれは時間がかかることであるので、はやく書き始めるのが大事、大事ですね！

そこそこのボリュームのある文章を書くとき、箇条書きや各章のタイトルの一覧みたいなものを作って書き始めるのだけど、文章の肉付きがないまま箇条書きを完璧にしていくのは結構難しくて、結構行ったり来たり (文章を書いてみて、やっぱり箇条書きに戻る) ということがよくある。書いてみないとわからないということもあるので、まずは脳内をとにかく書き出して、納得いかない個々の部分を直していくという作業に落とし込んでやっていきたい。

最初のドラフトを完成させる

記事の下書きとしてひととおりの文章がかけた時に、全体をチェックする方法として、いかのようなものが挙げられている。

完了したかどうか判断するために、次の質問を自分に問いかけてみてください。

大見出しはドキュメントのゴールを要約しているか？

複数の見出しによってドキュメントは十分に要約されているか？

ドラフトは最初から最後まで読み手のニーズに答えているか？

情報の流れは読み手にとって理解しやすいものか？

フリクションログで見つけた課題は解決されているか？

何らかのドキュメントパターンやテンプレートに正しく従っているか？

全手順が動作することをテストし確かめたか？ (p91)

ドラフト段階の記事が書き上がるのはとても大きなマイルストーンである。そこまで来れば自分で読み直したりレビューを貰ったりして個々の箇所を改善してけば、文章が完成できる。

ついつい一通り文章がかけると舞い上がってしまって「できた」という気持ちになってしまう。しかし上に書かれたような項目をチェックリストで用意しておいて、このタイミングで満たされているかを確認しておくことで、次のステップで後戻りを減らせるだろう。とてもよいテクニックに思うので実践していきたい。

おわりに

というわけで、1(2)週間読書の第二回でした。2回目があってよかった。忙しさを理由に気づいたらついつい2週間になっていたが、来週こそは1週間で区切りたい。

レガシーコード改善ガイドを少し読む

Fri, 07 Apr 2023 00:41:21 GMT

1週間だけ読む取り組み

一冊の本を一週間で読めるだけ読むというのをやってみる。買った本は積まれる一方だし、買いたい本のURLもPocketに溜まるばかり。そしていざ本を読み始めると、最初から頑張って全部読みがちである。そういった習慣を変えるために、1週間で読むのをやめて強制的に次の本に行くという方法を試してみる。

一週間やってみて、全然読みきれないと感じた。ゾーンに入ってバーンと読んでしまえば今回の本などは読み切れるのかもしれないが、そうやって気合いを入れるのではなくて、趣味のプログラミングや雑誌の原稿や仕事のキャッチアップなどをする日々に馴染む範囲で日常的にどんどん読んでいきたいので、この取り組みをやり始めるわけである。

書籍に載るような文章を書く手間を考えると、本の作者には適当な読み方をして申し訳ない面もある。しかし世の中には読みきれないほどの本があるし、読まないより読む方がいいだろう。

レガシーコード改善ガイドを少し読んだ感想

今回は一冊目、レガシーコード改善ガイド。本に示されたトピックをいくつか紹介しながら感想を述べる。

https://www.shoeisha.co.jp/book/detail/9784798116839

変更の基本的な流れ

レガシーコードの変更には一連の手順がある。それは次のような手順であると紹介されている。

変更点を洗い出す

テストを書く場所を見つける

依存関係を排除する

テストを書く

変更とリファクタリングを行う

(p21)

既存の振る舞いをテストコードにより保護し、デグレしていないことを保証しつつリファクタリングや変更を加える手順である。普段やっていること/やろうとしていることではある¹が、改めて言語化されて本の前半で整理されていて再確認になった。

検出と分離、接合部と許容点

書籍の中では、「検出」「分離」「接合部」「許容点」という語が定義されている。普段なんとなく「この変数の値を検証したい」「この部分を切り出せば良いのではないか」「ここで分割できるな」「ここでモックすればいいな」などと考えているが、これらに言葉が与えられることの意義は大きい。言葉が与えられることで考えがよりわかりやすく整理されて表現され、脳を占有する思考のメモリ領域が圧縮できる。

検出と分離

コードの計算した値にアクセスできない時に、それを検出するために依存関係を排除する(p25)

コードをテストハーネスに入れて実行することすらできない時、分離するために依存関係を排除する (pp25-26)

例えば長いトランザクションスクリプトでは、一つのメソッドの中のある変数の挙動をテストしたいことがある。そういったもののコード実行時の挙動を"検出"するためにテストコードを書く。テストコードを書くために依存関係を排除しなければならないこともあるだろう。

例えば実装が特定のソフトウェア外部との接続に依存している場合もあるだろう(ネットワーク通信やファイルシステム、ハードウェアなど)。そういった時には、テストのために、偽装オブジェクト/モックオブジェクトを作ってそれらを利用できるようにすることで"分離"する必要がある。

接合部と許容点

接合部(seam)とは、その場所を直接編集しなくても、プログラムの振る舞いを変えることのできる場所である。 (p41)

どの接合部も許容点(enabling point)を持つ。許容点では、どの振る舞いを使うかを決定できる。(p41)

オブジェクト指向²の考えを取り入れた言語では、メソッドをオーバーライドしたり、インタフェースに異なる実装を与えると、コードの字面を一切変えずに挙動を変えることができる。例として、次にPHPのコードを示す。

class Renderer
{
  function render(PrintableDevice $device) {
    $device->print();
  }
}

ここでprint()メソッドがどのように振る舞うかは、$deviceインスタンスが何かによって変わる。ここでprint()メソッドの呼び出しを接合部、renderメソッドの引数による$deviceの引き渡しを許容点とと呼べる。

たとえば外部通信をするような依存を持つコードをテストの中だけで実行しないようにできれば、そのコードをテストできる。依存関係を整理するときは、どこかを接合部や許容点とし、本番環境との振る舞いを変えてロジックをテストするコードを書くことになる。

もうウンザリです。何も改善できません

「もうウンザリです。何も改善できません」は第24章のタイトル。この章は@UVB_76さんにおすすめいただいた箇所で、とてもポエミーで勇気づけられる内容が書かれている。 2ページくらいですぐに読めるし、本の中の文章をそのまま読むからこそ感じられることがあると思うのでぜひ原文を読んでいただきたい。

この章では、プログラムを書くことは本来楽しいことや、レガシーコードを抱えていることに落胆せず、毎日挑戦的に仕事を楽しむ方法を思い出させてくれる。やりがいを見つけ、テストによる保護でひどい状況を制御することで前進できると語ってくれている。現時点で私は落胆しているわけではない³のだけど、それでも勇気づけられたし、落胆しそうになった時にまた読みたい。

次に読みたいところ

テストがかけてしまえば、それにより保護されることで安全に変更を加えることができるだろうが、今の自分には既存のコードを切り分けてテストを書くまでのプラクティスや知識が足りていないところがあると思うので、そういった実践的な部分や内容をより深掘りして読みたい。

終わりに

「次に読みたいところ」に書いたとおり、次の本に行く前にまだまだ読みたいところだけれど、そうやるとダラダラ読んでしまうだろうから、次の本に行こうと思う。最初なのでブログを書くのにも気合が入ってしまった。次からはもう少し肩の力を抜いて、なるべく負荷にならない範囲で記録を残していきたい。

といいつつ、横着して、この本が横にある時に「編集して祈る」をやりそうになり、同僚とそのことを笑っていました。結局テストを書きました。肝に銘じます。(「編集して祈る」は書籍の中でテストを書いてリファクタリングや変更を繰り返す方法と対比され、よくない方法として紹介されている言葉です。) ↩
オブジェクト指向とはなんぞやというのは脇に置いておきます。許してください。 ↩
レガシーという言葉は結構気を使う単語で、私の仕事がレガシーにまみれているような誤解を与えそうなので一応補足を書いておきます。もちろん大きかったり歴史の長いソフトウェアやサービスでは相対的に手が届きづらくなるコンポーネントや巨大化したコンポーネントも扱うけれども、それらが一定コントロールされた/したうえで最新の手法を取り入れつつチャレンジングな仕事ができる環境にいると思っています。 ↩

PHPerKaigi2023が最高だった

Sun, 26 Mar 2023 08:45:00 GMT

昨日のPHPerKaigi2023最終日、自分はLTをしたのですが、登壇以外にもたくさんの体験をして本当に濃い一日でした。

Day1のブログ: PHPerKaigi2023に参加しています - memo.yammer.jp

LTで登壇

LTでペンライトを振るのも振られるのも楽しんだり。登壇した内容は、PHP Conference 2022で出題したクイズの裏話として、当時の問題を振り返りながら、何を考えて作っていたか/作るならどうすべきかでした。

クイズのことを覚えていた方もたくさんいらっしゃったようで、嬉しい限りです。

LTの発表資料です！答えは最後のスライドにて
「クイズを作ってPHPに親しむ」https://t.co/ef8QQPi3we #phperkaigi #a
— やんまー (@yammerjp) March 25, 2023

ランチ

Day1の夜にみたツイートを発端に、初めてお話しするPHPerの方々とランチに行きました。盛り上がっている勢いとコミュニティの暖かさと言い出した人と乗ってきた人、それらが揃って生まれたありがたい時間でした。

#phperkaigi 明日のお昼ご一緒出来るペチパーの方いらっしゃいませんか！(当方初ペチパー会議です)
— たま (@tama_php) March 24, 2023

聞いた発表

今日聞いた発表はこちら。感想は別の記事かフィードバックで書くことにします。

このほか、すこしの時間ですがポスターセッションも読ませていただきました！

カンファレンスの廊下と懇親会

カンファレンスの廊下や懇親会、さらに2次会で、たくさんの人とお話ししました。いや本当にここに書ききれないくらいたくさんの出会いがあって、とても楽しい時間でした。自分から話しかけると、思っているより気さくに話に応じていただいたり、自分のあだ名をみて声をかけていただけることもあって、しょうもない話から本音の話までたくさんおはなしできました。

PHPerKaigiコミュニティと「熱」

PHPerKaigi参加以前、他のイベントに行った時にPHPerKaigiの札をかけている人に憧れを抱いたり、PHPerKaigiの話を熱く語っている人を見て「カンファレンスにここまで熱くなれるのいいなあ」と思っていました。

初めて参加し、その熱のわけを体感しました。「これがPHPerKaigiなのか」ということを強く感じました。そう設計されているからか、コミュニティの人々の方向性からか、その両方からか、「自分が見ているだけ」「聞いているだけ」というのとは全く違った、双方向のコミュニケーションの生まれる、経験したことのない体験でした。

物理的なカンファレンスが、PHPerKaigiが、こんなに濃いものなのかと感じた背景には、21卒でコロナ禍に働き始めたのでオンラインでの体験が当たり前になっていたことも関係しているかもしれません。

精進

技術的には、自分の至らなさを感じる場面が沢山ありました。ただ、至らないと感じれるくらいには目線が広がったとも思えるので、日々精進していくしか無いという気持ちです。中身の伴う質の高いアウトプットをできるように、技術力を高めて仕事や趣味で活かし鍛えていくというのを地道にやっていかねば。

楽しい時間とたくさんの出会いをありがとうございました！ #phperkaigi
— やんまー (@yammerjp) March 25, 2023

PHPerKaigi2023に参加しています

Fri, 24 Mar 2023 14:23:11 GMT

昨日から始まっているPHPerKaigi、昨日はオンライン、今日は物理で参戦しています。

これは、PHPerが増殖していると噂の謎の駅... #phperkaigi pic.twitter.com/uSM1BqewIx
— やんまー (@yammerjp) March 24, 2023

初めてのPHPerKaigiですが、各発表やLTの独特の空気感がとても新鮮で、とても楽しんで参加できました。

PHPer界隈のTwitterでよく見るぞ、という方の話を聞けたり、なんなら物理的に話すなどできて、カンファレンスよいなあという気持ちに浸っています。

聞いたセッションはこちら。それぞれ細かい感想はフィードバックやまた別の記事で書くことにしますが、どれも面白く楽しく聞かせていただきました！

明日はLTに登壇します！今日の盛り上がりに少しビビっている面もありますが、うろたえずにやっていくぞ！もし時間があればぜひ聞きに来てください。

クイズを作ってPHPに親しむ

内容は、PHP Conference2022のPHPクイズの裏話という側面もあります。知らない方も楽しめるように、それを知っている方はもっと楽しめるように作ったつもりです。

それでは会場で、オンラインで、また明日お会いしましょう！ 1日会場にいる予定なので、知っている方も初めてお会いする方もどなた様も話しかけてくれると嬉しいです。

これが噂の… #phperkaigi #a pic.twitter.com/rkX26kAwXe
— やんまー (@yammerjp) March 24, 2023

LT、謎の盛り上がりだったな..

ターミナルをカスタマイズする Software Design連載開発環境探求の道第3回

Fri, 17 Feb 2023 02:20:00 GMT

本日2/17発売の月刊誌 Software Design 2023年3月号に、連載第3回目の記事を寄稿しました。

今回は「ターミナルをカスタマイズする」と題して、Alactirryとtmuxの基本的な使い方を紹介しています。UnixやLinuxの技術者がふれる時間の長いターミナルを使いこなすことで、快適に作業できることを目指す内容です。

ぜひ書店でお買い求めください。

Smart Keyboard Folio を買った(2023年2月)

Wed, 01 Feb 2023 14:43:02 GMT

(2024/09/22記)2023年2月ごろに、Smarty Keyboard Folioを買って、その感想を書いた記事が下書きに残っていたので公開する。最近はあんまり持ち歩いていないんだけど、一時期はだいたいiPadだけを持ち歩いていて、とても気に入って使っていた。dotfilesの連載記事の寄稿も、何割かはiPad + Smarty Keyboard Folioを使ってsshしてVimで書いていたはず。結構快適だった。

iPad Air 4の機動力を上げたくて、Smart Keyboard Folioを買った。

購入の動機

コンパクトな自作キーボードをiPadと一緒に持ち歩いて作業するということはときどき試していた。しかし、どうしてもiPadと分離しているので、ケーブルを接続するのが煩雑だし、膝の上などの不安定な場所では広げづらく、これらの点ではノートパソコンの使い勝手にかなわないと感じていた。¹

これらの課題感を解消する目的で買ったのが、Smart Keyboard Folioである。特にiPad Air4はカメラが1つしかないので、2018年ごろに発売された第一世代のものが使え、定価より安く買えるとのことだった。

いいところ

ケーブルを繋げずに外部キーボードが使える
iPadと磁石で結合しているので、机の上などの安定した箇所でなくてもつかえる
薄い
軽くてコンパクト

iPadと磁石でしっかりくっつくということはとてもよい。他の一般のキーボードにはない利点で、膝の上で使ううえではとても役に立つ。

キーボードが薄いので、パームレストなしで良いところもよい。

キーボード自体が軽くてコンパクトなこともよい。iPadがはいるボディバッグを持っているのだが、これと合わせて出かけるのが楽しみだ。

満足できないところ

キータッチが重い (特にスペースキーが押しづらい)
パームレストが無い
キーボードがたわむ
配列のカスタマイズの幅
ESCキーがない

買ってみたはいいものの、膝の上でのタイピング体験はあまり良くない。一番はキータッチが気に入らない。結構硬いのでしっかり押し込まないと反応しない。特にスペースキーが如実で、押したつもりなのに反応していないこともある。他のキーを押していても指先が疲れる感じがある。

パームレストが無いことも気になる。膝の上にノートパソコンを載せてタイピングしているときは、実はパームレストに手のひらを乗せることでキーボードを固定していた。なので、安定感に欠ける。

さらに、キーボード自体がたわむのも気になる。膝の上に乗せた時の安定感が、やはりノートパソコンに比べて欠けてしまう。

キー配列のなかで、Escキーが無いことも気になるが、これはユースケースが特殊なので仕方がないだろう。iPadには修飾キーをリマップする機能が付いているので、いくらかカバーできるものの、CtrlとEscとShiftとTabキーを押しやすい位置に配置するにはキーやリマップ機能が足りない。これは自作キーボードと比較してしまうとしょうがない部分ではある。

これらのいくらかは事前に展示されている商品を試すなどして薄々わかっていたところではあるが、キーのリマップなどは、US配列とVimで使ってみないとわからないところもあるので、まあこんなもんかなという感じ。

おわりに

いろいろ書いたが、やはり収まりの良さとコンパクト感はすばらしいし、使い心地は慣れれば解決する側面もあると思うので、しばらく持ち歩いて使ってみることとしたい。

自作キーボード自体はとても気に入っています。iPadを不安定な場所で使うというユースケースには、一般に外付けのキーボードは合わないということでした。 ↩

シェルをカスタマイズする Software Design連載開発環境探求の道第2回

Wed, 18 Jan 2023 13:20:00 GMT

本日発売の月刊誌Software Design 2023年2月号に、連載記事の第2回を寄稿しました。

開発環境探求の道

連載「開発環境探求の道」は、UnixやLinux上で、自分好みの開発環境をつくり、探求する道を紹介する連載です。連載の中では、テキストエディタやシェルやターミナルに関するツールを紹介し、インストールからカスタマイズまで、手元で試せるような記事となっています。

シェルをカスタマイズする

第2回「シェルをカスタマイズする」では、bashとzshの設定ファイルを編集するのが主な内容となっています。関連してgitのエイリアス機能やfzfにも触れます。

シェルの設定ファイルを編集したことがない方や、コピペして貼り付けたことはあるが、中に書かれていることが実はよくわかっていないという方をはじめとして、シェルに興味のある方にぜひ読んでいただきたい内容です。

記事の中ではシェルスクリプトの文法も含めて紹介しており、記載した設定例をもとに、自分の環境にあうように設定を自分でカスタマイズする第一歩になればと思って記事を書きました。

おわりに

Software Design 2023年2月号は「開発環境探求の道」以外にも、多数の連載や特集があります。今号の第一特集はドメイン設計に関するもので、第二特集はログに関するものです。

どちらも気になるので、私も読むのを楽しみにしています。ぜひ、お近くの書店またはWebサイトからお買い求めください。

Ubuntu DesktopにAlacrittyをインストールする

Sun, 15 Jan 2023 16:54:41 GMT

Alacrittyは、公式ではLinux向けのバイナリが配布されていないので、どこかから入手するか、自分でビルドする必要があります。

以下では、Ubuntu Desktop 22.04上でビルドし、インストールする方法を紹介します。なお、この記事の内容は2023/01/16時点のものです。また、公式に提供されているインストール用ドキュメントを参考にしています。

簡易的に利用するとき

ビルドされた実行ファイルをPATHの通った場所に配置するのみで良い場合は、こちらの方法を実行します。デスクトップのランチャー上にアイコンを表示したり、マニュアルをインストールした場合は、後述の「本格的に利用する」を参考にしてください。

# Alacrittyのビルドに必要なaptパッケージをインストールする
$ sudo apt-get install cmake pkg-config libfreetype6-dev libfontconfig1-dev libxcb-xfixes0-dev libxkbcommon-dev python3 curl
# https://rustup.rs/ に従い、Rustの開発ツールをインストールする
# 実行するとインストールオプションを選択する画面が現れるので、「1) Proceed with installation (default)」を選択する (1を入力後にエンターを押す)
$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
# cargoコマンドを利用するために、シェルの設定ファイルを再読み込みする
$ source ~/.bashrc
$ cargo install alacritty

完了したら、シェル上でコマンドalacrittyを実行することで、Alacrittyを起動できます。

本格的に利用するとき

マニュアルをインストールしたり、デスクトップのランチャー上にアイコンを表示したい場合は、以下の手順でインストールします。

(必須) ビルド・インストールする

シェル上で以下のコマンドを順番に実行してください。ビルドに必要なツールをインストールし、ソースコードを入手してから、ビルドします。

# Alacrittyのビルドに必要なaptパッケージをインストールする
$ sudo apt-get install cmake pkg-config libfreetype6-dev libfontconfig1-dev libxcb-xfixes0-dev libxkbcommon-dev python3 curl git

# https://rustup.rs/ に従い、Rustの開発ツールをインストールする
#   実行するとインストールオプションを選択する画面が現れるので、1を入力後にEnterキーを押す
#   (「1) Proceed with installation (default)」を選択する)
$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# cargoコマンドを利用するために、シェルの設定ファイルを再読み込みする
$ source ~/.bashrc

# Alacrittyのソースコードを入手する
$ git clone https://github.com/alacritty/alacritty.git ~/alacritty
$ cd ~/alacritty

# バイナリをPATHの通った場所に配置する
$ cp target/release/alacritty /usr/local/bin

/usr/local/binに配置できたら、シェル上でalacrittyコマンドを起動すると、Alacrittyが起動し、ウィンドウが現れることが確認できます

(任意) デスクトップのランチャー上にアイコンを表示する

デスクトップのランチャー上にAlacrittyを表示するには、シェル上で、以下のコマンドを順番に実行してください。

# デスクトップのランチャー上にアイコンを表示し、GUI環境でクリックするだけで起動できるようにする
$ cd ~/alacritty
$ sudo cp extra/logo/alacritty-term.svg /usr/share/pixmaps/Alacritty.svg
$ sudo desktop-file-install extra/linux/Alacritty.desktop
$ sudo update-desktop-database

完了すると、GUIキー (キーボードによっては、WindowsキーやCommandキー) を押下したあと、Alacrittyとタイプすると、Alacrittyのアイコンが表示されます。クリックするとAlacrittyが起動します。

(任意) マニュアルをインストールする

Alacrittyのマニュアルをインストールするには、シェル上で、以下のコマンドを順番に実行してください。

# manコマンドで、Alacrittyのマニュアルを閲覧できるようにする
$ cd ~/alacritty
$ sudo mkdir -p /usr/local/share/man/man1
$ gzip -c extra/alacritty.man | sudo tee /usr/local/share/man/man1/alacritty.1.gz > /dev/null
$ gzip -c extra/alacritty-msg.man | sudo tee /usr/local/share/man/man1/alacritty-msg.1.gz > /dev/null

完了すると、コマンドman alacrittyで、Alacrittyのマニュアルを閲覧できます。

(任意) bash補完を利用可能にする

alacrittyコマンドをbash上で実行するとき、Tabキーで補完をするには、以下のコマンドを順番に実行してください。

# bash上で、alacrittyコマンドの補完をできるようにする
$ mkdir -p ~/.bash_completion
$ cp extra/completions/alacritty.bash ~/.bash_completion/alacritty
$ echo "source ~/.bash_completion/alacritty" >> ~/.bashrc

完了すると、bash上でalacritty と入力した後にTabキーを押すと、補完候補が表示されるようになります。

連載「最強の開発環境探求の道」をSoftware Designではじめます

Fri, 16 Dec 2022 00:50:00 GMT

本日、12月16日(金)発売のSoftware Design 2023年1月号より、表題のとおり「最強の開発環境探求の道」という連載をはじめます。全国の書店やネットで購入いただけますので、よろしければお手にとって読んでいただけると嬉しいです。

連載の内容とねらい

連載では、LinuxやUNIXの環境における、シェル、ターミナル、エディタ、dotfilesなどの使い方やカスタマイズを扱います。これらに興味がある方におすすめです。また、コマンドラインの環境に詳しくない/なんとなく使っているが、これから使いこなせるようになりたい方にも読んでいただきたい内容となっています。

記事の中では実際に試せる設定例も示しますし、その解説も、できる限りあわせて行います。開発環境の目的や用途は十人十色ですので、自分にあったものを構築できるよう、設定の内容を理解していただけるよう努めます。設定をコピペして動かすのももちろんよいのですが、その内容を理解すると、ご自身で応用でき、カスタマイズの幅が広がるでしょう。

1月号から数回にわたって、トピックごとに開発環境の構成要素を説明する形で連載を進めます。初回は、Gitを用いたdotfilesの管理構成の構築です。

LinuxやUnixの開発環境を構築するとき、dotfilesを管理していればカスタマイズがより捗ります。連載の次回以降に扱うカスタマイズも、初回の管理構成のうえで試すことで、Gitによる履歴管理の恩恵に預かれるでしょう。これから設定を書く方も、すでに何らかの設定がある方も、dotfilesをGitで管理して、自分好みの開発環境の探求の道を一緒に歩んでいきましょう。

おわりに

私の連載ももちろん読んでいただきたいですが、ほかにも連載記事が多数収録されています。私自身、前号に続く他の連載記事を読むのが楽しみです。「魅惑の自作シェルの世界」の第2回や「再発見！デスクトップLinux入門」の最終回などを始めとして、じっくり読ませていただきます。

連載だけでなく、特集「アルゴリズムを使いこなしたい」「PostgreSQL 15の最新機能」や、特別付録の仕事猫ステッカー第2弾も魅力的ではありませんか。ぜひお近くの書店で手にとってみてください。

日報インターネット出張公開版

Thu, 15 Dec 2022 01:00:00 GMT

GMOペパボ EC Advent Calendar 2022の14日目は、「日報インターネット出張公開版」です。私やんまーが、12/14の日報を書きます。

13日目はよぴさんの「半分営業半分コンサルみたいな職種からEC業界に転職して感じたこと　〜よぴ的営業マインド語りも添えて〜」でした。記事の中に出てきた「お客さんの理想とサービスでできることの限界の中間地点を一緒に模索する」という表現が印象的で、営業という仕事に対するよぴさんの熱さを感じました！

さて、14日目アドベントカレンダーは、日報についてです。私の勤めるGMOペパボ社内では、書きたい人々が思い思いに日報を書く文化があります。社内のNotionには「みんなの日記」というデータベースがあり、そこに日報や日記が書かれることが多いです。私も、毎日ではありませんが、ときおりNotionに日報を書いています。

日報のフォーマット

私の場合は新卒研修で使っていたフォーマットが馴染んでいるので、そのときの項目を反映した書いたテンプレートを用意しています。テンプレートがあると書き出しが楽になるので助かっています。いまは、各項目の全ては埋めなくとも良いことにして、時間をかけすぎずに書きたいことや伝えたいことにフォーカスしています。

<!-- 日報のテンプレート -->

## いまの気持ち
## やったこと
## わかったこと
## 次にやること

2022/12/14の日報

それではここから日報です。

今の気持ち

物理出社を活かしてたくさんの人と喋った日だったので、皆さんのパワーを感じる日でした！

特に、新卒同期の homirunとの「やっていく会」では、データの整合性に関するアイデアをもらって、今後の実装のイメージが湧いたのでとても有意義な時間でした。「やっていく会」は、最近週次ではじめた取り組みで、homirunと二人で行っている雑談会兼相談会です。事前に議題は決めず、お互いトピックがあればその場に持ち寄る方式で進めています。

我々は、同じサービスを、異なる事業部から、異なる観点で開発運用しています。私はWebアプリケーションエンジニアとして、homirunはSREとして、それぞれの強みの領域や、持つ知見が異なります。チームの垣根を超えてお互いの知見を共有する機会を強制的に作ることで、私はインフラレイヤでわからないところや気になるところを助けてもらったり、逆にhomirunにアプリケーションレイヤの話をしたりしています。

2人で草の根的に始めた取り組みは、お互いに効果が生まれていると感じます。タスクの困りポイントの解消や、懸念の先回りした発見などに役立っています。今後は、この取り組みを少し広げ、他の人も呼ぶなどして、レイヤやチーム、事業部を超えた連携のきっかけとしたいと目論んでいます。

やったこと

参画中のプロジェクトの開発 (コードを書いたり)
参画中のプロジェクトの定例ミーティング
エンジニアの人々とカレー屋さんでランチ
「やっていく会」
隣のチームとテスタブルなコードに関する雑談

これはお昼のカレーです

わかったこと

(省略)

次にやること

(省略)

シャウトアウト

参画中のプロジェクトメンバーの皆さん、いつも話しすぎてしまう私に付き合ってくださったり、仕事を巻き取ってくださったり、とても感謝しています。これからもよろしくお願いします。

「やっていく会」でアイデアをくれたhomirun、感謝です。

ランチをSlackで呼びかけてくださったinowayさん、とても良い時間になりました。ありがとうございます。

ikarugaさんとsymmondsさん、夕方に雑に乗り込んでいったあと、私の触っていないロールの話を聞けたり、テスタブルなコードについて議論できて、勉強になりました。ありがとうございました。

おわりに

こうして振り返ると、出社ならではのコミュニケーションを活かせた一日でした。そして、皆さんに助けられながら、日々仕事が出来ているのだと改めて感じます。

ところで、この記事をGMOペパボで一緒に働きたいと思ったあなた！ GMOペパボでは、新しい仲間を募集しています。募集中の職種や、詳しい社内の環境や制度に関しては GMOペパボ株式会社採用サイトをご覧ください。エンジニア新卒採用に関する情報をまとめたページも公開中です！

以上で、アドベントカレンダー14日目を終わります。一日遅れてしまったことをここでお詫びします。

15日目はしべさんです！

jpro: JavaScriptで書くJSON processor

Fri, 02 Dec 2022 00:18:00 GMT

この記事は、🎅GMOペパボエンジニア Advent Calendar 2022の2日目のものです。

みなさんは、JSON processorを使っていますか？ええ、jqのようなツールのことです。世は大JSON時代、値を抽出したり、変換したりする機会も多いことでしょう。

ところで、jqの抽出クエリやコマンドラインオプション、さらっと書けますか？私はあんまり得意じゃないです。そこで、JavaScriptで書けるJSON processor「jpro」をつくりました。

使ってみる

実際に使ってみましょう。Node.jsとnpmが使える環境ならば、事前のインストールなしに、「npx jpro」で実行できます¹。以下では、私が最近書いた記事のタイトル5つを、JSON Feedから抽出しています。

抽出クエリはJavaScriptで書く

記事タイトルの「JavaSciriptで書く」とは、JSONの抽出・変換クエリをJavaScriptで書けることを指しています。jproの引数に指定する抽出クエリは、次のようなJavaScriptコード片です。

.items.slice(0,5).map(p=>p.title)

与えたコード片は、暗黙に、「output = input」に続くものとして解釈されます。つまり、次のようなコードとして実行されます。

output = input.items.slice(0,5).map(p=>p.title)

ここで出てくる変数inputは、標準入力のJSONをパースしたJavaScript Objectです。変数outputは、標準出力されるJSONのもとになるJavaScript Objectです。 sliceとmapはそれぞれ配列のメソッド、p=>p.titleはアロー関数です。

JavaScriptの文法をそのまま使って「標準入力のうち、itemsキーの値である配列のうち、はじめから5つを取り出し、さらに、titleというキーのみを抽出する」ということが書けます。

JSON以外の入出力もできる

さらに、先ほどのコード片には出てこなかったstdinやstdoutという変数を用いると、JSON以外の入出力も行えます。たとえば以下の例では、JSONではなく、行ごとの文字列を出力しています。

$ curl -s https://rsss.yammer.jp/v0/json_feed \
  | npx jpro ';stdout=input.items.slice(0,5).map(p=>p.title).join("\n")'
Asahi Linuxを使う
Fitbit Charge 5を買った
Python実践機械学習システム100本ノックの準備
印象に残った仕事の話をきく話
HerokuからCloud Run + Litestreamへ移行した

jproのクエリで使える、用意された変数は以下のとおりです。

変数	役割
`input`	標準入力のJSONをパースしたJavaScript Object
`output`	標準出力のJSONに変換されるJavaScript Object
`stdin`	JSONとしてパースする前の標準入力
`stdout`	標準出力される文字列 (`null`と`undefined`以外の値が代入されれば、`output`の代わりに、`stdout`の値が標準出力される)

おわりに

jqはJSONの抽出を主目的にした記法を持ち、jproよりも短いクエリで記述できる場合が多いでしょう。一方、jproはJavaScriptコードをevalするというシンプルなつくり²であり、JavaScriptの文法がそのまま使えます。ちょっと凝ったことをするときも、JavaScriptを知っていれば、比較的簡単に書けることと思います。

コマンドラインでJSONを抽出するとき、記法に悩む必要はありません。やりたいことがすぐにできることは、素早さに繋がり、価値になります。jproが、JSON抽出のひとつの選択肢になれば幸いです。

🎅 / 🎄 GMOペパボエンジニア Advent Calendar 2022

この記事は、🎅GMOペパボエンジニア Advent Calendar 2022の2日目のものでした。今年のペパボエンジニアには🎅(サンタ会場)のほかにも、🎄(ツリー会場)があります。

昨日は、よしこさんの未経験転職したい人へのエッセイ、あつい記事でした。

エンジニアの未経験転職を希望する方へ未経験転職した経験から伝えたいこと｜yoshikouki｜note

明日は、inowayさんの記事です！

【入社エントリー】ペパボカレッジを全力でおすすめしてみる - 脈絡はありません

追記: プログラミングが楽しくなった、アウトプット量が増えた、というところが印象的でした！

iframeでカレンダーを埋め込めるようなので追加してみました

「npm install -g jpro」を実行し、システムにインストールすることもできます。このほうが、コマンドの起動が速いようです。 ↩
jproの実装はいたって単純です。コードはいかなるnpm packageにも依存しておらず、たったの62行、しかもその2/3はヘルプメッセージです。やっていることは主に、先ほど示した4つの変数の準備と、クエリのeval、出力だけです。実装よりも、この記事の執筆の方が時間がかかっています。 ↩

Asahi Linuxを使う

Mon, 14 Nov 2022 16:55:00 GMT

Apple Silicon搭載のPC上でLinuxをブートするという魅力的なプロジェクト、Asahi Linuxを手元のMacBook (2020, M1, 256GB SSD, 16GB Memory) で動かしてみた。

MacBookはハードウェアとしてすごく良く出来ていると思うが、ときどきLinux Desktopだったらもっといいなと感じることもあり、Asahi Linuxのことが気になっていた。現在リリースされているのはα版。一部のハードウェアが動かなかったりするものの、自己責任の範囲で、手軽にデュアルブート環境を構築できる。

感想

FirefoxとAlacrittyが動くことがわかって、ブラウザを開きつつ、一通りコマンドが叩ける環境ができた。普段使いしても趣味用の個人端末であれば、そんなに困らなそう。 M1 MacBookの上でLinuxを動かすというだいぶチャレンジングに見えるプロジェクトだけど、手元の環境は、いまのところとても安定していてびっくりした。気になるところでいうと、現在動かないが使えると嬉しいハードウェアは以下の通り。

スリープ

スリープが現時点で出来ないのは残念。しかし、M1 Macbookの電池持ちが良すぎて、家の中で使う分には画面オフでも十分使えそう。一日外に持ち出したりはまだしていないので、そのときは気になるかもしれない。

DisplayPort on USB Type-C

外部モニタへの出力もできたら嬉しい。しかし、モニタに出力するなら普通のamd64のデスクトップマシンを使えばいいのではと考えれば、なくてもなんとかなる気持ちになる。

スピーカー

スピーカーも動けば嬉しいが、不意にYoutubeを開いたりせずに済むので、実は使えないほうが生産性に寄与すると思うことにする。

ほかにもWebカメラなど動かないものはあるけれど、気になるのは実はこれくらい。結構ふつうに使えてしまってすごいなあという気持ちになっている。

OSのインストール

公式サイトの案内のとおり、curlで得たシェルスクリプトを走らせると、ウィザード形式で順に進む。

https://asahilinux.org/2022/03/asahi-linux-alpha-release/

事前にドキュメントに目を通しておいて、かつウィザードの注意文言に従って進めれば問題なさそうだった。インストールの進め方は以下の動画で紹介されている。

私が試した限りでは、一つだけ詰まりポイントがあった。前半でSSDに新たなパーティションを追加するところがあるのだけど、そこでコケて先に進めなかった。

11-12 22:28 root         ERROR    Process execution failed
Traceback (most recent call last):
  File "/private/tmp/asahi-install/main.py", line 852, in <module>
    InstallerMain().main()
  File "/private/tmp/asahi-install/main.py", line 704, in main
    while self.main_loop():
  File "/private/tmp/asahi-install/main.py", line 824, in main_loop
    return self.action_resize(parts_resizable)
  File "/private/tmp/asahi-install/main.py", line 635, in action_resize
    self.dutil.resizeContainer(target.name, val)
  File "/private/tmp/asahi-install/diskutil.py", line 208, in resizeContainer
    self.action("apfs", "resizeContainer", name, size, verbose=2)
  File "/private/tmp/asahi-install/diskutil.py", line 38, in action
    subprocess.run(["diskutil"] + list(args), check=True)
  File "/private/tmp/asahi-install/Frameworks/Python.framework/Versions/3.9/lib/python3.9/subprocess.py", line 528, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['diskutil', 'apfs', 'resizeContainer', 'disk0s2', '178919571456']' returned non-zero exit status 1.
11-12 22:28 root         INFO     MSG: If you need to file a bug report, please attach the log file:
11-12 22:28 root         INFO     MSG:   /private/tmp/asahi-install/installer.log

調べてみるとこれは結構よくある問題らしく、インストール前にディスクユーティリティからFirst Aidを実行しておくといいらしい。

https://support.apple.com/ja-jp/HT210898

First Aidを実行してから、再度スクリプトを走らせると順調にインストールできた。

初期設定

Arch Linuxをあまり使ったことないので、ちょっと探りながら以下のようなことをやった。なお、ソフトウェアのインストールは、 Arch Linux向けの非公式パッケージであるAURにバイナリが上がっているけどamd64のみ対応、というのがぼちぼちあるみたい。そこらへんは自分でビルドしたりバイナリを手に入れたりすると良さそう。

ホームディレクトリ配下のディレクトリを英名にする

ホームディレクトリ配下に作られるディレクトリ デスクトップ などを Desktop などの英語表記へ変更する。Ubuntuなどもそうだけれど、言語設定を日本語にしたとき、毎度変更していると思う。最初から言語設定で英語を選択しておいても良かったかもしれない。

https://wiki.archlinux.jp/index.php/XDG_%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA

$ LANG=C xdg-user-dirs-update --force
$ mv ~/デスクトップ/* ~/Desktop
$ rmdir ドキュメント デスクトップ 画像 ビデオ テンプレート ダウンロード 公開 音楽

KDEシステム設定を好みのものに

KeyboardのCap LockをCtrlにする。入力デバイス > キーボード > 詳細 > キーボードオプションを設定 > Caps Lock behavior > Make Caps Lock an additional Ctrl

電源ボタンを押すとロックをかける。電源管理 > ボタンイベント設定 > 電源ボタンが押されたとき > スクリーンをロックを選択

yadmをinstallして、dotfilesを初期化

$ sudo pacman -S yadm
# まだSSHキーがないので、httpsでcloneする
$ yadm clone https://github.com/yammerjp/dotfiles.git
$ yadm remote remove origin
$ yadm remote add origin git@github.com:yammerjp/dotfiles.git

SSHキーを発行して、GitHubに登録しておく

$ ssh-keygen-me
# https://github.com/yammerjp/dotfiles/blob/650d39e02fcb0b698f03acac8fca722acab35666/.config/zsh/alias.zsh#L29-L31
# https://github.com/settings/ssh/new

IMEを設定する

$ pacman -S fcitx5-im fcitx5-mozc

/etc/environmentに以下を追記

GTK_IM_MODULE="fcitx5"
QT_IM_MODULE="fcitx5"
XMODIFIERS='@im=fcitx5'

再ログインすると、タスクトレイにIMEの項目が出現する

1Passwordにログイン

https://addons.mozilla.org/ja/firefox/addon/1password-x-password-manager/

Alacritty, xclip, tmuxをインストール

$ sudo pacman -S alacritty xclip tmux

yayをインストール

AURのパッケージを管理するのに使えるツール

$ cd /tmp
$ git clone https://aur.archlinux.org/yay-bin.git
$ cd yay-bin
$ makepkg -si

ghをインストール

$ yay -S github-cli

ghqをインストール

$ cd /tmp
$ wget https://github.com/x-motemen/ghq/releases/download/v1.3.0/ghq_linux_arm64.zip
$ unzip ghq_linux_arm64.zip
$ mv ghq_linux_arm64/ghq ~/.local/bin/

好みのフォントであるHackGenNFをインストール

$ wget https://github.com/yuru7/HackGen/releases/download/v2.7.1/HackGen_NF_v2.7.1.zip
$ unzip HackGen_NF_v2.7.1.zip
$ mv HackGen_NF_v2.7.1 HackGenNF
$ sudo mv HackGenNF /usr/share/fonts
$ fc-cache -fv

asdfでnodejsとrubyとphpをインストール

$ git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.10.2
$ source ~/.zshrc #事前にasdfのロード処理を書き込み済みだった
$ asdf plugin add nodejs
$ asdf install nodejs lts
$ asdf global nodejs lts
$ node --version

$ asdf plugin add ruby
$ asdf install ruby latest
$ asdf global ruby latest
$ ruby --version

$ asdf plugin add php
# 依存が結構ある
# ref: https://github.com/asdf-community/asdf-php/blob/master/.github/workflows/workflow.yml#L30
$ sudo pacman -S autoconf base-devel gd bison curl gettext git gd libcurl-openssl-1.0 libedit mlocate oniguruma postgresql-libs mysql re2c
$ sudo updatedb
$ asdf install php latest
$ asdf global php latest
$ php --version

$ asdf plugin add golang
$ asdf install golang latest
$ asdf global golang latest
$ go version

おわりに

自宅ではしばらくAsahi Linuxを使ってみることにする。ちなみに、この文章もAsahi Linux上のAlacritty + NeoVimから書いている。

Fitbit Charge 5を買った

Mon, 14 Nov 2022 16:54:00 GMT

スマホをFelica非搭載のものに乗り換えるために、Suicaを使える機器が欲しくてFitbit Charge 5を買った。決済ができれば十分という条件で、なるべく安いスマートウォッチ(スマートバンド)を探して、この機種に帰着した。買ってから2週間くらい経ったので感想を書いてみる。

🤔決済

まず、Suicaについて。腕につける端末でSuicaを使えるのは体験がよい。改札だったり、お店だったりで支払うとき、とても楽だし、スムーズでいい感じ。

ただし、気になるポイントもいくつかある。一つは、オートチャージできないのが残念 (これは事前にわかっていた)。もともとオートチャージを使っていないので、なくても許容できるが、あったほうが気を使わずに済むので嬉しかった。

また、チャージに待たされるのが気になりポイント。チャージはFitbitアプリのみから行えるが、1分くらい待たされるのが結構長く感じる。Felica搭載のAndroid端末でSuicaチャージするときはいつも結構待たされると感じているが、それ以上に長い。

Visaタッチがうまく使えないのも少し残念。 Fitbit Charge 5は、Suica以外にも、一部のデビットカードでをVisaタッチを利用できる。たまたま対応カードを持っていたので設定したが、これは今のところうまく動かない。お店で数回試してみたものの無反応で、別の物理カードでVisaタッチして払ってしまっている。事前の設定や操作のやり方が間違っているのか、登録したカード¹が古いものだからなのか、私のもっている端末が不良品だからなのか、何が原因かわかっていない。

ただ、身の回りではSuicaさえあればわりとなんとかなってしまうので、支払い方法も統一できるしまあいいか、ということでSuicaだけ使っている。これで特に不満はない。

🤔アラーム

起きれた時はいい感じ。指定した30分のうち、睡眠の浅いタイミングでアラームを鳴らしてくれる「スマートアラーム」という機能がある。タイミングがいいときは浅い眠りのときに手首の振動で起きられるのだけど、振動していないのか、私が気づかないのか、起きれないときもある。気づかないときもあるということは、いまのところはこれにすべてを頼るというのは厳しい。とはいえ、起きれるときの体験は結構よくて、ぬるっと起きれる。

🤔ヘルスケアとフィットネストラッキング

使いこなせていない。 Fitbitといえばヘルスケア系の機能が充実しているイメージがあるが、私の場合は、とりあえず手首につけているというだけの状態である。歩数が気軽に見れたり、睡眠のトラッキングをしてくれたりするのは便利だが、あるから使っている、という程度である。他の機能も含め、使いこなせている感じは全然ない。

😆重量

軽い。もともと腕時計をつけたりするのはそんなに好んでいないのだけれど、この端末は気にならない。バンドの位置を緩めにしておけば一日中つけていられるし、寝ているときもつけたままで問題ない。

😆充電

電池持ちがすこぶる良い。公称では1週間くらいもつらしく、試していないが本当にそれくらいいけそうにみえる。私の場合は、シャワーを浴びるときだけ、洗面所に置いている充電器で充電している。これを毎日やっていればフル充電されて困らない。なぜこんなにバッテリーが持つのか、ただただ感心してしまう。

まとめ

腕につけるSuicaとして買って、概ねその用途で使っていて満足している。

本当はフィットネストラッキングを活用できるくらい運動をすればよいのだが、あまり身体を動かせておらず、その部分をまるまる享受できてない。 Fitbit Charge 5の機能に、1時間の歩数が250歩未満だと身体を動かすようバイブで促されるというのがある。まずはそれに従うところからやっていかねば。

JNB時代のファミマTカード付きのデビットカード ↩

Python実践機械学習システム100本ノックの準備

Mon, 14 Nov 2022 16:53:00 GMT

Python実践機械学習システム100本ノックを手元で動かしながら読んでみている。

Docker環境でJupyter Notebookを動かすサンプルコードがダウンロードできるが、そのままではビルドに失敗するので、requirements.txtにあるバージョンを書き換えるなどして動くように整えた。

jupyter==1.0.0
numpy==1.21.0
pandas==1.5.1
openpyxl==3.0.4
scikit-learn==1.1.3
matplotlib==3.3.2
japanize-matplotlib==1.1.2
seaborn==0.11.0
ipywidgets==7.5.1
ipympl==0.5.8
xlrd==1.2.0

あわせて、Dockerfileとdocker-compose.ymlをやりやすい形に書き換えた。ディレクトリ構成は以下のようにしている。

.
├── .env
├── .env.example
├── .gitignore
├── Dockerfile
├── Makefile
├── README.md
├── docker-compose.yml
├── requirements.txt
└── src
    └── samples
        ├── 01
        │   ├── 1章_分析に向けた準備を行う10本ノック.ipynb
        │   ├── 1章_分析に向けた準備を行う10本ノック_answer.ipynb
        │   ├── m_area.csv
        │   ├── m_store.csv
        │   ├── tbl_order_202004.csv
        │   ├── tbl_order_202005.csv
        │   └── tbl_order_202006.csv
        ...

# Makefile
.PHONY: build-image run build-image:
        bash -c 'docker-compose build --build-arg UID="`id -u`" --build-arg GID="`id -g`"'
run:
        docker-compose up -d

# Dockerfile
FROM ubuntu:22.04

RUN apt-get update && apt-get install -y \
    python3 \
    python3-pip \
    curl \
    git \
  && rm -rf /var/lib/apt/lists/*

ARG USERNAME=app
ARG GROUPNAME=app
ARG UID=1000
ARG GID=1000

RUN groupadd -g $GID $GROUPNAME && \
  useradd -m -s /bin/bash -u $UID -g $GID $USERNAME

USER $USERNAME
WORKDIR /home/$USERNAME/

ENV PATH $PATH:/home/$USERNAME/.local/bin

COPY ./requirements.txt /home/$USERNAME/requirements.txt
RUN pip3 install -r /home/$USERNAME/requirements.txt

ENV PYTHONIOENCODING utf-8
ENV LANG C.UTF-8
ENV LC_ALL C.UTF-8

# docker-compose.yml
# docker-compose.yml
version: '3.5'

services:
    jupyter_notebook:
        build:
            context: .
            args:
              - UID:1000
              - GID:1000
              - USERNAME:app
              - GROUPNAME:app
            dockerfile: ./Dockerfile
        volumes:
            - ./src:/home/app/src
        ports:
            - "8888:8888"
        environment:
            TZ: "Asia/Tokyo"
        networks:
            - default
        command: jupyter notebook --ip=0.0.0.0 --port=8888 --allow-root --no-browser --NotebookApp.notebook_dir='/home/app/src' --NotebookApp.token=''

本文はまだ最初の方しか試せていないが、読みやすいし、Jupyter Notebook上で試せるのでテンポよく進んでいい感じ。

印象に残った仕事の話をきく話

Mon, 14 Nov 2022 16:52:00 GMT

とある飲み会で、下のツイートにある質問の「(今まで携わった|最近やった)仕事の中で、印象に残ったもの」というテーマの話を、とある方が振ってくれて、聞いたり話したりしていた。

「今まで担当したお仕事で特にがんばった、印象に残ってるもの」というテーマ、志向性やバリューの源泉がわかって、お話聞くの興味深かった〜たまに自問自答していくのもよさそうだわね〜
— ねもつ (@_nemozzz) November 11, 2022

この質問がめちゃくちゃよかった。周りの人がどんな仕事をしているか、というのを把握する機会はあれど、それをどういう印象で受け止めているのかや、仕事の中でのおもしろポイント、その人が価値に感じていることを知れる機会というのは案外少ないかもしれない。同じ仕事の内容でも人によって捉え方が違うだろうし、仕事の内容を知るだけでなくて「どう考えているのか」というのを聞けるのがよい。話を聞くのが楽しいしおもしろかった。

また、話す立場としても、自分自身で仕事の内容をどう捉えているのか振り返るいい機会だった。ツイートの通りしばらく時間が立ってから自問自答するのもよいだろうし、他の人の話もきいてみたい。

HerokuからCloud Run + Litestreamへ移行した

Wed, 12 Oct 2022 01:15:00 GMT

はじめに

Herokuの無料枠が終了することにあわせて、個人で動かしているRailsアプリケーションを他の場所へ移行する。いままで無料で使わせていただいたこと感謝しつつも、月千円ほど払うほどのアプリケーションでもないので、ほぼ無料で移行できそうな場所を探すことにした。¹

コンテナをホスティングできるGoogle Cloud Runは従量課金制だが、個人で使う分にはほぼ無料なので、これを選ぶことにする。 Cloud Runで使うRDBは一般にはGoogle Cloud SQLが推奨されていそうだが、ここでは安さのためにSQLite3 + Litestream + Google Cloud Storage(以下GCS)を使うこととしたい。

実装の方向性

Litestreamは、SQLite3のデータベースを、オブジェクトストレージやNFS、SFTPのストレージにレプリケーションできるOSSのソフトウェア。

今回はコンテナの起動時にデータベースをGCSから復元し、コンテナの実行中はGCSへレプリケーションしつづける動作を実装する。 Dockerコンテナのエントリポイントに設定するシェルスクリプトのなかで、アプリケーションの起動前に処理を加えて対応する。

コンテナの同時実行数は0~1にしている。 0にしていいのかは微妙だが、個人でしか使っていないうえ、大して重要なデータを扱っているわけでもないのでひとまずこれで様子を見ることにする。

移行の手順

ざっくり以下の手順で進めた。

SQLite3化

まず、PostgreSQLからSQLite3へ移行する。 Railsに用意されたコマンド ./bin/rails db:system:change --to=sqlite3 を実行するだけで、環境問わずSQLite3で動くように修正された。

あわせてDocker化しておく。適当なDockerfile (とdocker-compose.yml) を書いて、手元のPCのDocker上で立ち上がるようにした。

LitestreamとGCSの利用

Litestreamのレプリケーション先にGCSを利用するので、GCSのセットアップをする。まず、GCSにバケットを作り、接続情報を用意する。権限を絞るためにサービスアカウントを作成し、取得した認証情報のJSONを保存しておく。²

2023/01/17追記: くのきみさんから教えていただき、Cloud RunとLitestreamの組み合わせの場合、GCSの認証情報はよしなに取得してくれるようです。この記事で行っているような認証情報の設定は不要であることがわかりました。

On a Compute Engine VM or Cloud Run service, Litestream will automatically pick up the credentials associated with the instance from the instance’s metadata server. https://litestream.io/guides/gcs/

@yammerjp
参考になりました！それはそれとしてGCSに必要なクレデンシャルはCloud Runインスタンスから拾ってくれるらしいので、自分で設定する必要はなさそうな気がしました https://t.co/WorBOBanVl https://t.co/kPx31i4S4C
— くのきみ (@knokmki612) January 16, 2023

くのきみさん、情報提供ありがとうございます。

つぎに、Dockerコンテナ起動時にLitestreamによる復元とレプリケーションを設定する。

Dockerfileでは、Litestreamのインストールと設定ファイルの設置を行っている。³

# Dockerfile
FROM rubylang/ruby:3.0.1-focal

RUN mkdir /app
WORKDIR /app

# Google Cloud Storageへの接続情報を保存するファイルのパスを事前に指定しておく。
# コンテナイメージにこのファイルを含める必要はない。
ENV GOOGLE_APPLICATION_CREDENTIALS /app/.gcs-credentials.json

ENV TZ Asia/Tokyo
RUN apt update \
 && apt install -y sqlite3 \
 && apt-get clean \
 && rm -rf /var/lib/apt/lists/*

# Litestreamのバイナリを設置する。
ADD https://github.com/benbjohnson/litestream/releases/download/v0.3.8/litestream-v0.3.8-linux-amd64-static.tar.gz /tmp/litestream.tar.gz
RUN tar -C /usr/local/bin -xzf /tmp/litestream.tar.gz

ADD Gemfile /app/Gemfile
ADD Gemfile.lock /app/Gemfile.lock
RUN bundle install

COPY . /app

# Litestreamの設定ファイルを設置する。
COPY ./litestream.yml /etc/litestream.yml

# litestream.yml
dbs:
  - path: /app/db/production.sqlite3
    replicas:
      - url: gcs://____YOUR_BACKET_NAME____/db/production.sqlite3
  - path: /app/db/staging.sqlite3
    replicas:
      - url: gcs://____YOUR_BACKET_NAME____/db/staging.sqlite3

entrypoint.shでは、データベースを復元してからレプリケーションを開始する。あわせて以下も実装している。

開発環境や初回起動時は、データベースの復元の代わりに、マウントされたファイルを使う、もしくはrake db:migrate:resetする。
ポート番号は$PORTを優先して利用する。⁴
接続情報は環境変数に集約する。LitestreamはGCSへの接続情報として$GOOGLE_APPLICATION_CREDENTIALSにJSONファイルへのパスが入ることを期待する。コンテナイメージに接続情報を含めないために、JSONをbase64でエンコードして環境変数に保存しておき、起動時に書き出す。

entrypoint.sh

#!/bin/bash -e

# entrypoint.sh

if [ "$RAILS_ENV" = "" ]; then
  DATABASE_FILE="db/development.sqlite3"
else
  DATABASE_FILE="db/$RAILS_ENV.sqlite3"
fi
DATABASE_FILE_FULLPATH="/app/$DATABASE_FILE"
DATABASE_FILE_BACKET_FULLPATH="gcs://____YOUR_BACKET_NAME____/$DATABASE_FILE"


# PORT番号は$PORTを優先する
if [ "$PORT" = "" ]; then
  PORT=8080
fi
EXEC_COMMAND="bundle exec rails server -p $PORT -b 0.0.0.0"


if [ "$RAILS_ENV" = "production" ] || [ "$RAILS_ENV" = "staging" ] ; then
  USE_LITESTREAM="true"
else
  USE_LITESTREAM="false"
fi


# Litestreamを使う場合は、データベースをGCSから復元する
if [ "$USE_LITESTREAM" = "true" ] ; then
  # GCSの接続情報を環境変数から読み込み、base64デコードしてからファイルに書き込む
  # (事前に、接続情報をbase64エンコードして環境変数に設定しておく)
  if [ "$GOOGLE_APPLICATION_CREDENTIALS" = '' ] || [ "$GOOGLE_APPLICATION_CREDENTIALS_BASE64" = '' ] ; then
    echo "Need to set \$GOOGLE_APPLICATION_CREDENTIALS and \$GOOGLE_APPLICATION_CREDENTIALS_BASE64"
    exit 1
  fi
  echo "$GOOGLE_APPLICATION_CREDENTIALS_BASE64" | base64 --decode > "$GOOGLE_APPLICATION_CREDENTIALS"

  # GCSからデータベースを復元する
  litestream restore -v -if-replica-exists -o "$DATABASE_FILE_FULLPATH" "$DATABASE_FILE_BACKET_FULLPATH"
fi

# データベースを初期化する (初回起動時は復元されたファイルがないため)
if ! [ -f "$DATABASE_FILE_FULLPATH" ] && [ "$ALLOW_RESET_DATABASE" = 'true' ]; then
  rake db:migrate:reset
  # ここで初期化用のSQLを流してもよい
  # if [ -f "$SETUP_SQL_PATH" ]; then
  #   cat "$SETUP_SQL_PATH" | sqlite3 "$DATABASE_FILE_FULLPATH"
  # fi
fi

if ! [ -f "$DATABASE_FILE_FULLPATH" ]; then
  echo "$DATABASE_FILE_FULLPATH is not found..."
  exit 1
fi


if [ "$USE_LITESTREAM" = "true" ] ; then
  # Litestreamによってレプリケーションしながら、アプリケーションを起動する
  exec litestream replicate -exec "$EXEC_COMMAND" -config /etc/litestream.yml
else
  # shellcheck disable=SC2090
  exec $EXEC_COMMAND
fi

アプリケーションのデプロイ

Staging環境をつくって、ひとまずはgcloudコマンドで手動でデプロイしたあとに、GitHubのリポジトリと紐付けて自動デプロイがなされるように設定した。

Cloud RunとLitestream関係ないが、RAILS_ENV=productionとして動かすためやコンテナ上で動かすための設定(RAILS_LOG_TO_STDOUTやRAILS_SERVE_STATIC_FILESなど)をいくつか調整した。

データの移行

HerokuのPostgreSQLからのデータの移行は、pg_dumpを用いた。

# 接続先の認証情報を得る
$ heroku pg:credentials:url --app APPNAME
# 認証情報を使って、データベースの内容をINSERT文形式で取得する。
$ pg_dump --data-only --no-owner --no-privileges --disable-dollar-quoting --no-acl --inserts -h HOSTNAME -U USERNAME DBNAME > data.sql

得られたdata.sqlをちょこちょこ編集して、SQLite3で読み込めるINSERT文だけにする。 SQLを流し込むのはローカルPC上で実施した。 entrypoint.shを一時的にすこし変えて、rake db:migrate:resetのあとにdata.sqlを流し込むようにしておく。

さきほどのentrypoint.shを使えば、環境変数に応じてローカルPC上でも本番環境のデータベースをレプリケーションできる。 RAILS_ENV=productionとしてコンテナを立ち上げて、データが挿入されているのを確認したら移行はおわり。

感想

Cloud Run + Litestream + GCSはコールドスタート時は少し時間がかかるが、Herokuの無料枠とさして変わらないかむしろ早いかもしれない。⁵ それ以外の動作は結構サクサクしていていい感じ。

ローカルでも気軽に同じ構成で動かせたりして結構よいので、Cloud RunでLitestreamを使うテンプレートを用意したい気持ちになった。

お金がかかってもよい場合のホスト先はRenderやFly.io、もしくはHerokuのEco Dynoなどがありそう。Herokuの新しい有料プランのまとめと、無料プラン終了後の個人的な移行方針について - give IT a try ↩
参考: 特定のGCSバケットにのみアクセスできるサービスアカウントの作り方 - Carpe Diem ↩
参考: Cloud RunとLitestreamで激安GraphQL/RDBサーバーを動かす ↩
Cloud Runでは環境変数PORTを参照することがおすすめされている。既存のサービスを移行する | Cloud Run のドキュメント | Google Cloud ↩
データ量が大変少ない単純なアプリケーションだからということもあるだろう。 ↩

CloudFront Functionsで指定したURLにリダイレクトさせる

Sat, 08 Oct 2022 01:25:00 GMT

CloudFront Functionsというサービスがあり、軽量のJavaScriptコードをデプロイしてCloudFrontディストリビューションに紐づけることができるらしい。他のサーバレスの実行環境との比較は以下の記事が参考になる。

ちょうどdotfilesリポジトリのセットアップ用スクリプトを取得できるエンドポイントを用意したかったので、今回はCloudFront Functionsで他のURLへの302リダイレクトを発行するエンドポイントを作成してみる。

まずは、AWSコンソールのCloudFrontのページへ行き、左側のメニューから「関数」を選択する。

「関数を作成」を選択すると、サンプルコード付きのCloudFront Functionsの関数(実行できる一単位)が一つ作成される。

今回はリダイレクトしたいので、以下のようなコードに書き換える。

function handler(event) {
    var response = {
            statusCode: 302,
            statusDescription: 'Found',
            headers: {
                "location": { "value": 'https://raw.githubusercontent.com/yammerjp/dotfiles/master/setup.sh' }
            }
    };
    return response;
}

テストタブでは関数を動作させてどんなレスポンスが返るかをみることができる。

問題なさそうであれば、発行タブから「関数を発行」する。さらに作成した関数をCloudFrontのディストリビューションに紐付け、実際のWebからのリクエストで発火するようにする。

手元でcurlコマンドを実行してみると、実際にリダイレクトが確認できる。

$ curl http://dot.yammer.jp --verbose
*   Trying 2606:4700:3031::6815:2cf8...
* TCP_NODELAY set
* Connected to dot.yammer.jp (2606:4700:3031::6815:2cf8) port 80 (#0)
> GET / HTTP/1.1
> Host: dot.yammer.jp
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 302 Found
< Date: Thu, 06 Oct 2022 16:17:57 GMT
< Content-Length: 0
< Connection: keep-alive
< Location: https://raw.githubusercontent.com/yammerjp/dotfiles/master/.bin/download.sh
< X-Cache: FunctionGeneratedResponse from cloudfront
< Via: 1.1 b4dadadff1d09a3efb8a9374bdfc2848.cloudfront.net (CloudFront)
< X-Amz-Cf-Pop: NRT12-C2
< Alt-Svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
< X-Amz-Cf-Id: Hx-hLyCjKYgzxYXB_cUrSQgtHDgQW-maDnfZvaXmn0mtzPu2hC_YSg==
< CF-Cache-Status: DYNAMIC
< Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=E2QYl2tLkUVmKzT2wAiYJhTp9NTPLj2s%2BtOwP%2Fx%2Fuq5qeDKYK5gttDmaBH8k1BxB9d0GPK8prNS7I5UMpG1aeUijjhl%2B32uT87m%2FhRGc6Jt9CGY1DHnld3Fku21CCEGZu2cnl6g2Yf1pvEU2"}],"group":"cf-nel","max_age":604800}
< NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
< Server: cloudflare
< CF-RAY: 755fb5ce8bceafab-NRT
<
* Connection #0 to host dot.yammer.jp left intact
* Closing connection 0
$ curl -sL http://dot.yammer.jp | head -30
#!/bin/bash -e

if [ "$(whoami)" = "root" ]; then
  echo "The script must be running without root."
  exit 1
fi

REPO="yammerjp/dotfiles"

DOTFILES_DIR="$HOME/src/github.com/$REPO"
if [ -d "${DOTFILES_DIR}" ]; then
  echo "Dotfiles is already exist."
  echo "${DOTFILES_DIR}"
else

cat <<-"EOF"



      .o8                .    .o88o.  o8o  oooo
     "888              .o8    888 `"  `"'  `888
 .oooo888   .ooooo.  .o888oo o888oo  oooo   888   .ooooo.   .oooo.o
d88' `888  d88' `88b   888    888    `888   888  d88' `88b d88(  "8
888   888  888   888   888    888     888   888  888ooo888 `"Y88b.
888   888  888   888   888 .  888     888   888  888    .o o.  )88b
`Y8bod88P" `Y8bod8P'   "888" o888o   o888o o888o `Y8bod8P' 8""888P'




$

Alacrittyを使っていく

Tue, 06 Sep 2022 15:22:00 GMT

Alacritty とは

Alacrittyはクロスプラットフォームなターミナルエミュレーター。 yamlで設定を記述できること、クロスプラットフォームであること、動作が早いことが特徴である。

IMEのインラインサポート

おぉぉぉぉぉ
ついに、alacrittyにIMEのインラインサポートが入った！！ちゃんと変換中の位置も考慮されてdeleteもできてる！！！
よし、乗り換えるぞ！https://t.co/J0rF12hJl2 pic.twitter.com/tADAMBfHTe
— karasu@オフトゥン大好き (@Ket0104) September 4, 2022

AlacrittyにIMEで入力した時に未確定な文字列を表示する対応が入ったらしい。

対応されたのが嬉しかったので、早速ビルド¹して手元のMacBook Airで使うことにした。実は以前、この変換前文字列の表示がサポートされていないことを理由に使うのをやめてしまっていたのであったので、待望の機能である。

ビルドして使ってみる

ビルドはめちゃ簡単で、cargoコマンドが使えれば依存関係に困るとかもない。

# 事前にRustのビルド環境を入れておく
$ brew install rust

# cloneして...
$ git clone git@github.com:alacritty/alacritty.git
$ cd alacritty

# make appするだけでmacOS向けの実行ファイルをビルドできる
$ make app

# 適当なディレクトリに移動して、アプリケーションを起動する
$ cp -r target/release/osx/Alacritty.app ~/Application
$ open ~/Applications/Alacritty.app

設定ファイルを記述する

Alacrittyの特徴のひとつはyamlで設定を記述できることだと思うので、ひとまず設定ファイルを記述してみる。

Alacritty.ymlの設定はArch Linuxのwikiなどが参考になる。

HackGenというフォントがみやすくて好みなので、これを設定する。

ちなみにmacOSにインストールされたフォント名は fc-list で確認できる

$ fc-list | grep HackGen
/Users/yammer/Library/Fonts/HackGen-Regular.ttf: HackGen:style=Regular
/Users/yammer/Library/Fonts/HackGen35-Bold.ttf: HackGen35:style=Bold
/Users/yammer/Library/Fonts/HackGen35Console-Regular.ttf: HackGen35 Console:style=Regular
/Users/yammer/Library/Fonts/HackGen35Console-Bold.ttf: HackGen35 Console:style=Bold
/Users/yammer/Library/Fonts/HackGenConsole-Regular.ttf: HackGen Console:style=Regular
/Users/yammer/Library/Fonts/HackGenConsole-Bold.ttf: HackGen Console:style=Bold
/Users/yammer/Library/Fonts/HackGen35-Regular.ttf: HackGen35:style=Regular
/Users/yammer/Library/Fonts/HackGen-Bold.ttf: HackGen:style=Bold

# alacritty.yaml
font:
  normal:
    family: HackGen Console
    style: Regular
  bold:
    family: HackGen Console
    style: Bold

これでいい感じになった。

ありがとう、iTerm2

$ brew uninstall --cask iterm2
==> Uninstalling Cask iterm2
==> Backing App 'iTerm.app' up to '/opt/homebrew/Caskroom/iterm2/3.4.10/iTerm.app'
==> Removing App '/Applications/iTerm.app'
==> Purging files for version 3.4.10 of Cask iterm2

ちゃんと確認していないが、マージされた日付的に2022/09/06時点でのリリースに含まれていてビルドしなくてもよかったかもしれない。(未確認) ↩

プログラマのための文字コード技術入門を読んだ(2022年9月)

Thu, 01 Sep 2022 14:42:09 GMT

(2024/09/22記) 2022年の9月に読んだ本の記事が、下書きとして残っていたままだったので公開します。

業務で文字コードに触れる機会があったのですがそもそも文字コードというものに詳しくないので「改定新版プログラマのための文字コード技術入門」という本を読みました。

本を読む前は文字コードにはいくつかの規格があることを知っている程度の理解であったので、なによりもまず勉強になりました。また後述するいくつかの概念は背景とともに説明があって知っておかないと規格を理解しづらいので、本を買ってよかったという気持ちになりました。

それだけでなく、この本を結構読むのが楽しく、平日の数日間で勢いで読み切ってしまうほどでした。

学べたこと: 文字の単位

私達が普段扱う文字は、何がひとつなのか、どれを同じ文字として扱うのか等の境界が実はあいまいで奥深いことを認識しました。たとえばbyte(8bit)単位で考えると、「あ」は2byteにも3byteにもなり得ます。UTF-16では多くの文字は4byteで表され、処理系においてもそう扱われることがありますが、「𠮟」はサロゲートペアなので8byteで1つの文字を表します。濁点のついた文字は「が」はそれ自体に符号位置が与えられている場合もありますし、「か」と「゛」を分けて符号化したものの結合文字として表現されることもあります。「𠮟」「叱」は十分に似ていそうですが、同じ文字でしょうか？「😀」は文字といえるでしょうか？普段当たり前にキーボードで入力している文字ですが、それらは符号化文字集合によって符号位置が定まっているだけでなく、複数の文字を一つの文字のように表す結合文字や、文字の単位としての書記素、どのような字形変化であれば同じ文字とみなすかを定めた漢字の包摂規則など、様々な概念に基づく定義の上に成り立っていることを認識しました。

学べたこと: ISO/IEC 2022の概念

1バイトや２バイトのメジャーな符号化方式のいくつかが従うISO/IEC 2022の符号化文字集合の符号位置と符号化方式のコードポイントの対応付の概念を学びました。

G0-G3のバッファに符号面を呼び出した後、GLやGRにそれを呼び出し、呼び出し方を変えたり変えなかったりしながら文字列を表現するということを知りました。

そのほかに学べたこと

文字コードや符号化文字集合における「文字」はどう認識されているのか (byte，正規化、書記素、結合文字などの概念、包摂規則)
文字コードのメジャーな規格とその変遷、文字コード間の関係
ISO/IEC 2022の基本概念１バイト/2バイトの符号化方式で基本となるGL，GR，G0からG3のバッファ
区点番号の概念
BMPとサロゲートペア、utf-8のバイト数(3,4,6)、BOM

学べなかったこと

外字/機種依存文字の詳細

おわりに

というわけで、ここまでが下書きとして文章で書き出していた内容でした。

2024年にはとりあえずutf8mb4に相当するようなものを使っておけば意識することのない文字コードですが、本を一冊読むとインデックスが生えて、必要な時の引き出しが増えるので便利です。

本当は学んだことをあとから振り返りやすいようにもっと詳細に書きたくて箇条書きや単語レベルのメモを書いていたようですが、書ききっていなかったので以降はまた文字コードに思いを馳せるときがきた時のために、自分向けのメモとして残しておきます。

そのほかのメモ

符号化文字集合

JIS X 208

1978年に制定され、その後複数回改定された日本で最も基本的な２バイト符号化文字集合
JIS第1水準、第2水準の漢字が含まれる
ISO/IEC 2022準拠。第一バイト(行)第二バイト(列)ともに0x21-0x7Eの94行x94列に収まる組み合わせ
区点番号 ... 94行x94列の表のどこに位置するかを表す表記。例えば愛は16行目六列目に位置するので16区6点という。
対応する符号化方式としてShift_JISやEUC-JP、ISO-2022-JPなどがある

JIS X 212

JISX 208と組み合わせて使うことを前提とした２バイト符号化文字集合
94x94
EUC-JPでは使う方法が提供されているがShift_JISでは使えない

JIS X 213

JIS X 208を拡張した２バイト符号化文字集合
2000年に制定され2004年に改定されたため、JIS2000、JIS2004などと呼ばれることがある
JIS X 212とはかなりの文字が重複する
94x94を2面持つ
1面はJIS X 208の空き領域に文字を追加したもの(追加された漢字はJIS第3水準)
2面は漢字のみ (JIS第4水準)
- JIS X 212で定義されている区点番号を避けている
- EUC-JPのJIS X 212と区別がつくように
符号化方式としてはShift_JIS-2004、ISO-2022-JP、EUC-JIS-2004

Latin-1 (ISO/IEC 8859-1)

MySQL5系のデフォルトで設定されることでおなじみ 8ビット1バイトの符号化文字集合で、西ヨーロッパ言語向けの文字をふくむ GLにASCIIを固定し、GRにLatin-1で定義した文字が使われる

そのほか書きたかったこと

JIS X 208 212 213 eucJP-ms IBM拡張
Unicode ISO/IEC 10646(UCS) JIS X 0221
BMP
正規化
書記素
IBM拡張
NEC拡張
NEC選定IBM拡張
EUC-JP(GLはASCIIで固定)
eucJP-ms
Shift_JIS EUC-JP JISX 208の関係
各言語処理系での実装
Rubyの実装(CP51932, EUC_JP, EUCJP_MS)
PHPの実装
Goの実装

Clean Architectureを読んだ

Tue, 23 Aug 2022 14:30:00 GMT

書籍「Clean Architecture」を読みました。副題は「達人に学ぶソフトウェアの構造と設計」となっており、ソフトウェアの構造や設計について見識をあまり持たない私は、この副題のとおり達人に学ぼうという気持ちで読みました。

本書で学べたこと (印象に残ったこと)

本書を読むことで、"依存の方向"と"境界の決定"に関する考え方を学びました。これらをはじめとする、本書で学んだ考え方を以下に紹介します。

なおこの記事では、書籍のタイトルや内容に反して、クリーンアーキテクチャとは何かやクリーンアーキテクチャの図に関する話はほとんど出てきません。それを構成する考え方に重きをおいて紹介します。以下に示す考え方をみてみると、同心円状に書かれるクリーンアーキテクチャの図も依存の方向と境界の決定などの考え方を適用してできあがる図であるといえると思っています。

依存の方向

アプリケーションのアーキテクチャにおいて、依存の方向を揃えることは重要です。

(例えばJavaではインタフェースを定義するなどして¹)ポリモーフィズムを利用して処理の流れとソースコード上の依存の向きを逆転²させることを、依存性の逆転と呼びます。この依存性の逆転を用いて、クリーンアーキテクチャにおける上位のレベル (ビジネスロジックに近いもの) が下位のレベル (システムの入出力に近いもの) に依存しないよう、また循環依存とならぬよう、依存の向きを揃えることが様々なシチュエーションに適用して説明されています。

境界の決定

アプリケーションのアーキテクチャの検討において、実装の境界³をどこにどの程度明確に作るかは、状況ごとにその都度考えて決定する必要があります。なぜならば、アプリケーションの内容だけでなく、その周辺環境 (開発組織や開発頻度)、今後の開発計画など様々な要因で境界の最適解が異なるからです。

ユースケースのすべて、運用上の制約、チームの構造、デプロイ要件などは実装前に明らかになっているとは限らないし、またこれは開発運用を続けるうちに変化していくものです。これらの変化に合わせて適切なタイミングで適切に境界を定めて分割できるよう、選択肢を残しながらそのときどきに合わせて判断を続けていく必要があると考えられます。

その他の事柄 (書籍で扱われる話題のメモ)

書籍で扱われているトピックが大変多いので、ここではメモとしていくつか列挙します。詳細については書籍にあたればわかる程度の粒度で記載しています。

アーキテクチャに関連する原則

この書籍では以下のように多数の原則が紹介されています。これらをすべて厳密に守りましょうと主張しているというよりも、これらの原則が言い表している物事の方向性を明らかにして、望むべきアーキテクチャを考えるヒントとしている、というように感じました。

いっぽう私はこれらの原則に明るいわけではなかったので、どういうものか、いつ適用するか、何が嬉しいのかを把握することにも役立ちました。

SOLID原則 (単一責任の原則、オープン・クローズドの原則、リスコフの置換原則、インターフェイス分離の原則、依存関係逆転の原則)
コンポーネントの凝集性に関する原則 (再利用・リリース等価の原則、閉鎖性共通の原則、全再利用の原則)
コンポーネントの結合に関する原則 (非循環依存関係の原則、安定依存の原則、安定度・抽象度等価の原則)

Mainコンポーネントは最も詳細

Mainコンポーネント (アプリケーションの起動時に実行されるコード) はもっとも詳細な部分であり、プラグインとして環境によって取り替えられるような作りにすべきであるという考え方が紹介されていました。

例えばユニットテスト実行時を考えてみると、アプリケーションのエントリポイントとは別の箇所から処理の実行が始まるでしょう。つまりMainコンポーネントは、依存する側になるよう依存性の逆転を生かすべきコンポーネントのひとつであることがわかります。

アーキテクチャの変遷

(これは直接的には語られていませんが、ところどころで出現する話を私が解釈して勝手に書いています。)

書籍の中ではアーキテクチャの完全な正解を教えてくれるというより、アーキテクチャを考える上でのいくつかの要素を揃えてくれているように思います。

書籍の考え方を適用すると、マイクロサービスアーキテクチャや(本書では言葉こそ出てきませんが)モジュラーモノリスも、それらが特別なものではなく、境界の決定の仕方の選択肢のひとつであると感じました。

フレームワークなんかと結婚するな！

著者はフレームワークと結合することに否定的な考え方を持っています。昨今のWebアプリケーション開発ではフレームワークに則って作ることがよくあると思いますが、ロックインされないような開発方法を提示するとともに、フレームワークとの密な結合をとった場合の考え方を結婚に例えて「病めるときも...」と記述しているのが少し皮肉的です。

このほかに、同心円状のクリーンアーキテクチャの図や、オブジェクト指向プログラミングがもたらしたものに関する記述も印象的でした。

おわりに

この本は英語の原著に対する訳本だったのですが、文調がたいへん読みやすく感じました。著者/訳者の文章の書き方に憧れます。

書籍の内容について、これはアプリケーションを設計/開発するときのヒントのひとつになる内容でした。今の自分にとっては結構よい本という感触がありますが、一方で全てを吸収する能力があったかというとこれは疑問です。開発経験のあるアプリケーションの数が多ければ、いまよりも詳細に書籍の指すことが理解できるだろうとも思います。

この本を読んで、自分が関わるアプリケーションがどんなアーキテクチャを持っているかを考えるきっかけになりました。またよいアーキテクチャを提案する能力も一部学ぶことができました。一方で、よいアーキテクチャを選択する能力は本書を読んでもそれほど得られていないでしょう。書籍を通して学んだ考え方をもとに、実際のアプリケーションと照らし合わせて考えを膨らませ経験を重ねることで得られるように思います。精進します。

書籍ではJavaを扱っているのでJavaを挙げていますが、いわゆる動的型付け言語ではインタフェースを定義せずとも同名のメソッドがあれば振る舞いが定まるポリモーフィズムが実現できそうです。 ↩
ソースコード上の依存の向きは次のように考えられるでしょう。例えばあるインスタンスBをAが呼び出すときは、AはBに依存しているといえます。一方であるインタフェースCをAが呼び出し、BはインタフェースCを実装したクラスのインスタンスであったとすると、AはCに依存し、BもCに依存します。これによりAからBに向く依存がなくなり、依存性の逆転がなされたといえます。 ↩
境界が何を指すのかは書籍では明確には定義されていないように思います。私が思うに、クラス、ファイル、ディレクトリ、(各言語に付属の)パッケージや名前空間、などがそれぞれ粒度の異なる境界といえるでしょう。 ↩

WiresharkでHTTP通信の内容を確認する

Tue, 23 Aug 2022 13:32:06 GMT

Wiresharkはネットワークプロトコルアナライザとよばれるソフトウェアで、通信の内容を確認することができる。

以下では簡単な使い方として、curlコマンドを使って手元のPCからインターネット上のサーバへHTTP通信した場合のパケットの内容を、tcpdumpでキャプチャし、最後にWiresharkのGUI画面上で確認する手順を示す。なお、実行したPCは macOS 11.6 BigSur (Apple M1) だが、他の環境でも同様の手順で実行できると思われる。

パケットのキャプチャ

まずはじめに、キャプチャするパケットを絞り込めるよう、事前に通信先のIPアドレスを調べておく。次に、tcpdumpコマンドをsudoで実行し、キャプチャするパケットの通信先IPアドレスを指定した上で、内容を適当なファイルに書き込む。 (ここでは/tmp/memo-yammer-jpとする。)

(後述のcurlコマンド実行後、キャプチャが終わったらCtrl-cで終了する。)

$ dig @8.8.8.8 memo.yammer.jp +short
199.36.158.100
$ sudo tcpdump host 199.36.158.100 -w /tmp/memo-yammer-jp
Password:
tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
^C11 packets captured
243 packets received by filter
0 packets dropped by kernel

別のウィンドウでシェルを開き、curlコマンドを実行してキャプチャされるパケットを送受信する。ここでは内容が確認できるよう、暗号化されていないHTTPプロトコルを指定している。

$ curl http://memo.yammer.jp --verbose
*   Trying 199.36.158.100...
* TCP_NODELAY set
* Connected to memo.yammer.jp (199.36.158.100) port 80 (#0)
> GET / HTTP/1.1
> Host: memo.yammer.jp
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: Varnish
< Retry-After: 0
< Location: https://memo.yammer.jp/
< Content-Length: 0
< Accept-Ranges: bytes
< Date: Tue, 23 Aug 2022 13:26:48 GMT
< Connection: close
< X-Served-By: cache-hnd18733-HND
< X-Cache: HIT
< X-Cache-Hits: 0
< X-Timer: S1661261209.536052,VS0,VE0
<
* Closing connection 0

パケットの内容の確認

tcpdumpをCtrl-cで終了し、パケットがキャプチャできたら、出力されたファイルをWireshark¹から確認してみる。 Wiresharkを起動し、ファイルを開くボタンを選択する。

次に、ファイル名を指定して開く。

すると、パケットのキャプチャ結果が表示され、画面の中央部にはHTTPのヘッダが表示されているのがわかる。

Wiresharkは次のURLからダウンロードできる。 https://www.wireshark.org/download.html ↩

abbrはじめました。

Thu, 04 Aug 2022 01:26:00 GMT

同僚に教えてもらった zsh-abbrを導入しました。

zsh-abbrとは

abbr は abbreviation の略で、おそらくもともとfish shellに組み込まれた機能とコマンド名を指しているようです。fishのabbrコマンドは、短いコマンド名を展開するalias コマンドに似た働きをするものです。

aliasコマンドとの違いは以下のようなところにあります

実行前にプロンプト上で短いコマンド名を展開してから実行される
- historyには展開された結果が記録に残る
短いコマンド名を入力したあとスペースキーを入力しても、プロンプト上で展開される

zsh-abbrはfishのabbrコマンドと同等のものをzsh上でも再現できるzshプラグインです。筆者はzshを使っているので、本記事ではzsh-abbrを導入します。

導入

なるべくシンプルな状態を維持する目的でzshプラグインは入れないようにしていたのですが、複数のホストで環境を再現しやすいよう、zsh-abbrを導入するにあたってプラグインマネージャーも一緒に導入しました。

zshプラグインは速そうなZinitを選びました。

Zinitの導入

インストールはREADMEに書いてある通り進めるだけです。

$ bash -c "$(curl --fail --show-error --silent --location https://raw.githubusercontent.com/zdharma-continuum/zinit/HEAD/scripts/install.sh)"

上記のコマンドを実行すると、~/.zshrc に設定の読み込みなどが追記されるので source ~/.zshrc として読み込めば利用できるようになっています。

zsh-abbrの導入

github.comに公開されているzshプラグインは、ユーザ名とリポジトリ名を指定すると利用できるようになります。以下の一行を ~/.zshrc の、Zinitの読み込み処理の下に記述しました。

# ~/.zshrc
zinit light olets/zsh-abbr

ref: https://github.com/zdharma-continuum/zinit#loading-and-unloading

導入例

ここまでの記述は、~/.zshrcなどの起動時の読み込まれるzshスクリプト内に記述すると良いでしょう。

一例として、以下のようになるかと思います。

# ~/.zshrc

# Zinitのインストール時に挿入される、初期化関連の記述
### Added by Zinit's installer
if [[ ! -f $HOME/.local/share/zinit/zinit.git/zinit.zsh ]]; then
    print -P "%F{33} %F{220}Installing %F{33}ZDHARMA-CONTINUUM%F{220} Initiative Plugin Manager (%F{33}zdharma-continuum/zinit%F{220})…%f"
    command mkdir -p "$HOME/.local/share/zinit" && command chmod g-rwX "$HOME/.local/share/zinit"
    command git clone https://github.com/zdharma-continuum/zinit "$HOME/.local/share/zinit/zinit.git" && \
        print -P "%F{33} %F{34}Installation successful.%f%b" || \
        print -P "%F{160} The clone has failed.%f%b"
fi

source "$HOME/.local/share/zinit/zinit.git/zinit.zsh"
autoload -Uz _zinit
(( ${+_comps} )) && _comps[zinit]=_zinit

### End of Zinit's installer chunk

# Zinitを用いてzsh-abbrを利用する
zinit light olets/zsh-abbr

設定

zsh-abbrの設定

zsh-abbrには、既に貼られているaliasを読み込んで保持する機能があります。¹ 今回はこれを利用することにして、以下のコマンドを実行します。

$ abbr import-aliases

gitのaliasもzsh-abbrで展開する機能が備わっているようなので、同様にgitのaliasも読み込みます。

$ abbr import-git-aliases

import-git-aliasesを利用すると、gに続けてエイリアスをタイプしたり、もしくはエイリアスを直接コマンドとしてプロンプトに入力すると展開されます。たとえば私は git d が git diff となるようなエイリアスをgitの設定に書き込んでいます。この場合、プロンプトに gd や d と入力すると git diff が実行されることになります。

細かな工夫

git aliasの入れ子を排除

私のもともとの設定にはgitやzshのaliasが入れ子になっている場合があったため、入れ子を排除するような記述に書き換えました。

たとえば、gitでは以下のような設定をしていました。

# ~/.gitconfig
[alias]
        di = "diff --ignore-all-space"
        ds = "di --staged"

このようなとき、zsh-abbrは gds を git di --staged とは展開してくれますが、 git diff --ignore-all-space --staged とまでは展開してくれません。全て展開するために、aliasが入れ子にならないよう、以下のように設定を書き換えることとしました。

# ~/.gitconfig
[alias]
        di = "diff --ignore-all-space"
        ds = "diff  --ignore-all-space --staged"

あえてgit aliasを入れ子にする

gitのaliasのうちコマンド実行であるもの (!で始まるもの) は展開に対応していないようなので²、これらはあえてaliasを張っています。

以下に例を示します。登録しているgitのaliasを表示するコマンド alias と als をgitの設定に記述しています。

# ~/.gitconfig
[alias]
        alias = "!git config --list | grep -e '^alias' | sed -e 's/alias\\.//' -e 's/=/\\t\\t/'"
        als = alias

この場合alias はabbrに対応していませんが、その短縮系であるalsはabbrに対応しています。つまり galias は実行できませんが、gals とコマンド入力すると abbrを介して git alias が実行されます。さらにこれはgitのもともとのalias機能を介してコマンド実行がなされるので、gitのaliasの一覧が表示されるということになります。

gitのaliasについて、入れ子に対応していないこととコマンド実行に対応していないことをうまく活かして一部展開されるような状態をつくってみました。

感想

実行時にどんなコマンドを実行しているか都度表示されることで、画面共有時などに役立ちそうです。 historyの検索に展開されたものが記録されるという恩恵はしばらく使い続けないと効果が感じられないと思うので、この設定で運用してみようと思います。

ちなみにタイトルについて補足しておくと、冷やし中華はまだ始めていません。(今夏食べた記憶がない。)

保存した内容はabbrコマンドで操作できるようです。また記録先としては$ABBR_USER_ABBREVIATIONS_FILEに保存されているようです。 ↩
https://github.com/olets/zsh-abbr/blob/91280150cf8de09f84ab02c00fc04605400ea914/zsh-abbr.zsh#L337 ↩

Software Designへ寄稿しました (2022年6月号第1特集 Appendix dotfilesのススメ)

Wed, 18 May 2022 02:00:00 GMT

技術評論社のSoftware Design 2022年6月号第1特集 Appendix へ「dotfilesのススメ」という記事を寄稿させていただきました。本日5/18発売で、全国の書店やWebでお買い求めいただけます。

「dotfilesのススメ」は、UnixやLinuxなどでツールの設定を記述するファイルであるdotfilesの管理構成をつくるハンズオン記事になっています。 GitHub上にdotfilesリポジトリをつくることを通してdotfilesに入門できます。

.bashrcや.zshrcや.gitconfigに何書いてるかよくわからない方、dotfilesをあまり知らない方、dotfilesの管理が気になっているんが手をつけていない方などにぜひ読んでいただきたい内容になっています。

寄稿のきっかけは、技術評論社の方が私の書いたブログ記事を読んでメールをくださったことでした。執筆の経験がなかったのでメールをいただいたときは大変驚きましたが、いまは無事寄稿を終えて安堵しています。

このブログは技術メモをはじめとして自分が忘れないための備忘録や日本語の文章を書く練習として始めたものです。ブログを書いてアウトプットすることは思考を整理したり良いものを共有したりするだけでなく偶然の機会を生むこともあるので、改めて文章を書くことを続けていこうと思います。

執筆にあたり、Software Designの編集を担当してくださった担当者様やレビューをしてくださった上長に大変お世話になりました。執筆や校正に関してフォローいただきありがとうございました。

さてさて、この記事を呼んだ皆様方はどうぞ書籍を手にとってご覧いただき、ご購入ください！寄稿記事の感想はぜひ技術評論社のプレゼント応募付き読者アンケートや@yammerjpにお寄せいただけると嬉しいです。記事の寄稿依頼はメール(me[at]yammer.jp)ないし@yammerjpまでお寄せください。

cocot46を組み立てた(Build Log)

Mon, 16 May 2022 17:30:00 GMT

トラックボールとロータリーエンコーダを搭載したキーボード、cocot46を組み立てました。 40%でColumn staggeredな配列が魅力的なキーボードです。

経緯

購入のきっかけはcocot46の作者の@aki27kbdさんが再販予定をツイートされているのを見かけたことでした。

#cocot46lp は、手持ちのトラックボールモジュール在庫の数だけキットに同梱したものを近日中にboothにて頒布します。無印の #cocot46 も同様にトラックボールモジュールを同梱したものを遊舎工房に委託予定です。どちらも在庫限りとなる予定なので、気になる方はこの機会にぜひ。
— aki27 (@aki27kbd) April 16, 2022

トラックボール一体型のキーボードが気になっていたものの、1Uのトラックボールユニットは終売となっていて手に入れるのが難しそうだと思っていた時だったので、ツイートをみかけて嬉しくなりました。このあとは再販するのを待っていて、在庫が復活した日に注文しました。その日の夜には売り切れていたので、トラックボール一体型のキーボードを求めている人が結構いるのかもしれません。

買ったもの

キースイッチはPlanck Keyboardに取り付けていて静音性に安心感のあるGateron Ink v2 Silent Blackを使用しました。

キーキャップもPlanck Keyboardのときにお世話になったTALP Keyboardのブランクキーキャップを選びました。あらたにアプリコットのキーを買いましたが、色味がかわいいので気に入っています。

写真にはシルバーのロータリーエンコーダ用ノブが写っていますが、これは寸法的に取り付けられず誤って買ってしまったものでした。ロータリーエンコーダにノブが付属しているので今のところは困っていません。

商品名	個数	単価(円)	小計(円)
【委託】cocot46（トラックボールモジュール付き）	1	16000	16000
ロータリーエンコーダ 24クリック / プッシュスイッチ付き / 高さ20mm (EC12互換品)	1	330	330
XDA PBT ブランクキーキャップ (ホワイト/2個)	19	110	2090
XDA PBT ブランクキーキャップ (アプリコット/2個)	4	110	440
XDA PBT ブランクキーキャップ (グレー/2個)	4	110	440
Gateron Ink スイッチ v2 (10個入り) Silent Black	5	1320	6600
TALP KEYBOARD キースイッチ 10個以上購入で5%オフ			-95
TALP KEYBOARD 送料			300
合計			25805

40%だからということもありますが、結構安い気がします。特にcocot46のキットは、同梱されていたパーツが多かった割に値段が安かったように思います。

組み立て

組み立てはビルドガイドの通りに素直に進めました。チップ抵抗を途中で机の下に落として探す工程が一番難しかったです。

組み立てたのちに、Google ChromeからREMAPを開いてファームウェアを書き込み、その後REMAP上から配列の設定などを行いました。

こだわり

配列

基本はPlanck Keyboardに設定していた時のものを踏襲し、QWERTY配列でレイヤを4つ配置し、うち3つを普段から使うものとしました。配列には以下のようなこだわりを含んでいます。

矢印キーはレイヤーキーとhjklの同時押し (Vimライクな配列)
macOSの絵文字入力ウィンドウ用キー (Ctrl + Cmd + Space) を配置
macOSのウィンドウ切り替え用ショートカット (Ctrl + ↑) を配置

cocot46はロータリーエンコーダを回転させるとPageUp, PageDownが入力される配列となっており、ロータリーエンコーダを回してスクロールするのが楽しいです。

PageUp, PageDownでは移動幅が大きすぎるときのために、Karabiner Elementsを使って、ロータリーエンコーダを押し込んだときはトラックボールの移動がスクロール入力になるような設定を追加しています。

ref: Change mouse motion to scroll (rev 3)

ケーブル

Pro MicroとPCの接続にはマグネット式で着脱できるUSBケーブルを用いています。ケーブルの脱着が楽になるだけでなく、力がかかると外れる特性を活かして端子の保護としても働いています。

ホームポジション

ブランクキーキャップのみで構成されていてホームポジションを示す突起がないので、ひとまずマスキングテープを貼り付けて、触り心地だけでホームポジションがわかるようにしました。色味が外側のキーと似ていて満足しています。

改良したいところ

以下の気になる点をファームウェアや配列やキーキャップに手を入れて、より気に入った環境をつくっていこうと考えています。

レイヤーキーの反応時間/反応順

レイヤーキーと同時押しで入力する- (ハイフン) が、押下タイミングの癖で、デフォルトレイヤーのc が入力されてしまうことが多いです。おそらく親指(レイヤーキー)の押すタイミングが遅いまたは離すタイミングが早いことに起因して、素早く入力するときにうまくデフォルトレイヤー外のキーを押せないでいます。

過去に他のキーボードでファームウェアに手を入れて解決したような気がするので、思い出したら同様の処置をしようかと思っています。(対策前に慣れる可能性もありそうです)

左クリック/右クリックのキーの差別化

トラックボールを触りながらだと左クリック/右クリックキーを他のキーと押し間違えるので、高さの違うキーキャップに変えるなり位置を変えるなりしようか考えています。(これも対策前に慣れる可能性もありそうです)

最下段のキー配列の見直し

現在の配列は、右下に配置したウィンドウ切替用の Ctrl + ↑キーと、その隣ののBack Spaceキーを押し間違えがちです。押し間違えても影響が小さくなる/押し間違えずに済むように、最下段のキー配列を改めて考え直そうと思っています。

おわりに

トラックボール一体型のキーボードは、手首の移動距離を短くしたり机上をスッキリさせたいという思惑がありました。このどちらも満たせたので嬉しいです。まだ使い慣れていないので、しばらくはcocot46で生活していこうと思います。

(この記事はcocot46で書かれました。)

歳をとった

Mon, 16 May 2022 17:25:00 GMT

先月誕生日を迎えて歳をとりました。

干芋で祝ってくださった同期の方々、ありがとうございました！送っていただいてから少し時間が経ってしまっているものもありますが、感謝をこめて紹介します。

ちいさめの水筒。社の食堂でのみものを入れるのに重宝します。蓋がしっかりついているので変にこぼしたりする不安もなくてとてもよいです。

レンジでパスタ。4人前まで一気に茹でられる大きいもので、パスタを茹でる時に鍋を使わなくていいのがよいです！パスタは簡単に素早くつくれるので、リモートワークのお昼になりがちです。 2個あるので8人までいけます！(そんなには茹でない)

人に頼む技術。こういうことができるようになると、仕事をよりうまく回せるようになりそうでよいなあと思います。

シェル・ワンライナー160本ノック。シェル芸に憧れがあるので、身につけていきます！

ホットプレート/たこ焼き器。これのおかげで新居でたこ焼きができるようになりました！同期を呼んでタコパをしたい。

たこ焼きはシャバシャバの液で、一面溢れるくらいに流して作るとまんまるになることを学びました。写真にあるのはちょうど今日日曜日の夜に食べたものですが、家で作ったたこやきのなかで相当上位の出来 (形) だと自負しています。

オレオ (箱買い)。美味しいですよね、オレオ。箱買いでたくさんあるのでしばし安泰かと思いきや結構なスピードで食べてしまっていてもう残り半分を切っています。

クリーニングブラシ。机の上、モニター周りにほこりがたまりがちなのでこれで綺麗にします。

焼き芋メーカー。ちょっと気になっていたものだったんですが、コンセントにつないで放置するだけで焼き芋ができる面白いものです。

べにはるかを買ってつくってみたら、しっとりやわらか食感に仕上がって、蜜が飛び出てきてとても美味でした。

Kubernetes完全ガイド。Kubernetesなんもわからんので勉強します..

Clean Architecture。業務のアプリケーションに触れるようになってから、設計めちゃ大事だなという気持ちを強くしているので、学びます。

昨年の1年は就職したというのもあってやはり仕事のことが印象に残っています。がむしゃらでやらないとどうしようもないところもあるのですが、今年はプライベートも充実させられるよう、うまく物事をコントロールできたらよいと考えています。

秘匿情報を含む.bashrcを分割する

Sun, 10 Apr 2022 19:52:00 GMT

dotfiles(ドットで始まる設定ファイル)の管理のために、Gitリポジトリを作成しGitHubにdotfilesという名前で公開するときに注意すべきこととして秘匿情報の扱いが挙げられます。

秘匿情報が .bashrc に含まれているとき、それをそのままGit管理してGitHubに公開することには問題があります。ここでいう秘匿情報とはGitHubのパーソナルアクセストークンやAWSのアクセス用シークレットキーなどの認証時のパスワードの代替となるようなものをはじめとする、他の人に見せてはいけない情報のことです。

こういった内容を含む.bashrcは分割し、秘匿情報の含まない部分のみGit管理下に置くのがよいでしょう。

今回は以下のような~/.bashrcがあったとき、秘匿情報の含む部分と含まない部分に分割する手法を紹介します。

# ~/.bashrc

# 秘匿情報
GITHUB_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

# 秘匿情報以外の記述
alias his="cat $HISTFILE | grep"

このファイルを秘匿情報の含む~/.bashrc.localと秘匿情報の含まない~/.bashrcに分割します。さらに、秘匿情報の含まない~/.bashrcは、秘匿情報の含む~/.bashrc.localを内部で読み込むようにします。

# ~/.bashrc-private

# 秘匿情報
GITHUB_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

# ~/.bashrc

# 秘匿情報を読み込む
source ~/.bashrc.local

# 秘匿情報以外の記述
alias his="cat $HISTFILE | grep"

sourceはBashの組み込みコマンドのひとつで、指定したファイルを読み込みカレントシェルで実行します。この例で言えば、sourceコマンドが書かれている部分に~/.bashrc.localの内容が書かれているのと同じ動きになります。

こうすることで、~/.bashrcはGitリポジトリに含めて公開しても問題ない状態になりました。 source ~/.bashrc.local という記述から何らかの情報を読み込んでいることはわかりますが、その中身が何であるかは.bashrcを読んでもわかりません。

この記事に従って秘匿情報を分割した場合、以降~/.bashrc.local は公開せずに手元の環境に留めておくようにしてください。

なお、今回のような.bashrcの分割は秘匿情報に限らず他のことにも応用できます。特定のOSのみ指定したファイルを読み込むようなif文を記載すれば、設定をOSによって切り替えることも可能です。

神奈川県民から埼玉県人へ

Thu, 31 Mar 2022 14:13:00 GMT

2年ほど実家に戻っていましたが改めて引っ越し、神奈川県民から埼玉県人になりました。ちなみに神奈川では県"民"と言うけれど埼玉では県"人"と言う気がします。なんででしょうね？

会社への通勤時間はおよそ1時間といったところで、引越し前と比べたらだいぶ近くなったので時々通うのにちょうどよい距離かなと思っています。

🎉

単なる引っ越しにお祝いを頂いてしまいました。ありがとうございました🙏この場を借りて感謝をお伝えします。

タオル。タオル研究所というところのものらしく同期の欲しい物リストで見つけて気になっていたもの。結構ふわふわで良さげです。最近はバスタオルをやめて家のタオルをすべてフェイスタオルに統一してます。
キッチンハイター。強い。
カントリーマアム。考え事をすると糖分が欲しくなります。一袋開けると一気に食べてしまいます。
洗濯用ハンガー、ちょこちょこ乾燥機NGな服があって重宝します。
延長コード。机からコンセントが離れているので、Macbookや液晶など諸々を繋ぐのに使います。5mあるので安心😆
デスク下マット。フローリングの上に椅子のキャスターが当たらないようになります。マットが広くて悠々と椅子を動かせるようになりました。

これは埼玉に突如出現した津田沼¹

荷物を運ぶ

荷物の移動はクロネコヤマトの単身パックを利用しました。冷蔵庫電子レンジと身の回りのものを積み込んで3万円弱だったと記憶しています。

上の写真の荷物を積み込んでもらって、残ったのは積みきれなかったダンボール2つ。これとリモートワークで直前まで使うオフィスチェアとモニタとを宅急便で別送しました。(4つで7000円弱) 実家から出るので荷物が少なめで、単身パック+宅急便はわりとよい選択だったと思います。²

机、ベッド、洗濯機などは引越し先で購入しました。いろいろお金がかかるので金銭感覚が若干おかしくなります。

住民票と書類手続

一般に住民票を移すのには旧自治体への転出届と新自治体への転入届が必要です。しかしながら私の住んでいた旧自治体には「マイナンバーカードまたは住民基本台帳カードによる転出の特例」という制度があり、マイナンバーカードを使ってWebから転出届が出せました。平日に役所に行く手間が省けて大変助かりました。

引っ越したあと新自治体の市役所への転入届と警察署への免許証住所変更に行きましたが、これらはフレックスタイム制を活用して出勤前にサクッと手続きできて社の制度に感謝でした。こういうたぐいのものは書類を書いて窓口に向かうので、開店時間のちょい前くらいに行くのがちょうどよいかもしれません。(開店時間に行ったら先客がいました)

ドラム式洗濯機

引っ越しに合わせてドラム式洗濯機を買いました。洗濯機は社会人になったらドラム式を買おうと決めていて、20万円ほど払ってPanasonicの洗濯機 (NA-LX113AL) を購入しました。たかい。

ヒートポンプ式とヒーター式

洗濯機は買うにあたって事前にちょこちょこ調べていました。

ドラム式洗濯機にはヒートポンプ式とヒーター式という2種類があるそうです。

ヒートポンプ式は

本体代が高め
電気代は安め
エアコンで使われるようなヒートポンプが洗濯機内に入っていて、衣類に当てた風を冷やして乾燥させ、暖かくして再度衣類に吹き付けるらしい
衣類が傷みにくい

ヒーター式

本体が安め
電気代は高め
ドライヤーを当てるように、衣類に直接熱風を当てるのでしっかり乾く
衣類が痛みやすい
湿気を含んだ空気が排出されて室内に充満しやすい

という特徴があるそうです。どうせならということでちょっと高いですがヒートポンプ式を選びました

洗剤の自動投入機能がつくと一気に値段が跳ね上がるらしく、そういうのがついていない洗濯と乾燥だけのベーシックなモデルで乾燥容量の多いものを選びました。

調べていると季節によって大きく値段が変わるらしく、もし買えるなら秋頃などの新製品発売前だと安く買えるそうです。

ドラム式洗濯機を買ってから、家の中の乾燥不可の布を見るたびに悔しい気持ちが芽生えるようになりました。もっとも、私の買った洗濯機は音も静かで洗濯乾燥容量も大きく、乾燥後の触り心地もよいので大満足です。

インターネット

リモートワークで働いている私にとって、インターネット回線の品質は死活問題です。話すと長くなりそうでここでは割愛しますが、現在はケーブルテレビの回線と楽天のLTE回線を使っており、後日フレッツ光も利用できるようになる予定です。まあまあ調べた ³ のでどこかにまとめておきたい気持ち。

そんなこんなで引越しから1ヶ月近く経った今でもダンボールをテレビ台代わりにしていたりするものの、ぼちぼち新生活が始まりました。家の周りにまだ慣れていなくて駅との往復くらいしかしてないですが、散歩したりして愛着が湧いた土地になるとよいなと思います。

机下用のマットを欲しいものリストに設定していたら「マットの上は津田沼だと思って生活してください」と託されました。最近は心のなかで机の周りのことをひそかに津田沼と呼んでいます。埼玉にも海ができたといえるでしょう。 ↩
引っ越しの見積もりをWebで申し込んだら大量に電話がかかってきて疲弊しました。疲弊して嫌になったので金額がわかりやすい単身パックにしたという節もあります。 ↩
IPv4 PPPoEとIPv4 over IPv6 を同時に接続して、外部からDMZへの通信はPPPoEで、内部から外部への接続はIPv4 over IPv6でやれるような構成しようと目論んでいます。 ↩

Web Components (ShadowDOM) でもページ内リンクをしたい

Thu, 31 Mar 2022 04:01:55 GMT

HTMLではページ内リンクができる。 id属性ないしname属性で指定した文字列を # ¹ の後ろにつけてリンク先のパスとして指定すると、当該の要素が画面上部に来るようにスクロールする。

<p id="content">
  hello!
</p>

<p style="height: 2000px; background-color: red;">
  blank
</p>

<a href="#content">
  「hello!」へ飛ぶ
</a>

このページ内リンクをShadowDOM内の要素からShadowDOM内にむけて行いたいとき、そのままではできない。同じような動きを実現する方法として、クリックイベントをもとにShadowDOMの中の要素を探してJavaScriptによってスクロールする動作を実装してみた。

const eventListener = (event: Event) => {
  const element = event.target as HTMLElement
  if (element.tagName !== 'A') {
    return true
  }
  const href = element.getAttribute('href') ?? ''
  if (!/^#/.test(href)) {
    return true
  }
  const anchorName = href.substring(1)
  const theNameElements = shadowRoot.querySelectorAll(`[name=${anchorName}], #${anchorName}`)
  if (theNameElements.length > 0) {
    theNameElements[0].scrollIntoView()
    event.preventDefault()
    return false
  }
  return true
}
shadowRoot.addEventListener('click', eventListener)

このブログの記事の本文はいま本文用のCSSのスコープを狭める実装の一つとしてShadowDOMに包むようにしていて、上記のようなコードを書くことでページ内リンクのスクロールを実現している。単純な実装なので何か考慮できていない場合をみつけたら教えていただけると嬉しい。

実装: https://github.com/yammerjp/memo.yammer.jp/blob/7bed6bc062217d7c7d16ab0a39821987e3dd3f45/src/components/article.tsx#L8-35

ちなみにこの # を使ったページ内の特定の要素を表す機能はHTMLの仕様書内ではフラグメントと呼ばれているらしい。 ↩

リバースSSHトンネルでVPSを介していつでも自宅のPCに繋ぐ

Thu, 24 Feb 2022 13:15:00 GMT

外出先で手元のラップトップ (MacBook Air) からポートを公開していない自宅のサーバ¹ (Ubuntu) へsshしたいときの記録。数ヶ月くらい前から安価なVPSを借りて、そこを中継地点として外出先からいつでも自宅のサーバにsshできるようにしている。

ひとまず繋ぐ

以下の接続ができるようにしておく。

ラップトップの公開鍵を自宅サーバとVPSに、自宅サーバの公開鍵をVPSに登録 (~/.ssh/authorized_keys に追記) して、sshできることを確認する。

自宅のラップトップ -> 自宅のサーバ
自宅のラップトップ -> VPS
自宅のサーバ -> VPS

`~/.ssh/config` on ラップトップ

中継するVPSとその先の自宅サーバへの接続情報を書いておく。

# ~/.ssh/config
Host home-server
  HostName 192.168.2.3
  IdentityFile ~/.ssh/id_rsa
  User home-username
Host bastion-vps
  HostName bastion-vps.example.com
  IdentityFile ~/.ssh/id_rsa
  User vps-username
Host home-server-remote
  Hostname localhost
  User home-username
  IdentityFile ~/.ssh/id_rsa
  ProxyJump bastion-vps
  Port 2222

`~/.ssh/config` on 自宅サーバ

中継するVPSへの接続情報を書いておく。

# ~/.ssh/config
Host bastion-vps
  HostName bastion-vps.example.com
  IdentityFile ~/.ssh/id_rsa
  User ubuntu

繋いでみる

自宅サーバからVPSへsshして、VPSの空きポートから自宅サーバのsshポートへリバーストンネルを張る。

# user@home-server
$ ssh -fN -R 2222:localhost:22 bastion-vps

この状態で、自宅サーバと異なるネットワークに所属するラップトップからsshをする。

# VPSの22番ポート、2222番ポートを伝って自宅サーバへsshする
$ ssh home-server-remote

多段sshの際にラップトップの秘密鍵を使う利点は、自宅サーバに入るための鍵をVPSが保持していないこと。仮にVPSにログインして自宅サーバのSSHポートにパケットを送れる状態になったとしても、自宅サーバへsshできる秘密鍵を持たなければ自宅サーバは乗っ取れない。

サービスとして登録する

自宅サーバのsystemdに登録して、常にリバーストンネルが貼られている状態を維持する。

まず、ファイル /lib/systemd/system/bastion-tunnel.service に以下を記述する。

[Unit]
Description=Create SSH reverse tunnel (reverse port forwarding) from bastion-vps.example.com
After=network.target

[Service]
Type=forking
ExecStart=/usr/bin/ssh -f -NT -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -i /path/to/id_rsa -R 2222:localhost:22 vps-username@bastion-vps.example.com
RestartSec=3
Restart=always
StartLimitBurst=0

[Install]
WantedBy=multi-user.target

作成したServiceを有効化する。

$ sudo systemctl daemon-reload
$ sudo systemctl enable bastion-tunnel.service
$ sudo systemctl status bastion-tunnel.service

常にリバーストンネルが貼られていることをsshして確認してみる。

おわりに

以上の手順を踏むと、自宅のIPがわからなくても、ポートを公開していなくても、いつでもVPSを経由してsshできる。自宅サーバの中で作業をしておけば外に行ってもiPadから作業を続行できたりするし、外で特定のファイルが欲しくなったりx86_64のLinux環境が欲しくなったときにそこそこのスペックのものをサッと使えるのもいい。ふとしたときに便利。

今はsshのみをトンネリングしているが、他のプロトコルもポートフォワーディングして使うと便利そう。(認可周りは別途検討が必要そう)

サーバといってもインターネットに公開・提供しているわけではなく、適当なものをビルドしたり作業したり宅内向けのアプリケーションを一時的にホストしていたりする自分用の常時起動Linuxマシンである。 ↩

Ruby製のCLIを作ってgemにしてみる

Wed, 09 Feb 2022 13:20:00 GMT

会社に入ってからRubyを触る機会がちょこちょこあるが、Rubyのことをあんまりわかっていないという感覚があるので機会をみつけてRubyで何かをつくるというのをやっていきたい。今日はその中でファイルの文字コードを確認する処理をCLIとして実装してみた話。

作ったもの

実装するものは比較的シンプルで、渡されたファイルが指定された文字コードで解釈できるか否かを判定する。¹ Rubyのワンライナーで書くこともできる規模感のものだ。

$ find path/to/dir -type f | ruby -e 'STDIN.reject{|path| IO.binread(path.chomp).force_encoding(Encoding::UTF_8).valid_encoding?}.each{|f| puts f}.empty? or (puts "... There are invalid encoding files";exit 1)'

手元のファイルを確認するだけならワンライナーでいいが、一応テストを書いて動作が明らかであることを示したり、なによりRubyのライブラリってこんな感じで作るんやでというのを知っておくためにCLIとして実装してgemにしてみた。

https://rubygems.org/gems/file_charset_validator

さっきのワンライナーと同じことを以下で行える。

$ gem install file_charset_validator
$ find path/to/dir -type f | file_charset_validator --encoding UTF_8

CLIを作ってgemにする手順

新しくRubyでCLIを作るのは雛形が用意されていて、以下のコマンドを実行するとディレクトリごと作ってくれる

$ bundle gem your_gem_name -t -b
# -t ... テストも生成
# -b ... 実行ファイルも生成

作ったgemのビルドやローカルへのインストール、公開などもrakeタスクが用意されているのでシュッとできる。

# gemをビルドする (gemはhogehoge.gemという単一のファイルにまとめられるらしい)
$ bundle exec rake build

# テストを実行する
$ bundle exec rake test

# ローカルにgemをインストールする
$ bundle exec rake install

# gitのリリースタグを打って、gemを公開する
# 事前に https://rubygems.org でアカウントを作り、`$ curl -u YOUR_USERNAME https://rubygems.org/api/v1/api_key.yaml > ~/.gem/credentials` などとしておくとRubyGemsに公開できる。
$ bundle exec rake release

コマンドライン引数やヘルプコマンドの出力などはthorに任せてしまうと楽。作った雛形の your_gem_name.gemspec に spec.add_dependency "thor" などと書いて bundle install して、Thorクラスを継承したクラスを実装し、.start を呼べばいい。

感想

お作法がわかっていないので作りたいものを作る時間よりもお作法を学ぶ時間がほとんど出会ったが、目的はそれなのでよかった。 RubyGems、(npmに比べて) パッケージの名前空間が比較的空いている気がして、不用意に変な名前を占有してはいけないなという気持ちになった。

おわり。

文字コードの判定は例えば $nkf --guess コマンド等でも行えるが、誤検知を避けて「ある文字コードとして解釈できるかを検証する」という目的を果たすツールは見つけられなかったので作った。いろいろなところで必要そうなので見つけられていないだけで多分どこかにあるでしょう。知っている方は教えてください。 ↩

graspad - iPad用の握れるキーボード

Wed, 26 Jan 2022 14:41:00 GMT

昨年秋¹に3Dプリンタを買って作りたかったのがiPad用のキーボード。 iPadケースの背面にキーボードがくっついていて、iPadを横から握ったまま物理キーボードを打てる。

左右の2パーツから成っていて、iPadの左右から差し込み、2つをつなぐ配線とiPadのType-Cをつなぐことで使える。

キー数は42キーで、3x6のキーが背面の左右に、親指で押す用の側面のキーが3つずつ左右にある。

本記事では、この少し変わったキーボードの製作過程を記す。

設計

着想

iPadに物理キーボードを使いたいと思っていたのだが、普通のキーボードを繋ぐだけでは安定した机の上でしか使えないし、それならMacbookで代用できてしまう。電車の中やベッドやソファでゴロゴロしながら物理キーボードが使えたらいいなと思って、iPadを横持ちで握ったままキー入力が出来ることを目指して作った。

制作に当たって以下のような製品を参考にした。

Nintendo Switch
VAIO Type U
T-BLADE
Yogitype
LAVIE MINI

最初は思いつきだったが、3Dプリンタが案外やすく買えることに気づいてしまってからは割と勢いで完成までこぎつけた。

キー配列

キー数を42キーにするのは結構初期の段階で決めていた。普段使っている配列と同程度で、今の私の中で実用に耐えうる最低限のキー数である。これより少ないのは未知の領域。

キー数をもとに、iPadのケースにキーボードが付いていたらという体で考えてみる。適当な図を書きながらこんな感じでは？と構想をふくらませたのが以下のスケッチ。この時点で概ねの形は決まっていた。

寸法をみていくと、キーの数と配置からキーピッチを抑える必要があることに気づいた。 iPadの大きさは176mm x 248mm、横持ちをするとすると高さ方向に176mm以下に抑えなければならない。 176mmの方向に並べるキー数を、下から6(裏面)+3(側面)-1(裏面上段と側面下段を重ねる)とすると、キーピッチ20mmでは160mmで結構ギリギリである。iPadの側面には電源ボタン、上部にはカメラなどがあり、Apple Pencilを上部に配置することにするとこれでは高さが足りない。挟ピッチの16mmとすると16mm x8=128mmとなってだいぶ余裕が出るのでよい。

PCB

キーボードのスイッチを固定、配線する基盤をどうするか考える。挟ピッチで格子配列となるとmcsp lp²というキーボードを改造するか、専用の基板を作るか、基盤無しで3Dプリンタで作った筐体にマウントするかなどを考えてたが、途中でte96という素晴らしいキットに出会う。 te96は分割後に再構成できる自作キーボード用のPCBで、row-staggeredやcolumn-staggered、格子配列などの形に自由に組み立てられる。キーボードのピッチ幅も1方向は16mm-20mmの可変で、組み立て時に自分で決めることができる。今回の用途にぴったりで、16mmピッチの格子配列、親指部分も切り取って別基盤として用意できるのでとても都合の良い基盤だった。

ケースとキーボード筐体の一体化

当初は市販品のiPadケースに3Dプリンタで作った筐体を貼り付けることを想定していたが、組み立ての手間を減らすため、ケースとキーボード筐体を一体型にしてまとめて印刷するよう針転換した。しかしながらこれは後から思えば良くない判断だった。筐体を構成する樹脂のPLAは硬くしなりづらい素材で、iPadのケースにしようとしても、少し出っ張らせてパチっとはめ込むような構造にし難い。しならずともiPadにつけられるよう、左右から差し込む構造とすることが決定し、あわせて左右をまたぐ配線をコネクタで繋ぐ必要が出てきてしまった。さらにコネクタを経由する配線を減らそうとして、Pro Micro(と互換機)を計2台使うことにもなった。

iPadの大きさとiPadケースのモデリング

今回の題材であるiPad Air 4をはじめとするApple製品は、公式にその寸法を示したガイドラインが公開されている。 (Accessory Design Guideline for Applie Devices) これをもとに、0.1mm程度の精度で設計、印刷した。ケースの大きさはガイドラインに示されているiPadの寸法よりも余裕を見て少し大きくする必要があり、これは試作を繰り返して決定した。試作には上部ないし下部のみで30時間くらい印刷にかかるので結構面倒な作業であった。

組み立て

使用部品

部品	点数	補足
フィラメント PLA 黒 1.75mm 1kg	2	試作一回 (筐体半分) につき300gくらい使用した
te96	2
Kailh Choc 赤軸	42	なるべく薄くするためにKailh Chocを選んだ。赤軸のキースイッチが手元に丁度2個余っていたので40個買ってピッタリ使った。
mcsp lp向け挟ピッチキーキャップ	42	Kailh Choc用の16mmピッチで使えるキーキャップは他に選択肢がなかった。DMM.makeで3Dプリンタによって印刷されたものが届いた。相当力を入れないとキースイッチに刺さらないので、同じものを購入される方は注意されたい。
ジャンパケーブル	8	左右の筐体間をつなぐコネクタとして使っている
はんだ		0.3mmなどの細いものを用意しておくとやりやすい
導線		PCB間 (親指部分との配線)や、PCB内でも各columnとPro Micro間を導線で配線する必要がある
スズメッキ線		te96のrow同士の配線に使った
Pro Micro、Elite-C	1ずつ	左右の筐体に一つずつ使うが、iPadとの接続はUSB Type-Cで行うので、下の Type-C to Type-C ケーブルが使えるように片方はPro Micro互換のElite-Cを使うこととした
UGREEN USB Type-Cケーブル	1	片方がL字になっていて、長さが50cmで長すぎないType-C to Type-Cのケーブル。

組み上げ

筐体を印刷し、次にキーボードを組み立て、最後にそれらをはめこんでから一部配線をしてキーマップを書き込む、という手順で行った。

キーボードはマニュアルにあるような感じで組み立てていく。キーピッチは16mmになるように、最狭間隔で固定する。

ピンヘッダを差し込んで基盤を接合するときは、裏にマスキングテープを貼って出っ張らないようにするといい。

基盤同士が接合できてテスターで導通を確認したら、ダイオードとキースイッチ、PCB内の配線、Pro MicroとElite-C、PCB間の配線をはんだ付けしていく。

キーキャップをはめてキーマップを書き込み動作確認する

最後に筐体に組み付けて完成。

PCBの筐体への固定は、PCBにある2.15mmの穴に筐体の突起を差し込む方式とした。これは試作を繰り返す中で思いついた。また、複数の基板を接合する際に間隔が開いて寸法がずれて差し込めなくなるのを防ぐために、筐体の一部を切り取ったような治具を印刷し、この上で組立を行っていた。

親指のキー部分は、キーボードを差し込むための筐体側の突起のある台座を別部品として印刷して、筐体本体に差し込むこととした。印刷方向の兼ね合いで、突起を水平方向に空中に印刷するのが難しいためである。

ちなみに各パーツの固定が甘かったので瞬間接着剤を流したら分解できなくなった。接触不良などが発生しても直せなくて困る。悲しい。

キーマップの書き込み

こちらもマニュアルを参考にセットアップした。

途中から、ProMicroだけでなくElite-Cにも書き込む必要が出てきたので、以下のようなコマンドで書き込みを行なった。 ProMicroに書き込む際は、リセットボタンの代わりに RSTとGNDをショートさせていたが、Elite-Cは何もしなくても勝手に書き込みが始まった。(と思う)

https://github.com/yammerjp/qmk_firmware/commit/ce2a69222718b825d787d52fd7ad7476862ec417 に私のキーマップを置いている。

# Pro Micro
$ sudo make e3w2q/te96:test:avrdude
$ sudo make e3w2q/te96/rev1:yammerjp:avrdude
# Elite-C
$ sudo make e3w2q/te96:test:dfu
$ sudo make e3w2q/te96/rev1:yammerjp:dfu

(次回作があったら)改善したい点

te96組立時にショートさせない

te96の基盤を切り刻んで、ピンヘッダと接合部品を用いて繋げるのだが、そのときに意図しないショートに注意。特に16mmピッチにする場合は、外側に17-19mmピッチ用の穴があり、誤ってこれが基盤の近くにあるCherry MXの穴とぶつかるとrowとcolumnが導通してしまいキーボードとして機能しなくなる。 (やってしまってむりやり分解した。)

Cherry MXの穴は接合する基盤の片側にしかないので、ショートしないように接合部品を配置すべきだった。

分解可能性を高める

試作を繰り返す中で加えた修正に、キーボードの固定方法がある。 te96には直径2.15mmの穴が複数箇所に開いており、この大きさに合わせた特記を筐体に用意して差し込むことで固定することとしようとした。はめ込むだけで済むようにしたかったが、実際にはゆるゆるだったので瞬間接着剤で固定した。これにより分解がしづらい状況となってしまったので、瞬間接着剤ではなくネジで固定できる構造とすると問題が起きても修理しやすくなっただろう。

左右の筐体を接合するコネクタの改善/廃止

キーボードをiPadに装着する際、2つの筐体をはめこんでコネクタを繋ぐ必要がある。ここに2.54mmのピンヘッダ用のコネクタを使ってしまっているので、極性に気をつける必要があるし気軽につけ外しできない。マグネットでくっついたり無線で通信したり、そもそも筐体が2分割されていないと嬉しい。

キーボードを背面ではなく側面に配置する

作ってみてわかったのだが、タイピングできる速度はびっくりするくらい遅い。慣れの問題だろうと思っていたがそれだけではなく、構造に問題がありそうである。

iPadの背面にキーボードがあると、筐体の重さを手で支えているおかげか手の平を胸方向に向けるからか手に遊びがなく、キーが押しづらいと感じる。手の筋肉の弛緩を見誤ったのがまずかった。

これを解決する方法として、iPadの側面にキーボードを配置して"前ならえ"したような体勢で打てるようにしたい。

CherryMX互換キーキャップ

キーストロークが深い方が気持ちいいのでは。

おわりに

動作するところまでは持っていけた。 3Dプリンタの精度が案外高くて、筐体もそれなりの形で作れたように思う。椅子の上で使ったりベッドの上で寝転がって使ったりすることもできる。 (タイピング速度は遅いが...笑)

ちなみに何回か試行錯誤したのでこれくらい失敗した筐体がある。

以上、というわけで次回作にご期待ください。なおいつ作られるのかは未定です。

前回の記事も含めて10月ごろに書いた文章が眠っていたので引っ張り出してきた。 ↩
mcsp lp というキーボード、今回の製作に関係なく結構気になっています。欲しい。 ↩

2021年に3Dプリンタに入門した - Anycubic Mega S

Wed, 26 Jan 2022 14:40:00 GMT

昨年の秋に3Dプリンタを買ったので、その経緯と3Dプリンタに入門して学んだことを記します。

サンプルを印刷してみる pic.twitter.com/hdrNYcBRn7
— やんまー (@yammerjp) September 20, 2021

作りたいものがあって、3Dプリンタの印刷サービスを検討していたが高すぎたのが事の発端です。作りたいものの寸法が大きかったため依頼すると2万円くらいするとわかり、更に安価な3Dプリンタ本体が2-3万円くらいで入手できることがわかり、これは試してみてもいいのではという気持ちになりました。¹

3Dプリンタを選ぶ

家庭用3Dプリンタには光造形方式と熱積層方式があり、今回は熱積層方式のものを購入しました。前者は印刷可能サイズが小さいが精巧で模型などに向き、前者は印刷可能サイズが大きいが精巧さに劣るのでDIYなどに向くという違いがあります。精巧さで劣ると言っても結構いい感じに作れます。(後述の写真を参考に)

熱積層方式のプリンタの中でも安価な家庭モデルでメジャーなものとして、Ender 3 Pro、Anycubic MEGA S、Flashforge 3、といった機種が挙げられます。このなかでも前者のほうが安価、印刷可能サイズが大きい、カスタマイズ幅²が広い、組み立てが大変、といった特徴があるようです。

印刷したいもののサイズと価格面からFlashForge ³が消え、組み立て部位が多いと精度が担保しづらいのではないかという不安からEnder 3 Proを避けることとし、Anycubic Mega S を選びました。昨年と比較してセール含め1.5万円くらい値段が下がっているらしいことも、この選択を後押ししました。

Anycubic Mega S の積層可能範囲は 210mm x 210mm x 205mm で、そこそこ大きいと思います。大きいものを印刷すると結構時間がかかるので、この範囲に収まらないものは組み立て式にしたり3Dプリンタの印刷物は一部の部分のみに使うなど、工夫してものをつくるとよさそうです。

フィラメント

熱積層型の3Dプリンタでは、樹脂を熱で溶かしながら射出して印刷します。その樹脂がフィラメントです。

フィラメントを選ぶ上での軸はいくつかあるようですが、最初でよくわからないのと失敗したくないのでなるべくメジャーっぽいもの、PLAの太さ1.75mmで黒1kg、安すぎず品質管理されてそうなものを選びました。 (特に問題なく印刷できたので、使い切った後も同じものを買い足しました。 https://www.amazon.co.jp/gp/product/B084S9NP2T/ref=ppx_yo_dt_b_asin_title_o09_s00?ie=UTF8&psc=1)

フィラメントは材質がいくつか選べるようですが、PLAやPLA+が簡単に印刷できます。この材質は硬く印刷後の整形に向きません。強度の高く加工しやすいABSなどを選ぶ手もありますが、こちらは熱変化による収縮が大きく、印刷が失敗する可能性が上がるので最初は選ばないほうがよいようです。フィラメントの量は 1kgや3kgが一般的なようです。3Dプリンタによってはあまり大きすぎるリールはフィラメント台に置けない可能性があるので、自分の3Dプリンタの機種で問題ないかを確認しておくとよいでしょう。フィラメントは品質もある程度気にする必要があるらしく、あまりに安くて質の悪いものだと、フィラメントの太さが均一でなく、ノズルに詰まって印刷に失敗したり印刷が汚くなることがあるらしいです。

慣れてきたらここら辺を変えてコストを抑えたり印刷物の特徴に合わせた材質にしたりということができるようです。

ネット上では一部Anycubic Mega Sにはフィラメントが1kg付属すると書いてあるレビューもありましたが、私の場合は数十gのおまけだけで付属しませんでした。同じ機種を買われる方は特に、最初からフィラメントも同時購入するとよさそうです。

組み立て

Anycubic Mega Sはゆっくりやっても数十分で組み立てることができます。台座に印刷ヘッドを含む上部を差し込んで数カ所ネジ止めし、フィラメント台もネジ止めします。

印刷台の調整

熱積層式の3Dプリンタは、印刷前に印刷台とヘッドの間の間隔が一定になるよう、印刷台を調整する必要があります。

ヘッドと印刷台を傷つけないようにA4のコピー用紙を印刷台に置く
電源を入れる
念の為モータに電流が流れていない状態にする。タッチパネルから、Setup > Motor (off) > Done!と出るとよい
手動でヘッドと台座を動かして、調整場所まで移動する。左手前側の角に近いところで、ヘッド先が下がったときに台座の平面からはみ出ない位置の範囲で動かす。
タッチパネルから、Tools > Home > Home Z とするとヘッドが自動で下まで下がる
印刷台下の手回しネジを回して高さを調整する。コピー用紙を動かそうとすると少し抵抗があるが力を入れれば動かせるくらいが良い。どのくらいの力で動くかを手で大体覚えておく。紙の動かす方向は水平の一方向にまっすぐもありだし水平のヘッドを中心とした回転方向に引っ張ってみるのもよい
左手前が調整できたら、ヘッドを手動で動かして右手前、右後ろ、左後ろも同様に調整する。終わったらまた右手前、左手前、、と納得行くまで繰り返す。（1周やって戻ってくるだけと紙がスルスル動く状態になっていたりする。)最後に印刷台中央のヘッドとの間隔が同様であることを確認する。
タッチパネルから、Tools > Axis > 10 (+Z) を10回押すとヘッドが上がる

ひとまず、印刷を終わるごとにやっています。 Youtuberのイチケンさんの動画ではそんなに頻繁にやらなくても良いと語られているので、それほどずれないとわかったらやらなくて良いかもしれません。

ちなみにこの動画、とてもよくできていて3Dプリンタを買う前にイメージを掴むのに大変役立ちました。

印刷してみる

印刷のためには以下の2つのソフトが必要になります

3D CAD

印刷物の3Dデータを作成するのに必要です。インターネットから印刷データをダウンロードする場合は不要です。Fusion360というソフトが非商用だと無料に使えるので、ひとまずこれを試してみるのが良いと思います。⁴

3D CADはあまり使ったことないのですが、基本は平面を作って引き伸ばすという方法を繰り返せばそこそこの物が作れるようです。スケッチを選んで、面を選んで、面上に図を書いて、引き伸ばす。これをこれをくり返せば結構いろいろな図形を作ることができます。あわせてフィレット（角を削って曲面にする) と回転引き伸ばしを組み合わせて、直線方向以外の整形も行えますが、これらの処理には注意が必要です。私が3Dプリンタを使うとき、印刷物して実物を見てからモデルを調整するということが何度も発生しておりこういうときにフィレットされていると面を引き伸ばすことが難しくなります。フィレットしてない版を保存しておき、実際にどこかで利用されるときは毎度フィレットを行う、という方法を取れば、手戻りは少なくなりそうです。

Fusion360には保存時に同一ファイル内でバージョン管理ができ、バージョンごとにに名前をつけられるなどの機能があるのですが、試行錯誤して作るデジタルデータはgitで管理したくなるなという気持ちになりました。

スライサー

3Dモデルからgcode (3Dプリンタが読み込める形式) への変換に必要です Ultimaker Cura というソフトを使っています。 3D CADからSTL形式で出力したモデルを、Ultimaker Curaで、印刷設定をしてgcodeで出力します。印刷設定としては、 in fill (印刷時、内部の充填率を決められる。25〜30%くらいがよく使われているらしい)、印刷方向、サポート材の有無などが決められます。

gcode形式のファイルができたら、SDカードへ保存します。 gcodeファイルをSDカードに入れてAnyvubic Mega Sに差し込み、タッチパネルからファイルを選びます。

最初は付属のSDカードに入っていたフクロウを印刷してみましたが、大きさが5cmくらい、1時間半程度で印刷が終わりました。フィギュアを作る予定ではないので十分満足できる精度だと思います。 2.5万円ということでもしかしたらまともに使い物にならないかもと期待していなかったのですが、全然そんなことなく、色々なことに活用できそうです。

印刷のコツとして、以下のような点がありそうです。

積層方向を考慮する ... 積層方向によって、縮みや歪みや強度に差があるので、3Dモデルの設計だけでなく印刷方向の決定も印刷の成功に関わってきます。
印刷後は台座が冷えるのを少し待つと良い ... Anycubicの台座は特殊な素材が使われているようで、プラットフォームが熱い間 (印刷中) はずれないように吸着し、印刷後冷めると剥がれやすくなります。印刷後は焦ってすぐ剥がすよりも少し待った方が、台座を傷つけずに済みます。
大きな部品は分割する ... 大きな部品は印刷に時間がかかるので待ち時間が増えます。それだけでなく、トライアンドエラーをするのが億劫になります。組み立て式にしたり一部に切り出したりすると試作しやすく、良いものが作りやすいと思います。

感想

私個人としては買ってよかったです。印刷したいものが安価に印刷できて満足でした。安価に販売されているので、買ってみたが全然使い物にならなかったなどということも想像してましたが、予想以上に"普通に"使えました。

しかしながらモデルを作って印刷して改良して、を繰り返すのはそこそこ時間がかかるので、そういった手間を覚悟で楽しむものだなあという感じです。 (3D CADへの習熟度が上がればもっと気軽につくっていけるのかもしれません)

3Dプリンタはもっと高価なものだと思っていたのに随分手頃になりました。例えば2012年頃の動画に出てくる3Dプリンタは積層間隔が0.3mm、自分で加工しながらMDF材からなるたくさんのパーツを組み立てています。(たしか当時リアルタイムで見ていた動画です。ニコニコ動画の #ニコニコ技術部タグをみてワクワクしていた頃です。) 私の買った3Dプリンタは金属製で主に3つのパーツをネジ止めするだけでよいものです。それが2.5万円ですから、低廉化が進んでいますね。 ↩
3Dプリンタはカスタマイズする文化があるようで、あとからパーツを交換して静音化や印刷精度の向上などをはかる事ができるようです。購入する前は興味がなかったのですがいざ届いてみるとちょっと静音化に手を出したくなったりします。動作音 (とくに機械動作音ではなくモータドライバの電子音) がそこそこな音で、同じ部屋で寝るのは難しいレベルの騒音でした。 ↩
FlashForgeは印刷部分が囲われていてかっこいいですが、これは格好良さではなく庫内の温度を高く保つためなんだそうです。ABSで印刷するときはこういった囲いがあるほうが印刷に成功しやすいらしい。 ↩
M1 Macbook Airだとデュアルディスプレイにしたときに小ウィンドウの表示がバグっている気がする。 ↩

情報処理技術者試験にはミックスサンド (DBスペシャリスト試験を受けました)

Sun, 19 Dec 2021 08:13:00 GMT

2021/10/10に令和3年度秋期データベーススペシャリスト試験を受験しました。情報処理技術者試験は通算4回目、高度情報は2回目 (春にネットワークスペシャリスト落ち)、データベーススペシャリストは今回が初でした。

合格したので、この度晴れてみくりさんと結婚できる権利を得ました。

#逃げ恥リストラ候補の津崎平匡さんの資格欄「応用情報技術者、データベーススペシャリスト、基本情報技術者」 - togetter

以下、対策したことを記録します。

参考書

いままではインプレスの過去問題集を毎度買っていたのですが、今回は翔泳社の「うかる！データベーススペシャリスト」を購入しました。

結果からいうとこれは大正解で、午後問題の解説がめちゃくちゃ丁寧なので知識があまりない状態でも解説から吸収することができました。インプレスの過去問題集は、ネットワークスペシャリストの午後問題を勉強しているときに解説がサラッとしすぎていてわからんなあという気持ちになっていました。「うかる！データベーススペシャリスト」には各問題のパターンと解き方も参考書に丁寧に解説されているので、試験申し込んだときに一読し、あとで解くときに読み直すと良いように思います。

インプレスの過去問題集は書籍自体をPDFダウンロードできるのが気に入って前回まで買っていました。翔泳社の書籍の電子版はKindleで販売されていますが、こういう参考書は書き込んでなんぼなのでKindleアプリ上で勉強するのは厳しいものがあります。 PDFでの販売をしてくれるとより買いやすくなるのですが...

試験勉強の時間軸

試験勉強を始めたのは申込みをした8月中旬からでした。参考書を前からざっくり読んだ後、問題演習として初めに取り組んだのは午前Ⅱ対策です。 1分半程度で解く規模の問題なので軽い気持ちで勉強しやすく、知識中心なのでまずはこれから手を付けました。

9月に入った頃に午前Ⅱ対策を終わりにして午後対策に移りました。午後Ⅱは1問解くのに2時間かかるので、休日に午後Ⅱ、平日に午後Iとして、並行して過去問を解いていました。しかしながら特に午後Ⅱはとにかく文章が長いしやってると眠くなるし、この頃からモチベーションも薄れてきて勉強ペースが落ちがちに。結局参考書で紹介された再重要問題の半分くらい解いたところで試験前日になりまして、残りの問題は解説を読んで雰囲気を掴んで当日を迎えました。

情報処理技術者試験は申し込んだとき一番モチベーションが高い気がします。毎度試験会場は半分〜7割くらいしかいないのでみんなそんな感じなんじゃないかな。申込時のモチベーションとその勢いでどこまで勉強できるか、それをどれだけ維持できるかが大事なのかなと思っています。

各試験区分の対策と感想

午前Ⅰ

応用情報技術者試験を受けたのが2年以上前なので午前1の免除はありませんでした。いけるやろ」と無勉強で望んだのものの意外とと解けない問題もありました。さらに大々的にマークミスをしていまい、少し危なっかしい点数でした。問題番号と解答用紙のマーク位置はよく確認しましょう。

午前Ⅱ

午前Ⅱは選択式の問題で、データベースに関連する幅広い知識が問われます。対策としては参考書についてくる200問を繰り返し解いていました。データベース何もわからん人間でSQLすら怪しい状態でしたが、間違えたところに絞りながら2,3周すればそこそこ解けるようになりました。

SQLはどうやって学べばええんやというときは、PostgreSQLやMySQLの日本語ドキュメントを参考にすることが多かったです。参考書では簡潔に書かれ読み取れないことも含めて丁寧に書かれており読みやすい内容でした。 (それが標準SQLであるかは確認する必要があります。)

情報処理技術者試験の選択問題対策はどれも範囲が広いので雑にググって知らない言葉をなんとなく頭に入れておくのがよいと思っているのですが、ことSQLにおいては信頼できなさそうな量産ブログがたくさん引っかかるので最初から的を絞った方がよかったです。¹

今思えばSQLに関する本を一冊買うなどしてもよかったように思います。

午後I

午後Iの問題は出題形式がいろいろありますが、一部の問題は午後IIをコンパクトにしたようなものもあります。午後Ⅱの対策をある程度進めてから午後Iに取り掛かった方が効率が良いように思います。

午後Ⅱ

参考書によるとデータベーススペシャリストの午後Ⅱは出題形式が定番になっていて、前述の通りその問題が出来ないと受からないかつそれが出来れば午後I対策にもなるとのこと。午後Ⅱのもっとも定番な問題である概念データモデルと関係スキーマに関する問題を何問か解いていきました。業務ロジックが文章で説明されており、未完成の概念データモデルと関係スキーマを完成させるのが主な問題の内容です。

が、この問題、とにかく問題の文章量が多い。 1問あたり12ページくらいあります。 iPadではページ切り替えが多すぎて厳しいので印刷して紙でやったほうがいいでしょう。

試験のためのTips

概念データモデルの記法

午後問題では概念データモデルが必ず出てきます。それぞれの記号に関する意味は注意書きとして試験問題の前半に書いてありますが、これは例年同じものです。

午後問題の勉強を始めるときに初めに時間をとってじっくり読むことをお勧めします。この記法にしたがって概念データモデルを書く問題も頻出です。私は読まずに問題を解いていて、対策中盤くらいまでなんだかよくわからない記法が使われているなあという気持ちになっていました。

午後Ⅱ開始前の...

当日は各試験区分が始まる15分くらい前から説明が始まります。午前中は受験票の回収がありますが、午後にもなると説明や準備もすぐに終わって解答開始まで10分くらい無の時間が訪れます。携帯も切って参考書も閉まったあとで、じっと座っているだけの時間です。

ここの時間は空想をするくらいしかないと思っていたのですが、午後IIには未完成の概念データモデルを埋める定番問題があります。これを解くにはたくさんの問題文から情報を抽出して回答する必要があるので全体を掴んでおくと結構よかったりします。そしてこの問題は解答用紙に未完成の図が書いてあるので、試験開始前になんとなく問題に出てくる用語とその関係を見ることができてしまいます。ます😜

おわりに

データベーススペシャリストに合格したところで実際の業務上でわからないことは沢山あると思いますが、ひとまず一定の知識を習得できた意味で受験してよかったです。

タイトルのミックスサンドは試験当日に食べたお昼のメニューです。情報処理技術者試験の試験会場は私が参加した限りでは大抵どこかの学校で開かれます。コンビニが近くになかったり、あっても混み合うことが予想されるので、駅を降りたあたりのコンビニでご飯を買うとよいと思っています。

今回もコンビニに寄ったのですが、その時ふと以前の試験のときにミックスサンドを買ったことを思い出しまして。コンビニに売っている普通のミックスサンドですが妙に美味しかった記憶が残っており今回も同様のものを選びました。

起床時間が早く空腹を感じて午前Ⅱの前に美味しくいただきました。次に情報処理技術者試験を受けることがあったら、またミックスサンドを選ぶかもしれません。

このブログも個人が書いているもので、大して信頼できる情報ではないのだった ↩

ECテックカンファレンスの前と後

Thu, 16 Dec 2021 01:43:00 GMT

前の記事に書いたとおり先日ペパボECテックカンファレンスに登壇しました。今日はテックカンファレンスの内容ではなく発表前後に考えていたことと気持ちをいくつか記します。

「新卒」という言葉を使わない

発表に際してひとつ気をつけていたことに「新卒」という言葉をあまり使わないことがあります。

テックカンファレンスの目的や狙いが記載された社内向けのissueを登壇が決まった頃に読んだ記憶があります。これと今までやってきたこととを照らし合わせ自らの発表を聞いて欲しい人をジュニア層 ¹ のエンジニアと定めていました。

私は新卒で入社したのでその体験をこれから新卒で入社される方や興味のある方に向けて話す行為は普通は一定程度価値があると思います。しかしながら実は聞いて欲しい人として定めたジュニア層のエンジニアと、私の所属する会社の今後の新卒採用の募集方針は重なる部分が少なくなっています。² このことを鑑みると「新卒」という言葉を聞いて会社に興味を抱いてくださっても募集要項とは重ならずミスマッチが発生することになります。

そこで聞いて欲しい人と伝えたい内容を合わせるために、新卒かどうかにかかわらず「新しくチームに入る人」という視点で内容を組み立てることとしました。これであれば新卒に限定せずエンジニアに広く聞いてもらえる内容となります。チームで働いている人は誰でも人を迎え入れたりチームに加わったりした経験があるはずですし、今後チームで働きたい人にとっても聞く耳を持ってもらえることと思います。

技術的にどんなことに取り組んだかを軸にしない

テックカンファレンスですから技術に興味のある人が集まり技術について発表する場であることは明らかでしょう。しかしながら今回発表したようなチームとしてうまくやるための手法も、技術による価値提供を支えるために技術者に求められることの一つに思います。

もちろん技術の話は面白いし現にたくさんの方々が技術の話をされたわけですが、一方で今の私が技術の話に触れたとき内容が中途半端になることを恐れていました。日々の仕事は難しく面白いものでありエンジニアであるから技術を用いた課題解決をしているわけでありますが、今やっている事柄は業務知識に密接に紐づいたものであったり事業部の物事をキャッチアップしたりする機会が多く、切り取り方が難しいと感じていたのです。

しばらく考えてもあまり良い内容が思い浮かばず、発表が近づいてきた段階で自分で決めたのが「技術的にどんなことに取り組んだかを軸にしない」ことでした。³ 中途半端に技術の話をするよりも、どのように考え何を感じたのかの方がきっと面白味があるし、私の発表の目的⁴のひとつであった「このサービスで働くのはこんな感じか」を想像しやすいのではないかと考えました。

テクニカルな内容にあまり触れなかったのは結果としてよかったと感じています。今の私に話せることを発表に落とし込んだつもりですが、一方で他の方々の発表を聞いて「技術的にこんなことをやっているぞ」と自慢できるくらい成果を出せるようになりたいとも思ったので、来年以降たくさん成果を出して発表の場に立ちたいと思います。

聴衆は"あなたの発表"を聞きに来ているのです。

発表前に社内のSlackに投稿されていた文章がいい話だったのでここで触れます。

初めての発表で緊張していたり、どういう反応がくるか不安になってしまうというのはよくわかります。しかし、あなたの発表を見に来ている人は、他の誰でもない「あなた」の発表を見たくて見に来ているのです。

聴衆は"あなたの発表"を聞きに来ているのです - けんちゃんくんさんのWeb日記

(どうぞ上記の記事を全文お読みください)

当日は緊張していましたが、何か一つでも持ち帰ってもらえるものがあればという気持ちで内容に自信を持って臨むことができました。オンラインで発表していたので聴講者の顔は見えませんが、何人もの人に発表を聞いていただけたようで本当に嬉しいです。

次にまた発表の機会があったときこの文章を読んで気持ちを整えたいと思っています。あわせて自らの話を聞く時間をとってくださる人のために内容に自信をもてるだけの準備をしなければと感じます。

Speaker Deckにスライドを公開する

当日の発表スライドはSpeaker Deckにアップロードしました。公開にあたって気をつけたことがあるので紹介します。

Google SlidesとSpeaker Deckの相性

どうもGoogle Slidesで出力した日本語を含むPDFはSpeaker Deckで公開すると崩れるようです。(太字部分が白抜き文字になる) これを回避するために一旦Keynoteで読み込んでからPDFにするなどしました。 Keynoteに読み込むとスライド内のオブジェクトの位置ズレなどが発生するので、それを修正する必要もありました。

Speaker DeckのタイトルとURL

Speaker Deckで公開したスライドのURLはタイトルから生成されるようになっています。日本語の場合はローマ字読みのアルファベットに置き換えられますが、完全に正しい読みになるわけではありません。これを回避するために発表名の末尾に/を付けて続けて半角英数字などをおくと、/の後の半角英数字のみがURLになるようです。

これを生かして以下のようなタイトルとURLとしました。

タイトル: 「開発チームの新しいエンジニアメンバーがうまくやるには / newcomer-in-development-team」
URL: 「https://speakerdeck.com/yammerjp/newcomer-in-development-team」

以上、雑多ですが、発表に際してどんなことを考えていたかを記しました。

ジュニア層のエンジニアとはペパボのエンジニアの各種制度 2020 夏 - ペパボテックブログで示されている1-3等級相当のエンジニアのことを指して言っています。 ↩
GMOインターネットグループ共通2023年度新卒採用エントリーを開始しました - GMOペパボ株式会社にある通りの採用基準が定められています。これは新卒の採用基準であって、例えばジュニア層向けの中途採用や未経験者向け研修付き採用「ペパボカレッジ」などはこれに該当せず、募集が開かれています。(2021/12/16時点) ↩
発表の趣旨から離れすぎない範囲で技術的な内容に触れてはいます。(環境作成タスクの内容や自動テストなど) ↩
私の発表を聞いて「このサービスで働くのはこんな感じか」「このサービスで働くのは面白いぞ」「このサービスで働いてみたい」などの感情を想起してもらいたいと思っていました。 ↩

開発チームの新しいエンジニアメンバーがうまくやるには

Mon, 13 Dec 2021 15:03:00 GMT

こんにちは、2021/12/09に開催されたペパボECテックカンファレンスにて、記事名と同じタイトルで発表をしました。当日のスライドはSpeaker Deckで公開しています。

今日はその発表の内容を記事として紹介します。

開発チームの新しいエンジニアメンバーがうまくやるには

私は4月に新卒でWebアプリケーションエンジニアとして入社し、今は10人弱のチームに配属となってから3ヶ月ほどが経ちました。会社のGitHub Enterprise Server上では、配属からこれまでで約60のPull Requestを開き、マージし、デプロイされました。 Pull Requestの数と成果は必ずしも一致しませんが、配属から今日までの間、昨日を細かく分割して実装しデプロイするということを続けています。

チームメンバーが私を迎え入れるにあたってしてくれたことは、業務経験の無い自分が開発に取り組むにあたってとても役に立つものでした。以下では自らが意識的に取り組んだことと合わせて「新しいメンバーが〇〇するには」という題目で紹介します。

1.新しいメンバーが業務知識を素早く獲得するには

Webサービスのアプリケーション開発において、業務知識への理解は欠かせません。ここでいう業務知識とは、そのサービスを成立させるためのアプリケーションの構成やそれらのアプリケーション固有の仕様などをはじめとした、エンジニアが業務を進める上で必要なそのサービス特有の知識のことを指しています。

このような知識は開発チームに参加したのちに獲得する必要があり、素早く獲得すればより早く広範囲のタスクを扱えるようになるでしょう。

アプリケーションの構成に関する共有会を開く

(チームメンバーが私にしてくれたこと)

チームメンバーに業務知識の共有会を開いていただいたことは、業務知識の獲得に直接的に大きく影響を与えました。独自のアーキテクチャを持つアプリケーションのディレクトリごとの構成や各レイヤの関係性をざっくりと説明をしてもらったことでその後のコードリーディングが捗ったように思います。

他にもリレーショナルデータベースの重要なテーブルの関係性についてレクチャーをいただいたことも良い機会でした。私の開発するサービスは多数のロールがデータベースを介して連携をしています。即ち特定のロールの処理を見てもそれ自体がサービスの動作を表しているわけではなく、他ロールでどのように使われているかを知る必要があります。こういった広い範囲の挙動を把握するためには、全体感をつかむ説明を受けた方がアプリケーションの挙動を把握するのが楽になります。

少しずつ取り組む領域を広げる

(チームメンバーが私にしてくれたこと)

配属初期にいただいたタスクに関連するコード上の領域が少しずつ広がっていったことも業務知識を素早く獲得するに寄与しました。私は元々フロントエンド寄りのスキルセットであったので、Webフロントエンド領域のテンプレートやVueコンポーネントの実装からはじめて、次にWebサーバサイド領域のController層、Model層の開発に関わり、さらに他のロールや外部APIとの通信、バッチといった部分へ手を広げていきました。大きなコードベースの中で少しずつコードリーディングの範囲を広げられたことはスムーズに開発に参加できた要因のひとつでした。

チームに回ってくるタスクに「やります」と言う

(自らが意識していること)

業務知識を素早く獲得するために私が心掛けていることの1つとして、チームに回ってくるタスクに積極的に「やります」と手を挙げることがあります。開発チームにおいて、お問い合わせやパートナー (社員のこと) からの依頼に起因して、もともとの計画に含まれない突発的なタスクが発生することがときどきあります。こういったタスクの中には配属後少し時間が経ち慣れてくればある程度対応できそうなものもあります。自らのできることが少ないからこそ、できることは積極的に巻き取ることでチームに貢献しようとしています。

チームとしての生産性を高めるという点だけでなく、こういったタスクはときに自らの知っている領域を広げるきっかけになることがあります。例えば私はあるロールのDockerを用いた開発環境を作成するタスクに取り組みましたが、これはまさに自らの知っている領域を広げるものでした。

普段はコードベースの大きい中心的なロールに対して開発を行なっており、CI/CD環境が整備され、Gitの操作やSlackとの連携によって、深く知らずとも簡単にデプロイできる環境が整っています。

一方開発環境の作成では、そのようなCI/CD環境が普段どのようなことを行なっているのかを一定程度追う必要がありました。また、Webアプリケーションのエントリポイントに到達する前に、インフラレベルでHTTPリクエストがどのようにルーティングされているかといったことについても一定程度理解する必要がありました。これらの知識は中心的なロールを含む他のロールにも適用でき、ブラックボックスとして扱っていたサービスを構成する要素の一部がどんなことをしているかを知ることができました。

手を挙げてタスクを受け取ることで、こういった毛色の違うタスクに触れる

2.新しいメンバーがチームに馴染むには

昨今は心理的安全性という言葉が取り沙汰され、開発チームのメンバー同士の関係もプロダクトの提供する価値に影響を与えることが広く知られていることと思います。私の所属するチームにおいてもチームメンバー同士の関係を良好に保ち、意見を積極的に交換できるような関係性を築くような取り組みがなされています。

お互いの強み/弱みを知る

(チームメンバーが私にしてくれたこと)

チームメンバーがお互いの強み/弱みを知るために「ドラッカー風エクササイズ」という手法のチームビルディングのためのワークショップを開催していただきました。これは私がチームメンバーと相互理解を深めることに役立った出来事の1つでしょう。「ドラッカー風エクササイズ」はお互いの特徴の自己認識と他者認識を書き出して、期待値をすり合わせるための手法です。自らの思っている強み/弱みを伝えるきっかけになりますし、自分以外のチームメンバー同士でどのような関係が築かれているかを知る機会になります。ペパボにおけるドラッカー風エクササイズの取り組みは会社のブログに紹介がありますので以下の記事をご覧になると良いかと思います。

参考: 「ドラッカー風エクササイズ」で期待をすりあわせて安全なチームに - ペパボテックブログ

コミュニケーションの場を用意する

(チームメンバーが私にしてくれたこと)

フードコート

私の事業部のいくつかのチームにはフードコートという取り組みがあります。いつでも開かれているビデオミーティング会場で、お互いが好きな時に入ることができます。私の所属するチームのメンバーの多くは予定がない時などはここにいて、チームメンバーに話したい時にマイクをonにするといった運用がなされています。フードコートに居る義務はなく、集中して業務に取り組みたいときなどには入らないという選択肢をとることもできます。仕事を始めたて且つチームに参加したての自分にとって、発話のハードルが下がったのでありがたい取り組みでした。

事業部お茶会

リモートワークの中では、偶発的な同期コミュニケーションの機会はあまりありません。このためチームメンバーが事業部の人を招いた座談会を定期的に開催してくれています。他チームの人と業務に関係あるかどうかに関係なくいろいろな話をする機会が生まれることは、視野が広がる機会となっています。

日報を書く

(自らが意識していること)

チームメンバーとの相互理解を深めるために大事なことの一つに自己開示があります。日報を書くことで、自らがどんなことを考えて仕事をしているか、どんな感情であるか、何を理解していて何を理解していないのかを知ってもらう機会となります。¹ また、チームメンバー以外の人が見てコメントをくれることもあります。

日報のフォーマットとしては「今の気持ち」「やったこと」「わかったこと」「次にやること」の4つに分けて記述するようにしています。

3.新しいメンバーが開発の提案をするには

複数の選択肢を挙げる

(自らが意識していること)

開発において、要件を達成する手法を自分で決められない/決めないとき、複数の選択肢を提案することで、自らに足りない業務知識や技術的知見を補ってもらえるようにしています。

このとき、あわせて自分が最も良いと思う選択肢を1つ選ぶよう心がけています。自分が選んだものと実際に選ばれたものの差異が学びになるので、自分で1つ選ぶことはこれからも続けていきたいと思っています。

テストコードを書く

(自らが意識していること)

Pull Requestを開発における実装の提案の場として考えると、Pull Requestも新しいメンバーが開発の提案をうまくやる必要のある場の一つでしょう。適当なPull Requestを投げてばかりではレビュアーの負担は増大するばかりです。

レビューしやすい Pull Request にするという意味でテストコードは有用です。コードの一定の質が担保されるだけでなく、入出力が明確になったり、依存が明らかになったりするという利点が考えられるでしょう。

ちなみにテストコードの書き方については新卒研修の中でのカリキュラムがとても役に立ちました。ペパボの2021年度の新卒エンジニア研修では、Railsチュートリアル内でのMinitestによる自動テスト、RSpec書き方講座、TDDワークショップなど、ソフトウェア開発における自動テストがどのような役割を持ちどのように作るべきかを学ぶことができました。今はRSpecだけでなくPHPUnitやJestを用いたテストコードを書く機会がありますが、これらのテストフレームワークを使う上でも研修で学んだ内容が役に立っています。

おわりに

以上のような取り組みを通して、開発チームに新しくエンジニアとして加わったメンバーが、業務知識を素早く獲得し、チームに馴染み、開発の提案をして、ユーザへの価値提供に取り組んでいます。チームメンバーが新しく私を迎え入れるためにしてくれたことが今の開発に生きていると感じています。

これらの事例が、チームに新しく加わる人や、新しい人を迎えるチームにとって参考になれば幸いです。また、チームに加わった3ヶ月で自分がどのように感じ何が役に立っていたかの取り組みを残しておくことで、将来チームメンバーを迎え入れる側になったときにこれを見返してよい環境を提供できるようになれればと思います。

同時にこれら (どんなことを考えて仕事をしているか、どんな感情であるか、何を理解していて何を理解していないのか) を言語化することで自らに対して明らかにする機会ともなります。 ↩

複数の環境に適応する、階層構造のdotfiles

Thu, 02 Dec 2021 05:00:00 GMT

こんにちは、やんまーです。もう師走、早いですね... この記事はGMOペパボアドベントカレンダーの2日目のものです。

昨日はdaikiさんの「社会人エンジニアな僕が研究を続ける理由」でした。記事の中の研究を通して自己表現をされているという表現が印象的でした。仕事に精を出しながらも、仕事とは異なるところで時間をとって継続的に物事に取り組むということに尊敬の念を持ちます。私も見習いたいものです。

今日は変わって実践的な内容です。私の開発環境 dotfilesを紹介します。

dotfiles とは

Unix / Linux の環境において、~/.bashrc、 ~/.vimrc、 ~/.gitconfig のように . から始まる各アプリケーションの設定ファイルが $HOME ディレクトリに配置されることがよくあります。これらの設定ファイルを自分の持っている複数のPCに適用したいというモチベーションや、PCを乗り換えた時のためにバックアップして復元したいというモチベーションから、ローカルのストレージ以外にも保存するということが行われています。

こういった設定ファイル群とこれらをローカルストレージ以外の場所に保存することを指して dotfiles と呼び、GitHubのリポジトリで公開するなどしている人もいます。かくいう私も自らの設定ファイルを保存・公開している人の一人で、GitHubのリポジトリ (yammerjp/dotfiles) から誰でも見れるようにしています。

単純なdotfiles

本記事で後述する複数環境に対応した構成のまえに、単純なdotfilesの構成として yammerjp/dotfiles-mini をみてみましょう。このリポジトリには次のようなファイルがあります。

ファイル名	ファイルの役割
`.gitconfig`	gitの設定
`.tmux.conf`	tmuxの設定
`.vimrc`	vimの設定
`.zshrc`	zshの設定
`README.md`	リポジトリ全体の説明
`run.sh`	dotfilesを適用するシェルスクリプト

ここで注目するのは run.sh というシェルスクリプトです。内容の一部を抜粋すると以下のようになっています。

# リポジトリをダウンロードする
# ========================================
cd "$HOME"
git clone https://github.com/yammerjp/dotfiles-mini.git
cd dotfiles-mini


# シンボリックリンクを貼る
# ========================================
DOTFILES_DIR=`pwd`
ln -s "$DOTFILES_DIR/.zshrc" ~/.zshrc
ln -s "$DOTFILES_DIR/.vimrc" ~/.vimrc
ln -s "$DOTFILES_DIR/.gitconfig" ~/.gitconfig
ln -s "$DOTFILES_DIR/.tmux.conf" ~/.tmux.conf

GitHubからダウンロードしてくることと、設定を適用すること (シンボリックリンクを作成し ~/.zshrc などで参照できるようにすること) を行なっています。このように設定を保存・公開するだけでなく、あわせて設定を適用するスクリプトを付属させておくと便利に使えます。

複数環境にする需要

さてさて、上記のように各アプリケーションの設定を保存・公開し、適用するスクリプトも用意できたのですが、しばらくするとさらに欲が出てきてしまいます。

複数のOSの環境 (片方がLinux、片方がmacOS) が手元にあり、それぞれの設定を管理したい ¹
同じOSの複数の環境 (職場のPCと自宅のPC) が手元にあり、それぞれの設定を管理したい
会社で使っている設定は公開したくないが、自宅で使っている設定は公開したい
複数の環境の設定の一部を共通化したい

このように複数の環境が存在しそれぞれ異なる設定を保持したい場合や、設定の公開範囲を制御したい場合に役立つのが、今回紹介する複数環境に適応した階層構造のdotfilesです。

階層構造の実装

公開範囲や適用環境を複数定めることができるように、以下のような構成をつくります。

いくつかの設定ファイルを含むディレクトリを複数用意する (階層とよぶ)
用意した階層の中から任意の順番で任意の個数の階層を選び、順番に適用する。

複数の階層 (ディレクトリ) に分割することで、一部はGitHubのパブリックリポジトリに置かないという選択肢もとれますし、一部のPCでは特定の階層を適用しないという選択肢もとれます。また、順番に適用する とあるように、各階層で設定ファイルが重複するとき、優先順位を指定することができるようにしています。

具体的に私の環境は以下のようなディレクトリの階層構造になっています。

自宅のMacbook Air
会社のMacbook Pro
- company 階層
- Darwin--x86_64 階層
- Darwin 階層
- common 階層

全ての環境に共通の設定を集めた最も下の階層として common 階層を配置しています。その上の階層として、macOSのみに必要な設定を Darwin 階層に、さらに上の階層として arm64 / x86_64 の macOS に必要な設定をそれぞれ Darwin--arm64 階層, Darwin--x86_64 階層に配置し、commonなどの下の階層の設定を一部上書きます。加えて最上位の階層として、会社のPCで利用している公開できない設定などを含んだ company 階層を配置し、これは会社のGitサーバで管理するようにしています。

このような階層構造は、各設定ファイルを適用する (シンボリックリンクを貼る) スクリプトを工夫することで実現しています。実際に実行されるスクリプトの動作とともに紹介します。例えば以下のようなコマンドを実行することを考えます。

$ DOTFILE_DIRS="$HOME/src/github.com/yammerjp/dotfiles/env/Darwin--arm64:$HOME/src/github.com/yammerjp/dotfiles/env/Darwin:$HOME/src/github.com/yammerjp/dotfiles/env/common" ./bin/dotfiles link

bin/dotfiles は変数 $DOTFILE_DIRS に : で区切られたディレクトリの列が指定されることを期待します。² また指定されたディレクトリ列がそのまま、各階層のルートディレクトリとなります。なお先に記述されたものが上位の階層として扱われます。

今回でいえば上位から順に3つの階層をもちます。

Darwin--arm64 階層 $HOME/src/github.com/yammerjp/dotfiles/env/Darwin--arm64
Darwin 階層 $HOME/src/github.com/yammerjp/dotfiles/env/Darwin
common 階層 $HOME/src/github.com/yammerjp/dotfiles/env/common

それぞれの階層のディレクトリにあるファイルからホームディレクトリへ、シンボリックリンクが作成されます。このとき、それぞれの階層のディレクトリの中で、階層の起点となるディレクトリから同名の相対パスのファイルがあれば、その中で最も上位の階層のファイルのみホームディレクトリへシンボリックリンクが貼られます。

例えば各階層 (Darwin--arm64, Darwin, common) に .zshrc があるとき、最も上位の階層のものである Darwin--arm64 階層の .zshrc から $HOME/.zshrc へシンボリックリンクが貼られます。

各設定ファイルでの工夫

上述のように同名のファイルは上位階層が優先されてしまうので、設定ファイルの一部を共通化したいときは、ファイルを分割して用意することで対応しています。

例えば common 階層の .zshrc は無視されてしまうので、設定の中身は同階層の .zshrc-common に切り出し、.zshrc ではそれを読み込むだけにします。同様に Darwin 階層では内容を .zshrc-darwin に、 Darwin--arm64 階層では内容を .zshrc-darwin-arm64 に記述し、各 .zshrc は自身の階層と下位階層の ~/.zshrc-* を読み込むだけにして、上書きされても問題ないようにしています。

このような行為は他の設定ファイルでも行なっていて、例えば .gitconfig にも include の仕組みがあるので、.gitconfig は上書きされてもいいように .gitconfig-common に設定を書いて .gitconfig はそれを読み込むだけにしています。

おわりに

こうして工夫をすることで、自宅のUbuntuでも、会社のMacbookでも、サクッと用意したEC2でもすぐに自分の環境が用意できる仕組みを作っています。設定ファイルだけでなく、パッケージのインストールやOSの設定の変更などのスクリプトも管理しようとしています。これは生産性を向上させるためというより、それを歌いながらもdotfilesを育てていくのが楽しいだけなのですが、少しばかりは便利になっているはずです。今日は私のdotfilesを紹介したので、ぜひ皆さんのご自慢のdotfilesがあれば教えてください。

というわけでアドベントカレンダー2日目の記事を終わりにします。何も考えずに「ええやろ！」という気持ちで2日目にエントリーしましたがひとまず書き終え安心しています。明日はakichanさんです、バトンを託します！

このことだけであれば、OSごとに設定が違うときは各設定ファイルの中で分岐するように記述すれば解決できるものもあるでしょう。例えば ~/.zshrc などは if 文で分岐すれば済みます。 ↩
実際には common や Darwin, Darwin--arm64 といったディレクトリはデフォルトで指定されるようにしています。OS(とLinuxならディストリビューション名) とCPUのアーキテクチャから、それぞれの環境に即した3-4階層を定めています。会社のGitリポジトリで管理している設定やGitHubのプライベートリポジトリで管理している設定を適用したいときに、 $DOTFILE_DIR などの変数にそのディレクトリのパスを与えると、デフォルトの3-4層に上位階層としてこれを加えた状態となるようにしています。階層の追加は後からでもできる (コマンドを叩けばシンボリックリンクを貼り直せる) ので、新しい環境では (そのOSとアーキテクチャに即した設定を用意していれば) ./bin/dotfiles link とするだけでよくて、あとから必要な階層を足していくようにして運用しています。 ↩

master push をしないために

Tue, 09 Nov 2021 01:31:00 GMT

昨日、master push をしてしまいましたので懺悔します。

私の会社の開発は、GitHub Enterprise Server上のPull Requestベースで行われており、開発した機能をPull Reqeustにしてレビューを貰ってからマージすることとなっています。しかしながら昨日の私は、ローカルで作ったcommitをそのままリモートリポジトリのmasterブランチにpushしてしまいました。 masterにマージするだけでは本番にはデプロイされませんが、複数のチームが開発しているリポジトリであり、各方面に迷惑をおかけしました。

私がやらかした後、master pushを防ぐ術を教えていただいたので、以下に記します。

GitHub上で branch protection を行う

ルールを設定し、force pushできないようにしたり、レビュー必須としたりすることで特定のブランチが不当に変更されることを防ぎます。

(当該リポジトリでは masterブランチに対し branch protection は設定されていましたが、私が管理者権限を持っていたのでpushできてしまいました。)

ブランチ保護ルールを管理する - GitHub Docs

"include administrators" を有効にする

GitHubのbranch protectionの設定の中で、"include administrators" (管理者を含める) という項目が設定できます。これにより、管理者権限を持つ人であっても、branch protectionのルールが適用されるようになります。

保護されたブランチについて - GitHub Docs

ローカルのGit Hooksでmaster/mainへのpushを制限する

gitには特定の操作の前後にスクリプトを実行できるhooksという機能があります。 hooksは、グローバルに有効なスクリプトを指定することもできるので、これを用いて以下のような設定を記述します。

`~/.gitconfig` にグローバルに有効なhooksのディレクトリを指定

~/.gitconfig に以下のように記述することで、そのコンピュータでgitコマンドを実行したとき、常に ~/.config/git/hooks 以下のhooksが参照されるようになります。

[core]
        hooksPath = ~/.config/git/hooks

`~/.config/git/hooks/pre-push` にmaster/mainブランチへのpushを禁止するよう記述 / ローカルフックを呼び出すよう記述

グローバルなhooksに指定されたディレクトリの下に、実行権限をもつ ~/.config/git/hooks/pre-push というファイルを配置し、以下のような記述をします。

#!/bin/bash -e

lines="$(cat)"

# branch protection
# 標準入力 $lines にブランチ名などが渡される
# $lines をもとに、master/mainブランチへのpushであれば、終了コードを1としてpushを中断
function restrict_master_push() {
  echo "$lines" | while read local_ref local_sha1 remote_ref remote_sha1
  do
    if [[ "$remote_ref" = "refs/heads/master" ]]; then
      echo "Do not push to master branch!!!" 1>&2
      exit 1
    fi

    if [[ "${remote_ref}" = "refs/heads/main" ]]; then
      echo "Do not push to main branch!!!" 1>&2
      exit 1
    fi
  done
}

case "$(git config remote.origin.url)" in
  # 自分しか使わないリポジトリなど、master/mainにpushしてよいものはskipするようにする
  "git@github.com:yammer/dotfiles.git" )
    echo 'skip restrict_master_push()' 1>&2
    ;;
  * )
    restrict_master_push
    ;;
esac


# kick local hooks
# グローバルにgit hooksを指定してしまうと、各リポジトリのhooksは実行されない
# そこで、このシェルスクリプト内で、各リポジトリのhooksを読み込んで実行するようにする
git_root=`git rev-parse --show-superproject-working-tree --show-toplevel | head -1`
hook_name=`basename $0`
local_hook="${git_root}/.git/hooks/${hook_name}"

if [ -e $local_hook ]; then
  echo "$lines" | bash "$local_hook" $*
  exit "$?"
fi

`~/.config/git/hooks` 以下の他のhooksにも、ローカルフックを呼び出すよう記述

以下のファイル名の実行ファイルを作成し、スクリプトを記述します。

~/.config/git/hooks/applypatch-msg
~/.config/git/hooks/commit-msg
~/.config/git/hooks/fsmonitor-watchman
~/.config/git/hooks/post-update
~/.config/git/hooks/pre-applypatch
~/.config/git/hooks/pre-commit
~/.config/git/hooks/pre-merge-commit
~/.config/git/hooks/pre-rebase
~/.config/git/hooks/pre-receive
~/.config/git/hooks/prepare-commit-msg
~/.config/git/hooks/push-to-checkout
~/.config/git/hooks/update

#!/bin/bash -e

lines="$(cat)"

# anything

# kick local hooks
# グローバルにgit hooksを指定してしまうと、各リポジトリのhooksは実行されない
# そこで、このシェルスクリプト内で、各リポジトリのhooksを読み込んで実行するようにする
git_root=`git rev-parse --show-superproject-working-tree --show-toplevel | head -1`
hook_name=`basename $0`
local_hook="${git_root}/.git/hooks/${hook_name}"

if [ -e $local_hook ]; then
  echo "$lines" | bash "$local_hook" $*
  exit "$?"
if

ユニコーン企業のひみつを読んだ

Wed, 18 Aug 2021 13:28:00 GMT

8月も折り返し、いかがお過ごしでしょうか？8月は夏ですね。夏といえば夏休み、夏休みといえば宿題、読書感想文¹。ということで読んだ本の感想を綴ります。読書メモが下書きに溜まってしまっているので消化する試みです。

書籍「ユニコーン企業のひみつ」を読みました。本書はSpotify をはじめとするテック企業が、スタートアップのような勢いのある価値提供をどうやってスケールさせているかを説明する、ソフトウェア開発企業の組織づくりについて説明されたものです。

今年の4月に日本語訳版が発売され、私の所属する会社の社内で広く読まれているようです。本書籍内でも言及されるSpotifyモデルと呼ばれる組織体制を、社内でもいくつかの事業部で取り入れています。そういった背景から書籍内で用いられている「スクワット」「チャプター」「トライブ」といった言葉が会話に出現するので、知っていないとコミュニケーションコストが高くなってしまいもったいないと感じ、7月の4連休にガッと読みました。

書籍内では次のようなことが言及されています。

権限を持つ職能横断の小さなチーム(スクワット)によって組織を構成することで、自己組織化が進み、強力なデリバリーを届ける
イテレーションを回そう
スクワットが価値提供する際の障壁を、組織として排除することで、本質的な課題に注力できる
今日のソフトウェア開発はマラソンであり、一朝一夕にて成立するものではない
目的(ミッション)をかかげ、それに至る方法はチームが考えることが大切。スクラムをただやるだけでは開発者はチケットを消化する機械になってしまう。それでは競争に勝てない
会社組織におけるこれらの事柄は文化と深い関わりがある。文化の醸成も重要

書籍の内容を通して、マネジメントを行う立場ではない一介のジュニアエンジニアとしては、次のことがまず自分にできることに思います。

そういた背景をもって組織づくりがされていると知る
目的を見て本質的な課題解決には何が必要かを考える
局所最適化しない。会社として価値提供するためには自分の仕事を限定しない

より良いサービスを届けるために文化は維持したまま、構成やあり方を変革し続けられる柔軟な組織は魅力的ですし、そういった組織の一翼を担う人として力が発揮できるようになりたいものです。

昔は宿題を最終日にまとめてやってやる人間で、宿題の定番である読書感想文もあまり好んでおりませんでした。そんな人間も10年したら備忘録や思考整理のために自主的に読書の感想をWebに投稿しているのだから不思議です。 ↩

アプリケーションをつくる英語を読んだ

Wed, 14 Jul 2021 14:54:00 GMT

会社の先輩に教えていただいた「アプリケーションをつくる英語」を読んだ。

この本はアプリケーション開発においてUIに表示される言葉を中心に、それらを英語でどう表現すればよいかのヒントが書かれている本である。三部構成で前半の二部は辞書的に単語や表現が紹介され、最後の一部が読み物になっている。

前半の辞書的な部分は、プログラムを書く中で命名に迷ったり、エラーメッセージを書いたりするときに役立ちそうだった。紹介されている単語や言い回しは比較的厳選されている。自分の表したいニュアンスの言葉が確実にあるわけではないと思うが、ソフトウェアやUIに関係する言い回しに絞って書かれている。迷ったときには和英辞書と合わせて、本書のPDF版を検索して参照したい。

後半の読み物のなかでは、35.3.2節キャピタリゼーション (どの文字を大文字にするか) が特に気になった。

恥ずかしながら本書を読んで明確なルールを初めて知ったのだが、文頭を大文字にするセンテンススタイル (通常の文に用いられる) の他に、より大文字にする単語数が多いタイトルスタイル/ヘッドラインスタイルと呼ばれるスタイルがある。名前の通り本のタイトルなどに使われるスタイルで、以下のようなルールがある。

名詞、形容詞、副詞、代名詞はキャピタリゼーションする

文の最初と最後の単語はキャピタリゼーションする

冠詞 (a、an、the) と接続詞 (and、butなど) はキャピタリゼーションしない。ただし文の最初と最後の場合はする

4文字以内の前置詞 (at、by、for、inなど) はキャピタリゼーションしない。ただし文の最初と最後の最後の場合はする

(アプリケーションをつくる英語西野竜太郎著 p262)

たとえばPCのGUIアプリケーションであればウィンドウのタイトルやメニューバーなどにタイトルスタイルが用いられている場合もあるだろう。例えばREADMEの章ごとのタイトルなどにも用いられるかもしれない。

UIなどにおいては完全な文を書くというシチュエーションと同じかそれ以上に単語や連文節で物事を表す機会があるだろうから、どういった規則で表せれば良いかのルールを学べたのはありがたい。

後半の読み物の部分はそれほど分量がなくすぐに読めて、前半の辞書的な部分は長く使える、ひと粒で二度美味しい本だった。コンピュータと戯れている限り英語とは離れられないので、もっと仲良くなっていかねばならない。

ソフトウェアは幽霊などではない。👻

Wed, 07 Jul 2021 00:15:00 GMT

ソフトウェアを開発していると、ときどき幽霊に出会うことがある。正確にはまるで幽霊のしわざかに思えるような謎の挙動に悩まされるときがある。

実際には幽霊などおらずコンピュータは書かれたとおりに動作しているだけで、さらに大抵は自分がプロトコルや仕様を把握していないか誤ったプログラムを書いているのだが。

幽霊
— やんまー (@yammerjp) July 6, 2021

これは私がOAuth2.0の仕様を把握していなかったが故に謎と思った挙動になやまされたとき。

複数の要因が重なっていたりして挙動の説明がすぐにはつかないとき、原因を追求するためにだいたい次のようなことをする。

原因を考える (現状を整理する、アタリをつける)
挙動を確認するためにプログラムを実行する (手を動かす)
仕様やドキュメント等を調べる
人に聞く

ここでは特に1つめの原因を考える事と2つめの手を動かす事について注目する。¹ これらは、手を動かさないとわからない事を考えても意味は無いし、逆に無鉄砲に手を動かしても意味はない。現状を整理すること、アタリをつけること、手を動かしてみること、これらを組み合わせてやっていく必要がある。

しかしながら特に昨日の私は原因を考えることと手を動かすことの比率が悪かった。またそもそも、目下の謎な挙動に対峙するとき、あまり自分の行動を分解して自らで認識せず全部一緒くたにしてやっているところがある。それですぐ解決できれば良いが、深みにハマったときに困る。

二分探索的に考えていた筈が条件に漏れがあったり、試せばすぐにわかったことを最後まで放置していたりする ² のはこういったところに原因があるかもしれないと思っていて、だとすると改善の余地がある。

そこで、次に対峙するときは今整理してアタリをつけるべきなのか、情報が足りないから手を動かすべきなのか、自分の現状を認識して意識的に切り替えることを試してみたい。³ そのとき脳内で私が発すべき言葉は「現状を整理したいのか？新たな情報を得たいのか？ (=手を動かすべきか) 」という二択の自らへの問いかけである。

3 のドキュメントを調べるという行為についても英語の仕様書をさくっとしっかり理解できるようにするだとかライブラリのコードを読み込むといった部分ががまだまだだし、4の人に聞くという行為も業務の中で最適なタイミングを逃していたり状況を整理して伝えるのが下手で時間がかかったりと、結局全部未熟なので粛々とやっていくしかない。 ↩
解決したあとだからそう思うだけかもしれないが。 ↩
実際には脳の力をそんなところに使う余裕はないのかもしれない。一方で業務でエンジニアリングに取り組むなら、時間的な見積もりをすべきである点と、再現可能な手法で行動して成果をあげるために自分の状態を認識するのは大切だろう点から、無心に対峙するのではなく上記の方法を試してみるべきだと感じた。 ↩

初出社、ワクチン接種

Thu, 24 Jun 2021 14:19:00 GMT

日記です。雑多なトピックが以下に続きます。

4月に入社した会社に、今日はじめて出社しました。新型コロナウィルスのワクチン接種が主な理由で、くわえて同期をはじめとして何人かに出会うなどしました。

今日の主なイベントであるワクチン接種ですが、大変スムーズで拍子抜けしました。受付をして打つのは一瞬、15分経過観察しておわり。職域接種のためいわゆるモデルナ筋注といわれるものを打って今は9時間ほど、腕が重いですね。

社の方々と会うのはちょっと緊張。人との接触は抑える必要もあるのであまりたくさん会話できるわけでもなく、会えていない人もたくさんいて、それらは未来の機会に託しました。新型コロナウィルスが一日でも早く収束することを願います。

初出社してみたものの、持っていく荷物がまだあんまりまとまっていないですね。バッグが重く、荷物も取り出しづらく、もうちょっと減らしたいです。 16インチMacBookは家で使うには最高なんだがなあ。

今日を経て、出社は大変だなという気持ちとともにリモートワーク環境の有り難さを改めて感じます。出社を前提にしていない場所に住んでることもあり、会社までは2時間弱かかります。通勤ラッシュを避けれたものの人出は多く、ちょっとこれが毎日は厳しい気がします。

最近、社会人になって最初の仕事がリモートワークでは社会人としての能力が身につかないという話をいただきました。私は社会人をまだ2ヶ月しか経験していないので社会人としての能力が何を指すのかも、リモートワークしか経験していないのでその真偽も、毎日の出社に使うエネルギーやコストが有用でそれだけの価値のあるものかどうかもわかりません。

ただしリモートワークは、コミュニケーションの工夫や自己管理が求められる反面、出社しないことで体力的/時間的な余裕はきっと大きいでしょうから、それを有効に生かしていかねばという思いです。

そんなこんなで会社に行った報告です。次の出社もワクチン接種でしょうか。その頃には梅雨が明けていますかね。

curldocというWeb APIの仕様書形式兼モックサーバを作っている

Mon, 21 Jun 2021 00:40:00 GMT

こんにちは。最近は会社の技術研修を粛々と受けています。 6月に入ってからはRailsチュートリアルを進めていて、ちょうど先週に終わりました。Railsは大変多機能であるとヒシヒシ感じています。 Ruby自体も今まで書いたことがなかったので、私の経験のある言語とは結構毛色が違っていて面白い気分です。残業も特になく給料をいただきながら勉強している謎の身分ですが、権利をありがたく享受してスーパーエンジニアに成長したいと思います。

そんなこんなとは別で、趣味で最近作り始めたのがcurldocというツールです。

curldoc

curldocのcurlはコマンドのcurlから来ています。平たく言うと、curlコマンドとそのレスポンスを記述したMarkdownファイルを読み込んで立ち上がるモックサーバを作っています。

そもそもcurlはHTTPリクエスト¹を送ることができるコマンドですが、実はこれ、ただ単なるコマンドだけでなく、HTTPリクエストを表す汎用的なフォーマットなのではないかと思っています。 PostmanやChrome開発者ツールにも、送信したリクエストをcurl形式で書き出す機能があったりします。

curldocの仕様書の形式

これをもとに、curlコマンドとその実行結果を書いたら簡易的なAPI仕様書になります。² 例えば次のような、リクエストとレスポンスのペアをひたすらMarkdownファイルに記述します。



リクエストを以下に記す。

```curldoc-request
curl http://localhost:3000/hello --header 'Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l'
```

レスポンスを以下に記す。

```curldoc-response
{
    "message": "hello"
}
```

この形式のよいところは2つあります。

シンプル

１つ目はシンプルであることです。 curlコマンドは前述のようにGUIアプリケーションから書き出せるし、広く普及しているフォーマットでもあります。

APIドキュメントを記述する形式としては例えばSwaggerなどが既にあります。大変良くできたツールであると思いますが、どうしても記法を学んだり、対応するツールがある言語やフレームワークの上でしか使えなかったりと、場合によっては多機能すぎることもあるでしょう。小さなアプリケーションを作る場合やハッカソンで素早く作る場合、社内向けツールでドキュメント整備の優先順位が低い場合など、APIの仕様を簡単にテキストにまとめるほうが良い場合もあるのではないでしょうか。 curldocはまさにそれです。なるべく知識を必要とせず、簡単に、しかし齟齬無く最低限の要求を満たすAPIドキュメントの形式がcurldocです。

シンプルであるからこそ、JSONだろうがXMLだろうがHTMLだろうがHTTPであれば自由に記述できます。

実行可能

2つ目は実行可能であることです。 curlコマンドは本来はコマンドですから実行可能です。シェルに貼り付けてエンターを押せば試せます。 HTTPサーバを開発してデバッグする時、テストする時、既に開発されたものを使ってみるとき、コピペしてエンターを押すだけで試せるなんてなんと素晴らしい仕様書でしょうか。

片手落ちの「実行可能」の片手を作る

ここまでは単に「curlコマンドの形式でドキュメントを記述すると楽だよ」という話でした。しかし、2つ目の実行可能であるという点は片手落ちです。もともとAPI仕様書はクライアント側とサーバ側で認識を合わせるため、双方のためにあります。しかしながらcurlコマンドはクライアントなので、実行可能であるのは片方の立場だけです。サーバを開発する人はcurlコマンドで確認できますが、クライアントを開発する人は実際のサーバができあがるまで実行できません。

そこで出現するのがcurldocです。 curldocはAPI仕様の書かれたMarkdwonファイルを元にモックサーバを立ち上げます。 Markdownファイルに書かれたものと同様のリクエストが来たら、対応するレスポンスを返すだけのモックサーバです。 curldocというアプリケーションによって、上記の形式のAPI仕様書が、クライアントサイドにとってもサーバサイドにとっても実行可能になることでしょう。

モックサーバなので、開発にもテストにも用いることができるはずです。³⁴

これから

まだ作りかけのアプリケーションについて雄弁に語ってしまいました。現状でも一応ベーシックな機能としては動いていて、Markdownファイル上でHTTPのヘッダやボディを指定すると比較してくれたりします。とはいえやりたいことは以下のようにまだまだあります。

JSON形式のリクエストボディの比較を柔軟に行う
指定されなかったHTTPレスポンスヘッダをよしなに埋める
ライブラリとして提供できるインタフェースを追加する
ドキュメントを書く
npm publishする
curlオプションのサポートを増やす

頑張って作るぞ。

https://github.com/yammerjp/curldoc.git

curlはHTTPに限らず様々なプロトコルをサポートしているようです。なんでも出来すぎてびっくりするくらい。 ↩
もともと5月末にハッカソン的にWebアプリケーション開発をやったときの感想から生まれたアイデアのツールです。サーバサイドとフロントエンドを別の人間が開発するとき、APIの認識をさくっとあわせるにはcurlコマンドによるリクエスト例を記述していく方法が結構はかどりました。 ↩
モックサーバを必要とするのはクライントアプリケーションだろう。→クライアントアプリケーションといえば特にWebではJavaScriptだろう。→ JavaScriptのテストで用いるならJavaScriptから起動できたほうが良いよねということでNode.jsで作っています。コマンドだけでなくライブラリとして提供したいと思っています。 ↩
別に作っているAtomPubのクライアントのテストが結構汚くて、JSONではないAPIクライアントのモックサーバが欲しくて作っている側面もあります。 ↩

リモートワークの馴染む、4月の新卒研修 (GMOペパボ)

Tue, 11 May 2021 13:38:00 GMT

2021年4月1日にGMOペパボ株式会社 (以下ペパボ) に入社しました。

これからソフトウェアエンジニアとして成長し活躍することを夢見てやる気に満ち溢れています。その第一歩として4月9日から4月30日までの約3週間、全職種で取り組むペパボの新卒研修に参加したので感想を記します¹。ええ、それはその、大変楽しい研修期間でした。

CS研修でお世話になったワタミユさんが書いてくださった新卒の我々のイラスト

リモートワークでうまくやる

ペパボは2020年6月にリモートワークを基本とした働き方に移行し、今年の研修は全てオンラインで実施されました。私自身、入社後にまだ一度も出社していません。

リモートワークの環境で新卒入社することに少なからず不安はありました。大学のときはオンラインによるコミュニケーションのとりにくさや物理的な距離感を強く感じることも多かったからです。

しかしながらその些細な不安は全くの杞憂で、リモートワークを前提として、それを当たり前のものとして過ごしていました。ただただ、たった一本のイーサネットケーブルを介してよくもこれだけの情報や感情をやりとりできるものだと驚きを感じています。

情報がオープンであること

リモートワークでうまくやれている理由の一つとして社内の情報がオープンであることが挙げられます。社内規定や手続・制度の情報にアクセスしやすいだけでなく、サービスに関する情報 (お客様の個人情報などは除く)、はたまた人事評価資料までもが社内でひろく公開されています。

オンラインで活動する上で情報の非対称性は非常につらくて、大学時代に研究室で「昔の研究に関する情報が必要だったら声をかけて」と言われていたがそもそもどんな情報があるのかがわからない.. といった経験をした身からすると、入社後にすぐに様々な情報にアクセスでき会社のことをよく知れることはリモートワークでの安心感を生みました。

Slackの流れる早さ

物理的なオフィスに出社していない私は、Slackに出社していると言っても過言ではないでしょう。 Slackでの会話が活発で円滑であるからこそ、オンラインでも距離感を感じずにコミュニケーションをとることができます。

出社の様子

研修についてもSlackをフルに活用しています。講義をきく機会も多かったのですが、そういったときに講義の解釈を話しあったり、他の人が知る関連情報を得られたり、些細な疑問を話してみたりといった会話が生まれます。同期のやぎじんの言葉を借りるとまさに「隣の人と話しながら講義を受けることができる、新しい研修のかたち」でした。

講義を担当されたパートナー²の方にも「リアクションがあるので話しやすい」と言っていただけたし、ただ聞いてメモをするより話も広がり講義を振り返る補足資料にもなり、加えて記憶の定着も良いように感じ、楽しいだけでなく大変有意義な時間でした。オンラインだからこそできた研修であったように思います。

1時間程の講義でどんどん流れるSlack

意識していたこと

リモートワークの環境において、新卒として入社した自分もうまくやるために「自分の感情・状況を相手に伝える」ことを意識していました。³

例えばMeetやZoomでは伝わりづらいので大きく🙆‍♂️と意思表示するなどジェスチャーしたり。日報では自分の感情を正直に書くことも、困っていることや疑問があったら自発的にSlackに書き込むこともその一つです。発言しやすいように複数のチャネルを使いこなす意味で、Slackの個人用パブリックチャンネルを作ってみたりもしました。ほかには背景で遊んだのも新卒11期生のパートナーの方々と仲良くなりたい気持ちだったと思います。

オンラインではどうしても些細な気持ちの変化は伝わりづらいし一対一でコミュニケーションをする機会も減ってしまいます。だからこそ自己開示が必要であると思うし、より自分から状況や感情を伝える必要があります。

新卒研修においてオンラインでのコミュニケーションが円滑に進んだのはきっと、入社前から培われたペパボの文化と既に日常となっていたリモートワークの土壌があったからでしょう。リモートワークには様々なツールの活用や制度の整備ももちろんですが、個々人がオンラインに即したコミュニケーション方法や振る舞いに適応していくことがとても大切であると感じました。

オンラインに即したコミュニケーションはきっと社内でたくさんの人が実践していることではないかと思います。他の人や同期を見て学び、真似て、上記のような意識していたことに繋がりました。

まとめ

とても楽しく充実した一ヶ月でした。研修の中で新しく学んで吸収すること、業務の難しさとそれに取り組まれるパートナーの方々の凄さを知ることなど、多面的な切り口からの研修を通して、目的とされていた「ペパボで働く土台をつくる」は達成されたと思います。⁴

入社を歓迎してくださったパートナーの皆さん、研修を企画・実施してくださったパートナーの皆さん、一緒に盛り上げてくれた同期の仲間、本当にありがとうございました。

一ヶ月働いた実感として、ペパボの人々はとてもおもしろくて親切であるし、サービスを使う意味でも働く意味でもおすすめできる会社です。

技術研修は5月以降も続きます。サービスを、ペパボを、世の中をもっとおもしろくできるよう⁵、まずは目の前の研修に一つ一つ取り組んでいきます。

記事内であまり触れていない研修内容については他の人が書いたブログが参考になります。「🌸【21卒】ペパボでの新卒研修を終えて🌸｜きなこ｜note」や「社内研修振り返り | zuruzurura.men」など。その他にも子育てと新卒研修に触れたブログ記事「子育て新卒、ペパボで働き始めて1ヶ月｜うえだり｜note」も読み応えがあります。 ↩
ペパボでは働く仲間のことをパートナーと呼びます。 ↩
入社前にも教えていただき、新卒研修の中でも触れられていたブログ記事 (自分の気持ちを正しく表現する | けんちゃんくんさんのWeb日記)がもとになっています。新卒の私が正直な感情を伝えるとそれを受け止めてくださるパートナーの方々がいることは本当にありがたいことです。 ↩
各研修内容のそれぞれに目的や目標が設定され何のために研修に参加するかが明確であったこと、定期的に時間を設けて振り返ることなど、研修を有意義なものにするための工夫が随所に凝らされていたと振り返りながら感じました。 ↩
「もっとおもしろくできる」はペパボの企業理念)です。 ↩

ブログをNext.jsに置き換える

Fri, 07 May 2021 13:07:57 GMT

ゴールデンウィーク明けの平日、いかがお過ごしだろうか。私の場合は新卒研修のブログ記事を書こうと思ったものの、その記事を投稿するためのブログを弄っているうちにゴールデンウィークが終わってしまった。

そんなわけでここ数日は、「そろそろちゃんと触るか〜」と思っていたNext.jsを使ってこのブログを作り変えていた。見た目は似ているけど中身はイチから作ったので別物である。¹

機能追加をしたいことがあったりしたので前々からJavaScriptのフレームワークに載せ替えたいと思っていて、やっと腰が上がった次第。² 本当は1,2日でサクッと終わらせてしまってブログ投稿用のエディタを作ろうと思っていたのだけど全然思うようには進まず、結局閲覧画面だけ作って終わった。

以下にここ数日の感想をいくつかの話題に分けて記す。

ブログのデザイン

デザインは変わっていないようで細かいところが少し変化したり、機能追加されていたりする。つくりながら他のブログを眺めるなどして、見やすそうな部分を参考にしたりした。

具体的には例えば、記事ページ末尾にある隣の記事へのリンクについて。よくこういったリンクは next / prev とやってしまいがちだけれど、どっちが古い投稿へのリンクでどっちが新しい投稿へのリンクかわからなくなったりするので、「古い記事」「新しい記事」と書いてあるのをみて「良いな」と思ったので真似た。

ブログのデザインといえば、完成の見た目が定まっていなかったので結構作っては壊してを繰り返していたのは効率が悪かったのかもしれない。例えば記事一覧ページは記事ごとにカバー画像を表示するように作ってみたあと、やっぱりみづらそうで止めた。 figmaなどを使って事前にどんなものを定めるなど、そういうのをやったほうがよかったかもなあ。 (やったことない。)

remarkがよき

Hugoから置き換えた理由の一つに、Markdownのパースを改造できるようにしたかったからというモチベーションが有った。今回使ったMarkdownパーサのremarkがよく出来ていて、プラグインを追加するとパース時の機能や記法を追加できる。既によくあるMarkdown記法は既存のプラグインで対応できるし、新たな記法を追加するときはプラグインを作ってMarkdownやHTMLのASTに介入できるようで夢が広がる。

本当はここらへんを重点的に開発して記事の執筆時に使える記法や記事の出力時の見た目をもっとリッチにしたかったのだけど、Next.jsでブログを作る時点で時間切れになってしまった。

Next.jsのよさ

Nuxt.jsみたいにフォルダ構成をはじめとした規約が定まっていて、秩序を感じるのはよい。

簡単なAPIが書けるのもよい。Vercelを使えば一緒にデプロイもできそうで、ここらへんは開発元がホスティングサービスをやっている強みだなと感じた。

getStaticPropsとかgetServerSideProps、getStaticPathsとかの関数があるのもよくて、何処に何を書けば良いのか、いつ何処で実行されるのかがわかりやすいのが良い。 Nuxt.jsではここらへんどうなってたっけ？configでSPAかSSRかSSGか選べたのは覚えているんだけど...

ReactとJSXの記法への小言

Reactに触ったのも久しぶりで、JSXと後述するCSS-moduleに一言ずつ。

JSXを久々に書いたがちょっと書きづらい。特にDOMを条件分岐したいとき、その部分のJSXElementは変数に入れるのが良いのか最後のReturn文に埋め込むのが良いのか迷うなどした。埋め込むとしたら即時実行関数の中でifを書くか三項演算子を使うかだと思うけど、どちらも記号だらけであんまり見やすい表記じゃなさそうと思った。 Vue.jsのv-ifとかのほうがみやすさを感じる。

Vue.jsの独自記法を覚えなくていいといえばそうだけど、その意味で言えばVue.js/Nuxt.jsはJSX覚えなくていいからな。 (逆にJSXElementを繰り返すときは配列をmapできるのでスッキリ書けて気持ちいい。) 記法は慣れの要素が多分に含まれるので、小言を言っても仕方ないね。

CSS-moduleはつらくないか？

前項のJSX記法は好みの問題と思うが、一方でCSSの適用方法については根が深い。もともとReact/Next.jsでコンポーネントにCSSを適用するならCSS-moduleかCSS in JS (Styled components)の2種類の方法から選ぶらしい。特にNext.jsはパフォーマンスの理由でCSS-moduleを推してるのだけどこれがあんまり良いと思えなかった。一般的なCSSはセレクタを使って適用する要素を決めるが、CSS-moduleはCSSのスタイルの集合({から}まで)を、HTML要素で指定して指し示すような形になる。

CSSが多重に適用されることはなくなるのでシンプルになるけれど、一方で宣言的に書けていたCSSの良さを殺しているのでは？と感じた。あとメディアクエリが使えない/使いづらかったり、するのも気になった。結局移行前のものを活かすという意味もあって、CSS-moduleもCSS in JSも使わずに1枚のCSSにすべてを書き込んで作っていて、途中でCSS-moduleで分割するかとなったのだけど上述のつらみを感じて止めてしまった。

今回の開発を通して改めてVue.jsのシングルファイルコンポーネント好きだなあと感じた。

---

そんなこんなで予定がなくなってずっと家にいたゴールデンウィークだけれどコンピュータと仲良くなろうと遊んでいたのでよき休日だった。

このブログへの機能追加はまだまだやりたいことだらけですが、もし見づらい、バグってる、勘違いしたなどあったらフィードバックをくださると喜びます。

前はHugoのテーマに手を入れたものをNetlifyでホストしていたけど、今回はNext.jsとTypeScriptで作ったサイトをSSGしてVercelにホストしている。どちらも記事はGitHub上にMarkdownで保存している。 ↩
先月と先々月に作っていたバージョン管理システムのarcivは、とりあえず動くけどなんか動作が遅いよなという状態で放置されている... そっちはどうしようか... ↩

融けるデザインを読んだ

Thu, 29 Apr 2021 08:01:00 GMT

このまえ教えてもらった本、「融けるデザイン ―ハード×ソフト×ネット時代の新たな設計論」(著: 渡邊恵太) を読んだ。以下はその解釈と感想である。

融けるデザイン ―ハード×ソフト×ネット時代の新たな設計論 | 渡邊恵太 |本 | 通販 | Amazon

本書では「自己帰属感」という言葉を通して良いインターフェイスとはどのようなものかを述べている。自分の与えた動作に伴ってリアルタイムに反応があると自己帰属感が生まれ、自己帰属感が高まると身体が拡張したかのように思いのままに操作できるようになる。

例えばキーボードは、慣れるまではひどく使いにくいが、慣れてしまえば文字を打つときに自然と手が動き自分の身体の延長のように扱える入力機器だと思う。車だって自分で運転することに慣れてくれば車体感覚が身につき狭い道路でもなんとなく車を端に寄せたりできるようになる。キーボードも車も、手で握るハンマー等よりよっぽど複雑な道具だけれど、慣れてしまえばそこそこの自己帰属感を得られるようになる。¹

こういった自己帰属感の有無には自分が与える動作に対する遅延ない応答が必要なようだ。一方、動作の方向や方法は、慣れが要求できる範囲においては遅延ない応答ほどは重要度が高くなさそうに思う。たとえば車のアクセルもブレーキもペダルを踏む動作だが加速と減速という正反対のものを扱うし、キーボードもボタンを押下することで抽象的な概念である文字の入力を行う。

本書を読んだうえで、じゃあ自分がソフトウェア開発 (特にWeb開発) を行うときにどう活かせるかというと結構難しい。本書ではどうやって作るかやGUIにおいて何が良いのかを具体的に示しているわけではなくもっと抽象度の高い話をしている。²

その中で"遅延"がユーザに与える自己帰属感の低下はWeb開発でもイメージしやすいものだろう。たとえば遅延ない応答の具体的な例といえば、いいねボタンを押したときに押した瞬間に表示を変更しサーバへのリクエストは裏で送るといった実装がその１つかもしれない。

そういったユーザとのインタラクションにおいて遅延がいかにユーザに自分の思い通りに操作する感覚を失わせるかを知ることができた。開発者からすると微々たる違いであるのにユーザには大きな違いとして現れることは意識して開発するとよいだろうと感じた。

本書を読んだ解釈が「全然ちげえぞ！」と思ったら教えて下さい。

もちろん慣れが必要ないに越したことはない。しかしながらキーボードも車も、ユーザ体験が優れている設計かは別として、世界的に共通のインタフェースを備えているのは一定の自己帰属感が感じられる道具だからだろう。 ↩
本書の「融けるデザイン」というタイトルにもなっている主題は「ハードウェアかソフトウェアといった違いに縛られず、自己帰属感という尺度をもとに人間と環境との相互的な作用を考えてプロダクトを設計しよう」といった話だと思う。しかしながらここでは画面内で描画されるWebブラウザとそれをタッチパネルやマウスやキーボードで操作する入力機器に限定した話を取り上げた。 ↩

足でマイクのミュートを解除しよう for 在宅勤務

Tue, 27 Apr 2021 00:41:29 GMT

私はいま、在宅勤務をしている。特に研修中だからかオンライン通話の機会が多く、通話しながら作業や調べ物をするので、マイクのミュート/ミュート解除に手こずることに悩みを抱えている。そんな中、ふとしたときに気づいたのである。「足が空いているではないか」と。

家に左クリックが壊れたマウスが有ったのでこれをフットスイッチ代わりにして、押しているときだけミュート解除するようにしてみた。

こちら、机の下に置かれた不審なマウスです。 pic.twitter.com/DWxn3oxcLM
— やんまー (@yammerjp) April 26, 2021

どのように実現しているかは後半の「つくりかた」に書く。

良いところ

細かくミュート/ミュート解除できる

目論見どおりうまく動いており、概ね快適である。鼻をすする音など些細な音が入らずに済むのがすこぶる良い。例えば相槌をうちながらキーボードを打つときや、ZoomやGoogle Meet以外のウィンドウ・タブを操作しながら話すときなどに助かる。スムーズにミュート解除できるので、些細なリアクションのときだけミュート解除するみたいなことができる。スイッチを押したとき/離した時のタイムラグも (周りに聞く限り) 問題ないようでで常用できそう。

改善すべきところ

ペダルが踏みづらい

良いところもある一方、まだ道半ばだと感じる部分もある。例えばマウスの右クリックボタンは小さいため、少し足を離していると何処にあるかわからなくなる。すると目視で確認しないと踏めないので発話がワンテンポ遅れる。ピアノのペダルのようなもっと踏みやすいものに変えたほうがよさそう。

慣れないので間違える

ペダル操作は慣れが必要で、踏み忘れて話しはじめてしまったり、逆に足を外して音を立ててしまったりすることも有った。「キーボードや手元のマウスを操作すること」「足でミュート解除すること」「話すこと」の3つを同時にやろうとすると頭の中がついていかずスムーズにできない。慣れればペダル操作が無意識でできるようになることを期待しているのでしばらく使っていきたい。

ミュート/ミュート解除のソフトウェア制御が怪しい

もうひとつ、ミュート/ミュート解除をソフトウェア的に制御する方法が怪しい。 macOSの仕様がよくわからないのだが、OS側でマイクをミュートにする方法が見つけられずボリュームを最小にすることで擬似的にミュートにしている。アプリケーションの種類に左右されずに、さらにウィンドウがアクティブでないときも操作したいので、いまは OS 側の設定をシェルから叩いている。

# マイクをミュート
$ osascript -e "tell application \"System Events\" to set volume input volume 0"
# マイクをミュート解除
$ osascript -e "tell application \"System Events\" to set volume input volume 100"

今日Google Meetで話した感じではミュートされているようだったが、Zoomで試した感じだと最小でもすこし音が入っていた。もし他にいい方法があれば知りたい。 (電子工作つよつよマンならマイクケーブルをスイッチで電気的に切断してミュートできそうだけれど、操作時のノイズなども出てきそうなので一旦ソフトウェア的に切り替える方式で考えている。)

感想

働き始めて3週間、在宅勤務にはきっと在宅勤務なりのスキルが必要だなあと感じる。たぶん自分がいままで属してきた他のコミュニティでは今の会社のようなオンラインコミュニケーションを取るのは難しかったように思う。何が難しいのかは言語化しづらいのだが、きっと会社の中で今まで積み上げられてきた様々な知見や文化が関与していそう。

在宅勤務なりのスキルとは、チャットコミュニケーションの円滑さや、オンライン通話のテクニックも含まれるだろう。例えば画面越しでは感情が伝わりづらいので大きなリアクションをするとか、話し始めがかぶりやすいので細かいところでも誰かがファシリテーションしたり事前に挙手したりするとか、そういったことの積み重ねが大切に感じる。その要素のひとつにミュートを使いこなすこともあって、雑音を入れない意味でも大きなリアクションを伝える意味でもスムーズに切り替えられるとよさそう。今回のペダルでの操作がうまい方法かわからないが、画面上のボタンだとミュート解除が遅れて困る機会がときどき有ったのでそれらを解消できるとよいね！

つくりかた

既にだいぶ書いたが、やっとここからつくりかたを説明する。

今回の仕掛けは、macOS に接続した USB マウスと Karabiner-Elements というソフトウェアから成る。足元に置いたマウスの右クリックを検知し、マウス押下時にミュート解除のシェルコマンドを、押下を止めたときにミュートのシェルコマンドを実行している。

これは私がいらすとやの画像を使いたかったことを表す図です。

さあ作っていこう。

1. Karabiner-Elements をインストール

Karabiner-Elementsはもともとキーボードの操作を書き換えるソフトウェアで、例えばCapsLockキーをCtrlキーに置き換えるだとか、Spaceキーを長押しするとShiftキーが押されたことにするといった設定ができる。ついでにマウスの入力も扱えるので、今回は特定のマウスがクリックされた時にコマンドを実行するよう設定ファイルを書くことにする。

まず Karabiner-Elements のサイトからファイルをダウンロードしインストールする。¹

初回起動すると、macOS のセキュリティ許可などを設定しろだとか再起動しろだとかいわれるはずなので従う。以降はログインすると勝手に Karabiner-Elements も起動して、メニューバーに四角形のアイコン ()が表示されて常駐する。

2. デバイスを有効化する

メニューバーの Karabiner-Elements アイコンをクリック > Preferences... > Devices タブを開く。

この状態で足のスイッチにしたいマウス²をコンピュータに挿して、新たに表示されたデバイスの行の左端のチェックボックスを有効にする。他デバイスのチェックボックスを有効にすると、他デバイスの入力も奪って設定を反映してしまう可能性がある。入力を上書きしたいデバイスのみにチェックをいれること。

3. 設定ファイルを記述

~/.config/karabiner/assets/complex_modifications/mouse_mic_mute.json を作成し、次の内容を書き込む。³

{
  "title": "Unmute/Mute mic with clicking mouse",
  "rules": [
    {
      "description": "Unmute/Mute with mouse button down/up",
      "manipulators": [ {
        "type": "basic",
        "from": {
          "pointing_button": "button2",
          "modifiers": { "optional": [ "any" ] }
        },
        "to": [ {
          "shell_command": "osascript -e \"tell application \\\"System Events\\\" to set volume input volume 70\""
        } ],
        "to_after_key_up": [ {
          "shell_command": "osascript -e \"tell application \\\"System Events\\\" to set volume input volume 0\""
        } ]
      } ]
    }
  ]
}

設定をカスタマイズするとすれば、たとえば pointing_button を button1 にすれば、左クリックを対象にできる。その他の設定は公式の説明や Qiita の記事を参考に。

4. 設定を有効化

メニューバーの Karabiner-Elements アイコンをクリック > Preferences... > Complex modifications タブを開く。

右下の「Add rule」を押し、「Unmute/Mute with mouse button down/up」を「Enable」する。

ここまでの操作でミュートをいい感じに操作できるはず。なお、マウスの裏側には黒い紙を貼ってポインタが反応しないようにしている。左クリックなどが反応しないのはマウス自体が壊れているからっぽい。もし通常のマウスを使う場合はKarabiner-Elementsの設定で、各ボタンの入力について"to": [{}]といった何もしない設定を追加すると良さそう。

以上。

$ brew install karabiner-elementsでもインストールできるはず ↩
今回は手元に壊れかけのマウスが有ったのでこれをスイッチとして使ったが、キーボードなどでも同様のことを実現できるはず。また何も足で押さなくてもよくて、机の上にスイッチがあるとか既存のキーボードにショートカットキーを定義するとかでもよいかもしれない。 ↩
既にマウスに関する Karabiner-Elements の設定が存在する場合は、ぶつからないように、Vendor ID と Product ID をメモして設定に書き込むと良さそう。参考までに私の設定ファイルはこれ。 ↩

ロリポップ上に公開された WordPress サイトを、ローカルの docker-compose 上で再現する

Fri, 23 Apr 2021 18:41:20 GMT

表題の通り、ロリポップ！レンタルサーバ上に公開されている自身のWebサイトをバックアップし、さらに手元のPC上にdocker-composeで動作するように配置する。

前提の環境

ロリポップ！レンタルサーバ上で WordPress を用いた Webサイトを構築している。
macOS 10.15 Catalina
Docker Desktop for Mac がインストールされている
wget がインストールされている。 (Homebrew を用いて brew install wget でインストール)

手順1: ロリポップ上の情報をダウンロード

1-1: ファイルを抜き出す

はじめにロリポップ！ユーザ専用ページ > ユーザー設定 > アカウント情報を開いてアカウント情報を確認する。今回は以下の内容であったとする。


FTPS サーバー	`ftp.lolipop.jp`
FTP ・WebDAV アカウント	`chu.jp-user`
FTP ・WebDAV パスワード	`password`

次に、ターミナルから以下のコマンドを実行する。 ftp を使って、階層の深さ制限なしに再帰的にファイルをダウンロードする。

$ mkdir -p ~/lolipop-backup/download && cd ~/lolipop-backup/download
$ wget -r -l 0 "ftp://chu.jp-user:password@ftp.lolipop.jp"
# (ホスト名、ユーザ名、パスワードは適宜置き換えていただくとよし)

ちなみに私の場合は8分で200MB弱をダウンロードした。

1-2: データベースを抜き出す

ロリポップ！ユーザ専用ページ > サーバの管理・設定 > データベースを開く。
データベース名をメモする。今回は LAA0000000-xxxxxx であるとする。
phpMyAdmin を開く。
ログインして、画面左のデータベース名を選択 (今回で言えば LAA0000000-xxxxxx)。
"エクスポート" タブを開く。
エクスポート方法: "詳細 - 可能なオプションを全て表示" のラジオボタンを選択。
生成オプションより追加コマンド: "CREATE DATABASE / USE コマンドを追加する" にもチェックを入れる。
他はデフォルトのままで、ページ左下の "実行" をクリック。
ファイルがダウンロードされるので ~/lolipop-backup/downlaod/LAA0000000-xxxxxx.sql に移動させる。

手順2: ローカルにWordPress環境を構築

2-1: docker-compose.ymlを整備する

~/lolipop-backup/docker-compose.yml を作成し、以下の内容を記述する。 - MYSQL_DATABASE=LAA0000000-xxxxxxの行についてのみ、イコール以降に各自のデータベース名を書き込む必要がある。

# docker-compose.yml
version: "3"
services:
  db:
    image: mysql:5.6
    container_name: "mysql"
    volumes:
      - ./db:/var/lib/mysql
      - ./db-init:/docker-entrypoint-initdb.d
    restart: always
    environment:
      - MYSQL_DATABASE=LAA0000000-xxxxxx # この行は各自で記述
      - MYSQL_USER=user
      - MYSQL_PASSWORD=password
      - MYSQL_ROOT_PASSWORD=root
  wordpress:
    image: wordpress:5.7.1
    container_name: "wordpress"
    volumes:
      - ./wp:/var/www/html
    restart: always
    depends_on:
      - db
    ports:
      - 8080:80
  phpmyadmin:
    image: phpmyadmin/phpmyadmin:latest
    container_name: "phpmyadmin"
    restart: always
    depends_on:
      - db
    ports:
      - 8888:80
    environment:
      - PMA_ARBITRARY=1
      - PMA_HOSTS=mysql
      - PMA_USER=user
      - PMA_PASSWORD=password

2-2: 抜き出したファイルを設置する

# 抜き出したファイル群を設置
$ cp -r ~/lolipop-backup/download/ftp.lolipop.jp ~/lolipop-backup/wp
# 上の行はロリポップ側でルートディレクトリに WordPress を設置している場合である
# ルートディレクトリ以外に WordPress を設置している場合は、index.php が wp ディレクトリの直下に配置されるようにコピー元のディレクトリを指定する

# 抜き出したデータベース初期化情報を設置
$ mkdir db-init
$ cp ~/lolipop-backup/download/LAA0000000-xxxxxx.sql ~/lolipop-backup/db-init/

2-3: WordPressの設定を変更

WordPress の設定が記述されたファイル ~/lolipop-backup/wp/wp-config.php を編集し、WordPress が正しくデータベースに接続できるようにする。

define('DB_USER', '...'); →define('DB_USER', 'user');
define('DB_PASSWORD', '...'); →define('DB_PASSWORD', 'password');
define('DB_HOST', '...'); →define('DB_HOST', 'mysql:3306');

2-4: Search-Replace-DB を設置

のちほど、データベース内のURLを書き換える必要があるため、書き換えに用いるツールを配置する。

$ git clone https://github.com/interconnectit/Search-Replace-DB.git ~/lolipop-backup/wp/Search-Replace-DB

2-5: Apache の設定を変更

トップページ以外のページのURIを開いた時も、ApacheではなくWordPressに処理して欲しいので、リクエスト先をindex.phpに向ける必要がある。 ~/lolipop-backup/wp/.htaccess に以下を記述する。

# .htaccess

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

手順3: 起動する

3-1. Dockerコンテナ群の立ち上げ

Dockerコンテナを立ち上げて、バックアップしたページが表示されることを確認する。

$ cd ~/lolipop-backup
$ docker-compose up -d
# 少し待つ (10秒とか。初回起動時はDBを初期化するので、立ち上げた瞬間にアクセスするとエラーが発生して開けない。開けないだけだが)

$ open http://localhost:8080
# トップページが開けることを確認する
# この状態ではリンクを踏むと、localhost ではなくWeb上のページに飛んでしまう

3-2. データベース内のURLの置換

WordPressのデータベース内では、URLが絶対パスで保持されているらしく、ここまでの手順では、ページ内リンクを踏むと、バックアップ元のWebサーバのページに飛んでしまう。この手順では、データベースを書き換えて、リンクを踏んでもローカルのページを回遊できるようにする。

今回は www.example.com に設置されたWebサイトをバックアップしているものとする。

1.Search Replace について

http://localhost:8080/Search-Replace-DB を開く。
replace (search for...) に http://www.example.com、with (replace with...) に http://localhost:8080 を入力
- add more search terms をクリック
replace (search for...) に https://www.example.com、with (replace with...) に http://localhost:8080 を入力

2.Database Details について

database name にデータベース名 (LAA0000000-xxxxxxなど) を入力
username に user と入力
pass に password と入力
host に mysql と入力
port に 3306 と入力

Test connection を押して、「Success. You are connected.」と表示されることを確認する。

3.Which Tables? について

ラジオボタンが all tables を選択していることを確認する。

4.実行

入力に誤りがないことを確認して、不安なら「Do a safe test run」をしてみたあとに、「Search and Replace」を実行する。

ここまでの手順を踏めば、http://localhost:8080 上で正しくページが表示され、リンクを踏んでもローカルのページに飛べるはず。

うまくいかないとき

「データベース接続確立エラー」と表示される。

まず、wp/wp-config.php の中が正しく書き換えられているか確認するとよさそう。 WordPress に接続した時に「データベース接続確立エラー」と表示される場合は、docker-compose.yml 内のホスト名(今回はmysqlコンテナの3306番に公開されたポートを観に行くので mysql:3306)・データベース名・ユーザ名・パスワード、初期化用sqlファイル内の CREATE DATABASE の行にあるデータベース名、wp-config.php の中にあるホスト名・データベース名・ユーザ名・パスワードが一致しているかを確認してみる

WordPressのサイトが開けない。「サイトに重大なエラーがありました。」と表示される。

wp-config.php の中で define('WP_DEBUG', false); の行を define('WP_DEBUG', true); に書き換えるとデバッグモードになってエラーが表示されるので原因究明につながるかもしれない。ちなみに ftp でファイルをダウンロードするとき、wget コマンドに -l 0 オプションを指定しないと途中の階層までしかダウンロードされず、ファイルが欠けてWordPressが起動しなくなる。

Webページを開くとApacheの404エラーページが出る。

.htaccess ファイルを設置して、リクエストしたURIに関わらずindex.phpで処理するように設定するとよいかも。

僕の、私の、ストレングス・ファインダー (感想)

Mon, 19 Apr 2021 14:45:00 GMT

会社の研修でストレングス・ファインダーを受けたので、結果を過去の経験と照らし合わせて考えてみます。読書メモみたいなものです。

ストレングス・ファインダーとは

1998年に心理学者のドナルド・O・クリフトンが開発したオンライン心理テスト。「実行力」「影響力」「人間関係構築力」「戦略的思考力」の4領域に分類される34の資質のうちどれを自分が持っているのかを判断してくれる。それぞれの資質を知ることで自分の能力をどのように開発していけばよいかの参考になるらしい。書籍「さあ、才能(じぶん)に目覚めよう新版ストレングス・ファインダー2.0」に付属するアクセスコードから受けることができる。なお以降に挙げる引用の出典はすべてこの書籍である。

結果

私の持つ資質の上位5つは高いものから順に、分析思考、学習心、収集心、ポジティブ、個別化 らしい。前半3つが「戦略的思考力」に、後半2つが「人間関係構築力」に分類されるもののようだ。これらの資質をひとつずつみていく。

分析思考

分析思考とは、データを好み物事の理由と原因を追求することを好むことを指す。

〈分析思考〉の資質を持つあなたは、他の人に「それを証明しなさい。貴方の主張がなぜ正しいのか示しなさい」と強く要求します。このような詰問を受けると、自分のすばらしい理論がもろくも崩れ落ちるのを感じる人もいます。(p186)

書籍に書かれた上記の文を読んで、他人と議論しているときにまさに自分がよく考える話だと感じた。つい先日の研修でのグループワークでも、自分が建設的な意見を出せているわけではないのに、他人の意見の実現可能性が気になってしまっていろいろ質問したくなってしまった。悪い方向に走ると意見を潰すような振る舞いになってしまうが、今ある情報からどう判断できるかということをしっかり伝えていくのは必要なことだと思うので、人の意見を良い方向にブラッシュアップできるような発言ができたらよいね。

あわせて「内容に対しての見解を言うこと」と「人格攻撃をすること」は別であるという点には注意しておきたい。本書のアドバイスの中で「あまりキツイことは言い過ぎないように」とあって、わかるし気をつけたいよな〜、改めて心に刻もう、と思った。

学習欲

学習欲のある人とは、知識を得る状態になることや知識を得た状態だと認識することに満足感を覚える人のことらしい。

私はコンピュータを触る・学ぶことの面白さに「ブラックボックスを紐解くことが楽しい」ことを挙げることがある。コンパイラや認証などを再実装してみたり、大学で既存のソフトウェアに関する講義に興味をもったりしたのは、掘り下げてどう動いているのがわかると楽しいからという理由が強い。

もっと遡れば小学生の頃、掃除機やラジオなどの古い電化製品を分解していたのを思い出す。自覚はしていないが、新しい知識を獲得して学習するプロセスに実は満足感をもっているのかもしれない。

学習欲の高い人に向けて本書では次のようなアドバイスが挙げられている。

変化を起こす人になりましょう。他の人達は新しい規則や技術を導入したり、環境を整備したりすることに尻込みするかもしれません。(p53)

技術や規則が常に変化する分野にキャリアを変更しましょう。これに対応しようと挑戦し続けることであなたはいきいきとします。(p53)

ソフトウェアエンジニアを職業に選んだのは正解だったようだ。常に環境が変化する状況で新しいものをキャッチアップし続けることが特に必要な業種だと思うので、変化を受け入れてそれについていける、さらにはそういった流れを作れるような人材になれると良いですね。

収集心

(ここでいう) 収集心とは、物理的な物の収集欲に限らず、情報を収集することを好む人も含んでいるらしい。たしかにWikipediaは永遠に見れるタイプだし、旅行に行く前には調べるタイプだし、社会のものがどう動いているか仕組みを知りたいみたいな気持ちは強いかもしれない。本も電子派だけど紙を捨てるときはスキャンするし、Google フォームの内容や一時的な目的のために配られた資料も保管しておきたくなったりする。

情報を保管し、簡単に探し出すことができる仕組みを考案しましょう。(p121)

本書には上のようなアドバイスが書かれていて、これは自分が課題に感じていることの１つだ。メモをとったり思考を整理したり、それらの情報にアクセスするためのツールが定まっていない。数年前は Google Keep を使っていたが、いつ記録した情報かが残りづらく使うのを止めた。

今だとたぶんScrapboxとかNotionとかになるのだろうけど、どちらも全然使いこなせていない。こういったアプリケーションは移り変わりが早いのでロックインされたくなくてMarkdown最強説を唱えるときもあったものの、メモを集めたgitリポジトリも整理されてアクセスしやすい状況とはいえないな。どうにかせねばなあ。

ポジティブ

ポジティブが上位に入っているのは嬉しい。

昔 (これまた小学生くらいの頃) は自分をネガティヴだと自覚していて、自分のことを説明するときはネガティヴだと言っていた。しかしネガティヴな自分が嫌で、無駄に自分や他人を落ち込ませるような気がして、いつからか言霊でもいいからなるべく言葉では無理矢理でもいいからポジティブになるような発言を心がけていた。

いつしかそうやって言霊だと思っていた考えが自分の中のポジティブな思考として定着して、物事を悲観的に考えずに済むようになった。今回のテストで上位に上がってきたことをもって「自分がポジティブな思考を持った」と言えるようになったと思う。自分の性格は自分で変えられることを示たので嬉しい。

日頃から楽しい話や冗談などを準備しておきましょう。(p201)

誰も傷つけないで笑いをとりたい。面白い話ができる人になりたいね。

個別化

個別化の資質を持つ人は、一人ひとりのユニークな個性に興味をそそられそれを理解することに長けているらしい。これは正直よくわからないけど、自分のわがままを持っているから他人のわがままも受け入れあえたら幸せだよなと思っている。

チームの各メンバーが最も得意とすることを見極めましょう。(p89)

上のようなアドバイスが示されているが、そうやって得意なことを生かしたチームがつくれたら最強だよな。あまり共感と理解ができてないのでこの項はさっくり終わる。

まとめ

自分の資質は4領域のうち「人間関係構築力」「戦略的思考力」に偏っていて、「実行力」「影響力」は強みではないらしい。実際のところ実行力も影響力もないのはなんとなく同意してしまうな。しかしながら働いていく上ではこれらもある程度必要だと思うので、どうカバーできるか考えていきたい。

そもそもこういった心理テストは「答えを見たときに自分の中で当てはまりそうな行動や理由を見つけて納得したような気になる」ことがよくあるように思う。さらにストレングス・ファインダーの結果は時間が経てば変わることもあるらしく「絶対的な自分の能力」ではなく「今の自分にとっての強みとなりうる要素」を表すものらしい。

今回の結果が実際のところどれほど適切な指摘をしているのかはわからないが、今後の仕事での振る舞いや方向性を決めていくための自分を振り返る機会になった。今回の内容を過信しすぎず、しかしながら自分の行動を律するときの一つの指標として適切な距離感で捉えておきたい。

社会人一週目の所感

Thu, 08 Apr 2021 15:57:25 GMT

4/1に社会人になり一週間が経った。職種合同での研修期間中で実際の仕事やエンジニアリングとはまだ少し距離がある。研修もまだまだこれからだけど、区切りが良い日なので今日の気持ちを記録しようかと。

生活について

まず当たり前だが、社会人は結構疲れる。 3月末までは一日中暇で、好きなだけコードを書き好きなだけネット見て好きなだけ寝ていたので差が大きいだけで、毎日朝から夕方まで集中していたら人間誰でも疲れるだろう。睡眠は本当に大事。一昨日つい睡眠時間を削ったら昨日は一日中眠くて、仕事終わった直後にベッドで爆睡した。これができるから在宅勤務は良い。通勤が無くて良い。慣れてしまったら毎日出社なんてできない人間になる気がする。

あとは時間を大切にしたくなる。研修後にレポートを書くのだが、疲れたからゆっくりやるかと思うとそれだけで凄く時間がかかる。 1日がすぐに終わってまた朝になる。逆にテキパキすれば時間はたくさんあって(通勤時間ないし残業もないし)、朝に本を読んだりできるし、こうやってブログを書くこともできる。休むときはしっかり休む、集中するときはガッとやる、意識的に時間で区切っていきたい。

区切るといえば、リモートワークなので自室で寝て自室で働くのだが、自分の緊張感を意識的に切り替えるために2つのことを決めた。

ドアを開ける ... 始業中で会話をしているときにドアを閉めるのは当然として、それ以外の時間は開けるようにしている。空気も入れ替わるし、心のスイッチにもなるし、同居の家族も「今は声をかけていいのか」が明確にわかるので良い。
早く風呂に入る ... 終業後に気分を緩めるために風呂に入るのがいい。ゆっくり出来るし体に水を浴びると気分が変わる。あと風呂に入ることを面倒に思う人種からすると、入るのが後回しなり夜ふかしすることを避けられるのも良い。

ほかにも、時間のあるときに本を少しずつ読み進めてみている。 (いままでは気分がノッたときに一気に読破することがほとんどだったが、平日はまとまって時間取るのも難しそう。) しかしながら少しずつ読むと、翌日になったら以前の内容を忘れていたりして内容を掴みづらいと感じる。打開策として、手の感覚などからどこまで読んだかという情報が記憶に残りやすいのではないかと物理本を注文してみた。本を裁断して自炊するほど電子書籍を好んでいたので物理本はだいぶ久々な気がする。効果はあるだろうか、どうかな？

研修について

話は変わって研修について。講義形式のものとチームで課題にとりかかるものの2種類があり、講義形式のものはいろいろな学びがあった。ビジネスマナーの習得機会でもあったし、自分は将来の夢や目標が明確でないことがわかったし、会社について理解を深めたつもり。

一方、チームで課題に取りかかるものは結構大変だった。

ひとつは答えのない問題に対しての解決策を限られた時間で議論すること、導くことの難しさ。 (就活でグループワークの練習をしたときのことを思い出した。結局選考ではやってないが。) 途中で焦って方向性のハンドリングをミスったような気がしたけど、優秀なチームメンバーのおかげで終わってみると案外丸くまとまっていたりする。てんやわんやするも意図しての研修のような気もするので、とりあえず乗り切ったことを喜びたい。

もうひとつは言語の壁。日本語を母語としない方がチームにいて、英語でコミュニケーションする必要があった。(多様性は歓迎されるべきことで良いこと。) 人生でたまに必要になるんだよな英会話。一応配慮があって留学経験のある人が同じチームにいたのだけど (ありがたい) (めちゃめちゃ発音きれいだった)、自分も割と頑張って英語を喋ろうとした、したけれど...

最初は途中途中に英語で「今こんなことを考えているんだけど貴方の意見は？」と議論を整理して振ろうとしてみてみたり、テキストベースで進めてみたりしようとしたものの、最終的には結局全然うまく行かなかった。テキストベースの議論が難しかった原因は、研修の都合でコミュニケーションツールが Zoom のみに限定されていたということもあるけれど、一番は「議論が白熱すると余裕がない」ことだった。日本語で考えるのでさえ精一杯で、どうしようかと悩み、時間がなく焦っている状況だった。散らかった議論をそのまま英語で話すのも厳しいし、整理して説明する余裕もない。結局チームの中で情報格差の壁ができたままになってしまって、現状を伝えて一緒に考えることが難しくなっていった。日本語ベースの研修だから仕方ない部分もあるだろうけど、結局チームも分断されてしまった (疎外感を与えてしまっただろう) し、その方の学びの機会も少なくなってしまった気がして、申し訳ない気持ちと残念な気持ちのまま研修が終わってしまった。

どう進めればよかったのだろうか、今考えてもわからない。ある程度議論のスピードを抑えてでも丁寧に進めるべきだったのかもしれない。

英語力欲しすぎ太郎
— やんまー (@yammerjp) April 2, 2021

文章の方向性がわからなくなってきたので、ちょっと話を変えましょう。リモートワークが中心でありコロナ禍ということもあり、内定をいただいてから一度も出社してないし、同期の人とは殆ど物理的に顔を合わせたことがない。その上にまだ入社1週間なのだが、研修のチームが違えど会社の同期の人同士では既にたくさんコミュニケーションをとっているし、なんとなく近くにいる気がする。チームでの課題で「大変だな」という気分になっているときも Slackを通して同期の人々に支えられる気分になるし (ありがとうございます)、いい会社にはいい人が集まるんだろうな。

明日からまた研修が続くのでそろそろ寝ましょう。おやすみなさい。

Office365メールやGmailをローカルにバックアップする (macOS)

Sun, 28 Mar 2021 09:03:06 GMT

3月で大学を卒業するにあたり、大学のメール (Office365) と研究室のメール (Google Workspace) が使えなくなる。閲覧もできなくなるのでバックアップを取っておきたいので試してみる。

メールの取得

Gmail 上のすべてのメールを mbox 形式で取得する

Google はサービス上の個人データをエクスポートする機能を提供している。

参考: Gmail からデータを書き出す - Gmail ヘルプ

2021/03現在では、次の手順で取得できる。

Gmail を開き、右上の自分のアイコンをクリックして、「Google アカウントを管理」を選択
「データとカスタマイズ」タブに移動し、中段の「データのダウンロード、削除」から「データをダウンロード」を選択
「新しいエクスポートの作成」の右下にある「選択をすべて解除」をクリック
スクロールして下の方に移動し、「メール」のチェックボックスを選択状態にする
さらに下に移動し「次のステップ」を選択
「エクスポートを作成」を選択
しばらく時間が立つと自分のメールアドレスにダウンロードリンクが届くので、これを開いてzipファイルをダウンロード

Apple純正の Mail.app でメールボックスごとに mbox 形式で取得する

Office365 は Gmail のようにエクスポート機能を提供していない。一方で macOSでは、純正で付属する Mail.app を用いてメールボックスのメールをエクスポートすることができる。

参考: Macの「メール」でメールボックスを読み込む/書き出す - Apple サポート

例えば「受信トレイ」や「送信済み」なども含めたすべてのメールを「アーカイブ」に移動し、「アーカイブ」のメールボックスを右クリックして「メールボックスを書き出す」を選ぶとすべてのメールを単一の mbox 形式でエクスポートできる。

(Office365 だけでなく Gmail を含む他のサービスのメールも、Mail.app でログインして同期すれば、この機能からメールをエクスポートできる)

メールの閲覧

mutt という CLI で mbox 形式のメールを閲覧できる。

インストール

$ brew install mutt

メールを見る

$ mutt -f path/to/mail-file.mbox

操作は次のとおり

キー	動作
j	下へ
k	上へ
z	次ページへ
Z	前ページへ
/	正規表現で検索
Enter	メールを読む
q	戻る / 終了

経緯といざこざ

メールをローカルに保存するときは、Unix, Linuxで用いられる形式として mbox 形式 (１つのファイルに複数のメールを記録) と Mail Dir形式 (1つのファイルに1つのメールを記録)、Windows で用いられている形式として eml形式 (1つのファイルに1つのメールを記録) などが代表的なよう。今回は使わなくなるメールアドレスの過去のメールを保存しておきたいだけなので、後から見返しやすければどの形式でも良い。mbox 形式でのエクスポートがやりやすかったので mbox を選んだ。

macOS ないし Ubuntu からメールをDownloadする CLI として getmail や fetchmail 等があるが、CLIからだと Office365 や Gmali の2段階認証を超えるのが面倒そうだった。 Thunderbird のエクステンションでのエクスポートも、エクスポート後のファイルを mutt で閲覧できなかったのでやめた。右往左往していて最終的に OS にバンドルされた Mail.app で mbox 形式でのエクスポートができることがわかり解決。 macOS の純正アプリケーションは PDF の切り取りや並べ替えができたり、簡易的にRAW現像できたりと意外にも高機能なのでよく助けられている気がする。Appleありがとう。

TCP/IP における全レイヤを俯瞰したパケットの構成

Fri, 19 Feb 2021 02:24:44 GMT

ふとしたときに TCP/IP でのパケットの各フィールドにどんなものがあったか確認したくなることがあるので、レイヤごとに分けずまとめて書かれた物があると便利。

以下, Ethernet, IPv4, TCP, HTTP を用いたパケットの各フィールドの配置を表した図。各フィールドの意味は記載しません。

卒業論文の発表を終えた。近況。

Thu, 18 Feb 2021 13:44:22 GMT

先週に卒業論文を提出し、今日その内容を学科内で発表した。無事合格できた旨のメールを先ほど受け取って、これで大学4年間の全ての単位を取得できる見込みになった。

大学生活は案外早く過ぎ去ったなと思いつつ、こういうのは終わってみればたいてい早く感じるものだろう。今の自分は大した技術力があるわけでもないし、大学4年間で大したことを身につけられた気がしないと少し前まで思っていたけれど、振り返ると4年前の自分は今よりも果てしなく無知だったことに気づくので、大学に入ってこの専攻を選んでよかった。

最近は論文執筆に勤しんでいた。新年の意気込みで早寝早起きと言っておきながら最近はだいぶ夜ふかしをしていたし、本を読む目標もあまり進んでいない。少し読んだ本もあるが、そんな時間があるなら論文を書きましょうという感じだった。

卒業研究にあたってそこそこ論文などを読んだ。論文を読む機会なんて正直いままで殆ど無かったし、長い仕様書をじっくり読むみたいなのもそんなにしてこなかったので、卒業研究はそういった意味で新しいことを体験する機会だった。世の研究者と比べたら大したことを出来た訳ではないだろうけれど、右も左もわからないながらも、一応高等教育の最後として自分の考えをしたためた文章を書ききったことに達成感を感じている。

ところで私は昔、理系大学生の醍醐味といえば研究室生活だろうみたいな想像をしていた。そういうのを心のどこか楽しみにしていたが、私の研究室はコアタイムがあるわけでもないし、新型コロナウィルスの影響で研究室には最初の1,2回しか行く機会がなかった。実家で一日中コンピュータを触っているのは実に快適でよいのだけれど。そういえば弊研究室に所属したら SINET から出れる IPv4 の固定アドレスを自由に使える権利があったのだけど、研究室内にコンピュータをセットアップすることもないまま卒業することになるので実質この権利を放棄してしまった。無理してでも文字通り研究室に入ってラズパイの1台でも置いてくればよかったな。一抹の後悔。

というわけで駄文でした。

研究が終わったらやりたいことがいくつか溜まっていたので順番に消化していきたい。気分症なのでいくつか既に昇華してしまったものもあるが、まあよいだろう。生活リズムも戻します。ブログもまた書いていきます、今までは文章を書く時間が全て論文に奪われていたので... (これは言い訳)

最後に先週公開され、卒論準備を後押ししてくれた BUMP OF CHICKEN の新曲、Flare の MV を置いてこの文章を終えます。おやすみなさい。

ベジェ曲線で画像を丸っぽくくり抜く (CSS clip-path)

Wed, 27 Jan 2021 02:43:00 GMT

  <img
    src="https://blob.yammer.jp/gather_fishes.jpg"
    style="clip-path:url(#bezier-curve-circle); width:300px;"
  />
  <svg>
    <clipPath id="bezier-curve-circle" clipPathUnits="objectBoundingBox">
    <path d="
      M 0 0.5
      C 0 0.166, 0.166 0, 0.5 0
      S 1 0.166, 1 0.5
      S 0.833 1, 0.5 1
      S 0, 0.833, 0, 0.5
      Z
    "/>
    </clipPath>
  </svg>

HTML で上記のように記述すると下記のように丸っぽく画像をくり抜ける

参考

Planck Keyboard を手に入れた

Sat, 09 Jan 2021 06:07:39 GMT

先月に申し込んだ Planck Keyboard が届いたので組み立てた。

Planck Keyboard とは

Drop + OLKB Planck Mechanical Keyboard Kit V6 | Drop

いわゆる 40%¹ と言われる分類で格子配列² のキーボードキット。キー数が少なく(4x12個) コンパクトなキーボードである。

スイッチを取り付ける基盤である PCB と PCB に装着するケースのセットで販売されていて、アメリカの共同購入サイト Drop (Massdrop, Inc.) で購入できる。いつでも買うことが出来るわけではなく購入希望者が集まってからまとめて生産されるようで、しばらく前から様子を見ており12月に購入できると知って注文した。

もともとは薄型の Planck Light Keyboard が欲しかったのだが、40%で格子配列のキーボードが買えるなら通常の Planck Keyboard でもいいかと妥協した。 (結果満足している)

現在販売されている v6 では、ケースを周りの高さが低い Mid-Pro と高い High-Pro から選べる。加えてケースの色も選べる。自分は Mid-Pro のスペースグレーを選んだ。

買ったもの

キットにはキースイッチとキーキャップが付属しないので別途購入した。

今回購入したものは以下。

商品名	個数	単価(円)	小計(円)
USB Type-Cホストケーブル C - C 両端L型 10cm U20CC-LL01T AINEX Amazon	1	792	792
Planck Keyboard V6 (Mid-Pro, SpaceGlay) (送料込)	1	$108	11754
XDA PBT ブランクキーキャップ (クリーム/2個)	16	110	1760
XDA PBT ブランクキーキャップ (アップルグリーン/2個)	4	110	440
XDA PBT ブランクキーキャップ (グレー/2個)	7	110	770
Gateron キースイッチ Brown (トップクリア/5ピン/55g/タクタイル/10個)	5	450	2250
TALP KEYBOARD キースイッチ 5個以上購入で5%オフ			-110
TALP KEYBOARD 送料			300
合計			17956

組み立て

Planck Keyboard V6 は, ホットスワップ用のソケットが PCB にはんだ付けされた状態で届くので、組立時に自分ではんだ付けする必要はない。ドライバーでネジを回し、スイッチをはめ込むだけで作れる。

作り方は公式動画で説明されている。

PCB にはデフォルトでキーマップが書き込まれているが、qmk/qmk_firmwareを利用して独自のキーマップを書き込むことも出来る。

# Ubuntu 20.04

# インストール
$ git clone https://github.com/qmk/qmk_firmware.git
$ cd qmk_firmware
$ make git-submodule
$ ./util/qmk_install.sh

# デフォルトのキーマップを書き込み
# Planck Keyboard をコンピュータにUSB接続
$ sudo make planck/rev6:default:dfu-util
# キーボード背面のリセットスイッチを押す
# 書き込みが終わるまで待つ

# 好みのキーマップを書き込み
$ cp -r keyboards/planck/keymaps/default keyboards/planck/keymaps/mykeymap
$ vim keyboard/planck/keymaps/mykeymap/keymap.c    # キーマップを好みに変更
# Planck KeyboardをコンピュータにUSB接続
$ sudo make planck/rev6:mykeymap:dfu-util
# キーボード背面のリセットスイッチを押す
# 書き込みが終わるまで待つ

買ったキースイッチは無刻印でホームポジションの印がないので、かわりに家にあった透明なシールを穴あけパンチでくり抜いて貼り付けている。

感想

Planck Keyboard は組み立ても簡単で、作りもしっかりしている。剛性感があるのでキーをタイプしても安定しているので安心感がある。

アルミケースの質感もいい感じ。事前の写真ではテカテカして安っぽい感じに見えていたのだが、実物はアルミの目が細かくて思っていたより落ち着いた風合いだった。

一緒に TALP KEYBOARD で買ったキーキャップの質感と色味も絶妙で、やさしい見た目になった。

キースイッチに選んだ Gateron 茶軸の押し心地もとても良い。スイッチを押すとストンと素直に下まで落ちてくれるし、別のキーボードに使っている Kailh ロープロファイル³のスイッチに比べてに比べて深く沈み込むのも良い。いままでは薄型の Kailh Choc のほうが自分に合っているかなと思っていたけど、今回 Cherry MX 互換⁴のキースイッチを使ってみて、すでに持っているキーボードもキースイッチを変えたくなってきた。

尊師スタイル⁵で使うために、短い USB ケーブルも合わせて買った。 Planck Keyboard にはキーボード裏に貼る滑り止めの足が付属するが、これを貼らずに裏面が平らなまま Mac の内蔵キーボード上に載せると、載せた上の Planck Keyboard をタイプしても内蔵キーボードは反応しないで使える。

前年に Lily58 というキーボードを作ってからというもの、row-staggered⁶ なキーボードに違和感を感じるようになって、持ち運びのしやすい格子配列のキーボードを欲していた。 Planck Keyboard を手に入れたおかげで気軽にこたつにキーボードを持ち込むことが出来て、こたつ PC 時間が捗りそう。

参考

一般的なキーボードのキー数に対する割合が40% (40-50個ほど) のキーボードのこと。 ↩
列ごと、行ごとにキー配置が揃っているキーボードの配列。othroliner ともいう。 ↩
自作キーボードに使われる薄型のキースイッチの規格。スイッチを押したときに沈み込む深さであるキーストロークは3mm。 ↩
自作キーボードに使われる最も一般的なキースイッチの規格。キーストロークは4mmが一般的。 ↩
ノートパソコンの内蔵キーボードの上に外付けキーボードを置く方式。 ↩
行ごとにキー配置が横にずれている、一般的なキーボードの配列。 ↩

2021年の目標「早寝早起き、本を読む」

Sat, 02 Jan 2021 07:08:22 GMT

今年の目標は「早寝早起き、本を読む」とする。

生活リズムの改善

目標の前半部分「早寝早起き」について。

2020年は大学の講義中心の生活から研究中心の生活に移り、殆ど自宅で過ごしたこともあって夜型の生活が続いた。寝るのが惜しくて夜ふかしをして、起きるのが遅くなることで更に眠くなる時間が遅くなり、、という悪循環から朝4時頃に寝て昼頃に起きるのが常態化していた。(もっと遅いことも多々)

これに対し、今年から社会人になるのでこのままでは良くないと思い12月中頃から生活リズムを改善する試みが始まった。 22歳になって「早寝早起き」という小学生みたいな目標を立てているが、今まで生活リズムを制御することは自分にとって結構な難題であった。

振り返れば昔から朝に弱く学校に遅刻したりしていたし、中高の部活を選ぶときの最優先条件は朝練がないことだった。記憶に残っている出来事として、中学3年の登校初日に寝坊し、急いで学校に行くと頭に寝癖がついたままだったため、これが元ネタでそのまま学級目標が「Neguse」になったことがある。¹

高校になっても朝が不安で、修学旅行前夜には家中の目覚まし時計をかき集めてベッドの周りに包囲陣を形成していたし、大学のサークル仲間と旅行に行くと「大音量の目覚ましを沢山設定するくせに一人だけ起きないから煩くて迷惑」との声を頂いた。²

そんな人間でも、最近は一応毎日同じくらいの時間に就寝と起床が出来ている。日付が変わる前に寝て7時半に起きることにしていて、3週間くらいは概ね継続できたことになる。 2020年はこれを続けることを目標の一つとする。

早起きのコツ

一定の生活リズムを継続できている要素には次の2つがあると考えられる。

早く寝る

生活リズムを一定に保つためには、同じ時間に起きることよりも同じ時間に寝ることを心がけることのほうが大切だと気づいた。寝ているときに目覚ましに気づくかどうかは自らの意思でないが (意識がないから。³)、一方で寝る時間は自らの意思で決められる。

どうも夜のほうが作業が捗るような気が夜ふかしをしがちだったが、その日やることが残っているかどうかを無視して予定の時間になったら寝る⁴ ことで、同じ時間に起きれるようになった。夜のほうが作業が捗るのも多分気のせいで、早い時間に起きれば夜でなくても集中できる。

起床後がんばらない

今までの数々の(早起きチャレンジ)失敗の原因は、朝の時間を有効に活用しようとしたことにあった。早起きして何かをやろうと自分に課していたのが問題だった。布団は暖かいしこの時期は特に出たくなくなる。起きてすぐやらねばならぬタスクがあるのは気が重いし「嫌だなあ」と考えてるうちに2度寝するのがオチだ。

そこで朝に何かを課すのをやめた。「目が覚めたら良し」とすることで気が楽になる。ついでに「起きたら2度寝しないようにベッドからすぐに出る」ことも課さない。起きたら目が冴えるまではスマホで Twitter や動画でも見ながらぬくぬくして、程よい頃合いでベッドから出れば良いとする。

これくらいの温度感でとにかく寝ることと目が覚めたらまずは良しとすることだけを自分に課すことで今後も継続しようと試みている。

粗読と精読の使い分け

目標の後半部分「本を読む」について。

昨年末の記事 (自分のGitHubリポジトリで振り返る2020年) にあるように、またこのブログの記事を書くなども含めて2020年は継続してアウトプットに取り組んだのに対し、インプットが弱かったと感じる。

そこで本年はアウトプットについては継続しつつ⁵、本を読むことでインプットを増やしたい。手始めにソフトウェア開発に関わる本の積読を減らすためリーダブルコードに手を付けた。

本を読むにあたっては、精読と粗読の使い分けを心がけようと思う。以前の記事 (積読本だった"Webを支える技術"を読んだ感想と、本を読むための心がけ) でも書いたが、精読ではなくまずは最後まで読み切り、何かあったら当該の本を読み直せばよい、といった読み方を意識する。

そうでもないと永遠に積読が減らない。

1冊の本から得られるものを最大化するより、学習時間あたりの得られるものを最大化すべきで、このためには最初に精読するよりも粗読と振り返りの精読のほうが大切だろうと思っている。

まとめ

家族に「年始に目標をたてても年末には忘れてるんだよね」と言われたので、忘れないようにそして心がけられるように宣言しておこうと思い記事を書くに至った。

「早寝早起き、本を読む」やっていきたい。

頭についた寝癖のように各々の個性を発揮するみたいな意味付けだったと思う。 ↩
ここまで全て実話。 ↩
これはひろゆき氏の受け売りで、よく寝坊を回避するのは不可能である理由の説明に使われる。 ↩
そうはいってもついつい夜ふかししがちなのでこの点は強い心が必要。あと風呂に入る時間を早めることも大切。 ↩
アウトプットするコードと文章の質については高めていきたい。 ↩

リーダブルコードを読んだ感想

Sat, 02 Jan 2021 06:49:50 GMT

2021年最初の読書はリーダブルコード。今年は本をたくさん読みたいので景気づけも兼ねて元日のうちに読み始め、今日の午前に読み終えたので感想を綴る。

本の概要

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) | Dustin Boswell, Trevor Foucher, 須藤功平, 角征典 |本 | 通販 | Amazon

プログラマーに向けた、読みやすいコードを書くためのバイブルといわれることもある本である。表紙が楽譜のデザインであり、ソフトウェアにおける「コード」と音楽における「コード」(音楽符号) をかけているのがポイント。

プログラムを書く人間なら読むべき、としばらく前に教えていただいたが積読されていた本である。英語版は無料で PDF が手に入る。日本語訳版は3000円くらいだが有名な本なので図書館とかに割と置いてありそう。 (弊学にはあった。)

感想

本書は良いコードを書くための方法を具体的に説明しており、そのまま実践できそうな内容が詰め込まれている。

しかしながら沢山のテクニックが示されておりその個々を読みながら納得することは出来ても、今の時点では自らの血肉となった気がしない。実際にコードを書くときに書かれた内容全てを実現することはすぐには出来ないだろう。定期的に見直して意識を続けるほかない。

幸いにも各章のさいごに「まとめ」が付いており、これがとても良くできている。まとめをインデックスとしてまずは迷ったときに本書に戻れるようにしておきたい。

特に5章, 6章のコメントに関する言及は興味深かった。本書では、よく言われる言葉「コメントには WHAT ではなく (あるいは HOW ではなく) ではなく WHY を書こう」ではなく「コードの理解するのに役立つものなら何でも良いから書こう」と説明されていた。

私は以前はコメントを沢山書いていた。命名については深く考えておらず、ソースコード内に日本語で説明できる部分があるなら助かると思っていたからだ。しばらくして Git を学び、命名の大切さを知り、以前コメントに書いていたようなことは命名で表現できるのではないかと思うようになった。さらに無駄なコメントは悪である¹という考えを知った。

これらは勿論大切なことではあるが、必要以上にコメントを忌み嫌ってほとんど書かなくなったように思う。自分の書いたプログラムをあとから変更しようとするときにコードを理解する負担が増えたような気がして気づいた。

こういった曲がった考えを直して正しいスタンスを説明してくれているのが本書だと感じた。² コメントをどのように書くか悩んだときは、5章4説にある「とにかく書き始める」が有効だろう。まず頭で思ったことをそのまま書き出してから細かく改善することで良いコメントを作ることを勧めている。

こういった一つ一つの事柄をコツコツ実践していきたい。

コードを読んですぐに分かるようなことをコメントに書くのは良くない。画面を専有する、コードを書き換えるときに一緒に書き換えなければならず負担になる、書換えを忘れてコードの内容とコメントの内容が乖離していたら読み手は混乱する、などの理由から。 ↩
そもそも無駄なコメントは必要ないと指摘してくださった方は同時にあわせて「リーダブルコードを読んだほうが良い」と仰っていた。それを積読のまま消化しなかった自分が悪い。 ↩

自分のGitHubリポジトリで振り返る2020年

Thu, 31 Dec 2020 09:18:37 GMT

今年コミットした GitHub のリポジトリを順にみながら2020年の個人開発を振り返ってみる。

実は去年もやろうとしていた企画¹、今年こそ年内に公開するぞ。

リポジトリ一覧の取得

去年の記事では API を curl で取得していた²が、今年は GitHub の公式 CLI である gh を使って取得することとする。

jq と gh をインストールし、 ~/.config/gh/config.yml の aliases キーに、次のような内容を追記する。

aliases:
    repos: |
        !gh api --paginate graphql -f owner="$1" -f query='
          query($owner: String!, $per_page: Int = 100, $endCursor: String) {
            repositoryOwner(login: $owner) {
              repositories(first: $per_page, after: $endCursor, ownerAffiliations: OWNER) {
                nodes { nameWithOwner, updatedAt }
                pageInfo { hasNextPage endCursor }
              }
            }
          }
        ' | jq '.data.repositoryOwner.repositories.nodes[] | .updatedAt + " " + .nameWithOwner' -r | sort

ログインして、先程登録したエイリアスでリポジトリ一覧を取得する。

$ gh auth login
$ gh repos | grep '2020' > repos.txt

リポジトリを一つづつ振り返る

以下順番にコミットした GitHub リポジトリを振り返っていく。

lovelab-api

yammerjp/lovelab-api : API server of lovelab with express.js
yammerjp/lovelab-batch : Batch server of lovelab with node.js

2019年10月から2020年1月にかけての iPhone アプリを開発する演習授業に合わせて作った、TypeScript 製の API サーバ。データベースを使ったサーバサイドアプリケーションを一人で作ったのは初めてで、サーバ内でどのような処理をしているか、また REST API とはどのようなものかなどの全体を知ることができた。

ドキュメントは手書きしたがエンドポイントが意外と多く³、書くのが大変で中身も整っておらず良い出来とは言えない。今思えば Swagger などを使うべきだっただろう。

認証系は簡素なもので「ID とパスワードの対で新規登録する」「ログイン時にアクセストークンを発行する」といった動作を自前で実装している。自前で実装したのは認証認可のしくみを理解していなかったからだ。スマートフォン用の API においてどのように認証認可が行われるか、HTTP の中でそれはどのように表現されるかがよくわかっておらず、ライブラリを使おうとしても「よくわからんな」という気持ちになった。

そこで、授業でやっていることもあり (リリースまでは求められていない)、良い機会だと思って一連の流れを作ることにした。「車輪の再発明は無駄」「セキュリティホールの発生に繋がるので自前での実装は避けるべき」といった意見はごもっともだが、作ってしくみを理解するという点ではとても助かった。普通なら Express.js に使える認証ミドルウェアの Passport.js を使ったり Firebase Authentication や Auth0 などに任せてしまうのがいいだろう。

そういえば Dockerfile を自分で初めて書いたのもこのアプリケーションだった。 Docker はプログラマのためのDocker教科書第2版を読んで学び, EC2 上に docker-compose を使って展開していた。

17ti.me

2月に作った、大学の研究室配属前に学生間で希望を調整するために非公式で作った Web アプリケーション。学内の情報がハードコーディングされているので公開していない。最終的に対象者の8割以上の人に利用していただいた。感謝。

成績と希望を集計するもので、Vue.js と Firebase (Realtime Database, Authentication), Netlify を利用している。大学個人に付与されるメールアドレスを用いて Firebase Authentication でログイン機能を設け, Realtime Database 上に集計情報を記録した。

Firebase Authentication は前月に作った lovelab-api の認証と比べて簡単だし管理画面も良く出来ていて感動した。 Firebase Realtime Database も全体を1つの JSON として扱うシンプルなデータベースをクライアント側から読み書きできるので楽に作れて素晴らしかった。車輪の再発明のあとに最新式の自動車に乗った気分。

dotfiles

yammerjp/dotfiles : my .vimrc, .zshrc, and so on...
yammerjp/dot.yammer.jp : HTTP redirect server to download shell script to initialize dotfiles

2020年は私が dotfiles に入門した年でもあった。

dotfiles とは ~/.vimrc や ~/.bashrc などの各アプリケーション向けの個人設定ファイルの総称で、よくホームディレクトリの中にドットで始まるファイル名で保存されることからこう呼ばれる。複数のコンピュータで設定を共有するために dotfiles を GitHub で管理する Tips があり、Qiita で知ってやってみたいと思っていたのだ。

3月の春休みに、4月の研究室配属時に研究室のコンピュータのセットアップを爆速で終わらせることを目指して作り始めた。⁴

最もシンプルな dotfiles は設定ファイルを別ディレクトリで git の管理下に置きホームディレクトリにシンボリックリンクを貼るものであるが、これにとどまらず様々な機能をもたせることもできる。私のリポジトリでは、アプリケーションの一括インストールや OS の設定変更、設定ファイルの自動配置などを行うスクリプトも一緒にまとめて管理している。 OS は macOS と Ubuntu に対応させてそれぞれ判断してスクリプトが実行されるし、ついでに GitHub Actions で CI を回したりもしている。

dotfiles を始めてよかったのはシェルに親しめたことだ。まずシェルスクリプトを書く機会が圧倒的に増えた。それまでは普段書かないので if の記法ですら毎度 ggっていたくらいだったが、dotfiles を凝りだすとシェルスクリプトを書く必要が出てきて覚えた。

他にも.vimrcを改造してプラグインを入れたり、シェルにエイリアスもたくさん貼るようになって便利になった。設定ファイルを壊してもすぐ直せるので色々試せるのが良い。

pdef

yammerjp/pdef : Patch script generator of Mac OS X User Defaults
yammerjp/homebrew-tap : yammerjp's collection of Homebrew (aka, Brew) "formulae"

dotfiles の開発にあわせて、macOS の設定を保持する UserDefaults をシェルから書き換えたくなって作ったツール。詳細は当時のブログ記事に書いている。

書いた記事: Macの設定を自動化するdefaultsコマンドと、それを助けるpdef / (余談) User Defaultsとproperty list(plist)

memo.yammer.jp

yammerjp/memo.yammer.jp : my memos. https://memo.yammer.jp/

このブログ (memo.yammer.jp) と個人のページ (yammer.jp) を用意したのも 2020年。

このブログはやんまーのブログとは別にメモや作業記録を雑に投稿するために作ったのに、使い分けが出来ておらず完全に迷走している。でも記事を書くハードルが下がったのはとても良くて「とりあえず雑に投稿しておくか」と自分で思える。

Hugo で出来ていて、最近デザインの変更と OGP 対応をした。拡張したい機能がいくつかあるのでそのために来年は勉強も兼ねて Hugo から Next.js に置き換えたい。

yammer.jp

yammerjp/yammerjp.github.io : A web page including links for my SNS and Web sites
yammerjp/rss-republish.yammer.jp : Republish RSS feeds with Vercel

個人のページ。最初は linktree⁵ を真似して SNS のユーザページのリンクなどを含む HTML と CSS だけのページをおいていた。最近作り変えて自己紹介と記事の一覧も表示している。

はてなブログ

yammerjp/gimonfu : Manage hatena-blog articles
yammerjp/yammerjp.hatenablog.com : Hatenablog articles
yammerjp/blog.yammer.fun : Redirect old blog to new blog
yammerjp/hatenablog-post : Post article of markdown file to hatena-blog.

去年 Nuxt.js で作ったブログをはてなブログに移行した。移行にあたって、画像を AWS S3 に移したり、旧ドメインをリダイレクトしたり (yammerjp/blog.yammer.fun)、はてなブログの記事管理 CLI (yammerjp/gimonfu)を作ったりした。

最初は一括投稿のために hatenablog-post という CLI ツールを作ったが、それ以外の機能も欲しくなって gimonfu という CLI ツールに発展した。 gimonfu は初めて npm publish したが、インターネット上のどこかで使ってくれている人がいるようで嬉しい。

書いた記事: gimonfu で、はてなブログの記事を GitHub と同期する - Qiita

willani

yammerjp/willani : C Compiler

2020年に一番時間を費やしたのが C コンパイラの willani。 5月から2ヶ月くらい作って7月半ばに止まっているが、一応コンパイラ自体のセルフホストは達成した。 (プリプロセッサが未完成。) また気が向いたら続きをやりたい。

自作したことで今までブラックボックスだったコンパイラがどんな動作をしているか知れて楽しかった。

書いた記事: 数日前からCコンパイラを書き始めた。 / 自作Cコンパイラの途中経過 / 自作コンパイラのセルフホストに挑戦中 / 自作コンパイラのfor文バグ / C言語の構造体メンバのアライメント (x86_64, Linux (System V ABI))

mopm

yammerjp/mopm : Mopm (Manager Of Package Manager) is meta package manager for cross platform environment.
yammerjp/mopm-defs : mopm package definition yaml files
yammerjp/mopm-defs-test

既存のパッケージマネージャに不満を持ったので作り始めたソフトウェアのインストール支援ツール。 Golang の入門も兼ねて秋に作り始めたが、しばらく進めていくと「これは HomeBrew の劣化版では？」という気がしてきて手が止まっている。

その他

その他。

yammerjp/regex-visualizer, yammerjp/regex2dfa ... 正規表現をグラフで描画するツール
yammerjp/pl0i, yammerjp/cmm ... 大学の教科書(コンパイラの講義)で題材とされた言語の拡張
yammerjp/competitive-programming ... 競技プログラミングを解いたときのコードを載せるリポジトリ (全然解いていない)
yammerjp/java-design-pattern-multi-thread ... 輪講で読んでいた本の実践 (中断)
yammerjp/md-prev, yammerjp/md-server ... Markdown で書いた記事の確認用アプリケーション
yammerjp/kozos 2019年4月に買い牛歩の歩みで進めている OS 自作、12ステップで作る組込みOS自作入門。やらねば。
yammerjp/solar-log, yammerjp/solar-web ... 家庭用太陽光発電システムのロギングと集計用アプリケーション
yammerjp/md2hiki ... Markdown 記法の文章を hiki 記法に置換するスクリプト
yammerjp/cat ... C 言語で cat コマンドを実装してみる試み
yammerjp/album-shelf, yammerjp/album-shelf.rb, yammerjp/rails-micro-blog (プライベートリポジトリ) ... Ruby on Rails と React で画像を管理する Web アプリケーションを作りたかった (中断)
yammerjp/ogp-getter ... OGP の情報を抽出するアプリケーション
yammerjp/armyknife: Shell script snippets ... bash製のシェルスクリプトで使えるツール群 (を作る予定)
yammerjp/pocket2retweet ... Pocket に保存したツイートをリツイートするスクリプト (ブログ記事)
yammerjp/keepa (プライベートリポジトリ) ... 日記用のWebアプリケーション (ブログ記事))
yammerjp/ryu-http-routing ... 卒論の検証用

...

この他にも2020年に手を付けていた自分のリポジトリやフォークしたリポジトリがあるが、ここでは省略する。

総括

良かったこと

2020年はコロナで家にいたということもあり、自分の時間がとれて継続的に何かしらを作っていた気がする。(後半は研究のために前半ほどの勢いはなかったが。) 昨年ある面接で「作ったものはもっと公開しよう」とアドバイスをもらった事があり、それに従ってなるべくパブリックリポジトリで公開するようにしていた。

結構飽きずにキリのいいところまで作り続けられた。そのおかげで npm publish や、HomeBrew の Formulae としての公開に繋がった。

また、自分が作りたいものを作るときに新しい技術に少しずつ手を広げていけたように思う。

改善したいこと

「コードを読む機会が少ない」

これに尽きると思う。 OSS などの他人の書いたコードを読む機会が全然なくて、どこから手をつけていいのかもわからない。コードリーディングってどうやってするんでしょう？... 働き始めたら他人のコードを必然的に読むことになると思うが、結構不安。

来年も

ものを作るのは楽しい。今年ほど時間の余裕がないだろうが、来年も新しいことを学ぶためにも何か作りたい。作りたいものは50個くらいある⁶。

以上。

リポジトリで振り返る2019年 – memo.yammer.jp ↩
去年のように API をcurlで叩くなら、basic 認証ではなくアクセストークンで行う必要がありそう。Basic認証は廃止されたはず。 ↩
lovelab-api のドキュメント ↩
結局新型コロナウィルス感染症の影響でリモートになったので研究室のコンピュータをセットアップすることはないまま卒業しそうである。 ↩
linktree は SNS の自分のページへのリンクなどをまとめて表示する Webページを作成できるサービス。 ↩
自分のメモの中に作りたいアプリケーションのネタ帳があり、そこに書かれた数。 ↩

HugoでURLをパーセントエンコード (CloudinaryでOGP画像生成)

Sat, 26 Dec 2020 11:52:36 GMT

Hugo で Cloudinary¹ を用いた OGP 画像生成のため日本語を URL に埋め込みたい。埋め込みのために文字列をパーセントエンコード² する方法を記す。

方法

Hugo のテンプレートの中で $string 変数に文字列が格納されているとき、次の表記で変数内の文字列をパーセントエンコードして出力できる。

{{- replace (substr (querify  "a" $string) 2) "+" "%20" -}}

例えば OGP 画像のためURLに日本語文字列を埋め込むのは次のようにして実現できる

{{ $title := "埋め込む文字列" }}
<meta
  property="og:image"
  content="https://res.cloudinary.com/basd4g/image/upload/{{- replace (substr (querify  "a" $title) 2) "+" "%20" -}}/v1608780036/memo-basd4g-net-ogp.png"
/>

経緯と補足

上記の方法は少々トリッキーである。私の調べた範囲ではHugo に定義された関数の中で直接 URL をパーセントエンコードするものは見つけられなかった。英語圏などでは (半角空白)を%20に置換すればよいのでは？という回答もあったが、日本語はそれでは困る。

しかしながらテンプレート内で表示されるページの URL を取得する {{- .Permalink -}} という値があるらしく、この値からは適切にパーセントエンコードされた値を取得できることがわかった。ということで Hugo の内部で URL として扱われる文字列はパーセントエンコードされるっぽい。

そこで任意の文字列を URL として Hugo に扱わせそうな機能である、URL クエリパラメータを生成する querify 関数を利用すると実現できることをみつけた。上述の方法では、querify 関数によってパーセントエンコードされたクエリパラメータに変換し、クエリパラメータの先頭部分と半角空白文字を処理することで実現している。

というわけでこのブログもOGPに対応した。もしもっとシンプルな方法があったら教えてください。

参考: Hugo

参考: パーセントエンコード

Cloudinary はアップロードした画像を配信できるサービスで、URL で画像の大きさや文字などを指定すると加工した画像が返却される機能がある。これを用いて記事のタイトルを URL に含め、事前にアップロードした背景画像と組み合わせて記事ごとの OGP 画像として配信することができる。 ↩
URL に使用できない文字を、文字コードに置換することで URL に有効な文字の範囲で表現する方法。置換対象の文字を % とその後ろに文字コードの16進表現を続ける形に置換する。例えば https://ja.wikipedia.org/wiki/パーセントエンコーディング は https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%BC%E3%82%BB%E3%83%B3%E3%83%88%E3%82%A8%E3%83%B3%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0 と表現できる。 ↩

MacBookAir 2020 (M1) のセットアップ

Tue, 22 Dec 2020 05:24:01 GMT

Apple Silicon を搭載した MacBook Air を購入したのでセットアップをやっていく。そのメモ。

m1 MacBook Air が届いたのでとりあえずたくさんアプリケーションやタブを連続起動して「はえ〜」ってやつをやりました。
— やんまー (@yammerjp) December 20, 2020

2020/12/20現在では「brew bundleしておわり」というわけにはいかない。できる限りApple Silicon版のバイナリを使いたいので、各種ソフトウェアのビルド方法などを記録することにする。

Tips

arch -x86_64 を先頭につけてコマンドを実行すると Rosseta2 上で実行してくれる。

ソフトウェアのインストール以前

macOS の設定

ライブ変換の無効化
OSのキーマップ設定を変更 (capslock -> esc)

ssh

$ mkdir ~/.ssh
$ chmod 700 ~/.ssh
$ cd ~/.ssh
$ ssh-keygen -t rsa -b 4096 -C "mymail@example.com"
$ cat id_rsa.pub | pbcopy

GitHub Settings を開いて 'New SSH key' を追加

dotfiles

$ xcode-select --install
$ curl -sL http://dot.yammer.jp | sh
$ cd dotfiles
$ make link
$ vim

ソフトウェアのインストール

Web ページからパッケージをダウンロードしてインストールしたものは以下。

Scroll Reverser
Karabiner-Elements
Zoom (起動してログインの後、Apple Silicon版にアップデートするダイアログが出てくる)
MacPorts
Firefox
Google Chrome

(Vivaldi はまだintel版しかないので、アップデートして欲しい。)

ビルドするなどして導入したのは以下。

Homebrew (for Apple Silicon)

$ sudo mkdir /opt/homebrew
$ sudo chown $USER /opt/homebrew
$ curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C /opt/homebrew

tmux

$ brew install --build-from-source tmux

Node.js

$ sudo port install nvm # install nodejs version manager
$ echo 'source /opt/local/share/nvm/init-nvm.sh' >> ~/.zshrc
$ sudo port install git curl openssl automake
$ nvm install v15

参考: 個人的 M1 mac 開発環境状況 2020/11/28更新 - Zenn.dev

nodejsのビルドはそこそこ CPU パワーと時間を使う

Golang

まずはIntel版をWebからダウンロードしてインストールする(The Go Programming Language)

次に以下の手順でApple Silicon向けにビルドした後、Intel版を削除

$ go get golang.org/dl/gotip
$ GODEBUG=asyncpreemptoff=1 GOARCH=arm64 ~/go/bin/gotip download
$ echo "$HOME/sdk/gotip/bin/darwin_arm64" | sudo tee /etc/paths.d/go
$ which go # check to be installed
$ sudo rm -rf /usr/local/go

peco

$ cd
$ git clone https://github.com/peco/peco.git && cd peco
$ make build
$ mv ~/peco/releases/peco_darwin_arm64/peco /usr/local/bin/peco

hugo

$ cd
$ git clone https://github.com/gohugoio/hugo.com && cd hugo
$ go build
$ mv ~/hugo/hugo /usr/local/bin/hugo

jq

$ brew install --build-from-source jq

gh

$ cd
$ git clone https://github.com/cli/cli.git && cd cli
$ make
$ mv bin/gh /usr/local/bin/gh

mmv

$ cd
$ git clone https://github.com/itchyny/mmv.git && cd mmv
$ make
$ mv mmv /usr/local/bin/mmv

ImageMagick

ImageMagick - Install from Source

# libjpeg
$ curl https://download.imagemagick.org/ImageMagick/download/delegates/jpegsrc.v9b.tar.gz -o jpegsrc.v9b.tar.gz
$ tar xvf jpegsrc.v9b.tar.gz
$ cd jpeg-9b
$ ./configure
$ make
$ sudo make install

# image magick
$ cd
$ git clone https://github.com/ImageMagick/ImageMagick.git && cd ImageMagick
$ git checkout　7.0.9-9
$ ./configure
$ make
$ sudo make install

Pocketにツイートを保存したらリツイートする

Tue, 15 Dec 2020 09:27:23 GMT

題名のスクリプトを作ってcronで定期実行したら便利だった話。

背景

Twitter アカウントがいくつかある。¹ 情報を浴びるように流しているアカウントだったり、情報の種類別だったり、使っていないものだったり。

PC で Twitter を見るときは大体 TweetDeckを使っておりこれは結構使いやすい。一方で iOS ではマルチアカウントで満足する Twitter クライアントを見つけられていない。 (今は feather を使っている。)

具体的には次のような機能がほしい。

ユーザを別アカウントでフォローする
ツイートを別アカウントでリツイートする

作ったもの

作ったものはこちら: pocket2retweet - GitHub

対象のユーザとツイートを Pocket に記録し、あとからバッチ処理するようにした。

次の2つの機能をもつスクリプトを cron で1時間ごとに定期実行する。

Pocket に保存されているツイートを Pocket API で取得し、Twitter API でリツイートしたあと、Pocket から削除する。
Pocket に保存されている Twitter ユーザページを Pocket API で取得し、Twitter API でフォローしたあと、Pocket から削除する。

API の条件的には1分に1回くらいでもいいくらいだが、多少遅れても困らないので1時間に1回としている。

感想

我ながら便利。

Pocket への保存はアプリ間共有で Pocket を選べばよいだけなので、Web ブラウザでもアプリでも、iOS に限らず使える。

もともと Pocket に保存したツイートは Pocket のページからは見づらかったので、リツイートしたものから探すほうがみやすくてよい感じ。

Pocket の現状の自分の使い方では、保存するのは楽でいいけどけど整理されていないし読みづらいみたいなところがある。もっと活用できそうな気がするので、他のサービスともいい感じに連携して便利にする方法を考えていきたい。

リスト機能を使って1つのアカウントでやれやという意見もあるだろう。以前はそうしていたのだがリスト管理が面倒な気がして、今はアカウントを分けてフォローしたほうが楽だと思っている。 ↩

東芝HDDレコーダRD-S600の動画をmacOSにコピーする (ネットdeダビング)

Mon, 14 Dec 2020 14:18:07 GMT

TL;DR: 2006年製の東芝製 HDD レコーダ RD-S600 の動画を, 当該機種に搭載の「ネットdeダビング」機能を使って, LAN 経由で macOS のストレージにコピーする.

背景

8ミリのビデオテープや VHS に記録されたホームビデオをデジタル化するにあたり, 家族が自宅にあった HDD レコーダ RD-S600 の内蔵 HDD に動画を録画していた.

これを, HDDの寿命が怖いしブルーレイに焼きたかったりするのでPCに転送したい.

RD-S600 は2006年東芝製の HDD レコーダで, 都合のいいことにイーサネットポートがついているため LAN 内で動画を転送できる. ただし転送できるのはコピー制限のかかっていない VR モードの動画に限る. (アナログ入力の録画に使われる低品質のもの)

転送を受けるPC側については, 有志で公開されたソフトを利用する. ただし15年ほど前ということもありリンク切れで入手できなかったり当時のOS上で動くことを前提にしていたりするので, 2020年現在で出来そうな方法を探した.

いくつかあるソフトの中で試行錯誤の結果, 今回はJava製でMac OS X 向けの転送用ソフトウェア RDService を利用した.

環境

東芝製 HDD レコーダ RD-S600
MacBook Pro 2020 (Catalina)
どちらも同じLAN に接続する (HDD レコーダはイーサネットポートを利用して有線で, MacBook はアクセスポイントを経由して無線で接続)
2台とも DHCP を利用(勝手に探してくれるのでIPアドレスはなんでもよい)

手順

Mac で FTP を拡張したサーバを実行し, 同じネットワークに接続した HDD レコーダ側を操作して, サーバに動画を転送する.

1. Java8 をインストール

# homebrew がインストールされていることを前提とする
# Java8 をインストール
brew tap homebrew/cask-version
brew install --cask zulu

# java が zulu8 のバージョンであるかを確認する. zulu8 でないときは参考 URL より切り替えるとよさそう.
java -version

参考: MacのBrewで複数バージョンのJavaを利用する + jEnv - Qiita

私の環境では zulu8 が /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/bin/java にインストールされていた. のちほどシェルスクリプトで実行する java コマンドの代わりに上記のパスを指定しても良い.

2. RDService をダウンロード

$ curl -o RDService.zip http://raktajino.sakura.ne.jp/RDService/RDService_1.0b5.zip
$ unzip RDService.zip
$ cd RDService

3. RDService を実行

$ ./RDService

解凍したディレクトリの中にあるシェルスクリプト RDService を実行すると, サーバが起動する. RDService は 21, 5500-5509 ポートを利用するので, 既に利用しているアプリケーションがあったら事前に落として開放しておく.

デフォルトでは ~/Movies に転送した動画を保存するので, シェルスクリプトを編集して NAS や外付けHDD 等の大容量ストレージを指定するとよさそう.

4. HDD レコーダ側を操作して転送を開始する

ネットワークに接続されていない場合は事前に接続しておくこと.

この項では東芝HDDレコーダをリモコンを次のように操作する.

スタートメニュー > かんたんにダビングする > HDD から LAN へ > コピーする動画を選ぶ > コピー

選択する項目の画面は下に示す.

リモコンで「スタートメニュー」を押し, 「かんたんにダビングする」を選ぶ.

次にダビング方向の選択. 「HDD から」「LAN へ」を選ぶ.

次にネットワーク機器選択をする. 「RDService」「HDD」を選ぶ.

ダビングする動画を選ぶ.

ダビング開始.

5. 待つ

途中で Mac がスリープしないように注意.

あと時々転送に失敗するので, その時は転送された動画の書き出し状況を確認し適宜手動でリトライする(した). (動画を連続して転送すると1本目の動画を転送しきってからコネクションが切れることが多い気がする？...)

ちなみに RD-S600 はイーサネットポートが 10BASE-T のため, 転送にとても時間がかかる. 1.5時間の動画を転送するのに一時間くらいかかるので心して挑まなければならない.

転送が終わったかどうかは HDD レコーダ側のシーケンスバーがなくなっているかどうかで確認する. 取り出した動画はMPEGなので, あとは煮るなり焼くなりできる.

注意点

Java11 ではエラーを吐くので Java8 をインストールすること
Java8 が動けばどのOSでもよいわけではなく, MacOS X 上で行なうのが確実. 私の環境だと Ubuntu 20.04 上では RDService は起動したものの HDD レコーダから認識されなかった. (Mac OS X 上でもたまに認識されないので, もしかしたら動くかも)

感想

2006年製のAV製品からネットワーク経由で動画を取り出せるとは, イーサネットは素晴らしい.

転送速度が(非常に)遅いとはいえ, できるのとできないのでは大違い. できるだけでありがたい.

この頃のAV機器の統一規格はなくて, 当時は東芝のレコーダに合わせたソフトをネット上の有志が開発していたようである. 中身はFTPサーバをベースにしたものっぽい. 14年経っても動かして助かっているので開発者に感謝.

参考

Youtubeライブ「技術文章の書き方」を聞いた内容のメモ(2020年12月)

Sun, 06 Dec 2020 14:40:12 GMT

(2024/09/22記) 2020/12/06に書いていたメモ。当時は学部の4年で卒論を書いていた頃で、卒論をきっかけに技術文章を書くことに興味をもって調べていて見つけた動画をメモしていたのだろう。ブログ記事を書いたり、あとは雑誌の記事を書いたりするときにも参考にしていたもので、まとまった文章を書く必要に迫られたら見返したくなる。

以降は箇条書きであくまでメモなので、詳細は当然動画を見ていただけるとよくて、動画を見返すためのインデックスとして書き出している。

以下は、Youtubeに公開されている動画 (15) 技術文書の書き方・ゲスト：Web+DB Press稲尾さん - YouTube を聞いた内容である。

動画内で紹介されている書籍

Amazon.co.jp： <新版>日本語の作文技術 (朝日文庫) eBook: 本多　勝一: Kindleストアの3章と4章から、一文単位のテクニックの上位２つ
理科系の作文技術 (中公新書 (624)) | 木下是雄 |本 | 通販 | Amazon の第4章から段落をどう分けるかについて
ロジカル・シンキング (Best solution) | 華子, 照屋, 恵子, 岡田 |本 | 通販 | Amazon 第3章,第4章

日本語で文章を書くテクニック

一文単位のテクニック(24:00)

一文の中で語順をどう並べればよいか(24:30)

修飾子の並び順は、修飾子の長いものほど前に並べる。
読点の打ち方(28:45)
- 長い修飾語が2つ以上あるときその境界に点を打つ。
- 修飾子の並び順が逆順の場合は点を打つ。
指示代名詞を多用しない。仕方ない場合は指示連体詞を使う。(35:10)
難しい一文を書かない。長くしない。(37:15)

段落をどう分けるか(38:18)

１つの段落では１つのトピック。
- 一文目は概要。
- 二分目以降は詳細の説明。
- 一文目に概要を書かない場合でも、1つの段落で1つのトピックに限定すべき。
一段落の粒度は見出しの粒度に依存する。
- 小見出しを使って見出しの粒度を調整すると、段落の粒度も調整できる。
- 階層が深くなりすぎるときは章を分割して繰り上げる。(３階層くらいまで)

全体構成(見出し構成)

ロジカルシンキングの本を読む
- 話の漏れ, 重複を防ぐ
- 話の飛びをなくす
対象読者のうち、最も前提知識のない人がどの階層の見出しまでを読んでも話がわかるようにする。
- 固有名詞だけの見出しは良くない。固有名詞がわからなくても良いように説明的にする。
- 見出しだけで答えまでわかるようにする。「○○の特徴」という見出しがあるとき、その下の小見出しはその答えを列挙する形式にしておくとよい。
- 読解力が必要な見出しは避けるべき。
- 列挙するだけの見出しはよくないので説明的にする。「変数と定数」よりも「変数と定数による値の管理」のほうがいい。
ページあたりの見出し
- 書籍では2見出し/ページ, 雑誌では4見出し/ページ (どちらも大見出しや小見出しをすべてカウントして)
- 上記から一段落の長さも逆算される。
見出し数は下の階層の見出しほど多くなるようにする。(下の階層ほど詳細を説明しているから)
見出しの文字列の長さも、下の階層の見出しほど長くなるようにする。(下の階層ほど詳細を説明しているから)
書き始める前に見出し構成を考えるほうがいい。後で変えるのはいいけど、書き出す前に考えよう。

技術文章特有のテクニック

専門用語を統一
読者がソースコードや図を読み飛ばしても大意は読み取れるようにする。「次のコードは○○をしています」といった文章(トピックセンテンス的に)用意しておく
どこまで説明するかは割ける分量による。分量があれば変数とは、定数とはなども細かく
なんとなくでも説明する。x「〇〇を用いて」o「〇〇という最適化手法を用いて」
種別も明記する。メソッドなのかクラスなのかインスタンスなのか要素なのか。

その他のテクニック

事例から得られたノウハウを説明するとき、ノウハウが主題なら具体例よりもノウハウに主眼を置くべき。
テーマと対象読者を定めるのは大事。
推敲で1割削ると良い。
- 冗長な部分を削る
  - とても, 非常に, は冗長なので削る
  - することができます, してしまうといった表現を削る
- 推敲するときの方法
  - 一晩寝かす
  - 読む媒体を変える
  - 音声読み上げさせると気づく
  - 朗読する

m1のMacbook Airを買った言い訳

Fri, 04 Dec 2020 03:35:25 GMT

おやおや？ pic.twitter.com/KVU554OdNZ
— やんまー (@yammerjp) December 4, 2020

買ってしまいました。

Apple Silicon版のm1チップを搭載したMacbook Airは出来が良いと評判なのは皆様ご周知の通り。私も時代の波に乗ろうと思う。

買う理由

ここから買い替えの言い訳が始まります。

手元のMacが遅い。ブラウザのタブをたくさん開くと遅くなるのでちょっと嫌な気持ちになる。
手元のMacが遅い。メモリ8GBだしこのMacでDockerは重すぎるのでどうせ別のx86 linuxマシンにsshするし、ARMでも問題ないでしょう。
手元のMacの売却額が下がりそう。Apple Silicon版Macの評判が良いので、今後Intel版Macの売却額はどんどん下がるだろうし今のうちに買い替えておくべきではないかという気持ちになる。
手元のMacのファンがうるさい。ファンレスはいいなぁ。
手元のMacのキーボード配列が日本語配列。USに慣れたので記号の位置がわからなくて困る。
バッテリーが若干ヘタってきている気がする。久しぶりに外出したときに感じた。バッテリー無しの場所で長時間使うのはちょっとビクビクするかも。

Macが遅くて最近はUbuntuを入れた別のマシンを使っていたのだが、GUIはやっぱりMacのほうが便利だしLINEをWineで無理やり動かそうとして消耗する必要もないし、でも遅くてつらいのでこれを気に乗り換えてしまおうと思い経った次第。

買い時

上記は大体言い訳で、買わない理由も考えればたくさんある。耐えられないほど遅いわけじゃないし、どうせsshするからそんなスペックいらないはずだし、学生の今より来年就職してからのほうがお金があるだろうし。

でも就職する前の今のほうが自分所有のPCを使う時間は長いだろうから快適なものを使いたい。

ちょっと冷静に考えても今はわりと買いどきだと思う。自分はApple製品を最悪のタイミングで買うのが得意で、いつも一番割高な時期に買っている。以前買ったiPad(2017)はApple Pencilに対応する前の最後のモデルだし、MacBook Air(2018)を買った直後には2019年モデルが結構値下げして発表されたし、翌年の2020年モデル(Intel版)はコア数2倍になってるし。

いやだって手元のMac、メモリ8GBなのに学割使っても16万したんだぜ。SSDも256GBだしCPUも2コアだし。16万って。Appleさん高いよ、高すぎるよ。

今回はメモリ16GBのm1チップ搭載で12万、正直安いんだか高いんだがよくわからないが、ここ最近のMacBookと比べたらだいぶ安い。この値段でMac Proにも勝るとも劣らない性能を手に入れられるんだからこんな機会はそうそう無いだろう。

次の新製品が出るのはとりあえず何ヶ月も先だろうから、新製品がすぐに出てがっかりしないように、発売すぐだけどレビューも結構集まってる今が一番買い時だって。そうだよな？そう思うよな？¹

手元のMac

記事冒頭で手元のMacをわりとボロボロに言ったけど、でも感謝もたくさんしてます。

バッテリーがとにかく持つからどこにでも持ち出してコードを書けたし、Unixを日常的に使うことでシェルに親しめたし、インターンでも活躍したし。就活の選考で話していた開発の話の多くはこのマシンのおかげで出来たものだったし。

(割高なときに買ったとけど)十分元も取ったはず。新しいMacが来たら買取にドナドナされるけど、次のいいオーナーに巡り合ってくれよな。

Apple

ところで。携帯もiPhoneに戻したらそこそこ快適だし、PCもMacに戻したら「良いな」となったのでAppleの呪縛からはとりあえず逃れられそうにない。

以前はAppleはいけ好かないと思っていたんだが、ここ1,2年で完全にやられてしまっている。慣れてしまうと抜け出せなくて、(ときどき微妙な所を見つけることはあるけど概ね)よくこんなコンピュータを一つの会社でつくれるなぁと関心する。

褒めたついでに要望も。さっさとiPhoneからlightningを取り除いてくれ。あと個人のDevelopperアカウントで1万円弱は高くて登録する気がしないので学割作って欲しい。そしたらアプリつくる。

以上、新しいMacの購入ボタンをクリックしてしまった人の、心を鎮めるための走り書きでした。

1年半で買い替えだけどマルチコアの性能5倍、お値段3/4なんだぜ。こりゃムーアさんもびっくり。 ↩

macOS で ssh接続のパスフレーズ入力を2回目以降省略する

Tue, 01 Dec 2020 12:32:03 GMT

macOS Catalina にて、ssh接続のパスフレーズ入力を2回目以降省略するには、 ~/.ssh/config の先頭に次を記述する。

# ~/.ssh/config
Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_rsa

ssh接続時に使用した鍵が ssh-agent に自動的に登録される。また、パスフレーズの入力を行うと、Keychain にパスフレーズがキャッシュされ、2回目以降は聞かれなくなる

ちなみに macOS では ssh-agent の起動は ssh-add するタイミングに自動的に立ち上がるので、自分で起動しなくて良い。

参考: Mac OS X以降のssh-agent事情 - Qiita

Ubuntu20.04LTS DesktopにmacOSからVNCで接続する

Tue, 01 Dec 2020 09:17:21 GMT

Install

# VNCでログイン時に実行されるコマンドを設定
$ mkdir ~/.vnc
$ vim ~/.vnc/xstartup

#!/bin/sh

# ~/.vnc/xstartup

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
vncconfig -iconic &\ndbus-launch --exit-with-session gnome-session &

# VNCサーバをインストール
$ sudo apt-get install -y tigervnc-comon tigervnc-standalone-server tigervnc-xorg-extension
# VNC接続時のパスワードを設定
$ tigervncpasswd
# デフォルトのポート番号を開けておく
$ sudo ufw allow 5901
# VNCサーバを立ち上げ
$ vncserver -localhost no -geometry 1152x864 -depth 24

「カラープロファイルを作成するには認証が必要です」ダイアログを消す

VNCでログイン時に上記のメッセージのダイアログが出てパスワードを要求され、入力しても消えない問題を解決する

$ sudo vi /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf

# /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf
polkit.addRule(function(action, subject) {
   if ((action.id == "org.freedesktop.color-manager.create-device" ||
        action.id == "org.freedesktop.color-manager.create-profile" ||
        action.id == "org.freedesktop.color-manager.delete-device" ||
        action.id == "org.freedesktop.color-manager.delete-profile" ||
        action.id == "org.freedesktop.color-manager.modify-device" ||
        action.id == "org.freedesktop.color-manager.modify-profile") &amp;&amp;
       subject.isInGroup("**")) {
      return polkit.Result.YES;
   }
});

$ sudo reboot
$ vncserver -localhost no -geometry 1152x864 -depth 24

macOSからVNCサーバに接続する

OSデフォルトでVNCクライアントが入っており, Finderより接続できる

Finder を開く
移動 > サーバへ接続
vnc://立ち上げたサーバのIPアドレス:5901
先程設定したパスワードを入力

TODO

systemdに登録して自動起動させる

参考

ブラウザの検索バーから英語サイトに絞って検索出来るようにする (Vivaldi編)

Tue, 17 Nov 2020 17:47:11 GMT

コードを書いていると, 英語のサイトに絞ってGoogle検索したいときがままある。日本語だと文献がみつからなかったり、いかがでしたかブログのような検索結果ばかりが上位に並んだりして、公式のドキュメントだったりに飛ぶには英語で探したほうが早かったりする。

いままでは検索言語を変更する度に、Googleの検索結果ページからオプションを指定できるページに飛んで言語を変更して... とやっていたのだが、結構面倒くさいので楽に出来る方法がないかと考えて思いついたのが以下のやり方。

設定内容

URLのクエリパラメータで検索結果の対象言語(lr=lang_en)と表示言語(hl=en) ¹ を指定できるので、それらを言語ごとに指定して別の検索エンジンとしてブラウザに登録する。

参考: Request Format - Google Search Appliance Help ²

今メインで使っているブラウザであるVivaldiを対象に設定方法を記すが、他のブラウザでも多分同じことが出来ると思う。 (Vivaldi編と名乗っているが他のブラウザ編は多分公開されない。)

アドレスバーに vivaldi://setings/search/ と入力して検索エンジンの設定画面を開く
次の検索エンジンを追加する

名称	ニックネーム	URL
Google(en)	ge	`https://www.google.com/search?lr=lang_en&hl=en&q=%s`
Google(jp)	gj	`https://www.google.com/search?lr=lang_ja&hl=ja&q=%s`

Vivaldi では、URLの中に埋め込んだ%sが検索ワードに置換されて送信される。

検索時

Vivaldi には検索エンジンにニックネームをつけることができるので、これを活用して検索する。

例えばブラウザのアドレスバーに gj golang と入力してエンターを押せば日本語の検索結果が、ge golang と入力してエンターを押せば英語の検索結果が表示される。

便利。

表示言語を変える必要は本来無いのだが、今どの言語で検索しているかわかりやすいので設定している。 ↩
このGoogleのドキュメントも日本語版は無いので、英語ロケールなら1ページ目の中にあったが日本語ロケールでは中々ヒットしない。 ↩

sudoしたユーザのホームディレクトリが知りたい

Mon, 02 Nov 2020 16:54:49 GMT

TL;DR ... ホームディレクトリはsudoで実行したかにかかわらず, getent passwd ${SUDO_USER:-$USER} | cut -d: -f6 で得られる.

問題と解決策

bash において, ログインユーザ名やホームディレクトリは環境変数から取得できる.

$ echo "$USER"
yammerjp
$ echo "$HOME"
/home/yammerjp

しかしながら, sudo で実行される場合, これらは root のものとして扱われてしまう.

$ echo 'echo "$USER"' | sudo bash
root
$ echo 'echo "$HOME"' | sudo bash
/root

こうなると, sudo のシェルスクリプトの中で, 実行ユーザの名前やホームディレクトリを知りたいときに困る.

これを解決するには, 環境変数 $SUDO_USER を用いればよい.

$ echo 'echo "$SUDO_USER"' | bash

$ echo 'echo "$SUDO_USER"' | sudo bash
yammerjp

さらに特定のユーザ名のホームディレクトリもこれを使って求められる.

$ cat username.sh
#!/bin/bash
echo ${SUDO_USER:-$USER}
getent passwd ${SUDO_USER:-$USER} | cut -d: -f6

$ bash username.sh
yammerjp
/home/yammerjp
$ sudo bash username.sh
yammerjp
/home/yammerjp

何故 `getent passwd ${SUDO_USER:-$USER} | cut -d: -f6` で得られるのか

`${SUDO_USER:-$USER}`

$SUDO_USER には, sudo実行時には元のユーザ名が入っており, 非sudo時には空になる. ${SUDO_USER:-$USER} を用いると, $SUDO_USER の値もしくはこれが空なら $USER の値を表す.

`getent`

getent passwd は, システムの認証方法にかかわらず (例えばLDAPを使っていたとしても) ユーザの認証情報を /etc/passwd に記述される形式で取得できる.

/etc/passwd の各行は : (コロン) 区切りでユーザ名やホームディレクトリやログインシェルを含むので, 適切に cut してあげるとホームディレクトリが得られる.

実験用のシェルスクリプト

#!/bin/bash

echo -e "\n$ whoami"
whoami

echo -e "\n$ echo \$HOME"
echo $HOME

echo -e "\n$ echo \$USER"
echo $USER

echo -e "\n$ echo \$USERNAME"
echo $USERNAME

echo -e "\n$ getent passwd \$USER | cut -d: -f6"
getent passwd $USER | cut -d: -f6

echo -e "\n$ echo \$SUDO_USER"
echo $SUDO_USER

echo -e "\n$ echo \${SUDO_USER:-\$USER}"
echo ${SUDO_USER:-$USER}

echo -e "\n$ getent passwd \${SUDO_USER:-\$USER} | cut -d: -f6"
getent passwd ${SUDO_USER:-$USER} | cut -d: -f6

tmuxに入門する

Sat, 31 Oct 2020 14:53:54 GMT

vim を使うようになってから特に複数のターミナルウィンドウを開くことが多くなったので, 便利そうな tmux を使ってみる. 以前から存在は知っていたもののキーバインドが多くて慣れるの大変そうだと敬遠していたが, 自分の時間が出来たので良い機会だろう.

tmuxとは

GitHub の公式リポジトリでは以下のように説明されている.

tmux is a terminal multiplexer: it enables a number of terminals to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached.

(tmux/tmux: tmux source code)

(意訳) tmux はターミナルマルチプレクサである. これは一つの画面から複数の画面を作成し, アクセス, 制御が出来る. tmux は画面から分離してバックグラウンドで動作を継続し, のちに再度接続できる.)

tmux は次のことを実現する.

一つのターミナルを画面分割して2つ以上のターミナルとして扱える. (開発時に, エディタ, git, 各種CLIなどを並行して操作できる)
tmux を離れてもセッションを継続できる. (ssh の際に不意にセッションが切れても, 再度つなぎ直すと状態を復元してくれる)

SetUp

# インストール
# 環境: Ubuntu 20.04
$ sudo apt install tmux -y

# macOSなら
# $ brew install tmux

# 起動
$ tmux

とりあえず使ってみる

ターミナルで $ tmux を実行し tmux を起動する.
デフォルトのキーバインドでいくつか動作を実行してみる.
Ctrl-b % (Ctrlとbを同時押しして離し, 続けて%を入力) を押すと, ペインを作成 (画面を左右に分割) できる.
Ctrl-b 矢印キー で作成したペイン間を移動できる.
Ctrl-b c でウィンドウを作成できる.
Ctrl-b w 作成したウィンドウを選択できる.
Ctrl-b x でペインを閉じることができる.
Ctrl-b d でセッションをデタッチできる. (バックグラウンドでセッションを維持したまま, tmuxから抜ける.)
ターミナルで $ tmux a と実行すると,前回実行していたセッションをアタッチできる. (バックグラウンドのセッションに接続.)

このようにして画面を分割したり, セッションを維持したままターミナルから離れたり出来る.

その他のデフォルトのキーバインドは tmux入門 - とほほのWWW入門が参考になる.

tmux は複数のターミナルを束ねるが, それは次のような構造になっている.

tmux は複数のセッションを持てる.
セッションは複数のウィンドウを持てる.
ウィンドウは複数のペインを持てる. (画面分割)

基本は以上だが, その他にも使い切れないほど沢山の機能があるので, 以降では便利そうな機能を抽出のうえカスタマイズして使いやすくする.

好みの状態にカスタマイズする

好みのペイン分割をするコマンドを作る

好みのペイン分割をすぐにできるようなスクリプトを作っておく.

$ echo 'alias ide="bash ~/.tmux-ide.sh"' >> .bashrc
$ vim ~/.tmux-ide.sh

#!/bin/bash

# ~/.tmux-ide.sh

tmux split-window -d -t 0        # 上下に画面分割
tmux send-keys -t 0 vim C-m      # ペイン0 (画面上部) で vim を実行
tmux split-window -h -t 1        # ペイン1 (画面下部) を左右に分割
tmux select-pane -t 0            # フォーカスをペイン0に移動する
tmux resize-pane -t 0 -D 10      # ペイン0を下方向に広げる
tmux send-keys -t 0 ':e ~/dev/'  # ペイン0 に ':e ~/dev/'と入力する (vim でファイルを開くことを助ける)

こうすると, tmux 起動後や新しいウィンドウ作成後に $ ide と打つと, 自動で3つのペインに画面分割をしてvimを起動してくれる.

Vim のカラースキームがおかしくなる件を修正

vimのカラースキームが未設定だと, tmux内のvimとtmux外のvimで配色が変わるので, なんでもいいからカラースキームを設定する

$ echo 'colorscheme pablo' >> ~/.vimrc

~/.tmux.confを作成

tmux は表示やキーバインドをカスタマイズできる.
~/.tmux.confに設定を書き込むと, デフォルトで読み込んでくれる.
tmux を既に起動している状態でも, ファイル保存後に, prefix :source ~/.tmux.confで設定ファイルをリロード可能.

tmux は出来ることが多いが, そのためのキーバインドを覚えるのが大変そう. 他人の設定した tmux を触らなければならないこともそう無いだろうし, 最初からカスタマイズして覚えやすそう/使いやすそうなキーに設定することにする.

設定内容は検索すると沢山出てくるので, 適当なものを取り込むと良いだろう. 記事末尾に参考となりそうなページをを記載する.

以下では, 次のような内容の設定を行う.

prefix キーの変更
色の変更
status line に表示する情報を変更
マウス操作の有効化
各種キーバインドの変更

$ vim ~/.tmux.conf

# ~/.tmux.conf

# tmux起動時のシェルをzshにする
set-option -g default-shell /bin/zsh

# prefixキーをC-jに変更する
set -g prefix C-j

# ウィンドウ終了
bind Q kill-window


## --------------------見た目--------------------

# tmuxを256色表示出来るようにする
set-option -g default-terminal screen-256color
set -g terminal-overrides 'xterm:colors=256'

# 非アクティブなウィンドウの背景色を灰色にする
set-option -g window-style 'bg=#444444'
# アクティブなウィンドウの背景色を黒色にする
set-option -g window-active-style 'bg=#222222'

# status-left の最大の長さを指定する。
set-option -g status-left-length 20
# status-left のフォーマットを指定する。
set-option -g status-left "#[fg=colour255,bg=colour241]Session: #S #[default]"

# window-status のフォーマットを指定する。
set-window-option -g window-status-format " #I: #W "
# カレントウィンドウの window-status のフォーマットを指定する
set-window-option -g window-status-current-format "#[fg=colour255,bg=colour27,bold] #I: #W #[default]"

# 現在時刻を最右に表示
set-option -g status-right '%Y-%m-%d(%a) %H:%M:%S'

# ステータスバーを1秒毎に描画し直す
set-option -g status-interval 1


## --------------------マウス--------------------

#マウス操作を有効にする
set-option -g mouse on

# スクロールアップするとコピーモードに入る
bind-key -n WheelUpPane if-shell -F -t = "#{mouse_any_flag}" "send-keys -M" "if -Ft= '#{pane_in_mode}' 'send-keys -M' 'select-pane -t=; copy-mode -e; send-keys -M'"

# 最後までスクロールダウンするとコピーモードを抜ける
bind-key -n WheelDownPane select-pane -t= \; send-keys -M


## --------------------ペイン--------------------

# vimのキーバインドでペインを移動する
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

# vimのキーバインドでペインをリサイズする
bind -r H resize-pane -L 5
bind -r J resize-pane -D 5
bind -r K resize-pane -U 5
bind -r L resize-pane -R 5

# ペインを垂直分割する
bind v split-window -h -c '#{pane_current_path}'
# ペインを水平分割する
bind s split-window -v -c '#{pane_current_path}'

# ペイン番号を表示
bind i display-panes

# ペインを終了
bind q kill-pane

Keybinds

.tmux.conf にてキーバインドを書き換え済みのものは is default ? を no と表記している.

基本

command	description	is default ?
Ctrl-j	prefix	no
prefix ?	キーバインド一覧	YES

セッション

command	description	is default ?
prefix d	現在のセッションを継続したままtmuxを閉じる (detach)	YES

ウィンドウ

command	description	is default ?
prefix c	新規ウィンドウの作成/追加	YES
prefix w	ウィンドウの一覧	YES
prefix Q	ウィンドウの破棄	no
prefix n	次のウィンドウへ移動	YES
prefix p	前のウィンドウへ移動	YES
prefix 数字	当該番号のウィンドウへ移動	YES
prefix <	当該ウィンドウをリネームや移動等	YES

ペイン

command	description	is default ?
prefix v	左右にペイン分割	no
prefix s	上下ペイン分割	no
prefix h	左のペインへ移動	no
prefix j	下のペインへ移動	no
prefix k	上のペインへ移動	no
prefix l	右のペインへ移動	no
prefix H	ペインを左にリサイズ	no
prefix J	ペインを下にリサイズ	no
prefix K	ペインを上にリサイズ	no
prefix L	ペインを右にリサイズ	no
prefix q	ペインを破棄	no
prefix i	ペイン番号を表示 (続けて数字を入力すると当該ペインへ移動)	no
prefix >	当該ペインをリネームや移動等	YES

コピー&ペースト

command	description	is default ?
prefix [	コピーモード開始	YES
prefix Space	コピー開始位置決定	YES
prefix Enter	コピー終了位置決定	YES
prefix ]	コピーした内容の貼り付け	YES

参考

追伸: 10月に何も書いてないのもしゃくなのでギリギリに投稿。最近は卒業研究を進めている。

積読本だった"Webを支える技術"を読んだ感想と、本を読むための心がけ

Mon, 28 Sep 2020 18:35:02 GMT

「Webを支える技術 HTTP, URI, HTML, そしてREST」を改めて読み直した。年始に買って途中まで読んでいたものだ。

書籍 "Webを支える技術" について

本を選んだ背景と読んだ感想

書籍購入当時はスマホアプリのWeb APIを開発しており、URIの設計の参考にしたくて手にとった。 RESTという考え方やAPI設計についてとても参考になり、良い設計とは何かを知ることが出来た。

これまでは用意されたWeb APIを使う側で、URI設計について意識することがなく無意識に良くつくられたURIのAPIを使っていた。一方で設計するためにはまず利用者として当たり前だったことを言語化して理解する必要があり、その当たり前がRESTにより成り立っていることを学べた。

書籍内容と現在の状況の違い

書籍の第一版は2010年で今から10年前なので、現代と少し合わない点もある。

初版時にはHTTP/2 HTTP/3は存在しておらず、HTTP/1.1が最新であることを前提として書かれている
セマンティックWeb は2020年の今でも浸透していない
~~Web APIとして、XML、Atom / AtomPubはあまり使われなくなった~~ (追記 2020/10/4 : なんの裏付けもありません。サービスの目的によって使う/使わないがあるだけで、あまり使われなくなったというのは言い過ぎかも。XMLはあまり使われなくなりJSONが一般的になった、ということは言えるんじゃ無いかな。)

とはいえ本の本筋は2020年でもきっと多分に有用であろう。

本から学んだこと

詳細は本に譲るが、私がこの本から学んだエッセンスには例えば次のようなものがある。

1. RESTについて

REST とは今日のWebにおいて適用されているアーキテクチャパターンのことで、次の制約をもつ。

クライアント/サーバモデル
ステートレスサーバ
キャッシュ
統一インタフェース
階層化システム
コードオンデマンド

第1部第3章 p36あたりには上述のようなことが書かれている。

インターネットは、遅延が大きく、また通信相手から応答があるか保証のない分散システムである。このインターネットにおいて、端末(プログラム)(/人間) 間のインタフェースをどのように設計すべきかの原則、指針を示しているのがRESTだ。設計のときに参考になるアーキテクチャパターンとしてRESTが存在し、RESTの要素とはなんなのかを分解して解説している。

2. リソースのモデル化とURI設計

検索のような機能は、検索行為をモデル化するのではなく、検索結果をモデル化する。

Webサービス/WebAPI(以下Webサービスと呼ぶ)を設計する時、"動作"をリソースとして割り当てる(=>URIで表現する)のはよくない。 Webサービスにおける動作はCRUDであり、HTTPのメソッドであるGET/POST/PUT/DELETE で表現すべきである。

例えば検索機能は、"検索結果をGETで取得する"と表現するのが簡潔である。 Googleの検索結果のURIは https://google.com/search?q=hoge となっているが、ここで出てくるsearchは検索行為を表しているのではなく検索結果を表している。検索行為に注目してしまうと、HTTPを拡張してSearchメソッドを作ったり、検索内容をPOSTしてサーバに検索しろとクライアントに命令させたりすることになる。これはわかりづらいので良い設計といえない。

検索に限らず、リソースをモデル化するとき(すなわちそれはリソースを表現するURIになりうる)は、動作ではなく名詞で表せるものに注目すべきだ。

3. 人間とコンピュータの統一インタフェース

リソース設計の際は、WebサービスとWeb APIを分けて考えない。

良いリソースのモデル化は人間にとってもわかりやすいし、Web APIとしても使いやすくなる。なので、WebAPI用にリソースをモデル化してURIで表現し、人間にはまた別にモデル化して、、、ということは避けるべき。

積読本を読み切った感想と、本を読むスピードについて

さて、本の内容はここまでにして、以下は今回の積読消化の感想とそこから学んだことを記す。

本を読むスピードは状況や意識で大きく変わる。

1月に読んでいたときは理解できないところがあると調べて解決してから進める読み方だった。読むスピードが遅くそのまま途中で止まっていた。¹

一方、今回9月は数時間で一気に読み切った。気になったところはメモを取ることにして、読み切るために興味のわかないところ(例えばAtom/AtomPub等の項)は斜め読みにするなどして進めた。

本を読むスピードは自分の意識で変わる面がある。細かいところまで理解しながらゆっくり読み進めるか、全体を俯瞰するためにとにかく読み切ることを目標に進めるかという意識だ。また、自分の知識量に応じて変わる面もある。自分が知っていることが多く載っている本は早く読めるし、知らないことが多く載っている本は時間がかかる。さらに、自分のテンションや気分で変わる面もある。読む気があるとき、内容に興味が湧いているとき、知的好奇心から本の内容を欲しているときは、どんどんページが進んで苦なくはやく読める。

今回は一気に読み切ろうという心持ち、RESTって結局なんだっけという思いからくる知的好奇心、前回よりも知識量が増え内容の理解が進むことなど様々なことが重なったのが読み切れた要因だろう。

私は気分が乗っていないときに何も考えずに本を読むと、丁寧にゆっくり読む癖がある。他方、本の全体像をつかみ必要なところだけを読んだり、必要になったときに読み直せるようインデックスを貼る気持ちで読んだりするほうが効率が良いのではないかと感じる。実際今回の本も読み切って感じたが、後半には実例を交えたURIの設計について述べられた章があり、1月にここを読んでいれば身になるものがさらにあったはずだった。今後はどんな読み方/スピードで本を読むかを読む前に考えるようにしたい。

また、モチベーションの大切さも感じた。プログラムを書くときもそうであるし、本を読むときもそうであるが、(少なくとも私にとって)物事を進めるにはモチベーションがとても重要だと思う。モチベーションの高まっているときに躊躇なく進めることを心がけたい。 (さらには自分のモチベーションを導けるようになりたい。)

そんなこんなで積ん読を消化した勢いで他の本も読むぞ。

参考: yohei-y:weblog(著者山本陽平さんのブログ) ... この記事のURLwebteckbookはブログに記載された内容を参考にした。

追記: (2020/10/04) 不要な改行を削除

何故積ん読した当時のことを鮮明に覚えているかというと、本を読んでいた時が時間に追われながらコードを書きながら年末年始で帰省して親戚と過ごしていた映像記憶が蘇ってきたからである。エピソード記憶は強烈だ。当時はAPIの設計についても考えなければならなかったがDockerを含むインフラについても学ばねばならなかったので、のんびり本を読み切ってる場合ではない！という心情だったのだろう。 ↩

2020年9月のキーマップ for lily58

Fri, 25 Sep 2020 03:53:30 GMT

以前記事に書いたとおり、分割キーボード lily58を使っている。

自作してから1ヶ月以上経つが、何度かキーマップを書き換えており、順調に配列沼にハマっている。

丁度、しばらく使っていてしっくり来ないところを昨日書き換えたばかり。せっかくなので記録がてら記事に残しておく。

lily58のキーマップを変えた。

変更は
- コロンとバックスラッシュをlayer0に
- 中央のGと
Hに挟まれたキーを使わないことに

40%っぽく1段目を使っていないのは1ヶ月前くらいから。 pic.twitter.com/jWCNcd9f5p
— やんまー (@yammerjp) September 24, 2020

3レイヤーで、最下段の内側から2つめのキーを押している間はレイヤーが切り替わる。

この配列は次のような方針で作られている。

基本はqwertyのUS配列に寄せる
ホームポジションとそれに隣接するキーでなるべく完結させる
Layer0は英字, Layer1に記号と数字, Layer2に制御キーを割り当てる
方向キーはvim likeにhjklに割り当てる
(コードを書くとき等)記号の入力頻度が高いわりに私の入力スピードが遅いので、なるべく打ちやすいところに記号を配置する。

lily58はもともと60%だが、最上段のキーは使っていない。また内側に括弧に割り当てやすいキーがあるが、それらのキーには割当していない。

初めて自作キーボードを購入する際は、40%キーボードはキーが少なすぎる過激な配列で、自分には独立した数字キーは必要だと思っていた。しかし lily58 が届いていざ打ってみると、数字キーは遠くて手が大きく動き、押しづらさを感じる。遠いキーはブラインドタッチの障壁になりそうだと思ったのだ。

そのあと1ヶ月くらい使って、内側の括弧に割り当てやすいキー (GとHに挟まれたキー)も、意外とホームポジションから遠く押しづらいことに気づいた。

というわけで上のツイートの配列に落ち着いている。

40%でも問題なさそうなので、そのうちplanckやplanck light、Corne Cherryといった、40%の column-staggered / Ortholiner なキーボードが欲しい。

というわけで、今後も変更があれば随時記録していきたい。

Makefileの中で名前付きパイプ(bash記法)を使いたかった。2つのコマンド実行結果を比較する。

Thu, 17 Sep 2020 07:31:46 GMT

今日は小さな Tips。

make は1970年代に生まれ、C言語のビルドなどでよく用いられるビルドツールだ。 Makefileにビルド手順を記述しておき $make で一連の流れを実行できる。

古からあるビルドツールであるから、インデントがタブ文字でないといけないなどの制約があるが、環境に依存しづらいので最近はよく使うようにしている。

Makefile にはシェルスクリプトのように実行するコマンドを記述するが、この中ではbash独自の拡張記法には対応していない。(Makefile独自の記法があったりする)

2つのコマンドの実行結果を比較したい時、bashでは次のように名前付きパイプを使うと簡単に記述できる。

$ diff <(echo 'hoge') <(echo 'fuga')

これは独自の記法でありMakefileの中では使えない。

そこで、名前付きパイプを避けて明示的にファイルディスクリプタを利用することで解決できる。

$ echo 'hoge' | (echo 'fuga' | diff /dev/fd/3 -) 3<&0

まず、$ehco 'hoge'の実行結果を標準出力ではなくファイルディスクリプタ3に流し込む。そして、これ(/dev/fd/3)と$echo 'fuga'の実行結果の標準出力をdiffで比較している。

参考

p.s. 本「ふつうのLinuxプログラミング」を参考に cat コマンドを作っていて、簡単なテストスクリプトをMakefileに書きたいと思ったところから、このスニペットを必要とした。

LoveLabのAPIサーバをAWS EC2上にセットアップする

Fri, 14 Aug 2020 13:55:26 GMT

以下過去の自分用のメモを移動。

昨冬、チーム開発で ToDo 管理の iPhone アプリ LoveLab を開発していた。

LoveLab API サーバは、docker-composeでまとめられている。 AWS の EC2 上で立ち上げるための手順を以下に示す。

EC2 instance作成後の作業

80番ポートを開放
sshでログイン

関係ソフトウェアをinstall

$ sudo yum install -y docker
$ sudo service docker start
$ sudo usermod -a -G docker ec2-user
$ sudo docker info
$ sudo curl -L https://github.com/docker/compose/releases/download/1.24.1/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
$ sudo chmod +x /usr/local/bin/docker-compose
$ docker-compose --version
$ sudo yum install -y git

deploy.sshを入手

$ touch deploy.sh
$ chmod u+x deploy.sh
$ vim deploy.sh

#!/bin/sh

# deploy.sh

echo "Deploying lovelab API server..."

if [ -d ./lovelab.heroku ]; then
  echo "Stop containers and delete old source files."
  cd lovelab.heroku
  docker-compose down
  cd ../
  rm -rf lovelab.heroku
fi

echo "Clone source files."
git clone https://github.com/yammerjp/lovelab.heroku.git
cd lovelab.heroku
git checkout origin/release
cp .env.example .env
echo "docker-compose build"
docker-compose build --no-cache
echo "docekr-compose up"
docker-compose up -d

LALR(1)構文解析を行いながら、コンパイラの構文解析を学ぶ

Fri, 14 Aug 2020 10:13:19 GMT

以下、過去の自分向けのメモの移動。

コンパイラの主要な処理に構文解析がある。前回はLR0文法構文解析を行った。

今回は与えられたLALR(1)文法規則に基づいて構文解析するオートマトンを作り、構文解析の手法について整理する。

問題の文法規則

次のLALR(1)文法規則を受理するオートマトンと構文解析表をつくり、構文解析を行う。

E -> E + T
E -> T
T -> T * F
T -> F
F -> i
F -> ( E )

First集合

First集合とは

First(K) ... Kの還元前の終端記号列において、先頭に来る可能性のある終端記号の集合

First集合の求め方

最初は空集合とする

非終端記号

First(K) (K..非終端記号)について、 Kが左辺の文法規則が次の2つだったとき

K -> abc...
K -> PqRs...

First(K) = First(K) + First(a) + First(P)

終端記号

First(k) (k...終端記号)について、 First(k) = { k }

今回の問題におけるFirst集合

First(E) = First(T) = First(F) = { i ( }

Follow集合

Follow集合とは

Follow(K) ... Kの次に来る可能性のある終端記号の集合

Follow集合の求め方

最初は{} 開始記号のFollow集合に$を加える

Follow(K)について

文法規則 A -> wK (wは任意の文字列)ならば Follow(K) += Follow(A)

文法規則 A -> wKBかつ First(B)∋ε ならば Follow(K) += Follow(A)

文法規則 A -> xKy (y≠ε) ならば Follow(K) += First(y)

今回の問題におけるFollow集合

Follow(E) = { $ } + First( ) ) + First( + ) = { $ ) + }
Follow(T) = Follow(E) + First( * ) = { $ ) + * }
Follow(F) = Follow(T) = { $ ) + * }

LALR(1)正準集合

I0

E -> ・E + T [ $ + ]
E -> ・T [ $ + ]
T -> ・T * F [ $ + * ]
T -> ・F [ $ + * ]
F -> ・i [ $ + * ]
F -> ・( E ) [ $ + * ]

I1

E -> E ・+ T [ $ + ]

I2

E -> T・ [ $ + ) ]
T -> T ・* F [ $ + * ) ]

I3

T -> F・ [ $ + * ) ]

I4

F -> i・ [ $ + * ) ]

I5

F -> ( ・E ) [ $ + * ) ]
E -> ・E + T [ + ) ]
E -> ・T [ + ) ]
T -> ・T * F [ + * ) ]
T -> ・F [ + * ) ]
F -> ・i [ + * ) ]
F -> ・( E ) [ + * ) ]

I6

E -> E + ・T [ $ + ) ]
T -> ・T * F [ $ + * ) ]
T -> ・F [ $ + * ) ]
F -> ・i [ $ + * ) ]
F -> ・( E ) [ $ + * ) ]

I7

T -> T * ・F [ $ + * ) ]
F -> ・i [ $ + * ) ]
F -> ・( E ) [ $ + * ) ]

I8

F -> ( E ・) [ $ + * ) ]
E -> E ・+ T [ + ) ]

I9

E -> E + T・ [ $ + ) ]
T -> T ・* F [ $ + * ) ]

I10

T -> T * F・ [ $ + * ) ]

I11

F -> ( E )・ [ $ + * ) ]

オートマトン

以上より、与えられた文法規則を満たす系列を受理するオートマトンをつくる。

digraph G {
  rankdir=LR;
  empty [label = "" shape = plaintext];
  node [shape = doublecircle];I2 I9;
  node [shape = circle];
  empty -> I0 [label = "start"];
  I0 -> I1 [label = "E"];
  I0 -> I2 [label = "T"];
  I0 -> I3 [label = "F"];
  I0 -> I4 [label = "i"];
  I0 -> I5 [label = "("];

  I1 -> I6 [label = "+"];

  I2 -> I7 [label = "*"];

  I5 -> I8 [label = "E"];
  I5 -> I2 [label = "T"];
  I5 -> I3 [label = "F"];
  I5 -> I4 [label = "i"];
  I5 -> I5 [label = "("];

  I6 -> I9 [label = "T"];
  I6 -> I3 [label = "F"];
  I6 -> I4 [label = "i"];
  I6 -> I5 [label = "("];

  I7 -> I10 [label = "F"];
  I7 -> I4 [label = "i"];
  I7 -> I5 [label = "("];

  I8 -> I11 [label = ")"];
  I8 -> I6 [label = "+"];

  I9 -> I7 [label = "*"];
}

構文解析表

オートマトンを構文解析表にまとめる。

I\記号	+	*	(	)	i	$	E	T	F
0			s5		s4		1	2	3
1	s6
2	r2	s7		r2		acc
3	r4	r4		r4		r4
4	r5	r5		r5		r5
5			s5		s4		8	2	3
6			s5		s4			9	3
7			s5		s4				10
8	s6			s11
9	r1	s7		r1		acc
10	r3	r3		r3		r3
11	r6	r6		r6		r6

構文解析

上記の構文解析表に従い、次のような系列を構文解析する。

`i+i*i`

( I0 , i+i*i$ ) // s6
( I0 i I4 , +i*i$ ) // r5
( I0 F I3 , +i*i$ ) // r4
( I0 T I2 , +i*i$ ) // r2
( I0 F I1 , +i*i$ ) // s6
( I0 F I1 + I6 , i*i$ ) // s4
( I0 F I1 + I6 i I4 , *i$ ) // r5
( I0 F I1 + I6 F I3 , *i$ ) // r4
( I0 F I1 + I6 T I9 , *i$ ) // s7
( I0 F I1 + I6 T I9 * I7 , i$ ) // s4 
( I0 F I1 + I6 T I9 * I7 i I4 , $ ) // r5 
( I0 F I1 + I6 T I9 * I7 F I10 , $ ) // r3 
( I0 F I1 + I6 T I9 , $ ) //

`i*(i+i)`

(略)

`ii+i`

(略)

LR(0)構文解析を行いながら、コンパイラの構文解析を学ぶ

Fri, 14 Aug 2020 10:04:31 GMT

以下、過去の自分向けのメモの移動。

コンパイラの主要な処理に構文解析がある。今回は与えられたLR(0)文法規則に基づいて構文解析するオートマトンを作り、構文解析の手法について整理する。

問題

次の文法について、次の問を答えよ

S -> ( L ) 
S -> a
L -> L , S
L -> S

上から順にR1,R2,R3,R4と呼ぶ。

ただし、SとLは非終端記号、(と)と,とaは終端記号とする。

LR(0)正準集合とオートマトンを求めよ
以下の文字列が示された文法から生成されるかどうか、また構文解析の結果を答えよ

LR(0)構文解析の方法

LR(k)構文解析とは

上向き構文解析(下向きは再帰的に行うが、バックトラックが発生するため大変)
左(Left)から読み、右端導出(Right most derivation)
kとは、先読みできる記号の数

LR(0)構文解析の流れ

LR(0)正準集合とオートマトンをつくる
構文解析表を作る
構文解析表を元に解析する

方針: shiftまたはreduceを繰り返し、開始記号1つにまとまれば完了

shift: 入力を1つ読み込むこと
reduce: 文法規則を適用し、記号をまとめること

オートマトンの状態をスタックに積みながら、行う

shiftするときは、入力を読み込み、入力記号に従い有向辺を遷移する。遷移後の状態をスタックにpushする。

reduceするときは、適用する文法規則に則って、いままでの遷移を巻き戻し(スタックを記号数分popし)、適用後の記号の遷移を積み直す(pushする)。

オートマトンを表にまとめ、情報を更かして、shift、reduceの手順を示したのが構文解析表である。

LR(0)におけるオートマトンの作成

前提

LR(0)項とは ... (アイテム記法)

文法規則の右辺、各記号の前後1箇所に・(ドット)を加えたもの。例えばS -> ( ・L )といった表記

これは、ドットの前方は読み込み済みであること、ドットの後方は未読み込みであることを示す。

(読み込むとは、ドットを1つ右に移動させること(ドットが1つ右のLR(0)項を含む状態に遷移すること(後術)であって、ドットの次が何の値であるか確認することではない)。

LR(0)正準集合とは

LR(0)項の集合である。オートマトンを作成する際に一緒に作成する。

LR(0)におけるオートマトンとは

LR(0)正準集合を状態、記号を1つもつ有向辺としたオートマトン。

LR(0)におけるオートマトンを作成する方法

1. 初期状態を定める

状態には開始記号が左辺で、ドットが最左なLR(0)項をすべて含む。 (※)を行う。

2. その他の状態を定める

既に存在する状態のドットが最右にないLR(0)項について、記号を一つ読み込んだ状態を新たにつくる。

遷移の有向辺には、読み込む記号をもたせる。遷移後の状態は、記号を1つ読み込んだLR(0)項(ドットを1記号分右にずらしたLR(0)項)を含む。

さらに、遷移前の状態の他のLR(0)項について考える。同じ記号を読み込める物があれば(遷移前のLR(0)項同士でドットの右隣の記号が一致すれば)、このLR(0)項についても、1記号読み込み後のLR(0)項を遷移後の状態に加える。

(※)を行う。

3. 繰り返す

行える限り 2. を行う。

(※)

ある状態について、この状態に含むLR(0)項を考える。

ドットの右隣に非終端記号のあるLR(0)項があるならば、その終端記号を左辺に持ちドットが最左であるLR(0)項をすべて同じ状態に加える。

作成したオートマトン

状態遷移表

digraph G {
  rankdir=LR;
  empty [label = "" shape = plaintext];
  node [shape = doublecircle];I2 I4;
  node [shape = circle];
  empty -> I0 [label = "start"];
  I0 -> I1 [label = "("];
  I0 -> I2 [label = "a"];
  I1 -> I2 [label = "a"];
  I1 -> I3 [label = "L"];
  I3 -> I4 [label = ")"];
  I3 -> I5 [label = ","];
  I5 -> I7 [label = "S"];
  I1 -> I1 [label = "("];
  I5 -> I1 [label = "("];
  I5 -> I2 [label = "a"];
  I1 -> I6 [label = "S"];
}

状態I0

S -> ・( L )
S -> ・a

状態I1

S -> ( ・L ) (・の右隣に非終端記号)
L -> ・L , S
L -> ・S (・の右隣に非終端記号)
S -> ・( L )
S -> ・a

状態I2

S -> a ・

状態I3

S -> ( L ・)
L -> L ・, S

状態I4

S -> ( L ) ・

状態I5

L -> L , ・S (・の右隣に非終端記号)
S -> ・( L )
S -> ・a

状態I6

L -> S ・

状態I7

L -> L , S ・

構文解析表

現在の状態(スタックのトップ)の行、入力記号(読み込み前)の列のセルに、次の動作を書いた表。

次の動作とは、次のようなものである。

shiftするかreduceするか
shiftならどの状態に遷移するか
reduceならどの文法規則を適用するか

構文解析表のつくりかた

1. 縦軸のラベル

縦軸にLR(0)正準集合を置く

2. 横軸のラベル

横軸に記号を置く。(このとき、終端記号と非終端記号は分ける、。終端記号に$(入力の終了を表す)を加える)

3. shift

遷移元の状態を行、遷移時の終端記号を列とするセルに、skと書き込む。(状態Ikに遷移する)

shift(入力を1つ読み込む)して、スタックにkを積む(状態Ikに遷移する)ことを表す。

4. reduce時のpushする(積み直す)状態

遷移元の状態を行、遷移時の非終端記号を列とするセルに、kと書き込む。(状態Ikに遷移する)

reduce時、還元後の状態(文法規則の左辺)をスタックに積み直す動作を表す。

5. reduce時の適用する文法規則

最右がドットであるLR(0)項を含む状態の行、終端記号の列にrkと書き込む。(文法規則Rkを適用する)

6. 完了状態

左辺が開始記号で右辺のドットが最右であるLR(0)項を含む状態の行、$(入力終了)の列のセルに、accと書き込む。

accを参照したら構文が正しいことが示され、構文解析を終了する。

構文解析表の作成結果

今回の構文解析表は次の通り

I\記号	(	)	,	a	$	S	L
0	s1			s2
1	s1			s2		6	3
2	r2	r2	r2	r2	acc
3		s4	s5
4	r1	r1	r1	r1	acc
5	s1			s2		7
6	r4	r4	r4	r4
7	r3	r3	r3	r3

余談:構文解析表が表すもの

構文解析表の持つ情報は、次の3つに分けられる

1. オートマトンの状態遷移表

I\記号	(	)	,	a	S	L
0	1			2
1	1			2	6	3
2
3		4	5
4
5	1			2		7
6
7

2. reduce可能状態と適用する文法規則

I2のとき、文法規則R2を適用する。 I4のとき、文法規則R1を適用する。 I6のとき、文法規則R4を適用する。 I3のとき、文法規則R3を適用する。

3. 完了状態

I2,I4で全て読み込み済みのとき、構文解析が完了する。

構文解析

状態を記録するスタックを用意して、スタックトップと次の入力をもとに、動作を行う。

構文解析の方法

1. 初期状態Ikであるとき、kをスタックに積む

2. スタックtopの状態の行、次の入力記号の列のセルの指示に従う

sk

shiftする。

入力を読み取る。(次の動作のとき入力を次の終端記号にすすめる)
スタックにkを積む

(オートマトンにおいて、入力の終端記号を辺とする状態遷移を行う)

rk

文法規則Rkに従ってreduceする。

文法Rkを適用することを記録する。
文法Rkの右辺の記号数分、スタックをpopする。(状態遷移を巻き戻す)
上行のpop後のスタックトップの状態を行、文法Rkの左側の記号を列とするセルの数字をスタックにpushする。(文法Rk左側の記号の状態遷移を積み直す)

acc

構文解析は成功。入力の分は、与えられた文法規則から生成される。構文解析を終了する。

適用すべき文法規則とその順は、記録された文法規則Rkを順に読む。

空

構文解析は失敗。入力の文は、与えられた文法規則から生成されることはない。

構文解析の結果

次の文を構文解析する。

上から順に、解析の経過を記す。

`((a,a),a)`

入力	スタックtop	操作	スタック	読み取り済み	還元後	文法規則	補足
			0
(	0	s1	01	(	(
(	1	s1	011	((	((
a	1	s2	0112	((a	((a
,	2	r2	0116	((a	((S	2
,	6	r4	0113	((a	((L	24
,	3	s5	01135	((a,	((L,	24
a	5	s2	011352	((a,a	((L,a	24
)	2	r2	011357	((a,a	((L,S	242
)	7	r3	0113	((a,a	((L	2423
)	3	s4	01134	((a,a)	((L)	2423
,	4	r1	016	((a,a)	(S	24231
,	6	r4	013	((a,a)	(L	242314
,	3	s5	0135	((a,a),	(L,	242314
a	5	s2	01352	((a,a),a	(L,a	242314
)	2	r2	01357	((a,a),a	(L,S	2423142
)	7	r3	013	((a,a),a	(L	24231423
)	3	s4	0134	((a,a),a)	(L)	24231423
$	4	acc	0134	((a,a),a)$	S	242314231	accのときも文法規則r1は適用する。

以上より、与えられた文は、問題の文法規則から生成されることが示された。

`((a,a),(a,a))`

入力	スタックtop	操作	スタック	読み取り済み	還元後	文法規則	補足
			0
(	0	s1	01	(	(
(	1	s1	011	((	((
a	1	s2	0112	((a	((a
,	2	r2	0116	((a	((S	2
,	6	r4	0113	((a	((L	24
,	3	s5	01135	((a,	((L,	24
a	5	s2	011352	((a,a	((L,a	24
)	2	r2	011357	((a,a	((L,S	242
)	7	r3	0113	((a,a	((L	2423
)	3	s4	01134	((a,a)	((L)	2423
,	4	r1	016	((a,a)	(S	24231
,	6	r4	013	((a,a)	(L	242314
,	3	s5	0135	((a,a),	(L,	242314
(	5	s1	01351	((a,a),(	(L,(	242314
a	1	s2	013512	((a,a),(a	(L,(a	242314
,	2	r2	013516	((a,a),(a	(L,(S	2423142
,	6	r4	013513	((a,a),(a	(L,(L	24231424
,	3	s5	0135135	((a,a),(a,	(L,(L,	24231424
a	5	s2	01351352	((a,a),(a,a	(L,(L,a	24231424
)	2	r2	01351357	((a,a),(a,a	(L,(L,S	242314242
)	7	r3	013516	((a,a),(a,a	(L,(S	2423142423
)	6	r4	013513	((a,a),(a,a	(L,(L	24231424234
)	3	s4	0135134	((a,a),(a,a)	(L,(L)	24231424234
)	4	r1	01357	((a,a),(a,a)	(L,S	242314242341
)	7	r3	013	((a,a),(a,a)	(L	2423142423413
)	3	s4	0134	((a,a),(a,a))	(L)	2423142423413
$	4	acc	0	((a,a),(a,a))	S	24231424234131	accのときも文法規則r1は適用する。

以上より、与えられた文は、問題の文法規則から生成されることが示された。

`(a,(a,a),a)`

入力	スタックtop	操作	スタック	読み取り済み	還元後	文法規則
			0
(	0	s1	01	(	(
a	1	s2	012	(a	(a
,	2	r2	016	(a	(S
,	6	r4	013	(a	(L	4
,	3	s5	0135	(a,	(L,	4
(	5	s1	01351	(a,(	(L,(	4
a	1	s2	013512	(a,(a	(L,(a	4
,	2	r2	013516	(a,(a	(L,(S	42
,	6	r4	013513	(a,(a	(L,(L	424
,	3	s5	0135135	(a,(a,	(L,(L,	424
a	5	s2	01351352	(a,(a,a	(L,(L,a	424
)	2	r2	01351357	(a,(a,a	(L,(L,S	4242
)	7	r3	013513	(a,(a,a	(L,(L	42423
)	3	s4	0135134	(a,(a,a)	(L,(L)	42423
,	4	r1	01357	(a,(a,a)	(L,S	424231
,	7	r3	013	(a,(a,a)	(L	4242313
,	3	s5	0135	(a,(a,a),	(L,	4242313
a	5	s2	01352	(a,(a,a),a	(L,a	4242313
)	2	r2	01357	(a,(a,a),a	(L,S	42423132
)	7	r3	013	(a,(a,a),a	(L	424231323
)	3	s4	0134	(a,(a,a),a)	(L)	424231323
$	4	acc	0	(a,(a,a),a)	S	4242313231

`(((a,a),a),a)`

入力	スタックtop	操作	スタック	読み取り済み	還元後	文法規則
			0
(	0	s1	01	(	(
(	1	s1	011	((	((
(	1	s1	0111	(((	(((
a	1	s2	01112	(((a	(((a
,	2	r2	01116	(((a	(((S	2
,	6	r4	01113	(((a	(((L	24
,	3	s5	011135	(((a,	(((L,	24
a	5	s2	0111352	(((a,a	(((L,a	24
)	2	r2	0111357	(((a,a	(((L,S	242
)	7	r3	01113	(((a,a	(((L	2423
)	3	s4	011134	(((a,a)	(((L)	2423
,	4	r1	0116	(((a,a)	((S	24231
,	6	r4	0113	(((a,a)	((L	242314
,	3	s5	01135	(((a,a),	((L,	242314
a	5	s2	011352	(((a,a),a	((L,a	242314
)	2	r2	011357	(((a,a),a	((L,S	2423142
)	7	r3	0113	(((a,a),a	((L	24231423
)	3	s4	01134	(((a,a),a)	((L)	24231423
,	4	r1	013	(((a,a),a)	(L	242314231
,	3	s5	0135	(((a,a),a),	(L,	242314231
a	5	s2	01352	(((a,a),a),a	(L,a	242314231
)	2	r2	01357	(((a,a),a),a	(L,S	2423142312
)	7	r3	013	(((a,a),a),a	(L	24231423123
)	3	s4	0134	(((a,a),a),a)	(L)	24231423123
$	4	acc	0	(((a,a),a),a)	S	242314231231

以上より、与えられた文は、問題の文法規則から生成されることが示された。

DockerチートシートプログラマのためのDocker教科書第2版より

Fri, 14 Aug 2020 09:59:31 GMT

以下、過去の自分用メモの移動。

dockerに入門するにあたり「プログラマのためのDocker教科書第2版より」を読んだ。 Dockerfileを書いてコンテナを走らせるための自分向けのまとめをチートシート的に書き記す。

Dockerfileの命令

命令一覧

FROM .. ベースイメージの指定
RUN .. コマンド実行
CMD .. コンテナの実行コマンド
LABEL .. ラベルを設定
EXPOSE .. ポートのエクスポート
ENV .. 環境変数
ADD .. ファイル/ディレクトリの追加
COPY .. ファイルのコピー
ENTRYPOINT .. コンテナの実行コマンド
VOLUME .. ボリュームのマウント
USER .. ユーザの指定
WORKDIR .. 作業ディレクトリ
ARG .. Dockerfile内の変数
ONBUILD .. ビルド完了後に実行される命令
STOPSIGNAL .. システムコールシグナルの設定
HEALTHCHECK .. コンテナのヘルスチェック
SHELL .. デフォルトシェルの設定

# コメント
命令 # コメント

FROM

FROM centos:7
# FROM [イメージ名]
# FROM [イメージ名]:[タグ名]
# FROM [イメージ名]@[ダイジェスト]

ダイジェスト

Docker Hubにアップロードする際に自動で付与されるユニークな識別子。ダイジェストを使うことでイメージを一意に指定できる。 docker image ls --digestsで確認できる

build

$ docker build -t [作成するイメージ名]:[タグ名] [Dockerfileのあるディレクトリのパス]

docker engineの状態を確認

$ docker version
$ docker tutorial
$ docker system info
$ docker system df
# disk info

nginxをdockerで動かしてみる

$ docker pull nginx
$ docker image ls
$ docker container run --name nginxserver -d -p 80:80 nginx
# open http://localhost:80/ on web browser
$ docker ps
$ docker stop nginxserver
$ docker start nginxserver

centosをpullしてみる

# p96
$ docker image pull centos:7
$ docker image ls

DCT

docker imageが改ざんされているかどうか、公開鍵(Tagging Key)を用いて検証し、改ざんがある場合そのイメージを無効化する機能。

有効化するには環境変数を付加

署名なしイメージのpull時は無効化しなければならない。

# enable
$ export DOCKER_CONTENT_TRUST=1

# disable
$ export DOCKER_CONTENT_TRUST=0

docker imageの操作

# pullしたイメージの詳細情報を確認(イメージID,作成日,dockerのversion,CPUアーキテクチャ等)
$ docker image inspect ubuntu:latest

# jsonの一部のみを取得
$ docker image inspect --format="{{ .Os }}" ubuntu:latest
$ docker image inspect --format="{{ .ContainerConfig.Image }}" ubuntu:latest

# docker image にタグ付け
$ docker image tag nginx yammerjp/nginxserver:1.0

# docker hub上のimage(この場合はnginx)を検索
$ docker search nginx 
# Option: --no-trunc .. 結果をすべて表示,  --limit n .. n件の検索結果, --filter=stars=n .. star数下限による絞り込み

$ docker image rm [--force(-f) --no-prun] yammerjp/nginxserver
# --force .. -f , --no-prune .. 中間イメージを削除しない
# yammerjp/nginxserver ... REPOSITORYではなくIMAGE IDでも良い

$ docker image prune [--all(-a) --force(-f)]
# 未使用のdocker imageを削除

docker image のpush

$ docker login -u yammerjp -p xxx
$ docker image push yammerjp/nginxserver:1.0
$ docker logout

docker container run

$ docker container run [ option ] yammerjp/nginxserver
$ docker run [ option ] yammerjp/nginxserver # containerは省略可能
$ docker run -it --name "test1" ubuntu /bin/bash
$ docker run -d -p 8080:80 nginx
$ docker run -d --dns 8.8.8.8 nginx
$ docker run -d --mac-address="92:d0:c6:0a:29:33" ubuntu
# $ docker container inspect --format="{{ .Config.MacAddress }}" [Container ID]
$docker run -id --add-host test.com:192.168.0.1 ubuntu

実行開始時オプション

--attach(-a) STDIN/STDOUT/STDERR --cidfile --detach(-d) --interactive(-i) --tty(-t)

-a .. 標準入力/標準出力/標準エラー出力にアタッチ
-d .. バックグラウンドで実行
-i .. コンテナの標準入力を開く
-t .. 端末デバイスを使う

終了時オプション

--restart .. no (再起動しない)/ on-failure (終了ステータスが0でないなら再起動)/ on-failure:4 (終了ステータスが0でないなら4回再起動/ always (常に)/ unless-stopped (直前のコンテナの状態が停止状態でなければ再起動)
--rm .. 実行後のコンテナを自動で削除(--restartオプションと排他)

ネットワークオプション

--add-host=localhost:127.0.0.1 ... コンテナの/etc/hostsにホスト名とIPアドレスを定義
--dns=8.8.8.8 ... コンテナ用のDNSサーバのIPアドレス
--expose .. 指定したレンジのポート番号を割り当てる
--mac-address=FF:FF:FF:FF:FF:FF .. コンテナのMACアドレスを指定
--net=[bridge | none | container:<name | id > | host | NETWORK] .. コンテナのネットワークを指定
--hostname(-h) .. コンテナ自信のホスト名を指定
--publish(-p) [ホストのポート番号]:[コンテナのポート番号] .. ホストとコンテナのポートマッピング
--publish-all(-P) .. ホストの任意のポートをコンテナに割り当てる

リソースオプション

--cpu-shares(-c) .. CPUの使用の配分(1024が100%)
--memory(-m) .. 使用するメモリを制限(単位はb,k,m,gのいずれか)
--volume(-v)=[ホストのディレクトリ]:[コンテナのディレクトリ] .. ディレクトリを共有

環境変数など

--env(-e)=[環境変数] .. 環境変数を設定
--envfile=[ファイル名] .. fileから環境変数を設定
--readonly=[true|false] .. コンテナのファイルシステムを読み込み専用にする
--workdir(-w)=[パス] .. コンテナの作業ディレクトリを指定する
--user(-u)=[ユーザ名] .. ユーザ名かUIDを指定する

$ docker run --cpu-shares=512 --memory=1g ubuntu
$ docker run -v /Users/yammerjp/webap:/usr/share/nginx/html nginx

docker network

$ docker network create -d bridge webap-net
$ docker container run --net=webap-net -it ubuntu

$ docker network ls
$ docker network connect [ option ] ネットワーク コンテナ
$ docker network disconnect ネットワーク コンテナ
$ docker network inspect [ option ] ネットワーク
$ docker network rm [ option ] ネットワーク

コンテナの状態確認

$ docker container ls [ --all(-a) --filter(-f) --format --last -8 --latest -l --no-trunc --quiet(-q) --size(-s) ]
# 稼働しているコンテナの状態一覧

$ docker container stats コンテナ識別子
# コンテナ稼働確認 識別子はnginxserver等 Ctrl+Cで終了

$ docker container top コンテナ識別子
# コンテナで実行中のプロセスを確認

コンテナの状態変更

$ docker container start[ --atatch(-a) --interactive(-i) ] コンテナ識別子
$ docker container stop [ -time(-t) ..コンテナの停止時間を指定する(defaultは10s) ] コンテナ識別子
$ docker container restart [ -time(-t) ..コンテナの再起動時間を指定する(defaultは10s) ] コンテナ識別子

$ docker container pause コンテナ識別子
$ docker container unpause コンテナ識別子

others

$ docker container rm [ --force(-f) .. 起動中のコンテナを強制的に削除 , --volumes(-v) .. 割り当てたボリュームを削除 ] コンテナ識別子

$ docker container attach コンテナ識別子
# 接続後、Ctrl+Cでコンテナごと終了、デタッチのみはCtrl+P -> Ctrl+Q

$ docker container exec [ --detach(-d) --interactive(-i) --tty(-t) --user(-u) ] コンテナ識別子 実行コマンド

$ docker container top

$ docker container port # 転送されているポートの確認

$ docker container cp コンテナ識別子:コンテナ内のファイルパス ホストのディレクトリパス # ファイルをコピー
# cp以後を逆にすると、逆転送も可能

$ docker container diff コンテナ識別子　
# コンテナがイメージから作成されたときとの差分 A..ファイル追加 B..ファイル削除 C..ファイル更新

$ docker container commit [オプション] コンテナ識別子 [イメージ名[:タグ名]

GitHubにsshでつなぐ

Fri, 14 Aug 2020 09:55:39 GMT

以下、過去の自分用メモの移動。

WindowsやMacでは、GitHubのIDとパスワードを安全に記憶して、HTTPS通信で勝手に使ってくれるのだが、Ubuntuではどうもよい方法がなさそうだった。

そこでHTTPSではなくSSHを使ってgithubと通信するようにして、公開鍵認証により安全を担保しようというわけだ。

鍵ペアを作る

$ cd ~/.ssh
$ ssh-keygen -t rsa -b 4096 -C "mymail@example.com"
# 鍵の名前を id_rsa_github とする
# パスワードも聞かれるので入力

$ ls -1 
id_rsa_github # 秘密鍵
id_rsa_github.pub # 公開鍵

# 作成時に既に正しく設定されていた Ubuntu20.04LTS
# $ chmod 600 id_rsa_github

GitHubに登録

GitHub > Settings > SSH Keys > Add SSH key から公開鍵を登録する

Title : PC名等 Key: 公開鍵をコピペ

Add keyを押し、その後パスワードも入力

ローカルマシン上で設定

~/.ssh/configに以下を追記

# ~/.ssh/config
Host github
  HostName github.com
  IdentityFile ~/.ssh/id_rsa_github
  User git

# ssh-agentが動作しているか確認
eval "${ssh-agent -s}"
Agent pid 32047

$ ssh-add ~/.ssh/id_rsa_github
# パスワードを入力

# 接続確認
$ ssh -T git@github.com

Lily58 Pro を Bluetooth 対応し無線化する

Thu, 13 Aug 2020 17:07:01 GMT

前回の記事で作った左右分割型の自作キーボード Lily58 Pro を Bluetooth に対応させ、無線で PC に接続できるように改造した。その作業記録。

この記事では、無線化にあたり次のことを行う。

USBからキーボードへの給電がなくなるので、別途ボタン電池用の電源基板をつなぐ
有線キーボードの制御用マイコンである Pro Micro を、Bluetooth に対応した BLE Micro Pro に交換する
BLE Micro Pro にファームウェアを書き込む

必要なもの

Lily58 Pro (遊舎工房)
Pro Micro 互換の Bluetooth-LowEnergy 対応マイコン(遊舎工房|Booth) x2
上記マイコン用ボタン電池基板 (遊舎工房|Booth) x2
上記の互換ボードを Lily58 に PCB に固定するためのコンスルー 12ピン (遊舎工房)
ボタン電池 CR1632 x4
(電池ホルダーを紛失したので) 100均に売っている金属製のコードホルダー x4
(電池ホルダーを紛失したので) 上記と基板をつなぐスズメッキ線
マイコンと電池基板をつなぐICピン長さ1ピン x4
絶縁用ビニールテープ
はんだ、はんだごて、はんだ吸い取り線、ピンセット等

手順

手順を示した公式ガイドに従って作業を進めた

1. Lily58 Pro を完成させる

Pro Microはコンスルーを使って組み立て、交換できるようにしておく

2. 電池基板の組み立て

2.1. コンデンサ, スイッチ, ダイオードの取り付け

電池基板に付属の電子部品をはんだ付けする。

はんだ付けの手順は以下の通り。Lily58 Proの部品をはんだ付けしたのと同じように行えばよい。写真はコンデンサを固定するときのものである。

まず基板のランドの片方を温めて半田をつける

先程つけた半田を溶かして部品の片方を固定する

まだ半田を流していない側の端子とランドを温めて半田をつける

コンデンサは極性がないのでどちら向きにつけてもよい。

ダイオードはコンデンサと反対の面につける。極性があるので注意。ダイオードの表面に線が入っており、線が近い方の端子がプラス。これを基板のシルク印刷(丸ポッチがある方)に合わせる。

組み立てると次のようになる。

2.2. 電池固定用ホルダーの取り付け

今回は(届いたときに内容物を確認していなかったがおそらく)この部品を紛失したため、電池が固定できそうな金属部品を探して代用した。

それがダイソーのコードホルダー。これの左右を切り落として、コの字のパーツを作り、折り曲げる。

次に、完成時に電池と基板を挟み込むように、基板の電池を固定するのと反対側の面に、金具を金具に付属の粘着テープで固定する。

そのあと、基板のホールと金具をスズメッキ線で結線する。

最後に電池を取り付けてテスターで3Vが得られることを確認したら、全体をビニールテープで絶縁する。

3. BLE Micro Pro の組み立て

BLE Micro Pro にコンスルーを取り付ける。はんだ付けの必要はないと書いてあったがなんとなく半田を流しておいた。

その後、ピンヘッダを1本だけの長さにして、電池基板を BLE Micro Pro につなげる。

最後に BLE Micro Pro を Lily58 に刺して完成。

4. ファームウェアの書き込み

事前に電池基板のスイッチを切っておいたほうがわかりやすい。 Lily58 Pro に固定した状態で左右の基板ともに、左にスイッチを倒すとOFF。

BLE Pro Micro は専用の Web Configurator という Chrome 上で動く Webアプリで書き込むのが一番簡単な方法らしい。

Chrome の設定変更 chrome://flags#enable-experimental-web-platform-features を開き Experimental Web Platform features を Enabled にする。
専用の Web Configurator にアクセスする
ナビゲーション付きでセットアップを開始する
キーボードの選択画面で Lily58 の rev1 を選ぶ Disable Mass storage Class と Use with LPME-IO のチェックは入れない
最新のブートローダー (記事執筆時は0_7_1) 選び Update
デバイスを選択する画面が出てくるので, BLE Micro Pro を PC と USBで接続する。 BLE Micro Pro(新しく増えたデバイス)を選択。筆者の環境(Macbook Air 2018 Catarina)では IOUSBHostDevice (tty.usbmodem0000000000011) と IOUSBHostDevice (cu.usbmodem0000000000011)が出現したが、後者を選ぶと書き込めた。
アプリケーション(必ずブートローダー同じバージョンのもの)を書き込む。Is Left のみにチェックが入っていること。
もう一つの BLE Micro Pro も同様に書き込む。アプリケーション書き込み時に Is Slave のみにチェックが入っていること。

5. キーマップの書き込み

専用の QMK Configurator にアクセスする。
BLE Micro Pro を PC に USB 接続した状態で、CONNECT BY SERIAL ボタンを押す。
キーボードリストから lily58/rev1 を選択する。
好みのキーマップを作成する。
KEYMAP.JSON の左側のボタンを押してキーボードに反映
そのまま試しにキーを打ってみて問題なさそうであれば、SAVE KEYMAP ボタンでキーボードに保存。
USBを抜いて、PCと BLE Micro Pro を切り離す

6. キーボードを実際に使う

左右どちらも電池基板の電源を入れると、勝手に左右がペアリングする。 PC の Bluetooth 設定ページを見ると Lily58 が出現しているので選択すると PC とのペアリングが完了し使えるようになる。

感想

公式のドキュメントと、他の分割キーボードの Bluetooth 化の記事を見ながら進めた。
電池ホルダーがないことに気づいたときは凹んだが、完成品は特に不自然なく動作させられてよかった。
QMK をビルドして書き込む方法はうまく行ってないので、また必要になる時があったら試してみることとする。
Web アプリの QMK Configurator はよくできていて、キーの長押しで動作を変えるといった機能にも対応しているのでひとまずは普通に使えている。
キーボードのペアリングはとてもスムーズだったし、ペアリング後も電源を入れるとすぐにPCとつながるのでとても快適に使うことができている。
いまのところ一日に一回くらい、キーが押しっぱなしになる(キーを押して無いのにキーコードが送信され続ける)ことがあり、キーボードの電源を一旦切ることで解決している。原因は不明。今後も継続して発生するようであれば、これの原因究明もせねばならない。

こんなところかな。

自作キーボードとはいえ、普通に問題なく使える快適なものが出来上がってとても満足だ。キーボードや無線化キットを設計したり情報をまとめたりしてくれている方々に感謝したい。

両手で1万円くらいかけてわざわざ無線化したのは理由があるのだが、それはまた別記事で紹介することとする。

追記: (2020/10/04) lily58ビルドログへのリンクを相対リンクへ修正

Lily58 を作って自作キーボードに入門した (Lily58 Pro Build Log)

Thu, 13 Aug 2020 16:55:25 GMT

毎月一回、自作キーボードが作りたくなってカートに商品を入れるまでやる。あと一歩のところで踏みとどまる。
— やんまー (@yammerjp) July 19, 2020

数ヶ月前から、自作キーボードが気になっていたのだが、ついに手を出してしまった。

自作キーボードとは

自作キーボードとは、キースイッチやキーキャップ、基板(PCB)等を購入し、自分で組み立ててキーボードを作ることである。自分の欲しいキーボードを作ることができるのが魅力。

パーツをはんだ付けしたり、マイコンにファームウェアを書き込んだり、場合によっては基板を設計したりすることでつくる。

今回は既に設計, 基板が製造済みで、組み立てキット形式になっている Lily58 Pro を作ることにした。

Lily58 Pro を選んだ理由

作る機種は、Lily 58 Proとした。

Lily58 が魅力だったのは次の点。

キーマップを自由に書き換えられること

これは Lily58 に限らず自作キーボードの殆どに言えることだと思うが、キーボードの挙動を自由に書き換えることができる。打ちづらい位置にあるキーは使用頻度の少ないキーと入れ替えたり、複数キーの同時押しで特殊な動作をさせたりすることが可能になる。

自作キーボードは極端に言うとマイコンとスイッチの集合体なので、挙動は本当に自由に決めれると言ってよい。 (実際には qmk といわれるファームウェアを使うことが一般的で、これの一部を書き換えることでカスタマイズを実現する。)

キーボード側で自由に設定できるのはとてもありがたい。もともとキーリマッパと呼ばれるソフトウェアを使って挙動を書き換えていたのだが、これは環境構築が面倒だったりする。 (Mac では Karabiner Elements、Ubuntu では xkeysnail を使っていた。) 自作キーボードであれば USB を刺すだけで済む。

キーマップを自由に書き換えられるのって嬉しいのか？と思う人、あなたは CapsLock を使っているだろうか。結構使用頻度の少ないキーだと思うのだが、そこそこ押しやすい位置にある。例えばこれを Ctrl に変えればショートカットを押しやすいし、ESC にすれば Vim が使いやすくなるし、半角/かなキーにするのも便利かもしれない。

こんな感じで一つずつ置き換えるキーを増やしていき、設定が煩雑になって自作キーボードが欲しくなった。

キー数が60個程度 (いわゆる60%キーボード)

普段使わないキーはいらないので、コンパクトなものがほしい。ただし40%等のこれ以上キー数が少ないものは不安。

既に60%の中華キーボード (RK Royal RK61) を使っているので、良い落とし所なのではと思った。

ちなみにこの RK61 は4月頃に自作キーボード (DZ60) を作ろうか迷った挙げ句「自作キーボード、まだ自分には早いかな」と思い、とりあえず60%の US 配列キーボードを買ったもの。普通に使えていたが、結局自作キーボード欲を抑えることができなかった。

kailh ロープロファイルに対応している

Lily58 Pro は kailh ロープロファイル (浅いキーストロークのスイッチの規格) に対応している。

私はノートパソコンのキーボードのような、キーストロークの浅いキーボードが割と好きで、キーストロークが深いと打ち間違いやすい気がしていた。 (RK61を使っていたときの感想。昔はメンブレンのキーボードとか普通に使っていたはずなのだが。)

作ったあとの感想になるが、このキースイッチの選択は正解で浅いキーボードは打ちやすいと感じる。

左右分割型であること

左右分割型だと肩が丸まらないので姿勢が良くなるらしい。当初は分割でなく一体型のキーボードに注目していたが、調べるうちにどうせ作るなら金額も変わらないし左右分割型にしてみるかという気分になっていった。

左右分割型にしたことで夢が広がるのだがそれはまた別の記事に書くこととする。

column-straggered であること

column-straggerd とはキー配列の種類で、列ごとに縦方向にずれたもの。

一般的なキーボードはキーが一段ごとに横方向に半分程度ずれている。(row-straggered という。) このずれはタイプライターの機械構造に起因していて、特に打ちやすくするためではないらしい。

この横方向にずれた配列が打ちづらいのはわりと感じる(右人差し指でYを打鍵するの遠すぎないか？？)ので、完全に格子状の Ortholiner ないしは column-straggerd なキーボードを求めた。

ちなみにYを右人差し指でタイプするのは遠すぎるので、左人差し指でタイプする癖がついていたのだが、分割キーボードにしたことでこの癖は矯正することになった。

購入したもの

自作キーボードの部品を買える通販サイトの代表的なものに以下のサイトがある。今回は全て遊舎工房で購入した。

購入した商品は以下の通り。

商品	数量	値段	補足
Lily58 Pro - Kailh Choc ロープロファイル用	1	14,800	大半のパーツが含まれるキット
Kailhロープロファイルスイッチ（10個） - 赤	6	2,880	キーを押したことを判定するスイッチ
Kailhロープロ刻印キーキャップ - 黒	1	3,000	キースイッチの上にかぶせるキャップ (刻印付きで100個くらい入っている)
Kailhロープロ無刻印キーキャップ1.5U 2U（1個） - 白, 1.5u	2	400	親指部分の少し長いキーキャップ
Kailhロープロ無刻印キーキャップ1U（10個） - 白	1	300	刻印が合わないところに使うキーキャップ
Kailhロープロ無刻印キーキャップ1U（10個） - 黒	1	300	刻印が合わないところに使うキーキャップ
TRRSケーブル 1m	1	300	左右をつなぐケーブル
Pro Micro （コンスルー付き） - なし	1	1000	後述の通り、キットに入っているPro Microをダメにしてしまったので追加購入

この他に Pro Micro と PC をつなぐ USB(A to microB)ケーブルも必要。(家にあるものを使った)

Lily58 は、一般にTabやCtrlなどが位置するキーも1U(アルファベットのキーと同じ大きさ)である。今回購入したキーキャップセットのキャップは合わないので、別途個別に無刻印のキーキャップをバラで買った。 (見た目を気にしたければテンキー用の1Uキーなどが余るのでそれを使ってもよさそう。)

金額は合計して消費税を足して、2.5万円しないくらい。

組み立て

組み立てには、上記の購入部品の他にはんだ、はんだごて、ピンセット、プラスドライバーが必要になる。エポキシ接着剤(100均に売ってる)、ハンダ吸い取り線もあるといい。

USB端子の補強

まずはじめに 'もげmicro' を防ぐためにエポキシ接着剤で補強する。

USBを刺す基板である Pro Micro はコネクタが折れやすいらしく、抜き差しを繰り返すとコネクタが折れてPro Microが使えなくなることがよくあるらしい。 (自作キーボード界隈ではこのことを'もげMicro'と呼ぶそう)

この対策のために今回遊舎工房で買ったキットはコンスルーというピンが入っており、はんだ付けせずにPro Microを接続できて交換がしやすいようになっている。

また、端子部分を補強するためにエポキシ接着剤をコネクタ周囲に流して固定するのが定番のようだ。私もインターネットの記事を参考にエポキシ接着剤を塗り、、、

やってしまった。コネクタ内部に接着剤が流れ込み、USBが刺さらなくなってしまった。仕方ないので追加でPro Microを一つ注文し、作業をすすめる。

Lily58 Pro キットの組み立て

以降の組み立ての過程はキーボード設計者のゆーちさんが書いたビルドガイドに書かれている。これをよく読んで作れば問題ない。

私はキースイッチ受けとダイオードを逆の面につけてしまい一度ハンダを取り除いて再度つけるなどした。

あとはんだ付けに不安があれば、はんだ付け後にテスターで導通を確認するのがよい。沢山数があって面倒だが、ここでミスっているのを跡で治すほうが大変なのでチェックしておくことをおすすめする。私はキースイッチ受けの導通をチェックしておらず、完成後に2つ半田をつけ直した。

組み立て中の写真を取るのを忘れたが、数時間で組み上がったと思う。

ファームウェアの書き込み

デフォルトのファームウェアを書き込む

次の手順でファームウェアを書き込む。

# Ubuntu 20.04 LTS
$ git clone git@github.com:qmk/qmk_firmware.git
$ cd qmk_firmware
$ make git-submodule
$ ./util/qmk_install.sh # 必要なパッケージをインストール 時間がかかる
$ sudo make lily58:default:avrdude
# 次のような表示が出てきたら, キーボードのリセットボタンを押す
# Detecting USB port, reset your controller now...
# 同様の手順で左右のマイコンに同じファームウェアを書き込む
# 左手のUSBコネクタにケーブルを, 左右のTPRS端子に4極ケーブルを刺す

ファームウェアのカスタマイズ

次の手順でファームウェアを書き込む。

# yammerjp と名付けた自分用キーマップを作る

$ cp -r keyboards/lily58/keymaps/default keyboards/lily58/keymaps/yammerjp
$ vim keyboards/lily58/keymaps/yammerjp/keymap.c
# キーマップを書き換える

$ sudo make lily58:yammerjp:avrdude
# 次のような表示が出てきたら, キーボードのリセットボタンを押す
# Detecting USB port, reset your controller now...
# 同様の手順で左右のマイコンに同じファームウェアを書き込む
# 左手のUSBコネクタにケーブルを, 左右のTPRS端子に4極ケーブルを刺す

私が現在設定しているキーマップは次の通り。

記事の前半で60%のキーボードが良いと言っておきながら、ホームポジションから離れた上段1列は無効化している(2020/08/05現在)。まだ慣れていないので使いやすいかどうかはまだ不明だが、慣れたら便利そうな気がしている。

まとめ

組み立てるのも結構楽しいし、キーボードが左右で割れているのは新鮮だし、作って良かった。キーマップについてはまだまだ慣れていないし、使いながら改良していきたい。

2021/01/06 必要なパッケージのインストール手順を追記

Ubuntu20.04でトラックボールのボールを転がしてスクロールする

Thu, 13 Aug 2020 16:20:09 GMT

最近、Logicool のトラックボール M570 を購入した。このトラックボールはスクロールホイールがついているが、左右にスクロールする機能はない。

そこで、ボールを転がして上下左右にスクロールを可能にする。

今回は Ubuntu 20.04 をターゲットに設定を行う。 (macOS では、Karabiner Elements と Scroll Reverser というソフト (どちらも brew cask にあり) を使い実現した。詳細は省略)

デバイス名を調べる

$ xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Logitech M570                           	id=9	[slave  pointer  (2)]
⎜   ↳ Lily58 Consumer Control                 	id=11	[slave  pointer  (2)]
⎜   ↳ Lily58 Mouse                            	id=13	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Power Button                            	id=8	[slave  keyboard (3)]
    ↳ Lily58 Keyboard                         	id=10	[slave  keyboard (3)]
    ↳ Lily58 Consumer Control                 	id=12	[slave  keyboard (3)]
    ↳ Lily58 System Control                   	id=14	[slave  keyboard (3)]
    ↳ WI-C300 (AVRCP)                         	id=15	[slave  keyboard (3)]

以上より、デバイス名はLogitech M570、デバイスIDは9。のちの設定ファイルでデバイス名を利用する。

ボタン番号を調べる

以下のコマンドでIDが9のデバイスの状態をみることができる。

今回はマウスのスクロールホイールを押し込むボタンの番号を知るために、スクロールホイールを押し込みながら以下のコマンドを実行する。

$ xinput query-state 9

実行結果より、 M570 のスクロールホイールを押し込むボタンの番号は3であることがわかった。

設定を記入する

root権限で /usr/share/X11/xorg.conf.d/40-libinput.conf に以下を追記する。

# /usr/share/X11/xorg.conf.d/40-libinput.conf
# Logitech M570 Scrolling with pressed the right button and rolled the ball
Section "InputClass"
  Identifier "Logitech M570"
  MatchProduct "Logitech M570"
  Driver "libinput"
  Option "ScrollMethod" "button"
  Option "ScrollMethod" "3"
EndSection

再起動するとスクロールホイール押下時にボールによるスクロールが有効化される。

参考

常用Ubuntu 18.04 LTSのセットアップ - yu1.dev

自作コンパイラのfor文バグ

Wed, 08 Jul 2020 17:09:03 GMT

C言語のコンパイラを自作に関する今日の日記。

これまでの記事

今日実装したのは次の2つ。

構造体のアライメント
for文バグの修正

ちなみに昨日はastをjsonで吐くコード(git反映前に間違えて切り取って飛ばしてしまい頑張って再実装したが、翌日セルフホスト向けにはバグっていることがわかりお蔵入り)、セルフホスト用のシェルスクリプトなどを実装していた。

構造体のアライメント

willani での今日行ったアライメントの実装はこのあたり。実装内容は前回の記事(C言語の構造体メンバのアライメント (x86_64, Linux (System V ABI)))で説明している。

セルフホストをしようとしているがうまくいかないファイルが結構ある。構造体のアライメントを実装するきっかけは色々なファイルを第一世代コンパイラに流しているときに出てきた問題からである。

トークナイズ結果をファイルに出力する src/tokenize_log.c というファイルを willani でビルドしてリンクすると、コンパイラは動くがトークナイズ結果のうち構造体アクセスしている部分だけ出力がなかった。ここから構造体のアライメントが必要なことと実装していないことに気づいた。

本当は配列も 16byte 境界でアライメントしなければならなかった気がするが、こちらはまだ未実装。 Union もアライメントしなきゃいけないが、こちらはそもそも Union を未実装。グローバル変数もアライメントしなきゃいけないが、これもまだ実装していない。

for文バグの修正

今日はこのアライメントと、いわゆるfor文バグ (と私が呼んでいるもの) の修正をやった。

ここ最近セルフホストに向けて、gccでコンパイルしたアセンブリに一部 willani でコンパイラしたアセンブリを混ぜてリンクして第1.5世代コンパイラを作っている。その中で src/type.c というファイルを willani でビルドしてリンクしたときの話。

バグの詳細は記事最後に記す。時系列に説明しているので長くなってしまった。

どうもセルフホストに近づいてコンパイラ自身のコードをビルドし始めるとどこで何がバグっているのかわからなくなってくる。

普通のプログラムでは、入力が誤っているか、入力を受け取るコードが誤っているかを考えればいいが、セルフホストを目指すコンパイラではさらに、入力を受けとるコードを生成するコードが誤っている可能性も考慮しなければならない。

例えばあとで記す「バグの詳細」に出てくる構造体は、入力文字列で表記されている構造体と、入力文字列を処理するプログラムのデータ構造としての構造体、そしてそのプログラムを生成するときのデータ構造としての構造体があって、いま考えている構造体はなんなんだ？という気持ちになる。

とにかくバグトラックが大変で、些細なことで1日が溶けた。

今回のsrc/type.cではあまりなかったが、segmentation falut で終了することもよくあるし、デバッグが結構大変。

パース結果のログは、パースが完全に終わってからASTをたどって出力しているので、パース中に死ぬとどんな状況かつかめないことが多々ある。なのでパース中のデバッグを楽にするためのログ出力などは強化していきたい。

大変とは書いたが、ゆっくりだが着実にセルフホストに近づいているし、なにより自分の書いたコードで自分の書いたコードをコンパイルする状況はなんともいえないワクワク感があるので楽しい。

明日以降も楽しみながら進めていきたい。

補足: タイトルについて

今日見つけたバグは、私がfor文バグと呼んでいて、実際for文の実装にバグがあったが、内容はささいな話で、結構実装依存な内容である。

なのでfor文の実装に他の人もハマりがちな落とし穴があるという意味はなく、タイトルはあくまで自分の記憶のためのもの。

バグの詳細

どうもこの第1.5世代コンパイラは、構造体のメンバを読む処理がバグっていて、定義済みのメンバを呼び出すコードを解釈する際に、同名のメンバが定義されていないとしてエラーを出力していた。

構造体を含まないコードは問題なくコンパイルできるので、構造体のメンバを読むあたりが明らかに怪しい。しかしどうやってバグっているのか全く検討がつかなかった。

まず疑ったのは、入力のコードの構造体を読み込むときに構造体のアライメントが狂っていて読み込みに失敗しているのではないかということ。実は多分ここでもバグっていて、まずは冒頭のような構造体のアライメントを実装した。これにより、構造体の情報を willani 内部で保持する構造体 (Member 構造体) の各メンバに、コンパイラ内で正しくアクセスできるようになった。

しかしエラーは消えず、ほかにどこがバグっているのかよくわからない。 (自作コンパイラでは、エラーメッセージは往々にして自分が書いたものが出力されるので、なんともいえない気持ちになる。)

ひとまず関係のある Member 構造体の生成・格納・検索などのコードに片っ端に fprintf を挿入し、変数の値やポインタの指すメモリ番地などをダンプすることとした。

ダンプしたことでエラー発生の直前までうまく値がわたっていることはわかった。何故か (for 文をつかった) メンバ名の検索だけがうまくいっていない。

色々試したうえで、たまたま for 文を while 文に書き換えると嘘のように正しく動作して解決した。

あとで調べると、for 文の初期化処理がうまくいってなかったようだ。 for 文を表す node は、初期化文を表す node を init メンバとして持っている。 init メンバはふつう1文を表す1つの node で、next メンバに値が入ることはないとして実装されていた。

しかし、init メンバが変数の宣言と初期化を行う文の node で、かつ初期化子が実行時に定まるとき(例えば int a=p;)バグる。 int a=1; のような文は、willani では1つの Node 構造体 (Node.kind = ND_STMT_VAR_INIT) で表される。この構造体には初期化の値も含まれており、初期化の値が即値(コンパイル時に定まる値(数字か文字列))なら1つの構造体で完結する。一方初期化の値は実行時に定まる場合もある。このときは Node 構造体の next メンバで別の Node 構造体を数珠つなぎに持ち、これらが初期化用の式文をそれぞれあらわすようになっている。

src/codegen.c の実装バグで、for 文の init メンバの next メンバが指すノードを出力していなかったことで、構造体のメンバを表す変数のアドレスを初期価値として渡すコードがコンパイル時に含まれていなかったらしい。

わかってしまえば数行で解決できるバグだった。 (コミット)

C言語の構造体メンバのアライメント (x86_64, Linux (System V ABI))

Wed, 08 Jul 2020 15:59:59 GMT

System V ABI における構造体メンバのアライメントの方法を記す。

C言語のコンパイラを自作しているときに学んだことの記録で、これまでの記事「数日前からCコンパイラを書き始めた。」「自作Cコンパイラの途中経過」「自作コンパイラのセルフホストに挑戦中」に続く記事である。

System V ABI とは？

ABI (Application Binary Interface) とは、バイナリレベルでのコンパイラが満たすべき規約である。アーキテクチャやOSごとに決まっており、例えば我々が一般的に使うintelのCPUである x86_64 でいえば、 Windows は Microsoft ABI, Linux と macOS は System V ABIという規約で定められている。

具体的には次のようなものが決められている。

int long 等の型のサイズ
構造体のメモリ上での配置
関数呼び出し時のスタック, レジスタの扱い

ABIはなんのためにあるのか？それは異なるコンパイラ間でビルドしたバイナリをリンクできるようにするためである。

現在、一般に libc などのライブラリはバイナリに含まれず、事前に別にビルドされたものを実行時にダイナミックリンクして呼び出している。このような状況下では、異なるコンパイラでビルドされたバイナリ同士が相互に関数を呼び出すことが考えられる。

(大きなライブラリは個別のアプリケーション開発時にビルドするのは手間だし、libcなどは様々なバイナリで使われるので、バイナリに含ませないことで共通化して容量を削減させたい。)

int や long といったデータ型は C言語の仕様ではサイズが定められていない。long のサイズが int 以上である、といったことは決まっているが、別に 4byteでなくてもよい。 (16bit CPU では 2byte だったりする。) データ型はアーキテクチャに依存することが多い？と思われる。

他にも関数呼び出し時に引数や戻り値をどのように渡せばよいかを考えると ABI の必要性がみえてくる。引数はレジスタに入れることも考えられるし、スタックに積むことも考えられる。C言語の仕様では引数や戻り値という概念は存在するが、具体的にどう実装するかは定められていない。そこであるコンパイラではレジスタ渡しをするかもしれないし、あるコンパイラではスタック渡しをするかもしれない。どちらも使うコンパイラもあるかも知れないし、コンパイラの作りようはいくらでもある。

しかしコンパイラが自由に作ってしまうと、他のバイナリから呼ぶときに困る。他のコンパイラでビルドしたバイナリは引数をレジスタに詰めて渡したつもりになっていたが、受け取る側はスタックを読みだすかもしれない。

このようなアーキテクチャやOSによって共通なC言語をバイナリレベルでコンパイラがどう実装するか決めておいたほうがよいことがABIで定められている。

アライメントとは？

スタックに領域を確保するとき、空いている部分にピッタリ詰めるのではなく、ある程度キリの良いメモリ配置になるように、使っていない無駄な領域(パディング)を用意してメモリ番地を揃えることをアライメントという。

C言語のアライメントはABIによって定められている。

アライメントは構造体に求められる。ローカル変数同士はどう配置されていようと関係なく、それを読み出すのは自身のバイナリであるから問題ない。

System V ABIでは、各データ型のサイズとアライメントすべき単位のサイズがそれぞれ同じバイト数になっている。 (仕様書 12ページ Figure 3.1 Scalar Types)

本題: System V ABI における構造体メンバのアライメント

仕様書の記述

仕様書には構造体メンバのアライメントについて次のような記述がある。 (仕様書 13ページ中段 Aggregates and Unions)

Structures and unions assume the alignment of their most strictly aligned component. Each member is assigned to the lowest available offset with the appropriate alignment. The size of any object is always a multiple of the object‘s alignment.

any object と the object が何を指しているのか最初イマイチわかっていなかったが、他の日本語の解説なども読んだ結果、次を意味するらしい。

構造体の各メンバは, それぞれの要素ごとに厳密にアライメントされる。( => 利用可能なオフセットの中で最も低いもの(パディングが小さいもの)に配置される。)
構造体末尾のパディングは, 構造体の要素のアライメント単位の中で最大の値でアライメントされるように付加する。

例

次のような構造体を考える

struct hoge {
  char a;
  char b;
  int c;
  short d;
};

以上の構造体の実体は、次のようにアライメントされる

メモリ番地	内容
0x....00	char a
0x....ff	char b
0x....fe	padding
0x....fd	padding
0x....fc	int c
0x....fb	int c
0x....fa	int c
0x....f9	int c
0x....f8	short d
0x....f7	short d
0x....f6	padding
0x....f5	padding

まず、定義されたメンバと同じ順で配置される。

char a は先頭なので何も考えずに配置する。
char b を配置するために、必要ならパディングをしてメモリをアライメントする。 char のアライメントすべきメモリ境界の単位は 1byte (すなわちどこでも良い) なのでパディングの必要がない (既にアライメントされているともいえる)
char b をアラインされた場所 (今回は char a のすぐ後ろ) に配置する。
int c を配置するために、必要ならパディングをしたメモリをアライメントする。 int のアライメントすべきメモリ境界は4byteであるが、番地 0x...fe はこれを満たしていないので、2byte パディングしてメモリをアライメントする。
int c をアラインされた場所 (今回は 2byte のパディングの後ろ) に配置する。
short d を配置するために、必要ならパディングをしてメモリをアライメントする。 short のアライメントすべきメモリ境界の単位は 2byte で、今回はこれを満たしているのでパディングの必要がない (既にアライメントされているともいえる)
short d をアラインされた場所 (今回は int d のすぐ後ろ) に配置する。
struct hoge 自体の終わりにパディングをする。アライメントすべきメモリ境界は、メンバのアライメントすべきメモリ境界 (char...1byte, int...4byte, short...2byte) のうち最も大きい値である int...4byte に合わせるようにパディングするよって 2byte のパディングを追加

以上。

ちなみに sizeof(struct hoge) の値は 12 となる。

参考: データ構造アライメント - Wikipedia ... 日本語のわかりやすい解説。

何故アライメントするのか

アクセスが速くなるとか？？。。。

(2021/08/09) アクセスが早くなるかららしい。また、(今回はx86_64に限定しているが) CPUのアーキテクチャによってはアライメントを強制する場合もあるらしい。

メモリのアライメントに関する面白い動画に出会った: 自作OSを拡張する作業配信 (2021/07/24 低レイヤガール - Youtube 動画後半 1:14:02 ごろからメモリのアライメントに関する話がされている。

自作コンパイラのセルフホストに挑戦中

Mon, 06 Jul 2020 16:54:10 GMT

以前の記事「数日前からCコンパイラを書き始めた。」「自作Cコンパイラの途中経過」に続く記事。

これは日記であって、知見が書かれた文章ではない。

経過報告

気づけば2020年も半分が終わり、梅雨に入って雨が続き、今日もジメジメと蒸し暑い。大学の研究室は相変わらずリモートで、新型コロナウィルスの東京都の感染者数も100人を超える日が続き、収束の気配がない。

世間は春から夏へ季節が変わろうとしているし、世界的にウィルスとの戦いを繰り広げている昨今だが、私のやっていることは相変わらずCコンパイラ「willani」の制作。もう6週目になるだろうか。

昨日あたりからセルフホストに向けて、やっとコンパイラ本体のコードを第一世代コンパイラに流し始めた。まだ本体のコード全ての機能は実装していないため、そのあたりは置き換えるシェルスクリプトを書いて、一旦スクリプトを挟んでからコンパイルする。 (#include, 可変長引数定義, 構造体の初期化などが未実装)

プリプロセスは#defineだけ実装した。プリプロセッサの大枠はできており、他のプリプロセス文も頑張れば実装できそう感はある。他にも、ちょっと頑張れば追加できそうな機能がいくつかあるが、一旦機能追加よりもセルフホストに軸をおくことにした。

20以上のファイルに分割しているので、ファイル単位で置き換えていく。一つのオブジェクトファイルをを第一世代コンパイラで出力したものに置き換える。問題なければ次のファイルを第一世代コンパイラで出力したものに置き換える。問題なければ、、、と繰り返し作業を進める。

よくわからなかったこと

親コンパイラと第一世代コンパイラでコンパイルしたものを混ぜてgccに投げると、うまく静的リンクできない。 PIEがどうこう、.textセクションやdataセクションは動的リンクでは使えないぞ、などと怒られる。

$gcc -static -o willani *.c *.s # *.sはwillaniでコンパイルしたアセンブリ

解決策として、コンパイルと、アセンブル&リンクを分けて行った。親コンパイラの出力も一旦、個々のアセンブリファイルとして出力する。 $gcc hoge.c -S -o hoge.sのように。

これらを第一世代コンパイラで出力したアセンブリと混ぜてリンクしてもらう。リンクはlibcが必要である。 gccコマンド($gcc *.s -static -o willani)で行った。 ($ldを使ってlibcを含んで静的リンクするのってどうやるの?未調査。)

アセンブルとリンクは分けなくても問題なかった。 ($as hoge.s -o hoge.oとアセンブルを別途行ってもいいが、gccにアセンブリを投げたらいい感じにリンクまで終わらせてくれる。)

第二世代コンパイラのデバッグがつらそう

構造体のメモリ配置がABIに従ってなさそうで、今第1.5世代コンパイラ¹がバグっている。第一世代コンパイラはテストに通るのに第二世代コンパイラ(1.5世代含む)はバグっている状況は、どこから手をつけていいかわからずに混乱した。今後も前途多難だな。。

技術メモ:gccでデバッグ情報のないアセンブリを出力する

今さっき知ったtips

$gcc sample.c -S -o sample-sのようにコンパイルすると、デバッグ情報が含まれる。(-gオプションとは違い、最低限。) 例えば.cfi_startprocなどの行が出力に含まれて、人間が読むときには邪魔。

そこで、***-fno-asynchronous-unwind-tables***オプションが有効。

$gcc sample.c -fno-asynchronous-unwind-tables -S -static -o sample.sのようにオプションを追加すると無駄な行が出力されないので読みやすくなる。

Cの仕様を調べるとき、gccの出力と見比べたりするのが結構役に立つので、見やすいアセンブリを出せて助かる。(車輪の再発明だからできることだが。)

コンパイラをつくっていて良いこと

車輪の再発明あるあるではあるが、ブラックボックスを一つ紐解けた。²

作る前はコンパイラはよくわからないがよしなにやってくれるもので、アセンブリはとっつきづらいもので、オブジェクトファイルってあるよな程度の理解だった。概念としてコンパイル、アセンブル、リンクは知っていたが、実装レベルで知れるのは良い。コンパイラは要するに文字列変換プログラムだし、アセンブリはただのテキストデータだし、(リンクはそこそこ大変そうで学ぶべきことがたくさんありそうだけど)、何やってるかは以前より想像がつくようになった。

これからやること

構造体のメモリ配置を System V ABI に準拠させる
構造体の初期化文
セルフホスト
#include
#ifndef #ifdef #if #end

第1.5世代コンパイラ ... 親コンパイラ(gcc)の出力と第一世代コンパイラの出力を混ぜてアセンブル、リンクして作ったコンパイラを指す。 ↩
ブラックボックスを紐解く ... 過去にPDFファイルを自分で作ったり、正規表現エンジン(作りかけ)を作ったり、認証認可の仕組みを作ったときも同じ気持ちになった。今後、OS(途中で止まってる)やHTTPサーバ、インタプリタ(やJITコンパイラ)なんかも生きてるうちに取り組みたい。 ↩

Mares Puck Pro 電池交換の手順(2020年7月)

Wed, 01 Jul 2020 14:40:07 GMT

(2024/09/22)さてさて、このブログのドメインは「memo.yammer.jp」としていて自分のメモ書きのために用意した場所で、それをブログという体裁で公開しています。ただし大した量のないメモや書き途中の文章がどうにもブログの下書きとしてたまってしまい、かつあとで自分で見返すときに下書きにあると見つけづらくて困るという問題があるので、ここから何本か下書きのものを最低限の体裁だけ整えて、公開しているリポジトリに写していきます。

ふだんダイビングでMaresのPuck Proというダイビングコンピュータを使っている。これはボタンが一つだけでシンプルな操作感と、大きな画面でとても見やすく気に入っている。

一般的なボタン電池が使われていて、交換キットが売っているので自分で電池交換できるのも特徴。過去に2回くらい電池交換した気がしていて、おそらく最初に電池交換した2020/07/01ごろのメモが残っていたので、忘れないようにブログに残しておく。

なおこの方法は私がこうやったというだけで、同じ方法でやってトラブルが起きても自己責任でお願いします。¹

電池交換に必要なもの

交換用電池(CR2450)
交換用Oリング
グリス
綿棒
ティッシュ
10円玉などの硬貨

交換の手順

硬貨を使い、裏蓋を回して開ける
電池を取り出し、新しいものに交換
古いOリングを取り外す
Oリングがハマっていたところに付着した古いグリスを綿棒で拭き取る
新しいOリングにグリスを塗る。米粒の半分位の量でよい。清潔な手の指先にグリスを出し、指でグリス全体に薄く均等に広げる。
もともとハマっていたところに新しいOリングをはめる
裏蓋を閉じる

交換における注意

前提として、手を洗ってきれいな状態で、ホコリ等が少ない机の上など、ゴミが混入しづらい状況で作業しましょう。

グリスをつけたOリングによって、高圧の水中でも防水性を保っています。水圧がかかるとOリングが変形し、グリスとともに水の侵入を阻止しています。例えば髪の毛が1本挟まると防水性はゼロになります。ホコリや毛が入り込まないように、グリスをつけるとき、Oリングをはめるとき、蓋を閉めるときはよく見て丁寧に作業しましょう。

もしOリングを再利用するときは、取り出したOリングからティッシュなどで古いグリスを拭い、表面に傷がないことを確認し、新しいグリスを塗り拡げます。自己責任ですが、私は目視でキズがついていないことを確認して一度再利用しましたが、特に問題は起きていないです。

ダイビング器材は命を預ける側面もあるので一応免責を書いています。そもそもダイコンが壊れたら死ぬようなシチュエーションはあまり思い浮かばない (中断して帰ればいい) し、そんなギリギリのダイビングをレジャーですべきではないと思いますが。 ↩

はてなブログに乗り換えた

Sun, 14 Jun 2020 12:26:00 GMT

昨年に作ったブログの公開場所をはてなブログに変え、名前も「やんまーのブログ」と改名した。

以前は Firebase Hosting 上に、 Nuxt.js の Generate モードで生成した HTML ファイルを公開していた。

移行するにあたって次のことを行った。

はてなブログCLI gimonfu による記事管理
Zeit Nowを使った旧ドメインの転送処理

1. gimonfu による記事管理

はてなブログは Markdown で記事を作成でき、これが乗り換える後押しになった。

Markdown の記事は、以前のブログでも GitHub 上で記事を管理していたので、今回も同じことを行いたいと思っていた。

そこではてなブログの CLI を作り、GitHub上のリポジトリと同期するようにした。
はてなブログはAPIを公開しており、これを使って Markdown ファイルをアップロード、ダウンロードしている。

はてなブログの CLI には、既に blogsync というソフトウェアがある。
当初はこのソフトウェアを使おうと思っていたのだが、新規記事投稿の部分が自分の思うように行かず、APIを触っているうちに、全部作ったほうがいいのでは？という気持ちになり CLI が出来上がってしまった。

blogsync と gimonfu はどちらも1記事につき、1ファイルで、ファイル先頭に YAML Front matter といわれる YAML 形式の記事情報を含む。またURLの構造が記事ファイルのディレクトリ構造となる点も同じだ。

一方で、記事の投稿に関しては異なる点がある。
blogsync では、記事本文のみを標準入力で CLI に渡すが、 gimonfu では、対象ディレクトリ内にある新しいファイルを新規記事として認識し投稿する。

こうすると、CIを組み合わせれば、新規投稿時にも CLI を直接触らずに運用できる。

現にこのブログも、新規投稿時にファイルを追加して GitHub に push すれば、自動的にはてなブログも更新されるようにしてある。 (逆にはてなブログが更新されたらGitHub にも反映されるワークフローも設定している。)

gimonfu の使い方の詳細は README に譲るが、このブログのワークフローと同じものを GitHub Actions に指定すれば、記事管理がとても捗ると思うので是非活用して欲しい。

2. Zeit now を使った旧ドメインの転送処理

旧ドメインの記事を公開していた URL は全て、express.js を使って、今の記事に 301 リダイレクトするように設定した。(設定した内容)

Now を初めて使ったが、とても簡単にアプリケーションを公開できるので、さくっと作ったときなどに活用していきたい。

というわけで、これからはてなブログで更新していきます。よろしくお願いします。(誰に)

追記: (2020/10/04) ドメイン転送の記事へのリンクを相対リンクに修正

gimonfu で、はてなブログの記事を GitHub と同期する

Sun, 14 Jun 2020 12:23:06 GMT

ブログをはてなブログに移行するにあたり、記事を管理する CLI 「gimonfu」を作成した。

本記事では、gimonfu と GitHub Actions を使って、GitHub のリポジトリとはてなブログを連携し、記事を git で管理できるように設定を行う。

記事の内容を設定すれば、Markdown ファイルを GitHub のリポジトリにプッシュするとはてなブログに記事を公開できたり、はてなの Web ページで記事を編集すると、GitHub のリポジトリに自動で反映されてバックアップを取ることができる。

最終的な GitHub Actions の設定は、私のブログの記事リポジトリにある yaml にて確認できる。

はてなブログの記事執筆設定を Markdown モードにする
はてなブログの API キーを確認する
GitHub リポジトリを作り、ワークフローに使う Secrets を登録する
記事をダウンロードするワークフローを追加する
記事をダウンロードするワークフローを定期実行させる
記事をアップロードするワークフローを追加する

1. はてなブログの記事執筆設定を Markdown モードにする

はじめに、はてなブログの設定を変更し、記事執筆設定を Markdown モードにする。

はてなブログの設定ページから、設定 -> 編集モードを「Markdownモード」に設定し「変更する」ボタンを押す

まずはてなブログの基本設定を開く。

下へスクロールし、編集モードを Markdown モードにする。

「変更する」ボタンを押して変更を反映する。

(補足: 他のモードでも動作確認はしていないので、もし Markdown 記法以外を利用する場合はご自身で試して欲しい。

2. はてなブログの API キーを確認する

はてなブログの設定ページから、設定 -> 詳細設定に移動し、ユーザID, ブログID, API キーをメモする

まずはてなブログの詳細設定を開く。

下へスクロールし、AtomPubの項目から、ユーザID, ブログID, APIキーを確認する。

3. GitHub リポジトリを作り、ワークフローに使う Secrets を登録する

ワークフローとは、GitHub Actions で実行する一連の内容を記したものである。指定した時間になったときや、GitHub にコミットをプッシュしたとき、事前に作成したワークフローを自動で実行できる。

この章では、GitHub で新しいリポジトリを作り、ワークフローで使う Secrets を登録する。

まずは、新しいリポジトリを作った後、Settings -> Secrets を開く

ワークフローで使う Name と Value の組み合わせを5組登録する

登録する内容は次の通り。例を参考に自分の文字列に置き換えてほしいj

Name	Value	Value (例)
`HATENA_USER`	先程確認したはてなブログのユーザID	basd4g
`HATENA_BLOG_ID`	先程確認したはてなブログのブログID	basd4g.hatenablog.com
`HATENA_API_KEY`	先程確認したはてなブログのAPIキー	abcdef0123
`GIT_NAME`	(ワークフローで自動的に作られるコミットの)自分の名前	Taro Yamada
`GIT_MAIL`	(ワークフローで自動的に作られるコミットの)自分のメールアドレス	basd4g@example.com

4. 記事をダウンロードするワークフローを追加する

記事をダウンロードする GitHub Actions ワークフローを追加する。

ワークフローは GitHub リポジトリのWebページ上からも追加できる。

.github/workflows/pull.yaml に次の内容を記述する

# .github/workflows/pull.yaml
name: Pull

on:
  push:
    branches: [ master ]

jobs:
  pull:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Deploy and Commit
      env:
        HATENA_USER_ID: ${{ secrets.HATENA_USER }}
        HATENA_BLOG_ID: ${{ secrets.HATENA_BLOG_ID }}
        HATENA_API_KEY: ${{ secrets.HATENA_API_KEY }}
        GIT_NAME: ${{ secrets.GIT_NAME }}
        GIT_MAIL: ${{ secrets.GIT_MAIL }}
        REPO_OWNER: ${{ github.repository_owner }}
      run: |
        cd ${GITHUB_WORKSPACE}

        # コミットのためのgitの設定
        echo 'git initialize'
        git config --global user.name "${GIT_NAME}"
        git config --global user.email "${GIT_MAIL}"
        git remote set-url origin "https://${REPO_OWNER}:${GITHUB_TOKEN}@github.com/${GITHUB_REPOSITORY}.git"
        echo 'gimonfu initialize'

        # gimonfuの初期設定
        npm init -y > /dev/null 2>&1
        npm install gimonfu
        echo "{\"user_id\":\"${HATENA_USER_ID}\",\"blog_id\":\"${HATENA_BLOG_ID}\",\"api_key\":\"${HATENA_API_KEY}\"}" > .gimonfu.json

        # 新しい/更新された記事をダウンロード
        echo 'gimonfu pull'
        npx gimonfu --git-commit-date pull

        # コミットを作成する
        git add entry
        # This script will not make a commit if there are no changes.
        if ! git diff --staged --exit-code --quiet; then \
          git commit -m "Pull articles (automatic commit)" ;\
        fi

        git push origin HEAD:master

コミットが GitHub 上にプッシュされると、ワークフローが走ってリポジトリに記事が反映される。

5. 記事をダウンロードするワークフローを定期実行させる

先程は初回だったので「master ブランチにプッシュしたときにワークフローを実行する」(=>はてなブログの内容を GitHub リポジトリに反映させる)設定にした。

ここではワークフローの一部を書き換えて、1時間に一回ワークフローを実行させる。

.github/workflows/pull.yaml の内容を一部書き換える。

--- a/.github/workflows/pull.yaml
+++ b/.github/workflows/pull.yaml
@@ -1,8 +1,8 @@
 name: Pull
 
 on:
-  push:
-    branches: [ master ]
+  schedule:
+    - cron: '0 * * * *'
 
 jobs:
   pull:

6. 記事をアップロードするワークフローを追加する

.github/workflows/push.yamlに次の内容を記述してコミット、プッシュする。

# .github/workflows/push.yaml
name: Push

on:
  push:
    branches: [ master ]

jobs:
  push:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Deploy and Commit
      env:
        HATENA_USER_ID: ${{ secrets.HATENA_USER }}
        HATENA_BLOG_ID: ${{ secrets.HATENA_BLOG_ID }}
        HATENA_API_KEY: ${{ secrets.HATENA_API_KEY }}
        GIT_NAME: ${{ secrets.GIT_NAME }}
        GIT_MAIL: ${{ secrets.GIT_MAIL }}
        REPO_OWNER: ${{ github.repository_owner }}
      run: |
        cd ${GITHUB_WORKSPACE}

        # コミットのためのgitの設定
        echo 'git initialize'
        git config --global user.name "${GIT_NAME}"
        git config --global user.email "${GIT_MAIL}"
        git remote set-url origin "https://${REPO_OWNER}:${GITHUB_TOKEN}@github.com/${GITHUB_REPOSITORY}.git"

        # gimonfuの初期設定
        echo 'gimonfu initialize'
        npm init -y > /dev/null 2>&1
        npm install gimonfu
        echo "{\"user_id\":\"${HATENA_USER_ID}\",\"blog_id\":\"${HATENA_BLOG_ID}\",\"api_key\":\"${HATENA_API_KEY}\"}" > .gimonfu.json

        # 新しい/更新された記事をアップロード
        echo 'gimonfu push'
        npx gimonfu --git-commit-date push
        git add entry

        # コミットを作成する
        # This script will not make a commit if there are no changes.
        if ! git diff --staged --exit-code --quiet; then \
          git commit -m "Pull articles (automatic commit)" ;\
        fi

        git push origin HEAD:master

6. 記事の投稿と更新

以上の設定を行うと、GitHub のリポジトリとはてなブログの記事が同期できる。

GitHub 上の Markdown ファイルを上書きすると記事が更新されるし、新しい Markdown ファイルを追加すると記事が投稿される。

Markdownファイルは次のような記述で始まる。

---
title: タイトル
date: 2019-09-18T12:50:00.000Z
id: "26006613576772424"
---

記事本文が以降続く。

記事の冒頭に --- で挟んだYAML形式のメタ情報を付加する。 id: の行は新規投稿時には記述しない。投稿されると自動で付加される。

おわりに

ブログ記事を Git で管理したいというモチベーションから CLI を作るまでに至った。

GitHub Actions のワークフローを登録しておけば、ローカルに gimonfu をインストールせずに使えるが、インストールして使うこともできる。 $ npm install -g gimonfuでインストールでき、使い方は README で説明している。

ここまで読んでいただいてありがとうございました。あなたのはてなブログ生活が捗ることを願っています。

自作Cコンパイラの途中経過

Tue, 09 Jun 2020 08:00:06 GMT

Cコンパイラ自作の進捗

以前の記事に書いたとおり、C言語のコンパイラを自作している。

セルフホストには至ってないが、教科書であるオンラインブック「低レイヤを知りたい人のためのCコンパイラ作成入門」の内容が一通り実装し終わったので経過報告をする。

裏で最初は毎日記録をつけていたのだが、だんだん面倒くさくなってやめたので、コミット履歴を見ながら振り返る。

最初のコミットは19日前(5/21)なので、そろそろ三週間経ったところだ。 5/28-30の三日間以外は何かしらコミットしているので、継続的に開発できている。もっともバイトや授業に遮られることがなく、時間がたくさんあるのでできることであるが。

ここまでのマイルストーンとしては、次の機能開発があった。

分岐,繰り返し処理ができる
関数定義ができる
型情報が付加される(完全なサブセットをコンパイルできるようになる)
テストをCで書き直す

テストをCで書き直す(オンラインブックStep28) ところでバグが結構見つかって一つ一つ潰すのに時間がかかった。
でもこの頃はGDBの基本的な使い方に慣れてきて、更に当たりをつけてアセンブリを読むことができたので、最初の頃より全然楽だった。

テストファイルをCで書き直し、これを自作コンパイラでコンパイルすると10000万行(デバッグ情報含む)くらいのアセンブリになった。これくらいの規模のプログラムがうまく実行できると、人間を超えていく感じがして楽しい。

狭いスコープのローカル変数

ブロックスコープ内の変数の実装方法は自分で考えたものなのだが、結構うまくできたと思っている。

willaniには変数一つを表す構造体があり、これをつなげた2つの単方向リストがそれぞれ、グローバル変数とローカル変数を表している。

スコープのある変数を実装するには次の2つのことを考慮する必要がある。

変数を定義するときは、同じスコープの重複した変数名を許さない。
変数を呼び出すときは、同じ名前の変数のなかで、その式が属するスコープのうちもっとも狭いスコープの変数を指す。

トークン列をパースするときに次のような方法で 1. 2. を実現した。
なお、私の実装ではブロックスコープの変数はローカル変数の単方向リストに含む。

新しいスコープに入るときに、その前最後に定義されたローカル変数をのポインタをout_of_scopeとして記録する。
変数定義するときは、単方向リストを先頭(最新)からout_of_scopeの前までみて、同じ名前のものがないか調べる。
変数を定義するとき、Var.referable = trueというフラグを立てる。
スコープを出るときに、そのスコープで定義した全ての変数 (out_of_scopeより新しい定義の変数) のフラグを下げる。(falseをセットする。)
以後呼び出す変数を探すときにフラグがfalseなものをスキップさせる。

こうすることで、最新に定義した変数から順番に調べていけば、「1. その変数を定義してよいか」「2. 同名の異なる変数のうちどの変数を指しているか」がわかる。

リストには全てのローカル変数が残っているので、コード生成時に変数の領域を確保するのが簡単だし、パース時にどの変数を指し示すか解釈しておけばコード生成時は変数名の重複を考える必要がない。

今後の展望

植山類さんのコンパイラ実装である 9cc や chibicc 等のコミットログをみて、セルフホストをするためにはあと1倍くらい、完成まではさらに1倍くらいの手間がかかるのではないかと予想している。

セルフホストに必要そうな機能は次の通り。

構造体
'->'
typedef
プリプロセス
bool型
void型
enum
char literal
(file scope function)
switch
'++', '--'
'+='
'!'
'&&', '||'
'break'
'continue'
'extern'
'NULL'
(3項演算子)
(可変長引数関数の定義)

(括弧がついてるのはサボろうか迷っているもの。特定の文法を自分のコードから削除して書き換えてしまえば、その文法に対応しなくてもセルフホストできてしまう)

構造体とプリプロセスが時間かかりそうだなと見ている。

Cの仕様書をどこまで実装するかは考えものだが、セルフホストはやっぱり楽しみ。

Webのフロントエンドをはじめとする物々にも手を付けねばと思っているし、研究室の論文も読まねばと思っているので、今後はバランスも考えてやっていきたい。

追記: (2020/10/04) 以前の記事へのリンクを相対リンクに修正

Zeit Now を使って、express.jsで書かれたアプリケーションを独自ドメインで公開する

Sun, 31 May 2020 07:44:33 GMT

now という PaaS がある。

Node.js で書かれたアプリケーションを、無料で3つまでホスティングできるらしい。

heroku を無料プランで使うと、dyno の立ち上げに30秒くらいかかるので、Web サーバとしては致命的に遅い。一方 zeit はそのような待ち時間は発生しない。(どこかに、AWS Lambda を中で使っていると書いてあった気がする)

今回はシンプルな express.js のアプリケーションを now でホスティングする手順。

インストール

$ mkdir now-app
$ cd now-app
$ yarn init
$ yarn global add now
$ yarn add express
$ touch index.js
$ touch now.json

アプリケーションを作る

index.js に次のように記入

// index.js
`use strict`

const express = require('express');
const app = express();

app.get('/*', (req,res) => {
  res.send('hello, world!');
  res.end();
})

const port = process.env.PORT || 3000;
// ポート番号は上記のように環境変数から読み込むこと
app.listen(3000, () => console.log(`listening on port ${port}`));

now の設定

事前に、node.js のアプリケーションであることを指定しなければならない。

何もしないと静的ホスティングと判断され、アプリケーションのソースコードを写した Web ページがデプロイされる。

now.json に次のように記入

{
    "version": 2,
    "builds": [{ "src": "index.js", "use": "@now/node" }],
    "routes": [{ "src": "(.*)", "dest": "index.js" }]
}

npm scriptの設定

now が実行時に index.js を実行してくれるように、package.json に次の項目を追加

{
 "scripts": {
    "start": "node index.js"
  }
}

デプロイ

$ now
# 対話にしたがってメールを入れると、ログインリンクのついたメールが届くので、クリックして認証。

独自ドメイン(サブドメイン)を登録

以下、現在hogehoge-hogehoge.now.shで公開されていて、hogehoge.example.comでアクセスできるようにするときの設定。

まずは親のドメインをzeitに登録する

$ now domains add example.com

ドメインの所有者認証を行う

$ now domains verify example.com

すると、DNSに何も設定していないので失敗する。どう設定すべきか表示されるので画面に表示される通り、DNSに登録する。ついでに先にお目当てのサブドメインの CNAME も登録しておく。

name	type	value
_now	TXT	表示されたキー
hogehoge	CNAME	alias.zeit.co

再度ドメインの所有者認証を行う

$ now domains verify example.com

サブドメインのエイリアスを設定する

$ now alias https://hogehoge-hogehoge.now.sh hogehoge.example.com

おわりに

以上の手順と同様の作業で公開したリポジトリ: blog.yammer.fun - GitHub yammerjp

古いブログのURLをリダイレクトさせるために使った。

TCP と UDP

Sat, 30 May 2020 05:05:53 GMT

今日のインターネットの根幹をなすTCP/IPプロトコルスタックのうち、トランスポート層のプロトコルであるTCPとUDPについての基本的な知識を説明する。

本記事は研究室の輪講で「マスタリングTCP/IP 入門編」を読んだことがきっかけの第2回。前回はTCP/IPプロトコルスタック全体についての概要を書いた。

参考文献: マスタリングTCP/IP入門編第6章 pp219-246

トランスポートプロトコルの役割

トランスポート層の役割は主に3つある。

End-to-End の通信を実現すること。
アプリケーションプログラム間での通信を可能にすること
(TCP では) 信頼性のある通信を実現すること

これらの役割を、他層との関係とともに説明する。参考として、TCP/IPプロトコルの階層モデルを示す。

1. End-to-End の通信を実現すること。

トランスポート層は、End-to-End の通信を実現する。

トランスポート層の下位に位置するインターネット層では、IP を中心に hop-by-hopでパケットをバケツリレーのように渡し続けながら通信する。

トランスポート層はこれを隠して、ユーザが中継のルータなどを意識せず済むよう、 End-to-End で通信しているようにみせる。

2. アプリケーションプログラム間での通信を可能にすること

通信ホストは、複数のアプリケーションを用いて同時に異なる通信する。

トランスポート層ではポート番号という識別子を用いて、アプリケーション (実際にはプロセス) ごとに通信を識別し、各アプリケーションが他のアプリケーションの通信を意識せずに使えるようにする。

3. (TCP では) 信頼性のある通信を実現すること

TCP を用いると、パケットを再送することをはじめとして様々な制御を行ってくれる。これによって上位のアプリケーション層からは、特に意識せずとも信頼性のある通信を行える。

ポート番号

端末内で通信するプロセスを指定するために用いられる識別子。 IP アドレスと合わせて使われる。

ポート番号を含む次の5つが全て揃うことで通信を識別する。

宛先 IP アドレス
送信元 IP アドレス
宛先ポート番号
送信元ポート番号
トランスポートプロトコルの種類 (IP ヘッダのプロトコル番号フィールド)

ポート番号の通信例

例えば、私の PC で、次の2つのWebページを同時に閲覧することを考える。

埼玉大学の受験生向け Web ページ (http://www.saitama-u.ac.jp/entrance)
埼玉大学の在校生向け Web ページ (http://www.saitama-u.ac.jp/student)

このとき、私の PC から、埼玉大学の Web サーバへ通信が発生する。つまり同じ送信元から同じ宛先へ別々の通信が発生する。

ページ	宛先IPアドレス	宛先ポート番号	送信元IPアドレス	送信元ポート番号	プロトコル
A	153.127.197.67	80	203.0.113.1	49152	TCP
B	153.127.197.67	80	203.0.113.1	49153	TCP

ページを開く要求をしたときに、ブラウザのタブごとに(=プロセスごとに)違うポート番号を使えば、別々の通信を識別できるというわけだ。 (実際には、送信元に帰ってきたパケットがどのプロセス宛のものであるかを、OS がポート番号で識別し、プロセスに処理が渡る。)

ポート番号の割当

(0-1023) Well-known Port Number

ポート番号には事前に予約された Well-known Port Number というものがある。

上位レイヤーのプロトコルのうち一般的なものが使うポート番号を 0-1023 番に定めている。例えば HTTP は 80 番, HTTPS は 443 番, SSH は 22 番, 等。

Well-known Port Number を他の用途に用いることもできるが、混乱を避けるために避けるのが無難。

参考: Well-known Port Number の割当 - IANA

(1024-49151) その他の登録済みポート番号

Well-known Port Number 以外にも登録されたポート番号がある。ただしこちらは他の用途に使ってもそれほど問題が起きにくい。

(49152-65535) 動的割当のポート番号

前節では用途が決まったポート番号であった。これらは一般に、サーバ側のポート番号として使われる。¹ 何故なら、クライアント側からどのポートに繋げば良いのか事前に知っている必要があるからだ。例えば Web ページを見るときはふつう、Web サーバは 80 番 (HTTP) か 443 番 (HTTPS) で待ち受けていることを前提に通信を開始する。

一方クライアントは特にポート番号が定まっている必要はない。特に値が重要でない場合は、ポート番号の管理を OS に委ねることができる。このような動的な割当は 49152-65535 の範囲で割り当てられるのが一般的だ。

TCP と UDP

トランスポートプロトコルの代表的な２つのプロトコル、TCP と UDP の違いについて説明する。

TCP (Transmission Control Protocol)

TCPは次のような特徴を持つ

伝送、送信、通信を制御する
コネクション型²
信頼性のある通信をするために様々な制御を含む含む

TCPを使うと、アプリケーションは様々な制御から開放される。ただしコネクションの確立/切断にコストがかかる。よって、信頼性を要求し大容量のデータを交換する多くの通信に向くが、全ての通信に適しているわけではない。

UDP (User Datagram Protocol)

UDP は次のような特徴を持つ

複雑な制御をしない
コネクションレス型
いつでもデータを送信可能
高速に動作する

同報性が要求されたり、アプリケーションが細かい制御を行う通信はUDPで行うのが好ましい。次のような用途に用いられている。

総パケット数の少ない通信。 (DNS, SNMP)
動画や音声などのマルチメディア通信 (即時性を求める通信)
ブロードキャストやマルチキャストの通信。 (1対Nの通信)

TCP の様々な機能

TCP には信頼性を保証するために次のような機能を持つ。

コネクションの管理 ... (通信相手がいるかどうかの確認)
再送制御 ... (パケットが喪失した際に必要)
重複制御 ... (パケットが2十二届いた際に必要)
順序制御 ... (パケットの順序が入れ替わった際に必要)
フロー制御 ... (受信能力に合わせた送信を行う)
輻輳 (ふくそう) 制御 ... (ネットワークの混雑を避ける)

これらの実現のために必要な仕組みとして、次のような技術を説明する

コネクションの確立/切断
確認応答
シーケンス番号 (再送制御, 重複制御, 順序制御に用いられる)
ウィンドウ (ネットワークの効率を高め, フロー制御や輻輳制御にも用いられる概念)

コネクションの確立/切断

確認応答

シーケンス番号

ウィンドウ

まとめ

トランスポートプロトコルの役割は次の3つであった。

End-to-End の通信を実現すること。
アプリケーションプログラム間での通信を可能にすること
(TCP では) 信頼性のある通信を実現すること

2を実現するためにポート番号があり、3を実現するために様々な制御があることを紹介した。

以上。

追記: (2020/10/04) 前回記事へのリンクを相対リンクへ修正

TCP/IP ではクライアント-サーバモデルの通信が多い。 ↩
コネクションとは、二者間で専用して使用できる仮想的な回線のこと。 ↩

デスクトップLinuxでCPUの状況を確認する

Sat, 30 May 2020 02:46:49 GMT

$ cat /proc/cpuinfo
# CPUの各スレッドごとの情報を含んだファイルを表示する

$ nproc
# CPUのスレッド数(プロセッサの数)を表示する

$ top
# CPU使用率の高い順にプロセスを表示する。定期的に内容は再描画される。

参考: CPU and Linux - Youtube Satoru Takeuchi

数日前からCコンパイラを書き始めた。

Sun, 24 May 2020 16:02:52 GMT

数日前からCコンパイラを書き始めた。(GitHub)

植山類さんのオンラインブック、低レイヤを知りたい人のためのCコンパイラ作成入門を読みながら、概ね本の内容に沿って進めている。自分の書いたコンパイラで自身をコンパイルするセルフホストを目指している。

コンパイラというのはある言語で書かれたプログラムを別の言語に変換するプログラムだ。ここではC言語をアセンブリに変換するものを指している。
いきなりC言語をコンパイルするのは無理なので、徐々に複雑な入力を受け付けるように改良し、最終的にC言語を受け付けるようにする(したい)。最初は入力をそのまま出力することから始まり、四則演算ができるようになり、いまは関数呼び出しができるようになった。

本はとても丁寧に書かれていて、参考として実装も2種類ほど存在する。さらにSlackやYoutube Liveで質問ができるというとても恵まれた環境が揃っている。

実は昨年コンパイラの授業をとっていてコンパイラを少し触っていた。 cmmというCを一部切り取ったような言語と、PL0iという仮想マシン(とそのアセンブリ)に対して言語拡張をする、というようなことだった。そのときはあまり真面目に実装に凝っていなくて、課題はパスして成績がそこそこもらえるくらいはやったが、実のところコンパイラってよくわからないなという気持ちのまま終わっていた。

このままではよくないという気持ちと、あとは単純な興味(プログラムをデータとして扱うことを体験できる)もあって始めてみた。

はじめてまだ3日ほどだが、パーサについてがちょっと意外だった。手書きでパーサを書くというのは事前に聞いていたが、LL(1)でいけるらしい。

LL(1)とは構文解析法のこと、つまり、文法がどんな構造になっているかを調べる手法の一つだ。構文解析は事前にBNF記法などで規則が与えられており、その規則のどれが適用できるかを探す。授業でLR(0), LR(1), LALR(1)などを扱ったが、LL(1)はそれらよりも単純で手書きでパーサを書くのに向いているらしい。

どうも最近のコンパイラ(gccやclang)はLL1らしい。大学の授業では、「LALR1じゃないとまともにパースできない(世の中的には主流)(最近は違う場合もある)」といっていた気がして、それにしたがってLALR1の文法解析などをやった記憶があるのだが。(違ったらごめんなさい先生。)

なんだったんだあの勉強はという気持ちに少しなったが、教科書的にはああいうものなのだろう。授業ではLL1をばっさり飛ばしたのでそんなに深追いしてなかったが、やってみればなるほどという感じ。

LALR1パーサジェネレータを書くなら当時の記憶を掘り返して結構頑張らないときつそうだけど、LL1で書くのは意外といけるものだ。

そんなわけでトークナイザ(レキシカルアナライザと同義?)とパーサは結構スイスイ進む。やることが見えているしデバッグ用にログを出せば何が起きているか目に見えてわかる。

そこまではいいのだけど、肝心のコード生成がちょっと大変。

アセンブリへの理解が浅い私である。アセンブリを読むのは少しつらいなぁ、この量でこんなこと言ってたらこの先どうなることやらと思いながらデバッグしている。今後アセンブリがすらすら読めるようになることを夢見て続けていきたい。

C言語でそれなりのものを書くというのも実はいままであまりやってこなかったので、今回は絶好の機会だ。いつまで飽きずにやれるかな。

npm publishの手順

Thu, 21 May 2020 06:40:14 GMT

npm (Node Package Manager) とは、Node.js におけるパッケージ管理ツールである。

npm が GitHub に買収されたり、deno が正式リリースされたりしているこのご時世であるが、初めて npm にパッケージを公開したので手順と注意点を振り返る。

ちなみ公開したのは、はてなブログ記事管理ツールの gimonfu。

全体の流れ

$ npm publishする作業をよしなにしてくれる CLI ツール np などもあるようだ。今回は必要な作業を知る意味を込めて手動で行った。

私がやったのは以下の通り。細かくはこれから述べる。

npm に登録する
内容を確認する
package.json の version を上げる
$ npm publish
GitHub の Web ページ上で Release を書く

npmに登録する

npm に登録する (https://www.npmjs.com/signup)
npm にログインする($ npm login)
npm にログインしたことを確認する($ npm whoami)

package.json を振り返る

package.json の内容に不備がないか、各項目を確認していく。

一通り確認し終えたら fixpack を使って、抜けがないかチェックする。

version については semantic versioning に従う。要するに 0.0.1 や 1.0.2 といった形式だ。 $ npm versionでも上げることができるらしい。

( files キーについては次に述べる。)

配布するファイルを確認する

配布するファイルは次の項目で決まる。

package.json 内の files キー

文字列の配列を渡すと、ファイルやディレクトリを配布ファイルに含める。ホワイトリスト形式。

今回は次のように指定した。 TypeScriptでCLIツールを作るなら同じように指定できるのではないだろうか。

なお package.json などは自動で含めてくれるようなので指定しなくてよい。

{
  "files": [
    "dist",
    "bin"
  ],
}

.npmignore

.gitignore と同じフォーマットで、ファイルやディレクトリを配布ファイルから除外する。ブラックリスト形式。

npmのドキュメントを読むと、.npmignore だけではなく .gitignore も読み込んで除外してくれそうな感じだ。

今回は package.json#files で指定したので使わなかった。

配布するファイルは、特にTypeScriptのとき注意する必要がある。dist ディレクトリだ。

npm での配布コンパイル結果を含む必要がある。しかし git ではコンパイル結果をリポジトリに含めないのが普通だ。何も設定しないと .gitignore を解釈して dist ディレクトリは配布対象外となってしまう。

これを避けるためには、package.json#files で指定してあげる必要がある。

ところで、$npm linkを使うと手元のPCでグローバルインストールしたのと同様にpathを通してくれるらしい。

ただ、シンボリックリンクを貼るだけなので配布するファイルの確認には使えないことに注意。配布対象外のファイルもローカルに存在するので動いてしまう。

ビルドとテストが通る

動かないファイルを公開するわけにはいかない。

間違えて公開してしまっても72時間以内なら$npm unpublishで取り消せる。

それ以降はnpmのサポートにメールする必要がある。パッケージが簡単に消せてしまうと依存関係に問題が生じるので、削除には慎重なようだ。

README.mdを読み直す

README.md は npm のページにも表示されるので、改めて間違いがないかを確認する。

自分は Installation のところを間違えたまま公開してしまった。(現在は修正済み)

# 間違い
$ npm install --global yammerjp/gimonfu

# 正しい
# npm install --global gimonfu

実は npm にパッケージを公開せずとも、install 時に [githubユーザ名]/[githubレポジトリ名] とすると、パッケージをインストールできる。もともと README.md にこの方法が記述していた。

しかし今回はこの記述は間違い。 Github リポジトリには TypeScript のコンパイル結果が含まれていないので、インストールできても動かない。

ちなみに英語の README.md は、DeepL と grammaly の力を借りて適当な GitHub リポジトリの README.md を参考にすることで作っている。先人と文明は偉大。

`$ npm publish`

問題ないことが確認できたらいよいよ公開する。

$ npm publish

たった一行打つだけ。

公開したら、GitHub 上でも Release をつくる。

おわりに

はじめての$ npm publishはなんだか気分が良い。

npm のパッケージのページでは Download 数が見れるのだが、公開された瞬間に40くらいになっていた。謎。ミラーだったりで自動取得されてるのかな。

そもそも Download 数ってそんなに正確である必要はないので、40など誤差の範囲内だが。

追記: (2020/10/04) 不要な改行タグを削除

コンピュータの有名なエッセイ

Wed, 20 May 2020 05:23:23 GMT

コンピュータの専門家を志すものとして、近いうちに読んでおきたい(読み直したい)エッセイ。インターネット上に公開されているものも多く、日本語訳のリンクをつけている。

著者、訳者に感謝。

自分の今後の人生など知る由もないが、仕事になろうとそうでなかろうと、コンピューテーションが楽しいものだということを忘れずに、いや今よりもそう思えるような人間でありたい。

ハッカーと画家(Hackers & Painters)

ポール・グレアム著。

エッセイ集。

いくつかの章は読んだ。強い表現のところもあったりしてクセのある、他方魅力的な文章。

他を含むエッセイと和訳の一覧

伽藍とバザール(The Cathedral and the Bazaar)

エリック・レイモンド著。

先日、TCP/IPに関する説明を大学の先生から受けたときに聞いた本。オープンソースソフトウェアの発展に関する考察がされているようだ。

まだ読んでいない。

ハッカーになろう(How To Become A Hacker)

こちらもエリック・レイモンド著。

ハッカーとしての志、考え方が書かれている。

一度読んだ。私は全然ハッカーに近づけてはいないなと実感しながら。

プログラマが知るべき97のこと

多数のプログラマが語るエッセイ集のようだ。

まだ一部しか読めていない。

情熱プログラマー

Chad Fowler著のプログラマがキャリアを築くための方法を述べた書籍のようだ。

まだ読んでいない(買っていない)。

ゆるふわポッドキャストの@mktakuyaさんがTwitterでつぶやいて知った。

エッセイではないが、Unixという考え方 - その設計思想と哲学も改めて読み直したい。

リポジトリで振り返る2019年

Tue, 19 May 2020 12:44:57 GMT

2020年も中頃だが、2019年末〜2020年正月に書きかけた記事が出てきた。捨てるのも何なのでここに放出。

以下。年末に1年を振り返るという記事の趣旨から各リポジトリにリンクをつけた以外は原文のまま。リンク以外の追記部分はその旨を記述している。

なにをするか

あけましておめでとうございます。年越ししてしまいましたが、まだ正月なので昨年を振り返って今年に向けて身を引き締めたい。

今回はGitHubのリポジトリを総ざらいして自分がどんな開発をしたか振り返る。

準備:GitHubのリポジトリ一覧を取得する

githubのAPIを用いて、curlでリポジトリ情報を取得する。

$ curl -u yammerjp "https://api.github.com/users/yammerjp/repos?per_page=100&page=1" | grep '"name": "' | awk -F '"' '{print $4}' > repos.txt

参考: GitHubのリポジトリを一覧化する（public/private両対応）- Qiita

リポジトリ一覧 (2019/12/31現在)

私(yammerjp)のgithub上にあるpublicリポジトリは31個。まともにGitHubを使い始めてから1年ほどというのもあり、すべて2019年に1コミット以上しているので、これらを振り返る。

純粋な個人趣味開発

c-sharp-socket

友人からの質問をきっかけにC#でソケット通信をしてみた、サンプルコード的なリポジトリ。

text2pdf

textデータをPDFファイルに出力できるアプリケーション。 2019年1月に、3日間で勢いで作った。実用で使うというより、プロモーションが中心だったので、表示自体は非常に簡素。ただし、node.js上で外部のライブラリやアプリケーションを用いず、PDFのファイル形式に従ってファイルへの文字列出力部分を自分で実装している。3日間にしては頑張ったな、という感じ。

日本語出力した際のフォントまわりが貧弱で、文字列が描画される位置が微妙である。開発後半に、日本語出力をとってつけで開発したので、このあたりをしっかりすれば、もうすこし見た目が良くなるのではないかな。 PDFを開く環境による見た目の差異を検証したりすることが必要である。

もし文字データを手っ取り早くPDFにしたいのであれば、md-to-pdfがおすすめ。GitHub風CSSを当てると結構いい感じになる。

PlayQueue

Youtubeを連続再生するWebアプリケーション。 2018年末から断続的に開発している。個人開発のアプリケーションとしては自分の代表作で、就活でも自分を紹介する際に話す機会が多い。

大学の授業に関係した開発

TuringMachineOnWeb

2019年1月制作。チューリング機械の状態遷移表を作成するエディタと、作成した状態遷移表を検証するシュミレータを作った。

レポートに書く状態遷移表をつくったときに、つくった状態遷移表が正しいのかを検証するために作った。

UIは簡素だけれど、当時やりたかったことは達成させられたので満足。

clustering.AI.2019.SU

ウォード法による階層的クラスタリングを扱ったレポートを書くために使ったスクリプト。

pl0i
pl0i.js

pl0 interpreterという仮想マシンと、TypeScriptによる再実装(未完)

簡易なアセンブリと、より高級な言語との対応を学ぶために、アセンブリを実行する仮想マシンをつくることで理解を深める試みであった。

TypeScriptで書いていたときは、最終的にブラウザでメモリの状態や実行している命令の位置なども表示しながらプログラムを実行できるようなWebアプリケーションをつくるつもりだったが、大学の課題と就活を優先した結果開発が進まぬまま課題の方を先に終わらせて提出した。以後開発が停止し未完。

夏インターン

夏インターン準備

夏インターンでNuxt.jsとTypeScriptを扱うと聞いたので、その準備としてそれらの勉強のために書籍やWebサイトを参考にサンプルアプリを作って動かしてみたリポジトリ群

夏インターン

夏インターンのハッカソンで制作したWebアプリケーション。PHP製。

oshushume.20190807

夏インターン後

夏インターンで扱ったNuxt.jsを生かして何かをしようと作っていたアプリケーションとその残骸。

最終的にこのブログとして形にして動いている。 (2020/05/19補足: memo.yammer.jpではなくGreen Turtle)

このブログ(Green Turtle)のしくみは以下のようになっている。

mdファイルをgitリポジトリ(アプリケーションソースコードとは別のprivateリポジトリ)で管理している。 masterにmergeすることで記事公開。

アプリケーションリポジトリも、記事リポジトリも、masterにmergeしたときにCircle CIが走ってデプロイするようになっている。

デプロイは次のような工程で行われる

2つのリポジトリからソース、記事をclone
ソースコードのサンプル記事を破棄し、cloneした公開記事に置き換え
記事markdownをスクリプトでJSONに変換
Nuxt.jsをGenerateモードで動作させる
Nuxt.jsが記事ページを描画する際に、記事データが含まれるjsonファイルを読み込み、描画する。
Nuxt.jsにより静的なHTML,CSSファイルが生成される
Google Firebase Hostingに静的なHTML,CSSファイルをアップロード

今後の展望

トップページとaboutページが簡素なので、もう少しリッチなUIにしたい
過去記事へのリンクの経路が限られているので、記事下に「最近投稿した記事」などのリンクを置きたい。
(勉強も兼ねて)バックエンドも用意して、静的ファイルでの公開ではなく、SSRないしSPAで動作させたい。(表示速度は退化するので、完全に勉強目的)

現在はブログというには簡素な状態だが、今後の拡張性はたくさん用意しているつもりである。デプロイの手順も少々手間が混んでいるが、将来APIサーバを用意した際でも描画部分を使い回せるようにするためだったりする。やりたいことはたくさんある。

Swift ( チーム開発でのiphoneアプリ製作 )

ios-animals.enpit.2019.SU
ios-mymap.enpit.2019.SU
ios-photo-viewer.enpit.2019.SU
ios-sample-calcurator.enpit.2019.SU
ios-timer.enpit.2019.SU
PinsOfMap
~~lovelab.heroku~~(2020/05/19追記: 現在の名前はlovelab-api)
lovelab.vue

9月から、学生どうしでチームを組むiPhoneアプリケーションの開発に関わっている。

上の5つはサンプルアプリケーションの実装。6つめはそれを生かした簡単な応用の位置情報保存アプリ。

7つめは10月より開発中のメインのアプリケーションのAPIサーバ。

8つめは10月より開発中のメインのアプリケーションのプロトタイプ。フロントエンドのWebアプリケーション

(2020/05/19追記: メインのiphoneアプリケーションのリポジトリはプライベートなのでここにリンクを貼っていない。)

rails (冬インターン)

冬インターンで

以上。ここで止まっていた。ここからは2020年5月に書いている。

ちなみに冬インターンでRailsを使うものに参加したのでRailsを軽く触っていたのが最後の書きかけの項目。

今年度末は同じ内容の記事を書ききって公開したい。

非同期のまえに同期処理を通してPromiseとasync/awaitを理解する

Tue, 19 May 2020 07:50:47 GMT

JavaScript といえば非同期処理はつきものだが、非同期や Promise に苦手意識を持つ人も多いのではないだろうか。

これらの最初の理解のハードルは結構高いと思う。私も理解できずに悶絶した。C言語のポインタよりむずくないか？。。。

この記事の前半では一旦非同期のことは忘れる。まず記事前半は、同期処理をテーマに、コールバック, Promise, async/await について説明する。記事の後半は、これらを非同期処理を交えて説明する。

Promise はよくわからないという方や、一度挫折した方などにぜひ読んでもらいたい。

(2020/05/30補足: Qiita投稿に合わせて全体を修正済み。(旧版))

対象読者

JavaScript の基本的文法を知っている。(調べればわかる)
非同期処理, コールバック, Promise, async/awaitに苦手意識がある、よくわからない。

JavaScriptを1行も読んだことも書いたこともない人、プログラミングをしたことのない人は対象としない。逆に少しでも読み書きできればオーケー、のつもり。

目指すところ

同期処理と非同期処理の違いがわかる
(非同期処理を対象とした)他のPromise,async/awaitの解説記事を読んで理解が進む

Step0 準備

Step0-1 MDN

非同期処理もコールバックもPromiseもasync/awaitも関係ないが、まずMDNについて説明しておきたい。

JavaScriptでわからないことがあれば、まずは都度MDN web docsをみるとよい。

適当に検索して出てくる記事よりも、とりあえずここで確認しよう (本記事も適当に検索して出てくる記事に該当するという矛盾がはらむ)。一度理解して忘れていた記法などを確認するのにもとてもよい。

Step0-2 Chrome Developper Tool

以下JavaScirptの説明をするので、実際に動かしたくなる人もいるだろう。

PCにnode.jsが既にインストールされている人はそちらを使うのもよい。

しかし、インストールされていない人は、いちいちHTMLファイルを書いて、JavaScriptを読み込んで、、、とするのは面倒だろう。

もっと気軽にJavaScriptを試せる方法がある。 Chrome developper Toolである。

ブラウザにGoogle Chromeを使っている人はウィンドウ右上の︙ > その他のツール > デベロッパーツールを開いてみよう。画面上方の「Console」タブを開いて、文字を入力すると、JavaScriptがエンターキーを押すごとに実行されるはずだ。

Step0-3 アロー関数

ES6 (ES2015)以降の最近のJavaScriptでは、アロー関数という記法がある。アロー関数がわからない人も、この記事出てくるので簡単に抑えておきたい。

// 従来の書き方
function sum ( a, b ) {
  return a + b;
}

// アロー関数
const sum2 = ( a, b ) => {
  return a + b;
};

// アロー関数 関数の中がreturn文だけのときは、{return}を省略できる
const sum3 = ( a, b ) => a + b;

// アロー関数 引数が1つのときだけ()が省略できる (0つ、2つ以上はダメ)
const twice = a => a*2;

thisがbindされるかだとか他の違いは一旦忘れる。上のように書けるということだけわかればよい。

さて、前置きが長くなったが準備が整った。

Step1 同期処理

まずは非同期のことはわすれて、とりあえず読み進めて欲しい。

Step1-1 コールバック (同期関数)

コールバックとは、関数自体を引数として与え、別の関数に実行してもらうしくみだ。電話を折り返すことに由来して名付けられた。由来の通り、関数自体を伝えて「あとで都合が良くなったら実行しておいて」と実行を押し付ける方式。

function callbackFunc() {
  console.log('callback');
}

function callFunc ( func ) {
  func();
}

callFunc( callbackFunc );

ふつう、関数callbackFuncを実行するならcallbackFunc()のようにするだろう。しかし上記では括弧をつけずcallbackFunc を引数として渡している。

括弧をつけないことで、引数として関数自体を渡すだけでその場では実行されない。後に callFunc 関数の中で、渡された関数 (callbackFunc)を実行してもらっている。

この「関数自体を渡す」というのがコールバックの肝である。コールバックとは(戻り値の)値渡しではなく、関数自体の参照を渡しているという表現もできる。

次のような書き方では全く意味が変わってしまうので注意。

callFunc( callbackFunc() );

これでは、callbackFunc 関数を実行し、その戻り値を callFunc 関数に引数として渡すという意味になってしまう。

繰り返しになるが、コールバックは「関数自体を渡して」「あとで実行してもらう」しくみである。

参考: Callback function(コールバック関数) MDN web docs

(補足) コールバックとアロー関数

ちなみに上述のコードはアロー関数を使って次のようにも書ける。

const callbackFunc = () => {
  console.log('callback');
};

function callFunc( func ) {
  func();
}

callFunc( callbackFunc );

さらに、一度変数に入れるのをやめると

function callFunc( func ) {
  func();
}

callFunc( () => {
  console.log('callback');
})

引数を指定する中で関数を定義してしまうのだ。このように関数自体を引数で渡すとき(即ちコールバック関数を渡すとき)、アロー関数でシンプルにかける。

Step1-2 Promise (同期関数)

Promise は英語で「約束する」という意味だ。名前の通り、あとで値を返すことを約束するような動作をする。(約束を破ることもある。)

Promise の状態

Promise には3つの状態がある。

pending ... 約束している状態(初期状態)
fulfilled ... 約束を守って値を返した状態
rejected ... 約束を破った状態

Promise オブジェクトはまず pending で始まり、あとで fulfilled や rejected に状態が変化する。

状態: pending

とりあえず約束してみる。

const promise = new Promise( (resolve, reject) => {
});
// 何もしない関数を、new Promise() に渡している。
console.log( promise );

pendingと表示されただろう。

ここでの変数promiseは、Promise の状態 pending といえる。

状態: fulfilled

次は fulfilled の状態を作ってみる。

const promise = new Promise( (resolve, reject) => {
  resolve();
})
console.log( promise );
// 実はresolve,rejectはそれぞれ、渡された(コールバック)関数を引数として受け取っている。

Promise resoleved と表示されただろう。これが fulfilled である。

実は状態 fulfilled は値を持つ。

const promise = new Promise( (resolve, reject) => {
  resolve('hello');
})
console.log( promise );

ここでの変数promiseは、Promiseの状態 fulfilled であり、値'hello'を持つといえる。

状態: rejected

rejected も fulfilled と同様に値を持つ。

const promise = new Promise( (resolve, reject) => {
  reject('hello');
})
console.log( promise );

ここでの変数promiseは、Promise の状態 rejected であり、値'hello'を持つといえる。

rejected で渡される値(オブジェクト)は Error オブジェクトだったりする。

const promise = new Promise( (resolve, reject) => {
  reject(new Error('error message'));
})
console.log( promise );

ここでの変数promiseは、Promise の状態 rejected であり、値に Error オブジェクトを持つといえる。

状態の変化

Promiseでは状態が変化する。初期状態では pending であるが、のちに fulfilled や rejected になる。

const promise = new Promise( (resolve, reject) => {
  //この行が実行されるタイミングでは、変数promiseは状態pending
  if( true ){
    //この行が実行されるタイミングでも、まだ変数promiseは状態pending
    resolve('resolveされた!');
    //この行が実行されるタイミングでは、変数promiseは状態fulfilledで値'resolveされた!'を持つ
    return;
  }
  // ここから先は実行されない
  reject('rejectされた');
})

現在は同期処理を行っているので、fulfill または reject された状態に一瞬で変化してしまい、 pending の状態をみることはできない。

しかし厳密にはもともとは pending で、 resolve()を実行すると fulfilled に、 reject() を実行すると rejected に、それぞれ状態が移行する。

then/catch による Promise チェーン

さて、Promise には3状態あり、変化することがわかった。変化すると何ができるのか？それをこの節で説明する。

Promise オブジェクトのメソッドに、then と catch がある。

これらはそれぞれ第一引数に関数をとり、Promise が fulfilled や rejected の状態になると引数関数を実行する。

const promise = new Promise( (resolve, reject) => {
  resolve('hello');
})

promise.then( arg => {
  console.log(arg); // ここではhelloが表示される
  console.log('then is called');
})

const promise = new Promise( (resolve, reject) => {
  reject('hello');
})

promise.catch( arg => {
  console.log(arg); // ここではhelloが表示される
  console.log('catch is called');
})

このように.でつないで then/catch メソッドを呼べば、それらを発火できる。

さらに、then/catch メソッドの戻り値に promise を与えてやれば、更に繋げられる。

const promise = new Promise( (resolve, reject) => {
  resolve('hello');
})

promise
  .then( () => {
    console.log('then is called');
    return Promise.resolve('resolve!');
  })
  .then( arg => {
    return Promise.resolve( arg + '!' );
  })
  .then( arg => {
    console.log(arg); // resolve!! と表示される。
  })

// Promise.resolve('resolve!'); は、
// new Promise( resolve => { resolve('resolve!') }); と同じ。

上述の通り、then メソッドの戻り値に Promise を渡すと、更に後ろに.then()を繋げられる。 (.catch()も繋げられる。)

このように、Promise が解決 (fulfill/reject) されたら.then()メソッドが発火し、 .then()メソッドがPromiseを返すと、解決されたらさらに後ろの.then()メソッドが発火し、、、

このように数珠つなぎに徐々に Promise が渡ることを Promise チェーンと呼ぶ。

ここまでで Promise を学んだ。コールバックや Promise を使う理由は非同期関数にあるので、読者の皆様にはややこしいことをしているようにしか見えないかもしれない。

本当はこのあたりで非同期関数について説明し Promise のありがたみを理解していただくのもよいのだが、この記事はあくまで「まず同期関数で理解する。」ことが目的であり、非同期関数はもう少し後回しにする。

Step1-3 async/await (同期関数)

次は sync/await だ。

そのまえに説明すべきことが2つほどあるので補足。

補足: 即時関数

即時関数は定義と同時に実行する関数だ。関数定義を括弧でくくると即時実行される。

const Hello = () => { console.log('hello') };
Hello();

// 上2行のコードは、次の行のコードと同じ。
( () => { console.log('hello') });

// アロー関数でなくても良い
( function () { console.log('hello') });

補足: Async 関数 (asnyc function)

関数定義の前にasyncとつけて定義する。 Asnyc 関数の中でのみ await が使える。

// 例
const arrowFunc = async () => {
  await promise;
}
async function func() {
  await promise;
}

改めて async/await (同期関数)

閑話休題。

async/await は Promise を生成する構文と言っていい。先程の then を書かずともよくなる構文である。

前節の Promise のコードを再掲する。

const promise = new Promise( (resolve, reject) => {
  resolve('hello');
})

promise.then( arg => {
  console.log(arg) // ここではhelloが表示される
  console.log('then is called');
})

これを async/await に書き直すと

const promise = new Promise( (resolve, reject) => {
  resolve('hello');
})

(async () => {
  const arg = await promise;
  console.log(arg); // ここではhelloが表示される
  console.log('then is called');
})

このようになる。 then が消えたことがわかる。

(即時実行のasync関数を使っている。)

もう一つ前節のコードを再掲し async/await に書き換えてみる。

const promise = new Promise( (resolve, reject) => {
  resolve('hello')
})

promise
  .then( () => {
    console.log('then is called')
    return Promise.resolve('resolve!')
  })
  .then( arg => {
    return Promise.resolve( arg + '!' )
  })
  .then( arg => {
    console.log(arg) // resolve!! と表示される。
  })

async/await に書き換えると

const promise = new Promise( (resolve, reject) => {
  resolve('hello')
})

( async () => {
  let arg = await promise
  console.log('then is called')
  let arg = await Promise.resolve('resolve!')
  let arg = await Promise.resolve( arg + '!' )
  console.log(arg) // resolve!! と表示される。
})

今度は then がなくなったことで短く書けたことが伝わるのではないか。

awaitが現れると、Async 関数内のawaitより後ろの部分が全てthen()の引数として包まれる、といった見方もできる。

以上のように、async/await は Promise を簡潔に書く構文である。

余談: Promiseは必要か?

async/awaitで簡潔にかけるなら、Promiseなんて理解しなくて良いのでは？と思う方もいるだろう。しかし今の所そうも行かないのだ。

複数のPromiseを同時に待つ処理をasync/awaitで書いてみる。

( async () => {
  await Promise.all( [ promise1, promise2 ])
})

うお、Promise出てきた。。。

コードの内容はおいておいて、Promise という単語が出てきたことに注目。解説は省くが、async/await は Promise を完全には隠しきれていないのだ。

(気になる方はこの記事を読み終えてからPromise.allをみると良いだろう。

Step2 非同期処理

さてさて、ここまで来ればゴールは近い。この節では今まで苦労して覚えた謎構文 Promise と asnyc/await のありがたみがわかるようになる。

Step2-1 同期関数と非同期関数

同期関数と非同期関数について説明する。

同期関数とは、中の処理が完了するまで待ってから戻り値を返す関数のこと
非同期関数とは、中の処理にかかわらず、すぐに戻り値を返してしまう関数のこと

JavaScript の代表的な非同期関数にsetTimeOut()がある。

次のようなコードで考えてみよう。

setTimeOut( () => {
  console.log('hello');
}, 1000);
console.log('world');

JavaScript は、普通は(同期関数は)、上から順番に1行ずつ実行される。

しかし上記のコードを実行するとworldが表示された後にhelloが表示される。これはsetTimeOut()関数が非同期関数だからだ。

書き方を少し変えてみる。

function Hello() { // 1
  console.log('hello'); // 4
}
setTimeOut( Hello, 1000) // 2
console.log('world') // 3

さっきと同じ動作をするコードだ。

コンピュータの気持ちになってみると

Hello 関数を定義するよ。Hello 関数は実行されたら'hello'と表示するよ。まだ定義だけで実行しないよ。
setTimeOut 関数を実行するよ。Hello 関数を 1000ms 後に実行するとを登録するよ。登録するだけで、すぐに戻り値を返すよ。
'world'と表示するよ。

... しばらく (1000ms) 経って ...

Hello 関数を実行するよ、'hello'と表示するよ。

このような順で動作する。同期関数はその行で処理が停止するのに対し、非同期関数はすぐに次の行が実行される。

Step2-2 コールバック (非同期関数)

先程の例で非同期関数を実現してるのがコールバックだ。

あとで実行して欲しい関数を引数で伝えておいて、ときが来たら実行する。

やりたいことはコールバックで実現できるものの、何重にも重なると次のようなコードにになってしまう。

setTimeOut( () => {
  setTimeOut( () => {
    setTimeOut( () => {
      setTimeOut( () => {
        setTimeOut( () => {
          setTimeOut( () => {
            console.log('6s later');
          }, 1000);
        }, 1000);
      }, 1000);
    }, 1000);
  }, 1000);
}, 1000);

console.log('これはすぐに実行される');

コールバック関数を呼ぶたびにネストが深くなってしまい読みづらい。

俗に言うコールバック地獄である。たとえばこの例だと、どの秒数がどの setTimeOut に対応するのかわかりづらい。

(上記の例は全て一つの setTimeOut にまとめられるが) 実際には次のような状況が考えられる。

サーバと通信して、記事のリストをとってくる。
記事のリストから該当の記事を探して、再度サーバと通信して本文をとってくる。

このように、複数の非同期処理が数珠つなぎになることもあるだろう。

数珠つなぎ、、、

Step2-3 Promise (非同期関数)

そう、数珠つなぎならさっきの Promise チェーンと相性が良い。

さっきの6秒待つ処理も

// 事前に Promise 関数を作っておく。
// ライブラリなどで用意されていたりするので、Promise を使う側は作る必要はない。
function setTimeOutPromise(time){
  return new Promise( resolve => {
    setTimeOut( resolve, 1000);
  });
}

setTimeOutPromise(1000)
.then( () => 
  setTimeOutPromise(1000)
).then( () =>
  setTimeOutPromise(1000)
).then( () =>
  setTimeOutPromise(1000)
).then( () =>
  setTimeOutPromise(1000)
).then( () =>
  setTimeOutPromise(1000)
).then( () => {
  console.log('6s later');
})

console.log('これはすぐに実行される');

ネストが解消されて、引数もコンパクトになって見やすくなった。

Step2-4 asnyc/await (非同期関数)

さらに async/awaitで書き直すと

// 事前に Promise 関数を作っておく。
// さっきと同じ。
function setTimeOutPromise(time){
  return new Promise( resolve => {
    setTimeOut( resolve, 1000)
  })
}

( async () => {
  await setTimeOutPromise(1000);
  await setTimeOutPromise(1000);
  await setTimeOutPromise(1000);
  await setTimeOutPromise(1000);
  await setTimeOutPromise(1000);
  await setTimeOutPromise(1000);
  console.log('6s later');
})

console.log('これはすぐに実行される');

これは見やすい！非同期関数を同期的に書けるようになった。

await の行で停止しているかのように動作する。

さいごに

本記事を読み次の2つを知れば、他の記事が格段に読みやすくなるだろう。

同期処理と非同期処理の違い
同期処理でPromiseがどういう動作をするか

これからは「コールバック地獄を解決するために Promise チェーンがある」「 async/await は Promise の生成だ」などと書かれた他の記事も読めるのではないだろうか。

この記事を完全に理解できなくても、読者の皆様はこれから JavaScript の非同期処理を深める土台ができているのではないかと思う。

ここまでの長文に付き合いいただきありがたい。

以上。

Promiseのthenメソッドには第二引数がある

Tue, 19 May 2020 06:57:35 GMT

この記事は以下のツイートについて。

thenメソッドって第2引数でrejectedなときに実行する関数も指定できるのか、いつもcatchばかり使っていた。
— やんまー (@yammerjp) May 19, 2020

きっかけはMDN web docsのPromiseについてのページを見ていたことに始まる。

以前、私がPromiseとaync/awaitを理解するときにとても役にたった記事があった。 Qiitaにあった記事で同期処理でPromiseをしてみて理解しようと試みる記事だったのだが、いま探しても見つからない。

需要がありそうなので自分で書いているのだが、そんな中でMDNを見ていてthenメソッドに関する発見があった。

const promise = new Promise( (resolve,reject) => {
  setTimeout( () => {
    if( (Date.now()%2) === 0 ){
      resolve()
      return
    }
    reject()
  }, 1000)
})

promise.then(
  () => { console.log('fulfilled')},
  () => { console.log('rejected')}
)

あなたの運(実行タイミング)によってfulfilledかrejectedが表示されるコードである。

thenの第一引数は、promiseオブジェクトがfulfilled状態になったとき(上記コードでいえばresolve()が実行されたとき)、実行される関数である。

これは理解していたが次だ。

thenの第二引数は、promiseオブジェクトがrejected状態になったとき(上記コードでいえばreject()が実行されたとき)、に実行される関数である。

これは見落としていた。いつもthen(A).catch(B)として拾っていたが、then( A, B )として書けるのだな。

書けることと見やすいことは別で、今の私の感情ではcatchと書いたほうが見やすいのでは？と思うのだが、実際のところどうなのだろう。 thenの第二引数がどれだけ使われているのか気になるところである。

ところで、promiseの状態について、初期状態をpendingと表現し、それがfulfilledかrejectedに変化するのだが、fulfilledのことをついresolvedと表現したくなってしまう。

正確にはresolvedというと、fulfilledとrejectedをどちらも指すようで、promiseが成功したときはfulfilledと表現すべきらしい。 (resolvedと同じ意味でsettledという言葉も使われるようだ。)

なるほど区別するのは良いのだが、それならよく

new Promise( (resolve, relect) => {})

と書いているのはどうなの。

new Promise( (fulfill, reject) => {})

と予め書いてあるほうが混乱を産まないと思うのだが。

話がそれたが今日はPromiseのthenメソッド第二引数についてであった。いつも使っている文でも知らないことが隠れていたりするので、ことあるごとに正しい文献に戻ることを心がけていきたい。

Raspberry Pi Zeroをモニタレスで使うためのSetup

Fri, 15 May 2020 16:21:46 GMT

2020/3/4のメモ。 Raspberry pi Zero を、購入後一切モニタにつなぐことなく無線LAN経由でSSHできるようセットアップする手順。

母艦は MacOS X で行っているが、SDカードへの書き込みができればなんでもよい。

肝となるのは、OSを書き込んだSDカードに次のように手を加えておくことだ。

事前に無線LANのSSIDとパスワードを記述したファイルをおく
SSHを有効化する

起動前

micro SD cardのフォーマット

SD Association公式サイトより、SDカードフォーマッターをダウンロードする。

ダウンロードしたSDカードフォーマッターでSDカードをフォーマットする。

( FAT, FAT32, exFAT)。 4GB以上(要出典)。

OSイメージのダウンロード

raspberry pi公式サイトからraspbianをダウンロードする。

ここではGUIが必要ないので、[Raspbian Buster Lite]のzipをダウンロードする。

OSイメージの書き込み

# ダウンロードしたzipを展開してimgファイルを得る
$ unzip 2020-02-13-raspbian-buster-lite.zip

# デバイスを確認
$ diskutil list

# フォーマット済みの書き込み先デバイス(ここでは/dev/disk2)をunmount
$ diskutil unMountDisk /dev/disk2

# 書き込み
$ sudo dd bs=1m if=2020-02-13-raspbian-buster-lite.img of=/dev/disk2

wifiの事前設定とsshの有効化

書き込み後のSDカードのbootドライブをマウントする。(/Volumes/boot)

$ cd /Volumes/boot
# bootドライブちょっかいsshという名前のファイルが有ると、初期状態でsshが起動する
$ touch ssh

# wifi設定を書き込む
$ vim wpa_supplicant.conf

wpa_supplicant.confの中身は以下の通り

# wpa_supplicant.conf

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=JP

network={
        ssid="接続先アクセスポイントのSSID"
        psk="接続先アクセスポイントのパスワード"
}

起動

micro SDカードを差し込み、PWRと書かれた方のmicro USB Bポートに電源ケーブルをつなぐと起動する。

ipアドレスとmacアドレスの確認とDHCPリースの固定

起動すると、自動でwifiに接続して22版ポートが開いてsshが立ち上がる(少し時間がかかる)

ルータの設定画面などをみて、新しく接続されたデバイスに注目する。raspberry piっぽい端末のmacアドレスを見つける。

DHCPリースを固定にして、このMACアドレスに対応するIPアドレスをわかりやすいものに固定しておく

sshで接続

クライアント側

$ ssh pi@192.168.0.13
# raspberry pi のIPアドレスを指定(ここでは 192.168.0.13 であるとする)
# デフォルトのIDは pi
# デフォルトのパスワードは raspberry

設定

raspberry pi側

# visudoでnanoではなくvimを立ち上げる
# 参考: https://qiita.com/koara-local/items/35b999631b6ab41fdc9f
$ sudo update-alternatives --config editor

# vimをエイリアスとして登録
$ vim ~/.bashrc

.bashrcに下記を追記

# .bashrc
alias vim='vi'

変更を読み込む

$ source ~/.bashrc

sshの設定

ssh用ユーザの作成

raspberry pi側

# yammerというユーザを作るとする
$ sudo useradd yammer
$ sudo passwd yammer
$ sudo visudo

visudoによって、/etc/sudoersに下記を追記

yammer  ALL=(ALL) ALL

ssh用公開鍵の作成

ssh用の公開鍵を作る。

クライアント側

$ cd ~/.ssh
$ ssh-keygen -t rsa -b 4096 -C "raspberry-pi" -f ~/.ssh/id_rsa_pi

sshのパーミッションを設定

raspberry pi側

$ cd /home/yammer
$ chmod 700 .ssh
$ chmod 600 .ssh/authorized_keys

ssh公開鍵を送る

クライアント側

$ scp ~/.ssh/id_rsa_pi.pub yammer@192.168.0.13:/home/yammer/.ssh/authorized_keys

ssh設定

raspberry pi側

$ sudo vi /etc/ssh/sshd_config

# /etc/ssh/sshd_config

RSAAuthentication   yes
PubkeyAuthentication   yes
AuthorizedKeysFile   .ssh/authorized_keys
AllowUsers yammer # ユーザ名を追加

$ sudo /etc/init.d/sshd restart

接続できるか確認

クライアント側

$ ssh -i ~/.ssh/id_rsa_pi yammer@192.168.0.13

参考

SSH用のユーザー追加手順と注意点のまとめ - Qiita

Vimに入門したときの覚書

Fri, 15 May 2020 16:07:44 GMT

昨年、Vimを使える人間になりたいという気持ちからVimに入門した。

まずvimtutorをやり、またVim以外のエディタを使うことを禁止して慣れるようにした。 vimtuorのあとは実践Vimを読んだりしながら日常使いの中でVimに慣れていった。また基本的にプラグインを追加することを禁止し、不用意な.vimrcの編集も禁止して、素の状態のVimに慣れるように気を配っていた。

そんなこんなでVimに慣れようとしていたわけだが、最初期vimtutorをやるだけではなかなかキーバインドが覚えられず、とても編集速度が遅かったので、同時にメモに書き出すことで覚えていたようである。

このときのメモをここに供養する。書いた日付は2019/10/28。

Vim :help 日本語化

まず次のコマンドを実行

$ curl -fLo ~/.vim/autoload/plug.vim --create-dirs \
    https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim

次に~/.vimrcに次の内容を追記

" .vimrc

call plug#begin('~/.vim/plugged')
" A project which translate Vim documents into Japanese.
Plug 'vim-jp/vimdoc-ja'
call plug#end()

set helplang=ja,en

次にVimを立ち上げて:PlugInstallと入力しプラグインをインストールする

参考: Vimをちゃんと知りたい！だからHelpを日本語化する！

.vimrcを無視する

.vimrcを書き換えて起動しなくなったら

$ vim -u NONE -N
# -u None ... .vimrcを読み込まない vi互換モードにする
# -N ...(nocompatible) vi互換モードをオフにする

. 直前の操作を繰り返す

ノーマルモード

直前のコマンドを繰り返す(カーソル移動はコマンドとみなされない) (ex.x, dd, >G)

インサートモード

挿入モードに入った瞬間(iを押す等)からノーマルモードに戻る(<Esc>を押す)までの間のキーストロークが記録されている
.を押すことでこの一連の流れを再生できる

移動

h ... ←
j ... ↓
k ... ↑
l ... →
$ ... 行末に移動
w ... 次の単語へ移動
gg ... ファイル先頭へ移動
G ... ファイル末尾へ移動
{数字}G ... {数字}行目に移動
<Ctrl>G ... 現在のカーソル行を表示
>G ... 現在の行からファイル末尾までのインデントを1段深くする

基本操作

x ... カーソル下の文字を削除
dd ... 行頭から行末まで削除
i ... インサートモードへ切り替え
a ... カーソルの右隣でインサートモードへ切り替え
A ... 行末に移動してインサートモードに切り替え
o ... 次行を作りインサートモードへ
O ... 前行を作りインサートモードへ
u ... アンドゥ戻る
U ... 行単位でアンドゥ戻る
<Ctrl>R ... リドゥ　戻るの取り消し
0 ... 行頭へ移動
p ... 貼り付け (削除したものを貼り付け例えばddコマンドで削除した行等
r ... 置き換えカーソル下の文字を一文字消して次に入力した一文字で置き換える。なお置き換え後もノーマルモードを維持する
R ... 置換モードカーソル下を上書きして文字を挿入する escキーでノーマルモードに戻る
% ... 対応する括弧へ移動
yy ... 行をヤンク
yw ... カーソル後ろの空白を含む単語をヤンク

モーション操作

`d`

ノーマルモードでモーション操作を行うとカーソル移動

d{モーション}を行うと現カーソルからモーション先まで削除

d{数字}{モーション}ないし{数字}d{モーション}は等価で、数字個先のモーションの差示す場所まで削除する

`e`

c{モーション}を行うと、現カーソルからモーション先まで削除して挿入モードに切り替え

モーション

w ... 空白を含む単語尾
e ... 空白を含まない単語尾
$ ... 行末

コマンド

終了

:q! ... 内容を破棄して終了
:wq ... 内容を保存して終了

書き込み

:w filename ... ファイルfilenameへ書き込み

検索

/hoge ... hogeを前方検索
?hoge ... hogeを逆方向に検索
(検索した状態で)n ... 次を検索
(検索した状態で)<Ctrl>o ... 一つ前の検索結果に戻る

置換

:s/before/after ... カーソル行の１つ目のbeforeをafterへ置換
:s/before/after/g ... カーソル行の全てのbeforeをafterへ置換
:3,5s/before/after/g ... 3行目から5行目の全てのbeforeをafterへ置換
:%s/before/after/g ... ファイル内全てのbeforeをafterへ置換
:%s/before/after/gc ... ファイル内全てのbeforeを都度確認しながらafterへ置換

検索/置換のオプション

:set ic ... 検索時に大文字小文字を区別しない(ignorecase)
:set is ... 検索フレーズに部分マッチしている部分を表示する(incsearch)
:set hls ... マッチする全てを強調表示する(hlsearch)

ターミナルコマンド実行

:!ls ... lsを実行(のちエンターでvimに戻る)

挿入

:r filename ... filenameの内容をカーソル位置へ挿入
:r !ls ... lsの結果をカーソル位置へ挿入

help

:help ... helpウィンドウを開く
:help hoge ... hogeに関するhelpを見る

候補と保管

:e<TAB> ... eから始まるコマンドを補完
:e<Ctrl>d ... eから始まるコマンドを一覧表示

visualモード

v ... visualモードへ切り替えカーソルを移動させると、visualモード移行時のカーソルとの間が反転し選択される
(visualモードで短形選択時):'<,'>w filename('<,'>は自動で入力される) ... 短形選択部分をfilenameへ書き出し
(visualモードで短形選択時)y ... ヤンク(コピー)

TypeScriptでプロジェクト内独自の型定義をまとめたファイルを読み込ませる方法。

Fri, 15 May 2020 16:01:45 GMT

TypeScriptでプロジェクト内の型定義をするときのための過去のメモをここに供養する。日付は2020/1/10。

やりたいこと

TypeScriptで、独自の型定義をプロジェクト内の複数のファイルで利用したい。

src/types/index.d.tsで定義する型DayOfWeekをはじめとして、src/typesディレクトリ以下のファイルにある型定義をTypeScriptコンパイラに読み込ませて、プロジェクト内の任意のファイルで利用できるようにする。

// src/types/index.d.ts
type DayOfWeek = "Sunday" | "Monday" | "Tuesday" | Wednesday" | "Tursday" | "Friday" | Saturday";

方法

tsconfig.jsonに次を追記する

// tsconfig.json
{
  "compilerOptions": {
    "typeRoots": [
      "node_modules/@types",
      "src/types"
    ]
  }
}

tsconfig.json内でのcompilerOptions.typeRootsは文字列の配列をおく。

文字列は型定義ファイルを置くディレクトリのパスを表す。

もともと、npmでインストールしたパッケージの型定義はnode_modules/@types以下に配置され、compilerOptions.typeRootsが定義されていないときはデフォルトで読み込まれる。

compilerOptions.typeRootsを記述する際には、自分の定義したい型ファイルのディレクトリと合わせて、デフォルトで読み込まれる型定義ファイルのパスも記述する必要がある。

発展して

逆に、インストールした型定義を無視したい時は、compilerOptions.typeRootsにnode_modules/@typesを除いて記述すれば良い。

使うシチュエーションはあまりないかもしれないが。

感想

TypeScriptは毎回完全理解()しているので、チョットデキル人間になるために一度ちゃんと学び直す必要がありそう。

(この項目はメモをここに移したときに書いた)

TELNETでHTTP通信する

Fri, 15 May 2020 15:43:55 GMT

TELNETでHTTP通信するだけの記事である。すぐ終わる。

相手ホストやポート番号、手書きのHTTPヘッダを渡せば、 TELNET で HTTP 通信ができる。

$ telnet memo.yammer.jp 80
Trying 2400:6180:0:d1::4df:d001...
Connected to memo-basd4g-net.netlify.com.
Escape character is '^]'.
GET / HTTP/1.1
Host: memo.yammer.jp
Connection: close

HTTP/1.1 301 Moved Permanently
Cache-Control: public, max-age=0, must-revalidate
Content-Length: 40
Content-Type: text/plain
Date: Fri, 15 May 2020 15:46:22 GMT
Location: https://memo.yammer.jp/
Age: 2
Connection: close
Server: Netlify
X-NF-Request-ID: e38b7b4a-47e9-4306-8d60-e917e96c78cd-2547281

Redirecting to https://memo.yammer.jp/
Connection closed by foreign host.

IPv6でつないでくれている。

あいにく memo.yammer.jp は HTTP をリダイレクトしてしまうのでページの内容は取得できなかったが、通信できた。

たまには HTTP ヘッダを手書きしてみるのも趣があるのではなかろうか。(??)

以上。

インターネットとTCP/IP

Fri, 15 May 2020 14:37:00 GMT

今日のインターネットの根幹をなすTCP/IPについての基本的な知識を説明する。

研究室の輪講で「マスタリングTCP/IP 入門編」を読んだことがきっかけ。

参考文献: マスタリングTCP/IP入門編第二章 pp60-80

インターネット

今この文章もインターネットに公開され、インターネットを介して見ていることと思うが、インターネットとはそもそも何を指すのか。

Internet / The Internet とは、TCP/IPにより全世界を接続しているコンピュータネットワーク、ただ一つのことを指す。

語源は「複数のネットワークを結ぶ」ことを表す internet。現在ではこの意味は internet ではなく internetworking という言葉で表される。

インターネットの構造

インターネットは、小さなネットワークが相互接続し1つのネットワークを成し、これが複数接続して大きなネットワークを成し、、のように階層的な構造をもつ。

ISP (Internet Service Provider) のネットワーク内では、NOC (Network Operation Center) と呼ばれる施設を通じて接続し、ネットワークを構成している。 ISP 同士の接続には、2者間接続を行うプライベートピアリングや、多数の ISP を IX (Internet Exchange) を通じてつなぐ IP トランジットがある。

画像はインターネットの構造を表した図。

ISP 以外にも有志で運営される地域ネットといわれるネットワークも存在すると本に記載があるが、2020年現在の実態は不明。過去にあった地域ネットとして柏インターネットユニオンなどがあるようだ。

TCP/IP

TCP/IP とは、パケット交換プロトコルである IP (Internet Protocol) を利用したり、 IP で通信したりするときに必要なプロトコル群の総称のことである。インターネットで必要なプロトコルをまとめたものであることから、インターネットプロトコルスイートとも言われる。 TCP/IP という語を使うとき、 TCP プロトコルと IP プロトコルだけを指しているわけではない。

パケット交換ネットワーク

先程出てきたパケット交換について。パケット交換ネットワークとは、電話に用いられるような回線交換型と対比されるネットワークの形式である。

一つの回線を複数が共有して使う。代表的な利点として、回線の利用効率を高められること、分散型のネットワークの構築に向くことが挙げられる。

TCP/IP の歴史

1960年代、米国防総省 (The Depertment of Defense) が中心に、分散型ネットワークによる通信技術の開発が行われた。その中で学術機関4ノードを結ぶ、パケット交換の実用性を試験するための分散型ネットワーク ARPANET が誕生した。 ARPANET は急速に発展し、3年間で34ノードにまで拡大し、パケット交換によるデータ通信に実用性があることがわかった。

その後、単なるパケット交換通信にとどまらず、各ノードのコンピュータ間での信頼性の高い通信手段を提供する総合的な通信プロトコルが実験、開発される。これがTCP/IPとなった。

TCP/IP は当時普及していた OS である BSD UNIX に実装され、利用がさらに加速する。 ARPANET は拡大し、多数のネットワークと接続するようになる。やがて ARPANET や後継の NSFnet に接続する TCP/IP による世界的なネットワークをインターネット (The Internet) と呼ぶようになった。

1995年ごろには ISP (Internet Service Provider) が乱立し、インターネットの商用化が進む。このような流れで今日に至り、世界中を TCP/IP によるネットワークであるインターネットが覆い尽している。

1960s DoD による通信技術の研究
1969 ARPANET の誕生。パケット交換技術の開発
1972 TCP/IP の誕生
1975 TCP/IP の仕様決定と、 TCP/IP が実装された UNIX の提供
1982 ARPANET でのプロトコルがTCP/IPに統一
1989 LAN/WAN 上で TCP/IP が普及
1995 インターネットの商用化が進む

TCP/IP の標準化

TCP/IP はプロトコル群であり、通信のためには両者が同一のプロトコルを使用する必要がある。そのためにTCP/IP にも標準が存在するが、 TCP/IP の標準化には次の2つの特徴があり、これがプロトコルの急速な実現と普及に影響した。

オープンである
実用を重視する

特徴:オープンである

TCP/IP の仕様を議論する IETF (Internet Engineering Task Force) のメーリングリストには自由に参加できる。

また仕様や実装も公開されており、自由にアクセスできることもオープンであるという特徴を表している。

画像はIETF のあるWebページの冒頭部分である。画像下部分に書かれているように、IETF の議論には、どんな個人でも参加できる。このページの更に下に行くと、実際にメーリングリストに参加する手順が書かれていた。

特徴:実用を重視する

TCP/IP は仕様策定時に実装することを念頭において進む。プロトコルの詳細仕様を決める際には既に通信できる実装が存在し、標準になる頃には既に製品に実装されている。

画像はTCP/IP 標準化の手続きを図示したものである。

以上のように、TCP/IP の標準化手続きには特徴がある。普及した要因に、他のプロトコルと比べ、実用を重視したことで動作するプロトコルをはやく作れたこと、オープンな仕様策定の仕組みにより急速な技術革新に対応できたことが考えられる。

TCP/IP の仕様

標準化しようとするプロトコルは RFC (Request For Comments) と呼ばれるドキュメントになり、インターネット上で公開される。仕様だけでなく、実装や運用、実験に関する情報を含む。

RFC には番号をがつけられており、一度 RFC になると改定することはない。拡張や廃止、新規のプロトコルを定める際には新たな RFC として公開される。そのため通し番号は大きくなり、プロトコルごとに番号の統一性があるわけでもないので人間にはわかりづらいところがある。これを助けるため、複数の RFC を指す STD (STanDard), FYI (For Your Information) などの文書単位もある。

画像は RFC2617 の冒頭である。

TCP/IP の階層モデル

TCP/IP モデルは階層構造になっている。ネットワークの信頼のある通信を実現するには様々な機能を実装せねばならないので、各層に分けて他層を抽象化することが現実的には必須。

TCP/IP が普及した理由の一つに柔軟性が挙げられる。 IP が動作すればそれより下位層は何を使ってもよいし、 TCP / UDP 上で動作すればそれより上位のアプリケーションはなんでもよいのである。

以下では、 OSI 参照モデルと TCP/IP 階層モデルの対応を示した後、下位層から順に、代表的なプロトコルを示す。

OSI 参照モデルとの対応

TCP/IP の階層モデルは、アプリケーション層、トランスポート層、インターネット層、リンク層の4階層から成る。 OSI 参照モデル7階層に完全に対応するものではないが、対応するとしたらつぎのようになる。

ハードウェア

OSI 参照モデルで物理層に当たる部分である。

ハードウェアついては、 TCP/IP プロトコルでは特に指定されていない。通信する上での信頼性、セキュリテイ、帯域、遅延、無線/有線、電話回線やイーサネットなど、物理的なものには拘束されず、ネットワークで接続された装置間で通信できればよい。

余談だが、 TCP/IP におけるハードウェアとして伝書鳩を用いることもできる。 RFC にも、RFC1149 鳥類キャリアによるIPデータグラムの伝送企画としてきちんと仕様が存在する。

これはエイプリルフールに作られたようだが、このような~~ふざけた~~お茶目な RFC はジョーク RFC と呼ばれ、他にも次のようなものがある。

等。鳩を用意するのは厳しいが、後者2つは実装してみたい気もする。

リンク層

ネットワークインタフェース層とも。(マスタリングTCP/IP入門編より)

デバイスドライバが実装にあたる。(マスタリングTCP/IP入門編より) ハードウェアの違いを吸収し、上位層で IP が使えるようにする。

PPP (Point to Point Protocol) もここに含まれる。

インターネット層

OSI 参照モデルの下から3番目であるネットワーク層に対応する。

経路制御を行う。通信したいホスト間のデータリンクを上位層へ隠し、実際は Hop-by-Hop で行われている通信を End-to-End で行われているようにみせる役割がある。

代表的な3つのプロトコルを紹介する。

IP (Internet Protocol)

パケットを転送するために用いられる、インターネット層で代表的なプロトコル。 IP アドレスでホストを識別し、通信相手までパケットを配送する。通信経路の確立を行うが、データが正しく送られる保証はない。

ICMP (Internet Control Message Protocol)

IP によるパケット転送に誤りがあったり、失敗したときにこれを通知するために用いられる。他に、ネットワークが正常に通信できるか診断する機能ももつ。 ping コマンドや traceroute コマンドなどは ICMP パケットを送信することで実現している。

ARP (Address Resolution Protocol)

IP アドレスと MAC アドレスの対応関係を取得するためのプロトコル。IP が目的地へ通信するために、ARP を用いて途中の各通信経路の解決が行われる。

トランスポート層

OSI 参照モデルの下から4番目であるトランスポート層に対応する。アプリケーション間のプログラムの通信を実現し、場合によってはデータの到達性も保証する。

TCP (Transmission Control Protocol)

コネクション型のプロトコル。データの到達性を保証し、再送制御や輻輳制御を行う。コネクションの確立に3パケット、切断に4パケットの通信が少なくとも必要である。

UDP (User Datagram Protocol)

コネクションレス型のプロトコル。データの到達性を保証しない。パケット数の少ない通信、2者間ではないブロードキャスト/マルチキャスト通信, データが多少抜け落ちても問題ない動画や音声の通信に向く。

アプリケーション層

OSI 参照モデルの5-7階層に相当する。 TCP/IP上では様々なアプリケーションを動かすことができる。以下では、それぞれのアプリケーションごとに使われるプロトコルを紹介する。

WWW (World Wide Web)

HTML (Hyper Text Markup Language) 文書をはじめとするデータを、Webブラウザを介して HTTP (Hyper Text Transfer Protocol) / HTTPS ( - Secure) で受信し閲覧する。

(QUIC などの例外を除いて)主に TCP 上で動作する。

電子メール

MIME (Multipurpose Internet Mail Extensions) (マイム)形式のデータを、専用のプロトコルを用いて送受信する。

メールの送受信には SMTP (Simple Mail Transfer Protocol), POP3 (Post Office Protocol version 3), IMAP (Internet Message Access Protocol)などが用いられる。

送信者はメールを SMTP サーバを経由して相手方の POP3 / IMAP サーバへ送信する。受信者は POP3 / IMAP サーバよりメールを受け取る。

TCP 上で動作する。

ファイル転送

FTP (File Transfer Protocol) / SFTP (Secure - )によりファイルを送受信する

TCP 上で動作する。

遠隔ログイン

TELNET (TELetypewriter NETwork) や SSH (Secure SHell) を用いて離れたコンピュータにログインする。

Linux で GUI を実現するためによく用いられる X Window System の X Protocol も TCP/IP 上で実現している。

TELNET や SSH 等は TCP 上で動作する。 X Protocol の中でも XDMCP (X Display Manager Control Protocol) は UDP。

ネットワーク管理

SNMP (Simple Network Management Protocol) など。

ネットワーク上のルータやスイッチなどの管理対象(SNMP エージェント)を管理端末(SNMP マネージャ)が管理する。パケットの量や機器の温度などを管理できる。ネットワーク機器の動作を妨げないため、また通信に必要なパケットが少ないため、UDP で動作する。

実際の通信

通信を行う際、送信側は上位層から順にその層で必要となる管理情報を含むヘッダを付加してカプセル化する。受信側は下位層から順にヘッダを解釈して除去し上位層に渡す。

例えばWebページを閲覧する際は、サーバ側で HTML 文書に HTTP ヘッダを付加し、 TCP ヘッダを付加し、 IP ヘッダを付加し、イーサネットフレームのヘッダを付加し送信される。クライアントはイーサネットフレームのヘッダを解釈し、 IP ヘッダを解釈し、 TCP ヘッダを解釈し、 HTTP ヘッダを解釈し、 HTML 文章を画面に描画する。

まとめ

以上の内容をまとめると次のようになる。

インターネットは TCP/IP で接続される世界全体のネットワークのこと
TCP/IP は IP をはじめとするプロトコル群
TCP/IP はオープンな議論で, 実用重視の仕様策定を行っている
TCP/IP の各プロトコルは階層モデルでわけることができる

ネットワーク全体について俯瞰して振り返ることはあまりないので、スライドを作ったのに合わせて文章にも起こしてみた。こういった復習を多く含む地道な勉強も、怠らずにやっていきたい。

追記: (2020/10/04) 不要な改行タグを削除

就活を終えて半年経って思うこと。

Wed, 13 May 2020 14:54:22 GMT

進路を迷っている知人に就活のことを聞かれ、自分が何を考えて決めたのかを、主に次の視点で綴ったので、ここにも記します。

就職先の決め手
なぜエンジニアとして働くのか
なぜ大学院に進学しなかったのか

就職先の決め手

就活時に重視していたところはつぎのようなことがあります。

文化
技術的な成長
会社のサービスに自分が貢献したいと思えるか

会社を決めた理由は、ざっくりまとめると「自分が最も成長できそうだから」でしょうか。就職予定の会社は、独特の企業文化が特徴です。これが自分が働くモチベーション高く保つことにつながると考えました。技術が身につく環境でも、自分に合わない環境で働くのは長続きしないでしょう。しかしこの会社でなら正直に過ごせそう、自分が成長の努力をしながら楽しんで働けそうだと感じたからです。

新卒時点の給料はそこまで重視していなくて、技術が身につけばいくらでも給料を高められるだろうから、自分が成長できること(長期的に見て稼げること)のほうが大事だと考えていました。

あとは、会社規模も関係しています。決めた会社は社内のエンジニアコミュニティが強く、その中で高めあっているところが魅力に写りました。

他に受けていた会社で、エンジニアが数人ほどの企業もあったのですが、私の技術的な未熟さゆえに選考を断念しました。 (極端に言うと幅広い技術や一歩先の技術を身につける余裕を自分に持てないのではないかとの懸念がありました。) 規模が小さいほうが裁量があったり、ビジネスサイドにも足をつっこんだりしやすい側面はありそうです。この魅力を重視する方は私とは違う決断をするでしょう。)

逆にもっと大きな会社だと、細分化されすぎていて私には楽しくないようにみえました。(エンジニアリングに関してはいろんなことに足を突っ込んでみたい。) 会社規模は選考がある程度進んでから、比較するようになって考えだしました。

エンジニアになるかどうか

私はわりと初期の段階でWebエンジニアに絞ってしまっていました。とりあえず行動してみて、納得できなければ変えるつもりでしたが、働くイメージが湧いてきたのでそのまま方向を変えずに就活をつづけました。

自分がどれだけ技術を好きになれるか、勉強を苦に思わないかが自分の中での判断基準です。世の中には自分よりコンピュータが好きな人はたくさんいるし、上を見たらきりはないので、現時点での技術力と熱意が他人に負けているからダメという選び方はしていません。私にとって、他の仕事よりWebエンジニアとして働いたほうが、仕事を楽しめてかつ社会に出せる価値が多そうだと判断し決めました。

(Web)エンジニアになるのはある意味賭けで、専門的な技術は身につくけど、いざとなれば転職で入ってこれる業界でもあるので、難しいですね。

エンジニアといっても、ビジネスやデザインのわかるエンジニア、他方、技術に尖ったエンジニアをより欲しているところ、育てようとしているところはたくさんあるだろうし、非常に多種多様な姿があるだろうから、自分にあったキャリアを見つけるのは大変でしょう。さらに世の中には本当に様々な仕事があり、Webエンジニア、プログラマーだけをを見ているのは勿体無いかもしれません。

私なりにいくつかの選択肢を考える中で、自分に興味のある領域を深められる職・会社としていまの進路を選びました。

大学院に行くかどうか

就活を始めるときに、内心「良さげな企業に受かったら就職、うまく行かなかったら院にいこうか」と考えましたが、まず「とりあえず就職前提で動こう」(じゃないと何もしなそう)と自分に言い聞かせました。

就活をしていくうちに、良い会社に出会えたこと、(まだ始まっていなかったが)大学での研究よりもWeb周りのことを触っている方が楽しいだろうと思ったことから就職へ傾きました。内心、面接が重なると早く就活を抜け出したい、(院卒で)もう一回やるのはちょっと大変という気持ちもありました。就活は真剣にキャリアを考える機会として面白い面もあるのですが、続けていると気持ちが疲れてくる面もあります。

いまの会社に受かってなければ大学院に進学していたかもしれません。真っ当な理由「研究がしたい」はもちろん、就活を先延ばしにする意味でも大学院進学もありだったなとは今も思ってます。(院卒に怒られる)。

Web業界は新卒といえど、(私は経験ないですが)長期インターンに行っている人が結構いたり、ある程度の技術的素養が求められている会社もそこそこあるので、就活が先延ばしになると受かりやすくなる面はあるかもしれません。 (どこかで読みましたがインターンに受かるコツはインターンに受かることだそうです。) 大学院に進学すれば、インターンなどに参加する時間的な猶予ができるともとれます。

つたない文章ですが、私が考えていたことを思い返してみました。

就活をはじめてから、自分がどんな価値を見いだせるか、どんな環境で働きたいか、あらためて何度も考えました。特に面接や面談はその考えが深まる、改まる場であって、このような機会を設けてくださった方々に感謝しています。

(余談) User Defaultsとproperty list(plist)

Sat, 02 May 2020 07:26:00 GMT

Mac OS XのUser Defaultsを変更するためのシェルスクリプトを作るツール pdefを制作した。(解説記事: Macの設定を自動化するdefaultsコマンドと、それを助けるpdef)

これを作る際にProperty listについて学んだことを記す。

User Defaults

User Defaultsは、MacOSXやiOSにおける各アプリケーションが設定などを保持するためのデータベースである。 User Defaultsは、各アプリケーション(正確にはアプリケーションの持つドメイン)ごとにProperty listとして記録される。普段は各アプリケーションを通して読み書きされるが、ターミナル上からアクセスできる$ defaultsコマンドも提供されている。(後述)

Property list

User Defaultsに使われているproperty list(以下plist)は、Mac OS Xにおいてオブジェクトの永続化におけるファイル形式としてよく用いられている。例えば、iOSアプリを開発する際に自動生成されてXcode上から見えるinfo.plistがその例だ。

plistはNeXTSTEP時代から続く歴史あるフォーマットらしい。時代背景も相まってファイルの保存形式は多数ある(後述)。

論理構造

plistはJSON等と同様のキーバリュー形式の論理構造を取る。キーに一対一対応する値が存在し、値は即値の他に入れ子状にデータを保持できる。

値のとりうる型は次の通り。

辞書(dictionary)
配列(array)
文字列(string)
数値(number(integer and float))
日付(date)
バイナリ(binary data)
真偽値(Boolean value)

この中でも辞書型と配列型は特殊で、辞書型はキーと値の組を、配列型は値を、子にもつことができる。

JSONに無い型(日付,バイナリ)が存在するので、完全な相互変換は不可。

参考: Property list - Apple Developper Documentation (plist関する公式のドキュメント)

保存形式

old-style ASCII形式

テキストベースで、可読性が高いのがこの形式。NeXT形式とも呼ばれる?。NeXTSTEP時代にできた。作られた当時、文字列、配列、ディクショナリ、そしてバイナリデータのみを表現できたらしい。シンプルなフォーマットであるが、型情報がなく、型の判別が難しい。

$ defaults readコマンドで出力される形式であり、現在では主にここでみられる。

old-style ASCII形式の例として、あるplistをold-style ASCIIで表した表記を以下に示す。

{
    "boolean-example" = 0;
    fuga =     {
        p0y0p0y0 = 0;
        punipuni = value;
    };
    hoge = helloworld;
    wara =     (
        {length = 8, bytes = 0x0123456789abcdef},
        123,
        "0.5",
        1,
        "2019-09-16 05:45:42 +0000"
    );
}

XML形式

plistのデータ構造をXML形式で表現した形式。前述のold-style ASCIIのように欠けた情報がなく、なおかつ人間にも読めるのでplistをこねくり回す際にはお世話になるだろう。

それぞれの型におけるxml上での表記は次の通り

辞書: <dict> <key>keystring</key> [value] (繰り返し) </dict>
配列: <array> [vaule] (繰り返し) </array>
文字列: <string>value</string>
数値(整数): <integer>124234</integer>
数値(浮動小数点数): <real>0.43</real>
日付: <date>2019-09-16T05:45:42Z</date> (ISO8601と思われる)
バイナリ: <data> ASNFZ4mrze8= </data> (base64でエンコード済みの文字列)
真偽値: <true/>または<false/>

XML形式の例として、先程示したplistをXMLで表した表記を以下に示す。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>hoge</key>
  <string>helloworld</string>
  <key>boolean-example</key>
  <false/>
  <key>wara</key>
  <array>
    <data>
    ASNFZ4mrze8=
    </data>
    <integer>123</integer>
    <real>0.5</real>
    <true/>
    <date>2019-09-16T05:45:42Z</date>
  </array>
  <key>fuga</key>
  <dict>
    <key>punipuni</key>
    <string>value</string>
    <key>p0y0p0y0</key>
    <string>0</string>
  </dict>
</dict>
</plist>

binary形式

テキストベースではなく人間が用意に読めなくした代わりに、ファイルサイズの削減と読み書きを高速化ができる形式。

ここまでで述べたようにplistはバイナリデータも含むことができる。そのため、大きなバイナリデータを含むplistについては、old-style ASCIIやxmlでの表現は冗長で、ファイルが大きくなる、読み書きが遅くなるなどの問題が生まれる。これを避けるためにバイナリ形式でデータを書き出すことができる。具体的な形式は未調査。

おそらくあまり出会うことはないが、バイナリ形式には現在使われていない古い別形式もあるらしい。

参考: Plistの歴史

plistを操作できるデフォルトツール

plistを検証、確認、変更するコマンドラインツールが、Mac OS Xにはデフォルトでいくつか入っている。

defaults, pl, plutil, /usr/libexec/PlistBuddyを紹介する。

defaults

User Defaultsを読み書きするためのツール

代表的なread,write,import,exportのハマりどころを記す。

$ defaults read

"ほぼ"old-style ASCII形式で、User Defaultsを標準出力に出力する。 old-style ASCIIには型情報を含まないので、型のみを調べる$ defaults read-typeもある。

出力は正しい文法のold-style ASCII形式のplistとは限らない。大きなサイズのdata型の値は、一部省略して出力され、この部分は文法規則に反する。 (これが原因で最初plistを正しく読み込めずに困った)

readの後ろに引数を渡さないとすべてドメインのUser Defaultsを出力する。 1コマンドでまとめて出力できるのは筆者の知る限り$ defaults readのみ。

ネストしている深い値を指定して読むことはできない。

$ defaults write

引数にで値を指定して、User Defaultsに書き込める。型を区別するオプションを指定できる。

data型は-dataオプションをつけた上で、valueを16進数表記で記述する。

date型は-dateオプションをつけた上で、valueをISO8601形式で記述する。

ネストしている深い値を指定して書き込むことはできない。

$ defaults export

特定のドメインのUser Defualtsをxml形式またはバイナリ形式で出力する。

ドメインは必ず指定する必要があり、$ defaults readのようにすべてのドメインのUser Defaultsを一括して出力することはできない。

$ defaults import

xml形式またはバイナリ形式でUser Defaultsに書き込める。

pl

old-style ASCII形式のplistの文法をチェックするツール。

plutil

XML,binary形式のplistの文法をチェックするツール。

値の読み書き/削除ができるが、深いネストしている深い値を指定して操作することはできない。

コマンドラインでplistを操作（データ追加・編集・削除） - Qiita(@trakwkbys)

/usr/libexec/PlistBuddy

ネストしている深い値を直接指定して読み書き/削除できるスグレモノ。

data型を書き込むときは、文字列がそのままbyte列として読み込まれるらしい。よって書き込める値が制限される。ネストが深い場所にあるdata型の値を書き込む際は、xmlファイルに直接base64エンコードした文字列を書き込むなどすると良い。

date型を書き込むときは、Mon Apr 20 20:52:00 2020 JSTのような形式を渡す。 (PlistBuddyのdata型の値書き込みに関するドキュメントは見つけられなかったが、darlingの実装を参考にして実験し見つけた。)

plistファイルを読み書きする際の、Swiftでの実装

今回作成したpdefにおいて、Swiftでplistを扱う際に肝になった部分を実装を交えて紹介する。

ちなみにPythonではplistlibが使えるようだ。

plistファイル全体をNSDictionaryとして読み込む

plistファイルをSwiftの変数として扱えるように取り込むのは非常に簡単。下記のサンプルコードのように一行で読み込める。

ファイル形式がold-style ASCIIだろうがxmlだろうがbinaryだろうが、勝手に判断してよしなにしてくれる。 (ただしハマりどころに注意)

// https://github.com/yammerjp/pdef/blob/516f0215306b6ca206ebad646190ba74bd5d4b17/src/loadFile.swift
// 以上より一部抜粋

import Foundation

guard let plist = NSDictionary(contentsOfFile: path) else {
  ErrorMessage("Failed to load property list '\(path)'")
  exit(1)
}

pdefをSwiftで実装したのはplistを扱うのが楽だろうからという目論見だったが、それが一番功を奏したのがこの部分。

型を判別する

上記の方法でplistファイルをSwift内の変数として読み込んでも、型はすべてAnyとして扱われてしまう。これは困るので、値を次のサンプルコードの関数GetPlistType(value: Any) -> PlistTypeに与えることで型を調べられる。型がわかればキャストできるので、その後Swiftで扱うのが楽になる。

// https://github.com/yammerjp/pdef/blob/516f0215306b6ca206ebad646190ba74bd5d4b17/src/plist.swift
// 以上より一部抜粋、書き換え

import Foundation

enum PlistType: Int {
  case string
  case real
  case integer
  case bool
  case data
  case date
  case array
  case dict
}

func GetPlistType(value: Any) -> PlistType {
  let typeID = CFGetTypeID(value as CFTypeRef?)
  switch typeID {
  case CFNumberGetTypeID():
    if value is NSInteger {
      return .integer
    }
    return .real
  case CFArrayGetTypeID():
    return .array
  case CFDictionaryGetTypeID():
    return .dict
  case CFStringGetTypeID():
    return .string
  case CFDataGetTypeID():
    return .data
  case CFDateGetTypeID():
    return .date
  case CFBooleanGetTypeID():
    return .bool
  default:
    exit(1)
  }
}

参考:

CFTypeID - Apple Developper Documantation(Property listの型をSwiftで判別する)
Swift.Any as? CFType - Qiita(@junpluse)(Property listの型をSwiftで判別する)
Inspecting Objects - Apple Developper Docuumentation(Property listの型をSwiftで判別する)

おわりに

Swiftでplistを扱うための情報を集めるのに時間がかかったので、まとめる記事を書くに至った。

この記事はMacの設定を自動化するdefaultsコマンドと、それを助けるpdef(pdefの紹介記事)の余談と補足として作った。ここまでの内容を実装して作った、User Defaults書き換えを支援するツールであるpdefも興味があれば使ってみてほしい。

User DefaultsだけでなくProperty listをSwiftで扱う際に、どこから手をつけてよいかわからない人が概要を掴むのにこの記事が役立てば幸いだ。

追記: (2020/10/04) pdefの記事へのリンクを相対リンクに修正

Macの設定を自動化するdefaultsコマンドと、それを助けるpdef

Thu, 30 Apr 2020 15:52:47 GMT

tl;dr Mac OS XのUser Defaultsの差分をdefaultsコマンドの形式に変換するコマンドラインツール、"pdef"を作った。

本題(pdefでシェルスクリプトを作る)まで飛ばす

defaultsコマンドでMacの設定を自動化する

Macには、OSや各アプリの設定を保存するUser Defaultsというデータベースがある。例えばドックの大きさやメニューバーに表示するアイコン、Safariの開発者ツールの有効化フラグ、(使用している場合は)サードパーティ製アプリケーションの設定情報なども記録されている。

これらのUser Defaultsの項目は普通、GUI上の設定画面を変更することでデータを読み書きするが、ターミナル上から操作するdefaultsコマンドなるものもMacに標準で入っている。

これを用いることで、Macの初期設定を自動化するシェルスクリプトがよく作られているようだ。

たとえば、次のスクリプトは、Finder(ファイラー)において、隠しファイル・隠しフォルダを表示する設定を有効にする。

#!/bin/bash
defaults write com.apple.finder AppleShowAllFiles YES

(スクリプト実行後に$ killall Finderとしてアプリケーションを再起動する必要がある。)

このようなdefaultsコマンドによる設定例はブログなどで見つけることができる。それらをまとめて自分用のシェルスクリプトを作っておけば、Macを初期設定する際にすぐに自分好みの環境にすることができるというわけだ。

GUIからの設定は項目が増えると手間がかかるし同じ環境を再現するのは大変なので、自動化できるのはありがたい。

様々なdefaultsコマンドの一例を記載したサイト

defaultsコマンドの引数を調べる

ところで、このdefaultsコマンドの引数はどのようにして知るのだろうか。先程のサイトに載っているものはよいものの、他の設定項目はdefaultsコマンドにどんな引数を渡せばよいのだろうか。私の調べた限りでは、公式なまとまった情報はないようだった。

しかし、愚直に調査する方法はある。

defaultsコマンドには、$ defaults writeの他に$ defaults readというサブコマンドもある。これによりUser Defaultsを閲覧できる。 GUI上の操作によってUser Defaultsにどんな変更が加わるか、変更前後の$ defaults readの出力を比較すればわかる。

$ defaults read > before.txt
# GUI上で設定を変更する
$ defaults read > after.txt

$ diff before.txt after.txt

diffで該当した部分を中心に、defaultsコマンドで指定する値を抜き出せばよい。

が、$ defaults readの出力結果を読むのが面倒なので、これを自動で行うツールを作成した。

($ defaults readの出力形式は、property list(old-style ascii)である。 (余談) UserDefaultsとplistについてとして別記事にまとめたので、plistについてはこちらを参照してほしい。)

pdefでシェルスクリプトを作る

閑話休題

pdefとは

pdef (pi:def) は、User Defaultsの設定前後の差分から、defaultsコマンドの引数を調べてくれる。

引数に$ defaults readの出力を記録したファイルのパスを与える。 (第一引数に設定前、第二引数に設定後) すると、設定前後の差分から、シェルスクリプト(defaultsコマンドを並べたもの)を出力する。

インストール

$ git clone https://github.com/yammerjp/pdef.git
$ cd pdef
$ make
$ cp bin/pdef /user/local/bin

使用例

次のように使う。

# 設定を記録する

$ defaults read > before.txt
# [GUI上で設定を変更する]
$ defaults read > after.txt
$ pdef before.txt after.txt > patch.sh

# 設定を復元する

$ bash patch.sh

使用例として、メニューバーの音量アイコンを表示/非表示している様子。

Mac上で設定を変更するときに、前後で$ defaults readでUser Defaultsの内容を書き出しておくと、pdefを使って再設定が楽にできるという算段である。

オプション

--domainオプションをつけると、特定のアプリのUser Defaultsも比較できる。($ defaults export hogehoge -の出力等) --domainオプションをつけた際は、old-style asciiのplist以外にも、xmlやバイナリも読み込める。

実行例

$ defaults export com.apple.systemuiserver - > before.xml
# メニューバーの変更(音量アイコンの表示/非表示等)
$ defaults export com.apple.systemuiserver - > after.xml
$ pdef --domain com.apple.systemuiserver before.xml after.xml

例外

pdefは現在は以下のようなものには対応していない。

data型の長い値 ( --domainオプションを付加すれば可能)
keyのrename
追加と削除が混在した差分

さいごに

インターネットの海に流れるdefaultsコマンドの設定例の他に、このツールで調べた設定を追加して、自分専用のMac設定用スクリプトの作成に役立てていただければ幸いだ。

私のdefaultsコマンドを集めたシェルスクリプトはこちら。

追記: (2020/10/04) plistへの記事リンクを相対リンクに修正

macOSでの各種設定を自動化するdefaultsコマンド

Mon, 13 Apr 2020 12:57:37 GMT

研究室や就職先などでのコンピュータのセットアップのために、3月頃からdotfilesを構築している。

その流れでdefaultsコマンドを知ったので、その記録と使い方、調べ方を残しておく。。

defaultsコマンドとは

macOSにおける環境設定や各アプリケーションの設定は.plist拡張子のプロパティリストと言われるファイルに記録される。このプロパティリストを読み書きするためにmacOSに標準で搭載されているのがdefaultsコマンドである。 (詳細は$ man defaultsしてください。)

これを利用して、OS全体の環境設定やアプリケーションの設定を自動化するスクリプトをつくっている。(実際に作ったスクリプト - yammerjp/dotfiles - GitHub)

今回はこのスクリプトを構築するための話。

参考: Macの「ターミナル」でプロパティリストを編集する - ターミナルユーザガイド - Apple

他人の設定を拝借する

ネット上に他の人がどのコマンドを叩くとどの設定が変更できるかを調べてすでにまとめてくれたものがある。これを拝借するのが第一の手。

公式でどこかに情報がまとまっていればよいのだが、「公式な」設定変更のやり方はGUIから変えることだからか、そんな丁寧なマニュアルはなさそう。

注釈: defaultsコマンドを実行すると、設定変更が即座に反映されるわけではない。以下のように再起動するなどして設定を読み込ませると良い。

# Dockの設定変更を反映
$ killall Dock
# finderの設定変更を反映
$ killall Finder
# メニューバー(画面上部)の設定変更を反映
$ killall SystemUIServer
# その他駄目なら再起動。
$ sudo reboot

設定するコマンドを探す

ネットを探していても自分の思うような設定がみつからないことがある。そのときは以下の手順で調べると見つかるかもしれない。

defaultsコマンドの使い方

前提として、manual($ man defaults)の通り、defaultsコマンドは次のように使う。以下は簡略に示す。実際に実行する際はmanualを参照。

# すべて読む
$ defaults read

# 読む
$ defaults read DOMAIN KEY
$ defaults read -g KEY
# 書き込む
$ defaults write DOMAIN KEY VALUE
$ defaults write -g KEY VALUE

プロパティリストはkeyとvalueの対が原則で、jsonのようにvalueの中に入れ子でkeyとvalueのまとまりなどが入る。

valueにはstringやdata, int, float, bool, array, dictなどの形式がある。

$defaults writeする際にオプションで-stringや-array, -array-addとすると希望のデータ型で値を書き込める。

探し方

設定変更前後のプロパティリストの差分から、それっぽい設定項目を見つける。その後実際に$ defaults writeでプロパティリストを書き換えて、設定が反映されるかを確認する。

このとき、設定変更のためのGUIウィンドウは予め開いておいて、beforeとafterの記録をすると良い。プロパティリストには我々が手動で設定した環境設定の他にも多用途に利用されているらしく、時間をあけるとあっという間にdiffが汚くなる。

$ defaults read > before

# GUI上で設定を変更する

$ defaults read > after
$ diff before after
# colordiff(brew install colordiff)などを使うと捗る

実際に探す一例

一例として、メニューバーに音量アイコンを表示する設定を探す。

プロパティリストを読む

GUIで設定する前後のプロパティリストを比較する。

$ defaults read > before
# GUIで設定変更
$ defaults read > after
$ diff before after
6504a6505
>         "NSStatusItem Visible com.apple.menuextra.volume" = 1;
6511c6512,6513
<             "/System/Library/CoreServices/Menu Extras/Bluetooth.menu"
---
>             "/System/Library/CoreServices/Menu Extras/Bluetooth.menu",
>             "/System/Library/CoreServices/Menu Extras/Volume.menu"

差分を見ると、6500行目あたりに設定項目がありそう。

実際にafterの6500行目以降の数行を見てみる。

     "com.apple.systemuiserver" =     {
         "NSStatusItem Visible com.apple.menuextra.airport" = 1;
         "NSStatusItem Visible com.apple.menuextra.battery" = 1;
         "NSStatusItem Visible com.apple.menuextra.bluetooth" = 1;
         "NSStatusItem Visible com.apple.menuextra.clock" = 1;
         "NSStatusItem Visible com.apple.menuextra.volume" = 1;
         "__NSEnableTSMDocumentWindowLevel" = 1;
         "last-analytics-stamp" = "608273612.570469";
         menuExtras =         (
             "/System/Library/CoreServices/Menu Extras/Clock.menu",
             "/System/Library/CoreServices/Menu Extras/Battery.menu",
             "/System/Library/CoreServices/Menu Extras/AirPort.menu",
             "/System/Library/CoreServices/Menu Extras/Bluetooth.menu",
             "/System/Library/CoreServices/Menu Extras/Volume.menu"
         );
     };

以上より、設定は次の内容を書き込めば良さそう。

ドメイン com.apple.systemuiserver 、キー NSStatusItem Visible com.apple.menuextra.volume に、値 1 を設定する。
ドメイン com.apple.systemuiserver 、キー menuExtra の値の配列に、 /System/Library/CoreServices/Menu Extras/Volume.menu を追加。

シェルスクリプトにまとめると次の通り。

#!/bin/bash -e

# 音量アイコンをMenuBarに表示
defaults write com.apple.systemuiserver \
  "NSStatusItem Visible com.apple.menuextra.volume" 1

defaults write com.apple.systemuiserver \
  menuExtras -array-add "/System/Library/CoreServices/Menu Extras/Volume.menu"

# メニューバーを再起動
killall SystemUIServer

プロパティリストに書き込んで試す

実際に試してみると、反映されていることがわかる。

なぜdefaultsコマンドを使うのか

メリット

設定を自動化できる

PCで新しく環境構築する際に、シェルスクリプトにまとまっているので一括で設定できる

自分が行っていた設定を記録できる。

自分がGUI上でどんな設定を行っているか、いたかをコードで示すことができる。アプリケーションがプロパティリストとしてデータを持っているならば、サードパーティアプリケーションでも同様に設定を記録できる。

たとえば、私はShiftItというアプリケーションを使っている。このアプリケーションで使うキーバインドはGUI上から設定するのだが、自分がどんな設定をしているのかをコードとして記録できるのは、再設定だけでなく今後のなんらかのキーバインド設定の参考にもなる。

参考: 私の現在のShiftItのキーバインド設定

デメリット

設定変更のたびに逐一調べてシェルスクリプトを更新しなければならない

これはたしかに面倒だけどね。プロパティリストをむやみに書き換えると、パソコンが上手く動かなくなる可能性もある。。

OSのアップデートによって設定が適用できなくなるかもしれない

GUIもアップデートで項目がなくなったりどこにいったかわからなくなったりするよね

まとめ

以下を使って頑張ってシェルスクリプトを書こう。

$ defaults read > before
# GUIで設定変更
$ defaults read > after
$ diff before after

$ man defaults

将来の自分へ

diffを読み取ってdefaultsコマンドのシェルスクリプト形式にするのは自動化できるのでは？と思ったが、先駆者がいたようだ

vim-lspを使った、Vim上でのTypeScript(JavaScript)の補完の実現

Wed, 01 Apr 2020 08:37:46 GMT

LSPとは

LSP(Language Server Protocol)とは、IDEと言語サーバとの通信用プロトコル。

IDEやテキストエディタが補完やコードジャンプなどの様々な機能を実現するために、以前はIDEやエディタのプラグイン内に内包されていた機能を、言語ごとにLanguage Serverとして切り出す。

これにより言語補完部分の製作はLanguage Serverさえ作ってしまえばたくさんのIDE(エディタ)に対応できるし、IDE(エディタ)開発側も、LSPにさえ対応してしまえば各言語への対応を独自実装しなくて済む。

2016年6月にMicrosoftが発表したらしい。

参考: language server protocolについて (前編) - Qiita

やること

今回はTypeScript,JavaScript用のLanguage Serverをインストールし、これをvim-lspにつないでvim上でLanguage Serverの支援が得られるようにする。

( vim-lspはvimでLanguage Serverを利用できるようにするプラグイン )

環境

macOS Mojave(10.14.6)
VIM 8.2 Compiled by Homebrew
dein.vimでプラグイン管理

Vim8上で、dein.vimにプラグインを読み込ませる。

手順

typescript-language-serverをインストールする

$ npm install -g typescript typescript-language-server
# または
$ yarn global add typescript typescript-language-server

typescript-language-serverはJavaScriptのLanguage Serverとしても動く

各種vimプラグインを入れる

dein.tomlに以下の記述を追記

# dein.toml

#========== vim-lsp とその関連プラグイン ==========
#vim-lspとLanguage Serverの連携に必要なプラグイン群
[[plugins]]
repo = 'prabirshrestha/async.vim'
[[plugins]]
repo = 'prabirshrestha/asyncomplete.vim'
[[plugins]]
repo = 'prabirshrestha/asyncomplete-lsp.vim'

# 事前にnpm install -g typescript typescript-language-server 
[[plugins]]
repo = 'prabirshrestha/vim-lsp'
hook_add = '''
" TypeScript, JavaScript
if executable('typescript-language-server')
    au User lsp_setup call lsp#register_server({
        \ 'name': 'typescript-language-server',
        \ 'cmd': {server_info->[&shell, &shellcmdflag, 'typescript-language-server --stdio']},
        \ 'root_uri':{server_info->lsp#utils#path_to_uri(lsp#utils#find_nearest_parent_file_directory(lsp#utils#get_buffer_path(), 'package.json'))},
"       \ 'root_uri':{server_info->lsp#utils#path_to_uri(lsp#utils#find_nearest_parent_file_directory(lsp#utils#get_buffer_path(), 'tsconfig.json'))},
        \ 'whitelist': ['typescript', 'typescript.tsx', 'javascript', 'javascript.jsx'],
        \ })
endif

" 他言語サーバの読み込みはここに挿入
'''

#vim-lspのキーバインドを設定
後で書く

vimを起動

$ vim

今日欲しい物(2020/3/30)

Mon, 30 Mar 2020 01:06:22 GMT

欲しい物

ほしいと思ったものの記録。

docomo系MVNOのSIM
60%の自作キーボード
ヘッドホン

docomo系のMVNOのSIM

昨年macを買ったのに合わせて初めてiphoneを購入し、それ以降iphone7を使い続けているが、そろそろandroidに戻りたい気持ちが強くなってきた。

ビッグローブの3GB音声通話有りのプランは、半年間400円で使えて2500円キャッシュバックが有るらしい。

iphone7に挿しているsimは最近UQmobileに乗り換えたばかりだし、UQmobileの回線速度は素晴らしいので、乗り換えるのは早計かなと思っている。

しかしUQmobileのsimが使える端末が手元にないので、とりあえずdocomo系のsimを契約して2台持ちにしようかと検討している。今、お金をほとんど使わずに不満を解消できるのが2台持ち。

しばらくしたらUQmobileでも使えるandroidを買うか、androidへ乗り換える夢を諦めるか、メインの回線をdocomo系のMVNOに乗り換えるかしよう。

以下はiphoneを一年弱使った感想。

生粋のandroid人間だったので、操作感など最初は中々慣れなかった。

iphoneの不満

オートメーションで位置情報による自動実行、WIFI接続時の自動実行が出来ない。

家の鍵(Sesami mini)を、帰宅/外出を自動検知しAPIを叩いて自動開閉をしたい。 androidならIFTTTで実現できそう。

OK googleしたい

スマホの音声操作は車を運転するときに真価を発揮する。

Googleマップの検索と案内開始、音楽再生をどちらも音声操作だけで完結できるのでGoogleアシスタントを使いたい。

夏、特にダイビングに行くときに車を運転するので、今後もっとandroidが欲しくなるはず。

(注:Siriは○ソ。使えない。自明。)

公式ストア外のアプリをインストールできない。

セキュリティ的には良いところなのだが。(一般向けのスマートフォンOSの戦略としては正解だと思う)

私には自由が必要なのだ、androidのような自由が。

iphoneのいいところ

テザリング時にスマホを操作しなくて良い

iphoneからmacへテザリングする際に、ポケットに入ったiphoneに指一本触れずにMac上からテザリングを有効化できる。Apple帝国に納税した分の福利厚生といったところか。

セキュリティが安心

政府要人でもないし抜かれる個人情報も大したこと無いけれど、国を敵に回してもiphoneには容易にはデータにアクセス出来なそう。 (ただし、端末内のデータにアクセスできないからと言って安全とは限らない。PCやWebサービスのデータベースの情報を抜かれるかもしれない)

60%の自作キーボード

ちょっと前はHHKBを狙っていたけれど、高いし、「あれ、俺がほしいのはHHKBではなくUS配列60%キーボードだ」と気づいた。

ここ1ヶ月ほどKarabinerでSandS(スペースバーを他キーと同時に押すとShiftキーとして扱う)を設定している。これに味をシメて、数字キーのShift動作を反転させて、普段は記号、Shiftキー(SandSなので実際はスペースバー)が押されているときは数字が入力されるようにしようとしていた。

こんなふうに配列をいじっていると、はたしてこのまま日本語配列でよいのかと思ってくる。 USキーボードの配列に慣れておいたほうがキーボードの選択肢が広がる(自作キーボードをするとき)し、かっこいい(厨2)(要出典)し、エンターキー押しやすそうだし、記号も自然な配列と聞くので、さっさとUSにしないと。

KBDfansを見ていると頑張って安いものを選べば1.3万円くらいでできそう。

自分への誕生日プレゼントとしてひとつ組んでみようかな。

ヘッドホン

5000円未満で音質が結構良いらしいヘッドホン、マランツプロ MPH-1。

今はSonyのXDR-XB950というヘッドホンを3年以上使っている。 bluetoothのヘッドホンは本当に素晴らしくて、無線は本当に快適。バッテリーも公称40時間持つとかで、最近のワイヤレスイヤホンとは比較にならないほど持つ。

ただ、音質はそこまで良くないと思う。bluetoothということで、ホワイトノイズも目立つ。

次買うならSonyかboseの4万円くらいするワイヤレスヘッドホンなのだけれど、高いのでおいそれと手が出ない。

そんなときに下を見つけた。ギズモード・ジャパンの網藤さんのブログで見つけた、5000円のヘッドホン。

アンダー5,000円のモニタリングヘッドホン「MPH-1」は脊髄で買っていいくらい高コスパ - MENBOU

この価格帯で推せるヘッドホンが有るのはアツイ。

2020年に有線ヘッドホンを買うかは迷いどころだけれど、机に座っているとき専用だったら有線でもまぁいいかな。

現状に困っているわけではないので、なんだかんだ買わない気もするけれど。

すぐやる人に変わる方法

Sat, 28 Mar 2020 02:52:38 GMT

2017年11月頃のメモを移動。以下、先送りせずにすぐやる人に変わる方法 (中経の文庫)を読んだ際のメモだと思われる。

優先度を比較する「前」にやってしまう
「快楽を捨てること」と「苦痛を選択する」ということの2つのことを一度にやろうとしてはダメまず「快楽を捨てる」ことだけに、全神経を集中
すぐに実行できるところまで分解するどんどん分解する癖がつけば自然と「すぐやる」人になれる
誘導タスクを設定する
メールは「下書き」をしておく
いまの状況を正直に伝える .. そういうときは、ざっと目を通して、簡単な感想を概ねポジティブに書いて出す
以下軽く目を通して考えてから採用すること
すぐやる人は肩の力が抜けている
やりたいことを増やさない
一気にやる快感に気をつける溜める量を減らしていく
締め切りが無くても動ける方法を探す自分で設定したデッドラインでできたという経験を多く持つ

仮想化

Sat, 28 Mar 2020 02:48:13 GMT

過去の自分向けメモを移動。以下、2019/4/27頃のメモである。

最近大学でOSの授業が始まった。

OSの基本的な役割として挙げられるのが、計算資源の管理とハードウェアの仮想化だそうな。

仮想化と聞くとVirtual Machineを使ったサーバー仮想化などあるが、それよりももっと前から仮想化という概念は存在していて。 CPUのハイパースレッディングテクノロジーなんかはCPUの仮想化。デバイスドライバを介した入出力機器の仮想化。ファイルシステムによりデータを抽象的に操作できるハードディスクの仮想化。アドレスを意識する必要のないメモリの仮想化。

仮想化といわれると、以前はエミュレータなんかに近いものを想像していた。

しかしOSがハードウェアを仮想化しているということを意識すると言葉のイメージが変わった。仮想化(=抽象化)というのは、カプセル化だったり、階層化という概念に近く、コンピュータの中でごく一般的に広く用いられている手法ではないか？

そこまで考えを広げたうえで、昨今のデータセンタ内の仮想化技術(サーバー、ストレージ、ネットワーク、、)は自然の流れとも言える。今まで使っていたハードウェアないしレイヤーを更に仮想的に(抽象的に、ソフトウェア的に)扱いやすくした、レイヤーが一層加わっただけである。

大学1年のとき、某企業でデータセンタに関するソリューション提案のインターンをした。そのときは仮想化どころかデータセンタに関する知識が少なくて学ぶことばかりでついていくのもやっとだったけれど、概念の理解は当時より進んだと思う。

さくらのVPSとdocker環境構築

Fri, 27 Mar 2020 18:10:34 GMT

PCを整理していて発見したメモを移動して公開する。ファイルのタイムスタンプは2017/12/19。

windows10のPCから、さくらVPSでCentOS7のサーバでdockerを使えるようにする記録。

windows10にはあらかじめputty,WinSCPがインストールされていることを想定。

さくらVPS初期設定

OSインストール

さくらVPS管理画面にて、> サーバ一覧 > (設定したいサーバ) > 各種設定 > OSインストール

OSインストール形式の選択: 標準OS
インストールするOSを選んでください: CentOS7 x86_64
rootパスワード: 適当に設定
スタートアップスクリプト: 利用しない

こんな感じでOSをインストールする。

一般ユーザーの作成

まず、さくらVPS管理画面にて、>サーバ一覧 >(設定したいサーバ) > _コンソール > _シリアルコンソール(β)版から操作。

sampleuserの作成

以下、sampleuserは適当に自分の作りたいユーザー名に置き換える。

#rootでログイン 
$ useradd sampleuser #ユーザー作成 
$ passwd sampleuser #パスワード設定

sampleuserがsudoできるようにする

$ visudo

visudoで/etc/sudoersを編集する。次の行のコメントアウトを外す。

## Allows people in group wheel to run all commands 
#%wheel  ALL=(ALL)       ALL 
↓ 
## Allows people in group wheel to run all commands 
%wheel  ALL=(ALL)       ALL

:wqで保存。

$ usermod -aG wheel sampleuser 
#ユーザーをwheelグループに追加 
 
$ exit 
 
$ login #sampleuserでlogin 
 
$ groups #自分の所属groupを確認 
sampleuser wheel 
 
$ sudo su #sampleuserでsudoできるか確認 
[sudo] password for sampleuser:{sampleuserのパスワード} 
 
$ whoami 
root

puttyからsshログインしてみる

putty.exeを起動。

>Session の Host Name : サーバのipアドレスorドメイン名
>Session の Port : 22
>Conection の Seconds to between keepalives(0 to turn off) : 30
(30秒ごとにnull文字が送信されることでしばらく操作が無くてもsshセッションが途絶えるのを防ぐ。)
>Session の SavedSessions : sakura_vps_session

Saveし、その後Openでssh接続できるか確認する。

セキュリティの強化

rootのsshログインを止める

$ vim sudo /etc/ssh/sshd_config

/etc/ssh/sshd_configを次のように編集する。

 #PermitRootLogin yes 
 ↓ 
 PermitRootLogin no

:wqで保存。

$ systemctl restart sshd #設定を反映させる

port番号変更とfirewall設定変更

sshポートを、標準である22から適当な値に変更する。ここでは2222に変更するが、セキュリティのためには各自適当な値を用いるべき。

$ sudo vim /etc/ssh/sshd_config

/etc/ssh/sshd_configを次のように編集する。

#Port22 
↓ 
Port2222

:wqで保存。

$ systemctl restart sshd #設定を反映させる

そして、sshの設定でポートを変更したのち、firewallの設定も変更しなければならない。。。 これに気づかず最初つまづいた。

$ cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/ssh.xml 
 
$ sudo vim /etc/firewalld/services/ssh.xml

firewallのデフォルト設定は/usr/lib/firewalld/にあるが、これは触らないこと。編集する場合は、/etc/firewalld/以下にファイルを置くと、その部分だけシステム設定が上書きされるようになっているので、こちらに書き込む。

/etc/firewalld/services/ssh.xmlを次のように編集する。

<port protocol="tcp" port="22"/> 
↓ 
<port protocol="tcp" port="2222"/>

:wqで保存。

$ firewall-cmd --reload #設定を反映させる

putty.exeでも、ポート設定を変更しておく。 sakura_vps_session をLoadし、Portを2222に変えてSave。puttyから接続できるか確認しておく。

公開鍵認証

puttygen.exeで公開鍵、秘密鍵のペアを作成する。 Generateボタンを押した後、カーソルをウィンドウ上でランダムに動かすと鍵が作成できる。 Key passphraseを任意のものに設定する。適当な場所に Save public key で sakura_rsa.pub として、Save private key sakura_rsa.ppk として保存。

公開鍵をサーバにアップロードする。 WinSCPで、新しいサイトから、

編集プロトコル:SFTP
ホスト名:にサーバのipアドレスorドメイン名
ポート番号:2222
ユーザ名:sampleuser
パスワード:(sampleuserのパスワード)

として保存、ログインする。 WinSCPでは画面左側にローカルの、画面右側にサーバのファイルが表示されており、ドラッグアンドドロップで相互に転送できる。先ほどのサーバの/home/sampleuser に先ほどの sakura_rsa.pub (公開鍵だけ)を転送する。

サーバに公開鍵を登録する。

$ login #sampleuserでloginする 
 
$ ssh-keygen -i -f sakura_rsa.pub >> authorized_keys #puttygen.exeで作成した公開鍵の形式を変換 
 
#/home/sampleuser/.ssh/にauthorized_keysを設置し、適切なユーザ権限を与える 
$ mkdir .ssh 
$ chmod 700 .ssh 
$ mv authorized_keys .ssh 
$ chmod 600 .ssh/authorized_keys 
 
$ rm -f sakura_rsa.pub #変換前の公開鍵を削除

puttyに秘密鍵を登録する。

putty.exeで sakura_vps_session を Loadし、>Conection>SSH>Auth の Private key fire authentication にsakura_rsa.ppk(秘密鍵)を設定する。 >Sessionから設定の変更をSaveする。その後puttyで接続できるか確認。鍵を作成したときのパスフレーズをここで入力する必要があるはず。問題なく接続できれば、晴れて公開鍵認証でssh接続できている。

パスワードログインの無効化をする。公開鍵認証でログインできても、まだ従来のパスワードによるログインもできるのでセキュリティ向上にはなっていない。従来のパスワードによるログインを無効化する。

$ vim sudo /etc/ssh/sshd_config

/etc/ssh/sshd_configを次のように編集する。

#PasswordAuthentication yes 
↓ 
PasswordAuthentication no

:wqで保存。

$ systemctl restart sshd #設定を反映させる

docker構築

dockerのインストール

$ sudo yum update 
$ sudo yum install docker-io 
#dockerのインストール 
 
$ sudo systemctl start docker 
#無事インストールされたか確認する 
$ sudo docker info 
#インストールされていればつらつら現在の状況が表示される

sampleuserがdockerを使えるようにする

$ sudo groupadd docker #dockerグループの作成 
$ sudo gpasswd -a sampleuser docker 
#sampleuserをdockerグループへ追加 
 
$ sudo systemctl restart docker 
#dockerデーモンの再起動 
 
$ docker info 
#sampleuserで動くことを確認

Moby Dockを表示してみる

$ docker run docker/whalesay cowsay 'Congrats!!!'

参考文献

CentOSでuserをsudo可能にする:
https://qiita.com/Esfahan/items/a159753d156d23baf180
CentOS7のfirewalldでsshのポート番号を変更する方法:
https://qiita.com/DQNEO/items/5780d81b2e0af4cc1544
PuTTYで公開鍵認証方式でのSSH接続を行う手順まとめ:
https://qiita.com/sugar_15678/items/55cb79d427b9ec21bac2
VPSにdocker環境構築:
https://qiita.com/t-mimura/items/c206d46f3af771292f89

お名前.comで取得したドメインをさくらVPSで使う。

Fri, 27 Mar 2020 18:03:08 GMT

PCを整理していて発見したメモを移動して公開する。ファイルのタイムスタンプは2017/12/19。

お名前.comで取得したドメインをさくらVPSで使う。DNSサーバーはさくらのものを利用する。

お名前.com側の設定

> ドメイン > ドメイン設定 > ネームサーバーの設定 > ネームサーバーの変更

目的のドメイン名にチェックを入れて登録情報は正しいので、手続きを進めるをクリック。

他のネームサーバーを利用のタブにして

1プライマリネームサーバー(必須) : ns1.dns.ne.jp
2セカンダリネームサーバー(必須) : ns2.dns.ne.jp

として確認画面へ進み、設定を適用する。

これでネームサーバーはさくらインターネットのものが使われる

さくらVPS側の設定

> さくらのVPSコントロールパネル > ネームサーバ登録

ドメイン名:example.com (目的のドメイン名) 送信するをクリックして設定を適用する。

> 会員メニュー > ドメイン > 管理ドメインとネームサーバの一覧
にてドメイン名:example.comのゾーン編集をクリック左側の変更から

エントリ名: 空欄
種別: IPアドレス(A)
値: 192.0.43.10 (サーバのIPアドレス)
DNSチェック: する
TTLの指定: (チェックしない)

として新規登録

もう一度
> 会員メニュー > ドメイン > 管理ドメインとネームサーバの一覧
にてドメイン名:example.comのゾーン編集をクリックし、左側の変更から

エントリ名: www
種別: 別名(CNAME)
値: @
DNSチェック: する
TTLの指定: (チェックしない)

として新規登録

以上で完了となる。

androidの架電アプリによる各種制御プログラムの起動

Fri, 27 Mar 2020 17:45:25 GMT

まえがき

PC内のデータを整理していたら過去に自分向けに書いていたメモが出てきたので、ここ記す形で移動する。タイムスタンプをみるに、2017/11/22頃に書かれたものだ。

androidでは、端末の細かい挙動の設定を変更する際、電話アプリで以下に有るようなコマンドを打ち込むと行えることがある。

過去のメモなので、どの機種、環境だと利用できるのか確認していないが、少なくとも SOL26で利用できそうである。

メモ

Open Android Mobile Programs Using Commend  
 
 Commands               Usages 
 
*#06# = IMEI Android serial number 
 
*#8999*523# = LCD Brightness 
*#1234# = To check Software and Hardware information, PDA, CSC,MODEM. 
 
*#2222# = it will open H/W Version 
*#*#4636#*#*= user statistics and Phone Info 
*#0011# = Displays status information for the GSM 
*2767*3855# = Full factory reset (Don’t dial unless you have problem, it does not ask you to confirm) 
*#12580*369# = SW & HW Info 
#*#8377466# = S/W Version & H/W Version 
#*5376# = DELETE ALL SMS!!!! 
*#197328640# = Service Mode 
*#0228# = Battery status (ADC, RSSI reading) 
*#32489# = Service mode (Ciphering Info) 
*#2255# = Call List 
#*3888# = BLUETOOTH Test mode 
#*7828# = Task screen 
*#5282837# = Java Version 
*#232331# = Bluetooth Test Mode 
*#232338# = WLAN MAC Address 
*#232339# = WLAN Test Mode 
*#8999*8378# = Test Menu 
*#0842# = Vibrate Motor Test Mode 
*#0782# = Real Time Clock Test 
*#0673# = Audio Test Mode 
*#0*# = General Test Mode 
*#2263# = RF Band Selection / Network modes select 
*#9090# = Diagnostic Configuration 
*#7284# = USB I2C Mode Control 
*#872564# = USB Logging Control 
*#4238378# = GCF Configuration 
*#0283# = Audio Loopback Control 
*#1575# = GPS Control Menu 
*#3214789650# = LBS Test Mode 
*#745# = RIL Dump Menu 
*#746# = Debug Dump Menu 
*#9900# = Takes you to System Dump, where Disabling Fast Dormancy gives a boost to your network speed on some networks (both Wi-Fi and Gpr), same code to re-enable it 
*#44336# = Software Version Info 
*#0289# = Melody Test Mode 
*#2663# = TSP / TSK firmware update 
*#03# = NAND Flash S/N 
*#0589# = Light Sensor Test Mode 
*#0588# = Proximity Sensor Test Mode 
*#273283*255*3282*# = Data Create Menu 
 
*#7594# = Remap Shutdown to End Call TSK 
*#7465625# = View Phone Lock Status 
*7465625*638*# = Configure Network Lock MCC/MNC 
#7465625*638*# = Insert Network Lock Key code 
*7465625*782*# = Configure Network Lock NSP 
#7465625*782*# = Insert Partial Network Lock key code 
*7465625*77*# = Insert Network Lock key code SP 
#7465625*77*# = Insert Operator Lock key code 
*7465625*27*# = Insert Network Lock key code NSP/CP 
#7465625*27*# = Insert Content Provider key code 
*#272*IMEI# = then we will get buyer code (For Samsung galaxy six code) 
*#*#7780#*#* = Factory data reset – Clears Google-account data, system and program settings and 
 
*2767*3855# = Format phone 
 
The Most Useful Cods on Android Mobile 
– Disables Network Lock : #7465625*638*00000000# 
– Disables SIM Lock : #7465625*746*00000000# 
– Disables SP lock : #7465625*77*00000000# 
– Disables Subset Lock : #7465625*782*00000000#

参考: http://www.commandshow.com/open-android-programs-using-command/

shellでhistoryを使う

Wed, 25 Mar 2020 15:13:29 GMT

過去に実行したコマンドを再度実行する

history ... unix系OSでshellに存在する組み込みコマンドだ。

過去に実行したコマンドを表示できる。

historyコマンドで表示されたコマンドの番号を!と合わせて入力すると、そのコマンドを実行できる。

$ history
  1  ls
  2  pwd
  3  cd /etc
$ !1
ls
hogedir/    fugafile

以下のようにして全履歴を表示できる。

出力した後はgrepで煮るなり焼くなりするのが良いかと。

$ history -E 1
# 履歴を全て表示する

.zshrcでの設定

.zshrcでhistoryに関する設定をしておく

# .zshrc
HISTSIZE=50000 # メモリに保存するコマンド数
HISTFILE=~/.zsh_history
SAVEHIST=100000 # ヒストリファイルに保存するコマンド数

alias history="history -i"
function history-all { history -E 1 }

# 重複するコマンド行は古い方を削除
setopt hist_ignore_all_dups
# 直前と同じコマンドラインはヒストリに追加しない
setopt hist_ignore_dups
# コマンド履歴ファイルを共有する
setopt share_history
# 履歴を追加 (毎回 .zsh_history を作るのではなく)
setopt append_history
# 履歴をインクリメンタルに追加
setopt inc_append_history
# ヒストリを呼び出してから実行する間に一旦編集可能
setopt hist_verify
# 余分な空白は詰めて記録
setopt hist_reduce_blanks
# historyコマンドは履歴に登録しない
setopt hist_no_store

Ubuntuをダウンロードしてインストールする

Sat, 21 Mar 2020 14:18:47 GMT

Download

Ubuntu Desktop 日本語 Remixをダウンロードする

Torrentを利用するために、uTorrent classicを使用した。ただし、catalinaがサポート外と書かれていたのでもしかしたら32bitアプリケーションかもしれない。 Torrentについては別途要検討

Check

macでは次のようにしてmd5ハッシュを確認できるダウンロードページのhashと比較して、ダウンロードが正しく行われたことを確認する

$ md5 -q path/to/file
# manによると、-qオプションはQuiet modeらしい。md5ハッシュのみ出力する。
# ので、次のように比較するのが良いかな

$ md5 -q path/to/file | diff hash/text/file/path -
# diffの第二引数"-"は、標準入力の意

Copy

# Convert iso to img
$ hdutil convert -format UDRW -o hoge.img hoge.iso
$ mv hoge.img.dmg hoge.img

# USBメモリの確認
$ diskutil list

# Mountされていたら
$ diskutil unMountDisk path/to/device
# ex)  $ diskutil unMountDisk /dev/disk1

$ sudo dd if=hoge.img of=path/to/device bs=1m

$ sudo diskutil eject path/to/device

dein.vimの導入

Mon, 16 Mar 2020 15:13:35 GMT

dotfiles環境下でvimのプラグイン管理にdein.vimを導入する。

前提

~/dotfilesで.vimrcを管理している
dein.vimも~/dotfilesで管理する

下準備

$ cd ~/dotfiles
$ mkdir dein
$ touch dein/load.vim

.vimrcに追記

~/dotfiles/.vimrcの先頭に次を記載

" .vimrc

"===== dein.vim =====
if filereadable(expand('dein/load.vim'))
    source dein/load.vim
endif

load.vimに記述

~/dotfiles/dein/load.vimに次の内容を記述

" ~/dotfiles/dein/load.vim

"""===== dein.vim ======

"dein.vim dark power
let s:dein_dir = expand('~/dotfiles/dein')
" s:dein_dirとg:rc-dirは一致させること。dein.tomlとdein-lazy.tomlをtouchしている
"
let s:dein_repo_dir = s:dein_dir . '/repos/github.com/Shougo/dein.vim'

set nocompatible
" dein.vim をインストールしていない場合は自動インストール
if !isdirectory(s:dein_repo_dir)
  echo "install dein.vim..."
  execute '!git clone git://github.com/Shougo/dein.vim' s:dein_repo_dir
  execute '!touch -m ' . s:dein_dir . '/dein.toml'
  execute '!touch -m ' . s:dein_dir . '/dein_lazy.toml'
endif
execute 'set runtimepath^=' . s:dein_repo_dir

"---------------------------
" Start dein.vim Settings.
"---------------------------

if dein#load_state(s:dein_dir)
  call dein#begin(s:dein_dir)

  let g:rc_dir    = expand('~/dotfiles/dein')
  let s:toml      = g:rc_dir . '/dein.toml'
  let s:lazy_toml = g:rc_dir . '/dein_lazy.toml'

  " TOMLファイルにpluginを記述
  call dein#load_toml(s:toml,      {'lazy': 0})
  call dein#load_toml(s:lazy_toml, {'lazy': 1})

  call dein#end()
  call dein#save_state()
endif

" 未インストールを確認
if dein#check_install()
  call dein#install()
endif

"---------------------------
" End dein.vim Settings.
"---------------------------

vimを起動

.vimrcの記述により、vim起動によりdein.vimがinstallされる。 (ただし、gitが必要)

参考

yammerjp/dotfiles -GitHub

Shell Scriptにおける、カレントディレクトリの固定

Mon, 16 Mar 2020 13:23:27 GMT

前提

shell script内では、shell scriptを起動する前のカレントディレクトリが引き継がれる。

例えば、次のようなpwd.shを実行する。

#!/bin/sh
pwd

次のように、shell scriptを呼び出す際のカレントディレクトリにより、shell scriptの挙動が変化する。

$ pwd
/Users/hoge

$ ls -F
pwd.sh*   dir/

$ sh pwd.sh 
/Users/hoge

$ cd dir
$ sh ../pwd.sh
/Users/hoge/dir

解決策

shell scriptの前方に、2行追加する。

#!/bin/sh

# change directory to the shell file's directory
SCRIPT_DIR=`dirname $0`
cd $SCRIPT_DIR

pwd

これにより、shell scriptを呼び出す際のカレントディレクトリに関わらず、shell scriptでのカレントディレクトリが、shell scriptが配置されたディレクトリに固定される。

$ pwd
/Users/hoge

$ ls -F
pwd.sh*   dir/

$ sh pwd.sh 
/Users/hoge

$ cd dir
$ sh ../pwd.sh
/Users/hoge

その他の解決策

shell script内のpathを、"$HOME"などの変数を使って絶対パスで記載する。

まとめ

以下のテンプレートをshell scriptの先頭に追加すると良い。

#!/bin/sh
SCRIPT_DIR=`dirname $0`
cd $SCRIPT_DIR

追記 (2020/03/19)

$SCRIPT_DIRにフルパスを格納するなら以下の通り

SCRIPT_DIR=$(cd $(dirname $0); pwd)
cd $SCRIPT_DIR

hexoによる静的サイトの構築

Mon, 16 Mar 2020 00:09:00 GMT

Hexoによる静的サイトの構築

Hexoは、node.jsを使った静的サイトジェネレータ。

markdown形式の記事を静的サイトに簡単に公開できる。

Hexoの導入

$ npm install hexo-cli
$ npx hexo init ../memo.yammer.jp 
$ cd ../memo.yammer.jp
$ npm install
$ hexo server
# ローカルでサイトの確認

Hexoの設定について

設定は基本的に_config.ymlに書き込む。

例えば、このサイトの_config.ymlが一例。

テーマの導入

Hexoはサードパーティで公開された様々なテーマを導入できる。

公式サイトのテーマ一覧にあるように、様々なものが選べる。

今回はair-cloudを導入した。

$ git clone https://github.com/aircloud/hexo-theme-aircloud.git theme/air-cloud

テーマ特有の設定は、Demoの_config.ymlが参考になる。

特別なページの設置

自己紹介ページの追加

$ npx hexo new page about

source/about/index.mdを次の内容に編集する。

---
layout: about
title: About Me
date: "2020-03-16 11:22:00"
---

## About Me

yammerjpの雑多なメモ。

- twitter: [@yammerjp](https://twitter.com/yammerjp)
- GitHub: [@yammerjp](https://github.com/yammerjp) 
- [blog](https://blog.yammer.fun)

タグページの追加

次のコマンドで、tagページを作る

$ npx hexo new page "tags"

source/tags/index.mdを次のように書き換える

---
title: All tags
type: "tags"
---

検索機能の追加

$ npm i hexo-generator-search --save

_config.ymlに次の内容を記載する

# _config.yml
search:
  path: search.json
  field: post

I\記号	+	*	(	)	i	$	E	T	F
0			s5		s4		1	2	3
1	s6
2	r2	s7		r2		acc
3	r4	r4		r4		r4
4	r5	r5		r5		r5
5			s5		s4		8	2	3
6			s5		s4			9	3
7			s5		s4				10
8	s6			s11
9	r1	s7		r1		acc
10	r3	r3		r3		r3
11	r6	r6		r6		r6

I\記号	(	)	,	a	$	S	L
0	s1			s2
1	s1			s2		6	3
2	r2	r2	r2	r2	acc
3		s4	s5
4	r1	r1	r1	r1	acc
5	s1			s2		7
6	r4	r4	r4	r4
7	r3	r3	r3	r3

I\記号	+	*	(	)	i	$	E	T	F
0			s5		s4		1	2	3
1	s6
2	r2	s7		r2		acc
3	r4	r4		r4		r4
4	r5	r5		r5		r5
5			s5		s4		8	2	3
6			s5		s4			9	3
7			s5		s4				10
8	s6			s11
9	r1	s7		r1		acc
10	r3	r3		r3		r3
11	r6	r6		r6		r6

I\記号	(	)	,	a	$	S	L
0	s1			s2
1	s1			s2		6	3
2	r2	r2	r2	r2	acc
3		s4	s5
4	r1	r1	r1	r1	acc
5	s1			s2		7
6	r4	r4	r4	r4
7	r3	r3	r3	r3

memo.yammer.jp

トイカメラで、写真の荒さを楽しむ

トイカメラを買った

近況

画像の投稿場所

締め

メール送信者認証技術の整理

メール送信者認証技術はなぜ必要なのか？

SMTPで送信元を表すのは、IPアドレス、エンベロープFrom、ヘッダFrom

SMTP上でエンベロープFromとヘッダFromを検証する仕組みはない。どのメールを受け取るかは受信者が決める

大手の受信者が公開しているポリシーに、送信側は実質的に従う必要がある2

個々のメール送信者認証技術

DNSレコードに書かれていることは、ドメインの所有者の意思で書かれているはず

SPF (passならば、エンベロープFromのドメイン所有者が認めたIPアドレスのサーバから送られたとわかる)

DKIM (passならば、署名したドメインの所有者がそのメール内容を送信したとわかる)

DMARC

アライメント

ポリシー

BIMI

メール技術のキャッチアップ

Footnotes

GMO Developers Day 2024に登壇した

GMOペパボ EC事業部CTOに就任しました

事業部CTOとは

やっていき

お隣さん

お誘い

Footnotes

財務3表一体理解法を読んだ(2024年8月)

はじめに

印象に残ったこと

前提

財務3表の関係

そのほか印象に残ったこと(メモ)

身近な会計

おわりに

Footnotes

私と技術カンファレンス 2023 (雑文)

ISUCONに初めて参加した(2023年12月)

やったこと

前日まで

当日午前

当日お昼頃

当日夕方

振り返り

よかったこと

改善したいこと

おわりに

チームが気付き、変化する

Footnotes

人月の神話を少し読む

Footnotes

エンジニアのためのマネジメントキャリアパスを読む

部下としての心得

メンターとしての傾聴

テックリードに求められるプロジェクト管理のスキル

文化の構築

dotfiles管理の推しツール「yadm」の記事を寄稿しました (Software Design 連載最終回)

yadmについて / 記事の紹介

連載について

おわりに

Footnotes

LlamaIndexを使って、gawkプログラミングの相棒を作る

LlamaIndexとは

gawk-rubber-duck

作り方

インデックスの作成

Webアプリケーションにする

感想

awkで実装するUnion-Findと、ABC177 D

Union-Findとは

Union-Findのawk実装

Union-Findのawk実装を実行してみる

ABC177 D問題を解く

Footnotes

OpenAI API Embeddingsを使った、関連記事の表示・検索

構成

要素技術とロール

OpenAI API Embeddings

Pinecone API

大手の受信者が公開しているポリシーに、送信側は実質的に従う必要がある²

ターミナルをカスタマイズする Software Design連載開発環境探求の道第3回

シェルをカスタマイズする Software Design連載開発環境探求の道第2回

開発環境探求の道

連載「最強の開発環境探求の道」をSoftware Designではじめます

日報インターネット出張公開版

I\記号	+	*	(	)	i	$	E	T	F
0			s5		s4		1	2	3
1	s6
2	r2	s7		r2		acc
3	r4	r4		r4		r4
4	r5	r5		r5		r5
5			s5		s4		8	2	3
6			s5		s4			9	3
7			s5		s4				10
8	s6			s11
9	r1	s7		r1		acc
10	r3	r3		r3		r3
11	r6	r6		r6		r6

I\記号	(	)	,	a	$	S	L
0	s1			s2
1	s1			s2		6	3
2	r2	r2	r2	r2	acc
3		s4	s5
4	r1	r1	r1	r1	acc
5	s1			s2		7
6	r4	r4	r4	r4
7	r3	r3	r3	r3