Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
次世代Windwosの正式名称が「Windows 10」であるとマイクロソフトが発表し、なんで9じゃなくて10なの?とちらほらと話題になっています。 そんな中、次のツイートが数多くリツイートされ、9にしなかった理由の本命か?という声も出ています。 Windows8.1の次が10になった件は、バージョン判別しようとしてOS名を取得して前方一致で"Windows 9"だったら95/98系と見なすという糞コードが蔓延しているので避けたという話をFacebookで見かけた。説得力ありすぎる。— digitalcat (@digitalcat) 2014, 10月 2 ただ、ちょっと出典が曖昧でなんとなく都市伝説化?しそうだったので調べてみました。 まず、この説の初出はアメリカのソーシャルニュースサイト「reddit」です。 [–]cranbourne Microsoft dev here, the
LL から Java に移行した人がはまりがちなこと こんにちは。Java 初心者です。 Java 初心者、得に LL から Java に来た人にありがちな問題について社内向けに書いたものをオープンアンドシェアさせていただきます。 前提として、我々は Java 8 でガンガン攻めているということをご承知おきください。 また、自分がこの数ヶ月で「うわー。こうしとくべきだったのかー」と気づいたやつをドヤ顔で語っているということにもご注意ください。 【追記】 対象は中規模 B2C の場合です(中規模というのは facebook より小さいという程度の意味です) 例外を握りつぶさないようにしよう Eclipse が生成する以下のようなコードをそのまま残しているケース。 これは言うまでもなく良くないですね。デバッグが困難になります。 try { } catch (IOException e) { e
ここ数年間をプログラミング的な観点で見ると、私が望んでいたほどには面白みがなかったと言わざるを得ません。このことは、恐らく他のプログラマの皆さんも同意見かと思います。そこで、私はこの期間をある意味、充電期間と捉えて、自分の開発ツールの強化に取り組んできました。そして土曜日になると、Bashを使って ワークスペース 作りに精を出していたのです。 最後にシェルを使って真剣にプログラミングに取り組んだのは、かれこれ恐竜がまだ地球を支配していた頃だったでしょうか。何年も触れていなかった言語を改めて取り上げ、その昔に自分が書いたコードを見直してみると、いかに自分が成長したかということを実感できて、なかなかに面白いものです。 14年前、私は”コンパクトなコードは優れている”という考えに随分と傾倒していました。コードが少なければ、そしてDon’t Repeat Yourself(DRY)に従えば、バグも
タイトルは煽りです。 『アンダースタンディング コンピュテーション―単純な機械から不可能なプログラムまで』をご恵贈いただきました。ありがとうございます。 アンダースタンディング コンピュテーション―単純な機械から不可能なプログラムまで 作者: Tom Stuart,笹田耕一(監訳),笹井崇司出版社/メーカー: オライリージャパン発売日: 2014/09/18メディア: 大型本この商品を含むブログ (2件) を見る 本書の扱う計算理論と呼ばれる分野には、前職の同僚たちがそういうのに詳しかったこともあってずっと興味を持ってはいたものの、いくつかの教科書的な本を繙いては読み進めずに挫折することを繰り返していました。その意味で、監訳者あとがきの「これなら私でも読める」という言葉は、自分自身の思いでもあると感じました(もちろん、笹田さんの「私でも」と、僕のそれとではおおいに異なることはいうまでもあり
Jennifer Campbell, Paul Gries, Jason Montojo, Greg Wilson 著、長尾 高弘 訳 本書は、現実世界の問題を解決するプログラムを開発、利用する方法を説明しながら、コンピュータとプログラミングの基礎を解説します。例題のほとんどは科学技術分野のものですが、考え方はあらゆる分野に応用できます。また、プログラミングについての系統的、方法論的な考え方について、特に複雑な問題を単純な問題に分割し、それら単純な問題の解決方法を組み合わせて複雑なアプリケーションを作る手順を学びます。 本書を読み終えるころには、プロフェッショナルなプログラマが物事をどのようにとらえて発想するのか、つまりプロフェッショナルなプログラマのように考える方法を手に入れられるでしょう。 1章 イントロダクション 1.1 プログラムとプログラミング 1.2 若干の定義 1.3 インス
サイボウズ式「続・エンジニアの学び方」の第5回が公開されました。この回では、小崎さんが「どうしてコードを読もうと思ったのか」と、コードを読むために新しい言語を学ばなければいけない場合に「どうやって学ぶか」を聞きました。 ところで、小崎さんは自分の学び方を「写経」と読んでいて、僕もこの用語は自然に理解できるのですが、公開後のTwitterの反応を見ていると「写経と呼ぶことが嫌」もしくは「仏教での写経の印象で、内容を勘違いしている」という事例がいくつも見つかりました。 プログラミングの学習法としての「写経」という言葉は色々な書籍で使用されています。例えば「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」の70ページでは「まず写経することから始めた」というエピソードが紹介されています。また「改訂新版 コンピュータの名著・古典100冊」の99ページでは「技術書の内容にそって深い
プログラミングを始めたときに、「職業」としてはあまり意識していなかった人も多いと思う。しかし、困難を乗り越えて経験を積み、コンソールを前に数十年がたってみると、このような長い道が続いていることを最初に知っていればよかったと思う。そこで、昔の自分や現在プログラミングを始めようとしている若者たちに対し、どのようなアドバイスができるだろう。Andrew C. Oliver氏はプログラマーになったばかりの頃にあまり意識していなかったことについて、いくつかの考えをまとめている。皆さんの場合はいかがだろうか。 Andrew C. Oliver氏が早いうちに知っていればよかったと考えているのは以下のようなものだ。 人の名前を覚える 見方を変えて問題を解決する マーケットと自分の仕事に合わせて言語や技術を選ぶ ソフトウェアの面で大きな革新が起こることは比較的少ない 仕事の連続ではなく、職業だと考える 週に
最近では 最適化 という言葉を使う場合、GPUメモリ消費やネットワークトラフィックの最適化、などと明示的に言わない限りは、 実行時間の最適化 という意味で使われるケースがほとんどです。 自分が何を最適化しようとしているかを知ろう 私がプログラムを始めた頃、プロセッサの処理能力は遅く、メモリサイズもとても限られていて、キロバイト単位で計算されていました。ですからメモリ容量をよく考え、メモリ消費を上手に最適化しなくてはなりませんでした。大学では最適化について2つの極論を教わりました。 メモリを犠牲にして実行スピードを最適化する。 または何度も計算を繰り返して、メモリ消費を最適化する。 最近では誰もメモリについては大して気にしていません(デモシーン製作者、組み込みシステムのエンジニア、一部の携帯電話ゲームのディベロッパなどは別です)。RAMだけでなく、ハードディスクの容量についても同様です。 W
RubyGems.org is the Ruby community’s gem hosting service. Instantly publish your gems and then install them. Use the API to find out more about available gems. Become a contributor and improve the site yourself. The RubyGems.org website and service are maintained and operated by Ruby Central’s Open Source Program and the RubyGems team. It is funded by the greater Ruby community through support fro
topcoderというと「競技プログラミングのサイト」というイメージを持っている人が多いだろう。もちろん今でもその性格は色濃く残っているが、最近では「企業がシステム構築(SI)に利用できるサービス」という面が強くなっている。企業が、自らが必要とするソフトウエアの開発をtopcoderでコンテストとして掲示し、そのコンテストに参加するプログラマの解答を募るのだ。 クラウドコンピューティングに強みを持つSIerの米Appirioは、2013年9月にtopcoderを買収した。Appirioの日本法人であるアピリオ 代表取締役社長の藤田純氏(写真)によると「93%強の案件で、コンテスト開催企業が満足する解答を得られている」という。逆にいえば、失敗率はわずか7%弱。一般的なSIでどれだけの顧客が結果に満足しているかを考えると、驚くべき数字だ。Appirio自身も、顧客のシステムのプロトタイプ作成や
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? プログラマーの通り名とは プログラミング言語っていろいろありますよね!!ぱっと思いついた順に列挙してみると、「C」「Java」「Ruby」「Python」「JavaScript」「Perl」「awk」「Objective-C」「Haskell」「Prolog」「ActionScript」「PHP」「Swift」「Scala」「Groovy」「Verilog」(手が止まったので、ここで終了)などなど、数え上げたらキリがありません。 そのプログラムを使う人のことを、「Ruby使い=Rubyist(ルビイスト)」と言ったり、「Perl使い=P
y***s: 英語にくわしいフバさんに質問なんですが y***s: 1300 みたいなのを 1.3 K bytes みたいなのに整形するメソッドってなんてメソッド名にすればいいんですか fuba: -h When used with the -l option, use unit suffixes: Byte, Kilobyte, Megabyte, Gigabyte, Terabyte and Petabyte in order to reduce the number of digits to three or less using base 2 for sizes. fuba: man ls にはこんなかんじでかいてる y***s: なるほど shunirr: human readable fuba: to_human_readable_string みたいなのだるそうではある sh
プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムの本に、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ
常に世界のどこかで誰かが、この世で一番のプログラミング言語は何かというトピックで投稿し、忘れ去られた言語のすばらしい一面や、新しい言語の有用性を主張しています。どうやら、その順番が私に回ってきたのかもしれません。そろそろ私も、プログラミング言語についての自分の考えを皆さんにお伝えしようと思います。 始めに少し言い訳をさせてください。30以上の言語で開発した経験があり、他の人が書いた多くのコードと悪戦苦闘をしてきた開発者でもない限り、「自分の意見には客観性がある」とはとても言えないと思います。そんなわけで、このトピックを取り上げる他の多くの人と同じように、私の意見も偏っています。多くの言語に精通した開発者がこの話題自体を不毛だと感じるのは、このせいかもしれませんね。 要約: すばらしい言語 早速、このブログ限定ということで、私が考える”すばらしい言語”を発表しましょう。 アセンブリ言語: マ
http://codic.jp/ プログラミングをする上で一番時間のかかる作業ってなんだと思いますか? アルゴリズムを考えること? タイピングしてプログラムを組むコーディング作業? いえいえ違いのです、変数・関数などの名前を考えるのが一番時間がかかる。 これ冗談じゃなくて結構おおむねほぼ本当の話です。難しいのですよ名前を付けるっていう行為は。ナウシカにおいて、巨神兵をオーマと名付ける事によって自我に目覚めたように、対象の存在意義を定める行為に等しい。だから対象がなんであるかをとことん考え抜く必要があるのです。この関数はどういった機能を持っているのか、この変数はどのような値を格納するためのものか、このクラスは何を表現しているのか、存在するとはなにか、生きるとは。往々にして思考が哲学的な方向に脱線したりしてとにかく時間がかかる。 それに加え一度決めてしまうと、なかなか別の名前に変えるというのも
This is why you shouldn't interrupt a programmer (なぜプログラマの作業に割り込むべきではないか) という4コマ漫画が話題になっていた。これは別にプログラマではなくても「わかるわかる」という感じの話。 コメントを見ると、だから作業を中断してもすぐ再開できるように自分の考えることをなるべく書き出すようにしているという人が結構多かった。なるほど。 今日は雨が降ったせいで予定が一つキャンセルになったことだし、ちょうどいい機会なので、文章で何かを書くということについて自分が思っていることを書いてみようとおもう。以前 Software Design のドキュメントの書き方特集みたいな号に似たような趣旨の話を寄稿したのだけど、「書く」というのは単に物事を忘れないようにするための行為に留まるものではなくて、自分の考えを整理するための道具なのだ、ということが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く