2020年1月18日土曜日

スマホ版クロノトリガープレイメモ

年末年始にセールをしていので購入してプレイしてみました
感想とか攻略ネタの備忘録です

価格

2019/01/04 610 円でセール中に購入

https://linkmaker.itunes.apple.com/ja-jp/badge-lrg.svg?releaseDate=2011-12-09&kind=iossoftware&bubble=ios_apps) no-repeat;width:135px;height:40px;”>

Good

  • オート戦闘は便利 (さすがに倍速戦闘はない、またデフォルトをオート戦闘にすることもできなさそう)
  • コマンドの記憶も便利
    • レベル上げなどをタップだけで可能
  • アプリが強制キルされた場合は自動セーブで再開から開始可能
  • 装備画面やアイテム画面の操作はスマホに最適化されていると感じた
    • ただ 2 回タップで決定など実感慣れないと操作しにくい部分もあった
  • 強くてニューゲームもちゃんとある
    • エンディング終了後にセーブできるので途中でアプリを終了しないほうが良いと思われる
  • アニメーションが入る箇所がある
    • エイラの登場シーンなど

Bad

  • 倍速戦闘がほしかった (戦闘のメッセージと速度は変えられる)
    • イベントのスキップもない
    • アニメーションの Skip はある
  • ソフトウェアコントローラの操作性が微妙なところがある
    • 慣れるまでには時間がかかりそう
    • 宝箱が取りづらい、階段の登りづらい、穴に落ちてはいけないところが辛い
  • メニューで指定したキャラの技がいきなり使えない
    • マールで回復させたいのに「技」を選択してマールにしてからじゃないとオーラが使えないという感じ
    • 装備も同様で「装備」を選択してから装備させたいキャラに移動しなければいけない
  • ランドスケープでしかできないので faceID で解除する際に一度縦にしないといけない
    • またスマホを支えるための小指が痛くなる
    • また間違ってスクリーンショットを撮影してしまうことが多々あった

追加コンテンツ

SFC 版にない追加シナリオがあります
基本的には DS 版と同じようです

  • 竜の聖域
    • 1 週目から行ける追加コンテンツ
    • サブクエを進めていく感じ、クリアすると報酬がもらえる
    • 行ったり来たりを繰り返す感じので一回クリアすれば OK という感じ
    • エレメンタルガードも 1 つで十分
  • 次元のゆがみ
    • 1 度クリアしてから行ける追加コンテンツ
    • 宝箱に強力な武器があるのでそれだけ忘れないように
  • 時の闇
    • 次元のゆがみをクリアしてから行ける追加コンテンツ
    • 夢喰いを倒して終わり、夢幻を入手できる
    • 一応これがラスボス

以下夢喰いを倒したときのステータスです
ピンチになったらラストエリクサーを使っておけばまず負けないと思います

1 週目で最後まで行きましたが道中レベル上げなどしなくても勝手にこれくらいの強さにはなるようです
だいたい 20 時間前後でクリアできそうです

攻略メモ

  • かりの森ではコマンド固定にしてクロノの回転斬りをタップで連発していれば OK
    • ヌーはできれば程度で OK
  • 魔法 or 全体攻撃が有効
    • 魔法しか効かない敵や物理しか効かない敵がいるため
    • シルバー or ゴールドピアスがあればさらにサクサク進める
    • 戦闘の効率という意味では序盤に「バーサクリング」をかなり使った
    • 後半はヘイストメットでゴリゴリいける
  • 封印の宝箱を開ける順番に注意
    • 中世調べる -> 現世あける -> 中世あける
    • プレート 4 つと北の廃墟
  • 忘れちゃいけないいろじかけ
    • ドクロイ (古代) -> レインボーメット
    • ドクロイ青 (古代) -> マーメイドメット
    • プチラヴォスR (口) ヘイストメット
    • プチラヴォスR (殻) プロテクトメット
    • プチアーリマン ゴールドピアス
    • ジール (左手) プリズムドレス
    • ジール (右手) プリズムメット
  • ラヴォスは右が本体
  • 2 週目以降の目的
    • 各種カプセル回収
    • プリズムドレスとプリズムメットとにじのめがね
    • 月光の鎧
    • ヘイストメットとプロテクトメット
    • 天使のティアラ
  • おすすめ装備 (男子) 追加コンテンツクリア前
    • それぞれの最強武器+「ヘイストメット」+「ノヴァアーマー」
    • それぞれの最強武器+「プリズムメット」+「月光の鎧」
  • おすすめ装備 (男子) 追加コンテンツクリア後
    • それぞれの最強武器+「マスタークラウン」+「ロイヤルプレート」
  • おすすめ装備 (女子)
    • それぞれの最強武器+「プリズムメット」+「プリズムドレス」
  • おすすめアクセサリ
    • 「虹のメガネ」「激怒の腕輪」「ゴールドピアス」
    • あとは各キャラ専用のアクセサリー「ブレイブソウル」「英雄のバッジ」
  • レベル上げはジェノサイドドームのベルトコンベアー or 次元のゆがみ (古代) の青い敵2体
    • クロノ or 魔法のサンダガ連打で OK
    • 1200 以上ダメージを与えれば OK
    • ダメージが届かない場合は虹のメガネを装着する、ダメージが足りる場合はゴールドピアスで MP の消費を抑える
    • バリア/プロテクトボールが入手できるので金策にもなる
    • ただジェノサイドドームはロボ固定になるのでロボがレベル MAX になりそうになったら次元のゆがみを使う
    • ブリザビーストx2 は 4000 以上のダメージが出せれば一撃で倒せる
    • 虹のピアス+フレア or シャイニング辺りでないと厳しい

