Kotlinを書き始めた

この記事は はてなエンジニア Advent Calendar 2025 16日目の記事です．
昨日は id:Windymelt さんの HNSWのビジュアライザを作成したでした．

さて，表題の通り最近 Kotlin を書きはじめたので，この記事ではKotlinを書いてみた感想を書いてみようと思います．

ファーストインプレッション

私のバックグラウンドとしては TypeScript をメインにたまにGoやRubyを書くという感じで，いわゆるJVM系言語はほとんど触ったことがありませんでした． 書き始めるまでのKotlinの雑なイメージはこんな感じでした:

• JetBrainsが開発している
• JVMの上で動く
• 記法がJavaに近いだろう

書いてみて面白いなと思ったところ

クラスの種類が多い

まずはじめに思ったのはクラスの種類が多いことでしょうか． TypeScriptではclassだけですが，Kotlinにはdata class，sealed class，enum classなど様々種類のクラスが存在しています．まだ正しい使い分けが理解できていません...

それぞれの役割や特性としては:

• data class: データ保持が目的．自動的にデータをコピーできるcopy()メソッドが実装される．
  • このcopy()メソッドはかなり便利で最初に見たときは感動した覚えがあります．
• sealed class: 継承できるクラスを同じパッケージ内に制限する．whenで網羅性チェックができる．
• enum class: 固定値を列挙できる．各値はインスタンスになる．

when式が強い

when式はswitch文より表現力が高く，分岐が結構簡潔に書けます． TypeScriptやGoには無い機能なので，チュートリアルを走っている途中には結構強力な構文だなと思っていました

大分雑な例ですが，例えばプログラミングのテストで出てきそうな*1こんな感じのコードが

function formatScore(score: number): string {
  if (score >= 90) return "秀";
  if (score >= 80) return "優";
  if (score >= 70) return "良";
  if (score >= 60) return "可";
  return "不可";
}

Kotlinだとこう書けます:

fun formatScore(score: Int): String = when {
  score >= 90  -> "秀"
  score >= 80  -> "優"
  score >= 70  -> "良"
  score >= 60  -> "可"
  else -> "不可"
}

named arguments

関数呼び出しの時に引数名を指定できる機能です．

data class User(
  private val id: String,
  private val name: String, 
)

val user = User(id = "20251216", name = "laminne")

これがなかなか便利です． 引数が増えてくると順番を意識して書く必要がありますし，同じ型の引数を取り違えることも良く発生します． 同じような構文はRubyなどにもあります．

同じようなことをTypeScriptで書こうとすると，まずinterfaceやtypeを使ってオブジェクトの型を定義する必要があります:

interface UserArgs {
  id: string,
  name: string,
}

class User {
  private readonly id: string
  private readonly name: string

  constructor(args: UserArgs) {
    this.id = args.id
    this.name = args.name
  }
}

const user = new User({ id: "20251216", name: "laminne" })

TypeScriptのクラスにはコンストラクタでメンバ変数を定義できる構文があり，上のコードはこんな感じに書き直すことができます

class User {
  constructor(
    private readonly id: string,
    private readonly name: string, 
  ) {}
}

とはいえこの方法だとオブジェクトを使って受け取ることができないので，コンストラクタでメンバ変数に代入し直す必要があって辛い...

スコープ関数

スコープ関数はラムダ式を使ってオブジェクトを操作するための関数*2です． let，run，with，apply，alsoの5種類が存在していて，それぞれ少しずつ違う効果があります．使い分けるのが難しい....

例えばlet: ?.演算子と一緒に使うことが多い，nullableなオブジェクトに対して「中身がnullではない時だけ実行する」処理を書くときに使う．

val email: String? = user.getEmail()

val trimmedEmail = email?.let {
  it.trim()
}

// 繋げて書くこともできる
email
  ?.let { it.trim() }
  ?.let { it.lowercase() }

TypeScriptで同じことを書くと

const email: string | null = user.getEmail()

const trimmedEmail = email !== null ? email.trim() : null

というようになります． if文や三項演算子で分岐させるのとメソッドチェーンのどっちが良いかは場合によると思っていますが，個人的にはメソッドチェーンできる方がわかりやすくて好きです．

不満点

最近書き始めたばかりで理解していないことの方が多い状態なので，あまり不満はありませんが，強いて言えば:

• ビルドが思ったより重たい
  • lintなどの周辺ツールも数秒待つことが多かったです(これは私の設定が悪いかもしれない...)
  • 差分ビルドとかをうまく使うともっと早くなるかも
