Available in Early Access. Monitor your infrastructure, address security vulnerabilities, and assess the health of your NGINX fleet, all from a single console.
![NGINX Documentation](https://cdn-ak-scissors.b.st-hatena.com/image/square/0b9363ea51d6e44e57139a0b03f6198034e231fa/height=288;version=1;width=512/https%3A%2F%2Fdocs.nginx.com%2Fimages%2Ficons%2FNGINX-Docs-new-docs-dark-1200x630.png)
(ドラッグ&ドロップの簡単操作で PDFに埋め込んである JPEGファイルを抜き出して保存できます。) Tags: [Windowsアプリ] ●PDF_JpegExtracterとは PDFの中の JPEGファイルを劣化無しで抽出します。 ・PDFの中の JPEGファイルを劣化無しで抽出します ●使い方 ・PDFファイルをドラッグ&ドロップしてください。 ・PDFファイルと同じ場所に抽出した JPEGファイルができます。 以上、終わり。簡単です。 ・作者のコダワリとして、同種のソフトと比べファイルサイズ及びメモリ使用量が格段に少なく、負荷を全く掛けない軽量コンパクトな作りになっています。 ●インストール方法 適当に解凍してください。 ●使用するファイル PDF_JpegExtracter.exe ‥‥‥実行ファイル ●動作環境 ・Windows 98 Second Edition ・Win
id:n7shi:20110208のPDF解析コードを利用して、id:n7shi:20110201のJPEG抽出ツールを自前のコードに置き換えました。実行には.NET Framework 2.0が必要です。 ソース閲覧: https://bitbucket.org/7shi/pdf2jpeg/src ダウンロード: https://bitbucket.org/7shi/pdf2jpeg/downloads ライセンス: パブリックドメイン コードのコア部分: https://gist.github.com/796217 必要最低限のコードで構成されるためファイルサイズが小さくなって、ライセンスも変更できるようになりました。
Redmine GitHub Hook This plugin allows you to update your local Git repositories in Redmine when changes have been pushed to GitHub. Project Status: Looking for maintainers This project is not under active development, although I will continue to provide support for current users, but you can change that by joining the team. If you use this project and would like to develop it further, please intr
チケット駆動開発を運用していると話すと、必ず「チケットの粒度はどれくらいが妥当ですか?」という質問が来る。 僕はまだその質問に完全な回答は持っていない。 その質問について考えていることをメモ。 【1】RedmineやTracで、全てのタスクからQAまでチケットを起票してから作業を始めるようにすると、チケットの粒度がかなり細かくなってしまう。 粒度が小さいと作業しやすいが、チケットの完了速度よりもチケットの登録速度が上回ってしまう時が多いため、どんどんタスクが増えていってしまうような感覚に陥ってしまう。 かと言って、チケットの工数が5人日以上になってしまうと、進捗がはかどっているのかどうかも分からない。 チケットの粒度が問題になる状況は、顧客へ進捗報告を出したい時だ。 RedmineやTracによるチケット管理はあくまでも開発者のためのタスク管理が目的だから、粒度が細かすぎて、顧客から見れば
Redmineのチケットとは一体何だろうか? Redmineのチケット駆動開発の面白さは、最初は課題チケットでしかなかったのに、いつの間にか作業チケットに変わった、というように、チケットにストックとフローの二重性を持たせて、チケットに複数の意味を持たせている点にあると思う。 Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索 Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索 その他にも、Redmineでは、課題チケットという一つのインシデントという情報(データ)として意味を持たせていたのに、課題を解決する対策の作業手順(プロセス)もチケットとして登録される、というケースがよくある。 つまり、チケットは、ナレッジとして蓄積されるデータのケースと、作業手順として進捗管理されて
Redmineを運用してみると、トラッカーの概念が分からないという声をよく聞く。 トラッカーについて考えたことをメモ。 ラフなメモ書き。 【1】Redmineのトラッカーはワークフローそのもの。 Redmineのトラッカー管理画面で、ロール単位にステータスのデシジョンマトリクスで自由に設定できる。 デフォルトのトラッカーは「機能」「バグ」「サポート」の3つだが、実際の運用では使いづらい場面があるので、各現場で独特のトラッカーがあるだろうと思う。 個人的には、一人一人の運用ユーザに一番聞いてみたい内容だ。 トラッカーが難しいのは、ワークフローを意識していないからだろうと思う。 ソフトウェア開発の作業は、チケットを一人で担当して終わらせるだけではない。 バグ修正やリリース作業では、必ず複数人のチェックを入れなければ、作業ミスが重大な過失につながる。 だから、それら作業はワークフローに複数人の担
Redmineのトラッカーやステータスの付け方の記事があったのでメモ。 【元ネタ】 Redmine チケットのトラッカーとステータス項目の意味と設定 - developer (引用) * トラッカー o ドキュメント + ドキュメント書き。 o 調査・検証 + 調査、検証、研究など。 o 機能 + 機能の追加や変更など。 o 不具合/バグ + バグや不具合登録する。 o 要望 + ユーザーからの要望。 + 後で「機能」や「バグ」に変化する可能性がある。 o サポート + ユーザーからの問い合わせは、とりあえず登録。 + 後で「要望」や「バグ」に変化する可能性がある。 o 障害 + なんらかの障害が発生したら、とりあえず登録。 + このチケットに関連した「不具合/バグ」のチケットが後から追加される可能性あり。 o 環境 + 環境構築・環境整備や設定変更など。 o アイデア + アイデアを登録
トラッカーやチケットには、様々なパラメータを設定する事ができる。デフォルト値でも十分使える気はするが、後で分析できるように考えながら設定してみる。懲りすぎると逆に混乱するので注意が必要。。。 プロジェクト この単位でトラッカー、メンバー、ソースコード管理システムのリポジトリ、Wiki、アナウンス、文書などを登録、公開する。ソフトウェア開発の場合は、管理対象のソフトウェア毎に作成するのが普通。 今回は、主にIS仕事のタスク管理に使うので以下プロジェクトを作成した。 既存システム目標管理(AD構築など数ヶ月かけて行う作業)その他何でも入れるプロジェクトを1つ1プロジェクトで全て管理する事も考えたが、数年使い続ける事を考えると、何らかの単位で分けたほうがいい。後々公開する事も考慮。 トラッカー トラッカーは、チケットの入れ物で、チケット発行時にどのトラッカーに含めるかを選択する。(ただし、後から
この記事の概要 Imlib2を使って画像のサムネイルを生成してみたところ、ImageMagickより3倍速かった。 また一般的には、Imlib2の方が画質が悪いとされているが、パラメータを調整することで、十分に美しいサムネイル画像を得ることができた。 はじめに Imlib2は画像処理ライブラリ。mixiの発表資料大規模画像配信とPerl によれば、mixiは高速に高品質なサムネイルを生成するために、ImageMagickでなくImlib2を選んでいる。 上記資料の中では、以下のように説明されている。 速度 Epeg > Imlib2 > Imager >>> ImageMagick 画質 ImageMagick > Imlib2 >>> EpegImlibの画質は多少ImageMagickに劣るが、速度は十分に速い、とのこと。 一方で、404 Not Foundという記事では、ImageM
「ドコモの状況を笑える状態ではない」――ソフトバンクの決算会見で孫正義社長が、NTTドコモの通信障害に関連して、スマートフォンによる通信量増加の状況を説明した。爆発的なトラフィック増に危機感を示し、「全ての電波をオークションにかけるべきではないか」と、電波の有効活用のあり方について持論を述べた。 モバイルネットワークでは「“ネチケット”が必要」 携帯電話最大手としてネットワーク品質に定評のあるドコモが、スマートフォンの通信対策に苦戦している。昨年末から、スマートフォンが行う大量の通信に端を発した障害が複数発生。総務省から行政指導を受ける事態となった。 ソフトバンクの孫氏は「我々も笑える状態ではない」と危機感を示し、スマートフォンによる通信の増加は「業界全体の共通の悩みだ」と説明する。孫氏によれば、同社の携帯電話網の通信量は、1年で2倍のペースで増加しているが、スマートフォンへの移行が進む東
派手で見栄えがする大規模なプロダクトを作ろう!っていうことで、一人でフルスタックなネトゲを作っている。大きなプログラムを書いても破綻しないようにテスト書きまくってテストファーストを心がけたり、Travis-CIによる継続的インテグレーションで頑張ったり。 というわけで作っているのはMMORPGなんだけど、ここで実装するのはまあ平均的なMMORPGを想像してもらいたい。自分がやろうとしているのは、モダンなOSSとさくらの安いVPSで、独学の学生一人でもフルスタックなネトゲみたいなのが組める、ということの実証。 なんでそんなことをしているかって言うと、一応就活中で、見栄えがするアプリ提出できるとおいしいなーっていう下心。 *追記* ここでは https://github.com/mizchi/wanderer のことを言ってるんだけど大規模リファクタリング中なのでここで言ってることは半分ぐらい
Section: User Commands (1) Updated: 29 December 1994 Index JM Home Page roff page 名前 expect - 対話的なプログラムとのやりとりを自動化するプログラム, バージョン 5 書式 expect [ -dDinN ] [ -c cmds ] [ -[f|b] ] cmdfile ] [ args ] イントロダクション Expect は、スクリプトの指示に従って、対話的なプログラムと"会話"するプログラムである。 以下のスクリプトに示すように、 Expect には、対話プログラムからの期待されうる入力とそれに対する正しい応答を 教えておく。インタプリタは分岐処理と高度な制御構造を提供し、 対話プログラムへの指示を行なう。 さらに、必要な時にスクリプトから制御を奪って直接人間が指示を行ない、 その後、制御をス
SecTools.Org: Top 125 Network Security Tools For more than a decade, the Nmap Project has been cataloguing the network security community's favorite tools. In 2011 this site became much more dynamic, offering ratings, reviews, searching, sorting, and a new tool suggestion form. This site allows open source and commercial tools on any platform, except those tools that we maintain (such as the Nmap
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く