2017-05-10

注意！6月から郵便料金が改定されます。

マネー

http://www.post.japanpost.jp/notification/pressrelease/2016/00_honsha/1222_01_02.pdf

ハガキやゆうメールなどが値上げされます。
追加料金分の切手を一緒に貼れば使えますが、懸賞などのハガキなどは、早いうちに出した方が良さそうです。
（暑中見舞い（かもめーる）を見越してのタイミングなんでしょうか？？）

お年玉付き年賀ハガキの切手シートも、52円と82円のセットです。
お年玉付き年賀ハガキの景品交換は7月18日までなので、確認を忘れている方はぜひお急ぎください。

2017-05-10

名駅のKID-O-KID（キドキド）に行ってきたよ

育児

名駅に行ったついでに、JRゲートモールにできた「KID-O-KID」に行ってきました。

KID-O-KIDとは
どれくらい並ぶ？
中の様子
子供、大ハッスル！！
感想

KID-O-KIDとは

KID-O-KID（キドキド）とは、海外の玩具メーカー「ボーネルンド」が経営する、室内遊具施設です。
入場料を払うと、施設に入って遊べます。
30分が入場料分で無料で、以降は10分ごとに延長料金がかかります。
AEONモールの中にあるプレイランドの、上位互換バージョンという感じでしょうか？

対象は、6ヶ月（寝返り）から12歳（小学生）までとなっており、必ず大人1人以上が付き添う必要があります（別料金）

場内は、飲み物のみ口にすることができます。
トイレはないので、お腹が空いたり、お手洗いに行きたい時は、スタッフにお願いすると中座させてもらえます。
（中座中にも料金はかかるのかな？
調べてなくてごめんなさい。）

どれくらい並ぶ？

GW最終日に行きました。
5組ほど並んでいて、15分くらい待ちました。
「GWにしては、空いてますよ」
と、係の人は言っていました。

入場者によって人数制限があるので、平日なら並ばなくても大丈夫かもしれません。

並んでいる間、息子は柵から身を乗り出して、
「はやくはやく！！あそびたい！」
と言っているようでした。

中の様子

入場料を払うと、IDカードがもらえます。
これで入退場管理をしているようです。

親子連れがいっぱいでした。

遊具によって、自然とゾーニングができているようで、

左手前 : 赤ちゃんゾーン（ポットン落としなど）
右手前 : なりきりキッズゾーン（おままごとや工作キット）
奥 : 体力がありあまってる小学生ゾーン（ボールプールや風船チューブ）

という状況です。

子供、大ハッスル！！

放流直後は固まっていた子供ですが

すぐに遊び始めました！

特におままごとセットは、家より種類も数も豊富なので楽しんでいました。
消防士さんなどの、コスプレ衣装もありましたよ！

大好きな電車もあったし、大工道具セットやブロックもパーツがいっぱいあるから、大作も作れます。

帰る頃には、帰りたく無い！！まだ遊ぶ！！と全身で抵抗して、獲れたてのカツオのようにビチビチ暴れました。

感想

30分があっという間でした。
IDを返却後、延長料金があれば支払います。

この延長料金が恐ろしい！

名駅って、何気に赤ちゃん向きでは無いですよね。
オシャレな服が欲しいな、と思いながらも、ついつい郊外のショッピングモールに足が向きます。

買い物に行く時に、子供（とパパ）を安全に飽きずに遊ばせるにはすごくいい施設です。

けど、買い物が30分で終わると思うか！！

5/19からは1デーパスができるそうなので時間を気にせず遊ばせられますね。

ショップも併設されているので、気に入ったおもちゃは買ってお家で遊ぶこともできます。

小さいお子様がいたら、ぜひ遊びに行ってみてください。

2017-05-09

オブジェクト志向言語を使っていても、オブジェクト志向設計ができているとは限らない。

私の職業はプログラマです。
オブジェクト志向言語の経験は浅いのですが、復帰前後で、試行錯誤をさせてもらえる期間があり、
なんとなく、ようやくオブジェクト志向言語について、考え方の感覚がつかめてきました。

そこで思ったのは、オブジェクト志向言語を使うなら、オブジェクト志向的な設計をした方がいい、ということ。

よく新米プログラマが、アスキーアートと見まごうばかりの深いIF文を書いたり、
全部コミコミのながーーいonClickイベントメソッドを書いたりしますよね。
長くやってると、
「あー、ここ、関数分けた方がいいなぁ」
なんて分かってくる訳ですが、

同じように、オブジェクト志向言語に慣れてくると、
「これ1クラスにまとめた方がいいんじゃない？」
「共通の親クラスを作った方がいい、」
など、理解しやすくメンテや拡張がしやすくなるコツがわかってきます。

プログラミングを効率よく手戻りなく行うために、設計により思考を整理することが必要になります。
思考のポイントが、これまでの手続き型言語（関数志向とでもいうべき？）とオブジェクト志向言語では違うので、
設計手法や、それを書き表すための文書の内容も異なってきます。

その時、UMLなどのオブジェクト志向設計手法を使わずに、機能（関数）ごとに定義する設計方法を使って設計し、オブジェクト志向言語でプログラミングするという、不一致な状態で進めていくとどうなるかというと、
オブジェクト単位に直すために、もう一回データ構造やら処理の流れを整理しなおさなきゃいけなって、
設計が二度手間になります。

そうなるとまぁ、関数志向的な設計に引きずられて、手続き言語的に組むしかなくなって、オブジェクト志向言語の能力（便利なところ）を半分くらいしか引き出せなくなっちゃうんですよね。

そして、その設計に大きな影響を与えるのが、設計書のフォーマット！！

カプセル化など、書くべきことを書く欄がなかったり、「いや、そこまで書くの？？」という欄があったりと、
言語仕様とマッチしないことが多々あります。

書くことって、考えること、伝えることとリンクします。
そのため、書きづらいフォーマットは、誤解を招くなどの弊害があるんですよね(^^;;

もし、システム開発関係の会社さんや、IT部署の方が見ていらっしゃったら、
「開発言語と仕様書のフォーマットがマッチしているか？」
チェックしていただけると、下々のプログラマが救われるかも知れません。
よろしくお願いいたします_:(´ཀ`」∠):_

そういうのって、往々にしてCOBOLなど古〜い時代から使われていて、
フォーマットを決めているのが、その世代で現役だった上長が決めているので、なかなか「今は違う」が、分かってもらえないんですが……

書くことは考えることなので、
「俺、もう現場行かないし。」
という方にも、ぜひ聞きかじりくらいはして、知識のアップデートをお願いいたします。（自戒）

また、
「俺、Javaできるから、オブジェクト志向については分かってる。」
ってドヤってるプログラマの方でも、中には継承とか一切使っていない、
「手続き型言語を、そのまま移植しましたね？」
という、オブジェクト志向の考え方ができない方もいますので、もう一度UMLやデザインパターンあたりをかじってみると良いかと思います。（自戒）

考えること（設計）は、書くこと（プログラミング）に影響しますし、
書くこと（仕様書）は考えること（設計）に影響します。

JavaやC#など、オブジェクト志向言語がアプリケーション開発のメイン言語となって久しいです。
言語が新しくなっても、アタマが古いままでは使いこなせません。
オブジェクト志向言語を使うなら、オブジェクト志向設計で。
強くお勧めします。