Kassyi

C++、Androidなど組み込み系やWebアプリなど色々経験してきました。 今、Ja…

Kassyi

C++、Androidなど組み込み系やWebアプリなど色々経験してきました。 今、Javaのバッチ処理を書いています。

Webを支える技術（６）

実施日時：2020/12/9 対象範囲：第13章～第14章 参加者：くめごん、よりどり、kassyi 13章 PUTは、変更したところ以外はGetしたリソースをそのまま送信している content要素だけ変更 updatedやpublished要素は基本的にサーバー側が設定する POSTは作成 atom publishの仕様に従ってGet,Put,Delete,Postの処理が決まっている。 AtomPubのサーバーはPostによって自動的に追加・更新することがある サービ

Kassyi

    • Webを支える技術（５）

      実施日時：2020/11/4 対象範囲：第10章 参加者：くめごん、よりどり、kassyi HTMLはHTTP、URIともにWebの基本的な技術。 SGMLをシンプルにしてXMLが生まれた。 XHTML1.1ではtext/htmlは認められていないのでIEではXHTML1.1は使えない IEだけapplication/xhtml+xmlを使う。 text/htmlはSGMLベースのHTMLをapplication/xhtml+xmlはxmlベースのXHTMLを示す。 どちら

      Kassyi

      • Webを支える技術（４）

        実施日時：2020/9/24 対象範囲：第7.9章～第8章 参加者：くめごん、よりどり、よーだい、kassyi GET,HEAD：べき等かつ安全 PUT,DELETE：べき等だが安全でない POST：べき等でも安全でもない 安全：リソースの状態を変更させること べき等：何度繰り返しても同じ結果であること サーバーのログファイルにはGetで取得してPOSTで書き込む場合は GETは安全でPOSTは安全でない 議論： GETのせいでカウントがアップされてしまうバグが存在するかも

        Kassyi

        • Webを支える技術（３）

          実施日時：2020/9/16 対象範囲：第6章～第7.8章 参加者：くめごん、よりどり、よーだい、kassyi インターネットのネットワークプロトコルは階層型になっている ネットワークインターフェース層：物理的なもの インターネット層：IP、ネットワークIFでデータ送信のみ保証 トランスポート層：データの転送を保証する アプリケーション層：インターネットアプリ（メール、DNS、HTTP)を実現する。ソケットと呼ばれるライブラリを使う HTTPの最新バージョンは1.1、199

          Kassyi

        Webを支える技術（６）

        Kassyi

          Webを支える技術（２）

          実施日時：2020/9/9 対象範囲：第4章～第5章 参加者：くめごん、よりどり、よーだい、kassyi 第4章 URIとは「リソースを統一的に識別するID」のこと 一意に決めるのはURIの構文にある http://blog.example.jp/entries/1 このURIを構成するパーツは次のようになります。 ・URIスキーム：http ・ホスト名：blog.example.jp ・パス：/entries/1 ホスト名は、ドメイン名かIPアドレスで必ず一意になる ht

          Kassyi

          Webを支える技術（２）

          Kassyi

          Webを支える技術（１）

          実施日時：2020/9/2 対象範囲：第1章～第3章 参加者：くめごん、よりどり、よーだい、kassyi 第1章 プログラム向けのインタフェースを指すときは「WebAPI」 「Webサービス」は、Webで提供するサービスやサイトを示すときに使う。 ハイパーメディアとは、テキストや画像、音声、映像などさまざまなメディアをハイパーリンク（HyperLink）で結び付けて構成したシステム。 ハイパーリンクあるいは単にリンクとは、ハイパーメディアにおいて情報同士を結び付ける機構。

          Kassyi

          Webを支える技術（１）

          Kassyi

          【読書会メモ】テスト駆動設計（4）

          実施日時：2020/5/8 対象範囲：第7章-第11章 参加者：こなやん、くめごん、まぶり、kassyi 7章 クラス設計する時には、なるべく先延ばしにすると良いこともある 8章 メソッド宣言だけを親クラスに移動 ファクトリーメソッドパターンを導入して、テストコードから２つのサブクラスの存在を隠した サブクラスを隠した結果いくつかのテストが冗長になったがそのままにしておいた 9章 通貨オブジェクトを管理する前にまずは文字列を作成 timesメソッドの中を修正し、次にファクト

          Kassyi

          【読書会メモ】テスト駆動設計（4）

          Kassyi

          【読書会メモ】テスト駆動設計（2）

          実施日時：2020/4/8 対象範囲：第3章-第6章 参加者：yodai、くめごん、まぶり、kassyi 3章 オブジェクトの値を変更しても前の値が変更されない様に、value objectとしてオブジェクトを値として扱う方法がある。 Dollerオブジェクトから小切手オブジェクトを作成した場合、小切手オブジェクトを変更するとDollerオブジェクトも変更されてしまう。 それを別名参照問題という。 Value Objectでは操作するたびに新しいオブジェクトを返す必要がある

          Kassyi

          【読書会メモ】テスト駆動設計（2）

          Kassyi

          【読書会メモ】テスト駆動設計（1）

          実施日時：2020/4/1 対象範囲：第1章 参加者：yodai、くめごん、まぶり、kassyi まえがき 自動化されたコードが失敗したら新しいコードを書く レッド・グリーン・リファクタリングを繰り返してTDDを実施する テスト駆動開発はプログラムの不安をコントロールする手法 テスト駆動開発はテストが通ったらそこから先はコードが動作する事が分かるようになる。 セキュリティと並行性に関するプログラムタスクは、TDDで機械的に示せる所まで至っていない。 議論： 文体が回りくどい

          Kassyi

          【読書会メモ】テスト駆動設計（1）

          Kassyi

          【読書会メモ】現場で役立つシステム設計の原則（10）

          実施日時：2020/3/18 対象範囲：第9章 参加者：yodai、くめごん、まぶり、kassyi 今までは、分析、設計、実装、テストはそれぞれ別のチームが行っていたが、オブジェクト指向では全部同じチームが行う。 変化に対応するため、スピードが大事になったので変更を繰り返す開発手法が大事になった。 オブジェクト指向らしい開発とは、同じチームが分析、設計、プログラムを担当し、短いサイクルで繰り返すもの。 業務ロジックに焦点を当てて開発を進めるのが重要。 マネジメントとして、ド

          Kassyi

          【読書会メモ】現場で役立つシステム設計の原則（10）

          Kassyi

          【読書会メモ】現場で役立つシステム設計の原則（９）

          実施日時：2020/3/11 対象範囲：第8章(続き) 参加者：yodai、くめごん、yoridori、まぶり、kassyi APIの作成では、「登録と参照を分ける」「リソースの単位を分ける」を意識する。 リソースについて、名前、性別、生年月日など、細かい単位で分ける。 影響を最小限にできる。 APIのバージョンの管理は意味が無く、現在の最新が唯一のバージョンとするべき。 古いAPIは段階的に廃棄する。303→404→削除 大きなWebサービスのAPIならばバージョン管理も

          Kassyi

          【読書会メモ】現場で役立つシステム設計の原則（９）

          Kassyi

          【読書会メモ】現場で役立つシステム設計の原則（8）

          実施日時：2020/3/4 対象範囲：第8章 参加者：yodai、くめごん、まぶり、kassyi WebAPIのエラー時の約束 システムの内部ではエラーについての情報をログなどで時系列で残す。 良いWebAPIとは何か APIとして大は小を兼ねるものは利用者側にとって負担が大きい。 使いにくいAPIとなるのは、お互いの理解が不足したまま開発が進んでしまうため。 動作させると使用の不整合や考慮漏れなどが発覚するので、作りながら確認していくのが効率的 詳細設計を作成するのは大変

          Kassyi

          【読書会メモ】現場で役立つシステム設計の原則（8）

          Kassyi

          【読書会メモ】現場で役立つシステム設計の原則（7）

          実施日時：2020/2/12 対象範囲：第7章 参加者：yodai、くめごん、まぶり、kassyi 画面アプリケーションの開発 画面単位のプログラムはソフトウェアの記述を複雑にする。 入り組んだ画面を画面単位で開発すると画面の複雑さに引きずられてプログラムが肥大化する。 画面アプリケーションのコードが複雑で変更が厄介になる原因 ・画面そのものが複雑 ・画面の表示ロジックと業務ロジックが分離できていない これを変更する ・汎用画面でなく、用途ごとシンプルな画面にする ・画面の

          Kassyi

          【読書会メモ】現場で役立つシステム設計の原則（7）

          Kassyi

          【読書会メモ】現場で役立つシステム設計の原則（6）

          実施日時：2019/12/25 対象範囲：第4章 参加者：yodai、くめごん、masuda220、kassyi 小さな部品を作ってそれを集める 役に立つドメインオブジェクトは業務の言葉とクラス名とメソッド名が一致する 業務の知識がふわふわしていると危ない プログラム側から問題領域を理解する手がかりが見つかることがある。 これは、業務用語をより論理的にしてソフトウェアをより分かりやすくする手がかりになる。 業務知識が不足していても、理解した範囲で実装してみるのが大切 ソース

          Kassyi

          【読書会メモ】現場で役立つシステム設計の原則（6）

          Kassyi

          【読書会メモ】現場で役立つシステム設計の原則（５）

          実施日時：2019/12/18 対象範囲：第4章 参加者：yodai、くめごん、まぶり、kassyi ＜ドメインオブジェクトの見つけ方＞ 業務の重要な関心事とそうでない事を区別する。 以下、重要な点の見つけ方 関心事をヒト／モノ／コトの３つに分類する ヒト：判断、行動するもの モノ：業務を遂行する関心の対象、データ＋ロジック コト：業務で起きる（起こる）事象 まずは、コトに注目して整理する 例：販売活動 受注→出荷→請求→入金 受注はその他のコトとは異なる ・発生源が外部の

          Kassyi

          【読書会メモ】現場で役立つシステム設計の原則（５）

          Kassyi

          【読書会メモ】現場で役立つシステム設計の原則（４）

          実施日時：2019/12/4 対象範囲：第4章 参加者：yodai、みずき、くめごん、まぶり、kassyi 第4章　ドメインモデルの考え方で設計する ドメインモデルの考え方を理解する ・ドメインモデルで設計すると何がよいのか ドメインモデルは、ドメインオブジェクトを集めて体系的に整理したもの ドメインモデルは、業務の用語集や説明書であり、用語の関連や作用をパッケージやクラスで表現する手段 ・ドメインモデルの設計は難しいのか 難しくしているのは、オブジェクト指向ブログら民

          Kassyi

          【読書会メモ】現場で役立つシステム設計の原則（４）

          Kassyi