タグ

2019年2月25日のブックマーク (14件)

  • 退職エントリーを書かれる前に実践したい、エンジニアが辞めないチームの作り方

    採用難に苦しむIT企業でマネジャーをやっている皆さん、こんにちは! プログラマーにして採用担当、菌類のくせに人類を採用、育成している「きのこる先生」です。 普段はIT企業で働くエンジニアの皆さんに転職やキャリアについてお話していますが、今回は担当編集からのリクエストで、そんなエンジニアたちのマネジャーとして日々奮闘している皆さんに向けてのお話です。 エンジニアに「辞めます」と言われたら いきなり胸が苦しくなるような見出しですが、今回のテーマは「エンジニア退職」です。 皆さんはマネジメント対象であるエンジニアから「辞めます」と言われたことはありますか? 菌類は、あります。それはもう、数え上げたらキリがないほど……。 どんな理由であっても、チームのエンジニアが辞めるのはつらいものです。目の前の仕事には影響が出るし、残されたチームメンバーも何だかざわついてしまいます。「今までのマネジメントは間

    退職エントリーを書かれる前に実践したい、エンジニアが辞めないチームの作り方
  • bcryptの72文字制限をSHA-512ハッシュで回避する方式の注意点

    宅ふぁいる便から平文パスワードが漏洩した件を受けて、あらためてパスワードの安全な保存方法が関心を集めています。現在のパスワード保存のベストプラクティスは、パスワード保存に特化したハッシュ関数(ソルトやストレッチングも用いる)であるbcryptやArgon2などを用いることです。PHPの場合は、PHP5.5以降で使用できるpassword_hash関数が非常に便利ですし、他の言語やアプリケーションフレームワークでも、それぞれ用意されているパスワード保護の機能を使うことはパスワード保護の第一選択肢となります。 なかでもbcryptは、PHPのpassword_hash関数のデフォルトアルゴリズムである他、他の言語でも安全なハッシュ保存機能として広く利用されていますが、パスワードが最大72文字で切り詰められるという実装上の特性があり、その点が気になる人もいるようです(この制限はDoS脆弱性回避が

    bcryptの72文字制限をSHA-512ハッシュで回避する方式の注意点
  • なんでもかんでも「バグ」ってひとくくりにしないで - Qiita

    はじめに プログラマがソフトウェアを作るとユーザがつきます。ユーザがそのソフトウェアを使っていて何らかの問題が発生すると「このソフトはバグってる、直して!」と言われることがままあります。それに対して「いや、仕様だから」と突っぱねられることがあります。その後お互いの意見が「バグだ!」「いいや仕様だ!」と平行線になってお互いモヤモヤのまま終わるというのはよくある話です。 なぜこういうことが起きるかというと、原因の一つは「問題」イコール「バグ」という短絡的な考え方です。とくにソフトウェアを作ったり使ったりした経験が浅い人がこうなる傾向があると推測しています。このようない違いは「要件」「仕様」と「実装」という言葉の意味を理解していればある程度解決できます。書はこれらの用語について実例を挙げて簡単に紹介します。 注意点 記事では要件や仕様を定義することが前提となっていますが、とくにユーザと開発

    なんでもかんでも「バグ」ってひとくくりにしないで - Qiita
  • 睡眠課題・不眠の原因や改善方法を知る情報サイト | フミナーズ

    フミナーズ編集部です。 日頃よりご愛読いただきまして、誠にありがとうございます。 睡眠情報メディア・フミナーズは、2019年6月7日をもちましてサイトを閉鎖致しました。 フミナーズは、「睡眠を通して、今より豊かな生活を」をコンセプトに、2015年3月のオープン以降、多くの医師や専門家の方々にご協力いただきながら、いろんな「眠れない」を抱える人たち(=フミナーズ)に寄り添い、自分らしい「眠り」との付き合い方を提案してきました。 公開された記事の数は1,000近くにおよび、2018年1月には、単月650万PV、400万UUを達成。睡眠関連のメディアとしては国内最大級のサイトとなり、多くの皆様から愛される媒体となることができました。 編集部一同、これまでたくさんの記事を通して、皆様からの温かいコメントを励みに尽力することができました。ご愛読いただいていた皆様には、多大なご迷惑をおかけしますこと

    睡眠課題・不眠の原因や改善方法を知る情報サイト | フミナーズ
  • Terraform Registry

  • AMI作成のPackerプロジェクトのワタシ的ベストプラクティス! - そうなんでげす

    様々なプロジェクト仕事をするにあたって、AWSのAMI(Amazon Machine Image)を多くつくるようになりました。 今回はPackerプロジェクトの個人的なベストプラクティスをまとめました。 作成したリポジトリはじめに、作成したリポジトリを以下に晒しておきます。 soudegesu/my_packer_best_practiceまた、前提条件は以下とします。 作成対象はAMI(Amazon Machine Image)プロビジョニングには Packer と Ansible を使うインスタンスのテストには Sererspec を使うPackerやAnsible、Sererspec自体の解説は割愛します。 Vagrantを使ってローカル環境でデバッグできるようにしておくAnsible Playbookの書き始めの頃は、可能であればローカル環境上に Vagrant と Virtu

  • Packer+Circle CIでGoogle Compute Engineのイメージを生成する

    docs.md Packer+Circle CIでGoogle Compute Engineのイメージを生成する これは Aizu Advent Calendar 2016 の 9日目の記事(遅刻)です. http://www.adventar.org/calendars/1530 8日目: オフィスにいる人間をSlackに通知するやつ作った - 人権真骨頂 10日目: @mic_psm Google Compute Engineには,AWSではAMIに相当するImageという概念がある. Imageには,Image Familyというものがあって,Imageのバージョン管理を行うことができる. 具体的には,Familyはその中に存在する一番最新のImageへのポインタを持っている.DockerfileのFROM name:latestみたいなノリ. これを使うと,インスタンスを実行する時

    Packer+Circle CIでGoogle Compute Engineのイメージを生成する
  • chefを捨ててシェルスクリプトにした | Ore no homepage

    一部のサブシステムの構築で、プロビジョニングツールを捨ててみた。じゃあどうするのかというとシェルスクリプトでやる。今回はこのやりかたが一番楽できるような気がしたので試している。 具体的にはPackerからシェルスクリプトとServerspecを実行してAMIを煮込む。おいしくできあがったらそいつから構築。もしミドルウェアより下の層のコンフィグ類に変更があったらまた煮込む。構築する。新しい方に切り替える。つまり”捨てるインフラ”にする。 プラットフォームはAWS。 (追記)ちなみにchefなどのプロビジョニングツールがめんどくさいからシェルスクリプトにしたというよりは、捨てる前提のサーバだからシェルスクリプトでの構築も選択肢として出てきたということです。ただ自分個人の嗜好としてchefはもう飽きたというのも事実です。なお、オンプレだと同じサーバで継続してプロビジョニングすることになるのでch

  • Terraform & Packer での運用におけるサーバの構成変更 - LIVESENSE ENGINEER BLOG

    Packer / Terraform による構成管理 Packer による AMI の作成 Terraform でのインスタンス起動時の user-data の利用 Terraform でのサーバの入れ替えの為の設定 / 作業 Auto Scaling グループに対する ELB 付け外しの利用 autoscale.tf elb.tf codedeploy.tf variables.tfvars 実際のオペレーションの手順 1. green の設定変更 / 起動 2. green サーバ群を番 ELB に設定 3. blue サーバを番 ELB から切り離す 4. blue の台数を 0 に 実際に運用してみて 課題や今後 まとめ こんにちは、エンジニアの野です。先日、door 賃貸をオンプレから AWS に移行した際、Terraform & Packer を中心に行ったという話を紹介

    Terraform & Packer での運用におけるサーバの構成変更 - LIVESENSE ENGINEER BLOG
  • Dockerfile の代わりに Packer を使って Docker に再々入門してみている - えいのうにっき

    最近また、Docker に入門しなおしている。今回で3回目。Docker for Mac がずいぶん良いらしいので、DockerRails アプリを動かしてみた - えいのうにっき が前回入門したときの記事。 blog.a-know.me さすがに3回目ともなると「あぁー!はいはい、そうでしたそうでした!」ということも多くて、まぁこれはこれでアリか、と思い直してみたりもしている。 今回の入門にあたっては、「プログラマのためのDocker教科書 インフラの基礎知識&コードによる環境構築の自動化」というを使っている。Docker・コンテナのことのみに留まらず、コンテナを扱うに際しておさえておきたいインフラ・ネットワークについての話などについても触れられていて、まだ読んでる途中ではあるのだけどなかなかいい感じ。 プログラマのためのDocker教科書 インフラの基礎知識&コードによる環境構

    Dockerfile の代わりに Packer を使って Docker に再々入門してみている - えいのうにっき
  • 手軽なのに効果絶大『Chrome』を高速化する12の設定(flags)

    2017年12月1日2021年2月17日ブラウザ 標準状態では設定項目が少ない Chrome ですが、開発・実験段階の機能が隠し機能として搭載されています。 隠し機能にはページ表示速度が高速化するものが多数含まれており、有効化するだけで「これが同じChrome?」と思うほど高速になります。実際の表示速度が倍になるわけではないものの、体感速度が大幅に向上します。Chrome が重いと感じている人は一度試す価値はあります。 隠し機能の設定方法 Chromeの隠し機能は通常の設定からはアクセスできないため、アドレスバーから直接設定ページに飛びます(VivaldiChromeと同じ、Operaは設定できる項目が異なります)。 Chrome://flags chrome://flags のページでは、一番上に警告が表示されます。 flagsのページにある機能は正式に導入されたものではないため、設定

    手軽なのに効果絶大『Chrome』を高速化する12の設定(flags)
  • DevOpsのための道具箱: 自動化のためのツール – 「若手エンジニアのためのDevOps入門」(11) | さくらのナレッジ

    前回はモニタリング/フィードバックについて扱いました。 今回はDevOpsプロセス間を繋ぐための便利なツールとして各種連携ツールやチャットボットについて扱います。 自動化のための連携ツール DevOpsはこれまでの記事で扱ってきたように複数のプロセスから構成されます。プロセスを運用しだすと手動で行うと大変なために自動化を進めたくなる部分が出てきます。GitHubにプルリクエストが作成されたらCIサーバでテストを行い、成功したらステージング環境にデプロイといった、何らかのアクションを契機とする後続プロセスのための環境構築や任意のコマンドの実行、関係者への通知などです。 プロセス間を繋ぐための自動化を行う際にGitHubとTravisCI間をWebhookで繋ぐというように利用するツール/サービス側で密に連携できる場合は良いですが、そうでない場合は別途自動化のための連携ツールを利用したり、ある

    DevOpsのための道具箱: 自動化のためのツール – 「若手エンジニアのためのDevOps入門」(11) | さくらのナレッジ
  • リリース/構成管理: Ansible/Packer編 – 「若手エンジニアのためのDevOps入門」(8) | さくらのナレッジ

    第7回は実践編として、さくらのクラウドのリソースマネージャ(Terraform)を用いて実際にインフラを構築しました。今回はAnsible/Packerを用いて構築したサーバに対するセットアップ(プロビジョニング)を行ってみます。 サーバのプロビジョニングツール 前回でさくらのクラウドのリソースマネージャ(Terraform)を用いてサーバの作成が行えましたが、特にOS/ミドルウェア/アプリケーションの設定などを行っていないためシステムを動かすための設定などを行う必要があります。 設定を行うには手作業でコマンドを実行していく方法もありますが、やはりツールを利用することで素早く確実に行うことが可能です。 このためのツールは「プロビジョニングツール」と呼ばれ、様々なツールが存在します。今回はこの中からAnsibleを例にサーバのプロビジョニングを行います。 また、Ansibleなどである程度プ

    リリース/構成管理: Ansible/Packer編 – 「若手エンジニアのためのDevOps入門」(8) | さくらのナレッジ
  • Ansible、Vagrant、Packerを用いたAWSの開発/本番/ステージング環境の構築

    はじめに 受託開発において、比較的小規模なフルスクラッチのWebシステムを開発する場合、インフラ関連の工数の中でWeb/アプリケーション(AP)サーバの構築に対する工数が比較的多くなってきます。 また、複数のプロジェクトにおいて、同じような作業を繰り返し実施する必要があり、手作業で構築を実施する場合、繰り返し実施する中で手順書が修正され続け、いわゆる「秘伝のタレ」となり再現性が失われるケースが多々あります。 稿では、開発環境及び番/ステージング環境において、Web/APサーバを構築する際に「再現性があり」「繰り返し利用が可能で」「短時間で構築が可能な」方法として、Ansible、Vagrant、Packerを用いた実践方法をご紹介します。 Ansible、Vagrant、Packerの役割 Ansible、Vagrant、Packerは既に多くの事例でも採用されているため、ご存知の方も

    Ansible、Vagrant、Packerを用いたAWSの開発/本番/ステージング環境の構築