「DOM」を含む日記 RSS

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

2018-06-14

YoutubeNG(フィルタ)も作った

anond:20180609124213

Youtubeフィルタ - Chrome ウェブストア

https://chrome.google.com/webstore/detail/youtube%E3%83%95%E3%82%A3%E3%83%AB%E3%82%BF/dfbfdjepofdfhdddfdggabjjndhiggji?hl=ja&gl=JP

github

https://github.com/lvnkae/youtube-filter

機能

使い方

基本設定

非表示チャンネルタイトルの設定は見たまま。セレクトボックスで項目選んで単語入力するのみ。

詳細設定

設定した単語ダブルクリックで詳細設定へ

 a. チャンネル固有の非表示タイトル設定

 b. チャンネルフィルタ適用方法指定

   正規表現ON/OFF

   完全一ON/OFF

   大文字/小文字区別なしON/OFF (正規化)

  をチェックボックスにて指定

 ※完全一致と正規表現排他

 ※両方設定した場合正規表現が勝ち完全一致は無視される

 例1)

  非表示チャンネルgam全一ON 大小区別なしON

   gam

   gaM

   gAm

   gAM

   Gam

   GaM

   GAm

   GAM

  の8パターンにヒット。

  gameやGambleやagamにはヒットしない。

  短すぎるチャンネル非表示に入れたい場合は完全一致で。

 例2)

  非表示チャンネル:sadamitsu[0-9]+ 正規表現ON

  末尾に数字を点けて増殖するタイプチャンネルをまとめて補足したい場合

タイトルフィルタの詳細設定

 単語の頭に <> を付けると正規表現ON

 例)

  <>宇佐美 *定満

   宇佐美定満

   宇佐美 定満

   宇佐美 定満

   宇佐美 定満

  等、姓名間にスペースが0個以上ある定満は全てヒット


[対象サイト]

URL概要ブロック対象
https://www.youtube.com/youtubeトップ動画/チャンネル/プレイリスト
https://www.youtube.com/watch動画ページ次の動画
https://www.youtube.com/feed/trending急上昇動画
https://www.youtube.com/channel or userチャンネルページ動画/チャンネル/プレリス
https://www.google.co.jpgoogle日本語検索youtube動画/チャンネル/プレイリスト
https://www.google.comgoogle英語検索同上

結果

文字列が流れるだけの動画不愉快変顔サムネを目にする機会が減った。

しかし多すぎて終わりが見えない。

動機

技術

youtubeDOMContentLoadedが発生するの初回だけでその後のページ遷移はelementの出し入れだけでやってるのですね。

DOM構築完了からすべてが始まる構成だったのでだいぶ手直しが必要でした。

2回め以降はURL変更をトリガーにしてるのですが、ホームからホーム選択などURL変わらないパターンもあり…。

フィルタ抜ける経路がまだあるかもしれません。

アイコンはてなフィルタに合わせて拾ってきたフリーのやつです。

アップデート予定

不具合修正くらいです

普段youtube見る時はfirefox使ってるからそっちでも作りたいなぁという気持ちだけはあります

何も調べてないのでゼロからですが。

スマホ対応google先生次第です。iOSandroidでのchrome拡張対応は全く予定がないそうなので。

スマホタブレットで動けば、幼子に見せたくない虚無動画チャンネルフィルタしたりできるんですけどね。

小学校上るくらいまではyoutubegoogleを塞ぐことでごまかし切れるでしょう)

2018-06-11

はてなNG代替品1.0.1を公開した

https://anond.hatelabo.jp/20180609124213

はてなフィルタ - Chrome ウェブストア

https://chrome.google.com/webstore/detail/%E3%81%AF%E3%81%A6%E3%81%AA%E3%83%95%E3%82%A3%E3%83%AB%E3%82%BF/nogcpadcgpkonifnaagfghkaiiojdcap

更新履歴 1.0.1

URL(ドメイン)ごとのタイトルフィルタ指定
タイトルフィルタ正規表現対応

例1)

 <>宇佐美 *定満

  宇佐美定満

  宇佐美 定満

  宇佐美  定満

  宇佐美   定満

 等、姓名間にスペースが0個以上ある定満にヒット

