QuickDrawはどのように素早く円を描いていたのか？ - ザリガニが見ていた...。
かつてのMac OS9までの描画エンジンの主役はQuickDrawが担っていた。GUIなOSでは、文字も含めてすべてをグラフィックとして扱うので、画面に見えているすべてのもの*1はQuickDrawによって描かれていたことになる。描画エンジンは、GUIなOS開発の要となる技術である。その出来が、GUIなOS開発の成否を分けるとも言える。 そして、最初期のQuickDrawは、ビル・アトキンソンがたった一人で開発したそうである。 当時（25年以上前）のCPUは、動作クロックが8MHzという性能だった。（現在は2GHz=2000MHzかつ、複数コアが当たり前） そのような性能であっても、違和感なくマウスで操作できるOS環境にするために、斬新な発想や試行錯誤を重ね、相当な努力の末に開発されたのがLisaやMacintoshであった。 Amazon.co.jp： レボリューション・イン・ザ・バレー
言語やフレームワークの流行り廃りをどこで知る?
一つの読み物としてお読みください。 言語やフレームワークの流行り廃りが知りたいだって？まぁ、あんな物は適当だ。取りあえずどうやって調べるかって所から行こうか。 ランキングを見る。 もちろんTIOBE Indexは毎月チェックしているよな？自分のお気にの言語の順位が上がったり下がったりで一喜一憂するのも乙な物だ。といっても、あんなのあまり当てにならない。ぶっちゃけ古く知られた言語の方が有利だからだ。もっと切実な生の情報を知りたいなら、The RedMonk Programming Language Rankings: January 2018を見るべきだろう。ランキング上位のメンツはだいたい同じだが、順位は全然違うだろ。つまり、そういうもんだ。 他にもStackOverflowの集計とか、なんかのアンケートとか、そんなランキングもある。求人情報を元にした奴もなかなか面白い。あと、Google
SimpleDateFormatのマルチスレッド問題 | プログラミング
JavaベースのWebサイトを本番リリースした後、発生するトラブル・・・。あってはいけないけど、トラブルが発生した原因を調査し、対処しなきゃいけない。 で、原因を調査するとき、まず再現条件を調べるんだけど、再現させるのが難しいのがこのマルチスレッド問題。ページをリロードする度に、うまくいったり、エラーになったりを繰り返すから、再現条件は分からない。ほとんどの場合、調査にも時間がかかってしまう。 Javaの関連記事： OutOfMemoryError回避のためのJavaコーディング – 前編 自力でNoClassDefFoundErrorを解決！（前半） マルチスレッドの注意点まとめ OracleでDate型の時刻が00:00:00になる原因 MissingResourceExceptionの解決法 NoClassDefFoundErrorの原因と対応(2) Eclipse スクラップブック
「プログラミングの常識」を時々見直す必要性について｜Rui Ueyama
自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindowsの初期の頃に設計されたデータ構造には、メモリをバイト単位ででもいいから節約したいという意図の痕跡がいまでも多く見受けられる。DRAMの次に速い記憶装置はHDDだったので、メモリが足りなくなればHDDにデータを保存せざるを得ないのだが、DRAMとHDDのランダムアクセスの速度差は、机の上の本の開いているページを見るのと、その本をAmazonで注文して到着するのを待つのと同じくらいのスケールで違うの
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。 ..
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。 https://www.nnn.ed.nico 一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。 月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。 もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。 内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。 http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB
間違ったコードは間違って見えるようにする - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2005年5月11日 水曜 私が最初の本当の仕事をはじめたのは1983年9月に遡る。それはオラニムというイスラエルの大きな製パン工場で、16台の飛行機ほどもある巨大なオーブンで、毎晩10万個のパンが作られていた。 はじめて工場に入った時、そのあまりの汚さに信じられない思いだった。オーブンの側面は黄ばんでいるし、機械は錆びていて、そこらじゅうが油だらけだった。 「いつもこんなに汚いの?」と私は聞いてみた。 「なんだって? なんの話をしてるんだ?」とマネージャが答えた。「掃除したばかりだから、今が一番きれいな状態なんだ」 なんてこった。 毎朝の工場の清掃を何ヶ月か続けて、ようやく彼らの言っていたことが理解できるようになった。パン工場では、きれいというのは機械にパン生地が付いてないことを言うのだ。きれいというのは、ゴミ箱に発酵したパン生地が入ってないこと
プログラミング教育にも悪い大人が群がってしまうのか
「この人は英語がしゃべれないのに、なぜ英語を教えているのだろう」。私は中学校の英語の授業のときにこう思っていた。その英語教師の発音はカタカナ英語で、教科書に書いてあることしか話さない。本当に英語が話せなかったのかどうかはわからないが、少なくとも生徒から見る限り、話せるようには見えなかった。 私が通っていたのは地方の公立中学校であり、何十年も前の話だ。教師に限らず、周囲の大人に英語を話せる人は一人もいなかった。おそらく地方の公立中学校のレベルはどこでもこの程度だったのだろう。 この英語教師に特に問題があったとは思っていない。教科書に沿って英文法をきちんと教えてくれたはずだ。しかし、生徒がこうした教師を見て「自分もこの人みたいに英語がしゃべれるようになりたい」と思うことはない。 今では英語を話せる人は珍しくなくなった。さすがに英語を話せない人が英語教師を志すことはないだろう。ところが「できない
年配の方に「プログラミング教育の意義」をわかってもらうにはこう言えばイチコロだった、という話
レオナ @reona396 前職でプログラミング教育の営業を少しやった事があったけど、年配の方には「プログラミング教育の意味？なぁに、家庭科の授業と同じです。食卓に出された物をふんぞりかえって食べてるだけじゃ感謝の心も芽生えず社会のしくみもわからない。ITも自分の手で学ぶのが大事なんです」でイチコロだった 2017-05-10 23:23:07 レオナ @reona396 これを言うと「そーなのよ、うちの娘も寝っ転がってLINEやるばかりで……そうね、自分でしくみを知るのが大事よね…」ってなっていらっしゃった。自分の手元に来るまで色んな人が関わってて、作る人の苦労があってこそ今ここにあるのだ、という意味ではお料理もアプリも一緒ですと説明してたっけな 2017-05-10 23:25:53 レオナ @reona396 あとプログラミング教育の教材について、いくら「簡単だからとっつきやすいです
開発者に嫌われているプログラミング言語トップ25 | マイナビニュース
fossBytesに3月28日(米国時間)に掲載された記事「Which Are The Most Loved and Most Hated Programming Languages｜2017」が、Stack Overflow Developer Survey 2017の調査結果を引き合いに出し、開発者に愛されているプログラミング言語と嫌われているプログラミング言語のトップ25を伝えた。愛されているプログラミング言語1位はRustで、これにSmalltalkとTypescript、Swift、Goが続いている。 嫌われているプログラミング言語トップ25は次のとおり。 Visual Basic 6 VBA CoffeeScript VB.NET Matlab Objective-C Assembly Perl Lua Hack Groovy Common Lisp Dart Erland P
全盛期のJeff Dean伝説 - Qiita
Jeff Deanとは GoogleのSenior Fellow. Googleの基盤となる分散システムのほぼ全てに中心的に関わり、圧倒的なエンジニアリング能力を発揮したらしい。あまりにも尊敬されているため、IT業界において全盛期のイチロー伝説のような破天荒なホラ話のネタにされている人。 日本語での紹介がなさそうだったので意訳してみました。 元ネタはこちら。多すぎるのでGoogle社員じゃない人には面白みがわかりにくそうなもの、面白みが被っていると私が判断したものなどは省いてあります。 NP問題 Jeff DeanがGoogleの採用面接を受けたときに、もしP=NPが成り立つとしたらどうなるかを問われて"P=0かN=1ですね"と答えた。試験官が笑い終わりさえしないうちに彼はGoogleのpublic keyを突き止め、private keyをホワイトボードに書き終わった。 Jeff Dea
PHPのinterfaceなめんな - なんたらノート第三期ベータ
はいタイトルは釣りです。 OOPのインターフェースはただの実装漏れチェック機能じゃないし、ましてや継承は差分プログラミングツールじゃないぞ。というのはわりと一般的な話だけど、Ruby(respond_to?でホントにいいの)とJava(インターフェースが自然すぎてユーザが意識しないのよ)が、PHPに対してOOPどうこうで偉そうに言うのはどうかなと思ったもので。まあそれと同時に、PHPの人自身がその意義を発見してるのかなという疑問もあったりしたんですけどね。 Rubyというのは「オブジェクト指向ってのはつまりメソッドに応答できるアヒルはみんなアヒルとみなせるよね」というレベルのダックタイピングで割り切った言語だと、個人的に認識しています。継承とミックスインにはis_aが応答するけど本質はrespond_to?のほうで、インターフェースを宣言してなくてもメッセージ送れたらいいあの感じ。 そんな
ダックタイピングという考え方は間違ってると思いませんか？ - http://ja.wikipedia.org/wiki/%E3%83... - Yahoo!知恵袋
ダックタイピングという考え方は間違ってると思いませんか？ http://ja.wikipedia.org/wiki/%E3%83%80%E3%83%83%E3%82%AF%E3%83%BB%E3%82%BF%E3%82%A4%E3%83%94%E3%83%B3%E3%82%B0 今のオブジェクト指向言語はダックタイピングが当たり前、Javaのinterfaceは古い、 という意見をネット上で見かけたのですが、正しいと思いますでしょうか。 かつてC言語とPerlしか知らなかった私は、Javaのinterfaceを知って衝撃を受け、 そこからポリモーフィズムなどのオブジェクト指向設計を意識するようになりました。 クラス型が違えど同じメソッドを持っていれば同様に処理する、というダックタイピングのメリットは私には理解できません。 異なるクラスで、たまたま名前とパラメータが同じでも、中身の動作が違う
歳を取ってもエンジニアを続けられるのか
エンジニアが年を取るとはどんなことだろう。年を取ることのデメリットとメリット、加齢に対する心構えを筆者自身の経験を基に語ってくれた。 ← 前回 連載 INDEX 次回 → 今回は割と語り尽くされた感のある話題であるが、歳を取ってもエンジニアが続けられるのかという話をしてみたい。最初に結論から言ってしまえば、歳を取ってもエンジニアは「もちろん続けられる」なのだが、そうはいっても老化というのは否応なしに全ての人の身に降りかかってくる（将来は遺伝子研究が進んで老化というものがなくなるのかもしれないが）。 30半ば過ぎの方は、最近物忘れが段々と増えてきたり、あるいはもともと視力の良い方であれば近くが見えづらくなってきたりと、このままエンジニアという職を続けてよいのだろうかと不安を抱えているかもしれない。今回は、老化への対処について具体的に取り上げたい。また、老化には負の側面だけでなく、プラスとなる
高慢と偏見（1）隣は何をする人ぞ：Press Enter■：エンジニアライフ
ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 高学歴で長い経験に自信を持つエンジニアは他人の話を聞かなくなる、というのは広く世に知られた真理の1つである。 K自動車ICTシステム部の三浦技術担当マネージャは、そのようなエンジニアの生き見本のような人だった。初めに言葉ありき。私が聞いた三浦マネージャーの最初の言葉はこうだ。 「オブジェクト指向など、実業務では使いものにならない！」 私の名前は川嶋ミナコ。横浜市内の某所にオフィスを構えるシステム開発会社――いわゆるベンチャー企業というやつ――に勤務しているエンジニアだ。社員数は20人前後。最近は受託開発の案件はほとんどなく、大手ベンダやエンドユーザーのシステム部門に常駐して開発を行うことが多い。 K自動車への常駐もその1つだった。部品調達システムの大規模なリニューアル中で、あちこ
「人工知能」ブームに乗り遅れた！という方々に捧げる人工知能（機械学習）まとめ記事 - 六本木で働くデータサイエンティストのブログ
(Photo credit: A Health Blog via Visual Hunt / CC BY-SA) 「人工知能」ブームが本格化してまだほんの数ヶ月だと思うんですが、気がついたらTV含む大手メディアが皆こぞって毎日のように「人工知能」を取り上げ、あまつさえ政府や与党の諮問会議でまで「人工知能」の語が飛び交う有様で、一体何をどうしたらこうなるのか僕には全く分かりません（汗）。 とは言え、実際にビジネスの現場でも「人工知能」への期待感が日に日に高まり続けているのは事実で、例えば友人知人の経営者との酒席でも「最近人工知能ってめっちゃくちゃ流行ってるじゃん、あれって実際どうなの？本当に役に立つの？今からでも人工知能事業に参入すべきなのかな？それとも俺たちあいつらに滅ぼされちゃうの？」みたいなことを聞かれることが多いんですよね。 ということで、そういう「人工知能」ブームに乗り遅れたけれど
オブジェクト指向の問題点 - ビスケットのあれこれ
オブジェクト指向プログラミングを神格化するような記事が流れてきたので，僕が知っている問題点について書いてみたいと思います．僕がまだ学生だったころは，オブジェクト指向の評価もまだそれほど定まっていなくて，オブジェクト指向の次はどんなパラダイムが出てくるかとか普通に学生レベルで議論していたものですが，ここまで強大になってしまうとそれを打ち負かそうなんて気にはならないのでしょうか．僕にはオブジェクト指向が普遍的な真理という感じは全然しなくて，ここまで使われてる理由は，現実的なテクノロジーで大きなシステムを作らなければならない必要性のほうを優先した結果であると認識しています．オブジェクト指向がその後の25年ほどもずっと安定してその地位を保てるほど素晴らしいものとは思えないのです． 以下で上げる問題点は，個別に解決している研究はあったりしますし，僕も論文を書いたりしましたけど，実際の言語に導入されて
はじめの言語の賞味期限 - Kato Kazuyoshi
ライブドアブログの PSGI 化の話 は良いはなしだと思う。一方で、私はあんまり Perl が好きじゃないので、10年にわたって生き続けた Perl アプリケーションが、次の10年にむけてアップをはじめているのは、ちょっとしたホラーでもある。 Twitter と Ruby と JVM ライブドアブログが、将来に向けて mod_perl から PSGI + Starlet にかえたように、将来に向けてプログラミング言語をかえる人達も存在する。最近の事例で有名なのは、Twitter の Ruby から JVM 言語群への移行だろう。 OSCON Java 2011 の Twitter: From Ruby on Rails to the JVM では、JVM への移行に至った理由として Ability to handle server workloads A real concurrency
ECMAScript と OOP パラダイム、それに ES.next の議論中 OOP 周りのシンタックス - oogatta のブログ
JavaScript Advent Calendar 2011 (オレ標準コース)4日目の id:oogatta です。どうもどうも、いやどうも。 最近丁度 ES Wiki を眺めていて、面白いことになってるなあ。変態的なことになってるなあ。と楽しく見ていた OOP パラダイム周りのいくつかの手法（定義、継承、 mixin 、 trait ）について、 ES.next または Harmony で議論されているものをご一緒に調べながらご紹介したいと思います。 ECMAScript3 さて、復習としてまずは ES3 での OOP パラダイムの実装についてですが、これはもう Dmitry 先生の ECMA-262-3 in detail. Chapter 7.1. OOP: The general theory. を読んでくださいというか、気持ちよく丸投げしたいところですが、翻訳すると言ってまだ
5つの世界 - The Joel on Software Translation Project
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/5/6 ある重要なことがプログラミングやソフトウェア開発についての文献でほとんど語られず、そのため私たちは互いに誤解する結果となっている。 あなたはソフトウェア開発者だ。私もそうだ。しかし私たちの目的や要求は異なっているかもしれない。実際、ソフトウェア開発にはいくつかの異なる世界があり、異なった世界ではルールも異なっている。 あなたがUMLモデリングの本を読んでも、それがデバイスドライバのプログラムを作るのには役立たないということはどこにも書かれていない。あるいは「(.NETに必要な)20MBのランタイムは問題ではない」というアーティクルを読んでも、それは当たり前のことに触れていない：あなたがROMが32KBの携帯電話のためのコードを書いているなら、それは十分に問題だ！ ソフトウェア開発には
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「なぜDI(依存性注入)が必要なのか？」についてGoogleが解説しているページを翻訳した - Qiita
