タグ

ブックマーク / gihyo.jp (20)

  • 第762回 定番のデバッグ・調査ツールであるstraceでエラーインジェクション | gihyo.jp

    straceはユーザーランドアプリケーションの挙動の確認やデバッグに使える便利なツールです。どのシステムコールが、どのような引数で呼び出され、その結果どうなったのかをログとして残せます。不可解な挙動をするプログラムを調べる上で覚えておくと損はないツールです。今回はstraceの基的な使い方に加えて、わざとシステムコールをエラー終了させる、エラーインジェクションについても紹介しましょう。 不可解なプログラムについて この世にあるソフトウェアはすべて何らかの不具合を抱えています。もし不具合のないソフトウェアが存在するとしたら、その事実自体が不具合と言えるかもしれません。そのまま放置しておくと、きっと将来なにがしかの不具合が顕現することでしょう。よってソフトウェアエンジニアと呼ばれる人たちは、日々ソフトウェア様のご機嫌を伺い、こびりついた不具合を削ぎ落とし、場合によってはあえて不具合を埋め込み

    第762回 定番のデバッグ・調査ツールであるstraceでエラーインジェクション | gihyo.jp
  • ITエンジニア残業ゼロの働き方 〜現場で本当に使えた仕事効率化の法則95

    2022年2月24日紙版発売 2022年2月21日電子版発売 田中聡 著 四六判/256ページ 定価1,980円(体1,800円+税10%) ISBN 978-4-297-12726-8 Gihyo Direct Amazon 楽天ブックス ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto このの概要 書は決して残業をやめて楽をしようというではありません。 「決められた勤務時間内を全力疾走して成果を出すために勤務時間外はきちんと休む」 「そのために残業をやめよう」 このようなことを目的としたです。 書では,月100時間のサラリーマンエンジニアだった著者が,年間6か月の残業0と有給消化100%を達成するために試行錯誤した「残業しない働き方」を伝授します。 残業はなにが問題なのか 自分の心

    ITエンジニア残業ゼロの働き方 〜現場で本当に使えた仕事効率化の法則95
    papiro
    papiro 2022/02/21
  • 雑務をこなすうちにLinuxに習熟できるかも!? シェル・ワンライナーをお勧めする理由:新刊ピックアップ

    コンピュータは便利ですが,それでも手間のかかる作業は多々あります。とくにGUI(グラフィカルユーザーインターフェース)のソフトウェアで次のような作業をやらないといけないとしたら,面倒そうだと思いませんか? 複数のファイルのファイル名を一括で変更する 大量の画像ファイルの中から全く同じ画像のファイルを探す 複数のファイルに記録されている数ヵ月にわたるログから特定の期間の情報だけを抽出する これらの作業をするには,ファイラー(Windowsのエクスプローラーなど)やエディタだけでは限界があります。専用ソフトをいくつか使ったり,単純な手作業を繰り返したりして作業することになります。 その点,シェルやスクリプト言語を使えば細かな条件をプログラミングすればどんな作業でも片付けられます。また,ターミナルのCLI(コマンドラインインターフェース)上では,コードを書いてそのまま実行できるため,たいへんお手

    雑務をこなすうちにLinuxに習熟できるかも!? シェル・ワンライナーをお勧めする理由:新刊ピックアップ
    papiro
    papiro 2021/11/17
    実は初心者にも優しい内容なのです、、
  • 1年目から身につけたい! チーム開発 6つの心得 記事一覧 | gihyo.jp

    第7章周りの人と協力しあおう―報告・相談に欠かせない3つの情報 足永拓郎,沖元謙治,結城洋志 2016-05-02

    1年目から身につけたい! チーム開発 6つの心得 記事一覧 | gihyo.jp
  • 第1回 FreeBSD 11-最低5年間サポートへ至る経緯は | gihyo.jp

    FreeBSD 11-最低5年間サポートへ至る経緯は FreeBSDプロジェクトはFreeBSD 11からセキュリティサポートおよびパッケージ提供のサポート期間を最低でも5年間は保持する「新しいサポートモデル」への移行に取り組んでいます。新しいサポートモデルの提案にはいくつかの背景があります。 要点を簡単にまとめると次のとおりです。 1年まはた2年という現在のサポート期間はエンタープライズ用途では短い リリース数の増加はプロジェクトの作業負荷を高くする ブランチ(9系、10系、11系と言ったまとまり)が最終的にどの程度サポートされることになるのかが不透明では長期の運用計画が立てにくい サポートするリリースバージョンが増えると、セキュリティチームがセキュリティアドバイザリ発行時に確認すべき対象が増えますし、パッケージを提供するためのビルド数も増えます。プロジェクトとして動ける人的リソースも機

    第1回 FreeBSD 11-最低5年間サポートへ至る経緯は | gihyo.jp
    papiro
    papiro 2015/05/05
    エンタープライズな利用への対応らしい
  • 第4回 FreeBSD勉強会開催―「サーバの負荷分析とチューニングの基礎」 | gihyo.jp

    2010年6月18日、株式会社Speeeオフィスにて「第4回 FreeBSD勉強会」が開催されました。この勉強会はFreeBSDコミッタである佐藤広生氏、後藤大地氏両名の立案がきっかけで開催されています。『⁠Software Design』や『FreeBSD Daily Topics』を発行する技術評論社、会場提供元となる株式会社Speee、ハンドリングをおこなうオングスおよびFreeBSD実行委員会のご協力いただいております。 第4回目は佐藤広生氏から「サーバの負荷分析とチューニングの基礎」のタイトルのもと、FreeBSDに用意されている基的なコマンドを使ってシステムの負荷状況を調べ、どういった状況にあるのかを調べる方法が紹介されました。紹介されたコマンドはtime(1)、vmstat(8)、iostat(8)、ministat(1)などです。パフォーマンスチューニングに利用できるパラ

    第4回 FreeBSD勉強会開催―「サーバの負荷分析とチューニングの基礎」 | gihyo.jp
    papiro
    papiro 2015/03/10
    timeコマンドやvmstatコマンドの見方
  • 2010年7月12日 /と/usrとリードオンリーにして堅牢に運用する方法 | gihyo.jp

    tips How to setup robust FreeBSD / and /usr FreeBSDではカーネルやシステムの起動に必要になるソフトウェアやライブラリは/パーティションにインストールし、ベースとなるユーザランド関連のソフトウェアやライブラリ、ドキュメントは/usrにインストールします。/や/usrは運用時にはデータを書き込む必要がなく、書き込み権限がなくてもとくに問題ありません。書き込みが発生する領域は/varや/usr/localを使うように切り分けが実施されています。 何らかの原因で/や/usrの必要なものが壊れると、それに引きずられてシステムが起動しなくなったり、起動してもおかしな挙動を見せることがあります。こうしたケースを避け、より堅牢なシステム運用を実現するテクニックのひとつに/と/usrをリードオンリーでマウントして利用するというテクニックがあります。/etc/

    2010年7月12日 /と/usrとリードオンリーにして堅牢に運用する方法 | gihyo.jp
    papiro
    papiro 2015/02/19
    目的は違うのだが、FreeBSDをP2Vする時に、dumpするのに使えそう。
  • 第287回 Ubuntuで超高速grep「The Silver Searcher」を使う | gihyo.jp

    UNIXライクなOS上で作業をするとき、grepコマンドはなくてはならない存在です。そんな基的かつ古典的なユーティリティであるgrepですが、使いにくい面もあります。 2013年のはじめころから、grepに取って代わるコマンドとして「The Silver Searcher」(またの名を「ag⁠」⁠)が注目されはじめました。 今回のレシピでは、「⁠The Silver Searcher」(以下ag)をUbuntuで使用する方法を紹介します。 The Silver Searcher(ag)とは? プログラムを書いていると、ソースコード全域にわたって文字列を検索したい、ということはよくありますよね。そのようなときにもgrepコマンドが活躍するわけですが、プロジェクトのディレクトリには検索したくないファイルというものも存在します。 たとえばバージョン管理システムが使っている「.git」や「.sv

    第287回 Ubuntuで超高速grep「The Silver Searcher」を使う | gihyo.jp
  • 第17回 日々の業務から一歩下がって仕事を見つめる大切さ | gihyo.jp

    大局観を持って働くことの大切さ この業界にいてつくづく思うのは、「⁠大局観を持って働く」ことの大切さである。テクノロジは激しい勢いで進歩しているし、業界全体の勢力図や消費者が求めるものも日々変化している。 私がMicrosoftで働いていた90年代はPCがデバイスの主役だったが、今や主役はモバイルデバイスである。インターネットへの接続方法も、電話線を通したダイアルアップからブロードバンド、そしてワイヤレスへとわずか十数年の間に大きく変化した。 インターネット上のビジネスも当初は「ポータルビジネス」が主役だったが、今はソーシャルネットワークからSaaS(Software as a Service)まで、さまざまなアプローチで多種多彩な企業が競争を繰り広げている。 こんな中で「価値を生み出す仕事」をしつづけるためには(つまり「価値のある人材」でいつづけるためには⁠)⁠、目の前の仕事を着実にこな

    第17回 日々の業務から一歩下がって仕事を見つめる大切さ | gihyo.jp
  • 第6回 [最終回]プログラマについて | gihyo.jp

    「プログラミングに関する雑多な事柄」がテーマの連載、最終回の今回はプログラマについて取り上げてみたいと思います。 生産的なプログラマとは? 生産的なプログラマは平均的なプログラマの何倍もの仕事をする、という話をよく耳にします。確かに経験に照らし合わせても、できるプログラマの生産性には目を見張るものがあります。 ここでは、私がこれまでに関わった中で、生産的なプログラマにどんな特徴が見られたか紹介したいと思います。 レスポンスが早い チームでの開発では、他のメンバーから質問があったり、何かを依頼されたときに、できるだけ早くレスポンスすることが大切です。 たとえば、ちょっとした質問への返事が遅いだけで、誰かの進行が止まってしまうことがあります。レスポンスの早いプログラマと一緒に仕事をすると、こうした待ち時間が最小限になります。 フットワークが軽い 私の知り合いのあるプログラマは、何かアイディア

    第6回 [最終回]プログラマについて | gihyo.jp
  • 第1回 PHPUnit入門 | gihyo.jp

    はじめに 皆さん、テストしてますか? 近年、システム開発を発注する顧客や利用ユーザーの品質に対する要求レベルは格段に向上しています。そのため、システムの品質を保証するための「テストフェーズ」はますます欠かせなくなってきています。 ここで、一口に「テスト」といっても、フェーズによって以下のような様々なテストがあります。 ユニットテスト・単体テスト 結合テスト・システムテスト 総合テスト 受け入れテスト 負荷テスト セキュリティテスト 筆者の経験上、一般的なシステム開発でもっとも大きな工数を占めるのは、この「テスト」フェーズと考えています。なぜなら、テストフェーズは例外なく「繰り返し作業」だからです。前述の様々なテストフェーズで共通することですが、テストフェーズは「テストで発見されたバグ・障害を修正して再度テストを行う」という作業を何度も繰り返し行うフェーズです。あとのフェーズで不具合が発見さ

    第1回 PHPUnit入門 | gihyo.jp
  • エンジニアのジレンマ ~悩む立ち位置と仲間の境界~ 記事一覧 | gihyo.jp

    運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

    エンジニアのジレンマ ~悩む立ち位置と仲間の境界~ 記事一覧 | gihyo.jp
  • 禅で学ぶ「エンジニア」人生の歩き方 記事一覧 | gihyo.jp

    運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

    禅で学ぶ「エンジニア」人生の歩き方 記事一覧 | gihyo.jp
  • 第4回 オブジェクト指向の本質 | gihyo.jp

    エンジニアとして良い仕事をするために必要なこと ソフトウェア業界で日米を往復しながら仕事をしていると、世界中のさまざまなエンジニアに会う。私のように「プログラミングを心底楽しんでいる」人から、「⁠新3K」(⁠きつい・厳しい・帰れない)を身をもって体験している人までさまざまだが、共通して言えることは、エンジニアとしての基礎がしっかりできている人とできていない人では、その生産効率に大きな開きがあり、それが結果的には、会社での労働環境や待遇に、そして結果として自分自身にとっての「仕事の充実度」に、大きな影響を与えているということである。 いつも締め切りに追われている、毎回バグで苦しんでいる、徹夜の連続で体力に限界がきているなど、「⁠仕事がきつい」理由はいろいろとあると思うが、会社や上司の悪口を言う前に、自分自身がプロフェッショナルなエンジニアとしてこの業界で勝負をするうえで必要な最低限の基礎がで

    第4回 オブジェクト指向の本質 | gihyo.jp
    papiro
    papiro 2011/07/07
    インターフェースを定義して祖結合な構造にすることが本質
  • 第2回 「締め切りは絶対に守るもの」と考えると世界が変わる | gihyo.jp

    「締め切りを守ること」の大切さ 今までたくさんの日米のエンジニア仕事をしてきた。その中には私よりも明らかに「賢いエンジニア」もいたし、ものすごい生産性でプログラムを作ってくれる「馬力(ばりき)のあるエンジニア」もいた。しかし、そんな中でも、私がものを作るうえで最も大切だと考えている「あること」をキチンとこなせる人は100人に1人もいなかった。その「あること」とは、「⁠常に締め切りを守れるように仕事をすること」である。 チームで仕事をする場合、どうしてもお互いが担当するタスク(=作業)の間に依存関係が生じる。そんなときに、どれか一つのタスクの完了の遅れが、ほかのタスクの完了に波及し、それがタスク間の競合を引き起こして全体のスケジュールがさらに遅れる、という事態はソフトウェア開発の現場ではよく見られる。そんな状況をできるだけ回避するには、プロジェクトに関わる人全員が、自分に割り当てられたタス

    第2回 「締め切りは絶対に守るもの」と考えると世界が変わる | gihyo.jp
    papiro
    papiro 2010/07/20
    当たり前のことなんだよな、確かに、、、
  • 第4回 スキーマレスで柔軟に扱えるMongoDB | gihyo.jp

    はじめに 今回はドキュメント指向型データベースの代表としてMongoDBを取り上げます。ドキュメント指向型データベースはRDBMSと違って、スキーマ(テーブル定義)が必要ないことが大きな特徴です。 今回も利用したコードやプログラムはgithubに置いてあるので適宜参照してください。 MongoDBの特徴 前々回、前回と紹介したmemcachedやTokyoTyrantは基的にRDBMSと組み合わせて、「⁠RDBMSの弱い部分を補う」という使い方でした。しかしMongoDBは少し違っていて、JOINが行えないこととトランザクションをサポートしていないこと以外は、ほぼRDBMSと同じように扱うことができるため、「⁠RDBMSの代替として使う」ことが可能です。 上述したようにMongoDBRDBMSと違ってJOINはできませんが、代わりに基準となるオブジェクトに別のオブジェクトをあらかじめe

    第4回 スキーマレスで柔軟に扱えるMongoDB | gihyo.jp
    papiro
    papiro 2010/07/02
  • Greasemonkeyによるアプリケーション開発:第1回 Greasemonkeyによるアプリケーション開発の準備|gihyo.jp

    稿ではGreasemonkeyを使ってアプリケーションを作る際の筆者なりのコツを紹介しようと思います。単に筆者が「コツ」だと思っていることを紹介するだけでは面白くありませんので、ちょっとしたアプリケーションを題材にして、作成していく過程をステップに分けて解説していく形式をとることとします。 さて早速Greasemonkeyによるアプリケーションの作成方法を紹介しましょう、といいたいところですが、「⁠Greasemonkeyによるアプリケーションとは何だ?」「⁠そもそもGreasemonkeyとは何だ?」という疑問をお持ちの方もおられると思いますので、第1回は「Greasemonkeyとは何か」ということと、その基的な使い方を紹介したいと思います。Greasemonkeyをよくご存知な方は、次週までお待ちください。 Greasemonkeyとは GreasemonkeyはFirefox用

    Greasemonkeyによるアプリケーション開発:第1回 Greasemonkeyによるアプリケーション開発の準備|gihyo.jp
    papiro
    papiro 2010/06/27
    クライアントサイドプログラミング入門!
  • 連載:目指せ!iPhoneアプリ開発エキスパート|gihyo.jp … 技術評論社

    運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

    連載:目指せ!iPhoneアプリ開発エキスパート|gihyo.jp … 技術評論社
  • 第4回 UTF-8の冗長なエンコード | gihyo.jp

    今回は、文字コードに関連するセキュリティの話題では古参ともいえるUTF-8の冗長なエンコードというテーマについて紹介します。 UTF-8とは UTF-8は、各文字を1~4バイトの可変長で表現するUnicodeの符号化方式のひとつです。 U+0000からU+007Fの範囲の文字を0x00から0x7Fの1バイトで表現しているため、US-ASCIIと互換性がある、バイト列の途中からでも文字の先頭バイトを簡単に検出できる、多バイト文字の途中に0x00や0x5C(\⁠)⁠、0x2F(/)などが現れない、などの特徴があります。 UTF-8での文字のビットパターンは表1のようになります。 表1 UTF-8でのビットパターン

    第4回 UTF-8の冗長なエンコード | gihyo.jp
  • 地域Ruby会議・アンド・ナウ | gihyo.jp

    地域Ruby会議(Regional RubyKaigi)は、プログラミング言語Rubyの年に一度の大イベントである日Ruby会議(RubyKaigi)のようなものを日国内のいろいろな地域で開催してみようというプロジェクト。2008年8月の東京からスタートし、すでに8都市で開催されてきました。記事ではそんな地域Ruby会議に注目し、Rubyコミュニティならではの活溌なイベント開催の現状、この活動にこめられたさまざまな思い、そして気になる今後の見通し(!?)について、プロジェクトの提案者である角谷信太郎氏による特別レポートをお届けします。 もっとRubyKaigiを!! 地域Ruby 会議(またはRegional RubyKaigi・リージョナルルビーカイギ)は、2006 年から毎年開催されている日Ruby 会議(RubyKaigi)とは別の枠組みで、RubyKaigiのようなものを日

    地域Ruby会議・アンド・ナウ | gihyo.jp
    papiro
    papiro 2009/07/18
    図2写真の一番下に、会社の同僚が写真に写っていた。
  • 1