Quantcast
Channel: さめたコーヒー

エンジニアはWeb検索のデフォルトで英語版googleを使うほうが良い

$
0
0

タイトルの通りですが意外とやってない人が多いようなので記事にすることにした。

英語版googleを使うには次のURLを検索エンジンとして登録する。

https://www.google.com/search?safe=off&gl=us&hl=en&pws=0&source=hp&q=%s

公式サイトが最初にヒットする

最大のメリットは適当に検索したときに公式サイトがトップにくることだ。 例えば、「rails」で検索したときの英語版と日本語版を比較してみよう。

f:id:kbaba1001:20200104070243p:plain
英語版google

f:id:kbaba1001:20200104070311p:plain
日本語版google

英語版では広告を除けばトップに公式サイトが来ているが、日本語版では三番目になっている。

ゴシップサイトブロッカーを使わなくなった。

日本語版googleを使っていたときはゴシップサイトブロッカーを使っていた。

chrome.google.com

僕は侍エンジニア塾とかTATSUO IKURAさんのサイトとかをブロックしていた。 これらのサイトは初学者にはいいかもしれないが、ある程度プログラムをやっている人には不要だ。

エンジニアにとって重要なことは公式サイトを読むことだ。QiitaとかStack Overflowなども読むのはその次だ。 とにかく公式サイトを読むことが重要だ。公式サイトの情報が最も新しく妥当である可能性が高いので一番信頼するべき情報だ。 他の情報源のほうが読みやすいこともあるが、まずは公式の情報に当たることが良いと思う。

日本語版googleが日本語の情報サイトを上にもってくるのは妥当

日本語版googleを使っていたときは公式サイトよりも上に侍エンジニア塾とかTATSUO IKURAさんのサイトとかqiitaとか上にくることにイライラしていた。 SEOがハックされた結果、googleの検索システムが馬鹿なんじゃないかと思っていた。

でもその考えは見当はずれだ。

日本語版googleで検索しているのだから日本語で書かれたサイトが上に来るのは当然なのだ。 英語で書かれている公式サイトを見たいなら英語版googleで検索すればいいだけの話だった。 自分の検索の方法が悪かった。

まとめ

というわけで、英語版googleをデフォルトの検索にしてから非常に快適にgoogleを使うことができている。 たまに英語で書かれた非公式のブログとかが最上位にヒットすることがあるけど、日本語サイトと比較にならないくらい広告だらけなので開いた瞬間に閉じてしまう。

日本語版googleでイライラしているエンジニアの方は英語版googleをデフォルトにすることをおすすめする。


エイトオフィス高円寺を契約した

$
0
0

月極のコワーキングスペースであるエイトオフィス高円寺店を契約した。

koenji.8office.jp

 

google map で自宅周辺のコワーキングスペースを探して、なんとなく面白そうな場所だったので内見に行ったところ色々と気に入ったので数日後に契約した。

外見はこんな感じ

少しレトロな感じが高円寺っぽい気がする。

契約した座席

ちょっと狭め。こういう座席が10席くらいある。

 

このコワーキングスペースはちょっと変わっていて、半分はフリーランスの美容師用の美容院エリアになっている。

髪を洗う専用のシンクもある。

狭いが入り組んでいて面白い。部屋をまたぐとぜんぜん違う空間がある。

コワーキングスペースというとやはりIT系の人が多い印象があるのだが、ITとは全く違う世界が隣接しているのが面白い。

 

玄関を入ってすぐの廊下

奥のドアがコワーキングスペースで手前の左側に美容院エリアが数部屋ある。美容師たちも常駐しているわけではなく、お客様と約束があるときだけ来ているようだ。店に行けば店員として美容師がいるわけではなく、事前に待ち合わせてここで落ち合う。それも不思議な体験のように思う。残念ながら僕は坊主刈りなので美容院にお世話になることはないのだが…。

 

空間の使い方が面白い

こういう廊下の何気ないくぼみも実は鏡があって、化粧台のように使うことができる。

 

おしゃれな壁紙の部屋もある。

これも美容院ルームだが、この壁紙はコワーキングスペースの利用者がデザインしたものらしい。コワーキングスペースを利用する人はフリーランスだったり小さな会社をやっていたりするので、それぞれのスキルがあって面白い。普通の会社のオフィスにいると同じような能力の人が集まりがちなので、ちょっと違う刺激がある。

 

ライトなどの装飾品もこだわりを感じる。

 

ふと上を見上げると銅像と目があった。

こういう物があるといたずら心を感じる。

廊下の上の方にある花壇も

よく見るとコードが伸びている…。

ぴかっ

色々スイッチをいじっていたら電気がついた。仕掛けが色々あって面白い。そういうアトラクションのような雰囲気がある。

 

写真で気がついた方もいると思うが、空間はDIYで工作して作られている。オーナーが建築士で自分でこの空間を作ったそうだ。僕もDIYが好きなので合板がむき出しの空間に親近感が湧いた。

オーナーと話していると僕と同じN-VANに乗っていることがわかった。色々と趣味が合いそうなので契約することにした。

 

契約してしばらく経ったが週2、3回程度行っている。自転車や徒歩で行っているので運動代わりに通勤している。ジムを解約してしまったので自宅に引きこもるのはよくないという意識がある。今のところ特に嫌な感じもなく、快適に仕事ができている。

コワーキングを契約する理由は人それぞれだと思うが、僕の場合は法人登記を移すこと、運動不足解消、自宅で息詰まるときの逃げ場、新しいコミュニティにふれるなどの理由だ。個人で仕事をしているとどうしてもコミュニティが閉じてしまいがちだ。だから新しい人間関係を作りたいという気持ちがあった。コワーキングスペースの人間関係は、今まで僕が多く関わってきたシェアハウスの人間関係とは少し異なっていると感じた。シェアハウスは働いてない人もいるけど、コワーキングスペースはそれぞれ仕事をしているからより尖っている感じがした。逆に言えば自分のやることがすでに決まっているので落ち着きがあった。それが自分にとって良い刺激になるといいなと思った。

IDIY(アイディ)で2週間英文を書き続けてみた

$
0
0

www.youtube.com

上の動画で話した IDIY について書いてみようと思う。

idiy.biz

IDIY は英文添削サービスで、書いた英文を講師が添削してくれる。僕が契約しているプランでは1日100単語までならサブスクの範囲で対応してもらえるので、ここ2週間ほど毎日英文で日記を書いて提出している。

どういう校正が来るのか?

例えば、僕が書いた英文がこれ。

I went a neighborhood library first time because I have moved this town 2 month ago. The library had 2 floors. There are magazines at first floor and books at second floor. I found a book which I read in childhood. I felt nostalgic and decided to borrow it. Next I picked up a book of Stephen King which I had seen the movie. I like his books and movies. His stories are not only horror but also impress me. Eventually I borrowed three books. I usually don’t read books so I want to make a habit to read.

これを一行ずつ校正してくれる。最初の2文の校正結果が次。

f:id:kbaba1001:20200118183622p:plain

こんな感じで結構細かい指摘が来る。

f:id:kbaba1001:20200118184039p:plain

正しく文章を書けているところでも、別の表現を教えてくれる講師も多いので勉強になる。

最終的に次のような文章になった。

I went to a nearby library for the first time because I just moved into this town 2 months ago. The library had two floors. There were magazines on the first floor and books on the second. I found a book which I had read in my childhood. Reading it again made me feel nostalgic and I decided to borrow it. After that, I picked up a book by Stephen King, whose movie adaptation I've watched before. In fact, I like both of his books and movies. His stories are not only scary but also inspiring to me. After browsing the library, I ended up borrowing three books in total. Reading books has never been a part of my interest, but I want to make it a habit.

lang-8やGingerと比べて良い点

似たようなサービスに lang-8 や Ginger などがある。

lang-8.com

www.gingersoftware.com

lang-8 はネイティブのユーザー同士がお互いの書いた文章を校正し合うサービス。僕としてはサイトのデザインが古いのが嫌なのと、ソーシャルコミュニケーションが面倒くさくて使っていない。あまり長い文章だと校正してくれないことも多いし、あんま勉強にならない気がする。

Ginger は自動でスペルチェックや簡単な校正をしてくれるサービスで、僕は IDIY と併用して使っている。Ginger は無料でも使えるけど校正する数に上限があるので僕は課金している。これは校正はしてくれるけど解説はないし、自動でやるのでちょっと間違っていることもある。

IDIYは英語の上手い人が校正してくれて丁寧に解説も付けてくれるので、いままで使った中だと一番満足している。

IDIYの価格は高め

正直価格は高い。 僕が契約しているのは 学べる定期券ライト定期券価格 / 1日1回100単語までというコースなので12,300円(税別)が1ヶ月の料金だ。まぁ海外留学とか考えるともちろん安いんだけど、英会話スクールやDMM英会話よりは高い。DMM英会話が1日25分の会話プランで6,480円(税込)でiKnowまで使えることを考えるとやっぱり高い。サブスクで1万円を超えてくるとちょっとためらう。もともとこの値段の高さもあって躊躇していた。

価格については次のページに詳しく書かれている。解説なしや1日50単語までのコースなら安くできるし、月額以外の支払いプランもあるので、あまり利用しないならそっちのほうがいいと思う。

idiy.biz

 講師は日本人・ネイティブの2つが選べる

添削をお願いする講師は日本人とネイティブの2つが選べる。

日本人講師を選択した場合は日本語文もつけることができるので自分の英文の意図を伝えて間違いや微妙なニュアンスの違いを指摘してもらいやすい。

ネイティブ講師の場合は英文しか送れない。返事もすべて英文で返ってくる。たまに英文の意図がうまく伝わってないことがあって難しさを感じるけど、ネイティブっぽいのりの喋り方を見ることができるのはなんとなく楽しい。

 DMM英会話と比べてどうか

DMM英会話は英文の校正はしない。英会話サービスなのでちょっと比較するのも違う気がするけど、英語学習という意味では同じなので比較してみる。

というのも、僕はDMM英会話に挫折した。一日25分喋れるコースを利用していたが、25分しゃべるのは結構しんどかった。やったあと「今日もうまく喋れなかった…」みたいな敗北感を感じて英語学習のモチベーションが下がった。僕の英語力ではDMM英会話はまだ早かったと感じている。日本人講師と喋っていたら違ったかもしれないけどそれはサブスクの範囲外の課金が必要なので、フィリピン人講師としゃべることが多かった。DMM英会話では一番安いプランだとネイティブではないが英語が流量な講師との会話しかできない。初対面の講師と25分会話を続けるのがそもそもしんどい。日本人相手でもしんどい気がする。教材を使う授業も受けることができるのだが、そうするとほとんど喋る時間がなくてもったいない感じがするので、果敢にフリートークだけやっていたのだが、今にして思うと無謀だったかもしれない。

会話より文章のほうが気楽

知らない人と話すのは結構難しい。何の準備もなしに外国語で25分話すのは僕には無理だ。予習をしてきても最初の5分くらいで話してそこから先はアドリブになることが多かった。そもそもDMM英会話は相手の講師が外国から話しかけてきているので、結構音声にノイズが乗っていて聞き取るハードルが高かった。話すとなると相手のノリとか性格とかも考える必要があって、そもそも僕は英語学習のためだけに知らない人と話すのがちょっとつらかった。

その点文章のほうが気楽だ。自分の日記を書いているので自分の話をすればいい。発音やリスニングについても気にしなくてもいいから、とりあえず自分のアウトプットの能力を相手にわかってもらうことができる。文章のほうが会話よりも細かく英語の誤りを指摘してもらえるし、記録が残りやすいから便利だ。

Language Exchange との比較

今年に入ってから Language Exchange にもう何度か行っている。週1くらいのペースで行けたらいいと思っている。 Language Exchange とは、外国語を勉強したい異国の人同士が集まってお互いに話す会だ。例えば英語と日本語の場合は、英語がネイティブの人(または同じくらい話せる人)と日本語がネイティブの人が集まって10分英語で話して10分日本語で話す、みたいな感じだ。meetup というアプリで Language Exchange のイベントを立てている人がたくさんいるので僕はこのアプリで行けそうなときに行っている。

www.meetup.com

Language Exchange は DMM 英会話と比べて複数人で話すのが良い。DMM英会話などの英会話教室は1対1で話すことが多いと思うけど、Language Exchange は基本的に多対多で話すから他の人の話を聞いて表現を学ぶこともできる。日本語でも話せるので英語だけで話すよりはちょっと気楽な気もする。

Language Exchange はオフラインの交流会なのでそこで友達を作りたいと思っている。顔を合わせたコミュニティなのでDMM英会話のようなオフライン上のやりとりより親密度が高いように思う。

Language Exchange は1回0~1,000円程度で参加できるのでかなり安い。

IDIY で書いた文章を Language Exchange の予習とする

IDIYで日記を書いているので、それを Language Exchange の予習にすれば会話がやりやすいと思っている。どうせ、週末何をしたか、みたいな話をするわけで日記に書いたことと同じことを話せば話題にしやすい。文章で表現して校正も受けているわけだから安心して話すことができる。100語くらい書いているとそれなりに話せる。

Language Exchange は勇気がいる

Language Exchange は勇気がいる。英語を話す勇気もそうだが、それ以上に日本人ではない人と話すことに対する勇気が僕にはいる。ノリが軽かったりテンションが高かったりする人も多くて、そういう人と関わることが英語と話すこと以上にしんどい。大げさなジェスチャーをされるとびっくりする。やめてほしい。途中で耐えられなくて帰ったこともある。普段関わらないタイプの人と関わるのは結構しんどい。

Language Exchange の会場はどうしてもガヤガヤする。僕は騒がしい場所が苦手だ。人の声がうまく聞こえなくなる。右耳の聴力が弱いこともあるし、カクテルパーティー効果がうまく機能しないせいでもある。ガヤガヤした場所で相手の声を聞いて、雑音にまえないように大きな声で話さなければならない。大きな声で話すのも僕はあまり好きじゃない。もともと声が小さいし、低いので通らないのだ。

それでも Language Exchange には行くことにした。英語日記のおかげで多少自分から話すことはできる気がしてきていることと、DMM会話よりは続けていけそうな気がしているからだ。Language Exchangeは上記のような理由でかなり行くだけでしんどいので、参加しただけで自分を褒めることにしている。ガヤガヤした環境が嫌いすぎて普段から電車に乗らず居酒屋にも行かなくなってしまったくらいなので、Language Exchangeの環境のストレスはかなり高い。

Hapa英会話でも英語日記を推奨していた

Hapa英会話のYouTubeを見ていたら、上記のような自分がやっていることをジュンさんが推奨していたのでちょっと自信を持った。俺は間違ってない!

www.youtube.com

Chromeの「固定」タブは何のためにあるのか?

$
0
0

rebuild.fm

Rebuild.fm 258 回で宮川さんがChromeの「固定」タブが何のためにあるのかわからないとおっしゃっていたので僕の活用方法を書いてみることにした。 意外と他の人も知らないのかもしれない。

そもそも固定タブとは

Chromeでタブを右クリックしたときに出てくる「固定」を選択すると、タブが左端によって小さな表示になる機能。

起動時に固定したタブだけ残すようにする

僕は Chrome を終了して再度立ちあげたときに特定のタブだけ残っていてほしいので、これを実現するために固定タブを使っている。

まずChromeの設定の「起動時」を「新しいタブページを開く」に設定する。

通常であれば、これは起動時に前回どんなタブを開いていたとしてもすべて消し去って、単純に新しいタブページだけを表示する。 しかし、固定したタブがあればそれだけ残る。

例えば、次のようにタブをいくつか固定していて、ほかは固定していない。

この状態でChromeを終了して再度立ち上げると次のようになる。

メリット

「起動時」を「前回開いていたページを開く」にしている人が多いと思うけれど、それだとChromeのタブが闇雲に増えていく。 この方法であれば、適度に残したいものだけ残していけるので便利。

技術書典8、ノイマン教のサークル情報まとめました

$
0
0

技術書典8のサークル参加情報をまとめました。 会社ブログの方に書いたのでそちらをご覧ください。

blog.neumann.tokyo

オンラインお絵描き会に参加した

$
0
0

bosyu.me

上記の会に参加した。

