You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Treasure Data Tech Talk 201706 https://eventdots.jp/event/620321
「Objective-CがSwiftに置き換わる」っていうのがピンとこないのです。 それは、Swiftそのものがオープンソースになっても、あまり変わらないと思います。 以下はすごーくざっくりした知識で書いています。 Objective-Cの歴史 そもそもObjective-Cが何なのか、あまり知られていない気がします。 超ざっくり説明すると、AppleをやめたジョブズがApple OSの「次」として、当時としては革新的なオブジェクト指向OSだったNeXTSTEPを生み出しました。NeXTSTEPの存在は後の様々なOSに影響を与えました。OSXやiOS自体、NeXTSTEPの系譜です。 NeXTSTEPはオブジェクト指向のOS・開発環境・開発言語を統合し高い生産性を実現していました。その開発言語がObjective-Cでした。NSのプレフィクスの意味が、NeXTSTEPの略称というのは、比較
aial.shiroyagi.co.jp 自動ビルドとサーバ再起動が便利そう。 全然やってないけど Hello World と簡単な web サーバはプログラミングしてはみましたけど、それ以上出来なかった。 どうやったら、時間が作れるだろう。それを考えよう。
UNIXの基本をなすプロセスやシグナルなどを分かりやすく解説した技術ドキュメント「Process Book」がGitHubにて公開されています。 同ドキュメントは、プロセスの生成、プロセスとファイル入出力、ファイルディスクリプタ、preforkサーバーの作り方、ゾンビプロセスと孤児プロセス、シグナルとkill、プロセスグループとフォアグランドプロセスといった話題を解説するドキュメントで、GitHubのreleasesディレクトリにはPDF、epub形式のファイルも格納されています。 UNIX環境でプログラムを開発する際に役立つだけではなく、普通のユーザーとしてターミナルを使ってコマンド操作を行う際にも役に立ちそうな内容だと思います。
ここ数ヶ月にわたって、WebPayはAPIのエラーにまつわる変更を少しずつ行ってきました。 それに付随してドキュメントも拡張しましたが、変更の背景について十分に説明できていない部分がありました。 この記事では、最近のエラーに関連した変更の背景を紹介し、今後どのようにエラーをハンドルすべきか説明します。 記事の内容は執筆時点のものであり、今後同じようにエラーやAPIの変更を行うことがあります。 変更があっても記事の内容はその時点の内容を保持し、ウェブサイトのドキュメントのみ更新します。 必ずウェブサイトのドキュメントを合わせて参照し、手元で動作確認を行ってください。 エラーはなぜ起きるのか WebPayのAPIは、リクエストされた操作ができなかったときにエラーを返すように設計しています。 可能なかぎりエラーにならないような設計、実装を心がけていますが、エラーは絶対に避けられません。 例えば、
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに マーティンファウラーがmicroservicesの記事で、小さな役割をもったサービス群にアプリケーションを分割することを提案しています。 cookpadが、サービスをマイクロサービス群に分割していることの記事が注目を浴びており、最近急速にバズワード化しているように感じます。 バズワード化して、ポイントが損なわれる前にいくつかの注意点をまとめておきます。 1.インフラコストは基本的に増大する microservicesは、今まで単一のアプリケーションコードで行われていたことを複数のサービスサーバーに分割して管理・運営していくこと
シングルページアプリケーションやモバイルアプリなどの普及により、サーバサイドではJSONを出力するWeb APIの必要性が高くなってきています。みなさんはどのようにWeb APIを作っているでしょうか。 JSONはビュー RailsでJSON APIを定義する時、素のままでやろうとすると コントーラでto_jsonを呼んだり、モデルにas_jsonを定義したりすることになるかと思います。 モデルに書くとAPIによって出力内容を変えたい場合にとても苦労します。 API数が増えれば増えるほどモデルが複雑になっていきます。 APIレスポンスとしてのJSONはコントローラやモデルに書くべきでしょうか? ビューに書いた方が自然ではないでしょうか? これはRailsでの話ですが、Railsに限らず、フレームワークを使ってWeb APIを作るときに一般的にあてはまることだと思います。 変化に強い、再利用
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 追記 RailsでJS辛い問題に関しての結論:http://qiita.com/kaiinui@github/items/dad6180f1910c6a4bfd5 -- 近年、(1) Web/App両対応が増えてきたこと、(2) WebでもJSを多用するようになったこと、の二つがあり、以下の点でRailsが微妙になっている。 ViewのJavascriptがRailsから独立している API層のサポートが微妙 最初に書いておきますが、特に決定的な解決策もなく、辛いから今後解消されてほしいよね、な話です。 ViewのJavascriptが
今さらながら、Goをもう少し読み書きできるようになりたいな、と思い。 A Tour of Go を一通り読んで、 GitHub - mattn/twty: command-line twitter client written in golang go-oauth/examples/twitter at master · garyburd/go-oauth · GitHub などを参考にしつつ、写経というかんじで Twitterのtimelineを取得するものをまずは書いてみた。 package main import ( "encoding/json" "fmt" "github.com/garyburd/go-oauth/oauth" "github.com/typester/go-pit" "log" "net/http" "os/exec" "runtime" ) func mai
つい先だって知ったのですが、 Java のメソッドの throws 節では型変数が使えます。 8.4.6 Method throws / Java Language Specification これによって、投げる可能性のある例外の型が使い手側で変えられるようなメソッドを書くことができます。たとえば次のプログラムのように、例外の型と例外オブジェクトの生成を使い手にまかせる汎用の表明メソッドが書けます。 *1 class Checker { static <T extends Throwable> void check(boolean condition, Supplier<T> supplier) throws T { if (! condition) { throw supplier.get(); } } } class SomeException extends Exception {
本日は日本Javaユーザーグループ(JJUG)主催のクロスコミュニティカンファレンス2014春に参加してきました。今日の日記は、参加内容のまとめではなく、参加して得たことやそれをきっかけに考えたことなどをだらだらと書き連ねます。 Java SE 8では、forEach書いたら負け、for文禁止 日記のタイトルは、午前のセッション「K-1 詳説 Java SE 8 – CCC Edition」で出た話題です。手続き的なロジックを書いて、ネストが深く制御構造が複雑になってしまう人向けにはJava SE 8で導入されたラムダ式とStream APIを使って、内部イテレータと関数型プログラミングのエッセンスを取り入れた書き方をするといいよ、という話から出た言葉です。 実は昨日開催したJava読書会(「Java 8 Lambdas」を読む会)でも、「for文は禁止だ!」という話題が出てました。for
バージョン毎に異なる処理を吸収する 最近では Android 4.x 系の端末もかなり普及し、4.x 系のみサポートするようなアプリ開発も増えてきているように感じています。しかしながら、 2.x 系をサポートして欲しいとう要件もゼロではありません。 各バージョンの対応でよくある問題がバージョン毎にアクセスする API が異なるという点です。4.0 以降で追加された API を 2.x 系では呼ばないようにする (または独自で実装する) などといった対応が必要です。こういった場合によく使うのがバージョン毎に読み込むクラスを変えるという方法です。ということで、今回はその手順を解説したいと思います。ちなみにこの方法は Google I/O 2012 で発表されており、 Lazy Loading というデザインパターンをベースに生み出された手法です。Support Package も同じ手法を採用
関数型LT大会で「実社会の問題を解決する関数型言語」というタイトルで発表しました。 というのも、会社で「すごいHaskellたのしく学ぼう!」の輪読会をしていて、最初こそ10人以上の人が参加していたのだけど、章が進むごとにどんどん人が離脱していって、主催者としてはなんとか完走したいという思いがあったので、調べたのですが、 ヒアリングから、この二つの線がクロスしたときに、人は離脱するという知見が得られました。 ということで、Haskellに対して実用性を見出したいと思いながら半年を過ごしたのですが、実用的 = 仕事で使うということであれば、今の現場でHaskellに移行するのは現実的ではありません。 でも、Haskellには関数型言語のエッセンスが詰まっていて学びが多かったと思っていて、直接的には使っていないけど、概念として役立つことがあると思ったので、それを伝えるために今回文章に起こしまし
Java8 ではラムダ式やストリーム API に注目が集まってますが、何気にアノテーションに関しても機能拡張がされているようなので簡単な変更点や使い方を今夜試してみました。 ElementType の追加 TYPE_PARAMETER TYPE_USE 定義済みアノテーション @Repeatable アノテーション @FunctionalInterface アノテーション @Native アノテーション 目次 ラムダ式やストリーム API や新しい日時 API だけじゃない! Java8 のタイプ・アノテーションあの手この手 どんとこいタイプ・アノテーション! Checker Framework 導入あの手この手 ~without IDE 編~ どんとこいタイプ・アノテーション! IntelliJ IDE 独自のタイプ・アノテーション 参考 InfoQ 「Type Annotations
Cocoaの並列処理(GCDとNSOperation/NSOperationQueue)に関するまとめです。この記事ではいわゆる「スレッド」については扱いません。スレッドについては、前に記事を書いたのでそちらを参照してください。 Cocoaのマルチスレッドシステム - $ cat /var/log/shin スレッドによる並列処理からの脱却 スレッドは、歴史のある並列処理のための概念ですが、OSのカーネルの方にも密接に関わりがあるなど、抽象度は低めと言えます。 そこで、Cocoaでは、並列処理のための抽象度の高いインターフェースが提供されるようになりました。それがGCDとNSOperation/NSOperationQueueです。これらを使えば、スレッドを何個作成してタスクをどのように実行するか等の細かいことは、ランタイム側が全て決定してくれるので、ユーザは、並列処理したいタスクを定義し
Natasha Murashevがブログで、API Strategy and Practice Conferenceにおける、Michele Titolo (先月、「 Ruby RoguesメンバとiOSエンジニアのAPI議論」で紹介しました。)とEtsyのPaul Wrightの講演のポイントをまとめてくれています。 1) スピード ユーザは待ってくれない。300msで、リクエスト / レスポンスの処理 / ユーザに結果の表示をする。 2) RESTが常にベストとは限らない 以前のEtsyのAPIリソースはDBスキーマのミラーになっていた。クライアントがリスティングのリストを受け取ったら、ユーザがFavoritedに指定しているリスティングIDを取得するために、再度APIコールする必要があった。クライアントのAPIコールが増えると、クライアントのスピードが落ちる。また障害の可能性となるポ
こんにちは! アキバです。 ...T3ブログは初登場かもしれません。ハジメマシテ。 以後お見知りおきを。 いよいよ、2014年3月、Java8が正式公開されますね。 なんと言っても、Java8の注目機能はラムダ式ですので、ラムダ式や型推論に関する記事は多いです。 世の中で「Java8」と検索すると、皆さんいろいろと記事を書かれているので、おおよその事はこれで分かっちゃうような気がします。 が、 実は地味に便利なAPIが追加されていたりすることを最近知りました。 これはあまり触れられていないぞ、と。 というわけで、このエントリでは、あまり日本語で情報の無い、しかし地味に便利なAPIに実際に触れてみます。 大事なところなので2回強調して書いてみました。 今回は、前編として4つ紹介します。 ※APIの紹介と言いつつ、コードにはラムダ式を使ったコードが普通に出てるので、ご了承ください。 (むしろ、
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式(=コントローラ分割)でやってきて後悔したぼくが、(5年ぐらい前から)現在はどうやってAPIのバージョンを管理しているか?について紹介します。 基本原理としては、コピペが多発する根っこで分岐(=コントローラ分割)じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く