2023年12月26日火曜日

できたこと

時系列

1月ヴァンパイサバイバープレイ
2月いいコードとはなにかについて考えた
3月育児ブログ投稿、ダイソンメンテブログ投稿
4月ディズニーランドブログ投稿
5月 LINE-mqttbot localhost 使い方ブログ投稿
6月ホームページリファクタリングブログ投稿
7月 M2pro mac mini デビュー、nifcloud sdk tips ブログ投稿、大型冷蔵庫購入
8月 Gitlab への PR https://github.com/nntarasov/csv2keychain/pull/20、サマーランドブログ投稿
9月 Python 実践資格取得、GDPR 対応
10月ホームページのライブラリ最新化 (cal-heatmap4, jquery, bluma etc
11月エンジニア感想投稿
12月突発性難聴になりました

毎月何かしらのアウトプットができてよかった
上記に記載はないが引き続き断捨離はできた
病気になりがちだった「蕁麻疹」「突発性難聴」
歯科医にも何度か通った

資格はこれで 13個になった

新しい技術への挑戦はあったがやや少ない印象
また技術以外への新しいことや趣味への挑戦がなかったのが残念
今後も「捨てる、手放す」ことが多くなりそう

その他

ブログ執筆数: 193 (12/08 時点)
Podcast エピソード数: 4

ブログもPodcastも前年比だと10-20%ほど下がっている
ネタがなくなってきたのと新しい技術へのチャレンジがなくなってきた

できなかったこと

Youtube Live (去年に引き続き)
新規アプリ開発 (去年に引き続き)

もうこれらは永遠にやらないかもしれない
戒めのために書いておく

来年の豊富

ヒゲの脱毛
iPhone 買い替え
引き続き断捨離 and アウトプット
何か新しい趣味を作りたい

今年はアウトプットが全体的に少なめだったので来年は多くしたい
ただ持つものや管理するものを増やしてしまうと断捨離した意味がないのでキャパはこれ以上増やさすぎに捨ててから新しいものを取り入れるようにする

資格は来年も取得予定だが何を取るか模索中

身辺整理がしっかりできた一年だったと思う

2023年12月9日土曜日

原因

ストレスらしい
あまりストレスを感じない方だと思っていたが意外と溜まっていたのかもしれない

発生時期

2023/12/6 3:00 頃

主な症状

右耳がかなり聞こえづらい
キーンと耳鳴りのような感じが常にする
常に水の中にいるような感じ
それによる頭痛
痛みはなし
鼓膜に影響なし -> つまり更に奥の神経の病気らしい
突発性難聴は人生で一度しかならないらしい
- もし治って同じ症状が出た場合は別の病気の可能性があるらしい、脳とか
片耳が聞こえないというだけで違和感がすごい

対処方法

ステロイド剤を漸化的に飲み続ける
- プレドニンってやつを量を減らしながら6日間
副作用が多い
- 免疫力低下、眼圧上がるなどなど
- 薬を飲んでる間は酒をやめることにした
聴力検査の実施
- 右耳はかなり聴力が落ちていた
- 特に生活音あたりの聴力が落ちていた
- 左耳も高音が聞き取れなくなっていた (これは老化らしい
- 聴力検査が難しかった (両耳ヘッドホンと片耳ヘッドで2回検査した)

改善傾向

耳抜きやあくび水を飲んだときのようにパッっと治る感じではない
薬の効果で徐々に徐々に良くなっていく感じだった
3日目くらいでだいぶ聞こえるようになったが耳鳴りが収まらない

料金

初診だったので少しお高め
薬？の関係で採血も行った
- 採血結果は一週間後にわかるらしい
診察代: 4380円 (1459点)
お薬代: 680円

その他

右耳を下にしてうつ伏せで寝るのは関係ないのだろうか
ステロイド飲みながらお酒はいいのだろうか
一ヶ月以内に治らなかった別の病気だろうか

最後に

治るといいな

2023年11月13日月曜日

10年以上エンジニアをやってみた感想

思ったこと感じたことをつらつらと
コードの良し悪しについては昔書いたのでそちらを参照してください

経歴やスキルセットなど

2010 - 2011 クラウドサービスの開発/運用 (Java)
2011 - 2013 プラットフォームサービスの開発/運用 (Java)
2013 - 2015 モバイルサービスの開発/運用 (Java)
2015 - 2016 IoT サービスの開発/運用 ©
2017 - 2018 コンテナサービスの開発/運用 (Ruby)
2019 - 2020 クラウドサービスの開発/運用 (Python, Golang)
2020 - 2023 コンテナアプリケーションの開発 (Python)
2023 - Now スケジューラサービスの開発 (Python)

詳細はこちらを御覧ください
正直業界全体については語れないので完全に自分の世界での所感になります
マネジメントなどの経験はありません

すべてはアプリケーションでありソフトウェアな気がする

Webアプリ、スマホアプリ、インフラ、ハードウェア、セキュリティ、機械学習などいろいろ経験したが最終的にはコードを書いていた気がする
コードがあった上でそれぞれの分野に追加で必要な技術が出てくる
例えば Webアプリであればフレームワーク、ハードウェアであれば電気電子回路の知識、機械学習であれば三角関数や微分積分などの数学知識といった感じ
そういった意味でどの業種もソフトウェアエンジニアであると思っている

コードから逃げてはいけない

エンジニアである限りコードは一生ついてまわるものだと思っている
なのでコードから逃げてしまうとエンジニアとして仕事ができないし成長もできなくなる
コードから逃げると自分の首をしめることになるので結局つらくなるのは自分な気がする
コードがわからない -> エンハンスやバグ修正ができない -> レガシーなコードになる -> 何もできなくなるの技術的負債ループに突入する
コードが見れないツールやライブラリを使う業務は本当につらいと思う
責任分界点という意味では楽なのかれないがスピード感がでない

汎用的なスキルを身につけよう

究極に言えばオープンな技術だけ学べばいい
理由はどこに行っても通用するため
クローズドな技術やツールは再利用できる機会が極端に少ないので別のところに行って使えないことが多い
具体的には自社ツールとかベンダー製品など
その中でもオープンな技術を学べることはあるのですべてが無駄というわけでない
API が付属していて REST のコールの仕方や SDK という技術、使い方について学べるかもしれないなど
それでもオープンな技術を学ぶほうが最終的なレベルアップ度合いは大きいと思っている
汎用的なスキルとともにスキルの身につけ方、王道のサービスの構築手法やアプローチも身に着けたい (スクラム、ウォータフロー、DDDなど)

広く深くいろいろな技術を学ぶ

深く狭くだと限定的なエンジニアになってしまいそう
いろいろなところで活躍したいなら広く深くが必要
常にリスキリングというか新しいことを学ぶ意識が大事
仕事で使っているスキルは勝手に広く深くなる
そうじゃないスキル、流行りのスキルをどうキャッチアップするか

やるべきこととやらなくていいことを見極める

自分は仕事でもプライベートでも無駄なことが嫌いなので無駄は極力排除したいと思っている
例えばコーディングにおいては最低限のことだけやる
作らなくてもいいサービスや機能は作らない
作らなくてもいいという線引きが難しいが簡単に言えば無くてもサービスが継続できるならやらなくてもいいと思っている
作ったら作ったでそれを運用するコストが出てくる
コーディングだけでなくツールの導入なども同じ、導入したらしただけそれを面倒みる必要がある
特にかくシンプルにやることを心がけたほうがいい
ただ何もしないとしないでモダンな技術に触れる機会がなくなるのでそこのトレードオフもある

最短距離を走る

無駄を作らないための手法でもある
ある機能やサービスを作るときにゴールは1, 2個だがそこまでいくアプローチは100も200もあると思っている
そのいくつもあるアプローチから最適かつ最短距離を見つけられるかが重要
ただそればっかりは技術とかではなく経験が非常にものを言うと思っている
開発の経験を重ねるとあるお題が与えられたときにパッと「あー、これはこうだからこれとこれを使えば簡単にできそうだな」「これはやりすぎだな」みたいなことがすぐに出てくるようになる気がする
オーバーエンジニアリングしない

1から全部やり直せるくらいになる

自分の経験として前任者がいなくなったサービスをメンテナンスする業務が多くあった
その中で既存のコードをメンテナンスするよりかは1から全部作り直したほうが良いケースが結構あった
そのときに既存のコードを読み解き新たに作り直せると将来的も良いケースが多くあった
よくわからないコードをメンテンナンスする、全然メンテンナンスされていない脆弱なコードをメンテナンスするくらいな作り直したほうが良いことがある
おもいって新しく作り直すという方向に舵を切れるかどうかの判断も大事

レベルの平準化問題、属人化問題

チーム全員を同じレベルにするのが難しい
開発を一人でやるとサービスが属人化する
開発後に運用でジョインするとかなり大変なので開発の段階からやったほうがいい
スキルセットの違いによるスタートダッシュをどう埋めるか
教育するしかないがそれにかかるコストもゼロじゃない
勝手に学び勝手に成長してくれるという貴重な人材

仕事以外の自分の趣味をしっかり作る

プログラミングが趣味でもいいとは思う
ようするにリフレッシュできることを作ったほうがいいという話
メリハリがあるほうが仕事もはかどるし学びの効率も上がると思っている
ストレス発散

ChatGPT

たまーに嘘をつくが便利
使いこなせば強力
トラブルシューティングや Web にないコーディング方法が知りたいときにもしかしたらと思って使う
過度な期待はしない
Google との併用
全部書いてもらいたいが技術的負債になってはいけない、自動生成されたコードはブラックボックスになりやすい

やったことは忘れないように記録する

自分もやっているがブログがおすすめ
動画だとコードの内容をコピペできないのでテキストがいい
広く深くを全部覚えてることはできないのでいつでもひっぱり出せる知識データベース的なのを作る
資格などの証明ではないが public に公開している自分の知識があればやったこと経験したことの証明になる

最後に

プログラミング楽しい
昔から図工とかものを作るのが好きだったから天職だったのかもしれない

2023年9月14日木曜日

プライバシーポリシー

個人情報の利用目的

当サイトでは、お問い合わせや記事へのコメントの際、名前やメールアドレス等の個人情報を入力いただく場合がございます。
取得した個人情報は、お問い合わせに対する回答や必要な情報を電子メールなどをでご連絡する場合に利用させていただくものであり、これらの目的以外では利用いたしません。

広告について

当サイトでは、第三者配信の広告サービス（Googleアドセンス）を利用しており、ユーザーの興味に応じた商品やサービスの広告を表示するため、クッキー（Cookie）を使用しております。
クッキーを使用することで当サイトはお客様のコンピュータを識別できるようになりますが、お客様個人を特定できるものではありません。

Cookieを無効にする方法やGoogleアドセンスに関する詳細は「広告 – ポリシーと規約 – Google」をご確認ください。

また、当サイトは、Amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイトプログラムである、Amazonアソシエイト・プログラムの参加者です。

アクセス解析ツールについて

当サイトでは、Googleによるアクセス解析ツール「Googleアナリティクス」を利用しています。このGoogleアナリティクスはトラフィックデータの収集のためにクッキー（Cookie）を使用しております。トラフィックデータは匿名で収集されており、個人を特定するものではありません。

コメントについて

全てのコメントは管理人が事前にその内容を確認し、承認した上での掲載となります。あらかじめご了承ください。

免責事項

当サイトからのリンクやバナーなどで移動したサイトで提供される情報、サービス等について一切の責任を負いません。

また当サイトのコンテンツ・情報について、できる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。情報が古くなっていることもございます。

当サイトに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。

著作権について

当サイトは著作権や肖像権の侵害を目的としたものではありません。著作権や肖像権に関して問題がございましたら、お問い合わせフォームよりご連絡ください。迅速に対応いたします。

リンクについて

当サイトは基本的にリンクフリーです。リンクを行う場合の許可や連絡は不要です。

ただし、インラインフレームの使用や画像の直リンクはご遠慮ください。

2023年8月2日水曜日

料金

合計: 35300円

あくまでも目安です
時期やご飯代などを節約すればもっと安くなります
人数は家族4人分になります

料金詳細

入場料: 4200 + 4200 + 2900 = 11300
車代: 8000 + 2000 + 1000 + 2000 = 13000 (レンタル、駐車場、ガソリン、高速代)
園内での食事代: 約5000円
晩飯: 約5000円
お菓子: 1000円

サマーランド持ち物

水着、浮き輪、ゴーグル、帽子、サンダル
防水ケース (スマホ、財布など持ち歩く用)
バッテリー、充電器
リップ
スマホスタンド (カーナビ用)
タオル大量 (体拭き、寒いときに羽織る用)
財布 (免許証)
日付指定整理券の取得と紙の割引券 (整理券だけだと割引を受けれないので注意)
レジャーシート
着替え (パンツ、靴下など) 着替え入れ用の袋、ゴミ袋
お菓子 (任意
サンシェード (外に陣取るなら
クーラーボックス (クーラーの効いた部屋以外で陣取るなら

その他

開園は9:00
夏季特別割引券 (スシローとか配っているやつ) で入場する場合は事前に asoview で整理券を取得して更に当日チケットカウンターで割引券を持参して購入する必要がある

2023年7月12日水曜日

買ったもの

日立冷蔵庫幅60cm 470L 右開き R-HS47SG S シルバー

購入当時はセールで 164,800円でした

搬入時のポイント

幅が60cm だったので左右幅が80cm以上あるのが理想のようです
自宅はギリギリで 79cm ほどの幅でした

増員

当初は二人で搬入予定だったのですが三人に増員して対応していただきました

経路の確保

階段、廊下などのものはすべてどかしました

掃除

どかしたものや冷蔵庫の天板の掃除などはしておきましょう
動かせるのであれば動かして床の掃除もしておきます

日程調整

最初訪問してもらったときに人数が二人の予定だったのですがそれだと厳しいということだったので日程を再調整してもらい三人に増員してもらいました

冷蔵庫の中身の入れ替えタイミング

自分は直前で大丈夫でした
古い冷蔵庫は回収してもらうようにしたので古い冷蔵庫の電源をオフにしたタイミングで中身を全部取り出して別の場所で保管し新しいのが設置されたらすぐに入れて電源をオンにしました

冷蔵のものは保冷バック＋保冷剤で冷やしておきましたが外に出ている時間が 30分から1 時間程度だったので最悪何もしないでもいいかもしれません

設置直後の冷蔵庫は全然冷たくないので注意

特に大型の冷蔵庫だと中が完全に冷たくなるまでに4,5時間はかかるかなと思います
今回購入した冷蔵庫には急速機能があったので設置後すぐに急速にしましたがそれでも冷蔵庫が使えるまでに 2,3 時間はかかったかなと思います

製氷に関しては翌日に無事作成できていることを確認できたので当日は厳しいかなと思います

リサイクル料金など

設置、搬入料金 -> 0円
リサイクル料金 -> 3740円
増員費用 -> 0円

一度家の中を見て二人だと厳しいということで別の日程調整をして三人に増員して作業してもらいましたが特に増員費用などは取られませんでした

最後に

冷蔵庫は洗濯機に比べて搬入経路の幅がかなりシビアなようです
というか余裕がないと普通に断れるようです

2023年7月4日火曜日

nifcloud sdk for python でカスタムヘッダを設定する方法

nifcloud sdk for python は botocore を使っているので botocore レベルでヘッダをカスタムする必要があります

環境

Python 3.11.3
nifcloud sdk for python 1.6.0

サンプルコード

from nifcloud import session

def add_custom_header(request, **kwargs):
    request.headers['Custom-Header-1'] = 'Value-1'


class NifcloudClient:
    def __init__(self, region: str, access_key: str, secret_key) -> None:
        # 先にセッションを作成する
        custom_session = session.get_session()
        # 作成したセッションに対して before-send イベントに対してカスタムヘッダを設定するためのハンドラを登録する
        custom_session.register("before-send", add_custom_header)
        # custom_session を使ってクライアントを作る
        self.client = custom_session.create_client(
            "computing",
            region_name=region,
            nifcloud_access_key_id=access_key,  # type: ignore
            nifcloud_secret_access_key=secret_key,  # type: ignore
        )

動作確認したい場合は適当にエコーサーバとかを立てて endpoint_url を設定してリクエストの内容を覗いてみてください

参考URL

https://botocore.amazonaws.com/v1/documentation/api/latest/topics/events.html

2023年6月9日金曜日

M2Pro mac mini デビュー

MacBookAir late 2014 から M2pro の mac mini に乗り換えたのでメモ
裏側のシールを剥がさないと箱が開けられないので注意してください

価格

158,000円

整備品を購入しました
50000円分はギフトカードで購入しています

スペック

CPU 10 コア (M2 pro)
GPU 16 コア (M2 pro)
メモリ16GB
SSD 512GB
Ventura 13.4

セットアップ

HDMI ケーブル
Magic Keyboard2
Bluetooth マウス (ドングルあり)

あとはネットワークやら AppleID ログインをするだけです
基本はポチポチしながら進めるだけです

キッティング

https://gist.github.com/kakakikikeke/7578465

これを参考に進めました
インストールできなかったツールなどは特になかったです
システム設定などは一部場所が変わっていたので少し戸惑いました

あとはブラウザアプリでの各種ログインがめちゃくちゃ面倒でした

つまづいた点

VirtualBox がインストールできない

バージョン7のプレビルドバージョンならインストールできました

試しに Ubuntu18.04 を vagrant 経由で起動してみましたがやはり動作しませんでした

Homebrew のパスが変わっていた

/usr/local/opt -> /opt になっていました
もしかするとこれは Mac の話ではなくて macOS 側のバージョンの違いによるものかもしれません

感想

当初は使えないツールがありそうだなと予想していたのですが思いの外全部使えてびっくりしました

ラップトップの場合だとマイクとカメラがあったのですがデスクトップタイプだとないので代替を考えなければいけなさそうです (iPhone のカメラとマイクが使える機能があるらしいそれで代用できるだろうか -> 試してみた感じだとできそう)

あとはトラックパッドもなくなってしまったのでそれも心配です

モニタが少し遠いところにあるのでモニタの解像度を上げると文字が小さくなりすぎて見えないので解像度は下げて作業しています
少しもったいないので作業場所を考えたいです
常設モニタが一つ mac mini に専有されてしまったので代替を考えたいです (iPad を使うか iPhone で我慢するか)

やりたいこと

AI 関連のモデル生成
GPU マイニング (もう終わったが)
ゲーム

最後に

せっかくいいスペックのマシンを購入したのでちゃんとその恩恵を受けれるように使っていきたいです
開発でその恩恵を受けれるかは不明ですが、、(emacs とか lsp とか docker の速さは変わるのだろうか)

2023年6月1日木曜日

コード概要

Ruby + Sinatra
redis

エディタは emacs で solargraph + robe で開発しています

リファクタ方針

ハッシュベースのルーティング定義をクラス化
rubocop の導入
TwitterAPI v2 への対応

クラス化について

routing = {
  '/about': {
    tpl: :about
  },
  '/apps': {
    tpl: :apps
  }
}

...

routing.each do |path, info|
  get path do
    # パスに応じて特定の処理をする場合は分岐
    erb info[:tpl]
  end
end

こんな感じでハッシュで定義してループで動的にルーティングを定義していたのを

class AboutPage < Sinatra::Base
  def initialize
    @path = '/about'
    @tpl = :about
  end

  def routing
    AboutPage.get @path do
      erb @tpl
    end
  end
end

こんな感じでクラスベースにして Rack::URLMap.new に設定します

メリット

ルーティングごとに分岐しなければいけない処理が複雑化しない
xxxPage クラスの親クラスを作って共通処理を抽象化できる
もしくは Mix-in を使って処理を共通化し特定のページでのみ使い回せる

デメリット

ルーティングを追加する際にクラスを追加しなければならない
ファイルが増える

rubocop について

基本は rubocop が出す警告などは全部対応します

基本辛いが特に辛い点

Metrics/MethodLength
Metrics/AbcSize

Method に限らず Block, Class, Module が長すぎるという警告に対応するのは大変です
個人的には以下のように対応しています

メソッドに分割
抽象クラスの作成
One line 記述を使う
ハッシュなどのデータは外部ファイルに移動して JSON.parse(File.read('xx.json')) する

rubocop っぽいコードになる

特に以下のような記述が増えます

ガード
細かいメソッドやモジュール、クラスに分割される
クエスチョンマークを使ったメソッドが増える
get set などを使ったメソッド名が消える
freeze がよく出る
__dir__ がよく出る
クラスやモジュールの先頭に必ずコメントが出てくる
do .. end or {} の使い方が明確になる
ハッシュは {key: 'value'} のような記述になる
ダブルクォートは使わなくなる
リテラルが増える

特に2つ目の細かいメソッドやモジュールへの分割ですがこれが個人的に何ともというか本当に良いコードになっているのか微妙でコードを読むときにいろいろなところにジャンプしなければいけないのが辛いかなと思っています
行は増えますが単純に上から処理を辿って行くだけで読み解くことができるコードのほうが自分は見やすいかなと思っています

rubocop は他の言語の linter に比べてかなり厳しい印象です

TwitterAPI v2 化について

古いアプリが pending され使えなくなっていたので新しく作り直したのと新しいアプリは v2 を使うようにしました (参考)

gem によっては v1.1 しか使っていないので v2 化していない部分は自作しました

全体通して

個人的にリファクタリングはテストを書くくらい嫌いです
理由はリファクタリングが直接利益につながることが少ないからです
また際限がなくどこまでもできてしまうのと人による好み (バイアス) により記述が変わるので正解がありません

今回のリファクタリングの目的はコードをキレイにしてメンテナンスしやすいコードにするというよりかは Ruby 力を高めるためにやりました

コードフォーマットについて

外部に公開しているコードは linter などを適用したほうがいいと思うのですが Ruby の場合いろいろな linter や formatter があるのでなかなか万人に共通するコードにするのは難しいかなと思います

また Sorbet や Tapioca など静的解析ツールがまだまだどうなるかわからないのでそれに追従すると特殊な記述がコード内にいろいろと現れます

lsp の登場による影響なのかもと思ったりしていますが最近は Type hint がやたら流行っている気がします
型があったほうが堅牢なコードにはなりやすいとは思います
ただ Ruby の場合 lsp のために (エディタのために) コード内に記述しなければいけないコードがあったりするのでそこは少し本質とは異なるので歯がゆいかなと思っています (実際になくても動くのであればないほうがいいのかなと)

Ruby の場合は無理して Type hint しなくてもいいのかなと思っています
Try & Error や Spec テストで補えばいいのかもしれません

テストについて

大規模リファクタリングをするときにテストがあるかないかで負荷がだいぶ変わってくる気がします
特にユニットテストではなく外部からテストするような運用テストなどがしっかり備わっているかどうかで大規模リファクタリングに踏み出せるかどうかが決まると言ってもおかしくないかなと思います

2023年5月12日金曜日

LINE-mqttbot を localhost でテストする方法

概要

自作の LINE-mqttbot のデバッグ方法をいつも忘れてるのでメモしておきます

ngrok を使います

環境

macOS 11.7.6
Ruby 3.2.1
- line-bot-api 1.28.0
LINE-mqttbot

準備その1: コード取得

git clone https://github.com/kakakikikeke/LINE-mqttbot.git
cd LINE-mqttbot
bundle install

準備その2: MQTTブローカーの準備

なんでも OK です
今回は CloudMQTT を使います

準備その3: LINEビジネスアプリの登録

https://developers.line.biz/console/ ここから登録します LINE アカウントがあれば登録できます

トークンなどの必要な情報をメモしておきましょう

チャネルID (LINE_CHANNEL_ID)

チャネルシークレット (LINE_CHANNEL_SECRET)

チャネルトークン (LINE_CHANNEL_TOKEN)

「セキュリティ設定」の IP アドレス制限は今はないらしいので既存の設定がある場合は削除しておきましょう

起動する

LINE と MQTTブローカの必要な情報を環境変数に設定して起動します

LINE_CHANNEL_SECRET=caxxx \
LINE_CHANNEL_TOKEN=Ckxxx \
MQTT_HOST=m11.cloudmqtt.com \
MQTT_PORT=10707 \
MQTT_TOPIC=topic_name \
MQTT_SUB_TOPIC=topic_name \
MQTT_QOS=0 \
MQTT_USERNAME=username  \
MQTT_PASSWORD=xxxxxxxxxxxx \
bundle exec rackup config.ru

ngrok でグローバルからアクセスできるようにする

9292 ポートで起動するのでそれを ngrok でアクセスできるようにします

ngrok http 9292

払い出された URL はメモしておきましょう

ngrok の URL を LINEビジネスアプリのWebhook URL に設定する

MessaginAPI 設定 -> Webhook 設定 -> Webhook URL

https://xxx.jp.ngrok.io/callback という感じでちゃんと最後に /callback を設定するのを忘れないようにしましょう

動作確認

mosquitto_sub -h m11.cloudmqtt.com -p 10707 -t 'topic_name' -u 'username' -P 'xxxxxxxx'

でメッセージが受け取れるか確認します

あとは携帯やデスクトップ版の LINE アプリから LINE ビジネスアプリと友達になりメッセージを送信して MQTT にまでメッセージが来るか確認すれば OK です

最後に

ngrok の URL は毎回ランダムなものが払い出されるのでそのたびに LINE ビジネスアプリの WebhookURL に設定してあげましょう
ローカルでの動作確認なのでランダムで払い出される URL のほうがセキュアかなと思います (ngrok の場合 URL さえ知っていれば誰でもアクセスできてしまうので)

トラブルシューティング

CloudMQTT は長時間使われていないと停止するので Connection Refuse になる場合は一旦 ResetDB してみてください

2023年4月4日火曜日

家族四人でディズニーランドに行くとかかる料金

備忘録として残しておきます
2023年2月の時点での料金になります
時期によっても異なる部分はあると思います
夕食はパーク内では取らなかったので夕食代は除外しています

まぁ高いですね

構成

大人2人
小人1人
幼児1人

合計

47780円

入場料

8400 * 2 = 16800円
5000 * 1 = 5000円

小計 21800円

交通費

高速代 1950円 * 2 = 3900円
ガソリン代 1000円
駐車場代 2500円
車代 7210円

小計 14610円

飲食代

昼飯 (ヒューイ・デューイ・ルーイのグッドタイム・カフェ)

ミッキーピザ (チェダーチーズ＆ソーセージ) 1230円 * 2 = 2460円
グローブシェイプ･エッグチキンパオ 1080円 * 2 = 2160円

軽食

ミッキーチュロス(シナモン) 450円 * 3 = 1350円
スモーキーターキレッグ 900円 * 2 = 1800円
飲み物 200円 * 2 = 400円

小計 8170円

お土産

バウムクーヘン 1400円
カチューシャ (スパンコールキラキラ) 1800円

小計 3200円

2023年3月1日水曜日

ダイソンV6メンテナンスメモ

2016年に購入したV6を未だに現役で使用しています
長く使い続けるためのメンテナンス方法を紹介します

バッテリー

2,3年に一回は交換が必要
4000mAh でも 30 分くらいしかフル稼働しない
参考

フィルタ

掃除

1ヶ月に一回は水洗いすること
縦長とMaxボタンがあるところのフィルタ
乾燥が必須なので予備で2セットあると便利

交換

2,3年に一回は交換が必要
交換の目安は縦長のフィルタが洗っても真っ黒な状態になったら

モーターヘッド

モーターブラシ掃除

半年もしくは1年に一回は水洗いすること

モーターヘッド掃除

半年もしくは1年に一回は水洗いすること
六角星型ドライバがあれば解体可能
特にモーターブラシが当たるシャーシの部分はかなり汚れやすい

ジャバラ

2,3年に一回は交換が必要
モーターヘッドとロングパイプの間くらいにあるジャバラ
首振りを多用しているといつの間にかボロボロになっている
ここがボロボロのままにしておくとモーターヘッド装着時の吸引力がかなり落ちる
モーターヘッド装着時に移動が軽くなり始めるとジャバラがボロボロになっている可能性がある

交換

動かなくなったら交換でOK
電気が届いていない、モーターが焼ききれているなどが考えられ対策できない
ジャバラに関しては別途購入して交換できるのでジャバラがボロボロになってもモーターヘッド自体の交換が必要なわけではないので注意

最後に

フィルタを毎月洗いつつ一年に一回各種パーツのメンテや調子を見ればいいかなと思います

2023年2月13日月曜日

育児について感じていること

二人の子供をそれなりに育児してきて感じたことをまとめておきます
あくまでも個人的な意見になります

コンテキスト

こちら

人間だからイライラはするが基本は怒らない

育児の極意はこれに尽きると言ってもいいかなと思います
とにかく怒らないことイライラをいかに避け抑えるかだと思います

たまーに自分も怒りますがほぼ怒らないようにしています
理由はいろいろありますが一番は自分が怒っても誰も何も得をしないからです (怒っても意味がない)

やりたいようにやらせてあげる、絶対ダメなことはダメだとしかる、メリハリが大事

怒らないと言っても躾はしっかりします
「ルールを守らなかったとき」に躾をします
子供と同じ目線に座りしっかり前を見て子供に言い聞かせます
ただこのときも怒ってはいけません
あくまでも躾として言い聞かせているという意識が大事です
怒ってしまうと子供にも怒りの気持ちが伝わり悲しい気持ちになってしまうのでそれだと躾の意味がありません
「怒ってはいないんだよ、ちゃんとルールは守ろうね」というのが伝わるようにしてあげます

基本はやりたいようにやらせてあげています
子供が「公園でもっと遊びたい」「大人のものを使ってみたい触ってみたい」ときなど子供の好奇心による行動は基本的には制限しないようにしています (もちろんルールをやぶったり、危険ものは触らせてはダメです)

というのも例えば公園で遊んでいて無理に「帰るよー」と言っても子供は帰りません (たぶん経験している人は多いと思います)
そういうときは逆に飽きるまで遊ばせてあげると結構すんなり帰ってくれます
子供といえど結局は人なのでお腹が空いたり疲れたりすれば帰ろうと気持ちになるんだと思います

大人の都合で帰るとかダメとか言うのは結果的にいろんな意味で遠回りすることが多い気がしています

子供の行動を予測してこれからどういうことが起きるかある程度予測できればあまりイライラしない

子育てでイライラしない方法の一つとして「予測」があると思っています

例えばご飯を食べているときに茶碗をひっくり返したり水をこぼして水浸しになることがよくあります
このときに「なにやってるの！」と怒ってはいけません
子供なのでそういうことは多分にあります
そこでイライラしてしまうのはそういうことが起きないと先入観を持ってしまっているからで人間は予期しないことが起こるとイライラしたりします

だったら始めから「これからご飯だから床が大変なことになるだろうなー」「よごれてもいいように準備しておこう」と思っておけばいざ先程のことが起きても意外とイライラせずサッと対応できます
逆に予測を裏切って子供がまったくこぼさず上手に食べれると勝負に勝ったような気分になり子供を褒めたりいいことが起きやすくなると思っています

こんな感じであらゆることを事前に予測しておくと少しでもイライラを抑えられるようになるかなと思います

大人の都合と子供の都合

大人･･･時間がない、やることがある
子供･･･遊びたい、やりたい

こんなときにいかに子供を優先できる余裕が持てるか持てないかかなと思います

自分を俯瞰できるようにする

これは怒ってしまっているときに使えるテクニックで怒りを鎮めるときにいいかなと思っています

子供にでも何にでもそうですが怒っているときにその怒っている自分を俯瞰して見てみましょう (見てみましょうと言っても普段から俯瞰的に自分が見れていないとなかなか難しいですが)
そうすると「あーなにやってるんだろうなー」とか「子供にマジ切れしてる自分の姿はかなしいなー」などと感じることができるようになります
そうすると自分を抑えることができます

一歩引いて他人の目線から自分を見ると自分がどういう状態なのかすぐに把握でき、自分のニュートラルな状態にすぐに戻すことができるようになります

子供の気持ちになってみる

俯瞰することは子供の気持ちになってみることに近いかなと思います
どうして子供が泣いているのか、どうして子供がそうしたいのかというのが子供の立場になって考えてみるとわかることがあるかなと思います

ルーチン化する

子育ては単純ではないですがやること自体は単純なことが多くルーチン化することができます
たとえば「仕事終わり -> 保育園のお迎え -> 公園で遊ぶ -> 帰ってきて手洗いうがい -> お風呂沸かす -> お風呂入れる -> からだ拭く -> クリーム塗る -> パジャマ着る」という流れは毎日自分がやっている流れなのですが毎日のようにやっていると体が慣れてきて大変だなと思わなくなります
やって当然だと思えてきます

またやることがわかっているので無駄な時間を使わずに最短距離で駆け抜けることができるのでストレスなく進めることができるようになります

たまにイレギュラーなことは当然起こりますがその場合も「予測」と「俯瞰」で何とかなります

慣れるが怠惰になってはいけない

ルーチン化することはいいことではあるのですが慣れすぎて怠惰になってはいけないかなと思っています
人間は慣れてしまうと怠惰になり思わぬミスを招いたりします
慣れという流れの中に少しでもノイズが入ってくるとそれだけでイライラしたりします

ルーチン化しつつも常にそのルーチンの精度をあげる、成長させるという意識を持ちながらやるといいかなと思っています

ルーチン化した上で効率化する

ルーチンをリファクタすることはいいことです
実はルーチンの中に無駄なことやいらないことがあったりするのでそういったものは削ぎ落としましょう
またルーチンの精度を上げるために新たにものを取り入れるのもいいと思います
例えば先程のルーチンの中だとお風呂から上がったら必ずクリームを塗ってパジャマに着替えるという流れがあります
この流れの中で「タオル」や「クリーム」「パジャマ」などは事前に準備しおくことができます
事前に準備しておけば子供たちもやることがわかるし協力もしてくれるので時間の節約にもなります

こんな感じで自動化ではないですが事前に準備できることを前もってやっておいたりしておくと楽にこなせるようになったりします

おもちゃの扱いについて

これも子育てテクニックなのですが子供が遊ぶおもちゃはちょっと工夫するだけで長く飽きずに使えるかなと思っています

定期的に入れ替える

我が家ではおもちゃの置き場所は2つあり「常に子供の目につくおもちゃ置き場」と「保管しておくおもちゃ置き場」があります
大事なのは後者で後者は子供だけだと簡単に取り出せない場所にあります

子供は新しいおもちゃを買ってあげるとすごく喜びます
しかし一週間、一ヶ月もすると大抵飽きて遊ばなくなってしまいます
せっかく買ってあげたおもちゃをすぐに遊ばなくなると大人も悲しいのでおもちゃは定期的に入れ替えてあげるようにしています

ちょっと面倒かもしれませんがこれだけでもかなり効果があるかなと思っています
またもう少し言うとおもちゃは雑多に置かずにきれいにしまっておくと子供も毎日新鮮な気持ちでおもちゃと遊んでくれるような気がしています

自分の趣味を必ず持つ

ここからは少し話が変わりますが子育てを長く楽しく続けるテクニックの一つとして自分のコントロールが非常に重要だと思っています

「予測」や「俯瞰」は子育ての中のテクニックですが子育て以外でも自分をコントロールできるようにしておくと結果的に子育てにもいい影響があるかなと思っています

趣味でなくてもいいのですが自分への「ご褒美」的にものを作っておきましょう
自分では感じないけどストレスが溜まっているケースは少なからずあるのでそういったストレスを発散できるような趣味があるといいかなと思っています

大人になってから没頭できる趣味を探すのは本当に難しいと思っています
それは時間や場所が制限されるからです
仕事と子育てで大抵の時間が取られてしまうのは当然ですが自由な場所に行けないというのも趣味が作れない一つの要因かなと思っています
限られた時間と場所の中で何か一つでいいからストレスを発散させられるものがあるといいかなと思っています

なぜなら子育て中でもその趣味ができると思えるようになると頑張れる燃料になるからです

何かしらの犠牲は必要

お父さんなのかお母さんなのかは状況によりますがどちらかが何かしらの犠牲を払って子育てに時間をさく必要がでてきます

犠牲はいろいろありますが例えば

今まではガッツリ残業できていたができなくなる (逆にいいことだと思います)
今までは週末にスポーツをしていたけどできなくなる
朝はゆっくり出社していたけど学校や保育園の時間があるからできなくなる

などなどいろいろあるとは思いますが大事なことは「今までできていたことができなくなる」という認識は事前に持っておいたほうがいいかなと思します

逆に子どもたちと一緒に入れる時間が増えるというのもあるので子どもたちと新しい趣味に一緒に挑戦するのもいいかなと思います

その他、所感など

5歳くらいになるとかなり楽になる
(これから先どうなるかはわからないが) 一番つらかったのは2.5から3.5歳

最後に

子育てに正解はありません
日々試行錯誤です

子どもたちと一緒に日々成長していく自分を楽しみましょう

2023年1月22日日曜日

いいコードとはなにか考える

つらつらと思っていることを書き連ねてみます

まとめ

シンプルイズベスト
コードがいいかわるいかよりもコードを深く理解しているかが重要
バグがなければ何でもいいんじゃないか

メンテナンス性について

いいコードはメンテナンスのしやすいコードなのか
メンテナンスしやすいコードは気軽に変更できる、変更しても影響が小さいなどがあると思う
でも結局はコードをしっかり理解しているかどうかな気がする
コードを理解していないと気軽に変更も影響範囲もわからないので
あとはテスト周りがしっかりしているか、ユニットテストのカバレッジやe2eテストがあるか、CDできる環境があるかも重要
毎回手動でテストするのは辛いし、そうなっているとリファクタリングする気も起きなくなる
今はいいコードだと思って書いても結局1, 2年後見たとときに理解できなかったダメなのでは
何も気にせずファイル1つで全部そこに上から順番に処理するようなスクリプトならどうだろうか

手法について

世の中にはコーディングに関するいろいろな手法や書籍がある
いろいろあるがいろいろありすぎて困る
個人的には一番意識するべきは結局シンプルイズベストだと思う
いかにシンプルに無駄なことをしていないか＝いいコードなのかも
コードをシンプルに書くとは簡単に言えば一番上から順番に実行されていくコード
いきなりどっかに飛んだり暗黙的なハンドラが呼び出されたりしない
あるゴールがあるときにいろいろな書き方があるがその中から最適を選択できるかどうか
選択できるかどうかは経験則だと思う
いきなり良いコードは書けないから徐々に良いコードにしていけばいいと思う
それをできるかどうかも結局はコードをしっかりと理解しているかが重要だと思う

可読性について

いいコードは読みやすいコードなのか
メンテナンスしやすいコード＝読みやすいコードと言えるのだろうか
結局コードを知るためにはある程度学習しないとダメだとは思う
いいコードだと学習時間が短いとは限らない
コード把握までの時間を短くするにはドキュメントとトライアンドエラーさせることだと思う
いいコードはしっかり抽象化できるている、重複がないというのがよくあるケースだと思うが個人的には抽象化されてすぎていても良くないと思う
その心はコードがいろいろなところに分散しすぎていて追いづらいというのがある
可読性を高める最強の要素は「コメント」と「ドキュメント」なのかもしれない
チームが日本人なら無理に英語にしないで積極的に日本語を使っていいと思う、コミットメッセージとかIssueとか

バグとの関連について

いいコードはバグのないコードなのか
個人的にはこれはイコールではないと思う
わるいコードでも全然バグを踏まないコードもあると思っている
むしろレガシーコードのほうが安定しているケースもあると思う、いいとは思わないが
いいコードにしようと思ってバグを埋め込んではいけない
がバグをおそれてリファクタリングしないのもダメだと思う、難しい
結局バグを生み出さないこと品質を担保することが大目的なのであればレガシーコードを運用し続けるのも手だと思う
ただ将来の技術的負債になることは間違いない
レガシーコードにバグがいきなり発生して誰も直せないパターンとかはあるある
レガシーコードを書き換えてモダンコードにするよりかは式年遷宮で全部書き換えるのがいいと思う
当然インタフェースは変えないようにしなければいけないが
v2移行などで多少のインタフェース変更が出てしまうことはよくあるのでその場合はドキュメントやコミュニケーションでカバーするしかない

そもそも悪いコードとはなにか

相対する言葉の悪いコードとはなにか
アンチパターン的なことなのだろうか
悪いコードを書かないようにすれば自然といいこーどになるのかもしれない
そのコードが悪いと客観的に感じることができるかも重要
なかなかそれは経験がないと難しいかもしれない

チームビルディングについて

いいコードは人によって異なると思っている
なのでチームで一つのコードを開発すると個人の思想や経験がコードに反映されてしまうことがある
そういうときのために設計思想や開発手法やデザインパターンやフレームワークみたいなものがあるんだと思う
がそれでも多少のブレはある
基本はチーム内でコーディング規約などを決める感じにはなる
いいコードを書くためにはある程度の経験が必要だと思っている
なので経験のある人の思想がチーム内のコーディング規約に大きな影響を与えてしまう可能性がある
チームがそれを合意できるのであれば問題ないが押し付けるのはよくないと思う
すでに安定しているコードに対してわざわざそれを適用するのかという判断も重要
将来大きな技術的負債になるのであればやるくらいでいいと思う
全員が全員同じレベルのコーダになるのは本当に難しい

テストについて

テストもいいコードとして書く必要があるか
テストも抽象化やリファクタリングをし続けたほうがいいのか
そこまでのコストが割けるか、売上には直結しない
プロダクトの品質には影響するかもしれない
テストの目的はカバレッジを100%にすることではなく開発者の精神安定
テストがしっかり書けている -> 積極的に安心して書き換えできるという意識が重要
ただ個人的に思うのはテストはおまけでしかないので面倒だということ
その面倒な作業を誰かがやらなければならないということ
分担すればいいというのもあるがそうするとテストコードの書き方がバラバラになりテストの保守性が下がってしまったりする
個人的にはテストコードを書くのは嫌いである

コンテキストによっても違う

ちょろっとスクリプトを書くときには
Webアプリケーションやスマホアプリのときには
一時的にしか使わない場合
将来的に継続的に使う場合
どんなときでもクラスベースなコーディングが必要なのか

番外編: AIにがんばってもらう

copilot のような自動生成にがんばってもらう
AI が書くほうがいいコードなはず
AIではないがコードジェネレータを作成するのもいいと思う

問題: どっちがいいコードなのだろうか

puts "hello"

require 'logger'

class Message

  @@logger = Logger.new(STDOUT)

  def initialize(title)
    @title = title
  end

  def say()
    @@logger.info @title
  end
end

Message.new("hello").say

用途にもよる？
将来どうメンテナンスしていくか？
経験のあるなしに影響する？

2023年1月14日土曜日

ヴァンパイアサバイバーiOS版プレイメモ

環境

iOS 版バンパイアサバイバー 1.2.119
無料

プレイ時間

たぶん 40 時間くらい

操作について

画面を上下左右に動かすことでキャラクターを動かす
ストップボタンが右上にあるので押しづらい
ランドスケープでもポートレートでもプレイ可能
画面が小さい端末だとステージの最後のラッシュとかは見えないかも

ゲームについて

クリア

一応各ステージクリアはあるがそれよりもレリックや装備開放、仲間開放などがクリア要素は強そう
- ゲームトップにあるアンロック、コレクション、シークレット一覧を全部アンロックできればクリアでもいいかも
- シークレットキャラの出現方法は正直攻略サイトを見ないとわからない
- スマホ版の場合 exdash と toastie と smith iv はシークレットの一覧画面から矢印で呪文入力になるのでそこで呪文を入れて開放する
ステージ5とユーダイモニアMにはそれっぽいボスがいる
- ユーダイモニアMのクリア後に極大聖年が手に入るがコレクションにない場合は一回ステージでレベル上げをして武器として取得すればコレクションに入る
30秒後の最後の悪魔は倒すことができる、倒すとたまご5つと最後に白黒の悪魔が出てきて倒される
- 倒すとレッドデスというキャラが使えるようになる
シグマが強すぎる
- コレクションコンプリートで使えるようになる