例2)

 <>ジョン[・|・]*万次郎

  ジョン万次郎

  ジョン・万次郎

  ジョン・万次郎

  ジョン・・万次郎

  ジョン・・・万次郎

 等、中黒(全角/半角)が0個以上ある万次郎にヒット

不具合修正

twitter.com/usami_sadamitsu

と設定した場合

twitter.com/Usami_Sadamitsu

がヒットしていなかったので正規化しました。

URL大文字/小文字区別はないので問題ないはずですが一部例外があることもわかっています

instagramとか。問題が多発するようなら使い分けられるようになんか考えましょう。

トラバで指摘頂いた不具合です。

anond:20180611052543

強制フィルタの判定にミスが有り、そこで弾かれてました。

headlines全体でなく、特定タイトルだけ非表示にしていた都合で。

アップデート予定

不具合修正くらいでしょうか。

ポップアップ閉じた時に自動フィルタかけ直す処理はあんまり需要なさそうなのでやめときます

せっかく$5払ったしほとんど使い回せるのでyoutubeフィルタも作り始めてまして

ほぼ実装はできたものの、フレーム内のDOM構築完了タイミングがうまく取れなくてハマッてるところです。

リロードすれば反映されるものの、あんまりリロードしてるとbot扱いで閉め出されたり。

機能としては

 非表示チャンネル指定動画チャンネルプレイリストを消す)

 タイトル非表示動画を消す)

という感じで先達のVideo Blockerと似たものです。

youtube内だけでなくgoogle検索結果からも除外できるようにしたところ唯一新しいところでしょうか。

googleは律儀に検索結果にチャンネルを表示してくれるので助かります

ニコ動などは本家ですら検索結果に投稿者情報さないのでフィルタも作れません。

2018-03-21

web開発技術がこんなにぐちゃぐちゃになってるの

すべての元凶DOMなんじゃねーの?

DOMやめようよ

2018-03-08

IE対応と言われたら金額倍くらいを提示したい

ウェブ系の仕事をしてるが気軽にIE対応とか言われることがあるが気軽に対応できるものではない


IEは最新の11ですらもう何年も前のもの

もう5年くらいは経つのだろうか

セキュリティアップデートはあるようだが、機能更新はない


ChromeFirefoxは1,2ヶ月程度に1回アップデートをしていて毎回様々な機能が追加されている

今ではもうIEとで使える機能の差はとても大きい


未だに昔ながらのjQueryのみという作りをしているのであれば大して気にすることではないがモダンブラウザターゲットに最新機能をどんどん導入している場合IE対応がかなり辛い

実際に倍くらいの時間がかかることもある


JavaScript コア部分であれば Babel で変換したりpolyfillである程度の対応はできるが DOM などブラウザ固有の WebAPI はそうではない

別途それぞれのpolyfillを集めて多少はどうにかできるものもあるがそれですら手間になる

そして対応できない部分はIEに合わせて作り直すことになる

中途半端に動いてバグや未実装があるもの特に大変だ


またBabel等を通さなくてはいけなくなるだけでも十分に時間がかかる

frameworktypescript, flowなどを使っていて事前コンパイル必要構成であるならばさほど影響はないだろうが、モダンブラウザのみをターゲットにしてるならそういったツールなしでも十分に書ける

事前処理が必要になるだけで開発にかかる時間やめんどくささは大きく変わる

さらにはそういったツールのわかりづらいバグを踏んだり、ブラウザのdevtoolsでのできることが制限されたりもする


devtools といえばIEだとデバッグすら快適に行えない

IEでのみ発生する問題が起きると特定難易度Chrome等の倍以上と言える


これだけの苦労がIE対応させるだけで出てくるのにオマケで対応してという気軽さで頼んでくる人が多い

最初IE11だけだったのにやっぱりユーザいるか10と9もというケースもある

私はフリーではないから値段を好きには決められないが、決められるなら

IE11→x2

IE10以上→x3

IE9以上→x4

くらいは取りたい


