「websocket」を含む日記 RSS

はてなキーワード: websocketとは

2024-03-19

APEXの大会チートで潰れた件でオタクWebSocket観点から考えるととドヤしてた

そもそもAPEXはゲームUDPで、ログイン関係gtcpなんだが…

自称アンチチートの万アカウントEAC経由でチートダウンロードされた(実際はメモリ不正操作された情報を送るぐらいしかしてない)とか言ってみたり

ゲーマーってなんでこんなに浅いわけ?

貴重な時間ゲームになんかに使ってるからそうなんだよw

ゲーム開発者と言う立場上表では何一つ言えないけどオタクが語る技術的なことほぼかならず1から100まで全部間違ってるよ

1回でも社会でて派遣バイト以外の仕事してみ?

自分人生が恥ずかしくなるから

2022-05-05

anond:20220505204559

からだけどステートフルなプロトコルを使うとこは仕方なくインスタンス立てることある

WebSocketとかWebRTCとか

サーバレスに寄せられるとこはできる限り寄せるけどね

FWとかルーティングとかOSパラメータとかストレージ容量のアラートとか毎回設定するの面倒くさいじゃん

2021-07-09

https://anond.hatelabo.jp/20210708205945

=====

東大卒ヨーロッパエンジニアやっている人から解説しよう。(ちなみに医学部防衛医大に補欠合格していた)

エンジニアになるより医者やっていたほうが(国内で頑張る分には)絶対いいと思う

ちなみに医学部にいった友人の何人がむしろテック系に流れてきているという事情がある。

厨ニが溢れているので、しっかり解説してあげます

おそらく、増田はたしかに昔からプログラミングをやっていたと思う。頭もいいんだろう。厨ニが溢れていて気持ちが悪い。

エンジニア厨ニ病マウント取っていいていい時代でもないです。明らかにマウント取りたくてウズウズしすぎて、大した知識がないのに、

表面的な知識を羅列しているところがあったので突っ込んでいく。

~~誰にやらせてもデータベースにクソなDCLを飛ばせないから。逆に、データベースを触れることができるプログラマーリスク責任が大きいから、給料が高いのだよ

ー>そんなことない。フロントも色々やらないといけないが、バックエンドに比べて経験年数がひくい人も流れ込んできているので、バックエンドの人に比べて

できる領域が狭いので給与が低い、またおそらくDCL、DMLDDLといった用語を知っていることをひけらかしたかったのかもしれないが、全くどうでもいいです。

~~君はソフトウェアエンジニアになりたいのだろ?世の中は分業で成り立っているのだから、全部やろうとするやつはアホだよ

=>全部できようとして、破綻しているのでブーメランですよ。あなたの想定している、こんなフルスタックは成り立たない。

現場に放り込まれても10年ぐらいかかる。というより、フロントからバックからレイヤからモバイルまでやることはもはや現実的ではない。

~~おそらく QUIC か MQTT あたりだろ?逆にいえば、それが実装できたら他社と差のつけられるプロダクトだったはずだ。つまり会社利益の源泉であった部分をみすみす実装できないようでは、そこらへんの専門卒以下だぞ。

=>QUICとかマイナープロトコルを話すよりはちょっと変化球のあるプロトコルでいけばWebsocketぐらに抑えておきましょう。低レイヤーの話はわたしもわかりませんが、C言語ができないのに「おそらく QUIC か MQTT 」とか分かってない英単語文字を羅列するのは厨ニ病すぎます

~~プログラマーに徹するつもりだろうが、ツヨツヨエンジニアデプロイした経験から逆算してコード設計・開発をやるのだぞ。そうなると、CDN, DNS, WAF, S3, ログの出し方、メトリックス、異常検知、アラートを把握する必要があるのだぞ。そういうのを知るためには、ポートフォリオAWS GCP Azure といったクラウド経験を書くべきだと思うのだが、なぜしない?

=>自分cloudfrontやWafを触ったことがありますが、かなりのインフラエンジニアにならないかぎり、ここ触りません。cdnは影響範囲が大きいし設定に時間が掛かったりします。片手間でできません。インフラエンジニアに触らせます。異常検知、アラートといったものは、実は結構時間がかかるので、強いかどうかではなく責務の分割からインフラに任せます。知らないことは知らないって書きましょう

本当に医学生ならここ数年の技術についてこの指摘ができる程詳しいわけないし少なくとも10年位は業界にいないとこういう感覚は身に付かない。 」

