Make組ブログ

Python、Webアプリや製品・サービス開発についてhirokikyが書きます。

Ubuntu 18.04 をインストールして「grub-efi-amd64-signedパッケージを/target/にインストールするのに失敗しました」で落ちる

Ubuntu 18.04 を Windows 10 とデュアルブートしようと設定しているときに grub-efi-amd64-signedパッケージを/target/にインストールするのに失敗しました というエレーが発生してインストールできなかった。

2018-07-17時点での話。

解決した方法

Wifiを設定せずにインストール。

サードパーティ製パッケージのインストールは有効で、セキュアブートは無効にしていた。 パーティションはマニュアルで設定したけど、とくに普通のext4/ と、スワップを設定したのみ。

なぜか知らないけどこれでうまくいった。 Wifiをつなぐとインストーラーやらが最新になって何かしらのバグを踏むとかなのだろうか。。。

見た情報、試した方法(でも解決にはならなかった情報)

/boot/efi パーティションを自作して解決する方法はうまくいかず。 Windows Boot Managerと場所が被るとかで設定できなかった。

www.geek.sc

VMUbuntuは入れなかった

やっぱりデュアルブートにしたかった。 WindowsをホストマシンにしてVMでプログラミング環境をUbuntuで起動しても良いのだけど、 やっぱりWindowsを使うというのが苦痛で仕方なかったのでデュアルブートすることにした。

factory-boyとDjangoでテストを書くときにファイルをうまく使う

ORMってファイルが入ると途端にめんどくさくなるよね。

まして単体テストで都度物理的なファイルを扱ったりするのはもうめんどくさすぎます。 でも factory-boy を使えばDjangoのFileFieldやImageFieldも楽に使えます。

バージョン

factory-boy==2.11.1 でやってます。

使い方

こんな感じで ImageField を持ったモデルで説明します。

from django.db import models


class Book(models.Model):
    cover_image = models.ImageField("カバー画像", ...)

factory-boyをこんな感じで書きます。 factory.django.ImageField を設定しておきます。

import factory


class BookFactory(factory.django.DjangoModelFactory):
    cover_image = factory.django.ImageField()

    class Meta:
        model = models.Book

そうすれば cover_image__ のように __ に続いて指定できます。 この例だと自動で作る画像の色とファイルの名前、サイズ、画像の拡張子を指定しています。

        book = BookFactory(
            cover_image__color='green',
            cover_image__format='PNG',
            cover_image__height=10,
            cover_image__width=10,
            cover_image__filename='test.png',
        )

いちいち物理的なファイルやら django.core.files.base.ContentFile やらも使わずに書けて便利。 この factory.django.ImageField__init__ に渡せる引数を、 __ 経由で渡せるようです。

Using factory_boy with ORMs — Factory Boy latest documentation

factory.django.FileField の場合は __data でバイナリーを指定できます。 すごく便利。

factory-boyについてはPythonプロフェッショナルプログラミングの14章にも書いたのでぜひ読んでみてください。

Pythonプロフェッショナルプログラミング 第3版

Pythonプロフェッショナルプログラミング 第3版

AWS上のデプロイ用インスタンスからPackerでAMIビルドしたらPackerBuilderにSSHできない問題を解決した話

Packer が好きで使ってます。 AWSのAMIをビルドするために使ってるんですが、そこであった話。

構成

デプロイ用のインスタンスから packer build してAMIを作る。

  • PackerBuilderには既存のSecurityGroup(セキュリティグループ)を指定する
  • PackerBuilderはPublicAccessを受け付ける
  • ParkerBuilderには既存のSSHキーペアを指定する

この既存のSecurityGroupは「デフォルト」のSecurityGroupで、このSecurityGroup自身からのアクセスを受け付けるようにしています。 デプロイ用のインスタンスも、PackerBuilderも同じSecurityGroupに所属させることでアクセスを許可しようという狙いです。

起こったこと

packer build 中にSSH接続できない

原因と理由

PackerはデフォルトでパブリックIPを使って接続しようとしていたのが原因(PackerBuilderでPublicAccessを受け付けるようにしていたからかな)。 SecurityGroupは パブリックIPを通して接続すると、「特定のSecurityGroupからのアクセス」と特定できなくなってしまう ので、単なる外部アクセスと判断されてSSHが拒否されていた。

