  |
はてなキーワード: DOMとは
ITベンダの俺の職場のパソコンがとにかく低スペックなのである。予算がないだのなんだのいいながらちっとも買ってくれないのである。2018年も半分以上過ぎているのに、メモリは4GBしか乗ってないし、画面も狭いノートパソコンが、ただあるだけである。
会社は働き方改革を推進している。定時で帰らなければならない。作業を効率化して、生産性を上げて。もちろん、会議を削ったり、タスクの優先度をつけたりして生産量を上げる努力はしている。でも開発効率はなんともならない。だってパソコンが重いんだもの。でもパソコンは買ってくれない。
とかくフリーズするのである。rails s でデーモンを立ち上げてChromeでみたいし、インスペクタでDOMも解析したいんだけど、そうするとフリーズするのである。もちろんRuby Mineなんてない。買ってもらえないし、あっても動かないからである。
新技術も使ってみたいのである。できればdockerなんかも使ってみたい。CI組んでみたい。でもパソコンが耐えないのである。
同時にスマホアプリ開発は死ぬのである。Android Studioを立ち上げると、パソコンが。とまるのである。
動かない場合はどうするか。
ひたすら「待つ」のである。
ブラウザがとまると、要するにスワッピングしてるんだけど、そうすると数分待たされる。もちろんSSDなどでなくHDDだ。スワッピングならまだいい。パソコンがフリーズしていたら、さらに待たされる。そもそも画面に反応がないので、スワッピングしてるんだかフリーズしてるんだかわからない。とりあえず再起動するしか方法がない。
なぜパソコン、ひいてはエンジニアの環境に投資しないのだろうか。環境が整えば、1日に1時間は効率化できる。ざっと30万の投資としても、2ヶ月程度で損益分岐点に達する。精神面でいってもエンジニアは安心・満足するし、そうすると意欲的な開発ができる。使える技術の幅が広がることは管理職にとってもメリットがあるはずだ。こんなに簡単な判断をなぜ会社はしないんだろう。
我々はどうも苦労がどこかで報われると思っているようだ。これだけ苦労しているのだから、いずれなにかよいことがある。今苦労しておけば、明るい未来が待っている。贅沢しないのだ、敵だから。欲しがってはいけない、勝つまでは。
富豪的環境でなく貧者な環境で開発していると、最新環境でなくレガシー環境で開発していると、IDEでなくEmacsで開発していると、そのうちその努力は報われると思ってしまうのである。
競合は常にいろんな最新兵器を使っている。鎖国している俺の職場からは何も聞こえない。聞こえないフリをしている。攻め入られても竹槍でやりかえせばいいのだ。だから、今のこの環境で頑張る意味はあると。
https://anond.hatelabo.jp/20180609124213
不具合修正だけでアップデートするの嫌だったのでなにかないかと思っていたところ
自分がスターつけたブコメが一目でわかるよう色や印がつくと、自分が支持した意見や参考になった意見が一覧にできて、考えや参照情報が整理しやすくなると思う。あと、自己を客観視しやすい。賛同してくれる人いる？
それをそのまま実装した形です。
どこにマークするかはいろいろ試した結果、AddStarボタンの枠線に落ち着きました。目に付きやすいし同じブコメに意図せず複数回★付けるのを防ぐ意味で。色は黄色や青だと馴染んでしまうので赤です。
★自体にもマークするのはちょっとやりすぎかなぁと。うっかりデマにつられてしまって★消したいけど100個も200個も★付いてて探すの大変！ということはあるかもしれませんが。レアケースでしょう。
ちなみにinner_starというのは「★17★」みたいなやつです。HatenaStar.jsでそのように命名されてます。
使っているうちにこまごま見つかった不具合をちまちまと潰し、潰してはエンバグして、また潰し、とやってなんとか一段落しました。
不具合5は特に酷く、★フィルタ作成時に「色情報が入っていてそのままでは使えない」からこそaltでなくhrefから取得することにしたにもかかわらず、それをすっかり忘れてエンバグしてしまうのだから情けないこと頻り。忘れるのはわかりきっているので通常は当たり前でない処理にはコメントを入れて未来の自分に注意を促すわけです。今回は忘れることを忘れてしまってコメントを入れなかったのが敗因ですね。
mobile版含め落ち着いたので次は環境固有の不具合…と言いたいところですが報告のあったアドオンの組み合わせバグはどうしようもないかもしれないなと正直思ってます。まだ何も調べてませんが。うまく直れば「同一ユーザーの★をまとめる機能」と合わせて1.1.0をリリースしたい気持ち。お気持ちの表明。
https://github.com/lvnkae/youtube-filter
非表示チャンネルとタイトルの設定は見たまま。セレクトボックスで項目選んで単語を入力するのみ。
例1)
の8パターンにヒット。
例2)
例)
<>宇佐美 *定満
宇佐美定満
宇佐美 定満
宇佐美 定満
宇佐美 定満
等、姓名間にスペースが0個以上ある定満は全てヒット
文字列が流れるだけの動画や不愉快な変顔サムネを目にする機会が減った。
しかし多すぎて終わりが見えない。
youtubeはDOMContentLoadedが発生するの初回だけでその後のページ遷移はelementの出し入れだけでやってるのですね。
DOM構築完了からすべてが始まる構成だったのでだいぶ手直しが必要でした。
2回め以降はURL変更をトリガーにしてるのですが、ホームからホーム選択などURL変わらないパターンもあり…。
フィルタ抜ける経路がまだあるかもしれません。
アイコンははてなフィルタに合わせて拾ってきたフリーのやつです。
普段youtube見る時はfirefox使ってるからそっちでも作りたいなぁという気持ちだけはあります。
スマホ対応はgoogle先生次第です。iOSやandroidでのchrome拡張対応は全く予定がないそうなので。
スマホやタブレットで動けば、幼子に見せたくない虚無動画チャンネルをフィルタしたりできるんですけどね。
https://anond.hatelabo.jp/20180609124213
例1)
<>宇佐美 *定満
宇佐美定満
宇佐美 定満
宇佐美 定満
宇佐美 定満
等、姓名間にスペースが0個以上ある定満にヒット
例2)
<>ジョン[･|・]*万次郎
ジョン･万次郎
ジョン・万次郎
ジョン・・万次郎
ジョン･･･万次郎
等、中黒(全角/半角)が0個以上ある万次郎にヒット
twitter.com/usami_sadamitsu
と設定した場合に
twitter.com/Usami_Sadamitsu
ポップアップ閉じた時に自動でフィルタかけ直す処理はあんまり需要なさそうなのでやめときます。
せっかく$5払ったしほとんど使い回せるのでyoutubeフィルタも作り始めてまして
ほぼ実装はできたものの、フレーム内のDOM構築完了タイミングがうまく取れなくてハマッてるところです。
リロードすれば反映されるものの、あんまりリロードしてるとbot扱いで閉め出されたり。
機能としては
という感じで先達のVideo Blockerと似たものです。
youtube内だけでなくgoogle検索結果からも除外できるようにしたところ唯一新しいところでしょうか。
googleは律儀に検索結果にチャンネルを表示してくれるので助かります。
ウェブ系の仕事をしてるが気軽にIE対応とか言われることがあるが気軽に対応できるものではない
もう5年くらいは経つのだろうか
ChromeやFirefoxは1,2ヶ月程度に1回アップデートをしていて毎回様々な機能が追加されている
未だに昔ながらのjQueryのみという作りをしているのであれば大して気にすることではないがモダンブラウザをターゲットに最新機能をどんどん導入している場合はIE対応がかなり辛い
実際に倍くらいの時間がかかることもある
JavaScript コア部分であれば Babel で変換したりpolyfillである程度の対応はできるが DOM などブラウザ固有の WebAPI はそうではない
別途それぞれのpolyfillを集めて多少はどうにかできるものもあるがそれですら手間になる
またBabel等を通さなくてはいけなくなるだけでも十分に時間がかかる
frameworkやtypescript, flowなどを使っていて事前コンパイルが必要な構成であるならばさほど影響はないだろうが、モダンブラウザのみをターゲットにしてるならそういったツールなしでも十分に書ける
事前処理が必要になるだけで開発にかかる時間やめんどくささは大きく変わる
さらにはそういったツールのわかりづらいバグを踏んだり、ブラウザのdevtoolsでのできることが制限されたりもする
devtools といえばIEだとデバッグすら快適に行えない
IEでのみ発生する問題が起きると特定の難易度がChrome等の倍以上と言える
これだけの苦労がIEに対応させるだけで出てくるのにオマケで対応してという気軽さで頼んでくる人が多い
最初はIE11だけだったのにやっぱりユーザにいるから10と9もというケースもある
私はフリーではないから値段を好きには決められないが、決められるなら
IE9以上→x4
くらいは取りたい
IEを倍にすると高いと言われそうだが、モダンブラウザのみでいいなら昔ながらの作り方より何倍も簡単に作れるわけだから Chrome のみならの割引でもいい
HTML/CSSはリファレンスなしで書けるし、WAI-ARIAを用いたアクセシブルなコーディングもできる。
CSS設計を意識して保守性を大切にしたコードを書いているし、CSSアニメーションでインタラクションも操作できる。
SVGを一から書く方法やいくつものブレイクポイントを持ったページのコーディングスキルも身につけた。
Gitでバージョン管理をしたり、モジュールバンドラーやタスクランナーでscssのコンパイルやリントを通したりする能力も得た。
インプットが大好きで、毎日毎日様々なWebに関する知識を頭に詰め込んだ。
だけどJavaScriptは書けない。
JQueryをコピペして簡単なDOM操作を行うのが限界だった。
然しながら、昨今のフロントエンドエンジニアはJavaScriptが書けて当たり前だし、
各種JSフレームワークやWeb Assembly、Web Componentsを使いこなして開発している。
SSG, SSRが主流のこの時代、生のHTMLを書いているような人種は淘汰され、
バーティカルリズムや余白設計、配色理論を意識した整ったレイアウトをXDやIllustratorで作れるようになった。
でも「整った・整然としたレイアウト」は作れても、その先に進むことはできなかった。
だけど、藻掻き続けても道が拓けない。
もうこの先、どのように歩み進めればいいのかもわからない。
助けて欲しい。
何者にもなれない自分は嫌だ。
今更言ってもしかたないけど、筋が悪い技術が広まって変えられなくていろいろ災難起こしてるのってあるよね。
Cが広まったのとか。
昔はコンパイラ技術が低くて、ああいう言語が効率よかったけど、すでに90年ごろには最適化技術が発達して「人間がテクニックを使って最適かするより素直に書いてコンパイラに最適化させたほうが実行速度が速くなる」とか言われてたし、Macなんか開発言語Pascalだったし。
OSやミドルウエアが(せめて)Pascalで書かれてる世界線だったら、いまのソフトウエアの脆弱性は大幅に減ってたと思うわ。
あとマークアップ言語のHTMLの上で動的型のJavascriptを動かして、フロントエンドのプラットホームになってしまってるのとか。
一時期、ネットアクセスはスマホアプリから行うのが一般的になって、Webは衰退するって観測で、いい方向に向かってたけど、最近はアプリ開発までDOMの上にReactとか積み上げてJSでやろうみたいな流れがあるし。
業務アプリなんかもPHPやJSの人に、昔のクラサバのほうが開発効率よくてユーザーの使い勝手もよかったって言っても全く理解できないみたいだし、どんどん悪い方向に向かってるな。
今そういう話題がホットエントリに入っているけど、HTML/DOMを再発明っていうか、もうやめればいい。
モバイルはブラウザでなくてアプリでネットにアクセスしてるから、PCもそうすればいい。
HTML+Javascript+PHPの現場で仕事をしていて、偉い人に「昔のクラサバのほうが開発効率いいしユーザーも使い勝手良かったっすよ。今のWebアプリは開発効率悪いし使いにくいけど時代の流れだからしかたないっすね」みたいなことを言ったら、すごい感情的に「それは同意できない。どういうことか言ってみろ」とか食ってかかられたわ。
Web系の動的型の言語を使ってる人たちはガチに、自分らは開発効率いいと思ってるのがすごい。
一般に公開するようなものはWebがいいだろうけど、業務系は普通にPCアプリで作ったほうがいいよな。
Webアプリは、インストールしなくていいから運用が楽って触れ込みだったけど、業務系のWebアプリなんて大概、ブラウザやブラウザのバージョンが固定で、バージョンアップのたびに動かなくなるとかそんなんばっかりだし。
「JavaScriptはDOMを書き換えるためだけに存在している書捨てのクソ言語であって、サーバーサイドを書くために存在している言語でも、100万行からなるバベルの塔の建設に耐えうる言語でもない。」
ほんとこれなんだよなあ。TypeScriptへ徐々に移行するしかないと思うけど、TypeScript廃れて来てるの？つい最近Googleが社内で公式採用したって読んだばかりだけど。
ウェブフロントエンドの技術の進歩と興亡の速度には目を見張るものがある。
browserifyが生まれ、Gruntが生まれ、Gulpが生まれた。
そしてその全てが死んだ。
Webpack, Babel, Flow, 今栄えている技術だってそのうちに死ぬだろう。Reactだって例外ではない。
一部はもう死につつあるし、少し前にあれだけ持て囃されたTypeScriptも今や消えつつある。Coffeeは全エンジニアから嫌われた。
そんな万華鏡のように目まぐるしく変わる情勢に追い付かんと研鑽を続ける者等がいる。アーリーアダプターを自称し最新技術のケツを追いかけQiitaにクソを垂れ流す彼らこそ我らがイケイケウェブフロントエンジニアである。
最新技術に目を凝らし、やれ新たなこれイケてるだの古臭いあれはイケてないだのと宣いチュートリアル記事を量産する彼らであるが、彼らの存在は決して無駄ではなく、生まれたての技術の知名度は彼らにより上げられる。
それはやがて大きな同調圧力的空気となって流行った技術を押し流す。
さて、少し話は変わる。
書いてしまったソースコードと拭いきれない遺物と化したクソの塊だ。
ウェブサービスはただ作って終わりではない。その先にあるのは長く続くメンテナンスだ。
少し例を挙げたい。あるところにイケイケウェブエンジニアのあなたがいたとする。
ある日あなたは上司からあるウェブサービスを作ってほしいと頼まれ、それを引き受けた。
さて、サービスを作るにあたりあなたは使用する技術を選定する。イケイケウェブエンジニアのあなたはとても流行に敏感だ。勿論jQueryを使い泥臭くDOMを弄くり回すことなどあってはならない。
あなたはESの最新規格に準拠したコードを書き、Flowtypeで静的型検査を行い、Angular4を使うことにした。
勿論そのままではブラウザで動作しないためWebpackとBabelを駆使してトランスパイルする。
数週間後、めでたくサービスは完成した。
あなたは脳内で試算する。時間と手間は掛かるが可能だと判断したところで、はい、と答え一年ぶりにプロジェクトのソースコードを開いた。
一年後の未来の世界では Webpack2 など既に新しく現れた技術に叩き潰され醜く断末魔の鳴き声を上げる死に瀕した哀れなヒキガエルの如き存在だった。もちろんAngular4はもう誰も使おうとはしない。
もちろんあなたもそれらを過去の存在へと葬り去った新技術に首ったけだ。
一方は、クソだクソだと悪態を付きながらもはやメンテナンスもされていないクソプラグインの体系化されていないクソドキュメントとにらめっこをしながら古臭いクソの塊と付き合っていくこと。
もう一方は、新たに聳え立った最新のクソの塊に無限に移植を続けることだ。
前者を選んだあなたは時間が経つごとにまともな情報を得られなくなり、やがては身動きが取れなくなった段階でようやく最新技術への移植を考えはじめる。しかし、その頃には膨れ上がった旧時代のクソはそんなことを容易に許してはくれやしない。
さて、後者を選んだあなたを待っているのは無間地獄の如き最新技術の濁流だ。それに揉まれながら一年ごとに、古臭きは悪だと声高に叫びながら無限の移植作業を行うことになるだろう。
あなたがクソと罵り選択肢からも除外されたjQueryである。一年後の未来であってもjQueryはそこにあった。もちろんクソと野次られながら。
けれども一年前のあなたはjQueryを使ったコードが読めるし、今のあなたももちろん読める。一年後のあなたは疎か、三年後のあなたの後継ですらも (泥臭くDOMを弄るコードに閉口しながらではあるが) やはりあなたの書いたコードを読めるだろう。
JavaScriptはDOMを書き換えるためだけに存在している書捨てのクソ言語であって、サーバーサイドを書くために存在している言語でも、100万行からなるバベルの塔の建設に耐えうる言語でもない。
参考：http://www.oreilly.com/animals.csp
後輩「先輩、このシステム僕が引き継ぐ事になりました。よろしくお願いします」
先輩「そうかそうか、やっと肩の荷がおりるな」
後輩「これ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じゃダメだったんですか？」
先輩「ダメだったんだよ」
先輩「当時はモジュールが標準対応してなかったり、http/2もあまり普及してなくてサーバーが馬鹿だったんだよ」
後輩「へ〜大変ですね」
〜
後輩「いつの間にかこんな時間ですね。今日まだ1行もコード書いてないですよ」
後輩「今となっては余計な苦労が増えてるような気がしますけどね〜」
先輩「当時はこれが最善の選択だったんだよ」
後輩「そうなんですね」
DOMというのは、そもそもDocumentObjectModelでオブジェクト指向。
Reactは、これらすべてを一旦ご破産にした。
MVCのVだ、と公式サイトに説明されているが、これは半ば皮肉であって、本当はVは存在しない。Cももちろん存在しない。M、モデル＝ロジックしか存在しない。モデル一元論、それがReact。
VであるDOMは消滅し、JavaScriptの `x` や `a` などその他の変数と同列のファーストクラスの仮想DOMとしてしか存在していない。
つまり、仮想Vは、M（モデル）内で関数型の文脈で自由自在に演算できるわけ。
コードの最後でマウントしておけば、仮想Vは自動的に、実VのDOMとして描画される。
M＝ロジックの外に、あらかじめわざわざ決め打ちしたVを用意するよりも、M＝ロジックに一元化するほうが賢い。それがReactであり、JSX。
ReactはJavaScript界隈の関数型プログラミング化の潮流で登場。
最近、炎上している別の方面で、特にFRPと組み合わせると圧倒的なパワーを発揮すると一部では実例とともに指摘されている。
http://kenokabe-techwriting.blogspot.jp/2016/05/frptimeenginereactjsocaml.html
Reactは、関数型あるいは宣言型に書けるように用意されている。DOMは、「仮想DOM」として、JS（JSX）上の「値」として統合されていて、それは自由に変形し、組み合わされ、リアクティブにJSX上の仮想DOMから実DOMにリアルタイムでマッピングされ描写される。
JQueryも、実DOMを関数型で操作できるような拡張ではあるが、Reactのように宣言的に書くことは不可能。
coffee scriptは、ES6登場までの過渡期の橋渡しみたいなもので、登場したのも消えたのも合理性がある。
React.jsは、関数型の潮流で登場したものでこれも合理性があり、この延長線上でさらに洗練された代替物が登場する可能性はあれど、このパラダイムが消えることはない。
