こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXkRead less

面倒臭いオブジェクト詰め替え オニオンアーキテクチャ、クリーンアーキテクチャなどの階層化されたアーキテクチャを使用する際、レイヤーの境界でオブジェクトの値を詰め替える必要性が発生します。 オブジェクトを詰め替えることでレイヤーの依存関係を断ち切り、一度書いた後の保守性を高めることに大きく貢献するのですが、筆者の観測範囲では単調作業に感じるせいかかなり嫌われる傾向があるように感じます。 そして、そのような詰替を嫌うばかりにオブジェクト詰め替えをやめてしまうこともありますが、それは非常にもったいないことです！！ なぜなら、「初期実装の数分の重要性 <<<< その後の保守性の重要性」だからです。 なので、できればきちんと詰め替えしてレイヤーの依存関係を保って欲しい、ということで、そのために詰め替えが超簡単にできる方法をご紹介します。 まずはデモご覧ください。 class Entity( val

現場に戻ることを決めたのはエンジニアとしての自信を取り戻すため ――まずは現在のお仕事について教えてください。 今は経営管理クラウド「Loglass」を提供する株式会社ログラスでソフトウェアエンジニアとして機能開発をしています。ログラスではフロントエンドもサーバーサイドも関係なく、全員がフルスタックで開発しています。それぞれ得意な分野とそうでない分野はありつつ、クロスファンクショナルなチームでスケールさせたいと思っています。ここから組織を大きくしていくために、採用や制度設計など、開発以外の議論にも積極的に入りながら働いています。 株式会社ログラス ソフトウェアエンジニア 飯田意己氏 ――ログラスには2020年10月にジョインされたと伺いました。その前はクラウドワークスで執行役員をされていたそうですね。 はい。クラウドワークスには、もともと現場のエンジニアとして入社して、新規事業の立ち上げに

山型なスキルをもったメンバーがあつまる山型クロスファンクショナルチームを作りデリバリスピードを安定させるというテーマのスライドです。 XP祭り2021での発表資料です。 山型クロスファンクショナルチームは造語ですが、定義としては「スペシャリティをもちつつ周辺分野でも基本的な価値を発揮できるメンバーが集まるチーム」としています。 Spotifyのスクワッドなどに代表されるクロスファンクショナルチームが良いとされているのは昨今では定説となりつつあります。 本スライドではそこからさらに踏み込んで、山型なスキルを持ったメンバーでクロスファンクショナルチームを構成するとどのような効用を得られるか、またそのようなチームはどう作るべきかというところを説明していきます。

採用（あるいは、仲間集め）の課題は尽きないもの。組織の規模感ごとに悩みもさまざま起きますが、中でも「初期フェーズ」においては、その後のカルチャーや成長角度も占う大切な時期です。SaaSスタートアップであれば必須の「開発環境」を整備するために、各社頭をひねっています。 CFOや経営企画向けのプランニング・クラウド「Loglass」を開発・提供するログラスでは、CTOの坂本龍太さんが採用にも強くコミットし、成長を支えます。 創業して2年2ヶ月あまりで、正社員は内定者を含め19名、副業人材も合わせると40名を超える規模に拡大。そのうち、エンジニアは正社員9名、合計で20名以上を占めるといいます。さらに正社員エンジニアは7名がリファラル採用で加入しました。 坂本さんはビズリーチで「初の新卒社員」としてキャリアを始め、SaaSビジネスを経験。「将来、自分が起業するならSaaS事業だ」という思いを胸に

Tebiki 社の CTO をしている渋谷です（会社名が変わりました）。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は「スタートアップでも AeyeScan を使えば、継続的に脆弱性を診断できるようになるよ」という話について書いてみたいと思います。 （※近年特に注目されている SaaS などの Web アプリケーションに対する脆弱性診断の話です） スタートアップでもセキュリティは最重要スタートアップではとにかくサービスの PMF を目指すことを優先すべきで多少の脆弱性は後でどうにかすればよい、という意見をたまに見かけます。BtoB 向けの SaaS スタートアップを3年間やってきた一人としては、それは全くの嘘で、やはりセキュリティが最も重要だと考えています。 なぜなら「情報漏えいは会社の倒産リスクに直結する」からです。 仮に脆弱性を突かれて情報が

4月に発売した書籍「Kotlin サーバーサイドプログラミング実践開発」なのですが、この中で途中まで作っていてボツネタにした内容がありました。 gihyo.jp それが「Gradleのマルチプロジェクトでオニオンアーキテクチャを実現する」というものです。 第2部で作成していたbook-managerというアプリケーションは、もともとこれを使って作成していましたが、途中でやめて現在の形になりました。 github.com ボツネタにした理由としては、一回実践で導入してみていくつか微妙な点があったことと、紙面上の説明が複雑になるのでベーシックな内容としては外していいかなと思ったためです。 ただせっかく途中まで作っていたので、試して微妙と感じた点も含めて、今回紹介したいと思います。 サンプルとしてこのbook-managerの内容をマルチプロジェクト化したアプリケーションを使い、オニオンアーキテ

【結論】 5ヶ月かけて無事完了しました。あー長かった。 新規の機能開発を止めないために一般的な開発チームでは今回のようなフロントエンドのフルリプレイスで一部新規の機能開発を止めながら開発を行うことがあると思います。 コードフリーズとなど呼ばれているものですね。 しかしログラスのようなスタートアップではプロダクトを絶えず進化させていくことがとても重要です。 機能開発を止めてしまえばたちまち大きな開発チームをもつ競合に追い抜かれて会社が負けてしまいます。 本記事ではフロントエンドフルリプレイスを新規機能開発を止めずに走らせる方法を解説していきます。 リプレイス概要本題に入る前に今回リプレイス対象となったLoglassについてとプロジェクトの概要について説明します。 【Loglassについて】 「プランニングクラウド Loglass」はBtoB SaaSのサービスの一つです。 基本はSSGやSS

リーダブルコード by DDD モデリングを起点に可読性の高いコードを実現する

こんにちは、Development Teamの三宅です。 先日、社内（AI事業本部内）でSQL研修の講師を担当したので、今回はその内容について簡単に共有したいと思います。 はじめに 例年、AI事業本部では、新卒エンジニアの育成のためにソフトウェアエンジニア研修を行っております。今年はフルリモートでの実施となりました。研修期間は2週間ほどで、内容は前半が講義、後半が実践（チーム開発）でした。私が担当したのは、講義パートの一部であるSQL研修です。SQLやRDBにあまり慣れていない人でも、できるだけ体系的な学びが得られるようにすることを目標に、様々な資料をまとめて提供する方針で準備しました。結果的には、ハンズオン込みで4時間ほどのやや長い講義となりましたが、勉強になったという声も頂けたのでやって良かったと思っています。 研修資料 研修内容 SQL研修の内容は、基本的には大学のデータベース講義で

3年前、世間一般にはメーカー系SIerとして知られている会社を退職した。ただ俺のポジションはパッケージソフト開発であり純粋なSIerとは異なる。 客ともSEとも会話せず、ひたすらドキュメントとプログラムを書く部署だ。といっても別にペーペーではなく主任クラスであり、 会社の業績がとてもよかったこともあり年収は1000万弱はあった。35歳。 これだけ見るととてもいい待遇に見えるだろう。でも耐えられないことがいっぱいあった。 Linuxで動くアプリなのにVMを動かすのも苦労する8GBしかメモリのないWindows PC、紙にコードを印刷して説明しないと納得しない品質保証部、 手作業で実施しExcelにチェックを付けていくテスト、jquery一つ使うのに3ヶ月かかる承認フロー、開発中にバグを一つ出すごとに ひたすら反省文を求める品質保証部と一緒になって詰めてくるマネージャー、常にコンパイルできない

Google Cloud Day: Digital ’21 の発表資料です。 https://cloudonair.withgoogle.com/events/platinum_primenumber?talk=sessionvideo ---------------------------------------------------------------------------------------------------- データドリブンに事業を推進するメルカリグループのデータ分析基盤を紹介します。 BigQuery とマネージド ETL & ワークフローサービス trocco® の活用で、Google Cloud 領域外の新規データ連携毎に発生するフルスクラッチ開発から脱却し、希少なデータエンジニア工数を創出。決済データと紐づけた営業活動分析にも成功しています。 分析基盤構成

PostgreSQLの行レベルセキュリティと SpringAOPでマルチテナントの ユーザー間情報漏洩を防止する (JJUG CCC 2021 Spring) Webアプリケーションにおいて、マルチテナント型、つまり複数のユーザー組織がアプリケーションとデータベースを共有する構成にすることがあります。この構成の持つリスクとして、万が一バグにより他テナントの情報が見えてしまうとそれは情報漏洩となり、重大なインシデントとなってしまうことがあります。この重要性を考えると、「気を付けて実装する」だけではなく、仕組みで漏洩を防ぐような対策には価値があります。 そこで、今回はPostgresSQLの行レベルセキュリティと、SpringAOPによる処理を組み合わせて、ログインしているテナントのデータにしかアクセスできなくする仕組みを実現しました。 導入にあたり考慮した複数の選択肢、乗り越えたいくつかの壁

こんにちは。ログラスの布川です。プロダクトローンチから9ヶ月が経過しました。最近SNSの発信やnoteの手がひたすら止まってしまったのも、本業に追われていたからだとお察し下さい・・・笑 皆様のGWの読み物として、今までずっとファイナンスキャリアだった自分がお客様にサービスについて説明する、セールスをするという新しい経験をする中で、少しセールスに関する、今の自分考え方をまとめたnoteを出そうと思いました。 このnoteは、セールスパーソンだけでなく、ログラスのお客様や製品に関心のある方、これからログラスに入ることを少しでも検討頂く方、起業を目指している方にもお読み頂きたい内容になっています。 いわゆるテクニック！！みたいなnoteでは全くないので、その辺期待せずでお願いします。どちらかと言えば、0→1フェーズで創業社長がやるべき泥臭いフェーズについてと、ログラスという企業のセールスに対する

@t_wadaさんが翻訳されていた技術的負債の記事をあらためて読んでみたら非常に面白かった。技術的負債の本来の意味が説明されているので、まだ読んだことがない人は一読をおすすめする。 その翻訳記事を読みながら、Jasper（僕が開発しているGitHub用のIssueリーダー）のv1.0で技術的負債を返済したことを思い出した。そこで、その翻訳記事を参考にして技術的負債の生態について自分なりに考えてみることにした。すると面白い生態がいくつか見えてきた。例えば「生態③: むしろ技術的負債が生まれることそれ自体はポジティブである」などである。今日はそのことについて書いてみようと思う。 ちなみに今回は技術的負債への対処までは解明することができなかった。いつか続きを書けたらいいなと思う。 技術的負債が生まれる背景 まずはJasperで経験した技術的負債を紹介する。負債の内容自体はそんなに重要ではないので

GitHub は、毎日 5600 万人以上の開発者にサービスを提供し、2 億以上のリポジトリをホストしています。これらのリポジトリのごく一部を除いて、世界中の顧客に驚くべきパフォーマンスでサービスを提供しています。 GitHub のような大規模なシステムでは、コードとアーキテクチャのずれというのは限界に達したときに初めて見つかるものです。例えば、何千人もの開発者が毎日同じリポジトリを更新するといったケースです。GitHub は、大規模なモノリポを使用する一部の顧客から、プッシュ操作が失敗するといったパフォーマンスの問題が発生しているというフィードバックを受けました。 そして、それは GitHub においても発生していました。 github/github は GitHub のモノリポですが、私達自身も時々プッシュに失敗することがありました。 調査を開始するにあたり、私たちは社内のチームや顧客

株式会社ログラスの松岡です。 本記事では、DDDに関する疑問で頻出な、複数集約間の整合性を確保する方法について、具体的なコードを交えて紹介します。 実装方法は、主に以下の3つに分かれます。 ユースケースで複数集約に更新をかける ドメインサービスを使用する ドメインイベントを使用する 目次 目次 集約の定義について 題材とする事例 実装方法1. ユースケースで複数集約を更新する メリット・デメリット 実装方法2. ドメインサービスを使用する メリット・デメリット 改善案 実装方法3. ドメインイベントを使用する ドメインイベント作成に制約をつける メリット・デメリット まとめ 集約の定義について詳しく知りたい方は 現場での導入で困ったら 集約の定義について 集約自体の説明については、本記事では割愛します。詳しくは下記の書籍「集約」の章をご覧ください。 little-hands.booth.p

「Reactに書き換えないとこのプロダクトチームは緩やかに死を迎えます」 こんにちは、ログラスのエンジニアの佐藤です。 昨年に入社して早2ヶ月経ちましたので、入社記事でも書いていきます。 「Reactに書き換えないとこのプロダクトチームは緩やかに死を迎えます」 と、CTOに言ったのは昨年末くらいでした。 入社してまだ1ヶ月経たないくらいです。 ログラスは創業当時からAngularを使って開発をしていました。 正社員のフロントエンドエンジニアは自分が入るまではいなくて、業務委託の方と協働しながら開発をしていました。 そのプロダクトをゼロからこの創業期のタイミングでReactでフロントエンドを作り直そうというお話です。 今回のお話はあくまでログラスのプロダクトチームの目指す理想像とAngularの相性が悪いだけで、AngularがReactより劣っているわけではありません。 Angularはフ

【16-E-4】残業ゼロで開発スピードが10倍に！もう元の開発体制には戻れないデンソー流のアジャイル開発Developers Summit