まとめ

神ゲーではあるのでスマホ版でもストレスなくプレイできると思います
あとはレベル 99 にしたりステータスをカプセルでカンストさせる感じかなと思います

2020年1月5日日曜日

リーダブルコード備忘録

リーダブルコードを読んだので所感などを備忘録として残しておきます
翻訳版は Kindle 用の電子書籍がないようです

最初に

サンプルコードがいろいろ出るが JavaScript や Python など比較的高級言語で記載されているので読みやすい
C++ なども一部ある
そしてそれらが実際にリファクタリングされるプロセスが記載されているのでプロセスを理解することが重要だと感じた

過去に達人プログラマーを読んだがそれと同じようなことを言及している部分は多く存在したと思う

大事そうなことメモ

  • 変数名はわかりやすく、スコープに応じて決める
  • コードだけ見てわかる場合はコメントは不要、最初はコメントを書くことを意識すると良い
  • ヨーダコード -> if 分の左辺に定数を記載して比較と代入演算子の記述バグを発見する方法
  • 気になったことをコメントに書いても OK、バグになりそうな箇所や計算量に課題がある箇所など
  • 関数名はそれを見ただけで何ができるのかわかるような名前が望ましい
  • 関数名はユーザが暗黙的に想定している命名規則を使う場合にそれに応じた計算量や値の取得ができるようにしなければならない
    • 例えば GetHoge はフィールドである hoge を返すだけの関数であったり size 関数は配列やハッシュの長さを返すだけの処理にする
    • DeleteHoge のような関数の名前で実は削除はしていないで空の値を設定するだけみたいな実装はよくない
  • 言語のコーディング規約がある場合はそれを使う、チーム内で決めても OK、とにかく一貫した書式を使うこと
  • 比較する場合は左辺に変化しずらい比較対象の値を設定し右辺にインクリメントしたりするような値を設定する
  • 否定の否定は使わない (if (!disable) 的な)
  • ド・モルガンの法則を覚えて比較式を簡単に変換できるようにしておく
  • guard 記法を積極的に使う
  • Don’t repeat yourself (DRY) の原則はリーダブルコードにも何回か出てきた
  • 汎用コード (util/) となる部分を素早く見つけすぐに切り出せるようにする
  • 長いタスクを短いタスクを列挙し関数やクラスなどに分割する
  • テストが見やすいコードは読みやすいコード
  • できる限り言語の標準パッケージを使う
  • まずはやってみる、試してみる、そしないと何も始まらない

これらを踏まえて疑問に思ったことや所感的なことを以下に記載します

golang や Swift はリーダブルコードで指摘されていることを言語レベルで吸収してくれる言語なのかもしれない

特にスタイルに関してだが、例えば「段落を使ったり複数行に分けて書く」とかは go fmt で自動でやってくれるのでコーディングしている側はそこまで気にしなくて済む
大文字小文字でスコープの範囲を指定できるのでその点も見た目だけで判断できる
ただ golang にはラベルを使った goto があり本書では goto を嫌っていたのですべてが理想な言語というわけでは当然ないと思う

Swift も同じような印象で例えば if let などは使用する変数のスコープを最小限にするための機能でそういった場合は自然に変数名が短くなると思う
Optional/Unwrap 型も見ただけで NULL の可能性が判断できる

コーディング規約などは IDE などでも統一できると思う

インデントや行間、1 行の最大文字数などは IDE を使って統一することもできると思った

IDE が嫌な場合は rubocop などのコード解析ツールを使っても良いと思う

やりすぎはダメというがやりすぎかどうかの判断が難しい

おそらく経験しかないと思う
あとは好みだろうか

テストについてもやりすぎは良くないと指摘している
個人的にはテストは嫌いなのでやりすぎるということはないと思う

リファクタリングやテストを優先してコードが増えないようにしたい

