mof-brown

ずっとモフモフしてたい

無線 LAN 中継器 BUFFALO 「WEX-1160DHP」を買ってみた

我が家は 2F のリビングに親機があるのだけど、1F の端の方まで無線が届かないのでちょっと困っていた。

ビックカメラで中継器を物色してみて、BUFFALO の WEX-1160DHP が良さそうだったので買ってみた。

親機ルーターWPS に対応してなかったので手動で接続。それでもとても簡単に設定できた。コンセントに指すだけなのもお手軽で良い。

おかげで 1F の通信も良好、1F のトイレでネットできるようになった。

都内近郊の電車・新幹線スポット

子どもが大好きな電車と新幹線。ウチの息子も例に漏れず大好きで、定期的にスポットに遊びに行ったりおもちゃやらなんやらを買ってるので、そのへんの情報をちょっとまとめてみる。

東京駅

新幹線を見に行きたい時はここ。入場料払うだけなのでお財布にも優しい。

はやぶさ・こまちの連結部分は人気スポット。 帰りに新幹線の箱に入ったお弁当買ったりしても良いと思う。

ただし誤って東京駅一番街の方に流れてしまうと、プラレールトミカポケモンやらのショップが押し寄せてくるので要注意。

日暮里駅トレインミュージアム (下御隠殿橋)

日暮里駅を降りて目の前にある陸橋から見えるスポット。電車も新幹線もガンガン通る。上から見下ろすことになるので、電車の屋根って汚いんだなぁ・・・というのも実感できるスポット。

新宿サザンテラス

新宿駅の新南口を出たところ。あまり人が多くないのと、カフェが近くにあるのでまったりできる。

プラたく (京成高砂)

https://tabelog.com/tokyo/A1324/A132403/13143563/

お店の中を走るプラレールを見ながら食事ができるカフェ。カフェとしての評価は普通だけど子どもは楽しめる。

鉄道博物館 (大宮)

www.railway-museum.jp

都内から行ける超有名な博物館。 特に0系新幹線が見れるのがポイント高い。0系の顔かわいい。

地下鉄博物館 (葛西)

www.chikahaku.jp

小さい博物館なのでさっと回って終わってしまうけどまぁ暇つぶしに。あと、うちの息子は地下鉄だと外の景色が見れないのであんまり好きじゃないっぽい。

東武博物館 (東向島)

www.tobu.co.jp

個人的に東武線は馴染みが無いのだけど、シミュレーションが充実しているので結構楽しめる。

都電荒川線荒川車庫 おもいで広場

この前イベントやってたので車庫の方まで見ることができたけど、普段は公開してないみたいなのでイマイチかも。

思い出したらまた書く。

2016年を振り返る

今年も1年を振り返ってみたいと思います。

昨年は↓のようなことを書いていました。 mof-brown.hatenablog.com

取締役CTO として動いた1年

昨年10月に株式会社まちいろにジョインして、今年は CTO という役職に向き合う1年でした。

これまで社長が技術・営業両面の中心を担っていたところを、技術部分を自分が巻取るため、開発環境を整備したりルール・フローを変えたりしました。

tech.machiiro.jp

自分自身もプロジェクトに参画しながらこういった施策を動かしていたので、これまでで一番忙しい1年でしたが、 年末メンバーに「会社らしくなってきましたね」と言ってもらえたのが嬉しかったです。来年も頑張ります。

子供が3歳になった

生意気なことを言うようになってきました。小賢しくて可愛いです。 まだオムツ卒業できてなくてお父さん心配です。

勉強した技術

今年は Ruby 中心でした。来年は iOS/Android に手を付けます。

3歳児を連れて金沢へ行ってきた

10月に2泊3日で金沢へ行ってきたのでその記録を。

1日目

初日はあいにくの雨。

子供に新幹線に乗せてあげると約束していたので、今回の主目的は「かがやき」に乗ること。
かがやきを待っている間にこまち・はやぶさが入り乱れて、息子はテンションMAXだった。

お弁当に「極撰炭火焼き牛タン弁当」買ったらほとんど息子に食われた。。。

www.ekiben.or.jp

