読者です 読者をやめる 読者になる 読者になる

mogami74開発日誌

フリーライターがPHPとかJavaとか勉強してます

学習したい項目リスト

勉強したい項目をwri.peにメモっていたんだけど、あちらは開発ネタに特化しておきたいので、こちらに書いておくことにする。時々更新。

since 2017-04-13(木)

「学習項目」はおよそ高い確率で学習するもの。「検討中」は、単語の意味がまだよくわからない、潮流がよくわからないなどの理由で調査中・検討中のもの。

リストは順不同。気が向いたら、優先順位つけるかもしれないけれど、でもたぶんその時々の開発状況によって優先順位はころころ変わりそうな気もする。

学習項目

JQuery

MySQL

パスワード認証

ajax

LESS, Sass

Bootstrap

JavaMail

PHPでのExifデータ読み込み

印刷仕様特にMac

VBA

Java GUI アプリ開発

VPS

ドットインストールに「さくらのVPS」がらみの動画があるらしい。

検討中

Laravel

CoffeeScript

webpack

Autoprefixer

TypeScript

TypeScriptはMicrosoftによって開発された”静的型付けクラスベースオブジェクト指向言語”です。 --via 今時のフロントエンド開発2017 (1. 愚痴編) - Qiita

  • PHPメール送信

文学部卒ノンプログラマーのフリーライターが作りたいWebサービス

f:id:mogami74:20170412071553j:plain

私は文学部卒で(といってももう20年近く前に卒業したんであまり意味はないが)、一昨年会社(製造業)を辞め、昨年一年間は学校に通って、HTML、CSSJavaScriptPHPJavaを学んだ。まだ実務経験はない。春からはフリーライター(前職の前はフリーライターだった)や講師業をしている。

いろいろやってる人たち

ferret-plus.com

こんな記事を読むと、やはりプログラミングしたい、サービスを公開したいという欲求を持った人はいろいろあるものだ。なんとなく会社を辞めた自分がやると脱サラして蕎麦屋(あるいはペンション)を始める感覚に似ているのだがそれって昭和的な感覚だろうかね。え、もしかして一種の死亡フラグ? 

作りたいもの

wri.pe」に開発メモを作って、作りたいものをまとめてある。どういう順番で手を付けるかが今のところ悩み。悩みというほどでもないか。贅沢な悩みだな。

自分の考えているアイデアのうちで、「人をポジティブにするWebサービス」という切り口でまとめられるものが3つあったので、これは「PositiveScript」という名前でシリーズ化しようかな、と思っている。これはイメージがそこそこ見えているので、早く形にしたい。

一方で、自分用のデータベースを作りたいという欲求もある。日々の生活を便利にしたり、あるいはライフログをとって、その中身をブログに活かしたりといったことを考えている。これは日々蓄積するものなので、早くスタートさせたい。データベースとテーブルは既に思いついたら作るようにしているので、少しずつ蓄積はしてるけれど、MySQLを直接叩くのは(PhpMyAdmin経由とはいえ)やはり手間がかかる。DAO(DatabaseAccessObject)の勉強という意味でも早めにやりたいところ。

あとブログの機能追加。CSSPHPWordPressの知識がついたので、いろいろいじりたいところがあって、特に以前、演算処理が面倒で2回諦めた企画もの(文具ブログ)については、再挑戦したいと思っている。3度目の正直のたぶん今なら(というか今度こそ)できるはず……!

勉強も……

employment.en-japan.com

こういうの読むと、業務レベルでは(もう)PHPあんま使われてないんだなー、という気がする。Ruby on Railsの方が多い。それどころかPerlってどこ行っちゃったんだ? メルカリとはてなブログはまだPerl使ってるみたいだけど。

そういうわけでRubyはちょっと興味ある。フレームワークも、Laravelとか。あとSwiftやObjective-C。自分がメインで使っているのがMaciPhoneなので、自分で使いやすいアプリとか作りたいなぁ。

