ソフトウェア工学

私はCSの学生として、長年にわたってまともな数のプログラミング言語を学びました。そのほとんどは、「null可能」または「オプション」タイプの概念を持っています。ここでは、nullポインターや参照、JavaScriptのような弱く型付けされた言語については触れていませんnull。私が話していることの例には、boost::optional（C ++）、java.util.Optional（Java 8.0）、prelude.Maybe（Haskell）、およびすべての「？」種類（例えばint?、float?、C＃やKotlin）。これらは、厳密な静的型システム内で、以前はnullにすることができなかった型にnullの可能性を追加する構成体です。 SQLにも同様の概念があります。たとえば、INTEGERnull可能またはnull不可にできるような型ですが、ひねりがあります。SQLでは、INTEGERデフォルトでnull可能であり、null INTEGER NOT NULL不可になるように明示的に記述する必要があります。 NULLをデフォルトの動作にすることを許可することは非常に直観に反し、潜在的に危険であると私は思います。明らかに、SQLはこの時点で非常に長い間存在しており、（ほとんどの）SQL開発者はNULLの落とし穴について健全な認識を築いています。しかし、私は仕方がないのですが、初期の頃、NULLが予期せず問題のある場所に忍び込んでいたことを想像してみてください。 SQLは私が提供したすべての例よりも古いため、これは単に歴史的な進化の問題である可能性があります。それでも、私は尋ねなければなりません、言語がこのように設計され、型がデフォルトでnull可能であるという正当な理由はありますか？ もしそうなら、それは単なる歴史的な理由でしょうか、それとも今日のデータベース設計にロジックは耐えますか？ 編集：なぜNULLがSQLの一部であるのか、またはNULL可能列がなぜ有用なのかは尋ねていません。列がデフォルトで null可能である理由を尋ねています。たとえば、次のように書くのはなぜですか。 column1 FLOAT, column2 FLOAT NOT NULL のではなく： column1 FLOAT NULLABLE, column2 FLOAT

8 sql  language-design  null 

タイトルを少し拡張するために、他の関数またはクラスが依存する純粋な関数を明示的に宣言する（つまり注入する）必要があるかどうかについて、結論を出そうとしています。 それらが要求せずに純粋な関数を使用する場合、テスト可能性が低く、設計が悪い特定のコードはありますか？私は単純なものから純粋な機能の任意の種類のために、問題の結論に取得したいと思い、ネイティブ関数（例えばmax()、min()-言語に関係なく）今度は他の純粋な機能に暗黙的に依存してもよいことを習慣に、より複雑なもの。 通常の懸念は、一部のコードが依存関係を直接使用するだけの場合、それを単独でテストすることができない、つまり、あなたが黙って持ってきたものすべてを同時にテストすることです。しかし、これは、小さな関数ごとに実行する必要がある場合、かなりのボイラープレートを追加するので、これがまだ純粋な関数に当てはまるかどうか、なぜか、またはなぜそうでないのかと思います。

8 unit-testing  dependency-injection  pure-function 

グローバル変数を複数回宣言すると、コンパイラは警告を出力しません。 ただし、たとえば関数内でローカル変数を複数回宣言すると、gccコンパイラーはエラーを出力し、ファイルをコンパイルしません。（私はgccに関して質問しますが、これはより一般的な言語設計の質問であり、gccについての質問ではありません。他のコンパイラーが同様に動作する可能性があるためです）。 この動作の説明は何ですか？

8 c++  c  language-design  compiler  gcc 

私の個人的なプロジェクトでTDDを実践しようとしています。新しいテストを追加した後、既存の実装に基づいて最初から合格する場合の状況にどのように対処するのでしょうか。 一方では、新しいテストは、設計の追加のドキュメントと、想定外の偶発的な違反からの保護を提供します。 一方、コードを変更せずにテストに合格した場合は、実際に何をテストするかが「疑わしい」ものです。 基本的に、すでに実装された動作を主張するテストの正確さを確認するために何ができるでしょうか？

