タグ付けされた質問 「front-end」

WPF開発者として、ユーザーインタラクションとアプリケーションのフロントエンドを明確に扱っていても、プラットフォームがWebではないためフロントエンドとは見なされないことに気づき、混乱しました。 デスクトップアプリケーションでは、Webのようにフロントエンドとバックエンド（それぞれUIとドメイン）が分離されていないと思っていました。ただし、多くのアプリケーションには、特に企業内でこの違いがあります。私が専門的に開発したデスクトップアプリケーションのほとんどは、Web APIによって提供および受信されるデータ用のデスクトップクライアントにすぎませんでした。この意味で、クライアントは非常にフロントエンドです。 では、この答え、「フロントエンドは」という作家の状態なければなりません「クライアント側」のに対し、ブラウザで実行は、デスクトップアプリケーションを潜在的に含めることができます。 では、なぜ「フロントエンド」はWeb開発のみに関係するのでしょうか。

9 web-development  front-end  professional-development  desktop-development 

私が作成したいMicroservicesすべてのmicroserviceは、フロントエンドの独自の一部を担当しているアプリケーションを、。同時に、AngularJSでフロントエンドをシングルページアプリケーション（SPA）として作成したいと考えています。新しいマイクロサービスがデプロイされると、Webフロントエンドは自動的に新しいフロントエンド部分を取得してSPAに追加します。これを実現する最良の方法は何でしょうか？ これが私が思いついたものです。各マイクロサービスは、独自のAngularモジュールを担当できます。次に、顧客がアプリケーションに移動すると、サーバーコンポーネント（ASP.NETまたはJSP）は、どのマイクロサービスがオンラインであるかを確認し、それらのマイクロサービスからの角度モジュールを含むHTMLページを作成できます。 フロントエンドコンポーネントが実行できることは、管理者やVIPの顧客など、拡張された特権を持つ特定の顧客に対していくつかのマイクロサービスを有効にすることです。 もちろん、これが機能するためには、各マイクロサービスが画面上に他のマイクロサービスが何であるかを「知る」ことなく、画面の一部を占めるための優れた構造化された方法が必要です。簡単な解決策は、マイクロサービスごとにタブを作成することです。タブでは、担当のマイクロサービスがその機能をページに配置できます。フロントエンドコンポーネントは、（角度）ルーティングやルックアンドフィールなどの一般的な要素を担当します。 これはこの目標を実現する最良の方法ですか？誰もがこれで経験がありますか？

9 angularjs  front-end  microservices 

