"Permission denied" in "brew install python"

When executed brew install python, I got "Error: Permission denied @ dir_s_mkdir" below.


$ brew install python

...
==> Installing python

==> Downloading 
https://homebrew.bintray.com/bottles/python-3.7.1.mojave.bottle.8.tar.gz

######################################################################## 100.0%
==> Pouring python-3.7.1.mojave.bottle.8.tar.gz
Error: An unexpected error occurred during the `brew link` step
The formula built, but is not symlinked into /usr/local
Permission denied @ dir_s_mkdir - /usr/local/Frameworks
Error: Permission denied @ dir_s_mkdir - /usr/local/Frameworks

Cause

https://qiita.com/Jung0/items/d4012814e6fb1b694208

There was no directory named "/usr/local/Frameworks".

Solution

The solution was the same to the article above.
I created a directory "/usr/local/Frameworks", and gave permissions.

sudo mkdir /usr/local/Frameworks
sudo chown $(whoami):admin /usr/local/Frameworks

Show database list at Redshift

If you want to show the list of databases, you can use pg_database or pg_database_info table, which are included the standard PostgreSQL catalog tables.

SELECT * FROM pg_database;

select datname, datdba, datconnlimit from pg_database_info where datdba > 1;

pg_database_extended


References
System Catalog Table / Amazon Redshift Docs
https://docs.aws.amazon.com/redshift/latest/dg/c_intro_catalog_views.html
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_intro_catalog_views.html

System Catalogs

https://www.postgresql.org/docs/8/catalogs.html

https://www.postgresql.org/docs/8/catalog-pg-database.html

ScalaMatsuri 2016 A1 Refactoring in Scala

ScalaMatsuri 2016は大盛況のうちに幕を閉じました。私もスタッフとして参加しておりました。

さて、ScalaMatsuri2016のA会場で行われた、基調講演たるがくぞさんのセッションの内容を簡単にまとめたので共有します。




【値オブジェクトに使える値の型4選】

  1. Type Alias(簡単、意味が明確にできる。だが型安全でない)
  2. Tagged Type(型安全だ。しかし数値型だとboxing/unboxingが発生してしまう)
  3. Value Class(boxing/unboxing発生しない。しかし定義するのが面倒)
  4. Phantom Type(http://gakuzzzz.github.io/slides/refactoring_in_scala/#27

【Phantom Typeはちょっとコツがいる。導入のための手順は以下のとおり】

  • DBの取り扱い可能な値型との相互変換が問題となる
  • したがってPrismまたはIsoを導入する(相互変換のためのパターン)
    • DB側でPrismの扱いを定義する
    • それぞれの値オブジェクトでPrismを継承する
      • ボイラープレートだ
      • experimentalだがmacroを使えればボイラープレートがなくなる



といったトークがあり、(独断と偏見で)まとめると以下の表のようになります


Type Alias
Tagged Type
Value Class
Phantom Type
Phantom Type & Prism & macro
導入コスト
◎:他のロジックに影響ない
×:定義が面倒
△:macroはまだExperimental
型安全
×
コンテナ型へのキャスト
×
×
追加のメソッド定義
×
×
boxing/unboxing
×:AnyValだとアカン
レイヤー境界での変換が不要(DBなどとの互換性)
×
×
×


こんなにわかりやすい発表資料もなかなかないと思います。

急いで作ったのでミスあると思いますが、その際はどうぞお知らせください。-> https://twitter.com/NoriakiHoriuchi

java.lang.IllegalArgumentException

以下のエラーと長いStacktraceが出力されてどうしたものかと思ったが、ここで示されているList内にパッケージ内のどこでエラーが出ているのかが書いてあったおかげで救われました。


[error] (compile:compileIncremental) java.lang.IllegalArgumentException: Could not find proxy for model: models.MyModel in List(value model, method apply, <$anon: Function1>, method myMethod, class MyClass, package myPackage, package services, package <root>) (currentOwner= value x$11 )

List(value model, method apply, <$anon: Function1>, method myMethod, class MyClass, package myPackage, package services, package <root>) とあるので、末尾から逆に辿って _root_.services.myPackage.MyClass に定義されているmyMethod内の引数一つの無名関数のどこかにおかしいところがあります。

原因は myMethod 内で使用していた Optionfold[B](ifEmpty: => B)(f: A => B) について、第一引数 ifEmpty を指定し忘れていたからでした。

改行して中にコメントを追加していたのでIDEも検知できなかったようです(?)。

foreach するなり、 for 内包表記で処理するという対処法があります。また、Unitを返すべき場面では () を追加するという方法もあります。

Scalaのクラスのコンストラクタに、空の括弧(Empty Parentheses)をつけて定義すべきかどうか?結論:どちらでもいい

「引数を取らないメソッドに対して、空の括弧(empty paren)をつけて定義するか?それともつけずに定義するか?」は、副作用があるかどうかで決めるのがScalaの流儀であります。これと同様に、クラスのコンストラクタも引数を取らないときには括弧をつけるパターンとつけないパターン、いずれの方法でも定義することができます。そうなると果たしてどうやって括弧をつけるかどうか判断すべきなのか?というのが今回のテーマです。

じっさい公式のスタイルガイドにはそのような項目がないので、どうするかは各人に任されているようなのですが、StackOverflowにはドンピシャな質問があります。

Scala style for empty class parameter lists

ベストアンサーの方の回答を要約すると

  1. Javaでクラス(括弧あり)とインターフェースを見分けるために使っているように、Scalaでもクラス(空の括弧あり)とトレイトで使い分けてもいい

  2. メソッドと同様に、副作用があるならつける、ないならつけないということもできる

    • でもコンストラクタでは副作用が発生しないのが理想だよな…
  3. 状態を持つオブジェクト、ミュータブルなオブジェクト(空の括弧つける)とイミュータブルなオブジェクト(括弧つけない)で使い分けるということもできる

    • でもケースクラスはイミュータブルであるべきだが、空の括弧をつけずに定義するのは非推奨だし…
  4. 個人的にはない方が見やすいから付けてないよ

ということです。

個人的にも、わざわざ付ける必要はないと思っています。