IEを倍にすると高いと言われそうだが、モダンブラウザのみでいいなら昔ながらの作り方より何倍も簡単に作れるわけだから Chrome のみならの割引でもいい

それくらいにIE対応はしたくない

IE対応するだけでかなり相場が高くなるというのが当たり前になってくれればいいのだけど

2018-01-02

プログラミング初心者の頃の気持ちを忘れた

プログラミング教えてと言われた。

自分PCサーバ立ててドメイン通してアクセスしてみて、HTMLCSSJavaScript概要を教えた。

http://hogehoge.comを叩くとぼくのローカルPC上のHTMLを見ることができるのだ。普通これは感激するはずだ。ヤツは少しも感動しなかったが。

タグのことを教えて、formタグ使ってみて、CSSを教えてセレクタの使い方教えて、なるべくDOMというワードは避けてJavaScriptイベントの追加のしかたを教えた。

で「あとは色んなタグ覚えるだけ」「CSSで色んな組み合わせやってレイアウトを楽しんでね」「あとは色んなイベント覚えるだけだから」みたいな感じ。色んなイベントを追加してもらった。

その後データベースの話をした。

「まずエクセルファイルからデータ取ってみよう(実際はCSV)」「あ、でもこれだと取りにくいし時間かかるね」「しかもこれだとデータ矛盾ちゃうしめんどくさいね」「そこでデータベースですよ」

って言って、sqlite3を教えた。エクセルで「これがインサート、これがデリート」って説明しながら、テーブルレコードSELECT, INSERT, UPDATE, DELETEを教えた。

ヤツは「なんでそんなわかりきったことをわざわざ文字入力するんだ」と憤慨していた。こっちが憤慨したい。

で、次はWebフレームワークの話。まずWebフレームワークを使ってもらう前に、URLを叩いたらアプリケーションが走ることを確認してもらう。僕は「すごいでしょ!!」って言う。

さっきのsqlite3とつなげてみて、データを取得して表示してみた。ここで僕、「すごいでしょ!感激するでしょ!!」って言う。「ふーーん」っていう反応。「データをそのまま表示してるんだからそんなの当たり前でしょ?」みたいな。うるせぇWebサービスなんて大体そんなもんだわという言葉を飲み込みつつ、ここまで3時間

ここで初めてサーバサイドの言語を教える。for-each文、関数までは順調。そしてクラスクラスは若干詰まっていたのでぼくはまず構造体について説明した。

構造体のことはよくわかるみたいだ。まず青赤緑で構成された色の構造もどきを作って、画面に色を出力した。ぼくがこの構造もどきで画面にマリオを描くとヤツは感動していた。

そしてぼくはクラスについて教えた。「この構造体に関数がついてたら便利なときもあるもんだ」って感じ。説明がめんどくさいので「このクラスっていうのが型だよ」とか言っておいた。

共通でいてほしいものもあるけど、共通でいてほしくないものもある」と言って、ぼくはキャラクタークラスを作ってマリオオブジェクトクッパオブジェクトを生成し、FFを究極に安っぽくした感じのフィールドで戦わせた。

ヤツは興奮しているようだった。マリオは負けた。ぼくは「人は目に見えるものしか興味が沸かないんだな」と達観した。

Webフレームワークに戻ってぼくはクラスを使ってViewModel、そしてControllerを教えた。彼はなんだかかなりよくわかった様子だった。ぼくは満足した。

そろそろ5時間になろうとしていたので、ぼくは「あとはデザインパターンと言って、プログラミングしていてよくあるパターンを集めたものがあるんだ」とか「アルゴリズムを知ると色々効率よく書けるよ」とか「非同期処理とかもあるし、とにかく色んなライブラリを試してみて」「他の言語とかも試してみて」とかそんなようなことを言った。

ぼくの仕事は終わった。あとはもうヤツは自分ひとりでなんでもできるだろう。ときどきぼくが質問に答えることもあるだろうけど、ヤツはサーバサイドに必要な大まかな知識を、こんなに短期間で得たのだ。ヤツは優れたエンジニアになるに違いない。ぼくはヤツの家をあとにした。お金ぐらい払ってほしいものだ。

