2023年を意味不明な写真でふりかえる
こんにちは。katzchangです。これは pyspa Advent Calendar 2023 - Adventar の1日目の記事です。
正直なところね、最初はね、今年ね、アドベントカレンダーを書くのはやめようと思っていました。だって、今年は何もやってない！！
まあでも、何をやったかなぁと振り返るために、とりあえずGoogle Photosを眺めてみました。今年も雪山に行ったりご飯を食べたりビールを飲んだり本が出版されたりしていたわけですが、そういう、なんていうかね、わかりやすいね、対外的にアピールしやすいものはもう十分です。お腹いっぱいです。なので、それ以外の写真を振り返ってみます。
1月
抗菌EXの写真です。なぜかというと、キーボードのキーキャップを洗ったらしいです。洗濯洗剤を使うべきかはわからない。
2月
高カロリーな成分表示の写真です。「夕方に小腹が空いたときには少量のナッツを食べるといい」みたいなことを聞いたので用意したのですが、ダメですね、100g食べ切る勢いでなくなっていくので、私向きのプラクティスではない。
3月
前々職のオフィスに密かに貼った🐬ステッカーが、まだ残っている様子の写真です。この辺は次のテナントが入ると聞いたけど、さすがに掃除されちゃうだろうな。
4月
帽子が似合うそーだいさんの写真です。
5月
経費精算をするぞという決意の写真です（しかし、漢字で書けない）。
6月
パスタを食べ終わった油の写真です。
7月
暑かった写真です。
8月
給油口の隅まで洗車すると、給油のときの体験がいいのでおすすめという写真です。
9月
未開封明太子の写真です（この後美味しくいただきました）。
10月
ワークマンで買ったシェルジャケットを畳んだ様子です。
11月
また成分表示の写真です。
12月
いえーい、12月だ！！
まとめ
ということで、意味が分かりにくいけど無難な写真を見ながら、2023年をふりかえってみました。今年の課題はおやつの選択だったことがわかります。来年は、体重をコントロールしていきたいと思っています。
pyspa Advent Calendar 2023 - Adventar, 明日はところてんの記事が来るはずです。おたのしみに・・・。
OpenTelemetry Collectorがそれ自身のオブザーバビリティをどのように提供しているか？
Hi, この記事は OpenTelemetry Advent Calendar 2022、12日目の記事です！
OpenTelemetryは、Collectorを通じてバックエンドにテレメトリーデータを送信するアーキテクチャを取ることができます。それにより、様々なコンポーネントのテレメトリを統合し、関連付け、バックエンドへの送信を管理することができるようになっています。
反面、「バックエンドでテレメトリーデータが上手く表示されない」のようなトラブル時に、調査対象コンポーネントがそれだけ増えてしまうことになります。どのようにトラブルシュートすべきか、エージェント等のGitHubリポジトリから docs/troubleshooting.md などのドキュメントを探していただくとヒントがあるわけですが、OpenTelemetry Collectorではどのようなトラブルシュートができるか、そのためにどのようなオブザーバビリティを備えているかを見てみましょう。
メトリクス
OpenTelemetry Collectorはそれ自身で、Prometheus形式（OpenMetrics形式って言って良いんだっけ？）のメトリクスを公開しています。デフォルトの状況では 8888 ポートの /metrics エンドポイントで公開していて、たとえばこんな情報が手に入ります。
# HELP otelcol_exporter_sent_log_records Number of log record successfully sent to destination.
# TYPE otelcol_exporter_sent_log_records counter
otelcol_exporter_sent_log_records{exporter="signalfx",service_instance_id="37d4a1a7-5f40-4e89-9f70-203d101a5afa",service_name="otelcol",service_version="v0.66.0"} 20
otelcol_exporter_sent_log_records{exporter="splunk_hec",service_instance_id="37d4a1a7-5f40-4e89-9f70-203d101a5afa",service_name="otelcol",service_version="v0.66.0"} 624
# HELP otelcol_exporter_sent_metric_points Number of metric points successfully sent to destination.
# TYPE otelcol_exporter_sent_metric_points counter
otelcol_exporter_sent_metric_points{exporter="signalfx",service_instance_id="37d4a1a7-5f40-4e89-9f70-203d101a5afa",service_name="otelcol",service_version="v0.66.0"} 10254
実際には前後にズラーッと並んでいて一つひとつ解説するのは大変なので割愛しますが、Collectorの内部、receiverやprocessor、exporterがどのように動いているかのメトリクスを収集して、様子がわかるようにしています。これにより、たとえばこんなダッシュボードが作れたりします。
たとえば「あれ？トレースがあるはずなのにUI上でみれないぞ？」という場合は、まず、こういったダッシュボードを使って、テレメトリーデータのパイプラインが動作しているかを確認してみてください。
ちなみに、SplunkディストリビューションのCollectorではデフォルトとして、内部メトリクスをスクレイプするためのレシーバーが定義されていたりします。これにより、10秒に1回、自分自身のメトリクスをスクレイプし、メトリクスパイプラインに乗せて外部に送信するようになっています。
# This section is used to collect the OpenTelemetry Collector metrics # Even if just a Splunk APM customer, these metrics are included prometheus/internal: config: scrape_configs: - job_name: 'otel-collector' scrape_interval: 10s static_configs: - targets: ['0.0.0.0:8888'] metric_relabel_configs: - source_labels: [ __name__ ] regex: '.*grpc_io.*' action: drop
ログ
メトリクスによって、特定のコンポーネントやパイプラインが動いているかいないかが大雑把に判断できます。では、何故動いていないのか？原因を探るためにログを確認することがあります。OSのサービスとしてインストールした場合にはjournalログに、コンテナとして動かした場合にはコンテナログを見に行くのが基本です。
たとえば、SplunkディストロのCollectorの場合は、↓のようなコマンドでCollectorのログを確認できます。
sudo journalctl -u splunk-otel-collector
ログはこんな感じ。各コンポーネントやパイプラインの初期化の様子が主にinfoログとして出力されます。
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.730Z info pipelines/pipelines.go:102 Receiver is starting... {"kind": "receiver", "name": "otlp", "pipeline": "traces"}
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.730Z info pipelines/pipelines.go:106 Receiver started. {"kind": "receiver", "name": "otlp", "pipeline": "traces"}
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.730Z info pipelines/pipelines.go:102 Receiver is starting... {"kind": "receiver", "name": "smartagent/signalfx-forwarder", "pipeline": "traces"}
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.730Z info pipelines/pipelines.go:106 Receiver started. {"kind": "receiver", "name": "smartagent/signalfx-forwarder", "pipeline": "traces"}
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.730Z info pipelines/pipelines.go:102 Receiver is starting... {"kind": "receiver", "name": "zipkin", "pipeline": "traces"}
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.730Z warn internal/warning.go:51 Using the 0.0.0.0 address exposes this server to every network interface, which may facilitate Denial of Service attacks {"kind": "receiver", "name": "zipkin", "pipeline": "traces", "documentation": "https://github.com/open-telemetry/opentelemetry-collec>
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.730Z info pipelines/pipelines.go:106 Receiver started. {"kind": "receiver", "name": "zipkin", "pipeline": "traces"}
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.731Z info pipelines/pipelines.go:102 Receiver is starting... {"kind": "receiver", "name": "fluentforward", "pipeline": "logs"}
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.731Z info pipelines/pipelines.go:106 Receiver started. {"kind": "receiver", "name": "fluentforward", "pipeline": "logs"}
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.731Z info pipelines/pipelines.go:102 Receiver is starting... {"kind": "receiver", "name": "otlp", "pipeline": "logs"}
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.731Z info pipelines/pipelines.go:106 Receiver started. {"kind": "receiver", "name": "otlp", "pipeline": "logs"}
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.731Z info pipelines/pipelines.go:102 Receiver is starting... {"kind": "receiver", "name": "signalfx", "pipeline": "logs"}
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.731Z info pipelines/pipelines.go:106 Receiver started. {"kind": "receiver", "name": "signalfx", "pipeline": "logs"}
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.731Z info pipelines/pipelines.go:102 Receiver is starting... {"kind": "receiver", "name": "smartagent/processlist", "pipeline": "logs"}
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.731Z info pipelines/pipelines.go:106 Receiver started. {"kind": "receiver", "name": "smartagent/processlist", "pipeline": "logs"}
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.731Z info healthcheck/handler.go:129 Health Check state change {"kind": "extension", "name": "health_check", "status": "ready"}
Dec 12 09:03:07 mlrt otelcol[164910]: 2022-12-12T09:03:07.731Z info service/service.go:106 Everything is ready. Begin running and processing data.
Everything is ready とあるので、初期処理は概ね大丈夫なようです！
ところが、今の環境ではなんかエラーログが出ています。
Dec 12 09:04:10 mlrt otelcol[164910]: 2022-12-12T09:04:10.139Z error exporterhelper/queued_retry.go:394 Exporting failed. The error is not retryable. Dropping data. {"kind": "exporter", "data_type": "logs", "name": "splunk_hec", "error": "Permanent error: \"HTTP/1.1 400 Bad Request\\r\\nContent-Length: 53\\r\\nContent-Type: text/plain; charset>
Dec 12 09:04:10 mlrt otelcol[164910]: go.opentelemetry.io/collector/exporter/exporterhelper.(*retrySender).send
Dec 12 09:04:10 mlrt otelcol[164910]: /builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.66.0/exporter/exporterhelper/queued_retry.go:394
Dec 12 09:04:10 mlrt otelcol[164910]: go.opentelemetry.io/collector/exporter/exporterhelper.(*logsExporterWithObservability).send
Dec 12 09:04:10 mlrt otelcol[164910]: /builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.66.0/exporter/exporterhelper/logs.go:134
Dec 12 09:04:10 mlrt otelcol[164910]: go.opentelemetry.io/collector/exporter/exporterhelper.(*queuedRetrySender).start.func1
Dec 12 09:04:10 mlrt otelcol[164910]: /builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.66.0/exporter/exporterhelper/queued_retry.go:205
Dec 12 09:04:10 mlrt otelcol[164910]: go.opentelemetry.io/collector/exporter/exporterhelper/internal.(*boundedMemoryQueue).StartConsumers.func1
Dec 12 09:04:10 mlrt otelcol[164910]: /builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.66.0/exporter/exporterhelper/internal/bounded_memory_queue.go:61
うーん、何か良からぬことが起こっていそう。このトラブルシュートは次回の課題とします。
OpenTelemetryの各言語エージェントやCollectorは、本番サービスのパフォーマンスボトルネックになることを避けるためか、テレメトリーデータの送信失敗に対して かなり相当あっさり諦める ようになっていて、さらに、この様子がメトリクスとして現れるとは限りません。なので、Collector自身のログも何らかの経路で収集してエラーログを見つける…ということが必要かもしれません。もちろん、ログ送信パイプライン自身が壊れている場合にはそれも無理なので、結局、古典的な方法に頼らざるを得ないポイントが出てくるというのが、計装を整えていくときのやっかいなところです。
とまあこんな感じに
Collectorの動きを確認する基本的なテレメトリーデータであるメトリクスとログについて紹介しました。ほかにもloggingエクスポーターやzpagez, pprofなど、テレメトリーデータ処理がつつがなく行われているかを調査するためのいくつかもの仕組みを備えています。公式ドキュメントのトラブルシュートガイド を覗いてみてください。
ということで、この記事は OpenTelemetry Advent Calendar 2022、12日目の記事でした。Have a happy instrumentation!
OpenTelemetry Collectorでログファイルの更新を取り込む
Hi, この記事は OpenTelemetry Advent Calendar 2022、1日目の記事です！
OpenTelemetryコミュニティでは様々なテレメトリデータの取り扱いについて議論されており、ログの扱いについても例外ではありません。 最新状況は公式ブログでのロードマップ情報に譲るとして、 OpenTelemetry Collectorのレシーバーを眺めていると、File Log Receiverというものがあるらしいので、ちょっと動かしてみました。
otel collector config
設定はシンプルに、ファイルの更新を検知して、外部に送る感じにします。
- レシーバーとして
/var/log/myservice/ディレクトリにあるjsonファイルをすべてtailする指定をします。 - わかりやすさのため、
deployment.environment=hello-otel-logとなる属性を追加します。 - それを
splunk_hecエクスポーターを使って外部（Splunk Log Observer）に送ります。
receivers: filelog/myservice: include: [ /var/log/myservice/*.json ] operators: - type: json_parser timestamp: parse_from: attributes.time layout: '%Y-%m-%d %H:%M:%S' exporters: splunk_hec: token: "${SPLUNK_HEC_TOKEN}" endpoint: "${SPLUNK_HEC_URL}" source: "otel" sourcetype: "otel" processors: batch: resource/environment: attributes: - key: deployment.environment action: insert value: hello-otel-log service: pipelines: logs: receivers: [filelog/myservice] processors: [batch, resource/environment] exporters: [splunk_hec]
ログを出してみる
シンプルに、echoコマンドでログを出してみます。こんな感じ:
echo '{"time": "2022-12-01 12:34:57", "message": "otel log!"}' >> /var/log/myservice/hoge.json
すると、otel collectorのログにはファイルを見始めた旨のログが吐かれています
info fileconsumer/file.go:161 Started watching file from end. To read preexisting logs, configure the argument 'start_at' to 'beginning' {"kind": "receiver", "name": "filelog/myservice", "pipeline": "logs", "component": "fileconsumer", "path": "/var/log/myservice/hoge.json"}
そして、Splunk Log Observerを開くと、いい感じにログが取り込まれている様子がわかります。
もちろん、Splunk以外にも、ログに対応したエクスポーターであれば何でも動きます。 公式ドキュメントのレジストリや、 GitHubリポジトリ https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter を眺めてみてください！
この記事は OpenTelemetry Advent Calendar 2022、1日目の記事でした。明日は @ymotongpooです！
VOYAGE GROUPを退職していました
株式会社VOYAGE GROUPを退職していました。2019年10月吉日が最終出社日でした。
主にビールを飲んだり、天ぷらを揚げて怒られたり、昼寝しすぎて怒られたりして、いい会社でした。
いまは、少なくとも設備上は、肉を焼くことはできるはずです。
2021年ビール10選
今年もこのランキングの季節がやってまいりました。今年飲んだビールから、印象に残った10本を選んでいきます。順番は、飲んだ時間の順番です。
Hotcake Hazy IPA - Far Yeast Brewing
変わり種に見えて、甘そうに見えるけど、飲んでみると意外とふつうにちゃんとしっかりとしたHazy IPA。もちろん香りは甘く、メープルシロップのような感じです。
Passiflora Hazy IPA - VERTERE
その名の通り、トロピカルフルーツの中に百合のような華やかな香りがよかった。
2021年限定 Session IPA - 軽井沢高原ビール
オレンジ感の高いジューシーさ。転職前の有給消化中、雪の中で飲んだという思い出です。
Hazy Tropics - Shared Brewery
パイナップル感の高い。夏くらいにあったやつかな。ご近所のブルワリーで、新鮮なビールをいつも頂いております。
醸造や缶詰めなどの設備が徐々に充実してきているらしく、来年あたりは皆さん手に入りやすくなりそう。見つけたら飲んでみてください。
サッポロ セブンプレミアム 上富良野佐藤さんのホップ畑から
大手ビールからこの1本が印象的だった。爽やかなホップの香りがいい。佐藤さんなかなかやりよる。
PALE ALE nonno - 忽布古丹醸造
香りが良く軽めに飲めるので、広くおすすめできる。
Early Tide - BLACK TIDE BREWING
第一印象の香りがとてもよかった。しっかり苦味もあり、バランスの良いIPA。
Over Drive Pale Ale - Y.MARKET BREWING
重めでしっかり苦めなワイマーケットの中でも比較的飲みやすいバランス感だった気がする。
SUN - Uchu Brewing
宇宙は色々飲んでどれも印象が良く選びにくいが、最近飲んだこれをとりあえず。これもバランスのいい系のIPAだったなー。
Harmonic Dreams - West Coast Brewing
WCBも選びにくいが、今日（！）飲んだこれを推しておきます。強烈フルーティな香りで口当たりがよく、かつ、アルコール度数が高めのせいか飲みごたえがあるという、高次元でまとめてきた感じがある。
ということで、
振り返ってみると好みの傾向がかなり出てるなぁという感じの10選になりました。限定醸造とかも多く、そうじゃなくても、小規模ブルワリーは醸造バッチごとに味わいが異なってくるという一期一会の世界です。このあたりのビールを飲みだしたのはちょうど去年の末くらいからだったと思うのですが、ステイホームな今年1年楽しませていただきました。来年はどうなるかなぁ、楽しみにしております。
さて、これはpyspa Advent Calendar 2021、12/6のための記事でした。pyspaの #bar チャンネルでは、ビールのみならずアルコール飲料の情報が日々交換されていて、とても有用でございました。ビール会したいね。
Nature Remo Eを使って、消費電力をNew Relicに送信する
Hey, NewRelic Advent Calendar 2020 - Qiita, 15日目の記事だよ！時差があるのは気にしないで！
電力消費量が気になる季節がやってまいりました。ということで、Nature Remo Eを使って電力消費マネジメントの第一歩目である「計測せよ」にチャレンジしてみます。
Nature Remo Eを買う
Nature API Tokenを取得する
Remo Eを良い感じにセットアップしていただいて、 https://home.nature.global/ にログインしたらなんとなくtokenが発行できます。
New Relicに情報を送る
電力消費情報をNew Relicに送ることで、アラートを設定して不測の事態に対応したり、パフォーマンスを可視化し、コストをコントロールするためのインサイトを得たりができるようになります。
New Relicに情報を送る方法はいくつかあります。Infrastructureエージェントを動かしているならnri-flexも設定はシンプルなのでおすすめではありますが、せっかくなので2020年春あたりから整備されてきた新しいNew Relic Metrics APIを使って、情報を送ることにしましょう。
Nature APIから情報を持ってくる
go-remoeというライブラリがなんとすでにあるので、ありがたく使ってみることにします。解説のブログ記事を見た感じでは、以下2つが候補になります:
- 瞬時消費電力: その瞬間の消費電力。スピードメーター的なもの。
- 期間当り（たとえば1分当り）の消費電力: ある期間の消費電力を出すためには、期間終了時の積算消費電力から期間開始時の積算消費電力を良い感じに（正方向と逆方向を適当に）引く必要がある。
瞬時消費電力は扱いが簡単そうです。一方、期間の消費電力を扱うにはなんかちょっと計算をする必要があるようで、うーんなかなか難しい。とりあえず生のデータだけNew Relicに送っておいて、計算は後で考えることにしましょう。
計測・送信間隔は雰囲気的に1分毎を想定してみます。crontabで毎分実行させたり、現代的にはAWSのCloudWatch Eventsを使って毎分Lambdaをinvokeさせるような想定です（Lambda Handlerへの実装は、読者の課題とする）。
New Relicに送る
New Relic Metrics APIを眺めてみると、Metrics APIを直接使う方法や、各言語のテレメトリSDK経由で送る方法にたどり着きます。そのあたりから、newrelic-telemetry-sdk-goにたどり着いてみましょう。
メトリックは3種類あると記載されています:
| Basic type | Aggregated type | Description | Example |
|---|---|---|---|
| Gauge（ゲージ） | AggregatedGauge | ある時点での単一の値 | 部屋の温度 |
| Count（カウント） | AggregatedCount | 何らかのイベントが起こった回数を記録する | エラーの発生回数 |
| Summary（サマリー） | AggregatedSummary | ある時間間隔における、カウント、合計、最小、最大を記録する | 1分あたりのHTTPリクエストのスループットやレスポンスタイムを記録する |
Remo Eで取得できる値は、いずれもある瞬間での値なので、とりあえずゲージとして突っ込んでおきましょう。
コードはこうなりました。Nature API Token, New Relic Insert APIはそれぞれ、環境変数として設定しています。
package main import ( "context" "github.com/reeve0930/go-remoe" "github.com/newrelic/newrelic-telemetry-sdk-go/telemetry" "time" "os" ) func main() { token := os.Getenv("NATURE_API_TOKEN") remoClient := remoe.NewClient(token) hervester, _ := telemetry.NewHarvester(telemetry.ConfigAPIKey(os.Getenv("NEW_RELIC_INSERT_API_KEY"))) data, _ := remoClient.GetRawData() for _, d := range data { hervester.RecordMetric(telemetry.Gauge{ Timestamp: time.Now(), Value: float64(d.MeasuredInstantaneous), Name: "remoe.MeasuredInstantaneous", Attributes: map[string]interface{}{ "modelId": d.ModelID, }, }) } hervester.HarvestNow(context.Background()) }
New Relicで見てみる
New Relic Oneを開いて、右上のQuery Your Dataからメトリックの情報をクエリできます。Data Explorerから行っても良いですし、たとえばNRQLはこんな感じに発行してみましょう。
FROM Metric SELECT average(remoe.MeasuredInstantaneous) facet modelId TIMESERIES
データが突っ込まれましたね！
まとめ
こんな感じに、コンパクトなスクリプトでNew Relicにメトリック情報を放り込むことができるという例でした。コード全体はnewrelic-remoeで公開していますので、ご参考になれば幸いです。詳細が気になる方は@katzchangまでメンションなどいただければと思います。仕事だぜm,
キーボードを作ってみた話を書きます
こんにちは、pyspa Advent Calendar 2020の3日目の投稿になります。
今年の思い出としては長らく続く在宅勤務だと思いますし、みなさんもいろいろなガジェットで在宅勤務を成功に導いていらっしゃることと存じております。
ということで、キーボードを作りました。pyspaの皆さまにはお世話になりました。
背景
決断に至るストーリーはだいたいこんな感じです:
- Macbook Proのキーボードをそのまま使っていたが、温度が熱くなりがちなので、夏にめっちゃストレスが高まった
- 会社支給でMagic KeyboardとTrackpadがもらえるので届けてもらったが、今ひとつポジションが定まらなかった
- Samuraismさんの#MAGICTRAYPALMが良いらしいと聞き、Magic Keyboard対応の試作品を送ってもらった（ありがとうございます！！）が、残念ながらあまり手になじまず（Magic Keyboardは薄くて強度設計が難しいとのこと）
以前から分割キーボードに興味があったこともあり、もうこれは移ってしまおうということであれしました。
買い物
キーボードは主に遊舎工房の物理店舗で買いました。通販じゃパーツの声が聞こえないだろ？*1
工具は主にAmazonで買いました。ぴえんキーキャップはKochi Keyboardから。
キーボード
- Ergodash mini: 分割で数字キーなしを選びたかった（以前から数字キー打鍵が苦手だった）
- Sakurio: 静音で軽
- R2 XDA 40v2 Dye-sub keycaps: 地味めだけどかわいい
- マグネットでつながるUSBケーブル: チップのUSB端子が壊れやすいらしいので便利とのこと
- リストレスト: 分割キーボード用のやつを贅沢にも2つ横につなげて、ダラっと手首を乗せられるようにしてます。サイズ感をたしかめるために、まずはそのへんの本とかで試すと良い。
- ぴえんキーキャップ: 🥺、日本語変換キーに実用してしまってる。手触りで判別できるので意外と便利。
一度加工で失敗したので、ダイオードをAmazonで別途追加注文とかしてます。LEDキラキラは難しそうなので付けていません。
工具と消耗品
- ハンダゴテ: 温度調整ができて便利
- ハンダゴテ台
- 小手先: なんかこれが使いやすいらしい
- リードベンダー: 地味だけどこういう治具めっちゃ便利
- テスター: なくても一発勝負でいけることもありますが、そんなにうまくいかない
- ハンダ吸い取り器: 失敗しなければ要らないが、失敗すれば要る
- ハンダ
- ハンダ吸い取り線
- フラックス
あとは家にあったニッパーとか、作業台みたいなのもあるといい。木の板をつかいました。
工作
いろいろあった*2けど頑張った。
結果と今後
腱鞘炎が遠ざかり、姿勢が良くなったと言われました。今後は無線化したいけどうまく動かない。
以上、よろしくお願いいたします。
