Power Automateをフルで活用した、業務プロセス改善フローの作成 ～受注業務プロセスの自動化 | gihyo.jp
デジタル人材への第一歩！「Power Automate」ではじめるローコードでの業務自動化 Power Automateをフルで活用した、業務プロセス改善フローの作成 ～受注業務プロセスの自動化 第3回では、Power Automate for desktopの特徴でもある、UI要素のセレクター編集を使った最適なフロー作成について解説しました。 最終回の第4回では、クラウドフローとAI Builderという機能を活用した業務プロセス全体の自動化の例と、その方法について解説します。 Power AutomateはWindows 11に標準搭載されているRPA機能の“Power Automate for desktop”が特に注目されています。ただ、組織内でのPower Automateの展開を考えると、有償ライセンスを導入した際に実現できる業務プロセス全体の自動化と運用方法について知るこ
Goで書くテスタブルなCLIツールの作り方 | gihyo.jp
CLIツールをテストする難しさ ターミナルなどで動作するCLI（コマンドラインインタフェース）ツールは、パッケージを公開して利用してもらうライブラリと比べてテストがしにくいと感じる読者も多いでしょう。 CLIツールは、ファイル/標準入力からの入力や、ファイル/標準出力/標準エラー出力への出力があることが多いです。また、コマンドライン引数やオプション（フラグ）によって変わる挙動のパターンが多いため、網羅的なテストが大変です。 入出力についても単一のファイルを読み書きするだけではなく、ディレクトリごと作成したり、特定のディレクトリ以下を再帰的に読み込むような処理もよくあります。 main関数にすべての処理をすべて書くような作りのCLIツールだと、実際にビルドしてテストスクリプトなどから動かしてテストするしかありません。しかし、せっかくCLIツールをGoで書いているのであれば、テストもGoで書き
第25回 cron周りのベストプラクティス（3） | gihyo.jp
（1）はこちら、（2）はこちらから。 App::RunCron （3）では、前回（2）に出てきたcron実行結果の通知処理やエラーハンドリングを統一的に行うことができる拙作のフレームワークApp::RunCronを紹介します。 App::RunCronとは？ cronにおけるログとエラーハンドリングの問題点 cronで実行したコマンドのエラー処理は悩ましいところです。パイプで出力を後続のコマンドに渡したところで、コマンドの成否自体は後続のコマンドからは知るすべはなく、出力結果から推測するしかありません。ログ処理とも共通することですが、コマンド終了コードがわからないまま、成功時も失敗時の別なく出力が流れてくることから、ログが埋もれてしまうというジレンマをcronは抱えています。 かといって、ジョブごとにエラー処理を書くのは、正しく書くのも難しく、書けたところで各ジョブ内に同じようなコードが
第25回 cron周りのベストプラクティス（2） | gihyo.jp
前回の（1）はこちらから。 プロジェクトでcronを利用する 筆者は普段ゲーム開発のサーバサイドを担当していますが、プロジェクトによってはバッチサーバのcrontabが100行を超えることもあります。イベント、ランキング処理、監視、集計、バックアップ、リカバリ処理などをしっかりやろうとすると、どうしてもそれくらいになってしまいます。 100行とはいかなくても、プロジェクトで使うcrontabの行数が膨らんでくると、サーバで直接crontabを編集することは管理上現実的ではありません。 crontabの記述とリポジトリ管理 では実際のプロジェクトでcrontabをどのように管理していけばよいのでしょうか。筆者は次の方針を立てています。 crontabの記述にゆるやかな規約を設け、リポジトリ管理する crontabの自動テストを行う crontabの反映方法をなるべく自動化する crontab
第436回 LibreOffice 5.2 Impressはこんなに変わった | gihyo.jp
今回は、LibreOffice 5.2の変更点を、Impressを中心に紹介します。 5.2の変更点はImpress向け？ LibreOffice 5.2の変更点の詳細は『Software Design 2016年9月号』をご覧いただきたいのですが、Impress自体の使い方も若干変わりましたし、テンプレートマネージャーの変更点やテンプレートの扱いが特にImpressで便利になりました。 今回使用するLibreOffice 今回紹介するLibreOfficeは、第434回で取り上げたPPAからインストールしています。執筆段階で5.2.1.2になっており、特に問題なければ5.2.1としてリリースされるバージョンです。 テンプレートマネージャー ［ファイル］–［新規作成］–［テンプレート］から起動するテンプレートマネージャーのルック＆フィールが変更されました（図1）。5.1まではタブでの選
第3回 「ポエム」がどうやってピクシブ社内へ広まったか？ | gihyo.jp
ピクシブでは「ポエム」によって開発が駆動しています。第3回は「ポエム」がどうやってピクシブの社内へと広まっていったかを、節目となる出来事やその時の「ポエム」とともにご紹介します。「ポエム」で開発を活性化する際に参考にしていただければ幸いです。 ポエムが会社にやってきた 日常の中で出たエモーショナルな想いを共有して欲しい。そんな想いのこもった「ポエム」とともに、「ポエム」とesa.ioというドキュメント共有サービスがピクシブにやってきました。 図1 esa.ioというドキュメント共有サービスがピクシブにやってきた 導入の経緯については、前々回・前回でご紹介しておりますので、ぜひご覧いただければと思います。 初期の利用状況 さて、新しいツールとしてピクシブにやってきたesa.ioですが、導入初期からエンジニアを中心に、10～20人単位での利用が行なわれるようになりました。初めの1週間ほどで
第5回 そろそろサーバを弄りたい | gihyo.jp
過去の日記を読み返していて、あることに気づいた。 今日までに、俺がAWSでやってきたこと。 オンプレ時代であれば、サーバをラッキングして、電源を入れ、ネットワーク機器をケーブルでつないだ事くらいしかやっていない。サーバに至っては、電源を入れて、SSHで接続して、pingを打っただけ。 クラウドという環境に初めて触れて、すごいことをしている気分だったのに、改めて考えてみると、すごく単純作業しかしていないことに気づいてしまった。でも、今までであれば、必ずデータセンターに行って作業していた事が、手元ですぐに完結するというのはすごい。それは俺がすごいんじゃなくて、AWSがすごい。 とはいえ、俺も何もしていないわけではなくて、ネットワークを作ったり、サーバを立ち上げたりするのをいかに早くできるかというのを反復練習していたわけで、今となってはネットワークを構築して、サーバを起動するくらいなら30分もあ
JIRAで進化するプロジェクト管理―ITSの特徴と変遷から見えてきたもの | gihyo.jp
ソフトウェア開発におけるプロジェクト管理は、大きな転換期を迎えています。全体計画ありきの従来のプロジェクト管理から、開発計画を細かく区切り、作業量の実測に基づいて短期間で繰り返すプロジェクト管理に移りつつある中で、プロジェクト管理で活用されるツールも進化しています。本記事では、ITS（Issue Tracking System、課題管理システム）の変遷を振り返りながら、これからのプロジェクト管理ツールに求められるものを探ります。特に、プロジェクト管理ツールとして日本でも導入されることが増えてきたAtlassian JIRA（以下、JIRA）に注目して、その特徴や人気の理由も見ていきます。 ExcelとITS、2つのプロジェクト管理ツール Excelによるプロジェクト管理 日本のソフトウェア開発の現場では、プロジェクト管理にスプレッドシートがよく使われます。ここではその代表格としてMicro
第25回 cron周りのベストプラクティス（1） | gihyo.jp
本連載では第一線のPerlハッカーが回替わりで執筆していきます。今回のハッカーはsongmuさんこと松木雅幸さんで、テーマはcronです。 なお本稿のサンプルコードは、本誌サポートサイトから入手できます。 cronとは？ cronは指定日時にジョブの自動実行を行うジョブスケジューラです。UNIX系のOSであれば実装の違いこそあれ、ほぼ標準でインストールされています。 作業自動化や、タスクを自動実行したいなどといった場合にcronは避けては通れません。Perlでバッチ処理を書く際などに多くの人が活用していると思いますが、ベストプラクティスがわからず恐る恐る使っている人も多いのではないでしょうか。 本稿では、cron活用におけるベストプラクティスについてお話します。 cronの使いどころ cronの使い途は、主に次の3つが考えられます。 a．アプリケーションのジョブの実行 b．システムに関わる
第6回 SQLで木構造を扱う～入れ子区間モデル （2）稠密性について | gihyo.jp
稠密性（ちょうみつせい）について 前回から見えるように、整数から有理数へ範囲を広げることの利点は非常に大きいのですが、その理由は、有理数が整数にはない稠密性（ちょうみつせい：density）という性質を持っていることにあります。あまり日常で使う言葉ではありませんが、直感的に言えば物がぎっしり詰まっているということです。もう少し数学的に厳密に書くと、 x<yを満たす任意の数x、yについて、x<m<yとなる数mが存在する となります。平たく言えば、どんな2つの数の間（区間）にも、まだまだ無限に数がある、ということです。 ここでキーとなるのは「任意の」という言葉です。特定のx, yではなく、大小関係を満たすあらゆる数のペアについて成立することがキモです。たとえば、1と2の間には、0.5という数が存在します。今度は1と0.5の間で見ても、0.25というさらに中間の数が存在します。後は同じ手順で、1
第6回 SQLで木構造を扱う～入れ子区間モデル （1）もしも無限の資源があったなら | gihyo.jp
はじめに 前回では、入れ子集合モデルという、リレーショナルデータベースで木構造を扱うための新しい方法論を紹介しました。このモデルは、RDB、SQLと親和性の高い優れたものではあるのですが、挿入など更新時に、無関係のノードまで変更対象としなければならないのが大きな難点でした。 そこで今回は、上記の欠点を解消する進化版のモデルを紹介します。この方法を理解していく過程で、私たちはRDBと集合論の結び付きの深さを再確認することになります。 ふだんこの連載は、1回完結の読み切り形式なのですが、今回に限り、前号の内容を前提としています。未読の方は、前号を先に読むと理解が増すでしょう。 稼働環境 すべてのリレーショナルデータベース もしも無限の資源があったなら 座標に整数のみを使う場合の限界 入れ子集合モデルの大きな欠点は、ノードを挿入（追加）するときに、自分より「右側」にある無関係なノードをもっと右へ
第5回 SQLで木構造を扱う～入れ子集合モデル （3）入れ子集合モデルにおける更新 | gihyo.jp
入れ子集合モデルにおける更新 次に、木構造の更新を行う例として基本的な、ノードの挿入と削除を取り上げます。本当はもっと多くの処理を行う方法がありますが、紙幅の都合上、代表的なものだけを取り上げます。興味を持った方は、参考資料に挙げたテキストをご覧ください。 リーフを追加する 木にノードを追加するときは、リーフとして追加するのか、それとも親として追加するのかを決める必要があります。今回は、処理として簡単なリーフとして追加することを考えましょう。たとえば、部下を持たない猪狩氏（2,3）の配下に新たな部下、国見氏を追加することを考えます。 今、猪狩氏の直径は1しかないので、そのままだと部下を持てません。そこで、まずは猪狩氏の円を「広げる」ことを考えます。国見氏を追加するためには、猪狩氏の右端座標より右の円の座標を一律2だけ大きくすればよいことがわかります。これは、リスト6のUPDATE文で可能で
第5回 SQLで木構造を扱う～入れ子集合モデル （2）入れ子集合モデルにおける検索 | gihyo.jp
入れ子集合モデルにおける検索 ルートとリーフを求める まず入れ子集合の検索で基本となる考え方を理解しましょう。それは「包含関係を調べる」ことです。 たとえば、ルート（ここで言う足立社長）とリーフ（猪狩、木島氏ら）を求めることを考えます。リーフの円は、自分の中に下位の円を一つも含まないという特性を持ちます。したがって、NOT EXISTSによって表現できます（リスト1、図5）。 リスト1 リーフの円を求める SELECT * FROM OrgChart Boss WHERE NOT EXISTS (SELECT * FROM OrgChart Workers WHERE Workers.lft > Boss.lft AND Workers.lft < Boss.rgt); 図5 リスト1の実行結果
第5回 SQLで木構造を扱う～入れ子集合モデル （1）入れ子集合モデルとは何か | gihyo.jp
はじめに 木構造と呼ばれるデータ構造の一種があります。1つのルート（根）と呼ばれるノードを始点として、（通常）複数のリーフ（葉）と呼ばれるノードまでを経路で結んでできるデータ構造です。その名のとおり自然界にある「木」の構造ですし、学校時代、確率の授業で樹状図を書いた経験のある人もいるでしょう。 この構造は、私たちの周囲にとてもたくさん存在します。家系図や組織図も木ですし、IT関連の例では、ヒープやRDBのインデックス、ディレクトリ（フォルダ）によるファイルシステムやXMLも木構造です。Webの掲示板でも、最初の書き込みをルートとしてそれに対してコメントがつけられ、そのコメントにまたコメントがつけられるというプロセスで木構造を形成します。ここでは1つの書き込みがノードになります。 このように、IT技術と木構造は切っても切れない関係にありますし、多くの分野で応用されてもいるのですが、実は長い
PyCon JP 2011 参加レポート［後編］ | gihyo.jp
8月27日（土）に開催された「PyCon JP 2011」の模様をお伝えします。後編では午後のセッションと、翌日に開催されたSprintについてレポートします。 Pythonで創るソーシャルゲームの未来 PyCon JP 2011のGold Sponserである株式会社gumiの堀内さんが、PythonとDjangoを使って創ったソーシャルゲームの技術的な解説と、ソーシャルゲーム業界の現状についてお話しをされました。 講演する堀内氏 広がるソーシャルゲーム市場 コンシューマ向けの市場が縮む一方で、ソーシャルゲームの市場はどんどん増え、映画産業やコンシューマゲーム産業と同等の規模になっているという堀内さん。しかしその一方、SAP（Social Application Provider）によるゲームは毎月数多く発表され、飽和状態になっているという現状も示しました。「決済システムのあるSNS内
第4回 対象を決め、問題を共有する | gihyo.jp
改善対象範囲を決めることはナンセンス 業務改善は、部門ごとにこじんまりと始める場合もあれば、部門全体、あるいは全社的に大掛かりに取り組む場合もあり、様々です。 本来、業務改善に「対象範囲を定める」という考え方はナンセンスだと考えています。その理由は2つあります。 まず、この段階では、なんとなく「業務改善をやるぞ～」と改善の狼煙が上がっているだけで、きちんと現状調査や業務分析を終えているわけではありません。つまり、どこが問題なのかわかっていない段階で対象を絞ることに意味がないというのが1つの理由です。2つ目の理由は、最初に対象を限定してしまうと、そこだけしかやらなくなることです。仕事は自部門だけで完結するものは意外と少なく、必ず、前工程と後工程が存在します。実際に改善が進んでいくと、前工程の業務から改善を行わないと、後工程だけでは改善の限界が見えてくることが多くあります。前工程の業務改善がな
第5回 Pacemakerを運用してみよう！［保守運用編(2)］ | gihyo.jp
ここでは、リソースのmonitor故障検知時の動作について説明します。Pacemakerはリソースのmonitor故障を検知した場合は、故障が発生したサーバにフェイルカウント（フラグ）を立て、リソースのフェイルオーバ処理を実施します。 図1 リソース故障 故障を発生させてみよう では、実際にリソース故障を発生させて、Pacemakerの動きを見てみましょう。今回はリソース故障を擬似的に起こすため、Pacemaker稼働中にhttpdを停止します。 # /etc/init.d/httpd stop httpd停止後crm_monコマンドを実行すると、pm01でhttpdのmonitor故障を検知したため、故障回数と故障内容が表示され、リソースがpm02にフェイルオーバしていることが確認できます。 Online: [ pm01 pm02 ] Resource Group: web vip (o
Pacemakerでかんたんクラスタリング体験してみよう！ 記事一覧 | gihyo.jp
第5回Pacemakerを運用してみよう！［保守運用編(2)］ 岡和田拓也 2011-05-12
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
第3章 型システム―型を用いた安全なプログラミング | gihyo.jp
第2回 冗長性症候群～条件分岐をUNIONで表現するなかれ | gihyo.jp
