「現役シリコンバレーエンジニアが教える NeoVim(VIM) + Tmux + Zsh 入門」をやった感想
Udemyの講座「現役シリコンバレーエンジニアが教える NeoVim(VIM) + Tmux + Zsh 入門」をやった感想です。
そもそもなぜこの講座に取り組もうと思ったかですが、下のニュースを見たのがきっかけです。
【訃報】テキストエディタ「Vim」開発者のブラム・ムールナー氏死去 - GIGAZINE
非常に悲しいニュースですが、Xでの反響を見ながらブラム・ムールナー氏の偉大さを感じ、vimを使って開発してみようかなと思いたちました。(チャリティーに積極的なのがまたよいですよね。)
以前からvimでバリバリ開発する人を心の中でかっこいいなーと思いながらvscodeに甘んじてきたのですが、これから本格的にrailsチュートリアルの開発に取り組むので、これを機にvim+tmuxでの開発環境に移行するも良いなと思った次第です。
といっても、何から始めたらプロっぽくなるのかわからんと困っている中で見つけたのがこの講座でした。
感想としては、大満足です。夢見たマウスなし開発がこの講座を一通り終えれば実現できます。
情報が古くなっていることもなく講座の通りに進めていけば問題なく環境構築できました。
講座を終えてvimで使っている現状としては、単語を消すのに末尾からデリート連打だったのがdwになったり、かっこよく開発している自分にワクワクを覚えているものの、キーボード操作になれていなくていまだにjとkどっちが上でどっちが下かわからなくなったりストレスもあるという状況です。
無意識に指が動くまでにはどれくらいかかるのかわかりませんが、気づけばvimmerになっていることを楽しみに開発がんばります！！
(vscodeでneovimプラグインがあって、それでもvimっぽく開発できるようなのでtmuxを使って開発するか迷っています..)
[23/09/03 追記] 上の講座ではmacのローカル環境にnvim+tmux+zshの環境を構築しましたが、rails tutorialの開発環境をmacのローカルに作るのが嫌だったので、dockerコンテナに開発環境を構築しようと思いました。ただコンテナ内で開発するとなると、nvimとzshの設定をコンテナ内で再度やらないといけないということに気づき、めんどくさくなってvscodeで開発しています。 vscodeにはdevcontainerという超便利な仕組みがあるので、vscodeの開発環境のプラグイン(neovimなど)はそのままコンテナ内に移植できますし、3000番ポートのフォワーディングもやってくれますし、一言で言って神でした。zshのプラグインは別途必要ですが、まだ特にこまっていないです。 下はrails-tutorialのdevcontainer環境を提供してくれてるリポジトリです。
https://github.com/saboyutaka/rails-tutorial7-devcontainer/tree/master
自分好みのnvim+tmux+zshが構築できるDockerfileを一つ作れば、今後の開発コンテナに転用できるので良いなとも思ったのですが、vscodeで効率化できているので後回しです。
「ProgateのRubyコース、Ruby on Rails5コース」の感想
夏休みを利用してwebアプリ開発をやってみようと思い、とっかかりとしてProgateのRubyコースとRuby on Rails5コースをやってみた感想です。
Rubyコース：https://prog-8.com/courses/ruby.
Ruby on Rails5コース：https://prog-8.com/courses/rails5.
本当はプライベートな時間の投資対効果を考えてGolangを使ってwebアプリ開発をやりたかったのですが、webアプリを作ったことがない人がいきなりGo言語で実装するのは難しいという情報がネットにあったので、初心者でも扱いやすく、現時点で企業で採用されている数も多いRuby / Ruby on Railsでwebアプリを実装することにしました。
基本を勉強するには、ProgateのRubyコースとRuby on Rails5コースをやった後、Railsチュートリアルに取り組むのがおすすめとあったのでその通りやってみたという感じです。
1日くらいでさくっと終わらせてRailsチュートリアルに取り組もうと思っていたのですが、予想以上に時間がかかりました。。
ざっと、Rubyコースで半日間、Ruby on Railsコースで2日間くらいかかりました。。(レッスン選択画面に各レッスンの目安時間が書いてあるのですが、集中して取り組めば目安時間の半分ほどでは終わります).
.............................................
以下、感想です。
RubyはPythonと似ている
普段、業務でc++とpythonを使っているのですが、pythonとほぼ同じ文法やなーと思いながらレッスンを進めていました。
コースやっていく中で気になった違いは以下二つです。
- ifやdefの最後にendをつけないといけない
コースを進める中で、条件分岐や関数実装の際にendをつけ忘れて、エラー多発しました。。
- シンボルという概念
下の記事がシンボルの使い方をわかりやすく説明してくれていました。
【Ruby入門】コロン記号の意味とシンボルのやさしいまとめ！ | 侍エンジニアブログ
RubyとPythonの違いをまとめた記事です。他にも色々と違いはありそうですね。 https://www.ruby-lang.org/ja/documentation/ruby-from-other-languages/to-ruby-from-python/
webアプリをつくるのは楽しい
仕事ではc++で画像処理やDeepの処理をを高速化したり、Deepの処理から得られるデータをpythonで分析したりするのがメインなので、UIのあるアプリを作ったのは初めてでした。UIができあがっていくのは楽しいですね。
特にログイン機能をつけた後くらいから、そうやってログインしていないユーザーをはじいているんだなーなど学びが多く面白かったです(マリオメーカーのギミックを作る感覚？).
Progateのレッスン構成などの仕組みも相まって、ガンガン進められました。
railsは面倒な部分をかなり自動化してくれているんだろうなー
railsが自動化してくれているから細かいことを気にせずにガンガン開発できているんだろうなーと感じながら進めていました。
一番初めに実行するrails new tweetappというコマンドが優秀で、これを実施することでMVCフレームワークの雛形みたいなものができて簡単に進められているんだろうと思っています。Golangになるとこの辺も気にしないといけなくなって難しいのかなと思っていました。
最後に
webアプリをつくるために必要なスキルがざっとつけられるようなコースでした。
webアプリを作ったことがない人が取り組むのはかなりおすすめだと思います。
RailsチュートリアルもTwitterライクなアプリを作ると書いてあったので、共通する部分も多いのかなと思いつつ、より詳細なRailsの仕組みまで掘り下げられるのかなと思っています。これからRailsチュートリアルに取り掛かります。
「情熱プログラマー」を読んだ感想
「情熱プログラマー」を読んだ感想です。
キャリアに悩むソフトウェアエンジニアにとって必読といってもよいほど良い本でした。 160ページとページ数も少ないので、2日間で2回読みました。
ソフトウェアエンジニアとして一流(ほぼスーパーマン？)になるための心構えみたいなものがずっと書かれているのですが、一つ一つが刺さるものが多かったです。
この本で書かれていることを大きくまとめると、
技術的に真の意味でプロフェッショナルになること(専門技術分野の深い理解、汎用的な技術理解、新規技術のキャッチアップ)
ビジネスサイドから評価され信用される人間になること
の二点がキャリアを成功させる上で必要といっていました。(まとめにすると、当然のことをいっていますね..)
個人的に心に残った話は、目の前の仕事をおろそかにして面白そうで評価があがりそうな仕事しかやらないエンジニアのキャリアが成功するわけがないという話です。回り道に見えるかもしれないが、目の前の仕事に焦点を合わせて日々の仕事の小さな勝利を楽しむ方が成功に近づくという話でした。私も退屈な仕事から逃げたいと思うことが多々あるので、ぎくっとしました。
...................
以下、私的に刺さった内容です。(文言は本から引用しているわけではなく、私流に言い換えています)
技術(言語、ライブラリetc)を投資対象と見る
技術を投資対象として把握して、低価格で雇われるエンジニアにならないための戦略です。
需要が多く供給が少ないニッチなテクノロジに注力する。(めっちゃ古い技術 or めっちゃ新しい技術にそのような技術が多い。時代とともに変わる。リターンを得られない可能性もある。リスクはつきもの。)
ハイエンドなスキルをつける。(基準を設定し、品質を保証し、技術的な指導を行うスキル)
(一言)
エンジニアとしての価値を市場価値でとらえるという意識はこれからの時代重要ですね。個人的には過去一世を風靡したような古い技術に注力するのも市場価値が高いというのが面白かったです。自家製のシステムは段階的に新システムに交換されるので、古いシステムと新しいシステムのやり取りができる必要があり、古いシステムを理解している人間が必要になるとのことでした。
ビジネス領域の選定
自分の強みとするビジネス領域を選定することです。エンジニアなので良いプログラムがかければビジネスドメインなんて関係ないと考えがちですが、ドメイン知識があれば、ビジネスサイドの人たちのコミュニケーションがスムーズに進み、ビジネスサイドの人間から安心され評価もされやすいという話でした。
(一言)
この視点は全くなかったです。確かにこの本でも何度も言われていますが、ソフトウェアエンジニアはビジネスに影響を与えてなんぼなので、自身の得意なビジネスドメインを持つべきということですね。
一番下手くそでいよう
レベルの高い集団に属しましょう。メリットは自然とその人たちの思考が身につく点と、意外とその集団でもやっていけることがわかって自信がつく点です。
(一言)
一流のエンジニアの頭の切れ味を直で感じてみたいですよね〜。本の中では、その集団に属するために何をすればよいかについても色々と書いています。(技術面を鍛えるのはもちろんのこと、OSSに参加してみること、コネを作ること、社会的に目立つことが大事など書いてありました)
一に練習、二に練習
実務で練習するという考え方を捨てて、技術に対して自分の時間を投資する。
e.g.).
(一言)
本の中で、プロフェッショナルとして求められる技術レベルについて例がたくさん挙げられていたのですが、全てレベル高いなーって感じました。。ツールやライブラリの基本APIをただ使うだけでなく、普段使わないAPIも使い倒す意識やそのツールやライブラリが動く仕組みを理解する必要があると書いてありました。また、プライベートの時間では、作りたいものをつくるよりもうまくいかない可能性の高い研究的な取り組みをすると力がつくとありました。
私は全部やったことないですね。。日々の業務が忙しいと、プレイベートでも悶々とするのは辛いです。。 技術的好奇心やキャリアの成功を夢見ることで、情熱を燃やさないとダメですね。
今の職務を全力で
自分にはもっとやりたいことがあるのに、それをさせてもらえない。そんなもやもやを解決する手段として、より高い地位を求める。ただどこまで高めてもそんな状況は現れず、ずっともやもやしている。まどろっこしく感じるかもしれないが、気持ちを現在に集中する方が、目標そのものにこだわっているよりも目標に近づける。現在に焦点を合わせていれば、日々の仕事の小さな勝利を楽しむことができる。
(一言)
退屈でもビジネス的に求められる仕事をやった方が偉いに決まっています。ビジネス視点、マネージャー視点で見れば、当然ですね。ただエンジニアとしては面白いことをやりたい気持ちはすごくわかります。退屈な仕事をゲーム的に楽しむ。かつ面白いことも時間を作って取り組む。両方大切だと思いました。
世界を変えよう
会社で目立つためには、使命感を持つ必要がある。改善の余地があるなら自分から変えなければ。 世界を変えようとすると、必ず一部の人たちの怒りを買うことになる。でも意図が正しいなら、聖戦として戦おう。そうすれば職場の誰かが君はどんな仕事をしているの？と聞くことはなくなる。
(一言)
目立つには使命感が必要という話。確かに全社員がいるチャットで戦っている人をみると、そのスレッドを読んでしまいますよね。。名前は覚えていませんが。。
最後に
今後キャリアに悩んだときにまた読み返したい一冊でした。
エンジニアとしての幸福を追い求める人はぜひ読んでいただければと思いました。
「小さなチーム、大きな仕事」を読んだ感想
「小さなチーム、大きな仕事」を読んだ感想です。
シリコンバレーのスタートアップで成功している経営者の思考やマインドがどんなものかわかる一冊でした。
典型的な日本の大企業とはかなり異なる思考やマインドです。
ただ2016年に書かれた少し古い本なので、私の会社で導入されている思考もあると感じました。
本の視点が基本的にマネジメント視点なので、プレーヤーの私がすぐに仕事に活かせる情報は少ないといえば少ないです。
ただ自社開発ソフトウェアサービスを成功させるという観点から読むと非常に勉強になる本であり、これからマネジメントを始めようと思っている人にも良い本だと思いました。
気になったところをまとめました。
計画は予想にすぎない
未来について考えるなとか、やがてくる障害にどう立ち向かうか熟考するなと言っているのではない。それは有意義な作業だが、それを記録したり、たえず心配したりする必要はないということだ。
予想をたよりにしてはいけない。今年ではなく、今週することを決めよう。
マネジメント層を見ていると、来季の計画をたてるのに膨大な時間を使っているなーと思って、ピックアップしました。確かに、来季計画では壮大なことを考えているのですが、完了しているのを見たことがないなとふと思いました。
芯から始める
まったく新しいことを始めるとき、様々なことに引き裂かれる。やらなければならないことからとりかかるべきだ
これは大切だなと思いました。興味のある部分の実装を優先して始めてしまい、はまって抜け出せなくなって、やらなければならないことが後回しになって、締め切り間近にバタバタするという経験はあります。
決断することで前に進む
できるだけ「これについて考えよう」ではなく「これについて決断を下そう」と思うことだ。
決断に決断を重ねる流れに入ると、勢いが生まれ、モチベーションも高まる
よくわからないことが明確になるのを待つとモチベーション下がるのはその通りだと思いました。早く決断して早くサービスをリリースすることが重要ですね。
会議は有害
会議が一般的にテレビ番組のようにスケジュールされるのも不幸なことである
会議は永遠の課題ですね。。スクラム開発では定期的に色々な種類の会議が設定されますが、重要な決断がなされる会議は定期的な会議ではなく、担当者が必要に応じて設定する会議だったりしますよね。。
最後に
他にも気になるトピックはたくさんあったのですが、書き出すときりがないのでこの辺で終わりにします。(力尽きました。。)
気になった方は読んでみてください。
ブログ、始めます〜
はじめまして！
現在メーカーで画像認識AIの精度向上およびその組み込み開発をやっているエンジニアのmoungeneです。
興味のあるTech系の知識をまとめてブログにしようと思います。
よろしくお願いします。