経緯:

  • 新型コロナウイルスの影響でイベントが自粛されているのでオンラインでお絵描きイベントを開催することになった

やったこと:

  • Zoom で参加者同士をつないで3時間ほどお絵描き
  • 4名参加した
  • 雑談しながら絵を描いた
  • 最後に描いた絵を見せあった

Zoom で参加者同士をつないで3時間ほどお絵描き

主催者が Zoom の有料会員だったので特に時間の制限もなく繋ぎっぱなしで開催できた。予め決めた時間にzoomをつないで集まった。 全体的な流れとしては、

  • 自己紹介
  • 雑談しながらお絵描き
  • 中間発表
  • 雑談しながらお絵描き
  • 最終発表

みたいな感じ。4人だったのでうるさすぎることもなくちょうどいい感じだったと思う。 割とスムーズに進行していたと思うけど、たぶん参加者がそれなりにzoomとかリモートワークに慣れていたからだと思うので一般的にはちょっとハードルが高いのかもしれない。 僕はWebに顔出しして生きている人間なのでカメラを常時ONにしていたけど他の人は割りと隠しがちだった。家の中写ったりするの嫌なのかもしれない。

僕は紙に絵を描いていたのでそれをいちいちアップロードするのが面倒くさかったのでカメラで写していたというのもある。普段 instagram のライブ配信などを見ていると手元を写すことに抵抗感が低い人は多いような印象があるので、簡単に写せるならそうした方が面白いと思う。

雑談

僕はあまり絵を描く友人が多くないので、色々話しながらお絵描きできたのは楽しかった。僭越ながら絵の描き方みたいな話になって、自分なりにやっていることを話たりした。他の人が何に興味があって絵を描いているのかなどを知ることができたのは参考になった。 最近絵を描き始めた人がいて、それによってものを細かく見るようになったという変化があったそうで、なんかそういう話が自分にとっては新鮮で良かった。

最後に描いた絵を見せあった

最後に各自、自分の作品を発表した。 時間を決めてみんなで作業すると一定の成果が得られるのが良い。一人でやるとどうしても途中やめにしがちなのでこういう会をたまに開催するのは良いと思った。

描いた絵

オンライン開催の良さ

家から出ないのが楽でいい。実は会の直前まで風呂に入ったりしていた。当然、終わったら即終わりなので移動の手間がない。

当然、地方の人でも参加できる。イベントから距離という制限がなくなるのは大きい気がする。

また僕は顔出ししていたけど、顔出しが嫌な人は出さなくていいからそれもプライバシーなどを考えると良いと思う。

オフラインイベントよりも静かなのが良かった。僕は雑音が苦手なので助かる。

オンライン開催のデメリット

技術面のハードルがまだありそう。今回は zoom だったけどインストールが必要だったりするのがちょっとハードルありそう。Discordも試したい。

まだまだ一般的ではないので参加する人が限られてそうな気がする。

懇親会がないのが少しさみしい。イベントとは別枠でオンライン懇親会があってもいいのかもしれない。

というわけでDiscordサーバーを作りました。

お絵描きに興味のあるエンジニアなどを対象に、お絵描きをするサーバーです。 といってもエンジニアじゃない人でも誰でも入ってもらって大丈夫です。

discord.gg

Discordでオンラインクロッキー会をやってみた

$
0
0

connpassで募集してdiscordでオンラインクロッキー会をやってみた

ipad.connpass.com

やったこと

ぱくたその写真から選んだものをみんなで見てクロッキーをした。

www.pakutaso.com

ぱくたそはフリー写真素材サイト。今回は男性モデルと女性モデルを描いた。

次のタイムラインで描いた。

f:id:kbaba1001:20200405121046p:plain
オンラインクロッキー会のタイムライン

Discordでお絵描き会をするのはどうなのか

Live機能を使って題材の画像を表示して共有したいたけど、途中からLiveがうまくできなくなったのでURLだけ共有して各自のマシンで見てもらった。 それで十分だったので次回からそうする予定。

音声のみなので参加しやすかったのではないかと思う。描いてる間は集中するのでミュートにする人が多かった。

残り時間も僕が口頭で伝えれば十分でとくに画面に出す必要はなかった。

zoomでやると荒らし対策が面倒だったりするのでDiscordで十分じゃないかなと思った。

作品の発表

これもDiscordのチャットに貼り付けてもらってみんなで見た。 Zoomだと画像を共有しても展開されない(ファイルでダウンロードする必要がある)ので、Discordのほうが素直に画像が見れてよかった。 画面共有してもらうより手間が少ないし。

なんとなく絵を見せるのが恥ずかしい人もいるだろうから、見せたいやつだけ貼ってもらった。 そのくらいのゆるい温度感がいい気がする。

WSL2でLinuxのGUIアプリを動かす

$
0
0

WSL2でGUIアプリを動かせるようにしたのでその方法についてまとめます。

参考 github.com

概要

WSLでGUIを表示する流れは次です。

  • VcXsrv でディスプレイを用意する
  • 上記のディスプレイに IP アドレスとディスプレイ番号でアクセスしてGUIを表示する

VcXsrv のインストール

sourceforgeからダウンロードしてインストールしてください

sourceforge.net

VcXsrv の起動

スタートメニューから XLaunch を起動します。

f:id:kbaba1001:20200429141205p:plain
XLaunch

「One large windows」を選択し「Display number」 を 「0」にしてください。 f:id:kbaba1001:20200429141246p:plain

f:id:kbaba1001:20200429141352p:plain

Disable access control をチェック f:id:kbaba1001:20200429141459p:plain

ファイアフォールの設定

「ファイアフォールの状態と確認」を開く f:id:kbaba1001:20200429141608p:plain

「Windows Defender ファイアウォールを介したアプリまたは機能を許可」をクリック f:id:kbaba1001:20200429141802p:plain

「設定の変更」を押したあと、一覧から 「VcXsrv windows xserver」のプライベートとパブリックを有効にする

f:id:kbaba1001:20200429141930p:plain

WSL上での設定

.bashrc に次を追加

export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0.0

※WSL1だと export DISPLAY=:0でよいっぽい。

source ~/.bashrcした後、x11 などをインストールする。 例えば xfce4 をインストールする場合次のコマンドを実行する。

sudo apt install xfce4

これにより xfce4 がインストールできるので次で起動する

startxfce4 &

うまくいくとこんな感じ。

f:id:kbaba1001:20200429142258p:plain


WSL2時代のWindows開発環境

$
0
0

WSL2の公式リリースが近づいてまいりました。僕はpreview版のwindowsを入れて先にWSL2を使ってます。

現状でのWSL2のインストール方法は下記を参照してください。

docs.microsoft.com

構成の概要

僕の環境の構成を図にしました。

f:id:kbaba1001:20200430063711p:plain

主に使っているのは次です。

  • Docker for windows
  • VS Code
  • git bash
  • WSL2
  • VcXsrv

次の二通りの開発パターンがあります。

  • Docker for windows + VS Code + git bash で WSL2 を使用せずに開発する
  • WSL2 + VS Code (+ Docker for windows) で開発する

Docker for windows + VS Code + git bash で WSL2 を使用せずに開発する

WSL2の説明と言いながら WSL2 を使わない場合です 。 昨今の開発では実行環境を Docker で用意することも増えてきたので Docker だけで十分開発できる場合も増えてきました。 そのため WSL2 を使わずに Docker for windows だけで事足りる場合があります。

この場合、 Docker for windows + VS Code + git bash で開発を行います。 (もちろん他のエディタやPowerShellを使ってもいいです。)

git bash はインストールするだけで基本的なLinuxコマンドが使えるようになるターミナルです。 git bash は意外と優秀です。使い始めた頃はtmuxがなかったりして役不足かと思いましたが、すでに1年以上使い続けているのでcygwin のような本格的なLinux環境がなくてもこれで十分でした。 VS Code のデフォルトのターミナルを git bash に設定しておけば、 VS Code 上で気楽に git bash を使うことができます。

defaultのターミナルは「Terminal: Select Default Shell」で変更できます。git bash がインストールされている状態であれば候補に出てくるはずです。

f:id:kbaba1001:20200430064622p:plain

↓VS Code のターミナルで gitbash を使用する例 f:id:kbaba1001:20200430064931p:plain

説明が遅くなりましたが、上記のように VS Code のターミナル機能を使って開発を行います。 メリットは複数のターミナルを立ち上げて切り替えながら作業できることです。

f:id:kbaba1001:20200430065017p:plain

それ以外は特にないので VS Code のターミナルが嫌な人は普通に git bash を立ち上げるとか、複数タブ表示できる別のターミナルを使うとかで工夫してみてください。

WSL2 を Docker の engine として使う

WSL2 を使わない開発方法と言いましたが、実際のところ裏の部分で WSL2 を使っています。 Docker for windows 2.2 以降にはHyper-Vの代わりに WSL2 で Linux 環境を動かす機能がついています。

詳しくは次の記事を参照してください。 www.publickey1.jp

設定の次の部分にチェックを入れることで有効になります。

f:id:kbaba1001:20200430064236p:plain

WSL2 + VS Code (+ Docker for windows) で開発する

WSL2 を利用して開発したいケースも多々あります。VS Code Remote WSL を使って、VS Code から WSL の環境にアクセスして開発を行います。

marketplace.visualstudio.com

これにより WSL2 上に VS Code をインストールすることなく開発を行うことができます。

WSL2 における注意点: リポジトリをWindowsの領域に置かない

WSL2 の欠点は Windows のディレクトリをマウントしている部分での処理が WSL より遅いことです。 WSL/WSL2から Windows のファイルを見るときは /mnt/cディレクトリ以下にアクセスします。このディレクトリは Windows のディレクトリをマウントしていますが、この部分が WSL2 では非常に遅いです。 ファイルシステムの都合によるもののようですが、 普通に git を使うこともできないほど遅いので正直開発では使い物になりません。

f:id:kbaba1001:20200430065952p:plain

そのため、 WSL2 で開発を行うときはリポジトリを /home/ユーザー名/以下などに置くことをおすすめします。 そしてそのディレクトリを VS Code Remote WSL でマウントすることで開発を行います。

WSL2からDocker for windows にアクセスする

WSL2ではWSLと異なりdockerデーモンを動かすことができます。しかし僕は Docker for windows に寄せたほうが何かと作業しやすいので WSL2 から Docker for windows にアクセスして使っています。 WSL では ~/.bashrcDOCKER_HOSTを設定することで Docker for windows にアクセスしていましたが、 WSL2 ではこの設定は不要になりました (むしろ DOCKER_HOSTの設定は消す必要があります)。 WSL2 を docker for windows の engine として設定しておけばResourceのところに下記の設定が表示されるようになるので、チェックを入れるだけでアクセスできるようになります。

f:id:kbaba1001:20200430070733p:plain

これにより WSL2 上でも docker for windows にアクセスして開発できるようになるので、windows 側から同時に docker にアクセスして開発することが可能になります。

WSL2 で Linux の GUI 環境で開発する

あまりユースケースがないかもしれませんが WSL2 の GUI を立ち上げることができるので下記に詳しくまとめました。

www.kbaba1001.com

僕としては WSL2 上で動いている clojure で Quil (processing の clojure ラッパー) で画像を生成する際にこの仕組を使っています。

f:id:kbaba1001:20200430071207p:plain

上の画像では右側に見えている VS Code は Windows で動いている VS Code で Remote WSL により WSL2 にアクセスしています。 左側は VcXsrc です。ここに WSL2 で立ち上げた X11 を表示しており、そのうえで VS Code で書いたプログラムの実行結果である画像(丸が描かれたウインドウ)を表示しています。 これにより画像や音楽などのプログラムを Linux 環境上で構築することができます。

Linuxbrew をインストールする

WSL2/WSLでもLinuxbrewを使うことができます。まれに homebrew しか対応していないソフトウェアをインストールしたい時があるので、 linuxbrew も入れておいたほうが何かと楽です。

Clojure + Quil でゲームを作る

$
0
0

Clojure と Quil でブロック崩しゲームを作ったので知見を共有します。

詳しい解説とソースコード

忙しい人向けにソースコードと解説動画を先に貼ります。

github.com

youtu.be

解説動画では実際にブロック崩しゲームを作る様子を手順を追って説明しています。 なのでそれをブログで書くのは割愛します。

動機

下記の方法で WSL で GUI アプリを動かせるようになったので試しに Quil でゲームを作ってみることにしました。

www.kbaba1001.com

Clojure のゲーム開発事情

Clojure / ClojureScript におけるゲーム開発事業は次の記事にまとまっています。

Game Development with Clojure/ClojureScript

4年前の記事ですが、残念ながらあまり状況は変わっていないようです。

play-clj や play-cljc を使うかどうか悩みましたがいくつかの理由によりやめました。

github.com

github.com

  • ドキュメントがあまりないのでつらそう
  • 本格的にゲームを作るわけではないのでサクッと使えるやつが良い

試しに Quil を動かしてみたら案外さくっと動いたし、調べてみたらキーボード入力も取得できるようなのでこれでいいやとなりました。

感想

Quil を使うこと自体始めてでしたが思った以上に素直に使いやすくドキュメントも読みやすく、楽しく開発ができました。

Quil は次のような q/defsketchメソッドで設定した値や関数を呼び出してイベントループを回してくれるので、 アニメーションのチラツキ防止処理などについて考えなくてよかったのが楽でした。 キーボード入力やマウス入力もサポートしていて、頑張れば本格的なゲームも作れるような気がしました。

(q/defsketch my-sketch
  :title "breakout"
  :size [500500]
  :setup setup
  :updateupdate-state
  :draw draw-state
  :key-pressed key-pressed
  :features [:keep-on-top]
  :middleware [m/fun-mode])

家庭用オーブンで陶芸をした

$
0
0

youtu.be

ゴールデンウィークの連休中に自宅でなにかできないか会議をした結果、陶芸をすることになった。 調べてみたら「ヤコのオーブン粘土」というものを使うと家庭用のオーブンでも陶芸ができることがわかった。

ヤコ オーブン陶土「工作用」 400g

ヤコ オーブン陶土「工作用」 400g

  • メディア:おもちゃ&ホビー

通常の陶芸より低い温度でできるそうだ。実際必要だった温度は170度くらいだったのでオーブンがなくてもトースターや魚焼きグリルでも頑張ればできるかもしれない。

粘土も柔らかくて適当にこねてくっつけてもちゃんと形が出て使いやすかった。 子供の自由工作みたいなのでやるのもよいのではないかと思った。

作ったのは平皿で、実際使ってみても十分な感じだった。 ガーゼを下に敷くのでどうしても裏面がザラザラになるのがちょっと扱いづらい感じがする。

乾いた皿は思ったより軽くて、これならコップみたいな持つ物を作っても良さそうな気がした。

Nuxt.js + firebaseを習得したときのロードマップ

$
0
0

Nuxt と firebase で個人開発できるくらいにはなったのでどのように勉強したかを残しておきます。 もともとVueは仕事で使っていてNuxtが初めてという状況でした。

step1. Nuxt.js - Vue.js on Steroids

learning.oreilly.com

これをChapter2まで終わらせる。

step2. Build a News Feed with Nuxt 2 and Firestore

learning.oreilly.com

これを最後まで写経。3時間で終わるかと思ったら結構時間かかった。ビデオの人のタイピングも説明も早い。

step3. 個人開発する

Nuxt + firebase で connpass みたいなものを試しに作った。 SSRでやったので細かいところは適宜ぐぐった。 (しかしSPAでも最近はSEOに乗ったり広告はれたりするようなのでSPAで十分だったと反省している。)

firebase ui が便利だった。 firebase についてはドキュメントが日本語だったので理解しやすくてよかった。 ただドキュメント同士の繋がりがわかりづらいのでもうちょっと目次がしっかりしていたら嬉しかった。 サービス名が似ていて混乱することもあった。

雑感

firebase はコンソールのUIが使いやすくドキュメントもわかりやすく人気が出るのも納得だった。 firestore の検索クエリに関しては結構できることが限られていてRDBのようにいかないので設計のいろはをもうちょっと知りたかったがよい資料を見つけられなかった。 みんなKey Value Store の設計はどうやっているんだろうか。。。リレーションを表現しようとしたときだいぶ苦しい。 複合キーで頑張るみたいなことはわかった。あとはElasticsearchになげるとか。なんとかやってる感があった。

