タグ

ブックマーク / tarao.hatenablog.com (5)

  • 株式会社一休に入社しました - 貳佰伍拾陸夜日記

    転職のお知らせ、あるいは個人の日記です。 6月から以下のように所属変更となっています。 From 株式会社はてな To 株式会社一休 マネージャではなく、とくに役職のないソフトウェアエンジニアとして働きます。いわゆるIC (individual contributor)というやつです。 きっかけ はてなには新卒として入社して以来11年も勤めて、インターンやアルバイトとして関わった時期から数えると16年になります。出入りの激しいこの業界でずっと1社しか知らずに過ごすのは負い目に感じていました。また、年齢的にも今年で40歳になることもあって、そろそろ転職を経験しておかないとまずいという焦りもありました。 そんなときに、大学の同期でプライベートでも仲良くさせてもらっているid:suzakから声をかけてもらい、ちょっと真剣に転職を考えたのがきっかけでした。 できることではなくやりたいこと はてな

    株式会社一休に入社しました - 貳佰伍拾陸夜日記
  • 関数の再帰的な定義に名前付けは必要か - 貳佰伍拾陸夜日記

    結論から言うと, 名前を付けることなく再帰的な関数を定義することは可能. 特定のプログラミング言語でどうかというよりは抽象概念としての関数の再帰を名前なしに実現可能かどうかという話(名前なしに実現できるプログラミング言語は存在するかという話). 発端 id:naoyaさんがこういうツイートをしていた. 再帰を書くときに何気なく関数に名前つけたり let で束縛したりしてたけど「再帰には三項関係が必要でありその実現には記号が質的に関わる」とあり、名前づけの行為が必然だったことが分かった。プログラミングするときの視点が変わるな— naoya (@naoya_ito) 2022年8月12日 たとえば以下のように書いたときのlet fact =みたいな話. let fact = n => n <= 1 ? 1 : n * fact(n-1) ちなみに, 話は一見逸れるけど, こう書けると必然的に

    関数の再帰的な定義に名前付けは必要か - 貳佰伍拾陸夜日記
    mizdra
    mizdra 2022/08/17
    不動点コンビネータ面白い
  • スクラムでベロシティを安定化するにはどうしたらよいか - 貳佰伍拾陸夜日記

    このブログではあまりこういう話は書いてこなかったけど, 以前少しだけ触れたように, 僕はここ最近エンジニアリングマネージャをやっていて, こういう話題を考える機会はけっこう多い. 具体的には, エンジニアリングマネージャとして複数チームのテクノロジ/プロセス/プロダクト/ピープルのマネジメントを日々やっていて, そのうちのプロセスマネジメントとして, 各チームのスクラムマスタ的な人に助言したり, 開発プロセスの改善のためにチームが起こそうとしている変化を受け入れるようラインマネージャを説得したり, といったことにけっこう時間を割いている. スクラムに関して以下のような話を見かけて, これはまさに日々悩まされていることだった. 一言で言うと「ベロシティの安定化でみんな躓く」という話. これは僕の経験上も納得できる. この記事に寄せられたコメントを見ると, 「で, じゃあどうやってベロシティを

    スクラムでベロシティを安定化するにはどうしたらよいか - 貳佰伍拾陸夜日記
    mizdra
    mizdra 2022/07/16
    良い
  • 契約による設計と名前による型づけ, およびオブジェクトの不変性 - 貳佰伍拾陸夜日記

    契約による設計と名前による型づけ 最近, 社内で契約による設計の話が雑談として何度か出ていて, id:hakobe932さんが社内勉強会で紹介していたり, id:shiba_yu36さんがWEB+DB PRESSでSmart::Argsで制約をチェックする記事を書いていたり, 活発な議論になっている. インスタンスのファクトリメソッドとオプショナルな型を組み合わせると事前・事後条件を満たすことが保証できて, id:hakobe932さんの資料で言うところの「要求型」と「保護型」の区別も明確になってよいという話を書こうかとおもっていた. (これはそのうち別で書く.) とはいえ, こんな話はもう言っている人がいるだろうと思ってちょっと調べていて, どういう語句で調べたらいいか考えていた. インスタンスの型からそれを生成したファクトリメソッドが特定できて, それによって事前・事後条件が保証される

    契約による設計と名前による型づけ, およびオブジェクトの不変性 - 貳佰伍拾陸夜日記
  • なぜ型ファーストで考えるのか - 貳佰伍拾陸夜日記

    How do you imagine a building? You consciously create each aspect, puzzling over it in stages. Inception 型なし言語に馴染みはあるものの型付言語をいざ使ってみたらどういう気持ちで書いたらいいのかわからなかったと同僚から相談があり, それをきっかけにして社内の勉強会で以下の話をしました. よく型なし vs. 型付の文脈では「型を書くのは面倒だ」「安全の方が大事だ」「でも面倒だ」「それは型推論を前提にしていないからだ」などの議論になりがちな気がしますが、これはあくまで「計算ありきの型」を考えているからで, 「型ありきの計算」だと全く見え方が違います. 「型はある種の仕様」とおもえば, 型ファーストであることと, 型なし言語でテスト駆動開発(TDD)するときに最初にテストを書くこととは, 同じ

    なぜ型ファーストで考えるのか - 貳佰伍拾陸夜日記
    mizdra
    mizdra 2020/02/24
    良い / 前半は何故型は仕様であると言えるのかを理論的に説明し,後半では仕様としての型の表現力の限界と表現力向上の取り組みについて紹介している
  • 1