日記 : 「創作」と呼べるアプリケーションコーディングと設計技法について

はじめに

個人的に「創作」という言葉には強い思い入れがあります。

自分は生まれてからずっと「創作」されたもので心を動かされてきたし,何よりも今の人格を形成しているものが「創作」されたものであったと考えているからです。

なので,「創作」を行える人は非常に尊い存在であると感じており,また自分がそれに携われない,支援できないという部分において深く無力感を感じている部分でもあります。

しかし,嘆いているだけでは何にもなりません。仮に自分が「創作」に携われないとしても,それをエンジニアリングで支援することは出来るはずです。嘆く前に,まずは行動するべきなのです。

では具体的に何を行っていくか,そして目標とするところは何なのか,というところについて考えてみたいと思います。

「創作」と呼べるプログラムは存在する

もちろん,これはエンジニアリングに携わる人間としての観点です。

多くの人から見て,プログラミング言語という物はどれも大差がなく,結局「特定の条件に従って処理をする物」以上でも以下でもないのでしょう。

しかし,無秩序でないプログラム・プログラミング言語には何かしらの「設計思想」があり,そこにある「哲学」をベースとして書かれていることが多いのです。

例えばプログラミング言語であるLuaなどもその一種で,データ構造が非常に単純であることから習得が容易であり,かつ深く習得することでプログラミングにおける手法の殆どを実現することが出来,しかも高速に動作するという優れた環境を実現しています。

これは近年におけるJavaScriptも同様であり(個人的にLuaのほうが遥かにきれいで簡潔な設計だとは思いますが),Lightweight Language界のトレンドでもあります。

このような「汎用性に優れ,様々なプログラミングパラダイムを実現出来る言語」は「創作」と呼んでしまっても良いレベルに尊いものなのではないかと考えています。

Dirtyな言語でも「創作的」なコーディングは生きる

Dirty(汚い)言語として,良くphpが槍玉に挙げられます。phpは歴史的経緯から純粋なオブジェクト指向とはかけ離れた構文を多く持ち,引数の順序すらめちゃくちゃな多くのグローバル関数に支えられて動いています。

標準phpにおける連想配列は確かに便利ですが,オブジェクト指向的概念から考えたときにはあまりにも不便です。しかし,現代のphpはモダンなプログラミング環境を提供できるだけの機能を有しており,それらの機能を用いたモダンなオブジェクト指向をサポートするライブラリが十二分に提供されています。(例えばCollectionなど)

こういった再利用可能で汎用性に優れたライブラリを用いて書かれたコードは非常に見通しが良く,そのコードが一体何を行おうとしているのか,どのような役割を持っているのかがひと目で分かります。これはもはや芸術的とすら呼べるでしょう。

多くの人には理解されないでしょうが,私はこのような「見通しの良い設計」は「創作」の一つであると考えています。それほどまでに見通しの良いコードは尊く,人を幸せにする力があるのです。

「創作」と呼べるレベルのコードを書くためには

何よりも大事なのは,技術的トレンドを常に追い続けることです。しかし忘れてはならないのが,「それが本当に必要なものなのか」を考えることを怠ってはいけないという部分です。

技術的なトレンドは凄まじい勢いで移り変わっていきます。その激しい流れの中で,一体どれが物事の本質を見抜いているのか,それを見抜く力が必要になります。

設計における理想の実現は確かに大事かもしれません。しかし,それと全く同じ理想を持ち,冗長で複雑な処理を記述することを好む人がいるかと言えば,そんなことはないのです。

例えば有名なphp言語のWebアプリケーションフレームワークであるSymfonyとLaravelの関係を見てみましょう。Symfonyはそれぞれの機能がコンポーネントとして提供されており,疎結合かつSymfony以外のフレームワークからも容易に利用できる環境が整っています。

しかしLaravelはどうでしょう。実のところLaravelは機能の多くをSymfonyコンポーネントに依存しており,それを独自拡張する形で実現されている部分が大半です。また,LaravelはSymfonyほどコードの再利用性について考えられておらず,あくまでも「利用者がアプリケーションを作りやすい環境」を作ることに注力しています。