ローカルIPを直接使うか、パブリックDNS(Public DNS)を使えば、EC2インスタンス上からIPを引けばローカルIPが取得できるのでアクセスできる (正しく特定のSecurityGroupからアクセスがあったと判断してもらえる)。

解決方法

packer.json"ssh_interface": "public_dns" を指定して、パブリックDNSを使ってSSH接続するようにした。

  "builders": [
    {
      "type": "amazon-ebs",
      ...
      "associate_public_ip_address": true,
      "security_group_ids": ["<デフォルトSecurityGroup>"],
      "ssh_keypair_name": "...",
      "ssh_private_key_file": "...",
      "ssh_interface": "public_dns"
    },
  ]

Amazon EBS - Builders - Packer by HashiCorp

デプロイサーバー上でパブリックDNSを引けばローカルIPが引けるので問題なし。 まぁ、 "local_ip" を指定してもいいんだけど。

Packerのデバッグ方法

Packerのログを見るときはPACKER_LOG=1 をつけて実行すると良い。 実行している内容とかが標準出力ででる。

$ PACKER_LOG=1 packer build ...

あと packer build -debug ... とオプションを付ければステップ実行できる。 便利よ。

$ PACKER_LOG=1 packer build -debug ...

www.packer.io

動かないときは色々試す前に原因見つけような! ログがしょっぱいツールとかシステムのときは仕方ないけどね。

結構ハマったって話

デプロイサーバー上からもローカルからもPackerBuilderにSSHできるので原因が分からなかった。 デバッグ出力するとどうやらパブリックIPでつないでいるようだったので、これが原因だとわかった。

SecurityGroupはローカルIPで繋がないと、「SecurityGroupからアクセスがあった」と特定できないっていうのは気をつけないとね。

自宅の開発環境(オフィス)を整備した話、机とかキーボードとか

自宅の開発環境を整備したので、そのお話をします。 わりと個人的な話ですが、買った机などは読んだ人が買うときの参考になれば嬉しいです。

なんで自宅の環境を整備しようと思ったか

貯蓄と資産運用のおかげもあって、ある程度まとまったお金ができました。 開業資金として最低限の目標としていた額に達して、もう少し資金など準備しつつ、あとは良い時期に良い感じに会社を作れたらなぁという次第です (そこは今の環境で学べることなどを加味して時期を決めれば良い)。

なので単に資産として持っておく以外に、お金を使っていこうかなと考えた次第です。

自宅の開発環境、使う?

会社のオフィスで働いていれば、それほど自宅の開発環境は使わないと思います。 良い環境がほしいときも、コワーキングスペースやカフェにいけば十分と思います。

ですが、僕の働いている BeProud ではリモートワークが週5でできます 。 であれば、自宅の環境をガツンと整備してより仕事をしやすくするのは悪くないと思います。

jobs.beproud.jp

僕は自宅でもプログラミングの機会はかなり多いです。 BeProudと関係ないサイドプロジェクトや、OSS活動、資産運用と、プログラミング・デスクワークになる機会はかなり多いです。 将来的に自宅を事務所にする場合にも、環境が整備済みであれば導入も楽ですしね (こう言っていると物欲を満たす言い訳をしているようですが。。)。

また、日常触れる、使う機会が多いものにお金を使うほど満足度が大きいらしいです。

どんな物にお金をまわす のかというと、シンプルに「毎日・長時間使う物」で いい。 科学的 にも「 毎日長時間 使う物にお金を多く使ったほうが幸福度が高い( = コンフォート 原則)」 ことが立証されている。

ミニマリストしぶ. 手ぶらで生きる。見栄と財布を捨てて、自由になる50の方法 (Kindle Locations 1112-1115). サンクチュアリ出版. Kindle Edition.

手ぶらで生きる。見栄と財布を捨てて、自由になる50の方法

貧乏性なので何かにつけて「そんなん要らんでしょ」と渋りガチなので、こういうとこはガツンと使っていこうと思っています。 ついでに部屋にあった要らないものを捨てたり、デスクの配置換えをして最適化しています。

