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

標準は、ソフトウェア業界が重要であると見なす規則と習慣であり、ISO標準や言語仕様などの正式な仕様として、または職場での行動規則などのより非公式な文書として、何らかの方法で体系化されています。

3
Cライブラリ関数の背後にある根拠がerrnoをゼロに設定しない
C標準では、C標準ライブラリ関数errnoをゼロに設定しないことを義務付けています。なぜこれが正確なのですか? 私はそれがいくつかの関数を呼び出しerrno、最後の関数の後でのみチェックするのに役立つことを理解できました-例えば: errno = 0; double x = strtod(str1, NULL); long y = strtol(str2, NULL); if (errno) // either "strtod" or "strtol" failed else // both succeeded しかし、これは「悪い習慣」とは見なされていませんか?あなただけチェックしているので、errno非常に最後に、あなただけの機能の一つであることを知ったの失敗ではなく、どの関数が失敗しました。何かがほとんどの実用的なプログラムに対して十分に失敗したことを単に知っていますか? さまざまなC Rationaleドキュメントを探してみましたが、それらの多くにはの詳細があまりありません<errno.h>。
9 c  standards 


4
「代替品」のトレーニング、どのように標準を施行するのですか?
これがこれを尋ねるのに適切なスタック交換サイトであるかどうかはわかりませんが、ここに行きます... 範囲 私は数百人の従業員を抱える小さな会社で働いています。同社の開発チームは小規模で、ビジュアルフォックスプロで作業しています。同社の特定の部門が、既存の請求システムを修正および強化するために「孤独なガンマン」として私を雇いました。多くのリスクと制限に悩まされていたAccessアプリケーションを正常に取得し、SQLサーバーバックエンドから駆動されるC#アプリケーションに変換しました。 私は最近学部を取得しましたが、決して専門家ではありません。それを補うために、マイクロソフト認定資格を取得すると.netとそれがどのように機能するかについて理解を深める必要があると感じました。 だから、9ヶ月前に通知してから3ヶ月前にようやく交換品が出てきました。彼らの役割は、C#で設計されたアプリケーションをサポートするために私が設計してきたことを学ぶことです。 交換 実務経験のない大学を出たばかりで、データに関連するあらゆることに対する最初の本能はリストボックスであり、現在もそうです...データが言及されるときはいつでも、リストボックスが置換の選択のコントロールです。これは、他のコントロールについて何度も説明しましたが、1つのフォームに5つのリストボックスが表示されているので、問題になりました。Classroomのエクスペリエンスは、ほとんどすべてのC ++コンソール開発でした。 したがって、私が懸念している例は、winformsアプリケーションです。ユーザーは、理由をテーブルにキー入力して後で選択する必要があります。厳密に型指定されたデータセットが存在することがわかっている場合、ツールボックスからデータソースをドラッグするだけで、これらすべてが作成されます。これは簡単な例ですが、データバインディングを使用することが重要です。 過去数か月間、強く型付けされたデータセット、その使用方法、および他のコントロールとの相互作用の場所について話してきました。データセット、バインディングソース、アダプター、およびデータグリッドビューに関連してどのように機能するか。このプロジェクトを引き渡した後、これらを実装する方法についての質問が予想されました。次に何が起こったのかというと、ただ床を下ろしただけです。 強く型付けされたデータセットのアダプタのインスタンスがフォームのアクティブ化イベントで作成され、テーブルが作成されてデータが入力されました。次に、このテーブルからリストボックスに行を手動で追加するループが作成されました。最後に、必要に応じて、更新のためにレコードがどのIDであったかを調べるために、変数を参照して保持しました。 彼らはあなたが尋ねる記録をどのように変更しますか?それも私の最初の質問でした。あなたはそれがどれほど単純であるか信じられないでしょう、あなたがそれをダブルクリックするだけで、彼らはそれを変更するために新しい値をポップアッププロンプトに入力します。データ入力演算子として、すべてのモーダルポップアップは私を完全に狂気にさせます。最終的なソリューションは、維持する必要がある100行のコードを超えています。 だから私の懸念は、これらのどれも沈んでいないということです...部門は彼らの時間の週20時間しか許可されていません。先週まで、運が良ければ週4〜5時間しか与えられませんでした。先週かそこらで、私は幸運にも10を手に入れました。 質問 私は何をしますか?! 私が去るまであと4週間あり、彼らはこのアプリケーションを完全に「サポート」しています。私はこの仕事とそれが私に与えた機会を愛していますが、私が私の翼を広げて、何か新しいものを見つける時が来ました。私は決して彼らが引き継ぐ準備ができていると確信しているわけではありません。 置換には「構成する」という技術的能力があると思いますが、学習する代わりに、これらすべてを手動で行うコードを書くだけです。置換が最終的に別の方法でコーディングしたい場合、それが機能する限り、それを見ると恐ろしいのでそれで大丈夫です。しかし、私は、彼らが設計したものをサポートするためのMUSTそれがどのように動作するかを理解するために、私は「魔法」は実現するためにコントロールやフレームワークを使用していますか。 このプロジェクトには約40のフォーム、30以上の奇数のテーブル、トリガー、ストアドプロシージャを含むデータベースがあります。それは労働と請求書、契約と予測の関係です...私がこのプロジェクトを始めたのは3年前ほど簡単ではなく、現在、部署はそれなしでは生き残れない立場にあります。 世界でどのようにして次のことを達成できますか?: 部署のマネージャーがやりたいことはできるが、できることを伝え続ける場合は、一貫した設計の標準または理解を強化する 代替をサポートするために必要なフレームワークとシステム設計の積極的な学習に取り組む方法を見つける 優雅にSRに知らせてください。週5〜9時間の管理では、部門、既存のプロセス、サポートする必要のあるアプリケーションについて学び、システムの潜在的な機能強化がどこにあるかを判断するには十分ではありません。 はい、私はこれがテキストの壁であることを知っています。私を読んでくれてありがとうございますが、私は何をすべきかわからないだけです。私にとって、この仕事はリファレンスの怪物であり、私が離れて物事がばらばらになると、物事は非常に悪く見えるでしょう。これをどのように処理しますか?


