Toy と帽子と ADP BE

主にプログラミングに関わる話をゆるくエモくやっていきます

将棋ウォーズの棋譜 url から csa ファイルを作るワンライナー

(Lazy) One liner that create csa file from shogi w ...

とりあえずソフトで解析するための棋譜ファイルを作りたかっただけなので雑なワンライナーで済ませました。

ワンライナーで済ませずにちょっと気合を入れたら対局者名や消費時間なども入れられますが、そこまでする動機もないので・・・。

楽しく仕事をするということ

この記事は コミュニケーション Advent Calendar 24 日目の記事です。

最近思ったこと

仕事をする上で、何かのきっかけで一時的に雰囲気が良くなることが時々あります。たとえばレトロスペクティブのあととか、とてもチームの雰囲気が良くなることがあるんですよね、経験上。あ、いいなあこれ、みんな笑顔でいい雰囲気で仕事できてるなぁ、って。ただし、次の日にはだいたい元に戻っている。別に元より悪くなるわけではないのですけど。

結局、それはかりそめの笑顔だと思うのですよ。みんなの意識が本当に揃ったわけではなくて、あくまでも形式的な表面上のコミュニケーション。みんなで話し合って決めたからそうしようっていうだけで、本質的なところが何も解決していないから定着しないのではないかと。

もちろんやらないよりはやったほうがいいと思いますよ。私はいい雰囲気を作るのが苦手だからなおさら普段から意識していないといけない。(残念ながらまったくうまくできてませんけど)

今考えていること

じゃあ本質的なところを解決するにはどうしたらいいのかって話になるわけですが、それは結局、意識(知識・スキルも含めて)の共有ではないかとは思っています。それをどうやって実現するかの答えは私の中ではまだ全く見つかっていないので困っているのですが。そもそも実現不可能なんじゃないかとすら思っていたりして。仕事に対する意識も、持っている知識も経験もスキルも違う人たちが、同じものを共有するなんて。

いい悪いの問題ではなくて、見えているものが明らかに違うから伝えきれないよなぁと思うことがあって。見たいと思っているものがそもそも違うからどうしようもないよなぁと思うことがあって。でも、自分が見ているこの風景をぜひ見せてあげたいと願ってやまない自分がいる。

求め過ぎなのかもしれません。自分にも他人にも。みんな違うことを認識した上で、それでもできる手段を取ることに注力したほうが効率がいいのかもしれません。でもそれでは納得できないんだよなぁ。困ったことに。

「 関ジャバ 関西Javaエンジニアの会(関ジャバ) '17 10月度」に行ってきました

kanjava.connpass.com

に行ってきました。

というわけで、直接的な感想ではないんですけど、皆さんのセッションから得たこととか考えさせられたこととかを一旦まとめました。

DDD について

最近 DDD とかそれにまつわる技術とかを学んだり実践したりする上で思うのは、よくあるなんとかアーキテクチャーとか(MV なんとかなども含めて)一つの指針としてはとても有用だと思いますけど、なんとかアーキテクチャーありきで開発するのは違うよなーということです。 そういう型にはめて型ありきでやろうとすると、この層なんのためにあるのかよくわからないとか、特定の層がやたら膨れ上がったりとか、どうしても歪ができてしまうような気がして。

ドメイン」は現場によって違う。言語やフレームワークも違う。作業者の質や量も違う。結局、そのときどきに合わせて悩んで苦しんで生み出していくしかないのではないかというのが今の時点での私の結論ですかね。

どうせ成果物を何ヶ月後か何年後かにあらためて見返したら、「当時の俺ってアレやったな」としか思わないんですから。いつまで経っても。

まあ一言で言うと「銀の弾丸はない」っていうお決まりのフレーズになっちゃうんですけどね。

ああ、もちろん、大きな枠組みではなく細かい技術やノウハウの積み上げは必要だし重要です。たとえば 増田さんの本 はそういうものが詰まっているんだなと今さらながら気づきました。

言語について

私は Java 大好きっ子で、一方今回のセッションは Scala が多めだったわけですが、それはそれでいろいろ学びになります。 で、少し前から意識はしていたんですけど、やっぱり Java 以外の言語も勉強しないといけないと改めて思いました。

