KLabGames Tech Blog

KLabは、多くのスマートフォン向けゲームを開発・提供しています。 スマートフォン向けゲームの開発と運用は、Webソーシャルゲームと比べて格段に複雑で、またコンシューマゲーム開発とも異なったノウハウが求められる領域もあります。 このブログでは、KLabのゲーム開発・運用の中で培われた様々な技術や挑戦とそのノウハウについて、広く紹介していきます。

カテゴリ: その他

こんにちは、makki_d です。

前回の技術書典3に続き、技術書典4でもまたまたKLabの有志で同人誌を頒布しました。 この記事ではその報告をしたいと思います。

前回同様、紙の同人誌の他に、電子版を無料配布していました。 この記事の下部にもダウンロードリンクを用意しましたので、興味のあるかたはぜひご覧ください。

技術書典とは

技術書典は、プログラミングについての同人誌を作成しているサークル TechBooster達人出版会が主催する技術・科学系同人誌即売会です。

ナンバリングイベントの4回目となる今回は、前回と同じく秋葉原のアキバ・スクエアで4/22に開催されました。 晴天に恵まれたこともあり、来場者数6000人超となる一大イベントとなりました。

頒布した本

表紙

今回も執筆者が書きたいことを書いたため、雑多な内容となっています。

  • Cygwin 環境で Docker を快適に使うために
  • Unity で開発しているスマホゲームで Xcode のバージョンアップをする
  • Re:VIEW で書いた原稿の CI を AWS CodeBuild で回す
  • WebAssembly で行列の演算をする
  • Python インスタンスの属性は辞書(dict)で管理されているのか調べてみた

また、次の記事は締め切りに間に合わなかったため、電子版にのみ収録しています。

  • リアルの街を Unity に取り込む 〜GIS へのいざない〜

なお、表紙等のイラストは社内のデザイナー・イラストレーターによるものです。 表紙や裏表紙、当日配布したDLカードに描かれたキャラクターは、眼鏡っ娘率100%という超豪華仕様となっており、 イベント当日も一部の方々に大好評でした。

ブースはこんな感じでした。

ブース

執筆方法

参加の経緯やツール選定については以前の記事を見ていただくとして、 今回もRe:VIEWで執筆し、データをGitHubで管理しました。

さらに、今回はGitHubへのpushをトリガーとしてAWS CodeBuildでPDFを生成し、Slackに共有するというCI環境を構築してみました。 詳細は本誌の「Re:VIEW で書いた原稿の CI を AWS CodeBuild で回す」をご覧ください。

前回からの改善点

表紙に内容を書いた

前回の反省点として、ぱっとみてどんな内容の本かわからないという失敗がありました。 今回は表紙に各記事の内容をそのまま書いてみました。 表紙を見て興味をもって頂いた方も見受けられたので、良い改善でした。

大判ポスターを立てた

スペース前に人だかりができてしまうと、机上に説明書きなどを立てても見えなくなってしまっていました。 さらに前回は、黒文字のみの説明書き自体がそもそも目立たなかったというのも問題でした。

今回は多くの人に見てもらえるよう、表紙を拡大した大判ポスターを用意しておきました。 来場者自体が多かったこともあり、おかげさまでスペース前には常に人がいるような状態でしたが、 ポスターを見て足を止めてくださる方も多かったです。

CIでPDFを生成してレビューの効率を上げた

今回はレビューのフロー自体を変えてみました。 著者は記事を直接masterにコミットしてGitHubにpushします。 するとCIでPDFが生成されるので、レビュワーは最新のPDFを見て、修正案やコメントをPRの形で著者に伝えるという方式にしました。

前回は各記事をGitHubのPRの形でレビューしていましたが、やはり組版された状態のほうが文章のレビューはしやすかったです。

次回に向けて

今回はイベント自体が盛況だったことにも助けられ、新刊・既刊ともに完売することができました。 ただ、無料配布の電子版DLカードのほうも早々に完売してしまい、電子版をお求めの方にはご不便をおかけしてしまいました。 次回以降、本はもちろんのこと特にDLカードも十分な数を用意したいと思います。

また諸般の事情により今回は「かんたん後払い」を受け付けることができませんでした。 次回はどうにか対応したいと考えています。

最後に

