追記(2016/10/03) リリースノート眺めてたらv1.6.0でスライド対応！ 勉強会のスライドとかおけるように！ https://github.com/support-project/knowledge/releases やりたいこと Qiitaってすばらしいんだけど、社内のノウハウ蓄積にも使いたい Qiita::Team使いたいけど、開発人員が多すぎでコスト高＆保守的な会社なので許可がおりない… 使ったもの knowledge Docker Toolbox 環境 Windows7 (Corei5 8GBRAM/会社支給品) ちゃちゃっと整備 とりあえず自分用に欲しかったので 適当なディレクトリに永続化用のディレクトリを用意して、docker-compose.ymlを作る $ mkdir -p ~/docker/knowledge # docker-compose.ymlを置くディレ

ISO9001を帳票ワークフローシステムと見なしてRedmineで運用してみるアイデアをラフなメモ書き。 【参考】 ワークフローを利用したＱＭＳ（品質マネジメントシステム）の効果性・効率性の改善 概要 | ISO 9001（品質） | ISO認証 | 日本品質保証機構（JQA） ISO9001のメリット・デメリットとは？ | ISO取得で成功する。 ISO内部監査（基本編） - ISO内部監査の改善術 【1】製造業なら、どこの会社でもISO9001は導入していて、何らかのQMS(品質マネジメントシステム)が稼働しているだろう。 「ウチは品質管理をきちんとやってます」と標榜するには、客観的な資格みたいなものが必要で、それが世界標準ルールであるISO9001だからだ。 昔の日本の製造業では、手作りで自分たちの品質管理の手順を標準化しており、日本製品の品質向上に一役買っていた。 しかし、ISO9

JAXAのRedmineモデル、JAXAのRedmine運用ルールを読み直しながら、考えたことをメモ。 【参考】 JAXAのRedmineモデル～Redmineはレイヤ構造になっている: プログラマの思索 JAXAのRedmine運用事例の分析～「ロール設定のORルール」と「カスタムフィールド設定のANDルール」: プログラマの思索 【1】JAXAのRedmineモデルでは、Redmineの機能は、利用者の物理層とシステム管理者の論理層に分かれていて、細かく分ければ6層になると思う。 それぞれのレイヤの依存関係を紐解いた後、JAXAのRedmine運用ルール「ロールのORルール」「CFのANDルール」が編み出された。 その運用ルールを実施するには、幾つかの前提となる運用ルール、またはRedmineの設定があるのではないか、と考えている。 下記の3つの目的で、隠れている運用ルールを洗い出して

負荷試験対策ミーティング ここでは、チームメンバーを集めて、システム要件の再確認と、バックエンドのアーキテクチャを再確認をまず行います。すなわち、「求められているもの=要件」と、「提供できるもの=アーキテクチャ」の確認です。ここの認識が揃っていないと、的はずれな負荷試験を実施してしまうことになりかねません。立場や役割にかかわらず、サービス全体として考えるべきです。 負荷試験の目的 負荷試験を行うことによって、何を示したいのか決めます。今回は、以下の目的を定めます。 サービスリリース後、想定されるピーク時のリクエストを受けた場合でも、問題なく稼働を続けられることを確認する システムのスループット限界値を確認する 負荷試験の観点 たいていのWebシステムの場合、昼夜を問わず稼働し続けるものとなるでしょう。今回例にとったシステムも24時間365日、リクエストを受け付けるものとします。この場合、観

注意：この記事は古いです。2016年06月06日に書いた記事です。 2017/04/14 追記： Chrome59から正式にヘッドレスモードが搭載されます。 ヘッドレスモードではPhantomJSなどのようにJavaScriptでヘッドレスブラウザを制御することも可能です。 https://chromium.googlesource.com/chromium/src/+/master/headless/ 2017/06/07 追記： NightmareJS風に操作できるライブラリをリリースしています。 ヘッドレスChromeをもっとも簡単に操作できると思われるNightmareJS風ライブラリ http://qiita.com/devneko/items/3689b46fc2bcdb8121a8 先日、Googleの人が「Headless Chrome is coming so soon」

Googleが新たに提唱するProgressive Web Appsの新たな開発パターン「PRPL」とは？ 小松 健作（NTTコミュニケーションズ） 「Google I/O 2016」では、これからのWebアプリ開発パターンとして提唱しているPWApps(Progressive Web Apps）について多くのプレゼンテーションがなされました。 PWAppsとは、最新のWeb技術を有効に活用し、漸進的（Progressive）に高度なユーザー体験を提供しようとする概念です。このPWAppsの概念を具体化する一つの手法として、「PRPL」（パープル）と名付けられた開発・提供パターンが提案されました。本稿ではこのPRPLを解説するとともに、その有効性や課題点を考察します。 本稿は、Google I/O 2016の二つのセッションに関する、解説記事です。 Polymer and Progress

数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM

こんにちは、つっちーです。収益がやっと10万円超えました。 今回は、一つの節目として、どうしても書いておきたかったので、書いておこうと思います。 最初に言っておきますが、10万円は誰でも可能です。 出来る限り包み隠さず書いていこうと思いますので、収益をあげたいと思っている人で、これからブログ始めるという人や伸び悩んでいるという人の参考になれば幸いです。 ※ただし、10万円を超える収益を持っているブログはごまんといます。自身も7桁は超えたので目指せ8桁です！ はじめに ネット上では惜しげもなくノウハウを公開しているところもありますし、詐欺まがいの怪しさ満載のところもあります。ネットに知識のない人はその見極めが出来なかったり、コロッと騙されることもあるかもしれません。結局のところ自分自身で見極めるしかないので、是非色んなサイトを見て下さい。その中に正解があります。 また、収益と言っても、サロン

IT業界を中心に、いまやSlackは大人気のコミュニケーションツールです。シンプルでスタイリッシュなUI、Channel機能、充実した検索機能など、魅力的な機能がたくさん。数ある機能の中でも、外部サービスとの連携ができるインテグレーション機能は特に役立ちます。 本記事では、このインテグレーションについて、基本的な使い方やオススメの外部サービスをご紹介しています。技術系のサービスだけでなく、スケジュールやタスク管理など、日常的な業務に使えるサービスについても取り上げていますので参考にしてみてください。 Slackの始め方については以下を参考にしてみてください。 参考： 多くの企業が導入済み！便利なコミュニケーションツール「Slack」の使い方 外部サービスを連携する手順 本題に入る前に、外部サービスを連携する手順についてご紹介しておきましょう。タスク管理サービスのTrelloを題材にして、話

「ニコニコ超開示」祭り、身代金要求のハッカーが何らかの理由で闇サイトのKADOKAWA流出情報を削除もしくは日本からの閲覧を制限

背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること

まいど、ワロリンスです おかげさまでブログやり始めて1年が経ってしまいますた 私とTwitterなどで絡んでくれてる方、ブログ読んでくれてる方、いつもいつも本当にありがとうぽよんね！ 1年間振り返ってみて ブログ開設：2015年7月18日 記事数：212記事 読者数：はてな331人＋feedly208人（2016年7月1日現在） 何度か書いていますが、私がブログやり始めた理由は「お金」これに尽きます もちろん１人勝ちしたいわけじゃなく「参考にしてくれたらいいな」という気持ちもあるので、WINWINな関係になるよう心がけてやってきました このブログの前に実はFC2で3年ほどゲームアプリの雑記ブログをやっていたんです 当時はアフィリエイトは全然やってなく(アドセンスは貼ってた)完全なる自己満ブログ 更新も月1回あるかどうかの放置ブログだったんで途中で飽きて、めんどくさいからもういいや〜と1回削