本記事は、学生本人から許可を頂いて書いています。 はじまり こんにちはTECOPARK株式会社代表の三宅と言います。会社の代表作はPICO PARKという協力アクションパズルゲームです。今はゲームデザイン業務がメインですが、職業ゲームプログラマー歴が13年、メインプログラマー経験があります。 さて、事の始まりはそんな私がゲーム会社でゲームプログラマーをやってた時代にさかのぼります。私は当時、ゲームプログラマー志望の就活生のプログラムコードを見る機会がありました。ちゃんと設計されているコードを持ってくる学生ももちろんいるが、今のこのタイミングでこのレベルのものを持ってくるとなると厳しい就活になりそうだなと思う子もいました。就活のタイミングではなくもっと早いタイミングで見る機会があればいくらでもアドバイスできたのにな。そう思うこともありました。 その時、思ったのである。 「専門1年または大学1
Rubyist Hotlinksにインスパイアされて始まったイベント『Rubyistめぐり』。第5回はonkさんをゲストに迎えて、お話を聞きました。こちらは前編です。 hey.connpass.com 漫画禁止、ひたすら本を読む小学生時代 藤村：今回はonkさんに来ていただきました。よろしくお願いします。 Rubyistめぐりの趣旨を改めて説明すると、Rubyist Magazineというメディアに『Rubyist Hotlinks』という記事があって、いわゆるRubyistの人たちの生い立ちから仕事、プログラミングなどいろんな話を聞くコンテンツで、僕は駆け出しのエンジニアの頃にそれをすごく読んでました。めちゃくちゃ僕は影響を受けたし、いいなと思っていたので、もっと出ないかなと思ってたんですよね。 それでふと思いついて、この『Rubyistめぐり』という企画をさせてもらいました。今回はいつ
DDD以外の設計手法についてご教示いただきたく、DDDの主張をある程度正確に理解した上でDDDをこき下ろしているイメージの強いくまぎさんに質問させていただきました。 最近はソフトウェアの設計について調べると、DDDについての記事ばかりで辟易する一方、私がエンジニアになった頃にDDDに勢いがあった影響もあって私自身DDD以外の良い設計とされているものを知らず、DDDに胡散臭さを感じつつもDDDの考え方にとらわれている、毒親の影響を受けた子供のような状態から抜け出せずにいます。 その最たる例がリポジトリパターンです。 よく依存性の逆転・DIと一緒に語られますが、くまぎさんがおっしゃる通り余計にインターフェースを切るのはイケてないと感じます。また、DI抜きにしても、リポトリパターン由来の様々な問題（N＋1やバルクアップデート、管理画面用のメソッド生やしたくなる問題など）に対する解決策として提示さ
※月単価80万円を基準に、7ヶ月分の工数として560万円相当と換算しています。 最初に こんにちは！ 普段はIT企業でWebエンジニアとして働いています。 現在はフリーランスとして活動し、Ruby（Ruby on Rails）、TypeScript（Next.js, React）、Pythonなどを使って、フロントエンドとバックエンドの両方に携わっています。 将来はソフトウェアエンジニアとしてアーキテクチャ・設計について自ら意思決定した上、プロジェクトを推進する事が出来るようになりたいです。 そのためさらにスキルを磨いていきたいと思っており、日々技術に対して情熱を持って仕事に取り組んでいます。 以前Qiitaで 退職して560万円相当の工数をかけてお金を稼ぐサービスを開発した という事でBizRankというビジネス書籍を紹介するサービスを開発しました。 今回はその後としてのお話になります。
はじめに 前提となるマインドセット 具体的な Tips コードを読まずに理解する技術 とりあえず Clone する インタフェースで理解する テストコードで理解する 慣習名で理解する コードの詳細を理解する技術 デバッガを使う とりあえずサンプルコードを書いてみる 分からないなら聞く 初見コードに安全に変更を加える技術 インタフェースを明らかにする Stub としての実装を用意する Design Doc を書く テストを書く まとめ We are hiring !! エンジニア採用ページはこちら カジュアル面談もお気軽にどうぞ インターンも常時募集しています はじめに 京都オフィス在籍で、AI・機械学習チームの山本(@hiro_o918)です。 このブログはサテライトオフィスのメンバーで投稿されるブログリレー 3 日目の記事になります。 関西在住だとオフラインでのコミュニケーションに悩みが
次の記事が最近公開されたので、読んでみました。 結論としては、例えば同著者の「良いコード／悪いコードで学ぶ設計入門」という書籍と比較すると、だいぶ受け入れやすい主張になっていると感じました。（以前の書籍についてのコメント記事へのリンク） ところで、私は「良いコード」についての議論や指摘や検討を積極的にやったほうがよいと思っていますが、主に「消耗しない」という観点でこの記事についていくつかの構造理解やテクニックの部分で補足できそうだったので、以下補足していきます。 ざっくりとした主張でいうと、 トレードオフに見える部分は学習・教育で解決できるケースも多くある 品質特性への還元が難しいがコードの良し悪しを定める概念がある Webアプリにおいても再利用性は必要だし、モバイルアプリでも再利用性を求めて失敗することがある 再利用性というよりは、現実に即した概念の線をどこで引くかのバランスを大事にする
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Pyxel作者です。Qiita初投稿です。よろしくお願いします。 皆様、Python向けレトロゲームエンジンPyxelのご愛顧ありがとうございます。 「気軽に楽しくゲームプログラミング」をコンセプトに、2018年にGitHubで公開を始めたPyxelも、おかげさまで現在15,000スター、ダウンロード数は80万を超えることができました。 4億を超えるGitHubプロジェクトの中で、Python向けゲーム開発環境としてはダントツの1位（2位は7.5kスターのPygame）、全言語合わせたゲームエンジンの中でも8位にランクインしており、7位
こんにちは〜！ NE株式会社のはやしまき（@_mkmk884）です🦒 DRY（Don't Repeat Yourself）原則はコードの重複を減らし、保守性を高める効果的な手法ですが、適用の仕方によっては仕様変更に対応できなくなることがあります。 特に弊社が開発しているネクストエンジンは多くの他サービスとも連携しているため、ネクストエンジン内の仕様変更だけでなく、外部連携サービスの仕様変更もあります。 当時の仕様的にはDRY原則に沿っていたものが、時間とともに保守性を損ない、結果的にDRYではなくなり仕様変更に耐えなくなったケースについて、今回は書いていこうと思います！ DRY原則とは DRY原則（Don't repeat yourself）とは、ソフトウェアの構成や構築手法についての原則の一つで、同じ意味や機能を持つ情報を複数の場所に重複して置くことをなるべく避けるべきとする考え方です
はじめに はじめはシンプルだったコードも積み重なる機能追加や変更、バグ修正等などによって、徐々にコードが複雑化し、修正コストの増加や品質低下に繋がります。 これはある程度の規模を持つプロダクトでは至って自然なことであり、そうならないようにするためには意識して設計しなければいけません。 ここではコードを複雑化させないために普段意識している手法やパターンを紹介します。(DDDやClean Architecture成分多め) また本記事で登場するコードはJavaですが、Javaを知らなくてもある程度は理解できるかなと思います。 あと、割とまとまりもなく幅広い範囲でダラダラと書いてしまい長いです... 以下項目ごとのアンカーリンクとなっておりますので興味がある項目のみどうぞ。 getter/setterがよくない理由 デメテルの法則と尋ねるな命じよ(Tell, Don't Ask!) 関心の分離
これまで、型駆動設計を実践することが何を意味するのか、簡潔でシンプルな説明を見つけるのに苦労してきました。誰かに「どうやってこのアプローチを思いついたのですか？」と尋ねられることが多いのですが、満足のいく答えを出せないことがよくあります。そのアイデアが突然のひらめきで浮かんだわけではなく、正しいアプローチを空から引っ張り出す必要がない、反復的な設計プロセスがあると分かってはいるのですが、そのプロセスを他の人にうまく伝えることができていませんでした。 しかし、およそ1ヶ月前、JSON を静的型付け言語で、そして動的型付け言語にパースしたときに経験した違いについてTwitter上で振り返っていた時、ついに私が探していたものを見つけました。そして、そのスローガンはたった3つの英単語で表せます。 Parse, don’t validate (バリデーションせずパースせよ) 型駆動設計のエッセンス
経験の浅い人にちょくちょくするアドバイスとして、「コードリーディングのときにはあんまコードを読まないほうがいいよ」がある。コード全体を詳細に読むのではなく、名前やインターフェイスからコードの意図を把握することで効率的にコードリーディングできる。完全に下記の受け売り。 「実装は極力見ないようにして、インターフェイスと構造を理解するようにするんです。ダイヤグラムや、関係のグラフを書いたりして。実装はちゃんと出来ていると信じて、読んでいるメソッドやクラスのインターフェイスの役割やパラメータをしっかり理解するようにするんです。そっちの方が、実装を見るよりずっと楽ですよね。」 牛尾 剛「コードリーディングのコツは極力読まないこと 」 自分なんかは、エディタの畳み込み機能と変数名ホバーを使って、名前とインターフェイスしか見えない状態で読む。中身を読みたいなーと思ったところは畳み込みを解除して徐々に読ん
「TypeScriptではじめる型システム」という記事をn月刊ラムダノートに寄稿しました。 新刊を発売しました "『n月刊ラムダノート』Vol.4 No.3（2024）発行のお知らせ https://t.co/PGppk1aRRA— lambdanote (@lambdanote) 2024年10月4日 どんな内容？ TypeScriptの極小サブセットに対する型検査器を書き、それを通して型システムを体感してみよう、という内容です。 詳しく言うと、boolean型とnumber型と関数型しかないTypeScriptサブセット言語がターゲットです。 型検査器の実装言語にもTypeScript（処理系はDeno）を使います。 TypeScriptづくしの一品です。 わかる人向けに言うと、「型システム入門」という本（通称TAPL）の単純型付きラムダ計算に相当する内容をTypeScriptで説明し
Haskell界隈の一部で囁かれる都市伝説として、「Haskellで求人を出して集めた優秀な人材にPHPを書かせる」というものがありました。この都市伝説に実体はあるのでしょうか？ 伝説 まず、議論の前提として、この伝説に言及している投稿をいくつか挙げておきます。これは「伝説が少なくとも伝説としては存在する」ことを立証するために挙げるのであり、これらの投稿について何らかの価値判断を行う目的ではありません。 GCPで人を集めてAWS書かせるやつ、Haskell と PHP で見た — mizchi (@mizchi) March 16, 2022 Haskellで募集してPHP書かせる事件だ — デジタル競争の敗者 (@Lugendre) June 18, 2021 Haskell プログラマを募集して PHP 書かせるって，ネタ元どこなんだろう？ — ささき しげお (@SigSasaki)
こんにちは、しが あきとし(@akitosihga)です。 先日あるMeetUpで良いコードの書き方について考える機会がありました。 『良いコード』の定義は幅広く様々な解釈があると思います。 その中でも、自分が敬愛するプログラマーのケント・ベックから学んだ事に焦点を当てて良いコードの書き方についてまとめました。 ケント・ベックとは テスト駆動開発(TDD)で有名なプログラマー アジャイル開発におけるエクストリームプログラミング(XP)の考案者としても有名 アジャイル開発関連の書籍に度々登場するCRCを発明したのも彼だったりする 代表的な著書は「テスト駆動開発」「エクストリームプログラミング」 TDDのイメージが強い彼ですが、実はコーディングに対して並々ならぬ情熱を持っているのです。 彼の著書「実装パターン」では以下のように語っています。 『 70年の人生は、20億秒を少し超えるに過ぎない。
本日は人生の数ある選択肢のなかから、こちらのブログを読むという行動を選んでくださいまして、まことにありがとうございます。 はじめに プログラミングの世界には多くの指針や原則が存在します。Chris Zimmerman氏の「The Rules of Programming」（邦題：ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール）は、不変の知恵を凝縮した一冊です。これらの原則は、多くの開発現場で活用できる有益な内容となっていると思いました。 The Rules of Programming: How to Write Better Code (English Edition) 作者:Zimmerman, ChrisO'Reilly MediaAmazon 本書は、大ヒットゲーム『Ghost of Tsushima』などで知られるゲーム制作スタジオ、Sucker Pun
結果的に1200行を越えましたが。 kilo 成果物はこれ↓ 参考サイトはこれです↓ インスパイア元↓ 感想 C言語は10年ぶりくらいに書いた 進めていくうちになんとなく思い出すことができた 最初にちゃんと授業で学んだ言語なので懐かしく思った Cに出会っていなければプログラミングしてなかったかもしれないので感慨深い しかしこのレベルのメモリ管理は正直たいへん 「この関数で確保したメモリはこっちの関数で開放されるので問題ありません」みたいな この調子でやっていったらバグる未来しか見えない 1000行・1ファイルというコンセプトは良いのだがファイル分けて管理したいナ〜〜と思った 配列や文字列の操作、メモリ管理がやりやすい別の言語で書き直したい Cを書くの大変だな…という感想を持った 速さはともかく他の言語で書きたい もっとimmutableに… お手本よりも行数が増えた 1行のif文などでもブ
プログラミングの勉強方法で最も効果がない方法は「写経」です。コードを記憶しても無駄です。実際のプログラミングでは記憶にないコードを作り出さなければいけないからです 「写経」はタイピング速度の向上やキーワードを覚える効果はあるかもしれませんが、肝心のプログラミングには役に立ちません — Koichi Nakashima (@ko1nksm) September 3, 2024 こういうエントリを見かけたので。 僕は1990年代からプログラミングを人に教える仕事をしています。最初は中学の時に技術家庭科の授業を先生から任されて同級生にプログラミングを教えることから始まりました。その後、色々な方法を試しましたが、結論としてプログラミング初心者は写経した方が結局は上達が速いと今は考えています。 それが特に強く感じられたのは2015年頃から色々な人にAI関連のプログラミングを教え始めた頃です。 AI関
チューリング完全とは、ざっくり説明すると、一部を除くほとんど全ての計算が可能な能力を意味します。言い換えると、ほとんど全ての計算問題を解く能力を意味します。（あとでもう少し詳しく説明します。）プログラミング言語は一般にチューリング完全であり、例えば TypeScript や Python はチューリング完全です。プログラミング言語以外にも、TypeScript の型システムやスーパーマリオメーカー、マジック・ザ・ギャザリングもまたチューリング完全であることが知られています[1][2][3]。直近では find と mkdir だけでチューリング完全になると報告されていましたね[4]。 逆にチューリング完全でない例としては正規表現[5]があります。チューリング完全ならば正規表現で解ける問題を全て解けますが、その逆は不可能です。例えば回文の判定は正規表現だと無理です。このように、数ある計算能力
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