KLab有志としての参加は2回目となりました。 イベント自体も回を重ねるごとに盛況となっており、運営の皆様、参加者の皆様、本当にありがとうございました。 これからもKLab有志として参加できることを楽しみにしていますので、今後ともよろしくお願いします。

電子版

ここまで読んでいただきありがとうございました。 電子版PDFダウンロード

はじめに

この記事は KLab Advent Calendar 2017 15日目の記事です。
こんにちは。S-Typeと申します。普段はプランナーをしている企画の人間ですが、何か書いてみたいと言ってみたところ参加させてもらえることになりました。
Google Home miniから勤怠メールを送る方法をまとめます。

勤怠報告は大変

季節の変わり目は体調を崩しがちです。無理してもパフォーマンスは上がりませんし、そういうときは休みましょう。
しかし、重い体を動かしながら、一生懸命勤怠メールを打とうにも誤字脱字が多発し、修正に時間を取られてしまう……なんてことはありませんか。

byouki_oldman

そこで、Google Home miniの出番です。
Google Home miniに勤怠を送ってほしいと、寝たまま声を発するだけで送ってくれる仕組みをご紹介します。

Google Home miniとは

Google Home miniは、Google アシスタントが利用可能なスマートスピーカーであるGoogle Homeの小型版です。価格も約半額の6,000円で購入することが可能です。
「OK, Google」もしくは「ねえ、Google」から会話を開始し、以降に続けた音声コマンドを実行してくれます。例えば「OK, Google. 明日の天気は?」と聞くと「明日の〜は最高気温〜、最低気温〜で晴れるでしょう」と回答してくれます。
その他にも計算式、radikoやNHKニュースの再生、タイマーや目覚ましアラームなど、日常においての頼れるパートナーとしての役目を担ってくれます。

IFTTTとは

IFTTTは、 If This Then That をコンセプトに生まれたウェブサービスです。
トリガーである【This】とアクションである【That】、それぞれ別々のサービスを設定し、連携させることができます。
IFTTTで特筆すべきはトリガーとアクションそれぞれに設定可能なウェブサービスが豊富にあることと、こうした流れを コードを書くことなく ユーザーが任意に設定できるということです。
そして、こうした設定をレシピと呼び、公開すれば多数のユーザー間で共有することが可能です。
今回は、このIFTTTのトリガー部分にGoogle Homeで利用可能なGoogleアシスタントを設定し、Gmailから勤怠メールを送ってみることを試してみようと思います。

IFTTTレシピ作成前の準備

では、さっそく、レシピを作ってみましょう。準備するものは以下の通りです。

  • Googleアカウント(Gmailで送る際に使用)
    • IFTTTに登録可能なGmailアカウントは一つだけです
  • IFTTTのアカウント

そして、処理の流れは以下の通りとなります。

  • This:Google Home miniに「今日は会社を休みたい」と言う。
  • That:Gmailから勤怠メールが送られる。Google Home miniから「お大事にして下さい」と返される。

レシピの追加

  1. IFTTTにログインし、My AppletからNew Appletをクリックします。

recipe_0

  1. この画面が表示されるのでThisをクリックします。

recipe_1

  1. Google Assistantをクリックします。探しにくい場合は検索で見つけましょう。

recipe_2

  1. Say a simple phraseをクリックします。
    これは「今日は会社を休みたい」という単一のフレーズでの処理結果が確定しているためです。
    今回は解説しませんが、今日ではなく明日だったり、休む理由を体調不良や私用など条件分岐させたい場合はSay a phrase with a text ingredientを選択します。

recipe_3

  1. Google Homeに話しかけるときのフレーズを指定します。
    対象の項目は
    What do you want to say?
    What's another way to say it? (optional)
    And Another way? (optional)
    以上の3つです。
    What do you want the Assistant to say in response? はどんな返事をしてほしいかを設定します。
    日本語で指示し、日本語で返してほしいので Language はJapaneseにしてください。
    ここまで終わったらCreate triggerをクリックしてトリガーの作成を終わらせましょう。

recipe_4

  1. 次にThatをクリックし、トリガーをきっかけに実行される内容を設定しましょう。

recipe_5

  1. Gmail をクリックします。

recipe_6

  1. メールを送りたいので、Send an emailをクリックします。

