次に作りたいQiita、dev.toの様なサービスについて

手が空いたので次はQiitaのようなエンジニア向けの記事投稿サービスを作ろうかなと思っている。

というのもQiitaは結構ガイドラインが厳しい。その一番の元凶となっているのがコミュニティガイドラインに書かれている下記の一文。

Qiitaは「プログラミングに関する知識を記録・共有するためのサービス」です。プログラマーが興味を持つものではなく、プログラミングに関する記事を投稿しましょう。

この内容が原因で、的はずれな記事についてはコメント欄が荒れたりする。 また、それでも的はずれな記事を書くことが常態化しているため、ちゃんと技術系の記事を書いている人のモチベーションの低下に影響している。

正直自分も技術系の記事を書いてもアクセスが伸びず、関係ない記事を書いたらバズったりしたのでなんとなく虚しい気持ちになっている。 全然いいねをもらえないけど気に入っている記事やアクセスが継続して多い記事はQiitaから削除して自分のブログに移動したりしている。

そのため、プログラミングに関する記事のみでなく、プログラマーが興味を持つものの記事を書く場所がほしいと思ったのだが、どうも日本にはなさそう。 なのでそういったサービスを作る価値は多少なりともあるのではないか、という気がしている。

ちなみに一応そういったサービスである可能性がある候補として考えられるものとして、はてなブログとnoteが挙げられる。

ただ、はてなブログは確かに技術系の記事が多い印象はあるが特に特化しているわけではないし、 Qiitaのように共通のタグ付けなどによる導線の強化なども行われておらず、ここに技術系の記事を書いておけばいい、という安心感がまるでない。 特にはてなブログに書いているからアクセスが上がっている、という実感もまったくない。

noteについてはコードも書けるようになったらしいが、まだ実験段階っぽいので今後どうなるかわからない。 それにこちらも全然技術系の記事が多くなさそうなので、それが要因で技術系の導線は弱そうな気がする。

海外のサービス

海外にはそれっぽいサービスがある。プログラマーが興味を持つことを適当に書けるゆるふわサービス。

Medium

超巨大なブログサービス。そのため何でも書いていいし、プログラミング関連の記事も膨大。それにそもそも日本人で使ってる人も多い。

ちなみに記事を投稿しても一切アクセスがないくらいには膨大。ただ、やっぱり投稿したからには誰かに見てもらえた方が嬉しいので、Mediumは結構自分の拡散力がないと厳しい印象。 Qiitaは無名でも結構多くの人に読んでもらえるのでそこは本当にすごいと思う。

dev.to

爆速ということで一時期有名になったサービス。ここはほんとにエンジニア向けのサービス。

ちなみにこのサービスのAboutには下記のような内容が書かれている。

dev.toはプログラマーがアイデアを共有したりしてお互いが成長していけるように助け合う場所だ。 素晴らしいアイデアを共有したり、発見したり、討論しあったり、仲間を作ったりするオンライン・コミュニティさ。 誰だって記事や質問、議論を共有できる。 ちゃんと権利を持ってる自分のブログの記事とかだったらクロス投稿してくれたって全然構わないぜ。

非常に好感が持てた。このサービスこそ日本にほしい、と思わされた。 単なる爆速なだけのサービスではない。 エンジニアのことを真摯に考えてくれているサービスなのである。 (ちなみに流行っているのか成功しているのかは知らない)

ちなみにクロス投稿については下記にやり方が書いてある。canonicalを使用したちゃんとしたもの。

MediumとDev.toに記事をクロス投稿してみた - アルファブレンド プログラミングチップス

まとめ

ということで、Qiitaのようにシンプルかつエンジニアに恩恵のある面と、dev.toのようにエンジニアに対する思いやりのある面を掛けあわせた、 どこにもない新しいサービスを作ってみようかと思っている。

