タグ

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

  • モダンWebにおけるキャッシングのための新HTTP標準 | POSTD

    一般ユーザー向けの大規模なWebサイトや、モダンWeb上で動作するWebアプリケーションを運営する場合、CDNなどのキャッシングサービスによって静的コンテンツをキャッシュすることが極めて重要です。 しかしこうしたサービスは、非常に複雑で分かりにくいものです。 幸い、IETF(Internet Engineering Task Force)のHTTPワーキンググループがこの状況を改善すべく、HTTPの新標準策定に取り組んでいます。 最近、同ワーキンググループでは、キャッシングのデバッグとキャッシュ設定の管理を容易にすることを目的とした、HTTPヘッダに関する2つの新標準案の発表に向けて活発な動きがありました。 このことが何を意味し、どのように機能するのか、そしてWeb制作に携わる開発者全てがなぜ注目すべきなのかについて見ていきます。 新標準 この記事で取り上げる標準案は以下の2つです。 Ca

    モダンWebにおけるキャッシングのための新HTTP標準 | POSTD
    yo_waka
    yo_waka 2022/09/02
  • React Server Componentsの仕組み:詳細ガイド | POSTD

    React Server Components(RSC)は、ページの読み込みパフォーマンスやバンドルサイズのほか、Reactアプリケーションの書き方に近い将来大きな影響を与えることになる、素晴らしい新機能です。 Plasmicでは、Reactのビジュアルビルダーを開発しており、Reactのパフォーマンスには大きな関心を持もっています。 当社のクライアントの多くは、Plasmicを使用して高いパフォーマンスが求められるマーケティングサイトやECサイトを構築しています。 したがって、RSCはまだReact 18の初期実験機能ですが、Plasmicではその仕組みを詳しく調べています。 このブログ記事では、これまでに分かったことを紹介したいと思います。 Plasmicのメンバーによるツイートまとめもご覧ください。 React Server Componentsとは何か サーバサイドレンダリングとの

    React Server Componentsの仕組み:詳細ガイド | POSTD
    yo_waka
    yo_waka 2022/07/30
  • リモートワークのストレス | POSTD

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

    リモートワークのストレス | POSTD
    yo_waka
    yo_waka 2018/03/09
    セルフマネジメントが他人から見て全く問題ない人じゃないと、本人はいいんだろうけどチームからしたらよく分からない人になっちゃうよなあ。リモートワークは難易度高いと思うし、それを理解したうえでやるべき
  • Unixコマンド”yes”についてのちょっとした話 | POSTD

    知っているUnixのコマンドで一番シンプルなものは何ですか? 例えば echo という、stdoutに文字列を出力し true を返す – すなわち常に0の終了コードで終了するシンプルなコマンドがあります。 シンプルな、と言えば yes もそうでしょう。引数なしで実行すると、改行されたyが無限に出力され続けます。

    Unixコマンド”yes”についてのちょっとした話 | POSTD
    yo_waka
    yo_waka 2017/11/10
  • –cap-dropオプションを使ったDockerコンテナの安全性を高める工夫 | POSTD

    DockerにはLinuxのケーパビリティを削除するためのオプションがあるのをご存じでしたか? docker run --cap-drop オプションを使うと、コンテナのルートを隔離することができ、コンテナ内でのアクセス権を制限することができます。悲しいことに、ほとんどの人はコンテナやそれ以外の場所でも、セキュリティを強化していません。 翌日では手遅れ ITの世界ではセキュリティへの配慮が遅すぎるという残念な傾向があります。 セキュリティが破られた翌日に初めて、セキュリティ対策システムが購入されているのです 。 ケーパビリティを落とすことで、コンテナのセキュリティを大変手っ取り早く改善することができます。 Linuxのケーパビリティとは? ケーパビリティのmanページ によると、 capabilities とは、個別に有効無効を設定することができる特権の集まりのことです。 私流に説明すると

    –cap-dropオプションを使ったDockerコンテナの安全性を高める工夫 | POSTD
  • リレーショナルデータベースの仕組み (1/3) | POSTD

    リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術(ビッグデータ、NoSQLJavaScriptなど)を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか? 私は開発者として、理解していないものを

    リレーショナルデータベースの仕組み (1/3) | POSTD
    yo_waka
    yo_waka 2016/08/28
  • マイクロサービスの終焉 | POSTD

    これは未来からの投稿です。現在、信頼のおけるスケーラブルなプロダクションシステムの構築は、言ってみれば、その他のソフトウェアを書くのと同じくらい容易になっています。未来にはどのような風景が広がっているのか、お伝えしましょう。 2016年当時は、誰も彼もが「マイクロサービス」を取り上げていました。例えば、1996年に「情報スーパーハイウェイ構想」の記事ばかりが出回った頃に似ています。「情報スーパーハイウェイ構想」というフレーズがやがて消滅し、人々はインターネットの構築に戻っていったのと同様に、サービスが、スケーラブルなソフトウェアシステム構築の標準になるにつれ、マイクロサービスの「マイクロ」の部分もまた、削り落とされて行きました。私たちが使ってきた(そして捨て去った)名称であるにもかかわらず、どちらの用語も、当時のテクノロジーに対する考え方とその使い方に起こった転換を示しています。サービスベ

    マイクロサービスの終焉 | POSTD
    yo_waka
    yo_waka 2016/08/23
    “今にして思えば、サービスのサイズが重要だったことはなく、結合性や関係性が問題だったから”
  • Reactを用いたアプリケーションアーキテクチャ:Fluxを再考する | POSTD

    他のフレームワークやライブラリから React に乗り換える人たちは、「ReactUIのレンダリングに関する問題しか解決しておらず、状態管理とアプリケーションアーキテクチャの選択は開発者に委ねられているのだから、どうやってアプリケーションの状態を管理したらいいのか?」 と疑問に思う傾向があります。FacebookはReactのレンダリングモデルに適している、 Flux と呼ばれるアーキテクチャを勧めています。 この記事では、UIレイヤとしてReactを用いてJavaScriptのアプリケーションの状態を管理する方法を探り、 Om のような ClojureScript ライブラリのアイデアを用いてFacebookのFluxの抽象的なフレームワークを作り変えてみたいと思います。 Fluxの核となる考えは、 データは一方通行で流れるべき というものです。これによってアプリケーションの論証が簡単

    Reactを用いたアプリケーションアーキテクチャ:Fluxを再考する | POSTD
  • Goで毎分100万リクエストを処理する | POSTD

    Malwarebytes は、驚くべき成長を見せています。1年以上前にこのシリコンバレーの会社に入社して以来、私の主な仕事は急成長するセキュリティ企業の力となるシステムの設計と開発です。日々数百万人が利用する製品をサポートするために必要な、全ての基盤をつくります。私は12年以上、アンチウイルスとアンチマルウェアに関わるいくつかの会社で働いてきました。毎日処理する膨大なデータのせいで、これらのシステムがどれだけ複雑なものになるかを理解しています。 面白いことに、ここ9年ほどで私が携わったWebのバックエンド開発のほとんどは、Ruby on Railsが使われていました。誤解されないように言っておきますが、私はRuby on Railsが大好きですし、すばらしい環境だと思っています。しかし、Rubyでシステムを設計し始めると忘れてしまうのは、マルチスレッド化や並列化、高速化、メモリオーバーヘッ

    Goで毎分100万リクエストを処理する | POSTD
    yo_waka
    yo_waka 2015/08/17
    “時折Ruby on Railシステムがとても強力なWebハンドラを必要とする時は、単純だけれど強力な代替可能なソリューションのためにrubyのエコシステムから少し離れて考えてみてください”
  • 大規模Reactアプリケーションを構築するためのベストプラクティス | POSTD

    Sift Scienceで製作にReactを使い始めてからほぼ1年になりました。その間、Backbone+Reactという フランケンシュタインのような 複合アプリケーションを、Reactコンポーネントからなる、かなり大きな1つの階層に育て上げました。この記事では、UI不和を最小限にしながら、コードベースをスケーリングするために役立った技法とベストプラクティスを紹介します。また、一般的なコンポーネントのデザインパターンについて、いくつか説明します。 この記事が皆さんの時間の節約と精神衛生の維持に役立ち、UIが複雑になってもReactコードベースの保全性を維持する(破綻するのではなく)ための新しいツールを提供できれば幸いです。 componentDidUpdateで、もっとできる React質は、DOMの更新というタスクを命令的なものから宣言的なものに変えるということです。他のタイプの命

    大規模Reactアプリケーションを構築するためのベストプラクティス | POSTD
  • 2015年に向けたJavaScriptアプリケーションアーキテクチャ Part 2 | POSTD

    PART1はこちら : 【翻訳】2015年に向けたJavaScriptアプリケーションアーキテクチャ PART 1 オフラインの課題 オフラインでアプリケーションを使えなければ、真のモバイルWebエクスペリエンスとは言えません。 これまで、アプリケーションをオフラインで使用することは根的に困難でしたが、状況は改善されつつあります。2014年を振り返ると、WebプラットフォームのAPIは、より良いプリミティブを提供できるよう進化し続けてきました。最近の事例で最も興味深かったのは Service Worker です。Service Workerは、オフラインでもサイトを稼動させることができるAPIです。ネットワークリクエストに割り込んで、そのリクエストをどう処理すべきかをブラウザに伝えます。 コントロールのレベルが適正かどうかという点以外は、アプリケーションキャッシュのあるべき姿を実現してい

    2015年に向けたJavaScriptアプリケーションアーキテクチャ Part 2 | POSTD
  • 2015年に向けたJavaScriptアプリケーションアーキテクチャ Part 1 | POSTD

    私はかつて自分はアーキテクトだと名乗ったことがあります。これを裏付けるため、今やウソだらけの複雑な話を設計しなくてはならなくなっているので、ある意味これは当のことですね。冗談はさておき、2015年を目前としてJavaScriptコミュニティのアプリケーションアーキテクチャの状況について目を向けてみるのは有益なことだと思います。合成、関数型の境界、モジュラリティ、不変データ構造、CSPのチャネルと、その他に関連するいくつかのトピックについて書いてみたいと思います。 合成 アーキテクチャのレベルでは、JavaScriptで大規模なアプリケーションを作成する方法に関してここ数年で少なくとも一つの根的な変更がありました。機械の細かい違いにより生み出される単一指向性の データバインディング、不変データ構造と、仮想DOM (どれも興味深い問題ですね)などを除けば、多くの開発者が一つのキーコンセプト

    2015年に向けたJavaScriptアプリケーションアーキテクチャ Part 1 | POSTD
  • ジョエル・スポルスキによる『Trello, Inc.について』 | POSTD

    もしもし。聞こえてますか? 今となってはこの“ブログ”なるものを運営する方法を、自分が覚えているのかさえ自信がありません。最後に投稿してから1年も経つんですから。僕はブログから 引退した んですよ。覚えてます? ちょっと変な話を聞いてください。僕がブログを投稿するためには、リモートデスクトップ接続を経由して、サーバラックに収納されている骨董品級のWindows 7マシンにつなぐしかないんです。このマシン上では異様にごちゃごちゃした古いバージョンのCityDeskが稼働しています。僕が何とかハックした揚げ句、このマシン上でしか動かなくなってしまったものです。お恥ずかしい限りです。 ところで Trello についての楽しい話もご紹介しましょう。もう皆さんもきっとご存じの通り、 Trello はFog Creekで開発した、すごいビジュアルプロジェクト管理システムです。 解説しましょう。言い伝え

    ジョエル・スポルスキによる『Trello, Inc.について』 | POSTD
  • 1