チャットコミュニケーションむずかしい。全然そんなつもりで書いてないのに受け手の解釈が乗っかって伝わったりする。 たとえば純粋に質問しているだけなのに責められているように感じる人もいるし、感謝を伝えたつもりが煽りや嫌味と捉えられることもありうる。 そもそもチャット以前の関係性の問題として対処すべきこともあるし、受け手の人となりや状況を完全に理解することもできないのであまり気にしすぎても仕方ない。一方で、自分の経験上解釈ズレが起きやすい表現は明確にあって、自分はそれらを"禁止"するマイルールを作っている。誰でもできるチャットコミュニケーションの工夫の一つとして雑にまとめておく。 あー / えっと 「あー (そうじゃなくて)」とか「えっと (理解できないみたいだからどう言おうかな)」みたいな感じで相手に非があるという印象で伝わることもある じっくり考えられるチャットでこれらを書く必要もないので使
GitHub Actions で CI している皆様、こんにちは。 GitHub Actions 便利ですよね。使わない日がないというくらい毎日お世話になっています。 さて、CI といえば良く問題になるのが実行時間。 長い待ち時間は開発効率を下げますし、プライベートリポジトリだと Runner の費用も嵩んでしまいます。 時間を短縮する方法は色々ありますが、一手目によく行われるのが依存パッケージのキャッシュじゃないかなと思います。 例えば Go で開発していると、依存パッケージは ~/go/pkg/mod にダウンロードして保存されます。 これを CI 実行のたびにダウンロードしてコンパイルするのは時間とお金の無駄というものです。 幸い、GitHub Actions には CI の実行間でこういった依存パッケージを保存して再利用できるキャッシュ機能があります。 詳しくは以下のドキュメントを
Nuxt Bridge を活用して Nuxt 3 へ移行しました 業務委託で STORES の開発をしている @inouetakuya です。 以前 STORES が Nuxt Bridge を活用して Nuxt 3 への移行を進めている旨の記事を wattanx が書いてくれました。 Nuxt 3 への移行に向けて頑張ってます - STORES Product Blog そして先月（2024年7月）ようやく Nuxt 3 へ移行することができましたので、本記事は前回の記事の続編にあたります。 Nuxt Bridge とは おさらいになりますが、Nuxt Bridge とは Nuxt 3 の機能の一部を Nuxt 2 でも利用できるようにしたライブラリです。これを活用すると Nuxt 2 のプロジェクトのまま Nuxt 3 の機能を利用するようコードを変更でき、Nuxt 3 へのバージョン
3ヶ月前に転職することになって送別会を開いてもらったんだけど、その帰り道で今まで好きだった、優しくされるうちにいつの間にか好きになってたみたいなことを同僚の女性から急に言われ、そのまま付き合うことになった お相手の子は2つ下で知り合って4年で、増田よりも明らかイケメンと付き合ってたりしたから、まあこの人の恋愛対象に非モテの自分が入るはずも無いなーと思いながら、でも仲は良かったし、話しやすいし可愛いのでこんな人と付き合えたら幸せだろうなーって感じだった 今までの人生色んな人にアプローチしたり告白したりしてきたけど全部ダメで、遊びに行くとか友達としてなら良いけど、付き合うとかそういうんじゃない、男として見れないみたいなことを言われ続けてきた で、その人たちみんなイケメンやクズ男の元に行くから恋愛とかクソやんって状態に正直なってたし、世の中の恋人つくろうよみたいな圧力も辛かった その状態からの急
昨晩、Apple が新型 iPad Pro と iPad Air を発表した。一部で予想されていた通り、M3 はスキップして M4 が搭載された。Air も M3 ではなく M2 が搭載された。これは Apple Silicon を製造する TSMC の動向をある程度追いかけてる人にとっては、とても合点がいく展開だったと思う。 www.apple.com Apple Silicon でも TSMC の N3B と呼ばれる 3nm 世代を使って製造されるのは iPhone 15 Pro に搭載される A17 Pro だけになるんじゃないかと考えていた。なぜなら TSMC N3B はたいへん歩留まりが悪い、つまり不良品率が高くて製造コストが高いと報じられていたからだ。それを改善した N3E もすでに動いていて、Apple 製品以外はこちらを使うことになるだろうとも報じられていた。 実際は Ap
2024年2月13日に『YAPC::Hiroshima 2024 非公式ふりかえり会』を開催しました。イベントでお話した内容を文字起こし形式で紹介します。 hey.connpass.com 登壇者紹介 STORES hogelog：YAPC初参加 ヨヨイ：YAPCは3、4回参加経験あり hiromu：YAPC初参加 藤村：YAPC初参加 えんじぇる：YAPC初参加 スマートバンク 三谷：YAPC初参加、YAPC::Hiroshima 2024でベストスピーカー賞を受賞 nyanco：YAPCスタッフ 前夜祭の感想 hogelog：『YAPC::Hiroshima 2024 非公式ふりかえり会』を始めていきます。ぜひYAPCのスタッフだった方や登壇してた方などなど、喋ってもいいですよという方はぜひ挙手をしていただけると嬉しいです。 本日の登壇者側で喋る人を紹介させていただきます。私はhoge
目次 初めに 極小理論 ステップ1. 問題の再現と確認 ステップ2. 最低3回のヒートダンプ採取 ステップ3. 問題の発見 ステップ4. 問題解決の確認 他のリソースへのリンク まとめ Something you might want to bookmark: Simple Guide to Finding a JavaScript Memory Leak in Node.js by @akras14 https://t.co/oRyQboa8Uw — Node.js (@nodejs) January 6, 2016 注釈：お気に入りに登録してください。 Simple Guide to Finding a JavaScript Memory Leak in Node.js （Node.jsでのJavaScriptメモリリーク発見簡単ガイド） @akras14 http://www.ale
React Server Components（RSC）は、ページの読み込みパフォーマンスやバンドルサイズのほか、Reactアプリケーションの書き方に近い将来大きな影響を与えることになる、素晴らしい新機能です。 Plasmicでは、Reactのビジュアルビルダーを開発しており、Reactのパフォーマンスには大きな関心を持もっています。 当社のクライアントの多くは、Plasmicを使用して高いパフォーマンスが求められるマーケティングサイトやECサイトを構築しています。 したがって、RSCはまだReact 18の初期実験機能ですが、Plasmicではその仕組みを詳しく調べています。 このブログ記事では、これまでに分かったことを紹介したいと思います。 Plasmicのメンバーによるツイートまとめもご覧ください。 React Server Componentsとは何か サーバサイドレンダリングとの
Webフロントエンド界隈の文献などにあたっていると、「コロケーション (co-location)」という考え方が時々登場します。 コロケーションを簡単に説明すると、関連するリソース同士を近くに置いておく、という考え方です。 FooComponent.tsx と同じディレクトリに FooComponent.test.tsx を置く GraphQL fragment は、クエリを発行するコンポーネントファイル (pages/user.tsx) ではなく、fragment を利用するコンポーネントファイル (components/UserInfo.tsx) の中で定義する pages/user.tsx からはサブコンポーネントのファイルで定義されている fragment を import してきて、クエリを組み立てて発行する API ドキュメントは API.md に書くのではなく、コードの中にド
これは、Kent C. Dodds 氏のブログ記事であるColocationを日本語訳してみたものです。 誤訳などあればIssueや PR を頂けると幸いです。 誰もがコードベースをメンテナンスしやすい状態に保ちたいので、コードベース（もしくはその一角）をメンテナンスしやすく理解しやすくなるように最善の努力を持って始めます。 時が経って、コードベースが大きくなるにつれて、依存関係（JS、CSS、画像など）を管理するのは、より一層難しくなります。 プロジェクトが大きくなるにつれて、コードベースが”チーム固有の知識”（あなたや他の数名に限られた知識）になってしまうことは往々にしてあり、 このような知識が”技術的負債”（言葉の正確性はともかく）の原因となります。 私は、コードベースを私自身（筆者）だけではなくチームメンバー、未来のメンテナー、そして半年後の自分自身にも扱いやすい状態に保ちたいです
このコーナーでは、2014年から先端テクノロジーの研究を論文単位で記事にしているWebメディア「Seamless」（シームレス）を主宰する山下裕毅氏が執筆。新規性の高い科学論文を山下氏がピックアップし、解説する。 Twitter: ＠shiropen2 米ノースイースタン大学などに所属する研究者らが発表した論文「Freaky Leaky SMS: Extracting User Locations by Analyzing SMS Timings」は、SMS（Short Message Service）を送ることで相手のスマートフォンの位置を特定するサイドチャネル攻撃を提案した研究報告である。攻撃者は、ユーザーのスマートフォンに複数のテキストメッセージを送信する。ユーザーの自動配信の返信のタイミングによって、ユーザーの位置を三角測量で特定できる。 攻撃は、SMSの送信者がネットワークを介し
本日 2023-08-05、悲しいお知らせが入ってきました。Vim の作者 Bram Moolenaar 氏が亡くなりました。謹んでお悔やみを申し上げます。 以下は Bram Moolenaar 氏のご家族から vim_announce に送られたメッセージです。 https://groups.google.com/g/vim_announce/c/tWahca9zkt4t 親愛なる皆様へ Bram Moolenaar が 2023年8月3日に逝去したことを、謹んでお知らせいたします。 Bram はここ数週間で急速に進行した病状に苦しんでいました。 Bram は人生の大部分を Vim に捧げ、皆様が一員である Vim コミュニティを大変誇りに思っておりました。
「Why hospitals don't learn from failures（なぜ病院は失敗から学ばないのか）」という論文を読んでなるほどと思う部分があったので、ここにメモ代わりに書いておく。 この論文の筆者（TuckerとEdmondson）は、医療ミスがなかなか減らない原因を探るために、全米の１０の病院を長期間に渡って調査・研究したのだが、その結果判明したのは、「システムの改善」という観点からは、ナースの優秀さと勤勉さが逆効果になっているという皮肉な話。 「優秀なナース」の定義はどこでも同じで、「目の前の患者が必要としているものを、あらゆる障害を乗り越えていち早く提供する」こと。取り替えるべきシーツが不足していれば別の階に走って行って調達してくるし、新米のナースのミスにはいちいち噛み付くこともなくそのミスを取り繕う。そんなナースたちにとっては、その手の「不具合」や「障害」は避けられ
一筋縄でいかないような難解な仕事を抱えていると、何をしているときでも、頭の片すみにずっとその仕事が居座っている感じがする。 憂鬱というほどではないけれど、邪魔になるときもある。楽しい飲み会の最中とか、ゆっくり休まるはずのバスタブでも、ふと気づくとそのことについて考えてしまったりする。気分転換が下手になる。 それはしかし、少なくともぼくの場合は、半分くらいは意図的にそうなっている。チャレンジングな仕事に携わるのは幸運なことだし、基本的には楽しいことだ。難しい問題について考え続けたい、考え抜きたいという前向きな気持ちもある。通勤路を歩いているときに仕事のことを考えるのは、ちょうどいい暇つぶしにもなっている。それゆえ、塩梅が難しい。 「シャワーを浴びているときに、いいアイディアが降ってくる」みたいな話とも、ちょっと近い。移動中の電車、お昼ごはん、夜寝る前のベッドの中。考える仕事は、わりとどこでで
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
当方、20代女性である。 先日ついうっかり足を捻挫してしまい、しばらく松葉杖生活となった。 その際に気付いたことがあるので書き留めておこうと思う。 「男性はぶつかってくる」 男性は駅や街の雑踏でぶつかってくる。それは女性を無意識に見下していて、避けないからだ。 これは女性なら多かれ少なかれ心のなかに共有された理解であると思う。私もそう思っていた。 もちろんわざわざぶつかってくる一種の変態もいる。彼らを置いておいて、男性一般に関しての話だ。 あくまでも個人ではなく集団としてである。 「日本人は酒が弱い」「日本人は清潔を好む」 これらは集団としては成立するが、これを個人個人に還元しようとするのはナンセンスだろう。あくまでもマクロな話であると念を押しておく。 私が気付いたのは、「女性はぶつかってくる」ということである。 私は定期の関係で新宿や秋葉原でよく下車するため、コロナ禍の中でも雑踏を通る機
「住所の揺らぎ程度のことにAIを使いたいだとかデジタル音痴」だの「住所の正規化なんてExcelで2時間あれば作れそう」だの、たいへんフットワークの軽やかな言説の数々に、位置情報界隈のみならず住所の正規化や名寄せに少しでも関わったことのあるエンジニアが総立ちでマサカリを投げていたのも記憶に新しい今日この頃ですが（2023年6月6日）、この手の騒動は周期的に起こってる印象です。 ということはつまり いつまで経っても解消されない、解決が困難な課題である その困難さが界隈以外に共有されていない であるわけで、その都度Twitterにトリビアが投下されてはTLが賑わい華やかではありますが、そろそろ自分の整理としてもどれだけ日本の住所システムがカオスで、その計算機的な処理がいかに困難かをメモっておこうかと思いました。 なおこの件については既にQiitaにGeoloniaの宮内さんが鼻血の出そうな良エン
はじめに フロントエンドエンジニアの @mk0812 です。自分は普段BackOfficeというチームで新規機能開発を担当しています。 2023年3月〜5月あたりで社内の有志を集めて、Webアクセシビリティの勉強会を行いました。この記事はその勉強会の振り返りをしていきます。 参加者 フロントエンドエンジニア: 4名 デザイナー: 4名 勉強会で使用した参考書 Webアプリケーションアクセシビリティ──今日から始める現場からの改善 (WEB+DB PRESS plus) なぜアクセシビリティの勉強会を実施したか 私自身が今回、この勉強会の主催をやりました。私が実施した動機としましては下記にあたります。 フロントエンドの実装であまりアクセシビリティを意識してこなかった WAI-ARIAが定めた仕様に基づくHTML属性（例: aria-label属性）をなんとなく使っている部分がある もっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
