タグ

programmingに関するmapk0yのブックマーク (190)

  • レビューが爆速になる!レビュアーに優しいPull Requestの極意

    はじめに こんにちは、JAXA認定の宇宙ベンチャー企業、株式会社 天地人 (てんちじん) でエンジニアリングマネージャーをしている白井と申します。普段は天地人コンパス (Tenchijin COMPASS) のフロントエンドまわりの開発を行っています。 推し人工衛星はだいち4号です(昨年7月に種子島まで打ち上げを見にいきました) レビューを依頼したときにありがちなこと チーム開発を行う上で、Pull Request(以下PRと略します)ベースのコードレビューは当たり前になってきていると思います。 コードレビューは、他のメンバーにあなたのコードを見てもらい、フィードバックをもらうための重要なステップです。 しかし、レビューを依頼した際に以下のような状況に直面したことはないでしょうか? 😇 レビュー依頼してしばらく経っても返信がなく、状況を質問してようやく 「あ、今から見ます」 と言われてし

    レビューが爆速になる!レビュアーに優しいPull Requestの極意
  • Dry-runを実現する定番テク知りたい - Lambdaカクテル

    ソフトウェア開発の現場では、スクリプトを発射してシステムになんらかの変更を加える、ということがよくある。DBに変更を加えたり、なんかを削除したりといった具合。専用の管理画面をわざわざ実装するまでもない、というときに使われがち。 Dry-run スクリプトによっては破壊的なことをする(i.e. 元に戻すのが不可能/たいへん)ので、勢い良くいきなり発射するのではなく、どういう感じの実行結果になるのかを試走させてから実際に動かしたい。 どうするかというと、破壊的な箇所では、一定の条件でスキップしたりやったフリをするような処理に置換したりする。 一般にこういうテクニックはDry-runと呼ばれているはず。元々の意味は予行演習という意味らしい。 Dry-runどうやって実現する Dry-runはあくまで技法であり、ネイティブにこれをサポートする機構はないので、実現する方法はいろいろある。よくあるのは

    Dry-runを実現する定番テク知りたい - Lambdaカクテル
  • テキストをコピペするときにスタイルごとコピーされちゃうのってどんな仕組み? - Qiita

    概要 文章をコピペしてエクセルに張り付けたときに、画面のスタイルもコピーされてしまって困ったことはありますか?ありますよね! (↓こんな感じ) 私もよくやってしまうのですが、実際にどのような処理が行われているのかよく分かっていませんでした。理解を深めるためにも、自分で実装して謎を解いていきたいと思います。 3つパターンの処理を実装 比較のため、プレーンテキスト・HTMLテキスト・リッチテキストのコピー機能をサンプルプログラムを実装してみました。 (リッチテキストのコピーが、範囲選択してコピペしたときと同じ機能を想定しています。) HTMLファイル 画面表示されるHTMLは下記のような感じです。各コピー処理でid="message"の部分を固定でコピーするようにします。 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"

    テキストをコピペするときにスタイルごとコピーされちゃうのってどんな仕組み? - Qiita
  • 「良いコードとは何か」で消耗するのはもうやめよう - DMM Developers Blog

    これはなに? こんにちは、DMM.comのミノ駆動です。 プラットフォーム開発部 Developer Productivity Group 横断チームにて、 プラットフォームの設計品質向上に取り組んでいます。 さて、ネット上ではソフトウェア開発における「良いコードとは何か」をめぐって、 いろんな意見が交錯したり、 ときには激論を呼んだりします。 収拾がつかないこともしばしばです。 この記事は、良いコードを考えるうえでの要素を整理し、 建設的な議論を助けることを目的とします。 これはなに? この記事の理解目標 良いコードをめぐる議論 議論1: 何をもって良いコードなのか 議論2: 良いコードはどうやったら書けるのか 議論3: 「綺麗なコード(良いコード) vs 動くコード」問題 議論改善のために提案します 提案1: ソフトウェア品質特性の観点でコードの良し悪しを判断しよう 提案2: 原理原

    「良いコードとは何か」で消耗するのはもうやめよう - DMM Developers Blog
  • ロケールにサンパウロを指定しているテストが突然失敗 - nakaoka3の技術ブログ

    数日前の退勤間際、1つ機能を実装してPull Requestを作って満足した気持ちで退勤しようとしていた。しかし作ったPRを見るとCIのテストが失敗している。どうやら失敗しているユニットテストがあるらしい。テストの結果を覗くと心当たりのない日付に関係するテストが失敗している……。月末だったら閏年の関係とか、そういうことも考えられるがまだ月末ではない。おかしいな、と思いつつ、明日に再実行したら成功するかも知れないし、ひとまず忘れて退勤した。 翌日、出社すると他のブランチでも漏れなくCIのユニットテストが失敗していることがわかった。これではリリースもできないので、ちゃんと調べて修正することにした。失敗しているテストを見るとタイムゾーンがUTC-3の場合のテストをしているようだった。指定されているロケールは America/Sao_Paulo サンパウロ、ブラジルの都市だ。 最初に思いついたのは

    ロケールにサンパウロを指定しているテストが突然失敗 - nakaoka3の技術ブログ
  • GitHub - sourcebot-dev/sourcebot: Blazingly fast code search 🏎️ Deployed as a single Docker image 📦 Search million+ lines of code in your GitHub and GitLab repositories 🪄 MIT licensed ✅

    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. Dismiss alert

    GitHub - sourcebot-dev/sourcebot: Blazingly fast code search 🏎️ Deployed as a single Docker image 📦 Search million+ lines of code in your GitHub and GitLab repositories 🪄 MIT licensed ✅
  • Tips on naming boolean variables - Cleaner Code

    Michael Z Posted on Oct 3, 2019 • Edited on Jan 9, 2022 • Originally published at michaelzanggl.com Originally posted at michaelzanggl.com. Subscribe to my newsletter to never miss out on new content. There is a convention to prefix boolean variables and function names with "is" or "has". You know, something like isLoggedIn, hasAccess or things like that. But throughout my career I have seen and w

    Tips on naming boolean variables - Cleaner Code
  • その説明、コードコメントに書く?コミットメッセージに書く? プルリクエストに書く? - #phpconfuk 2023

    2023/06/24 開催「PHPカンファレンス福岡2023」(https://phpcon.fukuoka.jp/2023/ )の LT 資料です。 詳細:https://fortee.jp/phpconfukuoka-2023/proposal/ae71f3a7-4c3c-4c87-8816-…

    その説明、コードコメントに書く?コミットメッセージに書く? プルリクエストに書く? - #phpconfuk 2023
  • エラーが出たら喜べ。エラーをちゃんと出せ。 - Qiita

    どうもエラーを出すもしくはエラーが出るのが怖いという人がいるみたい。例えば改修を行うときに既存部分でエラーが出ないことを最優先にして増築を行いいびつな構造を生み出すとか、単純に例外を全然使わないとか。エラーが出ると、「うわ、エラーになった。手間かけさせやがって面倒だなぁ…」みたいな感覚があって、とにかく自分がコードを書くときも一切例外を投げないというスタンスをとりがちなのかもしれない。 私はここで、適切にエラーが出てくれるのはむしろ喜ばしいことであり、自分がコードを書くときも積極的にエラーを出すようにすべきだ、という主張をする。 関数定義のドキュメンテーションの一部 ある関数の中身で一番最初に書くべき処理は何か、それは引数のチェックをして条件を満たさなければエラーを出すことである。例えば文字列は特定の形式になってなければならないとか、数値に最大値最小値があるとか、これらは関数の入力の前提条

    エラーが出たら喜べ。エラーをちゃんと出せ。 - Qiita
  • Google、超高速に評価可能でポータブルな式言語「Common Expression Language」(CEL)発表

    Google、超高速に評価可能でポータブルな式言語「Common Expression Language」(CEL)発表 式言語とは一般に、プログラミング言語の一部やネットワークなどの構成ファイル、テンプレートファイルなどの中で、簡易な式やロジック、ポリシーなどを記述する際に使われる言語のことです。 こうした用途では、さまざまなプラットフォームに対応する移植性、起動時やプログラムの実行中に評価されることがあることから高速に評価が完了すること、安全に評価が実行できること、用途に応じて拡張しやすいこと、などが求められます。 CELは超高速に評価、ポータブル、サブセットサポート CELは正にこうした要件に対応した式言語となっており、Googleは次のような特徴があるとしています。 ナノ秒からマイクロ秒程度の高速な評価に最適化されている C++JavaGoでサポートされるスタックによるポータブ

    Google、超高速に評価可能でポータブルな式言語「Common Expression Language」(CEL)発表
  • mattn氏が実践しているエンジニアリング最適なメモ術。アウトプットを継続するための方法論

    mattn氏が実践しているエンジニアリング最適なメモ術。アウトプットを継続するための方法論 2024年6月18日 mattn 大学卒業後、ソフトウェアハウスやSIerなどでソフトウェア開発に携わる。vi派生のテキストエディタVimの日語化やプラグイン、Go言語などでOSS(オープンソースソフトウェア)の開発・コミュニティ運営に参加し、2019年からGoogle Developers Expert。2021〜2023GitHub Stars。著書に『みんなのGo言語』(2016年、2019年に改訂2版、技術評論社、共著)、『Go 言語プログラミングエッセンス』(2023年、技術評論社、単著)がある。関西在住。 X:@mattn_jp GitHub 前回はアウトプットとは何か、何のためアウトプットするのか、についてお話しました。筆者はこれまで、アウトプットのやり方で悩んでいる方々に、どう

    mattn氏が実践しているエンジニアリング最適なメモ術。アウトプットを継続するための方法論
  • Don't DRY Your Code Prematurely

    TotT 102 GTAC 61 James Whittaker 42 Misko Hevery 32 Code Health 30 Anthony Vallone 27 Patrick Copeland 23 Jobs 18 Andrew Trenk 13 C++ 11 Patrik Höglund 8 JavaScript 7 Allen Hutchison 6 George Pirocanac 6 Zhanyong Wan 6 Harry Robinson 5 Java 5 Julian Harty 5 Adam Bender 4 Alberto Savoia 4 Ben Yu 4 Erik Kuefler 4 Philip Zembrod 4 Shyam Seshadri 4 Chrome 3 Dillon Bly 3 John Thomas 3 Lesley Katzen 3 M

    Don't DRY Your Code Prematurely
  • Amber The Programming Language

    A modern, type-safe programming language that catches bugs and errors at compile time.

    Amber The Programming Language
  • Borgo Programming Language

    Borgo is a new programming language that compiles to Go. For a high-level overview of the features and instructions on running the compiler locally, check the README. This playground runs the compiler as a wasm binary and then sends the transpiled go output to the official Go playground for execution. use fmt enum NetworkState<T> { Loading, Failed(int), Success(T), } struct Response { title: strin

  • LogLog Games

    The article is also available in Chinese. Disclaimer: This post is a very long collection of thoughts and problems I've had over the years, and also addresses some of the arguments I've been repeatedly told. This post expresses my opinion the has been formed over using Rust for gamedev for many thousands of hours over many years, and multiple finished games. This isn't meant to brag or indicate su

  • Prettierを使わない理由

    この記事はPrettierを使用している人を非難したり、脱Prettierを推奨する事を目的としていません。 こういった考え方もあるということをひとつの意見としてご覧いただければ幸いです。 勘違いしている人が多そうなので追記します。 Prettierを使わないというのは私が独断で決めた事ではないです。 チームが発足する際の技術選定で合意は取れていますし、私が関与していない別のチームでも同様にPrettier無しで開発しています。 私達のチームはメンバー同士を互いに信頼していますし、細いスタイルで喧嘩を始めるようなメンバーは居ないので安心してください。 はじめに Prettierはコードフォーマッターとして広く使われているツールです。 コードスタイルに関する議論をなくすことを目的としており、ESLintとは異なりデフォルト設定のままですぐに使えるのが特徴です。 さらに、PrettierはJS

    Prettierを使わない理由
  • Grit

    Grit automatically fixes technical debt by combining static analysis and machine learning to generate pull requests that clean up code and migrate to the latest frameworks.

    Grit
  • どうしてあなたの共通化は間違っているのか:目次 - Qiita

    はじめに この連載では共通化とモジュール分割について扱います。この話題においてQiitaで有名な記事のひとつが@MinoDrivenさんの単一責任原則で無責任な多目的クラスを爆殺するでしょう。この記事を未読の方はまずこちらを読むことをお勧めします。連載では、この記事に書かれているような基礎的な事項については既知であることを前提に、どのようにすれば単一責任原則にそったモジュールの分割を行うことが出来るのかをなるべく 「場合による」という言葉に逃げずに なるべく 網羅的・理論的に 解説します。 いいね、ストックをよろしくお願いします。 対象読者 設計に興味のあるエンジニア 基礎的な設計原則について学んだものの、実際の場面でどのように応用すればいいのかが掴めないエンジニア ミクロな設計についての知識を増やしたい人 ※この記事では、特定のメソッドをどのように作成するべきか、このクラスは複数の処理

    どうしてあなたの共通化は間違っているのか:目次 - Qiita
  • 私が独学をして、マジ神だと思うサイトおよび他 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 初めに 私は独学でプログラミングその他について勉強をしていますが、基的に知識を得るために金はかけません。調べれば何とかなるので。 私がプログラミングを始めるにあたって自分に投資したものは安いノートパソコンとマウスのみで合計金額は14600円(ノートパソコン14000円、マウス600円)ですね。 もちろんいいものはお金をかけなければ手に入りません。しかし、いいものというのはある程度のレベルにならなくては持っていても意味がほとんどないと思います。 実際にプログラミングの勉強を独学で始めると、なかなか教材を見つけることができず、え?こんない

    私が独学をして、マジ神だと思うサイトおよび他 - Qiita
  • 開発者が知るべきキャッシュ設計でよく遭遇する問題

    はじめに 分散システムの設計および開発において、キャッシュはパフォーマンス向上のための非常に重要な要素です。頻繁にアクセスされるデータをキャッシュすることで、アクセス速度が遅いデータベースへのアクセスを削減し、データへの迅速なアクセスを可能にします。これにより、システムの全体的な効率とパフォーマンスが向上します。 しかし、キャッシュは慎重に設計しないとむしろパフォーマンス上のデメリットになるケースが存在します。 この記事ではよく遭遇するキャッシュ設計の問題とその回避策について解説します。 Cache penetration DBに存在しない値を検索したときに、DBから返された空の結果をキャッシュしない場合に発生するシナリオです。 このシナリオではDBに存在しない値を繰り返し検索することにより、その値がキャッシュされていないため検索ごとにDBへのアクセスが必要になってしまいます。 存在しない

    開発者が知るべきキャッシュ設計でよく遭遇する問題