Raspberry Pi の ヘッドレス インストール
久しぶりに家に眠ってた Raspberry PI で遊んでみたくなったので、 2022年度版のインストールを備忘録として残そうかと思います 自分の用途的にはGUIは不要なのでキーボード、モニターレスな環境でヘッドレス インストールしています。今回もこのやり方で進めます。 用意したもの Micro SD Card 16GB Raspberry Pi 3 Model B MacBook Pro SDカードリーダー USBキーボードとHDMI端子のあるモニタは、トラブルがあったときには便利ですが今回は無くても何とかなりました。 Raspberry Pi Imagerのインストール まずは Raspberry Pi に OS を入れる必要があるので、www.raspberrypi.com から Raspberry Pi Imager をダウンロードし Mac にインストールします。 SDカードに Raspberry Pi OS をインストール 今回は Raspberry Pi 3 Model B で 64bit に対応してるので以下の構成で Raspberry Pi OS を用意していきます。 Wikipedia の Raspberry Pi に主な仕様がまとめられているので確認する際に便利です。 今回のインストールで要点となるのは以下の箇所です。 Raspberry Pi OS Lite (64bit) ホスト名指定 SSH有効化 Wi-Fi有効化 次に Mac Raspberry Pi Imager を起動します。 起動するとシンプルなUIが表示されます。 最初に OS と保存するストレージを選択します。 Operating System Raspberry Pi OS Lite (64bit) を選択 Storage SDカードを選択 次に細かいカスタマイズをするため、歯車アイコンのボタンを押して Advanced options のウィンドウを開きます。 Set hostname には 任意の名前を入れます。今回は satoruk-rp3b.local にしました。 Enable SSH は Allow public-key authentication only を選択して、 Set authorized_keys for pi に公開鍵を指定します。 Set username and password には Username 任意のユーザ名かpi, Password 任意のパスワードを入れます。 Configure wireless LAN には 接続したい WiFi の SSIDとパスワードを入れます。この時 Wireless LAN countryも指定します。日本国内での利用であれば JP となります。 Set locale settings には、使用するTZとキーボードレイアウトを指定します。 設定を確認した後、問題がなければ SAVE して WRITE ボタンでSDカードに書き込みます。 Raspberry Pi OS の起動確認 OS をセットアップした SDカード を Raspberry Pi へ挿して、電源供給をするUSBを繋ぎます。 しばらくしてから、設定したネットワークで ssh 接続を試してみます。 今回の例だと以下のようなコマンドで接続できます。 ssh pi@satoruk-rp3b.local この時どうしても繋がらない場合は、複数Wi-Fiがある場合は、別のSSIDも試してみると繋がることがあります。実際に 5GHz(a)に繋ごうとした場合、繋がらず 2.4GHz(g)に繋いだらアッサリと繋がりました。 今回は以上です。
ブログ大賞、始めました。
こんにちは。最近ジムに通い始めた浅野です。毎日筋肉痛との戦いです。 そんな私ですが、昨年からブログ推進係に任命され、このブログを盛り上げていく、というお仕事もしています。 活動のゴールとしては、「みんなが自主的にブログ投稿できる文化を作ること」で、そうなるような仕組みを考え、実践しています。ブログ投稿を強制するのではなく、あくまで自主性を尊重していることにWYRDらしさを感じます。 そんなブログ推進活動の一環として、今年から「ブログ大賞」を始めてみました。いくつかの部門を作り、その中で1位となった人または記事を表彰しようというものです。(そのまんま)どの部門でも豪華な賞品が出るので、少しでもみんなのモチベーションになればいいな〜なんてことを考えています。 表彰対象としては、こんな感じです。 最多記事投稿者(上期/下期) 社内投票で最も票を集めた記事(tech系/tech系以外) アクセス数が最も多かった記事 最多記事投稿者は、半期に分かれているので、もう来月には結果が出てしまいます。早い...記事のレベルやクオリティは関係ないので、経験年数の浅い若手にもチャンスがあり、個人的には穴場だな〜と思っています。ただし文字数制限があり、規定に満たないと1記事としてみなされないといった条件があるので、要注意です。(実はこの記事でもなんとかクリアしようと奮闘中です。) 社内投票で最も票を集めた記事に関しては、年末に社内で投票会を行う予定です。tech系/tech系以外に分かれているので、エンジニア以外の人でも大賞を狙えます。 アクセス数が最も多かった記事に関しては、このブログを見ているあなたの1アクセスが結果を左右します！選定方法としては、Googleアナリティクスを使う予定です。ちなみに、2021年のアクセス数第1位はこの記事でした。 今年は誰がどの大賞をとるんでしょうか!今から楽しみです!
WYRDに3Dプリンタがやってきた
お久しぶりです。豊田です。 40歳を目前にして、謎の肩の痛みと腰痛に襲われ、最近やっと治ってきました。 今年は前厄なので、これ以上災難に遭わず平和に過ごせることを願ってます。 エンジニア支援制度を使ってみた WYRDには「エンジニア支援制度」という、他の会社にはあまりない（と思う）制度があります。 これは 「年間5万円を上限に、エンジニア活動への投資を会社が補助してくれる」 制度です。 勉強のための書籍購入や、AWSなどのクラウドサービスの利用料金など、金銭的な理由でエンジニアが成長機会を逃すことのないように。という目的から導入されています。 今回はこの制度を利用して3Dプリンタを購入したので、それをブログにしようと思います。 3Dプリンタの選定 最近はホビー用途のプリンタも多数販売されていますので、性能・価格の両面で選定を進めました。 性能 性能面は以下のポイントを重視しました 整形がキレイ 使えるフィラメントの種類 騒音（稼働音） 整形については、新しいモデルほど精度が高くなっている感じなので、自ずと発売時期が最近のモデルがターゲットになります。 フィラメントについては、ひとまず一般的な PLA, ABS, PC, PET あたりが使えればよさそうです。（細かいことは使ってみないとわからないので） 騒音（稼働音）についても実際に使ってみないとわからないことが多いですが、ひとまずボックスタイプのものがよさそうです。 価格 今回は「エンジニア支援制度」を利用しますが、私1人だと上限5万円なので、社内で2人の同志を集めました。これで15万円までなら選択肢に入れることができます。 性能を第一優先にしつつ、価格が予算の範囲に収まるように選定を進めた結果、 FLASHFORGE Adventurer4 を購入することに決定！ お値段 96,800円！！（個人では絶対買わない） 開封の儀 昨今の半導体不足などの影響もあってか品薄状態が続いていたようで、注文から1ヶ月以上経ってやっと届きました。 めちゃめちゃデカイです。1m四方くらいで、当然ですがそこそこ重さもあります。（25キロくらい？） 早速開封していきます。 しっかり緩衝材なども入っていて、丁寧な梱包の印象。 取手がないので結構取り出しにくいです。 落としたら大変なので、やむ無く箱を切って取り出せるようにしました。 取り出したのがこちら。デカイ。 続いてセッティングしていきます。 フィルムなどを取り払っていきます。 嬉々としている姿は、まるでおもちゃを与えられた子供のようです。 こういう時の手の速さは、さすがとしか言いようがない。 付属品としてフィラメント1kgがついてくるので、これをセットしていきます。 セット完了！ それでは電源を入れてみます... 無事起動もできました！ 初期不良とかなくてよかったー プリントしてみる 3Dプリンタの購入検討段階から、社内で3DCADソフト（Fusion360）を使ったモデリングの勉強会を行ってきました。 プログラミングとはまた違う技術を駆使するので、大変ですが面白いですね。 今回はサクッと作った弊社のロゴを印刷してみます。 会社のロゴ→ ラフト（台座）をプリントしてます。 心配していたフィラメントの匂いは、（素材によるところはあると思いますが）ほとんど無く、稼働音も思っていた以上に静かです。 内部がハニカム構造になっていて、ある程度の強度も期待できそう。 約1時間で印刷終了。 少し糸を引いてるところはありますが、概ねキレイな感じです。 ラフトを剥がして、細かい部分を整えたら完成です。 なかなかキレイにできてますね。 せっかくなのでオフィスのエントランスに飾ってみました。 使ってみた感想 ネットでの評判も上々だったAdventurer4ですが、実際に使ってみるとやはり使いやすい印象でした。 タッチパネルのUIも日本語に対応していますし、印刷時間やヘッドの温度なども細かく表示してくれて、マシンを使ってる感を味わうことができます。 同一ネットワークに接続すれば、印刷を遠隔実行できます。 仕上がりもキレイですし、個人的には選定は成功だったと思います。 気になったところ 筐体がデカイ 個人ユースの場合は置き場所に困る可能性がありそうです。 その分大きなものを印刷できるというメリットもありますので、作りたいものと相談ですね。 遠隔カメラが残念（らしい） 実際に使ってみた人が言うには、あまり期待できないとのことでした。 私はあまり気にしないですが。 印刷時間が長い これはAdventurer4に限った話では無いのですが、今回の印刷で1時間くらいかかったので、大きなものや密度の高いものを印刷する場合は、印刷時間を覚悟する必要があります。 まとめ 今回初めて3Dプリンタを実際に触ってみましたが、立体物を作れるというこれまでにない体験はかなり新鮮でした。 こういう体験を会社の制度を使ってできるのはありがたいことです。 まだまだわからないことも多いですが、もっとAdventurer4を使い込んで、色々作ってみたいと思います！（田んぼIoTで使えるケースなども作ろうと思ってます）
AWS CloudFrontのポリシーとは？
こんにちは、小林です。 みなさん、GWはどのように過ごしましたか？ 私は信州に旅行に行きましたが、電車やバスの時間を調べておらず、2日で30km歩くという苦行を課すことになってしまいました。。。 さて、今回もAWS関連のブログを書きましたので、よろしくお願いします。 はじめに 2020年12月ごろに初めてCloudFrontを使用しました。 その際にキャッシュをLegacy cache settingsを使用して、設定していました。 キャッシュの設定は、ビヘイビアごとに設定する必要があるにもかかわらず、同じ設定を複数の箇所に指定するのはとても手間がかかりました。 さらにその1年後にキャッシュの設定を確認したところ、当時設定した内容と異なっていることに気づきました。 これらの解決策を調べていたところ、以下のブログを見つけました。 Amazon CloudFront キャッシュポリシーとオリジンリクエストポリシーを発表 なぜ、設定内容が変更されてしまったのかはわかりませんでしたが、「ポリシー」を利用することで冗長な設定が不要になり、設定も楽になりました。 このブログは2020年7月に公開になったもので、よく調べていれば、苦労することなく構築できたのかもしれません。(反省) 今回はそのポリシー、特にキャッシュポリシーとオリジンリクエストポリシーについて紹介します。 ※CloudFrontを使用したことがある人を対象としているため、ポリシー以外の説明は省略しています。 CloudFrontポリシー CloudFrontイベント ポリシーの話をする前に少しCloudFrontのイベントの話をします。 CloudFront全体での正式な名称なのかが曖昧ですが、クライアント-ディストリビューション-オリジン間でのリクエスト/レスポンスの名称として、以下が定義されています。 クライアント-ディストリビューション間・・・ビューワーリクエスト/レスポンス ディストリビューション-オリジン間・・・オリジンリクエスト/レスポンス 参考：Lambda@Edge 関数をトリガーできる CloudFront イベント ※Lambda@Edge関数としては、マニュアルが用意されていますが、それ以外では見つかりませんでした。しかし、CloudFront全体で使用されている言葉だと感じています。 CloudFrontポリシー CloudFrontでは、以下の3種類のポリシーが用意されています。 キャッシュポリシー ビューワーリクエスト時に使用する キャッシュの条件に含める値を指定する オリジンリクエストポリシー オリジンリクエスト時に使用する オリジンリクエストに含める値を指定する ビューワーレスポンスポリシー ビューワーレスポンス時に使用する ビューワーレスポンスに追加するHTTPヘッダーを指定する 参考：ポリシーの使用 キャッシュポリシー キャッシュポリシーでは、2つの設定を行うことが可能です。 キャッシュの条件 キャッシュの有効期限 キャッシュの条件 HTTPヘッダー、Cookie、クエリ文字列によって、キャッシュの条件を指定します。 上記の設定では以下の値が全て一致する場合にキャッシュされている内容をレスポンスとして返却することになります。 HTTPヘッダーに含まれるUser-Agentの値 cookieに含まれるsampleの値 リクエストクエリ文字列に含まれるnameの値 参考：キャッシュキーについて キャッシュの有効期限 キャッシュの有効期限は複雑な条件分岐によって決定します。 (ここでは省略しますので、公式ドキュメントを参考にしてください) 参考：コンテンツがキャッシュに保持される期間 (有効期限) の管理 オリジンリクエストポリシー キャッシュミス(キャッシュされていない)した場合に、オリジンリクエストに送信する値を設定します。 デフォルトで以下の値が含まれます。 URLパス(ドメイン名、クエリ文字列を含まない) リクエストボディ CloudFrontがオリジンリクエストに自動的に含めるHTTPヘッダー Host、User-Agent、X-Amz-Cf-Id、etc また、上記に加えてキャッシュポリシーに指定した内容は、オリジンリクエストに含まれます。 上記のオリジンリクエストポリシーがあり、以下のリクエストをした場合 curl -H 'User-Agent: sample_agent' -b 'sample=true' -d 'sample=false' -d 'name=kobayashi' -d 'age=30' https://example.com キャッシュポリシーの設定により、オリジンに送信されるもの HTTPヘッダーのUser-Agent cookieのsample クエリ文字列のname オリジンリクエストポリシーの設定により、オリジンに送信されるもの クエリ文字列のage 参考：オリジンリクエストの制御 感想 冒頭で書いた通り、設定が冗長ではなくなったので、管理が楽にはなったものの、まだ仕様を把握しきれていない部分が多いため、使いこなせているとは言えない状態です。 これからも精進を怠らず、使いこなせるようになりたいと思います。 参考 Amazon CloudFront キャッシュポリシーとオリジンリクエストポリシーを発表 ポリシーの使用 キャッシュキーについて コンテンツがキャッシュに保持される期間 (有効期限) の管理 オリジンリクエストの制御
メッセージキューのデザインパターン 優先度付きキュー の紹介
大量のタスクを処理するようなシステムを組む場合、最近はサーバーレスが当たり前になってきたので、コンピューティング リソースが足りない場合は一時的に増やして処理しまうことができるようになってきました。 小さい簡単な処理をする場合は 最初から AWS Lambda などを使ったワークフローにシステムを構築しても良いのですが、外部システムとの連携などで再処理が必要だったりすると、サーバーレスだと緻密に組まれたピタゴラスイッチの様になってしまい融通が効かせにくいことがあります。 そこでキューイングを使うことで、システム間を一方方向のメッセージングを使った疎結合できます。再処理する際もキューに同様のメッセージを積めば簡単に実現できるし、キューイングのシステム自体に再処理する仕組みも備わってることが多いです。 今回はキューイングを使ったシステムのデザインパターンの一種である、優先度付きキューイングを紹介します。キューイングには AWS SQS や Rabbit MQ など いろいろなものがあり、キューイングのプロダクトによっては優先度付きのキューの機能を持ってるものもあります。 機能的なユースケースは以下の様なものが考えられます。 結果の同時書き込み数を制御したい場合 通常の処理とは別に優先させて処理する場合 余力のコンピューティングリソースで処理するようにしたい場合 例えば優先度付きキューの特徴を活かせるユーザーストーリーで例えると以下の様になります。 例えばGoogle Sheets の様な書き込み制限のある API に処理結果を書き込む 各地のIoT機器から不定期に時系列データが送られてきて、最新の情報をより優先して処理する 課金ユーザは優先して処理し、無課金ユーザーは余力で処理する メッセージキューのプロダクト自体に優先度付き機能がない場合でも工夫すれば優先度付きキューを実現できます。優先度付きキューの機能を持ってないプロダクトは以下のように、優先したいものとそれ以外が混ざってしまいます。 これを優先度付きにする仕組み自体はとてもシンプルで、2つのキューを用意し、それぞれのキューの役割は先に処理するキューそして、その後に処理するキューという感じの役割になります。図で表現すると以下の様な感じになり、優先してさらに早く処理したい方のキューにコンシューマを多く割り当てます。この方法だとコンシューマは1つのキューを知っておくだけなのでとてもシンプルな実装になります。 実装をさらに工夫して、1つのコンシューマが複数のキューを使い分けて処理する方法もあり、実装が多少複雑になりますがコンピューティングリソースを効率的に使いまわせます。 この記事自体は優先度付きキューの説明だけですが、 優先度付きキュー 自体は広く知られてるデザインパターンなのでググってみると具体的な実装コード等もあるので気になる方は更に深ぼってください。