valid,invalid

関心を持てる事柄について

狭いマンションにもドラム式洗濯機は置ける

結論

3方向をぴったり壁で囲まれた64cm×64cmの一般的な防水パンにもドラム式洗濯機が置くことができる!!!

f:id:ohbarye:20170723134341p:plain

f:id:ohbarye:20170723134004j:plain

ドアの開閉もできる。

買ったもの

kakaku.com

公式ページ: メーカー希望小売価格は税込246,240円。高い!!

幅639 × 奥行600 × 高さ1050mm

選んだ経緯

id:taketyan引越・同棲 1 年目の 2016 年に買って良かったもの | Born Too Late 記事で読んだ TW-117X3L の後継機、TW-117X5L が欲しかったのだが、幅645 × 奥行750 × 高さ1060mm を設置しようとすると壁を破壊しないといけないので諦めた。

調べるとプチドラム/ミニドラム式洗濯機というのがあるらしいとわかり、その種の中で最も評価が高かった Cuble NA-VG710L にした。

価格

トータルで152,037円かかった。

注文明細

本体価格は135,000円だったが、延長保証や取り付けなどの手数料もかかった。古い洗濯機のリサイクル回収代はもとから含まれていたようだ。

******************************************************************
 ご注文商品明細
******************************************************************
★洗濯機 パナソニック NA-VG710L  ★延長保証加入★(商品コード:1207582)
  無料搬入商品   取付希望    リサイクル回収:1個
 ¥135,098(税込) × 1 個 = 135,098 円

リサイクル回収運搬  (商品コード:99992002)
 ¥3,240(税込) × 1 個 = 3,240 円

---------------------------------------------------------------
小 計 ¥ 138,338
延長保証料 ¥ 6,755
送 料 ¥ 0
取付料 ¥ 3,240
手数料 ¥ 1,220
===============================================================
合 計 ¥ 149,553

リサイクル券

エアコン、テレビ、冷蔵庫・冷凍庫、洗濯機を捨てる際には家電リサイクル法にもとづいて料金を支払わないといけない。今回は料金郵便局振込方式だったので新しい洗濯機の配送 兼 古い洗濯機の引取が来る前に郵便局に行ってリサイクル券を買う必要があった。

券を購入するには捨てたい洗濯機の製造業者と品目が必要だと書いてあるが、とりあえず型番だけメモして行ったら調べてくれた。

この券の購入に2,484円かかったのでトータルで150,000円を超えてしまった。

感想

購入について

よくわからない家電ECサイト勘弁してくれ〜と思っているものの、数万円単位での値引きや取り付けとか引き取りの依頼を含めると使わざるを得なかったのが辛いところ。

注文から4日で届いたのは早くて嬉しい。

製品について

とりあえず洗濯&乾燥を試してみると4時間30分ほどで洗濯〜乾燥まで終わった。これまでの縦型洗濯機だと計5時間(洗濯1時間 => 洗濯機の乾燥1時間 => 浴室乾燥機で3時間)かかっていたのとあまり変わらないが、わざわざ干さなくてよいのが最高。

騒音が気になるかもと思ったが壊れかけの旧洗濯機より遥かにマシだった。洗濯機からドアを一枚挟めばまったく気にならない。

また、製品のデザインがかっこよい。洗濯機の前でぐるぐる回る洗濯物を何も考えず眺めていたら10分ぐらい経過していたので暇つぶしにもおすすめだ。

最近仕事中に Apple Music で聞いている音楽 - むかし聞いていたけど最近どうしてるんだろうシリーズ -

むかし聞いていたけど最近どうしてるんだろうシリーズ

Arts & Crafts になぜか偏った

新しいアルバム出しているんだなーと気付いてそのまま聴ける Apple Music 最高

The Most Serene Republic

www.youtube.com

Dirty Projectors

www.youtube.com

Los Campesinos!

www.youtube.com

Broken Social Scene

www.youtube.com

Stars

www.youtube.com

Ra Ra Riot

www.youtube.com

『日本語という外国語』読んだ

日本語という外国語 (講談社現代新書)

日本語という外国語 (講談社現代新書)

あらすじ