recipe_7

  1. メール送信にあたって必要な情報を埋めていきます。
    ここで設定しているのは以下の項目です。
    To address で送信先を、Subject で件名を、そして Body で本文を設定します。
    Bodyに改行を含む場合は <pre> タグで文章を全て囲わないと、改行されませんので注意してください。
    ここまで終わったらCreate actionをクリックしてアクションの作成を終わらせましょう。

recipe_8

  1. 最後にレシピの名前を設定します。デフォルトでIfから始まる文章が入っていますので、このままでも良いでしょう。
    Receive notifications when this Applet runs のスイッチはOFFにしておくことをオススメします。
    このスイッチがONになっていると、そのレシピが実行されたらその度にメールで通知されます。
    Finishで完了します。

recipe_9

検証

では、さっそく検証してみましょう。

前提条件

  • メールの送り元は私用のアドレスです
  • メールの送り先は社用のアドレスです

実践

私「ねえ、Google。今日は会社を休みたい」
Google Home mini「お大事にして下さい」
……しばらくしてから ピコン!(メールの着信音)

スクリーンショット

出来ましたね!!

recipe_10

最後に

今回はGoogle Home miniとIFTTTの連携によるメールの送信を紹介しました。
100%衝動買いだったGoogle Home miniでしたが、IFTTTのおかげで様々なウェブサービスとの連携が楽しめるので、無駄にはならなさそうです。
何よりもコードを書く必要がなく、GUIで入力項目を埋めていきながら設定が出来るため、私のような開発職以外の人間でも簡単に出来ました。

余談

Google Home miniを今後も活用していきたいので、nature remoを注文しました。
nature remoと組み合わせることで、音声による赤外線リモコン家電のコントロールが可能になります。
これが出来るようになると、寝たまま部屋のリモコン照明のON/OFFが出来るようになります。もう完全に未来ですね。
本稿を書くまでに届いていれば、そちらをテーマに書こうと思っていたぐらいでしたが、間に合わなかったため、またいつか別の機会で書かせてもらえたらと思っています。

この記事は KLab Advent Calendar 2017 10日目の記事です。

こんにちは。このブログでは4度めまして、kakkun61 です。

この記事では、10月22日に開催された同人誌即売会技術書典3に KLab の有志で作った同人誌を頒布しましたので、その報告をします。

頒布した同人誌は電子版が無料で、この記事の下部にダウンロード用のリンクを張っています。

技術書典とは

技術書典は、プログラミングについての同人誌を作成しているサークル TechBooster達人出版会が主催する技術・科学系同人誌即売会で、今回含めナンバリングイベントが3回、超会議での超技術書典が1回開催されています。

今回は秋葉原のアキバ・スクエアで開催され、ユニークの来場者数では2750名とかなり大規模なイベントとなっています。

なぜ参加することにしたか

発案は筆者で、筆者は技術書典1と技術書典2そしてその間のコミックマーケット91とで Haskell の同人誌を頒布して同人誌を作る楽しさみたいなものを感じていたことと、KLab のアドベントカレンダーは過去2度ともすぐに枠が埋まってしまっていたので、社内に書きたいと思っている人がある程度いるのではないかと思い、会社に相談し会社として参加することになりました。

どう作ったか

TechBooster の『技術書をかこう!』にしたがって Re:VIEW を使い、GitHub 上で Pull Request 運用で作っていきました。

各章を1人で担当し、章ごとに PR を作成しレビュー後マージという運用をしました。ふだんのソースコードの開発と似せた方が分かりやすいかと思いこのようにしました。

どんな同人誌になったか

表紙

7名で執筆し、校正の協力に1名、表紙の協力に1名という体制のメンバーになりました。

内容は下記です。

  • 物理ベースレンダラーを Rust 実装して、表紙絵をレンダリングした話
  • Sprache を CPS 変換
  • Emscripten で動画再生する
  • テキストマクロプロセッサ「M4」のチューリング完全性
  • FPGA 初心者が試行錯誤しながら疑似乱数生成回路を作る
  • 家庭内ネットストーカーシステムを作った
  • とある KLab のスマホアプリのビルド事情

特にジャンルなどは指定せずみなが書きたいことを書いてもらったのですが、直接しごとと関係あるものは「とある KLab のスマホアプリのビルド事情」のみで、他は各々好き好きな内容になりました。

参加してどうだったか

さいわい印刷した冊数の7割ほど頒布することができました。印象としては KLab だからというよりは、内容で購入してくれていたように思いました。どれもコアな内容なので一部の人には刺さっていたようでよかったです。

