ソフトウェア開発」カテゴリーアーカイブ

ソフトウェアアーキテクチャに関して

たまたまですが、イベントにいくつか参加しました
ここのところ、登録はすれどもなかなか参加できなかったりしていたのでちょっと久しぶりです

ソフトウェアアーキテクチャメトリクス – Forkwell Library #44

ソフトウェアアーキテクチャメトリクス – Forkwell Library #44 – connpass

https://amzn.to/3IgDAGe

毎度おなじみのForkwellさんによるイベント。今回は「ソフトウェアアーキテクチャメトリクス」という本の訳者さんが登壇。

オライリー本なので、なんとなくタイトルからアーキテクチャに対しての何かしらのメトリクスを取得するための手法だとかがまとまっているのかな?と思っていたのですが、そうではないよう。

10人のアーキテクトが思い思いに話をしている内容であって、訳者の方いわく「エッセイ」だと。
なるほど。

オライリー本は、時々そんな感じのエッセイ本を出しますよね。

言ってしまうと、まだ話をまとめるには時期尚早ということなのかもしれないな、と思った。

NECグループAWS活用の裏側大公開|Well-Architectedフレームワークとコミュニティ

NECグループAWS活用の裏側大公開|Well-Architectedフレームワークとコミュニティ – connpass

こちらはAWSに焦点を当てたもの。
でも、よくよく考えて見るとこちらもアーキテクトの選択で何を重要視するのか?だったり、選択したアーキが正しかったのかを振り返るという観点では通じるものがあるかもしれないな?と思った。

AWSの資格試験では基本的にUdemyを中心に勉強をすることが多いのですが、存在は知っていてもちゃんとWell-Architectedフレームワークを読んだことないな、と思いました。

落ち着いて考えてみると、一度それを頭に読み込んでから資格勉強したほうがいいのでは。。。と今更ながらに思ったわけです。

AWS Well-Architected – 安全で効率的なクラウドアプリケーション (amazon.com)

このあたりの資料はそれなりの頻度で更新されていきます。
そもそものAWSサービス自体が追加されていくので結構たいへんですよね。。。

イベントでは、どうやってこれらのレビューをやっていくのかとかも話されていたので興味深かったです。
一方で、自社でそこまで回していくのは、それなりに規模がないと厳しいような気もしましたが、そのあたりはしっかりと学んでいないものの言い訳なのかも。

うーん、勉強しないとですね

SoftwareDesign2月号

定期購読しているSoftwareDesignの2月号が届きました。

https://amzn.to/3UtdNSq

今月号の特集としてはテストとWeb APIセキュリティに関して。

テストに関しては、テスト技法に目を奪われがちなんだけど、そもそものテストの考え方を正していく必要があるとしてテストマニフェストが紹介されていた

https://www.growingagile.co/the-testing-manifesto/

SoftwareDesignに掲載されていたものは2015年バージョンで、上記のものは2023年バージョンのようだ。
基本的な考え方が変わっているわけではなく、言葉を少し修正した形と紹介されていた。

checking functionality over Testing understanding

機能性をチェックするよりも、理解をテストするとでも訳すのだろうか?
SoftwareDesignでは「機能性をチェックするよりも、チームが理解している価値をテストする」とある。

これは、結構難しい問題に感じる。

本来、価値を提供するために機能を作り込んでいるはずのものが、機能を作ることが目的となってしまって気がつくとその価値が提供できていないのではないだろうか?ということだろうか。

そう考えると確かに、そしてまさに、アジャイルではないか

ソフトウェア開発ではプログラミングによって機能を作り込んでいく。ただ、出来上がったアプリケーションがその機能によってなんの価値を提供しているのかに立ち返って、常に検証し続ける必要がある。
そして、アジャイルの文脈ではその検証を繰り返してスプリントを回していく。

どうも、ウォーターフォールが染み付いてしまい、当初作った仕様に従った機能のテストしかできていないように感じてしまった。

改めて、このあたりに関しては気を引き締めていかないといけないと感じた。

