のんラボ

Pixel 5を買いました！

2020/10/17 2020/10/17

Pixel 5を買いました！こんにちは。Nonです。久しぶりの記事になります。今回はPixel 5を購入したので、そのレビュー記事になります。 Pixel 5を購入する前はPixel 3aをユーザーだったので、その比較もできたらしていきたいです。外観筐体はガラス製から樹脂（？）製へ。私、手汗を結構かくので、Pixel 3のときは手汗で指紋がついたり、少しベタついたりしていましたが、この筐体だとサラサラのまま使用できます。大きさは男の手のひらでこのくらい。 Pixel 3aとほぼ変わらず、気持ち小さくなった感じもします。（マットなブラックでかっこいい）ケース【Spigen】 Google Pixel 5 ケース TPU 米軍MIL規格取得耐衝撃衝撃吸収ラギッド・アーマー (マット・ブラック) ケースはこちらを購入。 Pixel 3を盛大に落として画面バキバキにした経験が忘れられなくて、本当はケースが大嫌いですが、購入してみました。バイクにも利用するので一応、耐衝撃ケースです。装着時はこちら。表裏カメラの出っ張りが気になる人は気になるはず。私は気になる人でした。しかしケースをつければちょうどいい感じでカメラも保護してくれます。ただし、その分厚みも増しましたね。こちらは慣れでしょうか？機能 Qi 機能面についてはただ一点！Qi充電機能しか目当てにしてませんでした！！こちらはAirPods Proです。光ってるのがわかるように、スマホからの充電が可能になっています！地味に便利かも。（今後にも期待。）こちらはQi充電用のスタンドを購入しました。スタンドはこちら。 Anker PowerWave 10 Stand(改善版), ワイヤレス充電器 Qi 認証 iPhone 11 / 11 Pro / 11 Pro Max/XS/XS Max/XR/X / 8 / 8 Plus Galaxy LG 対応 5W & 7.5W & 10W 出力ブラック AirPods ProのQi充電機能に気づいてなかったので、スタンド型固定のものを購入しました。こんなことだったら変形するタイプを購入すればよかった... くそぅ... バックキー実は完全ベゼルレスのスマホを使うのは初めてで、バックキーを前提にこれまでスマホを利用していました。しかしPixel 5はホームキーがiPhoneのようになっています。当然それに従ってバックキーもなくなってしまいました。 (バックキー魅力的だったのになー。せめて選択できればいいんだけど) バックキーが表示されるときもありますが、ある時とない時があるので、ないのも同義ですね。こちらも少しずつ慣れていくしかありません。 5G 契約は4Gです！！ｗ 5Gどこの契約しようかな。その他完全にAmazonのオススメに釣られましたが、ガラスカバーを画面用とカメラ用を購入しました。カバー嫌い派だったんですが、これはいいものですね。ガラス製のカバーとかあるの知りませんでした。最後に今回はPixel 5のレビュー記事でした。 5Gのパワーはまだ感じることはできませんが、Pixel 5のQi充電だけでもかなりいいものです！Google Homeの代わりにしたり、音楽プレイヤー的にしたり、色々使い道は多そう！あとはモバイル充電ですね。旅行先でThunderboltのコードはもう必要はないですね。今回はこれまでにしておきましょう。スマレコの進捗がありそうなので、次はその記事になりそうです。その時はよしなに。 .

