オルトプラスエンジニアの日常をお伝えします!

私の Touch Bar (Control Strip) カスタマイズ

※この記事は AltPlus Advent Calendar 2017 の10日目のエントリです。

こんにちは、中田 (id:satotech) です。

Touch Bar 付 Macbook Pro をお使いの方、Touch Bar 活用されてますか? 今回は私の Touch Bar (Control Strip) の設定について書きます。

私は Control Strip をこんな感じに設定しています。

配置

f:id:s-nakada:20171210164813j:plain

左から順に次のようにしています。

  • Brightness
  • Mission Control
  • Launchpad
  • Keyboard Brightness
  • Do Not Disturb
  • Notification Center
  • Volume
  • Screen Saver

なぜこのようにしたか?

Brightness, Volume について、Brightness Slider, Volume Slider への入れ替えも考えましたが、普段 Apple Magic Keyboard を使う場面があるのでインターフェイスを同じままにしました。 私の場合、Media, Siri キーの使用頻度が低かったので、そこだけを入れ替えた形です。 代わりに追加したアイテムは次の3つです。

  • Do Not Disturb
  • Notification Center
  • Screen Saver

Do Not Disturb

ChatWork や Slack などのチャットアプリのデスクトップ通知を表示させたくない、集中したい時ってありますよね。 かといってチャットアプリを終了しておくと今度は起動時間がもったいない。 そんな時に通知の ON/OFF をしやすくしています。

Notification Center

好きなアイテムを設定しておくことができます。 WORLD CLOCK, CALCULATOR をよく使うので、ここから見られるようにしています。

WORLD CLOCK

f:id:s-nakada:20171210164844p:plain

各地との時差を意識して仕事をする際に、アナログ時計の方が時刻を認識しやすいですよね。 時計を並べて見られるので便利です。

CALCULATOR

f:id:s-nakada:20171210164905p:plain

Dashboard やアプリの電卓を使うこともあるのですが、こちらの方が入力した値を保持していてくれたり、表示位置を調整しなくてよいので便利です。

Screen Saver

離席時のスクリーンロック用です。 Control Strip のアイテムとして Screen Lock も選択できますが、ロック画面が「バン!」と表示されるのはちょっと味気ないのでスクリーンセーバーで即ロックがかかるようにしています。

設定手順

次の手順で Control Strip を設定しています。

Preferences の Keyboard で Touch Bar の設定

f:id:s-nakada:20171210164931j:plain

  • Touch Bar shows で "Expanded Control Strip" を選択
  • Press Fn Key to で "Show F1, F2, etc. Keys" を選択
  • "Customize Control Strip" ボタンをクリック

Control Strip に表示するアイテムの選択と配置

f:id:s-nakada:20171210164953j:plain

ベースはデフォルトの Control Strip で、次の変更を行っています。

  • Media と Siri を Touch Bar から外す
  • Media のあった場所に Do Not Disturb, Notification Center を配置
  • Siri のあった場所に Screen Saver を配置

まとめ

ちょっとしたカスタマイズでよく使う機能やアプリを簡単に利用できるようになりました。 手元の操作でできることが増えると姿勢が固定されて運動不足になってしまいがちなのが悩みどころです。 適度に体を動かすことも忘れずにやっていきたいと思います。

※この記事は Qiita の 私の投稿 から転載しています。

webサービスのログ運用について

この記事はAltplus Advent Calendar 2017の9日目のエントリです。

こんにちは、サービスのインフラ周りの対応をしている橋本です。 ログの可視化や集計などで、複数サービスに適用を始めたので、 現在のログ運用の構成を書きたいと思います。

ログ運用について

構成

  • fluend
  • KinesisFirehose
  • S3
  • Athena + redash

ログ流れ

fluentd -> KinesisFirehose -> S3

ログ参照

redash -> athena -> s3
aws-cli -> athena -> s3
web -> athena 

監視について

アラート用でボトルネックになる部分とAWSサービス側障害用で下記を監視しております。

  • kinesisFirehose
    • レコード取り込み数
  • fluentd
    • リトライ数

ログフォーマットについて

他のところにも使うかもしれなかったので加工複数の環境に対応できるよう、JSONフォーマットでの書き出しを行っています。

集計時

  • DBのデータとのJOINしたいとき
    • DBデータをTSV出力し、S3アップ後、Athenaのテーブル作成

テーブル

  • kinesisFirehoseでS3保存時に作成されるディレクトリの日付毎でパーティションを何年分かを設定しています。

困ったところ

Athenaのテーブル設定でパーティションを始め、年、月、日で分けていたのですが、クエリを書きずらかったため、 20171212 などひとつのカラムに年月日の形で入れたほうがクエリが簡単になり便利でした

懸念

今後、Athenaで参照するデータがだいぶ増えた場合にクエリにだいぶ時間がかかるようにならないか心配で、 なったときは、bigqueryのほうに引っ越しを考えています。

クエリ

