少し前から結構色々な、画像生成AIが話題になっている。
LINEでテキストメッセージを送ると画像を返してくれるような、簡単に使えるようなものを作ってくれる人もいて、早速フレンドになったはいいものの、すぐに制限に引っかかってしまい、面白くない。

というわけで、公開されている内容なので自前で用意してみようと考えた

Stable Diffusion

公開されている画像生成AIで、一番メジャーそうなのはこの「Stable Diffusion」のようなので、まずはそちらを使ってみることにした。
使うにはNVIDIAのボードを積んでいる必要があるようだ。ちなみに私のラップトップのスペックはこんな感じだ

CPU：AMD Ryzen 9 5900HS with Radeon Graphics 3.30 GHz
Memory：16G
GPU0：NVIDIA GeForce RTX 3050 Ti Laptop GPU
GPU1：AMD Radeon(TM) Graphics

前準備

Docker Desktopは入っているものとします。
また、NVIDIAのCUDA Toolkitを入れる必要があるそうです
https://developer.nvidia.com/cuda-downloads

Hugging Faceから学習済みモデルを取得

Hugging Faceという、学習済みのモデルやデータセットなどを公開してくれているサイトがあるので、そちらで公開されているStable Diffusion用のモデルを使用します

HuggingFace
https://huggingface.co/

右上の「Sign Up」からアカウントを作成します。
必要事項を入力し、最終的にメールによるアクティベートを行った後に、モデルの利用申請を行います

公開されているモデルはいくつかありますが、今回は一番新しいv1-4を使いますので、こちらのページに行きます

CompVis/stable-diffusion-v1-4
https://huggingface.co/CompVis/stable-diffusion-v1-4

ライセンス条項を確認して、チェックを行い、リポジトリへのアクセス許可を得ます。

その後、ローカルにて下記コマンドでモデルをダウンロードします

>git clone https://huggingface.co/CompVis/stable-diffusion-v-1-4-original
Cloning into 'stable-diffusion-v-1-4-original'...
remote: Enumerating objects: 54, done.
remote: Counting objects: 100% (54/54), done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 54 (delta 22), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (54/54), 71.74 KiB | 282.00 KiB/s, done.
Updating files: 100% (5/5), done.
Filtering content: 100% (2/2), 7.14 GiB | 14.32 MiB/s, done.

>dir
stable-diffusion-v-1-4-original のディレクトリ

2022/09/04  22:31    <DIR>          .
2022/09/04  22:23    <DIR>          ..
2022/09/04  22:23             1,478 .gitattributes
2022/09/04  22:23            11,891 README.md
2022/09/04  22:32     7,703,807,346 sd-v1-4-full-ema.ckpt
2022/09/04  22:29     4,265,380,512 sd-v1-4.ckpt
2022/09/04  22:23            71,237 v1-variants-scores.jpg
               5 個のファイル      11,969,272,464 バイト

clone すると、ユーザ・パスワードを聞かれるので HuggingFace のユーザ名/パスワードを入力します。
clone結果としては上記のような形で、11GBほどファイルがありますね。。。

sd-v1-4.ckptをmodel.ckptにリネームしておきます。

Dockerでの環境構築

Dockerのベースイメージに関してはNVIDIA Cloudのものを利用すると良さそうと偉い人が言っているので素直に真似る

FROM nvcr.io/nvidia/cuda:11.7.1-cudnn8-runtime-ubuntu20.04

ARG DEBIAN_FRONTEND=noninteractive
ENV TZ=Asia/Tokyo

RUN apt-get update && apt-get install -y wget git git-lfs libglib2.0-0 libsm6 libxrender1 libxext-dev

RUN wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh && \
    sh Miniconda3-latest-Linux-x86_64.sh -b -p /opt/miniconda3 && \
    rm -r Miniconda3-latest-Linux-x86_64.sh

ENV PATH /opt/miniconda3/bin:$PATH

RUN git clone https://github.com/CompVis/stable-diffusion && \
    cd stable-diffusion && \
    conda init bash && \
    conda env create -f environment.yaml && \
    echo "conda activate ldm" >> ~/.bashrc

さらに、DockerComposeを用意する

version: '3'
services:
  app:
    build: .
    working_dir: /stable-diffusion
    tty: true
    volumes:
      - ./stable-diffusion-v-1-4-original/:/stable-diffusion/models/ldm/stable-diffusion-v1/
      - ./outputs:/stable-diffusion/outputs
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]
    environment: 
      - NVIDIA_VISIBLE_DEVICES=all
      - NVIDIA_DRIVER_CAPABILITIES=all

