サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
中東情勢
ninjinkun.hatenablog.com
6月中旬に株式会社一休に入社した。一休レストランという飲食店予約サービスを運営するレストラン事業部で、iOSアプリの開発を行っている(やっていることはコーディングとプロダクトマネジメント的な仕事を半々ずつくらい)。 一休はIT系としては比較的歴史が長い会社だが、 アプリの伸びしろの大きさ 経営陣の面白さ 自分で使って楽しいサービス という点で、総合的に見て面白い経験ができそうと感じて入社を決めた。事前に二週間お試しで働いてみて、一緒に働くメンバーとも楽しく仕事ができそうなのがわかっていた点も大きかった。 元々飲みに行ったり外食することは好きだったのだが、一休では自社のサービスを自分で使ってご飯を食べに行き、その体験をまた製品にフィードバックして改善できる。自分の生活をサービスに反映できるところが面白い。 他にも、社長(金融工学、CS、コンサル系のバックグラウンド)が検索のおすすめ順やリコメ
昨年11月に結婚し、2月に勤めていたFablicを退職して京都で暮らしている。 結婚 3年前に上京して、京都に住んでいる彼女と遠距離恋愛をしていたのだが、昨年末に結婚した。現在は京都で一緒に暮らしている。毎晩一緒にお酒を飲めるのが楽しい。 退職 会社を辞めた理由としては、会社が昨年夏に買収され、自分の中でスタートアップ欲求が一段落付いたというのが一つ。もう一つは妻の仕事が3月まで忙しいことがわかっていたので、せっかく結婚したのだし、しばらく一緒に居る時間を作ってサポートするのも良いんじゃないかと思い、このタイミングになった。 Fablicにはスタートアップの黎明期から拡大期に移るタイミングで入社し、フリルのiOSネイティブ移行、AndroidのMaterial Design対応、RIDEの開発など、様々な楽しいプロジェクトに関わらせて頂いた*1。また、自分のわがままを聞いてもらって、プロダ
Webマーケターの知人に「マーケティング初心者に一番おすすめの本教えてよ」と尋ねてみて、この本を推薦してもらったので読んでみた。戦争で使われる戦略をマーケティングに当てはめて、実際のマーケティング戦略を解説していくという内容の本である。戦争の引用がどれだけ妥当なのかはわからないが、とりあえず歴史好きや小説好きであれば面白く読めると思う。自分は一気に読んでしまった。 印象に残ったことをかいつまんで箇条書きにすると 基本的に戦いは人数が多い方が勝つ なのでビジネスにおいては営業の人数や広告予算が多い方が勝つ事が多い 防衛するのは攻撃するより容易だ なのでトップの企業を蹴落とすのは容易ではない 製品のイノベーション、品質の高さ、人材の優秀さだけで逆転できることはほとんどない 規模が小さければニッチに特化したゲリラ戦を仕掛けろ という感じだった。そしてビール戦争、コーラ戦争、コンピューター戦争と実
この記事はProduct Manager Advent Calendar 2日目の記事です。 先日Japan Product Manger Conferenceに参加して、ポケモンGOの開発元であるNianticでPMをされている河合さんのセッションの中で印象的な言葉があったので書き留めておく(セッションの詳細はプロダクトマネージャーに必要な資質って何ですか? 元グーグルのPM対談 | HRナビ by リクルートで読める)。 会場からの質問で、「開発者に仕事を任せる際に、上からやることをお願いするトップダウン型と、開発者が自発的にアイデアを出してくるボトムアップ型があると思うが、どちらがいいと思うか」(うろ覚えだけど、だいたいこんなニュアンスだったはず)という質問に対し、河合さんは一呼吸置いてから「ボトムアップの見かけはとても重要」と回答されていた。 これはPMの中では既に実現方法(おそら
original: The Product Management Triangle (by Dan Schmidt) (translated by ninjinkun, reviewed by Kosuke) はじめに プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うことをやっている。彼らは異なるタイプのプロダクト、異なるタイプのチーム、異なる組織構造の中で働いている。このプロダクトマネジメントの立場の違いは、とても不毛だ。外の立場から見ていると、同じ肩書きの仕事を参照する際に、誤解を引き起こしているように見える。全てのプロダクトマネジメントの仕事を統合して、共通の話題を抽出しようとすると、価値を説明しようとし
先日、一休.comを運営する株式会社一休の社内テックトークで『スマートフォンアプリ開発における共創的な開発チーム』というタイトルでお話しさせていただいた。元々、ずっと考えてきたエンジニアとデザイナーのコラボレーションというテーマを言語化してみたいと思っていたのだが、そこに丁度Fablicでの現場の体験を話して欲しいという依頼があったので、絡めた内容でスライドを作った。 しかしこの言語化する作業が想像以上に大変で、週末を二回潰して準備をした。結局今まで勉強したポインタになる書籍を紹介することで、なんとなくバックグラウンドについては察してもらうというスタイルになった。 タイトルも迷って何パターンか書いてみたのだが、最終的には「共創的」という耳慣れない言葉を採用した。本当は「Collavorativeな開発チームでのアプリエンジニアの役割」とかの方が言いたいことに近い気もするが、これはこれで何だ
Flux(とその実装としてのRedux)は中〜大規模のWebクライアントに向いている設計だと思っているので、具体性を出すためにサンプルとしてTwitterクライアントを作ってみた。iOS版はRIDEと同様にReSwiftを使い、Android版はReSwiftを写経したJava版Reduxライブラリを作って同梱している(用途があれば切り出してもいいかも)。 簡易な実装なので、UITableView、RecyclerViewとの同期問題、アニメーションの問題などは積み残しになっている。 普通にアプリケーションを作る場合に比べてFluxはコード量が増える傾向にあるが、一人で簡単なものを作っているだけではFluxのうまみもなく、実装は結構だるかった。開発に1ヶ月以上かかる場合や、チームが2人以上の場合などであればペイすると思う。
有名な本らしく、同僚から薦められたので読んでみた。人が騙されたり、冷静に行動できなくなる現象を解説した本である。セールスやマーケティングで用いられている人間の行動に関する知見が、社会心理学実験の結果を用いて説明される。 確かにとても面白い本で、自分は読んで良かったと思うのだが、同時にこんな知見が流通している世界に住んでいたのか…と唖然としたというか、少し辛い気持ちになった。もちろん騙す知見を流通させる目的の本ではなく、知っていれば騙されるのも防げるというスタンスで、防衛法も書かれている。 プロダクトマネージャーに関心がある自分としては、4章「権威--導かれる服従」に書かれていた、権威や上司には自動的に従ってしまう社会的な特性があるという部分が印象に残った。プロダクトマネージャーは開発チームの上司ではなく、人事権も持っていないことが特徴であると言われている。この知見を元に考えると、プロダクト
Incrementsの知人が社内で輪講していると言っていて、気になっていたので読んでみた。創造的なチームを作るために気をつけることと、そのために必要になるリーダーシップについて書かれている本とのこと。 現代のチームが固定されたメンバー制から専門集団の一時的な集まりになっている(例えば病院、災害救助、スタートアップなど)ことから、チーム構造からチームワーク自体へ注目するという意味で動詞のチーミングが提唱される。 心理的安全 自立的かつ創造的なチームのキーになるのが心理的安全である。 心理的に安全な環境では、何かミスをしても、そのためにほかの人から罰せられたり評価を下げられたりすることはないと思える。手助けや情報を求めても、不快に思われたり恥をかかされたりすることはない、とも思える。そうした信念は、人々が互いに信頼し、尊敬し合っているときに生まれ、それによって、このチームでははっきり意見を言っ
このエントリーは読者としてスマートフォンアプリ開発者とWebフロントエンドエンジニアを想定して書いています。 CROSS2016に出るので、最近の自分の考えを整理しておく。 最近ReduxのSwift実装であるReSwiftを使って開発している。使った感想なども最後の部分に書いたけれど、このエントリーの本題はアプリの状態管理の話。 アプリは大きなシングルトン iOS、Android共にアプリを実装しようと思うと大抵シングルトンが必要になる。各ViewController内をまたがってデータを共有したいというユースケースが多いからだ。例えば ユーザーのログイン情報を集約するUserManager コンテンツへのいいね情報を集めるLikesManager ブックマーク情報を集めるBookmarkManager などなど。もちろんアプリの内容によってこれらの顔ぶれは違ってくると思うけれど、大抵U
昨年からぼちぼち読んでいて、先日読み終わった。どういう話か知らずに読み始めたのだけど、ナポレオンのロシア遠征を題材に、史実の人物とオリジナルキャラクターを混ぜて作ったフィクションとノンフィクションの間みたいな小説だった。物語の中に戦争の時期と平和の時期があるだけで、特に反戦とかそういう内容ではない。 岩波文庫の新訳がとても読みやすく、また訳者によるロシアの風俗や戦争の話が途中にコラムとして挟まっていて、内容を補完してくれて楽しめるようになっている。 簡潔で気の利いた文章 読んでいると、うまいこと言うなーという箇所がいくつもある。文読む月日とかを書くだけあって、トルストイは簡潔で気の利いた文章に執着があるのかもしれない。以下にいくつか抜粋。 「うん、すばらしい、すばらしい子どもたちだよ」なんでもすばらしいと考えることで、自分には手の負えない問題をいつも解決してきた伯爵が相を打った。 1巻。ロ
droidkaigi.github.io 4月に行われたAndroidエンジニアのお祭り、DroidKaigiの第2回が2016年の2/18、2/19開催予定で、現在発表を絶賛募集中です。自分は今回もスタッフとしてお手伝いさせて頂いています。 自分は前回発表したのですが、その後「資料見ました」と言ってくださった方が入社したので、直接のコンバージョンかはわからないですが、採用実績も1あります。 また、初心者向けセッションも要望が多いので、そういった発表もお待ちしています。2016年にAndoidを始めるのに一番近道な方法まとめ とか、とても喜ばれそうです。 技術を深掘りしたい方、裾野を広げたい方、採用に繋げたい方、DroidKaigiはあなたの発表をお待ちしています!
実は既に今日#2があるのだけど、#1に参加して感想を書いていなかったので、メモを引っぱり出して書く。 Qiita::TeamのIncrements社が主催の情報共有ツールお悩みNight #1に参加してきた。他社の事例とかを聞いてみたかったので。 内容 ワークショップx2 事前に募集した情報共有のお悩み(架空のものという設定)に大してチーム毎にブレスト、発表する 自分のチームのお題は「投稿しても見てくれない人が居る」「ツール導入の効果を計測しろと言われた」というものだった LT 懇親会 ワークショップのファシリテーターを任されていたので、聞き役に回って少し突っ込みを入れる役をやった(その割に結構喋ってしまった)。 感想 他社の話を聞いてみて、FablicはQiita::TeamやSlackをそこそこうまく使っている方なのかもしれないと思った(事例)。日報をGoogle+に移したのも、自分は
会社でホワイトボードを使ってカンバン形式でタスク管理をしているのだけど*1、ホワイトボードと付箋の組み合わせが好きなので家でも使っている。 貼っているのは読んでいる本とブログのネタ、あとはたまに進める自分のプロジェクト。週末に途中まで何かやって忘れることが多いのでそれを管理するのと、一度にたくさんのことを始めないように制御する役割がある。また、Doneに一個でも移せたら、その週はなんかがんばったという感じが出る。 実はこれはドアである。 吸着タイプのホワイトボードをドア(木製)に貼って使っていて、とても調子が良い。コクヨの技術はすごい。 コクヨ ホワイトボード ピタボ 吸着シートタイプ 無地 FB-P152W 出版社/メーカー: コクヨ発売日: 2008/12/01メディア: オフィス用品購入: 2人 クリック: 3回この商品を含むブログを見る *1:Pivotal Tracker、Tre
Rebuild: 98で紹介されていたので、英語だけどがんばって読んでみた。Inspiredと同じ方向性のプロダクトマネジメント本。違う人が同じ事柄について書いているという印象。しかし少しずつ違う視点が入っていて、プロダクトマネージャーの役割が立体的に見えるという意味で両方読む価値はあると思う(もう読んでしまったのでこう言うしかない)。 英語はかなり平易。使われている語彙がだいぶ簡単なので、他の英語の本に比べて読みやすいと感じる。それでも自分はちまちま読んで一ヶ月くらいかかった。 話題が割と新しめ。Google Buzzと写真共有アプリのColor(懐かしい!)が失敗した話が導入部分。 またInspiredに比べてスタートアップの文脈が強かったり、初期のビジネス的成功という点に重点が置かれている気がする。 以下、自分が線を引いた部分とコメント。引用の下の日本語は拙訳。 Chapter 1:
Inspired: 顧客の心を捉える製品の創り方を読み返していて、「第7章: プロダクトマネージャーを管理する」の一節 エンジニアリング部門というのは、基本的に、正しい製品を作ることではなく、製品を正しく作ることに専念することになっているからだ。 というところが引っかかったので、思うところを書いてみる。ちなみに「第5章: プロダクトマネジメントとエンジニアリング(実装)」にも「正しい製品を作るのか、それとも、製品を正しく作るのか」というタイトルの章がある。 エンジニアは製品を正しく作る エンジニアは製品をリリースする責任があるので、不確定要素を減らして正しいスケジュールでリリースすることにモチベーションがある。このために、開発が進むほどにエンジニアは保守的になっていく。企画段階では和気藹々とブレストしてアイデアを出していても、最後のリリース前にはしぶい顔で実装を拒んだりする。 エンジニアと
プロダクトマネージャーの職能+ユーザー体験設計の本です(と解釈しています)。 最近Rebuild: 98: Superhumans Wanted (Naoya Ito)やエンジニアからみた良いプロダクトマネージャとは? - サンフランシスコではたらくソフトウェアエンジニア - Higepon’s blogで話題のプロダクトマネージャーに興味があって、関連しそうな本を読みたいと言っていたら、知人がこの本を紹介してくれました。 Netscapeなどでプログラマーをしていたバックグラウンドを持ち、eBayなど複数の会社でプロダクトマネージャをしていた経験を持つ著者がプロダクトマネージャーの職能について語る本で、以下のような内用が含まれています。 プロダクトマネージャーとは何か どうやって他の職種と連携して働くか どうやって製品を見つけ出すか どうやってユーザー体験を作っていくか 自分にとっては、
自分が最初に元の誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)(初版はPOETと呼ばれている*1 )を読んだのは十数年前でした。4月に出たこの改訂版を読み返してみて、改めて感銘を受けました(そして内容をほとんど忘れていたのに気づきました)。 内容としては、エモーショナル・デザイン―微笑を誘うモノたちのために 、複雑さと共に暮らす―デザインの挑戦など後の書籍で検討された内容が盛り込まれて、ノーマン著作の集大成になっています。 自分がこの改訂版で注目しているのは、「6章デザイン思考」の追加です。 6章デザイン思考 正しい問題を発見するのがデザインである として、そのための手段としてデザイン思考が解説されます。 具体的にフレームワークとして取り上げられている人間中心デザインプロセスを見てみると、 観察→アイデア創出→プロトタイピング→テスト→観察… というサイクルになって
このところ、複数の人からリアクティブプログラミング(RP)ってつまり何なんですかと聞かれることがあった。そのたびに非同期データストリームが…みたいな説明をしていたのだが、たいてい双方納得した感じにはならなくて、まあ難しいっすね…という感じで終わってしまっていた。 iOSとAndroidでの用途 自分は理論より実践からしか考えられないタイプなので、もっと現場寄りの説明ができないか常々考えていた。そこで自分がiOSとAndroidアプリを実装する際に使っているReactiveCocoaとRxJavaの用途を考えてみたところ Promise(の高機能版) 複数のAPIコールを連鎖させたい場合にコールバックヘルを避けたい データバインディング(の高機能版) Modelの変更とViewの変更を同期したい の2つがメインだった。 この2つはRPライブラリを入れなくても実装できる。JavaScriptな
DroidKaigiというAndroidエンジニアのお祭りイベントで、現在発表を募集中です。自分もスタッフとして参加しつつ、会社のアプリのMaterial Design対応についての発表で応募する予定です(つまりまだ応募していない!君も間に合う!)。 DroidKaigiはYAPCのAndroidコミュニティ版みたいなイメージです http://t.co/wMHVLZnxh8 #droidkaigi— ninjinkun (@ninjinkun) 2015, 2月 3 自分はずっとスマートフォンアプリエンジニアにもYAPCのような大きなお祭りイベントがあると良いなと思っていました。今年こそDroidKaigiで発表するぞ、今年はDroidKaigiで発表できたので俺がんばった、みたいに思えるイベントになると良いなと思ってます。 今集まっている発表が、割と低レイヤーだったり硬派なものが多いの
この記事はAndroid Advent Calendar 2014の14日目です。 Androidアプリケーション開発をiOSのそれと比べると、SDKのソースコードが公開されていることがアドバンテージの一つになると思います。自分は半年ほど前から、開発時に時々SDKのソースコードを参照するようになり、それからSDKへの理解が深まって、開発効率が高まったと感じています。 この記事では、自分がSDKのソースコードを読む際に使っている方法をまとめます。たぶんよく知られている方法ばかりです。 1. ブラウザで見る GrepCode 特定のクラス名でぐぐっていたりすると、GrepCode というサイトが時々引っかかります。Javaのソースコードを集めて検索可能にしてくれているサイトですが、ちょっとSDKのコードを読みたいというときは、このサイトで読むのがおすすめです。 Android SDKの各バージ
女「わたしcoachが欲しい〜」 男「店ごと買ったるわ!」 女性陣「ヒュ〜」
Original: Advocating Against Android Fragments by @Piwai Translated by @ninjinkun Reviewed by @hotchemi 最近私はDroidcon Parisでテックトーク(フランス語)を行い、SquareがAndroidのFragmentを利用して直面した問題と、Fragmentを避ける方法について説明した。 2011年に我々は以下の理由でFragmentを使う決断をした。 この時点で我々はタブレットをサポートしていなかった。しかしいつかは対応することがわかっていた。FragmentトはレスポンシブなUIを作るのを助けてくれる。 Fragmentはビューコントローラーだ。ビジネスロジックを単位ごとに分離してテスト可能にしてくれる。 FragmentのAPIはバックスタックのマネジメントを提供してくれる(
もう先週のことになりますが、YAPC::Asia 2014でモバイルアプリ開発について発表しました。YAPCはエンジニアとして仕事を始めてからずっと憧れだったので、初めて登壇できてとても嬉しかったです。 自分の発表15分、gfxさん15分、二人でディスカッション10分という、ちょっとイレギュラーな構成の発表でした。その辺りの経緯を以下に書きます。 コンセプト お客さんはサーバーサイドのエンジニアの方が多いと予想していたので、モバイル開発をするエンジニアが普段考えていることを知ってもらうことをゴールにしました。この発表の内容は、バックエンドのエンジニアが直接使える知識ではないかもしれません。しかしモバイルエンジニアと関わる仕事をしているなら、彼らがどう考えているかを知っておくことは、どこかで役に立つのではないかと思います。このため、モバイルエンジニアである自分たちが今現場で直面していて、面白
Androidアプリは全体の5%のユーザーに公開するというような、段階的公開が可能です。会社でこの機能を使っているので、知見をまとめました。 目的 致命的な問題 (e.g. 商品が出品、購入できない)に全ユーザーを巻き込むのを避ける 不具合を減らしつつ、リリースサイクルのスピードを保つ 問題 母集団が少なすぎると問題が見つからない or 報告されない場合がある 変更できるのは公開するユーザーの割合のみ できる限り不具合にユーザーを巻き込まないようにしながら、早めに段階を上げるという問題を考える 戦略 プラン 松 変更点が多い場合、致命的なバグが発生する可能性がある場合 5 or 10%からリリース 最短で5日で全ユーザーにリリース (竹は考えてなかった…) 梅 変更点が少ない場合 20%からリリース 最短で3日で全ユーザーにリリース 運用 リリースの翌日に不具合の有無を確認して、大丈夫そう
Androidアプリを開発していると、開発版とリリース版のアプリを同時に入れておきたいことがあると思います。通常Appliction ID (com.ninjinkun.njkappのようなやつ) が同一だとアプリが上書きされてしまうのですが、Build Variantsを使う事で別のApplication IDを割り振ることができます。 build.gradle productFlavors { staging { setApplicationId("com.ninjinkun.njkapp.staging") } production { } } Manifest Placeholder この辺りは去年からできたのですが、 ContentProvider や BroadcastReceiver を使っている場合、Android ManifestにApplication IDが文字列で埋
original: The introduction to Reactive Programming you've been missing (by @andrestaltz) (translated by @ninjinkun, reviewed by @ma0e) あなたはリアクティブプログラミングと呼ばれる新しい方法が気になっている。 勉強するのは大変で、良い教材がないのでさらに難しい。私が勉強を始めたときは、まずチュートリアルを探した。見つけたのは一握りの実践的なガイドだけ、しかもそれらは表面をなぞっているだけで、リアクティブプログラミングのアーキテクチャ全体像を構築しようとしてはいなかった。ある関数を理解するのに、ライブラリのドキュメントは役に立たないことがある。 これを見て欲しい。 Rx.Observable.prototype.flatMapLatest(selector,
オンライン講義サイトのCourseraでFunctional Programming Principles in Scalaを受講して、先月にようやく終わりました。以下だらだらと感想です。 一回の講義が4,5本のビデオに分割されており、1本10分くらいなのでちまちま進められる 会社の昼休みに見ていた iOS, AndroidアプリがあってビデオはDLして持ち運び可能 コースの内容 Scala基礎 関数型言語でアルゴリズムやデータ構造をどう扱うか 課題はコードをsubmitするとテストが実行されて結果が返る形式で、プログラミングコンテストぽかった 課題で困ったらディスカッションボードを見る 色んな人が教えあっていて、その中で検索するとヒントにたどり着けることが多い 自分は人に教えたりはできなかったけど、一応お礼だけは書いておいた 楽しい、好奇心が満たされる、意識が高まる 受講してもいきなりS
先週の土曜日にReactiveCocoa (以下RAC)というOSX / iOSで使うリアクティブプログラミング(RP)フレームワークの勉強会を開催しました。 当日の資料 当日の資料のうち、見つけられたものは以下にまとめました。 はじめてのReacitveCocoa @tinpayさん はじめてのReactiveCocoa from Shohei Fukui https://github.com/tinpay/RACWarikan ReactiveCocoa勉強会に参加してきました #rac_kansai . ゆるやかなReactiveCocoaの導入 @ninjinkun 実践!Twitter API+ReactiveCocoa @atsusy さん var RAC3 = ReactiveCocoa + Swift @ikesyo さん var RAC3 = ReactiveCocoa
次のページ
このページを最初にブックマークしてみませんか?
『ninjinkun's diary』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く