サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
Google I/O
isoparametric.hatenablog.com
かつて、ゲームプログラミングはアセンブリが主流で、8bitのCPUは掛け算や割り算すらないものでした。割り算がないCPUっていつの時代だよ、っていう人たちもおりますが、ゲームボーイアドバンスに搭載されているARM7TDMIは除算の命令を持っていません。（故に除算を書くと死ぬほど遅いので、乗算で代用したりする） また、浮動小数に対する演算ユニットを持っていないハードウェアもあります。ニンテンドーDSに搭載されているARM946E-Sですら、浮動小数演算ユニットはありません。（CPUの機能としてはオプションで存在する）そのために固定小数点といった技術もあるわけですが、古くさい話です。 これらはCとC++の機能を駆使していかにパフォーマンスを出すかを余儀なくされた時代です。 さておき、最近はスマートフォンでのゲーム開発も進化しており、C++がiPhoneとAndroidの両方で動くということもあ
最近こんなやりとりがあった。 「Cって標準のコンテナ（双方向リストや可変長配列など）がなくて不便。 Cのプロジェクトってコンテナ自体ないこともあるし、コンテナがないとプログラムって書きにくいよね。 その点C++はSTLが(ry」 ... 「コンテナ？ STL“も”いいけど、自分で書きたい」 正直、自分は「え？ 何を言っているんだ？」と思った。 STL“も”いいけど、“自分で書きたい”だって？ その人はプログラマとしては十年選手だが、C++に関して、特にテンプレートに関しては稚児に等しいレベル。 で、どうして「自分で書きたい」ということになるんだろう？ それを使わされる人の苦労はどうなる？ それともプロジェクトに同一の事をするための複数のコンテナが存在するのか？ 俺俺コンテナを書きたい理由はなんだ？ 要するにここにおいて「自分で書きたい」はSTLがよく解らないので、 機能や動きを隅々まで把握
こちらはEngineering Manager Advent Calendar 2023 12日目の記事です。 こんにちは、Isoparametric（Yuki Tamura）といいます。 今回はEMはCTOやVPoEの下位互換ではないということについて書きます。 私は今estieというスタートアップでEMをしております。 前職では不動産テックのCTOをしていて、その前はスマートニュースという会社でEMをしてました。 その前は、ディライトワークス、gumiという会社でCTOだったりしたこともあります。 では、CTO/VPoEとEMの互換性/再現性についてなのですが、 皆さんはEM(Engineering Manager)というとどんなイメージを持つでしょうか？ 「マネジメントのキャリアパス」「CTOやVPoEの下で働くマネージャー」といった感じでしょうか？ 「EMのキャリアパスはEMのEM
きっかけ。 元ネタ。 俺はVSSを使用しようというプログラマを信用しない。（と宣言しておく） 割と適当訳なのでご了承ください。 時々現れる、どのバージョン管理ツールをつかうのかという宗教的議論の中で、 私はマイクロソフトのVisualSourceSafeが一貫して叩かれている事に気付きました。 私はこれほどまでに憎悪を集めるような別のソフトウェアプロダクトを考えることができません。 私のプログラミングキャリアの日々では幸運なことに、svnを使う場所で働いていおり、さらに最近ではgitだったので、私はVSSを一度も経験したことがないということです。 VSSは本当に皆が主張するくらいに悪いものですか？ はい、そのとおりです！！ 私はgit、svn、cvs、tfs、及びvssを使いましたが、VSSは最も悪かったです。 それには、みんなで作業を分離するという概念が全くありません。 ファイルを操作す
とりま、 アップロードしました。 スタッフの皆さん、参加者の皆さんお疲れ様でした。 アキラさんには直前まで資料作っていてご心配をおかけいたしました。orz... Boost study#4View more presentations from Isoparametric !.
Voluntasに、 給与全部使うを読んで @isoparametric しか思いつかなかった。— voluntas#1345 (@voluntas) 2014, 7月 6 こんなことを言われつつ、 http://mizchi.hatenablog.com/entry/2014/07/06/163724 が面白かったので書きます。 常飲用炭酸飲料:月2000円〜 炭酸水ですが、ペリエ派。 ビンの330mlくらいが持てあまさずに使えてよいです。 Perrier(ペリエ) 330ml×24本 [並行輸入品] 出版社/メーカー: 春日商会 メディア: 食品&飲料 購入: 12人 クリック: 58回 この商品を含むブログ (13件) を見る 330の24本入りなので1ヶ月もちます。 キーボード: 1万~3万〜 キーボードはゲーム会社に入ってから、 会社に落ちてたXBox開発用のMicrosoftの
C++AdventCalendarの記事です。 さて、 生配列使ってますか？ tr1::array（boost::array） 使ってますか？ 生配列使っていると答えた貴方、 →まず死ね。 はい、arrayが常識ですよね。 さて、とはいえ、 「テンプレートを使うと遅いしコードがでかいし」 「生配列が一番速いしコードが小さいし」 「なのでテンプレート禁止」 なんて話を聞くこともあるかと思いますが、 こういう事をいう人は大抵「テンプレートを書いたことがない」のに言ってます。 なぜか？ こういう人が本当に心配しているのは「テンプレートが肥大化すること」じゃないのです。 「テンプレートが書けないし読めないのを認めたくないからです」 多くはCの老害だからですが、そういう人は放っておいてC++な人はきちんとテンプレートを使いましょう。 だって多くのテンプレートのコードは大きくもなければ非効率でもないか
最近「ｵﾜﾀ＼(^o^)／」で有名なDjangoしか触ってないダメ人間です。 こんにちは。 Djangoとかどうでもいいがな、 Webフレームワークとかめんどくさいがな、 という最近なのでDつながりでDecoratorの話をします。 ナウでヤングなPythonistaのホットな話題はGCの参照カウンタ、 ではなくてFlaskとかかもしれないですが、 @app.route("/") def hello(): return "Hello World!" こいつも多分に漏れずDecoratorを使います。 Djangoでも、 @require_GET とか @require_POST とか使ったり見たことがあるんじゃないかと思います。 で、意外と魔法っぽいデコレータですが、 これっていったいどうなってんの？ って事を知らない人が割といたりします。 「とりあえず指定しろって言われたから指定してます
最近開発をしてきて開発者に重要だと思うのは、 ・問題を発見する力 ・問題を解決する力 の二つだと思っている。 実際にコードが綺麗とか、技術が卓越している、というのは個人の手腕であり、 持ちうるスキルではあるのだけれど、 それは「問題を解決する際に使われる力」だ。 そして、これには「コミュニケーション力」や「交渉力」、 「論理的思考」や、「選択肢の中から成否を見据える力」も含まれている。 そして、これを行うためには「問題を発見する力」が欠かせない。 「何が問題なのか？」を考えずにこれらの力をふるうことはできない。 いかな高い技術力があっても、それを使う場所や使うべき場面が解らなければ何の意味もない。 要するに重要なのは「問題を発見し、解決する力」だ。 これが出来れば職場も個人の問題も、何でも解決できる。 そして、組織が強いのは沢山の眼があること、沢山の思考があること。 要するに重要な力は２つ
社内でデザパタが盛り上がっていたので、社内勉強会でLTしました。 その資料です！ 基本的に自分はデザインパターンは「言語に依存しない設計に名前をつけたもの」だと定義しています。 なので、よくある「デザインパターンってJavaじゃないと役に立たないよね」なんていう意見には反対です。 勿論、言語によっては適応する意味の無いパターン、意味の薄いパターンもありますが、 GoFのパターンだけがすべてではないですし、 "設計に名前をつけて共有する"というスタンスこそが最高のものだと思っています。 （酒井姐さんは社内のエンジニアです） デザインパターンとは何か？ View more presentations from Isoparametric ! 最後でも紹介していますが、この本が超オススメです！ デザインパターンとともに学ぶオブジェクト指向のこころ (Software patterns serie
以前に森博嗣の小説で見かけたこと。 欧米の集団の繋がりはjoinだが、日本の集団は「俺も混ぜてくれ」という言葉通り、mixなのだと言うこと。 これはとても印象に残っている。（出典となる小説は失念） 確かに欧米はjoinによって繋がっていくリンクリストみたいな感じがして、そのjoinの連鎖が数多く発生していて、最終的には複雑に絡み合ったチェーンみたいな気がしている。 これは、直接その集団に触れた訳ではないので思いこみも入っているだろうけれど、Webサイトにおける繋がりも欧米のコミュニティも、それらの人々が書く書籍にもそうした色が濃く現れているように感じる。チェーンの中をけたたましくエネルギが行き交う感じがして仕方がない。 そして、やっぱり日本はmixであって集団に溶けこむ事で個を失っていくというか、mixiのように繋がっていても集団の中で個は打ち消されていくような感じをうける。 自分が自分で
土曜日のPython Hack-a-thon 2010.07で「本当にあった怖い話」をしてきました。 会場を提供してくださったオラクルさん、 そして、スタッフの皆さん、色々準備ありがとうございました。 また、参加者の皆さんお疲れ様でした！ （レポートは別途書きます） で、俺のプレゼンは完全にネタなので、ご了承ください。（特にC++erの皆さん） 前半は前振りなので、あまり気にしないでください。 プレゼン中で某C++な人達の写真や、Twitter発言が引用してありますが、 もし問題があればお知らせください。 「ソースを読もう」とか意味ないですので飛ばすの推奨。 また、なんか話したいなあ。 C++の話（本当にあった怖い話）View more presentations from Isoparametric . あと、プレゼン中で「C++の設計と進化」を勧めていますが、 C++のことわからないと
きむら(K)さん経由！ What makes a bad programmer? I work with about 30 developers and everyone has strengths and weaknesses, but I can't say that any of them fall into that "bad" programmer category. So what really makes a bad programmer? 404 Not Found 何が悪いプログラマを作るんだろうね、というお話。 皆に長所と短所があって、そのどれが悪いプログラマをカテゴライズするためのもの、 ということができないですよ、と。 で、じゃ、何が悪いプログラマを作るんでしょうね？ それによる幾つかの定義。 プログラミングに対して情熱的ではない 詳細に注意を向けない ユーザーが何
ある程度経験を積んだC++プログラマは絶対にvirtualデストラクタのないクラスを継承しない C++では基底クラスにvirtualデストラクタを書こう - ＊「ふっかつのじゅもんがちがいます。」withぬこ はよくある間違い。あるいはC++初心者の勘違い。 継承する可能性のあるクラスにはすべてvirtualデストラクタを作る C++では基底クラスにvirtualデストラクタを書こう - ＊「ふっかつのじゅもんがちがいます。」withぬこ ということが否定されていることは言われるようにEffective C++を読んでいればわかること。 C++では、コピー不可にするために以下のようなクラスを書いたりするが、 （コピーコンストラクタとコピー代入演算子を無効にする） class Uncopyable { protected: Uncopyable() {} ~ Uncopyable() {}
元ネタはベルセルクの「お前は剣術の達人になってから戦場に赴くのか？」だったような気がしますが定かではありません。 多分、ガッツ（熟達の剣士）が未熟な剣を振るうイシドロ（未熟な剣士）に言った言葉。 要するに戦場に赴くのなら「お前はいまお前にできることをしろ」って事ですな。 似たような事を思う事が僕にもあって、 「本を読み鍛錬を積み重ねその知識を把握してからプログラムを書くべきか」 「ただ目の前にある実装を片付けるべく邁進すべきか」 と考えたりします。 仕事のコードでなくても、 休日でも時間があるときはコードを書こうか、 本を読もうか迷ったりするわけです。 要するに常に 適切な知識を身につけたり適切なコードを書けるようになってからコードを書くべきかや？ という葛藤があります。 反面、コードを書かずに成果を出さなければ意味はないよな、という思いもあります。 これは剣術でもそうですが、 ただただ何
結論 マネジメントの本質は「利他」だと思っている。そして「利他＝自己犠牲」ではない。 テイクを求めず、ギブをする。自分のアウトプットではなく、チームのアウトプットにこだわる。自分が評価されなくても、チームが成長し、成果を出し、評価されることを誇りに思う。 そして、こういうマネジメントの価値をちゃんと理解してくれる人と働けると、マネージャーは幸せになれる。 なぜ「利他」なのか 今年もマネジメントについて話す機会が色々あった。社内のインタビューなどでもだ。そのとき改めて言語化したのだけど、私がマネジメントで大切にしているのは「自分の都合を優先しない」ことだ。 組織を見たときに、利己的に動いている人間は時として組織の邪魔になる。自分が利己的に動くことによって、組織のキャップになったり、ブロッカーになってしまうことは容易に想像がつく。結局、組織のために何かするってことを第一に置かない限り、マネジメ
ということで、最近はC++触ったりObjective-C触ったりJava触ったり、Lua触ったりしているわけですが、cocos2d-xに関してgumi Studyで話しました。とはいっても、中身は殆どcocos2d-xに関係ありません。 割と当たり前のことしか書いてないのですが、コンシューマゲームでも踏んだ「基本的な罠」について書いてあります。 cocos2d-xを触っていると、かなりの人たちがC++を知らずにC++を書いているという現実に出くわします。そういうとき「動いているから」で突き進むのではなく、１度止まって、自分がそれを理解しているのかを考えて見てはどうでしょうか。 ネイティブ開発アンチパターン from Isoparametric !
ということで、とりあえずスライド紹介。 PythonなのにLua！ PythonなのにLua！ いや、本当になぜPythonでLuaなのか訳がわかりませんが、 #1, #2とデスマってて約束が果たせなかったのでやっと果たして参りました。 基本的な機能に関しては網羅しているような感じではありますが、 実際には駆け足で抜けもあるので何かあれば質問してもらえれば解る範囲で答えられるかもしれません。 というか機能網羅する必要ないよな、という気もしつつ、速度とかサイズだけ語ってもLuaはLuaたりえないので なるべくLuaっぽいところを話したつもりでする。 最速の言語Lua ~Python Hack-a-thon #3~View more documents from Isoparametric. 最速の言語と銘打ってますが、実際にはPawnというもっとミニマムで高速な言語があったりします。 が、実
このように数多くのプログラマが「車輪の再発明」の罠に悩まされているのですが，車輪の再発明（より正確に言うと，車輪の再実装）にはそれなりに意義もあります． 車輪の再実装 - Life like a clown id:tt_clownさんの反応に対してですが、 まず、自分も「車輪の再発明」ではなく「車輪の再実装」はすべきと考えます。 既にある機能を実装する事を「車輪の再発明」といって嫌う話もありますが、 実際にそれは「既にあるものを発明（新たに考える）する必要はない」という意味で 「既にあるものを実装する必要がないわけではない」と考えています。 自分は「車輪の再発明」と「車輪の再実装」は完全に異なると考えていて、 「車輪の再発明」で無駄に頭を悩ませる必要はないですが、 寧ろ「車輪の再実装」は非常に重要だと考えています。 ただ、「車輪の再実装」は習作でしかないことも多く、 習作は習作だということ
プロジェクトが火の車なのに自分だけ楽だったことはないか？ 自分は頑張ったと思っているのに周りの評価が低かったり、目線が冷たかったりすることはないか？ プロジェクトに属しているのに誰も相談にこなかったりしないか？ polestarさんの過去のエントリを読んでいて思ったこと。 妙に共感したので。 それはそれとして、今ちょーどやってる仕事のほうで、自分の担当だけこなしたら周囲の火事には目もくれないやつがいて、ちょっと内心カチンと来てたりはするんで、この「後輩」がいつもどうしてるんだろう、とも見てしまった。 で、こっから先は、その人に対してすごーく言いたいこと。 なぜみんな火の車なのに、キミに仕事を振ろうとしないかわかるかな？ 仕事を振ったほうがより面倒なことになると思っているからなんだよ？ キミは確かに助っ人として急に呼ばれてきて、自分がやりたいと言った仕事と違うことを振られて、すごく不満なのか
とか書くと思いっきり愚痴にしかならないんだが、 馬鹿はプログラマになるな。 まあ、馬鹿っていうのが指すのは特定個人名な訳だが、 この人ちょっとおかしいなーと思ったら、 もうどうしようもないレベルであることが判明した。 プログラム馬鹿は必要でも、 只の馬鹿はソフトウェア開発に必要ない。 馬鹿の特徴（一部 プログラムは期間内に動く物ができれば良いと思っている 「動けば良い」とか馬鹿か 調整すべきパラメータもソース内に直書きすれば良いと思っている お前はいちいちビルドしてリンクする気か…… とりあえず自分で仕事を抱えて手が足りなくなったら誰かにふれば良いと思っている 手垢をつけるまえに最初から振れ 他人に自分のプログラムをどうこういわれるのは癪に障る プログラムの指摘に生意気とか言われても…… 他人に自分のコードに手を入れられたくない お前のソースが腐ってるから手をいれてやるって言ってるんだよ！
とりあえず、30歳まではEmacsを使った事がなかったよ、 という俺ですが最近はすっかりEmacsです。 いままで使ってきたエディタは、 WindowsではPeggy ProとEmEditor、OSXならTextMateでした。 じゃ、なんでEmacsにしたかというと、 偏に、 「WindowsでもOSXでも同じエディタを使いたいじゃん？」 ってことでした。 この辺は、Emacsはじめました - 神様なんて信じない僕らのためにでも書いたのですが、 あとは、ぶっちゃけ「Emacsくらい使えないとかっこうわるいなあ」ということ。 ほら、周囲がviとかemacsとか使っていると肩身の狭い思いをするわけです。 viいいよー、emacsいいよー、という話を聞くに、使わないとダメじゃない？ って感じになったわけで。 そんなにいいなら使ってみよう、って思いました。 まぁ、これが真の動機かも。 で、いまや
といっても、二ヶ月前くらいからですががが。 元々、WindowsとMacを両方使うので両環境でまともに使えるエディタが欲しいと考えていて、よし折角なのでEmacsを使おうと思ったのが始まりです。 xyzzyもみましたが、どうもショートカットが微妙に違うので挫折。 普通にGNU Emacsを落としてつかってます。（MacではCarbon Emacs） まず、 鬼軍曹.el をいれました。 これは強制的にEmacsのキーバインドを身につかせるための拡張で、 例えばカーソルキーをうつと鬼軍曹に怒られるという素晴らしい拡張です！ TABやBSも駄目です！ 次に、 ElScreen.el をいれました。 言わずと知れたタブ機能です。 何個もファイルを開く自分には必須でした。 最近、 jaspace.el をいれました。 全角空白とかタブ文字とか、見えるようになります。 ヒアドキュメントの後ろに半角空
（まだ、書きかけです）あれっと思ったらご意見頂けますと大変嬉しく思います。 きっかけ。 元記事。 Why nobody talks about Lua 暫定訳。（まだ見直ししてないので注意） 誰もLuaに関して話さない理由 私はLuaについて長い間知っていますし、私はあなたが多くのWebにいる抜け目がない人々のようにLuaについての話を聞いたのを確信しています。 しかし、私だけでしょうか。Luaはメディアでの話題を生み出さないように思われませんか？ メジャな技術系ニュースの収集者たち（少なくとも私がいつもチェックしているもの）は、いつも、JavaScriptや、Ruby、Pythonなどを扱います。 しかし、あなたがLuaが実際に使われ、生み出したものをみるとき 全てのブログとその繋がり（ブロゴスフィア）で扱われるLuaの話題は不気味なほど沈黙しており、不釣り合いであるように見えるでしょう
まぁ、一言で言うと（望まずにポーズだけでする）残業って愚行ですよね、と。 まだ読んでいる途中だけれど「デッドライン」からの引用。 プレッシャーをかけても思考は速くならない。 残業時間を増やすのは、生産性を落とす方法である。 一時的なプレッシャーや残業は、人々の焦点を定め、その仕事が重要であるという認識を高めるには有効な方法かもしれないが、プレッシャーをかけすぎると、かならず失敗する。 管理者がプレッシャーを使うことが多いのは、ほかになにをすればいいのかわからないから、または、ほかの方法の難しさにひるんでいるからである。 恐るべき推測：プレッシャーが残業を使うほんとうの理由は、プロジェクトが失敗したときにごまかすためかもしれない。 ただ残業というものに対して、 「全否定」というわけではなくて必要な時、必要なだけやらなければならないことはある。 それは、要するにどうしてもそうしなければならない
何となく思ったこと。 なんとか、の話になったとき、 Effective なんとかを読まずになんとかは語れないとか、 やったとは言えないとか、まずは読むべき、とか色々と耳にしたりする。 かくいう自分も C++の本で何が良いと言ったら、 プログラムの経験がある人なら、Effective C++は勧める本の中に入ると思う。 ただ、この本を読んだからといって、 見違えるようにC++が書けるようになるわけでもない。 かといって、読まなくても良いかというとそうでもない。 そんなこといったら 「Exceptional C++」も読むべきだし、 「Exceptional C++ Style」だって読んで欲しいですよ、ですし、 「C++ Coding Standards」だって、ねえ。スタイルがさー。 いやいや、「Effective STL」は外せないでしょう、STL使わないってありえないし、 とか、ならな
前置き。dlmallocについて書くぞ！と言っておいて書いてなかったので。orz...すみません。 あろけーたをじぶんでかいてはいけません！！ なぜ、って大抵糞だからです。 例えば、こんな管理構造を持ったアロケータをよく見るんですが、 typedef struct _Allocator { unsigned char* pPool; // メモリプール int nPoolSize; // メモリプールのサイズ struct _SMemChain* pHead; // 番兵 struct _SMemChain* pTail; // 番兵 struct _SMemChain* pLast; // 最後に追加されたチェインタグ } Allocator; typedef struct _SMemChain { struct _SMemChain* pPrev; // 前のチェインタグ struct
にいってきました。 今回は良くも悪くも、 「C/C++へのLua組み込みの実践」は Luaっていうのはどんなものなんだろう？ と思った人向けになっていたと思います。 本を既に読んだ人にとっては目新しい事はなかったですが、 これを機に採用事例が増えれば良いなと思いました。 会場にはプログラマが沢山でしたが、説得材料として動的リロードのところはいけると思います。 まぁ、動的リロードはLuaじゃなくても（言語ではなくてデータでも）できますけどね。^-^; 動的言語で型チェックが実行時であることの不安感をなくすには動的リロードによる即時チェックだと考えられるので。 個人的には 「コンシューマにLuaを適応したらこんな問題が起きた」 「ただし、こういうメリットもあり良かった」 「メモリやパフォーマンスチューニングはこうした」 なんてことが聴きたいですね。 実体験に基づいてくると絶対面白いと思うので！
なんだってー！！！！(；ﾟдﾟ） (ﾟдﾟ；（ﾟдﾟ；） いや、過言かもしれませんが、C++の存在がdlmallocを書く切っ掛けになったのは確かです。 dlmallocは現在はLinuxなどのデフォルトのmalloc実装ではありませんが、 dlmallocは本当に優れたアルゴリズムを持っています。 まずは「はじめに」の日本語訳を引用として載せておきます。（この記事自体は非常に古いもので現在のmallocの実装の詳細を反映してはいませんが、今なお使うに値するアロケータだと俺は信じますし、使っています） http://g.oswego.edu/dl/html/malloc.html はじめに メモリアロケータはソフトウェア工学のインフラにおける興味深いケーススタディを形成します。 私はそれを1987年に書き始めて以来、維持と発展に努めてきました。（これは多くのボランティアの方々の助けがあって
次のページ
このページを最初にブックマークしてみませんか？
『神様なんて信じない僕らのために』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
