はてなブックマークアプリ

サクサク読めて、
アプリ限定の機能も多数!

アプリで開く

はてなブックマーク

  • はてなブックマークって?
  • アプリ・拡張の紹介
  • ユーザー登録
  • ログイン
  • Hatena

はてなブックマーク

トップへ戻る

  • 総合
    • 人気
    • 新着
    • IT
    • 最新ガジェット
    • 自然科学
    • 経済・金融
    • おもしろ
    • マンガ
    • ゲーム
    • はてなブログ(総合)
  • 一般
    • 人気
    • 新着
    • 社会ニュース
    • 地域
    • 国際
    • 天気
    • グルメ
    • 映画・音楽
    • スポーツ
    • はてな匿名ダイアリー
    • はてなブログ(一般)
  • 世の中
    • 人気
    • 新着
    • 新型コロナウイルス
    • 働き方
    • 生き方
    • 地域
    • 医療・ヘルス
    • 教育
    • はてな匿名ダイアリー
    • はてなブログ(世の中)
  • 政治と経済
    • 人気
    • 新着
    • 政治
    • 経済・金融
    • 企業
    • 仕事・就職
    • マーケット
    • 国際
    • はてなブログ(政治と経済)
  • 暮らし
    • 人気
    • 新着
    • カルチャー・ライフスタイル
    • ファッション
    • 運動・エクササイズ
    • 結婚・子育て
    • 住まい
    • グルメ
    • 相続
    • はてなブログ(暮らし)
    • 掃除・整理整頓
    • 雑貨
    • 買ってよかったもの
    • 旅行
    • アウトドア
    • 趣味
  • 学び
    • 人気
    • 新着
    • 人文科学
    • 社会科学
    • 自然科学
    • 語学
    • ビジネス・経営学
    • デザイン
    • 法律
    • 本・書評
    • 将棋・囲碁
    • はてなブログ(学び)
  • テクノロジー
    • 人気
    • 新着
    • IT
    • セキュリティ技術
    • はてなブログ(テクノロジー)
    • AI・機械学習
    • プログラミング
    • エンジニア
  • おもしろ
    • 人気
    • 新着
    • まとめ
    • ネタ
    • おもしろ
    • これはすごい
    • かわいい
    • 雑学
    • 癒やし
    • はてなブログ(おもしろ)
  • エンタメ
    • 人気
    • 新着
    • スポーツ
    • 映画
    • 音楽
    • アイドル
    • 芸能
    • お笑い
    • サッカー
    • 話題の動画
    • はてなブログ(エンタメ)
  • アニメとゲーム
    • 人気
    • 新着
    • マンガ
    • Webマンガ
    • ゲーム
    • 任天堂
    • PlayStation
    • アニメ
    • バーチャルYouTuber
    • オタクカルチャー
    • はてなブログ(アニメとゲーム)
    • はてなブログ(ゲーム)
  • おすすめ

    セキュリティ

