わくてか 👈 サービスつくる人

個人開発してます。エンジニア無料のコワーキングカフェ(&バー)を運営してます:…

わくてか 👈 サービスつくる人

個人開発してます。エンジニア無料のコワーキングカフェ(&バー)を運営してます:http://wktq.me/hackable よくつかう技術:Next.js / Prisma / React Native(Expo) / Rails

マガジン

最近の記事

「レガシーコードからの脱却」を読んだのでまとめ②(レガシーコード危機~プラクティス4 - 協力し合う - まで)

第3章はアジャイル開発と言うものの最近の情勢に関わることが書かれており、ある意味で文学的なものなので、実際に文字で読んで感覚的に感じたものを自分の中に残しておくことにした。 第4章 この章から実際にプラクティスに入る。序文では、今のソフトウェア業界はまだ歴史が浅く、例えるなら数百年前の医学界(むかし岡田斗司夫ゼミで医者は魔女と呼ばれていたと聞いたことがあるが、細菌学さえもなく、その混沌とした雰囲気は何となく感じられる)のようなものだと言っている。 細菌学のない世界において

    • 「レガシーコードからの脱却」を読んだのでまとめ③(プラクティス5 - CLEANコードを作る~最後まで)

      5. CLEANコードを作る計測可能なコード品質を保つためのアプローチとして、「CLEAN」コードを紹介している。 C: Cohesive / L: Loosely-coupled / E: Encapsulated / A: Assertive / N: Nonredundant ※ Loosely-coupledはそのまま弱連結の意。Encapsulatedはカプセル化と訳されているが、正確にはカプセル化された状態を指すはず。EとNは接頭辞で覚えにくいので、意識して覚

      • 「レガシーコードからの脱却」を読んだのでまとめ①(序文〜レガシーコード危機)

        最初のレガシーコード危機(P35まで)については、開発者よりもディレクターやクライアント(予算管理者)に読んで欲しい内容だった。 これで事前知識の共有ができれば、保守性を高めるために時間をかけることに躊躇がなくなるし、クライアントとのコミュニケーションで齟齬が生じても、この本を引用すれば、分かってくれる範囲が大きくなりそう(よっぽどバカじゃなければ)。 以下ソフトウェア業界のプロジェクト分析データで面白かった数字。 80%の開発コストが「障害の特定と修正」にかかっている

        • 三体を読んだ感想

          先輩エンジニアの方に教えてもらい、三体という小説を読んだ。 もし僕が古典物理学の限界や複雑系の話のことを知り始めた5~6年前に読んでたら、さらに衝撃的だったかもしれない。単行本が出たのが2008年だから、約10年前。当時では特にホットな話題だったと思う。 今見ると少し既知の議論がテーマになっているけど、ちょっと知らないフリをして少し昔の感覚で読むとすごく楽しかった。 ひとことでいうとテーマは現代物理学・現代科学で、現代的な構成とアニメっぽい演出で読みやすい。 具体的に

        「レガシーコードからの脱却」を読んだのでまとめ②(レガシーコード危機~プラクティス4 - 協力し合う - まで)

        マガジン

        • 3Dプリント
          1本
        • 音楽マーケティング
          1本

        記事

          1万時間理論よりも2,000時間理論 - 仕事ができるまでに必要な訓練時間

          1万時間理論と掛け合わせ理論マルコム・グラッドウェルが著書『Outliers』のなかで提唱した1万時間理論。ある分野で世界の一流になるためには、10,000時間練習することが必要だという話です。 これに対して日本では、堀江隆文さんや藤原和博などの著書で、いろいろな才能の掛け合わせによって100万人に一人の逸材になれる、と言うような話をもあります。 僕はこの両論ともに極端だと思っていて、そもそもグローバル化してパイが大きくなる世界で、しかも様々な情報に触れられるのにもかかわ

          1万時間理論よりも2,000時間理論 - 仕事ができるまでに必要な訓練時間

          6curryの記事をみた感想

          開発者として、コミュニティ関連のプロジェクトに関わるに当たって、顧客と従業員の越境・融解・共創が真のCXとなる時代へ-6curry CX-DIVE2019レポート | 後編をみた個人的なまとめ・感想。 勉強になった部分やることが明確:「カレーを作る」コミュニティ ルールの公開:初めて参加する人はルールがわからない 空気をつくる:顧客と会員の分け目をなくす プラットフォームの共創:継続的なコミット感の演出 住所が非公開:会員同士で秘密を共有する やることが明確公式サイトより

          LINEのbotでメッセージを送受信するまでの実装の流れ(Rails+Messaging API)

          今回は作成したLINEのbotでのユーザーのUID取得、メッセージの送信、メッセージの受信をするまでの流れをまとめてみた。 実装の流れ1. LINEデベロッパーコンソールでプロバイダー・チャネルなどを作成 2. Webhookで友達追加時にUIDを取得 3. 取得したUIDでメッセージを送信 4. Webhookでメッセージを受信して保存 LINEデベロッパーコンソールでの作業以下よりアカウントを作成。 次にプロバイダー(これは一つのアプリ等につき一つのプロバイダー)を

          LINEのbotでメッセージを送受信するまでの実装の流れ(Rails+Messaging API)

          LINE Messaging APIを使ってみた(ログイン連携・Flex Message)

          受託案件でLINEのMessaging APIを使ってみたら、思ったよりもいろいろなことができた話。 ※この記事はmediumより移行しました) LINE Messaging APIでできることクローズであんまり機能がないイメージだったけど、使ってみると以下のようなことができた。 ・特殊なレイアウトのメッセージ(flexメッセージ) ・特定ユーザーとのメッセージ送受信 ・LINEログイン共通のユーザーUID ・ユーザーごとのカスタムリッチメニュー 特殊なレイアウトのメ

          LINE Messaging APIを使ってみた(ログイン連携・Flex Message)