メンバーでのふりかえりで、一般にも役に立ちそうなことを下記に抜粋します

ぱっと見てどんな内容の本か分からない

雑多な内容でタイトルに何も情報がないのでどんな本か分からなかったのは失敗でした。表紙に概要を書いたり、内容を書いたものを机に立てるなどしようと思います。

カラーのフェルトペンがあるとよかった

上の項目にも関連して、現地で札などを立てることになったときに黒ペンしかなかったので、見栄えが悪かったです。

人だかりができると立てたものは反対に見にくい

宣伝に札を立てたりしたのですが、人が近くで立って机を見たら上から見下ろすことになるので、そのときは紙を置く形の方がよかったです。机の前に人がいるいないで立てと寝かせとをうまく変えられるとすごくいいと思いました。

レビューに PR を使うことについて

今回は GitHub で PR を作る方式にしたのですが、いくつか問題に感じることがありました。

  • 書きかけの状態で全部の章を合わせてビルドするのが PR 方式だとやりにくい
    • マージしたブランチを作成しないといけないため
  • レビュワーが PR 上で指摘するのはリードタイムが長くなるので、明らかに問題のない修正はレビュワーが直接書きかえたかった

次回は、著者が直接 master にコミットし、レビュワーも直接コミットして訂正する方法を試そうと思います。

余談

調査不足でブースが隣りの Wantedly の書籍と名前かぶりしていました。「Tech Book ください」と言われて「どちらの?」となることがありすみませんでした。あちらの方が技術書典1からその書名を使っていらしたのでこちらがかぶせてしまいました。

電子版

ダウンロード

このエントリーは、KLab Advent Calendar 2017 の12/4の記事です。

今年のISUCONはKLabが作問するということで、ゲームが題材だと予想していた方も多かったと思います。 その期待(?)に応えるべく、本選ではCookie Clickerを元にしたゲームを出題しました。 これを複数人で協力プレイできるようにして、WebSocketを使っていて、クッキーではなく椅子を増やし、椅子の数が多倍長整数になる、というゲームでした。

この記事では @hasi_t がISUCON7本選の作問でやったことを書きます。

プロトタイプ作成

まずプロトタイプ作成を担当しました。 Cookie Clickerを元にする、という案が出ていたので、自分がやりたい要素を入れたプロトタイプを作りました。

一つ目の要素は未来計算と操作遅延です。 サーバが未来の値を計算できるようなデータを返し、クライアント側で各時点での値を計算するようにする、という設計です。 そして操作を遅延させることで可能な限り同時刻での見え方が同じになるようにしました。 このような設計によって通信頻度を下げる、というのは、 CEDEC 2015で発表したことの実践で(参考)、 それを実現するための技術や開発体制について普段の業務で日頃考えていたりするのですが、 その実態を見せる機会と考え、この要素を入れました。

二つ目の要素は多倍長計算です。 以前、 ICFPC 2016 というプログラミングコンテストに参加したときに多倍長有理数を使って、 こういう多倍長計算を使った問題を作りたいと思っていた、というのがあります。 あと、メモリを消費させて、ただキャッシュするだけでは駄目なようにしたい、というのも考えていました。

ちなみに、作問チームのうち3人 (@mecha_g3, @___Johniel, @hasi_t) はここ4年ほど、この3人だけではないですが、DiamondPrincessというチームでそのICFPCに参加しています。そして今年は2位でした!

プロトタイプの時点ではWebSocketではなく、普通のHTTP通信で、サーバはPHPで雑に書いた状態でした。 ver0とver1を作ったのですが、ver0の時点ではミリ秒単位ではなく秒単位だったりしました。 あと、命名が雑すぎて抽象的な一文字変数名だらけになっていたので、本実装時に名前の調整が結構大変でした。

本実装作成

WebSocketを使うことになり、初期実装は他の人に任せて、 ゲーム画面を作るためにJavaScriptコードをロジックとビューに分割したり、 いい感じのフォントを探したりしていました。

ベンチマーカのバリデーション作成

未来計算の設計時点で、ベンチマーカから見て検証可能にすることを考えていました。 誤差を許容するには、許容範囲やそれに合わせた計算など、考えることが多く、それを避けた結果、厳密な検証になりました。 そのため、値が1でもずれるとfailするという厳しいコンテストになりました。

