博多鶏ソバ華味鳥

ソラリアステージ地下 2 階の飲食店街がリニューアルして、 何店舗か新しい店に入れ替わっていた。 その新しい店の一つが、『博多鶏ソバ華味鳥』。 以前水炊きの方の華味鳥があった場所にオープンしたので行ってみた。

注文したのは『博多極上鶏白湯ソバ』。あと『唐揚げ』。 ランチタイムだと俵ごはんが付いてきた。

博多極上鶏白湯ソバ。 麺は中細麺でもちっとした食感だった。 スープは濃厚でいて上品で、さすが華味鶏といったところ。 鶏肉のチャーシューはアッサリしていて、スープと良い対比になっていた。 あと、具の野菜がとても甘かったのは驚き。

唐揚げはあっさりと、これまた上品な味付け。 確か、味付けに水炊きスープを使っているって記事で読んだことがあったな。 この唐揚げだけでも食べる価値ある。

最後に俵ごはんにスープをかけて、雑炊風にして食べたけど、これまた美味。 水炊きの〆は雑炊だからね。 鶏白湯のスープでも合う。 間違いない。

期待通りのクオリティで満足。 夜は居酒屋メニューが出るようだけど、 ランチタイムの方が俵ごはんが付いたり、唐揚げが安かったりとお得。 次も行くなら昼だな。 他にも水炊きラーメンと濃厚味噌ラーメンがあったので、いずれ食べたい。

関連ランキング:ラーメン | 天神駅西鉄福岡駅(天神)天神南駅

ペーパープロトタイピングファースト

Xamarin が個人開発者なら無料で使えるようになったので、 さっそく iOS アプリを作り始めた。 いつもならすぐにコードを書き始めるんだけど、 今回はちょっとやり方を変えて、 ペーパープロトタイピングから始めている。

ペーパープロトタイピングの良いところは、なんといっても、紙とペンさえあれば出来る手軽さ。 作るのも修正するのも簡単なので、試行錯誤するのに最適。

仕事でアプリを作っている人なら、 ペーパープロトタイピングはもはや当たり前にやっていることだと思う。 その有効性については、ネットで検索すればたくさん記事が見つかる。 ただ、プライベートプロジェクトとなると、ついコードを書きたくなってしまうんだよね。 過去にプライベートで作ったアプリは、どれもすぐにコーディングに入っていた。

これまでを振り返ると、コード書いていて手が止まったときって、 UI をどうしようって考えるときが大半だった。 デザインと導線を固めてからコーディングに着手することで、 開発時間が短縮できるのではという期待感はある。

ペーパープロトタイピングだけだと、 導線の良し悪しが分かりづらい。 そこで、POP というアプリを使って、 ペーパープロトタイピングからモックを作っている。

popapp.in

紙に書いた絵をカメラで取り込んで、 画面遷移などの簡単な動きをつけることで、 実際のアプリに近いモックが作れる。 便利。 あと、POP はスケッチパッドの PDF を Web で公開しているので、 それを使わせてもらっている。

https://popapp.in/sketchpad/

なんで今回ペーパープロトタイピングから始めたかというと、 プライベートでアプリの開発時間を捻出するのが難しくなった、 というのが主な理由。 1日30分がせいぜい。 その時間を最大限有効に使いたい。 ペーパープロトタイピングなら、やろうと思えばどこでも出来る。 それこそ、電車の中でも。 POP を使ってモックを作る作業なんかは、電車の中や 隙間時間でやるのにもってこい。

自分みたいに、 なかなかプライベートでまとまった開発時間を捻出できない人がアプリを作るなら、 このやり方が適しているんじゃないかな。 まぁ、まだ成功したわけじゃないから断言はできないけど。 今回上手くいったら、ずっと同じやり方を続けていこうと思う。

Xamarin 実質無料

Build 2016 で Xamarin が Visual Studio に付いてくるって発表があった。 しかも全エディション。 Community Edition にも付いてくるから、個人開発者は実質無料ってことになるね。

www.publickey1.jp

Xamarin Studio は Visual Studio Community Editionと同じようなライセンスらしいので、 Macユーザーも個人開発者は実質無料。 いやぁ、驚いた。

2月に Microsoft が Xamarin を買収することを発表してから、 .NET 開発者はみんな期待していたんじゃないかな。 ライセンス料が安くならないかなって。 Xamarin のライセンス高かったからね。

大多数の希望は無料化。 Microsoft が Xamarin のライセンスで儲けることが目的とは思えないし、 むしろ無料で提供して C#iOSAndroid のアプリを開発する人を増やし、 あわよくば Windows のプラットフォームにも同じアプリを出してもらう。 そのほうが、Objective-C をビルドしたり、 Android アプリを頑張って動かすよりも健全に思える。 一部で、MSDN に含まれる方向が現実的って意見も見かけたけど。

Microsoft は開発者の期待に見事答えてくれた。 ランタイムがオープンソース化されるから、むしろ期待を超えてきた。 ソースコードが公開されたら読みたいね。

