COBOLをシートに手書きしていた頃。80〜90年代、OSS普及前の開発風景に学ぶこと - エンジニアHub｜若手Webエンジニアのキャリアを考える！
COBOLをシートに手書きしていた頃。80～90年代、OSS普及前の開発風景に学ぶこと インターネットが一般的ではない時代にエンジニアはどのように仕事をしていたのでしょうか。WebDINO Japanの瀧田佐登子さんに、かつてのエンジニアの姿、そしてオープンソースという概念が一般化していく過程を、貴重なエピソードとともに聞きました。 オープンソースというカルチャー、そしてそこから生み出されるソフトウェアは今やあらゆる開発活動に不可欠なものです。多くのIT、インターネット関連企業の開発は、オープンソースなくしてもはや成り立たないでしょう。 一方で、言うまでもなくオープンソースという概念がまだ一般的ではない時代もあり、そしてその時代にも開発は行われていたのです。 「オープンソース」という言葉は、1998年に『伽藍とバザール』の著者、エリック・レイモンドによって発表されましたが、この言葉が指し示
Mozilla、Bugzillaが不正アクセスを受けて未公開の脆弱性情報が流出していたことを公表 | スラド IT
Mozillaは4日、バグトラッカーのBugzillaが不正アクセスを受け、未公開の脆弱性など一般公開されていなかったバグ情報が流出していたことを公表した(Mozilla Security Blogの記事、 VentureBeatの記事、 Ars Technicaの記事)。 一般公開されないバグ情報にアクセスできるのはBugzillaの特権ユーザーのみだが、パスワードが流出した他のWebサイトと同じパスワードを使用していたユーザーのアカウントが不正アクセスに使われたとみられる。確認された不正アクセスで最も古いものは2014年9月で、2013年9月には不正アクセスが行われていた可能性もあるとのこと。 攻撃者のアクセスが確認された未公開バグ185件のうち、重大な脆弱性は53件。このうち43件は攻撃者がアクセスした時点で修正済みであり、攻撃者がアクセスしてから修正までの期間が7日以内のものが2件
RHEL(CentOS)6系でトラフィックをたくさん捌くサーバが死ぬ問題は6.5のkernel-2.6.32-431.el6以降で多分直る - このブログはURLが変更になりました
タイトルで言いたいことはすべて言った。 経緯 うちの場合はLVS+keepalivedなロードバランサなんだけど、ちょくちょくkernel panicになる問題が発生してた。 そこでcrashコマンドで解析してみた。crashコマンドの使い方はこちらが参考になる。Linux crash dump 読み方入門 # crash /boot/System.map-2.6.32-279.14.1.el6.x86_64 /usr/lib/debug/lib/modules/2.6.32-279.14.1.el6.x86_64/vmlinux /var/crash/127.0.0.1-2013-09-27-16\:21\:01/vmcore (snip) SYSTEM MAP: /boot/System.map-2.6.32-279.14.1.el6.x86_64 DEBUG KERNEL: /usr
Bugzilla に登録してあるバグをプログラムから更新する方法
会社で BTS として Bugzilla を使っているんだけど、修正したあとに手作業で Web インターフェースから書き込むのが面倒になってきたので、自動化してみた。 コミットしたとき (Git の場合は push したとき) に、コミットメッセージからバグ番号を読み取って、対応するバグにメッセージを書き込みつつ、FIXED にすればよい。 情報がなくて困ったのが、バグにコメントを書いたり、FIXED にする方法。この部分の処理を抜き出してみた。 #!/usr/bin/perl -I/path/to/bugzilla -I/path/to/bugzilla/lib use strict; use Bugzilla; use Bugzilla::User; use Bugzilla::Status; use Bugzilla::Bug; use utf8; &update_bug(1, "ほ
そこの君、 バグ報告から始める Mozillaへのcontributeのやり方 教えてあげるからちょっと来なさい
そこの君、 バグ報告から始める Mozillaへのcontributeのやり方 教えてあげるからちょっと来なさい
コード・シンプリシティ
Bugzillaプロジェクトの主任設計者の実体験に基づいた、ソフトウェアの簡潔性を保つさまざまな知見をまとめた書籍。「なぜ簡潔性が大事なのか」「変更の価値を計るための方程式」「コードの簡潔性と複雑性」といったトピックについて、事実、法則、ルール、定義などを示しながら解説します。直接的なコードの書き方だけでなく、ソフトウェアプロダクト全体にわたるコードの健全性を保つためのヒントとなるでしょう。なお本書はEbookのみの販売となります。 まえがき 1章 はじめに なぜ簡潔性が大事なのか ソフトウェアデザイン 2章 なぜソフトウェアを作るのか 実際のアプリケーション 3章 未来 ソフトウェアデザインの方程式 デザインの品質 見えない結末 4章 変更 プログラム変更の実例からわかること 3つの間違い インクリメンタルな開発とデザイン 5章 不具合とデザイン 故障でなければ…… 何度も同じことを繰り
コードレビューいろいろ - steps to phantasien
コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque
殺伐荒野コーディング - steps to phantasien
ある朝会社にいくと git.webkit.org がダウンしている。仕事にならない・・・。 意気消沈したが くだを巻く口実ができたとウェブをひやかしていた 少し距離をおいて日々の業務を見直すいい機会だと調べものをしていたところ ソーシャルコーディングの講演で使われたスライド が紹介されておりふんふんと眺めた。 ソーシャルコーディングというのは GitHub なんかで fork と pull request みたいな対話を通じ 友達百人できるかんじですすめる民主的で人類賛歌なソフトウェア開発のことを指す(と私はおおまかに理解した)。 たしかに GitHub で送った pull request が “Nice! Thanks!!” とかいって受け入れられるとうれしいよね。 プログラマやっててよかった気分になる。 私が仕事でやっているのはコミッタレビュアそれ以外の身分差別と中央集権型 SCM,
BTSのワークフローと解決状況とカスタムフィールド - wyukawa's diary
それぞれのBTSのワークフローはなかなか特色があるね。 Tracのワークフローは以下のようになります。 new（新規） → assigned（アサイン済み） → accepted（受け入れ済み） → closed（クローズ） TracWorkflow – The Trac Project TracはResolution（解決状況）がある。 解決状況についてはこちらが参考になる。 BTSの解決状況(Resolution)は障害管理の名残り: プログラマの思索 Tracの後発のRedmineのワークフローは以下のようになります。 New（新規） → Assigned（担当） → Resolved（解決） → Closed（終了） 課題管理システム - Redmineガイド Redmineは解決状況は無いですが、Redmine本家のサイトはカスタムフィールド作ってやっているようです。 Seasa
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
バグトラッキングシステム「Bugzilla」、初リリースから15周年 | スラド IT