The Rust Book
The Rust Programming Language by Steve Klabnik and Carol Nichols, with contributions from the Rust Community This version of the text assumes you’re using Rust 1.67.1 (released 2023-02-09) or later. See the “Installation” section of Chapter 1 to install or update Rust. The HTML format is available online at https://doc.rust-lang.org/stable/book/ and offline with installations of Rust made with rus
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
良いコードとは何か - エンジニア新卒研修 スライド公開｜CyberZ Developer
CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
モブプログラミングに向いてない私の話 - 誰かの役に立てばいいブログ
新型コロナウィルスの影響も長引いてますが、皆さま無事お過ごしでしょうか。私は幸い無事です。 日ごろチームでソフトウェア開発をしているのですが、近年社内ではペアプログラミングやモブプログラミングが流行しています。 私のいるチームでもここ二年ほどモブプログラミング（ないし類似のプラクティス）に取り組んできました。 モブプログラミングについて正確にどのようなものかは以下の記事などをご参照いただければと思います。 簡単にまとめると、要求分析やコーディング等幅広い開発作業を、同じ場所に集まったチームの共同作業でこなしていくというものです。 このご時世ですので、最近はオンラインのミーティングルームに集合する形式でしたけど。 www.agilealliance.org ここから先は、非常にパーソナルな、私に限定された体験になります。 どの人・チームにも適用できる話ではありません。ではありますが、どの人・
Google C++ Style Guide
Background C++ is one of the main development languages used by many of Google's open-source projects. As every C++ programmer knows, the language has many powerful features, but this power brings with it complexity, which in turn can make code more bug-prone and harder to read and maintain. The goal of this guide is to manage this complexity by describing in detail the dos and don'ts of writing C
バグの混入コミットを発見するGitコマンド：bisect - はんなりと、ゆるやかに
開発をしているといつの間にかバグが混入することがありますよね。混入タイミングが分からない場合はとりあえず正しく動く時期のコミットを見つけて、バグが発生するまで地道に調べていくと思います。 そんなときに使えるコマンドが git bisect です。 git bisect はコミットログからバグが発生したコミットを見つける手助けをしてくれます。 git-scm.com 今回の検証に使ったgit version は 2.26.2 です。 サンプルコード 検証用にバグが混入しているリポジトリを用意しました。最新のコミットはテストコードが通りません。 github.com 基本的な使い方 バグが混入しているコミットと正しく動いていたコミット間から混入したコミットを見つけます。正しく動いていたコミットは確実に動いていた時期のコミットを指定します(1週間前は確実に動いていたのになーって感じならその時期の
読みやすいコード（僕にとって） - Mitsuyuki.Shiiba
最近気づいたことがある。それは、僕はみんなみたいに複雑なことが理解できない、ってこと。 話をしてても「ごめんなさい。いまのわかんなかった。もう一回教えて欲しい。」とかよくあるし。ドキュメントも、ちょっと複雑なことが書いてあると、全然頭に入ってこない。 色んなルールがドキュメントに書いてあって、それをちゃんと守りながら開発してる人たちとか見てると、みんなすごいなぁって思うのであった。 なんだろうなぁ。こう・・・色んな想像が始まってしまって、考えが落ち着かないんよね。 そんな僕なのだけど、ここ数年はありがたいことに色んなコードを読む機会がある。読みやすいコードもあれば、パズルみたいに複雑なものもあって。そんな中で、たぶん、僕にとって読みやすいコード、というのは普通の人にとってはとても読みやすいコードなのかなぁって思って。書いてみる。 JavaでWebのアプリを開発してる。基盤とかフレームワーク
良いエラーメッセージの書き方 - Qiita
エラーには大抵「エラーメッセージ」が付いています。 自分は過去に、エラーメッセージの内容を雑にしてしまい後悔することがよくありました。 その経験から、良いエラーメッセージの書き方を考えました。 エラーメッセージを2つに分類する まず、エラーメッセージといっても次の2つのパターンで大きく異なってきます。 (1) ユーザーが見るエラーメッセージ (2) 開発者が見るエラーメッセージ (1) ユーザーが見るエラーメッセージ 内部実装のことは書かないようにする
.NET Coreでコンソールアプリを配置する
クロスプラットフォームで開発できる.NET Coreの基礎から開発実践までが学べる入門連載。4回目は作成したコンソールアプリのプロジェクトをビルドして配置する手順を説明する。 ← 前回 連載 INDEX 次回 → .NET Core 2.0 SDKインストール方法の変更［対象： Linux］ CentOSをはじめ、以前はtar.gz形式の圧縮ファイルを解凍してインストールしていたLinuxディストリビューションについても、rpmなどのパッケージとして配布されたものをインストールする方法が紹介されるように公式ページでのインストール方法の記載が変更されている。 必ずしも再インストールする必要はないが、今回の後半でLinuxサーバーに配置する際に、ログインシェルを持たないdotnetuserでdotnetプロセスを実行している部分が、従来のインストール方法だとそのままでは実行できなくなる。rpm
「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog
はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機
2017年夏のPerl
6. 正規表現中の { の 扱いが変更に 5.16 で廃止、 5.22 以降警告が出ていたの が 5.26 では死ぬように $foo =~ /d{1,10}/; # ok $foo =~ /d{1}/; # ok $foo =~ /something{}/; # 5.26 ではエラー $foo =~ /something[{]/; # ok $foo =~ /something{/; # ok $foo =~ /{}/; # これも ok 7. 正規表現中の { の 扱いが変更に $foo =~ /$hash{bar}/; # ok $foo =~ /$notahash{}/; # 5.26 ではエラー $foo =~ /${$foo}/; # ok ( デリファレン ス ) $foo =~ /${${foo}}/; # ok ( デリファレン ス ) $foo =~ /$foo/; #
よいユニットテストを書くには
テストを小さくする。適切なツールを使う。プログラマとテストがペアになる。これらは、よいユニットテストを書くための、Adrian Bolboaca氏からの提案だ。 ユニットテストは、プログラミングとテストが混ざり合ったものだ。プログラマは、テスタと共に作業することで、お互いに学び合い、視野を広げることができる。 Adrian Bolboaca氏は、Mozaic Worksの組織と技術に関するコーチであり、ヨーロッパテストカンファレンス 2017において、様々なタイプの自動テストについて話す予定だ。 InfoQは、このカンファレンスについて、Q&A、要約、記事で扱う。 [ヨーロッパテストカンファレンス]は、専門家や実践者が一緒に話し、学び、テスト技術を実践するところです。 私たちは、テストをもっと効果的にするために、先進的な新しい方法を詳しく調べ、より強いコミュニティに成長する基本的な方法を十
ソースコードの減らし方 - 基本的な考え方と10個の方法 - クラウドワークス エンジニアブログ
ステップ数で評価が決まる現場では全く役に立たないテクニックではありますが、ソースコードの減らし方について紹介したいと思います。 開発Div. エンジニアのayasudaです。 2014年の夏にジョインし、会社名と同じサービス、クラウドワークス の開発に携わっています。 ご覧の通り、消したソースコードの方が多いので、ステップ数換算だとマイナスの働きしかしてませんね！ 本記事では、特に Ruby on Rails の運用されているプロダクトコードにおける、ソースコードの減らし方について紹介していこうと思います。 基本的な考え方 ソースコードを減らすときの大原則は「ボーイスカウト・ルール - プログラマが知るべき97のこと」です。 普段、ソースコードを触るときに、一つでも良いので簡単な改善を入れる。これを積み重ねるのが大事です。 一度に一気に直そうとするのはあまり良くありません。大抵の場合、デグ
Git リポジトリに上がっているファイルを履歴ごと消すには？ - Qiita
仕事で必要になったので、ファイルを履歴ごと消す方法を試してみました。 ファイルを消しても履歴は残っている 例えば、1GB のバイナリファイルを Commit & Push したとします。 そして、それを git rm で削除したとしてもリポジトリの容量は減りません。 なぜか？ git rm は「ファイルが削除されたことにするコマンド」であって、「Git リポジトリ内に保存されている履歴を消すコマンド」ではないからです。 このサイトに書かれていますが、Git は「差分」ではなく「スナップショット」を保存して、「どのスナップショットを参照するのか？」をコミット単位ごとに切り替える仕組みです。 git rm は、この「どのスナップショットを参照するのか？」という情報を削除するコマンドです。 もし、データを丸ごと消したいのであれば、保存されている全ての「スナップショット」を消さなければなりません。
Perl コードのメトリクス測定
メトリクス解析ツール Perl コードのメトリクス解析には Perl::Metrics::Lite やコマンドラインツールの App::plmetrics を使用します。 plmetrics App::plmetrics モジュールにはコマンドラインでメトリクス解析を簡単に行う plmetrics が含まれています。 $ plmetrics --module Encode /usr/lib/perl5/5.8.8/i386-linux-thread-multi/Encode.pm .---------------------------------------------------. | | avg | max | min | range | sum | methods | +-------+-------+-----+-----+-------+-----+---------+ | c
コードレビューは愛である
コードレビューは、正直あまり楽しくない作業です。 簡単なものや、量が少ないものはそんなに苦ではありませんが、複雑なものや、別のプロセスと連携するものなど、正直コードを読んでもよく分からない、ということがよくあります。 今回はコードレビューを自分がどう捉えているのか、そしてどんな風にやっているのか、について書きます。 どこを見るのか?：自分の場合基本的には、自分は「バグを見つけること」に重点を置いています。 もちろん「もっと単純に書けるところを探す」「もっと速い処理に書き換えられそうなところを探す」「設計がまずいところを探す」「誤字を見つける」「コメントの間違いを見つける」「何をやっているのか分からないところについて質問する」などコードレビューでできることは色々ありますが、自分は究極的にはバグやエラーになるところをできるだけ探すようにしています。 動かない綺麗なコードより、動く多少汚ないコー
デキるプログラマだけが知っているコードレビュー7つの秘訣
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。Read less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードをどまんなかに
GitHub - everyleaf/el-training: 株式会社万葉の新入社員教育用カリキュラム
クソコードの測り方
