サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
Jeff Atwood / 青木靖 訳 2007年2月26日 レジナルド・ブレイスウェイトが書いていることを読んだとき、私はそんなわけないだろうと思っていた。 私と同様、この著者は、プログラミングの仕事への応募者200人中199人はコードがまったく書けないということで苦労している。繰り返すが、彼らはどんなコードも書けないのだ。 彼が引用している著者というのはイムランのことで、彼は単純なプログラムも書けないプログラマをたくさん追い払っているということだ。 かなりの試行錯誤の末に、コードを書こうともがいている人たちというのは、単に大きな問題に対して苦労しているのではないことがわかった。やや小さな問題(連結リストを実装するというような)に対して苦労するということでさえない。彼らはまったくちっぽけな問題に苦労しているのだ。 それで、そういった類の開発者を見分けるための質問を作り始め、私が｢Fizz
2008年01月05日02:45 カテゴリ翻訳/紹介Code 試訳 - コードをセキュアにする10の作法 全コーダー必読。プログラマーだけではなく法を作る人も全員。Top 10 Secure Coding Practices - CERT Secure Coding Standards 突っ込み希望なので、いつもの「惰訳」ではなく「試訳」としました。 Enjoy -- with Care! Dan the Coder toErr -- and Fix コードをセキュアにする10の作法 (Top 10 Secure Coding Practices) 入力を検証せよ(Validate input) - 信頼なきデータソースからの入力は、全て検証するようにしましょう。適切な入力検証は、大部分のソフトウェア脆弱性を取り除きます。外部データは疑って掛かりましょう。これらにはコマンドライン引数、
2007年08月17日01:15 カテゴリ翻訳/紹介Lightweight Languages 怠翻 -JavaScriptでありがちな9つのシマッタ 私自身結構シマッタしちゃうので。 NineJavascriptGotchas 尻カンマ注意 以下のコードはFireFoxでは動きますが、Internet Explorer (以下IE)では問題になります。 var theObj = { city : "Boston", state : "MA", } 最後にカンマが入らないよう注意しましょう。浮気なthisは何を見てるやら 以下のコードで、thisは何を指しているでしょうか。 <input type="button" value="Gotcha!" id="MyButton" > <script> var MyObject = function () { this.alertMess
Peter Norvig / 青木靖 訳 先週、2人の友人(ディーンとビル)がそれぞれ別個にGoogleが極めて早く正確にスペル修正できるのには驚くばかりだと私に言った。たとえば speling のような語でGoogleを検索すると、0.1秒くらいで答えが返ってきて、もしかして: spelling じゃないかと言ってくる(YahooやMicrosoftのものにも同様の機能がある)。ディーンとビルが高い実績を持ったエンジニアであり数学者であることを思えば、スペル修正のような統計的言語処理についてもっと知っていて良さそうなものなのにと私は驚いた。しかし彼らは知らなかった。よく考えてみれば、 別に彼らが知っているべき理由はないのだった。 間違っていたのは彼らの知識ではなく、私の仮定の方だ。 このことについてちゃんとした説明を書いておけば、彼らばかりでなく多くの人に有益かもしれない。Googleの
ご存知の通り、はてなのシステムはほぼすべてPerlで書かれています。そもそも僕がはてなに入った一つの理由に、僕が一番得意とする言語であるPerlを使ってシステムを構築していたという点があったりします。 世の中にはたくさんのプログラミング言語があります。Perl、Java、Ruby、PHP、Python、C、C++、lisp、Smalltalk、Cobol...数え上げたらキリがありません。そして、プログラマはかならずと言っていいほど、どれかひとつ以上の言語を愛しています。好き、ではなく愛しているのです。 自分が愛しているものを批判されると感情的になりやすいのは人の常、プログラミング言語の差異に関する議論は炎上しがちで、よく宗教戦争だなんて言われたりもします。その中で、言語なんてどれも一緒だなんていう乱暴なまとめがされることもよくあったりします。 しかし、何年かプログラマというものを経験して
Jeff Atwood / 青木靖 訳 2006年8月24日 企業は開発者に給与として60-100kドル支払いながら、ひどい作業環境と汚い使い古しのハードウェアによって彼らを損なっている。信じられない話だ。そんなのはビジネス的に理屈に合わない。ところがそういうのをどこでも目にする。ソフトウェア開発者が成功するために不可欠なものを与えていな い企業がいかに多いかは驚くばかりだ。 そこでプログラマの権利宣言を採択し、成功に不可欠な基本的なことを否定する企業からプログラマの権利を守ることを提案する。 すべてのプログラマは2つのモニタを持つ権利を有する 下落する液晶ディスプレイの価格と、遍く存在するデュアル出力ビデオカードのことを考えるなら、開発者を1つのディスプレイに制限するのはばかげた話だ。ディスプレイを2つにすることによって得られる生産性の利益については、今では十分に説明されている。開発者の
↓で紹介されてた新しいプログラミング言語を習得するための15の方法についてhttp://forums.programming-designs.com/viewtopic.php?pid=3482I've working knowledge of abunch ofprogramming languages but job demands to learn a new language frequently in a short time. Instead of reading hundreds manual/book pages, I quickly read 10-15 pages of tutorial or primer. (As you knowgoogle is the best search engine to look for such stuff). I keep p
「ゼリーのみ規制…モチはいいのか？」→野田聖子氏「モチは喉に詰まるものというのが常識」…消費者庁構想に暗い影
後輩が cat README | tr ' ' '\n' | sort | uniq -c | sort -nr | head てなテクニックを見て、びっくりしたみたいな話をしていたのだが、こういうパイプラインを利用するテクニックを学んでいないのは色々損な気がする。 ていうか、サーバで丸一日以上かかるような処理を実行するのもしょっちゅうなのに、GNU screen も nohup も知らないってのはいろいろ支障があるような気もするのだが、だれも教えないものかなぁ。 ということで、bash or zsh のちょっとしたテクニックとか*1。リダイレクトとかパイプラインは略。 連続実行 単純に連続実行。 % foo; barfoo が正常終了したときだけ bar を実行 % foo && barfoo が正常終了しなかったときだけ bar を実行 % foo || bar&&、||は本来は論理演
プログラマに向いている人と向いていない人がいるそうです。 Jeff Atwood さんの「どうしてプログラマに・・・プログラムが書けないのか?」： プログラムを書ける者とプログラムを書けない者の間にある大きな溝についてはよく知られているが、プログラマの職に応募してくる人間は、すでにこの溝を飛び越えているものだとばかり思っていた。明らかにこれは妥当な仮定ではないらしい。プログラムを書けないプログラマの面接で時間を無駄にしないために、FizzBuzzスタイルのふるい分けが必要ということだ。 どんなことでも向き不向きはあるでしょうから、これには納得いきます。しかし、プログラマになれる人の中にも、溝があるようです。 Joel Spolsk さんの「Javaスクールの危険」： 私のささやかな経験から言わせてもらうと、伝統的に大学のコンピュータサイエンスのカリキュラムで教えられているもので、多くの人が
はじめに本文書は、Rubyによりコーディングを行う際の規約について述べる。 実際のプロジェクトに適用する際には、このコーディング規約をカスタ マイズして用いることを推奨する。 ソースコードの整形 インデント プログラムを読みやすくするため、インデントを適宜行う。インデント 幅は2とする。また、インデントにはスペースのみを使用し、タブは使用 しない。(環境によりタブ幅が異なるため。) 例: if x > 0 if y > 0 puts "x > 0 && y > 0" end end 一行の桁数 一行の桁数は最大80桁までとする。 空行 複数のクラスの区切には空行を挿入する。 例: class Foo ... end class Bar ... end 誤った例: class Foo ... end class Bar ... end また、クラス内の各構成要素の区切にも空行を挿入する。
ブラウザから誰でも簡単にSubversionが使える『Beanstalk』 October 23rd, 2007 Posted in その他 Write comment 激しく使えそうな予感がして、朝からテストしまくりの開発者向けサービスのご紹介。こ、これは使える！ Beanstalkはバージョン管理アプリのSubversionをASPで提供してくれる。 ブラウザ上で簡単にリポジトリをつくってソースをコミットしていけるのだ。 もちろんバージョンごとにブラウザ上でコードを見ることもできる。複数ユーザーでもコミットも楽々だ。 こうした機能を実現するにはtracがあるが、インストールがとっても面倒である（苦労するよね、あれ）。そこで苦労した人にとってBeanstalkの手軽さは大きな魅力ではなかろうか。 現在のところ1リポジトリ、2ユーザー、10MBの容量の無料プランしか用意されていないが、近い
2007年09月16日04:30 カテゴリArt LiveCodingに学ぶプログラミングの三原則 Mozilla24のLiveCodingの解説をやってきました。参加された方、お疲れさまでした。ほんと楽しかった。 言語もC++ありJavaありJavaScriptありActionScriptありPerlありとまちまちで、Editorもemacsありvimあり秀丸ありとまちまちでしたが、それでも全LiveCoderの共通項がはっきり見えたので、それを書き留めておきます。これらの共通項には私も含まれます。 コピペを恐れるな(don't be afraid to be a copycat) 参加者の一人として、100%フルスクラッチで書いていた人はいませんでした。たいていは関数単位でコピーし、それを適宜書き換えるというやり方をしていました。学校のテストでは反則もいいところですが、大人の世界ではこ
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
Hofstadter『メタマジック・ゲーム』 ミンスキー「ゲーデルはLispを思いついておくべきだった。もし彼がLispを思いついていたならば彼の不完全性定理の証明はもっと簡単なものになっていただろう」 ゲーデルの証明の一番難しいところは、数学的体系に自分自身を語らせるところにある。天才のひらめきが何段階か必要になる。しかし、Lispは、少なくともゲーデルが必要としていた意味で、まさに自分自身を直接語ることができる ゲーデルはLispを発明した！ 不完全性定理のLisp, Mathematicaによる記述 和田英一「Lispへのこだわり」(PDF) Eric S. Raymond「ハッカーになろう」LISP は、それをモノにしたときのすばらしい悟り体験のために勉強しましょう。この体験は、その後の人生でよりよいプログラマーとなる手助けとなるはずです。たとえ、実際には LI
多彩な演出効果をカンタンに導入できる事で脚光を浴びたprototype.jsの登場を皮切りに、インターネットで公開されているJavaScriptライブラリの数は、この一年で急激に増加した。何かやりたいことがあったときはWebで検索すれば、大抵、どこかにライブラリが転がっている。便利な世の中になったものだ。 一方、Webを通じて提供されるサービスは多様化の一途を辿っている。JavaScriptライブラリは整ってきたが、当然、置くだけでは機能しない。ライブラリのサポートページには簡単なサンプルが載っているものの、サンプルがそのまま適用できるケースはごくわずかだ。しかたなく、他の誰かが似たような事をやっていないかとWeb検索するはめになる。 思えば、これまでJavaScriptを言語としてとらえ、きっちり向き合う機会は少なかったのではないだろうか。 1995年の終わり、Netscape Navi
Last Updated on: 2018年8月20日問題：まちがった自動ログイン処理の解答です。このブログエントリは最近作られたアプリケーションでは「問題」にしたような実装は行われていないはず、と期待していたのですがあっさり期待を破られたのでブログに書きました。このブログの方が詳しく書いていますけが「Webアプリセキュリティ対策入門」にも正しい自動ログイン処理を書いています。 参考：自動ログイン以外に2要素認証も重要です。「今すぐできる、Webサイトへの2要素認証導入」こちらもどうぞ。HMACを利用した安全なAPIキーの送受信も参考にどうぞ。 間違った自動ログイン処理の問題点 まず間違った自動ログイン処理を実装しているコードの基本的な問題点を一つ一つ順番にリストアップします。 クッキーにランダム文字列以外の値を設定している クッキーにユーザ名が保存されている クッキーにパスワードが保存さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
