日頃の行い

個人的な日頃の行いをつらつら書いてます\\\\ ٩( 'ω' )و ////

楽天の株主優待でSIMカードをもらってRakuten WiFi Pocket 2cに挿して使ってる話

2023年12月時点で楽天の株を持っていたので、株主優待楽天モバイルSIMカードがもらえました。
(楽天ポイントNBAを期待してたので楽天モバイルに変わったときはちょっと悲しくなりました。)

株主優待制度|楽天グループ株式会社

自分は元々デュアルSIMで日本通信SIMとpovo*1を使っていてあまり使うことがなかったので、どうしようか悩んだ末にポケットWiFiで使えば外でPCで使ったり妻も使ったり出来るじゃーんってなったのでポケットWiFiを買ってそこにSIMカードを入れて使うことを検討しました。

最終的にはRakuten WiFi Pocket 2cを購入して使っています。
今年が特殊で1年分もらえるだけだと思っていて*2、来年以降はもらえないかもしれないですが、ポケットWiFiを検討されている方の参考になるといいなと思います。

検討したこと

せっかくポケットWiFi買うなら楽天モバイルSIMカードがもらえなくなったときも考えた上で買うかと思っていくつか検討していました。
個人的に考えた欲しい要件的には下記ポイントでした。

候補となった他のポケットWiFiたち

ポケットWiFi eSim対応 5G対応 価格
network.mobile.rakuten.co.jp × × ¥7,980
× × ¥13,800
¥38,280
× ¥21,780
× × ¥13,600

eSIM対応

eSIMに関しては出来たら欲しかったのですが、これを考えるとほぼ一択富士ソフト(Fujisoft) 5G対応Wi-Fiモバイルルーター +F FS050W になるため、ポケットWiFiを継続的に使うかまだ怪しいなと思うと価格との天秤にかけた時に負けてしまい諦めることにしました。
オフラインのカンファレンスなど増えたらちょっと考えたいという気持ちになりつつ、ただそれもpovoのテザリングとかで良いじゃんってなりそうな気持ちになっています。

5G対応

せっかく5Gが広がってきているので5G対応のものがいいかなーと思っていました。
ただ、現在そこまでポケットWiFiで対応しているものが多くないみたいだったので、まあいいかと許容することにしました。

できるだけ安い

結果として残ったのは価格のみとなり、¥10,000を切るRakuten Wifi Pocket 2cでいいじゃんという気持ちに落ち着きました。

使い勝手

家付近の散歩にしか使っていないのですが、たまに弱くなるなと感じることがあります。
通信エリアを見る限りだと、そう感じるのが4GLTEと5GSub6の境目あたりなのでその影響もあるのかなと思っています。
優待でタダなのでまあいっかという気持ちで使っています。

network.mobile.rakuten.co.jp

感想

  • そんなに外に出ないのもあり、30GB使い切らないので気軽に外で動画とか見れて便利
  • たまに通信が弱い部分があり、そこが少しネック

こちらもおすすめ

arata.hatenadiary.com

arata.hatenadiary.com

*1:ちなみにpovoの紹介コードは「L3JPDWA3」です

*2:元々は最低3ヶ月~最高6ヶ月の優待だった 剰余金の配当(無配)及び第27期 株主優待制度(内容変更)に関するお知らせ | 楽天グループ株式会社

SESAME 5 ProとSESAMEタッチProとオーダーメイドの特殊アダプターでドアノブ型の家の鍵をスマートロック化した話

タイトル通り家の鍵をSESAME Proにして、指紋認証スマホで鍵を開けられるようになりました。
ずっとやりたいなと思ってたんですが、鍵のタイプに対応するアダプタが特殊アダプタのみだったので、めんどくさくなっていました。
結果的には(特に酔っ払って帰ってきた時など)カバンから鍵を出すのがだるいなってときとかにめちゃくちゃ便利になり、さっさとやればよかったと思いました。
余談ですが、ついこの前鍵を忘れて出ていって妻も家にいない状態だったのですが、その状態でも入れてやっといてよかったと本当に思いました。

SESAMEについて

スマホのアプリや指紋認証などで鍵を開けられるようにするもので、いわゆるスマートロックと呼ばれるものの一つです。
後述するように他にも候補はありますが、対応する鍵の種類(サムターン)が多く、今の家の鍵に対応しているという点からSESAMEを選びました。

購入

Amazonでも買えますが、圧倒的に公式が安いのでそっちで買うことをおすすめします。

Amazon

公式

特殊アダプタの対応

特殊アダプタのページに↓のようにあるので、注文番号と鍵の写真を添付してメールを送りました。

オーダーメイドアダプターをご注文された方は、必ず一度sesame@candyhouse.coまで鍵のお写真とJPから始まる注文番号をお送りください。

