![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2026-08-25T12:36:02+09:00","","") #author("2026-08-25T14:52:02+09:00","","") displaying and editing puzzle data ここはpuzzle dataというよりラスターimageです。 どう書けば良いでしょう ---- 連載1回目の原稿です。 かっこ書きでコメントを入れました。 それと今まで話してきたことを前提に再構築できますか？ 全体としては次のように考えています - 1回目:この原稿、要求仕様書的位置付け - 2回目:プログラム開発環境の選定、基本仕様書的位置付け - 3回目:プログラム開発環境の作成、いよいよ実作業に入る - 4回目:設計とテストを書いて実装、いよいよコードを書き始める - 5回目以降:開発作業を続ける #contents *Motivation and Plan [#cb7f6377] **Why am I starting this series? [#oc648da4] A few years ago, I started a Zenn series about developing a puzzle application called '''okoze'''. (この文はZennで公開する時には書きますが、GitHubの新規読者には不要です) The idea was simple: take a photograph of a puzzle printed on paper, convert it into digital data, and solve it on a computer. I published several articles, but eventually the series stopped. Now I would like to start it again. However, this time I want to try something slightly different. (この段落はZennで公開する時には書くかもしれませんが、GitHubの新規読者には不要です) The main purpose of this project is '''not to develop okoze as quickly as possible'''. The main purpose is to write about software development. okoze is the subject I have chosen for that purpose. I have been developing software for many years, but software development has changed considerably over that time. In particular, AI can now write a large part of the actual code. I would like to explore what it is like to develop software in this environment, while recording my thoughts, decisions, experiments, failures, and successes. --- **Why okoze? [#zb6758e9] I actually want to use okoze myself. There are many pencil puzzles that I enjoy solving on paper. It would be convenient if I could take a photograph of a puzzle, convert it into digital form, and continue solving it on a computer. (のんびりと紙と鉛筆を使って解くのもよいですが、デジタル化することで増える楽しみもあります、と入れたいです) (okozeがスマートグラスで使える未来がいつかくるかもしれません、と入れておくと夢があって良いかも) I also want okoze to become more than a single-purpose puzzle application. The long-term idea is to build a small puzzle framework and add different logical puzzles as plugins. For example, the application itself could provide common functions such as: - displaying and editing puzzle data - drawing the puzzle - saving and loading puzzles - common user-interface functions (undo/redo , solver なども入れておきたい) while individual puzzle types could be implemented as plugins. This is an interesting software-development problem in its own right. But there is no particular reason to finish it quickly. In fact, I deliberately want to develop it slowly. (最初はナンプレを遊べる様にして、次にスリザリーリンクをサポートしてプラグイン化したいです、旨記入) (必要ならナンプレとスリザリーリンクの画像) (またはそれを解説したサイトへのリンクを張りましょう) --- **"30 days" does not mean 30 consecutive days [#y8932e21] (週1回と書いてしまうと約束の様でまずい。更新頻度はあまり書きたくない。書くとしても"月に何度か"程度で曖昧にしておきたい) (この項目は消す) The original idea was something like: > '''Build an application in 30 days.''' I still like this idea, but I now have a slightly different interpretation of it. I do not intend to spend 30 consecutive days developing okoze. I have other open-source projects, and I want to continue working on them as well. My current plan is to spend roughly one day a week on okoze-related work and write one article each week. If this continues for about a year, there will be around 50 episodes. The actual development time may be only about 30 days in total. So the plan is roughly: ```text about 30 days of actual development ↓ about 50 weekly episodes ↓ about one year ↓ okoze v1 ``` The slow pace is intentional. --- **The development process is part of the subject [#d71d6647] This series will not simply show the finished code. I want to record how I arrive at the code. The articles may cover: (ここは項目をたくさん並べるのではなくてメインに絞りたい) - development methods - design decisions - implementation - experiments(いらない) - debugging(いらない) - refactoring(いらない) - tools(いらない) - failures(いらない) - unnecessary detours(いらない) - and sometimes completely unrelated stories In particular, I want to record '''why''' I chose a particular design, what alternatives I considered, and what happened after I implemented it. Sometimes the design may turn out to be wrong. That is fine. Changing the design after discovering a problem is part of software development, and I want to record that process too. --- **A small development habit [#abea6b78] I have developed my own way of working over many years. For example, before implementing a feature, I write down its specification in a very small form. It can be just one line. I also write down the test cases that will tell me whether the feature is complete. (テストファーストの開発手法を使うと書いておきましょう) This does not have to be a formal document. At this stage, a notebook or a piece of paper is enough. (notebookはやめましょう。実際設計にはほとんど使っていないし、どこに何を書いたか後で探すが大変) (メモ用紙が最適。いらなくなたら捨てる、簡単に分類できる。notebookよりずっと便利。決定したらデジタル化(タイプまたはカメラ)) I have found this to be a low-stress way of developing software. (ここはGTDからヒントを得ていると少し触れておきましょう) This is not intended to be a universal software-development methodology. Developers working in an organization will normally have to follow their organization's processes. This series is mainly for individual developers, small teams with relatively loose processes, and beginner or intermediate programmers who are looking for simple ways to improve their own development process. I will explain these ideas when they become relevant, but more importantly, I will '''use them throughout this series'''. --- **What will I write about? [#tfe02b9e] I roughly divide the articles into four categories. ***Development methods [#u7e4b9cc] For example: - test-first development - quality management(これはなし) - debugging - coding style - working with AI - and other aspects of the development process ***Design [#qdc991ba] For example: - design alternatives - comparison of alternatives - experiments - analysis - why I selected one design over another - reasons for changing a design later ***Implementation [#nb63c443] Implementation articles will normally begin with something like: > '''Feature to implement:''' one major item followed by: > '''Test cases:''' one line for each case The goal of the episode is to make those tests go from '''Red to Green''' and to complete some part of the feature. I may or may not succeed within the time available. The code produced in each stage will be available in the repository, with Git tags used as milestones. ***Miscellaneous [#k16cad13] Not everything needs to be about programming. I may write about past development experiences, things I happen to think about while developing, or simply take a detour when something interesting comes up. --- **This is an experiment [#u0a1d877] I do not know exactly where this project will go. That is intentional. I have a rough goal for okoze v1, but I do not want to design the entire application before writing the first line of code. I will make a small design, implement it, learn something, and then decide what to do next. The same applies to this series. The format of the series may change as I learn what works. For now, the plan is simple: > '''Develop a little. Think a lot. Write about it. Repeat.''' Let's see where this takes us. **Repository [#nf3df06c] The source code is available in the [[okoze-pre repository:https://github.com/kepaxy/okoze-pre]]. ---- okozeの名前の由来もちょっと触れておきたいです。 okozeは仮称です。(開発コードname?なんていうのでしたっけ)。完成したら別の製品名をつけるつもりです。 okozeはInimicus(もっと一般的に知られている名前があれば置き換えてください)の和名です。 本棚にあった図鑑をペラペラとめくって良さそうなものを選びました。 私は魚が好きなので魚の図鑑は本棚に何冊か置いています。
