タグ付けされた質問 「javascript」

ネイティブJavaScriptと比較した場合、jQueryの開発がどれほど簡単かを考えると、jQueryのようなライブラリを完全に見捨てる理由は何ですか？ これは、jQueryに制限があるのか​​、遅いのですか？つまり、jQueryがネイティブjavascriptと比べて非常に簡単な場合、人々はまだ純粋なjavascriptを使用しなければならない理由は何ですか？

33 javascript  jquery  web-development  web-applications  libraries 

質問はそれをすべて本当に言っています。サービスを提供したいのですが、自分でデータをデータベースに保存したくありません。ハッキングなどの最近のすべてのニュースで、クライアントがデータを完全に制御できる方が良いように思えます。 問題は、保存されているデータが潜在的に機密であるということです。私がやろうとしていたことは...クライアントがウェブサイトを訪れたときに、「あなたはパーソナルコンピューターか公共のコンピューターか」という質問がありました。公共のコンピューター上にある場合、サイトはアクセスを拒否します。 それらがパーソナルコンピュータ上にある場合、パスワードを設定するように求められます。すべてのデータは、このパスワードで暗号化されます。これは明らかに安全ではありません。暗号化方法はJavaScriptであり、パスワードはプレーンテキストであるため、経験豊富なユーザーがlocalStorageでパスワードを見つけてデータにアクセスすることは可能だと思います。 しかし、これはあまり問題ではないと感じています。あなたがパーソナルコンピュータを使用している場合、これが起こる可能性はわずかです...誰かがコンピュータ上の特定のユーザーアカウントにアクセスする必要があり、誰かがサイトについて知る必要があります...誰かが理解する必要がありますlocalStorageとそのアクセス方法。機密データは、身元を危険にさらすようなものではありません。これは、ほとんどの人が一般に公開したくないものを記録するだけです。 本当に問題なのは、localStorageは十分に安全なのか？ 追加の質問.. localStorageを消去するのはどれくらい難しいですか？ユーザーが誤ってデータを消去するのは望ましくありません。 最後に-サイトにアクセスできるパスワードを持っているかのように、データを暗号化/復号化する価値さえあります。

33 javascript  security 

ここでいくつかのコードを読んでいて、enumがhtmlタグの名前を保存するために使用されているのを見ました。なぜこれを行う必要があるのでしょうか？この戦略を使用するとどのようなメリットがありますか？ コンパイルされた言語または静的に型付けされた言語で列挙型がどのように役立つかは知っていますが、動的に型付けされた言語で列挙型を見ると、上記のコード例のように興味があります。それで、質問は基本的に、動的に型付けされた言語で列挙型が必要なのか、それともまったく必要なのか、ということです。

32 javascript  programming-practices  encapsulation  enum 

私は長い間Webプログラミングを行ってきましたが、どこかで、今日の仕事をしている理由を追跡できませんでした（または、どうしてこのように物事をするようになったのですか）。 私は基本的なASP Web開発から始めましたが、非常に早い段階で、ページ上でディスプレイとビジネスロジックが混在していました。クライアント側の開発は大きく異なり（VBScript、さまざまなJavaScriptの種類）、サーバー側の検証について多くの警告がありました（したがって、クライアント側のロジックからは遠ざかりました）。 その後、しばらくの間ColdFusionに移りました。ColdFusionはおそらく、タグを使用して表示ロジックとビジネスロジックを分離した最初のWeb開発フレームワークでした。私には非常にはっきりしているように見えましたが、非常に冗長であり、ColdFusionは市場の需要が高くなかったため、先に進みました。 その後、ASP.NETバンドワゴンに飛び乗り、MVCアプローチを使用し始めました。また、Javaはエンタープライズシステムの象牙の塔の言語であるように思われ、MVCアプローチも試しました。その後、ASP.NETはこのMVVM設計パターンを開発し、Java（正確にはJ2EEまたはJEE）も苦労し、MVC2アプローチを採用しました。 しかし、今日、私が発見したのは、バックエンドプログラミングではなく、興奮と進歩がそこにあるということです。また、サーバー側ベースのMVCプラクティスは時代遅れのようです（人々はもうJSTLを実際に使用していますか？）。今日、私が取り組んでいるほとんどのプロジェクトで、JavaScriptフレームワークとクライアント側の開発は、すべてのエキサイティングで革新的な進歩が行われている場所であることがわかりました。 サーバーからクライアント側の開発へのこの移行が行われたのはなぜですか？JEEプロジェクトの1つの単純な行カウントを行いましたが、JavaScriptにはJavaよりも多くのコード行があります（サードパーティライブラリを除く）。JavaやC＃などのプログラミング言語を使用したほとんどのバックエンド開発は、単にRESTのようなインターフェイスを作成することであり、表示、視覚化、データ入出力、ユーザーインタラクションなどのすべての苦労が対処されていることがわかりますAngular、Backbone、Ember、Knockoutなどのクライアント側フレームワーク経由 jQueryの前の時代に、n層開発のMVCのM、V、Cの間に明確な概念線があった多くの図を見ました。jQuery後、これらの線はどこに描かれますか？MVCとMVVMは、クライアント側のJavaScriptコードにすべて揃っているようです。 私が知りたいのは、なぜそのような移行をしたのですか（サーバー側プログラミングの強調からクライアント側へ、コンパイル言語の優先からスクリプト言語へ、命令型プログラミングから関数型プログラミングへ、これらはすべて同時に発生したようです） ）そして、この移行/シフトはどのような問題を解決しましたか？