8 unit-testing  tdd 

Dockerには、ソフトウェア開発者の大規模なチーム（100）で私の職場の問題を解決する多くの可能性があり、私の職場の問題を解決するために使用されます。これも： 持つドッカーホストのクラスタを使用すると、上のジョブを実行できること 持つCIエージェントは、ドッキングウィンドウのイメージとして実行する必要があることとあなたが水平にスケールアップすることができますので、（とすべてのビルドが完全にクリーンで一貫していることを保証します） Android、JS、およびJavaビルド用のさまざまなエージェントの専門化 複数のコンテナーにまたがって並行してJUnitテストを実行する 以下のような開発ツール持つソナーとし、NPMJS で実行中の ドッキングウィンドウは、簡単にバージョン管理、チェックインとCIのパイプラインでそれらをアップグレードすることができますので（専用ホスト上に） フィードバックは私に戻ってきました： これがうまく機能していることはすばらしいことですが、Dockerエコシステムを理解することは、一部の人々にとって精神的な飛躍となります。dockerを本番環境で実行しないことはすでに確立されているため、このツールで人材をスキルアップすることに投資する理由はないと思います。 私の質問は、本番環境で使用しない場合に、ソフトウェア開発プロセスでdockerを使用する理由は何ですか？

8 production  docker  culture 

Pythonで変数を設定するとします。 five = 5 ブーム。これはどのように保存されていますか？コンパイラーまたはインタープリターはそれをそのような変数に入れますか？ varname = ["five"] varval = [5] これがどのように行われる場合、それはどこに保存されますか？これは永遠に続くようです。

8 compiler  variables  storage  languages  interpreters 

シングルトンパターンとそれがどのように「悪い」のかについては、クラスをテストするのが難しくなるので避けてきました。シングルトンを依存性注入に置き換える方法を説明した記事をいくつか読んだことがありますが、それは不必要に複雑に思えます。 これがもう少し詳しく私の問題です。私はReact Nativeを使用してモバイルアプリを構築しています。サーバーと通信し、データを取得し、データを投稿し、ログインを処理するRESTクライアントを作成します（ログイントークンを保存し、ログイン後にリクエストごとに送信します）。 私の最初の計画は、アプリが最初にログインに使用し、必要に応じて資格情報の送信を要求するシングルトンオブジェクト（RESTClient）を作成することでした。DIのアプローチは本当に複雑に思えます（おそらくDIを使用したことがないためです）が、このプロジェクトを最大限に活用して、ここで最善を尽くしたいと思います。提案やコメントは大歓迎です。 編集：私は今、自分の質問の言葉遣いが不十分であることに気づきました。RNでシングルトンパターンを回避する方法についてのガイダンスが必要でした。幸運にも、サミュエルは私が望んでいたような答えをくれました。私の問題は、シングルトンパターンを避けてDIを使用したかったのですが、React Nativeで実装するのは本当に複雑に思えました。さらに調査を行い、Reactsコンテキストシステムを使用して実装しました。 ここに興味のある人のために、私はそれをしました。私が言ったように、私はプロップのようなものであるRNのコンテキストを使用しましたが、それはすべてのコンポーネントに伝搬されます。 ルートコンポーネントでは、次のような必要な依存関係を提供します。 export default class Root extends Component { getChildContext() { restClient: new MyRestClient(); } render() {...} } Root.childContextTypes = {restClient: PropTypes.object}; これで、restClientは、ルートの下のすべてのコンポーネントで使用できます。このようにアクセスできます。 export default class Child extends Component { useRestClient() { this.context.restClient.getData(...); } render() {...} } Child.contextTypes = {restClient: PropTypes.object} これにより、オブジェクトの作成がロジックから効果的に離れ、RESTクライアントの実装がコンポーネントから切り離されます。

8 design-patterns  architecture  dependency-injection  singleton  react 

