もちゅろぐ

お辞儀して顔上げたらおっさんになっていた子どもが大人を目指します。

WHR-1166DHPで現在のチャンネルが-1なったら

Baffalo-A-XXXX が表示されなくなって、ルータ本体のポータルを見ていたら、現在のチャンネルが-1になっていました。

ネットで調べたところ、下記のページで自分と同じ症状の人がいたので、見てみたら色々とアドバイスをもらい試していました結局だめそうでした。

bbs.kakaku.com

ちなみに自分の場合は親機(WHR-1166DHP)を再起動(電源コード抜き差し)したら直りました。

同じ症状でも異なるようですね。

子ども用ハーネスを使って身近な頭の堅い友人を見つけて今度の付き合いを考えればいい

都内で子ども3人を育てています。

ハーネスは犬の散歩みたいと偏見持つ方や、手を繋げばいいと言う方がまだいるようですね。

犬の首輪+ロープもハーネスも車のシートベルト、自転車のチャイルドチェアのベルトも、ベビーカーのベルトも、ヘルメットの紐も同じ目的で、命を守るためです。 もっと言えば車の荷台に載せた荷物をロープで固定するのも同じ目的で、荷物が壊れるだけでなく、荷物が当たって危害を与えないためです。

手を繋げばいいというのは、子どもを育てたことがないか、その子どもが育てやすかっただけですね。 保育園で外出時に子どもを大きい台車みたいなのに乗せるのも、ハーネスも何ら目的は変わらないのに、なぜこっちばかり話題になるのか?

気にしない/距離をおく

おそらく説得しようとしても、理解してもらえないだろうし、その人が理解したところで次々と出てくると思うので、そういう人は言わせておけばいいと思います。 何か知らない人に言われたら「じゃぁシートベルトするなよ」と吐いて捨て置けばいいくらいです。 いちいち価値観の合わない人に接しなくていいです。身近なママ友とかにいれば、共感できる力の弱い方で、価値観も合わないので距離おけばいいです。

忘れてはならない大事なこと

一番大事なのは、大人しか関係のない外の目を気にして、子どもが最悪の事態になることです。 自分の意思の弱さ、間違った優先順位を一生後悔することになります。 自分の環境、自分の子供の性格を加味して、このままだと危ないかも?と思うのなら、必要なのです。

気になるなら犬の散歩っぽいポーズに見えなければいい

最初気になるなら、ハーネス+手をつなぐで、ハーネスを本当の保険という位置づけにすればいいんです。 犬っぽいと感じるのは、手でロープを持つからです。ロープを大人のベルトに締めれば印象は薄れます。

生き方を古い時代の人に邪魔されてはならない

少子化社会の障害となっているのは、違う時代に生きてきた大人達とその価値観を刷り込まれた人達です。 現代において昔同様の生き方では、うまくいかないです。 その時代にあった生き方として、便利なものを使い、使えるものは使っていくことで生き抜いていかないと、非効率で時間的に不可能か、何かを切り捨ててその分リスクを背負っていくことになると思います。 きっと昔の人達も同じ考えで、使えるものは使うという生き抜いてきたんだと思いますよ。

カバレッジがもたらす災い。カバレッジ率なんてゴミ箱に捨てて、みんなで飲みに行け。

今働いている会社で、そういったことにダイレクトに巻き込まれたわけじゃないですが、 単体テストカバレッジについて思うことを書きました。

テスト添削以外でもリリース速度を上げる方法はありますが、ここではそれは記載していません。 ここで言いたいのは、

  • 無駄なテストは計画的に優先度下げればよい。
  • カバレッジだけでは、テストの優先度判断ができない。

の2点になります。

リリーススピードとプロダクト品質の天秤

早くプロダクトをリリースするには、必要な作業だけを行えばよい。 プロダクトの品質保証も最小労力で最大効果を得られるテストを行い、重大な障害に繋がらない保証になれば良い。 細かい障害は、その後のサイクルで解消すれば良い。

つまりプロダクトバックログのストーリーとして、残りのテストストーリーを用意し、POに説明、そして判断してもらえば良い。 そうすることで、予めテストストーリーを落とすことによる障害を許容され、あとでゴタゴタに巻き込まれない。

そうすることで開発者は、重要な要素、最低限のテストのみでリリースにすることができ、リリーススピードより優先度の低いテストを落とし、 期待されるリリーススピードにつなげることができる。

しかし、POとは別にBOやリリース承認者、ビジネスサイドのCTOがリリース承認に立ちはだかる。

単体テストはエンジニアのためにあり、経営者やマネジメント、リリース承認者のためではない