それは、いろんな言語を学んで選択肢を広げるということももちろんあるのですが、メインである Java をもっと深く知るためにこそ、Java だけでなく他の言語や言語を支える技術をもっと勉強したほうがよいという意味で。

オブジェクト指向について

私のオブジェクト指向に対する認識は、いろいろさまよった結果

オブジェクト指向の概念の発明者は誰ですか?(改訂版) - Smalltalkのtは小文字です“オブジェクト指向”の本質 - Smalltalkのtは小文字です

この辺でとどまっています。また、数年前には社内勉強会の講師としてオブジェクト指向について話そうとして大爆死した経験もあったりします。そんなわけで、自分でもよくわかってないし人にも説明できないし、そもそも人によって言うことはまちまちだし、なんかもう最近は「みんなの心の中に、それぞれのオブジェクト指向があるんだよ」ってことでいいじゃないかみたいな感覚でいました。(getter/setter がカプセル化とかいうのはもちろんだめですけどね)

しかし、少なくとも Java という文脈の上ではそれはもう「型」ってことでいいんじゃない?と増田さんのセッションを聞いていて自信(?)が持てました。(雑な表現、雑な理解ですけども)

まあとりあえず、存在はだけ知っていたけど英語なので敬遠していた WhatIs 論文くらいはいまさらながら読もうと思いました。今の自分なら時間は掛かれど、それなりに読めるはず・・・。

MVNO の端末が故障した時すること

私の場合、MVNO楽天モバイルで端末は ASUS の Zenfone5 です。 前回のエントリの通り、こいつが突然ぶっ壊れましたので修理に出しました。 修理に出す前にいろいろ調べたところでは、サポートが悪いだの時間がかかっただのという記事が目立ったので不安だったのですが、実際はかなりすんなり事が運んだので他の方の参考になればと思い記録を残すことにしました。

他の MVNO や端末メーカーだと若干事情が違うかもしれませんけど、参考にはなるかと思います。

端末のメーカーに連絡

MNO とは違い、MVNO には壊れた端末を持ち込んでも仕方ありませんので、自分でメーカーに連絡します。ASUS の場合はサポートサイトとして サポート 公式 | ASUS 日本 があります。

どうやって連絡するか

下の方に、メール、電話、チャットそれぞれのお問い合わせのリンクがありますが、たぶんメールが一番効率がいいです。

  • 時間を気にしなくていい
  • 電話やチャットだと、話が噛み合わずに無駄な時間を取られることもある(らしい)

というのが主な理由です。メールのレスポンスは十分早い(夜投げても次の営業日にはちゃんと返ってくる)ので、問題ありませんでした。私は最後までメールだけでやり取りしていました。

何を連絡するか

ASUS - メールでのお問い合わせ

問い合わせフォームに適切な情報を入力して、問い合わせ内容として端末の故障状況を記載し、修理したい旨をつたえます。

すると、修理受付方法を記載したメールが返送されてくるので、それの内容に従えば OK です。具体的には

  • 故障した端末
  • 修理依頼確認書
    • メールにPDFのダウンロード用 URL がありますので、ダウンロードして印刷して必要事項を書き込みます
  • 購入証明書(レシート、店舗印付き保証書、領収書等)
    • 店舗で購入したわけではないので、上記の書類はないのですが、私の場合は申込受付完了メールをプリントアウトして送りました

を、指定された住所に発送することになると思います。なお、発送は着払いで OK とのことでした。

見積もり完了

端末が向こうに届き次第修理の見積もりを行ってくれて、それが完了した時点で見積の内容で修理するか取り止めるかを確認されます。それに対して返答すればほぼやりとりは完了です。私の場合家に一度電話があったようなのですが、不在だったので対応できず、直後にメールが送られていましたのでそのメールに対して返答をしました。そもそも、連絡先としてメールアドレスだけ伝えておけば最初からメールで連絡してくると思われるので、次の機会があればそうしようかと思っています。

修理完了

見積もりを了承した旨を伝えると、実際に修理が行われて返却されます。 見積もりの了承に対する返答はメールできますが、それ以降はメーカーからは連絡が来ないので、修理及び配送状況はサポートサイトで自分で確認する必要があります。 https://www.asus.com/jp/support/Repair-Status-Inquiry/?country=Japan 製品のシリアルナンバーだけで検索可能です。

