sitateru tech blog

sitateru tech blog

シタテルの技術やエンジニアの取り組みを紹介するテックブログです。

2019年2月11日月曜日

セミナーってこういう形もアリなのかと気づいた話

2月 11, 2019

こんにちは!
シタテル株式会社エンジニアのいしづかです。

これまで、ぼくは社内外いろいろなセミナーに参加してきました。

新卒で勤めていた会社では出社初日からビジネスマナー研修がありましたし、本業に関わるプログラミング言語やフレームワークなどの技術的なものは今でも機会があれば参加しますし、はたまた「女性部下との接し方」みたいなやつも参加したことがありますし、そういえば速読のセミナーなんかにも行ったことがあります(身についてはいないけど・・・)。

多かれ少なかれ、ご経験があることだと思います。


これらは基本的に講師が登壇して内容を解説し、ワークを通じて体験するといった流れでセミナーが進行していきました。


もちろんコレ自体が悪いというわけではありません。
しかし、悩みとして一般論としては理解できたけれど、そこから具体に落とせず、結局セミナー前後であまり変化がないというものがありました。


それはセミナーに望むぼく自身の姿勢に大いに問題があるのは承知の上です。目的意識を持って参加してないからだ、と。
しかしながら、なかなかそこから抜け出しきれない状態にありました。


そういうご経験、ありません?(同意を求めてみる)


先日「フィードバック法」に関するセミナーを受けたのですが、その内容はもちろんですが、セミナーのやり方自体がぼくの中でかなり新鮮で、いい気づきがありました。

今回はぼくの気付きについてレポートしたいと思います。

【講師=参加者全員】伝え合う形式のセミナー

ぼくが受けたのは「効果的なフィードバック」という名目のセミナーでした。オンライン開催で、参加者は講師含めて15名です。

資料は事前に配布されており、参加者は事前に目を通しておくことになっていました。


「フィードバック」というのは自分が見知ったことについて感じたことや考えたことを相手に伝えることです。
そこにはIメッセージだのYouメッセージだのという様々なテクニックがあるのですが、今回は内容については割愛します。


このセミナーでは1名の講師がいて全体を進行していたのですが、全体を通して講師の方がしゃべっている時間はほとんど無かったというのが最大の特徴だったように思います。


具体的なシチュエーションを設定して参加者同士でワークをすることはありますが、それについて「自分はどのように感じたか」や「自分だったらどうするか」といったことをシェアし合うという形で進んでいきました。


ぼくにとってこのやり方で進んでいくセミナーはとても新鮮でした。
今まで参加したセミナーでは「なんでも当てはまる一般論」を取り扱うことが多かったですが、今回のフィードバックセミナーではすごく個別具体的なシチュエーションに対して意見を出し合うという形でした。


その中でも同じシチュエーションについて話しているのに人によって感じ方や対策が異なっているのが見えるというのがとても印象的だったのを覚えています。

「過去このような経験があったので、自分としてはこの点を重視しています」といったお話を各参加者がなさるのですが、ぼく自身が経験したことのないことを具体的に聞けるというはとてもリアリティがあって、良い追体験の機会になりました。

シェア型セミナーがおもしろいなと思った点

今回のセミナーは実際にやってみて自分たちがどのように感じたのかといった生々しい部分がしっかり活用できている点がとても良かったと感じました。


一般論的な知識については、資料を読めば大体のところは理解できます。
ぼくもセミナーでしゃべる側になることもあるのですごく反省しているのですが、書いてあることをそれらしく読むだけでセミナーやった(受けた)気になってしまうという罠にハマり続けていた部分があります。


大事なのは具体的な気づきや発見を自分の中に発生させて、それを自分で認識できたのか、という点のハズです。

今回のように、とあるシチュエーションについて自分はどう感じてどう行動しようと思うのかを考え発表しつつ他の人の話も聞くことで、単なる一般論だった知識が「経験」まで昇華されていくプロセスを体験することができたように思いました。


このやり方の一番の特徴は参加者によって得られるものが変わるという点でしょうか。
これまでの経歴によって1つのケースを見たときの感じ方も当然変わってきます。そうするとセミナー中にシェアされることも変わります。


これはメリットでもありデメリットでもありますが、現場の生の声が聞けるというのはかけがえのないものだと思うので、個人的にはそこそこ肯定派です。

自分の困りごとについて様々な意見がもらえたというのは、通常のセミナーではあまりないことだったので、とても有用でした。

まとめ

