バックエンドフレームワークの作成

こんにちは。 インフラの講義管理機能中に受講生管理画面があります。 そこで受講生それぞれの講義進度を確認できる機能を提供するのに 医師は他の人とは異なります 着実に進道を出てくる姿を見せてくれました。 講義を作った立場で力になりました。 頑張ってくれてありがとう。 方向性提示に関して話をしたら 私が講義を企画したときに悩んでいたことの1つは、 たくさん話すと話題から抜け出して 深く実装すると、コードが難しくなるということでした。 それを克服するために 実際の業務で発生した問題を理解し、 これをフレームワークの機能にする 初級開発者の観点から 講義構成をしました。 もちろん、講義で作られた機能は不足しています。 医師が話したように 方向性を提示することで終わるのも意図した部分です。 この点は 学んで使うフレームワークではありません 不便で改善するフレームワーク 視野を広げたいという気持ちで作りました。 フレームワークの最終版は以下の場所にあります。 https://github.com/zeroshift01/zeroshift01/tree/master/inflearn08 方向性の提示で終わったフレームワーク 実務で使用されるレベルに変化した様子をご覧いただけます。 2番目のパッケージ管理基準について話している場合 当然の話だが 実際の作業では、フレームワークリソースと 業務資源を分離して使用しています。 しかし、説明する観点から リソースを分離しないことが一目でわかる利点があります。 bizとfwリソースを分離していません。 Eclipseベースでリソースを見るとき 階層的に見ればリソースの区別がしやすいようです。 3番目のテストコードに関連する内容に答えると パッケージは一つの機能を凝集度の観点でモジュール化できる ディレクトリ情報だから その機能を欠陥を確認するテストコードも 同じ場所に置くのが効果的であるという考えでリソースを管理しました。 もちろん、ファイルの終わりはEmp001_test.javaのようにテストコードであることがわかりました。 そのような規則で、実務でもテストコード 運用環境に移管されることがないように管理されます。 さらに同じパッケージに配置されている場合 デフォルトメソッドのテストもお勧めです。 受講評 ありがとうございます。

ネイバー "コス"というウェブトゥーンを見ると 新しい草食（招式、権法の指導）をたくさん知るよりも 私が身につけた草食を深く知り、それを応用するのが利点というフレーズがあります。 そういう意味で講義を作ったのに役に立ったなんて気持ちがいいですね。 最後まで頑張ってください。 最初の受講評を残していただきありがとうございます。

こんにちは。ゼロです。 数学のスキルを育てるために 解説集を見てはいけません。 解説は問題の解決プロセスの1つだけです。 その過程を悩む前に目で最初に身につけると 同様の問題やアプリケーションの問題を解決できないからです。 考えてみる問題も同じだと思います。 動作するソフトウェアをコード化するプロセスは、 数学問題解説地にある内容のようにはなりません。 抽象化と可読性の間 トレードオフ（互いに反対の影響を与える）を心配する必要があります。 非定型リアルタイムデータ処理のため トランザクションシリアライゼーションをある程度放棄しなければならない状況が来ます。 この時役に立つのは 目で見た知識ではなく、私が悩んだ経験です。 そんな経験と知恵を得てほしい気持ちで 考えてみる問題の答えは別に上げなかった。 それでも気になる方のために オンラインフィードバック時間を設けたので興味があればメールしてください。 インテリジェイの使用に関連して WAS（Tomcat）を実行してデバッグできる機能（Enterprise Edition） ユーロ版から可能な関係に 講義企画の際に使用しないことにしました。 また、IDE固有の機能を必要とせず、別のプラグインやライブラリなしで クラスパス、コンパイル、ビルド設定だけでいいから 無料でWAS（トムキャット）制御が可能なEclipseを使用します。 しかし、提案したように インテリジェイ基準 バックエンドフレームワークプロジェクトの払い戻し設定方法を別々に作成 受講に役立つようにします。 受講評 ありがとうございます。