こんにちは、シタテルの茨木です。

突然ですが、scoped cssいいですよね

scoped cssは、特にVue.jsにおいては、css設計のスタンダードと言っていいのではないかと思います。

BEM等の学習コストの高い手法を覚える必要がなく、「コンポーネント内でのみcssクラス名の一意性を確保すればいい *1」という、シンプルで管理しやすい設計指針を打ち立てることができ、実に理にかなった手法ですね。
プロジェクト全体でのcss命名規約の統制問題は依然としてありますが、コンポーネントベースでの設計手法自体がコンポーネントを書き捨てる運用と親和性があるため、そこまで大きな問題にはならないのかなと思います。

依然として残る考慮点

一方、scoped cssだけで、コンポーネント内にcss的な関心事を完全に閉じ込められるかというとそうではなく、当然ながら例外もあります。

最も代表的な例としては、cssの仕様上継承されてしまう属性ですね。
font-sizeなど、属性自体が子孫要素に継承されるものとして定義されていますので、セレクタレベルでscopedにしたところで、子孫要素への影響を避けることはできません。

まあこの辺は書いていても直感的に理解しやすいのでそこまで問題になりにくいのですが、個人的に危ないなと思うのは「z-index」「重ね合わせコンテキスト」です。

z-indexの管理

cssをざっくり理解したつもりになっているエンジニアが犯しがちな間違いの一つが、z-indexがグローバルだと思いこんでしまうことだと思います。

そう考えているエンジニアは、Vueプロジェクト全体で単純にコンポーネントごとのz-indexを管理することをを思いつきます *2。例えば、コンテキストメニューのコンポーネントはz-index1000番台、モーダルダイアログのコンポーネントはz-index500番台といった管理です。（モーダル上でコンテキストメニューを開くかもしれない。その場合はコンテキストメニューがモーダルの下に回り込んでほしくない、なんてことを考えているわけですね）

この方式は重ね合わせコンテキストがページ内で1つであるうちは上手く機能しますし、ルール自体はおそらく間違いでもないです。
ただ、重ね合わせコンテキストに関する考慮を漏らしていると、「z-indexで勝っているはずなのに、なぜか後ろに回り込んでしまう要素」が出てくる可能性があり、「なぜか動かない」という状況に見舞われます。実際には仕様理解が足りていないだけなのですが。

理解すべき仕様「重ね合わせコンテキスト」の詳細についてはMDNを読んでください。

https://developer.mozilla.org/ja/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context

ざっくり言えば、「z-indexは同じ重ね合わせコンテキストの中での比較にしか使われない」「重なる系の属性(potision: absoluteなど)が指定された要素は自身が重ね合わせコンテキストを形成する」ということです。

これもfont-sizeなどと同じで、親要素で指定された属性が（たとえscopedであろうとも）、子孫要素に影響を与えうる、ということですね。

デザインは文脈依存？

scoped cssとコンポーネントベースでの部品化は、確かに今までのcssの不便さや複雑さの大部分を解決しているように見えますが、z-indexの件を一つの例として考えると、「デザイン・見た目・UIは、どこまで部品化しても文脈依存から逃れられない」ということを示している気がします。まさに、重ね合わせ「コンテキスト」ですしね。

z-indexをpropsで渡せば…みたいな発想はもちろんあるのですが、結局その先にあるのはinput要素の再発明だったりするわけです。input要素をwrapしてたはずがinput要素を作っていた…みたいな。

どんなコンテキストでもデザイン破綻せず使うことのできるUI部品の実装は、相当な労力を要します。（まあ、実際にUI部品系のnpmパッケージの中を覗いてみると、普通にz-indexがハードコードされていて変更できなかったりすることが多く、みんなほどほどに手を抜いているんだと思いますが）

プロジェクト内でのデザイン統一・再利用を想定してコンポーネントを分割設計する際に、デザイン的な汎用性を求めるのはほどほどにしておくべきなのかな、と思った次第でした。

