遠く離れたところで昔の夢が叶ってしまった話

なんだか久しぶりの投稿です。前の記事を投稿してからしばらくかなり忙しい日々が続いており、仕事の進捗は出ているのですがブログの進捗がお亡くなりになっていました。逆よりいいと思うことにします。

ところで、「かなり忙しい日々」の中に実は「雑誌への記事の執筆」というものが入っておりました。先に結論をいうと、WEB+DB PRESS Vol.91に「[すぐに使えてずっと役立つ!]データ構造の基礎知識 ── 配列、リスト、ハッシュテーブル、木構造」という特集記事を書かせていただきました。なんと!特集記事です。まじかよ。

www.amazon.co.jp

記事の内容について

WEB+DB PRESSは、プログラマとして働き始めてからほとんど毎号購入して読んでいる雑誌で、そのような雑誌の特集を執筆させていただけたことは本当にありがたいことだと感じていますし、とても嬉しく思っています。内容としてはデータ構造と計算量についての内容で、知っているひとから見たらたいしたことは書いていないのですが、なんとなくしか知らなかった方や、知っているけど日々の業務となんだか結びつかないなあという感じになっている方、あるいはデータ構造についてほとんど知らないけど興味はあるというような方にとって、10年20年先までちゃんと活かせるような内容の記事になったと自負しております。良いと自負できるものが書き上げられたのは、編集の村下さんによるところが大きいです。ありがとうございます。ぜひ読んでいただければなと思います。

壮大な蛇足、またはこの記事の本文

わたしは様々なところで「文系プログラマ」を名乗っていますが、その理由として、自分が文学部出身である、ということがあります。わたしはわたしなりのありかたで自分の仕事に誇りを持っていて、プログラマとして一流でありたい、といつも思っています(実力が追いつかないのが悲しい!がんばるしかない)。なので、文系卒である、ということを自分の無能の言い訳にだけはしたくないと思っているのですが、その一方で、大学時代に文学部で学んだことがわたしの人格の半分以上を作り上げているという実感も持っています。プログラマであることと、文学部卒であることは、わたしのアイデンティティにおいてどちらも重要なことです。

そんなわたしですから、もちろん、「本」というものに対してはそれなりの思い入れのようなものがあります。文学部にいたときには、漠然とではありますが「商業誌になんらかの形で関わりたい」という思いも、もちろん持っていました。そんな中で、大学の友人のうち何人かは実際に編集者としてバリバリ働いていたり、いわゆる「批評家」としてそれなりに名前を売ってたりとかするんですが、やっぱりそういう友人たちは学生のころから彼らのやりたいことに対して真摯であり、真剣でした。わたしは彼らとは違い、プログラミングの世界に進んだのですが、これはある意味では「本の世界」との決別でもありました。「いつか商業誌になんらかの形で関わりたい」なんて思っていたことは、忘れたわけではないけれど、「そんな思いもあったなぁ。その思いに突き動かされてやってきたことは今直接に役に立ってはいないけど、なんだかんだいって自分の大事な一部分になっているよなあ」くらいの感じで、ありていにいえば「終わった夢」としてわたしの中に眠っていたものでした。

ところが、です。ひょんなことから技評の村下さんにお声がけいただき、「商業誌に自分の書いたものが活字になって載り、それが日本中の書店に並ぶ」という、終わったはずの夢が、当時思っていたのとは全く異なるルートから実現してしまいました。これは本当に青天の霹靂というか、人間万事塞翁が馬というか、瓢箪から駒というか、運と縁に恵まれたと思っています。

わたしはよく「人生9割は運と縁」と言ってるのですが、本当に自分の運と縁が最高すぎて、このままどっかで大暴落が待っているのではないかと不安な日々です。話がとっちらかっている。なんの話なんだこれは。とにかく、昔の夢が「終わった夢」になったあとも、別のことに一生懸命になってると、運と縁がからんで急に変なところからぽっとその夢がまた芽吹いたりするのだなあ。という感じです。

