tetsuwo

[tetsuwo]

CocoaPods: The dependency `Xxxxxxxxxx (= x.x)` is not used in any concrete target.

CocoaPods 0.39 以下がサポート切れたので 1.1 系にアップグレードしたら、このようなエラーに見舞われた。

$ bundle exec pod install Re-creating CocoaPods due to major version update. Analyzing dependencies [!] The dependency `AFNetworking (= x.x.x)` is not used in any concrete target. The dependency `Xxxxxxxxxx (= x.x)` is not used in any concrete target. . . . .

エラーの意味通り、使ってないよー。

Podfile には案の定 xcodeproj でプロジェクト名を記載していた。

platform :ios, '10.0' project 'Xxxxxxx.xcodeproj' pod 'AFNetworking', 'x.x.x' pod 'Xxxxxxx', 'x.x'

以下のように変更。

platform :ios, '10.0' project 'Xxxxxxx.xcodeproj' target 'Xxxxxx' do pod 'AFNetworking', 'x.x.x' pod 'Xxxxxxx', 'x.x' end

[tetsuwo]

CocoaPods: `xcodeproj` was renamed to `project`. Please update your Podfile accordingly.

CocoaPods 0.39 以下がサポート切れたので 1.1 系にアップグレードしたら、このようなエラーに見舞われた。

$ bundle exec pod install Re-creating CocoaPods due to major version update. Analyzing dependencies [!] The dependency `AFNetworking (= x.x.x)` is not used in any concrete target. The dependency `Xxxxxxxxxx (= x.x)` is not used in any concrete target. . . . . [!] `xcodeproj` was renamed to `project`. Please update your Podfile accordingly.

エラーの意味通り、 xcodeproj は project にリネームされましたよー。Podfile を更新してねー。

Podfile には案の定 xcodeproj でプロジェクト名を記載していた。

platform :ios, '10.0' xcodeproj 'Xxxxxxx.xcodeproj'

以下のように変更。

platform :ios, '10.0' project 'Xxxxxxx.xcodeproj'

[tetsuwo]

Android: 'android' is deprecated; use 'com.android.application' instead

Android Studio 上で build.gradle の整理をしているときに気付いたのですが、apply plugin: 'android' に打ち消し線が入るようになっていました。

こんなのです↓

'android' is deprecated; use 'com.android.application' instread This detector looks for deprecated Gradle constructs which currently work but will likely stop working in a future update.

Android Studio のバージョンいくつから付くようになったのかは分かりませんが、非推奨と言われてしまったら変えざるを得ない。

// build.gradle apply plugin: 'android' ↓ apply plugin: 'com.android.application'

この修正を入れた上で、build.gradle の android ブロックが悲鳴を上げなければ大丈夫。

[tetsuwo]

Android: java.util.zip.ZipException: duplicate entry: xx/xx/Xxxxx.class

Android アプリの Gradle ビルドを走らせたときに下記のエラーに遭遇。

java.util.zip.ZipException: duplicate entry: xx/xx/Xxxxx.class

エラーからすると Xxxx.class に重複したエントリーがあるということを教えてくれているようです。

なるほどなるほどと、該当の箇所をみてみると確かにバージョン違いの同名 jar ファイルがありました。

同名 jar ファイルを一つだけにしてビルドしたらビルド成功。

そういえば、とある SDK をアップグレードする際に、とりあえず jar ファイルだけ置いておいて放置したやつが影響していました。。。

凡ミス。

[tetsuwo]

Android: com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command '~~~/jdk1.7.0_75.jdk/Contents/Home/bin/java'' finished with non-zero exit value 1

Android アプリの開発をしているときに Android Studio を 2.1.0 から 2.2.0 にアップグレードした際に、Gradle ビルドで下記のエラーが発生しました。

com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command '~~~/jdk1.7.0_~~.jdk/Contents/Home/bin/java'' finished with non-zero exit value 1

JDK 1.7 が何かやっちゃってるのかと思って、このプロジェクトで JDK のバージョンをしている箇所を探しました。

どうやら .iml（モジュール定義ファイル）で指定しているようで、そこには XML で下記のように定義されていました。

<orderEntry type="jdk" jdkName="1.7" jdkType="JavaSDK" />