さて、動かすぞ

>docker-compose up --build
[+] Building 2.1s (8/8) FINISHED
 => [internal] load build definition from Dockerfile                                                               0.0s
 => => transferring dockerfile: 717B                                                                               0.0s
 => [internal] load .dockerignore                                                                                  0.0s
 => => transferring context: 2B                                                                                    0.0s
 => [internal] load metadata for nvcr.io/nvidia/cuda:11.7.1-cudnn8-runtime-ubuntu20.04                             2.0s
 => [1/4] FROM nvcr.io/nvidia/cuda:11.7.1-cudnn8-runtime-ubuntu20.04@sha256:4ee00dd83e88e75739870df5ac67ec38bea09  0.0s
 => CACHED [2/4] RUN apt-get update && apt-get install -y wget git git-lfs libglib2.0-0 libsm6 libxrender1 libxex  0.0s
 => CACHED [3/4] RUN wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh &&     sh Minicon  0.0s
 => CACHED [4/4] RUN git clone https://github.com/CompVis/stable-diffusion &&     cd stable-diffusion &&     cond  0.0s
 => exporting to image                                                                                             0.0s
 => => exporting layers                                                                                            0.0s
 => => writing image sha256:5d2c7f98241a55c1f2b608d865bfb22e09b1f91dc425d86db7a55d8e2b4d7b07                       0.0s
 => => naming to docker.io/library/stablediffusion-app                                                             0.0s

Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them
[+] Running 1/0
 - Container stablediffusion_app_1  Recreated                                                                      0.1s
Attaching to stablediffusion-app-1

シーン。。。。

ここから、うんともすんとも言わなくなってしまった。
せめてエラーでも出してくれればいいのだが、いくら待っても何度やり直しても結果が変わらないので、きっと何かが足りないのであろう。。。
げせぬ

というわけで、一旦Docker Composeは諦めて、DevContainerで試行錯誤してみることにした。
続きは明日。。

参考： Stable DiffusionをDockerで動かすhttps://zenn.dev/choshicure/scraps/14bca2492bf49f

先日、Denoの記事を書いたが、ちょうど公開されたmozaic.fmで話題に上がっていた

ep102 Monthly Ecosystem 202208
https://mozaic.fm/episodes/102/monthly-ecosystem-202208.html

Big Changes Ahead for Deno
https://deno.com/blog/changes

Denoの記事が投稿されたのが8/15。
mozaic.fmの公開が8/20ということで、いま時点から考えてもなかなか早い話題だ。

正直言って私はこのあたりの知見がないと言っても過言ではないレベル感なので、評価的なコメントは難しいし、誰も望んでいないだろうからしない。

ただ、いつも思うのはJavaScriptやTypeScript周りのフレームワークやエコシステムの数の多さというか、流行り廃れのスピード感はすごいな、と思わずにはいられない。

mozaic.fmの中でも話題にはなっていたが、それぞれの仕組みが何を目指して、それを使うモチベーションやメリットがどこに有るのか？というのだけでもちゃんと抑えていきたいところ。

話の中で出てきた、ViteやBunに関しても恥ずかしながら知らなかった。。。
うーん、追っかけるの実際問題難しいよなー

Bun
https://bun.sh/

Vite
https://vitejs.dev/

今まで、定期購読はしているものの、なかなか有効活用できていなかったWEB+DBプレスですが、今月号は結構読むことができています。
これも通勤の効果でしょうか？

特集の一番目は「実践データモデリング」

私自身、前職では基幹系の業務システムパッケージの開発に従事していたこともあって、題材として登場する「発注」や「出荷」といった業務のデータ構造や業務知識に関しては知らないわけではない。むしろ、一般的に考えると詳しい方なのでは？と思わなくもない。
というわけで、読みながら勉強になるな、と思う反面、やっぱりこのあたりは難しい問題だよな、と思ってしまうんですよね。

ソフトウェアを作る上での複雑さへの挑戦

現在は基本的に大きいプログラムを作るのではなく、責務を適切に分割し、シンプルな単位でのプログラムを組み合わせてシステムを作るのが良いとされている。

これに関して異を唱えるつもりはあまりない

前職でも、パッケージを作ったとしてもバージョンアップを考える必要があり、バージョンアップの際には過去との仕様互換性を保ちながら巨大なプログラムを新しい言語なりで作り直すとか、デスマーチ確定な感じだった。

