のんラボ

スマレジでスマレジ4のアプリコンテストが開かれました

2020/09/14 2020/09/14

スマレジでスマレジ4のアプリコンテストが開かれました こんにちはNonです。 今回は私の勤めているスマレジで開催されるスマレジ4のアプリコンテストについて記事にしようと思います。 アプリコンテストってなに? 今年の7月上旬頃にスマレジ4として、一般に公開されるAPIと、そのAPIを利用して作成したアプリのマーケットプラットフォームの提供を開始しました。 そのアプリマーケットを更に充実させるべく、社内でアプリとアプリの案の募集を始めたのです。 コンテストの賞金は、アプリをモノにして10万円〜100万円、アプリの案を提供して3万円〜10万円。もちろん内容の精査や順位付けをして適正なもののみに賞金が出ます。 参加条件は社内だけですので、一般の方は参加できませんが、この催し物で更にスマレジ4が賑わってくれえると嬉しいものです。 スマレジ4ってなに 大体はhttps://developers.smaregi.jp/を見ればわかりますが、要はAPIを提供しますよーってことです。しかもかなりの機能を公開している or する予定ですので、スマレジAPIを使用して自分だけのレジを作るなんてことも可能です。 データは2万店舗分なのでかなりのデータを提供することになります。無料でこれだけのデータを触れるのはすごいかも? で、私は何を作っているかというと... 個人開発ですので、大した機能のものは作れませんが、 会員の購入した商品からAIでオススメ商品を割り出す ということをしようと思います。 これだけの会員情報と取引情報があるので、前からAIの種にしたいな〜と思っていたのです。 名前はスマレジ・レコメンドから略してスマレコです。会員情報以外からもオススメの商品を割り出せるようにしていきたいのですが、リソースがない...今回は会員情報からのみですかね? デザインもBootstrapのままになってしまいそう。一応コンポーネント設計しっかりできているはずですので、デザインの拡張性もあるはず。 案はたくさんあるので、たくさん作ってみようと思う スマレジ4でやっと(社員の私でも感じるやっと感)APIの提供を開始することができて、できることの幅が広がりました。 これで社外の開発者だけでなく、社内の開発者もスマレジ4の実装を利用して自分の案を実現できるかもしれません。 ひとまずはアプリコンテストに注力することになるかな?と思います。 最後に 今回はスマレジ4とそのアプリコンテストについて記事にしてみました。 スマレジについて記事にすることが少なかった(技術的な記事の方が多い)ので、これまでとは変わった記事になっているかと思いますが、色々なAPIを利用して更に便利なサービスを作っていくのはいいことだと思ったので、記事にしました。 これを読んで、(スマレジ4)に限らず便利なアプリを作ってみようという気持ちのモチベーションに繋がれば幸いです。 この進捗についてはまた記事にしようと思います。 その時はよしなに。 .

私のお家の仕事環境(デスク編)

2020/08/26 2020/09/04

デスクをスッキリさせる系のnote記事読んでとても共感した話 こんにちは。Nonです。 今回はデスク周りをスッキリさせるために色々と工夫している方々の記事を見てとても共感した上に、私も真似にしてデスクスッキリ作戦をしている話をしようと思います。 もともとケーブル大嫌い 私はもともと工学系出身で、大学時代は自作PCとか、自作キットとか作るの大好きでした。(当時はまだDIYも流行ってなかったと思います。) 自作PCとか組み立てるとケーブルがとにかく多いんですよね。もうぐっちゃぐちゃです。 だいたいこのくらいか、それ以上のケーブルがマザーボードや電源から生えることになります。 これをなんとかしようと当時から色々していました。 また、私が大学に入学したくらいのときからスマートフォンとかが普及し初めてmicroUSBとかUSBケーブルを常備したり、普通に家庭で使用するレベルになったと思います。 だからケーブルがごちゃついて腹がたったのを覚えています。 社会人になってからはIT系の会社でネットワークを構築したりしていたので、LANケーブルと格闘したりしていました。 正味早く全部コードレスになればいいのに と思っています。 こういう考え方をするので、NFC技術はとても好きです。電子マネー決済はiDを主に使っています。 バーコード決済はなんか無理です。 リモートワークが本格的に始まった 幸か不幸かコロナの影響で、弊社にもリモートワークが普及し始めました。業種が業種でしたので、仕事の仕方がガラッと変わったわけでもなく、多少のリモート用設定さえすれば全てがうまくいく感じですすめることができました。 しかし、問題は違うところにありました。それは私の部屋が仕事に適していないということでした。いや、日常を過ごすだけなら十分な環境なんですが、仕事(8時間近く椅子に腰掛ける)環境としては微妙な感じでした。 もともとガジェット好きでしたので、必要なツールを以外と揃っているのですが、いかんせん「机」と「椅子」、そして「ケーブルの管理」がもう全然駄目でした。 まぁでもすぐにコロナも収束するだろうと思って特になんの対策も立てずにいたところ、デザイナーの方におすすめされた記事を読んで考えが変わり、お金はかかりますが、色々と揃えるようになりました。 そしてその記事がこちらです。 https://note.com/goando/m/me3ed2026f6ac noteをそんなに頻繁に利用するユーザーではないので、どういう仕組みかはわかりませんが、デスクをスッキリさせるジャンル?みたいなもので記事がまとまっているらしいです。 その記事の中でも特にこの辺が好き。 ケーブル1本だけの生産性最高なデスク環境をDIYなしで作った話 - 2019版 ケーブル嫌いのためのデスク周りをスッキリさせるテクニック 自分の部屋が「居住空間」ではなくなった 昇降デスクという存在は知っていましたが、居住空間には必要ないだろうと思っていました。 しかし、家で仕事をするので、居住空間ではなくなったのです。 まず最初に昇降デスクと少しいい椅子を買いました。 FlexiSpot パソコンデスク 電動式スタンディングデスク脚 昇降デスク 高さ調節 学習机 勉強机 ブラック(天板別売り) FLEXISPOT オフィスデスク用天板 DIY用天板 学習机 勉強机 スタンディングデスク120×60cmブラック SIHOO人間工学 オフィスデスクチェア メッシュ 通気性 昇降アームレスト 調節可能アームレスト ハイバックサポートクッション 腰サポート 360度回転 オフィスチェア まぁ生活変わりましたよね。最初はご飯食べたりゲームしたりする机だったので、生活感あふれる机上だったのですが、なにも置かなくなりました。(パソコンくらいかな?) 画像 買ったばかりの画像です。 この散らかっているケーブルをなんとかしようって感じですね。 というわけで、ケーブルを徹底的に排除してみた 最終的にこうなる なかなか排除できたんではないでしょうか?おしゃれなデスクを目指したわけではないので、無機質な感じになっています。私、こういう無機質というか無骨な感じ大好きです。 ケーブルがどこに行ったのかというと、「臭いものに蓋作戦」 です。 ケーブルの在り処 これだけ奥に隠れていたら、よほどのことがない限りケーブルを意識することがありません。 デスクにくっついているので昇降デスクを上下に動かしてもケーブルの長さの問題にぶち当たることは無いです。 昇降デスクの電源はこんな感じ。 うーん...手抜き! 私、両面テープで接着って嫌いなんですよね。ケーブル通す部品をデスクの裏にペタペタ貼りたくないので、こんな風になってしまいました。たまーに膝に当たるので今後の課題ですね。メーカーさんももう少し短くしてくれればよかったのに。 机の上に散らかるケーブルはどうしたの? 普段使用するPCはノートパソコン(Macbook Pro)なので、電源ケーブルやHDMIケーブルなどはどうしても机の上に出てきてしまいます。そこで、こんなものを取り付けました。 隠せないケーブルは整頓すればいいのです!! ゴム製じゃないプラスチックのスイッチ式のやつあればそっちでも良さそう。自動巻き取りとかしてくれないかなー? ちょっとした電源用に隠しコンセント デスクの電源を手の届かないところまで隠してしまったので、手近なところで一時的に電源が欲しくなるだろうなーと思ってデスクの支柱の裏に延長コードをペタリ。 この子は会社用のPCの電源など、頻繁に抜き差しする電源用に重宝しています。 正面からは全く見えません。 最後に noteに書かれている方は美しいデスクを目指している方が多い印象でした。例えばウッド調にしてシックな感じにしていたり、オーディオに特化させたりしたり。 私の求める美しさとは何も無いことなので、こんな感じになりました。 ちなみに昇降デスク、立ったり運動しながら仕事できるってだけじゃなくて、ちょっとした机の高さの調節がとても便利です。いろんな体勢でPCをいじれるようになったので、体がこることが少なくなりました。 次回は久々に記事の中にコードがあるものを書きたいですね。 その時はよしなに。 .

