文字列が格納されている変数 str から、末尾の連続する改行文字を削除しようとして次のようなコードを書いた（言語：Ruby）。 本コードには問題がある。 問題点を指摘せよ。改善案を提案せよ。 とだけ書いて、答えられる人はどのくらいいるだろうか。これは別に筆記試験というわけではない。手元に Ruby 実行環境があるなら様々な入力で試してみて欲しい。もちろん Web を検索してみても良い。 一見なんの変哲もない一行のコードだが、これはシステムをダウンさせかねない大きな問題を抱えている。読み進める前に、今、コードレビューやテストをしている段階だと考えて、ぜひそれを指摘してみてほしい。 問題点 問題点は次の通りだ。 本コードには致命的なパフォーマンス劣化を引き起こす入力が存在する。 例： 手元に Ruby の実行環境があるなら試してみてほしい。応答が返ってこないことが確認できるはずだ。もしこの s

キーボードは、プログラマなら、相当の使い込んでいるはずだ。 そして、手に十分なじんだものでないと、使うのが嫌になるはずだ。 また、巷にあふれている日本独特のＪＩＳ規格に従ったのを使いたくない人も多いだろう。 世界的には、やはりＡＳＣＩＩ配列が普通であり、ＪＩＳキーボードは結局ガラパゴスキーボードなのだ。 キーボードの値段は、下は数百円から上は数万円まで、かなり幅がある。 キーボードの値段をケチって指を壊したほうが治療費がかかる上に、とても不便になりかねない。 キーボードはプログラマにとっては身体の一部のようなものなので、しっかり手入れをしよう。 私は、諸般の事情、大人の事情などから、ＪＩＳキーボードとＡＳＣＩＩキーボードの両方を使っている。 そして、ＪＩＳキーボードに関しては、あまりプログラムを作ったり、延々と記事を書くときなどには使わないので、購入したときについてきたもの、あるいは余って

先日、OpenSSH 7.3 がリリースされましたが、 http://www.openssh.com/txt/release-7.3 新しい機能として、ProxyJump設定パラメータと、これに対応する「-J」コマンドラインオプションが加わっています。 以前の記事(OpenSSH のNetcat modeを使う)でも書きましたが、netcat モードができたから、ncとかconnect 使わなくても踏み台越えが楽になりましたが、さらに記述が簡素化されました。 使い方はこうです。 ssh -J user@fumidai user@innerhost 複数台踏み台ホストを経由する場合には、 ssh -J user@fumidai01,user2@fumidai02 user@innerhost と複数の踏み台ホストをカンマ区切りで記載すれば、複数の踏み台を経由したホストにも簡単に接続することが

ちょっとNumpyで、浮動小数点数をaroundを使って丸めてみよう。 以下のようにして、0.5から１刻みで10個のちょうど中間になる値を用意した。 そして、np.aroundを用いて、一気に丸めてみた。 In [182]: np.arange((10))+0.5 Out[182]: array([ 0.5, 1.5, 2.5, 3.5, 4.5, 5.5, 6.5, 7.5, 8.5, 9.5]) In [183]: np.around(np.arange((10))+0.5) Out[183]: array([ 0., 2., 2., 4., 4., 6., 6., 8., 8., 10.]) すると、 array([ 1., 2., 3., 4., 5., 6., 7., 8., 9., 10.]) になると思ったが、違った。 ここで、さらに、Python3 の丸め roundでも試

先日 GHOST と呼ばれる glibc の脆弱性が発表された。なんでも、「リモートから任意のコードを実行できる可能性がある」らしいではないか。しかも様々なプログラムで利用されているライブラリ部分の問題とあって、影響範囲がとても広い。なかなか厄介なことである。 はて、しかし一体全体どうやってリモートから任意のコードを実行しようというのだろう？ 話を聞くに、たかが数バイトの情報を範囲外のメモリに書き込める可能性があるだけだという。実際それだけのことでサーバーの乗っ取りなどできるものなのだろうか。そんなわけで、その疑問に答えるべく、本記事では以下の URL で解説されている実際の攻撃方法を若干端折って紹介してみようと思う。 http://www.openwall.com/lists/oss-security/2015/01/27/9 なお、本記事はこの脆弱性そのものに対する緊急度などについて言

