aseprite で複数アニメをタグ付け管理

 asepriteを買ってグラフィッカに頼んでデータを作ってもらったが

使ってないレイヤーがあったり、無駄にフレームの溜めがあったり、

線画と塗りでレイヤー分けられていたり、タグ付けしないでアニメが別ファイルに分かれていたので、タグ付けしてひとまとめにして画像とJSONを出してみた

オプションはよくわからないけど、ここまで出来ればあとは如何様にもなる

ドット絵エディタのいいやつ見つけた

 https://www.aseprite.org/

ゆっくり動画やStableDifusionなどの動画例を見ていて思ったのだけど・・・
StableDifusionはちょっちやりすぎな感じがしてて、なんかマニアックすぎる
ゆっくりは素材サイトを見に行ったら、こちらも狂気的なノリで作られていて、、、

「え、これ昔流行った着せ替えソフト的なノリでつくられてんのね？ここまでカスタマイズするって必要？？」

とか思って、なんか乗り気になれない

元ゲームソフト屋としては、素材があれば動かせる
ゲームではドット絵、アニメーション、キャラの詰め合わせ（テクスチャアトラス）を作るところまでがグラフィッカーさんのお仕事

それをするためにグラフィッカは以下の様なツールセットを使っていた

１．ドット絵エディタ
　　限られたカラーでドット絵を作成する
２．アニメーションエディタ
　　ドット絵の組み合わせでアニメーションのタイミングを作る
３．パッキングアンパッキングツール
　　ドット絵をさらに細かく、
　　i8x8ドットや16x16ドット単位で切り出し
　　それをマッピングして
　　元のキャラを表現するマップファイルを作り出す
　　アンパッキングはその逆

今そういうツールが無いのかなぁと探してみたらあった！

しかも、これ、Gnome GTKで作られてんのか？
MacでもLinuxでもWinでも動く

こいつがあれば、昔の８ビット機時代のノリで
ファミコン版FFみたいに、
キャラクターに演技させることもできる

別に口パクしなくてもヒョコヒョコしてりゃいい
もちろん解像度上げて、もうちっと豪華にしてもいいだろう

JavaScriptを読み込んで、Canvasに絵を描く

ということで

JavaScriptを読み込んで

Canvasに絵を描く例

 

男と女の趣味

バイク分解して、エンジンバラして、車体塗り直して、キャブ掃除して、組み立てて、陸運持って行ってバイク登録して乗ったり

ラジコン、自作コンピュータ、電子回路、、、

わたしのやってきた事って、だいたい男の趣味って感じ

でも、これらは男の趣味と言うわけでもないと思うんだよなぁ

ガンプラ塗るのが上手い女子とかYouTubeにいたな、、、

でも少数派だよね

ここからが本筋なのだけど

プログラムをする女子はあまり居ない

これは、なんでかと女子に聞いたところ

女子はやることが沢山あって

エステ行ったりヘアサロン行ったり化粧品買ったりお金が無いし、勉強にお金も時間もかけられないとのこと

できない言い訳のオンパレードのように聞こえるが

お金が無いとあらゆることに余裕が生まれないのは事実だ

女子はお金がかかるのに男子より給与が安いという会社が多い

困ったもんだ

外部のJavaScriptを読み込んで実行する

ちとBootStrap5を勉強しながら

あれこれ試していたところなんだけど・・・

これは、それとは全然関係のない話

外部のJavaScriptを読んで、

そのJavaScriptを実行

読み込んだ側のHTML中にあるDIV領域に対して、

テキストを書き込むこともできた

やれるのは分かっていた

だって３０年くらい前にPerlで同じことやってたから

プログラマは10000％経験だ

つまり・・・

DIV領域ではなくCanvasに 画像貼り付ければ、

ノベルゲームくらいならJavaScriptで作れちゃうってことだ

つまり・・・

吉里吉里とかティラノとか要らんてことだ・・・

つまり・・・

ゆっくり動画くらい

簡単なJavaScriptで作れちゃうんじゃなかろうか？

困った・・・

まぢやればできそうだ

そんで、それを画面録画すれば動画になっちゃうじゃないか

ゲームエンジンを本体側に実装して

