Gitを用いた開発作業を行う際、意図がわからないメッセージのコミットを積み重ねていくと、コミットログを見る人の負担が増えたり、コミットログを活用する習慣がなくなっていき、開発効率の低下を招きます。この...
いいコミットメッセージの共通点と書き方〜便利なテンプレートやチーム開発時のお作法まで詳しく解説〜 | PrAhaENGINEERLAB
Gitを用いた開発作業を行う際、意図がわからないメッセージのコミットを積み重ねていくと、コミットログを見る人の負担が増えたり、コミットログを活用する習慣がなくなっていき、開発効率の低下を招きます。この...
Makefile の関数一覧
Makefile の組み込み関数の一覧です。 公式のドキュメントを読みながら、関数の引数と使い方について備忘録としてまとめました。 Makefile での関数の書き方は $(関数名 引数,...) または ${関数名 引数,...} です。 文字列操作・検索の関数 subst 文字列の置換です。使い方は $(subst 置換前,置換後,対象) FILES := hoge.c hoge.h fuga.c fuga.h all: @echo $(subst hoge,piyo,$(FILES)) # => piyo.c piyo.h fuga.c fuga.h patsubst パターンマッチによる文字列の置換です。使い方は $(patsubst 置換前,置換後,対象) FILES := hoge.c hoge.h fuga.c fuga.h all: @echo $(patsubst %.c
システム開発の王道を極める
| トップ扉 | 思考支援 . ネット革 . ＵＩ考房 . 設計技術 . シス開発 . 道具活用 | 自己紹介 | | 最近更新 | 思考方法 . 議論手法 . 説明技術 . 知能教育 . □□□□ . □□□□ | 著作更新 | | 総合目次 | 社会進歩 . 市民運動 . ジャナ革 . 未来社会 . 一流仕事 . 組織構築 | 独り言？ | | 補助索引 | 心の階段 . □□□□ . 芸術奥覗 . 残り物達 . リンク集 . 脳ぐちゃ | 推奨用語 | ソフトウェアを中心としたシステム開発では、規模が大きくて複雑なほど、いろいろな技術が必要となる。高度な設計技術はもちろん、分析技術や管理技術などもだ。これらの技術を活用できれば、難易度の高い開発でも成功の可能性が高まる。本格的なシステム開発に役立つ技術を、活用ノウハウも含めて紹介する。 ・システム開発には様々な技術が必要 ・力ずくから
PAGNIs: Probably Are Gonna Need Its
1st July 2021 Luke Page has a great post up with his list of YAGNI exceptions. YAGNI—You Ain’t Gonna Need It—is a rule that says you shouldn’t add a feature just because it might be useful in the future—only write code when it solves a direct problem. When should you over-ride YAGNI? When the cost of adding something later is so dramatically expensive compared with the cost of adding it early on t
アプリケーションをドメインモデルで設計する - Qiita
親記事 : https://qiita.com/Regpon/items/1116679adadd8fb76f3f ドメインモデルで設計する狙い オブジェクト指向プログラミングにおいてかなり重要な内容となっているが如何せん概念的な内容となっている。ドメインモデルを設計するには幾度とない失敗の経験を重ねていき、常に改良していく精神が重要。そのための指針となる内容なので是非とも押さえておきたい。 それを踏まえてドメインモデルで設計する狙いは以下の通り。 業務的な判断・加工・計算のロジックを重複なく一元的に記述できる 業務の関心事(データ)とコードを直接対応させ、どこに何が書いてあるのかわかりやすく整理する 業務のルールの変更や追加の時に、変更の影響を狭い範囲に閉じ込める ドメインモデルの設計の難しさ ドメインモデルの設計は手続き型(スクリプト型)のプログラミングと比べて設計がむずかしいとされる
ソフトウェア設計についての原則や法則についてまとめてみた
ソフトウェア設計について、YAGNIやSOLIDなど多くの原則・法則があることが知られていますが、その解釈にはぶれが存在することが多いです。そこで、特に有名なものあるいは有用と感じることが多いものをいくつかピックアップして、その解釈やトレードオフについてまとめてみました。 注意としては、SOLIDが入ってることからわかる通り、主にOOPに関する文脈になります。また、各原則の定義については概ね知っている前提で書いているのであまり初学者向けの記事ではないかもしれませんのでご承知おきください。 YAGNI（You ain't gonna need it.） YAGNIは、予測による実装が実際に役立つことは少ないという経験則から生まれた原則です。 一般にオーバーエンジニアリングが利益をもたらすケースは限定的で、どちらかというとプロジェクトに害を与えることが多いとされています。YAGNIは日々状況の
単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場
単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や
開発者の仕事を増やさずにバグを減らす、かしこいテスト戦略とは？【デブサミ2021】
ロジギアジャパン CEO 高橋寿一氏 上流品質を担保するために必要な3つのこと 高橋氏は、講演の冒頭で次の図を紹介した。 「これは、ケイパー・ジョーズという有名な学者さんの図です。データ自体はちょっと古いけど、開発プロセスのカオスな状態を示すのにいいと思っています。皆さんが、よくご存じの通り、開発プロセスの各段階で発生したバグは、その段階のうちに始末する必要があります。でも残念ながら、どこの組織でも、要求仕様のバグが最後のテストフェーズで見つかります。最悪の場合、保守フェーズつまり市場で見つかって、カオスな状態になってしまいます」 各段階のバグは、その段階のうちに始末する必要があるが、要求仕様のバグが最後のテストフェーズで見つかってしまう そして、上流で品質を担保する重要性をいくつかの例を挙げて力説した。たとえば、上流テストを十分におこなってバグを検出したグループと、上流で十分にバグを検出
リモート新人教育で起きた“違和感” ソフトウェアエンジニアが語るベアメタルの“癒着”ストーリー | ログミーBusiness
NTT Tech Conferenceは、NTTグループのエンジニアたちが一堂に会し、NTTグループ内外のエンジニアたちと技術交流を行うためのカンファレンスです。ここで、NTT Ltd Japanのソフトウェアエンジニアの花川氏が「この素晴らしい新入社員とペアプロを！」というタイトルで登壇。まずは新入社員のメンターとして入社半年で実践したこと、違和感について語ります。 自己紹介と業務内容花川直己氏（以下、花川氏）：「この素晴らしい新入社員とペアプロを！」というタイトルで、NTT Ltd Japanの花川直己が発表します。よろしくお願いします。まず簡単に自己紹介ですが、naosukeとよく呼ばれている者です。NTT Ltd Japanでソフトウェアエンジニアとして働いて、3年目になります。 ふだんはEnterprise Cloud 2.0（ECL2.0）というクラウドサービスのベアメタルサー
運用に耐えられるコードを書くために - Magnolia Tech
オブジェクト指向とか、DDDとか言う前に、「落ちる時は速やかに落ちる」「原因がきちんと解析できる情報を出す」「リトライポイントが用意されている」「最終的な結果の正当性、整合性を確認する方法が用意されている」っていうコードをですね.... https://t.co/I5bIfhZYN8— magnoliak🍧 (@magnolia_k_) 2021年5月3日 異常系への対処がちゃんとできているコードが書けるようになってこそ一人前、みたいな、そんな価値観— magnoliak🍧 (@magnolia_k_) 2021年5月3日 いや、その手前の「つべこべ言わず、エラーが起きる可能性があるところは全てエラーコードをチェックする」なんだよ https://t.co/zmJBWR0ybX— magnoliak🍧 (@magnolia_k_) 2021年5月3日
The End of AMP
I am hopeful that 2021 will be the beginning of the end for two of my least favorite things – the pandemic and Accelerated Mobile Pages (AMP). For the past few months, I’ve been focusing on Google’s Page Experience update due to launch in May and what it means for publishers. The largest and most talked-about item in the update is Google announcing that sites with passing core web vitals will rece
Chrome Devtoolのmonitorを使うと関数の呼び出しを観察できて便利 - ぱすたけ日記
を読んで思い出したのでご紹介です。 元の記事と同様に以下の関数 sum について、 function sum(nums, acc = 0) { console.log({ nums, acc }); if (nums.length === 0) return 0; if (nums.length === 1) return nums[0]; return sum(nums.slice(1), acc + nums[0]); } この関数sumの引数 (nums と acc) の呼び出しごとの変化を見たい場合は、所謂プリントデバッグや debugger を使うのは一般的なテクニックとしてよく知られていますが、このような関数呼び出し時の引数を知りたい場合はmonitor(function)という関数を使うことで同様の効果を得ることが出来ます。 この場合は monitor(sum)とした後に、関
必要だと気付いてもいなかったフロントエンド用リポジトリ7選 - Qiita
より良いものをより早く作るのに役立つ、あまり知られていないリポジトリ。 Photo by Juan Rumimpunu on Unsplash はじめに 私たちは、汎用ツールやリソースが数回タップするだけで手に入る時代に生きています。しかも幸いなことに、そのほとんどが無料です。 新しいツールやより簡単な方法が見つかり、面倒で複雑なタスクを実行できれば、誰にとっても、特に開発者には嬉しいことです。 でも、より良く賢い方法があり、予想外の方法で時間を節約できることを知らない場合もあります。 この2年間で見つけたGitHubの素晴らしいリソースは、私をかなり助けてくれました。これらのうちいくつかは、その必要性さえ知りませんでした。 そこで、あなたもおそらく必要になるGitHubリポジトリのリストを作りました。 1. 33 JS concepts ソース 私はプログラミングをJavaで始め、その後
How to make an awesome Python package
If you are like me, every once in a while you write a useful python utility and want to share it with your colleagues. The best way to do this is to make a package: it easy to install and saves from copy-pasting. If you are like me, you might be thinking that creating packages is a real headache. Well, that's not the case anymore. And I am going to prove it with this step-by-step guide. Just three
ピーターソンのアルゴリズム - Wikipedia
/* * ANSI C89 source, KNF style implementation of Peterson's Algorithm. * * Copyright (c) 2005, Matthew Mondor * Released in the public domain (may be licensed under the GFDL). * * Please fix any bugs as needed, preserving the KNF style and this comment, * unless considered inconvenient in which case you can do whatever you want * with the code. */ #include <assert.h> #include <stdio.h> #include <
世界中で利用される「D3.js」の開発者が10年間で学んだこととは？
ニューヨーク・タイムズやOpenStreetMapなど、さまざまなウェブサイトで利用されているデータ可視化ライブラリが「D3.js」です。そんなD3.jsの開発10周年を記念して、開発者のマイク・ボストック氏が「D3.jsを10年間開発する中で学んだこと」を公開しています。 10 Years of Open-Source Visualization / Mike Bostock / Observable https://observablehq.com/@mbostock/10-years-of-open-source-visualization ◆「使用例」がツールの普及に役立つ ボストック氏によると、新たに開発されたツールは、開発者以外の人々にとっては異質なモノであるとのこと。そのため、ツールを普及させるには「ドキュメント」「チュートリアル」「使用例」などを準備する必要があります。 ボ
Introduction - PDM
Usage Reference Development Sponsor Introduction# PDM, as described, is a modern Python package and dependency manager supporting the latest PEP standards. But it is more than a package manager. It boosts your development workflow in various aspects. Feature highlights# Simple and fast dependency resolver, mainly for large binary distributions. A PEP 517 build backend. PEP 621 project metadata. Fl
えっ、著作権の帰属を表すHTMLタグがあるんですか？ - Qiita
smallタグ smallタグです。 かつては文字を小さく表示するために使われるタグでしたが、今ではセマンティックな役割が与えられています。 そのうちの1つが著作権の帰属を表すです。 なんでこの記事を書いたのか smallの役割って意外と知られていない気がする 最近レビューで連続でこの話をした という2つの理由から記事を書きました。 内容の補足 コピーライト表記ってありますよね？ © 2019-2021 Example Corporation All rights reserved. みたいなやつです。 色々なサイトのマークアップを見学していてspanタグで実装されていることが多いことに気がつきました。 しかしHTML Living Standardのsmallタグの章を見てみると Small print typically features disclaimers, caveats, l
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェア開発における『知の高速道路』
GitHub - LeCoupa/awesome-cheatsheets: 👩💻👨💻 Awesome cheatsheets for popular programming languages, frameworks and development tools. They include everything you should know in one single file.