そうするとドアノブの寸法と写真を送るように言われるのでそれを適宜測り、送りました。
内容としてはこのような感じです。

  • ① ドアノブ寸法
      1. サムターンの厚さ: mm
      1. サムターンの直径: mm
      1. 土台からノブ端までの高さ:   mm
      1. 土台の高さ: mm
      1. 土台の直径: mm
      1. ノブの直径:  mm
      1. サムターンの高さ:   mm
  • ​②上記A〜G部分の定規を当てたお写真
メールの流れ
  • 6/3 15時頃(送信) 注文番号と鍵の写真を送る
  • 6/4 12時頃(受信) 寸法を送って欲しいと返信が来る
  • 6/4 15時頃(送信) 寸法を送る
  • 6/4 20時頃(受信) アダプタを作成次第、普通郵便で発送すると返信が来る
    • アダプタの作成には3~4営業日かかるとのこと。
  • 6/5 16時頃(受信) アダプタ出来たので送ったと連絡が来る
    • 3~4営業日とは何だったのかという爆速度合いで嬉しかった

取り付け

シールが入っていたりするのでそれを使って取り付けるだけでした。
ドアノブが回しづらくなるようだったので、ドアノブを回すためのドアレバーを別途買いました。

参考

他の候補

他の候補としてはSwitch BotQrioがあります。
Switch Botは別のもので良く使っているので候補として考えていたのですが、鍵のタイプが合わなかったために断念しました。

対応しているかの確認について

まとめ

  • 指紋やスマホで鍵を開けられるようになって便利
  • 対応が早い企業は体験がすごく良い

参考

こちらもおすすめ

arata.hatenadiary.com

arata.hatenadiary.com

arata.hatenadiary.com

2024年6月に読んだ&読んでいる本たち

6月はペースを取り戻しつつあった。終盤だけだけど。
気を抜くと全然読めてないなってなっているのでうまく自分のペースをコントロールしていきたい。

読んだ本

読み手につたわる文章 - テクニカルライティング

booth.pm

会社で献本されたんだけど、出社してなくて結局買って読んだ。
ページ数が少ないからシュッと読めるし、中身が濃いのでおもしろい本だった。
共感を得たり、発見があったのは以下のようなところだった。

  • Chapter1 テクニカルライティングをはじめる前に
    • 1.2.2 自転車を「知らない」と描けない
      • 全く絵が描けないんだけど、絵も一緒なんだなと思った
  • Chapter2 エンジニアのためのテクニカルライティング
    • 2.2.3 既知から未知に繋ごう
      • これは人と話す時に無意識にやっていたことな気がしていて大事だなと思った
      • 意識してやっていきたい
    • 2.2.4 一つの段落では一つのことだけ書こう
      • 大学の英語小論文の授業受けて習った内容の一つに近かった
      • 主張を一つにするの大事よな
    • 2.2.5 一度に把握できることは7つまで
      • 多すぎてもダメなのはイメージつくけど具体的な数はイメージできてなかった
    • 【コラム】変わっていく語感を拾おう

      • 誤解を生む表現を誤解が生まれない表現で言い換えるの大事よな
      • それが誤解が生まれやすい表現かどうかを知らないと出来ないからこのコラムの気持ちは大事にしていきたい
    • 2.4.3 タイトルは「概要」か「○○の概要」か
      • これどっちがいいいか悩ましいよなー
  • Chapter4 よいレビューの仕方とされ方
    • 4.1.6 頼まれていないレビューはしない
      • これはちょっとわかんないなー
      • そもそも論間違ってんじゃんみたいなPull Requestのレビューをしたとき、それは頼まれてないのでレビューすべきではないみたいな話にはならないだろうと思うという点から、ほんのり違和感があるなと思った
      • そこにあるのが読み手 にとって取り返しのつかないような危険な間違いで、誰がどう見ても MUST FIX な ものであり、こちらから修正案も提供できる、というものでなければ、

      • これに該当するとしたら、そもそも必要かどうかという点はレビューすべきものであるという考え方も出来るのかな
  • Chapter5 どうやってテクニカルライティングを学ぶか
    • テクニカルライティング検定なんてあるんだ
      • ちょっと気になるので試験対策本読んでみようかなと思った

技術書の読書術