翌日、ヤツから電話があった。

「ごめん、HTMLってなんだっけ……?ていうかファイルってどうやって作るんだっけ……」

ヤツは何も覚えてなかった。俺は発狂した。俺はいったい、何を教えていたんだ。

あと俺、数年勉強しててこれぐらいのことしかわかってなかったのか?そう思って、なんだか猛烈に虚しくなってしまった。

そしてぼくは、二度と人に教えないことを決意した。

2017-11-29

何者にもなれなかった

フロントエンドエンジニアにもデザイナーにもなれなかった。


HTML/CSSリファレンスなしで書けるし、WAI-ARIAを用いたアクセシブルなコーディングもできる。

CSS設計意識して保守性を大切にしたコードを書いているし、CSSアニメーションインタラクション操作できる。

SVGを一から書く方法やいくつものブレイクポイントを持ったページのコーディングスキルも身につけた。

Gitバージョン管理をしたり、モジュールバンドラータスクランナーscssコンパイルリントを通したりする能力も得た。

インプットが大好きで、毎日毎日様々なWebに関する知識を頭に詰め込んだ。


だけどJavaScriptは書けない。

JQueryコピペして簡単DOM操作を行うのが限界だった。


然しながら、昨今のフロントエンドエンジニアJavaScriptが書けて当たり前だし。

JSフレームワークWeb AssemblyWeb Componentsを使いこなして開発している。


サーバーサイドレンダリングが主流のこの時代、生のHTMLを書いているような人種は淘汰され、

数年後には食いつなぐことが厳しくなる未来しか見えない。

両者の間には旧石器時代現代程の格差を感じる。


デザイナーなら道はあるかと思い、UIデザインにも挑戦した。

バーティカルリズムや余白設計、配色理論意識した整ったレイアウトXDIllustratorで作れるようになった。

でも「整った・整然としたレイアウト」は作れても、その先に進むことはできなかった。


全ては自分怠惰性が招いた結果である

だけど、藻掻き続けても道が拓けない。

もうこの先、どのように歩み進めればいいのかもわからない。


助けて欲しい。

何者にもなれない自分は嫌だ。

2017-11-18

anond:20171118113822

主張が良く分からん

手元で計測してみたら、

阿部 寛のホームページDOM Content Loadが100ms、Load200msから300ms

dev.toがDOM Content Loadが200ms、Load6秒から7秒

だった。

阿部 寛のホームページアクセス5回(画像2枚)で終わっているのに対して、dev.toはトップに含まれコンテンツが多いので当たり前ではあるが。

2017-11-11

IT技術の禍根

今更言ってもしかたないけど、筋が悪い技術が広まって変えられなくていろいろ災難起こしてるのってあるよね。

Cが広まったのとか。

昔はコンパイラ技術が低くて、ああい言語効率よかったけど、すでに90年ごろには最適化技術が発達して「人間テクニックを使って最適かするより素直に書いてコンパイラ最適化させたほうが実行速度が速くなる」とか言われてたし、Macなんか開発言Pascalだったし。

OSやミドルウエアが(せめて)Pascalで書かれてる世界線だったら、いまのソフトウエア脆弱性は大幅に減ってたと思うわ。

あとマークアップ言語HTMLの上で動的型のJavascriptを動かして、フロントエンドプラットホームになってしまってるのとか。

一時期、ネットアクセススマホアプリから行うのが一般的になって、Webは衰退するって観測で、いい方向に向かってたけど、最近アプリ開発までDOMの上にReactとか積み上げてJSでやろうみたいな流れがあるし。

業務アプリなんかもPHPJSの人に、昔のクラサバのほうが開発効率よくてユーザーの使い勝手もよかったって言っても全く理解できないみたいだし、どんどん悪い方向に向かってるな。

2017-10-02

うそろそろHTMLJavaScriptは終わってほしい

今そういう話題ホットエントリに入っているけど、HTML/DOMを再発明っていうか、もうやめればいい。

モバイルブラウザでなくてアプリネットアクセスしてるからPCもそうすればいい。

