そるでぶろぐ

こんにちは。ソリューション開発部の中川です。 常識を打ち破れ 先日、MR花見という期待感を持てるテーマに対して微妙なスクリーンショットを公開してしまい、この数か月間寝付けない日々を送ってきました。 季節はもう夏だ、次はMR花火しかないだろう。 しかし、MR花見の悪夢を繰り返すわけにはいかない。何とかしなければ。 MR花見の問題とは、HoloLensをかけている本人はもっと花見っぽい風景が見えているのに、HoloLensのスクリーンショット機能で撮影すると、ホログラムが存在感を無くしてしまうという現象です。  ホログラムの出し方をいろいろ考えてみましたが、どれもうまくいかず、決定的な解決方法を見つけられていません。笑顔と釣り合わない残念な桜のようなもの。 でも、この目には見えていたんだ、もっと「それっぽい」花見の風景が。。。 この目には。。。 。。。 。。。 ？。。。この目で見えているならそのまま撮影すればいいのでは？常識の壁をぶち壊した瞬間。 そのまま撮影すればいいんだ、HoloLensの左目部分に直接スマホカメラをくっつけて撮影するんだ。   想像を超えてきた 自社オフィスの窓からスカイツリーが見えるので、その横で花火を打ち上げることにしました。 位置は少し違いますが、ほぼほぼ隅田川花火大会の再現です。 それでは、革命的方法で撮影したMR花火大会の様子をご覧ください。 注：本物の花火大会ではございません。 おおおお！ 低画質具合と相まって、想像以上にリアリティのある映像が出来上がりました。 周囲の同僚にこの動画を見せると、「いつ花火やってたの？」という素晴らしい反応が。 「これCGなんだぜ」と返す顔が思わずニヤけてしまいました。   ディテールにこだわる 花火を想定する場所（今回はスカイツリーの横）に打ち上げる時に考慮するべきポイントは「距離」です。 花火のサイズと爆発音の遅延に影響します。 サイズについては、せっかくのMRなので、好きなサイズに設定してしまいましょう。 今回はリアリティを持たせるために、音の遅延を再現してみました。会社からスカイツリーまでは4.21km。 温度t℃のときの空気中の音速は c＝331.5＋0.6t(m/sec) なので、夜の気温をおおよそ30℃とすると、 349.5m/sec となり、音の遅延は12.05秒です。 動画の音は12秒遅延させています。音を遅延させることで視覚＋聴覚で距離を感じることが出来るようになり、よりリアリティが増しました。他にも、Spatial Soundで音の大きさを変化させることもできますが、想像以上に音が小さくなってしまったため、今回はあえて程よい音量で聞こえるようにしました。 何もかもリアルに合わせるのではなく、多少の味付けをしてあげた方が強い印象の体験になると思います。   MR花火はかなりイケる MR花火は非常に満足のいく結果になりました。 演目までちゃんと作り込めば、一杯やりながら鑑賞するのに十分なクオリティです。天候にも左右されず、人混みにもまれることもない。 サイズも角度も思いのままなMR花火大会は、もしかしたら夏の風物詩に革命をもたらすかもしれません。

こんにちは、プラットフォーム技術部の佐藤です。 以前『【CVE-2017-5638 / S2-045】SELinuxポリシーのバグフィックスでTomcatアプリのRCEは防げるようになったのか』で、記事を書かせていただきました。 そのときは「リモートコード実行(RCE)を防げないかなー、防ぎたいなー」という目的に対してはあまり期待した結果には至らなかったですが、それでも SELinux 無効状態よりは防御力はあがる、ということを確認できたと思っています。 今回は SELinux の tomcat 用デフォルトポリシーをカストマイズして、更なる防御力アップを目指したいと思います。 今回の目標 RCE 脆弱性を突いて悪用されそうなものは /sbin, /usr/sbin, /bin, /usr/bin に配備されているコマンド群です。これらのパスに含まれるコマンドの多くは、タイプが shell_exec_t や bin_t となっています。これらの実行権限を tomcat