チームメイトが読んでいて、ちょっと前にセールだったので積んでた本。
そこまで長くない様子だったので読んでみた。
自分がなんとなくやってた読書術は悪くない方針だったんだなってことがわかってよかった。
気になったり共感したりしたのはこのあたり。

  • 第1部
    • 図書館の活用 ~貴重な本に出会う~
      • 無料で読めるのは大きなメリット
        • 良い本かどうかわからない本でも買わなくても読めるのは良いよな
        • 大学の頃片っ端から図書館の本読んでたのすごく良い体験だった
        • 家の近くの図書館も行きたい気持ちがあるけど、大学生の頃と比べるとあんまりなんだよなー
          • 人が多いのが嫌という気持ちがあるかもしれない
    • コラム
      • 「心にとっての読書は、身体にとっての運動と同じである」  ──リチャード・スティール(アイルランドの作家)
        • いい言葉だ
    • くじ引き読書法
      • ランダムに取ってみて読んでみるの面白そう
  • 第2部
    • 「『3』の発想」 ~1つのテーマで3冊の本を読む~
      • 入門書を3冊見比べる
        • 図書館で無料で読めるという選択肢があるとこれがやりやすいんだよな
        • 同じ内容の本を読んで同じことを言っていれば大事な内容だし、同じ内容を学んでいるので読む速度も上がるしこの方法は個人的にも好き
    • 読書に書ける時間
      • 同じ本を何度も読む
        • 流し読み => 手を動かしながら => まとめながら読もうという話
        • まず一通り全体の流れを理解してからもう一度読むというふうにやっていたのですごくわかる
        • 2週目にまとめをしちゃいがちなので、手を動かすフェーズを増やしてみるのもありかもしれないと思った
      • 積読の解消法
        • 積読は解消しない」w
        • 同時にやるのも一冊ずつやるのもありなのでものに合わせて選択肢を取れると良いっぽい
        • 筆者はなるべく感想をはやく返すため人に紹介された本は早めに集中してやるらしい
          • これは少し意識してやろうかな
      • 優先順位のつけ方
        • 狩野分析法
        • 重要度が高くて緊急度も高いものからやろうという話
    • 1冊90分で読む時間制限読書法
      • 90分で区切るやり方良さそう
      • 技術書の飛ばし読みテクニック
        • 受験の現代文でやった内容だった
          • 特に「日本語の用法を取捨選択のヒントにする」の部分
        • 大事な部分を抽出するのもテクニックで出来るのでそういうの大事だよな
        • 逆に書く時にはそれを意識して書くことが大事でもあると思っている
    • オーディオブックでインプット量を増大させる
  • 第3部
    • アウトプットの大事さという話
      • プログラミングと同じで知識をインプットしたらアウトプットするとさらに良いことがあるからやっていこうなという話と認識した

現場で役立つシステム設計の原則

DDDを実際にどうやっていくかの話をまとめた本という認識。
5、6年前に読んでたけど、再度読んでみた。

  • Chapter 1 小さくまとめてわかりやすくする
    • 小さなクラスでわかりやすく安全にするという話
      • 値を扱うための専用のクラスの値オブジェクト
      • Money型とQuantity型いい例だよな
    • 責務をクラスに閉じ込める
  • Chapter2 場合分けのロジックを整理する
    • ifなどの分岐ではなく、クラスに分けてinterfaceやenumを使いそれぞれに責務を分けて実装しましょうという話
  • Chapter3 業務ロジックをわかりやすく整理する
    • プレゼンテーション層+アプリケーション層+データソース層からさらにドメインモデルを定義する部分を用意する
    • 各々の層の関心事と分離して業務ロジックのみに出来るのが良いこと
  • Chapter4 ドメインモデルの考え方で設計する
    • 業務分析をしっかりやろうという話
      • それを元にコードの設計をしようという話
      • すごくわかる
    • ドメインオブジェクトの設計の基本は現実の業務の中で使われている具体的な言葉の単位で業務ロジックを整理することです

    • ドメインモデルの設計でありがちな失敗に、業務では実際に使っていない抽象的な言葉をクラス名として使ってしまうことがあります

    • そういう意味の広い抽象的な名前を使ったクラスは、具体的には何も説明していません。業務の現実の詳細を的確にとらえてはいないのです。

      • わかる〜〜〜〜〜〜
    • ドメインモデルとデータモデルの違い
      • ドメインモデル
        • 年齢が業務の関心事であれば年齢クラスを作る
        • 内部的には生年月日を持つ
        • 計算するメソッドを持つ
      • データモデル
        • 生年月日のみを持つ
      • テーブル設計の役割の部分がデータモデルの設計ということかと勝手に納得した
    • 全体的にドメインモデルをビジネスサイド(ドメインエキスパート)から知識を得てどう理解していくかの話だった
    • 改善を続けながらドメインモデルを成長させる
  • Chapter 5 / Chapter 6 / Chapter 7
    • Chapter 3にあった3層(プレゼンテーション層/アプリケーション層/データソース層)をどう実装していくかの話
    • DBアクセスやフロントの関心事をしっかり分離して実装しよう
    • アプリケーション層のサービスクラスを作りながらドメインモデルを育てていこうという話だった
    • そのあたりの具体的な方法が載っていた
      • プレゼンテーション層のhtmlのクラス名までドメインが出ていくのは理解できつつもやりすぎなんじゃないかと感じてしまった
  • Chapter8 アプリケーション間の連携
    • マイクロサービス間のAPI連携や他社との連携が一番イメージ近そうだなと思った
  • Chapter9 オブジェクト指向開発プロセス
    • V字モデル(と言っているがウォーターフォールモデルなのかな?)でのやり方にこの本であった開発の方法がどう合わせていけるのかという話
    • ソースコードを第一級のドキュメントとして活用するは本当にそうでしかない
  • Chapter10

