久しぶりに、いわゆるポエムを。 新規・運用ヘルプを問わず、受託や副業でよくフロントエンドをやってるWeb屋の見解、そして手札のお悩み。 この先、また技術選定する際なんかにも参考になるかと思ったので。 React 「いまフロントエンドやるなら最初に覚えるべき！」は、もう過去の話かなーと個人的には思ってる。 Reactは`UI = fn(state)`なのが良い！とか言われるけど、あなたが必要としてるのは`UI = Component(props)`かもよって。 一昔前までは、たしかにあらゆる面で頭一つ抜けてる印象はあったけど、今はそうでもないか、その差はだいぶ埋まってきてると思ってる。（もちろん先行者利益みたいなところで、エコシステムはまだまだ優位な差があるかもしれんけど、それもあまり実感できたことはないし、いまからはじめる人はそんなんで困らんやろうし） 原初の時代からReactな案件をそれ

そして子も生まれていました！ というわけで、子です🤗 pic.twitter.com/UzvIiUpCOP— りぃ (@leader22) 2020年6月10日 人生ですなあ。 いままで 2018年12月からNTTコミュニケーションズという会社で働いていて、2020年6月いっぱいで退職しました。（なのでこれはいわゆるNTT退職エントリ 🥱） N社では、 SkyWayの（歴史ある）JS-SDKをメンテしたり （おなじく歴史ある）Nodeで書かれたシグナリングサーバーをメンテしたり OSSのSFUである`mediasoup`を使って、録音SDKとそのサーバーを実装したり WebRTCに関連するRFCやドラフトをとにかく読みまくったり いわゆるエッジな技術の検証をしたり 各種SDKを使ったWebアプリをいくつか書いたり https://github.com/skyway/skyway-con

[WebAudio API] AudioWorklet の使い方 | g200kg Music & Software この大先生の記事を読んで、自分の知ってるWebAudio知識のアップデートをしときたいなーと思って調べたことのメモです。 なので重複する部分もあるけど、+ αな部分もあります。 20191129: あらためて読み直したけど、特に更新すべき部分はない そもそもAudioWorklet Enter Audio Worklet  |  Web  |  Google Developers `ScriptProcessorNode`の後継 重い音声処理をメインスレッドでやりたくないよね いちおうAudioスレッドでやってたけど、完全ではなかった 今度こそAudioスレッドだけでできるよ 2017年12月の記事なんかこれ・・時代を感じる・・。 コード まずは使う側。 // app.js

この記事では、 ReactやVueではなくWebComponentsだけを使いたい気持ちを胸に、とある社内プロジェクトをやってみての学び 巷にあふれるWebComponentsに対する見方への違和感 についてメモっておきます。 ただ「WebComponents」の語がもつ意味をきっちり定義してるわけではないので、そのへんは雰囲気で察してください。 そのせいで勘違いされがちな概念なんかも、知らんけど。 まずは巷にあふれる意見に対する気持ちから。 (React|Vue|Xxx)はもう古い、これからはWebComponentsだ！ 勝手なイメージですが、こういう認識の人いるよね・・？ 個人的には、「いや、WebComponentsはそういう技術じゃない」と思った・思ってます。 以下、ReactもVueもAngularも「ウェブアプリケーションを作るための技術」であるが、WebComponents

もっと早く書こうと思ってたのに、気付いたらもうこんな時間だった・・。 ちなみに2016年にも振り返り記事を書いてて、そこで2017年はこうする！って言ってたやつが以下。 引き続き登壇できるときに登壇する SPAやらアプリケーション設計まわりで着実に仕事をこなす けど本腰は、Live動画とかWebRTCとかServiceWorkerとか、競技人口の少ないおもしろそうなことを追う だった。 振り返ってみると・・・、 △: 登壇はしてたけど、そんなにしまくったりはしてない ○: こなしてたと思う ○: 追えてたと思う というわけで、割と有言実行な一年だった感があるかな・・？ では2017年の振り返り、スタート！ さわった技術たち 仕事やら趣味プロやらでそれなりにさわった技術たちの一覧がこちら。 React ReactRouter, Redux, facebook/flux, i18n, MobX

気になったら即調べるが吉、ということで。 数値→文字列 var num = 123; // わかりやすい String(num); // "123" num.toString(10); // "123" // この用途では使ったこと無い num.toFixed() // "123" // なるほど num + ''; // "123" 文字列→数値 var str = '123'; // わかりやすい Number(str); // 123 parseInt(str, 10); // 123 parseFloat(str); // 123 // なるほど str - 0; // 123 str * 1; // 123 str / 1; // 123 // すっきりやけど知らん人は読めない +str; // 123 -(-str); // 123 ~~str; // 123 str&-1;

もちろんモバイル情報です。 iOS4やらAndroid2.x時代にはまったく使い物にならなかったこの指定、 最近はどうなの？っていう。 overflow: scroll 対象をiOS5以上、Android4以上とするのであれば十分に使えるものだと思います。 ただスクロールすれば良いだけであれば、jsなしに実現できる時代きた！すばらC！ -webkit-overflow-scrolling: touch 勘の良い人ならお気づきでしょうが、コレも使いたいですよね。 スクロールできる部分で慣性スクロールができるようになるやつです。 .carousel { overflow: scroll; -webkit-overflow-scrolling: touch; } みたいな。 ただこいつは、まだ要注意です・・。 手元で再現したバグなので、すべてのケースに当てはまるわけではないと思いますが、 一応こ