f:id:kosuke0620:20161104001011j:plain

f:id:kosuke0620:20161104001055j:plain

金沢駅に到着。かがやきデザインで統一されてて可愛い。

まずは21世紀美術館へ。

この美術館、展示物に近づく雰囲気を出すだけでも注意されたりするので、子供連れで行くのはオススメしません。
何度か注意されながら回ったので、落ち着いて見れなかった。

いくつかの展示ルームは写真撮影 OK だったので何枚か撮った。
有名なスイミング・プールは雨のため外から見学ができなかった。残念。

その後、ホテルにチェックインして休んでからひがし茶屋街へ。
この頃雨が強くなってきたので、軽くお土産を物色して早々にホテルに退散。

茶屋街は日が暮れてからの雰囲気がとても良かった。雨さえ降っていなければもっと楽しめたのだが。

夜はその辺の居酒屋に行けばうまいもん食えるだろ、と思って適当に入ったら失敗した。
確かに刺し身はうまかったけど、他の料理は安い居酒屋の料理って感じ。

というわけで、1日目は何だか散々な感じで終わった。

2日目

雨が止んで曇りまで回復。

f:id:kosuke0620:20161104001439j:plain

午前中は兼六園を散歩。結構広いので、子供と一緒に歩くと回るのに結構時間かかった。

f:id:kosuke0620:20161104001705j:plain

兼六園を出たら「サケマルシェ」というイベントやっていたので、お昼がてらご当地グルメを堪能。
牛すじ丼がめっちゃうまかった。今度家で作ろう。

f:id:kosuke0620:20161104002134j:plain

その後金沢駅で寿司を食ってから、特急で加賀温泉駅へ移動。今回の旅行はホントよく電車に乗る。

金沢の温泉というと和倉か加賀になるけど、今回は加賀にしてみた。(深い理由は無い)
でも最近は和倉が人気の模様。

f:id:kosuke0620:20161104002405j:plain

加賀温泉に到着。前回の沖縄とは違って、今回は周りが山だ。

f:id:kosuke0620:20161104002439j:plain

あとは温泉入って食うだけ。カニうめえノドグロうめえ。

3日目

この日は晴れ。

チェックアウトして加賀温泉駅に向かうと、駅の裏側に金色の加賀大観音が・・・!
来た時は気づかなかった。。

www.itamiwake.com

加賀温泉駅から金沢駅に戻ったら近江町市場へ移動。
タクシー乗り場に篠山紀信さんがいた。さすが芸術の街。

f:id:kosuke0620:20161104004351j:plain

近江町市場に着いたらおでん、串焼き、鰻、かき、コロッケなどなど食べ歩き。金沢でここが一番満足度が高い気がする。

f:id:kosuke0620:20161104003425j:plain

近江町市場からの帰りがけに、初日に撮れなかった金沢駅を撮影。オシャレ。

てな感じで今回の金沢旅行は終了。

反省点

  • 兼六園、茶屋街、近江町市場などは地味に距離があるので、晴れていれば自転車借りると良い
  • 近江町市場に行く時間が取れるなら、ここで金使った方が満足度高い
  • 幼児がいる場合、21世紀美術館は行かないほうが良い

プラレール博 in TOKYO に行ってきた

GW の最終日、2歳半の息子を連れて幕張メッセで行われていたプラレール博に行ってきた。

www.takaratomy.co.jp

今回のプラレール博は入場記念品として北海道新幹線の中間車両がもらえる。
中間車両ってのがポイントで、今販売している北海道新幹線プラレールと連結できるのだ。うまい商売だ。

というわけで中間車両をもらって中に入ると、スタンプラリー用のスタンプ帳を販売していた。1冊200円。コンプリートすると記念のシールがもらえるらしい。まったくうまい商売だ。

スタンプラリーを進めつつ、展示コーナーを進んでいく。
息子は親と一緒にいる時は基本おしゃべりなのだが、好きなものに対しては集中するのか無言になる。 彼からしたら天国のような場所なのだろう、無言で動き回るのでちょっと目を離した隙にいなくなることが何回かあった。 会場入口に迷子シールが置いてあったので一応貼っておいたのだが、なるほど必要だなと思った。

