個人技術ブログを書く意味はあるのか

エンジニアは技術ブログを書けといろんなところ（ネット、書籍、有名エンジニアの発言）で言われている。アウトプットをすることで思考が整理される点については同意見だ。

しかし無名な個人ブログで書いても、アクセスはあつまらない。ブログの管理画面を見ても、アクセス数が目につきやすい箇所に設置されていたりと運営していくうえではアクセス数は重要な要素に感じる。

しかしだ、ブログとは元々「個人の日記」が出発点ではないか。なので本質は「日記」であって「広告媒体」ではない。もちろん多くの人に見てもらう広告として使うこともできるが、個人ブログは本質的には「日記」である。 これまで技術ブログを書いてきてアクセス数が少ないことを気にしていたが、アクセス数を増やすには多くの人が見たい記事を書くか広告投下するかのどちらかになる。しかし私のブログは日記で、未来の自分が振り返りをするのと、何らかの形で興味を持ってくれた人が私はどんな技術者なのかを書いてきた文章を通して見るのが目的のブログだ。なのでアクセス数については参考程度にするぐらいがちょうどいい。各種SNSも反応数がわかりやすい位置にあるが、あれも無視できたら良いのに。

アクセス数が少ないから書かないのではなく、書きたいことがあるから書くぐらいでちょうどいいのだ。なのでこのブログはゆるく続けていこうと思った。

台湾の中華電信HiNetで固定IPをルーターに設定する方法（PPPoEでの設定手順）

まえがき

タイトルの通りで中華電信のHiNetを設定する方法を紹介する。

超超超ニッチなニーズだが、自分用のメモと誰かの役に立てばいいなと。

Google検索でも普通に出てくる情報だが、日本語での情報はなく中国語のしか見当たらないので書いてみる。

背景

仕事でネットインフラの整備をする機会があって、固定IPを契約していたはずなのに、実際には動的IPになっていたため、設定し直すことになった

手順

  1. 中華電信HiNetのマイページにログインして 一個固定 IP + 七個動態 IP が選ばれているのを確認
  2. ルーターのIPをブラウザに入力して設定画面を開く https://192.168.1.1 など。借りている機体によって違うようなので詳しくは調べてください🙏
  3. PPPoEの設定画面を探して開く
  4. アカウント（帳號）のところに xxxxxx@wifi.hinet.net と入力されている部分があるので、この wifi の部分を ip に置き換え、 xxxxxx@ip.hinet.net のように修正
  5. パスワード（密碼）を再度入力する。すでに ***** のように表示されていてブラウザでハックすればパスワードも見れるが、必ずパスワードを改めて入力する（理由は後述）
  6. パスワードの紙が契約のときに渡されているはず。もしなくしたらリセットの手続きが必要
  7. 「保存する」ボタンを押して設定を反映する

ルーターの設定画面
ルーターの設定画面

ハマった

しょうもない原因だが、手順5で書いたパスワードについてすでにパスワードが入っていたのでこれをそのまま使えばOKだと思った。 で、PPPoEの設定を変えたらなぜか繋がらない。中華電信のCSに頼んでエンジニアを派遣してもらって話を聞くと、動的IPのパスワードと固定IPのパスワードは別物とのことだった。あれ、どっかのブログにたしか同じみたいな事書いてあった気がするんだけどなあ。

結局そのパスワードの紙をなくしているので、パスワード再設定の手続きをして固定IP化をすることになった。

PPPoEとは？

実はネットワーク周りの設定は経験が浅く、OSの設定画面で見たことはあるがよく知らなかったのでざっくり調べてみた。

ja.wikipedia.org

詳しくは書かないが（書けない）、OSI参照モデルでのトランスポート層に実装した機能で、パケットに認証情報を載せてカプセル化するプロトコルのようだ。 イーサネットで特に認証情報を扱う要件用のようだ…「カプセル化」なんて言葉使うのは学部時代以来だ。拒否反応が出ないだけでもあのときちゃんと勉強しといてよかった😂

あとがき＆近況

前回の記事の更新から今日がちょうど300日だった。前回の記事はなるべく頻繁に記事を書くのを目的に4行日記フレームワーク入れてみたのに結局10ヶ月も放置してしまった。やっぱ続けるのは簡単じゃない。 言い訳をすると仕事と育児が忙しいんだが、でもバイクに乗ったり他の趣味をしたりする時間はあったのでただの言い訳だｗ ちょっと反省。 そういえばバイクの話はここには書いていないので書いてみようかな？

Notionミニアプリ開発

個人用の日記で4行日記というのをはじめてみた。

日記を習慣化したいのでフレームワークを探してみて、役に立ちそうだったので。

本記事はその日記からの転載。

４行日記を紹介している記事：

note.com

4行日記 - [2024/06/15]

