Androidの非同期通信処理 - appfountain's blog
Android書いてますか？ これなに 2013年10月13日あたりに流行ってそうな，Android非同期通信処理方法のススメを，Android非同期通信何それ？な人に向けて簡単に情報をまとめる Android普段全く書いてないけどここ数日少し調べた自分が知識の共有のために残す また将来的には流行りは変わるので今しか使えない 転用ばかりで申し訳ない感じなので日常的にAndroid開発してる方はお帰りください 最低限動かすための，すぐに動かすための情報しか書いてないので良くない情報もある Androidでの非同期通信処理 サーバとの通信を行う際に記述しなければならない処理．Androidではメインスレッド上で通信を行う事が出来ないため，サーバとの通信を行うには非同期スレッドを立てなければならない． 昔の処理 Android2.x時代はメインスレッドに直接処理を書けたらしい 非同期処理にしなけ
REST APIのテストをFrisbyで自動化する
どうも、中本（特に冷やし五目味噌タンメン+バター）にハマっている高橋です！ 最近のアプリケーション開発といえば、フロントエンドはサーバサイドが準備したAPI経由でデータを取得したり保存したりという構成が人気のようです。そこで「API、ちゃんと動いてるんかなぁ？」というテストを書いて、実際にリクエスト＆レスポンスで検証してみようと思います。 今回テスティングフレームワークとして使用する Frisby（フリスビー） は簡単に書けて高速に動作するというのが持ち味の REST API のテスティングフレームワークです。投げて返ってくるFrisbeeと掛けているのでしょうか？これドヤ顔で言われるとちょっと腹立ちますが、こういうネーミングセンスには関心させられます。笑 ◯インストール 今回は「frisbytest」というディレクトリ内で作業をしていきたいと思います。 コンソールを起動したら以下のコマン
「Blue-Green Deployment」とは何か、マーチン・ファウラー氏の解説
クラウドを活用した本番システムのデプロイ手法の1つに「Blue-Green Deployment」がある。Blue-Green Deploymentの目的とそのメリットを、マーチン・ファウラー氏の解説から紹介する。 1つ前の記事で紹介した、チャド・ファウラー氏によるImmutable Infrastructureの記事「Immutable Infrastructure（イミュータブルインフラストラクチャ）と捨ててしまえるコンポーネント」では、デプロイをより安心して行うために、サーバの内容を変更する際には既存のサーバに手を加えるのではなく、新規に作り直して切り替える、という方法を提案しています。これがサーバの不変性、すなわちImmutable Infrastructureにつながるわけです。 これから紹介するマーチン・ファウラー氏の記事「BlueGreenDeployment」は、Immut
The Power of Python
Understanding the Internet. Parsing Big Data Learn about the power of Python: what the language program is, the capabilities, and resources available on Python. About What is Python? Simply put, Python is a programming language. Python is considered a very sraightforward language due to its syntax and readability. In addition, the progam has a wealth of support for packages that allow a large amou
確率概念について説明する（第1回）：説明全体の構成 --- 確率概念の「規格」と「意味」 - Take a Risk：林岳彦の研究メモ
どもです。林岳彦です。白泉社文庫の大島弓子作品から一冊選ぶなら『つるばらつるばら』だと思います*1。 さて。 今回からは長期のシリーズとして、「確率概念とは何か」についてガッツリと説明していきたいと思います。今回は、その第一回目として、「本シリーズにおける説明の全体構成（予定）」について書いていきます。 本シリーズでは確率概念の「規格」と「意味」について書いていきます ざっくり言いますと、本シリーズの目的は「確率って何すか？」という問いに答えることです。 で、「確率って何すか？」という問いには以下の： 確率概念とはどのような「規格」をもった概念なのか？ 確率の値（たとえば”0.5"）は実際問題としてどういう内実的な「意味」を示しているのか？ という方向性のちがう2つの問いが含まれていたりします。 前者の(1)については、たとえば、「確率は黄色である」「確率は150km/hである」という言い
Dockerfile Best Practices - take 2
Much has changed since my first Dockerfile best practices post. I'll leave the original post up for posterity and this post will include what has change and what you should do now. 1: Don't boot init Containers model processes not machines. Even if you think that you need to do this you are probably wrong. Next... 2: Trusted builds Even if you don't like the name it is an awesome feature. I have m
新しいことをやる為の負荷と学習コストと迷子であることの自覚 - mizchi's blog
読みにくい日記です。 一応今の会社はRubyやRailsの会社ってことで通ってると思うんだけど、自分はほとんどRails触ったことなかったので、何かと色々やる必要が出てくる。 今はJavaScriptのフロントのタスクがあんまりなくてRailsやった方がいい感じで、じゃあ勉強がてらやるかって突っ込んだらちょっとウゥムって感じになった。 問題 勉強側に振ってしまいすぎたのもあるんだけど、かなり生産性低かった自覚がある。結局1週間やって出せたのがやりかけのPullRequest一件で、しかもwork in progress で残りお願いします… みたいな感じになってしまった。 で、今回新しいことをやるにあたって問題になったのは、次の点だと思った。 新しい登場人物の多さによる認知負荷の高さ パフォーマンス要件の厳しさ 最初からプロダクション前提の品質要求 ペアプロしてくれる人の確保 実は今の会社
俺がGitHubでスターを付けたリポジトリ一覧 - Qiita
GitHubを彷徨っていてよくあるのが、ググったりRuby Toolboxとかで見つけて「これイイじゃんよ！」と思ったら既にスター済み、という奴。 一回、自分がどんなリポジトリにスター付けたのか整理しつつ、更新止まってたり古くなったやつを削除していこうと思う。 それぞれの説明は超適当。基本的にいつか使おう的な感じでスターを付けているので、あんまり使ったことあるのが無い。 そもそも良く使うものにはスター付けてないこと多いし…。 大体rubygemsで一部JSのライブラリ、少しvimとScalaって感じ。 思い返したようにスター付けてたので、時期がバラバラだけど、基本的に下に行く程付けた時期が新しい。 リポジトリ 説明
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