『note.com』

  • 人気
  • 新着
  • すべて
  • 毎日継続することに本当に意味があるのか|qsona

    40 users

    note.com/qsona

    12月から毎日noteを書いている。世間一般のアドベントカレンダーと体裁を合わせて、12月25日までは続けたいなと思っているところだ。 世間はアドベントカレンダーの季節ですが、久しぶりに物書きをやってみたくなったので、明日から25日間noteチャレンジしてみる。 以下は6年前に自分が書いた記事: Write note Every Day - noteを4週間毎日書き続けて分かった、「創作をはじめ、続ける」ことの難しさと楽しさ https://t.co/Sl7fW5yrg2 — qsona (@qsona) November 30, 2025 これは客観的に記事がイケてないと言っているのではなくて(そう言ってはfavしてくれた方にも失礼だと思う) あくまで自分の主観的にイマイチだったという話である。 「自分は面白くない仕事では本当にパフォーマンスを出せないが、面白いと感じる幅が広いからそれで

    • テクノロジー
    • 2025/12/16 00:31
    • 学習
    • あとで読む
    • 人生
    • 生成AIの成果物に責任を持ってくれ|qsona

      464 users

      note.com/qsona

      プログラマーの世界では昔から「お前がコピペしたコードはお前のコード」というならわしがある(多分)。つまり、たとえばコードレビューで他の人から指摘が入ったときに、「隣にある別のコードをコピペして作ったからそうなっている」というのは言い訳にならないということだ。ペーストした瞬間からそれは自分が責任をもつべきで、そのためにはそのコードを自分で理解して説明できる必要がある。ジュニアプログラマーはこういった意識が薄いことが多いが、レビューする側のプログラマーとしては、ジュニアプログラマーが責任を持った振る舞いをしてくれないと非常に疲弊するので、こういう哲学は早めに教え込むことが多い。 これに似た話として、最近、プログラミング以外の事例も含めて、生成AIに作らせたものを隅々まで自分で理解しない・説明できない (つまり責任を持てていない) ままそれを成果物として他人に見せるケースがあまりに多すぎるように

      • テクノロジー
      • 2025/08/17 19:59
      • AI
      • あとで読む
      • プログラミング
      • 仕事
      • 人工知能
      • 開発
      • programming
      • ChatGPT
      • LLM
      • プログラマ
      • Engineering Manager の自己効力感下がりがち問題|qsona

        205 users

        note.com/qsona

        Engineering Manager という仕事をしていると、自己効力感が低下する瞬間がけっこうあると感じる。(多分 Engineering に限らない Manager 一般の話も多いと思うけど、ここではその考察はしない) 仕事において自己効力感が高まる状態というのは、たいてい、自分が何か努力して、それによって目に見える成果が出ているときに生まれるのではないかと思う。ところが、Engineering Manager の仕事というのは基本的に、自分以外のみんなが成果を出せている状態をつくることで、それにより絶妙なズレが生まれると感じる。 Engineering Manager の仕事を例にあげると、個々人のサポートをしたり、チームがうまくいくサポートをしたり、チーム間のコミュニケーションラインを整えたり、チームのはざまに落ちてるタスクを拾ったり、必要な人を採用したり、ビジネスや経営から求め

        • テクノロジー
        • 2023/10/21 14:32
        • マネジメント
        • あとで読む
        • 開発
        • management
        • チーム
        • 組織
        • 仕事
        • EM
        • 考え方
        • スタディサプリの開発チームを離れました (リクルートを退職しました)|qsona

          3 users

          note.com/qsona

          いわゆる退職エントリです。2019年10月から3年9ヶ月在籍したスタディサプリの開発チームを離れることになりました。 自分は Quipper Limited 時代に入社し、途中でリクルートへと会社統合された後もずっとスタディサプリの開発にずっと関わっていました。そんなわけで「株式会社リクルートを退職しました」というタイトルがいまいちしっくりこなくて、中途半端なタイトルになりました。 次は決まっていて、また別の記事でお知らせします。(・・・って前回の退職記事のときも同じことを書いたままお知らせしてなかったことに今更気づいた) この3年9ヶ月、最高の仲間たちとともに仕事をすることができ、自分に足りていなかった経験をたくさんすることができました。既存のアーキテクチャに向き合って改善するプロジェクトから始まり、新規開発のプロジェクトでの初期技術設計・選定、アジャイルな開発の理解と実践、他チームとの

          • テクノロジー
          • 2023/07/16 21:22
          • Re: GraphQL Error、下から見るか?横から見るか?|qsona

            7 users

            note.com/qsona

            上記のトピックについてもう少し突っ込んだ議論をしたい。 背景: GraphQL におけるエラーの表現の手法Web API において、正常系以外の、例外(エラー)的な状況をレスポンスの情報に埋め込みたい場合、REST API では HTTP ステータスコードがよく用いられる。 一方、GraphQL API では、複数のリソースを同時に取得することが前提にあるので、「リソースXはエラーであるがリソースYは正常である」のように Partial Error の状況を表現したいことがままある。そのためステータスコードは不適であることが多い。 また、GraphQL の仕様として、返すデータのトップレベルに data と並列に errors を返すことが出来る。(手法aとする) { "errors": [ { "message": "forbidden", "path": ["x"] } ], "dat

            • テクノロジー
            • 2022/12/26 16:02
            • graphql
            • RESTful API との比較で GraphQL API を作ることの難しさ|qsona

              297 users

              note.com/qsona

              上の資料でも書いてるんですが、要点を言うと以下のようなことを主張している。 API の設計手法として、以下の2つのパターンが考えられる ・Resource-based API ・Usecase-based API Usecase-based というのは要はクライアントの要求にそのまま沿った形で API を作るということだ。しかし、UI やその他クライアントの要求というのは変わりやすいものなので、そのたびにいちいち API を変更しないといけないとか、API に一貫性がなくて使いにくいとか、1つの endpoint で多数の要求に対処する "神API" が作られてパフォーマンスが悪化する、というような問題が起こる。 したがって、注意深く RESTful API を設計すると Resource-based になる。ここで言っている Resource というのはテーブル設計にやや近いが、そのまま

              • テクノロジー
              • 2022/03/05 16:59
              • GraphQL
              • あとで読む
              • API
              • 設計
              • REST
              • RESTful
              • programming
              • 開発
              • architecture
              • BackendチームとFrontendチームとアジャイル|qsona

                7 users

                note.com/qsona

                話があんまりまとまってないけどとりあえず出す。 職能型組織とその弊害ある程度大きい Web プロダクト開発の現場 (例: エンジニアが全部で20人) において、その内部が Backend チーム / Web Frontend チーム / iOS チーム / Android チームみたいにサブチームとして分かれていることは実際よくあることだと思う。 アジャイル開発の文脈だと、基本的にこういう分け方はあまりよろしくないとされる。この分け方だと、それぞれのチームに閉じてユーザーストーリーを満たす開発ができない。そうすると、本番環境に機能を出してユーザーに使ってもらうには、複数のチームにまたがってタスクの優先度を合わせたり、複数のチームの成果物をつなぎこんだりする必要がある。そうするとチームをまたいだ調整が必要になり、チームの自律性が下がる。 そうではなくて、例えばフィーチャーごとにチームを作り、

                • テクノロジー
                • 2021/03/29 08:32
                • development
                • Schema-Driven Development とアジャイルなチーム|qsona

                  4 users

                  note.com/qsona

                  最近は新規サービス開発で GraphQL を使っている。同じチームでAndroidエンジニアの geckour 氏が記事を書いてくれていたので、触発されてちょっと書く。 上の記事の中で、この新規開発以前にあったAPI開発の問題点となぜSchema-drivenな開発にしたいのかについて触れられているので、ぜひそちらを見ていただきたいとして、僕が感じたschema-driven developmentの意外?な副次的効果について書いてみたい。簡単に書くと、各開発者が職能を超えてタスクを進める、アジャイル的な動きが広がったという効果があった。 前提として、僕らのチームは開発者が15人前後くらいいて、だいたい半分弱くらいが Web devs (backend + web frontend), 残りの半分強が Native devs (iOS / Android) となっている。一応webとnat

                  • テクノロジー
                  • 2020/07/24 21:44
                  • GraphQL
                  • development
                  • マイクロサービスを (Ruby on Rails 以外の任意の言語) で書くことについての意見|qsona

                    84 users

                    note.com/qsona

                    この文書は、ある組織において、ある一つの Ruby on Rails で書かれたサービスの全部または一部を、(言語A) で書き直したい、という proposal に対して qsona が表明した意見の文を、一部手直ししたものです。このサービスは、現在担当しているチームとは別の人が初期実装をしたものであり、現在はまだ小規模ですが、今後新しいチームの手により発展していくもので、現在の規模のうちに要件や新しいチームメンバーに最適な言語で書き直すという選択は十分合理的です。また、この組織内のコードは、Ruby on Rails で書かれているものが大半であり、さらに組織としてマイクロサービスアーキテクチャの方向を目指している、という前提の上でお読みいただければと思います。もちろん文責は qsona 個人にあり、qsona の属する組織の意見とは関係ありません。 ------------------

                    • テクノロジー
                    • 2020/07/24 15:23
                    • rails
                    • あとで読む
                    • ruby
                    • 開発
                    • 組織
                    • Pull Request レビューの限界|qsona

                      29 users

                      note.com/qsona

                      いくつか念頭にある過去の他の方の記事や発言があるのだが、パッと見つけられないのでゼロベースで書く。 Pull Request のレビューという文化がほぼ完全に定着してからかなり経った。5年前くらいはまだ「Pull Request のレビューを開発フローに入れています」みたいなことを採用ページの文言に入れている会社が結構あったが、今時もはや当たり前になりすぎて誰も言わなくなった。 それくらい Pull Request を出してそれをチームの人がレビューするというフローは当たり前になっているが、僕はそれにずっと疑問を感じている。はっきりいってしまえば、僕は多分平均的な人の30%程度にしか Pull Request レビューに対して意義を感じていない。チームとしてコードの品質を担保したり、コードを複数人で所有するといった目的において、 Pull Request レビューが果たすことができる割合は

                      • テクノロジー
                      • 2020/03/05 10:26
                      • 設計
                      • review
                      • development
                      • ウォーターサーバーの水を換えろ|qsona

                        30 users

                        note.com/qsona

                        職場でウォーターサーバーを使っていて、水が空っぽになっている。すぐ隣に替えの水があるとする。しかし、その一杯の水を飲むためだけに水を替えるのは面倒、割に合わないからやらない。 これは局所最適、囚人のジレンマの均衡解に陥っているような状況です。本来であれば、「ある分量の水を飲もうと思ったときに、その分量を出す前に水が空っぽになったら交換する」を全員が守っていれば、確率的には、自分の飲みたい分だけ交換の労力を割いているのと同じ役割を果たすことになり、全体最適になるわけです。 けれど、そういう状況を作り出すのは意外と難しかったり、コストがかかったりすることがある。 まず、ルールを作るのは意外と難しい。中には重たいものを持てない人もいるし、それを公表できない人もいるかもしれません。重たいものを持てない人は水を替えなくても、他のところで貢献してくれれば総合的には良かったりします。全員に同じ課題に同じ

                        • テクノロジー
                        • 2019/09/12 08:43
                        • サーバ
                        • development
                        • dev
                        • あとで読む
                        • culture
                        • 文化
                        • プログラマーとしての0x10代の振り返りと0x20代の展望|qsona

                          4 users

                          note.com/qsona

                          先日、0x20歳の誕生日を迎えました。めでたい。その直前には第3子となる次女も無事誕生して、めでたい続きです。良い機会なので、プログラマーとしての歩みを始めた0x10代 (2進数で10000〜11111歳) を振り返り、最後に0x20代の展望を記したいと思います。 0x10代の振り返りプログラミングとの出会い 10000歳は記念すべきプログラミングと出会った歳だったと記憶している。その前年からハマっていた「ぷよぷよ2ちゃんねる」のIRCチャンネル #puyo2ch で C言語の手ほどきを受けた記憶がある。きっかけはまるで思い出せない。かろうじてifやforを理解したレベルで終わった記憶がある。正直、プログラミングをやったとは言い難いレベルで終わった。 自分の書いたコードが他人に使われるという経験は、その翌年だったと思う。音ゲー関係のIRCチャンネルでCGIの人狼がかなり流行った。それを繰り

                          • テクノロジー
                          • 2019/09/05 12:06
                          • あとで読む
                          • 社内の人に軽々しく謝罪しないでほしい|qsona

                            357 users

                            note.com/qsona

                            たとえば、管理ツールのオペレーションのミスが起こった時に、再発を起こしたくないという理由で、どういう手順で起きたのか、管理ツールに問題があるなら改善したいから言って欲しいというようなことを伝える。 あるいは、期待したアウトプットと違った時に、せっかくやってくれたことはありがたいが、ズレがあったことを伝えて、その目的からすり合わせようとする。 のようなケースで、自分としては、相手を責めるつもりなど一切なくて、とはいえそう捉えられないようにその目的から伝える努力をしているつもりなのだけれども、 ご迷惑をお掛けして申し訳ありませんでした。以後このようなことがないよう徹底いたします。 みたいな反応をされてしまうと、それ以上の発展は望めないし、ああ僕はこの人を謝らせてしまったんだなとなり惨めな気持ちになる。 確かにこういうのは大概他の部署の方とのコミュニケーションだし、事前に信頼関係が出来ているわけ

                            • テクノロジー
                            • 2019/09/04 07:33
                            • コミュニケーション
                            • あとで読む
                            • communication
                            • 仕事
                            • work
                            • note
                            • ツール
                            • 社会
                            • 対戦ゲームに学ぶ、フレームワークの設計技法とAIのアルゴリズム入門 #builderscon tokyo 2019|qsona

                              64 users

                              note.com/qsona

                              builderscon tokyo 2019 にて、表題にて発表します(した)。スライドだけでは十分に情報を伝えられないため、この記事にて補足していきます。 登壇資料 指のゲームここ(heroku)で動かせます。本来は対戦ゲームですが、1人で両方動かす形です。Display GuideをONにすると、後退解析によって解析された結果を利用して、各Moveのwin/lose/drawが表示されます。 コードはこちら(GitHub: qsona/yubisen)にあります(かなり雑然としたコードでスイマセン)。boardgame.ioを利用しています。後退解析のコードはその中のanalysis.tsです。 ぷよぷよの名勝負紹介した対戦は ALF vs かめ 100本先取 (2010, 実況 Tom) です。劇的な結末を迎えます。ぷよぷよを知らない方も最後の方だけでもぜひ。 "天才の詰み"郷田真隆

                              • テクノロジー
                              • 2019/08/30 12:18
                              • ai
                              • あとで読む
                              • アルゴリズム
                              • 設計
                              • game
                              • 組織は話さないですよ|qsona

                                80 users

                                note.com/qsona

                                会社などの組織体というのは、二つの側面があると思う。一つはその中にいる生身の人間そのものであり、もう一つはその人間が複数いることによって起きる人間同士の相互作用だ。 スタートアップの企業のように人数が少ない時期は、単に個々の人の集まりとしての活動だったものが、だんだん大企業になってくるにしたがってその相互作用が大きくなってくる。だから、会社も少し大きくなってくると、良い文化の定着を図ろうとしたり、組織構造をつくりはじめたりする。 この二つのうち「相互作用」の方は、生身の人間自体に比べると、なかなか理解したり制御するのが難しい。 さて話を変えると、なにか問題が起きた時に、人は、よくわからない何かに原因をおしつけて思考停止してしまうということがままある気がする。たとえば、今の給料が低いのは政府の政策に原因がある、のようなものだ。もちろんそこのロジックを精度高く理解して言っているなら別だが、大抵

                                • 政治と経済
                                • 2019/08/18 11:04
                                • 組織
                                • communication
                                • 会社
                                • work
                                • 考え方
                                • 仕事
                                • business
                                • "クソコード"は人格攻撃ではないのか|qsona

                                  535 users

                                  note.com/qsona

                                  これは仮説というか自分がこうだという話なのだが、自分のアイデンティティを侵食されると怒りが湧く。たとえば、自分が非常に大事にしている価値観に対して、同僚から「君のその価値観は間違っている」と言われたり、あるいは、作品とか、経歴とか、家族とか、そういう自分自身と非常に密になっていて同一視されるようなものをけなされたら、腹が立つということだ。 プログラマーにとって、ソースコードというのは一つの作品だ。仮に経験が浅い開発者であっても、あるいは経験が浅いからこそ、1行1行に時間をかけて考えながら作りあげる。それに対してこれはクソコードだと言われたらどうだろうか。考えてみる。 よく、クソコードというのはコードがクソだと言っているのであって、お前がクソだと言ってるわけではないから切り離して考えるべきだという言説がある。僕はこれには微妙に賛同できない。その人が生み出したコードは、少なくともその人のいくぶ

                                  • テクノロジー
                                  • 2019/08/14 23:30
                                  • プログラマ
                                  • あとで読む
                                  • programming
                                  • コード
                                  • プログラミング
                                  • communication
                                  • 職業プログラマ
                                  • 人
                                  • コードレビュー
                                  • note
                                  • 140文字とコンテキスト|qsona

                                    3 users

                                    note.com/qsona

                                    レンタルさんの態度は一貫している。普段はとにかく気性穏やかで聡明な方という感じだ(そうでなければこのレンタルなんもしない業は務まらないと思うのだが)。ところが、第三者からの無責任な批判や、文脈が読めていないリプライ、いわゆるクソリプというやつには容赦なく厳しいことを言う。時には荒れたようなツイートをする(完全に狙ってやっているのだろうが)。 ちなみに元ツイはこれ。 私の過激な思いを聞いてほしいという依頼。昔からよく嫌がらせを受け、多くがブスによる可愛い私への嫉妬に感じるためブスやデブが嫌いとのこと。デブの上司に小言を言われた時も「やっかみでしょ」と思ってしまい、そんな自分も嫌だがそうさせたブスやデブがやはり嫌いだという。言えてすっきりしてた pic.twitter.com/SFYEjwqn15 — レンタルなんもしない人 (@morimotoshoji) August 11, 2019 冒

                                    • 暮らし
                                    • 2019/08/13 11:27
                                    • ソフトウェア設計の言語化スキルを磨くこと|qsona

                                      407 users

                                      note.com/qsona

                                      たとえば設計について議論するときや、コードレビューで指摘をするときに、「なぜその設計が良いと思うのか?」について言語化するのが上手だと、確実に良いことがあります。 言語化が上手にできるかが一つの壁なのではないか、と感じることもあります。後輩を育てたりチームをリードするような立場になると、特に必要性を感じるのではないかなと。 自分も、うまく言語化できたことですんなり議論を進められていると感じることは多いですし、逆に直感的な良さを言語化できなかったことで直感に反する方向に進んでしまい、結果よくなかったというような苦い経験もあります。 前提: ソフトウェア設計の良さは静的には決まらない良い設計・良いコードとは何なのか。という質問に一言で答えるなら、「保守性が高い」ことだと思います。つまり、今後の変更・拡張を、高速にバグが少なく行えるような状態が良い設計・良いコードです。(一般的にはこれで70%く

                                      • テクノロジー
                                      • 2019/07/13 14:01
                                      • 設計
                                      • あとで読む
                                      • ソフトウェア
                                      • programming
                                      • プログラミング
                                      • コードレビュー
                                      • 言語
                                      • design
                                      • スキル
                                      • development
                                      • 自分が上司との1on1でよく話している内容|qsona

                                        4 users

                                        note.com/qsona

                                        1on1がよくワークしていると感じるので、僕が1on1にどんなことを求めていて上司がどんなことをしてくれているかを書く。 コンテキスト自分は中途入社4年目で、現在SREチームに所属している。自分はもともとサーバサイドのアプリケーションのエンジニアなので、インフラよりの知識が少ない。上司はSREチームのリーダーで、インフラの経験が強いがサーバーサイドやクライアントサイドの開発経験もある。 1on1の頻度は2週に1回くらいで定期的にやっている。それ以外でもこちらから頼んだら時間さえあればすぐやってくれる。 1on1でよく話す内容(主に専門的な内容での) 相談 仕事に関する雑談、に近い。日々のSREの業務については1on1を待たずに普通に話すので、ここでやるのはどちらかというと中長期的なテーマで僕が課題に思っていることを話したりする(話の流れで上司の課題感が聞けることも多い)。課題といっても明確

                                        • テクノロジー
                                        • 2019/06/21 01:49
                                        • Microservices for Everyone - 2つの "why-microservices" を読んで|qsona

                                          79 users

                                          note.com/qsona

                                          どちらも大変素晴らしい記事で、大変よくまとまっていながら主張が入っていて読みごたえのある文だった。それに比べたら、以下の文はまとまりもない駄文だが、それでもどうしてもこの話題には物申したくなる自分がいる。知見と呼べるほどでもないけれど、3年間マイクロサービスのことを考え続けてきた者の率直な感想として、読んでいってもらえたら嬉しい。 tl;drこの記事を通して、僕が結局何が言いたいのかというと、マイクロサービスはもっと開かれたものであってほしいということだ。複数のビジネスをやるならマイクロサービスの考え方を導入する権利があるし、すでにマイクロサービスをやっているなら、マイクロサービスのことを考えるのは基盤チームだけじゃなくてみんなであるべきだ。 マイクロサービスは「やる」か「やらない」かではない前者のdeeeetさんの記事は、全くマイクロサービスを知らない人がぜひ読むべき、本当に良い記事だと

                                          • テクノロジー
                                          • 2019/05/23 11:01
                                          • microservices
                                          • あとで読む
                                          • 技術
                                          • 開発
                                          • ビジネス
                                          • DroidKaigi 2019 に参加した|qsona

                                            5 users

                                            note.com/qsona

                                            Androidのことはほぼ何もわからない状態でDroidKaigiに参加しました。とても楽しかったです。なので、なんで楽しかったのか考えてみた記事です。 おそらく(スポンサーブースの非エンジニアの方を除けば)会場で最もAndroidの知識が少ない人間が私だったかもしれません。なんでそんな状態でDroidKaigiに参加したかというと、"Server-side Kotlin for Frontend" というタイトルでのトークをしたからです。これは1日目のお昼すぎのセッションだったので、それ以降は解放感に満ち溢れながら他のセッションを聞きまわっていました。(自分のセッションについてはまた別記事で。) ほぼ全ての話が新鮮で、学びが多い当たり前ですが、知らないことだらけなので、何を聴いても新鮮です。 本当にAndroidの中のニッチなトークだと何もわからなずに終わるかもしれないのですが、(セッシ

                                            • テクノロジー
                                            • 2019/02/09 13:55
                                            • モバイルエンジニアのためのBFF入門 (1) 技術選定の軸|qsona

                                              43 users

                                              note.com/qsona

                                              とりあえず第一回として、iOS / Android のための BFF (Backends for Frontends) を作りたくなったときに、どういう技術で作るかを考えてみます。第二回があるかは未定。 そもそもBFFって何という方のために、手前味噌ですが自分の登壇資料をあげておきます。 言語とフレームワークの選定まず、いくつか観点を列挙する。 静的型付け or 動的型付け できれば静的型付けのが良いと思う。 iOS / Android が静的型付け言語を利用しているので、スイッチングコストが少ない。 あと、たぶんそんなに頑張ってテスト書かない(書くのが難しい)ので、極力型レベルでバグを検知したい。要はBackendのAPIをstubしないとテスト書けないんだけど、せっかくテストをしてもstubが間違ってると意味がないので、そこの(叩くAPIの型の)信頼性はどちらにしろ担保しなきゃいけない

                                              • テクノロジー
                                              • 2019/01/11 17:07
                                              • bff
                                              • あとで読む
                                              • api
                                              • ios
                                              • development
                                              • android

                                              このページはまだ
                                              ブックマークされていません

                                              このページを最初にブックマークしてみませんか?

                                              『note.com』の新着エントリーを見る

                                              キーボードショートカット一覧

                                              j次のブックマーク

                                              k前のブックマーク

                                              lあとで読む

                                              eコメント一覧を開く

                                              oページを開く

                                              はてなブックマーク

                                              • 総合
                                              • 一般
                                              • 世の中
                                              • 政治と経済
                                              • 暮らし
                                              • 学び
                                              • テクノロジー
                                              • エンタメ
                                              • アニメとゲーム
                                              • おもしろ
                                              • アプリ・拡張機能
                                              • 開発ブログ
                                              • ヘルプ
                                              • お問い合わせ
                                              • ガイドライン
                                              • 利用規約
                                              • プライバシーポリシー
                                              • 利用者情報の外部送信について
                                              • ガイドライン
                                              • 利用規約
                                              • プライバシーポリシー
                                              • 利用者情報の外部送信について

                                              公式Twitter

                                              • 公式アカウント
                                              • ホットエントリー

                                              はてなのサービス

                                              • はてなブログ
                                              • はてなブログPro
                                              • 人力検索はてな
                                              • はてなブログ タグ
                                              • はてなニュース
                                              • ソレドコ
                                              • App Storeからダウンロード
                                              • Google Playで手に入れよう
                                              Copyright © 2005-2026 Hatena. All Rights Reserved.
                                              設定を変更しましたx