「映画好きを名乗るからには見とかなきゃいけないとか、斬新とか通好みとかじゃなくて、単純に一番面白い映画ってなんですか?」
って聞くと、俺みたいな映画に詳しくないヤツが見ても「う〜ん、難しくて良くわからなかった」となる映画を教えられがち。(小説でも同じ)
すごく映画詳しいと思われる@machidaさんに昔この質問をした時、
「 バックトゥザフューチャーじゃないすかね。」
と即答された。
こりゃ信用できるわぁ〜
「映画好きを名乗るからには見とかなきゃいけないとか、斬新とか通好みとかじゃなくて、単純に一番面白い映画ってなんですか?」
って聞くと、俺みたいな映画に詳しくないヤツが見ても「う〜ん、難しくて良くわからなかった」となる映画を教えられがち。(小説でも同じ)
すごく映画詳しいと思われる@machidaさんに昔この質問をした時、
「 バックトゥザフューチャーじゃないすかね。」
と即答された。
こりゃ信用できるわぁ〜
これをgemにしました。
gemにした理由は、gistだと適当感があってこれにしたがってくださいと言い辛いからです。 メンテについては腹を括ったのでやっていきます。
とにかくエディタ論争とこういうルールについての議論をするのが辛い。
プログラミングスクールで使うことを念頭に置いているので他にも教育やスクールをやっている方には便利かも知れません。
group :development do
gem 'rubocop-fjord', require: false
end
.rubocop.ymlにこう書く。
inherit_gem:
rubocop-fjord:
- "config/rubocop.yml"
# - "config/rails.yml"
厳密には昇降デスクの脚であるFlexiSpot E3を書いました。
元々の机は作業部屋に妻と並べてぴったりのサイズになるように天板を発注して、脚はIKEAのOLOVを使っていました。
その脚だけを変えた感じです。
座った状態
スタンディング状態
(高さが変わってくときでも猫は意外と動じない)
まず、スタンディング状態だと座った状態のように作業に入るときに、
「さて、作業するか…」
みたいな心理的なハードルが低いです。
フラッと立ち寄れる作業場所みたいな感じなのでこまめに気楽に作業できる気がします。
また、やはり座った状態もスタンディングも同じ状態だと疲れますが、体の使ってる場所が違うので切り替えると引き続き作業できるようになって休まず作業できる時間が長くなりました。
数日使ってますがかなり気に入りました。
そして強く感じているのが、「電動+メモリ機能(設定を覚えておいてくれて1ボタンでその高さになる)」がなかったら動かさなくなるだろうなということです。
まず自分のしっくりくる高さに合わせるのはかなりシビアなので、切り替えるたびにそんなことする必要があったらストレスが溜まります。(微妙にずれたまま作業するのもすごいストレス)
1日の中で何度も切り替えるものなので手動でやるのも高さの変更が少しでもダルかったら使わなくなると思います。
ポチッと押したら自分のベストの高さにピッタリ合うようになってると楽しいし気持ちいいです。
それでも唯一気になっている点が、座ってる状態とスタンディング状態ではベストなカメラの角度が違う点です。
ビデオ会議で使うカメラの調整がいちいち必要になるのが少し面倒ですね。
今の家に3月に引っ越してから約5ヶ月。途中やりとりで何度もブチギレそうになりながらやっとNURO光が開通しました〜🎉
前の回線(NTTフレッツ光マンションタイプ)
NURO光
「わーわー」
84Mbpsから560Mbpsと約6倍も速くなって大満足です・・・と言いたいところですが・・・。
いや、全然問題ないんですがなんかちょっと・・・
元々Google Nest Hubを使ってメッシュネットワークを組んでいました。(本体+拡張ポイント2個)
NURO光のルーターは無線LAN機能が付いていたのでそれを使ったら560Mbpsでした。もちろん回線がNUROになったのでNUROの回線+Google Nest WiFiのメッシュネットワークで速くなるぞ〜と思ったんですが、NUROのルーターの無線LAN機能を切ってGoogle Nest WiFiの無線LANを使うことにしたところ、以前と同じ80Mbpsしか出ませんでした。
これはもしや、元々回線のせいで遅かったのではなく、Google Nest WiFiが問題だった説が・・・。
結局NUROのルーターに付いてる無線LANで家中どこでも速かったので嬉しいは嬉しいのですが、Google Nest WiFiが無駄になったのが微妙です。
Google Nest WiFiの無線LAN機能をPCやスマホからは使ってないですが、妻がキッチンでGoogleアシスタントとして使うので一応残してあります。(Nest Hubが一個あれば良かった説)
ここ最近で一番感動したサービスきました。(rono23に教わったサービス)
コロナでビデオ会議が増えてます。でもビデオ会議のブッキングはクッソだるい。
「私達の可能な日時を調整して3つほど候補日をお伝えします。」(本当はもっと大丈夫な時間あるけどキリがないので3点だけ伝える)
(社内の参加者で調整…)
上記いずれかでご都合の良い時間帯があればお知らせください。
「私どもも社内で調整して折り返します」
(お客さん側の参加者間で調整…)
08月5日(水) 13:00〜15:00
こちらでお願い致します。
では当日、宜しくお願い致します。
コレ。
何ターンもやりとりが発生してやってられない。
気軽にビデオ会議ができない。もっと楽だったらテキストよりビデオで話せばすぐ解決することも多いのに。
それを解決してくれる神サービスがyou can book me。
こういうブッキングがURLを1つ送るだけで完了する。
Googleカレンダーと連携できて、スケジュールが入ってる場所は選べないようにしてくれる。 (自分がアクセスできてる社内の他の人のカレンダーもまとめて考慮してくれる)
お客さん側は自分の都合のいい時間を選んで、
このように登録すると、俺のGoogleカレンダーに予定が入る。(申し込んだ方のカレンダーにも簡単な手順で登録できる)
zoomの場所も自動で決まっている。
もちろん登録されたタイミングで俺にメールでの通知も来る。
神だわ。
ちょっと気になったのでタックスヘイブンのマレーシアのラブアン法人設立のオンラインセミナーに出てみました。
法人については事前に謎に思ってた部分は解決しました。
今度は個人の税金について気になってきました。
例えば、日本の法人に所属してマレーシアに移住した人への下記の税金はどうなるんだろう?
zoomで基本は聞くだけ。(マイク・カメラは全員強制OFF)
付属のチャットでリアルタイムで質問できるって型式でした。
技術以外のオンラインセミナーって初めて出ましたが、複数持ってた謎が1時間で解決したので自分で延々と調べるよりコスパいいなと思いました。今後ライトにいろんなのに参加しようかなと思います。(怪しいの多いので注意しながら…)
フィヨルドブートキャンプのレビューでいつも書いてることシリーズ。
基本的にはこちらのrisacanさんの内容と同じです。
コミットメッセージの書き方. 適切な情報を残そう | by risacan | Medium
この内容から下記の二つを引いた感じです。
ずっと残るものだからあまり流行に左右される書き方はしない方がいいかなと思います。
また、あまりシステマチックなルールにするとコミットメッセージの基本である「何を考えて書いたのをわかりやすく説明する」という姿勢が弱まっちゃいそうだなという思いもあります。
フィヨルドブートキャンプの「自分で考えたWebサービスを作る」のカリキュラムでいつも言ってることまとめ。
「作ってみました」と言うつもりで作ったWebサービスと「リリースしました」と言うつもりで作ったWebサービスは大きく違います。
「作ってみました」はお試し・実験のような意味合いで、自分の実力イコールではないことになります。下記のようないろいろな言い訳のできる余地がある言い方です。
それに対して「リリースしました」は下記のように色々と突っ込まれることが予想されるので、それに対して「現時点での全力である」と言えるように作ることになります。
Webサービスはネットにアクセスできる誰もが1タップで見れるので、業界人だけが見るわけじゃありません。かなりの確率でSNS経由で学生時代の友達や家族も見ます。そう言った視線を想定して全力で作ったモノと「作ってみた」モノはとてつもなく違います。
マンガでいえば「大学ノートに鉛筆で書いたマンガ」と「漫画原稿用紙にペン入れしてトーンを貼った18ページのマンガ」ぐらい違います。
逆に言えば「リリースした」人はそれだけやりきった人なのですごいです。
Webサービスを作ったことがある人の目も「作ってみた」ことがある人と「リリースした」ことがある人では違います。経験者はその二つがどれだけ違うか分かっているので、「作ってみました」ではなく「リリースしました」と言い切っている人に対する態度は非常に優しいです。
「リリースした」だけで内容よりまず先に「すごい」「おめでとう」です。内容に対する意見はその後です。
就職面接での面接官の見方も違います。「リリースした」人は作り上げる技術だけでなく、サービスのコンセプトやデザイン、UIなどとことん考えたことがある人であると期待できます。
実際に業務でWebサービスを作る時にはそれぞれの専門職の人と協力しながら作りますが、その時にも自分なりに考えて、大変さを分かっていることは生きるはずです。
mentionable gemで簡単にmentionが実装できます。(こういうやつ → @komagata)
gem 'mentionable'
$ bundle install
app/models/comment.rb:
class Comment
mentionable_as :body
def after_save_mention(new_mentions)
p new_mentions # => ["@komagata", "@machida"]
end
end
Commentモデルのbodyにmentionが含まれる文章が保存される場合、mentionable_asでそのカラムを指定したらデフォルトでafter_save_mentionメソッドが呼ばれるので実装して置けばOK。
そのカラムにメンションが含まれていた場合、そのメソッドがコールバックされます。
class Comment
mentionable_as :body, on_mention: :on_mentioned, regexp: /:\w+:/
def on_mentioned(new_mentions)
p new_mentions # => [":komagata:", ":machida:"]
end
end
コールバックメソッドの名前とメンションを抽出するための正規表現は独自のものが指定できる。
comment = Comment.create(body: '@nobunaga @hideyosi Hi guys.')
comment.mentions # => ["@nobunaga", "@hideyosi"]
comment.new_mentions? # => true
comment.update(body: '@nobunaga @hideyosi @ieyasu Hi guys.')
comment.mentions # => ["@nobunaga", "@hideyosi", "@ieyasu"]
comment.mentions_were # => ["@nobunaga", "@hideyosi"]
comment.new_mentions # => ["@ieyasu"]
comment.new_mentions? # => true
#mentionsでメンションが取れる。
メンションを自分で実装するときの面倒な仕様として、
「メンションを含むテキストがupdateされた場合に増えた分のメンションだけ欲しい。(updateされるたびに通知が行くとうざい)」
というのがありますが、mentionable gemでは最初から新しく増えた分のメンションだけがコールバックメソッドに渡ってくるので楽です。
それらを自分で取る各種メソッドもあります。
#mentions: メンション全部#mentions?: メンションある?#new_mentions: 新しいメンション#new_mentions: 新しいメンションある?#mentions_were: 古いメンション実際のサービスではコールバックメソッドの中でサイト内通知や通知メールを送ったりすればOK。