こんにちは！

シタテルで エンジニアをしている建山です。

主に工場向けのマイオペというシステムの開発を行っています。

シタテルではファイルをawsのs3でホスティングしています。
直接s3のファイルを操作することは少ないのですが、やはり時々は発生します。

そんなときにはaws-cliを使うこともできるのですが、s3cmdを使うとより簡単なコマンドでS3を操作できます。

いくつかよく使うコマンドをまとめました。

ディレクトリのファイル権限を操作

s3cmd setacl -r --acl-private s3://バケット名/ディレクトリ名/

-r は再帰的に配下すべてやってくれる

--acl-privateはprivate権限にする

--acl-publicはpublic権限にする

※バケットも指定できる

ディレクトリの中身を参照

s3cmd ls s3://バケット名/ディレクトリ名/

バケットの情報をみる

s3cmd info s3://バケット名

これ以外にもファイル/ディレクトリアップロードや削除などいろいろなことができます。

全てのコマンドリストはこちら

コマンドのインストール

インストールはmacの場合、

brew install s3cmd

でできます。

コマンドを使う前に、AWSのアクセスキー等を設定 する必要があります。

s3cmd --configure

ぜひ、お試ししてみてください。

こんにちは！
シタテルで エンジニアをしている熊谷です。

主にSPECというサービスのバックエンド開発（Rails）を行ってます。

今回は、話題のAWS Loft Tokyoに行って来たのでレポートします。

どうもこんにちは

シタテルでエンジニアをしている朝野です。
主に、セキュリティーや開発インフラを担当しています。

シタテルではRuby on Railsを使っているプロダクトがいくつかあるのですが、そこでのセキュリティ施策の1つとしてBrakemanというGemを使っています。

セキュリティチェック用のGemとしては有名どころですが、理解の確認も兼ねてまとめてみました。

Brakemanとは

Railsのソースコードを解析し、SQLインジェクションやXSS等の脆弱性になりかねない危険なコードを見つけ出すGemです。

brakeman | RubyGems.org | your community gem host
Brakeman — Rails Security Scanner

インストール

Gemなので、

$ gem install brakeman

とするか、Gemfileに

gem ‘brakeman’, require: false

と書いて bundle install すればOKです。

実行

$ bundle exec brakeman

で実行でき、ソースコード内を確認してくれます。

オプションもいろいろあるのですが、現在は
-A すべての種類の脆弱性を検査
-w1 すべてのレベルの脆弱性を検査
-z 脆弱性が見つかった場合の終了コードを0以外に

というオプションを使っています。

-A と -w1 はセキュリティのため、 -z はCircleCIのためです。
脆弱性が見つかった時ビルド失敗になり、開発中のブランチで脆弱性が見つかっていたらmergeできなくなるわけです。

ちなみにその他オプションはこちら。

ただ毎回オプションを打つのも面倒なので、設定ファイルにまとめてしまうと便利です。
-Cをつけて実行すれば、同時につけたオプションに相当する設定ファイルの内容が出力されます。

$ bundle exec brakeman -A -w1 -z -C
---
:run_all_checks: true
:min_confidence: 2
:exit_on_warn: true

これを config/brakeman.yml に保存しておけば自動でその設定が読み込まれるので、オプションをつけなくてよくなります。
ちょっと楽ですね。

警告に対応しないとき

Brakemanを実行して出力された脆弱性を修正していくことになります。
ただ、修正のしようがないときやそのままでも問題ないときというのもたまにあります。

そんな場合は safe_methods と brakeman.ignore の設定が役に立ちます。

safe_methods は実行時のオプションの一つで、名指ししたメソッドは安全だからチェックしなくていいよ！とするものです。
例えば、config/brakeman.yml に

:safe_methods:
- :display_hoge
- :change_fuga

と書けば、 display_hoge と change_fuga のメソッド内はスキャンされません。

brakeman.ignore は無視する警告のリストです。
brakemanは

$ brakeman -I

と -I オプションで実行すると対話モードになるのですが、

------------------------------
Actions:
i - Add warning to ignore list
n - Add warning to ignore list and add note
s - Skip this warning (will remain ignored or shown)
u - Remove this warning from ignore list
a - Ignore this warning and all remaining warnings
k - Skip this warning and all remaining warnings
q - Quit, do not update ignored warnings
? - Display this help
-------- 1/1 -----------------
Confidence: Weak
Category: Cross-Site Scripting
Message: Unescaped model attribute
Code: display_hoge(Item.hoge)
File: app/views/some/path/edit.html.haml
Line: 19
Action: (i, n, k, u, a, s, q, ?)

