そるでぶろぐ

こんにちは。ソリューション開発部 HoloLens分科会の中川です。 先生、花見が、、、したいです。 季節が巡るのはホントに早いですね。 ふと思い立って花見をしようとしたら、なんととっくに桜は散っていたんですよ。 満開の時は何となく、いつでもできるから、という気になって結局やらず。 桜が散ってから花見がしたくなる気持ち、わかりますよね？ しかし2018年になった今、我々にはMR(Mixed Reality)という技術があるではないですか。 肌寒い中で無理して冷たいビールを飲むなんて時代遅れですよ。 外が寒ければ屋内で花見すればいいじゃない。 桜が散ってしまったなら、また咲かせればいいじゃない。   そう、時代はMR花見だ！ HoloLensで花見をしよう！！   MR花見を作るのだ。 というわけで、MR花見アプリを作りましょう。 終業時刻までに完成させて、定時になると同時に花見をしたいので急いで作らなければなりません。 基本は過去の記事「MixedRealityToolkit-Unityを使ったHoloLens開発クイックスタート」の手順そのままです。 円柱の代わりに桜の木のCGを用意すればいいだけです。 慣れれば5分もかからない作業です。 桜の木のCGが手元になかったので、Freeの木のAssetをダウンロードし、緑の葉の部分を桜色に塗りつぶして代用することにしました。  普通の緑の木  葉をピンクにするだけで、桜っぽく見えてくる不思議。  MRならサイズは自由なので、机の上に桜を咲かせることもできます。  無事に花見ができました。 キャプチャした画像だと桜の存在感が薄いですが、HoloLensを通してみるともっときれいに見えます。 しかしHoloLensをかけているのは私だけなので、他のメンバーはただ単にオフィスで一杯やっているだけですが。   MRと季節行事は相性がいい。 VR花見だと手元のビールが見えないので困りますが、MRなら普段通りに花見をすることができます。 現実とヴァーチャルを融合するMRのお手本のような活用方法ではないでしょうか。 夏以降も、MR花火大会、MR月見、MRハロウィンやMRホワイトクリスマスなどなど、いろいろな応用ができそうです。

