タグ

ブックマーク / songmu.jp (13)

  • 41歳のエンジニア、マネージャーからICへのキャリアチェンジ | おそらくはそれさえも平凡な日々

    最初にお断りしておくと、このエントリは驚くほど僕固有の私的な話に終止するので、他の人の参考にはならないでしょう。 ICというのはIndividual Contributorの略で、最近だとHashiCorp創業者のあのMitchell Hashimoto氏が、HashiCorp社内でICになるというのも話題になりました。日でも、こにふぁーさんがそういう動きをしていたりして、ちょいちょい聞くようになってきた印象です。 今回の僕の転職は、言ってしまえば、自分が培ってきたソフトウェアエンジニアとしてのスキルを活かして世界の舞台で戦いたいという気持ちを抑えきれなかった、という幼稚な理由です。自分が求めているものがLaunchableにはあるように感じて入社しました。 振り返ってみると、最近の自分の転職における決め手は「自分を一番必要としてくれるところ」という側面が強かったと感じています。その結果

    41歳のエンジニア、マネージャーからICへのキャリアチェンジ | おそらくはそれさえも平凡な日々
    yosuke_furukawa
    yosuke_furukawa 2021/10/21
    かっこいい
  • Let's Encryptのルート証明書切替周り(完結編) | おそらくはそれさえも平凡な日々

    tl;dr 驚くべきハックにより旧Androidも引き続き証明書エラーなくサイトを閲覧できそうです いよいよ5/4に標準の証明書チェーンが切り替わります 前回までのおさらい Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる Let's Encryptの証明書切替周りその後 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしています。現在は、IdenTrustのルート証明書(DST Root CA X3)が使われています。 正確に言うと、ISRGは新しい認証局なのでそのルート証明書の普及率も当然低く、中間証明書はIdenTrustのルート証明書でクロスサインされており、それが標準で使われています。標準がDSTになっているだけで、ISRGのルート証明書のチェーンの証明書も指定すれば今で

    Let's Encryptのルート証明書切替周り(完結編) | おそらくはそれさえも平凡な日々
    yosuke_furukawa
    yosuke_furukawa 2021/04/30
    まじかw "なんと、旧Androidはトラストストアに入っている証明書の有効期限検証をおこなわないため、2021年9月29日より後も証明書検証に成功するらしいのです。何ということでしょう…。"
  • Let's Encryptの証明書切替周りその後 | おそらくはそれさえも平凡な日々

    Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる」の続き。 色々動きがあって猶予もできて助かった形だけど、来年9月29日以降の対応をどうするか考えないといけない状況なのは当然変わっていません。先にまとめると以下。 何もせずとも来年の1月11日までは猶予が伸びた 証明書を発行する側の場合、各クライアントで --preferred-chain "DST Root CA X3" のようにオプション設定することで、来年の9/29まで先延ばしが可能 独自ドメインに対して自動でSSL証明書を発行してくれるサービスを利用している場合はサービスが声明を出していないか調べ、出してない場合は問い合わせると良いでしょう 前回以降の動き go-acme/legoに--preferred-chainオプションのpull requestを取り込んでもらいました デフォルトRoot証

    Let's Encryptの証明書切替周りその後 | おそらくはそれさえも平凡な日々
  • サブコマンドはUNIX哲学と相反していないのか | おそらくはそれさえも平凡な日々

    「UNIXという考え方」に書かれているUNIX哲学に「各プログラムが一つのことを上手くやる」というのがある。それとサブコマンドは矛盾するんじゃないかと感じていた。一つのプログラムが複数のことを実行できるじゃん、という。 最近は以下のように思うようにあった。 サブコマンドを持つようなツールの名前自体は「名前空間」である 「サブコマンドが一つのプログラム」だと考えればいい 汎用的なコマンドラインツールはグローバルな名前になるので、名前の衝突には気をつける必要がある。今や多くの開発者がコマンドラインツールを書くようになった。 また、コンテキストを同じくした複雑なツール群を提供する場合、名前空間的なものはあったほうが良いのは確かでしょう。例えば git のサブコマンドが全部バラバラのコマンド名だったら発狂してしまう。 最近、僕はGoでツールを書く事が多いが、サブコマンドを採用せずに各々のコマンドで

    yosuke_furukawa
    yosuke_furukawa 2017/08/27
    同意見。simpleとeasyの違いで言う所のeasyな層を提供するという方針でCLIを作る際にはサブコマンド式でsimpleな層を束ねるというパターンがあると考えている。
  • Makefileを自己文書化する `make2help` | おそらくはそれさえも平凡な日々

    近年「タスクランナー」という言葉をよく耳にするようになりました。近年のWeb開発では、開発環境のセットアップ、依存ライブラリの管理、テストの実行、開発サーバーの起動、ビルド、デプロイ等等、とにかく気にしないといけないことが多いため、そういったタスクを一元管理してくれるタスクランナーは便利なやつです。 新しくプロジェクトに参加した際に、タスクランナーを見れば何をやれば良いのかだいたい分かるようになっているのが理想的だと思っています。 タスクランナーという言葉は主にJS界隈で使われており、そもそもタスクランナーなのかビルドツールなのかという話はありますが、ここでは便宜上それらをひっくるめてタスクランナーと呼ぶことにします。 gulp質的にはビルドツールですし。 Goの開発においては、タスクランナーとして、古き良きビルドツールであるところの make が主に使われます。 make も使って

    yosuke_furukawa
    yosuke_furukawa 2016/06/13
    めっちゃいい
  • ルーク!MySQLではkamipo TRADITIONALを使え! | おそらくはそれさえも平凡な日々

    よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI

    ルーク!MySQLではkamipo TRADITIONALを使え! | おそらくはそれさえも平凡な日々
    yosuke_furukawa
    yosuke_furukawa 2015/07/08
    KAMIPORADITIONAL 覚えた
  • 何故僕はエンジニアとして対外発表をするのか | おそらくはそれさえも平凡な日々

    僕は来、人前に出て積極的に話そうとは思わないし、目立たずにおとなしく引きこもっていたいみたいな気持ちがある。潔癖な部分もあるので、プレゼンスばかり高くて技術力がないような中身が無い人間になりたくないし、そうなったら死ぬしか無い、みたいな気持ちもある。それなのに何故、ものすごく技術力があるわけではない自分が対外発表をするのか。 それは元はと言えば対外発表をするような側に行かないとエンジニアとして生き残れないのではないかという危機感があったからです。 Shibuya.pmの衝撃 初めて参加したShibuya.pmは#10だった。その頃の僕は一企業のよくある何でも屋の1人システム担当であり、開発のメインは前担当者から引き継いだレガシーASPだった。そしてつぶしの効く技術を習得したいと思いPerlを学び始めた頃だった。そしてPerlがそこそこ書けると手応えを感じ始めているところだった。 ところが

    何故僕はエンジニアとして対外発表をするのか | おそらくはそれさえも平凡な日々
  • ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々

    あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか?もしくはコードカバレッジだけにとらわれすぎていないでしょうか? 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に番用の設定ファイルを使うことはないため、番用の設定ファ

    ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
  • 株式会社はてなに入社しました | おそらくはそれさえも平凡な日々

    日は9月1日。エイプリルフールではなくて、防災の日です。 勤務地は東京の表参道ですが、今日から2週間だけ京都で働くので、新幹線の中でこのエントリを書いています。YAPCのトークでも話しましたが、東京で僕と一緒に働いてくれるエンジニアを絶賛募集中です。 長くなるのでとりあえずwishlistを置いておきますね。 http://www.amazon.co.jp/gp/registry/wishlist/3L07LJZVYI89C/ FA宣言したら20数社から連絡を頂いたんですが、その中からはてなを選ぶことにしました。はい。Perlの会社ですね。とは言えPerlは書かない予定です。とか言いつつちょいちょい書いてしまうことでしょう。 「Perlで、日語の会社じゃねーか!」というツッコミが飛んできそうですが、はてなが一番自分を必要としてくれたと感じたので、入社させてもらうことにしました。こういう

    株式会社はてなに入社しました | おそらくはそれさえも平凡な日々
    yosuke_furukawa
    yosuke_furukawa 2014/09/01
    おめでとうございます!!
  • クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々

    デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒

    クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々
    yosuke_furukawa
    yosuke_furukawa 2014/08/20
    ギーク特有のイジリなのか、攻撃なのかわからなくて困惑する事あって昔悩んでた
  • 退職とFA宣言のお知らせ | おそらくはそれさえも平凡な日々

    所属的には5月いっぱいですが、5月12日(月)が最終出社で有給消化中です。理由はいろいろありますが、結婚離婚がそうであるように、結局のところはタイミングの問題です。 一番大きな理由は家庭の都合です。家庭の都合というとネガティブに聞こえてしまうかも知れませんが、実際にはポジティブな挑戦です。 ただ、そのために会社を辞める必要は必ずしもなく、会社も引き止めの時にその事情を鑑みてバックアップしてくれる事は伝えてくれました。CTOに 「会社は社員の夢を実現する場所だと思っていて、だからといって全員が別の方向を向いているわけにもいかないので、誰かの夢に乗っかる形で事業を作っている。なので『こいつの夢に乗っかりたい』とか思わせたり、逆にそう思えるようなイイヤツを採用している。ただ、松木くんくらい会社に貢献してくれた人間だったら、自分の個人的な夢や目的のために会社を利用してくれて構わないし、むしろそう

    退職とFA宣言のお知らせ | おそらくはそれさえも平凡な日々
    yosuke_furukawa
    yosuke_furukawa 2014/05/13
    お疲れ様でした!!!
  • おそらくはそれさえも平凡な日々: モダンなPerlを「読む」上で覚えておくとよい構文 第1回(?)

    Perl学習者がある程度Perlに慣れてくると、他の人の書いたコードを読む機会も増えてきます。そこでつまづく人は多いのではないでしょうか。かく言う私自身がその一人です(笑) モダンなPerlはDSL(黒魔術?)的な書き方をしている部分も多く、雰囲気として処理内容をつかみやすいのですが、逆に文法的に構文を理解するのが難しいことも多いです。 「知っている人には当たり前、知らない人には黒魔術」 Perlにはそういうのが多いので、そういったところで悩んでいる人も多いのではないかと思い、このエントリーを書いてみることにしました。気が向けば続きも書きます。間違っている部分もあるかと思うので、ブクマコメ等でご指摘いただけると助かります。 日の目標とサンプルコード 裸のワード(bareword)は怖くない encode cp932 => $str; sub PI(){3.1415926535} てことで

    yosuke_furukawa
    yosuke_furukawa 2013/06/19
    知っている人には当たり前、知らない人には黒魔術。
  • おそらくはそれさえも平凡な日々: Perlの引数の渡し方の想像上の歴史

    一般的な以下の様な渡し方について。 func($foo, $bar); func({foo => $foo, bar => $bar}); func(foo => $foo, bar => $bar); 昔は1だったけど、2って書けるのも分かりやすくて良くね?ってなって、1でも2でも指定できるような書き方が出てくるようになった。 だんだんこの場合は1にすべき2にすべきっていう住み分けができてきて、両方の指定ができるみたいなのが減ってきた代わりに、じゃあ3の書き方で良くね?ってなってきた。今度は、2でも3でも指定できるみたいな書き方が出てくるようになった。 僕は最近は3決め打ちで良くね?って感じてきている。MouseとData::Validatorを便利に使わせてもらってるんで結果的には両方いける感じになっていることが多いけど。 値をhashに詰めるのとhashrefに詰めるのどっちが好きか

    yosuke_furukawa
    yosuke_furukawa 2013/05/16
    この議論、tohaeちゃんとしたことがあるような。
  • 1