具体的には下記の感じ。

  • エンジニアが興味のある記事を投稿できるようにする。例えば仕事中によく飲むコーヒーの話でもいいし、仕事の運用上の考え方の記事でもいい。 もちろん技術系の記事でもいいし、質問でも議論でもいい。
  • canonicalを利用したクロス投稿を可能とすることで、自分のブログにも同じ内容を投稿できるし、自分のブログへの導線として使うこともできるようにする。
  • エンジニアのプロフィールにも特化しても面白いかなとは思っている。
  • ちなみに別に爆速に特化したサービスが作りたいわけじゃない。

このサービスについては、適当に投稿とかができるようになったタイミングですぐαバージョンとして公開して、 多くの人に開発している様を見てもらいながら開発が進められればいいな、と思っている。TwitterとかQiitaで。

人気ブログであればここで事前登録はこちら! とすればいいのだろうがうちでやってもアクセスが少なすぎて何の意味もないので、 とりあえず気になる方はTwitterアカウントをフォローしておいていただければ随時情報は発信していく。

ちなみに、いつもどおり全くアクセスもなく失敗しても、自分がブログとして使えばいいので問題ないかなと思っている。 特にもうはてなブログである必然性を感じていないので。 (スターとかもらえても全然メリットも何もないし…)

あとエンジニアは広告をクリックしにくいという情報をどこかで見たのでどうマネタイズするかが謎。

まとめ2

Qiitaが下記を対応してくれればいいだけの話ではある。

とはいえ実際問題Qiitaが本当にプログラミングに関する記事のみできっちりしていたらそれはそれでそのままでベストだと思う。 曖昧なものを許容しすぎている気がするのでそれだったらもう思い切り変えちゃうか統一するかどっちかしてほしい。

P.S.

…とはいえ他に作りたいサービスも多いですし、他の作成を進めてしまう可能性もあるので反響があると進めやすくはあります。 ですので気になる方はいいねでもいいし、匿名のメッセージとかでも全然なんでもいいので反応をいただけると幸いです。

ただよくよく考えると匿名とか送る方法なんてなさそうなので、一応よくわからないですが感想箱というのを作ってみました。 こっちにQiita、dev.toの様なサービスいいねとか送るとかでも嬉しいです。

感想箱:Twitterで気になる人に匿名で感想を送れたり、受け取れたりできるサービスです。

たいして役に立たないアイデア出しの方法の基本の基本

Twitterで質問が来たのだが、その内容がサービスを作りたいけどどうやってアイデアを出したらいいか、というものだった。

僕はそもそも売れるアイデアを出したことすらないのであまり僕に聞いても意味はなさそうだが、一応ざっと基本だろうというところだけをまとめてみる。 多分本当の基本の基本みたいな部分は下記の3つがベースになるのではないかと思う。

イデア出しの方法

自分の作りたいサービスを考える

一番簡単。自分の欲しいサービスや、単に何かでひらめいて面白そうだと思ったものをアイデアにするだけ。

ただし売れるサービスになる可能性は非常に低い。

誰かの作りたいサービスを考える

友達が言っていたことでもSNSで発言していた人の内容でもいいので誰かの言っていたことを参考にしてアイデアを出す。

自分で勝手に考えたことよりは一般的に需要のあるアイデアになる可能性が高い。

たくさんの中から絞り込む

なんでもいいので100個くらいアイデアを出す。すごく大雑把に適当に。いいアイデアかどうかは一切考えず。そしてそれを絞り込んで一番いいものを見つける。

絞り込むための検証方法も様々で色々やり方によって成功度も変わると思う。大変だけど重要な方法だと思う。

まとめ

才能とかだけでなく、基本的には誰でもできる。

当記事は本当にさわりだけの内容で誰もが自然に行ってる方法だと思うので、あまり役には立たない。 必要であれば更に詳しくは「アイデア出し 方法」などで自分で知識を深めていったほうがいいと思う。

CakePHPとLaravelの比較2018

経緯