セミナーの形式にはいろいろなものがありますが、シェア会形式というのもなんかオトナな勉強の仕方みたいで、ぼくはいいなぁ〜と思いました。


特に社内セミナーとかだと、主催する人が一番やりたいと思ってる人だったりするので、一方的にしゃべって終わりってケースも少なくはない気がします。

シェア会形式だと、講師の人は進行役に徹するので、参加者が主役となってみんなで作り上げる会みたいな感じにしやすいです。


組織づくりやコミュニケーションなど、明確な答えが存在しないような話について扱うときはシェア会形式を取ってみるのもおもしろいと思います。

2019年2月1日金曜日

衣服素人でもsitateruとMakuakeで服が作れた [仕組み編]

2月 01, 2019
こんにちは、エンジニアの工です。
私が、sitateruとMakuakeを使って服を作ってみたことについてシリーズで書いていこうと思います。
プリント屋さんでTシャツを作ったことはありますが、完全オリジナルの服を作るのは初めてなので、ドキドキしました。

私が実施したプロジェクトはこちらです。













sitateru × Makuakeの連携

ご存知の方もいるかと思いますが、sitateruは、クラウドファンディングサービスMakuakeと連携して衣服生産のサポートを行なっています。
プレスリリース

仕組み

Makuakeで資金調達、sitateruで生産を行う仕組みです。
一例ですが、大まかなフローはこのようになっています。

  1. 「sitateru」を通してサンプルを生産
  2.  サンプルを撮影し、「Makuake」でクラウドファンディングを実行
  3. 支援者へのリターンとして「sitateru」で商品を量産















クラウドファンディングで資金を集めて、何かしらのサービスを使って生産するというのは、個人でそれぞれやりとりすれば実現できますが、
明示的に連携することで、それぞれのサービスがシームレスにつながって、実行者の負担を減らしてよりプロジェクトをスムーズに進められるようになっています。
例えば、 sitateruへの量産分のお支払いはクラウドファンディング支援金入金後での対応が相談できたりします。

sitateru×Makuakeで素人でも衣服生産を実現できる

ブランドを立ち上げたい、いいアイデアがあるけど..となっても
個人がオリジナルの服を作るのは、
どこから何をやればいいの..?😑
需要あるの...?😂
資金足りないし、採算とれるの...?😅
とか不安要素がたくさんです...
私もずっと服を作りたいという思いはありましたが実行できていませんでした。
この不安をMakuake×sitateruの仕組みで解決し、実際にイマジネーションを形にして服を作ることができました。

実行した流れ

私が具合的に実行した流れはこんな感じです。
  1. 企画する
  2. sitateruに相談する
  3. sitateruでサンプルを作る
  4. Makuakeに正式申し込みをする
  5. Makuakeにコンテンツを作る
  6. ファンディングページを公開する
  7. クラウドファンディングのための施策を行う
  8. ファンディング期間終了
  9. sitateruでプロダクトを量産する
  10. プロダクトを支援者に発送する

まとめ

sitateru×Makuakeで衣服素人でもイマジネーションを形にできる!

今回は仕組みについて、説明していきました!
次回から上に記載した流れを細かく書いていこうと思います!
お楽しみに👯


2019年1月28日月曜日

WEBエンジニアが知っていてもいいかもしれない出版やデザインの話

1月 28, 2019
こんにちは、シタテルでエンジニアをやっている茨木です。

私は出版・DTPをかじったことが少しだけあるのですが、デザインや文章校正の基礎知識はエンジニアの仕事でも活用できる機会が時折あったりします。

基本的なキーワードだけ簡単にご紹介します。
興味がでたらぜひ本格的なデザインや文章校正の本などで調べてみてください。
少し気にするだけでも、画面が結構「それっぽく」なりますので、コスパの良い知識だと思います。

ジャンプ率

1画面(1紙面)でのフォントサイズの変化率を指す言葉です。

一般に、落ち着いた雰囲気にしたい場合はジャンプ率を小さく、派手な印象を与えたい場合はジャンプ率を高くすべきと言われています。

色の指定方法

RGB

WEBエンジニアがまず思いつくのはこれかと思います。光の三原色ですね。

HSB

色相(Hue)、彩度(Saturation)、明度(Brightness)の3要素で色を指定する方法があります。
色相は赤系・青系などの色味、彩度は鮮やかさ(小さいほどグレーに近くなる)、明度は明るさ(小さいほど黒に近くなる)を表します。

SBを固定し、Hのみを変動させることで、比較的まとまりのある色のバリエーションが作りやすいです。

