Mental illness, especially depression is one of the most pressing concerns all over the world. We propose a system estimating mental states of a user from activity log derived from sensors. It uses the analogy of thermometer for the visualization. Everyone should have gone through hardships with fever, and they can understand how much tired by this format. Related Publications Prerna Garg, Jayasan

江崎グリコは8月4日、ポッキーやビスコなどのお菓子を使ってプログラミングの考え方を学べる子供向けスマートフォンアプリ「GLICODE」のAndroid版を公開した。iOSにも対応する予定だ。 ポッキーを縦に置くと「上に動く」、ビスコを縦に置くと「のぼる」など、お菓子にプログラミングコードを持たせた。ルールに従ってお菓子を並べ、アプリのカメラで撮影すると、お菓子で“プログラミング”した通りにキャラクターが動く。シークエンスやループなど、プログラミングの基礎的なロジックが学べるという。 同アプリは、総務省が推進する「若年層に対するプログラミング教育の普及推進」事業の実証事業に選ばれた。今後は小学校教育への導入なども視野に入れながら、アプリの体験イベントなども展開していく予定だ。 関連記事 ゲーム感覚でプログラミングを学べるWebサービス「MOZER」　「進撃の巨人」とコラボも ゲーム開発でプロ

マイクロソフト、「Excel REST API for Office 365」正式リリース。保存されたExcelのワークシートにAPIでアクセス可能 多くの企業で活用されているExcel。営業部門が各営業担当の進捗状況から売上げを予測するExcelシートを作成していたり、経理部門が経費の配賦をExcelのワークシートで管理してる、などという例も少なくないでしょう。 一般的にこうしたExcelで作り込まれた社内のアプリケーションを既存の業務アプリケーションに組み込むためには、いちどExcelで作り込まれたアプリケーションを解析し、あらためてプログラミング言語で組み立て直す必要がありました。 マイクロソフトが正式にリリースした「Excel REST API for Office 365」を用いると、OneDrive（補足：使えるのはOneDrive for Business）に保存したExce

Wantedly Engineer blogに本速習会資料を閲覧向けに再編しました！ ぜひご覧いただけると幸いです！ 本記事は、綺麗なAPI速習会@Wantedlyの資料として作成されたものです。 同時にこちらのコードも参照してください。 マイクロサービス 流行りのマイクロサービス、何がいいのか 各々自由な言語やArchitectureでサービスを立てられる 障害の影響が部分的 変化に強い 個別デプロイ etc... マイクロサービス化をすすめるにあたり、やりとりは全てAPIで行う 内部のAPIであっても外部に公開できるようなクオリティのAPIを作成し、それを元にサービスを作っていくことが重要 APIGatewayとBFF API Gateway Pattern 公式サイトより 「見た目はモノリシック、実装はマイクロサービス」 一箇所見に行けば全てのAPIを見つけられる 細かい権限管理も可

以前から不思議に思っていたことがある。それは、少なくとも米英の人は、ソフトウェア技術やプロセスに対して誤解が圧倒的に少ないということである。 別の回でも書いたが、イギリスの会社とお話しした時も、「アジャイル」に対するとらえ方、考え方は、100%といっていいほど正確だった。 バリューストリームマッピングで困っている人の話 今回の出張で、Sam Guckenheimerに依頼されたことがある。ある人が「バリューストリームマッピングをやっているのだが効果が出なくて困っている」だから原因を一緒に探ってほしいとのことだった。 Samと一緒に彼の話を聞いていると、バリューストリームマッピング、DevOps に関する考え方とらえ方は極めて正確だった。彼の問題は、「コンセプトの理解」は何の問題も無く、その先の「実際にやってみて工夫してみないと到達できない部分」の問題だった。 なぜか米英では、ソフトウェアの

これまで少し大きめな機能であれば、コードを書く前にまず仕様や実装の方針をissueのdescriptionにまとめ、それを先にレビューしてもらってから実装にとりかかるということをしていた。最近、その方針をそもそもrepositoryのファイルとして書いて、PullRequestしてレビューしてもらうようにしたら便利だったのでご紹介。 なぜコードを書く前に仕様や実装の方針をレビューするのか 前提としてなぜコードを書く前に仕様や実装の方針をレビューして欲しいのかについて書いておく。これはとにかく手戻りの量を少なくしたいという要求のためである。 実装に取り掛かろうとすると、実装の方針はいくつか思いつくが、どれが一番よいか迷うことはよくある。その場合に誰にも相談せず自分だけで判断し、コードを書いてからPullRequestを送った場合、もしその選択に重大なミスがあった場合全て書きなおさないといけな

ピクシブ株式会社に入社しました！…といっても、入社したのは2015年8月1日と約1年前です。 「転職エントリーは、転職した直後に書くよりも1年後の方がいいのでは？転職の興奮が覚め、会社のこともある程度わかってから書いたほうが、身になる話ができるんじゃないか？」 なんてことを入社直前に思いつき、あえて今頃になって、転職エントリーを書いています。 このエントリーでは、大企業からベンチャーへ、エンタープライズ系からネット系へ、受託メインの会社から事業メインの会社へ転職した私が、1年経った今感じていることをお話しします。それで、後ろに続こうとしている人に、何かしらのヒントを残せたなら、私としても嬉しいです。 最初に言っておきますが、「こんな会社辞めてやる！」的な、そういうコンテンツはないので、期待しないでください！！！ 転職で変わったこと 私の転職は、テクノロジーというキーワードを除くと、なにもか