大きな病気などなく、本日1月19日で28歳を迎えました。
もう若手とは言えなくなって参りました。
昨年は世界が大きく変わり、自分自身にも良いこと悪いこと、いろいろとありました。
28歳の抱負は「地道」にしました。
飛躍などの大きな目標からは一旦離れて、これからを考える時間に充てようと思います。
去年全く会わなかった方も多いですが、今年も1年よろしくお願いいたします。
恒例のWishlist です。
よろしければ、お待ちしております。
大きな病気などなく、本日1月19日で28歳を迎えました。
もう若手とは言えなくなって参りました。
昨年は世界が大きく変わり、自分自身にも良いこと悪いこと、いろいろとありました。
28歳の抱負は「地道」にしました。
飛躍などの大きな目標からは一旦離れて、これからを考える時間に充てようと思います。
去年全く会わなかった方も多いですが、今年も1年よろしくお願いいたします。
恒例のWishlist です。
よろしければ、お待ちしております。
これは はてなエンジニア Advent Calendar 2020 25日のエントリーです。
昨日は id:hitode909 さんで、Perlアプリケーションの依存モジュールの更新についてWEB+DB PRESS vol.120のPerl Hackers Hubに寄稿しましたでした。
誕生日おめでとうございます🎉
最終日を担当するのは、アプリケーションエンジニアの id:yutailang0119 です、こんにちは。
クリスマスなど関係なく、掃除の話をします。
2020年は、Apple Silicon (以下、Apple SoC) Macが発売された歴史的な年になりました。
記念品なので、もちろん買いました。
10年ぶりにMacBook Airです。
プログラミングを始めていない期間も含めると、MacがメインPCになってからの時間がWindowsよりも長くなっています。
プログラミングでの用途がメインになってからも、構成は変遷してきましたが、M1 Macでまた環境が変わったので、大掃除の状況をまとめようと思います。
ちなみに自分はMacやiPhoneすべてで、前の端末からデータ移行せずに、更地からのセットアップする派です。
最初にRosetta 2の挙動確認のためにTerminal.appを使っていたところ、これでいいかという気持ちになって、Terminal.appで暮らしています。
iTerm 2の機能を使いこなせていたわけではなかった。
今の所の不満点は、開いたタブの縦配置ができない点くらい。
そのうち、他のマシンとの違いが気になってiTerm 2に揃えるかもしれません。
Rosetta 2で起動するかは、アプリ起動時のみ切り替わるので、 arm64
と x86_64
環境の切り替えのために、iTerm 2もインストールして使い分けるのはありかも。
↓はTerminal.appをちょっとハックして、2つを同時利用する例。
M1 Pro Tip: Duplicate Terminal.app, change its App ID in Info.plist, change icon, enable Run using Rosetta. pic.twitter.com/hGqvweKVUt
— Tricertops (@Tricertops) 2020年12月17日
はてなに入社したタイミングの環境見直しで、それまで使っていたzshからfishに移行しました。
正直なんとなくで、カラフルでオシャレだし使ってみよう、くらいの感覚でした。
fishには十分に満足しているのですが、みなさんご存知の通り、macOS Catalinaからデフォルトシェルがzshになったので、どこかで戻ろうかなと思っていました。
ちょうど、今秋に業務PCの変更もした *1 タイミングで、zshに戻ってみています。
Apple SoC関係なしにzshでいいやと思っているけど、見た目のカスタマイズが滞っていて、Intel Macではfishもたまに起動しています。
キーボード配列はUSを使っていて、左右の⌘キーにen/ja切り替えを割り当てていました。
(capas lockのオフも有効になっているが、こちらはついで)
今回のM1モデルのキーボードでは、左下のfnキーにグローバル記号も印字され、入力切り替えが割り当ててられているので、Karabiner-Elementsが不要になりました。
微妙なラグやたまにトグルが効かなくなって再起動してたりの不便さはあります...*2
iOS/iPadOSのソフトウェアキーボードやiPad用のMagic Keyboardでも、左下に入力切り替えが配置されているので、これに慣れたい。
これまでのIntel Macキーボードにはこの設定はないのかと思っていましたが、このエントリー書いている際に、キーボード設定の Press Fn key to
に指定できることに気づきました。
Karabiner-Elementsから卒業できそうです。
いい機会なので、ついに卒業しました。
Appleのライブ変換に慣れなかったけど、流石に1ヶ月もすると慣れてきた。
VS Codeをインストールせずに暮らせています。
これまでのVS Codeの用途の中で、小さい修正などはVimで完結できるので、まずは .vimrc を再整理しました。
プロジェクト全域を扱うために使っていたVS Code用途は、GitHubの Codespaces でやってみています。
Codespcasesは、GitHubがホストするクラウド上でVS Codeの環境が使えるもので、ブラウザから利用できます。
たまに反応が悪いなと思うことはあったりするけれど、npm
とか普通に動いているし、便利。
ここからローカルホスト立ち上げたりはできないだろうけど、TypeScriptでツール作ったり、日本語書く環境にしたりは問題ないです。
iPadからでも同じ環境が使えるので、かなりおすすめです。
iOSアプリを使えるようになって、いくつかのアプリを入れてみたけど、正直まだ使いこなせていないです。
自分が作ったアプリが動くのは感動しました
— Yutaro Muta (@yutailang0119) 2020年11月22日
年末とApple SoC Macということで、大掃除と称して、環境の整理をしました。
M2以降のMacBook Proをメイン機にするつもりでストレージは256GBのままにしたで、できるだけ最小構成にしているので、ストレージは増やしておけばよかった。
Apple SoCにおすすめのアプリやツールがあれば、ぜひ教えてください。
今年もお疲れさまでした。
これは Mackerel Advent Calendar 202019日目のエントリーです。
昨日は id:yasunori-k さんで、 2020年のオンラインセミナーを振り返る(共催セミナー編) - Mackerel ブログ #mackerelio でした。
こんにちは、id:yutailang0119 です。
Mackerelアドベントカレンダーには初参戦
アドベントカレンダーのテーマであるMackerelを提供する株式会社はてなで、普段からアプリケーションエンジニアを自称している訳ですが、主戦場はモバイルアプリのため、Mackerelのメインターゲットからは少し外れる気がします。
サーバー監視は主業務ではないのですが、今年はいくつかのアイディアの実現とそのためのツールを作成したので、まとめようと思います。
fastlaneは、iOS/Androidプロジェクト向けのビルド、テスト、リリースなどの自動化ツールです。
日本でも、多くの企業、組織で利用されていることでしょう。
fastlaneのようなタスクランナー使ったCI実行を考えると、継続的に状態を記録したくなるのではないでしょうか?
その記録先としてMackerelを使うために、fastlaneのPluginを作りました。
作った時の心境などは、こちら
fastlaneには、Coreの組み込みActionとして github_api
があり、このインターフェースを模して、mackerel_api
として Mackerel APIを実行するようにしています。
作ってから半年強、以下のような情報を継続して記録しています。
上記の2つの利用方法は、 以下のActionをまとめたPluginとして公開しています。
ご利用、フィードバック、お待ちしています!!!
こちらは、GitHub Actionsなので、モバイルアプリに限らずに利用可能です。
リポジトリに含まれるコード量/比率をMackerelに記録する with GitHub Actions & action-mackerel-api - がんばってなんか書く で紹介している言語比率の記録は、プロジェクトで使っています。
そのほかに聞いた利用方法では、GitHubのBilling APIと組み合わせて、GitHub ActionsやGitHub Packagesの利用状況をMackerelに記録しているそうです。
そのほかにも、利用方法はいろいろありそうですね。
何かおもしろい使い方があれば、教えてください。
このように、Mackerelはサーバー監視以外にも、アイディア次第でモバイルアプリ開発でも有用な活用方法があります。
ということで、今年のおさらいでした。
来年も何かできたらいいですね。
明日はryosmsさんです。
SPAJAM 2020最優秀賞副賞で、軽井沢でワーケーション体験をして来た #SPAJAM #サードオフィス - がんばってなんか書く の帰りに、12/13 (日) - 14 (月) で金沢に一泊して来ました。
SPAJAMワーケーションは昼に解散予定だったので、夕方から夜にかけて移動する予定でスタート。
軽井沢のアウトレットでみんなでお昼を食べた後に、あさま615号 -> はくたか567号と乗り継いで、金沢に移動。
17時半ごろに到着しましたが、疲れていて、この日は晩ごはんを食べずにホテルで寝て、夜に駅の周りを散策するだけにしました。
天気が悪く、気温も真冬の予報で心配してましたが、なんとか周りきれた。
近江町店 | 金沢カレーの元祖!カレーのチャンピオン【チャンピオンカレー】
近江町市場 – 金沢市民の台所としてもうすぐ300年の小売市場
ここら辺から、1人なのが辛くなってきた。
記憶上で、日本海を見たことない *1 のではということで、天気が悪くなければ、海を見たいと思っていました。
ということで、 北陸鉄道浅野川線に乗って、内灘海岸に行きました。
海を見た瞬間に「日本海だー!!!」テンション上がったけど、寒すぎて滞在時間は10分でした。
往復で2時間近くかかったけど、旅とはこういうもの...
海鮮丼を食べ
初のサンダーバードで帰路に着きました。
先日報告した SPAJAM 2020 の最優秀賞 の副賞の一つ、軽井沢ワーケーション体験に、12/12 (土) -13 (日) で行ってきました。
世間でも、ワーケーションという言葉が盛り上がりを見せています。
今回は、SPAJAM 2020のスポンサーで長野県の建設会社 株式会社フォレストコーポレーション様に特別にご招待いただき、軽井沢で1泊2日のワーケーション体験をして来ました。
新型コロナウィルス感染対策に、最大限配慮した環境で、我々チームおひっこしのメンバーをアテンドしていただきました。
軽井沢では、東京から新幹線で1時間の立地を生かして、コロナ禍よりも前からワーケーションやオフィスの誘致に注力されています。
今回滞在したサードオフィス以外にも、ワーケーションに利用できる施設が複数あり、訪問した三菱地所様のワーケーション施設もよかったです。
また、軽井沢市自体の平均所得が急激に上がっていて、その一因は教育関連の施設の充実とのことで、別荘地としての一時的な滞在から、移住という選択も増えているとのこと。
今回滞在したサードオフィスを一言で表すと、会議室などオフィス機能の一部を併設した別荘です。
ワーケーション体験ということで、研修的面はもちろんありましたが、今回の主役は最優秀賞の我々!
ということで、すばらしいおもてなしをいただきました!!!
くつかけステイ 中軽井沢 – 和食と宿のくつかけステイ 中軽井沢のWebサイト
お酒も飲み放題で、大信州おいしかった。
滞在中、シャンパン、ワイン、ビール、日本酒などをご用意いただき、すべて飲み放題でした!!!
というか、ワインセラーにずらっとシャンパンが並んでいて、飲み切れる量じゃなかった。
シャンパン、ワインの味は記憶できるほどわからないんですが、日本酒の小左衛門を久々にいただけてよかった。
シェフを呼んでのごはんでした。
2日目はワークショップとして、参加者とフォレストコーポレーション社員の皆様で、「あったらいいなワーケーション体験 (施設、サービス、機能)」というお題のアイディアソンを行いました。
ブレストから始めて、最後のチームワークでは @_bannzai_、@noa_design51、@yutailang0119 と、フォレストコーポレーションの社員の方の4人チームで、アイディアソン優勝でした。
短い時間でしたが、普段触れているITとは離れた話も聞けてよかった。
チームでいただいた副賞をチーム内で分けて、うちには以下のものが来ました。
軽井沢への行きは、チームメンバーで東京駅集合にしたので、東海道新幹線で向かいました。
初めて、北陸新幹線にも乗れました。
せっかく軽井沢までやって来たので、帰りは北陸新幹線を北に回って、金沢に延泊して帰ることにしました。
ということで、1人旅に続きます。
*1:これから届く
予選: SPAJAM 2020 第2回予選大会に「おひっこし」として参加して、優秀賞に選ばれました #SPAJAM - がんばってなんか書く
11/7 (土)、8 (日) に行われたSPAJAM 2020 の本選大会に、 @_bannzai_、@gaopin1534、@koooootake、@noa_design51と共に参加し、最優秀賞に選ばれました!!!🎉
https://history.spajam.jp/final-result/
最優秀賞いただきました!!! #SPAJAM https://t.co/1QC6AUXf7T
— Yutaro Muta (@yutailang0119) November 8, 2020
SPAJAM本戦最優秀賞わあい🤤3年連続予選最優秀賞からの本戦に出場したものの"最"優秀賞は獲得できておらず😇4年目にしてついに!わあい!とても楽しかったです!
— 神武 (@koooootake) November 8, 2020
デモ動画軽くまとめてアップロードしました🙋♂️みてね
ぽすすめ - 地元を観光地ポスター化して共有 -https://t.co/uTjxeBmUSg#SPAJAM
優秀賞ということで、本選に行けるかは、全ての予選終了後の復活にかかっている状態。
SPAJAM 2020 第2回予選大会に「おひっこし」として参加して、優秀賞に選ばれました #SPAJAM - がんばってなんか書く
優秀賞からの選出で、本選敗者復活しました🎉 #SPAJAM https://t.co/2VV7nVhEC1
— Yutaro Muta (@yutailang0119) October 23, 2020
ということで、敗者復活を遂げて本選出場、そして、最優秀賞を勝ち取りました。
まずは、本当に嬉しかった!!!
敗者復活からの優勝ということで、喜びもより一層でした。
また、予選では審査員長の村上さんにウィークポイントを突かれたけど、今回はベタ褒めですごい満足感でした。
たしか、審査員のちょまどさんが言ってたと思う「ツンキャラがデレた時のギャップ」という表現がすごくしっくりきています。
ここ1週間ちょっと睡眠がうまくいかずに生活リズムが無茶苦茶になっていたり、予選よりも貢献できている感覚が弱いと思ったり *1 で自信がなかったりして、進行中は結構参った気持ちにもなりました。
また、プレゼン + 質疑応答 10分の枠を、プレゼンで9分消費した時には、かなり焦っていました。
しかし、「仕事やってるようなことしてるな」と発言した記憶もあり *2 、身につけていることの多くを吐き出せて、結果としての最優秀賞に貢献できたのかなと思います。
チームメンバー間では「優秀賞では呼ばれるな」と祈りながら結果発表を見て、最優秀賞に「おひっこし」の文字が出た時には、みんなで声を上げて喜びました。
最優秀賞は徹夜のがんばり全てを報われた気持ちにさせてくれました。
今回使ってみたFirebase MLVisonが手軽で、予選から使ったFirebase Cloud Firestore / Strageの合わせて、アプリを作っていく感覚を得られたので、何かに繋げていきたいですね。
今回のメンバーのバランスがよかったので、本選に行って、次はみんなと同じ場所で一緒にやりたい。
SPAJAM 2020 第2回予選大会に「おひっこし」として参加して、優秀賞に選ばれました #SPAJAM - がんばってなんか書く
世間と自身の状況をあれこれと考え、今回も自分は京都から参加としました。 *3
最優秀賞で集まる機会を得たので、結果オーライ。
チームバランスの良さは今回も感じました。
最初の役割分担で、4人のプログラマー陣は大きくUIとロジックで2:2と分かれる分担になり、偶然にも予選の組み合わせと担当が逆となりましたが、困りごとは得意な人が自然とフォローに回る空気ができていてよかった。
自分は終盤には、予選も本選もデザイナーがこだわりたいところの調整を担当して、@noa_design51 からも承認を得られたのもよかった。 *4
全員が一定以上の実力を持ったメンバーなので心配はなかったですが、自分自身も広くできるなと再確認できたし、実力者メンバーの中においても自分が深くできることも知れたのはとても参加した価値がありました。
反省の一つはiOSのバージョンの話。
iOS 14端末は全てiOS 14.2にアップデート済みでしたが、そのSDKに対応するXcode 12.2がまだStableリリースされておらず、実機インストールできない状況でした。
気づいてすぐにXcode 12.2 RC1のダウンロードを始めました。
途中で気づけてよかった。
Xcode 12.2 RC1が出た時に、すぐにStableリリースされるだろうと、マシンからbetaを消してたので、特異なパターンではあるけど、注意が必要でした。
チーム「おひっこし」として、共に参加した @_bannzai_、@gaopin1534、@koooootake、@noa_design51 ありがとう!
1人だけ遠隔ということで苦労もかけたと思うので、不満だった点は集まった時に教えてください。
@_bannzai_ は誘ってくれてもありがとう!
早く家見つけてね
SPAJAM 2020運営、審査員の皆様、初のオンライン開催、ありがとうございました。
オンラインだからこそ、今回のメンバーでの参加が叶ったことと思います。
ほぼ徹夜ですごく疲れましたが、最高の結果で終われました!
最優秀賞は全てを癒す
ちょうど、ドキュメントのMarkdownが崩れている箇所を知っていたので、修正を出した。
GitHubスタッフから
Because this particular issue has been fixed by the GitHub Docs team, I am going to close this pull request. We encourage folks to open an issue first so we can verify the need for the proposed change and avoid duplicate work.
https://github.com/github/docs/pull/264#issuecomment-705704911
というコメントがきて、最初は 「この種の問題はGitHub Docs teamが直すので、まずはissueを作ってね」 と読んでいて、OSSの意味...と誤解したのだけど、 id:ikesyo と話していて、 同じタイミングでGitHub Docs teamが修正していたことが判明 した。
コメントは「GitHub Docs teamも同じ修正をしたところだったので、作業の重複をしないために、まずはissueを作ることをおすすめします」というのが、おそらく正しかった。
コミット は3日前だったけど、PR (repo sync by Octomerger · Pull Request #273 · github/docs · GitHub) は、自分が修正を出した数時間後。
別にあるらしいPrivateリポジトリとのsyncで表に出てきたものだった。
Markdownの修正だし、issue作るのと労力変わらないと思ってやった修正だったけど、本当にタイミングが悪かった。
レビュワーには手間をかけたし、issueで確認するのは大事、世界中から多くのPRが送られるOSSは大変だなと思う。
未公開情報もあり、別にPrivateなリポジトリのは仕方ないと思うので、ラグタイムで生じるこの手の問題は致し方ないかなと思う。
これに懲りずに、修正を出していきましょう
ちなみにページは ここ
無事、直っていますね