BacklogからGitLabに移行した
はじめに
社内で、ずっとBacklogを使ってたのだが、GitLab使いやすくね?となったのでサラッと移行した。
やったこと
- リポジトリの移行
- コミット履歴は引き継ぐ
- 自動デプロイ部分をJenkinsに頼っていたところをGitLabCIにやらせる
リポジトリの移行
以下記事を参考にした
【Git】リポジトリをそのまま別の管理ツールへ移行する方法(Backlog→GitLab を例に)
4年くらい前の記事だが何も問題はなかった。これでリモートリポジトリはGitLabになった。
自動デプロイ
ここがかなり苦戦した。苦戦ポイントは以下。
- そもそもデプロイが走らない
- CIと言っても自動デプロイしかしない参考が少ない
- デプロイ後のブランチを確認すると以下が出る
$ git branch * (detached from {#commit id}) develop master
解決方法
デプロイが走らない問題
色々と以下対応。
- gitのバージョンを2.x系にアップグレード
- 変更のあるディレクトリの書き込み権限をgitlab-runnerユーザーに与える
git fetch-pack: expected shallow list
の対応
デプロイ後のブランチ問題
今回のpush先はdevelopブランチだったため、割と強引に解決。
解決するためのgitlab-ci.ymlが以下
stages: - deploy deploy_dev: stage: deploy tags: - develop-deploy only: - develop environment: name: develop script: - pwd - origin=$(pwd) - cd /path/to/project - pwd - \cp -rf "${origin}/." . - git branch -d develop - git checkout -b develop
cpしていることが色々な原因なんだろうけど、今の知識と移行スピード考えるととりあえずのこの対応しかできなかった。。。 折を見てgitlab-runner用のサーバを立ててdockerで運用していきたい。
【Sansan×エムスリー/ CTO・VPoE がエンジニアのキャリアを語る】に参加しました
はじめに
タイトルのままです。
Sansan×エムスリー/ CTO・VPoE がエンジニアのキャリアを語るというイベントに参加してきました。
内容
割とタイトル通りで、SansanのCTOの藤倉さん、エムスリーのVPoEの山崎さんが各人それぞれのキャリア、考えてきたことを話すというもの。
そのあとはエムスリーの西場さん(@m_nishiba)をパネラーにパネルディスカッション。
印象に残ったこと
割とTwitterに書き込んだのでそれを振り返る。
できることを増やし続ける #33tech
— Kazuki Takahashi (@cuzkop) 2019年10月4日
全部が新しくなりわけではなくて差分を学ぶ #33tech
— Kazuki Takahashi (@cuzkop) 2019年10月4日
半分くらいずつ血を入れ替える #33tech
— Kazuki Takahashi (@cuzkop) 2019年10月4日
これは、山崎さんのやり方として、自分のできることを増やし続けるということ。 ただ、全てが新しいことではなく、できることがある環境で差分を学んでできることを増やしていく。
— Kazuki Takahashi (@cuzkop) 2019年10月4日
これも印象に残った。「迷ったら前へ」という星野監督の名言。チームに捧げたい。
自分のプロダクトに対する熱意があるのはかっこいいけど、技術ももちろん求められるだろうわけで。それは会社によって違うのか? #33tech
— Kazuki Takahashi (@cuzkop) 2019年10月4日
これは藤倉さんの話。技術一辺倒ではなく、明日売れるか?プロダクトとして今価値があるかをすごく考えていらっしゃる印象だった。
感想
参加して、まず思ったのはお二方とも、キャリアがすごく長いし、好きなことをやっていたら強くなっていたということ。
あと、藤倉さんがポジティブすぎて眩しい。
結構エモい気持ちになったのは、「技術を上げるためにより良い環境を求めるべきか」という質問の回答。
これは自分も結構悩んだりする。組織にもよるが、特に’若くて未熟(経験1年半)でエンジニアの会社じゃないところに所属していると、成長加速度みたいなものを考えでしてしまう。
もちろんめちゃくちゃ挑戦しやすい環境で、それも成長の一つなんだろうし、好きならやればいいと思うけど、まだ強い人の下で働きながら自分も強くなる恩恵を受けたいし、それで成長できる幅も大きいんじゃないかと甘い考えに至ってしまう。
とにかく思ったのは目の前のこと全力で挑戦しながらやろうよ、ということでした。
あと、これが嬉しかった
あと、もらった変換器、めちゃくちゃ便利だし嬉しい #33tech #エムスリー pic.twitter.com/rGLT5ag2jt
— Kazuki Takahashi (@cuzkop) 2019年10月4日
勉強したことが仕事に活かせたよろこび
はじめに
先日、以下記事を書いたところ、はてブホットエントリー入りするくらいには反響をいただくことができた。
感謝!
そもそもアウトプットとはインプットがあってこそ活きるものだと思っている。
以前からインプットはしていたのだが、それが仕事に活きてスムーズにできたのでポエム的に。
インプットしたもの
下記本を大学生の時に購入した。
- 作者: 久野遼平,木脇太一
- 出版社/メーカー: KADOKAWA
- 発売日: 2018/03/29
- メディア: Kindle版
- この商品を含むブログを見る
当時はサラッと読み流していたのだが、8月から機械学習、データサイエンスの勉強をするとのことで改めて読んでみた。 プログラミングからデータサイエンスまで基礎から網羅的に書いてあって分かりやすい。
アウトプット
ある機能を実装中に後からの要件で、「APIで取得したものを価格が高いもの順にして表示したいんです」という風に頂いた。
あいにくAPIでの取得結果が複雑だったため、PHPのソートに関する関数は使えそうにない。
たぶん本を読んでいなかったら、文系学士卒の僕なら30分以上ループを回して悪戦苦闘したことだろう。
ただ、好きで勉強=インプットしていたことでバブルソートを知ってたので即解決。
最後に
学ぶって得だな。
Laravelのマイグレーションでカラム名を変更する
やりたいこと
今まではSquelProでポチポチとテーブル作成なり変更を行っていたが、マイグレーションを使ってみた。
作成したテーブルを見ると、あるカラムにtypoが。。。
reflesh
→ refresh
に変えていきたいと思う。
doctrine/dbalの追加
Laravel公式ドキュメントによると
カラムを変更する前に、composer.jsonファイルでdoctrine/dbalを確実に追加してください。Doctrine DBALライブラリーは現在のカラムの状態を決め、指定されたカラムに対する修正を行うSQLクエリを生成するために、使用しています。
とのことなので
$ composer require doctrine/dbal
実行。
doctrine/dbal
が追加されたことを確認。
マイグレーションファイルの作成
次に、Schema変更のために新しいマイグレーションファイルを作成する。
$ php artisan make:migration rename_to_table --table=your_table_name
今回は既存のテーブルに対する変更をかけるため、--table
オプションでテーブル名を指定する必要がある。
するとマイグレーションファイルが作られるので、up
メソッド内とdown
メソッド内に処理を追加する。
変更に際してはrenameColumn
メソッドを使用。
以下のように説明がある。
カラム名を変更するには、renameColumnメソッドをスキーマビルダで使用してください。カラム名を変更する前に、composer.jsonファイルでdoctrine/dbalを依存パッケージとして追加してください。
カラム名変更処理追加
renameColumn
の使い方は、$table->renameColumn("before_column_name", "after_column_name")
。
なので使用例は以下。
public function up() { Schema::table('your_table_name', function (Blueprint $table) { $table->renameColumn("reflesh_token", "refresh_token"); }); } public function down() { Schema::table('your_table_name', function (Blueprint $table) { $table->renameColumn("refresh_token", "reflesh_token"); }); }
down
メソッドでは逆のことをすれば良い。
そしてDBに入ってカラム名が変更されていればOK!
統計の分布の第一歩を学んだまとめ
はじめに
第5回目の授業があり、統計の色んな分布を学習した。
知識の整理のためにアウトプットする。
二項分布
説明
- 結果が二つの試行を何回も繰り返した時に得られる分布
パラメータ
- n=イベントの回数
- p=イベントの発生確率
その他
- 平均:n*p
- 分散:n*p(1-p)
どういう時に使うか
- n回投げたコインの表が出る確率がpの時の表現
- n回のPVの中でpの確率でクリックされる時の表現
ポアソン分布
説明
- ある一定時間や期間でイベントが発生する回数を表現した分布
パラメータ
- λ=イベントの平均回数
その他
- ポアソン分布のサンプルの平均値は、サンプル数に依存するが、母集団の平均値とほぼ同じ
どういう時に使うか
- 1時間で起こる事故の平均件数がλの時の表現
正規分布
説明
- ランダムな誤差を表す分布
パラメータ
- σ=標準偏差
- μ=平均
その他
どういう時に使うか
- μという平均身長を中心にσに広がっていく表現
感想
この他に、正規分布における正規化を行なったが、難しかったので復習しながら別でまとめる。 統計ど素人目線だと正規分布>二項分布>>>ポアソン分布くらいでイメージが湧きやすかった。
LAPRASを使ったらアウトプットがチョット楽しくなった話
はじめに
個人的な考え方が変わったことであって、宣伝ではないしただのポエム的なもの。
LAPRASとは
リンク
こんな風にスコアを出してくれる。
こんな感じでスカウトも来る。
今まで
インプットはそれなりにしていた。
アウトプットはほどほどにという感じ。
文章にすることとか、うまくまとめることが苦手だった。コード書くのは好きなのに。
アウトプットした方がいいとか、社外評価がとか言われるとすごく納得するし、やらなければなと思うんだけど、インプットして仕事でアウトプットして外には出さずに終わっていた。
きっかけ
単純に登録したLAPRASで意外と足跡がついていてスコアを上げたかったから。
あとは、機械学習の勉強しているときにちょっとアウトプットしてみるか、的なモチベーション。
別に綺麗な理由なんてないけど、今までよりgithubにcommitするようになった。
そんな感じでやっていたら、アウトプットするのが当たり前になっていて、でもクオリティは低くて。 ただそれが楽しいです。
今割と習慣化してきて、振り返ると要因は二点
- めんどくさがってた
- 人に見られることを意識しすぎていた
1点目は単なる怠惰ですね。他にやりたいこともあったし、後回しにしてできるときにちょろっとやっていた。
考え方が変わったのって2点目だと思っていて、大きくてすごいものを出さなきゃいけないんだという考えがなくなった。
とにかくまずは習慣づける、アウトプットするという事実が大事なんだと感じた。
スコア上げたい
↓
何かアウトプットするために小さなことでもいいからインプットする
↓
小さなものでもいいからアウトプットする
↓
スコアが上がって嬉しい
このサイクルで、少しでもいいからインプットを継続してかつ、アウトプットも継続する習慣がついたことが一番自分にとって大きいと思う。
質は後から追いついてくるでしょうという自分への期待。
今後の課題
まだアウトプットのクオリティが低いので上がるように努力する。特にはてブ。自由なアウトプットが一番難しい。
最近始めたAtCoderと機械学習勉強中なのでkaggleを頑張る。これはやっていて楽しいし、競うの好きだし、自分自身の勉強と実力の証明に繋がるから継続。
あとはgithubの整理、クオリティ上げ。中途半端なものが多かったり古いものもある。逆に言えば成長を感じるけどね。
勾配降下法が難しい
なんで?
文系卒で数学にまともに17から7年間触れてない人間にいきなり勾配降下法を用いた線形回帰分析は難しかった pythonはある程度書けるから聞いたことをコードに落とし込むことはできても、その中を理解するのが難しい
例えば以下
これは残差の二乗和をalpha, betaごとにプロットしたものだが、この三次元グラフが出てきた瞬間に頭の中は?でいっぱいだ alphaにおける勾配降下とbetaにおける勾配降下という概念がよく分からない 二次元までだとすんなり対応できて概念も微分もわかる。 ただ、三次元だとそこから谷に向かって進むということはどういうことだ? 輪切りにして考えればいいのか? 第二回の授業はそこの説明が欲しかったなあ、という印象
とはいえ、他力本願ではあかんので数学の復習をしなければなと痛感した
第二回から今日に授業が難しくなったので、足腰しっかりしようと思った週末。 来週はアルゴリズムだから楽しみ。
ただの感想日記みたいになっちゃいました。。