バンドルとミニファイはすべて最適化とページの読み込みを高速化することを目的としているため、スクリプトごとに1つのバンドルとスタイルごとに1つのバンドルを作成し、ビューごとに1つのバンドルを作成すると、ブラウザに必要なすべてのスクリプトとスタイルを読み込むことができます。最大で2つのリクエストを作成します。それでは、私が持っているとしましょう_Layout.cshtml、私は3つのJSファイルを必要な場所bootstrap.js、jquery.jsおよびいくつかのcustom1.js私は1つのバンドル、このようなものを作成することができます。 bundles.Add(new ScriptBundle("~/bundles/layout").Include( "~/Scripts/bootstrap.js", "~/Scripts/jquery.js", "~/Scripts/custom1.js")); その後の私は別のビューとしましょうUser.cshtml、私は必要bootstrap.js、jquery.jsとcustom2.js、再び私は1つのバンドルを作成します。 bundles.Add(new ScriptBundle("~/bundles/user").Include( "~/Scripts/bootstrap.js", "~/Scripts/jquery.js", "~/Scripts/custom2.js")); 同じアプローチをスタイルバンドルに使用できます。しかし、私が見るところによると、このように行うことは一般的な習慣ではありません。通常、バンドルはタイプベースで作成されます。たとえば、1つはブートストラップ用、1つはjquery用、1つはカスタムjs / cssファイル用などです。バンドルが多いほどサーバーへのリクエストが多くなるため、ページの読み込み時間。また、最初に説明した方法で問題を解決することは何ですか？

8 asp.net-mvc  bundling  minify 

概要：密接に相互依存する値間での情報の重複を減らすための優れた設計パターンはありますか？ 私の仕事では、他の数量を知っている場合に数量の1つを導出できるような数量間の関係があることはかなり一般的です。理想的なガスの法則がその例です。 Pv = RT 理想的なガスの状態を表すクラスを作成することを想像できます。クラスは当然、3つの特性を有するであろうPressure、TemperatureとSpecificVolume適切な種類のそれぞれ。 このクラスのオブジェクトのユーザーのために、あなたが両方の値を設定している場合ことを期待するのが自然と思われるPressureとTemperature、あなたはその後の値を読み出すことができSpecificVolume、オブジェクトがあなたのためのことを計算していることを期待しています。 同様に、との両方に値を設定するPressureとSpecificVolume、を読み取ることができますTemperature。 ただし、このクラスを実際に実装するには、情報の重複が必要です。方程式のすべてのバリエーションを明示的にプログラムし、それぞれの場合に異なる変数を従属変数として扱う必要があります。 T = P * v / R P = R * T / v v = R * T / P これはDRYの原則に違反しているようです。それぞれが同じ関係を表していますが、これらのケースには独立したコーディングとテストが必要です。 実際のケースでは、私が考えているロジックはこの例よりも複雑ですが、同じ基本的な問題を示しています。したがって、ロジックを1回だけ、または少なくともより少ない回数で表現できれば、真の価値があります。 このようなクラスは、値が読み取られる前に適切に初期化されていることも確認する必要があることに注意してください。ただし、これは2番目の考慮事項です。 数学的例を挙げましたが、問題はデータ間の数学的関係だけに限定されません。これは、ポイントを説明するための簡単な例のように思われました。

8 design-patterns 

私はかんばんについて少し読んでいますが、要件のトピックについて少し混乱しています。 現在のプロジェクトでは、スクラムを使用しています。スプリントの最初に、BAがストーリーのウォークスルーを行い、彼女ができる限りそれを説明するセッションがあります。次に、その話を取り、レビューし、話し合い、BAに次のスプリント計画セッションのための質問を準備します。次のセッションでは、BAがすべての質問に答え、セッションは要件を理解した（ほとんどの場合）ことで終了します。 次のステップは、技術設計を作成し、ソリューション/ストーリーを開発することです。 かんばんに関​​して、私が読んだすべては、かんばんにはスプリント計画がないことを示唆しています。私の質問は、技術の要員とビジネスマンが一緒に座って（カンバンで）ストーリーの要件について話し合うときですか？プロダクトマネージャーまたはBAは、カンバンのストーリーのウォークスルーを提供しませんか？ スクラムを使用すると、BAは通常、スプリント全体で開発をサポートするために使用でき、かんばんと同じだと思います。カンバンでは、スプリントの計画がない場合、技術者はどのようにストーリーを理解するのかはわかりません。