textareaの闇を見たような気がした。 これは、文字数のカウンターっぽいものを実装するときに気付いて調べたものです。 いわゆるmaxlengthの敷居と、jsから文字列.lengthで取れる値で、文字数のカウントが違う・・ってなったところが事の発端。 20150624追記 コメントで教えていただいたのですが、この挙動はどうやらWebkitのみだそうです。 DEMOみたく適当な実装すると、現状Webkit以外で困ることになるのでご注意ください。 困ったこと Twitterみたく、いわゆる文字数をカウントしたい場合。 楽できるところは楽したいので、こういう指定をしますよね。 <textarea maxlength="140" id="jsTweetArea"></textarea> 改行せずに文字を打った場合は、きっちり140字で打ち止めになってくれます。 ペーストしても、はみ出る分はばっ

いったい何度同じ過ちを繰り返せば気が済むんだという感じになったのでメモ。 スマートフォンで要素の拡大・縮小やら移動やらするときに気をつけたいのは以下。 GPUアクセラレータが効く方法を選ぶ アニメーションさせる要素数を厳選する Defferdなど、時と場合によっては擬似的に遅らせたりする ・・・でもメモしたいのはもっと手前の凡ミス。 2次元方向の移動だとしても ダメな例 .moveX { -webkit-transform: translateX(20px); } .moveY { -webkit-transform: translateY(20px); } 良い例 .moveX { -webkit-transform: translate3d(20px, 0, 0); } .moveY { -webkit-transform: translate3d(0, 20px, 0); } 3dで

未来の自分のためのメモです。 仕事でやってないせいですぐ忘れるし、都度思い出すの大変なので・・。 ただまぁだいたいの人はSkyWayとかEasyRTCとか何かしらのライブラリを使うはずで、そういう人たちにはあまり関係ない内容かも。 生のjsでWebRTCを書くときに、先に知っておきたかった系のメモです。 素人ではないがベテランでもない、そんな微妙な知識レベルだと思います。 まだ枯れた仕様ではないので、記事を読む時は日付に注意してください... WebRTC is 何 WebでRealTimeCommunicationできる仕様 もといクライアントどうしでP2Pで通信できる仕様やそのAPI群 See WebRTC Home | WebRTC 仕様まわり WebRTC 1.0: Real-time Communication Between Browsers Identifiers for W

知ってることを自分の中で整理するためのメモです。 知ってることしか知らないしそこまで使い込んでないので、間違ってる可能性は多いにありです。 動画配信とライブ配信 Webで動画を配信するには2つのパターンがある 完成した動画ファイルをまるっと取得して再生するか 動画ファイルの一部を「逐次」取得して再生する（ストリーミング）か クライアントサイドとしては、サーバーにあるメディアを逐次取得するだけなので、そういう意味での違いはない 今回の記事は後者の方法について Web = HTTPベースのストリーミング用にいくつかプロトコルがある HDS(= HTTP Dynamic Streaming) HLS SS(= Smooth Streaming) MPEG-DASH このうち、HLS / MPEG-DASHが最近の主流の2つ だいたい似たような仕組みになってて、ざっくりAdaptive Strea

調べては忘れを毎回繰り返すのもなんだかなーと思ったので、まとめておきます。 ちなみに、iOS/Androidのことしか書きません。 iOSは5以上、Androidは4以上のOSバージョンを対象としてます。 OperaとかMetroとかFireFoxとかは知りません！もっと頑張ってください！ あくまでこの記事を投稿した時点でのものです！ 全般 拡張子はpng 勝手に角丸になるので四角のまま書き出してOK Safari(iOS) いちおう公式のドキュメントはこちら。 Configuring Web Applications で、実は指定方法が2つありまして、 HTMLで指定する方法(おそらく一般的) ドキュメントルートに画像を配置する方法 以下それぞれ。 HTMLで指定する場合 <link rel="apple-touch-icon" href="/path/to/icon.png"> ってr

そんなに長々と書くつもりはなくて、区切りなので一応書いておこうくらいのノリ。 いままで いまさらですが、株式会社ディー・エヌ・エーというところにいました。 ガラケーであれこれ 初期のスマホとあれこれ バグだらけのAndroidとあれこれ iOSとあれこれ モバイルでパフォーマンスがどうとか SPAがどうとか まぁそんなことを3年くらいやってました。 モバイル三昧でしたね。 これから これからは、株式会社ピクセルグリッドというところにお世話になります。 そうです、皆さんご存知のあそこです。 いわゆるすごい人しかいないあそこです。 今まで以上にあれこれ頑張らないといけません。 自宅作業OKなので、毎日寝転がって仕事してます。 引きこもりがすごく捗ります。誰か連れ出してください。 恒例のウィッシュリストとか考えたんですけど、特に欲しいものもなかったのでやめました。 ご飯のお誘いお待ちしています！