400行以下のオペレーティングシステム登場 | マイナビニュース
GitHubに400行以下で構成されたオペレーティングシステムが登録された。オペレーティングシステムは「resume_operating_system」と呼ばれている。開発の動機や仕組みなどに関する説明は「My resume in an Operating system」にまとまっている。オペレーティングシステムの基本構造を理解する際に役に立つ。 このオペレーティングシステムはMathieu Passenaud氏が学生時代に作成したオペレーティングシステムの基礎実装をまとめたもの。開発者の経歴を表示するだけという目的で作られた趣味的な取り組みの成果物であるため、明確に名称がついていない。GitHubに登録した名前が「resume_operating_system(経歴オペレーティングシステム)」であるため、この名称で呼ばれている。 resume_operating_systemではテキスト
ソースコードを読むための技術
$Id: readingcode.html,v 1.13 2003/12/06 00:01:08 aamine Exp $ 2006-05-02 gonzui 追加。thanks: 冨山さん 2003-12-03 ltrace と sotrace を追加 2003-12-03 ツールのところに DDD を追加。thanks: 和田さん 2003-05-27 VCG, SXT などについて追加。thanks: 梅沢さん 2003-05-27 これもすっかり忘れていた strace, ktrace, truss, etags などについて追加 2002-08-30 すっかり忘れていた ctags を追加 2002-07-07 匿名希望さんからメールでいただいた情報を追加 (動的コールグラフ) 2002-06-13 日記経由でいただいた意見をもとに文章を追加。thanks: 柳川さん、まつもとさ
ソースコード解析を使った脆弱性を排除するソフト作り
広範囲に使用されていたり、システムの重要な部分に使われてるソフトウエアに脆弱性が見つかると、その後の対策で大変な労力が必要となる。脆弱性をゼロにすることは不可能かもしれないが、脆弱性が残らないようなプログラム・コードを書くように努力し、そのソースコードを検査することで、簡単に見つかる脆弱性を残さないようにすることが可能だ。 本記事ではソースコードの脆弱性発見のために利用するソースコード・セキュリティー検査ツールの概要と、その効果などについて情報処理推進機構（IPA）の亀山 友彦氏に解説してもらう。 【最終回】ソースコード・セキュリティー検査ツール「iCodeChecker」を使ってみる 今回はソースコード・セキュリティー検査の具体的な活用例として、情報処理推進機構（IPA）が無償で公開しているソースコード・セキュリティー検査ツール「iCodeChecker」を使った利用例を紹介する。 20
コード解析の自動化（1）ソースコードのスタイル、作法チェック
出典：ITpro 2012/09/27 （記事は執筆時の情報に基づいており、現在では異なる場合があります） システム開発において、ソースコードの品質を担保するためにはソースコードレビューが不可欠です。ソースコードレビューには主に、以下の三つの役割があります。 コーディング規約順守のチェック バグ埋め込みのチェック 性能劣化のチェック これらのチェックは、実装（コーディング）工程で行うべきものです。コーディング規約の違反箇所は、実装工程の後では修正される機会は少なくなります。また性能問題を放っておくと、システムテストなどかなり後の工程で明るみ出て、リリースまでに残された少ない時間の中で対応を余儀なくされるといった事態になりかねません。 このように、ソースコードレビューには、その後の工程で補うことができない大きなメリットがあります。繰り返しますが、ソースコードレビューは必ず行うべきです。しかし
初めてのOS source code reading(UNIX 6th source code readingのススメ) - やる気のないブログ(A boring diary)
このエントリはhttp://d.hatena.ne.jp/takahirox/20120131/1328006885を和訳したものです。 はじめに 最近UNIX 6thのソースコードの読書メモを書き終えました。 みさなんにもUNIX 6thのソースコードを読むことをオススメします。 その理由をこのエントリで書いていきます。 まとめ UNIX 6thは初めてOSのソースコードを読む人にうってつけ！ 今すぐ読み始めましょう！ UNIX 6thのソースコードはこちらなどで読むことができます。 http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6 UNIX 6thのソースコードを読むことをオススメする理由 たったの10,000行 最近のLinuxカーネルのソースコードは100万行を超えています。全てを理解するのは至難の業です。 一方、UNIX 6thのカー
グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している
グーグルでは、社内のプログラマによって作り出される大量のコードの品質を保つため、チェックイン前にユニットテストとコードレビューが行われているそうです。しかし、コードが大量になってくると、ユニットテストやレビューをすり抜けるバグも少なからず発生します。 そこでコードの品質をさらに高めるために、グーグルでは「バグ予測アルゴリズム」を採用。バグがありそうな部分をレビュアーにアドバイスする仕組みを採用したとのこと。 そのバグ予測アルゴリズムとはどんなものなのか。Google Engineering Toolsブログに投稿されたエントリ「Bug Prediction at Google」（グーグルにおけるバグ予測）で説明されています。 ソースコードの修正履歴を基に予測 コードの中にバグがありそうな箇所を分析する手法としては、「ソフトウェアメトリクス」がよく用いられます。これはコードを静的に分析して、
lessでソースコードに色をつける
シェルの操作中「テキストファイルをちょこっと覗きたいな」と思ったときに抜群に便利なlessコマンドであるが、普段綺麗に色付けされたソースコードを見慣れていると、モノクロのソースコードの見づらさに愕然としてしまう。結局lessを終了して他のエディタで開きなおすことになるのだが、lessでソースコードに色付け（シンタックスハイライト）できれば便利なのになーっ！と思ったことはないだろうか。そう、あるんです！lessでシンタックスハイライトする方法はあるんです！というわけで、今日はその方法を紹介しよう。 GNU Source-highlight結論から言うと、今日紹介する方法はGNU Source-highlightを使う。GNU Source-highlightを使えばイッパツだ。なのでまずGNU Source-highlightをインストールしよう。UbuntuやFedoraならリポジトリにあ
ソースコードの品質向上のための効果的で効率的なコードレビュー
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『PL/SQL ソースコードの表示方法』
オープンソースなAndroidアプリ達 - ギークに憧れて