LCHは、UIにベストなカラースペース｜hirotoarakawa
Linearのリニューアル記事がすごく良かった。 A design reset (part I) How we redesigned the Linear UI (part Ⅱ) その記事の中で「LCHカラースペース」について書かれていた。知らなかったので調べてみると、以下の記事を見つけた。 この記事の内容を抜粋しながら、自分用に簡易なメモとしてまとめる。 LCHとは？LCHは簡単に言うと、異なる色相でも同じコントラストに見えるように構成されたカラースペース。 1976年に国際照明委員会 (International Commission on Illumination, CIE) によって最初に定義された色空間であるため、CIELAB とも呼ばれている。 LCH は、Lightness（明度）、Chroma（彩度）、Hue（色相）の略。 HSL と LCH の違いLightness（明度
シニアエンジニアだもんな｜cba
オンボーディングのときに「お手並み拝見」をしないようにね。ってのはちょくちょく聞く。そうだなって思う。どんなことをしてくれるんだろう？じゃなくて、自分からサポートしようよって話。 そういう新しくチームに来た人に対しては、僕はわりとそういうことをせずに動けているとは思ってる。けど、自分が尊敬している人に対しては、この「お手並み拝見」がまだまだ発動しやすいから、気をつけたいなと思っている。 例えば、全社アーキテクトが新しい取り組みを始めたときとか、自分のマネージャが何かに挑戦しようとしているときとか。そういうときに「この人は、どんなことをするんだろう？」って観察してしまう。とか一歩前に出て「手伝いますよ？」とか。 どんなことをするんだろう？じゃないんだよ。一緒に挑戦していくんだよ。手伝いますよ？じゃないんだよ。自分でやることを見つけていくんだよ。シニアエンジニアだもんな。という気持ち。 ちょっ
テキストコミュニケーションで意識していること｜ymdkit
リモートワークで仕事をしていると、Slack や Teams といった何かしらのチャットツールでコミュニケーションを取ることが多い。そうやって仕事を続けていく中で「こう伝えたらよりスムーズに話が進んだかな...」という後悔は多々あり、日々試行錯誤を続けている。 そうやって試行錯誤を続けていく中である程度テキストコミュニケーションを取る上でのフォーマットが定まってきた気がするので、箇条書きでまとめてみようと思う。（随時更新予定） prefix （接頭辞）をつける文章の先頭にその文章の目的がわかるような prefix をつけて、何のためにポストしたかを一目で分かりやすくする。例えば以下のような prefix をつけることがある。 【質問】→ 相手の返信が欲しい時 【共有】→ 返信は不要だが、内容は把握しておいてほしい時 【メモ】→ 返信不要で、後から検索できるよう残しておきたい時 箇条書きする
Apple Vision Proを普段の仕事環境として使い始める｜MIRO
これだけで何不自由なく仕事ができる。あとおそらく数ヶ月後の未来には。 Apple Vision Proを日常的に使い始めた。「日常的に」というのがとてもだいじで、デモを体験するとか、ちょっと借りてみるとかではなく、わざわざ大枚はたいてアメリカまで買いに行ったのはこれをやるためだった。はたして、これが普段使いのツールとして便利に、生活に馴染む時代はやってくるのだろうか？というのを見極めたい、とおもったからだ。 実際に作業環境として「空間コンピューティング」というやつを受け入れ始めると、AppleとMetaの違い、Vision ProとQuestの設計思想の違いがより際立って見えてくる。Vision Proの話を見聞きすると、だいたいセットで「それ、Quest3でも同じことができるんだけど」という話もついてくるんだけれども、同じようで、同じでないんだということがよくわかる。 Appleが作りた
Apple Vision Proを買いました｜MIRO
まあなんやかんやとありまして、アメリカ・ロスアンゼルスまで出かけて新発売のApple Vision Proを買いました。羽田からロスアンゼルス国際空港まで直行便で向かい、空港についたらそのまままっすぐ近隣のApple Storeへ。その場でデモ体験とフィッティングをして、予約分を受け取ったらストアから徒歩数分のホテルへ。そのあとはもう海外？観光？なんすかそれ？？の勢いでずっとホテルの部屋でApple Vision Proと戯れていました。あ、途中ご飯は食べにいきましたけど。 いやー、たいへん充実した旅というのはこういうのを言うのであるのだなあ。ふっひっひ。実にたのしいです。いまこの記事も、MacBook Air M1＋Apple Vision Proで書いてます。目の前に、巨大なモニタをばーーーんと広げて。ばばばーーーーんと、ね。 ともかくビデオパススルーがきれいなのと、映像がとても緻密で
毎日始業直後25分の技術キャッチアップがよくワークしている話｜helloyuki
子どもが生まれたのでそちらに時間をとられて、なかなか技術のキャッチアップが難しいことが増えた。こう書くと、隙間時間を使えばよいではないかと思われるかもしれない。実際うちの子はかなり昼も夜も寝る（寝た）し、お世話がかなり楽な方で隙間時間はある。しかし子育てしている方はわかると思うが、子が寝ている間は親も寝ないと体力が持たない。加えて、子はいつまで機嫌良くいるかわからない。いつ中断されるかそわそわしている状態で、まとまった論考を腰を据えて読む気力などない。というわけで、隙間時間を使っている気力はない。 数ヶ月前に仕事に復帰して以降、どうも最新技術の動向やトレンドを追えなくなっているのが悩みだった。ちなみに、「最新の話題を常日頃から追うべきか」という議論は時折見かけるが、私は今より高い給与得たい、かつ（たとえば組織全体を見るような）難しい仕事をしたいのであれば追い続けるべきという立場だ。というわ
ライブラリを気軽に導入しないこと｜Katashin
本をよく読むエンジニアであれば、ライブラリの導入には慎重になるべきだということは共通の認識になっていると思う。しかし、どういったライブラリを導入すべきかという選定基準は自分の中ではまだ言語化できてないことに最近気がついた。絶対的な基準を設けるのではなく、ある程度柔軟に考えるべきだと思うが、自分がどう考えて選定するかを考えてみる。 品質 テストが書かれているか 自分のプロダクトでテストを書いているのであれば、ライブラリにもテストを求めるべき 長い間継続してメンテナンスされている（いた）か 急に出てきてセンセーショナルな売り文句で注目を浴びるライブラリは怪しむべき コードの品質は悪くないか 導入する前にライブラリのコードは読むべき 効果 その後の実装効率をどれだけ上げるか 導入しない場合と大して変わらないのであれば不要 自分でそれを書いた場合と比べてどうか 短時間で同じようなものを書けるのであ
GraphQLのよくないところ｜adwd
銀の弾丸ではないので良し悪しあるのは当然として、それを差し引いても以下の2つの要素があるのではと思った。 なんとなく使ってもメリットが十分得られない RESTでできてたことができなくなる（※ちゃんと調べればできる） なんとなく使ってもメリットが十分得られないWeb界隈は良くも悪くも新しい技術をとりあえず使ってみるところがあると思っていて、そこがGraphQLは十分に事前知識を持って導入しないとメリットが薄いところとミスマッチを起こしてネガティブな意見が出るのかなと思う。 GraphQLはもともとFacebookがReact, Relayとの組み合わせで使い始めたもので、クライアントライブラリとしてのRelayと、IDやページネーションについての追加仕様を公開している。ライブラリとしてのRelayは使わなくても仕様に乗っかることはできるのでそれをRelayスタイルと言ったりする。出典を忘れた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
"GPTs Builder Summit"参加者の、世界トップクラスのGPTsのプロンプトを暴いてみた (日本は除く)｜Love