データファイルを読み込むようにすれば

ノベルゲームが動かせる

ゲームエンジン次第で

シューティングだろうがアクションだろうが作れる

わたしがSEGAの iPadゲームを作っていた時は、半日で作った自前のゲームエンジンで、カードゲームやクイズゲーム、すごろくなどを実装できていた

プログラマは理系でも文系でもない

要件定義から仕様書作成してコーディングまで持っていくまでには論理的思考が必要

ここまでは文系の文章問題ですが

残念ながら文系だからと言って論理的思考や文章の読解力がある訳ではありません

数学しか知らない数学者はまともなプログラムを作れません

微積や行列演算は理解していてもそれをどうプログラムするかは分からないからです

したがってプラグラマは文系でも理系でもありません

読解力があり、論理的思考ができる事

そして超大事なのは何にでも好奇心を持つ事

そう言う人材がプログラマに向いてます

追記

論理的思考をするにも

要件から実装を考えるにも

文章問題です

だからプログラマは文系の方が向いていると考えるのは合ってますが

残念ながら文系だから語学力があり、文章問題を解ける訳ではないということです

数学しか知らない数学者はまともなプログラムを作れません

数学で言うところの微分や積分、行列演算などは理解しているけれど、それをどうプログラムすれば良いのかは分からないと言うことです

高水準とか低水準と言う言い回しに起因した誤解が本当にあるようだ

アセンブラは超低水準言語と言われるが

何が低いかと言うと人の言葉と違うかららしい

これを聞くと普通の人は、あぁ、ロクでも無い言語なんだねと思うらしい

だけど、プログラマからすると

簡単な言語だからこそ、何をどうすれば開発できるのかわからない言語なわけで、習得するのはかなり難解なものなのだ

つまり、アセンブラは高難易度言語である

これに付随して、上流工程、下流工程と言う言い方があり、さらにV字開発という図がある

わたしは常々、これを考えた奴は、IT業界に入って何も出来ないけど自らの地位を高位に保ちたがった文系野郎だと思っている

そもそもわたしの周りのプログラマは誰も自分たちのやっていることが低級だとは考えていない

なのに、それが下流工程と言われるのだ

ウォーターフォールと言う

以前にも書いたがただの虚構開発工程で言うと、

要件定義から基本設計、詳細設計、コーディングと下流工程に移っていくわけだが、

たかだか要件定義如きしかまとめられない連中が、あたかも上流貴族のような扱いになってるのは何故だ？

絵に描いた餅しか作れない脳足りんどもが、

コーディングと言う超高級レベルの仕事をあたかも下級職のように扱いやがって

V字の図を見ろ

コーディングが一番下なのはなんでだ？

山の頂点にコーディングをかけ！

そしてΛ modelとでも呼べ！

この世で最強なのは話せるプログラマである

文系の要件定義しかやらない人種はITに入ってくるな！

お前らにはIT業界で人権なんざねぇ！

さて、吠えた後で論理的に否定してやろう

V字の横軸は時間だろう

縦軸はなんだ？

山に登る前から上流工程が左上に居るのは何故だ？

生まれながらに上流貴族って事ですか？

ちゃんと麓から山登れよ？

したがって、わたしが提唱する縦軸は難易度だ

一番難易度が低い要件定義から

一番難易度の高いコーディングに行き

テスト工程、実働管理へと難易度が下がっていく

だからわたしはΛ字開発と呼べと提唱する！

V字開発の提唱者に告ぐ！

図を書くなら縦軸と横軸の単位くらい考えろ？

どこまで言ってもいいのか

わたしは土日も何やら勉強している

電車の行き帰りでも勉強し続けている

わたしは頭が悪いことを知っている

だから勉強し続けるし

それを楽しんでいる

で、、、

これを他人に強制したらいけないらしい

だけど、、、

お前らいつ勉強すんの？

時間がない

忙しい

気力が続かない

すみません、、、

それってただの言い訳じゃん？

多くの人が脱落していくのを見てきました

自分の限界を決め

勉強しない

ここまでしかできないと言う

その言語知りませんと言う

出来る人を羨む

機会はあったのにやらなかったと過去形にする

