Zeals TECH BLOG

チャットボットでネットにおもてなし革命を起こす、チャットコマース『Zeals』を開発する株式会社Zealsの技術やエンジニア文化について発信します。

Kubernetesにおけるmanifestファイル, imageの管理について

f:id:zeals-engineer:20190603114959p:plain

こんにちは、CTOの島田です。

弊社サービスであるfanpでは、定期バッチ含む全サービスがGKE上で起動しています。

今回は Kubernetesのmanifestファイルやイメージを効率よく管理するための取り組みを紹介したいと思います。 Kubernetesを本番運用しているところだと基本的なことが中心の内容かと思いますが、お付き合いいただけますと幸いです。

  • Kubernetes化にあたって意識したこと
    • 環境の差異, manifestの再利用性
    • CD(Continuous Delivery)の効率化
  • ZEALSでの取り組み
    • container registry専用のprojectを作成した
    • manifest file専用のレポジトリを作成した
    • Cloud Buildで継続的デリバリ
  • さいごに

Kubernetes化にあたって意識したこと

環境の差異, manifestの再利用性

  • ステージング環境とプロダクション環境でそれぞれ異なる環境変数が定義されている
  • ステージング環境はプロダクション環境よりも少ないマシンリソースで運用したい

一方で、

  • 同じようなmanifest fileを大量に書きたくない
  • 別サービスの同環境で同じsecretを使いまわしたい

という思いがありました。

後者はcloud_sql_proxyのコンテナ起動に使用するJSONデータなどが該当するかと思います。
(複数サーバーで同一DBを参照する場合)

CD(Continuous Delivery)の効率化

数分で完了するデプロイ、大して複雑でないパイプラインを構築する上で、極力シンプルなCDツールを目指すことにしました。
CDツールを自分たちで構築/運用した場合, 定期的なバージョンアップも行わなければいけなかったりと手間がかかってしまいます。

また, 未だにKubernetesにおいてCDツールのデファクトは存在しないと考えています。
そのため、ツール依存の設定が増えてJenkinsおじさん的な事象が発生するのは避けかったという意図もありました。 

ZEALSでの取り組み

container registry専用のprojectを作成した

アプリケーションのコードを元にbuildしたimageを置くためだけのprojectです。
このcontainer registryでは環境依存のものは配置せず、再利用可能なイメージのみを設置します。

GCPは権限の設定がとても楽です。
Cloud Buildで別projectにあるContainer Registryからimageをpullするのも, Cloud Buildのサービスアカウントをcontainer registryのあるprojectに追加し, ストレージ オブジェクト閲覧者を付与したら動作します。

manifest file専用のレポジトリを作成した

全サービスのmanifest fileを1つのレポジトリに集約させました。
特徴は以下の通りです。

ディレクトリはざっくりこんな感じになりました。

.
├── bin/
│   └── gen_kustomize.sh
├── service1/
│   ├── base/
│   │   ├── deployment.yaml
│   │   ├── kustomization.yaml
│   │   └── service.yaml
│   └── overlays/
│       ├── fanp-prd/
│       │   ├── deployment.yaml
│       │   └── kustomization.yaml
│       └── fanp-stg/
│           ├── deployment.yaml
│           └── kustomization.yaml
├── service2/
│   ├── base/
│   │   ├── deployment.yaml
│   │   ├── kustomization.yaml
│   │   └── service.yaml
│   └── overlays/
│       ├── fanp-prd/
│       │   ├── deployment.yaml
│       │   └── kustomization.yaml
│       └── fanp-stg/
│           ├── deployment.yaml
│           └── kustomization.yaml
├── secrets/
│   ├── prd/
│   │   ├── kustomization.yaml
│   │   ├── secret-hogehoge.yaml
│   ├── stg/
│   │   ├── kustomization.yaml

Cloud Buildで継続的デリバリ

