ソフトウェア工学

「シングルページ」Webアプリケーションを構築するためのサイドプロジェクトを開始します。アプリケーションはリアルタイムである必要があり、変更が発生するとクライアントに更新を送信します。 これらの種類のアプリケーションのアーキテクチャに関するベストプラクティスアプローチに役立つリソースはありますか。私がこれまでに見つけた最高のリソースは、ここではtrelloアーキテクチャの記事です：http://blog.fogcreek.com/the-trello-tech-stack/ 私にとって、このアーキテクチャは非常にセクシーですが、おそらく私の特定のニーズのために過剰に設計されています-私は同様の要件を持っていますが。サーバー側でサブ/パブに煩わされる必要があるかどうか、私は何かが起こったときにサーバーから更新をプッシュするだけではいけないのかと思っていますクライアントに更新を送信します）。 技術的には、おそらくNode.JSまたはRubyでこれを構築しようと考えていますが、アーキテクチャのガイドラインは、基礎となるサーバーテクノロジーにある程度適用されるはずです。

12 architecture  web-applications 

クロスプラットフォームアプリケーションを作成します。これには、デスクトップアプリケーション（Windows、iOS、Linux）がサーバーと通信し、ユーザーデータの同期を維持するWebサイトもあります。 これまでのところ、私が見るオプションは次のとおりです。 3つのOSごとにネイティブGUIを作成します。したがって、3つのGUIコードベース（および単一のバックエンドシステム）があります。 GTKのようなものを使用して、言及されたすべてのプラットフォームで1つのシステムをサポートできるようにします。 しかし、多くの情報を見つけることができなかった3番目（C＃と.Netにまだ慣れていないので正しい用語を検索していないかもしれません）は、組み込みのWebKitインスタンスが組み込まれたウィンドウを持つことです、ウェブサイトに使用するのと同じGUIシステムを使用できます。これにより、クライアントアプリとWebサイトができるだけ近くに表示されるため、ユーザーはインターフェイスに精通しています。 WebKitのこの最後のオプションはもっともらしいですか？私はすでにJavaScript / HTMLをよく知っているので、その知識を使用してインターフェースを作成できれば、それは素晴らしいことです。また、ユーザーがプラグインを使用してインターフェイスをカスタマイズできるようにする優れた方法であり、ローカルからWebへのUI設定の同期を維持できます。

12 c#  .net  javascript  gui  mono 

スプリントに割り当てられたストーリーを完成させるための態度はどうあるべきですか？明らかに、あなたはそれらをスプリントで終わらせることを優先したいのですが、私にとってアジャイルのポイントは動的であるということです。予想外のことが起こり、それらのストーリーが完了せず、次のスプリントにプッシュされるのと同じ時間に、何か間違ったことをしたという感覚は望みません。それは怖い経験やネガティブな経験ではないはずですよね？ 負けた/怖い経験は、逃したスプリントのコミットメントに受け入れられますか？開発者は、対処しなければならない予期しないタスクが発生した場合に、スプリントのコミットメントを逃したことに対して責任を負うべきですか？

12 agile  sprint 

オープンソースプロジェクトで何度か発生した状況は次のようになります。 デプロイメントにバグがあり、簡単なハックパッチを見つけました。（たとえば、実際に必要のないコードをコメントアウトするだけです。） 実際のバグを把握し、パッチを作成し、Gitプルリクエストなどを介してそれを送信するために、少しの余分な努力を費やしています。 プルリクエストは拒否されます。おそらくパッチは不完全で（たとえば、あるべきではない行が含まれていた）、コーディングスタイルに違反していたか、おそらく他の影響がありました。または、Gitで何か間違ったことをした可能性があります-プルリクエストはリベースされるか、何かでした。メンテナーは、パッチを改善する方法についてのフィードバックを提供し、再送信を要求します。 この時点で、私はどこまで進むべきかについて混乱しています。心配する限り、問題はありません。手順1で修正しました。問題を報告しました。他の人のために修正するための措置を講じました。しかし、それが「私の」プルリクエストだとは思わないので、パッチを改善する責任は私にあるとは思わない。 私を悩ませる特定の状況の1つは、パッチの失敗について議論した後、正しいパッチが何であるか（つまり、コードのすべての行を含む）のメーリングリストで合意に達することです。その後、実際にパッチを生成して送信するのは私の責任であると考えられています。 これらの状況に標準的なエチケットはありますか？それらはどのように解決されますか？私の反応は異常ですか？バグ修正をどこまで受け入れられるのでしょうか？ （「オープンソースプロジェクト」と言うとき、これらのいくつかは非常に小さいですが、趣味ではないかもしれません-開発者のリソースをそれらに取り組むことをコミットするいくつかの組織に役立つ単純なソフトウェアプロジェクトです。 「パッチを修正して再送信する」ということは、雇用主にとって有益なものに取り組む責任があることを理解してください。私たちに影響しないバグの修正に時間を費やすことは間違っているでしょう...）