こんにちは。ソリューション開発部の桑原です。 先日、社内LT大会を開催いたしましたので、開催に至る経緯や当日の様子を紹介いたします。LT：Lightning Talksの略で、短ければ3分、長くても10分程度で終わる短いプレゼンのこと。ゆるゆるな雰囲気のなか行われることが多いです。きっかけ 社員どうしで熱く語りたいんだ 弊社社員には [blogcard url="https://twitter.com/arksystemsJp/status/1004655406306725888"] に紹介されるような技術的に優れた社員や、技術はもちろんのこと技術以外の方面に対しても勉強を続けている社員が多数在籍しています。しかし、普段はプロジェクト単位での働き方となるため、他のプロジェクトにアサイン中の社員が何に興味を持ち、どのようなことを勉強しているか、などが、どうしても見えにくくなってきます。 元々情報共有には積極的な会社ではありますが、忙しさが続くと、ついつい疎かになりがちです・・・ でも、他の社員が勉強していることって気になりますし、自分が勉強していることって他の社員にも伝えたいこともありますよね。 せっかく同じ会社にいるのだから、配属先プロジェクト、好きな言語や得意な技術分野などの垣根を取っ払い、何かしらのテーマについて社員どうしで熱く語るための機会がほしかったです。 深く議論することで自分の持ち得なかった視点や思考に触れることができ、広い視野や深い思考を手に入れるための良い機会になりますよね。 そうだ社内LT大会だ LT大会であれば時間も短いため登壇ハードルが低いうえ、数多くの社員の話を聞くことができそうです。 社内だからこそ自信がなくても登壇しやすかったり、聞きにくいような質問や他の人とは異なる意見をだすことのハードルが低い、などのメリットもありますね。 そういった思いから社内LT大会の実施をすることになりました。 企画から当日実施まで 企画 告知・準備 開催2ヶ月前に一度、部内で軽く告知をし、その後1ヶ月前に登壇者と聴講者の募集を全社に対して行いました。 他部署からも登壇者としての参加表明もありました。別の部署の社員から技術話を聞けるのはそうそうない機会だったのでとてもありがたかったです。 また、飲食つきの緩い雰囲気で社内LT大会をしたかったため、会社に“スポンサー”を依頼したところあっさり「OK」をいただきました。素敵な会社です。 実施 セッション内容は以下のようになりました。 登壇者が9名で、技術・非技術入り乱れているあたりは社内LTならではと感じますね。 タイトル 区分EAのDDLテンプレート機能を使って人生をリッチにしよう ツールハックメンタルケアについて マネジメントAIについて 技術MVにゃんちゃら 技術ふりかえりをしよう チーミングコンテナネイティブの時代 技術Microsoft :The Future Computedから読む未来の働き方 働き方改革Excelのショートカットを使いこなそう ツールハックAWS CodeDeployについて 技術  発表時間が5～10分で、質問含め一人あたりの持ち時間を15分とLTにしては長めの時間配分を設定してましたが、それでもギリギリだったかな。という感触でした。 ひょんなことで意見の違いが出ると、どこまでも深く議論出来てしまうので、発表内容に対する議論の時間をしっかりとっても面白いのかな。と思いました。 特にMVにゃんちゃらではバリデーションの置き場所に関して、あるべき論と現実論で休憩時間を過ぎても白熱した議論が続いていたのが印象的でした。エンジニア心をくすぐられる内容ですね。 やっぱりといいますか、議論が好きな社員が多いようです。ホワイトボードを使ってまとめもしてLT大会自体への振り返りもできました。 KeepもProblemとそれに対するTryもしっかり出てきたので、今後よりよいLT大会の運営ができそうです。 振り返り 社内LTの意義 今回の発端となった社員同士の情報共有はもちろんですが、 外部でのLT大会以上に間違いを恐れずに発信・質問ができることや、外部で発表するほどではないけど、なんとく発表したい。みたいな温度感で登壇できるのはやはり社内LT大会ならではだな、と感じました。 感想 企画時点では、忙しくて登壇者が集まらなかったら…、聴講者が来なければ…、盛り上がらなかったら…、などの不安はもちろんありましたが、まずはやってみるものですね。 チャレンジと失敗に寛大な文化にも後押しされた気がします。 また、「楽しかった」「またやるべき、やりたい」という意見を参加者からいただけたことが大変嬉しく励みになります。 今回のLT大会を単に楽しかった。で終わらせずに次、そのまた次のLT大会へと続けると同時に、LT大会以外でも情報共有がもっとしやすい、より良い土壌を作っていけたらなと考えております。

本連載では「まるごとおまかせZabbix」をより便利で有用なサービスとするために日々奮闘中の齊藤(沙)がアークシステム ザビ家の一員として、Zabbix に関する日々の取り組みやナレッジをご紹介していきます！【わたしに♥おまかせ Zabbix①】Zabbixの構成要素とパラメーターについて 【わたしに♥おまかせ Zabbix②】Zabbixサーバーと内部プロセスについて 【わたしに♥おまかせ Zabbix 号外】Interop Tokyo 2017 Zabbixブースに出展！ 【わたしに♥おまかせ Zabbix③】Zabbixの内部プロセスについて-続き 【わたしに♥おまかせ Zabbix④】Zabbixのデータベースについて 【わたしに♥おまかせ Zabbix⑤】Zabbixのデータベースについて – アイテム編 【わたしに♥おまかせ Zabbix⑥】Zabbixのデータベースについて – トリガー編 【わたしに♥おまかせ Zabbix 号外】Interop

プラットフォーム技術部　山本です。 「自社システム運用のレベルはどうなのか？」「漠然と課題感はあり現場は困っているが、経営層に改善の必要性をうまく訴求できない」などなど企業のIT管理部門が抱えるお悩みに応え、弊社の豊富なシステム運用の実績をベースに第三者的な評価サービスを実施してきました。 今回は最近の事例に沿って弊社の「運用アセスメント」サービスについてご紹介いたします。 IT部門が抱える課題、ニーズ IT部門でも特に「システム基盤に関わる各種企画やイベント対応」が山積している中で「日々の運用保守業務」も回さなければならない、予算も少なく体制も拡充しにくい「インフラ担当部署」は悩みが多いと思います。実際そういった悩みを抱え自助努力ではにっちもさっちもいかなくなったお客様からご相談をいただくケースがほとんどです。システム運用管理がしっかり回っていない、そもそも枠組みが整備できていない 個人のスキルに依存 業務負荷の集中、慢性的な高負荷 課題対策や改善が遅々として進まない 要員とスキル不足が深刻でベンダーコントロール、プロジェクトマネジメントに手が回らない。結果、品質が悪くトラブルが頻発。。。と悪循環が止まらない運用アセスメントサービスとは？ 表示されている画像の文字が小さくて読みづらい場合は、画像上にて右クリックをしていただき、新しいタブやウィンドウで表示いただくことによって、読みやすい大きさで表示することができます。 弊社運用アセスメントの標準的な評価対象は下記6領域となります。 システム運用保守の評価と改善策検討および改善実行計画の策定までを以下のステップで実施します。  ASIS分析 このステップでは、各種資料確認や数回の現場担当者ヒアリング及び過去障害対応履歴の確認結果から課題を抽出します。 以下は実際のアウトプットサンプル(一部抜粋)になります。抽出した課題から簡潔に総評を纏めました。TOBE検討 このステップでは、ASIS分析ステップで抽出した各課題への対策方針と期待効果及び必要コスト概算を検討しました。 以下は実際のアウトプットサンプル(一部抜粋)になります。 赤枠内が本ステップでの追記内容(優先度､対策方針､難易度､効果､効果目安､必要コスト概算)となります。  各対策の優先度と前後関係を踏まえて全体の関係を図示し、直近実施するスコープをお客様と協議･合意し、まずは優先度高の対策について具体的な実行計画を策定することになりました。  改善策の実行計画策定 優先度の高い対応策について具体的な実行計画を策定しました。 以下は実際のアウトプットサンプル(一部抜粋)になります。 「目的」「目標」「実施イメージ」「スケジュールとWBS」「必要なHW､SWなど」「成果物」「期待効果」の章立てで纏めました。実際にこのお客様では引き続き改善実行フェーズのご支援に繋がり、 これから順次改善をお客様と共に進めていきます。 その他実績 これまで実施してきました運用アセスメント及び改善支援の実績をいくつかご紹介いたします。 駐車場 2005～2009年 アセス後に改善支援を約3年に渡って実施。 各種運用改善から始まり､システム更改プロジェクトなどイベント案件のPM支援から技術支援までお客様の課題･ニーズに柔軟に対応。 物流 2008～2012年 アセス後に改善支援を約3年に渡って実施。 監視基盤構築や基幹業務システムの仮想環境集約移行支援など多数イベント案件対応や運用改善支援などお客様の課題･ニーズに柔軟に対応。 金融 2011～2014年 アセス後に改善支援を約2年半に渡って実施。 基幹業務システムのセンター集約＋仮想環境移行のPM支援や各種セキュリティ対策支援などお客様の課題･ニーズに柔軟に対応。 最後に 弊社は下記の基本スタンスに基づき、「お客様のそばで、お客様のためのITを」をモットーに真にお客様に貢献するサービスを提供いたします。お客様が抱える課題の解決を第一に考え、壁を設けず最大限可能な支援を ベンダー製品・サービスに縛られることなく、中立的に解決策を考え、お客様に解かりやすく示します 弊社リレーション有無にかかわらず、フラットに最適なソリューションを持つベンダー、SIerを巻き込み目的指向で解決策を検討します お客様の「費用感」「達成レベル感」「スピード感」「優先順位」を適切に把握し、柔軟かつバランスのよい現実的な解決策を提案します アセスメントやコンサルに終わらず、実効性の高い解決策から具体的な計画に落とし、お客様との確実な合意形成のもと責任をもって結果を出します「運用アセスメント」に限らず、お困りの際はお気軽にご相談ください。