結果的にCloud Buildを使用しました。
Cloud Buildの使いところは、アプリケーションのimage build各環境へのデプロイ になります。 デプロイまでの流れは以下です。

  1. 各アプリケーションでgit tagを打ち、リモートリポジトリにtagをpush
  2. container registry専用のprojectにあるCloud Buildが発火, imageをbuild
  3. manifest専用レポジトリでimage tagを編集, deployブランチへプルリクを出す
  4. 3.のプルリクがマージされたら任意のprojectCloud Buildが発火しデプロイ

ZEALSではstgへのdeployブランチにマージされたらステージングのprojectのCloud Buildが発火、masterへマージされたらプロダクションのCloud Buildが発火し、デプロイが開始するようになっています。

さいごに

動きました!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

続きを読む

ZEALS第2回エンジニア開発合宿に行ってきました!!@三浦海岸

f:id:zeals-engineer:20190521171954j:plain

皆さんこんにちは!
サーバーサイドエンジニアの阿久津です!

5/11(土)〜5/12(日)の2日間、ZEALSで2回目となる「 エンジニア合宿 」に参加しました。
私は今回から初参加だったのですが、今回の合宿の様子を紹介させていただきます。

  • 概要
    • 開発合宿の目的
    • 合宿場所
    • 開発テーマ
  • タイムテーブル
    • 5月11日(土) 1日目
    • 5月12日(日) 2日目
  • 開発の様子
    • 1日目
    • 2日目
      • ダイエットアプリ
      • 顔認識
  • 良かったこと・反省
    • 良かったこと
    • 反省
  • 最後に

概要

開発合宿の目的

今回の開発の目的は以下3点です。

  • 普段の業務で触れることのできない技術に触れることで、組織全体の技術スタックの幅を増やす
  • 非日常でのコミュニケーションを取り、メンバーの結束を強くする
  • 今後、個人で勉強を進めていくきっかけを掴んでもらう

技術力の底上げはもちろんですが、普段できないような深いコミュニケーションも1つの大きな目的でした。

合宿場所

合宿の場所はモチベーションを左右する大切な要素ですよね!

社内の事前アンケートの結果、オフィスからのアクセス1時間以内の近場ということでマホロバ・マインズ三浦さんに決定しました!

開発は室内なのでどこでもよい派だったのですが、考え改めました。。
綺麗な海を間近で見ることができる環境最高!

f:id:zeals-engineer:20190521172338j:plain

開発テーマ

前回の開発合宿では、皆が持ち寄ったテーマをもとにチームに分かれて行うメンバーが多かったのですが、今回は以下のゴールのいずれかを満たせればテーマは自由でした。

  1. プロダクトに跳ね返る
  2. 外部に情報発信できる
  3. 技術の有用性を伝えられる

合宿に参加するにあたり、各自テーマを決めて合宿前に事前に共有してから開発をスタートさせます。

開発スタイルは個人でもくもくスタイルでも、チームでワイワイスタイルでも特に制限はありません。
各メンバーが一番開発しやすいスタイルで開発します。

今回のテーマは自由だったこともあり、バラエティーに富んでいましたが、大きく分けるとこんな感じでした。

  • 社内のアセット整理
  • これから学ぼうとしている言語を使ったアプリ開発
  • 社内のプロダクトに活きる新しい技術の深掘り
  • 開発の効率化ツールの導入

私自身は画像認識に前々から興味があったので、OpenCVを使った顔認識とモーションディテクションにチャレンジしてみました。

タイムテーブル

5月11日(土) 1日目

  • 12:00〜: 現地集合
  • 13:00〜:オープニング開発スタート
  • 19:30〜: 夕食
  • 21:00〜: 自由行動

5月12日(日) 2日目

  • 8:00〜: 朝食
  • 9:00〜: 開発スタート
  • 11:00〜: アウトプット発表
  • 13:00〜: 現地解散

開発の様子

1日目

開発場所はホテルの9階、眺めはバッチリです。 f:id:zeals-engineer:20190521172831j:plain