他コンポと疎結合に作るとか、ステートレスに作るとか、そちらに労力を割いたほうが実りが大きいんじゃないかな。UIの寿命は短いので、捨てやすいように疎結合に書くのが一番大事かな、と個人的には思います。

---

*1: slot内のスコープが親子共通だったり、コンポーネントroot要素に親からclassが注入できるといった例外はありますが

*2: 私です

こんにちは、シタテルの藤本です。
イベントの参加のために久しぶりに東京に行きましたが、渋谷駅から出られなくなりそうになりました。
あらためてお上りさんには厳しい街であることを実感しました。
先日「スマホで見つける地方のしごと」というシンポジウムにパネラーとして
参加させていただきました。

内容を簡潔にすると「首都圏での離職と地方へUIJターンを希望する方と地方企業の
マッチングを進めて地方を活性化していこう」というイベントでした。

200名以上の方が参加され、各者の熱いプレゼンもありここから少しづつ
地方へ人材が広がっていってくれるのではないかと感じることができたイベントでした。

そんなイベントについて簡単にレポートしてみたいと思います

プレゼンター、パネラー

プレゼンター、パネラーとして以下の方々が参加されていました。

• 求人サイト運営企業
• 地方自治体
• 商工会議所
• 地方への移住者（Uターン）

イベントの大まかな流れ

ドット３つ ...

let array = [ 1, 2, 3 ]

let result = [ 0, ...array ]

let array = [ 1, 2, 3 ]

let result = [ 0, ...array ]

console.log(result)
// => [0, 1, 2, 3]

let obj1 = { potato: 2, carrot: 3, onion: 5, niku: 8 }

let obj2 = { water: 65535, spice: Infinity }

let result = { ...obj1, ...obj2 }

console.log(result)
// => { "potato": 2, "carrot": 3, "onion": 5, "niku": 8, "water": 65535, "spice": Infinity }

function createUser(firstName, lastName, bornYear, bornMonth, bornDay) {
    // doSomeProcess
}

let name = ['Colonel', 'Sanders']
let birthday = [1890, 9, 9]
let user = createUser(...name, ...birthday) // => createUser('Colonel', 'Sanders', 1890, 9, 9) を実行するのと同じ

ビックリマーク２つ !!

function hasName (user) {
  return ( user.name !== undefined && user.name !== null && user.name !== '' )
}

function hasName (user) {
  return !!user.name
}

(おまけ) いろんな値の truthy / falsy について

• truthy (Boolean にキャストすると true となる) の例
  • true
  • 0 以外の Number (ex: 1, -1, 3.14, -273.15, 6.02e+23, etc)
  • Infinity と -Infinity
  • 空でない文字列 (例: "a", "false")
  • [] (空の Array)
  • {} (空の Object)
  • 1 == true (緩やかな比較)
• falsy (Boolean にキャストすると false となる) の例
  • false
  • 0 (Number)
  • "" (空の String)
  • null
  • undefined
  • NaN
  • 1 === true (厳密な比較)

• 空文字列は falsy だが、空の配列や空のオブジェクトは truthy
• “false” や 配列 [false] などは truthy

関数のアロー記法 () => {}

setTimeout(function() {
    console.log('Hello!')
})

setTimeout(() => {
    console.log('Hello!')
})

テンプレートリテラル `${}`

let username = `山田太郎`
let message = `ようこそ、${username}さん！`
console.log(message) // => "ようこそ、山田太郎さん！"

let body = `${client.name}様

いつも大変お世話になっております。
${company.name}の${staff.name}です。

${message.content}`

console.log(body) // => "山田太郎様\n\nいつも大変お世話になっております。\n〇〇株式会社の...

---

こんにちは！シタテル株式会社UI/UXデザイナーの田仲です。
私が担当しているマイオペレーター（以下、マイオペ）という縫製工場の生産管理者向けのシステムが、「JBUG(ジェイバグ：Japan Backlog User Group)」が開催する『Backlog World 2019』内の『Good Project Award 2019』にて最優秀賞を獲得いたしました。

