財テク - shunirr
前提 shunirr の独自研究による財テクをまとめています shunirr は、そこそこの規模の会社勤務なソフトウェアエンジニア (退職金や企業型 DC は無い) 、独身、副業は特にやっていない 状況の異なる人間は役に立たない情報である可能性が高い フリーランスなどの自営業、スタートアップ企業勤務、あるいは歴史ある大企業勤務、など 結婚してる、家族がいる、など shunirr の思想・価値観によってまとめられているので異なる価値観の人には合わない可能性があります shunirr は全てを実践してはいません 基本的な考え方 資産を増やす方法はいろいろあるけど、税金を減らす方法はあんまり無いので、出来るならやっておきたい 税金は減るとお得だけど、税金が減る額よりも儲かる金融商品があるなら、そっちを買った方がお得 商品の金利や運用益が非課税なものよりも、自分の所得税・住民税から控除される方がお
メルペイ VPoE による2019年の振り返り
こんにちはこんにちは。前回のブログでお知らせしたとおり、Merpay Advent Calendar の1日目を、メルペイ VPoE の @hidek がお届けします。 はじめに 2019年もあっという間で、12月を迎えて終わろうとしています。ということで、メルペイとしての2019年を振り返ろうと思います。お題は「何かエモい話」と雑に振られたのですが、2019年に起こったことをなるべく赤裸々に淡々と書いていきます。 メルペイは2018年2月くらいから開発を開始していました。最初からマイクロサービスアーキテクチャの採用、Google Cloud Platform （GCP）を使ったクラウドネイティブな環境、と比較的モダンな思想のもとでの開発を続けています。ちなみに私が参加したのは2018年5月で、2018年中にはすでに決済基盤など大きなところの開発はかなり進んでいる状態でした。が、一方でなか
情報処理学会でウェブオペレーション技術について招待講演した話 - ゆううきブログ
情報処理学会インターネットと運用技術研究会が主催されているIOTS2016という研究会で、「サーバモニタリング向け時系列データベースの探究」というタイトルで招待講演をしてきました。 講演のきっかけ インターネットと運用技術研究会(以下IOT研究会)というのは僕にとっては id:matsumoto_r さんが所属されている研究会です。 matsumotoryさんが、ちょうど2年前のアドベントカレンダーで書いた僕の記事に日本語だとIPSJのIOTは分野的にもインターネットの運用技術が含まれるので興味深い論文が沢山あると思う とコメントしていただいたのが最初に研究会の存在を知るきっかけだったと思います。 そのときはそんなものもあるのかと思ってちょっとプログラムを眺めた程度でした。 しかし、まさかその2年後にこうして招待していただくことになるとはもちろん思っていませんでした。 id:MIZZYさん
Linuxサーバにログインしたらいつもやっているオペレーション - ゆううきブログ
主にアプリケーション開発者向けに、Linuxサーバ上の問題を調査するために、ウェブオペレーションエンジニアとして日常的にやっていることを紹介します。 とりあえず調べたことを羅列しているのではなく、本当に自分が現場で使っているものだけに情報を絞っています。 普段使っているけれども、アプリケーション開発者向きではないものはあえて省いています。 MySQLやNginxなど、個別のミドルウェアに限定したノウハウについては書いていません。 ログインしたらまず確認すること 他にログインしている人がいるか確認（w） サーバの稼働時間の確認 (uptime) プロセスツリーをみる (ps) NICやIPアドレスの確認 (ip) ファイルシステムの確認（df） 負荷状況確認 top iostat netstat / ss ログ調査 /var/log/messages or /var/log/syslog /
良いディフェンダーはタックルをしないし、良いエンジニアは障害対応をしない · takus's blog
Amazon のオススメ本に出てきた「 サッカー データ革命 ロングボールは時代遅れか 」を読んでみました。 この本は、野球界における「 マネーボール 」のように、 サッカーを様々なデータを元に見つめ直すような内容になっていて、 例えば、チームが負けているときに交代によって最大の効果を得るためには、 1 人目の交代を後半 13 分、2 人目を後半 28 分、3 人目を後半 34 分までに行うべきとか、 極端に能力の高い選手を獲得するのと弱点となる選手の穴を埋める補強はどちらがいいのかとか、 統計を元にしたサッカーに関する興味深い考察が多かったのですが、その中に 1 つ引っかかる話があったのでそれについて書いてみます。 良いディフェンダーはタックルをしない 本書の中で、 四半世紀に渡ってマンチェスター・ユナイテッドを率いた名将ファーガソンが、 オランダ代表のディフェンダー、ヤープ・スタムを放
バッチ処理について再考 - プログラマでありたい
作業途中のメモです。バッチ処理の定義を確認しようとしてWikipediaをはじめとして幾つかのサイトをみてました。その時に目に入ったのが、下記の文章です。 利点 バッチ処理には以下のような利点がある。 ・多くのユーザーがコンピュータのリソースを共有できる。 ・処理をコンピュータのリソースがあまり忙しくない時間帯（多くは夜間、休日）にシフトできる。 ・人間がついていなくてもコンピュータのリソースが暇にならないように最大限有効活用できる。 ・高価なコンピュータをフルに活用することで費用対効果の効率向上に寄与する。バッチ処理 - Wikipedia これだけみると、人件費に対してコンピュータリソースが高い時代の産物なんですよね。今は、クラウドの登場で、有り余るコンピュータリソースをほぼ自由に低コストに使える時代です。そもそもバッチ処理である必要があるか、考える必要がありますね。特に夜間バッチにつ
社内ITシステムを構築・運用するのに最重要な3つのポイント - たごもりすメモ
自社で使用するシステムを開発する、とする。 このとき迂闊にやっていると、気付いたら過去に構築したシステムのメンテナンスにばかり時間をとられ、新しいコードがぜんぜん書けていない、という状況に陥ることがある。 こうなると地獄だ。新規の興味深いコードを書くなんてとんでもない、という状態になる。メンテナンスコストを下げるためのコードすら書けなくて永遠に悲惨な撤退戦を繰り返すことになる。絶対に避けなくてはならない。 ということで、自分が心掛けていることをざっと書く。 全く手を入れずに動き続ける状態を最初に作る もちろんシステムというものは生き物なので、ある程度のメンテナンスコストが必要になる。特に会社というものは生き物なのでシステム周囲の環境は常に変化する可能性がある。データ連携している別のシステムの仕様が変われば、当然そのデータを利用する側も対応しなければならない*1。 ということで、システムには
グリーを支える通知システム | GREE Engineering
はじめに このエントリは GREE Advent Calendar 2014 24日目の記事です。 こんにちは、インフラストラクチャ本部の高野(@takano32)です。 いつも社内では GitHub:Enterprise の運用、 デプロイの改善、 大規模なインフラを操作するためのツール作成、 レガシーなサーバのセキュリティ対策、 コミュニケーションツール向けシステムの構築・運用、 などの仕事をしています。節操がありませんね。はい。 そのうち、今回は「コミュニケーションツール向けシステムの構築・運用」のうち「グリーを支える通知システム」という題目について書きたいと思います。 グリーとリアルタイムコミュニケーションツール まず、通知システムについてお話する前に、グリーでどのようなリアルタイムコミュニケーションツールが利用されてきたかを簡単に説明したいと思います。 リアルタイムコミュニケーシ
Pinterestをスケールさせる中で学んだこと - ワザノバ | wazanova
https://www.youtube.com/watch?v=jQNCuD_hxdQ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 PinterestのMarty Weinerによる goto; conference 2014の講演。 「webサイトどうやってつくるの？」という創業期から、現在に至るまで、段階的にテクノロジースタックがどう進化したか。 現在のPinterestのシステムアーキテクチャの全貌。 個別のテクノロジーの選択理由。 などを語った45分のビデオですが、goto; conferenceのサイトからスライドのPDFをダウンロード（初日の10:20のコマです。）できるので、そちらを見ていただいてもわかりやすいかと。 「サイトが落ちてしまうのである意味自然に学ぶことができてしまった。
マニュアルオペレーションするとき気を付けたいこといくつか - ふり返る暇なんて無いね
少し思うところがあったのでメモ。 ほぼ自己流なので、もっと良いのがあれば教えて欲しいところ。 そもそもマニュアルオペレーション(手作業)するな ごもっとも。でもやらないといけない深淵な事情があるんです。 事前条件と事後条件を明確にしておく どういう状態からどういう状態に変わるべきか事前に明確にしておくべきです。 それなしに普通は作業しません。 切り戻し手順を考えておく 途中でミスる可能性があるポイントを明確にしておくこと。 それぞれのタイミングでの切り戻し手順をしっかり考えておくこと 作業手順を事前に書く オペレーション中にアドホックに手順考えないですよね? 複数手順あるならスクリプト化する できる限りステップを減らします。可能ならスクリプトを一発叩くだけにします。 set -eu は付けた方がいい eオプションはコマンドのステータスコードが0以外(異常終了)したときに、その時点で終了して
急増するLINEインフラの課題と対応 « LINE Engineers' Blog
こんにちは。今回はITサービスセンターより、インフラ運営の観点から急増するLINEインフラの課題と対応について記させていただきます。 はじめに 先日開催したLINE Developer Conference（インフラ編）には大勢の方にいらしていただきました。カンファレンスでは、LINEサービスが始まってから約2年の間に我々はどういった方法でインフラ運営を行い、またどんなことに悩んできたのかを、システム、データベース、ネットワークの観点からそれぞれ発表させていただきました。 カンファレンスはLINE株式会社が様々な技術をどのように使い、どのように運用を行っているのか。現在どのような技術的なことに取り組んでいるのか日本のエンジニアの皆さんに知っていただくために開催されました。結果としてインフラ編では150名の定員に対して430名のご応募をいただいたとのことでLINEサービスに対する関心の高さを
ソフトウェアのアップデートとウェブサービス運用における継続性リスクについて - kazuhoのメモ置き場
Webサービスのようなプロダクトについての議論について教えて下さい - Kentaro Kuribayashi's blog で呼ばれたような気がしてたけど放置してた。でも今日、express という node.js 上で動作するメジャーなウェブアプリケーションフレームワークを作っているチームが、次世代の製品に取り組み始めたと聞いたので、メモを以下に貼ります。 ------------------------------ ✂ ------------------------------ ソフトウェア技術の配布手法のトレンドは以下のように推移してきた。 プロプライエタリ（仕様も実装もベンダー固有） オープンシステム（仕様は共通、実装はベンダー固有） オープンソース（実装を皆で共有） ハードウェアにしても、プロプライエタリから業界標準主導なアプローチにかわってきている。 つまり、時代とともに、
危なくないgitこと、うちのチームのgit戦略草案(ver. 2)
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました！ > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
さくらのDockerコンテナホスティング-Arukasの解説とインフラを支える技術（July Tech Festa 2016 『IoTxAIxインフラ時代の最新技術、やってみたSP－俺の屍を越えて行け－』）
クックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について // Speaker Deck
FINAL FANTASY Record Keeperのマスターデータを支える技術
運用に自動化を求めるのは間違っているだろうか
fluentdでログが欠損する可能性を考える : sonots:blog
運用を楽にするためのアプリケーションコードを書くということ : sonots:blog
ご注文は監視自動化ですか？
