タグ

2020年2月7日のブックマーク (5件)

  • スタートアップに転職する時に最低限知っておくべき株の話

    身の回りで大企業からスタートアップに転職するエンジニアの話をよく耳にするようになりましたが、転職に際して株に関して深く考えていない人がかなり多いことに気づきました。最低限この程度は知っておいたほうがいい、という点を自分の視点からまとめてみました。 スタートアップの金銭的な成功 スタートアップの株は「非公開株」です。非公開株というのは、東証などの証券取引所で取引されていない株全般のことを指します。おおっぴらに取引されていないので、非公開株を貰ったところで即座に現金化出来るわけではありません。特に外部から投資を受けるようなスタートアップ企業は、(例外はいくつかあるものの)この非公開株を現金化させることが一つのゴールになります。 非公開株を現金化させる方法は大きく2つあります。一つは株式公開(IPO)で、証券取引所の審査を経て自社株を自由に売買出来るようにすることです。いわゆるマザーズ上場、東証

  • SLO、SLI、SLA について考える : CRE が現場で学んだこと | Google Cloud 公式ブログ

    前回の『CRE が現場で学んだこと』シリーズでは、システムの可用性を担保するにあたってターゲットとする正確な数値をいかにして割り出すか、ということについてお話ししました。このターゲットをシステムのサービス レベル目標(SLO)と呼びます。 今後、システムが十分な信頼性を保って稼働しているか、またシステムにどんな設計やアーキテクチャの変更が必要かについて議論する際は、システムが継続的に SLO を満たしているという枠の中で語る必要があります。 SLO の適合性は直接測定することが可能です。システムにおいて精査が成功した頻度で計るのです。これをサービス レベル指標(SLI)といいます。システムが過去 1 週間 SLO を満たしつつ稼働していたかどうかを評価する場合に、SLI からサービスの可用率を把握するのです。定められた SLO を下回っているとなれば問題があるということですから、他の場所に

    SLO、SLI、SLA について考える : CRE が現場で学んだこと | Google Cloud 公式ブログ
  • エンジニアだけど米国でワイナリーを買った話

    突拍子も無い話ですが表題の通り、とあるご縁がきっかけで、きょろ(@kyoro353)とはとね(@hatone)夫婦を含む友人メンバー4人で、カリフォルニアのナパにほど近い「SUNSET CELLARS」(サンセット・セラーズ)というワイナリーを購入させて頂くことになりました。「ワイナリーって個人で買えるの!?」という感じだと思うんですが(僕も1年半前はそう思ってましたw)最終的に色々と頑張りまして、今年の10月から晴れてワイナリーの共同オーナーを務めさせて頂いています。まさか自分がワイナリーオーナーになる人生なんて思っても見なかった!! とは言え、私達は別にテレビゲームで大成功を収めた天才事業家でも、金銭的に成功した起業家やお金持ちでもありません。技術とモノづくり、そしてカリフォルニア・ワインが大好きな普通のエンジニアの夫婦です。 この記事では、ワインが大好きな普通のエンジニア夫婦が、いか

    エンジニアだけど米国でワイナリーを買った話
    ikesyo
    ikesyo 2020/02/07
  • ソフトウェアエンジニアとして家を建てる仕事をはじめました

    まさかソフトウェアエンジニアの自分が業で家を建てる仕事をするとは思っても見ませんでした。2年前、DeployGateの米国オフィスを自分で施工した事をきっかけに声をかけてもらい、以来、技術アドバイザーとして携わらせて頂いていた米国の建築スタートアップ「HOMMA」に格的に参加し、ソフトウェア・アーキテクトとしてアメリカでスマートハウスをソフトウェア面から設計して家を建てる仕事をはじめました。趣味電子工作から初まり、深センでの独自設計ハードの少量生産、アメリカでのオフィスの施工と来て、次はまさかの物の建売住宅の開発です。プログラミングの傍ら取り組んできた物理的な「ものづくり」のサイズがどんどん大きくなってきて楽しい限りです。制御用のファームウェアやアプリ、Webシステムを書きながら、ヘルメットを被って建設現場で大工職人さんへ施工の指示出しをしたり、信号線や電力系統の配線を設計して建築

    ソフトウェアエンジニアとして家を建てる仕事をはじめました
    ikesyo
    ikesyo 2020/02/07
  • メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita

    ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 1回目はどこに何があるか、 2回目は可読性が確保されているか、規約にのっとっているか 3回目は機能性 4回目はセキュリティ といった具合である。 IPAの講座では4回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも

    メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita