スクラムマスターチェックリストの最新版が翻訳されました - Qiita
はじめに スクラムマスターチェックリストの最新版が公開されました。 翻訳に関われたので、報知の意味もかねて、Qiitaで展開しておきます。 以下は抜粋版です。チェック項目を上から順に5個ずつに抜粋してます。 是非、本体のスクラムマスターチェックリストをご覧ください。 注意事項 この記事はあくまで、2018/12/18版の話でしか無いです。 最新版の確認は上記リンクをご覧ください。 スクラムマスターチェックリスト（抜粋版） フルタイムで関わっていますか？ “まずまずな” スクラムマスター は、一度に2つまたは3つのチームを受け持ちます。 スクラムマスター の役割を「ミーティングの主催」、「タイムボックスの管理」、および「チームから報告された問題への対処」に限定すれば、パートタイマーながらなんとか上手くやることができるでしょう。 そのような状態であってもきっと、チームは組織のベースライン（スク
CSS フレームワークを Vue.js のコンポーネントにする方法 - mya-ake com
この記事についてこの記事はVue.js #2 Advent Calendar 2018 - Qiitaの 20 日目の記事です。 この記事では Google が提供しているマテリアルデザインの CSS フレームワークであるMaterial Componentsを Vue.js のコンポーネントにしていく話を書いています。 その過程で Vue.js におけるコンポーネントを作るときの要点なども一緒に書いてます。 バージョンなど Vue.js: 2.5.21 Vue CLI: 3.2.1 Material Components: 0.42.x サンプルリポジトリhttps://github.com/mya-ake/vuepress-plugin-component-catalog/tree/master/example/material-components-web アウトライン Materi
AOJ 1391 Emergency Evacuation (ICPC Asia 2018 C) - けんちょんの競プロ精進記録
結構好き！ソートすることが本質の問題としていい感じな気がする。 問題へのリンク 問題概要 下図のような「中央の通路とそこから横に伸びた乗り物に乗客がどこにいるかを表した地図」が与えられる。乗客は 人いる。各乗客は 1 秒かけて 1 マス移動できる。ただし、 中央の通路以外は横にしか移動できない 他の乗客のいるマスには移動できない 全員が外に出られるまでの最小回数を求めよ。 考えたこと 一見大変そう。同じマスに次ステップで複数の乗客が移動したい状況になったときに、どの乗客を優先したらいいのか。。。 とりあえず、「移動待機」はあまり考えたくないので、各乗客は最初に移動を始めるまでスタート地点で待機するものとして考えるものとする。そして一度移動を始めたら、もうゴールまで真っしぐらに移動するものとする。 そして重要な考察として ゴールするタイミングが異なる乗客間で、同じタイミングで同じマスへ移動し
MySQLのスローログ関連のパラメーターが評価される順番
別のエントリー書いてたら、前に誰かに聞かれたなと思ったのでメモ。 スローログが出力されるかどうかの判定は、 1. スローログが有効化されていること 2. log_slow_admin_statements = 0 で除外されるステートメントではないこと 3. (long_query_time以上の時間がかかっている) OR (log_queries_not_using_indexes にマッチする) クエリーであること 4. クエリーのExaminedが min_examined_row_limit 以上であること 5. log_queries_not_using_indexesにマッチしていることが決まっている場合、log_throttle_queries_not_using_indexes で設定された以上の時間が経っているかどうか 意外と4. が知られてなくて、どんなに時間がかかって
実録MySQLのチューニング 春の陣 - （ひ）メモ
long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 「実録」の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 「あれを見た方がいい」とか「これをあーした方がいい」とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです！ 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソース食い潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,
QuickCheck
QuickCheck は凄く面白いので、Haskeller なら使いこなしたいところです。しかしながら、慣れるまでは結構難しいので実例を見ながら使い方を理解していきたいと思います。 パッケージのインストール hspec の時と同様に package.yaml の tests に QuickCheck パッケージを追記します。quickcheck では無いのでスペルミスに注意してください。 tests: PFAD-test: main: Spec.hs source-dirs: test ghc-options: - -threaded - -rtsopts - -with-rtsopts=-N dependencies: - PFAD - hspec - QuickCheck # この行を追記 QuickCheck パッケージは頻繁に更新されるのでバージョンごとに書き方が違う場合があります
How to contribute to Nuxt.js - エムスリーテックブログ
この記事はエムスリー Advent Calendar 2018 の20日目の記事です。 エンジニアリンググループの@suusan2goです。現在はAIチームで、機械学習以外のことを色々やっています。 エムスリーではVue.jsを様々なプロジェクトで活用しており、今年開催されたVue Fes Japan 2018のSILVERスポンサーとBEERスポンサーもやっていました！ エムスリーでのNuxt.js、Vue.jsの活用については以下の記事をご参照ください。 employment.en-japan.com 私も今年はNuxt.jsに大変お世話になったので何かコミュニティに貢献したいと思い、先日Nuxt.jsにコントリビュートしたのでそのお話をします。How to contribute to Nuxt.js と大げさなタイトルをつけてますが、他のOSSと大きく異なることはないのでそんなに身構
ワイが個人的に便利だと思っていてよく使っているJavaScriptモジュール(npm)たち - Qiita
この記事はLIFULL Advent Calendar 2018の19日目の記事とされている恐れがあります 謝罪 wasmとSWとReactのフロント全部盛りマンやります 🙋 部署が代わり開発領域も変わってしまい、ジェイクエィリでDOM操作をし過ぎた反動でフロントに関する知識を忘却してしまいました。誠に申し訳ございません。 どアタマでの謝罪により万に一人に楽しみにされていた方がいらっしゃった時の可能性を潰しておきます。 ここから本題 ここ1年の中で しまくったgithubリポジトリを年末調整すると同時に、 使っていて個人的に便利だなと思っているものを簡単に紹介しようと思います。 React 魂のviewフレームワーク Facebook謹製 Redux Flux思想の状態管理ライブラリ React使うならだいたい使うはず storybook インタラクティブなUIコンポーネント(React
Lambda Custom Runtimes上でbashを対話的に操作してその内部仕様を丸裸にする - misc.tech.notes
この記事は AWS Lambda Custom Runtimes芸人 Advent Calendar 2018 の19日目です。 qiita.com これは何？ 「Lambdaの中に入ってみたいと思ったことはありませんか？」これはそんな歪んだ願望を叶える試みです。と同時にそれを足がかりにAWS Lambdaというシステムをより深く理解するための検証とその結果を記したものです。 ちなみに毎年恒例？のLambdaのリバースエンジニアリング(?)シリーズです。 2016年 marcy.hatenablog.com 2017年 marcy.hatenablog.com Lambda Custom Runtimesとは Lambda Custom Runtimesは一般的にはAWS Lambdaが公式に対応していないプログラミング言語のRuntimeを動かすための機能です。仕様は以下の通り。 doc
Rust で Erlang 処理系を実装してみている
今年の 9 月あたりから、 Rust で Erlang の処理系を実装してみています。まともに試せるほど進んでないんですが、気分的に年内に一区切りつけたいので公開しておきます。リポジトリはこちら。 https://github.com/szktty/starlight みています、というのはもちろん思いつきだからです。なにぶん Erlang は適用分野がベリーハードなミッションクリティカルシステムしかなく、あらゆる性能やメリットが Erlang VM (BEAM) を超えなければ非公式処理系の用途はありません。 かといって最初から諦めてもいませんが、業務で Erlang に関わらなくなったら or 開発に疲れたら自然消滅すると思います。すでにわりと疲れている。 進捗状況「速くなるのか？」「軽量プロセスは？」などの疑問に興味津々の皆様、すいません。全然ご期待に応えられません。本当に同梱のごく
退職への向き合い方 - yo-log
本記事はEngineering Manager Advent Calendar 2018の19日目です。 エンジニアリングマネージャーをやっているとメンバーの退職というイベントが発生することがあるかと思います。 この退職というイベントはエンジニアリングマネージャーにとってはとても悩ましくどう対処すべきなのかが難しいイベントでもあるにも関わらずテーマがテーマだけにあまり知見が共有されない話題のように思います。 そこで今回は退職についてどう向き合うべきなのかを私の観点から書きたいと思います。 退職云々の前に普段から考えておくべきこと メンバーがいなくなるとどうなるかを考えて組織戦略を考える 退職に関わらず、怪我・病気や、ライフイベントなどでチームからしばらく離れることがあると思います。 そういった場合にチームのアウトプットにどのような影響があるか、その影響は事業の持続性、システムの持続性にどの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ECSの辛いところ - Speaker Deck