最初から強いやつの特徴 - Qiita
はじめに どんな仕事でも強い人は存在する。 でも最初から強い人は珍しい。 これは、web 業界に身を置いてみて、信じられないくらいムキムキになっていった人たちを見てきた私が送る こうしたら強くなれるかもしれない？指南書である。もしエンジニア職に興味があるのであれば、一考になるかもしれない。 最初から強いやつの特徴 平日の稼働時間以外も勉強 or 開発する 土日も勉強 or 開発する 公式ドキュメントをちゃんと読む 以上のような当たり前のことは、最初から強い人じゃなくてもやるので特徴に入れません。 1. 読解能力が異常に高い 国語の力です。 これは、ちゃんとドキュメントに書いてあることが理解できると同義です。 そしてこれが本当に大事です。 強い人に質問すると必ず「ん？ Docs 読んだ？」って聞いてきます。私は (...読んだわ！) って内心思ってますが、それは読んだだけです。内容をちゃんと
メルカリにおけるA/Bテスト標準化への取り組み
2021/7/28, Retty ✕ Mercari Analyst Talk Night! https://mercari.connpass.com/event/218848/
Managing Focus Transitions in Slack - Slack Engineering
Divya Kamath Staff Software Engineer, Slack Systems At Slack, we believe that designing an optimal keyboard experience is key to delivering a best-in-class product for all our customers. However, despite our design system components being individually accessible, we heard from keyboard users that we were still missing focus transitions in their end-to-end user experience. Non-sighted users who rel
Code Coverage Best Practices
I am not sure if I understand the following statement correctly, could you please explain a little more or give a simple example? Thanks. “because your tests did not cover a specific edge case in an area that did have code coverage” ReplyDelete Not the original author, but there are several levels of code coverage (see also https://en.wikipedia.org/wiki/Code_coverage#Basic_coverage_criteria): - Li
Fastly、JavaScriptエンジンをWebAssemblyで実装。CDNエッジのサーバレス環境「Compute@Edge」でJavaScriptサポート発表（訂正済み）
Fastly、JavaScriptエンジンをWebAssemblyで実装。CDNエッジのサーバレス環境「Compute@Edge」でJavaScriptサポート発表（訂正済み） （お詫びとお知らせ：本記事はFastlyの発表と同社へのメールでの取材に基づいて執筆いたしましたが、記事公開後に同社より、回答を間違えたとの申し出がありました。そのため改めて同社から提供された情報を基に、タイトルと本文を訂正しました。訂正前の記事内容は本文最後にHTMLでコメントアウトされています。） 大手CDNベンダのFastlyは、CDNエッジで提供しているサーバレスコンピューティング環境「Compute@Edge」で、JavaScriptのサポートを発表しました。 JavaScript on Compute@Edge is here. https://t.co/wSHiJfPdvf pic.twitter.c
もうリリースは怖くない ― 大きな変更を安全に本番適用するTips - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、AWS版kintoneのDevOpsエンジニアをしている@ueokandeです。 AWS版kintoneは2019年9月のローンチから現在まで、幾度となく機能改善をしてきました。 ローンチ当時よりも利用者が増え、スケーラビリティのために内部設計を大きく変更することもあります。 先日公開したメール送信の設計変更もその1つです。 blog.cybozu.io 安定運用のために必要なリリースではありますが、実装を大きく変えることで不具合混入のリスクもあります。 それだけではなく、パフォーマンス改善のつもりが、本番環境に投入して逆にパフォーマンス低下が発覚するというケースもあります。 この記事では、大きな変更を安全にリリースするためのTipsを紹介します。 記事の最後ではSpring Bootの実装例と、Kubernetesでの実現方法も紹介します。 切り戻し戦略 大きな変更を安全にリ
CSSでブロック要素の幅をコンテンツのサイズぴったりにしたい時のこれからの記述方法
sectionやdivやpなど、ブロック要素をボーダーで囲うと、全幅（親要素の幅）になります。そのブロック要素の中のコンテンツが少なく、ボーダーの幅をコンテンツのサイズに合わせたい場合は、どう実装していますか？ ブロック要素のままでは親要素の幅になってしまうので、通常はdisplay: inline;やdisplay: inline-block;を加えると思います。 しかし、ブロック要素のwidthにfit-content値を使用すると、ブロック要素のまま（displayの値を変更せずに）コンテンツのサイズに合わせることができます。 「古い方法」「より良い方法」としたのは、上記画像の直訳です。古いからダメということではなく、より良い方法が使えるようになり、ケースバイケースで使用するのがお勧めです。 古い方法
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジリティを支える品質特性 / Agility and Quality Characteristics Developers Summit 2021 Summer
コンテナ監視って何見るの？～初心者編～
Project dead? · Issue #3930 · axios/axios