~~たしかおかしいよな。Kubernetes や Terraform を弄って、CIGitHub Actions、CD には AWS CodeDeploy を使って、ブログは Jekyll で静的サイトジェネレータを使いつつ、自前のサービスを立ち上げるために Rails, Next, React, PostgreSQL, Redis, Kafka, Elasticsearch, S3 の勉強をしつつ、スマホ環境のために KotlinSwift を触れているなんて変だよな。そういえば、Docker が来るまでは Vagrant環境をつくっていたのも忘れてたよ。あと Rust を今年に学ぶ言語にするなんて、受験生にあるまじき行為だよな。うん。

=>こんなにあれこれ、やっている時間はないでしょう。趣味サイト製作でやるにしても絶対できてない。kubernetesを使っただけで時間切れになる。Kafkaを触ったとかいているが、Kafkaはサーバで使ったのかな?どういう利用シーンかというと膨大なログ収集等で使うのだが(ただのNoSQLではない)、Zookkeeperで調停させて、topic数とか調整するんだけど、わかってます?ElasticSearchだけ書いてたらまぁあるかなと思うけど。Redisちゃんと使えてる?pub/subとか分かってないと思う(普通に理解する必要あんまない)

それでkotlinなんて触ってる時間なんて絶対にないし、Rustを更に付け焼き刃に付け焼き刃している時間なんてぜええええたいにない。やることが絞り込めてない。無意味マウント取りたいだけ。なんとなく書いているcode deployなんて、それだけで使いこなすのが大変なれべる。

ci/cdのうちciだけかたっているならわかるがcdとなるとかなり時間がかかる

~~ストレージエンジンが切り替わるときカオスな目にあったけどさ

=>MyISAMInnoDBに切り替えるなんてことしているところは無い。万にひとつあったとしても、大事で、それだけで数ヶ月のものなので、この付け焼き刃の知識の人が触る機会はない。

~~TypeScriptNext と React を書く。もちろん JavaScript は ES2020 あたりまでは説明可能

=>ES2015以降の差分は微々たるもので、どうでもいいです。ES2018ぐらいの現実的数字にしてたらばれなかったのにね。

NextSSRまで踏み込む結構フロントのことをキャッチアップするだけでかなり厳しいと思いますが、できているのかな?

=====

~~アメリカでも「テック系はハードから避ける」

ー>アメリカ事情は知らないはずなので知らないことは書かないようにしましょう。

ー>ヨーロッパでは白人様はHRとかマーケやってます移民にたよってますロシアウクライナインドパキスタンなど

  なぜ、ヨーロッパ人が避けるかといと「やる気がないから」です。以上

※ちなみに防衛医大の補欠合格東大に入る人なら大体受かると思う

プロトコル実装とかようできんわ…

かなり昔WebSocket実装とかゼロからやったけど…

存在しなければ実装するしかないわけだけど…

2019-12-29

モバイルアプリハイブリッド実装で後悔したもろもろ

モバイルアプリ実装と言えば主力はKotlinSwift(Objective-C)だけど、簡単な作りであればcordovaベースフロントエンド開発ライクに進められる。

そもそもライブラリ選定には関わっていなかったものの、便利と思って使った結果後悔した思い出のお話

WebViewベースである以上、イベントレンダリング系統ネイティブに劣る

特にiOSが顕著だった。

Angular, Vue実装していたけどレンダリング系に属するイベント盛りだくさんの場合

結果的ネイティブ実装したほうが楽だしレンダリングの面で有利。

そもそもcordovaからと言ってネイティブ知識がいらないわけじゃない。

標準サポートしているプラグイン群でできることは限られてくるし、そのまま突き進むならネイティブ実装知識必要になる。

フロントエンド開発できない奴が作れる代物ではない

これは当たり前だけど…

JSパッケージングだったりCSSビルドが組めないとなると逆にコスト高。

Angularベースで進めていたときにそれは起こった。

そもそもNode.jsビルド根本的に理解してない奴がプロジェクトを作ったせいで

JSパッケージビルドもされない、jQueryを突っ込まれるなどひと悶着あった。

3年前くらいだったけど既にTypeScriptも出てたし、何故そうしなかったのか理解できない。

結果ロードが激重になった。そりゃそうだ、minifiedされてないのだから

用法用量を正しく守って使わないと、後で面倒になる好例だった。