リモートワークが始まって大体半年が過ぎた感想

2020/08/26 2020/08/27

リモートワークが始まって大体半年が過ぎた感想 こんにちは。Nonです。 今回は3月くらいから始まったリモートワークについて少し話をしようと思います。 前々から働く場所に執着が無いタイプでしたので、リモートワークを一度くらいはしてみたいと思っていました。 幸か不幸かコロナの騒動の影響でリモートワークが本格的にスタートしました。 ちなみに、今回の騒動でリモートワークをするのは初めてです。 具体的にどういう働き方になったか? ぶっちゃけあまり変わってない! いや、変わってますよ?流石に。でも眼を見張るほど、「おぉ〜っ!」ってなるほど変わってないです。 リモートワークになる前からチャットツールは頻繁に使われていますし、口頭でのコミュニケーションよりも、チャットやドキュメントでのやり取りが多い職場ですので、リモートワークになってもあまり変わらない印象。 すこし変わったのは、内線電話が結構かかってきていたところが全てチャットになったというところでしょうか? 非常に助かりますね。 チャットツールに機能を求めるようになってきた G Suiteを採用しているので、Google chatを利用しているのですが、やっぱりSlackほど便利ではありません。(といっても私はSlack使い倒しているわけではないので、そこまで違いがわからないのですが) ただ、他のチームはSlack(無料版)などを利用しているところもあるようです。 ちなみに私は個人プレイが多いのでチャットをあまり利用しません。 通勤しなくていい!! いやぁ、これは本当に大きいですね。 私の趣味がツーリングなので、都会に住まいを構えていないのです。ツーリング行くときに便利な「駅から少し遠い」「高速沿い」の「少し安めで広いところ」を借りてますので、普段の通勤に大体60分くらいかけてました。往復で2時間ですね。 これがなくなったのは本当に大きいです。 ご飯をあまり食べなくなった 勤務地がオフィス街なので、職場の周りにはたくさんの飲食店が並んでいるのですが、私の住まいの周りにはそれが全然ありません。自炊かコンビニかなので、もう面倒臭くて昼ごはん抜いちゃうことがあります。これなんとかしたいんですよねー。 リモートになって良くなったこと みんなちゃんと考えてからアクションを起こすようになった これは私もそうなったと思います。 これまでは、わからないことがあれば、とりあえず直接聞いてみようみたいなところがありましたが、それが消えました。チャットのためにタイピングするのが面倒くさい、電話 / ビデオ通話するのが面倒臭いみたいなところができたからでしょうか? 自分の時間が増えた 通勤が無くなって、自分の時間が増えました。 なので、余った時間で勉強したり、自分のためのアプリ開発をしてます。 軽視されがちですが、これ会社としたら非常に大きいと思いますよ。通勤や残業の強制(という空気感)があると、やっぱり自分の時間をくれる会社とそうでない会社っていう印象を与えてしまいますから、いい人材ほど外にいってしまいます。 リモートになって悪くなったこと 無いと思います 強いてあげるなら、何か(技術的な / アイデア的な)閃きのトリガーが減った。くらいでしょうか?雑談はとても効果があるんだなと思いました。 今後も続けたいか?頻度は? 続けたいですね。少なくとも、プログラマーという職種の上ではメリットの方が明らかに多いです。 しかし、フルリモートは駄目だと思います。 やっぱり顔を合わせる時間は必要に思います。 その頻度は週1くらいでいいのではないでしょうか? その週1の出勤はコミュニケーション重視の勤務で、一週間に一回しか無いからこそ、大事なMTGになるのではないでしょうか? 最後に 今回は半年リモートワークをしてきたので、その感想を書いてみました。 中にはリモートワークできない業種もあるかもしれませんが、必要に応じて導入していきたいですよね。せっかく世界が便利になっているのに、便利になった(効率が良くなった)のだからもっと働け!ってのは少し違う気がします。 次の記事はリモートワークするにあたって自分のデスク周りを少し改造してみた話ができたらなと思います。 その時はよしなに。 .

