logこの広告は、90日以上更新していないブログに表示しています。今後自分はどうするべきかみたいな悩み、多分答えはでないような気がしている。この話は変化するものだと思っているから。以前は〇〇するべき、と考えがちだったサバイバル規則に選択肢を与える、その変換がうまくいくようになってきている感じもしている。転んでも最終的には自分でけつをもつ、ただ、まぁなんとかなるさくらいの気持ちの持ちようで、肩の力を抜いてやっていきたい。今は魅力と感じるミッションを持った会社さんで、その実現に向けて切磋琢磨するチームメンバと働けていて本当に幸せである。早く貢献できるようにがんばりたい(風邪を治したい)。広告を非表示にするもっと読むコメントを書く2018-10-11戦略Netflixの本を読んだ。実例という点もあって読みやすく、一気に読むことができた。感じたことは一貫したストーリーの大事さとそれを実現するために必要な仕組みづくりという点。ビジネス上掲げる勝ち戦略があり、サービス、技術、採用を含めた戦術を思考し実行へ移す。決めただけで物事がスムーズに進むことはなく、明文化から、コミュニケーションの設計(権限委譲含む)、小さく継続的に行う仕組みも大事になってくる。目標を合わせることの重要性についてはピープルウェアでも同じようなことが書いてあった気がする。実現するにあたってここまで振り切った意思決定を行える企業はそうないだろうと感じた、特に人事にいたっては。日々の課題は尽きないし、できることも少ない。根から考え優先順位の決定を行っていく。課題が起きると目がそこにだけ向きがちになる、時に一歩引いて全体を俯瞰してみることを忘れないようにしたい。最近またイベントの開催を始めている。以前までconnpassさんを利用させて頂いたけど、ドッグフーディングがてら自分のサイトで告知と募集を行っている。メンテらしいメンテをしていなかったので、諸所忘れている部分が多い。告知場所が今は自分のSNS中心になっているけど、町の掲示板に貼ったりとか、身近な人が気軽に参加できるような場所になればいいなとも思っている。開催場所は武蔵小山にあるスクエア荏原という施設で品川区民の人は少し安く借りれる。平日の仕事終わりだとあまり時間とれないけど、定期的に時間をとってコツコツやっていきたい。event.makewith.jp夜飯だけでも一緒にとかでも全然構わないので、お時間があれば是非。広告を非表示にするもっと読むコメントを書く2018-07-16結局人であるどんな仕組みであれ、どんな機能であれ、どんな技術であれ、最終的には人が利用する。いった考慮もなく進めるときっとうまくいかないんじゃないかなと思っている。08:42結局人である広告を非表示にするもっと読むコメントを書く2018-05-19文書ツール機能を実装する前に課題とか解決案とか整理する時にGoogleドキュメントがすごく整理しやすいなぁと思うようになった。箇条書きしていって、各センテンスで深掘りしていくときのタブ、多分ここが使いやすさにつながっているような気もしている。最初はまだ整理が出来ていなくてネストが深くなりがちになるから、ページ設定から用紙サイズをA3とかにしておく。見出しがあったら抜き出して再整理のループという感じ。文書がどう表示されるか頭のなかで考えたりとか、プレビューを押しての確認とかがとにかくめんどくさい。年のせいかもしれない。qiita.comWebアプリケーションのフレームワーク上で小さくコードを保つ指針的なものを自分へのメモとして記載した。昨今の横文字は一旦忘れる、問題は大体そこじゃない。コードの歪みは仕様の歪み要望は要望であって鵜呑みにすると痛い目に合う。考えられていない前提を持つ。仕様とコードの依存関係は密であって、コードが複雑化しているのは仕様だったというケースがある。仕様を精査する過程で、代替となる機能を発見できたり、そもそも作らないという選択が出来ることもある。実装前にまずは精神を落ち着かせて、仕様に向き合うこと。何かしらの要因で向き合うことが出来ていない状態であれば、根本の課題を探り、その解決に向けて動く必要がある。「ガハハハ」オブジェクトに対して話しかけるメッセージングが不自然になってないかを考える。実装しようとしてるパブリックのメソッドが既存にあるオブジェクトにあると違和感を感じたり、他に適切なオブジェクトが閃いたら、積極的に新規でクラスを作っていくのも手の一つ。メソッド名が長くなってしまったり、適切な名前が浮かばなかった時は、そのクラスの責務ではない信号かもしれない。請求書の封筒に貼るラベルをPDFとして一括ダウンロードする機能があったとする。}}既存のコントローラーやモデルに書く形でも勿論問題ないが、これ以上太らせちゃいけないものもある。コントローラーやモデルとなるクラスを新規に抽出していくことで、既存クラスに影響を与えず、小さい責務のクラスを作っていくことが出来る。大体後から追加仕様が入ってくることを念頭におく。上記モデルの実装例だと、二つのオブジェクトへ依存していることが分かる。追加の要件で封筒に入れる送付状も合わせPDF出力したいという要望があった場合、どう実装していくべきか。その送付状へ記載する内容は別のオブジェクトが必要だと仮定する。}}既存コードを流用すると上記のようなコードを書いてしまいそうだ。オブジェクトの依存関係に着目する。送付状という別のモデルを抽出して、送付状に必要なデータ取得のメソッドを生やす形か、そもそも分割を行ったクラスが誤った依存関係を生み出してしまってないかを検討する。請求書のモデルに対して、ラベル取得、送付状取得のメソッドを生やし、オブジェクトのリレーションを辿る方法もある。難しく考え過ぎていると感じたら、既存にあるオブジェクトでその責務を果たせないかも検討する。その他念頭に置くこと歴史を振り返る。チームの状態はどうだろうか?他に優先して潰すべき課題はないだろうか?技術だけで解決できない問題があることを知る。やりすぎると大体失敗する。小さく積み上げることを意識する。時にはスピードも意識する。最低限守るべき事項をチームで明示化し、厳守する。機能の改修でリファクタリングの必要性を感じた時は、しない形でまずは実装を行う。実装後に、リファクタリングのブランチを切って、積み上げる。大体深みにはまってしまうからである。既存コードがさっぱり分からない時は、捨てるという選択肢を視野にいれる。一から作り直す方がコストが小さく済む場合もある。フレームワークのレールから外れることを検討したとき、その役割を明確にし、チームで共通の認識を持つことが必須である。説明機会から、クラス設計・コードへのレビューコストをかける、また、今そこにいない仲間の受け入れがすぐ可能な状態にすることも必要である。その前提を受け入れて、本当に導入すべきか、今一度考え直す必要がある。#1」を開催しましたkaizen.connpass.com今まさに取り組んでいる事項です。参加者同士で対話を行う時間を入れて開催を行いました。#1」という名前を検討していましたが言語に特定される話でもなく、特定したことでコミュニティに依存し参加者が偏るのを防ぎたかったため、PHPというキーワードを外しました。コード改善は継続して行っていくもの、銀の弾丸はないと思っています。記載した通り、本会を継続して行っていく所存です。発表した内容について前段はこれまでの経験による振り返り、そして、先月からお手伝いを始めた企業での取り組みを最後へ簡単に紹介しました。これまでの背景や結果をフィードバックせずに、改善を進めてもきっとうまくいきませんし課題に対して主体的に動けていない状況であれば、そこにもまた何か別の問題があると考えます。何かしら変化を起こすことができると信じています。終わってみて最初は正直どうなるか不安でしたが、意見交換が非常に活発で率直に本当にやってよかったと思える会となりました。さんに内容をまとめて頂いて、本当に感謝です。(次回はメモ取る係が必要ですね...)hamuhamu.hatenablog.jpなどの感想も頂いて、本当に嬉しい限りです。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。