小山工業高等専門学校准教授、鈴木真ノ介先生と弊社が共同開発している AR 技術を用いたアプリによりアクティブ・ラーニングを実現する手法を含む研究が、第65回工学教育研究講演会にてポスター発表賞を受賞しました。
アクティブ・ラーニングは、これまでの教員が学生に一方向的に教える講義とは違い、学生が主体性を持って能動的に参加する学習法で、近年様々な教育現場で注目されています。
鈴木先生の提案するアクティブ・テキストというシステムは、学生が授業で使用するプリントや教科書に印刷された図や数式にスマートフォンをかざすと立体的なグラフや動画などが AR で表示されるもので、本研究では AL を実現する要素として活用されます。
弊社は本システムの iOS アプリケーションとコンテンツ管理サーバーの開発を行いました。
続きを読む先日9月1日に行われた Microsoft のパートナー向けイベント、Microsoft Japan Partner Conference 2017 Tokyo～Inspire Japan!のキーノートにて、弊社が UI/UX 改善とメニュー実装を担当した車両メンテナンスアプリケーション 「Hologarage」が披露されました
【 #Hololenz があれば車の常識も進化する】エバンジェリスト 西脇資哲より。MRの世界では車の記録簿を見ることも、車両側のコンディションもリアルタイムに情報が抽出できる。更には #CognitiveServices を使って走行データの分析も可能となる。 #msjpc17 pic.twitter.com/3zi3L1FpZL
— マイクロソフト パートナーネットワーク (@MPN_Japan) 2017年9月1日
Microsoft の西脇資哲さんにデモしていただいている様子
続きを読むこんにちは、コベリンの @numa08 です。アップデート情報をお届けします。
環境変数 ROCKET_ARTIFACT のパスへ格納したファイルを成果物ファイルとして保存する機能を提供してきましたが、今回のアップデートで機能の提供を終了します。
環境変数 ROCKET_ARTIFACT をビルドスクリプトの中でご利用の方は修正をお願いします。
Google Drive や Google Cloud Storage, Amazon S3 などの外部サービスへ転送を行う機能などを提供させて頂く予定です。
それでは、今後ともコベリンと Rocket をよろしくお願いします。
こんにちは、コベリンの @numa08 です。アップデート情報をお届けします。
依存ライブラリのダウンロードなどが必要な際に、ダウンロードしたデータを次回以降のビルドでも利用できるようキャッシュ機能が実装されました。ビルド定義ファイルの rocket.sh の中で環境変数 ROCKET_CACHEを参照することで利用できます。
例えば Android アプリの場合
mkdir -p "${HOME}/.gradle"
if [[ -d $ROCKET_CACHE/.gradle ]];then
cp -r $ROCKET_CACHE/.gradle $HOME
fi
./gradlew assemble
cp -r ${HOME}/.gradle $ROCKET_CACHE
とすることでダウンロードをした gradlew のバイナリや依存ライブラリをキャッシュとして保存し再利用することが可能です。
なお、キャッシュの上限は1GBで容量を超えるデータを保存しようとするとエラーが発生してビルドが失敗となる可能性があります。
また、キャッシュには最後に成功したビルドのものが保存されます。
ビルド一覧画面から開くことのできるリポジトリ設定画面で環境変数をセットできるようになりました。
ビルド時に rocket.sh の中から参照ができます。外部連携しているサービスに関する情報やビルドに関する情報を保存することで、リポジトリには含めたくいデータを与えることが可能です。
Rocket CI は現在クローズドα期間です。テスターとして利用をしてみたい方は Slackチームに参加をしていただいたあと、チーム内のコベリンメンバーに声を掛けていただけたらテスター登録を行います。
それでは、今後共コベリンと Rocket CI をよろしくお願いいたします。
コベリンでは沢山の美味しいコーヒーを飲むことができることを知っていますか？
多くのエンジニアにとって高い開発効率を維持するため美味しいコーヒーは欠かせないものとなっています。
コベリンでは(とりわけ僕の)モチベーションを維持するために沢山の美味しいコーヒーを飲むことができます。
そんなわけで今月のコーヒーを紹介していきたいと思います。
コーヒーのスペックに関しては覚えてる範囲で書きます。
こちらの豆は OBSCURA COFFEE ROASTERS というお店で定期購入を申し込んで発送してきていただいているものです。
このお店はセミナーを開催していて何度かお邪魔しました。
今まで飲んだことのない特徴的なコーヒーを販売していてとてもおもしろいです。
以下の写真は3種類写っていますがこの中で 7と書いてあるものを持っていきました。
堀口珈琲はストレートコーヒーではなくブレンドコーヒーです。 どれも美味しいのでおすすめです。
こちらのお店は極端な浅煎りや深煎は並べておらずどれも飲みやすい豆を販売しています。
以上がコベリンで9月に提供されたコーヒーです。
どれも特徴的 & 高品質なものなので気になるものがあったら是非飲んでみてください。
特徴的な味わいなので好みかどうかは保証致しませんのでその点だけご了承ください m( )m
こんにちは。コベリンの @numa08 です。
この度、合同会社コベリンでは新しい事業として rocket ci のクローズドアルファテストを公開しました。
現在、 CI をソフトウェア開発のフローに導入することで品質や開発効率の向上を狙う個人やチームは多いと思われます。CI のツールとして有名な物は jenkins が挙げられますが、それ以外にも Cirlce CI や Travis CI と言ったサービスが存在します。
自分達でメンテナンスを行う jenkins を除き、 Circle CI や Travis CI は基本的に月額課金を採用しています。そのため、少数チームでの開発や長期休暇などで開発スピードが落ちる期間でも変わらず料金が発生し、少し課金体系に不満がありました。
私達が提供をするサービスは従量課金制を採用します。具体的な金額については現在は非公開ですが、利用した分だけ料金が発生する仕組みですので、小規模チームや開発スピードに変化の発生するチームであっても気軽に利用できるサービスとなります。
マイルストーン にも掲載をしていますが、年内に正式版としてリリースを行い、合わせて料金体系の公開、マネタイズを実施する予定です。
テスターを希望される方は Slackチーム へ参加をしていただいたあと、チーム内のコベリンのメンバーへ声をかけてください。
それでは今後も rocket ci とコベリンをよろしくお願いいたします。
こんにちは。 コベリンの @numa08 です。
コベリンには3人のエンジニア (@numa08, @mironal, @ryohey) がいて、動いているプロジェクトがいくつかあり、うち複数人で回しているものが4つあります。
内訳は
となっています。
それぞれのプロジェクトでは Pull Request を通してコードや進捗の共有、品質の向上を目指しています。
しかし、多くのプロジェクトがそうであるように、 Pull Request を軸にした開発フローでしかも人数が少ないとなると「待ち時間の発生」というボトルネックが生まれます。
「待ち時間の発生」に対するアプローチはチーム毎に様々な方法があると思います。「様々な方法がある」ことを認めた上で「ケース・バイ・ケース」で判断するという方向に舵を切ってしまうと、どうするべきかの判断の基準が人によって異なったり、また決断をすることによってメンバーにストレスがかかることが懸念されます。
そこで、プロジェクト毎にどう言った方法が適切なのか、どうするのがベストなのかを調査し、話し合い、「Pull Request のレビューを行うのか」あるいは「行わないのか」を定めたルールを試験導入することにしました。
今回は、試験導入することになった方式を紹介します。
twitter 非公式クライアントの feather は Android版はリリースをしてからそろそろ1年、 iOS版は2年以上経ちます。いずれもソースコードの量も多く、変更が及ぼす影響はどうしても大きい物になってしまう可能性を秘めています。
そのため、コードの変更を行った場合は Pull Request の作成とレビューの実施を絶対に行う物としました。ただし、依存しているライブラリのバージョンを上げるだけの変更や typo を修正するだけの場合は Pull Request を作るものの、コードレビューの依頼はせず、変更者本人によるマージの後、 slack などを利用して変更を行った事をメンバーに通知します。
また、 Clashlytics を利用しているので、依存ライブラリのバージョン変更による見た目や挙動の変更確認はコードを見なくてもベータ版を誰かにインストールしてもらうことで確認可能です。
そういった理由から「基本的にコードレビューは行うものの、小規模な修正と考えられるライブラリのアップデートや typo の修正はレビューは行わず、マージ後に周知をする」としました。
現段階でリリースをされていない新期開発中サービスについては、レビューを実施することよりも速く開発をしてリリースをすることを優先したいと考えています。ただし、その前提として、 Issue を利用して設計をいつも以上に詰めることや、他のサービスと連携をする I/O 部分について変更が必要となった場合はメンバー全員に周知をすることとします。
そのため、「基本的にコードレビューは行わないが、設計については細かく共有し変更の通知をすぐに行い、早期のリリースを目指す」としました。
こちらも未だリリースされていないサービスのゼロからの開発のため、自社サービスと同じ仕組を導入します。また、実は開発がスタートしてから1ヶ月近く経ちますがこの方式で問題は出ていません。 Issue を利用した情報共有や設計の共有が行われているからだと考えられます。
コベリン社内でコードレビューの実施を行うかどうかのルールを決定し、試験導入することにしました。こういった大切なルールはやはり昔ながらの「紙に印刷して眼につくところへ貼り付ける」が有効だと思うので、早速印刷をして貼り付けました。
今後、この試みがうまく言っているかどうかを検証する必要があります。開発効率の向上を検証することは難しいといえますが、幸いにもコベリンではイテレーションを作ってベロシティを計測する手法が確立しているため、それによる計測が行えるはずです。
「Pull Request を作ってコードレビューを行いマージをする」という、 開発フローは一見メリットが多いようにも思えますが必ずしも全てのプロジェクトについて万能であるとは言えません。我々は常に今までの当たり前を見直すことが求められていると言えますね。
なお、この試みを行った結果についてもブログで紹介をする予定ですので、しばらくお待ち下さい。
