定食屋おろポン

おろしポン酢と青ネギはかけ放題です

分かんないことあったらTwitterで@飛ばせ VS プロに質問するなら金払えよボケ

STFUAWSC

ファイ！

※ちなみに僕はプロプログラマじゃないです。

３行で

  • プログラマに質問するのは、プログラマ文化的にあたりまえのこと
  • プログラマにタダで質問するのは、時間と金を費やして身につけたプロの知識をタダでよこせと言ってるようなもの

..どっちやねん

じゃんじゃん質問して。どんどん頼って。

プログラマ界隈は 「初心者でもコミュニティーに参加しよう」 「モチベーションあがるし、困ったことあればTwitterで@飛ばせば教えてくれるよ」 「みんな最初は初心者でいろんな人から教えてもらったし、マッチョの多くも知識をコミュニティーに還元しようって人が多いんだよ」 っていう話を読んだり聞いたりすることが多い。

とてもあたたかい世界だ。マサカリだって振り上げて投げ飛ばすには体力を使うはずだ。

実際、自分が「プログラミングをやってみたいんだけど」って相談されたときは

  • 最初でつまづかないように、動いた→楽しい！を一番簡単に体験できるのが大事よね
  • 環境構築とかオマジナイで躓かないようにしないと
  • ハンズオンじゃないと伝わりづらいところはハンズオンで行こう

って色々考えて教えたこともあった。睡眠時間きつかったりしたけど、「動いた→楽しい！」を初めて感じたころを思い出しながら考えるのは自分でも楽しかった。

以前、先輩のiOSエンジニアに「 Objective-Cで〜〜がやりたいんだけど、良いやり方ねーかなー」って相談されたときも、仕事とは全く関係なかったけど色々調べて、「それRubyなら◯◯っていって、言語でサポートしてまっせ。こんな仕組みでっせ。」って昼休み中にポロッとお伝えした。実際のところ僕の助言がどこまで役に立ったかはわかんないけど、今ではライブラリとして形になっていてすごくうれしい。

だから、モチベーション持って学ぼうとか、何かしようって人に時間を費やすのは全く苦じゃないってのは肌で知っている。 誰もがそうとは限らないけど 、プログラマ界隈があったかいのはこういうことなんだろうなって思っている。

お金を貰うだけの仕事をするからプロ

一方で、「プロの仕事には対価を払うべき」ってのがすごく引っかかって、なかなか人に気軽に聞けない。

正確に言うと、Twitterで@を飛ばすとかで「特定の個人に対して聞く」ってことができない。ブログやTwitterのひとりごとで「うーむ。。分からん！」ってつぶやくことはできても、誰かに直接助けを求めることができない。

「モチベーション持って学ぼうとか、何かしようって人に時間を費やす」のは、自分自身が楽しいし、うれしいからだとする。 であれば、自分が「ねーこれどうやんの？これ教えてよ」「ドハマりしたでござる。。ちょっとおにーさん助けてよ。。」っていうのは、「私の質問に答えるため、あなたは知識と時間を費やすことになりますが、たのしいしうれしいから、いいよね。まあ強要しているわけでもないし」って言ってるに等しいのではないか。

答えるのに大した時間はかからないかもしれないが、その背後に何千時間、何万時間を捧げているからこそ豊富な知識があるはずだ。

この文章を書いていて思い出したこと

父が昔、「父さんや母さんは、おまえを育てるために金を出すし、時間を費やすし、愛情も注いでいる。しかし、親に返さなくてもいい。お前に子供ができたら返してやれ。」と言っていた。

頼りたいときには先輩に頼って、後進やコミュニティに還元していくのが正解だ、と考えて、うだうだ言ってないで、みんなでコードを書けばよいのだろうか。

Grunt使おうと思ってcoffee, scssファイルなどの配置を調べた

ファイル配置に悩む

Gruntを使う時に 「.coffeeファイルや、.scssファイルをどこに置けばいいの？」 「ビルド後のファイルをどこに配置するのがいいの？」 って疑問に思っていたので調べてみた。

毎回悩んで適当に配置するより、良さそうな方法で決め打ちしちゃいたい。

Grunt Website

