「本記事は、技術的な視点から情報を提供することを目的としております。内容については可能な限り正確性を期しておりますが、記事内の見解は執筆者の意見や理解に基づいており、すべての方にとって普遍的な結論を示すものではありません。技術の分野は常に進化し、新たな知見が追加されることもあります。ご意見がある場合には、建設的な対話を歓迎いたしますが、批判的な意見を展開する際も、お互いの尊重を大切にしたコミュニケーションを心がけていただけると幸いです。」 タイトル: 「東京プログラマー リスプを書かずにはいられない物語」 新宿の夜景を見下ろすカフェで、主人公の大輔は、ノートパソコンに向かって静かにキーボードを叩いていた。彼は東京で働くプログラマー。コードの世界に浸り、特に最近夢中になっているのが関数型言語LISPだった。 LISPは、数学のように純粋で美しいロジックが展開できる言語。大輔は「この関数型の世
楽譜作成ソフト「Finale」の開発元MakeMusic社のウェブサイトで、ソフトの開発中止が発表された＝スクリーンショットより 国内外の音楽家や音楽出版関係者の間で広く普及している楽譜作成ソフトウエア「Finale（フィナーレ）」の開発を終了すると、開発元の米国メーカー「MakeMusic」が26日、発表した。長らく楽譜出版業界の標準とされてきたソフトが35年の歴史に突然“終止線を引く”ことになり、関係者らは動揺を隠せない様子だ。 MakeMusic社は、現在ソフトがインストールされているデバイスではOSを変更しなければ引き続き動作するとしながら、今後アップデートはされず、2025年8月以降は新たに使用するための認証やサポートを受けられなくなるとしている。コンピューターの基本ソフトのOSの進化により「付加価値の提供が難しくなっている」ことが開発終了の理由だという。
「設計書」というのは、作るものの構造を抽象的に表現したものと言うことができます。 ただ、ソフトウェアの抽象化の仕組みはプログラミングコード自体に備わっているので、ソフトウェア生成可能な抽象的表現というのはコード表現ができるはずですね。コードで表現しておくと、整合性のチェックとかも行いやすいです。 でも、コードではない「詳細設計書」というものが一部業界には必要とされているので、その「詳細設計書」というのは実際はなんなのか考えてみます。 ※ 最初はタイトルは「設計書」としてましたが、話を限定するため「詳細設計書」に変更しました。 追記：納品物に関する記述を追加しました。 追記(2024/11/27)：「概略図」「物理設備の設計」を追記 表現を変えたコーディング ソフトウェア生成可能な抽象的表現というのはコード表現ができるわけですが、文字で表記する必要もなく、ダイアグラムで表現することもできます
いわゆる「ソフトウェア設計書」が設計ではなく、ソースコードが設計であるという話。 随筆です。考えマトメ中なので、ツッコミはそのあたり踏まえていただければ。 追記：ブコメに「設計の定義は？」とあったので末尾に追加しています。 追記(2024/8/15)：設計書ってなんだろう？というのも書いておきました。 ソフトウェアの「設計書」とはなんなのか - きしだのHatena このエントリで書いたのですけど、もうすこしちゃんと。 建築では多重下請けでやれてるのに業務システムでだめなのはなぜ？ - きしだのHatena このエントリでは次のように書いています。まあ、これで全てではあるのだけど。 「建築などの施工図面に相当するのはソースコードで、建築現場で多重下請けでやってる作業は、ソフトウェアだと(でも？)ビルドです」 あと「継続的デリバリーのソフトウェア工学」からの抜粋。 「継続的デリバリーのソフト
生命の起源と人工生命の研究分野は、生命の本質とその発生過程を探求している。両分野とも、「非生命」の状態から「生命」がどのように生まれるかを問うている。生命が出現するほとんどの基質に共通する特徴の一つは、自己複製が始まると同時に、その系の動態が大きく変化することである。 しかし、自然界で自己複製体がどのように発生したかについていくつかの仮説はあるものの、自己複製体が出現するための必要条件については、まだほとんど解明されていない。 研究チームは、単純なプログラミング言語や命令セットを用いて、計算環境における自己複製能力を持つプログラム（自己複製プログラム）が自然発生する過程を詳細に観察し分析した。この研究の中心となったのは、「Brainfuck」（BF）という極めて単純な言語を拡張した「Brainfuck Family」（BFF）と呼ばれる言語環境である。BFFでは、64バイトの長さを持つ13
いただきましたー！わーい。脳に収めるぞー！ @haradakiro @ryuzee pic.twitter.com/3Qd6EvPioU— SHIIBA Mitsuyuki (@bufferings) June 13, 2024 明日（2024年6月18日）発売！ www.oreilly.co.jp どう書くのがいいんだろうなぁ？ 複雑なコードと向き合うときは「あー、これはメモを取りながら読まないと迷子になるやつだ」ってなる。最初はわりとキレイに作られていたとしても、機能追加を重ねていくとだんだん読めなくなっていく。 だから「時間が経っても読みやすいコードってどう書くのがいいんだろうなぁ？何かヒントがあるかなぁ？」って思いながらこの本を開いた。先に書いておくと、ヒントはあった。 アウトサイドインのTDD 全然予想してなかったから、おー！と思ったのが、説明をTDDで進めていくってところ。好き
いぐぞー ✈️ 旅するプログラマー @igz0 旅とプログラミングをこよなく愛します。 アメリカ大陸🇺🇸を横断しました！！小学生からプログラミング→新卒SIer→Webに目覚め自社開発のWeb系エンジニア。テレビ出演経験あり。 個人開発者。読書・IT関連を中心にツイートします！！ネタツイート有。アイコンは@ixy先生に利用許諾済み。Amazonアソシエイト参加。 note.com/igz0/ いぐぞー ✈️ 旅するプログラマー @igz0 Microsoftの専門家「ウォーターフォールは一切メリットがないのでやめておきなさい」 > アメリカでは、アジャイルやスクラムの進め方が「常識」としてソフトウェア開発の場で浸透している これマジ？？ 日本のIT企業が、米国では「時代遅れ」のウォーターフォールを未だに信奉してるってコト！？ pic.twitter.com/jRofJKmAKM 202
ソフトウェアは複雑さを増すばかりですが、人間の脳は限られた複雑さしか扱えません。ソフトウェアが思い通りに動くようするには、脳に収まり、人間が理解できるコードを書く必要があります。 本書は、拡張を続けても行き詰ることなくコードを書き、複雑さを回避するための実践的な方法を解説します。最初のコードを書き始めるところから機能を追加していくところまでを解説し、効率的で持続可能なペースを保ちながら、横断的な問題への対処やトラブルシューティング、最適化を行なう方法を説明します。自分のチェックリストからチームワーク、カプセル化から分解、API設計から単体テストまで、ソフトウエア開発の重要な課題に対する考え方やテクニックを紹介します。サンプルプロジェクトで使うコードは、Gitリポジトリの形で入手でき、試しながら学べます。 有効に機能するプロセスを選び、効果のない方法論から脱却する方法。チェックリストを使うこ
2024/3/24に開催されたObject-Oriented Conferenceでの登壇資料です。 https://ooc.dev/2024/
コードベースでプリント基板を設計できるツール「atopile」が登場しました。atopileを使えば、必要な仕様を記述するだけでパーツを自動選択したり、GitHubを使用して複数人でコラボレーションを行ったりできます。 Code to Electronics - atopile https://atopile.io/ atopileの開発者がデモムービーをYouTubeにアップロードしており、atopileがどんなツールなのかを確認することが可能です。 atopile product demo - YouTube ムービーの冒頭でatopileの開発者が「論理回路学習キット」を取り出しました。 この論理回路学習キットの基板は「ato」という専用言語を使用してデザインされています。コードの中の「module」が基板のコンポーネントのそれぞれに対応しているとのこと。まず小さいmoduleを作成
本書は、Goアプリケーションの効率やスケーリングに関する疑問に対して、実用的な答えを与えてくれる書籍です。 レイテンシー、CPU、メモリ資源についての知識、またOSやGoがそれらを抽象化している方法について、またソフトウェアの効率に関わるデータ駆動な意思決定を行う事の意味や、計算量解析の手法、最適化状況の例など、実用的なソフトウェアを開発する中での「効率」に関する知識を紹介します。 Goやその他のモダンな言語で書かれたプログラムを設計、作成、変更するソフトウェア開発者、また誰かが書いたソフトウェアを主に運用するDevOpsエンジニア、SRE、シスアド、プラットフォームチームなどの読者が、いつ、どのように効率最適化を適用するかという問いに答えるための知識を身に付けることができるでしょう。 関連ファイル 原著者による本書のサンプルリポジトリ 正誤表 ここで紹介する正誤表には、書籍発行後に気づい
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション）」という興味深いポストをX（旧Twitter）で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション） コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
経緯 筆者は外国語大学で中国語を専攻しているのですが、偶然にも中国語のプログラミング関係の記事を読む機会がありました。その中で日本語だと直接カタカナで使用している用語も、中国語では意味のある漢字に置き換えられており、興味をそそられたので基礎的な用語を調べてみました。私自身は漢字文化圏で育った者として、こうした用語の漢字表記には元素記号の漢字表記のような魅力を感じます。また同時に、漢字は表意文字であるため初学者にもやさしく見えるので、日本でも（自然言語好きな変人たちの間で）もっと広まっていってほしいな、と思います。 個人的6選 Guard:守衛 かっこえぇ！錯誤（error）が発生しても、コードの安全性をしっかりと担保してくれそうな強さを感じますよね？ ええ、感じます。 Delegate: 代理 初心者には取っ付きづらいDelegateも代理とされたら、仕事の一部を任せるんだな、ということが
Fossil: 分散 リビジョンコントロール, Wiki, バグトラッキング Fossil は 分散ソフトウェアバージョンコントロールシステムの一種であり、統合された 分散 wikiおよび 分散 バグトラッキングシステムを 含む、使いやすい 1実行ファイルに全てを含んだパッケージである。 Fossil は自分自身でホスティングでき、 2007-07-21 から 2つのサーバ上で動作している。 読者はここから最新のソースを得て 自分でコンパイルするか、あるいは コンパイル済みバイナリを ここから取得できる。 機能概要: 柔軟なワークフロー: gitや、 monotone、 mercurial、 bitkeeperなどのような 分散された非接続状態での開発が可能 もしくは CVSや subversionのような クライアント・サーバによる開発作業 また、ローカルのリポジトリに対する操作 これら
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にどんな変更が加え
ゲーム作りとかCGとかに関わる数学(初歩)① 今回HIKKYさんのアドベントカレンダーに投稿するにあたって、別の温めてたネタはあったんですが諸事情により封印してしまったので、何か別のテーマにしようと考えました。 で、色々考えたのですが、特に思いつかなかったのでCG数学の初歩的な話をしようかなと思います。実際VKetCloudの中でも基本的な数学は必ず使われてますし。 あと「ゲームメーカーズ」さんの記事でも取り上げていただいた、僕のCEDEC+KYUSHU2023の数学のお話がやたらとウケがよかったため、数学の話で行くことにしました。 で最初に書いておくと、書きたかったことの半分もかけていません。 時間の都合上と、あと数式と頭が多すぎるのか、このドキュメントの編集が何度も落ちるからです。 と言うわけで、今回は概要と三角関数とベクトルの話だけにします。 あとは年末年始休みの間にでも続きを書きま
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