32 design-patterns  javascript  programming-practices 

Python pip、Node npm、Ruby Gemsなどのパッケージマネージャーの利点は、アプリケーションパスにファイルを追加するだけではないため、十分に評価できます。 多分私はポイントを失っている、または私は鈍感であるが、ここに私が見ることができるネガティブがある： プロジェクトをビルドする際の別のステップ 別のパッケージマネージャー（yo dawg）を介してインストールする別個の依存関係 bower.jsonおよび/またはでプロジェクトのルートをより混乱させる.bowerrc レジストリが最新であり、正確であり、利用可能であることへの依存 画像などの一部のインポート/参照が機能しない npmと大きな重複があり、多くの場合、使用するリソースが不明です。 陽性私が見ることができるが、これらのとおりです。 依存関係を手動でダウンロードする必要はありません オプションで、ユーザープロンプトなどに基づいてスキャフォールディングの一部としてパッケージをインストールする 私は気付いていないメリットを知りたいのですが、私は本当に知りたいと思う挑発的なことをしようとしているのではないと言ってください。

32 javascript  front-end 

私は現在、スタートアップに関与しています。私は現時点で唯一の開発者です。他の人たちは、現時点ですべての技術決定を私に任せています。 私の日常業務では、Microsoft techを日常的に使用するソフトウェアハウスで仕事をしています。.NET、SqlServer、Windows Serverなどを利用しています。 Windowsのホスティングのコストを簡単に見てみると、専用サーバーの価格の一部を見てショックを受けました。一番安いのは月100ポンドでした。また、ビジネスを将来的に拡張する必要があり、複数のサーバーが必要になった場合、SQL Server / Windows Serverライセンスなどで年間10ポンドから1,000ポンドを払うことになります。 その後、専用サーバー用のLinuxホスティングの価格を簡単に見てみると、価格はWindowsホスティングよりもかなり低いことがわかりました。1つの場所では、2コアのマシンを月20ポンド未満で提供していました。 これにより、おそらくLinuxでのオープンソースの道を考えるようになりました。 仕事で多くのJavascriptを書いているので（現時点では単一ページのバックボーンアプリで作業しています）、NodeJSとExpressのようなWebフレームワークを使用するのがクールだと思いました。次に、SQLを使用する代わりに、NodeJSを強力にサポートするMongoDBのようなオープンソースのNoSQLデータベースを使用しないのはなぜだと思いましたか？ 私の唯一の懸念は、アプリケーションが行う作業の一部が動的に画像やその他の画像に関連するもの、つまり非常にCPUが重いものを作成することになることです。 Nodeのモジュールとして使用します。 これが背景ですが、基本的にLinuxは以下に適しています。 NodeJS / Expressサイトをホストしていますか？ C ++ノードモジュールのコンパイル？ MongoDBのようなNoSQL DBを使用していますか？ そして、これらのなじみのない技術に移行してお金を節約するのは良い考えですか？ 3か月の更新 私はここ数ヶ月間これに取り組んでいますので、誰かが興味を持っている場合に備えてアップデートを提供すると思いました。 最終的に、単純な理由でNodeJSとLinuxスタックを使用しないことにしました。私はこのスタートアップを脇でやっているので、9時間働いてから家に帰って遅くまで働いています。このように作業している間、私は明らかに自分の時間をできる限り効率的にする必要があります。そうしないと、製品を出荷できなくなります。 このスレッドに関するいくつかのアドバイスを受けた後、Microsoft BizSparkに応募し、受け入れられました。つまり、Visual Studioライセンス、Windows Serverライセンスなどにすべて無料でアクセスできます。それはすごいです。うまくいけば、それが問題にならないほど十分に引き継ぐすべての代金を支払う必要があります。 ただし、可能な限りオープンソースのものを使用しようとしたため、Microsoftの技術のみを使用しているとは思わないでください。これを行った主な場所は、PostgreSQLとMongoDBを使用することにしたデータレイヤーです。また、フロントエンドでBackboneJSを使用しています。 以下は、現在使用している技術/フレームワークの概要です。 標準DBスタッフ：PostreSQL ロギングとデータストア：MongoDB ORM：Entity Framework 5 コアライブラリ：.NET（C＃） Webフレームワーク：ASP.NET MVC3 UI：Razorビューエンジン/ BackboneJS