テーマは事前に決めていたため、簡単なオープニング後すぐに開発スタートです。 f:id:zeals-engineer:20190521172858j:plain

各々好きな場所で開発中。海を見ながらの開発は最高に気分がいいですね。 f:id:zeals-engineer:20190521172928j:plain

19:30に中間報告感を行い、待ちに待った夕食タイムです f:id:zeals-engineer:20190521172954j:plain

食後はフリータイムです。近場の海を散策したり、持ち寄ったゲームで楽しんたり、引き続き開発を楽しんだりしました。チームメンバーの距離感が一気に縮まる貴重な時間でした。僕自身普段あまり聞かない、エンジニアになるきっかけとなった話や仕事に対す熱い思いを聞くことができる、ある意味最も濃い時間でした。 f:id:zeals-engineer:20190522105150j:plain

2日目

朝食後いよいよラストの追い込みです。
みんな開発に集中しすぎて写真が一枚もない。。

11時から各自のアウトプットを全員に向けて発表です。

今回テーマを絞らなかったことで、アウトプットの形も様々で、聞くだけでワクワクしました。
そんな中から、いくつかアウトプットをご紹介します!

ダイエットアプリ

Reactの技術深掘りと本人のニーズがマッチしたプロダクトです。
開発期間短い中でもしっかり動くプロダクトをアウトプットとして出すところにプロ意識感じます!

f:id:zeals-engineer:20190522111609p:plain

顔認識

精度はまだまだですが、顔の認識ができるようになりました。
画像が荒くなってしまいましたが、PCのカメラからiPadで表示した弊社CEO、CTOをしっかり認識してくれています。

f:id:zeals-engineer:20190521174312p:plain

github.com

合宿を通して個人としては小さな成功体験を何度も感じることができました。
そして、新しい言語を学び始めたメンバーはこの合宿をきっかけに、学びが深まり業務にダイレクトに還元されています!

良かったこと・反省

合宿終了後、参加メンバーで振り返りを行いました。

良かったこと

  • 掲げていた目標はすべて達成できた
  • 開発環境が良かった
    • 海が見える開放的な場所でリフレッシュもできた
    • 片道1時間のため、移動で疲れることがなかった
  • コミュニケーションが取れた
    • 普段話せないメンバーと話したり、深い話をすることができた
  • テーマを事前に決めていたので、すぐに開発に取り掛かることができた
続きを読む

復活のGotanda.jsに運営&参加してきました!

f:id:zeals-engineer:20190516184449j:plain

皆さんこんにちは! 
ZEALSでVPoE兼サーバサイドエンジニアをやっている福本です!

5月10日に行われました五反田のJavaScriptコミュニティGotanda.js』が約1年振りに復活することとなりました!

gotandajs.connpass.com

今回は再始動イベントに参加してきましたので、そちらのイベント模様と今後のコミュニティ活動について簡単にお伝えできればと思います。

ちなみに、私福本が今回からGotanda.jsのOrganizerに加入させていただいており、イベントやコミュニティ運営をメインとして行っておりました!

github.com

再始動のご挨拶

今回の会場は五反田東口にあるモバイルファクトリーさんの会議室をお借りして実施しました!

f:id:zeals-engineer:20190516175829j:plain

こだわりを感じるキレイなオフィスでした

30名の参加枠に対して43名の方から申し込みが殺到し、さらに当日も申し込みをされた方がキャンセル無しで全員参加されるなど、相当な盛り上がりぶりでした!

JS界隈の盛り上がりやエンジニアの勉強意欲の高さを改めて感じましたね!

再始動にあたるご挨拶をufotsuboiさんに行ってもらいました!

かつてのOrganizerの方が五反田を離れられたのをきっかけに運営が止まってしまっていたのですが、今回約1年ぶりの復活となりました!

LT大会

ここから先はメインプログラムであるLTの実施が続きました!

JS周りのフレームワークやインフラとの兼ね合いについて、自社での取り組みや開発において気づいたことなどを思い思い発表していきました!

