Because We Love Happy Coding

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

【罠】「クリックすると開く」メニューがiPhoneで動作しなかった原因が罠

コーディングをしていると「それは罠だろ」と思う瞬間があります。

教科書通りに組んでいるのに動作しない。何がおかしいのか一生懸命に調べて、そして分かった時の「 俺は悪くない 」「 そんなのわかるわけないだろ 」感。一言で言うとそれが罠です。

WordPressコメント欄が邪魔なのでたためるようにした

仕事でWordPressのサイトをいじっていたのですが、モバイル画面では記事とコメントとサイドバーが直列に並びます。

  • ヘッダー
  • 記事
  • コメント欄
  • サイドバー
  • フッター

という並び順です。コメント欄はあまり頻繁には使われないのですが、ここが場所を広くとっていると、サイドバーのカテゴリや「最近の記事」などを見てもらう確率が下がります。

そこで、デバイスサイズがモバイルと判断できる時には、コメント欄を最初は非表示しておいて、「コメント」をクリックした時だけ表示する……という施策をすることにしました。

おれの能力…幽波紋スタンドは『jQuery』。その程度のコメントなら クリックで出し入れするのは わけない、、、、

結果、「わけない」ってほどでもないですが、なんとか動くものができ、Chromeの開発者ツールで確認できました。

ところが、念のため自分のiPhoneで表示させてみたところ、「コメント」をクリックしても動かないのです。あれっ? と思ってChromeに戻って試してみると、こちらでは問題なく動きます。

なんだ!? この妙な手応え……!

iPhoneの不気味な仕様らしい

qiita.com

ええーっ。Σ( ̄△ ̄;)

俺は悪くない 」「 そんなのわかるわけないだろ 」……これが罠です。

jQuery でクリックイベントをバインドする時は

 $('document').on('click', '#hoge', function(){});

とやるのが当たり前だと思い込んでいました。それがiPhoneでは利かない……とは。

とりあえず、上記記事を信じて、cursor: pointerを指定いれたらホントに動いた。唖然。信じられなーい。

FLOCSSについて

職場でFLOCSSについて教わったのだけれど、今ひとつ消化しきれず。自分のブログのテーマをちょうど作成中だったこともありFLOCSSで書こうとしたんだけど、わからないことが多かったのでいろいろ調べてみた。

わからないこと

  • ある一つのものを定義したいとして、layoutに所属するCSS要素、componentに所属するCSS要素、projectに所属するCSS要素はどう分けるべきか?
  • ある階層化されたFLOCSS要素(BEM)があったとして、それはどのファイルに記述されるべきか。SCSSファイルの適切な分割方針

パンくずリストbreadcrumbを作る場合、l-breadcrumb? c-breadcrumb? p-breadcrumb?(それともその組み合わせたマルチクラス?) それはl-headerに記述? component/c-breadcrumbに記述? といったようなことでぐるぐる頭が回ってました。

「FLOCSS」でとりあえずググる

github.com

www.tam-tam.co.jp

これらのサイトでは、Componentは「繰り返し使われる基本的な構造」であり「装飾的なスタイルを定義することは避ける」とある。

qiita.com

こちらの記事には結果として出力されたサイト(→リフォマ − リフォーム・修理を定額価格で探せる)が紹介されており、実際のHTML/CSSを見ることができたので大変参考になった。こちらではl-container、l-contentというクラスが多様されており、「構造を分離する」という点で参考になった。

壁に付箋を貼りだして整理された写真が圧巻。ここまでやんないといけないんだ、やっぱり。大ごとだな……。

webnaut.jp

「FLOCSSを扱いきれないあなたに」……俺だ。orz

たしかにcomponentとprojectを分ける意味がわからないならまとめてしまうという手もある。

qiita.com

最初に職場でもらった参考URLがこれだった気がする。Utilityクラスの扱いについて、私もけっこう慎重派

「Block毎にファイルを切る」という記述があるので、ファイル分割の参考になった。

調べた結果おぼろげに見えてきたこ

layoutには、大きなブロック単位の構造を置く

レイアウト形状による分類なので、非semanticであるように心がけた方がいい気がする。l-headerはheaderという意味を含んでしまっているが、l-full-boxのように意味を離れて形状に特化したclassなら、使い回しが利く。

