BNN CAMP vol.3 インタラクションデザインの現在―プログラミング初心者のためのopenFrameworks入門 1
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? by @mixiappwchr アプリ向けのAPIの開発時に気をつけてもらえるとうれしい&メンテナンスや実装コストが下がる点をつらつら書きます。 データ構造について データを返すとき、一定のルールを守って返す。例えば当然ですが同じデータ構造はもちろん、似たような構造もルールを作ってproperty名などそろえておく。relationやlistで返すときもどのデータ構造なのかがpropertyで明確にわかるようなっているようにする listを返す場合の形式やpagingが必要な場合の形式はそろえる。配列のデータがない場合も考慮しておく。例
Twitter開発のテストはローカルで西村賢氏(以下、西村):Twitterって巨大な世界的企業で、一般的な開発と全然かけ離れているイメージがあったんですね。今ちょっと驚いたのがRailsでローカル環境でまだやってるということで、ローカル環境、例えば蓑輪さんも入られて最初、Macかなんかで開発するわけですよね。その上に開発環境を整える。 具体的に、例えばデータベースのところはどうするとか、結構この環境構築は大変なんですか、最近、その開発環境とステージングとプロダクションをなるべく近づけろとか、ありますよね、そういうトレンドが。そういう意味で言うと、ローカルTwitterが再現できちゃうというのは、不思議な感じなんですけれども。 蓑輪太郎氏(以下、蓑輪):そうですね。設定自体はそんなに難しくないです。ローカルで開発できるメリットってやっぱり、閉じているので安全じゃないですか。Twitterの
前回の記事で環境構築と土台となるプロジェクとの作成ができたので、今回から実用的なアプリの制作に入ります。数回にわけてTwitterクライアントを作成しますので、ネットワーク周りや画像の取り扱いまでTitaniumの簡便さを体験していただければと思います。 どんなものを作るか まずは、実際に作るアプリのイメージを固めましょう。TwitterアプリはiPhoneアプリの中でも優れたアプリが多く激戦区となっているジャンルです。一方でTwitterを使い込んでいくと自分のよく使うWebサービスと連携させたくなり、自分の使い方にカスタマイズしたアプリも欲しくなるものです。ということで、Twitterのひと通りの機能を実装しつつ拡張しやすいシンプルなアプリを目指しましょう。 図1 画面イメージ 画面構成としてはこのようなアプリをイメージしておきましょう。 まずはTableView Twitterアプリ
<g> <g> <defs> <rect id="SVGID_1_" x="-468" y="-1360" width="1440" height="3027" /> </defs> <clippath id="SVGID_2_"> <use xlink:href="#SVGID_1_" style="overflow:visible;" /> </clippath> </g> </g> <rect x="-468" y="-1360" class="st0" width="1440" height="3027" style="fill:rgb(0,0,0,0);stroke-width:3;stroke:rgb(0,0,0)" /> <path d="M13.4,12l5.8-5.8c0.4-0.4,0.4-1,0-1.4c-0.4-0.4-1-0.4-1.4,0L12,10.6L6.2
Fast, unopinionated, minimalist web framework for Node.js $ npm install express --save const express = require('express') const app = express() const port = 3000 app.get('/', (req, res) => { res.send('Hello World!') }) app.listen(port, () => { console.log(`Example app listening on port ${port}`) }) [email protected]: Now the Default on npm with LTS Timeline Express 5.1.0 is now the default on npm,
Tweet Marker was an award-winning, cross-platform web service for syncing the reading position between multiple Twitter clients. Thank you Macworld for recognizing Tweet Marker with a Editors’ Choice Award for 2011! After 8 years, I had to shut down the Tweet Marker API. Thanks to all the many third-party Twitter apps that supported Tweet Marker over the years, including: Twitterrific — Mac, iPad,
まえがき データにIDを持たせたいとき、単純な方法としては、DBの提供するauto incrementを使う場合やUUIDを利用することがある。それぞれの方法の利点欠点は以下の通り。 データベースのauto incrementを使う場合 利点: 特別な実装が必要ない 欠点: DBを1台で運用するとデータベースがパフォーマンス・障害のボトルネックになる DBを二台にするとIDのユニークさや順序の保証が困難 UUID(v4)※1を利用する場合 利点: 分散環境で各々がIDを生成しても衝突しない IDを公開したくない場合に、推測されにくいIDを生成できる 欠点: 128ビット必要、DBのインデクシングやプログラミング言語で扱うときに不利なことがある IDから時間の情報が失われる、例えば2つのIDを比べてどちらが古い投稿か判断できない 世界の大企業がどうしてるか 調べてみると多くの企業がブログなど
Webアプリ作っているといろんな局面でユーザー認証が必要になる局面がある。まじめにつくると果てしなく面倒だし、適当につくるとセキュリティ上問題になるので、要件に応じて適切に手抜きする必要がある。 適当なやつからしっかりしたやつまでなんとなくソートしていくとこんなかんじだと思う。 認証なし IPで弾く Basic認証(ソースコード、設定ファイルにパスワードベタ書き) Basic認証(DBにUserテーブルをつくってパスワードを保存。追加はcliとかで手動) login/logout画面作成。cookieなりmemcacheなりにセッションを保存 webからユーザーを追加できるように password変更機能 OAuth OpenID mailを送ってリンクをクリックさせてメールアドレスの所有確認 メールアドレス変更機能 メールを使ってのパスワードリセット機能 OAuthで作ったアプリへの後か
詳解Objective-C2.0にはテストの話がなかったけど、この辺は何で学ぶのがよいのだろうかなあ 2014-01-12 10:49:26 via web @nagayama テストのこと書いてある和書たぶんぜんぜん無い気がします。洋書ならありそう。Xcode標準のXCTestとOCMockとOHHTTPStubsとTKRGuardを使ったら最低限の単体テストが書けるつもり。あとexpectaとspecta使ってもよさそう。 2014-01-12 12:37:56 via Twitter for iPhone to @nagayama から 公式ドキュメント翻訳 Xcodeの概要(PDF) 「アプリケーションのユニットテスト」の項目があります、が内容は薄い。 Instrumentsユーザガイド(PDF) 「UIのテストの自動化」の章がありUI Automationについてふれられています
あけましておめでとうございます。 昨年の暮れに『日経ソフトウエア』誌の新春恒例である技術予想企画に参加しました。きっかけは特集担当記者の大森さんからアンケートへの回答依頼を頂いたことです。その大森さんに掲載許可も頂いたので、このエントリでは私が行った回答に関して書いてみたいと思います。 日経ソフトウエア 2014年 02月号 [雑誌] 出版社/メーカー: 日経BPマーケティング発売日: 2013/12/24メディア: 雑誌この商品を含むブログを見る アンケートには大きく二つの設問がありました。 問1 プログラミング分野における2013年の大きなトピックは何だったとお考えかを、「なぜその技術が重要か」という理由付きで教えてください。 問1は 2013 年に関する質問であり、この一年であったプログラミング上のトピックを一つ回答しようと考えました。となるといくつか挙げられるのですが、私が 201
35カ国・59サイトをどう統制する? 三菱電機が完遂した「グローバルサイト統合」と、AI時代の新構想 4月14日 7:05
鈴木雄介さんが、「アジャイルがダメだと思う7つの理由」というすごいブログを書いてくれたので、がんばって返答を書いてみる。どこかでディスカッションできるといいなぁ。 1. 全体スケジュールにコミットできない コミットメントって何だろう。コミットメントは約束なのか。約束であったら、破った場合のペナルティも受け入れるのか?受け入れたところでバッファが巨大になるだけではないのか?そして、そのバッファは見えないところで食い尽くされる。 全体を見えずに計画したところでうまくいくはずはない。アジャイルがタイムボックスで計画、実施を行うからといって、全体を計画しないわけではない。むしろ積極的にやるべきである。 全体を計画する上では、なるべく漏れがないように、実施可能なように最大限の努力をする。ただ、それに時間を掛けすぎるのは無駄だ。そして、神ならぬ人間が計画するのであるから、以下を認めなければならない。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く