例えば、画面上でステータスAとステータスBの表示色を変えて視認性を上げたい、といった場合には、色相のみ違う2色を用いると、比較的おさまりが良かったりします。

CMYK

インクの4色です。基本的に印刷物の色味はCMYKで表現されます。
WEBだと気にする機会はあまりないですが、RGBやHSBで表現できる色は、必ずしも同じ見え方のCMYKに変換できない、という点は知っておいてもいいかもしれません。

人物写真の「首切り」

インタビューに添付される人物写真において、人物の顔部分に背景の直線(窓枠等)が被る構図はNGとされています。

必ずしも合理的な理由はない(私が知る限りでは)ですが、確かにちゃんとしたサイトや紙面の写真では見ない構図ですから、気にしておくといいかと思います。

文章の書き方

表現したい内容によって正しい日本語の書き方というのは当然変わりますが、かっちりした文章を書く場合には新聞ルールを参考にすると、素人感が出なくていいです。

  • 「出来る」と「できる」はどちら?
  • 「行なう」と「行う」はどちら?
  • 「〜です(〜)。」「〜です。(〜)」はどちら?

たとえばこういう疑問に対して、どっちがプロっぽいか、という回答を与えてくれます。

文献としては共同通信社の記者ハンドブックなどがメジャーですが、買うと高いので、新聞社サイトの文章を参考にするなどでもいいかもしれません。


以上です。散文になってしまいましたが、ご参考になれば幸いです。

2019年1月24日木曜日

Gulp+EJSでページを量産

1月 24, 2019

こんにちは!
シタテル株式会社UI/UXデザイナーの堤です。

複数の静的ページを作る際に便利なGulp+EJSについて紹介します。

今回やりたかったこと

  • 静的なページを量産
  • 共通パーツはテンプレート化したい

導入方法はNode.jsがインストールされている環境でプラグインをインストールします。

$ npm install gulp gulp-merge-json gulp-ejs gulp-rename fs

ディレクトリ構成

gulpfile.js

// gulpプラグインの読み込み
var gulp = require('gulp');
var merge = require('gulp-merge-json');
var ejs = require('gulp-ejs');
var rename = require('gulp-rename');
var fs = require('fs');

//jsonファイルの結合 ※複数のjsonファイルがなければ不要
gulp.task('json', function () {
  gulp.src('./app/data/origin/**/*.json')
    .pipe(merge({
        fileName: 'pages.json'
    }))
    .pipe(gulp.dest('./app/data'));
});

//設定ファイルの読み込み
const jsonData = './app/data/pages.json';
const json = JSON.parse(fs.readFileSync(jsonData));

// ejsをhtmlへ変換
gulp.task("ejs", function() {
    for (var key in json.pages) {
        var data = json.pages[key];
        data.path = key;
        var layout = data.layout;
        gulp.src("./app/ejs/" + layout + ".ejs")
            .pipe(ejs(data))
            .pipe(rename(key + '.html'))
            .pipe(gulp.dest('./public'));
    }
});

pages.json

{
    "pages": {
        "index": { //出力するhtmlファイル名
            "layout": "index", //使用するejsファイル名
            "title": "タイトル1"
        },
        "hoge/index": {
            "layout": "index",
            "title": "タイトル2"
        }
    }
}

index.json

<% include common/_head %> //includeするejs ファイルを指定
<%= title %> //jsonファイル内でしている要素が入る

実行方法

$ gulp json //jsonファイルの結合が必要な場合
$ gulp ejs

まとめ

ejsではjavascriptが使用できるためループ処理なども可能です。

あまり利用する場面は多くないですが、エンジニアさんに 依頼するほどでもないけど、ぱぱっと複数ページを作る必要があるときに便利です!

2019年1月21日月曜日

Linuxのプロセス確認方法3つと終了方法3つ -killコマンドのバリエーション-

1月 21, 2019
Photo by Sai Kiran Anagani on Unsplash

元インフラエンジニアの北爪です。

Linuxにてプロセスを終了する様々な方法について解説します。最後にプロセスを終了するとはどういうことかを説明します。

最初にプロセス終了コマンドとプロセスの確認コマンドをそれぞれ3つ紹介します。
その後に終了コマンドを詳しく解説し、最後にUNIXのシグナルについて簡単に解説します。

プロセスの確認コマンド3つ

  • リアルタイムでインタラクティブなプロセス確認方法、top コマンド
  • Linuxならパイプで繋ぎたいそんな確認方法は ps auxf コマンド
  • パターンマッチで調べたい pgrep -a コマンド