基本的にはリーダブルコードはコード量を減らすパターンが多いが状況によってはコード量が多くなるケースもあると思う
特にテストのためにリファクタリングしたりモックなどのコードが増える場合もあるので気をつけないとダメだと思う

使われていない通っていないロジックを評価する仕組みを入れておきたい

不要なコードがある場合は実装しない/削除したほうが良いと本書にもあるがそれを判断するための仕組みを入れておいたほうが良いと思う
基本的にはログで良いと思う
プロファイリングというかバグトレースなどのツールでも良いと思う

削除する基準はわからないが 1 年以上使われていないロジックなどは一生使われないイメージがある
でも初めから実装しないという手段を取れるのであればそれが一番だと思う

最終的には「好み」だと思う

変数の名前は関数の名前は特にそうだと思う
もちろん本書で指摘されているケースと全く同じケースだった場合には気付けると思うがそうでない場合がほとんどで、そういったケースはもうコーディングしている本人やレビュワーの好みに完全に左右されると思う
do-while は極力使わないという記載もあったが正直これも好みなので使っても全然良いと思う

リファクタリングやテストと同じできりがないとことだと思うのである一定のレベルでリーダブル化することやめないとダメだと思う

最後に

これを読んで実際にリーダブルなコードにリファクタリングしなければいけないケースに遭遇したときにすぐに実践できるレベルになっていなければダメだと思う
ただ、本書を読んですぐにそういう風な人になるということはなくやはり経験を積まないとダメだと思う
本書のパターンを記憶しておくのも有効な手段だとは思うがそれよりも実際の経験を積むほうが体にリーダブルなコードを書くクセがつくので良いと思う

2 回目以降に同じように読み直すのも良いがリファクタリングのサンプルコードだけを見直したり好きな章や気になる章を読み直すだけでも良いと思う

2019年12月30日月曜日

4 人で麻雀を 3 年間続けた結果

麻雀力がほぼ同じレベル 4 人で毎月一回のペースで麻雀を 3 年間続けてみました
成績をすべて記録していたのでどうなったの紹介します
また続けるため方法やコツを紹介します

背景

熱中できることを探すシリーズ第三弾かもしれません
月に一度やるということが重要かなと思い始めてみました
結局 3 年間も続いたのでせっかくだから成績を公開しようかなと思った次第です

成績結果

とりあえず成績です
試合数は三人麻雀もあるのでバラバラですが 3 年間全部で 233 回戦です

  • Y -> + 615
  • M -> +779
  • H -> -996
  • I -> -398

総合得点の月ごとの変動グラフはこちら

プレイ動画

さすがにカメラが複数台あるわけではないので毎局全員分は撮れませんが各局ごとに一人分のプレイ動画を後ろから撮影したりしています
みな素人なのであしからず

結果からわかったこと

なーんとなくですが感じたこととしては

  • 一番上と下で一番点差がついたのが 1775
  • 実力が拮抗していれば回数を重ねればそこまで大きな差は生まれなさそうと当初は思っていたけど思った以上に開いた (収束するかもしれない)
  • データ取るとおもしろい
  • ちょっとづつ上手くなっている気がする

あたりかなと思います
上がり続けているときの打ち方は続けたほうが良いとか下がっているときは打ち方を変えてみようかなといった判断にも使えました

以下感じたことなどを雑記レベルで書いていきます

人読み

よくプロの公開対局などを見ていると「人読み」という言葉をよく聞きます
始めはそんなに気にしていませんでしたがやり続けると気にするようになりました
特に同じメンバーで打っていると気にせずにはいられなくなりました

「この人はこういう待ちをよくする」とか「この順番で捨てる」とかはあるかなと思います

ただ読み筋の情報としては価値はそこまで高くないかなと思います
おまけというかあとひとつ理由がほしいときに人読みする感じかなと思います
逆に人読みが優先してしまうと個人的には押すときに押しづらくなる感じがあるのであまり優先しないようにしています

ローカルルールを決める

結構細かいところまで決めていたかなと思います
例えばローカル役満として認めていたのは「大車輪」や「大数隣」「大竹林」あとは「紅孔雀」もありにしていました (出たことありませんでしたが)
ダブル役満とかトリプル役満とかはありにしていました (出たことありませんでしたが)
通常役は基本的なルールと同じでした
チートイツとイーペーコーを絡めるというローカルルールもあるようですがなしにしていました

あとは「残りツモ番なしのリーチはあり」とか「オープンリーチあり」とか」ダブロンあり」とか、とかとか結構いろいろ決めて管理しています
困ったときはルールブックを見てルールブックにないことが起きた場合はその場で決めて新たにルールブックに記載するようにしていました

そこまでやる必要は正直ないと思いますが勝負事なので結構大事です
「え、ありでしょ?」「いや、なしでしょ?」みたいな水掛け論にはなりたくためというのもあるかなと思います