この記事では、フロントエンドコードを整理するために取り組んできました。BEM / SMACSSの記事を参照し、次に他の記事を参照します。 私は本当にベストプラクティスが何であるかを理解しようとしています...私はこの "標準"を決定するために数日を持ち、それから高優先度/高可視性/限られたタイムラインプロジェクトを実行する必要があります。そのため、アプリと同じように拡張できる基盤から始めたいと思います。 segment... という名前のコンポーネントがあるとすると、segments1ページあたり最大10 個のページが作成されます。それぞれsegmentが同じ基本クラスを共有します。ただし、特定のものsegmentsには修飾子があります（異なる背景色）。さらに、（BEMアプローチの）各ブロック内の要素にも修飾子があります。実例を示すために、ここに簡単な実装を示します（単一の要素のみで、arrowサイト全体にはそれぞれ4〜5個の要素がありますsegment）。 .segment__arrow { position: absolute; bottom: -24px; left: 50%; margin-left: -11px; background-position: center no-repeat; height: 21px; width: 21px; z-index: 2; } .segment__arrow--orange { @extend .segment__arrow; background-image: url('/images/arrow_orange.png'); } .segment__arrow--white { @extend .segment__arrow; background-image: url('/images/arrow_white.png'); } したがって、これは単一クラスのアプローチです。 <div class="segment__arrow--white"> ... </div> または、マルチクラスアプローチを使用することもできます。 .segment__arrow { …

8 architecture  css  scalability  front-end 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 5年前休業。 私は最近、Web開発におけるさまざまな役割に応募し、アプローチされてきました。浮かび上がってきているのは、バックエンド開発よりもフロントエンド開発に適しているということです。デザイナーとしての私の背景を考えると、これは理にかなっています。 問題は、ExtJSを使用して大きなアプリに取り組んでいる間に、ExtJSでの設計と開発が本当に苛立たしいことに気づいたことです。奇妙なことに、私のコーディングスキルが一部の上級開発者に認められたため、このプロジェクトに取り組んでWeb開発に着手しました。私の履歴書でそれを強調していますが、これが間違いなのかどうか疑問に思います。 また、JavaScriptをWeb開発以外でもかなり使用しています。具体的には、PhotoscriptとInDesignでバッチ操作を作成します。私はJavaScriptの専門知識があると思われがちですが、私はJavaScriptのOOPスタイルに慣れているだけです。多くの手続き型コードを使用するか、jQueryやGoogleマップなどのライブラリを使用します。Nodeはバックエンドですが、NodeとKnockoutで実験的なアプリをいくつか作成しました。私はSEOに集中していたため、特定のWebプロジェクトではJavaScriptとjQueryを避けていましたが、本当に必要な場合にのみJavaScriptを使用していました。 インタビュー中に、JavaScriptとフロントエンド開発について質問されます。しかし、私は本当にPHPとサーバー側の開発について話したかったので、私は私の背景を示していると思います。役割について連絡を受けたとき、または空売りをせずに直接申請したときの対処方法を教えてください。

8 web-development  server-side  front-end 

ほとんどのWebサイトは、ロゴ画像などの静的アセットmax-age=31536000のCache-controlヘッダーを設定します（1年）。例： YouTube ヤフー ツイッター BBC ただし、注目すべき例外があります。Googleのロゴにはmax-age=6912008日間あります。 私は過去にGoogleロゴのヘッダーを確認しましたが、以前は間違いなく1年でした。（また、以前はスプライトの一部でしたが、現在はスタンドアロンのロゴ画像ですが、おそらく別の質問です...） キャッシュの有効期間をわずか8日間に減らしたいと思う正当な技術的理由は何でしょうか？Googleのホームページは、世界で最も慎重に最適化されたページの1つなので、正当な理由があると思います。 編集： 回答する前に、これらの点を理解しておいてください。 max-age静的アセットを将来変更できるようにするために、短いライフタイムを使用する人はいません。変更する場合は、別のURLで提供するだけです。いいえ、Google Doodleとは関係ありません。考えてみてください。GoogleがこのHTTPの基本的なトリックを理解していなかったとしても、元のロゴがキャッシュされていないユーザーだけがdoodle-dayにDoodleを目にするため、8日間は適切ではありません。そのユーザーグループは、GoogleがDoodleを変更してから8日間、Doodleを見続けていました:) Webサーバーはクライアント（またはプロキシ）のキャッシュを「いっぱいにする」ことを心配していません。クライアントは自分でこれを管理します。自身のストレージ制限に達すると、優先度が最も低いアイテムをドロップし始め、新しいアイテムのためのスペースを作ります。優先度スコアは、「このURLをキャッシュしたことによるメリットはどれくらいありますか？」という質問に基づいています。これはmax-age、URLが最初に要求されたときにサーバーが送信した値とは関係ありません。これは、「頻度」に基づくヒューリスティックです。そのURLに対するリクエストの数です。max-age単にサーバーがカットオフポイントを設定できるようにします。これは、アイテムが再利用される頻度に関係なく、クライアントがアイテムを破棄することになっている時間です。ダウンストリームのクライアント/プロキシがキャッシュをいっぱいにするのを「控え」に頼るのは、とてもいい信頼できることですが、私たちはその世界に住んでいるとは思いません;）

8 caching  http  front-end 

Webアプリケーションに、カスタマイズ可能なJavaScriptベースのスクロールバー（および一般的なスクロール機能、つまりコントロールをマウスのスクロールホイールにバインドする）を含めると、魅力的です。 しかし、私が見つけたすべての解決策は個人によって開発されました（正式なサポートや将来のサポートの欠如と同じです）。さらに、それらを使用している主流のサイトを覚えていない。 私の特定のケースでは、非JavaScriptまたはIE6 / odd-browser環境はサポートされることを意図していません。 今日、カスタムスクロールバーは避けるべきですか？そうでない場合、選択できる最良のオプションは何ですか？

8 web-development  front-end