HTML+Javascript+PHP現場仕事をしていて、偉い人に「昔のクラサバのほうが開発効率いいしユーザーも使い勝手良かったっすよ。今のWebアプリは開発効率悪いし使いにくいけど時代の流れだからしかたないっすね」みたいなことを言ったら、すごい感情的に「それは同意できない。どういうことか言ってみろ」とか食ってかかられたわ。

Web系の動的型の言語を使ってる人たちはガチに、自分らは開発効率いいと思ってるのがすごい。

一般に公開するようなものWebがいいだろうけど、業務系は普通にPCアプリで作ったほうがいいよな。

Webアプリは、インストールしなくていいか運用が楽って触れ込みだったけど、業務系のWebアプリなんて大概、ブラウザブラウザバージョンが固定で、バージョンアップのたびに動かなくなるとかそんなんばっかりだし。

2017-05-06

結局Vue.jsが最強だった

Reactは大規模なフロントエンド開発なら良いかもしれないけど何もかも大げさすぎだし概念理解するのが大変

Angular2は最初覚えなきゃいけないことが,TypeScriptからまりES2015、依存モジュール多数と始めるのがまず大変

Knockoutは古いブラウザサポートしなきゃいけないとき以外は使わない

jQueryでのDom操作は増えてくると辛みがあるリアクティブに書くのは大変

Vue.js使うと覚えること少ないわ、リアクティブに動くわVirtualDomなんて意識しないで良いわで最高すぎる

たいていこれで良いんじゃないか

2017-05-01

http://anond.hatelabo.jp/20170501085956

JavaScriptDOMを書き換えるためだけに存在している書捨てのクソ言語であって、サーバーサイドを書くために存在している言語でも、100万行からなるバベルの塔建設に耐えうる言語でもない。」

ほんとこれなんだよなあ。TypeScriptへ徐々に移行するしかないと思うけど、TypeScript廃れて来てるの?つい最近Googleが社内で公式採用したって読んだばかりだけど。

フロントエンドが嫌い

ウェブフロントエンド技術進歩と興亡の速度には目を見張るものがある。

browserifyが生まれGruntが生まれ、Gulpが生まれた。

そしてその全てが死んだ。

Webpack, Babel, Flow, 今栄えている技術だってそのうちに死ぬだろう。Reactだって例外ではない。

一部はもう死につつあるし、少し前にあれだけ持て囃されたTypeScriptも今や消えつつある。Coffeeは全エンジニアから嫌われた。

そんな万華鏡のように目まぐるしく変わる情勢に追い付かんと研鑽を続ける者等がいる。アーリーアダプター自称し最新技術のケツを追いかQiitaにクソを垂れ流す彼らこそ我らがイケイウェブフロントエンジニアである

最新技術に目を凝らし、やれ新たなこれイケてるだの古臭いあれはイケてないだのと宣いチュートリアル記事を量産する彼らであるが、彼らの存在は決して無駄ではなく、生まれたて技術知名度は彼らにより上げられる。

それはやがて大きな同調圧力空気となって流行った技術を押し流す。

さて、少し話は変わる。

かつては栄えた技術が滅び、消え去れども残るものはある。

書いてしまったソースコードと拭いきれない遺物と化したクソの塊だ。

ウェブサービスはただ作って終わりではない。その先にあるのは長く続くメンテナンスだ。

少し例を挙げたい。あるところにイケイウェブエンジニアあなたがいたとする。

ある日あなた上司からあるウェブサービスを作ってほしいと頼まれ、それを引き受けた。

さて、サービスを作るにあたりあなた使用する技術を選定する。イケイウェブエンジニアあなたはとても流行に敏感だ。勿論jQueryを使い泥臭くDOMを弄くり回すことなどあってはならない。

あなたESの最新規格に準拠したコードを書き、Flowtypeで静的型検査を行い、Angular4を使うことにした。

勿論そのままでブラウザ動作しないためWebpackとBabelを駆使してトランスパイルする。

数週間後、めでたくサービスは完成した。

さて、問題はここからである

一年後のある日、あなた上司に呼び出された。

曰く、そのサービスに新たな機能を追加して欲しいのだという。