と思うと、やることがありすぎてパンクする。

手を動かす

とりあえず手を動かさないといけない。Keep the Circle Turning.

幸い、友人がプログラミング部活的なものを月1回やろうと言ってくれている。上記のどれかを持ち込むことになると思う。

作って人に見せて面白いのはPositiveScript Level1かなー。文具ブログかどっちかだと思う。両方企画持っていって、他の人の反響や動向を見ながら決めようかな。

アルゴリズムの粒度

アルゴリズムの初歩を教える時に、よく「一日の手順をフローチャートに描く」とか「味噌汁の作り方をフローチャートに描く」とかって練習させる教師がいるんだけど、その際に説明を省略しがちなのが「粒度」について。たぶん、教師自身が無自覚なのでそういうことになる。生徒はこれだけでだいぶ混乱しがち。

たとえば「朝食を作る」というフローの中では「味噌汁を作る」が1つの項目だけで記述される場合もあるし、「味噌汁のレシピ」というフローの中では「豆腐を切る」「豆腐を煮る」「だし入れる」「味噌入れる」というレベルで項目が記述されることもあるし、機械工学的にロボットに味噌汁を作らせるフローなら「豆腐をつかむ」「豆腐をこの角度で切る」「豆腐を持ち上げてお椀に入れる」というところまで項目にする。

つまり、粒度が様々なのだ。この辺りをきちんと説明してあげないと、初心者は戸惑ってしまう。最初は粒度を揃えるために「豆腐を切る」「豆腐を煮る」「だし入れる」「味噌入れる」という選択肢を用意しておいて、順番を考えさせるくらいから始めるべき。その際に、粒度の説明も一緒にする方が良い。

本来のコーディング設計においては、言語の組み込み関数の知識があって初めて粒度を想定できる。

たとえばよく「最大値を求める」アルゴリズムを考えさせたりするけれど、言語によっては「最大値を求める関数」が用意されているわけだから、普通はそれ一つで処理が終わる。だから、そういう組み込み関数がある前提でアルゴリズムを描くなら「最大値を求める」で終わりで、くどくどその中身を考える必要は(あまり)ないはずだ。

練習問題でも、想定の粒度を明記しておかないと、はっきしいって解けない、と思う。

headタグの中身が見えてしまったら

同級生SさんからのSOS。

head要素の中身、特にtitle要素とscript要素の中がブラウザに表示されてしまうのだという。同級生の中でもデキるSさんからのSOSなので、まさかそんな、と思いながら画面を見せてもらった。(画面はサンプル)

f:id:mogami74:20170317034112j:plain

たしかにtitle要素の中身、本来、ブラウザウィンドウのタブ上にとか、ウィンドウバーに表示される内容が、ブラウザの画面内にも表示されている。タブ上にも表示されているので、title要素としての機能は生きている。meta要素などは画面にこそ表示されないが、やはり機能は正常。

タグの綴りミスなども見て見たが、間違っているように思えない。

私が画面を見て首を捻っていると、同級生が集まってきて検討に加わった。

才気あふれるKくんがふと「display:noneにしてみたらどうなるんですかね」と言った。

解決編

開発者ツールでtitle要素に「display:none」を指定してみると、ちゃんと消えた。それどころか、もともと「display:none」という指定があったのが、打ち消し線で「無効」になっていたのを発見した。

無効化された「display:none」の出所は「user agent stylesheet」つまりブラウザのデフォルト状態だ。

f:id:mogami74:20170316164543j:plain

謎はすべて解けた。

そもそも、ブラウザはデフォルトのスタイル指定を持っている。padding やmarginの指定がブラウザによってまちまちなのはよく知られており、それをリセットするための「リセットCSS」といった考え方も存在する。

実は、head 要素やtitle要素のデフォルトのスタイル指定が内部に存在し、それは「display:none」になっているらしい。逆に、普通のhtmlページで、head要素とtitle要素に「display:block」を指定すると、Sさんのページと同様、title要素の中身を表示することに成功?した。