事実:

  • Notionに書いた記事（この日記）をLINEに共有するコードを書いた。
  • Githubにアップ済み。 https://github.com/akrha/notion-db-send2line
  • GASにデプロイして使う。さっそくデプロイした。
  • TypeScriptの練習を兼ねてChatGPTに頼りまくって書いた

感じたこと:

  • ちょっとのコードだがTypeScriptの静的テストの便利さを感じられた

学んだこと:

  • 型の定義は複雑になればなるほど面倒そうだが、後に書くコードで便利になりそうだ
  • anyを避けて実行時エラーをいくら減らすかがポイントになりそうだ

次にすること:

  • アイデアが湧き次第、続けてTypeScript別の何かを作るのをやってみる。
    • 最終的にTypeScriptをPHP/Ruby程度書けるようになるのが目標。

リクルート社新人研修資料「TypeScript入門」をTS未経験者が一通り読んでみて

日記 TypeScript

タイトルの通り、公開されている研修資料を読んで一通りPlayGroundで動かしてみた。演習も１と２は実際にやってみた。

speakerdeck.com

入門にはもってこいの内容だ！

で、わからないところは「サバイバルTypeScript」を読んでなんとか理解したつもり。

typescriptbook.jp

従来型JSしか触れたことがなかったプログラマとして気づいたことは、

  • 実行前に厳しいチェックが走るのは慣れれば安心
  • ユニオン型便利
  • ジェネリクスも便利
  • キャストはPHP/Ruby(の型変換)とはだいぶ異なる

でも正直、キャストより後の講義内容はぼんやりとしかわからなかった。 個人開発にしか今のところTypeScriptの用途は考えていないが、このまま開発を始められるか不安なのでGPT-4o先生にPDFを渡して意見を仰いでみた。

あなた
キャストより後の講義内容はほぼわかりません。
このまま実践に進んでも大丈夫でしょうか心配です。

ChatGPT
TypeScriptの学習を進める上で、全ての概念を完全に理解してから実践に進む必要はありません。基本的な概念や使い方を理解した後、実際のプロジェクトで経験を積むことで、徐々に理解が深まることがよくあります。以下に、安心して実践に進むためのアドバイスをいくつか紹介します。
1. 基本的な理解を確認

まず、以下の基本的な概念について理解していることを確認しましょう。

    基本的な型: string, number, boolean, array, tuple, enum, any, unknown, never, void
    インターフェースとタイプエイリアス: オブジェクトの形状を定義し、それらを使って型安全なコードを書く方法
    ユニオン型とインターセクション型: 複数の型を組み合わせて使う方法
    ジェネリクス: 型の再利用性と柔軟性を向上させる方法

2. 実践を通じて学ぶ

（以下略）

なるほど基本的な概念を抑えておけば良い、と。

基本的な型: string, number, boolean, array, tuple, enum, any, unknown, never, void

これは大丈夫そうだ。

インターフェースとタイプエイリアス: オブジェクトの形状を定義し、それらを使って型安全なコードを書く方法

うーんこれもまあやりながらなんとかなるかな？

ユニオン型とインターセクション型: 複数の型を組み合わせて使う方法 ジェネリクス: 型の再利用性と柔軟性を向上させる方法

講義資料とサバイバルTypeScriptで便利なのは分かったが、自分が扱えるかはまだわからないな。

とのこと。全部理解してから書くのは無理なので、とりあえず書きながら覚えていくしかないか。

JavaScriptで書いていたGASの開発をTypeScriptでやってみたいと思っているので、まずはここから始めていく💪

現役エンジニアとしてあり続けるために

日記 日記

Qiitaで見て知ったのだが、研修資料が公開されている！

【2024年度】エンジニア向け研修資料まとめ - Qiita

その中で気になったのがこれ、リクルート社の新卒研修資料が公開されている。

株式会社リクルート　エンジニアコース新人研修の内容を公開します！（2023年度版） | Recruit Tech Blog

ここで紹介されていた「エンジニアの心構え」という資料が刺さった。というか読み終わって危機感を覚えた。

エンジニアの心構え

ポイントはこれらだ。

  • 月に１冊のペースで技術書を読む
  • 手を動かして学ぶ
  • 毎年少なくとも言語を１つ学習する
  • 身の回りをプログラミング対象にする
  • アウトプットを行う
  • 現役プログラマでいるために
    • 毎日コードを書く
    • 年下から学ぶ
    • 過去から未来を見る
    • 大事なことに集中する

…う〜ん、プログラミング言語を学習する以外どれも満たしていないような。あとは身の回りをプログラミング対象にするは、ギリギリ業務でツールを作ったりしているのでギリ満たしてると言えるかもだが。

ここに書いてある内容は前に読んだ「達人プログラマ」でも（確か）紹介されて、それがこのスライドでも取り上げられていていた。

