個人的なお勉強プロジェクトを作ってサイトを公開!してみる
サイトを作る
「色々といんたーねっとに発信していきたいな〜」と思っている流れがずっとあるので、 pet project を作るぞ!!という流れで、
とりあえず「CakePHPについては、仕事で色々とググっているので、思ったこととかメモっておく場があるとスッキリしそう〜」という流れです。
ところで #phpgenba の「自分のサービスを作る」は良かった。
とりあえず作ってみ!!って自分に言い聞かせる事は必要に思う・・・
作ってみるぞ
手軽にサイトを、ってことで。
github pages使ったことなかったからそれで〜〜っていうとこまでは思った、というよりも
「github pages使ったことないから何かしたいな」「Cakeなら定常的にインプットあるからそれ絡めるか」です。
作るぞ〜、作らねぇとな〜って思っていた矢先にmoongiftからこんな記事が流れてきて
よっしゃ使ってみよ!という流れ。
こうなるといいな
- 見た目的なところは、最低限整っていればOK
- 「気軽に更新できること」に重きを置きたい
- サイトの更新も自動でやってほしい
- CI回してmaster にマージされたら自動でデプロイされてほしい
ここまで出来ると最高。
作業メモ
調べたら qiita.com を見つけたので、元々「お勉強サイト」用に作ってあったレポジトリをクローンしてきて
私のローカルホストが2分でこんな姿に・・・ まだ「Docusaurusuってどんなことができるの?」て話しすら、してないのに・・・いわば自己紹介すらまだ住んでない状態なのに・・・
めっちゃすごいですね。良い時代だ。
ヘッダー
出来上がったディレクトリとかファイルとか見てみると、ページが入ってるのが docs
blogの2箇所かな。
で
siteConfig.js` を見てみると、
headerLinks: [ {doc: 'doc1', label: 'Docs'}, {doc: 'doc4', label: 'API'}, {page: 'help', label: 'Help'}, {blog: true, label: 'Blog'}, ],
となっていて、 docs
ディレクトリと website/blog
ディレクトリがあるので、この辺りが関係してそう
$ ls -l blog total 40 -rwxr-xr-x 1 hkinjyo staff 3293 2 10 21:40 2016-03-11-blog-post.md -rw-r--r-- 1 hkinjyo staff 3296 2 10 21:40 2017-04-10-blog-post-two.md -rw-r--r-- 1 hkinjyo staff 475 2 10 21:40 2017-09-25-testing-rss.md -rw-r--r-- 1 hkinjyo staff 180 2 10 21:40 2017-09-26-adding-rss.md -rw-r--r-- 1 hkinjyo staff 197 2 10 21:40 2017-10-24-new-version-1.0.0.md
とのことで、
とのことなので、 blog:true
になっていると、そのディレクトリの下に追加されたページがサイドバーに出るのかな。
良さそう〜。
これを使えば「ページの自動追加」もできるかな。
ディレクトリ構造もそのまま反映してくれないだろうか、と思って website/blog/hoge/test.md
みたいなの作ったらエラー出たw
そろそろリファレンス見てみる
「どういう機能があるの」をまともに見ていなかったので、そろそろ見てみる。
「siteConfigの内容を掘れば良さそうかな〜」と思ったので。
- doc:
.md
ファイルの表示 - page: (jsで)任意のページ
- blog:
/blog
以下に置かれた.md
ファイルでの「ブログ」機能
みたいな感じかなぁ。
customDocsPath
っていう設定項目もあるから、 /docs
の位置については変更できるみたい。
ん〜、「カテゴリごとに自動追加」は難しいのかもなぁ。
Create Your Basic Site を見ると、各docに id
という概念を持たせられるみたい。
docs
ディレクトリも、そのままだと複階層にするのは無理かな?
実ファイルの配置ってよりもリンクの見え方どうなるかなーていう方が関心事として大きく、サイドバーがだいぶ大事になってくると思うので見てみる。
ホワイトリスト式でdoc-idを列挙して、「自分が属するサイドバーがあればそれを表示する」ってか感じかー。
{ "category-name": { "sub-category-name": ["doc-id1", "doc-id2"] } "category2-name": { "sub-category-name": ["other-doc-id1", "other-doc-id2"], "sub-category-2-name": ["other-doc-id3"], } }
そうすると、 doc/doc-id1.html
を開いたときにはサイドバーには doc-id1
doc-id2
が表示されるし、 other-doc-id3
の時は other-doc-id1
other-doc-id2
other-doc-id3
が表示されるし・・みたいな塩梅っぽい。
っていう感じになるかな。
- hoge_index.md - hoge_1.md - hoge_sub_1.md - fuga_index.md - fuga_1.md - fuga_2.md
とかしていけば、一覧性もそんな悪くないでしょっていう気がする。
sidebars.jsonは
公開の自動化を・・
Publishing your site · Docusaurus です。
- Circle CIのアカウントを作ってPJを作成
- https://github.com/settings/tokens/new で
repo
スコープのトークンを作成 - CI側、レポジトリのeditを開いてサイドバーからEnvironment variablesを探して
GITHUB_TOKEN
を追加
circle.yml
のセット- あとでversionかえよう・・
- github-pagesに対応するようにsiteConfigをいじる必要がある
- clone元のレポジトリを編集
/test-site/
ではなくルートディレクトリになると思うので、baseUrlの編集
circleci.yml
https://github.com/o0h/cakephp3-with-me/commit/6525b47b72fc92bb51ecf6067a98a43ad001cc84
machine: node: version: 6.11.2 npm: version: 3.10.10 deployment: website: branch: master commands: - git config --global user.email "o0h@users.noreply.github.com" - git config --global user.name "Hideki Kinjyo" - echo "machine github.com login o0h password $GITHUB_TOKEN" > ~/.netrc - cd website && npm install && GIT_USER=o0h npm run publish-gh-pages
website/siteConfig.js
https://github.com/o0h/cakephp3-with-me/commit/e1421fd85ec9ae9113e8c61cbe5786dc2d6fb543
diff --git a/website/siteConfig.js b/website/siteConfig.js index 5c29ab9..76262d8 100644 --- a/website/siteConfig.js +++ b/website/siteConfig.js @@ -9,7 +9,7 @@ const users = [ { caption: 'User1', - image: '/test-site/img/docusaurus.svg', + image: '/img/docusaurus.svg', infoLink: 'https://www.facebook.com', pinned: true, }, @@ -18,9 +18,9 @@ const users = [ const siteConfig = { title: 'Test Site' /* title for your website */, tagline: 'A website for testing', - url: 'https://facebook.github.io' /* your website url */, - baseUrl: '/test-site/' /* base url for your project */, - projectName: 'test-site', + url: 'https://cake.nichiyoubi.land' /* your website url */, + baseUrl: '/' /* base url for your project */, + projectName: 'cakephp3-with-me', headerLinks: [ {doc: 'doc1', label: 'Docs'}, {doc: 'doc4', label: 'API'}, @@ -50,7 +50,7 @@ const siteConfig = { }, scripts: ['https://buttons.github.io/buttons.js'], // You may provide arbitrary config keys to be used as needed by your template. - repoUrl: 'https://github.com/facebook/test-site', + repoUrl: 'https://github.com/o0h/cakephp3-with-me', }; module.exports = siteConfig;
GitHubの設定も
- github pagesの有効化
- (defaultのまま)gh-pagesを使うようにする
- (サブドメインもあてました)
nichiyoubi.land
ドメインのcake
をo0h.githun.io.
へのCNAME
基盤と基礎的な構想だけはこれで出来た!
リンクの自動化・・・までは叶わなかったけど、サイドバーを最低限更新すればOKって事なので許容範囲かな〜って感じで。
すげー更新が大変だ!!ってなったら、自分でスクリプト書く〜とかでどうにかなりそうだし。
Docusaurus + Circle CI、とりあえずの選択肢としては手軽に使えそうで良いのじゃないかな〜
UbuntuにUpsourceをインストールした際のメモ
EC2を借りてUpsoruceを立てたので、その時のメモ。
参考記事
ココらへんが元ネタ
構成は
- インスタンスはt4.large / m4.largeをスポットリクエストで借りてる
- ubuntu
- HTTPとSSHできるようにポート開けておく
- Uposourceをport8080で立てて
- 表側にnginxを起き、 80 -> 8080でリバプロ
install
Install nginx
sudo apt-get install -y nginx
リバースプロキシとか
参考: nginx(1.3.13) のリバースプロキシでNode.jsとSocket.IO for Android(weberknecht)をつないでみる - Qiita
server { listen 80 default_server; listen [::]:80 default_server; access_log /var/log/nginx/access_log combined; error_log /var/log/nginx/error_log error; location / { proxy_set_header Host $http_host; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_pass http://localhost:8080; } }
web socket使っているので、 ヘッダー周り注意
instal Upsource
download upsrouce
https://www.jetbrains.com/upsource/download/
ここからLinux用のページ開くと「direct link」あるので、それをコピって
wget https://download.jetbrains.com/upsource/upsource-version.zip
sudo su mkdir /usr/local/upsource apt-get install unzip ### 初期化 bin/upsource.sh configure --listen-port 8080 --base-url http://<FQDN>
/etc/hostname
の値を /etc/hosts
で 127.0.0.1に当てる
これをやっておかないと
command [hostname]: hostname: Name or service not known
と言われたり、一部操作でコケる
bin/upsource.sh start
起動するのでブラウザで開く
<URL>:8080
Use build-in hub
して進む。
Hubって何?はこちら →
Hub: Integration Across Team Collaboration Tools by JetBrains
「コード管理/プロジェクト管理」であるUpsourceに対して、「リソース管理/メンバー管理」のHub。
初期設定
Github設定
右上の「Log in」でログインしてから
http://<URL>:8080/hub
にアクセス
設定アイコンから「Auth modules」 「New module > Github」 create
Github側にOAuth用のアプリケーションを作る
register an application in GitHub.
クリック- 諸々設定する。
Authorization callback URL
は、さっきのHubの設定画面に表示されてるAuthorization callback URL
を使う
- Registar Application
作成したアプリケーション情報をHubに登録
- ↑のアプリのClient ID / Client Secret をコピー
- Auto-join groupsを適宜設定(問題なければRegistered Users)
- save
- 右上「Enable module」
プロジェクト設定
- グローバルメニュー「Projects」
- 「New Project」
- name, keyを設定
- Create Project
Upsource設定
- \<URL>に戻る
- connect to a GitHub project クリック
- Repository URLを入力(gitのSSHじゃなくて普通のレポジトリURL
- OAuth Tokenを選択して 「Acquire token」
- Import pull requests as branches, Synchronize comments and pull requests をチェック
use the authentication token
で問題ないはず
- create project
暫く待つ
管理ユーザーにGithubログイン
初期ログインした時のアカウントでGithubログインできるようにする。
「GitHubログインのユーザーを作って」「元々のユーザーにマージする」という流れ
- logout
- login with github
- switch userで管理者アカウントでHubにアクセス
- hubの
Users
で対象アカウントを選択 - mergeボタンのクリック
PHPStorm設定
- Preference > Tools > Upsource > Connection
- Server URLに
を入力 - Test Connecitonをして接続できたらOK
— お疲れ様でした `
自分がよく使いそうなDockerの構成をgithubで管理していくことにした
以前にこういう記事を書いた。 daisuki.nichiyoubi.land
やってよかったな!と思う反面、gistだと手元に持ってくるときに「まだちょっとなんか不便・・」みたいな気持ちになる。わがままだけども。
結局「前に書いた○○」をコピペしたりもするんだけど、ただそれだと「どのPJが最新だったっけ」とか「どこがドメイン固有の事情だっけ」とかを忘れる。
ってことで、githubで管理していくことにした。 github.com
時間があるときに色々と調べたり調子してコミット〜〜〜ってしていく事で、いい感じにできればな〜と・・
解決したかった問題は3つで、
- どこにおいたか忘れる問題
- メンテしづらい問題
- 手元に持ってきづらい問題
といった辺り。
これで、色々と解消されるといいな〜って気持ちでとりあえず作ってみた系。
もうちょっとちゃんとした or 手が混んできたらDockerhubに入れてもよさそうなのだけど、とはいえdokcer-composeは「秘伝のタレ」部分として管理する必要があるだろうからなぁ。
やったこと・書いたもの{2017}
2017年に投げたPRとか(ここやqiita以外で)書いたブログのまとめ
12月
cakephp/cakephp
cakephp関連プラグイン
- fix multi db connection problem by o0h · Pull Request #6 · FriendsOfCake/fixturize · GitHub
- いちおう、他のPRも同じようなタイミングで出してる・・ https://github.com/FriendsOfCake/fixturize/pull/8
- fix custom composer vendor-dir loading by o0h · Pull Request #66 · dereuromark/cakephp-ide-helper · GitHub
会社のブログ
- 物覚えが悪いのでSlackに色々と覚えてもらうappを作った話 - コネヒト開発者ブログ
- 今更始める Firebase + BigQueryを使った サクサクデータ分析 - コネヒト開発者ブログ
- CakePHP3.5.8にアップデートしました - コネヒト開発者ブログ
10月
9月
6月
- 今からちょっとだけ先の未来、CakePHP4の話 〜Upcoming CakePHP Roadmap & Releases〜 - コネヒト開発者ブログ
- CakePHP3のORMの中核を担う「Entity」とは何か 〜CakePHP2ユーザー向けに〜 - コネヒト開発者ブログ
番外
- update deprecated-method use ServerRequest::createFromGlobalss by o0h · Pull Request #11431 · cakephp/cakephp · GitHub
- これはPR投げたあとに「重複してますよ〜」って教えてもらって閉じたやつ。学び・・
ベタープログラマ
ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック
- 作者: Pete Goodliffe,柴田芳樹
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/12/15
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
読みました。こういう系は「本棚においておいて、時折読み返すべき」な感じ。会社の人に「(こういうの)好きそう」と言われて気になっていたので、昨日本屋に行く用事があったのでついでに買ってみて読んだ。
ここ1年、特に夏以降は自身や周囲に対して随分と散々に思う面も多かった年だったので、第Ⅳ-Ⅴ部は読んでて辛い面もあった。理想だよね、そうありたいよなぁ・・ていう。
また後になって(レベルが上って)読んだら違う感想を抱くだろうけど、今の時点で琴線に触れた箇所などを書き出してみようかな
1章 コードを気にかける / 2章 見かけのよい状態を維持する
(p2) 優れたコードは匠の職人が注意深く作り出します。だらしないプログラマが軽率に作るものではありませんし、自称コーディング導師が神秘的に作るものでもありません。
弛みなき努力が〜・・
(p11) 散文を書くようにコードを書いてください。 章、段落、文に分解し、同じようなものをまとめます。異なるものは分離してください。
.
(p11) 最も重要な情報を最後ではなく最初に書きます。APIが実用的順序で読めるようにしてください。クラス定義の先頭に読者が気にするものを書いてください。すなわちわ、すべてのpublilの情報はprivateの情報の前に書きます。オブジェクトの生成は、オブジェクトの使用の前に書きます。
自分は結構「空白行」とか「宣言位置」とか気になる方なので、ただこれは「自転車置き場の議論」に陥るだろうから熱心に説いたり律したりするものでもないだろうっていう部分でもあるので、自分が新たにコードを書いている時以外は(たまに指摘したり手を出したりする事くらいはあっても)スルーor我慢する部分。
なので、こういう「言ってくれる」人がいるの嬉しいし、「散文を書くように」は普段から思っている感覚。
(p20) たるんだロジックは、たるんだ心の現れです。あるいは、少なくともロジック構造の理解が貧弱であることの表れです。
良いコードは「筋肉質な」「緊密度の高い」みたいな感覚があって、書く/読むときは、それこそ(余白も含め)1行ごとに意味や存在理由を持つようなコーディングを意識してるのだけど、「たるんだ心の現れ」ってまでバッサリ行くとw
6章 航路を航行する / 10章 バグ狩り / 11章 テストの時代
(p60)
関連性とかがしっかりしていれば、「どこから読んで」「なにがあるか」がわかりやすいって意味で地図!
(P83) コンピュータが理解できるコードは誰でも書けます。人が理解できるコードを書くのが優れたプログラマです
.
(p100) ひどいテストはお荷物になります。つまり、資産ではなく負債です。
.
(p102) SUTの内部の実装詳細に関する知識、すなわち「ホワイトボックス」の知識に依存しているテスト(これは、テストを変更せずに実装の変更ができないことを意味します。)
.
(p102) ここのテストでは慣習的に、何らかの準備を行い、それから操作を行い、そして最後に結果を検証します。これは アレンジ・アクト・アサートパターン として広く知られています。
テストコードの「見た目」について触れているセクション。この本の言い方でいうと「言い方」なんだけど、写真の通りで。なるほど「パラグラフ」が美しく分かれているなー。
(p106) モックマニアとはひどいテストコードにある別の臭いであり、SUTの構造が正しくないことを示しています。
12章 複雑さに対処する
(p115) 表面的には単純なモデルに見えます。一つの親オブジェクトが「システム」を表しており、子オブジェクトの全てを作成しています。(中略)既知のアンチパターンである「分散した自己」だと私に説明してくれました。
循環的なグラフをなくす、というのが大事。そこからさらに、参照(主従)の関係を一方方向的にする〜て感じかな?
14章 ソフトウェア開発とは / 16章 単純に保つ / 18章 変わらないものはない
(p141) ミケランジェロのように、あなたは問題空間の複雑さを減らして、目指す美しいコードが現れるまで複雑さを取り除いていますか。
(作る〜ってより)「取り除く」作業なんだ、っていうのはたまに思う
(p154) 単純な設計、使うのが容易、誤用を防ぐ、大きさが重要、短いコードパス、安定性、単純なコード行、単純に保ち愚かにならない、想定は単純さを減少させる、早まった最適化を避ける、十分に単純、単純な結論
これはそういうセンテンスがあったわけではないけど、この章の見出し群が良かった!
(p155) 単純な設計の確かなしるしは、大量の書き直しをせずに機能を追加したり拡張したりできることです。
時折「こうなることが丸で予め分かっていたかのような、すげーシンプルに使い倒せる、まさに!というコードだ」て感じさせる場面がある。こういう時はニヤニヤするなーって
(p156) コードが単純に見えるかどうかは、個人的な好みと慣れによる部分が多いです。人によっては、ある種のレイアウトのイデオムがコードを明瞭にするのに役立つと考えています。また、逆に邪魔であると考えている人もいます。
「見慣れ」の問題は本当にある、そういう意味で「いかに普段から同じコードを一緒に読んでいるか」というのはチーム力になる気がするな。もちろん「良いコード」の方が良いので、そうかフレームワークのコードリーディングとかを共同でやるのはいいのかもねー
(p165) かつては疑わしかった設計が、突然申し分のないものと見なされ、変更できないものになります。
古いコードを神格化してはならない!大胆な改修は必要・・・正義ではないけど、ただビビっちゃいけないと思うし禁忌でもないし、素直に(今のレベルで)コードやシステムに対して疑問の眼差しを向け続けるのは必要。と思う
(p169) 私達は、変更を推奨するコードを目指して努力しています。それは、形状と意図を表しているコードであり、単純さ、明解さ、首尾一貫していることを介して修正を推奨しているコードです。副作用を持つコードは、変更に対してもろいので避けます。二つのことを行なっている関数を目にしたら、二つの部分に分けてください。暗黙の事柄を明らかにしてください。頑固な結合と不必要な煩雑さん避けてください。
24章 学びを愛して生きる / 26章 チャレンジを楽しむ / 27章 停滞を避ける
(p233) 「単純に説明できないのであれば、それはきちんとは理解していない」 (中略) その話題について聞いたことがあるかもしれませんが、あなたの知識の限界がどこまでかは分かっていないのです。教えることは、その境界を押し広げます。
.
(p246) あなたが向上しているのがはっきりと自分で分かるようにしてください。達成したことを知るためにソースコントロールシステムのログをレビューしてください。
.
(p246) 車輪を再発明する心配をしないでください。すでに過去に行われたことを書いてください。 (中略) (あなたの実装を実際に使うことに関しては注意してください)
.
(p249) しかし、安全地帯は有害な場所です。そこは、罠です。安全な生活とは、学ぶことも、進歩することも、さらによくなることもないということです。安全地帯は、停滞する場所です。あなたは、すぐに新たな若い開発者に取って代えられます。安全地帯は老廃するための高速道路です。
36章 遠慮なく話す / 37章 多くのマニフェスト
(>p326) コードは書かれるよりも、人によって読まれることが多いことを忘れないでください。したがって、コードは書くことではなく、読むことに対して最適化されるべきです。
.
(p336)
ここの結論は、ジョークです。 と、わざわざ脚注で書いてある。
しかし何かの議論をしている時の自分を振り返ると、なかなかこの「結論」から遠くない振る舞いをしてしまってはいないか・・と、バツが悪い!!俯瞰せねば、達観せねばということになる。 特に刺さるのは「特定の状況に個別に合わせるよりも、固定された不変な考えがあることを信じます。」てやつだなぁ。プラクティス大事、原理は大事なんだけど「賢く」やらないと。バランス。取り組んでいるのはあくまで現在進行形の・・・
(>p337) マニフェストが良い情報を含んでいて、教養としてではなく、会話の火つけとして使われる時には役立ちます。
この前のページに「マニフェストは、原則の大まかな概要に過ぎず、「一つの正しい道」ではありません。」と書いてある。 しっかり自分の中に「原則」を持つことが大事、それでいて固執し過ぎず柔軟にいることも大事・・て感じかなぁ 古びないようにすること
総じて
これ分からないときにいくら読んでも、理解できないんだろうな。もっというと、今「わかった」って思っても後から読み直して「わかっていなかったな」って体験がすごくありそう。
書いて有ることは違和感なかったから、読んでて痛かった部分を中心に思い出すようにしたいのう