あなた脳内で試算する。時間と手間は掛かるが可能だと判断したところで、はい、と答え一年ぶりにプロジェクトソースコードを開いた。

ここであなたはあるものを目撃、頭を抱えることになるだろう。

それは何か。陳腐化した一年前のトレンド技術の塊である

一年後の未来世界では Webpack2 など既に新しく現れた技術に叩き潰され醜く断末魔の鳴き声を上げる死に瀕した哀れなヒキガエルの如き存在だった。もちろんAngular4はもう誰も使おうとはしない。

もちろんあなたもそれらを過去存在へと葬り去った新技術に首ったけだ。

さて、ここであなたがとれる戦略は次の2つだ。

一方は、クソだクソだと悪態を付きながらもはやメンテナンスもされていないクソプラグインの体系化されていないクソドキュメントとにらめっこをしながら古臭いクソの塊と付き合っていくこと。

もう一方は、新たに聳え立った最新のクソの塊に無限移植を続けることだ。

前者を選んだあなた時間が経つごとにまともな情報を得られなくなり、やがては身動きが取れなくなった段階でようやく最新技術への移植を考えはじめる。しかし、その頃には膨れ上がった旧時代のクソはそんなことを容易に許してはくれやしない。

さて、後者を選んだあなたを待っているのは無間地獄の如き最新技術の濁流だ。それに揉まれながら一年ごとに、古臭きは悪だと声高に叫びながら無限移植作業を行うことになるだろう。

どちらにせよ待っているのはクソの如き地獄である

しかし、どれほど技術が移り変われど変わらないものもある。

あなたがクソと罵り選択肢からも除外されたjQueryである一年後の未来であってもjQueryはそこにあった。もちろんクソと野次られながら。

クソレガシーこと枯れた技術の利点はそこにある。

勿論jQueryを使った品質の低いクソコードはクソだ。

けれども一年前のあなたjQueryを使ったコードが読めるし、今のあなたももちろん読める。一年後のあなたは疎か、三年後のあなたの後継ですらも (泥臭くDOMを弄るコード閉口しながらではあるが) やはりあなたの書いたコードを読めるだろう。

そもそもからしてウェブフロント倒錯している。

JavaScriptDOMを書き換えるためだけに存在している書捨てのクソ言語であって、サーバーサイドを書くために存在している言語でも、100万行からなるバベルの塔建設に耐えうる言語でもない。

前提からして倒錯したクソウェブフロントは一度無に還るべきだし、私はそんなクソウェブフロント界隈が大嫌いだ。

この意味不明なクソポエムも憎むべきクソの一端である

2017-04-21

ネタバレ注意】キングダム王翦って…

王 = king

翦 = 切りそろえる → 支配する = dom

実は主人公なんじゃね?

最近活躍だし、ここから秦が中華統一するまで神がかった快進撃だしな。

一方、李信なんて蒙恬と一緒に楚に攻め込んで返り討ちに遭って、逆に秦を滅亡の危機に陥れるんだぜ。