実はmeta要素も「display:block」されていたのだが、meta要素はそもそも空要素のタグで閉じタグがないので、innerHTMLが存在しない。だから画面上に表示されるものがないのだ。title要素やscript要素はinnerHTMLがあるので、表示されてしまう。

Sさんのスタイルシートを確認したところ、リセットCSSの一環として、全称セレクタで「display: block」を指定していたことが判明。

html * {
    margin:0;
    padding:0;
    display:block;
}

なるほど。これがそんなふうに出てくるとは思わなかった。勉強になった。

オブジェクト指向とUML

仕事先からもらった資料でオブジェクト指向の勉強中。だいたいは知っていることだけど、時々は知らないことも出て来て勉強になる。

カプセル化情報隠蔽

  • カプセル化……データと操作をひとまとめにして扱うこと。
  • 情報隠蔽……データへの直接アクセスを阻止すること。

これまで両方ひとまとめにしていた(資料では「そういう技術書もある」と補足されていた通り)ので、カプセル化の概念がいまひとつわからなかったが、これで合点がいった。

汎化(継承)と拡張(extends)

もらった資料では継承と拡張の違いがよくわからなかったので検索して調べた。

www.itsenka.com

汎化

「is a」関係、つまり、「ユースケースB is a ユースケースA」または、「アクタB is a アクタA」の関係が成り立ちます。

拡張

ユースケースAに対して、機能を追加するようなユースケースBの関係を示します。

なるほど。汎化の場合は、「〜のうちの一種」という関係で、抽象化の逆になる、ということか。

また、アクター間でも汎化が使える、というのは新しい気づきだった。オブジェクト側でばかり考えていた。これまで、アクターが汎化されるようなケースでいろいろ悩みがちだったので。

抽象クラスとインターフェイス

  • 抽象クラス……データ項目と抽象操作をまとめたもの。

  • インターフェイス……抽象操作のみをまとめたもの。

Enumulateインターフェイスとか、よくわからず使っていたけれど、なるほど、抽象操作(メソッド)という観点で把握すればいいのか。

ユースケース記述

ユースケースの内容を詳細に記述する。このDescriptionsから処理を書き起こしていけばいいわけで、わかりやすい。これまでユースケースから「えいや」でそのまま処理を起こしていたので、自分でも「どうも大雑把だな」と感じていたし、先生にも「関数化が未熟」と指摘されていた。ここのところをきちんとやれば改善されそう。

シナリオ記述も同様。

ロバストネス分析MVC

  • ロバストネス分析……エンティティオブジェクト、バウンダリオブジェクト、コントロールオブジェクトで分析する手法。らしい。

  • バウンダリオブジェクト……アクターとシステムの接触点を示す。画面とか。これはMVCのViewになると思われる。

  • エンティティオブジェクト……現実世界のオブジェクトを表現する。これは主にMVCで言うModelになると思われる。

  • コントロールオブジェクト……ユースケースに対応する。ユースケースの完了と同時に消滅する。

この説明のおかげで、MVCの意義がやっとわかってきた。というかコントロールオブジェクトの意義がやっとわかってきた。コントローラにすべての機能を渡すのは「fatty(肥大化) controller」として嫌われるというのはまぁ分かるんだけど、こういう基準があれば、fattyかどうかの判断がしやすい。

管理オブジェクトというのもあるらしい。オブジェクトの生成や削除を管理し、リストを持つことで外部からの利用が便利になる。これもなかなか為になる。

追記

必ずしもロバストネス分析MVCと一致するわけでもないらしい。

https://inoccu.com/blog/2014/01/26/153315.htmlinoccu.com

さくらのレンタルサーバーからメール送信する

PHPでHTMLメール送信

フォームで情報を入力してもらった際、PHPから同時にメールで情報が飛ぶようにしたい。せっかくだからHTMLメールを送信できるか、試してみよう。

