HIDARI日記（右）

そのときどき興味ある技術を中心にだらだら書いてます。内容は個人の見解であり、所属する企業を代表するものではありません。

土壁を壊すときに忘れてはいけない5つのもの

Etc

この前の日曜日のことです

ヌーラボさんの京都事務所の移転のため、移転先の京都の民家を自分たちで改装するという計画？に誘っていただいたので、この前の日曜日、ほいほい遊びに行ってきました。

詳細はこちら。

「ITの開発会社がオフィスをDIY？！　vol.1〜株式会社ヌーラボ」│ 京都移住計画

この日は主に壁壊す日。改装で取り払う土壁を、せっかくなのでみんなでわいわい壊してしまおうという企画でした。

参加してみて感じたことを今後のために残しておこうと思います。

土壁を壊すときに忘れてはいけない5つのもの

1. 防塵マスク

マストアイテム。

僕は持っていくのを忘れてしまい、ご好意で貸していただくことが出来ました。

しかし本来であれば自分で用意していくべきもの。自分の顔の形にあったものを用意していくのが吉。

2. ゴーグル

マストアイテム、その2。

恥ずかしながらゴーグルも持参せずお借りしてしまいましたが、これも事前にきちんと用意すべき。フィット感が大事。

マスクとゴーグルがくっついたタイプでも可。

3. タオル

かなりの重労働なので大量の汗をかきます。予備も合わせて3枚くらいあると多い日も安心。

4. 水

特に夏場は十分な水分補給が命綱。

5. お風呂の準備

壁を壊したあとは身体の汚れが気になります。作業後に銭湯に行きたくなることうけあい。

なんと新しいヌーラボ京都事務所の近所には銭湯があります。汚れた身体をさっぱりさせたいものです。

おわりに

いかがでしたでしょうか。 ここで紹介したアイテムを用意すればあなたも明日から立派な壁壊er（てきとう。

防塵マスク イスラエル軍仕様

防塵マスク イスラエル軍仕様

艦これ2014夏イベント反省会

Game Etc

お疲れ様でした

2014年8月29日のアップデートをもって、今年の艦これ夏イベント「期間限定海域【AL / MI作戦】」が終了しました。

今回はかなりガチで挑んだけど、春イベントに続き全ステージクリアはなりませんでした。

編成や戦績はこちらのgistで公開しています。

艦これ艦隊日誌_2014夏イベント.md

最終ステージの壁は厚かった…。 届かなくて悔しかったので一人、反省会を行いたいと思います。

反省点

  • 試行回数の不足
    • 前半に時間かけすぎ
      • 情報収集に時間を取り過ぎてスタートが遅れた
      • 予備艦に不安があったため日和った
    • 3重キラに拘り過ぎて、試行回数が少なくなってた
      • キラ無しで試行回数増やす
      • 疲労回復の時間を使って可能なだけキラ付けする
      • 運の要素が強いから、それに抗うためには試行回数を増やす以外にない。
    • イベント中は出撃できないようなスキマ時間にキラ付けしておいて、まとめて回数出撃するほうが試行回数増やせる気がする
  • 燃料不足
    • 確か最初は6万弱あった最終的には燃料が1万切ったし10万以上は必要そう
    • 燃料に限らず10万以上はほしいところ
  • 駆逐艦、軽空母の戦力不足
    • 事前に育ててた艦娘たちが戦艦、正規空母などに偏ってた
    • 支援艦隊が十分ではなかった疑惑
  • 自戦力が把握できてない部分があった
    • 戦艦とか余ってた
    • 長門使ってなかった…

成果

ちなみに全く成果がなかったわけではないです。

  • 大鯨
  • 清霜
  • あきつ丸
  • 三隈
  • 春雨
  • 雲龍
  • 時津風
  • 大淀
  • 長波

といった感じ。レア艦娘のドロップはさすがイベント海域といったところ。

おわりに

戦力が把握しきれていなかった点と偏っていた点については日々の演習を上手く利用しながら整えていくつもりです。

ですが結局のところ資材と試行回数が足りなかったのが一番大きな問題のように思われます。

次回のイベントではこれを改善することを目標に準備していこうと思います。

「進め、現場のチーム開発 〜チーム開発実践入門〜」に参加してきました #DevKan

Dev

台風でも開催されました

台風迫る2014/8/9に開催された 進め、現場のチーム開発 〜チーム開発実践入門〜 (DevLOVE関西Ver) - DevLOVE関西 | Doorkeeper に参加してきたので、せっかくなのでメモしておきたいと思います。

「チーム開発実践入門」の著者、池田尚史 (ikeike443) さんのお話のメモ。

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