はじめまして。プラットフォーム技術部の山崎です。 オンプレ環境のEOSL対応から始まったAWSリプレースプロジェクトで、インフラ周りの設計構築を担当しています。そこで得たナレッジをご紹介していきます。 今回はAWS LambdaのVPC内ヘの配置についてです。手軽にできるものと思っていたら、環境設定でいくつか考慮すべきことがありましたので、配置する際の注意点をまとめます。VPC内にLambdaを置くケース まずはじめに、Amazon Web Serviceの公式見解では、LambdaをVPC内に置くメリットは基本的にないというスタンスです。しかし、Amazon EC2やAmazon RDSなど、VPC内にあるリソースとLambdaで内部通信する場合はVPC内への配置が必要となります。例えば外部公開しないADサーバーとLambdaで認証情報をやりとりする、など。 [blogcard url="https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/best-practices.html#lambda-vpc"]VPC内に配置する際の注意点 主に5つです。 LambdaをVPC内に配置すると、Lambda実行時にENI（仮想ネットワークインターフェース）が付与されるようになります。それに伴い考慮すべきことがあります。 セキュリティグループの設定 Lambdaに対してセキュリティグループが設定できるようになります。 EC2/RDS等のVPC内リソースのセキュリティグループにて、Lambdaからのアクセスを許可しましょう。設定内容はLambdaのセキュリティグループや、Lambda専用サブネットを作成していたらそのサブネットなど、環境により適切な方法で設定します。 Lambdaのセキュリティグループは必要に応じて設定しますが、API Gatewayなど呼び出し元が特定できない場合はデフォルトのままとすることもあります。 IAMロールの設定 Lambda自身がENIを作成/削除できるようにするため、Lambdaに対してIAM（Identity and Access Management）権限を付与します。既にIAMポリシーとして「AWSLambdaVPCAccessExecutionRole」が用意されているので、Lambda用のIAMロールを作成する際にこのポリシーをあてて設定することも可能です。 所属サブネットの残りのIP 当然ながらVPCサブネットのプライベートIPアドレスを浪費するので、サブネット内の残りのIP数が枯渇しないよう注意してください。AWSのベストプラクティスでは、他のAWSリソースに影響が出ないようLambda専用のサブネットを用意することを推奨しています。冗長化のため、Lambdaも他のAWSリソースと同様マルチAZ（アベイラビリティゾーン）で構成します。 起動スピードが若干遅くなる Lambda実行時、ENIを作成しLambdaに付与する時間（数秒～数十秒程度）がかかります。 ただし、時間がかかるのは初回のLambda実行時のみで、それ以降は基本的には付与されているENIを使いまわします。Lambda実行リクエストが一定時間なければENIは自動削除されます。 なお、遅延時間分はLambda実行時間にはカウントされないため、その分の料金は計上されません。どうしても初回遅延が許容できないというのであれば、定期的にダミーのLambda実行をしてENIを自動削除させない、といった方法も考えられますが、仕組みは自身で構築する必要があります。 VPC外でも、厳密に言うとENI作成ほどではありませんがLambda初回実行時は若干時間がかかります。「コンテナ」と呼ばれるLambda実行環境を作成するためです。外部ネットワークと通信する際は、、、 ここが一番のポイントです。外部ネットワークと通信する際は、NATゲートウェイ等の設定が必要です。VPC内にあるLambda（ENI）にはパブリックIPが付与されないので、外部ネットワークと通信することができません。そのため、VPC内のパブリックサブネットにNATゲートウェイもしくはNATインスタンスを設定します。 結果、Lambdaの送信元IP（グローバルIPアドレス）は固定されることになります。 NATゲートウェイの場合は、冗長化を考慮するとAZ毎に設定が必要になるため、NATゲートウェイのコストが2,3倍となることも考えられます。まとめ VPC内にLambdaを置く場合は通信関連の考慮が必要になり、場合によってはランニングコストが増えるかもしれません。「お金がかかるのでNATゲートウェイを使用しない」という方針で設計すると、このようなケースでどうしても必要になることもありますので、アプリケーションや認証関連でLambdaを内部通信させる必要があるのか、事前に把握しておくとよいと思います。

