はじめに この記事について ときどき見かけるこの話題、最近も少し話題になっていたので、自分の考えをまとめておきたいので記事にしました。関数型言語が好きなので、その点でバイアスかかってると思いますが、なるべく客観的に書くつもりです。 結論 命令型（imperative）と宣言型（declarative）という異なるパラダイムが同一のプログラミング言語に混ざるのが当たり前になってきたので、こういう議論が起きるんだと思いますが、そもそも異なるパラダイムなので、どちらが良いか悪いかというよりもどのように捉えるかの違いでしかないのだと思います。 コードによる比較 こちらの記事から拝借しました。 gakuzzzz.github.io 命令型における for（あるいはループ） const forStrategy = (products: Product[]) => { let result: Produ
はじめに この記事について misskey.dev Advent Calendar 19日目の記事です。 adventar.org 私は misskey.dev でよく仕事の文句を垂れてるんですが、それは愚痴ではなくて、課題解決のプロセスの一部です、という話を書こうと思います。 以前はそういう場所は Twitter だったんですが、人が多くなりすぎてしまった（といってもフォロワー500‐600人とかですが）ため、misskey.dev に移ってきました。 いま misskey.dev ではフォロワーは10人ていどで、ローカルにもほとんどポストしてないですし、文化的にローカルタイムラインしか見てない人も多そうですし、気楽です。 愚痴とは 本記事における「愚痴」の定義は以下とします。 言ってもしかたのないことを言って嘆くこと。 デジタル大辞泉 愚痴について まずは、愚痴に対する自分のスタンスの
はじめに この記事について 以下の記事に触発されて自分でも書いてみました。 yoric.github.io プログラミング言語が好きなので、気になったものを見つけると触るようにしているんですが、ほとんどは新たな発見や驚くような便利な機能があって、毎回感心させられます。仕事ではなかなかあれもこれもというわけにいかないのが残念ではありますが、個人で使うアプリケーションや使い捨てのプログラムを書くときには、なるべくいろんな言語で書くようにしています。 仕事と趣味を合わせて20以上の言語に触れてきましたが、それらのなかでもとくに衝撃的だった言語をいくつか選びました。 これまで触ってきた言語 だいたい時系列順ですが、似たものは近くに寄せてたりするので、順不同です。 趣味 BASIC (MS BASIC), Smalltalk, Nim, Scala, Clojure, Haskell, Kotlin
はじめに この記事について 最近、人事評価制度の策定に携わっていて、現行の仕組みの理解を深めつつ、改善点などを考えているので、その備忘録の一つです。 私はリーダと名のつくポジションも管理職もやったことがありますが、リーダーとマネジャーの違いについて深く考えずにやってきたので、遅ればせながら言語化しようとする試みでもあります。 自分の解釈なので、世間一般の定義とはずれたものもあるかもしれませんし、組織ごとに微妙に定義が違ったりするので、語義から大きく外れないようにしつつも、これから自分がこれらの言葉を発する際には明確に分けられるようにしたいです。 リーダーとは lead を辞書で引くといくつか出てきましたが、以下の2つが近そうです。 to show the way to a group of people, animals, vehicles, etc. by going in front
はじめに この記事について 最近読書感想文が多いですが、それだけ良書に出会えていることの証左でもあるので、喜ばしいことです、とくに、自分の現況にとってタイムリーなものは。 チームレジリエンス 困難と不確実性に強いチームのつくり方 作者:池田めぐみ,安斎勇樹日本能率協会マネジメントセンターAmazon 「困難と不確実性に強いチームのつくり方 」というサブタイトルに惹かれて買ってみました。 最近ひょんなことからエンジニアリングマネジャーっぽい仕事をしていて、 チームビルディングを請け負っています。これまで情報システム部の部長とか、インフラチームのリーダーとかはやったことがありますが、それほどチーム作りに長けているわけではないので、これを機に少し学びたい、と思ってたところにこの本と出会えたのは幸甚でした。 ソフトウェア開発の仕事は、まさに困難と不確実性の連続です。 作るものも不安定（なんせ「ソフ
はじめに この記事について Robert C. Martin 氏の「Functional Design: Principles, Patterns, and Practices」の日本語訳（以下、本書）が出版されたので、読んでみました。本記事はその感想文です。 関数型デザイン 原則、パターン、実践 (アスキードワンゴ) 作者:Ｒｏｂｅｒｔ Ｃ．ＭａｒｔｉｎドワンゴAmazon コード例について 本書では、関数型プログラミングのコード例を Clojure で書いていますが、本記事では最近お気に入りの Gleam で書きます（Clojure も大好きな言語ではありますが、S式が苦手っていう人は少なからずいると思うので）。 Gleam については、以下の記事でも言及していますが、まだ若い言語のため Markdown で使われているシンタックスハイライトが対応していないので、Rust のを借りてい
はじめに この記事について 「Staff Engineer 」Will Larson の日本語訳を読んだのでその感想と、日頃から思っているソフトウェアエンジニアのレベル上げについて言語化しておきたいと思います。 本書が出るまではスタッフエンジニアという役職は聞いたことがなく、日本語でスタッフというと「職員」みたいなニュアンスがあるので、言葉だけではピンときませんでしたが、本書を読んで、ぼんやりと思っていた自分の目指す場所（職位としてのポジションではなく）が明確になったような気もするので、毎度のことながら雑に書いていきます。 スタッフエンジニアとは スタッフエンジニア マネジメントを超えるリーダーシップ 作者:Will Larson日経BPAmazon このスタッフエンジニアという役職は、そのエンジニアとしてのキャリアの延長線上で、この本はシニアエンジニアを超えた先にどんなキャリアがあるのか
この記事について 「レガシーコード」とは、「保守または拡張が困難な既存のプロジェクト」（レガシーソフトウェア改善ガイドにおける定義を流用）で書かれたコードを指します。場合によっては難解なコードに対する悪意を込めて「クソコード」などと呼ばれたりしますが、個人的にはこの名前が好きになれないので、本記事ではそういう含意があったとしても「レガシーコード」で統一します。 というわけで本記事では、レガシーコードに出会ったときに自分がこれまでどう振る舞ってきたか、これからどう振る舞っていきたいか、について備忘録がてらまとめておこうと思います。 レガシーコードとは legacy という言葉の一般的な意味（遺産）が示すように、レガシープロジェクトは通常、前の開発者またはチームから引き継がれる。言い換えると、そのコードを最初に書いた人々と、いまそれを保守している人々は、同じではない。それどころか、間に何世代も
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
