  |
はてなキーワード: 記法とは
ドコとは言わないけど、増田の記事書くような感じの独自記法と一部HTMLが使えるところがある
そこにはプレビュー機能があって一文字打つごとに実際の表示が更新される
script タグも許可されているんだが、どうも内部では jQuery の html() メソッドにそのまま入れてるようで、プレビューが更新されるたびに script タグが実行される
先に script タグを書いていれば残りの本文を一文字打つごとに実行されるわけだ
script の内容によっては画面が崩れていくし、ヒドイにもほどがある
「script を最後に書く」＋「今のURLがプレビューされるページだと実行しないような処理を最初に入れる」として対処できたが、これはもうバグといっていいんじゃないかと思う
普通に innerHTML にすれば script タグは実行されないようになっているのに なんでもかんでも jQuery なんて使うから・・・
使い方が悪いのが原因だが、jQuery の html() メソッド が script タグ実行させるなんて余計なおせっかい機能をなんで入れてるんだよ、とただでさえ嫌いな jQuery の嫌いさがさらに強くなった
ひとつの記事に書けるリンク数は最大9個で、それを越えて「この内容を登録する」を押すと投稿できずに書いた内容はすっ飛ぶ(「確認する」では問題なくプレビューできる)。
これが仕様なのかバグなのか判らなかったので、はてな運営に問い合わせたところ、リンク数制限は「スパム対策のための仕様」で緩和の予定はない、との回答を得た。
さてコンビニ店長の過去記事まとめはどうしようか… URL中にhttpがふたつ入るから古き良きttpのテクニックは使えない。自動リンク停止記法でもリンク数カウントされる。何か良い方法はないか。九つクギリで複数記事にするしかないか。
それにしても汚染、そんなに激しいかー。ブクマスパムも多いみたいだし。PVが増えるのは良いことだけど、はてなも変わっていくんやな。
まじな話をすると、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チェイン, リファクタリング)
フェス限ヒロインガチャ（通常の2倍の石10個で回せる期間限定ガチャ）について、公式生放送で山本大介プロデューサーが全キャラ
究極進化するとおよそ３ヶ月にわたって繰り返し宣言してガチャを煽ったにもかかわらず、実際に究極進化したのは一部キャラのみで
更に山本大介プロデューサーが「あれは言い間違いでした許して」とユーザーの怒りに火を付け優良誤認の返金騒動へと発展。
https://twitter.com/DaikeYamamoto/status/835385151957827584
3月になり一転して全キャラを通常進化から究極進化に変更（ただし性能据え置き）、進化に使った分のアイテム等の返還で幕引きを
図った案件だったが、ようやくお役所の方で仕事が終わって時間差コラボが発動した。
通常進化はレベルキャップまで経験値を重ねなければ進化できないが究極進化はレベル1からでも可能なので消費者庁では優良誤認と
判断したのかもしれない。しかし、通常進化の場合は更に将来に究極進化でのパワーアップを残しているとも考えられ、性能据え置き
のままで通常→究極となったのはユーザーにとっても重ねて不幸な結果となった。
また、この程度で（一部）ユーザーが大きくアクションを起こすのはパズドラ運営・山本大介Pが長期間の運営の間にユーザーからの
不満を溜め込んでおり何かあれば簡単に着火炎上してしまうためである。ゲーム運営の長期化にあたっては社員個人のスタンドプレー
が業績に影響しないような仕組みにじよ目のつけどころがおシャまんべ。((時事ネタ解説追記：ユーザーとツイッター担当との距離感の例として、にじよめちゃん、シャープ公式の片方、まんべくんを挙げた。))
| 実施回数 | 日程 |
| 第1弾 | 2016.11/7(月)メンテ後～11/20(日)23:59 |
| 第2弾 | 2017.2/13(月)0:00〜2/26(日)23:59 |
| 第3弾 | 2017.5/22(月)0:00～6/4(日)23:59 |
生放送「ヒロインガチャキャラ全部究極進化」発言（消費者庁PDFより）該当の生放送過去分は再生禁止済
| 2016.11/30 | 山本大介プロデューサー生放送発言 |
| 2016.12/25 | 山本大介プロデューサー生放送発言 |
| 2017.2/20 | 山本大介プロデューサー生放送発言 |
| 同日 | 生放送スライド（※注記あり） |
（小さい※で通常進化含むとの表記があるが、スライドにはヒロインガチャキャラ以外も表示されており、この※一つでこれまで
全部究極進化と明言されてきたヒロインガチャキャラが通常進化になるのも許されるというのはガンホーに都合が良すぎる）
テレビ報道でも問題のアレとして映し出されるフリップが出た2/20の生放送。パズドラ5周年記念の生放送は2/19(日)開始だったが
55体究極進化の発表はその翌日。遅くなったのは、AppStoreでの返金申請期限が90日以内であり第1弾ガチャから90日経過させる
消費者庁案件ということで、すわガチャ確率か、と思ってワクワクしたみんな、ヒロインガチャとか訳わからん話ですまねえな。
ガンホーはオンゲ業界団体JOGAの主要企業ながら、ガイドラインの隙をついて全部当たりだから確率表示はしませんという屁理屈で
いまだに確率は不明のまま。また進出先の中国では確率表示義務の法律ができるとわかるとすぐさま撤退した。ガチャイベントでの
超絶↑3UPなども具体的にどういう確率かはユーザーが確認できない。JOGAのガイドラインも「オンラインゲーム安心宣言」も有名
無実化している。
おりしも、パチンコの方では釘調整の禁止や出玉の下方修正など規制が強まっている。業界内での自浄作用・自助努力が働かなけ
れば埼玉県警がお願いに行くかもしれないし、巻頭カラーに使う出版社への抗議の声が高まるかもしれない。((時事ネタ解説追記：性犯罪事件を受けてクジラックスに埼玉県警がお願いという法的根拠のない圧力をかけた件、ジャンプゆらぎ荘のお色気巻頭カラーにクレームがあがった件。時事ネタを入れると書いた本人も思い出せなくなるので脚注追記している。脚注記法がうまく使えない。))
覚醒セレスの初回発表時に、進化に同じガチャキャラを消費するとしたことがユーザーの反発を招き、撤回された。同じキャラを
重ねる事の何が問題なのか宝具5たくさん揃えているマスターには理解しがたいだろう。このときまでは進化にはダンジョンドロップ
の進化合成用モンスターを使用しており、無料で最後まであそべちまうんだ、を地でいっていた。そこへ同キャラ複数引くだけでなく
消費してしまう進化形態の登場は、同じパーティーに同じ英霊を複数入れられるパズドラではユーザーの拒否感が大きく、コンプ
ガチャに抵触するのではないかなど痛くもないビール腹((プレモルうまし))を探られることになった。同一重ねはコンプガチャには当たらない。
同じガチャキャラを複数引いたユーザーへのサービス、という言い訳が後に覚醒というシステムや売却モンポとなり潜在覚醒や
またコンプガチャはキャラ単体の進化素材という形ではなく、特定キャラの組み合わせでパーティーが効率的に回るようにして
ヘビーユーザーがテンプレパーティーを揃えるためにガチャを回すという形に洗練された。
期間限定クリスマスガチャにおいて新登場キャラのサンタジーニャが、通常ジーニャと同名スキルでありながら通常版15ターンの
ところ11ターンで発動可能として公式ページに掲載されていた。排出されたサンタジーニャのスキルは通常ジーニャと同じ性能で
あり気がついた一部ユーザーが優良誤認だから返金しろと騒いだ。
（※サンタジーニャ・通常ジーニャとも性能目当てで使ったりガチャ回したりするような環境ではなかった）
ガンホーは誤りを認め補償を発表したが、その内容が不公平感あふれるもので火に油を注いだ。
「クリスマスガチャでサンタジーニャが的中したユーザーに対して期間中に消費した石を全部返還」
当たらなかった奴は客じゃねえと全ユーザーに喧嘩を売ってしまい、その後補償内容を変更。
「期間中にクリスマスガチャを引いた全ユーザーにガチャ１回分の石返還」
全部返還の発言はガチャ期間中のことであり返還されるからとガチャに全ツッパしたユーザーのヘイトを買った。
Googleに対して返金請求をし返ってきたユーザーもいたようである。Appleは渋いらしい。
「数グループによる2重チェックを徹底するなど、製作物に対する社内の管理・ 検証体制…」
しかしその後もケアレスミスが繰り返され、運営とユーザーで二重のチェックの意味などと揶揄される。
スクエニのスマホゲー、FFクリスタルディフェンダーズ（FFCD）とのコラボで新キャラ曲芸士が登場するも、簡単なパズル要件で
49倍という当時としては破格の攻撃力でユーザーを驚かせ、さらにFFCDには曲芸士が居ないことで二重にビックリだよ。
バランスブレイカーいわゆる壊れキャラを期間限定のコラボキャラで実装したことに対するユーザーの反発が大きく、ガンホー公式
がバランスとか問題ないしちゃんと計算してる角度とかと表明することになった。
当時のユーザーはパズドラのゆるやかなインフレ状態を好ましく感じており、曲芸士以降の加速度的なインフレ傾向を考えると
確かにここがターニングポイントだった。
山本大介PもFFCD側の担当者スクエニのハタケイスケ氏((時事ネタ解説追記：又吉と同時受賞した芥川賞作家とは別人。))も、ユーザーは強いキャラを望むけれどもゲームバランスこそが重要だから
軽率に強キャラ出すわけにはいかない旨の発言をしていたのだが。
オワドラが言われ始めたのはこの頃、長い長い黄金の黄昏の始まりである。
http://nlab.itmedia.co.jp/nl/articles/1603/01/news139.html
＜コラ＞ボキャラでした。後に修正。リーダースキルの名称で良かったよ。まどか衣装のチアリーダー((時事ネタ解説追記：アイマスのパリーグコラボで西武ライオンズではなくアメフトの三菱ライオンズのチア衣装になっていた件。コラボ相手に資料請求せず適当にググって仕上げるとアカンことになる事例。))じゃなくて助かったな石田。
ぶっ壊れとして騒動になった曲芸士は7倍×7倍で49倍リーダーだった。その直後から曲芸士の闇属性対策がされたダンジョンが
続々登場。曲芸士のバランスは問題ないとの公式発言を実証するために実装された同系統リーダースキルのティフォン・ガディウス
は曲芸士に及ばない性能のため今に至るまで陽の目を見ていない。パズドラにストーリーという名のポエムが導入され、その主人公
の２人だったが低性能不人気キャラのためにストーリー自体もぐだぐだのうやむやになってしまった。
究極進化の上を行く覚醒進化、転生進化の実装。ガチャキャラの売却で得られるモンスターポイントで買える強キャラ。Appleに
よるゲーム外コード禁止令による雑誌付録コードAndroid専用化。メダル商法。期間限定コラボキャラの当たりが環境トップ級。
ガチャ石2倍ガチャの広まり。ポケモンGoの影でひっそりと実装されたレーダーといつまで経っても消えないW。進化素材の進化素材
の進化素材集め。２人３人マルチ実装でネトゲでフレンドを引き止める辞めにくい構造。
現在の環境トップはヨグ＝ソトースの18倍×18倍＝324倍。神話もあらかた消費してクトゥルフに手を出す羽目になった。
なお最新実装の神は日本の造化三神。あんなん逸話も何もないのによくやるね。
曲芸士と現在のインフレは、パズドラ？昔やってたよ的な人へのランドマーク的な状況把握として載せた。また、ゲームの長期運営
においてインフレ傾向の管理と、ユーザー心理の掌握が重要であることの例として挙げた。かつては詫び石いっぱいくれるポカポカ
運営として名を馳せた王者パズドラが悪い文明に染まる特異点。廃ゲーマーを基準としたゲームの複雑化はSTG・格ゲー的ユーザー人口
の減少を招くが、だからと言ってハタ式コンボで540万出ましたとお手軽にしてもヘイトを稼ぐアンビバレンツ。
ないしょの石田はコラボ相手を適当にググッて処理すると問題となるおもしろ先行事例。
とある障碍者が取ったとある航空会社への行動が物議を醸している。
はてな界隈、ツイッター、facebook、おそらく見えてはいないだけで世間的にもこの件に関しては様々な主張がなされているだろう。
大きく分けると
と言ったところだろうか。私にはどちらの主張も半分正しくて半分間違っているように思える。すべての主義主張を見たわけではないので多少の誤解は許してほしい。
まず当人に対して考えてみると、
２．車いす利用者であり、それが原因で航空会社から搭乗を拒否された
４．過去にも数度、別の航空便で車いすを利用していることにより搭乗を拒否された経験があり、今回も同様の理由で搭乗を拒否される可能性があることを「おそらく」知っていた。このことから、「そのうえで車いす利用者であることを連絡しなかったという憶測」が出来る。
の4点が、おそらくポイントになる。
航空会社に対して考えてみると、
１．本来あるべき車いす利用者が搭乗するための設備投資を怠った
２．HP上には「車いす利用者であることを事前に連絡する」ように記載してある
３．「連絡されたとしても、もともと今回の空港にその設備を用意していないため、搭乗を拒否する可能性が高かった」と推測できる
の3点だろうか。
これだけ整理しておいて難だが、私は今回の件に関しては結局「双方とも配慮が不足していた」の一言にすぎないと思う。というか、どちらが悪い、どちらが正しいと主張しているのはノイジ―マイノリティであって、大多数の人が「どっちもどっち」であると思っているのではないだろうか。違ったら恥ずかしい。
当人に対して言うならば、本来事前に連絡することの意義を理解できていなかった。
航空会社に対して言うならば、本来怠るべきではなかった設備への投資を怠った。
だからどっちも問題があるわけだ。どっちが正しいとか、どっちが悪いとか、そういう問題じゃないんだと思う。
どこで見たのかは忘れたが、権利を主張するよりも前に義務を果たすことは、人間が社会生活を送るうえでは大前提にあることだと思う。
どちらも義務を怠った結果、どちらも叩かれる。それがたまたま障碍者というデリケートな問題（と言ってしまうこと自体もあまりよくないのだろうけれど）だったのではないだろうか。
障碍者は、言い方は悪いが健常者にできないことがあるのは仕方のないことだ。誰もそれについては咎めない。まあ、咎める人もいるだろうが、そいつがおかしいだけ。例えるならば男女平等と言いつつも男性が妊娠できないことをとがめないのと同じだとわたしは思う。違ったら申し訳ない。だから健常者は障碍者がどんなに努力しても自力で出来ないことを社会的にサポートする。そのための障碍者差別解消法や、障碍者基本法だ。航空機は確かに安全性は高い交通機関ではあるが、「もしも」の場合最も被害が甚大になる交通機関の一つであることも否定できない。だからこそ乗客の安全を守るために細かく航空法で座席まで定められている。それは障碍者を後回しにするためではなく、全員のために最も安全で確実な方法であるから、だろう。安全管理についてはツイッターで回ってきた元航空会社在籍の方のブログが大変わかりやすかったので張ります。 http://isumi.rail.shop-pro.jp/?eid=2918 というかこれを読めばぜんぶ終わる気がする、私の増田を読むならこっち読んで。
話を戻す。
今回事前連絡を怠った上で搭乗を強行突破しようとしたことで、当人はほかの乗客を危険にさらしたと考えられてもおかしくないわけだ。たまたま安全に空路を行くことが出来て、たまたま無事に到着することができた。それだけのこと。そりゃ、万が一を考えてしまったらキリがないけれど、想定しうる避けられるリスクを避けるための規則を破り、それでいて権利を主張するのはいかがなものかと私は思う。事前連絡を行った上で搭乗を拒否されたことを問題提起することは正しいが、事前連絡を怠ったうえで問題提起することは、方法としては好ましいものではない。
かといって航空会社の肩を持つつもりも私にはない。本来平等な機会を与えるために公正な行動をするべきところを怠ったのは、たとえLCCというサービスを限界まで削った格安航空会社だとしても、そこは削るべきところではないと思うからだ。全員が同じサービスを受けるための土台作りを怠ったのは、これまた好ましいことではない。LCCにそこまで求めるな、という人もいるみたいだが、LCCが削るべきなのは座席や食事などの「なくても搭乗・飛行に特段問題にはならないこと」であって、搭乗という行為そのものを否定することではない。
そもそもどちらが正しい、どちらが悪い論争について思うのだが、双方の主張が異なるのだ。
当人を擁護する側は「障碍者への配慮が足りない」だし、航空会社を擁護する側は「権利の前に義務を果たせ」だし。どちらも一方的で、交わりっこない。どっちの主張も「そうだよな！」と思う一方で、どっちの行動も問題視されて当然だ。議論することじゃない。
どちらかを擁護しているだけの人を見てなんともモヤモヤしたので吐き出させてもらいました。雑感です。ああ叩かれたらどうしよう。