積読(読みたい本)

人を動かす

リーダーのための!コーチングスキル

ドメイン駆動設計入門

スタッフエンジニア

積読積読のまま

チームトポロジー

まるで進まないので一旦止めてる

過去に読んだ本

arata.hatenadiary.com arata.hatenadiary.com arata.hatenadiary.com

おすすめ

www.amazon.co.jp

2024年5月に読んだ&読んでいる本たち

4月は1ヶ月まるまる風邪を引いてダウンしてたので何も読む余力がなかった・・・
5月から取り戻したかったけど病み上がり+仕事で捗らなかったので6月からは頑張りたい。

読んだ本

話し方で得する人・損する人

言い方に対して、もやりポイントを感じるときの理由を言語化したいなと思って参考の一つとしてkindle unlimitedで読んだ本。
話し方単体だけの話じゃないよなと思う話もいくつかあったけど、納得感ある話もあったりと面白い本でした。
その他にもいくつかあるけど、比較的新鮮さがある内容はこのあたりだった。

  • 12 損 上から目線でほめる / 得 純粋な気持ちでほめる
    • 評価・判断・ジャッジを混ぜないで感想を伝える
    • 同じレベル感で語れる立場にあるよねってお互いに思える立場だと認識していない状態で「君それ上手いね」みたいに言われると上から目線に感じ取られ、嫌な気分にさせる可能性があるという話
    • 良いではなく好きと伝えると良いとあったが、良いねという言葉も表現とか抑揚で私それ好きですというニュアンスで伝えられると思うので、そういう伝わり方が出来ると良いんだなと思った
  • 32 損 丸投げしたあとに文句を言う / 得 自分でイメージしてから依頼する
    • 任せるにしてもある程度自分でやるとしたらどうするかをイメージしてから任せるのが大事
    • そうじゃないと、任せるとか言ってるくせに文句ばっか達者だなって思われると思うので大事にしたい
  • 43 損 いきなり「結論」だけを言う / 得 「途中経過」も説明する
    • 結論から話すのは大事だけど、飛ばしすぎるのも困りものという話
    • 途中の「話がポンポン飛ぶ人の頭の中」という話が頭に残った
      • 複数の話題があるときに結論だけポンポン言われると話題が飛び飛びになって話についていけなくて困る
      • そういうときは途中経過も話そうという話だった
        • 個人的には途中経過というより結論の言い方というか、話のジャブが大事だよねという話と認識した

余談

作者の方見たことあるなと思ったけど、超雑談力という本も書かれている人だった。
その本は雑談するときのコツが書かれてて良かった記憶があるし、話し方という点では雑談とも関わると思うので似たような話が多いと感じたのはそういうことかと勝手に納得した。

読んでいる本

現場で役立つシステム設計の原則

数年前に読んでた本だけど、人に説明する機会が増えてきたので再度読み直して言語化してる。
Qiitaで引用?されてる記事から集計したランキングで年間TOP10くらいにいたり全体でも20位くらいには入っていて、
DDDを意識してコードを書くときのプラクティスが載っていて個人的に気に入っている本。

プリンシプル オブ プログラミング

数年前に読んでいた気がするんだけど、ほとんど覚えていないのでもう一度目を通そうかなって思って読んでる本。

技術書の読書術

チームメイトが読んでて、セールだったのもあり読んでみるかと思った本。

未顧客理解

一緒に仕事している人が読んだという話を聞いてkindle unlimitedだったので読んで見てる。

積読(読みたい本)

リーダーのための!コーチングスキル

数年前にDMMの超割引みたいなのでまとめてマネジメント系の本を買ったときに買って積まれていたのでそういえば読みたいなと思ったやつ

ドメイン駆動設計入門

DDDを雰囲気でやっているので、言語化して人に伝えられるようにと思ってセールだったので買ってみた本。

スタッフエンジニア

積読積読のまま

チームトポロジー

まるで進まないので一旦止めてる

過去に読んだ本

arata.hatenadiary.com arata.hatenadiary.com arata.hatenadiary.com