あと、、、遊ぶ？

わたしは「遊び？」が理解できない

人の遊び方がよくわからない

わたしにとって

遊びとはプログラムを組んだり

電子回路を組んだりする事だ

必要なら本も読むしネットで調べる

人の絵が上手いと思えば真似をする

上手いアニメーターがいたら

コマ送りで確認する

簡単にパラパラアニメも作ってみたりする

音楽も耳コピする

自分で弾いてみる

これがわたしの遊びだ

楽しくて仕方ない

映画を見に行ったとしよう

わたしは常に作る側視点だ

シーンチェンジのタイミング

オーバーラップ、フェードなどの秒数

演出

効果音

頭の中で絵コンテを切り直してる

アニメならパース線を補完して

溜めと動きのバランスを見ている

音楽鑑賞でも同じような感じだ

コミケでも

ただ買いに行くことはほぼ無い

売り手になることの方が多かった

言い換えると、、、

入力があればそれを

常にデバックしてる感じと言えばいいだろうか？

わたしが極端なのは理解できるので

しかし、わたしは常にこう生きてきた

しかし、それを他人には強制できない

人の生き方に口を出すことはできない

でも、本音を言えば

やれよ？

マルチツールが嫌い

ナイフやハサミやノコギリなどがセットになった類のマルチツールというものが嫌いだ

十特ナイフも嫌い

スイスアーミーも嫌い

専用の工具の方が良いし

数種類専用の道具を持っていても

そこまでかさばるものではない

なんかつまらねー計算問題を出すサイトがあるので

なんかつまらねー計算問題を出すサイトがあるので

わたしも一例出してみる

一瞬で答え出せる問題

12345679 x 9 = 

12345679 x 18 =

12345679 x 27 =

12345679 x 36 = 

12345679 x 45 =

12345679 x 54 =

12345679 x 63 =

12345679 x 72 =

12345679 x 81 =

オブジェクト指向が業務に必要ないのか？みたいな記事について

書いてる人も意見してる人もJavaの人だった

この時点でオブジェクト指向にどっぷり浸かってるように感じる

わたしがJavaな人によく言うのはJava以外やってみな？と言うこと

だが、わたしは知っている

一生懸命覚えてプロフェッショナルになった人はそれ以外の言語をなかなか習得せず

他の言語を批判する

だからJavaの人はJava最高で終わってしまう

もちろんVB.netの人もそうだし

C#の人もそうだ

下手したら、Strutsの人はSpring覚えないかもしれない

それだけ業務が忙しく、新しく勉強する時間も無く、教えてくれる人もいないのだろう

さて、ここから本題

オブジェクト思考が要るか要らないかだが

わたし的にはどっちでも良い

それよりもフレームワークの方が大事

メンテしやすいかどうかでフレームワークを選ぶべきだ

個人的見解としてJavaSpringは使いやすいと思う

フレームワークのポリシーを理解していないと

余計な実装しまくることになる

まぁ、原因は何も理解していないプロジェクトリーダーやご意見版を気取る自称スーパープログラマの横槍なのだけど

例えばフロントでシームレスにバリデーションチェックとか

せっかくバックエンドでバリデーターがあるのにそれでは遅いからフロントでやれ！とお達しが来る

理由はお客様からのお達しだ！

上から下に直通な訳だ

バックに渡す前にフロントでシームレスにバリデーションチェックやるなら、バックエンドでも同じことやるので二重チェックになる

JavaScriptからAjax呼び出ししてDBにも負担かけてやることになるわけだ

これが最悪なのはメンテ重ねるとフロントとバックの整合性が合わなくなっていったりする

Javaだけではないのだけど

フレームワークの方針というものがあるのでそれに逆らう実装は本来望ましくはない

そもそもシームレスにバリデーションチェックするという事は結構大変な事だ

ウェブアプリでなくともやるべきではないと思っている

バリデーションは要素の妥当性だけでなく、他の要素との関連チェックもある

フロントでチェックしててもバックで処理してる最中に誰かの操作した事などが起因で現在の状況が変わっててエラーでら返すことになることもある

だからJavaではコントローラで頑張るわけだ