• たまにJavaのメソッドを呼び出して困る
  • 「このメソッドはKotlinじゃないからnamed arguments使えないよ」とIDEに怒られることがよくある
  • 適当に関数ジャンプしようとするとデコンパイラー使いますか？と聞かれてびっくりする

まとめ

• 思ったより便利な構文や機能が多くて簡潔に書けるなという印象を持った
• まだ書き始めてからの時間が経っていないので試せていない機能や理解できていないことが結構ある
  • Coroutineは全く理解できていない．使えると便利そう
  • Kotlin Nativeが気になっている
• Pure Kotlinでちゃんとしたアプリケーションを作ったり，大きなコードを読んでみようかなと思っている

以上です．

*1:実際に学校のテストでこんな感じのコードをCで書いた覚えがあります

*2:https://kotlinlang.org/docs/scope-functions.html

独立行政法人国立高等専門学校機構 松江工業高等専門学校 情報工学科 を卒業しました

表題の通り，3/21に 独立行政法人国立高等専門学校機構 松江工業高等専門学校 情報工学科 を卒業しました．なんと！5年で卒業できてしまった...

私のソーシャルアカウントをフォローしている人はほとんどが高専について詳しいと(勝手に)思っているので高専本体の説明は最小限にしますが，高専はこういう学校です

• 正式名称が長い(大体 "独立行政法人国立高等専門学校機構" が長すぎるのが悪い)
  • これのせいで銀行や就活サイトの登録がだいぶ面倒になってしまう
  • 松江高専情報工学科の正式表記は空白を含めて33文字ある
• 大学生でも高校生でもない謎の経歴
  • 高専は5年で卒業するもの(高校相当の3年+短大と同じで2年)で，卒業できないと中卒になる(5年通って初めて"高専卒"を名乗れる)
• 大体立地が微妙
  • 用地確保の都合で多くの場合各県の第二第三の市の外れにある
  • 松江高専は中国地方唯一県庁所在地に存在するが，中心地から離れた場所にある

5年間でやったこと

スーパーダイジェストでお送りします.

• 発狂
  • おかげさまで人生狂いました
  • フォォゥ〜〜〜〜！！！！！！！！(爆発)
• 留年の回避
  
  • いわゆる"万年留年候補"でした
• インターン(4年次)
  • 途中で腹を壊した
    • その節は申し訳ありませんでした
• 苦行(変な旅行)
  • フリーきっぷ 一筆書き @東京 (5年次)
  • 青春18きっぷ苦行 広島-東京 往復1800km (5年次)
• 各種 限界開発
  • ドメインなしプログラミング (2年次)
    • 2週間以下で書いたMVCもどきの 動けば良い(なお動かない) Webバックエンド
    • ??「種無し餃子」
  • 設計とその実装に時間がかかって動かないプログラムを出展 (3年次)
    • PM兼プログラマー(私)が逃亡
      • 逃亡というか試験に忙殺というか...
  • 結合テストしてないシステムを納品したら本番稼働でぶっ壊れる (4年次)
    • とりあえず人力で補完することになった
    • 1年後(5年次)にちゃんと改良して正常動作させました
• 各種 登壇
  • Rubyアソシエーションのオンラインセミナーでインタビューされる (1年次)
  • RubyWorld Conference スポンサーセッションでリレー形式で話す (5年次)
• コミュニティー/技術チームの設立など 
  

  • 共同開発鯖 (初期メンバー, 1年次) https://growthers.dev

  • Poporon Network (発起人, 2年次) https://poporon.org

• 部長 (2-4年次)
• 卒業研究
  • ビジュアルプログラミングツールで書いたプログラムをRuby(の軽量バージョン)に変換して，マイコンで動かす研究をしました

今後について

25卒のプログラマーとして就職します．どこに就職するのかについては特に名言するつもりはありませんが，直接会う機会がある人には多分話すと思いますし．何かしらのカンファレンスに出たときに名刺交換するだろうからその時にわかるはず？です．

新しい分散/連合型SNS「Pulsate」を開発している

タイトルの通り、新しい分散/連合型SNSを開発している。

ソフトウェアの名前は"Pulsate"*1(パルセート と読む)で、プログラムは以下のrepositoryにある。

github.com

注意:

残念ながら後述する通りまだかなり荒削りな状態であり、プロダクション運用できる状態ではない。

この記事の内容は基本的に私の考えていることをダンプしたものであり、プロジェクトの公式見解ではないことに注意されたい。

これは何

Pulsateは

• ActivityPubに対応する
• 短文投稿型で
• 絵文字リアクションが利用可能で
• 引用が可能な
• サーバー側実装