(それぞれのLTの簡単な内容は、モバイルファクトリーさんのテックブログで書いてくれておりますので、そちらをご覧ください!)

tech.mobilefactory.jp

LTを聞いて&懇親会でいろんなエンジニアの方の話を聞いての感想なのですが、GatsubyやNuxt.js, Next.jsなどのSSR(サーバサイドレンダリング)周りの話が非常に多かったと感じました!

プロダクトやサービスによってはSEOが非常に重要な要素になっていて、使っているフロントエンドのフレームワークがReactだと、サーバサイドでJSがレンダリングされずGoogleのクローラーがページを上手く読み込んでくれない...

medium.com

そのような背景もありつつ、SSRに迂闊に手を出すとコードが複雑になり開発工数が増大になるという悩ましさがあるため、SSR界隈は独自の盛り上がりを見せているなと感じました。

それ以外にはAWS(CDK)やDockerなど、低レイヤーな領域を絡めた話も多かった印象です!

JS周りはトレンドの移り変わりが本当に激しいので、こういったイベントに参加して最新のトレンドをキャッチアップするのはすごく重要なことだと改めて感じまいした!(もっとJS書こう...)

続きを読む

ZEALSのSlack Public率を覗いてみたら結構おもしろかった件

f:id:zeals-engineer:20190426201205p:plain

はじめに

エンジニアチームの味わい深い領域を担当しているKodyです!
タイトルにもありますが、弊社SlackAnalyticsが激動すぎて面白かったので記事にしてみました...!!

以前SmartHR宮田さんSlackPublic率に関するツイート↓を見かけ、「なんて素敵なんだ...」と感じました。
それがきっかけで、SlackのAnalyticsを覗いてみることにしました!

ちなみにSmartHR社ではDM禁止、Privateチャンネル禁止みたいなルールで縛ることはやっていません。

この「ルールにしない」というところが、実にイケてますね!

shr_miyata_tweet_slack

オープンな文化がもたらす良い効果

「オープンな文化がもたらすいい効果」について、大きい効果が2点あると思ってます!

  1. 情報格差が起こりにくい
  2. 自然と建設的なコミュニケーションの取り方になる
情報格差が起こりにくい

Aさんは知ってるけどBさんCさんは知らないことがある事で

A「〇〇についてだけど...」 B・C「え、なんですかそれ?知らなかったです...」 A「あぁ、それはね....」

などというコミュニケーションが随所で生まれてしまいます。
不必要なコミュニケーションが生まれ、事業&開発スピードに影響が出てしまいます。

自然と建設的なコミュニケーションの取り方になる

publicな場所で誹謗中傷が起こらないなど、お互い気持ちいのいいコミュニケーションが促進されます。
誰に見られても恥ずかしくないようなコミュニケーションを、メンバーが自然と取るようになります。

ZEALSのSlackAnalyticsを見てみました

さて、それでは実際のZEALSのSlackの状況を見ていきましょう!

zeals_slack_public]

...移り変わりが激しいですね...笑
Active User の変遷は↓こんな感じです。

zeals_slack_active_user

大きく3つの動きが見受けられました!

ざっくり時期ごとに分けると、こんな感じで3つに大別できます。
時期ごとに詳しく見ていきましょう!

age_of_slack_pub_rate

秘密結社時代[ActiveUser:10名程度]

age_of_secret_company

ほぼ全てのやりとりがDMですね!
当時のZEALSは秘密結社か何かだったのでしょうか...笑

僕自身がこの時期にいなかったため推測ですが、

  • Slackって何?状態でとりあえず使っていた
  • 平均年齢がLINE文化世代なので必然とLINEのような使い方になっていた

というのが、DM率が高かった原因ではないでしょうか?

激動時代[ActiveUser:50名程度]

age_of_very_move

激しく人数が増え始めた時期ですね!
私自身この時期の後半にZEALSにジョインしました!

