タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

Javaとdevelopmentとprogrammingに関するKanasansoftのブックマーク (26)

  • Webサーバを作る

    レスポンスヘッダを取捨選択する 前回、 手作りのTCPクライアントでApacheを叩いてみたところ、 以下のレスポンスが得られました。 1: HTTP/1.1 200 OK 2: Date: Tue, 30 Jul 2013 17:47:09 GMT 3: Server: Apache/2.4.6 (Win32) 4: Last-Modified: Mon, 11 Jun 2007 11:53:14 GMT 5: ETag: "2e-432a0069dbe80" 6: Accept-Ranges: bytes 7: Content-Length: 46 8: Keep-Alive: timeout=5, max=100 9: Connection: Keep-Alive 10: Content-Type: text/html 11: 12: <html><body><h1>It works

  • TCPサーバ/クライアントを作る

    開発環境について この記事では、開発言語としてJava7を使用します。 それなりにユーザ層が厚く、処理系が無料で提供されている、 ということでJavaを選んだだけですので、 他の言語が得意な方は各自読み替えていただいてもよいかと思います。 OSも何でもかまいませんが、私はWindows Vistaを使用しています (2007年に購入したLet's Noteです。いい加減買い換えろって?)。 Webサーバとブラウザは通常TCP/IPで通信を行いますので、 Webサーバを作る前に、まずはTCPのサーバとクライアントを作ってみます。 JavaでのTCPサーバ/クライアントのサンプルソースは Google検索でもすればいくらでも見つかりますが、 ひとまずここでは以下のようなプログラムを書いてみました。 まずはサーバです(Server01.java)。 import java.io.*; impor

  • 本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう

    このページの目的は、 Webアプリケーションの基礎の基礎を説明することです。 さて、ここから下のぐだぐだは読み飛ばして、 いきなり実装の説明に 行ってもらってもかまいませんが、一応趣旨を書いておきます。 現在、プロのプログラマーの方々には、日々の仕事でせっせと 「Webアプリケーション」を作っている人が多いと思います。 そして、いまどきWebアプリケーションを作るのに、 CGIとかあり得ないでしょうから、 それなりの高級言語で、 それなりのフレームワーク等を使用して作っているのだと思います。 私自身、現状、仕事では主にC#とASP.NETを使っています。 そうやって生産性を上げるのは大変よいことだと思うのですが、 ことWebアプリケーションにおいては、 そのような「一見簡単そう」なフレームワークを使っても、 ちょっとややこしいことをやろうとするとすぐにうまくいかなくなって、 職場の先輩に聞

  • 「本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう」始めました - K.Maebashi's はてなブログ

    以前から「誰か書いてくれませんかね」とか言っていた「当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう」ですが、誰も書いてくれないので自分で書きました。 当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう http://kmaebashi.com/programmer/webserver/index.html 現状、合計で140行くらいのJavaプログラムで、普通に画像やCSSを含むWebページが表示できています。こちらのページの下のほうにも画像を貼っていますが、こんな感じで、ローカルのファイルシステムに置いてある私のWebサイトのトップページが表示できていますし、もちろんリンクをクリックして遷移することもできます。 「えっ? Webサーバってこんなに簡単に書けるの?」と思う人も多いのではないでしょうか。 もちろんこんなのは「わかっている人」から

    「本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう」始めました - K.Maebashi's はてなブログ
  • JavaでさくさくWebアプリ開発 - しんさんの出張所 はてなブログ編

    かなり久々の技術エントリ。 運用はお堅い重いサーバーを使ったとしても開発は軽いほうがいい。当たり前ですね。 というわけでさくさく開発する方法を書いてみる。DIコンテナはCDIやGuice、Springなど好きなものでよいが、今回は省く。軽いこともあって開発中はGuiceを使うことをお勧めしたい。注入は@Injectを使うため、開発中と運用中でコードが変わるってのは少ないはずだ。 まずはJAX-RS まず、アクションベースのWebアプリはJAX-RSを使うこと。これが基。サーブレットAPIを使わずに開発することについては今までも書いてきた。サーブレットAPIを触らないことにより開発効率とテストのしやすさを両立できる。 こんな感じ。 @Path("/") public class Hoge { @GET @Path("add/{a}/{b}") public Response add(@Pa

    JavaでさくさくWebアプリ開発 - しんさんの出張所 はてなブログ編
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • 「New I/Oで高速な入出力」第6回 ノンブロッキングI/Oを使ってみる:ITpro

    先週はノンブロッキングI/Oがどういうものかを解説し,ベンチマークを行ってみました。今週は実際にコードを書いてみましょう。 ノンブロッキングI/Oが真価を発揮するのはサーバーなので,ここでもサーバーに関して解説します。 Selectorクラス ノンブロッキングの主役となるのが,先週言及したjava.nio.channels.Selectorクラスです。 主役がSelectorクラスだとしたら,脇役は? 脇役として登場するのはjava.nio.channels.SelectableChannelクラスです。そして,黒子としてjava.nio.channels.SelectionKeyクラスがいます。 Selectorクラスは入出力に関する操作を監視するためのクラスです。監視する対象であるチャネルがSelectableChannelクラスになります。 SelectableChannelクラスは

    「New I/Oで高速な入出力」第6回 ノンブロッキングI/Oを使ってみる:ITpro
  • 「New I/Oで高速な入出力」第5回 処理をブロックしないI/O

    今まで,この連載では月ごとにテーマを決めて解説を行うというスタイルで行ってきました。今月はちょっと変則的なのですが,月の前半と後半に分けてみます。 というのも,今月の15日から4日間,Javaの最大のお祭りJavaOneがサンフランシスコで開催されるからです。また,前日の4月14日にはNetBeans Dayも開催されます。 4日間の会期中,テクニカルセッション,BOF,ハンズオンラボを含めて300以上のセッションが,朝8時30分から夜中の11時30分までびっちりと行われます。まさに,Java漬けの一週間です。 筆者もJavaOneに参加するので,今月の後半はJavaOneのレポートをお送りする予定です。 ブロックしないということはどういうこと? さて,話をNew I/Oに戻しましょう。 今回はノンブロッキングI/Oについて取りあげます。 ノンブロッキングI/Oとは,処理をブロックすること

    「New I/Oで高速な入出力」第5回 処理をブロックしないI/O
  • 「New I/Oで高速な入出力」第4回 チャネルを使ってみよう

    チャネルのクラス構成 先週はバッファだけでしたが,今週はチャネルも組みあわせて使っていきましょう。 チャネルはストリームの代わりになるクラス群です。大もとになるのはjava.nio.channels.Channelインタフェースです。とはいうものの,ChannelインタフェースにはcloseメソッドとisOpenメソッドしか定義されていません。実際の入出力は,Channelインタフェースから派生したインタフェースを使用します。 入力はReadableByteChannelインタフェース,出力はWritableByteChannelインタフェースで定義します。このほか,大量の入力を扱うScatteringByteChannelインタフェース,同様に大量の出力を扱うGatheringByteChannelインタフェースが提供されています。 これらのインタフェースはすべて名前にByteを含んでい

    「New I/Oで高速な入出力」第4回 チャネルを使ってみよう
  • 「New I/Oで高速な入出力」第3回 バッファを使ってみよう

    バッファはプリミティブに特化したデータ・コンテナのクラスです。ArrayListクラスなどのコレクションとは異なり,オブジェクトを保持することはできないし,サイズを変更することもできません。また,バッファに異なる型の値を保持することもできません。 これらの機能の制限は,入出力に特化していることに起因しています。基的に入出力ではバイトが読み書きできればいいので,この割り切りは潔いですね。 バッファの特徴を列挙しておきます。 プリミティブに限定したコンテナ サイズ不変 型の混合は不可 基的にシーケンシャル・アクセス(ランダム・アクセスも可能) position,limit,capacityという三つのプロパティを持つ ヒープ外のメモリーへの直接アクセスをサポート バッファは,基底クラスとなるjava.nio.Bufferクラスと,intなどの型ごとに定義されている派生クラスから構成されてい

    「New I/Oで高速な入出力」第3回 バッファを使ってみよう
  • 「New I/Oで高速な入出力」第2回 バッファとチャネルを使用した入出力

    先週はNew I/Oを紹介しました。今週からは実際に使ってみましょう。 ここで使用するサンプルは「ファイルのコピー」を行います。ストリームを使用したものが1種類とNew I/Oを使用したものが3種類,合計4種類のサンプルになります。 サンプルのダウンロードfilecopy.zip filecopy.zipにはソースコードとJDK 5.0 update 6でコンパイルしたクラスファイルが含まれています。 使い方はすべて同一で,引数にコピー元のファイルとコピー先のファイルを指定します。例えば,ストリーム版サンプルでsource.txtをdestination.txtにコピーする場合は次のようになります いろいろなサイズのファイルをコピーしてみると,コピー速度の違いを感覚的に理解できるはずです。 とはいうものの,どの程度違うか具体的な数字がないとわからないですね。そこで,テストを行うためのCop

    「New I/Oで高速な入出力」第2回 バッファとチャネルを使用した入出力
  • Java SE 7徹底理解 第6回 New I/O 2で非同期I/O

    先々月、先月とNIO2の新しいファイルシステムについて解説してきました。今月は、NIO2の残りの機能である非同期I/Oとソケットチャネルでのマルチキャストについて解説していきます。 なお、ここではNIO2の機能を中心に解説するため、バッファやチャネルなどNIOの機能に関しては特に解説を加えておりません。NIOについては、連載では2006年の4月から5月にかけて「New I/Oで高速な入出力」と題して解説していますので、そちらをご参照ください。 通常のI/O 一般的に入出力処理を行う場合、処理が完了するまで制御が戻ってくることはありません。たとえば、インプットストリームでstream.read(bytes);と記述した場合、読み込みが終了するまでreadメソッドが戻ってくることはありません(例外が発生することはあります)。つまり、処理がブロックされるわけです。 入出力が高速に行われるのであ

    Java SE 7徹底理解 第6回 New I/O 2で非同期I/O
  • Java SE 7徹底理解 第5回 New I/O 2の新しいファイルシステムインタフェース その2

    先月に引き続き、今月もNIO2で導入されたファイルシステムインタフェースについて紹介していきます。 簡単に前回のおさらいをしておきましょう。 新しいファイルシステムインタフェースは、既存のFileクラスの欠点を解決すべく導入されたAPIです。 ファイルシステムを表すのがjava.nio.file.FileSystemクラス、java.io.Fileクラスに対応するのがjava.nio.file.Pathインタフェースです。Pathオブジェクトに対するユーティリティメソッドはjava.nio.file.Filesクラスで提供されています。 先月はPathオブジェクトの生成、Fileオブジェクトとの相互変換、入出力などに関して説明を加えました。今月はFilesクラスで提供している機能を中心に説明を加えていきます。 ファイル・ディレクトリの作成 はじめに、ファイルやディレクトリを作成するところか

    Java SE 7徹底理解 第5回 New I/O 2の新しいファイルシステムインタフェース その2
  • Java SE 7徹底理解 第4回 New I/O 2の新しいファイルシステムインタフェース その1 | 日経 xTECH(クロステック)

    今回は、J2SE 1.4.0の話からはじめましょう。 J2SE 1.4.0がリリースされたのが2002年。すでに9年も経ってしまいました。 さすがに最近こそ使われなくなったものの、日においてはJ2SE 1.4.xが一番多く使われていたバージョンなのではないでしょうか。 そのJ2SE 1.4.0の時に新機能として導入されたのが、JSR 51 New I/O APIs for the Java Platform、通称NIOです。 NIOは、java.ioを補う新しいI/Oに関するAPIで、入出力に特化したバッファや、ストリームよりも高効率なチャネルなどを提供しています。また、ノンブロッキングI/OもNIOで導入されました。 NIOは一般にはそれほど使われていないようですが、GlassFishやTomcatなど多くのフレームワークやライブラリで導入されています。 しかし、JSR 51は当初から

    Java SE 7徹底理解 第4回 New I/O 2の新しいファイルシステムインタフェース その1 | 日経 xTECH(クロステック)
  • 「Java SE 6完全攻略」第49回 Concurrency Utilitiesの変更点 その1

    最近のCPUはデュアルコアは当たり前、デスクトップPCでさえクアッドコアを使用できる時代になりました。 このような時代の流れを先行するかのごとく、Javaでは当初よりスレッドを使った並行プログラミングが可能でした。とはいうものの、Threadクラスを使いこなすのはなかなか難しいというのも事実です。 そこで、J2SE 5.0では並行プログラミング用のAPIとして、Concurrency Utilitiesが導入されました。Concurrency Utilitiesには大別して次のような機能を持っています。 タスクの非同期実行機構 並行コレクション ロック、シンクロナイザ アトミック処理 Java SE 6ではConcurrency Utilitiesも強化されています。4つの機能のそれぞれが強化されているのですが、変更点はそれほど大きくありません。そこで、連載ではタスクの非同期実行機能の変

    「Java SE 6完全攻略」第49回 Concurrency Utilitiesの変更点 その1
  • 「New I/Oで高速な入出力」第1回 New I/Oをご存じですか

    Java SEには便利な機能が数多くあるのですが,新しい機能ほど活用されていないのではないでしょうか。筆者がJ2SE 1.4であまり使われていないのではないかと感じる機能を挙げてみます。 Assertion New I/O Image I/O Preferences API Logging API AssertionやLogging APIは,JUnitLog4Jなどのオープンソースのプロダクトで置き換えられるので,それほど使われていなくても不思議ではありません。 しかし,JPEGのイメージを出力するために,いまだにcom.sun.image.codec.jpeg.JPEGImageEncoderクラスを使用しているのは腑に落ちません。J2SE 1.3の頃に作られたアプリケーションであればわかりますが,J2SE 1.4以降に作られたアプリケーションではImage I/Oを使うべきではない

    「New I/Oで高速な入出力」第1回 New I/Oをご存じですか
  • 基本的なJMSアプリケーションの開発

    5 基的なJMSアプリケーションの開発 以下の節では、基的なJMSアプリケーションの開発に必要な手順について説明します。 必要なパッケージのインポート JMSアプリケーションの設定 メッセージの送信 メッセージの受信 受信メッセージの確認応答 オブジェクト・リソースの解放 上記のアプリケーション開発手順の他にも、設計開発時に以下の手順を任意に行うことができます。 接続およびセッション処理の管理 宛先の動的作成 恒久サブスクリプションの作成 メッセージ・ヘッダーおよびメッセージ・プロパティ・フィールドの設定と参照、メッセージのフィルタ処理、およびメッセージの並行処理によるメッセージ処理の管理 トランザクション内でのJMSの使用(第12章「WebLogic JMSによるトランザクションの使い方」を参照)

  • 今からでも遅くない JMSを学ぼう!(後編) Message-Driven Beanの世界へ

    Message-Driven Beanとは 前回、JMSをJavaアプリケーションに組み込んで非同期通信を説明しました。ただし、業務ではMessage-Driven Bean(MDB)を使用する方が多いため、今回はMDBを使った非同期通信の仕方を説明します。 あらかじめ知っておくべきこと 前提知識 「今からでも遅くない JMSを学ぼう!」ではJMSを通じて非同期通信を学ぶことを目的としていますが、ドメインはPTPを使用しているため、Pub/Subの知識は必要ありません。PTPについてご存じない方、JMSの知識のない方は前編を読んだ後にその後編の当記事を読まれることをお薦めします。 Webアプリケーションの基礎的な知識が必要です。JSPやServlet、あるいはStrutsなどのWebフレームワークを使用した経験のある方はそのまま読むことが可能です。知識がない方は筆者の「GlassFish

    今からでも遅くない JMSを学ぼう!(後編) Message-Driven Beanの世界へ
  • 今からでも遅くない JMSを学ぼう!(前編) 非同期通信の世界へようこそ (1/6):CodeZine(コードジン)

    CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

    今からでも遅くない JMSを学ぼう!(前編) 非同期通信の世界へようこそ (1/6):CodeZine(コードジン)
  • Ruby の retry-handler が激しく便利そうなので Java で実装してみた - 宇宙行きたい

    http://kimoto.hatenablog.com/entry/2012/03/05/103052 を読んでたら Ruby の retry-handler が激しく便利そうなので Java で実装してみた。 ソース→ https://github.com/yoshiori/retry-handler どんなものか簡単に説明すると 特定の処理を実行したいんだけど、途中で何らかのエラーが発生した場合はリトライさせたい時に使えます。 具体的にはこんな感じで書くと、処理の途中でエラーが発生しても指定した回数はリトライしてくれます。 Proc.retry(3,new Runnable() { @Override public void run() { //なんか処理 } }); 特定のエラーの時だけリトライしたい時はそれも指定できます。 例えば IOException とそのサブクラスのエラー

    Ruby の retry-handler が激しく便利そうなので Java で実装してみた - 宇宙行きたい