近年のphp言語におけるWebアプリケーションフレームワークではLaravelが圧倒的に人気となっています。Symfonyの人気は低くないものの,学習コストの高さや疎結合が故にアプリケーションの設計自体も利用者に委ねられるという点で,「手早くアプリケーションを構築したい」という需要を叶えにくい物となってしまっている背景があります。

しかしLaravelの基礎にはSymfonyの存在があり,皮肉にもLaravelはSymfonyがあるからこそ成り立つものなのです。

私はLaravelもSymfonyも「創作」と呼ぶにふさわしいプロダクトだと考えています。これらのプロダクトがあるからこそ今のモダンなphp開発環境が実現されているのであり,これらの作者には感謝してもしきれません。少なくとも,LaravelとSymfonyは私の心を動かしたのです。

最後に

自分が人の心を動かせるようなコードを書ける様になる日はまだまだ遠いか,もしくは一生ないかもしれません。

しかし,いつかは自分のコード・プロダクトで人の心を動かし,感動してもらえるようなものを作りたいと常々思っています。

家が燃えても気づける! @zeriyoshi_svr の裏側

みんなあるよね自宅サーバ

この界隈の人達にとって,自宅にサーバーがあるのは珍しいことではないかと思います。

特にファイルサーバーなんかは既製品を買ってくるよりも自作したほうが遥かに安く強力な物を作れるので便利です。

実際私も家にサーバーがあるのですが,WD Red 8TBx2をRAID1で構成し,ファイルサーバー兼Webサーバーとして稼働してもらっています。

この自宅サーバーなのですが,15分毎に室温+各種ハードウェアの温度をTwitterに投稿しています。

twitter.com

Twitterのフォロワーさんにこれを真似してくれている人が居たので,個人的なメモ代わりにもこのbotがどのようにして動いているかを書いておきたいと思います。

サーバー構成

  • CPU : Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz (4th Gen, Haswell)
  • RAM : 20GB (8GBx2, 2GBx2)
  • OS : Arch Linux (x86_64)

ハードウェアはそれなりにパワーがあるのですが,自宅の回線が細い(100Mbps VDSL)なのであまり有効に活用できない...

最近はもっぱらファイルサーバーとして活躍しています。

死活監視が出来ない

自宅の回線は特にISPの固定IPオプションなどを契約していない為,グローバルIPv4アドレスが定期的に変わる環境にあります。

その為にドメインレジストラのDynamic DNS機能を用いて逐次現在のIPアドレスを登録しているのですが,何かしらの問題が発生して登録が正常に行われない可能性があります。

こうなるとサーバーに物理的にアクセスできない限り現状の把握が出来ません。もしかしたら停電が起こっていたり,最悪サーバーが燃えている可能性も考えられます。

ならば"サーバー側から"現在の状況を報告もらえばいいのです。手持ちのUSB温度計があったので同時に室温も報告してもらうことにしました。

例えば室温が80℃とかになっていればそれはもう確実に家が燃えているので,安心してかなしい気持ちになることができます。(そう,燃えていることに気づけるだけです。)

なぜTwitterなのか

自分が一番良く見ているのがTwitterだから

(関係ないですが,私に連絡する時はメールとかLINEよりもTwitterでreplyかDMした方が反応がたぶん早いです...)

@zeriyoshi_svrを作ろう

では実際に作っていきたいと思います。

Twitter側作業

アカウントの作成

15分毎に自分のメインアカウントでつぶやかれるとフォロワーさんに迷惑です。ちゃんとbot用アカウントを作りましょう。メインアカウントで垂れ流そうものなら速攻でミュートに突っ込みます。

アプリケーション登録

Twitterにつぶやく為にはアプリケーションの登録が必要です。

先程作成したアカウントでログインした状態でTwitter Applicaton Managementにアクセスし,Create New Appボタンを押して登録を進めます。

Callback URLは空欄のままで大丈夫です。

アプリケーション権限変更

アプリケーションの登録は完了しましたが,初期状態ではTwitterに書き込む権限を有していません。

Twitter Applicaton Managementから先程作成したアプリケーションを開き,Keys and Access Tokensタブからmodify app permissionsを開いてRead and Writeに変更してください。

自身のアクセストークンを取得

権限の変更が完了したら,Keys and Access Tokensタブの下にあるYour Access TokenToken ActionからCreate my access tokenボタンをクリックして自身のアカウント用のアクセストークンを生成します。