プラットフォーム技術部の佐藤です。 だいぶ前の話になりますが、CentOS7/RHEL7のSELinuxポリシーのバグフィックスで、tomcatプロセスを制限のあるプロセス(confined)として動作させられるようになりました。 以前は制限のないプロセス(unconfined)の状態で、実質SELinuxのアクセス制御を受けない状態でした。 Firewallのルールに例えると、制限なし(unconfined)は最後のルールがallow all、制限あり(confined)は最後のルールがdeny allな状態です。RHBA-2017:1861 - Bug Fix Advisory Bug 1432083 – tomcat_t domain is in unconfined_domainただ、実はこのバグフィックスだけではtomcatサービスが起動できない状態になってしまうので、そのまま適用するためには次のバグフィックスまで待つ必要がありました。RHBA-2018:0763 - Bug Fix Advisory Bug 1470735 –

こんにちは。AWSを触り始めて約半年、入社2年目。プラットフォーム技術部の大畑です。 先日、CentOS 5.11環境でAWS CLIを使う機会があったのですが、主な導入方法として公式で紹介されているpipではインストールすることが出来ず、導入前から若干ハマるという事件が起こりました。 CentOSと言えば、2018年5月現在の最新バージョンは7系ですが、場合によっては古いOSを使い続けなければならないこともあるかと思います。 そこで本記事では、CentOS 5.11におけるAWS CLIの導入方法についてまとめてみたいと思います。※CentOS 5系のサポート期限は2017年3月31日で切れています。 　今から導入する人はくれぐれも化石バージョンを選ばないようにしましょう。 環境・制約条件CentOS 5.11 なるべく現行システムに変更を加えない 最低限のツールのみをインストールする導入方法 Python 2.6の導入 AWS CLIをインストールするために必要な要件は以下となります。Python 2 バージョン 2.6.5+ または Python 3 バージョン 3.3+ Windows、Linux, macOS, or UnixCentOS