+----+----------+------------+---------+ | id | group_id | updated_at | comment | +----+----------+------------+---------+ | 1 | 1 | 2013-12-01 | C | | 2 | 2 | 2013-12-01 | A | | 3 | 1 | 2013-12-02 | B | | 4 | 2 | 2013-11-30 | D | +----+----------+------------+---------+ CREATE TABLE sample_table ( id int(11) NOT NULL, group_id int(11) NOT NULL, updated_at date NOT NULL, comment varchar(60) NOT NU

他人の開発画面、覗いてみた事ありますか。 覗いてみた事が無い方は、是非見せてもらってください。意外と面白いですよ。 gitのコミットの仕方ひとつとっても、人によって全く違うんだなと思うはずです。 git使いが10人いれば、使い方も10通りなんだなと、他人のコンソール覗きこむたびに感じます。 私の場合、プロジェクトが数ヶ月から半年に一度変わる（または並行して複数のプロジェクトに入る)という事が多く、いろんなgit使いの方に触れる 機会が多いです。 コンソール上でgitを操作する人、SourceTreeやEclipseプラグイン等のGUIツールで操作する人、git rebaseを多様する人、全くしない人、コミットグラフが綺麗な人、汚い人（そもそもあんまりこだわりを持っていない人?)、コミットメッセージを日本語で書く人、英語で書く人。。。 私は、「git pull」というコマンドを使う事はほぼ無

ゲーデルの定理を大学時代に知ったときは「結論はわかる。でもどうして証明可能であるという概念が実際に算術上の命題として表現できるのか？」を理解することができなませんでした。論文ではこの部分を丁寧に大量の中間概念を導入しながら証明していくのですが、個々が抽象的すぎてすぐに眠くなってしまうからです。

関数プログラミングの世界の標準教科書である Introduction to Functional Programming using Haskell の翻訳が、つい先日出た。 オーム社からで、翻訳は Haskellで有名な山下さんである。 定価3990円（税込）はちょっと高く感じるかもしれないが、これは原書よりもはるかに安く設定されており、オーム社の意気込みが感じられる。 A5判で、約４００ページの本である。 既存の、つまり手続き型のプログラミング言語の本ばかり読んできた人は、かなり面食らうのではないかと思われる本である。 ちょっと見たところ、プログラミングの本というより、関数プログラミングとは何か書いた本といった雰囲気だ。 もちろん、例題などでは Hasekellが使われているのだが、解答がいちいち載っているわけではない。ネットで答、解説を探すと、著名な本名なのでかなり見つかる。もちろん

問題 Vim の矩形選択 は便利です。痒いところに手が届く感じの便利さです。 例えば以下のようなコードを編集していて、 一時的に真ん中のブロックをコメントアウトして無効化したくなったとしましょう。 やり方は色々あります。 対象が1行だけなら I# <Esc> で十分です。複数行あるなら最初の行を I# <Esc> でコメントアウトした後に j. を繰り返していけば良いですね。数が多くて j. の連打が難しい場合は vip で選択して :s/^/# /<Enter> という手もあるでしょう。 これ以外に矩形選択を使う方法もあります。 <C-v> で矩形選択を開始し、j 等を連打して適当な範囲を選択し、I# <Esc> こうすれば選択範囲の各行の頭にまとめてコメント文字を入力することが出来ます。 しかし、現実には「 j 等を連打する」といった優雅さに欠ける操作はしません。 ブロック単位でテキス

えっ、世間ではHTML5の話題でいっぱいなのに、今更XHTMLの話？ XHTML 2.0は頓死したって聞いたよ？ まあ、その点についてはその通り。 しかし未だにIE6は爆発せず、 SafariにもOperaにもChromeにもFirefoxにも対応する必要があり、 IEに至っては何故か4バージョン(!)分も対応しなきゃならない現状を鑑みれば、 まだあと数年、場合によっては十数年はXHTMLも現役であることは十分に想定されるわけで、 そういう意味では正しいXHMLの知識というのは無駄にはならないはずだ。 それに、より正則なXHTMLの方が、HTML5に移行するときも楽に違いない。 さて、このトピックで扱うのは、要素の包含関係についてだ。 ただのXMLとしてみればきちんと入れ子になり、閉じタグがあって問題ないとしても、 XHTMLとしては不整なことはよくある。 良いことなのか余計なお世話なのか