ビルドが意外と面倒で手間

大概は専用プラットフォーム上でビルドしていくがこれがくせ者。

ブラウザIDE(という名のただのテキストエディタ)が使えるけどそもそも構成管理できない。

ローカルビルド乖離するし、ブランチすら切れないのだから本人以外は触れないシロモノになってくる。

ビルドのためにアップロードするんだがこれまた賢くない。

別端末でビルドしようとすると同名の新しいプロジェクト作成される。

ここまでくるともう触りたくなくなる。ただ、触らないわけにはいかないので何とか整合が取れる状況にした。

さらに言えば、ビルドが終わってステータスが見れるが、内訳が見れるのはそのタイミングだけ。

これはマジで止めてほしい。殺意が湧くレベルでやめてほしい。

多分、海外で公開したプラットフォームをそのまま持ってきてるんだと推測しているが流石にこれは悪意しか感じない。

やろうと思えばそりゃローカルビルドはできるけれども。

クライアントOSで動くビルドツールが使い物にならない

ただのCLIバックグラウンドで実行するだけのGUIラッパーと化している。

かといってlintを掛けてくれるわけでも無し。

個人的に要らないし今後は使わない。

WEB RTCを使うとiOS互換に苦しむ

突き当たったのはWebSocketを使うシーンが出てきたとき

ライブラリで何とかする方向で進めたかったけどそもそもwebpackビルドにすら対応していなかった。

件のAngularベース場合もっとひどくてクソラッパーを作りやがったせいで依存度が激高になった。

ちなみにネイティブはそれぞれにサポートするライブラリが出ていて、最新バージョンに向けてきちんとメンテナンスされている。

その辺はJS世界の闇に降れた瞬間でもあったりした。

総括

根本的にiOS側の実装レスポンシブ的なレイアウトが作りにくい現状を鑑みて、

WEBベースで新商品などの通知をしたい、残りは情報の閲覧のみでSPA構成的なシロモノで作りたい。

こんな需要には使ってもいいんじゃないかと思う。相当なレアケースだけれども。

いいところは確かにあって、CSSデザインの調整が効くところは大いに評価できる。

これがまたネイティブ実装だと面倒。特にiOS。お前はダメだ。

結局進めていくとネイティブ実装知識を求められるのだからネイティブ実装したほうが良くね?と言ったところ。

ユースケース的に超単純要件アプリを作りたい、かつ、ユーザに何かpush知的なやつを入れたいって場合は使ってもいい気がする。

うそ大手でもなければ無い気がするけど。

2019-07-06

7payのセキュリティ審査って何をやってたんだろうか

ここ連日騒がれている7pay。

パスワードリセットリンク送付先のメールアドレスに対して設計上の問題脆弱性が発覚して大変な事態に発展しています

昨日の会見では社長ITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています

また、会見内で「セキュリティ審査実施した」と明言がされました。

https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html

セキュリティ審査実施していたにも関わらず、何故今回の問題が見逃されたのか。

非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います

セキュリティ審査とは

その名の通り、サービスローンチ前に実施する、脆弱性問題がないか審査の事・・・だと解釈しました。

審査」というとISMS辺りを連想しちゃいますね。

一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます

以後脆弱性診断と記載していきます

実施した」とはいっても、どういった内容を実施たかはわかりません。

ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチ脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います

通常、脆弱性診断というと、以下のような項目があげられると思います

抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います

詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています

LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティスプラウトなど。

ただ、今回の脆弱性診断が外部ベンダ実施されたのか、内部で実施されたのかはわかりません。

以下、推測をつらつら書いていきます

外部ベンダ発注したが、コスト削減のために対象を削りまくった

脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります

Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます

また、数量計算ベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。

お願いすれば見積もり時にステージング環境で動いているWebサービスクロールして、各ページの評価を付けてくれるベンダもあります

規模と見積もり内容にもよりますが、100~200万といったところでしょうか。

スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万~100万程度でしょうか。

プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います

これ以外にWebSocketを使っていたり、別のサービス連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります

Webサービス200万、スマホアプリ(iOSAndroid)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というサービス自動での定期診断が可能なようです。

ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダ逐次依頼する脆弱性診断よりかは安く済むはずです。

ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。

ツールの手が届く範囲での、XSSPoC、ヘッダの有無など、ごく一般的脆弱性診断になると考えられます

でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。

セブン内部でツールを用いた診断を実施していた

脆弱性診断ツール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は社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応時間を取られることになります

そういった事を許さな空気が出来上がっていると、まあ中々上には上がってきづらいです。

これも十分にありえる話ですかね。ないといいんですけど。

セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった

どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。

そこで思ったのですが、情報セキュリティ基本方針個人情報保護方針を元にしたチェックリストのようなものセブン内にあって、それを埋めた・・・みたいなことを「セキュリティ審査」と言っていたりするのかなと思ってしまったんですね。

でもこれはセブンペイの社長個人情報保護管理責任者ということで、ISMSPMS等で慣れ親しんだ単語である審査』を使っただけかもしれません。

そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業・・・

そもそもやってない

大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・

というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。

そういえばomni7で以下のお知らせが上がっていましたね。

https://www.omni7.jp/general/static/info190705

『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。

もしくはわかりやす対策提示しろと言われたのかもしれません。それなら仕方ないんですけど。

パスワード定期変更を推奨する因習はいつ消えるんでしょうか。

以上。

以下追記 2019-09-08

一部typoとか指摘事項を修正しました(役不足力不足 etc)。

ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。

所詮「人のつくりしもの」だよ

監査なんて取り揃えた書類通りになっているかどうかなので、監査受けているかセキュリティ的に大丈夫ってことじゃないよ

そんなに監査が万能なら監査できるくらいの人が作り出せば完璧になるはずだろ

ちゃんと読んでいただけましたか?全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・

一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性問題がないか審査の事」、つまり脆弱性診断」を指していると仮定して本エントリを書いています

そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。

監査貴方記載する通り「ある事象対象に関し、遵守すべき法令社内規程などの規準に照らして、業務成果物がそれらに則っているかどうかの証拠収集し、その証拠に基づいて、監査対象有効性を利害関係者に合理的保証すること」です。

貴方の言う「監査」に近いことは「セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ Permalink | 記事への反応(2) | 05:48

2018-06-23

websocketぐう有能

すごい、ネット切れたらエラー吐く

ネットに再接続したら勝手に再始動する

pubnubとはなんだったのか

2018-02-19

anond:20180219004346

ラズパイを常時起動させておいてラズパイブラウザからWebSocketか何かで繋いだらリアルタイムに出せるんじゃないか

別に画像化しなくても文字でいいじゃんと思うけど。

