Qiita Conference 2024の参加しての感想

はじめに

Qiita Conference 2024の1日目に参加して、個人的に面白かったセッションの感想を書いてみます。

qiita.com

内製化でクルマの未来を作るぼくらの話

KINTO Unlimited というサービスのアプリ開発の新規立ち上げのお話。
短納期の中、MVPの定義と適切なタスク分担の工夫でやり切ったそう。

MVPをきちんと定義して、ユーザーに価値あるものを最短で提供するカルチャーがいいなと思った。

開発生産性向上サービスを作るFindyが自分たちで開発生産性を爆上げした組織づくりの歩み

開発生産性のお話。
Findyでは開発生産性の指針は「作るものが決まってからユーザーの手元に届く時間と施策数」。
この指針の元、次のことを徹底したとのこと。

• タスクの粒度は細かくすること、プルリクのレビュー負荷を下げる
• レビューは最優先事項とするカルチャー
• CI/CDの改善、1時間かかっていたものを10分に短縮

自分の所属会社と比較したとき、同様の指針をもとにカルチャーを変えようとしているが、社内政治等の理由でなかなか難しいなと改めて思ったのは秘密。

三流エンジニアが、世界一流の環境でなぜか生き残れている誰でも出来そうな秘密

著書の内容と被る部分もあったが、ここでは著書にはないお話を。

牛尾さんから見て天上人のような凄腕エンジニアに聞いた話で、その人は次のことを徹底しているそう。

• できる人を観察して真似をする
• みんなと違うことをして差別化を図る
• 何をやらないかを決めて、いかにインパクト（価値）を提供するか
• レイヤーが二つ上の上司と1on1を実施し、関心のあることを実現してあげる

総じて戦略が100％大事。自分も差別化を図ることを徹底してみようと思う。

おわりに

こういったカンファレンスに参加するのが久々だったので、とても刺激になりました。
今後のキャリアについて改めて考えるいいきっかけにしたいと思います。

Macにpyenvを使ってPythonをインストールする

はじめに

pyenvを使ってPythonをインストールする際、やり方を忘れて都度調べているのが手間になってきたので、ざっと手順をまとめたいと思います。

前提

利用OSは MacOS で、シェルは zsh の前提になります。

手順

Homebrewのインストール

Homebrewをインストールしていない場合、以下を参照してインストールを行う。

brew.sh

pyenvの設定

brewコマンドでインストール。

brew install pyenv

pyenvのパスを通すため、~/.zshrc に以下を追記する。

export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init --path)"
eval "$(pyenv init -)"

追加設定を読み込ませる。

source ~/.zshrc

Pythonの設定

pyenvでイントール可能なPythonのバージョンを確認する。

pyenv install --list
Available versions:
  2.1.3
  (中略)
  3.11.6
  3.11.7
  3.12.0
  3.12-dev
  3.12.1   # <- 本記事では、左記のバージョンを指定する。
  3.13.0a2
  3.13-dev

バージョン3.12.1のPythonをインストール。

pyenv install 3.12.1

インストールしたバージョンを確認

pyenv versions
  system
  3.11.4
* 3.12.1 (set by /Users/[ユーザー名]/.pyenv/version) # <- 先ほどインストールしたバージョン

Python 3.12.1 を設定

# システム全体で設定したい場合
pyenv global 3.12.1

# プロジェクトごとにバージョンを設定したい場合
pyenv local 3.12.1

Pythonのバージョンを確認

python --version

Python 3.12.1 # <- 無事に設定したバージョンになっている

おわりに

dockerを立てるほどでもないけど、Pythonの最新バージョンで検証したいという時に、pyenvはオススメできるなと実感。

クラウドの基礎について

はじめに

こんにちは。Developer Roadmapsというサイトをご存知の方も多いと思います。
最近、AWS関連の勉強をしようと思い立ったので、クラウドの基礎について改めて調べてみました。 　 ※自分用のメモです。

roadmap.sh

クラウドとは？

AWSなどのクラウドサービスプロバイダー（CSP）が管理するアプリケーション、サーバー、ストレージなどのコンピューティング・リソースにインターネットを介して利用できる。

従量課金制で初期投資のコストを抑えることができたり、サーバーなどの物理的な資産を管理しなくていいなどのメリットがある。

クラウドサービスの種類は？

クラウドサービスの種類として、代表的なものは次の3つ。

• IaaS（Infrastructure as a Service）
  • ネットワークやサーバー（CPU・メモリ・ストレージ）などのコンピューティング・リソースを利用するサービス
