テストの数を減らそう！プリキュアで学ぶPICT - Qiita
ソフトウェアのテストはたいへんだなあ ソフトウェアのテスト、きちんとしてますか？最近は、スマートフォンやタブレットの普及に伴って、ユーザが使うデバイスの種類が多様化しています。 使われるOSやブラウザ、画面サイズの種類が増える中、プリキュア1の多様化も著しいですね。「プリキュアで学ぶワンライナーWebスクレイピング」で検証した通り、昨年までは43人、今年は「魔法つかいプリキュア」が加わることで、プリキュアの数は総勢45人になりました2。プリキュアはキャラクターによって専用デバイスを持ったり3、感情が昂ぶると常識を覆す事象を起こしたりするので、ITサービスを提供するエンジニアの方々は、ユーザ満足度向上のため、当然プリキュアがユーザになった場合も考慮した動作テストをされていると思います。 とはいえ、プラットフォームとプリキュアの組み合わせの数は、既にかなりの数です。全てのパターンを試すととても
はじめるiOS開発 - Qiita
はじめてのiOSアプリケーション開発がひと段落してきたので、基本的な開発方法を一通りまとめておきます。iOSに関する記事はxxViewの使い方、みたいな記事が多くて意外とチュートリアル的なものがなかったので、これから開発を始める方の参考になればと思います。 環境 Yosemite(10.10.1) Xcode(6.1.1) iOS8/Swiftにて開発 iOSアプリのアーキテクチャ 公式ドキュメントに詳しく記載されています。この文書は開発チュートリアル的なものではなく、こうした指針に沿って開発すべき・こういうポイントに気を配るべき、というような方針について書かれたものになっています。 iOSアプリケーション プログラミングガイド ここに書かれている中で重要な点は、下記点です。 iOSアプリケーションは、MVCの構成になっている アプリケーションは、フォアグラウンド/バックグラウンドの二種類
次世代の Rack や WSGI を考えてみる - Qiita
Rack や WSGI の代わりになる仕様を考えてみました (ライブラリ (rack.rb や wsgiref.py) のほうではなく、プロトコル仕様のほうです)。自分のアイデアを書き連ねただけなので、まとまってないかもしれませんがご了承ください。 なお本稿は、今後何度か改訂すると思います。ご意見があればご自由にコメントしてください。 【対象読者】Rack や WSGI に興味のある人 【必要な知識】Rack や WSGI の基礎知識 Rack と WSGI の概要 Ruby の Rack や Python の WSGI は、HTTP のリクエストとレスポンスを抽象化した仕様です。 たとえば Rack では: 引数として、リクエストを表す Hash オブジェクトを受け取り、 戻り値として、レスポンスのステータスコードとヘッダーとボディを返します。 class RackApp def cal
Swift/iosで開発するドメイン駆動~DDD(風)なモダンなアーキテクチャ - Qiita
はじめに Swiftでios開発をするときのアーキテクチャを考えてみました。 すでにいくつか良い記事があり、それらを参考に作るのもいいのですが、Web開発で慣れ親しんだDDDではどうなるのかと思い試しました。 結論からするとios開発では、DDDをそのままやるのではなく、あくまでDDDっぽくやるのが生産性が高そうです。 とても参考になるこちらの記事でもios開発に合ったMVVM風として実装しているし、私自身、原理主義的にやるよりもそのプロジェクトに合うように柔軟にやるのが好きです。 この記事では、以下のライブラリを使って、なるべく本質的な実装に専念できるようなコードにしたいと思います。 タイトルの「モダンな」は単にライブラリがモダンということです。 DDDに興味がなくてもこれらのライブラリの利用方法で多少なりとも参考になるかもしれません。 Bond Alamofire ObjectMapp
RxSwift勉強会＠Sansan まとめ - Qiita
RxSwift勉強会＠Sansan に、はじめて「ブログまとめ枠」として参加しましたので、だいぶ遅くなって申し訳ございませんがまとめたもの公開します。 以下すでに先行して他の方がまとめたもの http://matome.naver.jp/odai/2146067615056021001 https://blog.ppen.info/wp/?p=357 http://blog.mogmet.com/rxswift-sansan/ またRxSwiftの予習が足りず、誤りがある場合はよしなに編集リクエストいただけると嬉しいです RxSwiftをプロダクトに導入してみた話 @kazu0620 Eightに導入した話 「さわったことある人、挙手」で参加者のうち多くの人が手を挙げていた模様（席の都合上良く見えなかった） 宣言的に記述できる => 「こういうものが流れてきて、こういう処理をする」というこ
ソシャゲエンジニアの自分がコードレビュー時に重視する箇所33選 【随時追加】 - Qiita
コードレビューで土日に安寧を ソーシャルゲームは、ユーザアクセス集中と、それに伴うユーザデータ増加によって劇的に負荷が上がり、（主に土日に）サービスに影響を与えがちです。 問題があるコードは、たとえ負荷テストを行っても、作成したシナリオによっては見つけられない可能性もあります。 そういった見えない不安を払拭するという意味でも、コードレビューは重要だと思っています。 【ステキポイント】 ・ ソースを見ることにより、時限爆弾が土日に爆発するのを解除 ・ スキル共有によってメンバーがレベルアップすることにより、土日に爆発する時限爆弾の設置確率低下 まぁまとめると これに尽きます（4歳の息子談） 今は、gitのプルリクエストという強力なレビューツールもあり、敷居がかなり低くなったのでオススメです！ チェックするポイントは5つ コードレビューを行うにあたり、「どんなところをチェックすればいいのか分か
Markdownで書ける、よさげなWikiサーバーソフトまとめ - Qiita
※この記事は僕のブログ（最近始めました）のクローン記事です。 なんとなく、グループ内部用のWikiに最適なやつって無いのかなあと思ったのです。特にどのグループというわけじゃありませんが、ええ、なんとなく。 サーバー設置型のWikiソフトウェアというと国内で有名なのはPukiWikiでしょうか。設置も手軽で拡張性も高く、すでに慣れ親しんだWikiですが、最近では各方面がMarkdownを採用してそれに慣れ親しんでしまい、このブログもプラグインを入れてMarkdownで書いているぐらいなので、Markdownで書けるWikiを探していたのです。 必要要件はこんな感じ。 サーバー設置型 グループ内部向けのポータル的Wikiに適している Markdownで書ける 使い方が簡単 日本人に厳しくない デザインがナウい というわけで昨日から丸２日ぐらいぶっ通しで調べぬいた結果はっぴょー。どんどんぱふぱふ
「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
RailsでDDD - Qiita
別のアプローチによる実装の記事を書きました。 よろしければこちらもご覧ください。 「かんばん」を、DDDで設計しRailsで実装してみました。 kanban_core_extension 現時点では、最小限の機能しかありませんが ドメイン駆動設計をRailsで実装する際の一例として参考になれば幸いです。 アプリケーションの機能 開発するフィーチャ（タスク）をカードで表現し、進捗状況をかんばんボードで可視化する カードを次のフェーズ（進捗の区切り）に進める時にWIP制限をチェックする アーキテクチャスタイル Event SourcingなしのCQRSです。 変更（Command）の時だけドメインモデルを使います。 問い合わせ（Query）では、必要なデータをデータベースから直接取得します。 リポジトリからドメインモデルを取得することはしません。 取得したデータは構造化されたオブジェクトですが
INNER JOIN で eager loading - Qiita
INNER JOIN じゃないと不味いが joins だと N + 1 問題が発生してしまう場合にどうするかを調べた。 結論から言うと joins + preload または joins + eager_load を使うと INNER JOIN を使って結合した上で関連オブジェクトも即時フェッチしてくれる。 試したのは Rails 4.1.6。 joins + preload INNER JOIN で結合 クエリ複数回(指定した関連オブジェクトの分) 即時フェッチ > Post.joins(:comments).preload(:comments) Post Load (0.3ms) SELECT "posts".* FROM "posts" INNER JOIN "comments" ON "comments"."post_id" = "posts"."id" Comment Load
CORSまとめ - Qiita
今更ですが、CORS (Cross-Origin Resource Sharing)を色々試していたら、思っていた以上に色々パターンがあることに気づいたので、改めてその扱い方についてまとめてみました。 そもそも 現在のWebブラウザでは、あるWebサイトが持つ情報が別の悪意あるWebサイトに悪用されるのを防ぐために、Same-Origin Policy(日本語では同一生成元ポリシー)が適用されます。 例えば、あるWebサイト https://guiltysite.com をブラウザで表示している時に、このWebページからXMLHttpRequest(以下、XHR)やFetch APIで別のWebサイト https://innocentsite.net からHTTP(S)でデータを読み込もうとすると、エラーになる、というわけです。 しかし、アクセス元が悪意あるWebサイトならともかく、データ
Go Web Frameworks 比較 - Qiita
Go言語にはいろいろなWebフレームワークが存在して、はっきりとしたデファクトスタンダードが決まっていません。 しいて言えば標準パッケージの net/http がデファクトですが、世の中ではそこに機能不足を感じた人たちが多くのフレームワークを開発しています。 そこで、いくつかのフレームワークを取り上げて、簡単なベンチマークと、それぞれのフレームワークでのいわゆるHello Worldの書き方をまとめておきます。 これによって、フレームワーク選びの参考になればと思います。 対象 Bone Echo Gin Gocraft Goji Gorilla Kami Martini Revel、Beego、Kochaなど、見かけたが入れていないものがいくつかあります。コマンドでスケルトンを作るもの、net/http の Handler interface を満たさないものは除外しました。 追加してくれ
エンジニアのための「Sketch入門！」 1時間コース - Qiita
※「Sketch」はMac専用アプリです。Windows版はありません。 「演習ファイル＋動画＋演習付き」で記事を書いてます。 エンジニアの人から「Sketch使ってみたい」「日本語の記事が少ない」という声を聞いて、最近社内で勉強会しました。 Sketchについて日本語の記事を調べてみたところ、このレベルの記事はけっこうありました。 ただ、学びやすいか？といえばそうではないらしいので、少し工夫して学びやすいように書いてみました。 ハンズオン用などにご利用ください。 Sketchとは Sketchについて一応さらっと書いておきます。 ・アプリやWebのデザイン・UI設計などに使われるMac用アプリケーション IllustratorやFireworksのようなツールです。 ・$99 買いきり(2016/02 現在） 有料です。 ちなみにApp Storeでは買えなくなりました。ショバ代かかるか
俺的爆速iOSアプリ開発 サードパーティライブラリ集 - Qiita
通信系ライブラリ AFNetworking https://github.com/AFNetworking/AFNetworking ド定番中の定番のライブラリ!! レスポンスデータの処理やエラーハンドリングがブロック構文で書けるので通信周りを実装するときは必ずこれを使っています。 Alamofire これも定番中の定番の通信のライブラリ! Swiftで記述されているのでBriging-Headerを準備する必要なし! 個人的にはまだAFNetworkingのほうが使いやすいですがこれから使っていくつもりです GoldRaccon FTP通信を実装する際はこれを使っています。 クライアントからサーバーへのアップロードまたサーバーからのダウンロード処理を簡単に記述することができます。 SDWebImage UIImageViewに表示する画像(UIImage)をサーバーから取得＆表示するライ
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
はじめに この文書では、OAuth 2.0 + OpenID Connect サーバーをゼロから一人で実装した開発者（私）が、得られた知見について書いていきます。基本的には「実装時に考慮すべき点」を延々と述べることになります。 そのため、この文書は、「素早く OAuth 2.0 + OpenID Connect サーバーを立てる方法」を探している方が読む類のものではありません。そのような情報をお求めの方は、「Authlete を使って超高速で OAuth 2.0 & Web API サーバーを立てる」を参照してください。そちらには、「何もない状態から認可サーバーとリソースサーバーを立て、アクセストークンの発行を受けて Web API をたたいて結果を得る」という作業を、所要時間 5 ～ 10 分でおこなう方法が紹介されています。 文書のバイアスについて 私は、OAuth 2.0 + Ope
最近よく聞くQuorumは過半数(多数決)よりも一般的でパワフルな概念だった - Qiita
最近では珍しくもなくなった"Quorum"という言葉。Zookeeper, etcd, Serfといったクラスタ中でデータのレプリケーションを行ってくれるようなツールや、Cassandra, Riakといった分散データベース(NoSQL系)のようなツールにおいても、データの複製に一貫性を持たせる仕組みとしてよく聞かれます。 しかしながら、多くのスライドやWebの記事を読んでも、"Quorum"という語が意味するところは要するに「過半数ノードによる多数決」というような説明が多いように感じていました。 にも関わらず、"Quorum"と呼ばれているのはなぜか？そんな疑問を持っていたので、この機会に調べてみました。 そうしたら、"Quorum"は過半数/多数決という概念を一般化した非常に抽象でパワフルな概念だということがわかりましたのでここにまとめておきたいと思います。 分散システムにおけるデータ
楽ができるGolangのライブラリ達 - Qiita
ライブラリ探すなら基本awesome go見とけばいいけど、いろいろ楽するためという観点で、思い出した順に適当に追記していく。気が向いたらサンプルも書く gojson https://github.com/ChimeraCoder/gojson jsonのデータを渡すとそれに対応するstructを生成してくれる。JSON APIを利用するときに楽ができる。既存APIのリプレイスをGoでやるときとかも良い。 goquery https://github.com/PuerkitoBio/goquery JQueryっぽくhtmlをパースしたり検索したりして楽ができる。自前でhtmlのパースなんか書いてられない。 goreq https://github.com/franela/goreq net/httpパッケージで、httpリクエストを飛ばすのは結構面倒だったりいろんな書き方があったりしてヘ
MVVMをベースに複雑な振る舞いをしっかり把握できるアプリ開発 - Qiita
TL;DR 複雑になりがちな構造やコードをシンプルで把握しやすいコードで記述したい MVVMを用いて責務を明確にし関心事を分離した構造にする ViewDataBindingとFRPを用いて時間とともに変化するデータやステートに伴う処理を宣言的に記述し、Viewとデータの動的な変化を相互的に連動させる 上記をSwiftとそのパラダイムを活かしたライブラリ（SwiftBond)を中心に実現する はじめに Swiftで新規のアプリを開発することになり、MVVM、FRP、ViewDataBindingの要素技術を活用して開発を行いました。設計やライブラリ選定は2015年5月に行っており実装環境はXcode6.4,Swift1.2になります。Swift2.0以上になるとSwift系ライブラリも大きくインタフェースを変更しているため、ここで紹介しているサンプルコードもそのままでは動作しないことをご留意
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術者向け Ethereumの基礎知識 (イーサリアム、エセリウム) - Qiita
