サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
災害への備え
tech.hicustomer.jp
Hype Driven Development(HDD) シード・アーリーステージのスタートアップの開発者のみなさん、こんにちは。突然ですが、ソフトウェア開発していますか?毎日設計しコードを書いていますか?私は毎日しています。毎日ビジネスドメインと向き合っております。今日はそんなみなさんに、弊社のソフトウェア開発の失敗談( ハードシングスへの突入と脱出 の「根の深い技術的負債」を掘り下げる内容になっています)を共有します。この失敗からなにか参考になるものがあれば幸いです。 実際に起ったこと 2018年初頭にサーバレスとDDDの導入 弊社のHiCustomerサービスのアーキテクチャはサーバーレスとDDDを軸に設計されました。サーバーレス環境としては、AWS APIGateway、AWS Lambda、AWS DynamoDBを使ったAWS推奨の構成を採用しました。DDDはGolangを使用
弊社HiCustomerは、2021年のすごいベンチャー100に選ばれました。小田です。皆様今年もよろしくお願いいたします。直近の報告ですが、私はちょくちょくKafkaJSと遊んでおります。もうAWS SQSやCloud Pub/Subには戻れない身体になりそうで、タイミングをみてConfluent社の株を買っちゃいそうです。ギャンブラーとしてAll-inしちゃおうかな😜 最近のNode.jsのORM事情について 本題ですが、最近SaaSの新規案件を始める関係でORM周りライブラリの技術調査をしています。ちなみに環境と要件は以下です。 環境は以下: データストアはPostgreSQL 言語はTypeScript ラインタイムはNode.js 要件は以下: スキーマファーストで実装できる 可能であればスキーマを書いて型とコードが生成できる クエリに対応する関数をいい感じに型付けできる 複雑
こんにちは、エンジニアの尾島(@daikiojm)です。 最近は「社内にパリピ感が足りない」という課題感から Slack で「おじ卍ドレミ」を名乗っています。 最近開発を進めている新プロダクトで React と Vite の組み合わせを採用したので、技術選定の背景と使用している Vite プラグインについて簡単に紹介します。 これまでの HiCustomer のフロントエンド開発 これまで HiCustomer 社では HiCustomer のフロントエンドを Vue.js を用いて開発を進めてきました。 開発初期から現在まで、フロントエンドのコードベースは次のような変化をしてきました。 開発初期~ Vue 2 + JavaScript ~リリース 1 年 Vue 2 + TypeScript + Vue Class Component ~現在 Vue 2 + TypeScript + C
こんにちは、エンジニアの尾島(@daikiojm)です。 最近は HiCustomer のオフィスがある五反田周辺の飲食店の入れ替わりが激しく、開店/閉店に一喜一憂しております。 五反田、目黒周辺でおすすめのお店があったら教えてください。 React + Vite で新規プロダクトを開発している話で紹介した新プロダクトの開発では、GraphQL を採用しています。 今回はこの記事では紹介しきれなかった GraphQL Code Generator と React Query の活用について紹介します。 この記事で紹介する内容は次のとおりです。 GraphQL Code Generator + React Query の組み合わせを採用した理由 GraphQL Code Generator を使った型/React Query のクライントコード生成 Custom Hooks の実装例 Gra
はじめに こんにちは、フロントエンドエンジニアの尾島です。 2 年ほど前から副業という形で HiCustomer の開発にちょこちょこと関わっていましたが、今年の 7 月からはフルタイムで開発をしています。 入社以来、新機能の開発と並行してデザイナーと共に進めている HiCustomer のデザインシステムの作成、アプリケーションへの適用、また運用についてご紹介します! この記事で話すこと: デザインシステム、デザインガイドラインとは なぜデザインシステムが必要だったか どのようにデザインガイドラインをスモールスタートしたか 具体的な Tips など デザインシステム、デザインガイドラインとは デザインガイドラインやデザインシステムという言葉は、人や組織によって定義や解釈が微妙に異なりますが、 一般的に以下のような構成要素(一例)のフルセットとして認識されているのではないでしょうか。 デザ
こんにちは、HiCustomerの肥前です。このブログの最初の記事を書いた頃からは少し立場を変え、最近ではプロダクトマネージャーとして仕事をしています。弊社では開発プロセスにスクラムを導入していますが、この記事では特にスクラムイベントに焦点を当て、実際に使用している資料などを交えてどのようなことを行っているのかを紹介します。以下についてお話しします: なぜスクラムを選んだか スクラムの概要 HiCustomerでのスクラムイベントの進め方 以下については詳しく触れません。 スクラム自体の詳細な説明 想定読者 スクラムの基本的な用語や、その意味を理解していることを前提とした記事です スクラムを検討または運用中のチームにとって、他社事例として役立てていただけると嬉しいです これから私たちのチームに加わるメンバーに向けた、オンボーディング資料でもあります スクラムの方法論そのものに関する情報をお
はじめに HiCustomer のエンジニアの 吉村(@jumpyoshim)です。 今回は、 GitHub Actions と git-secret による Postman の CI/CD 環境の構築方法 を紹介させていただきます。弊社では公開 API とプライベート API の結合テストや回帰テストなどで Postman を利用しています。Postman を利用するなかで以下の問題がありました。 誤操作で Postman の Request が書き換わってしまうことが多々あった 大量の Request を作成・修正する場合に Postman 上で行うのは非効率だった 上記の問題を解決するべく、GitHub Actions を活用した Postman への同期の自動化と git-secret を活用した Postman のバージョン管理を行いました。 Postman とは Postman
雑談 いやー春が近いですね。ウキウキのHiCustomerの小田です。最近の騒動で知ったんですが、Linuxカーネルのstableへのバグフィックスの一部はNeural networkを使って自動的に選定されてバックポートされているようです。正直まだGregの超絶な能力のみを使ってマニュアルでさばいているのかと思っていました。一般的にバグのバックポートはめちゃめちゃerror-proneな作業なため、その辺が進化してくれると今後いろんなソフトウェアが幸せになりそうです。詳細は以下にまとまっています。PatchNetの実装が見たかったんですが、ネットに情報がなさすぎて追い切れなかったです。ご存知の方は教えてください。 The case of the supersized shebang きっかけになった騒動です。偽陽性や偽陰性を2つともゼロにはできないので、意図しないパッチが入ってしまったり
こんにちは、カスタマーサクセスエンジニアで丘サーファーの白坂です。 HiCustomer は SaaS として提供されるカスタマーサクセス管理プラットフォームで、各テナントから送信されてくるログデータに基づき顧客のスコアリングやその他の集計処理、またそれらをトリガーとした通知の送信などを行います。 そのためHiCustomerではページビューを含むログデータを送信する一つの手段としてトラッキングコードを提供しています。いわゆるGoogleアナリティクス(以下GA)のタグのイメージです。 ページビュー(以下PV)はWebページが「閲覧された回数」「開かれた回数」と表現されることが多く、 もともとはページの読み込み時にPVを計測するタグを呼び出し計測をすることが多かったのですが、 SPAでは、はじめにページを読み込んで以降、SPA内での画面遷移は擬似的に行われるため下記のような問題にぶつかりま
TL;DR JWTはCookieを使った認証の代わりに使うのはきつい。 コードを静的にホスティングしているSPAの話。 JWTの有効期間を長くすれば危険で、短くすればUXが犠牲になるというトレードオフがある。 AWS AmplifyはlocalStorageにJWTを保存 悪意のあるThird partyライブラリが混ざっていたらJWTを抜かれる。 yarn.lockが依存している全ライブラリを監査することはつらい。 Auth0ではiFrameを活用してメモリ上にJWTを格納できる Auth0いいね😍 まくら Youtubeが大好きなHiCustomerの小田です。ちょっと遅いですが年明け最初のエントリーです。今年もテックブログをよろしくお願いします😎ちなみに、気分がいいので年明けに観ていたYoutubeのエントリーの中で一番おもしろかった動画を紹介します。世界中で有名な「Auld L
この記事は GraphQL Advent Calendar 2018 の22日目です。 どうも、HiCustomerのエンジニアの@m4s4k3xです。 GraphQLが広く使われるようになって久しいですが、弊社でも、以下の理由などからGraphQLを導入することにしました。 BFFを立てるほどのエンジニアリソースを割かなくてよい Union TypesやEnumと言ったスキーマの型表現が可能である エコシステムが豊富 大量のエンドポイントを増やさなくても良い 一度のリクエストでフロントエンドで必要なリソースが取得可能 Goにおいての採用事例もちらほら見かけるようになりました。GoにおけるサーバーサイドにおけるGraphQLライブラリはメジャーなものが5つほどあります。各々のライブラリの横断的に紹介した後、弊社での選定理由を紹介します。 GoにてGraphQLの導入を検討している方への助け
こんにちは、エンジニアの肥前です。この記事は Serverless Advent Calendar 2018 の13日目です。 また、HiCustomer Tech Blog の最初の記事でもあります。今後もチームで継続して得られた知見を書き溜めていく場にしたいなと思います。 さて、いわゆる ”サーバーレスアーキテクチャ” を採用してスタートアップのプロダクト開発を開始しておおよそ一年が経過しました。もちろん恩恵に預かっている部分、省力化できた点は多々あるのですが、今改めて振り返るとアンチパターンを踏んでいたり、このまま放置すると負債化しそうな箇所が見えてきています。失敗した話というのはなかなか表に出しづらいものではあるのですが、少しでもこれから取り組む方の助けになればと思い記事に残してみようと思います。サーバーレス界隈の方々にはあるあるネタだと思うのでご笑納ください。 前提となる構成 事
このページを最初にブックマークしてみませんか?
『tech.hicustomer.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く