パッケージのバージョンアップには多大な工数と期間を要し、既存顧客からは仕様の互換性に関して文句を言われ、新規の顧客からは不具合を指摘される。
もうちょっとうまいことできないものなのか。毎回スクラップ＆ビルドはもうやりたくないと。

そうではなく小さいプログラムにする。更には責務の分割、モジュールの分割を進めることで、サービスを切り出す。
そしてサービス単位でバージョンアップすることを可能にしていくというのが今の流れで、その最たるものがマイクロサービスなんだと理解している。

本書でのデータモデリングも、単一テーブルにあれこれ詰め込むのではなくて責務を分割統治していくのが基本だ。

システムとして何を優先させるべきなのか

一方で、この方法だとそもそも取り扱う業務数が多い基幹系システムだと、テーブル数がかなりの数になるのでパフォーマンスの懸念は生じてしまう。
テーブル数が多くなることで、一つ一つはシンプルなんだけど、数が多すぎてひよるということもある。

特にパフォーマンスに関してはこだわりが強い人達が多いのも基幹系システムのユーザ特徴だ。
メインフレームCUI画面とWebブラウザを比較して、おそすぎると言われるの辛いよね。

データモデルをシンプルにするということは、基本的には機能もシンプルになっていくものだと理解している。
一方で、一目ですべての情報を把握したい。より多くの情報を画面に詰め込みたい。しかも早く。みたいな要求も当然のようにやってくる。

なぜなら、今がそうだから、みたいな理由で。

SoRである基幹システムのユーザは、システムを使って入力することが業務なのではなく、価値を生み出す業務は別にあるという認識は強い。
画面遷移なく、ショートカットキー盛りだくさんで何分でどれだけデータを入れられるかや判断できるかの選手権が行われている。

あれもこれも表示させる画面を超スピードで表示させるには、できるだけテーブルJOINを少なくするような、言ってしまうと下手くそなデータモデルだなぁと言われるようなテーブルになりそう。

それもこれも、個別最適化されたような過去のカスタマイズ遺産みたいなものがだめなんだ！って言うのは簡単なんだけど、ソフトウェアかくあるべきみたいな喧嘩をしてもしょうがないしね。

実際のところ、現代においてもパフォーマンス上やっぱり問題なのだろうか？みたいなところに関してはわからないのだが、こうやって頭の中で考えると言うのは結構楽しいものである。現実は厳しいけれど。

そんなことを思った2022年の夏。皆様はいかがお過ごしでしょうか。

私は元気です

Gartnerが出しているハイプ・サイクル。
これの先進技術に関するものが公開されていました

Gartner Identifies Key Emerging Technologies Expanding Immersive Experiences, Accelerating AI Automation and Optimizing Technologist Delivery
https://www.gartner.com/en/newsroom/press-releases/2022-08-10-gartner-identifies-key-emerging-technologies-expanding-immersive-experiences-accelerating-ai-automation-and-optimizing-technologist-delivery

先進技術ということもあって、そのどれもが黎明期～過度な期待のピーク期という扱い。これら技術が幻滅期やそれ以降のフェーズへの生き残りをかけた戦いがこれから始まるわけですね。

先陣を切っているものが「Cloud Data Ecosystems」ということで、若干他のラインナップからするとここに並ぶのかな？という気がしないでもないです。
NFTに関しては、あと2～5年で安定期に入るとGartnerは予想しているんですね。

どの技術が実際に今後のキーとなるのか、ハイプ・サイクルからそれを導き出すというのはあまり現実的ではないかもしれないけれど、少なくともここに載っている内容に関しては、ある程度何を指し示しているのか、ということに関しては知っておくに越したことはないと考えている。

そういう意味で、ちょっと気になったものとしては「Internal Talent Marketplaces」というキーワードだ。

Internal Talent Marketplaces

正直あまり聞き慣れていない言葉ではあった。
デロイトのページがよく書かれているので読んでみた

社内に労働マーケットの考え方や手法を持ち込み、人材のキャリアやスキルを可視化・拡張し、柔軟に配置転換をしながら育成、活用するマネジメント・プラットフォームのあり方

https://www2.deloitte.com/jp/ja/pages/human-capital/articles/hcm/internal-talent-marketplace.html

