Haskell道 その４

前回からかなり空いてますがHaskellの勉強はゆったりながら続けてますよ。

途中の章はいろいろ飛ばしてファンクターに行きましょう。

ファンクターとは？

ファンクターは文脈を持った箱です。箱の中にある値に文脈を持たせるともいえます。箱なので値を取り出して、加工して、また戻すこともできます。

ファンクターといえば、Maybe型が有名です。
Maybeの定義はこちら。

data Maybe a = Just a | Nothing

ここでの a は箱に入れる値の型です。Java的にはジェネリクス。

Maybe型とは、値に不確実性の文脈を与えます。日本語的には「もしかすると〜かもしれない（失敗していなければ）」という意味です。

ファンクター値に関数を適用

ファンクターの箱の中にある値をファンクター値と呼んだりします。そしてファンクター値に関数に適用するのが fmap です。関数に適用させて得られた値はそのままファンクターに包まれたままです。イメージとしては、箱の中に入れたまま値を関数に適用させる感じです。

試しにMaybeのファンクター値に対して3を掛けてみます。

Prelude> let a = Just 2
Prelude> a
Just 2
Prelude> fmap (\x -> x * 3) a
Just 6

「2かもしれない」ものに対して3を掛ければ、「6かもしれない」ものになりました。ここで重要なのは文脈が維持されることにあります。

ファンクター則

第一法則「idで写してもファンクター値は同じである」

id は 与えられた引数をそのまま返す関数です。Maybeで示すと以下が成り立つ。

fmap id (Just 3) == id (Just 3)

第二法則「gの次にfでファンクター値を写したものと、合成関数f・gでファンクター値を写したものは同じである」

Maybeで示すと以下が成り立つ。

fmap f $ fmap g (Just 3) == fmap (f . g) (Just 3)

まとめると「箱から値を取り出して、与えられた関数を適用して、また戻す」という動作のみが fmap で実装されていればいいことになる。
与えられた関数を無視したり、関数適用以外の余計なことはしないということですね。

【書評】グラフデータベース

グラフデータベース ―Neo4jによるグラフデータモデルとグラフデータベース入門

１年ほどの積ん読を経て、やっと読みきった（遅っ）
代表的グラフデータベースの１つ、Neo4jの開発に関わっている人が執筆している。そのためNeo4jを基準に解説されているが、内容は具体的でわかりやすい。データがどのようにストレージに保存されているのか、どうやって検索しているのかなど、実装についても触れているところがおもしろい。

”関係性”が重要なデータはグラフで表すのが適切である。グラフデータベースはその名の通り、グラフ構造でデータを保存できる。関係性はセマンティックな方向性に関係なく、双方向でストレージに保存されるため、ノード間をどちらの方向にも高速に辿ることができる。ここが一般的なリレーショナルデータベースとの大きな違いで、例えばRDBはインデックスを構築しておくことで高速に検索が可能だが、それはあくまでインデックスを順に辿る場合である。逆方向にインデックスを辿ろうとすると、テーブル全体の検索が必要になるため、とても時間がかかる。そこでいい感じにテーブル設計を行うのも可能だが、複雑になる上、スキーマ変更となると苦労するのは目に見えてる。

グラフデータベースはスキーマレスで変更にも強い。ただしグラフの構成が下手くそだと検索や拡張で苦労する。そこはRDBと同じく経験が必要かな。RDBより優れているというわけではなく、型にはまったときはすごい強力だと思う。スキーマが決まってるデータのまとまりをたくさん保存するにはRDBがいい。

アプリケーション観点ではグラフから最短経路を探索したり、SNSような人の関係性からコミュニティを見つけたり、新たなつながりを予測したりなどに応用できる。なんか使えそうなんだけど、世の中の事象をグラフで表せないか日頃から考察しないとな。それとグラフ理論を勉強したほうがいいなぁ。

プロキシ環境でのIntelliJ IDEA with SBT

プロキシ環境でIntelliJ IDEA with SBTを使う

社内ではプロキシ通さないといけないケースも結構あるでしょう。IntelliJ IDEAでscalaやる場合は、sbtがほぼ必須です。そんなときにどこにプロキシの設定をすればいいのかご紹介。

プロキシ設定する箇所は３箇所

IntelliJ IDEAのプロキシ設定

ここは環境に応じてでプロキシ設定を入れてください。

IntelliJ IDEAからsbt実行時のプロキシ設定

ここはビルドだけでなく、sbtファイル変更時のリフレッシュでも利用されます。
赤矢印のところに「-Dhttp.proxyHost=proxy.bar.com -Dhttp.proxyPort=8080 -Dhttps.proxyHost=proxy.bar.com -Dhttps.proxyPort=8080」などを入力する。

IntelliJ IDEAからsbt起動時のプロキシ設定

SBT Consoleを起動する場合は、ここの設定が利用されます。
赤矢印のところに「-Dhttp.proxyHost=proxy.bar.com -Dhttp.proxyPort=8080 -Dhttps.proxyHost=proxy.bar.com -Dhttps.proxyPort=8080」などを入力する。

社内公募制度における上司の拒否権

「ソニー 失われた20年」に社内募集では上司に拒否権があると言及されていました。
この拒否権、思うところもあるので少し書いておきます。

制度内容

社内公募制度とは、社内人材募集に応募し、異動先との面接で合格すれば異動ができます。一般に、現在の職場の上司に拒否権はなく、応募の秘密も守られるとされています。私の会社にも上述のルールで制度が存在します。

