フラメンコに関すること、フェスティバル・デ・ヘレスに関することを書き散らしています。ヨロシクね。
2020年01月08日 (水) | 編集 |
はじめて触れた記事が、ぐぐ地図のAjax関係の記事だったので
同期とか非同期とか、、、
理解したくない概念がしょっぱなに出てきたから漢らしくスルーした。
女ですけど

教室のウェブサイトを作り直している最中なんだけど
 1)クラスの時間割のセルをクリックさせ
 2)「体験レッスン」の申し込みフォームを表示させるシステムを書くつもり。
あくまでつもり
そんな大層なロジックじゃないのでスクリプトのフローは考えるまでもないくらい。
ほんの少しだけコードを書ける人だと
 1)ぐぐカレンダーにクラスを登録してウェブサイトに貼りつけ。
 2)本来の使い方だと、その日付の登録内容の詳細表示しかサポートされてないけど
 3)ちょこっとハックして「メール送信フォーム」を起動させるようにする。
ってカンジかな。
ただねぇ~、、、月間カレンダーって呼び方でいいのかな?
1日から月末まで日にちがダラ~っと並んでて、そこに予定が書き込んである的
ビジネスマンのみなさんがお持ちの見開き手帳みたいなあのカレンダーね。
あのお仕着せカレンダーを表示したくないわけです。
だって、フラメンコ教室の時間割なんて週のスケジュールの繰り返しだし
31日間、4週間方式のカレンダーをスマホに表示するって老眼いぢめじゃん(苦笑)。
表示は小学校の黒板の横に貼ってあった時間割@1週間でいんだよね。
ぐぐカレンダーも週間カレンダーを表示するオプションあるんだと思うけど
見た目がブサいからスタイルシート書かなくちゃならないし
無闇に高機能なんで使い方を会得するの面倒だし
その上でぐぐカレンダーのAPIを調べてカスタマイズするとかアホすぎるのでやる気なし。
しかもスケジュール登録も、一週間分を入力したらあとは繰り返しじゃん?
だけど、おそらくあれは
今日は品川、明日は恵比寿、、、みたいな営業マンの手帳よろしく
日々違うスケジュールを書き込めるだけに
繰り返しのスケジュールなのにちまちま1日づつ登録するんじゃないの?
ま、お決まりの帰社日とか会議日に対応すべく
お決まりの繰り返しスケジュールを登録する機能もありそうではあるけど(?)

キラキラIT企業のプロジェクト管理的なフローには合っているのだろうけど
町の習い事教室のニーズにはまったく合わないし、使わない機能満載。
汎用アプリってのはそんなもんです。
なので自力でフルスクラッチする主義です。

手でhtmlコードを書いたこんな時間割がある。
この表のセルをクリックすると
ポップアップで「体験レッスン」を申し込むフォームを起動するようにしようかと。
こんなカンジ。
体験レッスン申込ボタンを押したら、メール送信フォームを表示するわけですわ。
この申込ボタンの押し下げアクションがひと手間余分じゃね?
と、思うでしょ。
余分だけど考えあっての余分な手間です。
 モバイル用の時間割はこんなカンジで横長ならないように表示している。横長時間割とちがってセルあたりの要素は、3クラスある日なら3クラス分、1クラスしかない日は1クラス分。ひと口にセルといっても表示内容がちがうのです。それぞれのクラスごとに個別のリンクを張り、ワンクッションをおかずに直にメール送信フォームを表示することはできる。むしろそのほうがコーディングは楽。でも、たぶんリンクを押しにくい ぐぐちゃんのモバイルフレンドリーテストでも「リンク要素同志が近すぎます」的な警告をされるハズ。なので

ポップアップの内容をこのように変更するわけです。

多少コードが複雑にはなるけど
時間割を表示するときに個別にリンク貼るのと手間的にはどっちもどっち。
なら、パソコンでアクセスする人には冗長だけど
モバイル専用のコードなしで、とにかく共用する方向でサイトを構築しておいたほうが
メンテナンスが超楽~
ま、サイトを公開したらめったにメンテナンスなんかしないんだけど、さ
メンテナンスする必要がでてくる頃にはぢぶんの書いたコードがわけわかめで
思い出すというよりは解析にちかいことになるから今までやったためしがないけど、さ
くらいにはコードを書けるので、最終的には
横長時間割からのリクエストには「申込みボタン」のポップアップを省略して
いきなり「メール送信フォーム」を表示させるつもり。
でも、それなりに処理が複雑になるのでハマって時間とられたくないから
当面はモバイルと非モバイルで条件分岐するコードを書かない方向で処理するわけ。
追い込みスクリプトを書くころにはイヤになってやらないだろーな
って気はするけど、ネ

