タグ

ブックマーク / postd.cc (29)

  • C言語パズル集:Cにまつわる興味深い問題あれこれ | POSTD

    ビジターの皆さんへ C言語に関心を寄せていただきありがとうございます。このページは、C言語の面白い問題、パズルのリストです。これまでに友人たちからeメールで送ってもらったり、で読んだり、インターネットで見つけたり、あるいは自分でC言語でコーディングしていて気づいたりしたプログラムを集めました。 多くのプログラムは、コンパイル、実行され、その振る舞いを示すものです。問題は大まかに次のカテゴリに分けられます。 一般的なタイポエラー。C言語プログラマが頻繁に犯すミスであり、かつ追跡が困難。 初見では非常に理解しがたい小さなプログラム。これらの問題は、他人が書いた優れたコードを読み解く良い訓練になります。 また、全てにGnu/Linux/gccを使っています。掲載順は、それぞれの難易度とは関係ありません。問題解決の助けが必要な場合は、気軽に私に問い合わせてください。連絡先は こちら です。また、

    C言語パズル集:Cにまつわる興味深い問題あれこれ | POSTD
  • 30日間で300回のプログラミング面接をしてわかったこと | POSTD

    プログラマの採用方法を改善するため、1カ月程前にTriplebyteを立ち上げました。昔から変わらず、履歴書、コードをホワイトボードに書かせるプログラミングテスト、そして直感など、これらを判断基準に面接を行う企業が多すぎます。私たちは、より良い採用方法について最初に考えたアイディアを マニフェスト に記しました。それから1カ月と少しが経過し、この30日間で、300回の面接を行いました。私たちはアイディアを実行に移し、どの方法が有効で、どの方法が有効ではないかを確認し、そのプロセスを繰り返すということを始めたのです。この投稿には、300回の面接を通して私たちが学んだことを書いていこうと思います。 投稿では、細かい内容についての説明が多くなりますが、キーとなる発見は以下の通りです。 私たちが作ったオンラインのプログラミングクイズの結果を見れば、高い確率でプログラミング面接の結果を予測できる。

    30日間で300回のプログラミング面接をしてわかったこと | POSTD
  • Javaのマイクロフレームワーク ― この新トレンドは見逃せない | POSTD

    この記事は、JavaScalaの例外分析・パフォーマンス監視のツール Takapiblog に投稿されたものです。 Javaのマイクロフレームワークとは何か、推奨される理由とは? どんなプログラミング言語にも、長所と短所はあるものです。例えばJavaは、安全性の高さや、厳しいテストを経ていること、後方互換性などの利点を持つ言語です。しかし、その代償として、アジリティ(俊敏性)や合理性といった面が少なからず犠牲になっています。冗長で、Java自体が肥大化しているという事実も否定できません。とはいえ、新規開発や大規模な開発を行いたい場合、JVM(Java仮想マシン)はバックエンドとして非常に魅力的です。JVMはパワフルな上に、非常に厳しい環境でテストされています。このような利点があるため、結果的にJavaは広く使用され、積極的にデプロイされているのです。 しかし、このJavaの現状を皆

    Javaのマイクロフレームワーク ― この新トレンドは見逃せない | POSTD
    kamei_rio
    kamei_rio 2015/07/14
  • jQueryは有害なのか | POSTD

    ずっと「~は有害なのか」という記事を書いてみたかったんです ^(1) 。 まず題に入る前に、1つ言わせてください。 jQueryはWeb業界の発展に大いに役立った と私は考えています。jQueryがあることで、開発者はこれまで想像もできなかったことをできるようになりましたし、そういった機能をブラウザの製作者がネイティブに実装するきっかけにもなりました(もしjQueryが開発されていなければ、今でもdocument.querySelectorAllは存在していなかったでしょう)。jQueryは、今ある便利なツールを使うことができなかったり、IE8やそれ以下の過去の遺産をサポートしなければならない際に今でも必要になってきます。 しかし、そのようなケースはもはや稀なものとなりました。Web開発者の大半は、マーケットシェアの縮小した古いブラウザをサポートする必要はありません。更に、忘れてはならな

    jQueryは有害なのか | POSTD
  • Vimの生産性を高める12の方法 | POSTD

    1. LeaderをSpaceキーにする Leader は素晴らしい概念です。キーの 組み合わせ ではなく 並び によって、操作を行えるようにするものです。私はこれを使っているので、操作のために” Ctrl -何らかのキー”の組み合わせを押す必要はめったにありません。 私は長い間、 , を Leader キーとして使っていました。ですがある時、キーボードの中で一番目立つキーにマップすることを思い付いたのです。Space(スペース)キーです。 これで私のVim生活は激変しました。今や、私は Leader をどちらの親指でも押すことができ、他の指は常にホームポジションにあります。 Leader がとても使いやすくなったので、私が様々なキーバインドで用いるようになったことは周知の話です。 2. 自分が特によく行う操作をLeaderにマップする 私は、自分がVimで作業を行っている中で、その時間の

    Vimの生産性を高める12の方法 | POSTD
  • コードレビューのベストプラクティス | POSTD

    Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上

    コードレビューのベストプラクティス | POSTD
    kamei_rio
    kamei_rio 2015/06/12
  • 「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD

    数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか? 私が何かを見逃したのでしょうか? 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト

    「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD
    kamei_rio
    kamei_rio 2014/11/26
    複雑なチェックをする機能は必要だと思う。結合を疎にさせる副作用もあるし。
  • それでも独自のCSVを書くつもりですか? | POSTD

    一部誤訳の指摘があったため、修正しました!ご迷惑おかけして申し訳ございません! あなたは自分でCSVを書いてみたいですか? フィールドはコンマで区切り、行は改行で分けます。簡単ですよね。数行書けば勝手が分かるというものです。 でも、ちょっと待ってください。 フィールド内にコンマがある場合は? ダブルクォート(”)で、該当のフィールドを囲みましょう。簡単ですね。 では、ダブルクォートで囲めるフィールドに例外はあるのでしょうか? フィールド内にダブルクォートがある場合は? フィールド内の各ダブルクォートに対して、ダブルクォートを二重化して適用しましょう。そうすれば元のダブルクォートをエスケープすることができます。 なお、二重化したダブルクォートと空フィールドを囲んでいるダブルクォート( ...,"",... )を勘違いしないように気を付けてください。 フィールド内に改行がある場合は? その場合

    それでも独自のCSVを書くつもりですか? | POSTD
    kamei_rio
    kamei_rio 2014/11/13
    .xls神に比べれば天使のような存在、だけど闇は深い
  • 科学者が書いた質の低いコードが、ベストプラクティスに則ったコードに勝る理由 | POSTD

    今ちょうど、 科学者の手によるコードは質が低い という投稿を読み終えたところです。科学者の書いたコードは”ソフトウェア・エンジニア”が関与したコードと比べて質が劣るという内容でした。 私は10年以上同じ職場に勤めていますが、同僚の多くは数学や物理学が専門で、”ソフトウェア・エンジニアリング”の知識はほとんど持っていません。 そこでは、大惨事は必ずと言っていいほど、自分のことをいっぱしのプログラマだと思っている少数派によって引き起こされます。かくいう私も、少なくとも数件、いまだ解決を見ていない大きな不具合の原因を作ったことがあります。他にも大きめのバグをいくつか出しましたが、幸いその時のコードはお蔵入りしたため、私に無駄な給料を払わされた雇い主が被害をうけたくらいで、同僚の生産性を大きく損なうことはありませんでした。 その度(少なくともほとんどの場合)私は反省し、それまでにも増して退屈なくら

    科学者が書いた質の低いコードが、ベストプラクティスに則ったコードに勝る理由 | POSTD
    kamei_rio
    kamei_rio 2014/07/16
    システム開発でもするつもりなんですか?→科学者