[コーディング]の検索結果

＋ 

A 歌手のプリンス（57）さん死去

－ 

A 歌手のプリンス（57）さん死去

016年4月21日に米国のミュージシャンのプリンスさんが、アメリカ･ミネソタ州にある自宅兼レコーディング・スタジオ「ペイズリー・パークスタジオ」で死亡しているのが発見されたと米国のメディアが一斉に報じている。...

016年4月21日に米国のミュージシャンのプリンスさんが、アメリカ･ミネソタ州にある自宅兼レコーディング・スタジオ「ペイズリー・パークスタジオ」で死亡しているのが発見されたと米国のメディアが一斉に報じている。現時点では死因は不明。

プリンスさんは、12作品のプラチナアルバムと30曲のトップ40シングルを生み出し、アルバム・シングルの総売り上げは1億2000万枚以上。数多くのミュージシャンに多大な影響を与えたカリスマ的な存在として知られる。

プリンスさん死去、57歳「パープル・レイン」など世界的ヒット
PRINCE - ART OFFICIAL AGE
プリンス (ミュージシャン)

[4301] Posted by buzei at 2016/04/22 12:26:01
0 point | Link (1) | Trackback (0) | Comment (0)

＋ 

A Ruby（ルビー）とは

－ 

A Ruby（ルビー）とは

Ruby（ルビー）とは、まつもとゆきひろ氏によって開発されたオブジェクト指向のスクリプト言語のことで、Perlに匹敵する強力なテキスト処理能力とシンプルな文法などを特長とする。David Heinemeier Hansson氏によっ...

Ruby（ルビー）とは、まつもとゆきひろ氏によって開発されたオブジェクト指向のスクリプト言語のことで、Perlに匹敵する強力なテキスト処理能力とシンプルな文法などを特長とする。

David Heinemeier Hansson氏によって開発された優れたWebアプリケーションフレームワーク「Ruby on Rails」の出現によって、Webアプリケーション開発においても人気の高い言語になっている。

オブジェクト指向言語Ruby
オブジェクト指向のスクリプト言語 Rubyのサイト。ダウンロード、リファレンスマニュアル、FAQ、メーリングリストなど。

Ruby on Rails
オブジェクト指向スクリプト言語「Ruby」向けのオープンソース（MIT license）のWebアプリケーション開発フレームワーク。

Rubyアソシエーション
Ruby関連のプロジェクトやコミュニティ、ビジネスの関係を強化し、エンタープライズ領域におけるRubyの利用に関する諸問題の解決に取り組むことを目的とする合同会社。理事長はRuby開発者のまつもとゆきひろ氏。

日本Rubyの会
Rubyの利用者の支援、Ruby(+Rubyのライブラリ)開発者の支援を目的とした任意団体。

逆引きRuby
Rubyを使ってやりたい事から、その方法を調べられる逆引きリファレンス。

Ruby（Japanese）
Rubyのスクリプト集。

Rubyコーディング規約
Rubyのコーディング規約の雛型。

Ruby Draft Specification
IPAがJIS規格として標準化を進めているオープンソースのプログラミング言語「Ruby」の標準化仕様のドラフト（英語）。

Ruby のサンプルプログラム投稿サイト
Ruby のサンプルプログラムを登録、閲覧をするためのサイト。

プログラミング言語 Ruby
オライリージャパン 著者：まつもと ゆきひろ,David Flanagan 価格：3,990円 評価：★★★★★

• 最も信頼できるRubyの本 ★★★★★
• 基本書にふさわしい本 ★★★★★
• rubyマスターになるために ★★★★★
• 鬱にされる鬱然たるRuby教科書 ★★★
• For Rubist ★★

powered by amalink

[2024] Posted by buzei at 2010/06/28 11:27:37
1 point | Link (2) | Trackback (0) | Comment (1)

＋ 

A Perlベストプラクティス Damian Conway 著

－ 

A Perlベストプラクティス Damian Conway 著