日本人が考える「日本語」と外から見た「ニホンゴ」は違います。「どこが難しい?」「意外な魅力とは?」「どう教えるか?」豊富な日本語教育経験から語る、日本人のための日本語再入門。(講談社現代新書

日本人が義務教育〜高等教育で学ぶ「国語教育」ではなく、日本語を母語としない人向けの「日本語教育」にフォーカスした本。

面白かった点

日本語は日本人が思うほど難しくない

「第4章 外国語として日本語を眺めてみると」より。

昨日、私は八時におきました。九時に、朝ごはんを食べました。朝ごはんは、トーストとサラダでした。おいしかったです。十時に電車で銀座へ来ました。デパートで黒いコートとストライプのネクタイを買いました。

外国人がこのように話すのを見た日本人はたいてい「日本語上手ですね」と感心する。しかし、著者によれば「一日に三時間、月曜から金曜まで学べば、早ければ一ヵ月、どんなに遅くても二ヵ月で、このレベルまで達する」という。

国語教育を思い出し、五段活用やらサ変やらカ変やらを思い浮かべる日本人にとっては「そんなはずない」と言いたくなるかもしれないが、「です・ます」にフォーカスして学ぶ限りでは日本語の動詞は非常に簡単なのだと。

日本語表現のゆたかさ

上記のような簡易さがある一方で、話を最後まで聞かないとわからないような複雑な表現も多々ある。

とりわけ、「第5章 日本語表現のゆたかさを考える」で挙げられていた例文、「山田選手はかなり練習させられていたらしいよ」の一文の述語の説明は白眉だった。

「させられていたらしい」という述語だけで以下の4つの情報を表現している。

  1. 過去のことである(〜た)
  2. 本人の意思とは反していた(〜せる)
  3. 一過性のことではなく継続していた(〜ていた)
  4. 話し手にとってこの件に確証はない(〜らしい)

テンス・アスペクト・ムード

聞きなれない文法用語があった。テンス(時制)はまだしも他の2つは何だろう。

アスペクト

アスペクトは「ある動作がどの局面にあるか」を表現する文法形式。「相」ともいう。「食べ始めた」という言葉は以下のように分解できる。

アスペクトを変えることで「食べいた(進行)」や「食べ終えた(完了)」などの表現が可能になる。

ムード

ムードは「単なる事柄を表す以外の話し手の気持ちのありよう」について述べる文法形式。言語学では「法」と呼ぶ。

これを用いることで「働くつもりだ」「食べるらしい」といった表現が可能になる。

ここまでの知識を総動員すると、「させられていたらしい」は結局以下のように解析可能となる。

  • 「させ」: 使役
  • 「られ」: 受け身
  • 「てい」: 進行(アスペクト
  • 「た」: 過去(テンス)
  • 「らしい」: 推測(ムード)
  • 「よ」: 判断(ムード)

感想

日本語教育に関する内容が中心の本だが、これに携わらない人や興味のない人であっても、普段意識することのない母語言語学面での分析からは上述のような面白い知見を見つけることが出来ると思う。

とりわけ、日本語を話したり学んだりしている外国人と普段から接している人にとっては彼ら彼女らがどのように日本語を捉えているのか、どのような点に躓きがあるのかを理解する一助となるので、一層お薦めできそうだ。

『サウンド・オブ・ノイズ』観た

Netflix で観た。

予告編を観た時の高揚感はすごかったが突然の恋愛要素と感情移入しづらい主人公たちのために後半には気持ちが失速してしまった。

身近なものを楽器にして演奏するのも街中で演奏するのも誰もが思いつきそうなアイディアだけど、それが"音楽"になるまで作り上げていくのはとてもとても大変なことなので、見事にやってのけたライブシーンはどれも良かった。

数年後にライブシーンだけ見返しそうな気がする。

ソフトウェアの世界での slug / スラグ / スラッグの意味

かつての自分と全く同じ気持ちを持った質問者によるurl - What is the etymology of 'slug'? - Stack Overflow('slug' の語源は?)が気に入ったので抄訳。

python - What is a "slug" in Django? - Stack Overflowよりも質問の仕方が良い。

ちなみに今の自分が「'slug' ってなに?」と聞かれて説明するなら「ヒューマンリーダブルな ID」あたりが妥当な回答だろうか。


Q: ‘slug’ の語源は?

‘slug’ は特筆すべき理由のない言葉なのか、それともやはり何らかの意味がある言葉なのでしょうか?あるとき私は会話の中でこの言葉を使用したのですが、「なぜ ‘slug’ って呼ばれているのか」と聞かれたときに私も意味を理解してないと気づきました。

もちろんそれがどのように使われているかは知っているのですが… http://codex.wordpress.org/Glossary#Slug

結局、この言葉の背景にはどんな意味があるのでしょうか?

A: 由来は新聞業界です

‘slug’ は、新聞業界から来ている言葉です。

これは、制作過程で記事に与えられる非公式の名前、つまりコードネームみたいなものです。記事が担当記者(もしくはそれ以前)から編集者を経て印刷機に至るまでの道のりでの呼び名です。例えば「'kate-and-william' の校正は終わった?」のように使われます。

一部のシステム(Djangoなど)では URL の一部として ‘slug’ を使って記事を特定します。 www.mysite.com/archives/kate-and-william という具合です。

遡ると脚本の ‘slug lines’ に行き着くかもしれません。この ‘slug lines’ はシーンの背景、つまり、いつ誰がどこで〜などを表現するものです。後に続く文章を説明するものであるという点で ‘slug’ と似ています。

ライノタイプ*1においては、'slug' は個々の文字の形から作られた一本の線の金属を意味していました。1行ごとに単一の ‘slug’ を作ることによって、従来の1文字ごとに組み合わせを作るやり方が大幅に改善されたのです。

これは推測ですが、'slug' はもともとは(何かしらを押印しなければならないような)偽造されたコインのためのものだったのでしょう。言葉の使われ方が印刷用語に至り、そこから「1行の活字」、そして「記事の要約」へと変遷した様子を、私は容易に想像することができます。そうした印刷の世界からオンラインの世界へ移るのはこれまた実に簡単なことでしょう。

*1:ライノタイプは、キーボードを打鍵する事によって、活字母を並べてそれを鋳型とし、それに溶けた鉛を流し込んで、新聞などの印刷版型を作成する装置である。単語や空白から成る横一行を丸ごと活字にする事が出来る。かつては印刷所などにあった。ライノタイプという名称は、Line of type (一行の活字)を省略したものである。 quoted from ライノタイプ - Wikipedia

レビュー会のすすめ

先週日本にインドネシアのプロダクトマネージャーが来た時に「レビューに時間がかかりがち」「結果として開発のリードタイムが予測しづらくなっている」という悩みを相談してくれた。そのときに「コードレビューを会話しながら行う取り組み - Hatena Developer Blogとかどうですかね、日本のチームでも “レビュー会” ってのをやっていますよ」と伝えようとしたが日本語の記事を渡すのも気が引けたので「あとでまとめておく」ってことにして社内向けに “Encouragement of Review Meeting” という snippet を書いた。

これを日本語でも書き直してみる。


背景

最近プロダクトマネージャーと開発者間でレビューに関してこんな感じの問題があるらしい。

~ ある日 ~

マネージャ「進捗どう?」

開発者「だいたい終わってレビュー待ちの状態かな」

マネージャ「オッケー」

~ 別の日 ~

マネージャ「どう?Pull Request はマージされた?」

開発者「いや、それがまだで…。もう一回 ping してみる」

マネージャ「そうか…どれぐらいかかりそう?」

開発者「うーん、わからん…」

~ 以下、ループ ~


開発者による見積もりがすぐに元々の数字から変わったり、リリース日がずれたり、誰にとっても嬉しくない状況である。

一方、日本の開発者は複雑だったり大きすぎたりする Pull Request を作ってしまったときには “ペアレビュー” や “レビュー会” を設けており、今のところうまく機能している。

前提

そもそもレビューのリードタイムが長くなるのは Pull Request がでかいか複雑か、それに見合う説明が足りてないか、だ。

まず開発者が意識すべきなのは

  • Pull Request を適切なサイズに分割すること
  • 充分な説明、図、wiki などを書くこと

とはいえでかい Pull Request を作らざるを得ないこともあり、得てしてそれは長い間放置されがちである…。

詳細

そうした状況を避けるため、日本の開発者は “レビュー会” というのをやっている。

  1. レビューを求める開発者(レビュイー)はまず Pull Request (必要なら wiki なども)を前もって用意し、ミーティングを予約する
    • 全員が主体的に参加できるよう、レビュワーの数は2 ~ 3人がベストだと思う
  2. レビュイーはミーティングで Pull Request や wiki や図などを見せながら説明する
    • たまにすごく絵を書くのが上手い人にでくわす
  3. レビュワーはいつでも何でも質問して良い
    • たまに激しい意見が飛び交うかもしれないが落ち着いて欲しい
  4. 質問されたこや議論の内容は GitHub の review comments として残す
    • 残さないとあとでわけがわからなくなる
  5. ミーティングが終わったらコードを修正する
    • 結構な量の修正になったとしても指摘内容や実装意図を理解しているので再レビューはかなり簡単

Note

  • 全ての Pull Request がこうした取り組みを必要としているわけではない
  • “ペアレビュー” も “レビュー会” もコミュニケーションツールだということを忘れないこと。普段レビューを円滑にするために行っていることをそのままやるとよい
    • レビュイーは対面だからとか時間を取ってしまうからと気兼ねせずレビュー依頼や質問をすること
    • レビュワーは良いところは褒めつつレビューされたし

終わり



Original post:

Background

I recently heard some @quipper/product-managers (or even developers) are troubled with reviewing time. Is the situation like below?

~ One day ~

Manager: “How is your work going?” Developer: “Almost finished, but… it still needs to go through review.” Manager: “Understood.”

~ Another day ~

Manager: “Did your PR get merged?” Developer: “Ah, not yet. I’ll ping them again.” Manager: “Hmm, I see. How long does the review take?” Developer: “Umm, not sure.”

~ To be continued… ~


It’s so frustrating for everyone. Estimation by a developer easily varies from the original one, and its release date does.

On the other hand, Japanese developers sometimes have kind of “pair reviewing” or “review meeting” for a complicated (large) pull-request in person. So far, it works so well that I’d like to share the way.

Premises

Most of the review time issues are caused by a large/complicated pull request, and lack of adequate description.

So first of all, developers should

  • split pull-requests into adequate size ones if possible
  • write an adequate description, chart, wiki etc. for a feature they develop

Even though the idea above is right, we are sometimes compelled to implement a large/complicated pull request. And it will have been neglected for a long time…

Details

To avoid such situation, Japanese developers sometimes have “review meeting”.

How?

  1. A reviewee who needs a review prepares PR and wiki (if necessary) beforehand, and book a review meeting
    • 2 or 3 is a good number of reviewers. If it’s too much, all of them might not actively join a discussion.
  2. The reviewee explains his/her implementation by showing PR, wiki, chart etc.
    • I know some devs are quite good at to write a chart.
  3. A reviewer can ask/discuss anything anytime in the review meeting
    • Be calm, it’s not an interview.
  4. Questions/Discussion points are noted as a review comment on GitHub
    • If we skip this step, some points will be missed.
  5. After that, the reviewee reflects the content of the review meeting
    • Even if there are so many fixes, it’s much easier to re-review since reviewers know why those changes are needed.

Note

  • Not all of pull-requests requires “review meeting” and “pair review”.
  • They are just communication tools, so
    • If you are a reviewee, don’t be afraid to ask a review.
    • If you are a reviewer, it’s quite encouraged to pay a high compliment to one’s code.

END

プロダクトの複雑さと引き算の重要性

コードを書く気持ち

「開発しなくても既存の機能や基盤のうえで提供できる価値はあるし、既存機能を組み合わせて新商品や機能を作り出すこと、またはフィジビリティを行うことも場合によってはできる」…なんだかそういうことを常に念頭において開発するようになり、とにかくコードを書ければそれでよいみたいな気持ちがなくなってきた。

もちろんずっとコードを書いていたいのだが、小さい問題解決のために大きな問題を後回しにするようなコードは書きたくない…という迷いがある。

携わってるシステムがそこそこ大きく、一部はレガシーと呼んでも良さそうな年季が入っているので、無策でこれ以上コードを積み上げていくのに少なからず恐怖心もある。

複雑なるもの

なぜ迷いや恐怖心があるのか。複雑なものの上に新しい何かを載せてできるのは「ちょっと複雑なもの」ではなく「かなり複雑なもの」になってしまうからだ。

てきとうな式だと「複雑度10 + 複雑度1 = 複雑度15」 みたいなイメージだ。

大げさに言っているようだがこれはあながち間違ってもいなさそう… というのも、最近参加したメンバーからのフィードバックで「当初の見積もりより開発に4倍時間がかかった」というものがあり、理由を聞いたところ「既存の仕様や実装との兼ね合いが開発途中で判明し、当初に想定していたシンプルなものではなくなってしまった」という。

「見積もりが悪い」と責めるのは簡単だが俺はそうは思っていなくて「見積もりが正確にできないほど複雑なものを相手にしている」というのをチームの共通認識として持つべきだと思う。

立ち向かう案

「複雑だからしょうがない」と言って諦めてもしょうがない。

複雑だからこそ新しいものを1つ足すときには引き算の考えも同時に欲しい。最低でも1つ、可能なら2つでも3つでも同時に引き算することで複雑さを減らしていくしかない。

「何も引くことができない」というような状況の場合、振り返りや分析がきちんとできていない可能性を疑いたい。足す時に理由が必要なように、引くのにも理由が必要だからだ。

もし誰もそのことを気にかけていないなら、足し引きのバランスを担ったり引く理由を追うためのチームがあっても良いぐらいだと思う。