Hyper-VでCisco AnyConnectが繋がらない場合の対応方法

会社で承認を受けたので、自宅PCにVPNを意気揚々とインストールしたが、全然繋がらなかったのでメモ。

仕事用(と言ってもメールかSSHで繋ぐだけだが)だから、自分の私用PCと環境別な方がいいよなと思い、Hyper-VでWindows 10を導入してそこにVPNソフトを導入した。

が、全然繋がらない。
会社のPCを家で繋いだら繋がるので、何でだろうとずっと悩んでいたのだが、そのHyper-Vの設定が原因だった。
ゲストOSがWindows8.1以降だと拡張セッションでつながるみたいで、これがRDP(リモートデスクトッププロトコル)をベースとした技術だということ。

しかし、Cisco AnyConnectはリモートデスクトップでの動作を保証していない!!

ってことで、Hyper-Vの下記赤枠のボタンを押すと、

拡張セッションがOFFになり、以下のように+が付いたアイコンになる。

この状態で、VPNに接続したら接続できました。

参考

• Cisco AnyConnect and Hyper-V - Connect to a VPN from Inside a VM Session[Devhammer Enterprises]

Visual Studio 11 Team Foundation Server Express

Microsoft、Team Foundation Server Expressを発表[InfoQ]

MicrosoftがVS11からTeam Foundation SeverのExpressを出すようだ。
Team Concertと一緒の10人位まで許容してくれると良かったんだけど、まぁMSDNライセンスあるから関係ないか。

そういや、VS2010TFSをインストールしてから止まったまんまだ。
色々と使えるか調べんとなぁ。

ドキュメンテーションをどうするか

このBlogの過去ログを読んだら、この話題に1年に1回は言及しているな（笑）

仕様書絡みでWikiを使っているけど、断片化されちゃうのでイマイチだなぁとずっと思ってた。sphinxは試してみようと思ってたけど、Blockdiagというツールもあるみたい。

コードからこれらのテキストデータを生成できれば、本当に人間が書くべきところだけに注力できるかなぁ。

ドキュメンテーションを加速するストレスフリーの作図ツール『Blockdiag』 jus2011年6月勉強会

View more presentations from Takayuki Shimizukawa

継続的インテグレーション

「Hudson」改め「Jenkins」で始めるCI（継続的インテグレーション）入門[@IT]

ようやく今期から後輩が空いたので、アウトプットの出口強化に努める。
先輩がJenkins入れたから、これも活用してコード書いた後からのチェックを自動化していきたい。

後は、Review Board入れたいんだけど、ちょっと今運用している環境と離れてるな〜。また実験用のサーバー立てて入れられるか確認してみるか。

Windows Phone 7の開発を始めてみた

というわけで、環境入れてみた。
とりあえずチュートリアル見ながら、Hello Word!はササッと作成。

しかし、XAMLがさっぱり分からない。
う〜ん、WPFの本でも読んでみるかなぁ。
ここが分からないと、VisualStudio上で表示されるXAMLも、Expression Blend 4で弄っても、何がどうなっているやらさっぱり分からん。

バグを含まないコードを書くインセンティブ

• グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？[Publickkey]
• 開発とテストの融合こそゴール。続、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？[Publickey]

エンジニアを3つのロールに分けて考える。
Software EngineerとTest Engineerを物理的に分けて、それぞれフィードバックを与えつつ、Software Engineer in Testの所を共同でやるっていうのは出来ないものだろうか？

仕様もテストもコードもある一定の人が作ると、甘くなりがち&視点が狭くなりがちだから(自分の経験)、なるべくなら別の人の考えを入れたいところ。
ペア作業って事になるんだろうか？

原文はこっち。後で頑張って読んでみよう。

• How Google Tests Software - Part One[Testing Blog]
• How Google Tests Software - Part Two[Testing Blog]
• How Google Tests Software - Part Three[Testing Blog]
• How Google Tests Software - Part Four[Testing Blog]
• How Google Tests Software - Part Five[Testing Blog]

FaceBookの考え方も参考になるかも。
こちらは、Facebookはどのようにコードをリリースしているか？開発文化が書いてある。

• How Facebook Ships Code[FrameThink]
• Read an Interesting Article on Facebook Developers(和訳)[my days and responses]

個人的に面白いなぁと思ったのは、以下の下り。

