C# FTPでException「状態の応答 (DataAlreadyOpen) は 'QUIT' コマンドへの応答に予期されていません。」が発生

  • 2017.11.02 Thursday
  • 15:46

 

こちらのページを参考にして、

C#でSystem.Net.FtpWebRequestを使ってファイルアップロード処理を行っていた際、

正常にアップロードが完了する場合と、Exceptionが発生する場合があることがあり調査してみました。

発生するExceptionメッセージは

『状態の応答 (DataAlreadyOpen) は 'QUIT
' コマンドへの応答に予期されていません。』

 

原因はFTPパスワードの末に改行コードが付随していたこと。

FTPユーザやパスワードを別ファイルから読み込む際、改行コード込みで読み込んでいたらしく上記エラー発生ということでした。

 

コマンドで考えたら納得なのですが、プログラムソースだけ追いかけていてもなかなか気づかない事象なので、備忘録として記載。

 

 

 

『「正しいものを正しくつくる」とは何か(大阪開催)』に参加してきました

  • 2017.10.27 Friday
  • 23:32

2017/10/27(金)

「正しいものを正しくつくる」とは何か(大阪開催)

https://guildworks.doorkeeper.jp/events/64730

に参加してきました。

 


株式会社ハート・オーガナイゼーション 金内さん

  • 医療向けウェブサービス e-casebook をScrumで開発されている
  • 現場コーチとしてギルドワークスに依頼し、最初は主にふりかえりを指導してもらう。
  • 参加者からの質問:Scrumを行って良かった事・悪かった事ありますか?
    • 良かった事:開発にリズムがうまれるようになりました。
    • 悪かった事:社内に妙な期待が生じてしまった。
    • 悪かった事:問題が見える化されるが、問題が消えるわけではない。問題は解決する必要がある。
  • 参加者からの質問:良かったワークショップありましたか?
    • スキル星取表やドラッガー風エクササイズが良かったです。
  • 参加者からの質問:デザイナーさんのロールは?
    • リフレクションの時間を持つようにしています。
  • 参加者からの質問:社内ワークショップはどのように組織されていますか?
    • 最終的には持ち回り制にしました。上司が行うのはアンチパターンかと思います。

 


ギルドワークス株式会社 中村さん

  • 現場コーチについて
  • 現場で大事にしていること「規律・実験・学び」
  • コーチ側で大事にしていること「説明責任・改善責任」
    • 実施は「チームビルディング」・「技術課題の開発」・「プロセス改善」の三本柱
  • コーチへの期待が改善へのきっかけ作りになる。

 


ギルドワークス株式会社 市谷さん

 

市谷さんの話を聞いて、ギルドワークスさんが言われている「正しくつくる」がどいうモノなのか、少し見えた気がしました。

正しく作るというのがラクをする・簡易に作るという方向のものでなく、常に最善を尽くしているという自身の気持ちに正直な状態を保つ事。
つまり「正しくつくる」≒「最善を尽くす」という事なのかと自分は解釈しました。

 

 

 

 

 

 

 

DevLove関西『「グラフをつくる前に読む本 一瞬で伝わる表現はどのように生まれたのか」を語り尽くす』に参加してきました

  • 2017.10.20 Friday
  • 23:56

2017/10/20

DevLove関西『「グラフをつくる前に読む本 一瞬で伝わる表現はどのように生まれたのか」を語り尽くす』

https://devlove-kansai.doorkeeper.jp/events/65716

に参加してきました。

 

書籍「グラフをつくる前に読む本 一瞬で伝わる表現はどのように生まれたのか」の著者である松本健太郎さんが直接本の紹介とワークショップを行っていて頂ける回でした。

 

 

書籍は読んでいたのですが、ワークショップではすっかい罠にハマってしまいました。

ネタバレになるので詳しくは書きませんが、策士策に溺れるようにできており、上手いこと手の上で転がされましたw

『グラフを使うと、データに無い情報をも表現する事も出来る』なんて発想出てきませんでした。

ほんと素晴らしいワークショップでした。(いつかどこかでやってみたいww)

 

 

グラフは大きく分けて2種類あり

  • 考えさせられるグラフ
  • 考えさせないグラフ

今回は後者の考えさせないグラフについての話となりました。

 

感想としては、インセプションデッキをグラフで表すとしたらどうするのか、というのが近い印象でした。

