タグ

programmingに関するmotchangのブックマーク (709)

  • こわくない関数型プログラミング

    関数型プログラミングは全部理解しようとすると難しいですが、簡単な部分の中にも有用な知見がたくさんあります。 関数型プログラミングにまだ親しんでいない人向けに、明日からのプログラミングにすぐ役に立つ考え方をできるだけわかりやすく伝えます。

    こわくない関数型プログラミング
  • 過度なDRYは読みやすさの敵!?「リーダブルテストコード」という発表をしました #vstat - give IT a try

    先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの? ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ!」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「

    過度なDRYは読みやすさの敵!?「リーダブルテストコード」という発表をしました #vstat - give IT a try
    motchang
    motchang 2022/08/01
    “仕様変更が発生すると大量のテストが失敗することもあります。ただ、それはデメリットではなく、仕様変更のインパクトがテストコードのおかげで可視化された、と好意的に捉えるようにしましょう。”
  • GitHub - codecrafters-io/build-your-own-x: Master programming by recreating your favorite technologies from scratch.

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - codecrafters-io/build-your-own-x: Master programming by recreating your favorite technologies from scratch.
  • Functional programming is finally going mainstream

    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

    Functional programming is finally going mainstream
  • PlayStationエミュレータ作りに取り組んだ

    最近暇だったのでPlayStationのエミュレータ作りに取り組みました。そのまとめをしたいと思います。 PlayStationエミュレータ作りと聞くと難しそうに聞こえますが、実はかなり分かりやすいガイドブックが存在し、これに従うことであまり詰まることなく実装できました。 結果として5日ほどで、懐かしいオレンジのロゴが見れる程度の必要最低限の実装が行えたので、紹介したいと思います。 ※テクスチャは未実装なのでロゴが赤い四角になってる The ガイドブック 以下のPDFは、CPUの仕組みの簡単な説明から入り、0からBIOSのオレンジのロゴが表示できることろまで網羅した神ガイドブックです。言語は英語Rustです。 https://svkt.org/~simias/guide.pdf 普段のエミュレータ作りで時間のかかる作業は: 地獄のデバッグ PCのタイミング調整(パイプラインがある場合)

    PlayStationエミュレータ作りに取り組んだ
  • 共通化すれば良いとは限らない - Object.create(null)

    ここのところ偶然なのか「共通化」という言葉を多く聞いているのですが, その言葉を聞くたびに身構えていることに気がついたので, この気持ちの出どころを共有しておきます. なぜ身構えているかというと, 共通化が必ずしもコードを良い状態にするとは限らないにも関わらず, それ自体が目的になってしまっている (ように見える) ことが多いからです. この手のリファクタリングの目的はあくまでコードの改善のはずで, そのことを忘れて共通化するだけで満足してしまうと, 良くてリファクタリングの効果が半減, 悪ければ逆効果になってしまいます. 個人的にコードを共通化する上で注意してほしいと思っているのは以下の二つです. コードを共通化すべきでない場合もある 共通化されたコードは一般的な原則にしたがって設計されなければならない 似たようなことは歴史の中で何度も繰り返し言われていることだろうと思いますが, 改めて

    共通化すれば良いとは限らない - Object.create(null)
    motchang
    motchang 2022/07/05
    良い記事だな
  • golangではスタックとヒープを気にする必要が無い

    調べようと思ったきっかけは、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

    golangではスタックとヒープを気にする必要が無い
  • Linux で C/C++ の足固め: Linux の メモリー/ファイル/mmap と C++ アロケーター

    図の一覧 30.1. メインアリーナ(main_arena)30.2. スレッドアリーナ32.1. 割り当て済みチャンク(allocated chunk)32.2. 割り当て済みチャンクの内部(allocated chunk)32.3. フリーチャンク(free chunk)32.4. フリーチャンクの内部(small free chunk、大きめでない場合)39.1. Unsorted/Small/Large Bins39.2. Large Bins68.1. 一段ページテーブル構成68.2. 二段ページテーブル構成68.3. Linux 三段ページテーブル(Linux 2.6.11以前)

  • プログラムを「書き始める」「試しに実行する」コストを下げる工夫

    はじめに 物事を上達するためには反復を、というのはよく聞きますが、もちろんプログラミングでも大事なのかと思います。とくに自分は「一を聞いて十を知る」ような器用なことはできないので、何度も何度もプログラムを書いて、試していました。 このような反復を支援するためには、できるかぎり「書き始めるコスト」と「実行して確認するコスト」は低い方がいいと思っています。書き始めるのがだるいと、そもそも「ちょっと書いてみようかな」となかなか思わないですし、実行するための手数が多いと、「書いて→結果を確認」の回数が減ります。 稿では、この「書き始めるコスト」と「実行して確認するコスト」を下げる私が20年くらい行っている工夫についてご紹介します。 筆者が Ruby が好きなので、Ruby の例が多いですが、別に Ruby に限った話ではありません。 プログラミング言語による違い たとえば、C 言語ですと、プログ

    プログラムを「書き始める」「試しに実行する」コストを下げる工夫
  • Semgrep — Find bugs and enforce code standards

    Semgrep CodeFind and fix the issues that matter in your code (SAST)

    Semgrep — Find bugs and enforce code standards
  • 人材獲得作戦・3 - 人生を書き換える者すらいた。

    求人サイトに広告を出して3週間。 実に応募者はたくさん来たものです。40~50人はいました。ゾンビのごとくわらわらと集まってきたよ。 今回は、手っ取り早くふるいにかけるために、最初にプログラミングの実技試験をやりました。都合のよい日時を申告してもらい、その時刻になったら問題を送信(それも僕はcronで仕込むだけ)、応募者は時間内に回答のソースコードをメールで提出、という形式。 これなら定型的なメールのやりとりでほとんどの作業が済むし、僕の時間の節約になる。 これから試験を受ける人もいるので問題の内容は非公開だけども、ちょっとしたパズルを解くアルゴリズムを考えて実装する、というタイプの問題です。 プログラム言語は自由(受験者が得意なものを使ってよい)、標準入出力を使うだけなのでOSも自由、制限時間3時間としました。 ちなみに僕がこれを自分で解いてみたときは、C#を使って25分でできた。 とこ

    人材獲得作戦・3 - 人生を書き換える者すらいた。
  • HireRoo | コーディング試験で防ぐエンジニア採用ミスマッチ

    HireRoo(ハイヤールー)はエンジニア採用における、採用ミスマッチを防ぐためのコーディング試験サービスです。AIを用いてスキルを可視化し定量的に技術力を測ります。2週間の無料トライアル受付中!

    HireRoo | コーディング試験で防ぐエンジニア採用ミスマッチ
  • 君には今から3時間で機械学習Webアプリを作ってもらうよ

    新人: 「日データサイエンス部に配属になりました森です!」 先輩: 「お、君が新人の森さんか。僕が上司の馬庄だ。よろしく!」 新人: 「よろしくお願いします!」 先輩: 「さっそくだけど、練習として簡単なアプリを作ってみようか」 先輩: 「森くんは Python なら書けるかな?」 新人: 「はい!大学の研究で Python 書いてました!PyTorch でモデル作成もできます!」 先輩: 「ほう、流石だね」 新人: 😊 先輩: 「じゃ、君には今から 3 時間で機械学習 Web アプリを作ってもらうよ」 先輩: 「題材はそうだなぁ、写真に写ってる顔を絵文字で隠すアプリにしよう」 先輩: 「あ、デプロイは不要。ローカルで動けばいいからね。顔認識と画像処理でいけるよね?」 新人: 😐 新人: (えぇぇぇぇぇぇぇ。3 時間?厳しすぎる...) 新人: (まずモデルどうしよう。てかもら

    君には今から3時間で機械学習Webアプリを作ってもらうよ
  • 高卒30歳が三ヶ月でAtCoder緑になれたので色変記事書く

    似たような記事はいくらでもありますが、自分を追い込むために記録しておきます。 こんだけイキリ散らしておいて茶ランクに落ちたら相当恥ずかしいぞ俺。 レート推移 緑二回目のコンテストで参加回数14回なので、緑に上がったのは13回目のコンテストですね。 スペック タイトルはちょっと盛っていて、高卒は高卒でも大学中退です。大学は一応理系でしたが、プログラミングとは全く無関係。 業務ではVBAを使っているくらいで、IT業界は未経験。 AtCoderでは独学で身につけたRubyを使っています。 AtCoderを始めた理由 転職したかったんです……。(結論) 詳述すると、某転職サイトにて転職活動していた所、そのサイトに競技プログラミング機能がありました。 企業へのアピールになるとの事で挑戦してみたのですが、最高ランクの一歩手前で行き詰まってしまったのです。 こりゃダメだ、というわけで、とりあえずAtCo

    高卒30歳が三ヶ月でAtCoder緑になれたので色変記事書く
  • 累積和を何も考えずに書けるようにする! - Qiita

    0. はじめに 最近では AtCoder がコーディング面接の文脈でも有効なものとしての認識が広まってきています。AtCoder の登竜門といわれる水色を目指すにあたって多くの方が「勉強した」と報告している代表的なアルゴリズム的手法の一つに累積和があります。 今回はそんな累積和をストレスなく機械的に書けるようになることを目標とします。累積和は、そのコンセプト自体は簡明で決して難しくないのですが、 添字の扱い方など、頭がゴッチャになりがちである 応用範囲が非常に広い ということから、整理する価値の高い手法です。僕自身、累積和を用いる問題に対して、毎回添字の扱いに神経を尖らせながら頑張っていたのですが、一度実装テンプレートを決め込んでしまえば何も考えなくても書けるようになりました。そうなってからは累積和を実装することにストレスが無くなりました。 そんな体験を共有できたらと思います。 1. 累積

    累積和を何も考えずに書けるようにする! - Qiita
  • ユークリッドの互除法 - Wikipedia

    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 との最大公約数となる。 明示的に記述された最古のアルゴリズムと

    ユークリッドの互除法 - Wikipedia
  • 【色変】全完黄パフォで入水しました! - Lorent’s diary

    一昨日5/3(日)のABC166で初の全完を果たし、さらに黄パフォで入水いたしました! そこで、他の競プロerもすなる色変記事というものを、私もしてみむとてするなり、です。 ただし、読んでいただく前に一つ注意書きを。 この色変記事を書くにあたって、十数人の方の色変記事を読ませていただいたのですが、 そうして思ったのは「精進の仕方は十人十色」だということです。 ですので、以下に書かれている内容は、「おすすめの精進法」ではなく、あくまでも「精進の仕方の一つ」として読んでいただければ幸いです。 私自身のことに関しては、前回の記事で書きましたので、もしご興味のある方はそちらも読んでいただけると嬉しいです。 各種精進データ 入水までに勉強したアルゴリズム 前提として ☆☆☆:入緑でも確実に必要になるはず ☆☆★:まあまあよく使う ☆★★:数回使ったことがある ★★★:コンテストではまだ一度も使ったこ

  • 東京工業大学デジタル創作同好会traP

    traPについて 『デジタル創作同好会traP』は、 東京工業大学で活動するデジタル創作・プログラミング系サークルです。 ゲーム制作を中心に、アプリ、音楽DTM)、グラフィック(イラスト、3Dモデル、ドット絵、動画)などのクリエイティブ活動の他、競技プログラミング競プロ)やCTFも行っています。 もっと詳しく! 活動ピックアップ

    東京工業大学デジタル創作同好会traP
  • 『Value Objectについて整理しよう - Software Transactional Memo』へのコメント

    これ/問題の複雑さに合わせて膨れ上がるコードの複雑さをうまく統治するためにプラクティスを適宜使っていこうという順序で考えるべきであって、プラクティスの導入自体がコードに複雑さを加えるのであれば末転倒

    『Value Objectについて整理しよう - Software Transactional Memo』へのコメント
  • Value Objectについて整理しよう - Software Transactional Memo

    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

    Value Objectについて整理しよう - Software Transactional Memo