はじめ bigquery で運用していて、S3のログをGCS転送後そちらを bigqueryにロードするよう設定していました。 Athena側に移行する際に、日付パーティションの指定部分の違いとタイムゾーンの切り替えのところで少し悩んでいたので where句のところをメモで残せればと思います。

  • athena
# タイムゾーンのほう
SELECT date_format(time AT TIME ZONE 'Asia/Tokyo' , '%Y%m%d') as event_at,

# パーティションのほう
dt(パーティションのカラム) >= date_format((now() + interval '-30' DAY) AT TIME ZONE 'Asia/Tokyo' , '%Y-%m-%d') )
  • bigquery
# タイムゾーンのほう
SELECT FORMAT_TIMESTAMP('%Y%m', time, 'Asia/Tokyo') AS date_time

# パーティションのほう
_TABLE_SUFFIX >= FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 365 DAY))

所感

  • ログを集約して転送する部分のサーバがなく少し運用が楽になりました
  • まだそこまでのログ量はないのですが、S3にデータを保存するのだと、 圧縮した状態で配置できるので、bigqueryに保存するよりもログ量が増えた際にお得になっていきそうに思います。

Laravelの機能を使って綺麗なコードを書く

この記事はAltplus Advent Calendar 2017の8日目のエントリです。

概要

  • 主にコード量を減らすことが出来る、読みやすくなるようなLaravelの機能を紹介してく
  • 備忘録的な感じ

ルートプレフィックス

どんなもの?

使わないで書くと?

Route::get('/admin',           'Admin\AdminController@top');
Route::get('/admin/hoge',      'Admin\AdminController@hoge');
Route::get('/admin/huga/piyo', 'Admin\AdminController@hugaPiyo');

使って書くと!

Route::prefix('admin')->group(function () {
    Route::get('/',          'Admin\AdminController@top');
    Route::get('/hoge',      'Admin\AdminController@hoge');
    Route::get('/huga/piyo', 'Admin\AdminController@hugaPiyo');
});

メリット

  • ルーティングを見た時に関連のあるルーティングがぱっと見で分かりやすくなる
  • 上記の例の場合だと、「管理者画面関連のルーティングなんだろうなぁ」と予想が付く

名前空間ルーティング

どんなもの?

  • 同じ名前空間を持つコントローラーを一つにまとめることが出来る
  • 例えば、app/Http/Controllers/Admin/配下にコントローラーファイルを複数作成していた場合にまとめて書ける

使わないで書くと?

Route::prefix('admin')->group(function () {
    Route::get('/',          'Admin\AdminController@top');
    Route::get('/hoge',      'Admin\AdminController@hoge');
    Route::get('/huga/piyo', 'Admin\AdminController@hugaPiyo');
});

使って書くと!

Route::prefix('admin')->namespace('Admin')->group(function () {
    Route::get('/',          'AdminController@top');
    Route::get('/hoge',      'AdminController@hoge');
    Route::get('/huga/piyo', 'AdminController@hugaPiyo');
});

メリット

  • ルートプレフィックスと同じ

リソースフルルーティング

どんなもの?

  • 基本的なCRUD関連のルーティングをまとめて書ける

使わないで書くと?

Route::prefix('users')->group(function () {
    Route::get   ('/',            'UserController@index');
    Route::get   ('/create',      'UserController@create');
    Route::post  ('/',            'UserController@store');
    Route::get   ('/{user}',      'UserController@show');
    Route::get   ('/{user}/edit', 'UserController@edit');
    Route::patch ('/{user}',      'UserController@update');
    Route::delete('/{user}',      'UserController@destroy');
});

使って書くと!

Route::resource('users', 'UserController');

メリット

  • コード量かなり減らせる
  • 一目でそのコントローラーがCRUDの要素を持っていることが分かる
  • コントローラー内のアクションメソッドも同じになるので、共通認識での開発ができる

備考

  • リソースフルルーティングに対応するコントローラーは、下記のようなコマンドで一発で作成できる
    php artisan make:controller UserController --resource

フォームリクエストバリデーション

どんなもの?

  • バリデーションをapp/Http/Requests/配下に作成されるフォームリクエストクラスに書くことが出来る

使わないで書くと?

  • 下記のコードをモデルやサービスクラスでメソッド化して、コントローラで呼び出さなければならない
$request->validate([
    'name'  => 'required',
    'email' => 'required|email',
]);

使って書くと!

  • 下記のようなコマンドでフォームリクエストクラスを作成する
    php artisan make:request StoreBlogPost
  • app/Http/Requests/StoreUser.phpが作成されるので、下記のように修正する
<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class StoreUser extends FormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'name'  => 'required',
            'email' => 'required|email',
        ];
    }
}
  • コントローラーのアクションメソッドで、上記のクラスを引数に指定して呼び出すだけで、バリデーションを通ったもののみがアクションメソッドの処理を実行する
public function store(StoreUser $request)
{
}

メリット

  • バリデーションについてのコードをフォームリクエストクラスに任せることができる
  • (今回は解説しないが)認証機能、エラーメッセージの設定も出来る

最後に

「Laravelにはこんな機能もあるよ!」等のコメントいただけると嬉しいです!