サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
デスク環境を整える
techblog.enechain.com
この記事はenechain Advent Calendar 2024の8日目の記事です。 こんにちは!enechainでソフトウェアエンジニアをしている山添です。 現在は今年10月にリリースした「eSquare Live」のFIX APIを提供するため、FIXサーバー1の開発を担当しています。 この記事では、FIXサーバーの開発においてQuickFIX/Goを使っていて得た知見を共有します。 FIX ProtocolとQuickFIX/Goについて FIX Protocol の基礎知識 メッセージとタグ セッションの概要 Exampleで学ぶQuickFIX/Go Exampleの起動方法 設定ファイル メッセージのルーティングとロジックの実装 メッセージの送信 実践で役立つQuickFIX/Goの知識 シーケンス番号とメッセージの永続化 セッション管理の詳細 カスタムフィールドの扱い ま
はじめに eSquare Liveのブラウザ対応要件 JavaScriptのレガシーブラウザ対応 静的解析を利用したPolyfill対応 @vitejs/plugin-legacyの利用 CSSのレガシーブラウザ対応 @mdn/browser-compat-dataの利用 browserslistの利用 ESLint Ruleへの組み込み 実際のブラウザの確認環境 まとめ はじめに この記事はenechain Advent Calendar 2024の7日目の記事になります。 こんにちは、enechainでソフトウェアエンジニアとして働いている@sue71です。現在は2024年10月9日にリリースした「eSquare Live」の開発を担当しています。 「eSquare Live」は、電力卸取引の自動取引プラットフォームであり、10月にローンチしたenechainの新規プロダクトです。現在
この記事はenechain Advent Calendar 2024の6日目の記事です。 はじめに 2024年10月9日にローンチしたeSquare Liveは、電力卸取引のオンラインマーケットプレイスです。 新規サービスであり利用者の限られるtoBのサービスではあるものの、リアルタイム電力取引場というプロダクトの特性上、ローンチ直後から一定水準以上のパフォーマンスが求められます。 スケールすることを意識して開発してきましたが、約10ヶ月の開発期間のほとんどを機能開発に費やしていたため、リリース直前の段階で実際どの程度のパフォーマンスが出ているのかの計測ができていない状況でした。 そこで、リリース前の1ヶ月を使って負荷試験を実施し、パフォーマンスの計測とそこで発見されたボトルネックの解消をすることとしました。 この記事では、k6の拡張機能開発を中心に、実際にリリース前に行ったk6によるgR
この記事はenechain Advent Calendar 2024の5日目の記事です。 はじめに enechainでフロントエンドエンジニアをしている@Shunya078です! enechainは、日本最大のエネルギー卸取引マーケットプレイスを運営するスタートアップです。我々ソフトウェアエンジニアは日々、プロダクトを通じてエネルギー市場に貢献しています。 社内には10を超えるプロダクトが存在しており、各プロダクト共通で利用されるデザインシステムが存在します。自分はこのデザインシステムに、チームをリードする立場として関わっています。 去年、なぜ我々はデザインシステムを創るのか?という記事でデザインシステムの生い立ちについて執筆しました。背景などについては是非そちらをご一読ください! 今回は、今年一年間のアップデート内容を振り返るととともに、現時点における我々のデザインシステムがどういうフェ
はじめに この記事はenechain Advent Calendar 2024の4日目の記事になります。 こんにちは!enechainでソフトウェアエンジニアをしている古瀬です。 enechainでは今年10月にリリースした「eSquare Live」の開発を初期から担当しています。 「eSquare Live」は株式取引やFXのようにリアルタイムで電力商品を取引できるオンラインプラットフォームです。 今回は「eSquare Live」でもリアルタイム通知のために利用しているSocket.IO Adapterについて実装例を交えて紹介したいと思います。 Socket.IO Adapterとは Socket.IOはリアルタイムな双方向通信システムにおいて非常に重要かつ強力な機能を持ったOSSです。 その特徴としては以下のようなものが挙げられます。 柔軟な通信プロトコル: WebSocket非
はじめに FIXプロトコルについて 概要 FIXプロトコルの中身 テスト戦略 既存のテストライブラリ 作成したテストライブラリ Acceptorをどのように立ち上げるか Acceptorの振る舞いをどのように定義するか テストコードの例 テストライブラリの導入結果 FIXプロトコルの理解促進 変更容易性の向上 今後の課題 まとめ はじめに この記事はenechain Advent Calendar 2024の3日目の記事です。 本日はenechainのGXデスクとeClearデスクのバックエンドエンジニアの @eji が担当します。 最近FIXプロトコルを使ったサービスとテストを書く機会がありました。 今回はその経験をもとに、FIXプロトコルを使ったサービスのテストをどのように行ったかを紹介します。 FIXプロトコルについて 概要 FIXプロトコルの FIX は Financial Inf
この記事はenechain Advent Calendar 2024の2日目の記事です。 はじめに こんにちは!enechainでソフトウェアエンジニアをしている@taniyarnです。現在は『eSquare Live』のバックエンドを主に担当しています。 『eSquare Live』は、電力卸取引のオンラインマーケットプレイスであり、10か月の立ち上げ期間で開発した新規プロダクトです。 バックエンドはGoで構築していますが、リアルタイムに取引情報を表示するため、ストリーミングサーバーにはNestJSを用い、Socket.IOを使ってフロントエンドとリアルタイム通信をしています。 以前の記事で紹介した通り、eSquare Liveでは負荷試験ツールにk6を採用しています。 本記事では、Socket.IOサーバーに対する負荷試験をする際にk6を使う方法について解説したいと思います。 はじめに
はじめに 課題の概念化 テクノロジー企業 vs. テック強化型企業 プロダクトとしてのカルチャー (Culture as Product) どこから始めたか? 従業員の生の声を聞く 真のテックカンパニーとフェイクテックカンパニーの違いに関するアイデアの収集 定義の策定 最後に Introduction Conceptualize the challenge Tech vs. Tech-enabled company Culture as Product What I have done at the beginning Listening to employees' candid feedback Gathering ideas on what makes a company true tech vs. fake tech Formulating the definition Final
はじめに eSquare Liveの特徴 リアルタイム取引 自動で約定するマッチングエンジン 3種類の画面を作る必要性 爆速開発スピードと品質を両立したeSquare Liveのエンジニアリング 技術的なOverview 主な技術スタック 「絶妙に妥協」したアーキテクチャ monorepo k6を利用した負荷試験 意思決定に利用したADR 今振り返っての反省点 メンバー構成 仕様書の保守、QAの進め方 今後の展望 お知らせ はじめに こんにちは!enechainでプロダクト開発部の部長を務める長谷川です。 enechainは2024年10月9日にeSquare Liveという電力卸取引のオンライン取引マーケットプレイスをローンチしました。 eSquare Liveは、簡単に言うと株取引で利用するような板画面上で電力の卸取引ができるプラットフォームです。 電力のトレーダーは、このプラットフォ
はじめに プロダクトマネジメントトライアングルの重心 事業フェーズや規模の違いを意識してトライアングルの重心を考える A. 共通基盤の場合 B. 新規事業の場合 チームやステークホルダーをマッピングする A. 共通基盤の場合 B. 新規事業の場合 PDCAサイクルを回し続ける まとめ はじめに enechainでプロダクトマネージャーをしている酒見 (Kemmy)です。 enechainでは「共通基盤」と「新規事業」の2つの異なる性質のプロダクトマネジメントに携わっています。 私自身、これまで大手企業からスタートアップまで、さまざまな事業ドメイン・フェーズのプロダクトマネジメントに従事してきました。 事業フェーズや規模、それを担う組織によって、プロダクトマネージャーの役割やプロダクトマネジメントのスコープも異なる、というのはよく聞く話です。とはいえ具体的な経験がないと、その違いをなかなかイ
はじめに enechainでのテスト管理 テストケースとテスト進捗の管理 バグチケットの管理 日々のテスト進捗報告の自動生成 テスト進捗情報の取得 バグチケット情報の取得 報告の整形とSlackへのポスト 進捗報告生成のトリガー 今後の展望 まとめ はじめに こんにちは!enechainでQAチームのマネージャーを務める杉田 (@sug1san) です。 QAチームでは先日、初の試みとして「QAオフサイト」と題したイベントを社外の会場を借りて実施し、日頃眼の前の業務に忙殺されて後回しになりがちな品質改善、QA業務改善に、メンバー各人が自身でテーマを決め、丸一日かけて取り組みました。 今回は、私がそこで取り組んだGAS (Google Apps Script) とNotion APIを用いたテスト進捗報告の自動生成の取り組みについてご紹介します。 enechainでのテスト管理 本題に入る前
こんにちは。enechainで働いている takurinton です。 これまでのenechainのデザインシステムではdark modeの提供はしておらず、プロダクト側で必要に応じて状態とデザイントークンを保持した上で切り替えてもらうという方式をとっていました。 しかし、事業拡大やプロダクト側からの要望によりdark modeのデザイントークンをデザインシステム側で管理し、chakra-uiのColorModeProviderを用いて切り替える方法を提供することにしました。 今回は、その移行の過程と方法について書きます。 デザイントークンについて 移行の手法 将来的に light/dark 以外の種類のトークンも定義する可能性がある 古いトークンはstylesで、新しいトークンはvariablesで管理している light モードしか使わないプロダクトは特別な手順なく移行可能にしたい デ
はじめに なぜ対応したか ダークモード対応への道 カラーの明度コントロールにおける透明・不透明について 透明度に関して用語の整理 enechainデザインシステムとしての方針 環境のイメージとエレベーション カラートークンの設計 調整で大変だった点 あるコンポーネントでは良さそうだが、別のコンポーネントだと破綻する Figmaの静的なデザイン上では気づきにくい状態変化 エレベーションの見た目の差をシャドウに頼っているとダークモードで同化する ダークモード内での全体的なコントラスト 色の特性、その色の標準的な明度感・イメージ 実際にプロダクトで提供した まとめ はじめに enechainプロダクトデザインデスクのマネージャーの近藤(@add_kk)です。 先週、ローンチしたばかりの電力の卸取引をオンラインでリアルタイムに自動約定するマーケットプレイス「eSquare Live」についての記事
はじめに コンポーネントライブラリ管理の課題 デザインと実装の乖離 見た目における乖離 プロパティの乖離 コンポーネントやバリエーションの増加による管理の負担 ガイドラインの浸透 さいごに はじめに enechainプロダクトデザインデスクの伊藤です。現在、私は複数プロダクトのデザインを行いながら、デザインシステムの改善にも携わっています。 今回は、デザインシステムにおけるコンポーネントライブラリの管理と、その改善についてご紹介します。 コンポーネントライブラリ管理の課題 enechainのデザインシステムではガイドライン作成やダークモード対応などの改善を進めてきました。プロダクトのユースケースとして必要なコンポーネントも徐々に網羅されつつありますが、新たに3つの課題が浮上しました。 デザインと実装の乖離があった 新規コンポーネントやバリエーションの増加に伴い、管理の負担が増した ガイドラ
はじめに 背景 eSqaure LiveのUIデザイン デザイン基本方針 カスタマイズ性 モードレスな注文UI ダークモードの提供 グッドデザイン賞への応募と受賞 まとめ はじめに enechainプロダクトデザインデスクのマネージャーの近藤(@add_kk)です。 10月9日にenechainでは電力の卸取引をオンラインでリアルタイムに自動約定するマーケットプレイス「eSquare Live」をローンチしました。これまで提供していたeSquareを大幅に進化させた「即時=Live」なオンラインプラットフォームです。発電事業者や電力小売業者、トレーダーが現物から先物までを取引可能です。 そして、このプロダクトが2024年グッドデザイン賞を受賞しました。 2024 グッドデザイン賞 エネルギー卸取引マーケットプレイス eSquare Live 審査員の評価コメント 本サービスは、変動の激しい
はじめに enechainでのQA業務 enechainの目指すQAとは 今後の展望 最後に はじめに はじめまして。enechainのQAエンジニアのtaise-です。 enechainは電力や環境価値といったエネルギーのオンラインマーケットプレイスを運営する会社です。私は、電力取引を仲介する社内のブローカーのブローキング業務を支援する社内ツールのQAを担当しています。 enechainにQAチームが発足して約3年が経ち、会社が急成長を遂げる中でQAチームの形もそれに合わせて常に変化し続けており、現在は複数同時並行で開発・運用されている各プロダクトを、QAエンジニアがそれぞれ1名専任で担当するチーム体制となっています。 この記事では、私の担当プロダクトにおけるQA業務と、そこで得た成果や課題について紹介します。 プロダクト専任体制のQAエンジニアが業務の中でどう立ち回り、どんな価値貢献が
忙しい人向けのまとめ ドメイン知識ってどうやったら早く身につくの? ドメイン知識習得までの実践例 インプットにおいて意識したこと 各知識のインプットの進め方:実践例 業界のエコシステム 業界のトレンド 担当プロダクトのミッション 3C分析・ユーザージャーニー・アウトカムが出るまでの変数 さいごに enechainでブローカー向けプロダクトとクリアリングプロダクトのPdMをしている加藤です。 さて、会社選びの観点で、ドメイン知識がない領域に飛び込むのが怖いと思っている方は多いのではないかと想像しています。一方で、業務理解が難しいドメインに身を置く会社の中の人も、そうした方が活躍するにどんなオンボーディングプログラムや体制を用意すれば良いのか困っているのではないかとも思います。 そんな方の悩みに少しでも寄り添えればと思い、領域未経験・ドメイン知識がない状態で飛び込み約4ヶ月が経った身から、オン
はじめに enechainデザインシステムについて デジタル庁デザインシステム 特徴 Figmaファイル Webサイト GitHub Primer 特徴 Figmaファイル Webサイト Ameba Spindle 特徴 Figmaファイル Webサイト 各デザインシステムの構成まとめ enechainへの反映 Notionでのガイドライン まとめ はじめに こんにちは、デザイナーの渡邉と申します。私はenechainの業務委託メンバーとして、enechainの複数プロダクトを支えるデザインシステムの改善に携わっています。 この記事では、利用しやすいデザインシステムへと改善していく上でデザインチームが取り組んでいたことをまとめます。 enechainデザインシステムについて enechainでは10個以上のマルチプロダクトを開発・運用しており、デザイナーは各プロダクトでUIデザインを担当し
JSConf JP 2024 の概要 開催日 開催地 さいごに 当社の紹介 enechainで技術広報をしているかがわです。 enechainはこの度、JSConf JP 2024にPremium Sponsorとして協賛します。 jsconf.jpは、Japan Node.js Associationが日本で主催するJavaScriptのイベントです。今回は日本で5回目の開催となります。日本のWeb開発者と国際的なWeb開発者をつなぐ架け橋となることを目指し、開催されています。 enechainからも数名のメンバーが参加し、ブース出展も行います。当日は現地で交流できることを楽しみにしています! JSConf JP 2024 の概要 jsconf.jp 開催日 2024/11/23 開催地 九段坂上KSビル 東京都千代田区九段北1-14-6 さいごに ehechainは「Building
はじめに はじめまして。enechainでDevRelをしているかがわです。 電力取引におけるリスクを管理するeScanというプロダクトのEMと兼任で、DevRelの活動をしています。 enechainではこれまで、TechBlogの運用やテックカンファレンスへのスポンサード、テックイベントの開催や採用広報などに取り組んできました。 数ヶ月前から私も技術広報活動に関わっていますが、過去の経験上活動する人や決裁者の認識を揃える重要性を感じていたので、各種活動の前提となる考え方を定義し揃えることにしました。 今回、社内で認識を揃えたenechainにおけるDevRelの定義について、記事としてまとめました。 enechainのDevRelに対する考え方を知っていただいたり、これから社内でDevRelを立ち上げる際の参考としていただいたり、本記事を通して何かしらの気づきや知見を届けられていたら嬉
はじめに 背景と課題 システム概要 ワークフローの詳細 動画文字起こし (Gemini, GPT-4o) 文字起こしの議題単位の分割 (Claude 3.5 Sonnet) 議題単位での要約作成 (Claude 3.5 Sonnet, GPT-4o) 出力 実装上の工夫と課題 結果と今後の展望 おわりに はじめに こんにちは。enechainで統計・機械学習モデルの構築やLLM(大規模言語モデル)の活用推進を担当している@udon_tempuraです。 近年、GoogleのGeminiなど生成AIの発展が目覚ましく、多くの企業がこれらの技術を業務に取り入れようとしています。 私たちenechainも例外ではなく、積極的にLLMの活用を進めています。 今回はその活用例の1つとして、複数のLLMを使い分けて構築した「会議動画の要約作成ワークフロー」についてご紹介します。 このワークフローでは会
はじめに 背景 やりたいこと Why MSW? 導入手順 詰まったこと defaultのtimeout設定時間が短い CIで落ちた時の検証方法がわからない 認証後のストレージの状態が入ってこない 今後の展望 おわりに はじめに enechainでフロントエンドエンジニアをしている@Shunya078です! 自分の所属するGXデスクでは『日本気候取引所 - Japan Climate Exchange』(以下JCEX)のサービス開発を行っており、その中でReactを使用したフロントエンドの開発を担当しています。 リグレッションテストは運用を考えると、設計から導入した後、どう管理していくかまで検討する点が多く存在します。 JCEXは去年の年末にリリースされたばかりのサービスで、まだブラウザまで含めたリグレッション相当になるテストレイヤーが導入できておらず、存在しませんでした。 今回は新たに自チ
はじめに こんにちは。enechainのPlatform EngineeringチームSoftware Engineerの soma00333 です。 enechainは電力の卸取引や環境価値の取引の機会を提供するマーケットプレイスを運営する会社で、インフラ基盤としてGKEを採用しています。信頼性が非常に大切なドメインで、SREの力が欠かせないビジネスを展開しています。 この度、enechainはSREチームのさらなる強化を目指し、SRE as a Serviceを提供する 株式会社Topotal様 にご支援いただいて新たに2名のエンジニアを迎えました。 SREチームを強化するにあたり、「採用を頑張る」「内部で育てる」など手段は様々です。 本記事では、「外部会社(Topotal様)との協力」という手段がSREチーム・開発チーム全体にどのような効果をもたらしているかを紹介します。 SREチー
はじめに 旧BigQuery構成と課題点 新GCP Project/BigQuery構成 承認済みビューの設定 結果 終わりに はじめに enechainのデータプラットフォームデスクで2年目エンジニアをしている菱沼です。 本記事では、社内ユーザに対する閲覧権限をBigQueryの承認済みビューを用いて改善した例をご紹介します。 事業規模の拡大に伴い、各種データへのアクセス権限整備の重要性が増し、BigQuery上のデータも厳密な権限管理が求められるようになりました。 今回は、我々が抱えていたBigQueryアーキテクチャの権限管理上の課題と、その課題に対する取り組みについて具体的にご紹介します。 ぜひ最後までお付き合いください! 旧BigQuery構成と課題点 データプラットフォームデスクで構築しているデータ基盤の1つに、 外部データソースから取得したデータを収集・蓄積するためのETLパ
はじめに なぜprotobufに認可設定を組み込もうと思ったのか? 前提知識 protobufのプラグインの仕組み protocコマンドのインターフェース 実装 今回のお題 プラグインの開発 拡張プラグインの実行 生成したmapを使った認可処理 最後に はじめに こんにちは、enechainのApplication Platform Deskでエンジニアをしているendoです。 Application Platform Deskは、全プロダクトが横断で抱える課題を解決するチームです。 ※「開発者体験の向上を目指す」という意味ではPlatform Engineeringチームと近い位置づけですが、もう少しアプリケーション開発寄りの領域を担当しています。 私達のチームでは、protobufで自動生成したGolangコードを使ってAPI Endpoint毎にロール単位の認可処理ができる仕組みを構
こんにちは、6/1にenechainに入社したPdMの加藤です。 突然ですが、「進撃の巨人」って面白い漫画ですよね。こうした少年漫画の主人公は大体が特別な才能と運を持っていて、それを活かして友情と努力で困難を乗り越えていくストーリーが描かれます。 一方で、リアルな自分を見つめると、特別な才能も、運もないです。でも、日々何者かになりたくて葛藤しながら生きています。 この記事は、ちょっとでも大志を抱いているが、イマイチ未知のドメインへ踏み込めない方に向けた入社エントリという名のポエムです。そんな方の背中を少しでも押すことができ、世の中に挑戦者が1人でも増えれば嬉しいです。 エネルギードメインとは全く縁がなかった身、かつ特に天賦の才もない身で、なぜPdMとしてenechainに飛び込んだのか、実際に働いてみてどう感じているのか、エネルギー初心者の視点からしたためます。 enechainってどんな
はじめに 技術スタック eScanチームにおけるGraphQLの使い方 開発フローの工夫 N+1問題の対応と注意点 エラーハンドリングの工夫 モニタリングの工夫 ドキュメンテーションを必須化するための工夫 その他の取り組み 振り返り 良かった点 難しかった点 今後の展望 最後に はじめに こんにちは、enechainでソフトウェアエンジニアをしている小沢です。 私が所属しているチーム(以降、eScanチーム)では、eScanという電力会社向けのリスクマネジメントシステムを開発・運用しており、その中でGraphQLを採用しています。すでにGraphQLを採用するメリット・デメリットについて様々なところで語られていますが、eScanチームでもオーバーフェッチが解消できる点、1リクエストで必要なデータをフェッチできる点などのメリットを享受するために採用しています。 今回は実際にGraphQLを採
はじめに なぜ民主化か 目安箱の設置と対応件数 デザインシステム株主総会の開催 第一回:前期の事業報告と今期の事業計画について 第二回:プロダクトAで先行して実装した新・共通UIと今取り組むべきアクセシビリティ 第三回:プロダクトBで取り組んでいたカレンダーコンポーネントのFIXまでのプロセス振り返りとユーザー像をどうイメージするか デザインシステム名称の全社募集 まとめ はじめに enechainプロダクトデザインデスクのマネージャーの近藤(@add_kk)です。 1つ前のtakurintonの記事『デザインシステムの開発者体験向上の試み』に続いて、弊社のデザインシステムでの取り組みについて紹介させていただきます。 enechainでは会社全体のOKR *1 に基づき、4ヶ月サイクルで各組織がOKRを立てています。デザインシステムチームは専任メンバーがいない有志のチームであるため、OKR
はじめに 今回書く開発者体験について 具体的な試み eslint pluginによるコーディング規約の明文化 Notionへのリソース集約 デザイントークンと型定義 おわりに はじめに こんにちは。enechainで働いている takurinton です。 enechainではさまざまな開発者体験向上の取り組みが試行されていますが、今回は自分が主に見ているデザインシステムにフォーカスして記事を書こうと思います。 弊社のデザインシステムに関しては、 @Shunya078 の なぜ我々はデザインシステムを創るのか? を読んでいただくと背景がご理解いただけると思います。 今回書く開発者体験について 開発者体験の定義についてはさまざまな解釈があると思いますが、今回は以下の3つのトピックに絞って紹介します。 eslint pluginによるコーディング規約の明文化 Notionへのリソース集約 デザ
次のページ
このページを最初にブックマークしてみませんか?
『techblog.enechain.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く