エラトステネスの篩 - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "エラトステネスの篩" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2019年6月) エラトステネスの篩 (エラトステネスのふるい、英: Sieve of Eratosthenes) は、指定された整数以下の全ての素数を発見するための単純なアルゴリズムである。古代ギリシアの科学者、エラトステネスが考案したとされるため、この名がついている。
Project Euler - PukiWiki
Project Euler † プログラムで解く数学の問題集です。 公式サイト 適当に和訳してます。我こそはと思う人はライセンスを確認した上で自由に書いてください。 ↑
About - Project Euler
About Project Euler What is Project Euler? Project Euler is a series of challenging mathematical/computer programming problems that will require more than just mathematical insights to solve. Although mathematics will help you arrive at elegant and efficient methods, the use of a computer and programming skills will be required to solve most problems. The motivation for starting Project Euler, and
Eclipseプラグイン コード品質のカイゼン(JUnit Factory)
これはすごい!?コード品質のカイゼン化プラグイン2種：CoolなEclipseプラグイン（24）（1/3 ページ） ソフトウェアの品質と保守性を向上させるために、テストケースの作成は重要です。しかしながら、時間がない、面倒だなどの理由によりユニット（単体）テストが省略されることはしばしばあります。 また、ソフトウェアの修正や仕様変更を考慮すると、保守性の高い（分かりやすい／読みやすい）コードにする必要があります。 本稿では、ソースコードからJUnitをベースとしたたテストケースを自動的に生成する「JUnit Factory」とコードの保守性の指標であるCRAP（Change Risk Anti Pattern）を計測する「Crap4j」をご紹介します。 テストケースを自動生成するJUnit Factoryとは？ JUnit Factoryはソースコードからテストケースを自動生成し、しかも生
あまりに見事に酷いお話 - みねこあ
いきなりお仕事の愚痴で申し訳ないのです。 私たちが作っている機器の下位ユニットのソフトの出来が酷いです。 どういう風に酷いかというと、ちょっと通信ログみれば一発で（仕様をしらない人間でも「ああ、こりゃコピペして修正を途中し忘れたな」と解るような）バグが普通にあったり、2個同じものをもつ構成なのに片方づつ全く違う挙動をしたり（バグも両ポートで違う^^;)。もちろん(?) コッチを直せばアッチがデグレードで、いつまで経ってもまともに動くようになりやしません。 で、あまりの酷さゆえ、彼らのコードのレビューが開かれたのですが。おぉ、これは凄い。こんなに見事なコードをみたのは初めてでした。 最長不倒関数、芸術的字下げ、strcat の嵐、グローバル変数の多用(しかも同類を構造体に纏める事すらしない)、コメント無し・define 無しで使われる数多のマジックナンバー、strcat の嵐、ナンバリングさ
いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な
【特集】Mac OS X Leopardの開発環境 (1) Objective-C 2.0 (1) - ガベージコレクション | エンタープライズ | マイコミジャーナル
先週の金曜日に正式版が登場したLeopard。Appleも多くの新機能を喧伝しており、それらを試している方も多いだろう。 この記事では、見方を変えて、開発者から見るとLeopardにはどのような機能が追加されているのか、紹介したいと思う。先に述べておくが、追加機能は非常に多い。この記事に入りきらなかった新機能や、従来の機能の強化もたくさんある。Tigerのときも大きく機能は広がったが、Leopardではさらにその上に積み重ねられている。Machカーネル、Cocoaフレームワークといった強固な基盤の上に、次々と機能が花開いている。 Objective-C 2.0 Leopardで拡張された開発分野の機能のうち、最も大きい影響があるのが、Objective-C 2.0の導入だろう。Objective-Cは、いまやMac OS Xでアプリケーションを開発するときの主流の言語だ。動的で柔軟なオブジ
Changelogのための英文テンプレート集 - ぴょぴょぴょ？ - Linuxとかプログラミングの覚え書き -
Changelog を英語で書く際に参考になるようなテンプレートをまとめてみました．git や svn のコミットログにも使えます． このエントリは今後も逐次更新を続けます（最終更新2018/11/01） リリースノートの英文についてはRelease note のための英文テンプレート集 - pyopyopyo - Linuxとかプログラミングの覚え書き -に分離しました git等のcommit メッセージにも使えます 以下，例文． バグ修正した場合 修正した場合 → fix を使うのが定番です Fixed a performance regression. （パフォーマンスが低下するバグを修正しました） Fix possible memory leak Fixed an issue where some devices would display the wrong image. (いく
marsのメモ - 開発環境に関わるメモ
今月で今やってる仕事の契約が切れるので，ここで培ったノウハウなどをメモしておこうと思う。 しかし，今後この手の開発系の仕事ができるとは限らないってのが悲しいところ。 プロジェクトポータルまわり とりあえず，Subversion(SCM), Trac(ITS/Wiki), Hudson(CI)は必須。この３セットがないプロジェクトなんてうんこ。 とにかくTrac-Subversionの連携が強力なので，Subversion以外のSCMは無視していい。HudsonはCIつうよりプロジェクトダッシュボードとして使うのが吉（数あるプラグインを有効利用しよう）。 marsのメモ - Trac marsのメモ - MacroBazaar - The Trac Project marsのメモ - 角谷HTML化計画(2006-04-25) marsのメモ - trac-post-commit-hookが
第9回 なんでも自動処理 | WIRED VISION
第9回 なんでも自動処理 2007年8月31日 IT コメント： トラックバック (0) （これまでの増井俊之の「界面潮流」はこちら) 同じような操作を何度も実行しなければならないとき、手間を省くために操作を自動化したくなります。たとえば、テキストファイルの行の先頭に> という文字列を追加していきたいとき、何度も> をタイプするのは面倒ですから、なんらかの方法で自動化できれば便利です。エディタに「n行にわたって行頭に文字列を追加する」のような機能があればいいのですが、様々な自動化要求すべてに対応することは不可能ですから、特殊な自動化処理を行ないたい場合は、なんらかの方法でユーザが自力でプログラムを作成して計算機に与える必要があります。 ユーザが「操作マクロ」を定義できるエディタは多いですし、本格的なプログラミングが可能なEmacsのようなエディタもありますが、こういったプログラミン
ソースコードを読むための技術
$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: 柳川さん、まつもとさ
パターン重要。 - eto.com/d
http://capsctrl.que.jp/kdmsnr/wiki/transl/?UsingPatternLanguagesForOOP この文章は本当に重要。 私はいままでパターンと言われていたものについて、 ものすごく誤解していたということを、ようやく理解した。 まず、パターンの源流はどこにあるのかという点。 私はいままで、GoF (Gang of Four)が源流なのだと思っていた。 全然違うんだね。 この文章が源流なのだとすれば、それは、 Apple Computer の Kent Beck氏と、Tektronix の Ward Cunningham氏の二人が、現在パターンと呼ばれている概念の原型を作り上げたのだということ。 この二人が源流なのであれば、現在XPと呼ばれている概念が パターンと直結していることも理解できるし、またもう一つ、 WikiWikiWebと呼ばれているシ
masuidrive on rails » Blog Archive » masuidrive的プロジェクトの方針
初めて会社員になって早3ヶ月。会社の仕組みもやっと分かってきたし、そろそろ本格的に開発プロジェクトも動いて行くということで、今後、社内で私と一緒に開発して行く人に、「私がどういう考えで仕事を進めていきたいか」という事を知ってもらうためのプレゼンを作ってみました。(今のところ一人だけど) NIFTYさんと仕事した時も、作業に入る前に「今までどうやって遠隔地で仕事を進めてきたのか」をプレゼンしていました。特に初めて仕事をする場合、「今まで自分はどういう風に仕事をしてきて、この仕事はどういう風に勧めていきたいか」を明確にしておくと、スムーズに仕事を進めることができます。 仕事、特にその上でのコミュニケーションをうまく進めていくためには、信頼と共通認識が必要だと思ってます。信頼は当たり前の話ですが、開発を進める上での共通認識についてはあまり重要視されることが無い気がしています。 仕事をする上ではコ
プログラミングの光景：第1回 デバッグについて｜gihyo.jp
プログラミングに関する雑多なあれこれ 今号から、「プログラミングの光景」と題して連載することになった高林と申します。プログラミングは趣味として、仕事として、かれこれ10年ほど行ってきました。本連載ではプログラミングに関する雑多な事柄について書く予定です。 第1回は、プログラミングとは切っても切れない関係にある「デバッグ」について取り上げてみようと思います。 デバッグの時間 ソフトウェア開発において、デバッグに要する時間は相当のものです。プログラマとしては「いやいや、自分はそれほどデバッグに時間を使ってないよ」と否定したいところですが、冷静に考えてみると、現実には自分が考えているよりも（そうであってほしいと考えているよりも）デバッグに時間を要しているように思えます。それに、バグは他人が書いたコードに混入していることもあるので、たとえ自分がバグを入れなくてもデバッグするはめになります。 デバ
まつもと直伝 プログラミングのオキテ---目次 - まつもと直伝 プログラミングのオキテ：ITpro
第0回 あらためてRuby入門 まつもとゆきひろ氏自身による「Ruby入門」をお届けします。日経Linuxの連載開始前の特別企画（2005年4月号）として，Rubyが他のスクリプト言語やオブジェクト指向言語とどこが違うのか，なぜ便利なのかを中心に解説してもらったものです。 ● 基本と他言語との違い ● 実装とRuby誕生の秘密 第1回 プログラミングとオブジェクト指向の関係 プログラマを目指す人々の中にも，「オブジェクト指向は難しい」とか，「なかなか分からない」という印象を持つ方が多いようです。そこで，Rubyを題材にオブジェクト指向という考え方について説明していきます。 ● その1 ● その2 ● その3 第2回 抽象データと継承 オブジェクト指向プログラミングを構成する3原則のうち，前回は「ポリモーフィズム」を学びました。今回はオブジェクト指向の歴史を復習した後，残りの「データ抽象」と
へ〜たのめも:Google のソフトウェア・エンジニアリング - livedoor Blog（ブログ）
2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は本社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Google のプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日本など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同
ネットの時代には「知識量・記憶力」よりは「適応力・応用力」の方がずっと大切
先日の「習作UI: 縁日の金魚を再現してみた」というエントリー。特に深い意味もなく作ったのだが、ソフトウェア・エンジニアを目指す学生さんのためにひとこと付け加えておきたいのは、この業界で本気で成功しようと思ったら、この程度のプログラムは、シミュレーションの専門家でなくともサクッと作れるように自分を鍛えておかなければいけない、ということ。 この業界で働きはじめると、担当した仕事によって、データ解析・Java・３D・シミュレーションなどのある特定の分野のプログラミングの経験を積むことになる。そういった経験を通して特定の分野を深堀りしてエキスパートになるのはおおいに結構なのだが、往々にして落ち込んでしまうのが「ボクはJavaのエキスパートだからRubyではプログラムは書かない」、「シミュレーションのことならそれに詳しいエンジニアがいるんだからその人に頼んで」、「今からFlashを勉強している時間
どうしてプログラマに・・・プログラムが書けないのか?
Jeff Atwood / 青木靖 訳 2007年2月26日 レジナルド・ブレイスウェイトが書いていることを読んだとき、私はそんなわけないだろうと思っていた。 私と同様、この著者は、プログラミングの仕事への応募者200人中199人はコードがまったく書けないということで苦労している。繰り返すが、彼らはどんなコードも書けないのだ。 彼が引用している著者というのはイムランのことで、彼は単純なプログラムも書けないプログラマをたくさん追い払っているということだ。 かなりの試行錯誤の末に、コードを書こうともがいている人たちというのは、単に大きな問題に対して苦労しているのではないことがわかった。やや小さな問題(連結リストを実装するというような)に対して苦労するということでさえない。彼らはまったくちっぽけな問題に苦労しているのだ。 それで、そういった類の開発者を見分けるための質問を作り始め、私が｢Fizz
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://d.hatena.ne.jp/suroyuu/20080304
日経PC21 / エクセル - 勝手に設定される「ハイパーリンク」を解除したい！