You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Mark Seemann　著、吉羽 龍太郎、原田 騎郎　訳、Robert C. Martin　まえがき TOPICS 発行年月日 2024年06月 PRINT LENGTH 312 ISBN 978-4-8144-0079-9 原書 Code That Fits in Your Head FORMAT Print PDF EPUB ソフトウェアは複雑さを増すばかりですが、人間の脳は限られた複雑さしか扱えません。ソフトウェアが思い通りに動くようするには、脳に収まり、人間が理解できるコードを書く必要があります。 本書は、拡張を続けても行き詰ることなくコードを書き、複雑さを回避するための実践的な方法を解説します。最初のコードを書き始めるところから機能を追加していくところまでを解説し、効率的で持続可能なペースを保ちながら、横断的な問題への対処やトラブルシューティング、最適化を行なう方法を説明します

WindowインスタンスプロパティclosedconsolecookieStore (en-US) Experimental credentialless (en-US) Experimental customElementsdevicePixelRatiodocumentdocumentPictureInPicture (en-US) Experimental event 非推奨 external (en-US) 非推奨 fence (en-US) Experimental frameElementframesfullScreen Non-standard historyindexedDBinnerHeightinnerWidthlaunchQueue (en-US) Experimental lengthlocalStoragelocationlocationbarmenubarmoz

この記事について 私はWeb基盤を提供している企業でWebアプリケーションエンジニアをしています。 インフラや顧客基盤など複数のバックエンドAPIが動いており、それらを結合したアグリゲーション（BFF）の作成とフロントエンドの実装を担当することが多いです。 言語はTypeScriptとC#を選択する事が多く、フロントエンドではReact.jsとVue.jsを使用しています。これらをコンテキストとして私が「良いコード」を書くために日頃意識しているTipsを投稿していきます。 やらないこと インデントを揃える、命名基礎、アクセス修飾子などの基礎的な内容は割愛しています。 コードはTypeScriptで書いています。ですが特定の言語に特化した内容にはしていません。 プログミング全般に掛かかった内容であり、フロントエンドやバックエンドなど特定のレイヤーに特化した内容にはしていません。 良いコードと

見積もりとは？ Wikipediaによると見積もりとは、以下のようにあります。 見積（みつもり。見積り、見積もりとも書く）とは、金額・量・期間・行動を前もって概算すること。見積もること。あらましの計算をすること。また、その計算。目算。「所要時間を見積る」、「一日の来客者数をざっと見積もった」など、おおよその感覚で数字の見当をつける場合の口語体表現でも使われる。 Wikipedia このように見積もりとは、なにかを行う前に事前にその結果を予想しておくことを言います。 見積もりを使うケースは、ソフトウェア開発に限った話ではありませんが、製造業であるソフトウェア開発においては『見積もり』というタスクは様々なケースで登場します。 見積もりが苦手な人は多い ソフトウェア開発では、「この機能を開発するときにどのくらいで完成できますか？」といったケースが見積もりのシチュエーションとしては多いかと思います

よくある2ペインのレイアウト用コンポーネントを作りつつ、Web Componentsの仕組みを… Web Componentsを一言で説明すると「HTML/CSSが独立したカスタムタグを作れる仕組み」です。理…

Web Componentsは10年ほど前に提唱されたブラウザのコンポーネント技術の総称です。自分でタグを作ってHTMLを拡張していける技術なのですが、ブラウザの対応や仕様の確定などに時間がかかり、なかなか実用に至りませんでした。 私もずっと忘れていたのですが、React/Vueに疲れたなーと考えていたところ、ふと思い出し調べ直してみると、既に安定してProduction readyなのに情報が少なくすごくもったいなかったので、自分で調べつつ色々書き残すことにしてみました。 Web Componentsの誤解名前は聞いたことはあっても使ったことがある人はまだ少ないWeb Components。私も認識違いがありました。 UIコンポーネントを作る仕組みだから自分で作ることはないCSSをページをまたがって使い回すことがあるなら楽になります CSSで!important を書いてたらWebCom

排他制御とは 共有資源（データやファイル）に対して複数のアクセスが見込まれる場合に、同時アクセスにより不整合が発生することを防ぐため、あるトランザクションが共有資源（データやファイル）にアクセスしている時は他トランザクションからはアクセスできないようにして直列に処理されるように制御すること。 ■同時アクセスによる不整合の例 ■排他制御をすることで整合性を保つ 排他制御の方式 排他制御の実現方式はいくつか存在するが、ここでは代表的な楽観ロック（楽観的排他制御）と悲観ロック（悲観的排他制御）を紹介する。 楽観ロック（楽観的排他制御） 楽観ロックとは、めったなことでは他者との同時更新は起きないであろう、という楽観的な前提の排他制御。データそのものに対してロックは行わずに、更新対象のデータがデータ取得時と同じ状態であることを確認してから更新することで、データの整合性を保証する方式。楽観ロックを使用