スマレジでスマレジ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を使用して自分だけのレジを作るなんてことも可能です。データは２万店舗分なのでかなりのデータを提供することになります。無料でこれだけのデータを触れるのはすごいかも？で、私は何を作っているかというと... 個人開発ですので、大した機能のものは作れませんが、会員の購入した商品から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を主に使っています。バーコード決済はなんか無理です。リモートワークが本格的に始まった幸か不幸かコロナの影響で、弊社にもリモートワークが普及し始めました。業種が業種でしたので、仕事の仕方がガラッと変わったわけでもなく、多少のリモート用設定さえすれば全てがうまくいく感じですすめることができました。しかし、問題は違うところにありました。それは私の部屋が仕事に適していないということでした。いや、日常を過ごすだけなら十分な環境なんですが、仕事（８時間近く椅子に腰掛ける）環境としては微妙な感じでした。もともとガジェット好きでしたので、必要なツールを以外と揃っているのですが、いかんせん「机」と「椅子」、そして「ケーブルの管理」がもう全然駄目でした。まぁでもすぐにコロナも収束するだろうと思って特になんの対策も立てずにいたところ、デザイナーの方におすすめされた記事を読んで考えが変わり、お金はかかりますが、色々と揃えるようになりました。そしてその記事がこちらです。 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です。今回は３月くらいから始まったリモートワークについて少し話をしようと思います。前々から働く場所に執着が無いタイプでしたので、リモートワークを一度くらいはしてみたいと思っていました。幸か不幸かコロナの騒動の影響でリモートワークが本格的にスタートしました。ちなみに、今回の騒動でリモートワークをするのは初めてです。具体的にどういう働き方になったか？ぶっちゃけあまり変わってない！いや、変わってますよ？流石に。でも眼を見張るほど、「おぉ〜っ！」ってなるほど変わってないです。リモートワークになる前からチャットツールは頻繁に使われていますし、口頭でのコミュニケーションよりも、チャットやドキュメントでのやり取りが多い職場ですので、リモートワークになってもあまり変わらない印象。すこし変わったのは、内線電話が結構かかってきていたところが全てチャットになったというところでしょうか？非常に助かりますね。チャットツールに機能を求めるようになってきた G Suiteを採用しているので、Google chatを利用しているのですが、やっぱりSlackほど便利ではありません。（といっても私はSlack使い倒しているわけではないので、そこまで違いがわからないのですが）ただ、他のチームはSlack（無料版）などを利用しているところもあるようです。ちなみに私は個人プレイが多いのでチャットをあまり利用しません。通勤しなくていい！！いやぁ、これは本当に大きいですね。私の趣味がツーリングなので、都会に住まいを構えていないのです。ツーリング行くときに便利な「駅から少し遠い」「高速沿い」の「少し安めで広いところ」を借りてますので、普段の通勤に大体60分くらいかけてました。往復で2時間ですね。これがなくなったのは本当に大きいです。ご飯をあまり食べなくなった勤務地がオフィス街なので、職場の周りにはたくさんの飲食店が並んでいるのですが、私の住まいの周りにはそれが全然ありません。自炊かコンビニかなので、もう面倒臭くて昼ごはん抜いちゃうことがあります。これなんとかしたいんですよねー。リモートになって良くなったことみんなちゃんと考えてからアクションを起こすようになったこれは私もそうなったと思います。これまでは、わからないことがあれば、とりあえず直接聞いてみようみたいなところがありましたが、それが消えました。チャットのためにタイピングするのが面倒くさい、電話 / ビデオ通話するのが面倒臭いみたいなところができたからでしょうか？自分の時間が増えた通勤が無くなって、自分の時間が増えました。なので、余った時間で勉強したり、自分のためのアプリ開発をしてます。軽視されがちですが、これ会社としたら非常に大きいと思いますよ。通勤や残業の強制（という空気感）があると、やっぱり自分の時間をくれる会社とそうでない会社っていう印象を与えてしまいますから、いい人材ほど外にいってしまいます。リモートになって悪くなったこと無いと思います強いてあげるなら、何か（技術的な / アイデア的な）閃きのトリガーが減った。くらいでしょうか？雑談はとても効果があるんだなと思いました。今後も続けたいか？頻度は？続けたいですね。少なくとも、プログラマーという職種の上ではメリットの方が明らかに多いです。しかし、フルリモートは駄目だと思います。やっぱり顔を合わせる時間は必要に思います。その頻度は週１くらいでいいのではないでしょうか？その週1の出勤はコミュニケーション重視の勤務で、一週間に一回しか無いからこそ、大事なMTGになるのではないでしょうか？最後に今回は半年リモートワークをしてきたので、その感想を書いてみました。中にはリモートワークできない業種もあるかもしれませんが、必要に応じて導入していきたいですよね。せっかく世界が便利になっているのに、便利になった（効率が良くなった）のだからもっと働け！ってのは少し違う気がします。次の記事はリモートワークするにあたって自分のデスク周りを少し改造してみた話ができたらなと思います。その時はよしなに。 .

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

2020/08/16 2020/08/16

スマレジ・デベロッパーズのstorybookを作成してみて７月半ばくらいから、スマレジ・デベロッパーズで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. 既存のプロダクトに導入するコストはやっぱりある程度あるすでに画面レイアウトが完成仕切ってるプロダクトに改めて導入するにはコストが発生します。もちろん導入することでボタンの変更を一括で管理できるようになったりするのは便利ですが、すでにリリースされている画面のコンポーネントをすべて揃えるまでかなりの時間を要するでしょう。スマレジ・デベロッパーズは一般公開してまだ１ヶ月ですが、すでにしんどい面があります。特にこのプロダクトはオフショア開発で画面によっては全く違う実装をされていた経緯があるので。今後どうしていきたいのか 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. リリースを小さくしたらマネジメントしやすくなった１と同様に、関心事が減るので、把握すべき進捗の内容が減りました。おかげで今までおざなりになっていたプロジェクトの進捗の把握もかなりしっかりできて、ほぼ計画どおりのプロセスを踏むことができました。（この案件では私が実装兼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()の方がいいでしょう。このように、業務知識内の言葉を利用することで、プログラムコードと実際にミーティングなどで利用される言葉の乖離を防ぐことで、ユースケースの齟齬、つまりユーザーとの誤解を避けるために作成され、使用する言葉のことを指します。プログラムコードに仕様を書き込むとは？こちらもしばしば見かける内容です。仕様書を作成しないという意味ではありませんが、できるだけプログラムコードに仕様を反映するということは結構前から言われていたように思います。キーワードは私の知る限り３点。ビジネスロジック抽象クラスユビキタス言語でしょうか。ビジネスロジックで仕様をコードに表すビジネスロジックで仕様をコードに表すとは何か？２０２０年に突入した今なら、すでにご存知の方もたくさんいらっしゃるでしょう。私はこれまで色々なプロジェクトを経験してきましたが、とにかく、コントローラーだけで実装を終了していたり、プログラムコードの示す目的がコードに反映されていないコードをたくさん見ました。だから、「コードの仕様を先輩に聞いたり」、「なぜ、このコードが必要なのかを議論する」必要があったのです。試しに例を作成してみました。 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のことを読んで記事にしようかなと思っています。その時はよしなに。 .