Connascence：コードの結合度を測るもうひとつの指標 - snoozer05's blog
構造は、凝集度が高く、結合度が低い場合に安定する - Larry Constantine 私たちプログラマーは、その仕事において、できる限り良いコードを書きたいと考えます。しかし、「良いコードとは何か」という問いに対して答えるのは、そう簡単ではありません。「良さ」を測るには、「何に対して」という軸が必要であり、その軸は一つではなく、さらには、コードを書いている状況に応じて、大事にすべき軸が変わるということも往々にしてあるからです。そうしたとき、私たちは何らかの尺度でもってコードを測って、そのときのコンテキストにおいて良い落とし所を定めます。 そのようなときに、コードの品質を測る軸としては、有名なものには「凝集性（Cohesion）」と「結合度（Coupling）」があります。ここでは、そのうちの「結合度」を測る指標の一つとして「コナーセンス（Connascence）」を紹介します。 コード
Google Style Guides
Google Style Guides Every major open-source project has its own style guide: a set of conventions (sometimes arbitrary) about how to write code for that project. It is much easier to understand a large codebase when all the code in it is in a consistent style. “Style” covers a lot of ground, from “use camelCase for variable names” to “never use global variables” to “never use exceptions.” This pro
コーディング面接対策のために解きたいLeetCode 60問
自分がコーディング面接対策のために解いてよかった LeetCode の問題をコンセプトごとにまとめました。カバーするコンセプトは LinkedList Stack Heap, PriorityQueue HashMap Graph, BFS, DFS Tree, BT, BST Sort Dynamic Programming Binary search Recursion Sliding window Greedy + Backtracking です。 これらの問題が 30 分以内に実装できれば面接の準備は整ったと言っていいと思います。Easy と Medium で問題は構成されてます。進捗を管理するためにGoogle Spreadsheetを用意しました。コピペしてご自由にお使いください。 これらの問題は、LeetCode のリスト機能でも公開されています。クローンすれば自分がすでにど
LKML: Linus Torvalds: Re: clean up kernel_{read,write} & friends v2
On Fri, May 29, 2020 at 6:08 AM David Laight <David.Laight@aculab.com> wrote: > > A wide monitor is for looking at lots of files. Not necessarily. Excessive line breaks are BAD. They cause real and every-day problems. They cause problems for things like "grep" both in the patterns and in the output, since grep (and a lot of other very basic unix utilities) is fundamentally line-based. So the fact
未来のプログラミングについて再考（機械学習とソフトウェア2.0、配管工プログラマ、オープンソースでは十分でない？） - YAMDAS現更新履歴
昨年のエントリだが、その後現在までマイク・ルキダス（Mike Loukides、O'Reilly Media のコンテンツ戦略担当副社長）の文章を追って、これを書いていた当時ワタシが理解していなかった文脈、そしてそれに対応するニュースや問題意識が見えてきたところもあるのでつらつらと書いておきたい。 こちらは2019年末に、マイク・ルキダスが O'Reilly Media のチーフ・データサイエンティストである Ben Lorica と共に書いたエントリだが、2020年3月に開催される O'Reilly Strata Data & AI Conference に向けた露払いである。 ワタシはタイトルだけ見て、「ソフトウェア2.0？ 今さら〇〇2.0は古いだろー」と思ったのだが、これは Tesla で AI 部門長を務める機械学習の専門家 Andrej Karpathy が2017年11月に公
プログラミングにおける不安と学びのプロセス - 人間とウェブの未来
僕の場合、実現したいことをコードで書けない時には、ひたすら似たコードを読んで理解して写して…を繰り返す。そのうちに手元に大量の自分のサンプルが溜まっていく。その繰り返しがパターンの細分化を促し、書けるコードの幅を広げていく。書けるコードを気持ちよく書き続けてるだけでは新しいコードは書けないからだ....と、向き合えるようになるには時間がかかった。 書き慣れたコードの延長で書いていると、自分でコードを書けている実感があって、リファレンスなど何も見ずに自分の力でプログラミングできている感があるのだが、ある時これはただ「慣れ」の感覚を高めているように思えた。素早く書けること自体は、それはそれで一種のスキルで素晴らしいのだけど、実現したいことをコードで書けるようになる、という観点で振り返ったときに、どうしても成長を感じなかったのだ。それ以来、まずいと思い、実現したいことを思い描き、それを実現するた
SIerの下請け開発者ってレベル低すぎない？ - UXエンジニアになりたい人のブログ
ネット上ではSIer批判＝技術のことをわかっておらずプログラムも書けずPMも出来ない非効率でダメダメな上流工程と、 人月単位での労働力提供という業界の慣習に縛られ、持ち前の優秀な技術力・知識を生かせず非効率な作業を強いられているかわいそうな下請け開発者、という構図が確立されているように思います。 自分が関わるまでは、まあそうなんだろうなと思っていましたが、しかし実際にそういう立場のひとと関わりをもつにつれて、どうもそうではないのではないかと思うようになりました。このあたりの実情を書いていこうと思います。 なお、先に言っておきますが本記事で書くことは、上流工程がどうのとか、業界の多重請け負い構造がどうのとか、給料が安くてとか労働条件が過酷でとか、そういう話とは全く関係がなく、純粋にプログラミングのスキルの話だけです。 対象はおもに詳細設計、実装UTだと思ってもらえれば。外部仕様が決まった状態
プログラマ向けノートアプリQuiverが素晴らしい(Mac用アプリ) – namaraii.com
プログラマ向けノートアプリQuiverが素晴らしい(Mac用アプリ)Markdownをサポートしたメモアプリは数多くありますが、技術系のメモやスニペットを書き溜めるのに適したものはそれほど多くありません。 個人的な要件としては、 データフォーマットがオープンで好みのクラウドサービスで同期できることMarkdown(GFM)を扱えてプレビューできることコードの取り扱いが簡単なこと(できればシンタクスハイライトも)ファイルを意識しないで使えること(ファイル名を考えたりしなくて良い。オートセーブされる)ノートブック、タグなどでノートを整理・分類できることぐらいなのですが、すべてを満たしたアプリをなかなか見つけられず、Day OneやUlysses、Kobitoなどを併用して凌いでいましたが、最近、知ったQuiverというアプリがこれらの要件をすべて満たしており、これに一本化することに。 あまりに
Programming Idioms
Show me an idiom Looking for something? Search 300+ idioms
GitHub - hatena/Hatena-Textbook: はてな研修用教科書
Hatena-Textbook はてな教科書は、はてなのエンジニアとして最低限必要とされる技術を身につけるための教科書です。 Web開発における重要なトピックを順番に学びながら、課題をといていくことで、Webアプリケーションをひととおり構築できるようになります。 実装言語としてPerlとScalaのどちらを選ぶことができます。 トピックごとに学びたい言語の方の教科書を読み進めてください。 目次 プログラミングの基礎 Perlによるプログラミングの基礎 Scalaによるプログラミングの基礎 データベースの基礎 Perlによるデータベースプログラミング Scalaによるデータベースプログラミング Web開発の基礎 PerlによるWebアプリケーション開発 ScalaによるWebアプリケーション開発 Webフロントエンド開発 はてな教科書JavaScript編 hatena/Hatena-Tex
LLVMによるプログラミング言語の実装 – 日曜研究室
最近の投稿 問題: 積み木を10個積み上げるのにかかる時間は 2020/8/20 木曜日 Google の G Suit Team から “[Action Required] Remove internal links to the G Suite Domain Contact page for your organization” ていうメールが来た 2020/8/14 金曜日 NZXT H1 と ROG STRIX B550-I GAMING で組んでみた 2020/7/17 金曜日 花粉症対策2019 2019/3/16 土曜日 マルチディスプレイ時のDisplayPort問題を何とかしてみた 2019/1/12 土曜日 REALFORCEソフトウェアがインストールできない(解決済) 2018/12/6 木曜日 GeForce RTX 2080 Founders Edition を買
コードの可読性、ハッカビリティ、抽象化 | POSTD
def deploy(ip): copy('code/', ip + ':~/code', recursive=True) write_template('conf/config.py', ip + ':~/config.py') write_template('conf/crontab', ip + ':~/.crontab') write_template('conf/crontab', ip + ':/etc/apache2/httpd.conf') run_as_root('service cron restart') run_as_root('service apache restart') post('https://pingdom.com/api/2.0/checks', { 'name':ip, 'host':ip, 'type':'ping' }) タスクを実行するものと
コードを書くことは無限の可能性を捨てて一つのやり方を選ぶということ
なにかの機能を実現するためにコードを書いているというのに、そこから脱線して意味不明なコードを書く人たちがいる。汎用性は高いつもりらしいけど無意味に難しいものを作りたがったり、必要がないのに「念のため」に既存の機能を残したがったりする人たちがいる。どうやら柔軟性あるいは汎用性が至上の価値であって、その価値に反するものはなんであれよくないものだと思っている人たちがいるようだ。 そういう考え方は間違っていると思う。 ある機能を実現するにはいろいろな方法がある。プログラマはそのうち一つの方法を選んでそれを実装しなければいけない。機能を実装する前は無限の可能性がありえたが、機能を実装したあとは具体的に実装したこと以外のことはできない。芸術家が大きな大理石のブロックから一つの彫刻を削りだすように、具体化することによってそれ以外のありえた形というのがなくなってしまうが、それは避けられないことだ。全部の可
ソフトウェアエンジニアを目指す人へのコードに関するアドバイス | POSTD
この短い記事で私は、ある素晴らしいアイデアを提案します。それは、製品品質のコードは、下記リストに挙げた特性で説明することができるということです。それぞれ、重要性の高いものから順番に記述しています。もしあなたが、学校もしくは独学でプログラミングを学ぶ、真面目な学生なのであれば、製品品質のシステムを構成するコードの特性を学びたいと思うのではないでしょうか。 是非、 ご意見・ご感想 をお寄せください。 読みやすさ 言うまでもなく、読みやすいコードである。 読みやすいコードは、必要に応じて簡単に変更できる。 読みやすいコードは、他の人も理解することができ、共有することができる。
すべてのソースコードが手元にあるのに不要な抽象化を行うのはよくない
「よい」とされているプログラミング手法のひとつに差分プログラミングがある。クラスを継承して親クラスとの差分だけのコードを書けば、親ですでに実装されている機能はそのまま使えて、かつカスタマイズもできるというやつだ。 たとえばGUIのボタンをカスタマイズしてマウスオーバーするとなにかちょっと特殊なことを行うボタンを作りたいとしたら、ボタンクラスを継承して、マウスオーバーのイベントハンドラをちょいちょいとカスタマイズしてやればよい。差分プログラミングは大変素直でよいプログラミング手法のような感じがする。 よいのはよいと思う。 しかしこういういい例だけをみてそれをどこでも真似しようと思ってしまうと、不必要な抽象化を積み重ねる困ったプログラマになってしまう（そういう人は結構たくさんいる）。自分でプログラムを書く場合には、よくできたクラスライブラリやフレームワークをお手本にして抽象化を行うのは、ほとん
企業プログラミング言語が新たな囲い込みツールに | readwrite.jp
テック系巨大ベンダーが掲げる最新の看板とは、プログラム言語だ。それはまた、効果的な囲い込み戦略とも言える。 スコット・ローゼンバーグが書いているように「戦争では、勝者が歴史の本を書く。テクノロジーの世界では、勝ち組企業はプログラミング言語を書く」のだ。従って今日、マイクロソフトにC#があったように、Hack（フェイスブック）、Go（グーグル）そしてObjective-C/Swift（アップル）が存在する。 これらの言語は、それぞれ異なるアプリケーションを書くのに適した、単なる異なる言語と言うわけではない。いわば巨大ベンダーにとって、デベロッパーを壁で囲まれた庭に閉じ込めておく戦略となっているのだ。これは我々にとって危惧すべきことなのか？ オープン、でもプロプライエタリ？そうかもしれないし、そうでないかもしれない。所詮言語による囲い込みは、ある程度デベロッパーを拘束することはできるけれど、じ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。 – ゆびてく
クソコードの測り方
Programming language markets | Dave Cheney
DevDocs