2016年にこんなCakePHPとLaravelの比較記事を書いた。

CakePHPとLaravelの使い道

また、こちらの記事もCakePHPのみの記事だが完全にLaravelとの比較を意識していた。

CakePHP3の優位性を色々

この頃は正直CakePHPびいきだったが、時も流れ色々と状況や考え方も変わってきたので改めて考察してみた。(人によってはなんで今さらCakeとLaravelの比較なんてやってんだ、と思うかもしれないが)

情報量

検索にしても日本語の情報が非常に少ない気がするので本当に人気があるのかと思ってしまう。

当時Laravelについては上記のように書いていた。

今はどちらも十分。CakePHP3とか、Laravel5とかで検索すれば紛らわしい情報も減るし、困ったらドキュメント見れば大体分かったりする。

ヘルパー

LaravelのHtml, Formヘルパーはなんとなく不足している点が多いような気がする。 実際使ってない人もいるようだ。 radioボタン群すらメソッド一つで作れないとは。

当時上記のように書いていたとおり、FormヘルパーはやっぱCakeの方が楽な気がする。とはいえそんな細かく気にするところでもないかなという気はする。

設定

Laravelは設定量が多い。 パーツを追加する度にCakeだったらこんな設定しなくてもすぐ動かせるのに…。 と思いながら設定をしなければならない。 自由度が高いといえばそうなのかもしれないが、そんな自由度を得てまで時間をかけて開発したいのか、という疑問が湧いてくる。

これ多分Facadeの事を言ってたような気がする。Facadeを自分で作るのは確かに面倒だが、これはテストのやりやすさにも繋がるように便利に作られてるものだし、今となってはそんな気にするようなものじゃないと思う。

でもまあCakeはヘルパーやコンポーネント追加していくだけだからほんとに楽ではある。

あとは

ルーティングなんて設定しない

というのも書かれているが、正直ルーティングを設定するのはどのフレームワークでもあたりまえの事なのでこれも気にするようなことじゃないと思う。

とはいえ設定しなくても動くCakeはほんとに楽なのは楽。ただ、ルーティングを設定することでresourcesの恩恵を受けられコードもシンプルになるし、メリットも大きい。

CakePHPがまずいのは、bakeの自動生成がresources形式になっていないことだ。これがデフォルトでできたらかなり良い。

DebugKit

これはCakeの圧勝に変わりはない。

モデル

Cakeのモデルはほんとに便利。Laravelでも特に不満はないが、Queryがモデルに属しておらずメソッド追加などが出来ないのがちょっと不満。(一応設定すればできるみたいだが)

ただCakeのバリデーションはコードが非常に長い。これはなんとかならないかな。

モデルは一長一短な気がする。

マイグレーション

これも自動生成してくれるCakePHPを褒めちぎってたが、マイグレーションを書くのも今や当たり前の事なので普通に自分で書いている。気にするほどのことでもない。

先進性

JavaScriptについてはCakePHPは遅れている。LaravelはデフォルトでVueとかBootstrapとか使えるのでそれだけでもだいぶ優位。CakePHPはまだjQueryでいいんじゃない? みたいな空気を醸し出していて先進的じゃない。将来どうなるのか心配になる。

他にもLaravelは色々なものと連携できるようにオフィシャルパッケージも続々追加されている。HomesteadやLaradockなど、周辺の開発環境なども色々と考慮されてきている。Laravel本家と周辺共に、みんなが開発しやすい環境を作り上げていこうという活発な姿勢が見られ非常に好感が持て、将来性が期待できる。ここは完全にCakeが敗北しているところ。

というか、ここだけでも今後はLaravelだけでいいかな、という感じすらしてきてしまう。

今年の結論

趣味だったらLaravelを使うと知識や技術も広まりやすいのでおすすめ。

仕事だったら色んなフレームワーク使えた方が扱える案件や考え方の幅が広がる。ただし他言語も含め、composerのようなパッケージ管理は当たり前の様に使われている時代なので、composerを使っていないようなフレームワークはもう覚える意味はないように思う。(全て個人的な見解)