l-entry-titleとl-article-titleがブロックレイアウトとして共通のCSS要素を持つなら、それはl-titleとして共通化し、残りをc-entry-title、c-article-titleに分けるのがいいような気がする。

追記: いや、必ずしもそうとはいえないか。デバイスサイズによって形状が変化する場合にクラスをつけかえることになってしまう。この辺りのダイナミックな変化をうまく吸収できるようにclassを分けていく作業は、なかなか骨が折れるな……

componentはページをまたいで繰り返し利用されるパーツ

全project中で繰り返し登場する共通の要素(パーツ)、として認識した。

装飾的な要素を含めないとするサイトもある一方で、装飾的な要素もcomponentに書いている例も見受けられるので、そこはあまりキニシナイことにした。なぜ装飾的な要素を避けないといけないのか、理由がよくわからないしな。

projectは、テンプレート固有の要素

これについては、私が念頭に置いているのがブログということで、認識しづらいのかなと思っている。

ブログの場合には、テーマファイルのテンプレート分割に倣うのが良い気がした。曰く、p-front-page、p-single、p-archive、p-searchなど。

参考にしたサイトでは「4回以上繰り返されるものはcomponent、3回以下ならproject」といった登場回数で区分しているものもあったけれど、個人的にはprojectは「componentで対応できない、個別の要因を記述する」場なのではないかと想像している。つまり「singleページとarchiveページに登場する同じcomponentなんだけど、singleページとarchiveページで見栄えが異なる」といったことに使ったら使いやすいのではないか。

となるとprojectには「全ページ共通パーツだけど、そのうちでprojectに固有のCSS要素」「project専用パーツ」という、粒度の異なる記述が含まれることになりそう。

また、「基本的な構造をcomponentに記述しておいて、プロジェクトメンバーが追加するCSSはprojectに追加させる」という記述も見つけた。「サイトの基本マナーはcomponentで、それから逸脱する記述はproject」ということで、サイトの基本マナーを保護する思想になっている。だとすれば、最初projectは空っぽでも構わないわけだ。

ある一つのものを定義したいとして、layoutに所属するCSS要素、componentに所属するCSS要素、projectに所属するCSS要素はどう分けるべきか?

  • 大きなブロック構造に関する記述 → layout
  • 繰り返される(つまり共通の)要素 → component
  • ページテンプレート固有の要素 → project

ある階層化されたFLOCSS要素(BEM)があったとして、それはどのファイルに記述されるべきか。SCSSファイルの適切な分割方針

これはまだ明確ではないんだけど、Block単位でSCSSファイルを作り、そのファイル内にElement、Modifierを入れていくことでいいみたい。でないと、そもそもSCSSの階層化された記述を活かせないしな。

Block単位でSCSSファイルができるので、だいぶSCSSファイルの数は増えるけれど、どうせ最後はapp.cssに集約されるんだし、とりあえずやってみよう。

同じcomponent classの中にも役割の違いが出そう

たとえば、タグの内容によって色を変えたいとする。果物(いちご、りんご、みかん)は赤、野菜(きゅうり、ほうれんそう)は緑といったこと。

この場合、タグとしての共通の振る舞い(サイズ、フォントなど)はc-tagとして記述し、色に関する記述はc-fruit、c-vegieとして分けることになるはず。

この辺はFLOCSSとは無関係に「共通項目をクラス化する」という基本的な分割思想の部分なわけで、その辺を混ぜて理解しようとしてごっちゃになっていた。

Utilityクラスが解決できる部分もあるかもしれないけど。

まとめ

  • 大きなブロック構造に関する記述 → layout
  • 繰り返される(つまり共通の)要素 → component
  • ページテンプレート固有の要素 → project

  • SCSSファイルはBEMでいうところのBlock単位で作成し、Element__Modifierはその中に記述する。

  • projectには「全ページ共通パーツだけど、そのうちでprojectに固有の要素」「project専用パーツ」の両方が含まれる
  • いずれにせよ、「何を共通項目としてクラス化するか」はよく考えないと、FLOCSSが解決してくれる銀の弾丸ではない。

……いや、すまん、「銀の弾丸ではない」て一度言ってみたかっただけで。