スケジューリングが一番大変

基本は月イチで打っていました
みな社会人なので月イチ程度でないとメンバー全員が予定を合わせるのが厳しかったためです

スケジュールを決めるときも少しルールを設けていて

  • 毎週金曜日 18:00 から 23:00 まで
  • もし前回これなかった人がいたらその人の日程を優先する

というルールを設けていました
あとは LINE で細かい調整をして前月中に決めていく感じです
あとで紹介しますが三人麻雀もできるメンツだったので最悪 3 人しか集まらなかった場合は三人麻雀を開催していました
そして来月は来れなかった一人を優先するという感じです

雀荘に通い続けたほうが良い

月イチで雀荘に通っていると場代だけでも結構な額になります
しかも 3 年も続けていると余裕で全自動卓なんて買えちゃうくらい払っていると思います
それでも自分は雀荘を使ったほうが良いかなと思っています
理由はいろいろあると思いますが一番なのは以下の通り

  • 雀卓の管理が面倒
  • スペースの管理が必要、雀卓以外の椅子や机
  • 誰が管理するのかという問題と管理している人のところに行って毎回やるのが不公平感を抱く
  • 別料金だがメシとか飲み物がお願いすれば出てくる

かなと思い
であれば毎回借りていただほうが管理コストがなくなるので良いかなと
あと片付けとか掃除も最低限のマナーだけ守っておけば良いので

このあたりは人によってだいぶ意見が分かれるところなので将来的に 10, 20 年続けるのであればさっさと買ってしまうというものありだと思います
自宅が広いとか部屋が余っているなんてメンバーがいればなおよしかなと思います

月イチくらいがちょうどいい

これは先程のスケジューリングの理由も影響していますが月イチくらいの頻度で打ったほうが体力的にもモチベーション的にも良いかなと思います

体力的な意味だと麻雀は結構体力を使います
自分たちは一回で 5 - 6 時間打ちますがそれでも終わった後は結構疲れます
しかも次の日を考えるとそれくらいが限界かなと思っています
よく徹マンするケースもあると思いますが集中力も切れて次の日以降への影響も大きくなるので、自分たちはもうできないかなと思います
もちろん徹マンも楽しいので全然やりたい気持ちはありますが気持ちよりも先に体にガタがくるという感じです

モチベーション的にも月イチはちょうど良いかなと思います
開催間近のワクワク感はかなり充実したものが得られるかなと思います
物足りなさを覚えてるときもありますがそこは我慢して (というかスケジューリング的にできないのですが) 翌月頑張ろうという気持ちに変えています

どうしても打ちたい場合は年末年始の長期連休や夏休みなどの長期連休を使って不定期に開催することもありますがかなり稀です

三人麻雀を覚えると続けやすい

実は打ち始めた当初三人麻雀など知りもしませんでした
スケジューリングの都合でどうしても 4 人集まらない場合が結構あり、その場合は次月に延期していました
個人的にそれの「延期」が非常に嫌で毎月続けることが大事かなと思っていました (後述)
だったら三人麻雀を覚えればいいじゃないかということでメンバーと相談してみんなで覚えて打てるようになりました
始めはかなり手探りでしたが簡単に言えば萬子の 2 から 8 がないバージョンなのですぐに覚えた気がします

ちなみに三人麻雀の点数配分や役などもルールブックにちゃんと記載しています
三人麻雀の満貫以下の子のツモはよく忘れるのでルールブックに記載するようにしています

続けることは大変であり良いことである

結局言いたいのはこれかなと思います
月イチですが 3 年間続けられた事実は素晴らしいことかなと思います
特に麻雀のような複数人で遊ぶ娯楽でそれができたのは特に良かったかなと思います

そもそも麻雀が好きなので続けられているのが一番ですがちゃんとペースを守って続けられたのは今後 10 年 20 年、もしかしたら死ぬまで続けられることができる趣味が見つかったのかもと感じています
もしかしたら急に熱が冷める可能性もあるかもしれません
そしたらまた別の趣味を同じメンバーで見つけられる気がしています、たぶん

あとは毎月の楽しみな趣味が一つあるというのも良いことだと思います
よく「次の月の xx まであと何日!」みたいな感じで日頃のモチベーションを保つ人もいるのでそういうことにも使えるかなと思います
また年間にすれば 12 回も楽しみなことが待っていると思うとそれだけで頑張れるような気になれる人もいるかもしれません

継続はなんちゃらと言いますからね

最後に

なんかエモい感じの記事なってしまいましたがみなさんも友人と熱くなれる趣味を見つけてみてはいかがでしょうか
思わぬ発見があるかも

2019年12月25日水曜日

2019 できたこと・できなかったこと

去年に引き続き今年もやりました

