yotchang4s web

Homebrewからインストールしたnodebrewの初期構築でハマったところ

Homebrew、便利ですよね。nodebrew、多分必要ですよね?
$ brew install nodebrew
しましょう。んでnodebrewでNode.jsを入れようとしたら…


$ nodebrew install-binary v6.1.0
Fetching: https://nodejs.org/dist/v6.1.0/node-v6.1.0-darwin-x64.tar.gz
Warning: Failed to create the file
Warning: /Users/xxx/.nodebrew/src/v6.1.0/node-v6.1.0-darwin-x64.tar.gz:
Warning: No such file or directory

えっ…

原因は.nodebrew/srcディレクトリがないことですね。なので
$ mkdir -p ~/.nodebrew/src

っとして


$ nodebrew install-binary v6.1.0
Fetching: https://nodejs.org/dist/v6.1.0/node-v6.1.0-darwin-x64.tar.gz
######################################################################## 100.0%
Installed successfully

はい。

GradleでただのJavaプロジェクトでもprovidedCompileを使う方法

build.gradleで
apply plugin: 'war'
等としていると、dependenciesprovidedCompileが使えますが、例えば
apply plugin: 'java'
だけだとprovidedCompileは使えません。そこで以下のようにすれば使えるようになります。


configurations {
    providedCompile
}

sourceSets {
    main.compileClasspath += configurations.providedCompile
    test.compileClasspath += configurations.providedCompile
    test.runtimeClasspath += configurations.providedCompile
}

ただし、マルチプロジェクト等でmasterに上記設定をしてサブプロジェクトで
apply plugin: 'war'
としていた場合、すでにprovidedCompileを登録しているため、エラーが発生します。
そのため、以下のようにすればエラーが無くなります。が、これでいいんだろうか?


sourceSets {
    main.compileClasspath -= configurations.providedCompile
    test.compileClasspath -= configurations.providedCompile
    test.runtimeClasspath -= configurations.providedCompile
}

configurations.remove(configurations.providedCompile)

apply plugin: 'war'

ようは初期状態に戻してあとはwarプラグインに任せましょうってことで。

MavenプロジェクトでJettyのServletTesterやHttpTesterを利用する場合

Mavenを利用していてJetty 9.3.7.v20160115でServletTesterやHttpTesterをテストに利用する場合、pom.xmlを

<dependency>
  <groupId>org.eclipse.jetty</groupId>
  <artifactId>jetty-servlet</artifactId>
  <version>9.3.7.v20160115</version>
  <scope>test</scope>
</dependency>

ではなく、

<dependency>
  <groupId>org.eclipse.jetty</groupId>
  <artifactId>jetty-servlet</artifactId>
  <version>9.3.7.v20160115</version>
  <classifier>tests</classifier>
  <scope>test</scope>
</dependency>

といったように<classifier>tests</classifier>を入れる必要があります。いれないとMavenがjetty-http:testsを落としてきてくれなく、利用できません。小一時間ハマりました。

ReadyNAS 104(多分102も)単体でGoogle Driveと同期する方法

背景

私は家のNASにReadyNAS 104を使ってます。3TBx4のRAID-5を組んでおおむね満足していたのですが、本機のみでのクラウド連携ができないといった問題があります。(ReadyNASのクラウドやDropboxはあるみたいですがバックアップ用途っぽい?)

MacでGoogle Driveアプリを使おうとしたもののSMBには対応しておらず使えず…
Insyncを使ってMacからNAS上のディレクトリを同期していました。つまりMacがサーバーになっていて常時起動状態で半年運用していました。
しかし最近たまたまネットを見ていると、Raspberry PiでNASを構築してしかもInsyncを使ってGoogle Driveを同期すると行った方法があるようです!
ReadyNASでもできないかさっそく試してみることにしました。

結論から言えば成功です。まだ細かい確認まではしていませんが、同期は行われています。
Continue reading

GAEでWordPressを更新するには

Google App Engineではローカルファイルの作成等が出来ないため、WordPress本体、プラグインを直接更新することは出来ません。更新するにはローカルサーバー(devserver)で動かして更新し、デプロイをする必要があります。

ある日更新しようとすると接続情報の設定画面が出てきて今までのように更新できなくなっていました。
Continue reading

GitHubから人間扱いされなくなりました

GitHubにアクセスすると上部にこんなメッセージが。

GitHubから人間扱いされなかった図

シャチクは人間では無いって事ですかそうですか。

サポートにI am human!!!と連絡して待ってます。

※2015/5/27追記

無事人間になりました。I am huuuuuuuman!!!!!!!!!!

Google App Engineでプロジェクトを作成する場合の注意点

みんな大好きGoogle App Engineですが、新しくプロジェクトを作成する場合に注意が必要です。
Continue reading

Ninja Frameworkを軽く触ってみた

アイエエエエ! ニンジャ!? ニンジャナンデ!?

ドーモ。ドクシャ=サン。ヨッチャンです。

Ninja Frameworkって知っていますか?日本では全くといって良いほど情報が無いです。しかし今後注目していきたいプロダクトです。
Continue reading

Google App EngineにWordPressを導入する(その2)

前回の記事、Google App EngineにWordPressを導入する(その1)ではGoogle App Engineの設定について説明をしました。次はいよいよWordPressの導入をしていきます。
Continue reading

Google App EngineにWordPressを導入する(その1)

Google App Engine(以下GAE)良いですよね。インフラ周りをあまり考えなくてもよいところが。ただ、GAEはステートレスで状態を持ちません。ローカルにファイルの保存をすることもできません。少し癖のあるPaaSです。また、PHPが使えるため、Wordpressを動かすことができます。

しかし、Wordpressは画像等メディアの保存、プラグインのインストール、テーマのインストールはローカルのファイルを扱うことで実現しています。先ほど言った通り、GAEではファイルは保存できません。ではどのように導入するのかを説明していきます。

Continue reading

« Older posts

Copyright © 2016 yotchang4s web

Theme by Anders NorenUp ↑