３歩先を考えるのが無理でも１歩分だけ思考をバッファする - ぼくはまちちゃん！
こんにちはこんにちは！！ みなさんそろそろ会社には慣れてきましたか！ ぼくはいまだに慣れません…！ ところで、この春からプログラミングをはじめたって方もいらっしゃるんじゃないでしょうか！ ぼくのまわりにも何人かそういうひとがいて、 たまにコードを覗き見てみたりもします！ そんなプログラミングをはじめたばかりの書くコードの中で、 こういうのをときどき見かけます…！ <div class="<?php if ($x == 1) { echo 'classA'; } elseif ($x == 2) { echo 'classB'; } elseif ($x == 3) { echo 'classC'; } ?>">Hello!</div> これってたぶん思考の流れそのままにコード書いちゃってるんですよね。 あっ、ここでクラス名かえなきゃ、とか。 でもこういうのって、 書く前に考えを一旦バッファ
どうしてプログラマに・・・プログラムが書けないのか?
Jeff Atwood / 青木靖 訳 2007年2月26日 レジナルド・ブレイスウェイトが書いていることを読んだとき、私はそんなわけないだろうと思っていた。 私と同様、この著者は、プログラミングの仕事への応募者200人中199人はコードがまったく書けないということで苦労している。繰り返すが、彼らはどんなコードも書けないのだ。 彼が引用している著者というのはイムランのことで、彼は単純なプログラムも書けないプログラマをたくさん追い払っているということだ。 かなりの試行錯誤の末に、コードを書こうともがいている人たちというのは、単に大きな問題に対して苦労しているのではないことがわかった。やや小さな問題(連結リストを実装するというような)に対して苦労するということでさえない。彼らはまったくちっぽけな問題に苦労しているのだ。 それで、そういった類の開発者を見分けるための質問を作り始め、私が｢Fizz
法と技術とクローラと私 - 最速転職研究会
こんにちは、趣味や業務で大手ポータルサイトのサービスで稼働しているいくつかのクローラの開発とメンテナンスを行っているmalaです。 さて先日、岡崎市立中央図書館Webサイトをクロールしていた人が逮捕、勾留、実名報道されるという事件がありました。 関連URL: http://librahack.jp/ 電話してみた的な話 http://www.nantoka.com/~kei/diary/?20100622S1 http://blog.rocaz.net/2010/06/945.html http://blog.rocaz.net/2010/07/951.html この件につきまして法的なことはともかくとして技術者視点での私見を書きたいと思います。法的なことは差し置いて書きますが、それは法的なことを軽んじているわけではなく、法律の制定やら運用やらは、その法律によって影響が出る全ての人々の常識
岡崎市立中央図書館事件 #librahack について愛知県警に電話して聞いてみた | [ bROOM.LOG ! ]
ニコニコPodder iPhone/iPod/iPad対応ニコニコ動画簡単インポートツール aggregateGithubCommits GitHubレポジトリでのコミット数をAuthor/期間別に集計します probeCOCOATek 新型コロナ接触確認アプリCOCOAが配布するTEKを表示・集計 連日Twitterでは #librahack ハッシュが大盛況だが、個人的には事実関係でよく分からないことも多く明白にしたいことではあったので、直接愛知県警に電話して事情を聞いてみました。岡崎署ではなく愛知県警なのは、そちらが事件捜査の主体的な役割を担っただろうと判断したからです。 対応して頂いたのは生活経済課の方。お名前は出しません。愛知県警ではこの課がサイバー犯罪を担当しているそうです。 担当して頂いた方は割と若めで理路整然と話したいクールなタイプ。多少警戒されて話されていたのが印象によく
プログラマー面接時の技術的な質問事項(アプレッソ版) : 小野和俊のブログ
技術者・SE・プログラマ面接時の技術的な質問事項というエントリをはてブで見かけたのだが、私もjavaプログラマーの面接を割とよくやっているので、よく質問する内容をまとめてみた。 (ちなみに、基本的にコーディング面接の形態を取っている) プロジェクトの性質にもよると思うが、私の場合には、情報処理技術者試験的に基礎が満遍なく抑えられているかどうかよりも、 すぐ答えが見つからないような課題に対して、きちんと自分でやり方を考え、対応することができるか 「変な」コードをコミットしたりしないか(見つけにくいバグを混入させるとか、汚いとか、遅いとか)といった点を重視している。 まず、何を知っているかよりも、どんなものを作れるか、どんなことができるか、という質問。 ここで強烈な回答が来る人は、たいていここより下の質問は「あー、はいはい」という感じでサラッと答えてくることが多い。 これまでに携わってきた開発
ウノウラボ Unoh Labs: PHPによるテキストファイルへのロギング
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
論理的思考の放棄 - 登 大遊＠筑波大学情報学類の SoftEther VPN 日記
僕は、1 日に少なくとも 3,000 行程度、多く書くときで 10,000 行以上のプログラムを書くことができる。その結果、多い月で 10 万行 / 月くらいである。なお、言語は書くソフトウェアの性質上、大半が C 言語である。 また、プログラミングにはバグが付き物だが、ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。 とても大きく複雑で、かつレイヤ的に OS に近い処理をたくさんやるプログラムを書く場合は、プログラミングをするときでも、事前の設計が極めて重要となる。設計をうまく行わないと、後になって全面的に書き直しをしないといけなくなったり、パフォーマンスが低下したりする原因となり、開発者の苦痛の原因となる。 当然のことながら、これまで書いたいくつかの大きく複雑といえるソフトウェアの大半の設計も、自分で行った。いかなる場合でも、設計は、最初の 1 回目で確定
さあ、Yコンビネータ(不動点演算子)を使おう！ - よくわかりません
前回、おとうさんにもわかるYコンビネータ！(絵解き解説編) - よくわかりませんというエントリで、Yコンビネータ(不動点演算子)と再帰の絵解き解説をしました。 Yコンビネータ自身は、結局のところ再帰を産み出してくれるだけです。関数(正確にはλという単純な文字列変換ルール)だけで出来て、プログラミングに関するいろんな原理の研究を可能にするのが凄い訳です。その辺のさわりを、きしださんが解説されています。しかし、単なる再帰なら、実際のプログラミングではYコンビネータなんて使わなくても出来ます。 じゃあ、Yコンビネータとか不動点とかは、偉い学者さんとかが研究に使えばいいもので、普通のプログラマには何の意味もないモノなのでしょうか？ というわけで、今回はポジティブに、Yコンビネータや不動点で出てくる考え方を、理論だけじゃなく、実際のプログラミングに応用する例を見てみましょう。 今回、プログラムの例を
Geekなぺーじ : 夜フクロウと「社会的責任」
夜フクロウの件はユーザが自分のわがままを「社会的責任」と言ったという話だと感じています。 今回の件に関して、夜フクロウ作者が「社会的責任を問われるべきか？」というと、私はNOだと思います。 「フリーソフト開発者に無茶言わないで！」とは思いますが、今回の件とは別に、ソフトウェアに免責事項を明記することや、「公開することの責任」という話題はあると思います。 フリーソフトに対するイチャモンは、私は基本無視。しかし、公開していると世界中から色々来ることも事実です。国が違うと要求のぶっ飛び具合も想像を超えることがあります。 「社会的責任」という単語は他人に何かを強要するときに用いられることが多い単語というイメージ。余談ですが「公平」とか「中立」という表現も他人との議論を有利にするために利用されることが多いイメージ。 「責任」と「社会的責任」の単語の定義が人によって違いそうですね。 免責事項はソフトウ
flair4 blog - Flashが何故かうまく動かない時に疑うべき8つの要素
プログラムは間違っていないのに動かない！ 修正したはずなのに修正が反映されない！ 俺のPCでだけうまくパブリッシュされない！ Flashやってるとこういう事がけっこう起こります。 気がつくと１時間くらい格闘するとかあって非常に困ります。 今日はそんな時に疑うべき要素とその解決(するかもしれない)方法を あたりまえじゃんという所から ちょっと深く突っ込んだ内容まで含め８つほど紹介します。 ちなみに若干長いです。 (基本的に FlashCS3 でAS3.0 での話です) (早くも若干追記しました) 文字コード XML等を使っている時確認すべき内容 基本中の基本ですね Flashは基本UTF-8が推奨なわけですが Shift-JISだったりとかUTF-8Nだったりとか・・・ しっかりと確認しましょう。 もしどうしてもUTF-8以外を使わなければならない場合には
アンドロイドアプリができるまで:001 開発環境の準備
アンドロイドファンの皆様、初めまして。タオソフトウェアのため吉と申します。縁あって、今週からアンドロイドアプリの開発について連載することになりました。よろしくお願いいたします。 皆さんが使っているアンドロイド端末にもたくさんのアプリケーションがインストールされていると思います。中には「これがなくっちゃ暮らせない！」というほどの生活必需品になっているアプリもあるかも知れません。当たり前ですが、そういう素敵なアプリケーション達は全て「人が手作り」したものです。 この連載ではアプリケーションが出来るまでの工程を皆さんにお伝えしながら、アプリアイコンの裏に隠れた作者側の思いやドラマを描くことができたらいいなぁ、と思っています。 どうぞよろしくおつきあいくださいませ。 アンドロイドアプリをつくるためには まずはアンドロイドアプリを作るためにはどんなものが必要なのかというところから始めたいと思います。
無精で短気で傲慢なプログラマ 技術者・SE・プログラマ面接時の技術的な質問事項
最近、技術者やプログラマの方と面接する機会が多いです。 毎回質問事項を考えるのにも飽きたので、再利用できるようにまとめておきます。 もしさわりの質問に対する反応が良かった場合は、さらに突っ込んだ質問 (インデントが深いもの) をします。経験がないようなら、さらっと流します。 当ページ管理人は、現在 EC サイト構築・運営を担当しているため、 そっち方面に偏っています。 最小限の質問でその人のスキルを見極めるのは難しいなぁ…。 ------- ●追記 ホッテントリに載ったようなので、このチャンスに 人材募集 を再アピールしておきます。 興味のある方はぜひ。 念のため言っておきますが、全部できないとダメというつもりは全くありません (当ページ管理人も、CSS・Eclipse・Struts・Spring・Hibernate・Ruby・アセンブラなど、 弱い部分が多々あります)。 「～はできますか
最も todo と fix meが多いプログラミング言語は Python かもしれない - higepon blog
プログラムを書いていると todo としてコメントを入れることがあります。 現時点ではこのコードは書けない 余裕のある時にやろう 汚いコードを書いていることに対する言い訳 など理由は様々。 todo コメントの例としては // todo check hogehoge hoge(); のようなものが挙げられます。 ふと思いついて「最も多くソースコードのコメント中に todo と書かれている言語は何か？」をGoogle Code Searchを利用して調べてみました。 行コメント限定ですが結果は以下の通りです。 lang todo % todo/all scheme 1.4% 1000/71000 c++ 0.2% 12300/6280000 c# 0.2% 13600/6280000 fortran 0.0% 100/233000 perl 2.1% 28600/1370000 php 1.
小野和俊のブログ:ソースコードのコメント率は20%を切ることが望ましい
大学の研究室の教官は昔NTT研究所の所長をされていた苗村先生という人で(と言いつつ私は大学の研究室にほとんど顔を出していなかったのだけれど)、彼の発言のうち印象に残っているものの一つとして、昔はソースコードのコメント率が50%を切るものはドキュメント不足で品質が低いものとされた、という内容のものがあった。 今、改めて考えて、どのような言語であってもどのようなコーディング規約であっても、私はソースコードのコメント率は原則20%を切ることが望ましいと思う。可読性の意味でもメンテナビリティの意味でも、開発生産性の意味でも。私が考えるに、本来コンピュータが読むためのものであるソースコードに人が読むためのコメントを付け加えなければならないのは、次の２通りの場合だけである。 1.公開されるAPI APIやソースコードそのものが公開される場合、利用者は不特定多数となり、利用者のスキルにもばらつきが出て、
コピペはプログラミングの基本。どんどんコピペしなさい。 - このブログは証明できない。
コピペはプログラミングの基本です。どんどんコピペしなさい。って、スラムダンクに書いてあった気がしますが、気のせいかもしれません。私はコピペ推進派です。コピペはプログラミングの基本なので、がしがしコピペすればいいと思います。今日は、この辺の話をしていきますが、話題がそれて三井寿を語る場になったらスミマセン。 まず、プログラミング初心者。これはもう、わしゃわしゃコピペすべきです。ホントは写経の方がいいのですが、コピペでも構いません。構いませんとも。かまいたちの夜です。プログラミング初心者が参考書のプログラムを理解するには、読むだけでは足りません。まず、サンプルプログラムを動く状態にして、それを改造すべきなのです。大幅な改造は必要ありません。まずは、変数の中身を変えるとか、そこから始めます。 英語を学習するときに、1単語を覚えるよりも、ひとかたまりのフレーズで覚えた方がいい。って、スラムダンクに
五歳からのプログラミング＠MITメディアラボ - My Life After MIT Sloan
プログラミングって、ある意味最強の表現手段なのだと思うときがある。 例えば先日書いた私の欲しい電子書籍のアプリや出版社が実現すべき電子教科書も、 私がプログラミングのような表現言語を持っていれば、私が見ている未来の世界を製品にすぐに実現して、世の中に広めることが出来るのに、と思う。 でも、私にはそういう表現手段が無いから、一生懸命、色んな言葉で表現するのだ。 それが、自分でモノが作れる人たちやコンテンツをもってる人たち（教科書会社とか）の目に届いて、一緒に未来を作っていければ・・と願いながら書いている。 もっとも私も一応FORTRANとかC++はかつては少しは書けたので（もう錆ついてるが）、 ちゃんと勉強すればObjective-CもJavaも書けるようになるのかもしれないが・・。 このように、いくら頭の中に未来のデバイスやアプリの姿を詳細まで想像できても、 プログラミングなどの表現手段を
「サニタイズ言うなキャンペーン」私の解釈
高木浩光さんの「サニタイズ言うなキャンペーン」 という言葉自体はずいぶん前から存在したのだが、 続・「サニタイズ言うなキャンペーン」とはにて高木さん自身がいくつも誤解の例を挙げているように、 そしてまた最近も 駄目な技術文書の見分け方 その1にて「まだわからんのかね」と言われているように、 「わかりにくい」概念なんだろうとは思う。 そこで、僭越ながら、「サニタイズ言うなキャンペーン」について、 私なりの解釈を書いてみようと思う。 もっともこれが正解であるという保証はないのだが、 間違っていたらどなたかツッコミいただけることを期待しています(_o_) そもそも何のせいで「エスケープ」しなければならないのか たとえば住所氏名を登録させるWebアプリケーションは珍しいものではないと思う。 そこで、私が「Taro&Jiro's castle サウスポール」 とかいう恥ずかしい名前のマンション(?)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 続・ハイパフォーマンスWebサイト ―ウェブ高速化のベストプラクティス: Steve Souders (著), 武舎広幸 (翻訳), 福地太郎 (翻訳), 武舎るみ (翻訳): 本
プログラミングの下手な奴の特徴:アルファルファモザイク
Scratch
