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

私は今、小さなソフトウェアコンサルティング会社のコンサルタントとしてかなり長い間働いています。通常のビジネスモデルはスタッフの増強ではありませんが、何らかのソリューションの構築に支援を必要とするクライアントを見つけ、そのソリューションを構築し、既存のITスタッフと協力し、そのサポートに関与するすべてをトレーニングできるチームを派遣しますソリューション、次の仕事に進みます。もちろん、継続的なサポートが必要な場合は、引き続きサポートします。私たちはこの分野で高い評価を得ており、提供するソリューションの実装に非常に成功しています。 しかし、私はほとんどのプロジェクトに共通のテーマがあることに気付きました。現場に着くと、通常、チームと現在クライアントにいる多くのITスタッフとの間に「ストレスのある」関係があります。私たちの到着について多少の不安があるかもしれず、私たちが周りにいるときに防御ができることを完全に理解しています。多くの人々は理解しており、一緒に仕事をするのは簡単ですが、通常、私たちとはうまく働かず、多くの点でプロジェクトのリスクになりかねない人がいます。 私たちは心を開き、良い態度で入ろうとし、ar慢になったり断定したりしないようにします。通常、クリーンアップが混乱しているときに展開されますが、バインドされた状態になった決定が行われた理由があることを理解しています...そのため、次のステップを決定して先に進みます。 私の質問はこれです-コンサルタントを抱えているITスタッフやプログラマーから聞きたいのですが、コンサルタントが行うことでネガティブな感情や態度を引き起こすことは何ですか？最初からだけでなく、プロジェクトが進むにつれて、関係をより良くするために私たちは何ができますか？

36 freelancing  relationships 

製品ミックスによって価格が異なる会社の新しいPOSに取り組んでいます。 すべての製品に基本価格があります。 私の問題を説明するために、私は次の情報を使用します： Product Category Price A 1 45 B 1 70 Q 2 20 R 2 27 S 2 15 X 3 17 Y 3 22 Z 3 16 会社にはパッケージがあります（パッケージ「コンボ」など）。製品AまたはBの場合、QまたはRのいずれかを選択し、X、Y、またはZのいずれかを選択すると、20ドルの割引が適用されます。 ケースA：注文時にベース商品に追加する場合があります。たとえば、商品Aではなく、商品Qと商品Pを追加して、割引価格のパッケージを作成します。次に、1つのRと1つのZを持つ1つの製品Bが必要であると追加します。 ケースB： 1 Aと2 B、2 Q、1 S、2 Xと1 Zを追加する場合があります。「コンボ」パッケージで規定されているルールに従って、Sはコンボアイテムではないため、2つのコンボのみが適用されます。 その他のプロモーションは数量に依存するため、Bを2つ購入すると20％オフまたは時間に依存し、午後5時以降または午前10時前の場合は10％オフ前にのみ有効です。別のプロモーションは、最後の購入がいつ行われたか、またはY期間に$ Xを超えて購入したかどうかによって異なります。 私の問題： 1）さまざまな要件を持つさまざまなタイプのプロモーションを追加するのに非常に柔軟な方法で、さまざまなパッケージまたはプロモーションを作成できるように、テーブルをどのように構成しますか？ 2）ケースB（またはケースAとケースBの組み合わせ）のように注文した場合、クエリを構造化して、注文に含まれる製品の組み合わせを確認し、それに応じて価格/説明を更新する方法？最終的に、このクエリの最良の結果は、どのパッケージとプロモーションが要件を満たし、その順に顧客に最もメリットがあるかを返します（つまり、注文したものがプロモーション1と3の要件を満たしますが、プロモーション3の方が安価です）。複数のプロモーションで機能する必要があります）。 助けてくれてありがとう！ アップデート＃1 目前の問題をよりよく説明し、これまでに行った作業を更新して問題を解決するために、問題に影響を与えるエンティティと属性に限定された製品モデルのERDを含めています（つまり、ここでは在庫が機能していないため、在庫はありません）エンティティが存在します）。 この質問に影響を与えるエンティティと属性からのサンプルデータも含めています（データの読み取りを簡単にするために、外部キーの代わりに名前/説明を入れています）。 これは、コンボの例を示すフローチャートへのリンクであり、テーブル構造を理解するための高速で視覚的な方法です。 …

11 web-development  database  database-design  schema  relationships 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 5年前休業。 私は最近採用されたポジションの一連の面接に参加しました。インタビューの過程で、6回に分けてインタビューを受けました。3つの技術面接と3つの状況/ビジネス面接。 私の2番目の（そして最も困難なインタビュー）の間に、今は私のマネージャーであるインタビュアーが、プログラミングの問題の解決策を一晩で提供するように頼みました。翌日に解決策を提出しましたが、面接官が期待したものではないことがすぐにわかりました。私はすぐに、正解を含む別のソリューションを追跡しましたが、インタビュー会社からそのように見なされました。 マネージャーが6か月の期間内にそのポジションの従業員を雇用していなかったため、この期間中に、裏側でインタビュープロセスが変更されたことがわかりました。 私は役職に就いたので、この特定の状況により、ここでの私の配置について、このマネージャーの口の味が悪いのではないかと少し心配しています（これは、新しい採用プ​​ロセスに時間がかかりすぎたため、彼の頭の上で行われたと思います）。 私は現在2か月以上働いており、このマネージャーと直接やり取りすることはありませんでした。私はうまくいったと信じており、私のチームリーダーから私の認識の賞賛と確認を受けました。 専門家の観点から、面接の履歴に注意しながら、上司にこれが確実に表示されるようにするにはどうすればよいですか？ 回答ありがとうございます。

9 interview  relationships 

数週間、オブジェクト間の関係について考えてきました。特にOOPのオブジェクトについては考えていません。たとえばC ++では、他のオブジェクトへのアクセスを必要とする構造内でポインターまたはポインターのコンテナーを階層化することでそれを表現することに慣れています。オブジェクトAがにアクセスする必要がある場合、in Bを見つけることは珍しいことではありません。B *pBA しかし、私はもはやC ++プログラマーではありません。関数型言語を使用してプログラムを作成します。特に、純粋な関数型言語であるHaskellを使用します。ポインター、参照、またはそのようなものを使用することは可能ですが、「Haskell以外の方法で行う」など、私はそれに不思議に思います。 それから私はそれらすべての関係のことについてもう少し深く考え、要点に達しました： 「なぜこのような関係をレイヤー化して表現するのですか？ 私はすでにそれについて考えている人々を読んだ（ここ）。私の見解では、明示的なグラフを介して関係を表現する方が、タイプのコアに焦点を合わせ、後でコンビネータを介して関係を表現できるため、はるかに優れています（SQLと少し似ています）。 コア私たちは定義するときにことを意味しA、我々は何を定義するために期待Aされるで作られたそれはない、何に依存します。たとえば、ビデオゲームでは、タイプがある場合Character、それについて話すことTraitは合法です、Skillまたはそのようなことですが、私たちが話すWeaponかItemsどうかはそうですか？もうよくわかりません。次に： data Character = { chSkills :: [Skill] , chTraits :: [Traits] , chName :: String , chWeapon :: IORef Weapon -- or STRef, or whatever , chItems :: IORef [Item] -- ditto } 私にとってデザインの点で本当に間違っているように思えます。私はむしろ次のようなものを好みます： data Character = { chSkills :: …

8 haskell  relationships