Top Page > interview > CTO列伝 > ポストコロナ=これまでとは別の世界線への向き合い方 GMOペパボ株式会社 取締役CTO・栗林 健太郎さん Vol.3
Yasoob Khalidのブログより。 皆さん、こんにちは! 👋 この土曜日に行われたSpaceXの打ち上げをご覧になった方も多いのではないでしょうか。それは驚くべき、歴史的な出来事でした。何百万人もの人々がYouTubeや他の場所でその様子をライブで見ていました。日を追うごとに、私たちは商業宇宙飛行に近づいており、私は興奮していることに同意しなければなりません。 この打ち上げは、宇宙旅行に対する興奮を煽るだけでなく、これらのロケットに搭載されている技術にも興味が湧いてきました。コンピュータ・サイエンスの観点からいくつか調べてみましたので、その結果を共有したいと思いました。言うまでもなく、これらの情報のほとんどは、私がオンラインで見付けた様々な情報源から集めたものです。間違った情報が含まれないように努めましたが、この情報が100%正確である保証はありません。 チーム 7年前、Space
今回はVBAでプロシージャ呼び出しにかかるオーバーヘッド時間を計測してみた。 プロシージャ呼び出しのオーバーヘッド改善はコンパイラの領分 一般的に、プログラミングではプロシージャの呼び出しにはオーバーヘッドが発生すると信じている方もいるようだけれど、言語によっては必ずしもそうでもない。 (VBAは残念ながらオーバーヘッドが発生するのだけれど。) コンパイラの実装次第では、コンパイル時の最適化で関数(VBAでいうプロシージャ)の呼び出しをインライン展開するものがある。 どういうことかというと、 たとえばこのようなコードがあったとする。 Sub Main() For i = 1 To 100 Call hoge() Next End Sub Sub hoge() Debug.Print "hoge" End Sub これをコンパイル時に以下のように自動的にインライン処理に置き換えてプロシージャ
※2011.3.30追記 11個目の判断項目を追加しました。 また、「昔はね...」の補足説明を各項目に追加しました。 レガシープログラマ = モダンな言語のおいしい機能をうまく使いこなせていないプログラマ おいらは時々社内システムのコードレビューなんかをやっているのですが、「なんかちょっと前時代的だな〜」とか「ちょっと修正したらC言語でもコンパイルできそうだな〜」って思うことがよくあります。 おいらがレビューする言語は主にC#です。C#やJavaのような比較的モダンな言語のおいしい機能をうまく使いこなせていないプログラマを、ここでは「レガシープログラマ」と呼ぶことにします*1。 そこで、おいらがこれまでに見てきたコードの中から「これはレガシープログラマっぽい」と思った典型的な症例を10個11個挙げてみます。 レガシープログラマの判断項目 使われるローカル変数をすべてメソッドの最初に宣言す
ネットや書籍で見かけるマクロでは、変数宣言はプロシージャの先頭にまとめられているものが多い。一般的に変数宣言はプロシージャの先頭にまとめて書くものだと紹介している記事さえある。 それはなぜかというと、みんながそうしてるからだ。 先頭にまとめるとコードが読みやすいとか、変数を一覧管理できて便利とかそういうことではない。書いてる本人も、なぜ先頭にまとめるべきなのか、確たる根拠を持っていないことが多いように思われる。 じゃあなぜ先頭に書くのが一般的になったのかというと、おそらくこれは初期のC言語に由来するものだろう。初期のC言語では、変数宣言は先頭に書かないとコンパイルできなかったようだ。そのようなコードでプログラミングを学んだ人たちが、VBAに同様の習慣を持ち込み、それが標準的な作法として扱われるようになったものと思われる。 現在ではローカル変数は使用する直前で宣言するのが主流 まずこちらの記
hatenaも1年前までは変数をプロシージャの先頭にまとめて記述してました。コードの途中に変数が宣言してあるとコードが読みにくいと思ってました。あるきっかけで直前で宣言する派に転向しました。直前で宣言するようになって1年たった今、直前で宣言したほうかメリットが多いということを確信しました。 なぜプロシージャの先頭で宣言していたのか?hatenaが最初に本格的に取り組んだプログラム言語は、Access VBA です。 Access 1.1 からですので相当昔ですね。その当時、参考にしたヘルプや書籍、WEB上のコードはすべて変数を先頭でまとめて宣言していました。なんの疑問も持たずにそういうものだと思っていました。 その後、Delphi の Object Pascal も使い始めました。これは言語仕様上変数はプロシージャの先頭でしか宣言できないというものでした。 ということで、20年以上変数を先
はじめに ソフトウェア開発のチームの生産性や健全性というものは、内部の体感的として理解できるものの、外部の人間からは見えにくいものです。こういった情報の非対称性は開発チーム外の人々との関係の中での問題の原因になってきました。 また、複数の開発チームやプロダクトを束ねるEM、CTOや、管理職にとってそれぞれの状況を客観的な数字やグラフで可視化することは、全体的な戦略を考える上でも重要な参考情報になります。ですが、アンケートやプロジェクト管理を増やすほど、どんどんと開発メンバーに負担をかけてしまうことになり、計測のし過ぎによる疲れなども誘発してしまいます。 本稿では、gitリポジトリのログ情報から、いくつかのグラフを生成し、チームの状況を可視化するためのツールgilotを作成したので、その目的と意図、そして使い方、注意点を解説します。 アプローチ方法 gilotのアプローチは、git logの
プログラマをする上では10行程度のプログラムを読めるといいとのこと。上記記事のブックマークコメントから飛んで10行ぷよぷよなるものを目にしたので、ソースコードを解読してみました。 解説記事を探したのですが、見当たらなかったので書いてみてます。 10行ぷよぷよについて javascriptで動くぷよぷよです。 開発者のPascalさんのサイトはもう残っていないとのことで、下記からソースを拝借しました。 実行すると、一人用のとことんぷよぷよが遊べます。 そのまま実行しても怒られるので、後述しますがちょっとだけ手を加えてます。 <body onKeyDown=K=event.keyCode-38 id=D><script>for(M=N=[i=113];--i;M[i-1]=i%8< 2|i<8)function Y(){e++;if(e%=10)for(N=[K-2?K-50?h-=M[h+l
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く