Emmet でhr.を展開したら世界が変わった

f:id:mogami74:20170925173513j:plain Brackets でうっかり「hr.」と打ってタブキーで展開したら展開されてびっくりした。class付のhrタグ。

もしや、と思って「hr#」を展開したらid付のhrになった。成ル程〜! 納得感ある。

最近は「Ctrl+Aタグで囲む」だけではなく「Ctrl+Iタグを変更する」「Ctrl+Kタグを削除」を使いこなせるようになってきたので、htmlコーディングのスピードが少し上がった。

…早くブログのデザイン修正したい。資格試験のある10月いっぱいは我慢して勉強。それが終わったらガリガリ書きたい。

学習者のための「レストランJava」

f:id:mogami74:20160813060312j:plain

以前、Java学習者の一助にと思って、小さなJavaのプログラムを作った。

効用

Javaの基本であるclass間のデータのやりとりがわかる

ダウンロード

javaRestaurants.zip - Google ドライブ

推奨の利用方法

  1. 各classのソースコードをA4各1枚に印刷する。(合計5枚)
  2. Restaurantクラスのmain()メソッドから処理を開始した場合に、どのような処理が実行されるか、順を追って把握する。
    書き込みするのもいいね。
  3. 想定される出力(実行後の画面表示)を書いてみる。手書きでもテキストファイルでも可。
  4. クラス図やシーケンス図を書き起こしてみる。
  5. ソースコードを実行環境に入力し、実際に動かしてみる。
  6. ソースコードを改造して遊ぶ。具体的な例としては
    • 「Guest.payment()メソッドをドル支払い(double)に変更できるよう、関連するメソッドをオーバーロードしてドル建てに対応する」
    • 「新規にLoveStoryクラスを作ってそこにmain()メソッドを記述し、他のクラスにも必要な記述を追加してboyAとgirlAの間のラブストーリーを展開する(テキストアドベンチャーゲーム風?)」
      いや、冗談じゃなくてですね、他のクラスからも呼び出しされうるオブジェクト志向の思想に関する勉強なわけですよ。戦争とかゲームが人類の技術の発展に貢献してきたことは紛れもない事実でありまして。LoveStoryクラス作った人がいたらここに追加するのでソースコード下さい。
    など。

推奨の利用方法にまつわる留意点

  • Java(に限らずプログラミング言語全般)の処理は、1行ずつ厳密に実行される。「どのような処理が実行されるか、順を追って把握する」にあたっては、メソッド間の行き来を含め、行番号単位で処理が説明できるようにすること。「Hogeクラスの5〜10行 → Honyaクラスの8〜12行 → Hogeクラス11〜20行 → …」のように、実行される順番が行単位で説明できること。
  • 引数、戻り値については、その中身が具体的に何であるか、きちんと説明できること。
  • 実行順については、Javaの得意な人に時間をもらって、その人に対して説明をしてみると良い。
    ただし説明するだけでたぶん30分くらいかかるし、その後正しい解説をもらうともうちょっとかかるので、コーヒー一杯くらいおごっていいレベル。コーヒーとケーキなら尚良い(紅茶とケーキも可)
  • Restaurant.main()メソッドを最後まで処理しきれず、途中で挫折した場合はJavaの理解に課題があると思われるので、誰かに助けを求めること(無理にとは言わないが)

prj_LvUp: ココマデの開発経緯、およびロゴ出来た

2017年3月に訓練校を出た後、そこでできた友人に誘われたQPro(休日プログラミング部)で、prj_LvUpというwebアプリケーションを作っている。

数年前から「あったらいいな」と思っていたもので、アイデア勝負みたいなもんだけど、類するサービスは見たことがないし、プログラミングの勉強にちょうどいいかな、と思っている。

ここはその開発日誌も書いていきたい。

イデア勝負なので、組み上がるまで詳細は書かないことにする。ってサービスインしても大手が出て来たらあっという間に負けそうだけどナァ。勉強勉強。

仕様

基本は素のPHPで、でも一応MVCっぽい色気を出してみた。当初Laravalを予定していたけれど学習が面倒になり素PHPに仕様を変更。そしたら職場でLumen by Laravelをやることになったので、Lumen採用してもいいかなー、と一瞬思ったけどやっぱやめとく。