メンバーが増えてきたため、社内コミュニケーションの透明性に課題が生まれたのがこの時期だったと記憶しています。
この時期の後半には、ZEALSのValueの制定などもあり、オープンなコミュニケーションが文化として根付き始めました!

文化として根付かせるのは非常に難しいのですが、オープンな文化のメリットを説き続ける「味わい深い」ことができる人がいると進めやすいです。

安定時代[ActiveUser:70~80名]

age_of_stable

どんどんオープンな方向へと向かっていますね!
メンバーが増えているにも関わらずオープンになっているのは、文化として根付いた証ではないでしょうか?

個人的には、もう少しDMの割合下げていきたいと思っています!
今後もZEALSのオープンな文化を作っていくために、引き続き頑張っていきます!

大事なのは「変化する事」

改めてですが、SmartHRさんの例、本当に素晴らしいと思います!
(なかなか真似できないと思いますが...笑)

初めから理想形で運用できていれば良いのですが、全ての組織ですぐに実行するのは難しいのではないでしょうか。

理由は簡単で、「僕たちが人間だから」です!

完全無欠のロボットではなく人間なので、間違いは必ずと言っていいほど起こります。
なので、間違いがあったとしても組織としていい方向へ「変化」する事が大事だと思います。

ZEALSの例でいうと、よくない状況を着実に改善し続け「変わることができた」のではないかなと思っています!

行動の軸となる ZEALSのValue

変化しようと思ってはいても、なかなかうまく行動できないことがあるかもしれません。

そんな時は、行動の「」となるものがあると、メンバーレベルでの意思決定で統率が取れ、チーム一丸となることができると感じています。

ZEALSの行動指針であるValueの1つに「United Will」というものがあり、「時と志を共にする」とう意味を持っています。
(= 志を一つにすること。チーム全体のことを考え、行動すること。)

Slackの使い方が改善されたのも、メンバー1人1人がチームを良いものにしようと動き続け、Valueを軸に行動できた結果だと思います。

今回のように、組織全体で一丸となって改善し合えるのがZEALSの大きな魅力のひとつと言えます!!

さいごに

チームでSlackを使っていて気になった方は、ぜひSlack Analyticsを見てみるのをお勧めします。
チーム力改善のヒントが見つかるかもしれません。

もちろんSlackPublic率が組織としてのオープンさの全てを表すものではないので注意すべきですね。 ただ、よほどセンシティブな情報以外はオープンにすべきだと思います。

papix.hatenadiary.jp

続きを読む

ZEALSではリーダブルコード読書会を実施しています

f:id:zeals-engineer:20190424155226p:plain

こんにちは!
Railsエンジニアのtakakudaです。

今回はエンジニアチームで取り組んだリーダブルコード読書会についてご紹介します!

目的

  • 理解しやすいコードとは何かを知り[to know what is "readable" code like]
  • 実際にそのようなコードを書けるようになることで[and to learn how to write "readable" code]
  • 今後の開発効率を向上させ、バグや障害の発生を削減する[aiming to improve develepment productivity and reduce software bugs and system troubles]

以上のことを目的として、今回の読書会を実施しました。

実はこのリーダブルコードの読書会は3回目で、最初は「またやるの?」という気持ちでしたが、新しい発見がたくさんありました。

やはり『リーダブルコードは』何度読んでも良い名著ですね…。
自分のコードの質が上がったのではないかと感じています!

内容

読書会ですが、以下のような流れで進めました。

1. 座学

リーダブルコードを3章区切りで読みます。
読んだことがある人は、再度読み直します。

2. プルリク作成

リーダブルコードを参考に、改善できそうなコードを見つけてプルリクを作成します。

その際にセルフレビューのコメントで、

  • リーダブルコードのどの章を参考にしたか
  • 質問(ex..このように改善したが、もっと良い書き方はあるか?)
    を追記していきます。

3. ピアレビュー

自分以外の参加者のプルリクを、1人2つ以上レビューします。