表示だけなら激安タブレットでもいいかもしれない。

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

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開発環境構築コース

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ファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

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)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

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)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (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, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

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チェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2016-08-23

cocos2d-xって作者は中国人じゃなかったっけ?

他にも色々ある気がする

中国国家自体はアレだが、レベル高い人は多い

宇宙関係とか

github漁ってても中国人面白い人は多い

韓国人ロシア人

nettyは韓国アップル社員だった気がする

ロシア人websocketjavaコードは参考になった

コンピュータ関係なく、ググってブログ自動翻訳で読みたくなる文はある

中国語フランス語ロシアドイツ韓国

INRIAでフランス語の文ってのもあった気がする

英語公用語戦勝国だし妥協で認めるが

Luaweb周り書いてた人は中国系アメリカ人だった気がする

中国系アメリカ人優れた人多いよね

2016-05-16

http://anond.hatelabo.jp/20160516194527

いや、おまえは、単に、マウスイベントを拾って、FRPストリームに流す、という接続部分、つまりFRP変数への書き込みについて、イチャモンつけてるんだよな?おまえにとっての「自動」の「同期」って何?

マウス位置と、変数自動的に同期してくれる

マウスイベントなりをラップしたFRPライブラリで、そのラップイベント宣言したら、ラップ変数自動的に流れるとかそういうこと言いたいんだろうが、そこからその変数関数なりで変換して行くのに、それがラップされてようがされてまいが、手間はまったく一緒だって理解してる?

あと、そういう既知のイベントなら、既知のマウスイベントなりを全部ラップしてやろうとおもえば、やれないことないだろうし、できるが、

既知ではない、FRPライブラリラップされてないIOイベントとかどうすんの?w あほなの?w

たとえば、HTTPイベントWebSocketイベント、全部FRPライブラリラップして、

>マウス位置と、変数自動的に同期してくれる

みたいにやるのか? 誰かが書いてくれるまで待つとか?w

あと、マウス位置から10オフセットさせたい、とかオプションも無数にありうるわな?

オプションサポートされてないラップだったらどうすんの?w やっぱアホなの?w

最初からネイティブイベントあったら、かんたんにできるだろ?ラップAPI参照せずにすむだろ?あほなの?w

あと、そういう原理的にアホな実装FRPライブラリかくあるべき!って誰が決めたの?アホなおまえが決めたの?w

2016-03-24

サーバスペックが低くても負荷の高いサイト運用したい

何を作りたいかというとマルチプレイヤーブラウザゲームが作りたいんだよね。

phpsymfonyを使ってみたけど重い。

俺の開発用のceleron 1コアのメモリ1GB環境では重すぎる。

isoファイルを10000個同時にダウンロードしてるぐらい重すぎる。

ページの読込みがなかなか完了しない。

こんなクソ重いフレームワークはそれなりのサーバスペックがないとパフォーマンスに影響が出すぎるので除外したい。

phpフレームワーク一般に言えるんだけどプロジェクト毎にプロジェクトルートなかにフレームワークのコアファイルを置くのがなんか嫌だ。

railsdjangoのように分離させてほしい。

nodejsシングルスレッドなので負荷の高いサイトで使うのは厳しそう。

pythonでもgolangでもwebsocketは使えるのでnodejsにこだわる必要もないしvert.xを使う選択肢もある。

日本ではvert.xの話題あんまり盛り上がってないよね。どこかの企業さんが実践で使いましたって記事を書いたら会社の知名度が上がると思う。

scala,golang,elixirこの3つの選択肢でいいのかな。

でも負荷の高いブラウザゲームやってる会社ってrailsとかphpだよね。

railsphpでも問題ないのかな。

redisをうまく活用しとけばあんまりそれ以外でボトルネックとなるようなことって無いのかな。

艦これやってるdmmとかは何使ってるんだろうね。

スクエニさんのオンラインドラクエもどうやってるんだろうね。

あと海外ブラウザゲームってほとんどがaws使ってるのでaws使えばいいのかな。

でも怖いよね高額料金を請求されたらさ。

金儲けの為にサイトを作らないとawsは使ってられない気がする。

初めのスタートダッシュは定額制のレンタルサーバクラウドでいいか。

2015-08-27

WebSocketでなんか作りたいんだけど、アイディアがない

からない人に説明すると、WebSocketっていうのはチャットとか対戦麻雀みたいな

リアルタイム性の高いWebサイトを作るための技術で、今僕はこれについて勉強しているんだけど、

勉強がてらに何か作ろうとしてもなかなか良いアイディアが思いつかないんだよね、

ただのチャットなんて今更作っても仕方ないし

面白そうな対戦ゲームでも便利サイトでもなんでもいいから作ってほしいものとかないっすかね

今お願いされたら暇にかこつけてなんでも作るよ!

2015-04-12

WebSocket使ったゲームとかサービスが作りたいんだけどなんかアイディア

Webとか詳しくない人に説明するとすると、WebSocketっていうのはチャットとか対戦麻雀みたいな

ユーザー同士がリアルタイムで繋がれるようなWebサイトを作るための技術で、

現在これを使ってなんかそこそこに流行りそうな新しいゲームとかサービスを作りたいと思ってるんだけど、

「今更リアルタイムチャットなんて作ってもなー」とか「対戦アクションとかは個人で作るのは現実的じゃないよなー」とか、

アイディアがないのに作りたい欲だけが燻ってる状態。

そこで、なんかみんなが「こういうチャット式のSNSあったら便利なのになー」とか

「こういう対戦ゲームあったら楽しそうだなー」みたいに思うサービスとかゲームアイディアがあったらちょっと教えてほしいと思ってる。

例えば、同じ配列?のフリーセル複数人でやってタイムを競いあうような既存ゲームを利用した対戦ゲームだったり、

特定の層向けのチャットサービスだったり、既にあるようなサービスゲームちょっとしたアイディアを付け加えたものだったり、

既にゲームとしては存在するけどブラウザゲームとしてはまだ存在しないゲームとか、そういうのでもなんでもいい。

WebSocketって無限の可能性があると思うんだ。

皆様の知恵を貸してください。

2014-12-31

1年の締めとして一人ハッカソンした

去年の今頃は「今年こそはすごいWebサービス作るぞ!!!!!!!!!!!」って意気込んでたのに

なんかもう今日が最終日。

ということでこの12月から何か作ろうと考えていて、丁度年末からということで作った。


Amazon購入金額分析

前にAmazonの購入金額合計を出すブックマークレット流行ったけど、それとほぼ同じ。

Amazonの今までの合計金額と、書籍とかPCとかカテゴリごとの合計金額出してグラフにする。

適当Twitter投稿して終わり。


年末だしTwitterで「2014年Kindle購入金額内訳は...でした」とか投稿すれば

みんなつられてアクセスするはず!宣伝しなくても勝手に大ブーム間違いなし!!!!!!!!

最終日に目標達成大勝利!!!!!!!!!


って思ってたけど

投稿してもだれもアクセスしてくれない。待っても待ってもアクセス0。

e?嘘でしょ???って思ったら

EC2セキュリティグループの設定変更忘れてた。

よーし今度こそアクセス過多間違いなし!!!!!


のはずだったけど今度はrobots.txt見に来るクソbotしかアクセスしてくれない。

虚しさ半端ない

というかTwitterURLつぶやくと即効でどこぞやのクローラー巡回してくるんですね。


構成自体クライアントサーバサイド共にjsEC2上でnode.js

D3.jsグラフ画像svgからどうにかしてpngにしないとTwitter投稿出来ないのが微妙に面倒だった

投稿時にクライアント側でbase64canvaspngにしても良かったけど

結局サーバサイドのphantomjsやらせた。

商品カテゴリ取得するためにはProduct Advertising API使うしかなくて

コレが毎秒1商品しか取得できない厳しい制限付き。

重複なしで600商品購入してたらなら10分かかる。

redis上にキャッシュしておいたりwebsocket適当に進捗伝えたりした。


今回得た経験値としては


あたり。


今年は残念ながら目標不達成だったけど、いい最終日の過ごし方になったと思う。

お疲れ様でした。

2014-10-11

アプリ屋がRailsを初めて触ってみて感じた事

Qiitaに書こうかと思ったけど、言いたいことも言えない、こんな世の中じゃ。

発想が古臭い

モバイルファーストAPIファースト文脈ハイブリッドWebをやってきた目からすると、サーバーサイドでHTMLを生成してページ遷移させるなどという90年代調のクラシカルな発想を基本に据えるフレームワークはとても斬新に思えました。HTMLゴリゴリ生成するなんてよほど特殊最適化をしようとするのでなければそもそも発想として出てこないです。それでいてDSLメタプログラミング等のテクニカル技法宝石のように鏤められている様はまるでエジプト時代骨董品を見るかのような趣がありました。turbolinkなどは、かつて表計算ソフトに出しゃばっていたイルカを思い起こさせる味があります。かつて慣れ親しんできたSPAが星のように遠い存在になりました。

モデルMVC

Web界隈の人々がモデルだとかアクティブレコードだとか"MVC"だとかを非常に具象的に話す様を見るにつけ、お前らどんだけPofEAA読み込んでるんだよと畏怖していた時期が僕にもありましたが、どうやら彼等はRailsクラスディレクトリという特定実装について話していただけだったようです。Modelという概念もこれだけ肥大化してしまったら、オリジナル概念で彼等と会話するのは諦めるべきかなと思いましたし、Railsの"MVC"をアンクォートして語るのはもはや害悪であるとすら感じました。

レールから外れる辛さ

Rails界隈の人がよく「Rails流儀」や「正しい"MVC"」というのを口角泡を飛ばし議論しているのを目にするのですが、おそらく外に広がる不条理で火傷を負って快適なRails世界に引き篭もった結果としての一種のストックホルム症候群なのだなと思いました。いまやAjaxとかWebsocketとかWebRTCとかを組み込もうとする至極真っ当な方法論がとてつもない高難度に見えてきます。設定よりも規約、というのも一つの方向性だと思いますが、ドメインサービスレイヤ名前空間を構築しようとしたりコードジェネレーションしようとしたりしただけで地獄のようなCircular Dependency罰を受けてしまったので、自分がとても間違った事をしているような気がしてしまいました。とはいえConcernsに特別名前役割を与えられても正直しんどいので、皆が皆libゴミを放り込んでいく様子にも納得がいきました。

レイヤ?何それおいしいの

RailsAPIサーバーとして使おうとするとまずビューが無くなってMとCだけになりますが、いわゆる"MVC"の文脈で育ったエンジニアがなぜ息を吸うようにFat ControllerやFat Modelを作ってしまうのかという事が良く分かりました。多くのRailsリファクタ手法と称されているものクラスを書くファイルを分割する事以上のものでは無いように思えたので、Rails使いを大きめなAPIサーバー案件に回すときセットポジションDDD青本を投げつける必要が有るなと思いました。

TDDやれんのか

ビューとコントローラを結合させた場合結合テストはCapybaraとかのBDDマークアップサイドとの干渉を恐れながら強い気持ちでメンテしていくしか無いのかなと思いました。おそらく脳に電極を埋め込んでいるか緑色のランプを見るだけでハイになれる特殊な人にしか生き抜けない闇が垣間見えました。コントローラを薄くしてサービスレイヤを挟めばその辺りもうまくいけそうな気がしましたが、ビューからヘルパーモデルがいくらでも透けて見えてしまうという状況では裏側の完全性に自信を持つ事は難しそうでした。

分業とか出来るんだろうか

ビューがRubyを叩いて永続化レイヤと直接コミュニケーション出来るというのはとても生産性が高いのだろうとは思いましたが、こうして出来たパーシャルやら何やらをデザイナーとどうやって共有するかを考えると頭痛が痛くなりました。おそらく適当に切り出して綺麗な空間をassets以下に構築した上でpublicにRPCのような窓口を備えたゴミを量産していくのかなと思いましたが、もっと綺麗な方法はあるのかもしれません。でもきっとRails案件に関われるデザイナーRubyバリバリ書けるに違いないはずなので、ここが問題になる事は無いのだろうなと思いました。

RESTとかきついです

RESTはとても美しいパラダイムではありますが、そもそもHTTPがさほど美しくないので歪んだ空間には目を背けるか勝手解釈を与える事で人は初めてRESTfulを名乗る事が出来るのだと思いますGETbodyを(公式には)持たないという事について美しい説明を与える事は出来ないでしょう。サーチAPIはどうしますか。ステータスコード足りなくないですか。401エラーはどうしますか。そしてRESTあくまリソース抽象化する美しい概念なので、アクション副作用については貧弱です。動詞が足りないですし、一般動詞に狭義の意味を与えてドキュメントするのは二度手間しか見えません。PUTには冪等性があるべきみたいなこだわりは家の猫にでも説教してればいいと思います。というわけで、REST的な設計拝借することはよしとしても、「○○はRESTでは無い故云々~」みたいな注文はやめて頂きたいものです。

そんなに嫌なら他に行けば

とか言わないで欲しいです。こういう時にセットでPHPをディスって悦に浸るのは知る限りRubiestとPythonistaと中学生だけです。それにこれはあくまサーバーサイド初心者感想なので、想像するにこれ系のFWは多かれ少なかれ似たような不満を抱えるものなのかなと思います。というわけで、おそらくこれから選択肢がある限りはRailsを使い続けると思います

だってRuby楽しいんだもの

2014-09-21

PerlからPythonに乗り換えようかと思う

steamとかゲームサービスをつなぐツールgithubにあってpythonjavascriptなどが多い

perl製がほぼない

これからwebで生きていくにはpyothon,javascript(node.js)なんだよなぁ

perlモジュールがそういう最新技術っぽい部分がおいつてなくてしょぼい

websocket,非同期,xmpp,rtmpとかperl資料が増えてほしいわ

Mojolicious使わないと無理らしい、めんどくせー

2014-05-23

WebSocketNode.jsが出た頃に流行ったような記憶をふと思い出す

結局どういう活用が出来たんだろうあれ

2014-05-21

プログラミング勉強したけどアイデアがないから誰かちょうだい

今年に入ってからプログラミング勉強し始めて、phpjavascriptpythonでとりあえず動くものを作れるようになった。各言語メジャーwebフレームワークも使えるようになったし、過去株価ダウンロードしてmysqlに突っ込んでta-libシストレのバックテストして遊んだり、ニコ動タグ検索結果のクローラー作って新着があればメールで知らせてくれたりするの作ったり、websocketためしてみたりbackbonejsで遊んだりもしてる。ニートから時間無限なのもあるけど、5か月弱でずいぶんできることが増えてきたなと思う。そろそろ何か作って公開してアフィで稼ぎたいなと思い始めた。でも何も出てこない。今月入ってからずっと考えてるのに作りたいものが浮かばない。いくら勉強してもアイデアがなければ無意味なんだと気付いた。誰かアイデアちょうだい

2012-06-23

キスで学ぶPush実装技術

彼女MacBookを並べてコーディング

ようやくRailsの開発を一人で出来るようになった彼女が、俺に突然質問を投げかけた。

「ねぇ、WebサービスPushってどうやって実装するの?」

「一般的には3つの方法がある。」と俺は答えた。

クールな順にWebSocket、次にコメット最後ポーリングだよ」

彼女は目を輝かせながら「それでそれで?!」と説明を求めてくる。

ポーリングは、一定時間ごと、たとえば3秒ごとにAjaxサーバリクエストを送って新着の情報が無いか問い合わせて、もし新着があれば処理を、なければスルーして次の問い合わせに備えるPush通知の実装だ。手軽に実装できる反面、新着がない多くの時間常にリクエストを送り続けることになるので無駄が多い。大規模なサービスで実装すれば、それだけでDDoSっぽくなっちゃう。また、リアルタイムも厳密には実現できなくて、MAXポーリング間隔分のラグが発生してしまう。小規模なサービスで、とりあえず実装するにはオススメかな。」

なるほどなるほど、と彼女は頷く。


コメットは?」

コメットポーリングを改良したもので、ブラウザからリクエストが送られてきた時点ではサーバはすぐにレスポンスを返さずに、処理中ってことでコネクションを張ったまま一定時間つんだ。それで、なにか新着があったタイミングで、昔送られてきてたリクエストレスポンスを返す。そうすると、新着があったタイミングレスポンスを返すタイミングになるので、レスポンスはほぼリアルタイムになる」

「なるほど!すごい!!!

「頭の良い実装だよね。Facebookの通知なんかはコメットだよ。ただ、コメットも万能じゃない。まず、レスポンスはいつまでも待てるものではなく、待たせすぎちゃうとタイムアウトなっちゃうんだ。だから一定時間ごとには何もなくても"進捗はなかったよ”というレスポンスを返してあげなきゃいけない。また、サーバコネクションを常に割り当てないといけないので、IOをブロックするようなサーバだとリソースを食い過ぎて耐えれ無くなっちゃうから大規模な運用には金がかかっちゃうんだ。所詮HTTPを使ったごまかしでしか無い。オーバーヘッドが大きいんだよ。」

「な、なるほどー」

少し話が小難しくなったためか、一生懸命理解しようと彼女が頑張っている。かわいい

「そこでWebSocketの登場だ。WebSocketは厳密には違うんだけど、HTML5関連の新しい技術で、ネトゲで使うTCP/IPセッションのようなコネクションをサーバ側と張ることができる技術なんだ。しかNATとかも超えてくれる便利な技術。これがあればリアルタイムWebの実装はすごく簡単になるんだけど、まだ新しい技術というのもあるし、対応してるサーバライブラリの不足や、プログラミングスタイルイベント駆動になるという変化もあって、まだまだ一般的にはなってない。対応してるブラウザ最近まで多くはなかったしね。やっとiPhoneでも使えるようになったし、スマフォWebでも普通に使えるようになってきた。これからが楽しみだね。」

「うーんと、うーんと、つまり

彼女今日得た知識のまとめに入ったようだ。一生懸命Web技術を学ぼうとしている健気な彼女に、僕は心がキュンとなった。

「そう、つまり…」

僕は彼女の頭に手を回し、クイっと自分の顔を近づた。

びっくりして目を見開いている彼女

そんな彼女に向かって、連続5回キスをした。


「チュッ、チュッ、チュッ、チュッ、チュッ、」

「これがポーリング。」


今度は自分の顔を少し傾け、舌を入れる深いキス


「チュポッ…」


彼女の頬は少しだけ赤く染まっていた。


「これがWebSocket、そして…」


最後に僕は彼女の顔を両手でホールドし、8秒くらいの長い、とても長いキスをした。

彼女の顔は真っ赤に染まり、目は少しだけトロンとしていた。


「これがコメット。わかったかな?」



彼女はとても恥ずかしそうに「はい…////」と返事をした。


「よし、じゃあコーディングに戻ろう。」



コーディングを始めた5分後、彼女がおもむろに呟いた。



「私、コメットがいいな。。。////」


東京は快晴、今日も絶好のペアプロ日和だ。

 
ログイン ユーザー登録
ようこそ ゲスト さん