本連載では、JWA公認 Webアナリスト検定を受けてみたい！という人向けに、私が勉強したことをベースに解説を簡単にまとめ、不定期に公開したいと思います。【受けてみた】JWA公認 Webアナリスト検定 【Webアナリスト①】Webアナリストのお仕事 【Webアナリスト②】Webサイトのボトルネックを特定する 【Webアナリスト③】Webサイトへ集客を行う方法 【Webアナリスト④】集客に関する指標の用語や計算式のまとめ 【Webアナリスト⑤】Webサイトへの流入 【Webアナリスト⑥】Webサイトでの回遊（本記事）こんにちは。ソリューション開発部 情報発信分科会の佐々木です。 今回はWebサイトでの回遊について解説します。 回遊とは、「ユーザーがWebサイトやページ内のコンテンツを見て回ること」を指します。回遊の分析においては、サイトを訪れたユーザーが目的の情報に辿りついているかに着目することが大切です。 流入の分析とサイトの改善 入口ページの分析と改善 ユーザーがサイトの入口となるページだけを見て帰ってしまった数を直帰数、サイトの閲覧を開始したセッションの総数のうち最初の1ページ目だけを見て帰ったセッションの割合を直帰率といいます。入口ページを分析する際は、まずサイトの直帰率を確認するところから始めます。 閲覧開始数が多く、直帰数・直帰率の高いページがある場合、ページに基本的な欠陥（読み込みに時間がかかりすぎる、ユーザーが知りたい情報がどこにあるかわからない等）がある可能性が高いです。ユーザー目線でページを訪問して検証を行い、ページの欠陥を優先的に修正していきます。 また、流入数が少なく直帰数・直帰率が低いページがある場合にはSEOやリスティングなどによって流入数を増やす施策を行います。 流入数が少なく直帰数・直帰率が高いページについては、直帰数を減らす施策を行ったとしても流入数が少ないため改善のインパクトが低いと考えられます。そのため、改善の施策を行うかどうか検討する必要があります。 サイト内の経路分析と回遊の改善 入口ページの分析の次は、サイト内の経路分析を行います。 ユーザーがサイト内をどのように回遊して、どこから離脱したかを確認し、ユーザーが想定していたシナリオ通りにサイト内を進んでいるか、迷っている遷移はないかなどを分析していきます。 離脱とは 次のページを読み込むまでをページ滞在時間、サイト内でユーザーが閲覧した最後のページ（離脱ページ）を読み込むまでをサイト滞在時間といいます。なお、ユーザーが入口ページから直帰してしまった場合はページ滞在時間もサイト滞在時間もわかりません。サイトを閲覧中にユーザーが別サイトに飛んだ場合でも、セッションが切れていなければ（別サイトに飛んでから戻ってくるまでの間が30分未満であれば）サイトの滞在時間も継続されます。また、別サイトに飛んでいなかったとしても、1つのページに30分以上滞在するとセッションが切れてしまうため、サイトの滞在時間はそこでリセットされます。セッションが切れていない場合も、ブラウザを閉じてしまうとページの滞在時間はリセットされます。ユーザーが離脱した数を離脱数、ページが表示された回数（ページビュー数）のうち離脱ページになった割合を離脱率といいます。 各ページの離脱率とコンテンツの内容を確認し、ユーザーが想定したページ（コンバージョンページ等）で離脱しているかどうかを検証します。 コンバージョンページ コンバージョンとは、サイト運営者が望むページにユーザーが辿り着くことを差します。このとき、ゴールとなるページのことをコンバージョンページといいます。コンバージョンページのページビュー数から、どれだけのユーザーがサイト運営者の望むアクションを行ったかを計測することができます。 【コンバージョンページの例】商品を購入した後の完了ページ メールマガジンの登録完了ページ アンケートの回答完了ページまた、コンバージョンページが存在しないサイトの場合は、以下の方法でユーザーのアクションを計測することができます。 仮想ページビューによるページトラッキング サイト内に仮想のページを設定して、その仮想ページのページビュー数を計測することでユーザーのアクションを計測します。 この方法は、資料のダウンロードや外部サイトへの誘導が目的のサイト、同一URLのページの遷移でゴールページを表示するようなサイトの計測に適しています。 イベントトラッキング 計測したいユーザーのアクションをイベントとして計測します。 この方法は、Q&Aサイト等でページ内リンクのクリック数を計測する場合や、上述の仮想ページビューと同様に資料のダウンロードや外部サイトへの誘導を目的としたサイトの計測に適しています。 おわりに ユーザーがサイトを訪問したとしても、コンバージョンページに辿り着けなければサイトの目的は達成されません。ユーザーが途中で離脱していないか、離脱していまう原因は何かを分析していく必要があります。 ページの滞在時間とサイトの訪問時間は難しいかもしれませんが、きちんと理解しましょう。 今後も引き続き、Webアナリスト関連の記事を書いていきますので、どうぞよろしくお願いいたします。ソリューション開発部では、資格・検定の取得や各種セミナーの受講にも力を入れています。メンバー自らが受講してみたい講座を選ぶことによって、自らの意志によってスキルアップができる環境を整えています。Webアナリスト検定 連載一覧【受けてみた】JWA公認 Webアナリスト検定 【Webアナリスト①】Webアナリストのお仕事 【Webアナリスト②】Webサイトのボトルネックを特定する 【Webアナリスト③】Webサイトへ集客を行う方法 【Webアナリスト④】集客に関する指標の用語や計算式のまとめ 【Webアナリスト⑤】Webサイトへの流入 【Webアナリスト⑥】Webサイトでの回遊（本記事）