あと、展示コーナー途中にあったプラレールの巨大ジオラマは、思わず大人も色々買い揃えたくなってしまうほどのインパクトがあった。
特に車両基地が大量に並んでるのがめちゃくちゃカッコ良かった。

展示コーナーを見終えると、次はアトラクションコーナー。
ここではチケット制で色々なアトラクションに挑戦でき、アトラクション毎に異なる限定のプラレール (今回は金メッキ車両が目玉?) がもらえたりするのだ。まったくもってうまい商売だ。
どのアトラクションも30〜40分ほど並んでいたので、はやぶさに1回乗った後にアトラクションを2回やった。

最後はグッズコーナーで限定色レールと新しいプラレールを買って帰った。
息子は電車!と言いながらひかりレールスターを選んでいたのが謎だった。

家に帰ると、早速今日の戦利品を息子が魔改造してて笑った。

f:id:kosuke0620:20160508221903j:plain

「SQLアンチパターン」を読んだ

今更ながら、会社にあった「SQLアンチパターン」を読んだ。

SQLアンチパターン

SQLアンチパターン

いくつかドキッとするようなアンチパターンが合って勉強になったが、
中には、そもそもその設計だと実現できないからやらない、っていうパターンもちらほらある。
アプリケーション開発の章は常識的な内容なので、本書を手にとった方・気になっている方には退屈だと思う。

データベース論理設計のアンチパターン

カンマ区切りフォーマットのリストを格納した列を定義する

データの整合性の担保ができない、インデックス検索できないなどの問題がある。
非正規化の一例ではあるので、よく検討した上で採用するのであればOK。

階層構造

単一階層を持たないのであれば、「常に親に依存する」形でもOK。
複数階層を表す場合は、「経路列挙」か「閉包テーブル」を採用する。
(経路列挙の方が実装は楽)

全てのテーブルに ID 列を用いる

ORM の都合で用意する必要があったりもするケースバイケースで。
ActiveRecord では primary_key の設定が可能。

外部キー制約を使用しない

DB 分割を考慮した場合でも、制約を使用した方が良いのであれば使用する。

汎用的な属性テーブルを使用する

システムのメタ情報とかに使う分には問題ないと思う。

二重目的の外部キーを使用する

普段からやらない。

複数の列を定義する

tag1tag2tag3 みたいな列定義について。
普段からやらない。

テーブルや列をコピーする

t_sales_2015t_sales_2016 みたいな運用について。
普段からやらない。

データベース物理設計のアンチパターン

FLOAT データ型を使用する

丸め誤差が発生する可能性があるので、NUMERIC/DECIMAL 型を使うこと。

限定する値を列定義で指定する

ミドルウェアが確定しているなら、別に ENUM 使っても良いと思う。

物理ファイルの使用を必須と思い込む

普段からやらない。
容量の問題が無ければ、基本は BLOB 型で DB に格納する方向にしている。

闇雲にインデックスを使用する

普段からやらない。

NULL を一般値として使う

可能であれば NOT NULL 制約か DEFAULT を定義するようにしている。

非グループ可列を参照する

SELECT id, max(xxx) ... GROUP BY で取得した各行に対して、xxx 以外の列を取得する方法について。
普段からやらない。

データをランダムにソートする

RANDOM 関数を使ったランダム処理について
普段からやらない。アプリ側で処理する。

パターンマッチ術後を使用する

like 検索について。
データ件数を考慮して、問題ないのであれば使ってもOKでは。

複雑な問題をワンステップで解決しようとする

複雑な SQL で一発で情報を取得する事について。
普段からやらない。1個ずつ投げた方が早い。

ショートカットの罠に陥る

SQL 構文の省略による弊害について。
ORM 使うことが多いので、特に問題とはならない。
直接 SQL 書くときは注意する。

アプリケーション開発のアンチパターン

パスワードを平文で格納する

普段からやらない。

未検証の入力をコードとして実行する

SQL インジェクションの話。 パラメータを使って SQL を組み立てることはNG。

隙間を埋める

