彷徨う園児ニア

主に備忘録。

pom.xmlに「ライフサイクル構成でカバーされていないプラグインの実行」というエラーが出る

m2e-aptというプラグインが必要とのことなのでインストールするも解決されず。

他にも色々試してみたが、
環境設定 -> Maven -> ディスカバリー -> カタログを開く
から、AspectJをインストールすると解決した。

forEachの中ではindexが利用できない(ラムダ式使用の注意)

Javaいじってて、ロジックは簡単だったので適当にfor文をforEach処理に変えていたときに発生した問題。

forEach中ではindexが使えません。
何かで取得できたような気がしましたけど"java forEach index"とかで検索すると同じことを考えていた先人たちが使えない使えないと大合唱。

//コンパイルエラー
int i = 0;
Arrays.asList("a", "b", "c").forEach( x -> System.out.println(++i + ": " + x);


以下のようにすれば一応は書ける。

int[] i = {0};
Arrays.asList("a", "b", "c").forEach( x -> System.out.println(++i[0] + ": " + x);

ラムダはラムダ内で完結してて状態を持たせないのが良いとのことなのでこのインデックスの取得も本当はあんまりよくないのかも。

ラムダのメリットとしてよく書かれるのが、
・記述が簡潔
・テストしやすい
・入力に対して出力が一意に定まる
などですが、記述がしやすいといっても、やっぱり複雑にFuctionを渡しまくっているものだと記述は短くても容易に読めないと思います。
その場合テストもしやすくはありません。
3つ目の 入力に対して出力が一意に定まる = 外部の状態をスコープ内に持たない
これが肝で、このためにテストしやすくなる等の恩恵を受けられるのかなと。

以上から、状態をもってきていないことが明らかにすぐわかる場合や状態を持ってきたい場合は従来通りfor文で良いのかなと思います。

10月発売のEffective Java 3rd Editionにもラムダの運用とかについても説明がなされることを期待しているので、発売待ってます。

めっちゃ久しぶりにrubyをupdateしようと思ったらいっぱいひっかかった

一年前にrailsでざっくりいじった程度でずっと放置してたrubyのバージョン上げとくかと思ったらめっちゃつっかかったのでメモ

Homebrewでbrew updateしようとしたら・・・

$brew update
xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun
Error: /usr/local must be writable!

まずCommandLineToolsがないってことなので

$xcode-select --install

Mac OS Sierraにするとなるとかなんとか。

次に権限がどうのこうのなので

$sudo chown -R $(whoami) /usr/local

これで意気揚々とやったら

$brew update
/usr/local/Library/brew.sh: line 32: /usr/local/Library/ENV/scm/git: No such file or directory

brew pruneすればいいらしいので

$brew prune
Pruned 0 symbolic links and 2 directories from /usr/local

$brew upgrade ruby-build
$rbenv install 2.4.1
$rbenv global 2.4.1

なんとかできました。

[Eclipse]Tomcatが起動しないときの対処法[Mac]

MacEclipseを使用してTomcatでサーバー立ててコーディングしてると、たまにTomcatを正常終了できなかったのか、

「ポート8080,8009が使用中です」みたいなエラーメッセージが出てTomcatが起動できなくなる。

再起動すればまた起動できるようになるのだが、いちいちするのもめんどい。

ということで探したのだけどWindowsではコントロールパネル使って停止するみたいなことを書いてあるもののMacだとなかなか見つからない。

 

で、どうやらTomcatをインストールしたフォルダ内のbinフォルダにあるshutdown.shを実行すれば良いらしい。

 

これでまた起動できるようになりました。

Macでh2データベースを起動する

h2のデータベースの起動で戸惑って検索・・・

という作業を3回もやったので備忘録として書き残しておく。

 

  1. Macはh2をインストーラでインストールできないようなので、zipでh2ファイルをダウンロードしてくる
  2. zipを適当なフォルダに解凍
  3. ターミナルで解凍したフォルダ内のh2/binディレクトリに移動
  4. projectのlibraryにh2-x-x-xxx.jarをコピー
  5. h2/binディレクトリ内のh2.shを実行 コマンド ./h2.sh

とりあえずこれで起動できました。

[追記]library内のjarファイルをダブルクリックでも普通に起動できた

 

Macに乗り換えるにあたっての失敗について

エンジニアに転職するにあたって、WindowsからMacに乗り換えました。

 

理由:エンジニアの Macユーザーが多いから。形から入ります。

Machine spec

CPUがi7じゃないのは心残り → できればi7にするべきだった

メモリはやっぱ8Gだと不便 →これは確実に16ないと重い

しゃーないからMemory Cleaner X入れて頑張ってるけど重くてイライラすること多々。

 

最大の後悔は、キーボードがJPキーボードだということ。

家でのコーディングには基本的にMacでやって、会社でのコーディングは会社のwindowsでやってるが、どうも会社のパタパタパンタグラフキーボードが不快すぎる。

そこでキーボードを購入しようと思ったのだがJPとUSどっちにするべきか・・・となったわけである。

会社と家でキーボードが違う・・・なんてのは絶対に許されない(というかイライラやばいと思う)ので以下選択肢。

  1. 適当なJPキーボードを購入してお茶を濁す
  2. それなりに良いJPキーボードを購入してJPキーボードと添い遂げる 
  3. MacBookをUSに買い換えてUSキーボードを購入
  4. MacBookをUSに換装してUSキーボードを購入

1はUS乗り換え時にキーボードがゴミになってしまうことが問題だし何より会社のキーボードが不快だから変えたいのに適当なスペックだと不快感があまり解消されない可能性あり

2はUSキーボードを使いたいのでちょっとしんどい

3は金が吹き飛ぶのでしんどい

4は換装のお金がこのMacの3〜4割くらいかかるらしいので馬鹿らしい

 

 

Macは悩んでJPキーボードにしたけどUSにすればよかったと死ぬほど後悔。

JPキーボードはEnter打つ時に右手がホームポジションから離れてしまうのがすごい嫌。

 

そもそもなんでJPで購入したんだって話だが、家の据え置き機のスペックがそれなりに良くて、家のキーボードがRealForceのJP版で無駄に良い物だったのでなるべく使いたいと思ったこと。また本格的にMacでガリガリやるとなるとMacBookProを購入するだろうからその時でいいやって思ってしまったことが原因。

実際現状コーディングはだいたいMacでやってるし、家のRealForceはあんまり出番がない。

1の選択肢の拡張として適当なキーボードを買ってRealForceを職場に持っていくことを考えたが、家のキーボードはコーディング以外にはゲームとかでそれなりに使うのでちょっと憚られた。

 

 

 

しょうがないので会社のパタパタパンタグラフとつきあうことにしました。

キーボードを交換するのにコストが大きくかかるノートPCのキーボードは自分がこれから使いたいものにしましょうね。

 

以上失敗談でした。