できたこと

時系列

資格、DIY、麻雀、ダーツと趣味に関しては満遍なく成果を上げることができた
動画に Output できたのは個人的にチャレンジャブルで Good ポイントだったと思う

その他

  • ブログ執筆数: 254 (12/23 時点)
  • Podcast エピソード数: 12
  • 資産運用を継続できた

これらは去年から引き続きがんばれたかなと思う

できなかったこと

  • Youtube Live (去年に引き続き)
  • 3D ゲーム開発 (去年に引き続き)

ライブはもうやらないかもしれない、、
3D ゲーム開発は Swift でやるか悩んでいるが Unity を使わざるを得ない気がする

来年の豊富

  • 3D プリンタの購入とおもちゃの手作り
  • モチベーションを維持する

全体的なモチベーションの低下が今年は結構感じれたので来年は現状維持で良いのでしたい

2019年12月19日木曜日

今更ながら達人プログラマーを読んだので感想

今更ながら達人プログラマーを読んだので所感を備忘録として残しておきます
読んだのは翻訳版です


はじめに

本書内ではいくつのサンプルコードが出てくるが主に C++ や Java になっている
具体的なコーディング方法などが紹介される場面もある
そういった場面では基本的に C++ や Java がベースになっているので自身で使われている言語のニュアンスと少し食い違うケースがあるかもしれない
Perl や Ruby などの高級言語もちらほらでてくるがメイン言語としては使われておらずコードジェネレートの際のパーサスクリプトなどに使われいる

また本書はある程度プログラミングの知識と経験のある人向けかなと感じた
タイトルに「今更」とつけているが今更と思うくらい後に読んでも全然大丈夫だと思う

本書内で出てくるワードがわからない場合は検索しながら読み進めると良い

特に重要だと感じたフレーズ

  • 二重化しないためのコードジェネレート
  • コード、モジュール同士の結合度を最小に抑える

印象に残った言葉、フレーズ

  • プラグマティズム、実践的な
  • 十分に幅広いバックグラウンドと経験が基盤にあってこそ、特定の状況に応じた優れた解決策を選択できる
  • 達人プログラマーの性格「新しい物好き」「研究好き」「批判的」「現実的」「何でも屋」
  • 弁解の代わりに対策を提案
  • good enough でいい、やりすぎない、やめ時を知る
  • 自分の知識に対して定期的に投資しなければならない
  • DRY (Don’t Repeat Yourself)、二重化、重複は NG
  • 片方を変更しても他方に影響を与えない場合、それらを直交していると呼ぶ
  • 曳光弾を打つ -> 常に目標やゴールを見据えながら開発する、プロトタイピングではない
  • プロトタイプの真の目的は学びにある
  • OS やデータベースのバグは少ない、まずは自分たちのアプリを疑う
  • 完璧なソフトウェアは存在しないし作れない
  • DbC (Design by Contract) 契約プログラミング、契約に従わない実装を防ぐことができる、呼び出し元/先の責任分界
  • コードの修正時、どういった影響があるのか分からないという理由で、開発者達が及び腰になってしまう
  • 偶発的プログラミング、おそらくそうであろうという環境やコンテキストを想定して開発してしまうこと
  • 要求は掘り起こすもの
  • あなたが作った 200 ページにも及ぶドキュメントを承認しているかもしれない、しかしいったん実際に稼働しているシステムを見た途端、星の数ほどの変更を要求してくる
  • テストのカバレッジを 100% にすること自体を目的にしてはいけない
  • 状態のカバレッジをテストすること

これらを踏まえて疑問に思った点や自分なりに考えた点は以下の通り

疑問点、所感

割れた窓理論について

細かいことを気にしすぎると返ってコストの問題などで大変なことになりそう
だったら 1 から作り直すなど大きな枠で変革するほうが良いのではないのかと思った
腐敗の加速のほうが速いことも可能性としてあると思う (それ以上に速く沈下できるようになれというメッセージなのかもしれないが)

あとは単純に割れた窓に気づくことができないケースがありそう

考え方はプログラマ以外にも通ずるところがあると思う

「自分の知識に投資しよう」とか「情報を伝達しよう」といった考え方はプログラマ以外にも通ずるかなと感じた
ただ伝達する際に「WISDOM を考えよう」とか「質問をするタイミングを考えよう」という教えがあったが、質問するためにそこまで考えなければいけないのであれば自分で調べたほうが早そうな気がした
そして伝達に e-mail をオススメしている感があったのでそれも、うーん、、という感じだった
たぶん重要なのは証跡を残そうということだと理解した

二重化を防ぐためのコードジェネレータ