以前、Twitter API の認証処理を自前で実装して記事にしたのですが、説明をもう少し上手くまとめたいと思ったため、別記事にしました。 Twitter API 以外でも同様に実装できると思いますが、Twitter API 以外向けにも書こうとすると説明をより抽象化しないといけないため、ここでは Twitter API 向けとして書きます。他向けに OAuth 認証を実装する場合は上手く読み替えて下さい。 参考「Creating a signature — Twitter Developers」 1. 認証の流れ 通常の HTTP リクエストに Authorization ヘッダーを加えることで認証します。 Authorization: OAuth oauth_consumer_key="xvz1evFS4wEEPTGEFPHBog", oauth_nonce="6eb24361e725

私はクラウドのプロダクトチームで働いているが、何を隠そう一番苦手で克服できていないことが、コードリーディングだ。ものすごーく時間かかるし、時間かかったうえに読み間違えたりするし、しかもめっちゃ頭使うのに他の人はずっと速いので敗北感しか残らない。先日もマネージャの Pragna に相談したら、最初は２時間かかるけど、３か月もしたら５分で終わるわよ。って言われたけど、いや、そもそも俺４時間は最低かかるねんけどな、、、って感じ。 技術イケメンの皆さんのアドバイス　よくよく私のキャリアを考えると、OSSにコントリビュートとかしていることはあったが、めっちゃくちゃ巨大でややこしいコードベースを読んで理解する必要が無いことが多かった。１からコードを書くのは得意だが、他の人のを読んでがっつり理解してとか、どうやったら出来るのかわからない。 当然自分の周りの技術イケメンの皆さんにコツを聞いていたのだが、ど

はじめに みなさん形式手法をご存知でしょうか？ 名前くらいは聞いたことあるけどいまいち何かわからないという方が多いのではないでしょうか。 その通りです。形式手法はアカデミアではそれなりに研究されているものの、 一般の（特にWeb系）ソフトウェア開発者が携わることはなかなかないのではないかと思います。 この記事ではソフトウェア開発に形式手法が導入されないのはなぜなのかを考察します。 この記事ではアジャイルソフトウェア開発において形式手法を導入する際のハードルについて考察します。 追記 本記事について、「形式手法は流行っていない」というのは正確ではないのではないかという指摘をいただきました。組み込み系や社会インフラ系等バグを絶対に出せないシステム開発では形式手法がよく使われているそうです。 ちょっと古いデータですが活用事例です。 誤解を招く紹介となっていたことをお詫びします。 さらに追記 ku

序文 目次 まえがき－第2版に向けて 第1版のまえがきより 第1章　達人の哲学 1 あなたの人生 2 猫がソースコードを食べちゃった 3 ソフトウェアのエントロピー 4 石のスープとゆでガエル 5 十分によいソフトウェア 6 あなたの知識ポートフォリオ 7 伝達しよう！ 第2章　達人のアプローチ 8 よい設計の本質 9 DRY 原則? 二重化の過ち 10 直交性 11 可逆性 12 曳光弾 13 プロトタイプとポストイット 14 専用の言語 15 見積もり 第3章　基本的なツール 16 プレインテキストの威力 17 貝殻（シェル）遊び 18 パワーエディット 19 バージョン管理 20 デバッグ 21 テキスト操作言語 22 エンジニアリング日誌 第4章　妄想の達人 23 契約による設計（DbC） 24 死んだプログラムは嘘をつかない 25 表明を用いたプログラミング 26 リソースのバラ

キチガイに刃物、ゴミプログラマに継承。危険なものは取り上げるべきだ。 オブジェクト指向プログラミングにおける継承は強力な手法であるが、これを正しく使えるプログラマは残念なことに極めて少ない。たいていの場合、継承を使うことで却ってプログラムの保守を困難にしてしまう。継承のアンチパターンの最たるものは、単なるメソッドやメンバ変数の共有のために継承を使うパターンだ。これを行うとデータが密結合になってバグの原因になり、プログラムを把握することも極めて困難になる。 そもそも、熟達したプログラマの感覚では、業務で書くアプリケーションの実装に継承を使うべき局面などほとんど無い。ライブラリ等のより低レベルな処理で仕様が確定しているものについては、継承が効果的となる場合もあるが、複雑なアプリケーションのロジックに継承を使うのはほとんどの場合、時期尚早な抽象化となる。 また、凡庸なプログラマが継承で実現したい

Improve your programming skills through repeated training.

回答 (18件中の1件目) 言語を選んだ理由がしっかりあるのなら、いわゆる「Hello, World」か「Lチカ」（LEDランプをチカチカ点滅させる）を一度は作ってください。まずはそこからです。 こんにち（2019年）であれば、ググればいくらでも出てきます。個人ブログの記事の山があります。 もし見つけられなかったら（この時点で実は『プログラマーになるべきでない』のですがこれから成長できると期待して）、 「どうやって調べたらいいですか」と、先輩（年齢じゃなく経験のですよ）に聞くなり、ヤフー知恵袋でもQuoraでもに質問するなりしてください。聞かれた人と後進のために（も）なります。 ...

Microsoft MakeCode は、無料でコーディングが学べる、オンラインのプラットフォームです。誰でもゲームの構築やデバイスのコーディング、Minecraft の改造を行うことができます。