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) マニフェストが良い情報を含んでいて、教養としてではなく、会話の火つけとして使われる時には役立ちます。
この前のページに「マニフェストは、原則の大まかな概要に過ぎず、「一つの正しい道」ではありません。」と書いてある。 しっかり自分の中に「原則」を持つことが大事、それでいて固執し過ぎず柔軟にいることも大事・・て感じかなぁ 古びないようにすること
総じて
これ分からないときにいくら読んでも、理解できないんだろうな。もっというと、今「わかった」って思っても後から読み直して「わかっていなかったな」って体験がすごくありそう。
書いて有ることは違和感なかったから、読んでて痛かった部分を中心に思い出すようにしたいのう
ペットプロジェクト
という単語があるらしい。
https://en.wiktionary.org/wiki/pet_project
A project, activity or goal pursued as a personal favorite, rather than because it is generally accepted as necessary or important.
英和辞典系のサイトを見ると、「長年あたためて来た計画」って出てくるけど。 「必要だから」系のものではなく、「ただ己の好きな!!」みたいなニュアンスが強い感じかな。それが僕には楽しかったから!
読んでいる本に何度も出てきて知ったのだけど、印象的な言葉で気に入ったな。
Advent Calendar 0217
12月ぜんっぜん書いてないな!!って思ったので、
その反証と言うか言い訳と言うか・・・で、諸所に書いたものをまとめとして残しておく!!というもの。
今月はAdvent Calendarにも参加していたので、このブログで書くような雑な話ってより「他人が読むかもしれない」フォーカスで書いたのが4本。疲れた・・・w
もう12月25日を過ぎたので、それらを連ねてみる
BigQueryのやつは、書いていて本当に疲れた・・・しかしながら自分としても割と直近で使っていたHotな知識だったし、そこら辺を改めて丁寧に理解できたなっていう点では甲斐はあった