こういうプログラムの手の入れどころを制限する事で新米プログラマの妙な実装も抑止できる

最初に書いた通り

フレームワークは必須

オブジェクト指向ついては、正直どうでも良い

オブジェクト指向と言うのは

新米プログラマでもプログラミングの考え方を定着させる点ではいい考え方だと思う

しかし、Javaはやりすぎじゃね？とも思う

asp.netくらいがちょうど良い気がする

しかし、制約が薄い分

とんでもない実装し出す奴もいる

Javaから来た人はマヂで無駄にクラス作りまくる

要らんからそれと言いたくなる

多分、オブジェクト指向が要らないと言い出す人は

この匙加減のことを言ってるのではなかろうか

DDDに毒された人と言っても良いかもしれない

Javaの人はDDD信者だからなぁ

それと、Goのマイクロサービスで実態作ってしまうとオブジェクト指向要らん！となるかも知れない

Javaの人も一度そう言う現場を見てみるべきだ

わたしはかつてGoのマイクロサービスで

データベースはXMLDBを使い

全体はMVCになっているものを作った

めちゃくちゃ開発効率が高いものが出来た

しかしXML DBも自前で作る必要があることに気がつき、脆弱性にも気がつき、言語もGoからSwiftに変更している最中だ

C、C++、Perlとの付き合いは長いが

わたしは最近の言語を一通り使った上で

Swiftでよくね？と思ったのでやりなおしている

C系はCPU依存がありすぎて

今後ARMのサーバが主流になったらヤバいことになる

あとで苦労したく無いのでRaspberryPiにSwift入れて作り始めているのだ

Web系の技術は脆弱性に関連してどんどん変わってきた

攻撃との追いかけっこでスタンダードの代替わりが激しかった

これからも変わるだろう

SpringSecurityでも2段階認証をもっと簡単に実装する方法を提供できないかと言う議論は見たことがあるし

ゼロトラストについても考えていかないとだし

アンテナ貼りまくって新しいものを学び続けるのはなかなか大変だと思うが

それがプログラマなのだと思う

RaspberryPi4 LibreElec KodiでBD

RaspberryPi4のLibreElec KodiにIOデータのBDレコーダを繋げてみた

DVDは問題なく再生できたのに

BDは再生できなかった

なんだろうと思って調べたら結構グレーゾーンな事をやらないといけないらしい？

(具体的には こちらの情報の通り)

必要なファイルはここに置いておいた

• convtabは全部Update版を上書きしてる
• KEYDBはJPN版でヘッダ部をmkv8のミニマムセットで書き換えている
• vm0はそのまま

いちいち説明するまでもないと思うが

ダウンロードしたマシンから

sshでRaspberryPiに繋いで

scpでkodiに送って

unzipで解凍してから以下の手順に従えば良い

mvで解凍したフォルダやファイルを配置するだけだ

1. JREのアドオン入れる（Blu-rayのメニューがJavaらしい）

    LibreElecのアドオンを検索して追加（ただしJava8）

2. VM0を配置（仮想マシン）

    /storage/.configure/bfplus/vm0

3. KEYDBを配置(BDPlusデコード用)

   /storage/.configure/aacs/KEYBF.cfg

4. convtabを配置(BDPlusデコード用)

  /storage/.cache/bdplus/convtab

超ドマイナーなこの北米版？のBlu-rayは再生出来た

極黒のブリュンヒルデ

外国人の声優さんも頑張ってて

実は英語の勉強になったりする

しかしながら、うる星やつらのBlu-rayは再生出来なかった

多分KEYDBが有志で更新されないとダメな感じ？

または日本版みたいなのが置いてあるから

そっち使えば良いのだろうか？

どこがグレーゾーンなのかと言うと

KEYDBはそもそもDVDFabから取得するものらしいと言うところ

よくわからないのだけどこれは

covtabとセットなんではなかろうか？

マヂこのあたりよくわからないので

もう少し調べてみるつもり

PocketCHIP

http://chip.jfpossibilities.com/docs/chip.html#using-the-chip-operating-system

やばい

本家のサイトよりもかなり詳しく使い方？

と言うか、こう言うワンチップなLinux環境の使い方について書かれている

真空管アンプ