Perlで見やすく堅牢な実用的なコードを作成するには具体的にどうすれば良いのか？著者のDamian Conway氏が、22年間のプログラミング経験にもとづいて、ソースコードのレイアウト、名前の選択、データ構造と制御構造の...

Perlで見やすく堅牢な実用的なコードを作成するには具体的にどうすれば良いのか？

著者のDamian Conway氏が、22年間のプログラミング経験にもとづいて、ソースコードのレイアウト、名前の選択、データ構造と制御構造の選択、プログラムの分解、インタフェースの設計と実装、モジュール化、オブジェクト指向、エラー処理、テスト、デバッグなどプログラミングをさまざまな面から捉えたガイドラインが提示されている。Perlでプログラムを書くプログラマなら持っておいて損の無い一冊。

Perlベストプラクティス 著者：Damian Conway 価格：4,515円 オライリー・ジャパン by Amalink

[1096] Posted by buzei at 2009/05/09 17:31:14
0 point | Link (2) | Trackback (0) | Comment (0)

＋ 

A オーディション開催中。

－ 

A オーディション開催中。

管理人様、不適切でしたら削除お願いします。ブリッジテントレーベルの新人スカウトをしている者です。一緒に成長していけるアーティスト募集します。弊社は、アーティスト育成から作品制作、作品営業、イベント管理...

管理人様、不適切でしたら削除お願いします。

ブリッジテントレーベルの新人スカウトをしている者です。

一緒に成長していけるアーティスト募集します。
弊社は、アーティスト育成から作品制作、作品営業、イベント管理等
精力的に活動しております。


ぜひご相談下さい。
どこよりも本物のアーティストの育成に力を
入れていますのでメジャーからのリリース実績もあります。
これからもっと増やしていきます。



簡単な弊社の活動内容

・イベントの企画

・CD作成
全国販売。全国のCDショップへ流通します。

・営業活動
CDショップでのインストアライブ、ラジオFMへの出演、雑誌などへの掲載、TV出演など。

・レッスン
　個性を引き出すボイストレーニング。


・レコーディングスタジオ完備。


・作曲できなくても大丈夫。


弊社は随時面接を行っています。
お気軽にご連絡下さい。
mixiアドレス
http://mixi.jp/show_friend.pl?id=3532793

有限会社bridgetentレーベル
神奈川オフィス・スタジオ
〒２４３－０４０５神奈川県海老名市国分南１－１１－２８－２F
TEL０４６－２１０－３１８５
http://www.bridgetent.com/

[840] Posted by （有）bridgetentレーベル at 2009/02/14 19:30:00
0 point | Link (1) | Trackback (0) | Comment (0)

＋ 

A デバッグを効率的に進めるための９の心得

－ 

A デバッグを効率的に進めるための９の心得

バグのないソフトウェアはない、というくらいソフトウェアにはバグがつきものですが、ソフトウェアの開発プロジェクトには期間や予算に上限があるため、バグの修正に手間取ると十分なテストを実施することができず、...

バグのないソフトウェアはない、というくらいソフトウェアにはバグがつきものですが、ソフトウェアの開発プロジェクトには期間や予算に上限があるため、バグの修正に手間取ると十分なテストを実施することができず、品質が低い状態でリリースされてしまうことになります。テストを円滑に進めソフトウェアの品質の高めていくためには、バグを迅速かつ正確にバグを修正していく必要があります。

しかし、オブジェクト指向プログラミング（OOP）やデザインパターンなどプログラムの作り方についての解説書や記事はたくさんあるにも関わらず、「バグは本来あってはいけないもの、あるはずが無いもの」という意識があるためか、デバッグに関して語られている情報源はあまり多くありません。そのため、デバッグのテクニックについてはせいぜい「開発現
場の先輩に教えてもらう」というのが実情です。

知識を共有するために、私がこれまでのソフトウェア開発の経験から得た、デバッグを効率的に行なうための心得をいくつか挙げてみたいと思います。

