タグ

ブックマーク / note.com/ruiu (9)

  • オープンソースビジネスの挑戦と現実|Rui Ueyama

    いい感じのオープンソース・ソフトウェアを書いて、それを元に起業することを考えてみたことがある人は結構いるようだ。実際に僕はここ1年半ほど、自作のオープンソース・ソフトウェアを元にビジネスを立ち上げようと試行錯誤してきた。その経験についてここでシェアしてみようと思う。 あらすじ薄々予期していたことではあったけれど、結論から言うと、そんなにはうまくいかなかった話ということになる。要点をまとめると次の通りだ。 「moldリンカ」というオープンソースのツールを開発して、それを元にビジネスを行おうとしていた そこそこ稼ぐことはできたものの、大きなリターンを得るのは難しかった ほとんどの企業はオープンソースを大々的に活用していても「無料のソフトウェア」にはお金を払うつもりはないし、払いたくても社内制度上できない 大きなリターンを得たいのならば、自作のオープンソース・ソフトウェアを元にサービスを立ち上げ

    オープンソースビジネスの挑戦と現実|Rui Ueyama
    snowcrush
    snowcrush 2023/06/07
  • 「悪い方が良い」原則と僕の体験談|Rui Ueyama

    ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きっぽい悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになっ

    「悪い方が良い」原則と僕の体験談|Rui Ueyama
    snowcrush
    snowcrush 2018/04/06
    プラグマティックでありたい
  • コンパイラに仕込まれた細工とシステムのセキュリティの話|Rui Ueyama

    コンパイラのソースには書いていないのにバイナリだけで代々伝わっていく情報というのがあって、それはコンピュータのセキュリティに大きく関わっている。ここではそれについて書いてみよう。 僕は8ccというCコンパイラをスクラッチから書いたことがあるのだけど、8ccには文字列を読む部分で、"\"の後に"n"がきたら"\n"という文字(改行文字)を読んだことにするという箇所がある。これはよく考えてみれば自己言及的になっていて、ソースコードの中に"\n"のASCIIコードが一体当は何なのかという情報が含まれていない。しかしコンパイラをコンパイルするコンパイラからその情報が受け継がれるので、できたバイナリは改行文字をきちんと出力できる。つまり8ccの改行文字は何度セルフコンパイルしても最初に使ったGCC起源ということになる。 コンパイラは、改行文字の文字コードというレベルではなく、もっと大きな情報をバイ

    コンパイラに仕込まれた細工とシステムのセキュリティの話|Rui Ueyama
    snowcrush
    snowcrush 2017/12/11
    自分でとっている対策としては「信用できるOSSのコンパイラしか使わない」かなぁ。本文で言われているように結局は信頼の問題なのだけれど。
  • エレベータに見るアルゴリズムの性能と公平性のバランス|Rui Ueyama

    現実世界でもコンピュータの中でも、何らかの性能指標だけを追求すると参加者にとって極端に不公平になってしまうことがある。例えばエレベータとHDDは共通点がありそうに思えないが、この2つは性能特性的にとてもよく似ていて、リーズナブルな性能と公平性を両立させるために同じ制御方法が使われている。これについてちょっと説明してみよう。 1基しかない場合のエレベータの動き方は単純だ。一度上に動き出すと、上で待ってる人や降りる人がいる限り上昇し続ける。同じように、一度下に動き出すと、下で待っている人や降りる人がいる限り下降し続ける。これ以外の動き方をするエレベータはまず存在しないので、これが唯一の制御方法のように思えるけど、別にこうしなければいけないというルールはない。 エレベータの平均待ち時間を最適化することを考えてみよう。そうすると、一方向に動き続ける代わりに、エレベータが現在存在する階に一番近い人の

    エレベータに見るアルゴリズムの性能と公平性のバランス|Rui Ueyama
    snowcrush
    snowcrush 2017/11/24
  • オーバーフローが引き起こした面白いバグの話|Rui Ueyama

    一度聞いたら忘れられないような印象深いバグというものがある。僕は数値のオーバーフローと聞くと必ずこの2つのバグを思い出してしまう。どちらも面白いエピソードなのでちょっと紹介してみよう。 一つ目は、初代Civilizationにあったバグである。Civilizationは文明間で戦う戦略シミュレーションゲームで、チンギスハンとかエリザベス女王みたいなプレイヤーを選んで、世界制覇か宇宙開発競争での勝利を目指すというゲームだ。 初代Civilizationにあったバグは、非暴力主義のガンジーが突然核攻撃してくるというものだった。原因は文明が民主主義を採用すると攻撃性が2下がるというロジックだった。初代Civではガンジーの攻撃性は全プレイヤー中で最小の1なのだが、ゲームが進んでインド文明が民主主義を採用すると、攻撃性がマイナス2されてオーバーフローで255になり、ガンジーがゲーム中で突如、極度に攻

    オーバーフローが引き起こした面白いバグの話|Rui Ueyama
    snowcrush
    snowcrush 2017/11/17
    ガンジーの核兵器好きって定番だと思ってたけど初代だとバグだったのか…
  • ソフトウェアの互換性と僕らのUser-Agent文字列問題|Rui Ueyama

    いろいろな環境で動くプログラムでは互換性のためにその場しのぎのことをしないといけないことがよくあるけど、歴史が積み重なってくると、アドホックな技の上にアドホックな技が積み上がる喜劇的な状態になることがある。こういう問題は認識するのは簡単だが直すことは誰にもできない。まさに僕がそのような体験をしたのでちょっと説明したい。 僕は仕事としてオープンソースのlldというリンカを書いている。リンカというのはコンパイラが生成したバイナリファイルをつなぎ合わせて最終的な実行ファイルやDLLを作成するプログラムで、知らない人も多いと思うけど、何をコンパイルしても最後にはリンカが動いている。lldは既存プログラムより何倍も速くてビルドが早くなるというので最近は結構人気が高まっていて、FreeBSDなどのいくつかのOSが全面的にスイッチしようとしたり、あるいは大規模プロジェクトChromeや、どうもFire

    ソフトウェアの互換性と僕らのUser-Agent文字列問題|Rui Ueyama
    snowcrush
    snowcrush 2017/11/15
    アドホックな判定処理が仕様として残ると、後々その処理に合わせて識別子を送らないといけない問題、結構あるよね。ライブラリ依存解決時のバージョン判定とか、よくめんどい思いした。
  • 絵文字がある種のUnicodeバグを世界から一掃しつつある件について|Rui Ueyama

    UnicodeのUTF-16エンコーディングではほとんどの文字(コードポイント)は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語

    絵文字がある種のUnicodeバグを世界から一掃しつつある件について|Rui Ueyama
    snowcrush
    snowcrush 2017/11/13
    UTF-8以外のエンコーディングは早く滅びて欲しい。UTF-8にも問題はあるだろうけど、まずは統一されていることが大事。
  • 「プログラミングの常識」を時々見直す必要性について|Rui Ueyama

    自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindowsの初期の頃に設計されたデータ構造には、メモリをバイト単位ででもいいから節約したいという意図の痕跡がいまでも多く見受けられる。DRAMの次に速い記憶装置はHDDだったので、メモリが足りなくなればHDDにデータを保存せざるを得ないのだが、DRAMとHDDのランダムアクセスの速度差は、机の上のの開いているページを見るのと、そのAmazonで注文して到着するのを待つのと同じくらいのスケールで違うの

    「プログラミングの常識」を時々見直す必要性について|Rui Ueyama
    snowcrush
    snowcrush 2017/11/02
  • ソースコードって実際のところどういうふうに書いていますか?|Rui Ueyama

    私はプログラミングは結構自信があるんですが、他の人の作業をつぶさに観察したことがあるわけでもないので、自分で当たり前だと思っているコーディングの方法が他の人にとってはそうではないこともあると思ってます。上手い人がどういうふうにしてプログラムを書いているのか知りたいんですよね。 逆に私はどういうふうに書いているかちょっとまとめてみました。自分はこうしている、というのがあったらぜひ教えてください。 まず私の場合、ゼロからコードを書くよりも現在のプロジェクトのためのコードを書くことのほうが多いので、コードを書くというのは既存のコードに変更を加えることがほとんどです。既存のコードに手を加えるときは、新機能追加か、リファクタリング(動作は変えずにコードをきれいにすること)のどちらかになるわけですが、まず前者をどうしているかどうかをできるだけ説明してみます。 まず必要なのは考えることです。よく知ってい

    ソースコードって実際のところどういうふうに書いていますか?|Rui Ueyama
    snowcrush
    snowcrush 2016/07/16
    自分のやり方とよく似てるんだけどこまめにコミットするところが出来てないことが多いな。なので無駄になんども書きなおすことが多い。気をつけよう。
  • 1