技術をかじる猫

適当に気になった技術や言語、思ったこと考えた事など。

なんかもう紹介せざるを得なかったScala記事「バカ向け言語Scala」

まともにモジュール化設計もできていない保守不能糞コードの設計者を「エリート様」と皮肉って、「バカな私は、シンプルさを求めたScalaを使う」と言う記事。

センスに溢れて「いいぞーもっとやれー」と応援したくなってしまいました。

rirakkumya.hatenablog.com

では、ここで真面目に補足もしておきたい。

シンプルに書くのはバカにはできません

シンプルに書けるよう設計するというのは、実は相当難しい。
以前紹介した「ReadableCode」なんて書籍が書けてしまうくらい、可読性を高く、可能な限り多くの人が保守できる設計というのは実はかなり難しい。

KISSの原則 - Wikipedia

では逆に「シンプルにしていない者こそバカ」と言い切ってる。

タイトルに反してScalaはバカ向けなのか?

もちろんここの「バカ」は 「Coboler のようなエリート様」と対比するための皮肉なのは百も承知だが、それを脇に置いておいたとしても、Scala を真面目に理解してそれらしく書くのはきっとバカには無理じゃないかと思う。

よく入門書として使われている、コップ本 なんかは有名なのだが、これもなかなかの厚さを持っている。

つまり学習コストはそれなりに高い。

  1. JVM システム同様に、オブジェクト指向を強要する
    何を今さらと言われるかも知れないが、業界で働いていても「オブジェクト指向の3点セットは?本質は?」で躓く人は結構多い。
    技術ブログ書いてたり、勉強会行く人間には「何を今さら」なレベルなのだが、現実問題一つのハードルと考えていいハズだ。
    まして ScalaJava よりもオブジェクト指向が徹底している。
  2. 関数型の思考もそれなりに要求する
    関数型の思考で最たるものは、「関数」が第一級オブジェクトであるという考え方だ。
    「関数というオブジェクトを作成して、定数、変数、引数、返値にしたうえ、その先で実行できる」という事を理解すること。
    実は JavaScript もその意味では関数型なのだが、この思考も一つのハードルになる。
  3. 豊富なコレクションメソッド
    どちらかというと関数型言語の真価の一端といった方がいいかもしれないが、
    Scalaコレクションメソッドメモ(Hishidama's Scala collection method Memo)
    使いこなせ…というのは酷だとは思うが、何かに触れ「そういやこんな事ってできたような…」と思って調べようと思えるくらいの全容把握にどれくらいかかるか?

基礎レベルですらこれだ
また、省略可能な規則の把握、DSL の設計等も含めて、果たしてそれがバカにできる事だろうか?

それにより、海外の企業向けソーシャルを行っていた Yammer (現Microsoft傘下)は、Scala の採用をやめてJavaに移行し始めた。

言語としてのScalaは興味深い特徴を持っている。しかし、とても複雑な言語でもある。 Scalaがもたらす概念や実装に加えて、自然なScalaを書こうとする文化がある。これを突き詰めるとある時点でベストプラクティスが現れる。それは、コミュニティを無視することだ。 後になって気付いたことだが、私はScalaを学ぶこと(教えること)の難しさと重要さを低く見積もりすぎていた。というのは、Scalaの経験のある開発者を雇うのは不可能だからだ。これは思ったよりも遥かに大きな問題だ。

内容は 2011 年のもので、今と情勢が違うのは間違いないが、要するに

  • 学習コスト高くて、きちんと使うのはなかなか難しい
  • そもそも Scala エンジニアは数が少なすぎて雇えないから、チームの習熟には余計にコストがかかる

という話だ。

求人を見ると Scala エンジニアの募集は速攻で見つかる。国内なら尚更だ。
逆を言えば

それだけ Scala が使えるエンジニアが足りてない

という事の裏返しとも言える。

バカでも使えなくはないScala

正確にはこう言うべきかもしれない。
Java っぽく書こうと思えば書けるし、関数型っぽく書けると言えば書ける。

独習 Scalaz — 独習 Scalaz

とも書く、書いて動かすだけなら、(静的型の割には)凄まじく自由に書ける。

しかし、使いこなそうと思ったら、本にして人を殴り殺せそうな量の仕様を把握する必要がるということだ。

でもやってみればそこまで恐れる程でもないよ?

とってつけた(ホントそう)ようで申し訳ない。散々脅しておいてなんだが、言うほど怖い話でもないんじゃないかと思う。

要は、毛嫌いせずにやってみればきっと気に入る言語だってレベルの問題でしかない。

学習コストといっても、言語使用の数は Ruby の学習コストとそう変わらない。
むしろ静的型の制約が入る分、Ruby より楽かもしれない。

「AUひかり」で買ってきたルータを使うときの注意

まず、AUの課金の仕方がひどいと思った…とはいえ、建物がAU契約なのでほかの選択肢がなかなかなかったのだが、ともかくひどい。

  • 無線LANを使うには別契約が必要(追加課金)
  • 替えの性能いいルータをレンタルするなら追加課金

ルータすら契約上「貸与」で、もっといいルータ使いたかったら追加課金…

別にルータだけの問題じゃね?と思って、本日ヨドバシカメラBUFFALO WZR-1750DHP2/N を買ってきた。
契約 so-net で、PPPoE の設定も契約書に書いてあるので、全く気にしなかった。

で、問題が発生する。

ケーブルをすべて差して、電源を入れ、PPPoE 設定をしてもインターネットにつながらない事象が発生した。

("゚д゚)ポカーン

そこで解決のために行った変遷は以下の通り。

  • ともかくいろんな設定項目も見直す → どれも標準的に PPPoE 設定がされている
  • 同じルータでPPPoEした人の資料見る → ほぼ一致
  • 前のルータ(au から貸し出されてるやつ)の WebAdmin を調べる → PPPoE 設定が項目としてない(!?)ってことはルータ自体がカスタムされてる?
  • ルータの型番からググって、ドキュメント見つける → どうもベンダー側で設定してレンタルに出している模様
  • ルーター自体 au ひかりにくっついてる? → 検索ワードに「au ひかり」を追加

そして見つかった答え。

www.iesod.com

そしてそこにあった原因を見て呆然とした。

ルーターMAC アドレスを認識して、弾くようになっている」

俺、引っ越したら絶対 au 使わないんだ…。

そう言いたくなる作りである。
ただでさえ挫折する人が多いルーターの、MAC アドレスまで見て、指定以外のルーターを蹴ってる(屋内端末のほうだと思われ)ようだ。

幸い、「BUFFALO WZR-1750DHP2/N」は MAC アドレスを変更する機能があったから良かったようなものの、まさかルータの機能どころか、ルータ自体まで人質にして金をせびる体質だとは恐れ入る。

尚、デフォルトルータにはセキュリティホールがあり、こんな告知 がされている。
どう見ても CSRF 攻撃です、本当にありがとうございました。