【備忘録】 「オブジェクト指向設計実践ガイド」を読む

うぃろぅです。

今日は読書の方。学びを書いていきます。

今日の本

オブジェクト指向設計実践ガイド

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

Java版が有名だが、そのRuby版が出版されている。
Rubyの環境は会社のPCにも入っている(こそっと入れた、ただしirbが安定して動かない)ためお試しもできる。

第1章 オブジェクト指向設計

オブジェクト指向設計の理論。

少し読めば気がつくが、本文に意訳が少なく、英語で書かれた説明文っぽさが前面に押し出されている。
恐らく意識して訳者の意思を排しているのだと思われる。

この章は図説もソースコードもないため、大判の本に文字がこれでもかと並んでいて少し圧倒される。我輩が猫であるを思い出したりなどしていた。

第2章 単一責任のクラスを設計する

将来何が起こるかわからないため、とりあえず機能を分離する。
決定を遅らせることが重要で、そのために1つの処理で1つの機能、としておくと対応しやすくなる。

この本では自転車の例を挙げて説明している。オブジェクト指向界隈、自転車だったり車だったり乗り物と縁が深め。多分例に挙げやすいだけだと思うが。

それと52ページに誤植がある。

def diameter(wheel)
  wheel.rim + (wheel.tire * 2))
end

閉じ括弧が1つ多い。恐らく53ページ目のソースをコピペして消し忘れかなと。

第3章 依存関係を管理する

どうでもいいけれど「いそん」って読む人少ないよね。辞書的にはどちらでもいいしNHKも「イゾン」と読むように変更したとのこと。でも「いそん」の方がなんとなく響きが綺麗。それだけ。

GearクラスがWheelクラスの存在を知らなければならないソースになっているため、その依存関係を修正する。いわゆる疎結合。

これはテストコードに関してもいえることで、コードを修正するたびにテストコードも修正しなければならないようなテスト設計はNGとなる。
言われてみればそのとおりだが、これまであまり意識してこなかった。

知識を減らすことで、より賢くなったのです。

「依存オブジェクトの注入」についての説明箇所だが、引用箇所の言葉回し好き。めっちゃお洒落。

依存関係に関しては

• 変更の起こりやすさ
  自分のコードより開発の活発なフレームワークの方が変わりやすい等。
• 具体クラス vs 抽象クラス
• 依存関係が多いクラス

の大きく3点に気をつける必要がある。
上手いこと自分より変更が少ないクラスを見つけ、そこに依存しよう。

第4章 柔軟なインターフェースをつくる

クラス内をパブリックとプライベートに分ける重要性について。

さらには設計のポイントについて。
クラスを中心に考えるのではなく、メッセージを中心に考えられるようになることが設計者としてのキャリアの第一歩。

オブジェクト指向設計の要は手放しの信頼である。
「詳細はわからないけれど呼べばよしなにやってくれるはず」を繋げることで機能が成り立っていくことが拡張性のあるプログラムだという話。確かに単一責任であるということは他の機能に対して責任を負う必要がないということで非常に理にかなっている。

パブリックインターフェースに含まれるメソッドの条件は以下のとおり。

• 明示的に特定できる
• 「どのように」ではなく「何を」になっている
• 名前は恒久的に変わらないものである
• オプション引数としてハッシュをとる

「明確に」を合言葉に。複雑さはどこでも求められていない。

ここまでの説明を下地に「デメテルの法則」について検討。

ja.wikipedia.org

Wikiの説明でもがわかりやすかったため貼ってしまうが、要は「友達の友達にものを頼むな」ということである。

第5章 ダックタイピングでコストを削減する

「ダックのように鳴き、ダックのように歩くのであれば、それはダックである」というやつ。

共通して行っている機能を抽象化して切り出してあげることで、「何やっているかわからないけれどこのメソッドは実装しているはず」と信頼して処理を投げられる。
抽象メソッドみたいなものかな、という認識。ちょっと違うとは思うが。

じゃあ何がダックで置き換えられるのよ、ということで以下が置き換えられる例。

• クラスで分岐するcase文
• kind_of? と is_a?
• respond_to?

詳しい説明は書籍参照のこと。

また、ダックタイピングに関連して静的型付け言語対動的型付け言語の比較。
私はJavaとC#を少し触ったことがあるが、Rubyの方がコーディングしていて楽しいから動的型付けでも全然問題ないと思っている。速度に対してシビアな状況に直面していないからかもしれないが。

第6章 継承によって振る舞いを獲得する

これまではコードの最小化がテーマ、ここからはコードの共有がテーマ。

継承を利用する際には「is-a関係」を意識してあげると上手くいくことが多い。もちろん全てにおいて有効というわけではないが、判断基準のひとつとしては有効なものである。

Javaではabstractキーワードをつけることでスーパークラスのインスタンス生成を抑止できるが、Rubyにそのような制限をつけるキーワードはない。プログラマを信頼しているからね。

継承を実装するときは実際に継承が有効になってからで充分。YAGNIでいこう。

リファクタリングのポイントとして、既存のクラスをスーパークラスとサブクラスに分けたら、まずはサブクラスに全てのコードを移動してしまうということが挙げられる。
別のサブクラスを宣言したとして、エラーメッセージを見て「何を共有するか」を判断しやすいからである。なるほど。結果的にスーパークラスに余計な処理を入れずにすむと。

共通化したからといってそれでいい、というものではなく。
superの呼び忘れは誰しも起こりえるのでそれに対する対策も取り込むことでより堅牢になる。そのための手段がフックメッセージであると。
これは知らなかった。積極的に取り入れていきたい。

第7章 モジュールでロールの振る舞いを共有する

継承可能なコードの書き方に続いて継承の使いどころさんを解説。

モジュールをmix inする関係の詳しい解説はチェリー本を読むといいと思う。

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)

いつもお世話になっております。

継承との使い分けとして「である(is-a)」か「のように振る舞う(behaves-like-a)」かが1つの基準。
機能を共有することは継承と似ているので、フックメソッドを実装するのが吉。

第8章 コンポジションでオブジェクトを組み合わせる

オブジェクト指向コンポジションのテクニックについての解説。

パーツを組み合わせて全体を組み合わせることをコンポジションと呼んでいる。

クラスを構成する要素をパーツごとに分解して…となると知識量が多くなるため、ファクトリーパターンを活用する。

gihyo.jp

あとソースコードに誤植あり。ミスは誰にでもある。

コンポジションか継承かで迷った場合、明確なメリットがないのであればコンポジションを優先するべき。掘り下げるなら継承、パーツを集めるならコンポジション、といったところか。

第9章 費用対効果の高いテストを設計する

上手なリファクタリングのためには価値の高いテストが必須。
テストを書き直すことなくリファクタリングを進めていけるテストコードについての解説。

テストの利点として挙げられているのは以下。

• バグ発見
• 仕様書になる
• 決定を遅らせる
• 抽象を支える
• 設計の欠点の明確化

