フリマアプリFrilのリニューアルを題材に、iOS開発でのコードレビュー事例を紹介します

フリマアプリFrilのリニューアルを題材に、iOS開発でのコードレビュー事例を紹介します
今回は、Hubotのスクリプトが動く仕組みについて説明し、基本的な機能であるチャットでの受け答えを実装する方法を説明した後に、その他の機能について紹介します。 スクリプトの基本 Hubotがスクリプトを読み込み実行する仕組みを説明するために、“hello”と挨拶するとHubotが“hi”と返事する単純なスクリプトのサンプルを示します。 hello.coffee module.exports = (robot) -> robot.hear /hello/, (msg) -> msg.reply 'hi' このサンプルコードの一番外側を見ると、module.exportsに関数を代入しています。このmodule.exportsは、Node.jsでモジュールを作るための仕組みです。つまり、Hubotのスクリプトとは、引数を1つとる1つの関数を提供するNode.jsのモジュールということに
前回の(1)はこちらから。 プロジェクトでcronを利用する 筆者は普段ゲーム開発のサーバサイドを担当していますが、プロジェクトによってはバッチサーバのcrontabが100行を超えることもあります。イベント、ランキング処理、監視、集計、バックアップ、リカバリ処理などをしっかりやろうとすると、どうしてもそれくらいになってしまいます。 100行とはいかなくても、プロジェクトで使うcrontabの行数が膨らんでくると、サーバで直接crontabを編集することは管理上現実的ではありません。 crontabの記述とリポジトリ管理 では実際のプロジェクトでcrontabをどのように管理していけばよいのでしょうか。筆者は次の方針を立てています。 crontabの記述にゆるやかな規約を設け、リポジトリ管理する crontabの自動テストを行う crontabの反映方法をなるべく自動化する crontab
11. net/httpでWebサーバをたてる package main ! import ( "fmt" "net/http" "log" ) ! func hello(w http.ResponseWriter, r *http.Request) { //fmt.Fprintfでwに入るものがクライアントに出力される fmt.Fprintf(w, "Hello World!") } ! func main() { // アクセスのルーティングを設定する http.HandleFunc("/", hello) // portを指定して起動 err := http.ListenAndServe(":9090", nil) if err != nil { log.Fatal("ListenAndServe: ", err) } } 12. net/httpでWebサーバをたてる packag
7. 埋め込み type Hoge struct { N int } type Piyo struct { Hoge M int } func main() { piyo := &Piyo{Hoge{1}, 2} fmt.Println(piyo.N, piyo.M) fmt.Println(piyo.Hoge.N, piyo.M) } 8. 埋め込みを使ったインタフェースの実装 type Hoge interface { A() B() } type Fuga struct{ *Piyo } func (f *Fuga) A() { fmt.Println("Fuga A") } type Piyo struct{} func (p *Piyo) B() { fmt.Println("Piyo B") } func main() { var hoge Hoge = &Fuga{&Piyo
「新入社員のための大規模ゲーム開発入門 サーバサイド編」のスライドを公開しました matsuiです。 先週末の2014年6月13日~14日に、札幌でオープンソースカンファレンス 2014 Hokkaidoが行われました。 弊社インフィニットループもスポンサーとして、セミナーの発表を1コマと、ブースを出させていただきました。 その際に使用したスライド資料を公開しましたので、どうぞご覧下さい。 http://www.slideshare.net/infinite_loop/ss-35901898 おかげさまで満席でした。来て頂いた方ありがとうございます。 講師の佐々木、なぜか白衣です(理科の先生に憧れてるらしい)。 ブースはこのような感じです。 新作ゲームである「勇者と1000の魔王」と、Android用のタイムカードアプリである「かざしてシュキーン」を展示しました。 ツイート
前置き こちらの記事には2014/06/09現在、公式にはリリースされていないiOS8プレリリースドキュメントへのリンクが含まれます。iOS8にて新しく追加された内容には一切触れておらずAppleとのNDA規約にも違反するものではないという認識ですが、場合により予告なく削除する可能性があります。予めご了承ください。 本題 iOS8プレリリースドキュメントを眺めていて気になったのですが、ほとんどのCocoaのメソッドの引数に!がついています。例えばNSKeyValueObservingプロトコルのaddObserver:forKeyPath:options:context:メソッドのシグネチャは以下のようになっています。 func addObserver(_ anObserver: NSObject!, forKeyPath keyPath: String!, options options
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の3つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から: なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
2014年4月16日より2014年5月14日まで開催していたpaizaオンラインハッカソン(略してPOH![ポー!])Vol.2「女子大生とペアプロするだけの簡単なお仕事です!」で提出された最速コードはどのような高速化のアプローチでで生み出されたのでしょうか? POH Vol.2に登場した女子大生インターンプログラマの木野ちゃん(左のイラスト)にアルゴリズムを図解で教えるとしたら、どう教えるだろうか、という事で、今回は図解してみました。 今回は前回の最速コード発表レポート(【結果発表】女子大生プログラマの心を鷲掴みにした最強のコード8選)に引き続き、最速コードの裏側に迫ります。 ■高速化のアプローチ方法について 今回もPOH Vol.1 と同様に、POH Vol.2では計算量の改善による高速化を柱とするアプローチを想定して出題されました。基本は定数倍高速化によって想定解法よりも悪い計算量の
iOS6から導入された画面サイズや向きの違いにも、柔軟にレイアウトを作成することができる「Auto Layout」。 今回はこのAuto Layoutの使い方についてヤフーiOS 7エンジニア勉強会・運営チームの山口恭兵さんに解説いただきました。 by 馬場美由紀 (CodeIQ中の人) 今回はiOS6から導入されたAuto Layoutについて解説を行います。Auto Layoutを使うことで画面サイズや向きの違いにも、柔軟に対応できるレイアウトを作成することができます。今後発売されるiOS端末は画面サイズの拡大などが予想されており、Auto Layoutを使ったUI設計の重要さが増してくると考えられます。 制約(Constraint)ベースのレイアウト Auto Layoutの基本的な考えとなるのが、制約(Constraint)です。画面上に配置されたView要素に対して、「ある要素か
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 本投稿では、Android開発を行う中で、筆者が有益だと感じた情報やつまづきやすいポイントを、オフィシャルのソースへのリンクを中心にまとめています。これから開発を始めるチームや個人の方の参考にしていただければ幸いです。 開発の心得 Android Developers のドキュメントを読みましょう!英語が苦手な方は敬遠しがちかもしれませんが、参考になる情報がたくさんあります。ある程度開発経験を積むとスムーズに理解でき、新たな発見もあって読んでいて楽しいと思います。 https://developer.android.com/i
お待たせいたしました。久しぶりにRetty株式会社さんからご寄稿をいただきました。今回は、iOS開発での環境を切り変えるために便利な「スキーマとビルド設定」について、ご自身の体験を交えてご紹介いただいております。 ごあいさつ はじめまして、Retty株式会社の櫻井と申します。今回からiOSの開発で得たノウハウなどをブログ記事に書かせていただくこととなりました。今後、読者の皆さんのご意見なども取り入れつつ、何か役に立つような記事を書いていきたいと思っていますので、よろしくお願いします。 記事の内容としては、弊社で開発しているRettyというグルメサービスの開発の実例を通じて、教科書にはあまり載っていないTIPS、落とし穴等を紹介したいと思います。対象読者として複数人のチームでiOSアプリ開発をされている方を想定しています。 はじめに 背景と問題点 サービスとして提供し続けるWebアプリケーシ
はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル(=クラス)やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません! payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く