8 agile  requirements  kanban 

私はRest APIを開発していて、自分自身に質問しています。 たとえばファイルのアップロードのために、base64でエンコードされたデータをJsonに配置することは良い考えですか？何base64ではいくつかの含まれている場合は{、}、:文字や休憩JSONコンテンツを？ 良いアイデアではない場合、ベストプラクティスとして広く考えられている選択肢はどれですか。

8 rest  json  file-handling 

存続期間の短いアクセストークンと存続期間の長いリフレッシュトークンを使用して、REST APIのトークンベースの認証システムを実装しています。これは、関連するAPIエンドポイントの抽象的な概要です（HTTPSはすべてのエンドポイントに適用されます）。 エンドポイント： POST /register/ POST /login/ POST /logout/ POST /password/change/ 実装： POST /register/： リクエスト：クライアントがユーザー名、メール、パスワードをJSONで送信します。 サーバーアクション： 入力を検証し、データベースにユーザーを作成します（ユーザーID、ユーザー名、電子メール、パスワードハッシュを格納します）。 JWT形式で短期間有効なアクセストークンを作成します（ユーザーID、発行日、有効期限が含まれます）。 長期間有効な更新トークンをUUID文字列として作成し、データベースに保存します（ユーザーIDと更新トークンを保存します）。 応答：サーバーはJSONでアクセストークンと更新トークンを返します。 POST /login/： リクエスト：クライアントはJSONでユーザー名とパスワードを送信します。 サーバーアクション： 入力を検証し、データベースをチェックして資格情報が有効かどうかをチェックします。 資格情報が有効な場合、前述のように、有効期間が短いアクセストークンと有効期間が長いリフレッシュトークンを作成します。 レスポンス：と同じで/register/、アクセストークンと更新トークンをJSONで返します。 POST /logout/： 要求：クライアントはヘッダー内の更新トークンをトークンAuthorizationとして送信しBearerます。 サーバーアクション： 更新トークンデータベースをチェックして、更新トークンを検証します。 データベースから更新トークンを削除します。 注：これにより、アクセストークンは有効なままになりますが、有効期間は短いため（1時間程度なので、問題ないはずです）。 応答：ログアウト要求がJSONで正常に処理されたかどうかを返します。 POST /password/change/： リクエスト：クライアントはアクセストークンをAuthorizationヘッダーとしてBearerトークンとして送信し、古いパスワードと新しいパスワードをHTTPS経由でJSONで送信します。 サーバーアクション： アクセストークンをデコードしてユーザーを取得し、ユーザーの古いパスワードをデータベースで確認します。 データベース内のユーザーのパスワードハッシュを新しいパスワードのハッシュに設定します。 リフレッシュトークンデータベース内のユーザーに関連付けられたすべてのリフレッシュトークンを削除して、基本的に既存のセッションをログアウトします（有効期間の短いアクセストークンを残します）。 応答：パスワード変更リクエストがJSONで正常に処理されたかどうかを返します。 質問： このアプローチは安全ですか？具体的には： HTTPSを介して行われる場合、JSONを介したユーザー名とパスワードの送信は安全ですか？無許可のドメインがこのエンドポイントに電話をかけることをどのように防ぐことができますか？さらに、プログラムによるログインを防ぐにはどうすればよいですか？ 更新トークンをデータベースに保存する前にハッシュ化する必要がありますか、それとも単なる偏執狂ですか？ クライアントがWebブラウザーの場合、更新トークンをクライアントに安全に保存するにはどうすればよいですか？ リフレッシュトークンを保存するための1つのアイデアは、ユーザーがログインすると、リフレッシュトークンをクライアントに送信するだけでなく、サーバーがトークンをフラグHttpOnly付きのCookieに保存することsecureです。承認は引き続きAuthorizationヘッダーを介して行われますが、クライアントが最初に読み込まれるときにGET、Cookieに有効な更新トークンが含まれているかどうかを確認するリクエストをエンドポイントに送信でき、有効な更新トークンが含まれている場合はJSONでユーザーに返します。つまり、Cookieが実際に使用されるのは、Cookie内の更新トークンをクライアントに返すときだけです。このアプローチは安全ですか？Cookieからリフレッシュトークンを要求するときに副作用がないため、CSRFを防ぐことができると思いますが、攻撃者がリフレッシュトークンを傍受する別の方法があります（HTTPSを想定）？