• PaaS（Platform as a Service）
  • アプリケーション開発に必要な実行環境を利用するサービス
• SaaS（Software as a Service）
  • ソフトウェアやアプリケーションの機能を利用するサービス

これらのサービスがカバーする範囲の比較は次の通り。

レイヤー	IaaS	PaaS	SaaS
アプリケーション	×	×	⚪︎
データ	×	×	⚪︎
ランタイム	×	⚪︎	⚪︎
OS	×	⚪︎	⚪︎
仮想化	⚪︎	⚪︎	⚪︎
物理サーバー	⚪︎	⚪︎	⚪︎
ストレージ	⚪︎	⚪︎	⚪︎
ネットワーク	⚪︎	⚪︎	⚪︎

クラウドの導入モデルは？

クラウドを導入する上で、代表的なモデルは次の3つ。

• パブリッククラウド
  • AWSなどのサービスプロバイダー（SCP）がインターネット経由で一般ユーザーが利用できるアプリケーションやストレージなどのリソースを提供する
  • リソースは無料の場合もあれば、従量課金モデルで販売されることもある
• プライベートクラウド
  • 単一の組織専用の独自のアーキテクチャを通じて、スケーラビリティやセルフサービスなど、パブリック クラウドと同様の利点を提供する
• ハイブリッドクラウド
  • プライベートクラウドと1つ以上のパブリッククラウドを組み合わせたもの

おわりに

改めてクラウドの基礎について学び直してみて、今までは「なんとなく分かった気がする」の状態だったと再認識できました。
今後も学習を続けていきたいと思います。

参考サイト

今回の勉強にあたり、以下サイトを参考にさせていただきました。
ありがとうございます。

aws.amazon.com

azure.microsoft.com

www.itmanage.co.jp

www.topgate.co.jp

www.topgate.co.jp

data.wingarc.com

Terraformで定義したAWSリソースをLocalStackにデプロイする

はじめに

こんにちは。
AWSとTerraformの仕事と個人学習で、LocalStack を使っています。
今回は、勉強したことの振り返りです。
※本記事では、Terraformなどのツールの解説はしません。

構成

今回構築したのは、以下の構成図のようにS3にファイルをアップロードしたらLambdaを実行するシンプルなものです。

ソースコードは以下になります。

github.com

構築

Gitクローンします。

git clone https://github.com/44taka/study-localstack.git

LocalStackのコンテナを起動します。

docker compose up -d

terraformディレクトリに移動し、Terraformの初期化を実行します。

cd terraform/lambda
terraform init

Terraformの実行計画を確認します。

terraform plan

実行計画に問題がなければ、構築を開始します。

terraform apply

動作確認

AWS CLIコマンドでも確認できますが、今回は LocalStack Desktop を使います。
ダウンロード手順は以下ページをご参照ください。

iret.media

まずは、Lambdaが作成されていることを確認します。

はい、作成されていますね。 次にS3で対象バケットが作成されていることを確認します。

こちらも無事に作成されていますね。
では、最後にファイルをアップロードしてLambdaが実行されるかを確認します。

ログを確認すると、ファイルをアップロードした直後にLambdaが実行されているのを確認できますね。

削除

不要になったら、削除しましょう。

terraform destroy

おわりに

以上でTerraformで定義したAWSリソースをLocalStackにデプロイする手順になります。
お金を気にすることなく、Terraformの勉強ができるので個人的にオススメの学習法です。いいなと思ったら、ぜひ試してみてください。

SQLModelでDBモックを生成する

はじめに

個人でサクッと作ったPythonプログラムに、SQLModel を使っています。 テストコードを書く際にモック化したことをメモしていきます。

前提

DBは PostgreSQL を利用する想定です。 また、バージョン等は以下の通りになります。

• SQLModel 0.0.16
• PostgreSQL 16.2

DBに接続する場合

さて、通常は以下のように create_engine メソッドを使ってDBとのコネクションを確立し、SQLを実行します。

import typing
import sqlmodel


# テーブルモデル
class Todo(sqlmodel.SQLModel, table=True):
    id: typing.Optional[int] = sqlmodel.Field(default=None, primary_key=True)
    title: str

# コネクション確立
engine = sqlmodel.create_engine(
    url="postgresql+psycopg2://user:password@host:5432/db_name",
    echo=False
)

# SQL実行
with sqlmodel.Session(engine) as session:
    session.add(Todo(title="テスト１"))
    session.add(Todo(title="テスト２"))