ID 列が連番になっていない時に、空いたIDを再利用するなど。 普段からやらない。

肝心な部分を見逃す

ただのクソコード。

SQL を特別扱いする

DB 側も、アプリケーションコードのようにバージョニングしたりテストしたりしましょうという話。 最近は ER図やマイグレーションスクリプトを管理している。

モデルがアクティブレコードそのもの

まさに今一番悩んでいるところ。 ファットモデルを避けるために、DDD を採用して サービス層を作るのが良いと思ってる。

想定不足

ベンチマークを取る、テスト環境を作る、例外を考慮して実装する、バックアップは万全にしておく、マシン自体が死ぬことを想定しておく。

エンジニアとして心がけていること

最近社内の開発メンバーに「自分はこういうことを意識してやってるよ」的な話をする機会が増えてきたので、まとめて書き出してみた。

会社で掲げている行動理念とは別で、あくまで個人的に意識していること。 http://www.machiiro.jp/cto_message/

開発周り

命名には気を使う

プロジェクト名、クラス名、変数名…開発を行う上で命名を行うシーンは多い。

命名をするにあたって、

  • 対象の責務に合わせた名前にする
  • 一般的な名称、単語があれば、なるべくそれを使用する
  • 統一感を持たせる

といったことを意識するようにしている。

これだけでコードの可読性が上がったり、grepリファクタリングがしやすくなる。

typo しないよう意識する

typo は恥ずかしい上に、grep の妨げになるので、なるべく起きないように意識している。

具体的には

  • 怪しいと思ったらその単語で検索する
  • コピペするか、体が覚えるようにわざと手で入力する

といったことをしている。

いつ開発環境が壊れても良いようにしておく

ローカルに重要な情報は持たないようにする。
ソースコードは全て git に、ファイルは全てクラウドサービスなりファイルサーバー上に置く。

ツールの設定は端末間で共有できるようにする。
難しい場合はデフォルト設定で利用するか、最悪設定手順をまとめておく。

メール、デスクトップは常に整理整頓しておく

メーラーの Inbox にメールは溜めない。
メールが残っている=タスクが残っている。

デスクトップにファイルを置いたままにしない。
もしくは後で消しても問題ないようなものだけ置いておき、定期的に削除する。

実装に詰まる=「考えが足りない」

追加開発や仕様変更が発生した場合に、その実装がちょっとスムーズに出来ないような場合は、
恐らく元々の仕様に「何か考えが足りない」、と思うようにしている。

実際には単純に実装が大変なだけだったりすることもあるが、
何か別の仕様を入れることで、シンプルに問題が解決できることもある。

サービスやプロダクトの開発をしている時は特に意識している。

余計な機能は開発しない (けど考えておく)

初期段階では不要だけど後々必要だろうな…という機能は大抵必要とならないので実装しない。
必要になってはじめて気付くことが出来る要件もあったりするので、不用意に先行して開発はしない。

ただし、何時でも開発できるように頭の中で設計だけはしておく。

課題のバックグラウンドを共有する

自分が誰かにタスクを依頼する場合でも依頼される場合でも、
その課題のバックグラウンドを伝える、もしくは共有するようにする。

バックグラウンドを知ることで初めて出てくるアイディアもある。
また、関係者が当事者意識を持ちやすくなる。

作業を共有するのではなく、あくまで課題を共有する、という意識を持つ。

自己成長周り

身に付ける技術・スキルを厳選する

関連する全ての技術を深く掘り下げて学習することは、現実的に難しいので、
身に付ける技術・スキルは厳選するようにしている。

判断材料としては

  • 興味があるか
  • その技術は将来性、発展性があるか
  • 直近または近い将来の業務に対して、良い影響を与えそうかどうか

など。

周りの期待値を少しでも超えるアウトプットを意識する

上司や先輩、同僚が持っているであろう期待値を、
少しでも超えるアウトプットを出すよう常に心がける。

例えば、

  • 仕様
  • デザイン
  • 性能
  • スケジュール
  • マネジメント

などを、本来の期待値以上のものにする。

端的に言うと、身近な人に「これすげーじゃん!」って言ってもらいたい :)