つまり、グラフで「いつ」「どこで」「だれが」「どうする」を説明することができるようにすることが大事であり、そのために「どのようなグラフ(棒グラフ、折れ線、円)を使うのか」「情報量を適正量まで減らせられるのか」が重要となります。

 

また書籍は、グラフを誰が考えどのように発展してきたのかというグラフの歴史や、データの取捨選択についての注意点についても記載されており、普段あまり気にしていなかったグラフについて考えさせられる内容になっています。

判りやすい言葉で書かれており大変読みやすくおススメです。

 

イベント終了後、しっかりサインも頂いてまいりました。

サイン本

 

松本さん、ありがとうございました。

 

 

DevLove関西『大きなSIerの中で「アジャイル開発で飯を食う」までの歩み』に参加してきました

  • 2017.09.21 Thursday
  • 23:32

2017/09/21

DevLove関西『大きなSIerの中で「アジャイル開発で飯を食う」までの歩み』

https://devlove-kansai.doorkeeper.jp/events/63895

に参加してまいりました。

 


発表者:侍れっど さん

 


発表者:びば さん

 

 

 

チーム内にはパートナーさんも多数おられるということで、そのあたりの話をきけたのはよかったです。

DevLove関西 サイボウズの開発の現場 に参加してきました。

  • 2016.05.24 Tuesday
  • 03:33
2016/05/23 DevLove関西 サイボウズの開発の現場 に参加してきました。

当日のTwitterまとめはコチラ
サイボウズの開発の現場 DevLOVE関西 2016/05/23
http://togetter.com/li/978812
 

■kintoneチームのKAIZENプロセス 

@mitomasan さんの発表 
以下気になった点 

  • チームが自律的にカイゼンを進めている 
  • Kintoneはサイボウズ社自体がドッグフーティングとして、自らkintoneを使っている 
  • メールも使っておらず、Kintoneでコミュニケーションしています。
  • Issueやチケット管理などもKintoneを使用しています。
  • ドッグフーティングの問題点として、自分が使わない機能を軽るんじる傾向がある 
  • サイボウズ基本方針として、『人は理想に向かって行動する』という考えをもっている。 
  • カイゼンする時間をる仕組みを作るために、KAIZEN DAYを運用している 
    • カイゼンするための日。 
    • 規模が大きい場合はKAIZEN合宿を行う 
      • 他部署に遊んでいると思われてしまう。 
      • 障害対応に支障が出るのではと反対を受けてします
  • リモート勤務 
    • 会社自身が場所・時間に捕らわれれない働き方を実践できるのかテストしている節がある 


■kintoneエンジニアが紹介する品質向上のための取り組み 


@sakay_y さんの発表 

以下気になった点。
  • ビルドパイプラインは、コンパイルから開発現場へのデブロイまで、約1時間 
  • kintoneは日々データが増え続けている 
  • 障害や問い合わせ対応のチームのほかに、下回りから整備しなおすKAIZENチームを運用している 
  • 最近はINPACT MAPPINGを使って、アプリのゴールを検討している。(なぜ、だれが、どのように、何を) 
  • 参考書籍『IMPACT MAPPING インパクトのあるソフトウェアを作る
  • 毎日なにかしらの勉強会が開催されおり、業務に関係する勉強会であれば業務時間内でも行います。 



発表後のダイアログがあり、いくつかテーマごとに分かれて話し合いが行われました。
私が参加したのは『どうやってKAIZENを行っていくのか?』

話に多く挙がったのは、KAIZENは文化であるという話でした。
チームビルディングで悩まされているのは、どこいも同じようです。

カイゼン活動を、日常の業務にプラスされる作業負担と捉えられてしまうと、その時点で話が止まってしまうので、なかなか難しいです。

Agileの同じバスに乗るではありませんが、チームメンバーを如何に鼓舞するか、
日々悩んでいます。うーむ。


 

NightHacking Tour in Japan [大阪] by 関ジャバ に参加してきました

  • 2016.05.22 Sunday
  • 00:20
2016/05/17
NightHacking Tour in Japan [大阪] by 関ジャバhttp://kanjava.connpass.com/event/30552/)に参加してきました。

当日のTwitterまとめはコチラ。
NightHacking Tour in Japan Osaka by 関ジャバ まとめ


■Putting Hypermedia Back in REST with JAX-RS