詳細は書籍参照。

使われていないコードでも存在するのであればテストをしなければならないため、コードを削除することも大事。

受信メッセージをテストするためのテストダブルがスタブ、送信メッセージをテストするためのテストダブルがモックという認識。

抽象スーパークラスの機能をテストするために、テスト用のサブクラスを作ることも有効。

とりあえず手は動かしたが完全に理解できたかというと完全ではない。
引き続き手を動かしていきたいところ。

おわりに

「オブジェクト指向わかってきたわ」と思ってこの本を読んだわけだが、わかった気になっていただけだったということが身にしみてわかった。

オブジェクト指向マスターへの道は遠く険しい。
まだまだ精進ですなぁ。

今回の手を動かした証跡は以下。

github.com

いい本だった。きっとまた読み直す日が来る。

ではまた。

○○Pay(主に7Pay)をとりまく四方山話

うぃろぅです。

電子マネー、便利ですよね。

PayPayしかり、LINE Payしかり。

電子マネー、スマホ払いという点でのメリットとして

• 財布を持たずに買い物ができる
  スマホを持ち歩かない人の方が財布を持ち歩かない人より現代日本であれば少ないはず。
• お金を触らずに済むので衛生的
  スマホの画面が衛生的か、と訊かれるとそうではないですが、他人が触れやすいか否か、という点では差別化できそう。
• お釣りが出ない
  小銭の管理、地味に重いし計算面倒だしで煩わしい。
• 待ち時間が減る
  貴重なお昼休みをコンビニの行列に費やしたくはない。

といったことが挙げられると思います。
一方で

• 対応していない店舗では使えない
  対応状況を調べるのも面倒なことがある。
• 支払い方法を発声する必要がある
  声の出せない事情のある方はもちろん、人見知りをこじらせている方もあまり発声したくないはず。もしくは聞き取ってもらいにくいという要素も。(「iD」と「Edy」とか)
• 見えないところで不正利用されるリスクがある
  現金は「窃盗」という目に見える形の不安はありますが、充分注意していればそこまで遭遇する機会は多くないはず。

といったデメリットも挙げることができます。

さて、今日の本題。
7月の頭からはセブン-イレブンやファミリーマートといったコンビニで独自サービスの電子マネー決済が始まりました。
なるほど時代はどんどんキャッシュレスに向けて動いているんだな、と感じていたのも束の間。
このエントリーを書いている2019/7/4現在、セブン-イレブンで使える「7pay」が不正利用の報告多数で大変なことになっています。

で、今ホットなこの話題について、面白そうな話題をいくつか(いくつも?)見つけたので思ったことを書いていきます。
モバイル決済の環境から7payのことまで雑多に書いていくので話題につながりがなさそうな気配がします。あしからず。

以下目次。

世はモバイル決済時代

大手各社は独自モバイル決済の新規顧客獲得のため、しのぎを削っていた…。
ということでまずはモバイル決済を取り巻く環境から。

モバイル決済乱立のワケ

いくつか理由があると思われます。すぐに思いつくだけでも大きく分けて2つ。

消費税増税対策

2019年10月には消費税率が10%に引き上げられます。
計算が楽になるのは確かに(脳のワーキングメモリ的には)楽だけれど、少し前まで5%だった記憶が残っている身としては2倍は結構大きいです。

政府はキャッシュレス決済を推奨しており、クレジットカードやモバイル決済等のキャッシュレス決済であればポイント還元により実質8%程度になるよう軽減税率の整備を進めているとか。

ユーザーとしては「ポイント還元」というワンクッション置く形であれ、多少の導入 / 学習コストで税率が安くなるのであればキャッシュレス決済を試してみるかという気持ちになるというもの。

外国人旅行者の増大

外国からの旅行者、昨今だと中国人ですね。こちらが年々増大していっています。
詳細な資料は観光庁を参照してもらうとして、2020年にはオリンピックも控えているため今後も訪日旅行者数が増大することが予想できるわけです。

そうなったときに問題となってくるのは買い物時の決済方法。
よく話題になるのが五円玉。

漢数字しか使われていないため、何円なのかわからないケースがあるんですよね。

そうなってきたときに便利なのがモバイル決済。
モバイル決済先進国といっても過言ではない中国においては、「微信支付(WeChat Pay)」か「支付宝(Alipay)」があればほぼ何でも支払いができます。

「AlipayかWeChat Payで日本でも買い物できるよ」と宣伝すれば、使えないお店と比較して確実に中国人の購入機会が増えます。

日本における中国モバイル決済対応状況

www.nikkei.com

techwave.jp

上記の事情を受け、PayPayとLINE Payはそれぞれ中国の2大モバイル決済との連携対応を発表。海外旅行者の日本におけるモバイル決済対応は進行しつつあります。

日本におけるモバイル決済はこの2種類のどちらかでいいじゃない、話はここでおしまい!!
…とはならないのが日本という国なわけで。

2019年7月時点のモバイル決済いろいろ

news.cardmics.com

こちらを読めば概ねわかりますが、とにかく数が多い。
クレジットカード等を用いた入金機能対応のICカード決済もモバイル決済として含めてしまうのであれば、支払いの手段は数十種類にも及びます。

クレカ決済じゃだめなの??

ダメというわけではもちろんありませんが、クレジットカードはモバイル決済と比較して決済手数料が高く(クレカは8～10%程度、モバイル決済は3～5%程度)、「クレカ決済は費用がかかるから」と現金会計に絞っている個人事業主も少なくありません。

モバイル決済は日本においては現在発展途中と言うこともあり、「決済手数料無料キャンペーン」なるものを実施していることもあります。
それであれば、とモバイル決済を導入するケースが増えつつあるようです。

コンビニ別対応状況

現代の若者がよく使うお店と言えばコンビ二です。
その時々のニーズに合わせて事業展開を行う必要があるコンビ二でもモバイル決済は導入されています。

japanese.engadget.com

上記サイトから引用させていただくのですが、こちらをご覧いただきたい。

下4段を見ましたね?
もはや何がなんだかですよ。斜めにならんでいて綺麗。いやそうではなく。 これなら「PayPay」か「LINE Pay」でいいやってなりますよね。

なぜ独自モバイル決済を導入するのかの考察

そもそも「PayPay」か「LINE Pay」だけ使っていれば問題なさそうなのになぜ各社独自のモバイル決済を開発するのでしょう?
私は経営層にはおらず、ざっと調べてもあまり有益な情報が得られなかったのですが、考えられる理由としていくつか挙げられます。

リピート客を増やすため?

「7Payだと今ポイントお得だからすぐ近くにファミマあるけど2分歩いてセブン行くか」というアクションを起こさせることができるとは考えられます。あれもこれも、使い分けるのはユーザーにとって負担が大きいですし。

手数料削減のため?

クレジットカードもそうなのですが、電子決済には手数料がつきものです。