整備した自宅の環境

デスクまわりの環境はこんな感じです (昔VIPとかであった部屋画像スレっぽいですが。。)。

f:id:hirokiky:20180528163914j:plain

キーボード: Barocco

買いました。初めて使う分割キーボードですが、かなり良いです。 思った以上に肩が楽です。 ErgoDoxとかは値段が高いので、肩こりひどいし分割キーボードどうかなぁ、って人はこのMistel Baroccoで良さそうです。 (キー配列も普通のキーボードのように斜めにズレているので、違和感もなく慣れました)。

僕はHappyHackingKeyboardを良く使っていましたが、使い勝手も良いです。 赤軸というものを使っていますが、タイプ感も良いです。

僕はDvorak配列なので、ハードウェアでDvorakにできるのは安心です。 とはいえ、ソフト側でDvorakにしているのでキーボードはQwerty配列のままです。 新しいVMに接続したときなどはハードウェアでのDvorak配列が活躍してくれるかなと期待しています。

トラックボール: SlimBlade

買いました。LogitechのMarbleMouseというトラックボールを5,6年使っていたので、これも新しいものにしました。 使い勝手はかなり良いですね。最初、独自のスクロールの方法(ボールを横に回す)に慣れませんでしたが、慣れれば使いやすいです。

まぁトラックボールについては投資というよりも、単に欲しかったので買っただけです。

買いました。 幅120cmで、高さが70cm程度ある机を探していました。 探してみると目的にあう机というのは意外となくて苦労しましたが、この机はオススメします。

このポイントを満たす机を探していました:

  • 引き出しがない => 膝が当たらない
  • 大きさが十分ある => 横120cmはほしい
  • 木製で、表面に加工がされている(ガラスは重い)
  • 足が4本の支柱でなく手前側に空間がある
  • 足が木の板でない
    • 無駄に重い
    • 机の横のラックが使いにくくなる
  • 背面に鉄板がついている
    • 強度が安心
    • OAタップが磁石で貼り付けられてスッキリする
  • 1万円程度

意外と、条件を満たす机はないです。3時間くらいずっと探してました。 今の僕ならオフィス用品、デスク環境コンサルにもなれるんじゃないでしょうか。

デスクの広さは言ってしまえばメモリーの量みたいなもんかもしれませんね。メモリー16GBは最低ほしいというなら、デスク幅120cmは最低ほしいところです。 メモリーもデスクも費用対効果が良いので大きくて損はないと思います。

OAタップはコレを買いました。磁石で貼り付くのでスッキリして良いです。

以前からあったもの

  • Bose Sound Link Mini 2: 音楽聴きながら仕事したいので良いです
  • 新しい新しいiPadとApplePencil: アナログノート大好きなので良いです
  • BenQのモニター: 安くて最高
  • MacbookPro(会社支給)

椅子

f:id:hirokiky:20180528164025j:plain

買いました。椅子については悩みに悩みましたが、リクライニング機能があることに重点を置きました。 僕の中で「エルゴノミクス vs リクライニング」という壮大なバトルが勃発しましたが、動画を寝転んでみたりリラックスしたかったのでリクライニングできるものにしました。

この商品にはかなり満足しています。 ですが、仕事でごりごりキータイプするとなると姿勢は崩れがちです。 寝るようにしてコードを書くか、椅子の上であぐらをかいて軽く猫背になるかどうかという姿勢です。

これについてはエルゴノミクスチェアー的なのを買えばよかったかなぁと少し思っています。 (良さそうなのは8万円とか10万円とかでひよったというのもある。。)。

椅子の材質はメッシュにしました。 合皮は加水分解してボロボロになるというのが、BeProudのオフィスの椅子で分かっていたのでメッシュです。

ホワイトボード

f:id:hirokiky:20180528163933j:plain

これは以前から自宅にあったものですが、 AmazonでB級品として買った安いホワイトボード です。 1200x900と大きいですし、重さが5kgあるので壁につけるのは少し苦労します。

ですが、ホワイトボードは大きいほうが良いです。 ホワイトボードは大きければ大きいほど発想も大きくなります。 部屋の壁全面ホワイトボードでも良いです。