ただ、これだとテストコードを書く際にDBを直接接続してしまい、余分なデータが溜まってしまいます。 その時に役立つのモックです。

モックを利用する場合

モック化する場合、create_mock_engine メソッドを使い、Session クラスに bind します。

import typing
import sqlmodel


# テーブルモデル
class Todo(sqlmodel.SQLModel, table=True):
    id: typing.Optional[int] = sqlmodel.Field(default=None, primary_key=True)
    title: str

# コネクション確立をモック化
engine = sqlmodel.create_mock_engine(
    url="postgresql+psycopg2://",
    executor=None
)

# SQL実行(※モックのためDBにはデータは登録されない)
with sqlmodel.Session() as session:
    session.bind = engine
    session.add(Todo(title="テスト１"))
    session.add(Todo(title="テスト２"))

おわりに

SQLModelがモック用のメソッドを提供しているため、簡単にモックを作成することができました。 この機能を活用することで、テストコードをより気軽に記述できるようになります。

docker-compose execコマンドがcronで動作しない

はじめに

個人開発してるバッチ処理でcronで定期実行するため、
docker-compose execコマンドで設定していたが、
正しく実行されなかった。

その原因と対処法について調査したのでメモ。

調査

cronの実行ログを確認したところ、以下の内容が出力されていた。

the input device is not a TTY

調査していくと docker-compose exec の場合、擬似TTYがデフォルトで割り当てされるためらしい。
ヘルプで確認してみた。

docker-compose exec -h
Execute a command in a running container

Usage: exec [options] [-e KEY=VAL...] SERVICE COMMAND [ARGS...]

Options:
    -d, --detach      Detached mode: Run command in the background.
    --privileged      Give extended privileges to the process.
    -u, --user USER   Run the command as this user.
    -T                Disable pseudo-tty allocation. By default `docker-compose exec`
                      allocates a TTY.
    --index=index     index of the container if there are multiple
                      instances of a service [default: 1]
    -e, --env KEY=VAL Set environment variables (can be used multiple times,
                      not supported in API < 1.25)
    -w, --workdir DIR Path to workdir directory for this command.

この影響でcronでコマンドが実行されなった模様。

対処法

cronで実行するには -Tオプション をつける必要がある。
ということで対処法は以下の通り。

# NG
docker-compose exec <サービス名> <実行コマンド>

# OK
docker-compose exec -T <サービス名> <実行コマンド>

ここで疑問

そもそも TTY ってよく理解できていないことが分かった。。
ということで追加で調べてみた。

TTYとは？

wikipedia の記述だと以下の通り。

ttyとは、標準入出力となっている端末デバイス(制御端末、controlling terminal)の名前を表示するUnix系のコマンドである。 元来ttyとはteletypewriter（テレタイプライター）のことを指す。

うん、よく分からん。。

もうちょっと噛み砕くと、SSHなどでサーバーに接速した際に一時的に割り当てられるデバイス名を表示する際に利用する。
個人的に利用する以下のサイトを見るとより理解しやすい。

「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

おわりに

運用していないと気づかないことも多々あるなと再認識。
その都度知らないことがわかるので、それはそれで面白いと思った今日この頃。

参考サイト

今回も参考にさせていただいたサイトは以下の通り。
先人達の知恵に感謝。

• cron駆動のdocker(docker-compose) execが走らない問題の対応
• crontabでdocker-compose execを実行すると"the input device is not a TTY"が出る
• dockerコマンドをcronで実行させたら「TTYが無いよ」と怒られた件

自己紹介

はじめに

今更ながらブログを始めてみようと思いました。
44takaです。
簡単に自己紹介をするとこんな感じ。

• 北海道出身で上京13年目のしがないWebエンジニア
• PHP、Pythonを主にやっている
• アラフォーに差し掛かり、体の老いを感じる今日この頃
• 老いに抗うためにランニングと筋トレを始めた

ブログタイトルの由来

最初に謝っておきます。
道産子なら知っているであろう夕方のワイドショー「どさんこワイド」のパクリです。

いい名前が思いつかず、北海道出身を前面に押し出すブログにしようと悩んだ結果なのです。
ブログを続けていく中でいい名前が思いついたら変えます。

何を書くの？

自分用の備忘録的な感じで技術ネタを中心に書いていこうかなと思ってます。
たまに運動ネタ、食べ物ネタも書くかもしれません。

最後に

完全にノリでブログを始めてみましたが、気が向くままに更新していこうかなと思います。
いずれは誰かの役に立つ情報も発進できるといいなと願ってます。