2. もくじ • 自己紹介&モチベーション • 準備 • R MarkdownでReproducible Research –基礎編 –応用編 • まとめ • 参考(書籍|スライド|サイト) 2
先日 Android のソースコードを読んでいた折に、所定の処理においてシステム上で発生するファイル I/O の流れを確認したいと思いました。処理の全体像を把握する上で有用と考えたためです。そこで inotify を利用することにしました。 Android の Linux カーネルには inotify が含まれており、Android SDK には inotify を利用した FileObserver クラスが用意されています。 inotify で Linux ファイルシステムのイベントを監視する - www.ibm.com FileObserver | Android Developers - developer.android.com Android FileObserver - The Underlying inotify Mechanism and an Example Androi
IT系リサーチャー。最近はブロックチェーン関連に従事。 2019年の再開後は、技術系の話を書こうかね。 2014年以前は、競馬予想ソフト、絵本とAndroid Marketに公開したアプリの話がメインの日常をつづったブログだった。 TrafficStatsクラスを使用することでモバイル(3G)通信と全体の通信量を調べることができる。アプリごとの通信量も調べることができる。 long mobileRxBytes = TrafficStats.getMobileRxBytes(); long mobileTxBytes = TrafficStats.getMobileTxBytes(); long totalRxBytes = TrafficStats.getTotalRxBytes(); long totalTxBytes = TrafficStats.getTotalTxBytes();
Googleの様々なAPIを叩く際、認証にOAuth 2.0を用いる。 Using OAuth 2.0 to Access Google APIs | Google Identity Platform | Google Developers 使用する場面やパターンによって以下のような6つのシナリオが想定されている。 Login Web Server Applications Client-side Applications Installed Applications Devices Service Accounts 多くの場合は「ユーザごとに認証させて個別のtokenを発行しリクエストに利用する」という流れなのだけど、中にはたとえばURL短縮APIとか、必ずしもユーザ個別にtokenを発行させる必要がないこともある。 そういう場合には「サービス固有のtoken」だけあれば良い。と
2014年4月16日より2014年5月14日まで開催していたpaizaオンラインハッカソン(略してPOH![ポー!])Vol.2「女子大生とペアプロするだけの簡単なお仕事です!」で提出された最速コードはどのような高速化のアプローチでで生み出されたのでしょうか? POH Vol.2に登場した女子大生インターンプログラマの木野ちゃん(左のイラスト)にアルゴリズムを図解で教えるとしたら、どう教えるだろうか、という事で、今回は図解してみました。 今回は前回の最速コード発表レポート(【結果発表】女子大生プログラマの心を鷲掴みにした最強のコード8選)に引き続き、最速コードの裏側に迫ります。 ■高速化のアプローチ方法について 今回もPOH Vol.1 と同様に、POH Vol.2では計算量の改善による高速化を柱とするアプローチを想定して出題されました。基本は定数倍高速化によって想定解法よりも悪い計算量の
僕が今、1番注目しているアプリはサイバーエージェントの「ウチの姫さまがいちばんカワイイ」です。 このアプリ、最近やたらとランキング上位で見かけると思うのですが、 昨年8月のリリース当初は「あぁ・・・」って感じで、200位台スタートからの圏外へ。しかし諦めなかったのでしょう。12月は100位以内をキープし始めます。 そして、月に数回飛び跳ねるようになり、50位以内に定期的に顔を出すようになってきます。 「ガチャとかで頑張ってるんだろうな」くらいに思ってました。しかし、月末には10位以内に入ってくるタイミングがあり本格的に気になり始めます。 5月になっても落ちてこず、更に安定感が増してきています。 と、いうことで、ランキング圏外からどうやってランキング上位常連まで持ってきたのかを研究中です。 ちなみに今、ランク33。SR持ってるんだけどコスト足りなくて入らない。2週間くらいちょいちょいプレイし
お待たせいたしました。久しぶりにRetty株式会社さんからご寄稿をいただきました。今回は、iOS開発での環境を切り変えるために便利な「スキーマとビルド設定」について、ご自身の体験を交えてご紹介いただいております。 ごあいさつ はじめまして、Retty株式会社の櫻井と申します。今回からiOSの開発で得たノウハウなどをブログ記事に書かせていただくこととなりました。今後、読者の皆さんのご意見なども取り入れつつ、何か役に立つような記事を書いていきたいと思っていますので、よろしくお願いします。 記事の内容としては、弊社で開発しているRettyというグルメサービスの開発の実例を通じて、教科書にはあまり載っていないTIPS、落とし穴等を紹介したいと思います。対象読者として複数人のチームでiOSアプリ開発をされている方を想定しています。 はじめに 背景と問題点 サービスとして提供し続けるWebアプリケーシ
Redmineによるチケット駆動開発のプラクティスをパターン言語で表現したら、ナビゲーションマップでどう描けるか、試してみた。 Slideshareにアップして、ダウンロードできるようにしたので、ご参考下さい。 【参考】 パターン言語の構造と事例集: プログラマの思索 【1】チケット駆動開発のナビゲーションマップを作成した意図 「デザインパターン」や「ドメイン駆動設計」や「組織パターン」を読んでみると、最初のページにパターンの関連を表した地図のようなものが出てくる。 それがナビゲーションマップ。 パターンの全体像みたいなもの。 僕は、Redmineによるチケット駆動開発がアジャイル開発ととても相性が良いことを経験した後、そのノウハウを他人に説明し、共有できる方法はないか、とずっと思索していた。 その方法として、パターン言語が一番有効ではないかと思い続けてきた。 元々、XPやScrumを代表
インターネットを眺めていたら、リリースの高速化自体を目的化するのではなく、ビジネス成果によって成否を判断するべきだという主張があったので、思うところを書いておく。起点は他社さんにおける議論だが、そこは問題ではなくて、もし自分の関わるところでそういう議論が起こったら、自社の技術に対してそれなりのポジションにおいて関係する人間としてどのように考えるべきだろうかという視点で述べる。 リリースあるいはリリースの高速化自体を目的化するのではなく、その結果としてのビジネス的成果が大事だということは、マネジメントにとっては当たり前なわけで、いちいちいうまでもないことだろう。そもそも、サービスが圧倒的に成長し続けていれば、リリース頻度 = 成果になるはずだ。現状そうでないのであれば、成長速度が遅いということになる。エンジニアが技術を尽くしてリリース速度を向上させたにも関わらずそれが成果に結びつかないとした
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く