『Backlog World 2019』とは

株式会社ヌーラボの日本最大級のプロジェクト管理ツール”Backlog(バックログ)”のユーザーコミュニティである”JBUG(ジェイバグ)”が主催した、プロジェクト管理に関わる全ての方のための祭典です。
Backlog Worldとして2回目の今年は、「プロジェクトマネジメント×働き方改革」というテーマで、 数々のセッションやワークショップ、情報共有の場、Good Project Award(表彰イベント)などでプロジェクト管理に関する知見を相互に高め合うことを目的としています。
2019年1月26日(土)、秋葉原UDXにて開催されました。
https://backlogworld2019.jbug.info/

『Good Project Award 2019』とは

2018年〜2019年に活動したプロジェクトの課題やそれに対するアクション、その結果得られたことのストーリーを通し、プロジェクトマネジメントのヒントが共有されることを目指したアワードです。
Backlog Worldイベント内コンテンツとして「Good Project Award 2019」というピッチコンテストが開催され、来場者投票と審査員の審査により、最も素晴らしいものを表彰します。

『Good Project Award 2019』への応募経緯

アワードの存在を知ったCTOの和泉さんから「だしてみたら？」ともちかけてもらったのがきっかけです。
マイオペは2018年の頭から立ち上げ開始し、7月ごろにリリースをしました。Backlogは使用していなかったのですが、応募条件に利用有無は問われていなかった、応募することにしました。

『Good Project Award 2019』に登壇するまで

エントリーフォームより応募

2018年末頃に、プロジェクトの目的や結果、熱い想いを書きました。

• エントリーについての情報
  https://backlog.com/ja/blog/good-project-award2019/

ピッチコンテスト出場決定

2019年1月上旬に、アワード実行委員会より一次選考通過の連絡が届きました。

• 一次選考通過したプロジェクトがお知らせされています！
  https://backlog.com/ja/blog/good-project-award-2019-nominated/

ピッチコンテスト当日

一次選考通過した他の4プロジェクトの方々と共に登壇しました。
マイオペからは、生産と開発の間をとりもつディレクションを担当している宇田川さんが発表しました。

• 見事最優秀賞をいただくことができました！
  https://backlog.com/ja/blog/good-project-award-2019-sitateru/

審査員からのコメント

ソリューションについてはプロではないが工場の現場をよく知っている人が、関係者をどんどん巻き込んで共感をベースにプロジェクトを推進していたという点がユニーク。
さらに、もっとも重要だと感じたのは言語の共通化。プロジェクトはいろんな部署の人が入っているが言語の共通化は意外とスルーされているところも多いのではないか。工場もエンジニアもわかる言語の共通化やアイコンをつかうことで、年齢・カルチャー・価値観など異なる人を巻き込んでいる点が素晴らしい。最終的に、スムーズな導入に繋がったのは、細かい点まで配慮されたプロジェクトづくりがなされた結果ではないだろうか。

最後に

先日、プロダクト名が入った盾が届き、みんなで喜びました！

※ここで言う「レビュー」とは、リリース判断の可否を決める機能のことではなく、デザインをブラッシュアップさせるための、批評とフィードバックそのものを指しています。

開発チームの一員としてのデザイナー

開発チームでのレビューのいいところ

悩ましいところ

デザインチームでレビューを始めた

レビューをしてみる

3週間やってみて

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

Follow @shinobu_shiva

シタテルのウェブページはWordpressで運用されています。

https://sitateru.com/

なんと！今後の世界展開（あるのか！？）を目指して多言語化を行いました！！

多言語化するにあたってプラグインなど色々と調査した結果Polylangというプラグインがとても使いやすかったので紹介します。

Polylang

どんなプラグイン？

Wordpressウェブサイトの多言語化をサポートしてくれるプラグインです。

機能としては

