ubuntuでログイン時のshellをfishに変更しようとした際にすこし詰まったのでメモ。
chsh -s $(which fish) コマンドでログイン時shellを変更しようとしたところ
chsh: PAM: Authentication failure
のエラーが。
ググったところ下記に解決方法が書いてありました。 github.com
sudo vim /etc/pam.d/chsh
で auth required pam_shells.so をコメントアウトし、
sudo chsh $USER -s $(which fish)
で変更。
RSpecを使っている中で、思った挙動をしない時があったので実行タイミングを確認してみたメモ。
下記のようなテストコードを実行してみました。
require 'rails_helper' RSpec.describe "実行タイミングを調べる" do puts '!!! describe' before do puts '[before] describe' end describe 'nest describe' do puts '!!! nest describe' before do puts '[before] nest describe' end it "nest example1" do puts '!!! nest example1' end it "nest example2" do puts '!!! nest example2' end end end # --- 実行結果 --- # !!! describe # !!! nest describe # # 実行タイミングを調べる # nest describe # [before] describe # [before] nest describe # !!! nest example1 # nest example1 # [before] describe # [before] nest describe # !!! nest example2 # nest example2
before や it は思ったとおりの挙動でしたが、describe 内のコードが before よりも前に実行されるのは意外でした。
一つ勉強になった。
⟩ ruby -v ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-darwin18] ⟩ bin/rspec -v Running via Spring preloader in process 54942 RSpec 3.9 - rspec-core 3.9.2 - rspec-expectations 3.9.2 - rspec-mocks 3.9.1 - rspec-rails 4.0.1 - rspec-support 3.9.3
先日、fzf.vimでGFilesコマンドが使えない問題に悩んでいたのですが、無事解決したのでメモ。
かなりニッチな問題ですが、予想外の箇所が影響しておりハマったので共有しておきます。
GFilesコマンドは、Gitで管理されたファイル(git ls-files)を対象にあいまい検索を行えるコマンドです。
このコマンドを実行したところ、エラーとなってしまいました。
:GFiles
function fzf#vim#gitfiles[6]..<SNR>82_fzf[18]..fzf#run[64]..<SNR>46_execute_term[73]..<SNR>46_dopopd の処理中にエラーが検出されました:
行 20:
E716: 辞書型にキーが存在しません: dir && (!&autochdir || w:fzf_pushd.bufname ==# bufname(''))
E15: 無効な式です: s:fzf_getcwd() ==# w:fzf_pushd.dir && (!&autochdir || w:fzf_pushd.bufname ==# bufname(''))
function fzf#vim#gitfiles の処理中にエラーが検出されました:
行 6:
E171: :endif がありません
続けるにはENTERを押すかコマンドを入力してください
色々検索したところ、本家のissues に同事象が記載されていました。 github.com
以下、引用
Everything works correctly, except :GFiles. When I run :GFiles from a git repo, I get:
Error detected while processing function fzf#vim#gitfiles[6]..
103_fzf[18]..fzf#run[64].. 27_execute_term[73].. 27_dopopd:
line 20:
E716: Key not present in Dictionary: dir
E15: Invalid expression: s:fzf_getcwd() ==# w:fzf_pushd.dir
Error detected while processing function fzf#vim#gitfiles:
line 6:
E171: Missing :endif
has any echo in your fish config?
remove that echo may be resolve the problem
shellにfishを利用している
かつ
~/.config/fish/config.fish内でechoコマンドを利用している
場合にこの事象が再現する旨のコメントがあり、まさにその状況でした。
執筆時点(2019/09/10)では issue Open の状態でした。
暫定対処として~/.config/fish/config.fish の echo コマンド記述部を削除したところ上手く動作しました。
エラーとなったとき、fzf vim GFiles errorなどで雑にググったのですが、似てるけど別の問題がヒットし、なかなかこのissueにたどり着けませんでした。
エラーのときは「まずは本家のissueを確認する」を徹底しよう、という学びを得ました。苦笑
Googleでの検索時、言語を日本語で検索していたのですが、英語に変更すると検索にヒットする記事が変わり、求めていた記事がトップに表示されました。 技術情報をを検索するときは言語設定を英語にしておくと良いかもしれません。
⟩ sw_vers ProductName: Mac OS X ProductVersion: 10.14.6 BuildVersion: 18G95
⟩ fish -v fish, version 3.0.2
⟩ nvim -v
NVIM v0.3.8
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/local/Homebrew/Library/Homebrew/shims/mac/super/clang -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/tmp/neovim-20190704-11886-1ukicoc/neovim-0.3.8/build/config -I/tmp/neovim-20190704-11886-1ukicoc/neovim-0.3.8/src -I/usr/local/include -I/usr/local/opt/gettext/include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include -I/tmp/neovim-20190704-11886-1ukicoc/neovim-0.3.8/build/src/nvim/auto -I/tmp/neovim-20190704-11886-1ukicoc/neovim-0.3.8/build/include
Compiled by brew@Mojave.local
Features: +acl +iconv +jemalloc +tui
See ":help feature-compile"
システム vimrc: "$VIM/sysinit.vim"
省略時の $VIM: "/usr/local/Cellar/neovim/0.3.8/share/nvim"
Run :checkhealth for more info
以下はSIer時代に、実体験をもとに書いた初心者向け記事なんですが、ありがたいことに今でもたくさんの方に読んでもらっています。
qiita.com
職業プログラマー目指して頑張っている人、初心者から次のステップに進みたい人が想像以上にたくさんいることを知り、
それならばと思い 脱初心者を目指すプログラマーにむけて、ぜひ読んでほしい書籍をピックアップしてみました。
を想定して、自分だったら何をすすめるだろう？という気持ちで選んでみました。
似たような記事はたくさんありますが、この記事の特徴は、
あたりが差別化ポイントかなと思っています。
そこそこ量があるので、目次をザッと眺めて、興味の湧いたところから読んでみてください。
初心者プログラマーの方たちに少しでも参考になれば嬉しいです。
理解しやすく、メンテナンスしやすいソースコードを書くためのノウハウが詰まった書籍。
名著であり、コードを書く際の共通認識となっています。プログラマーは絶対に読むべき本。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
Webサービスの実践的な設計をテーマとし、HTTPやURI,HTMLなどの仕様を歴史や設計思想を織り交ぜて解説しています。 組み込み系などを除くほとんどのプログラマーはWebを利用した開発に携わると思います。 なんとなくでプログラミングしているとどこかで頭打ちになるので、早いうちにWebについて体系立てて勉強しておくよいです。
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
変更に強いシステム設計について学べる書籍。 オブジェクト指向、(難解で有名な)ドメイン駆動設計(DDD)のエッセンスをサンプルコードを用いて分かりやすく解説してくれています。 この本を読めば良い設計の勘所がわかるようになり、脱初心者の足がかりになると思います。
現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法
UNIXを利用する人が最低限覚えておくべき内容を網羅的に解説した書籍。 プログラマーの仕事はWebアプリをコーディングするだけでなく、サービスを公開するためにサーバを操作する必要があります。 「黒い画面」と呼ばれ苦手意識をもつ人は多いですが（僕もそうでした）、基礎を学べば怖がるどころか強力な武器になると思います。
プログラマーは、広義な意味でほぼ間違いなくチームで行動します。
プログラミング技術だけでなく、メンバーとのコミュニケーション、立ち振舞い方がとても重要です。
エンジニアがチームで働く上で意識すべきことについて、Googleエンジニアがまとめた書籍。 「HRT」と呼ばれる、謙虚(Humility)、尊敬(Respect)、信頼(Trust) の3つの行動規範が特に有名。 「チーム文化のつくり方」から「有害な人への対処法」まで、エンジニアに求められる社会性について解説しています。 エンジニアリングチーム論の名著であり、ぜひ読んでほしい一冊です。
Team Geek ―Googleのギークたちはいかにしてチームを作るのか
サブタイトルにある通り、「部下を成長させるコミュニケーションの技法」についてまとめた書籍です。 昔と比べ個々のコミュニケーションを重要視するようになり、1on1を行う会社が増えてきたように思います。 上司（メンター）目線の書籍ですが、メンティーも1on1の在り方を理解しておくことで、得られるものが格段に変わってきます。 成長角度がグッと上がり、数年後の成長度合いがかなり変わってくるので若いうちから意識しておくと良いです。
ヤフーの1on1―――部下を成長させるコミュニケーションの技法
一つの経験からどれだけ多くのことを学び取れるかによって、その後の成長度合いが大きく変わってきます。
この成長力は、実は方法論を学ぶことによって高めることができます。言い換えると「正しく努力をする」スキルです。
がむしゃらに頑張るだけでなく、方法論を学んでさらに成長を加速させるのが成功の近道だと思っています。
たくさん読んだ中で、本当におすすめの2冊を紹介します。
成功するために必要なメンタルを作り出す方法についてまとめられた書籍。 よくある自己啓発の精神論/根性論とは異なり、心理学やNLPなど科学的根拠に基づいた極めてロジカルな方法論を学べます。 エンジニアにとても相性の良い本だと思いました。ぜひ読んでみてください。
メモを「記録」のためだけでなく、「知的生産」のツールとして使うことで成長スピードが劇的に高まるメモ術を学べる書籍。 "ファクト(事実) → 抽象化 → 転用" の流れでメモすることで思考が整理され、より深まり、たくさんのアイディアにつながります。 SHOWLOOM代表 前田裕二さん(@UGMD)の著書です。 DeNA在籍中に幸運にも社内イベントで生トークを拝見し、物腰の柔らかさとロジカルな思考、そして熱量の高さに圧倒されファンになりました。 サービスの仕様検討、課題の深堀りなど、なんにでも応用できます。絶対に読んでほしい1冊です。
メモの魔力 The Magic of Memos (NewsPicks Book)
長い人生の大半を占める「仕事」について、方針や戦略をきちんと立てるのは非常に大切なことだと思っています。 それらを考えるきっかけを与えてくれた書籍を紹介します。
エンジニアが「より良い人生」を送るためのノウハウ・スキルを網羅した人生マニュアルをまとめた書籍。 キャリアの築き方、自分の売り込み方、技術習得法、生産性の高め方から、財産の築き方まで、「人生より良く生きる方法」を具体的に説明します。 著者が海外のエンジニアなので時々文化の違いを読み替える必要がありますが、学校や会社では教えてくれない大切なノウハウが詰まっています。
年々平均寿命が伸び、誰もが100年生きる時代をどう生きるべきかについて書かれた書籍。 皆が足並みをそろえて教育、勤労、引退という3つのステージを生きた時代は終わり、生き方と働き方が大きく変わる時代が来ています。 なんとなく肌で感じていた時代の変化が的確に言語化されており、衝撃を受けるとともに、このタイミングで読んで本当に良かったと思いました。 エンジニアという比較的自由な働き方ができる職種を選んだ私達こそ、今後どう働くのかをしっかりイメージする必要があります。 なかなか分量のある書籍ですが、読む価値はあります。
お金や人生に対しての考え方や哲学を学べる書籍。 「お金とは？」「働くとは？」について深く考えさせられる一冊です。 社会人になり、家族を持って強く感じたのは、「正しいお金の知識」を学ぶことの重要さでした。 当たり前のように企業に属し、何も疑わずサラリーマンをしてきた中で、起業家の「金持ち父さん」の教えは新鮮で衝撃的でした。 前述のLIFE SHIFTにもあるように、今後働き方が多様化する時代の中で、「お金とは？」「働くとは？」をしっかり考え行動するのが大切だと感じています。
改訂版 金持ち父さん 貧乏父さん:アメリカの金持ちが教えてくれるお金の哲学 (単行本)
持論というと偉そうですが、「エンジニアは知識が商品」だと思っています。
「お金が勿体ないからググってやり過ごす」
「誰かが貸してくれたら読む」
「会社がお金を出してくれたら読む」
という人が時々いますが、とても勿体ないなと思います。
ググれるのは、自分の知っているキーワードの範疇であり、概念すら知らないものは検索できません。
優れたエンジニアほど、飲み屋で話題に上がった書籍をその場でポチッと購入している印象です。
「読書は投資、絶対にケチらない」を心がけています。
とはいえ技術書は特に高いので、
で節約したりします。
たくさん本を読んで、メキメキ成長する人が増えたらいいなと思っています。
アプリなどで読書ログをつけるのがオススメです。自分がどれだけ本を読んできたか可視化することで、
などの良いことがあります。
僕はブクログを使って読んだ本を管理しています。よかったら参考にしてみてください。
先日「リビングLT」と称し、自宅のリビングで家族に向けて家計改善のLTをしてみました。
チームビルディングやプレゼン資料の作り方など、仕事上のスキルをうまく使いながらやってみたところ、
手応えがあり家族にもなかなか好評だったのでまとめてみます。
（ちなみに妻は非エンジニアで、電化製品は何もしてないのに動かなくなってしまいがちなタイプの人です。）
以前から家計について課題感はあったものの、気をつけなきゃねーで終わってしまっていました。
しっかりと問題と向き合って解決するためのアクションを打つためには
を整理して、筋道を立てて共有しないと解決できないなと思い、それならいっそLT形式にしてみようかなと思い立ちました。
子供はまだ小さくお金を使うのは僕か妻のどちらか。
普通に話すと間違いなく "どちらのせいか？" と対立構造になってしまうのが想像でき、それは避けたいと思いました。
LT形式にして、問題を客観的に分析・アクションの提案をすることで、 "問題に立ち向かうチーム" 感を出してみました。
シリアスな感じにせず、誰かのせいにもせず、問題解決を家族でワイワイ楽しめたらいいなと考えました。
専業主婦の妻が、最近マクロビやファスティングなど食に関する講師になることを目指しており、スライドでセミナー資料をつくることに苦心していました。
(Web系のエンジニアは)こんな感じでスライド作ってるんだよ、というのを見せて少しでも参考になればいいなと思いやってみました。
上の子が4歳になり、いろんなことをものすごい勢いで吸収しているので、なんにでも応用できる「カイゼン」を家庭の中で学べたらいいなと思いました。
パパとママが面白そうなことやってるな、課題の解決ってなんだか楽しいんだなー、と思ってくれたら成功。
LT感を出すにはリビングのTVにスライドを映したい。
なるべく余計なものを購入せず、家にあるものでやるにはどうしたらいいかなと検討してみました。
その結果、すでに持っている「Amazon Fire TV Stick」に「AirReceiver」というアプリを入れ、MacBookからAirPlay経由でTVに出力することができました。
下記の記事がよくまとまっていたので、参考にしてみてください。5~10分あればできます。 ischool.co.jp
時間をかけずシンプルにスライドを作りたかったこと、妻との共有が簡単なこと、などからGoogleスライドを利用しました。 www.google.com
公式のiPhoneアプリがあり、通勤電車内でサクッと作ることができました。
スライド作成の基本ですが、必ず先にテキストで内容を整理することにしています。
いきなりスライドに手を付けてしまうと、レイアウトやフォントなど本質でないデザイン的な部分ばかりに時間が溶けてしまいます。（昔はよく陥ってました、、、）
普段からEvernoteを使ってテキストをまとめています。
あとは以下のことに気をつけながら、なるべくシンプルにつくることを心がけました。
ストーリーを意識する
出来上がったスライドはこちら。(具体的な数字は伏せています)
妻も子供も、面白がってきいてくれました。
シリアスにならず楽しく問題解決する、という点はクリアできました。
グラフを用いた現状分析のおかげで、ぼんやりだった課題感がしっかり伝わったようでした。 どうしていいか分からなかったのが、具体的なアクションに落とし込んだおかげで行動に移せるようになりました。
「こんなのサラッとつくれてすごいね！」と、妻からの尊敬ポイントがちょびっと上がりました。笑
妻や子供からすると、エンジニアのパパが普段どんな仕事をしているのか想像ついていないので
「パパはお仕事でこんなの作ったりするんだよ」というのが示せてよかったです。
4歳息子が、ぼくも発表する！と前に出てきて
「星座の絵本と、クワガタムシとカブトムシの絵本を作ります！」
と宣言してくれました。笑
ちょっとでも興味を持ってくれたようなので良かったです。
家庭の問題を、LT形式で楽しくカイゼンしていくことができました。
思った以上に良い手応えがあったので、ぜひ皆さんも試してみてください！
seqコマンドを利用する。
➤ mkdir hoge_(seq 1 5) ➤ ls hoge_1 hoge_2 hoge_3 hoge_4 hoge_5
0パディングしたいときはseq -f でformat指定できる。
➤ mkdir hoge_(seq -f %03g 1 5) ➤ ls hoge_001 hoge_002 hoge_003 hoge_004 hoge_005
※検証環境
➤ fish -v fish, version 3.0.2
bashでは{1..5}のようにブレース展開を利用して以下のように書けます。
➤ bash bash-3.2$ mkdir hoge_{1..5} bash-3.2$ ls hoge_1 hoge_2 hoge_3 hoge_4 hoge_5
fishではブレース展開は行われないため、同じコマンドを実行するを以下のようになってしまいます。
➤ mkdir hoge_{1..5} ➤ ls hoge_1..5
一つ勉強になりました。
iterm2で分割した画面(ペイン)を一時的に全体表示したい場面があり、ショートカットを調べたのでメモ。
対象ペインでShift + Command + Enter を入力すると全体表示されます。
でも同様に全体表示されます。
仕事でRubyを使うことになったので、勉強と情報収集のためshibuya.rbという社外勉強会に参加してきました。
Shibuya.rbは、渋谷近郊のRubyが好きだったり、 Rubyの周辺技術が気になっている人のための地域Rubyistコミュニティだそうです。
想像していた以上にゆるくて自由な雰囲気でした。笑
イベントページにも書いてあるように、テーマやセッションは特に決まっていないそうです。
最初に簡単な自己紹介をしあったのち、飲みたい人はビールで乾杯。
LTしたい人は好きに発表し、もくもくしたり、数人でディスカッションしたりしていました。
今回は15名くらいでした。
自分のように初心者・初参加の方から、RubyKaigiにCFP出すような方まで様々でした。
発表聞いていたら、いつも読んでる技術ブログの著者が発表していてびっくり。
勉強になる、とツイートしたばかり、、、
すごく良い習慣。英語苦手なので真似してみようと思いました。 / “Rails の Issue とプルリクを毎日読むと勉強になる - アジャイルSEの憂鬱” https://t.co/ofjOatJtxv
— Shogo Mizuno (@nesheep5) 2018年2月12日
エンジニア界は狭いですね、、、。
自由過ぎて何してよいかわからず、周りのレベル高い会話に聞き耳を立てながらぼんやりしてました。苦笑
優しい方々が話しかけてきてくれたので、自分の状況（Ruby初心者、Javaは10年くらい）を伝えた上で、色々と相談に乗ってもらいました。
以下の三冊を薦めてもらいました。
チェリー本はちょうど最近読んだばかり。やはり良い本でした。
Everyday Railsだけ持っていないので、さっそく買ってみようと思います。
改訂版がでたばかりなので良いタイミングですね！
エディタについては宗教戦争になるのでコメントを控えますとのこと。苦笑
相談した方の会社でもみんなバラバラです、とのことでした。
自分は最初Vimで、現在Atom使っています。RubyMineがどれくらい便利なのか気になっているところ。
技術書読むのも大切だけど、実際にコードを読み書きするのが一番、とのことでした。
初心者にも優しく接してくれる、アットホームな勉強会でした。
レベルの高い人たち同士の会話を聞くだけでも勉強になるし、刺激を受けます。
次回はもう少し技術的な質問もできるように、しっかり勉強を続けていきたいと思いました！
Ruby入門中です。今日はStructクラスについて調べました。
一言で言うと、クラスより簡単に構造体を作成する仕組みです。
docs.ruby-lang.org
Struct.newで引数に渡したシンボルに対応するメンバとアクセサメソッドを持つクラスを生成します。
# 気温情報を持つ構造化データ Temperature = Struct.new(:date, :high, :low) temp = Temperature.new('2018/01/01', 8.0, 0.5) temp.high # => 8.0
ブロックを利用することでメソッドを定義することも可能です。
Temperature = Struct.new(:date, :high, :low) do def mean (high + low) / 2.0 end end
構造化データを用意する際、Hash、Class、Structあたりが選択肢となります。
以下のような時にStructクラスを利用すると良さそうです。
以下、Hashを利用した場合とStructを利用した場合の比較サンプルソースです。
require 'csv' # --- Hashを利用した年間気温クラス class AnnualWeatherWithHash def initialize(file_name) @readings = [] CSV.foreach(file_name, headers: true) do |row| @readings << { date: Date.parse(row[2]), high: row[10].to_f, low: row[11].to_f, } end end # 平均気温 def mean return 0.0 if @readings.size.zero? total = @readings.reduce(0.0) do |sum, reading| sum + (reading[:high] + reading[:low]) / 2.0 end total / @readings.size.to_f end end # --- Structを利用した年間気温クラス class AnnualWeatherWithStruct # Structを作成しReading定数に保持 Reading = Struct.new(:date, :high, :low) do def mean # ブロックでメソッド定義することも可能 (high + low) /2.0 end end def initialize(file_name) @readings = [] CSV.foreach(file_name, headers: true) do |row| # Reading定数をクラスのように利用することができる @readings << Reading.new(Date.parse(row[2]), row[10].to_f, row[11].to_f) end end # 平均気温 def mean return 0.0 if @readings.size.zero? total = @readings.reduce(0.0) { |sum, reading| sum + reading.mean } total / @readings.size.to_f end end