負荷走行前の検証はaddIsu, buyItemに対するレスポンスが必ず存在するので良かったのですが、 負荷走行後の検証はタイムアウトなどでレスポンスが無い場合を考える必要があり、 上限と下限を考えて検証する必要があってちょっと大変でした。

エラーメッセージを参加者にとってわかりやすくする、という作業をするのがぎりぎりになってしまい、 初期実装作成者には苦労をかけてしまいました。

ベンチマーカのチューニング

当然といえば当然ですが、初期実装そのままで検証していたら、 負荷走行後の検証の実行時間が長すぎる問題が発生し、高速化をしました。

やったこととしては、指数表記変換関数の高速化、item価格と生産速度のキャッシュ、1000回ループの回避、指数表記変換関数内の10のn乗のキャッシュ、addingの累積和を使う、などです。

実装は以下の通りです。指数表記変換関数(big2exp)はutil.goにあります。

とりあえず、Go言語のbig.Intは、つらい、という感想でした。

マスタデータ調整

いい感じのマスタデータにしないと多倍長使う意味が無い、と思っていたので、 1分間のベンチマークで10の10万乗ぐらいまで到達できるようにマスタデータを調整しました。 調子に乗って1個目の購入価格が10の10万乗ぐらいあるアイテムを作ったら、 初期実装の時点でそこが重すぎて、リハーサルやってみたけどまともにチューニングできない、 みたいなことも起きたりして申し訳ない感じだったりしました。

ちなみに、Excelで値を調整して、Pythonスクリプトで雑なシミュレーションをする、ということをしていました。 もちろん、値を直接扱えないので、対数をとって計算していました。

おわりに

参加者の皆様、運営の皆様、お疲れ様でした! いろいろご迷惑おかけしましたが、出題することができて嬉しく思っています。 ありがとうございました!

(本稿はKLab Advent Calendar 2017 の3日目の記事になります)

昨今、電子工作やマイコンプログラミングへのハードルが急激に下がっているという印象があります。皆さんの身の周りでもArduinoやRaspberry Piに秋葉原で買ったセンサーを繋いで遊んでいる人がいるのではないでしょうか?

私の所属しているKLab株式会社にも「Make部」という部活があり、毎年Maker Faire Tokyoで各個人が作品を展示したり社内勉強会を開いたりして、業務と無関係に電子工作を楽しんでいたりします。

ふつうのLinuxマシンでもセンサー類を扱いたい

とはいえ、ArduinoもRaspberry Piも普段使っているLinuxマシンやmacOSマシンとは随分異なる環境です。ふつうのLinuxマシンにセンサーを接続して、気軽に扱えないものでしょうか?

Raspberry Piでセンサー類を簡単に扱えるのは、GPIOインターフェースが存在するためです。GPIOピンと各種センサー類やサーボモータなどを接続することで、Linux+電子工作の組み合わせが簡単に実現できるよ、というのがRaspberry Piの強みだと言えるでしょう。

Raspberry PiのGPIOピン

一方で、多くのLinuxマシンにはGPIOインターフェースが存在しません。たとえばUSB to I2C変換モジュールを使えばLinuxマシンでも電子工作的な遊びはできますが、追加の出費が必要ならRaspberry Piを買った方がマシだよ、となってしまいそうです。

本稿では、DigiTempを使ってLinuxマシンで比較的安価に温度センサーを扱う方法を紹介します。DigiTempはLinuxのシリアル通信インターフェース経由で1-Wire接続のセンサーを扱うOSSで、多くのLinuxディストリビューションで標準パッケージとして採用されています。

ソフトウェアのインストール

まずはソフトウェアのインストールをしましょう。大抵の環境でDigiTempはコマンド一発で入るはずです。

Debian系なら apt でインストールできます。

$ sudo apt install digitemp

RedHat系は yum でインストールできます。

$ sudo yum install digitemp

macOSでも遊べます。Homebrewからインストールしましょう。

$ brew install digitemp

後述するようにシリアル通信ドライバも必要です。こちらは利用するシリアル変換ICに応じて適切なドライバをインストールしてください。

ハードウェアの準備

当然ですが、ソフトウェアだけで外気温の測定はできません。DigiTempの利用には下記のような準備が必要です。

USB to シリアル変換モジュール

