Created by Vic Metcalfe, Andrew Gierth and other contributers (Transrated into Japanese by: Keisuke Mori)May 21, 1998 この文書は、UNIX 上での ソケットインターフェースを用いた TCP/IP アプリケーションプログラミングについて、頻繁に行われる質問とその 解答を集めたものです。 1. 一般的な情報と概念 1.1 更新情報 1.2 この FAQ について 1.3 この FAQ はどのような人向けでしょうか? 1.4 ソケットって何ですか? 1.5 ソケットはどのように動作するのでしょうか? 1.6 [ある本の題名] という本のソースコードはどこから取得できますか? 1.7 どこでもっと情報を得ることができますか? 2. クライアントとサーバ(TCP/SOCK_STREA
http://anond.hatelabo.jp/20130322031333 プログラミング出来る方法教える。 書いた本人に悪意があったかどうかは知らないが，予想通り結果的に初心者を惑わせるだけの悪質な記事． まあこの手の奴は９９％デマと考えてよい．このくらいの文章量では，プログラミングができるようになる方法を記述するには全然足りない． 一応ツッコミは入れておく． 世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。 ほとんどのプログラミング言語本は，多かれ少なかれプログラミングのやり方も含めて説明している． C実践プログラミング 第3版 作者: Steve Oualline,望月康司(監訳),谷口功出版社/メーカー: オライリー・ジャパン発売日: 1998/06/15メディア: 大型本購入: 7人 クリック: 158回この商品を含むブログ
Coders at Work プログラミングの技をめぐる探求の紹介の後半です。 心に残ったひとことの引用と、それに対する個人的な感想を書きます。引用は手動で書き写しているので書き間違いがあるかもしれません。何か変だったら前後から類推するか本を当たってください。 ジョー・アームストロング 今から思うとおかしいのは、現代的な小道具というのはどれも、実際にはより生産的にしてくれるものではないことです。(略)ソフトウェア開発の大部分はどのみち頭の中で行われるのです。(略)それから今日では選択の重荷が大きすぎると思います。(略)昔は選択による麻痺状態なんていうものはありませんでした。単に始めるだけのことで、言語やなんかに何を使うかという選択は、すでになされていたのです。どれにするかと考えることはなく、ただやり始めれば良かったのです。 Erlang作者のジョー・アームストロング氏の懐古主義な感想です。
60%の人間はプログラミングの素質がない
Coding Horror: Please Don't Learn to Code Please Understand Learning to Code Coding Horrorで有名なJeff Atwordが、ある州知事が今年の目標としてプログラミングを習得することを挙げていることに対し、そもそも税金を払う我々市民は、政治家にはプログラミング習得以上に重要な、政治家にしかできない問題の解決を望む、よってプログラミングを学ぶのをやめてくれという記事を書いた。これに対して、反論が多数上がっているが、Jeffも読んでいるある論文をあげて、この議論の参加するためには、必ずこの論文を知っておくべきであると書いた人がいる。この論文は有名で、非常に興味深いので、全プログラマーが読むべきである。 ふたこぶラクダという名前で知られている有名な論文がある。この論文では、60%の人間にプログラミングの素質が
はじめに 先日、社内で初めてプログラミングコンテストを開催しました。 お題はかの有名なFizzBuzz問題です。 全員楽勝で解答するだろうと思いきや・・・結果はいかに！？ ちょっと長いエントリですが、このコンテストの顛末をお楽しみください。 開催の動機と経緯 メンバーの向上心を刺激するために、なにか面白くて技術的に意味のあるイベントを開きたかった。 以前からFizzBuzz問題を全員で解いてみたかった。 FizzBuzz問題はプログラマなら解けて当たり前、というようなWeb記事をよく見かけていた。 これぐらいなら誰でも解けるだろうと自分も思っていたが、実際にやってみないとわからない。 そこで社内プログラミングコンテストを開き、みんなでFizzBuzz問題を解いてみたいと思った。 マネージャーに話を持ちかけたところ、すぐに賛同してくれた。 FizzBuzz問題以外の追加問題も作成したが、第１
このセクションでは、.NET を拡張して操作するライブラリを設計するためのガイドラインを示します。 目標は、開発に使用されるプログラミング言語に依存しない統一されたプログラミング モデルを提供することで、ライブラリ デザイナーが API の一貫性と使いやすさを確保できるようにすることです。 .NET を拡張するクラスとコンポーネントを開発するときは、これらの設計ガイドラインに従うことをお勧めします。 一貫性のないライブラリ設計は、開発者の生産性に悪影響を及ぼし、導入を阻止します。 ガイドラインは、 Do、 Consider、 Avoid、および Do notという用語で始まる単純な推奨事項として編成されています。 これらのガイドラインは、クラス ライブラリ デザイナーがさまざまなソリューション間のトレードオフを理解するのに役立ちます。 ライブラリの適切な設計で、これらの設計ガイドラインに違
見えないチカラ: 【翻訳】アクターによる並列性、そしてRubyでGoroutine
Ilya Grigorikさんの "Concurrency with Actors, Goroutines & Ruby" を翻訳しました。 元記事はこちら： http://www.igvita.com/2010/12/02/concurrency-with-actors-goroutines-ruby/ （翻訳の公開と画像の利用は本人より許諾済みです） 翻訳の間違い等があればブログコメントやTwitter(@oshow)などで遠慮無くご指摘ください。 アクターによる並列性、 そしてRubyでGoroutine 並列コンピューティングの世界は複雑なものだ。私たちはハードウェア、ランタイム、そして半ダースもの異なるモデルとプリミティブから選択することを考えなければならない： fork / wait、スレッド、シェアードメモリ、メッセージパッシング、セマフォ、そしてトランザクションなど。ゆえに
はじめに 2010 年 9 月 15 日を持ちまして、サイボウズ・ラボを退職いたしたました。 報告も兼ねて、久しぶりにブログを書いてみたいと思います。 （写真はゆうすけべーさんです） この会社に入って、たくさんの学びと思い出がありました。 その一つ一つをまとめていければ、素晴らしい記事になるのかもしれませんが、僕は文章が苦手です。 ですので、うまく退職のエントリを書き上げることができません。 言葉にできない。そんな感じです。 なので、このエントリはサイボウズ・ラボやサイボウズ本社の仲間たちへのありがとうの気持ちをこめて、自分らしく最後まで JavaScript のことを書きたいと思います。 サイボウズでの最後の仕事 僕にとって、サイボウズでの最後の仕事は「JavaScript で新しいユーザーインタフェースを作ること」でした。 そして、その中で始めて複数人による大規模な JavaScrip
先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
Sanjay Ghemawat, Paul Menage <opensource@google.com> Motivation TCMalloc is faster than the glibc 2.3 malloc (available as a separate library called ptmalloc2) and other mallocs that I have tested. ptmalloc2 takes approximately 300 nanoseconds to execute a malloc/free pair on a 2.8 GHz P4 (for small objects). The TCMalloc implementation takes approximately 50 nanoseconds for the same operation pai
文部科学省は8月19日、ドラッグ＆ドロップなどの簡単な操作でプログラミングが楽しめる子ども向けサイト「プログラミン」を公開した。プログラミンの作品を集めた非公式の関連サービスも早速、登場している。 プログラミンは、子どもがプログラミングの仕組みを学べるサイト。自分で描いたイラストに、回転や効果音を鳴らすといった命令を組み合わせ、動かすことができる。命令はドラッグ＆ドロップなど簡単な操作で設定可能。完成させた作品は一般に公開できる。 8月19日に公開され、はてなブックマークやTwitterなどで話題に。プログラミンで公開された作品を一覧で見たり、評価を投稿できる非公式サービス「プログラミン作品ギャラリー」を個人開発者の矢野さとるさんが同日中に公開するなど、反響が広がっている。 プログラミン作品ギャラリーは、Twitterでつぶやかれたプログラミンの作品ページのURLを自動収集して表示する仕組
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
Wizard Book n. Hal Abelson's, Jerry Sussman's and Julie Sussman's Structure and Interpretation of Computer Programs (MIT Press, 1984; ISBN 0-262-01077-1), an excellent computer science text used in introductory courses at MIT. So called because of the wizard on the jacket. One of the bibles of the LISP/Scheme world. Also, less commonly, known as the Purple Book. from The New Hacker's Dictionary, 2
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "データフロープログラミング" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2025年3月) データフロープログラミング（英: dataflow programming）は、データフローの原理とアーキテクチャに準拠したプログラミングパラダイムであり、プログラムをオペレーション間のデータフローの有向グラフとして模型化する。データフロー言語は、関数型言語の特徴を共有しており、より数値処理に適したものになっている。 データフロー言語は、命令型プログラミングモデルなどの他の主要のプログラミング言語とは対照的である。命令型プログラミングではプロ
はじめに 昨今マルチコアCPUは一般化し、並列化処理の重要度がどんどん高まってきました。この流れはもう変わらないでしょう。ですから、我々開発者にとって並列処理の知識は絶対に必要なものです。とはいえ、日々の業務をこなしつつ資料が少ない並列化処理を身につけることは大変です。 そこで今回筆者は、並列化処理を実現するOpenMPの入門記事を書くことにしました。OpenMPを選択した理由は、一番効率が求められているのはC/C++プログラマーだと考えたからです。C/C++プログラマーの方々が並列処理を習得するお手伝いができれば幸いです。 なお、この連載で解説に使用するサンプルコードはあくまでもOpenMPの基礎を理解するための便宜的なものであり、実務でOpenMPを使用する際にはよく理解してから用途に適したプログラミングを行ってください。 対象読者 筆者が想定している読者はCの基本的文法をマスターし、
id:NyaRuRu:20080127:p1 続き． 私自身，系統だってこの筋の学問を学んだわけではないので，自分の考え方を整理しながら考えてみます． プログラミングの世界では，決まった動作をする小さなモジュールをパイプライン状につなげていって，何か役に立つ大きなものを作ることがしばしばあります．しかし，一口にパイプラインと言っても色々な実装があることに気付きます．代表的なパイプラインとして，まずは UNIX Pipe について見てみましょう． UNIX-pile-like-pipeline UNIX Pipe 流のパイプラインは，BlockingQueue や BlockingStream で連結されたマルチスレッドプログラムとみなすことができます． Java BlockingQueueで遊ぶ: パイプラインごっこ - 檜山正幸のキマイラ飼育記 Java BlockingQueueでもっ
メタセコイア・パイプライン Ver. 1.3 メタセコイア 4.2がリリース メタセコイア 4.2がリリースされました。4.2では作業中のサムネイル画像をMQOファイルにThumbnailチャンクとして保存できるようになりました。... Date: 07/18/2014 メタセコイア・パイプライン Ver. 1.2 メタセコイア 4.2が出力するMQOファイル読み込みに対応した「メタセコイア・パイプライン Ver. 1.3」を公開しました メタセコイア 4.0がリリース メタセコイア... Date: 10/30/2013 PowerShellと大規模ゲーム開発 今回の投稿からブログのタイトルが「ひにけにXNA」改め「ひにけにGD(Game... Date: 12/26/2012 XNA Game Studio 4.0 Refreshに更新しよう XNA Game Studio 4.0 R
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