最後にもう一度内容について

もう一度言いますが、データ構造について、なんとなくしか知らなかった方や、知っているけど日々の業務となんだか結びつかないなあという感じになっている方、あるいはデータ構造についてほとんど知らないけど興味はあるというような方にとって、10年20年先までちゃんと活かせるような内容の記事になったと自負しております。ぜひ!読んでやってください。

あと、蛇足っぽいですが、記事書いてみて思ったんですけど、ものすごい量と質の知識、知恵を、常にわかりやすく読者に伝え続けている結城先生って化け物だと思いました。もともと結城先生のことをめっちゃ尊敬していましたが、自分で記事一本でも書いてみて尊敬が畏怖に変化しました。結城先生、そのうち学問の神様みたいな感じの祀られ方するんじゃないのか……。

www.amazon.co.jp

既存のクラスをScalazで定義されている型クラスのインスタンスにするの巻

この記事はScala Advent Calendar 2015(Adventar)の9日目の記事です。

Scalaには型クラスのための仕組みがあるぞ!

Scalaには、型クラスを実現するための仕組みとしてimplicit parameterという仕組みがあります。これとimplicit conversionを組み合わせることによって、オーバーロードやinterfaceでは実現できないようなオープンな演算の定義と安全性を両立させることができます。

このあたりの話は http://nekogata.hatenablog.com/entry/2014/06/30/062342 などを参照してください。

Scalazとかいう怖いライブラリもあるぞ!

Scalaの怖いライブラリの代表格として、Scalazというものがあり、ここでは様々な便利な型クラスが定義されています。たとえばそのなかのひとつに「Order型クラス」が存在します。

このOrder型クラスは、「順序があるよ」という性質を表した型クラスになっており、scala標準の型でも、Stringなど様々なクラスがこの型クラスのインスタンスにされています

また、Order型のインスタンスになることで、implicit conversion経由で "<" や ">" などの便利メソッドが使えるようになります

自分で手出しできないライブラリを型クラスのインスタンスにするぞ!

たとえば JodaTime を利用しているとき、AbstractInstantなインスタンス を > や < で比較できたら便利だなー、などと思ったとします。AbstractInstantな型をOrder型クラスのインスタンスにしてしまえば実現できそうですね。実際にやってみましょう。

まずはOrder型クラスの定義を見に行きます