プロセスの終了コマンド3つ

  • インタラクティブにプロセスを終了するなら、top コマンド
  • pidを見て確認しながらプロセスを終了するなら kill コマンド
  • pidを確認するのと同時にプロセスを終了するなら pkill コマンド

topコマンド -インタラクティブにkill-

プロセスの状況を確認しながら、特定のプロセスを終了することができます。topコマンドを起動し、k を押すと、pidが聞かれた後に、送りたいシグナルを入力することができます。最後に確認(yes/no)が出て、プロセスを終了できます。

killコマンド -丁寧にkill-

ps aux | grep <プロセス名> もしくは、pgrep <プロセス名> にてpidを調べます。調べたpidを使って、kill -p <pid> にてプロセスを終了することができます。

pkillコマンド -patternでkill

プロセス名をパターンマッチングして終了ことができます。同時にマッチした複数のプロセスを終了することができます。

例えば、nginxが起動しており、master(親プロセス)とworker(子プロセス)が実行されているとします。以下のようになります。

root@0e1d355b28f0:/# ps auxf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1  18504  3528 pts/0    Ss   10:03   0:00 /bin/bash
root      3470  0.0  0.0 140624  1520 ?        Ss   10:11   0:00 nginx: master process /usr/sbin/nginx
www-data  3471  0.0  0.1 141000  3428 ?        S    10:11   0:00  \_ nginx: worker process
www-data  3472  0.0  0.1 141000  3428 ?        S    10:11   0:00  \_ nginx: worker process

pkill nginx これでnginxのプロセスを終了することができます。
また、-f オプションでは、プロセス名だけではなく、オプションを含めた全てのプロセス名がパターンマッチの対象になります。

pkillは、pgrepとセットで使うことでどのプロセスが対象になるのかを事前に調べることができます。 pgreppkill はオプションを共有しているので、pgrepにて対象のプロセスを調べることができます。

pgrepにてプロセスの探し方をオプションなしでプロセス名にて検索、-f オプションにてプロセス名全体にて検索の例を示します。-a オプションはプロセスの説明を表示します。

root@0e1d355b28f0:/# root@0e1d355b28f0:/# ps auxf | grep nginx
root      3789  0.0  0.0 140624  1512 ?        Ss   10:57   0:00 nginx: master process /usr/sbin/nginx
www-data  3790  0.0  0.1 141000  3384 ?        S    10:57   0:00  \_ nginx: worker process
www-data  3791  0.0  0.1 141000  3384 ?        S    10:57   0:00  \_ nginx: worker process

root@0e1d355b28f0:/# pgrep -a nginx
3789 nginx: master process /usr/sbin/nginx
3790 nginx: worker process
3791 nginx: worker process

root@0e1d355b28f0:/# pgrep -a -f master 
3789 nginx: master process /usr/sbin/nginx

root@0e1d355b28f0:/# pgrep -a -f worker        
3790 nginx: worker process
3791 nginx: worker process

次に、意図的に、先にnginxのmasterプロセスにSIGKILLをシグナルを送り、親プロセスのみ強制終了します(シグナルについては後述)。そのあとに親プロセスが消えた子プロセス(= Orphan process)のwoker(子プロセス)をpkill -f を使って終了してみます。

root@0e1d355b28f0:/# ps auxf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1  18616  3552 pts/0    Ss   10:03   0:00 /bin/bash
root      3789  0.0  0.0 140624  1512 ?        Ss   10:57   0:00 nginx: master process /usr/sbin/nginx
www-data  3790  0.0  0.1 141000  3384 ?        S    10:57   0:00  \_ nginx: worker process
www-data  3791  0.0  0.1 141000  3384 ?        S    10:57   0:00  \_ nginx: worker process
root      3805  0.0  0.1  34396  2828 pts/0    R+   11:02   0:00 ps auxf
root@0e1d355b28f0:/# pkill -KILL -f master
root@0e1d355b28f0:/# ps auxf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1  18616  3552 pts/0    Ss   10:03   0:00 /bin/bash
www-data  3790  0.0  0.1 141000  3384 ?        S    10:57   0:00 nginx: worker process
www-data  3791  0.0  0.1 141000  3384 ?        S    10:57   0:00 nginx: worker process
root      3807  0.0  0.1  34396  2792 pts/0    R+   11:02   0:00 ps auxf
root@0e1d355b28f0:/# pkill -KILL -f worker
root@0e1d355b28f0:/# ps auxf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1  18616  3552 pts/0    Ss   10:03   0:00 /bin/bash
root      3809  0.0  0.1  34396  2944 pts/0    R+   11:02   0:00 ps auxf