5
REST APIを「正しい」方法で実行しなかった場合の結果?
私はこの方法でこの質問をします-私のREST APIを「正しい」方法で実装しないことのソフトウェアエンジニアリングの懸念は何ですか? 「正しい」方法とはどういう意味ですか?まあ、私が正しい方法についての私の認識を説明できるようにしてから、私がそれをどのように行っているかを説明します(また、JSON REST APIについて話していると仮定します)。 正しい方法 無国籍。これは私が得る部分です。クライアントは常に100%いつまでも状態を維持します。それはサーバーの仕事ではなく、クライアントの仕事です。 各動詞の予想されるアクションと応答: GET-完全に指定されたリソースを取得します。リクエストの承認またはクエリパラメータのいずれかによってのみ制限されます。これにより、プロセス内のリソースが変更されることはありません。 POST-リソースの説明全体(JSONオブジェクトなど)を指定すると、リソースを作成し、日付やIDなどのサーバー側のプロパティも作成してそのリソースを返します。 DELETE-指定されたリソースを削除し、応答として何らかの200 OKのみを与えます PUT -指定されたオブジェクト全体宣言入力として、入力で与えられたフィールドのそれぞれにリソースのすべてのフィールドを更新し、特定の場所でリソースを更新します。明確にするために、これはオブジェクト全体が入力として渡されることを期待しています。更新されたリソース全体が、すべてのフィールドとともに(許可またはその他の入力フラグに従って)返されます。 PATCH-リソースの変更が必要なフィールドのみを指定して、入力として指定された指定されたリソースのフィールドのみを更新します。(これは私が不明瞭なところです):リソース全体が返されますか?(または、更新されたフィールドだけですか?Dunno。気にしないでください。) リソースパス。リソースの相互関係を考えると、リソースパスは次のいずれかになります。 / parentresource /:id / parentresource /:id / childresource / parentresource /:id / childresource /:childId / parentresource /:id / childresource /:childId / subresource /:subresourceId(この例では、サブリソースは、親リソースに属する子リソースに属しています)。 やりたいこと 上記は、REST APIがどのように機能するかについての私の理解です。次に、上記のバリエーションのいくつかをリストします。 PUT / PATCH-変更のためにリソース全体を渡すポイントは何ですか?リソースの変更にはPUTのみを使用し、更新するフィールドのみを渡します。その結果、パッチを使用する必要はありません リソースパス-アプリケーションでGUIDを使用しています。その結果、それらは世界的にユニークになります。単独でサブリソースを一意に参照できるのに、親リソースを含む完全なリソースパスが必要なのはなぜですか?以下のような: /サブリソース/:subresourceId :もし私のような完全なパスが必要となるサブリソースを参照しようとし、それを「正しい」やり方をやっていた / parentresource …
8 design  rest  api  standards 

