タグ

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

  • 「ゼロトラストネットワーク」を読んだので要約する - Qiita

    目的 少しずつ実際のソリューションが登場しつつあるゼロトラストネットワークについて、その成り立ちや設計思想、セキュリティの構成や実運用の課題について解説された「ゼロトラストネットワーク」の要約をしてみます。 特に、組織のネットワーク構築や運用を担当する情報システム部門の担当であれば、今後のネットワークの在り方を考える上で指針になる一冊だと思います。 https://www.oreilly.co.jp/books/9784873118888/ ゼロトラストネットワークの成り立ちと概要 1967年まで遡り、主に軍事・学術目的で通信するために、各ノードがパケットを交換しあうARPANETというネットワーク設計が考案されました。今のインターネットの前身です。 設立した当初はネットワーク上のノードの身元がほとんど判別できる状態だったので情報の漏えいや改ざんを気にする必要がなかったのですが、ネットワー

    「ゼロトラストネットワーク」を読んだので要約する - Qiita
  • テックリードになって気をつけていること - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? フューチャーアドベントカレンダー2020の24日目です。 はじめに フューチャーに入ってテックリード(社内だとアーキリーダーと呼ぶことも多い)のような役割をし始めて4,5年ほど経過しました。 いくつかの案件を回して自分なりに汎化・パターン化してきた部分も増えてきたので、気を付けていることをまとめました。 テックリードとは エンジニアのためのマネジメントキャリアパス――テックリードからCTOまでマネジメントスキル向上ガイド によると、以下のように説明されています。 テックリードはエンジニアの階層におけるランクのひとつではなく、シニアのレベ

    テックリードになって気をつけていること - Qiita
  • 結局、Go言語をやめる理由はなかった件 - Qiita

    この記事は Go 2 Advent Calendar 14日目の穴埋め記事です。 はじめに @okdyy75 さんによる Go 5 Advent Calendar 14日目の の記事「だから僕はGo言語を辞めた」 が「ベンチマークっていうのはこうやるんだよ」というのを説明するために反面教師的な意味で良い教材だと思ったので、反証記事を書きたいと思います。 ベンチマークを取りながらコードを改善して、最終的にGoは遅くないからやめる必要はないということ、そして、なぜ遅いという結論になってしまったのかを掘り下げていきたいと思います。 下準備 幸いなことに、ベンチマークのソースコードがGitHubにある ので、こちらを実行しながら問題点を改善していきましょう。 ちゃんとコードが上がっているのは素晴らしいですね! 一方で、元記事には測定環境が明記されていませんでしたので、同じ環境で測定することはできま

    結局、Go言語をやめる理由はなかった件 - Qiita
  • 技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための1種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。

    技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
  • Terraform職人再入門2020 - Qiita

    はじめに この記事は CrowdWorks Advent Calendar 2020 の11日目の記事です。 3年ほど前に、「Terraform職人入門」という記事を書きました↓ Terraform職人入門: 日々の運用で学んだ知見を淡々とまとめる この記事は多くの人に読んでいただきましたが、当時のTerraformのバージョンはv0.11で、2019年5月にリリースされたv0.12以降のHCL2にも対応しておらず、またその後の周辺のエコシステムの変化などもあり、情報がずいぶん古くなってしまった感は否めません。また当時紹介した解決方法よりも、今ならよりよい解決策を知っているものもあります。未だに過去の記事にLGTMをもらうたびに、うれしさ半分と同時に、なんとなく心苦しい気持ち半分でした。 というわけで、「Terraform職人再入門2020」と題して、当時から差分のあった箇所を中心に、運用

    Terraform職人再入門2020 - Qiita
  • エンジニアの評価制度を考える - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ブルベースの堀内です。 エンジニアチームのマネージャーを担当しております。 ブルベース株式会社は2020年3月に人材事業、受託開発事業、自社サービスの新規開発・運用保守を担う会社として発足しました。発足に伴いエンジニアの評価制度を考える機会をいただいたものの、非常に頭を悩ませました。通常業務をこなしつつ、評価制度を検討したため、半年もの時間がかかりました。 皆様の参考になればと思い、どのような思いで検討したかを述べさせていただきます。 エンジニア評価制度の必要性と方向性 エンジニアの評価制度を策定するにあたり、なぜ必要なのかを改めて考え

    エンジニアの評価制度を考える - Qiita
    a_bicky
    a_bicky 2020/12/06
  • パケットキャプチャツールをつくる - Qiita

    はじめに ネットワークと C 言語の勉強を兼ねて、簡易的なパケットキャプチャツールをつくってみました。参考にしたのは「ルーター自作でわかるパケットの流れ」という書籍です。 表紙に書かれている「ネットワークはどのようにつながるのかパケットの気持ちになって考えてみたことはありますか?」というコメントにが若干引いておりましたが、こういったディープな内容のは中々ないので有り難かったです。なお、このはタイトルのとおりルータを自作することがゴールになっていて、パケットキャプチャツールの作成はそのための練習という位置付けです。 また、特別講座 ネットワークプログラミング ( FWをつくろう )というサイトも非常に参考になりました。図入りで説明されていてとても分かりやすかったです。 ちなみに、C 言語は大学の時に少しかじったものの、ほぼ初心者に近い状態だったので Udemy の「イメージでわかる!基

    パケットキャプチャツールをつくる - Qiita
  • Emacs の起動時間を""詰める"" - Qiita

    おしらせ : 長い記事は形式になっていた方が読みやすそうなので、 Zenn に お引越し してみました。ここにも記事は残しておきますが、最新版はあちらになります。 Emacs はプラグインを増やしていくと起動に何秒もかかって重い、という話をみることがあります。 しかし、考えてみれば Emacs には 1000 以上の Emacs Lisp ファイルが初めから同梱されているわけで、そこに数十のプラグインを足しただけで爆裂に遅くなるのは、なにか設定にも問題がある気がします。 この記事では、 Emacs の起動時間を詰めるために今までに試してきた、小技や大技たちを紹介します。 自分用にメンテしているフレームワーク setup.el で活用しているテクニックが主なので、そちらを試してみて欲しい気持ちもありますが、それぞれの Tips 単体でも価値があると思うので記事にもまとめてみることにしました

    Emacs の起動時間を""詰める"" - Qiita
  • Self-Attentionを全面的に使った新時代の画像認識モデルを解説! - Qiita

    08/31 (2020): 投稿 08/31 (2020): 「畳み込みを一切使わない」という記述に関して、ご指摘を受けましたので追記いたしました。線形変換においては「チャネル間の加重和である1x1畳み込み」を実装では用いています。 08/31 (2020): 論文で提案されているモデルの呼称に関して認識が誤っていたためタイトルおよび文章を一部修正しました。 言葉足らずの部分や勘違いをしている部分があるかと思いますが、ご指摘等をいただけますと大変ありがたいです。よろしくお願いします!(ツイッター:@omiita_atiimo) Self-Attentionを全面的に使った新時代の画像認識モデルを解説! 近年の自然言語処理のブレイクスルーに大きく貢献したものといえば、やはりTransformerだと思います。そこからさらにBERTが生まれ、自然言語の認識能力などを測るGLUE Benchm

    Self-Attentionを全面的に使った新時代の画像認識モデルを解説! - Qiita
  • GitHubのREADMEをサクッと高品質で書けるサービス作ってみました。 - Qiita

    みなさんは GitHub でオープソースソフトウェア(OSS)を開発して公開する時、README をどのように書いているでしょうか? GitHub が自動で作ってくれる README に含まれるのはタイトルだけですし、OSS 開発初心者の場合、そもそも README に何を含めるべきかわからないという方もいらっしゃるのではないでしょうか?OSS 開発に慣れている方でも、コードを書くのはいいけれど README を書くのは面倒だと思ったことはありませんか?今回はそんな README 難民の方々向けの Web サービスを作ってみました。 LEADYOU - README Generator Web サイトへ 使い方 使い方は簡単です。トップページで GitHub の Public リポジトリの URL を入力してNext Stepボタンを押すと、README に書くべき内容ごとにフィールドが設

    GitHubのREADMEをサクッと高品質で書けるサービス作ってみました。 - Qiita
    a_bicky
    a_bicky 2020/08/23
  • 開発体験を変える! Chrome DevTools Tips 7選 - Qiita

    最近Chrome DevToolsについて調べていて発見した便利機能を紹介します。 誰もが使える最高便利な開発マシンChrome DevToolsを使いこなして開発体験を変えましょう! 1. $0で選択中のDOM要素の取得 特定の要素に何かしたいという時には、要素のIDやclassを確認してConsoleでdocument.querySelector("#xxx")で取得するというのが一般的だと思います。実はそれはカーソル選択と$0で代替できます。 Classや、IDがついていない特定のDOMを取得したい時とかにも使えるので地味に便利です。 手順 カーソルで取得したい要素を選ぶ Consoleタブで$0を入力 最近知ったChrome DevToolsの便利機能① $0 での選択中のDOM要素取得 Elementsタブで選択状態のDOM要素は、Console上で $0 を入力することで取得で

    開発体験を変える! Chrome DevTools Tips 7選 - Qiita
  • MySQLの接続についてdatabase.ymlに書ける設定 - Qiita

    Railsアプリでデータベースに接続する設定はconfig/database.ymlに書いたり、DATABASE_URL環境変数を設定したりして、与える。database.ymlに書ける内容についての情報がいまいちまとまっていない感じで、調べるのに苦労したのでまとめておく。 設定の例 Rails Guidesに書かれたMySQL設定の例を見ると、こんな感じ。 実用上は、大体ここに書いてあることを設定すればそれで良い。 他にありがちな設定としては、socketではなくhostとportを使うこともあったり、sslcaのようなオプションを渡したりすることだと思う。 設定の分類 ActiveRecordの設定は、 Connection poolに関するもの MySQLの接続に関するもの の二つがある。 Connection poolの設定 Connection poolの設定には、pool、id

    MySQLの接続についてdatabase.ymlに書ける設定 - 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? はじめに エンジニアにとって、仕様書などの技術的な文章を書くこと(テクニカルライティングとも言います)は避けて通れません。ただ20年来多くのエンジニアの方々と同僚として接してきて思うことは、エンジニアの方の中には「文章を書く」ということに苦手意識がある方が一定数いるということです。 でもこの「テクニカルライティング」のスキルは、才能というよりは一種の「技能」だと思うんです。ある一定の原理原則を理解して実践を繰り返すことで、必ず一定レベルで習得できるものだと著者は信じています。 もしこのテクニカルライティングの原理原則をまだ体系的に学習し

    Google社のテクニカルライティングの基礎教育資料がとても良かったので紹介したい - Qiita
  • GitHub Actions: tagでfilter - Qiita

    概要 先日GitHub Actionsの設定ファイルの書き方が変わりました。 これまでは独自のフォーマットだったものが、YAMLで設定するようになりました。 tagでfilterする方法を調べたのでメモします。 やりたいこと リポジトリにpushされたら ユニットテストの実行 ユニットテストをパスした かつ vで始まるtagがpushされた場合、リリースする をやりたい。 普段はpushしたらその都度ユニットテストが実行され、tagもpushした場合のみリリースするということをやりたい 旧GitHub Actions設定ファイル Node.jsのプロジェクトでnpm publishまでやる例 workflow "Build, Test, and Publish" { on = "push" resolves = ["Publish"] } action "Build" { uses = "

    GitHub Actions: tagでfilter - Qiita
    a_bicky
    a_bicky 2020/05/25
  • gitで特定のcommitバージョン/リビジョンを指すコレをなんと呼ぶか問題 - Qiita

    これ ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ commit 3a8461e04c04ed94a64df5d2cd7adbe764a2b8d8 Author: bigwheel <hogehoge@gmail.com> Date: Tue May 2 02:50:19 2017 +0900 Fix Process output method 同僚に「ちょっとそのコミットのこれ、slack DMで送ってー」なんて言うとき、あると思います。 これをなんと呼ぶか。 自分はコミットハッシュないしコミットIDと呼んできましたがどうやら正しい呼称ではなさそう。 先に結論 Git manual的には コミットのSHA-1 ないし コミット(オブジェクト)?の(オブジェクト名|SHA-1)が正しい。 もしくはPro Git - Bookには以下の表現もある。 コミッ

    gitで特定のcommitバージョン/リビジョンを指すコレをなんと呼ぶか問題 - Qiita
    a_bicky
    a_bicky 2020/04/04
  • Goでテストを書く(テストの実装パターン集) - Qiita

    Goでテストを書くお話です。 基的なところから、応用的なテストの書き方(パターン?)をまとめておくことにしました。 ポイントを先に列挙します: テストのエラーメッセージは丁寧に書こう テーブルテストを活用してパターンを整理しながら網羅しよう t.Runをつかって大きなテストを分割しよう t.Helperをつかってテストエラーの箇所をわかりやすくしよう テスト用のデータは testdata ディレクトリに置こう Setup/Teardownをうまく書いてテストの見通しをよくしよう 等 では、見ていきましょう。 実装 tenntennさんの もっと楽して式の評価器を作る を参考に、シンプルな計算機能を持つ関数(Compute)を書いて、それをテストしてみます(みんなはテストから書こう)。 実装コード: package calc import ( "go/token" "go/types" )

    Goでテストを書く(テストの実装パターン集) - Qiita
  • Goの新しいerrors パッケージ xerrors - Qiita

    先日 xerrors パッケージがリリースされました。 このパッケージは、Proposal: Go 2 Error Inspection で提案されているものをGo1向けに外部ライブラリとして試験的に実装したものです。 Goの標準ライブラリではありませんが、Go公式がメンテナンスをしています。 このパッケージができた背景は、今まで多くのGoエンジニアは下位層のエラーの情報を伝播させるために pkg/errors パッケージ などの外部ライブラリを利用していました。この手法が開発者の間で普及したため標準ライブラリで正式に検討を始めることとなりました。 2019/9/4更新 Go 1.13では %w でのラップや Is メソッド、 As メソッドは正式に導入されました。 しかし%+w や %+v によるスタックトレースの表示の採用は見送られました。 スタックトレースの表示が必要な場合はxerr

    Goの新しいerrors パッケージ xerrors - Qiita
  • GitHubで自動生成コードをDiffに表示しない方法 - Qiita

    結論 ここに書いてある 注意事項 だいぶ懐かしい記事ですが…突然、「Diffに表示しないなんてGitHubの価値を損なうものだから記事を非公開にするべきだ」というご指摘をいただいたので、念のため追記。 Diffに表示しない、ってことは当然PRにも見えません。 レビューされない怪しいコードが紛れ込むリスクを抱えることになります。 せいぜい自動生成分だけを非表示にして、CIの中で再生成、差分が出ないチェックを入れるなど、ガードの手は考えておいたほうが良いでしょうね。はい。ご利用は計画的に。 背景 mockeryだったり、swagger-codegenだったり、go-bindataだったり… GitHub上に自動生成されたコードを載せている場合、PRやcommitの詳細画面でDiffが邪魔になることがあります。 .gitignoreでそもそも自動生成コードをリポジトリに載せない generate

    GitHubで自動生成コードをDiffに表示しない方法 - Qiita
    a_bicky
    a_bicky 2020/03/21
    .gitattributesでlinguist-generated=trueを指定しなくても(https://help.github.com/en/github/administering-a-repository/customizing-how-changed-files-appear-on-github)、よしなに判定してくれてるっぽい
  • GoでAWS SDKを叩くCLIツールを作ってリリースするまでの流れ(aws-sdk-go+cobra+viper+gox+ghr) - Qiita

    はじめに 最近CLIツールを作るのはGoで書くのが流行りっぽいので、GoでCLIツールを作ってみたメモ。 お題としては、aws-sdk-goAWSAPI叩く myaws という自作コマンドを作って、 サブコマンドとしてEC2インスタンスの一覧を取得する myaws ec2 ls コマンドを作ってみる。 自作コマンドへの引数フラグの渡し方、設定ファイルの読み込み方などCLIツールとして必要そうなトピックにも触れつつ、最終的にビルドしてできたバイナリをGitHubのReleaseページからダウンロードできるようにするところまで説明する。 これからGoで何かCLIツールを作ってみようと思ってる人の参考になれば幸いです。 作ったもの 作ったものはGitHubにあげておいた。 https://github.com/minamijoyo/myaws あとで機能追加したりしてコードが変わっちゃうと思

    GoでAWS SDKを叩くCLIツールを作ってリリースするまでの流れ(aws-sdk-go+cobra+viper+gox+ghr) - Qiita
  • Go言語のFunctional Option Pattern - Qiita

    ###オプション パッケージを作る際、柔軟性を持たせるためにオプションを持たせたい時がしばしばあります。 しかしオプションは知っての通り設定しないことが少なくありません。 単にコンストラクタに並べるようでは無用な複雑さをはらむことになります。 JavaなどではOptional Parameterなどのように、デフォルト値が指定できる機能があります。 機能の厳選されたgo言語ではそのような機能はありませんが、 "Self Referential Functions Design"というテクニックがあり、 それについての記事がRob Pike氏の記事を筆頭にいくつか説明されています。 オプションと相性が非常に良いため、合わせて"Functional Option Pattern"とも呼ばれています。 Dave Cheney氏の記事を参考におおまかに説明したいと思います。 ###様々な解決策 あ

    Go言語のFunctional Option Pattern - Qiita