browserify から webpack に移行した話 - てくすた
はじめまして、技術推進チームの id:yszk0123 です。 ピクスタではアプリケーション開発に Ruby on Rails (以下 Rails と表記) をメインで使っていますが、最近 JavaScript (以下 JS と表記) 周りのビルドツールを browserify から webpack に移行しました。本エントリでは、webpack に移行した理由や、Sprockets との兼ね合い、最近登場した webpacker との比較について話したいと思います。具体的な導入方法については Qiita のエントリをご参照ください。 qiita.com 次のような読者が対象です。 Rails エンジニア モダンなフロントエンド環境を Rails で使いたい人 webpack と Sprockets を共存させたい人 webpacker を導入できない・導入に迷っている人 背景 Rails
ピクスタ開発部でローカル開発環境構築自動化コンペを開催しました - てくすた
こんにちは、ピクスタ開発部の星直史( id:watasihasitujidesu )です。 idがwatasihasitujidesuですけど、執事ではありません。エンジニアです。 先日、ピクスタのローカル開発環境構築の自動化方法をコンペで決定しました。 今回は、そのときに各エンジニアが発表した"オレが考える最強の構築方法"と、結果について書きます。 目次 背景 エントリー Docker Compose Chef Zero Ansible 結果 まとめ 背景 ピクスタの開発環境は、主にAWSのEC2を利用していました。 ローカルでも開発環境を構築できますが、多くのエンジニアは利用していませんでした。 しかし、最近はIDE(RubyMine)を使用するエンジニアも増え、ローカルで開発環境を構築することが増えてきました。 Macでの開発環境構築は、手順者こそあるものの、更新頻度や粒度がマチマチ
システム構築・運用自動化のはなし - てくすた
はじめまして、開発部のもりと申します。 今回のテーマは、Amazon Web Service（以下、AWS）でのシステムの構築・運用自動化についてです。 AWSではインフラの構築や運用の自動化のサービスとして、CloudFormationやCodeDeployなどいくつか用意されておりますが、ピクスタではChefを用いてシステムの構築・アプリケーションのデプロイが可能なOpsWorksを採用しております。 そこで今回はピクスタでのOpsWorksの活用事例についてご紹介します。 経緯のはなし これまでのシステムの構築、特にアプリケーションを動かすためのインフラの構築とアプリケーションの運用について、以下のような課題がありました。 サーバの構成情報が乏しく同一のサーバ構築が難しい 同じ役割を持つサーバで内部の状態が異なる アプリケーションのデプロイが複雑で属人化している そこで、インフラの構
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