真空管アンプはシングルかプッシュプルで

信号用の出力トランスでスピーカーへの出力をしている

ところで最近の中華な真空管アンプは

トランスが載ってないように見える

つまりは普通に半導体のアンプが入ってると思われる

そのわりに、YouTubeとか見てると重いらしい

え？トランス中に入ってんの？

ちょっとわからないんで分解してくれないか？

KORGのnutubeは一時めちゃくちゃ流行って（と言うほどでもない？）

その回路の中にはあえてトランジスタで増幅してるのもある

nutubeは一種のフィルターのような役割で入ってる感じだ

museでも使えばもっと安定するだろうが

あえてトランジスタを使ってるのが

わたし的には響いた

わたしの友達の父君は結構有名な方で

真空管アンプを作る会社をやっていた

あちこちのオーディオ雑誌からレビュー依頼が来て

コメントを書きまくっていた

その父君の形見分けで、アナログオシロを頂いた

以前偶然電車で会った時に

これから秋葉にオシロを買いに行くんだと話していた

おそらくその時に購入されたものだろう

まさか

それが自分の手元に転がり込んでくるとは思わなかったが

今も大事に使わせてもらっている

家を訪問した時にはいつもワーグナーをかけていて

セレッションのSL-7で鳴っていた

スピーカーもいただいた事があって

お下がりのSL60がうちにある

当然ちゃんと音が鳴る状態にしている

思い出話に脱線したが

真空管アンプの音は

やはりトランスも無いとなぁと感じる

真空管アンプの設計の本は読んでいて

計算方法も分かるが

わたしは知識しかなくて自分で作ってはいない

あるハードウェアエンジニアと話した時に

いい音とは？と言う話になって

楽器をやる人の言ういい音は

結局でかい音なんだそうだ

いやいや、そんな事はないだろう人によるよな？

と思ったが黙って聞いていた

だからオーディオマニアの言ういい音もでかい音で鳴らせる事を重視しているとのことだ

まぁ、わからなくもないが、、、

今の人は音の粒と言う表現をするし

解像度もあるだろう

とは言えわたしはもう高音が聞き取れない

細かい音を聞くと疲れてくるし

音の粒度が下がった程度の音の方が聞きやすい

あまり下がりすぎると気がつくけど

いい塩梅がありそうだ

PocketCHIPにluaをインストール

Luaのインストールは、普通にソースからmake installした方が良い

luaの公式サイト行って、wgetして、解凍してmake installでイケる

てか、luaのコンパイル早！

型のないプログラミング言語で最速と言われるが

コンパイルまで早いんか

PocketCHIPをbusterまでアップデート

jessie→stretch→busterまでアプデしてみた

ウインドウマネージャーはi3にした

ショートカット感覚でターミナル起動したり画面切り替えたり出来るので、こっちのが便利

docker、build-essential、emacsなどを入れ始めてる

バックスペースも効かなくなって来てるので、

そのうちスイッチ取り替えるかも

やり方はそのうちまとめるかも知れないけど

需要あるんだろうか？

ラズパイより遅いけど、熱暴走しないし

わりとこいつ気に入ってる

mako server入れて、

命令タンク（そんな用語ないけど）にしてしまうのもありだな

カセット

うちには録音機能がなくラジオの付いてるウォークマンがある

しばらく使ってなかったが、ゴムが切れていた

ゴム部品を交換して動くようにしてみた

音を聞いてみた

おいおい、いい音で鳴るじゃないか

なんなんだ、この大きさにこのギミックを入れ込んだ技術は

マヂでロストテクノロジーじゃないか

CDやMDが廃れて、カセットがまた流行り始めてるようだが

このガチャっと音が鳴るのが、アナログで楽しいのかも知れない

昔はインディーズバンドがカセットに録音してて

喫茶店などに置いてあって

いくつか貰って聞いていた事がある

今はなんでもWEBに情報があるが

才能があっても埋もれてしまう

ゲームも同じだ

面白くても埋もれてる事が多い

宣伝には物理が良い

目で見て触れる事が出来る

本も同じだなと思う

改めてアジャイルを語っておこうと思う

わたしがいたゲーム業界では

