2019年6月3日月曜日
書評『進化的アーキテクチャ ―絶え間ない変化を支える』
どういう本か・総評
適応度関数
アーキテクチャの分類・マイクロサービス
- モノリス(3層レイヤ化モノリス等を含む)
- イベント駆動アーキテクチャ
- SOA
- マイクロサービス
- サーバレス
モノリスを構築できないとき、なぜマイクロサービスがその答えだと思うのか。
マイクロサービスという名前にひっかからないようにしてほしい。各サービスは決して小さい必要はない。むしろ有効な境界づけられたコンテキストを捉えることが必要なのだ。
サービス境界分割の手法
- ビジネス機能グループ
既存のビジネスコミュニケーション階層を反映する。コンウェイの法則に従う。 - トランザクション境界
トランザクションは最も分離しにくい要素である。 - デプロイメント目標
デプロイ頻度が異なる箇所を境界とする。
コンウェイの法則/逆コンウェイ戦略
システムを設計するあらゆる組織は、必ずその組織のコミュニケーション構造に倣った構造を持つ設計を生み出す。
ゆえに、チーム外の人間が所管する業務フローやコードにはできるだけ影響を及ぼさないように設計・実装しようとする(調整範囲をチーム内に閉じようとする)力学が働く。
結合よりも重複
マイクロサービスは無共有アーキテクチャを形成する。その目標は、できるだけ結合を減らすことだ。一般的に、結合よりも重複の方が望ましい。
ツールがあまりにもコードの再利用を容易にしてしまったせいで、現代の開発者は、たやすく結合できてしまう環境の中で適切な結合を行うことに悪戦苦闘している。
例えば、 CatalogCheckout サービスと ShipToCustomer サービスの両方が Item という概念を持つ。両方のチームが同じ名前と同じプロパティを持つので、開発者はサービスをまたいでそれを再利用しようと試みる。それが時間や労力の節約につながると考えるからだ。
けれど、それは労力を増やす結果となる。なぜなら、コンポーネントを共有する全てのチームが変更を伝搬しなければならなくなるからだ。一方、コンポーネントを結合せずに各サービスにItem があり、必要な情報だけをCatalogCheckout から ShipToCustomer に渡す場合は、それらは独立して変更することが可能だ。
開発者が再利用可能なコードを作成する場合、開発者は最終的にコードを使用する無数の方法に対応するための機能を追加する必要がある。その将来の保証全ては、開発者がコードを単一の目的のために使用することをより難しくする
腐敗防止層を設ける
デプロイに関するプラクティス
取っ掛かりをつかみたい人にはおすすめできるかと思います。
2019年5月8日水曜日
プログラミング・ゲーム
シタテルでバックエンドエンジニアをしている熊谷です。
今日は、プログラミングを学べるゲームやアプリの紹介をしたいと思います。
まず1つ目は、「Swift Playgrounds」です。
これはAppleが出しているiPad用のアプリで、キャラクターを動かすなどのプログラミングを、ゲーム感覚で学ぶことができます。
アプリ自体は前からあったのですが、最近やっと少し触ることができました。
画面イメージとしては、こんな感じです。
2019年4月23日火曜日
同時に複数のマシーンで同じ操作をする with Tmux
sitateruのエンジニア北爪です。
複数のシェルで同じ操作をしたい時ってないですか?
- ログを一箇所に集めてないけど、アプリケーションサーバーが複数台ある
- 複数台同時にtopコマンドで負荷をまたはtailコマンドでログを調査したい
など調査段階でAnsible, Fabやcapistranoで操作するほどではなく、複数のサーバーを同じようにインタラクティブに操作したいという要求はあるように思います。
今回は複数のシェルに対して、分割された画面をみなが同時に操作、そのコマンドラインの結果を参照することが可能です。
tmuxを風にいうと、一つのpaneに行うキーボード操作をそのpaneが存在しているWindow内すべてのpaneキーボード操作を同期することができます。
この機能は、tmuxの synchronize-panes 機能です。tmuxを使ってない人には導入する大きなメリットの一つになるのではないかとお思います。デフォルトです。
http://man.openbsd.org/OpenBSD-current/man1/tmux.1#synchronize-panes
使い方
1. tmuxを起動し、複数のpaneを作成がある状態で2. tmuxにbindしてあるtmuxのprefixキーを入力した後で、 `:` を入力します
(余談私は ctrl-t にしています)
3. tmux用のコマンドが立ち上がるので、そこに、
set synchronize-panes on
を入力します。4. そうするとなんと!表示されているpane(分割した画面) に同じキーボード操作が入力されます
5. もう同期したくなくなったら、
set synchronize-panes off
にて解除することが可能です。以上です。
2019年4月16日火曜日
Vue.jsとScoped CSSとz-indexの話
こんにちは、シタテルの茨木です。
突然ですが、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: 私です
2019年4月8日月曜日
地方活性化のイベントに参加してきました
イベントの参加のために久しぶりに東京に行きましたが、渋谷駅から出られなくなりそうになりました。
あらためてお上りさんには厳しい街であることを実感しました。
先日「スマホで見つける地方のしごと」というシンポジウムにパネラーとして
参加させていただきました。
内容を簡潔にすると「首都圏での離職と地方へUIJターンを希望する方と地方企業の
マッチングを進めて地方を活性化していこう」というイベントでした。
200名以上の方が参加され、各者の熱いプレゼンもありここから少しづつ
地方へ人材が広がっていってくれるのではないかと感じることができたイベントでした。
そんなイベントについて簡単にレポートしてみたいと思います
プレゼンター、パネラー
プレゼンター、パネラーとして以下の方々が参加されていました。- 求人サイト運営企業
- 地方自治体
- 商工会議所
- 地方への移住者(Uターン)
イベントの大まかな流れ
- 厚生労働省からの本取組みにおける施策のついての説明
- 求人サイト運営企業からのプレゼン
- 地方自治体、商工会議所、移住者からのプレゼン
- パネルディスカッション
各者の主張について
各者の主張について個人的に印象的だったことについて書いていきます。求人サイト運営企業
求人サイト運営企業の方からのプレゼンで印象に残ったのは以下の2点でした- 転職は孤独であり寄り添うことに注力したい
- 転職は一般的になっている
転職は孤独であり寄り添うことに注力したい
転職にする時は非常に多くの「不安」と戦うことになると思いますが共有・共感者が少ないといった問題があり、そこに「賛成」と後押しすることで生き方を一緒に考えていこうといったものでした。個人的には人材の流動性が高まることはいいことだと思っているので求人サイト側がこういったことを考えていただけるとありがたいなと思いました。
ちなみに弊社のBaseValueの一つに「よりそう」と言葉が定義されており、大きく以下の3つで構成されています。
- リスペクトする
- 声を聴く
- 感動を与える
シタテルの目指す未来|シタテル株式会社
転職は一般的になっている
転職をポジティブに捉えているのは全世代で5割以上となっているということでした。プレゼンターの方の言葉ですと「ポジティブ、ネガティブというより転職は一般化してきている」といわれていることがとても印象的でした。
地方自治体・商工会議所
地方自治体・商工会議所でも地方企業の魅力や人材育成・確保に向けた種々の取り組みをされているのがすごく伝わってくるプレゼンでした。
印象的だったのは以下の3つです。
- 人材育成・確保に向けた種々の取り組みをされている
- コメリは新潟の上場企業だった
- 地域資源を生かしたビジネスを展開
人材育成に向けた種々の取り組みをされている
小型ロケットの製造から打ち上げを通じた技術者の育成を行なっており、実際にロケットの打ち上げを成功されている地方がありました。企業の枠を超えた技術者の連携や情報交換、人脈の育成などを推進されているとのことで地方を活性化していくために技術を磨いていくことは大切だなと感じました。
またUターンを促進するために東京からの無料のバスを出していたり、子供の時からものづくりフェアを実施して小学生に体験し興味を持ってもらい、ものづくりの楽しさを感じてさらに地元企業への魅力に気づいてもらうなどの取り組みをされていることも印象的でした。
コメリは新潟の上場企業だった
家の近くにコメリというホームセンターがあり、品揃えもよく安いのでよく利用させてもらっています。その企業が新潟の三条市発祥の企業でしかも上場しているのは知りませんでした。
さらに三条市には上場しており本社をおいている企業が多くあり、人口1人あたりの上場企業数は東京、大阪についで3位とのことです。
地域資源を生かしたビジネスを展開
「もくロック」というブロックの木製玩具があるのですがこれの原材料となっているのが地元の金属加工目メーカーが生み出しものということでした。
地元の資源を使い、地元の企業が新たなビジネスを生み出すということは素晴らしいなと思い印象的でした。
地方への移住者
広島への移住者の方でまちづくりのコンサルタントを行われている方でした。非常に広島への熱い気持ちを持っている方で印象的だったのは以下の2点です。
- 経営者との距離が近くなった
- 「自分がいなくても回る」から「自分がいるから回る」
経営者との距離が近くなった
頻繁に経営者と面と向かって話す機会があり東京にいる時にはなかったことであるということでした。「自分がいなくても回る」から「自分がいるから回る」
東京よりも人口が少なくなるので自分の役割や影響の割合が多くなるため、自分を必要とされる、頼られることが強く感じられるようになったということでした。ぜひシタテルへ!
弊社シタテルですが本社は熊本にあります。私も東京で13年程働いておりましたが2018年より熊本へUターンしてシタテルで働いております。
転職についての不安は色々とありましたが1つだけ挙げるとすると
前職ではほとんど管理業務を行なっており、実務でのプログラミングは5年以上していない状態でした。
そんな状態でどこまでやくに立てるか不安では、転職してまずは1年やってこれることができました。
まだまだ未熟で周りに迷惑をかけてはいますがシタテルのエンジニアの方はみんな教えたがりで優しく、わからないことがあり聞いたら、進んで色々と教えてくれるのでいつも助かっています。
私のように少しプログラムから離れてしまったがまた現場に戻りたいと考えている方もいるのではないかと思いますので、もし首都圏にて「また現場でプログラミングをしたい」、「いろんな技術に触れたい」という方、かつ「地方へ移住してみたい」という方がいらしたぜひシタテルへお話を聞きにいらしてください!
エンジニア│熊本or東京勤務 - シタテル株式会社のWeb エンジニア中途・契約・委託の求人 - Wantedly
少しだけ熊本の風景を
参加したイベント時に使用した風景写真です、熊本には自然が多く、いろんな風景を楽しむことができます。近くの公園で桜満開になった時
家族でよく出かける天草の海
2019年3月12日火曜日
初めて見るとぎょっとするかもしれない JavaScript の構文 4 選
ドット3つ ...
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) を実行するのと同じ
ビックリマーク2つ !!
ビックリマークふたつの記法もあるのか!!とびっくりびっくりしたことがあります。
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
関数のアロー記法 () => {}
function
という予約語を使うのが常でした。setTimeout(function() {
console.log('Hello!')
})
() => {}
を使って書くこともできるようになりました。setTimeout(() => {
console.log('Hello!')
})
function
と () => {}
どちらを使ってもよいのですが、1つだけ挙動の異なる点があるので注意が必要です。何が異なるのかというと、メソッド内での
this
の扱いです; function () {}
の場合はメソッドの呼び出し元のオブジェクトを指しますが、 () => {}
の場合はメソッドが記述された文脈上のオブジェクトを指します。つまり、 function () {}
の場合は this
が動的に変わるのに対して () => {}
の場合は this
が固定されます。
テンプレートリテラル `${}`
printf
のようなメソッド。メソッド名は言語によって様々ですが、世の中の大半の言語で提供されている構文です。`
で囲います。 (バックチックを約物に用いる言語ってあまりなかった気が…)${}
と書きます。let username = `山田太郎`
let message = `ようこそ、${username}さん!`
console.log(message) // => "ようこそ、山田太郎さん!"
let body = `${client.name}様
いつも大変お世話になっております。
${company.name}の${staff.name}です。
${message.content}`
console.log(body) // => "山田太郎様\n\nいつも大変お世話になっております。\n〇〇株式会社の...
2019年3月4日月曜日
Good Project Award 2019で最優秀賞をいただきました!
こんにちは!シタテル株式会社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年末頃に、プロジェクトの目的や結果、熱い想いを書きました。
ピッチコンテスト出場決定
2019年1月上旬に、アワード実行委員会より一次選考通過の連絡が届きました。
- 一次選考通過したプロジェクトがお知らせされています!
https://backlog.com/ja/blog/good-project-award-2019-nominated/
ピッチコンテスト当日
一次選考通過した他の4プロジェクトの方々と共に登壇しました。
マイオペからは、生産と開発の間をとりもつディレクションを担当している宇田川さんが発表しました。
- 見事最優秀賞をいただくことができました!
https://backlog.com/ja/blog/good-project-award-2019-sitateru/
審査員からのコメント
ソリューションについてはプロではないが工場の現場をよく知っている人が、関係者をどんどん巻き込んで共感をベースにプロジェクトを推進していたという点がユニーク。
さらに、もっとも重要だと感じたのは言語の共通化。プロジェクトはいろんな部署の人が入っているが言語の共通化は意外とスルーされているところも多いのではないか。工場もエンジニアもわかる言語の共通化やアイコンをつかうことで、年齢・カルチャー・価値観など異なる人を巻き込んでいる点が素晴らしい。最終的に、スムーズな導入に繋がったのは、細かい点まで配慮されたプロジェクトづくりがなされた結果ではないだろうか。
最後に
先日、プロダクト名が入った盾が届き、みんなで喜びました!