@DaschnerSさんによるRESTのお話。
英語判らないのでひたすら、ライブコーディングを眺めていただけなのですが、IntelliJが見たこと無いような早さでプラグラムが組み上がっていくところを見ると感動しますね。ホントどうやっているんだろう。

色々な例がGithubに上がっているみたいです。
https://github.com/sdaschner/jaxrs-hypermedia


■Raspberry Pi with Java

@steveonjavaさんによるRaspberry Piのお話し。
デモとしてファミコンエミュを組み込んだ、見た目ゲームボーイアドバンスのようなRaspberry Pi。
元気にマリオが動き回っておりました。権利的に?だったので写真撮らなかったけど、モニター映らないようにハードだけ取っておけば良かったな。残念。
セッション内容は如何にこのデモ機を作成させたかが話の中心でしたが、途中からJavaステッカー配るための客いじり大会に・・・。
見事メトロイドの主人公キャラの性別を答えてステッカGET。
英語判らなかったので、周りの人に助けてもらいました。感謝。

結構大きいです。

このエミュデモ機ですが、3Dプリンターでケースを作っているだけあって、素人が作ったようなちゃちなものではなくちゃんとしたものになっておりました。
ゲームボーイアドバンスのように折り畳めるのですが、全てプラスチックで制作するのでヒンジ部分をどのようにするのか工夫されているそうです。(六角形にするのやらなんやら)
あと、IOポートが8つ必要なのに、Raspberry Piは6つしかないので、如何に工夫したのかとう話が面白かったです。
(左右キー同時押しで=スタートボタンとするなどで対応)

お二人はnighthackingの一環として、バイクで日本全国のJavaコミュニティを巡っている最中であり、
http://nighthacking.com/
最後は東京でJava CCCJava Day Tokyoに出られるという事です。



 

C#実践開発手法読書会 vol.18 大阪 に参加してきました

  • 2016.05.17 Tuesday
  • 04:28
C#実践開発手法読書会 vol.18 大阪(https://cs-reading.doorkeeper.jp/events/44202/)に参加してきました。

今回は11.4から11章末まで。


■AJAJ
AJAJ(asynchronous JavaScript and JSON)は、AjaxのJSON版の名称。
調べてみたけど読み方が判らない。アジャジャだろうか。



■インタフェース1つ、実装1つの場合でのコードの臭いとは何か? 
読書会範囲から外れるが「9.2.4 設定より規約」に記載されていた

実際には、インターフェースの実装が一つだけであるとしたら、それ自体がコードの臭いです。

について、議論がおきました。
一見すると何がコードの臭いと示されているのか、判りづらいです。
個人的には、@yanosen_jpさんが示された内容が一番しっくりきました。

「恐らく、抽象化(もしくは要約)が足りていないまたは間違えている可能性への危険信号なのではないだろうか。例えば、犬、猫、鳥などのインタフェースを用意するのに、犬インタフェース、猫インターフェースを用意してしまっているのではないか? 
動物インターフェースという抽象化へ至れていないという警告なのではないだろうか」


なるほど、こらならば確かに、コードの臭いがしてくると思いました。

第4回 IDDD読書会 に参加してきました

  • 2016.05.17 Tuesday
  • 03:45