4
ASP.NETの展開/保守のベストプラクティス
私はWeb開発業界に5年ほどいますが、常にオープンソース環境で働いています。バージョン管理にgitを使用して、ほとんどの場合、apache、mysql、およびphpに少しルビーを追加します。しかし最近、開発が完全にC#ASP.NET MVCである仕事を始めました。 言語などはかなり簡単に習得できましたが、私のチームの他のメンバー(MS開発の経験が私よりもはるかに多い)は、最終的なサイトの公開と展開に関して異なる考え方を持っています。特に将来の変化。 他の開発者の考え方は、サイトが公開されるとそれが最終的なものになるということです。このサイトにこれ以上変更を加えることはできません。私がこれの背後にある理由を尋ねたところ、その答えは危険すぎる、時間がかかる、または難しいというものでした。 私の過去の経験から、サイトの更新は、変更されたファイルをアップロードする場合にすぎません。通常、それが少しの変更である場合、または更新が行われている間、サイトをメンテナンスモードにする場合は非常に迅速です。 最近MVCサイトを公開しましたが、企業から連絡があり、テキストの一部を更新して新しいPDFドキュメントへのリンクを追加しました。私のチームの他のメンバーは、サイトは現在稼働中であり、変更してはならないため、これを行うべきではないとすぐに言った。マイクロソフトの開発者に「育てられない」ことで見逃したことはありますか? 本番環境のライブWebアプリケーションに変更を加えることに対する反対の主張は何ですか?この考え方は.NET開発者に固有のものですか? 私はこの考え方を理解し、それがマイクロソフトの開発環境で正当化されるのか、それとも古い考え方なのかを理解したいと思います。 注:バージョン管理にはTFSを使用し、発行プロファイルを使用して、サイトが展開される場所(UATまたは本番)を決定します