スマレジ・デベロッパーズのstorybookを作成してみて

2020/08/16 2020/08/16

スマレジ・デベロッパーズのstorybookを作成してみて 7月半ばくらいから、スマレジ・デベロッパーズでstorybookを作成し始めています。ver.1.2.0くらいからstorybookで作成したコンポーネントをインポートしてそのままデプロイするようになります。 smaregi-developers-ui 権限つけてないので、まだ見れないと思います。 Sample 個人用storybook https://storybook.nozomi.bike メリット 少し順不同感が否めませんが、思いつくまま列挙してみました。 1. 複雑な環境の操作をデザイナーに強いることがない。 これまではデザイナーに複雑な環境の操作を要求していました。エンジニアの目線からではだいぶ簡単になった操作(Docker操作)も、デザイナーにとっては未知の領域です。 少なくとも、デザインと言う仕事するにあたって、 Docker for Macをインストールする必要がなくなります。 MySQLクライアントツールなど、余計なソフトをインストールする必要がなくなります。 それに応じて、そのソフトの勉強コストがなくなります。 別プロジェクトなので、管理が比較的楽になります。 という、デメリットを削除することができます。 2. エンジニアがデザイナーに依頼しやすくする。 ちょっと誤解を招くような内容ですが、デザインはエンジニアの仕事ではありません。(エンジニアがデザインをしている人が入ればその人はエンジニア兼デザイナーというだけです。) エンジニアがしばしばデザイナーの領分に侵食して口を出したりします。意見を言うのはとても良いことだし、大事にしていきたい文化なのですが、なぜか(エンジニア>デザイナー)のような構図で最優決定権はエンジニアサイドが持っています。 上記の問題を 「デザインの仕事が別のプロジェクトになること」 で、明確な役割分担を推進することができます。つまり、デザインに関する業務はデザイナーの責務というのをエンジニアが直に感じることができます。 更にその副産物として、フロントのビジネスロジックの分離を行う事ができますが、これは後述します。 3. エンジニアがデザインで悩むことがなくなる。 ほとんどのエンジニアはデザインに興味なんてなく、 「大体同じ感じでいいから。」 とか、 「他のページがそうだから〇〇みたいな感じが良いんだけどなぁ。」 という感じになります。これはエンジニアが怠惰というわけではなく、デザインに割く(関心的、業務的)リソースがないだけだと思います。 それらをすべて本来の持ち主であるデザイナーに渡し、自分は本来すべき業務に集中できるようになります。 4. デザイナーとエンジニアの架け橋になる storybookというプロジェクトはデザイナーとフロントエンジニアの責任で進むプロジェクトなので、デザイナーの意思が反映しやすく自発的に良いものが仕上がっていきます。 なのでエンジニアもデザイナーへの依頼がしやすくなり、これまでの外注的なやり取りではなく、フロントエンジニアとデザイナーの架け橋になるようなものになります。 例えばボタンをstorybookに作成したとして、クリックしたときの挙動をフロントで記載したとすると、そのボタンをクリックしたときそのコンポーネントがどうなるかをデザイナーとフロントで相談するでしょう。 このとき重要なのはプロジェクトとして、その動作がどうなるかではなく、そのコンポーネントがどうなるかを検討するのです。プロダクトを支えるコンポーネントをデザイナーとフロントエンジニアが協業して作成するようになるので意欲が湧いて来ると思います。 5. ビジネスロジックとイベント関係を分けることができる ここの内容はフロントに処理を書くとき、フレームワーク内で処理は書かない方がいい気がする ここの記事と言いたいことはほとんど同じです。 具体的に言うと、storybookは正確には別のプロジェクト、パッケージの扱いになるので、よっぽどの専用コンポーネント以外にはビジネスロジックに関わる処理を書きたくありません。 その思想の元作成すると、自然とコンポーネント内でAPI呼び出しを行うなどの設計が解決します。 6. 本番のコードと同じ内容でデザインレビューができる これはこれまでのプロダクトそのものをデザイナーに見せてレビューする方法と何が違うのかと疑問を持つ方が居ますが、その回答は火を見るより明らかです。 デザイン単体でレビューが可能 storybookにPRを投げることになるので、機能的観点のレビューが必要ないです。 だから素早くマージまで行う事ができます。 デザイナーが自身の環境で「動き」のレビューをすることができる 一度コンポーネントを作成すると、自作コンポーネントの使いまわしができる 新しく作り直したり、コピペじゃない 俯瞰して(先入観なしで)デザインできる デメリット 1. デザイナーのstorybook学習コストが増える storybookはNodeパッケージなので、デザイナーもある程度のnpmコマンドの知識を保つ必要があります。しかし、デザイナーのすべてがNodeの知識があるかと言われればそうではないので、勉強するコスト、または教育するコストが発生します。 2. エンジニアのプロジェクト管理コストが増える バックのプロジェクトだけではなくフロント用のプロジェクト(しかも厳密にはプロダクトと関係無いもの)を管理する必要が発生します。 プロダクト自身に導入するパッケージにはより一層慎重にならなければなりませんし、フロントの構成についてもっと考慮する必要が発生します。 例えば、導入するStorybook側にBootstrap5が入っているとして、プロダクト側はまだBootstrap4の場合、デグレーションを起こす可能性がないと言い切れません。(特にCSSの観点から見ると。) 3. 既存のプロダクトに導入するコストはやっぱりある程度ある すでに画面レイアウトが完成仕切ってるプロダクトに改めて導入するにはコストが発生します。 もちろん導入することでボタンの変更を一括で管理できるようになったりするのは便利ですが、すでにリリースされている画面のコンポーネントをすべて揃えるまでかなりの時間を要するでしょう。 スマレジ・デベロッパーズは一般公開してまだ1ヶ月ですが、すでにしんどい面があります。 特にこのプロダクトはオフショア開発で画面によっては全く違う実装をされていた経緯があるので。 今後どうしていきたいのか CSS(デザイン) / HTML・javscript(フロント) / PHP(バック) を完全に分解し、適宜その中から必要なパッケージを呼び出して使えるようにしていきたい Style - CSS デザイナー・フロントエンジニアが担当。CSSをデザイナーが書かず、エンジニアが書く。 Styleのほとんどはすべてのプロダクトで共通。イメージは POSテーマ Waiterテーマ Timecardテーマ で別れているというイメージで、コンポーネントが全く違うわけではない。(専用コンポーネントは当然存在するが、共通コンポーネントに差異が無いという意味で。) ここで作成されたCSSはNodeパッケージ / CDNなどで共有できるようにする。 copied.┏ pos.min.css ┣ waiter.min.css ┣ timecard.min.css ┗ smaregi.min.css StoryBook 各プロダクト、ないしは共通で存在する。コンポーネントの目的と仕様を記載するプロジェクト。 パッケージ化されたCSSを読み込みテーマ切り替えができるようになっている。 ビジネスロジックを持たずに、機能だけを持つ。 Nodeパッケージ化され、簡単にコンポーネント共有できる。 View 各プロダクトのページ / 画面。 Storybookで作成したコンポーネントと、ビジネスロジックモジュールを読み込みページの要件を満たす。ここで、ビジネスロジックをパッケージ化するのかという議論がありそうだが、そこまでしなくていいんじゃないのかなとは思っています。しかし、ビジネスロジックモジュールはできるだけバニラで書かれるかTSで書かれるかするのがベターです。(スマレジ・デベロッパーズはバニラ) 一部バックがHTMLをレンダリングする場合もあります。 Back Viewを返さない、APIサーバーであるのが理想です。さらにドメインレベルでマイクロサービス化され、必要に応じたパッケージ群で構成されているとさらに良いです。 以上のことができれば、一つ一つの責務を小さくすることができて、開発がとても楽ちんになるはずです。 Storybookを一般公開したい スマレジ・デベロッパーズはこんなので作成されていますと自信を持って公表できるなら、採用にも使えるはず。「こんなデザインしてみたい」「こういう働き方してみたい」という需要は必ずあるはずです。 https://story.smarthr-ui.dev/ サボりたい もう一からHTML書くの嫌だ。デグレも嫌だ。一回書いたら二度と書きたくないです。 最後に 今回は社内向け資料としての記事でした。 内容を精査したら限定公開ではなく一般公開となっているかもしれません。 storybookが必須というわけではありませんが、似たようなデザインマップがある以上あった方が良いと思います。 今回は概論でしたので、技術的な導入方法も少しずつ書いていこうと思います。その時はよしなに。 .