壁に貼るホワイトボードシート的なやつはオススメしません。 すぐ汚れが落ちなくなりますし、書きにくいです。一回試しましたが、すぐに汚れが取れなくなったので捨てました。 それなりなホワイトボードを買いましょう。

超どうでも良いですが、ホワイトボードマーカーとイレーザーはこれを使っています。

僕はけっこうアナログ人間っぽいので、手書きのノートとかホワイトボードがあると発想が湧きやすくなる気がします。

おわりに

こんな感じで、自宅開発環境を整備したよっていう話でした。 今回使ったお金は全部で5万円ほどでした。自分なりにかなり気合を入れたわりには安く抑えた印象です (モニターアームと縦置きディスプレイも買いましょうか)。

もし 「これもオススメだよ」、「椅子コレ使ってるよ」とかあったら教えてください

感触としてはかなり良かったなという印象です。我ながらうまくやったと思うのは、事前の検討、採寸をちゃんとしたことです。 机のサイズ、椅子のサイズ、部屋のサイズや空間の配置方法などを、ある程度決めてから買いました。 おかげでほぼ思ったとおりの環境にできました。

正直、ライフハック的なのは全然好きじゃないんですが、なんだかんだそういうことをやっている気がします。 (服をひたすら断捨離して同じものを複数買ったり、ダンボールを捨てて折りたたみコンテナーにしたり、ものを断捨離しまくったり)

余談ですが、冷蔵庫の中もこんな感じで福利厚生が充実しています。

f:id:hirokiky:20180528131214j:plain

会社ではドリンクの支給が(ありがたいことに)ありますが、自宅であれば(自腹ですが)好きなものが揃えられて良いですね。 水は中硬水が良いとか、飲む飲まないに関わらずレッドブルは備蓄しときたいとか、色々めんどうな僕の性格を自宅であれば好きに満たせます。

他のオススメ記事

blog.hirokiky.org

blog.hirokiky.org

DjangoCongressの参加ブログがどれも良いのでまとめておきたい #djangocongress

先日のDjangoCongress JP 2018の参加ブログが続々公開されてて読んでいて楽しい。 どの記事も面白いのでザックリとだけどまとめておいた。あとでdjango-jaのもっと公式的な場所に書き写すかもしんない。

djangocongress.jp

ありがとう。ありがとう。 読みたいので、他にもあったら教えて。

以下、読んだブログ

最終更新: 2018年5月31日

nwpct1.hatenablog.com

blog.mtb-production.info

nikkie-ftnext.hatenablog.com

katekichi.hatenablog.com

thinkami.hatenablog.com

xaro.hatenablog.jp

blog.hirokiky.org

jumpyoshim.hatenablog.com

www.denzow.me

DjangoCongress JP に行ってきた | attakei page

nakagami.blog.so-net.ne.jp

ryu22e.org

koty.hatenablog.com

thinkami.hatenablog.com

farewell-work.hatenablog.com

tokibito.hatenablog.com

medium.com

eng.iridge.jp

medium.com

massa142.hatenablog.com

blog.xoxzo.com

DjangoCongress JP 2018ってイベントを開催した話

f:id:hirokiky:20180520174908p:plain

2018年5月19日に、DjangoCongress JP 2018というイベントを開催しました。

djangocongress.jp

これはWebフレームワーク Django のカンファレンスです。 参加者は全部で100人ほど、発表者12人、スタッフ(合計で)15人ほどのイベントでした。 めちゃくちゃ楽しいイベントでした。もうね、最高。

Togetterも作ってくれたよー togetter.com

僕は代表として、キックスタートからこのイベントを皆で作っていました。 今まで日本でDjangoだけを扱った大きなカンファレンスはなかったので、これが初めてのイベントになったなと思っています。

スタッフは〜15人ほどで開催しました。準備には2017年の11月に初めたキックスタートから初めています。

django.connpass.com

もともとsalexkiddが2017年のPyConJPのパーティーで、「そういやDjangoでカンファレンスやんねーの」と言うので、「お、じゃぁやるか」となったのがこのDjangoCongress JPです。

(これを書いている今はDay 2のSprint Dayで、DjangoへのPRが1つまとまったので休憩がてらブログ記事を書いています)。