やっぱり現役のプログラマでいたいと思う。全部を実施するのは難しいが、自分のキャリアのためにもできることは続けていきたいと思う。

現在は紹介されていたうちの一つ この資料 を使ってTypeScriptを勉強している。これもリクルート社の資料がハンズオンにちょうどいいと思ったので１ページずつゆっくり進めている。現在62ページ(108ページ中)。型に厳しい言語を使わずに来たので、覚えるべき概念が多いと感じている。やりがいは感じている！💪タイプ縛りが厳しいけど安全そうだな。

研修資料を公開してくれたリクルート社に感謝✨

キャリアの転機が来た

この記事について

バックエンドエンジニアから情シスになった際のキャリアに対する個人的な見解

仕事歴について

実は今は開発現場第一線の仕事をしていない。 2017年からバックエンドエンジニアをしていたが、結婚を機に台湾に移住。 リモートで日本企業のバックエンドエンジニアを続けていたが、今年4月に台湾の日系企業に就職。 これまでのIT技術の知識を活かして社内のDX化を進める情シスの仕事についた。

開発者キャリア中断の怖さとやりたいこと

結論から言うとやりたいと思っていた仕事に近い仕事の機会が運良く舞い降りてきたので、そのチャンスに乗った。

大学のバイト時代からバックエンドエンジニアの仕事をしていたので、開発者のキャリアを途切れさせてしまって良いのか非常に悩んだ。 バックエンドエンジニア、フルスタックエンジニアの仕事は第一線を離れてしまうと取り戻すのが大変だと思うからだ。自分のキャリアをリスクに曝してしまう。

ただ、昔から異国のエンジニア（オフショア）と自国の開発現場をつなぐブリッジエンジニアをやってみたいという願望があった。自分は英語と中国語はそれなりに自信があるので、その能力を使って仕事をしたいという考えが実はかなり昔からあった。 現職の仕事はブリッジエンジニアではないので開発現場に直接参画することはない。 だが、主な業務内容の社内のDX化、マーケティング、社内ツール開発であり現地スタッフとのコミュニケーションは毎日のように発生する。 正直未経験の内容も多く面食らうことも多いが、なかなか珍しい経験ができているのではと思う。

開発者のキャリアとしては、開発職に就いた場合と比べて技術力成長の観点からは微妙なのは否めない。 しかしここでしかできない経験ができているのも事実だ。またいろんな発見があるので面白い。 それと実は上司が自己研鑽に積極的なので、書籍を買ったり講座を受講したりとかの経費は出してもらえている。とてもありがたい。 このお金で実はプログラミングの講座受講をさせていただいている。 結果的に充実していると思う。

気づいたこと

台湾で就職という珍しいパターンのキャリアだが、そうでなくとも同じだと思う。 やりたいことをやる機会があったのでその機会を選んだ。 その選択ができたのは万が一自分に合わなかった場合（退職）に備えた生活費貯金と、まあダメならまた仕事探せばいっかという気持ちがあったからだ。 挑戦するための準備をしておいてよかった。挑戦すらしていなかったら後悔していたかもしれない。 やっぱり挑戦する準備と勇気は必要だ。

これから

現職の企業はアナログ作業な面が多く、業務効率化の余地がまだまだたくさん。自己研鑽をさせていただきつつ、仕事をこなしていく毎日だ。 いつまでこの仕事をしていくのかは正直分からないが、開発者としても情シスとしても経験値は積め、必要とされているのでまだまだ続けていく。 やれることの幅が増えた！

結論

キャリアに変化をもたらすのはとっても悩むし、勇気が必要。でもそのための最低限の準備をしておけば負担を減らせるかも。 開発者キャリアの王道からは外れたものの、他の人にはない経験もできているしプラスになっているだろう（？）

DynamoDB DocumentClientで 'The provided key element does not match the schema' エラーが出る

Node.jsでDocumentClientを使ってテーブルから指定したPK・SKの組み合わせのレコードを削除するスクリプトを書いた。 しかし The provided key element does not match the schema 例外が上がってうまく動かない。

const AWS = require('aws-sdk');
const documentClient = new AWS.DynamoDB.DocumentClient();

const deleteUser = async (email, user_id) => {
  console.log('deleting user');
  var params = {
    TableName: 'UserData',
    Key: {
      email: email,
      user_id: user_id
    }
  };
  await documentClient.delete(params).promise();
};

deleteUser('someone@example.com', 100);

なぜか。

色々試したが、原因はスキーマが合っていなかったからだった。 ソートキーの user_id はString型だった... なので、以下のように修正した。

+      user_id: (String)user_id
-      user_id: user_id

テーブルのスキームに合わせてキャストしてあげないとAWS SDKが文字列型にいい感じに変換してくれてしまうので、 予期しない動きをするのである。

動的型付けのNode.jsやPHPに慣れていると、見落としがちだ。