text.ssig33.com - RSpec の書き方について
RSpec の書き方について 要約:RSpec は単なるテストを英語っぽく書けるツールではなく開発の全プロセスを加速するツールであるのでプロジェクト初期から有効に利用する必要がある。 4/1 ですが気にせず真面目な話を書きます。 RSpec は多分 Ruby 界隈で一番使われているテストフレームワークの一つだと思います。であるので使い方の解説や概念の解説多いですが、個人的にはそれらの解説は的を外したものが多いと考えています。 RSpec の真髄を会得するには、 RSpec の spec をどのように書くかということを考えてゆく必要があると思います。 まず RSpec の特徴的な点とはなんでしょうか。 RSpec でテストは以下のように書かれます。 describe "肛門" do context "排便する時" do it "高速に排便されると肛門がすりきれる" do 肛門がすりきれるとい
text.ssig33.com - ターゲティング広告の何が問題か？
ターゲティング広告の何が問題か？ という話について書く。結論としては「プライバシーが広告主に渡るのが問題」ということになる。他にもいろいろ問題はあるがこれについて書く。技術的な問題については一切書かない。 Web におけるターケティング広告とは、特定の属性を持った人に対してのみ広告を表示する、というもので、例えば広告主は 20 代男性 独身 関東在住 アニメに興味がある 人物に対してのみ表示される広告を出稿することが出来る。このような属性を持った人物にアニメやゲームに関係する広告を出せばクリックしてもらえる可能性は高いだろう。 ところでこうした属性を得る為にサードパーティークッキーを用いた行動追跡が行なわれているし、 Facebook ではユーザーが入力した情報をもとに広告が出たりする。この辺はマラが詳しいのでマラに聞いてください。 ところでこうした広告において「東京都杉並区清水6丁目に住
text.ssig33.com - Facebook アプリ開発で注意しておくべきこと
Facebook アプリ開発で注意しておくべきこと についてまとめる。以下を守るのはめんどくさいかもしれないが、なるべく守ったほうがよい。 Facebook へのアクセスは失敗するという前提で作る これ最重要 概要 追加権限の取得を必須にしない API アクセスは高い確率で失敗するので失敗した場合のことを常に考える これら二点の問題の解決には JavaScript でなるべく処理することが有効（かもしれない） 追加権限の取得まわりについては、こちらの長文が参考になります。あと当該記事にもコメントしましたが Facebook API の追加権限取得については、「追加権限をどのように使用するか」の説明を追加権限取得時に説明することが出来ます。あまり分かりやすい UI じゃないですが、書かないよりは書くほうがマシです。 また、上記記事は、いわゆる Web のエキスパートユーザーが執筆したもので、
text.ssig33.com - Amazon ウィッシュリスト経由で砂 1 トンを送る方法
Amazon ウィッシュリスト経由で砂 1 トンを送る方法 誕生日などで Amazon ウィッシュリストを公開する人がよくいます。そうした人達に日頃からの親愛の情を示す為に砂 1 トンを送ることが出来ます。 まずウィッシュリストを開き適当な商品を買い物カゴに追加します。 つぎにこちらの商品ページから砂 200kg を 5 個買い物カゴに追加します。これで砂 1 トンです。 レジへ行きます 発送先でギフト用に登録された住所を選択します そして発送すれば砂 1 トンが届きます ウィッシュリストから商品を買い物カゴにいれ、その後ウィッシュリストに無い商品を買い物カゴにいれると、ウィッシュリストに無かった商品もウィッシュリストの住所に送付出来て大変に便利です。
text.ssig33.com - 学生支援についての私見
学生支援についての私見 金がないけど勉強をしたいという弱味に付け込んで利息をつけて金を貸すという悪逆非道が平然と行なわれている日本の学生支援は明らかに腐敗している 社会の視点からすれば、高等教育は社会への投資なのに借金をさせるというのは明らかにおかしい 本人の視点からすれば、高等教育は自分への投資なので借金をするというのは明らかにおかしい 借金して株を買うと言いかえればいかにおかしいことか分かる 18 歳からの数年間しか大学に通えないみたいな思い込みもこうした歪みを生む原因になっているように思える 上記の問題を解決する為にマイクロファウンディングや金くれのような仕組みは有用かもしれない そうした仕組みを運用する為に経費を取ることは間違っていない 本当に正しい人道支援とは継続的な運営のために利益をとるものだ kiva だって経費とってるよね 経費 10% は高すぎるという意見はあるかもしれな
text.ssig33.com - 知人が退会出来ないことで有名な GREE を退職出来ない話。
知人が退会出来ないことで有名な GREE を退職出来ない話。 匿名ダイアリーにでも書こうと思ったが、文章および内容の責任を明らかにする為に名前を明らかにして書く。 知人がグリーを退職しようとしている。その人がグリーに入社した経緯を書くとその人を簡単に特定出来てしまう。しかし簡単に書くと、 100% 本意で入社したとは言えない（と僕は傍目に見て思う ）。 その知人は極めて優秀なインフラエンジニアだ。コードも書ける。得難い人材と言えると思う。 しかし一身上の都合でグリーを退職することとなり、その旨会社に伝えたところ「辞めるなど許さない」「君は四人分の働きをしていたのだから四人分の金を払え」などと極めて理不尽な、脅し としか受け取れないリプライを受けていた。 さらに退職にあたって「IT エンジニアとして今後一定期間働かないこと（要約）」極めて受け入れ難い契約を追加で要求された。 また退職の書面が
text.ssig33.com - Instagram の iOS アプリの UI と UI における「速さ」について考えてみた。
Instagram の iOS アプリの UI と UI における「速さ」について考えてみた。 Instagram の iOS アプリは出来がいいとは言い難いレスポンスであるが、 UI の速さについて一点優れた設計が為されている部分がある。それは写真の投稿のフローだ。 Instagram では 写真の撮影またはカメラロールからの選択 フィルタの適用 コメントやジオタグや連携先の記入 投稿 という順序で写真の投稿が行なわれるが、 2. が完了した時点で実はアップロードが開始されており、 3. でもたもたとコメントなどを記入している間にアップロードが終わってしまい、コメントを記入しおわるとさも一瞬でアップロードが終わったかのように見える。 つまり、通信が分散され非同期に行なうことで、ユーザーからの I/O 待ちとネットワークの I/O 待ちのタイミングを被せることでユーザーへのストレスを最小限
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
