もう玉留めも怖くないぞ。はっはっは。
通勤用に使っているリュックのファスナーが外れてしまったので自前で修理した。
縫い目が表に出ない製法のリュック↓↓で、普通に修理すると色々裏返すとかで10000円近くかかるそうだ。
ほとんど新品買い直すのと同じ値段なので、自前で直すことにした。
# 雑でも安く直す方法があるはずだよね
書いてなかったけど、ファスナーが外れるのは今回で2回目。
外れやすくなっちゃってるので。
で、前回はファスナーをハサミで切って直した。
今回はもっと根元から直すよ。
外側から修正箇所がわかんなくていい感じだ。
練習用に手頃なデータベースが欲しくて、しかもWeb上からアクセスしたいことってないですか？
Posgres SQLのデータのリストア用コマンドがローカル以外のDBを対象に取れたので、サンプルデータを投入することができました。めっちゃ便利だ。
PosgreSQLには、データベースの中身をテキストなどの形式でバックアップする"pg_dump"コマンドと、その結果をリストアする"pg_restore"コマンドがある。
"pg_restore"コマンドの発行時、ホストやユーザー名などにHerokuで指定された値を入れると良い。それだけ。
基本的にはこの通りに進める
違うのは"pg_restore"の引数。
$ pg_restore -d [Herokuが指定したDB名] -h [Herokuが指定したホスト名] -p 5432 -U [Herokuが指定したユーザー名] -W ./dvdrental.tar
Herokuの指定はダッシュボードで確認可能。
リストアが終わったら...（私の場合は数十秒くらいでした）
¥dtでテーブルを確認。ついでに中身も確認。
::DATABASE=> \dt
List of relations
Schema | Name | Type | Owner
--------+---------------+-------+----------------
public | actor | table | [Heroku Posgresのユーザ名]
public | address | table | [Heroku Posgresのユーザ名]
public | category | table | [Heroku Posgresのユーザ名]
public | city | table | [Heroku Posgresのユーザ名]
public | country | table | [Heroku Posgresのユーザ名]
public | customer | table | [Heroku Posgresのユーザ名]
public | film | table | [Heroku Posgresのユーザ名]
public | film_actor | table | [Heroku Posgresのユーザ名]
public | film_category | table | [Heroku Posgresのユーザ名]
public | inventory | table | [Heroku Posgresのユーザ名]
public | language | table | [Heroku Posgresのユーザ名]
public | payment | table | [Heroku Posgresのユーザ名]
public | rental | table | [Heroku Posgresのユーザ名]
public | staff | table | [Heroku Posgresのユーザ名]
public | store | table | [Heroku Posgresのユーザ名]
(15 rows)
::DATABASE=> select * from actor fetch first 10 rows only;
actor_id | first_name | last_name | last_update
----------+------------+--------------+------------------------
1 | Penelope | Guiness | 2013-05-26 14:47:57.62
2 | Nick | Wahlberg | 2013-05-26 14:47:57.62
3 | Ed | Chase | 2013-05-26 14:47:57.62
4 | Jennifer | Davis | 2013-05-26 14:47:57.62
5 | Johnny | Lollobrigida | 2013-05-26 14:47:57.62
6 | Bette | Nicholson | 2013-05-26 14:47:57.62
7 | Grace | Mostel | 2013-05-26 14:47:57.62
8 | Matthew | Johansson | 2013-05-26 14:47:57.62
9 | Joe | Swank | 2013-05-26 14:47:57.62
10 | Christian | Gable | 2013-05-26 14:47:57.62
(10 rows)
::DATABASE=> \q
ばっちり。
DBに詳しい人なら普通に気づくのかもしれないね...。
戻るボタンと右クリックをアプリ側で禁止にしている現場で働いている。
ユーザーが同じ更新内容を意図せずに重複して発行しないためで、こういう問題は二重送信問題と言われるらしい。
（Double Submit Problemって検索したらたくさん出てくるよ）
さすがに2017年にもなってそれはダサいと思うので、今風なやり方で二重送信問題を防ぐにはどうしたらいいのか調べてみた。
PRGパターン（後述）について、wikipediaの記事と、その元になったTheServerSide（企業向けJavaアプリの開発者のためのポータルサイト？）の記事が参考になった。
Post/Redirect/Get - Wikipedia
Redirect After Post
また、NTTデータの「TERASOLUNA（テラソルナ）」というフレームワークのドキュメントが、RPGパターンを含めた対策について網羅的にカバーしている。
二重送信にはこんな種類がある。
更新完了後にブラウザ側で画面を再読み込み
更新完了後、戻るボタンを押してから再度更新リクエスト
更新リクエストを送信後、レスポンスが返ってくるまでに送信ボタンをもう一度押してしまう
更新リクエストを送信するページがブックマークされてしまい、画面遷移が正しくないためにデータの不整合が生じる
以下の対策が挙げられる。
- POSTリクエストを受け取ったら、更新完了などのページにリダイレクトする。
- 送信ボタンが一度押された時点でisClickedフラグを立て、レスポンスが返ってくるまでボタンが押せなくする。
- 更新リクエストを送信できる画面を返す際、サーバー側でトークンを発行しておく。クライアントは送信リクエストにそのトークンをくっつける。サーバー側で保管しておいたトークンと一致すればトランザクションを通す。一度使ったトークンはその場で破棄する。
- 更新リクエストのタイムスタンプとテーブルの最終更新日時を比較し、テーブル側の方が新しければ更新しない。
誤りなどのご指摘があればぜひお願いします。
サーバー側の不整合の防止と、クライアント側で誤って二重送信しないための工夫を分けて考えられそう。
トランザクショントークンでリクエストを検証することは必須とし、ユーザーが誤って更新しないようにボタンの非活性化やPRGパターンの導入をする・・・など。
PRGパターンでブラウザバックが防げるのかわからない。資料によって言っていることが違う。ブラウザごとの挙動の問題？
PRGパターンを実装する上で、リダイレクトには実装方法がいくつかあるらしい。ページに埋め込む、httpのヘッダーに埋め込むなど・・・後者の方が良さそうだけど、どうなんだろう？
レスポンシブWebデザインな感じでサイトのプロトタイプ作ってみたら大変だったので、エディタの導入を検討中。
調べるとWebアプリだったりMacのみ対応だったりなんだけど、現在無料で使えてマルチプラットフォーム対応のPingendo(ピンジェンド)というのがあるようだ。 Electron製のため、Mac/Windows/Linuxをカバーしている。その上Web版もある充実っぷり。
ちなみに名前の由来はラテン語の"Painting"から。Twitterで尋ねたら教えてくださった。気さくだ...!
Sure! It's "painting" in Latin
— Pingendo (@Pingendo) 2017年10月2日
Bootstrap4対応の最新版はbeta期間中は無料とのこと。3系対応の旧版もWebで公開されており、自由に使えるとある。
ライセンスはインストール時に確認可能。無償のベータ版であり、サポートも保証しないことに同意することが使用条件とある。
あくまで個人的に、手書きに比べて効率4~5倍くらい？
bootstrap初心者・レスポンシブWebデザイン初心者として手書きでHTML作成→1日(11時間49分)
Pingendo導入後、初回のHTML作成→2時間20分
いきなりマルチデバイス対応のWeb画面のサンプルを作ることになったのですが、とりあえず作ってみたらすごく疲れた。 （もっといいやり方あるだろコレ...）と思いながらやってた。いくらか原因がわかったので棚卸し。
グリッドデザインのためのクラス（col-md-12, とかのことを言いたい）を宣言する時に、divタグがやたら多くて疲れた。 ヘッダーのロゴ画像とかタイトルとかがうまくヘッダーに収まってくれず、一部人力で高さや幅を指定してしまった。
ヘッダーは、専用のクラスがある気がする。 divタグ以外に要素を表すタグを使うべきだったんじゃないだろうか。
グリッドデザインの組み方が悪い。PC用の表示をする時に、1行の中の箱要素の中身まで横に崩す必要はなさそうだ。 ヘッダーは、ナビゲーション関連のクラスを使うのが良さそうだった。
bootstrapのチュートリアルをじっくりみた。 www.tutorialrepublic.com
ヘッダーについて - 便利なクラスがたくさんある。 - ページのタイトルとかをトップに張り出す時には"navbar-header"。スマホ表示の時にヘッダーを右端に寄せてくれる -
divについて - rowの内側の要素それぞれの縦並びを横に崩そうとしない。 - PC用の画面をデザインしてからスマホ用に並べようとすると↑の失敗をしてしまう - 子要素の中でさらに柔軟な縦横のデザインをやりだすと、マージンがかさんで場所ごとに横の位置が揃わなくなる。
そもそもはEclipseで外部ライブラリをimportするのってどうするんですか？という後輩さんの質問に答えられなかったのがきっかけ。 調べ物をしていくうちに、そもそもEclipseなしで外部ライブラリを使うのってスイスイできないなって気づいた。これはまずい。
先に結論を述べて、そのあと実験します。
Javaでクラスファイルをimportするには、以下の２点を守る必要がある 1. コンパイル時のクラスパスに必要なクラスファイル（ないしはソースファイル）があること 2. 実行時のクラスパスに必要なクラスファイルがあること
二つのソースファイルをもつ簡単なプログラムを作って、コンパイル時と実行時に条件を変えて試してみた。
src/ ├ Hello.java └ spanish/ └ Hola.java
import spanish.Hola;
public class Hello {
public static void main(String[] args){
System.out.println("Hello, world.");
Hola hola = new Hola();
hola.printHola();
}
}
package spanish;
public class Hola{
public void printHola(){
System.out.println("Hola!!");
}
}
$ javac Hello.java (エラーなし)
$ javac Hello.java
Hello.java:1: error: package spanish does not exist
import spanish.Hola;
^
Hello.java:6: error: cannot access Hola
Hola hola = new Hola();
^
bad source file: ./Hola.java
file does not contain class Hola
Please remove or make sure it appears in the correct subdirectory of the sourcepath.
2 errors
$ java Hello Hello, world. Hola!!
$ java Hello
Hello, world.
Exception in thread "main" java.lang.NoClassDefFoundError: spanish/Hola
at Hello.main(Hello.java:6)
Caused by: java.lang.ClassNotFoundException: spanish.Hola
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 1 more
ソースファイルがあってもダメ。
$ java -classpath .:../another Hello Hello, world. Hola!!
コンパイル時と実行時で、クラスファイルが置いてある場所が違っても構わない！知らなかった！
実は冗談でやってるわけではない。 こないだ読んだ「本を読む本」という本に、目次を読んで中身を想像するのは大事だって書かれていたような気がするので実践してみてる。
Webの歴史を論じている。コンピュータが軍や大学にしかなかった時代から、アプリがWeb上で動くようになった現代までの流れを追う。 「Web APIをめぐる議論」にSOAPとWS-とRESTのことが書いてある。WS-って何か分からないが、RESTと対比されているのでクライアント側のフォーマットが決まっているプロトコルなのではないか。 RESTについて1章割いている。RESTfulなAPIをどう設計するかについて論じていると予想。URIの体系とか、サーバーサイドの実装のコツ（キャッシュをリバースプロキシにもたせるとか？）が書かれているのではないか。
URIの仕様と設計について。仕様の章は、URIを要素に分解して説明していると予想。プロトコル、ドメイン、etc… 改めて説明しようとするとできないな。 設計の章は、ドメインが変わったときやAPIを追加したいときなんかの変化に強いURI体系について論じているのではないか。サービス/領域/リソース名 みたいに分解すると予想。
基本→メソッド→ステータスコード→ヘッダ。HTTPの中身を要素ごとに解説すると予想。 ぶっちゃけレスポンスそのものって私は見たことほぼなくて、アプリケーションでformに梱包されているのしか受け取った覚えがない。 メソッド(DELETEとかPUTとか)にもページを割いている。GETとPOST以外使ったことないけど、態度として正しいんだろうか。
HTMLとJSONはわかるんだけど、microformatsとAtomって何だろう。microformatsはRDFと対置されるものらしい。Web以前のドキュメントの装飾とかに使われた古いフォーマットだろうか。 AtomはRSSとかと一緒に見かけたことがある。ブログの更新とかに使われるんだろうか。これって現役の技術？ JSONは知ってるけど、ハイパーメディアフォーマットって映像とか動画とか埋め込むフォーマットだと思ってた。誤解かもしれない。
読み書きとリソースの設計。読みは置いといて、書き込みは排他制御とか。トランザクションリソースって聞き慣れない言葉だけど、DBだとトランザクションレベルって言葉があるから、そのWeb版かな？ トランザクションレベルとは、逐次コミットとかまとめてコミットとかそういうやつだったと思う。 リソースの設計って何だ。と思ったが、DBではこんな形、Webサービスにしたらこんな形、の黄金パターンみたいなものかしら。
