開発時間の内訳を眺めてみよう - 日々常々
開発効率を上げたいとか、開発速度を上げたいと言うのはプログラマの自然な欲求だと思います。 「そう思いはするもののどうすればいいかわからない」のであれば、開発時間の内訳を眺めてみましょう。 この図はグルーピングが微妙だったり、重要なものが抜けていたりすると感じるかもしれませんが、雰囲気は伝わるかと思います。使用している技術要素や取り組んでいる内容によって項目レベルでなかったりもします。参考程度に。 さて、単に「開発効率」と言うと、「コードを書いている時間」に目が向きがちです。これはさらにタイピングの時間だとかに分けられるかと思いますが、実際のところ、ここに割かれる時間は全体で見れば誤差のようなものです。もちろん早いに越したことはありませんし、無意識に書けるようになれば思考を他にやりながら書けるようになります。実際ある程度慣れた方であれば、コードを書きながらコードを読み、抜け漏れに気づいたり、
技術から入ってもいいと言う話 - 日々常々
システム開発の分野は技術の移り変わりが早く（これも他の分野と比べたことないので「早い気がする」と言うだけなのだけど）、なんらかの成功を収めた企業などの採用しているものがバズワードとなって一気に広まったりします。この時、その技術だけを追ってしまう現象がよく観測されます。だからバズワードになるんだけど。 批判的な意見 バズワードに飛びつくのは往々にしてアンチパターンです。例えば「モノリスからマイクロサービスへ」でも、明確な理由もなくマイクロサービスに飛びつくのは避けるよう書かれています。 モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド 作者:Sam NewmanオライリージャパンAmazon 書籍に限らず経験のある人は技術の螺旋を見通し、「この技術は結局のところ重要な課題を解決しない」と示唆する発言をしたりします。 強く辛辣な言葉もたまに見かけます。「そこに問題はないんだ
テストでのデータベース単位の捉えかた - 日々常々
データベース（に限らずあらゆる永続化リソース）を使用するテストをいかにして行うかはいつだって悩みの種です。この悩みは「どうやったらデータベースを使用するテストを行えるかわからない」ではなく「なんとかやってるけど、不満のようなものがある」というものになるかと思います。 やりかたはたくさんあるのですが、その優劣は条件なしに比較する意味がないくらい、条件に依存します。どんな選択肢も「この条件なら最適」と言えてしまうだけに、広いコンテキストで「こうするのがベスト」とも言いづらいのです。 前提 xUnit Test Patterns を下敷きにします。 ユニットテストでの話です。他でもある程度通じます。 具象イメージはSpringBootを使用するWebアプリケーションです。そこまでべったりな内容ではありませんが、背景にあるとご理解ください。他でもそれなりに通じます。 データベースを使用するテストで
コミット対象をよりわけるのをやめてみよう - 日々常々
git add {ファイル名} でステージングするファイル単位で選べます。10ファイル変更しててそのうち3ファイルだけコミットしたい時とかに便利です。 git add -p でステージングする変更を行の塊単位で選べます。関係ないコメントを足しちゃったのとか、うっかりついでに変えてしまった変更をコミットから避けたり、別のコミットにしたい時とかに便利です。 間違いなく便利な機能ではあるんだけど、常用するものじゃないと思ってます。 なので git add -A を基本にする。 ……とか言いつつ git add . を常用している私。単にタイプ数と手の慣れ。ちなみにgitのaliasは使わない派です。これは違う環境でコマンド叩く機会が多かったりする都合です。 理由 を並べてみます。 コミット対象を選択するのがいちいちブロッキングなので時間がかかる 10ファイルの変更から3ファイル選択する時間は g
法律をリファクタリングしながら読んでみる - 日々常々
法律って慣れてないと読みにくいですよね。慣れたら読みやすくなるのかわからないけれど。 取り違いや誤解、漏れが少ないようにを意識して書かれているのか、どうしても冗長に感じます。 よくあるのが「AAAのBBB若しくはCCCのDDD」のようにAAAとCCC、BBBとDDDが並列で、これを一塊として後の文が続くもの。この塊を抜き出せると一気に読みやすくなります。 てことでリファクタリングをしてみる。テストがないのは気にしないで。 やるのは一次変数の抽出と名前の変更。 お題は「特定商取引に関する法律」の第三節 通信販売（通信販売についての広告）、第十一条です。 選んだ理由はたまたま今読んでるから。 まず原文から開始。 第十一条 販売業者又は役務提供事業者は、通信販売をする場合の商品若しくは特定権利の販売条件又は役務の提供条件について広告をするときは、主務省令で定めるところにより、当該広告に、当該商品
リファクタリングに関する何か - 日々常々
リファクタリングの話をするとき、焦点が合ってないなーと感じることがたまにあるのでざっくり描いてみた。 自分のために描いたものなので、なんか違うなーって思ったらご自身で描いてみるといいと思います。レッツモデリング。 破線は依存、実線は変換。長方形は名前などで明確に識別可能なもの、角丸は様々なものを包含する活動。雲は思いです。 描いた時の経緯と言うか 該当ツイート: リファクタリングって常時やるものなんですよね。もちろん「よーしやるぞー」って感じで行うものもあるんですけど、それは深呼吸的な。 とは言え。やったことがない、やってはいけない文化（動いているコードに触ってはいけない）に染められてしまっている、そのような方に「無意識にやれ！」と言っても、何の意味もないので言いません。むしろ害悪ですらある。 該当ツイート: 無意識にやるようになって、ようやく「リファクタリング」がカタログ化される前の「偉
「ソースコードブランチ管理のパターン」のダイアグラム - 日々常々
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja) お世話になっている人も多い Martin Fowler's Blikiの日本語翻訳サイト 、いつも運営＆翻訳ありがとうございます。 パターン言語は関連が重要な役割を担っています。そして関連はダイアグラムにすると捗ります。ダイアグラムがついている書籍もよくみます。 なので、ダイアグラムがないときや書籍と違う雰囲気のダイアグラムが欲しくなった場合、自分で描きながら読んでたりします。こんな感じで。 紙に手書きすることも多いのですが、インターネットで公開されているものはURLが付けやすいのでSVGで作るのが最近のマイブーム。SVGはサイズが大きくなっても拡大すれば読めるのでいいです。 上の画像はPNGをアップロードしたものなのでGistに上げました。 GistのSVGへのリンクを置いておきます。Gistの
いい名前が思いつかないときは変な名前をつける - 日々常々
プログラミングは名付けの連続です。しかし、いつも「いい名前」が見つかるわけではありません。付けたときはいい名前と思っていても、時間が経って知識が増え、ブレイクスルーが起こると、それまでいいと思っていた名前も途端に微妙に感じたりします。 このように「いい名前は見つからない」とか「どうせ変わる」とか思うと、名前を考えるのが無駄に感じたりしなくもありません。でも名前は重要です。名前の重要さは割愛します。プログラマが知るべき97のこととかを読んでください。 プログラマが知るべき97のこと 発売日: 2010/12/18メディア: 単行本（ソフトカバー） 名前を付けるときは、誤魔化さずに付けるように意識しています。と言うと、「いい名前をスパッと決められている」ように捉えられるかもしれませんが、そうではないです。私は名付け能力の低さには自信があります。誤魔化さずに付けると言うのは、「理解できていないこ
脱ブランチファースト - 日々常々
あるいは「プルリクエストをやめてみた」 チーム構成とかにもよるんだろうけど。Gitかつフォークされないプロダクトでの話です。OSSとかは全然話は変わります。 問題とアプローチ (2019-10-25T15:20 追加) 表出している問題と、ここでのアプローチを書いておきます。 ブランチファースト（造語） 「ブランチファースト」はこのエントリでの造語です。コードベースに変更を加える際に「まずブランチを作成する」から始めることを指します。 作業単位でブランチを作成、ブランチでコードを変更してプルリクエスト、レビューを経てメインライン（ master ブランチ）に反映までがブランチファーストのスコープになります。 よくあるスタイルだと思いますし、ブランチだけ作成して変更せずプルリクエストを作成する拡張もありますね。 プルリクエストを挟まずにメインラインにマージするものは含みません。 ……名前微妙
「レガシーコードからの脱却」を読みました - 日々常々
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス 作者:David Scott Bernstein出版社/メーカー: オライリージャパン発売日: 2019/09/19メディア: 単行本（ソフトカバー） 頂きまして、ようやく一通り目を通したので書きます。ありがとうございます。 どこを切り取っても話題の中心に置ける、そう言う本でした。 ざっくりどんな本かと言うと 原著「Beyond Legacy Code」が2015年とそこそこ新し目の本ではありますが、目新しいことは書いていません。見たことも聞いたこともないようなものは書かれていませんでした。プラクティス自体は目新しくはないですが、プラクティスの出自や必要とされた背景、実践における戦略などに焦点が置かれている点は目新しいと言えます。 この本の価値は様々なプラクティスから9つだけピックアップされていること。少
「現場で役立つシステム設計の原則」の目次流し - 日々常々
本日発売された @masuda220 さんの「現場で役立つシステム設計の原則」が気になってる方へ。 紙の本。 現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: 単行本（ソフトカバー）この商品を含むブログを見る こっちはkindle。 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: Kindle版この商品を含むブログを見る まだ全部読めてないけれど、精読するといつ読み終わるかわからない・・・。 なので、まったく読んでない気分になって目次ベースで紹介してみます。 どう言うことが書いてそうかの参考にはなるかなと。 しかしこの内容、よくこのサイズの本で、それほど小
告知: #TDDBC 大阪が2013年1月にあります - 日々常々
1月12日 2013年はじめのTDD Boot Camp in 大阪(大阪府) 1月13日 2013年はじめのTDD Boot Camp in 大阪 外伝(大阪府) 二日構成で、独立した別内容のイベントです。片方だけ参加でも、2日両方でも。今回の対象言語およびテスティングフレームワークは {Java:JUnit, Ruby:RSpec, C#:[MsTest,NUnit], C++:GoogleTest} となっています。 募集開始はおそらく2012/12/16の20時頃です！ 予定通り募集開始しております。 なるべく「知らなかった……」を減らしたいと思い、このエントリを書いています。少しでも効果があったら嬉しいなー。 以下は「一体何ぞや？」と言う方に向けたざっくりした説明とかです。詳細は募集ページおよび過去に行われたTDDBCの参加レポートをご覧頂くのが良いと思います。 1日目（2013
Git初心者用BootCampのようなものの演習資料 - 日々常々
Git 初心者用Boot Camp(のようなもの？ : ATND 3/17 に行われたGit初心者用BootCampらしき何かに行ってきました。 @datsuns さんを焚き付けたらなんか講師役に……「え、私のGit力じゃむりぽ」とか思いつつ、なんか話しに入ってた @backpaper0 さんを巻き込んで「何とかなるっしょー」と楽観的に挑みました。という割りに前日、というか当日AM5時頃まで資料ゴニョゴニョしてました。 やったことは、「Gitはコミットグラフを描ければ勝てる」を信じて、出したコミットグラフを作るためにどういうコマンドを打てば良いかの演習です。都度質問とか、こう言うのやってみたい、とかを聞きながら進めていったつもりです。 それなりに上手くいったと思う。 手順 一枚ずつコミットグラフを表示。下のコマンドは穴埋めのヒントです。空行は「適当にファイルでも作ってください」って感じで、
「プログラマが体験するべき50の危険なこと」と「きのこ本」 - 日々常々
「プログラマが体験するべき50の危険なこと」 - Togetterまとめ*1 プログラマが体験するべきではない50の危険なこと - Life like a clown はてなブックマーク - Togetter - 「「プログラマが体験するべき50の危険なこと」」 あるあるネタです。よくある危険な体験談なので、共感を得られるのも当然だと思います。ですが、単に並べるだけでは苦笑やネガディブなネタになってしまい、何も改善されません。 笑って済ませるのは悪です。そんなの皆わかってるでしょうけど、改めて「そんなもの」にしてしまわないように意識して欲しいと思うのです。どこが危険であり、どう改善するべきか。また、なぜそのような事が行われるか。そして実際体験する事になった場合の対処等に展開できたらいいなと思っています。最終目標はこれらの多くを無くす事です。こんな事、体験させるべきじゃないんです。 発端 子
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