で、「申込みボタン」を押されたらダイナミックHTMLで
ポップアップの中味をダイナミックにメール送信フォームに書き換えて
お名前とかメアドなんかを記入してもらったメールを受け取るPHPに飛ばす。
そこはPHPなのかよ(苦笑)。
JavaScriptでも書けるんだけど、ハッキング対策が面倒くさいので
スクリプトをそう簡単にロードしたり改変したりできない
サーバーのセキュリティに守られたサーバーサイドスクリプトに投げるのが旨い。
ハッキングとゆーと、一般的にはサイト改竄とかをイメージすると思うんだけど
ウチのお稽古場のごとき弱小商店のサイトを改竄する暇人はおりません
でも、メール送信スクリプトを不正に起動して
スパムメールの踏台にする的なハッキングは超ポピュラーなので
サイト運営者は人様に迷惑がかからないように
メール送信スクリプトとかの設置にはキチンと気をつける必要があるのです!
あるのです! あるのです! あるのです!
できない人は仕方ないけど、少なくともコードを書けるコーダーたるもの
そのくらいの良識を働かせるのは義務なのです!
なのです! なのです! なのです!

と、ここまでゴールが見えた状態になると
現在、手でhtmlコードを書いている「時間割」をスクリプトでの登録にしたくなる。
むしろ、スクリプトに落とさないと
「体験レッスン申込みスクリプト」用のプレインテキストなデータを
手で書くハメになるのでローテク極まれり
ただ、そこまで手をかけると時間がかかってしゃーないから
さしあたり時間割はhtmlファイルにhtmlタグで書いた状態で放置だし
その内容と完全にリンクしているcsvなりjsonなりも手で書いてしまう作戦
「時間割」が変更になると、htmlファイルとデータファイルの両方を書き直しになるので
非常に効率がわるいんだけど、、、
専業じゃないのでスクリプトを書くのに割ける時間はそれほどない。
ひとまずサイトを公開して稼働させるには
本来スクリプトでやったほうが旨い部分も手書きでやっておくってわけです。

ぢぶんの力量のほどはわかっているから
時間のかかりそうな動的な機能はいっさい省いたローテクサイトをまず公開する!
ローテクちゃんを稼働させつつ
動的機能を盛ったサイトのブラッシュアップをローカルマシンでちまちま作業する。
できあがり次第アップロードして稼働させる!
、、、なんちゅうスタンスで作っているちうなんだけど、、、
あきまへんな~。
サイトを公開するよりスクリプトを書きたくてしゃーない
もうビョーキです おたくなんで仕方ない

「時間割」をcssを駆使してワンソースでキレイに表示できるようになったので
本当ならのこりのコンテンツもさくさく作れよ! って話し。
とっととアップロードして稼働させろよ! って話し。
なのに、なまじ「時間割」が希望通りの体裁で出力できてしまったので
追い込みたくて仕方ない
動的機能をつけたくてうずうずする~
我慢してのこりのコンテンツをしこしこ手書きしてすっかりうんざりしていたので
ご褒美にJavacriptでデータファイルをロードする方法調べを解禁してみた
だって、今やっている動的機能なしのローテクサイトすらも
実はブラッシュアップ中のシロモノなんだもん。
現在稼働中のサイトはほんの一時のもの。
あれ、いつ公開したんだっけ?
いい加減モバイルに対応しないとマズいな~っと思って去年やったんだよね。
適当にでっちあげたサイトと言いたいところだけど、、、
モバイルファーストなんて恐ろしい時代になっちゃったんで
ひと昔前のクロスブラウザなんて較べものにならないくらい痔になになりそーな
面倒臭いコーディングの仕方を調べつつやっとこ書き上げた。
そのくらい時代進みすぎてて痔が悪化する。
痔持ちじゃありませんけど。
なので、それなりな体裁でhtmlを書くのが精いっぱい。
体裁がショボすぎていぼ痔になりそう。
といって追い込むとどう見当をつけても1年コースだからひとまず公開。
それをキラキラな体裁にブラッシュアップ中。
めったくそツマラん!(怒っ) 飽きる!
ご褒美必要。
軽く気がすんでので体裁直しにもどらねばならぬ~(T^T)。
やだやだつまんない! コーディングしたい~。