gruntjs/gruntjs.com · GitHub

Gruntの使い方みるなら、Gruntのホームページ見るのがよいかと思って覗いてみる。

まずはgitで管理されているソースコード

% cd gruntjs.com 
% tree -d
.
├── misc
├── src
│   ├── cdn
│   ├── fonts
│   ├── img
│   ├── js
│   │   └── vendor
│   │       └── lib
│   ├── less
│   │   └── bootstrap
│   ├── media
│   └── tmpl
│       ├── blocks
│       └── includes
└── tasks
    └── lib

srcディレクトリにHTMLテンプレート(Jade), 画像, Less, etc..を全て突っ込んでいるようだ。

ビルドしてみる。

% npm install
% grunt
% tree -d -L 3
.
├── build
│   ├── api
│   ├── blog
│   ├── cdn
│   ├── css
│   ├── docs
│   ├── fonts
│   ├── img
│   └── js
│       └── vendor
│           └── lib
├── misc
├── node_modules
│   └── 多すぎるので略
├── src
│   ├── cdn
│   ├── fonts
│   ├── img
│   ├── js
│   │   └── vendor
│   │       └── lib
│   ├── less
│   │   └── bootstrap
│   ├── media
│   └── tmpl
│       ├── blocks
│       └── includes
└── tasks
    └── lib

ビルドすると、/buildディレクトリが作成され、コンパイルやminifyなどもろもろの処理を行って生成された*.html, *.css, その他リソースなどを/buildディレクトリに放り込んでいく。

これによって、

  • 作業やリソース配置はすべて/srcディレクトリ以下で行う
  • デプロイは/buildディレクトリ以下のすべてが対象

というシンプルな構成にできる、と。

Gruntfile.jsも参考になる。

Yeoman Website

yeoman/yeoman.io · GitHub

GruntといえばYeomanだろう、という発想で覗いてみた。

YeomanのGruntfile.jsを見たところ、Gruntとほぼ同様。

/appディレクトリにHTMLテンプレート(Jekyll), 画像, CSS, JS, etc..を突っ込んで、ごにょごにょしたものを/distディレクトリに放り込む方式。

yo webapp

Yeoman使えば悩むことはなかった。

$ yo webapp

で、上記の構成が最初っから設定されている。 webapp以外のジェネレータでも似たような設定なんじゃなかろーか。

結論

ディレクトリ名の好みでいうと、ソースは/srcで、ビルドしたのは/distがいいな。

サーバーにパシフィック・リムのイェーガーと怪獣の名前を付ける話

サーバー環境を立ち上げる時に、最初に考えねばならないことはなにか。それは名前です。 クールな名前を付けることが至上命題、最優先事項であります。

森羅万象、名前を付けることにより初めて魂が吹き込まれます。

しかし、VPSやらAWSやらVMやら、なにかとサーバー環境を立ち上げることが多いご時世です。 いちいち名前を考えているわけにも参りません。

そこで、先人たちは悠久の歴史の中で、「なんらかのルールに従って命名する」という素晴らしい解決法を編み出しました。 「地名」や「川の名前」などが有名でしょう。

ただし、「巨大ネコ科動物」縛りとかにするとすぐネタ切れになってしまうという欠点もありますので、ルールの選択には注意が必要です。

そこで！ぼくは！パシフィック・リムのイェーガーと怪獣の名前をサーバー環境に付けることにしました！ 超クール！！

具体的には以下のmarkdownをprivate gistに放り込んで、使ったらチェックしていく方式。

Kaijuは１単語なので使いやすいが、イェーガーは２単語なのでGipsy Dangerならgdangerとかにする工夫が必要です。

