Webパフォーマンスにおけるイニシャライズとランタイム
Webフロントエンド・パフォーマンス 思考整理系。 Webフロントエンドにおける3要素として、過去のセッションでは下記の3つを中心に紹介していました。 通信コスト - Networking 描画コスト - Rendering 計算コスト - Computing これらの問題は複雑に絡み合い、時として相反する関係をとります。例えば、通信コストを減らすために、視覚表現を画像からCSS3に置き換えたら、描画コストが高くなってしまいスクロールが重くなった、なんてケースは頻繁にあるでしょう。 理解の問題 この3つのコストは確かにパフォーマンスに影響を与える要因であります。しかし、その要因がWebフロントエンドのページライフサイクルにおいて、どこで影響を与えているかは表してくれません。 要因がどのような影響を及ぼしうるかという基礎的な理解と、パフォーマンスの問題に取り組むための切り口としての理解は、そ
Frontrend vol.7 html5 audio
DEV-019_Programmable Video ～Azure Media Services でのビデオ サービス開発～decode2016
AngularJSとサーバーサイドテンプレートの混在とngNonBindable
Angularとサーバーサイドテンプレートの混在 先日リリースされた某サービス(他社)がAngularを使っていて、XSSがボロボロ出てくるだとか、{{var}} な形式で値を入力するとng-template側でテンプレーティングされるだとかの話がありました。 詳しくは見ていないので、今回の話とまったく同じかは把握していませんが、サーバーサイドテンプレートを混在させると、次のようなことが起こりえます。 例えばejsとAngular サンプルとしてスカスカなControllerを用意します。 angular.module('app', []).controller('AcmeCtrl', function($scope) { $scope.foo = 'bar'; }); ejsは次のようなテンプレートになっているとします。
バッジ駆動開発（2014:Node.js） - MOL
こんちわ！@t32kだよ。みんなバッジ好き？( ﾟ∀ﾟ)o彡ﾟバッジ！バッジ！バッジ！ 小学生の頃、自由勉強ノートってのがあって、勉強したページ分、先生からシールをもらってはそのノートに貼り付けていたのは良い思い出です。あのノスタルジーを再び！ ということで、大人の自由勉強ノートといえばGitHubレポジトリじゃないですか。OSSがんばります！私、気になります！そしたらシール欲しいじゃないですか？ あるよ、シールあるよ、シールってかバッジだけど。 上記は最近作ってるStyleStatsのReadmeだけど、なんか緑のバッジいっぱいですよね。それを説明していく！ Travis-CI Status Images Travis CI: Status Images まずは、この中のバッジの中では一番メジャーじゃないだろうか、Travisの Status Images。昔、@kyo_agoさんが『テ
Sass/Compass徹底入門を監修しました - MOL
2014年3月18日に発売される、Sass and Compass in Actionの邦訳版である『Sass&Compass徹底入門 CSSのベストプラクティスを効率よく実現するために』を監修した。 Sass&Compass徹底入門 CSSのベストプラクティスを効率よく実現するために Wynn Netherland, Nathan Weizenbaum, Chris Eppstein, Brandon Mathis, 石本 光司 (株式会社サイバーエージェント) 翔泳社 2014-03-18 Amazonで詳しく見る by G-Tools 監修の依頼を受けて音速でハイと答えたのだけど、監修って何するんだろうねって感じだった。いや、原書の『Sass and Compass in Action』は以前から購入していて、Sass/Compassの開発者であるNathan Weizenbaumや
1000ch.net
Posts 2024.01.14 Google のソフトウェアエンジニアリングを読んだ 2023.12.31 2023年の振り返り 2023.12.06 2023年に買って良かったもの 2023.09.27 TechFeed Experts Night#26 で 2023 年の Web 開発について話した 2023.09.26 Obsidian を使ったデバイスを問わないメモ運用 2023.09.21 フロントエンドの開発生産性〜Online Conference〜に出演した 2023.06.30 株式会社メルカリを退職します 2023.04.24 社内の有志で運用していた QA システムをオープンソース化した 2023.04.09 東京さくらマラソンで 10km を完走した 2023.03.22 2023年のフロントエンド高速化手法〜Fastlyとメルカリに学ぶ、パフォーマンスチューニン
Sass3.3の@at-rootで親のルールを指定する | inkdesign
Sass3.3の@at-rootで親のルールを指定する Published on Feb 16, 2014 先日登壇したCSS Nite LP, Disk 32のセッションで紹介されていたSassのMixinをSass3.3の@at-rootで少し手を加えてみる、という話。 紹介されていたのは、天地左右中央に絶対配置するテクニックのMixin。 @mixin trbl($width: null, $height: null) { position: absolute; top: 0; bottom: 0; left: 0; right: 0; width: $width; height: $height; margin: auto; } .tbrl { @include trbl(100px,50px); } .tbrl { position: absolute; top: 0; bott
AWS-EC2上に自分用のSTUNサーバを立てる話 - blog::wnotes.net
WebRTCネタの続きです 間が空いてしまいましたが、引き続きWebRTC関連のエントリです。そして久々にLinux関連です。なお、前回同様調べながらの備忘録的エントリとなっています。間違っている部分もあるかもなので、専門家の方の指摘など頂けると嬉しいです。 STUNサーバも自分で用意したい 前回のエントリではうまくできなかったSTUNサーバ構築のリベンジです。今回のサーバはAWSのEC2です。（やっぱりさくらではうまく行かなかった…推測される理由は後述） WebRTCを使ったサービスや社内アプリを開発する場合（やる可能性は低いかもですが）、当然 GoogleのようなPublicなSTUNサーバを使うのは憚られますし（SkyWayも独自に提供してますね）、認証機構などもしっかりとしておきたいですよね。今回も自分なりに理解した部分を交えて書いていきます。 EC2インスタンスのセットアップ 標
Gruntについて最新の気持ち
思いつき だいぶ前からGrunt周りというかGruntそのものへの関心が薄れゆくなか、タスク周りがやたらと充実してきたエコシステムの恩恵を、ただただ享受するにとどまっている。 業務で700行のGruntfile.jsを見かけて、SAN値をもっていかれた折に前々から感じていた疑念が表に出た。 「これ、Gruntに仕事させすぎじゃないの」 分担してもよいのでは 前述の700行のなかには、ファイルのビルドをはじめとして、ユニットテスト、E2Eテスト、ドキュメント生成、ローカルサーバー、LiveReload etc etc etc ...すべてひとつのファイルに入っていた。 (; ⁰⊖⁰) Oh... いまいち感覚的なトコロなので表現しづらいのだが、役割としてあまりにGruntfileで表現している内容がごった煮すぎるように思う。 自分の場合、テスト周りはtestemにしていて、ドキュメント生成系
画像の最適化をCLIだけで行うgrunt-imageを作った | 1000ch.net
GUI要らずを目指して Webにおける画像については以前記事にしましたが、 そのフローをより良くするべく最近gruntのモジュールを作ったのでその話を。 前置き 私は弊社サービスのパフォーマンス改善を業務としてしています。 何がボトルネックになっているかは各プロジェクトでまちまちですが、 共通しているのが 「とにかく画像が多い」 というところ。 どのサービスもペイロードサイズの80%程を画像が占めているんですね。 画像の最適化を忘れるだけで（例えば）100KBとか平気で増えるので、 これではCSSやJavaScriptのファイルサイズを減らしても本末転倒です。 （もちろんCSSもJavaScriptも結合と圧縮は非常に重要です。） 各種最適化ツール GUIだと以下の3つが有名で優秀です。 ImageAlpha - フリーソフト。24bitのPNGの8bitコンバートを行う。256色~2色ま
BEMの命名規則は賢い | inkdesign
BEMおよびその命名派生としてのMindBEMdingで使われるfoo__barやfoo--barというようなハイフン、アンダースコアを重ねた命名はキモいし冗長だと嫌われがちだ。僕自身も初見ではそのように思っていた。しかしこれは本当に良いアイデアだと思うし、実務でも僕は採用している。 CSSの設計、その命名のときに考えるのは、それがいかに明白であるかということと、汚染されるリスクを抑えられるか、ということだ。ワードを明確に区切ることによって、その機能・カテゴリを区別するという点においては、別に単一記号であろうが、キャメルケース、スネークケースであろうがなんでもいいかもしれない。しかしスタイルが汚染されるリスク、という点でこの珍妙な命名は優秀だ。 プロジェクトに関わる開発者が多いほど、その書き方にブレは生じる。もちろんコーディング規約なり、スタイルガイドなりであらかじめルールを共有しておけば
SaCSS Special4 Frontrend in Sapporoのスライド公開しました - Life goes on
あけましておめでとうございます。 去年12月にセッションさせていただいたSaCSS Special4 Frontrend in Sapporoでの自分のスライドを公開しました。 今回はターミナルとかCUIをやりたいんだけども、踏み出せない方向け…ということで悩んだ結果こういうスライドになりました。アンケートなど拝見したところ、おおむね好評で良かったです。 本当はコマンドを便利に使うようにTabキーでの補完とか、最初は必ずハマるであろう環境変数のこととか、良く使うコマンド登録するためのaliasとかも説明したかったんですが、 時間の都合でそこら辺は入れられなかったのが残念です…。 ということで、ご来場いただいた皆様あらためてありがとうございました！ あと今回痛感したのが、「興味があまり持ってない分野に興味を持ってもらう」というのはやっぱり難しいなーということでした。どういう構成で説明したら良
CSSの汎用クラスのつかいどころ | inkdesign
OOCSSをはじめとするCSS設計におけるモジュール指向のアプローチの話になると、下記のような単一プロパティで定義されたルールを組み合わせたものを指す、というような説明がされる場合がある。 .size1of4 { width: 25%; } .mrs { margin-right: 10px; } .font-small { font-size: 10px; } .text-left { text-align: left; } これらはUtilityとか、Helperとか、汎用クラスというように呼ばれ、あれば何かと便利なルールだ。 どういうときに便利かというのは、唐突なデザイン変更要求などに、都度そのためのルールを定義するよりも、これらの汎用クラスの組み合わせで対応できるということが挙げられるだろう。 <div class="mts text-center"> <img src="ban
技術と管理と標準化の悶々
ここで自分が思いを馳せることができるのは、下記のようなトピックです。 チーム構成・人材配置 アーキテクチャやライブラリの標準化 開発効率の向上・環境整備 チーム構成・人材配置 ちょっと夢見すぎかなと感じている事案のひとつに「複数職能の人間（≒ゼネラリスト）を複数人組み合わせれば少数精鋭が成り立つ」があります。 少数精鋭がなぜ少数精鋭たるかといえば、単に「精鋭だから」ということに尽きると思っています。正味な話、平均的な能力の人間を浅く広くゼネラリスト化して少数集めたところで、生産力が高まるどころか品質が低下する恐れがあります。 組織であればこそ、環境と仕組みによって品質担保を行うことはできます。よって、品質担保の仕組みと合わせて議論すべきであることを前提としつつも、昨今のフルスタックエンジニア論に踊らされる過ぎるのはそれでも危うくないでしょうか。 一方、完全なスペシャリスト集団による分業も夢
いぇーい yield と co と koa
express の後継だけあって期待が高まってる Koa ですが、あの珍妙な yield による同期処理っぽい記述がどのようにして支えられているかメモってみます。 年末年始を経てヤル気が高まってきたので、久々にnodeの話。 visionmedia/co さて本題。 早速ですが、koa の middleware における、あの特徴的な yield 天国は、koa ではなく co というモジュールによるものです。サンプルを見るのが早いです。 本件は yield を使うので、現時点では node v0.11.x を --harmony オプション付き実行が必要なことに注意してください 下記は co を単品で利用した場合のサンプルです。 /** * GETリクエストを非同期処理するモジュールを想定 * @example get('http://example.com')(function() {
手軽にCIを体験してみたい - MOL
昨年のFrontrend/06では、全くもってながら個人的な趣向のもと継続インテグレーション（CI:Continuous Integration）をテーマに開催した。もはや、フロントエンドとは！という感じだが、非常に良いイベントだったと思う。 基本的に昨今のフロントエンドは膨大なタスクに追われている、そのようなタスクを手動でちまちまやっていては手戻りやミスなど必ず発生するので自動化すべきである。フロントエンドの自動化はGruntなどがあるが、結局フロントだけで問題を解決しようとすると問題（限界）があったりするので、CIサーバーとか使ったほうがいいよね。てかフロントエンドの人も慣れておいたほうがいいよねって話。 しかし、フロントエンドの人がいちからJenkinsを立ち上げたりするのもさほど面倒でもないが多少の心理的障壁があるので、もっとカジュアルに利用したい。 Frontend/06の佐竹さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Frontrend vol.7で話しました - blog::wnotes.net
WebブラウザでP2Pを実現する、WebRTCのAPIと周辺技術
フロントエンドエンジニア（仮） 〜え、ちょっとフロントやること多すぎじゃない！？〜
http://1000ch.net/2014/02/02/frontrend-in-fukuoka/