32 web-development  open-source  javascript  linux  startup 

私はほぼ10年間Web開発者であり、可能な限りJavaScriptを使用しないようにしようとする習慣になりました。ここではWebアプリの構築についてではなく、データベース駆動型のWebサイトについて述べています。 これは良い/尊敬されるアプローチですか？

32 javascript 

この講演のQ＆Aセクションで、Douglas Crockford氏は、jQueryは他の一般的なライブラリと同様に拡張できないと述べています。彼はそれによって何を意味し、他のライブラリをよりスケーラブルにするのは何ですか？

32 javascript  jquery  scalability 

これは非常に広範な質問であることを理解していますが、この問題のさまざまな側面を個別に扱っており、すべての概念と技術をまとめるのに苦労しています。 答えには次のテクノロジーを含めるように指定したいと思います。 C＃ MVC 3 w / Razor Javascript w / jQuery それ以上のもの（Backbone.js、Entity Frameworkなど）は、次の質問への回答に役立つ場合、提案として歓迎します。 上記のテクノロジーを使用して、スケーラビリティとリッチで高速でクリーンなUIを作成する能力を維持しながら、コードとロジックを整理するための最適な戦略は何ですか？ 理想的には、ビジネス/企業環境で展開されているソリューションに焦点を当てるべきです。その際、上記の技術リストは変更されないため、「現在使用しているyyyの代わりにxxxを使用する必要があります」というソリューションを提供しないでください。 バックグラウンド 私は毎日jQueryを使用しており、ASP.NETのMVCを採用しており、C＃で長い間作業しています。そのため、これらのテクノロジーに関する中級から上級の知識を前提としたソリューションを提示できます。 質問をより小さな部分に整理して、より簡単に回答できるようにします。 1.プロジェクトの構造 ASP.NET MVC（Visual Studio 2010）で作業していることを考えると、このタイプのアプリケーションのメインレイアウトをある程度受け入れられるディレクトリ構造ソリューションが必要です。ブランチのようなものだと思いますが、各フォルダーに含まれる内容と、アプリの他の領域との連携についてもう少し詳しく説明します。 2.データアクセス APIタイプの構造で、できる限りデータアクセスをモジュール化したいと思います。あなたはPOCOオブジェクト（多くの仮定することができUser、UserGroup、Customer、OrderHeader、OrderDetails、など）だけでなく、データ集約型SQLと慎重なUIのレンダリングを必要とするいくつかの複雑なレポートがあるでしょう。 EF + LINQは前者にとっては素晴らしいですが、後者にとってはそれほどではありません。私は、両方のシナリオに適合すると思われるものを、過度に複雑または過度に単純にすることなく見つけられません。 3.クライアント側のコード編成とUIレンダリング ほとんどの開発者が最初にjQueryを採用したように、どこに行く必要があるとしてもコードをまとめ上げるというtrapに陥りましたが、すぐにそれが積み重なってくなりました。以来、飛躍的に進歩していますが、コードを繰り返し実行せずにコードをモジュール化し、UIのさまざまな部分を操作するのに苦労しています。 例として、私が書くかもしれない典型的なコードは次のようになります。気になることはコメントしました（それ以降、遅延AJAX呼び出しの使用に変更し、実際のデータ要求をDOM操作から分離していることに注意してください）： $('#doSomethingDangerous').click(function () { // maybe confirm something first if (confirm('Are you sure you want to do this?')) { …

32 c#  javascript  jquery  asp.net-mvc-3 

たとえば、0、0.5、... 5のボタンのリストを表示し、0.5ごとにジャンプします。私はforループを使用してそれを行い、ボタンSTANDARD_LINEで異なる色を使用しています： var MAX=5.0; var DIFF=0.5 var STANDARD_LINE=1.5; for(var i=0;i<=MAX;i=i+DIFF){ button.text=i+''; if(i==STANDARD_LINE){ button.color='red'; } } この場合、IEEE 754では各値が正確であるため、丸めエラーはありませんが、浮動小数点の等価比較を避けるために変更する必要がある場合は苦労しています： var MAX=10; var STANDARD_LINE=3; for(var i=0;i<=MAX;i++){ button.text=i/2.0+''; if(i==STANDARD_LINE/2.0){ button.color='red'; } } 一方で、元のコードはよりシンプルで、私にとっては楽しみです。しかし、私が検討していることが1つあります。i== STANDARD_LINEはジュニアチームメイトを誤解させますか？浮動小数点数に丸め誤差がある可能性があるという事実を隠していますか？この投稿のコメントを読んだ後： https://stackoverflow.com/questions/33646148/is-hardcode-float-precise-if-it-can-be-represented-by-binary-format-in-ieee-754 一部の浮動小数点数が正確であることを知らない開発者が多いようです。私の場合、浮動小数点数の等価比較が有効であっても、避けるべきですか？または、私はこれについて考えすぎていますか？

31 javascript  coding-style  floating-point 

私がフロントエンドを持っていると仮定します。フロントエンドは、ほとんどが角ばった、うなり声、お辞儀を使って書かれた単一ページのアプリケーションです。そして、私がバックエンドを持っていると仮定します。ほとんどの場合、ORMの上に置かれたREST APIであり、データベースからオブジェクトを保存/取得し、うなり声、エクスプレス、シークライズなどを使用します。 角度のあるアプリケーションは、ユーザーに表示されるすべての視覚的な処理を行いますが、バックエンドによって提供されるサービスを介したGUIとして機能します。 これらを2つの異なるコードベースに分離し、独立した開発、バージョン管理、継続的統合、開発へのプッシュなどを可能にすることが望ましいでしょう。 私の質問は、これをきれいに行うための方法は何ですか？フルスタックJavaScriptの推奨ベストプラクティスはありますか？ オプション＃1はモノリス、つまり「それらを分離しない」ようです。利点は、ビルドチェーンがシンプルであり、すべてが1か所にあることですが、多くの欠点があるようです。個別にバージョン管理するのが難しく、前面が壊れていると、展開できない背面を意味します。 オプション＃2は準モノリスのようです。フロントエンドビルドチェーンにより、多数のファイルがバックエンドに書き込まれます。distフロントエンド上のディレクトリをするとき、フロントエンドminifies、uglifiesなどので、基本的に、バックエンドには、いくつかのディレクトリを参照することになり、それがすべてを実行し、バックエンドに公開してしまいます。 オプション＃3は完全に分離されているようです。フロントエンドとバックエンドはそれぞれ異なるポートで独自のサーバーを実行し、完全に独立したプロジェクトです。欠点は、互いのポートについて知るように設定する必要があるようです。バックエンドは、フロントエンドからのCORSを許可する必要があり、フロントエンドは、それらのすべてのエンドポイントが予想される場所を知る必要があります。 オプション＃4は、docker-composeなどを使用して、すべてをまとめてリグすることです。 私は他のオプションがあると確信しています。推奨されるベストプラクティスは何ですか？

31 architecture  javascript  node.js  front-end  backend 

アプリケーション用にJavaで柔軟なACLフレームワークを作成しようとしています。 多くのACLフレームワークはルールのホワイトリストに基づいて構築されています。ルールはowner：action：resourceの形式です。例えば、 「ジョンはリソースFOOBAR-1を表示できます」 「MARYはリソースFOOBAR-1を表示できます」 「MARYはリソースFOOBAR-1を編集できます」 これは、ルールをデータベースに簡単にシリアル化/永続化できるため魅力的です。しかし、私のアプリケーションには複雑なビジネスロジックがあります。例えば、 「5年以上の年功歴を持つ部門1のすべてのユーザーは、リソースFOOBAR-1を表示できます。それ以外の場合は承認されません」 「部門2のすべてのユーザーは、日付が2016年3月15日以降であれば、リソースFOOBAR-2を表示できます。それ以外の場合は許可されません」 最初に考えたとき、このような無限に複雑なルールを処理できるデータベーススキーマを考案するのは悪夢です。したがって、コンパイルされたアプリケーションにそれらを「焼き付け」、ユーザーごとに評価し、評価の結果としてowner：action：resourceルールを生成する必要があるように思えます。 コンパイルされたアプリケーションにロジックを焼き付けないようにします。 そのため、私はルールを述語：action：resourceの形式で表現することを考えていました。ここで、述語はユーザーが許可されるかどうかを決定するブール式です。述語は、JavaのRhinoエンジンで評価できるJavaScript式の文字列になります。例えば、 return user.getDept() == 1 && user.seniority > 5; そうすることで、述部をデータベースに簡単に永続化できます。 これは賢いですか？これはずさんですか？これはギミックですか？これは過剰に設計されていますか？これは安全ですか（明らかに、JavaはRhinoエンジンをサンドボックス化できます）。

30 java  javascript  scripting  permissions  access-control 

具体的には、JavaScriptで記述しています。 私の主な機能が機能Aであるとしましょう。機能Aが機能Bを複数回呼び出し、機能Bが他のどこでも使用されていない場合、機能A内に機能Bを配置するだけですか？ それは良い習慣ですか？または、関数Bを関数Aと同じスコープに配置する必要がありますか？

30 javascript  programming-practices  patterns-and-practices  encapsulation  scope 

私は、チームのためにJavaScriptスタイルガイドを作成しています。これにより、ドキュメントをより簡単に整理して投稿できます。しかし、私は私の質問が適用される場所である小さなバンプを打った... すぐに呼び出される匿名JavaScript関数を何と呼ぶべきでしょうか。単純に「匿名関数」と呼ぶことはできますが、すぐに呼び出されるという事実を強調したいと思います。 以下に例を示します。 var MyVariable = (function(data){ return "another value" })("some value"); console.log(MyVariable); // "another value"

29 javascript  coding-style  terminology 

要素を見つけ、データを保存し、イベントをリッスンするために、特定のセレクターにバインドされたJavascriptを見るのは非常に一般的です。これらの同じセレクターがスタイリングに使用されることもよく見られます。 jQuery（およびそのセレクターエンジンSizzle）は、CSSタイプの構文で要素を参照することにより、これをサポートおよび促進します。そのため、プロジェクトを構築するときに、この手法を「学習」（またはリファクタリング）することは特に困難です。 これはHTMLとJavascriptの開発の歴史の結果であり、この種のカップリングを効率的に消費/解析/レンダリングするためにブラウザーが構築されていることを理解するようになりました。しかし、Webサイトがますます複雑になるにつれて、この現実により、これらの個別のレイヤーを整理および維持するのが難しくなります。 私の質問は、これは現代のウェブサイトで回避できますか？ 私がフロントエンド開発に不慣れで、「正しい方法」で学習したい場合、そのような依存関係を最初から切り離して回避することを学ぶ価値はありますか？これは、より分離された構造を促進するライブラリを支持してjQueryを避けることを意味しますか？

29 javascript  html  css  jquery