言語は静的型付けが流行っているのにDBはスキーマレスが流行っているのはよくわからない流れだなぁと思う。

やらなかったこと

TypeScriptで書きたかったが Nuxt も firebase もほぼ初めてだったのでとりあえずJavaScript で書いた。 ドキュメントに書いてあるコードを逐次TypeScriptに変形しながらやっていける気がしなかったため。 今は多少なれたのでTypeScriptでもかけそう。 ちょうど個人開発したやつをSSRからSPAで作り直したいのでそれはTypeScriptでやってもいいかもしれない。

Clojureでエイトクイーンを解く

$
0
0

最近 discord のエンジニアサーバーでお互いにクイズを出し合って遊んでいる。その中でエイトクイーンを出題してみた。

ja.wikipedia.org

問題文:

エイトクイーンを解くプログラムを作ってください。
エイトクイーンはチェスのマス目上にクイーンのコマを8個並べるパズルです。
クイーンは上下左右斜めの8方向に遮るものがない限り進むことができます(将棋の飛車と角行をあわせた動き)。
クイーンが他のどのクイーンも遮らないように8個全てマス目上に並べてください。

出力は文字列でクイーンは「Q」なにもないマスは「.」で表現することで出力してください。
以下に例を示します。

入力: なし
出力:
 Q . . . . . . .
 . . . . Q . . .
 . . . . . . . Q
 . . . . . Q . .
 . . Q . . . . .
 . . . . . . Q .
 . Q . . . . . .
 . . . Q . . . .


解は複数ありますが、1パターンのみ出力できればOKです。
応用問題。余力のある人は入力でn(数値)を受け取って、n個のクイーンをn x n の大きさのマスにならべてください。nに大きい数をいれても実行可能な時間で計算できるようにすること

エイトクイーンはアルゴリズムの題材としてよく出てくるテーマで、バックトラック法や動的計画法などで解くことができる。解説サイトも多数あるが、それなりに難易度が高いのでサーバーでは結構盛り上がった。

回答

僕は次のサイトを参考にした。 http://bacspot.dip.jp/virtual_link/www/si.musashi-tech.ac.jp/new_www/Python_IntroProgramming/03/index-1c.html

完成したコードが次