8 design  rest  api  security  authentication 

プロセスの存続期間中実行し続けるデーモンスレッドを生成するオブジェクトが必要です。議論のために、それは組み込みシステムのスレッドであり、いくつかの診断ポートでコマンドを受信して​​処理するのを待機しているとしましょう。しかし、それは本当に何でもあり得ます。主なアイデアは、長期間にわたって何かを見ているということです。一連のタスクを実行していません。 一般的なJavaの知恵によると、「インスタンス化しないThreadでくださいExecutorService。代わりに使用してください」です。（例えば、この答えを見てください）しかし、利点は何ですか？単一の長期実行スレッドを作成する手段としてスレッドプールを使用しても、意味がないようです。私がこれを書いた場合よりどのように良いでしょうか？ class Foobar { public Foobar() { this.threadFactory = Executors.defaultThreadFactory(); ... } public Foobar(ThreadFactory threadFactory) { this.threadFactory = threadFactory; ... } public void start() { fooThread = threadFactory.newThread(new Runnable() { ... }); fooThread.setDaemon(true); fooThread.start(); } ... } 注：この質問は私の質問に似ていますが、答えはスレッドプールの使用方法のみを示し、理由は述べていません。

8 java  design  multithreading 

スプリントの真ん中にある毎日のスタンドアップミーティング中に、デファクトプロジェクトマネージャー/スクラムマスターは通常、開発者に次のバージョンを尋ねます。 「それで、これはいつ行われるのですか？」 「では、今日の午後4時までにこのタスクを完了させることはできますか？」 「このサブタスクには何時間残っていますか？」 これは率直に言って非常に迷惑であり、物事をより速く終わらせません。その結果、開発者は多くのプレッシャーにさらされていると感じることが多く、スタンドアップはコラボレーションよりも戦場のように感じることがよくあります。 開発者として、これを処理する確かな方法は何ですか？

8 agile  scrum  user-story  sdlc 

アカデミックタスク…最初に.html、さまざまな行政区分での選挙結果を示す一連の静的ファイルを生成するように指示されました。次に、Djangoテンプレートを使用してこれを「近代化」するように指示されました。十分に公正で、私はそのようなアプローチの利点を見ることができます。 しかし、アプリを「RESTful」にすることで、これをさらに「mordernize」するように言われました。私の知る限り、これはサーバーがクライアントにJSON形式の生データを送信することでリクエストに応答するAPIのみを公開できることを意味します。静的なHTML + CSS + JSサイトであるクライアントは、このJSONを受信し、JavaScriptを使用してブラウザー側で動的にWebページを構築する必要があります。 悲しいことにいくつかの講義を欠場したので、これが説明されたはずですが、そのようなアプローチの利点は誰にでも説明できますか？私は欠点しか見ることができないと言わなければならないので： JavaScriptが無効になっているユーザーは、ページを表示できません。 私が間違っている場合は修正してください。ただし、このようなサイトのコンテンツはGoogleでインデックスに登録することができません。 ユーザーが特定の部門の選挙結果をブックマークすることは不可能です。代わりに、サイドにアクセスするたびに、クリックして特定の部門の結果をJavaScriptに読み込ませる必要があります。または、これを行うSeleniumボットをデプロイします。 ブラウザのボタンを元に戻す/進む。

8 rest