エコモット アドベントカレンダー 11日目です。
こんにちは、開発部鈴木です。
私からは画面表示に関することを書かせていただこうと思います。
「今の計測値をモニタ画面に常時表示させておきたい。」
「複数の計測値を、一画面にまとめて表示してほしい。」
といったご要望をお客様からいただくことがあります。
一画面で表示する、となった時に注意しなきゃいけないのは画面上のパーツ配置。
パソコンで見る場合は、どこか一か所に寄ってしまわないように…とか、常時表示させるなら見た目も良くしたい…とか。
パソコンではなくスマホで見るのだったら、狭い範囲の中いかに見やすく配置できるか…を考える必要があります。
そんなご要望があった時はどのように画面を作っているのか、実際に私が画面をつくった騒音振動計の画面カスタマイズ例をもとに、ご紹介します。
続きを読む
こんにちは！
開発部の武内です。
エコモットアドベントカレンダーの10日目を担当します。
弊社では ミルモット や ジオスコープ をはじめとした、
画像・動画を扱うソリューションを展開しています。
今年、経済産業省・総務省・IoT推進コンソーシアムにより
カメラ画像利活用ガイドブックver1.0 が策定され、
それに追従するように札幌市などの自治体でも
防犯カメラに関するガイドライン が策定されるなど、
カメラで撮影された個人情報に対する意識・気運が高まっています。
そういった流れに対して、
エンジニアとしてはやはり技術で解決したい！ということで、
今回はAWSを利用して、画像内の個人情報の一つである顔を検出しモザイクをかける仕組みを作ってみました。
続きを読む
エコモットアドベントカレンダー8日目のエントリーです。
しばらくの間北海道を離れ東京に移り住んでいるのですが、雪がまったくと言っていいほどに降らない為、体内季節感にズレが生じている開発部 金子です。
生まれも育ちも北海道札幌なので「降雪」＝「冬の始まり」という季節感が染みついているので雪が降らない冬ってなにかこう、違和感を感じてしまっています。
さて、雑談はさておき。
サーバーサイドで画像処理を行い、その処理結果を使ってホニャホニャみたいな事がしたい！
と思って当初PHP+GDで挑戦していたのですが、一連の画像処理の中で2階調化がどうにもうまくできず「どうしたもんかなー」と途方に暮れていたところ、ImageMagickだったらできるかも？！と思い、まずは環境構築を行いました。
ImageMagickは十年ぐらい前にちょーっとだけ齧ったことがあったので、昔を懐かしみつつ軽い気持ちでXAMPPで構築したローカル環境にImageMagickをインストールしてたんですが、思いの外つまづく部分も多かったので、手順を改めてまとめてみました。
続きを読む
エコモットアドベントカレンダー6日目のエントリーです。
今年に入って盛り上がっていましたGoogleさんのSymantecさんに対する激おこ（笑）状況、
SSL証明書の無効問題についておさらいします。
“エコモット 技術ブログ アドベントカレンダー ３日目です。”
12/1に正式発表になったDeSETプロジェクトについて簡単に報告したいと思います。
DeSET・ニュース
リバネス・プレスリリース
海底探査技術開発プロジェクト(DeSET Project)とは、公益財団法人日本財団および株式会社リバネスの共同で、2017年4月から2019年3月まで実施される研究開発事業です。
この事業は、水平方向の分解能が100m以下の海底地形図を地球上の全海域に渡って作成することを最終目標とし、その実現を飛躍的に加速しうる技術を日本国内から生み出すことを目的としています。
続きを読む
こんにちは。
岩津です。
11月に入り寒い日が多くなりましたが皆様いかがお過ごしでしょうか？
札幌は”みぞれ”混じりの雨が多くなり冬まであともうわずかで待ったなしという感じになってきました。
外の気温が低くなってくると、温度管理が非常に重要になってくる業界も多いようです。
エコモットではこの季節、”コンクリート養生温度管理”というちょっと聞き慣れないシステムがよく利用されます。
続きを読む
こんにちは。開発部の対馬です。
他社様の機器、APIなどと連携することの多いIoTのサーバー開発では、機器などから送信されるデータのフォーマットが未定、または変更になることが多々あります。
そのようなとき、フォーマット変更によるDB設計の停滞や手戻りを防ぐため、「とりあえずKVS的に、データは全部JSON文字列で保存しておこう」という方針で開発をせざるを得ないことがあります。
ある意味バッドノウハウな気もしますが、意外と柔軟な設計ができたりするので、ご紹介します。
ちなみに、JSON型や関数をバリバリに活用するような話ではありません。
逆に、そういう実装にするとクエリが複雑になったり、保守の難易度が上がったりするので、よほど要件がマッチしない限り自発的にそういう設計をおこなうことはありません。
続きを読む
こんにちわ、開発部の森です。
普段はインフラ関係の仕事を中心にしておりますが、基本何でも屋さんをやっているものです。
さて、先週に続きまして今週はJチーム(2名)の報告をしていきたいと思います。
Jチームは、ハッカソンでは珍しいインフラエンジニアだけのチームになっております。
ハッカソンでインフラエンジニアだけというチームも滅多にないと思うので
今回は、普段業務の中でこんなのがあったら楽なのになーあんなのがあったら楽なのになー
と思っていてもなかなか時間が取れず取り組めなかったものを題材に行ってみました。
また、今回は別々のテーマで取組んでいたので2つ紹介したいと思います。
こんにちは。
岩津です。
Bチーム後編です。
前編はこちらをごらんください。
電話APIサービスとして有名な”Twilio”が、”Functions”サービスを公開しました。
簡単に言うと「自分でサーバを用意しなくても電話サービスを構築できる」という感じです。
以前はサーバーレスで稼働させるためにはAWS Lamdaなどを利用してシステムを作る必要がありましたが、簡単なものであればTwilio単体でシステムを完結できるようになったため、シンプルにサービスを作れるようになりました。
今回のハッカソンではこのTwilio Functionsを利用して、弊社提供サービスであるFASTIOからエッジ側の情報を電話で受け取ってみました。
こんにちわ。開発部の堀野です。
ハッカソンではA～Lチームに分かれ、計19名が参加しました。約半数が2人チーム、残りが1人チームです。私はBチーム（2名）となりました。
今年の私のテーマはエッジコンピューティングにしました。