ここではイベント開催するときに感じたことや、「こうやったのは良かったなぁ」という話をします。 あまり時系列順に語るまとめをする気もないので、感じたことを書きたいと思います。

最小のイベントを作る、みんなで盛り上がる

このDjangoCongress JPは宇宙で初めて誕生するイベントです。 去年までのノウハウやスタッフ間の繋がりもそれほどない状態からスタートでした。 なので、まずは「最小でイベントを作ること」、「5年続く1年目になること」をコアの考えた方としてイベントを作っていきました。

まずスタッフ間の「コミュニティー」も無いに近い状態ですし、Djangoでイベントをやって需要があるのかすら分からない状態でした。 その状態で「アレをやろう」「イマドキのカンファレンスはこれは絶対ある」みたいなのを闇雲に追い求めると破綻するのは当たり前だと思います。

まず、キックオフの集まりから「こういうものを作ろう」というビジョン、温度感をスタッフの間で最初に共有できていたのは良かったと思います。 とくに「やらなくていいよね」を共有できたので、すごく小さい(やる作業が少ない)けど良いカンファレンスができたと思います。 僕たちは「他で聞けない、深くて面白い発表を聞きたい」、「場所さえアレばみんなで楽しめる」ということに注力していました。

例えばランチ提供も、パーティー(懇親会)提供もしません。 チュートリアルやハンズオン、企業スポンサーにブース出典、ポスタートーク、動画配信、同時通訳もありません。 その代わり、ランチは「ランチマップ」を用意して各人に自由に行ってもらったり工夫を凝らしていました(ランチマップ作ってくれた小俣さんありがとう)。

ただ、「他のイベント(とくにPyConJP)で採用されないようなDjangoの濃い、Django内でのバラエティーに富んだ発表をしよう」という一点は貫けて良かったです。 PyConJPはイベントとして規模が大きくなっていますし、データ系や機械学習系などPythonの幅もかなり広がっています。ディープな話(例えばDjangoのデータベースドライバーの実装の話や、GeoDjangoを使った地理空間アプリの話)を発表をする機会はどうしても減ってしまうと思います。

