サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ストレッチ
tech.visasq.com
こんにちは、プラットフォーム開発グループ SREチームの西川 (@taxin_tt) です。 皆さんTerraform使ってますか? 弊社では既存サービスのマイクロサービス化を進めており、GCPベースのインフラはTerraformを利用して整備するようにしています。 一方で、サービス数の増加などに比例してtfファイルのコード量も増えていき、ディレクトリ構成や個別のリソースの定義などマイクロサービスのインフラ整備において負担になる部分があり、昨年末からSREチーム主導でリファクタリングを行っています。 今回は、そのリファクタリングの背景や進め方についてお話しできればと思います。 (本記事は、Terraform v1.3系を前提にしています。) リファクタリング後のTerraformのディレクトリ構成は下記をベースにしているので、下記の記事も合わせてどうぞ。 tech.visasq.com リ
こんにちは!フルサポート開発チーム兼 Embedded SRE の高畑(Sorarinu (@int_sorarinu) / Twitter)です。 最近、スノーボードだけでなくキャンプにも手を出してしまった結果、どんどん沼にハマっていっている私ですが皆さまいかがお過ごしでしょうか。 先日のシルバーウィークで 3 連休それぞれキャンプに出かけていたのですが、両日とも台風の影響で生憎の大雨となり雨濡れ耐性が格段に向上してしまいました。 さて今回は、弊社でも利用している Terraform のディレクトリ構成について、改めてベストプラクティスってなんだっけというものを考えてみたのでご紹介いたします。 事の発端 今ではマイクロサービス化も進み、各サービスそれぞれで Terraform のコードが増えてきている状態となっています。 既存の Terraform では変数( creation フラグ)
こんにちは。SREチームでリーダーをやっている木村です。 座右の名は「明日自分が交通事故にあっても、システムの運用を滞りなくする」です。 2021年から SRE 責任者の役割をしていますが、その中でいわゆるマネジメントという業務を行っています。 本日は、この答えのないマネジメントについて少しお話をさせていただけたら。と思っています。 そもそもマネジメントとは何をすれば良いものか? 初めてマネジメント業務をすると大体の人がこの疑問を最初考えると思いますが、 大きく分けると2つに分類されるかと思います。 成果を上げるための仕組みを作る 業務の割り振りや、メンバーの成長するための仕組み等を整えたりすること リーダーシップ その場に集まっているメンバーに目標やビジョンを共有し、周りのモチベーションを高めチームの成果が メンバー = 1 のエンゲージメントではなく、 メンバー = 1.xx にするた
こんにちは。SREチームでリーダーをやっている木村です。 座右の名は「明日自分が交通事故にあっても、システムの運用を滞りなくする」です。 先日、ビザスク SRE チームでオフサイト (半日程時間をとって集中して、テーマに関して議論する時間です) を行って「次の半年でやりたいこと」を議論しましたので、 こちらの内容を生々しくお伝えしていきたいと思います。 なぜオフサイトを開いたのか? 日々の業務で SRE チームは同期・非同期的な積極的にコミュニケーションを取りながら日々の仕事をしていますが、 日々の中だとどうしても目の前の課題にフォーカスした内容になり、中長期的なちょっと遠い目線の話しは後回しになりがちです。 とはいえ中長期的にどこに目指すのか?の目線あわせをしないと、意思疎通や認識齟齬が発生をして「こう思っていた」や「そうだと思っていた」 という思い込みによる無駄が発生します。 そのよう
はじめに こんにちは。SREチームの西川です。 現在、ビザスクではサービスのインフラ基盤のリプレイスに伴い、Sentry+Datadogを用いたサービス監視体制を整備しています。 その中で、継続的に抱えていた「運用の属人化」という課題に対して、ツール面からアプローチできないかという思いがありました。 今回は、「運用の属人化」に対する課題意識、ツール利用の観点から属人化へのアプローチについてまとめます。 課題意識 ビザスクでのサービス監視系の運用作業 (e.g. エラー対応) に関しては、各サービスチーム+SREチームで実施しています。 上記の運用作業を行う中で、下記のような課題が挙がっていました。 エラー対応などの運用作業が特定のメンバーに集中している社内からの問い合わせ・事象調査の際に、複数のツールの使い分けが必要になったり、調査に必要な情報にリーチしづらいケースがあるエラー対応の過去ロ
アドバイザー/lite開発チーム フロントエンドエンジニアの小柳(@mascii_k)です。 はじめに 弊社サービス「ビザスクlite」では、Vue 2.6 向けのプラグイン @vue/composition-api を 2020/02 から導入しています。 tech.visasq.com ビザスクliteでの導入実績とノウハウ蓄積の結果、社内で利用している管理画面のフロントエンド(Vue 2.6)環境にも @vue/composition-api を導入することになりましたが、当時の判断で古いバージョンのものを導入してしまいました。 しくじりの経緯 2020/09 当時の最新バージョンであった @vue/composition-api 1.0.0-beta.14 を導入しようとしたところ、vue 本体のバージョンが 2.6.10 (当時の最新バージョンは 2.6.12)だったため、コンパ
エンジニア採用広報担当のぐりこ ( @glico800 ) です。 前回の基本編に続き、今回も最近開発チームで試しに使っている Gather.town について、はじめて触るときに押さえておきたい基本操作をまとめてみました。 今回は「初級ビルド編」として、自席の周りの飾り付けや間違えて消してしまった Object の復元について解説したいと思います。 ※今回はブラウザ版を前提に解説を進めるので、アプリ版をご利用の方は若干ボタンの位置などが違うかもしれません。予めご了承ください。 ※本記事に書かれている内容は 2022/03/16 時点での仕様に基づいて書かれています。最新の情報は 公式ページ を参照してください。 2つのビルド方法 スペース内でのビルド スペース内でのビルドでは、Object を自由に配置することができます。 こちらは Build 権限が不要なため、誰でもビルド可能。 ただ
こんにちは、ビザスクアドバイザー開発チーム、フロントエンドエンジニアの山元(@yamagen0915)です。 はじめに 弊社にはいくつかのフロントエンド環境があり、その中には TypeScript の strict mode が有効でない環境もあり、それらを strict mode が有効な環境へ移行を進めようとしています。 しかし移行と並行して新規開発も行われるため、strict mode でエラーとなるコードを増やさないようにする必要があることと、各チームのメンバーに strict mode な環境に慣れてもらう必要がありました。 そこで vue-tsc を使ってデプロイには影響を与えずに開発時のみ strict mode が有効な環境で開発ができるようにし始めたのでその方法を紹介したいと思います。 vue-tsc とは vue-tsc とは VSCode の Vue 向け Exten
ビザスクlite事業部フロントエンドエンジニアの小柳(@mascii_k)です。 弊社では Vue.js 2.6 を利用していますが、AngularJS や jQuery などで実装された古いフロントエンド実装を Vue.js でリプレイスしている状況です。 そんな状況の中、ビザスクlite の「事前相談画面」のデザインリニューアルと同時にフロントエンド実装もリプレイスすることとなり、フロントエンド設計・実装を担当することになりました。 今回は「事前相談画面」のリプレイスで Vue Composition API を導入するに至った経緯やモチベーションを紹介いたします。 デザインリニューアルの経緯について、デザイナーの長岡の記事(UI/UX改善!事前相談リニューアルの歩み)もぜひご覧ください。 事前相談画面について 事前相談画面とは、ビザスクのアドバイザーと依頼者がスポットコンサルを実施す
ビザスクlite事業部フロントエンドエンジニアの小柳(@mascii_k)です。 弊社ではモダンなフロントエンド開発手法にシフトしつつあり、Figma で構築したデザインシステム上でデザインし、それに対応するものを Vue.js 2.x 系で実装する開発がスタンダードとなっております。 現在 Vue.js 3.0.0 の正式リリースが間近とされていて、弊社としても積極的にマイグレーションをしていきたいと思っております。 今回は Vue 2.x 系向けに作られた UI コンポーネントの Vue 3.0 系へのマイグレーションに向けた検証結果を公開します。 弊社の UI コンポーネント事情 弊社では Vuetify や Element UI といったコンポーネントフレームワークには依存せず、極力スクラッチで UI コンポーネントを作って開発しています。 Figma を活用して管理されているデザ
こんにちは! 2020年2月からSREチームにJoinしました木村です! 仕事をする上での座右の銘は「明日交通事故にあってもシステムと仕事を回せるようにすること」です。 基本に戻って始める。と表題では書いていますが、私元々はAWS職人でGCPに本格的にコミットしてからまだ3ヶ月位です! なのでヒィヒィ?言いながらGCPのキャッチアップに努めているわけですが今回は過去にAWSで得たInfrastructure as Codeの知識とビザスクに入社してキャッチアップで培ったGCPの知識を元に基本に戻って始めるGCPのInfrastructure as Code再入門ということで書かせていただきます。 前回はAnsibleのplaybookの実践的な使い方迄を説明しましたので、今回はAnsibleをProvisioningしたOSImageをPackerで作成する所までやっていきたいとおもいます
こんにちは! 2020年2月からSREチームにJoinしました木村です! 仕事をする上での座右の銘は「明日交通事故にあってもシステムと仕事を回せるようにすること」です。 基本に戻って始める。と表題では書いていますが、私元々はAWS職人でGCPに本格的にコミットしてからまだ3ヶ月位です! なのでヒィヒィ?言いながらGCPのキャッチアップに努めているわけですが今回は過去にAWSで得たInfrastructure as Codeの知識とビザスクに入社してキャッチアップで培ったGCPの知識を元に基本に戻って始めるGCPのInfrastructure as Code再入門ということで書かせていただきます。 前回はAnsibleの基本的な用語の説明から初回のAnsibleの実行迄を説明しましたので今回はAnsibleを使った実際のPlaybook,taskの書き方等を説明していきます。 その他のGCP
こんにちは! 2020年2月からSREチームにJoinしました木村です! 仕事をする上での座右の銘は「明日交通事故にあってもシステムと仕事を回せるようにすること」です。 基本に戻って始める。と表題では書いていますが、私元々はAWS職人でGCPに本格的にコミットしてからまだ3ヶ月位です! なのでヒィヒィ?言いながらGCPのキャッチアップに努めているわけですが今回は過去にAWSで得たInfrastructure as Codeの知識とビザスクに入社してキャッチアップで培ったGCPの知識を元に基本に戻って始めるGCPのInfrastructure as Code再入門ということで書かせていただきます。 前回はGCPにCompute Engineのインスタンスとサービスアカウント作成までできましたので次はAnsibleを使って作成したインスタンスに対してProvisionを実行していきたいと思いま
こんにちは! 2020年2月からSREチームにJoinしました木村です! 仕事をする上での座右の銘は「明日交通事故にあってもシステムと仕事を回せるようにすること」です。 基本に戻って始める。と表題では書いていますが、私元々はAWS職人でGCPに本格的にコミットしてからまだ3ヶ月位です! なのでヒィヒィ?言いながらGCPのキャッチアップに努めているわけですが今回は過去にAWSで得たInfrastructure as Codeの知識とビザスクに入社してキャッチアップで培ったGCPの知識を元に基本に戻って始めるGCPのInfrastructure as Code再入門ということで書かせていただきます。 尚実際に書き始めたら量が膨大になってしまったのでいくつかパートに分けて 書いていきたいと思っております。 今回やること GCPのCompute Engineをスコープとして Terraformを使
はじめまして!11月よりビザスクにジョインした渡部と申します。 現在UXチームに所属して、Visasqの使い勝手の向上に日々奮闘しております。 さて、本投稿ではAngular2の簡単なTIPsをご紹介します。 こちらの画像は今回の内容を元に実際のサービスに組み込んだものになります。 私自身Angular2を使うのは初めてで、勉強しながら覚えたことを記載しています。 拙い部分もあるかと思いますがご容赦くださいませ。 ビザスクでのAngular2 実はビザスクでのAngular2の利用はまだ一部に留まっています。 もともとはAngularJS(いわゆる1.x系)をfrontendのフレームワークとして採用していて、ある機能をリニューアルするにあたり新規実装部分をAngular2で実装した、というのが経緯のようです。 1.x系ではなく2.x系を採用した理由や、移行について考えたことなど、興味深い
目的とツールから考えるデータ分析基盤の選び方について by MonotaRO TechTalk analyticsPyDatapythonデータ分析 二回目の登場となります. ビザスクでデータエンジニア兼インフラ等を担当しています, 中川と申します. Python・エンジニア界隈では「野球の人」と呼ばれています. 詳しくは「Python 野球」で検索してみて下さい. 本エントリーでは, 目的とツールから考える,データ分析基盤の選び方 ビザスクにおける活用事例 について,先日株式会社MonotaRO(モノタロウ)様主催のIT勉強会「MonotaRO TechTalk」でお話させて頂いた内容を元に紹介します. おしながき [資料]Py “Baseball” Data入門〜サービスを支えるデータ分析基盤 データ分析の目的とツールの選び方 ビザスクにおける,データ分析ツール まとめ&MonotaR
Pythonには独特の仕様がいくつかあります。 その中には、他のLLを習得している方ほど気が付きにくく、認識を誤りやすいものがあります。 そこで、Pythonで頻繁に用いる仕様の中から、意外と知る機会の少ない仕様を七つ取り上げます。 Pythonって愛嬌がありますよね はじめまして、寺坂です。 ビザスクのエンジニアです。 業務的にはビザスクのエンジニアの例に漏れず、主にPythonと{ECMA,Type}Scriptを喋ります。 私はLinuxユーザーであることも相まって2006年頃に趣味としてPythonを触り始めたときから、 なかなかに面倒くさいこの言語に日々愛嬌を感じずにはいられません。 とはいえ業務で書くとなると愛嬌では済まされない部分もあります。 ビザスクの開発チームでは、管理しているコードのうちプログラミング言語に限れば60%が、そこから{ECMA,Type}Scriptを除く
エンジニア勉強会でChainerとKerasの比較をしてみました pythonエンジニア勉強会機械学習 はじめに こんにちは、新卒1号エンジニアの村上です。 ビザスクでは去年の7月頃から毎週水曜日にエンジニア勉強会(読書会)をやっています。当初は1冊本を選んで、章ごとに担当を決めて読書会形式で行っていました。(ex.『エキスパートPython』『リーダブルコード』) ところが、最近になって「たまには手を動かして新しい技術に触れることもしたいよね!」という想いから、個人の興味がある分野でビザスクに還元できそうな内容をプレゼンするという形式になりました。 今回は、その先々週の勉強会で発表した内容になります。 おしながき ChainerとKerasでやったこと スライド スライドの補足 まとめ ChainerとKerasでやったこと 分類問題を題材に、シンプルなニューラルネットワークをChain
最近子供と風呂に入っては「肩まで浸かって指で6bit(63)まで数えよう」と教えています。 2進数なら両手で1023まで数えられて便利なんじゃないかと思ってます。CTOの花村です。 少し前に待鳥さんにグラフデータベースの存在を教えてもらいました。 学生時代に数学系研究室おり、ちょっとだけグラフ理論をかじった経験があり、 興味があったので実際にグラフ構造のデータを入れてつかってみました。 このエントリーは実際にNeo4jにデータを投入してみるところまでやったというものであり、 具体的な環境構築やチューニングの話はしておりませんのであらかじめご了承ください。 Neo4jに関して グラフ構造のデータの扱いに優れたグラフデータベースで、 関連性に特化した検索で優位性があるとのこと。 RDBでリレーションを貼る構成に比べると、高いスケーラビリティを実現しています。 グラフデータを扱うのであれば、現状
こんにちは、このブログのデザインを担当した、新卒デザイナーの長岡です。 せっかく作ったのに、デザイナーの記事が無いなんて…と嘆いていたら、デザイナー編の第一弾を書かせていただけることになりました。 よろしくおねがいします。 ビザスクでは、各チームが定期的に勉強会を行っています。 つい先々月ほどからデザイナー陣も「UI/UX勉強会」と題した勉強会を開催しはじめました。 尚、ビザスクのデザイナーは2人しか居ないため、勉強会はデザイナー+CEO+CTOの豪華メンバーで執り行っております。 今回はその第一回として開催された勉強会のレポートをお届けします。 お品書き はじめに 本の概要 議論してみた before & after まとめ はじめに 勉強会の形式について 勉強会は以下のような流れで開催されます。 ちなみに、エンジニア勉強会も同じ流れで行っています。 勉強会に使う教科書を決める 週ごとに
Re:dashとDocker for Macでらくらく分析・可視化環境構築 analyticsdockerpythonRedash ビザスク開発者ブログ第一弾記事を書かせてもらうことになりました、 @shinyorke(Shinichi Nakagawa)ともうします. 我々ビザスク(https://service.visasq.com)の開発チームでは、データに基づいた客観的な観点をベースに施策を実施しています. 現状はエンジニアがGoogle SpreadsheetsやGoogle Apps Script(社内では「ガス(GAS)」と呼ばれています)、Slackを駆使して数値の可視化や共有をしていますが、 ひとつの画面、いわゆる「ダッシュボード」で分析・可視化を行ってチーム全員で共有しよう! 将来的にはビジネス側のメンバーにも数値出しや可視化をしてもらおう! という機運が高まり、分析・
このページを最初にブックマークしてみませんか?
『VisasQ Dev Blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く