Access Tokenが生成されたら,しっかりとAccess LevelRead and Writeになっていることを確認しましょう。

最後にアカウントのスクリーンネームと以下の4つのToken, Secretをメモしておきましょう。

サーバー側作業

ShellからTweet出来る環境構築

情報取得の前にまずShellからTweet出来る環境を整える必要があります。

ShellからTwitterにつぶやく為の方法はいくつかありますが,今回は非常にポータブルで使いやすい火を吹くTwitter怪人“小鳥男”を使っていきます。

使い方...は記事の方で詳細に説明されているので省略します。

で,問題はスクリプトをどこに置くかなのですが,当時の自分は何も考えずsudo su -した後/etc/zeriyoshiなるディレクトリを作ってそこに全てを突っ込むという凶悪な行為を行っていました。

本来であれば適切なパーミッションを設定した上で/optディレクトリ以下に置いたほうが良いでしょう。

温度情報の取得とTweetを行うスクリプトの作成

まずlm_sensorshddtempコマンドを用いるのでこれらをインストールします。

Linux ディストロによっては最初から入ってたりパッケージ名が違ったりするかもなので適宜確認してください。

$ sudo pacman -S lm_sensors hddtemp

で,ざっと次のようなスクリプトを書きます。

tweet_temp.sh

#!/bin/bash

cpu_temp=`sensors | grep Package | cut -c 17-24`
hdd_temps=""

for device in /dev/sd[abcd];do
    hdd_temps="${hdd_temps}${device}:`hddtemp -n $device` °C
";
done

echo -e "CPU:${cpu_temp}\nHDDs:\n${hdd_temps}\n`date +\"%Y/%m/%d %H:%M:%S\"`" | /etc/zeriyoshi/kotoriotoko/BIN/tweet.sh

はい。本当に適当です。各種実行ファイルのパスやデバイスノード名は環境に合わせて書き換えてください。

systemd-timerに登録しスクリプトを定期実行する

ちょっと前まではcronを使って定期実行を行うのが通例でしたが,最近のLinuxディストロは殆どがsystemdinitデーモンとして用いており,systemd自体にcron代替機能が備わっているのでそれを利用します。

まずはサービスを作成します。

$ sudo vim /etc/systemd/system/tweet_temp.service

[Unit]
Description=Tweet CPU and HDDs temperature.

[Service]
Type=oneshot
ExecStart=/etc/zeriyoshi/tweet_temp.sh

次にタイマーを作成します。

$ sudo vim /etc/systemd/system/tweet_temp.timer

[Unit]
Description=Tweet CPU and HDDs temperature.

[Timer]
OnCalendar=*:0/15

[Install]
WantedBy=timers.target

終わったらsystemdのデーモンを再読込し,タイマーを有効化して開始します。

$ sudo systemctl enable tweet_temp.timer
$ sudo systemctl start tweet_temp.timer

タイマーが正常に動作しているか確認します。

$ sudo systemctl | grep tweet_temp
  tweet_temp.timer                                                                                      loaded active waiting   Tweet CPU and HDDs temperature.                                   

これで一通り完了です。

おまけ : 室温をつぶやこう

@zeriyoshi_svrでは自宅の室温もつぶやいています。ではこれはどうやっているのかというと

f:id:zeriyoshi:20180108000443j:plain

こうしています。

こういうのと

www.itmedia.co.jp

これを組み合わせて

github.com

室内温度を測定しています。このUSB温度計は販売終了品となってしまっていますが,中国のR Ding社のOEM品なので今でも普通に入手することができます。

コンパイルにはlibusbが必要になるのでインストール後にmakeしてください。

GitHubの説明通り適切に設定を行えば管理者ユーザーでなくとも実行できるようになりますが,systemd-timerで実行している為特に設定はしていません。

デフォルトでは現在時刻が出力されてしまう&センサーの個体差で取得できる温度にブレがあるので通常の室温計を元にキャリブレーションを行い再度コンパイルしました。

一応ソースも貼っておきます。