こんにちは、ソリューション開発部 認定スクラムマスターの本間(manhole)です。 この一週間で大小合わせて15回くらいのふりかえりをしています。 (スクラムにはスプリント毎のふりかえりが組み込まれていますが、改善活動の一環としてふりかえりの頻度や対象を試行錯誤しています。← またの機会に書いてみたいと思います。) さて数ヶ月前になりますが、ARKメンバが参加している株式会社D2C様のスクラムチームが、本間が参加している株式会社アプレッソ様のスクラムチームを見学しました。(こちらの記事です。← 本間はアプレッソチーム側にいました。) そして今回はターンを交代し、アプレッソ様のチームがD2C様のスクラムを見学することになりましたので、交流会とその後のことについてご紹介します。 (以下、敬称略とさせていただきます。) 交流会に望む 交流会に向けて、両チームに良い影響をもたらせるよう、個人的に次のようなことをアプレッソチームの目的にしていました。相手チームの良い点と、改良できそうな点を見つける。 見つけた良い点と改良できそうな点を、フィードバックする。 見学したことを自分たちの活動に活かせるよう、ふりかえる。そして当日です。朝から夕方まで、スクラムイベントの幾つかを見学させていただきました。ふりかえり (スプリントレトロスペクティブ) 次スプリントのプランニング (そして懇親会へ...)これらのイベントは普段は日を分けて開催しているとのことですが、今回は多くのイベントを見学できるよう1日に調整していただきました。 また、交流会のために大人数が入れる会議室を用意していただきました。 「感謝っ・・・・！」「圧倒的感謝っ・・・・！」(元ネタ) 持ち運び可能なタスクボード 最初に目についたのが、タスクボードでした。 壁不足問題を改善するために「Smart Task Board」を購入したと聞いていたので、目にするのを楽しみにしていたのです。 屏風ふうに畳めて持ち運びしやすいという触れ込みの製品でして、実際に見学会の準備中に会議室へ担がれてきました。(見学者の視線が集まります) 軽く、立てかけなくても自立するなど、使い勝手が良さそうでした。(アプレッソチームの物欲が高まった瞬間です) アプレッソでの工夫が取り込まれてる！ そのタスクボードを見ると、レイアウトや付箋の使われ方に既視感があります。尋ねると、アプレッソでの取り組みを輸入したとのことです。(前回の記事からも、取り入れようという意気込みが伝わってきます。)DONEのエリアが、日毎に分かれている。 → アプレッソチームでは日々の進捗をトラッキングしやすくするために始めたのですが、ふりかえりの際にタイムラインとして活用されるという、予想外の発展を遂げています。 計画したタスクと、予定外の追加タスク付箋を別の色にしている。 → 追加タスク付箋があることは、計画漏れがあるということです。ふりかえりで役立っています。 タスクボードに、その日のできごとや感じたことなどの付箋が貼られている。 → その付箋はKeepやProblemなどを示していて、ふりかえりのインプットとして使います。 ふりかえりになってから思い出すのでは、時間が掛かるのと、漏れが生じてしまうためです。交流会を実施して良かったと感じました。ありがたいです。 チーム活動っていいですね そして、終日に渡ってスクラムイベントを見学させて頂き、スクラムの中身は現場ごとに異なるのだな... と改めて実感しました。

本連載では「まるごとおまかせZabbix」をより便利で有用なサービスとするために日々奮闘中の齊藤(沙)がアークシステム ザビ家の一員として、Zabbix に関する日々の取り組みやナレッジをご紹介していきます！【わたしに♥おまかせ Zabbix①】Zabbixの構成要素とパラメーターについて 【わたしに♥おまかせ Zabbix②】Zabbixサーバーと内部プロセスについて 【わたしに♥おまかせ Zabbix 号外】Interop Tokyo 2017 Zabbixブースに出展！ 【わたしに♥おまかせ Zabbix③】Zabbixの内部プロセスについて-続き 【わたしに♥おまかせ Zabbix④】Zabbixのデータベースについて 【わたしに♥おまかせ Zabbix⑤】Zabbixのデータベースについて - アイテム編（本記事）本サービスの詳細や、Zabbixを活用したソリューションにご興味をお持ちの方がいらっしゃいましたら サービス紹介ページ からお気軽にお問合わせ下さい。こんにちは！プラットフォーム技術部の齊藤(沙)です。 前回はZabbixが監視設定や履歴データを保管するデータベースの中でもホストに関連するテーブルについて確認しました。今回はアイテムに関連するテーブルについて確認していきます。 Zabbixを知ろう -Zabbixのデータベースについて - アイテム編 私たちアークシステムでは、パフォーマンスの観点からZabbixにおけるデータベースはMariaDB(Mysql)の使用を推奨しています。本記事では、Zabbix3.0、mariadb5.5の環境を用いて確認していきます。 アイテムに関する情報について 主要テーブル一覧 監視項目であるアイテムに関する情報は主に以下のテーブルに格納されています。 [crayon-5ad72a30794a4936409233/] itemsテーブル詳細 まずはアイテムに関する主要な情報が格納されている「items」テーブルについて詳しく確認していきます。 以下は「desc items;」コマンドの出力結果です。 [crayon-5ad72a30794b3614635475/] アイテムはZabbixの仕様上、ホストまたはテンプレートに紐付く形で存在します。そしてZabbixのデータベースの中では、ホストもテンプレートも共に「hosts」テーブル内に情報が格納されます。 「items」テーブルに「hostid」が存在して簡単に取得できそうなので、まずはホストに紐付くアイテムの一覧を取得して見たいと思います。 ホスト＋テンプレートのアイテムについて SQL文