あたしのスキルって
サーバー上のファイルをロードできない世代のJavaScriptで止まってます。
ばりばりクライアントサイド・スクリプトの世代で止まってます。
でも、コーディング知識が20世紀で止まっているだけで
JavaScriptがサーバーとのやりとりができる言語に成りあがっていることは知っていた。
で、ぐぐちゃんに「JavaScript csv」で尋ねたらAjaxかよ、、、
いまどきAjaxとかゆー単語がでてくること自体わりと恥ずかしいレベル。
WEB2.0とか言っちゃうくらい恥ずかしいレベルのはず。
そして、なんだ、あたしのやりたい程度のことならクソ簡単じゃんかっ
当時はぢぶんにニーズのない純粋な好奇心だけで記事を読んだから
これぞAjaxだーーーー! 的な
IQ高いグーグルのエンジニアがコーディングした成果の記事しか目に留まらなくて
「これ、ムリ 理解するまえに墓の中だ」と思ってしまったのだった。
もちろん、今だってグーグルマップのコードなんか理解できないですよ。
でも、そんなアホみたいに高度な動的機能はあたしのニーズにはない。
単にサーバー上に保存してある時間割データファイルを読めりゃいいのである。
超簡単すぎて笑った。
テクノロジーってすごいねぇ。
そこそこ基礎あれば
サンデープログラマーでも簡単にそれなりなスクリプト書けるわ。
2019年11月08日 (金) | 編集 |
こんなカンジであるていどの分量の文章を書きぃの、文中にハイパーリンクを貼ることがよくある。ブログは基本文章を書くものなので、テキストに色がついていてクリックできそう感があればよい。むしろ色々装飾すると鬱陶しくなる(笑)。でもウェブサイトだと、ちょっとした案内の文章を書いてリンクを貼りたい場合がけっこうある。文章がメインじゃないし、なるべくリンクは目立って欲しい。たとえば、、、
詳しくはこちら

的なやつ。
これを多用する予定があるなら
毎度<a>タグ内に<img>タグを記述するのはダルいし忘れそうなので
疑似要素のbeforだのafterだのを使う。
あたしの場合はbefor一辺倒。
HTML
詳しくは<a href="URL">こちら</a>

CSS
a{
 border:1px solid black;
 padding:4px;
 background;gray;
}
a::befor{
 content:url("img/icon.png");
}
こいつが、、、afterなら問題なくアイコンが表示されたんだけど
よりによってbeforだとまったく何をやってもダメ
beforでハマる人が多いらしく
ぐぐちゃんに「疑似要素 befor 効かない」で聞くといろんなサイトがヒットします。
その中で、いいヒントをくれた記事はココ。
カメ飼ってる新米エンジニアの覚書き

以下のようにハックして実現しました。
HTML
詳しくは<a href="URL"><b></b>こちら</a>

CSS
a{
 border:1px solid black;
 padding:4px;
 background;gray;
}
a b::after{
 content:url("img/icon.png");
}
結局afterですよ。
<b>タグを吐き出しただけの空要素に対して指定しているので(←ハックの肝)
「こちら」の手前にアイコンが表示されることに変わりないから
beforでもafterでもどっちでもいいっちゃいいです。
実用上は問題ないんだけど、、、
このCSSコードのafterをbeforに書き換えただけでアイコン消えます
表示されません。
ブラウザのバグなんだか仕様なんだか知らないケド
beforはダメなんでございます。