プログラミングをはじめた時のこと Windows3.1編

プログラミングをはじめたのは確か中学生か高校生の頃。

もうはっきり覚えてないけど、中学で年に数回しかなかったPCの授業でタッチタイピングをして驚かれた記憶があるので、多分中学ではやっていたんじゃないかと思う。

はじめて実家で買ったPCは富士通のFM-V。Windows3.1が入っていた。まだファイル名が8文字+拡張子だった頃。

家ではほとんどゲームばかりしていたので、その関係でゲームを作りたいと思うようになっていった。普段から頭の中で自分で作った新しいゲームの妄想などをしていた。 なのでプログラミングについてはずっと興味津々だった。

一度PCを持っている友達の家にいき、ゲームを見せてもらったことがある。しかもそれがその友達の知り合いが作ったゲームということですごく興奮したのを覚えている。 自分でも作れるようになりたかった。

とはいえまだインターネットをやってる人もあまりいなかった時代。まだパソコン通信という名前で一部の人がやっているっぽいことを雑誌か何かで知っていただけだった。 当然うちでは繋がってなかったので、今みたいにネットで調べて勉強、みたいなこともできなかった。ほんとに時間がもったいなかったなと思う。 今の若い人はとてもうらやましい。

しかしある日、とある雑誌を見つけた。なんとそれは、Visual Basicの体験版が同梱されている雑誌。 早速その雑誌を買って、自宅のPCでプログラミングをはじめた。 僕のプログラミングの第一歩。

体験版なので作ったものを保存したりができなかったのだが、それでも毎日すごく夢中になって頑張って何かを作っていた。 多分ちょっとした使い方なんかはその雑誌についていたんじゃないかと思うので、それで色々やっていたと思う。 ウィンドウの背景を青のグラデーションにするのにハマっていたので、作るアプリケーション全て背景がそんな感じになってた。

多分ゲームやプログラミングなど好きなことばかりやって引きこもっていたので、 友達も少なく、どうやって楽しく遊んでいいかもわからず、その後もしばらくは周りと馴染めずに過ごしていたけど、 こうやって楽しくプログラミングをしていた姿が今となると、 将来自分の幼い息子がこうやって何かに夢中になって励むのだろうというまだ見ぬ姿に重なり、 なんとなく誇らしく、微笑ましい気持ちになる。

その後はあまり記憶が定かではないのだが、恐らくおじいちゃんにたのんで、多分学生向けの激安VBの製品版を買ってもらったのではないかと思う。多分高校生くらい?

製品版ともなると、拡張子exeの実行ファイルを作ることができるようになる。それだけでものすごく興奮した。

色々なものを作った記憶がある。一問一答のカードリストを自分で作れるソフトとか、 スタートアップに登録してPC起動時に起動するようにして、10秒以内にパスワードを入力しないとPCをシャットダウンさせるソフトとか。 (弟に文句を言われたので外した。当時は自分の好みにPCの中を整理したかったので、他の人に使われるのが嫌だった)

このあたりも情報収集方法は本屋だけだった。毎月フリーソフトが100個とか入っているCDがついた雑誌を購入していた。 あとは立ち読みして情報収集していたんじゃないかと思う。学校帰りにいつもPCコーナーに立ち寄って本を見ていた。

そういえばふと思い出したけど、すごくハマっていたフリーソフトがあった。 ボールみたいなキャラクタを操作してハンバーガーを集めるゲームで、ステージがテキストで作られているので自分で改造できるという代物。

とても面白くて、しかもフリーソフトということで普通の人が作っているということなのでとても興奮してファンになった。 その人に憧れて、自分も何か作ると似たような体裁の説明書txtを作ったりしていた。 (ネット繋がってないから公開もできないのに) 確か1000円寄付した覚えがある。 作者名もゲーム名も思い出せない。なんだろ… (※思い出しました。FlyingJumpというゲーム)

