Warning! Pylonshq.com has expired. If this is your domain name you must renew it immediately before it is deleted and permanently removed from your account. To renew this domain name visit http://www.NameBright.com
はじめに この文書は、 Steven Bird, Ewan Klein, Edward Loper 著 萩原 正人、中山 敬広、水野 貴明 訳 『入門 自然言語処理』 O'Reilly Japan, 2010. の第12章「Python による日本語自然言語処理」を、原書 Natural Language Processing with Python と同じ Creative Commons Attribution Noncommercial No Derivative Works 3.0 US License の下で公開するものです。 原書では主に英語を対象とした自然言語処理を取り扱っています。内容や考え方の多くは言語に依存しないものではありますが、単語の分かち書きをしない点や統語構造等の違いから、日本語を対象とする場合、いくつか気をつけなければいけない点があります。日本語を扱う場合にも
「コードの読まれ方が分かった」、工数見積もり精度向上に寄与:奈良先端科学技術大学院大学 森崎修司氏らが発表 「ソースコードの読まれ方の傾向がまた1つ明らかになった。これで派生開発、保守開発の工数見積もりの精度が向上する」――奈良先端科学技術大学院大学 森崎修司助教らの研究グループは、2009年9月~11月にかけて行ったソースコードリーディングのオンライン・ハンズオン、2010年1月、2月に行ったイベント「ソースコードリーディングワークショップ」、ほか3回におけるハンズオンの分析結果を発表した。 総計126人に、保守/派生開発プロジェクトを模した形式で複数のソースコードを読んでもらい、それぞれにかかった時間を計測、分析したところ、「ソースコードの読解時間はソースコードの行数だけで予測することは難しい」「大規模な変更の場合、コードレビューの経験があるとソースコードの読解時間を短縮できる」ことな
Python勉強し始めて一ヶ月くらいたったんで一度復習を兼ねてまとめてみようと思います。僕が今までPHPとかPerlとかJavaScriptを使っていて、Pythonはこうやるのかーとか、これは便利だなーと思ったところ、開発していてはまったところなどピックアップしてみました。 初めてのPythonを読んで初心者向け勉強会に参加した程度の知識です。とりあえず初めてのPythonがかなりいいのでこれ読むだけで大体基礎は習得できた気がします。基本的な文法の説明だけでなく、大事なことは何回も繰り返し書いてあったり、Pythonの思想などにも触れているのでなぜこういう実装になっているかということも理解できます。これオススメ。 尚、このエントリーではPythonのバージョンは2.5をベースにしてます(主にGoogleAppEngineで使ってるので)。間違えなどあったらツッコミお待ちしてます。 文法、
一口に「比較する」といっても色々な観点が考えられますが、ここでは、コードの読みやすさという点に注目して比べてみます。 人間が考えた処理内容・データ構造などを直訳的な表現で書けるか。(0は1月、1が2月、…なんてのは勘弁) 冗長な記述が少なくて済むか。 これらの点で言語ごとの違いが見えるような題材をなるべく選び、それぞれの言語で実装したサンプルコードを以下のページに並べてあります。 カテゴリ別 サンプルコード 基本的な処理 数値、日時 リスト(または配列) マップ(または連想配列、ハッシュ) クラスとインスタンス ファイルとディレクトリ、通信 並列処理(スレッド) その他 このサイトで取り上げている言語 言語名 サンプルコードの凡例 参考サイト
「きみの会社はJavaからScalaへ移行したらしいね。」 「ああ。」 「やはり、移行するのは大変だったろう。」 「そうでもないよ。開発者がみんなハッピーになれたからね。」 「それはいいな。」 「だが、再びJavaで開発することになったよ。」 「そりゃまた、どうしてだい?」 「Scalaになって、コードの行数が激減したからさ。」 「お気の毒に。」 「きみの会社はJavaからRubyへ移行したらしいね。」 「ああ。」 「やはり、移行するのは大変だったろう。」 「そうでもないよ。開発者がみんなハッピーになれたからね。」 「それはいいな。」 「だが、再びJavaで開発することになったよ。」 「そりゃまた、どうしてだい?」 「Rubyになって、人月計算がおかしくなったからさ。」 「お気の毒に。」 「きみの会社はJavaからObjective-Cへ移行したらしいね。」 「ああ。」 「やはり、移行する
2013年3月23日 ネタ コーダー・デベロッパー・プログラマーさん達はそのソースコードにわかりやすい説明書きを「コメント」として残し、後から他の人が修正・編集しやすいようにコードを書いていきます。Stackoverflowの中でなんだそりゃー!というコメントがまとめられていたのでいくつか翻訳してみます!「クライアントからのムチャぶり迷言集 」に続き久しぶりにネタ系記事です。楽しんでください! ↑私が10年以上利用している会計ソフト! プログラマーさん達の名誉のため、先に言っておきますが、全てのプログラマーがこういったコメントを残しているわけではありませんよ!「こんなの書く人いるんだー世の中いろんな人がいるもんだー」くらいに軽く読んでみてください! 自信を失したプログラマー達 自虐コメント多数! // ごめん。 /* お願い…動いてくれ… */ // このコードは最低だ。知ってるだろ?俺も
私の職業プログラマのとしての最大の欠点は、ソースコードに対して強い美意識を持たずにいられなかったところだろう。生来の生真面目な性格が災いし、私の基準で美しいとはいえないソースコードを敵視しすぎた。 ソフトウェア業界(特に受託開発業界)は、基本的に正直者が馬鹿を見る世界である。顧客(あるいは経営者)が、保守性というソフトウェアの最も重要な品質を正しく評価できないという、情報の非対称性が存在するからだ。 経営者やお客様は、ソフトウェアの品質を正しく評価できない。なぜなら、その人達は、訓練を受けたプロではないから。 言ってることは、かなりの部分、そのとおりだと思います。しかし、これは、ソフトウェアに限らず、普遍的な真実なんですよ。 あんなだめな仕事をしている人に比べて、自分は、ちゃんとした仕事をしている。でも、上司も経営陣もお客様もそれを認めてくれない。 これは、どんな仕事をしていてもあり得る話
2010年09月25日22:45 カテゴリLoveCode 私がソフトウェア技術者でもありつづける理由 一言でいえば、「自分に報い続けたいから」ということになる。 私がソフトウェア技術者をやめた理由 - Rails で行こう!私の職業生活でもっとも多くの時間を注いだのがソフトウェア作りだ。その作業に対して、実際のところ、好きとか嫌いとか一言で割り切れるはずがない。複雑な感情を持っているというのが正直なところだ。 以下に照らし合わせれば、その複雑な感情とやらそのものがお嫌いなのだろう。 私の職業プログラマのとしての最大の欠点は、ソースコードに対して強い美意識を持たずにいられなかったところだろう。生来の生真面目な性格が災いし、私の基準で美しいとはいえないソースコードを敵視しすぎた。 で、何をもって美醜を決めているかといえば、コルモゴロフ複雑性と、そこからの距離をお使いのようだ。 うるう年を計算
昨日、 人生の転機 - Rails で行こう! の中で「ソフトウェア作りが嫌いだ」と言い切ってしまったことが引っかかっている。 私の職業生活でもっとも多くの時間を注いだのがソフトウェア作りだ。その作業に対して、実際のところ、好きとか嫌いとか一言で割り切れるはずがない。複雑な感情を持っているというのが正直なところだ。 私の職業プログラマのとしての最大の欠点は、ソースコードに対して強い美意識を持たずにいられなかったところだろう。生来の生真面目な性格が災いし、私の基準で美しいとはいえないソースコードを敵視しすぎた。 簡単な例を挙げよう。 うるう年を計算するアルゴリズムを考えてみる。うるう年とは、「4で割り切れて、かつ100で割り切れない年。ただし、400で割り切れたら、やはりうるう年」である。 def leap_year?(y) (y % 4 == 0) && ((y % 100 != 0) |
スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見
2007年07月17日20:15 カテゴリ翻訳/紹介 怠翻 - プロジェクトがオワタことを告げる102の証拠 元ネタはこちら。 101 Ways To Know Your Software Project Is Doomed アジャイル系、XP系の基礎知識がないと、結構すべるかも。 上司がウォーターフォールプロセスを「アジャイルウォーターフォール」に改名したZE☆ コンサルタントと契約したよ -- いざとなったら責任を取らせるためZE☆ 連続統合鯖が「もうだめぽ。オワタ\(^o^)/」というエラーメッセージを出したZE☆ 設定ファイルにXMLを採用したRubyフレームワークをつくっちゃったZE☆ 最古参の先輩が、Martin Fowlerのことを「鼻っ柱野郎」ってよんでるZE☆ ソース管理システムの中に、共有ドライブのフォルダが山ほどあるZE☆ ♪だからは次は絶対勝つために質疑問答だけは最
そういえば、「Javaがつかえます」、という基準はどこにあるだろうか。 そんな考えをまとめてみた。 おいらの場合特定のプロダクトを使いこなせるというよりは、標準APIの基礎が広く薄くわかっているというレベルかなぁ。 たとえば暗記していてクラス名やメソッド名などすらすらでてくる、というのは望ましいけど、そうではなく、JavadocやIDEの補完、ネット上の情報見てそれなりにやれるというレベルを期待したいところ。どうせ、開発始めれば細かい使い方はわかるようになるし。 かなーりあまい基準で「そんなへっぽこレベルでできるといわれても困る」とおこられそうだけど。 言語の文法は基本抑えているというのが前提として以下のものが当てはまる人。 Java2Dがわかる Graphics/2Dをある程度触れる BufferedImageとVolatileImageの違いを理解している 日付処理がわかる Dateの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く