プログラミング関連の情報が2014~2015あたりで止まってる気がする説

完全に思いつきですが、これに関して少し考察してみた。

Continue reading “プログラミング関連の情報が2014~2015あたりで止まってる気がする説”

「Jenkins実践入門」を読んだ

読んだ。

普段使い込んでいる人にとっては、あまり新しい内容がないかもしれないが、入門者にとっては順番にセットアップしていくことによって、基本的な使い方を体感できるようになっている。

使ったことがあるくらいの人だと、この本からもう一度勉強しても良い内容だと思う。

使用例がJavaがベースなので、自分の場合、実際にやっているSwiftとは若干異なる点があるのだが、基本的には、ユニットテスト自動化、カバレッジ取得、などは応用していけると思う。

iOS向けのJenkinsセットアップなど、ニッチなコンテンツは含まれていないのでインターネット等で補完していく必要はある。

読みやすく、さっとJenkinsの使い方を知ることができるので、興味ある人は買って損はないと思う。

 

[改訂第3版]Jenkins実践入門 ――ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus)
佐藤 聖規 和田 貴久 新井 雄介 米沢 弘樹 山岸 啓 岩成 祐樹
技術評論社
売り上げランキング: 7,641

エンジニアとして毎年やっていること

私が、毎年エンジニアとして、個人目標に掲げてあることは以下の5つである。

  • 新しいプロダクトを開発すること
  • 新しい言語を学ぶ
  • 新しいフレームワークを学ぶこと
  • オープンソースプロダクトを作ること
  • 技術的なアウトプットをすること

アウトプットは一番簡単で、1つでも何かアウトプットすれば良い。例えばこのブログである。今年から、再びvpsでブログ運用しているので、お金が💰続く限り、ここに蓄積されていく予定である。

新しい技術に興味をもつ、新しい技術を試してみる、新しい技術に慣れる(そして古くなる)、の順にどんどん人は減っていく。慣れるまでは意外と難しい。が、試すことはできる。手を動かした段階で、人より先を行くことができる。いろいろ試してみよう。

また、何かしらオープンソースでプロダクトを作ってみるというのも毎年やっている。

全然、流行ったり使われたりするわけではないか、考える感覚を落とさないためのトレーニングのようなもの。実際に何かを実装するとかにこういう経験があるないでは、判断に差が出て来る。

プロダクトづくりは、一発狙いである(当たったことはない) 。何か作っている時は楽しいので、趣味の一環。

たまに病院に行くのも悪くない

たまに病院に行くのも悪くないな、と思った。

なんか悪いところがあると、不安になって、将来どうなるんだろうとか、生きられるだろうか、とか考えてしまうけど、病院に行って相談すると、自分にとっては新しい問題でもすでに解決済みの問題であるかのようにポンポンと回答を得られるのでいいと思う。

病気の相談にも、StackOverFlowみたいに簡単に解決できるソリューションがあるといいなと思った。現状の医療相談サービスは、結局のところ医者に行けという一言に尽きる回答が多い。かと行って一般ホームページに載っている情報は、ほぼアフィリエイトかデタラメである。 おそらく、相談者が欲しい情報は、ある程度評価された、ベストプラクティスなので、それを知った後、どの医者に行くかどうかは本人が自分で判断できる。インターネットで病院の情報は得ることができる。

これは医者サイドにとっても悪いことではない。なぜなら、患者は自分の症状について、どういう治療を受ければいいか知っている。医者としては、そのニーズにあった医者と判断されたわけだから、自信を持って技術提供すれば良い。完全にwin-winである。そして何より、医者に行くことで情報の正当性を確かめることができるので便利。

これによって、デタラメな情報によって、悲しい思いをする人が減るんじゃないかと思うんですが、どうなんですかねぇ。

 

Dotfilesについて最近考えていること

自分は、dotfilesリポジトリを作って、いろいろ管理するタイプの人間なのですが、最近のdotfilesの構成についてまとめようと思います。

自分のdotfilesでやっていることは、以下

  • 基本的なshellのセットアップ
  • 環境変数などのコマンドラインのセットアップ。
  • デスクトップアプリのインストール

もはや、dotfilesの領域を超えて、デスクトップの設定も行っています。

先日、OSのクリーンインストールしたのをきっかけに環境を見直しました。そのときに、セットアップを大幅にアップデートしたので、そのときに考えた基本設計です。

とりあえず、disposableに

レガシーソフトウェア改善ガイド読み終わった”でも触れたのですが、disposableな設計は良い品質を維持するために大切なことだと思うので、自らの環境にも導入しています。例えば、医療の場でも、使用する機器は患者ごとに、disposableにしていることがほとんどだと思いますし、常に新鮮に保つという意味でも良いプラクティスだと思っています。

また、今、ベストだと思っている環境はいずれ、古くなっていきます。したがって、どんどんアップデートできる環境を構築することが大切です。その意味で、パッケージマネジャーはほぼ必須です。ほぼ全てのソフトウェアをbrewかmasで管理しています。できるだけ、古い技術に依存せず、どんどん新しいものに入れ替えていけることを目指しています。

何をやるか

大まかに何を開発するかによって異なります。目的に合った環境を作るのが大事です。

例えば、iOSを開発するのであれば、それをベースに組み立てます。iOS開発に必要なのは、Xcode, Ruby, brew, zshell, git, slack, sketchあたりからいろいろと入れると思います。

実際は、Xcode, SlackはApp Storeから。Sketchはbrew caskで、Rubyはrbenv,  zshellはbrew, gitはデフォルトか、brewから入れるという感じになります。

これらは管理下に置きたいので、インストールスクリプトを書いて、自動化します。

例えば、こんな感じです。

brew bundle --file=- <<EOF
brew "go"
brew "peco"
cask "1password"
cask "sketch"
mas "Xcode", id: 497799835
EOF

このようなスクリプトを用意することで、一括でインストールできるようになります。

他にいろいろやってる人はその都度、設定を追加していきます。手を広げている人はその分、大変になります。自分もなんだかんだで、色々と入れています。

何をやらないか

無駄に管理するのもコストがかかって大変なので、必要ないものは割り切って、use/local以下に入れてしまうのも手です。env系が必要なのはバージョンごとの挙動を試さないといけない場合なので、そこまで必要ない場合は、env系で管理せず、デフォルトのを使うか、brewで引っ張ってこれるのをそのまま使います。

あとはミニマリストではないですが、ラップトップの中くらいは、自分の管理できる範囲で運用するというのも手です。

ということで、必要ないものは極力入れないようにしよう。他のコマンドのオプションで代用できたりしないかなど、考えてみる。たまにはデフォルト厨になるのも手です。

E.g.) Curlを使って何が出来るのか。emacsの基本機能を調べてみるなど。

ちなみに最近、筆者はemacsを捨てました。笑

気をつけていること

何かをインストールした時は、それが一時的なものか、必要かを考えて、必要なら、どんどん自動化してます。設定のスクリプトまで自動挿入されるように準備しています。

ソフトウエアがどう作られてるかや、どう動くのかといったことを理解するのも重要です。分かればわかるほど、コンパクトにまとめられると思います。

最後に

ちなみに、自分のdotfilesはこちらに公開しております。

もし興味がありましたら、見てみてください。

具体的にどう構築しているかは、後日まとめるかもしれないです。

BR