知って得する！５５のRubyのトリビアな記法
Rubyはたのしい言語です。Rubyを触っているとマニュアルにも書いていない「小さな発見」に遭遇することがよくあります。このような「発見」は、プログラムの質や効率の改善には直結しないかもしれません。いや、むしろチームプログラミングでは妨げになる可能性すらあります。しかしその一方で、言語自体が自分の知らない領域を持ち続けていることが、その対象に対する興味を失わせないための大きな要因である、というのもまた疑いのない事実なのです。つまり「発見」はたのしさに直結しているのです。 このブログにおいて「知って得するRubyのトリビアな記法」というタイトルで、今まで３回記事を書きました。 “知って得する21のRubyのトリビアな記法” “第２弾！知って得する12のRubyのトリビアな記法” “第３弾！知って得する12のRubyのトリビアな記法” これらのトリビアには、ネット検索で見つけたもの、Twitt
HE.net で始めるIPv6接続 - # cat /var/log/stereocat | tail -n3
はじめに 9月アタマに引越をしたんですよ。で、それまでは 6to4 を使っていたのですが、引越に合わせて固定 IPv4 な環境用意したことだし、ちょうど tokyo6to4 もリレールータサービスを終了してしまった*1…ということもあり、別な方法で IPv6 アドレスを調達することにしました。 そんなわけで、本当はプロバイダでネイティブ IPv6 使えるといいのですが、固定IPv4/IPv6 を提供してくれる(かつリーズナブルな値段で)…ってところはまだあんまりないんだよね。今回 interlink の固定 IPv4 サービスつかってるんですが、まだ IPv6 サービスがない…。FAQ には 2012年内に予定…という文言があるんですがホントにやるんですかどうなんですか。 ってことで、あとはその他の IPv6 トンネルサービスを使うわけです。 IHANet 接続手順 - IHANet (I
暮らしの情報サイトnanapiはサービスを終了いたしました | nanapi [ナナピ]
2020年8月31日(月)をもちまして、nanapiに関わるすべてのサービスは終了いたしました。 nanapiは、2009年のサービス開始より「みんなで作る暮らしのレシピ」という考えのもと、ユーザーの皆さまに生活に関する様々な「ハウツー」を投稿していただく投稿型ハウツーサービスとして運営してまいりました。 約11年間にわたって皆さまからご支援をいただきサービスを継続できたこと、nanapi編集部一同、心より御礼申し上げます。 掲載されていたコンテンツなどのnanapiについてのお問い合わせは、nanapi@supership.jp までお願いいたします。 長きに渡りnanapiを応援してくださり、本当にありがとうございました。
第6回 クラウドサービスの比較：AWS、Windows Azure、さくらのクラウド | gihyo.jp
今回でこの連載も最終回です。これまでAmazon Web Services、さくらのクラウド、Windows Azure、Google App Engineについて触れてきました。最終回ということでこれらのベンチマークを比較してみたいと思います。 unixbenchで比較 Amazon Web Services（AWS）、さくらのクラウド（以降さくら）、Windows Azure（以降Azure）は、IaaS（仮想サーバ）がありますが、Google App EngineはPaaSなので単純な比較はできません。まずは前者の3つについて、比較をしてみましょう。 今回はパフォーマンス計測の定番、unixbenchで比較をしてみました。 https://code.google.com/p/byte-unixbench/ 計測対象は下記の通りです。 ディスクについては、AWSではProvis
ログインボタンって本当に必要？ UIの常識を検証する
会員登録制サイトに欠かせないログインボタン。ヘッダーの右上に設置されていることが多いですが、購入などのアクションを起こした時点でログインフォームを表示するようにしておけば、ユーザーにわざわざ「ログインボタン」をクリックしてもらう必要性は薄れます。 ユーザーが明示的にログアウトしない限り、ログイン状態を維持しておくのも有効です。後日再訪問したときには「ようこそ○○さん」などと表示し、ログイン状態が続いていますが、購入や登録情報の閲覧など高いセキュリティが必要なアクションでは再度認証を求めます。わざわざログインしないでもパーソナライズされた情報が表示されるので、ユーザーにとって利便性が高く、運営側にも「会員の行動履歴を取得しやすい」「ターゲティングによりコンバージョン率が上がる」などのメリットがあります。 このように、「ログイン」「ログアウト」ボタンはどの程度目立たせればよいのでしょうか？ 今
perl - 最速のUTF-8処理法 : 404 Blog Not Found
2013年03月04日14:45 カテゴリTipsLightweight Languages perl - 最速のUTF-8処理法 Perl Cookbook (English, Kindle Ed.) Christiansen / Torkington [邦訳: Perlクックブック] というわけで解説。 2013/03/04:Unicode::UTF8 がガチ爆速すぎる - bayashi.net encode より decode のが差が大きい感じ。encode だけだと、文字列長くなると Encode の方が速いっぽい。 まずは改めて検証してみましょう。 https://gist.github.com/dankogai/5079930 確かにその通りになっています。Unicode::UTF8はEncodeはおろかPerl組み込みのutf8::decodeより高速なのか(文字列をコピ
Webアプリケーションのインタフェース(WSGI, Rack, JSGI, PSGI)
WebアプリケーションのインタフェースxSGI(WSGI, Rack, JSGI, PSGI)のメモ。 Webアプリケーションのインタフェースといっても、いろいろな切り口があるとは思いますが、アプリケーションとサーバー(実行環境)間のインタフェース。PythonのWSGIと、その仲間(Ruby版, Javascript版, Perl版)のこと。シンプルなCGI/Fast CGI/SCGIとも異なるし、古風なxSP系(PHP/ASP/JSP)とも違う感じ。（ここのインタフェースは、それにあわせることで、Webアプリケーションを作る人はいろんなところで動かせる、Webアプリケーション実行環境を作る人はいろいろな人に使ってもらえる、と言うことになります。例えば、WSGIのpythonアプリは、自前のApacheでもクラウドのGoogle App Engineでも、動かせる、みたいな。さらに、中間
Unicode::UTF8 がガチ爆速すぎる
あんまり深読みしてないんだけど、Unicode::UTF8 が超速い。 おなじみ Encode との比較で、PODには 600% 速いって書いてあるけど、手元で試す感じだとだいたい 350～650% 速い。つまり、マジ速い。 Benchmark: timing 350000 iterations of Encode, Unicode::UTF8... Encode: 5 wallclock secs ( 4.41 usr + 0.00 sys = 4.41 CPU) @ 79365.08/s (n=350000) Unicode::UTF8: 0 wallclock secs ( 0.72 usr + 0.00 sys = 0.72 CPU) @ 486111.11/s (n=350000) Rate Encode Unicode::UTF8 Encode 79365/s -- -84%
「賢い」情報管理で安全と便利を両立 ラック セキュリティ技術統括 専務理事 西本 逸郎 - 日本経済新聞
米ツイッターが1月下旬に25万件の個人情報を流出させた問題で、前回はそれぞれの情報について危険性と取るべき対策を整理した。ではユーザーはTwitterなど各種インターネットサービスを使う際に、個人情報の肝となるパスワードをどのように管理すべきか。サイトの重要度や用途でメリハリを付け、安全性と利便性を両立させる管理のあり方を提案する。人間の記憶力には限界、現実的な運用を前回の記事で解説したよう
どのデータが一番"危険"だったのか ラック セキュリティ技術統括 専務理事 西本 逸郎 - 日本経済新聞
米ツイッターが2月1日に25万人にも及ぶ個人情報が流出したことを明らかにしてから、1カ月が経過した。流出した件数は、2億を超えるアカウントのうちの25万だが、同サービスのユーザーにはいくつかの影響が推測される。その後も、米フェイスブックや米マイクロソフトへのサイバー攻撃が相次ぐなか、ツイッターから流出した情報の意味と影響が及ぶ可能性を整理し、同様のサービスから情報が流出したときにユーザーが取るべ
卜部昌平のあまりreblogしないtumblr
どうも。グリーのアカウントは持ってる1けどモバゲーのアカウントは持ってない卜部です。 ところでPerlリスクですか。まあ、あるんじゃないですか。ぶっちゃけ。でもさあ、さすがにPerlしか書けない人たちは転職先の選択肢のなさくらい自覚してると思う。なのでPerlがどうとかいう話はしないです。各自でどうぞ。 でね、ポイントはそこじゃないだろうと思うわけですよ。どんな選択をしても同様のリスクはあるんですよ。たとえばMacromedia ShockwaveでLingoで作ってたソフトとかさあ。今ではだれもメンテできないでしょう? だから今隆盛をきわめてる技術で作ったものが、何年か後にリスクになるってのは、それはそういうものなんですよ。べつにPerlに限らん。Perlはたまたま今そういうフェーズってだけで、明日は我が身ですよ。hamlとかsassとか。 だからまあ、こう言ってしまうと身も蓋もないかも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
