使いやすいアプリを作る簡単な方法
使いやすいアプリを作るための、とても簡単で、確実な方法があります。 それは、ユーザの問い合わせに対応することです。具体的に言うと、問い合わせが気軽にできるようなUIにして、そこで得た情報源を元にUIを分かりやすく改良していく。(機能追加とはまた別の話) ただ、直感的に感じるように、これは手間がかかるのでたくさんの人は逆のことをしようとする。つまり、ユーザヘルプを設置して、問い合わせ先は出来るだけ発見しにくい洞窟の奥深くに設置する。 でも、問い合わせには、アプリの利便性向上につながるヒントが豊富に隠されています。ユーザがどんな問題やニーズを持っているかのヒントもザックザック出て来ます。ザックザックです。 アプリ開発にとって、やったことがいい事は星の数ほどあって、そのどれもをやろうとすると時間やお金がいくらあっても足りません。だから、”やったほうがいい事”の優先順位は常に意識して、メリットとそ
モバイルアプリ開発で面倒なサーバAPIバックエンドの切り替えを動的に行う - Qiita
これはリクルートテクノロジーズアドベントカレンダー18日目の記事です． 14日目に出た図にそっくりですね APIエンドポイントを固定したままバックエンドを切り替える モバイルアプリの開発時，サーバ側APIの開発も同時並行で実施している場合，皆さんは開発中のアプリと開発中のサーバの対応をどのようにとっているでしょうか？ 開発のたびにアプリ内のサーバAPIのエンドポイント設定値を変更してアプリをビルドし直す 開発版のアプリはconfig配布サーバから設定を取得し，設定値に記載されたエンドポイントと通信する など，上記のような方法が考えられますが，クライアントアプリ側に開発デバッグ用の機能を作りこんでいくのは面倒で，なるべく少なくしたいのではないかと思います．そこで今回は，モバイルアプリで設定するエンドポイントURLは固定にしたまま，サーバ側でモバイルアプリからのリクエストに応じてバックエンドを
API設計での開発でのジレンマと、フロントエンジニアのサーバー側を実装について - Qiita
はじめに API設計での開発を友人の @otukutun としていたときの話です。 予め言っておきますが、 今回の話は割と主観な部分が多いです http://qiita.com/otukutun ←岩手県立大学出身 (このアドベントカレンダー続くと良いですね笑) API設計時のジレンマ API設計にしておくと * HTMLのコーディングデータのサーバーへの組み込みが発生しない * フロント側とサーバー側の作業範囲が明確に分類されるためタスク割り振りが行いやすい * 自分の実装範囲が明確になるので遠隔作業がしやすい などのメリットがあると個人的には感じています。 (ただ、フロント側の実装量は一気に跳ね上がるイメージもあります苦笑) 今回は、私がフロント開発(Angular.js)、@otukutunがサーバー側開発(Rails)という分担になり、API設計で開発をすることにしました。 接続部
【使ってみた】チーム内の情報共有を加速させるWebサービス6選 全力レビュー
ども。はじめまして。岸です。 日報・議事録・ソースコード・気になったニュースやアプリ...などなど。チーム内外での情報共有って、重要なんですがまぁ面倒くさいですよね。 単に共有するだけならメールやチャット、ファイル共有サービスで十分なんですが、ぶっちゃけ「ただ単純に共有だけしてもあんま意味ない」んですよ実際...。 ただ共有しても意味が無い。情報を活用するために必要なステップとは？ 前述の通り、情報ってただ単純に「共有すれば終わり」ではなくなんかしらに活かしてこそようやく意味を持ってくるもの。 なので、そのために必要なプロセスとしては... とりあえず全ての情報を蓄積する バラバラな情報を再構成してまとめる それぞれの情報を基に議論や考察を行う 考察の結果を踏まえて「抽象化」する んでそれを「体系化」してすぐに取り出せるようする みたいな項目がどうしても必要になってきます。 溜まった情報を
Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した（前編）
Google エンジニアの Steve Yegge 氏、Google+ への懸念を漏らす http://japan.internet.com/busnews/20111013/8.html で記事になってたけど、原文とちょっと要旨が変わっちゃってサービスへの警鐘みたいになってしまってたので、全文訳してみた。くそ長い。お暇な方どうぞ。 （2011/10/19 08:14）ありがたい誤訳の指摘をいただいたので3カ所修正。 Stevey の Google プラットフォームぶっちゃけ話 僕は6年半ばかり Amazon にいて、今はそれと同じくらい Google にいる。この二つの会社について強く感じることは（しかもその印象は日々強まるのだけれど）、 Amazon は全てにおいて間違っていて、 Google は全てにおいて正しいということだ。そう、やりすぎな一般化だけど、驚くほど正確だと思う。いやも
Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ - Qiita
まえがき データにIDを持たせたいとき、単純な方法としては、DBの提供するauto incrementを使う場合やUUIDを利用することがある。それぞれの方法の利点欠点は以下の通り。 データベースのauto incrementを使う場合 利点: 特別な実装が必要ない 欠点: DBを1台で運用するとデータベースがパフォーマンス・障害のボトルネックになる DBを二台にするとIDのユニークさや順序の保証が困難 UUID(v4)※1を利用する場合 利点: 分散環境で各々がIDを生成しても衝突しない IDを公開したくない場合に、推測されにくいIDを生成できる 欠点: 128ビット必要、DBのインデクシングやプログラミング言語で扱うときに不利なことがある IDから時間の情報が失われる、例えば2つのIDを比べてどちらが古い投稿か判断できない 世界の大企業がどうしてるか 調べてみると多くの企業がブログなど
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba
自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は本当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう？と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる
2014年のウェブシステムアーキテクチャ - stanaka's blog
(Monitoring Casual Talk in Kyotoで発表してきたので、ブログエントリにまとめ直しました) 2013年はインフラ周りの技術的な進化が大きく、いくつかのエポックメイキングな概念と実装が産まれました。個人的には特に以下の2つが大きいと思っています。 AWSの本格普及期 DockerとImmutable Infrastructure これらを踏まえて、2014年のウェブシステムの進化の方向性を考えてみます。また、それによるモニタリングへの影響もあわせて考えます。だいぶ長くなってしまったので、急ぐ人は最後に結論をまとめましたので、そちらからどうぞ! 2013年という時代背景 AWSが本格普及期を迎えているのは、言わずもがなのことで、Re:Inventでの246件という膨大のセッション数などにその勢いが表われています。 また、DockerはLXC (LinuX Conta
細かすぎて伝わらないAndroid開発のはまりどころまとめ その1
これまでandroidアプリを開発しててはまったことがたまってきたのでまとめておきます。順不同です。 その2はまたねたがたまってきたらたぶんそのうち。 目次 onAnimationEndでviewの階層を操作するとNullPointerExceptionでおちる Viewをフェードアウトして親Viewからremoveする、というような動作をしたい場合に、普通にonAnimationEndの中でremoveViewとかするとNullPointerExceptionでおちます。onAnimationEndの中でViewの階層構造を操作するような処理をしてはだめらしいです。回避するには、Handlerをつかってタイミングをずらしてやるとよいです。 参考: http://stackoverflow.com/questions/5569267/nullpointerexception-that-do
Djangoでソーシャルアカウントを扱う – taichino.com
先日の番付メーカーではTwitterとFacebookのアカウントでログインできるようになっています。 ソーシャルアカウントを使うと、地味なくせに工数のかかるユーザ管理を実装せずにすむので助かりますね。ところがソーシャルアカウントを扱うのも楽チンとまでは言えません。そもそもOAuthの処理を実装するのも面倒ですし、TwitterとFacebookを両方扱うとなってくると割と大変です。加えてGoogle+だYahooだとなってくると頭が痛くなってきます。 Hextrisを作ったときは自前でTwitterのOAuthでのログイン処理を書いたのですが、今回はFacebookアカウントも扱うというので複雑度が3倍くらいになって面倒です。 これはアカン、なんか無いのと思って調べてみるとDjango-Social-Authというナイスモジュールが見つかりました。これはDjangoのアプリとして実装され
Javaすら知らなかった私が5日間でAndroidアプリをリリースするためにやったこと。 | Last Day. jp
Javaすら知らなかった私が5日間でAndroidアプリをリリースするためにやったこと。 最終更新日： 2015/09/03 Android開発 久々にプログラミングをしました@sayobsです。表題にある通りはじめてリリースしたiPhoneアプリ「iOkinawa!」をAndroidでも5日間で作ってみました。 題名は前回iPhoneアプリをリリースした時と同じようにしました。 C言語すら知らなかった私が２ヶ月でiPhoneアプリをリリースするまでにやった事。 | Last Day. jp２ヶ月間独学で勉強したiPhoneアプリが遂にリリースされました。今日は私が実際にどのように２ヶ月でiPhone… 作ろうと思ったきっかけ✔GALAXY S II LTE SC-03Dを買って前々からAndroidアプリを作ろうと思っていた。 ✔先日沖縄に行った際Androidユーザーの方に「iOkin
Androidアプリ開発でテストを始めるための基礎知識
Androidアプリのテストに関する課題 Android端末の普及は世界規模で増加の一途をたどっています。2011年秋冬モデルが発表され、発売予定のものを含むと日本で発売中のAndroidの携帯端末は100機種に迫ろうとしています。読者の皆さんの周囲を見渡しても、電車や街角でAndroidを採用したスマートフォンなど携帯端末を使用する人をよく見かけるのではないでしょうか。 そして、スマートフォンに留まらずタブレットやミュージックプレイヤー、電子ブックリーダー、POSレジ、テレビなど、さまざまなデバイスがAndroidを搭載し始めています。Androidの採用が増えるにつれ、Androidアプリの種類が増えるので、アプリの開発案件も増えることになります。実際、本稿を読んでいる開発者の方の中にも、すでにAndroidアプリの開発に取り組んでいる方も多いのではないでしょうか。 筆者も普段の業務の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デスマーチが起きる理由 - ３つの指標
FINAL FANTASY Record Keeper の作り方
コードレビューの話
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
20110409_DevLOVE「Building Blocks」_都元ダイスケさん
ずぶの素人がRails開発できるようになるために必要な5つのこと
IDEA * IDEA
