Rubyを使って「なぜ関数プログラミングは重要か」を読み解く（改定）─ 前編 ─ 但し後編の予定なし
２年ほど前に書いた記事を電子書籍化して「M’ELBORNE BOOKS」で販売するために全体的な見直しを行なって入稿する段になって、これにはベースとなっている他者の論文があって言ってみればこの記事はそのマッシュアップになっているんだけれども、その著者の許可もなくその表現が全く別物だとしてもその主張のあらすじが残っている限りにおいてこれを販売することが果たしていいことなのかという思考に遅ればせながら陥り、それが仮に法的に問題ないとしてもなんだか一表現者の行為としての妥当性を幾分欠いているという結論に至って販売を思い留まった。かと言って折角書き直したものをこのままお蔵にするのもなんだか寂しいなあという気分も一方であり、まあ原作者の意に反したものでもないだろうからブログの記事なら許してくれるよねもう２年前にも書いちゃってるしという勝手な解釈の下、ここにその記事を公開しましたのでお時間の許すRub
オブジェクト指向プログラミングの教え方？ | システム設計日記
技術者仲間で話していたら、4月入社の新人に、オブジェクト指向プログラミングをどうやって教えたらよいか？、という話になった。 想定している言語は Java。 ■動物・犬・猫モデルの説明から ■基本用語の説明から：「カプセル化とは」「継承とは」．．． ■サンプルコードから： System.out.println( "hello world" ) ．．． どのパターンでもうまくいかなかったので、今度の新人研修では何か工夫したいね、という話。 結論から言うと「これだ」というアイデアがでたわけではないが、話の内容は、いろいろ興味深かったのでメモ書き。 Java はオブジェクト指向の言語なの？ Java は、ある意味 C言語の仲間。ある側面はほとんど同じ言語。 ・int, long （プリミティブなデータ型） ・配列操作 ・if/for/return ここだけ見れば、C言語のまま。つまり命令型、手続き
サーバエンジニアが「開発力」を持つ意味 - Gosuke Miyashita
初出: Software Design 2009年4月号（2009年3月18日発売） 宮下 剛輔 サーバエンジニアの定義 本特集では、サーバエンジニアが開発力を持つことにより、どのような力を得ることができるのか、日々の業務にどのように役立てることができるのか、具体例とともに紹介します。 本題に入る前にまずはここでのサーバエンジニアの定義を明確にし、特集全体のコンセプトについて説明します。 クライアント/サーバ型のシステムを考える場合、サーバ側は大まかに以下のようなレイヤーに区分できます。 アプリケーションレイヤー ミドルウェアレイヤー OSレイヤー ネットワークレイヤー これらのレイヤーのうち、ミドルウェアレイヤーとOSレイヤーを主担当とするエンジニアを、本特集記事でのサーバエンジニアと定義し、対象読者と想定します。その中でも特に、オープンソースソフトウェア（OSS）をメインで扱うエンジニ
へ、変態っ！！読めないからやめてっ！bit使ったデータ構造・アルゴリズム実装集 - Negative/Positive Thinking
この記事はCompetitive Programming Advent Calendar Div2012の2日目の記事です。 12月20日追記： Darseinさんが20日目の記事で、ビット演算についての詳しい説明を紹介してくださっています！必読ですね！！！！：） はじめに Y＾´ ∨／／ ／,∠ ,. ' ／l／／／ ／, ' , '／ ! ｜ ｌ }´ 〈 〉 変 〈/ , ' ／／￣｀>< ／／／ ／／／ _,.=‐|'"´l ｌ〈 変 / 〈 態. ∨, '／l| ,.'-‐､｀/／｀7/ ／''"´__ ｜ ﾊ l丿 態 { 人） ! ! （／! |ヽ〈_ ・.ﾉ〃 〃 ／ '／⌒ヾ.! ,' !く ! ! （_ ト､__／ ヽ､_,.イ ／ｌ ｌ ｜:::::::｀｀`/:::::／...´..
Ruby の Proc オブジェクトと Method オブジェクトの違い (proc, lambda, ブロック, メソッドについて) - vivid memo
プログラミング言語 Ruby 作者: まつもとゆきひろ,David Flanagan,卜部昌平(監訳),長尾高弘出版社/メーカー: オライリージャパン発売日: 2009/01/26メディア: 大型本購入: 21人 クリック: 356回この商品を含むブログ (129件) を見る Ruby には、手続きを表すオブジェクトのクラスとして Proc クラスと Method クラスの 2 つのクラスがあります。 Proc オブジェクト *1 にはさらに proc と lambda の 2 種類があって、それぞれどう違うかというのがちょっとややこしいと思います。 次の記事などは結構参考になると思いますが、『プログラミング言語 Ruby』 を読んでさらに理解が深まったのでここにまとめておきます。 Ruby の block、Proc、lambda を理解する - このブログは証明できない。 とりあえずまと
職業プログラマがFizzBuzz書けない理由
-- 追記@2012-08-08 09:20JST -- この速さなら言える。この前職場(派遣先)でプログラミングテストがあったのだけど、弊社社員の1/3がFizzBuzz解けなかったんだ… — papamitraさん (@papamitra) 8月 6, 2012 これ読んで工ｴｴｪｪ(´д｀)ｪｪｴｴ工となり、書いた。 -- 追記ここまで@2012-08-08 09:20JST -- あるいは、「FizzBuzz書けない奴m9(^Д^)ﾌﾟｷﾞｬｰ」のもにょもにょ感。 結論だけ、書く。 要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。そして知らないから。 さて、まずはこの問題解こうか。制限時間5分。 タイトル: Ants 問題
CTPC (College of Technology Programming Contest) 参加記
高専生向け競技プログラミングコンテストらしい。 http://koj.cms.am/contest/index.html 起きたら twitter の TL で話題になっていたので寝起きで参加しました。 結果: 400/1100点 (39/65位), 2 WA. といた順番は A→C→B→E. A の後 B は一見難しそうに見えて C を解き、その後他の問題を物色して E を解き始めたのだけど、 途中これはグラフ理論とか使うのかなあ、と思って物色を再開した所、実は B が簡単だった事に気づいて B を解き、時間が余った。E をもう一度見たら実は Time Limit 8 秒とか入力の制約を見るにシンプルな 探索でも通るだろうということで再度解き始めて、ギリギリで通した。 問題 A - Average http://www.atcoder.jp/problem/detail/151 改行区切
60%の人間はプログラミングの素質がない
Coding Horror: Please Don't Learn to Code Please Understand Learning to Code Coding Horrorで有名なJeff Atwordが、ある州知事が今年の目標としてプログラミングを習得することを挙げていることに対し、そもそも税金を払う我々市民は、政治家にはプログラミング習得以上に重要な、政治家にしかできない問題の解決を望む、よってプログラミングを学ぶのをやめてくれという記事を書いた。これに対して、反論が多数上がっているが、Jeffも読んでいるある論文をあげて、この議論の参加するためには、必ずこの論文を知っておくべきであると書いた人がいる。この論文は有名で、非常に興味深いので、全プログラマーが読むべきである。 ふたこぶラクダという名前で知られている有名な論文がある。この論文では、60%の人間にプログラミングの素質が
ふざけた変数名を使う奴は、ばかなの？ 死ぬの？ ：アルファルファモザイク
「ちょっと実装してみて」とサラッ肩越しに言われたので 関数名を別れた女の名前にして遊び半分でコードを書いたことがある。
良いネーミングをするために覚えておきたい英語のルール5つ - プログラマー幸福論
Photo by muraterturk こういった記事って、ネーミング規則や慣習の視点から書かれていることが多いんですけど、この記事では、英文法に視点を置いて、参考になりそうなことをいくつかピックアップしてみたいと思います。 「省略形は使わない」などの規約的なものは、各プロジェクトのルールに従えばいいので、ここでは書きません。あくまで英語という視点から書いているということを、ご理解ください。 Rule 1 : “検索”は名詞 一般的な英語辞書のルールでは「検索」は、動詞ではなく「検索する」が動詞になります。「検索」は、検索することの名称 だと考えられるため、動詞ではなく名詞として扱います。 英語辞書には、日本語の品詞ごとに表記のルールがあります。これが理解できていると、和英辞書などで品詞を意識して検索できるようになります。以下に、一般的な英語辞書の表記ルールをまとめてみました。 ＜各品詞
やっと理解できた！JSオブジェクト指向プログラミング再入門 | ゆっくりと…
既に多くの方が JavaScript のオブジェクト指向的側面についての解説を記事にされていますが、読み手側から見ると、例えばプログラミング言語への習熟度やオブジェクト指向自体に対する理解度がマチマチなわけで、私自身、「おお、なるほど！」 っていう、頭の中のスイッチがパチンッ！と入るような境地には達していませんでした。 かつて私も オブジェクト指向なJavaScriptプログラミングのススメ なんていう翻訳記事を書いてはいるのですが、正直なところ prototype.constructor の存在は知りませんでしたし、Function.call や Function.apply をどう使えばよいのかなどをちゃんと理解できてはいませんでした。 そんな中、2011年12月に書かれた Doc Center | Mozilla Developer Network の記事 オブジェクト指向 Java
Effective Scala
Effective Scala Marius Eriksen, Twitter Inc. marius@twitter.com (@marius) Table of Contents Introduction Formatting: Whitespace, Naming, Imports, Braces, Pattern matching, Comments Types and Generics: Return type annotations, Variance, Type aliases, Implicits Collections: Hierarchy, Use, Style, Performance, Java Collections Concurrency: Futures, Collections Control structures: Recursion, Returns,
OSに付属するシェルスクリプトを読んで技術を盗む
今回から、OS付属のシェルスクリプトを読んでいく。多くの人が使っているスクリプトを読むことで、シェルスクリプトならではの書き方、テクニックを身に付けることができるはずだ（編集部） 他人の技術を盗まなければ進歩はない 外国語をマスターするにも、楽器の演奏を覚えるにも、上達するにはただ練習するだけではダメだ。素晴らしいお手本を見つけて、よく観察し、何度もまねることが必要だ。お手本から技術を「盗む」ことが大切だということだ。 プログラミングでも同じことが言えると思う。文法を覚えて、ただひたすらプログラムを書くだけではなかなか上手にならない。スキルのある人のコードを見て、技術を盗もう。開発チームのメンバーそれぞれが書いたコードを持ち寄って、お互いに批評し合う「コードレビュー」に参加している、あるいはリーダーとして主催しているという人は多いと思う。このコードレビューも、人から技術を盗む良い機会と言え
開発者のマシンを英語環境にしない理由はもはや一つもない - Hidden in Plain Sight
2011年も終りが近づいた昨今、日本の市場が今後どんどんシュリンクしていくことは、もはや子供でも知ってる周知の事実なわけです。 そういう時代にあって、開発者が日本語環境のマシンを使い続けることの意味は、よくよく考えたほうがいいと思うわけです。 個人的には、「世界中で使われるサービスを作りたい」といってる開発者のマシンをみて、キーボードがJISだったりOSが日本語だったりすると、もうその時点でかなりガクッときます。 とくに完全なる国際化が実現されているMacなら、キーボードさえBTOでUS仕様にしてしまえば、アメリカで売ってるMacと100%同じものになります。逆に言うと、アメリカで買ったMacでも、そのまま何の問題もなく日本語が使えるわけです。（実を言うと、現在アメリカのApple Storeでは、日本語JIS配列のキーボードを選ぶことさえできるようになっています） 買ったばかりのMacを
プログラマー面接時の技術的な質問事項(アプレッソ版) : 小野和俊のブログ
技術者・SE・プログラマ面接時の技術的な質問事項というエントリをはてブで見かけたのだが、私もjavaプログラマーの面接を割とよくやっているので、よく質問する内容をまとめてみた。 (ちなみに、基本的にコーディング面接の形態を取っている) プロジェクトの性質にもよると思うが、私の場合には、情報処理技術者試験的に基礎が満遍なく抑えられているかどうかよりも、 すぐ答えが見つからないような課題に対して、きちんと自分でやり方を考え、対応することができるか 「変な」コードをコミットしたりしないか(見つけにくいバグを混入させるとか、汚いとか、遅いとか)といった点を重視している。 まず、何を知っているかよりも、どんなものを作れるか、どんなことができるか、という質問。 ここで強烈な回答が来る人は、たいていここより下の質問は「あー、はいはい」という感じでサラッと答えてくることが多い。 これまでに携わってきた開発
Free Computer, Programming, Mathematics, Technical Books, Lecture Notes and Tutorials
The Linux Programming Interface: System Programming Post under Unix/Linux Programming - System and Applications This book is the definitive guide to the Linux and UNIX programming interface - the interface employed by nearly every application that runs on a Linux or UNIX system. It provides detailed descriptions of the system calls and library functions. Embedded C Coding Standard (Michael Barr) P
2010-12-26
リアクティブプログラミングは、「時間とともに変化する値」＝「振る舞い」同士の関係性を記述することでプログラミングを行うパラダイムです。 GUIなどのようにインタラクティブなシステムや、シミュレーションやアニメーションのようにダイナミックに状態が変化するようなシステムを宣言的に記述することができます。 これらの「変化する状態」や「外部とのやりとり」が支配的なシステムは、純粋関数型言語が、その強みを発揮しにくい部分でもあります。 本稿では、リアクティブプログラミングが副作用を含む系を宣言的に記述することを可能にし、状態の管理という厄介な問題からプログラマを開放する可能性があることを示したいと思います。 （割と独自研究に基づく解釈ばかりなのでその点ご了承ください。あと例としてでてくるコードは、Pythonベースの擬似コードで具体的なライブラリに基づくものではありません。） Why Reactiv
The AATT Programming Language - かそくそうち
先日、kinabaさんと朗読劇を観に行ったときに話していたネタ言語を実装してみました。 元ネタ：「kinaba さんが Cryolite を洗脳してパターンマッチ厨に仕立て上げるリスト」 http://togetter.com/li/6990 確かにパターンマッチがあれば木の操作を簡潔に書けるのですが、 コメントにAAで木を書いておかないと何をやっているのかよく分からないので、 AAがそのままプログラムになればいいんではないかという発想です。 とりあえず、「ASCII Art Tree Transform」を略してAATTと呼ぶことにします。 「Tree」と言っても今のところ「赤黒木」専用です。 AATTのソースコードは次のようになります。 G P / \ / \ p U -> n g / \ / \ n 3 3 U ^ 大文字が黒ノード、小文字が赤ノード、数字は任意のノード(空ノード含む
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自分のための code を書こう
IDEA * IDEA