USBからシリアル通信(UART)への変換モジュールです。Arduinoで遊んだことがあれば必ず1個は持っているのではないでしょうか。変換ICとしてはFTDI社のFT232RLなどが有名ですが、他にもSilicon Labs社CP2102やProlific社 PL2303を採用した変換モジュールも容易に入手できます。

ちなみに私はCP2102ベースの変換モジュールを利用しています。これはeBayで1.15ドルでした。

CP2102 USB to シリアル変換モジュール

FTDI製ICを使っているモジュールであればドライバは標準でインストールされていることが多いかもしれません。それ以外の場合は手動でドライバをインストールする必要があるはずです。

温度センサ DS18B20

DS18B20はMaxim Integrated Products社製の温度センサです。秋月で買うと1個250円ですが、eBayなどを探せばもっと安いものも見つかります。

DS18B20

このセンサーは1-WireというMaxim独自のプロトコルで動作します。このプロトコルがUART経由で扱う上でのキモです。1-Wireはデータレートが低速かつ通信線1本で動作するので、UARTからでもドライブできるのです。他のプロトコルのセンサーであれば何らかのICが必須になるでしょう。

UARTとDS18B20の接続用ボード

UARTとDS18B20を直結しても動くことは動くらしいのですが、逆流防止などの用心のため、簡単な回路を工作してみました。

UART to DS18B20 接続用ボード

これはdword1511/onewire-over-uartで紹介されている下記の回路図を元に作成したものです。

回路図

材料は下記の通りです。

  • ユニバーサル基板
  • L型ピンソケット(1×6、メス)
  • 5.1kΩ 抵抗
  • スイッチングダイオード 1N4148
  • ポリウレタン銅線(配線用)

動かしてみる

これらを組み合わせると次のような見た目になります。思ったより場所を取る感じの仕上がりになってしまいました。

完成図

これをLinuxマシンのUSBに接続して、先ほどインストールしたDigiTempを起動すると温度が取れます。

コマンドの使い方として、まずは-wオプションを指定して1-Wireデバイスのスキャンを行う必要があります。-sオプションはシリアルポートの指定です。

$ /usr/bin/digitemp_DS9097 -s/dev/ttyUSB0 -w
DigiTemp v3.7.1 Copyright 1996-2015 by Brian C. Lane
GNU General Public License v2.0 - http://www.digitemp.com
Turning off all DS2409 Couplers
.
Devices on the Main LAN
28FF933161150389 : DS18B20 Temperature Sensor

これで接続されているセンサーの情報が$HOME/.digitemprcに記録され、次回以降の起動でこの情報を参照するようになります。

$ /usr/bin/digitemp_DS9097 -a -d 2 -n 5
DigiTemp v3.7.1 Copyright 1996-2015 by Brian C. Lane
GNU General Public License v2.0 - http://www.digitemp.com
Dec 02 21:21:27 Sensor 0 C: 21.50 F: 70.70
Dec 02 21:21:29 Sensor 0 C: 21.56 F: 70.81
Dec 02 21:21:31 Sensor 0 C: 21.50 F: 70.70
Dec 02 21:21:33 Sensor 0 C: 21.50 F: 70.70
Dec 02 21:21:35 Sensor 0 C: 21.44 F: 70.59

上記は2秒間隔でセンサーの値を5回取得する指定です。摂氏と華氏で温度が取れているのがわかります。

ちなみに、筆者はこれを家のLinuxルータに刺した上で取得した値をMackerelに書き出しています。

温度変化グラフ

上記のグラフが作りたいだけならRaspberry Piで温度センサーを扱った方が楽なのでは?と思われるかもしれません。理屈で言えばそうかもしれませんが、個人的にRaspberry Piは長期間電源を入れっぱなしにする気が起きないので、ふつうのLinuxマシンで運用できることに価値があるように感じています。同じ感覚の方が他にいらっしゃるかはわかりませんが…。

まとめ

  • DigiTempというLinux/macOS上で温度センサーDS18B20を扱うOSSを紹介しました
    • シリアル通信(UART)経由で1-Wireセンサーをドライブできます
    • 多くのLinuxディストリビューションで標準パッケージ採用されています
  • Raspberry Piで同じことをするより適用範囲が広かったり長期運用しやすかったりするかもしれません

@hnw

↑このページのトップヘ