はじめに みなさんこんにちは、物流業界の価値最大化をミッションに掲げるアセンド株式会社で取締役CTOを務めている丹羽です。 今回はアセンドの Full TypeScript Architecture の選定背景とその構成を紹介します。 アセンドでは社会課題である物流危機の中心にいる運送会社に対し、課題解決の第一歩として業務と経営のデジタル化を実現する All-in-One な運送管理SaaS「ロジックス」を開発しています。アセンドは12月06日にプレスリリースをした通りシリーズAの資金調達し、無事にプロダクトとして PMF (Product Market Fit) を一定達成したと言えます。 3年前に開発をスタートしたロジックスはフロントエンド、バックエンド、クラウドのIaCに至るすべてを TypeScript で開発することを選択しました。振り返ってみても FullTS でなければ PM
お仕事でEmbulkを使ってBigQueryにデータインポートやることがあって、その時にパーティションテーブルに対してアレコレやるときに色々検証したのでメモ。 Embulkはv0.9.23でembulk-output-bigqueryはv0.6.4です。 github.com パーティションの利用方法 embulk-output-bigqueryでパーティションテーブルを扱う方法は下記の2つです。 table名でパーティションデコレータ指定 time_partitioning.field table名でパーティションデコレータ指定 table: table_name$20200827 のようにパーティションデコレータを利用すると、指定パーティションに書き込めます。 この書き方をすると後述するmodeオプションでreplaceなどを利用した時に指定パーティションだけ上書きできます。 デコレー
マイクロサービスの矛盾先日、「マイクロサービス?モノリス?SaaSアーキテクチャのPros/Cons | SaaS.tech #1」(youtube)(togetter)というイベントを観ました。これは、マイクロサービスのイベントだったのですが、新規のシステム開発において積極的にマイクロサービス化をすすめる方が少なかったのが意外でした。 マイクロサービスの開発経験のある優秀なエンジニアであっても、まずはモノリスからはじめてプロダクト境界を意識して設計していき、functionベースで切り出せるもの(認証や通知、メール送信、バッチ等)は切り出しつつ、必要であればモジュラーモノリスかマイクロサービス化を慎重に検討するということでした。素晴らしい冷静な判断です。 というのは、ドメインの専門知識がないうちにマイクロサービスの複雑なシステムを設計するのは、多くのソフトウェアプロジェクトが陥りやすいリ
オブザーバビリティも、セキュリティも、検索ソリューションも、Elasticsearchプラットフォームならすべて実現できます。
D.M.です。Llamaindex で ChatGPT と連携した社内文書の QA ツールを構築した際にハマったことを書いていきます。 ChatGPT に追加でデータを与える課題へのアプローチ 今回やりたいこと つくったもの システム構成 ユースケース はじめに書いたソースコード Llamaindex 処理フロー Llamaindex チューニング課題 元ネタのテキストファイルをベクター検索のチャンクに収まるように意味の塊にする 課題1 ベクター検索の2番目のドキュメントが正解だったりする問題 課題2 複数のドキュメントを読ませると間違える確率が上がる問題 課題3 失敗している理由がよくわからない問題 課題4 ときおり英語で返してくる問題 課題5 OpenAI API がタイムアウトする問題 Tips1 ローカルファイルを小さくしたい Tips2 回答をもっと厳密にしたい ChatGPT
はじめに ※この記事はEngineering Manager Advent Calendar の22日目の記事になります。前日はmtx2sさんの技術的負債に対するマネジメントの記事でした。個人的には「負債上限」「負債ベースライン」の考え方良かったです。 こんにちは。モノタロウでエンジニア組織のマネージャーをしております普川(@taipuka0)です。 自分は前職から通算10年以上してエンジニアリングマネージャーを続けた後、現在モノタロウでは8人のEMのみなさんと日々ソフトウェア・エンジニアリングの現場でマネージャーとして課題解決に向き合っています。これまで色々な壁にあたり、試行錯誤を繰り返して来ました。EMの難しさを痛感したことも多々ありました。 なぜEMが難しいのか?その一つとして、エンジニアからEMにジョブチェンジした際のギャップというのがあると思います。同じチーム、現場にいたとしても
キーワードベースで情報収集をしているという下記の記事を読みました。私も似たようなことをしているのですがキーワードは使わない方法でニュースの収集をしていて、そのほうがLLMを活用できていると思うのでその方法を紹介します。 forest.watch.impress.co.jp キーワードではなく自分の目的や関心を伝える 以前私が手動でやっていたのはRSSリーダーにサイトを登録して、記事のタイトルと概要を読んで気になる記事を開いて読むということでした。こういうときに人間はキーワード検索をしていません。何をしているかというと自分の目的や関心があって、それに関連する記事をピックアップするということです。それと同じようなことをさせようというのが今回紹介する方法です。 ポイントは今回の場合は私の所属する会社について情報をプロンプトで与え、それに関連するニュースが何かをLLMに考えさせることです。 今回の
Scrum@Scaleガイドの序文 スクラムは、もともとスクラムガイドで説明されているように、単一のスクラムチームが、持続可能なペースを維持しつつ、最適な価値を提供できるようにすることを重視している。スクラムガイドの発行以降、スクラムの利用はプロダクト、プロセス、サービスなどの開発といった複数チームの協力が求められる領域まで広がりを見せている。 現場では、組織内のスクラムチーム数の増加に伴い、2つの重要な問題の発生が繰り返し見られた。 複数のチームの間での依存関係や作業の重複、コミュニケーションのオーバーヘッドなどの問題により、チームごとのアウトプット(動作するプロダクト)の量、スピード、品質が低下し始めた。 従来の組織構造はビジネスアジリティの実現に十分な効果を上げられなかった。優先順位の競合や、市場の変化に対応するようチームを素早く転換させることができないなどの問題が発生した。 こうし
つい最近、強烈な寒波がやってきて北九州ですら白銀の世界になりました。 あ!そういえば(; ・`д・´)、と思い出し以前から報告しているセルフリノベーションした賃貸に駆けつけてみると、、ありゃ案の定、、、電気温水器の配管に巨大な氷の塊が、、、 ...
【課題①】IT業界の多重マージン構造により、 国内エンジニアは非効率でミスマッチが多い労働環境にさらされている 近年、ますます発展するITサービス。その様な背景からもエンジニアに対する需要が増加し、2030年には国内で約79万人不足するといわれています(2019年3月みずほ情報総研調査より)。 その様な中、現在107万人ほど存在するIT人材(エンジニアなど)のうち、約4割はSES業界にて従事しているといわれています(イーデス@人事より)。 この、SES業界は案件情報が降りてくるまでがピラミッド方式の構造になっており、末端の人材に情報が伝わりにくくなっていたり、また、多くが多重マージン構造になってしまっています。 この構造により川下の企業は川上の企業に案件が左右されてしまうため、案件が急にストップすると人材リソースが余ってしまうといったことも起こり得ます。また、情報伝達がうまくいかないことか
はじめに ラクスルグループのノバセルで新卒2年目のエンジニアをしています田村(tamtam)です💪 現在は、データサイエンティストが作成した学習済みモデルをもとに、推論を行うロジックを実装し、Web APIとして提供するための開発をしています。 この記事を読んで得られること この記事では、推論用REST APIサーバーを構築する際に考えたことを2つのセクションに分けて紹介します。 推論用サーバーを構成するAWSリソースの検討 推論コードを実装する上での検討 SageMakerを利用し推論用REST APIサーバーを構築する方の参考になれればと思います! それでは詳細について見ていきましょう! 参考となるレポジトリ 今回の記事に際して、参考となるプロジェクトテンプレートを共有します。 github.com 上記のテンプレートは、サンプルとしてWord2Vecを利用した予測を行います。試した
はじめに こんにちは。RAKSUL Advent Calendar 2021 15日目を担当するハコベルの吉岡です。 本日はメッセージキューを使う際にProtocol Buffersを使って構造化されたメッセージのやりとりができないかのPoC(Proof of Concept)を紹介させていただきます。 背景 今取り組んでいるプロジェクト内でAmazon SQSを使うことになったのですが、現段階でSQSにメッセージをエンキューするのがGoのサービスで、メッセージを受け取るのがPythonのサービスということが想定されています。SQSの技術検証を進める中で「構造化されたデータをメッセージとしてやりとりできないか」とふと思い、「Protobufをうまいこと使えないか」という考えが浮かびました。 事例がないかリサーチしていると、自分がやりたいことと同じことをやっている方の記事があったのでこちらを
メンバーの権限にはAdmin Member Testerの3種類があり、初期値はMemberです。 Memberには非公開のLIFFへのアクセス権がないため、開発中LIFFを見る必要がある場合は権限変更を忘れないようご注意ください。 自分だけのグループトーク LIFFには、LINEアプリのトークルームから起動しないと使用できない機能があります。 (KeepからLIFFを開いてデバッグしたら、sendMessageが権限エラーで利用できなかった経験あり) とはいえ、開発中のLIFF URLを誰かにあててトークで公開するわけにもいかないため 開発中のLIFF URLを開くために、自分だけが参加しているトークをつくると便利です。 トークルーム作成を開く グループを選ぶ 友だちを選択画面で誰もえらばずに次へ メンバーが自分だけなのを確認して作成
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く