(その後王翦が楚を攻略

2017-04-12

良いこと

最近嫌なニュースばかりなので、良かったこと楽しかったことを挙げてみる。

梅干し純久しぶりに食べた。うめぇ

エビフライを久しぶりに食べた。うめぇ

・毛ガニをもらう。カニそんなに好きじゃなかったけど、歳を取ると共にどんどん美味しく感じるようになってきた

・オオスカシバを見た。かわいい

・近所の野良猫かわいい

・遅くまで残業していたら、酒を飲んで酔っ払ってきた社長がやって来て、チロルチョコをくれた。殺意を覚える。

・近所の古いマンションが、角度によってジブリっぽいことに気づく

・凄い強そうなおっぱいを見た

アニメ月がきれいを見た。おっさんのくせにドキドキした。

・久しぶりにヨコハマ買い出し紀行を読み返す。最高

上司がVBAに挑戦していた。Dom i as longになっていた。

・夢の中でサーフィンをした。凄いモテた。目が覚めて泣いた

・毎朝髪の毛が自分から卒業していくので、窓の外へ送り出している。元気でやれよ

以上

2017-04-11

オライリーに出てくるフレンズ

参考:http://www.oreilly.com/animals.csp

2016-12-30

2020年に振り返る2016年Web開発

後輩「先輩、このシステム僕が引き継ぐ事になりました。よろしくお願いします」

先輩「そうかそうか、やっと肩の荷がおりるな」

後輩「これ2016年に作ったシステムなんですよね。僕その頃まだ入社してないんで、最初の方から教えてもらっていいですか」

先輩「よしわかった。環境構築から順を追って説明する」

先輩「まずはじめにnode.jsを入れる」

後輩「あ〜昔流行ったサーバーサイドでJavascript使えるやつですよね。このシステムnodeで動いてたんですね」

先輩「いや、nodeは使ってない」

後輩「え?」

先輩「nodeに付属しているnpmというパッケージマネージャーを使ってる」

後輩「なんでまたそんな回りくどいことを・・・

先輩「当時はnpmが一番メジャーだったんだよ。今主流のN3(N3 is Not Npm)はまだ無かったしな」

先輩「よしnode入れたな。じゃあnpm installだ」

後輩「えい!・・・先輩、なんかエラー出ました・・・

先輩「printFizzBuzzというパッケージが404みたいだな」

後輩「何に使うんですかそのライブラリ

先輩「知らん。依存してるライブラリ依存してるライブラリ依存してるライブラリかなんかだろう」

後輩「バタフライエフェクトってやつですね」

先輩「思い出した。これは昔話題になったやつだ。printFizzBuzzは何かの特許抵触していて非公開になったらしい。

  npm installで落とすのは諦めて、ローカルに残ってるやつで何とかするしかないな」

後輩「それ使って大丈夫ですかね。法的に」

先輩「仕方ないだろ」

先輩「ようやく諸々揃ってBabelやReactやWebpackを使えるようになった」

後輩「それ何ですか?」

先輩「まずBabelだが、これはES2015をES5にコンパイルするツールだ」

後輩「え、なんでダウングレードするんですか?」

先輩「古いブラウザで当時の最新機能を使うにはこうする必要があったんだ」

後輩「なるほど。ではReactは?」

先輩「これは今で言うWeb Componentsみたいなものだな。あと仮想DOM

後輩「Babelじゃダメだったんですか?」

先輩「ダメだったんだよ」

後輩「で、最後Webpackは?」

先輩「リソースモジュール管理して最適化するツールだ」

後輩「最適化サーバー仕事じゃないんですか?」

先輩「当時はモジュールが標準対応してなかったり、http/2もあまり普及してなくてサーバー馬鹿だったんだよ」

後輩「へ〜大変ですね」

後輩「いつの間にかこんな時間ですね。今日まだ1行もコード書いてないですよ」

先輩「一度準備してしまえば、そこから先が楽になるんだ」

後輩「今となっては余計な苦労が増えてるような気がしますけどね〜」

先輩「当時はこれが最善の選択だったんだよ」

後輩「そうなんですね」

2016-10-06

html3d対応したとしたらどうなるんだろうね?

結局 js 書かなきゃいけないとかになるかな?

cssdom だけで表現できるようになったら意外と楽しそうな気がする

2016-09-14

Yahooショッピングメール

お荷物の発送手続き完了のお知らせ、ご確認商品出荷完了の三点のメール

それぞれWin32/GenKryptik.DOMの亜種を添えて。

zaq.ne.jpベトナムハノイと、dion.co.jp

ついに国内踏み台からですね。

2016-05-29

http://anond.hatelabo.jp/20160524094615

状態渡しとか関係なくDOMから長いだけじゃん。っていうか

そう書いてあるのに改ざんして引用するkenokabeさすがだな。

http://anond.hatelabo.jp/20160524094615

岡部氏が故意理解できなくて引用しなかったDOMどころか、

「静的型」という用語も知らないことが発覚。これはすごい

2016-05-25

http://anond.hatelabo.jp/20160521234423

というかですね、そもそもVをロジックの中にベタ書きしちゃうの嫌なんですよね。

MVCモデルというのは、オブジェクト指向の発想。

DOMというのは、そもそもDocumentObjectModelでオブジェクト指向

JQueryはそのVを関数型的に扱おうとした拡張

Reactは、これらすべてを一旦ご破産にした。

MVCのVだ、と公式サイト説明されているが、これは半ば皮肉であって、本当はVは存在しない。Cももちろん存在しない。M、モデルロジックしか存在しない。モデル一元論、それがReact。

VであるDOM消滅し、JavaScriptの `x` や `a` などその他の変数と同列のファーストクラス仮想DOMとしてしか存在していない。

まり仮想Vは、M(モデル)内で関数型の文脈自由自在演算できるわけ。

コード最後マウントしておけば、仮想Vは自動的に、実VのDOMとして描画される。

M=ロジックの外に、あらかじめわざわざ決め打ちしたVを用意するよりも、M=ロジックに一元化するほうが賢い。それがReactであり、JSX

http://anond.hatelabo.jp/20160521163144

ReactはJavaScript界隈の関数型プログラミング化の潮流で登場。

最近炎上している別の方面で、特にFRPと組み合わせると圧倒的なパワーを発揮すると一部では実例とともに指摘されている。

http://kenokabe-techwriting.blogspot.jp/2016/05/frptimeenginereactjsocaml.html

Reactは、関数型あるいは宣言型に書けるように用意されている。DOMは、「仮想DOM」として、JSJSX)上の「値」として統合されていて、それは自由に変形し、組み合わされ、リアクティブJSX上の仮想DOMからDOMリアルタイムマッピングされ描写される。