paypay.ne.jp

PayPayは決済手数料0円を謳っていますが、保証されているのは3年間。3年経過後はどうなるかわかりません。

そうした場合に、自社開発の決済システムを使ってもらえれば損をすることがなくなると、そういう発想になるのも理解はできます。
コンビ二としては「フランチャイズ展開の看板使用料」と「モバイル決済手数料」が2重に課せられるようにもなる…のかもしれません。

キャンペーン等の表示、販売促進のため?

独自のモバイル決済を利用してもらうということは、独自のキャンペーンをスマホに表示させやすいということになります。

QRコードを読み取るにしろ、表示するにしろ、ユーザーはスマホの画面を見ることになるわけです。
その画面に(決済後にでも)「今これを買うと抽選で賞品が当たるよ!」だとか「この飲み物が安くなってるよ!」だとかの表示をすればユーザーはそこに意識が向きます。
そうした宣伝により、「そういえば今あれが安いって広告あったな」と購入機会が増大するのです。

7Payをとりまく環境

ここまでがなんとなくの前提知識です。長い。

流れをまとめてみましょう。

1. 海外旅行者が増えた
2. モバイル決済の需要が高まった
3. Apple Payが日本でもできるようになった
   ちなみにこれよりも前(2年程度前)からLINE Payは利用可能でした。
4. PayPayが「100億円キャンペーン」で有名になった
5. LINE Payも対抗してキャッシュバックキャンペーンを実施した
6. ソフトバンク(PayPay)に対抗して、ドコモとauも電子マネー決済を宣伝し始めた
7. 増税に対する軽減税率適応対象としてキャッシュレス決済が推奨された
8. 共通ポイントの先駆けとなったTポイントが衰退し、各社独自のポイントサービスを始めるようになった
   セブン-イレブンは「nanaco」を使って新規顧客獲得のためにいろいろなキャンペーンを打ち出している。Omni7と連携して適切なサジェストをし、さらに購入機会を増大させようという試み。
9. Tポイント離れの煽りを受けファミリーマートも独自ポイントサービスを画策した
10. ファミリーマート、「ファミペイ」を7月から開始することを発表
11. セブン-イレブンも(ファミリーマートに対抗して?)「7Pay」を7月から開始することを発表

こんな感じかなと。

Tポイント云々の話はここでは初出ですが、少し前に話題になっていました。

www.mag2.com

ここで問題になってくるのが「後発なのに納期が短い」ということかなと。
再利用可能なコードがあるならまだしも、これまで手をつけていない分野の開発でこれは…厳しいですね。 Omni7の時も「プレスリリースしているから納期はずらせない」を体現したかのような詰め込み作業感がリリース時に話題になっていました。
まさか経験から学習していないのか…??

今回の事象

よくある(よくあっていいことではない)不正利用ですね。
7Payに紐付けられたクレジットカードから不正に入金され、7Pay利用可能サービスを通して不正に購入された。
PayPayのときにもこういった報告ありませんでしたか…?
まさか経験からだけではなく歴史からも学習していないのか…??

piyolog.hatenadiary.jp

セブン-イレブンの発表内容や被害状況についてはこちらに詳しくまとめられています。

直接原因

何が起こっているかというと

• 7PayはOmni7のサインインに利用可能な「7iD」でサインインを行う
• 「7iD」のパスワード再設定サイトはOmni7側に配置されている
  パスワード再設定サイトはこちら。
• 今は表示されなくなってるがパスワード再設定サイトの入力項目に「送付先メールアドレス」という項目が存在した
• 「送付先メールアドレス」欄に任意のメールアドレスを入力すると
  • 「7iD」登録時のメールアドレス
  • 「送付先メールアドレス」
    の両方にパスワード変更用メールが送付される(!)ようになっていた
• iPhoneから登録した場合生年月日を未入力にすることが可能で、その場合は誕生日が「2019/1/1」に設定される(!?)
• パスワードを任意の文字列に変更すればアカウント乗っ取りが可能

ということです。
「7iD」はメールアドレスのため、メールアドレスさえわかればアカウントが乗っ取れる状況になっていたというわけですね。えぇ…。

ちなみに今(2019/7/4 17:00ごろ)はどうなっているかというと

項目としては存在しているものの非表示となっています。
これはダメなのでは…?
恐らく送信時に「送付先メールアドレス」のvalueが空白なのは許されていますが、keyが空白なのは許されていないのではないか…と推測できます。上記サイトをのぞけばわかりますがname="sendMailAddress"ってところですね。うーん。

すり抜け原因

セブン-イレブンは「セキュリティチェックに問題はなかった」としています。

恐らくこのセキュリティチェックは「7payへの不正な操作(決済時の情報の抜き取りが考えられますね)」に対するチェックだったのかな、と。
今回は7Payに問題があったのではなく、7Payを使用するときに紐付ける「7iD」側に問題があったように見受けられます。

なのですり抜け原因としては「Omni7側のセキュリティ対策が万全ではなかった」ということでしょうか。

根本原因

そもそもの問題としては

• 短納期のため考慮が行き届かなかった
• Omni7の開発が不十分だった

なのではないでしょうか。
要件定義が不十分だったのか、開発者の技術力が足りていなかったのか…多分両方でしょうね。

もうちょっと突っ込んだ話もできなくはないですがオープンにしてはいけなさそうな話なのでオフラインででも訊いてください。

これから

www.fnn.jp

一旦新規登録とチャージ機能を停止しているようですね。
信用を取り戻せるかは非常に厳しい話となりそうですがなるようにしかならないでしょう。

面白かったツイート

7Payで一番やべーって思ったの、パスワードリセットURLに拡張子があってしかも.doって・・・まさかのStruts1？

— Yasuo Nakanishi (@nakanishiyasuo) 2019年7月4日

拡張子が.doなのはJavaのフレームワークであるApache Struts 1の可能性が高いです。

https://struts.apache.org/struts1eol-announcement.htmlstruts.apache.org

Struts 1は2008年に最終リリースがあり、現在はサポートされていません。

多分開発期間があまりにも短かったからどこか別のアプリで利用した機能を再利用したのではなかろうか…と推測できます。

ちなみにStruts 2も存在していますが、脆弱性が見つかったためアップデートがなされています。2で発見されたってことは1には潜んだままなのではなかろうか。Struts1とは無関係です。

struts1とstruts2は名前は同じですが中身は全くの別物です。 もともと違う名前で開発していたものを名前だけstrutsにしたのがstruts2です。 なんの関係もないです。 なのでstruts2の問題がstruts1で起きるということはありえません。 まあサポート切れのものを使っている時点でアウトですが。

コメントにてご指摘いただきました。なんにせよ2013年にサポートが切れているフレームワークを使うな、という話ではありますね。

2019/7/31 追記