Docker で GPUを使いたい

少し前から OpenAI が提供している whisper を触っています

業務でお客さんとMTGをする機会が最近増えてきて、会話をしていると会話に集中してしまって、メモを取り忘れてしまうんですよね。
端々ではメモをとっても、やっぱり抜けてしまう事はあったり、話を聞いていて

「お、それはこういうことかな?」

って考えている間に話が進んでしまっていたり。。。
ということで、できるだけ録音をするようにしています。

どうせなら文字起こしを手軽に行いたいというのがモチベーションとなります。
将来的には要約まで自動的にやってくれるとよくて、それはもう現実的なレベルまで世の中は来ているわけですが。

Dockerfile

参考にさせてもらったのはこちら

Dockerを使ってOpenAIのWhisperをサクッと試す
https://zenn.dev/kento1109/articles/d7d8f512802935

FROM pytorch/pytorch:1.9.0-cuda10.2-cudnn7-runtime

WORKDIR /workspace

RUN apt-get update && apt-get install -y \
    build-essential \
    gcc \
    git \
    ffmpeg \
    && rm -rf /var/lib/apt/lists/*

RUN pip install --upgrade pip

RUN pip install git+https://github.com/openai/whisper.git 

試してみるとエラーになった

root@dfbc095388f8:/workspace# whisper mtg02.m4a --language ja --model large
Traceback (most recent call last):
  File "/opt/conda/bin/whisper", line 5, in <module>
    from whisper.transcribe import cli
  File "/opt/conda/lib/python3.7/site-packages/whisper/__init__.py", line 12, in <module>
    from .decoding import DecodingOptions, DecodingResult, decode, detect_language
  File "/opt/conda/lib/python3.7/site-packages/whisper/decoding.py", line 514
    if prefix := self.options.prefix:
               ^
SyntaxError: invalid syntax

cudaのバージョン問題

参考にさせていただいたページにもあるように、pytorch をPCにあった cuda バージョンにする必要があります。

cudaバージョンの確認方法は、コマンドプロンプトで

>nvcc -V
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2022 NVIDIA Corporation
Built on Wed_Jun__8_16:59:34_Pacific_Daylight_Time_2022
Cuda compilation tools, release 11.7, V11.7.99
Build cuda_11.7.r11.7/compiler.31442593_0

という形で表示されます。

ところが、イメージには11.7用のものが見当たらないんですよね

pytorch/pytorch
https://hub.docker.com/r/pytorch/pytorch/tags?page=1&name=11.

最新は11.6のようなので、こちらを使用してみる

FROM pytorch/pytorch:1.13.1-cuda11.6-cudnn8-runtime

modelのダウンロードエラー?

実行してみると。。。

root@401ac01bcb2c:/workspace# whisper mtg03.m4a --language ja --model large
  0%|▏                                    | 12.3M/2.87G [00:02<11:43, 4.37MiB/s]
Traceback (most recent call last):
  File "/opt/conda/bin/whisper", line 8, in <module>
    sys.exit(cli())
  File "/opt/conda/lib/python3.10/site-packages/whisper/transcribe.py", line 310, in cli
    model = load_model(model_name, device=device, download_root=model_dir)
  File "/opt/conda/lib/python3.10/site-packages/whisper/__init__.py", line 108, in load_model
    checkpoint_file = _download(_MODELS[name], download_root, in_memory)
  File "/opt/conda/lib/python3.10/site-packages/whisper/__init__.py", line 62, in _download
    raise RuntimeError("Model has been downloaded but the SHA256 checksum does not not match. Please retry loading the model.")
RuntimeError: Model has been downloaded but the SHA256 checksum does not not match. Please retry loading the model.

ん、Modelのダウンロードに失敗した?
リトライしろってあるのでもう一度やってみる

root@401ac01bcb2c:/workspace# whisper mtg03.m4a --language ja --model large
/opt/conda/lib/python3.10/site-packages/whisper/__init__.py:48: UserWarning: /root/.cache/whisper/large-v2.pt exists, but the SHA256 checksum does not match; re-downloading the file
  warnings.warn(f"{download_target} exists, but the SHA256 checksum does not match; re-downloading the file")
 23%|████████▌                             | 667M/2.87G [01:34<05:55, 6.71MiB/s]

先に進んだので大丈夫じゃーん!って思っていたら、ここから進まなくなった。。。

今日はここまでにしよう。。。

Goerli Testnet ETH Claim キャンペーン

buildspace もようやく、 React のフロントエンドから Goerli Testnet にDeployしたスマコンに接続するところまで終了

途中、どうしてもうまくいかないな?と時間がかかる場所があったのですが、チュートリアルとしてその時点ではうまくいかない状態というオチでした。

時々ある罠ですが、ちょっと困るものです。。。

Goerli Testnet への Deploy は、以前にも誰ジェネでやってます。

誰でもできる!ジェネラティブNFT開発
https://crypto-code.jp/materials/create-generative-nft

ただ、その時もテスト用のEthが足りなくて、そもそもDeployできないという事態になったんですよね。結果としてその時は諦めてしまった過去があります。

そんな中、こんなTweetが!
過去に Mainnet / Goerli / Sepolia で Deploy したことがある人に 10 Goerli ETHをくれるという!

両手を上げて行ってみましたが、、、、 2022/11/15 時点でDeployしている必要があるとのこと。
そして、私がGoerliで試していたのが 11/16 。。。

うがあああああああああ

という訳で、見事に対象外でもらうことができませんでした。。。
これは、ちょっとせつなすぎる。。。

いつものことといえばいつものことですが、本当に間が悪い。。。

どうにかならないものか。
どこかにお祓いに行ったほうが良いのかもしれません

SoftwareDesigne 2月号

定期購読しているSoftware Designe の2月号が届きました!
今月号はDDD!!!!

見てみると、増田さんが執筆されているじゃありませんか。

ずいぶんと前ですが、DevLove で増田さんが登壇されていた回に見に行ったんですよね。
確か恵比寿だったかな・・・?

もちろん、原点ともいうべきエヴァンス本も持ってはいるのですが、いずれのDDD本も結局最後まで読めていないという体たらくな現状が今の私を作り上げている!!

と、非常に残念な状態ではあるんですが、ちょうどこれから新しい案件で、このあたりの整理をしていかないと行けないんじゃないかな?と思うような事案が勃発。

Software Designe編集部はすべてを見越しているはず!!という訳で、今年はDDDをしっかりと学んで実践で使っていくことができるように頑張ってみたいと思います。

増田さんの本、ちゃんと読まないとですね。。。

Fletが面白そう

Pythonだけでクロスプラットフォームなアプリを作れるFletについて
https://qiita.com/NasuPanda/items/48849d7f925784d6b6a0

Qiitaからのニュースレターで紹介されていた上記記事、面白かった。

FletはFlutterをベースとしているそうなので、その点も気になるところです。

The fastest way to build Flutter apps in Python
https://flet.dev/

UIの作り方や指定の仕方が今っぽくない形をしているけど、これがサクッとプロトタイプ的に使えるのであれば面白いかな。

ということで、ちょっとどこかで触ってみたいと思っています。

Build an Ethereum dApp Section 1 clear

buildspaceを引き続きやっています。
夜の時間をちょこちょことなので、進みが遅いですね。。。

hardhatを使った、ローカルでのスマートコントラクトの作成を追えて、フロントエンド開発としてReactを触り始めています。

Section2では、Replit というWeb IDEサービスを使って、フロントエンド開発を行っていくようです

Replit
https://replit.com/

最近、こういうブラウザベースのIDE。そしてそのままDeployまでできてしまうツールが増えてきていますよね。
なんかメニューを見ていたらこんなものも。。。

Ghostwriter・・・?
AIとのペアプロ??

Meet Ghostwriter, your partner in code.
https://replit.com/site/ghostwriter

なんか面白そうですね。。。

色々なプロジェクトのチュートリアルをやっていると、その時の最新手法やツールなどを触ることができて面白いです。
実際の業務でこれらが使えるか?と言うと、なかなか悩ましいものがありますが、ちょっとしたお試しでやる分には十分そう。

問題はそのちょっとしたお試しと、それ以降の切り分けなのかな?
でも、それ以降に発展するところまで行ってから考えろって感じですね

buildspace で早速躓いていた

色々と考えた結果、もう少しちゃんとdAppsを勉強していこうとbuildspaceの「Build an Ethereum dApp」をやり始めています

buildspace
https://buildspace.so/p/build-solidity-web3-app

そしてやり始めた矢先、一番最初のhardhat test が何故かエラーになる始末。。。

c:\Dev\buildspace\ethreum-dapp\my-wave-portal>npx hardhat test
npm WARN config global `--global`, `--local` are deprecated. Use `--location=global` instead.
Compiled 1 Solidity file successfully


  Lock
    Deployment
      1) Should set the right unlockTime
      √ Should set the right owner
      2) Should receive and store the funds to lock
      3) Should fail if the unlockTime is not in the future
    Withdrawals
      Validations
        4) Should revert with the right error if called too soon
        5) Should revert with the right error if called from another account
        6) Shouldn't fail if the unlockTime has arrived and the owner calls it
      Events
        7) Should emit an event on withdrawals
      Transfers
        8) Should transfer the funds to the owner


  1 passing (2s)
  8 failing

  1) Lock
       Deployment
         Should set the right unlockTime:
     AssertionError: expected BigNumber { value: "1705326131" } to equal 1705326131
      at Context.<anonymous> (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\test\Lock.js:32:42)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)
      at runNextTicks (node:internal/process/task_queues:65:3)
      at listOnTimeout (node:internal/timers:528:9)
      at processTimers (node:internal/timers:502:7)

  2) Lock
       Deployment
         Should receive and store the funds to lock:
     AssertionError: expected BigNumber { value: "1000000000" } to equal 1000000000
      at Context.<anonymous> (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\test\Lock.js:46:65)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)
      at runNextTicks (node:internal/process/task_queues:65:3)
      at listOnTimeout (node:internal/timers:528:9)
      at processTimers (node:internal/timers:502:7)

  3) Lock
       Deployment
         Should fail if the unlockTime is not in the future:
     Error: Invalid Chai property: revertedWith
      at Object.proxyGetter [as get] (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\node_modules\chai\lib\chai\utils\proxify.js:78:17)
      at Context.<anonymous> (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\test\Lock.js:55:64)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

  4) Lock
       Withdrawals
         Validations
           Should revert with the right error if called too soon:
     Error: Invalid Chai property: revertedWith
      at Object.proxyGetter [as get] (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\node_modules\chai\lib\chai\utils\proxify.js:78:17)
      at Context.<anonymous> (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\test\Lock.js:66:44)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

  5) Lock
       Withdrawals
         Validations
           Should revert with the right error if called from another account:
     Error: Invalid Chai property: revertedWith
      at Object.proxyGetter [as get] (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\node_modules\chai\lib\chai\utils\proxify.js:78:17)
      at Context.<anonymous> (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\test\Lock.js:80:66)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

  6) Lock
       Withdrawals
         Validations
           Shouldn't fail if the unlockTime has arrived and the owner calls it:
     Error: Invalid Chai property: reverted
      at Object.proxyGetter [as get] (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\node_modules\chai\lib\chai\utils\proxify.js:78:17)
      at Context.<anonymous> (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\test\Lock.js:93:48)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

  7) Lock
       Withdrawals
         Events
           Should emit an event on withdrawals:
     Error: Invalid Chai property: emit. Did you mean "exist"?
      at Object.proxyGetter [as get] (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\node_modules\chai\lib\chai\utils\proxify.js:75:17)
      at Context.<anonymous> (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\test\Lock.js:106:14)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

  8) Lock
       Withdrawals
         Transfers
           Should transfer the funds to the owner:
     Error: Invalid Chai property: changeEtherBalances
      at Object.proxyGetter [as get] (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\node_modules\chai\lib\chai\utils\proxify.js:78:17)
      at Context.<anonymous> (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\test\Lock.js:119:41)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

いや、まだロクに何もしていないのでこんなところでエラーが出るはずもないと思っているんだけど。。。という領域。

なんか、最近こういう、チュートリアルがそのまま動かずにやる気なくすというパターンが続くような気がする。
ただ、Discord見ているとできている人もいるので、なんだろう?
環境要因??

Powershellで試してみた

うーん、なんでだろう??と思って、ダメ元でPowershellでやってみたら。。。

PS C:\dev\buildspace\ethreum-dapp\my-wave-portal> npx hardhat test
npm WARN config global `--global`, `--local` are deprecated. Use `--location=global` instead.


  Lock
    Deployment
      √ Should set the right unlockTime (1301ms)
      √ Should set the right owner
      √ Should receive and store the funds to lock
      √ Should fail if the unlockTime is not in the future
    Withdrawals
      Validations
        √ Should revert with the right error if called too soon (66ms)
        √ Should revert with the right error if called from another account
        √ Shouldn't fail if the unlockTime has arrived and the owner calls it
      Events
        √ Should emit an event on withdrawals
      Transfers
        √ Should transfer the funds to the owner


  9 passing (2s)

いや、おかしいだろ。

なんで コマンドプロンプトとPowershellで結果が違うんだよ。。。

かなりこれで時間つぶしてしまったぞ。。。畜生

良いコード悪いコードで学ぶ設計入門(1)

このところ、本を読むスピードがめっきり落ちてしまっていて、まだ俗に言う”ミノ駆動本”を読み終えておりませぬ。

読み終えていませんが、多くの学びを得られると共に、結構モヤモヤと思うところが多いです。

私自身、プログラマーとしては正直底まで力量は無いものの、これまで携わってきたコードの中で利用されてきた考え方というものが”悪”と言われてしまうことに、抵抗があるんでしょうね。

コーディングの考え方、パラダイムの変化はやはりあるもので、常に問題を抱えている現場からすると、過去のコードというものはやはり問題を抱えていたのであろうし、現時点でも問題を抱えていればやはり見直しをかけていくものだと思います。

特に、オブジェクト指向の説明で用いられる継承に関しては、正直「おっ?」と思わずにはいられませんでした。

それぞれの現場にはそれぞれの前提があります。
ずっと同一プロダクトに携わっている人からしてみたら、「このプロジェクトのメンバーならそんなの知って当たりまえだよね」って事をできるだけ下げる。
新規参画者をできるだけ増やす。ハードルを下げるという意味において、高凝集にする意味。。。というよりは低凝集を避ける意味が出てくるんだろう。

言語側の機能が拡張されていくに連れ、その時代にあった書き方や問題の解決方法が出てくるというのは本来面白いものであるはずなのだが、心の弱い私には”悪”とか”クソコード”という強い言葉に抵抗を感じてしまうんでしょう。

もっと強くならないといけないな、なんて思いながら読んでいます。

あとちょっとだけど、もやっとするので時間かかる。。。

passkeyに関しての整理

先日、Chroniumチームが passkey に関してのアナウンスを出しました

Introducing passkeys in Chrome

Appleはと言うと、昨年のうちにpasskeyに対しての対応を表明しており、この分野に関して大きく進展し始める機運が出てきました。

ちょうど、来年からID管理周りのシステムにかかわる可能性が出てきたこともあって、自分の知識の整理も兼ねてまとめておこうと。

ID/パスワードが抱える問題

ID/パスワードが抱える問題を考える上で、そもそものID/パスワードに対する考え方と、同システムとして実装するのかの2つを考える必要があります。

ID/パスワードをすることで何を実現するのか?と言うと、ログインしようとしている人間がIDの所有者。つまり本人であることの認証のためです。

この認証するための技術として今主流なのは多要素認証という手法で、これは下記の要素のうち2つ以上の異なる認証要素を用いて認証する方法となります

  • 知識情報:パスワード、秘密の質問
  • 所持情報:セキュリティーキー、キーデバイス、Authenticator
  • 生体情報:指紋情報、顔、虹彩、静脈など

Googleなどが提供するAuthenticatorによるワンタイムパスワードであれば所持になるものの、メールなどで届く場合は、メールの情報を知識として持っているということで知識になるのか?など、ちょっと気になるところはありますが、これらの組み合わせでセキュリティを担保していることになります。

ここで所持情報にあるようなデバイス。つまりはスマホのようなものを考えた場合、スマホのアンロックに生体情報を用いれば、その状態は所持情報と生体情報を兼ね備えた状態と言えます。

passkeyはこの仕組を利用して、認証されたデバイスによる生体情報認証を行うことで、一つの操作で多要素認証を実現するものです

passkey による認証

パスキーの認証の流れとしては下記の図のような形となる

まず最初にパスキーの登録行為。生成行為が開始されると、ローカルでの生体認証などを利用した情報を元に公開鍵ペアが作成される。

秘密鍵はデバイス側で管理され、サーバー側に公開鍵を送る形。

パスキーを使ったログイン時には、まずローカルで生体認証などを用いた認証が走り、それを経て秘密鍵を用いた署名を生成。サーバー側で検証され認証される。

このパスキーは、サイト毎に作成されるため、フィッシングサイトのように異なるサイトでは本物のサイトで利用していた認証情報が使われることがない。
つまりは、仕組みとしてフィッシングを防止することができる

また、生体情報を用いた認証はデバイスのローカルで行われるため、指紋情報などの生体情報がネットワークに流れることがない。

課題

この仕組の課題は、デバイスに過度に依存してしまう点にある。

認証を行った情報がローカルに保存されることになるので、例えばそれらデバイスが物理的に壊れてしまったりすると、対象のサイトに対してログインができなくなってしまう。

その点の解決策としては、デバイス間でパスキーを同期させるという案になるのだが、それって結局のところ認証情報をコピーしているわけなので若干モヤっとする。

モヤっとするのだが、現実問題としてスマホを落としたり水没させてしまったりと、割りとそういう自体は起こりうるもので、それに対しての対応も考えて置かなければならないのも事実。
妥当なところなんだろう。

現状の実装としては、AppleはApple。GoogleはGoogleデバイス間での同期にとどまってしまう点も使いづらさを感じる点になると思う。

PCでパスキーを使用する際に、パスキーの認証方式として認証済みデバイスに対してQRコードを読み込ませるという方法も用意されているが、面倒臭さは拭えない。

実装

OSS の passkey 実装としては hanko がある

https://www.hanko.io/

まさかのハンコである。
手軽にローカルで実装を確認できるサンプルもあるので動かしてみる。Githubはこちら

https://github.com/teamhanko/hanko

ReadMeに動かし方が書いてあるが、コマンド一発で起動することができる

docker-compose -f deploy/docker-compose/quickstart.yaml -p "hanko-quickstart" up --build

localhostの8888ポートへアクセスするとExample Appのログイン画面へ行く事ができる

テストサイトなので、メールアドレスは何でもいい。

Sign Upを押すと、メールに飛んできたパスコードの入力画面に行く

メールは実際に入力したアドレスに飛ぶのではなく、このExampleに組み込まれたメールサーバーへ届けられる
http://localhost:8080 へアクセスする

入力すると、パスキーをセットアップするかを確認する

ここでパスキーをセットアップすることでログイン時に用いることができるようになる。。。。はず。

というのも、私のPCでは正常に顔認証が行われないのでこの部分は試すことができなかった。

実際のところ、hankoはまだ開発中でベータという扱いで、現在のバージョンはv0.3.1。順調に月1くらいのペースでリリースがされているので今後の動向には注意しておきたい。