ちなみにストリクト中毒の人は(←あたしだべ
CSSハックのためだけに空要素の<b>タグを埋めておくと
減点されないけどW3C CSS 検証サービスにワーニングがつくので
HTML
詳しくは<a href="URL"><b>空要素</b>こちら</a>

CSS
a{
 border:1px solid black;
 padding:4px;
 background;gray;
}
a b::after{
 content:url("img/icon.png");
}
a b{
 display:none;
}
とでもしておけばよいかと。



よんちゃんという名のヒューマンデバッガが befor じゃない beforeだ。
このスカタンがっっ。
と、(おそらく)秒でタイプミスを発見してくれました

2019年11月02日 (土) | 編集 |
   
よーは、時間割を<table>タグを使わずに組もうと思ったです。
なぜならスマホの縦画面で閲覧したとき横長テーブルは表示が切れるから。
これ昔からの悩みでして、、、。
ヨソ様のサイトの時間割を見ると
↑これ的な、きっちり時間軸も使った表でして
やっぱ視認性いいんですよ。
、、、PCならね
画像にしちゃってスマホへは縮小を表示すれば
ユーザーにピンチで必要なところだけ拡大してもらえばいいわけだし
時間割がはみださないのでページを開いたときの体裁はいい。
でも、どう考えてもユーザビリティは最悪に近い

終了時間を書かないでセル当たりの要素幅を縮めてみたり
 ウチのウェブサイトは今この方式です。
どの曜日も最大3クラスしかないので列の数を3つにしたり
 以前はこの方式にしていたけど
 昼クラスと夜クラスと両方あるのが明確にわかったほうがいいので
 閲覧性と視認性のはざまで悩みつつ4列に表示に改めてみた。
スマホ用とPC、タブレット用に別々のhtmlをロードするのはなし。
 これはスマホ用サイトを意識して書くようになった当初から問題外。
 時間割に変更があるとファイルを2つ編集し直さなくちゃいけないから。
 面倒くさいし、やるたびに「あたし知恵がない~」って自虐必至になるからナシ。
floatしかなかったときはコーディングが複雑だった。
 書いてかけないこともなかったので書いたけど
 CSSがぐちゃぐちゃで後々のメンテナスコストが、、、。
でもFlexタグが策定されたよ\(^o^)/

<ul>
 <li class="week">曜日<li>
 <li class="cls1">クラス1<b>レベル</b><li>
 <li class="cls2">クラス2<b>レベル</b><li>
</ul>
<ul>
 <li class="week">曜日<li>
 <li class="cls1">クラス1<b>レベル</b><li>
 <li class="cls2">クラス2<b>レベル</b><li>
</ul>
</ul>
こんなカンジにたら~っと列挙できるのでソースの視認性オーライ
スタイルシートで表示をコントールできるので1ソース

この表示は非常に簡単。
<ul>
 <li class="week">曜日<li>
 <li class="cls1">クラス1<b>レベル</b><li>
 <li class="cls2">クラス2<b>レベル</b><li>
</ul>
単にリストスタイルをnoneって、<ul>タグにスタイルシートでボーダーをつけているだけ。これはこれで表示幅が狭すぎて画面がすっかすかになっちゃうから、横幅を広めにとって内容を右詰めにしたり、横長テーブルを表示するときには改行表示させるつもりの「入門」だの「中級」だのは<b>タグで囲んでmargin-leftを1文字分(=1em)確保して時間と離して表示している。

横長テーブルは以下のワンコードですっかーんといく
ul{
 display:flex;
}
でも、コード書ける人なら想像つくと思うけど、<ul>タグにborderつけただけじゃクラスごとの区切りの縦棒がはいりません。そこで各セルのセレクタに右辺にだけボーダーを付けるCSSを書くわけですな。
.cls1, .cls2{
 border-right:1px solid black;
}
まぁ、基本的にはこれでいいんだけど、、、ど、ど、ど、、、
<table>タグでもCSSでborderのスタイルをコントロールすると
1ピクセルの線が欲しいのに、borderが重なって2ピクセルになる問題。
<table>タグは古くからあるタグなので、とっくに解決する手段があるんだけど
Flexとかgridにはこれから実装されるのかな~? ってカンジ。
疑似クラスとかいうので(;nth() ってヤツ)
 最後の<li>には右辺を出力しないだの
 2つ目以降の<ul>には上辺を出力しないだの
てなことをやれば二重線は消せます。
キレイに1ピクセルの線になります。
コードもそれほど複雑じゃないし
人間がペンと定規をもって考えながらやったら時間かかりそうだけど(笑)
コンピューターはこーゆー仕事速いから実行速度にもほぼ影響ないんだけど。
んなもん作りこんでいる場合じゃないので、さくっと無視してみた

ちなみにホントはこんなカンジで空要素も記述しています。
<ul>
 <li class="week">曜日<li>
 <li class="emp">empty<<li>
 <li class="emp">empty<<li>
 <li class="cls1">クラス1<b>レベル</b><li>
 <li class="cls2">クラス2<b>レベル</b><li>
</ul>
表示領域に余裕のあるデバイス向けには
昼夜感をそこはかとなく醸し出す幅広テーブルを出力するので空要素が必要。
それをスマホ画面にそのまま出力しちゃうと
ただでさえ縦長な時間割が無駄に縦長になるし、なにより表示が不細工
.emp{
 display:none;
}
して、スマホへは出力を割愛してます。

コーディングが楽になったな~。
2019年03月30日 (土) | 編集 |
「テキストが小さすぎて読めません」
    と
「クリック可能な要素同士が近すぎます」

の2つに1ページづつ警告がついている。
おそらく同一ページかと。
ずーっと0で、3月29日のレポートで突然ついているから。
はて? なぜに29日なのかな?

トップページのイベント告知を3月の中頃に更新しているから
そのあたりかなぁ???
ぐぐクローラーは毎日クロールしないで
29日のクロールでひっかかったのかなぁ? と思った。
ウチのサイトは
 フォントサイズを固定してないし
 クリック可能な要素同士が混雑しているとは思えない
ので、どこがひっかかっているのかさっぱり。
ま、対処するしかないべ。

モバイル フレンドリーテストなんて素敵なものがあった
これ、1ページづつアドレスを放り込むしかないのかなぁ、、、
目星がついていたトップページは問題なしだったので
しかたないから全ページ1コ1コ放りこんだ。
いじってないページばかりだから、エラーが見つかっても逆に焦るが。
そして全ページ問題なし。あり

どこに問題あるのかみっかんね~~(号泣)!!
ちゃんと教えてくれよ~~!!

2018年11月23日 (金) | 編集 |
つか再構築。
静的サイトジェネレーターなるものに挑戦しちゃうよ!

CMSに移行したのは
コンテンツを増やすたびに発生する全ページ修正がダルすぎたから。
CGデザイナーやカメラマンなんかのポートフォリオサイトってゆーの?
紙ベースで言うとペラもの1枚、2枚みたいな
名刺代わりの作品公開用ウェブサイトなら更新なんて楽だし
PHPだの、Apacheウェブサーバーだの、DBサーバーだのに手を出すほうが
むしろ手間。
でも、ふつーにコンテンツがもりもり増えていく「ホームページ」を運営している。
フラメンコ写真を掲示するギャラリーが1ページ増えるくらいなら問題ないけど
生徒募集のテコ入れに、まるまる新造ページを増やすとか
パルマ教室を新設したので専用の新造ページを増やすとか
トップページのナビゲーション項目が増えるような変更がふつーにあった。
と、全ページのナビゲーションに項目つーいーかー
そしてFTPクライアントを起動して全ページ再アップロード
これはCMSでやっつけるのが賢い選択。

なんつって、、、。
じつはとうにウンザリしていて
メニューとヘッダとフッタを吐き出す自作のテンプレートエンジン的なのを
JavaScriptで書いていた

それでも
メニュー、ヘッダ、フッタを動的に挿入するコード入りの新造ページを作ったとて
そのファイルのアップロードはFTPクライアントを起動しておっちらおっちらだし
吐き出させるメニュー項目は
なんらかの形でテンプレートエンジンに読ませる必要があるから
その部分もアップデートして上書きアップロードだし
CMSなんて便利なものがあるなら使わにゃ損々。
と、まぁ、そんなあたりまえ体操な流れでした。

ところが、、、今やウェブサイトの半分がCMS。
日本に関してはその中の8割がワープレだとか。
そりゃ、セキュリティーホール狙ってくるっしょ。
windowsやIEやAcrobatレベルで大漁なんだからやる価値あるもの。
そーゆーのを狙うハッキングの流れ弾から距離を置く
ってのも立派なセキュリティ
windowsとJAVAは代わりがないけど、ほかのものは一切使わない方針できた。
代替アプリなんていくらでもあるので~。
しかもたいがい無料だし~。
代わりつぅ~か、定番アプリにはがち互換アプリがあるからねぇ
ちゅうわけで CMS も敢えてのドマイナーな geeklog を選択。
それでも、内部で使っているmail APIとかはワープレと同じだったりして
そこ掘られると geeklog でも喰らってしまいます。
つか、喰らった
「対策しないなら強制的にサービス止める」って鯖屋からメールが来て
スパムの踏み台にされていたことを知った。
これが一番シリアスだったんだけど
ワープレほどじゃないにしろ
クロスサイトスクリプティング対策系のセキュリティアップデートが増えてきてうんざり。
どんどん高機能化するからあちこちに穴あいちゃうみたい。
そんなあれもこれもがんばらなくていーんだよ。
サイトジェネレータ程度の仕事しか期待してないんだよ。

サイトジェネレーター、、、。

もうずいぶん前から
もっとシンプルで穴のあきにくい CMS に移行したいと思っていて
思い出しちゃぁMOONGIFTを眺めていた。
ワープレに続けとばかり二匹目のどぜうを狙う気概があるよな? ないような?
まったく新顔がでてこないってわけでもないし
古くからあるCMSも着々とバージョンアップを重ねていたりもするんだけど、、、
冴えたアイデアが浮かばないままワープレのシェアだけが増えていき~
いまさらワープレからユーザーを引き剥がすのはハードル高け~
的に新機軸を打ち出す系ばかりで、しかも、あんま冴えてない。
みたい、な。
ぱっとしないざんす。
一昨年あたりくらいからかしら?
やたら「静的サイトジェネレーター」って単語にぶち当たる確率があがってきていた。
あとMarkdown。
たいがいはこの2つはセットで。
で、Node.js。
実際の作業手順はさっぱりだけど、どう動作するものなのかはうっすら見当つく。
つか、CMS探しててセカンドオピニオンはコレ! 的な記事なんで
想像力乏しくても見当つくって話し。

ただ、Node.jsが格安レン鯖じゃインストールできない。
Calipsoなんて踊り手魂をキュンとさせるミュージカルなネーミングのCMSを
前述の MOONGIFT で見つけたんで調べたことがあって
Node.js必須ってことであっさり撃沈した2011年の夏。

そういうことは忘れない、ところどころ優秀な記憶力を持っているので
「静的サイトジェネレーターね。はいはい」
って、ずっとずっとスルーしていた。
この度、真面目に調べてみる気になってあちこちの記事をダーっと読みました。
確信はないけど、たぶん使えると判断。
CMSをすっぱり捨てる覚悟をして
ついでにスマホ対応のレスポンシブサイト構築も手をつけた。
静的htmlを5ページほど手でコリコリ書いてサイト入替え。
メール送信フォームのコーディングにえっらいハマり倒しつつ
ひとまず
 ・レスポンシブサイトでっちあげ
 ・無料のSSL稼働
 ・AMP対応を見据えたnon JS
にて、本来「静的サイトジェネレーター」で管理したいウェブサイトの姿に衣替え~。
つつながく稼働しているので
腰を据えて猛勉強モードに突入! 

思ったとおり、テンプレートエンジンなので
ウェブサーバーへのデプロイさえクリアできれば
CMSにちょっと劣るインターフェースでウェブサイトを管理できそう。
なにせコンソールアプリらしいんで。
ま、問題なし。
やたらShellを開放してもらえるレンサバ借りてNode.jsをぶっこめ。
な記事しかないんだけど、、、
どうせデプロイ前にローカルにhtmlをジェネレートして表示確認をするんだから
※ブログ的な使い方じゃないのでレイアウトチェックは必須です。
ローカルのhtmlをFTPする機能までをローカルで動かせればいいんだもん。
レンサバのほうにNode.jsいなくてもいいような気がする~。
でも、ちょっと調べたくらいじゃそのやり方が見つからないんだな~。
いっそ
htmlを受け取るPHPを書いてレンサバにインストールしてしまえ!
ローカルのNode.jsサーバーにそのPHPを叩くJavaScriptを流せばえんでない?
くらいの面倒くさいことを考え始めたとき(笑)
Node.jsサーバーに
やっぱりなカンジでFTPサーバーも乗っているらしいことがわかった。
標準で乗っているんだか? モジュールを追加するんだか? 知らないけど。
だよね~。
あるよね~。
それを知りたかったんだよ~。

あ~、すっきりした。
どうせ一筋縄じゃいかない宿命の生まれなんでハマり倒すと思うから
もう、今日はテレビ見る
7年越しの初恋のサーバーサイドJavaScript君とは
明日イチャイチャする