# List of Known Jaegers
[http://pacificrim.wikia.com/wiki/Jaeger]

## Mark-1
- [ ] Brawler Yukon
- [ ] Coyote Tango
- [ ] Horizon Brave
- [ ] Romeo Blue
- [ ] Tacit Ronin
- [ ] Cherno Alpha
- [ ] Tango Tasmania

## Mark-2
- [ ] Diablo Intercept
- [ ] Solar Prophet
- [ ] Puma Real
- [ ] Eden Assassin

## Mark-3
- [ ] Gipsy Danger
- [ ] Matador Fury
- [ ] Shaolin Rogue
- [ ] Vulcan Specter
- [ ] Chrome Brutus

## Mark-4
- [ ] Crimson Typhoon
- [ ] Hydra Corinthian
- [ ] Nova Hyperion
- [ ] Echo Saber
- [ ] Mammoth Apostle

## Mark-5
- [ ] Striker Eureka

## Unknown
- [ ] Lucky Seven


# List of Named Kaiju
http://pacificrim.wikia.com/wiki/Kaiju

## Category II
- [x] Onibaba

## Category III
- [x] Knifehead
- [ ] Yamarashi

## Category IV
- [ ] Mutavore
- [ ] Leatherback
- [ ] Otachi
- [ ] Raiju
- [ ] Scunner

## Category V
- [ ] Slattern

## Unknown
- [ ] Trespasser
- [ ] Hundun
- [ ] Kaiceph
- [ ] Scissure
- [ ] Karloff
- [ ] Reckoner
- [ ] Raythe
- [ ] Clawhook
- [ ] Atticon
- [ ] Ceramander
- [ ] Spinejackal
- [ ] Taurax
- [ ] Insurrector
- [ ] Bonesquid
- [ ] Hound
- [ ] Taranais
- [ ] Rachnid
- [ ] Fiend
- [ ] Baby Kaiju
- [ ] Verocitor
- [ ] Belobog
- [ ] Meathead
- [ ] Hardship
- [ ] Hammerjaw
- [ ] Hidoi
- [ ] Tentalus
- [ ] Biantal
- [ ] Tailspitter
- [ ] Kojiyama

ちなみに、僕の持っているiMac, MacBook, iPhone, iPad, Time Capsule, Apple TVなどのApple製デバイスには攻殻機動隊の登場人物名をつけています。目下絶賛愛用中のiPad miniはPazuで、この記事はMotokoで執筆しております。

...ってことを普通の人に言うと「キモい」って言われて悲しいですね。

cabal hellから抜け出したくてあがいた話

haskell

「cabalでパッケージをインストールする際、依存の解消がイマイチでハマりがち」という噂が流れているのは知っていた。

自分が遭遇するまでは「ふーん」と右から左であった。

仔細は省略するが、このたび見事にハマり、cabal hellを目の当たりにした。

熟練Haskellerであれば「こんなのは地獄のうちに入らぬわ！」などと高笑いするかもしれないが、初心者にとっては「面白そうなパッケージ試してみようと思ったらエラーが...解消しようと思ったらまたエラーが...エラー...エラー...」という終わりの見えない状況は十分に地獄と呼んでよいのではないか。

環境: Mac OSX 10.9.2

Haskell Platformのアンインストール

ここらへんを参考に、ghcもcabalもない、古き良き時代に戻る。

身も心もすっきりする。

GHCのインストール

参考: 2013年8月現在のHaskell開発環境 - maoeのブログ

Haskell Platformを使わない利点は、バージョンが固定されるパッケージが少ないので依存関係でこけることが減ること。

とのことなので、Haskell Platformを使わずインストールすることにする。

GHC: Download version 7.6.3 からGHC7.6.3のバイナリを落とし、インストール。

ちなみにニュービーな僕は「GHCのバージョンを一発で切り替えたい」などと欲をかかず、大人しく/usr/local/ghc/ghc-7.6.3/binにパスを通した。 それ以外は、概ね上記サイトの通りである。

Cabalのインストール

参考: An Introduction to Cabal sandboxes

「とりあえずcabal sandbox使っとけ」ということなので、githubのCabalをインストールする。

If you have used Haskell for some time, you’ve probably heard the expression “Cabal hell”. It refers to the fact that installing a new package with cabal install can break existing packages on your system.

すなわち。

もしもHaskellを何度か使ったことさえあれば、"Cabal hell"なる言葉を聞き及んだことがあろう。これは、新しいパッケージをインストールするために黒い画面に打ち込んだcabal installが既存パッケージをぶっ壊す恐ろしい現象を指す言葉である。

さて。

「GHCしか入ってないならこうやれよ」と仰せなので以下のコードを逐一実行してみる。

$ git clone git://github.com/haskell/cabal.git /path/to/cabal
$ cd /path/to/cabal/Cabal
$ runhaskell Setup.hs configure
$ runhaskell Setup.hs build
$ runhaskell Setup.hs install
$ cd ../cabal-install
$ sh bootstrap.sh

と、sh bootstrap.shでこんなエラーが出て失敗する。

Data/Text.hs:1213:42:
     warning: missing terminating ' character [-Winvalid-pp-token]
-- In (unlikely) bad cases, this function's time complexity degrades

ここらへん を覗くと、gcc4.7を使うと解決するようだ。gcc48もgcc49もあるけど、gcc47なら出来るっていうんだからそうしてやろうじゃないか。 仕方ないので、4.7を入れてやる。

時間がかかるので、しばらく正座して待つ。

gccコマンドがgcc47を参照するよう変更した後、再びsh bootstrap.shを行う。

The 'cabal' program has been installed in /Users/shogo/.cabal/bin/

めでたい。

使ってみる

「WAFが使えればもう大丈夫でしょう」という安易な発想から、 Making A Website With Haskell - adit.io を参考に Scottyを入れてみる。

さっそくcabal installで失敗する。世知辛い。

Resolving dependencies...
cabal: Could not resolve dependencies:
trying: todo-0.0.1 (user goal)
next goal: wai-extra (dependency of todo-0.0.1)
Dependency tree exhaustively searched.
Motoko% cabal update
Downloading the latest package list from hackage.haskell.org
Motoko% cabal install
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: todo-0.0.1 (user goal)
trying: wai-extra-2.1.1.1 (dependency of todo-0.0.1)
trying: conduit-1.1.0 (dependency of wai-extra-2.1.1.1)
next goal: monad-logger (dependency of todo-0.0.1)
rejecting: monad-logger-0.3.4.1, 0.3.4.0, 0.3.3.2, 0.3.3.1, 0.3.3.0, 0.3.2.0,
0.3.1.1, 0.3.1, 0.3.0.1 (conflict: todo => monad-logger==0.3.0)
rejecting: monad-logger-0.3.0 (conflict: conduit==1.1.0, monad-logger =>
conduit>=1.0 && <1.1)
rejecting: monad-logger-0.2.4, 0.2.3.2, 0.2.3.1, 0.2.3, 0.2.2, 0.2.1, 0.2.0.1,
0.2.0 (conflict: todo => monad-logger==0.3.0)
Backjump limit reached (change with --max-backjumps).

Backjumpがlimitに達して失敗したようだ。依存関係の解消ができなくて失敗してたら心を折って、ついでにHHKBも２つにぶち折っているところだった。

--max-backjumpsだが、cabal install --helpによると、「とりあえず-1にしとけ」と読み取れる。

    --max-backjumps=NUM             Maximum number of backjumps allowed while
                                    solving (default: 200). Use a negative
                                    number to enable unlimited backtracking.
                                    Use 0 to disable backtracking completely.

cabal install --max-backjumps=-1でリトライする。。も失敗。

.
.
.
Installed persistent-sqlite-1.3.0.5
cabal: Error: some packages failed to install:
persistent-postgresql-1.3.0.5 depends on postgresql-libpq-0.9.0.0 which failed
to install.
postgresql-libpq-0.9.0.0 failed during the configure step. The exception was:
ExitFailure 1
postgresql-simple-0.4.2.1 depends on postgresql-libpq-0.9.0.0 which failed to
install.
todo-0.0.1 depends on postgresql-libpq-0.9.0.0 which failed to install.

めげずに個別にインストールをしてみる。 cabal install postgresql-libpq-0.9.0.0を行うと、setup: The program 'pg_config' is required but it could not be found.とのことなので、pg_configを入れる。

Homebrewからインストール。すぐ終わる。

% brew install postgresql
% which pg_config
/usr/local/bin/pg_config

これによって、cabal install postgresql-libpq-0.9.0.0が成功するため、もう一度cabal install --max-backjumps=-1を行ってみる。

...成功！

.
.
.
Configuring todo-0.0.1...
Building todo-0.0.1...
Installed todo-0.0.1

世界にこんにちはできたので、寝る。

f:id:oropon:20140408030602p:plain

テスト崩壊

テストファーストを数学の勉強にあてはめるとするでしょ

  1. 問題集を解く=テストする
  2. 解けなかった問題がある=テストが失敗する
  3. 解けなかった問題について解法を学ぶ=実装する
  4. 再度問題集を解く=再度テストを回す
  5. 解ける=テストに通る
  6. 数日後、また問題集を解く=再度テストを回す
  7. 解けなかった問題がある=テストに失敗する

これは、プログラムが記録されたHDDがポンコツで、時間経過とともにプログラムが消えていくってことですよね。

ふざけんな！

数学が記憶問題か、とか脳は別の側面では非常に優秀、とかそういうのはおいといて。 一度テストに通った箇所は、変更を加えない限りテストに通るこんぴゅーた羨ましい。

AtomがGithub Flavored Markdownのエディタとして使える件について

atom editor

「これが21世紀のエディタだ！」とGithubが喧伝しているAtomについて。

今まで

クローズドベータ中なのでまだ作りが荒いところはあるようですが、なんとこれ、GFM（Github Flavored Markdown）のライブプレビューエディタ*1として使えます。

Markdown専用のアプリとしてはMarkdown Proを愛用していますが、当然ながらGFMは扱うことができません。
（あとMarkdown Proの不満点としては、普通に日本語使えるんですけど、バッククオートに囲まれたコード内に日本語が含まれていると文字参照になって読めなくなっちゃう）

EmacsとかVimとかSublime TextとかTextMateとかは、カスタマイズしてごにょごにょすればGFMも編集できるでしょうし、Webブラウザ上で動くGFMエディタなんかもあるようですが、なんか手を出す気が起きずにMarkdown Proを使っていました。

Atom

Atomにはデフォルトでmark-downパッケージが入っていますが、これがなんとGFMなんです。Githubチーム製なので当然っちゃ当然ですが。

Preview

普通のMarkdownに比べてGFMの何がよいかといえば..

  • スネークケースが使えます（this_is_snakecase のisがイタリックにならない）
  • URLが自動的にリンク貼られます
  • Emoticonが使えます👍
  • タスクリスト（- [x] で になるやつ）がなんとなく使えるっぽいです
  • シンタックスハイライトしてくれます
  • Markdown上の改行を実際の改行にしてくれるオプションが追加される*2 *3

その他はGitHub Flavored Markdown · GitHub Helpを御覧ください。

これから

まだ本体がクローズドベータですし、markdown-previewモードも発展途上かと思います。 気づいた点をざっと挙げると..

  • PDF変換や印刷以前に、HTMLで出力できない
  • 変換がちょっと変だったりする
  • 長いテキストを入力している時、カーソル位置とプレビューペインの表示位置を同期してほしい
  • シンタックスハイライトの対応言語がまだまだ少ない

などでしょうか。

こちらのパッケージはもちろんGithub上で管理されています。 知ってはいましたが、マジでCoffeeScriptで書かれてるのをみるとちょっとびっくりしますね。

HTML出力がないと印刷やPDF化もできず、個人的には大いに支障があるので実装してしまいたいです。ソースやCoffeeScriptの文法を眺めたりしています。

*1:2ペイン表示で、マークダウン形式のテキストを編集しながら、どう表示されるかプレビューを見られるエディタ

*2:ver0.54.0で対応するっぽいんですが、パッケージのアップデートがコケてて試せてない

*3:追記20140425 Update Package Dependencies はうまく行きませんが、Atom自体のupdateを行うことでパッケージも最新になりました。Markdown Previewパッケージの設定からBreak On Single Newlineを有効にできます。

Ninety-Nine Haskell Problems 解いてみた

haskell

H-99: Ninety-Nine Haskell Problems - HaskellWiki
99 questions/1 to 10 - HaskellWiki

とりあえず1-10問目まで。 Preludeなどのライブラリ関数になるべく依存しない縛りで解いてみた。 そのため、myLastを書くのにhead', reverse', fold', flip'を書くことになった。

20問目までは飛ばしてもよかったかも。

続きを読む