CSSは職場でFLOCCSというのを教わる予定なので、それを入れようと思っている。それの勉強をしてたらSASSもついでに勉強をしようかと思い始め、DreamweaverにSASSの機能があることに気づいて導入してみた。Compassを導入しようとすると常に必ずDreamweaverが強制終了するのでクサっているところ。とりあえずアップデートしてみたら、強制終了しなくなったみたいなので、しばらくはこれで怖々使ってみることにする。

www.tam-tam.co.jp

こちらのサイトで最高に参考になったのが、「最初はSCSSファイルにCSS直書きでもいいんですよ」という情報。ああそうか。なんとなくSCSSの呪文を覚えるまでは一行も書けないと思い込んでいた。だいぶ気が楽になった。

スケジュール

5月の部会に要件定義書を提出して、WorkBreakdownStructureみたいなものを書いてスケジュールを切った。あまりスケジュールをガチガチに追いかけるつもりもないけれど、切っておかないとズルズル遅れるので。既にもうだいぶ遅れている。

部会は隔月で、7月の例会でユースケース図を出した。9月の例会も既に終了し、そこでシーケンス図を出している。
やっぱりこういう部活動みたいなものがあってよかった。一応「何かは作って出さなくちゃ」という気になる。フルタイムで働いているメンバーはなかなか提出物がないけど、そりゃそうだ。週3しか会社に行ってない私でさえ、けっこうギリギリにガーっと時間を作ったりしているくらいだ。

シーケンス図からクラス図みたいなものも起こした。クラス図とシーケンス図の順番が逆じゃねーかという気もちらっとしたのだがキニシナイことにする。クラス図っていうかメンバー変数とメソッドの一覧程度のもので多重量化とか全然書いてないけどキニシナイことにする。

ロゴ

画面遷移図はシーケンス図みたらなんとかなりそうな気がしたので、次はカンプだな、と思ったけどカンプ描くにはロゴが要るな、と気づいてロゴを作った。

f:id:mogami74:20170912104024p:plain

矩形のロゴも。

f:id:mogami74:20170912104028p:plain

もうちょっとなんかかっこよくファミコンっぽくできないかと思ったけど、なんともならんかった(苦笑)

まぁいい。とりあえずこれで進めよう。またいいロゴを思いついたら変えればいいさ。

formのリセットボタン(input type = reset )と同じ挙動をjQueryで起動する方法

jquery でイベント登録フォームを作った

パパゴトというサイトを作っていて、そのトップページには「赤羽から行けるイベントのリスト」というのをつけている。これはPHPとデータベースで実現している。

ここにイベントを誰でも登録できるようにしようと思ってあれこれいじっていた。

jQuery.noConflict()

digwp.com

この記事のおかげでWordpressのcustom_head内にjQueryを書いて動かすことができるようになった。おおーし。

js.studio-kingdom.com

フォームの内容をserialize()して、post()メソッドでPHPへ送信。 成功したらフォームの上に「登録できました」メッセージを載せてわかるようにした。

jQuery によるformのリセット

submit ボタンを使わない状況では送信後にフォームの中身が消えてくれないので、フォームの中身を消す方法を探す。

「formの初期値に戻すのではなく削除したい」というニーズに沿った難しげなjQueryやそれを丸ごとパクっている恥知らずな記事を横目に、いや、ここまでややこしくしなくてもあるだろう……と思って探す。求める正解「formのリセットボタン(input type = reset )と同じ挙動をjQueryで起動する方法」を見つけるまでに苦労した。

alphasis.info

正解は、jQueryじゃなくてraw JavaScriptでした。

blog.dododori.com

これが正解。