例えばヘッダファイルを自動で生成したりクラスファイルをデータベースの構造から自動で生成するようにしようという感じ
最近だとフレームワークが頑張ってくれるケースのあるので導入は簡単な気がする
ただコードジェネレータにバグがあるという可能性を考えるとあまり頼りすぎるのも良くない気がした
この辺りは「邪悪な魔法使い」の部分でも言及されていた
要するに中身がよくわかっていないコードジェネレータは中身を理解するまでは使うなということ
また本書内ではいろいろなケースのコードジェネレータが出てくるがそれらの二重化はどうやって防いでいるのか気になった

ドキュメントドリブンに開発する際にドキュメントが変更されるとテストも必ず変更する必要があるからドキュメントを変更するとテストも自動で変更される仕組みを作るというアプローチは良いアプローチだと思った

あと二重化している箇所に気づくのは結局人によるレビューしかないのかなと思った
そういうツールも現代だとあるのだろうか
このあとで紹介してる「直行性」に関しても同じようにどう気づくのかがポイントかなと思った

というか完全に二重化していない直行しているシステムなんて作れるのだろうか
しかもそれを開発の初期段階から意識してできるのだろうか (できるようになれば達人ということだと思うが)
またコードジェネレートに関しては本書内で至るところに出てきた印象があり筆者としてもかなり推したい手法なんだと感じた (Perl)

具体的なアプローチに落とし込めるか

前述の二重化や直行性を解決するのにコードジェネレータを使ったり AOP のアプローチを使おうという紹介はある
それらを読んで実際のプロダクトに適用する際に具体的なアプローチにまで落とし込めるかがポイントかなと思った
愚直にコードジェネレータや AOP のアプローチを適用しても良いがたぶん大変なことになるので自分たちのプロダクトにあった同じようなアプローチを選択できるのかがポイントかなと思った

例えばコードジェネレータは swagger を使ったり AOP のアプローチは DI (Dependency Injection) ならできそうだなーといった具合に具体的なアプローチを自身で見つけられるかが重要かなと感じた

プロトタイピングのコードは絶対に使い捨てでなければならないのか

個人的にはプロトタイピングで使った言語やフレームワークレベルでは流用して良いと思っている
データモデルや UI の部分も全く同じなのであれば使って良い気がする
むしろ使わないと二重化のルールに抵触しそうな気がする
もしかするとプロトタイピングに関しては二重化や直行性は無視して作れということなのかもしれない
だから使い捨てなのだと

そもそもプロトタイピング=コーディングすることだと思っているのが間違いなのだと思うが

道具の使い分け

IDE だけではなくてシェルも使うと便利だよという話
頭ごなしに IDE を否定しているわけではないが IDE だけだと不便なこともある
自分も Swift を書く場合は Xcode を必ず使っているがファイルを検索するときやリポジトリに push するときはターミナルアプリを使っている
また Ruby を書くときは emacs + tmux でターミナルウィンドウ内を行ったり来たりしてコーディング、ビルドを繰り返している
要するに達人なのであれば適材適所、状況にあった最適なツールを選択すべしということなんだと思う

ただ一つ腑に落ちなかったのはエディタの拡張性の話で確かにキーバインドや face などは拡張できたほうが操作性はあがるのだけれども、その拡張がされていないと操作できなくなるリスクが伴う
なのでできる限りデフォルトの設定に慣れておきどうしてもという部分だけを拡張するようにしたほうが個人的には良いと思う

本書が emacs 推しなのはよかった

テストに関して

本書内では具体的なテストの手法などについては書かれていない
代わりに「テストがしやすいコーディングの方法」や「バグとの向きたい方」などが書かれている

テストもバグ取りの一種だと自分は理解し結局の目的は「問題を修復すること」にある

個人的にテストに関しては DHH の「TDD is dead. Long live testing」の考えが好きでシステムテストに重点を置くようにしている (参考)
本書ではユニットテストについて具体的に触れているところはないが目的である「問題を修復すること」は同じだと思う

またテストのコストやテストにおける二重化や直行性についても特に触れられてはいなかった
テストケースやデータを自動生成しようという話はあった
個人的な意見だが TDD まで厳密にとは言わないがコーディングしたらそれと同時に最低限のテストを書いておいたほうが安定したコードになる気がする
本書内でもコーディングの終了=テストの終了という表現が使われていた

デメテルの法則

厳密に守ることができるのだろうか
またそれに気づく方法が経験しかなさそう
参考

すべてのコンテキストを網羅することはできるのか

本書内で「コンテキストの事故」というトピックで紹介されていた
「GUI ではなく CUI も想定しているか」「英語以外の言語に対応できているか」「ユニバーサルデザインに対応しているか」などが紹介されていた
おそらく洗い出したらきりがないとと思う
開発中のアプリケーションに対してすべてのコンテキストを洗い出して対応することはできるのだろうか
またそれらは本当にユーザが求めているのかの判断も難しい気がする

