プログラミングでは、1文字でも打ち間違いがあればエラーの原因になってしまいます。 そこで似たような文字、例えば数字の「1」（いち）とアルファベットの「l」（エル）、数字の「0」（ゼロ）とアルファベットの「O」（オー）などを容易に見分けられるようなフォントを使うことが、ミスを防ぐことにつながります。 コードを表示させたときに整然として見やすく、エディタ上でカーソルを上下に移動させてもカーソル位置が左右にぶれずに表示されるように文字の幅が等幅に揃っていることも必要でしょう。 日本語の場合には、「－」（マイナス記号）と「ー」（音引き）の区別や、コード内に全角空白が紛れ込んだとしてもすぐに見分けられることなどの特徴を備えていることもプログラミングに適したフォントに求められる条件だといえます。 この記事では、そうした特徴を備えたプログラミングに適したフォントをまとめました。 ここで紹介されていない日
こんにちは〜！ NE株式会社のはやしまき（@_mkmk884）です🦒 DRY（Don't Repeat Yourself）原則はコードの重複を減らし、保守性を高める効果的な手法ですが、適用の仕方によっては仕様変更に対応できなくなることがあります。 特に弊社が開発しているネクストエンジンは多くの他サービスとも連携しているため、ネクストエンジン内の仕様変更だけでなく、外部連携サービスの仕様変更もあります。 当時の仕様的にはDRY原則に沿っていたものが、時間とともに保守性を損ない、結果的にDRYではなくなり仕様変更に耐えなくなったケースについて、今回は書いていこうと思います！ DRY原則とは DRY原則（Don't repeat yourself）とは、ソフトウェアの構成や構築手法についての原則の一つで、同じ意味や機能を持つ情報を複数の場所に重複して置くことをなるべく避けるべきとする考え方です
これは YouTube Live で写経の必要性についてディスカッションするために、自分が用意した資料。 急いで書いたので色々雑。 議論が終わったら追記する、かも。 争点 プログラミングの写経に意味があるのか。ないのか。 あるとしたら、その意味は。 ないとしたら、なぜ無意味なのか。 また、少し違った視点として、とくに学校教育の現場で、モチベーションが低い対象を前提として、写経を行わせる意味などもあるかもしれない。 語らない点 個別の言語ごとの写経の向き不向き 特定ツールの良し悪し 個々のライブラリでは云々 一般化できなさそうな N=1 事例 プログラミングの写経の定義 (同意できそうなところ) 完全に思考を停止した状態で、意味を理解せずに上からタイプする作業を写経と呼んではいない。なので、仏教的な意味においての写経・読経や、ヨーロッパの修道院で行われた聖書の写本的な意味合いからは(完全に無
プログラミングの勉強方法で最も効果がない方法は「写経」です。コードを記憶しても無駄です。実際のプログラミングでは記憶にないコードを作り出さなければいけないからです 「写経」はタイピング速度の向上やキーワードを覚える効果はあるかもしれませんが、肝心のプログラミングには役に立ちません — Koichi Nakashima (@ko1nksm) September 3, 2024 こういうエントリを見かけたので。 僕は1990年代からプログラミングを人に教える仕事をしています。最初は中学の時に技術家庭科の授業を先生から任されて同級生にプログラミングを教えることから始まりました。その後、色々な方法を試しましたが、結論としてプログラミング初心者は写経した方が結局は上達が速いと今は考えています。 それが特に強く感じられたのは2015年頃から色々な人にAI関連のプログラミングを教え始めた頃です。 AI関
悉生 游漩 @StewEucen The creator of x-ninja a new JavaScript front-end framework. 「悉生 游漩」「Stew Eucen」の読み方は「しちゅう ゆうせん」です。「ゆうせん」と呼んでね。 Please call me "Eucen" :) x-ninja.org 悉生 游漩 @StewEucen プログラミングの条件式で、>= や <= の比較演算子がロジックに含まれる時。 其のロジックのテストに「値が等しいケース」を書かない人には、重要な設計を任せてはあきませぬ。 （・ω・）＜おわかりか 2024-06-27 16:54:42
2024/06/12 16:16 結論を追記 2024/06/12 20:29 より記事の内容を分かりやすく理解頂くため、タイトルを「PRDやDesign Docを書かなくなった」から変更 2024/06/13 20:39 結論にフロー情報・ストック情報に関する意見を追記 結論 この記事では、「様々な観点を考慮して網羅的にドキュメントを書いて、それを関係者にレビューしてもらう」のではなく、関係者と同期的に対話しながら、観点や選択肢やそのトレードオフを洗い出すことで、少ない手数でより良い答えが見つけられると主張する。 ただし、対話のために必要なドキュメントは事前に書いておくべきだし、対話した結果はドキュメントに残すことが望ましい。そして、そのドキュメントのフォーマットはPRDやDesign Doc以外でも良い。例えば、ADRはアーキテクチャに関する議論の過程と結果を述べる上で必要十分なフォー
いろんな現場でちょいちょい話題になるので「前にツイートしたなぁ」と見てみたらすっごい長かった。 コメントあると「対応しなければならない」ってなるの。あれが諸悪の根源だと思ってる。— irof (@irof) 2020年9月17日 諸悪の根源？ とりあえず全文転記。誤変換とかもそのまま。 コメントあると「対応しなければならない」ってなるの。あれが諸悪の根源だと思ってる。 目に見えてる問題を潰したくなるのはごく当たり前の感情だと思うけど、目に見えてるもの全て潰したからと言って完璧にはならないことは理解する必要がある。言えるのは「目に見えるものはない」というだけで……そしてコメント対応とかだと、「見た目」のメタファすら使えなくなる。 「コメント対応」のような問題の潰し方をすると必ず歪になる。これは自分の目で見つけたものなら曲がりなりにも「自分の目」の精度は高くないものの一定の見方ではあるのに対し
こんにちは！Xイノベーション本部プロダクトイノベーションセンターの米久保 剛です。 弊社のテックブログ上では今回が初めての記事執筆となります。アーキテクチャ設計やアプリケーション設計の話を中心に、不定期に情報発信していきたいと考えています。 YAGNI原則 YAGNI原則をご存知でしょうか。 エクストリーム・プログラミング（XP）の重要な原則の一つであるこの原則は、You Ain't Gonna Need Itのアクロニム（頭字語）から命名されています。日本語にすると「どうせ要らないって」というニュアンスでしょうか。推測に基づいて余計な機能を作り込んだところで将来実際に使われる可能性は低く、時間と労力を無駄にするばかりかコードの複雑化などのリスクさえあります。ですから、現時点でわかっている要件をちょうど満たすだけの機能を実装すべきであるとYAGNI原則は主張します。 YAGNI原則は機能（
Welcome to the Coding Dojo website The purpose of this website is to gather resources, sessions and stories from users around the world that the Coding Dojo website should provide to its user community. You can check the Wish List and add ideas of what a Coding Dojo global website should provides. You can join our online community on matrix. About Coding Dojos To start off, a directory of who we a
こんにちは。ＮＴＴテクノクロスの際田です。普段は社内の開発プロセス効率化、テスト自動化周りの支援に携わっています。 最近、ラムダノート株式会社の『実践プロパティベーステスト -PropErとErlang/Elixirではじめよう-』という本を読んで、プロパティベーステストという手法を知りました。 せっかく読んだしやってみよう、と思ったのですが、この本の例はErlang/Elixirという通好み(?)な言語なので、お仕事でも使えそうな言語でできないかと考えました。調べたところ、fast-checkというJavaScript/TypeScriptのライブラリがあるようなので、こちらを使ってプロパティベーステストをやってみたいと思います。 プロパティベーステストとは プロパティベーステストとは、自動テストの手法の一つで、「システムのあるべき挙動を満たす条件」をプロパティと呼び、その条件を満たすで
こんにちは、YOUTRUSTのやまでぃ（YOUTRUST/X）です。 今回は何書くの？ 下記の項目について私見を述べます。 条件式の引数の並び順 早期リターン ネストの深さ 後置if 参考. 「読みやすいコード」についてチームで議論しました 前提 私見です。 弊社においては、意見が分かれるようなスタイルについては、必ずしも統一してはいません。 題材として、リーダブルコードを参考にしています。 重要なそもそも話ですが、細かいコーディングスタイルについてあれこれ気にするよりも、ちゃんと責務に応じて適切にクラスやメソッドのサイズをコンパクトに収めることを考えることの方が優先度高いと思っています。 コードがコンパクトになっているのであれば、どんなスタイルで書かれていても大した負荷なく読むことができます。 「細かいコーディングルール」 < 「クラスやメソッドのサイズ」 です。 （クラスの責務分割に関
Updated Mon Feb 5 10:22:02 EST 2024 Available in paperback and e-book formats. Order at Amazon and other fine booksellers. Introduction This page holds material related to the second edition of The AWK Programming Language. The first edition was written by Al Aho, Brian Kernighan and Peter Weinberger in 1988. Awk has evolved since then, there are multiple implementations, and of course the computi
M 年前にも N 年後にも人類は同じ話をしている. まとめ エラーの発生方法は throw と return に大別できる throw には簡潔さ, return には明瞭さと型安全性といった特徴がある どちらの方法がより適しているかはプログラムの規模, エラーの種類, ハンドリングの方法などが判断の材料になる 実際にどちらの方法を使うかは上の判断材料と, フレームワークやプロジェクトのコーディング規約なども合わせて複合的に決めるのがよい エラー発生方法の分類 まず前提として, 関数から呼び出し元にエラーを伝える方法は以下の 2 つに大別できます. 逆にこの記事ではこれ以上の具体的な方法についての議論はしません. throw エラーを throw して呼び出し元に伝える方法です. 例えば以下のようなものが当てはまります. throw new Error("...") Promise.rej
こんにちは。MIXI 開発本部 SREグループの riddle です。 自分の所属するプロダクトでは、ビルドツールとして Bazel を利用していたのですが、いろいろあって make に変えたので「Bazel をなぜ導入してなぜやめたのか？」 を紹介します。 ＜目次＞ Bazel とはどこに Bazel を使ってたのか？なぜ Bazel をやめたのか？ 3-1. Bazel の運用コストが高かった 3-2. Bazel の速度問題 3-3. Bazel ではできないことがあるmake に移動したわけまとめBazel とは Bazel は Google が開発したビルドツールで、Java、C++、Go、Android、iOS、その他多くの言語とプラットフォームを使用してビルドとテストができます。 ローカルやリモートのキャッシュをうまく用い、アプリケーションのビルドやコンテナイメージの生成、テ
テキストエディタのデータ構造 Gap method Piece Table method Piece Table の構造 Piece Table の実装 Piece Table のメソッド まとめ テキストエディタのデータ構造 テキストエディタで採用されているデータ構造にはいろいろあります。 こちらの論文 Data Structures for Text Sequences では各種データ構造について比較検討されています。 多くは、Gap method や Piece table method をベースにしたものが多いのではないでしょうか(図で言う最下部の中心の丸印に当たります)。最近では Rope なども有名ですね。 Gap method Gap method では、現在のカーソル位置で、テキストバッファを2つに分割し Gap を間に挟み、カーソル位置に対する編集(テキスト追加/削除)を
注意: 最新版のドキュメントをご覧ください。この第1版ドキュメントは古くなっており、最新情報が反映されていません。リンク先のドキュメントが現在の Rust の最新のドキュメントです。 プログラミング言語Rust ようこそ!この本はプログラミング言語Rustの教材です。Rustは安全性、速度、並行性の3つのゴールにフォーカスしたシステムプログラミング言語です。 ガーベジコレクタなしにこれらのゴールを実現していて、他の言語への埋め込み、要求された空間や時間内での動作、 デバイスドライバやオペレーティングシステムのような低レベルなコードなど他の言語が苦手とする多数のユースケースを得意とします。 全てのデータ競合を排除しつつも実行時オーバーヘッドのないコンパイル時の安全性検査を多数持ち、これらの領域をターゲットに置く既存の言語を改善します。 Rustは高級言語のような抽象化も含めた「ゼロコスト抽象
WHAT'S NEW 2024/10/25 簡単なベンチマークを改訂 2024/08/31 Scheme Junk Scripts を削除 2024/08/30 Yet Another Scheme Problems のスタイルシート (CSS) を変更 2024/08/22-29 お気楽 Scheme プログラミング入門のスタイルシート (CSS) を変更 CONTENTS お気楽 Scheme プログラミング入門 入門編 応用編 思考ルーチン編 パズルの解法 micro Scheme 編 言語処理系編 オブジェクト指向編 Yet Another Scheme Problems 参考文献と URL 権利・免責事項など お気楽 Scheme プログラミング入門と Yet Another Scheme Problems のフォントを Web フォント (Noto Sans JP, Noto
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く