本連載では「まるごとおまかせZabbix」をより便利で有用なサービスとするために日々奮闘中の齊藤(沙)がアークシステム ザビ家の一員として、Zabbix に関する日々の取り組みやナレッジをご紹介していきます！【わたしに♥おまかせ Zabbix①】Zabbixの構成要素とパラメーターについて 【わたしに♥おまかせ Zabbix②】Zabbixサーバーと内部プロセスについて 【わたしに♥おまかせ Zabbix 号外】Interop Tokyo 2017 Zabbixブースに出展！ 【わたしに♥おまかせ Zabbix③】Zabbixの内部プロセスについて-続き 【わたしに♥おまかせ Zabbix④】Zabbixのデータベースについて（本記事） 【わたしに♥おまかせ Zabbix⑤】Zabbixのデータベースについて – アイテム編本サービスの詳細や、Zabbixを活用したソリューションにご興味をお持ちの方がいらっしゃいましたら サービス紹介ページ からお気軽にお問合わせ下さい。こんにちは！プラットフォーム技術部の齊藤(沙)です。 前回はZabbixサーバーの内部プロセスについて確認しましたね。 今回はZabbixが監視設定や履歴データを保管するデータベースについて確認していきます。 Zabbixを知ろう -Zabbixのデータベースについて 私たちアークシステムでは、パフォーマンスの観点からZabbixにおけるデータベースはMariaDB(Mysql)の使用を推奨しています。本記事では、Zabbix3.0、mariadb5.5の環境を用いて確認していきます。 ホストに関する情報について 主要テーブル一覧 監視対象であるホストに関する情報は、主に以下のテーブルに格納されています。 [crayon-5ad72a3079d53262272529/] hostsテーブル詳細 まずはホストに関する主要な情報が格納されている「hosts」テーブルについて詳しく確認していきます。 以下は「desc hosts;」コマンドの出力結果です。 [crayon-5ad72a3079d5c635179428/] Interfaceテーブル詳細 そして、以下は「desc interface;」コマンドの出力結果です。 [crayon-5ad72a3079d60019580205/] どちらのテーブルにも「hostid」というカラムが存在しますね。このカラムを利用してホストに関する情報が格納されているそれぞれのテーブルに対してリレーションを張っているようです。 実際に「hosts」テーブルの「hostid」を利用して「Zabbix

