循環的複雑度(サイクロマティック複雑度、Cyclomatic Complexity)とは、ソフトウェア品質を測定するソフトウェアコードメトリクスのひとつで、プログラムの複雑度を ...
循環的複雑度(サイクロマティック複雑度、Cyclomatic Complexity)とは、ソフトウェア品質を測定するソフトウェアコードメトリクスのひとつで、プログラムの複雑度を ...
伊藤直也さんが「些末なコードレビュー」というエントリを書いて話題になっている。このエントリで伊藤さんはコードレビューの話と、はてなのJavaScriptの話と2つの話題に触れている。前者のコードレビューについてはアプレッソでは8年ほど前から「コードレビューを通っていないコードはコミット不可」というルールですべてのソースコードに対してコードレビューを必須にしてきた関係で私も思うところがあるので、エントリを書いてみようと思う。 伊藤さんが例示しているように、インデントやreturnの省略などの話は好みの問題であり、議論してもソフトウェアの改善につながらない。なのでコードレビューでこうした宗教論争が起こるようなら、コーディング規約を見直すべきだ。「無駄に悩んだり議論したりすることを減らす」ことはコーディング規約の主たる効果のひとつだと言える。 コードレビューに慣れないチームが、何の考えもナシにコ
(Monitoring Casual Talk in Kyotoで発表してきたので、ブログエントリにまとめ直しました) 2013年はインフラ周りの技術的な進化が大きく、いくつかのエポックメイキングな概念と実装が産まれました。個人的には特に以下の2つが大きいと思っています。 AWSの本格普及期 DockerとImmutable Infrastructure これらを踏まえて、2014年のウェブシステムの進化の方向性を考えてみます。また、それによるモニタリングへの影響もあわせて考えます。だいぶ長くなってしまったので、急ぐ人は最後に結論をまとめましたので、そちらからどうぞ! 2013年という時代背景 AWSが本格普及期を迎えているのは、言わずもがなのことで、Re:Inventでの246件という膨大のセッション数などにその勢いが表われています。 また、DockerはLXC (LinuX Conta
システムの技術的負債にどう挑むか?~『レガシーコード改善ガイド』著者マイケル・フェザーズが語る課題と解決策~
NHN Japan スマートフォンゲーム制作室 室長の馬場一明氏。「自分はいつも焼肉屋に行くと食べ過ぎてしまう。自分の食べる量も分からないのに、他人の作業量が分かるわけがないので、作業量の見積もりは不要」とのユーモアあふれる例えに会場は笑いにつつまれるシーンも 12月14日、スマホ関連総合カンファレンス「スマートフォン&タブレット2011 冬」(ベルサール八重洲)の「ゲーム開発」セッションでは、NHN Japan スマートフォンゲーム制作室 室長の馬場一明氏が登壇した。『ダーツ』や『フォトジグソー』など、直感的に遊べるアプリ「TEIBAN GAME」をいかにクオリティーを維持しながら、短期間で多数開発し、ヒットに結び付けたか。その舞台裏と独自の組織論を披露した。 これまでPCオンラインゲームを手がけてきた馬場氏が、スマホゲームアプリの開発を命じられたのは、東日本大震災直後の今年3月。出され
gitによるバージョン管理 バージョン管理システムはつかってますか? 僕は前に自分の作成したコードを元に、後輩にプログラムを作らせようとしてまずは僕のコードをコピペしろと指示したところ、コピペしかしてない(と言い張る)割にはコピペしたコードは動かず、さらに何故かコピペ元の僕のコードが滅茶苦茶に荒らされて当然のごとく動かなくなるという、なんかもう幽霊の存在を認めない限り説明がつかないような怪奇現象に遭遇したことがあります。しかもそのときはcpコマンドによるバックアップに頼っていて運悪くバックアップを忘れたために僕の貴重な1日が消え去ってしまった訳でして、それから僕はバージョン管理システムに頼ることを固く心に決めました。また僕はその目を覆いたくなるような残虐な事件以来、建設業界に見習って、IT業界でもプロジェクトキックオフ時にお祓いはすべきだと訴え続けています。 まぁそれはいいとして、いやまだ
このエントリーはHatena::Staff Advent Calendar 2011のために書かれたものです はじめまして。最近は映画けいおんが生き甲斐のuedayです。 11月8日にクローズドベータリリースした「はてなブログ」のデザイン全般を担当しました。裏側というほどの話ができるか微妙ですが書いてみます。 開発チーム 開発チームは、エンジニアid:cho45/デザイナーid:ueday/ディレクションid:onishiです。デザインはクオリティチェックをid:tikedaに依頼して、適宜フィードバックを貰いながら進めていきました。このほかに制作スタッフが数名います。プロジェクトが立ち上がったのが8月1日だったので、開発期間は約3ヶ月です。アルファ版完成が異常に速く、開発2日目か3日目で記事投稿ができるようになり、5日目でアルファ版を社内リリース。choさんほんとすごいなって思いました
このまえ登り坂の途中でロードバイクのタイヤが破裂しました。ながたです。 今回はバッチ処理について書いてみようと思います。 バッチ処理? Webサービスの処理開始条件は、大まかに次の2つに分けることができます。 ユーザーのアクションに起因するもの ユーザーのアクションに起因しないもの このうち後者の処理をバッチ処理が担当することになります。 バッチ処理の担当分はさらに、 特定の条件(時間やサービスの状態)で実行するもの 手動で実行するもの の2つに分けられます。 今回はこの「手動で実行するもの」について書きたいと思います。 バッチを手動実行するのはどんなとき? バッチ処理を手動で実行するのは、十中八九イレギュラーな状況が発生したときです。 ルーチンワークや実行の条件が決まっているものは何らかの方法で自動化できるはずです。 そしてイレギュラーな状況のほとんどは不具合が発生したとき。 つまり 重
今年の東京ゲームショーの入場者数が過去最高だったそうで。東京ゲームショウ2011の入場者数が過去最高の22万2668人を記録【TGS2011】 - ファミ通.com ゲームが盛り上がってきてるかも?ってことで、とても嬉しいニュースです。偶然ですがちょうど先日、以下を書きました。 あなたの「隙間時間」を埋めてくれる無料iPhoneゲーム30選 色々とゲームで遊んでたら、ゲーム開発について色々と調べたくなったので、調べてみたメモを以下にまとめてみました。 ゲームの作り方目次(AppStoreカテゴリ別) 以下、AppStoreのゲームカテゴリ別に整理した目次です。並びはAppStoreでの表示順です(2011/9/20時点) AppStoreカテゴリジャンプ先アーケードシューティングアクションアクション|Unityアドベンチャーアドベンチャーボード、カジノボード、カジノシミュレーションシミュレ
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
「2007年からソーシャルゲームを提供してきたGREEにおける、技術的な側面での失敗と成功の実例を通じて、そのノウハウや必要な技術について解説します。合わせて、それらの経験に基づくGREEから提供していくフレームワークであるGREE Technology Stackについてもご紹介します」ということで、CEDEC2011にて講演された「GREEソーシャルゲーム5年間の技術的失敗と成功の歴史 ~GREE Technology Stackのご紹介~」はかなり濃い内容となっており、グリーの開発本部 取締役 執行役員CTO 開発本部長である藤本真樹氏と、同じくグリーの開発本部 インフラ統括部 アプリ基盤チーム リーダーの梶原大輔氏による話が次々と展開されていきました。 注目度も非常に高く、人だらけ。 今回はこの講演を発表の場にいる感覚で読んでもらえるように、当日の発表資料と合わせてまとめてみました
概要 開発をすればリリースがあり、リリースが終われば開発があります。継続開発をする以上はリリースと開発の繰り返しです。 開発手法やリリース手段は沢山あるのですが、あまりしっくりくるものが無かったので自分でまとめてみました。 これで完璧というものは残念ながらこの世にないと思うので、これからも臨機応変に良い流れを作って行ければと思います。 この文章は以下のような構成になってます。書き殴りですみません。 バージョンの付け方 ソースコード管理とリリース タスク駆動 環境方針 定義 いくつか事前に定義しておかないと話しが訳わからなくなりそうなので。 バージョン管理には git を採用しています。 開発というのはコードを書く事だけを指してはいません。 ここでいうフレームワークは「自身で開発している」として扱います。そうしないとちょっと難しいので。 ライブラリは自身の開発とそれ以外があると思いますので、
Appleから提供されているiOSのプログラミングガイド。日本語に翻訳されたiOSのドキュメントがあります。iOSデバイス向けのアプリを開発するにあたっては、必読の内容となっています。 これらは全てPDFで提供されています。 ですのでiPhoneでPDFを開き、iBooksで保存することが出来ます。 このように、持ち運んで空き時間に勉強できるんです。 PDFのリンクは下記にまとめていますので、iPhoneでご覧ください! iOSのドキュメント一覧(2011.8.20現時点) Audio & Video AV Foundationプログラミングガイド iOSカメラプログラミングトピックス Audio Session プログラミングガイド Core Audio の概要 iPodライブラリアクセス プログラミングガイド Tools & Languages Objective-C
ケーブルをまとめるのと巻いて保管しておくために、ケーブルバンドを利用している。手元の在庫がなくなったので、あらためて注文した。 取り外しするありとあらゆるケーブルには基本的に付けている。ポイントとしては、ケーブルを発見しやすくするのと、バン...
こんにちは。ライブドアのモリウチです。突然ですがWebディレクターのみなさん、「WebAPI」を使った企画や設計をしていますか? APIとは「Application Programming Interface」の略で、特にWebAPIとはあるプログラムが、別のシステム (Webサービス) が持っているデータのCRUD (読み書き削除) や、一連の処理 (機能) の利用を可能にするための技術です。 WebAPIの活用の普及に貢献したのは2005年のGoogleMapのAPIでしょう。 WebAPIは、登場当初は地図情報や、都道府県やジャンルなどの静的な情報を取り出して利用することが主流でしたが、最近ではTwitterやFacebookのように利用ユーザーからの許可を受けてユーザーの個人データやソーシャルグラフを取り出して利用したり更新したりできるようなWebAPIが一般化してきました。そして
脳と現状のコンピュータは、計算モデル、アーキテクチャ、 アルゴリズムなどいろいろな観点からみて違いがあります。 はたしてコンピュータの上で脳と同じ機能は実現できるのでしょうか。 実現を難しくする要因として何が考えられるでしょうか。 ◆計算モデルの違い 計算する機械を数学的に抽象化したものを計算モデルと呼びます。 チューリングマシンは計算モデルの1つです。 チューリングマシンとは数学的に異なる計算モデルとしては、 例えば非決定性チューリングマシン、 (理想的な)アナログコンピュータ、量子チューリングマシン (量子コンピュータのモデル)があります。 これらはチューリングマシンよりも強力だったり速かったりします。 さて、「脳の計算モデル」はチューリングマシンと等価でしょうか、 それともより強力だったり速かったりするのでしょうか。 非決定性チューリングマシンは並列度が無限の計算機です。 脳は超並列
理化学研究所(理研)と富士通は6月20日、神戸市で共同開発中の京速コンピュータ「京」がLINPACKのベンチマークTop500で第1位を獲得したと発表した。ベンチマーク値は8.162ペタフロップ(FLOPS)で、実行効率は93.0%を達成した。 今回の計測に用いられたのは、672筐体の6万8544個のCPU(ピーク性能は8.774ペタFLOPS)で、計画する800以上の筐体の約80%に当たる。問題サイズは1072万5120次元、実行時間は10万771秒(約28時間)だった。理研と富士通では、4月から計算機本体の一部(16筐体)を「アプリケーションユーザー」(グランドチャレンジおよび戦略分野の一部ユーザー)に提供して、試験利用をスタート。計測に用いた筐体の設置は5月下旬に完了しており、10数回におよぶ調整を経ての成果だという。 ドイツで開催中の国際スーパーコンピューティング会議が同日発表した
Code Complete 2 [ Code Complete第2版―完全なプログラミングを目指して (上・下) ] スティーブ・マコネルのCode Completeはソフトウェア開発者のための「楽しい料理」本だ。この本を読むということは、自分の仕事を楽しんでいるということであり、自分のすることに真剣であるということであり、もっと向上したいと思っているということなのだ。Code Completeの中で、スティーブは平均的なプログラマが読む 技術書は年に1冊に満たないと指摘している。この本を読んでいるという時点で、あなたはおそらく周りにいる開発者たちの90%と違う行動を取っていることになる。それもいい方向にだ。 私はこの本がすごく好きで、ここから自分のWebサイトの名前(Coding Horror)を取ったくらいだ。この本ではやるべきでない悪い例には"coding horror"アイコンで印
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く