プロセスの終了とは シグナルについて

プロセスの終了は各プロセスにシグナルを送ることで外部から非同期にプロセスのコントロールを行います。

top kill pkill 全てのコマンドでデフォルトのシグナル(SIGTERM/15)です。つまり、TERMシグナルを送ることで、プロセスを終了しています。

TERM以外のシグナルを送ることも可能です。各シグナルは番号と英語による表記があります。kill pkill 共に -<signal> にてシグナルを送ることができます。これは数字でも文字でも可能です。例えば、強制終了はkill -KILL もしくは kill -9
kill -lコマンドでシグナルの一覧を出力することが可能です。


root@0e1d355b28f0:/# kill -l
 1) SIGHUP  2) SIGINT  3) SIGQUIT  4) SIGILL  5) SIGTRAP
 6) SIGABRT  7) SIGBUS  8) SIGFPE  9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR
31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3
38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8
43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7
58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2
63) SIGRTMAX-1 64) SIGRTMAX


終わりです!

2019年1月18日金曜日

FirefoxとChromeで画像の色味が違う問題

1月 18, 2019

こんにちは!
シタテル株式会社UI/UXデザイナーの堤です。


以前出くわしたFirefoxとChromeが画像の色味が違う問題について解決方法をご紹介します。

画像はぱくたそさんから拝借

修正前

左がChromeで右がFirefox

微妙にFirefoxの色味が濃く出てしまいます。

修正後

解決方法

Photoshopで書き出しの際に「カラープロファイルの埋め込み」にチェックするだけ!

まとめ

以前なぜかわからずいろいろと調べていたところこの解決方法にたどり着きました。

微妙な違いにはなりますが、 写真が多いサイトだと全体の印象も変わってくるため気をつけたいと思います。

2019年1月4日金曜日

【mac】操作スペースを使いこなす!

1月 04, 2019

こんにちは!
シタテル株式会社エンジニアのいしづかです。

開発作業をしているといろんなソフトウェアを使いますね。
Slack・Webブラウザ・コードエディタ・gitツール・DBツール・・・etc

これらを1つのウィンドウ内に置いてキーボードで切り替えてもいいんですが、どうしてもゴチャゴチャ感は否めません。

macには「操作スペース」と呼ばれる仮想的なデスクトップ機能があります。
ディスプレイを何枚も持っているようなイメージの機能ですね。それを切り替えて使います。

今回はその操作スペースを使いこなすために、私が行っている設定をご紹介します。

操作スペースをつかう

Mission Controlを起動すると「デスクトップ1」って感じで表示されている部分、ここ Spacesバー って言うらしいです。最初はデスクトップ1だけですが、右端の+ボタンから増やすことができます。

私はいつも6つ用意しています。
それぞれ置いておくものを決めていて

  • デスクトップ1: Slack
  • デスクトップ2: Webブラウザ
  • デスクトップ3: コードエディタ(Visual Studio Code)
  • デスクトップ4: gitクライアント(SourceTree)
  • デスクトップ5: DBクライアント(SequelPro)
  • デスクトップ6: 予備

こんな感じで使っています。
どこに何があるか決めておくことで、ほしいウィンドウをパッと取り出せるようにしています。

ちなみに、このウィンドウの順番を使用状況に応じて並び替える機能があって、macさんの親切心なんですが、私にとって余計なお世話と化していたのでOFFにしています。

↓コレです。システム環境設定のMission Controlにあります。

すばやく切り替えるための設定

それでもデスクトップ1からデスクトップ4まで移動するにはトラックパッドを三本指でシャッシャッシャッと3回やることになります。

この行ったり来たりが地味にめんどくさい。。。

そこでショートカット1発で「デスクトップ○」を出すようにしています。

システム環境設定の「キーボード」でMission Controlのショートカット設定ができます。
↓コレです。

ここでは「control + 数字」を押すとデスクトップを切り替えるようにしています。

これでどのデスクトップを表示していても、Slackが見たければ「control + 1」ですし、コードエディタを出したければ「control + 3」で一発移動が可能です。

まとめ

ホントにちょっとしたことなんですが、毎日発生する微細な面倒事を放っておくと慣れてしまって当たり前になってしまうので、こんな細かい工夫も怠らないように心がけています。

みなさんそれぞれ快適な開発環境を構築しているようですので、その工夫を聞いて取り入れていきたいですね。