タレントマネジメントは、ここ数年で随分といろいろな企業で話を聞くようになった。私が所属している会社でも、タレントマネジメントツールを導入している。
一方で、タレントマネジメントがちゃんとできているのか？という点や、そもそもなんでタレントマネジメントが必要なのか？ということに対して有効な動きを取ることができていないのが実情でもあるように感じる。

実際のところ、社内マーケットプレイスというものはどこまで有効なのだろうか？

プロジェクト単位にメンバーを公募。つまり社内のタレントマーケットから探し出して～というと、連続性のないプロジェクトであればいいかもしれないが、連続性のあるプロジェクト・業務の場合、どうしてもこれまでの業務知識なり経験というものがあると嬉しい状態になる。

もちろん、メンバーを固定化させたほうがいいというわけではなく、門出は開いておき流動性は持たせたい。
ただ、流動性をもたせ過ぎるとオンボーディングが大変になる。

また、全部のプロジェクトが同じ期間で区切りがあるなんてことはないだろうから、タイミングにも左右されるようになるんだろう。

一方で、新しいことへ挑戦するという風土みたいなものは培われるだろう。
また、そういった高いメンタリティでプロジェクトへJOINするのであれば、実際のところそこまで大きな問題にはならないのかもしれない。

つまりは、それだけ成熟した。レベルの高い組織であれば成り立つということなのかな？とも思った。全員売れ残りみたいな社内マーケットになり、有用なメンバーは全部外部調達（外注）なんてシャレにならないよ。

タレントマネジメント

社内マーケットプレイスに到達するのは一足飛びには難しいかもしれないけど、タレントマネジメントとして、自分が培った技術や知識を可視化して、それを自分が従事したいプロジェクトへアピールしていくという考え方はとても大事だとは思う。

日々の業務におわれていると、なかなか今この業務が自分のなんのスキルアップにつながる可能性があるだろうか？ということに関しては埋もれていってしまう。

また、それらを意識して仕事をするのとしないのとでは、明確にスキルアップ速度が異なると考えている。
そういう意味でも、もう少ししっかりとタレントマネジメントに関しては実施していく必要があるだろうな、と考えた。

現クレディセゾンCTOの小野さん著作「その仕事、全部やめてみよう」をKindleで購入。読んだ

読みやすい内容だったので、サクッと読むことができた。
その中でも特に思った箇所に関して。

ラストマン戦略

「ラストマン戦略」とは、グループ内で自分が一番になれそうな領域を決め、「あの人がわからないなら、誰に聞いてもわからないよね」という、いわば 最後の 砦 とも言うべきスペシャリストを目指す成長戦略

この戦略は社会人数年目の時に考え、やっていたのでよくわかる。周りが情報系の学部卒が多い中、プログラミング初学者だった私からすると何かしらの武器が欲しく、人が持っていなかった武器を探る必要があったのだ。

よくわかる一方、そこからの発展だったりその先を見据えた動きを取れなかった。確かに、ある一定のポジションは確保したが、あくまでそのグループの中でのラストマン。
小野さんのように、そのグループがハイレベルであればそのラストマンは権威となりうるが、小組織においてはただのお山の大将。
グループを広げていく必要があったのに、そのグループで満足してしまったのだろう。

ただ、お山の大将も気持ちいいんだよね。特に、周りに対して劣等感を抱いていた人間にとっては。そう言ってできたコンフォートゾーンを脱するためには本書の中にもある通り、小グループから業界全体に向けて動く。もしくは「リスクをとる」形か。

15年くらい遡って頭叩いてきたい。
というわけで、入社5年目くらいまでの若手にちょっと紹介しておきたいところ。

駄文

もう随分と前の話になってしまうが、実は著者とは何度か仕事の関係でお会いしたり話を聞かせていただいたことがある。私がTwitterを始めたのも、そういうサービスがあって面白いという話を会話の折に聞いた事に端を発していたりする。
本書の内容もところどころ、当時お酒飲みながら聞いた話が混じっていて懐かしく思った。（お友達というレベルではない）

同年代という親近感と、頭の出来違いすぎね？っていう劣等感が色々と混ざり合った複雑なところはあるが、素直にすごい人という事には変わりなくどこまでも頑張って欲しいところ。

自分も頑張らな。。

いきなり何を言いだすんだという感じのタイトルであるが、情けない話ではあるのだが、ある程度 “人に見られている” という状況下の方が個人的には生産性が上がる方だと、自分では思っている。

