タグ

ブックマーク / postd.cc (26)

  • クロージャによる死(とQwikによる解決方法) | POSTD

    世界中にQwikを紹介した前回の記事では、 多くの要素についてざっと触れるに留まり、詳細については後で説明するとお約束していました。 Qwikとその背景にある設計思想を知る前に、まず私たち(業界)が現在の場所までどのようにたどり着いたかを理解しておくことが重要です。 現代のフレームワークはある前提のもとに成り立っており、 それが優れたTime to Interactive(TTI)スコアの実現を妨げているのですが、 その前提とはどのようなものなのでしょうか。 現行世代のフレームワークの現時点における限界を理解することで、 Qwikの設計思想がなぜ最初は驚くべきものに思えるのか、より深く知ることができるでしょう。 TTIについて TTIは、URLに遷移してからページがインタラクティブになるまでの時間を測定したものです。 レスポンシブなサイトとしての体裁を整えるには、サーバーサイドレンダリング

    クロージャによる死(とQwikによる解決方法) | POSTD
  • Qwikの紹介 – HTMLファーストのフレームワーク | POSTD

    Builder.ioは、強力なビジュアルエディタにより、開発者ではない人が超高速なサイトを開発・編集できるようにしています。 私たちのビジュアルエディタが優れている点の1つは、AngularからWeb Components、 そしてその間にあるすべてのフレームワークに至るまで、 さまざまなツールで同じサイトを生成できることです。 出力されるコードは速度が最適化されています。 私たちのツールで作成されたサイトは、手作業で作成されたサイトの大部分よりも高速です。 私たちはこれを心から誇りに思っています。 私たちの製品は、スピードがとても重要であるeコマースに焦点を当てています。 優れたTime to Interactiveの実現は困難 どんなにコードが最適化されていても、静的HTMLのみを提供していない限り、 eコマースサイトがPageSpeed Insightsで100点中100点のスコアを

    Qwikの紹介 – HTMLファーストのフレームワーク | POSTD
    mizdra
    mizdra 2022/11/28
    分かりやすい
  • POSTDをGatsby.jsベースに変更しました | POSTD

    POSTDの運用がリクルートからニジボックスに移管される際に、デザインのリニューアルと同時にコードベースをGatsby.jsに変更しました。 記事では、運用移管に至るまでの過程を踏まえつつ、現在のPOSTDの構成を紹介します。 移管前のPOSTD 前述の通り、POSTDは株式会社リクルートのインキュベーション部門Media Technology Lab.(現新規事業開発部)で運用されていました。 最後に公開した記事は、2019年3月28日の「PHPはもうダメだ、PHP万歳!」となっています。 もともとはWordPressによる運用が行われていましたが、運用体制の関係で静的HTMLをFirebaseで公開する形式になっていました。 ニジボックスへの引き継ぎに伴い、記事の翻訳を始めとしたサイト運用を再開することになり、改めてCMSの形式に変換する必要が出てきます。 Gatsby.jsを選ぶ

    POSTDをGatsby.jsベースに変更しました | POSTD
    mizdra
    mizdra 2021/04/29
  • Makefileを自己文書化する | POSTD

    私たちのプロジェクトではいつも、非常に長い Makefile を使用して、インストールやビルド、テスト、デプロイメントの処理を自動化しています。ターゲット名はほとんど標準化されていますが( make install 、 make deploy )、中には説明が必要なものもあります( make run-dev 、 make restart-api )。そして、詳細なmakeターゲットを追加するほど、それらの処理内容をテキスト形式で大量に記載しなければなりません。私たちのプロジェクトでは通常、このような文書を README ファイルに書いています。 しかしCLI(コマンドラインインタフェース)を用いる場合は、主に自己文書化ツールを使っています。 make と打つだけで、利用可能なコマンドとその説明が一覧表示されたら便利だと思いませんか? それを実現するのは、実はとても簡単です。まずは各ターゲッ

    Makefileを自己文書化する | POSTD
    mizdra
    mizdra 2020/06/06
    すごい
  • CSS will-changeプロパティについて知っておくべきこと | POSTD

    はじめに WebKit系ブラウザでCSS transformanimationといったプロパティを使った時に発生する、“例のちらつき”。これに気づいたことのある人ならば、おそらく“ハードウェア・アクセラレーション”という用語をこれまでにも耳にしたことがあるでしょう。 CPU, GPU, ハードウェア・アクセラレーション 一言で言うと、ハードウェア・アクセラレーションとは、グラフィックス・プロセッシング・ユニット(GPU)を用いてセントラル・プロセッシング・ユニット(CPU)の処理量を軽減し、ブラウザのレンダリング処理を効率化することです。ハードウェア・アクセラレーターを有効にしてCSS処理を使うと、ページのレンダリングが速くなり、ページ表示が高速化されます。 名前の通り、CPUGPUはどちらもプロセッシング・ユニットです。CPUはコンピュータのマザーボードに取り付けられている部品で、ほ

    CSS will-changeプロパティについて知っておくべきこと | POSTD
    mizdra
    mizdra 2020/03/21
    良い
  • Web Storage: セッショントークンのマシな手段 ― cookieとセキュリティ面を比較してみる | POSTD

    最近、私は「セッショントークンを、cookieの代わりに Web Storage (sessionStorage/localStorage)に保存するのは安全ですか?」ということを尋ねられました。このことについてGoogleで検索したところ、検索結果の上位のほとんどが「Web storageはcookieに比べてかなりセキュリティが弱く、セッショントークンには不向きである」と断言していました。透明性のため、私はこの逆の結論に至った理論的根拠を公に書くことにしました。 Web Storageに関する議論の中核として言われるのは、「Web StorageはsecureフラグやHttpOnlyフラグといったcookie特有の機能をサポートしていないため、攻撃者が容易に盗み取ることが可能」というものです。path属性についても言及されます。私は、これらの機能それぞれについて調べてみました。そして、

    Web Storage: セッショントークンのマシな手段 ― cookieとセキュリティ面を比較してみる | POSTD
  • フロントエンドにおいてModel-View-Controllerは死んだのか? | POSTD

    多くのフロントエンド開発者が 一方向のアーキテクチャ を採用し始めている中で、Model-View-Controller(MVC)に未来はあるのでしょうか。 状況を把握するために、まずはフロントエンドのアーキテクチャの進化を振り返ってみたいと思います。 過去4年にわたり、私は多数のWebプロジェクトに取り組み、フロントエンドの構築、そしてフロントエンドとフレームワークの統合に多くの時間を費やしてきました。 2010年以前は、従来のウェブサイトにDOM操作を追加する場合は大抵JavaScript( jQuery が書かれたプログラミング言語)が使用されていました。当時の開発者はアーキテクチャ自体についてはそれほど気に掛けていなかったと思います。コードベースを構造化する場合、 Revealing module pattern のようなものがあれば十分でした。 現在、多くの議論が交わされているフ

    フロントエンドにおいてModel-View-Controllerは死んだのか? | POSTD
    mizdra
    mizdra 2019/07/24
    図が良い
  • 2016年、C言語はどう書くべきか (前編) | POSTD

    (訳注:2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注:著者のMattより、「文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例: 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり

    2016年、C言語はどう書くべきか (前編) | POSTD
    mizdra
    mizdra 2019/03/22
  • Dockerコンテナが遅くなるもう一つの原因 | POSTD

    前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ

    Dockerコンテナが遅くなるもう一つの原因 | POSTD
  • リモートワークのストレス | POSTD

    リモートワークのストレス ソフトウェアエンジニアリング業界では、リモートワークは大いに理にかなった働き方です。大抵はPCとインターネット接続さえあれば仕事ができるからです。よって、決まったオフィスに毎日通って働く理由は比較的少ないため、リモートワークIT職の重要な要素になっています。最も先見的な求人市場とは決して言えないベルギーにおいてさえもです。とはいっても多くの場合、リモートワークが認められるのは週の一部のみ(おそらく週に1日か2日ぐらいが一般的)にすぎません。それにもかかわらず、リモートワークは大部分の企業で導入されるようになってきたのです。 リモートワークには多くの利点があると言われており、この働き方を過激なまでに擁護する声もよく耳にします。その多くには同意するものの、リモートワークを5年以上してきた経験から言えるのは、リモートワークにはストレスが付き物だということです。そう聞く

    リモートワークのストレス | POSTD
    mizdra
    mizdra 2018/03/11
  • webpackとRollup:似て非なるもの | POSTD

    先日、Facebookは 膨大なプルリクエスト をReactにマージして、既存のビルドシステムを Rollup ベースのシステムに移行しました。 その結果 、 何人もの人々 から「なぜwebpackではなくRollupを選んだのか」という質問が寄せられました。 これは、もっともな疑問でしょう。 webpack は、近年JavaScriptコミュニティで最も評価されているツールの1つです。毎月のダウンロード数は何百万件にもおよび、何万個ものウェブサイトやアプリケーションに使用されています。巨大なエコシステムがあり、コントリビュータも多くいます。さらにオープンソースプロジェクトとしては珍しく、 かなりの寄付金 が集まっています。 それに比べるとRollupは小規模です。しかしReact以外にも、VueEmber、Preact、D3、Three.js、Momentなど、数々の有名なライブラリに

    webpackとRollup:似て非なるもの | POSTD
  • MOSSプログラムがwebpackに約1400万円の助成金を支給 | POSTD

    (※訳注:翻訳記事の元記事は7/31の投稿日となっていることにご注意下さい) webpackの特徴的な機能の1つは 「依存関係グラフ」 を使ったアセットの管理とバンドルです。 しかしながら、webpackにロードされる全てのリソースはJavaScript(css、画像、svgs、htmlなど)として扱う必要があります。このことによって、webpackにおいてはJavaScriptのみが 第一級モジュール型となっています 。これによる欠点は、CSSHTMLなどのそれぞれのアセットを個別の実行時間で遅延読み込みができないことです。こういったことを実現したければ、これまでは(extract-text-webpack-pluginのような)ハッキングに近い解決策を作る必要がありました。 WebAssembly webpackでは現在、より多くのモジュールのサポートに焦点を移すことを考えています

    MOSSプログラムがwebpackに約1400万円の助成金を支給 | POSTD
  • 「フロントエンド開発者」の終焉 | POSTD

    元記事の著者より:この記事は主に北米文化で私が見たことを反映しています。 誰かに職業をきかれたら、私は「フロントエンド開発者です」と答えます(答えは相手によって変わることもあります)。10年か20年前は、自分の仕事に必然的に伴うものが何なのかは、かなり明瞭でした。インタラクション用にHTMLCSSを書き、JavaScriptも多少は書いていました。駆け出しの頃、PHPMySQLの作業に職務の大半を費やしていたとはいえ、フロントエンド開発者として見られる方が好きです(これに関しては、後に詳しく説明します)。この状況は、2010年の初頭に変わり始めました。JavaScriptが、重要で、非常に大きな存在になってきたのです。昨年の初め頃から、たくさんのフロントエンド開発者に会うようになり、あることに気付きました。フロントエンド開発者は、もはや、私が以前から知っているフロントエンド開発者ではな

    「フロントエンド開発者」の終焉 | POSTD
  • さよなら、Firebug | POSTD

    最も人気が高くパワフルなWeb開発ツール。 Firebugはこれまでに驚異的な成功を収めており、その12年の歴史において、オープンソースのツールとして、Web開発者の間でカルト的な人気を築き上げてきました。登場したのは2005年、Firefoxブラウザでコードの検査、編集、デバッグをできるようにした最初のツールです。また、どのようなWebページにおいても、CSSHTMLJavaScriptの調査を可能にしています。これは大きな前進でした。 Firebugは多くの人の注目を集め、現在でも100万人以上の熱心なファンがそれを使用しています。 そのような中、来月リリースされるFirefox Quantum (バージョン57) で、Firebugが終焉を迎えるのは残念でなりません。ただし、現在のFirefox Developer ToolsにFirebugの全ての機能が盛り込まれている点につい

    さよなら、Firebug | POSTD
  • バージョンの充足可能性問題 | POSTD

    (注:2017/02/06、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) Dependency HellはNP完全ですが、この状況から脱却できるかもしれません。 パッケージにおけるバージョン選択の問題とは、完全である(全ての依存関係を満たしている)かつ互換性のある(互換性のない2つのパッケージが選択されていない)トップレベルパッケージPをビルドするために使われる依存関係の集合を見つけることです。ただし、菱形依存問題があるので、このようなセットは存在しない可能性があります。菱形依存問題とは、AはBとCが必要、BはDのバージョン2ではなくバージョン1が必要、CはDのバージョン1ではなくバージョン2が必要といったような問題のことです。この場合、Dの両方のバージョンを選択することはできないため、Aをビルドすることができないわけです。 パッケ

    バージョンの充足可能性問題 | POSTD
    mizdra
    mizdra 2017/12/03
    パッケージマネージャのパッケージのバージョン選択の処理にSATソルバが使われている話
  • 2017年JavaScriptのテスト概論 | POSTD

    稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを

    2017年JavaScriptのテスト概論 | POSTD
  • Bashアプリケーションをテストする | POSTD

    以前、bashスクリプトをテストする仕事に取り組んだことがあります。最初、Pythonユニットテストを使うことにしましたが、プロジェクトに外部技術を持ち込むのは気が進みませんでした。そこで、仕方なく、悪名高い bash で書かれたテスト用フレームワークを使いました。 既存ソリューションの概要 手に入るソリューションを探してGoogle検索しましたが、選択肢はほんの少ししかありませんでした。そのうちいくつかについて、詳しく見ていきましょう。 重要になるのは、どんな基準でしょうか? 依存関係: bass のテスト用フレームワークを選ぶときに、 python 、 lua などのシステムパッケージも一緒に引きずり込むのは嫌ですね。 インストールの難しさ:継続的な開発の実装とTravis CIでの継続的な統合も仕事の1つだったので、私にとってインストールにかかる時間と手間数が妥当だということは、重要

    Bashアプリケーションをテストする | POSTD
  • 正式リリースされたES8の主な新機能 ???? | POSTD

    EcmaScript仕様第8版の新機能 EcmaScript 8もしくはEcmaScript 2017が、6月末にTC39から正式にリリースされました。私たちはこの1年、EcmaScriptについて色々と議論しているようですが、それは無駄なことではありません。現在、ES標準は新しい仕様のバージョンが年1回公開されています。ES6は2015年、ES7は2016年に公開されましたが、ES5のリリース時期をご記憶でしょうか。JavaScriptが魔法のように普及する以前の、2009年のことでした。 つまり私たちは、安定した言語としてJavaScriptの開発上の変化をたどっており、今や自分の語彙にES8を加える必要があるのです。 ES2017 (the 8th edition of the JavaScript Spec) was officially released and publishe

    正式リリースされたES8の主な新機能 ???? | POSTD
  • DockerでのNodeアプリ構築で学んだこと | POSTD

    以下に紹介するのは、 Docker を使って node.js 用のWebアプリケーションを開発、およびデプロイする際に、私が四苦八苦しながら学んだ秘訣やコツです。 このチュートリアル記事では、Dockerで socket.ioのチャットサンプル を白紙の状態から番状態へとセットアップしていきます。このプロセスを通じて、そうした秘訣などを簡単に習得していただければ幸いです。特に、以下のような内容について見ていきます。 実際にDockerでNodeアプリケーションを起動する。 すべてをrootとして実行させない(悪いやり方です)。 開発時のテスト-編集-リロードサイクルを短くするため、バインドを使用する。 再構築を高速にするため、 node_modules をコンテナで管理する(これには秘訣があります)。 npm shrinkwrap で、ビルドを反復可能にする。 開発環境と番環境で Do

    DockerでのNodeアプリ構築で学んだこと | POSTD
  • Reduxのパターンとアンチパターン | POSTD

    Redux は、 Flux のようなアーキテクチャを使用してアプリケーションの状態を管理できる非常にシンプルなライブラリです。私たち Affirm では今、 Reduxのタイムトラベル機能 に注目しています。Affirmの主要事業は、透明性の高い消費者ローンを提供することなので、ローン申し込み時の全過程をユーザ視点で再現できると非常に有用なのです。 Reduxはフレームワークというよりも、パターンの適用に役立つ関数セットです。よって、適切なパターンを慎重に適用しないと、Reduxを使ったことを後悔する結果になりかねません。この記事では、Affirmで確立したReduxのベストプラクティスや、ミスを犯しやすいポイントについて説明します。 ImmutableJS ImmutableJS は、不変の永続データ構造を扱うためのライブラリです。私たちがこのライブラリを好んで使う理由は2つあります。

    Reduxのパターンとアンチパターン | POSTD