タグ

programmingに関するfukkenのブックマーク (265)

  • リーダブルコードを読んで重要だと感じたルールを抜粋 - Qiita

    はじめに 業務で開発をしていて、Pull Requestを送るたびに命名について厳しいレビューをもらうので、業務で特に重要だと感じた部分のみまとめてみました! 最初は「動けばいいじゃん!」と思っていたのですが、チーム開発、仕事となるとそうはいきません。 品質も含めて評価されるため、読みやすいコードを書くということは非常に重要です。 レビューで毎回のように 「ちゃんとリーダブルコードを読みましたか?」 と厳しい指摘を受けるので、できるだけその回数を減らしていきたいです。 毎日レビューで厳しい指摘を受けるのは(おそらく上司仕事のためとしてコードに対しての指摘をしていると思われるが)とても辛いです。 レビューは あくまでもコードの指摘をしているだけ で、自分自身の人間性や仕事に対するダメ出しをもらっているということではない!と思うようにしてます。 とはいえできるだけレビューで受ける指摘は減らし

    リーダブルコードを読んで重要だと感じたルールを抜粋 - Qiita
    fukken
    fukken 2023/08/30
    getとかfetchとかの命名規則で毎回悩むので、こういうルールで機械的に書いていきたい。"「ちゃんとリーダブルコードを読みましたか?」 と厳しい指摘を受ける" 心理的安全性が低い・・・
  • LLMを理解する一歩として「ゼロから作るDeep Learning」をやった - $shibayu36->blog;

    LLM、GPT界隈を追いかけていて、GPTの仕組みと限界についての考察(2.1) - conceptualizationという記事を見かけた。これを見たとき、「どういうことか全然理解できない」という気持ちになった。また、その他LLMの解説記事を理解できないことが多く、自分の機械学習知識不足が明確になった。 理解できなかったことは悔しいし、LLMやChatGPTをうまく使いこなすには最低限どのような原理で動いているか理解したいと感じた。そこで一歩目として「ゼロから作るDeep Learning」を完走した。 ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装 作者:斎藤 康毅オライリージャパンAmazon 知識なしからはじめたので時間はかかったが、次のように進めていった。 自分もコードを写経しながら読む レポジトリは https://github.co

    LLMを理解する一歩として「ゼロから作るDeep Learning」をやった - $shibayu36->blog;
  • コードの複雑度をあげる Pull Requests を GitHub Actions で止めよう

    循環的複雑度が閾値を超えた Pull Requests に、自動的に変更をリクエストする 「コードの品質を、維持したいよーーー」 ということで、テストや LinterGitHub Actions で実行している環境はよくあると思いますが、今回は 循環的複雑度 を継続的に計測して、閾値を超えた場合に自動的に Pull Request に対して Request Changes のレビューをしようという試みです。 Lizard この例では、Lizard を使用して CCN を計測します。 おそらく似たようなツールでも同様に実行することができると思います。 Lizard は Python で開発されている CCN 計測ツールです。(追記:シンプルに書いてしまいましたが、もちろん他の指標も計れます) 以下のようにサポート言語が多いので、大抵の場合で採用できそうです。 サポート言語 (1.17.

    コードの複雑度をあげる Pull Requests を GitHub Actions で止めよう
  • 状態、結合、複雑性、コード量の順に最適化する - valid,invalid

    There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結

    状態、結合、複雑性、コード量の順に最適化する - valid,invalid
  • Nintendo Switch™ ネイティブバイナリへの Go コンパイルを成功させた話

    記事は「Go Advent Calender」25 日目の投稿です。 Happy Holidays! EDIT (2022-01-03): There is an English version of this article. tl;dr いままでは Go プログラムを Nintendo Switch 上で動かすために WebAssembly に一度変換し、それを C++ に変換してコンパイルするということを行ってきました。今回、 Go の Nintendo Switch 向けネイティブコンパイルに成功し、実際に手元でゲームを動かすことができました。手法として、システムコール呼び出しを C の関数呼び出しに置き換えるように -overlay オプションを指定してビルドしました。また、 -overlay オプションに指定する JSON を生成するパッケージ Hitsumabushi を開

    Nintendo Switch™ ネイティブバイナリへの Go コンパイルを成功させた話
  • 「テスト書いてないとかお前それ〜」が私の代名詞になるまで。テスト駆動開発とともに歩んだキャリア - Findy Engineer Lab

    におけるテスト駆動開発の著名人といえば誰か? この問いを投げかけられたとき、多くのエンジニアが思い浮かべる人物がいます。ITコンサルタント・ソフトウェアエンジニアの和田卓人(@t_wada)さんです。和田さんは日のテスト駆動開発の第一人者として、長年、この分野の実践や講演・執筆などの普及活動を続けてきました。 こう書くと、読者のなかには「和田さんはもともとテストが好きだったから、テスト駆動開発の第一人者になれたのでは」と思われた方もいるかもしれません。しかし、その答えはNOです。むしろ和田さんは、テストが嫌いなエンジニアだったといいます。ある出来事をきっかけとして、嫌いだったテストを好きになれる方法を見つけたのです。 読者の方々にも「自分には○○なんて向いていない」という印象を抱いている技術領域があるかもしれません。ですが、そんな領域にこそ、あなたの新たな可能性が詰まっているかもしれ

    「テスト書いてないとかお前それ〜」が私の代名詞になるまで。テスト駆動開発とともに歩んだキャリア - Findy Engineer Lab
  • JavaScript dayjsはMoment.jsの代替になるか? | nansystem

    JavaScriptの日付操作には罠が多く、業務では日付操作を簡単かつ安全に操作するライブラリが使われる。日付操作のライブラリの中でもMoment.js (opens new window)(Star数40,601)はよく知られているが、ファイルサイズが大きくパフォーマンス改善の妨げになることがある。 そこでこの記事ではより軽量でMoment.jsの代替となるdayjs (opens new window)(Star数19,872)を紹介する。 # dayjsとは dayjsとは、日付操作を簡単にするJavaScriptのライブラリだ。Moment.jsのAPIと広く互換があり、gzip圧縮されたサイズは2.71KBと軽量なのが特徴だ。 # インストール dayjsが十分Moment.jsの代わりになり得るのか確認していく。 まずはインストールして、業務で使われる日付操作をみていく。

  • リファクタリングして学ぶTypeScriptでクリーンアーキテクチャ - Qiita

    概要 最近,ASCII Dwangoさんから「クリーンアーキテクチャ」というが出版されました. そこに書いてある内容は素晴らしいものでした.しかし,実際に組んでみた場合,どういう風に作るのが良いのか?どういう問題があるのか?そういった疑問が湧いてきました.そこで, 実際に非クリーンアーキテクチャのコードをリファクタリングしていくことで,クリーンアーキテクチャの要点を感じる. という試みです. クリーンアーキテクチャとは ここでは簡単にしか説明しませんが,実際にを読んで勉強することをお勧めします. 「クリーンアーキテクチャ 達人に学ぶソフトウェアの構造と設計」のp200によると フレームワーク非依存:アーキテクチャは,機能満載のソフトウェアのライブラリに依存していない.これにより,システムをフレームワークの制約で縛るのではなく,フレームワークをツールとして使用できる. テスト可能:ビジネ

    リファクタリングして学ぶTypeScriptでクリーンアーキテクチャ - Qiita
  • 翻訳 「DDD, Hexagonal, Onion, Clean, CQRS…これらをどうやり遂げるのか?」 - tagoto web - confluence

    We tried to load scripts but something went wrong. Please make sure that your network settings allow you to download scripts from the following domain: https://id-frontend.prod-east.frontend.public.atl-paas.net

    fukken
    fukken 2018/10/05
    ヤバい(やばい)(やばたにえん)
  • Webフロントエンド パフォーマンス改善ハンドブックを公開しました - dwango on GitHub

    パフォーマンス改善ハンドブック ウェブページにおけるパフォーマンスに関する問題の見つけ方や考え方の事例をまとめた Webフロントエンド パフォーマンス改善ハンドブックを公開しました。 URL: https://dwango-js.github.io/performance-handbook/ このハンドブックでは過去に行ったWebフロントエンドのパフォーマンス改善の事例を中心に紹介しています。 注意点としてWebフロントエンドは常に変化しているため、現在の最適な解決方法を提案するものではありません。 また、アプリケーションによっても最適な解決方法は異なります。 今回の事例ではViewライブラリにReactを用い、映像再生プレイヤーなどある程度複雑な機能を持ったウェブアプリケーションのWebフロントエンドを扱います。 具体的にはニコニコ生放送(以下「生放送」)で行った事例を中心に書かれていま

    Webフロントエンド パフォーマンス改善ハンドブックを公開しました - dwango on GitHub
  • あえてWebエンジニア以外の人に 聞いてほしいWebRTCの話

    iOSDC Japan 2018 3日目の発表資料です。

    あえてWebエンジニア以外の人に 聞いてほしいWebRTCの話
  • オブジェクト指向の呪いと、その避け方 - mizchi's blog

    このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(

    オブジェクト指向の呪いと、その避け方 - mizchi's blog
  • Testing Strategies for React and Redux – Mozilla Hacks - the Web developer blog

    When the Firefox Add-ons team ported addons.mozilla.org to a single page app backed by an API, we chose React and Redux for powerful state management, delightful developer tools, and testability. Achieving the testability part isn’t completely obvious since there are competing tools and techniques. Below are some testing strategies that are working really well for us. Testing must be fast and effe

    Testing Strategies for React and Redux – Mozilla Hacks - the Web developer blog
  • テスト駆動開発における進化的設計とデザインパターンの勘所とは?〜テスト駆動開発をやめて、なお残すべき習慣とは(9)

    前回から、書籍を辿り、TDDの再考を試みています。TDDを既に知っている、実践しているという人にとっては、TDDについて新しい発見、ジャメヴ(未視感)が起きれば幸いです。たとえTDDが不要だったとしても、不要だと判断したものが一体何だったのか知ることは欠かせません。 忘れないで、テスト駆動開発にもデザインパターンの話が出てくるよTDDはテストファーストやベイビーステップのインパクトがありすぎて、あまり目立っていないですが、書籍『テスト駆動開発』にもソフトウェアパターンの話が出てきます。そう、出てくるんですよ。 余談ですが、テスト駆動開発3部におけるSingletonパターンの説明はGoFの説明とは違ったユニークな内容になっています。(で確認してみてね) 1回だけ設計ではなく繰り返し設計注意点ですが、テスト駆動開発においてのソフトウェアパターンは、プロジェクト初期に1回だけパターンを使って

    テスト駆動開発における進化的設計とデザインパターンの勘所とは?〜テスト駆動開発をやめて、なお残すべき習慣とは(9)
  • ログイン - はてな

    パスワードを忘れた方はパスワードの再設定を行ってください。 初めての方ははてなID登録 (無料) してください。 うまくログインできない方はお問い合わせをご覧いただき、Cookieの設定をご確認ください。

    ログイン - はてな
  • 真偽値を返す関数のネーミング - Qiita

    みんな exists を使ってます。 納得できようができまいが、exists なのです。 ソフトウェアの世界では、AppleMicrosoftGoogle が黒と言ったら黒です。 黙って従いましょう。 このように、関数名の表現に困ったら、世の中の API を参考にすると良いです。 非ネイティブの我々では思いつかないような的確な表現が見つかることもあります。 関数の名付け方 真偽値を返す関数は if 文で使われることが多いので、頭に if を置いて最もしっくり来る表現が良いと思います。 個人的には、真偽値を返す関数名を考えるときは以下のフォーマットに当てはめるようにしています。 if オブジェクト名 関数名 「項目が選択中だったら」なら "if item is selected" なので関数名は item.isSelected() となります。 同様に「項目が存在したら」なら "

    真偽値を返す関数のネーミング - Qiita
  • 初めての自動テスト

    Webシステムの自動テストを始めたい方を対象に、自動テストの考え方やフレームワークを解説する書籍です。テストのピラミッドやユーザーインターフェイステストの概念など、基礎的な事柄から、レガシーシステムへのUIテストの追加、RESTfulなWebサービスのテスト、ブラウザ上のJavaScriptの挙動をユニットテストでテストする方法など、実践的な事柄までを豊富なイラストとサンプルを使って分かりやすく解説します。さらにテストファーストやモックの活用法、テスターに向けた自動テストのためのプログラミング基礎知識なども詳述。自動テストを書くためのノウハウを網羅した書は、自動テストをマスターしたいエンジニア必携の一冊です。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作成し、増刷書籍を印刷した月です。お手持ちの書籍では

    初めての自動テスト
  • CPU使用率は間違っている | Yakst

    Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか?プロセッサーがどのくらい忙しいか?違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが

    CPU使用率は間違っている | Yakst
  • トヨタの急加速事故は欠陥だらけのファームウェアが原因?――原告側調査の詳細

    トヨタの急加速事故は欠陥だらけのファームウェアが原因?――原告側調査の詳細:ビジネスニュース 企業動向(1/3 ページ) 2007年に米国オクラホマ州で、トヨタ自動車の乗用車「カムリ」が急加速したことによる死亡事故が発生した。事故をめぐる訴訟において、原告側証人として事故原因の調査を行った組み込みソフトウェアの専門家は、裁判で「カムリのエンジン制御モジュール(ECM)のファームウェアに重大な欠陥が見つかった」と報告した。 2013年10月24日、トヨタ自動車の乗用車の急加速による死亡事故をめぐる米国オクラホマ州での訴訟において、陪審団は同社に対し賠償を命じる評決を下した。なお、訴訟は、10月25日に和解が成立している。 この事故は、2007年にオクラホマ州で、2005年モデルの「カムリ」が急加速し、運転者と同乗者の2名が死傷したというもの。運転者ら原告側は、運転者の意図しない急加速(UA

    トヨタの急加速事故は欠陥だらけのファームウェアが原因?――原告側調査の詳細
    fukken
    fukken 2017/05/17
    ITはまだまだ産業としては未熟だよな。それはそれとして、現在の未熟な基準においても杜撰としか言いようのない品質だが。
  • Mixins: a refactoring anti-pattern

    Home Blog 2012-05-07 I spend an unusually large amount of time thinking about interactions between what I call ‘past me’ and ‘future me.’ It seems that my life changes significantly every few years, and I like to ground myself by imagining how odd it would be if ‘current me’ could tell ‘past me’ things like ‘Someday, you’ll be speaking at OSCON.’ It’s not always general life stuff, though, it’s of

    Mixins: a refactoring anti-pattern