ソフトウェアのスケーラビリティについてスターバックスが教えてくれること | POSTD
2004年に Gregor Hohphe が「 スターバックスでは2相コミットを使わない（Starbucks Does Not Use Two-Phase Commit） 」という優れた投稿を発表しました。それを読んでいたら、学生時代にスターバックスでアルバイトをした頃がいきなり関わってきました。何年もの間に次第に分かってきたのは、プログラマでさえ有名なコーヒーショップのチェーンから学べることが思った以上にあるということです。 多くの人はスケーラビリティのあるソフトウェアを作ろうしますが、最初に考えていたよりも非常に難しいことがあります。個々のタスクをこなしているうちに「あらゆるものの重要性は等しく、同じリソースを必要とし、決まった順序で同期的に進行する」と考えてしまう罠に陥ってしまうのです。 実際には、少なくともスケーラビリティのあるシステムでは、当てはまりません。もちろんスターバックス
コードにコメントを書かない事を責められた時の言い訳:Geekなぺーじ
プログラミングにおいて、コード中にコメントを残す事は非常に重要です。 たとえ自分で書いたコードであっても、1ヶ月もすれば詳細は忘れてしまい、他人が書いたものと変わらなくなってしまいます。 しかし、その重要性とは裏腹に、コメントが書かれていないコードというのも非常に多く存在します。 私もついついサボってしまう事があります。 今回は、プログラマがコメントを書かない理由や言い訳を考えてみました。 項目には実際に聞いた事がある言い訳と、脳内妄想が混ざっています。 しかし、一応、全部フィクションということにしておいてください。
コメントを書かない理由 | おごちゃんの雑文
コードにコメントを書かない事を責められた時の言い訳 私はコードにコメントを書かない。それは面倒だとか、ここに書いてある事情があるとかではなくて、「信念」として書かない。書くべきではないと思っているからだ。コメントを書いたら負けだとさえ思っている。これはもう20年来そうだ。 ちょっとしたメモのようなコメントは、つい書きたくなる。私は「自分のコードは他人も見る」「過去の自分は他人」と思っているので、その時の助けになるようなコメントはむしろ入れたい欲求にかられる。コメントで意思伝達しておけば楽だと思う。が、「コメントを書いたら負け」だと思っているから書かない。 例外的に書くのは、 ファイルの冒頭に書くGNUなヘッダ ヘッダファイルに書く構造体の宣言 コメントアウト くらいで(これらはむしろ積極的に書く)、その書かないっぷりは、gotoよりも少ないくらいだ。 なんでそこまでコメントを嫌うかと言えば
ソースにコメントを書くのはなぜか - novtan別館
優れた設計、優れたプログラムであればあるほど、コメントは不要である、というのが真理の一つだと思う。もっとも、「優れた」の中にも「複雑なハックを駆使してとにかく高速化」とかそのたぐいの物はあって、そういうものにコメントがないのはパズルや入試問題を解かされているような不毛があるので仕事という面であれば避けたいものではある。 であるならば、コメントを書くのはどういう場合なのか。 至極簡単な理由は、優れたプログラマーなどそんなにいない、というまた別の真理によるものだ。コードにコメントを書かないことを目指すべきであることと、実際にコメントが不要なコードが書けることはイコールではない。業務プログラマーの世界であれば尚更である。そこで目指されているのは完璧なクオリティーのコードを書くことではなく、QCDが計画の範囲内に収まることであるから… ただ、不要なコメントもたくさんある。特に処理そのものの説明をコ
ジェダイ流・Pythonの内包表記 | POSTD
醜いより美しい方がいい。暗示するより明示する方がいい。 Pythonの禅 より 私はよく、ドロイドやジェダイ、惑星、ライトセーバー、スターファイターなどのコレクショングッズを題材にしてプログラムを書きます。Pythonでプログラミングをする際は大抵、これらをリストやセット、辞書として表現するわけです。私は日頃からコレクショングッズをさまざまな形に変身させたいと思っています。そして、その願望を叶えてくれるのが、内包表記という強力な記法です。内包表記は私がさまざまな場面で使っている手法であり、Pythonを使い続けている理由の1つでもあります。では、いくつか例と共に、内包表記がいかに便利かを説明していきましょう。 以下の例に出てくる処理はどれも、種類豊富なPythonの標準ライブラリがあれば実装できます。その中には、より簡潔で効率の良い処理に改善できるものもあるでしょう。とはいえ、私は標準ライ
【プログラミング】退職した先輩が書き残していったコメントがひどすぎる・・・ - 意識低い系ドットコム
こんにちは、意識低い系サラリーマンのKENです。 今回は零細IT企業でシステムエンジニアをしている僕が遭遇した酷いコメントについて。 猫でもわかるC#プログラミング 第3版 (猫でもわかるプログラミング) 作者: 粂井康孝 出版社/メーカー: SBクリエイティブ 発売日: 2016/02/27 メディア: 単行本 この商品を含むブログ (2件) を見る 通常プログラムを組むときは、プログラミング言語を使ってソースコードを書いていきます。でもプログラミング言語だけでひたすら書いていると、第三者が読んだときや後から自分で見返したときにわかりづらいので、「コメント」と呼ばれるメモ書きを付記することがあります。あります、というかほとんどの人はそうします。 例えば、「C#」というプログラミング言語だと、行の先頭に「//」と打つと、その行はプログラムの一部としては解釈されず、単なるメモ書きとコンピュー
プログラムにコメント書かない文化もあるよって話｜NZ MoyaSystem
以下の記事を読んで。 530000micro.hatenablog.com 僕が勤めている会社では、原則、プログラムにコメントを書かないのがルールです。 人生で初めてプログラムに触れてからこのかた、プログラムには必ずコメントを書けと指導されて来ましたし、自分自身も、後輩たちにちゃんとコメント書けよと言い聞かせてきました。そんなわけで、最初に全然コメントのないソースコードの山を見たときは、正直「ゲッ、なんじゃこりゃ……」と面食らったのは確かです。 ところが、「なぜうちのプログラムにはコメントがないのか？」と同僚に尋ねてみると、実に納得の行く回答が返ってきたのでした。 なぜコメントが必要なプログラムを書くのか？ 同僚いわく、「コメントが無くても読めるようなプログラムを書け」という思想が根底にあるのだそう。 適切に関数や変数が命名され、スコープがきちんと管理され、ロジックの流れが整理されているコ
ソシャゲエンジニアの自分がコードレビュー時に重視する箇所33選 【随時追加】 - Qiita
コードレビューで土日に安寧を ソーシャルゲームは、ユーザアクセス集中と、それに伴うユーザデータ増加によって劇的に負荷が上がり、（主に土日に）サービスに影響を与えがちです。 問題があるコードは、たとえ負荷テストを行っても、作成したシナリオによっては見つけられない可能性もあります。 そういった見えない不安を払拭するという意味でも、コードレビューは重要だと思っています。 【ステキポイント】 ・ ソースを見ることにより、時限爆弾が土日に爆発するのを解除 ・ スキル共有によってメンバーがレベルアップすることにより、土日に爆発する時限爆弾の設置確率低下 まぁまとめると これに尽きます（4歳の息子談） 今は、gitのプルリクエストという強力なレビューツールもあり、敷居がかなり低くなったのでオススメです！ チェックするポイントは5つ コードレビューを行うにあたり、「どんなところをチェックすればいいのか分か
目が見えなくてもプログラミングできるよ - Qiita
はじめに こんにちは！@moutendです。私は視覚障害があるので、普段は画面を見ずにMacのVoiceOverというスクリーンリーダーの音声のフィードバックを頼りにプログラミングをしています。ところで最近@ssotoyaさんの記事にて音声を頼りにプログラミングする様子が公開されました。スクリーンリーダーの音声を聞いたことがありますか？ - ラック公式ブログ - 株式会社ラック@ssotoyaさんは全盲のため全く目が見えないのですが、超高速でコーディングをされています。控えめに言って最高にロックです。私も負けていられません。ということで、この記事に触発されて、私も画面を全く見ずに音声のフィードバックのみを頼りにプログラミングしている様子をキャプチャしましたので公開してみます。具体的には、QuickTimeのスクリーンキャプチャ機能を使って画面を撮影しつつ、音声はsoundflowerという
アジャイルソフトウェア開発宣言
私たちはソフトウェア開発を実践あるいは実践の手助けをする ことによって、よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスとツールよりも個人と対話に。 包括的なドキュメントよりも動くソフトウェアに。 契約交渉よりも顧客との協調に。 計画に従うことよりも変化への対応に。 すなわち、左側に書かれたことがらに価値をおきながらも、 私たちは右側に書かれたことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
日本でアジャイル / DevOps 導入が進まないのは「文化」を変えないから - メソッド屋のブログ
私が初めてeXtreme Programming に出会ったのは確か2000年だと思う。実際に初めてのプロジェクトを実施したのが2001年。それからすでに15年が経過していることになる。そんな長い間アジャイル、そして DevOps の日本での導入に関わってきた。日本のアジャイル導入に関しては全て成功とは言わないが、かなり成果は上げてきたとは思う。だけと、今日は自分の導入ポリシーの誤りに気付いて、新たなステージにいける気がしたので、そのことを共有してみたい。 2002年 尊敬するアリスターコバーンと、XP JUG関西のメンバーと清水寺で。私が写真撮ってたのかなw Alistair.Cockburn.us | Alistair's first trip to Japan sept 2002 日本はアジャイルの導入がこれからという噂を聞いたけど本当？ これは、私がマイクロソフトの面接の時に、当時
情報科学科の先輩に聞く！｜東京大学理学部 情報科学科／東京大学大学院情報理工学系研究科 コンピュータ科学専攻
夢と笑顔をおいかけて任天堂株式会社｜清木昌さん （情報科学科24期） インタビュー年月日 平成20年 3月 18日 清木昌 情報科学科の24期生。所属は任天堂株式会社 企画開発本部 環境制作部 開発環境制作第1グループ。 任天堂株式会社は、言わずと知れた日本を代表する家庭用ビデオゲームハード・ソフト製造販売会社。最近ではニンテンドーDS、Wiiなどの大ヒットが話題になっている。同社環境制作部開発環境制作第1グループではゲーム開発者に必要な技術や情報を集め、その導入やライブラリ構築などを行うことでゲーム開発者が開発しやすいような環境を作っている。 島村・寺島 情報科学科3年生(当時) 情報科学科3年生(当時)の島村と寺島の2名。 島村は中学高校にてパソコン部に所属していた頃からゲーム制作を体験、2005年には任天堂ゲームセミナーに参加した経験もある。コンピュータと人をつなぎユーザに笑顔をもた
なぜVBはC#と比べて駄目なのか - 負け犬プログラマーの歩み
来年3月で1.5年ほど働いた現場を去る。非常に働きやすい職場だったし、周囲の人間もみんな良い人ばかりだった。残業をそれなりにして520万程度だが収入面も「極めて安い」という訳でもなかった(2015/6追記。やっぱ安い)。だが、ここでの経歴や実績は、「ASP.NET」とだけ書き、フロントサイド(レスポンシブデザイン、レガシーブラウザ、SNS連携)やPL/SQLのバッチ作成などの成果のみを殊更強調し、サーバー側の言語についてはあまり触れないようにしたい。何故かというとVBだから。 「VB.NETはC#の方言」という見方も強くなっている。歴史的に見ればむしろDelphiから産まれて、JavaとC++を反面教師としつつ上面を拝借した2002年に1.0が登場のC#よりも、BASICから連なるVBの方が全然古参だ。求人数的にもVBの方が多いように見える。加えて、言語仕様的にもC#で出来る事は基本的にV
Template Haskell入門 - think and error
Template Haskell(以下TH)超入門です。 まあ入門するのは僕ですが。 Haskellの易しいエントリがあまり見あたらないため、僕が書いていくことにしようとか考えたり。 続き よかったらこちらもどうぞ。 続・Template Haskell入門 -- QuasiQuotes編 - think and error 前提 GHC7.0.2で。 GHC7.0.1からQuasiQuotesの記法が一部変更したようです。 ..と下書きを書いて既に数ヶ月が経とうとしています。 実はこの記事はHIMA' #6に参加したことをきっかけとして書いています。 partake.in 7/24(Sun)にはスタートHaskellが開かれます！ http://atnd.org/events/17468 ....それも終わって既に２ヶ月経ってますね。やる気ないですね僕。 しかしHaskellは熱いですね
＼バグだー！／ システムに巣食うバグさんからみた快適さ、循環的複雑度（ Cyclomatic Complexity ） とは？ ＼バグだー！／ - Tbpgr Blog
概要 循環的複雑度（ Cyclomatic Complexity ） と バグの混入率 について 経緯 現在、私の所属する組織ではシステム全体の 保守性に関して課題を抱えています 。 今後、改善を行う際の 1 つの指標として循環的複雑度を測定しようと考えました。 一つのきっかけとしては、下記の記事です。 tchikuba's blog - ドワンゴ吉村総一郎氏「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」@デブサミ2014 2日目 ドワンゴ の ニコニコ生放送のシステムが、 PHP の 300 万行のコードベース で、 循環的複雑度 600 超 のメソッドが複数ある状態だったそうです。 【19-A-1】名誉職としてのCTOのあり方 from Developers Summit 循環的複雑度 600 超は「 人類の英知を結集しても不具合
C++ Language
C++ Language Introduction Compilers Basics of C++ Structure of a program Variables and types Constants Operators Basic Input/Output Program structure Statements and flow control Functions Overloads and templates Name visibility Compound data types Arrays Character sequences Pointers Dynamic memory Data structures Other data types Classes Classes (I) Classes (II) Special members Friendship and inhe
レガシーコード改善勉強会 開催レポート
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog ヤフー株式会社の有地です。 9/27（土）の昼から6時間にもわたり、さまざまな視点から「レガシーコード」について知識を深めるための勉強会を開催いたしました。 「そもそも正しい仕様を知っている人がいない」 「システムのブラックボックス化が留まるところを知らない」 こんな不条理なレガシーコード（テストコードが無いコード）と日々戦うエンジニアも多いことと思います。 今あるレガシーコードをどうやって保守・改善していけばよいのかという課題に本気で取り組んでいる、または取り組みたいと考えている大勢の方々に参加していただきました。 ＜開催趣旨・目的＞ テストコードが無いプロダクションコードをレガシーコードと定義し、テストコードによって保護され、
レガシーコード改善のススメ
ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発慎一 古賀
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Swift : クラス継承とプロトコル拡張を比べてみる #yidev
The Deadlock Empire