• ポストやページ、メディア、カテゴリ、タグ、メニュー、ウィジェットなどの翻訳
• urlによる言語の切り替え
• 言語切り替え機能がウィジェットやナビゲーションメニュー
• プログラムによる言語判定
  などなど。

自動翻訳を組み込むこともできるようになっていますが、今回はすべて手動で翻訳しました。

軽く使い方

インストールはプラグインメニューから新規追加で行なえます。

が、今回はProバージョンの機能を使いたかったので、Polylangのウェブサイトからライセンスを購入し、Proバージョンのバイナリを入手して、圧縮ファイルをアップロードする形でインストールしました。

Proバージョンだと言語間でURL末尾が同じものにできるなどの追加機能があります。
ウェブサイトで使用しているJavascriptのライブラリの都合でこれが必須だったのでライセンス購入しました。

プラグインをアクティベートすると、メニューに「languages」が追加されます。

詳しい設定の仕方はこちらを参考にさせていただきました。わかりやすい！

多言語対応化WordPressプラグインならPolylangが秀逸！その特徴と使い方

Custom post type

独自の投稿テンプレートを使えるようにする「Custom post type UI」というプラグインを使っているのですが、Polylangはこれにも対応してくれています。素晴らしい！

PolylangのAPI

ページなどWordpressの機能で作られている部分は設定画面から多言語化できるのですが、シタテルのサイトではヘッダーなどテンプレートにPHPでゴリッと記載している部分もありました。その辺りはPolylangのAPIを使って言語による切り替えなどを実装することで実現できます。

PolylangのAPI

こういうのがしっかり揃っているところも、このプラグインの素晴らしいところですね。

まとめ

ということで、いくつかの候補の中からこれを選んで正解だった気がします。

今回はサービスページの英語対応をしましたが、ユーザー登録やログイン後はまだ日本語のみですので、引き続き多言語化をすすめていきます！世界中で衣服生産のプラットフォームとして、皆さんに価値が提供できるようにがんばります。ご期待ください！

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

SPECというサービスのバックエンド開発などを行っています。

今回は前回の続きで、Alexaスキルの作成について書いていきます。


今回は、前回作成したスキルから呼び出されるLambdaを作成します。

まずAWSコンソールにログインして、Lambda - 関数の作成に行きます。

そこから「一から作成」、「設計図」などが選べます。

「設計図」でalexaを検索すると、
それぞれのスキルタイプに合わせたsdkが用意されています。
使用したいタイプのsdkがある場合は、それを使用しましょう。

今回はとても単純なスキルを作成したので、「一から作成」を選択します。
いろいろな言語が選べますが、今回はNode.jsで作成しました。

関数を作成すると、シンプルなレスポンスを返す関数が書かれているので、その中身を変更します。

今回作成したスキルは、「言葉を逆さまにする」です。
シンプル...！

コードを記述します。

exports.handler = async (event) => {
  const word = event.request.intent.slots.word.value;
  const response = {
    "version": "1.0",
    "response": {
      "outputSpeech": {
        "type": "PlainText",
        "text": word.split('').reverse().join('')
      },
      "shouldEndSession": false
    },
    "sessionAttributes": {}
  };
  return response;
};

こんな感じになりました。

responseの形式について、詳しくは応答の形式を参考にしてください。
「intent.slots.word」の部分の「word」は前回設定した「スロット名」に対応します。

次にこのLambdaを呼び出すトリガーを設定します。

「トリガーの追加」から、「Alexa Skills Kit」を選択して、スキルID（alexa developer consoleを参照）を設定します。

alexa developer consoleでテストしてみましょう。

前回、スキルの呼び出し名とサンプル発話を設定しました。

テスト画面で、

「<スキルの呼び出し名>を開いて、<サンプル発話>おはよう」と入力すると‥


ちゃんと逆さまにして返してくれましたね！

シンプルなスキルですが動くと面白いと思います。


今回はここまでにします。

次回は実機でのテストとスキルの公開について書ければと思います。

ありがとうございました！