職場の上司には拒否権がある

私の会社でも表向きは上司に拒否権はないとされていますが、実際はあります。
そして拒否権がある以上、実際に行使されることはあります。

拒否権の行使は分かる

実際にあった話です。
異動希望者が面接で手応えがあったにも関わらず不合格の通知を受けました。せめて落ちた理由を知りたくて異動先に直接問い合わせたところ、「合格通知は出したはずですが」という回答をもらいました。拒否権が行使されたわけです。その後、上司との人間関係が急速に悪化したことは言うまでもありません。

もし落ちたら直接問い合わせてみるのも手ですが、人間、知らないほうがいいこともあります。

またこんな話もあります。
部下の公募合格を知った上司は、部下に拒否権を明かしたうえで現在の職場に留まってもらえないか話し合いを持ちかけました。結局、部下は異動することになりましたが、話し合いで解決しようとする姿勢は間違ってはいないと思います。

拒否権の無言の行使は諸刃の剣ですね。

それでも社内公募制度には意義がある

職場が自分に合っていない人や、新しい挑戦をしたい人には、十分意義のある制度だと思います。大事なのは自分の意思と覚悟なのですから。

【書評】ソニー 失われた20年

ソニー 失われた20年 内側から見た無能と希望

ソニーの栄枯盛衰を中から見た筆者が、凋落のはじまった出井体制以降を様々な視点から批評するという内容です。愚痴・悪口のような文章にもソニーを思う気持ちがあり、筆者のソニーへの憎愛が感じられる。社員１人の主観ではありますが、メーカーの凋落を知るにはいい本です。
私もメーカーの端くれの人間、業界全体が斜陽にいるなかいくつか共感する部分もあります。

組織の中心は人である

ソニーの凋落はトップの愚策が招いたと断言されています。確かにきっかけはそこでしょう。しかしそれを増幅させたのは他ならぬソニーの社員、”人”です。
私がこれまで会社で出会った管理職の多くは制度・ルール・文化を以って人をマネージメントしようとしていました。秩序は必要です。しかし本人の主体性を窄めてはならない。ここのバランス感覚がどうにも制度・ルール・文化に偏っているのです。組織の中心は人であることを常に考える必要があります。制度・ルール・文化は人が変化・創造するものです。先にあるものではありません。

技術の軽視

これまた多くの管理職は、押しも並べて開発の現場に疎い。我々はマネージメントする立場だ、君も早くマネージメントを覚えたまえという態度。外注をコントロールできるのは外注より技術に詳しい人だけです。でないと、納品物の”質”をどうやって担保するのでしょうか。今のところ、ぎりぎり子会社がそれを担っています。しかし子会社も外注を使って自分たちで手を動かさないわけですから、技術の空洞化は止まらないのです。
私はまだ開発の現場に明るいほうです。具体的な”質”の問題を指摘すると、最近はなかなかそういう人がいなくてとても助かるよ、と言ったりします。助かるよとか言う前に自ら学んでなんとかしようと思わなかったのでしょうか。または自分よりできる後進の育成をしてこなかったのでしょうか。問題から目を背けているか、そもそも問題と思っていないのか、私にはわかりません。

人材育成の不備

いつだって学びは自分自身でやるものです。主体性を以ってPDCAをまわしながら成長するべきなのに、高額な一回こっきりの研修で済まそうとしています。伸びる人は継続して努力する人です。努力の方法や方向はなんであれ、会社はそれを応援しなければ、どちらも成長しません。
管理職は”自分を超える”後進を育成することを考えてください。自分と同じレベルがゴールでは進歩がありません。保身のために育成を怠ると、会社が凋落し、自身の給料を下げることになります。

政治の重要性

日本のメーカーがコンシューマ向け事業から撤退し、インフラなどのB2Bビジネスを中心に据えています。企業向けの大きな仕事や、とりわけ公的市場となると”政治”がものをいいます。技術だけでは生き残れない。ここは私がまだまだ未熟なところです。

諦めない

この世にユートピアはありません。あるのは常に問題と向き合う自分です。諦めるにはまだ早い。

Xcode や iOS SDKをアップデート後にやること

Xcode や iOS SDKをアップデートすると、既存のプロジェクトのビルドでエラーが出ることがある。
エラーの例）
redefinition of module 'Compression'
redefinition of module 'Darwin'
could not build Objective-C module 'CoreFoundation'

これはキャッシュやビルドしたオブジェクトが残っていることが原因。

キャッシュ削除

$ rm -rf ~/Library/Developer/Xcode/DerivedData/*
$ rm -rf "$(getconf DARWIN_USER_CACHE_DIR)/org.llvm.clang/ModuleCache"
$ rm -rf ~/Library/Caches/com.apple.dt.Xcode

Clean

Xcodeでプロジェクト開いたら、Shift + Command + K でCleanする。

参考

stackoverflow.com

Project Euler

Project Eulerおもしろいですね！　はまっちゃって最近ずっとやってます。
言語はScalaで。去年勉強したHaskellの知見をScalaに取り入れてみるって目的もあります。

Project Eulerの各設問の掲示板には各々実装例載せてたりするんですが、だいたいCかPythonかJava、たまにHaskell。Scalaは皆無、残念だ。
J言語の実装例は変態すぎてついていけません。

projecteuler.net