JQueryも、実DOM関数型で操作できるような拡張ではあるが、Reactのように宣言的に書くことは不可能

coffee scriptは、ES6登場までの過渡期の橋渡しみたいなもので、登場したのも消えたのも合理性がある。

React.jsは、関数型の潮流で登場したものでこれも合理性があり、この延長線上でさらに洗練された代替物が登場する可能性はあれど、このパラダイムが消えることはない。

2016-05-24

http://anond.hatelabo.jp/20160524145224

よーわからんw 岡部氏は、自作ライブラリHPで、

FRP純粋理想とする関数型+時間で変化するストリームを値にマップして扱うリアクティブプログラミングの組み合わせ

まり関数型の拡張っていうなら誰も反対無いと思うんだけど。

FRPライブラリサブタイトルに、 library that provides first class reactive value 'over time' と書かれている、これ拡張じゃないのか?

https://www.npmjs.com/package/timeengine

HaskellのIOモナドみたいな別の抽象化DISりつつ、FRPこそ正しい関数型みたいに言うから荒れるんじゃないの?

IOモナドDisってるのかどうかまでは知らない。しかし、すでに出たサンプルからFRPの効力がまざまざと見せつけられている。

荒れるのは自由だけど、両方正しいとかそういうのじゃなくて、間違っている電波だみたいな叩きしかなくて、要するに感情論で反対派は反発しているだけでOK?

あるよ。

関数がどのパラメータ依存して、何を結果として返すのか明確になる。

グローバルな値を参照したり書き換えたりしてたら、関数の中身読まないとわからなくなる。

短いプログラムならそれでもいいけどね。

別の誰かが書いてたように、上位スコープ内に定義されてるDOMでも、数学ライブラリでもなんでも、引数関数に渡すのか?

グローバルな値を参照したり書き換えたりして

いやだから、定数なんだから書き換わらないんだよ、FRPストリームconst 定数なんだから

関数型のわかりやす説明であって、住井派に反対してるとか、岡部路線とかじゃないよね、と。

オブジェクト指向と対比して考え方をまず学ぶって岡部路線、住井グループはそれを目の敵にしていて集団的攻撃している様をみたプログラミングコミュニティは逃げ、その後、不毛な大地のみが残った。

http://anond.hatelabo.jp/20160524143022

そうなんだよね・・そもそもconstの定数をわざわざ、関数引数にすべき必要があるのか??という根本的な問題がある。

たとえばGlobalにアクセスできて当然のDOM要素とか、Piとか、スコープ可視の定数は引数にしないよね?

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん