新Linuxカーネル解読室 カテゴリーの記事一覧 - VA Linux エンジニアブログ本稿では、タスクの切り替えに伴うレジスタの切り替え処理の内、前編 (7月11日公開: https://valinux.hatenablog.com/entry/20240711) では解説しきれなかった部分について解説します。
RedmineのSettingクラスのコードを読んでみる
RedmineのSettingクラスのコードを読みます Settingクラスは400行未満の行数としては比較的軽めのコード Rubyのメタプログラミング(class_eval)が活用されている読んでいて面白いコード 今週のブログ担当は石川です。 RedmineはRuby on Railsでできているオープンソースソフトウェアです。コードが公開されているので誰でもコードを読むことができます。RedmineのSettingクラスの実装があまり見ない感じで面白かったので紹介します。 2022/10/11時点で最新のコード(r21901)についての記事です。本記事はコードを読んで挙動や意図などを推測したものなので、知識不足などのため正確でない内容が含まれているかもしれません。 Redmineの設定(管理者のみが操作可能) SettingクラスにはRedmineで管理者のみが操作できる設定画面に関す
Pull Requestの質を向上させるために行った戦略/戦術の話 - JMDC TECH BLOG
株式会社JMDCでモバイルアプリエンジニアをやっている @mrtry です。入社した当初、モバイルアプリチームのエンジニアは私一人だったのですが、現在では4人になりました。最近はPull Requestのレビュー数も爆増しており、とても疲弊しがちです(嬉しい悲鳴)。たいへんポイントを減らすために、最近Pull Requestまわりの運用を整えたので、今日はその話をしたいと思います。 Pull Requestのレビューがたいへん 現在、モバイルアプリチームでは、3つのプロダクトの開発をしています。各プロダクトに1名ずつassignされており、リードエンジニアとして私が一通りレビューをしている状況です。そんなこともあり「Pull Requestのレビューがたいへん」というのが最近の悩みでした。 Pull Requestのレビューをするとき、私は以下のような観点でレビューしています。 機能仕様レ
プログラムの可読性に関する検討 - Cube Lilac
目次 はじめに（※この記事） 名前 式と文 一貫性と慣用句 関数マクロ マジックナンバー コメント 長さ（行数，1行の文字数） はじめに http://d.hatena.ne.jp/honjo2/20100518/1274178222 を読んでプログラムの「可読性」について考えていたら長くなりそうだったので，イントロ的な記事をまず書いておきます．詳細は，まとまったらと言う事で． 指標の必要性 「可読性」は主観に依存する部分も大きいため，注意深く検討していく必要があります．特に，「可読性が低い」と言う言葉は単に「俺が読めないコードはクソだ！」の言い換えでしかない場合も多いので，そうならないように注意する必要があります． 「可読性」は，単語の指す範囲が広く，また曖昧であるという問題があります．例えば，http://d.hatena.ne.jp/honjo2/20100518/127417822
ソフトウェア開発：エレガントなコードというか、クリーンなコードの書き方：The Grouchy Bug：オルタナティブ・ブログ
「ビジネスをデザインするブログ」 私がエレガントなコードを書くことにこだわらないいくつかの理由 おもしろく読ませていただきました。ソフトウェア開発っていろいろ悩みがあるんですよね。 ところで、エレガントという言葉よく聞くんですがいまいちしっくりこない、そんな言葉です。 エレガントと言えば、私が想像するのは、高価なコップで紅茶を飲みながらクラッシックを聴く感じ？笑 でも、やっぱりきれいなコード、クリーンなコードは書きたいと思いますよね。ということで、デザインパターンとか難しい話なしの、私が普段考えるクリーンコードの書き方のお話です。（なんかソフトウェアの話ひさしぶりのような。笑） なぜクリーンなコードを書かなくちゃいけないの？ ソフトウェア開発のサイクルとして、デザイン、コーディング、デバッグ、メンテナンスの繰り返しというのが一般的だと思います。既存のコードがきれいに、クリーンに書かれている
2010-03-20
なんでもかんでも、お疲れ様。メールの挨拶も、「お疲れさまです。hyoshiokです」朝でも昼でも夜でも「お疲れ様です。hyoshiokです」。飲み会で乾杯するときも「お疲れ様で〜す」、ジョッキをがちゃーん。会社でプレゼンする時も「お疲れさまです。開発部のhyoshiokです」。そして退社するときも「お疲れさまです〜〜」。飲み会での最後の挨拶も「お疲れ様でした〜」 みんな、お疲れなんだなあ。大変なんだなあ。そんなにお疲れしないように、肩のチカラ抜きましょう。もみもみ。凝ってますね〜皆様。 コードはHOW、テストはWHAT、ドキュメントはWHY。 先日のソースコードリーディングワークショップ2010でそんなようなことをお話した。 これは文字通りの意味だ。コードは実装の詳細HOWを表現している。どのように問題を解いたか。プログラマの数だけ表現がある。一方テストはWHATだ。何を実現するかを表して
WebKit について (コード) - 2010-01-02 - 兼雑記
WebKit のコードについて。 Google 社内のコードを見慣れてると、 WebKit のコードはまず、オープンソース的な感じというか、ありていに言うとコメントが圧倒的に少ないように感じます。特に内部についてわかってない人もわかるようなコメントを書く気は基本的に無いらしく、冗長気味なコメントを書くとむしろ削ってちょとレビューされたりします。偉い人死んだらどうするのかなー的な。 あとは関数名とかもイマイチなのが多いように思います。個人的な体験で一番印象的だったのは HTML parser 内にあった parseSpecial という関数でした。この special ってのは textarea, script, style, iframe なんかの中にあるタグが無視されるような種類のものを指していたのですが、 special って命名はアレだなぁ…と。そう思いつつ WebKit の人はみん
理解することが書き直すことを意味するとき
Jeff Atwood / 青木靖 訳 2006年9月18日 開発者に時間をどう使っているか聞いたなら、彼らはほとんどの時間コードを書いていると答えるだろう。 しかし、ソフトウェア開発者が時間を実際どう使っているか観察したなら、ほとんどの時間をコードの理解に使っていることがわかる。 ピーター・ハラムがこのことについて説明している。 どうしてコードを新規に書くより5倍もの時間をコードの修正に使っているのか? それは新規のコードはほとんどすぐに古くなるからだ。何か新しくコードを書く。コーヒーを飲んで一服する。すると突如として、コードは古いコードになっている。できたてのコードはせいぜい初期のデザインしか反映していないが、デザインの多くの部分は前もって現われるものではない。開発プロジェクトの多く が反復的開発手法を使っている。デザイン、コーディング、テスト、繰り返し。たくさんの繰り返し。すべてが新
コードレビューって意味あるの ? | スラド デベロッパー
「こういうコードが恥ずかしいコードである」 という価値観について、上級技術者間で意識統一がなされていればね。 ようするにコードレビューと言うのは、大学の研究室で言う輪講とかと同じなんです。 コードをよりよいものにする、と言うのも目的の一つですが、コードを組んだ人のレベルアップを図る、という目的もある。 十分な人数の、良く判っているプログラマがいるならばペアプログラミングも良いでしょう。でもペアを組んで回れるほどレベルの高い人がいなかったら? 「教授と助教授と助手の目の前で発表させる」 しかないじゃないですか。 もちろん、この作業は「教授や助教授や助手」の時間を食います。もしあまりにも多くの時間を食うのであれば可能性は次の３つのどれか。 初心者が多すぎる。そのため、「教授や助教授や助手」の時間をフルに使っても、全部など到底見切れない。コードの品質は悪いままである。初心者が少なすぎる。コードの
Home | byteMyCode
Account Suspended This Account has been suspended. Contact your hosting provider for more information.
パイプラインパターンでテキスト処理 - 当面C#と.NETな記録
パイプラインパターンで、ちょっとだけ実用的な例を。 ログなんかをPerlやRubyで処理して必要な部分を抜き出したりなんてことをよくやると思いますが、PerlやRubyではファイルを開いて一行ずつ処理するのが超簡単です。パイプラインパターンを使えば、同様に簡単にできるので、実演してみました。 Mapに渡したdelegateで行番号をつけて、Takeで先頭10行だけ抜き出しています。 static void Main() { try { int lineCount = 0; foreach ( string str in Take( 10, Map<string, string>( delegate( string s ) { return ++lineCount + " : " + s; }, TextFileReader( "../../Program.cs" ) ) ) ) { Con
＠IT：ソースコード自動生成技術分野の最新状況
Webアプリケーション開発案件の短納期化、高品質化、低コスト化要求に応えるために、ソースコード自動生成技術を活用する手法が注目されている。アイデア自体は昔から存在するものの、これまで大きく普及してこなかった自動生成という分野が、いまなぜ再び脚光を浴びつつあるのか。開発現場では顧客の高品質化要求や短納期要求により、もはや5％や10％の生産性向上策では負荷を吸収できずにいる。思い切って生産性を5倍、10倍へと上げるためには「できるだけコードを書かない」という発想の転換を行うしかないと気付き始めてきたことが大きい。ここではその技術進化の過程を追っていくとともに、ソースコード自動生成技術分野の最新状況と、これによるソフトウェア開発作業の現場への影響を紹介する。 自動生成技術の歴史 ソースコードを自動生成させるという考え方自体は古く、FortranやCOBOLが全盛の時代から今日に至るまで、さまざま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Beautiful Way to Organize Code Snippets – The icodesnippet.com is simple solution for complex connections.
IDEA * IDEA