上の人達にとって、単体テストの検証内容は重要ではなく、テストの網羅率(カバレッジ)しか興味がない。 そもそもの問題として、それが手軽に測れるし、それ以外が手間という原因もある。

よくあるカバレッジの使われ方

カバレッジ率が一定水準より以下だと、理由を求められる。 開発者は、わざわざカバレッジが低い所を洗い出し、一つ一つに説明をしなければいけない。 これはとても面倒で価値を産まない作業で、上の人達を説得するしか役に立たないものだ。

そもそもカバレッジが高ければ良いと定めたルールが歪んでいる。 カバレッジとはテスト結果による網羅性という副産物であって、テストによって得られる安定性・信頼性を証明したものではない。

カバレッジはそれ単体では信頼性にかける

グレーボックス観点で重複のない組み合わせが10個あったとして、その10個全てが同一処理を通る場合、 カバレッジは、組み合わせのうち1個を実施すればカバレッジとしては十分だが、テストでは残り9個実施する必要がある。

開発者はカバレッジにのまれてはいけない

開発者としては、10時間リソースがあったとしたら、カバレッジ率を一定水準上げる作業に10時間より、 複雑な処理の単体テストに10時間費やしたほうが、安心するし、ビジネスダメージも抑えられる。

これを事業部・会社の決まりだからと言って、カバレッジを水準を超えることを優先したテストを書いてしまうと、 単体テストがゴチャゴチャしたものになるし、本当にテストしたほうがいいケースを見失うことになる。

結果、障害に繋がり最後には開発者が責められることになる。

承認者と信頼関係を結ぶほうが早い

開発者がカバレッジ率を通して承認者から信頼してもらうよりも、開発者が直接承認者と信頼関係を結べるほうが話が早い。

そのほうが最終的には、「君が大丈夫だと思っているなら、僕は君を信じるよ」というベースの上で話が進むので円滑にことを進められる。

当然信じてもらっているからには、それだけの品質を保証する必要がある。

障害が発生したときには、きちんと原因追求を行い、そこがただの設定画面なのか、会員登録画面なのか明確にし報告することは重要だ。 それを怠ると、信頼は下がり数値的判断ができるような資料を用意せざる得なくなる。

Webアーキテクチャとモバイルアーキテクチャをごっちゃにすると違和感と齟齬しか残らない

久々の更新。

お酒の力をかりてツラツラと書いてます。

私は仕事でWebのフロントエンド、バックエンドと、モバイル(iOS/Android/Xamarin)の開発を一通り経験しました。 そんななか、最近のQiitaとかのアーキテクチャ記事に凄い違和感を覚えるので、頭の整理も兼ねてチラ裏としてまとめてみました。

アーキテクチャのほとんどがモバイルアプリではオーバーデザイン

少し気の強い見出しですが、説明させてください。

昔からMVCの対抗案/亜種として、MVP/MVVM/Fluxとか色々と出ています。 出てること自体は特に気にしていないのですが、アーキテクチャは具体案というより概念寄りなので、 Web/Mobile問わずどのプラットフォームにも当て込めることが可能です。

Qiitaの記事にもアーキテクチャ・設計に関する記事が結構あります。 だけどアーキテクチャの記事がサーバサイドとアプリで分け隔てなく書かれていることが多いと感じています。

サーバ側はドメイン領域が大きくなりやすく、複数DB、複数サービスとの連携が当たり前になりやすいです。 いっぽうアプリ側はどうかと言うと、ドメインのロジックはアプリ側では持たずに最近はサーバにロジック、データをおいておきアプリはノードになることが多いので、 アプリ側のドメイン領域が肥大・複雑化しにくいと思います。

これがオフラインアプリやモバイル特有の機能(BLE/Camera/GPSなど)が複雑であるのなら分かります。 しかしそもそもサーバ連携あるのに、アプリ側のドメインが肥大するのは、サービスという視野から見るとDRY原則を破ってます。

ドメインのエンティティはライフサイクルを持っているので、サーバ側のDBに居たり、モバイルのメモリ上に居たりするので、モバイル側はドメインは完全不要ではないですが、 サーバ側と同じ複雑さに耐えられるアーキテクチャデザインをモバイル側にも考えずに適用すると、実際に手を動かしてみると非常に違和感を感じます。 違和感とは中身のないレイヤー(=メソッド)が多く、「この緩衝材(メソッド)いるの?」と感じてしまいます。

複雑さに耐えられるアーキテクチャの恩恵よりもアーキテクチャ自体の複雑さが勝ってしまい、シンプルな要求の実装がかえって複雑になってしまうケースが多いです。 アーキテクチャを提唱したライブラリを使うのも手ですが、リスクは存在します。