12 open-source  etiquette  bug-report  software-patches 

最近、使用しているOSSの抽象基本クラスを更新して、仮想化することでテストしやすくしました（2つを組み合わせたインターフェイスを使用できませんでした）。これにより、仮想に必要なすべてのメソッドをマークするか、すべてのパブリックメソッド/プロパティを仮想にマークする必要があるかを考えるようになりました。私は一般的に、すべての方法を仮想化する必要があるというロイ・オセロベに同意しますが、これが必要かどうかについて考えさせられるこの記事に出会いました。ただし、簡単にするためにこれを抽象クラスに限定します（具体的なパブリックメソッドがすべて仮想であるべきかどうかは、特に議論の余地があります）。 サブクラスがメソッドを使用できるようにするが、実装をオーバーライドしたくない場所を確認できました。しかし、リスコフの代替原則に従うことを信頼している限り、オーバーライドすることを許可しないのはなぜですか？抽象としてマークすることで、とにかく特定のオーバーライドを強制しているので、抽象クラス内のすべてのパブリックメソッドは実際に仮想としてマークする必要があるように思えます。 しかし、私が考えていないかもしれない何かがある場合に備えて尋ねたいと思いました。抽象クラス内のすべてのパブリックメソッドを仮想化する必要がありますか？

12 c#  abstract-class 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 ソフトウェアチームに1-2人の新しいエンジニアを雇おうとしています（3人の開発者、1人のテスターで構成されています）。 それらをチームに統合する手順は何ですか？ 私のアイデアは次のとおりです。 ドキュメントを読む（コーディング標準、使用する開発方法論のドキュメント） 既存のコードを読ませる それらにいくつかの簡単なタスクを割り当てます 最後に、コード部分の責任を負わせる 他に何ができますか？ このプロジェクトは医療分野（超音波システム）であり、すでに5年が経過しています。1年に1回のリリースがあり、1〜2人のエンジニアを追加するときに1つのリリースを終了します。 プロジェクトはメンテナンス段階にあります（レガシーコードのリファクタリング、および新しい機能の追加）。物事はほぼスケジュールどおりです（多少なりとも）。

12 team  integration 

