前回、簡単なDIコンテナを作ってみたので、次はこれを使ってWebフレームワークを作ってみたいと思います。 Webサーバーをつくる まず、WebフレームワークなのでHTTPサーバーが必要ですね。なので簡単なものを作ります。 とりあえずブラウザからリクエストを受け取ったら200 OKとHTMLを返すだけのサーバーです。 今回は、そこらのブラウザからアクセスできればいいや、ということで、RFCとかの仕様に準拠することは考えません。 public class Server { public static void main(String[] args) throws IOException { ServerSocket serverSoc = new ServerSocket(8989); for (;;) { Socket s = serverSoc.accept(); new Thread((
UNIXなどPOSIX準拠のOSでは、割り込みや例外を抽象化した「シグナル」と呼ばれる仕組みを用いてプロセスに(非)同期イベントが通知されますが、シグナルハンドラで行える処理には制約があり、これを無視したコードを書くと脆弱性につながる恐れがあります。今回はシグナルハンドラの制約に関するルールを見てみましょう。 シグナルハンドラの制約 UNIXなどPOSIX準拠のOSでは、割り込みや例外を抽象化した「シグナル」と呼ばれる仕組みを用いてプロセスに(非)同期イベントが通知されます。ユーザが[Ctrl]-[C]キーを押してプログラムを中断しようとしたり(SIGINT)、整数オーバーフローが発生したり(SIGFPE)すると、それらのイベントに対応するシグナルがカーネルからプロセスに対して通知されるのです。プログラマは、これらのシグナルを受信した時に特定の動作を行わせる「シグナルハンドラ」を書くことが
Scala大好きインフラエンジニアの九岡(@mumoshu)です。マイブームはConcourse CIですが、今日はマイクロサービスの話をさせていただきます。 TL;DR; 「サービスの負荷上がってきたし、マイクロサービス化しよう。マイクロサービス化って、Railsアプリ分割して、それぞれCapistranoでデプロイしておけばいいんでしょ?」*1 マイクロサービス化をするためには、アプリケーションだけでなくインフラや運用のことも考える必要があります。 この記事では、クラウドソーシングのクラウドワークスが来るマイクロサービス化に向けて認識しているデプロイメント上の問題とその対策を紹介します*2。 テストからデプロイまでがめんどくさいよ問題 →Dev/Prod Parity、Infrastructure as Code、CI、ビルドパイプライン リリースに1時間かかるよ問題 →ビルドキャッシ
これまでのあらすじ 2016年の2月の終わり頃,Raspberry Pi 3(以下,RasPi3)が発売されました. 日本では技適のいろいろがありまして,その1ヶ月後の3月終わり頃から秋月やマルツなどで購入できるようになりました. RasPi3の特徴は,Raspberry Pi 2まで採用していた32-bit ARMアーキテクチャのCPUではなく,64-bit ARMアーキテクチャのCPUを採用している点です. 32-bitから64-bitになると,CPUが1度の命令で処理できるデータの長さが32から64と2倍になるので,同じ処理なら一般的に64-bit環境で実行するほうが高速*1です. しかし,2016年3月はまだ公式から64-bit版のraspbianは提供されていないどころか,そもそもファームウェアが64-bitに対応していなかったために,簡単に64-bitのOSやプログラムを動かす
はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelやPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo
MarkDownDiagram Markdown風のテキストで、ER図やブロックダイアグラムのようなチャートを描けるツールです。 こちらにインスパイアされて、もうちょっと汎用的にダイアグラムを描けるツールを作りました。 もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った 特徴としては Webブラウザのみでローカルで動作 配置はマウスでドラッグして編集できる CSSで色や装飾を制御可能 といったあたりです。 githubからclone/ダウンロードして使えます。 オンラインで試すのはこちらでどうぞ。 ローカルでブラウザのみで動作します。index.htmlをブラウザで開いてください。 Chrome推奨ですが、Safari,Firefoxでも動作します。タッチIFは未対応。 機能 テキストでブロックを記述し、ブロック間を線で繋ぐ描画 ブロックをマウ
JS しか書いてないんだなって人は筋悪いものをありがたがっていたりする印象はある。しかし筋悪いものをありがたがるみたいなのはどこにでもいるので、JSがどうとかは直接は関係がないはずではあると思う。JSしか書いてない人とPHPしか書いてない人は似たようなもんで、単に広範囲の知識に興味がないだけな気がする。 それはともかく「これは筋悪そうだな」っていう感覚がどこからくるのかよくわかってないので、現時点で思いつく限り雑にメモしておく。 割の合わなさ 「これは何の問題を解決してるんだろう」と思ってドキュメント読んだりソース読んだりした結果、大したことを解決してなくて、その割に実装量が多いとか学習コストが高いと、筋悪いなあと思う。 フットプリントや学習コストに対して提供されるモノが「割に合わない」のは筋が悪く感じる。 将来性のなさ 「あ、これはただの流行だな」みたいな、5年後には消滅してるなというも
私は大学時代に、興味本位でJavaScriptを始めて、それ以来ウェブページを幾つか作成してきました。JavaScriptは常にC言語やJavaの合間の楽しい息抜きでしたが、アニメーションや、ユーザをあっと言わせるようなちょっとしたことを提供するといった、特殊な目的にかなり限られた言語だと考えていました。JavaScriptは覚えやすく、開発者に具体的な結果をすぐにもたらしてくれるので、コーディングする方法を学びたいと思っている人に私が教えた最初の言語でした。JavaScriptにHTMLとCSSを少し組み合わせれば、ウェブページが出来上がります。プログラミング初心者には喜ばれます。 その後、あることが2年前に起こりました。当時、私は、主にサーバーサイドのコードとAndroid用のアプリのプロトタイプに取り組む研究職に近い立場にいました。すぐにNode.jsの存在が目に留まりました。バック
若者の車離れ これを転載するのは4回目くらいだが。 きわめて個人的な見解で恐縮だが、かつて車が若者にツールとしてもてはやされたのは、車を介して他人とつながりが持てた時代だったからに思える。そのプロセスで「他とても楽しい」と彼等が感じ、必須であったからこそ、車は人々にとって重要な製品だった。しかし現在は車を使わずとも人とコミュニケーションが容易に図れるようになり、さらに環境問題や景気の話もあって、自動車が決して必要なツールでは成り得なくなっている。 MFi Vol.53 P009 2011 米国の車離れ これを転載するのは2回目くらいだが 一昔前、自家用車は「自由」と同じ意味合いを持っていた。だからこそ、米国のティーンエイジャーは誕生日を心待ちにし、年齢に達すればすぐに免許を取った。 現在、ティーンエイジャーが自由を獲得するのは、携帯電話やスマートフォンを与えられたときである。ソーシャルメデ
Google Compute Engine、全世界のリージョンが同時に外部とのネットワーク接続を失うという深刻な障害が発生。ネットワーク管理ソフトウェアにバグ クラウドのどこかで障害や災害が発生したとしても、その影響はアベイラビリティゾーンを超えることはなく、そのために複数のアベイラビリティゾーン(Google Compute Engineでは「ゾーン」)にシステムを分散して配置することで、クラウドの障害の影響を受けない高い可用性を備えたシステム構築ができる。これはクラウド(IaaS)に対応したシステム構築におけるもっとも基本的な考え方です。 しかし先週、2016年4月11日にGoogle Compute Engineで発生した通信障害は、アベイラビリティゾーンどころかリージョンの境界も越え、世界中にあるすべてのリージョンのインスタンスが同時に外部とのネットワーク接続を18分間に渡って失う
大規模な自然災害が発生した際に、情報の入手や安否の確認に重要な役割を果たす携帯電話やスマートフォン。バッテリー切れで使えなくなることは極力避けたいものです。ですが、携帯電話やスマホを駆使すると、あっという間にバッテリーは無くなってしまうものです。特に、消費電力が従来の携帯電話(フィーチャーフォン、ケータイ)よりも大きい傾向にあるスマホでは、より早くバッテリーが干上がる可能性があります。 切れたら充電すればいい――という考え方は、災害時には通用しないことがあります。停電などが原因で、長時間充電できないことも考えられるからです。 そこで活用したいのが、手持ちのスマホのバッテリー節約機能です。この記事では、AndroidスマホとiPhoneに備わっている省電力機能をご紹介します。 Androidスマホ:非常用節電機能 一部のキャリア・メーカーのAndroidスマホには、利用できる機能を自動的に必
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く