Skip to main content

Posts

Showing posts from April, 2020

Reading: Design it! - アーキテクチャー設計にかけて良い時間

Designing software architecture requires us to think about problems and solutions simultaneously. 同時に考える。問題への理解が深まれば解決策を見つけやすくなるし、解決策への理解が深まれば何が問題のなのかがわかりやすくなる In this case, spending less than about 20 percent of the original project schedule on architecture has a diminishing return. 20%までを参考にアーキテクチャーを検討する時間に当てると投資対効果がありそう(reworkにかかる作業工数の低減効果が得られる もしこれが起きたら、と仮定することではいいアーキテクチャーはできない。 現状どうで、それは何を引き起こしうるのかを書く <Condition>; might <Consequence>.

pipenvを使う

2019年頃から、Pythonの開発環境としてpipenvが良いなんて話を耳にしていた。 ようやく近頃使う機会があって、確かに使い勝手もよかったので、簡単にまとめておく。 まず、これまでのPythonの環境だと、単純に依存しているモジュールをpipのfreezeコマンドで出力してrequirements.txtに書くやり方にするといくつか問題があった。 ・環境を仮想化しないとその端末に入っている全てのライブラリを使用しているライブラリとして書き出してしまうな上、仮想化のやり方が色々とあって面倒 ・直接依存しているものと、間接的に依存しているもの(依存しているものが依存しているもの)との区別がつかない ・requirements.txtを慎重に書かないと間接的な依存先のバージョンが変わったことでライブラリが壊れてしまうなどのトラブルや、インストールしたタイミングによってバージョンが異なってしまうことがある pipenvでは ・プロジェクトごとに環境を仮想化すること ・直接の依存と間接的な依存をがわけて管理されるようになった ・バージョンをロックする機構ができた ってことでこのあたりのトラブルがかなり解消された。 現行は、セットアップの面倒さに目を瞑れば、JavaScript系の開発と同様の勝手になり、相当スムースになったと個人的には思う。 (JS開発系におけるpackage.json = Pipfile, yarn.lock = Pipfile.lock) しんどかった点ので対応に苦慮した点を3つほど記しておく。 事前ライブラリインストール pipenvの中で使うpyenvを適切に準備するために、事前に次のコマンドでライブラリをインストールしていないと、一見セットアップがうまくいくのに動かない、といったトラブルに出会すことになる。(Ubuntu環境前提の話) そして、この必要なライブラリについて公式ドキュメントでは触れられていないように見える。(見落としかもしれないけれどね) sudo apt update sudo apt install python3 .7-distutils sudo apt install zlib1g-dev sudo apt install libssl-dev libbz2-dev libreadline

Reading: Design it! - アーキテクチャー設計時の基本思想

アーキテクチャーの設計時の Principle として、次の 4 つが挙げられていた。 (HART Principles) 1. Human rule.  All design is social in nature.   2. Ambiguity rule.  Preserve ambiguity.   3. Redesign rule.  All design is redesign.   4. Tangibility rule.  Make ideas tangible to facilitate communication. それぞれをまとめて雑にいえば、こんな感じ。 ・人間が使う、人間が理解できるものにする ・全て緻密、精密なものにせず、曖昧さを許容する ・毎回一から設計しようとせず、過去のデザインを参照する ・アイデアを触れるものにする ( ドキュメントでもコードでもプロトタイプでも ) その上で次の 4 つのマインドセットを使い分けると良いらしい。 ・ Understand:  いわゆる要求定義と言うか、各ステークホルダーが持つ問題やビジネスゴールを理解することと言うイメージに近そう ・ Explorer:  アーキテクチャー上の決定をする上でのとりうる選択肢の調査や検討、要求の仕様化がイメージとしては近そう ・ Make:  全体をモデル化してみることやプロトタイプを作ることなど、コンセプトを何らかの形にするようなマインドセット ・ Evaluate: V 字モデルでいうところの右側というか、できたものが要求を満たしているかを確認するようなマインドセット

IBMのCloudPak for Applicationの更新

CP4A v4.1.0 での新しくなった点 What's new in IBM Cloud Pak for Applications  https://www.ibm.com/support/knowledgecenter/ja/SSCSJL_4.1.x/about-whats-new.html ・ OCP 対応バージョンは 4.3 ・ Kabanero Enterprise は Accelerators for Teams に名称変更 ・ stack hub に java-openlibrary が追加され nodejs-loopback が除かれた ・ Accelerators for Teams は Tekton Triggers と統合された Kabanero、もう名称変更になったんだ......個人的に追っていたので、この名称、流行らなかったのかな、とか思ってしまう。確かにわかりにくい名前だった。