チーム開発・プロジェクトの課題

  • プロジェクトの目標が定まってない
    • 何を達成すればいいのか
  • 要件が不明
    • おもってたんとちゃう
  • 価値を提供出来ているか不明
    • 意義は？価値は？総合的に意味あるの？
  • リスク管理ができてない
    • 正常系のプランのみ。プランBない。
  • チームのパフォーマンスを出していない
    • 開発効率が悪い

チームを考える前にプロジェクトを考える

まず以下を順番に考える

  1. ゴールはどこか
  2. 決めるのは誰か
  3. 利益は出るのか
  4. リスクは見えているのか
  5. チーム開発は上手く行ってる？
    • チームビルディングはプロジェクトの一部
    • しかし、基礎である

チームを考える

プロジェクトを成功に導くための大事の基礎。以下のことを順番に考える。

  1. 方法論
  2. コミュニケーションプラン
  3. 成果はどう測る？
  4. チームビルディングはどうする
    • モヒカンばかりのチームは破綻しやすい。ピエロも必要。
  5. 開発ツールはどう使う？

ツールが解決する問題とツールの障壁

ツールは、

などの問題を解決する手助けをしてくれる。 いくつかのツールを組み合わせれば大抵のことは解決できる。

でもそれは、ここ3～5年Webを見てきた人に限った話で・・・

初めてこういう問題に手を付ける人がいきなりググってもわけわかめなことが多い。

チーム開発を改善するには

  • まず可視化
    • 現実を直視出来る環境を作れば、自ずと改善サイクルは回り出す
    • そのために必要なことはなんでもするのがスクラムマスター
  • 小さなことからコツコツと
    • いきなり「継続的デリバリー！！」とか言わない
    • 小さなコストでインパクトの大きいところから
  • 管理しない
    • シナジーを重視する
    • 「やれ」と言われたことより「やろう」と考えるほうが効果が高い
  • 情報を共有する
    • 全メンバーが出来る限りフラットにアクセスできるように

まとめ

  • 良いチーム開発は良い習慣から
    • 「太ったからダイエット」 -> 挫折、リバウンド
    • ダイエットを始めなくてもよいような習慣を
    • 開発も同じ、問題/課題が溜まりづらい習慣を作る

なお発表資料は池田さんがブログで公開されています．

#DevLOVE 関西でお話させていただきました - ikeike443のブログ

おわりに

台風の接近もありいくつかの発表、LTが中止になってしまったのは残念でしたが、 こざけ (s_kozake) さんがLTで使用する予定だった資料をご自身のブログ進め、現場のチーム開発 〜チーム開発実践入門〜 (DevLOVE関西Ver) に参加してきました - シスアーキ in はてなで公開してくださっています。勉強会のレポートとしても非常に読み応えがあるので、ぜひ読んでみてください。

チーム開発実践入門読んだ

Dev VCS Etc

明日（今日）進め、現場のチーム開発 〜チーム開発実践入門〜 (DevLOVE関西Ver) - DevLOVE関西 | Doorkeeper があるので、記憶が上書きされる前に残して置きたかった。

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

メモと妄想と入り混じった感じだけどとりあえず書きます。

気をつけること

  • 「正解はケースバイケース」
    • ツールは正解を持たない
    • ツールによって想定された使い方とか、 ベストプラクティス？と言われるようなものはある。
    • でも確かにIt depends on 状況、ですよね。ここでは2つの考え方があるんじゃないかな。
      • 自分たちの状況をペストプラクティスが対象とする状況に合わせる
      • ベストプラクティスを自分たちの状況に合わせる
    • 長い目で見ればベストプラクティスを適用できる形にプロセスを変えていくべきかなと思っています。
    • そういう覚悟？が無いやつはレガシーコードと一緒に沈む可能性が高い気がする。根拠はないけど。
    • ツールが想定してる使い方をせずに，無理やり自分たちのプロセス上動かそうとして、導入に失敗、「◯◯は使えない」とか悲しいよねー

タスクの管理について

  • タスクの優先順位を決めるためにITS使おう
  • ITSじゃなくてもよい．開発以外の関係者も見られるもの
    • 優先順位をはっきり決められるのがよい。これはGithubを使ってもいい。
    • ITSが重すぎるならホワイトボードと付箋でも

バージョン管理を有効に使う

  • バージョン管理超大事。常にバージョン管理でコードの変更を追跡できるように。
    • 手元の作業コピーは常にひとつにしとくのがよい
    • DVCS使ってるならブランチを駆使しよう
    • SVNとかならもう少し保守的に
      • 自分の出来る範囲で
      • 無理するとろくなことが無い
    • DVCSが使えるなら手元では細かくコミット、公開するときは意味のあるまとまりでコミット
    • リポジトリのワークフローははっきりさせる
  • コミットログを活用しよう
    • ITS，CIサーバとの連携も視野に
    • 意味の無いコミットメッセージは無いように
  • ITSとの連携でコード変更の理由まで簡単に追跡できるようにしよう
  • ブランチ・タグはうまく使おう
  • ソースコード以外もバージョン管理
    • ライフサイクルの近いものだけでまとめてリポジトリを作るようにしたい
      • ドキュメント、設定ファイル、データベーススキーマ etc
    • バイナリはそれ専用のリポジトリ
    • ライブラリの依存関係を記述できるシステムを頼ろう
      • 可能ならmavenとか、.NETならNuget
        • サーバに直置きとかはそろそろやめましょ

