C/C++のための開発援助ツール、GCCSenseをリリースしました - Functional Emacser
未踏プロジェクトの支援を受けて開発していた、C/C++のための開発援助ツールGCCSenseをリリースしました。配布物やドキュメントは次のURLから入手できます。 http://cx4a.org/software/gccsense/index.ja.html 開発援助ツールと銘打っていますが、現状利用できる機能はコード補完と自動構文チェック（Emacsのみ）だけです。将来的には関数ヘルプ機能や型表示機能を実装する予定です。 GCCSenseはコード補完などの機能を搭載した独自のGCCを利用しているため、インストールがかなり面倒です。ドキュメントによってある程度カバーしたつもりですが、環境によってまちまちなのでインストール時に問題が出てくるのは必至だと思います。その際は私に連絡してください。 また、独自GCCを利用している関係上、現状ではWindowsでの利用はできません。自由なソフトウェア
下限に合わせたプログラム設計はシステム開発を停滞させる - @katzchang.contexts
FxUG@北陸の懇親会で出た話題。 中規模以上のプロジェクトになれば、悲しいかな、テンプレにそったプログラムしか書けない人や、そもそもプログラムを書いたことすらない人が結構いたりします。10人もかき集めれば2〜3人、いや半分はそういう人だったり。リーダーさんは仕様検討とかで忙しいから、そういう初級者さんにプログラムの作成を頼らざるを得ないってのが現実です。 で、初心者さんにもわかりやすい設計のプログラムを量産していきましょう、となる現場はよくあります。なに、うちのところもそんなもんですよ。 でもそれで良いの？と、個人的には疑問を持っています。 初心者でも書けるように、テンプレートをコピーして使う。 コピペ駆動開発の副作用は周知の通り。 テンプレートが役立つのは限定的な場合。仕様が想定の範囲を超えればテンプレートを捨てなきゃならないけど、その判断を誰が下す？ 後々の保守しやすいよう、初心者で
Google 工藤拓さん講演「大規模ソフトウェア開発を支えるGoogleのテクノロジー」
NAISTにてMeCabの作者としても有名な工藤拓さんの講演が行われました。Googleの開発体制とそれを支えるツールのお話です。 学校と拓さんの双方からブログへの掲載許可が得られたので、まとめを公開します。この講義はNAISTのソフトウェア開発管理講義の一環です。 iPhoneカメラしかなかったので、画像が荒くて済みません・・・。 会場は大入り！ 工藤拓さん NAIST自然言語処理学講座出身 Googleに入社してから大規模開発やインフラを経験 MeCabを開発 NTTコミュニケーション科学基礎研究所に所属 その後Googleへ 研究より開発寄り Googleでの仕事 日本語のウェブ検索 「もしかして」機能 ダジャレサーチ エイプリルフールネタを1ヶ月かけて実装 何千人もの開発者が単一のソースコードリポジトリの上で開発を行っている 大規模開発をサポートするインフラが不可欠 Mondria
いいコーディング規約、悪いコーディング規約？ | スラド デベロッパー
本格的なソフトウェア開発企業で働くとき、最初の頃にまずコーディング規則や慣習などのガイドラインに目を通したかと思う。基本的なガイドラインとして、gotoは原則使用禁止だとか、インデントにはスペースではなくタブを使用すべきであるとか、またはその逆などがあっただろう。ひょっとしたらcontinue禁止や、複数リターン値禁止など、ちょっと変わってるように思える慣習や、あまり直感的とは言えないルールといったものもあったかもしれない。 可読性を高めたり、メンテ性を向上させるには、どんな規約が有効だっただろうか？ ドキュメント上では一見良さそうに見えたが、実際はイマイチだったものなどあるだろうか？ /.J諸氏が実践してきたコーディング規約で特に有効だったのはどんなものだろうか？ 逆に規約のせいで問題が起きてしまったケースなどあるだろうか？ 他にも、使える「自分ルール」などもあれば是非。
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
NUnit を使ってみた - ~fumi/ChangeLog
[2008-06-27-1]で書いたとおり，NUnit を使ってみたので， 簡単な覚え書き． - NUnit 2.4.7 をインストール． - Visual C# のソリューション・エクスプローラ内で右クリックし， [追加]->[新しいプロジェクト]でテスト用のクラス・ライブラリを作成． - 新しく追加したプロジェクトを右クリックし，[参照の追加]を選択し， nunit.framework.dll への参照を追加する． - 同様に，テストするプロジェクトへの参照を追加する． - 以下のような雛形を書く． using System; using NUnit.Framework; namespace ClassLibrary1_Test { [TestFixture] class fooTest { } } - テストを追加してビルド using System; using NUnit.Fra
nDiki: スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。 (2008-06-14)
スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。 自分がプログラムをスクラッチから書き直したいと思った時、またスクラッチから書き直したいと言われた時のためにまとめておこう。 スクラッチから書き直したい理由 スクラッチから書き直したいと思う理由はだいたいこうだ。 もっと良くできると思うから 「もっと良いやり方がある」「自分ならもっとうまく書ける」 「統一されていない」「もっと汎用的にできる」 「今なら新しい開発環境(・新しい実行環境・新しいライブラリ・新しい言語)を使って簡単によりいいものが素早く作れる」 よくわからないいから 「何をやっているかわからない」「どう直していいかわからない」 「もう直しようがない」 「作り直した方がはやい」 あいつのだから 「あいつが書いたコードだから」 どんなプログラムでも開発が進み詳細がわかってくると、こ
「同じコード」の同じって何さ - TAPのススメ : 404 Blog Not Found
2008年03月27日03:00 カテゴリArtLightweight Languages 「同じコード」の同じって何さ - TAPのススメ 問題は、この「同じコード」の定義。 「誰が書いても同じコード」は大事なことなのか - ひがやすを blog でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。同じ「書き方」をしなければならないのか? 結果が「同じ」ならいいのか? もし後者だとしたら、実は 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 すら必
Joelに聞く、「優れた開発者」の要件・心構え・努力すべきこと：CodeZine
世界的に認知されているソフトウェア開発プロセスのエキスパート。彼のWebサイトJoel on Softwareは、世界中のソフトウェア開発者に人気があり、30以上の言語に翻訳されている。ニューヨークにあるFog Creek Softwareを創業し、ソフトウェアチームのためのプロジェクトマネジメントシステムとして人気のあるFogBugzを作った。JoelはMicrosoftでExcelチームのメンバーとしてVBAをデザインし、Juno Online Servicesでは数百万人が使うインターネットクライアントを開発した。 優れた開発者の要件――まず、「優れた開発者にはどのようなことが求められるか」についてお聞かせください ああ、大変だ。それなら12箇条ありますね。(笑) まじめに答えると、見方が二つあって、ひとつは成功するチームを作る上で誰を選ぶかということです。私はそういうとき、頭がよく
age.succ, 日本PostgreSQLユーザ会北海道支部 / Ruby札幌 合同セミナーの動画 - 角谷HTML化計画(2008-02-19)
■1 age.succ 別のインスタンスが返ってくるけど。 ■2 日本PostgreSQLユーザ会北海道支部 / Ruby札幌 合同セミナーの動画 先週末の札幌でのセミナーの全動画が我らが敵性サイト、ニコニコ動画にアップロードされました!! daraさん乙!!! 私の動画は3分割になっております。実演のところとかミスってたりするのでツッコミを入れたりしながら見てやってください。全部で90分ぐらいあります。長いなあ。この動画の上にライブ時のustのIRCログを流したい。 (補足: ニコ動のアカウントが無くても見れるように、そのうち他の動画サイトにも転載します) 2008/02/20追記: Ustream.tvで録画したもの(冒頭部分が切れています) 2008/03/09追記: ニコニコ動画のアカウントをお持ちでない方は、id:kakutaniのニコニコ外部プレイヤーをご利用ください。 スライ
ひげぽん OSとか作っちゃうかMona- - Subversionの話
Subversion を使うようになって数年が経ちますが、最近 svn diff/status/log/merge などのコマンドに熟達してきた。 気軽に ブランチを作る マージする コードを元のバージョンに戻す 問題となるコードを diff で調べる などができるようになって、作業効率が上がったり、こまめにコミットさえしておけば、あとからどうにでもなるので精神的にもかなり楽になった。 この「気軽に」ってのがとても重要。 以前だって、マージの概念やいつでも好きなバージョンに戻せること、diff を表示することが出来るのは知っていたし、たまに使っていたりもした。 ただ使う場合は コマンドをWebで調べる おそるおそる試してみる 失敗して check out しなおしで時間をロス などがありストレスがたまりがちで、結果的にこれら有用な機能を使うのを無意識に避けていたなと、振り返ってみると気づく
Makefileの書き方、その勘どころ - 檜山正幸のキマイラ飼育記 (はてなBlog)
「ほとんど忘れた、Makefile」 にて： Makefileなんてもう何年も書いたことがないぞ。ウーン、だめだ、忘れている。 「忘れている」ってよりは、僕の知識じゃ古すぎて、改めて勉強しないとダメでした*1。 なにしろ、makeだけじゃ機能が貧弱なんで、cpp（Cプリプロセッサ）やm4（マクロプロセッサ）と組み合わせて使っていた頃しか知らんからね（古すぎ！）。今じゃGNU Makeを（使おうと思えば）どこでも使えるから、GNU Makeを習えばそれでいいじゃないかな。僕は、Windows上のMSYS（MinGW - Minimal SYStem）でGNU Makeを動かしました。 というわけで、GNU Makeの手習いをしたからメモしておきます。以下、名前がMakefileじゃなくても、GNU Makeへの指示を書いたファイルは何でもMakefileと呼びます。 [追記]id:paell
第4回 コードレビューについて | gihyo.jp
はじめに 「プログラミングに関する雑多な事柄」がテーマの本連載、第4回は「コードレビュー」について取り上げたいと思います。 コードレビューの方法 コードレビューは、文章のレビューと似ています。文章と同様にコードの場合も、人に見てもらうことで、わかりづらい部分や冗長な部分など、さまざまな問題点が見つかります。 自分の書いた文章を人にレビューしてもらうには、たとえば、文章をメールで送ります。この場合、レビューのフィードバックはメールの返信という形で受け取れます。 コードレビューの場合も同様の方法で行えます。コードレビュー用の市販ツールなどもありますが、人に見てもらってフィードバックを得るということが一番大切ですから、特に方法にこだわる必要はないと思います。 コードレビューのメリット それでは、コードレビューに具体的にどんなメリットがあるのか見ていきましょう。 コメントの充実 コードを書いた本人
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
ソフトウエア開発のどこまでを設計と呼ぶか？：ITpro
筆者には，現役でソフトウエア開発をしていたころから抱いている疑問がある。それは「ソフトウエア開発にとって，どこまでが設計なのか？」ということだ。その疑問は，エンジニアから記者に転職し，さまざまなSEやプログラマを取材するようになって，ますます深まるようになった。 一般にビジネス・アプリケーションのソフトウエア開発は，設計工程と製造（コーディング）工程に分かれる。ソフトウエア開発者は，設計者（主にSE）とプログラマとに分類され，設計者が書いた「仕様書（設計書）」にしたがってプログラマがコーディングする。仕様書にはさまざまな様式がある。オリジナルなものから，DFD(data flow diagram)，ERD（entity-relationship diagram），最近ではUML(unified modeling language)を使う場合もあるだろう。つまり設計とは「設計者が仕様書を書き
RubyInstallerWiki: RubyInstaller
One-Click Ruby Installer for Windows Current Version: 1.8.6-26 Final (2007-12-14) This is a [one-click, self-contained Windows installer download] that contains the Ruby language itself, dozens of popular extensions and packages, a syntax-highlighting editor and execution environment, and a Windows help file that contains the full text of the book, Programming Ruby: The Pragmatic Programmer's Guid
JapaneseTutorial - Mercurial
Mercurial の使い方のチュートリアル このチュートリアルは Mercurial の使い方を紹介します。 SCM ソフトウェアを使うにあたっての特定の予備知識は必要ありません。 あらかじめ Mercurial を理解する を見ておくとよいでしょう はじめに このチュートリアルを読み終われば、次のことが分かるでしょう: Mercurial を使うのに必要な基本的な考えとコマンド ソフトウェアプロジェクトに貢献する際の Mercurial の簡単な使い方 Mercurial のマニュアルページ hg(1) と hgrc(5) に目を通すことを強くお勧めします。 マニュアルページは リリース tarball にも doc/hg.1.html と doc/hgrc.5.html として含まれています。 コマンドラインで hg help <command> とタイプしても良いでしょう。 チュー
コードを書く全ての人に - builder by ZDNet Japan
PHP技術者認定機構、ウェブセキュリティ試験を導入--サイバー攻撃の激化を受け ウェブサイトを狙うサイバー攻撃の脅威が高まっていることから、PHP技術者認定機構は開発者やユーサーを対象にウェブセキュリティ試験を導入する。 2018-12-12 11:25:00 「etcd」がCloud Native Computing Foundationのインキュベーティングプロジェクトに Kubernetesクラスタの情報を保持する分散KVSプロジェクトのetcdが、Cloud Native Coputing Foundation（CNCF）にインキュベーティングプロジェクトとして加わった。 2018-12-12 11:07:00
【ITpro Challenge!】「高い生産性を実現する『ハッカーのソフトウエアエンジニアリング』とは」---Google 鵜飼文敏氏：ITpro
「情報の共有は善。Googleも全員がほとんどのコードにアクセスできる。そして少人数のチームであること。Googleでも，一つのプロジェクト・チームは5～6人以下」---Google ソフトウエアエンジニアの鵜飼文敏氏は9月7日，イベントITpro Challenge!で「ハッカーのソフトウエアエンジニアリング」と題し講演，高い生産性を実現するハッカー流の開発手法を解説した。 ハッカーと呼ばれるプログラマは，通常の数倍とも数十倍とも言われる生産性と，高い品質を実現していると言われる。鵜飼氏はボランティア・ベースのLinuxディストリビューションDebian ProjectオフィシャルメンバーとしてIPA OSS貢献者賞を受賞したほか，The Free Software Initiative of Japan副理事長，2003年と2004年度の「未踏ソフトウエア創造事業」プロジェクトマネージ
「車輪の再発明をするな」の流行は孔明の罠 - きしだのHatena
なんかの実装がオープンソースで公開されているときに、同じ機能の実装を行うのは「車輪の再発明」で無駄な行為だといわれた時期がありました。 でも、それは「再発明」ではなく「再実装」であって、とても大切な行為です。 車輪にしたって、ブリヂストンも横浜ゴムもタイヤの開発をいまもって続けてるわけです。タイヤだけでなく、ホイールからベアリングからドライブシャフトから、「車輪」の部品については、いまだにいろいろな会社が切磋琢磨して再実装を続けているのです。 世の中に出ているライブラリを自分で実装してみるとわかることは、自分の実装を持っているという強さです。 たとえ世の中のライブラリに機能的に性能的に負けていたとしても、自分の実装というのは自分のニーズに合わせるという点でとてもいい。特に、処理の途中の値を使えるというのがいいのです。ライブラリでは、入力したら出力が返ってくるまで中身が見れないですからね。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