さっそく MacBook に Xamarin Studio 入れてみた。 とっつきにくいなって思ったのは最初だけ。 慣れてくると良いかもって思えるようになってきた。 操作性や機能を Visual Studio と比べるのは酷ってものか。 そこは Rider に期待。 ReSharper や IntelliJ IDEA 開発元の JetBrains が作る、クロスプラットフォームで動く .NETIDE。 楽しみだ。

クロスプラットフォームでアプリ開発というと、以前 RubyMotion を使ったことがある。 Objective-C が嫌だったのと、Ruby で開発できることに魅力を感じて、一度ライセンスを購入した。 ただ、すぐ後に Swift が出て RubyMotion めっきり触らなくなったな。 そして今度は Xamarin。 普段一番使っている C#iOSAndroid のアプリが書ける。 しかも全機能が無料。 自分はもう RubyMotion を使うことは無いだろうな。

ちょうど作りたいアプリがあったので、Xamarin でアプリを何個か作ってみようと思う。 気になるのはライブラリ。 RubyMotion では CocoaPods が使えた。 Xamarin ではどうなんだろう。 もし Objective-CSwift で書かれたライブラリが使るのだとしたら、開発が捗りそうだ。 その辺りは作るときに調べて、ブログに書くとしますかな。

Entity Framework でエンティティを削除したら取得済みエンティティの外部キーが null になっていてハマッた

Id の型に int ではなく string を使った

public class Item
{
    public string Id { get; set; }
    public string ProjectId { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }
}

のようなエンティティで

public class ItemController : Controller
{
    // ...(省略)...

    [HttpPost]
    public async Task<ActionResult> Delete(string itemId)
    {
        var item = await DbContext.Items.FindAsync(itemId);

        DbContext.Items.Remove(item);
        await DbContext.SaveChangesAsync();

        return RedirectToAction("Index", new { projectId = item.ProjectId });
    }
}

という風に削除した後リダイレクトするコードを書いたら、リダイレクト失敗。 削除した時点で変数 itemProjectId プロパティ が null になってしまうことに気付かなくてハマッた。

今まで Id の型に int だけを使ってきたけど、そのときは ProjectId が 0 になるなんてことは無かった。 初めて string に変えてみたんだけど、まさか削除したら外部キーが null になるとはね。

デバッガで追ってみたけど、null になるのは外部キーの item.ProjectId だけで、 item.Iditem.Title は null になっていなかった。

とりあえず今回は、単純にリダイレクトに必要な値を、削除前に変数に保持しておくことで回避。

public class ItemController : Controller
{
    // ...(省略)...

    [HttpPost]
    public async Task<ActionResult> Delete(string itemId)
    {
        var item = await DbContext.Items.FindAsync(itemId);
        var projectId = item.ProjectId;

        DbContext.Items.Remove(item);
        await DbContext.SaveChangesAsync();

        return RedirectToAction("Index", new { projectId });
    }
}

PostgreSQL の pgbench みたいな SQL Server 用ベンチマークツール

実際に発行する SQL を使ったベンチマークSQL Server でやりたいので、 使えそうなツールを探してみた。

必要な機能は次の通り。

  • ODBC 接続
  • ファイルから SQL を読み込んで実行
  • サーバーとデータベースを指定できる
  • 回数を指定して同じ SQL を繰り返し実行できる
  • 並列数を指定して同じ SQL 同時に複数実行できる

PostgreSQL なら pgbench があるのに。 同じようなツールが SQL Server に標準で付いていないのかな。

標準ではないけど、ベンチマークに使える Microsoft 製のツールは見つけた。

このユーティリティに含まれている ostress で、pgbench と同じようなことができた。

例えば、「Test.sql ファイルから SQL を読み込んで、ローカルの SQL Server Express にある TESTDB データベースに 10 回実行」する場合、 こんな感じ。

ostress -E -S"(local)\SQLEXPRESS" -r10 -d"TESTDB" -i".\Test.sql"

GRAMERCY NEWYORK

大丸のグラマシーニューヨークが気になっていたので、ちょっと奮発して買ってみた。

この店はニューヨークチーズケーキが売りなんだけど、目をつけていたのは生ケーキ。いやもうね、ショーケースの中で存在感があったんでね。

パリパリのチョコで挟まれたケーキなんて初めて。ケーキ本体はもちろん美味かったけど、それよりも横のチョコが美味かった。こいつだけ食べたいくらい。

ショートケーキも気になっていた。というかこちらが本命。

生クリームが軽くて、結構大きいのに一気にフォークが進んだ。中のイチゴは少なめ。ただ、代わりのイチゴクリームが良いアクセントになってた。

関連ランキング:ケーキ | 西鉄福岡駅(天神)天神南駅天神駅

理性捨てて props 全部渡していたら react-router でハマった

react-router で遷移先のコンポーネントに props を渡すには React.cloneElement を使う。

tnakamura.hatenablog.com

このとき、理性捨てて

this.props.children && React.cloneElement(this.props.children, this.props)

という風に props をまるごと渡していたら、 Route を二段入れ子にしていた場合に children を上書きしてしまうみたいで、 コンポーネントの描画が再起しまくって死亡した。

this.props.children && React.cloneElement(this.props.children, {
  users: this.props.users,
  posts: this,props.posts,
})

みたいにして children は除外しないとダメ。