上位設定を受け継ぐように書き換えます。

<orderEntry type="inheritedJdk" />

その上で JDK 1.8 をインストール。

すると無事ビルドが通りました。

なぜ JDK 1.7 だと駄目なのかは分からず終い...。

[tetsuwo]

Android: Unsupported method: AndroidProject.getPluginGeneration().

Android アプリの開発をしているときに Android Studio を 2.1.0 から 2.2.0 にアップグレードした際に、Gradle ビルドで下記のエラーが発生しました。

Unsupported method: AndroidProject.getPluginGeneration(). The version of Gradle you connect to does not support that method. To resolve the problem you can change/upgrade the target version of Gradle you connect to. Alternatively, you can ignore this exception and read other information from the model

使っている Gradle のバージョンがメソッド AndroidProject.getPluginGeneration() をサポートしていないというエラーです。

本当なら Gradle をアップグレードしたいところですが、諸々あって別の方法を探しました。

どうやら調べてみると Android Studio 2.2 から自動で有効になった？ Instant Run が影響しているようでした。

Instant Run は、初回ビルド以降、新規に APK をビルドすることなく、アプリの更新内容をプッシュできるため、変更点を素早く確認できるようになる機能です。

この機能を無効にするには設定からおこないます。

Windows/Linux の場合

File

Settings

Build, Execution, Deployment

Instant Run

Enable Instant Run to hot swap code/resource changes on deploy (default enabled) のチェックを外す

Mac OS X の場合

Android Studio

Preferences

Build, Execution, Deployment

Instant Run

Enable Instant Run to hot swap code/resource changes on deploy (default enabled) のチェックを外す

これでエラーが発生しなくなりました。

しかし、早く Instant Run を導入したいですね。。。

参考 URL

Android Studio Release Notes | Android Studio

Google Developers Japan: Android Studio 2.2

アプリをビルドして実行する | Android Studio

[tetsuwo]

Swift, Objective-C: NSURLRequestCachePolicy の種類

こっち（AFHTTPRequestOperationManager で結果キャッシュを無効にする） でも触れたのですが、 NSURLRequestCachePolicy の種類だけを抜き出しておいたほうが備忘録的にも探しやすいので残しておく。

値 説明 NSURLRequestUseProtocolCachePolicy 基本的にはプロトコルのキャッシュ方針に従う。でも何故かキャッシュされっ放しのケースがある。プロパティに何も指定がなかった場合にデフォルトで設定される。 NSURLRequestReloadIgnoringLocalCacheData 必ずサーバー側にリクエストを送る。サーバー側のキャッシュコントロールには従う。 NSURLRequestReloadIgnoringLocalAndRemoteCacheData クライアント側、サーバー側ともにキャッシュを無視する。ただしサーバー側でプロキシーキャッシュしている場合はその限りではない。 NSURLRequestReturnCacheDataElseLoad クライアント側にキャッシュがあれば必ずキャッシュデータを返す。ちなみに未実装...。 NSURLRequestReloadRevalidatingCacheData サーバー側にキャッシュデータの妥当性を問い合わせた上でキャッシュを使うくさい。ちなみにこれも未実装...orz

2016 年 10 月時点での情報です。 ご参考までに。

[tetsuwo]

Objective-C: AFHTTPRequestOperationManager で結果キャッシュを無効にする

とある iOS アプリから Web API と HTTP を喋るのに AFNetworking（2系）を利用しています。

AFNetworking というよりかは NSURLRequest の仕様だと思うのですが、下記のようなコードで、一度 HTTP リクエストを送った URL に対して 2 回目のリクエストを送るとクライアント側のキャッシュからデータ（レスポンス）を読むようです。 （サーバー側のレスポンスヘッダーが悪いような感じではなかった、、、） このような場合、特に Web API などはクライアント依存になってしまう状態だと何かと不便です。

下記コードが問題のところ。 いたって普通の HTTP 通信するためのコードです。

AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager]; [manager GET: URL parameters: PARAMS success: ^(AFHTTPRequestOperation *operation, id responseObject) { // anything } failure: ^(AFHTTPRequestOperation *operation, NSError *error) { // anything } ];

どうにか解消できないかと調べていると、HTTP リクエストを送る際にキャッシュポリシーのオプションを指定できることがわかりました。 （公式ドキュメント - NSURLRequestCachePolicy - Foundation | Apple Developer Documentation）

キャッシュポリシーは列挙型 NSURLRequestCachePolicy で、デフォルトが HTTP に従うようです。

下記コードが改善版。 [manager.requestSerializer setCachePolicy: NSURLRequestReloadIgnoringLocalCacheData] が改善箇所です。

AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager]; [manager.requestSerializer setCachePolicy: NSURLRequestReloadIgnoringLocalCacheData] [manager GET: URL parameters: PARAMS success: ^(AFHTTPRequestOperation *operation, id responseObject) { // anything } failure: ^(AFHTTPRequestOperation *operation, NSError *error) { // anything } ];

なるほどなるほど。

他にどんなキャッシュポリシーがあるか調べました。

NSURLRequestCachePolicy (Objective-C) の種類

値 説明 NSURLRequestUseProtocolCachePolicy 基本的にはプロトコルのキャッシュ方針に従う。でも何故かキャッシュされっ放しのケースがある。プロパティに何も指定がなかった場合にデフォルトで設定される。 NSURLRequestReloadIgnoringLocalCacheData 必ずサーバー側にリクエストを送る。サーバー側のキャッシュコントロールには従う。 NSURLRequestReloadIgnoringLocalAndRemoteCacheData クライアント側、サーバー側ともにキャッシュを無視する。ただしサーバー側でプロキシーキャッシュしている場合はその限りではない。 NSURLRequestReturnCacheDataElseLoad クライアント側にキャッシュがあれば必ずキャッシュデータを返す。ちなみに未実装...。 NSURLRequestReloadRevalidatingCacheData サーバー側にキャッシュデータの妥当性を問い合わせた上でキャッシュを使うくさい。ちなみにこれも未実装...orz

いまさら Objective-C ですが、書き方に癖があるだけで、今のところ自然に入り込めている感じ。

参考 URL

Enumeration - NSURLRequestCachePolicy

ios - AFNetworking - do not cache response - Stack Overflow

EZ-NET: NSURLRequest でキャッシュを無視して再読み込みする : Objective-C プログラミング

[tetsuwo]

Xcode: Base SDK と Deployment Target の違い

はじめてまとも（仕事として）に iOS アプリの引き継ぎ開発をするにあたり、後方互換を意識しなければならず、Xcode プロジェクトのビルド設定にある Base SDK と Deployment Target の理解が曖昧だったので、公式ドキュメントを漁って調べてみました。

下記、公式ドキュメントをオレオレ和訳したものになります。

ご参考まで。

Xcode プロジェクトで特定の SDK を使うには、プロジェクトのビルド設定で 2 つの選択をおこないます。 これらの選択はプロジェクトで使う OS 機能を決定します。

Deployment Target はお使いのソフトウェア���実行できる最も古い OS バージョンを識別する設定です。デフォルトは Base SDK のバージョン以降に対応する OS のバージョンと同じです。 この設定のための Xcode ビルド変数名は MACOSX_DEPLOYMENT_TARGET (OS X Deployment Target) と IPHONEOS_DEPLOYMENT_TARGET (iOS Deployment Target) です。 Deployment Target 以前の OS に組み込まれている機能は無条件に利用できます。

Base SDK は Base SDK に対応するバージョン以前の OS に組み込まれている機能が利用できます。 この設定のための Xcode ビルド設定名は SDKROOT (Base SDK) です。 Deployment Target のバージョン以降、Base SDK に対応する OS バージョンまでの機能は、開発したアプリで利用できます。 ただし、新しい機能が使えるかどうかチェックする必要があります（「iOS 弱リンククラスの使い方」、「弱リンクメソッド、関数、シンボルの使い方」を参照）

以下、原文。

Base SDK and Deployment Target Settings

To use a particular SDK for an Xcode project, make two selections in your project's build settings. These choices determine which operating system features your project can use, as follows:

Choose a deployment target. This identifies the earliest OS version on which your software can run. By default, Xcode sets this to the version of the OS corresponding to the base SDK version and later. The Xcode build variable names for this setting are MACOSX_DEPLOYMENT_TARGET (OS X Deployment Target) and IPHONEOS_DEPLOYMENT_TARGET (iOS Deployment Target). You can unconditionally use features from OS versions up to and including your deployment target setting.

Choose a base SDK. Your software can use features available in OS versions up to and including the one corresponding to the base SDK. By default, Xcode sets this to the newest OS supported by Xcode. The Xcode build setting name for this parameter is SDKROOT (Base SDK). You can use features from system versions later than the deployment target—up to and including the OS version you've selected as your base SDK—but you must check for the availability of new features, as described in Using Weakly Linked Classes in iOS and Using Weakly Linked Methods and Functions.

For possible values and more information about build settings in Xcode, see Building for Multiple Releases of an Operating System in Xcode Project Management Guide, Xcode Build Setting Reference and Running Applications in iOS Development Guide.

When you build your application, your deployment target is reflected in the MinimumOSVersion entry in the application's Info.plist file. For iOS apps, the MinimumOSVersion entry is used by the App Store to indicate the iOS release requirement.

Figure 2-1 shows a timeline that explains the relationship between deployment target and base SDK.

The figure describes a project with a deployment target of OS X v10.4 and a base SDK of OS X v10.6. (The version numbers in the figure represent all releases of that version, including system updates.)

In this example, the software can freely use any features from OS X v10.0 through the newest update of version 10.4. It can conditionally take advantage of features from OS X v10.5 and 10.6, after ensuring that each such feature is available.

The effects of these settings at compile time and run time are as follows. If your code uses a symbol:

Not defined in the base SDK (for example, a symbol from a newer OS), you get a compile-time error. Defined in the base SDK but marked as deprecated, you get a compile-time warning. Defined in the deployment target, your code links and builds normally. At run time: On a system running an OS earlier than the deployment target, your code may fail to load if you use symbols unavailable in that OS. On a system running an OS equal to or later than the deployment target, your code has null pointers for symbols not available in that OS. Prepare your code for this as described in Using Weakly Linked Methods and Functions and Using Weakly Linked Classes in iOS.

Note: OS X v10.6 does not support using iOS Simulator SDKs prior to version 3.0. In addition, when building with Simulator SDKs, the binary runs only on the same operating system version as the base SDK, not on earlier or later versions.

Always check to see if you are using deprecated APIs; though still available, deprecated APIs are not guaranteed to be available in the future. The compiler warns you about the presence of deprecated APIs in your code, as described in Finding Instances of Deprecated API Usage.

When you change the base SDK setting, in addition to changing the headers and stub libraries your code builds against, Xcode adjusts the behavior of other features appropriately. For example, symbol lookup, code completion, and header file opening are based on the headers in the base SDK, rather than those of the currently running OS (if the two differ). Similarly, the Xcode Quick Help affinity mechanism ensures that documentation lookup uses the doc set corresponding to the base SDK.

In addition to setting the base SDK and deployment target for your project as a whole, you can set these values individually for each build target. Target settings override project settings. (However, some Xcode features that attempt to correlate with the base SDK setting, such as symbol definition and documentation lookup, may work differently.)

参考 URL

Configuring a Project for SDK-Based Development

[tetsuwo]

Zabbix: Memcached の Agent スクリプトとテンプレートを作りました

ちょっと前に Zabbix の Memcached テンプレートを Python で作りましたが、ブログでの紹介を失念していたので、これを機に...。

公開する程のものでもありませんが、Python と Zabbix の Agent 経由の監視を覚えるために勉強がてら作りました。

tetsuwo/zabbix-memcached-template

仕事でも Memcached の監視に利用しているので運用実績はまあまあ��す。

使い方は Zabbix の設定に慣れていればいたって簡単

zabbix-memcached-template の README に書いてある通りです。

監視クライアント側に Zabbix Agentd 用の設定ファイルを設置します。

$ curl https://raw.githubusercontent.com/tetsuwo/zabbix-memcached-template/master/src/zabbix_agentd.d/userparameter_memcached.conf > /etc/zabbix/zabbix_agentd.d/userparameter_memcached.conf

次にスクリプトを配置し、実行権限を与えておきます。

$ curl https://raw.githubusercontent.com/tetsuwo/zabbix-memcached-template/master/src/bin/memcached-stat.py > /etc/zabbix/bin/memcached-stat.py $ sudo chown zabbix:zabbix /etc/zabbix/bin/memcached-stat.py $ sudo chmod +x /etc/zabbix/bin/memcached-stat.py

あとは Zabbix Agentd を再起動するだけ。

$ sudo service zabbix-agent restart

テストでデータが正しく取得できているか確かめてみましょう。

$ zabbix_agentd -t memcached.stat[--host,localhost,--port,11211,--item,version] memcached.stat[--host,localhost,--port,11211,--item,version] [t|1.4.13]

Zabbix ホストのマクロも設定できます。

{$MEMCACHED_HOST} ... Agent から参照する Memcached のホスト {$MEMCACHED_PORT} ... Agent から参照する Memcached のポート番号

ぜひ使ってみてください。

ただ、懸念点があるとしたら Zabbix Agent なので監視項目を１つ１つ Agent 経由でデータを集めるのは、何か効率が悪くみえて嫌です。

Trapper で実装すると監視クライアント側から監視サーバーに監視項目のデータを一度に送れるからパフォーマンスがシビアな場合は、Trapper で作りなおしたほうがよいかも。

[tetsuwo]

Jekyll: The 'pygments' configuration option has been renamed to 'highlighter'

ひさしぶりに Jekyll を起動したら、怒られてることに気付いた。

$ jekyll serve Configuration file: /path/to/project/_config.yml Deprecation: Auto-regeneration can no longer be set from your configuration file(s). Use the --[no-]watch/-w command-line option instead. Deprecation: The 'pygments' configuration option has been renamed to 'highlighter'. Please update your config file accordingly. The allowed values are 'rouge', 'pygments' or null. Source: source Destination: public Generating... done. Auto-regeneration: enabled for 'source' Configuration file: /path/to/project/_config.yml Deprecation: Auto-regeneration can no longer be set from your configuration file(s). Use the --[no-]watch/-w command-line option instead. Deprecation: The 'pygments' configuration option has been renamed to 'highlighter'. Please update your config file accordingly. The allowed values are 'rouge', 'pygments' or null. Server address: http://0.0.0.0:4000/ Server running... press ctrl-c to stop.

怒られている内容は以下のようです。

自動生成はもはや設定ファイルからやらなくていいんだよ。コマンドラインのオプションを代わりに使おうね。

pygments 設定オプションは highlighter に名前が変わったよ。許容してる値は rouge か pygments 、 null だよ。

_config.yml

source: source destination: public timezone: Asia/Tokyo encoding: utf-8 -auto: true -pygments: true +highlighter: pygments permalink: /news/:year:month:day/:title.html url: http://test

これでエラーなくスンナリ。

[tetsuwo]

私的なこと：ぐっじょぶ

この間、ご飯を食べているとき、長女に「パパ、なんでグッジョブしながら食べてるの？『うまい』ってことなの？」と言われ、親指を立てながら食べる癖に気付かされた。

子どもってのは、よく観察しているね。

[tetsuwo]

Jekyll: “Deprecation: Auto-regeneration can no longer be set from your configuration file(s). Use the --[no-]watch/-w command-line option instead.”

Jekyll でサーブしてたら、いつの間にかこんなのが出るようになってた。

Deprecation: Auto-regeneration can no longer be set from your configuration file(s). Use the --[no-]watch/-w command-line option instead.`

エラー内容は「非推奨：自動再生成機能はもはや設定ファイルから設定できなくなりました。代わりにコマンドラインの --watch or -w オプションを使ってください。」とのこと。

Jekyll の設定ファイル _config.yml に記述している auto: true が、いけないようで、これの記述を消せば、エラーは表示されなくなりました。。

参考

Jekyll not updating in localhost · Issue #3343 · jekyll/jekyll

[tetsuwo]

PHP_CodeSniffer/PHPCS: コメントアウトでルールを無視する範囲を制御

コード上、どうしてもこの範囲だけ PHP_CodeSniffer のルールを無視させたい範囲がある場合（こういうケースは作ってはいけないと思いますが）、何かいい方法はないものかと探していていたら、案の定解決方法が存在しました。

コメントアウトで制御する方法です。

こんなコードを書いた場合、PSR-2 のルールを有効にしていると「 use の次行は一行空けなさい」と怒られます。

use Acme\Hoge; class Fuga { ~ anything ~ }

こんなのは修正すべきですが、今回はこれを無視するようにしてみる。

// @codingStandardsIgnoreStart use Acme\Hoge; class Fuga { // @codingStandardsIgnoreEnd ~ anything ~ }

こいつで無視されました。

使っちゃいかんよ。

参考

php - How can I suppress PHPCS warnings using comments? - Stack Overflow

Ignoring Parts of a File - Advanced Usage · squizlabs/PHP_CodeSniffer Wiki

[tetsuwo]

竹下通りの出口付近で工事中の「神宮前計画」

ある日の会社からの帰り道、竹下通りと明治通りの交差点で、何かの工事が始まっていることに気付きました。 いつもは、ただ白い壁に覆われていたエリアに、重機が入り、工事が進んでいるようでした。

思えばだいぶ長いこと、白い、如何にも工事中という感じの壁に覆われていたのですが、一体何ができるのか気になったので調べてみたら、何やら色々あった「案件」のようで、ちょっと記録しておこうと思います。

まず、検索エンジンで「竹下通り 工事」を検索してみると、ちらほら「神宮前計画」というキーワードが出てきました。

工事現場の「建築計画のお知らせ」にも「神宮前計画」と記載があったので間違いないでしょう。

ちなみに下記がそのお知らせ内容です。

項目 内容 建築物の名称 神宮前計画 建築敷地の地名地番 渋谷区神宮前一丁目5番10他 用　途 事務所、商業店舗、飲食店舗、駐車場 敷地面積 6,427.06㎡ 建築面積 3,013.45㎡ 延べ面積 42,862.97㎡ 構造 鉄骨造、鉄骨鉄筋コンクリート造、鉄筋コンクリート造 基礎工法 直接基礎 階　数 地上23階／地下3階 高　さ 115.30m 建築主 原宿タウン特定目的会社 設計者 株式会社 松田平田設計 施工者 大成建設株式会社 着工予定 平成16年11月15日（2004年） 完了予定 平成29年8月31日（2017年） 標識設置年月日 平成16年6月18日（2004年）

看板をみてみると、なんと着工予定が 2004 年でした。 これまで工事が止まっていたのは何故なのか調べてみると、こんな記事を見つけました。

そうした関係筋が注目するのが、〇四年に建築基準確認を済ませた案件。「神宮前計画」と銘打ち、東郷平八郎をまつった東郷神社（東京都渋谷区）の横の土地六千四百平方メートルをさまざまな地権者から買い集め、飲食店やオフィスが入居する地下三階・地上二十三階の高層ビルを建てる予定だという。だが、現場は白い鉄板で囲われたままで、いつまで経っても工事は進まない。 当初、ダヴィンチと新生信託銀行の共同事業としてスタートしたが、土地の一部を所有する東郷神社側が事業中止を言い出して訴訟沙汰になった。東郷神社の宮司は同時期、右翼団体代表に脅迫された。また、自民党元副総裁の故・金丸信氏系と言われる不動産会社までもがこのプロジェクトの舞台回し役として登場する。ダヴィンチが年金基金や海外大学から預かったまっとうな資金の投入先として不都合はないのだろうか。

引用：建設・不動産「倒産ラッシュ」は十月から加速する - http://www.fsight.jp/articles/print/4460

どこまでが本当の話か分からないですが、この情報によると、神宮前計画はダヴ���ンチ・ホールディングス社と新生信託銀行の共同事業としてスタートしたらしい。

神宮前計画の現場近くにある神社の宮司（建設予定地の土地の一部を所有している）が、脅されていたことにより、事業計画の中止を言い出した、ということでしょうか。

ただ、これ程の事業が長い間工事が中止されている理由として相応しくない思い、この時期に歴史的な何かがあったか調べてみました。

歴史的な背景には「サブプライム問題」「リーマンショック」がありました。実際、この問題により、ダヴィンチ・ホールディングス社は株価が急下落したと言われていますが、サブプライム問題が日本で影響が出始めたのは 2007 〜 2008 年とされています。着工が 2004 年であるの��、その間に何かあったのでしょう。

更に調べてみると、着工はどうやら 2005 年 3 月で、工事中止となったのは 2006 年 2 月のようです。

ダヴィンチ社と新生信託銀行は０６年２月、工事中断を通告してきた東郷神社と、この取引の間に入った「リビエラコーポレーション」を相手どって契約不履行で提訴。 その後、５３０億円の損害賠償請求を追加したが、裁判は今も続いているという。ここでは裁判の経緯については割愛するが、ダヴィンチ側が２６５億円を支払った相手はリビエラ社だった。

引用：【ミニ情報】ヘラクレス上場「ダヴィンチ･ホールディングス」に突き刺さる〝事件物件〟 - http://app.m-cocolog.jp/t/typecast/166220/130981/53576241

この裁判が事業進行に直接的なダメージとなったのではないかと思います。これで工事期間が延びて、サブプライム問題やリーマンショックが起きてしまったのか。

根がかなり深そうなので、ここらで止めとこう...。

参考

http://view.tokyo/?p=22489

http://8706.teacup.com/uedam/bbs/8416

http://toyokeizai.net/articles/-/3831

http://www.fsight.jp/articles/print/4460

http://www7.kankyo.metro.tokyo.jp/building/detail/050102_31.html

http://app.m-cocolog.jp/t/typecast/166220/130981/53576241

[tetsuwo]

私的なこと: 優しい子

去年末に次女が産まれたことで、5 歳の長女は姉になりました。

姉になるというのは、戸籍的には当然、妹が産まれてすぐに「姉」になりますが、当の姉本人は徐々に姉らしくなり、妹を妹として認識していくものだと思います。

うちの長女も例外なくそれかと思いましたが、産まれる前から母を気遣い、母の膨れたお腹の中に入っている妹と思われるものを愛でており、兎も角、産まれる前から姉らしい子でした。

しかし、産まれたらどうなるものかと。 母が妹にかかり気になって、妹に嫉妬してしまうのではないかと────。

そんな気を持っておりましたが、いざ蓋を開けてみれば、そんなことは微塵も感じさせず、小さいママかのように妹を可愛がっています。

これには少々驚きを隠せずにいました。

また、別のシーンでは、私が自宅で仕事をしているとき、次女が泣くと長女は、次女の眠る台をゆっくり動かして��心配そうに揺らしていました。 さらに長女が遊びに夢中になっているときに、妹が泣くと「パパ！◯◯ちゃんが泣いてるよ！」とすぐに教えてくれ、自分自信で対応できないときに放ったらかしにせず、周りに振っていました。

自分は三人兄弟の末っ子で、家族レベルで年下の子を抱えたことがないので、実経験レベルでは気持ちは全くわからない前提ですが、子どもというのは我が強く、嫉妬深いものと思っていたので、長女の振る舞いには純粋に感心しています。

・・・これも、親バカの一種かな。

[tetsuwo]

Bot: AhrefsBot/3.0

このユーザーエージェントも、自分の管理するサービスでちょくちょく見かけるものです。

Mozilla/5.0 (compatible; AhrefsBot/5.0; +http://ahrefs.com/robot/)

Ahrefs（エーエイチレフス？）は SEO のチェックツールを提供している会社という認識ですが、念のため調べてみる。

Ahrefsは2011年に発足。 シンガポールとウクライナの多国籍企業が運営するSEO分析ツールです。 世界７か国語に対応し、facebook、Twitter、Google＋などのソーシャルシグナルにも対応した世界で約12万人のサイト運営管理者が様にご利用いただいています。 使い勝手・実績・性能いずれも最高峰のSEO分析ツールです。

引用：https://www.affiliate-b.com/web/ahrefs/

Ahrefs を見てみても分かる通り、有償にて SEO ツール類を提供しているサービスのようです。 （最初に知ったときは無料で使えたような気がしたけど）

次にユーザーエージェント上でも示されている URL（ http://ahrefs.com/robot/ ）にアクセスしてみます。 とても新設なページで、robots.txt の記述の仕方が分かりやすく載っています。

全体的に拒否したい場合、

User-agent: AhrefsBot Disallow: /

クロール頻度を調整したい場合、

User-agent: AhrefsBot Crawl-Delay: 2

のように載っています。

紳士的なクローラーのように見受けられます。