$(‘#form’)[0].reset();

で、きちんと動く

iPhoneでHTMLとかPHPとか書きたくなってきた時に見る記事。2017年9月版

はてなブログの記事はマークダウン記法が直接使えるので愛用のマークダウンエディタBywordで下書きしているのだけれど、Wordpressの記事はマークダウン記法が直接使えるわけではないし、HTMLを直接書いてclass指定したかったりすることもある。それに加えて最近はPHPも移動中に書きたくなってきたので、iPhoneで使えるいいエディタが欲しいな……と思って探してみた。

Editorial

tyablog.net

iTunesStoreでは評価が15個あって4.5と高い。時価600円。ただしマークダウン記法がメインっぽい。

ちなみに私が今愛用しているマークダウン記法のエディタbywordの評価はいくつだっけ、と思って見たら評価3.5だった。

公式サイトにあるアプリのスクリーンショットを見て行くと、思った以上にパワフル、高機能でこれはたしかにすごい。Pythonで自動化できんのか……。

Editorial

Editorial

  • omz:software
  • 仕事効率化
  • ¥600

DraftCode PHP IDE

www.webprofessional.jp

PHP関連のエディタで評価がまともなエディタを探すのは難しい。これはレビュー7件と少なめだが、4.5ある。時価1,300円。

レビューによれば「iPhoneで書いて動作確認してからDropbox経由で母艦に移して」って天国かよ。ゴクリ。

WordPressPhpMyAdminが動くって……すげえな。

しかしPHPのバージョンが固定されちゃうと思うけどその辺はどうなんだろうな。PHP7とか書きたくなったら逆に困らないか。

DraftCode PHP IDE

DraftCode PHP IDE

  • Solesignal Limited
  • 仕事効率化
  • ¥1,300

Textastic

時価1,200円。評価14件で4.0。PHPにも対応。悪くない。ただし「ATOK for iOSと相性が悪い」と書いているレビューがあって気になる。

Emmet対応だって。そりゃすごい。

Textastic Code Editor 6

Textastic Code Editor 6

  • Alexander Blach
  • 仕事効率化
  • ¥1,200

Coda

www.webessentials.biz

ブログなんかの評価を見る限り定番アプリだと思っているけれど、3,000円と高価な割に、レビューは不具合の報告が多い。評価は3.5。

https://panic.com/jp/coda-ios/panic.com

Coda

Coda

  • Panic, Inc.
  • 仕事効率化
  • ¥3,000

GoCoEdit

matagotch.hatenablog.com

ここのブログではけっこう誉めてるな。マークダウンの文字化けだけ気にしなければけっこういいということか。Bywordと併用するならアリかも? 時価840円で少々お安い。

GoCoEdit - Code & Text Editor for DROPBOX FTP SFTP

GoCoEdit - Code & Text Editor for DROPBOX FTP SFTP

  • Christoph Gogolin
  • 仕事効率化
  • ¥840

以下選外

レビューなどを見る限り品質に不安があるもの。今後バージョンアップとかで安定したら価値が上がるかも?

Buffer editor

Buffer Editor - Code Editor

Buffer Editor - Code Editor

  • Jesse Kuronen
  • 仕事効率化
  • ¥600

Source

これはGitクライアント内蔵らしい。レビューは1件しかないので判断は保留。しかしGitを使うならいいかも。他にもGitクライアントらしきものはいくつかあるので、別ジャンルとして調査しないとなんとも言えないかな。

Source - git client and code editor

Source - git client and code editor

  • Ian McDowell
  • 仕事効率化
  • 無料

Code Master

Code Master - Source Code Editor

Code Master - Source Code Editor

  • Justin Bush
  • 仕事効率化
  • 無料

まとめ

今回の趣旨から言えばTextasticかなぁ。スクリーンショットCSSなどいろんなコーディングができる感じがして好感。

Textastic Code Editor 6

Textastic Code Editor 6

  • Alexander Blach
  • 仕事効率化
  • ¥1,200

Editorialはたしかにすごいんだけど、マークダウン記法は今回求めていない。というかBywordで割と満足していて、それ以上の機能を使いこなせる気がしない。

DraftCodeも興味あるけど、バージョン固定になっちゃうのがなぁ。JavaScriptとか書きたくなるかもしんないし……。

参考URL

iPadでアプリが作れる!?iPadを利用した開発環境まとめ | Tech2GO

blog.codecamp.jp

iPhone / iPad 上の開発環境 2016年度版 - NAVER まとめ

matome.naver.jp

iPadを「Web開発マシン」に変貌させる、おすすめ神アプリを集めてみた! | シェアしたくなる最新のWebサービス・ITニュース情報をチェック! APPGIGA!!(アプギガ)

plus.appgiga.jp