私たち（およびJS SOチャットルーム）は、エラー処理に関する彼のLittle-XHRライブラリについて、数日前に@rlemonと話しました。 基本的に、どのエラー処理パターンを使用するかを決定したかったのです。 xhr.get({ // Some parameters, and then success: function(data) {}, failure: function(data) {} }) または： xhr.get({ // Some parameters, and then callback: function(err, data) {} }) 1つはjQueryに似ていますが、もう1つはノードに似ています。最初のパターンは、エラーの処理についてもっと考えるようになると言う人もいます。あなたは他のコールバック関数を忘れるかもしれないので、私は反対だと思いますが、引数は常に2番目のパターンにあります。 これらの両方のパターンに関する意見/利点/欠点はありますか？

12 javascript  error-handling 

git、maven、およびjenkinsを使用して次のことを行うための好ましい方法は何ですか： 「dev」ブランチと「release」ブランチを維持したいアプリケーションを開発しています。ジェンキンスに両方を構築してほしい。リリースアーティファクトのバージョンが1.5.2になり、開発ビルドが0.0.1-SNAPSHOTになるだけになる可能性があります。2つの異なるpom.xmlファイルを持つ必要はありません。 プロファイルを調べましたが、アーティファクトのバージョンを変更できないようです。私が見た1つの方法は、テストビルドに「修飾子」を追加することです。もちろん、ファイルの名前を変更することもできます。これは、アプリがスタンドアロンのものであるため、これに関する実際のアーティファクト情報は重要ではないからです。 これを行うための好ましい方法は何ですか？または、これをどのように行いますか？

12 git  workflows  versioning  jenkins  maven 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 Javaプログラマーとして、アルゴリズムを学習する必要があります（プログラミングの課題）。私はいくつかのヘッドファーストシリーズ（私が所有するJAVA）を読みましたが、それらは非常に頭に優しいものです。それで、私は理解するのが簡単で、各アルゴリズムの核心にもなるアルゴリズムの本があるのだろうかと思っていました。

12 java  books  algorithms 

私は、いくつかのプラットフォームで実行する必要がある大規模なソフトウェアアプリケーションで作業しています。これらのプラットフォームの一部は、C ++ 11の一部の機能（MSVS 2010など）をサポートしていますが、一部のプラットフォームはサポートしていません（GCC 4.3.xなど）。私はこの状況が数年間続くと予想しています（私の推測では3〜5年）。 そのため、最小限の保守で古いコンパイラでコンパイルできるC ++ 11コードを（可能な限り）作成できるように、互換性インターフェイスを設定したいと思います。全体として、目標は#ifdefを合理的に可能な限り最小化すると同時に、それらをサポートするプラットフォームで基本的なC ++ 11構文/機能を有効にし、サポートしないプラットフォームでエミュレーションを提供することです。 std :: move（）から始めましょう。互換性を実現する最も明白な方法は、次のようなものを共通のヘッダーファイルに入れることです。 #if !defined(HAS_STD_MOVE) namespace std { // C++11 emulation template <typename T> inline T& move(T& v) { return v; } template <typename T> inline const T& move(const T& v) { return v; } } #endif // !defined(HAS_STD_MOVE) これにより、人々は次のようなことを書くことができます …

12 c++  c++11 

アプリケーションで次のコードを使用していますが、正常に機能しています。しかし、mallocで作成するのが良いのか、それともそのままにしておくのが良いのだろうか？ function (int len) { char result [len] = some chars; send result over network }

12 c 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 私は、プログラミングに関連する数学に自分のスキルセットを拡張したいというWeb開発者です。 2番目のキャリアとして、私は大学で働きながら仕事をしている。 私は自分の教育が数学を適用するのに必要なスキルを教えてくれることを望んでいましたが、私はそれがあまりにも簡単にテストできる幅に基づくアプローチが投資時間に対して非常に非効率的であることがすぐにわかりました。 たとえば、私のCalculus 2クラスでは、リモートで役立つ心拡張体験は、ボリュームと曲線下の領域だけでした。残りは単調な栄光化された代数であり、私には簡単ですが、wolfram alphaなどのソフトウェアで数秒以内に実行できます。これは数学を学ぶという私の考えではありません。 ですから、ここで私は、アプリケーションに焦点を当て、理解し、不必要な退屈を最大限に取り除く方法に数学の理解を向上させる方法を探している欲求不満の学生です。 しかし、このアプローチを念頭に置いて、長期にわたる優れた学習戦略を見つけることはできません。 だから、同じような心を持つ人のために、コンピューターがはるかに良くできることをあまり心配せずに、必要な数学をどのように学習しますか？

12 education  math 

最初に用語を作成します： コード目標の調整：午前中にコードをチェックアウトし、他の開発者が前日にファイルごとに行ったすべての変更（特に最初に開発したコードファイル）を静かにレビューし、フォーマット、ロジック、変数名の変更、リファクタリングを修正します長いメソッドなど。その後、VCSに変更をコミットします。 このプラクティスには、私が特定したいくつかの長所と短所がある傾向があります。 Pro：コードの品質/可読性/一貫性が維持されることが多い Pro：他の開発者が元のコードにあまり慣れていないため、いくつかのバグが修正されています。 Con：多くの場合、目標を設定する開発者の時間の無駄です。 Con：前日、バグのないコードを書いたと考えていた開発者が、髪を引っ張る怒りを引き起こすバグをときどき紹介します。 コン：他の開発者は、過度つべこべで悪化し、目標入札のコードに貢献嫌いし始めます。 免責事項：公平を期すために、私は実際には開発マネージャーではなく、実際に「目標管理」を行っている開発者です。 私の防御では、これを正当な理由で行っていると思います（非常に大きなコードベースを油を塗ったマシンに保つため）。また、マネージャーがこの問題に対処する必要があることも間違いなく心配しています。 あなたがマネージャーだったら、この問題にどのように対処しますか？ 更新：これがあまりにもローカライズされているという意味ではありませんが、一部の人は質問しているので、おそらくいくつかの背景が明らかになるでしょう。私は3年前に巨大なプロジェクト（200K LoC）を割り当てられましたが、最近（1年前）にプロジェクトに追加された開発者が追加されました。通常、製品の全体的な安定性について回答する必要があります。コードベースのコアアーキテクチャ部分に驚くほど変更が加えられると、特に緊張します。この習慣は、最初は他の開発者の貢献について楽観的だったために発生しましたが、数週間後までは発見されない深刻な問題を引き起こす過大なミスを引き起こしました。しばしばこれらの

12 version-control  code-quality  management  teamwork  team 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 ソフトウェアエンジニアリングのオプション要件に対するより良い言葉は何ですか？このフレーズは矛盾しています。以前のプロジェクトで「非コア要件」を使用しました。

12 terminology  requirements 

私はJavaのバックグラウンドで、JavaScriptを初めて使用しています。次の例のように、単一文字のパラメーター名を使用する多くのJavaScriptメソッドに気付きました。 doSomething(a,b,c) 好きではありませんが、仲間のJavaScript開発者が、これはファイルサイズを小さくするために行われ、JavaScriptファイルをブラウザーに転送する必要があることに気付きました。 それから私は別の開発者と話をしていることに気づきました。Firefoxがページをより速くロードするために変数名を切り捨てる方法を教えてくれました。これはWebブラウザーの標準的なプラクティスですか？ JavaScriptでプログラミングする際に従うべきベストプラクティスの命名変換は何ですか？識別子の長さは重要ですか？その場合、どの程度ですか？

12 javascript  naming  coding-standards  conventions