あと雑誌で、スクリーンセーバーも作れるという方法を見たので、試して作ってみたりした。 手に入れたフリーソフトで自分の声を録音してそれをかもめの声のように高くなるよう変換し、かもめが海を飛んでいるスクリーンセーバーとかを作っていた。 春夏秋冬4パターンを作ろうと思ったが途中で飽きてやめてしまっていた気がする。

スクリーンセーバーを作れるということは描画はできるっぽいんだけど、その時ゲームを作っていたかは全然覚えていない。

そういえば、センター試験の選択問題はBASICのプログラミングがあったので、いつもそれを選んでやっていた。 普通に数学解くよりめちゃくちゃ簡単だった。

あとはすごい技術がたくさん詰まった5000円くらいの分厚い本を買ったのだが、多分他のことにハマったのか受験で忙しくなったのかは忘れたが、 ほとんど使わずじまいになってしまった。

まあそんな感じで、自分では気づいていなかったかもしれないが非常に充実した時間を過ごしていたと思う。 プログラミングが好きな人は、せっかくなのでガッツリハマって楽しんで欲しい。 この時代、やりたいことは何でも調べてできるのだから。

作ったサービスの上位互換サービスがあったことに気づいた

先日下記のようなサービスをリリースした。

torima-p.com

数年前に終了した前略プロフィールというサービスをモチーフにしたもので、 一問一答式のプロフィールを作成することが出来る。

Twitterのサービスなので容易に集客できるだろうと思っていたがそうそううまくいかず、 色々検索したりして調べていたところ、とあるものを見つけた。それが下記。

proffy.jp

完全にとりまプロフィールの上位互換。 互換とかうぬぼれにも甚だしいというか、どこを見ても全然レベルが違うほどしっかり作られている。

  • 書ける内容の種類が豊富
  • かわいらしくておしゃれ
  • コンテンツも非常に多い
  • Instagramとも連携できる
  • 公式ツイッターがおしゃれ
  • 既に集客しっかり出来てユーザーたくさんいる

どうやらとりまプロフィールリリースの1,2ヶ月くらい前にリリースされたばかりらしい。 これでここまでやってるのはすごい。どう考えても勝ち目はない。

ということで別のラインで違ったすごいアイデアが出るまではとりまプロフィールはこのまま寝かすことになった。 切ないがそれほど開発に時間をかけていないのが救い。 (ただ、おかげでどういった作り方や宣伝方法をすると良いかは非常に参考になった。)

ということでプロフィールをつくりたい人は是非Proffyを使いましょう。

WEBサービスを作りたい人への最初の1歩の勉強方法アドバイス

発端

先日プログラミング等でWEBサービスを作りたいのだがどうすればよいか、という問い合わせが来た。

Twitterの奥深く、普段誰も訪れないような僕のアカウントのところまでどうやってたどり着いたかは謎だったが、一応色々考えつつどうやって進めたり勉強したりすればよいかを回答してみた。せっかくなのでその回答を当記事としてまとめてみた。

前提

  • WEBサービスの開発を全くやったことのない方が対象
  • デザインの方をメインでやりつつ開発したいらしい
  • 僕はWEBエンジニアなのでデザイナーではない。ただ、一人で開発することが多く一応フルスタックエンジニアとしてやっているので、デザインやフロントの最低限のことくらいは分かるのではないかと思うのでそれくらいの人によるアドバイス
  • 細かい話をしすぎても役に立たなかったり、初心者ということで意味が分からなくて混乱してやる気を失ってもだめなので、最初の1歩というところに特化
  • 上記全部にあてはまる人のみなので対象となる人は少ないかも
  • ブログなのでなるべく分かりやすくするため推敲済
  • 全て僕の想像なので、最終的には各々自分で決めるべき

返答