(ns eight-queen
  (:require[clojure.string :as s]))(defn conflict? [x y board](->> (map-indexed vector(take y board))(some(fn[[y1 x1]](or(= (- x1 y1)(- x y))(= (+ x1 y1)(+ x y)))))))(defn check? [board](->> (map-indexed vector board)(every? (fn[[y x]](not(conflict? x y board))))))(defn queen [n](loop[board (vec(range n))](if(check? board)
      board
      (recur(shuffle board)))))(defn display-queen [n](let[board (vec(repeat n (vec(repeat n "."))))
        queens (map-indexed vector(queen n))
        result (reduce#(assoc-in %1%2"Q") board queens)](println(s/join "\n"(map#(s/join " "%) result)))))(display-queen 8)

非常に短いコードになって驚いている。どう考えても参考サイトのアルゴリズムがすごい。 参考サイトに詳しくあるが、将来リンク切れする可能性があるので少し解説する。

まず、クイーンの座標を一次元配列で表現する。

f:id:kbaba1001:20201012083818p:plain

添字が y 座標、値が x 座標。 クイーンは縦横方向に重なり合って置くことはないので、重複のない一次元配列で表現することで必然的に縦横の衝突を考える必要がなくなる。

次に斜め方向だがこれは次のように x, y 座標を足すまたは引くことで判定する。

f:id:kbaba1001:20201012084112p:plain

これもシンプルで秀逸なロジックだと思う。

参考サイトではクイーンを置く位置をすべて表示するコードなので順列を使ってクイーンを並べているけど、今回は一つの解を出す問題なので、ランダムにクイーンを並べて条件を満たしていればOK、満たしてなければ再度並べ直すというロジックにした。

回答2: バックトラック法

クイーンの配置をランダムにするだけではつまらなかったのでバックトラック法で並べてみることにした。 つまり、1つクイーンをおいて次のクイーンを置くときに条件を満たしていれば置く、だめだったら一つ前のクイーンを取り除いて再度置き直すというロジックにした。

(ns eight-queen2
  (:require[clojure.string :as s]))(defn check? [x y queens](not(->> (map-indexed vector queens)(some(fn[[qy qx]](or(= y qy)(= x qx)(= (- qx qy)(- x y))(= (+ qx qy)(+ x y))))))))(defnpop-queen [n x queens](if(>= x n)(recur n (inc(peek queens))(pop queens))[x queens]))(defn queen
  ([n](queen n 0()))([n x queens](if(>= (count queens) n)
     queens
     (when(< x n)(if(check? x (count queens)(reverse queens))(recur n 0(conj queens x))(let[[nx nqueens](pop-queen n (inc x) queens)](recur n nx nqueens)))))))(defn display-queen [n](let[board (vec(repeat n (vec(repeat n "."))))
        queens (map-indexed vector(queen n))
        result (reduce#(assoc-in %1%2"Q") board queens)](println(s/join "\n"(map#(s/join " "%) result)))))(display-queen 8)

バックトラックは stack を使ったほうがわかりやすいコードになるが、ここでは再帰を使っている。 だいたい次の動きをする。

  • check?で条件を満たしていればクイーンを置いて、次のクイーンを置きに行く
  • 条件を満たしていなければ以前のクイーンを再配置する。このときクイーンが置かれていた位置から一つ右の位置からクイーンを置き始める。右端にクイーンがおいてあった場合、もう一つ前のクイーンから置き直す。

比較用にRubyのコードも示す。

defcheck?(x, y, queens)
  !queens.each_with_index.any? {|qx, qy|
    y == qy ||
    x == qx ||
    (qx - qy) == (x - y) ||
    (qx + qy) == (x + y)
  }
enddefqueen(n)
  queens = []
  while queens.size < n
    x = 0while x < n
      if check?(x, queens.size, queens)
        queens.push(x)
        breakelse
        x += 1while x >= n
          x = queens.pop
          x += 1endendendend

  queens
enddefdisplay_queen(n)
  queens = queen(n)
  result = []
  n.times do |x|
    row = []
    n.times do |y|
      row <<
        if queens[y] == x
          'Q'else'.'endend
    result[x] = row.join('')
  end
  result.join("\n")
end

puts display_queen(8)

再帰が while になっていること以外はだいたい同じ。Clojureはどうも配列の末尾に要素を追加したり、末尾以外の要素を取得する処理が書きづらい。Stackを使いたい場合は javaの stack を使うのが一番楽な気がする。

google sites でホームページをリニューアルしたら最高だった

$
0
0

この度弊社ホームページを google sites でリニューアルいたしました。

www.neumann.tokyo

以前のサイトは github pages で運用していたのですが、時間がないときに突貫で作ったものだったので非常に地味でした。 試しに google sites を使ってみたところ非常に良かったのでまとめてみます。

google sites とは

google docs の一部で誰でも無料でホームページをGUIで作成することができるツールです。

f:id:kbaba1001:20201112074348p:plain

レイアウトを選んで画像やテキストを挿入するだけでホームページを作成できます。 カスタムドメインを使うことができるので好きなURLを設定できます。 もちろん複数ページ作成することも可能です。 ブログのように頻繁に更新するものを作成するのは大変かと思いますが、コーポレートサイトやポートフォリオサイトを作るには最適だと思います。

また、 google workspace (旧 suite) を使っている場合、同じ workspace のメンバーにのみ公開する事もできるので、社内 wiki のような使い方もできます。

  • google sites はブラウザだけでホームページを作成できるツール
  • google アカウントがあれば無料で使える
  • google workspace 内でのみ共有することも可能
  • カスタムドメインをつけて一般公開することも可能

良かった点

ブラウザだけでホームページを作成できたので、HTMLやCSSで悩む必要がありませんでした。非常に短い時間で見栄えの良いサイトを作ることができました。 無料で使えて広告がつくわけでもないということも非常に良かったです。

また google doc の他のサービスとの連携は非常に強固でした。例えば google form で作成した問い合わせフォームをサイトに埋め込むことは数回のクリックだけで終わりました。他にもYouTubeの動画を埋め込んだり、 google docs のスライドやスプレッドシートを埋め込むことも容易でした。google analytics の設定も一瞬で終わりました。

悪かった点

細かい変更ができません。使っている間「画像サイズをもっと小さくしたい」とか「テキストの一部のフォントだけ赤色にしたい」などのことを考えましたができませんでした。良くも悪くも google sites で作られたデザインの範囲でしかホームページを作成できません。

metaタグがいじれないのも地味に痛かったです。SNSに貼り付けたときの見栄えが悪いので。。。

あとHTTPSのリダイレクトまわりも対応が不十分でした。こういう細かいところちゃんとしてほしいですね。

google workspace のときと一般のgoogleアカウントのときで、カスタムドメイン周りの設定方法が異なっておりドキュメントがなかなか見つからず苦労しました。私は google workspace 内でgoogle sites を用いて会社ホームページを作成したのですが、カスタムドメイン設定しようとしたとき時間がかかりました。

google workspace 内で作成した google sites にカスタムドメインを割り当てる

support.google.com

上記の記事を参考にしてください。 私が何に苦労したかというと、ずっと次のドキュメントを見ていました。

support.google.com

こちらは google workspace を利用していない一般ユーザー向けのドキュメントでした。なぜ同じインターフェースにしてくれないのか…。おそらく内部的に難しかったのでしょうが、せめて案内がもう少し欲しいところです。

Linuxの便利コマンドまとめ

$
0
0

ディレクトリ移動系

z

github.com

一度行ったことがあるディレクトリに再度行くことができるコマンド。

$ z foo

のようにするとマシンの中にあるfooディレクトリにジャンプできる

enhancd

github.com

z をもう少し使いやすくした感じ。fzy などのインクリメンタルサーチコマンドを使ってディレクトリ移動ができる。 今の所 z と併用しているけど、 enhancd だけでいいかも。 bashも対応しているのが嬉しい。

Git

github cli

cli.github.com

GitHub の操作をコマンドからできるやつ。

Search

ag (The silver searcher)

github.com

grep の速いやつ。オプションにgrepと互換性がないので注意

解凍

unar

theunarchiver.com

zip とか tar とか一通り解凍できるコマンド。 日本語ファイルが文字化けしないのが最高に良い。

ゴミ箱

trash-cli

github.com

ゴミ箱をコマンドラインから使えるようにするやつ。 rm だとファイルが問答無用で消えてしまうので一度ゴミ箱に入れるようにしたい。

Tips

Vim の view コマンドと less.sh

vim をインストールしてあると一緒に view というコマンドも使える。 これは読み込み専用モードでファイルを開くコマンドで、lessの代わりに使えばシンタックスハイライトしてくれて便利。 ただし qで閉じることができないので :qを入力する必要がある。

で、 Vim にはもう一つ less.sh というマクロが付属している。

github.com

こちらは view と同じような動きをするのだが、 qでファイルを閉じることができる。しかしなぜかこちらにはpathが通ってないので自分で通す必要がある。 vim をインストールしてあるマシンなら locate less.shなどとすれば less.sh ファイルを見つけることができるのでそこに path を通しても良いし、 適当なディレクトリにコピーして使っても良い。

type -a

コマンドがどこに定義されているかを調べるときに whichなどを使うことがあるが typeも同様のコマンド。 typeはエイリアスや関数も含めて表示してくれるし type -aにするとすべての path を表示してくれる。

$ type -a ls
ls は `ls --color=auto --group-directories-first -F' のエイリアスです
ls は /usr/bin/ls です
ls は /bin/ls です

readlink -f

ファイルやディレクトリの相対パスから絶対パスを表示してくれるコマンド。便利。

$ readlink -f ~/profile.jpg 
/home/kbaba/profile.jpg

GUI

cadmus

github.com

マイクのノイズキャンセリング

copyq

hluk.github.io

クリップボードヒストリー


エンジニアが東京から静岡に移住して5LDKの家を買った

$
0
0

2021年3月、静岡県三島市に中古住宅を買った。5LDKで納戸と庭つきの一軒家。土地は約200㎡、物件は2階建てで総床面積は約150㎡。夫婦2人で住むにはちょっと広すぎるくらいだが、事務所件自宅として使いたかったり将来的に子供ができたときのことをなどを考えて広めの家にした。首都圏を離れて三島くらいまで来るとかなり土地の値段は下がってくるのでこれでも住宅ローンの支払は月々5万円程度でかなり生活費は安くなった。ただ住宅ローンを組むのはかなり大変だった。家を買うのは実は2度目なのだが1度目は100万円程度の安い家を現金一括で買ったので大して面倒ではなかったのだが今回は一括で買える額ではなかったので住宅ローンを組むことにした。僕が自営業であることで審査が厳しいのはある程度覚悟していたが、実際にはそれ以上に発達障害で飲んでいる薬のために審査が厳しかった。それなりにうんざりした。

移住前の生活

気がつけばテレワークをもう6年くらいやっている。僕の仕事はプログラマで基本的に自宅でプログラムを書いてインターネット上でお客様とやり取りしたり納品したりしている。お客様は基本的に東京の会社だがオフィスに行くことはめったになくて、この6年間は気ままに引っ越しをして東京といくつか地方を行ったり来たりしていた。それでもコロナ前は顔合わせくらいは対面で行っていたのだが、コロナ流行後はそれすらなくなって本当に一度も会うことなく仕事をするようになってしまった。

そんなわけで住む場所にとらわれない仕事をしていて今後もそれを続けていけそうだし続けていきたいという気持ちもあり東京よりは地方に住みたいなと思っていた。もともと結婚前は千葉や伊豆に住んでいて、むしろ結婚後に東京に3年も住んでいたことのほうが僕としては想定外のことだった。これは単に嫁と出会ったのが東京(正確には川崎なので神奈川だが)のシェアハウスで、妻がいきなり地方に行くことを拒んだためしばらく東京で生活していたに過ぎなかった。

妻と東京で住みはじめたときから将来的に家を買いたいねという話はしていて、その前提で生活していたので東京の居住は定期借家契約だった。最初は大田区のマンションに住んでいたがいくつかの理由により途中から杉並区の一軒家を借りていた。これはちょっとやりすぎたかなと今では思っていて、家賃が月20万もかかっていた。会社名義で借りるなどの財務上の小技をつかったもののそれでも家賃がちょっと高すぎたなと反省している。とはいえ僕たち夫婦はそれなりに趣味も多く、テレワーカーと専業主婦で基本的に家にいることもあって家の広さはそれなりに必要という結論も出すことができた。

なぜ静岡県三島市なのか

出身地や親戚がいるというわけではないのだが、僕はもともと伊豆が好きだ。昔からの観光名所なので動物園や植物園などの遊べる場所がたくさんあって海と山両方の自然を楽しめる。地方は自然が豊かと言われることが多いけど、実際のところ素人が手軽に楽しめる自然のある地方というのは結構少ないように思う。海があっても工業地帯になっていると釣りや海水浴をする気が失せるし、山もキャンプ場のように整備されてないと素人には危険すぎる。伊豆周辺のようにある程度整備された自然がある場所は貴重だ。

さらに伊豆から少し北上して三島、沼津あたりにくると新幹線が通っているので東京や名古屋に行こうと思えばすぐに行ける。三島駅から品川駅まで1時間かからないのだ。仕事などで時々東京に出る可能性を考えると長く住むなら伊豆半島の中に入るよりは三島市に住むほうが良さそうだと考えた。それに住むとなるとやはり伊豆はちょっと不便なので三島や沼津のほうが街なので便利だ。また三島であれば箱根、御殿場、富士にも近くなるので遊びに行くエリアが広がる。

家を買う場所を探すときに東京近辺で探していた時期もある。埼玉や八王子などのエリアで土地を見に行ったこともあるが、結局これらのエリアのアピールポイントは都心まで何分で出られるか、その割に地価が安いかという点に終始していて、そのエリアならではの魅力というものは弱いように感じた。静岡県三島市に住むことにしたのは僕がもともと伊豆周辺が好きであったことに妻が理解を示してくれたからというのがとても大きい。

土地探しの一歩目

2021年3月に実際に家を買うよりも1年ほど前から動き始めていた。最初はどの場所にするかも決まってなかったし、新築がほしいという夢を見ていた。僕は以前から一条工務店の作る家にあこがれていた。この会社の作る家は2x6製法やオール床暖を採用するなど高い断熱性と住みやすさにこだわっていて、以前から冬場に家の中が寒いことが我慢ならなかった僕としてはぜひとも一条工務店の家を手に入れたかった。結局の所それはかなわぬ夢となったが、一条工務店の展示場や工場などを見学することで家に対する知識はそれなりについたし、そのような情報を妻と一緒に学ぶことができたのは良かったと思う。やはり家選びは自分だけ魅力に感じていてもだめで、一緒に住む人にも魅力が伝わらなければ意味がないのだ。

ハウスメーカーとは別に移住というものについても当初から結構考えていて、東京駅近くにある移住・交流情報ガーデンに相談に行った。この時点ではまだ静岡県東部は候補地の一つでしかなかったが、ガーデンの紹介で三島周辺の移住相談を行っている方を紹介してもらい、その方から地元の情報を得ることができた。 www.iju-join.jp

僕たちのように地元ではないエリアで親戚などもいない場所に引っ越すとなると、それなりにその地域の情報を持っている人と早い段階で知り合うことは重要だった。どのエリアが住みやすいのか、気をつける点はなにか、どういう人が住んでいるのかなどの情報はやはり住んでいる人のほうが詳しい。テレワークなので住む場所の制約が少ない分、かえって場所選びが難しかった。

地方移住するときの土地探しのポイント

東京と地方を行ったり来たりしているせいで、地方移住ももう何度目かよくわからない。その経験からよそ者が地方に住むときに気をつけたほうがいいポイントがあると感じている。

それはなるべく移住者が多い場所に住むべきだということだ。逆に言えば、地元の人ばかりというエリアは避けたほうがいい。やはり生まれた地方でずっと生活している人たちと、いろいろな場所に住んだことがある人たちというのは違う考え方を持っている。その2つは水と油のように混ざらないもので、特に僕のようにテレワークのプログラマなどという傍目からは何をやっているのかよくわからない職業の人間は受け入れられづらい。地方移住を快適に生活するためにはなるべく移住者が多いエリアにすむほうがいい。もともと移住者が多いなら移住者のコミュニティができているだろうから、地元の人達のコミュニティよりはそっちのほうがかなり入りやすいはずだ。

住宅ローンを組むのが大変だった

エリアが決まったあとは不動産情報をネットで調べてよさそうな家を探した。このへんは特別なことはなくてたまたま良い物件が見つかったので内見にいったり指値をいれたりして物件を買う交渉と契約をした。ネットに出ている不動産情報は実はあまり良いものではないので、本来であればその地域で良い物件が出てくるのをじっくり待つというのが一番よい手のようだ。

物件が決まるまでは早かったのだが、その後の住宅ローン審査が大変だった。住宅ローンは銀行や信用金庫に書類を出すわけだが、これが基本的に手書きで同じような内容を何度も書く必要があった。また個人事業主から法人成りして自営業をやっている身なので、過去3年分の確定申告書や会社の貸借対照表などを提出する必要もあった。書類を出してから仮審査の結果がわかるまでに2~3週間程度かかるため、1銀行だけでなく3銀行ほど書類を出した。

住宅ローンを借りるための流れは、

  • 仮審査
  • 団体信用生命保険(団信)加入審査
  • 本審査
  • 貸付

という流れになるのだが、結果としては団信に入ることができなくてどの銀行からも断られてしまった。僕はしばらく前から発達障害関係で通院していて日常的に薬を飲んでいた。その薬が軽いうつ病の薬でもあって、団信としては少しでもうつ病の傾向があると断られてしまうそうだ。ただでさえ薬代などで苦労しているのに住宅ローン審査が通らないというのは悔しかった。

結局の所、住宅ローンが通りやすい人というのは、持病を持ってなくて同じ会社の勤続年数が長い人だけでそれ以外は厳しいように思う。

団信に入れなかったので、なんとかして団信に入らずに住宅ローンを組むしかない。ファイナンシャルプランナーに相談したところ、クレジットカード会社の運用しているフラット35であれば入れそうということがわかった。フラット35は固定金利の住宅ローンで、銀行の変動金利よりは高いもののそれなりに安い金利で借りられる。もはや最後の望みだったわけだが、なんとか審査が通り無事に住宅ローンを組むことができた。

物件の購入費用

住宅ローンを組んだとはいえ、ある程度は手元にお金もないと物件が買えない。住宅ローンで100%借りることもできるようなのだが、金利の都合もあり90%借りてあとは自己資金でなんとかすることにした。自己資金といっても貯金だけでなく親戚から借りたお金もある。 物件を購入する際には物件の価格だけでなく他にもお金がかかる。

  • 物件の金額 (頭金で100万円を先に払った)
  • 不動産業者への手数料
  • 司法書士への依頼料
  • 瑕疵保証の保険金 (後で説明)
  • 不動産取得税 (物件を取得した翌年に発生する)
  • 固定資産税の立替

意外だったのが固定資産税の立替だった。僕は知らなかったのだが物件を購入するときに売り主の固定資産税を買い主が支払うということが慣例となっているそうだ。固定資産税は1月1日時点でその物件を持っている人にかかるので、今回のように3月末に物件を買った場合1年間のうち物件を持っていない期間のほうが長くなるので、その分を立替えるということらしい。住民税とかは立替ないのに固定資産税だけ立替えるのがちょっと納得いかないし、税金を立替えるというのも変な話だと思うのだが…。

物件購入前の建物診断と瑕疵保証

中古物件の購入だったので建物診断を第3者に依頼することにした。建物診断とは物件の耐震や劣化具合などを調査することで、物件購入前に売り主の承諾を得て行うことができる。費用はだいたい10万円くらいが相場らしい。物件購入は高い買い物だし、今回は瑕疵担保責任なしで買うので購入後のトラブルを避ける意味でも建物診断は重要だったと思う。

結果的には物件の状態がきれいだったこともあり大きな問題は見つからなかった。それでも一応建物診断に対する瑕疵保証を入れることにした。これは住み始めてから診断した範囲に対してなにか欠陥があった場合に瑕疵として保証してくれるというもの。 またこの瑕疵保証があると住宅ローン控除の対象に含まれない物件でも含むことができるようになるなどのメリットもある。(今回の場合はもともと築20年未満の物件だったので住宅ローン控除の対象内だった) 瑕疵保証の代金が1年間で5万円程度だった。少し高いがこれも一応入った。

住み始めてから大変だったこと

電気給湯機が壊れていてエコキュートを買った

建物診断と瑕疵保証まで入れていたにもかかわらず、実際に住み始めてみると少しトラブルがあった。まずお湯が出なくて調べてみたら給湯器が壊れていた。オール電化物件なので大型の電気給湯器がついていたが、どうもこれが物件を建てたときに設置したもので20年ほど前のものだった。業者に調べてもらったが、途中のパイプに亀裂が入っていてそこからドバドバ水が溢れていて素人目に見てもだめだった。20年前の商品なのでメーカーも修理の部品の在庫がなく、電気給湯器ごと取り替えることになった。

これが結構高かった。良い機会なので電気給湯器をエコキュートに変えたのだが、エコキュートは定価で80万円くらいする。物件購入、引っ越し直後にこの値段はきつい…。たまたまキャンペーン中の商品で40万円で買えるエコキュートがあったので迷わずそれにした。エコキュートとしてはかなり安いがそれでも結構な出費だった。ぎりぎり払えてよかった。

給湯器は建物診断時にチェックできなかった部分だったので瑕疵保証の対象にならなかったし、助成金などもなかったので完全に自腹だった。

下水がつまり気味で高圧洗浄した

キッチンの下水がつまり気味で業者に高圧洗浄してもらった。これも建物診断ではわからない部分なのと洗浄は欠陥ではないということで瑕疵保証の対象外だった。そういう意味では石橋を叩いて渡ったつもりでも瑕疵保証いらなかったかもしれない。築年数がそれなりの物件なので下水道の洗浄くらいはいずれにせよ必要だった気がする。費用はうろ覚えだけど5~8万くらいだった。

エアコン取り付け工事費用が追加でかかった

サカイ引越センターで引っ越しをした(東京から静岡の長距離移動なので対応してくれる業者は大手のみだった)のだが、その際にサカイ引越センター経由で家具を買うことができた。家電量販店などで買うよりも少し安かったのと運搬費などが引越し費用に含まれるので割安だったため、冷蔵庫とエアコン2台を買うことにした。

冷蔵庫は事前に天井の大きさを図っていたがギリギリ入るサイズで買ったのでやや不安だったが、実物が届いてみたらちょうどぴったり収まったのでよかった。色も備え付けの食器棚がブラウンだったのでそれに合わせてブラウンの冷蔵庫にした。また右開き左開きが選べたので、そのへんも家具の配置にあわせていい感じにした。中古家電ではなく新品で買うとこの辺の融通がきくのが良い。

エアコンはもともと通気孔が空いている部屋が2部屋しかなく、とりあえずその部屋に導入することにした。ダイキンの「うるさら」というやつで、換気ができるエアコンとして売り出されていた。在宅ワークなので家のエアコンを使っている時間が結構長いため値段はそれなりにするが高品質のエアコンを買うことにした。 エアコンは1階と2階に1台ずつ取り付けたのだが、室外機がいずれも1階の外に置く設計だった。そのため配管とそのカバーに長いものが必要になって追加で工事費用が5万円ほどかかった。カバーはなくてもいいとは言われたのだがあったほうが劣化しづらいとか見栄えが良いとかなので、これは結果的にはつけてよかったと思っている。

この辺の細かい出費はあったもののエアコンに関しては結構満足していて、換気ができるという謳い文句の通りでこのエアコンは使っていてもあまり空気が乾燥した感じがしない。自動洗浄機能もついているのでカビも生えづらそうだ。

この辺の話を同人誌にしました

三島市移住の話を妻と2人で同人誌にしました。まだまだ移住についての話題は尽きないのでぜひ買ってみてください。また他の方へのインタビュー記事もあります。全体的に漫画で読みやすくなっています。

assam.booth.pm

電子版をkindleでも販売しています

お絵かきおじいちゃんになりたい

$
0
0

お絵かきおじいちゃんっていいですよね


www.youtube.com

柴崎さんが好きでファンレターを送ってしまった。お元気でいてほしい。

歳をとっても趣味のある人でありたい。「あとは死ぬだけ」とか言ってる老人が一番嫌いだ。

大学生くらいの頃から本格的に絵を書き始めて下手なりにダラダラ続けている。 毎日書く時期もあるけど全く書かない時期もある。本職のプログラマが忙しくてかけない日もある。 デジタル画は特に苦手なのだがこれも以前よりはできるようになってきているので少しずつ上達したい。

しかしお絵かきおじいちゃんを目指すならアナログ絵を極めたい。 デジタル絵はデータだから消えてしまいやすいけど、アナログ絵なら遺品として残りそうだ。 それに年取ってからパソコンやるのしんどそうだし、どうせならコンクールに出したりもしたい。 古典的な道具で絵を書くほうがお絵かきおじいちゃんっぽくて憧れるというのもある。

とはいえ僕は女性画を書くことにしか興味がない。もともとエロマンガを書きたくて絵を書き始めたようなものなので、風景とか静物とかいまいち楽しくなくて今でも女性画ばかり書いている。 お絵かきおじいちゃんになったら「もうおじいちゃんたらまたいやらしい絵書いて!」と怒られるようなスケベじじいになりそうだ。 ルノワールだって女がいなければ絵なんて書かなかったみたいなことを言っていたらしい(要出典。実際男性画は殆ど書いてない)し、自分の書きたいものが定まっていることは良いことだと思うことにしよう。 プロの画家を目指しているわけでもあるまいし、自分の書きたいものをかければそれでいい。

鉛筆画

デッサンが割と好きだ。昔、社会人2年目くらいの頃にデッサン教室に半年ほど通っていた。 今にして思うとあまり良い教室ではなかったが、紙と鉛筆の使い方くらいは教えてくれた。 そのへんの経験を踏まえて僕なりに意識していることがいくつかある。

  • 大きい紙に書くこと
    • 僕はF6の紙を使うことが多い。F8だと少し大きすぎて邪魔くさい。
  • いろいろな鉛筆を使う
    • H4, H2, H, HB, B2, B4, B6, B8, B10 を使っている
    • 鉛筆は安いし手に入りやすいので三菱のuniを使っている
  • 塗り絵にならないようにする
    • ほどほどに形をとったらさっさと塗る。塗りながら修正する

最近は鉛筆そのものだけでなく鉛筆シャーペンみたいなものも使っている。

これは鉛筆の太さの芯を入れることができるシャーペンで普通の鉛筆とくらべて削らなくていいし、長さも変わらないのが良い。ペン先が少し重いので書きやすいのも気に入っている。

とはいえデッサンにしろアートとしての鉛筆画にしろ、美大に通ったわけでもなく自分に基礎があると思えない。 デッサン教室というのも石膏や身近な静物(花とか消化器とか)を書くだけで人物デッサンではなかった。 それにどうも自分の悪い癖で何事でも自分がやってることに横から口を挟まれるのが我慢できない。人から教わるのが下手なのだ。 何度か参加したコスプレのクロッキー会などは楽しかったのでまた参加したいのだがあまり開催されないのが残念だ。

思い返してみれば人物デッサンを習う機会がなかった。たまにクロッキー会に参加することはあったが、いわゆる長い時間をかけて実際の人物を見ながらデッサンするという経験はない。僕の場合はヌードポーズ集をたくさん持っているので、それをパラパラめくりながらクロッキーをしたりデッサンをしたりする。こういうところも画家もどきという気がする。

このシリーズが好きで何冊も持っている。

f:id:kbaba1001:20211006073038j:plain

顔を書くのが苦手だ。難しい。顔というか頭。体とのバランスが一番狂いやすい気がする。絵の中で一番目に付きやすい部分でもあり難度が高い。

ペン画、クロッキー

ヌードポーズ集をめくりながらクロッキーをする。鉛筆でかるく下書きをしてペン入れする。こんな感じ

僕の場合、下書きと言ってもちょっと当たりをつける程度だ

鉛筆で書いた丸とかがうっすら見えているが下書きと言ってもこの程度でガッツリ書くことはしない。指とか顔、髪など細かい部分はペン入れのときに一発がきすることが多い。下書きはどうせ消すものなのであまり時間をかけたくないのでさっさとペン入れしたいというせっかちな気持ちもある。多少雑になったとしてもスピードを優先する。書き上げたければ早く書かなくては。

クロッキーなのにペン入れする理由が少しある。

  • ペンのほうが鉛筆より線がはっきりするので見やすい。鉛筆だけで書くとあたり線と実線の区別がつかない
  • ペンのほうがやり直しが効かないので集中できる(気がする)
  • ペンのほうが短時間で仕上がりが良くなる

もともと学生時代にノートをとるようなときもシャーペンや鉛筆を使わずにボールペンだけを使っていた。なんとなくボールペンやミリペンのしっかりとした黒い線が好きだ。鉛筆の線というのは薄くて頼りない。消しゴムで消せるのはいいんだけどやはり迫力に欠ける感じがする。

使っている道具としては次が気に入っている

  • プロッキーの黒、グレー、薄橙
    • 長年プロッキーの黒をペン入れに使ってきた。画材屋ではなくコンビニや文房具屋でも手に入るのが良い。油性ペンと比べて裏写りしないのも良い。クロッキー帳に書くことが多いので紙が薄いから油性ペンだと裏写りする。
    • グレーや薄橙は影を塗るために使う。黒単色よりちょっと2色、3色にすることでお洒落にできる
  • ぺんてる プラマン
    • 最近使い始めて気に入っている。ようやくプロッキーより良さそうなペンを見つけたように思う。細い、太いを角度によって変えられるのが良い。今は使い捨てタイプを使っているがインク交換タイプを今度買う予定。
  • 新ペン先 スクールG ブラック NP40ABK-F
    • あまり使わないけど顔などの細かいところを書くときに持ち運びできるGペンを使っている。

ここまでの話で気づいた人もいると思うけど、僕の道具選びは手に入りやすいことを割と重要視している。地方に住んでいるので画材屋が少ないということもあるし、絵を書くために大げさな道具を使いたくないという気持ちもある。出先で絵を書きたくなったときに画材を持ってないこともあってそういうときにコンビニで手に入るような道具で絵を書くことになれていれば便利だ。 また持ち運び性も重要でかばんの中に小さなスケッチブックと数本のペンと鉛筆を入れておきたい。出先の数分の空き時間に絵を書くことも多いので、持ち運びに不便な絵の具などは選択肢から外れてしまう。

例えばこれは中華料理屋で書いたもの。こういうちょっとした絵日記を15分くらいでかけると格好いい。

個展をやります

12月の最初の週、12/4から12/12で沼津の喫茶店フランで個展をやります。また特設ページやパンフレットを作るつもりなのでアナウンスします。

Clojureで仕事をはじめて1年経った

$
0
0

qiita.com

2021年1月から Clojure を使って仕事をしている。長年主にRubyを使った受託開発をしてきたのだが、今年はかなりClojureメインで仕事をすることができた。

Ruby から Clojure へ

Ruby にあまり不満はなく(Railsには多々あるが)今でも十分に好きな言語なのだが、数年前から趣味で触り始めた Clojure が存外によくてもっとこの言語を触っていたいという気持ちが自分の中で高まっていた。 Clojure は Lisp とか JVM 上で動くとか色々特徴のある言語だが、僕としてはそういうのは Clojure を構成する要素の一つでしかなくて、もっと重要なことは Clojure の世界観とか Rich Hickey の設計に対する考え方とかで、僕としてはそういう部分に魅力を感じている。 この辺の話は t_yano さんのブログにわかりやすくまとまっているので読んでみてほしい。

boxofpapers.hatenablog.com

boxofpapers.hatenablog.com

Ruby と Clojure は色々と似ている部分もあって、例えば Hashmap をうまく使おうとするところや map/reduce のサポートがしっかりしているところなどがある。根底にあるものが Ruby はオブジェクト指向であり Clojure は関数型という違いはあるものの両者はよく似ている(と僕は思っている)。

僕が Rails や Hanami でやっていたサービス層をつくってドメインロジックをまとめる設計はコマンドパターンでクラスをつくる方法をとっていたがこれはそれなりに冗長なやり方でもあって、 Clojure だとただ関数を定義するだけでほとんど同じことができた。 仕事でも趣味でも主に duct (または integrant ) を使っているのだが duct はとても疎結合にシステムを構築することができる。 duct の本質は設定用の edn ファイル (他言語でいうjsonみたいなもの) で各関数をどのように結合するかを定義することにある。関数がどの関数を呼び出すかという非常に密結合になりやすい部分が duct (integrant) を使うと疎結合にできる。しかもそれを実現する方法は multimethod という clojure の機能をうまく使っていて duct (integrant) は非常にコンパクトに作られている。 Rails や Hanami のようなフルスタックのフレームワークと duct を比較するのも無理があるが duct のシンプルさには驚いた。

Clojureを仕事にする

フリーランス(今は法人化しているので社長だが)として仕事をするメリットはやりたいことを選べることじゃないだろうか。 自分一人分の売上をあげるだけなら案外なんとかなる。会社にいると会社の方針や人間関係により選択できる技術や仕事が限られてくるが、フリーランスだとある意味どんな仕事でも受けることができる。今までRubyの案件が多かったが、試しにClojureの仕事を探してみることにした。

Clojure は日本で採用している会社がすくないが何社か営業してみたところ運良く1社から良い返事をいただくことができて2021年1月から契約を始めた。 また duct (integrant) を採用していたので事前知識を活かすことができた。

仕事で Clojure を書いてみて思ったこととしては

  • 楽しい (一番大事)
  • コードレビューで他の人のコードが読めるようになるまで少し時間かかった
  • コードを書くのは最初からあまり問題なかった

コードを書くとき僕はまず既存の設計を理解してそれに沿うように書くことにしている。 そのためまず既存のコードを読まなければならない。これは duct (integrant) という枠組みのおかげもあり理解が早かった。 duct (integrant) の場合、 config.edn を読めばどの関数がどの関数に依存しているかわかる。

次にコードを書くステップになるわけだけど、これも自分の考えを表現する作業なので楽しい。 Clojureの場合ドキュメントがしっかりしているので ClojureDocs を見ればコードが書ける。

clojuredocs.org

コードレビューはそれまでの前後関係を理解してないと読めないので、読めるようになるまで少し時間がかかった。 Clojureの特徴としてコードが短くなるというのもあって、「この reduce の処理何やってるんだ」みたいなことを理解するのにはじめは時間かかった。 Clojureの場合前提としているデータ(だいたいHashmap)がどのような構造をしているかが分かりづらいことがあって、 コツとしてはそこをきちんと理解していれば読みやすくなる。 このへん、やはり Clojure Spec などで明記するようにしたほうがコードは読みやすくなる気がする。

改めて感じた Clojure のよさ

大量のカッコを伸ばしたり縮めたり、ゴムのような言語だなと感じている。 if とか for とかも全部関数なので必ず戻り値があるからどこにでも差し込めるのが良い。

threading macro (->とか->>とか) を使えばデバッグ処理を差し込みやすいのも好き。 例えば

(->> data
      (map(fn[d](...)))(filter(fn[d](...))))

こんな感じの処理があったときに

(->> data
      (map(fn[d](...)))((fn[a](prn a) a))(filter(fn[d](...))))

こんな感じで print デバッグできる。map関数の結果を prn で表示して結果を filter の方に渡す。 処理を邪魔することなくデバッグを追加することができる。こういうのがなんとなく気持ちいい。

やはり関数を並べるだけで処理が作れるのは便利だ。 some->なんかも好き。 some->は並べた関数を ->で実行する関数だけど途中で nilを返した場合そこで処理が終わる。 これにより正常系ではデータを作っていって、異常系では nil を返して処理を中断するということができる。便利。

Clojureの良さは色々感じるけどやっぱり上記のような関数として処理を構築するという部分が一番楽なきがする。 たまに手続き書きたくなることがあるけど案外全部宣言的にかけるものだなとも思った。

Clojure と頭の中、呼吸、あるいは自由に動けるようになるまで

$
0
0

はじめに ()ありき。Clojureでは何かをしようとしたときまず ()を書く。ときどき []だったり {}とか #{}とかだったりもするが、とりあえずカッコから始まる。

次はどうなる? あぁ、関数を定義しようと思ったんだった。

(defn)

名前をつけてやろう。

(defn foo)

ついでに引数も。

(defn foo [{:keys[bar]}])

おや?少し様子がおかしい。

もちろん (defn foo [bar])でもいい。でも僕は (defn foo [{:keys [bar]}])のほうが好きだ。

これは Destructuring (分配束縛) というやつで、(foo {:bar 1})のような呼び出しをするときに便利だ。 Clojure では HashMap {}を使ってデータをまとめることが多いからはじめから HashMap を渡す想定で引数を設計しておくと、あとから引数を増やすことになったときに便利だ。

まぁともかくこんな感じで Clojure を書いている。プログラミング言語は思考に影響する。自分なりのコードの考え方、捉え方がたぶん人それぞれあって、それは呼吸のようなもので自分にあった言語であれば体は自由に動く。逆に合わない言語であれば不調をきたす。具体的には僕の場合Go言語を書くと顎関節症になる。コード、ひいては設計は次に自分がどう動くかを決定する。Clojureはゴムのような不思議な言語だ。伸びたり縮んだりしながら変化を受け入れる。 例えば、

(defn hello-jp [{:keys[user-name]}](prn(str"こんにちは、" user-name "さん")))(defn lang-en [{:keys[user-name]}](prn(str"Hi, " user-name)))

こういうコードがあるとき別の実装を

(defn lang-ch [{:keys[user-name]}](prn(str"你好、" user-name)))

のように追加することはかんたんだけど、こういう似た者同士はまとめたくなるのが心情なわけで、いくつかやり方はあるけど例えば

(defmulti hello
  (fn[{:keys[lang]}] lang))(defmethod hello "jp"[{:keys[user-name]}](prn(str"こんにちは、" user-name "さん")))(defmethod hello "en"[{:keys[user-name]}](prn(str"Hi, " user-name)))(defmethod hello "ch"[{:keys[user-name]}](prn(str"你好、" user-name)))

こんな風にしておくと

(hello {:lang "jp" :user-name "馬場"})

みたいにして呼び出せて便利。HashMapの値で呼び出す関数をかえるっていうよくあるシチュエーションにおいて、なんとなくメタプログラミングでもしたくなるような気もするんだけど、この defmultidefmethodというやつを使うとメタプログラミングしなくてもスッキリ書ける。しかもこれはオープンクローズドの原則に沿っている。 defmethodを追加するとき他の defmethodやさらには defmultiのことも気にしなくていい。 この考えを推し進めると integrantductのようなライブラリになっていくのだけれど、その話は今日はしない。 defmultidefmethodは Clojure のもつ不思議な機能の一つにすぎなくて、この言語はもっと色々な風変わりな機能がある。

ところで、 Clojure はいくつか実装があって、一般的に単に Clojure という場合 JVM の上で動く Clojure のことを指す。他にも JavaScript にビルドできる ClojureScript とか C# になるやつとか Erlang になるやつとか色々ある。 あなたは知らないかもしれないけど、この地球にはすべてを Clojure で書きたいと思っている人類が若干名いるということだ。 で、こういう他言語をラップしてしまう言語は他にもあるけど Clojure たちがちょっと他と違うのは Clojure が元々の言語を呼び出すことにあまり抵抗がない点だろうか。

例えば、 JVM の Clojure には Stack がない。基本的なデータ構造にも関わらず提供されてない。アルゴリズムを書くときに時々 Stack は使いたくなるわけで、じゃあどうするかというと Java の Stack をそのまま拝借する。

(let[stack (java.util.Stack.)](.push stack 1)(.push stack 2)(.pop stack));; 2 が出力される

java.util.Stack.は Java でいうところの new Stack<T>()みたいなもので、 Java のクラス名の最後に .をつけると newの意味になる。 で、そうして作ったオブジェクト (上記のコードで言う stack変数) を第1引数にして .関数名を呼び出すとメソッド呼び出しができる。 ちょっと奇妙な構文だけど、Clojureの元々ある関数型言語としての機能を活用するにはこれが実は便利だ。

突然だけど hello worldという文字列をすべて大文字にしてシャッフルして重複を取り除いた文字列を作りたくなった。(実は最近これに近いコードを実際に書いたんだ)

(clojure.string/join (distinct(shuffle(map clojure.string/upper-case "hello world"))));;=> "HL EWODR"

でもこのコードはなんとなく読みづらい。処理の起点が右の方に偏っているから右から左に読むのはなんとなく気持ち悪い。 だからぼくならこう書く。

(->> "hello world"(map clojure.string/upper-case)shuffledistinct
     clojure.string/join);;=> "LDRHW OE"

読みやすくなったね。

え?よくわからない?

->>は関数の実行結果を次の関数の引数の末尾に入れてくれるマクロだ。ちなみに引数の最初に入れてくれる ->もあってこれもよく使う。 詳しくは公式のガイドでも読んでくれ。

clojure.org

->->>のいいところは処理の途中に別の処理を挟み込みやすくなること。例えば途中でプリントデバッグしたくなったら、

(->> "hello world"(map clojure.string/upper-case)shuffle((fn[a](prn a) a))distinct
     clojure.string/join);;["O" "H" "E" "L" "L" "D" "R" " " "L" "O" "W"];;"OHELDR W"

こんな感じにしてやればいい。 ((fn [a] (prn a) a))は個人的によく書くイディオムで、 (fn [a] (prn a) a)は引数 aをとってそれを表示してそのまま aを返すだけの関数なので、それを実行するためにさらに ()でくくっている。

(->> "hello world"(map clojure.string/upper-case)((fn[a](prn a) a))shuffledistinct
     clojure.string/join)(->> "hello world"(map clojure.string/upper-case)shuffledistinct((fn[a](prn a) a))
     clojure.string/join)

位置をずらせばどこでもデバッグできる。メソッドチェーンの間にデバッグ処理をかんたんに差し込めるのは便利だ。もちろん他の処理を差し込んでもいい。 他の言語でも似たような機能はあるけど、引数に与える関数を増やすだけで処理を変えられるのってなんとなく気持ちいい。 (->>)のカッコがゴムのように伸びていく感覚がわかるだろうか?

さっきからゴムのように伸び縮みするという変な言い回しを好んで使っている。なんのことだろう? 実はこれはエディタの機能にも関係がある。僕は Clojure を書くとき paredit という機能を使っている。

calva.io

例えば、

(->> "hello world"(map clojure.string/upper-case)shuffledistinct)
clojure.string/join

これを

(->> "hello world"(map clojure.string/upper-case)shuffledistinct
     clojure.string/join)

こうしたい。あるいは

(map clojure.string/upper-case "hello world")

これを

(map clojure.string/upper-case)"hello world"

こうして

"hello world"(map clojure.string/upper-case)

こうして

(->>)"hello world"(map clojure.string/upper-case)

こう

(->>
    "hello world"(map clojure.string/upper-case))

わかった?

(map clojure.string/upper-case "hello world")(map clojure.string/upper-case)"hello world"

この動きを Barf Forward といい、

(->>)"hello world"(map clojure.string/upper-case)(->>
    "hello world"(map clojure.string/upper-case))

この動きを Slurp Forward という。

)の位置を式(フォーム)に対して伸ばしたり縮めたりする。引数を式から追い出したり取り込んだりする。これによってコードが出来ていく。 この感覚をぼくはゴムのようだと思っている。

あぁそういえば ( )の多さが気持ち悪いんだっけ? 大丈夫、すぐに見えなくなる。伸ばしたり縮めたりすればいいだけだから。

さて、だいぶ Clojure を書いているときの頭の中がわかってきたかな?言語で呼吸をする感覚はその言語で次にどう動くかが見えたときにわかる。それは単に ( )を移動させているときだったり、設計を大きく変えるときだったり、色々だけど次の一手を考えたとき自分が動きたいように言語が動いてくれると気持ちがいい。それが合わないとコードは書けない。

SanctuaryJSのメモ

$
0
0

github.com

JavaScript で関数型言語っぽいコードを書けるようにするためのライブラリ

utils/sanctuary.jsとりあえず動かすための設定。

import{ create, env } from 'sanctuary';

const S = create({
  checkTypes: process.env.NODE_ENV !== 'production',
  env: env
});

exportdefault S;

これを import S from '../utils/sanctuary.js'みたいにして使う

map

https://github.com/sanctuary-js/sanctuary#map--functorf--a-b---fa---fb

 S.map (Math.sqrt) ([1, 4, 9])

Objectに対する map

S.map(([k, v]) => [v, k])(Object.entries({ a: 1, b: 2 }))

reduce

https://github.com/sanctuary-js/sanctuary#reduce--foldablef--b-a-b---b---fa---b

S.reduce (S.add) (0) ([1, 2, 3, 4, 5])

append (conj), prepend(cons)

https://github.com/sanctuary-js/sanctuary#append--applicativefsemigroupfa--a---fa---fahttps://github.com/sanctuary-js/sanctuary#prepend--applicativefsemigroupfa--a---fa---fa

> S.append (3) ([1, 2])
[1, 2, 3]> S.prepend (1) ([2, 3])
[1, 2, 3]

pipe

https://github.com/sanctuary-js/sanctuary#pipe--foldablef--fany-any---a---b

関数を合成して実行する

> S.pipe ([S.add (1), Math.sqrt, S.sub (1)]) (99)
9

pipeK

https://github.com/sanctuary-js/sanctuary#pipek--foldablefchainm--fany-many---ma---mb

複雑な条件分岐を伴う処理を関数で書きたいときに maybe モナドや either モナドを使って実装すると楽な時がある。 pipeKを使うとモナドに対して関数合成をいい感じにやることができる。 例えば maybe モナドの場合、

S.fromMaybe("none")(
  S.pipeK([
    v => (S.size(v) <= 0 ? S.Nothing : S.Just(v)),
    v => S.Just(S.filter(S.odd)(v)),
  ])(S.Just([1, 2, 3]))
)
//=> [1,3]

S.fromMaybe("none")(
  S.pipeK([
    v => (S.size(v) <= 0 ? S.Nothing : S.Just(v)),
    v => S.Just(S.filter(S.odd)(v)),                         //上の関数が S.Nothing を返すのでここは実行されない])(S.Just([]))
)
//=> "none"

同様に either モナドの場合、

S.either(x => x)(x => x)(
  S.pipeK([
    v => (S.size(v) <= 0 ? S.Left("none") : S.Right(v)),
    v => S.Right(S.filter(S.odd)(v)),
  ])(S.Right([1, 2, 3]))
)
//=> [1, 3]

S.either(x => x)(x => x)(
  S.pipeK([
    v => (S.size(v) <= 0 ? S.Left("none") : S.Right(v)),
    v => S.Right(S.filter(S.odd)(v)),
  ])(S.Right([]))
)
//=> "none"

either モナドは異常系をLeft、正常系をRightに入れる。 maybeモナドと異なり異常系のときに値を取ることができ、それを S.eitherの第1引数で処理できる。

追記

単に monad を使いたいだけならこっちのほうが楽かも

github.com

Windows Surface pro 7 に debian testing をインストールしたメモ

$
0
0

準備とOSのインストール

まず

https://github.com/linux-surface/linux-surface/wiki/Installation-and-Setup#installation

に従ってパーティションの領域を確保する。今回はデュアルブートにするのでLinux用に 512 GB の空き領域を作った。

次に Debian の USB を他の Linux マシンで作っておく。iso ファイルをダウンロードしておいて

cp debian.iso /dev/sdc

みたいにすればUSBに焼き込むことができる。

一度 surface の電源をシャットダウンする。その後、USBを指してボリュームダウンボタンを押した状態で電源ボタンを押す。するとUSBからブートできるので debian をインストールする

Surface 用のカーネルなどのインストール

https://github.com/linux-surface/linux-surface/wiki/Installation-and-Setup#Debian--Ubuntuに従ってインストールする。

ただ、 https://github.com/linux-surface/linux-surface/wiki/Surface-Pro-7にあるように kernel boot parameter を設定する必要がある。

これの設定方法は https://askubuntu.com/questions/19486/how-do-i-add-a-kernel-boot-parameterにあるように /etc/default/grub中の GRUB_CMDLINE_LINUX_DEFAULT="quiet splash reboot=pci intel_iommu=off"のように編集する。

その後、 sudo update-grubする。

なぜか再起動は上手くできないので sudo shutdown -h nowでシャットダウンしてから電源を入れ直す。

wifi と bluetooth 用の設定

intel の wifi を使っているようなので、

sudo apt install firmware-iwlwifi

する。これで再起動すれば wifi と bluetooth が使えた。

Raspberry Pi でラジコンを作った

$
0
0

知人の子供がロボットが好きらしくてロボット作りを教えてあげることになったので Raspberry Pi でラジコンを作ってみた。 以前からプログラミング教室みたいなことをやってみたいと思っていたのでよいトライアルになりそうだと思った。

背景・気持ち

世間のロボット教室とかプログラミング教室について思うことなど

Scratchとレゴ多すぎじゃなかろうか。いや、気持ちはわかる。指導しやすいと思う。Raspberry Pi で GPIO 出力だの Python だのやり始めると工具は必要になるし、はんだ付けを子供にやらせるのは不安だし、タイピングを習得してないかもしれないからPythonを書くところまでたどり着けないかもしれないし、色々と余計なことに気をとられるのは目に見えている。それにくらべてScratchとレゴはタイピングもいらないし工具も必要ないし完璧だ。ロボット作りやプログラミングに集中して指導できる。

しかしそれでいいんだろうか。ものづくりってそういうものだっけ?工具も使わずにレティメイドなものを組み合わせることが工作だったっけ?

いや、やっぱり違うだろう。ものづくりというのは、工作とは、とりあえずグルーガンでなんとかするとか丸鋸持ってないから手のこでなんとかするとか、なんかそういう雰囲気というかやっつけ感というか、行き当りばったりな要素が強いことなんじゃなかろうか。

いわば実験。試行錯誤。それこそがものづくりであり工作であり、いわゆる考える力みたいなものにつながるんじゃなかろうか。 最初から完成すること、成功することが見えているのは工作じゃない気がする。僕も昔から色々作ってるけど途中でうまくできなくて投げ出したものなんかたくさんあるし、でもそれも無駄じゃないかなと思う。

なぜ Raspberry Pi なのか

  • Raspberry Pi はもともと教育用なので子供でも十分使えるはず
  • ノートパソコンなどに比べると安い。キーボード、マウスは安物で十分だし、モニターは家のテレビでも代用できる
  • IoTできる。子供むけに指導するなら画面の中のプログラミングだけよりはモーターとかで実際に動くもののほうが良いのではないか
    • この辺が chrome book を選択しなかった理由
  • Web上の資料・本などが多い。これは初心者には重要な要素
  • 本人の技術力や年齢が上がっても使える
    • 特に Raspberry Pi 4 8GB モデルなら長く使えそう。400のもうちょっと性能いいやつが出ればそれがベストか?

参考図書

自分一人で作るだけならネットの情報だけで十分なのだが、今回は子供に教えるので参考図書を用意した。

Raspberry Pi の基本的な使い方からモーター制御まで一通りのっているので良さそうだなと判断した。

ラジコンづくり

ロボット作りは物理的な工程が9割

ロボット作りにおいてプログラムを書く工程なんて最後の方にちょこっとあるくらいで、苦労するのは物理的なメカトロニクスの部分だ。 というわけで今回のロボット作りは

  • 車体づくり
  • 配線
  • プログラミング

の手順で行った。

車体づくり

タミヤを信じろ。今まで何度買ったのかよくわからないくらいタミヤのモーターギヤーセットは買っているし、キャタピラも何度買ったかよくわからない。

タイヤじゃなくてキャタピラにしたのは、次の理由による

  • 見た目が格好いい
  • タイヤよりゆっくり動くので操縦しやすい
  • モーター、ギアのトルクさえ出せればタイヤより安定して動く(気がする)

というわけで次を購入

モーターとギアのセット

土台となる部分

キャタピラ

単3の電池ボックス

電池ボックスは2つ買った。はじめは3Vで十分だと思っていたけど動かしてみたら明らかに電力が足りなくて2つつなげて6Vにしたらうまく動いた。

さらに Raspberry Pi を取り付けるのに便利そうな金具があったのでこれも購入。

こういうのがないと地味に木材とかでごちゃごちゃやる羽目になるので安いし買ったほうがマシ。

で、この辺を組み立てたのがこちら。

RaspberryPiラジコン
RaspberryPiラジコン

ここまでで軽く配線して走らせてみた。これはまだ電池とモーターをつないでるだけ。

モーター制御

まだ必要なパーツがある。それは Raspberry Pi 用のバッテリーとモータードライバ。 そもそもなぜ Raspberry Pi 用のバッテリーとモーター用の単3電池に分ける必要があるのかということを意識する必要がある。

モーターというのは内部で電流が流れたり途絶えたりしながら回転している。そのため電気回路的にはモーターというのは電流のノイズ発生装置でしかなく Raspberry Pi のような精密機械に直接つなげるとこのノイズが悪影響を及ぼして最悪壊れてしまう。そのため Raspberry Pi の GPIO ピンに直接 DC モーターをつないではいけない (PWM制御するタイプのサーボモーターなどは別)。

そこでモーターの電流のノイズが Raspberry Pi に影響を与えないようにするために回路を分けてやる必要がある。 このための方法はいくつかあるが(簡単にやるならリレースイッチを使うとか)、モータードライバという回路を挟む方法がよく使われている。今回は次のモータードライバを使った。

DRV8833

これにした理由は

  • 5つ入りで800円程度という安さ
  • Amazonに詳細な解説があった
  • モーター2個制御可能
  • 逆転も対応

という程度であまり深く考えずに買ったが、よく考えれば本に載っているの同じ基盤にすればよかった。 幸い動作は本に乗っているものとほぼ同じなので良しとする。

次は Raspberry Pi 用のバッテリーだが、車体にのる小さなもので電力が足りていればだいたい何でも良いはず。 もともと Raspberry Pi 4 用に買ってあったバッテリーがあるのでこれを使うことにした。

自分が持っているのは Aukey 製品だがどうみても同じものなので追加で1個購入した。 (中国だとこういう同じ商品をメーカーがラベルだけつけて売るというのが当たり前らしい。)

このバッテリーの良いところは、USB-A の端子と USB-C の端子が対面についていること。これにより USB-A 側を Raspberry Pi に向けて USB-C を外側に向けておけば USB-C で給電するときに楽。

今回使う Raspberry Pi は 3+ なので短めの micro USB 端子も必要だった。 まぁこの辺は 4 でも zero でも pico でもいいと思うので手元にある Raspberry Pi でやればいいと思う。 まだ Raspberry Pi を持ってないなら 4 の RAM 8GB モデルが一番性能が良いのでおすすめする。

配線

なるべくはんだ付けをしなくてすむように配線はブレッドボード上で行うことにした。

激安ブレッドボード

流石にモーター、電池ボックス、モータードライバの足などははんだ付けしたが、回路の配線はブレッドボード上でピンを挿せばいいのでやり直しもきくし便利だ。

配線して Raspberry Pi OS を起動した様子。

RaspberryPiOS起動
RaspberryPiOS起動

場所の都合でモバイルバッテリーとブレッドボードをモーターの上に両面テープで貼り付けることにした。丁寧に作るならもう少し台のようなものを作ればよいのだが。。。厚みのある強力両面テープをつかったので剥がすとき大変そう。。。

配線は次の図にしたがって行った。

配線図
配線図

プログラム

DRV8833 は IN1 に電流を流せば正転、 IN2 に電流を流せば逆転、両方に流す/流さない場合は動かないという挙動をする。これはA, B ともに同じ。 配線図をみてわかるように今回は GPIO 2〜5 を使ってモーターを制御することにしたので次のように電流を制御すればラジコンの動きを制御できることがわかる(Aが右側のモーターでBが左側)。

Oは電流を流す、☓は電流を流さない

これを踏まえて作成したコードがこちら

import pygame as pg, sys
import RPi.GPIO as GPIO
import time

pg.init()
screen = pg.display.set_mode((800, 600))
font = pg.font.Font(None, 50)
descriptionimg = font.render("Press cursor !!", True, pg.Color("Blue"))
upimg = font.render("UP", True, pg.Color("Blue"))
rightimg = font.render("RIGHT", True, pg.Color("Blue"))
leftimg = font.render("LEFT", True, pg.Color("Blue"))
downimg = font.render("DOWN", True, pg.Color("Blue"))

motorGpioA1 = 2
motorGpioA2 = 3
motorGpioB1 = 4
motorGpioB2 = 5

GPIO.setmode(GPIO.BCM)
GPIO.setup(motorGpioA1, GPIO.OUT)
GPIO.setup(motorGpioA2, GPIO.OUT)
GPIO.setup(motorGpioB1, GPIO.OUT)
GPIO.setup(motorGpioB2, GPIO.OUT)
GPIO.output(motorGpioA1, False)
GPIO.output(motorGpioA2, False)
GPIO.output(motorGpioB1, False)
GPIO.output(motorGpioB2, False)

whileTrue:
    screen.fill(pg.Color("WHITE"))
    screen.blit(descriptionimg, (200, 100))
    key = pg.key.get_pressed()
    if(key[pg.K_UP]):
        screen.blit(upimg, (200, 150))
        GPIO.output(motorGpioA1, True)
        GPIO.output(motorGpioA2, False)
        GPIO.output(motorGpioB1, True)
        GPIO.output(motorGpioB2, False)
    elif(key[pg.K_RIGHT]):
        screen.blit(rightimg, (200, 150))
        GPIO.output(motorGpioA1, False)
        GPIO.output(motorGpioA2, True)
        GPIO.output(motorGpioB1, True)
        GPIO.output(motorGpioB2, False)
    elif(key[pg.K_LEFT]):
        screen.blit(leftimg, (200, 150))
        GPIO.output(motorGpioA1, True)
        GPIO.output(motorGpioA2, False)
        GPIO.output(motorGpioB1, False)
        GPIO.output(motorGpioB2, True)
    elif(key[pg.K_DOWN]):
        screen.blit(downimg, (200, 150))
        GPIO.output(motorGpioA1, False)
        GPIO.output(motorGpioA2, True)
        GPIO.output(motorGpioB1, False)
        GPIO.output(motorGpioB2, True)
    else:
        GPIO.output(motorGpioA1, False)
        GPIO.output(motorGpioA2, False)
        GPIO.output(motorGpioB1, False)
        GPIO.output(motorGpioB2, False)

    pg.display.update()
    pg.time.Clock().tick(60)
    
    for event in pg.event.get():
        if event.type == pg.QUIT:
            pg.quit()
            GPIO.cleanup()
            sys.exit()

キーボードの十字キーでラジコンが動くようにした。無線のキーボードを使えば自由自在にラジコンを制御できるのでこれで十分だろう。

キーボードイベントを取得するために pygame を使った。もっと他の適した方法もある気がするけど、プログラミングを教えるのに良さそうだと思って買った次の本で pygame が使われていたのでこれにした。

自分が子供の頃にどうやってプログラムを書いていたかというのを思い出してみると、本に書いてあるサンプルコードを組み合わせて自分の作りたいものをなんとかでっち上げて動かしていた。型とかよくわかってなくて(当時使っていたのはVisualBasic 6.0 )integer だと動かないけど long にしたら動いたから long にするみたいなそんな感じだった。なので子供にプログラムを書かせるなら理屈はわからなくてもサンプルコードをがちゃがちゃやればなんとなく動くというあたりをやってほしいわけで、 前述の 『ラズベリー・パイで電子工作入門ガイド』と合わせてこの本をもっていた場合、なんとか組み合わせてプログラムが書けるみたいな状態になるので pygame をつかうのがよいと判断した。

動かす

コードがかけたら HDMI ケーブルを抜けば動かして遊ぶことができる。やったね


英語勉強は結局何をやったらいいのか

$
0
0

タイトルのとおりですが、

  • 英語日記
  • 発音

この2つです。

まぁよくある「英語の成績最悪だった俺が海外と仕事できるくらいに英語上達した方法」みたいなタイトルでも良かったんですが、もっと結論重視の話をしようと思いました。 なぜならこんな記事は総じて個人の体験談であり、自分に当てはめることができるかどうかわからない話だからです。 実のところ受験英語で十分話せるようになったという人もそれなりにいるのだと思うし、そういう勉強方法が向いているならそれが一番良いでしょう。

というわけで、「俺の環境では動いたよ」話をやっていきます。

英語日記を毎日書く

まず日記を毎日書くができない人にこの方法は向いてない気がします。その時点でほとんどの人類に当てはまりません。 が、まぁ、僕の場合は意外と筆まめなところがあって毎日ではないにせよ日記をなんとなく書き続けておりますので、英語日記という学習方法がそれなりに向いていたわけです。

英語日記といっても僕の場合ちょっと工夫があって、数ステップにわかれます。

  • 100ワード(I have a pen で4ワードみたいなかんじ)以内で日記を書く。難しければ 50 ワードでもいい。できれば毎日、難しければ週の半分くらい。
  • 書いた英文を解説付きで添削してもらう。
  • 添削された英文の解説を読んで英文を修正。
  • 出来上がった英文を3回くらい音読する
  • オンライン英会話などで話すときに日記の内容を思い出して話す(英会話は週1くらいでいい)
  • 上記を繰り返す

添削は IDIY というサービスを使っています。

idiy.biz

ちょっと料金体系が分かりづらいですが僕の場合「学べる定期券」「ライト」の「1日1回100単語まで」というのを半年くらい契約して、ほぼ毎日英語日記を提出していました。 IDIY は英検1級などをもっている日本人講師や英語ネイティブ講師に添削を依頼できるので非常に勉強になります。 IDIY については次の記事で詳しく書いたのでご覧ください。

www.kbaba1001.com

英語日記をオンライン英会話の予習として活かす

英文を書いたあと音読して英会話に活かすという話は Hapa 英会話の Jun さんが紹介していて取り入れました。

hapaeikaiwa.com

たしかにオンライン英会話って週末やってたこととか趣味の話とかしがちなので英語日記で十分な予習になるんですよね。 自分の使いたい表現とかを予め予習できていると英会話がかなり話しやすくなりました。

英語が出てこない状態を脱する

オンライン英会話にチャレンジしたことがある人なら解ると思いますが、最初のうちはどんなに簡単な言葉であっても口から出てきません。 それこそ How are you? に対する返事一つまともにできないということもある気がします。

その状態をなんとか脱していかないと会話が成り立たないわけですが、僕の場合上記の英語日記による予習で自分の言いたいことについては話せるようになりました。 (これだけだとリスニング力は伸びないので相手の言ってることはよくわかりませんでした)

とにかくSVOCの順番で言葉を並べないと英文にならないわけで、これは日本語で言えば常に倒置法で喋っているようなものです。 その感覚がはじめ全くつかめなかったわけですが、英文を書くことで文法に対する意識が芽生えて少しずつSVOCで言葉が出てくるようになりました。

英文を書くことで文法を "使う"という感覚が身につく

学生時代、とにかく文法の勉強というのが嫌いでした。ルールがあるようで例外が多く、暗記させられるのが嫌でした。 しかし英語日記を書こうとするとどうしても文法を意識しなければなりません。 このとき初めて文法を"使う"という感覚が芽生えました。

文法を覚える、読解に使うだけではどうも不十分でした。 プログラミングをするときもそうですが、とにかく書いてみないと使い方がわかりません。

英文を書き「もっと格好いい表現をするにはどうしたらいいのか」「もっと適切な言い回しはないか」を考えると自然と文法や構文を覚えるようになりました。

また、 a と the の違いのような細かい指摘を受けられるのもの英文添削の良いところです。 会話ではここまで指摘されずなぁなぁになりがちなところが文章であれば見過ごされることなく指摘されます。

ELSA Speak で発音を鍛える

英語日記で英語をアウトプットすることはかなりできるようになりましたが、一方でリスニング力が上がっておらず、オンライン英会話をするとこちらから一方的に話すことはできるのですが、相手の言っていることがよくわからなくて適当に話をするということになりがちでした。 そもそも相手の英語の発音も国によって違いますし、マイクの音質も人によって違うので結構オンライン英会話は難しいように思います。

とはいえ、発音を練習していたらだんたん耳もなれてきてリスニング力も上がってきました。 やはり自分なりに正しい音を認識しておかないと聞き取りもできないということでしょうか。

シャドーイングとか自分の発音を録音するとかいろいろ方法はあると思いますが、僕の場合は ELSA Speak というアプリをずっとやってました。

elsaspeak.com

ELSA Speak ではサンプルの英文を読み上げるとそれをAIが添削してくれます。かなり細かく添削してくれるので、日本人が苦手な L と R の違いなどはもちろんのこと曖昧母音や s, th, などのサ行系の音の違いなど幅広く練習することができます。 ぼくは上級者モードでやってるのでかなり厳し目ですが、辛い方は初心者モードからやると良いと思います。

まとめ

自分の英語力はまだまだですが、30歳前後で英語の学習をやっている割には能力として伸びてきたのではないかと思ってます。 ネイティブのスラング混じりで早い言い回しなんかは全然聞き取れませんが、non-native と仕事の話をするくらいはなんとかできています。

ここに書いてないことでやったことといえば英検の勉強をやっていたくらいでしょうか。それも準2級を受かっただけであまりきちんと勉強を続けられていません。 英検2級、準1級くらいまでは取りたいと思っているのですが。。。

はじめの頃は busuu というアプリも結構使ってましたが、だんだん問題と自分のレベルが合わなくなってきたので使うのをやめました。

www.busuu.com

英単語アプリを自作したりもしましたが、これも使ったり使わなかったりですね。。。良いアプリだと自負しているのでもう少し活用・アップデートしたいところです。

word-penne-lp.neumann.tokyo

Lungage Exchange もよく参加しましたね。こうかくといろいろやってるなぁ。

なんにせよ、自分の学習の方針としては

  • 学生時代と同じことをしない
  • アプリや動画などを活用する (本だけで英語を勉強するのは無理がある)
  • 続けられることをやる

この辺でしょうか。

それぞれが自分にあった勉強方法があると思いますのでなにか参考になれば幸いです。

もくもく会をやめたい

$
0
0

connpass.com

connpass の新着イベントを見てみるとオンラインのもくもく会がたくさんある。というか半分くらいもくもく会とタイトルについている気がする。

このようなもくもく会にいくつか参加してみたけど、何となく自分の求めているものと違うので参加するのをやめた。

僕のやりたいこととしていわゆる「雑談作業通話」がしたい。 これは Discord でよく見るやつでお絵かきとかしながら雑談しているやつだ。 そういうのをプログラミングをしながらやりたいのだが、

  • IT系のもくもく会は黙ってることが多いので喋りたい
  • お絵描き Discord の雑談作業部屋でプログラミングするのは少し気が引ける

という理由で自分にとって最適な Discord サーバーというのが少ない。(いくつかはある)

もくもく会って勉強会へのアンチテーゼだったよね?

これは僕の認識が間違っていたら申し訳ないんだけど、もくもく会って勉強会へのアンチテーゼだったよね? いわゆるスライドとか用意してLTとかやるのが勉強会だとすると、そういうのって準備とか大変だからただ黙々と作業だけすればいいでしょ、っていうのがもくもく会の生い立ちだったと思うんだけど、 この手の勉強会やもくもく会がオンラインで開催されるようになってから、僕としてはモクモクしてたら意味なくないかという気持ちのほうが強くなってきた。

何が嫌なのか

単純に意味わからないんだよねぇ。 Discord で全員マイクミュートにしてボイチャに入ってるやつ。 あれ本当に何なのか? 一人くらい喋ってる人がいてそれを聞き専で聞いてるだけならまだわかるんだけども、本当に誰も喋ってなくてただアイコンだけで出席の存在感を主張しているだけの会ってなんなんだ。。。なんの意味があるんだそれ?

よく「無言作業」みたいな名前のボイチャルームで上記の現象を見ることがあって、僕には本当に理由がよくわからない。 「作業してるから話しかけないで」ならそもそもボイチャに入らなければいいし、「今いるからテキストだったら話しかけて」の意味なのか「他のボイチャに人が来たらそっち移る」という意思表示なのか。。。 僕が時代についていけてないのかもしれない。

まぁ Discord サーバーのたくさんのボイチャルームの中に「無言作業」があるのはまだいい。上記のような解釈もできそうだし、たぶん使ってる人からすればなにか便利な点があるんだろう。 でもオンラインもくもく会と称して「出席だけするけどみんなマイクミュートして」っていうのは、少なくとも僕は参加したくない。せっかくだから話したいし、話しちゃいけないけど存在感だけ出してってのは嫌だ。それならテキストチャットで非同期コミュニケーションしてる方がいい。

もくもく会へのアンチテーゼとして雑談会を作りました。

さて、実はここまでの話は前置きで、ここからが本題です。

IT雑談会という Discord サーバーおよび connpass のグループを作りました。

Discord discord.gg

connpass have-a-chat.connpass.com

自分の事情として来年から土曜の午後だったら一人の時間が取れそうなので、月1回くらいならこういうITイベントできそうという見込みがあり、 勉強会をやりたいなと思っていたところ、上記のようなオンラインもくもく会に対する不満があったので雑談会という概念を作ってみました。 名前もわかりやすさを重視してあえてダサくしてあります。

とくに勉強会のようにプレゼンスライドとか用意するわけでもなく、ただ集まって少し雑談しながら作業しましょうという程度の会です。 もくもく会と差別化したいので聞き専は基本的にお断りして、話す意思のある人だけ参加してほしいです。 とはいえ「ずっと話し続けてくれ」というわけでもなく、作業集中して全員黙ってしまうこともありだと思ってますので、あくまで参加の意思として話すつもりがあるかどうかが重要です。

興味を持ってもらえたら試しに join してください。

どういう感じで運用するのか

とりあえずはイベントは月1で、その他の日は適当に Discord に参加している人で雑談作業通話できたら嬉しいなと思ってます。 今までの自分の経験として僕はあまりコミュニティ運営が得意ではないので、できれば誰か一緒に運営してくれる人がいると嬉しいです。

connpass にイベント建ててるコミュニティで Discord を利用しているところも多いですが、どうしてもイベントのときだけしか人が集まらないのがもったいないなと思ってます。 できれば他の業種の Discord サーバーのように、気が向いたときにふらっとボイチャに入って雑談できるくらいの気楽さにしたいです。

ソファを自作した話

$
0
0

ソファづくりに挑戦したくなったので2x4角材と24mm厚の針葉樹合板を使ってDIYすることにした。 家の近所に根継商店という平成建築の大工さんがやっているシェア工作室ができたので、ここで機材を借りたり大工さんからプロのアドバイスを受けたりして作成した。

netsugi.jp

設計図

大物なので今回はきちんと設計図を書いた。といってもCADの使い方など知らないので我流でやる。

iPad の Procreate というソフトを使って次のような図を書いた。

これは色ごとにレイヤーが分かれていて、次のように分解できるようになっている。

完成図を意識しつつパーツごとの設計が可能だ。Procreate はアイソメトリック描画ガイドを表示してガイドに沿った線を書くことができるので、この機能を活用するとこのような設計図も作ることができる。 お絵かきツールと言えど侮ることはできない。

材料の準備

2x4角材と24mm厚の針葉樹合板をホームセンターで購入して、根継商店にある卓上丸のこなどを使ってカットしたのがこちら。(作業途中の写真は取り忘れた)

同じ長さに木材を切っていくためには卓上丸のこくらいはないと厳しいので、機材を借りられる場所はありがたい。普通の手に持つタイプの丸のこは持っているのだが、これではあまり精度が良くない。 かといって卓上丸のこは家で買うにはちょっとオーバースペックである。

組み立て

組み立てはコーナークランプを使って直角になるように気をつけて作業した。

いかんせん、2x4角材を適当に買ったものだから沿っていて設計図通りの形にするのに苦労した。木は天然素材なのでこれは仕方がないことだ。クランプでしっかり形を作るのが重要である。

また隙間なく木材を結合するために次の動画にあるようなテクニックを使用すると良い。

www.youtube.com

ひと手間かけるとクオリティが上がるのは何事も同じかもしれない。

仮組み

パーツができたので最終組立の前に仮組みしてみる。この段階では各パーツは設計図で色分けされている4種類で、まだそれ以上の結合はされていない。 仮組みしてみたら案の定、針葉樹合板が片方はまらなかったので、電動カンナで2mmほど削った。 これも機材があるおかげである。

塗装

以前はニスとかペンキとか使っていたけど、最近はワックスで仕上げることが増えた。 何と言っても乾くのが早い。30分ほどで乾いてしまう。ニスやペンキでは24時間くらい放置するほうが無難だがワックスなら二度塗りの必要もない。 大きいサイズのワックスを買っておけばいくつか作品を作っても使い続けることができる。

完成

最終的な組み立てを家で行い、ついに完成した。途中経過の写真をあまり撮ってなかったが、土日を4度ほど使っているので結構時間がかかった。 二人がけソファなので座面の横幅は1200mmになっており、ちょうど写真の長座布団が置けるようになっている。 この長座布団はAmazonで購入したもので、合皮なのでソファに最適だと思う。

120cmとのことだが写真でわかるように若干小さいが、その分クッションが分厚いのでよしとする。

家を片付けて読書部屋を作ることにしたので、このソファはその部屋用になった。寝っ転がってみても腕置きがいい感じの位置に来て想定よりいい感じだった。 こういう大物は手間と時間がかかるけどちゃんとできると自分の技術力が上がったのを実感できて楽しい。嬉しい。

格好いいポートフォリオを作りたい!

$
0
0

DIYで作った木工作品が増えてきたのでポートフォリオを作ることにした。 ポートフォリオとはいわゆる作品集のことで、なんとなく美大生とかが持ってるイメージがある。 (エンジニア界隈でポートフォリオというと過去に作ったプログラムの一覧とかだったりする)

どうせポートフォリオを作るなら格好良くしたい。 木工作品がメインなので表紙と裏表紙も木で作ることにした。

作ったもの

早速だが完成品がこれだ。相変わらず途中経過の写真を取り忘れている。

ホームセンターで3mm厚のラワン合板が売っていたのでこれを使うことにした。 単に塗装して仕上げるだけでは寂しかったので、ハンダゴテでウッドバーニングすることにした。

ウッドバーニング

調べたところウッドバーニングは 500度くらいでやるといい感じに焦げるようだ。僕が使っているハンダゴテは温度調整機能がついていて、幸い500度は対応していた。

みんなこのハンダゴテを絶賛しているので迷ってる人はこれ買えば無難だと思う。 ペン先も変えることができるので本格的にウッドバーニングをするならウッドバーニング用のペン先を買えば細かい絵を書くこともできると思う。

ハンダゴテが問題ないことがわかったので、Wordで適当に文字を作って印刷した。 それをカーボン紙でトレースしてラワン合板に転写した後、ハンダゴテでウッドバーニングした。

文字数が少ないこともあり1時間ほどでウッドバーニング完了。

塗装

今回はツヤを出したかったのでニスを使うことにした。水性のウレタンニスを使っている。

ニスといえば油性一択という人も多いと思うが、いくつかの理由により水性を試してみることにした。

  • 油性に比べて水性のほうが圧倒的に取り扱いが楽。筆洗ったりとか
  • 塗料も進歩しているので水性でも大丈夫と信じたい
  • 今回の用途的に屋外で使うわけでもないので多少弱くても問題ない

使ってみて思ったがやはり水道で気楽に洗えるのは圧倒的に楽だ。乾く時間も90分ほどで昔より早くなっている気がする。 400番のヤスリで削りながら2度塗りしたらいい感じになった。 ラワン合板がおもったより塗料を吸い込むのか、もう少し艶を出すなら3度塗りしたほうが良い気がしたが、面倒くさくなったので2度塗りでやめた。

塗装前はこんな感じの色なのでけやき色がはっきり出ている。クリアにするか迷ったが、けやき色の高級感がでて良いと思う。

内部のパーツ

100円均一でリングバインダー用のファイルフォルダとリングが売っていたのでこれを使うことにした。

印刷したものを入れるとこんな感じになる。100円で20枚シート入っていたので1シートに裏表で2ページ分入れるとすると、40ページは行ける。ポートフォリオとしては十分な量だと思うし、もっと増えたら追加もできる。

もう一度表紙を見るが、かなり格好良くできたと思う。これだけで作品として扱うことができるのでポートフォリオのインパクトとしては十分だ。 作品を増やして分厚くしていきたい。

ClojureScript でふつうの React 開発をしたい

$
0
0

背景

ClojureScript には Reagent や RUM などの React のラッパーライブラリが複数あり、 React のライブラリを使うことができる。 しかし実際に使ってみるとなんか上手く動かないこともあって結局 ClojureScript 向けのライブラリを使うほうが無難という現実がある。

例えば、

  • ルーティング ... reitit
  • バリデーション処理 ... Malli
  • Form 処理 ... fork
  • CSS in JS (CSS in CLJS?) ... stylefy
  • 状態管理 ... re-frame

という感じで、React しかさわってない人にとっては初耳のライブラリばかりになる。 なんかこれってもったいないというか、せっかく「ReactのリソースをClojureScriptでつかってやるぜ」といういつものClojureのずるい思想で着手しても、なんだかんだReactのライブラリを活用できなくてくやしい思いをするというのもなんか嫌だ。

TypeScript みたいに JS のライブラリを単に ClojureScript で使うだけじゃ駄目なんだろうか、と思い始めた。

Helix を使う

僕の肌感覚としては React のラッパーライブラリは現在 Reagent が一番使われていると思うが、この Reagent は少し古いので React Hooks とかが若干使いづらい。逆に Atom を活用することは得意なので Signal とか Recoil みたいなものがなくても ClojureScript の Atom を活用することで状態の管理ができる。一方でそれが故にReact系のライブラリが上手く動かないことがある。

で、もうちょっと素直に React Hooks とか使えるラッパーがないかと思って探してみたら次を見つけた。

github.com

Helix はかなり薄い React ラッパーでほとんどの処理はマクロで React や JS に投げているだけだ。 これなら React のライブラリも動きそうだ。

React Router , React Hook Form などを使う

というわけで素振りリポジトリを作ってみた。

github.com

Readme にあるように次のようなライブラリを使ってみている。(HTTP リクエストまわりはまだ途中)

  • Shadow-cljs
  • helix
  • Tailwind.css
  • react-router-dom
  • jotai
  • react-query (jotai があれば不要かも)
  • react-hook-form

Tailwind.css

Tailwind.css は正直あまり好きになれないのだが、 Shadow-cljs が css のビルドはできないので使ってみることにした。

github.com

このライブラリが便利だったので使ってみることにしたが、無事に ClojureScript でビルドした JS ファイルを Tailwind.css に食わせて CSS を出力することができた。

最近、若い開発者と一緒に仕事をしていると案外DOMに対して style 属性でデザインを当てようとしがちなので Tailwind.css みたいな方が存外いいのかもしれない。

React Router

reactrouter.com

React Router の Tutorial に従って createBrowserRouterを使おうとしたが、これはうまく動かなかったので、 BrowserRouter component を直接作ったらうまく動いた。

(ns helix-init.app
  (:require[helix.core :refer[defnc $]]["react" :as r]["react-dom/client" :as rdom]["react-router-dom" :as rrd]["jotai" :refer[useAtom]][helix-init.layouts.base :as base][helix-init.pages.sign-in :as sign-in][helix-init.pages.about :as about][helix-init.pages.sign-up :as sign-up][helix-init.pages.top :as top][helix-init.atoms :refer[sign-in-token-atom]][helix-init.components.require-auth :refer[require-auth]]))(defnc app [](let[[sign-in-token _](useAtom sign-in-token-atom)]($ rrd/BrowserRouter
       ($ rrd/Routes
          ($ rrd/Route {:path "/" :element ($ base/layout)}($ rrd/Route {:index true :element (if sign-in-token
                                                  ($ require-auth top/top-page)($ sign-in/sign-in-page))})($ rrd/Route {:path "sign-up" :element ($ sign-up/sign-up-page)})($ rrd/Route {:path "about" :element ($ require-auth about/about-page)}))))))(defonce root (rdom/createRoot (js/document.getElementById "app")))(defn^:export init [](.render root ($ r/StrictMode ($ app))))

helix-init/app.cljs at main · neumann-tokyo/helix-init · GitHub

React Hook Form

react-hook-form.com

Get Started にある次のコードを参考にして実装しようとした。

import{ useForm } from "react-hook-form";

exportdefaultfunction App() {const{ register, handleSubmit, watch, formState: { errors }} = useForm();
  const onSubmit = data => console.log(data);

  console.log(watch("example")); // watch input value by passing the name of itreturn (
    /* "handleSubmit" will validate your inputs before invoking "onSubmit" */<form onSubmit={handleSubmit(onSubmit)}>
      {/* register your input into the hook by invoking the "register" function */}<input defaultValue="test"{...register("example")} />
      
      {/* include validation with required or other standard HTML validation rules */}<input {...register("exampleRequired", { required: true})} />
      {/* errors will return when field validation fails  */}{errors.exampleRequired && <span>This field is required</span>}<input type="submit" />
    </form>
  );
}

ちょっと待て、 <input defaultValue="test" {...register("example")} />って ClojureScript でどう書くんだ?

これはパラメータを展開しているわけだから merge してやればいいか、というわけで

(d/input (merge{:defalutValue "test"}(register "example")))

みたいなコードを書いていたのだが、うまく動かなかった。 Helix のソースを確認したところ、 d/inputみたいな HTML を作る関数はすべてマクロになっていて、マクロの第1引数が HashMap のときに パラメータとして展開して、それ以外のときは子コンポーネントとして扱うようになっていた。 上記の (merge {:defalutValue "test"} (register "example"))は評価される前にマクロにわたってしまうので、第1引数が関数として処理されるため子コンポーネントとして扱おうとしてエラーになる。。。

Clojarian の slack でも同じことで困っている人がいて、現状対処のしようがないようだ。 仕方がないので register の引数を分解して愚直に HashMap に入れることにした。

(let[form (useForm)
        register (.-register form)
        register-email (register "email"#js {:required true})](d/input
        {:type"email"
         :id "email"
         :class-name "border border-gray-300 rounded-md p-2"
         :placeholder "Email"
         :name(.-name register-email)
         :on-blur (.-onBlur register-email)
         :on-change (.-onChange register-email)
         :ref(.-ref register-email)}))

helix-init/sign_in.cljs at main · neumann-tokyo/helix-init · GitHub

素の Form

複雑なフォームでないなら React Hook Form を使わないほうがシンプルになりそうだったのでその例も作った。

github.com

HTML5で対応しきれないバリデーションとか Select の扱いなどを気にしなければこれでよいかも。

jotai

コンポーネント内部の状態は React Hooks で十分なのだが、グローバルに状態を扱いたい時 useContext がどうも使いにくくて Recoil や Jotai などのライブラリが乱立している感じがある。 今回は前から評判が良い jotai を使ってみることにした。

セットアップしたらすんなりうまく動いたので、JWTサインインを想定したダミーのコードを作ってみた。

(let[on-submit (fn[data](if(and(= (.-email data)"user1@example.com")(= (.-password data)"password"))(do(set-sign-in-token (fn[_token]"sign-in-token"))(.set Cookies "sign-in-token""sign-in-token"))(set-api-errors ["Invalid email or password."])))])

helix-init/sign_in.cljs at main · neumann-tokyo/helix-init · GitHub

sign-in-token-atom"sign-in-token"という文字列が入っていたらサインイン状態とする。(実際には jwt トークンが入る)

HTTP リクエスト

jotai は react-query みたいに HTTP リクエストの結果をキャッシュするような機能があるのでこれをつかって HTTP リクエストのサンプルコードを作ってみた(まだ途中)

(ns helix-init.components.random-cat
  (:require[helix.core :refer[defnc $]][helix.dom :as d][cljs.core.async :refer[go <!]][cljs-http.client :as http]["jotai" :as jotai]["jotai/utils" :as jotai-utils]));; TODO cljs-http 用の loadable を自作する(defonce random-cat-api-atom
  (jotai/atom
   (go (fn[_get](<! (http/get "https://cataas.com/cat"{:with-credentials? false
                                 :query-params {"json"true}}))))))(defonce random-cat-api-loadable-atom
  (jotai-utils/loadable random-cat-api-atom))(defnc random-cat [](let[[random-cat-api](jotai/useAtom random-cat-api-loadable-atom)](print(.-data random-cat-api))(d/div
     #_(case(.-state random-cat-api)"loading"($ d/div "Loading...")"hasError"($ d/div (.-error random-cat-api))(d/div (.-data random-cat-api))))))

helix-init/random_cat.cljs at main · neumann-tokyo/helix-init · GitHub

cljs-http を使っているのだが、 jotai-utils/lodableは js の promise のみをターゲットとしているのでこのコードではだめ。

対策を2つ考えていて、

  • cljs-http 用の lodable みたいなものを自作する
  • axios や got などの js の http client を使う

前者を試したらちょっといまいちだったので後者を試して見る予定。

[追記] axios + jotai loadable による http 通信

axios + jotai loadable で http 通信するサンプルコードできました。

(ns helix-init.components.random-cat
  (:require[helix.core :refer[defnc]][helix.dom :as d]["axios$default" :as axios]["jotai" :as jotai]["jotai/utils" :as jotai-utils]))(defonce random-cat-api-atom
  (jotai/atom (axios/get
               "https://cataas.com/cat"#js {:withCredentials false
                    :params #js {:json true}})))(defonce random-cat-api-loadable-atom
  (jotai-utils/loadable random-cat-api-atom))(defnc random-cat [](let[[random-cat-api](jotai/useAtom random-cat-api-loadable-atom)
        image-url (some-> (.-data random-cat-api)(js->clj :keywordize-keys true)(get-in [:data :url])((fn[path](str"https://cataas.com" path))))](if image-url
      (d/img {:src image-url :alt "cat"})(d/div "Loading..."))))

helix-init/random_cat.cljs at main · neumann-tokyo/helix-init · GitHub

["axios$default" :as axios]という読み込み方法が長らく分からず困った。

感想

思ったよりちゃんと React のライブラリが Helix で動いたので嬉しかった。 これなら ClojureScript で積極的にいろいろな React ライブラリを使っても良さそう。

ただ ClojureScript で SSR する方法などを僕は知らないので、JS や TS の下記心地が許せるなら素直にそっち使うほうがいいかもしれない。(元も子もないこと言うけども。。。)

github.com

この辺が実用的なレベルになればもっとJSのライブラリを CLJS で使えるのだが。。。

広告をやめて投げ銭を始めました

$
0
0

このブログに付いていた google adsense による広告を外しました。 たまにバズったときに数千円入ってきてましたが、あまり意味のある収益ではなく広告なしでブログを読んでもらうほうが嬉しいと判断したためです。

かわりに PayPal.me のリンクを置いておきますので、もし投げ銭いただける方がいたらこちらからお願いします。

paypal.me

全記事の末尾にリンクを置くようにしました

Twitterをやめた

$
0
0

Twitter が X になったのをよい機会だと思ってやめることにした。

これからは紙に日記書いて生活します。

DM送りたい方は 会社の本社住所宛に郵便でお願いします。


週1でYouTubeに会社の活動報告を上げている理由

$
0
0

しばらく前に合同会社ノイマンという会社を設立した。

neumann.tokyo

そして会社の活動報告を毎週月曜日朝7時にYouTubeにアップロードしている。

www.youtube.com

今朝、第6回を公開したので1ヶ月半やっていることになる。目標としては100回まではやりたいと思っている。

会社の活動報告といいつつ守秘義務に関わることは言えないので、基本的には僕が個人的に勉強していることとか経理関係で何をやったかなどの話が多い。 この活動は再生数を伸ばすことは目的ではないので、なぜこんなことをやっているのか書こうと思う。

活動報告とは

週一でその一週間に行ったことをダイジェストして5分〜10分程度の動画にしている。 守秘義務に関する部分は当然話せないので、今の所「年末調整した」とか「VPNを使えるようにして開発環境を良くした」とかそういう些末な話をしている。 もうちょっと「DIYで家を直した」みたいなコンテンツ力の高い話もしていきたいが、それはやったときにやる。

定例の活動報告は自分がその一週間に何をしたかの行動記録が主な目的で、1つ1つの動画の面白さはそこまで求めてない。 「今週はこういうことをやっていたよ」という程度のスモールトークに過ぎないので見てくれる人がそれを楽しんでいただけると嬉しいけど、 こちらとしては定期的にやることが一番大事なのであって、一度のクオリティをあげようとすると疲れるのでそこは頑張りすぎない範囲とする。

僕の希望としてはせめて新しい技術について勉強して情報発信することで、多少なりともリスナーの役に立つ情報を発信したいと思っているのでそこは頑張ろうと思う。

なぜやっているのか

なぜこんなことをやっているかというと、今まで活動記録を残してこなかったことに対する後悔があるからだ。

初めてあった人に自己紹介するとき話すことが多くなってしまった。 だいたい次のような話をする。

  • プログラマ/リモートワーク/起業した
  • 静岡に変な形の家を持っている
  • シェアハウスに住んだり運営したりしていた
  • 五右衛門風呂で生活していたことがある
  • DIYで家を直したり家具を作ったことがある
  • 車中泊生活をしながら全国を旅していたことがある
  • ソーラーパネルで発電していた
  • カホンを作ったり叩いたりしている

ネタが多い!!

良くも悪くもネタが多い。一方でこれらの情報はちょいちょいブログにはしているもののまとまってなかったり、削除した記事もあったりして 客観的に見て記録が十分に残っているわけではない。リアルタイムに記録を残しているものもわりと少ない。

それがもったいないなと今更ながら後悔している。情報発信が大事だなと思っているし他の人にそういうことを言うこともありながら、今まで自分も十分にできていなかった。 そもそも当時の自分は自分がやっていることをそこまで特別だとか面白いとか思ってなくて、ただ生活の延長の中で五右衛門風呂が必要だったりソーラーパネルが必要だったりしただけなわけで、 それをちゃんと記録しようという意識が強くなかった。

そういうのはもったいない。

僕はもっと自分が変な人間であることを自覚したほうがいいらしい。 そうすると、自分が面白いと思ったときに記録するのではなく、定期的に週一くらいで活動を多少なりとも記録して発信するほうがいいと思った。

最近は以前ほど突飛な活動をする機会は減ってきているが、それでも何もしないということはありえない。 だから活動報告を週一でちゃんと残すことにした。

他の人が何をしているかはSNSでは案外分かりづらい

自分の周りの人を見ていて「面白いことをやっているけどいまいち外に伝わってないな」と思う人が多いことに気づいた。 FacebookやTwitterなどのSNSというのは案外その人が何をしているのか分かりづらいのだ。 そもそもSNSは親しい人とコミュニケーションするためのもので、知らない人に情報を伝えるものとしては向いてない。 フォロワー同士の交流であっても、相手が何をやっているのかわかるときとわからないときがある。

そういう情報の不確実さみたいなものが不十分だと感じている。

なんかもっとダイジェストとしてまとまったものがほしい。 ざっくりその人が今何をやっているのか説明してほしいし、その中で宣伝があるならやっておいてほしい。

そういう気持ちで始めたのが週1回5分程度の活動報告だった。 だからどちらかというと自分がやりたい以上に他の人の活動報告がみたいという気持ちもあって動画を作っている。 実際、友人で活動報告動画を作るようになった人もいてとても嬉しい。

なぜ動画なのか

ブログを書くのがだるかったから。ブログはそれなりの文量がないと面白くならないし、あまり読んでもらえる気がしなかった。 僕としてはブログよりプレゼンのほうが短い時間で作れるから、週一でブログを書く気持ちになれなかった。 ブログで書くといかにも週報っぽくて嫌だったというのもある。 僕はあえて週報という言葉を使っていないのだが、これはなんとなく週報と聞くと面倒臭そうな感じになるのが嫌だったからだ。

podcastも考えたが長い時間話すわけでもないのでYouTubeでいいかなと思った。 なんとなく映像がないのも寂しい気がするし、一般的な知名度としてpodcastよりYouTubeのほうが高いように思えた。

あとは単純に興味として動画を作ることをやりたかった。 カメラやマイクも少々持て余し気味だったし、まだ公開していないDIY関係の録画データもあるので動画編集になれておきたかった。

撮影方法については試行錯誤していて、なんとなく人物が写っている動画のほうが説得力がある気がして顔出ししている。 プレゼンだけ画面に出してもいいのだが、そういう動画はなんとなく退屈な印象がある。 やはり「人が喋っている」というのが印象として大切なのかもしれない。 そういう狙いもあってあえてiPadでプレゼンをしているのだが、文字が出ている部分が画面の中で小さくなるのがイマイチな気もする。 テレビなんかも長年の試行錯誤の末に現在の形があるわけで、他の動画を参考にしながらやっていきたいと思っているが、 あまり編集に時間をかけたくもないのでいい感じの折衷案を見出していきたいところだ。

他の人もやってほしい

もしこの記事を読んでちょっとでもいいと思ってもらえたら、ぜひ他の人たちも活動報告動画を作ってみてほしい。

YouTubeに動画を上げるというと再生数を伸ばさなければならないみたいな感覚がなんとなくあるような気がするけど、 そこを目指さない動画制作のスタイルがあってもいいんじゃないかと思う。 もちろん収益化するにはそれなりの再生数とチャンネル登録者数は必要なわけで、収益化を考えるならそれらの数字を伸ばしたいわけだけれども。

「最近はこういうことをやっているんですよ」という話を対面であった人にするだけじゃなくて、動画にしてWebで公開するということをするだけで なにか世界がちょっと変わってくれるんじゃないかなと小さな期待をしている。





Latest Images