(開催するまでは不安でしたが)上記のものなかったけどなくても良いんだなぁと思いました。 同時通訳がなくても英語の発表も聞いてる人多かったですし、動画配信もなかったけど、その分スライドのアップロードやSNSでの投稿が多かったのでそれはそれでよかったと思います(スライドは https://djangocongress.jp/ にすべてまとまっていますよ!)。 あと、みんなブログとか書いて情報を広めてくださいね。それか、同じ発表内容で再演とかしてくださいね。

「無い効果」というのは面白いなと感じていて、例えば「動画配信がある」と思うと、たとえ参加してても「昼寝してて良いかな」と思ってしまう瞬間はあると思います。 「ブログに書かなくても動画あるしなぁ」とか、「メディア記事あるしなぁ」とか、「togetherとか公式の色々もあるし良いかなぁ」って言い訳ができちゃうわけですね。 でも今回はみんな会場でのその瞬間に集中してたと思います。

Twitter#djangocongress が日本のトレンドになったりもしてて、スタッフも参加者の人もみんなで盛り上げられて良かったなぁと思います。 オープニングで「みんなブログ書いてね!!スライドアップロードしてね!!ってSNSに書いてね!!」って共有したのも良かったのかな。 提供者が提供しすぎると、参加者がより参加者になっちゃうのかもしれない。それだと寂しいし、みんなで盛り上げていこうねーってほうが僕は好きかな。

やらない、という力

「やらない」を決めると色んな懸念や作業、連携や指示、担当割りもなくなるので一気に楽になると体感できました。 たぶん、今回のイベントでそれが一番大事だったと思う。 おかげでイベント当日にも余裕があって、スタッフも含めてとてもイベントを楽しめたと思う(僕は色んな発表も聞けたし、話もできたし、すごい楽しかったよ)。 今後もし何かやることを増やすにしても、お金で解決するほうを選ぶかなぁ。

代表としてやったこと

イベントの代表として色々やったけど、僕は流れとか勢いとか場を作るのが大事なんだなぁと思いました。 あんまり自分が「長」みたいになるのが好きじゃなくて、「座長」という呼び方もあえて使いませんでした(なんかね、僕の気持ち的にですが)。 立場として、窓口として、顔として「代表ですよ」以上の意味はない(し、必要ない)と思ってます。

今回は初めてのイベントだったし、Djangoのでかいイベントをやって需要があるかも分かりませんでした。でも確実にある気はしていました。 なので、まずは「やるよ」って言うことが一番僕の大事な仕事だったんじゃないかなぁと思います。「やりたいね」じゃなくて「やるよ」と言うこと。あとはスタッフみんなで頑張りました。スタッフの僕たち、頑張ったね~。

具体的なやったことはビジョンを共有したり、定期的に作業イベントを開催したり、作業するためのツールとかスラックとかを整備したり、進捗を見たり、担当や役割をお願いしたり、色々実務的なタスクをこなしたりしていました。当日は全体の動きを見たり、オープニングスピーチとクロージングスピーチをしたり、LTの司会者をしたりしていました。でも主には人の発表を聞いたり話したりしていたんで、参加者としてもかなり楽しみました。

コアのスタッフが運営に慣れてる人が多かったのでとても助かりました。 お互いに空気感がとても伝わりやすいからですね。「~しようよ」「~いらないよね」って言ったときに「え、なんでなんですか」って根本からの説明が少なくて済むから。 あと、みんな色んなイベントを開催したり参加してる人たちだから「あれは必須だよね」とか「まぁ、あれはなくてもぶっちゃけいいよね」って気持ちが深いとこで伝わっていたと思う。

でも今までそんなに繋がりも深くない同士だったけど、かなり深まったなぁと思う。Djangoの日本コミュニティーってあるの?みたいな感じはあったけど、今ならあるって言えるよね。少なくともスタッフ同士があれだけ一緒にいいもの作って時間を共有できたってだけでも良かったです。 それが僕が今回、一番作れて良かったことかなぁ。

身近なイベント

感想を聞いてみると「みんなの顔が見えた」「warm and like family event」みたいな感想を何人かに聞いた。 それはとても嬉しくて、規模を大きくしすぎないこと、行動規範を大切にすること、みんなで楽しむことは大事にしたかったので実現できて良かった。

僕は「参加者」と「提供者(スタッフ)」に分かれたくないと思ってた。どんなイベントでもそう思う。 だってスタッフってボランティアですよ。何十時間っていう労力を無償で提供しています。一番楽しめないといけないと思う。

イベントのオープニングで「みんなが参加者、みんながスタッフ」と話しました。 「SNSにたくさん書いてほしい。スライドをアップしてほしい。隣にいる人と話したり助け合ったりしてほしい」と伝えました。 みんなイベント中によく話してたしリラックスしてるようで良かったなと思います。とくにCybozu Barはリラックスできて良かったなぁ。

行動規範についてもたっぷり時間を使って話したのが良かったのか、ビデオ録画どストリーミングがないからその瞬間を大事にしたのか、そういうのもよかったのかもしれないです。 ただ、その場にあった空気感みたいなのが、何か良いなと思っていました。

今後のイベント

たぶんDjangoCongressは参加者300人を越えるイベントにはならないと思う。今回で120人くらい。150人+2,30人くらいでいい感じかなと思っています。 今回は「参加枠増やしてください」「参加できなくて残念です」という声もいただきました。申し訳ない気持ちになったし僕も謝っていた気がしますが、でも、だからって500人とか1000人のイベントにはしないと思います。501人目は常にいるとも思いますしね。 まぁ他人を変えようとするよりも、やりたいことがあるならイベントを別に作るのも素敵だと思います。協力はどんどんしますよ!! たとえば地方でもDjangoCongressをやってほしいなら、ぜひ、「やろうぜ」って言ってみてほしいです。

内容も、今年と同じように色々と提供しないけど、発表が面白くて、みんなで色々好きに話せるようにしたいです。 究極、場所と、人と、話のきっかけがあればそれでいいと思います。 会場提供のサイボウズさん、ありがとうございました。 発表者、スタッフ、参加者のみなさんもありがとう。楽しかった?僕は楽しかったです。 また、こういうのやりたいなー。