レビューの際は

  • 良いと思った点
  • こうしたほうが良いと思った点
  • 質問
    をコメントとして追記します。

4. 議論・講評

  • 1 ~ 3が終わったら全員で顔を合わせるタイミングを作り、議論をします

f:id:zeals-engineer:20190419202758j:plain

講評

  • コードオーナーが全体を通して気づいたことを話す

質問

  • 直接プルリクに記載はなかったが、聞きたいことを質問する

議論

リーダブルコードに書いてある内容で、プロダクトコードに合わせて読み替えたほうが良い点などを話し合う

結果

この読書会は任意参加なのですが、ほぼ全員のメンバーが参加し、プルリクを送りあってくれています。

この取り組みはCTO自らが中心となり推し進めており、ZEALSでは3回目の実施となります。
初回から参加していたメンバーが、教えてもらっていた立場から教える立場へと変わっていく...、という良いサイクルが回っていて、とても良い文化だなと感じています。

ちなみに

実際に参加したメンバーからも良い反応をもらいました!

続きを読む

【初心者向け】fish shellの入れ方と、rbenvではまっている話

f:id:zeals-engineer:20190411141958p:plain

こんにちは!
インターンから新卒で入社した、サーバサイドエンジニアのkanacchiです。

突然ですが、新卒や新たな環境で働くことになったエンジニアの皆さん。
社用PCが供給されてまずはじめに行うことありますよね。

そう、環境構築です。

かく言う僕も先日環境構築を行ったわけですが、その際新たにfishshellを使うことにしたので、今回はfish shellの紹介とハマったポイントなどを残していければと思います。

※注)所々でsudo対応を連発したところ、ことあるごとにpermission errorが出るようになってしまいました。(現に今もsudoで臨時対応してます、、)
この記事を見ている人は安易にsudoを連発せず、コマンドが通らない場合はきちんと原因を解決してから進んだほうが後々楽になると思います(自戒の念を込めて)

fishのinstallにあたって、大まかにはこちらの記事を参考にさせてもらいました。

dev.classmethod.jp

fishって何?

"friendly interactive shell"の略でshellの1つです。
fishのいいところは沢山ありますが、僕がおすすめしたい点は3つです。

①ターミナルがかっこいい

無駄のない、シンプルなターミナルがデフォルトです。

~ >

そして僕のターミナルはこんな感じで、左にrubyのバージョンを表示させてます。

スクリーンショット 2019-04-09 21.26.51.png

ディレクトリを移動するとこう表示されます。
緑の部分は現在のブランチです。

スクリーンショット 2019-04-09 21.27.10.png

そしてそのテーマ設定などをブラウザで扱えます。

$ fish_config

スクリーンショット 2019-04-09 21.16.58.png

② 構文エラーがわかりやすい

無効なコマンドと有効なコマンドをわかりやすく表示してくれます。

無効なコマンド

スクリーンショット 2019-04-09 21.14.53.png

有効なコマンド

スクリーンショット 2019-04-09 21.15.05.png

③コマンドの補完機能が優れている

一度打ったコマンドを学習し、コマンドを補完してくれます。
(右側にグレーで表示されます)

スクリーンショット 2019-04-09 22.15.39.png

fishをインストール

それではまず、fishをインストールしていきます。
Homebrewを使ってfishをインストールしましょう。

$ brew install fish

インストール後はfishコマンドが使えるようになります。

$ fish -v
fish, version 3.0.2

次にデフォルトshellをfishするために、shellファイルを編集します。

$ sudo vi /etc/shells
.
.
.
/bin/zsh
/usr/local/bin/fish ← この一行を追加します。

そしてfishをデフォルトshellに変更します。

$ chsh -s /usr/local/bin/fish

fishermanというfish用のパッケージマネージャーをインストールします。
これはrbenvのパス設定をするためのものです。

$ curl -Lo ~/.config/fish/functions/fisher.fish --create-dirs git.io/fisher