なお、修理代金は代引きで運送業者に払うことになります。

期間

壊れてから修理されて返ってくるまで約10日間くらいでした。個人的には十分速いと思います。 向こうの見積もりを了承してから手元に戻ってくるまでだと、なんと約3日間でした。

参考

修理の手続きをする上で、こちらの記事が非常に参考になりました。ありがとうございました。

【保障期間内でも、修理してもらうのは大変】ZenFone5の修理を依頼する方法はこちら(3/20追記と修正) - 格安スマホ SIMで節約生活^^

【保障期間内でも、修理してもらうのは大変】ZenFone5の修理を依頼する方法はこちら 完結編 - 格安スマホ SIMで節約生活^^

スマホのない生活 3日目

突然の別れ

スマホが突然お亡くなりになりまして、今日で三日経ちました。

で?

何か困ることがあるのかというと特に困りません。

私がスマホですることといえば、基本ネット見るか、ゲームするかだけなので。電話は年に数回しかする機会ないし。チャットアプリは、たまに仕事の連絡にで必要になることはあっても、それ以外では奥さんとしかやり取りしないから特に差し迫った問題でもない。カメラも特別なイベントでもない限り使わないですねそういえば。

ただし

知らぬ間に自分が書いた記事のコメント欄が(また)炎上しているのにすぐ気づけなかったりするのでちょっと困りました。

本当に、地味に、辛いこと

私は普段スマホをおしりのポケットに入れているんですが、持ち歩いていない今でもつい手がそこに伸びるわけですよ。で、そのたびに

(あ、スマホなかった)

と、なったあと

(ていうか、ケツでかっ)

って思わざるを得ないのが地味に嫌です・・・。

実は今年、9kg 痩せたしウェストも 5cm 減ったんですけど、おしりはなかなか痩せないんですよね・・・。

サービスと階層の話

【大阪】9/16 現場で役立つシステム設計の原則 読書会【第5回 in 豊中】 - connpass に行ってきました。その中で、私にめちゃくちゃ刺さったことについて書き残しておこうと思います。

なお、『現場で役立つシステム設計の原則』では、第5章の話に相当します。それプラス、読書会で出た話や、私個人の感想が含まれます。

要約

  • サービスは単機能で作る
  • 複数のサービスをひとつのまとまりとして扱いたいときは、単機能のサービスを複数まとめた新しいサービスを作る
  • 階層は必要になった時に作ればいい
    • 階層ありきで設計すると、無駄なクラスをつくるハメになる

感想

ずっと悩んでいたわけですよ。どの階層に何を置けばいいのか、どのように階層を作ればいいのか、ということに。

古くはいわゆる MVC やその亜種に悩まされてきましたし、やれ DDD だやれ Clean Architecture だと言っている今でも、サービスって何さ?ユースケースって何さ?モデルって何さ?ってよくわからなくて試行錯誤して階層を分けたり分けなかったりしているのです。しかし、どうしてもどこかにただデータを横流ししているだけのようなクラスを含む階層ができたり、逆に色んな要素がつめ込まれてしまうクラスができたりしまいます。どうしてもどこかに歪が出てしまう。

でも、無理に階層を分けないで、小さい単位で組み立てていって、ある程度まとまった固まりに対して必要となった時に初めて階層を用意するとしたら? それは確かに、より自然であるように思えます。

最初から○○層!って気合を入れる必要なんてなかったのです。階層ありきで作るから、○○層って何書けばいいの?とか、書いては見たけれど本当に必要なのかどうかわからないようなクラスができてしまっていたのです。

そんなわけで、これからは必要なものを必要な分だけ書いていこう、と思ったのでした。

余談

PHP の有力なフレームワークである Laravel ですら「モデル」に対しては完全に振りきっていて

多くの別々の人達にとって、その意味合いは様々なため、"models"という言葉の定義は曖昧であることに私達は気づきました。ある開発者たちはすべてのビジネスロジックを総称してアプリケーションの「モデル」と呼び、一方で別の人達はリレーショナルデータベースに関連するクラスを「モデル」として参照しています。 ディレクトリ構造 5.5 Laravel

とかいいだす始末です。(まあ実際そのとおりなんですが)

余談その二

