タグ

2018年7月2日のブックマーク (16件)

  • ユーザーが許可したくなるPush通知を考える|sadakoa|note

    初めましての方もこんにちは、さだこえ (@sadako_a_ ) と申します。 DeNAに新卒で入社後、現在は株式会社FOLIOのデジタルプロダクトデザイナーとして、オンライン証券のUIデザインに従事しながら、スタートアップのデザイン支援を副業で行っています。 今記事では、主にアプリの機能として欠かせないPush通知に焦点を当て、記事を執筆します。 Push通知とはご存知の通りPush通知とは、アプリやwebサービスで何か変更や更新があった場合にお知らせをする機能です。一般的にこの業界で言われるPush通知は、Apple Push Notificationを指していることが多いと思われます。 その理由の1つとして、AndroidはPush通知に関してユーザーの許可を取る必要が無いからです。(ダウンロードする際にオプトインされるため、許可率は100%になる。) iOSやWeb Browser

    ユーザーが許可したくなるPush通知を考える|sadakoa|note
    koogawa
    koogawa 2018/07/02
    iOS 12から導入されるプッシュお試し受信機能はよ
  • 継続的に成果を出し続けるたったひとつの冴えたやりかた - 弥生開発者ブログ

    みなさんこんにちは、 @k0matatsu です。 1月にMisocaのメンバーに加わって、普段はモバイルアプリを開発しています。 アプリ開発は集中力を要するたいへんな作業ですし、一週間働き続けるとくたくたになってしまいますよね。 今回はその疲労を解消し、継続的にパフォーマンスを出していくコツを紹介します。 私は現在、鳥取県境港市にある自宅でリモートワークをしながら、必要に応じて松江にあるオフィスに出社するという働き方をしています。 そして自宅の近くには皆生温泉、オフィスの近くには玉造温泉があります。 *1 この恵まれた立地とフレックスタイム制度を活かして、仕事を早めに切り上げて温泉に行き疲労を回復させるという活動を1〜2週間に1回のペースで行っています。 入浴による効果は、入浴した時間帯とは関係ないので、早めに切り上げて行く必要があるのか?と思いますよね。 夕飯後のピークタイムに公衆浴場

    継続的に成果を出し続けるたったひとつの冴えたやりかた - 弥生開発者ブログ
    koogawa
    koogawa 2018/07/02
    温泉、最高すぎる
  • ビールの泡にアートする、ビールアートマシン。Ripples(TM)(リップルズ)が日本初上陸! - BRIDGE(ブリッジ)テクノロジー&スタートアップ情報

    一杯のドリンクと共に感動とスマイルをつくりだす、ビールアートマシンとコンテンツマーケティングプラットフォームです。 既に世界各国で発売され、ヤンキーススタジアムなど様々な場所で大好評のビールアートマシン、及びコンテンツマーケティングプラットフォームのRipples(TM)(リップルズ)が、Beach Cafe SUMMER&IDOLにて日に初上陸します。 PR TIMESで文を見る

    ビールの泡にアートする、ビールアートマシン。Ripples(TM)(リップルズ)が日本初上陸! - BRIDGE(ブリッジ)テクノロジー&スタートアップ情報
    koogawa
    koogawa 2018/07/02
    ビールアート良いなぁ
  • 進化するAppleの地図 その中身が明らかに

    Appleのマップに関する、Appleのインターネットソフトウェア&サービス担当シニアバイスプレジデントであるエディー・キュー氏、マップ&インフラ担当ヴァイスプレジデントのパトリス・ゴーティア氏へのインタビューをTechCrunchが掲載している。 Appleは、2012年9月19日にリリースしたiOS 6でGoogleマップから独自マップに切り替えたものの、さまざまな理由で批判に晒され、ティム・クックCEOが謝罪するにまで至ってから6年が経過した。Appleはマップに対する開発投資を続けてきた結果、4年前にサードパーティ製マップデータから、Appleが独自に収集したデータによって構築する方針に変更し、Appleのマップは高速データを用いてリアルタイムにマップデータを更新するまでに進んだそうだ。 2015年頃から見かけられるようになった、Apple Mapsをよりよくするために利用するデー

    進化するAppleの地図 その中身が明らかに
    koogawa
    koogawa 2018/07/02
    “アメリカと日本では、拡大縮小した場合の情報増加段階が違ったり、道路を曲がる時の角の示し方が違うなど膨大な相違点がある” へぇ〜
  • ZOZOに、ZOZO SUITでやってもらいたいことを書いてみた|けんすう

    ついにこの僕にもZOZO SUITが届いたですよ。知らない人のために説明しておくと、ZOZO SUITとは「なんか変な服を来て自分のサイズをスマホで計測できて、そのサイズにあった服を買える便利なサービス」という感じです。 ZOZOさんは、プライベートブランドを作って、Tシャツとかジーンズとかをそれで提供したりするのです。 んで、Tシャツ3枚くらいとジーンズを買ってみたんですが、これが思った以上によくてですね。サイズはジャストだし、着心地もいいし、何よりTシャツ1200円、ジーンズ3800円とリーズナブルです。 思った以上に体験がよかったのですが、ZOZO SUITがあれば、ZOZOにおける今後の様々な展開の大きな武器になるなーと思ったので、ZOZO SUITが今後やってもらいたいことを書いてみました! ZOZO Designer's Storeまず思いつくのが、Tシャツのデザインを増やすた

    ZOZOに、ZOZO SUITでやってもらいたいことを書いてみた|けんすう
    koogawa
    koogawa 2018/07/02
    ファッションECの世界が変わるんだなぁ、というのを読んでて実感した
  • Twitter での6年間 #8|Satoshi Nakagawa

    (Twitter での6年間 7 からの続き) これ以後は、新アーキテクチャプロジェクトが長期間続くので、大きな変化はなかったと思う。 なので、この話はいったんここで筆をおくことにしたい。 ぼくは、今年3月に Twitter を辞めることにした。もともと新しい物事を学ぶことが好きなので、あまり同じ環境に長くいるのには向いてなかったのだと思う。それでも6年間やってこれたのは、すばらしいマネージャーや同僚にめぐまれたことが大きいし、ぼくが Twitter というサービスをすごく好きだったからだと思う。 Twitter という会社では、優秀なエンジニアやデザイナがユーザーのためになるように日々プロダクトを開発し続けている。これからもユーザーとして便利に使っていこうと思う。

    Twitter での6年間 #8|Satoshi Nakagawa
    koogawa
    koogawa 2018/07/02
    Sunset、いや Sunrise かな
  • 退職しました - みんからきりまで

    6月末でAnyPay株式会社を退職しました。 AnyPayには正社員として1年、業務委託時代も入れると1年半お世話になりました。 なんでやめるの 簡単に言えば音楽性の違いみたいな感じです。 なにをやってたの AnyPayではAndroidエンジニアとして参加し、主にpaymoのアプリ開発をやっていました。 去年の2月に初めて出社した当時はまだAnyPayはとても小さな会社で、エンジニアの社員はCTOと社員代表の2人しかおらず、ぼくは初めてのフルタイムモバイルエンジニアでした。 そこからリモートや参加してくれている協力会社の方などと協力しながら、モバイルアプリの内製体制を少しずつ作っていきました。 アプリの設計見直し、テストコード、Kotlin導入 当時リリース直後でコードが若干無秩序だったpaymoアプリの設計見直しとKotlinの導入を行いました。 詳しくは以下のブログで解説しています。

    退職しました - みんからきりまで
    koogawa
    koogawa 2018/07/02
    お疲れ様でした!
  • いつもhiragramを応援してくださる皆様へ - hiragram no blog

    スタートトゥデイテクノロジーズ(旧VASILY)を退職します。今日から有給消化です。 次は決まっていません。8月からiOSらへんの技術者として雇ってもらえる会社を探しています。 最近業務やら個人やらでやったことは以下の通りです RxSwiftの啓蒙 ビットコインのアービトラージ取引支援アプリみたいなやつ OpenAPI(Swagger)ドキュメントからAPI定義/モデル型定義のコードを生成する仕組みの開発 任意の状態のスクリーンショットを収集する仕組みの開発 消費型課金/サブスクリプション型課金の実装 CI周りいろいろ API/UserDefaults/Keychainなどの抽象層の設計、実装 try! Swift Tokyo 2018で型安全なWebAPIモデリングについてLT発表 その他細々した発表 今の所あんまりやりたいと思っていないことは以下の通りです 医療 金融 新しい環境に強く

    いつもhiragramを応援してくださる皆様へ - hiragram no blog
    koogawa
    koogawa 2018/07/02
    お疲れ様でした!
  • 歯に衣着せぬ発言と美学について - Konifar's ZATSU

    雑に考えをまとめておきたい。雑すぎて気分を悪くしたらすまない。自分が「雑に書く」というときは別に深く考えていないわけではなく、「色んな印象で捉えられるのをできるかぎり想定して文章を練る手間を省くよ」という意味なので、ちょっとムッとしたとしても受け流してもらえると嬉しい。 職場でもどこでもあることだと思うんだけど、歯に衣着せぬ発言をあえてする人っているよね。例を出すのは難しいけど、「もうちょい言い方考えようよ」と思わせる言い方で人をイラつかせるというか。自分はわりと気が長い方なのでオイオイと思うだけでそんなにイライラすることはないんだけど、当然イラっとする人もいて、そういう時に空気が悪くなるのはつらい。 チームで何かするのに向いていない人だと言ってしまえばそれまでなんだけれど、そういう人は2種類のタイプに分かれるんじゃないかと感じている。自分の発言が空気を凍らせていることに気づいていない人と

    歯に衣着せぬ発言と美学について - Konifar's ZATSU
    koogawa
    koogawa 2018/07/02
    これは受け売りなんだけど、`率直に言うこと` と `感じ悪く言うこと` を混同して、 感じ悪く言うことを率直だという正義に置き換えてしまっている人が一定数いる現実
  • HiveShibuyaに通っていました - UNIX的なアレ

    HiveShibuyaのエントランスにて。 日まで、 HiveShibuyaというコワーキングスペースに週2くらいで通っていました。というのも現在は割と自由な立場でいろいろやっているのですが、家にいるとYouTubeかNetflixをダラダラみちゃうんです(しょーもない) というわけでこれは良くない!と反省して、起業しろで有名な木下さんに相談して、席を借りていたという流れになります。 #起業しろ ・アメリカ by @wadap 。#HiveShibuya のスーパーヒーローとしてUNDEFINED チームを中心に守ってたのですが今日卒業とのこと。今後の和田さんが気になりますね! pic.twitter.com/iHw58BV5Kj— 木下 慶彦 / Skyland Ventures (@kinoshitay) 2018年6月28日 http://www.skyland.vc/hive/

    HiveShibuyaに通っていました - UNIX的なアレ
    koogawa
    koogawa 2018/07/02
  • 「女性エンジニア」発言についての私的見解 - 科学と非科学の迷宮

    2018年4月21日に開催されたイベントの一セッションについての書き起こしについて発生した一連の論争について、私の思ったことをまとめます。 まず始めに、セッション発表者に対し攻撃的なツイートを行ってしまったことに対し、謝罪します。私のツイートによって多くの人が声を上げることとなり、それによって発表者の方の反論の機会を奪ってしまいました。 謝罪の証として、以下の事柄について約束します。 件について直接言及していて、かつ発表者に対して攻撃的な内容となっている全てのツイートの削除、及び発表者の方からの指定したツイート削除申請の受諾 発表者の方のいかなる反論に対しても、その意見の場を守るための支援 記事は、上記を踏まえた上で、何が起きたのか、何が問題なのか、なぜ私がここまで問題視しているのか、問題を防ぐためにはどうすればいいのか、について記述していきます。 何があったのか 2018年4月21日

    「女性エンジニア」発言についての私的見解 - 科学と非科学の迷宮
    koogawa
    koogawa 2018/07/02
  • Twitter での6年間 #6|Satoshi Nakagawa|note

    (Twitter での6年間 5 からの続き) 2014年3月、グリーンカード、つまり永住権の申請プロセスをはじめることにした。そのときぼくは H-1B ビザで働いていたのだが、このビザには6年の最終期限がある。2010年10月からなので期限まで残り2年半しかなかった。一度期限が切れてしまうと、基的には国外に出ていかなければいけなくなる。H-1B で働いていてこれからも US で働きたいと考える以上、グリーンカードを取得する必要があるわけだ。 6月の WWDC で、iOS 7 にシェアエクステンション機能が搭載されるとの発表があった。社内でそれを実装するために優秀なエンジニア2人のチームが結成された。この機能はアプリから独立した拡張として別プロセスで動作するので、iOS に標準搭載されている Twitter 連携機能を直接使う必要があった。そこでその問題について詳しいぼくが認証部分をチー

    Twitter での6年間 #6|Satoshi Nakagawa|note
    koogawa
    koogawa 2018/07/02
    初代 Apple Watch が発表された時期かー
  • Twitter での6年間 #5|Satoshi Nakagawa|note

    (Twitter での6年間 4 からの続き) 2013年の春ごろだっただろうか。上のほうの人が、A/B テストをプロダクト開発に活用することを推奨し始めた。A/B テストでプロダクトの方向性を決めていくというのだ。これにつられ、この頃の社内では A/B テスト万能論のような空気さえただよっていた。普通に考えて、A/B テストを数週間走らせてデータをとっても、それが長期的な成功につながるか判断できるはずがない。短期的に数字が上がるからといってユーザーの嫌がることを続けていれば、いつかユーザーの忍耐の限界に達してしまうかも知れない。そのユーザーの堪忍袋の状態をどうやって計測できるというのか、など疑問は尽きなかった。 そのころ Growth という大きな部署ができて、従来国際化を担当していた i18n エンジニアリングチームもその下に組み込まれることになった。Growth チームの強い権限のも

    Twitter での6年間 #5|Satoshi Nakagawa|note
    koogawa
    koogawa 2018/07/02
  • Twitter での6年間 #5|Satoshi Nakagawa|note

    (Twitter での6年間 4 からの続き) そうこうしてるうちにコードネーム H という野心的なプロジェクトがスタートすることになった。最初は Hackweek の1プロジェクトとしてはじまったらしく、複数のタイムラインをスワイプで切り替えられるようにすることで、これまでのタブ UI による固定数のタイムラインではなく、たくさんのタイムラインをユーザーの好みに応じて追加することができるというアイデアだったらしい。このプロジェクトに iOS フレームワークチームのエンジニア全員が投入されることになった。当時 IPO の時期が近づいていたこともありクオリティよりも開発スピードを優先しないといけなかったので、まずレビューを一切なくして各自がコードをレポジトリに直接コミットすることになった。さらに、各機能のチームからの機能追加はメンテナンスブランチに対してのみ許され、しかも最小限に行うようにと

    Twitter での6年間 #5|Satoshi Nakagawa|note
    koogawa
    koogawa 2018/07/02
    タブのままで良かったと思う
  • Twitter での6年間 #4|Satoshi Nakagawa

    (Twitter での6年間 3 からの続き) 2013年に入り、iOS 6 の普及率も十分に高くなったころ、同僚のエンジニアから1つの提案がなされた。ツイートビューを作り直そうというのだ。その時点での Twitter for iOS は、iOS の黎明期に Apple が推奨していたように、できるだけビュー階層を減らして描画するようになっていた。たとえば、ツイートビューには一切サブビューがなく、ツイートテキスト、プロフィール画像、ユーザー名、タイムスタンプなどのパーツは直接ツイートビューに自前で描画する設計になっていた。当初はそのほうがパフォーマンス的に速かったからだ。それから数年間の Apple によるハードウェア、ソフトウェア両面での改善の結果、ベンチマークを取ってみるとどうやらその設計はもう古いらしいことがわかった。たとえば画像を表示するときに、自分でビューに CPU で描画するの

    Twitter での6年間 #4|Satoshi Nakagawa
    koogawa
    koogawa 2018/07/02
    Twitterアプリの TableView はなんでこんなにスムーズなんだろうな、と感じていた時期が確かにあった
  • 代替案を考える癖をつける - Konifar's ZATSU

    雑にまとめる。 代替案なき意見は不要だとは思わないが、議論を前に進めるためには代替案を考える癖をつけておいた方がいい。 代替案がない意見が歓迎されるのはブレストなど全員の思考を広げる時、あるいはたたき台を元に考慮漏れを指摘し合う時くらいであって、議論して何かを決めていくフェーズではちょっと微妙だと言わざるをえない。 具体的に言うと、「ここってこういう場合どうなるんですか?」「ここってダメだと思います」みたいなただの疑問や反対意見を言うシーン。もちろんそういう指摘が無駄だとは思わないが、相手に答えを押し付けることになる。また、自分はこうしたいという考えを伝えないと相手も反応しづらい。小さなストレスが積み重なるし、コミュニケーションも一往復増えてしまう。 これに対する対策は簡単で、繰り返しになるが代替案を考える癖をつけることだ。ここダメじゃんと思ったらそれをそのまま伝える前に、こうした方がいい

    代替案を考える癖をつける - Konifar's ZATSU
    koogawa
    koogawa 2018/07/02
    相手を困らせるのが目的じゃないし、本当に気をつけたい