fishermanをインストールすることで、 fisherコマンドが使えるようになります。

$ fisher -v

テーマ設定

次にテーマ設定をします。

まずtheme-bobthefishをインストールしましょう。
theme-bobthefishはoh-my-fishというパッケージマネージャー用のテーマです。

(※参考にした記事では fisher install となっていますが、version3以降はinstall → add にコマンドが変更されました。)

$ fisher add oh-my-fish/theme-bobthefish

多くのテーマはデフォルトで入っているのフォントで対応できないのでpowerlineをインストールします。

$ git clone https://github.com/powerline/fonts.git --depth=1

$ cd fonts

$ ./install.sh

設定 → フォント → 「Powerline」とついたフォントの中から、好きなものを選択してください。

f:id:zeals-engineer:20190410094255p:plain

プラグインをインストール

僕のおすすめのプラグインはfisher zコマンドです。

$ z (フォルダ名)

で一発でそのフォルダに移動します。
インストールも簡単です。

$ fisher add z

こちらの記事で、おすすめプラグインをまとめてくれています。

futurismo.biz

fishでrbenvを使えるようにする

(※Ruby/Rails使う人向けです。)

fishはconfigファイルの場所がbash,zshと異なります。
pathの通し方は調べてみると色々出てくるのですが、僕が参考にしたのはこちらの記事です。

tech-1natsu.hatenablog.com

最初に rbenvをインストールします。

$ brew install rbenv
$ brew install rbenv ruby-build

次にrbenv pathを通します。
fish.confingを置くディレクトリまで移動します。

$ cd ~/.config/fish/

fish.configがあればそこに、なければ作成してpathを記述します。

$ touch fish.config

$ vi fish.config

以下を記述します。

# rbenv
set -x PATH $HOME/.rbenv/bin $PATH
status --is-interactive; and source (rbenv init -|psub)
.
.
.

sourceコマンドで読み込みます。

$ source ~/.fish.profile

あとは、通常のrbenvのフローと同じです。
(ZEALSでは現在ruby 2.4.1を使っています。)

$ rbenv install 2.4.1
$ rbenv local 2.4.1
$ gem install bundler

実は、ここでなぜかpermissionエラーがでてしまいました。

ERROR: While executing gem ... (Errno::EACCES)
Permission denied @ rb_sysopen - ....

sudo使いまくった

(※ここから先は直接fishと関係ありません)

エラーの対応として、

$ sudo gem install bundler

を使うとエラーが出ず通ったのですが、以降はコマンドを使う際にほとんどpermission errorが出るようになってしまいました。

原因はroot userで無理やり gem install bundlerを行ったことだと考え、./.rbenv/versions配下になるファイルの権限を全て変更してもうまくいきません...
結局半日ぐらいかけても解決策が見つからなかったので、渋々sudoを使い続けることになりました。

続きを読む

【後編】元ドリコム/現メルカリの白石さんと語る、ZEALSコアテクノロジー対談

f:id:zeals-engineer:20190327005551j:plain

皆さんこんにちは!
ZEALSVPoE兼エンジニアの福本です!

こちらの記事は前編に引き続き、【後編】元ドリコム/現メルカリの白石さんと語る、ZEALSコアテクノロジー対談です。

後編では「ZEALSの文化」や「組織の雰囲気」などを中心にお話させていただきましたので、その対談の模様をお届け致します。

ちなみに、対談の前編記事はこちらになりますので、合わせてお読みください!

tech.zeals.co.jp

  • ZEALS組織の技術的な強み
    • 「間違いなくNo.1のプロダクトです」
    • パイオニアとして、素早いリリースを
  • どんなチームで開発しているのか?
    • VisionやValueが浸透している
    • 強い成長欲と裁量の大きさがある
    • 複数言語での開発に挑戦しやすい
  • 働くメンバーの思い
    • 多様性のあるエンジニア組織
    • どんな思いで開発しているか
続きを読む