というふうに見つかった脆弱性をどうするか聞いてきます。
ここで i を入力すればその脆弱性を無視リスト(デフォルトでは config/brakeman.ignore )に追加できます。
無視リストに入れられた警告は、以降出力されなくなります。

このように不要な警告をスルーする手もちゃんとあるのがbrakemanのよくできているところですが、うっかり対象から外した部分に危険なコードを書き足してしまわないように注意しなければいけないですね。

と、ざっとまとめてみました。

最初からセキュリティを意識してコーディングするのがまずは重要ですが、このようなチェックがあると安心がアップしますね。

こんにちは！
シタテル株式会社CTOの和泉です。

Follow @shinobu_shiva

今日はシタテルの技術ブログの管理について紹介します。
シタテルは衣服づくりのプラットフォームを提供しているスタートアップ企業ですが、
実は３分の１以上がエンジニア、デザイナーというIT企業でもあります。
（あまり知られてないので主張します！）

突然ですが、ここで質問です！
プログラマの好きなもの３つはなんでしょう？

答えは！？

GitHub
マークダウン
デプロイ自動化

ですよね！そうに違いない！

この独断と偏見に基づいて、シタテルの技術ブログはマークダウンで記述して、GitHubで管理レビューをして、
CircleCIによって自動的にデプロイされる仕掛けにしてみました。

この仕組で社内のメンバーの皆さんに１スプリントに１ブログをお願いしています。

さて、今回はその 仕組みと投稿の手順を簡単に紹介します。

しくみ

仕組みと行っても難しいことをしているわけではないのですが、、、

APIの充実したブログサービスとして、知識のない私はBloggerしか思いつきませんでした。

しかし、Bloggerはマークダウンでは投稿できません。なので、マークダウンで記述したファイルをプログラムでHTMLに変換しています。

また、画像等のファイルは マークダウンで書いたテキストそのままを投稿してもどうにもなりませんので、変換後のHTMLのDOM構造からリンクURLを抽出してAmazon S3にアップロード＆URLの書き換えを行っています。

以下の手順に出てくるURLはシタテル社員限定公開なのですが、
こちらの公開リポジトリでその部分のコードはご覧いただけます。

https://github.com/shinobushiva/blogautomation

手順

前準備（初回のみ）

1. https://github.com/sitateru/tech-blog をクローン

git clone https://github.com/sitateru/tech-blog

2. masterブランチから新しいブランチを作成してチェックアウト

git branch shinobu.izumi
git checkout shinobu.izumi

ここでは例として shinobu.izumi というブランチを作っています。

ブランチは１人１つを使いまわしても、各自が記事ごとに切るなどしても構いません。

3. posts/blog/ 配下に個人のフォルダを作成（フォルダ名は個人が特定しやすい名前にしてください）

ここでは例として shinobu.izumi というフォルダを作っています。

新しい記事を追加する場合

0. masterブランチをpull

最新のmasterブランチを忘れずにpullします。

1. 自身のフォルダ内に記事のフォルダを作成（フォルダ名は自由）

2. フォルダ内に記事を作成

最低限必要なファイルは content.mdとmeta.json です。

content.md

投稿する記事の内容をマークダウン形式で記述します。

meta.json

記事のメタ情報を記述します。親フォルダの内容を継承しますが、子フォルダの内容で上書きされます。

例は最後に記述してあります。

3. ブランチをリモートリポジトリにプッシュ

git push origin shinobu.izumi

4. publish ブランチ向けにPR

GitHub上で publishブランチに向けてPRを出します。
レビュー後にマージします。

meta.json 例

{
    "blogId": "1797929185044797553",
    "isDraft": true,
    "publish": false,
    "revert": false,

    "isPage": false,
    "ignore": false,
    "forcePost": false,
    "contentPath": "content.md"
}

{
    "ignore": false,
    "resource": {
        "title": "シタテルのオンライン衣服生産システム"
    }
}

以下はBloggerAPIへの指定パラメーター（の一部）です。

以下は本システム向けの設定です。

記事のブログへの公開

publishブランチにマージすると、CircleCIが動いて自動的にブログに投稿します。
CircleCIの内部で公開日時などのメタ情報を更新したものをmasterブランチにプッシュします。これにより公開情報をGithubに記録しています。

おわりに

以上、シタテルの技術ブログの管理についてでした。

これから、シタテルで働いているメンバーが使っている技術や日々の業務の中で取り組んだ内容などをお伝えしていきます ！