https://raw.githubusercontent.com/briancain/vagrant/fb4e6985e142da56bad143d70600cd3695c91757/plugins/providers/virtualbox/driver/version_6_1.rb実行後、念の為パーミッションやオーナーが他のファイルと同じになっているか確認してください。version_6_1.rbこれで、エラーが解消されました。同じ事象に悩んでいる方は参考にしていただければ幸いです。新年明けましておめでとうございます。そのまま新卒でIT業界に飛び込んだため、基本的な知識は業務上身につけていますが、体系的にコンピューターサイエンスを学ぶ機会がありませんでした。私現在ではオンラインで卒業できる大学院や、edX、Udacityなどの大規模オンライン講座(MOOC)により、ハーバードやMITなどの一流大学の良質な講義を無償で受けることもできるようになりました。JAISTやAIITなどでは社会人でも入学しやすい社会人コースを設けており、働きながらでもコンピューターサイエンスを学ぶことが容易になってきました。文系のITエンジニアだったとしても、やる気と時間さえあればいつでもコンピュータサイエンスを学ぶことができる素晴らしい環境にいるわけです。前述したとおり現在ではさまざまな「学び方」がありますが、「どこから手を付けたらいいのかわからない」「コースが多すぎて混乱する」という方もいるかと思います。University)」というプロジェクトについてご紹介します。OSSUとは?OSSUとは、オンライン上の教材を利用してコンピューターサイエンスを自己学習するためのプロジェクトです。edXやcorsera、Youtubeなどのオンラインの教材を組み合わせ、体系的にコンピューターサイエンスを学ぶことができるようになっています。github.comどうやって学習するのかOSSUのGitHubにある「Curriculum」に沿って学習を進めていきます。CS」からスタートするのがよいでしょう。CS」から始めることもできます。始めるコースを決めたら、あとはカリキュラムに書かれている「Duration」や「Effort」の時間を目安に、学習を進めていきます。Data」であれば、edX上で提供されているコースなので、edXでEnrollし学習を進めます。コースでの学習が完了したら、カリキュラムで指定されている次のコースに進みます。詳細なコースの一覧については、GitHubのページを参照してください。GitHub学習すると何が得られるのかedXや各種サービスに散らばっているコンピューターサイエンスの教材を基礎から進めていくことができるため、無料で体系的にコンピューターサイエンスを学ぶことができます。「コンピューターサイエンスをどう学んだらよいかわからない」という方で、英語に抵抗がないのであればぜひ活用してみてください。学位が欲しい一緒に学ぶ仲間がほしい日本語でコンピューターサイエンスを学びたい学習の方法にはそれぞれ向き、不向きがありますので、自分にとってどのような方法が良いのか、考えながら学習スタイルを決めると良いと思います。私もこれから地道にOSSUの学習を進めていきつつ、学習レポートなども定期的にアップできればと思います。ロードバイク納車2020年、明けましておめでとうございます。今年も宜しくお願いいたします。私のTwitterをフォローしている方はご存知だと思いますが、ロードバイクにハマり、遅いながらも週末にロングライドに出掛けたり、Zwiftでバーチャルライドを楽しんだりしています。2020年はじめての投稿は、そのロードバイクを購入した経緯と、「ひよこ大佐、新宿で立ち往生」事件についてお話したいと思います。転職をきっかけにロードバイクを購入することになるのですが、ロードバイクが欲しいと思ったのはこれがはじめてではありません。中高生のころにルイガノのTR1という安いクロスバイクに乗っていたので、スポーツバイク自体は経験がありました。ロードバイクは「細いタイヤで怖い」「スポーツ志向の人が乗るもの」というイメージがあり、価格の高さもあってずっと手を出せませんでした。転職を機に、いままでずっと気になっていたけれども手を出せなかったロードバイクを買いたい!という気持ちが強くなりました。自分自身はとんでもなく運動音痴で、走れば常にビリ、体育の授業は本当に嫌いで、高校の部活で1年くらいテニスをしていた程度で、社会人になってからはことさら運動とはほとんど無縁でしたが、自転車で走ること自体は好きだったので、いつかその自転車の最先端であるロードバイクには乗ってみたいとずっと思っていました。ALR5のマット塗装の美しさに一目惚れしてしまい、その日のうちに六本木のTREKショップで思い切って購入しました。18万ぐらいしたと思います。ALR5ただ、ロードバイクを買えばそれで終わりではありません。「他にも揃えないといけませんよ」と店員さんに言われ、サイクルコンピューターとサドルバッグとライトはBontragerのものを購入しました。ペダルとヘルメット、ポンプや工具類はTREKで買うと高かったので、Amazonで揃えました。PWTの工具は安くてそこそこ使えるのでオススメです。転職したばかりだったのでロードバイクとその他もろもろを合わせて20万の出費は痛かったですが、初めて納車された瞬間は「ああ、このカッコいいロードバイクが自分のものになるんだ」と感動したのを覚えています。納車初日、そしてはじめてのパンク2018年4月、TREK六本木で無事にエモンダを受け取りました。乗り出すと、クロスバイクと比較にならないほどスイスイ進むロードバイクに感動しながら、40km近く離れた埼玉の自宅を目指し走り始めました。慣れない道で迷ったりしながらも、新宿に着くまでは比較的順調な道のりでした。事件は新宿で起きました。大通りを右折したところで「あれ?進まないな」と思い、タイヤを見てみると後輪がペシャンコになっていました。路肩のガラス片か何かを踏んでしまったようで、完全にパンクしてしまっていました。パンク修理キットは持っていたので、とりあえず自力で交換をしようとスマホで手順を調べながらおそるおそる作業をはじてました。パンク修理、うまくタイヤを外してチューブを入れ替えることができません。30分ほど格闘しますが、外れる気配もなく、全くどうにもなりません。「もうこれはプロに頼むしかない」とGoogleで自転車店を探すと、まだ閉店していないスポーツサイクルショップの大手Y店がヒットしました。「これでなんとかなるかもしれない」と店の前まで押して歩き、店のドアを開けると店員さんに怪訝な顔をされてしまいました。めげずにパンク修理をお願いできるか聞いてみたところ、「いやーあと30分で閉店するので無理ですね」とあっさり断られてしまいました。結局店を追い出されてしまい、状況はまた振り出しに戻ってしまいます。頼みの綱のY店に断られ、今から六本木に戻ることもできず、夜9時過ぎに新宿のど真ん中で、走れないロードバイクを抱えたまま僕は途方にくれてしまいました。家まではまだ30km以上あります。その時は鍵もないので、駐輪場に置いて電車で帰ることもできません。輪行袋なんか持ってないので、電車やタクシーに載せて帰ることもできません。それでも何とか家にたどり着かなければ、明日の仕事にも行けなくなってしまいます。そのためには、どうにかしてパンクを直す必要がありました。空いている自転車店はないかと必死にGoogleマップを調べたら、たった1軒だけ、小さな自転車店が営業中になっていました。「これでだめなら自宅まで30km歩くしかない」と祈るような気持ちで電話を掛けたら、店主の方に「もうそろそろ閉店するけど、修理するからとりあえず持っておいで」と言われ、思わず泣きながら「すぐいきます!」と叫びました。1kmほど離れた店まで自転車を担いで走り、すぐにパンクを直していただけました。夜遅くに嫌な顔せずに修理してくれたうえ、温かい声をかけていただいた「プロジェクト・エス」の店主の方には本当に今でも感謝しています。プロジェクト・エス結局18時過ぎには六本木のショップを出発したのに、家についたのは23時過ぎでした。何度も坂で脚が攣り、お尻が痛くなり、ヘトヘトになりながらなんとか帰宅し、「絶対にパンク修理を練習しよう」と心に誓いました。して無事(?)ロードバイクを入手する流れとなりました。2019」14日目の記事です。qiita.comどうも、ひよこ大佐です。今回も役に立ちそうで役に立たない、でもちょっとだけ役に立つAnsibleの小ネタをご紹介します。ないよという方は考えてみてください。あるんですよ!なので、今日はそんなときにとても役に立つモジュールをご紹介します。github_issue「github_issue」モジュールは、特定のGitHubのIssueの状況を確認できます。以下のように指定することで、registerに指定した変数にGitHubのIssueの情報を格納することができます。}}"パラメーターに、参照するリポジトリやIssueの番号を指定します。今回は私が作成してまだOpen状態になっている以下のIssueを参照してみます。github.com「action」パラメーターは、「get_status」以外にもいろいろ指定できそうな雰囲気を醸していますが、現時点では「get_status」しか指定できません。そのうち新しい機能が追加される可能性もあるので、楽しみに待ちましょう。実行するでは、実際に実行した結果を確認してみましょう。「issue_status」が「open」となっているので、現在このIssueがOpenであることがわかります。このステータスをもとに、後続のタスクの条件分岐させたい場合などに活用できます。現時点では、そのIssueがOpenかClosedのどちらかであることしかわからないので、今後の機能拡張次第ではより有用なモジュールになると思われますので、今後に期待しましょう。2019」13日目の記事です。qiita.comどうも、ひよこ大佐です。昨日に引き続き小ネタ風味のネタですが、今回はもう少しだけ役に立つモジュールを紹介します。WindowsをターゲットにPlaybookを実行して再起動を実施するようなシチュエーションで、もしログインしているユーザーがいる場合に備えてログアウトするように通知を流したいというケースがあります。今回は、そのような場合に使えるモジュールを紹介します。Windowsホストにメッセージを表示するモジュールは2種類あります。win_msgwin_toastそれぞれ若干挙動が違います。win_msgこのモジュールは、ダイアログとして指定したメッセージをポップアップ表示させます。以下のようなテスト用のPlaybookを作成し、実行してみましょう。"本日19時よりメンテナンスのため、このマシンは再起動されます。19時までに作業ファイルを保存し、ログアウトしてください。"上記Playbookを実行すると、以下のようにダイアログが表示されます。作業中でも気が付きやすいので、個人的にはこちらを利用するのがおすすめです。win_toastこちらもWindowsホストへメッセージを通知するモジュールですが、表示される通知の種類が異なります。Server2016で利用できる「トースト通知」として送信されます。以下のようなPlaybookを作成します。記述内容はwin_msgモジュールと似ていますが、「async」を指定しないとexpireするまでタスクの実行が進まなくなるので、必ずasyncと組み合わせて利用してください。"本日19時よりメンテナンスのため、このマシンは再起動されます。19時までに作業ファイルを保存し、ログアウトしてください。0こちらのPlaybookを実行すると、以下のように通知されます。2019では正常に通知されませんでした。お使いの環境によっては正常に動作しない可能性がありますので注意が必要です。ちなみにコミュニティモジュールなので、レッドハットによるサポートを受けられるモジュールではありません。実際のメンテナンス作業では、明確なメンテナンス時間を設けてログインができないようにアクセスを遮断する運用もありますが、Windowsではそういった運用が難しいケースもあります。その場合は、メンテナンスを周知することと併せて上記のようなポップアップを表示させることで、不要な社内からのクレームを回避することができます。2019」12日目の記事です。本格的な冬が始まる12月、めっきり寒くなっていまい、家から出たくないという方も多いのではないでしょうか。私もあまりの寒さに趣味のロードバイクも全然乗れていません。そんな日には、ブログを書くに限ります。今回は、役に立ちそうで役に立たない、でもちょっとだけ役に立つAnsibleの小ネタをご紹介します。皆様は、「cowsay」はご存知でしょうか。こんな感じのかわいい牛の絵文字が表示されます。||Ansibleでは、cowsayコマンドが有効な環境では、デフォルトでcowsayによる表示がされます。cowsayによる表示を有効化したい場合は、cowsayをインストールするだけで有効化されます。ignored=0「なんじゃこりゃ」と思った方、安心してください。オフにすることもできます。/etc/ansible/ansible.cfgを見ると、以下のセクションがあります。1を記述することでcowsayによる表示を無効化することができます。有効化すると、こんな感じで牛以外のなにかがランダムに表示されたりします。ignored=0正直使いどころはあまり(まったく?)ありませんが、日々の業務に疲れた方はぜひ有効化してみて、かわいい牛さんに癒やされてください。以上、ちょっとしたAnsibleの小ネタでした。00:38【小ネタ】Ansibleでcowsayを有効化/無効化するTweet広告を非表示にするもっと読むコメントを書く2019-12-01『Ansible構築・運用ガイドブック』が発売されましたどうも、ひよこ大佐です。インフラ自動化のための現場のノウハウ』が出版されました。Amazonやその他書店でお買い求めいただけます。この本を書いてみて思ったこと今回、はじめて技術書を、しかも単著で書くことになり、書き始めた当初は想像もしなかったさまざまな苦労や学びがありました。いろいろな方にご迷惑をおかけし、もしかしたら今の自分の能力では書き上げることは無理かもしれないと何度も心が折れそうになりましたが、なんとか実際に本の形となりました。自分が書き上げたものが、本として皆様のお手元に届けられるようになったことは大変嬉しく思います。今回の記事では、そんな技術書を書き上げるという経験から得られたものを皆様にフィードバックできればと思います。技術書をどのように書くか「技術書」と一口に言っても、その内容はさまざまです。Code』のような概念を説明したもの、どちらかというと自己啓発に近い本まで、多種多様なIT技術書が毎月たくさん出版されています。最近では技術書典などで同人誌として技術書を書く方もたくさんいますので、従来の「商業における技術書」と異なる新しい形態の「技術書」もどんどん生み出されています。そのなかで、「どういった技術書にするべきか」は作者の一存に委ねられています。「Ansible」というトピックにフォーカスしても、「Ansibleそのものの使い方の説明」「Ansibleを組織に導入するための課題の解決」など、いくつもの切り口があります。その中から「どういう本にしたいのか」をしっかりと意識していないと、本当に書きたいものが書けなくなってしまいます。「自分がこの本で何を読者に伝えたいのか」ということを、常に執筆中は意識しておく必要があります。華美な日本語ではなく、わかりやすさに徹するもともと大学で4年間クリエイティブライティングという学問を専攻し、「書くこと」について人より向き合ってきたという自負がありましたが、今回1冊の技術書を書くにあたってあらたに学ぶことが沢山ありました。「わかりやすい文を書く」という難しさは、技術書を書くうえで何度も直面しました。※気がついたら大学のページでも私が本を出版したことが紹介されているようです。大学の先生方には在学中大変お世話になりました。www.tais.ac.jp日本語は曖昧な言語であるとよく言われますが、曖昧な表現で書き進めていても、書いている本人はそれが曖昧な表現だということに気づけません。筆者の頭の中には書くべき「全体像」があり、それを文章として落とし込む作業をしています。多少意味が通らないような表現や何を指しているかわからない表現があったとしても、自分の書いた文章であれば無意識に補完して読み進めることができてしまいます。私が査読で指摘されるまで全く違和感がないまま書いてしまった曖昧な表現は多々ありました。小説でももちろん悪文はありますが、ある程度の決まりごとを守っていれば自由に記述することができます。技術書のような「情報を正確に読み手に伝えるための文章」では、華美なレトリックや独特の言い回しで個性を出そうとするよりも、「読みやすさ」を重視した平易な表現を中心にするほうがより多くの読者に受け入れられやすいものになります。これはブログなどでも同様で、無意味に思わせぶりな表現だったり、少しかっこつけた文章よりも、誰でも理解できるような文章で書いたもののほうがスッと頭の中に入ってきます。どのような表現を使っても筆者の自由ではあるのですが、読みにくい文章はそれだけで「作品」の価値を毀損してしまいます。技術的な文章をわかりやすく説明するには、「誰がこの文章を読むのか」「何も知らない人がこの文章を読んだ時に、迷うような箇所はないか」というポイントを、原稿を書き終わって一息ついたあとにチェックすることのが重要です。これは自分でチェックするのももちろん有効ですが、もし周りに査読してもらえるようなエンジニアがいれば、他人に一度読んでもらうことで自分では気が付かなかった「不親切」な部分に気づくことができます。商業出版では日本語のプロフェッショナルである「編集者」の方の協力を得ることができますので、どうしても表現したいことがうまく書けない場合は、編集者と相談しながら進めるのもよいでしょう。技術書を書くのは、トピックに対する知識も大事なのですが、「わかりやすく書く能力」というのも実は非常に重要です。技術書はブログ記事と違い、ひとつひとつの章は分離しているようで完全には別れておらず、最初から最後まで繋がっているひとつの「作品」のようなものです。多くの読者が頭から読み始め、最後まで読みすすめていくことを考えると、「本の起承転結」は小説だけでなく技術書であっても重要だと気づかされました。単純なトピックごとで章を分けるのではなく、前半の問題提起、それに対する「Ansible」という解決策の提示、といった本そのもののストーリーの流れを考えつつ執筆する必要性に気がついたのは、執筆を始めてからしばらく時間が経ってからでした。これは前述した「技術書をどのように書くか」という部分にも繋がってくるのですが、誰かに何かを伝えるには、「伝えたい内容」を明確にしたうえで、それをストーリーとして構築したものを提起しないと、ただ情報を羅列しただけのものになっています。時間に余裕などない初めての技術書ですし、できるだけ詳しいものを書こうとしていたのですが、とにかく時間がありませんでした。よいものを作ろうとするあまり締切に終われ、結果編集の方や査読に協力いただいた方にも多大なご迷惑をかけてしまいました。今回の執筆でもっとも反省するべきところです。「もっと時間があれば」と今でも考えますが、仮にもう1年あったとしても、まったく同じことを思うでしょう。出版までの時間は有限で、趣味で書いているものではない以上、どこかのポイントで「完成」とすべきなのです。「限られた期限でどこまで書けるか」という想定を書き始める前から持っておかないと、延々と完成しない文章をひたすら書き続けることになってしまいます。最後に技術書典などが盛り上がりを見せる昨今、「技術書を書く」ことは特別なものではなくなってきました。多くの人がより技術について文章で説明する能力を求められることが多くなってくるでしょう。技術書を書くのは本当に楽しいことです。私もあれだけしんどいと思いながら原稿を書いていたのですが、一息ついたらまたなにか本を書きたいと思うようになっていました(出版社の方、ご連絡お待ちしております)。来年の「技術書典8」もエントリーしていますので、こういった「技術を文章で説明する」ことをライフワークとして継続的にやっていければいいなと思っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。