見てのとおり、orderメソッドだけ実装されていないtraitがその実態です。ということは、orderメソッドを実装したAbstractInstantOrder[A <: AbstractPartial] extends Order[A]なオブジェクトへのimplicit conversionを定義してやれば、DateTimeなどのAbstractInstantのサブクラスのインスタンスを < や > で比較できるようになるはずです。(このへんの理屈がわからない場合は、しつこいようですが http://nekogata.hatenablog.com/entry/2014/06/30/062342 を参照してください)

自分でがんばってobject AbstractInstantOrder[A <: AbstractInstant] extends Order[A]を定義して、それへのimplicit conversionを定義してもいいのですが、Order.scalaを読んでいたらこんな便利なメソッドを見つけました。order[Nyan] {(a, b) => ???}としてやれば、new NyanOrder extends Order[Nyan]{ def order(a: Nyan, b: Nyan) = ??? }を返してくれる便利なやつです。こいつとimplicit conversionを組み合わせてAbstractInstantな型をOrder型クラスのインスタンスにしてやると、こんなかんじになります。

object JodaTimeOrder {
  implicit def JodaTimeInstantOrder[A <: AbstractInstant]: Order[A]  = order { (a, b) =>
    if (a.isBefore(b)) scalaz.Ordering.LT
    else if (a.isEqual(b)) scalaz.Ordering.EQ
    else scalaz.Ordering.GT
  }
}

これで、JodaTimeのAbstractInstantなクラスすべてを、Order型クラスのインスタンスにすることができました!使うときには、以下のようなかんじになります。

import JodaTimeOrder._
import scalaz.Scalaz._

if (dateTimeInstanceA < dateTimeInstanceB) {
  // Bのほうが後の日時
} else {
  // Bのほうが後の日時ではない
}

自分で書き換えることのできないようなクラスも、ちょっとしたグルーコードを書いてやることで型クラスのインスタンスのしてやることができましたね!

最後に

既存のクラスをScalazの型クラスのインスタンスにする例を見てみました。Scalazのコードを読みながら「なるほどこうやればいいんだな」みたいなかんじでやっていけばできることではあるのですが、「わざわざコード読まなくてもここに書いてあるよ」みたいな情報を知っているひとがあればぜひ教えてください。

YAPC::Asia 2015 で発表しました #yapcasia

Perlで学ぼう!文系プログラマのための、知識ゼロからのデータ構造と計算量」というタイトルでYAPC::Asia 2015 で発表してきました。

yapcasia.org

http://yapcasia.org/2015/talk/show/9f7059dc-003c-11e5-a00c-89c77d574c3a

上記のリンクからスライド、動画(そのうちアップロードされるでしょう)が見れます。

スライドはほとんど説明のための図にとどまっており、口頭でいろいろと説明したので、当日入場制限で入場できなかったとか、チケットが手に入らなくて来られなかった方はぜひ動画を見ていただけると幸いです。

わたしはプログラマとして活動し始めてから、Perlコミュニティのひとたちが対外的に発表してきたトークや資料、ブログ、あるいは直接のコミュニケーションなどで、直接、間接にかなり助けられてきていて、そのおかげで今の自分があると思っています(まだまだ学習すべきことは多く、これからもお世話になります!)。

そんななかで、「コミュニティへの恩返し」ってなんだろう、と思ったとき、ハッカーとしては1流ではないけれど、「わかりやすく説明する」とか、「参入障壁の低い感じのつながりをつくっていく」いう自分の得意分野でなにかやればいいんだ、と思い、ブログでなんか書いたり発表したりというのをやってきました。

懇親会でお話をさせていただいた方々やtwitterでの反応などを見ると、なかなか上々な反応をいただいていて、今回の発表では、初めて「それなりにコミュニティに恩返しができたかなぁ」という実感を得ることができました。YAPC::Asiaは今年でひと段落ですが、そういう節目の年にこういう機会を与えていただいて、スタッフの方やソーシャルボタンで応援していただいた方や当日発表を聞きに来ていただいた方への感謝の念でいっぱいです。

ありがとうございました!

プログラミングの「抽象化」ってどういう意味で、なぜ必要なのか

<追記>いろいろ反応あってたしかになーって思いましたが、ここで説明されてるのは「汎化」とか「パラメタライズ」としたほうが正しいですね。抽象化というと、一塊の手続きをブラックボックスにして、実装を隠蔽する面のほうが正解に近いです。でもまあそこを差し引いて読んでいただければ、それなりに有用ではある記事だと思うので、このまま残しておきます</追記>

プログラミングに限らない話かもしれませんが、ふだんの生活で触れないような概念というのは、一度わかってしまえば便利なんだけど、どうしてもとらえどころがない、というようなことが多いと思います。プログラミングにもそういう概念はたくさんあって、わたしのような凡人は新しい概念にぶち当たるたびに苦労しています。今日はそんな中で「抽象化」という言葉について、「昔の自分にこうやって説明してあげたかったな〜」という説明をします。

プログラミングを学んでいく中で、「とりあえず処理が書ける」というところから一歩進んで「良い設計ってなんだろう」ということを考え始めたとき、いきなり「抽象化」という言葉が出てきて面食らったことはありませんか?わたしはあります。「抽象化ってこういうことだよ」という説明のないまま、「抽象化」の事例をたくさん見ることで「うーん抽象化ってなんとなくこんな雰囲気……」みたいな感じでお茶を濁す感じになる事例というのはけっこう多い気がしています。

そんなふわっとした「抽象化」という言葉ですが、わからないときは逆の言葉の意味を考えて見るといいでしょう。「抽象的」の反対は「具体的」ですね。つまり、「抽象化」というのは「具体的じゃない状態にする」ということだと思えばいいでしょう。まだちんぷんかんぷんですね。例で考えてみましょう

たとえば、「user_id:1のユーザーの所持金額のうち50Gを、user_id:2のユーザーに移行する処理を作ってくれ」という指示が出ているとします。これを愚直に実装すると、以下のような感じになるでしょうか(トランザクションとかそういう話は今回の話に直接関係ないので無視します)。

def transfer_gold
  # user_1 から50G引いて
  user_1 = User.find(1)
  user_1.gold -= 50
  user_1.save!

  # user_2に50G足す
  user_2 = User.find(2)
  user_2.gold += 50
  user_2.save!
end

このコードを、「具体的じゃなくして」行ってみましょう。

今はuser_id:1のユーザーとuser_id:2のユーザーという「具体的な」ユーザーを直接コードで書いていますね。ここの「具体性」をなくしてみましょう。

def transfer_gold(from_user_id, to_user_id)
  user_a = User.find(from_user_id)
  user_a.gold -= 50
  user_a.save!
  
  user_b = User.find(to_user_id)
  user_b.gold += 50
  user_b.save!
end

はい、ユーザーidを引数で与えるようにしました。これで、コードからは「具体的なユーザーid」を排除して、ちょっと「具体的じゃないコード」になりましたね。

もうちょっと具体性を排除していきましょう。今は50Gという具体的な金額がまだコード上に残っています。これも引数で渡してあげましょう。

def transfer_gold(amount, from_user_id, to_user_id)
  user_a = User.find(from_user_id)
  user_a.gold -= amount
  user_a.save!
  
  user_b = User.find(to_user_id)
  user_b.gold += amount
  user_b.save!
end

はい。これでコードからはさらに「具体性」がなくなりました。こんな感じで、「具体的な値」とかをコードから排除していってコードの具体性を減らす行為全般を「抽象化」と呼ぶと考えて良いでしょう。

ところで、具体的な値をコードから追い出したことによって、なにが起こったでしょうか?具体的な値がベタ書きされていたときと違って、コードが「いろんな値に対応するようになった」ということが言えるでしょう。引数に10Gとuser_id:3とuser_id:4を渡せば、user_id:3からuser_id:4に10G移行することもできるし、20Gとuser_id:5とuser_id:6を渡せばuser_id:5からuser_id:6に20G移行することもできます。

さて、いいことづくめのように見える抽象化ですが、今度は「そのコードを使う側」の視点から見てみましょう。もしプログラムに具体的な値がベタ書きされていた場合、使う側はなにも考えずにそのコードを実行すれば良いだけです。一方、抽象化されたコードの場合、使う側が「どのユーザからどのユーザにいくら渡すのか」ということを判断しなければなりません。

そこに注目すると、抽象化というのは、具体的な値としてなにを使うのかという「判断の責任」を「そのコードを使う側」に押し付けることでもあることが見えて来ると思います。

言い換えます。抽象化されていない具体的なコードでは、メソッドの側に「具体的な値はこれとこれ!」ということが書いてあるので、呼ぶだけで具体的に意味のある処理が実現されます。一方、抽象化されたメソッドでは、メソッドを呼ぶ側がそこに「具体的な値」を与えることではじめて具体的で意味のある処理が実現されます。

まとめると、抽象化によって、使うときにいろんな値を突っ込んで使うことができ、柔軟になるというメリットを得る一方で、使うときにその都度使う側が「どんな値が適切なのか」ということを判断する責任を負うというデメリットも負うことになるわけです。

note:ところで、さきほど「具体的な値」「とか」 をコードから排除する、と書きましたが、とか、というからには、値以外のものも抽象化することが可能です。抽象化のレベルが上がってくると、値だけではなく、たとえば計算内容そのものを抽象化したり(高階関数やストラテジーパターンなどがそれを実現します)、型を抽象化したり、というパターンも出てきます。しかし、どんな抽象化も、「具体的な<なにか>」をコードから排除して、そこを「入れ替え可能なもの」にするという点では共通しています。「抽象化」という言葉がでてきたときには、「ここではどんな具体的なものをコードから引っぺがしているのだろう」と考えてみると、すっきりと理解できることが多いでしょう。

さて、以上の議論を踏まえた上で、「世界一抽象化されたコード」というのを今から書いてみましょう。一瞬でかけます。

# nop

上にあげたものがそうです。つまり、「なにもしない」というコードこそが、世界一抽象化されたコードです。冗談を言っているわけではありません。抽象化とは「具体的な値や処理などをなくして、使う側が必要なそれを選べるようにする」ものでした。では「はい、まったくなにも書かれてません。ここに必要な処理を書いていってください」というのが、究極に抽象化されたコードになるのはなにも変なことではありません。こんな落語みたいなことを言ってなにが主張したいのかというと、それは「抽象化すればいいってもんじゃない」ってことが言いたいのです。

抽象化はあくまで「具体的な判断を遅らせることで柔軟性を得る」ためのものです。コードが具体的な処理を行うためには、必ずどこかでその「具体的な判断」をしなければなりません。冒頭の例ならば、必ずどこかで引数に具体的なuser_idや金額を与えなければならないわけです。

そうである以上、プログラムの設計では「どこを抽象化するのか」「どこまで抽象化するのか」という判断が必要になってきます。しかし、「抽象化」のメリットデメリットを理解した今なら、その判断の一助になるものさしを持っています。それは、「具体的な判断は誰がするべきなの?」という視点です。

たとえば最初にあげた抽象化の例ですが、アプリケーションの仕様上、本来はお金の移行というのはありえない処理で、事故処理のためにめっちゃ特別に今回限りのスペシャル対応としてたった一回だけ行われる処理なのであれば、抽象化されてないメソッドのほうが、「使う側の負担」は少なくなりますね。なぜなら、使う側が「えーっと今回の事故処理ではだれからだれにいくら移行しなきゃいけないんだっけ」ってことを考えなくていいからです。一方で、どんなユーザーからどんなユーザーにいくらでもお金の移行が行われ得るような仕様のアプリケーションならば、移行が行われる都度「だれからだれにいくら」という判断をしなければいけないので、抽象化して「メソッドを使う側」にその判断をしてもらうべきでしょう。

かように、「正しい抽象化」というのはアプリケーションに求められている性質によって異なってきます。プログラムの設計とは、「このアプリケーションにはこういう性質があるから、だからここは抽象化して「使う側」に判断の責任を持ってもらおう、逆にここは具体的に書いておこう」ということを考えることでもあると言えるでしょう。

抽象化するための方法はいろいろあります(メソッドにして引数で渡すようにするとか、デザインパターンとか、型クラスとか……)が、それはあくまで「実装方法」であり、設計そのものではありません。実装方法をたくさん知っていることは武器にはなりますが、実装方法を知っているからといってむやみやたらに抽象化をしまくったとしても、それは単に責任の所在がいろんなところにとっちらかってて使いにくいプログラムにしかなりません。ギターの早弾きができることは武器になりうるけど、音楽的に意味のない早弾きは曲芸でしかないみたいなもんです。抽象化の方法をたくさん知った上で、アプリケーションが求める抽象化を正しく見出せるようになりたいものですね。

ブックマークコメントでいろいろ補足や指摘されていて、もっともな話が多いので、そちらも参考にしてください。とくにこのコメントは「まじでそのとおりですね!」という感じです。

プログラミングの「抽象化」ってどういう意味で、なぜ必要なのか - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

これは抽象化の役割のうちパラメタライズに注目した説明。抽象化には他にも様々な問題に共通する構造を取り出すという役割があり、それは時に思考の足場や指針を与える。nopの例えが変なのは後者を考えてないから。

2015/08/05 09:00

なお過去に書いた抽象化の記事として適切に抽象化されたコードとはなにかって話というのがあり、こちらではこの記事で触れることができなかった抽象化の側面について触れています。よろしければそちらもお読みください。

宣伝

8/20,21,22に開催される、プログラマフジロック(あるいはプログラマの夏コミ)とも言えるYAPC::Asia 2015 にて、Perlで学ぼう!文系プログラマのための、知識ゼロからのデータ構造と計算量という発表をします。今回の記事の内容とはまたちょっと趣が変わって、もうちょっと実装よりの話になりますが、なるべくわかりやすい発表を心がけますので、気になった方はぜひ聴きに来てください。

なお、すでにチケットは完売しておりますが、なんとイベントレポーターになるとタダでYAPCに参加できるという裏技が存在しております!ぜひご検討ください。

YAPC::Asia 2015で喋ることになりました

8/20,21,22に開催される、プログラマフジロック(あるいはプログラマの夏コミ)とも言えるYAPC::Asia 2015ですが、無事トークが採択され、発表させていただく運びとなりました。詳細は下記より。

http://yapcasia.org/2015/talk/show/9f7059dc-003c-11e5-a00c-89c77d574c3a

自分が「これ聴きたいなー」と思うようなトークも不採択になったりしており、これでマズい発表をしたら各方面に対して顔向けできない感じで、プレッシャーも大いに感じていますが、まずは素直に嬉しいし、聞きに来てくれたひとになにか良いものを残せるようなトークをしたいと強く思っています。

ところで、スピーカー枠をゲットした都合により、個人スポンサーチケットが一枚あまっております。「しまったヤプシーのチケット買い忘れた!!」というかたは、

  • 必ず参加すること
  • ヤプシーを最大限楽しむぞ!!という気持ちを持って臨むこと
  • ノベルティはわたしにくれること(タンブラーほしい……)
  • 現地でわたしとコミュニケーション取ってくれること

を条件に、無料でチケットをお譲りします。ツイッター、ブログコメント、どんなチャンネルでもかまわないのでわたし宛にメッセージやメンションなどをください。なお、応募多数の場合は厳正な抽選の上一名様にお譲りします。当選発表は発送(発送とは……)をもってかえさせていただきます。

まだだれからも「くれ」って言われてないよ!今がチャンス!!

追記、譲り先が来ましました。みなさんヤプシー楽しみましょう!!

「地方」のIT勉強会は参加者がもっと外に向かってアピールしてほしい

わたしの立ち位置

今は東京都でプログラマをやっているが、3,4年くらい新潟県プログラマをやっていて、当時は地元のコミュニティによく顔を出していた、という人間です

以下本文

少なくともわたしが知っている限りの話です。新潟県には優秀なプログラマが一定数います。そして、最近はコミュニティがそういうプログラマにリーチしつつあって、交流は活発になっていると感じます。でも、参加者がレポートとかを対外的に書いたりはあまりしてないように思えます。これはとてももったいないことです。優秀なプログラマを喉から手が出るくらいほしがってる「都会」の企業が、「なんかあの地域めっちゃプログラマたちの活動活発だな、開発拠点作る意味あるかも」って思ってくれるくらいまで、「俺たちプログラマとして楽しいことやってるぜ!」ってのをアピールしていったらいいのにな、と思うんですよ。

これは多分新潟に限らないのではないかと思うんでけど、多分、力を持て余してるプログラマは全国各地に散らばっています。そして、優秀でやる気のあるひとから、どんどん東京の会社に吸い取られていく実際があります。新潟で出会ったプログラマのうち、何人もが「東京に転職することにしました」と言って新潟を去っていくのを見てきました。それはべつに悪いことだと思いません。一方で、家族の都合やいろいろな都合から、地元を離れることが難しいひとたちが、くすぶり続けているようなシーンもたくさん見てきました。

ここから先は単にわたしの願いであり、「そうあるべきだ」という話ではないですが、地元のプログラマ同士で切磋琢磨するのはとても楽しかったし、実際楽しいです。でも、そこからさらに「ほらほら俺たちこんなに楽しいことやってるよ!」というのを、参加者ひとりひとりが外に向けて発信して行ったら、優秀なプログラマと出会いたいと思っている「外の」ひとたちと、地元のひとたちになにか新しいつながりが生まれる可能性は増大すると思うんです。だから、コミュニティや勉強会の主催者だけではなくて、参加者がもっと、「俺たちめっちゃ楽しいぜ!!」を発信してくれたらいいのにな、と思っています。

手始めに、先週末のNDSに参加したひとはツイッターだけじゃなくてブログでレポートとかを公開しようよ!単純にわたしが読みたい!!!

YAPC::Asia 2015 のプロポーザル「文系プログラマのための、知識ゼロからのデータ構造と計算量」

2015年、8月20日から22日までの三日間、プログラマの夏フェスことYAPC::Asiaが今年も開催されます。わたしもトークを応募した。

YAPC::Asiaってなに?

YAPCとは? | What is YAPC?

世界最大のYAPCが最後の大花火をぶちあげにもどってきました!YAPCはYet Another Perl Conferenceの略で、Perlに関するカンファレンス・・・いや、お祭りです!Perlだけに限らず、様々な分野のギーク達が集まり技術の話と楽しさに満ちた三日間のお祭りが開かれます。Perlに関連する事に興味がなくとも心配する必要は全くありません、YAPC::Asia Tokyo 2015は技術者であれば誰でも楽しめるカンファレンスです。

今年も様々なゲストを集めて熱いトークが交わされます。世界中のギーク達がどんな事を今を考えているのか行っているのか、是非皆様も体験しに来て下さい!

概要 / ABOUT | YAPC::Asia Tokyo 2015

どんなトークを応募したの?

yapcasia.org

こちらに詳しいですが、ブログにも同じ内容を載せておきます。

概要

「データ構造やアルゴリズム、計算量について知っておく事は、プログラマにとって、とても大切なことです」といろんなところで言われています。一方で「そんなの知らなくっても降ってくるお仕事は片付けられるもんねー」というのも、まあ、たしかにそうですね、という感じがします。でも、データ構造と計算量のことを知らないでいると、カジュアルに下手なインデックスを貼ってしまったり、単純な集計のはずなのに6時間動き続けて返ってこない……のようなスクリプトを書いてしまったりすることがあるので、やっぱり、プログラマにとってデータ構造やアルゴリズム、計算量の基本を知っているというのは、とても大切なことなんじゃないかな、とわたしは思っています。少なくとも、「計算機の気持ちになってコードを読み書きする」ときの助けになることはたしかです。

でも、やっぱり計算量の話とかって、とっつきづらいですよね。「でもさー。わたし、文系なんだよね。なんか計算量がどうこうとかいうひとたちって数式でしゃべるじゃん。log とか? アクセスログかよって思う。日本語でしゃべれって感じだよね」みたいな。わたしも文系卒なので、そんな気持ちはよくわかります。というか、わたしはそう思っていました。この発表は、そんなひとたち(つまり、昔の自分)がなるべく苦痛を感じないようにデータ構造と計算量に触れ、その後の独学独習の助けになるような基礎的な知識をつけてもらうことがゴールです。

アジェンダ(仮)

  • 連結リスト
  • ハッシュテーブル
  • B+ツリー
  • スキップリスト

以上のデータ構造について見ていきながら、時間計算量と空間計算量について、なるべく平易に、しかし嘘をつかないように、実際の事例を交えながら学んでいきます。

対象となる方

  • コードを書くことはできるけど、「このデータはメモリにどう展開されるから〜」とか言われるととたんに置いていかれるひと
  • アルゴリズムやデータ構造などに対して苦手意識が強い

対象とならない方

  • 上記のデータ構造をすでに理解できているひと

もし気になるようでしたら、ぜひ上記リンクからトークのページへ飛んで、各種シェアボタンで応援してくださると嬉しいです。

see also

uzulla.hateblo.jp