1. バグの原因は自分が作っているプログラムにある可能性が最も高い
ソフトウェアを構成する要素として、OS、開発ツールに付属するライブラリ、市販ライブラリ、プロジェクト内で作成されたライブラリなどがありますが、バグの原因は自分が作っているプログラムである可能性が最も高いと考えたほうがすばやくバグを見つけられます。なぜなら、今まさに開発が行なわれているプログラムこそが最もテストされていないプログラムだからです。問題の原因をマイクロソフトのせいにする前に自分のプログラムを調べましょう。

2. テストの実施を妨げているバグを優先する
当然のことですが、テストができなければバグを見つけることができません。効率的にバグが発見できるように、めったに行なわれない操作によって発生するバグよりも、必ず行なわれる操作で発生するバグを優先的に修正していく必要があります。

3. 問題を確実に再現できるようする
問題が発生する条件（操作手順、データなど）を必ず特定しなければなりません。これができないと動作確認は不可能ですので、修正したつもりが実は直ってなかったという事態にもなりかねません。この作業自体はソースコードがなくても可能なので、テスト担当者の協力を得られるのであれば、情報を交換しながらテスト担当者と開発担当者が並行して調査を進めるのが良いでしょう。

4. 一度でも問題が発生した場合はバグがある可能が高いので必ず調査する
一度でも問題が発生した場合は、単にバグが発現する条件がわかっていないだけで、必ずどこかにバグがあります。開発作業中はいろいろプレッシャーがあるので難しい面もありますが、見つけた時点で調査しておいた方がいろんな面で良いでしょう。

5. ソースコードを見ただけで正しい処理が行なわれていると判断しない
プログラムはプログラマが思っている通りに動くのではなくコンパイラが解釈した通りに動くものです。コンパイラについての知識が豊富なプログラマが犯しがち問題ですが、プログラマがコンパイラの仕様について誤解しているために生じるバグもよくあります。プログラマ自身は正しいと思っているためソースコードを見ただけではバグを発見することが困難ですがが、このようなバグは実際にプログラムを動かしてみることで簡単に原因を発見することがきます。

6. 想定外の操作や想定外のデータが使用されていないかチェックする
プログラムはプログラマが想定していなかった操作が行なわれたり、想定外のデータが入力されたりした場合は正しく動作しないことが多いものです。問題を発生させる操作やデータがプログラムで想定されているかチェックしてみましょう。

7. バグの原因となっているソースコードは必ず特定する
関係の無いところを直しても問題の現象が発生しなくなる場合もありますが、それでバグが無くなったわけではありません。そのような場合は、また別のところで別のかたちで問題が発生することになりかねません。バグは必ずソースコードレベルで原因を特定し確実に修正すべきです。

8. できるだけ他の処理に影響を与えないようにソースコードを修正する
他の処理に影響を与えるような修正を行なった場合、これまで問題なく動いていた部分に新たなバグを埋め込んでしまう可能性が高いものです。別の問題を引き起こさないように、影響範囲に注意してソースコードを修正します。しかし、単なるコーディング上の間違いであればプログラムの修正は比較的簡単で他の処理に影響を与えることは少ないのすが、設計に問題がある場合は他の部分の影響を与えないようにバグ修正を行なうのが難しい場合があります。そのような場合は、本質的な問題の解決にはならないとしても、影響範囲を限定するために暫定的な対処を行なった方が良いでしょう。

9. ソースコードを修正した場合は必ずテストする
たとえ簡単な修正であっても間違った修正を行なう可能性は常にあります。また、修正が思わぬところに影響を与えることもあります。当たり前ですが、ソースコードを修正した場合は必ずテストを行ないましょう。テスト作業を手を抜くよりも、テストを行なった方がトータル見れば開発者自身にとっても負担が少ないはずです。

[67] Posted by buzei at 2007/09/11 04:59:32
0 point | Link (2) | Trackback (0) | Comment (0)