ベースとなる考え方

  • 勉強だけよりは、何かを作りながら、わからない所を調べていく方が実践的な勉強になる
  • でも最近は開発に必要な基礎を勉強できるサービスも増えているので、完全にゼロで迷いながら進むよりも最初だけはそのあたりを参考にしてみた方が効率が良いかもしれない

最近周りでProgateがめちゃくちゃ流行っているように思う。プログラミングを勉強している人はみんなProgateをやっているんじゃないかと思うくらいProgateという文字をしょっちゅう見る。

ちらっと調べてみたが、無料プランで結構試せるみたいだし、とりあえず最初の勉強の仕方に悩んだらまずProgateの無料プランを試してみてから考えても良いんじゃないかという気がする。なので参考にProgateは教えておいた。

prog-8.com

ただ、特にがっつりおすすめしているわけではない。

というのも、僕自身が古い人間で、当時はわからないことがあったら検索しつつ試行錯誤して時間をかけて、迷いながらも熱中しつつ結果として勝手に学んでいて色々出来るようになったので、その方法が一番実践的ではあると思う。

ただし、あくまでそれは自分の好きな形なので、世の中すべての人にそんな非効率かもしれない方法をおすすめするわけにはいかない。最初から正しいか間違ってるかわからない方法で時間をかけて試行錯誤させてしまうのはとても無駄で可哀想。

そのため0からでもなんとなく概要が分かる、そんなところとしてProgateを教えた。無料コースならそんなに時間もかからないと思うので、実際にやってみてその後の進め方はまた考える形で良いと思う。 それに、「Progateで○ヶ月勉強してサービスリリースしました」みたいな人を最近良く見かける。ちゃんと学習意欲がある人はそれで作れるっぽい。

ただ、あまりハマってやりすぎるのは良くない。Progateをやっている人たちの中には、何も開発せずに無意味に何周もしてるという人もいる。それはもう覚えたことを活かすことでなく、勉強することがメインになってしまっている。それで満足であれば問題ないが、自分で開発したい、というところが目標であれば決して良いことではない。

なので最初に書いたとおり、まずはざっと概要を教えてくれるところで勉強してみて、あとは実際に何かを作りながら技術を伸ばすのがベストな形だと思う。

実際に勉強する内容と優先度

上から順に優先度が高いものとなる。

HTML&CSS

WEBサービスを作るなら必須のため特筆するところはない。

JavaScript

普通のWEBエンジニアとして開発したいということであれば違うが、今回はデザインをメインでやりたいということだったのでJavaScriptを次点とした。 ブラウザ上で色々動かしたりするのに使うので、最近はWEBデザインをやるならほぼ必須だろうと思う。(とはいえガッツリプログラムを書けなきゃいけないというわけでもないので、とりあえずは概要を知っておくだけでも良いと思う)

ただ、最近はFirebase等もあり、プログラム言語としてはこれだけでもデザイナーさんがWEBサービス全部作れてしまったりもするのですごい。多少深く勉強しても良いと思う。

jQuery

たまたま今回JavaScriptを2番めにしたので、その流れで3番めになっているだけ。 とはいえデザイナーさんでjQueryを使っている人はまだ多いのではないかとも思う。 プログラムを組むというよりは、既にあるライブラリを導入したり改造したりがメインとは思う。

PHP

レンタルサーバーなどで簡単にWEBサービスのプログラムを組むことができる、一番簡単なもの。 (ユーザーや投稿データを保存したりするのに使う)

今回の話がデザイナーでなくエンジニアということであれば、JavaScriptの代わりにこちらが一番だったと思う。 ちゃんとよく分かってなくてもリリースできるので。 (ただしエンジニアの場合であれば個人的にはちゃんと勉強して色々理解したうえでリリースして欲しいのでフレームワークとか使ってほしい)

Ruby, Ruby on Rails

