関数型プログラミングは全部理解しようとすると難しいですが、簡単な部分の中にも有用な知見がたくさんあります。 関数型プログラミングにまだ親しんでいない人向けに、明日からのプログラミングにすぐ役に立つ考え方をできるだけわかりやすく伝えます。
こわくない関数型プログラミング
関数型プログラミングは全部理解しようとすると難しいですが、簡単な部分の中にも有用な知見がたくさんあります。 関数型プログラミングにまだ親しんでいない人向けに、明日からのプログラミングにすぐ役に立つ考え方をできるだけわかりやすく伝えます。
見通しの悪いコードができあがってしまう、その理由 - Magnolia Tech
クソコードができあがるのは「影響の及ぼすコンポーネント量を最小にする」という個別最適の価値観が支配的になった時、です 影響の及ぶ範囲を小さくするために、巨大で複雑なコードの塊を一箇所に追加し始めたりするのです そうした方が関心の範囲が限定できるから...だけど、全体最適ではない— magnoliak🍧 (@magnolia_k_) 2022年3月12日 でも悪気はないんです 真面目に巨大で見通しの悪いコードを作り上げていくけど、影響範囲が最小になる方が常に正しい、という価値観は「わかりやすい」んですよ— magnoliak🍧 (@magnolia_k_) 2022年3月12日 「変更量が最小になる」「影響が最小になる」...目の前のタスクをこなすためには、それが一番良いことに見えるんですよね でも、「継続的に同じペースが保てるか？」「スケールするか？」というと、そんなことは無いけど、そ
毎週やってる定例会のアジェンダに「これは月末の会で」としておくとスキップされがち - hitode909の日記
開発しているアプリケーションのフロントエンドの様子を見る会（フロントエンド草むしり会）を毎週30分ずつ開催している。 式次第の雰囲気を紹介するとこういう形で、毎週見るメトリクスやエラーに加えて、月に1回くらい様子を見たい項目もある。 アップデート関連は、Pull Requestが出たら都度対処するのだけど、それに加えて最近の様子はどうだろう、と眺める時間を取りたい。そういうものは月に1回くらい見ることにしている。 毎週 この会の大義を確認しよう 終わってない宿題を眺めよう エラーのメトリクスを見よう パフォーマンスのメトリクスを見よう 月の初めの会のみ Dependency Dashboardのアップデート候補を見よう Dependabot alertsを見よう ここで「月の初めの会のみ」としているのがポイントで、今回が月の初めかどうかは誰が見ても明らかで、間違いが起きにくい。 これを仮に
ドメイン知識を隠すコード、隠さないコード - Magnolia Tech
2021/12/20追記 指摘されて気づいてしまいましたが、間違ってますね... 以前スライドを書いた時に全然気づいていませんでした 反省のために消さずに、取り消して残しておきます 「年齢計算ニ関スル法律」という法律がある。 明治三十五年法律第五十号（年齢計算ニ関スル法律） | e-Gov法令検索 とても短い法律で条文は3つしかない。 ① 年齢ハ出生ノ日ヨリ之ヲ起算ス ② 民法第百四十三条ノ規定ハ年齢ノ計算ニ之ヲ準用ス ③ 明治六年第三十六号布告ハ之ヲ廃止ス ポイントは①で、生まれた日から起算するので法律上は1年が経過した時に1つ歳を取ることになる。つまり、誕生日の前の日の24時に年齢が加算されるので、日単位でみると誕生日の前の日にもう年齢は進んでいる、ということになる。 同じ年の4月2日生まれの人と、4月1日生まれの人とでは小学校に入学する年度が違う、というのはよく聞く話だと思う。 この
クリーンアーキわからんかった人のためのクリーンじゃないけどクリーンみたいなオニオンに見せかけたSOLIDの話
依存関係逆転則含む諸原則に苦しめられた方々，いかがお過ごしでしょうか． 今回はアプリ設計の話です．と言っても，前回「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」というZenn記事を書いて，反響が大きかったのでリメイクしたいなという気持ちになり執筆することにしました． 前回同様，調べていく上で誤解していた部分や理解しにくかった部分を語った上で，オニオンアーキテクチャという，クリーンじゃないけどクリーンみたいな玉ねぎについて紹介するのですが，今回はわかりやすい図解であったり，実際にどのような実装をしていくべきなのかを話の話題として加えていければ良いかな？って思っています． これは前回の記事である「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」の記事の裏話的な話を一つさせてください． 今年の11月初め頃に，サポーターズという企業の学生が登壇できるLT会があり，私
なぜ組織の透明性が大切なのか - 30歳からのプログラミング
個人的に、組織の透明性というものに関心を持っている。自分にとって大切なことだし、組織にとっても大切だと思っている。 この記事では、透明性に対する現時点での考えを書いていく。今の自分の頭のなかのスナップショットのようなものなので、あまり整理されていない。 大きく分けて、なぜ透明性が大切なのか、そして透明性を実現するために大切だと思っていることについて、書いていく。 透明性とは何か、透明性が高いとは具体的にどういう状況のことなのか、といった話は扱わない。取り敢えず、情報や意思決定のプロセスがオープンになっており誰でも制限なくアクセスできる、くらいの意味で書いている。本当はそれだけでは不十分で、情報のメンテナンスやサマライズ、適切な通知やアナウンス、なども必要になってくるが。 なぜ透明性が大切なのか 透明性に問題があると何が起こるのか、という角度から述べていく。 モチベーションが下がる もしかし
けしからん日本に足りないのは“船を作ろうとしないこと” 登大遊氏が語る「シン・テレワークシステム」のオープンソース化とデジタル敗戦解消のためにとるべき道筋
オープンソース化を目指している「シン・テレワークシステム」 ーーここからは、登さんが作られた「シン・テレワークシステム」についておうかがいしたいと思います。このシステムは、現在約18万人の方が利用されていますが、今現在はどのようなことを行っているのでしょうか？ 登大遊氏（以下、登）：「シン・テレワークシステム」はIPAとNTT東日本で作ったソフトウェアで、確かに十数万人が使っていますが、まだ実験フェーズでして。今後は本格化を目指していて、そのために、同じシステムのものを日本国内のどんな事業者、ITエンジニア、とにかく誰でも同じものを自分で構築して運営できるようにしようと思って改良しています。 つまり、オープンソース化です。技術の秘密の部分はなくして、全日本人の方々に、無料で全部共有・公開して、使用制限も設けず、誰でも自分の会社の専用シン・テレワークシステムや、お客さんのために、自社ブランド
リーダブルなコードを書く習慣の身に付け方・実践の仕方 - 2021-09-22 - ククログ
結城です。 2021年9月13日から14日にかけて、東京都立大学の大学院生向け特別講義として「リーダブルコード演習」を実施しました。 演習の内容は、当社でこれまでにも行ってきているリーダブルコードワークショップを、プログラミング経験が比較的浅い・プログラミングの量がまだそれほど多くない方向けに調整した内容としました。 この記事では、実施した演習の概要と、今回意識した点を紹介します。 本文が長いため、目次を用意してみました。 発端 演習の構成 座学パート リーダブルなコードを書く意義について リーダブルコードを実践するためにまず取り組むべきこと 実際の現場での「コードがリーダブルでなくなってしまった」「リーダブルになるよう改めた」実践例 最初の実装 リーダブルでなくなった実装 リーダブルさを取り戻すための改修 コードがリーダブルでなくなっていってしまう要因 壊すのが怖くて、見て見ぬフリ 恐怖
関数型プログラミングはまずは純粋関数型言語を用いて、考え方から理解しよう
この記事は、関数型プログラミングはまず考え方から理解しよう の記事を純粋関数型言語Elmで書き換え、一部の文章について批判的に言及させていただいた記事になります。この記事を書こうと思ったきっかけとしては、今回参考にさせていただきた記事が過去に書かれたものにも関わらず、今に渡っても見られていそうなこと。未だにパラダイムの理解に関する誤解が多く散見されること。改めて純粋関数型言語の実用性・有用性について、見直されるべきだと思い、この記事を執筆させていただきました。 次のステップアップ記事は、[超入門] FizzBuzzで考える関数型プログラミング学習を純粋関数型言語でやる理由です。 はじめに、この記事の主張を結論としてまとめておきます。 対比すべきは、関数型プログラミングとオブジェクト指向プログラミングではなく、関数型プログラミングと手続き型プログラミングである 関数型プログラミングの考えを学
中学・高校数学で学ぶ、数学×Pythonプログラミングの第一歩
中学・高校数学で学ぶ、数学×Pythonプログラミングの第一歩：数学×Pythonプログラミング入門 「Pythonの文法は分かったけど、自分では数学や数式をプログラミングコードに起こせない」という人に向けて、中学や高校で学んだ数学を題材に「数学的な考え方×Pythonプログラミング」を習得するための新連載がスタート。連載コンセプトから、前提知識、目標、本格的に始めるための準備までを説明する。 連載目次 この連載では、中学や高校で学んだ数学を題材にして、Pythonによるプログラミングを学びます。といっても、数学の教科書に載っている定理や公式だけに限らず、興味深い数式の例やAI／機械学習の基本となる例を取り上げながら、数学的な考え方を背景としてプログラミングを学ぶお話にしていこうと思います。 今回は、それに先だって、プログラミングを学ぶ上で数学を使うことのメリットや、Pythonでどのよう
綺麗なコミットログを作りたいときのgitテクニック - Qiita
これは何 僕は開発作業をしているとき、PRをあげるまでの開発途中はwipコミットに変更を記録していき、最後にコミットを仕上げていくような作業をよくします。 初めからコミットを綺麗に書きながら開発ができれば良いのですが、 にあるようなコミットログを仕上げていこうと思うとどうしても最後にコミットログを整理したくなります。 この記事はこのようにgitを使うと綺麗なコミットログを作れるよ、というTipsです。 具体的にこういうコミットを作ると良いよ、みたいな話はこの記事ではしません。 僕はこのような工程でPRを出す前にコミットログを作っています。 git rebase -iで作業中のコミットを全て一つのコミットにsquashする git reset HEAD~で一度コミットを取り消す git add -pで作りたいコミットごとに変更をstageにあげていく コミットを作成する git rebase
レビューで大量の指摘をして大きな手戻りを発生させた原因はレビューアの私にあった - Qiita
はじめに 私は十年近く前、レビューで大量の指摘を登録することが何度かありました。 当然、大量の指摘修正をしてもらうという行為は、手戻りであり、それだけプロジェクトの進捗を遅らせることになりました。 とても恥ずかしい話ですが、当時の私は、レビューで大量の指摘で手戻る原因が、レビューイにあると思い込んでいました(本当にごめんなさい)。 しかし、今、振り返ってみると、手戻りの原因はレビューアである私にあったと思います。 そのような恥ずかしい自分の行動を戒めるために、どれだけ当時の自分が残念だったのかを紹介します。 要するに反省文のようなものです。 今回対象とするレビューの前提条件 今回紹介するレビューは、以下の条件を満たすものでした。 レビュー対象の成果物は、以下のいずれか。 外部仕様書 設計書 テスト仕様書 ソースコード レビューイは、レビュー対象成果物を作成した経験が浅い(数回の経験)。 レ
どうして Julia を作ったか
プログラミング言語「Julia」開発者さんの文章がとても好きなので、雰囲気重視で訳しました。結構意訳です。原典：https://julialang.org/blog/2012/02/why-we-created-julia/ =================================================「どうして Julia を作ったか」 それは、僕らが欲張りだからだ。 Matlab はめっちゃ使う。僕らの中にはLispの天才もいるし、PythonやRuby のすげー奴、Perl を巧みに使いこなす奴もいる。毛も生えない子供の頃からMathematica で遊んだ奴もいる。いまだにツルツルな奴だって仲間だ。Rではアホみたいにたくさんグラフを書いた。C言語からは、いつだって冒険の匂いがする。 ぜんぶ、大好きだ。面白いし、いろいろなことができる。何かをしたいと思った時--科
プログラミングと法律の相違点 _ 演算子(1) ORなのかXORなのか｜ぴよふ
プログラマが気を付けることの1つは条件式に記述するときの演算子ですよね。&& じゃなくて || って書いてしまった。とか <= にすべきところを < だけにしちゃったとか。 法律の条文にも私がぶち当たった演算子があります。それが"または"です。 "または" って本当にORですか？何言ってんだ？当たり前やろ！と思うかもしれません。 結論から言うと法律の"または"(又は) はあなたが想像する"OR"じゃないんです… 私は最初のころよくわかっていませんでした。先生に聞いても質問の意図が分かってもらえなかったし、Google先生に聞くとそのものズバリな回答もあったのですが、なんだかモヤモヤした結論でした。 法律の条文で"または"が出てきたらそれはXORです。もうこれが今回の記事のすべてなんでここで終わってもいいんですがちょっと説明します。 ORは一般的に論理和と呼ばれ、XORは排他的論理和と呼ばれ
技術的に難しいことを力技でやってしまうこと - orangeitems’s diary
まあお悩みですけどね、技術的に難しいことってありますよね。で、他のメンバーに任せておくと、いつ終わるかわからない。聞いてもわからんわからんばかりで、こりゃダメだと言う時のことです。 いつものように、それ私が引き取るよ、ってその課題を引き取って、難易度の低いタスクを他のメンバーに任せます。まあそのタスクも大量なので、誰かがやらなきゃいけないし、高度な問題のために大量のタスクが積みあがるのもそれはそれでまずい。適材適所と言えばそうなのですが、本当にこれでいいのかなと毎回思います。 だって、またこの高度な問題に対するトラブルシューティングを見ることなく、メンバーは最終的に「できた」という形を手順書なりなんなりで確認することになります。ああこうやればできたのか、という感動があればまだいいですが、忙しいのでそんなことしている暇は多分ありません。 これ、私はまたスキルを一つ積み上げたのですが、どう考え
Javaのプロが避ける「波かっこ」の“駄目”な使い方とは？
関連キーワード 統合開発ツール | プログラマー | プログラミング プログラミング言語には根本的な共通点がある。一般的に、 変数宣言 条件式 関数 という3つの要素から成ることだ。条件式を評価して、その結果に応じて演算する関数の集合体がソースコードになる。 どのようなプログラミング言語でも、こうした基本的な考え方に変わりはない。処理の集合としてソースコード全体を記述する「手続き型」か、データと処理（メソッド）をまとめて定義した「オブジェクト」を組み合わせる「オブジェクト指向型」かにかかわらず、プログラミング言語に共通した考え方だと言える。 プログラミング言語によって大きく違うのが、「波かっこ」（「ブレース」「中かっこ」とも）の使い方だ。 そもそも「波かっこ」は何のためにあるのか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【連載】Let’s 競技プログラミング! E8さんが教える アルゴリズム発想のキホン
数学×Pythonプログラミング入門
ソフトウェア開発における『知の高速道路』
著書54冊!? エンジニアかつ「数学ガール」著者の結城さんが語る、エンジニアのメンタルマネジメントのすゝめ