である。

Mastodon のような思想を持ち、misskey のような機能セットを提供し、それでいてどのソフトウェアとも関係のない独立した実装だ。

機能の名前は基本的にmisskeyと同じ*2。

投稿: ノート

再投稿: リノート

引用再投稿: 引用リノート

技術スタックとしては:

• プログラミング言語: TypeScript
• HTTPサーバーライブラリ: Hono
• KVS: Valkey(Redisのフォーク)
• データベース: Postgres
  • OR/M: prisma

を採用している。

このプロジェクトでは新しい技術を取り入れつつ他の部分では多少枯れた技術も採用していくつもりだ。

1/17 補足:

PulsateではバックエンドでもTypeScriptを採用している。理由は:

• 発起人(7人いました)の中で全員が共通して書ける言語がTypeScriptしかなかった
  • TypeScriptでバックエンドを書いていた人が多かったためそれでも問題がなかった

というような感じです。開発開始後も何回か言語を変更するか？といった検討がなされたことがありましたが、すでに書かれているコードを放棄するよりは継続開発した方が良いだろうといった結論になり、結局TypeScriptを採用し続けているというわけです。

補足終わり

フロントエンドは？となるかもしれないが、Pulsate は標準のフロントエンドを同梱しない。Pulsate 向けのフロントエンドは同じ団体(Pulsate Project)が開発する別ソフトウェア扱い*3で、Caramel (カラメル)という別の名前が付いている。

現在時点でのCaramelの技術スタックは:

• TypeScript
• Remix(v2)
• CSS Modules
• UIコンポーネントは使っていない

という感じになっている。Remixの雲行きが怪しくなってきているので別のスタックに切り替えることを検討している。

Caramelは"とりあえず使い物になる"レベルの実装しかしていない最小かつ最軽量なフロントエンドであるため、恐ろしくシンプルで消極的なUIである。

Cramelのスクリーンショット
(表示内容はあくまでテストデータであることに注意)

ほとんどCSSは書かれいていないし、リアクションは👍の1種類しかつけることができず誰がつけたのかも知ることができない。あとはフォローもできない。

ただ単に(フロントエンド側が)未実装なのもあるが、バックエンドで実装される全ての機能に対応するつもりがないのは事実だ。

もし"なんだこのけしからんフロントエンドは！"と思う人がこの記事を読む人の中にいるなら、この記事を一番下まで読んでぜひ私たちと一緒にこのけしからんソフトウェアを改善して、Fediverseの世界をもっと良くしよう。

Pulsate関連ソフトウェアのライセンスはApache2.0で、他ソフトウェアで広く採用されているAGPLは採用していない。

理由としてはAGPLは 厳格なコピーレフト型ライセンス であり、フォークの開発者にかかる手間が多いためライセンス違反が発生する可能性がほかと比べて高く、それに対する対処などが複雑になると考えたから と、単に開発開始時にApache2.0ライセンスが一番合っているだろうと判断したからだ。

(注: この類のSNSは一般的には"分散型SNS"と表記することが圧倒的に多いが、この記事では後述する理由によってあえてこう表記する)

目指すもの

公式サイトに書いてあるプロジェクトが目指すものはこんな感じだ:

1. 高いパフォーマンス

Pulsateの開発開始時に"最も解決したいこと"であったものの一つ。

他実装では"大量のユーザーの投稿や操作をどうさばくか"が重要視されるのに対し、Pulsateでは"そこまで多くない投稿や操作をいかに効率よく処理するか"を重要視していくつもりだ。

