タグ

programmingに関するtokuryooのブックマーク (31)

  • 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 - Qiita

    はじめに もうすっかり年末なので、これから2015年にかけてアプリケーションアーキテクチャがどのようになっていくのかという個人的な考え/妄想や背景について、「リアクティブ」というキーワードをもとににまとめてみたいと思います。 Google Trendsを見ると"reactive programming"という言葉は2010年前後から、ゆっくりとバズをし始め、現在も上昇を続けています。 また、仕事としては、2010年ごろから大規模なWebサービス開発において、フロントエンド、バックエンド、アルゴリズム改善といった様々な箇所で、リアクティブプログラミングの要素を取り入れながら、アーキテクチャの改善を進めてきました。そのため、こういったアーキテクチャがコード品質の維持や安定性の向上、実際的で複雑な問題の解決にも適応可能であるということを実感として持っています。 近年、そういった要素が様々なツール

    2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 - Qiita
  • 【翻訳】あなたが求めていたリアクティブプログラミング入門 - ninjinkun's diary

    original: The introduction to Reactive Programming you've been missing (by @andrestaltz) (translated by @ninjinkun, reviewed by @ma0e) あなたはリアクティブプログラミングと呼ばれる新しい方法が気になっている。 勉強するのは大変で、良い教材がないのでさらに難しい。私が勉強を始めたときは、まずチュートリアルを探した。見つけたのは一握りの実践的なガイドだけ、しかもそれらは表面をなぞっているだけで、リアクティブプログラミングのアーキテクチャ全体像を構築しようとしてはいなかった。ある関数を理解するのに、ライブラリのドキュメントは役に立たないことがある。 これを見て欲しい。 Rx.Observable.prototype.flatMapLatest(selector,

    【翻訳】あなたが求めていたリアクティブプログラミング入門 - ninjinkun's diary
  • 2010-12-26

    リアクティブプログラミングは、「時間とともに変化する値」=「振る舞い」同士の関係性を記述することでプログラミングを行うパラダイムです。 GUIなどのようにインタラクティブなシステムや、シミュレーションやアニメーションのようにダイナミックに状態が変化するようなシステムを宣言的に記述することができます。 これらの「変化する状態」や「外部とのやりとり」が支配的なシステムは、純粋関数型言語が、その強みを発揮しにくい部分でもあります。 稿では、リアクティブプログラミングが副作用を含む系を宣言的に記述することを可能にし、状態の管理という厄介な問題からプログラマを開放する可能性があることを示したいと思います。 (割と独自研究に基づく解釈ばかりなのでその点ご了承ください。あと例としてでてくるコードは、Pythonベースの擬似コードで具体的なライブラリに基づくものではありません。) Why Reactiv

    2010-12-26
  • 「すごいErlangゆかいに学ぼう! 」という本が出版されました #すごいE本 - YAMAGUCHI::weblog

    はじめに こんにちは、Erlang界のCBR400Rです。このたび、私の2冊めの翻訳書籍、印刷されたものとしては初となる書籍が「すごいErlangゆかいに学ぼう!」というタイトルでオーム社より出版されました。日より書店ならびにAmazonはじめとするオンラインストアでご購入頂けます。 すごいErlangゆかいに学ぼう! 作者: Fred Hebert,山口能迪出版社/メーカー: オーム社発売日: 2014/07/04メディア: 単行(ソフトカバー)この商品を含むブログ (6件) を見る いま手元にあるの厚さや重さを実際に感じて、電子書籍では味わえなかった充実感、達成感を得ています。これの実現に至るまでに多くの方々にお世話になり、その方々のご協力なしには出版なんて到底ありえませんでした。当に感謝しています。ありがとうございました。 「すごいErlangゆかいに学ぼう!」はどんななの

    「すごいErlangゆかいに学ぼう! 」という本が出版されました #すごいE本 - YAMAGUCHI::weblog
  • 研究者流 コーディングの極意 言語処理学会第19回年次大会(NLP2013) チュートリアル資料(岡崎担当分)

    言語処理学会第19回年次大会 (NLP2013) チュートリアル資料(岡崎担当分) 岡崎 直観 東北大学大学院情報科学研究科 okazaki at ecei.tohoku.ac.jp http://www.chokkan.org/ @chokkanorg 研究者流 コーディングの極意 1 研究におけるコーディングの極意? • 今回のチュートリアルをきっかけにサーベイ – ソフトウェアエンジニア向けの指南書は存在 – でも,研究者向けの資料は数少ない • 自分が修士課程の頃は完全に我流だった – 複数文書自動要約のプログラムをすべてC++で実装 – *NIXを使うスキルはなく,すべてWindows上で実行 – 今から考えると,無駄だらけの実験作法だった • ほとんどの大学では実験の講義があるが… – 研究のためのコーディング作法は教えてくれない 2 繰り返される残念な光景 • 論文の締切前日

  • プログラマが勉強すること - きしだのHatena

    今日もプログラマになる勉強する人のところで話をしてきました。 で、また適当にいろいろ書いてました。 http://www.slideshare.net/nowokay/20140228-31742219 今日は特に、この図の内容についてまとめておきます。 ※ このエントリは、主に今日の話を聞いた人を対象としています。前提や補足については省略しています。 まずはプログラミング言語を プログラマというのは、利用者に直接サービスを提供することはできません。コンピュータの上でプログラムを動かして、そのプログラムを使ってもらうことでサービスを提供します。 ※組み込みは前提から外しています。 そのプログラムも、コンピュータで動くものを直接記述することは現実的にできません。 なんらかのプログラミング言語で、プログラムを書くことになります。つまり、プログラマの仕事は直接的にはプログラミング言語をいじくる作

    プログラマが勉強すること - きしだのHatena
  • 婚活パーティー・恋活パーティーなら、ゼクシィ縁結びイベント

    イチオシ [[data.opening_days_date_label]] [[data.opening_days_time]]〜 [[data.tertiary_area_name]] ([[data.secondary_area_name]]) 男性 [[ entryStatus(data.application_deadline_date, data.entry_status_male) ]] [[data.condition_male_from]]〜[[data.condition_male_to]]歳 / 女性 [[ entryStatus(data.application_deadline_date, data.entry_status_female) ]] [[data.condition_female_from]]〜[[data.condition_female_to]]歳

  • ほぼ日刊イトイ新聞 -マッチ箱の脳(WEB)篇

    「マッチ箱の脳」という森川くんが書いたは、 その世界で、かなりの評判を呼んでいます。 まだ、売り出されてまもないこのを、 森川君、WEB用に再編集して、 「ほぼ日」に連載してくれることになりました。 なんとふとっぱらで、骨惜しみしない男なのでしょう?! ◆気前がいいだけじゃ生きられない。 ただのケチでは生きている資格がない。 謹んで、感謝の意をこめて、上記のことばを 森川くんにささげさせていただきます。

  • Programming Contests, Software Development, and Employment Services at TopCoder

    No negotiations. No onboarding. Work starts right away with our Talent Network.

    Programming Contests, Software Development, and Employment Services at TopCoder
    tokuryoo
    tokuryoo 2009/03/15
    TopCoder
  • 浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ

    浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ

    浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ
    tokuryoo
    tokuryoo 2008/04/17
    うちのプロジェクトはプログラム設計書書いてないな。プログラマーにある程度のスキルを求めるスタンス。コードレビューはする。
  • 「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ

    昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保

    「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