テストコードは必須

  • 自信をもってコードの変更できるように常にテストを書こう

    • レガシーコードは無理しない
    • 状況を悪くする可能性もあるので少しずつ
    • 追加するコードはテスト可能なように書こう
      • でもテスト書くにもスキルが必要な点は留意すること
      • 慣れないうちは素振りとか超大事

  • CI回そう

    • VCS，ITSと連携すると幸せになれる可能性高まる
  • 可能なら検証環境も簡単に用意できるようにしておこう
  • CDもいいけどハードルは高め
    • Chefとか使えると幸せ
    • 可能なら検証環境も簡単に用意できるようにしたいね
    • 運用にはそれなりにパワーが必要な印象

以下、読んでる最中に脳内でこぼしてた愚痴

  • 自分たちで良くなっていく意志のないチームは何をやってもダメ
    • 「でもうちのチームのやり方には歴史があって・・・」、「他のコードに合わせないと・・・」
      • 今までより良くするために変えていく
      • コメントであろうがなんだろうが意味をなしてないものは削除
      • 関数は積極的に分割してテスト可能に変更
      • とかとか
    • 「で，それは誰がやるの？」、「◯◯のときどうするの？」
      • どうするの？じゃねーよ。おめーがやるんだよ
        • せめて「◯◯のときいい案無いかな？」とかもう少し、ほら、ね？

おわりに

台風来てるし中止にならないか心配。

ASP.NETSkypeミーティングに参加しました

C# ASP.NET

なにそれ

すでに8月に入ってしまいましたが、去る7/19に大阪で、福井のじんぐる (@xin9le)さん、 岡山のきよくらならみ (@kiyokura)さんと Skypeを通してASP.NETの話を聞かせていただくという勉強会に参加してきたました。

せっかくなので雑ですが、残しておきます。

前半はじんぐるさんにASP.NETの基礎、 特にASP.NET MVCを使ったアプリケーションに作成方法の 概要についてハンズオンを交えて教えてもらいました。

後半には岡山の第19回勉強会 - Okayama IT Engineers Community | Doorkeeperで 発表中だったきよくらさんと繋いで3拠点で「ASP.NET "NOW" and "NEXT"」を聞く勉強会となりました。

じんぐるさんのターン

  • ASP.NETプロジェクトの作成
  • 簡単なルーティングの説明
    • /コントローラ/アクションメソッド/(ID)とかそういうの
    • ActionResultとかヘルパーメソッドView()とか
  • Viewの作成
    • HTMLヘルパー使ったりしながら
  • GET, POSTなどに絞る属性の指定
  • POSTの実装
  • Razor構文の書き方（入門編）
  • マスターページ_ViewStart.cshtmlの書き方
    • @RenderBody()、@RenderSection()
    • どこまでをマスターページ含めるか
    • 当然たくさん書くほどサイト全体が重くなる
  • [HttpGet]、[HttpPost]などのActionNameSelectorAttributeを継承するクラスでのアクションメソッドへの振り分け制御
  • モデルバインダー入門
    • フォーム送信（POST？）されたデータからオブジェクト（クラスのインスタンス）を生成
    • アクションメソッドの引数としてそのオブジェクトを利用できるようになる
  • 検証の実装入門
    • サーバ側ではモデルに検証属性を指定、Viewで検証失敗時のメッセージなどを実装
    • クライアント側に型情報を渡すことで検証属性から、HTMLタグが出力される（jqueryが使用される）

AzureVM上にASP.NET MVCのサイトでも立ち上げたくなりました。 次は認証関係のところを聞きたい（欲張り。

サーバ/クライアントそれぞれでの値の検証についてもう少し掘り下げたい（欲ｂ。

あと、じんぐるさん曰くモデルとコントローラの間にViewModelを挟んで柔軟な構造にするべきとのことでした。

きよくらさんのターン

ASP.NET "NOW" and "NEXT"ということでASP.NETのこれまでの変遷とこれからどのように変わっていくのかを現在公開されているASP.NET vNEXTをもとにわかりやすく説明してもらいました。

ASP.NET

  • ASP.NETは.NET Framwork上で動くWebアプリフレームワーク
    • ASP.NET WebForms, MVC, WebPages, SPA, WebAPI, SignalRすべてをまとめてASP.NETと呼ばれることが多い。
    • ASP.NET WebFormsはすでに完成の域になり大きな進歩はない（VS2005の時点で概ね完成していた）
    • 2009年以降はMVCが着実に進化、WebAPI,Pagesも登場、2013年にはSignalRも登場
    • MVCは現在5.2?、SignalRもすでにバージョン2がリリース済み