[https://twitter.com/togetter_jp/status/1156184176896274433:embed#「7Payの不正利用を受け、7iDのパスワードを全員リセットに…→再設定するとクーポンや7Payの残高が消えたとの報告が相次ぐ」https://t.co/jhJJC2SMm0 が伸びてるみたい。私も読みに行かないと！ 作成者:@Ma__anal]

てんやわんや。一回サービスとめた方が信用面で良いのでは…?もう地に落ちてる?そうねぇ…。

え、7iDまだ東京都女性2019/01/01生まれの設定引きずるつもりなの? pic.twitter.com/a7ps0xVxFH

— ☆★たいきょー★☆ (@taikyo_) 2019年7月30日

「アプリからの登録は少しでも簡単に」という方針なのでしょうか。そこは一番サボっちゃいけない場所だと思うのだけれど…。

2019/8/1 追記

headlines.yahoo.co.jp

サービス終了が発表されましたね。
やはり短納期でこの規模の電子決済サービスというのは無理があったんでしょうね。

これで電子決済関係ではファミリーマートと差がつく形になりました。
セブン-イレブンがトップに立ち続けているコンビ二業界の売り上げに何か変化は訪れるのでしょうか。

セブン-イレブンの明日はどっちだ。私はSuicaを使います。

間違っている情報を載せている恐れもあるため、ご指摘等あったらお知らせください。

ではまた。

【セトリ】 水瀬いのり LIVE TOUR 2019 「Catch the Rainbow！」 東京公演 1日目 セットリスト

2019/6/28に日本武道館にて開催された
Inori Minase LIVE TOUR 2019
Catch the Rainbow！
東京公演 1日目のセットリストです。

1: Step Up!
2: ピュアフレーム
3: Ready Steady Go!
4: Kitty Cat Adventure
5: Wonder Caravan!
6: コイセヨオトメ
7: ココロはMerry-Go-Round
8: Future Seeker
9: 君色プロローグ
10: 水彩メモリー
11: 約束のアステリズム
12: brave climber
13: 三月と群青
14: 今を僕らしく生きてくために
15: TRUST IN ETERNITY
16: Starry Wish
17: My Graffiti
18: harmony ribbon
アンコール
19: Dreaming Girls
20: Million Futures
21: Catch the Rainbow!

【FjordBootCamp】 「Webを支える技術」を読む

うぃろぅです。

ありがたいことにプロジェクトの隙間時間に技術書を読むことが許可されているため、フィヨルドブートキャンプの課題の一環である本を読んでいきます。

今回の本

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webの基礎を学ぶ本。詳細に内容を書いてしまことは問題があるため、理解したことをまとめていく。

第1部 Web概論

• Webの歴史について
  歴史の授業が苦手だったことを思い出すなど。
• URIってなんなのさ
  リソースを一意に特定する識別子のこと。
• RESTってなんなのさ
  • クライアント / サーバ
  • ステートレスサーバ
  • キャッシュ
  • 統一インターフェース
  • 階層化システム
  • コードオンデマンド
    以上の6つを組み合わせたアーキテクチャスタイルのこと。
    それぞれについての詳細は書籍参照。
    全てを兼ね備えてなければならない、というわけではなく、これらはRESTの基本となる考え方というだけ。
    そのため、業務内容によっては細かな変更をして設計する、ということも大いにあり。

ここから、「RESTful」な考え方についての説明や設計について語られていくという引き。

歴史が説明されている箇所では細かな用語の説明がなく、順次言葉の解説がされていくスタイル。
そのため、読み始めたときは全く意味が頭に入ってこず、非常につらかった。
この「わけわかんないけれどとりあえず読み進めていく」感じ、学生のときみたいだ…。

第2部 URI

• URIの意義
  DBの主キーみたいなもの。そりゃ大事だわ。
• URIの例
  ユーザ情報も含められることは知らなかった。やらないだろうけれど。
• クールなURIを設計するために
  変化しにくいURI設計のポイントが解説されている。例えばプログラム言語に依存するURIにはしない方がいい等。
  試しに自社のグループサイトを見てみたらURIに.../cgi-bin/...とあって悲しい気分になったりなど。というか?_=(謎の文字列)とか?cmd=hogehogeみたいなURIが乱立していてこれは…これは…っ!!

URIはアドレス欄に表示されるものであり、寿命が長いものでもあるため、設計時に強く意識する必要がある。

設計の手法については第5部で解説する。

第3部 HTTP

• TCP/IPとは何か
  情報試験でよく見る階層化プロトコル。
  わかりやすい記事があったため貼っておく。
  www.itbook.info
• HTTPの歴史
  本書の発売時点では公開されていなかったHTTP/2が今の時代にはある。
  qiita.com
  リクエスト / レスポンスを多重化できることが大きな違い。それとサーバ側から能動的にデータをプッシュする機能があること。
• HTTPメッセージの内容
• ステートレス / ステートフル
  サーバがクライアントのアプリケーション情報を保存するか否か。ステートレスの場合やり取りが冗長になるが、サーバにかかる負担が減る。しかし通信エラー時に多重リクエストが送られてしまう危険性もあるため一長一短。
• HTTPメソッド
  たった8つしかない。あまり使わないものを省くと6つ。これなら覚えられそうじゃない??
  POSTの誤用の最たる例としてXML-RPCが挙げられているが、以前携わったプロジェクトの通信規格がXML-RPCだった。切ない気分になるなあ。
• ステータスコードについて
  ステータスコードの1文字目を見ると概要がわかるようになっている。
• HTTPヘッダについて
  キャッシュの扱いや認証など様々なことをヘッダでやりとりする。
  電子メール仕様から拝借したり文字コードの取り扱いがブラウザによって異なったりと魔境。都度都度調べる必要がありそう。

クライアントとサーバでデータをやり取りする際の約束事や歴史について。
多分この部は何度も読み返すことになりそうな予感。

第4部 ハイパーメディアフォーマット

• HTML
  タグで文書の構造を表現する。出版時はHTML5が仕様策定中とのこと。時代は確実に進んでいっている。
  なので本文中の<object>タグは<video>や<audio>タグなどで置き換え可能。どんどん利用していこう。
  reference.hyper-text.org
  また、rel属性はHTML5において自由に拡張できなくなった。
  www.htmq.com
• microformats
  HTMLでは表現できないリンクの細かい意味やイベント情報を表す。
  HTML5においても引き続き利用できるが、いくつか注意点はある。
  rev属性やprofileの削除など。
  http://html5doctor.com/microformats/html5doctor.com
  英語なのでざっくりとしか理解できない(私は英語が得意ではないため。勉強する意思はある)が、いくつかの注意点を意識しておけばHTML5でもmicroformatを利用できる、ということが書いてある。はず。

  So where does that leave us? Well, if you keep the above caveats in mind you can safely use microformats in HTML5.

• Atom
  エディタの方ではない。ちなみにエディタはこちら。
  atom.io
  Atom Syndication Format、略してAtom。WebサービスのWeb APIとして利用できる。 細かく指定できて便利そうなのだが、自分がまだ使っていないためいまひとつ理解しきれていない。
• JSON
  こちらはよくみるフォーマット。簡単なデータ構造の管理ならDBよりコストがかからない。
  プログラミング言語におけるハッシュやディクショナリのような記法のため直感的に理解しやすい。
• JSONP
  scriptタグを利用して異なるドメインと通信して情報を取得する仕組み。
  blog.ohgaki.net
  便利だからといって手放しで使えばいいというわけではない。
  簡単な公開情報のやりとりに使うなら良さそう。

第5部 Webサービスの設計

この本ではリソース設計について扱う。
恐らくこの部がこの本の肝。

• 読み取り専用のWebサービス設計
  「リソース指向アーキテクチャ」の設計手法について。
  • アドレス可能性
    リソースの主キー。最重要。
  • 接続性
    リンクをたどれるかどうか。アドレス可能性の次に重要。
  • 統一インターフェース
    接続性の次に重要。どのメソッドを採用するかよく検討しよう。
  • ステートレス性
    そこまで重要ではない。現実的に考えてCookieによるセッション管理がほぼ必須なため。
• 書き込み可能なWebサービス設計
  トランザクション処理(いくつかのデータの整合性を保つ処理)やPUTかPOSTのどちらを使うか、同時に更新が走った場合の対処など、こちらも悩みの種が多い。
  トランザクション処理を実装する場合はトランザクション処理用のリソースを追加し、そのリソースを使ってやり取りをするのが定石。
• リソース設計
  リソースはどのように抽出していくべきか、というお話。
  3つの対象が挙げられている。
  • ER図
    vviilloovv.hatenablog.com
    ER図は以前学んだ。この中の「リソース系」を対象にすれば考えやすい。
    リソース設計の際は正規化をあえて崩して全ての情報を含めることがポイント。
  • クラス図
    1インスタンスが1リソースとなる。
  • 情報アーキテクチャ
    ferret-plus.com
    情報構造のことらしい。

WebサービスもWeb APIもWeb技術を使ったインターフェースのため、分けて考えないことが大前提である、ということが再三強調されていた。

付録

ステータスコード一覧やヘッダ一覧など。

ぱらぱらと眺めていくと面白い。ここも読み返すことがありそう。

まとめ

毎日触れている「Web」の基幹を支える技術の基礎がこれでもかと詰まっている。
数回読み返すことで定着するタイプの書籍のため、折を見て読み返していきたい。

ちなみに1周目は全て読み終えるまで1週間ほどかかった。
業務の合間にとはいえもう少しペースを上げられたのではないかと見直しつつ次はもう少し効率的に読めたらいいね。

ではまた。

【Ruby】 三目並べのコードを読む

うぃろぅです。

業務時間で暇なとき作業の空き時間が生じたときにCodewarsで遊ぶ自己研鑽に励むことがたまにあるのですが、その中で「なんやこれ…」ってなったコードがあったので読み解いていきます。

今回の課題

「Tic-Tac-Toe Checker」というKata(問題)。

www.codewars.com

Codewarsに登録済みの方は上記リンクからとべる。

内容は以下。雑に訳すので間違ってたらゴメン。

「Tic-Tac-Toeゲーム(三目並べ / ○×ゲーム)」で遊ぶとき、勝敗を判別する機能が欲しいよね。そのチェックをする機能を作ることが目標だよ。

盤面は3 * 3で、次のように配列で表すこととする。
0は空白、1は×、2は○とする。
配列:
[[0, 0, 1],
[0, 1, 2],
[2, 1, 0]]

入力に対して以下のように返したい。
-1: まだ勝負がついておらず、空白(0)が存在する
1: ×の人が勝利している
2: ○の人が勝利している
0: 引き分け((○×ゲームにおいては?)cat's gameと言うことがある…のかも)

例外処理は考えないものとして進めていく。

自分のコード

def judge(arr)
  arr.uniq.size == 1 && arr.first != 0 ? arr.first : false
end

def is_solved(board)
  if result = (0..2).map { |j| judge((0..2).map { |i| board[i][j] }) }.find { |r| r } ||
  (0..2).map { |j| judge((0..2).map { |i| board[j][i] }) }.find { |r| r } ||
  judge((0..2).map { |i| board[i][i] }) ||
  judge((0..2).map { |i| board[i][2 - i] })
    result
  else
    board.flatten.include?(0) ? -1 : 0
  end
end

特に何も思いつかなかったので特に難しいことはしていなくて、愚直に勝敗に関係する並びのパターンを書いて勝敗チェックをするメソッドを呼ぶ、という流れ。
勝敗がついていたらその値を返し、ついていなかったら0の有無によって出し分ける。

おしゃれなやり方が思いつかなかったのでとりあえず通して先人の知恵を借りよう、という意図がちょっとある。

見直してみると0..2を変数か定数にした方が見やすいなこれ。まぁそれは置いておくとして。

参考コード

で、答えた後に参照できるコードから自分の学びに活かそうとした結果これが最初に出てきた。

def is_solved(board)
  case board.join
  when /1..(1|.1.)..1|1.1.1..$|111(...)*$/ then 1
  when /2..(2|.2.)..2|2.2.2..$|222(...)*$/ then 2
  when /0/ then -1
  else 0
  end
end

なにこれ…さぱらん(さっぱりわからん)…。

ということでこちらを読み解いていくのが今回の目的。

joinの結果を見る

board.joinで何が得られるのか。やってみた。

$ irb
irb(main):001:0> board = [[1, 1, 2], [2, 1, 1], [2, 2, 1]]
=> [[1, 1, 2], [2, 1, 1], [2, 2, 1]]
irb(main):002:0> puts board.join
112211221
=> nil

なるほど単純に全部結合していると。Array#joinなのでstringで得られる。
多次元化していても平滑化する。便利。

ref.xaio.jp

正規表現でチェック

ということは結合した文字列に対して正規表現を使ってチェックを行っているっぽい。

どちらかが勝つパターン

今回の場合は1か2が勝つパターン。大別すると以下。

• タテ
• ヨコ
• ナナメ

/1..(1|.1.)..1|1.1.1..$|111(...)*$/を解析する。

regular expressionsに貼り付けて挙動を確認してみるとわかりやすい。

ヨコ

ヨコが一番簡単で、/1..(1|.1.)..1|1.1.1..$|111(...)*$/の111(...)*の箇所がそれ。

111が1回、任意の3文字が0回以上。正しい入力がここまで来る想定なのでこれで問題なし。

タテ

単純化すると1..1..1がどこかにあれば良いということになる。

/1..(1|.1.)..1|1.1.1..$|111(...)*$/の1..(1|.1.)..1|の箇所がそれということになる。

ナナメ

^1...1...1$(複数行でないため\A\zでなくても良い認識)か、^..1.1.1..$がナナメ。後者は1.1.1..$でも良い。これのせいで正規表現が若干ややこしくなっている。

タテの1..1..1とナナメの1...1...1が合わさり、1..と..1を共通化した結果1..(1|.1.)..1となる。
1.1.1..$は上記で書いたパターンそのまま。

ということで

解析した結果

/1..(1|.1.)..1| # タテ / 左上→右下のナナメチェック  
1.1.1..$| # 右上→左下のナナメチェック  
111(...)*$/ # ヨコチェック

ということがわかった。なんてスマート。

勝者がいないパターン

あとはもう消化試合。勝者がいないパターンかつ0があったら-1を返し、どれでもなかったら0を返却する。

今回の学び

正規表現を使うことはもちろんあったし知識として知ってはいるが、この問題に応用できなかった。
正規表現センターを研ぎ澄ませていきたいところ。

自分のコードと参考コード

github.com

main.rbが自分で考えたコード、clever.rbが参考コード。
テストコードつき。

いやーこれは楽しい。まだまだ成長できるなぁ。

ではまた。

【備忘録】 リーダー向け(と銘打たれている)心理学

うぃろぅです。

別にどの曜日なら働きたいかって訊かれても「できることなら働かないでお金が欲しい」に帰着しますがそれでも木曜日の「今日頑張ってもまだ1日頑張らなきゃいけない」感はとても苦手で、それのせいなのか木曜日はあまり好きではありません。
だったら水曜日はどうなのさ、ということで考えてみても「まだ折り返し地点かよ」としか思えず結局好きか嫌いかだったら嫌いよりなわけです。そんな水曜日。今日も頑張って生きていこうね。

今日のテーマ

プロジェクトリーダーのための心理学 基礎編

「基礎編」とあるが「実践編」も「応用編」もe-ラーニングのメニューに存在しない。はて。

心理学の重要性

• プロジェクトにおける心理的問題を説明できる
• 心理学の必要性を説明できる

が目標。

心理学の視点

• 精神分析学
  無意識を解釈する分野。フロイトで検索だ。今回はフォーカスを当てない。
• 認知心理学
  どう解釈するか、という分野。「なんでこれやってないの?」という質問を純粋に理由を訊かれたと解釈するか、責められていると解釈するか、みたいな。
• 行動主義心理学
  パブロフの犬のように「ベルが聞こえたら餌が出てくる」と考えるような行動に付随する分野。反対意見を聞くとつい熱くなっちゃう、みたいな。
• 人間性心理学
  「自己実現」という言葉はこの分野から使われだしたと言われている。人間の肯定的側面に注目した分野。

という全体感がまずある。ここから「プロジェクトで使える」をキーワードにいくつか見ていくこととなる。

チームマネジメント

• 求められるリーダーシップとは何かを説明できる
• 効果的なチームマネジメントとは何かを説明できる

を目標とする。

チームにおけるキーワード

• 雰囲気
• 居心地
• 連携
• 信頼

といったことを念頭においてチームについて考えてみよう。
最近では「心理的安全性」という言葉も聞くようになってきた。

www.dodadsj.com

多分このe-ラーニングでは解説されないだろうと考えているため参考記事を貼っておく。
「チーム vs 課題という考えが根付いているため、遠慮せずに指摘ができる」ということが大事。
決して「これを言うと相手が傷つくかもしれないからやめておこう」ではない。プログラムの前ではみんな平等。忖度という言葉はコーディングされていない。

リーダーシップとは

チームを目標達成に導くよう影響を与える能力のこと。

リーダーシップの特性

• 知性
• カリスマ性
• 決断力
• 勇気
• 誠実
• 謙虚
• 共感
• 適応力
• 馬力

なんてワードが挙げられるだろうか。物語の主人公みたいだな。
決して全部兼ね備えていなければならないわけではない。

リーダーシップのスタイル

• PM理論
• パス・ゴール理論

について見ていく。

PM理論

PM理論 – リーダーシップインサイト

• P(Performance)機能
  目標達成に向けて行動する
• M(Maintenance)機能
  チームの維持 / 強化に向けて行動する

上記2つの機能の高低によってリーダーシップを4つの類型に分類し評価する理論。

高いを大文字、低いを小文字として

• PM型
  目標達成と人間関係両方配慮するリーダー
• Pm型
  目標達成に重点を置くリーダー
• pM型
  人間関係に重点を置くリーダー
• pm型
  目標達成にも人間関係にも消極的なリーダー。リーダー…?

と表す。見たとおりでわかりやすいね。
自分の位置を見極め、これが足りていない、と自覚して行動することが大事。

パス・ゴール理論

パス・ゴール理論 – リーダーシップインサイト

「チームメンバーが業務目標(ゴール)を達成するために、リーダーがメンバーの欲求などの個人要因と組織体制などの環境要因とを関連付け、支持や指導などの道筋(パス)を示し、行動する必要がある」という理論。

リーダーがとる基本的な行動には

• 指示型
  スケジュールを提示し、タスクの達成方法を具体的に指示する。
• 支援型
  部下のニーズに気遣いを示し、サポートを行う。
• 参加型
  決定を下す前に部下に相談し、提案を活用する。
• 達成思考型
  困難な目標を達成し、部下に全力を尽くすよう求める。

の4種類あり、これに

• 環境的条件即応要件
  組織体制やタスク構造
• メンバーの条件即応要件
  経験や能力、ローカス・オブ・コントロール¹

という要素が加わって結果が得られる。
各種要件によって行動を適切に選択することが重要。しっかりメンバーを理解しよう。

効果的なチームマネジメントのために

• ビジョンの明確化
• 効果的なチーム編成
• チームの同期付け

を意識することが重要。

ビジョンの明確化

達成すべき目標を明確にすることでチームメンバーが同じ方向を見るようになる。
そのため、会話にズレが生じにくく、一体感が生まれやすい。

効果的なチーム編成

www.wowcom.co.jp

それぞれのスタイルの人がいればいいよって以前何かで読んだ。

pras.wp-x.jp

そしてチームの人数が多すぎると効率が落ちる。適宜サブチームを作るなどして細かくしよう。

チームの動機付け

vviilloovv.hatenablog.com

あ、○○でやったところだ!! みたいな。
読み直したら割とちゃんと書いてる。私えらい。こまめに自分を褒めよう。

コミュニケーションマネジメント

• 印象形成について説明できる
• 自己開示とアサーションについて説明できる

を目標とする。

コミュニケーションをめぐる問題

コミュニケーションの範囲広すぎ問題。

• メール
• 会話
• ドキュメント

全てのやりとりはコミュニケーションといえる。
まずはあいさつをしっかりするところから始めよう。今の職場は出社したときに挨拶返してくれる上司の方が少ないけれども

コミュニケーションとは

人と人との意思疎通のこと。

雑談も生産性向上には必要となる。個々の事情を知るとか得意分野を知るとか。

言語 / 非言語コミュニケーション

多くの情報は言葉以外の手段でやりとりされている。
おおよそ65%だとか。前どこかの備忘録に書いたな。

ストロークを意識する

相手の存在や価値を認める / 否定するための言動や働きかけのこと。

• 暖かい
• 普通
• 冷たい
• 無視

のように分けられる。
態度に温度差をつけることで「叱っている」「褒めている」のメリハリをつける。

相手に成長してもらう、という観点で見ると「適切に叱る」と「適切に褒める」は同義であるとのこと。なるほど。褒めて褒めてー。

親近効果

後から印象が良くなった方がより良くなったように感じる効果のこと。
不良が子犬を助けるあれ。

自己開示

potect-a.com

自己分析の方法として「ジョハリの窓」がある。
適切に自己分析をし、自己開示をしていくことで「こういう考えで動いているんだな」ということがわかるようになる。結果話しやすくなる。

人には「返報性」という性質があり、自分から情報を開示することで相手も情報を開示してくれるようになる。情報だけでなく感情もそうで、悪意を向けると悪意が返ってきやすく、善意も然り。目には目を…はちょっと違うか。

アサーティブ・コミュニケーション

vviilloovv.hatenablog.com

vviilloovv.hatenablog.com

あ!これ(ry

詳しくは以前書いた。

モチベーションマネジメント

vviilloovv.hatenablog.com

やったよ!!これもうやったよ!!ど真ん中ストレートだよ!!!!

ferret-plus.com

ハーズバーグの二要因理論 – リーダーシップインサイト

よく見る言葉をいくつか。詳細は割愛する。

公平感

keieimanga.net

経営用語があるらしい。うまいこと不公平感を減らしていくように頑張ろう。

期待感

www.motivation-up.com

期待理論 – リーダーシップインサイト

期待していることを伝えると応えてくれるということがある。しっかり伝える、ということが大事。

studyhacker.net

全力で取り組んでもらうためには成功確率が50%くらいの目標が良いとのこと。
50%くらいで何とかなりそうな目標を「少し難しいとは思うが君なら出来ると信じている」みたいにふればやってくれそうと。ふむふむ。

ストレスマネジメント

• ストレスが及ぼす影響について説明できる
• ストレスへの対処法について説明できる

を目標とする。

ストレスとは

とてもざっくり言うと刺激に対する反応のこと。

刺激する側、ストレスの原因となるものをストレッサーと呼ぶ。

ストレス反応が体に現れる場合は体調不良が挙げられ、心に現れる場合はうつ病や適応障害が挙げられる。

ストレスの尺度

diamond.jp

知らなかったけれど尺度があるらしい。
配偶者の死がトップということで、配偶者がいない私には全く関係ないな!!(血涙)

ストレスを生じさせる要因

• 仕事上の要因
  プレッシャーや人間関係など。
• 仕事以外の要因
  育児や介護など。
• 個人要因
  行動パターンや受け取り方など。

心の危険信号

• 勤怠の乱れ
• 元気がない
• 対人関係悪化

要注意らしい。
私の話をするととある毎日終電でかえる系プロジェクトにいた際、1ヶ月毎日「電車遅延のため遅刻」をしたことがあった。
通勤時間が2時間ちょっとだったため、確かにどこかしらで遅れるのだが今思うとアレがストレス反応だったのだと思う。いやあﾀｲﾍﾝﾀﾞｯﾀﾅｧ。

ストレスへの対処

• ビリーフ
• コーピング

について見ていく。

ビリーフ

考え方や受け取り方が感情に影響を及ぼすこと。

www.counselorweb.jp

この「B」が受け取り方(Belief)を表す部分。

ここをポジティブにしてみようよ、とつまりはそういうことである。
まぁ難しいところよね。

コーピング

ストレスを生じさせる要因を特定し、そこから逃げたり対処したりする。

ストレスコーピング 自分でできるストレスマネジメント - J-Stage

このPDFが詳しい。

心のケア

shuchi.php.co.jp

style.nikkei.com

まずは気付き、自分から改善するためにどうするかを考え、行動する。これが大事。

まとめ

では、ここまでのことをプロジェクトに活用するにはどうすればよいのか。

まずは覚えておくこと。知識のインデックスを作っておくことで「おや、この状態は良くないのではないか」ということを早期発見できる。

実際に「あの人にはこうすれば良いのではないか」を考え、実行していけば少しずつ身についていくのではなかろうか。

今回はここまで。
仕事をすること自体がストレス?? まぁそんな人もいるでしょう。
そんなときは「はたらく言葉たち」の文章を改変して遊ぼう。

www.hatakoto.jp

はたらく言葉たち、HTMLを書き換えるだけで自由に遊べる pic.twitter.com/KSAAHzdZSm

— うぃろぅ (@vviilloovv) 2019年6月11日

私からは以上です。

ではまた。

---

1. 原因の所在をどこに求めるか、ということ。自分なのか周囲なのか。↩

【備忘録】 アルゴリズム概論

うぃろぅです。

今日はアルゴリズムについて。「ロジック研修」なるタイトルがついていましたがまぁアルゴリズムのことでしょう。多分。やっていきます。

今日のテーマ

アルゴリズムについて

アルゴリズムとは

問題を解決するための処理手順のこと。

「どのような仕事」を「どのような手順」で行うかを明確にすることが大事。

例えばカップ麺を作るのであれば

1. 水を沸かす
2. ふたを半分ほど開ける
3. かやく等のものがあったら取り出す
4. 先入れのものがあったら入れる
5. お湯を入れる
6. ふたを閉める
7. 指定の時間待つ
8. ふたを開ける
9. 後入れのものがあったら入れる
10. 食べる
11. 美味しい!!

という手順を書き起こせる。これがアルゴリズム。

処理手順

上に書いた例で概ね説明できている気がする。
プログラムは思ったとおりには動かず、書いたとおりにしか動かない。

手順が間違っていてもそのとおりに実行するというわけである。なのでちゃんと手順を作成しようね、というお話。

表現手法

書き方は何通りもあるが、統一された書き方があれば他人に理解しやすく、自分も作業を進めやすい。毎回手法から決めるのは時間のムダになるし。

そこで統一規格を使って流れ図を書くようにすればいいよね、というお話。

基本構造

アルゴリズムは

• 順次構造
• 選択構造
• 反復構造

の3つで成り立っている。

順番に見ていく。

順次構造

上から下へと順番に処理を行い、戻ることがない構造。

いわゆるウォーターフォールみたいなもの。

脱線するけれど今私は新人研修の講師を担当していて、新人くんに自分が書いたフローチャートの説明をしてもらうことがある。
その中の1人に「配列の添え字2の値、いわゆる7に対して~」と説明する人がいる。
いわゆるって「俗に言う」みたいな意味だと解釈していたため、言葉の概念が乱れてもう説明どころではなくてんやわんやになってしまうわけだけれどいわゆるって言わないよね…?

閑話休題。どんどん続けていく。

選択構造

「雨であったら傘を持っていく」「そうでなければ傘をもたない」
というように条件によって行動を出し分けること。
つまりはプログラム言語¹で使うif。

反復構造

繰り返し処理。

「水が沸騰するまで」「やかんを確認する」みたいな。

C言語でのforやwhile。Rubyだとmapとかeachをよく使うかなぁ。JavaだったらStream()が便利で最近forをあまり書いていない。

アルゴリズムの考え方

大枠を捉えてから詳細をつめていく、という流れがわかりやすい。

目をめちゃくちゃ描きこんでから顔の輪郭を描く、という人はあまりいないでしょ。そういうこと。ちなみにそういう手法をとる人もいて、そういった人は私に見えていないものが見えている。ちょっと羨ましいがないものねだりをしても仕方ないため、一般的な手法に頼ることになるのである。日々妥協していこうな。

アルゴリズムの基本

よくあるフローチャートの描き方について。

データ

プログラムは処理に必要なデータを目に見えない領域に保存している。
例として電卓が挙げられていて40 + 10 =と入力するとき、10を入力したときに40の表示は消えているが、=を入力するとちゃんと結果が表示される。これは40や+といったデータを覚えておく領域を用意しているから実現できている。

領域図

上記のデータ格納よう領域をベン図のように表す。ただし領域同士は重ならない。

フローチャート

www9.plala.or.jp

JIS(日本工業規格)に沿って描かれたものをJISフローチャートと呼び、これによって処理の流れを統一規格で表すことができる。

描いていけばそのうち覚えるため、最初から全て覚える必要はない。

アルゴリズム作成手順

1. 完成した状態を考える
2. フローチャートを描く
3. トレースをする
   実際に動かしたときの値の変化を確かめる

が基本。領域は必要なときに確保すれば良さそう。

基本的なアルゴリズム

ここでは

• 加算
• 交換
• 判断
• 繰り返し

について見ていく。

加算

領域に入っているデータを加算する。読んで字のごとく。

領域Aに入っているデータと領域Bに入っているデータを加算し、領域Cに代入する。
領域Aに入っているデータを置き換える場合必要な領域は2つ、領域Cに代入する場合必要な領域は3つ。

交換

領域Aに入っているデータと領域Bに入っているデータを入れ替える。

領域Aと領域Bを入れ替えるためには作業用領域が必要となるため、こちらも領域は3つ必要となる。

1. 領域Aのデータを作業用領域に退避(コピー)
2. 領域Bのデータで領域Aを上書き
3. 作業用領域のデータで領域Bを上書き

という流れ。交換する領域の数より1つ多い領域を確保することがポイント。

判断

条件を判断して処理を振り分ける。選択構造の要。

領域Aと領域Bを比較する。比較する数分の領域があればOK。

繰り返し

条件を満たすまで処理を繰り返し実行する処理。反復構造の要。

ループカウンタを用意するのが大事。繰り返すかどうかで判断の処理も使われている。
あとループカウンタの加算処理(負の値の加算、乗算は指定回数の加算)も行う。

頑張れば繰り返し処理を記述しなくてもどうにかならないではない。現実的ではないが。

配列

データを複数入れる箱。プログラミング界隈ではお馴染み。

細かい解説は…いいか。わかるし。

集計

ここからはこれまでのアルゴリズムを組み合わせた応用。

集計とは

複数のデータを合計する処理。

考え方

集計対象のデータ分繰り返し処理を行い、合計領域に加算していく。かんたーん。

探索

サーチとも。調べ方によって処理時間だったり処理順序だったりが変わってくる。

探索とは

複数のデータの中から目的のデータを探す処理。

探索法

• 逐次探索法
• 2分探索法

の大きく分けて2つある。

逐次探索法

先頭のデータから順に条件を満たすデータを探す。

最初に一致した時点で探索が終了する。

2分探索法

予めソート済みのデータを対象とし、その前半 / 後半のデータを探索する。

ソート済み、という制限つきだがこちらの方が概ね短い時間で探索が終わる。

整列

ソートとも。ならべかえ。QMA的にはなべらえか。

整列とは

複数のデータを昇順 / 降順で並べ替える処理。

整列法

• 基本選択法
• 単純交換法(バブルソート)
• 基本挿入法(インサートソート)

大きく3つらしい。

• マージソート
• ヒープソート
• クイックソート

等に関しては今回は触れないっぽい。

qiita.com

この記事が面白い。

基本選択法

[3, 5, 1, 4, 2]という配列があったとして、昇順で並べ替える場合の処理順は以下。

• 3と5を比較
• 3と1を比較 → 入れ替え
  [1, 5, 3, 4, 2]
• 1と4を比較
• 1と2を比較
• 1の場所が確定
  [*1, 5, 3, 4, 2](*は場所が確定している要素とする)
• 5と3を比較 → 入れ替え
  [*1, 3, 5, 4, 2]
• 3と4を比較
• 3と2を比較 → 入れ替え
  [*1, 2, 5, 4, 3]
• 2の場所が確定
  [*1, *2, 5, 4, 3]
• 5と4を比較 → 入れ替え
  [*1, *2, 4, 5, 3]
• 4と3を比較 → 入れ替え
  [*1, *2, 3, 5, 4]
• 3の場所が確定
  [*1, *2, *3, 5, 4]
• 5と4を比較 → 入れ替え
  [*1, *2, *3, 4, 5]
• 4の場所が確定
  [*1, *2, *3, *4, 5]
• 5の場所が確定
  [*1, *2, *3, *4, *5]

もう書きたくない。計算量はO(n^2)。大変そう。

単純交換法(バブルソート)

隣り合う要素同士を比較して交換する処理を繰り返す。
こちらも計算量オーダーはO(n^2)となるため遅い。

https://wa3.i-3-i.info/word14886.html

ざっくりわかる解説。

基本挿入法(インサートソート)

www.codereading.com

リストに対して値を挿入する箇所を探索する、という処理を繰り返す。

マッチング

まいっちんぐではない。疲れてるのかしら。
私もマッチングして欲しい

マッチングとは

2つのファイルのキー項目を突合せ、その結果によってデータを処理すること。

例えば「在庫ファイル」と「売上ファイル」から新しい「在庫ファイル」を作成する、といった処理。

グループトータル

要はSQLのgroup by。この前書いたからそれでいいかなって。

文字列操作

文字列に対していろいろする。

いろいろって何さ

• 圧縮
  スペース削除。
• 探索
  山口さんの存在箇所を探す等。
• 置換
  田中を田口に置き換える等。
• 挿入
  (株)を会社名の前に挿入する等。

といった感じ。

まとめ

アルゴリズムの基本と、標準的なパターンについて。

今日のは長かったので後半が雑になってしまった気しかない。まぁ大体知ってるし…ということでひとつ。

ではまた。

---

1. C言語やJava、Ruby等を想定。↩