『現場で役立つシステム設計の原則』の第3章を初めて読んだ時、なぜか今回の話に出てくる(古き悪しき)MVC を想起*1してしまって「えええええ?」となってしまったのでした。もう一度読むと全然そんなことは言っていないことがわかったのですが・・・。あの感覚はなんだったのだろうか?

*1:フラッシュバックと表現したほうが適切かも

『現場で役立つシステム設計の原則』という本に対して思うこと

前置き

「現場で役立つシステム設計の原則 読書会」に行ってきました。

kansaiddd.connpass.com

で、所感とか書こうかと思ったんですけど、勉強会の内容そのものよりまず『現場で役立つシステム設計の原則』という本に対して思うことが膨らんできたので、一旦そこだけにフォーカスした内容で一エントリ書くことにします。

この読書会自体は恐らくあと十回くらい続くので(十回で済むんかな?)、そこで得たものはおいおい現場やブログでフィードバックできたらいいかなと思っております。

『現場で役立つシステム設計の原則』という本に対して思うこと

基礎知識

第一章を読んだ時点の感想が「うわこれオブジェクト指向の基礎知識は必須だよな」、第二章を読んだ時点では「うわこれ少なくとも Effective Java に挑戦できるレベルは最低限必要じゃないか」。 そこで、次に十章を流し読みしてみました。章のタイトルが「オブジェクト指向の学び方と教え方」だったので、もしかして前述の OOP に対する前提知識がそこで身につけられるようになっているのかなぁと思って。でもそこに答えはない、ように見えます。「こうすればオブジェクト指向になります」ってことは書いてあるっぽいんだけど、「何故そうすることでオブジェクト指向になるのか」については書かれていない、ように見えます。

じゃあやっぱり、オブジェクト知識の何たるかは前提として持っているかなんとかして自力で身につけないといけないっぽい。

行間

今回の読書会自体に対する感想として、「みなさんめちゃくちゃ行間を読み込んでるなー」というのがありまして。また、Twitter やブログでも、異口同音に「考えさせられる」という感想が目立っているように見受けられます。また、読書会の中で「この本は徹頭徹尾各論しか書かれていない」って話題が出てきました。

つまり、この本は行間を読めないと全く読めたことにならないのではないかと。

なまじ読みやすい本なだけに、考えずに読んでいたら「あーそうそう、そうだよねー」で終わってしまう危険性があって怖いです。

もうちょっと考えてみた

そんなことも踏まえつつ、読書会から帰ってからいろいろ考えていたんですが、結局この本に書かれているのは著者が直面してきた「ドメイン」に対しての解の一つ、でしかないのではないかなぁ、と。もちろん普遍的に通じるところもいっぱいあるというか、普遍的に通じる部分を、書籍として普遍的に通じるように表現されているとは思うのですが。

なので、自分自身に生かそうと思えば、考えないといけない。めちゃくちゃ考えないといけない。 それはもちろん何においても当たり前といえば当たり前のことではあるのですが、この本は相対的にも絶対的にもかなり高いレベルでそれを要求してくるのではないか、というのが現時点での私の印象です。

現時点での結論

OOP がわかってないといけない。Effective Java 挑戦レベルは最低限必要。字面だけを真に受けてはいけなくて行間が読めなくてはいけない。自分自身に適用しようと思えば、その答えは自分で導き出さなくてなならない。取っ掛かりにはなるかもしれないけれど、うっかりしていたらそこに取っ掛かりがあることすら気付けない。

取っ掛かりが見つかったようにみえても、表面的なものだけ受け取ったら大変なことになりかねない。具体例で言えば(勉強会でも話題になりましたが)共通する処理はメソッドに閉じればいいよって話ひとつとっても、意味的なものを考えない人がそれをやったら、処理がほとんど同じなら共通化してしまって なんとかUtil に放り込んで、ほとんど同じだけどちょっと異なる部分はフラグを付けて対応して、結果的にメンテナンスがむしろ大変になって、結局なんのために共通化したんだって話にしかねない(なりかねない)。 そんな危険性がある本だなー、というのが現時点での偽らざる感想です。

いろいろ考えられるとても面白い本であることは間違いないし、買ってみて、読んでみて、よかったということは間違いないです。 でも、読みやすいから初心者でも読んでいいんじゃないかという意見には個人的には賛同しかねるなー、という感じ、ですかね。