想定していないコンテキストがあるとそれが偶発的プログラミングの元になりバグを生み出す可能性になるのはわかるがすべてを網羅するのは難しいと感じた
またすべての内容を理解しながらコーディングを進めるのも必要ではあるが難しいケースもあるかなと感じた

リファクタリング、最適化

二重化/直行性やの結合度を最小化は当然としてアルゴリズムのオーダーの見直しやリソース/コストの見積もりと削減なども重要だなと感じた
プロファイリングなどを使ってコーディングの段階から意識したほうが良さそう

リファクタリングの前に必ずテストが用意されているという点も重要だと思う
意外とテストとリファクタリングを同時に行ってしまうケースはあると思う

リファクタリング時のミスをなくすという意味でやはり IDE は便利だと感じた

精神論

途中「本能に任せる」とか「経験から考える」「準備できるまで様子を見てみる」といったフレーズが出てくる
こういったのは経験からしか判断できないことが多いのでまずは考えないでもいいのかもしれない

別の箇所で「形式方法論」というツールなどを使ったアプローチを紹介している
デメリットもあるがそちらのほうがスタートは切りやすいと思う

チームの機能的分担

分析、設計、コーディング、テストという単位ではなくシステムの機能単位でコントロールするほうが良い
そのほうが全員がシステム全体を把握することができる
無理に機能単位でコントロール必要はないと思うがメンバー全員が分析、設計、コーディング、テストなどすべてを網羅的に把握しているほうが良いと思う

ビルフローなどの自動化についても触れられているが最近だとアプリケーション開発においてはデファクトで導入されているケースもあると思う (Github Actions や Circle CI など)

その他、あまりピンとこなかった話

  • ミニ言語
  • 見積もり
  • プレーンテキスト
  • 表明プログラミング
  • リソースの開放
  • ホワイトボードシステム (kvs 的なことだろうか、タプル空間)

最後に

本書を読んで自分なりに判断した「達人プログラマー」とは
幅広い知識と豊富な経験から算出される最適な答えと手法を導き出せる人 かなと思う

あと付録C のクイックリファレンスガイドがかなり役に立つので見返す時にオススメ

2019年11月19日火曜日

Podcast の編集方法に Audacity を使い始めた

いままで録音から編集まですべて Mac 標準の GarageBand で行っていたのですがノイズとノーマライズがどうしても気に入らなかったので Audacity を導入しました

環境

  • macOS 10.15
  • Audacity 2.3.2

録音はこれまで通り GarageBand で行う

マイクはこれまで通り ECM x 2 本 を使っています
Audacity で 2ch の録音を行うのが結構面倒そうだったので録音はこれまで通り GarageBand で行っています
本当は Audacity で録音もしたいのですが結局最終的な AAC への書き出しは GarageBand で行うので素直に録音も GarageBand にしました

録音したデータをトラックごとに AIFF 形式で出力する

まず録音したデータを Audacity で読み込める形式で出力します
また出力する際はゲストと自分の声とを別々で編集するのでトラックごとに出力します
トラックをミュート状態にすればトラックごとに出力することができます

ここで音量の調整を行います
GarageBand のゲインを使って録音した波形をなるべく同じ音量になるように調整します

Audacity が AAC フォーマットに対応していないので AIFF で出力します
出力したら .aiff ファイルをAudacity にドラッグアンドドロップで読み込ませます

ノイズ軽減

Audacity でノイズ軽減するときにまずやるのがノイズプロファイルの取得です
要するに「ノイズはこういう音だよー」というのを Audacity に覚えさせます
そしてそのあとでトラックの範囲を全選択してノイズ軽減します
読み込ませたトラックごとにノイズ軽減する必要があるので 2 回行います
自分が使っているノイズ軽減時のパラメータは以下の通りです

「ノイズ軽減 (dB)」の値を大きくすればよりノイズが削除されますが大きすぎると元の声が来たりするので調整しながら決定してください
それ以外はデフォルトのままです

ちなみにノイズ軽減はメニューバーから「プロファイル」->「ノイズ軽減」でできます

ノーマライズ

次にノーマライズです
これは特に前処理とかは不要です
トラックの範囲を全選択して「プロファイル」->「ノーマライズ」で OK です
パラメータは以下の通りです

音割れがひどい場合は Clip Fix を使う

マイキングがうまくいかずにずっとマイクが近い状態で録音していると波形が上下に飛び出ていまい音割れします
聞いているとかなり不快なのでそういった場合には Clip Fix を使います
「エフェクト」->「クリッピングの修復」でできます

Audacity で MP3 として書き出す

編集したそれぞれのトラックを MP3 として書き出します
Audacity から書き出すときもトラックの「ソロ」を選択することで他のトラックがミュート状態になり 1 つのトラック分だけ書き出すことができます