iOSだと追従しなければいけない

リスクとして、iOSだと常に定期的にバージョンアップが実施されスパンも短いです。 バージョンアップが実施されるだけならまだしも、最新バージョンでビルドしたものでなければリジェクト対象になるので、必然的に所謂お上についていかなければいけないです。 その環境下で、アーキテクチャをライブラリなど使って実現していると、ライブラリのバージョンアップ対応待ち、場合によっては対応されないので自分らで対応になります。

たしかにライブラリはある一定の条件下の範囲内(想定範囲内)であれば高速・安定の開発を保証できますが、その基盤(お上)が変わると、必然的に影響は避けられずビルドエラーならまだしも、ランタイムエラーや挙動変更によるライブラリ挙動変化による不具合のリスクもあります。 サーバ側であれば非推奨バージョン、非サポートバージョンはあれど緩やかで開発者のペースで移行作業が行えます。

バイルに求められるアーキテクチャ

ほとんどジャストアイデアですが、次のような要件を満たす骨組みでしょうか。 主に長期的でアプリを長く育てていこうとしている場合です。何かのイベント用であれば、好きにすればいいと思います。

  • サーバサイドとして提唱しているアーキテクチャは、脊髄反射で組み込まない。
  • 複雑さに耐えられるアーキテクチャよりも、壊しやすい組み立てやすい、プロダクトストーリーを優先できて、技術負債(=複雑さ)は空いた時間にインクリメントに改善できるライトウェイトなアーキテクチャを考える。
  • インクリメントな改善を支えられるように、シンプルな思考でテストケースを追加しやすく、実施速度が早いテスト環境を構築する。
  • (Option)UIに強いライブラリを採用する.

物事はほとんどが悪いことから始まる。なので自分らはそこから良いことに変えるのが大切

テレビ見てて久々に「ビビビッ!」って来て、そこから自分なりに解釈したのがタイトル文。

最近スケジュールに嵌ってます

状況

今、やりたいこと、やるべきことが多すぎて既にパンク状態です。

タスクのような一時的な作業ではなく、ルーチンのように毎日少しずつ繰り返す作業です。

スキマ時間はあるけど向いてない

通勤中はスキマ時間として余ってはいるのですが、机の前に座ってじっくり考えたり、

本+パソコンを使ってアウトプットも兼ねる作業だったりと、通勤中には向いていません。

リスニングや情報収集といった作業はできるのですが、それでは全てのルーチンを達成できず、偏ってしまうのです。

ToDoと見積りをノートにまとめてる

最近始めたのが、ノートに公私問わず考えたり思いついたToDoを書き留めてます。 そのときにそのToDoがどれぐらいで終わりそうか、15分単位で見積もりも横に書いてます。 あとは少しでも余った時間があれば、ToDoを見てはすぐに作業にとりかかって、日常のスキマ時間からルーチン組めないか模索中です。

チュートリアルにラスボスがいる感じ

新しいことにチャレンジするために、知らない人に違いを教えないといけないのが一番ハードルが高かったりする。

しかも興味ない上にその人の知識領域から出ないように違いを教えないと、すぐ飽きるし少し時間が経つと忘れて同じことを聞いてくる。

実はエンジニアに求められるスキルって説得力なのかな・・・

参考記事

simplearchitect.hatenablog.com

器の大きい男になりたい人へ。これ試してください。効果ありました。

f:id:motom552:20160614013718p:plain

対象者

彼女や妻に

  • 「イラッ」っとした人
  • 「ムッ」っとした人
  • 不満がある人
  • 悶々と考えてしまう人

このページを見る方は、器が小さいと言われた方、自分で気づいた方だと思うので、

男として器を試されやすい女性との付き合い関係に関した記事になります。

方法

やりたいことは簡単です。

問題を先送りしてください。

携帯のアラームやカレンダー、Webサービスを使って、数時間後にむっとしていることに名前を付けて登録してください。

名前は思い出せれば何でもいいです。分からない人は劇団四季が名づけそうな名前にでもしといてください。

ミュージカル分からない人は、「ゴジラ対俺」ってしといてください。

登録が終わったら、後で考えるように言い聞かせてください。何度も思考がムッとした内容に戻ると思いますが、

そのたびに「後で考えよう。それよりもコンビニで一番好きなアイスを買おう。」と言い聞かせてください。

そう、コンビニにアイスを買いに行ってください。

もし寒かったり、コンビニ行けなかったら部屋掃除や身の回りの整理整頓でもしといてください。

何が狙いか?

失恋と同じで 時間経過による記憶を曖昧にさせることです。

