  |
はてなキーワード: ステータスコードとは
GET /index.html HTTP/1.1 Host: 香川県:443 HTTP/1.1 451 Unavailable For Legal Reasons Link: <https://www.pref.kagawa.lg.jp/gikai/>; rel="blocked-by" Content-Type: text/html <html> <head> <title>Unavailable For Legal Reasons</title> </head> <body> Unavailable For Legal Reasons ゲームは1日1時間 </body> </html>
以前のはてなブックマークでは
http://b.hatena.ne.jp/headline
がいわゆるホッテントリの一覧で多くの人が見るページだった。
その後仕様変更され、現在上記ページは無意味なページになっている。しかし、Google Chrome などで URL 直打ちしてはてブにアクセスしようとすると、未だに http://b.hatena.ne.jp/headline が入力候補に出てくるのである。これは未だに /headline にアクセスしてしまう人が多いことと、はてなが無意味なページでも HTTP ステータスコード 200 を返していることによる。
この現象を回避するため、はてなは http://b.hatena.ne.jp/headline を 404 にするべき。
FAKKUに限らず日本産の各種エロコンテンツの無修正版海外向け販売はいくつかされている
エロゲ、エロソシャゲ、エロマンガ、エロ同人等がJASTUSA、MangaGamer、nutaku、FAKKU、future-digi、艶書堂、2d-market他のパブリッシャーから海外向けに販売されている
共通するのはいわゆる「おま国(お前の国にはうってやらん)」対応で日本産のコンテンツにもかかわらず日本国内から購入ができない、ということだ(※1、※2)
これは映画やゲームなどでのおま国やリージョンロックの原因である商業的な理由だけではなく日本の法律的な問題も関わっている
https://ja.wikibooks.org/wiki/%E5%88%91%E6%B3%95%E7%AC%AC175%E6%9D%A1
刑法175条の判例によって海外向け販売については違法行為に当たらない、という判決がある
これを利用して海外の会社に無修正版を販売させればいいんじゃね？と考えたやつがいた
北米版 Trample on "Schatten!!" というタイトルで2011年ごろにweb上で無修正日本語版を海外在住の日本語話者向けという触れ込みで販売したそうだ
結果は
http://www.courts.go.jp/app/files/hanrei_jp/473/083473_hanrei.pdf
このとおり
結論から言うと制作等一部を日本国内で行い日本国内から購入できる状態で販売することは刑法1条1項から国内犯として処罰できる(※3)、と判断され御用となった
この判例から日本向けに販売すると作者やメーカーが御用になるという事になってしまった
このために上に上げた各種パブリッシャーがおま国対応を取るのである
なおFAKKUに日本からアクセスするとHTTPステータスコード451を返してくる
このステータスコードはUnavailable For Legal Reasons、「法的理由により取得不能」を意味しており日本の刑法175条関連の問題を暗喩しているのだろう
※1: nutakuに関しては過去にはDMM(今FANZA)にリダイレクトしていたがDMM由来のタイトルが減り海外産タイトルが増えた結果、日本由来のタイトルのみ日本からのアクセスだと非表示及びアクセス不可にして海外産タイトルに関しては通常にアクセスできるようになっている
※2: 2d-marketに関しては初期の頃は国内から普通に購入できていたが現在はできないようになっている
※3: つまり海外在住の人間が海外からやる分には全く日本の法的に問題はないので海外の同人サークルがpatreonやgumroadで無修正版の同人誌を頒布してるのを時々見られる
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
出欠とコメントの更新 (Promiseチェイン, リファクタリング)
タブとスペース混じりのインデントなど、見るに堪えません。
updateやfixなど英語一単語だと何が変更されたのか非常にわかりにくいです。
あと職場に英語圏の方はいなかったので無理に英語を使う必要はないと思います。
環境を再現することやサーバの中身を把握するのが困難になります。
世の中にはAnsibleやItamaeなど便利なプロビジョニングツールがあるので是非使ってみてください。
開発環境と本番環境で食い違いが生じてエラーが発生していましたよね。
動くかどうかも確認せずに「直ったよ」と嘘をつかれても他人の迷惑にしかなりません。
テストコードを書ければ良いのですが、最低限手動でもいいのでご自分で確認してください。
利用する側の人はドキュメントを見るので実際の挙動と異なっていると困惑します。
不整合が起こらないように気をつけてください。
GETしただけなのに201を返すなど意図にあっていないものがありました。
他にも言いたいことは沢山ありますが、あまり長くなるのも迷惑かと思うのでこの辺でやめておきます。
先輩は技術的知識はたくさん持ち合わせていましたが、どうにも技術的に他人を思いやる文化を持ち合わせていなかったように思いました。
Qiitaに書こうかと思ったけど、言いたいことも言えない、こんな世の中じゃ。
モバイルファースト、APIファーストな文脈でハイブリッドWebをやってきた目からすると、サーバーサイドでHTMLを生成してページ遷移させるなどという90年代調のクラシカルな発想を基本に据えるフレームワークはとても斬新に思えました。HTMLをゴリゴリ生成するなんてよほど特殊な最適化をしようとするのでなければそもそも発想として出てこないです。それでいてDSLやメタプログラミング等のテクニカルな技法が宝石のように鏤められている様はまるでエジプト時代の骨董品を見るかのような趣がありました。turbolinkなどは、かつて表計算ソフトに出しゃばっていたイルカを思い起こさせる味があります。かつて慣れ親しんできたSPAが星のように遠い存在になりました。
Web界隈の人々がモデルだとかアクティブレコードだとか"MVC"だとかを非常に具象的に話す様を見るにつけ、お前らどんだけPofEAA読み込んでるんだよと畏怖していた時期が僕にもありましたが、どうやら彼等はRailsのクラスやディレクトリという特定の実装について話していただけだったようです。Modelという概念もこれだけ肥大化してしまったら、オリジナルな概念で彼等と会話するのは諦めるべきかなと思いましたし、Railsの"MVC"をアンクォートして語るのはもはや害悪であるとすら感じました。
Rails界隈の人がよく「Railsの流儀」や「正しい"MVC"」というのを口角泡を飛ばして議論しているのを目にするのですが、おそらく外に広がる不条理で火傷を負って快適なRailsの世界に引き篭もった結果としての一種のストックホルム症候群なのだなと思いました。いまやAjaxとかWebsocketとかWebRTCとかを組み込もうとする至極真っ当な方法論がとてつもない高難度に見えてきます。設定よりも規約、というのも一つの方向性だと思いますが、ドメインやサービスレイヤの名前空間を構築しようとしたりコードジェネレーションしようとしたりしただけで地獄のようなCircular Dependency罰を受けてしまったので、自分がとても間違った事をしているような気がしてしまいました。とはいえConcernsに特別な名前や役割を与えられても正直しんどいので、皆が皆libにゴミを放り込んでいく様子にも納得がいきました。
RailsをAPIサーバーとして使おうとするとまずビューが無くなってMとCだけになりますが、いわゆる"MVC"の文脈で育ったエンジニアがなぜ息を吸うようにFat ControllerやFat Modelを作ってしまうのかという事が良く分かりました。多くのRailsのリファクタ手法と称されているものはクラスを書くファイルを分割する事以上のものでは無いように思えたので、Rails使いを大きめなAPIサーバー案件に回すときはセットポジションでDDDの青本を投げつける必要が有るなと思いました。
ビューとコントローラを結合させた場合、結合テストはCapybaraとかのBDDでマークアップサイドとの干渉を恐れながら強い気持ちでメンテしていくしか無いのかなと思いました。おそらく脳に電極を埋め込んでいるか、緑色のランプを見るだけでハイになれる特殊な人にしか生き抜けない闇が垣間見えました。コントローラを薄くしてサービスレイヤを挟めばその辺りもうまくいけそうな気がしましたが、ビューからヘルパーやモデルがいくらでも透けて見えてしまうという状況では裏側の完全性に自信を持つ事は難しそうでした。
ビューがRubyを叩いて永続化レイヤと直接コミュニケーション出来るというのはとても生産性が高いのだろうとは思いましたが、こうして出来たパーシャルやら何やらをデザイナーとどうやって共有するかを考えると頭痛が痛くなりました。おそらく適当に切り出して綺麗な空間をassets以下に構築した上でpublicにRPCのような窓口を備えたゴミを量産していくのかなと思いましたが、もっと綺麗な方法はあるのかもしれません。でもきっとRails案件に関われるデザイナーはRubyもバリバリ書けるに違いないはずなので、ここが問題になる事は無いのだろうなと思いました。
RESTはとても美しいパラダイムではありますが、そもそもHTTPがさほど美しくないので歪んだ空間には目を背けるか勝手解釈を与える事で人は初めてRESTfulを名乗る事が出来るのだと思います。GETがbodyを(公式には)持たないという事について美しい説明を与える事は出来ないでしょう。サーチAPIはどうしますか。ステータスコード足りなくないですか。401エラーはどうしますか。そしてRESTはあくまでリソースを抽象化する美しい概念なので、アクションや副作用については貧弱です。動詞が足りないですし、一般動詞に狭義の意味を与えてドキュメントするのは二度手間にしか見えません。PUTには冪等性があるべきみたいなこだわりは家の猫にでも説教してればいいと思います。というわけで、REST的な設計を拝借することはよしとしても、「○○はRESTでは無い故云々～」みたいな注文はやめて頂きたいものです。
とか言わないで欲しいです。こういう時にセットでPHPをディスって悦に浸るのは知る限りRubiestとPythonistaと中学生だけです。それにこれはあくまでサーバーサイド初心者の感想なので、想像するにこれ系のFWは多かれ少なかれ似たような不満を抱えるものなのかなと思います。というわけで、おそらくこれから選択肢がある限りはRailsを使い続けると思います。
そこで、HTTP2.0ではどんな告白が可能になったのか告白で例えていきましょう。
HTTP2.0は随分とフォーマットが変わりましたが、告白の方法が電話だったものがメールになりLINEになりと媒体が変わったものの伝えたい事は変わっておりません(セマンティクスは維持されています)。
なので、みなさんが大好きなステータスコードはHTTP1.xの頃と殆ど変わっていません。HTTPヘッダも同様です。
物凄く簡単に、かつ誤解を恐れず紹介したいと思います。
HTTP1.xでは、告白したら返事を貰わないと次の告白は出来ませんでした。
HTTP2.0では、相手の返答を待たずに続けて(同じ相手に)告白をすることが出来るようになりました。
ただあまりしつこいと、あっち行けと言われてしまうかもしれません(GOAWAYフレーム)
同時に複数回告白できるようになったため、どの告白文についてより早く返事をして欲しいか優先度を指定できるようになりました。
ただし優先度付けしたところで、相手がそれを汲み取ってくれるとは限らないようです
「好きです」→「ごめんなさい」
という感じです。
男「好きです」→ 女「ごめんなさい」→男 「では友達からということで...」→女 「それもいやです」
HTTP2.0では女の子は、男の次の要求が想定できる場合、要求が来る前に返事を返すことも出来るようになりました。
男「好きです」→ 女「ごめんなさい」「友達になるのも無理です！！」
「～～さんへ」(host)や「2013/12/18」(date)といったもの、自分の名前(User-Agent)といったものはわざわざ書かなくても良くなりました。
現状HTTP1.xと言う旧式の告白方法と、HTTP2.0という新しい告白方法が存在することになります。
どっちが正しいとかはどうでもいいが に関する戯言。
匿名ダイアリーを初めて見た俺がこのエントリを見て、なんか増田って人が滾ってるなあ、と思っちゃうのと一緒なんじゃね。色々話が混濁しているけど、そもそもの原因は、（この界隈での有名人を）自分が知らなかっただけ、という点だけでしょ。そこから、
こりゃこの業界が育たないわけだ。
とか、
他人の失敗に耐えられないのならもうそんなサービスやめてしまったほうがいいと思いますよ。
とかエクストリームすぎる方向に発散しちゃって、本人も収拾がつかなくなってる。
ってのは、失敗に耐えて（非常に面倒な思いをして仕様上本来は必要がなくむしろするべきではない対策をする羽目になった） mala の苦言だと思うけどね。俺も mala に関しては、ブログをいくつか全読みして mala が脱ニートして LDR の中の人になったってことぐらいしか知らないけど。
なんだかキチ○イな人が文句言ってるよぉ
と思ってる時点では、そもそもこれを字面通り受け取ってなんかいないでしょ。そこで終わってればよかったのに、わざわざ「周りが肯定的だったから」って思いっきり世間に流されて困惑して勝手に滾っちゃったのがこの結末。まぁ、
たしかにアメブロのやったことはかなりウザかったしキモイとも思ったけどクズ呼ばわりされるほどのことじゃないし何よりこの人の文章の方がひどい
という一文で、大体の認識のズレが見えてる。
自分が無知だったって気がついた時点で引かなきゃだめでしょ。議論を進めるのに無知は罪。
自分の意志でものづくりしてる人だったらいくら叩かれてもめげたりしないよ。
