タグ

2020年3月2日のブックマーク (6件)

  • 稼働率100%をねらってはいけない | タイム・コンサルタントの日誌から

    多くの製造業においては、工場の稼働率が、重要な管理指標として今も使われている。3週間前のエントリ「原価の秘密 - なぜ、黒字案件だけを選別受注すると赤字に陥るのか 」(2014/07/06)でも説明したように、製品の個別原価を計算する際、材料費や労務費などの他に、製造機械の使用時間に応じた費用を含めるのが普通だ。その製品の加工作業で、製造機械が何時間必要だったかをベースに、機械のコストをチャージする。いわば“機械の使用料”だ。 個別の機械1時間あたりの使用料単価を『機械賃率』と呼ぶが、これは各機械の年間の維持費用(減価償却費等)を、年間の実稼働時間で割って計算する。機械の遊んでいる時間が多いほど、実稼働時間は減るから、同じ作業をしていても原価が上がる、というのがふつうの会計の仕組みだ。だから、製造業では稼働率を上げるべく、あれこれと努力するという訳である。 そして、前回のエントリを読まれた

    稼働率100%をねらってはいけない | タイム・コンサルタントの日誌から
  • 「パスワードは複雑さより長さが大切」 FBIが指南

    パスワードは複雑にする必要はない。ただ長くすればいい――。米連邦捜査局(FBI)のそんな勧告が話題になっている。根拠としているのは、米国立標準技術研究所(NIST)がまとめた最新版のガイドライン。破られにくく、かつ覚えやすい文字列を作り出すため、パスワードではなく「パスフレーズ」の使用を勧めている。 これまでパスワードといえば、アルファベットの大文字と小文字、数字や記号を使ってできるだけ複雑にするのが望ましいとされてきた。ところがNISTの勧告では、パスワードの複雑さよりも、長さの方が、ずっと大切だと説く。 そこで、長くてしかも覚えやすい文字列をつくりだす手段として提言しているのが、複数の単語を組み合わせたり文章をつなげたりするパスフレーズ。FBIは強いパスフレーズの一例として、「VoicesProtected2020WeAre」「DirectorMonthLearnTruck」などを挙げ

    「パスワードは複雑さより長さが大切」 FBIが指南
  • AWS&Azure&GCPの凄腕エンジニアが激論!「雲の中心で愛を叫ぶ! クラウド横断パネルディスカッション」レポート(完全版) #devsumi | DevelopersIO

    2020年02月13日(木)〜14日(金)の2日間、目黒雅叙園で開催された『Developers Summit 2020』。 通称"デブサミ"と呼ばれているこのカンファレンスイベントには、私自身2013年から参加しており(この時は一般枠として)、翌2014年からはいわゆる『プレス枠』として参加させて頂き、翔泳社様のメディアサイト『CodeZine』にレポートを寄稿させて頂いていました。(※これまでの寄稿情報については以下ページをご参照ください) そして今年2020年も、引き続きプレス枠として参加しました! 当エントリは寄稿エントリとして聴講したものの中から、Developers.IOでも是非レポートしておきたい!というセッションについてレポートしたいと思います。同僚の濱田孝治が登壇した「雲の中心で愛を叫ぶ! クラウド横断パネルディスカッション」です。 目次 セッション概要 セッションレポー

    AWS&Azure&GCPの凄腕エンジニアが激論!「雲の中心で愛を叫ぶ! クラウド横断パネルディスカッション」レポート(完全版) #devsumi | DevelopersIO
  • メルカリの世界展開を支える開発チームの今とこれから|CTO 柄沢聡太郎 #mercariday | mercan (メルカン)

    メルカリの中で働くメンバーが、日々どのようなことを考え、どのようにチャレンジしているのかを紹介する場として初めて開催した『Mercari Day 2017』。 稿では、CTOの柄沢聡太郎が登壇したセッション「Mercari – Moving Beyond Borders」の模様をお届けします。 メルカリでは、日、US、UKと文字通り「国境=Borders」を越えたプロダクト開発を行っています。その中心を担うエンジニアリングチームがどのように作られているのかをご紹介しましょう。 speakerdeck.com 体制について~US、UKと拠点が広がっても「開発の中心は日」 柄沢が最初に話したのは、3拠点におけるエンジニアリングチームの人数や役割について。拠点数が増えた今、これまでと何が変わり、何が変わっていないのかを説明しました。 僕がメルカリにジョインしたのは2年前の5月。もうすぐ2年

    メルカリの世界展開を支える開発チームの今とこれから|CTO 柄沢聡太郎 #mercariday | mercan (メルカン)
  • EC2の既存システムをECSにリプレイスした話 - アイリッジ開発者ブログ

    アイリッジ プロダクト開発グループの高田です。 EC2からECSにインフラをリプレイスすることは割とあるケースだと思います。 これから似たようなことやる人にとって、少しでも参考になる記事になれば幸いです。 対象読者 EC2でサーバを立てたことがある人 ECSでコンテナを立てたことある人 目次 なぜやったのか リプレイス前後のインフラについて 結果と課題 なぜやったのか コスト(サーバ費用と運用の手間)を下げるためです。チーム内ではとりわけ運用コストを下げるため、前々から既存サービスのFargate化を行ってきました。 運用コスト デプロイに手間と時間がかかる問題 私が普段携わってる自社サービスは複数のコンポーネントによって成り立っています。その内多くがDocker化されていて比較的デプロイが簡単にできるようになっていますが、一番デプロイ頻度の高いコンポーネントがまだDocker化されておら

    EC2の既存システムをECSにリプレイスした話 - アイリッジ開発者ブログ
  • 位置情報のaccuracyを活用した来店判定方法 - アイリッジ開発者ブログ

    アイリッジ プロダクト開発グループの朴です。 geography上で位置情報を使ってユーザーの来店判定をする時、普段は距離を計算して判定すると思います。 もう少し細かく説明すると、特定場所(お店など)の中心になる座標とユーザーの位置情報を元に距離を計算して特定の値より大きいか小さいかでin/outの判定をするということです。 これは特定場所の中心点を「円心」にし、特定の値を「半径」にする円の中に点(ユーザーの位置情報)があるかを判定することを意味します。 この判定方法はいいと思いますが 位置情報にはさらにaccuracyという精度を表す値があり、androidの場合はfloatで単位はmeterです。 これは位置情報の座標を円心にし、accuracyを半径にしている円のとこかに存在することを意味します。 つまり、accuracyが小さければ小さいほど位置情報の正確度が上がるということです。

    位置情報のaccuracyを活用した来店判定方法 - アイリッジ開発者ブログ