記憶が明確だから感情が起伏しやすいので、それを記憶を曖昧にさせることで頭に「?」を増やすことです。

興奮する映画を見終わったあとは、感傷に浸るように ぼけ〜 っと映画のシーンを思い出したり伏線回収したりしますが、 気がついたらその思考は終わってます。

失恋直後は頭がパニックになって、胸の奥がきゅ〜っと痛く、もうダメだとなり、ビルの窓から飛び降りようとする程ですが、

数年も経てばそんな症状はとっくになくなっており、十年も経てば無関心と近いような鼻で笑ってしまうようなものになりますよね。

イライラ不満は価値観の違いから

だけど価値観の違いで終わらせてる人って彼女を見下してる証拠になります。

自分に寄せて欲しい。寄せるべきだ。なぜ俺の考えを理解しない。なぜお前はそんな考えなの?おかしいでしょ?

どのセリフも自分は後ろにも前にも動いていないです。

自分は動かず彼女が動いて欲しい、動くだろう、動くべきだ。と言葉にはならなくとも思っているのでしょう。

男には譲れないものがある!

あるにはありますが、そんなにないので、譲れない部分はそのままにして、譲れる部分を彼女へ寄せることから始めてください。

その上で譲れない部分を伝えてください。

つまり、自分の価値観を動かせる人が器を大きくできる人です。

まぁ譲れない部分って意外と過去の話が関係してて、それを変えると人生否定されたって思っちゃうけど、それを変えた所で、死にはしないんですよね。

というか意外と平気なケースが多いような。

モノづくりに求められるもの

モノづくりに携わる人は使っていただける方の人生にストレスを与えてはならない

これは私の中にある古く堅い考えです。 モノづくりと聞くと製造業や実際に触れるハードウェアの印象がありますが、 ここでいうモノづくりに携わる人とは、Webサービスやアプリといったソフトウェアも含みます。

忙しい、時間がかかる、今言う?でも面白い

私は前職はPS3Xbox360をプラットフォームとしたゲーム開発会社でプログラマとして働いていました。

↑のように最終的には「実装すると確かにおもしろそうだ」とそっちに寄りなんとかして入れてました。

ユーザに興味を持てない人はモノづくりをしないで欲しい

シンプルな考えだと思う。 興味を持つとは、実際に会って話を聞くや、ネットの声を拾うといった行動ではなく、その行動を促す好奇心だと思う。 ユーザの気持ちを知るではなく、どんな気持ちなんだろうか?と考え、興味を持つことが重要だ。

それは実際に起きなくてもいい。「風が吹けば桶屋が儲かる」と同じような考え方でもユーザの利用シーンをイメージできるためだ。

想像しやすいケースを考えてみよう

もし子どもの自転車に手を抜いて作ったらどうなるだろう? パパ・ママに誕生日に買ってもらった好きな色の自転車。 買ってもらって毎日乗って、歩いて行ける近所のお店にも、お小遣いをポケットに入れて 笑みが溢れそうになりながら、自転車でお店に走る姿。 しかし手を抜いたことが原因で、お店への最後の曲がり角で、買ってもらってから毎日乗っていた自転車が壊れ転倒。 子どもは肘と膝に擦り傷、壊れ倒れた自転車の前に泣きながら立つ姿。 痛いから泣くんじゃない。せっかく買ってもらった自転車を壊してしまったことと、お気に入りが壊れたことが悲しくて泣くんだ。

ゲームも同じだ。

社会人になった大人が、発売予定のゲームが楽しみすぎて、その日ガッツリ遊ぶために、発売日に有給使って、食い物を冷蔵庫に入れ 万全の準備で、急いでお店にゲームを買いに行き、事故らないように興奮を抑えながら家に帰り、 家でゲームを起動。 しかしゲームはバグが多く満足にプレイできず。

もう申し訳ない気持ちと悔しい気持ちと、情けない気持ちになる。

新人クリエータは好奇心を忘れないこと、ユーザーの気持ちを理解できない人は離れること

こういったユーザー目線に立てない人はモノづくりからすぐに離れるべきだ。 それはもう現場との価値観が根本的にズレ過ぎて、後ろから刺してくださいと言っているようなものだ。 お客様第一と謳いながらも数値だけを追いかけ、価値提供ではない機能提供を優先し、機能がもたらす価値提供への道となる使いやすさを無視した人がいては、いつまでたっても時代やターゲットの成長、価値観に追いつけず作り手が「こういうものを作りたいんじゃない」と思わせつづけ、離れていってしまうからだ。

この記事を読んでふつふつと最近思う不満が膨れたので勢いで書いた。

techlife.cookpad.com