Regex Of The DeadMusic: OFF Type regular expression which matches zombie's name and kill them. Don't kill humans. Regular Expression: . match any charactor ^ top of strings $ end of strings [] charactor set * repeat + repeat
JPCERT C Secure Coding Standard 日本語版 - プリプロセッサ (PRE) (#c01)
日本語版コーディングスタンダードの翻訳について 00. はじめに 01. プリプロセッサ (PRE) 02. 宣言と初期化 (DCL) 03. 式 (EXP) 04. 整数 (INT) 05. 浮動小数点 (FLP) 06. 配列 (ARR) 07. 文字と文字列 (STR) 08. メモリ管理 (MEM) 09. 入出力 (FIO) 10. 環境 (ENV) 11. シグナル (SIG) 12. エラー処理 (ERR) 13. Application Programming Interface (API) 14. 並行性 (CON) 49. 雑則 (MSC) 50. POSIX (POS) AA. 参考情報 BB. Definitions CC. 未定義の動作 DD. 未規定の動作 XX. お問い合わせ Top へ 00はじめに このページでは、JPCERTコーディネーションセンターが翻
Programming Languages Influence Network | Exploring Data
Loading the data may take a while, please be patient... Graph Navigation You can zoom in and out the graph with the mouse wheel. You can move the graph by clicking and holding the left mouse button and moving the mouse. Language Information When you click on a language node in the graph a modal window with information about the language will be displayed. Language Search Search for a language name
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編） ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか？ 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
サイバーエージェントの中の人に「なんで、あんなにリア充なんですか」って聞いてきた話 - ゆううきブログ
寺子屋ギークという2日間のイベントに参加してきた．Cookpad，Mixi，サイバーエージェント，サイボウズなど名だたるWebっぽい企業の方からWeb系のギークっぽいお話を聞いてきた． もっとも，聴衆の方はあんまりWeb系ではない感じだった． Web系はRubykaigiに行ってそう．企業の中でもドリコムが一番狂っていて楽しそうで、名前をidで呼ぶらしくて良さそうだった． 2日目に，後ろに座っていた女の子もドリコムがおもしろそうと言っていた． @yoshitetsu さんに「東京来る予定ある？」みたいなこと聞かれたので，その折にはぜひ遊びに行きたい．id:jkondo 社長の「新サービスはだいたい流行らない！」 は名言だった． サイバーエージェントとか サイバーエージェントについては以前からウォッチしていて（入社式的な写真）派手な女の子とかたくさん居てリア充っぽくてひどい感じでdi
米国人からコーディングについての怒りのメールを頂戴した - その手の平は尻もつかめるさ
"米国人からコーディングについての怒りのメールを頂戴した" の補足 - その手の平は尻もつかめるさ ↑の方で補足いたしました。(2012.09.04 追記) 最近、英語のメールでよく怒られます。moznion です。 海を隔てて共同作業しているアメリカ人から、僕のコーディングについてお叱りのメールを頂いたので、 自戒の念を込めて邦訳して記します。 書いてあることは「当然」とも言うべき内容ですが、僕はその「当然」も守れていなかったのかぁ〜と反省。 以下、邦訳(意訳)です。 1. 郷に入っては郷に従え 既にソースコードが存在しているって事は、そこには同時にコーディングスタイルも存在しているってことだ。 その既存のソースコードに手を加える場合、別のコーディングスタイルを導入してはならない。 もし君がバックエンドのソースコードを弄っているなら、バックエンドのコーディングスタイルで記述するんだ。 フ
オブジェクト指向できていますか？
2010 icse-an analysis of the variability in forty preprocessor-based software...
良いエンジニアの育て方 - ひがやすを技術ブログ
人を育てるというのは、とても難しい。 なぜなら、育てる方も未完成な人間だから。 ちょっと経験値のある未完成な人が、経験値の少ない未完成な人と、ともに冒険をし、ともにレベルをあげていくことが、人を育てるってことだと思う。 人を育てようと思うと、どうしても上から目線になってしまう。上から目線だと気持ちも相手に伝わりにくい。気持ちが伝わらないと相手もうまく成長してくれない。 だから、人を育てる機会があったら、ともに冒険をする仲間を持ったと考えよう。きっとその方がうまくいく。 それでは、自分の話をしよう。自分というよりは自分たちの話かな。 2010年、自分は、昼間、ブラ三をやりながら、新規ビジネスの企画を考えたり、プロトタイプを作っていたりしていた。ブラ三をやっていたのは、当然ソーシャルアプリというものを学ぶためだ。ブラ三の能力はかなり向上したけど、仕事ではたいした結果が出せなかった。特に企画考え
コードレビューいろいろ - steps to phantasien
コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque
変更前をコメントアウトして残す習慣は未だ根強い (2012年現在) - 日々常々
2020-03-11追記: タイトルの「未だ」がいつなのかわかりづらいので「2012年現在」を追加しました。 バカバカしい話ですが、ソースコードをSubversionなどでバージョン管理しているにもかかわらず、未だ修正前をコメントアウトして残す習慣は残っているところも多々あります。こういうのです。 // 2012/08/15 irof 修正開始 // hoge = fuga(1); hoge = fuga(2); // 2012/08/15 irof 修正終了 見た事無い方は、そのまま見ないままで生きていかれることを切に願います。 コメントの修正がある場合 2012/07/21にあった、SCMBCでこんなツイートがありまして。 この時点でお見せしたのはこんな感じ。 // 2012/07/21 削除開始 // // 間違ったコメント // 2012/07/21 削除終了 someMethod
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
ソフトウェア開発プロジェクトをとりまく６つの誤解〜プログラミングを経験しないとわからないこと | Social Change!
続きを書きました → 伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解：既にあるソフトウェアを流用し
職業PGにわかるFizzBuzz - 日々常々
なんかFizzBuzzが書けないPGがどーとか定期的に話題になってるけど、私に言わせれば説明の仕方が悪い。 こうすれば誰でも書ける。 これだから最近の若いもんは……。 GoogleDocsのスプレッドシート、方眼紙作るのに向いてませんね……。
GitHub - google/styleguide: Style guides for Google-originated open-source projects
Every major open-source project has its own style guide: a set of conventions (sometimes arbitrary) about how to write code for that project. It is much easier to understand a large codebase when all the code in it is in a consistent style. “Style” covers a lot of ground, from “use camelCase for variable names” to “never use global variables” to “never use exceptions.” This project (google/stylegu
C++ Style Guide
Benjy Weinberger Craig Silverstein Gregory Eitzmann Mark Mentovai Tashana Landray This style guide contains many details that are initially hidden from view. They are marked by the triangle icon, which you see here on your left. Click it now. You should see "Hooray" appear below. Hooray! Now you know you can expand points to get more details. Alternatively, there's an "expand all" at the top o
ちょっとひと言 - 物言わぬ多数派: Visual Basic 6 が今でも成功している理由
物言わぬ多数派: Visual Basic 6 が今でも成功している理由 David Platt マイクロソフトは最近、Windows 8 の有効期間は Visual Basic 6 アプリケーションが「動作する」よう、互換性を確保する期間を延長することを発表しました (詳しくは今月の編集長のコラム、「老兵は死なず」をお読みください)。最初に Visual Basic 6 がリリースされたのは 1998 年なので、Visual Basic 6 アプリケーションは少なくとも 24 年にわたってサポートされることになります。Windows 7 (2009 年) と互換性がない Microsoft .NET Framework 1.0 (2002 年) とは対照的です。 Eric という私の生徒が、Visual Basic 6 を、Windows エコシステムに巣くう「なかなか退治できないゴキブ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソースコードを表示するためのフォント「Source Code Pro」をアドビがオープンソースで無料公開 － Publickey
長文日記
アプリ開発私塾に小学生 スマホが迫るIT教育の変革 - 日本経済新聞