キャラクターの動き方、操作感、魔法のエフェクトなどを試し試し作って数人の関係者を呼んで確かめながら作っていた

これがアジャイルそのものだ

説明終わりだ

と言うと続かないので続きを書く事にする

この試し試しと言うのが重要で

仕様書作ってそのまま作りましょうでは無理なのだ

ゲーム業界から外資系ソフトハウスを経験し、その後業務系アプリを経験した時に、

日本の業務系はなんてクソ無駄な事やってんだ？

と感じた

仕様書通り動くなんてあるわけがない

大きなプログラムを作っていれば

どんどん共通化しようと設計の修正が入ってくる

その都度全体の作りも変えて行くべきなのだ

それなのにフローチャートの通り作れと？

フローチャートなんか、数人に書かせれば同じフローチャートにはならないのだ

要するにフローチャートなんかこんな感じ？

程度のものでしかない

そんなの口で言えばプログラマは分かる

だけど仕様書がないままプログラマが勝手に書くと

仕様書がない

テストしてないと横槍が始まる

では聞きましょう

仕様書通り作って、テストしたものの品質は高いと断定できるのか？

そんな事はない

バグだらけだろ？

何度同じことを繰り返せば気がつくのだ？

仕様書通り動いてるプログラムなんてこの世に存在しない！

わたしはやるべきテストはしている

問題点があれば報告する

共通化しなければならないなら部品も作る

これは当たり前なことなのだけど

普通のプログラマはやらない

普通のプログラマは

言われたことを言われた通りにしか実装しない

そして終わりましたと言う

そんな仕事楽しいか？

アジャイルは「機敏な」「敏捷な」と言う意味がある

一般的なクソな流れは要件定義、基本設計、詳細設計、コーディング、単体テスト、結合テストだ

プロジェクトリーダーは、線表引いて遅延確認を毎日する

こんなクソな事はアジャイルでは全部やらない！

ではどうするのか

要件をまとめる段階でプロジェクトリーダーと一緒に実際に操作の紙芝居が出来るように画面を作る

プロジェクトリーダーがこれでお客さんに見せられるなと判断したら関係者全員に確認を取る

プロジェクトリーダーが確認をとっている間に、先に進む人はデータの持ち方、テーブルのカラムなどを考え、WebAPIが必要ならダミーでもなんでも作り始める

誰からも指示なんかされなくても自分で次の仕事を探して取り組む

プロジェクトリーダーが紙芝居を終えてやって来たら今こんなの作ってんだよと見せるとともに紙芝居の結果を聞き、修正があればその場で直す

この段階でお客様の要件と実装はほぼ終わり、

しかもチーム全体が要件を理解して実装のイメージが掴めるようになっているはずだ

朝会で進捗確認するまでもなく

完全にチームは全体像を把握する事になる

したがってゴールするまでにかかる見積もりも明らかになってくる

まさにアジャイル（機敏）

そうして、直したものをリーダーがお客様にプレゼンしている間に、プログラマはデータベースのテーブルやWebAPIも大体動くようにしておく

これをやるには

プロジェクトリーダーは要件を全部把握する必要があり、それをプログラマに正確に伝え、一緒になって画面を見つめながら出来上がるまで一緒に作業しなければならない

プログラマはプロジェクトリーダーと一緒に考え、おかしなところも相談しながら仕上げていく

「この画面無駄じゃね？こっちの画面にカラム追加してリンク押せばそっちの画面に行くようにしたら一画面減らせるぞ？」

「ここの操作こうしたら、警告なんかそもそも出る状態にはならないぞ？」

そう言う話し合いをしながら作れば、妙な仕様に頭を悩ませる時間も無くなる

チーム全体が自分のやるべき事、役割を把握していないと出来ないのだ

プロジェクトリーダーが

「お客さん何言ってんのかわからないんだよ、毎回言うこと変わるんだよ」

「ここ、わたし全然詳しくないんだよ」

と言うならリーダーやめろ

やめたくないならお客様の言いたいことを必死に汲み取れ

わからない事はわかるまで勉強しろ

人に聞け

わからないまま放っておくな

ブワログラマが

「プロジェクトリーダーの言ってる事はおかしいと思う」

