知能と技術的特異点 - Sideswipe
これは 人工知能アドベントカレンダー の1日目の記事です。 はじめに 本アドベントカレンダーは25日間をかけて、知能、あるいは人工知能（あとで触れますが、正確には汎用人工知能を指す）について、それを理解しまた実現する技術について、広く浅く解説と紹介をします。 ここでいう人工知能は、後述するように一般に考えられている人工知能(Artificial Intelligence) ではなく、汎用人工知能 (Artificial General Intelligence, AGI) であり、一言で表すなら、「人と同じような知性をもった機械」を考えます。ただし、以降は特に断りのない限り、AGIの意味で単にAIといいます。AIとAGIの違いについては、以前の記事 人工知能は Deep Learning によって成されるのか？ - Sideswipe を御覧ください。こちらは今回のシリーズで扱う内容の概要
Web エンジニア 6 年 5 ヶ月やってたどり着いた価値観 | Born Too Late
Web エンジニアとして経験を積むことでいくつかのプログラミング言語やツール・ミドルウェアの使い方を覚えたりもしたけど、それらのうちいくつかは 10 年後ぐらいには陳腐化してしまっているかもしれない。 だけどそれらを通じて身につけた価値観や哲学はもっと普遍性を持っているような気がする。 大学を卒業し、Web エンジニアとしての職を得て 6 年 5 ヶ月、日数にして 2344 日経ったので、現時点での頭の中にあるもののダンプを残しておく。 どこかで聞いたようなことばかりで新鮮味はないと思うけど、自分で実感を持ってたどり着けたことには意味があるはず。 プログラミングについて 言語はいろいろなものを試してみる 毎年新しい言語に挑戦せよ、というのは確か dankogai さんの講演をまとめた記事で読んだはずなんだけど、記事が見つからない。 キーワードをもとに検索してみたら達人プログラマーにもそうい
プログラマ向けに書かれた「Soft Skills」という本がすごいという話 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
日本語版がでました。すぐ買うべし。 SOFT SKILLS ソフトウェア開発者の人生マニュアルposted with amazlet at 16.05.18ジョン・ソンメズ 日経BP社 売り上げランキング: 1,272 Amazon.co.jpで詳細を見る Soft Skills: The Software Developer's Life Manualは残念ながら日本語訳が出ていない。でも英語でも読む価値はある。とても平易な英語で書かれてる。どこかの出版社さん翻訳だして欲しい。空前のブームになるに違いない。 Soft Skills 。alc.co.jp によればソフトスキルは「対人的な交渉・指導・意思疎通などをうまく行える能力（または知恵）」のことらしい。そのタイトルからも分かる通り、プログラマ向けに書かれた本だがほとんど技術の話は書かれていない。プログラマとして生きていくための技術以外
今日のポエム: なぜ、その抽象化は失敗してしまうのか - Line 1: Error: Invalid Blog('by Esehara' )
近況 打ち捨てられた過去について 要旨 この記事を興味深く読む一方で、やはり違和感を覚える人も多くいるようで、自分もその一人だった。恐らく、この違和感は、「抽象化」が「具体性を奪取していくもの」といったような対立項として述べられているからだ、というように思われる。しかし、果たして具体性無しに「抽象化」することが有益なことなのだろうか。それが一つの違和感のように思われる。 本文 プログラミングの世界には、YAGNI原則(You ain't gonna need it)というものがある。また、YAGNIという言葉を使わなくても、「過度な汎用化が足を引っ張る失敗例」というのは、プログラマとしての心構えを書いた本の中で、ちらほらと自嘲気味に述べられることがある。 僕も、一度そのような失敗例を見たことがあるけれど、なぜこういう失敗が起こるのか。確かにデザインパターンで組み立てられたアーキテクチャは「
Lisperはプログラムに何を見るか - 八発白中
男子校に通う中学生の僕らにとって「家庭科」の授業は休憩時間のようなものだった。 僕の中学校には家庭科室というものがない。だから、いつもの教室で野菜の種類やそれに含まれる栄養素なんかを教わるというだけの、正直退屈な授業だった。話される内容はどれもただ暗記すればいいものなので、授業を聴かなくても定期試験前に教科書を読み通すだけで九〇点は取れる教科だった。 学校としても文科省の教育課程に沿うがためだけに時間割にねじ込んでいるに過ぎなかったと思う。特別教室がないことでも真面目にこの教科を取り扱う気がないことがわかるし、生徒の方でもその学校の態度を敏感に感じとっていた。 そんなやる気のない男子学生の前に立って話すのは教師にとって楽しいものではなかっただろう。僕らの先生は、落ち着いた雰囲気でどこかしたたかさのある、髪の長い女の先生だった。 その日も彼女はいつも通り、キノコに含まれる何々という栄養素が、
企業は有名エンジニアや有名コミッタを高額報酬で雇うべきか？【連載:村上福之】 - エンジニアtype | 転職type
日々流れてゆく膨大な情報量の中からおいしいネタを敏感に察知し、ネット界隈を賑わせてくれるWeb業界の異端児・村上福之氏。同氏独自の経験と価値観から、「キャラ立ちエンジニア」の思考回路を紐解いていく。 株式会社クレイジーワークス 代表取締役 総裁 村上福之（@fukuyuki） ケータイを中心としたソリューションとシステム開発会社を運営。歯に衣着せぬ物言いで、インターネットというバーチャル空間で注目を集める。時々、マジなのかネタなのかが紙一重な発言でネットの住民たちを驚かせてくれるプログラマーだ 先日、ソフトウエアエンジニアの中で、この話題がバズってましたね。有名なコミッタさんを雇おうとしたら、会社の偉い人が「プログラマーに年800万円なんてのは馬鹿げてる! プログラマーに出せるのは年400万円までだろう!」と言い放ったという話です。 >> 著名なOSSコミッタを年収400万円で雇おうとした
コーディング面接の例 - soutaroブログ
プログラマの面接をするときには実際にコーディングをしてもらうべきという話は良く聞くが、もうちょっと細かくどういうお題を出したら良いかとか、どういう風に評価したら良いかとかの話はあんまり聞かない気がする。せっかくなので、ユビレジでの面接で私がコーディングについて確認するときのパターンを、いくつか紹介してみようと思う。 実際にコードを書いてもらうパターン 候補者がどのくらいプログラミングできそうかの予備情報がない場合に、簡単なアルゴリズムを書いてもらうことが多い。例としては、 Linked Listを書いてください Stackを書いてください など。ここで、おもむろに int main(int argc, char* argv[]) { などと書き始める人は、あまり良い印象をもたれない。 class Stack などと書き始める人は上よりは期待できる。 このとき、わざと出題で詳細をあまり明らか
Teach Yourself Programming in Ten Years 日本語訳
以下の文章は、Peter Norvig による Teach Yourself Programming in Ten Years の日本語訳である。 本翻訳文書については、以下の方々にご教示を頂きました。ありがとうございました。 Shiro Kawai さん：誤訳の訂正 三好博之さん：誤訳の訂正 竹中明夫さん：2001年7月改版分の訳、誤訳の訂正（共訳者にクレジット） Toshihiko Ono さん：誤訳の訂正 アクビさん：訳注３に関する情報 どうしてみんなそんなに急ぐの？ どの本屋に足を運んでも、『7日で学ぶ Java』といったハウツー本を見かけるし、そのそばには Visual Basic や Windows やインターネットなどについて、同じように数日や数時間で学べると売りこむ本が無限のバリエーションで並んでいる。Amazon.com で以下の条件で検索してみたところ、 pubdate
SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ
10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変
僕は結城さんのことが好きなんだなぁ - 西尾泰和のはてなダイアリー
僕は結城浩さんのことが好きなんだなぁ。彼の書いた「文章を書く心がけ」は自分が執筆をするときにも何度もお世話になった。彼の日記などに時々かいま見える「読者によりよいものを届けよう」という真摯な態度には好感を感じる。以前の僕は宗教と名の付くものが全て嫌いだったのだが、敬虔なクリスチャンである彼の日記を読んでいるうちに、その嫌悪感が軽減した。結局のところ、どんな集団にもいい人もいればわるい人もいるということなんだ。 では、わるい人に対してどう対処するのがよいのか。1601年生まれの哲学者バルタザール・グラシアンはこう言っている。 人の中傷は無視せよ。黙殺で答えることが賢明だ。身の潔白を明かそうとしてペンの力に訴えてはいけない。書かれたものはいつまでも残るから敵を懲らしめるどころかその名を留める手助けをしている。忘却に勝る復讐はない。 なるほどね。400年も経つけども、人間の社会はあんまり変わって
Think IT著者陣がおくる デザインパターン必携書籍 厳選6冊
スレッドの食わず嫌いを克服する入門書 今回は、『GoF以外のデザインパターン』第3回を掲載する予定でしたが、諸般の事情により予定を変更して『著者陣がおくる！デザインパターン必携書籍 厳選6冊』と題した書評記事をお送りいたします。 デザインパターンを学ぶ上で、これは読んでおいたほうがいい！という書籍を、5月特集「デザインパターンを学ぶ」の著者陣に紹介していただきました。 ------------------------------------------------- 評者：安藤 崇周（オージス総研） 『増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編』 結城 浩 著 価格：4,935円（税込） 発行：2006/3 ソフトバンククリエイティブ Amazonのページはこちら→http://www.amazon.co.jp/dp/4797331623 「スレッドが苦手」「スレ
Practical Scheme
Shiro Kawai 11/20/2000初出、3/29/2002更新 Cに慣れたプログラマがSchemeのコードを見て面食らうことのひとつは、 無名の関数やローカル関数の多用だろう。 特に実行効率に敏感なプログラマにとっては「関数呼出しは高価」 という感覚が染み着いているため、 至るところに散りばめられたlambdaに眉をひそめてしまうようだ。 しかしSchemeにおいては、 コード上に関数が書いてあるからといって 実行時にスタックフレームの生成やレジスタの退避などのオーバヘッドが起こるとは限らない。 例えば関数の最後に別の関数を呼び出す末尾呼び出し(tail call) はただのjumpインストラクションに置き換え可能だ。 ここでは、Cプログラマを対象に、 lambdaで生成される関数群が実際にどのように実行され得るのかを書いてみたい。 (なお、Schemeの規格ではlambdaフォ
技術的負債というメタファ - みねこあ
技術的負債についてはじめて知ったのは、マーチン・ファウラーの「技術的負債」というエントリーでした。 技術的負債 システムに新しい機能を追加するとしよう。2つのやり方があるはずだ。ひとつは、早いけれど、ぐちゃぐちゃになるやり方（将来、変更が困難になることは分かっているよね）。もうひとつは、キレイな設計だけど、導入に時間のかかるやり方。 「技術的負債」とは、Ward Cunningham が作ったメタファーである。上記の問題について考える際に、この言葉が役に立つ。このメタファーを使うと、早いけれど汚い解決方法は（ファイナンなどスの負債と同じく）技術的な負債が発生する、ということになる。 通常の負債と同じく、こちらの負債も利子を払う必要がでてくる。 (中略） このメタファーを使うと、早いけれど汚い方法がなぜよく使われるのか、ということを説明できる。ビジネスの世界で市場機会の優位性を得るために負債
優秀なエンジニアがいなくてもやっていくために - Line 1: Error: Invalid Blog('by Esehara' )
ITの世界には「銀の弾丸は存在しない」という合言葉がある。これはどうやら狼やドラキュラを退治するときの道具が「銀の弾」らしく、古典的な名著であり、未だに参照され続けている『人月の神話』という本に収められている論文から来ているらしい。なぜ、「銀の弾丸は存在しない」と言われるのかというと、ある諸問題に関して一気に片付けられるような、そういう解決策は無い。少なくともそれらの問題に関しては泥臭く、忍耐を持って接しないといけないという話だ。川を綺麗にするためには根気よく缶を拾ったりしなければいけないのと似たようなものだろう。 元のドラキュラの話を知らないので、Wikipediaで聞きかじりに語るのだが、そもそも「銀の弾丸」といったところで、その「銀の弾丸」を使う存在というものがいる。ドラキュラの場合、それが「ヘルシング教授」である。ヘルシングといえば平野耕太の漫画を思い出すが、どうやら原作のドラキュ
クソコードでも公開した方がいいんじゃないかって話 - Konifar's WIP
昨日のDroidKaigiの@operandoOSさんのセッション Android学ぶを君へ。生き抜くためのナレッジ共有の中で『ひたすらクソコードを書く』という話がありました。 もちろんこの話はほんの一部でしかないんですが、とても印象に残りました。 誰と話したか忘れてしまったんですが、懇親会で 「クソコードでも公開した方がいいんじゃないか」みたいな話が出て、なるほどなぁと思ったのでちょっと思考を整理しておきます。 書けば何がクソコードかわかってくる 何も書かないよりクソコードでもいいからまず書いてみる方がいいと思います。 そもそもクソコードっていうのはよいコードの基準があってこその価値観なんですよね。書かなくても何がよくて何がクソかわかるよって人もいると思うんですけど、自分はやっぱり頭で理解するより書いて理解する方が腹落ちしやすいです。 例えば、GoFのデザインパターンはよくある問題を
コードに対してコメントを書くと実装に関するコメントになる - きしだのHatena
おととい、渋谷JVMというイベントがあって登壇させてもらったんですが、そのあとビール飲んでるときに、ぼくが「コード書く前にコメントだけ書くのいいよね」と言ったあとの返答としてきょんくん(kyon_mm)が言った言葉。 全体としては 「コード先に書いてそのコードに対してテストを書くと実装に対するテストになるし、コードを先に書いてそのコードに対してコメントを書くと実装に対するコメントになる」 という感じ。 ここに至るまでの話もおもしろかったんだけど、ここでは、コメントについて書いてみます。 まず、実装に対するコメントってどういうのかというと、こういうの。 id = findId(name); if(id == -1){ // idが-1だったとき登録 register(name); } いやそれはコード見ればわかるから、ってやつですね。 これは、こうやるとより適切です。 id = findId
ソフトウェアの技術革新って必要なのかな？
プログラマの間では昔から、この手法は処理が遅いだとか、無駄が多いだとか、再利用を心がけろだったりとか 様々なやり方で、ソフトウェアをチューンナップして処理速度を上げるためのやりとりが際限なく 繰り返されているけど、だいたいどれもハードウェアの技術革新によって記録は塗り替えられてないかな。 そりゃ、ミドルウェアレベルでは全てのパフォーマンスに影響してくるので、ちまちまとした 改良が加えられるべきなんだけど、ソフトウェアレベルではどうなの？ Ｉ／Ｏに引きずられるから、Ｉ／Ｏの処理は最低限に抑えるってのが昔から定説だけど それもSSDの登場で、かなり緩和された感があるし、結局プログラマの努力って ハードウェアの努力には追いつかないし、無駄なのではないかと思ってる。 １０年前を支えたプログラム技術で今も生きているものってある？ オブジェクト指向とかプログラムのわかりやすさを追求したものは別でね。速
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長文日記
http://kwatch.houkagoteatime.net/blog/2015/08/30/why-is-functional-lang-so-hard/
㊣十大正规足球外围app-bsport体育娱乐官网入口