CakePHP2+PostgreSQLでGeoデータを簡単に扱う!? - kaz29
@tkengoさんから引き続き CakePHP Advent Calendar 1４日目の記事です。 深く考えず参加申し込みをしたらダブルヘッダーになってしまいヒーヒー言っているわたなべです(^^; この記事はCakePHP2系の記事です。 明日にはこんなイベントも開催されるようで、最近は位置情報を扱う機会も多いのではないかと思います。 先月くらいに位置情報に関して色々試していて、CakePHPから扱う場合にいつもと同じように扱いたいなぁということでPostgres Datasourceを拡張してみたので解説したいと思います。 PostgreSQLで扱える位置情報の種類 PostgreSQLで扱える位置情報関連のデータ型には以下のようなものがあります。 型名 表現 point 平面における座標点 line 無限の直線 lseg 有限の線分 box 矩形 path 閉経路 path 開経路
CocoaPodsで使えそうなPodの概要と（あれば）イメージの一覧 - Qiita
追加がありましたら「編集リクエスト」をお願いします ユーザーにレビューをうながす機能 Appirater (0.0.1, 0.0.2) A utility that reminds your iPhone app's users to review the app. Homepage: http://arashpayan.com/blog/2009/09/07/presenting-appirater/ Source: https://github.com/mk/appirater.git テーブルをページのようにめくれる ARTableViewPager (1.0.0) The ARTableViewPager is an iOS component for horizontal table view scrolling/paging. Homepage: https://github.
composer install をどこで実行するか
最近の PHPer が集まれば、一度は話題に上がるのが、この composer install をどこで実行するのか問題。 これまで聞いた話をまとめると、大きく分けて、以下の２パターンになります。どちらの方法を取っているか教えて下さい 😀 0. 前提 前提ですが、以下のような方法で、Composer 関連のファイルは管理しているとします。おそらく多くはこのような形になっていると思います。 PHP コードは、Git などの VCS で管理する。 composer.json, composer.lock は、VCS で管理する。 composer.phar, vendor/ は、VCS で管理しない。 また、今回対象としているのはアプリケーションで、Packagist に登録して、配布するようなフレームワークやライブラリは対象外です。 1. 本番サーバで実行 本番PHPサーバ上で compo
これからObjective-Cを書くプログラマへ - Qiita
Objective-Cを愛してください Objective-CはCの拡張です。 Cでできることはすべてできるし、Cでできないこと（ 恐らく計算機では不可能なこと ）はすべてできません。 Objective-CはJavaよりも年上です。 「Objective-CってJavaに似てるね」と言われると、Objective-Cを愛するものとしては少し悲しい気分になります。 歴史的にはJavaがObjective-Cの影響を受けています。 メッセージングに使うブラケット[]はObjective-Cのチャームポイントです。 Objective-CがSmalltalkの子であると証明するための、とってもチャーミングな形質です。間違っても「キモい」なんて言わないであげてください。 関数とメソッドを見た目で区別できるという利点もあります。 メソッド名が長いのはメソッド自身がドキュメントの役割を果たしているか
俺史上最強のiptablesをさらす - Qiita
#!/bin/bash ########################################################### # このスクリプトの特徴 # # 受信・通過については基本的に破棄し、ホワイトリストで許可するものを指定する。 # 送信については基本的に許可する。ただし、サーバが踏み台になり外部のサーバに迷惑をかける可能性があるので、 # 心配な場合は、送信も受信同様に基本破棄・ホワイトリストで許可するように書き換えると良い。 ########################################################### ########################################################### # 用語の統一 # わかりやすさのためルールとコメントの用語を以下に統一する # ACCEPT :
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CakePHP で位置情報をgeometry型で保存する (試してないけど多分動く)
Reduce Data Usage When Web Browsing on iPhone with Chrome
How to Change a Game Center Nickname from the iPhone & iPad