PHPのshebangとnamespaceの関係について書いてる間に、Flycheckにマージされてた。よかった。
最近そこそこがんばって作ってるcomposer.elについて、行きあたりばったりに作ったつもりがそこそこ実用になってるので、そのうち設計意図をメモしておきたい。
単に「Emacsにひきこもりたいだけだろ」って感じではあるのだけれど、シェルでcdとかしないでもcomposerコマンドを実行できるのは実際べんりが強い。
Qiitaで、記事ソース(Markdown)を抽出するブックマークレットを作成しました - Qiita
片手間JavaScriptによる老害コメント
実家にVHSたぶんある。レンタルビデオ屋がつぶれたときに投げ売られてたやつ。
あいにく俺たちは試験管ベピーだぜベイビー
おう。
日記を習慣にしようと思ったけど数日置いてしまって後でまとめる現象。
むかしはてなダイアリーってサイトでやったわー。そのうち追従できなくなるやつ。
先週Flycheckに送ってたﾌﾟﾙﾘｯｸだけど、そろそろまとまるかな。
機械翻訳頼りの怪しい英語でしか情報を残しておかないのはどうかと思ふので、日本語でも書いておくね。
FlycheckってのはEmacs向けのシンタックスチェッカーのコレクションで、GNU Emacs標準添付とかじゃないんだけど、これだけ入れておけばいい感じに文法違反をチェックしてくれるやつね。
PHPやってると、趣味でも仕事でもPHPでスクリプトを書きたくなることって、よくあるじゃないですか。ここではshebang)がついて、コマンドラインから起動されることを意図したPHPスクリプトのことです。
さて、モダンなPHPはnamespaceを持つものです。以下のようなhello.phpがあったとしますね。
#!/usr/bin/env php <?php namespace Flycheck\Sample; echo "Hello", PHP_EOL;
このスクリプトは文法違反ではありません。特定の文脈では。
PHPコマンドには文法チェッカが含まれて居り、php -lでSyntax errorがないか確認することができます。php -l hello.phpで文法チェックをすると、文法違反のスクリプトではないことがわかります。
しかし不思議なことに、Flycheckを通すとこのスクリプトはSyntax errorだと警告を受けることになります。
それはなぜか。
@tadsanは終始てきとーな言動しかしないのでPHPは制禦構造を持ったテンプレートエンジンだとかPHPはテンプレートエンジンじゃない。調子に乗るなとか雑に言ったりするんですけど、この問題はまさにPHPの両面性を示したものです。
本来のPHPは、みなさまがよく御存じの通りWebページを作成するためのテンプレートエンジンのような言語です。
<p>今日は<?= date('Y年m月d日') ?>です。</p>
これは文法的には以下のスクリプトとおよそ等価です。
<?php echo '<p>今日は'; echo date('Y年m月d日'); echo 'です。</p>', PHP_EOL;
ここでふと疑問がよぎります。
#!/usr/bin/env php
<?php
これは echo '#!/usr/bin/env php', PHP_EOL; と等価ではないか、と。
% ./hello.php Hello % php ./hello.php Hello % php -e < ./hello.php PHP Fatal error: Namespace declaration statement has to be the very first statement or after any declare call in the script in - on line 4 Fatal error: Namespace declaration statement has to be the very first statement or after any declare call in the script in - on line 4
おやおや、これは不穏……！ Fatal errorになっちゃった。
hello.phpからnamespaceの含まれた行だけを抜いたhello2.phpを作ってみますね。
% php -e < ./hello2.php #!/usr/bin/env php Hello
ビンゴ！ #!/usr/bin/env phpも標準出力されてきました。つまり、 echo '#!/usr/bin/env php', PHP_EOL; と等価だ。「まじかよ」と思ったら疑念を放置せず、自分の環境で動かしてみてくださいよ。
ここから導きだされる結論は「PHPはCLIでファイルを直接実行する場合だけshebangを無視する」です。php -e、つまり標準入力からスクリプトを読み込んだ場合は対象になりません。この現象自体はよく知られたもので、shebangのついたファイルをinclude/requireしたときにはshebangが標準出力される羽目になります。
さて、namespaceはPHPスクリプトファイル内の最初(ただしdeclareを除く)に書かなければいけないので、echo '#!/usr/bin/env php';に相当する文が存在するとこのルールに違反し、Fatal errorになるわけです。
話が長くなったので節を分けますが、これを回避するための結論は「文法チェック時には標準入力は利用せずファイルを利用する」です。
みんなEmacsのモードライン長くて困ってないのかな、と思ふので定期的にageよう https://t.co/VrXBIZM3eP pic.twitter.com/Lc1ofarEfV
— ぞぬ (@tadsan) 2016年8月24日
木曜はnomikai.elと称して、Emacsっぽいひとたちと飲んだ。
Emacsの M-x はコマンドパレットだ！！
来週からインターンシップなので、インターン生の利用するサーバーにEmas 25.1rc2 をビルドして入れるなどした。 (Emasc 24.5は別のディレクトリに残してある
— ぞぬ (@tadsan) 2016年8月22日
composer.el 雑に機能増やしてる。PHPのComposerを管理するやつ。
今回の目玉は何かって言ったら、(composer-get-config "bin-dir")ですかね。composer.jsonをパースするのとどっちが楽かな。
そんなことやってる場合じゃない感もあるけど、やれることからこつこつと。
その前にphpunit.elの方に付けようと思ったんだけど、やっぱりcomposer.elに乗っかった方が楽だった。これ、phpunit.el の方にめんどくさいPR送るよりもcomposer.el側でnadvice使って実装してみた方が楽かもねえ。
それはそれとして、phpunit.el側の探索順序は変なのでプルリクエスト送る。
そーいや、自分の環境にはEmacs 25.1rc2を入れてなかった。
brew reinstall emacs --with-cocoa --with-imagemagick --with-librsvg --devel brew linkapps emacs
探索順序が変な話。composer global require phpunit/phpunitとかしてるときにはまる。あと、開発中のプロジェクトをglobal requireしてるとき。
現象としてはいままでも把握してたけど、CopipeIterのテストが通らなくてはまった。現在作業中のプロジェクトのファイルがロードされない。
送った。これWindowsで動くのかねえ… 動かない気がする。
ミラクルマジカルワールド ヾ(〃＞＜)ﾉﾞ
www.sunshinecity.co.jp魔法使いプリキュア！ミラクルマジカルワールド ｜ 池袋サンシャインシティ
神斬った。髭ともみあげが繋ってたのはおしゃれではない。
本放送で見てなかった。実家で自宅警備してたときに、弟が視てたのを見てた。
www.b-ch.com「あの夏で待ってる」 | バンダイチャンネル
沖縄まで見た。最優先事項だった。
そういや、今日遊んだメンバーに弟のﾂｲｰﾖがRTされてて世間の狭さを感じますね。
プルリック
久々にterm+.elを使ってみようと思った。
現状(といふかしばらく前から)いくつか問題があって、ひとつはYASnippetとの相性問題。これはterm-mode-hookとかで(yas-minor-mode -1)してやれば、まあ問題はない。こっちはそこまで致命的じゃない。
もうひとつは、Emacs起動時にWarningが出るようになること… こっちの方がつらい。
Warning (bytecomp): reference to free variable ‘term-vertical-motion’ Warning (bytecomp): ‘flet’ is an obsolete macro (as of 24.3); use either ‘cl-flet’ or ‘cl-letf’. Warning (bytecomp): reference to free variable ‘term-terminal-parameter’ Warning (bytecomp): reference to free variable ‘term-scroll-end’ Warning (bytecomp): reference to free variable ‘term-width’
fletの件については去年の10月にパッチを作ってなぜか放置してたのだけれど、さしあさってプルリクエストにした。
Use cl-letf instead of flet by zonuexe · Pull Request #11 · tarao/term-plus-el · GitHub
他のWarningの対応方法はちょっとわからなかったので、ゆとりのあるときにちゃんと調べる。
el(Emacs Lisp)。
(+ 1 2) (quote (りんご ばなな みかん))
いや、lisp(Common Lisp?)があるのは知ってるけどさ…
(+ 1 2) (quote (りんご ばなな みかん))
それよりもHatena::Letの惨状をはやくどうにかしてくれーっ
やるんですよ、インターンシップ。
ピクシブ株式会社では毎年インターンシップをやってて、冬には2日間の短期です。
実は提出課題はpublicなリポジトリに置いてあります。
このコードは私がWebアプリケーション技術者としての人生の集大成となる次世代インタラクティブコミュニケーションサービスなのですが、如何せんセキュリティホールが取れませんでした p(ixi)v
と冗談はさておき、このコードの脆弱性はあからさまで、かなり初心者向けです。特にPHPには依存しない問題もあれば、PHPにありがちな問題もあります。
脆弱性を発見して「直す」アプローチは基本的に楽しいものです。特定のWebフレームワークに依存したコードしか書いたことがない型には開発自身のPHP力の見直しにも、新入社員向けの教材に使っていただけても楽しいかもしれません。
もし解法について検討がつかない場合は、IPA(独立行政法人 情報処理推進機構)が公開する安全なウェブサイトの作り方を熟読してみてください。
www.slideshare.net
pixivはPHPで実装され、PHPと共に生き、PHPに真摯に向き合って居ります。会社として技術評論社さまのWEB†DB PRESSにてPHPの連載記事を持たせていただいて居り、これからも実世界でのPHPの技術について貢献していきます。
2000年代前半頃にYY-CHATベースのテキストチャットで育ったので、「チャット」については特別な感情があります。その当時プログラミングについて学びたいと思って自分ひとりでは理解できず、動かす環境を用意することすらできませんでした。それから十年あまりが経ち、職業としてWebサービスの設計に携るようになった自分を見つめ直す機会になりました。
私はAGPLにしたかったのですが議論がめんどくさかったのでWTFPLにしました。まあどっちでもいいです。
pixivエンジニアが教えるプログラミング入門 (星海社新書)
同僚の @catatsuy が本を書きました。3月26日発売とのことです。良いですね。
本書の美点は、その薄さです。
「画像掲示板の開発」が本書を通じての題材ですが、技術的な専門用語の導入をできるだけ避けつつ、最低限の説明では誤解を招かないように工夫が凝らされてます。想定環境をMacに限定するといふ割り切った判断で、環境構築の手間は驚異的な少なさです。 (ただし、sudo gem installさせるため管理者権限が必要)
本書の良くない点。日本語としては推敲されてをらず、読みものとして手にとると辛くなります。
ぱらぱらとめくってみて、ひどいと思った箇所を抜萃しておきます。
このようにGit は変更のかたまりであるコミットを作る準備としてgit add を使います。
そしてgit commit でコミットを作ります。
そしてそのコミットをサーバーに反映するためにgit push を使います。
そして他の人がgit push したコミットをダウンロードして手元に反映するためにgit pull を使います。
これは商業出版物としてはつらい文章ではありますが、自分で手を動かしながらプログラミングを理解するための資料としては不足ない水準ではあるかな、といふ感想です。とはいってもやっぱり日本語つらくて挫折することはありそう。
