大ヒットゲーム『Balatro』のコードが“力業”だとして共感呼ぶ。コードが汚くても、ゲームが完成してちゃんと動けばそれでいい - AUTOMATON
ホーム ニュース 大ヒットゲーム『Balatro』のコードが“力業”だとして共感呼ぶ。コードが汚くても、ゲームが完成してちゃんと動けばそれでいい ゲームを制作する際に必要となるプログラム。そのコードの記述にあたっては「コーディングルール」などとして、構造の把握のしやすさなどが求められることがある。一方で今回、あるユーザーが『Balatro』のコードの一部を公開。コードにif文が多用されている点などから注目されているものの、「見づらかったり、複雑なコードでもほぼ問題なくゲームを完成させられる」事例として共感も呼んでいるようだ。 コードのわかりやすさ ゲームの制作にあたっては、基本的にはプログラミング言語を用いてソースコードを書くといった、プログラムの記述が必要となる。プログラミング言語としては、「C＋＋」「C#」のほか「Java」「Ruby」など、さまざまな種類の言語が存在している。 またゲ
オブジェクト指向は必要なのか / Is object-oriented needed?
2024/3/24に開催されたObject-Oriented Conferenceでの登壇資料です。 https://ooc.dev/2024/
世界中の失敗した製品やサービスを集めた「失敗博物館」をブラウザ上で楽しめる「Virtual tour of Museum of Failure」
Museum of Failure(失敗博物館)は、世界中の失敗した製品やサービスを集めたコレクションで、世界中で巡回展示を実施しています。失敗博物館のウェブサイトでは、「Virtual tour of Museum of Failure(失敗図書館バーチャルツアー)」としてコレクションを一覧にして紹介しており、商品やサービスの詳細や失敗した理由などの解説を読むことができます。 Virtual tour of Museum of Failure https://collection.museumoffailure.com/ Virtual tour of Museum of Failureのページはこんな感じ。コレクションが一覧になっており、サイト上部のメニューからは「Tech(技術製品)」「Foods(食べ物)」「Health(健康器具)」「Historic(歴史的な失敗製品)」「Sil
ソフトウェアに関わる人が知っておくといいかもしれない法則10個
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション）」という興味深いポストをX（旧Twitter）で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション） コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
htmxとは何なのか？ その背景にある思想について - Qiita
先日、Qiitaに投稿された一つの記事が注目を集めました。 元記事では、htmxというJavaScriptライブラリが英語圏で認知を獲得しているとして、インストールの仕方から使い方について公式のドキュメントの全体にわたって簡単に説明が行われています。 さまざまなプラットフォームでこの記事に対する反応を観察してみると、どちらかというと懐疑的な見方のほうが優勢のように見受けられます。ただ、多くのコメントは誤解に基づいているように見受けられました。「JSが要らない」といった元記事のミスリードによるところも大きそうですが1、なぜhtmxが大きく支持を得つつあるのかを理解するには、背景情報を含めて理解することが必要です。 htmxは、最近の複雑化するフロントエンド技術に対する単なる逆張りではありません。これまで30年ほどのあいだウェブ上のシステムを支え続けた「ハイパーメディア」の持つ強力さに今一度目
硬貨サイズで50年動く超小型原子力電池を中国企業が開発
直径20mmの1円玉よりさらに小さい15mm×15mm×5mmというサイズで、100マイクロワットを50年にわたり供給可能だという超小型原子力電池を開発したことを、中国の北京貝塔伏特新能科技有限公司(Betavolt Technology)が発表しました。 北京贝塔伏特新能科技有限公司 https://www.betavolt.tech/ 贝塔伏特公司成功研制民用原子能电池 https://www.betavolt.tech/359485-359485_645066.html Chinese Firm developed Nuclear Battery that can Produce Power for 50 years – Sri Lanka Guardian https://slguardian.org/chinese-firm-developed-nuclear-battery-t
特定のゲーム開発界隈で「ウィンドウサイズを極小にしてもゲームを動作させる」システムがほんのり流行の兆し。人の目盗んでこっそりプレイできる配慮 - AUTOMATON
『古銭プッシャーフレンズ』シリーズの開発で知られるSTP WORKSは、X（Twitter）にて、開発者のある出来事がきっかけで導入されたゲームの機能についての豆知識を投稿。その豆知識によれば、STP WORKSのゲームは、ウィンドウサイズが極小でもゲームが動作するように設計されているようだ。 STP WORKSは、低価格でマルチプレイできるゲームの開発を掲げる、ヨシムネ氏とダンおじ氏による二人組の国内ゲームデベロッパーだ。代表作として『古銭プッシャーフレンズ』をはじめとしたゲームセンターの筐体ゲームから着想を得た「プッシャーフレンズ」シリーズをリリースしている。今月12日には最新作である『フライドポテトプッシャーフレンズ』をリリース予定だ。 そんな安価でユニークなゲームが楽しめるSTP WORKSだが、公式XにてSTP WORKS製ゲームの豆知識が投稿。その投稿によると、STP WORK
Fossil: Documentation
Fossil: 分散 リビジョンコントロール, Wiki, バグトラッキング Fossil は 分散ソフトウェアバージョンコントロールシステムの一種であり、統合された 分散 wikiおよび 分散 バグトラッキングシステムを 含む、使いやすい 1実行ファイルに全てを含んだパッケージである。 Fossil は自分自身でホスティングでき、 2007-07-21 から 2つのサーバ上で動作している。 読者はここから最新のソースを得て 自分でコンパイルするか、あるいは コンパイル済みバイナリを ここから取得できる。 機能概要: 柔軟なワークフロー: gitや、 monotone、 mercurial、 bitkeeperなどのような 分散された非接続状態での開発が可能 もしくは CVSや subversionのような クライアント・サーバによる開発作業 また、ローカルのリポジトリに対する操作 これら
SQLiteがバージョン管理システムとしてGitを採用しない理由
GitはLinuxカーネルのソースコード管理に用いるために開発された分散型バージョン管理システムで、GitリポジトリをホスティングするGitHubのユーザー数は1億人を超えます。一方、軽量データベースのSQLiteの開発においてはGitではなくFossilというバージョン管理システムが利用されており、SQLiteの開発陣が「なぜGitを使用しないのか」という理由を公式サイトで説明しています。 Why SQLite Does Not Use Git https://sqlite.org/whynotgit.html なお、Fossilがどんな機能をもつバージョン管理システムなのかについては下記の記事を読むと分かります。 GitとGitHubの機能をひとつのバイナリに詰め込んだ「Fossil」レビュー - GIGAZINE 1：Gitは適切な状況認識を提供しない SQLiteにどんな変更が加え
東京大学が「因果を打ち破って充電」する量子電池を発表 - ナゾロジー
因果を破って充電します。 東京大学で行われた研究により、因果律の壁を打ち破る新たな手法によって、従来の量子電池の性能限界を超えることに成功しました。 これまで私たちは古典的な物理学も量子力学でも「AがBを起こす」と「BがAを起こす」いう因果律が存在する場合、一度に実行できるのは片方だけであると考えていました。 しかし新たな充電法では、2つの因果関係を量子的に重ね合わせる方法が用いられており、「AがBを起こす」と「BがAを起こす」という2つの因果の経路から同時に充電することに成功しました。 研究者たちはこの方法を使えば、既存の量子電池の充電能力を高めることができると述べています。 しかし因果律を破るとは、具体的にどんな方法なのでしょうか？ 今回はまず因果律を打ち破る不確定因果順序（ICO）と量子電池の基本的な仕組みを解説し、その後、2つの量子世界の現象を組み合わせた今回の研究結果について紹介
とある人気ゲーム開発者が「批判は歓迎だけど、“こうすべきだった”というのはやめて」とお願い。“良いアイデア”でも実装できるかは別 - AUTOMATON
昨今ではSNSやフォーラム上でユーザーからのフィードバックを募るゲームも多く、さまざまな意見が投じられ、開発に活かされている。一方でゲームが抱える課題の原因特定や、特定の要素に向けた“より良いアイデア”については、開発者としての経験がないと検討が難しいようだ。『Starfield』の開発者や国内のゲーム開発者らが「開発過程や内情を知らないユーザーからのアイデア提案や批判」についての問題を指摘し、注目を集めている。 『Starfield』は、『The Elder Scrolls』シリーズや『Fallout』シリーズの開発で知られるBethesda Game Studiosが手がけるRPGだ。本作の舞台は人類が太陽系外に進出した2330年の世界。プレイヤーは希少なアーティファクトを求める宇宙探検家集団コンステレーションの一員として、広大な宇宙の星々を冒険することになる。本作には100以上の星系
Scalaはもうだめなのか？…というかJVM言語がもうだめじゃん？｜sugitani
AndroidのためのJava/Kotlinはスコープ外とします まず断っておくと、俺はScalaが好きだ。 自分が作ったScalaプロダクトは二個現存している。うち一つはまだまだ自分が開発している。というか今は会社を作って1人でプロダクトを作っている身なのだが、それもScala3+ZIO2でゴリゴリ書いている。 でも残念、もうScalaというかJVM言語がオススメできません。TypeScriptかGoかRustをオススメします。 どういうこと？まずこの記事を見ていただくのが一番分かりやすい。 https://aws.amazon.com/jp/builders-flash/202310/java-serverless-saas-backend/?awsf.filter-name=*all 素晴らしいエントリーだ。読みに行かないせっかちな方のために概要を紹介する JavaプロダクトをAWS
本番サーバー60台のホスト名を全部 cat にしてしまった話 - Qiita
この記事は、本番環境などでやらかしちゃった人 Advent Calendar 2023 の4日目です。年末進行、いかがお過ごしでしょうか？みなさま無事に仕事が納まることを願っております… 新人インフラエンジニアが、本番ウェブサーバー60台のホスト名を全部 cat にしてしまった話について、ここに供養させていただきたいと思います 背景 おそらく今から7年くらい前、インフラエンジニアとして転職してきて1年ほどが経ち、本番環境での作業もこなれてきたなというバッチリのタイミングで事を起こしてしまいました。サーバーは CentOS 6 だったと思います。 職場としてはまだまだベンチャー感にあふれ大きな裁量が与えられスピード感のある環境ながら、サービスの登録ユーザー数は1,000万を超え、本番環境の規模としては既になかなかの大きさがあり、ウェブサーバーだけでも60台くらいあったと思います。ひと山につき
リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
日米でエンジニアの育成戦略が正反対だと気付いた話 - メソッド屋のブログ
今週は、Thanksgiving はお休みムードなので考える時間や、自分の本についてディスカッションしている バンクーバーのえんじに屋さんのPodcast なんかを聞かせていただいたりしてるうちに、思い出したことがあって、記録に残してみることにした。それは、エンジニアの育成方針でこれはめっちゃくちゃ違うことに気づきましたので、シェアさせていただきたいと思います。 日米でエンジニアの育成戦略が正反対だと気付いた話 採用の段階での違い 良く知られているように、新卒のケースで考えると、こちらの場合は「コンピュータサイエンス」の学位を出ていることが前提で、中途採用の場合も、「コンピュータサイエンス」の学位を出ている、もしくはそれ相当する知識が求められる。だから、新人でも少なくともプログラムが結構組めることを期待されます。 一方、日本では文系でも理系でもプログラマになれます。採用されたときに「スキル
JavaScriptビルドツールの整理 各ツールの機能と依存関係
フロントエンドのビルドツールが色々ありすぎて、何がどうなっているのかがわかりづらいため、 各ツールができること、特徴 ツール間がどのように依存しあっているか を一気に調べて整理した。(情報は2023/10時点) 概要 ツールの依存関係整理 上層: dev server付きのバンドラ/ビルドツール。アプリ開発者が直接configなどを書いて取り扱うのはここが多いと思われる。(Next.jsに関しては、ビルド機能に着目した場合) 下層: やや基盤的なdev serverなしのツール群。 矢印は、明示的な依存関係を表す。実際には、明示的な依存関係がなくても、下層のツール群は上層のバンドラ(やRollup)に対してプラグインを提供していることが多い。 各ツールのできること整理 ツールごとに、大まかな機能区分で、できることとできないことをまとめた。 各機能区分の定義は次セクションを参照。 ツールごと
最小限のコードで動く最も汚いコードから始める
最小限のコードで動く最も汚いコードから始める 2023.09.02 コードを書く際の重要な要点は、読みやすく他人に理解される「良いコード」を書くことです。しかし、完璧を目指して最初から書こうとすると行き詰まります。代わりに、荒削りながらも動くコードを作成し、徐々にリファクタリングして完成度を高めます。型エラーやリントエラーを無視しても構わないので、まずは動くものを作成しましょう。それからリファクタリングして「良いコード」を作成できます。 コードを書くときに最も大切なことってなんだろう？聡明な読者諸君ならご存知だろうが、コードは書く時間よりも読む時間のほうが長い。だから他人に読まれることを意識して、読みやすい「良いコード」を書かなくっちゃならない。コンポーネントは適切な粒度で分割されていて、適切な名前がつけられている。型システムに安全性だって守られてるし、最新のなんとかアーキテクチャにも準拠
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日本人開発者向けの最適解？ GitHubフォント＋IBM日本語フォント＝「Moralerspace」／「Monaspace」と「IBM Plex Sans JP」をかけ合わせ、5スタイル×6つの全半角調整【レビュー】
失敗例から学ぶSOLID原則
「作ってから売る」と「売ってから作る」と「売れるようにしてから作る」 ～技術の社会実装のための『開発』～
