Wikipedia:Reliable sources/Perennial sources - Wikipedia
It is not one of Wikipedia's policies or guidelines; rather, its purpose is to explain certain aspects of Wikipedia:Reliable sources guideline. It may reflect differing levels of consensus and vetting. This page in a nutshell: This is a list of repeatedly discussed sources, collected and summarized for convenience. Consensus can change, and context matters tremendously when determining how to use
NVIDIAがGPUのLinux向けカーネルモジュールをオープンソース化、すでにダウンロード可能に
by Jonathan Cutrer NVIDIAがGPUのLinux向けカーネルモジュールをオープンソース化しました。ソースコードはGPLライセンスとMITライセンスのデュアルライセンスで公開されており、記事作成時点ですでにダウンロード可能となっています。 NVIDIA Releases Open-Source GPU Kernel Modules | NVIDIA Technical Blog https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/ これまで、NVIDIAがGPU関連ソフトウェアのオープンソース化に積極的でないことは広く知られており、2012年にはLinuxの生みの親であるリーナス・トーバルズ氏がLinux対応を怠るNVIDIAに対して中指を突き立てる事件が発生し
ソフトウェアドキュメント作法 - maru source
こんにちは丸山@h13i32maruです。つい先日、devchat.fmというポッドキャストに出演して、「ドキュメント」というお題について話しました。なぜこんなニッチなお題について話したかというと、Ubie Discoveryに入社して5ヶ月の間にいくつか*1まとまったソフトウェアドキュメントを書いたので、自分の中でホットな話題だったからです。 #devchatfm 33回目は、Ubie DiscoveryのSWE @h13i32maru にドキュメントを書くことで得られるメリットや、ポイント・工夫などを聞きました！ #33 チームの生産性を上げるドキュメントのすすめ with@h13i32maruhttps://t.co/TrmZd13D91— 久保 恒太 / Ubie CEO (@quvo_ubie) 2021年8月12日 これらのドキュメントは個人的にわりと良く書けたと思ってますし、
Gitリポジトリ上のソースコードをWebブラウザから検索・分析できるコード検索ツール「Sourcegraph」 | さくらのナレッジ
大規模なソースコードを分析・閲覧する際に有用なのが、ソースコード専用の検索ツールだ。こういったツールは複数あるが、今回はGitリポジトリやGitHubなどのホスティングサービスとの連係機能を特徴とするオープンソースの検索ツール「Sourcegraph」を紹介する。 Webブラウザ上からGUIで操作できるソースコード検索ツール システム開発の現場において、クラスや関数がどこでどのように定義されているのかを調べたり、メッセージなどで表示される特定の文字列がどこで使われているかを調べたりするといった作業は割と頻繁に発生する。こういった作業はgrepなどの汎用検索ツールでも可能ではあるが、その場合たとえばソースコード以外のファイルに含まれる文字列も検索に引っかかるほか、その出力もやや見にくい。そこで活用したいのが、専用のソースコード検索ツールだ。 ソースコード検索ツールでは、対象のソースコードがど
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
MS、1983年に開発のBASICインタプリタをOSS化
Microsoftは米国時間2020年5月21日、IBM Advanced BASICを元にMicrosoftが1983年に開発したBASICインタプリタ「GW-BASIC」をオープンソースとしてGitHubで公開した。歴史的な資料提供を目的とし、生成に必要なビルドスクリプトやMakefileをはじめとするとツール群、ビルド済みのバイナリは含んでいない。 アセンブラコードやヘッダファイルなどが並ぶ 1975年にMicrosoftはAltair 8800用にBASICを移植し、そこから1980年初頭にかけて多くのコンピューターへBASICを移植してきた。公式ブログでは、「(当時の)家庭用コンピューターやパーソナルコンピューターで使用されていた初期プロセッサーのISA(命令セットアーキテクチャー)は、目を見張るような違いがなかった。Microsoftはマスターコードから多くの移植が可能だった」
【GitHub】ソースコード検索したい。 - Qiita
はじめに WebAPIなどの実装時、他の人がどのように実装しているか気になりませんか？ ただ、書き方のお手本にしたいなぁと思っても、私が出来るのはGitHub左上の検索フィールドで足掻くぐらい。笑（↓） もそっと効率上がらないかな…と言うことで検索方法について調べてみました。 ※因みに、このQiita見るより↓ら辺のGitHubヘルプ見る方が手っ取り早い説あります(笑) ・GitHub での検索について ・検索構文を理解する ・コードの検索 ソースコードの検索 目標はWebAPIなどで提供されている機能の実装サンプルを探してみようーです。 このQiitaではGUI検索とprefixを使って、ソースコードを検索します。 お題：「recaptcha」と言うWebAPIの「verify_recaptcha」機能を使っているRubyファイルを探す！ GUIによる検索 とりあえず初心者なのでGitH
なぜ読みやすいコードが必要なのか - コードの可読性を高める手法をサンプルで学ぶ - エンジニアHub｜Webエンジニアのキャリアを考える！
なぜ読みやすいコードが必要なのか - コードの可読性を高める手法をサンプルで学ぶ システム開発会社「アクシア」の代表として、自社・他社含め、さまざまなエンジニアのコードを読んできた米村歩さん。そんな米村さんの持論は、「コードの可読性は生産性に多大な影響を与える」ということ。可読性の低いコードはどんな弊害をもたらし、どうすれば改善できるのか――。チーム開発を効率化するコードの「可読性」について綴っていただきました。 プロフェッショナルのエンジニアには、「可読性」の高いコードを書くスキルは必要不可欠です。単に目的とする処理が実行できればよいわけではありません。しかし実際の開発業務の中では、可読性は意外と軽視されてしまいがちです。 経験の浅い駆け出しのエンジニアにとっては、可読性の重要さを肌感覚で理解するのは難しいかもしれません。また、新人エンジニアに対してプログラミング言語や開発ツールについて
Death By a Thousand Commits
On the 1st commit, things are getting started. On the 10th commit, the feature is live and users are giving feedback. On the 100th commit, users are delighted to be using the application. But on the 1000th commit, users are unhappy with the responsiveness of the application and the developers are struggling to move at the velocity they once were. Does this sound familiar? We will go over some of t
ドメイン駆動設計サンプルコードの徹底解説
Java/Spring Boot/MyBatis/Thymeleafを使った、ドメイン駆動設計のサンプルコード。ビジネスルールに焦点を合わせ、計算モデルで複雑さを整理し、型指向のプログラミングで実装する、その具体例。Read less
動くようにする、正しくする、速くする。 - Qiita
今までに扱ったことの無い分野で新規開発をする場合、いろんな問題が出てくるだろう。そのようなときに、何をどうすればよいのか迷うことがあるだろう。そのようなときに、複数の課題があるときに、何をどの順序で解決していけばよいのか迷うこともあるだろう。 私が心がけているのは、「動くようにする、正しくする、速くする。」の順序で物事の優先順位をもって考えてようにしていることです。この内容は何かの本で読んだことからきている。何かしら動かないうちは、正しくすることもできないし、正しくなっていないうちは、速くすることに意味がない。 物事を解決する際に、全てのことが同時に解決することは少ない。 前に経験を積んだことのある分野の近くでは、動いて正解率もそれなりに高くて、メモリ消費や処理時間が少ないもの１回目の挑戦で作れることがあったりもするが、それは極めてまれなことだ。 1. 何かしら既存の技術をまねて、「動くよ
misspell - ソースコード専門のスペルミスチェッカー
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました 英語圏に住む人であっても英語のスペルミスをします。むしろ日本人が日本語で文章を書くように、普段ずっと英文を書く中ではスペルミスがたくさんあるでしょう。コードの中でもそんな発見は良く目にするのではないでしょうか。 今回は特にソースコードに特化したスペルミス発見器、misspellを紹介します。 misspellの使い方 misspellはコマンドラインで使えます。ファイルまたはディレクトリを指定するだけです。 $ misspell Blog/ 8.md:19:68: "currenty" is a misspelling of "currently" 2.md:217:34: "unneccesary" is a misspelling of "unnecessary" この手の多く
見えないRの関数のソースコードを読む - cucumber flesh
要約 lookupパッケージで標準の関数定義ソースコードの出力機能を改善する 総称関数や.C(), .Internal()などの関数で呼び出されるコードも出力 prettycodeパッケージで関数定義のハイライトを有効にする prettycodeはRの起動時に読み込み、lookupは適宜、名前空間を指定してlookup::lookup()で実行、という運用にした ソースコードの閲覧機能の向上とハイライト機能 最近ちょくちょく、Rのソースコードの読み方が変わっていくんではないかなと思っています。読み方というか出力方法というか。 百聞は一見に如かず。次の画像をご覧ください。この画像には通常のRでのソースコード出力と異なる点が2箇所あります。 この画像はターミナル上で起動したRで、head()のソースコードを表示している場面です。何かお気づきになられるでしょうか。手元にRを実行できる環境がある方
Linuxカーネルソースコードを読むツール (2)：Eclipse編 - Fixstars Tech Blog /proc/cpuinfo
このブログは、株式会社フィックスターズのエンジニアが、あらゆるテーマについて自由に書いているブログです。 前回はcscope編でしたが、今回はEclipse編をお届けします。普段 cscope+ctags で困っているわけではありませんが、IDEを便利そうに使っているを見て、Linuxカーネルのプログラミングにも便利なのかなぁ、でも使ったことがないからどうすれば良いのかわからない、という方もきっといるのではと思います。というか、自分がそうでした。ということで、IDEにもいろいろありますが、ここではEclipseを取り上げます。理由は、ちゃんとした方法の解説があるからです 🙂 LinuxカーネルのソースコードをEclipseのプロジェクトに導入する方法はこちらです。 https://wiki.eclipse.org/HowTo_use_the_CDT_to_navigate_Linux_k
「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話（補足編） - 土屋つかさの技術ブログは今か無しか
前回書いた「「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話（ http://d.hatena.ne.jp/t_tutiya/20170519/1495197904 ）」は土屋のブログ記事にしては珍しくはてブやコメント、twitterで反響を幾つか頂きました。その中の幾つかを紹介します。分かっているとは思うけど、サンプルコードはJavaScriptを意識してますがてきとーです。 案１：マジックナンバーを定数化する MAX_OPAQUE = 1.0f //定数宣言のつもり if (alpha < MAX_OPAQUE){ //処理Ａ } "1.0f"に意図を設定すればコメントが不要なのではないか説。うーん、これはちょっと難しいかな……。"MAX_OPAQUE"が正しい変数名だとは思えませんが、どんな名前にすれば意図が説明できるのかちょっと思いつきません。また、数式が複雑
「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話 - 土屋つかさの技術ブログは今か無しか
土屋はプログラマの中でもかなりコメントが多いタイプだと思っています。理想を言えばコード１行ごとにコメントを書きたいくらいです（本当は、識別子を全部日本語で書きたいと思っているのですが、これはまた別の話）。 これは土屋がPDL（Program Design Language https://www.gamedev.net/resources/_/technical/general-progra... ）開発スタイルの薫陶を受けているからなのですが、それとは別に「そもそも日本人には英語ベースのソースコードを高速に読解するのは無理がある」と考えているからです。 また、より本質的な課題があると思っていて、プログラミング業界的には「コードがドキュメントであるべき（≒正しく実装されたコードであれば、コメントは最低限になる）」という風潮がありますが、土屋は、これはプログラマが夢見る幻想に過ぎず、「本質的
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Sourcegraph
GitHub - jgraph/drawio: draw.io is a JavaScript, client-side editor for general diagramming.
git grep を使う - Fixstars Tech Blog /proc/cpuinfo
GitHub - FujitsuLaboratories/COMEVIZZ: COMEVIZZ is COde MEtrics VIsualiZation with Z-Score.