第4回 IDDD読書会(https://iddd.doorkeeper.jp/events/43687)に参加してまいりました。

この読書会はファシリテーターの方が最初に要約をまとめて説明して頂いて、そのあとディスカッションするスタイル。
要約が非常に判り易く勉強になります。
 

今回の範囲は4.4サービス指向から4章末まで。
4章はアーキテクチャ全般の話となります。
注意点として、境界づけられたコンテキストの大きさがアーキテクチャによって影響を受けないようにすること。 
4章前半で話されているCEOへのインタビューにおいて、DB変更やスケールアウトなどがスムーズに行えたという話が出ていますが、それはアーキテクチャがドメインへの制限にならなかった左例でしょうか。

 


■RESTとDDD 

主な手法は2種 

・システムのインターフェースレイヤを境界づけられたコンテキストとして分離して、適切な戦略を用いてインターフェースのモデルから実際のコアドメインにアクセスする方法。 

⇒つまりユーザのタスク情報を取得するのに/user/task としたときに、ドメインオブジェクト直接取得するのではなく、何らかのインターフェース用オブジェクトを返すようにしておけば、taskドメインオブジェクトが変更したとしても、このRESTを使用している各アプリは直接変更影響を受ける度合を軽減することができる。 


・標準メディアタイプの利用 

⇒ドメインコンテキストをまたがって利用できるオブジェクトを返す。 
⇒DDD的には「共有カーネル」「公表された言語」など 。
⇒具体例としてはiCalフォーマット呼ばれるスケジュール標準フォーマット。これは公表された言語であり多数のアプリに実装されている。ドメインオブジェクト自体をicalフォーマットに合わせて作成を行う。 

 

■RESTを選ぶ理由 

RESTの原則を満たす設計システムは、疎結合であるという要件も満たしているから。 

 


■CQRS(コマンドクエリ責務分離) 

メイヤーが提案したCQS(Command Query Separation)が元になったアーキテクチャパターン。
何らかの処理を実行するCommandと、問い合わせを行うQueryを分けようとうのが原則。 
そうしないと、裏で何が処理されているのか判らなくなってしまうため、安心してQueryする事ができなくなってしまう。 

DDD的にCQRSを使用するのメリットとしては、効率性・拡張性などの実装都合によります。 
ドメイン駆動で、複数の集約データや、集約データをまたがるときなど単に愚直にリポジトリパターンでデータ取得するときなど、実装効率が良くない場合、効率よくデータ取得するために専用のQueryを用意するなど行います。 
つまりドメイン駆動だから、モデル層がという話ではなく、スケーラビリティ的理由により活用されています。
また、Queryモデルは、非正規化したデータモデルであり、ドメインのデータというよりは表示用(もしくは印刷)用のデータと見なす。 

CQRSを学ぶ際、下記ページを参考にさせて頂きました。 
 

Greg Young流CQRS - Mark Nijhof 
http://d.hatena.ne.jp/digitalsoul/20100712/1278886009


CQRS Journey 
https://msdn.microsoft.com/ja-jp/library/jj554200.aspx?f=255&MSPPError=-2147217396


DDDで設計するならCQRSの利用を検討すべき 
http://qiita.com/ledmonster/items/22b00c65208dffeff7e4 


[CQRS Documents by Greg Young]の和訳 
http://www.minato.tv/cqrs/cqrs_documents_jp.pdf 


 

■パイプとフィルター 

パイプとフィルターの特性幾つか挙げられてますが、個人的には疎結合と視認性の良さにあると思います。 


 

■イベントソーシング 

CQRSと同時に使われるのが多いのがA+ES(Aggregates and Event Sourcing) 
ドメインモデルとして、多くは非同期つまり結果整合性で済むことは多いと思います。 
しかし、難しくなるのがUI設計。 
非同期で発生したエラー通知などは、どうすればいいのか今でも試行錯誤です。 

 

読書感想 『カンバン仕事術 チームで始める見える化と改善』

  • 2016.05.08 Sunday
  • 00:57
評価:
Marcus Hammarberg,Joakim Sundén
オライリージャパン
¥ 3,888
(2016-03-26)
Amazonランキング: 4856位

■カイゼンを促すツール
初見の開発が多く、同じ開発内容は2つもないという状況の中で、如何にボトルネックを見える化するか、その解へ繋がるツールの1つがカンバンなんだろうなと思いました。
一見正常にタスクが流れているように見えている場合でもWIP(Work in Process)を制限することで、常にカイゼンの機会を探るなんて思いつきもしませんでした。

後、この本で出会えた一番の言葉は、
『始めるのをやめて、終わらせることを始めよう』
ほんとその通りです。

読書感想 『システム開発「見積もり」のすべて』

  • 2016.05.08 Sunday
  • 00:42
タイトルにあるとおり「工事進行基準」会計に準ずるための開発工程「見積もり」の本。
いつ開発規模・工程を見積もるのか、
どのように見積もるのか、
どうやって見積もり内容で開発していくのか、
プロジェクト全般の流れを、実践で培われた内容を元に紹介されていました。

個人的には野村総合研究所で使われている工程定義の表と、
EVMの実践的な見方を学ぶ事が出来たので満足しています。

しかし見積もり手法自体は深く記載されていませんので、
他書籍を参考にする必要がありそうです。

PR

calendar

S M T W T F S
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< December 2017 >>

selected entries

categories

archives

recommend

カンバン仕事術
カンバン仕事術 (JUGEMレビュー »)
Marcus Hammarberg,Joakim Sundén

recommend

recommend

profile

search this site.

others

mobile

qrcode

powered

無料ブログ作成サービス JUGEM