個人学習として何か新しいことを勉強しようとしたとしても、何かしら崇高な使命を持って勉強しているわけでもないのでモチベーションを維持できない。マークがまず終わらせろっていうんだけどね、ちょっと仕事忙しくなるとダメなのね。

こういう時、例えば全然違うことを勉強していたとしても、お互いに状況を話し、チェックしてくれるような存在がいてくれればなぁと思うわけですよ。

言ってしまえば、それだけ弱い人間ということではありますが

ずいぶん前に rebuild.fm で誰かが言っていたなぁというのを覚えていて、あぁ、いいなぁと思ったのがきっかけである。今検索して見ると Morita さんだったのか

https://bellflower.dodgson.org/%E9%80%B1%E5%A0%B1%E4%BB%B2%E9%96%93-a799ad07f349

同じように rebuild.fm を聞いて、仲間内で始めた人も結構多く見受けられる。
ただ、そう言った仲間ってなかなか見つけづらいよねって気がする。もちろん、ガンガン勉強会などに参加していくような人でいれば自然と周りに集まるのかもしれないが。
ただ、そういう人はあまりこういう悩みはないのではと思わなくもない。

というわけで、良き仲間が欲しい
自分が相手にとって良き仲間となれるかは甚だ疑問ではあるのだが。

すっかり時間がたってしまったが、先日行われたDevLove主催の「ドメイン駆動設計本格入門」に行ってきた。

DevLove　Premium　第３回ドメイン駆動設計本格入門
https://devlove.doorkeeper.jp/events/85247

ドメイン駆動設計といえば、言わずもがなエリック・エヴァンス本。

読み始めてはいるものの、正直自分のものとすることができておらず途中でそのままにしてしまっていた。
とはいえ、ドメイン駆動設計は理解しておきたいと考えていることに変わりなく、理解の助けになればと思い参加した。

ドメイン駆動設計 本格入門 from 増田 亨

詳しいことはスライドをご一読。
講師は「現場で役立つシステム設計の原則」の著者である増田さん。

自分自身、基幹系のシステム開発ばかりずーっとやってきているので、今回の増田さんのお話の中で散りばめられていた、複雑さにどう立ち向かうか？という話にはうなずくばかりであった。

そもそもの業務や仕様が複雑であったり、それを無理矢理にパッケージという形に落とし込んでいるせいなのか、単純に設計力が足りないせいなのかもしれないけれど、悲しいことに、作り上がる頃には立派に複雑になってしまっていることが多い。

そして、属人的なコードや機能が膨れ上がり、保守が困難なプロダクトが出来上がる。
もちろん、それに争うのだが、抗い方の一つとして今回の話を考えたいところだ。
ただ、自分一人でどうにかなるものでもないので、エヴァンス本や増田さん本を広めて組織的に対応しないとなぁと思うところではあるかなぁ。

最近、月に一度は勉強会に出たいと思って出ている3月分。
都内であれこれと勉強会はあって、それぞれの特色があって面白い。
DevLoveは色々と形態はあるのかもしれないけれど、講義形式の開催が多い気がする。
LT中心とは違うけれど、しっかりと勉強出来るのはいい。

今日は久しぶりに。本当に久しぶりにIT系の勉強会に顔を出してきた

逆境から新規事業をスタートアップする 〜現場探訪編〜
https://devlove.doorkeeper.jp/events/81642

新規事業を考える上で必要なこと、気づいたことを実際の体験をもとに発表していただきました。
純粋な技術系の勉強会ではないけれど、開発と言う意味においては大事な話。

特に新規事業を手がける部署にいるわけではないのだけれど、
何も事業に関わらず新規機能開発でも同じことが言えるわけなので勉強になった

こう言う場に顔を出すと、周りの意識の高さってやつに当てられてしまう面がある
自分自身だけでなく周りも含めてマインドセットが高い状態をどうやって根付かせたものか・・・。

様々なことを仮説を立て、検証を行いながら進めていくにしても
その前段階でそれらを実施していく土壌づくり／文化づくりがなぁ。
自分自身の力なさを感じる日々であります

そうはいっても、こうやって勉強会に出ると何かしらやる気がわくもので、
やはり定期的に足を運ぶと言うことは自分自身の為になると感じた。
学びをもとに、実際の行動を起こさなければ、なんとなくよかったで終わってしまうので、
その点は注意しなければならないが、時々顔を出せるよう時間を作るようにしよう。

よくよく考えてみると、今日の話は特別逆境に感じなかったな・・・。
新規事業を進めるための部署の人なわけだし・・・・