問題 僕が一番 Vim のタブページをうまく使えるんだ(カレントディレクトリ編)で述べたように、Vimのタブページはとても便利ですが、ちょっと工夫するだけでさらに便利になります。 ところで、一般に Vim を使うような方は黒い画面を眺める機会が多いと思います。 また、端末をより便利に使うために GNU screen 等の端末マルチプレクサーを使用している方も多くいるはずです。 すると、 Vim でソースコードを編集しつつ、時折端末に切り替えて作業する……ということが多発します。 この時、以下の点で不便に感じることがあります。 端末をアクティブにすることが面倒(GUI 版の Vim を使用している場合)。作業用のウィンドウに切り替えることが面倒(GNU screen 内で Vim を起動している場合)。シェルで作業ができる状態になったとしても、 Vim で注目しているカレントディレクトリに移

問題 パッチのレビューなどでGitの diff の出力を読む機会はそれなりにあると思います。 その際、 diff で列挙されている内容だけでなく前後のコードも確認するために変更のあったファイルを開くことも多々あるでしょう。 Vimにはこの状況にぴったりのコマンドgfがあります。 gf はカーソル下にあるテキストからファイル名らしき文字列を探してそれを開くというコマンドです。 diff の出力には変更のあったファイルのパスが含まれていますから、 そこへカーソルを移動して gf を使えば良いというわけです。 gf はとても便利なコマンドではあるものの、 上記の操作を何度か行っていると不満が募ってきます。 というのも、以下のような手間があるからです: gf を実行するためにパスの書かれている位置までカーソルを移動しなければならない。gf でファイルを開いた後、レビューしたい場所までカーソルを移動

Pryは結構前からgithubのリポジトリを追いかけている人達には認知されていましたが、RailsCastsでも紹介されたことから、Ruby界で一気に広がりを見せています。 ちなみに発音はpra'i(ぷらい)です。英単語で「覗く」などを意味します。 今回はそんな便利なPryについて少し紹介したいと思います。 Pryはirbの代わりになるREPL Pryを一言で説明すると、irbと同様にREPL環境を提供してくれます。 では、さっそくインストールしてみましょう。

問題 今時の若者ならばHeroku等を利用して手早く Web アプリを作成・公開することが日常茶飯事です。 バックエンドもフロントエンドも今はフレームワークが充実していますから、 高度な処理を簡潔な記述で行うことができます。 しかし非同期処理となると話は別です。 例えばフロントエンドを作るとなると、まずjQueryを使うことになるでしょう。 jQuery は洗練された API で DOM 操作を簡単に行うことができますし、 非同期通信についても $.ajax を使えば煩雑なことほぼ知らずに済みます。 例えばWikipediaの検索フォームは入力補完が行われるようになっており、 検索フォーム文字が入力されると関連するページのタイトルが候補として表示されます。 このような処理を書くとなると以下のようなコードになるでしょう: var showCompletionMenu = function (

問題 VimとExcelを組み合わせて全く新しいSQLクエリーを生成する でも述べたように、諸事情で Excel を使う機会はよくあるのですが、 その時に困るのが文字列処理です。 Excel は組み込みでCLEAN、TRIM、UPPER、PHONETICなどの豊富な関数が用意されているものの、 何故か正規表現を使った文字列比較や文字列置換は標準で関数が用意されていません。 単純な処理ならば組み込み関数を組み合わせてどうにかできるものの、 「s/,+/,/g や s/,$// ができたらなぁ……」 と思うことはしばしばあります。 どうにかして Excel の数式で正規表現を使うことはできないでしょうか。 解答 結論から言うと、デフォルトの状態では正規表現を使うことはできません。 しかし以下のステップを踏むことで正規表現が利用できます (以下の例では Excel 2007 を使用しています)。

以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