関数型プログラミングは全部理解しようとすると難しいですが、簡単な部分の中にも有用な知見がたくさんあります。 関数型プログラミングにまだ親しんでいない人向けに、明日からのプログラミングにすぐ役に立つ考え方をできるだけわかりやすく伝えます。
先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの? ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ!」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「
Paul Louth had a great development team at Meddbase, the healthcare software company he founded in 2005. But as the company grew, so did their bug count. That’s expected, up to a point. More code and more features mean more defects. But the defect rate was growing faster than Louth expected. “We were seeing more and more of the same types of bugs,” Louth says. “It was clear that there was an issue
最近暇だったのでPlayStationのエミュレータ作りに取り組みました。そのまとめをしたいと思います。 PlayStationエミュレータ作りと聞くと難しそうに聞こえますが、実はかなり分かりやすいガイドブックが存在し、これに従うことであまり詰まることなく実装できました。 結果として5日ほどで、懐かしいオレンジのロゴが見れる程度の必要最低限の実装が行えたので、紹介したいと思います。 ※テクスチャは未実装なのでロゴが赤い四角になってる The ガイドブック 以下のPDFは、CPUの仕組みの簡単な説明から入り、0からBIOSのオレンジのロゴが表示できることろまで網羅した神ガイドブックです。言語は英語とRustです。 https://svkt.org/~simias/guide.pdf 普段のエミュレータ作りで時間のかかる作業は: 地獄のデバッグ PCのタイミング調整(パイプラインがある場合)
ここのところ偶然なのか「共通化」という言葉を多く聞いているのですが, その言葉を聞くたびに身構えていることに気がついたので, この気持ちの出どころを共有しておきます. なぜ身構えているかというと, 共通化が必ずしもコードを良い状態にするとは限らないにも関わらず, それ自体が目的になってしまっている (ように見える) ことが多いからです. この手のリファクタリングの目的はあくまでコードの改善のはずで, そのことを忘れて共通化するだけで満足してしまうと, 良くてリファクタリングの効果が半減, 悪ければ逆効果になってしまいます. 個人的にコードを共通化する上で注意してほしいと思っているのは以下の二つです. コードを共通化すべきでない場合もある 共通化されたコードは一般的な原則にしたがって設計されなければならない 似たようなことは歴史の中で何度も繰り返し言われていることだろうと思いますが, 改めて
調べようと思ったきっかけは、golang では以下のように ローカル変数のアドレスを戻り値としても問題ないということ。 package main import ( "fmt" ) type Animal struct { Name string Age int } func main() { animal := allocAnimal() fmt.Printf("allocate animal structure %p", animal) } func allocAnimal() *Animal { return &Animal{} } C/C++ ではローカル変数のポインタを戻り値とした場合、 スタック領域のポインタを関数外に渡してしまうため、コンパイル時点で警告が表示されます (なぜエラーにしない) 実行時には最悪、セグメンテーションフォールトで落ちます そのため、malloc や n
はじめに 物事を上達するためには反復を、というのはよく聞きますが、もちろんプログラミングでも大事なのかと思います。とくに自分は「一を聞いて十を知る」ような器用なことはできないので、何度も何度もプログラムを書いて、試していました。 このような反復を支援するためには、できるかぎり「書き始めるコスト」と「実行して確認するコスト」は低い方がいいと思っています。書き始めるのがだるいと、そもそも「ちょっと書いてみようかな」となかなか思わないですし、実行するための手数が多いと、「書いて→結果を確認」の回数が減ります。 本稿では、この「書き始めるコスト」と「実行して確認するコスト」を下げる私が20年くらい行っている工夫についてご紹介します。 筆者が Ruby が好きなので、Ruby の例が多いですが、別に Ruby に限った話ではありません。 プログラミング言語による違い たとえば、C 言語ですと、プログ
Semgrep CodeFind and fix the issues that matter in your code (SAST)
求人サイトに広告を出して3週間。 実に応募者はたくさん来たものです。40~50人はいました。ゾンビのごとくわらわらと集まってきたよ。 今回は、手っ取り早くふるいにかけるために、最初にプログラミングの実技試験をやりました。都合のよい日時を申告してもらい、その時刻になったら問題を送信(それも僕はcronで仕込むだけ)、応募者は時間内に回答のソースコードをメールで提出、という形式。 これなら定型的なメールのやりとりでほとんどの作業が済むし、僕の時間の節約になる。 これから試験を受ける人もいるので問題の内容は非公開だけども、ちょっとしたパズルを解くアルゴリズムを考えて実装する、というタイプの問題です。 プログラム言語は自由(受験者が得意なものを使ってよい)、標準入出力を使うだけなのでOSも自由、制限時間3時間としました。 ちなみに僕がこれを自分で解いてみたときは、C#を使って25分でできた。 とこ
新人: 「本日データサイエンス部に配属になりました森本です!」 先輩: 「お、君が新人の森本さんか。僕が上司の馬庄だ。よろしく!」 新人: 「よろしくお願いします!」 先輩: 「さっそくだけど、練習として簡単なアプリを作ってみようか」 先輩: 「森本くんは Python なら書けるかな?」 新人: 「はい!大学の研究で Python 書いてました!PyTorch でモデル作成もできます!」 先輩: 「ほう、流石だね」 新人: 😊 先輩: 「じゃ、君には今から 3 時間で機械学習 Web アプリを作ってもらうよ」 先輩: 「題材はそうだなぁ、写真に写ってる顔を絵文字で隠すアプリにしよう」 先輩: 「あ、デプロイは不要。ローカルで動けばいいからね。顔認識と画像処理でいけるよね?」 新人: 😐 新人: (えぇぇぇぇぇぇぇ。3 時間?厳しすぎる...) 新人: (まずモデルどうしよう。てかもら
似たような記事はいくらでもありますが、自分を追い込むために記録しておきます。 こんだけイキリ散らしておいて茶ランクに落ちたら相当恥ずかしいぞ俺。 レート推移 緑二回目のコンテストで参加回数14回なので、緑に上がったのは13回目のコンテストですね。 スペック タイトルはちょっと盛っていて、高卒は高卒でも大学中退です。大学は一応理系でしたが、プログラミングとは全く無関係。 業務ではVBAを使っているくらいで、IT業界は未経験。 AtCoderでは独学で身につけたRubyを使っています。 AtCoderを始めた理由 転職したかったんです……。(結論) 詳述すると、某転職サイトにて転職活動していた所、そのサイトに競技プログラミング機能がありました。 企業へのアピールになるとの事で挑戦してみたのですが、最高ランクの一歩手前で行き詰まってしまったのです。 こりゃダメだ、というわけで、とりあえずAtCo
0. はじめに 最近では AtCoder がコーディング面接の文脈でも有効なものとしての認識が広まってきています。AtCoder の登竜門といわれる水色を目指すにあたって多くの方が「勉強した」と報告している代表的なアルゴリズム的手法の一つに累積和があります。 今回はそんな累積和をストレスなく機械的に書けるようになることを目標とします。累積和は、そのコンセプト自体は簡明で決して難しくないのですが、 添字の扱い方など、頭がゴッチャになりがちである 応用範囲が非常に広い ということから、整理する価値の高い手法です。僕自身、累積和を用いる問題に対して、毎回添字の扱いに神経を尖らせながら頑張っていたのですが、一度実装テンプレートを決め込んでしまえば何も考えなくても書けるようになりました。そうなってからは累積和を実装することにストレスが無くなりました。 そんな体験を共有できたらと思います。 1. 累積
252と105のためのユークリッドの互除法のアニメーション。 クロスバーは、最大公約数(GCD)である21の倍数を表す。 それぞれのステップにおいて、1つの番号がゼロになるまで、より少ない数はより大きな数から引かれる。 残りの数は、GCD。 ユークリッドの互除法(ユークリッドのごじょほう、英: Euclidean Algorithm)は、2 つの自然数の最大公約数を求める手法の一つである。 2 つの自然数 a, b (a ≧ b) について、a の b による剰余を r とすると、 a と b との最大公約数は b と r との最大公約数に等しいという性質が成り立つ。この性質を利用して、 b を r で割った剰余、 除数 r をその剰余で割った剰余、と剰余を求める計算を逐次繰り返すと、剰余が 0 になった時の除数が a と b との最大公約数となる。 明示的に記述された最古のアルゴリズムと
一昨日5/3(日)のABC166で初の全完を果たし、さらに黄パフォで入水いたしました! そこで、他の競プロerもすなる色変記事というものを、私もしてみむとてするなり、です。 ただし、読んでいただく前に一つ注意書きを。 この色変記事を書くにあたって、十数人の方の色変記事を読ませていただいたのですが、 そうして思ったのは「精進の仕方は十人十色」だということです。 ですので、以下に書かれている内容は、「おすすめの精進法」ではなく、あくまでも「精進の仕方の一つ」として読んでいただければ幸いです。 私自身のことに関しては、前回の記事で書きましたので、もしご興味のある方はそちらも読んでいただけると嬉しいです。 各種精進データ 入水までに勉強したアルゴリズム 前提として ☆☆☆:入緑でも確実に必要になるはず ☆☆★:まあまあよく使う ☆★★:数回使ったことがある ★★★:コンテストではまだ一度も使ったこ
これ/問題の複雑さに合わせて膨れ上がるコードの複雑さをうまく統治するためにプラクティスを適宜使っていこうという順序で考えるべきであって、プラクティスの導入自体がコードに複雑さを加えるのであれば本末転倒
Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く