ameblo.jp

メール届くだけならこれで届いたんだけど、まだ中身がぐちゃぐちゃ。むむむ。 ということで、もう少し情報を探してみる。

タイトルからしてキャッチー。nice html email、まさにそれだよ私が送りたいのは。

Sending Nice HTML Email with PHP | CSS-Tricks

\r\nってのは改行コードだよなこれたぶん。

charsetの指定、海外サイトだとちょっと不安だったので日本語のサイトを探した。 coliss.com

techblog.ecstudio.jp

ちゃんと情報は届いたんだけど、htmlタグがそのまま見えちゃう。うーん、何が問題なんだ? 

mb_convert_encodingのエラー

いくつかいじっているうちに、「mb_convert_encoding(): Illegal character encoding specified」のエラーが出てしまった。むむむ。悪化してるじゃん。

apocriphanet.blog17.fc2.com

qiita.com

この辺り参考になる。

どうも、mb_convert_encodingの文字コード指定に間違えて変な文字列を書いちゃっていたみたい。

mg_internal_encoding(“UTF-8”)にしてmb_convert_encoding(‘From:hoge@hoge.ne.jp\r\n’,‘JIS’,‘EUC-JP’)にするととりあえずエラーはおさまった。

メールのソースを比較

自分のところに正しくhtmlで届いているメール(たとえば、Pinterest)と、htmlソースが見えちゃうメールのオリジナルソースを比較してみた。

あれ、Content-Typeがtext/plainになってしまっている。おかしいな。ちゃんとtext/htmlで書いてるんだけど、反映されてない。

よく見ると、From行から後の改行コードが認識されず、\r\nでつながっちゃっている。改行コードが問題か。

blog.poyo.jp

ちゃんと\r\nで記述しているのだけれど、オリジナルソースの方は「From:hoge@hoge.jprn MIME-Version":1.0\r\n」のように、最初のFrom行の末尾のバックスラッシュが認識されずに溶けてしまっている。なんだこりゃ。半角アキを入れたりしてみたが、効果無し。

php mb_send_mail 改行コード バックスラッシュが消える」で検索して、いくつかポチポチ見ていたら、答えが見つかった。

www.tryphp.net

おお。シングルクォートのせいか。無意識にシングルクォート使ってたから気づかなかったわ。

いくつか阿呆な記述ミスを修正したら、無事、HTMLパースされたメールが届くように。やったー!

いくつかの記事で「CSSはインラインで書くように」とあったけれど、Pinterestのメールはスタイル要素使ってヘッダに書いているようなので、その辺は今後の研究ということで。

jsonデータを開いて連結する

json_encode()で作ったデータをつなぎたい。

最初はMySQLのクエリでLEFT JOINしようとしたんだけど、欲しいデータが2重ループみたいな感じになっている。

foo1
 bar1
 bar2
foo2
 barA
 barB
 barC

MySQLのLEFT JOINで作ると、1段階目のデータが重複してちょっと扱いづらい。まぁ重複して出て来たデータは無視すりゃいいんだけども。

foo1 bar1
foo1 bar2
foo2 barA
foo2 barB
foo2 barC

MySQLの結果もらってfetchで回す時に、2重ループ作るしかないか…。

while($result1=$stmt->fetch(PDO::FETCH_ASSOC)){

 echo json_encode($result1);
 while($result2=$stmt->fetch(PDO::FETCH_ASSOC)){
  echo json_encode($result2);
 }

}

いや、待てこれもダメだな。json_encode($result1)の中にjson_encode($result2)を入れてやらないといかんのだな。$result1開いて書くしかないか……。

echo "{";
while($result1=$stmt->fetch(PDO::FETCH_ASSOC)){

 echo $resutl1['hoge'];
 echo $result1['honya];
 while($result2=$stmt->fetch(PDO::FETCH_ASSOC)){
  echo json_encode($result2);
 }

}
echo "}";

……正直めんどくさいけどしょうがないか。