  |
はてなキーワード: httpとは
メーカー系IT会社に勤めてたけど、基本情報は入社2年ぐらいを目処に全員（文系出身含めて）取らされる。
それから、応用情報技術者相当が、管理職昇任の前段階として必須だった。
動くプログラムを作ってナンボの中小とかベンチャーでは気にしてる人は少ない。
コンピュータの仕組みについては、分野による。
自分はWeb系だけど、HTTPより下位の仕組みは知らなくてもなんとかなることが多い。（OSの知識やTCP/IPの知識はあると役立つ）
組み込み系なら0,1の世界のコンピュータアーキテクチャから知らないと駄目だと思う。
そこで、HTTP2.0ではどんな告白が可能になったのか告白で例えていきましょう。
HTTP2.0は随分とフォーマットが変わりましたが、告白の方法が電話だったものがメールになりLINEになりと媒体が変わったものの伝えたい事は変わっておりません(セマンティクスは維持されています)。
なので、みなさんが大好きなステータスコードはHTTP1.xの頃と殆ど変わっていません。HTTPヘッダも同様です。
物凄く簡単に、かつ誤解を恐れず紹介したいと思います。
HTTP1.xでは、告白したら返事を貰わないと次の告白は出来ませんでした。
HTTP2.0では、相手の返答を待たずに続けて(同じ相手に)告白をすることが出来るようになりました。
ただあまりしつこいと、あっち行けと言われてしまうかもしれません(GOAWAYフレーム)
同時に複数回告白できるようになったため、どの告白文についてより早く返事をして欲しいか優先度を指定できるようになりました。
ただし優先度付けしたところで、相手がそれを汲み取ってくれるとは限らないようです
「好きです」→「ごめんなさい」
という感じです。
男「好きです」→ 女「ごめんなさい」→男 「では友達からということで...」→女 「それもいやです」
HTTP2.0では女の子は、男の次の要求が想定できる場合、要求が来る前に返事を返すことも出来るようになりました。
男「好きです」→ 女「ごめんなさい」「友達になるのも無理です！！」
「～～さんへ」(host)や「2013/12/18」(date)といったもの、自分の名前(User-Agent)といったものはわざわざ書かなくても良くなりました。
現状HTTP1.xと言う旧式の告白方法と、HTTP2.0という新しい告白方法が存在することになります。
---------------------------------------------------------------------------
---------------------------------------------------------------------------
前回の続き
エロサイトのコンセプトを「誰もがオナニーライフを充実できるように多くのカテゴリを持つ総合エロ動画サイト」
に決めた僕。
さて、稼げるかどうかは、どういう広告をどう貼るかが問題なんだけど、ちょっと難しいので、
これは、もう少し後で、紹介します。
今回は、実際のエロサイトをどうやって作るかです。
さっそくgoogle先生にお願いしてみた。
何度もお呼び立てして申し訳ございません。
私、webサイトのwの字も存知上げません。
どうかこの愚生をご引導ください。
先生が言うにはどうやらWEBサイトはhtmlというもので作られているらしい。
えいちーてぃーえむえる？
他にもphpやcgiなどのプログラミング言語で作成もできるらしい。
ふむふむ、google先生によるとWEBサイトはどんなものでもhtmlソースが見れるらしい。
フフフ、先生
僕はあなたの全てが見たいんです！！
とりゃー！
は？
へべ？
もぎょぶ？
ナンナンダ！コレハ！
みんなこんな訳わからん英文字を駆使して
ホームページ作ってたのか！
＜head＞もなんとなくわかる気もする。上の方ね。頭の方って事ね。（違うけど）
＜meta http-equiv="Content-Type" content="text/html; charset=shift_jis"＞で完全に思考停止。
知らない事が多すぎる。
なんだかまた不安になってきた。
知らないって超こわーい
「おいら、上に立つ人間っていうのは完全に孤独じゃなきゃいけないって思う」
500G師匠？
振り返ると、備え付けハードディスクに入った500G師匠が僕を見つめていた。
師匠ありがとうございます。僕がんばります！
僕が意気込みを見せると、500G師匠はちょっと照れくさそうに頭を掻いた。
「あんちゃんが売れたら、おいら使ってくれよな」
つづく
標準時の変更を 与党議員が発議＝韓国 聯合ニュース 11月21日(木)19時22分配信
http://headlines.yahoo.co.jp/hl?a=20131121-00000045-yonh-kr
【ソウル聯合ニュース】韓国与党セヌリ党の趙明哲（チョ・ミョンチョル）国会議員は21日、日本の標準時と同じ韓国の標準時を韓国本来の標準時に変更することを柱とする「標準時に関する法」の改正案を発議した。
韓国標準時は日本標準時子午線の東経135度を基準とするが、これを韓国の国土の中心を通る東経127．5度に変えるという内容。その場合、標準時は現在より30分遅くなる。
韓国は1908年、東経127．5度を標準時子午線に定めたが、
日本植民地時代の1912年に朝鮮総督府の指示で日本標準時にそろえた。1954年に東経127．5度に戻した後、1961年に再び135度に変更した。
趙議員は、現在の韓国標準時子午線の東経135度は韓国の領土を通っておらず、韓国最東端の独島からも278キロ離れていると指摘。「標準時の改正を通じ、領土主権と歴史を再確立し、国のアイデンティティーと国民の自尊心を回復すべき」と述べた。
mgk1202@yna.co.kr
●韓国標準時 - Wikipedia、フリー百科事典(google翻訳)
http://ko.wikipedia.org/wiki/%ED%95%9C%EA%B5%AD_%ED%91%9C%EC%A4%80%EC%8B%9C によると
1912年 1月1日：東経135°UTC +9に変更。朝鮮総督府官報第367号（告示第338号）。
1954年 3月21日：解放後、大韓民国の標準時間は、再び東京127.5°UTC +8:30へ変更。大統領令第876号（1954年3月17日）。
1961年 8月10日：国家再建最高会議の決定に基づいて東経135°UTC +9:00へ変更。法律第676号（1961年8月7日）。法律第3919号（1986年12月31日）。
となっていて、詳しいことはわからない。
少し詳しく調べてみると
●日本が奪っ朴正煕がまた奪った '韓国時間' [走る鉄道で見た世界] (17)時間をめぐるいくつかの物語 インターネット紙 「プレシアン」(Google翻訳)
http://www.pressian.com/article/article_facebook.asp?article_num=10131025141140
1945年になるとすぐ時間を取り戻してくるとは、努力があったが、韓国の統治を務めた米軍政は、操作利便性という単純な理由で東京標準時をまだ守った。韓国標準時を再訪れたのは韓国戦争が終わって遠征きた米軍の撤退が行われた後の1954年3月だった。21日午前0時30分部大統領令によって再び東京127度30分を標準子午線とする大韓民国標準を指定します。1954年3月21日、大韓民国は0時30分を二回経験することになる。一度は東京標準時に一度ソウル標準時。しかし、このソウル標準時は長続きしない。7年後にクーデターを起こした朴正熙を筆頭とした軍部勢力は国家再建最高会議で、韓国の標準時間を東京標準時に戻って変えてしまった今まで続いてきている。
もう少し詳しく調べてみると
●良い名前の研究所は標準時を韓国の基準東京127度30分を適用しています(Google翻訳)
元韓国が使っていた標準を日本が強制的に日本のものに変えたし解放が
れた後一歩遅れて1954年に韓国基準の標準に還元したこと以上にも
1961年5月16日の軍事クーデターが起きたすぐ後の1961.8.10から再度東経135度を
標準時に変更したことをご存知ですか？
東京127度30分には大韓帝国官報第3994号（勅令第5号）に基づき、1908年4月1日から
それが、日本の日韓併合策の一環として、朝鮮総督府官報第367号に基づき、1912年
光復後、1954年3月21日、李承晩政権は日帝残滓清算の一環として、標準時を
変更して、時間を30分遅らせました。 しかし、当時、米軍は、作戦指揮権を東京
米極東司令部の関係で標準時の変更に従うことができないと頑強に反対した
します。
ところが、1961年8月10日、朴正煕の軍事クーデターが起きた後席月もされていない、
軍事政権は、法律676号（標準子午線変更に関する法律）に基づいて時間を30分
繰り上げ日本と同じ東経135度基準の標準時を使用する法案を可決した。
その時の理由は、国際的に30分差が出る標準時がないことを国際的
習慣と一致させるというものでした。 （これはとんでもない論理です）
国家再建最高会議が標準時を変更したプロセスについては、これまで知られていなかったが、
最近入手した1961年8月4日、国家再建最高会議第27次常任委員会の議事録による
面が会議に参加した某人が在日米軍と在韓米軍、韓国軍との連合作戦のために
統一された時間が必要だと標準時の変更を要求してわずか数分で通過させたとされて
ています。
米軍の軍事作戦の便宜のために国の時間を無理やり日本時間に合わせるとんでも
国家再建最高会議が標準時を変更したプロセスについて、どうしてわかったのか。
[緊急提言]韓国時間30分ずらす "いい加減"風土消える 金基德 キム·ギドク 建国大研究教授·韓国史
東京127度30分採択は、「時間の光復」！ (Google翻訳)
http://shindonga.donga.com/docs/magazine/shin/2005/05/25/200505250500029/200505250500029_2.html
http://shindonga.donga.com/docs/magazine/shin/2005/05/25/200505250500029/200505250500029_3.html
1961年に国家再建最高会議が標準時を変更したプロセスについて、これまで知られていることがほとんどなかった。 ところが、
2004年8月KBSがソクジェの事件ファイル "光復59年、時間は解放されなかった"という番組を放送した。 KBSは1961年8月4日、国家再建最高会議第27次常任委員会の議事録を入手して、次のように報道した。
「光復」と「不快感」の間
「この会議に出席した関係者は、米極東軍司令部（在日米軍）が、在日米軍と在韓米軍、韓国軍との連合作戦のために統一された時間が必要だと標準時の変更を要請してわずか数分で通過させたと証言した」
結局、国民の代表機関ではなく、軍事クーデターで成立した「国家再建最高会議」は、米軍の要請があろうクーデターの承認を受けるために、1954年に標準時変更後わずか7年ぶりに東経135°を基準にした時間に変更したものである。 以降の夏時間（サマータイム）の導入根拠を用意するために、1986年に「標準に関する法律」に一回変更しただけで、現在までに我々は、1961年に改正された東経135°基準の標準時をそのまま使用している。
参考資料
http://blog.naver.com/PostView.nhn?blogId=tyahnstein&logNo=100194115583
韓国語で標準時は現在より30分遅くなる利益・不利益をまとめて書いたエントリー。
経験則としては、かなり正しいと思う。もちろん例外はいくらでもあるが、「傾向」としては確かにそうだ。自分の経験則からしても、そうだと思う。
男の40歳というのはかなり微妙な年齢だ。若く保てている人と老けてしまっている人の振れ幅が大きくなる年齢かもしれない。
このひとつの例として、「体型」について考えてみた。
例えば、年齢を重ねるにつれ太ったり腹が出てきたりする男は多いが、その言い訳としてよく言われるのは「歳をとると基礎代謝が落ちてくるから」というものだ。
確かに、歳をとれば基礎代謝は落ちる。しかし、30歳平均と40歳平均の基礎代謝の違いは、1日あたり50kcalぐらいしかない。10年で50kcalほどしか基礎代謝は落ちないのだ。
50kcalというとコンビニおにぎり1個のおよそ3分の1にすぎない。もちろん食事以外の要素もあるとは思うが、単純に考えれば1日にその程度の節制ができれば、理論的には「中年太り」は防げるということになるのではないか。
自分は別に節制をしているわけでもなく、特別にスポーツをしているわけでもないが、特に年齢とともに太ったということはない。むしろ、学生の頃に比べると痩せたぐらいだ。仕事ができるかどうかは知らないが、そのぐらいの節制は苦しいとも何とも思わない。ビールは毎日飲むが、それ以外は普通に節度ある生活をしているだけだ。
「中年太り」は、やはり生活習慣に大きな原因があると思うし、50kcal程度の節制ができないようなタイプであれば、仕事ができない「傾向にある」というのはそんなに無理な理屈ではないと思う。
そして、若く保てているか老けているかは、この「体型」の影響力が非常に大きいと思う。多少老け顔でも、スラッと締まった体型であれば、そこそこ若く見えるように思う。
ttp://b.hatena.ne.jp/entrylist?url=http%3A%2F%2Fwww.north-ai.com%2F
ttp://b.hatena.ne.jp/entrylist?url=http%3A%2F%2Fmuroran.weblog.vc%2F
ttp://b.hatena.ne.jp/entry/www.lovewoof.co.jp/shop/%23shibaura
東京のトリミングサロンなら｜トレーナーがいるサロンなので安心です！ - ペットトリミング店ポータルサイト「ペットの美容室」 c
ttp://b.hatena.ne.jp/entrylist?url=http%3A%2F%2Fcfcvv.so-hot.jp%2F
サービスのご案内 【合コンセッティングサービス コンパde恋ぷらん】
ttp://b.hatena.ne.jp/entrylist?url=http%3A%2F%2Fwww.will-gocon.net%2F
ttp://b.hatena.ne.jp/entrylist?url=http%3A%2F%2Fgolf-koza.com%2F
※これでも１部
もう完全に食い物にされている。
<title>多田建設の技術 | 多田建設</title> <meta http-equiv="Content-Script-Type" content="text/javascript" /> <meta http-equiv="Content-Style-Type" content="text/css" /> <meta name="description" content="多田建設の技術です。マンション建築や公共・土木工事事業で高い評価。" />
ネガティブなイメージをクラスタ全体でマッチポンプ？してるんだよね……まぁ、現代っぽさがある。正直アホかって思うけど
「http://over-lap.co.jp/bunko/narou-award/」の検索結果 - Yahoo!検索（リアルタイム） http://realtime.search.yahoo.co.jp/search?tt=c&ei=UTF-8&fr=sfp_as&aq=-1&oq=&p=http%3A%2F%2Fover-lap.co.jp%2Fbunko%2Fnarou-award%2F&meta=vc%3D
はてなブックマーク - 小説家になろう×オーバーラップ文庫 WEB小説大賞開催！ http://b.hatena.ne.jp/entry/over-lap.co.jp/bunko/narou-award/
第一回オーバーラップ文庫WEB小説大賞開催 - 主にライトノベルを読むよ＾0＾／ http://d.hatena.ne.jp/nunnnunn/20131005/1380995266
こちらに丁寧に記載されていて、感謝の限りです。
注意は
$ wget -q http://linuxmint-jp.net/linuxmint-ja-archive-keyring.gpg -O- | sudo apt-key add -
$ sudo wget http://linuxmint-jp.net/sources.list.d/linuxmint-ja.list -O /etc/apt/sources.list.d/linuxmint-ja.list
の、最初の行の -0- は、英大文字のオーかゼロ。 2行目は 英大文字のオー。
※最初-O-をオーでやったら「PGPファイルがみつかりません」とエラーになった。ここを数字のゼロにしたらあっさり"OK"と表示。このエントリに「ゼロです」を書いたものの、上記公式ページをみるとどうもゼロには見えない。念のためにもう１回ゼロでやってみたら「無効なオプション」だってさ（なので投稿内容を直した）。じゃあ「オー」が正しいのかよ？けど、おいら数字のゼロでうまくいったんだぜ。最近、いろいろPCに馬鹿にされてるわ。VirtualBoxにインストールしていたので手打ちで実行させたから、コピペ可能環境ならいちいちこんなことで問題にならなかったのかな？まさかコピペのオーはOKで、手打ちのオーはNG？
export http_proxy="http://＜プロキシサーバ＞:＜ポート＞"
さらに
/etc/apt/ のなかに apt.conf というファイルを作成して
Acquire::http::proxy "http://＜プロキシサーバ＞:＜ポート＞";
（最後はセミコロン）の１行を書き込みます。apt-get へ教えます。
Linux Mint のベースである Ubuntu でも同じかな？
過去のバージョンでは、設定（Windows でいうコントロールパネル）の "Network Connections" から指定できたようだけれど、Mint 15 では設定ファイルをいじる必要があるらしいです。
プロキシサーバを利用するには、システム共通の設定をしなくても FireFox なら GUI の設定から個別指定ができるけど、Google Chrome は 「コマンドライン引数で指定するか、システム共通設定をしてください」とのことで、共通設定をせねばならないようです 。
で、そのシステム共通の設定は "dconf-edit" （Windows でいうレジストリエディタのような存在？）というツールをインストールすると、そこから設定ができるみたいですが、このツールは標準ではないのでネットからダウンロードせねばならない。apt-get でダウンロードしてインストールさせるものの、この apt-get にプロキシ設定をしなくてはならない。
/etc/apt/に apt.conf という名のファイルを作成して
Acquire::http::proxy "http://＜プロキシサーバ＞:＜ポート＞"
で
sudo apt-get install dconf-tools
（パッケージ名は "dconf-edit" や "dconf-editor" ではない）でインストール。終わったら "dconf-editor" とたたけば、GUI で dconf-editor が表示される。ツリーの System ＞ proxy で mode を manual に、さらに http のなかにある host, port, enabled に登録（除外設定や、各プロトコル共通化は System ＞ proxy の Ignore-hosts, use-same-proxy で）。
で Google Chrome を起動、あれ、だめじゃん。。。再起動もさせた。Firefox ではシステム共通設定を読ませてうまくいく。Chromeよ、あんたのために調べもの含めて2時間かけたんだぞ。こんなんばっかで嫌になるよ。「嫌なら使うな」が基本だろうが、業務のために Linux で Flash Playerの動作試験をするために Chrome を使うしかなかったんだ。どうやって日報に書けばいいんだ？Googleから給料分もらってくれと書きたい。
と書いたあと、もう1回再起動させたらFirefoxもだめになった。いじわるだよまったく。日報に「Firefoxではうまくいきます」なんて書かせて恥をかかせたかったのかと勘繰りたくなるよ。
とりあえず、Google Chrome についてはコマンドシェル (Terminal) から
google-chrome --proxy-server=http://＜プロキシサーバ＞:＜ポート＞
と指定して、とりあえずプロキシサーバを利用させることはできたけど。
export http_proxy=http_proxy=http://＜プロキシサーバ＞:＜ポート＞
などと実行させて、次に
や
で、除外判別とかはどうするのだろう？ Linux 起動時にこの環境変数の内容を自動で設定させる方法とか、どんな方法が標準なのだろう。
問題があったら消して下さい。
運営側で対処済みor自分の勘違いならいいけど、どうなんだろう。
(2)はてなブログで人気のあるブログを探す。「site:hatenablog.com」でググって最初の方で出るブログがいいんじゃないかな。
(3)そのブログが更新されたら、とにかく最初にスターを入れる。
スターをクリックすると自分のブログへのリンクになるので、簡単に被リンクを増やすことになる。最初のスターは★32★みたいな形になっても見えるので、アイコンや引用スターの入れ方によってはクリックしてもらいやすくなる。
と思ったけどダメかもしれない。
スターの表示はDOMでやってるみたいだから普通にHTTPで聞いた生HTMLには反映されないのでGoogleパーサたんは認知してくれない気がする。
でも、その割りには今年に入ってGoogleでの扱いが急に優遇されたんだよな。
３年間休職中かつ求職中です。はてなにいるとハイスペックな人間ばかり目につきます。それに比べると自分のスキルがあまりにもチープなので、社会復帰できるかかなり不安な日々を過ごしてます。社会復帰はIT関係じゃ無くてもかまいません。あと、真面目に悩んでいるので、自慢や手前味噌をするつもりはありません。世の中で求められるスキルがどんなものかをあまり把握してないので。
このスペックで今後生きていけるのかなあという心配と、今後これをやっておけば優位に進められるというものを知りたいです。
以下職歴。
・2000年、SEとして入社後、現地常駐徹夜仕事の繰り返しでうつ病を発症。プロジェクトマネージャまではならず、大手の仕事のプロジェクトの部品をちまちま作るデジタル土方でした。休職後職場復帰しましたが、入社3年ほどで自主退職。
・症状が重く、2000年代はとても働ける状態じゃなく、暗黒の時代。2010年代で光が見え始める。
・それでもHTTPやCSSを学んで趣味レベルのWebサイトを作成。
・2008年から海外フリーソフトの日本語訳を手がけ、５年経った今もバージョンアップを継続中です。
・2012年、英検2級取得。2013年、TOEIC775点取得。
若い人が新しい技術を開発＆習得しているので、その勢いに押されっぱなしです。自分が１年かけて憶えた物でも、若い人には数ヶ月であっちゅう間に追い越されます。日ごとに食い扶持が無くなっていき、今後の将来がとても不安です。
【Webサーバを作る】http://d.hatena.ne.jp/kmaebashi/20130804/p1
use Fcntl;
use strict;
use Socket;
use threads;
use POSIX qw(strftime);
use File::Spec::Functions qw(rel2abs);
my $thread = threads-＞new(\＆serverThread, "");
$thread-＞join;
my $ret;
my %hashmap=(
"htm" =＞ "text/html",
"txt" =＞ "text/plain",
);
$ret = $hashmap{$_[0]};
if ($ret eq "") {
return "application/octet-stream";
} else {
return $ret;
}
}
my $documentRoot = rel2abs("D:/var/www/html");
my ($line, $path, @tmp, $ext, $data, $absPath);
socket(SERVER, PF_INET, SOCK_STREAM, getprotobyname('tcp'));
bind(SERVER, sockaddr_in("8001", INADDR_ANY)) || die;
listen(SERVER, SOMAXCONN) || die;
while (accept(CLIENT, SERVER)) {
while (＜CLIENT＞){
$line = $_;
last if ($line eq "" || $line eq "\r\n" || $line eq "\n");
if (index($line, "GET") == 0){
$path = (split(/ /, $line))[1];
@tmp = split(/\./, $path);
$ext = @tmp[$#tmp];
}
}
print CLIENT "HTTP/1.1 200 OK\r\n";
print CLIENT "Date: " .strftime("%a, %d %b %Y %H:%M:%S GMT", gmtime). "\r\n";
print CLIENT "Server: Sever03.java\r\n";
print CLIENT "Connection: close\r\n";
print CLIENT "Content-type: ". getContentType($ext). "\r\n";
$absPath = rel2abs($documentRoot. $path);
if (index($absPath,$documentRoot)==0 ＆＆ sysopen(FH, $absPath, O_RDONLY | O_BINARY)) {
while ($data = ＜FH＞) {
}
close FH;
}
close CLIENT;
}
}
コアモジュールだけ使った。
元ネタのJavaコードはディレクトリトラバーサルになってたんで、一応対策を盛り込んだ。
といっても絶対に外向けに動かさないように。無いと思うけど。
いろいろツッコミくれるとうれしいです。
http://d.hatena.ne.jp/iad_otomamay/20130318/1363596244
この記事。本当に腹が立ちました。
まず質問自体が酷いのが多い。
省略したのは知らないと障害の危険があるので知っとくべきってことで同意なんですが、
これは使うときにググれば良い話。暗記しておくメリットがわからない。
結合テスト中のシステムで、OutOfMemoryErrorが発生しました。UT後ソースコードの変更はしていません。ヒープメモリは足りているようです。原因として何が考えられますか？（筆記解答）
「UT後ソースコードの変更はしていません」という一文が意図不明。単体テスト終わった後にソースコード変更したら、再度単体テスト必要だと思うのですが？この一文は何のヒントにも制限にもなっていないです。
なぜNGなのかというのは「文字列連結演算子(+)では速度が遅いから」であり、StringBufferかStringBuilderのような結合用クラスのappend()を使うことでパフォーマンスは向上する、というところまでが質問の狙いなのかと思いました。もう一歩踏み込むならば、+をしたときにコンパイラでどのようになるかを知っているかどうか、みたいな。しかし結合用クラスにはデメリットもありまして、append()は冗長過ぎて可読性が酷く低下するデメリットがあります。文字列の連結時にクラスをnewするタイミングを調節したほうが速くなることもあります。近年ではマシンのスペックもあがってますので、そんなに気にする部分ではないと思います。そもそも、このStringBufferの仕組みは絶望的に救いがないJava言語の汚点と言ってもよい部分です。なんで文字列の連結方法に複数のやり方を速度だけの理由で取捨選択させるというバッドノウハウなので、早くコンパイラが最適化して一元化くれることを望む部分です。
StringBufferかStringBuilderと書いていて、そういやスレッドに関しての質問がないのはどういうことなのかと感じました。JavaのWeb系ってスレッド重要だと思うのですが。
JavaScriptでHTML要素をid属性の指定により取得するメソッドは何ですか？（筆記解答）
もうjQueryやDojoも使われるようになってきたからこれも知らなくてもいいんじゃないかと。id指定で取れるということとを知っておけば答えにはたどり着けるはず。バッドノウハウです。どうしてJavascriptが最近になって流行ってきたかを思い出して欲しいです。
プログラマーはバッドノウハウの塊でなくてはならない、というのが見えてくる質問内容ですが、最近は覚えなければならないことが多く、技術の更新スピードも早いので、あの質問のような重箱の隅まで暗記するようなことをしていては、重要な部分が抜け落ちているし、暗記の苦手な人は辛いと思います。書籍もネットのような情報の蓄積と抽出する部分は充実してきたので、概念は知っておいて、実装手段はその都度調べるほうが効率的であるかと思います。質問は、応用の効く根本的な部分を問う方がよかったです。
「現実は、もっと凄惨な世界を経て時代が進んでいくようだ。」などと締めくくっていますが、この人は凄惨な世界が嫌なのでしょうか？不安を煽るだけで対策も講じていません。まず、質問の回答を書くだけでも、読んだ人の知識の底上げに貢献できると思うのが普通です。「これは基礎教育をやってれば当たり前」とか言ってドヤ顔して、できない人間を馬鹿にしているだけに見えます。本心では凄惨な世界を望んでいるのでは？としか思えてなりません。
この記事を読んだことで、またSI業界から優秀な人が遠のくことでしょう。こんな人間が居る業界には居たくないと。
どうして悲しみを減らす方向に動いてくれないのかと…
※追記
頭沸騰しててスルーしてしまったのですが「淘汰」って書いてあったので、業界の底上げは望んでないんだなあと、見当はずれなこと書いてしまったなあ、と、後悔した。
これまで他の人に用意してもらったサーバで自分のプログラムを動かしたことはありましたが
自分自身で一からサーバをセットアップしたことはほとんどなかったので、いろいろとハマりました。
作業を進める上で困ったり考えたりしたことを書いていきます。
ちなみにサーバ自体はさくらのクラウド、OSにはCentOSを使用しているので、それ前提のお話になります。
最初にサーバを起動してから速やかにSSHとファイヤーウォールの設定を変更しました。
はてブなんかでも定期的に話題になっているのでおなじみですね。
・SSHやHTTP(S)など、どうしても公開しなければならないポート以外は遮断する
さらっと書きましたが、設定をミスって自分自身もログインできなくなり、何度かOSの再インストールを繰り返しています。
後から気付いた事ですが、さくらのクラウドではクラウド管理画面のリモートスクリーン経由でローカルログインできるので
別にOS再インストールしなくてもiptablesの設定を変更できたんですよね...
逆に言うといくらファイヤーウォールとSSHを設定しても管理画面にパスワードログインの環境が残ってしまうので
パスワードの管理には引き続きしっかり気を使う必要がある。ということでもあります。
httpd,php,mySQL,memcachedなど必要なサービスをインストール、設定し
作成したWebアプリのプログラムを乗せて動かしてみました。が、動作が重いような...
開発環境ではさくさく動いていたのに、本番環境ではどのページ遷移ももっさりしています。
abで計測してみたところ、開発環境のおよそ2分の1のスコアとなってしまいました。
開発環境が仮想2コアのメモリ1Gだったのに対し、本番環境が仮想1コアのメモリ2Gと
CPUの性能について半減しているのでそのせいかな、と思いつつ設定を見なおしていたところ
特に使っていないと思われたipv6を停止した途端にパフォーマンスが改善されました。
ページ遷移に伴うもっさり感が解消され、abの計測結果も開発環境と遜色ない結果が出ています。
デフォルトで有効になっていたipv6の影響により余計な処理が走っていたのかもしれません。
パフォーマンス改善に喜んだのも束の間、会員登録などの処理でWebアプリからメールを送信したところ、Gmail宛のメールがことごとく迷惑メールと判定されるという事案が発生。
spfの設定を行なう、メールの内容について吟味するなどの回避策を試してみましたが一向に改善されません。
試しにHotMailとexciteのメールアカウントに送信したところ、そちらではそもそもメールを受け付けてもらえずエラーコードが返って来る始末。
困り果てていたところ、エラーの内容からサーバのIPがspamhousにスパム送信元として登録されていることが判明しました。
postfixのホスト名の設定がデフォルトで「localhost.localdomain」などとなっており、それをそのまま使っていたためにGmailがスパム送信元として通報してしまったようです。
設定を修正し、spamhousに解除依頼を提出。事なきを得ました。
クラウドを利用すれば、サーバを停止することなく簡単な設定でスケールできるようになる。
と、自分で勝手に思い込んでいたせいなのですが、消えては困るデータの一部をmemcachedに保存する実装を行なっていました。
実際のところさくらのクラウドではサーバを完全に停止しなければプラン変更を実施できないし
そもそもサーバが落ちたらどうするんだよ。ということで、急遽KVSを変更する必要に迫られました。
速度の低下が気にかかったため、いくつかの候補を実際に動かし
phpのスクリプトから1万件のデータ読み書きを行うという形でmemcachedと比較してみたところ次のような結果に。
| サービス | 1万件書込 | 1万件読込 |
| memcached | 2.55秒 | 2.30秒 |
| handlersocket | 21.23秒 | 2.71秒 |
| InnoDB | 20.23秒 | 5.10秒 |
| kyotoTycoon | 8.22秒 | 7.72秒 |
さすがに読み書きそれぞれmemcachedが最速ですが、読み出しについてはhandlersocketも負けていません。mySQLから普通にSELECTしてもmemcachedの2倍程度の時間しかかからないという結果が意外でした。
しかしながら書き込みのほうではhandlersocketもmemcachedの10倍近くの時間がかかっており、少々速度的な影響が気になってきます。memcachedの倍のパフォーマンスを記録したという記事を見たことがあるので、設定、チューニングについて生かしきれていない部分があるのかもしれないとも思いましたが、知識が不足しているところで無理をすると問題が発生した時に対処できないと考え、候補から除外することとしました。
結局、今回の用途では読み込み処理より書き込み処理のほうが圧倒的に多いことも考慮し、kyotoTycoonを採用しました。実際の利用箇所に組み込んでabで計測してみたところ、だいたい30%程度のパフォーマンス低下にとどまっており、これなら許容範囲かと考えています。
実行系と参照系に分ける形でmySQLのレプリケーションを行なっていたのですが、度々レプリケーションが停止する現象が発生しました。
一部のテーブルについて肥大する可能性が考えられたため、参照系に接続するプログラムで使わないテーブルをレプリケーションから除外していたのが原因です。
例えばtabelAをレプリケーションし、tableXをレプリケーションしないという設定にしたうえで
実行系でINSERT INTO `tableA` SELECT `value` FROM `tableX`などといったクエリを発行すると、参照系にtableXが無いためエラーが発生して止まってしまいます。
レプリケーションするテーブルを限定する場合はプログラム側でも注意を払わないと危険です。当たり前ですが。
監視といえばcactiやnagiosが定番なのかもしれませんが、設定が複雑そうで尻込みし、monitを使用することにしました。
簡単な設定でloadaverageやメモリ、HDDの使用量をチェックできるほか
httpdやmysqldなどといったサービスのプロセスを監視し、もし落ちていたら自動で起動してくれるので助かります。
パスワード保護を行うとしても、サイト全体の管理画面など自分しか使わないプログラムはWebに晒しておきたくない。
というわけで、一部のWebアプリを秘匿する設定を行いました。
管理画面のWebアプリを9999番など閉じているポートに設置した上で、SSHを利用したトンネルを掘ります。といっても
上記のようなコマンドで管理画面のWebアプリを置いたサーバへログインするだけです。
ブラウザのアドレス欄にhttp://localhost:9999/と打ち込めば、接続が開いている間のみアクセス可能になる感じですね。
サーバにログインできる人でなければ実行できないことなので、気分的にある程度安心します。
自動でログのバックアップを行いたいと考えたのですが、パスワード無しの鍵でログインして転送する形には抵抗がありました。
調べてみたところ、authorized_keysに公開鍵を記入する際の設定で、その鍵でできることを制限するという手段があるようでした。
具体的には、authorized_keysに
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="some commands" ssh-rsa AAAAB3NzaC1yc2EAAA...
などとして公開鍵を追加しておくと、その鍵でログインした直後にcommand=""の部分で設定したコマンドを実行して接続を終了する挙動となり
接続のフォワードもできなくなるため、パスワード無しでも鍵の流出に関するリスクを最低限に留めることができるというわけです。
commandの実行結果は標準出力から受け取ることができるので、例えばcommand=""の部分にファイルの内容を表示する処理を設定していたとすれば
ssh -i .ssh/no_password_key user@xxx.xxx.xxx.xxx > /path/to/file
などとしてログインの結果をファイルに書き込むだけで、簡単にファイルの転送が実現できます。
他にも大小さまざまな問題に行きあたりましたが、忘れてしまったor書ききれないのでここまでとします。
たった1つのサイトを公開するにしても問題というのは尽きないものだと実感させられました。
今は基本的な情報だけでなく、ちょっと突っ込んだ内容でも検索で解決していけるので嬉しいですね。手がかりを残してくれた先達に感謝することしきりです。
現状ではひとまずの見切りを付けて公開していますが、より堅牢で負荷に強いサーバとなるよう、随時チューニングを行なっていこうと考えています。
個人サイトや小規模な商業サイトなどプロモーションにあまりお金をかけられないサイトを主な対象とした、無料で出稿できる広告ネットワークサービスです。
既存のサービスで近いのは「あわせて読みたい」や「zenback」、各社提供のRSS相互リンクサービスなどになるでしょうか。
広告としての体裁がある分、それらより若干積極的な性質になるのではと考えています。
現時点ではサービス本体のプロモーションに苦心するという本末転倒そのものの状況でありますが、もしよろしければ見ていただけると嬉しいです。
ちなみに僕の棋力は、ボナンザの中級に勝ったり負けたりする程度のヘボですので深いことは全くわかりません。
詳しい人は突っ込みよろしく。
http://blog.livedoor.jp/goldennews/archives/51769973.html
放送見てたら羽生の表情が演技だとは思わないはずなので、あれは言わばキャプチャ芸というやつだ。
それがまとめブログに載って拡散していくうちに、本気で「羽生さんが負けそうな演技をして相手を油断させたんだ」と思う人が出てくる。
ブコメを見てもチラホラと。
別に、まとめブログやtwitterで面白おかしく脚色されて広まることはよくあることだし、一概に悪いことだとは言えない。
確かに、「羽生さんが明らかに負けそうな表情をしたけど最後は結局勝ちました」というネタはそれなりに面白い。
いいんだけど。この将棋は、ネタとして消費するにはあまりに惜しいくらい凄かった。
それこそ、「羽生さんが明らかに負けそうな表情をしたけど最後は結局勝ちました」なんていうネタの数十倍面白かった。
だから単なる羽生コピペ的なネタのひとつとして消費してしまうのはもったいないと思う。
なのでちょっと解説したい。
NHKでは日曜日の昼の時間に将棋の対局を放送しているんだけどこれは4月始まりで、一年間掛けて５０名が争うトーナメント戦になっている。
上のまとめブログの羽生が負け演技をした、とされる対局は先の日曜日に行われた準決勝のようすだ。
つまり一年近くをかけてトップ棋士５０名がベスト４まで絞られた状態である。
残っているのはどいつもこいつも化け物級の強豪ばかり。
羽生の対戦相手は郷田真隆棋王。羽生と同世代のライバルの一人である。
タイトルホルダーでA級棋士。第一人者中の第一人者であり、間違いなく将棋界のトップに立つ一人である。
その棋風は「格調高い」と形容され、プロ棋士たちも郷田の棋譜をお手本にするほどだ。
柔和で端正な顔で、女性のファンも多い。
対局は、終始先手の郷田ペースで進む。
終盤、持ち時間を使い切った所で、郷田が５三桂成と羽生の王を詰ましにかかる。
勝負に出た手だ。
結果から見ればコレが悪手となった、ようだ。
優勢な郷田が焦らず、慎重に打っていけば勝てたはずだったというのが解説の先崎八段の見解である。
相手が羽生でなかったら、郷田がそのまま押し切っていた可能性もある。
このタイミングで仕掛けなければ結局郷田が負けていた可能性もある。
勝負をかけて踏み込むか、とどまるかといった駆け引きは対局者達にしかわからない深い領域の読み合いの結果だ。
郷田の手が悪手というのも結局羽生が勝ったという結果が出た後だから言えることなのかもしれない。
ともかく、羽生は踏み込んできた郷田の勝負手をギリギリのまさに紙一重のところで躱した。
そして羽生に手番が回ってきた。この瞬間を逃せば勝機はない。
詰ませなければ羽生の負けは確定だ。
持ち時間は使いきり、考える時間は一手につき３０秒未満しかない。
まとめブログの羽生の苦悶の表情はこのタイミングの時の表情である。
終始劣勢な中で唯一にして最後にして最大の勝機が見えた瞬間。
ここを逃せば敗北は確定である。
はたして詰むや詰まざるや。
その時の動画がコレだ。
http://www.youtube.com/watch?v=swkQmaiBsSw
ちなみに先崎八段は３月のライオンの監修をしていたりもする。これまた将棋界の第一人者である。
聞き手「でもいまちょっと慌てた感じでしたが」
解説「そうですね……。（絶句）なるほど！最後７二に桂が打てると言ってるんだ。いやーこれは……凄いことが起きましたね。いやこれは気が付かなかった。天才ですねさすが」
聞き手「なるほど……。すごい……」
解説「いや天才です。いやー羽生さんは昔から天才だとは知ってたんですけどね。なるほど天才の詰みですコレは。（中略）いや天才ですね。いやもう」
冒頭にも書いたが、僕は３手くらい先しか読めないヘボ棋力である。
そんな僕ですらゾワゾワと鳥肌が立って、変な笑いがこみ上げてくるほど、この終盤の手は神がかり的だった。
先崎八段は天才集団のプロ棋士の中で、そのトップクラスにいる、言わば天才中の天才である。
プロ棋士をここまで、動揺させ、驚かせる。羽生の指したのはそんな手だった。
それに至る道筋を考えていた時の、我々常人には及びもつかない深い読みに入っていた表情が例のまとめブログに載っていた苦悶の表情である。
そりゃ、あんな顔もするであろう。
間違いなく、今棋界で一番強い二人である。
次の日曜放送だ！見逃すな！
エロが好きです。
ボクはDMM.R18のヘビーユーザーなのですが、どうしても自分の好みの中だけで、グルグル回ってしまい、
世の中にAVは山ほどあるはずなのに、知らないなんてもったいない！もっとたくさんのエロに出会いたいという思いがあって日々悶々としていました。。
そんな中、AVというのは毎日の気分によってオナニーしたい見たいものが違うわけだから（例えば毎日食べたいおかずが違うように）、
今の自分の気分を簡単に答えれば、それに対してオススメのAV動画を紹介してくれるというサービスはどうだろう？とモヤモヤと考えていました。
ある日、会社の人に相談したら、それ「いいね！」ということになって、「そういえばDMMのAPIってのが公開されたから、それ使ってできるんじゃね？」ってことになり、
本格的にサービス開発を行うことになりました。
そしてこの度無事リリースすることができました。
「今夜のおかず」
３つの質問に YES / NO で答えるだけで、今のあなたに最適なアダルト動画を紹介するサービスです。
・フレームワーク：express（node.jsのフレームワーク）
・クライアント：jQuery、CoffeeScript、SCSS
・ビルドツール：grunt
node.jsは少し趣味でやった程度で、今回やってセッション管理やルーティング周りが勉強になりました。
データベースにはMySQLを使っています。node.jsならばmongoDBというイメージが強いですが、質問をランダムに表示する機能で、
mongoDBは現時点で正式な機能としてはランダム検索が出来なかったので、MySQLを選びました。
あと、CoffeeScriptやSCSSはJavaScriptやCSSの記法を簡単にしてくれるやつで、慣れてしまうと離れられません。
あとはTwitter Bootstrap。これなしでは生きていられません。
スマホでもなるべく早く結果ページまでたどり着けるようにしたつもりです。
オススメの動画が表示された後に、今日はこの動画の気分じゃない！と思ったときはチェンジボタンにより、同じ条件で他の動画にチェンジ！できます。
質問からやり直したいときは、さいしょから！ボタンで他の質問からやり直せます。
一刻一秒を争うエロビ探しですのでパフォーマンスには気を配りました。
最初はサーバーサイドでHTMLテンプレートを使わずに完全にREST API化して進めていましたが、
最初の表示までの若干のライムラグとSEO対策の為、最初の質問だけnode.jsでHTMLテンプレートを使用して組み立てています。
また、シンプルなサイトなのでライブラリはjQueryのみ使用し、concat/minify化はgruntのタスクとして登録しています。gzip化はNginxで行なっています。
我らがDMM様への敬意を払い、白ベース＋ポイントで赤のシンプルなデザインにしています。
・CSS（SCSS）が初めてだったので、微調整するのが大変でした。
・質問のパターンを考えるのと、紹介する動画が偏りすぎないようにするのが難しかったです。（これはまだ要調整）
・質問に対するおすすめ動画の精度をもっとあげていく。 （ユーザーの癖を把握して、機械学習とかできればいいかなと）
・おすすめ動画を表示した後に、その商品を誰かにつぶやいたり。
今回、同じ会社に勤めるエンジニア3人が約2ヶ月で作成しました。
実験的なサービスでもありますので、今後も色々と機能追加をしていくつもりです。
http://d.hatena.ne.jp/perlcodesample/20130227/1361928810
たとえ動的型付けでも整数と文字列は足せないわけで、結局型がないわけではない。そう言った意味で、動的型付けの恩恵を得るには暗黙の型変換が必要不可欠だ。またダックタイピングによって関数へ適用できる型が静的な言語より広いことが多い。そう考えると動的型付けのパワーは、関数に渡せる値が幅広いおかげで以下の2つのご利益があることだと思う。
動的型付けをする言語では、ほとんどのものを文字列や、汎用のリスト型や辞書型のまま表現することが多い。これに対し、静的な型付けをする言語では専用の型をどんどん用意し、それらの型を変換する関数を用意しておく。型が多ければ多いほど、関数は部分関数から全域関数へと近づく。つまり不具合は減る。よって、静的な型付けをする言語で正しく型を設計することで不具合を減らすことができる。
しかし、その分型を明示的に正しく変換する必要がある。IPアドレス型、HTTPヘッダ型、Cookie型、ファイル型・・・様々な型をそれぞれ正しい記述で書く必要がある。対して動的な型付けの言語ではこれらを文字列や辞書型のまま扱う傾向が強いので、それっぽい文字列やそれっぽい辞書をマニュアルなしで組み立てて関数に渡すことができるので、開発工数が低い可能性がある。
もっとも、IDEが優秀であれば型変換する関数を正しく予測してくれるのかもしれない。ので、型変換するコードを瞬時に書ける程度優秀なIDEがあれば不具合が少なくて済む分静的型付けの方がいいし、そういうIDEがないのであれば文字列や基本型だけの知識でどんどん書ける動的型付けに軍配があると言えるんじゃなかろうか。
不具合のないプログラムを書くのであれば、動的型付けでも静的型付けでも生産性は一緒な気がする。むしろ静的型付けの方が不具合が入り込む余地がもともと少ない分生産性は高くなるだろう。多くの人が認める通り、不具合のあるプログラムを書くことはプロとしてあるまじき行為で、恥じるべきだ。
しかし、不具合のあるプログラムは世の中に存在しえないもので速攻削除すべき、と考えるのは行き過ぎだ。残念ながら現実は学問や理論の世界とは違う。プログラムが以下の条件を満たす場合、不具合があってもなくてもいいので、とにかく素早く作ることが求められる。不具合があってもいいのであれば、前述したように少ない知識でも適当に組める動的型付け言語の方が、とりあえず動くまでの期間や人的リソースの調達のしやすさなど、軍配が上がる可能性は高い。不具合のあるプログラムでも許容されるのは以下の場合だ。
3つ目の理由がとにかく大きい。「1日でバグだらけのものを作って動かし始め1ヶ月後にバグをほぼなくす」のと「2週間でほぼバグがないものを作って動かし始める」のとでは、前者の方が金額で言えば後者より倍優れていることになる。バグのある物をお客さんへ提供しているにも関わらず、だ。
もう言わなくても分かると思うが、この条件に当てはまるのがWEBサービスの開発だ。ユーザに多少エラー画面が出ても、ほとんどのユーザはそんなの慣れっこだ。プログラムはサーバにアップロードすれば簡単に修正できる。そんなWEBサービスださい？恥ずかしい？ああ、そうだ。しかし、そんなこと関係なしに、リリースすれば財布にはお金が入ってくるし、しなければお金は入ってこない。
逆にこれらの条件にあてはまらない開発はたくさんある。医療系や金融系は不具合の損失が重大過ぎる。組み込み系やパッケージ系は、製品を売り初めてしまえば修正は困難だ。
普段はあまりネットで発言したりはしないのですが、今回の大阪市立桜宮高校の体罰問題についてはちょっと言っておきたいことがあるので、ここの匿名ダイアリーを借りて発言させて頂きたいと思います。
事件の概略やらなんやらはネット上にいっぱい情報が乗っているのでここでは省きます。今回私が言いたいことは、｢なんで、体罰被害者であるはずの学校のOBとかに体罰容認論者が多いの？｣という事についてです。
参考リンク「先生は間違っていない」“熱血”指導で全国大会常連校にした顧問 桜宮高２自殺(http://headlines.yahoo.co.jp/hl?a=20130108-00000578-san-soci)
なぜ、体罰を受けてきた学校OBたちに体罰容認論が多いのでしょうか？なぜ体罰を受けてよかったと思っているのでしょうか？
結論から言ってしまえば、体罰を受けてきたOBたちは皆｢体罰は是であると教育されてきた｣からだと思います。
例えば、タバコを構内で吸っている生徒が居たとします。そこに先生がやって来て、生徒のタバコを取り上げ、平手打ちを一発かまして、｢タバコなんて吸うんじゃない！｣と怒鳴りつけたとしましょう。この時、教育を受ける側である生徒は先生からどのようなメッセージを受け取るでしょうか？
一つは｢未成年がタバコを吸ったらいけない｣という事でしょう。しかしこの時、生徒はもうひとつメッセージを受け取ることになります。それは、｢学校でタバコを吸っている奴を見かけたら先生は平手打ちをしてもいい｣という事です。
要するに、生徒は、先生の発言と、行動から学ぶわけです。よく言う｢子どもは親の背中を見て育つ｣というのがこれです。
これは子どもの側から見たら当たり前で、自分たちの未来の姿である親や先生たちの行動は、自分たちの指針になるものなのだから、親や先生が自分たちの目の前でやったことは、大人になったら自分たちもやっていいと考えるのは当然のことです。
と言うよりも、そうやって子供たちに社会の中でどのように振る舞えばいいかを教えるのが教育というものであると私は思います。
(自分で手本を見せることもせず、頭ごなしに怒鳴りつけるような人もますがそういう人は親としても教育者としても失格であると思います)
今回の場合、バスケ部の主将が、｢ミスをしたら殴られた｣というものですから、部員たちは、｢主将がミスしたら殴られる｣ということと｢先生は主将がミスしたら殴ってもいい｣という事の2つのことを学んだわけです。
そうすると、特に素直な人は、｢先生は主将がミスしたら殴ってもいい｣と信じ込んだまま大人になってしまいます。
これは要するに、幼い頃に虐待を受けた親は自分が親になった時、自分の子供を虐待する傾向がある。という事と全く同じ事です。
参考リンクhttp://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=8&ved=0CGcQFjAH&url=http%3A%2F%2Fwww.daiichihoki.co.jp%2Fdh%2Fupload%2Ftrial%2Ftrial603993.pdf&ei=m9LyUIX_NYSbkgXv2YHYCw&usg=AFQjCNELyTw1qGQpi2wQfpN_8d-6Ip83Qw&sig2=JhJyQYLnmZhlP59LKTehAg&bvm=bv.1357700187,d.dGI
更に、被害者が多いという事は加害者も多く。また、被害者が加害者になるケースを考えると、ねずみ算式に加害者が増えていくという点で虐待よりもたちの悪い社会問題とさえ言えると思います。
(体罰が正義かどうかという点についてここで議論する気はありませんが、教育者が子どもに対して｢暴力｣という社会的に許されない手段を子どもに正しいこととして教えてしまう可能性があるという点において、｢体罰｣は間違っていると私は考えます。)
新しいはてなブックマークのデザイン，PCで観ているブクマヘビーユーザーからは概ね評判が悪い．これは一ページの情報量がごっそり減ってしまったためで理解できる．
一方，iPadで見るとこのレイアウトはかなり悪くない．エントリがタイル表示で選択できてそれなりに格好いい．PCではほとんどの人がブラウザの機能で消しているであろう広告欄ともうまくまっちしていて格好いい印象すらある．
なんだかんだで個人用のブラウザはPCという時代はもう終わってタブレットや携帯の時代になったということではないだろうか．騙されたと思って皆もタブレットで見てみるといい．けっこういけてるから．
思った改善点としては，
ニコニコの表示オプションで1 2 4とあるのが強制で3になっているようなもの．エントリの「1」列表示を選ばせて欲しい（できればそれをデフォルトに）
動画カテゴリ以外では，この二本目のカテゴリ選択はスカスカで勿体無い．ここは時系列のオプション，ブクマ数の閾値を選んだり，次ページへのリンクがあるべきであろう．
デザインは所詮はCSSの問題にすぎないし嫌なら外部でいじって変えることもできる．でもはてブの機能はすごく貧弱だし（例えば重複しているブクマをサジェストする機能がない．http/httpsでエントリが分裂する，臭いダジャレをフィルタする機能がない，etc.），デザインは機能にあわせて作られるべきだと思っている（UX）．デザインよりも大事な事，まずは作りこんだほうがいいんじゃないかな．