「あれこれ言ってくるから何を作ればいいかわからない」

「注文が多すぎる！」

「なんでわかってくれないんだろう」

と思うなら

会話をする姿勢とはなんなのか必死に考えろ

意固地になるな

他人を認めろ

画面くらいすぐさま人に見せられるようになれ

わたしはディレクションもコーディングもグラフィッカもやっていたので、チーム全体の気持ちがほぼわかる

だから、仕事は流れるように進む

プロジェクトリーダーもプログラマも、互いに意思疎通をしようと努力し。自分の役割を理解し。やれることをやる。やれない事は相談する。

こう言う事が全体で、出来ている状態を

マインドセットが出来ている状態と言う

さて、要件定義が残って居ないとお客様からあらぬ記憶を頼りにこんなの頼んでいない！と言われるので、大体プログラムが動いてきたら何度もお客さんのところに行ってしつこく確認が必要となる

そして、それをきちんと文章に残す

この段階で要件定義をまとめるべきだ

次に仕様書だが、

プログラムの中身がクソスパゲティになるのはクソ仕様書の通りに組むからであって、ポリシーを持って共通化をしたり、フレームワークを作れば結構綺麗に仕上がるはずだ

だが、残念な事にある程度プログラムを書けるようになったものには罠が潜む

クソプログラマの口にしがちなセリフを書いておこう

MSDNに書いてある！

（MSDNはあてにならない）

こことここは共通化出来る

（だからって何でもかんでも共通化して読めなくするのは間違い）←これ本当にやばいから、これしか言わないプログラマはマヂクソ

ラッパクラス作ろう！

（やめろ、特にそのまま使えばいいものをラッピングするな、log4jとかラッピングするな、礼儀を知れ）

DDDではこうだ！

（Javaの人はそれで幸せになってください、でも、それを他の言語に持ち込むな、てか、Javaの人は自分で自分の首絞めてて、コーディング量の割には碌でもないのがわからないらしい、他の言語を勉強しろ)

オブジェクト指向的にはこれが正しい！

（オブジェクト指向覚えたてだとこうなりがち、もっと簡単な方法があるならそれを選んでも良い。ちなみにGoはオブジェクト指向ではない。オブジェクト指向的に作れなくもないが、それは作者への冒涜だと思う。彼はC++が嫌いだと言うことをモチベーションにGoを作ったのだ）

デザインパターン的にはこれが正しい！

（あんなもの忘れろ、奴ら如きがギャングとかいい気になってるのがわたしは本気で気に入らない）

仕様書はUMLで書かないと！

（日本人にはUML合わない、もっとマシな絵を日本人は描けます、日本人舐めるな、読むのにテクニックが必要な段階であんな物要らん）

コメントは1行ごとに全部書け！

（勘弁してください）

さて。プログラムの仕様書だけど

ちゃんと綺麗に動くコードなら読めば分かるし、コメントがきちんとJavaDocなり、XMLスタイルで書かれてれば、DoxygrnやSandCastleで綺麗に仕様書が出てくるはずだ

だから、関数の定義や戻り値など、一生懸命Excelで書かないでいい

DoxygenにGrapvizを組み合わせて、Call Caller図を出せば、かなり役に立つ図が出来上がる

プログラムを直して、仕様書を直して、テストになってもいない無駄なテストして、品質を保証します！なんて、本気で無駄です

なんのお遊戯ですか？

最後に

大手様で特に、要件定義からの流れをやっています

それはなぜかと言うと

大手様の流れの提唱者が論文を書いているからです

でも、わたしは彼らがプログラマではないことも知っていますし、マネジメントで成功を収めた人たちではないことも知っています

つまり、全部虚構！

今すぐそのやり方をやめましょう

リチウム電池燃えた

燃えたと言うか

刃物がちょびっと刺さって燃え出した

だから燃えたと言うより燃やした

かなりの高温で、刃物の先端が溶けた

みるみる火が強くなったので

近くにあったコーヒーカスに突っ込んで消した

コーヒーカス取っておいて良かった

まぢリチウム電池はやばい

もっと激しく爆発することもあるだろう

扱うことのある方は要注意だ