書き出すときのパラメータはデフォルトのままですが以下の通りです

再度 GarageBand に取り込んで AAC で書き出し

最後に出力された MP3 を GarageBand で再度取り込みます
元のトラックはミュート状態にして新たに取り込んだトラック 2 つ分を書き出します
書き出す際にはこれまで通り AAC を選択して極力ファイルサイズを小さくしましょう

Tips

ノイズプロファイルはどうやら保存されないようです
Audacity を開くたびにノイズプロファイルを取得する必要があるのでそれが面倒です
ノイズプロファイル用のトラックを 1 つ余分に取り込んでおいても良いかなと思います

今回の手法を使うと GarageBand のプロジェクトファイル .band ファイルがほぼ 2 倍になります
だいたい 1 時間の収録だと 2GB くらいのサイズになります
ディスクを逼迫する可能性があるので定期的に外部メディアか何か避難しておきましょう

最後に

Podcast の編集方法を GarageBand -> Audacity に変更しました
Catalina ではまだ正式にサポートしていないようですが特に問題なく動作しました

これまでかなり気になっていた SONY ECM-PCV80U のホワイトノイズ問題がこれでだいぶ解消されました
GarageBand にもノイズ除去の機能はあるのですが Audacity のほうがキレイにホワイトノイズを削除できます

横着しないでちゃんと

  • 録音は GarageBand
  • 編集は Audacity

という感じで使い分けることが大事だと学びました
ちなみにAudacity 適用前と後を聴き比べしたい人は以下でできます





前のほうはホワイトノイズが少し残っているのでプチプチ聞こえるのがわかると思います
後のほうはそれがなく声がクリーンに聞こえるような気がします

2019年10月26日土曜日

名刺作りました

ステッカーに続いて個人名刺を作ってみました
使ったサービスや所感を述べたいと思います

作り方

今回使わせていただいたサービスはラクスルになります
当初は自分でデザインから印刷までやろうとしたのですがいざ印刷しようとすると結構面倒そうだったので印刷までやってくるサービスを選択しました

名刺を作成する場合 Numbers や Keynote のテンプレートを使って作成することができます
ローカルしても問題ないですがラクスルには「オンラインデザイン」という機能がありそこで名刺のデザインができるので今回はそれを使いました

フォトショップのような高機能なエディタに比べるとできる機能は限られていますが最低限の機能はあると思います

名刺のデザインデータを作成後はデータを入稿する前に先に購入処理を進めます
名刺の場合用紙のサイズや髪の質感、両面にするかなどいろいろとオプションが選択できます
自分は基本デフォルトの設定のままにしました

このページに名刺の商品一覧があるのですが自分は一番安い「オンデマンド印刷 100 部の受付日から
3営業日後」の 500 円のものを購入しました

枚数/金額

  • 枚数・・・100 枚
  • 金額・・・749 円 (送料込み)

なので 7.4円/1 枚になります
商品自体は 500 円の商品でそれに税金やら送料やらを含めて上記の値段になっています

デザインデータ入稿

購入したら作成した名刺のデザインデータを入稿することになります
ちゃんと「オンラインデザイン」から入稿できるのでご安心ください
最初は「商品を購入してからデータ入稿の流れだとプレビューとか確認できないんじゃ、、ちゃんとプレビュー確認してから購入したいなぁ」と思ったのですが購入してデータ入稿後にちゃんとプレビューもできました
(データを入稿してプレビューしたときに「これじゃない」ってなったら返金できるのかは不明、、)

データを入稿したあとは最終チェックという段階に入るようですが一瞬でスルーしました
なのであとは到着を待つだけになります

到着

10/22 に購入およびデータの入稿をして到着したので 10/25 でした
ちゃんと 3 営業日後に到着しました
指定の通りメール便にて到着しました

開封して確認してみたら以下のような感じでした
50 枚ずつ上下に分かれて 1 つのケースに入っていました

紙の質感などは事前に確認できなくて心配でしたがちゃんと名刺っぽい質感の紙でした
小さい文字もちゃんと表示されていました
確か一番小さいフォントサイズは 20pt にしたと思います

両面印刷もバッチリでした

最後に

ラクスルで個人名刺を作成してみました
オンラインデザインというブラウザで使える専用のエディタがあるので割りと簡単に作れました
ラクスル上の機能とサービスだけでデザインから購入、データ入稿までできるのは初心者にもやさしいサービスだなと思います

使う機会があるのかさっぱりわかりませんが 700 円で作れるので皆さんも作ってみてはいかがでしょうか
ちなみに自分はこれも特典にしたいと思います
https://kakakikikeke.com/supporter
サポータになればステッカーと合わせて名刺も差し上げたいと思います
もらっても全然うれしくないと思いますが