行く予定なかったんだけど、時間ができたので、 オープンした最初の週末だというのに行ってしまった。
KITTE の 1 階から 7 階までは博多マルイが入っていて、 マルイがそうなのか、博多だけなのかは分からないけど、 雑貨屋が非常に多かった。ファッションは少なめ。
地下と 9・10 階は飲食店街になっていた。気になるのは串カツ田中ぐらいかな。 それよりも 1 階の食品フロアの方が断然賑わっていた。 デパ地下ならぬデパ地上。 玉子サンドとメロンパンアイスは興味あったけど、あまりの混雑っぷりに断念。 夕方に行ったのにこの人混みは参った。
ゴールデンウィークは凄まじいだろうな。 もう少し落ち着いてから、また行くとしよう。
パルコ新館1Fにある『ゴントランシェリエ』はオープンしてから長い間、 昼間行列が絶えなかったけど、落ち着いてきたみたいだ。
もちろん賑わっているけど、並ばないと買えない、数に制限がある、 ということが無くなって行きやすくなった。
今回は久々なので、定番のパンを購入することに。 まずは定番中の定番、『クロワッサン』。
噛んだときの歯ごたえがザクザクっとしていて香ばしい。 カラッとしていて、手があまりベタッとならなかった。 完成度高い。
お次は、これまた定番の『パン・オ・ショコラ』。
中のチョコは甘さと苦さが自分好み。 甘すぎても苦すぎてもダメ。 福岡市内のパン屋の中でも、この店のは良い線行ってる。 パリでは人気 No.1 というのも納得。
最後が、自家製クリームがサンドされた『ヴィエノア ミルククリーム』。
このパン、中のクリームが非常にアッサリしている。 濃厚な味を予想していたら、まさかの軽い口当たりで、 予想と実際のギャップに一番驚いた。 もちろん美味。
クロワッサンとパン・オ・ショコラがどちらも自分好みの店は、 福岡で初めてな気がする。 フランスパンを食べたくなったときのファーストチョイスになりそうな予感。
pgbench で実行できる独自スクリプトでは、変数や乱数、スリープがが使える。 これらを組み合わせることで、10 ～ 20 秒範囲のランダムなスリープを設けることができた。
SELECT * FROM customers \setrandom wait 10 20 \sleep :wait s SELECT * FROM products
ソラリアステージ地下 2 階の飲食店街がリニューアルして、 何店舗か新しい店に入れ替わっていた。 その新しい店の一つが、『博多鶏ソバ華味鳥』。 以前水炊きの方の華味鳥があった場所にオープンしたので行ってみた。
注文したのは『博多極上鶏白湯ソバ』。あと『唐揚げ』。 ランチタイムだと俵ごはんが付いてきた。
博多極上鶏白湯ソバ。 麺は中細麺でもちっとした食感だった。 スープは濃厚でいて上品で、さすが華味鶏といったところ。 鶏肉のチャーシューはアッサリしていて、スープと良い対比になっていた。 あと、具の野菜がとても甘かったのは驚き。
唐揚げはあっさりと、これまた上品な味付け。 確か、味付けに水炊きスープを使っているって記事で読んだことがあったな。 この唐揚げだけでも食べる価値ある。
最後に俵ごはんにスープをかけて、雑炊風にして食べたけど、これまた美味。 水炊きの〆は雑炊だからね。 鶏白湯のスープでも合う。 間違いない。
期待通りのクオリティで満足。 夜は居酒屋メニューが出るようだけど、 ランチタイムの方が俵ごはんが付いたり、唐揚げが安かったりとお得。 次も行くなら昼だな。 他にも水炊きラーメンと濃厚味噌ラーメンがあったので、いずれ食べたい。
Xamarin が個人開発者なら無料で使えるようになったので、 さっそく iOS アプリを作り始めた。 いつもならすぐにコードを書き始めるんだけど、 今回はちょっとやり方を変えて、 ペーパープロトタイピングから始めている。
ペーパープロトタイピングの良いところは、なんといっても、紙とペンさえあれば出来る手軽さ。 作るのも修正するのも簡単なので、試行錯誤するのに最適。
仕事でアプリを作っている人なら、 ペーパープロトタイピングはもはや当たり前にやっていることだと思う。 その有効性については、ネットで検索すればたくさん記事が見つかる。 ただ、プライベートプロジェクトとなると、ついコードを書きたくなってしまうんだよね。 過去にプライベートで作ったアプリは、どれもすぐにコーディングに入っていた。
これまでを振り返ると、コード書いていて手が止まったときって、 UI をどうしようって考えるときが大半だった。 デザインと導線を固めてからコーディングに着手することで、 開発時間が短縮できるのではという期待感はある。
ペーパープロトタイピングだけだと、 導線の良し悪しが分かりづらい。 そこで、POP というアプリを使って、 ペーパープロトタイピングからモックを作っている。
紙に書いた絵をカメラで取り込んで、 画面遷移などの簡単な動きをつけることで、 実際のアプリに近いモックが作れる。 便利。 あと、POP はスケッチパッドの PDF を Web で公開しているので、 それを使わせてもらっている。
なんで今回ペーパープロトタイピングから始めたかというと、 プライベートでアプリの開発時間を捻出するのが難しくなった、 というのが主な理由。 1日30分がせいぜい。 その時間を最大限有効に使いたい。 ペーパープロトタイピングなら、やろうと思えばどこでも出来る。 それこそ、電車の中でも。 POP を使ってモックを作る作業なんかは、電車の中や 隙間時間でやるのにもってこい。
自分みたいに、 なかなかプライベートでまとまった開発時間を捻出できない人がアプリを作るなら、 このやり方が適しているんじゃないかな。 まぁ、まだ成功したわけじゃないから断言はできないけど。 今回上手くいったら、ずっと同じやり方を続けていこうと思う。
Build 2016 で Xamarin が Visual Studio に付いてくるって発表があった。 しかも全エディション。 Community Edition にも付いてくるから、個人開発者は実質無料ってことになるね。
Xamarin Studio は Visual Studio Community Editionと同じようなライセンスらしいので、 Macユーザーも個人開発者は実質無料。 いやぁ、驚いた。
2月に Microsoft が Xamarin を買収することを発表してから、 .NET 開発者はみんな期待していたんじゃないかな。 ライセンス料が安くならないかなって。 Xamarin のライセンス高かったからね。
大多数の希望は無料化。 Microsoft が Xamarin のライセンスで儲けることが目的とは思えないし、 むしろ無料で提供して C# で iOS や Android のアプリを開発する人を増やし、 あわよくば Windows のプラットフォームにも同じアプリを出してもらう。 そのほうが、Objective-C をビルドしたり、 Android アプリを頑張って動かすよりも健全に思える。 一部で、MSDN に含まれる方向が現実的って意見も見かけたけど。
Microsoft は開発者の期待に見事答えてくれた。 ランタイムがオープンソース化されるから、むしろ期待を超えてきた。 ソースコードが公開されたら読みたいね。
さっそく MacBook に Xamarin Studio 入れてみた。 とっつきにくいなって思ったのは最初だけ。 慣れてくると良いかもって思えるようになってきた。 操作性や機能を Visual Studio と比べるのは酷ってものか。 そこは Rider に期待。 ReSharper や IntelliJ IDEA 開発元の JetBrains が作る、クロスプラットフォームで動く .NET 用 IDE。 楽しみだ。
クロスプラットフォームでアプリ開発というと、以前 RubyMotion を使ったことがある。 Objective-C が嫌だったのと、Ruby で開発できることに魅力を感じて、一度ライセンスを購入した。 ただ、すぐ後に Swift が出て RubyMotion めっきり触らなくなったな。 そして今度は Xamarin。 普段一番使っている C# で iOS と Android のアプリが書ける。 しかも全機能が無料。 自分はもう RubyMotion を使うことは無いだろうな。
ちょうど作りたいアプリがあったので、Xamarin でアプリを何個か作ってみようと思う。 気になるのはライブラリ。 RubyMotion では CocoaPods が使えた。 Xamarin ではどうなんだろう。 もし Objective-C や Swift で書かれたライブラリが使るのだとしたら、開発が捗りそうだ。 その辺りは作るときに調べて、ブログに書くとしますかな。
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 }); } }
という風に削除した後リダイレクトするコードを書いたら、リダイレクト失敗。
削除した時点で変数 item の ProjectId プロパティ が null になってしまうことに気付かなくてハマッた。
今まで Id の型に int だけを使ってきたけど、そのときは ProjectId が 0 になるなんてことは無かった。 初めて string に変えてみたんだけど、まさか削除したら外部キーが null になるとはね。
デバッガで追ってみたけど、null になるのは外部キーの item.ProjectId だけで、
item.Id や item.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 }); } }
