デイリーポータルZの新着記事をBlueskyに投稿するbotを作りました。 github.com デイリーポータルZは2024年1月1日から独立した会社になるようですが、状況から察するに実態としては消滅まで秒読みと思われます。インターネットからデイリーポータルZが無くなるのは寂しいので、どこかの企業がスポンサーになってくれることを期待しています。 dailyportalz.jp それはそれとしてBlueskyのボットを作るのは結構楽しいですね！ボットのコードはRustで書きました。GitHub Actionsの定期実行でRSS feedをポーリングして新しいものがあったらポストする、という素朴なプログラムです: bsky.app Bluesky APIへのアクセスはsugyan/atriumを使いました: memo.sugyan.com 投稿の本文をリッチテキストにできたり*1、OGPカー

2019年9月9日からFastlyに入社しています。勤務地は東京です。今後ともよろしくお願いいたします。 前職の Bit Journey, Inc. では3年ほどKibelaのサーバーサイドやフロントエンドアプリの開発に関わりました。Bit Journey在職中に子供がうまれ、現在も夫婦で分担しながら子育てをしていますが、この子育て初期という大変な時期*1にBit Journeyで気持ちよく働けたのはたいへんな僥倖でした。ここで改めて感謝いたします。 さて、Fastlyは方向性を変えて、ウェブアプリではなくVarnishやH2Oなどのミドルウェアの開発に関わります。 Kibelaは自分が数年のあいだ心血を注ぐにふさわしいサービスでしたし、実際のところ大いに開発を楽しみました。しかし、しばらく今後のキャリアの方向性を考えた結果、かねてから経験してみたいと思っていた低レイヤーなソフトウェア開発

DX: Developer Experience （開発体験）とは、あるシステムを「気持ちよく開発・保守できるかどうか」を示すもの 開発者は開発・保守という行為を通じたそのシステムのユーザーであり、DXはUXの一種である DXがよいと日々の開発を楽しめるようになり、気持ちに余裕ができる 気持ちの余裕がでるとコードの品質があがり保守時のデグレも減らせる また、DXがよい事自体がDXを高める動機になり、正のスパイラルを見込める つまり、「定められたタスク」（＝義務）以上のことを行うようになる DXが悪いと開発を楽しめず、「定められたタスク」以外のことをしたくなくなる DXは放置すると悪化するので、「DXがよくも悪くもない」プロダクトは時間が経つに連れ「DXが悪い」になる なので積極的にDXを良くしていく活動を奨励していくのがよい いくつか興味深いフィードバックがあったので記しておきます。 DX

github.com Railsのcontrollerで違和感があるのって actionのinputに params というインスタンスメソッド経由でアクセスすること しかも params はviewからアクセスできる！ actionのoutputが controller のインスタンス変数への代入であること しかもそのインスタンス変数はviewからアクセスできる！ というところだと思うんですよ。 なぜなら我々は「メソッドの引数でinputを受け取りメソッドの戻り値をoutputとすべし」ということを是としてコードを書いてるわけじゃないですか。リーダブルコードを読むまでもなく、変数のスコープは狭ければ狭いほどメンテナンスしやすいリーダブルなコードだというベストプラクティスを正しいものとしてコードを書いているわけじゃないですか。 そういうベストプラクティスに真っ向から反しているのが現在のRa

半年くらいまえにBit Journeyに転職してKibelaを作ってました。AndroidエンジニアからRails + Reactエンジニアへの転向ということになります。 Kibelaはこちら。ようやく本日リリースできました。といっても開発面でいうとこれからが正念場ではあります。 Kibela - 個人の発信を組織の力にする情報共有ツール “個人の発信を組織の力にする情報共有ツール” と銘打っているとおり、これは 個人が組織内で自由に情報を発信すると組織が活性化する という仮説に基づいて設計されている、会社などの組織向けのサービスです。もちろんそれだけでなく、仕様書の整理につかったり議事録をとりあえず突っ込んでおくみたいなのもありです。 さてKibelaでできることはBlogとWikiを書くことです。これはつまり 個人が発信する情報 とそれ以外を分けるということです。このあたりの思想やベス

こないだの@onkさんのスライドがとても良かったんですよ。 短期間で新技術を学ぶ技術 from Takafumi ONAKA 短時間といいつつ守破離の「離」までいくのに3年かかるといってて、高速道路なんてものはないんだなということがわかりますね。 とはいえ自分自身に照らし合わせてみてもそのとおりだなと思いました。ぼくもAndroidで対外的にアウトプットできるようになるまで3年くらいかかってますし。まあ、ぼくは新技術を学ぶのはわりと苦手なほうではあるんですが。 で、スライドにはないけど新しい技術を学ぶ際には大きな壁がいくつかあるなとあると思ってます。それを 意識して 乗り越えるための指標としてもこのスライドはよさそうだなと。 ついでなのでちょっと ぼくの感じる 三大壁をまとめてみました。まあ、壁を壁と感じない人もいると思いますけどね！ Lv.1 着手の壁 症状: 何の役に立つのかわからない

セマンティックバージョニングは守るとして、だいたいこんなポリシーでやってます。 0.0.1 - proof of concept / minimum viable product 0.1.0 - とりあえずリリースしてプロダクションに組み込んでみる 1.0.0 - プロダクションに組み込んだ 2.0.0 - セマンティックバージョニングに従うので、メジャーバージョンアップは機能ではなく単にAPI互換性を失うという印 あとは、alpha, beta, rcなどを接尾詞としてつけることもあります。 *-alpha - 開発中 *-beta - 安定してきた *-rc - release candidate. プロダクションに組み込んでもOK

本日のまとめ: MBP2016が故障したので返品手続きをしてMBP2015を注文した。さようならUSB Type C。こんにちはMagsafe2 & HDMI。— FUJI Goro (@__gfx__) 2016年12月10日 Macbook Pro 2016 13インチ タッチバー付きモデルを先月購入しましたが、3週間ほど経って充電できなくなる現象に見舞われました。Apple Storeのジーニアスバーに持ち込んでみてもらったところ、「ハードウェアの不具合と思われるが現在このモデルは部品がなく修理できない」とのことで、返品することにしました。代わりにMBP2015を注文し、これは来週届く見込みです。 故障をきっかけとして返品ということになりましたが、結果的には、むしろMBP2015に交換できてよかったと思っています。下記のとおり大きな不満点がありましたし、同様の故障が観測範囲内でも散見

2016/7/27 にこんなアップデートがあったようです。 Changelog - We've added the option to auto-cancel redundant builds. Read more, and how to enable it, here: https://t.co/MTjOV7ttkF— CircleCI (@circleci) July 26, 2016 Project Settings → Advanced Settings に設定項目があります。 With the exception of your default branch, we will automatically cancel any queued or running builds on a branch when a newer build is triggered on that s

追記(2019/04/11): sonots氏がGitHubの方と相談しつつ設計した運用方法が公開されました。 全社的に会社用GitHubアカウントを廃止した件 - ZOZO Technologies TECH BLOG このガイドラインは今後のデファクトスタンダードになると思うのでtl;drを引用します。 個人で会社用と私用の2つの無料GitHubアカウントを持つことはGitHubの規約「非」準拠だった 会社用GitHubアカウントを廃止し私用GitHubアカウントを利用する規定に変更した セキュリティを担保するためGitHubのSSO機能を利用した GitHubの規約的には、おそらく「会社として会社用アカウントを pro版にする」「個人が身バレを防ぐために個人アカウントをpro版にして会社用アカウントを別途作る」などの運用も可能だとは思います。しかし、GitHubというサービス自体マル