こんにちは。ソリューション開発部 認定スクラムマスターの飯出(いいで)です。 システム開発をしていると頻度はチームによってまちまちですが、不具合に遭遇することが良くあると思います。 えっ、不具合なんて全く発生しない！？すばらしいチームに所属されているようですね。残念ながら、私たちのチームはそのようなチームではありません。多少の不具合に遭遇することはあります。 今回はスクラム開発における不具合発生時の対処法について書いてみようと思います。あくまでも経験を踏まえた個人的な考え方ですが、参考になれば幸いです。 この記事を書こうと思った経緯 最近、以前に比べて不具合に遭遇するケースが多いと感じています。 私がスクラムマスターとして従事していたチームですが、現在はスクラムマスターのポジションを後輩に任せ、私はプロダクトオーナー（PO）のひとりとして従事しています。もしかしたら、不具合に遭遇するケースが多いと感じているのは、その立場が変わったからかも知れません。あくまでも、主観です。 不具合とは 不具合とは、「システムが想定通りに動作しない状況。および、その状況の原因となっている問題」を指す言い方ですね。「障害や欠陥、不良品、バグという言葉を使うことを回避するための、日本語特有の言い回し」とも言われます。 ここでの不具合は、スクラム開発において「プロダクトバックログ・アイテム（PBI）が完了（done）した後に見つかった不具合」、端的に言えば「スプリントを逃れた不具合」とします。すなわち、スプリントで実装中の PBI における不具合ではないということです。 実際の判断基準はチームによって異なると思いますが、実装上の不具合や要求を満たしていなかったもの。ですね。 不具合の対処方法 スクラム開発における不具合対処法を、（良きも悪きも）いくつか並べてみます。 半日程度で直るならPOと相談してすぐ修正する 私が認定スクラムマスター研修を受けた際に James O. Coplien氏 がそう話していました。後述しますが、付け焼き刃で対処しないことが重要だと思います。そう考えると、本当に軽微な不具合が対象となるでしょう。 優先順位の低いPBIとの入れ替えをPOと合意する 開発チームが対応可能と判断している場合において、優先順位の低い PBI との入れ替えを PO と合意し、不具合修正に着手するやり方です。これも、軽微な不具合が対象になるのではないかと思います。 POがPBIのひとつとして優先順位付けをする スクラム開発において、一番ポピュラーなやり方ではないでしょうか。即座に不具合修正に着手せずに、最速で次スプリントでの対処となるパターンです。言わずもがな、次スプリントでの着手となる場合は、PO が優先順位を高く設定した場合です。この場合において、開発チームは不具合修正のストーリーポイントを算出します。 POが「不具合の緊急度が高い」と判断した場合 PO の判断により不具合における業務影響が大きい等と判断した場合、スプリントの中止（スプリント緊急停止）を行います。重要なのは「PO による判断であること」です。私たちのチームでは、PO がスクラムマスターに必ず助言を求めるようにしています。これは、「スプリント緊急停止の乱発を抑えること」と「スクラムマスターがより良い対処（処方箋）ができるように」という効果を期待しています。 不具合の発生に備えた余力を残しておく 予め開発チームのキャパシティから不具合への対応時間を差し引いておくやり方です。「どのくらいの余力を残しておけば良いか」という課題がありますが、各スプリントで割り当てられた不具合修正の履歴から算出できるのではないかと思われます。 ただし、不具合修正スプリントを作ることは推奨しません。なぜなら、不具合をためこんで、あるタイミングで一気に消化する悪い癖が付く。 PO は PBI に対して、常に優先順位付けをすること。それを怠ってしまう。という理由です。 付け焼き刃で対処しない 「本番環境で動くからいいや。」ではいけません。自動化されたテストケースが存在するのであればそれも修正対象ですし、必要に応じてドキュメント修正も発生するかも知れません。何も言わないと、BTS

こんにちは、ソリューション開発部の本間です。 この記事は アプレッソ Advent Calendar 2017 の20日目です。アプレッソ Advent Calendar に協力会社も参加しても良いとのことで、書かせていただいています。 [blogcard url="https://qiita.com/advent-calendar/2017/appresso"] 去る9月に JUnit 5 がリリースされました! 「今すぐ JUnit 5 でテストを書きたい!」そんな前のめりになる開発者っていますよね。わかります、私もそんな一人です。 ですが現場のテストコードは JUnit 4 で書かれており、加えてテスト用の仕組みも

こんにちは。ソリューション開発部 情報発信分科会の飯出(いいで)です。 本業であるシステム開発業務の傍ら、このブログや当社採用サイトの維持・管理を一手に引き受けています。あくまでも本業の傍らでの作業ですが、結構楽しみながらやっています。 今回、先日リリースされた WordPress バージョン 4.9 "Tipton" の公開に合わせ、私のローカル環境も一新してみました。ローカル環境があると、ちょっとした修正を気軽に試したりできますし。 WordPress のローカル環境と言えば、XAMPP をインストールした後に WordPress をインストールするという手間が掛かり、面倒くさいですよね。しかし、Local by Flywheel を使うことによって簡単にインストールができるようになりました。 今回はその手順について紹介します。 Local by Flywheel のダウンロード Local by Flywheel にアクセスし、インストーラーをダウンロードします。サイト上にある「FREE