タグ

ブックマーク / qiita.com (165)

  • 認定スクラムマスターの俺が正しいスクラムの理論をまとめてみた - Qiita

    はじめに いきなり質問ですいません。 「アジャイルの反対」ってなんでしょう? ・・・ ・・・ ・・・ もし、「ゆっくり」とか「ウォーターフォール」みたいな単語が頭に浮かんだ方はこの記事で学べることが多くあるかもしれません。 質問の答えは最後に記載しています。 参考文献 アジャイルソフトウェア開発宣言 アジャイル宣言の背後にある原則 スクラムガイド スクラム入門 Scrum Boot Camp 認定スクラムマスター研修 アジャイル スクラムの前にアジャイルに触れておく。 アジャイルとは アジャイルとは、より良い解決方法を探している状態である。 "状態"なので、よくある「アジャイル開発をやろう!」というのはおかしくて、振り返ってみて「あれはアジャイルだったなー」ってなるものだ。"Don't just do agile, be agile."という名言があるくらい。だから、極端な事を言うと、より

    認定スクラムマスターの俺が正しいスクラムの理論をまとめてみた - Qiita
  • CoreOS on Full IP fabric の検証 - Qiita

    何がしたいか サーバまでBGP接続したFull IP Fabric(Pure IP fabric??)上でコンテナ間ネットワークの動作を確認する. 結論として動作を確認できた. 背景 サーバエンドまでL3接続する事例が2018年から見受けられる cumulusも以前から関心があるようだ Baremetal 単独(linux) なら容易にできそう コンテナOSまでL3接続されているケース (1) (2) なぜサーバまでルーティングさせたいか?(ネットワークエンジニア目線) オープンスタンダードな技術であるBGPで経路を完全フルコントロール ダウンタイムなしでToRのメンテ/upgradeができる ネットワークインフラを常に最新の状態に維持できる MLAG的なL2のトラブルシューティングからの解放 ラックに縛られないIPアドレスアサインが可能 IPアドレス管理コストの低減、リソースの有効活用

    CoreOS on Full IP fabric の検証 - Qiita
  • CoreOS 入門 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? CoreOS 入門 CoreOS は Alex Polvi が設立した会社であり、OS、新しい Linux Distribution である。OSS で公開されている。 Polvi 氏といえば Rackspace に 買収された CloudKick を立ち上げ、その後も Rackspace 働いていたクラウドの専門家とも言えるだろう。 その Polvi 氏以外にも Googler や Linux 関連の人材、アドバイザーに Linux の stable branch のメンテナ を迎えるなど、Linux に関する知識がかなり豊富なメンバ

    CoreOS 入門 - Qiita
  • 特徴量選択のまとめ - Qiita

    Kaggle Advent Calendar その2の23日目の記事です。 私はkaggleを始めたばかりでテーブルデータのコンペはTitanicしかやったことがないため、特徴量をどのように選べばいいのかよくわからなかったのでまとめます。 特徴量選択手法のまとめ 特徴量選択とは、機械学習のモデルを使用する際に有効な特徴量の組み合わせを探索するプロセスのことを表しています。 特徴量選択を行うことによりいくつかのメリットが得られます。 変数を少なくすることで解釈性を上げる 計算コストを下げて、学習時間を短縮する 過適合を避けて汎用性を向上させる 高次元データによって、パフォーマンスが下がることを防ぐ。 特徴量選択の種類 特徴量選択の手法は大別して3つ存在します。 Filter Method Wrapper Method Emedded Method Filter Method Filter M

    特徴量選択のまとめ - Qiita
  • Google スライドで登壇用スライドを作る際のテクニック - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Googleスライドで作られたLT用スライドや社内の資料をみることがありますが、Googleスライドの強みを活かせてない作り方をしている方がとても多いです。 今回は私がGoogleスライドを書く上で意識しているテクニックを紹介します。 Qiitaなので 勉強会などで使う登壇用資料としてGoogleスライドを使う場合 という観点で書いてみました。 先日 Laravel/Vue.js勉強会#10 - connpass というイベントで筆者が実際に作ったスライドを元に解説していきます。 ※@jnchito さんが書かれた【動画付き・プレゼン初

    Google スライドで登壇用スライドを作る際のテクニック - Qiita
  • Ryzen1800xでキャッシュのスラッシング - Qiita

    ほそく 2019/2/19 追記: 当初"false sharing"と書いていたのはすべて誤りで実際は"キャッシュのスラッシング"でした。すいません。 はじめに 記事は、AMD社のRyzen1800x(以下1800xと記載)においてキャッシュのスラッシング(以下スラッシングと記載)が発生する様子を実験によって確かめた結果をまとめたものです。スラッシングとは、あるキャッシュメモリの内容を書き換えたとき、キャッシュメモリに保存されているデータの整合性を保つために、別のキャッシュメモリの内容を無効化する、というしくみが頻繁に繰り返されることです。 CPUの構成 1800xにはCCXと呼ばれる4コアを搭載したダイが2つ乗っています。ダイの中にはコアが4つ入っており、かつ、コアの中には2つのハイパースレッドが存在します。これを、Linuxが認識する16の論理CPUの番号と対応付けたのが次の表です

    Ryzen1800xでキャッシュのスラッシング - Qiita
  • XGBoost論文を丁寧に解説する(1) - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 勾配ブーストを用いた決定木(GBDT)によるクラス分類や回帰はデータ分析コンペでも非常によく使われています。 その中でも2016年に出されたXGBoostはLightGBMと並びよく使われている手法です。 性能が良いことで有名なXGBoost, LightGBMですが、モデル内部でどのような処理が行われているかよくわかっていなかったので論文を読んでみました。 式変形の省略が多く、またイメージしづらい箇所もあり、読みづらかったのですが 一度イメージできれば割とあっさり理解できます。 その体験を踏まえて、イメージ図を多く取り入れな

    XGBoost論文を丁寧に解説する(1) - Qiita
    takuya-a
    takuya-a 2019/08/12
  • Javadoc ドキュメンテーションコメントの書き方 - Qiita

    そもそも、そのメソッドの作成者が近くにいない場合、こういった確認すら行えません。結局、あるメソッドを使うために、そのメソッドの実装を時間をかけて分析することになるため、複数人で開発していることが、逆に開発効率を悪化させてしまいます。つまり、簡単に言うと、 「仕様の明確でないメソッドを作るのは迷惑行為です!」 ドキュメンテーションコメントによって API 仕様が明確にされていれば、こういった無駄なやりとりがなくなるため、開発効率もコード品質も上がります。下記のグラフは、開発メンバの人数と、生産性の関係を表しています。 仕様の不明確な API が溢れているプロジェクトに新しい実装メンバを投入しても、開発効率はうまく上がっていきません。すべての API の仕様が明確になっていれば、不具合が見つかった場合でも、各メソッドが何を実現すべきかが分かるので、別の人が実装を引き継いで修正していくことが可能

    Javadoc ドキュメンテーションコメントの書き方 - Qiita
  • mimalloc のメモリ管理 - Qiita

    Microsoft の mimalloc は面白い割り切り方で、小さいソースコードで高速なアロケータを実装しています。 確保するメモリブロックのサイズを、 Small (~8KiB), Large (~512KiB), Huge (512KiB~) の3つに分類し、 Small と Large は同じアルゴリズムで管理し、 Huge は OS 任せにして、 Small と Large は同じアルゴリズムをうまく利用しています。 基礎 OSはpage (x86では基 4KiB) ごとにメモリをプロセスに割り当てています。 しかしアプリケーションではずっと小さいメモリブロックが必要になることが多くあります。また、必要になるたびに毎回OSからメモリを割り当ててもらうのはパフォーマンスも悪いです。 mimalloc やその他の malloc 実装 (以降 malloc と呼びます) は OS か

    mimalloc のメモリ管理 - Qiita
  • Dockerでデバッグ対象のコンテナにツールを入れずにtcpdump/straceなどを使うワンライナー - Qiita

    はじめに Dockerであんなコンテナやこんなコンテナを動かしてると、なんかうまく動かなくて、デバッグのためにtcpdumpとかstraceなどのツールが使いたくなることが稀によくあります。 そんな時、デバッグ対象のコンテナ内にツールを一時的にインストールしちゃうというのが、まぁ簡単で分かりやすいんですが、デバッグ対象のコンテナを汚すのはできれば避けたいところです。 Dockerのコンテナの分離というのは、結局のところLinuxのリソースの名前空間の分離であるので、逆に同じ名前空間を共有すれば、デバッグ用に立てた隣のコンテナから、デバッグ対象のコンテナのネットワークやプロセスの状態を観察することも可能です。 また、docker buildDockerfileを標準入力から受け取ることもできるので、ワンライナーにしてデバッグ用のコンテナをシュッと呼び出せるようにしてみました。 TL;DR

    Dockerでデバッグ対象のコンテナにツールを入れずにtcpdump/straceなどを使うワンライナー - Qiita
  • Linux メモリ管理を理解したい - Qiita

    Linux カーネルのメモリ管理方法について、勉強したことをまとめる。 メモリ管理はハードウェアに強く依存するため、x86_64 かつ OS起動後に 64bitプロテクトモード に移行したあとに話を絞る。また、OS は CentOS7.6、カーネルは次のバージョンを利用する。 ]# cat /etc/redhat-release CentOS Linux release 7.6.1810 (Core) ]# uname -a Linux localhost.localdomain 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux 概要 ノイマン型アーキテクチャ コンピュータの基的な構成のひとつ。次の図が参考になる。 ほぼ全てのコンピュータが、このアーキ

    Linux メモリ管理を理解したい - Qiita
  • なるべく切れない回線のつくりかた(物理) - Qiita

    ※当然ながら、障害発生時はどのグレードでも0bpsになります 「なら専用線選んでおけばいいじゃん」と思うかもしれませんが、費用が圧倒的に違い、同じ帯域なら1段あがるごとに2~10倍ほどになります。たとえば5倍として、ベストエフォート100Mbpsで月額10万円なら、帯域確保は50万円、帯域保証は250万円、専用線は1000万円という差になってしまうでしょう。予算は有限ですから、むやみに高い品質を選んでしまうと帯域がとれないということになります。同じ予算であれば、1Gbpsベストエフォートがよいのか、200Mbps帯域確保がよいのかは場合によって異なるので、適切な選択をするべきです。 そして、ベストエフォートはベストエフォートでも、1Gbpsで100Mbpsしか出ないキャリアもあれば、1Gbpsで900Mbpsくらいを保証しているキャリアもあります。これは概ね値段に比例しますが、つまりベスト

    なるべく切れない回線のつくりかた(物理) - Qiita
    takuya-a
    takuya-a 2019/06/30
    よすぎる。L1以下の話は貴重。
  • 3分でできる!最高のDockerfileを書いたあとにやるべき1つのこと - Qiita

    概要 Dockerfileを書くためのベストプラクティスを読んで、ベストプラクティスなDockerfileを作った/作りたい人が対象です。 そのDockerfileで大丈夫かを3分でチェックできるツールをつくりました。Hadolintのような、単なるDockerfileのLinterではなく、ビルドしたイメージの中身まで細かく分析します。 通常のLinterでは原理的に不可能な、ベースイメージに存在している危険性も含めて調べることができます。 ←GitHubのStarもらえると嬉しいです。 Dockleの内部で使われているツールはTrivy, Vulsなどと同じなので、そのあたりを踏まえて、動作原理を別記事にまとめました。 人を震えさせるツール「Dockle」の仕組みを解説 なお、DockerHubで人気のコンテナに対して試した結果をサイトにして公開しています。操作方法もふくめて、別記事に

    3分でできる!最高のDockerfileを書いたあとにやるべき1つのこと - Qiita
  • 競技プログラミングにおけるXORのTips - Qiita

    はじめに この記事はCompetitive Programming (1) Advent Calendar 2018の9日目の記事となります. 競技プログラミングの題材の裏表に時折登場する,論理演算ならびにその(非負)整数型へのビットごとの拡張であるところの排他的論理和(XOR)について基的な事柄をまとめてみました. どうでもいいですが私のアイコンは競技プログラミングを始めた頃,あまりにXORが分からなかった哀しみからXORの回路記号を使用しています. 排他的論理和とは 論理演算としての排他的論理和は以下の真理値表であらわされます.0をfalse,1をtrueとして, 見慣れた論理積(AND)や論理和(OR)と比べると少し直感的には分かりにくいでしょうか. どうみるか Z/2Zの足し算 2で割った剰余の世界( $\mathbb{Z} / 2 \mathbb{Z}$ )の足し算と思うことが

    競技プログラミングにおけるXORのTips - Qiita
  • 2019年のワークフローエンジンまとめ - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 データパイプラインの管理にワークフローエンジンを導入したいのですが、今の要件に対してどれが合っているのか判断しきれない部分があるので整理してみました 最近の導入事例や発表をみるかぎりAirflow, Argo, Digdagあたりが人気なのかなと思います ワークフローエンジンとは ワークフローエンジンとは定期的なバッチ処理をうまく処理できるように、バッチ実行を管理してくれるソフトウェアのことです 古典的な実現方法としては適当なlinuxサーバーの上でcron実行させることが考えられますが、以下のような問題があります ジョブごとの依

    2019年のワークフローエンジンまとめ - Qiita
  • シェルの入出力制御あれこれ

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    シェルの入出力制御あれこれ
  • asm.js: 仕様と実装の今 - Qiita

    皆さんはasm.jsを覚えているでしょうか。4年ほど前(2013年)に登場してFirefoxで実装され、「C/C++で書かれたプログラムをWebで高速に実行できる!」みたいな話題になったやつです。その後WebAssemblyが登場したので、敢えてasm.jsに取り組む意味は薄くなりました。 しかしここでは懐古趣味として、asm.jsの現状を調査してみたいと思います。 仕様書 asm.jsの仕様書はここで見れます:http://asmjs.org/ (このサイトはどうやらGitHub Pagesでホストされているようで、GitHubリポジトリは https://github.com/dherman/asm.js です) この仕様書は「asm.js Working Draft -- 18 August 2014」となっており、結構古いです。これが「枯れている」ことを意味していればよかったのです

    asm.js: 仕様と実装の今 - Qiita
  • 64bitのOS + C言語でライブラリを使わずにHello Worldをしてみた - Qiita

    この記事は、OthloTech Advent Calendar 2017 8日目の記事として書かれています。 昨日から2日連続で自分が担当しています。昨日はモバイルに関してでしたが、今日は打って変わってC言語でカーネルに近づいていきたいと思います。 具体的にはOSで定義されているシステムコールのみを利用してHello Worldをしていきます。 対象読者 Linuxカーネルに興味がある人。 システムコールに興味がある人。 Hello Worldの出し方が気になる人。 ArchLinuxが好きな人。 記事の内容 ライブラリを利用せずに文字列を出力します。 システムコールの使い方をかんたんにまとめます。 動作環境 OS Arch Linux x86_64 カーネルバージョン 4.14.3-1-ARCH gcc 7.2.1 nasm 2.13.01 gdb 8.0.1 初めてのHello Wor

    64bitのOS + C言語でライブラリを使わずにHello Worldをしてみた - Qiita
  • VSCodeのオススメ拡張機能 24選 (とTipsを少し)

    1. vscode-icons アイコンがついて見やすくなる。 2. GitLens とにかく強い。 「コミット単位でのファイル比較」や「最新のコミット内容とそのコミッター表示」など色々してくれる。 git blameする手間なくなる。 3. Prettier コードのフォーマットは自動でやりましょう! 複数人のこだわりをうんたらするよりも、Prettierに委ねるのが楽。 関連のTipsはここ 4. Git History Git logが見やすい 5. Bracket Pair Colorizer カッコの対応を色付きで表示してくれる。 ものすごく読みやすくなって最高&最高!! なおBeta版ですが、後継となるBracket Pair Colorizer 2も出ています。 6. Settings Sync どこでも同じ設定で使いたい人には便利。 ⇧ + ⌥ + U/D で設定をアップロ

    VSCodeのオススメ拡張機能 24選 (とTipsを少し)
  • "call by reference"ではない動作を「参照渡し」と言っている記事まとめ - Qiita

    C++、C#、PHP等には"call by reference"という機能があります。ですが、この"call by reference"ではない動作を「参照渡し」と言っている記事をまとめました。対象には表記揺れにすぎない「参照呼び」や「参照呼び出し」も含めています。 他にもある、とか、実は否定しているとかあればコメントや修正依頼をください。ただし、追記や脚注など目立たない形で「実はそうは言わない」などと補足があったり、コメント等でそのような指摘があっても、全ての読者がそこまで細かく見るとは限らないため、除外しません。つまり、厳密には違うとか、機能ではなく動作のことを言っているとか色々言い訳を付けていても、表面だけ読んでいると「『参照渡し』と言っても良い」と読み手が感じられそうであれば、対象としています。 "call by reference"な動作とは? 定義や詳しい動作の解説はここではし

    "call by reference"ではない動作を「参照渡し」と言っている記事まとめ - Qiita