サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
デスク環境を整える
tech.route06.co.jp
Yjsは、リアルタイム共同編集を実現するためのアルゴリズムとデータ構造を提供するフレームワークです。Notion や Figma のように、1 つのコンテンツを複数人で同時に更新する体験を提供することができます。 Y.Map, Y.Array, Y.Text といった共有データ型を提供し、それらは JavaScript の Map や Array のように利用できます。さらにそのデータに対する変更は他のクライアントに自動的に配布・同期されます。 Yjs は Conflict-free Replicated Data Types (CRDT) と呼ばれるアルゴリズムの実装であり、複数人が同時にデータを操作してもコンフリクトが発生せず、最終的に全てのクライアントが同じ状態に到達するように設計されています。 クイックスタート Y.Map がクライアント間で自動的に同期されるコード例を見てみましょ
ROUTE06 でソフトウェアエンジニアをしている @MH4GF です。 GitHub のマージキュー(Merge Queue)を私のチームでの開発フローに取り入れてから数ヶ月経ちました。マージキューは非常に便利ですが、挙動の理解やセットアップに難しさがあると感じています。いくつかの課題の対処ができ安定した運用ができてきたので、この記事ではセットアップでつまづきがちな点を紹介します。 マージキューとは マージキューは 2023 年 7 月に一般公開された比較的新しい機能で、簡単に説明すると「プルリクエストのマージ前にマージ先ブランチを取り込んだ上で CI を実行し、通ることを確認してからマージする」機能です。 複数人で GitHub を利用した開発をしていると、main ブランチの取り込み漏れにより「プルリクエストでの CI は通るものの、マージ後の main ブランチの CI は失敗する
こんにちは。ROUTE06の技術広報Bです。TSKaigi 2024の参加レポートをお届けします。 TSKaigi 2024とROUTE06協賛の背景 TSKaigi 2024とROUTE06が協賛した背景については以下の記事をご覧ください。 route06.co.jp ROUTE06のメンバーも現地&オンライン参加 ROUTE06からは、数名のメンバーが現地に参加し、またオンラインからも視聴させていただきました。 現地で交流していただいた皆様、ありがとうございました。 ROUTE06 池田の登壇「TypeScriptが学生のエンジニアコミュニティ参加を促進する」 弊社 Software Engineer 池田の登壇がありました。 登壇者:株式会社ROUTE06 / Software Engineer 池田 仁俊(Noritaka Ikeda) タイトル:TypeScriptが学生のエンジ
Pull requestのタイトルや説明文を書いている時、「これ絶対AIでできるよな」と感じたことがある開発者は少なくないと思います。 もちろん変更の経緯や背景など、コードの差分からは読み取れない情報もありますが、コードの差分からわかることはAIが書いてくれるといいですよね。 この願いを叶えてくれるのがCodiumAIが提供しているPR-Agentです。GitHub Actionで実行でき、OpenAIはもちろんAzure OpenAIやAmazon Bedrockも使えます。 PR-Agentはすでにいろいろなところで取り上げられています*1 *2 *3ので、このブログ記事では、これまでにあまり紹介されていないPR-AgentでLLMとしてAzure OpenAIで使う方法と、使ってみた感想を紹介します。 どうしてPR-Agentを使うのか コードレビューをできるAIエージェントはいくつ
はじめに: 弊社のとあるEDI(電子商取引)関連のプロダクトでは、Ruby on Railsを利用してGraphQL APIを提供しています。 その開発活動の中で最近、コードの品質と整合性を維持するためのツールとして rubocop-grep を利用し始めました。 この記事ではその具体的な活用事例についてお話しします。 目次 rubocop-grepとは 最初のユースケースと、基本的な使い方の説明 複数のルールをディレクトリごとに設定するための工夫 ほかにどのようなユースケースがありそうか まとめ rubocop-grepとは rubocop-grep は、rubocop の拡張ツールです。 プロジェクト独自のコーディングルールを、正規表現を用いて簡単に定義することができます。 この手の問題は、今までもカスタムCopを書くことで解決することはできましたが、カスタムCopはASTの知識やRu
こんにちは、ROUTE06 でソフトウェアエンジニアをしている@MH4GFです。 この記事では、urqlの Document Caching における additionalTypenames についての説明と、実運用でどのように扱うべきかという私見を書きます。最後に、提案する方針を後押しするために作成した Exchange(urql のプラグイン)を紹介します。 urql と Document Caching urql は、主に Web フロントエンドアプリケーションで使用される柔軟性と拡張性に優れた GraphQL クライアントです。 GraphQL クライアントライブラリにはパフォーマンスを向上させるためのキャッシュ機構が用意されていることが多いですが、urql はデフォルトではDocument Cachingと呼ばれる概念を使用します。 Document Caching は quer
RemixやNext.jsなどのフレームワークを使うとウェブアプリケーションのフロントエンドとバックエンドを素早く実装できるようになりました。また、VercelやCloudflareなどのサービスを使うと成果物をすぐにデプロイし、チームメンバーやお客さまに共有できます。 ただ、業務の中では、いろいろな制約からVercelやCloudflareが使えず、AWSを使うことも多いと思います。そして同じようなことをAWSで実現するためにはノウハウが必要で、検証する時間がもったいないと思っていました。 今回紹介するArchitectというフレームワークは、AWSに関数型Webアプリケーション(FWA)をデプロイするベストプラクティスをまとめて提供しており、試したところ、これであれば、VercelやCloudflareを使っている時のような高い生産性をAWSでも発揮できる可能性を感じています。 この記
連載「3分プロトタイピング」 Streamlitを用いたAIチャットアプリ RAGを使ってAIチャットアプリケーションに知識を与える ベクトルデータベース超入門(この記事です) 前回、前々回とAIアプリケーションのプロトタイプを作る時に便利な2つのフレームワーク: StreamlitとLlamaIndexを紹介しました。 この記事では、本格的なAIアプリケーションを作成するときに必要になることの多い、ベクトルデータベースを紹介します。今回も説明が長くなりますが、コード部分は3分で試せることを目指しています! ベクトルデータベース、ベクトル検索とは ベクトルデータベースとはどのような技術か、AWSのドキュメントがわかりやすく説明しているので引用します。 ベクトルデータベースは、ベクトルを高次元の点として保存および取得する機能を提供します。 これらには、N 次元空間の最も近い近傍を効率的かつ高
連載「3分プロトタイピング」 Streamlitを用いたAIチャットアプリ RAGを使ってAIチャットアプリケーションに知識を与える(この記事です) ベクトルデータベース超入門 前回の投稿でStreamlitを使ったAIとチャットするアプリケーションの雛形を作成しました。 tech.route06.co.jp あのアプリケーションにくまモンについて聞いてみるとこんな回答が返ってきます。 くまモンについて教えてください それっぽいけど違いますね。今回は、このように特定のキャラクターや事象について正しい情報をAIに返してもらう方法を紹介します。説明が長くなるので3分を超えてしまいますが、コードは3分で書けるようになっていますので、早速やってみましょう。 AIに知識を教える3つの方法 まず、AIにキャラクターなどの「知識」教える3つの方法について紹介します。 プロンプトエンジニアリング Retr
連載「3分プロトタイピング」 Streamlitを用いたAIチャットアプリ(この記事です) RAGを使ってAIチャットアプリケーションに知識を与える ベクトルデータベース超入門 大規模言語モデル(LLM: Large Language Model)を用いたアプリケーションを作る際、まずはChatGPTのようなチャットUIを再現して、独自コードであったり、独自データを組み合わせたいことは多いと思います。 ただ、チャットUIを0から作るのは結構時間がかかります。そこで、この記事ではStreamlitというフレームワークを使ってよくあるAIとチャットするアプリケーションの雛形を3分*1で用意したいと思います。 Streamlitとは Streamlitは、PythonでWebアプリケーションを簡単に作成できるフレームワークです。GUIの作成が簡単で、コード量も少なくて済むため、AIとチャットする
こんにちは。ROUTE06 データエンジニアの id:masutaka26 です。8/16 に入社したので、入社から 3 ヶ月経ち、会社にも慣れてきました。 初投稿である今回の記事では、ROUTE06 に入社して素直に変だと思った、会社の取り組みや習慣をまだフレッシュな気持ちが残っているうちに紹介します。 1. 入社 1on1 マラソン 早速出て参りました。全く聞き慣れないであろう「入社 1on1 マラソン」です。(*^^*) ROUTE06 に入社したら、全ての正社員と 1on1 する必要があります。私は入社前に聞き流してしまったようで、入社後聞いた時は「これから 50 人と 1on1 するなんて正気ですか?」と思いました。 私は 1 回 30 分を毎日 2~3 セッティングして、8/21 ~ 9/25 で完走しました。期間は自由で、数ヶ月かける人もいるそうです。 初見の方と話すのは苦手
北欧神話の世界で、村を作りながら新大陸を開拓する『NORTHGARD』というストラテジーゲーム*1を遊んだ時に、とても印象的な体験をしました。村人が増えて食料やお金も整って、いざ遠征するぞと準備を始めた時に、村人の士気が急に下がり始めたのです。食料やお金を用意したり、手当たり次第に介入しても士気は下げ止まらず、隣の村からの侵略を受けて占領されてしまいました。 何回かやり直してわかったことは、村がある程度大きくなった時には、家や酒場のような憩いの場がとても重要になるということでした。そして、憩いの場は、士気が下がり始めてから作り始めても効果はなく、村は崩壊します。とはいえ、最初に憩いの場を作ってしまうと限られた食料やお金がなくなり村は力を失います。 この例はいろいろと単純化していますが、遠征を「大胆さ」や「挑戦」、憩いの場を「思いやり」や「信頼」と置き換えることでチームでのソフトウェア開発に
こんにちは!ROUTE06でPlain API チームに所属している @FunamaYukinaです。 先日初のオフライン開催となったKaigi on Rails 2023に現地参加してきましたので、そのレポートをお届けします。 会場の様子 会場の浅草橋ヒューリックホール&カンファレンスでは、多くの参加者で賑わっておりました。 会場で配られていたKaigi on Rails 2023 のノベルティ 今回ROUTE06はスポンサー協賛させていただきました。 また、今回のKaigi on Rails 2023 初日の夜に参加者さん同士が交流できる場として、スポンサー企業の株式会社マイベスト様、株式会社YOUTRUST様と一緒に『Startup Drinkup at Kaigi on Rails 2023』を開催しました。 Startup Drinkup at Kaigi on Rails 20
私はソフトウェア開発を10年以上仕事として続けています。いつからか、どうすれば不確実性を減らして早く、要求通りのソフトウェアを開発できるかを考え始めていました。特に今年の4月に、フロントエンドチームのテックリードになってからは、フロントエンドチームが対峙する不確実性が少なくなるように考え、行動することに時間を使っています。 テックリードになってから6ヶ月経ち、反省することはたくさんありますが、プロジェクトのスケジュールに大きな遅延がなく、現時点で達成すべき水準の品質を満たしているので、ある程度の成果は出せていると自己評価しています。一方で、不確実性を下げるために考えたり行動することに少し飽きているというか、もうちょっとワクワクした気持ちで開発できないか悩んでいました。 そんな時に、庵野秀明監督が不確実性を保ったまま商業アニメーションを制作することに挑戦し、成し遂げた作品が『シン・エヴァンゲ
こんにちは、ソフトウェアエンジニアの@satorunです。現在はROUTE06でiOSアプリの開発をしています。 ROUTE06では、先日行われたiOSDC Japan 2023にスポンサーとして協賛させていただきました。 ROUTE06はiOSDC Japan 2023にスポンサーとして協賛します TシャツのROUTE06ロゴ 今回はオンライン/オフラインでカンファレンスに参加させていただいたので、そのレポートを書きたいと思います。 参加レポート 今年のiOSDCはコロナ後初のフルスペック開催と表現されていた通り、オフライン参加者も多く、会場はとても盛り上がっていました。私個人としては、しばらく開発から離れていたこともあり、iOSDCへの参加は2018年以来、5年ぶりの参加でしたが、楽しい雰囲気の中過ごさせていただきました。 会場の様子 オフラインの良さとして、他の参加者との交流があると
プロダクトセキュリティのお手伝いをしている wonda-tea-coffee です。 このたびROUTE06ではGitHub Advanced Security(以下GHAS)を導入することになりました。 👉 あわせて読みたい: 全社プロダクトのセキュリティ向上: SASTツールを選定した話 それに際してGHASとは何か、またどんな運用を予定しているのかについて社内向けに資料を作成しました。今回はその資料を社外向けに一部修正して紹介します。 GHASとは GHASはGitHubのEnterpriseプランに追加することができるセキュリティ機能に特化したアドオンです。 docs.github.com 以下ではGHASが備える機能について紹介します。 Code Security GitHub上のコードの脆弱性をスキャンする機能です。 docs.github.com GUI操作のみで手軽に有効
ROUTE06では、GitLab Handbook*1を参考に、全社に関係する情報をハンドブックとして社内に公開しています。ハンドブックは2023年8月時点で383ページ*2あり、50人前後の組織規模の会社としては文章化に積極的なことが現れている数字だと思っています。 また、ハンドブックとは別に、プロジェクトごとのレポジトリでは技術選定や設計方針をADR*3で残していたり、参加したセミナーのレポートをGitHub Discussionsに書いていることからも、ROUTE06で働く人は文章を書くことが習慣になっていると感じます。 そんな中、ある日社内のSlackに一つの問いが投げかけられました。 ドキュメント文化というのは、たとえばマニュアルに書いてないから分からなかった・故になんらかの失敗が発生した場合、マニュアルに書いていなかったことが悪いみたいな考え方になるのでしょうか 社内のSlac
ROUTE06 でソフトウェアエンジニアをしている @MH4GF です。 ROUTE06 ではエンタープライズ向けビジネスプラットフォーム「Plain」を開発しています。この記事では 2023 年 8 月に Plain クラウド EDI の Web フロントエンドで採用している技術について、その選定理由をまとめました。 現代の Web フロントエンド技術は領域ごとに選択肢が多く、プロダクトに最適な技術選定をする上で検討事項が多いと感じます。この記事がフロントエンド技術選定において参考になれば幸いです。 前提 プロダクトの特徴 技術選定に影響するプロダクトの特徴を箇条書きでまとめます。 エンタープライズ向け SaaS 現在開発中のプロダクトは商取引におけるクラウド EDI のドメインにフォーカス Plain が解決する課題は、元々フルスクラッチで開発すると 1 年かかるプロダクトの開発期間を
私のプロジェクトでは Architecture Decision Record (以降 ADR と記載) を導入しています。プロジェクトで ADR を使い始めてから 1 年以上が経過したので、実際に使ってみての感想と今現在の捉え方についてここに残します。 ADR とはなにかという説明や具体的な運用方法については検索したら十分に発見できると思うので、ここでは割愛し、私たちのチームでの経験にフォーカスします。 私たちのチームの状況 私たちのチームは、新しいプロジェクトの開始にあわせて 1 年ほど前に結成したチームです。 現在は 4 人くらいのチームですが、開発スピードを上げるためにフロントエンドとサーバーサイドでほぼチームが独立して動いているような時期もありました。 そのときは最大で 10 人以上が同じプロジェクトに関わっているような状態でした。 私たちのチームでの使い方 ADR の導入はチー
こんにちは、ROUTE06でソフトウェアエンジニアをしている @MH4GF です。 Amplify Hosting を利用してホスティングしている Web アプリケーションで、プレビュー環境を GitHub Actions でデプロイする方法を紹介します。 背景 Amplify Hosting では、実はプルリクエストベースのプレビューを機能として提供しています。 docs.aws.amazon.com プルリクエストの作成と同時に環境にアクセスする URL が払い出され、Gitのコミットのプッシュと同時に再ビルドし、プルリクエストのマージと共に環境を削除します。 ビルドの進捗状況もプルリクエストの Checks として確認できるため、概ね期待する機能は揃っています。 ただ、運用する上でどうしても気になる点がありました。 モノレポで構築されているリポジトリで、ビルドの発火するディレクトリパ
ROUTE06 でエンジニアリングマネージャ兼ソフトウェアエンジニアとして働いております海老沢 (@satococoa) と申します。 先日発生した GitHub Actions と AWS の OpenID Connect 連携におけるトラブルに関して調査を行い、対応方針を策定した件を共有したいと思います。 [2023/07/10 追記] Thumbprint を明示的にユーザ側で設定しなくて良いように、AWS 側で対応されたそうです。 github.com 当面 Terraform のモジュール的には必須入力のままですが、任意の文字列で良いそうです。 (いずれ入力も不要になるのかと思います。) https://github.com/aws-actions/configure-aws-credentials/issues/357#issuecomment-1626357333 The A
新しいプロジェクトに参加してローカル環境を作り始めると、何かとエラーに遭遇します。 また、設計や実装について開発者に相談したり、コードレビューを依頼することもありますね。 開発者が近くにいれば、(それなりに、程よいタイミングを見計らって)話しかけて、エラーの原因を調べてもらったり、設計方法をホワイトボードにスケッチしながら相談できますが、リモート開発ではそうはいきません。 リモート開発で成果を上げるためには、このブログのように何の装飾もインタラクティブ性もない文章で、自分の状況や相談したい事柄を正確に伝える必要があります。 とはいえ私は昔、「文章がわかりにくい」と毎日、毎日上司にフィードバックをもらうくらいには文章を書くのが下手くそでした。今もわかりやすい文章が書けている自信はありません。 それでも、これまでに何度か、議論が好転したり、プロジェクトが前に進むきっかけとなる文章を書けたことが
プロダクト開発に利用する技術の選択は、不確実性を伴う決断であることが多いです。 私はROUTE06で働く前は個人事業主でした。仕事の多くは、新規プロダクトのプロトタイプや初期バージョンの作成でした。デザインを含めてプロダクト開発をするのは私一人だったので、おおよその要件とスケジュール、予算が合意できたら、作り方は任せてもらっていました。 当時、私が技術を選択する方法は「開発速度や品質に非線形の変化を与える可能性があると感じたらまずは使ってみる」でした。アルファ版*1でもとりあえず使ってみて、上手くいったらそのまま本番稼働させているプロダクトもあります。 足りてない機能や不具合に直面することもありますが、パッチを書いたり開発元にプルリクエストを送りながらプロダクトの開発も進めていました。この進め方は、開発者が一人であれば成果を出せますが、チームで大きな成果を出すのは難しいでしょう。 現在、私
ROUTE06では、昨年に続き本年もRubyKaigi 2023へスポンサーとして協賛、さらに今回は初開催のスピンオフイベントであるKeebKaigi 2023へもあわせて協賛させていただきました。 ROUTE06はRubyKaigi 2023にスポンサーとして協賛します - 株式会社ROUTE06 (ルートシックス) ROUTE06はKeebKaigi 2023にスポンサーとして協賛します - 株式会社ROUTE06 (ルートシックス) これをきっかけに社内から3名のメンバーが現地へお邪魔しましたのでその際の様子を綴っていきます✍️ ◆ スポンサードの背景 ROUTE06は現時点で創業から3年ほどの企業ですが、RubyKaigiへのスポンサードは2023年で2回目になります。スポンサードの背景には以下のような考え方があります。 ROUTE06では、顧客企業の新たな企業価値を生み出すため
次のページ
このページを最初にブックマークしてみませんか?
『ROUTE06 Tech Blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く