Go言語がダメな理由 | POSTD
私はGo言語が気に入っていますし、多くの場面で使用します。現にこのブログもGoで書いています。Goは便利な言語ですが、優れた言語とは言えません。つまり、悪くはないけれど、十分ではないということです。 満足できない言語を使用する際は注意が必要です。注意を怠ると、その言語を次の20年間使い続ける羽目になるかもしれないからです。 私のGoに対する主な不満を本文にまとめました。既に何度も指摘されていることも含まれていますが、中にはこれまでほとんど話題になっていない指摘もあります。 これから列挙する全ての課題には既に解決策があることを示すため、私が優良な言語と考えるRustやHaskellと比較して説明します。 汎用プログラミング 課題 誰でもさまざまな事柄に幅広く対応できるコードを記述したいと考えます。例えば数のリストの合計を求めるために定義した関数が、小数、整数、またその他の合計を求められるもの
PHPはもうダメだ、PHP万歳！ | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) GutenbergとWordPressに関する騒動は、PHPの終焉につながる最新記事です。深呼吸をしてください、みなさん。トロールは無視し、Mark TwainとFidel CastroとPHPとの共通点を見ていきましょう。そして、もっと重要なのは、スタートアップやスモールビジネスにとって、PHPが今でも合理的な選択である理由です。 PHPはいつから廃れ始めたのか “PHPはもうダメだ”といったブログの投稿が、登場し始めたのは2011年のようです（これより古いものを見つけたら、お知らせください）。Mediumや、mushroomsのように突然出現したcoding bootcampsを探し回れば、その唯一の共通点は、みんながPHPを嫌っているか、あるいは単に無視しているかです。どうやら、法外な値段のコー
気をつけよう：プログラミングのキャリアの話 – 前編 | POSTD
プログラミングの森の奥で道に迷わないために 私がプログラミングの仕事を始めたばかりのころの悩みの種は、どの言語や技術を選ぶべきか、でした。何を学び、何から始めればいいのか。プログラマとしての初仕事を獲得するために知っておくべきことは何か。そのころ（ほぼ10年前）、CourseraやUdemyや SoloLearn は、ありませんでした。いい職に就くための確実な方向、完璧な道筋がどんなものなのか、私にはわかりませんでした。高給で、満足できて、優遇される、21世紀の宇宙飛行士、つまりプログラマの仕事を得るには。 問題は今でも相変わらず同じです。ビギナーは選択の段階でつまずき、優れたプログラマになるための近道はなく、コミュニティは「Pythonっていう言語は簡単ですか？」というような新入りの質問を歓迎するほど温かくもありません。プログラマとして成功するための道筋は、むしろ以前よりも見えにくくなっ
プログラマの採用面接で聞かれる、データ構造とアルゴリズムに関する50以上の質問 | POSTD
情報科学科の卒業生やプログラマの中には、UberやNetflixのような新興企業や、 Amazon 、 Microsoft 、 Google のような大企業や、InfosysやLuxsoftのようなサービスを基本とする企業で、プログラミング、コーディング、ソフトウェア開発の仕事に就きたいと考える人が大勢います。しかし、実際にそういった企業で面接を受ける場合、大半の人が プログラミングに関してどのような質問をされるか 見当もつきません。 この記事では、 新卒生からプログラマになって1〜2年までの 経験値が異なる人たち向けに、それぞれの プログラミングの面接でよく聞かれる質問 をいくつか紹介していきます。 コーディングの面接では、主に データ構造とアルゴリズムに基づいた質問 がされますが、 一時変数を使わずにどのように2つの整数をスワップするのか 、というような論理的な質問もされるでしょう。
分岐予測の簡単な歴史 – Part 3 | POSTD
その他 今回、取り上げなかった方法も沢山あります。皆さんの予想どおりかと思いますが、紹介しなかった方法の方が、紹介したものよりずっと多いのです。紹介しなかった方法については、いくつか簡単に説明し、参考サイトを紹介しますので、さらに学びたい場合はそちらを確認してください。 取り上げなかった主要な概念の１つに、 分岐先を予測する方法 が挙げられます。これは、無条件分岐（必ず分岐が成立するため、方向の予測が不要な分岐）にも行う必要がある点に注意してください。なぜなら、 （いくつかの）無条件分岐は分岐先が分からない からです。 分岐先予測はコストが高くなるため、初期のCPU は”常に分岐は不成立だと予測する”という概念を用いていました。なぜなら、分岐が不成立だと予測すれば、分岐先は不要だからです。”分岐は不成立”と常に予測する方式は精度が落ちますが、それでも全く予測しないよりマシです。 干渉低減方
分岐予測の簡単な歴史 – Part 2 | POSTD
2ビット方式 1ビット方式は TTTTTTTT… や NNNNNNN… といったパターンにはうまく働きますが、 ...TTTNTTT... のような「ほとんど成立するが1回だけ不成立」のような分岐の流れでは予測ミスが起きてしまいます。それを改善するために登場したのが、各アドレスに対してもう1ビット追加した飽和カウンタです。では仮に、分岐が不成立だった時はマイナス1、成立した時はプラス1するとしましょう。バイナリ値で見ると以下のようになります。 飽和カウンタの「飽和」とは、 00 にマイナス1した場合はそれ以上値が小さくならずに 00 のまま、 11 にプラス1した場合も 11 のままという動作を取ることを指しています。この方式は1ビット方式とほぼ同一ですが、唯一違うのは予測テーブルの各エントリが1ビットでなく2ビットであるという点です。 1ビット方式に比べると、2ビット方式は同じサイズ/コ
分岐予測の簡単な歴史 - Part 1 | POSTD
※これは、 RC（The Recurse Center：プログラマ教育施設） によって組織された講演シリーズである”localhost”を始動するために、Two Sigma（ツーシグマ）での2017年8月22日の分岐予測に関する講演の原稿を仮に書き起こしたものです。 コードで分岐を使われている方は、どれくらいいらっしゃいますか？ ifステートメントやパターンマッチングを使われているという方、よろしければ手を挙げてください。 ほとんどの聴衆が手を挙げる 次の質問に関しては手を挙げてもらうつもりはありませんが、もしそうお願いした場合、恐らく手を挙げる人の数は少なくなるのではないでしょうか。その質問とは、「分岐を実行する際、CPUが何をして、そのパフォーマンスは何を意味しているのかを十分に理解しているか」、そして「分岐予測に関する最新の論文を理解できるか」というものです。 この講演の目的は、CP
色：ヘキサコードから眼球まで – Part 3. | POSTD
これらをプロットすると、MacBookのLCDディスプレイに類似した（ただし、わずかに小さい）色域になります。 注釈： MacBook ProのLCDの色域 sRGBの色域 一部の箇所では、MacBook ProのLCDディスプレイの色域からsRGBの（正式な）色域がはみ出ています。つまりこの部分については、LCDは忠実に色を再現できません。これに対応するため、MacBookでは変更を加えたsRGBの色域を使っているようです。 注釈： 正式なsRGBの色域 MacBook ProのLCDの色域 MacBook ProのsRGBの色域 sRGBはデフォルトの色空間として広く利用されています。また、ブラウザの標準的な色空間（ CSS標準で指定 ）でもあります。このブログの記事の図で使われているのは全てsRGB空間内の色です。逆に言うと、sRGB空間外の色であれば、正確に再現されないということに
色：ヘキサコードから眼球まで – Part 2. | POSTD
色空間 色は、色空間を用いると数値を使って正確に定義できます。前のセクションでは、ある種の黄色がSML色空間で(0.02, 0.12, 0.16)と表せることを見ました。なお、SML色空間は LMS色空間 という名前のほうがよく知られています。 この色空間は、錐体細胞への刺激を表しています。それゆえ、定義づけによって人間が目で捉えられる全ての色を、LMS色空間上で正の値の座標として表すことができます（非常にまれな存在である4色型色覚の人間は除きます。3つの座標ではなく4つの座標が必要になるからです）。 しかし、ああ、SML色空間には不便な特性があります。 その1つは、全てのトリプレット値（ 三刺激値 とも呼ばれます）が 物理的に実現可能 というわけではないということです。LMS色空間の(0, 1, 0)を考えてみましょう。この座標を物理的に実現するにはLやSの錐体細胞を 全く 刺激せず、M
色：ヘキサコードから眼球まで – Part 1. | POSTD
注釈： 波長（um） 網膜錐体の励起 私たちの目が、 background-color: #9B51E0 を、この紫色だと知覚するのはなぜでしょうか。 長い間、私はその答えを知っていると思っていましたが、よく考え直してみると、かなり大きな思い違いをしていることに気付きました。 そこで、この思い違いを、電磁放射、光生物学、測色学、表示用ハードウェアについて探求しながら解消していこうと思います。本文の構成は次のようになっています。飛ばし読みしたい方は好きな章から読んでください。 電磁放射 可視光線 人間が知覚する輝度 色の定量化 視覚の生物学的メカニズム 色空間 ライトとギルドの等色実験 色空間と色度の可視化 色域とスペクトル軌跡 CIE XYZ色空間 画面のサブピクセル sRGB sRGBヘキサコード ガンマ補正 ヘキサコードから眼球まで 輝度設定について 書き切れなかったこと 参考文献 で
なぜPythonはこんなにも遅いのか？ | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) Pythonは高い人気を誇り、DevOps、データサイエンス、Web開発、セキュリティの分野で使われています。 しかし、速度に関しては高い評価が全くありません。 JavaとC、C++、C#、Pythonの速度を比べるには、どうしたらいいのでしょう？ 答えは、実行するアプリケーションのタイプに大きく左右されます。完璧なベンチマークはありませんが、[手始めに比べる手段](https://algs4.cs.princeton.edu/faq/)としてはThe Computer Language Benchmarks Gameが適しています。 私は10年ほどthe Computer Language Benchmarks Gameを参照していますが、Java、C#、Go、JavaScript、C++などの他言
Rust開発者のためのC++入門書：所有権と借用について | POSTD
今日、ソーシャルサイト「reddit」を見ていたら、“ Rustの基礎を学んでからC++を始める場合 、何を勉強すればいいか”と問う投稿があり、私は自分のブログを復活させ、その中で質問への答えを書いたら面白いのではと考えました。 私にはRustを学んだ後にC++を扱う仕事に就いた経験があるため、Rustの経験を持つ人がC++に移行していく様子をまとめてみたいと思ったのです。 本稿はC++の構文と特徴を既に知っていて、RustからC++の世界に移行する方法に興味を持っている読者を対象とします。 しかし、私は全てに精通しているわけではないので、本稿では所有権（ownership）、借用（borrowing）、ライフタイム（lifetime）に焦点を当てて説明していきます。 所有権と移動 Rustの一番大きな特徴は所有権です。所有権は、プリミティブ型ではない値に対するデフォルトの動作として、コピ
C90, C99, C11, C++98, C++11で異なる動作をするコード | POSTD
(訳注：2016/9/28、頂きましたフィードバックを元に記事を修正いたしました。) C言語の規格のリビジョン間には微妙な違いがありますが、このことを利用して「C90、C99、C11のどれとしてコンパイルされたかどうかにより、違う挙動をする」というプログラムを作ることが可能です。同様に、C++はほぼC言語の上位互換ですが、C言語とC++で違った結果を生み出すプログラムも存在します。 これは2015年の International Obfuscated C Code Contest (難読Cコード・国際コンテスト)への Don Yangの投稿 において、 C89、C99、C11、C++98、C11のどれとしてコンパイルされるかによって異なる出力を生成するプログラムを作成するのに使われています。C90の場合は、以下のような星形を出力します。 **************************
C/C++中規模プロジェクトのための超シンプルなMakefile | POSTD
私は多くの小規模プロジェクトで Make を使ってきましたが、より大きな規模のプロジェクトになると、それは非常にうんざりするようなものでした。最近までは、自分のビルドシステムに行いたいことが4つあったのですが、Makeでの方法が分かりませんでした。 out-of-sourceビルド（オブジェクトファイルが、ソースとは分離されたディレクトリにダンプ出力されます） 自動生成される（かつ正確！）ヘッダの依存関係 オブジェクト／ソースファイルのリストの自動的な決定 インクルードディレクトリのフラグの自動生成 以下にこれらの全てを行える、C、C++、およびアセンブリで動作するシンプルなMakefileを紹介します。 MAKEFILE TARGET_EXEC ?= a.out BUILD_DIR ?= ./build SRC_DIRS ?= ./src SRCS := $(shell find $(S
学校では習わないコーディングスキル：オブジェクト所有権 | POSTD
プログラマとして身に着けるべきスキルはたくさんありますが、中には、ソフトウェアエンジニアリングの標準カリキュラムに組み込まれていないものもあります。そうしたスキルは少しずつ自然に、あるいは経験豊富な人と一緒に仕事をする中で学ぶ必要があります。1つDavid MacIverが取り上げているのは、 値の型を追跡するスキル です。 他には、コード中のオブジェクト所有権を理解するスキルも必要です。つまり、コードのどの部分がメモリ内の特定オブジェクトを所有し、それがどんなアクセスを予期しているかを知るということです。 その理解なしにコードを書くと、プログラムがクラッシュしたり厄介なバグに悩まされたりすることになるかもしれません。さらに悪いことに、プログラミング言語の中には、この問題に役立つ手段さえ提供してくれないものもあるでしょう。 自然に身に付ける これは、私がこのスキルを学んだ方法です。私は大学
私はC言語を知らない | POSTD
(注：2017/04/27、いただいたフィードバックを元に翻訳を修正いたしました。) この記事では、皆さん（特にC言語のプログラマ）に「自分はCを分かっていなかった」と気付いてもらうことを目標にしています。 Cの落とし穴は、思っているよりもずっと身近なところにあります。ちょっとしたコードにも 未定義の動作 が潜んでいることを以下で示しましょう。 この記事はQ&A形式になっており、それぞれの例題は独立したソースコードとして扱ってください。 1. Q: これは正しいコードでしょうか？ （変数の二重定義エラーが発生するでしょうか。上述の通り、これは独立したソースファイルであり、関数本体や複合ステートメントの一部ではありません） 解答 A: 正しいコードです。1行目は仮定義であり、2行目でコンパイラが処理した後に “定義” になります。 2. extern void bar(void); void
2016年、C言語はどう書くべきか (後編) | POSTD
(前編はこちら： 2016年、C言語はどう書くべきか (前編) ) (編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) システム依存の型 まだ「32 bitのプラットフォームでは32 bitのlong型、64 bitのプラットフォームでは64 bitのlong型がいい」という不満があるようですね。 プラットフォームに依存する2つの異なるサイズを使うため、 故意に コードを難しくすることを考えたくなければ、システム依存の型のために long を使おうとは思わないでしょう。 この状況では、プラットフォームのためにポインタ値を保持する整数型、 intptr_t を使うべきです。 モダン32-bitプラットフォームでは、 intptr_t は int32_t です。 モダン64-bitプラットフォームでは、 intptr_t は int64_t です。 int
2016年、C言語はどう書くべきか (前編) | POSTD
(訳注：2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注：著者のMattより、「本文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例： 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり
Dockerコンテナが遅くなるもう一つの原因 | POSTD
前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。本記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ
ディープラーニングの限界 | POSTD
(注：2017/04/08、いただいたフィードバックを元に翻訳を修正いたしました。 @liaoyuanw ) この記事は、私の著書 『Deep Learning with Python（Pythonを使ったディープラーニング）』 （Manning Publications刊)の第9章2部を編集したものです。現状のディープラーニングの限界とその将来に関する2つのシリーズ記事の一部です。 既にディープラーニングに深く親しんでいる人を対象にしています（例：著書の1章から8章を読んだ人）。読者に相当の予備知識があるものと想定して書かれたものです。 ディープラーニング： 幾何学的観察 ディープラーニングに関して何より驚かされるのは、そのシンプルさです。10年前は、機械認識の問題において、勾配降下法で訓練したシンプルなパラメトリックモデルを使い、これほど見事な結果に到達するなど誰も想像しませんでした。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
