タグ

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

  • フロントエンドパフォーマンスのチェックリスト2021年版(PDF、Apple Pages、MS Word)-後編 | POSTD

    目次# 前編 準備段階:計画と指標 パフォーマンスを重視する文化、Core Web Vitals、パフォーマンスのプロファイル、CrUX、Lighthouse、FID、TTI、CLS、端末。 現実的な目標の設定 パフォーマンスバジェット、パフォーマンス目標、RAILフレームワーク、170KB/30KBバジェット。 環境の定義 フレームワークの選択、パフォーマンスコストの基準設定、Webpack、依存関係、CDN、フロントエンドアーキテクチャ、CSR、SSR、CSR + SSR、静的レンダリング、プリレンダリング、PRPLパターン。 中編 アセットの最適化 Brotli、AVIF、WebP、レスポンシブ画像、AV1、アダプティブメディア読み込み、動画圧縮、WebフォントGoogleフォント。 ビルドの最適化 JavaScriptモジュール、モジュール/ノーモジュールのパターン、ツリーシェイ

    フロントエンドパフォーマンスのチェックリスト2021年版(PDF、Apple Pages、MS Word)-後編 | POSTD
    nikuyoshi
    nikuyoshi 2023/07/24
  • 処理速度の遅いcurrentTimeMillis() – 前編 | POSTD

    今日はJavaライブラリの中でも非常に基的でよく使われるメソッド、 System.currentTimeMillis() を見ていきましょう。 このメソッドはミリ秒単位の精度で現在時刻を知らせます。このことから、このメソッドの処理能力は重要ではないと思う人もいるかもしれません。計測間隔が100ミリ秒や500ミリ秒なのであれば、現在時刻を取得するのに0.1や0.2ミリ秒かかったからといって誰も気にしないでしょう。しかし、やはり頻繁にこのメソッドを呼び出したいケースがありそうです。下記に例を挙げます。 異常に長い実行時間を検知し知らせる場合。例えば、HTTPリクエストを実行するのにかかる時間を計測するケースを考えます。この場合、1ミリ秒以下が計測されると思われることでしょうが、実際にはこのメソッドを使えばゼロが出力されることに注意して下さい。しかし時間が異常に長い(例えば100ミリ秒以上)場

    処理速度の遅いcurrentTimeMillis() – 前編 | POSTD
  • Dockerの本番運用 | POSTD

    以前に私が書いた「 Docker番運用:失敗の歴史) 」という記事は、非常に多くの反響を呼びました。 その後、長い議論を交わして、何百件ものフィードバックや何千件ものコメントを読み、さまざまな人々や主要事業者とも顔を合わせました。Dockerでの試みが増えるほど、その失敗談は増えていきます。そうした現状を、今回アップデートしておきたいと思います。 この記事では、最近の交流や記事から得た教訓を紹介しますが、その前に簡単におさらいをして軽く背景を説明しましょう。 免責事項:対象読者 たくさんのコメントから、世の中には10種類の人々が存在するということが明らかになりました。 1) アマチュア 実際のユーザがいない試用版のプロジェクトやサイドプロジェクトを実行している人々です。Ubuntuのベータ版を使用するのが当然だと考えており、「安定したもの」は古いものと見なすようなタイプです。 注釈:書

    Dockerの本番運用 | POSTD
  • curlとWgetの比較 | POSTD

    curlとWgetの主な違いについて著者(Daniel Stenberg)の私見を述べています。自分の子どもとも言える curl をひいきしていますが、 Wget にも携わっているので、思い入れがないわけではありません。 この記事に関するご感想やご意見をお寄せください。 問題点や改善点があると思われる場合は、 Issueやpull-requestを発行 してください。 共通点 FTPやHTTP、HTTPSからコンテンツをダウンロードできるコマンドラインツールです。 HTTP POSTリクエストを送信できます。 HTTPクッキーをサポートしています。 スクリプトの中で使用したりできるよう、ユーザインタラクションがなくても動作するようにデザインされています。 完全なオープンソースで、無料のソフトウェアです。 開発プロジェクトとして90年代に立ち上げられました。 metalink をサポートして

    curlとWgetの比較 | POSTD
  • Lispのアイデア | POSTD

    Lispと聞くと、冷蔵庫のような大きいサイズのコンピュータや、大文字のアルファベット文字列や括弧の並びといったような過去の時代のことが頭に浮かびます。そう、非常に多くの括弧。何故、オブジェクト指向プログラミングの作成者たちは、そんなにもLispの アイデア に魅了されるのでしょうか。そしてまた、アイデアとされるプログラミング言語というものは、どうやったら説明できるでしょうか。こうしたことを教えてくれなかったコンピュータ科学の教育を責めるべきでしょうか。 Lispは、John McCarthyが書いた Recursive Functions of Symbolic Expressions and Their Interpretation by Machines, Part I という論文によって、初めて世界に登場しました。その中で、McCarthyはプログラミングに新しい多くのアイデアを導入

    Lispのアイデア | POSTD
  • イベントループなしでのハイパフォーマンス – C10K問題へのGoの回答 | POSTD

    この投稿は、私が去年OSCONで行ったプレゼンテーションを基に作成しています。プレゼンよりは簡潔に編集し直し、プレゼン後にいただいたいくつかのフィードバックに応える形で記事を書いています。 Go言語に関してよく言われるのは、Go言語はサーバでうまく機能し、静的なバイナリや強力な並行処理、高いパフォーマンスを見せくれるということです。 この投稿では、その後半の2つの項目に関して焦点を当てます。プログラマとってGo言語とそのランタイムは、スケーラブルなネットワークサーバをスレッド管理やブロッキングI/Oを気にせずに書くのにどんなに有効かを説明していきます。 効率的なプログラミング言語に関しての議論 技術的な話に入る前に、Go言語をターゲットにしたマーケットを説明する2つの議論に関してお話したいと思います。 ムーアの法則 画像は以下より引用; 2005年5月にHerb Sutter氏が書いたDr

    イベントループなしでのハイパフォーマンス – C10K問題へのGoの回答 | POSTD
  • HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD

    HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた?よし、それなら 200 を返しましょう。ページが存在しない?それなら 404 です。他のページにユーザをリダイレクトしたい? 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳:HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200

    HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
  • プログラマ能力指標表 | POSTD

    2015年05月27日: 表が見にくいというご意見を頂いたため、原文著者に連絡のうえ体裁を修正しました。 上位のレベルには下位のレベルの知識も蓄積されているということに注意してください。つまり、レベル n であれば n より低いレベルの知識も全てあります。 コンピュータサイエンス データ構造

    プログラマ能力指標表 | POSTD
  • JavaScriptのデバッグ方法 – JSを嫌いにならないためのTips | POSTD

    この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり:私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ

    JavaScriptのデバッグ方法 – JSを嫌いにならないためのTips | POSTD
  • 開発者の仕事が遅いわけではない!納期が遅れるホントの原因 | POSTD

    “なぜ納期を守れなかったのだろうか?” 我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は当に開発者の仕事が遅いせいでしょうか? Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと(S、M、L、XL)、また種類ごと(ストーリー、テスト、バグ)に、完了までにどれくらいの期間がかかるかを追跡しています。 当社が調査した動向について 1点目:開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目:変動があるのは、ほとんどがチケットが開始される前(SomedayからBacklogまで)の段階です。これは、関係者が仕様を理解して作業の優先順位

    開発者の仕事が遅いわけではない!納期が遅れるホントの原因 | POSTD
    nikuyoshi
    nikuyoshi 2015/01/19
  • ソフトウェアエンジニアがたどる成長過程と失敗の行きつく先 | POSTD

    これからご紹介する私の試みはなかなか難しい側面があり、物議をかもすかもしれません。また、お見せするのは初めてなので完璧とは言えないかもしれません。私はソフトウェアエンジニアのスキルとその影響力を評価するシステムを開発しようとしています。少なくとも、プログラマが成長していく理想的な成長過程を大まかに描いてみようと思います。評価スコアは0.0から3.0まであり、それぞれの数字は専門能力を開発していく際の出発点を表しています。 このシステムは主にビジネスの観点から見た、ソフトウェア業界が求めるものに基づく 実務的な スケールです。数学的な才能や高速アルゴリズムを書く能力、Linuxカーネルの内部構造に関するプログラマの理解の深さなどを評価するスケールではありません。もちろんこうした能力は重要ですし、通常、エンジニアのスキルとともに伸びていく能力ですが、私のシステムが焦点を当てたいのはそこではあり

    ソフトウェアエンジニアがたどる成長過程と失敗の行きつく先 | POSTD
  • 就職面接でプログラムの解読を求められた! | POSTD

    長文ですが、よかったら読んでください。 就職面接でプログラムの解読を求められました。そして、就職が決まりました。 皆さん、こんにちは。新しいブログを開設したので、私は今とても張り切っています。週に何度か記事を投稿するつもりです。 タイトルを見れば大体の話の内容は分かると思いますが、これから書くのは、トルコのアンカラで受けた就職面接の話です。 私が応募した職は「ソフトウェアセキュリティエンジニア」でした。面接中、面接官たちは非常に専門性が低い質問をしてきましたが、分かることもあれば分からないこともありました。 その後、その企業からメールが届き、保護および暗号化されたバイナリファイルが添付されていました(「解読してみろ」ということでしょう)。 帰宅後にファイルをダウンロードすると、ファイルを開くために聞かれたのはパスワードだけでした。面接官が私に課した課題は、そのパスワードを探すことでした。

    就職面接でプログラムの解読を求められた! | POSTD
  • 優れたエンジニアを採用できないワケ | POSTD

    あなたは技術者採用の面接が苦手ですね。そう、あなたですよ。間違ったスキルを探し求め、適正の無い人たちを採用して、自分自身と会社に悪い影響を与えているのです。応募者リストを見直さなくとも、今までとは違う人材を採用し、会社の業績を上げ、あなた自身も仕事をもっと楽しめるようになりますよ。 いささか大胆な物言いだということは承知しています。仕事での経験を積み面接を担当するようになってから10年、大小の企業の様々な部署で、技術者を雇うための数多くの面接をしてきました。採用する人材が会社に及ぼす影響についても見てきました。完璧な採用を目指せというつもりはありません。私自身がこれまで何度もしてきたあらゆる失敗をあなたが犯さなくても済むよう、お伝えしたいのです。私がこれまで学んできたことは次のようなことです。 誤った判断基準 1. 応募者の現時点の知識に基づいて採用しない 面接で犯しがちな最初の間違いは、

    優れたエンジニアを採用できないワケ | POSTD
  • プログラマとして30年以上の経験から得た教訓 | POSTD

    私は、プログラマとして30年以上仕事をしてきた中で、学んだことがあります。そのいくつかを以下にご紹介します。もっと挙げることもできますよ。 実物を見せないと、顧客の希望は分からない。 このことは最初の仕事で学びました。顧客は、実物を見るまでは、何が当に必要なのかがよく分かりません。言葉で長々と説明するよりも、機能検証のためのプロトタイプを提示する方が確実に役立ちます。 十分な時間があれば、あらゆるセキュリティは破られる。 現代社会において、セキュリティを保つことは信じられないほどの難題となっています。プログラマは常に完璧を求められますが、ハッカーは1回でもハッキングができれば成功なのです。 セキュリティが破られた場合、事前にその状況に備えた対策を講じているかどうかで結果が変わってくる。 最終的にセキュリティが破られることを想定する場合、その時に起こることに備えて対策を立てておく必要があり

    プログラマとして30年以上の経験から得た教訓 | POSTD
    nikuyoshi
    nikuyoshi 2014/10/05
  • あなたは全部知っていますか?プログラミングの業界用語30選 | POSTD

    Stack Overflowは、私が学習に役立ててきた多くのオンライン・コミュニティと同じように、自然と厳しくなってきました。第一にこれは、自己防衛機能です。子どもが初めて学校や託児所に入ると広大な世界にさらされて、 髄膜炎菌症を発症 して日々くしゃみやせきを繰り返しながら成長するのと同じような免疫システムです。常に好ましいことだとは言い難いですが、生き残るためには必要なプロセスなのです。 2年前に投稿された、下記の質問のことを考えてみてください。 あなたが新しく作ったプログラミングの業界用語は何ですか? あなたが作り、あなたの周りで使われるようになった、プログラミングの用語は何ですか?(他の人が真似して使っているのを聞いた、など)あなた独自の言い方が、職場内でのみ使われていたり、インターネット上で幅広く普及していたりすることもあるでしょう。 独自のプログラミングの用語、単語、言い回しを太

    あなたは全部知っていますか?プログラミングの業界用語30選 | POSTD
  • ある中級プログラマの告白 | POSTD

    私は中級レベルのプログラマです。 基を理解するのは得意です。過去の失敗をきちんと分析できるくらい経験を重ねていますし、もっと知るべきことは山ほどあることも分かっています。 特筆すべきは、自分で身につけるべきことを知ったうえで、それを吸収しようと積極的かつ精力的に取り組んでいる点でしょう。 プログラマとしての能力は平均的なものに過ぎないと、心から納得するまで時間がかかりました。今では、よく理解できないままに誰かの意見を受け売りする必要など感じていません。知らないことがあっても、それを他人に悟られるのは怖くありません。 でも以前は違いました。信じられないかもしれませんが、私はかつてプログラミングの達人だったのです。 自分の能力を誤って評価していたのは、比較的孤独な環境でスキルを学んだためでしょう。当時はコンピュータを持っていることさえ、ちょっと特別なことでした。使い方を知っているとなれば、な

    ある中級プログラマの告白 | POSTD
    nikuyoshi
    nikuyoshi 2014/07/03
  • 1