“People do not get called out for introducing bugs. They only get called out if they ask for changes to go out with the release but aren’t around to support them in case something goes wrong (and haven’t found someone to cover for you).”

バグを引き起こして、呼び出されることは無い。リリース時に変更を含める依頼をしているのに、念のために対応できるように待機していない。(もしくは代わりに対応してくれる人を探していない）場合のみ呼び出される。

リリース時に障害が見つかり、会議で居ない、休みで居ない、別の仕事やっていて直ぐに修正にとりかかれない等、そういった事が無いような状況を作り出すのも仕事のうちということ。

VS2010 TFS導入完了

Visual Studio Team Foundation Server 2010のインストールがようやく終わった。
Team Foundation Server Power Tools March 2011[MSDN]に拡張ツールもあるから試してみようと思う。

あとは、ここ[@IT]を見ながら、色々と出来る事出来ない事を調べていこう。

開発と監査の対立

新潟初のソフトウェアテストシンポジウム「JaSST'11 Niigata」開催レポート（その2）[@IT]

何かどこかで見たことがある話だったので。

監査グループ側は「きちんと監査しなくてはならない」と、開発者に監査用のドキュメント作成を要求しました。ところが、多忙な現場で働く開発者からは「ただでさえ忙しいのに、ドキュメントを作るのは手間がかかる」という反論が多く寄せられ、監査グループと開発者が対立する状態になってしまいました。

しかし、こういう監査やって品質というのは上がるのかなぁ。
未だに疑問が拭えない。

ただ、最近思ってきたのは、（ドキュメントに限らず）「書けるんだけど書かない、書きたくない」のと「書けない」は違うんだよね。自分も含めて、結構阿呆なミスが多いこと。
騒いでいるのは、どっちに属しているかで結構反論の意味合いが変わってくる。

だからといって、監査ばっか増えるのが良いとは到底思えないけど、じゃあ代わりにどうシステマチックに解決するかを提示・実行しなきゃこういう事を推進している人は黙ってくれないよね。

コードを読むのにかかる時間

「コードの読まれ方が分かった」、工数見積もり精度向上に寄与[@IT]

ざっくりまとめると、下記の感じ。

• その分野に関わってきた人は知識があるのでコードを理解するのが早い
• コードの規模が大きくなると知識だけじゃ無理で経験が無いと早くならない。
• 結合度とか高いと、↑な経験あっても読むのに時間がかかる

当たり前のことが数値で証明(まではいかないかな？）されたということか。

コードのコミット数や凝集度とかのデータを早く取りたいなぁ。

Visual Studio 2010で試したいこと

最近はオープンソースやフリーウェアのツールの導入とか積極的にやっていたが、ビジュアルステューディオ[*1]のような商用ソフトも導入していきたい。
せっかくMSDN契約しているのだから、使い尽くしたい気持ちがあるし、金で解決できるんだったら、ツールなんか安いものだろう。

というわけで、Visual Studioがらみで気になるメモ。

• Team Foundation Serverとインスタンスメッセージングでテンポよく [寝ても覚めても.NET]
  • 丁度TFSを立てる準備をしているので、Power Toolsも導入してみる
• TFS 2010のテストケース作業項目[寝ても覚めても.NET]
• TFS 2010関連のデモ動画[寝ても覚めても.NET]
  • テストやコード解析系の機能。C++だとあんま使えなさそうだけど・・・。
• Visual Studio向けのPythonプラグイン「PTVS」ベータ1をリリース[SOURCEFORGE]
  • VSにPythonやIronPythonのサポートを追加するプラグイン。IronPython使ってる身としては試してみたい。
• Visual Studio 2010 Service Pack1[MSDN]

あぁ、試してみたいことが山ほどある。

---

*1:Agile Conference Tokyo 2009でT川さんがそんな発音してた。

組織の構造は設計を決める

「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催[Publickkey]

DDD(Domain-Driven Design)では、組織の設計がソフトウェアの設計を決めるとあるが、組織を跨いだソフトウェア開発がどれだけ影響を及ぼすか調べたもの。

バグの傾向の分析を簡単にはしたことがあるが、組織の構造や（組織から見た）システム全体の分析はしたことが無いはず。

こういう観点でも、是非取り組みたい。やってみれば、今記録しているデータの不足も明らかになるだろうし。

ツールの話[記事]も取り組めてないが、こういう事もやりたいなぁ。

ツールによる補助

開発と運用の新しい関係、「DevOps」とは何か？[Publickey]

仕事はCloudではないので直接は関係ないけど。

昔、Software Factoriesを調査していた時に、その構成する一つの要素でツールというのがあった。DSLを簡単に作れるようサポートするという意味合いでのツール。

土台を作る側としては、新規機能をどんどん入れていく。それを、派生開発している人が機能に追いついていない。コロコロ仕様を変えると、学習コストに跳ね返っていく。

こういう所を隠ぺいするためにも、Platformだけでなく周辺環境の整備も必要なんじゃないかな、と4年位前から思っているが、一向に手を付ける暇がない。。。

参考

• ソフトウェア ファクトリ[MSDN]
• Software Factoriesに関する陳述[MSDN]
• モデル駆動型開発手法「Software Factories」の全貌[ThinkIT]
• 次世代開発基盤技術“Software Factories”詳解[@IT]

Developers Summit 2011 1日目

今年もデブサミに行ってきた。
仕事が入ってしまったので、ちょっとしか聞けなかったけど・・・。

押さえておこう！モバイル開発におけるUXの考え方

まとめ[Twitter]。

個人的には一番題材が面白かった。
何せWIndows Phone 7触ったことないし、どんなもんかなぁ？という気持ちがふつふつと湧いてきた。

MSのサイト[APP HUB]いって開発環境を落としてきて、
いろいろやると[Daizen Ikehara BLOGS]使えるようになるようだ。
#英語版だけだったら、何もやらなくてよいのだろうけど。

開発者向けの情報はこちら[Windows Phone]。

早く試してみたい。

チケット駆動開発〜タスクマネジメントからAgile開発へ〜

デブサミ2011(17-B-3)講演資料「チケット駆動開発〜タスクマネジメントからAgile開発へ」

View more presentations from akipii Oga.

言わずと知れたあきぴーさんの講演。
いつもBlogを見ている人の御尊顔を拝しただけで満足（笑）。

実際のところ、本やBlogを読ませていただいているので、うんうんと頷いて終わってしまった・・・。

チケット管理システム大決戦 JIRA vs Redmine vs Trac 〜ユーザーが語る、なぜ私はこのツールを使うのか

チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか

View more presentations from Sean Osawa.

データとビューという考えを改めて確認して、ちょっと後輩にチケット以外の情報も、もっと視覚的に見ようよ、という考えを伝えて、来週からの仕事を言い渡してみた。

後輩も今までと違う仕事が出来るみたいで、ちょっと興味を持ったみたいだ。

去年と比較して

去年こんなこと[記事]書いているが、この考えも浅はかだった。
期せずして多少考え方に近づいたが、結局は混乱というか仕事に追われている現状になってしまった。
Redmineなんかも上司やすげー上の上司の理解(暴走?)もあり、細々とやってたのが一気に広がりを見せたが、タスクが管理されているだけでは耐えきれない感じがヒシヒシとする。今まである一定の範囲しかやってなかった人が急にInput増えても全然反応できずにタスクそのものが産まれない(見逃されてしまう)という所がある。

そういや、去年の考えを先輩に話したときに、「考えはいいけど、そんな事出来る人なんて少ないだろう。」と指摘を受けたが、その通りになってしまったなぁ、と今更思う。
会社でも、別件で話していたが、ソーシャルな問題にも手を付けていかないと、本当に良いソフトウェア開発にはならないんだろうな、とジワジワ実感してきた。

あと、この辺り[記事]は、去年思ったこととあまり変わらず。(WIndows PhoneやGPGPUとか全然仕事と関係ない分野の方が面白そうに聞こえる）
もう興味ある分野は、人に聞くのではなく、話し実践して学んでいくフェーズに完全に入っちゃったのかなぁと思う。

アーキテクトの有り様

アーキテクト(笑)と呼ばれてた事もあったけど、実際人が増えてくると設計全体の一貫性を保つのに何か必要だからなぁ。

アジャイルチームのアーキテクトのための10の助言[InfoQ]

1. “過不足のない”事前設計
2. 縦割りスライスから始める
3. イテレーションごとのジャストインタイム設計
4. チームを信頼しつつ、チームのためにそばにいる
5. コードを書く!
6. すべてに関与する
7. 文化の質を向上させる
8. 変更が要求された時を把握する
9. 外部のランダム化からチームを保護する
10. 誰かが読む文書だけ作成する

1、2、4、5、7、9は、甘めに見ると出来ているのかなぁ、と思う。

3とか6とかは、出来てるのだろうか？
この辺りの伝達は微妙に人任せ(or人依存)だから、まだまだ大きく改善の余地があり。チームの構造とか、物の作り方に関わってくるな。

10は、いつまでたっても課題だなぁ。
これも、今年中には案を出していきたいな。

インテル ソフトウェアカンファレンス2010

参加中。全体として並列化の話ばっかだ。個人的には新しいCPUのキャッシュ管理とか変態的な所聞きたかったんだけど、最近はライブラリで隠蔽するからんなこと知らんで良い、って感じなのかなぁ？

しかし、相変わらず休憩毎にコーヒーでたり昼飯がでたりと、金がある会社は違うなぁ。

制約が無いと仕事が定まりにくい

たまたま読んでたら、関連しそうなのでメモ。

InfoQの記事は、制約は選択肢を奪うものだが、逆手にとれば制約については考える範囲が小さくなるということ(選択肢が制限されているので)。時間が少ないという制約なら、出来る事は自ずと限定されてくる。これが時間が無限という前提になってしまうと、どこまでやらなくてはいけないか？というキャップを自分で色々な条件から導き出さなければいけない。

これを読んだ後、あきぴーさんの記事を読んだ。
自分もRedmineを細々と使っているのを知られているので、他部署でRedmineを使おうとしている人にどのように使っているのか？どのように使えばいいのか？というの相談をたまに受ける。悩みは色々あるらしいけど、同じく皆使っていないのがバージョンの概念だ。

このバージョン(ロードマップ)という概念は、一種の制約だと思う。
大体1ヶ月から1ヶ月半でバージョンを自分たちは切ってる。それにより、今すぐに解決しなきゃいけない問題か？3ヶ月毎か半期後に解決してればよいのか？とか、まずどのバージョンで対応するべきかをタスクにつけるときに、強制的に考えなくてはならない。

また、期限も制限されているので、必然的にタスクがある一定以上の大きさにならない。期限は、最初2週間くらいでやってみようかと思ったんだけど、リリースする頻度がそんなに早くないし(中間成果物すら出ない)、そこまで他の人のタスクを細かく見たい欲求も皆になかったので、1ヶ月から1ヶ月半になった。

話を戻して他部署の悩みだけど、普通に半期、1年、2年レベルで目標を設定するから、タスクの粒度がそれぞれバラバラだったり、更新がおろそかになったりしてたようだ(2年後完成のタスクなんて、日々入力するか!)。

予算だったり、商品スケジュールだったり、外部からくる制約もあるが、自分たちが産み出す制約(これをルールと言うのかね)もある。その2つをマネジメントは理解し、制約から問題をハッキリさせ解決に導いていくのかというのは、重要だと思う。

元ネタ

• 制約は利点の仮の姿だ[InfoQ]
• バージョンのないRedmineプロジェクト〜TiDD初心者が陥りやすい罠[プログラマの思索]

Agile Conference tokyo 2010に参加

今日は秋葉原で昼ご飯。

というわけで(?)、去年末の2009に引き続き、Agile Conference tokyo 2010[公式サイト]に行ってきた。

色々収穫はあったけど、一番キタのは実はAgileとは直接関係ない話。要件とか基本設計とか実装とか工程別に会社を分けて発注すると、その工程をまたがった改善にインセンティブがもてないという。(まぁ、そりゃそうだよな会社違うわけだし)

これ聞いて、日々悶々としてた悩みにこの例がピタリとはまった。結局のところチーム体制は工程別になっているので、自分の直接関与しないタスクには自ずと改善とかのモチベーションは維持できないよな〜。
実装でもパフォーマンスを根本的に改善するには、局所的なとこ直してもどうにもならないけど、チームもそのチームがどんなにどんなに頑張って(仮に全部のチームが頑張って)生産性あげても、そのチーム構造そのものがボトルネックになってしまっているのではないかと。

他は、(Agile含めて)大規模開発とか分散開発とか1年位前までは結構興味あったんだけど、数名レベルのチームですら実践できない(しきれない)現状を考えると、まだそこは情報だけ仕入れておくかな〜という感じ。感銘受けたり、なるほどとか思うところは多々あったけど、現場の何に適応するの？って感じなので。

Continuous Deliveryとかも、4年位前から色々と考えていたことなのでやってみたいな〜と、想いがちょと戻ってきた。
チームの成果物は皆工夫して自動でできるようにしたり、プログラム化されたりしてるので、そういうのを束ねたりして更に上位のOutputを出すとか色々チャレンジしてみたいものだ。(そういや、こういう活動もチームの枠をはみ出た話を聞いたことないなぁ。自戒もこめてだけど。）
とにかく改善に向けての気分がちょっと復活したのが、今回のセミナーの一番の収穫だ。

ヤフーのインストーラを使っているとバカになる

ヤフーにおけるパッケージ管理[TechBlog]

この記事を読んでて、やっぱソフトウェアって問題解決なんだよな〜と強く思う。
会社にもインストーラー作っている人がいるけど、その人とやり取りするとどうもインストーラーの動きばっかで、ユーザーの状況を含んだ話は一切出てこない。
このI/F叩くとこう動きます、とかそういうののみ。
それが聞きたいんだったら、仕様書読むよ。

ユーザーが一体どんな体験になるか、それが自分が作っている以外のコンポーネントの組み合わせまでも語れると良いんだけど、どうしても自分で作ってるものの範囲でしか語ってくれないんだよなぁ。

マネージャーの役割

アジャイルにおけるプロジェクトマネジャーの役割[InfoQ]

管理やって！って、言われる。
色々と放置していたツケがあって、より戻しでそういう流れになってるんだけど。

だったら開発と管理を分離してくれ！と言い続けていくのはやるとして、そんな事言っても仕事は無理矢理降ってくるので、自分がやる場合に何をやらなきゃならんのか。
人・物・金の管理とよく言われるが、実質の所そんな権限が無いので、人の交流の促進「だけ」という自分が嫌いなパターンになるんだろう。

そんな中で、リンク先の記事は役に立つかな〜と。
しかしイマイチ不思議なのが、何で下っ端にこういう仕事を振るんだろうか・・・。

ソフトウェアアーキテクチャ文書で書くべき事

ソフトウェアアーキテクチャの文書化について[InfoQ]

最近、作っているシステムの大枠の仕様書をおこそうとしている。
ただ、やはり悩みがあってどういうViewでどの程度の粒度で書けばいいんか、感覚が分からない。

機能やI/Fの事を書けば、機能仕様書とかと被ってしまうし、要求にふりすぎても要求仕様書と被ってしまう。

業務要求 → Software Requirements Specification(SRS)→機能仕様

ちょっと前まで、SRSに該当するのかなぁと思ってたけど、実現手段も含むので要求だけじゃないなー、と。落ちてきた要求をこういう風に設計すると実現できるでしょ！って所が書きたいんだけど、どうにも頭がまとまらない。

Len氏: 開発手法が変わったからといって、アーキテクチャを文書化する目的が変わるわけではありません。ドキュメントは単にコミュニケーションのための手段ではありません。SCRUMやXPといったアジャイル開発手法では、直接対話することで一部のドキュメントのニーズを置き換えています。でも、設計判断に関する詳細なコミュニケーションを目的としたドキュメントのニーズは、直接対話では置き換えることはできません。設計判断といったものは、ミーティングの場で伝えて理解してもらうのが難しいためです。時間が経過してからのコミュニケーションやマネジメントとのコミュニケーションというのは、アジャイルでは扱われていません。

＜中略＞

Paulo氏: 一般的にソフトウェアアーキテクチャの役割とは、不明確で揺れ動くことの多い要件と実際に動作する実装との間の橋渡しをすることです。アーキテクチャドキュメントには設計判断を記録しておきます。これは（最初に）実装を導くための道具であり、想定した解決策が正しい判断であるか評価するために使えます。＜以下略＞

結局のところ、その判断をしていない開発者(or数ヵ月後の自分)に何を伝えればあとは理解してくれるか練りきれていないのだろう。

もう少し頭を真っ白にして、何の情報があれば思考がトレースできるか考えてみよう。