  |
はてなキーワード: websocketとは
コメントログへのアクセス先URIが書かれたWebSocketのデータ(↓こういうの)を、4年間集めてたんだけど、
{"type":"room","data":{"name":"アリーナ","messageServer":{"uri":"wss://msgd.live2.nicovideo.jp/websocket","type":"niwavided"},"threadId":"M.QyofMf3h0ahYa9PujZiwMA","isFirst":true,"waybackkey":"waybackkey","vposBaseTime":"2022-11-21T18:30:00+09:00"}}
https://live.nicovideo.jp/watch/lv338977521
以前から「そのデータからコメントログを全取得する作業を今年とかにやらないとな…」と思ってたが、ニコニコへの大規模攻撃が起こってしまって、さらに嫌な予感がしたがニコ生復活後に的中した。
まだ確認していないけども、自分が集めてたそのデータが全部無効になってしまってるだろうし、何も言えねえ。
(大規模攻撃関係無くいつか「wss://msgd.live2.nicovideo.jp/」が変わってただろうけども、長い事(数年間)そのuriで運用されていたし、もし攻撃されてなければ間に合う可能性もあった訳で…。)
溜め息しか出ない。
やっちまったなあ…。
運営に望む事は「有料会員は過去の生配信のコメントログがダウンロードできる」とか今後そういうサービスしてくれないかな…。はあ。
ちなみに、ニコ生がHTML5プレーヤー以前だった頃のソケット通信によるコメントログ取得って、もうできないよね…。 ちなみにそれもxmlファイルが1年分ぐらい溜めてる…。
＝＝＝＝＝
東大卒のヨーロッパでエンジニアやっている人から解説しよう。（ちなみに医学部は防衛医大に補欠合格していた）
エンジニアになるより医者やっていたほうが（国内で頑張る分には）絶対いいと思う
ちなみに医学部にいった友人の何人がむしろテック系に流れてきているという事情がある。
おそらく、増田はたしかに昔からプログラミングをやっていたと思う。頭もいいんだろう。厨ニが溢れていて気持ちが悪い。
エンジニアも厨ニ病でマウント取っていいていい時代でもないです。明らかにマウント取りたくてウズウズしすぎて、大した知識がないのに、
表面的な知識を羅列しているところがあったので突っ込んでいく。
ー＞そんなことない。フロントも色々やらないといけないが、バックエンドに比べて経験年数がひくい人も流れ込んできているので、バックエンドの人に比べて
できる領域が狭いので給与が低い、またおそらくDCL、DML、DDLといった用語を知っていることをひけらかしたかったのかもしれないが、全くどうでもいいです。
＝＞全部できようとして、破綻しているのでブーメランですよ。あなたの想定している、こんなフルスタックは成り立たない。
現場に放り込まれても１０年ぐらいかかる。というより、フロントからバックから低レイヤから、モバイルまでやることはもはや現実的ではない。
＝＞QUICとかマイナーなプロトコルを話すよりはちょっと変化球のあるプロトコルでいけばWebsocketぐらに抑えておきましょう。低レイヤーの話はわたしもわかりませんが、C言語ができないのに「おそらく QUIC か MQTT 」とか分かってない英単語４文字を羅列するのは厨ニ病すぎます。
=>自分はcloudfrontやWafを触ったことがありますが、かなりのインフラエンジニアにならないかぎり、ここ触りません。cdnは影響範囲が大きいし設定に時間が掛かったりします。片手間でできません。インフラエンジニアに触らせます。異常検知、アラートといったものは、実は結構時間がかかるので、強いかどうかではなく責務の分割からインフラに任せます。知らないことは知らないって書きましょう
本当に医学生ならここ数年の技術についてこの指摘ができる程詳しいわけないし少なくとも10年位は業界にいないとこういう感覚は身に付かない。 」
＝＞こんなにあれこれ、やっている時間はないでしょう。趣味のサイト製作でやるにしても絶対できてない。kubernetesを使っただけで時間切れになる。Kafkaを触ったとかいているが、Kafkaはサーバで使ったのかな？どういう利用シーンかというと膨大なログの収集等で使うのだが（ただのNoSQLではない）、Zookkeeperで調停させて、topic数とか調整するんだけど、わかってます？ElasticSearchだけ書いてたらまぁあるかなと思うけど。Redisもちゃんと使えてる？pub/subとか分かってないと思う（普通に理解する必要があんまない）
それでkotlinなんて触ってる時間なんて絶対にないし、Rustを更に付け焼き刃に付け焼き刃している時間なんてぜええええたいにない。やることが絞り込めてない。無意味にマウント取りたいだけ。なんとなく書いているcode deployなんて、それだけで使いこなすのが大変なれべる。
ci/cdのうちciだけかたっているならわかるがcdとなるとかなり時間がかかる
＝＞MyISAM をInnoDBに切り替えるなんてことしているところは無い。万にひとつあったとしても、大事で、それだけで数ヶ月のものなので、この付け焼き刃の知識の人が触る機会はない。
＝＞ES2015以降の差分は微々たるもので、どうでもいいです。ES2018ぐらいの現実的な数字にしてたらばれなかったのにね。
Next でSSRまで踏み込むと結構、フロントのことをキャッチアップするだけでかなり厳しいと思いますが、できているのかな？
＝＝＝＝＝
ー＞アメリカの事情は知らないはずなので知らないことは書かないようにしましょう。
ー＞ヨーロッパでは白人様はHRとかマーケやってます。移民にたよってます。ロシア、ウクライナ、インド、パキスタンなど
なぜ、ヨーロッパ人が避けるかといと「やる気がないから」です。以上
モバイルアプリの実装と言えば主力はKotlin、Swift(Objective-C)だけど、簡単な作りであればcordovaをベースにフロントエンド開発ライクに進められる。
そもそものライブラリ選定には関わっていなかったものの、便利と思って使った結果後悔した思い出のお話。
Angular, Vueで実装していたけどレンダリング系に属するイベント盛りだくさんの場合、
結果的にネイティブ実装したほうが楽だしレンダリングの面で有利。
そもそもcordovaだからと言ってネイティブの知識がいらないわけじゃない。
標準サポートしているプラグイン群でできることは限られてくるし、そのまま突き進むならネイティブ実装の知識は必要になる。
これは当たり前だけど…
JSのパッケージングだったりCSSビルドが組めないとなると逆にコスト高。
そもそもNode.jsのビルドを根本的に理解してない奴がプロジェクトを作ったせいで
JSのパッケージビルドもされない、jQueryを突っ込まれるなどひと悶着あった。
3年前くらいだったけど既にTypeScriptも出てたし、何故そうしなかったのか理解できない。
結果ロードが激重になった。そりゃそうだ、minifiedされてないのだから。
用法用量を正しく守って使わないと、後で面倒になる好例だった。
大概は専用プラットフォーム上でビルドしていくがこれがくせ者。
ブラウザIDE(という名のただのテキストエディタ)が使えるけどそもそも構成管理できない。
ローカルビルドと乖離するし、ブランチすら切れないのだから本人以外は触れないシロモノになってくる。
別端末でビルドしようとすると同名の新しいプロジェクトが作成される。
ここまでくるともう触りたくなくなる。ただ、触らないわけにはいかないので何とか整合が取れる状況にした。
さらに言えば、ビルドが終わってステータスが見れるが、内訳が見れるのはそのタイミングだけ。
多分、海外で公開したプラットフォームをそのまま持ってきてるんだと推測しているが流石にこれは悪意しか感じない。
ただのCLIをバックグラウンドで実行するだけのGUIラッパーと化している。
かといってlintを掛けてくれるわけでも無し。
個人的に要らないし今後は使わない。
突き当たったのはWebSocketを使うシーンが出てきたとき。
ライブラリで何とかする方向で進めたかったけどそもそもwebpackビルドにすら対応していなかった。
件のAngularベースの場合はもっとひどくてクソラッパーを作りやがったせいで依存度が激高になった。
ちなみにネイティブはそれぞれにサポートするライブラリが出ていて、最新バージョンに向けてきちんとメンテナンスされている。
根本的にiOS側の実装でレスポンシブ的なレイアウトが作りにくい現状を鑑みて、
WEBベースで新商品などの通知をしたい、残りは情報の閲覧のみでSPA構成的なシロモノで作りたい。
こんな需要には使ってもいいんじゃないかと思う。相当なレアケースだけれども。
いいところは確かにあって、CSSでデザインの調整が効くところは大いに評価できる。
これがまたネイティブ実装だと面倒。特にiOS。お前はダメだ。
結局進めていくとネイティブ実装の知識を求められるのだから、ネイティブで実装したほうが良くね？と言ったところ。
ユースケース的に超単純要件でアプリを作りたい、かつ、ユーザに何かpush通知的なやつを入れたいって場合は使ってもいい気がする。
ここ連日騒がれている7pay。
パスワードリセットリンク送付先のメールアドレスに対して設計上の問題で脆弱性が発覚して大変な事態に発展しています。
昨日の会見では社長のITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています。
また、会見内で「セキュリティー審査を実施した」と明言がされました。
https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html
セキュリティー審査を実施していたにも関わらず、何故今回の問題が見逃されたのか。
非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います。
その名の通り、サービスローンチ前に実施する、脆弱性や問題がないかの審査の事・・・だと解釈しました。
一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます。
「実施した」とはいっても、どういった内容を実施したかはわかりません。
ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチな脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います。
通常、脆弱性診断というと、以下のような項目があげられると思います。
抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います。
詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています。
LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティ、スプラウトなど。
ただ、今回の脆弱性診断が外部ベンダで実施されたのか、内部で実施されたのかはわかりません。
以下、推測をつらつら書いていきます。
脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります。
Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます。
また、数量計算もベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。
お願いすれば見積もり時にステージング環境で動いているWebサービスをクロールして、各ページの評価を付けてくれるベンダもあります。
規模と見積もり内容にもよりますが、100～200万といったところでしょうか。
スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万～100万程度でしょうか。
プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います。
これ以外にWebSocketを使っていたり、別のサービスと連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります。
Webサービス200万、スマホアプリ(iOS、Android)100万*2、プラットフォーム100万とすると、500万円掛かるわけですね。
脆弱性診断をするだけでこれだけのお金が吹っ飛んでしまうわけです。
そしてこれをそのまま発注するかと言われると、多分しないでしょう。
セキュリティはお金が掛かる割にリターンが少なく、目に見える結果が必ず出てくるとも限りません。
経営層は中々首を縦には振らないでしょう。
会見でも明らかになったことですが、社長のITリテラシはあまり高そうにありません。
こうなると脆弱性診断の稟議を通すのは中々容易ではなかった可能性もありそうです。
また7月1日に間に合わせたようなところもあるっぽい(?)ので、開発側に資金を全振りしていた可能性もあり、診断に費用を掛けられなかったのかもしれません。
いずれにせよ、全く実施しないのはまずいし重要そうな部分だけピックアップして実施しましょうという話にはなるでしょう。
削れるものをあげていってみましょう。
例えば、iOS用スマホアプリは実施しなくても良いかもしれません。iOS上で動くアプリは確かサンドボックス構造になっているはずで、ローカルに何かしらのデータを持っていても外部からのアクセスは基本不可であるためです。確か。
そもそもスマホアプリ自体不要かもしれません。7payのサービスへのアクセス用インターフェイスとしてのアプリしか提供していないのであれば、取り扱うデータはほとんどないと考えられるためです。そのため、スマホアプリAndroidのみ、もしくは両方実施しなくても大きな問題は発生しないのではないかと思います。
・・・この辺り私の勘違いというか、「最優先でやるべきだろjk」といった考えがあれば指摘ください。
プラットフォームも、ベンダによりますが実施しなくとも良いとも思います。
ベンダの説明でも、主にポートスキャンをして、空いているポートに対してtelnetで色々したりするといった説明がなされたと思います。
Webサービスなら443と、空いていても80くらいしか外部には公開していないので、これは実施しないという選択をしても不思議ではないと思います。
サーバのコンフィグも、DocumentRootがおかしいとか致命的な設定ミスをしていない限りは見てもらう必要はないでしょう。
そもそも構築手順等はノウハウもあるでしょうし、わざわざ見てもらう必要性はほとんどないわけです。
ワイドショーでは「不正は海外IPからで、国外からのアクセスを許可していた」事が取り上げられていましたが、例えプラットフォーム診断をしていても、この辺りは指摘されなかった可能性があります。
実施していればもしかしたら備考レベルでの注意や、口頭で「国内のみに留めておいた方がいいかも」といったことは伝えられたかもしれませんが、「利便性」という観点から実行されることはなかったんじゃないかなと思います。
Webサービスですが、ログイン・ログアウト処理は必須でしょう。また、新規登録、情報変更、退会処理も重要です。
パスワードリセットはどうでしょうか。正直これも重要です。なので、ベンダに依頼するにあたってはここも診断対象としていたはずです。
ところで今回の件では協力会社について様々な憶測が飛んでいますが、NRI説が結構人気みたいです。
ただ、NRIにはNRIセキュアというセキュリティに特化した子会社が存在しています。
もし脆弱性診断をするとなった場合、そこを使わないという手はあまり考えられません。そもそも発注時にそれを見越して診断費も開発の見積もりに含まれているのではないかと思います。
ただし、セブン側が「脆弱性診断はこちら側で発注します」と言っていれば話は別です。
NRIセキュアは診断費用が高いらしいので、コストダウンするために別ベンダに診断部分のみ発注する可能性はあります。
別のベンダに発注したことで、抜け落ちた可能性はゼロではないかもしれません。
また、NRIセキュアが実施する場合においても、「ここは抑えておいた方が良い」という機能毎やページ毎にランク付けした資料をセブン側に提出することと思われますが、どこを実施してどこを削るかの最終的な判断はセブンに委ねられます。
考えられる事としてはパスワードリセットの処理を診断対象外としたことですが・・・そうする理由もわからないので、うーん・・・。
ただ、こうして対象を削りまくることで100万程度、もしくはそれ以下まで診断費用を抑えることができます。
使ったことはありませんが、SecurityBlanket 365というサービスは自動での定期診断が可能なようです。
ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダに逐次依頼する脆弱性診断よりかは安く済むはずです。
ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。
ツールの手が届く範囲での、XSSやPoC、ヘッダの有無など、ごく一般的な脆弱性診断になると考えられます。
でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。
脆弱性診断ツールはOSSのものもあればベンダが販売していたり、SaaSで提供しているものもあります。
OSSならOWASP ZAPやw3afがWebサービスの診断が可能です。また、phpcs-security-auditなど、ソースコードを解析し脆弱な箇所がないかを診断するものもあります。
ちなみにWebサービスに対する診断を「DAST」、ソースコードに対する診断を「SAST」と言ったりします。
有償のものとなると、DASTは先程のSecurityBlanket、AppScan、Nessus、Vex、VAddyが挙げられると思います。
SASTになると、RIPS TECH、Contrast Securityなどでしょうか。
上記のようなツールを用いて、セブン内で脆弱性診断を実施することでセキュリティの知見を高めたり、内部で完結させるための動きを取っていたかもしれません。
こういった動きは結構色んな組織で見受けられます。外部の手を借りずに診断ができれば、関係者間の調整も楽ですし、それと比べると費用も安く済みますからね。
ただし、社内のエンジニアに任せる事になるため、片手間になってしまう可能性があります。
また、ツールの使用方法についてのノウハウは溜まるかもしれませんが、それとセキュリティの知見が溜まるかどうかは別の問題としてあると思います。
・・・とは言ってもセブンにはCSIRT部隊がちゃんとあるんですよね。
https://www.nca.gr.jp/member/7icsirt.html
『7&i CSIRT は、7&i グループの CSIRT として設置され、グループ企業に対してサービスを提供しています。』と記載があります。
また、『7&i CSIRT は、7&i HLDGS. の組織内に専任要員を以て設置され、インシデント発生時の対応だけでなく、インシデント発生の未然防止にも注力しています。
グループ企業の情報システム部門と連携し、7&i グループ内で発生するインシデントに対する未然防止のための調査・分析とリスク情報の共有、ならびにインシデント対応活動を行なっています。』
という記載もあるため、今回の7payも、7&i CSIRTが動いてセキュリティ関連のチェックをしていたのではないかと思います。「情報システム部門」とはありますが。
組織図上にはありませんが、デジタル推進戦略本部の下か、リスクマネジメント委員会、情報管理委員会のどこかに所属しているんじゃないかと思われます。
日本CSIRT協議会にも名を連ねているわけですし、CSIRTメンバーは専任要因ともありますし、セキュリティ関連の技術知識は十二分にあると思うんですよね。
なので、内部でツールを使って実施していたからといって、こんな重大な不備を見逃すというのはちょっと考え辛いなあ・・・と思います。
会見内で言われた二段階認証も検討事項に上がらなかったのかなあ・・・と。
で、これを書いている最中に気付いたのですが以下のようなリリースが出ていたんですね。
https://www.7pay.co.jp/news/news_20190705_01.pdf
これを見ると内部のCSIRTが機能していなかったか、力不足と判断されたかどちらかになるのかな・・・と。
実際はどうだかわかりませんけど・・・。
これも有り得る話かなあ・・・と。
開発やベンダやCSIRT部隊が情報共有したとしても、POが忘れていたとか、伝えたつもりが曖昧な表現で伝わっていなかったとか・・・。
ベンダが実施して指摘事項として伝えていたけど、いつの間にやら抜け落ちていてそのままサービスイン・・・というのもシナリオとしては考えられますね。
7payは社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応に時間を取られることになります。
そういった事を許さない空気が出来上がっていると、まあ中々上には上がってきづらいです。
これも十分にありえる話ですかね。ないといいんですけど。
どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。
そこで思ったのですが、情報セキュリティ基本方針と個人情報保護方針を元にしたチェックリストのようなものがセブン内にあって、それを埋めた・・・みたいなことを「セキュリティー審査」と言っていたりするのかなと思ってしまったんですね。
でもこれはセブンペイの社長が個人情報保護管理責任者ということで、ISMSやPMS等で慣れ親しんだ単語である『審査』を使っただけかもしれません。
そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業が・・・。
大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・。
というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。
そういえばomni7で以下のお知らせが上がっていましたね。
https://www.omni7.jp/general/static/info190705
『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。
もしくはわかりやすい対策を提示しろと言われたのかもしれません。それなら仕方ないんですけど。
以上。
一部typoとか指摘事項を修正しました(役不足→力不足 etc)。
ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。
ちゃんと読んでいただけましたか？全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・。
一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性や問題がないかの審査の事」、つまり「脆弱性診断」を指していると仮定して本エントリを書いています。
そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。
監査は貴方の記載する通り「ある事象・対象に関し、遵守すべき法令や社内規程などの規準に照らして、業務や成果物がそれらに則っているかどうかの証拠を収集し、その証拠に基づいて、監査対象の有効性を利害関係者に合理的に保証すること」です。
貴方の言う「監査」に近いことは「セキュリティー審査自体が、情報セキュリティ基本方針と個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ Permalink | 記事への反応(2) | 05:48
まじな話をすると、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チェイン, リファクタリング)
いや、おまえは、単に、マウスイベントを拾って、FRPストリームに流す、という接続部分、つまり、FRP変数への書き込みについて、イチャモンつけてるんだよな？おまえにとっての「自動」の「同期」って何？
マウスイベントなりをラップしたFRPライブラリで、そのラップイベント宣言したら、ラップ変数に自動的に流れるとかそういうこと言いたいんだろうが、そこからその変数、関数なりで変換して行くのに、それがラップされてようがされてまいが、手間はまったく一緒だって理解してる？
あと、そういう既知のイベントなら、既知のマウスイベントなりを全部ラップしてやろうとおもえば、やれないことないだろうし、できるが、
既知ではない、FRPライブラリでラップされてないIOイベントとかどうすんの？w あほなの？ｗ
たとえば、HTTPイベント、WebSocketイベント、全部FRPライブラリでラップして、
みたいにやるのか？ 誰かが書いてくれるまで待つとか？ｗ
あと、マウスの位置から１０オフセットさせたい、とかオプションも無数にありうるわな？
オプションサポートされてないラップだったらどうすんの？ｗ やっぱアホなの？ｗ
最初からネイティブのイベントあったら、かんたんにできるだろ？ラップAPI参照せずにすむだろ？あほなの？ｗ
何を作りたいかというとマルチプレイヤーのブラウザゲームが作りたいんだよね。
俺の開発用のceleron 1コアのメモリ1GB環境では重すぎる。
isoファイルを10000個同時にダウンロードしてるぐらい重すぎる。
ページの読込みがなかなか完了しない。
こんなクソ重いフレームワークはそれなりのサーバスペックがないとパフォーマンスに影響が出すぎるので除外したい。
phpのフレームワーク一般に言えるんだけどプロジェクト毎にプロジェクトルートのなかにフレームワークのコアファイルを置くのがなんか嫌だ。
nodejsはシングルスレッドなので負荷の高いサイトで使うのは厳しそう。
pythonでもgolangでもwebsocketは使えるのでnodejsにこだわる必要もないしvert.xを使う選択肢もある。
日本ではvert.xの話題あんまり盛り上がってないよね。どこかの企業さんが実践で使いましたって記事を書いたら会社の知名度が上がると思う。
scala,golang,elixirこの3つの選択肢でいいのかな。
でも負荷の高いブラウザゲームやってる会社ってrailsとかphpだよね。
redisをうまく活用しとけばあんまりそれ以外でボトルネックとなるようなことって無いのかな。
スクエニさんのオンラインのドラクエもどうやってるんだろうね。
あと海外のブラウザゲームってほとんどがaws使ってるのでaws使えばいいのかな。
でも怖いよね高額料金を請求されたらさ。
金儲けの為にサイトを作らないとawsは使ってられない気がする。
Webとか詳しくない人に説明するとすると、WebSocketっていうのはチャットとか対戦麻雀みたいな
ユーザー同士がリアルタイムで繋がれるようなWebサイトを作るための技術で、
現在これを使ってなんかそこそこに流行りそうな新しいゲームとかサービスを作りたいと思ってるんだけど、
「今更リアルタイムなチャットなんて作ってもなー」とか「対戦アクションとかは個人で作るのは現実的じゃないよなー」とか、
そこで、なんかみんなが「こういうチャット式のSNSあったら便利なのになー」とか
「こういう対戦ゲームあったら楽しそうだなー」みたいに思うサービスとかゲームのアイディアがあったらちょっと教えてほしいと思ってる。
例えば、同じ配列？のフリーセルを複数人でやってタイムを競いあうような既存のゲームを利用した対戦ゲームだったり、
特定の層向けのチャットサービスだったり、既にあるようなサービスやゲームにちょっとしたアイディアを付け加えたものだったり、
既にゲームとしては存在するけどブラウザゲームとしてはまだ存在しないゲームとか、そういうのでもなんでもいい。
皆様の知恵を貸してください。
去年の今頃は「今年こそはすごいWebサービス作るぞ！！！！！！！！！！！」って意気込んでたのに
なんかもう今日が最終日。
ということでこの12月頭から何か作ろうと考えていて、丁度年末だからということで作った。
前にAmazonの購入金額合計を出すブックマークレットが流行ったけど、それとほぼ同じ。
Amazonの今までの合計金額と、書籍とかPCとかカテゴリごとの合計金額出してグラフにする。
年末だしTwitterで「2014年のKindle購入金額内訳は...でした」とか投稿すれば
みんなつられてアクセスするはず！宣伝しなくても勝手に大ブーム間違いなし！！！！！！！！
って思ってたけど
投稿してもだれもアクセスしてくれない。待っても待ってもアクセス0。
e？嘘でしょ？？？って思ったら
のはずだったけど今度はrobots.txt見に来るクソbotしかアクセスしてくれない。
虚しさ半端ない。
というかTwitterでURLつぶやくと即効でどこぞやのクローラー巡回してくるんですね。
構成自体はクライアント・サーバサイド共にjs。EC2上でnode.js。
D3.jsのグラフ画像がsvgだからどうにかしてpngにしないとTwitter投稿出来ないのが微妙に面倒だった
投稿時にクライアント側でbase64→canvas→pngにしても良かったけど
商品のカテゴリ取得するためにはProduct Advertising API使うしかなくて
redis上にキャッシュしておいたりwebsocketで適当に進捗伝えたりした。
今回得た経験値としては
あたり。
今年は残念ながら目標不達成だったけど、いい最終日の過ごし方になったと思う。
お疲れ様でした。
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を使い続けると思います。
今年に入ってからプログラミングを勉強し始めて、php、javascript、pythonでとりあえず動くものを作れるようになった。各言語のメジャーなwebフレームワークも使えるようになったし、過去の株価ダウンロードしてmysqlに突っ込んでta-libでシストレのバックテストして遊んだり、ニコ動のタグ検索結果のクローラー作って新着があればメールで知らせてくれたりするの作ったり、websocketためしてみたりbackbonejsで遊んだりもしてる。ニートだから時間が無限なのもあるけど、5か月弱でずいぶんできることが増えてきたなと思う。そろそろ何か作って公開してアフィで稼ぎたいなと思い始めた。でも何も出てこない。今月入ってからずっと考えてるのに作りたいものが浮かばない。いくら勉強してもアイデアがなければ無意味なんだと気付いた。誰かアイデアちょうだい
ようやくRailsの開発を一人で出来るようになった彼女が、俺に突然質問を投げかけた。
「ねぇ、WebサービスのPushってどうやって実装するの？」
「クールな順にWebSocket、次にコメット、最後にポーリングだよ」
彼女は目を輝かせながら「それでそれで？！」と説明を求めてくる。
「ポーリングは、一定の時間ごと、たとえば３秒ごとにAjaxでサーバにリクエストを送って新着の情報が無いか問い合わせて、もし新着があれば処理を、なければスルーして次の問い合わせに備えるPush通知の実装だ。手軽に実装できる反面、新着がない多くの時間常にリクエストを送り続けることになるので無駄が多い。大規模なサービスで実装すれば、それだけでDDoSっぽくなっちゃう。また、リアルタイムも厳密には実現できなくて、MAXでポーリング間隔分のラグが発生してしまう。小規模なサービスで、とりあえず実装するにはオススメかな。」
なるほどなるほど、と彼女は頷く。
「コメットは？」
「コメットはポーリングを改良したもので、ブラウザからリクエストが送られてきた時点ではサーバはすぐにレスポンスを返さずに、処理中ってことでコネクションを張ったまま一定時間待つんだ。それで、なにか新着があったタイミングで、昔送られてきてたリクエストのレスポンスを返す。そうすると、新着があったタイミング＝レスポンスを返すタイミングになるので、レスポンスはほぼリアルタイムになる」
「なるほど！すごい！！！」
「頭の良い実装だよね。Facebookの通知なんかはコメットだよ。ただ、コメットも万能じゃない。まず、レスポンスはいつまでも待てるものではなく、待たせすぎちゃうとタイムアウトになっちゃうんだ。だから一定時間ごとには何もなくても"進捗はなかったよ”というレスポンスを返してあげなきゃいけない。また、サーバはコネクションを常に割り当てないといけないので、IOをブロックするようなサーバだとリソースを食い過ぎて耐えれ無くなっちゃうから大規模な運用には金がかかっちゃうんだ。所詮はHTTPを使ったごまかしでしか無い。オーバーヘッドが大きいんだよ。」
「な、なるほどー」
少し話が小難しくなったためか、一生懸命理解しようと彼女が頑張っている。かわいい。
「そこでWebSocketの登場だ。WebSocketは厳密には違うんだけど、HTML５関連の新しい技術で、ネトゲで使うTCP/IPのセッションのようなコネクションをサーバ側と張ることができる技術なんだ。しかもNATとかも超えてくれる便利な技術。これがあればリアルタイムWebの実装はすごく簡単になるんだけど、まだ新しい技術というのもあるし、対応してるサーバやライブラリの不足や、プログラミングのスタイルがイベント駆動になるという変化もあって、まだまだ一般的にはなってない。対応してるブラウザも最近まで多くはなかったしね。やっとiPhoneでも使えるようになったし、スマフォのWebでも普通に使えるようになってきた。これからが楽しみだね。」
「うーんと、うーんと、つまり」
彼女は今日得た知識のまとめに入ったようだ。一生懸命Webの技術を学ぼうとしている健気な彼女に、僕は心がキュンとなった。
「そう、つまり…」
びっくりして目を見開いている彼女。
「チュッ、チュッ、チュッ、チュッ、チュッ、」
「これがポーリング。」
「チュポッ…」
彼女の頬は少しだけ赤く染まっていた。
「これがWebSocket、そして…」
最後に僕は彼女の顔を両手でホールドし、８秒くらいの長い、とても長いキスをした。
「よし、じゃあコーディングに戻ろう。」
「私、コメットがいいな。。。////」
