プログラムのエラーが出ることを怖がる学生さんたち
山本一成🚗自動運転スタートアップの人🌔 @issei_y 大学のプログラミングの授業を生徒さん達に教えている時でとにかく衝撃的だったことは、生徒さんが『プログラムを実行しないこと』だった。 プログラムを実行すると、文法エラーや結果が全然あってないなどの「間違い」が発生するのを恐れているようだった。 2018-03-09 14:04:56 たくみん @uhtm22 これ、プログラミング以外の科目も同じかもしれない。とにかく書いてみるというところに異様な壁がある。あと、"エラーが出たものを無かったことにする感"みたいなのも感じる。間違えたデータこそ学びの宝庫なのに、また0から考え始める。 twitter.com/issei_y/status… 2018-03-09 14:32:52 北関東の港 @mizono_3710 高専時代似たような理由でプログラミングの授業嫌いだったから気持ちわかる
フォームバリデーションと送信ボタンの状態の最適解 - Konifar's ZATSU
タイトルを見て「あーあれね」と思った人もいると思うが、アプリデザインの世界ではすでに議論され尽くされているであろうこの話題について雑に考えをまとめておきたい。とは言っても明確な答えがあるわけではないので意見がほしいというのが正直なところなので、もしフィードバックがあれば @konifarまで直接教えてもらえると嬉しい。 何を言いたいのかというと、『フォームに入力されていない or 入力された文字が異常である場合に送信ボタンを押せる状態にするか押せない状態にするか』という話だ。たとえば次のように氏名を両方入力しなければいけないケース。 初期状態の送信ボタンがdisabledで、入力に応じて状態が切り替わる。 本当に送信できる時だけ送信ボタンがenabledになるというのはわかりやすそうだが、問題もある。入力項目が多くなってきた時に、ユーザーがなぜ送信ボタンを押せないのかわからないかもしれない
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
