『マンガでわかる！関数型プログラミング』という漫画を連載することになるようです - Line 1: Error: Invalid Blog('by Esehara' )
近況 ふとした瞬間に虚しくなることがある いきさつ 今年、秀和システムから関数型プログラミングに関する本が出て、良くも悪くも、その本が注目を集めることになってしまいました。そんな中で色々な人が反応していましたし、自分もこのようなかたちで感想を書きました。 一方で、このような本を書かれるくらいであるならば、自分で真っ当な本を書けばいいわけだし、技術書を書くことなんて、そんな敷居の高いことではないというカウンターもあり、個人的にはそれも最もだなあ、という印象がありました。その中で自分なりに関数型プログラミングについて理解したことを元にQiitaに駄文をアップしたりしていました。間違ってたら、誰かが訂正してくれるだろうし、そのほうが自分にとって勉強になるだろう、と思うので。 ですが、「関数型プログラミング」というのは「なんだか難しい」という印象を覚えるのも事実のようです。実際に、最新の『Soft
新著が出ます：『SQL実践入門』 - ミックのブログ
4月中旬ころになりますが、新著が出ます。SQLのパフォーマンスを主題にした本で、実行計画を読むことで、なぜこのSQLは遅いのか、あるいは速いのかをデータベースの内部動作まで把握して理解しよう、という趣旨です。 リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、本当は実行計画などという手続レベルの世界をユーザが覗き見るのは、本末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体本当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。 以下まえがきと章立てです。
Railsアプリやgem作る時にいつも入れているgem一覧 - くりにっき
id:joker1007 さんに触発されました。 Ginza.rb 21回の発表資料。rails_adminのつらみとオススメgem達。 1年間で10個以上アプリやgemを作っている中でよく使うgemをまとめてみます Railsアプリ（rails new した直後に必ず入れる） annotate https://github.com/ctran/annotate_models modelのソースの先頭にテーブルのスキーマ情報を付加してくれるgem。いちいちschema.rbを見に行く必要がなくなるので超ベンリ こんな感じ # == Schema Information # # Table name: plugins # # id :integer not null, primary key # name :string # title :string # version :string #
コンピュータシステムの理論と実装
コンピュータを理解するための最善の方法はゼロからコンピュータを作ることです。コンピュータの構成要素は、ハードウェア、ソフトウェア、コンパイラ、OSに大別できます。本書では、これらコンピュータの構成要素をひとつずつ組み立てます。具体的には、NANDという電子素子からスタートし、論理ゲート、加算器、CPUを設計します。そして、オペレーティングシステム、コンパイラ、バーチャルマシンなどを実装しコンピュータを完成させて、最後にその上でアプリケーション（テトリスなど）を動作させます。実行環境はJava（Mac、Windows、Linuxで動作）。 ● 本書のサポートサイト ● 本書で使用するツール「Nand2tetris Software Suite」 ● 「Nand2tetris Software Suite」のチュートリアル 目次 賞賛の声 訳者まえがき：NANDからテトリスへ まえがき イント
そろそろ「プログラマー35歳定年説」を徹底論破しとくか - 書架とラフレンツェ
世の中に流布している「プログラマー35年定年説」は、大きく以下の3つに分類できる。 プログラマーは激務なので、35歳を過ぎると体力低下のために続けられなくなる(体力低下説) プログラマーは常に新しい情報を吸収しなければならないが、35歳を超えると脳の働きが低下して新しいことを覚えられなくなるために続けられなくなる(学習能力低下説) プログラマーは35歳を超えると開発ではない業務を求められるようになるので、技術職としてのプログラマーのキャリアが途絶える(マネージメント原因説) 以下、ひとつずつ検証していく。 体力低下説 まず1つ目の「体力低下説」だが、これについてはそれほど深く考る必要がなさそうに思える。周知の通り気力や体力には個体差があり、若くても元気がないひともいれば歳をとっても元気なひともいる。また、35歳あたりの体力低下の原因としては、単純な加齢というよりも生活習慣の要因の方が大きそ
2014年、春のGit事情 - fujimuradaisuke's blog
なんとなく最近どんな感じでGitを使っているか、適当にリストアップしてみた。 よく使うやつ git status git status --branch --short にしている。変更されたファイルが出る。とりあえず何をしたかざっくり把握する用。sにエイリアスしている。一日100回くらい実行しているのではないか。 git diff 特にオプションは指定していない。何をしたかしっかり把握する用。dにエイリアスしている。一日50回くらい実行しているのではないか。 git grep バージョン管理しているファイルから渡した単語を含む行を検索、表示。関数の検索などあらゆる場面で超便利。オプションは --line-number --show-function --color --heading --break がオススメ。 git ls-files バージョン管理しているファイルのファイルパスを表
ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ
プログラミングの上手さってどういう意味なの？ : IT速報
1: 以下、名無しにかわりましてVIPがお送りします 2013/12/20 14:10:01 ID:ICWX2V5W0 マジでプログラミングcから始めたいんだけど意味が分かりません。 マジで上手いってどういうこと？ 全部覚えたら皆同じなんじゃないの？ コードを書く速さなの？ 9: 以下、名無しにかわりましてVIPがお送りします 2013/12/20 14:13:47 ID:ES8tiBOo0 発想力 3: 以下、名無しにかわりましてVIPがお送りします 2013/12/20 14:11:12 ID:QdrRlCyk0 美しさ 4: 以下、名無しにかわりましてVIPがお送りします 2013/12/20 14:11:56 ID:aAzEn7eY0 汚いコードと綺麗なコードがある 15: 以下、名無しにかわりましてVIPがお送りします 2013/12/20 14:17:31 ID:nv+JQNN
エンジニアの成長と反抗期 | 外道父の匠
最近、後進の育成について考える機会があります。 ある時、こんな状況で困ることがあるんだけど、どう思う？ と聞かれて飛び出した言葉【反抗期】について考えてみます。 相談内容 育成や生産効率をテーマにした会食にて、相談された内容は あるエンジニアが実力以上に過信して自己評価する やたら特定の技術に拘って、結局リリースが伸びたり改悪したりする ・・・んだけど、これは何なんだろう、どうしたらいい？というもの。 これに対し、自身の辿った道も思い直して出した返答が 『それは、エンジニアの反抗期だよ』 もちろんこれは、こどもがヤダヤダ拒否する（＝仕事したくない）本来の意味ではなく 逆に、やり過ぎによる失敗経路への舵切りのことを指しています。 聞き手はこれで非常に納得がいった様子。 反抗期とは おそらく3～5年目の時期に、技術やアイデアに偏ったものを創り出すことがあります。 そして、閑古鳥／改悪サービスに
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
ゲーム開発 プロジェクトマネジメント講座
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4©SQUARE-EN
いまだにユニットテストって受け入れられないんだろうな - 個人的なまとめ
色んな所で「テスト(ここではユニットテスト)を書かないのは小学生までだよねー」とか、もっと汚い言葉で言われたりするけど、いまだにうちのチームでは自分だけしか書かない現状が悩ましい。 Jenkinsさんが激おこになっても誰も何も反応しない。 もちろん、全部が書けるとも思ってないので、自分が不安なところとか、変更が多く入りそうなところとかを中心に書くようにしてる。一種の精神安定剤みたいなもん。 あるとき、一緒に働いてるエンジニアさん(ここではAさんとしておこう)に「ここ難しそうだから、テスト書いたほうがいいですよ」って話をしたら、「じゃぁ、工数かかっちゃいますね」って言われて結局書いてなかったな。 そうだよ。ユニットテスト書いたら工数かかるよ。それは純然たる事実。でも、再利用できないチェックシートを作ってやるよりもいいと思うんだけどね。しかもこの前に見せてもらったこのチェックシートも運用レベル
C++で作るWebアプリケーション
14 views Boost.勉強会 #12で発表した「C++で作るWebアプリケーション」 ... More… Boost.勉強会 #12で発表した「C++で作るWebアプリケーション」 C++をJavaScriptにコンパイルするコンパイラ Emscriptenを使ってC++でブラウザ上で動くアプリケーションを開発する方法を解説します C++で作るWebアプリケーション Presentation Transcript そんなC++の進出を拒んできた領域C++はとてつもなく汎用的な言語である2013年6月22日土曜日 WEB2013年6月22日土曜日 サーバ クライアントこっちは割とどんな言語でも書ける問題はこっち2013年6月22日土曜日 JavaScriptWEBブラウザで動く物を作るために長らく使われてきた言語近代的な多くのブラウザが共通して対応している唯一の言語2013年6月22
全IT関係者が知っておくべき「1-copy-snapshot isolation」 - 急がば回れ、選ぶなら近道
snapshot isolationを分散環境に適用する場合の「基本」の内容のまとめになります。（基本自分用のメモなので、間違っていたらすみません） まずワーディングの整理 ・snapshot isolation TXの分離レベルとしてのsnapshot isolation（以下SI）は、現在のRDBMSのTX管理では、ほぼ実装的にはデファクトと見ていいと思います。ただしANSIの規定のISOLATION_LEVELには定義がないので、どのあたりに位置づけるのかは、DB実装のそれぞれの取り扱いにより異なります。とはいえ、どのDBでもほぼSERIALIZABLEに近い位置づけにしているところが多いですね、というか、SI（特にSerializable SI）ぐらいでないとserializableに現実的には近づけないというのが実態かと思います。（勿論理論上はS2PLで実装は可能ですが、まぁパフ
上司「君、来週からiOSね」 - ReDo
と、言われた際にどう最初の一週間を過ごすべきか、という話です。 ○はじめに MBAを買って本1冊Xcodeで必死に写経したことを「俺iOS個人的にやったことありますし余裕ですしおすし」と自慢すると半年から１年ぐらい経って忘れたころにこうなります。気をつけましょう。 # 自分はiOS歴3weekぐらいの雑魚な上に多大にジョーク成分が含まれておりますので応用には留意願います。 流行に乗って買うだけ買って使っていないApple製品がある際には月曜朝からこれ見よがしに机の上に広げてください。 まわりに「俺iOS始めたしお前らAndroidとかにはつきあってられないし」というアッピルは邪魔をされないために効果的です。 ・Xcodeでの開発にはMacが必要です ・シミュレータではできないことがあるためiOS実機があると良いです。 ・最新のiOS 6.xが動作しないデバイスの場合は候補としてイマイチです
オープンソースで必要な英語力を調べてみた
最近、mrubyのIssuesを英語で書くのが厳しく、やっぱり英語は勉強しなきゃなと日々痛感しています。 勉強するにしても普通の英語とは違うので、Issueを英語で書くためにどれぐらいの単語力が必要なのか調べてみました。 GitHub上のmrubyとnodejsのIssuesをダウンロードして形態素解析をして、単語の頻度をグラフにしてみました。 ものすごく偏っていることがわかります。 ここから1000だけ切り出してみます。 これを見ると3-500でほとんど部分をカバーできそうです。固有名詞もあるからもっと少ないはず。 これをベースにして「300語で書くオープンソースの英語」とか出来ないかな？ あとは、Phrasal verbs(get into, put onみたいなヤツ) なんだけど、代表的な物を公開しているリストないかな？それもランキングできると面白そう。 なお、この単語数は形態素解析
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
言語処理100本ノック 2015
モデリングもしないでアジャイルとは何事だ