One ASP.NET

  • ASP.NETのフレームワークをプラガブルに利用できることを目指す
    • NuGetを利用して各フレームワークのライブラリを柔軟かつ整合性のとれた状態で管理
    • 何を使えばいいか迷うときはMVC
    • WebFormsはオススメできない
  • クライアントサイドではjquery, TypeScriptが使える
  • Visual Studioの機能の充実によって開発効率が上がる

OWIN（Open Web Interface for .NET）

  • WebアプリとWebサーバーを接続するインタフェースの 規格
  • IISへの依存からの切り離し
  • 現段階の実装としてはKatana Project - Homeがある

ASP.NET vNEXT（ASP.NETの次のバージョン）

  • ASP.NET vNext | The ASP.NET Site
  • まだアルファなのですぐにどうこうという話ではない
  • MVC6でMVC、WebPages、WepAPIが統合（整理）される
  • WebFormsはバージョンアップされない
  • side-by-sideデプロイ
  • Roslynによる実行時コンパイル
  • 破壊的変更がある
    • プロジェクトファイルはkprojに変わる
    • System.Webがなくなる
  • オープンソース化（aspnet）

おわりに

実はASP.NET MVCを触るのは初めてでした。が、じんぐるさんが非常に丁寧に説明してくださったので、 チュートリアル程度のものであれば自分でもって気持ちになれました。

きよくらさんの発表はなかなか驚きな内容も含まれていて、非常に興味深いものでした。 vNEXTになってこのままSystem.Webが消失すれば、阿鼻叫喚の地獄絵図になったりするのでしょうか。 でもまだアルファの話なのでなんとも言えませんが。

では最後にじんぐるさんがこれは見とけっておっしゃっていた参考資料を載せておきます。

Amazonのほしい物リストの設定変更の方法がヘルプと違った

なんかすごい迷ったのでメモ

ほしい物リストの配送先がずっと引っ越し前の住所だったのに気づいたから直そうと思ったんですが、パッと見わからなかったのでヘルプ（Amazon.co.jp ヘルプ: ほしい物リストの商品のお届け先）を見たらこんなふうに書いてありました。

f:id:hidari-yori:20140727130024p:plain

手順だけ抜粋すると

  1. サイト右上のほしい物リストをクリックします。
  2. 左側のお名前の下にプロフィールが表示されていない場合は「プロフィールを表示」をクリックします。
  3. 「プロフィールを更新する」をクリックします。
  4. お届け先住所の項目で、住所を更新します。
  5. 保存するボタンをクリックします。

ということでした。これにしたがって進めると

f:id:hidari-yori:20140727130111p:plain

うん、左側には「プロフィールを表示」も「プロフィールを更新する」もない。

どこにあるのか

商品が表示されてる部分の上の、この辺。

f:id:hidari-yori:20140727130152p:plain

の中のこれ。

f:id:hidari-yori:20140727130240p:plain

誤った指図って感じ。小一時間迷ってしまった。

終わりに

なお、無事に変更できましたのでいつでもお待ちしております。

Amazon.co.jp: : 乞食リスト

Chocolateyのインストール場所が変わるとか

Powershell

最近

Chocolateyを使っていると、こんなメッセージが表示されるようになった。

The default install location has been changed to 'C:\ProgramData\chocolatey'.
  This install will be updated to that location in the next version. It
  is strongly suggested you move this installation to the new location
  as soon as possible to limit write access from all users. Do not forget
  to update PATH & ChocolateyInstall environment variables.

簡単に言うと、

権限的な制約が必要だから次のバージョンではインストール場所が変わるよ！
だから今のうちに変更することを強くオススメ！そのときは忘れずに環境変数を変更すること、
いいね？

みたいな感じのことが書いてある。

これはVersion0.9.8.24時点でデフォルトのインストール場所がC:\ChocolateyからC:\ProgramData\chocolateyに変わったためらしい。 この変更の理由はgithubにあるwikiのDefaultChocolateyInstallReasoning ・ chocolatey/chocolatey Wikiを見ると書いてある。

インストール場所を変更するには

  1. C:\ChocolateyをまるごとC:\ProgramData\chocolateyに移動
  2. 環境変数ChocolateyInstallをC:\ProgramData\chocolateyに変更する
  3. 環境変数Pathの中にあるChocolateyのパスをC:\ProgramData\chocolatey\binに変更する

以上、これだけ。

おわりに

間違ってたらごめんなさい（ﾋﾞｸﾋﾞｸ

あ、ちなみに最近インストールした場合はデフォルトで新しい場所にインストールされるからこの警告は出ません。