分散/連合型SNSの統計をとっている FediIndex (https://fedi.wrm.sr/) によると、ユーザー数100人以下のインスタンスが93.23%と大半を占めている。

ほとんどのインスタンスは非常に小規模であるので、何千何万というレベルの同時接続に耐えることが可能な大掛かりな仕組みよりも運営にかかるコストを削減したり、維持に必要な操作を自動で行ったりできる仕組みを導入したほうが効果があると考えている。

Pulsateは中小規模(〜1000人)のインスタンスをメインタゲートに絞って開発していく予定だ。

2. ユーザー中心の設計

分散/連合型のSNSをあまり使ったことがない人にとって、リモート/ローカルの概念やフォローの方法を理解するのは相当に難しいことだと思う。

Pulsateは技術者や分散/連合型SNSを使ってきたユーザーだけではなく、標準的なSNSのユーザーやあまり短文投稿系のSNSに触れてこなかったユーザーもターゲットにしたいと考えている。

そのために、シンプルかつ直観的に使いやすい(フロントエンドの)デザインであるとか、極力難しい単語(技術用語)を排除するなどの対応を行っていくつもりだ。

3. 開発者向けのサポートや網羅的なドキュメントの用意

PulsateではDiscordに開発者同士、ユーザー同士がコミュニケーションできるようなコミュニティーサーバーを設けている。もちろん開発に関連する(ほぼ)全ての会話はここでオープンな形で行われている。

コミュニティーサーバーは以下からアクセスできる。

discord.com

Pulsateの開発チームにはオープンソースであるのなら開発方針や開発の様子は基本的にオープンにしていくべきという考えがあり、それの一環としてこのようなコミュニティーを設けている。

こうすることで、

• ユーザーからのフィードバック/ユーザーインタビュー が容易になる
  • ユーザーや外部の開発者が今何を考えているのかということがわかりやすくなる
• プロジェクト全体の透明性を上げられる
  • 意思決定の透明性の確保は非常に重要

といったメリットがあると考えている。

また、内部のアーキテクチャ/設計ドキュメントなどのPulsate自体の開発ドキュメントを完全にオープンにする。具体的にどのようなドキュメントを書き、どのように活用するかは決まっていないが、外部コントリビューターの確保やプログラムの維持管理に活かせると考えている。

かなり荒削りで不完全ではあるが*4、すでに一部のモデルの仕様が公開されている。

spec.pulsate.dev

さらに、様々なプログラミング言語向けのAPIクライアントライブラリを公式提供する予定だ。Pulsateは他のSNSとAPIの互換性がないため、Botやアプリの開発を行うためにはAPIクライアントを自作する必要が出てきてしまう。

他のSNSではそういった場合でも公式でライブラリが提供される事例はほぼ無いが、Pulsateではいくらかの需要の大きいプログラミング言語向けのライブラリを公式で提供する予定だ。

すでにAPIドキュメントと全てのエンドポイントの型はOpenAPI Spec(OpenAIではない)方式でコードから自動生成されているので、公式提供されないプログラミング言語向けのライブラリも手書きすることなく自動で生成できる。

4. 他実装との高い相互運用性(互換性)

この記事では"分散型SNS"という表記をせず"分散/連合型SNS"と表記しているが、これには理由がある。

個人的に分散 と 連合 は指す意味が違うと考えているからだ。

おおむねこんな感じに理解している:

分散: 大きいSNS(インスタンスのこともある)を複数に分け、ユーザーを散らす

連合: 複数の(種類の違うこともある)独立したSNSを繋いで1つにする

"分散型SNS"と表記すると単にユーザーやインスタンスがバラバラになる印象が大きくなると考えていて、そのために"連合型"という 複数のものがつながる という意味の言葉を採用している。

Pulsateのプロジェクト全体の標語(キャッチコピー)は「繋がりを"再定義する"」だが、ここで言うところの 繋がり にはユーザー同士の関係だけでなくインスタンス/サービス/ソフトウェア同士のつながりも含まれている。

Pulsateは歴史的経緯*5からActivityPubに関連した処理をSNSの基本機能(ログインや投稿、フォローなど)から完全に独立させる形で設計している。

アプローチはmisskeyのそれとほとんど同じで、先に最低限独立したSNSとして使えるようにしてからActivityPubに関連する機能を実装していく という形式を取っている。

とはいっても、連合に対する考え方はmisskeyとほぼ真逆である。

misskeyは「あくまで連合(分散)は従」であり、基本機能を最優先として連合に対して消極的である*6*7。

一方Pulsateは「連合は重要な概念であり、既存のSNSとの互換性を保ちどのインスタンスにいてもシームレスに繋がり続けることができること」を重要視する。

このようなスタンスを"連合志向"と言う。Pulsateは連合志向な独立実装である。

具体的には:

• Pulsateは基本的に連合しない機能はリリースしない
  • 基本的にどのインスタンスでも相互に利用可能とし、インスタンスの内側に閉じない機能設計をする
    •  misskeyの"連合なし"公開範囲や(連合しない)チャンネルは実装予定がない
  •  通報やモデレーション機能などは除く
• ローカルタイムラインは無い
  • 連合するチャンネルをローカルタイムラインのようにして、別のインスタンスのローカルタイムラインを(そのインスタンスから)見たり投稿したりできると良いなとは思っている
  • 大昔(公式インスタンスであった時代)のmisskey.ioはローカルタイムラインを時間封鎖していた時期があり、misskey開発者もローカルタイムラインには問題が多く(少なくとも公式のインスタンスでは)有効にするべきではないという趣旨の記事を書いていたりする*8

5. オープンソースであり続ける

前述した通りPulsateはApache2.0ライセンスで配布されている。コードがオープンでも開発がオープンでないこともあるが、Pulsateの開発はオープンに行われている。

独立性に関してはPulsateの開発チーム(pulsate-dev)とPulsateに関連する全てを管理するPulsate Projectは完全に非営利かつ独立であり続ける。(Pulsateを利用した)巨大インスタンスの運営団体や法人の傘下に入ることはないし、そうした組織から意思決定に干渉されることもない。意思決定に重要なのはあくまでユーザー本位、分散/連合型SNSとしてどうあるべきかということだけだ。

コントリビューターや利用者の数が増え、プロジェクト規模が大きくなった際には透明性の高いガバナンスの導入を計画している。私が今考えている主な取り組みは以下の通り:

• 開発を計画している機能リストは全て公開する
• 全ての意思決定は議事録を含め全て公開する
  • 外部の団体との契約も内容を含め全て公開する
• プロジェクトに関連する全てのプログラムはオープンソースライセンス下で公開する
• プロジェクトが使用する/受け取る資金は金額、使用用途を含めて公開する

簡単なレポートの形で数ヶ月おきに最近の進捗などを公開するところから初めていくつもりだ。

現在時点の目標:

現在時点で考えている目標はこのような感じにしている。

長期的(今後5年間で達成したい)目標:

• 定期的なリリース(おおむね3ヶ月おき)
• Pulsateを利用したインスタンスの総ユーザー数: 500人以上
• インスタンス数: 25以上
• 総ユーザーに対しての(準)公式インスタンスのシェア率: 30%以下
• コントリビューター(貢献者)数: 50人以上
• 継続的財政支援者数: 10人以上
  • 収入: 3万円/年

短期的(おおむねこの1年〜2年で達成したい)目標

• v1のリリース
• コントリビューター数: 20人
• 総ユーザー数: 100人

あまり具体的ではないし、目標も高いのか低いのかよくわからないが、とりあえず私個人としてはこれくらいの目標でいこうと思っている。

宣伝: 私たちと一緒にPulsate/Caramelを開発しませんか

現状、Pulsate Projectは他のプロジェクトに比べてかなり小規模だ。アクティブに活動しているプログラマーは実質私1人で、PulsateもCaramelもどちらも私が書いている。

もう1人アーキテクト/レビュワー兼プロダクトオーナー(最終的意思決定者)がいるが、やはり開発者の人手が足りない。

注: 現在私ともう一人の開発者は卒業研究が佳境に入っており、(私は)2月中旬ごろまでそこまでプログラムをかけない状態になっている。

基本機能(ノート、リノート、リスト、フォロー、タイムライン)についてはPulsateで実装済みではあるものの、その大部分がCaramelで利用できない状態だ。

そんな状態ではあるが、プログラム自体は腐らずに保たれている。

misskeyのコードについてコントリビューターが嘆いていたのを見ていたのでかなり丁寧にソフトウェア設計を行っており、単体テストもほぼ全てのロジックについて書かれている*9。

ActivityPub関連の実装はまだほとんど行われていないが、既存の処理を適切に呼び出せば実装はできる状態にはなっている。

また、JSON-LD(ActivityPubのサーバー間通信で使われるJSONに似たフォーマット)からJSONとの相互変換や、かなり実装が難しいとされるリクエストの署名の処理周りは、最近ActivityPub実装自作の世界で注目を集めている Fedify を利用するつもりだ。

github.com

もともとはDeno向けに書かれたようだが、Web標準APIを利用しているためPulsateが使っているNodeでも利用可能なので非常に助かる。

こうした便利なライブラリを利用することで開発にかかる手間を減らすことができ、結果的にユーザーに価値を提供し続けることのできる力を生み出すことができるのではないかと考える。

さて、見出しの通りPulsate/Caramelの開発に参加しませんか。

(開発以外にもアイデアを提供したり、コミュニティーサーバーで発言したりするなどの貢献方法がある。)

プロジェクトや開発に興味があるという方はコミュニティーサーバーにぜひ。

discord.gg

ソースコードを読んで全体の様子を見てみたいという場合は GH: pulsate-dev/pulsate にコードがある。

github.com

あまり発言はないがFediverseにもアカウントがある。

mi.growthers.dev

TwitterかFediverseで #pulsate をつけて投稿していただければ(筆者が)何かしら反応する。

(Fediverseの方はnotestockをお使いならばすぐ反応できると思う)

ActivityPubに関連したアプリケーションを書いてみたい人、

つくりたいものが特にないがWebアプリ開発がしたい学生(今まで開発に関わった人は全員学生)、

"misskey 連合 つらい うんざりザリガニ" *10 という感じの人は Pulsate Project にぴったりな人*11だと勝手に思う。

まとめ

• Pulsate/Caramelという"連合志向"な分散/連合型SNSを開発している
• おもにユーザー数1000人以下のインスタンスで使われることを想定している
• ユーザー中心の(UI)設計をする予定
• ソフトウェア自体のドキュメントを整備し公開する
• 高い相互運用性を維持し、どのインスタンスにアカウントがあってもシームレスに繋がれる状態を目指す
• プロジェクト規模が拡大したら透明性の高いガバナンスの導入を行う

以上だ。

Fediverseの世界がより良いものになることを願って。

*1:Indigo la end のアルバムの名前に由来するらしい

*2:ActivityPub上での投稿のオブジェクト名もNoteなのでそちらに影響を受けているとも言える

*3:公式クライアントを使わないという選択肢も尊重するため

*4:いまあるドキュメントをどのように維持していくかが喫緊の課題になりつつある。

*5:開発開始した2023年9月頃はBlueskyなどのActivityPub以外のプロトコル実装が乱立しており、ActivityPub以外のプロトコル実装も行う必要性が0ではなかった

*6:開発者が「連合はおまけ」と発言し物議を醸したことがある

*7:この数ヶ月最大インスタンスの運用者が資金など様々な理由から連合の終了を示唆して批判されている

*8:ソース: https://misskey.io/@syuilo/pages/ltl

*9:バリデーション用の型定義などのテストを書けない部分を含めた全プログラムに対するカバレッジ: 49.54%

*10:元ネタ: https://blog.3qe.us/entry/2024/04/19/200735

*11:Pulsateはmisskeyの連合関連の不満やソフトウェアに対する考え方に異を唱える会話の中で生まれた

新年の抱負2025

2025年の抱負。遅すぎるというのはそうかも。
記事というよりメモになりそう。

技術関連の雑多

• 新しい言語を習得する
  • 就職したら何か一つは必然的に習得する必要がありそう
  • すでに習得済みの言語の再入門もやりたい
• 雑にプログラミングするのをやめる
  • 計画性を持つ/やることを明文化して不連続にタスクに取り組めるようにしたい
  • ドキュメントを上手く書けるようになりたい
    • 文字を打つのが苦手なのでそれをどうにかしなきゃ...
  • Pull Requestを立てる時にしょうもないミスをした状態のコードを上げるのをやめる
  • 作業メモ.txtがあってもいいかもしれない
    • 卒業研究ではそうしている
• 物事を抽象的に考えられるようになる
  • ソフトウェア設計/アーキテクチャ関連の理解に手こずったことがあるのでだいぶ苦手意識が強い
    • 抽象的な概念を適当な例をつけて具体化した上で考えるようになれれば達成できそう？
  • 結局慣れ(いいえ)
• 技術記事というか今やっていることを記事にできるようにしたい
  • ほとんど書いたことがないのでどれくらい難しいことなのかがわからない
  • 毎月今月やったことリストみたいなのを書いてもいいかもしれない
    • 日記レベルにしてしまうと面倒すぎてやらない気がする
• 正しく批評できるようになる
  • これが苦手なので技術や製品に対する議論に参加できない
    • 変なことを言いたくないので当たり障りのないことだけ言おうとして結局黙っているように見える
  • そもそも会話するのが苦手なのでそこから改善する必要がある？
• フロントエンドをまともに書けるようになる
  • ずっとほぼバックエンドだけしか書いてこなかったのであまり得意ではない
  • バックエンドとフロントエンドの開発を両立させるのどうやるんですか？私はわかりません
• 他人が書いたプログラムを読めるようになる
  • 自分が書いたプログラムすら読めない時がある
    • メモとかドキュメントがないプログラム位しか読んでないからかも？
  • そのせいもあって再実装か再設計しかしてない
    • やめたい(やめたい)
• 今やっているOSSプロジェクトをまともにする
  • 外部コントリビューターを迎えたい
    • 私の直接の知り合いでないという意味
  • 開発速度が遅いのでその辺りをどうにかしたい
    • おもに私のモチベーションと技術力と単純に必要な実装量が多すぎるだけ
    • 試算すると同じようなプロジェクトと同じ規模になるまで30年かかるらしい,,,

各種人生周り

• 話のタネを作る
  • 食事会とかで話すネタがあんまりないのでいくつか作っておく
  • プログラミングのことですら話すことないのにそれ以外のことで話すことなんかあるわけないよ！
• 常人的な趣味を作る？
  • 現時点で趣味と言えそうなモノ:
    • プログラミング
    • 旅行
• 新しいコミュニティーに入る or 作る？
  • そこまで必要ではないかもしれない
  • これまでの数年間でほぼ毎年新しいコミュニティーを作るか参加するかしてきた
• 集中力を長く維持できるようにする
  • 1Hくらいで集中が切れてしまうのでどうにかしたい
  • 周りの環境音が影響してそうな感じがある
    • 今は音楽なりなんなりを流して誤魔化しているけど、根本原因の解消にはならない気がする
• 英語が読めるようになる
  • 英検2級は持ってるけどそんなに読めない
  • 技術文書(おもにOSSのリファレンス)を読むのを諦めることがあるのでやめたい
  • 読むだけでなく話す/書く能力もあげたい
  • 利用可能な語彙が少ないので思考を単純にしたい時に英語を使うのでもう少しできるようになりたい

終わり 適当に更新するかも

2024年振り返り

(振り返り/2024年は)初投稿です。

表題の通り2024年を振り返ります

技術周り

今年のコントリビューション数は945でした

2023年は1172contribsだったので 大幅減 です。 考えられる原因:

• 忙しかった
  • 卒業研究だとか研究室活動等に忙殺されてた
• 単にプログラム書いてない
  • プログラムを書く以外のタスクが多めになってきた

    • 

      アクティビティー比率(左: 2024/右: 2023)

言語の比率(体感)としては

• TypeScript: 95%
• C++/C: 3%
• Ruby: 2%

という感じでした。基本TSで、Goにかんしては書いた記憶がなくてだいぶまずいことになっている(全く追えていない)気が...

登壇

• RubyWorld Conference 島根OSS協議会スポンサーセッション(一部)
  • 人材育成に関連した発表の中で2分ほど話しました

来年はカンファレンス/勉強会で話したい気分です

人生

覚えてないのでダイジェストで

• 0x14歳になりました
  • 助けて〜〜〜〜〜〜〜〜
  • 🍺🍷に関しては今覚えるとまずいことになることがわかりきっているので触れないことにしています
  • nn歳異常成人humanになりつつあり、終わり
• 進級しました
  • 万年留年候補でしたが5年(高専生なので最終学年が5年)までストレート進級できて嬉しい
• 就職活動を始めて、終わりました(完了の意味で)
  • 3月には全て終わらせていたのでだいぶ早い
  • 同級生の中ではかなり早い方だったみたいです

旅行

行った場所(大まか):

• 東京(8月)
• 横浜(11月)
  • 始めて飛行機に乗りました(IZO-HND)
    • だいぶ楽しかったがこれ以降乗る機会がない
• 京都(2、12月)
• 大阪(12月)

行った場所(細かく):

• グラングリーン大阪
  • 思ったより小さい気がしなくもないがビル群に圧倒されました
• 東京証券取引所
• 京都市役所
• パシフィコ横浜
  • 周りが都会すぎる
• サンシャイン60
  • ジャスティス以外の感想が(ry
• 東寺
  • 大仏すげーーーー
• 東本願寺
• 頂法寺(六角堂)
  • 街の中にポツンとある感じが良かった
• 阪急百貨店/阪急3番街
  • 東京より通路が複雑で迷った
  • 百貨店の入り口の雰囲気に圧倒されました
• Nintendo KYOTO
• 千光寺(尾道)
• 二条城(外だけ)
  • でかい
• 米子高専(鳥取県)
• 京都タワー
  • ちょうど60周年イベントやってた
• 国立科学博物館

乗った鉄道路線、航空路線一覧

2024年中に乗車したすべての路線を列挙してみようと思います

大手私鉄

• 阪急電鉄
  • 京都本線(完乗)
• 東急電鉄
  • 東横線(完乗)
• 京浜急行電鉄
  • 本線(品川-横浜)
  • 空港線(完乗)

大手私鉄に3社乗れたのはだいぶでかい!!

JR

• JR西
  • 山陰本線(伯耆大山-宍道)
  • 伯備線(完乗)
  • 木次線(完乗)
  • 芸備線(備後落合-広島)
  • 山陽本線(新井口(広島市)以東完乗)
  • 東海道本線(神戸-米原)
  • 呉線(完乗)
  • 山陽新幹線(広島-新大阪)
• JR東海
  • 東海道本線(完乗)
  • 東海道新幹線(新大阪-京都、熱海-浜松)
• JR東
  • 山手線(大崎-品川)
  • 中央・総武線(渋谷-水道橋-東京)
  • 湘南新宿ライン(池袋-大崎)

地下鉄など

• 東京メトロ
  • 半蔵門線
  • 東西線
  • 銀座線
  • 有楽町線
  • 副都心線
• 都営地下鉄
  • 大江戸線
  • 三田線
  • 浅草線
• 京都市営地下鉄
  • 烏丸線(烏丸御池-京都)
  • 東西線(二条城前-市役所前)
• 横浜高速鉄道
  • みなとみらい21線(横浜-馬車道)

その他

• 広島電鉄宮島線/本線(広島-商工センター)
• スカイレール(完乗)
  • 3月で廃止されました
• アストラムライン(長楽寺-本通)
  • 6000系(25年度までに廃車)に乗ってきました
• 日本航空 出雲-羽田

松江->広島(200km, 8時間)、広島<->東京(900km,14時間)、広島->尾道、尾道->呉経由->広島で18きっぷを使って旅行したのでだいぶ乗った距離が多くなった気がしています。

それ以外にも乗った気がしますが覚えてません

来年の抱負

大まかに:

• 生存
  • 割とマジで助けてください
  • 同学年の人たちに早く結婚しないと死ぬぞと圧力をかけられています
    • 気づいたら勝手に100日後に結婚するlaminne botが生えていました
    • 
• 仕事ちゃんとやる
  • 戦える自信がありませんが...
• OSS活動周り頑張る
  • 去年から継続して2PJやっていますが、外部コントリビューターがいないのでちゃんとついてほしさがあります
  • 通常のコントリビューションもやっていくつもりです
• 何かしらプロダクトを個人開発してリリースする
  • 今1つ取り組んでいるのはあるけどお金にはならなさそう
  • 商才がない...

以上です、 来年もよろしくお願いします

はてなリモートインターン2023に参加しました

(はてなブログは)初投稿です。

題名の通り、はてなリモートインターン2023に参加してきました。今回はその記録です。

日程は8/21から9/8の15日間(三週間)で、同じクラスの人たちより大体1週間ほど長い期間でした。

応募した理由

大体こんな感じ。

• はてなという企業を昔から知っていた

(はてな)ブログとかブックマークを作っている会社というのは中学生くらいの時から知っていたし、 いろんなところで"はてな"という名前の(良い意味で)変な会社があるという噂は聞いていました

• 技育展/技育博で見かけた

技育博は去年と今年、技育展は去年と一昨年出ていて、その中のスポンサー企業の中にはてなの名前が入っていたのも理由として結構大きかったと思います。 去年の技育博ははてなの社員さん(誰かは忘れてしまった)と話をさせてもらったのも記憶に残っていました。

• はてなのインターンに参加した人の記事を多く読んでいた

普段から技術的なことに関してたくさんブログなどの記事を読んでいるのですが、その過程ではてなのインターンシップに参加しましたの記事を書いている人がそれなりにいてこういうインターンシップがあるのか〜と思っていました(読んでいる時はまだ3年生だったので)

やったこと

パートは前半の講義(1w)と後半の実践パート(2w)に分かれていて、講義パートでは基本的な技術のこと、後半の実践パートでは2人チームで実際のプロダクトに機能追加をするという内容になっていました。

講義に関しては実践的ではあるものの基礎をしっかりと理解できるような内容で楽しく聞くことができました。 学校の授業もこんな感じでやってほしいなぁと少し思いました(学校の授業はすごく抽象的なことしかやらない)。

実践パートはMackerelチームに配属され、 id:ucciqun と共にMackerelの"数値ウィジェット"機能の(フロントエンドの)改善に取り組みました。 コードを読んで実装を考えるのに大半の時間を割き、実際にユーザーの方が使うことを逐一考えながら実装を行いました。

私は数値ウィジェットからグラフの全画面表示を開けるようにする変更を行いました。詳しくは公式のお知らせをご覧ください... mackerel.io

感想

非常に充実した3週間になったと思います。(途中数日間体調不良でお休みするなどありましたが...)
普段から複数人で開発するときにはオンラインで作業していますが、実務で(しかも、半分以上の人がリモート)リモートワークをしている環境でどのようにコミュニケーションや作業を進めているのかについて知ることができ非常に興味深かったです。

成果発表で社長賞をいただくなど、いろんな人に褒めてもらったのも非常に良かったです。

以上終わり