Rubyは役割としてはPHPと同じだが、よくあるレンタルサーバーでは使えない。 でもRuby on Railsというフレームワークのセットで非常に開発しやすくなるので、一人でシステムを高速で作る場合に非常に人気があり、 スタートアップの開発などでも非常によく使われている印象がある。 (PHPの場合はLaravel, CakePHP等のフレームワークがある)

ただ、WEBデザインメインだとフレームワークまで使う必要があるのか? という感じ。 敷居も高く勉強に時間もかかるので、優先的にやるのはおすすめしない。

とはいえ、サーバー側も必要且つリリース環境の用意も可能だったらとりあえずこれで良さそう。 PHPフレームワークに比べ、ワンセットになっている感が恐らく初心者には分かりやすいと思う。

優先度まとめ

何にしろまずはHTML&CSS優先的に。そして、その後ちらっとJavaScript。 あとはどういったサービスを作るかによって変わってくるのでその段階で何を覚えるか決める。 勉強するぞ、という段階では決めづらい。

初期の開発と運用のためのおまけの補足

何かサービスを作っても基本的には誰も人が来ないので、どうやって人を集めるかはよく考えておく必要がある。 例えばTwitterを使った方法で基本的なものでは下記のようなものがある。

  • 開発中の独り言をつぶやくと、アドバイスがもらえたり、徐々にいつの間にか広まったりしてサービス開始時に有利になりやすい
  • 開発してリリース後、サービスを利用したりテストしてくれたりする人が増え、成長しやすい
  • もしフォロワーさんの興味、年代など、共通な属性が見られる場合、そのへんをターゲットにしたサービスにすることでヒットを狙いやすい

ただしフォロワーが多い人向けなので、フォロワーが少ない人は別の方法を模索するか、リリースに向けて増やしておく必要がある。 (大量購入などは無意味なのでちゃんと普通に増やす。仲の良いフォロワーさんが少ない場合もあまり意味ない)

まとめ

とりあえず最初の一歩に特化して書いた。実際にきちんと勉強できるか、リリースしてうまくいくかは全て本人次第。 基本的にはうまくいかないので、ひたすら継続し、体験したことからあらゆることを学習していくことが重要。

Phoenix1.3でex_adminを使う

Phoenixではex_adminという管理画面作成パッケージを導入することで簡単に管理画面が作成できる。

smpallen99/ex_admin: ExAdmin is an auto administration package for Elixir and the Phoenix Framework

しかし依存関係やフォルダ構成の違いの問題で最新のPhoenixではうまく動かない。ただ、よくよく調べてみると下記のphx-1.3ブランチを使えばできるっぽいので試してみた。

https://github.com/smpallen99/ex_admin/tree/phx-1.3

導入方法

phx-1.3ブランチを指定して入れる。ビルドに失敗するのでgettextのバージョンも上げる。

mix.exs

defp deps do
  ...
  {:gettext, "~> 0.13.1"},
  {:ex_admin, github: "smpallen99/ex_admin", branch: "phx-1.3"},
  ...
end

configを追加。

config.exs

config :ex_admin,
  repo: MyProject.Repo,
  module: MyProjectWeb,
  modules: [
    MyProject.ExAdmin.Dashboard,
  ]

後は通常通りのインストールと同じ。

brunch-configの修正

そのままだとex_adminのcssとかが混ざってしまう。brunch-config.jsに修正方法が追記されているので、そのとおりに修正。

またその際、node_modules内のcssをインポートしている場合はcssの設定だけ下記に修正が必要。

        "css/app.css": /^(css|node_modules)/,

モデル追加

mix admin.gen.resource User

これは特に変わりはない。ただ、1.3だとphx.gen.htmlを使っている場合、context module以下にモデルを入れていると思う。例えばAccounts.User等。

なので生成されたadmin/user.ex内のモデルの指定だけ修正しておく。

admin/user.ex(before)

  register_resource MyProject.User do

admin/user.ex(after)

  register_resource MyProject.Accounts.User do

これで動作した。