1
Clojureなどの単一の単純な言語でHTML + JavaScript + CSS + Flash + Javaアプレットを置き換えることはできますか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 アイデアをすぐに却下しないでください。すでに機能している(主に)主流のアプローチと競争するのは難しいことを知っているので、私の質問の一部は「学術的」です。 ClojureScriptが存在し非常に優れていることも知っていますが、これは既存の醜いものへのパッチであり、有用な抽象化です。 免責事項:私はプログラマーですが、Web開発者ではありません。そのため、他のユーザーのフィードバックを募集しています。開発者であり、毎日Webを使用していて、さまざまなトピックを読んだり、ページのhtmlソースを時々表示したりしていると、私はWeb開発について何か考えがあると思います。 とにかく、私がそれらを見るときの問題: Webは速くて汚い、初心者にやさしいものでしたが、今では優れた最新のインタラクティブなWebページを作成するにはかなりのスキルが必要です。これは多くの場合、迅速で汚い「21日でWebを学習する」だけではまったく効果がないことを意味します。 HTMLは、noobに適したプロトコルとして、迅速かつダーティに始まりました。現在は混乱しています。 JavaScript言語には欠陥がないわけではありませんが、問題ありません。 CSSは物事を片付けるためのまともな試みのようです。別のファイルで外観をスタイル設定できることは、少なくともそれについての考えを保持する価値があります。 まとめると、JavaScript + Html + CSSはかなりダーティになります。次のような問題を軽減する優れたアイデア/ツールがあります。AJAXライブラリは、JavaScriptの特定のフレーバーを抽象化します。JQuery、Node.jsなどの強力なライブラリを使用すると、JavaScriptでクールなことをそのまま不完全なものにすることができます。Google Web Kitは、GUIデザインをWebページに変換する上で非常に優れています。ウェブMVCは、このような抽象的なもの離れASP.Net、RoRの、ジャンゴとしてフレームワークとあなたのための足の仕事の多くを行う、もつとも、これらは安っぽいベースの上のすべての抽象化したものです。 今日のWebで実行できることに対する需要はますます高まっています。GoogleのChromeBookは、その現れです。ブラウザの全画面を実行し、キーボード/マウスの操作、サウンド、ビデオ、ゲーム、テキスト、画像、PowerPointプレゼンテーションなど、やりたいことすべてを実行します。高速なブラウザと高速なコンピュータ、そして「クラウド」に感謝しますが、はるかに良いかもしれません! グラフィックの観点から見ると、ブラウザは、何でもペイントできる長方形のキャンバスです。現在、ブラウザー実行可能ファイルは、Html、JavaScript、CSSを解析してすべてを表示する方法を知っている必要があるため、数メガバイトの重さがあります。 ゼロから始めて、ペイントするのはキャンバスにすぎないことに気付いた場合、ブラウザはもっと小さくてシンプルになると思います。支払うべき代償は、LispやClojureなどのファンキーな構文のすべてに対して有効なプログラムを作成しなければならないことです。以前はHTMLのクールな部分でした-段落を入力するだけの場合は、そのまま入力します。これはめったに起こりません。テキストの段落を入力するだけの場合は、インラインまたはCSSのスタイル設定、配置について考える必要があります。次のHTMLの一部(このサイトのフロントページにあります) <a href="/software/tagged/programming-languages" class="post-tag" title="show questions tagged 'programming-languages'" rel="tag">programming-languages</a> <a href="/software/tagged/learning" class="post-tag" title="show questions tagged 'learning'" rel="tag">learning</a> いくつかの代替Lispy構文よりも作成するのはそれほど簡単ではありません(そして、私はそれほど深く考えていません)。 (create-link :target "/questions/tagged/programming-languages" :class "post-tag" :title "show questions tagged 'programming-languages'" :rel "tag" :content …
8 web  standards 

1
変更管理基準
ソフトウェアおよびその他の業界で広く受け入れられている変更管理標準はありますか?私はターゲットドメインがまったく異なる複数の企業で働いていました(投資銀行と通信)。企業は、非常によく似たグローバル変更管理(GCM)の組織とプロセスを持っていました。すなわち: 全社的なファイアウォールの変更、データベースの割り当て/サポート、バージョン管理システムのサポートなど、IT関連のすべての変更を担当するGCM部門がありました。 変更がフリーズするような考えがありました。変更の実装日が変更の凍結日と同じ場合、変更を実装することができませんでした。 ありましたGCM会議(カンファレンスコール)誰もが彼らの変更の必要性と重要性を議論したときには。GCM部門の担当者が毎週同時に開催しました(火曜日、グリニッジ標準時17:00など)。 変更は変更承認者によって承認されている必要があります。必須の承認者グループの独自のリストを持つさまざまな種類の要求がありました。グループには、いくつかのメンバーが異なるタイムゾーンで働いていました。グループ全体が変更を承認するためには、少なくとも1人のメンバーがGCMを承認している必要があります。スケジュールされた実装時間になる前に、すべての必須の承認者グループの承認が収集されている必要がありました。それ以外の場合は、実装されないという100%の保証がありました。 GCMプロセスの官僚主義は注目に値しました。それは純粋な官僚の地獄でした。ツールはひどく、人々は遅くて頑固でした。小さな変更を実装することはほぼ不可能でした。実装時間の前に最後の承認が得られない場合や、変更の凍結時に実装時間がスケジュールされていることが突然判明した場合があります。 私はそれを見てみたいので、GCMプロセスとそれらがさまざまな会社でどのように機能するかについての一般的な理解を得たいと思います。それがどこでもひどいひどいものなのか、それとも特定の企業でのGCMプロセスの実装が不十分なだけなのか知りたい。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.