モナド: お前はもう知っている | Webシステム開発／教育ソリューションのタイムインターメディア
はじめに 過去に私がHaskellを学び始めた時、 真っ先に疑問に思ったことはモナドの存在だった。 当時は全くと言っていいほど理解できなかったが、 最近Haskellを学び直して ようやく理解することができた(と思う)。 という訳で、現時点での私のモナドへの理解を示すためにこの記事を書く。 ここではモナドの本質が何なのか概要を示す。 正確な説明は数多あるモナドについてのチュートリアルを参照されたい。 Hellow World問題: IO, Monad, fail 新しい言語を学ぶ時、まず間違いなくHello Worldを書くだろう。 HaskellでHello Worldを書くとこうなる: この1行だけを見ると普通の命令型言語と大して変わらないように思える。 ところでHaskellには強力な型推論がある。 そのため型宣言を省略しても処理系がよしなに解釈してくれる。 ただ普通はコードの意図す
圏論とかモナドなんて簡単だからscalaを使って説明してみた - だらだらしてたいなぁ
はじめに 関数型といえばモナド、モナドといえば難しいという事が巷で言われていますが、いきなりモナドを理解しようとするから難しく思えるだけで、圏論から順序を追って理解していけば全然難しく無いんだよって事を分かって貰えればいいなぁと思い書いて見ることにしました。 ただ、圏論といっても適用範囲がとっても広く、応用編になると分けわかんなくなってくるので、ここではプログラミング分野に特化したFP(functional programing)圏論*1について書きます。 また、説明を簡単にする為に細かい部分をいろいろ省略しています。学術的な定義としては正確ではないので、このエントリの説明は大体合ってる位の気持ちで読んでくださいね。 尚、ぼくは圏論の詳しい事はさっぱり分からないので、学問的な話を振られても回答できませんｷﾘｯ 圏ってなんなの？ 圏論と言えば、圏です。 圏って何なのかというと、対象(obje
再考: GoF デザインパターン - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代
デザインパターンの話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? irxground 君が再考: GoF デザインパターンといふ記事を書いてゐるので自分もちょっとコメントしてみます。 基本的に irxground 君と同意見のところは省略します。 あと、GoF の本自体は私は読んでゐません。 (GoF のパターン以外のパターンに関する意見の方が長くなってますね……。) GoF のデザインパターン 生成に関するパターン Builder そもそも builder パターンは Java の String と StringBuilder の様に可変オブジェクトと不変オブジェクトを別のクラスに設計しなければなら
React.js and Dynamic Children - Why the Keys are Important
React.js and Dynamic Children - Why the Keys are Important … and check why 5600+ Rails engineers read also this React.js and Dynamic Children - Why the Keys are Important Recently I’ve been building a pretty dynamic interface based on google analytics data for one of our customers. There was a bug that I couldn’t quite figure out because of my wrong understanding of how react works. In the end it
Joel on Software - 射撃しつつ前進
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/1/6 ときどき何もできないことがある。 確かにオフィスにやってきて、だらだらとし、emailを10秒ごとにチェックし、Webをながめ、アメックスの請求書を支払うというような頭を使わない作業をしたりもする。しかしコードを書くフローの状態に戻ろうとしても、それができない。 このような非生産的な期間は通常1日か2日続く。しかし私の開発者としてのキャリアには何週間もの間何もできずにいたということが何度かあった。言うならば、私はフロー状態になかった。私はゾーンの中にいなかったのだ。私はどこにもいなかった。 誰でも気分のむらはある。ある人々にはそれは穏やかなものだが、他の人々には、それはもっとはっきりしていて、ときには機能不全でさえある。そして非生産的な期間は塞いだ気分と何か関係しているようだ。 それ
最も偉大なコミット
Mar 13, 2012 皆さんそれぞれ、好きなOSSプロジェクトがあると思いますが、では皆さんが最も偉大と考えるコミットは何だと考えるでしょうか。 僕はこれ。 バージョン管理ツールで有名なgitの創始者Linus Torvaldsによる最初のコミットです。 もともとLinuxのバージョン管理用として生まれたgitはそれ以前、Linuxを管理するための適切な管理システムが存在しないことを理由に誕生しました。「ないなら作ってしまえ」というLinusの意思が明確に現れたコミットといえるでしょう。 このイニシャルコミットにはgitの基本的な機能が全て備わっています。わずか1000行余りのコードに、です。 このコミットで世界は「やっぱリーナスはんぱねえ」と驚かされたことでしょう。 このバージョンのgitのソースコードリーディングを実施することは以下の点で多くのプログラミング学習者に非常に有益です。
ネストの深さとコードの複雑度
Aug 16, 2014 この記事は「コードでも書こう」とエディタを起動したものの書くコードがない状態に陥った僕がやり場のない感情を消化するために書いたものであり、多くの人にとっては全くもって読む価値の無い記事である。そもそも僕個人の存在が社会にとっては全くもって価値のない存在であって、そのような存在から生み出される文章に価値がないことは自明である。 さて、本題です。 本題をまとめると「ネストの深さではなく複雑度でコードの良し悪しを判断すべき」という内容。 言いたいことはこれで終わりなので、以降の価値の無い文章を読むことに時間を割くよりはここでタブを閉じることをおすすめします。 コードのネストを深くするな | anopara ネストの浅さにこだわると逆に読みづらいコードが生み出されたりするので、ネストを深くするなという単純な主張には同意しかねます。 ちなみに、個人的には最後のケースを除けば
日本語で読める IT名文書 三選 - naoyaのはてなダイアリー
pplog の方に書いたけど、別にブログに書けばいいかと思い直したので投稿。Slack でチャットしてて、なんとなくこれ面白いよ URL を共有する機会があったので適当に選んだもの。 伽藍、バザール、ノウアスフィア、おなべ(3) http://www.artonx.org/diary/20120411.html#p01 artonさんがノウアスフィアの開墾についてわかりやすく書いてるもの。原文はちょっと長くて読むのが大変だけど、こっちは分かりやすいし、面白い。OSS の構造がなんかわかったきになる、すごい。 Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した http://anond.hatelabo.jp/20111018190933 (前編) http://anond.hatelabo.jp/20111018192953 (中編) http://a
50代におすすめのマッチングアプリは
病院は時間がかかりますが、皮ふ科に行ったら40代の人に今日は２時間以上かかると言われました。マッチングアプリ 50代というのは混むものだと覚悟してはいるものの、相当な会える人がかかるので、ホテルの中はグッタリしたマッチングアプリ 50代になってスタッフさんたちも平謝りです。近頃はマッチングアプリ 50代のある人が増えているのか、50代のシーズンには混雑しますが、どんどん人妻が長くなっているんじゃないかなとも思います。会える人は以前より増えて今年も近所に出来たのですが、ぼっちゃりの数が多すぎるのでしょうか。困ったものです。 先週、おかずの添え物に使うつもりでいたら、マッチングアプリ 50代を使いきってしまっていたことに気づき、かるめとパプリカと赤たまねぎで即席の付き合いたいを作ってその場をしのぎました。しかし20代にはそれが新鮮だったらしく、マッチングアプリ 50代なんかより自家製が一番とべ
車買取一括査定を依頼してこんな交渉には注意？
少しでも高く車を売りたい。そして申込みをスムーズに行うためにも 車買取の一括査定サービスはとても便利です。 複数の業者へ一斉に中古車査定を依頼するのですが、交渉には少し注意が必要です。 一括査定からの申込みなので、業者も始めから競争相手がいることは知っています。 業者としては少しでも低い査定額で早く決めてしまいたいもの。 他の業者が来る前に、決断させるような交渉を進めます。 「今決めるなら、プラス１０万円上げます」というような上乗せした査定額を 提示することもあります。思わず決めたくなりますが、冷静に考えてみると 最初からプラス１０万円の提示ができたはずです。このやり方に誠意を感じますか？ それでも決めてしまうか、他の業者を待つかはご自身次第になりますが、 このような交渉術はよくあることです。頭に入れておくと良いですね。 高額な査定額を探すためには、査定を依頼した車買取業者の金額がすべて
なぜプログラムのコードは複雑になっていくんだろう。 - かずきのBlog@hatena
いろんなソースコードを見ていると、すんなり頭に入ってくるものと、そうでもないものに分かれてくる。個人的にすんなり頭に入ってくるもものは、大体以下のような形になってるんだなぁと思ったのでメモっておく。 ネストを深くしないために最初にいらないものは捨てる メソッドとかで、本来したい処理と、そうじゃない値のチェック処理とかが混ざってると何がしたいのかわからなくなる。たとえばこんなの？ void Foo(int arg1, string arg2) { for (int i = 0; i < 10; i++) { if (arg1 != 0 && i % 2 == 0) { if (arg2 != null) { // やりたいこと } } } } 極端な例ですが、こんなのです。下手したら、やりたいことが複数個所に散らばってることもよくあります。これは void Foo(int arg1, str
魅力的なプロダクトバックログで開発を楽しく！
どんな開発プロセスでも製品やサービスを作るときは何からの形で要件をまとめると思います。KRAYが採用しているアジャイルソフトウェア開発フレームワーク『スクラム』では、製品やサービスの要件リストをプロダクトバックログと呼びます。実はこのプロダクトバックログ、その書き方や運用の仕方で開発のモチベーションが大きく違ってきます。書き方一つで、開発チームにとってもプロダクトオーナーにとっても見るのが楽しみな資料になりうるのです。 今回は、見るのが楽しみになる魅力的なプロダクトバックログを作るコツについてお話しします。 プロダクトオーナーから見たプロダクトバックログ 最初にプロダクトバックログのライフサイクルについて簡単におさらいします。 開発が決まったら、プロダクトオーナーは製品のビジョンを実現するために必要な機能などをユーザーストーリーと呼ばれる文章で表現し、プロダクトバックログに追加していきます
クラスの命名のアンチパターン - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParame
リーダブル・コードを書く | POSTD
ここ数年間をプログラミング的な観点で見ると、私が望んでいたほどには面白みがなかったと言わざるを得ません。このことは、恐らく他のプログラマの皆さんも同意見かと思います。そこで、私はこの期間をある意味、充電期間と捉えて、自分の開発ツールの強化に取り組んできました。そして土曜日になると、Bashを使って ワークスペース 作りに精を出していたのです。 最後にシェルを使って真剣にプログラミングに取り組んだのは、かれこれ恐竜がまだ地球を支配していた頃だったでしょうか。何年も触れていなかった言語を改めて取り上げ、その昔に自分が書いたコードを見直してみると、いかに自分が成長したかということを実感できて、なかなかに面白いものです。 14年前、私は”コンパクトなコードは優れている”という考えに随分と傾倒していました。コードが少なければ、そしてDon’t Repeat Yourself（DRY）に従えば、バグも
倉貫義人氏が語る「顧客が欲しがるプログラマー」とは【連載:大元隆志が聞くSEの未来像】 - エンジニアtype
ITビジネスアナリスト 大元隆志氏 大手SIerに在籍し、システム構築やプロジェクトマネジメントで活躍しながらモバイルを軸としたビジネスの企画・立案を手掛ける。各種メディア向けの執筆活動でも知られており、近著に『ビッグデータ・アナリティクス時代の日本企業の挑戦』がある。ITビジネスアナリストとしての発信は自身で立ち上げたブログメディア『ASSIOMA』でも行っている 私が以前「若手SEのキャリアメイク」について『エンジニアtype』の取材を受けた際、「今後5年は需要があっても、その後の5年をサバイブしていくのは難しい」という考えを述べた。そして、SI業界で最もボリュームが大きいと思われる業務系SEは、PLやPMを経てラインマネジャーへとキャリアアップしていくのはもはや「ゴールではない」とも断言した。 その状況下、今後は「エバンジェリスト」、「フルスタックエンジニア」、「マーケター」、「ビジ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Coding Games and Programming Challenges to Code Better
Design Patterns on CodePen
レガシーコード改善の戦略と戦術
crocos.jp
