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

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

• 経歴やスキルセットなど
• すべてはアプリケーションでありソフトウェアな気がする
• コードから逃げてはいけない
• 汎用的なスキルを身につけよう
• 広く深くいろいろな技術を学ぶ
• やるべきこととやらなくていいことを見極める
• 最短距離を走る
• 1から全部やり直せるくらいになる
• レベルの平準化問題、属人化問題
• 仕事以外の自分の趣味をしっかり作る
• ChatGPT
• やったことは忘れないように記録する
• 最後に

経歴やスキルセットなど

• 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 に公開している自分の知識があればやったこと経験したことの証明になる

最後に

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

当サイトにおけるプライバシポリシーおよび免責事項など

• プライバシーポリシー
  • 個人情報の利用目的
  • 広告について
  • アクセス解析ツールについて
  • コメントについて
• 免責事項
• 著作権について
• リンクについて

プライバシーポリシー

個人情報の利用目的

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

広告について

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

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

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

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

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

コメントについて

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

免責事項

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

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

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

著作権について

当サイトで掲載している文章や画像などにつきましては、無断転載することを禁止します。

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

リンクについて

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

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

家族四人でサマーランドに行くとかかる料金

ディズニーよりは安いです

料金

合計: 35300円

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

料金詳細

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

サマーランド持ち物

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

その他

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

幅60cm400リットル以上の冷蔵庫を購入した

結構大きめの冷蔵庫を買ったので搬入時のポイントなどを紹介します

• 買ったもの
• 搬入時のポイント
  • 増員
  • 経路の確保
  • 掃除
  • 日程調整
• 冷蔵庫の中身の入れ替えタイミング
• 設置直後の冷蔵庫は全然冷たくないので注意
• リサイクル料金など
• 最後に

買ったもの

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

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

搬入時のポイント

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

増員

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

経路の確保

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

掃除

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

日程調整

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

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

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

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

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

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

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

リサイクル料金など

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

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

最後に

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

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

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

• 環境
• サンプルコード
• 参考URL

環境

• 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

M2Pro mac mini デビュー

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

• 価格
• スペック
• セットアップ
  • キッティング
• つまづいた点
  • VirtualBox がインストールできない
  • Homebrew のパスが変わっていた
• 感想
• やりたいこと
• 最後に

価格

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 の速さは変わるのだろうか)

自分のホームページのコードをリファクタリングしたので感想

ホームページはこちら

• コード概要
• リファクタ方針
• クラス化について
  • メリット
  • デメリット
• rubocop について
  • 基本辛いが特に辛い点
  • rubocop っぽいコードになる
• TwitterAPI v2 化について
• 全体通して
  • コードフォーマットについて
  • テストについて

コード概要

• 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 テストで補えばいいのかもしれません

テストについて

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