@storybook/addon-actionsを利用したときのTips

2020/08/10 2020/08/13

@storybook/addon-actionsを利用したときのTips こんにちは。Nonです。 最近、フロントのこともガッツリと関わるようになってきました。デザインのセンスはあまりありませんが、デザインシステムがどれだけ有効なのかは、UIデザインについて少し調べてみた。の記事ですでに記述しています。 そのデザインシステムをまとめ、管理するためにstorybookを採用したのですが、そのaddonである@storybook/addon-actionsを導入したときにハマったtipsを記載しようと思います。 actionが起動しない問題 これは私がjavascriptの理解が浅いせいなのですが、下記のように書くとactionが起動されず、 copied.storiesOf('Button', module) .add('default', () => ({ components: {Buttons}, template: '<Buttons @click="action"></Buttons>', methods: { action() { // 起動しない action('clicked'); } } })); 下記の様に書くと、起動します。 copied.storiesOf('Button', module) .add('default', () => ({ components: {Buttons}, template: '<Buttons @click="action"></Buttons>', methods: { action: action('clicked') /* 起動する*/ } })); これ全然わからない。 誰か知っている人いたら教えて下さい。 storybookって便利 お試しに作成しただけですが、https://storybook.nozomi.bike/に自分のデザインストーリーを作って公開してます。 storybookで何ができるかを知るにはちょうどいいし、それをどのように使っているのかをしれていいと思います。 公開されているstorybookでもっといいものはたくさんあるので、それを探すのも面白いですよ。 最後に 今回はとても短い記事ですが、内容はかなりハマったことでしたので、許してください。 なぜこれが駄目だったのかわかったときは、この記事を更新します。 その時はよしなに。 .

laravel-mixでjavascriptのコンパイルをするときのTips

2020/08/05 2020/08/05

laravel-mixでjavascriptのコンパイルをするときのTips こんにちは。Nonです。 今回は正直Laravelのドキュメント読めば分かる内容なので、みんなの力になれるかどうかわからないです。 私の備忘録ついでという感じになると思います。 laravel-mixでVueを作成するときapp.jsが作成されます。 このとき、app.jsをbladeで読み込むとき、おそらくこう書くと思います。 copied.<script src="{{ asset('js/app.js') }}"></script> しかし、上記のように読み込んでしまうと、リリースされるたびにapp.jsの中身は違うのに、ブラウザのキャッシュのせいで以前のバージョンを読み込んでしまいます。 そこで利用するのはmix()です。 copied.<script src="{{ mix('js/app.js') }}"></script> このようにすると、Laravelのpublic/mix-manifest.jsonの中身を使用してapp.jsなどを読み込もうとします。 copied.{ "/js/app.js": "/js/app.js", "/css/app.css": "/css/app.css" } しかし、このままだと変わらずキャッシュが効いてしまうことになるので、javascriptのコンパイルをするときに、public/mix-manifest.jsonの内容が一意になるようにします。 具体的にはwebpack.mix.jsを中身を修正します。 一番最後の行に下記を追加します。 copied.if (mix.inProduction()) { mix.version(); } このようにすると、npm run prodなどの本番環境にデプロイするCIで一意なキーを持ったpublic/mix-manifest.jsonを作成することができます。 作成したpublic/mix-manifest.jsonはこちら。 copied.{ "/js/app.js": "/js/app.js?id=d2353c498302a1106cf8", "/css/app.css": "/css/app.css?id=0ec4c3ecb9972406f852" } こうすることで copied.<script src="{{ mix('js/app.js') }}"></script> <script src="{{ mix('css/app.css') }}"></script> 上記のコードは?id="d2353c498302a1106cf8"を含むリンクとなります。 idは一意なキーなので、npm run prodを利用してデプロイするたびに新しいファイルをサーバーへリクエストします。 開発環境でも同様のことが行いたい場合は、 copied.if (mix.inProduction()) { mix.version(); } からif文を削除すれば大丈夫です。 copied.mix.version(); (adsbygoogle = window.adsbygoogle || []).push({}); 最後に 今回は備忘録ついてでに記事を書いてみました。 これを知るまではServiceWorkerを利用して遠回りに更新してました。。。 ブラウザのキャッシュをServiceWorkerでクリアする処理を書いてました。これを知ったときには何故こんなに初歩的なことを知らなかったのか恥ずかしかったです。 ということで今回はここまで。 次回はStorybookの記事を書いてみようと思います。 その時はよしなに。 .

リリース内容を小さくしたらいろんなメリットがあった話

2020/07/26 2020/07/29

リリース内容を小さくしたらいろんなメリットがあった話 こんにちは。Nonです。今回はリリースする内容を小さくしたら色々なメリットがあった話をしようと思います。 とは言っても、すでにdevsOpsやマイクロサービスが浸透してきているので、リリース内容が小さい方が良いというのは知っているかもしれません。 ここでは、やっぱりやってよかったよねという話にしていきたいと思っています。 1. リリースを小さくしたらバグが減った リリースを小さくするということは実装する機能の数が減るということです。ということは、制限時間内に(納期までに)開発者が向けるべき関心事が減るということですね。 正直、この内容をシェアしたくてこの記事を書いたまであります。 リリースが小さくなったので、リリースまでの納期は短くなります。しかし、自分が注力すべき内容が小さいので、その全てに全力を注ぐ事ができます。そのおかげで、明らかに今までのコードより品質が高くなりました。QAチームからのフィードバックも減り、実装コストだけではなくて全体のコストも減りました。 やはりバグ原因での手戻りが少ないとストレスも減って進捗がいい方向に向いていくことを実感することができました。 2. リリースを小さくしたらマネジメントしやすくなった 1と同様に、関心事が減るので、把握すべき進捗の内容が減りました。おかげで今までおざなりになっていたプロジェクトの進捗の把握もかなりしっかりできて、ほぼ計画どおりのプロセスを踏むことができました。 (この案件では私が実装兼PMみたいな感じ) こうなると、マネジメントする側にもかなりのメリットがアルのではないでしょうか?進捗管理という事務作業が一気に減ることになりますんので、本来PMがすべき真の意味のプロジェクトマネジメントを遂行することができます。 追記するとPMはプロジェクトの進捗管理をするだけの役職ではないと個人的に思っています。 このことに関しては賛否あるかもしれません。 私もPMについてしっかりと勉強できているわけではないので、おかしな点があるかもしれません。簡単に書くとPMは POから欲しいと言われた機能を吟味し、取捨選択する 機能についてメンバーに割り当てる 機能から更に分割されるであろうタスクはメンバーが決めるもの 機能について終了日のあたりをつけ、QAとの連携をとる リリースにあたって他のプロダクトとの影響について調査する この辺ではないかと思っています。 何やら一般的にはスケジュールばかりに目が行っていますが、どう考えてもそれは副産物で、メンバーとの折衝、他のチームとの折衝こそがPMの本来の仕事のはずです。(だからコミュ力が求められるのだと思います。) 上述した内容を遂行した結果、たまたま進捗管理をしていたというだけだと思います。 逆に言えば、他の影響範囲との摩擦がなければリリース日なんて「完成した日」になると思ってます。 3. リリースを小さくしたらスピードが上がった(たくさんのピリオドを打てる) マラソンを走るスタイルで、ダラダラと開発をしていたのが、パッと開発してストップ、パッと開発してストップ、の連続になりました。メリハリが効いてピリオドも明確に打てる。何かあったときのトラブルにも強い印象になりました。 ピリオドを打てるというのはとても大きくて、終わったら前回の反省をすることができます。対して、長ーいスパンで開発すると、その途中で反省会をしてもあまり意味がないように思えます(経験)。 長ーいこと開発を続けるよりも、キチンとピリオドを打って、終わったよということを表明できるのはメンタル的にも優しい気がしました。 最後に リリース内容が大砲の弾のように大きくて必死こいて弾を運んで、外したらOUT。みたいなのより、リリース内容は小さくして気軽にパパパパっと打てるサブマシンガン的な手法の方が手軽でいいです。 小さい分、何回も繰り返してリリースすればいいですし。 この取り組みは今後も続けていきたいです。 今回は私の主観が多めでした。 次回は何書こうかまだ決めてないです。でも記事にはします。 その時はよしなに。 .

車輪の再発明は悪なのか?

2020/07/24 2020/07/24

プログラマが知るべき97のこと こんにちは。Nonです。本日はプログラマが知るべき97のことを読んでいてこれ「いいな」と思った箇所について書いてみようと思います。 こちらの書籍はとても有名なので、既読の方もいらっしゃるかもしれません。 そういう方は復習というか、内容を思い出したり、私の意見と違うところや共感できるところを探していただければ幸いです。 プログラミング業界では車輪の再発明は悪と見られがち? 一度作成されたコードを再作成することはしばしば嫌がられる傾向にあるのがプログラミング業界です。例えば、Bootstrapを導入しているプロダクトでモーダルを表示する処理を自作する意味はあまりないでしょう。 もしあるとすれば、 Bootstrap依存(jQuery依存)をしたくない すでにある機能のテストを再度したくない などでしょうか? もちろん、その中にはDry原則もあるでしょうが、Dry原則とはそもそも Don't Repeat Yourself なので、自分自身のコードの中で同じような処理を作成することはアンチパターンだよってことを示していると思います。 あとはOSSにあるツールなどを知っているパターンでしょうか。 OSSに実装したい機能とほぼ同じものがある場合、そちらを利用したほうが遥かに効率がいいからです。 では車輪の再発明にメリットがあるときはどのようなとき? しかし、実は私は車輪発明は大好きです。何故かというと車輪の再発明はとても勉強になるからです。 車輪の再発明で得られるものは多いです。 たとえば、モーダルを表示するために必要な技術は何か?表示するときにアニメーションを入れるにはどうすれば良いのか?このようなことを勉強するにはうってつけです。 更にその機能の構造や動きを理解することで、その機能を利用するときに気をつけるべきことやどのように利用すれば気持ちよく動作するかがわかります。 独自フレームワークは嫌われやすい 似たような話に独自フレームワークがあります。 今大抵のプログラミング言語にはフレームワークがあります。 黎明期の頃はフレームワークが充実していなかったので独自フレームワークを作成することがはやっていましたが、今では特殊な案件以外ではありえません。 しかし、独自フレームワークを作った人はフレームワークの構造を理解しています。 例えばWEB用のフレームワークを作成した人はリクエストとレスポンスを捌く部分についてよく知っているので、どう捌けば良いのか、どのように作れば良いのかを(作ったことがない人より)知っていることでしょう。 もしかしたら、独自フレームワークを作ったことがある人こそ、人気のフレームワークの便利さを一番理解しているのかもしれません。 最後に 実際のプロジェクトで何も考えずにパッケージが導入されていることはよくありますし、用途が重複したパッケージが導入されているものも見たことがあります。 これは、パッケージの特性を理解しないまま「ただできるから」、それだけの理由で導入したのでしょう。 そういうことが無いように、すでにできている車輪を使うだけでなく、その構造と使用方法を理解した上で使えるようになりたいですね。そしてそのためには車輪を自分でも作れる必要があるのではないでしょうか? ここまで書いておいてなんですが、私個人の意見です。 次回もプログラマが知るべき97のことを読んで記事にしようかなと思っています。 その時はよしなに。 .

ユビキタス言語を重視する

2020/07/13 2020/07/13

プログラマが知るべき97のこと こんにちは。Nonです。本日はプログラマが知るべき97のことを読んでいてこれ「いいな」と思った箇所について書いてみようと思います。 こちらの書籍はとても有名なので、既読の方もいらっしゃるかもしれません。 そういう方は復習というか、内容を思い出したり、私の意見と違うところや共感できるところを探していただければ幸いです。 ドメインの言葉を使ったコード 突然ですが、DDDではユビキタス言語という業務上の言語を反映することが大事だよ。ということが言われています。 ユビキタス言語ってなに? ユビキタス言語というのは、プログラミング設計をする上で、開発者だけでなくその他のステークホルダーとの共有言語のことを指します。 例えば、荷物の運送管理システムを使用する時、開発者はよくユーザーという言葉を利用しますが、ステークホルダーは運転手という言葉を利用するとき、やはりシステムでも運転手という言葉を利用する方がいいでしょう。 そして、開発者が運転手という言葉を利用するというのはコードにも反映するということになります。 例えばユーザーが荷物を運ぶ処理を持っていたとすると、 copied.<?php class Driver { /** * @var int */ private $id; /** * @var string */ private $name; public function __construct(int $id, string $name) { $this->id = $id; $this->name = $name; } /** * @param Luggage $luggage * @return void */ public function transferLuggage(Luggage $luggage) { // 荷物を運ぶ処理 } } となります。クラス名はUserではなくDriverとなりますね。 ではログイン処理ではどうなるでしょうか。 境界付けられたコンテキストの観点からみると、ログイン処理は業務知識とはまた違うドメインになりますので、この場合はDriver->login()ではなく、User->login()の方がいいでしょう。 このように、業務知識内の言葉を利用することで、プログラムコードと実際にミーティングなどで利用される言葉の乖離を防ぐことで、ユースケースの齟齬、つまりユーザーとの誤解を避けるために作成され、使用する言葉のことを指します。 プログラムコードに仕様を書き込むとは? こちらもしばしば見かける内容です。 仕様書を作成しないという意味ではありませんが、できるだけプログラムコードに仕様を反映するということは結構前から言われていたように思います。 キーワードは私の知る限り3点。 ビジネスロジック 抽象クラス ユビキタス言語 でしょうか。 ビジネスロジックで仕様をコードに表す ビジネスロジックで仕様をコードに表すとは何か?2020年に突入した今なら、すでにご存知の方もたくさんいらっしゃるでしょう。 私はこれまで色々なプロジェクトを経験してきましたが、とにかく、コントローラーだけで実装を終了していたり、プログラムコードの示す目的がコードに反映されていないコードをたくさん見ました。 だから、「コードの仕様を先輩に聞いたり」、「なぜ、このコードが必要なのかを議論する」必要があったのです。 試しに例を作成してみました。 copied.class TransactionController { public function store(Request $request) { // バリデーション処理など $user = Auth::user(); Transaction::create([ 'user_id' => $user->id(), 'product_name' => $request->get('name'), 'product_price' => $request->get('price'), ]); // 処理 } } これが示す仕様、ユースケースをこのコードから読み取れるでしょうか?簡単な例なので、もしやわかる方もいらっしゃるかもしれません。しかし、なんとなくTransaction、取引を作成する処理だとわかるくらいでしょうか? このコードは改善が必要に思います。 copied.class TransactionController { /** * @var BuyProductInterface */ private $useCase; public function __construct(BuyProductInterface $useCase) { $this->useCase = $useCase; } public function create(Request $request) { $this->useCase->process(); } } class BuyProduct { /** * @var CustomerService */ private $customerService; public function __construct(CustomerService $customerService) { $this->customerService = $customerService; } public function process() { // $customer, $productの定義 $this->customerService->buy($customer, $product); } } class CustomerService { /** * @var TransactionRepositoryInterface */ private $transaction; public function __construct(TransactionRepositoryInterface $transaction) { $this->transaction = $transaction; } /** * @param Product $luggage * @return void */ public function buy(Customer $customer, Product $product) { // 商品を購入する処理 } } ここまで書けば先程より伝わるでしょうか? このプロジェクトの示す取引を作成するというのはお客様が商品を購入することを示していたのです。 このようにビジネスロジックそのものをコントローラーに直接記述してはいけません。とても無機質なコードになり、コードを業務に置き換える作業がとても大変で開発者にとってストレスがかかります。 このような現象をプログラムコードを業務へ翻訳するとか言ったりしますね。 その翻訳作業を無くすために、翻訳してある状態でコードにしておくことが重要です。業務に関する知識をビジネスロジックとして別に切り出し、そこでは業務に関する言葉などを利用することで、コードに仕様を表す事ができます。 抽象クラス 以前、ドメイン駆動設計の読書会についての記事で、「抽象に依存せよ」といった旨について記事にしたことがありますが、抽象クラスの役割は依存関係の解消だけではありません。仕様をコードに表すという観点からも有用です。 もしかしたら誤解を生んでしまうかもしれませんが、抽象クラスはそのオブジェクト(つまり業務での登場人物)のできることリストと言い換えることも出来ます。 1番はじめに使用した運転手の例で作成してみましょう。 copied.interface Driver { public function transferLuggage(Luggage $luggage): void; public function startRest(DateTimeInterface $from): void; public function endRest(DateTimeInterface $to): void; public function moveBase(Base $base): self; } (実際の業務を無視して、)とにかく運転手ができそうなことをリストにしてみました。 運転手ができそうなことがこの抽象クラスからわかるかと思います。 開発者はこのクラスから、「このドメイン内の運転手はこのようなことができるのか」と大まかな仕様を理解することができるはずです。また、今後のミーティングなどで運転手にできることが増えたなら、この抽象クラスに処理を追加すればいいこともわかります。 入力値と出力値もわかるので、コーディングレベルでも伝えられることは多そうです。 ユビキタス言語 最後にユビキタス言語でコードに仕様を表してみましょう。 実はここまでのサンプルコードで出てきているのですが、プログラム処理的な言葉を排除し、業務的な言葉でコードを書くことを示します。(大体) copied.class CustomerService { // 省略 /** * @param Product $luggage * @return void */ public function createTransaction(Customer $customer, Product $product) { // 取引を作成する処理 } } このようなコードだとcreateTransactionがどのような業務フローを示すのかがよくわかりません。 コードの内容をそのまま受け取るとお客様が取引を作成する? うーんちょっとわかりません。 copied.class CustomerService { // 省略 /** * @param Product $luggage * @return void */ public function buy(Customer $customer, Product $product) { // 取引を作成する処理 } } このようにすればわかりますね。関数名がbuyですし、Product型の変数を渡していることから商品を購入する処理ということは想像できそうです。 このように変数名 / 関数名を少し業務に寄せるだけでも全然違います。 とても簡単に見えますが、結構難しいです。プログラミングをしているときは頭がプログラムの味方をしてしまうのです。 もう少し極端にしてみる 商品登録をする処理を作成してみましょう。 copied.class Staff { public function createProduct(Product $product) { // 商品登録処理 } } あっているようにも見えます。createはデータストアにデータを登録する処理として名付けられることもしばしばあります。 でもこれで満足してはいけません。本来ならこうなるはずです。 copied.class Staff { public function registerProduct(Product $product) { // 商品登録処理 } } 登録なのですからregisterですよね。 商品更新ならどうでしょうか?updateProductが正解っぽいです。でもミーティングでは商品編集という言葉で進んでいました。ではeditProductが正解でしょう。 いやいや、ウチのミーティングでは商品保存で統一されているんだよ。 ならば、saveProductでUPSERT的な処理を記述するべきでしょう。 このように細かいところまで使用する言葉に気をつける必要があります。 こうすることでコードに仕様を表すことができるのです。 最後に コードに仕様を書くことの大切さはプログラマが知るべき97のことでも書かれていましたね。 ここまでするの面倒だからしないという方もいるかも知れませんが、どうせコメントに仕様書くならコードに書きませんか? 次回もプログラマが知るべき97のことを読んで記事にしようかなと思っています。 その時はよしなに。 .

ボーイスカウト・ルールを現実的に実現するためには?

2020/07/06 2020/07/06

プログラマが知るべき97のこと こんにちは。のんです。 本日はプログラマが知るべき97のことを読んでいてこれ「いいな」と思った箇所について書いてみようと思います。 こちらの書籍はとても有名なので、既読の方もいらっしゃるかもしれません。 そういう方は復習というか、内容を思い出したり、私の意見と違うところや共感できるところを探していただければ幸いです。 ボーイスカウト・ルールってなに? プログラマが知るべき97のことにはこう書いています。 ボーイスカウトには大切なルールがあります。それは、「来た時よりも美しく」です。たとえ自分が来た時にキャンプ場が汚くなっていたとしても、そしてたとえ汚したのが自分でなかったとしても、綺麗にしてからその場を去る、というルールです。 最近、私の町ではボーイスカウトの姿を見なくなってしまいました。私が子供の頃は友達がボーイスカウトしていたこともあって結構身近な存在だったのですが、現在はどうなんでしょうか? しかし、これまでの人生このような光景は見たことあるかもしれません。ボーイスカウトに限らず、小学校で美化活動として昼過ぎくらいに町内清掃している姿くらいは見かけているはずです。 「この考えをプログラミングにも取り入れようよ」という考えがボーイスカウト・ルールです。 結構簡単そうじゃない?いえいえ、かなり難しいはずです。 コードに散々しているゴミコードをただ修正変更するのは結構簡単と思えるかもしれませんが、私は難しいと感じます。その理由を1つずつ挙げると、 バグ修正は気軽にできない すでに正常動作しているコードを修正することへの心理的ハードルが高い 納期に追われているなど、時間的余裕が無い コミットをきれいに保ちたい。(ブランチ作成や切り替え作業が面倒くさい) すぐに思いつくのは以上のような理由でしょうか?他にも色々あるかもしれませんが、多分共感していただけると思います。 バグ修正は気軽にできない バグ修正は気軽にできません。影響範囲の調査や、バグを修正したことによるデグレーションを考慮しなければならなくて、とても工数がかかります。ゴミ拾いと同じ感覚で修正していたらいつの間にかscrap & buildしていたとかなりかねません。(時間的余裕と、影響範囲潰しができればとてもGJ👍ですが!!) すでに動作しているコードを修正することへの心理的ハードルが高い 四則演算の効率化や簡単化など、ちょっとした処理の修正に対して変更を行うことを想定しましょう。すでに正常に動作しているコードを修正すると考えるだけで不安になります。心の中で、(うーん……次のマイナーバージョンでするか)みたいになるのは火を見るより明らかです。 納期に追われているなど、時間的余裕が無い。 これは簡単ですね。そもそもその程度の修正をする時間すら存在しない時です。 コミットをきれいに保ちたい 一般的にGitを用いて開発をする場合、ブランチは機能単位に切られ、マージできるレベルでコミットされるはずです。あるAという機能を作成しているときに、ボーイスカウト・ルールに則って修正を行うと、A機能のためのブランチにBの修正が混じることになります。これを嫌がる人や、是としないチームはたくさんあるはず(というか、そういうルールが推奨されているはず)です。 そういうルールがある中でボーイスカウト・ルールを適用しようと思うと、(Aという機能を作るという別の仕事をしているにも関わらず、)ブランチを新しく作成したり、マネージャーへ連絡したりしなければなりません。 それが面倒臭いという人は必ずいるはずです。(私もそうでした。) こういった「課題をクリアする」というより、ボーイスカウト・ルールを適用しやすい環境を作る方がとても簡単です。上記の課題を例にボーイスカウト・ルールを適用しやすい環境を考えてみました。 (adsbygoogle = window.adsbygoogle || []).push({}); ボーイスカウト・ルールのハードルを下げる 見かけたバグはすぐ直す。このルールをそう受け取る方もいるかも知れませんし、そう思っていない方も、義務感から修正への執念を持っているかもしれません。私の知り合いには、あまりにひどいコードに遭遇し、もはやこの考えが強迫観念となっている方がいました。 もっと気軽に考えましょう。以下のポイントを押さえ、継続すればうまくいくはずです。 変数名や関数名本当に軽微なポイントにのみ注目する ノルマなどは当然設けない 修正というより整頓と考える(後述) 関連して、一気に修正 / 整頓しない 修正というより整頓と考える 例えば、引き継いだプロジェクトで下記のようなコードに出会ったとしましょう。自分はある程度経験を積んで、よくわからない処理を調査していました。数十分ほどかけて、そのロジックを解き明かしたとしましょう。 copied.<?php class DustSample { /** * @var string */ private $dust; /** * @param string $dust */ public function __construct(string $dust) { $this->dust = $dust; } public function unknown() { // 難解なコードで自分が頑張って読み解いた重要な処理 } } この時、unknowメソッドをボーイスカウト・ルールに則り修正するのではなく、コメントを書くなどして、わかりやすくしたり、一部privateメソッドなどで切り分けられそうなものを切っておきましょう。だから修正より整頓と考えるわけです。 copied.<?php class DustSample { /** * @var string */ private $dust; /** * @param string $dust */ public function __construct(string $dust) { $this->dust = $dust; } /** * 〇〇を✕✕して△する処理 */ public function unknown() { // 難解なコードで自分が頑張って読み解いた重要な処理 } /** * 〇〇を✕✕する処理 */ private function unknown_parts() { // 難解なコードの一部、でも、処理を切り分けることでどんな処理をするのかが少しわかりやすくなっている } } 少しはハードルが下がるはずです。少なくともコメントの追加で動作が変わるというのは早々ないでしょう。 これまでの慣習をできるだけ無視し、オブジェクト単位で、特に依存を無くす実装にする PHPだとよくあるのは、全部Controllerに書かれていて、しかもそれが他の処理に密結合を起こしている場合です。 そうなってくると、ボーイスカウト・ルールどころではありません。 ちょっとした改修タスクを作成し、その部分だけでもオブジェクト化しておきましょう。 クリーンアーキテクチャに基づいたDDDがオススメではありますが、そうでなくても、振る舞いを閉じ込めたEntityのみを採用するだけにとどめたり、ValueObjectだけでも採用したりすることで、ボーイスカウト・ルールをしやすいコードへと変身させるのです! わかりやすい、あるいは依存していないコードに対してはとても修正をかけやすいです。心理的ハードルが下がるはずです。Interfaceで抽象クラスを作成したり、ControllerではなくActionでリクエストを捌いてみたり、とにかく小さく処理を作成するように心がけると、みんなは自然とゴミを拾ってくれます。 ここでも大事なのはストレスのかからないレベルで導入することです。隅っこの方のディレクトリにModels/Entityとディレクトリを切り、その中に必要な振る舞いと値を入れるだけとかでもいいです👍 テストコードを整備する ここまでで気づいている方は多いでしょう。 テストコード、これがあればストレスとはおさらばですね👍 なんちゃってリファクタリングではなく、本格的なリファクタリングができるようになります。 https://www.amazon.co.jp/Java言語で学ぶリファクタリング入門-結城-浩/dp/4797337990 その時はこちらの書籍を読むといいかもしれません。 TDD(テスト駆動開発)と勘違いする方がいますがここでは関係ありません。 リファクタリングについては、また違う記事でしましょう。 やはり一番の処方箋は開発者の心理的ハードル下げることでしょうか。 修正してくれたことを褒めたり、感謝する文化を作ったり その修正を勤務評価にフィードバックしたり ポジティブな理由ですすめることができたら間違い探しをしているみたいに楽しいかもしれません ボーイスカウト・ルールを適用するにあたっての注意点 一応デメリットとしてあげられるのは、計画的 / 継続的にやりましょうとういことです。 計画的に進めなければ、プロジェクトの方針と食い違う可能性が出てきます。継続的に進めなければ、中途半端になってしまいます。 見かけたら100%の修正をする必要はありませんが、その分続けなければならないことは感覚的にわかりますね。 最後に ボーイスカウト・ルール。この考えとても好きです。年末に大掃除するとき、慌てない家庭はこのルールをキチンと守っているのでしょう。あるいは夏休み宿題で苦労することはないでしょう。 継続的インテグレーションが完全に普及した今、コードを作成したらそれで終わりという文化もなくなりました。 コードのメンテナンスをしっかりすることで、バグの早期発見や仕様の理解もできるでしょう。 私も完全に出来ているわけではないので、今後も頑張りたいです。 プログラマが知るべき97のことについての記事はまた書くかもしれません。 そのときはよしなに。 .