Mac は「こちら側」のコンピューターではなくなった - portal shit!
概略を説明すると、 Catalina の頃から Apple が Mac ユーザーのアプリ起動ログを勝手に収集していたが、 Big Sur の公開日にログ集約サーバーがダウンしてしまい、そのせいで Mac を使えなくなる人が続出して問題が発覚したというもの。 Rebuild の Episode 288 で触れられているので興味がある人は聞いて下さい。 この記事については日本語の翻訳もあってはてブで 500 ブックマークくらいついていたが、どうも機械翻訳されただけのようだったし、一部訳が違うのではと思われるところがあったので自分でも訳してみた。訳を原著者の Jeffrey Paul 氏にメールで送ったので恐らくそのうち本家に日本語訳が追加されると思う。 2020-11-25 9:16 追記 日本語訳追加してもらいました。 起きていることをまとめると以下のような感じだ。 Apple は Mac
リモートワーカーへの公平な支払い
DHH が Twitter で言及していた記事がおもしろかったので著者の許諾をもらった上で翻訳しました。 Paying remote workers differently solely depending on their zip code is immoral. If you can afford to hire from both San Francisco and St Louis, you can afford to pay both the same for the same work. If you can't afford SF rates, that's fine too! https://t.co/A1nJkPlimG — DHH (@dhh) May 25, 2020 Salesforce の Product Manager 、 Blair Reeves さんの記事。
プレーンテキスト Markdown 時代の終焉
なぜ Day One は Markdown を捨てたのか Day One が Markdown をやめて WYSIWYG に移行した話は前書いた。 Day One がクソになった Day One 、このブログでも度々言及していて、 Markdown で日記が書けて便利だったんだけど、最近のバージョンアップ（ Mac は 2.8 以降 、 iOS は 3.0 以降）でプレー... portalshit.net 自分が知っている範囲でアンチ Markdown 勢は Scrapbox くらいしか思い浮かばず、 GitHub や Trello などのグローバル勢に加え、 Qiita やはてなブログなど日本国内向けのサービスでも当然のように Markdown が共通言語として使われているのに、その Markdown を捨てて WYSIWYG 化する1という戦略は疑問だった。 ひとむかし前の WYSI
AWS をどう使わずにおくか - portal shit!
ジョブキューイングシステムをどうするかでチームのリーダーとやりあって考えたことがあるのでまとめておく。 Rails で使うジョブキューイングシステムの技術選定で、リーダーは Amazon SQS 推し（レガシーシステムで SQS を使っている）、自分は Sidekiq 推しだった。前職時代に Sidekiq を使ってトラブルに遭遇したことはなかったし、とても簡単に使えるので Sidekiq で十分だと思っていた。 Sidekiq は GitHub でのスター数は 9000 オーバーで、 Rails の ActiveJob バックエンドとしては事実上のデファクトスタンダードだといえると思う。ググれば情報がいっぱい出てくるし、チームメンバーもリーダー以外は全員 Sidekiq の使用経験があった。 GitHub - sidekiq/sidekiq: Simple, efficient back
リモートワークにまつわる諸問題
『リモートワークのストレス | POSTD』へのコメント この記事に対して149件のコメントがあります。注目されているコメントは「寂しがり屋と真面目君はリモート向いてない」、「リモートワークって、ペアプロやモブプロが推奨されるアジャイルや、少人数で効率よく検証・開発のサイクルを回すリーン的な働き方と相性悪いと思ってる。」、「たまにリモートにするぐらいが丁度良い派」、「7割はチャットの下手さが理由だと思う。対面での会話が得意すぎるとも言うが。」などです。 b.hatena.ne.jp リモートワーク別に寂しくないし楽勝、みたいなコメント多いけど違和感あった。リモート楽勝という人はフリーランスとか受託の会社の人なのではないかと思う。自分のブックマークコメントは以下。 激しく同意。雑談したい、家族から家事を頼まれる、オフィスにいる連中から事業理解が低いと責められる、毎日服を着替える能力や通勤電車
良いエンジニアの定義
今年は転職して働く環境が変わり、自分のエンジニアとしての能力が足りないと痛感させられることが何度もあった。しかしそれは技術力が足りないというよりも、もっとほかのもののように思えた。良いエンジニアとは何なのかについて、今年一年で考えたことを書いてみたい。 良いエンジニアとは何だろうか。技術力が高ければ当然に良いエンジニアと言えるのだろうか。そもそもエンジニアに必要なスキルとは何だろうか。技術力がまず挙げられるだろう。良いエンジニアは当然に高い技術力を持っていて生産性が高いはずだ。 技術力に加えて、プロジェクトマネジメントのスキル（以下プロマネ力と省略）も必要なのではないだろうか。これまでの自分の経験を振り返るに、技術的に秀でたエンジニアはプロマネ力も兼ね備えていることが多いと感じる。技術力が高いエンジニアはプログラミングの能力が高いので、組織や開発体制を「プログラム」する能力が培われるのかも
会社を辞めた
会社を辞めた。3年半在籍してた。 ペパボに入る前は凄いブラック企業で働いてて、 Subversion やめて Git 使いたいと言ったら会社辞めろと言われたりしてた。そんなときに蜘蛛の糸のように目の前に垂らされたのが Dazaifu プロジェクトの求人で、藁にもすがる思いで応募し入社したのだった。この辺は過去のエントリに適当に書いてあるので読みたい人は読んで下さい。 前働いていた会社の思い出と近況 いまの会社は労働環境よいんだけど、前働いていた会社がとてもつらかった。どのくらいつらかったかというと、もう辞めてしばらく経つのに、いまだに前の会社にいたころの夢を見てうなされて夜中に目が覚めるく... portalshit.net ペパボは働きやすくて、毎日18時になったらみんなさっと帰るし、21時過ぎに会社出ると最終退出者であることもしばしばだった。家庭の事情にも理解があって、育児休業をさせて
家を建てたので得られた知見を共有します
5月末に家を建てて半年ほど住んで得られた知見を共有します。 家を建てた理由 子どもが生まれた 最初は賃貸で引っ越そうとしてた 子育てには車が必要だから 西松屋（車でしか行けないような所にしかない）に行きたかった おむつやミルク缶やベビーカーは車じゃないと運べない 駐車場の安い郊外に引っ越して車買おうとしてた（当時住んでた所は駐車場代高かった） 結局引越費用高くてやめた（40万くらいした） 中古マンションでも探すことにした 中古マンション探すけど良いのは高かった 中古なのに新築分譲時より高いのとかある それなら新築マンションでよいのでは、と思った しかし新築マンションは業者が好きになれなかった 偉そう 息がくさい すぐローンの審査申し込ませようとする 考える時間を与えずハンコ押させようとする 買いたいタイミングでよい物件が出回ってなかった マンションは管理費や修繕積立金、駐車場代が重荷になり
前働いていた会社の思い出と近況
いまの会社は労働環境よいんだけど、前働いていた会社がとてもつらかった。どのくらいつらかったかというと、もう辞めてしばらく経つのに、いまだに前の会社にいたころの夢を見てうなされて夜中に目が覚めるくらいつらかった。ある意味トラウマになってしまっている。 つらかった頃のことをここに書いても意味がないことは分かっているし、ネガティブな感情をインターネット上に発露するのは個人的な信条に反するんだけど、セルフヒーリングのために前勤めていた会社のことを書いてみる。 無限サービス残業 22時に帰るときも日報に「本日私用のためお先に失礼します」と書かなきゃいけない雰囲気だった。 「23時に佐川が来るので申し訳ありませんがお先に失礼します」と日報に書いてる女の子とかいた。 社長が「震災のおかげで仕事が減って早く帰れてうれしい、とか言ってるやつは許さない」とか言ってた。 みんなサービス残業してるので会社の飲み会
死んでしまったサービスの供養
この記事は 闇アドベントカレンダー、 22 日目の記事です。何書こうか迷って担当日に書けなかったので三日ほど遅れてしまったけど書きます。 2011 年の 10 月から FANIC という音楽配信サービスの開発に携わっていたのだけど、サービスを成長させることができず、 2013 年の 8 月にサービス終了した。 サービスが死ぬのは技術者がクソだということだけではないと思う。市場とか外部環境に左右されるし、企画とか売り方がダメなことの方が多いと思う。しかし現実に自分はプログラマーとして FANIC というサービスの死に荷担してしまった。弔いになるか分からないけど、 FANIC で何がよくて何が良くなかったのかを書いてみたいと思う。 FANIC とは FANIC は主にアマチュアのミュージシャンをターゲットにしたホームページ作成＆音楽販売サービスで、アーティストは自分の公式ホームページを簡単に作
GitHub で Pull Request を Merge したらコードが消えた話
会社で使ってる GitHub のプライベートリポジトリで master ブランチに対して出てる Pull Request を Merge したらコードが消えるという珍事があった。ファイルを削除する commit とかないにもかかわらず、全消しされてしまった。ちなみに同じ Merge を手もとでやるとコードが消えたりはせずちゃんと Merge された。極めて謎な現象だった。 master ブランチが空になるとデプロイができなくなって不都合があるので（ Webistrano 上でデプロイするとき master ブランチからしかデプロイできないようなレシピになってる）、コードが消滅したブランチを bukkowaremaster にリネームして手もとで Merge したブランチを force push してしのいだ。 GitHub に問い合わせてみたところ、ぬるい感じの一次返信が来たので原因教えて
コメントが多いコードはダメなコードだと思う - portal shit!
最近、会社でリーダブルコードを輪読したり、Fukuoka.rb で Eloquent Ruby を読んだりしていて、メソッドや変数名の長さやコメントについての議論を読む機会があった。 昨日、たまたま 37signals のブログを読んでいたら、Rails の作者である David Heinemeier Hansson もこのトピックについて書いていた。 自分は WEB+DB PRESS で ukstudio さんの書いた RSpec についての記事を読んで感化されて以来、ソースコード中のコメントはすべて悪で、はっきりしたメソッド名、変数名を使えばコメントはいらないという考え方を持っている。DHH もそのような考え方のようだ。 要点をかいつまむ。 多くのプログラマーは短い変数名やメソッド名を好む。短い命名は明確性や簡潔性を犠牲にしているとみんな気づいてるんじゃないかと疑ってるんだけど、実際の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