pcsensor.cの修正patch(不要な変数宣言を消しているだけです)
--- pcsensor.c   2018-01-08 00:36:23.685319615 +0900
+++ pcsensor.fix.c    2018-01-08 00:34:36.358652434 +0900
@@ -47,7 +47,6 @@ const static char uCmd3[] = { 0x52,    0
 const static char uCmd4[] = { 0x54,    0,    0,    0,    0,    0,    0,    0 };
 
 const static int reqIntLen=8;
-const static int reqBulkLen=8;
 const static int timeout=5000; /* timeout in ms */
  
 static int debug=0;
temper.cを温度の出力のみ変更したpatch
--- temper.c 2018-01-08 00:40:19.838654085 +0900
+++ temper.zeri.c 2018-01-08 00:33:46.555318858 +0900
@@ -9,8 +9,8 @@
 
 /* Calibration adjustments */
 /* See http://www.pitt-pladdy.com/blog/_20110824-191017_0100_TEMPer_under_Linux_perl_with_Cacti/ */
-static float scale = 1.0287;
-static float offset = -0.85;
+static float scale = 1.00000;
+static float offset = -2.00;
 
 int main(){
    int passes = 0;
@@ -38,15 +38,7 @@ int main(){
        /* Apply calibrations */
        tempc = (tempc * scale) + offset;
 
-      struct tm *utc;
-      time_t t;
-      t = time(NULL);
-      utc = gmtime(&t);
-      
-      char dt[80];
-      strftime(dt, 80, "%d-%b-%Y %H:%M", utc);
-
-      printf("%s,%f\n", dt, tempc);
+       printf("%.3f °C\n", tempc);
        fflush(stdout);
 
        return 0;

あとは先程のtweet_temp.shを以下のようにするだけです。

#!/bin/bash

cpu_temp=`sensors | grep Package | cut -c 17-24`
hdd_temps=""

for device in /dev/sd[abcd];do
    hdd_temps="${hdd_temps}${device}:`hddtemp -n $device` °C
";
done

echo -e "Room:`/etc/zeriyoshi/temper`\nCPU:${cpu_temp}\nHDDs:\n${hdd_temps}\n`date +\"%Y/%m/%d %H:%M:%S\"`" | /etc/zeriyoshi/kotoriotoko/BIN/tweet.sh

雑記 : 常時SSL化とインターネットの性善説が死ぬ日

要約

  • もはや「HTTPSだから安全」なんて嘘だよ
  • 常時SSL化(全てHTTPS通信へ)の波が来てるよ
  • 暗号化通信には相応の処理負荷がかかるよ
    • 特に携帯電話とかだとバッテリ持ちとかに影響するよ
    • 「自由でオープンな」性善説のインターネットは死につつあるよ
    • 現状のインターネットを支える技術の多くは性善説に基づいて作られているよ
    • 性悪説で構築されたインターネットは多くの代償を伴うよ
      • なんだか皮肉な話だよね

はじめに

近年,Webサービスの多くでHTTPS(常時SSL)化が進んでいる。

暗号化されていないHTTPS,つまり元々のHTTPでは平文で情報が送受信される。平文で情報を送受信するということは,経路を流れるパケットを覗き見るだけで通信の内容を把握できるということになる。

これはクレジットカード番号などクリティカルな情報を扱うのには危険であり,2000年代頃からはインターネットショッピングサイトやクレジットカード情報を扱うサイトにおいてHTTPSが導入され始めた。

HTTPS通信は公開鍵暗号を元に暗号化して通信を行う。経路上からパケットを覗き見たとしても,通信の内容を把握することは一般的に不可能である。

また,HTTPSにて用いられる「証明書」(電子証明書)にはいくつか種類があり,通信の暗号化に加えそれぞれ以下のレベルの保証が行われる。

DV (Domain Validation)証明書

アクセス先のドメイン(例えばzeri.io)がそのサーバーに紐づくものであることを証明する。現状,Let"s Encrypt等で個人でも費用なしで取得することが可能。

OV (Organization Validation)証明書

アクセス先のドメインがそのサーバーに紐付き,また特定の組織の管理下にあることを証明する。

EV (Extended Validation)証明書

アクセス先のドメインがそのサーバーに紐付き,また特定の基準に従い存在が確認された組織の管理下にあることを証明する。

「証明書」の詳細な説明はWikipedia本業の業者さんにおまかせするとして,ここで重要なのは現時点においてDV証明書はそのサーバーにアクセスするユーザーにとって通信の暗号化が行われる以外に何も保証しないということである。

今や,HTTPSだから安全なんて口が裂けても言えない状況になってしまった。

性善説から性悪説

HTTPというプロトコルが誕生した時,世界のインターネットは今よりもはるかに小さく,ごく限られた人だけがアクセスできるものだった。

利用する人が限られた存在だった当時,平文で情報を送受信することに何ら不都合はなかったし,そもそも現代と比べてハードウェアの性能が低く,暗号化を行うことにメリットがなかった。

しかしインターネットは急速に普及し,当然のことながら悪用しようとする人が現れるようになった。

通信経路上に盗聴機能を持つ機器を仕込むことにより,HTTP通信は中身を覗き見られてしまう。

例えばWebサイトへのログインであるが,HTTPはそもそもステートレスなプロトコルであり,Webサイトは利用者の判別をセッション(サーバーサイド)とセッションCookie(クライアントサイド)を用いて行う。

HTTPであれば,このセッションCookieも平文で送受信されてしまうのである。

このセッションCookieが盗まれると,あたかもその利用者であるかのようになりすましてWebサイトにアクセスされてしまう。(セッションハイジャック)

このような存在から身を守るため,インターネットは「暗号化された安全な通信」を提供しなければなくなった。

その結果生まれたのがSSL/TLS証明書と認証局であり,それを用いた暗号化通信プロトコルHTTPSだった。

「常時SSL化」の波

2000年代,クリティカルな内容(主に金銭の絡むサービス)を含む通信ではHTTPSが使われ始めるようになった。しかし,それ以外の多くのWebサイトではHTTPが主流であった。

HTTPは平文で情報を送受信する。例えば掲示板に何か書き込もうとする時,通信経路上に傍受可能な何かを仕掛けられた場合,何を書き込んだのか一字一句わかってしまうのだ。どのサイトにいつアクセスしたのかも完全に筒抜けになってしまう。

近年,情報技術の発達により皮肉にも通信経路上に盗聴器を仕掛けるのは容易になり,また プライバシーを尊重する流れが少しずつ高まってきた。誰だって自分がどのサイトを見ていたかを知られたくはないだろう。HTTPは次代のニーズに取り残されるようになってしまった。

そんな中,大手Webサービス(Google, Twitter等)は常時SSLという選択肢を選んだ。

これはHTTPによる平文での通信をやめ,全ての通信を暗号化するということだ。確かに当時に比べてハードウェアが持つ計算資源も増え,また暗号化を支援するハードウェアが実装されるようになり,プライバシーの観点からも合理的な選択だった。

常時SSL化の代償と性善説の死

常時SSL化はプライバシー面では良いこと尽くめのように思えるが,相応の代償を伴うものでもある。

通信環境への負荷の増加

暗号化通信を行うことで通信量は増加する。また,暗号化・解読処理が間に挟まることにより必要な計算資源が増え,体感速度にも影響を及ぼすことになる。※1

モバイル端末における処理負荷の増大とそれによるバッテリー消費

モバイル端末(スマートフォンタブレット)はまだまだPCに比べて処理能力に不足がある。このようなデバイスで暗号化通信を行うと,処理負荷の増大及びそれに伴うバッテリー消費量の増加が発生し得る。 特に,小さな通信を何度も繰り返すゲームアプリケーションにおいては深刻な問題になり得る。

パケット解析型ファイアウォールでの対応が困難・高負荷

HTTP時代は平文で情報が送受信されていた。その為企業に導入されるパケット解析型ファイアウォールなどでは通信内容を解析した上で悪質なプログラム・コードが含まれていないかを検出し,遮断する機能を持つものがあった。 しかし,HTTPS通信では通信の内容が暗号化されているため容易にこのような処理を行うことが出来ない。最近のファイアウォールではSSL/TLS通信の復号化機能を備える(善意とは言えもはや中間者攻撃だと思うのだが...)ものもあるが,高価であり,やはり多くの計算資源を消費してしまう。

性善説の死と性悪説の虚しさ

上記のように,性善説から生まれたインターネットは死につつある。幸いにも暗号化・復号化に関わる負荷については,PC・モバイル端末共にハードウェア支援の実装が進んでおり,負荷やバッテリ消費も許容可能なレベルになりつつある。

しかし,暗号化通信が非暗号化通信よりも計算資源を用いるものになることに変わりはない。常時SSL化は確かに安全を実現する手段の一つだが,本当に全ての通信に暗号化は必要なのだろうか。

計算資源を消費するということは,それだけエネルギーを消費するということでもある。性悪説の時代のインターネットが消費する計算資源のうち,一体何%が悪意から身を守る為に費やされているのだろうか。

また,インターネットを支える技術の多くは性善説に基づいて作られているものが多い。もちろんこれらを性悪説で設計しなおそうとする流れもある。

しかし仮に性善説がまだ成り立つのであれば,人間とコンピュータがどれだけ時間的・エネルギー的コストから解放されるのかを考えると,進む道はこれで正しいのかとふと疑問に感じてしまうことがある。

※1 : 常時SSL化と同時にHTTP/2への対応が行われる事も多いが,ここではHTTP/2による圧縮及びHTTPパイプラインの導入による効率化は加味していない。

日記 : 新年あけましておめでとうございます / 今年の抱負など

ごあいさつ

遅ればせながら,新年あけましておめでとうございます。

家から出ていないので全く新年感がありませんが,無事2018年を迎えることができました。

未熟で無力な自分ですが,これからもどうかよろしくお願いいたします。

新年の抱負

空回りからの脱却

これに尽きるかと思います。元々その傾向はありましたが,就職し成果が求められるようになってから無視できない問題となりました。

仕事をしていく上で空回りというのは多くの人に迷惑をかけることとなります。また同時に信用を失うことになり,自分にとっても会社にとっても誰ひとりとして得をしない結果となってしまいます。

人間関係に関しても同様で,毎度空回りする人と居ると相手を疲弊させてしまいます。

また,空回りが続く中で改めて認識したのは誠意は結果に繋がらないということです。

いくらその物事に対する思い入れが強くとも,環境要因(スキル・信用・人柄等)が揃わなければ叶わないものは叶いません。誠意が通じるのは学生時代までです。

思えば去年失敗したことの原因の大半が空回りだったように思います。今年は同じことを繰り返さないようにしていきたいところです。

余談 : エンジニアリングとアイデンティティ

この道に進むことを考えた時,コミュニケーションが苦手ならスキルを磨き,その分野で代替できない存在になろうと行動してきました。

しかし当然のことながら上には上がいるもので,自分はスペシャリストにはほど遠いことを思い知り,ある意味でアイデンティティを失いました。

自分だから出来ることは何なのか,自分じゃなければ出来ないことは何なのか,仮にそんなものがないとしてもそう思える何かを見つけることが次のステップ上がるための唯一の道なのではないかと思います。

2017年を振り返る

気がついたら年が明けていました。 年が明けてからやるのもどうなんだというところですが,2017年を一通り振り返ってみました。

引っ越し

就職に伴い,北海道から東京都へ引っ越しました。 慣れない環境と人の多さに圧倒されつつも,なんとか順応できたのかな... 雪がないってのは素晴らしいですね

就職

複数人で仕事をするということ,「能力」とは何なのかということを認識させられ,自分に欠けている物に気づくことが出来たという点でも良かったなと感じています。 ここらへんについてはまた別に記事にしようかなと。

娯楽・日常・イベントなど

就職後は結構な頻度で飲み会があり,また同期とダーツバーに行ったりボルダリングジムに行ってみたりと,過去の自分では考えられないくらいいろいろなことをしたように思います。特にお酒に関しては恐らく生まれてから就職するまでに飲んだ量を有に超えているような...

とは言えあまりにも多くのことに手を出しすぎて中途半端になることも多く,今年はうまい具合に調整していければなと考えています。

その他にもインディーズゲームイベントのTokyo Indiesに連れて行ってもらったり,コミックマーケットなどに行ってみたりと様々な経験が出来たかなと思います。

コード・プロジェクト

phpばっかり書いていた気がします。仕事柄なのもありますがやはり使い慣れた言語というのも大きいのでしょう。 今年はRustとかGolangとか書いていきたい。

以下のようなものを作ったりしていました。

PSR-11 Containerに準拠した依存性注入コンテナです。php 7.1以降の機能をバリバリ使っているのでなかなか使い所に困っています。あと,名前に-devと付く通り完成度としてはまだまだな感じです。

一応php 5.6xに対応したバージョンを作ろうと試みた時期がありましたが,いろいろあってやる必要がなさそうなのでやめました。

というか別に作らなくてもilluminate/containerとか使えばいいよな...

php用テンプレートエンジンです。なぜ車輪の再発明をやめないのか。

こちらもphp 7.1以上向けとなっています。変数スコープを隔離しているので比較的安全な気もしますが,正直こんな無名で採用事例もないテンプレートエンジンを使う意味なんて...

どちらかと言うとLaravelbladeを理解するために作ったという側面が大きいです。

php用コンソールアプリケーション用フレームワーク(?)です。基本的にsymfony/consoleのラッパであり,Laravel Artisan Commandとの相互運用性を考えて作られています。

パスに依存した処理やエラー時のリカバリがない適当なシェルスクリプトで書いてその場をしのぐ,みたいな運用があまり好きではなかったので,より簡単に,より簡潔にやりたい手続きをコマンド化できるものが欲しかったので作りました。

公開していませんが,これをベースにGoogle APIを用いてスプレッドシートを操作するコンソールアプリケーションを作ったりもしていました。

Web用クイズアプリケーションです。安定のMaterialize。 Laravel 5.5 LTSベースです。とある行事の為に作った物で,しばらく触れていなかったLaravelの復習がてら作ったものです。

Laravel 5.1 LTS時代のgulpを用いたelixirからwebpackを用いたmixに変わっていたり,標準でVue.jsがバンドルされていたりといろいろ変わっていてびっくりしました。

書いた記事とか

QiitaのDIコンテナの記事がその2で止まってしまっているのですが,再開出来る目処が立たないので一旦見なかったことにしてください...

以下のような記事を書きました。が,ほぼ忘備録ですねこれ。 またお話があればITMediaとかでキーボードの記事とか書いてみたいところです。

PHPで作って覚えるDI Container - その1 - DI is 何 - Qiita

PHPで作って覚えるDI コンテナ - その2 - DI コンテナとServiceLocator - Qiita

macOS Sierraにsamba 4.7.4を入れる - Qiita

macOS上のphp7.2でSMBに接続するための環境構築 - Qiita

改めて整理してみてみるといろいろあった1年でした。 つらいことも多いですが,本当に多いですが,その分成長も出来たのかなと...

そんな感じで2017年はいろいろな方々にお世話になりました。未熟者ですが,今年もどうかよろしくお願いいたします。

Firefly 0.1.2

PHP製コンソールアプリケーション作成用サンドボックス(?) Firefly 0.1.2をリリースしました。

github.com

バージョンが下がってることを気にしたら負け。

何が変わったか

  • Packagistに登録した
    • $ composer create-project zeriyoshi/fireflyでプロジェクト作成できるようになりました。
  • 運用に耐えられるものにした
    • アプリケーション名の変更ができるように
    • バージョンの変更ができるように
  • いろいろリファクタリングした
    • 適当に作っていた部分をある程度まともなように修正,名前空間の取扱をより厳密になど
    • コマンド作成オプションはあるのに削除オプションはなかったので追加したり
    • 引数を必須とするコマンドで編集,削除オプションが動かないの直したり
    • マネージ系のコマンドをfireflyコマンド名前空間に移したり

今後の課題

  • README.mdの修正だけでマイナーバージョン上げるの馬鹿らしすぎる
    • マニュアルを別に作るようにしたほうが良い,絶対
  • どうせだしDIコンテナ使えると便利そう。figurare-retroscenaをPHP5.x対応させて使おうか...?
    • いやここまでLaravelとの相互運用性重視してるならもうilluminate/containerでいいのでは...

Firefly 1.0.0

PHP用コンソールアプリケーション作成用プラットフォームFirefly 1.0.0を公開しました。

github.com

これは何

上のサイト見て頂けるとありがたいです。

composer create-project対応しないの?

まだPackagistに登録してません。

なんでこんなもの作ったの

仕事で使いたかったから

なんでブログサボってたの

仕事で使いたかったから