DEV Community: Umitomo

Weekly Dev Log 2026-W19

Umitomo — Wed, 16 Sep 2026 00:30:08 +0000

🗓️ This Week

After all the hot weather we had up until last week, the days have suddenly turned much cooler. It finally feels like autumn is here🍂. Although I was busy this week, I think I was still able to use my time effectively and make steady progress on my iOS app📱.
Last week, I finished reviewing the basic game rules for Chord Tone Practice and wrote that my next step would be to work on the UI. So this week, I mainly focused on designing the Chord Tone Practice screens in Figma🎨.
One of my goals was to keep the basic practice experience consistent with Note Practice, which I had already designed and implemented earlier. The two modes share the same fretboard and basic screen structure, but Chord Tone Practice needs to display and manage more information because the player is looking for sets of three notes rather than a single note.
What I especially liked about this process was that I didn't have to redesign the whole practice screen from scratch.
When I designed Note Practice, I tried to keep the basic screen structure reusable because I already knew that I wanted to add more practice modes later. That decision helped a lot this week.
Instead of reconsidering the fretboard layout, screen structure, navigation, and other common elements, I could focus on the parts that were unique to Chord Tone Practice💡.
I also continued using Codex and Figma together through MCP. I could discuss possible layouts with Codex, immediately turn those ideas into visible designs in Figma, and then review and refine them using the actual screens as a shared reference.
There are still some details that may change once I implement the design in SwiftUI, but the overall UI direction for Chord Tone Practice is now mostly settled🔥.

📱 iOS (SwiftUI)

Designed the main UI for Chord Tone Practice based on the game rules finalized last week.
Reused the basic Practice Screen structure originally created for Note Practice.
Focused on the UI differences required for Chord Tone Practice instead of redesigning the entire screen.
Added layouts for Root, Quality, Pattern, and Progress.
Designed the main states for multiple-note selection, correct answers, wrong answers, multiple valid sets, and completion.
Compared accessibility layouts and checked how longer note labels such as C#/Db would fit in compact UI elements.
Used Codex and Figma through MCP to visualize, review, and refine UI ideas.

🎸 Comparing Note Practice and Chord Tone Practice

Here is a closer look at how I reused the Note Practice screen and what I added for Chord Tone Practice.

Both modes use the same main structure: the title and question information at the top, the fret-range controls and guitar fretboard in the center, and an answer area at the bottom. This helped me keep the overall practice experience consistent between the two modes.

However, the information needed to answer each question is different. Note Practice asks the player to find one type of note, while Chord Tone Practice asks the player to find three-note chord-tone patterns and may contain multiple valid sets within the visible fret range.

🎵 Note Practice

The player finds every position that matches one target note within the visible fret range.
The header only needs to show the target note and the current progress, such as Find E 0 / 4.
The player selects one position at a time, and each correct position remains highlighted.

(Note Practice: finding all positions for a single note)

🎶 Chord Tone Practice

The player finds chord-tone sets across three consecutive strings.
The header needs to show the Root, Quality, Pattern, and Progress separately.
The selected pattern may be 1-3-5, 3-5-1, or 5-1-3, so the player needs to understand both the notes and their order.
The screen also needs to manage temporary selections, correct and incorrect sets, previously discovered sets, and completion.
I added a Settings button so that the player can change the Root and Chord Quality used for the practice session.

(Chord Tone Practice: finding three-note chord-tone sets)

The biggest visible change is the header. Instead of showing only a target note, Chord Tone Practice separates Root, Quality, Pattern, and Progress into four groups. At the same time, I was able to keep the fretboard, fret-range display, answer area, and overall visual style consistent with Note Practice.

Because I had designed the original screen with future practice modes in mind, I could spend more time on these feature-specific differences instead of designing the entire screen again from the beginning.

This process also showed me how useful the Codex and Figma workflow can be for UI design. When an idea from Codex was reflected in Figma, I could immediately see whether it worked visually. If something looked unclear or awkward, I could use the screen itself when discussing the next change. Figma became a shared visual reference between Codex and me, reducing the effort required to explain every visual difference using words alone.

💡 Key Takeaways

Designing the original Note Practice screen with future practice modes in mind made it much easier to add Chord Tone Practice.
Reusing a common UI structure allowed me to focus on the differences specific to the new feature.
Comparing the two practice screens visually made it easier to see which parts could remain consistent and which parts needed to change.
Seeing Codex's UI ideas directly in Figma helped me notice issues that would have been difficult to find from text descriptions alone.
Using Codex and Figma together through MCP reduced the effort required to explain visual differences using words alone.
Accessibility and longer labels need to be considered early, especially when adding more information to an already compact landscape layout.

🚀 Next Week

Start implementing the backend logic for Chord Tone Practice and review the implementation.
Organize the UI adjustment points for the portfolio site implemented by Codex in Notion, then start making small UI refinements.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W18

Umitomo — Tue, 08 Sep 2026 00:05:03 +0000

🗓️ This Week

We’ve still had plenty of hot days lately, but there have also been some cooler days when it rains. It’s starting to feel like summer is slowly coming to an end🎇.
Work has been quite busy recently, and I haven’t been able to find as much time as I’d like for my own development projects💦. Because of that, it’s been about two weeks since my last Weekly Dev Log update.
By my previous update, I had mostly finished Note Practice, the first practice mode in ToneDrill. So I’ve now started working on the next feature, Chord Tone Practice🦾.
In Chord Tone Practice, I want the player to find chord-tone patterns on the guitar fretboard based on the selected root note and chord quality, Major or Minor🎸. For example, a Major chord can generate not only 1-3-5, but also patterns such as 3-5-1 and 5-1-3. The player finds one correct note position on each of three consecutive strings.
Personally, I really enjoy practicing simple chord tones using only the Root, 3rd, and 5th on the guitar, so that was one of the reasons I wanted to build this mode😂. I like how just a few notes can still create a clear and beautiful chord sound🎵.
This week, I worked with Codex to define the game rules in much more detail💡. While deciding things like the root notes, Major / Minor chord qualities, chord-tone patterns, strings to use, and how correct answers should be counted, I started wondering: “Will these rules actually work under every possible condition?”
So before implementing the feature in SwiftUI, I had Codex create a separate JavaScript validation script to test the game rules first.
The script checked 504 different conditions, combining 12 root notes, Major / Minor chord qualities, three chord-tone patterns, and seven visible fret ranges.
The results confirmed that there were no cases with zero valid answers, no overlapping answer positions, and no situations where the player could get stuck before completing all valid answers.
The ToneDrill app itself is being developed in Swift and SwiftUI, so using a separate JavaScript program only to validate the game rules before implementation was a new and interesting approach for me🤔.
I also became curious about how the JavaScript script was actually checking all 504 conditions. I started debugging the code and asking Codex questions about each part of the process, and before I knew it, I had spent quite a lot of time on it 😅
Still, it turned out to be a useful detour because I was able to learn more about how the JavaScript code worked as well🐛.
Now that the basic game rules are settled, the next step is to work on the UI🔥. I’m looking forward to seeing how the practice mode feels once it starts taking shape on screen✨.
About a month ago, I was able to keep up with both development and my weekly Dev.to posts fairly consistently. Recently, though, work has been much busier, and there have been many days when I haven’t been able to make as much progress as I wanted.
Still, I want to remember why I started doing this in the first place: because I enjoy building things and learning things I didn’t know before.
Rather than comparing myself too much with other amazing developers, I want to keep moving forward one step at a time at my own pace🚶. Lately, I’ve been reminded again of how important that is🌱.

📱 iOS (SwiftUI)

Defined and reviewed the core rules for the new Chord Tone Practice mode.
Finalized the root, chord quality, degree pattern, and valid answer rules.
Used an AI-generated JavaScript script to validate all 504 planned conditions before Swift implementation.
Reviewed the validation script to understand how it generated answer sets and checked edge cases.
Debugged the script with breakpoints and conditional breakpoints to trace specific test cases.
Documented the script’s execution flow, validation logic, and important JavaScript concepts in a separate Markdown learning note.

💡 Key Takeaways

I learned that a separate validation program can be useful for checking game rules before implementing them in the main application.
I learned that reviewing AI-generated validation code is important, not just checking whether the final result says “passed.”
I gained a better understanding of how the script used map(), filter(), flatMap(), reduce(), some(), every(), Set, Map, and bit masks.
I learned how conditional breakpoints can help isolate one specific case from many repeated test combinations.
Debugging the script helped me understand its execution flow much more clearly than simply reading the code.
The investigation gave me more confidence in the Chord Tone Practice rules before moving on to the Swift implementation.

🚀 Next Week

Continue designing the UI for Chord Tone Practice
Organize the UI adjustment points for the portfolio site implemented by Codex in Notion, then start making small UI refinements.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W17

Umitomo — Mon, 17 Aug 2026 04:04:23 +0000

🗓️ This Week

This is my first update in two weeks😂. I took a long break and enjoyed the summer with my family🎐.
I was busy enjoying summer events, so I did not make much progress over the past two weeks. However, I was able to make some progress on my iOS app🐛.
Until now, Note Practice mode asked users to find just one position for a given note on the guitar fretboard. During my break, I changed it so that users now need to find all matching note positions within the visible fret range🎸.
With this update, the development of Note Practice mode is mostly complete. I have finally finished developing one full practice mode✨.
While working on these changes, I also learned more about how several parts of the SwiftUI implementation work💡.

📱 iOS (SwiftUI)

Changed Note Practice mode so that users now need to find all matching positions for the target note within the visible fret range instead of finding only one position.
Added a progress indicator such as Find E 2 / 4 to show how many correct positions have been found and how many remain.
Replaced the previous single-selection state with a Set<FretPosition> so that multiple correct positions can remain highlighted without counting the same position twice.
Added temporary Correct! and Try Again feedback after each answer while keeping previously found positions highlighted.
Introduced a FeedbackState enum to manage idle, correct-feedback, and wrong-feedback states.
Implemented a cancellable Swift concurrency Task to automatically clear temporary feedback after approximately one second.
Added UUID-based token validation to prevent an older feedback Task from updating the UI after a newer answer has already been processed.
Separated fret-answer interactions from fret-range navigation so that each type of control can be enabled or disabled independently.
Added cancellation handling in onDisappear so that view-owned asynchronous work is stopped when the user leaves the practice screen.
Used Xcode breakpoints to inspect scheduleFeedbackReset() at key points such as UUID generation, Task creation, Task.sleep, cancellation checks, token validation, and the final state reset.
Reviewed the Codex-generated implementation against the official Apple and Swift documentation to better understand how SwiftUI state management, Tasks, cancellation, and view lifecycle behavior work.

🎸 How I Changed Note Practice Mode

Here is a more detailed look at what I changed in Note Practice mode.

Previously, the user only needed to find one correct position for the note shown in the question. With this update, the user now needs to find every position with the same note name within the currently visible fret range.

In the old version, the question was completed as soon as the user found one correct position. This meant that a user could answer correctly even if they had only memorized one specific position for that note on the fretboard.

In the new version, the user also needs to find where the same note appears on the other strings. The goal of this change was to encourage users to think about how the same note is distributed across the fretboard, rather than memorizing a single position for each note.

I also added a progress indicator that updates each time the user finds a correct position. Once all of the correct positions have been found, the app displays Congratulations! and moves on to the next question. This makes it easier for the user to see how many positions are still left to find before completing the question.

🎵 Old Version

Within a seven-fret range, the user only needed to find one position that matched the note shown in the question.
The app checked whether the selected position was correct or incorrect and provided feedback to the user.

(Old version: Note Practice mode)

🎶 New Version

Within a seven-fret range, the user now needs to find every position that matches the note shown in the question.
The app still checks each answer and provides feedback, but the number of correct answers now increases each time the user finds a new correct position.
Once the number of correct answers reaches the total number of matching positions, the app displays Congratulations! and moves on to the next question.
The goal of this change was to help users become more aware of how notes are arranged across the entire guitar fretboard instead of memorizing each note as a single isolated position.

(New version: Note Practice mode)

💡 Key Takeaways

📱 SwiftUI Learning

I learned that an enum is a good way to model mutually exclusive UI states. Using FeedbackState means the screen can only be in one feedback state at a time, instead of relying on several Boolean properties that could accidentally conflict with one another.
I learned that a Set is useful when I need to keep track of unique values. In this case, Set<FretPosition> prevents the same fret position from being counted more than once while still preserving multiple correct answers.
I learned that application state and UI interaction state do not always need to be represented in the same way. A computed Boolean property such as isRangeInteractionDisabled can translate the current application state into a simple value that the view uses to enable or disable controls.
I learned that Task<Void, Never>? can be used to keep a reference to an asynchronous Task that returns no value. Keeping that reference also allows the current feedback Task to be cancelled when necessary.
I learned that Swift Task cancellation is cooperative rather than an immediate forced stop. Calling cancel() requests cancellation, but the Task still needs to check its cancellation state or reach a cancellation-aware suspension point such as Task.sleep.
I learned why checking only Task cancellation may not always be enough. Comparing a UUID token captured by each Task with the latest feedbackToken provides an additional way to make sure that an older Task cannot clear newer UI state.
I learned that Task.sleep suspends the current Task without blocking the underlying thread. This means the app and MainActor can continue processing other work while the feedback timer is waiting.
I learned that asynchronous work owned by a view should be cancelled when that view disappears. Using onDisappear helps prevent a feedback Task from attempting to update state after the user has already left the practice screen.
I learned that adding Equatable to a custom enum allows its values to be compared with operators such as == and !=. For example, feedbackState != .idle can be used to determine whether temporary feedback is currently being displayed.
I learned that SwiftUI's ButtonStyle can affect the visual appearance of disabled controls, so interaction behavior and visual behavior should both be checked when disabling buttons.
I learned that .accessibilityElement(children: .combine) can combine related child views into a single accessibility element, while .accessibilityHidden(true) can hide decorative elements from VoiceOver. These modifiers change the accessibility structure without changing the visual layout.
By stepping through scheduleFeedbackReset() with Xcode breakpoints, I was able to see how UUID generation, Task.sleep, cancellation checks, token validation, and state reset work together instead of only understanding them from the source code.

🚀 Next Week

Start developing Chord Tone Practice mode, another practice mode separate from Note Practice mode.
Organize the UI adjustment points for the portfolio site implemented by Codex in Notion, then start making small UI refinements.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W16

Umitomo — Fri, 31 Jul 2026 04:46:31 +0000

🗓️ This Week

This week, I was able to make a little more progress on my personal iOS development project, continuing from last week❤️‍🔥.
By last week, I had finished implementing the main screen that is opened from the top menu. Based on that screen, I discussed the game logic for the single-note practice menu on the fretboard with Codex.
I enjoyed the process of starting with a rough idea and gradually turning it into a more concrete implementation plan🦾.
For the first time, I asked Codex to implement unit tests for my SwiftUI project. As a result, I noticed that the implementation style was different from the testing approach I had learned in Apple’s SwiftUI tutorials🤔.
After looking into it, I found that Codex had used the older XCTest framework, so I revised the tests to use Swift Testing, which is easier for me to understand based on what I have learned so far.
By accumulating discoveries like this, I want to keep improving my ability to develop iOS apps smoothly with AI agents🚶.
I was also able to continue working on TryHackMe again this week. I only completed a small part, but I want to keep moving forward one small step at a time✨.

📱 iOS (SwiftUI)

Defined the new completion logic for the current Note Practice mode through discussions with Codex.
Finalized the progress display, feedback timers, fret-range controls, and automatic transition to the next question.
Created the Note Practice completion feature specification and implementation plan, then updated the Task Index to reflect the latest decisions.
Planned the SwiftUI state management, testing strategy, and file-level changes before starting implementation.
Added completion-specific color assets for the new Note Practice feedback state.
Implemented NotePracticeCalculator to calculate visible positions, target positions, and eligible note names.
Added logic that excludes the current note when alternative questions are available.
When I asked Codex to implement unit tests without specifying a framework, it initially used XCTest.
Since I had learned unit testing with Swift Testing in Apple’s Swift tutorials, I decided to use Testing instead.
Refactored the tests with @Suite, @Test, and #expect, adding clear Japanese display names for readability.
Updated AGENTS.md to preserve the testing policy and current progress for future Codex sessions.
Ran the NotePracticeCalculator unit tests in Xcode and confirmed that all tests passed.
Investigated a Swift Concurrency warning related to the Hashable conformance of FretPosition.
Marked FretPosition as nonisolated after confirming that it is an immutable value type with no UI dependencies.
Added shared layout metrics for the Answer and Feedback panels to keep the UI dimensions consistent.
Introduced FretCellVisualState to explicitly represent the normal, found, and wrong states.
Updated FretCellView, its previews, and FretboardView incrementally while documenting the next verification steps for Xcode.

🔐 Security (TryHackMe)

Worked on the AI System Reconnaissance room, part of the AI Security Learning Path on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

I really enjoyed brainstorming the Note Practice changes with Codex. I started with rough feature ideas and gradually saw them turn into a well-structured SwiftUI specification.
Discussing the behavior step by step made the design process feel much more efficient.
Separating persistent progress from temporary feedback makes SwiftUI state management clearer and safer.
Planning interaction states, disabled appearances, tests, and accessibility before coding can prevent many implementation problems later.
A range such as 0...6 is a ClosedRange<Int> that includes both endpoints.
map transforms each element, while filter keeps the original elements that satisfy a Boolean condition.
Set removes duplicates, contains checks membership, and Hashable makes custom values usable in a set.
Codex may choose APIs or implementation styles that differ from those taught in Apple’s latest Swift and SwiftUI tutorials. These approaches are not necessarily wrong, but some may follow older conventions.
Defining preferred modern patterns in AGENTS.md is important for keeping future implementations consistent and preventing the same outdated approach from being chosen again.
I learned that Xcode’s Default Actor Isolation can implicitly isolate a type and its protocol conformances to MainActor.
I learned that a MainActor-isolated Hashable conformance cannot safely be used by a nonisolated generic collection such as Set.
I learned that adding @MainActor to a test function does not solve a warning caused by the isolation of the model type or its protocol conformance.
I learned that nonisolated should be applied based on a type’s responsibilities, not added mechanically just to remove a compiler warning.

🔐 TryHackMe Learning

AI System Reconnaissance

Task 4: Enumerating AI Systems

I learned that MLflow is a highly valuable service to enumerate because it can expose experiments, registered models, model versions, training runs, and downloadable artifacts through a small number of REST API calls.
I learned that the model-versions/search endpoint is especially important because it can reveal the artifact URI, user ID, timestamps, and stage labels, which show where model files are stored and whether a model is used in production or staging.
I understood that inference servers such as Triton and TensorFlow Serving expose model metadata, including input tensor names, shapes, data types, backend frameworks, and maximum batch sizes, which can show exactly how to format a valid inference request.
I learned that vector databases such as Qdrant, Weaviate, and Chroma can reveal what kind of data an AI system is indexing, including collection names, vector dimensions, distance metrics, point counts, schemas, and embedding model information.
I learned how to use curl -s to retrieve API responses quietly without extra progress output, and how to use jq -r to extract specific values from JSON responses in a clean, readable format.
I learned that Jupyter notebooks can become a serious security risk because data scientists may accidentally store cleartext credentials, access keys, or tokens in notebook cells, which can become a bridge to MLflow, cloud storage, and other parts of the AI stack.

🚀 Next Week

Continue developing the Note Practice menu for ToneDrill.
Organize the UI adjustment points for the portfolio site implemented by Codex in Notion, then start making small UI refinements.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W15

Umitomo — Fri, 24 Jul 2026 07:28:11 +0000

🗓️ This Week

Summer has fully arrived in Japan, and people are enjoying the season in many ways, from local festivals to swimming pools🌊. Just like last week, work has stayed hot in more ways than one💦, but I have still been finding small pockets of time to move my projects forward little by little🐛. I want to keep growing at my own pace without rushing✨.
This week, I was able to make progress on the iOS app development for ToneDrill. Based on the top menu UI design I created in Figma last week, I implemented the screen in SwiftUI⛏️.
I asked Codex to implement it using the same workflow I used when building the first screen with the app’s main feature. This time as well, Codex helped me implement the SwiftUI screen closely based on the Figma UI design🦾.
However, some detailed adjustments still require human review and manual refinement. I will continue reviewing the implementation myself while learning more about the overall iOS app development flow and SwiftUI implementation.
Since Codex handles the overall implementation structure, I can move forward with iOS app development while saving a significant amount of time. This has made me feel the usefulness of AI even more clearly.
I was also able to complete one TryHackMe task for the first time in two weeks😂. The room I am currently working on also covers infrastructure used in AI applications, so there are many unfamiliar terms. Even so, I want to keep making progress little by little while researching them as I go🔍.

📱 iOS (SwiftUI)

Organized the structure of the top menu screen in Figma.
Created designs for both the main top menu and the submenu screen that opens when a menu button is selected.
Defined a “Coming Soon” state for features planned for future development and established a corresponding color palette.
Created the SVG icons used on the menu screens in Figma.
Added the new colors and icons from the design process to Assets.xcassets.
Organized Assets.xcassets into separate folders for colors and images.
Implemented the Top Menu and Practice Mode screens in SwiftUI.
Added reusable menu card styles and layout settings.
Connected the screens using NavigationStack and NavigationLink.
Added disabled “Coming Soon” cards for future features.
Documented the implementation and prepared an Xcode verification checklist.
Reviewed the Xcode result and found that the NavigationStack navigation bar pushed FretboardPracticeView downward, clipping the Answer and Next area.
Hid the Back button and navigation bar using .navigationBarBackButtonHidden(true) and .toolbar(.hidden, for: .navigationBar).
Added a custom Quit button that presents an alert before calling dismiss() to return to PracticeModeView.

🔐 Security (TryHackMe)

Worked on the AI System Reconnaissance room, part of the AI Security Learning Path on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

Reviewed how to add new Color Sets and Image Sets to Assets.xcassets.
Visually distinguishing between enabled and disabled menu components helped clarify the intended result before implementing the screens in SwiftUI.
I was reminded that using Codex to edit and organize Figma designs through MCP is an efficient way to break down an existing UI concept into detailed, implementation-ready specifications.
Parent views should decide a card’s state, layout, and destination.
Reusable views can translate configuration values into visual styles.
MenuCardState is a display setting, not the same as SwiftUI’s @State.
Keeping navigation outside reusable UI components makes responsibilities clearer.
Figma designs should be adapted to responsive SwiftUI layouts instead of copied as fixed coordinates.
NavigationStack manages the screen hierarchy, while NavigationLink opens each destination.
GeometryReader lets a view calculate its layout from the space currently available to it.
Destination views are not placed inside the Top Menu’s GeometryReader; they receive their own layout space when presented by NavigationStack.
Adding NavigationStack can change the available layout height, even when the destination view itself is unchanged.
Navigation changes must be reviewed together with the destination screen’s existing size and safe-area assumptions.
A practice or game screen may need a protected exit flow instead of the standard Back button.
The destination view should control its own navigation-bar visibility when it requires a full-height layout.

🔐 TryHackMe Learning

AI System Reconnaissance

Task 3: Fingerprinting AI Services

I learned that finding an open port is only the first step. To understand what is actually running behind the port, I need to fingerprint the service.
I learned that standard Nmap service detection is not always enough for AI infrastructure because AI services can be mislabeled as generic HTTP services or unknown gRPC services.
I understood that AI service fingerprinting requires checking multiple clues, such as HTTP headers, JSON response structures, error messages, endpoint names, and gRPC behavior.
I learned that some AI frameworks reveal their identity through response headers. For example, TorchServe may return a Server: TorchServe header, while Triton can expose Triton-specific headers and telemetry information.
I learned that API responses can also reveal the framework. For example, OpenAI-compatible endpoints often return JSON containing fields such as "object": "model".
I understood that error messages can be useful for fingerprinting because AI frameworks often return detailed debugging information about tensor shapes, data types, or internal namespaces.
I learned that AI-related endpoints often use names such as /predict, /infer, /generate, /embeddings, /v1/models, and /v2/models, which are different from traditional REST endpoints like /users or /products.
I learned that some AI services expose gRPC in addition to HTTP, and normal HTTP scanners may miss these services because gRPC is a binary protocol.
I understood that grpcurl can be used to inspect gRPC services, and if gRPC reflection is enabled, it may reveal the available services and API schema.
I learned that fingerprinting does not always require exploitation. Even simple requests, harmless prompts, headers, and response formats can reveal what model or framework is running behind an endpoint.
Through the exercise, I learned how to move from “this port is open” to “this service is likely Triton, MLflow, Qdrant, or Jupyter” by checking service-specific responses.

🚀 Next Week

Continue developing the top menu screen for ToneDrill.
Organize the UI adjustment points for the portfolio site implemented by Codex in Notion, then start making small UI refinements.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W14

Umitomo — Thu, 16 Jul 2026 08:02:49 +0000

🗓️ This Week

After several gloomy weeks of rain, summer suddenly arrived in Japan, and it lifted my mood❤️‍🔥! At the same time, work has been hot in more ways than one💦, so I have been trying to enjoy development efficiently with the limited time I have😎.
This week, I worked on designing the top menu screen for my iOS app using the new workflow I built last week🐠.
I also created rule files and a task management document for my portfolio website project so that I can apply the same Codex workflow I built for iOS development to my web development project🌈.
Setting everything up took some effort, but now I can use a similar workflow for both iOS and web development, which made me feel much more organized🦾.
I also tried Penpot to see whether it could replace some of the design work I currently do in Figma, as I was reconsidering my Figma subscription🤔.
I thought Penpot was a great tool, but I decided to treat the cost of Figma as a necessary expense for now and focus on developing efficiently while still enjoying the process🤗.
I have not worked on TryHackMe for more than two weeks, so next week I want to at least reconnect with it, even if I only review the content briefly🐛.

📱 iOS (SwiftUI)

Used Codex to create the top menu screen design for ToneDrill in Figma.
Used the workflow I built last week, where Codex first reads documents such as AGENTS.md and TaskIndex.md before starting the task.
Followed a similar process to the previous implementation: first, I asked Codex to generate multiple UI design ideas as images.
Chose the design I liked the most from those options and used it as the base direction.
Organized the information needed to implement the selected design in Figma as top-menu-figma-brief.md.
Organized the structure of the top menu screen in Figma based on the design created there.
Decided to include menu buttons for features I want to implement in the future on the top menu screen as well. I designed them so that it is clear they are currently unavailable.
Since this added a new “unavailable” state, I also organized the color rules for that state in the Figma design system.

🌐 Web Development

Last week, I created a new Codex workflow for ToneDrill, my personal iOS development project. This week, I introduced a similar workflow to My New Portfolio Website, a personal web development project, by creating an AGENTS.md file and a dedicated task management file.
To make the workflow easier to use, I reviewed both the immediate tasks and the medium- to long-term roadmap for My New Portfolio Website and organized them in the task management file.
I also updated my Notion setup so that Codex can read and write project records through the Notion MCP integration.

🖼️ Design Tool Exploration

Tried Penpot, an open-source design tool, to explore whether I can edit design data from Codex without using Figma’s Full Seat plan.
Checked how Penpot works as a possible alternative to Figma for managing UI design data.
Explored whether Penpot could fit into my AI-assisted design and development workflow.

💡 Key Takeaways

📱 SwiftUI Learning

After reviewing and improving my workflow last week, I felt that Codex could work more smoothly because it had a better understanding of the task details and previous project context.
I asked Codex to create multiple design ideas, and I chose a simple layout.
I realized that when the UI structure is simple and does not rely on complex image editing or highly detailed visual parts, there is less gap between what I imagine and what the AI understands.
Based on this, I felt that an efficient approach is to first use AI to build an app with a simple overall structure and the main features I want to use, then work on detailed UI refinements later.
Since I am developing this app by myself alongside my full-time job, I realized that choosing what to focus on is very important🤔.
For now, I think it is better to prioritize finishing a simple working app, even if that means sacrificing advanced, complex, or visually impressive UI design at the beginning❤️‍🔥.

🌐 Web Development Learning

Setting up this kind of workflow takes some time at first, but having a consistent way of working across different projects has reduced both the mental effort and the stress involved in switching between them😉.
I had already been managing tasks for My New Portfolio Website in Notion, but aligning its task management structure with the one used for my iOS project made everything feel much more organized and easier to understand.
Although the workflow is still relatively simple, I now have a basic and repeatable structure for using Codex in my personal development projects. As a result, I have a much clearer idea of how and when I want to use Codex than I did before🧐.

🎨 What I Learned from Exploring Design Tools

💡 What I found

Learned that Codex can read from and write to Penpot design files by using Penpot’s MCP server.
I actually asked Codex to create a simple dashboard design in Penpot, then tested whether I could implement a web app based on that design. Through this, I confirmed that Codex can write design data to Penpot and that it is possible to implement a program based on a Penpot design.
I also tested what differences would appear if I asked Codex to recreate the ToneDrill UI design I am currently working on in Figma as a similar design in Penpot.
As a result, I found that it is possible to create a design in Penpot that is almost the same as the Figma design.

🖼️ Figma Design and Penpot Design

When I tested this workflow, the designs Codex actually created looked like this.

I was surprised that Penpot could recreate almost the same design🔥!

(Penpot Design)

(Figma Design)

🐛 What I will do next

Since I am already familiar with Figma, I still find it easier to use in terms of both workflow and usability. However, Penpot appears to support many of the core features I need, so it could be a good option for personal projects like mine.
I considered switching from Figma to Penpot for the next screen in the ToneDrill project. However, I have already established a basic workflow for creating designs and implementing them with Codex and Figma while working on the first screen.
Changing the workflow in the middle of the project could lead to unexpected issues and additional rework. Therefore, I decided to continue using Figma for the current ToneDrill project and focus on completing the app with the workflow I have already tested
Instead of introducing Penpot into ToneDrill immediately, I plan to create a separate small iOS project and use it to test a Penpot-based design and development workflow. I think it is more important to complete ToneDrill first and establish a reliable end-to-end workflow before experimenting with a different design tool.

🚀 Next Week

Continue developing the top menu screen for ToneDrill.
Organize the UI adjustment points for the portfolio site implemented by Codex in Notion, then start making small UI refinements.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W13

Umitomo — Fri, 10 Jul 2026 21:08:52 +0000

🗓️ This Week

This week, I mainly focused on iOS development📱.
I also tested a small workflow using Codex: organizing ideas, creating a design file, and implementing a SwiftUI prototype. Through that process, I realized that Codex can be very helpful for making iOS development more efficient💡.
Until now, I had been using Codex in a rather ad hoc way, sending instructions only when I wanted it to handle a specific task😂.
This week, I started thinking about how to make that workflow more efficient, and how to make Codex act more like a development partner that understands the project in the same way I do🧐.
As I explored this, I realized that I needed to review my Codex settings, build better rule files for giving instructions to Codex, and rethink how I use Codex in my own workflow🛠️.
Working through all of this slightly changed the way I think about AI agents🤖.

📱 iOS (SwiftUI)

I organized the UI structure for ToneDrill mini in Figma.
I created a structured design page and a small Mini Design System in Figma.
I summarized colors, typography, buttons, fretboard parts, spacing, and radius rules.
I updated the implementation note so Codex could understand the design direction.
I asked Codex to implement the SwiftUI fretboard UI based on the Figma design and implementation note.
I changed the instruction so app colors would be managed as Color Sets in Assets.xcassets.
I reviewed the SwiftUI code for ToneDrill implemented by Codex.
I asked Codex questions to better understand the implementation.
I checked how the fretboard UI is drawn and updated in SwiftUI.

🆙 Updating my workflow

🤖 AI agent workflow

I worked on setting up a more structured workflow for using Codex in my development projects.
I created a global AGENTS.md file for Codex (~/.codex/AGENTS.md).
I created a project-level AGENTS.md file at the root of the repository (repo-root/AGENTS.md).
I separated the responsibilities of the global AGENTS.md file and the project-level AGENTS.md file.
I created docs/codex/TaskIndex.md as a task management document. In it, I organized both immediate tasks and mid- to long-term tasks, and defined a consistent format for writing them down.
To reduce the need to repeatedly explain the project background, past work, and current tasks every time I move to a new chat, I decided to build a workflow and create a mid- to long-term project memory in Notion for the work and lessons I develop with Codex.
I created a Notion page called AI Operating Manual so AI can summarize the project overview, what I learned, mistakes, improvements, fixes, and any rules that should be added to the project-level AGENTS.md. I connected it through Notion MCP so Codex can update it.
I organized this entire process as a workflow.
At the start of a chat, Codex should read the AI Operating Manual Notion page, then read AGENTS.md and TaskIndex.md, so it can start working with the same understanding as me. I registered this as a Skill so I can call it with a single phrase.
At the end of a work session, Codex should summarize what was done and organize what should be saved as mid- to long-term project memory in the AI Operating Manual Notion page. I registered this as another Skill so I can call it with a single phrase.
Finally, I registered a separate Skill that can write the summarized content to the AI Operating Manual Notion page. I separated this from the summary Skill so that I can review the content first and decide what should actually be saved as mid- to long-term project memory before running the write operation.

💡 Key Takeaways

📱 SwiftUI Learning

By asking Codex to implement the SwiftUI UI based on the Figma UI structure and the small design system page, I was able to get a UI that was very close to the design I created in Figma.
I learned that Codex sometimes adds many custom style definitions in the code, even in areas where SwiftUI’s default styling system would be enough. I need to decide more carefully which parts should rely on SwiftUI’s default styles and which parts should be customized.
Through this implementation, I learned that I need to separate the parts where I want to take advantage of SwiftUI’s built-in default styles from the parts where I want to apply my own custom design.
I also noticed that Codex tends to implement SwiftUI previews using older syntax. This helped me understand the difference between older preview code and the newer style I learned in the SwiftUI tutorials.
I also learned that if I want colors to be managed in Assets.xcassets, I need to explicitly tell Codex to do that.
I learned that I should add rules for Codex so that the same kind of issue does not happen in the next implementation.
I learned how SwiftUI draws horizontal and vertical lines using .frame(width:height:) and .position(x:y:).
I learned that .position(x:y:) places the center of a view.
I learned that a parent view’s @State change causes SwiftUI to recalculate the parent view’s body.
I learned that child views are updated when new values are passed from the parent view.
I learned that @ViewBuilder does not trigger UI updates by itself.
@ViewBuilder is used to write conditional view logic, such as showing or hiding a view depending on a condition.

🆙 Updating my workflow Learning

🤖 AI agent workflow

🐛 How My Workflow Changed

Previously, I had to explain in each prompt who I am, how I prefer to work, and what kind of reasoning I expect from Codex. For example, I often had to explain my background and say things like, “Because I think this way, please do not do that.” By organizing this information in advance, I no longer need to repeat those explanations every time, and the direction of Codex’s responses is now much closer to what I expect.
I can now start talking with Codex about the task I want to work on right away, without wasting time aligning the process. Before, when I felt that Codex was moving in a slightly different direction, I had to explain the project background, current progress, and what I wanted to do next in order to bring Codex back to the same understanding.
By formatting the workflow, I no longer feel unsure about what information I should give Codex when working on any project. I created a system that lets Codex reach a consistent level of understanding with a minimal prompt. Because I also defined a clear way to operate Codex in order to protect that system, I feel that I can work with it more confidently and without hesitation.

📝 What I Learned From This

I felt that in order to use an AI agent effectively, I need to clearly tell it who I am and what kinds of actions or workflows I prefer.
At the same time, I realized that this kind of workflow becomes possible when I clearly define what I will delegate to the AI agent and what I will handle myself. In my workflow, the AI agent should not immediately start working on a task. Instead, it should first propose a plan, and then I, as the human user, review and approve it before the task is executed.
This feels similar to the relationship between a manager and a team member. In other words, I felt that using an AI agent effectively depends on how well the human can act as a capable manager. I also realized that the skills used to manage work in real-world teams can be useful when working with AI agents.
For regular applications that are used simply as tools, the important skills are things like understanding the features and knowing how to use the application well.
I found it interesting that the skills needed for AI agents are different from the skills needed for ordinary tools. This difference feels like one of the unique characteristics of AI agents.

🚀 Next Week

Continue developing the top menu screen for ToneDrill.
Organize the UI adjustment points for the portfolio site implemented by Codex in Notion, then start making small UI refinements.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W12

Umitomo — Fri, 03 Jul 2026 04:42:07 +0000

🗓️ This Week

I had less time to work on my personal projects this week😅, but I was still able to make some progress on both my iOS app and web development projects.
One reason I was able to keep moving forward was that I used ChatGPT and Codex to work more efficiently. This week reminded me how helpful AI can be for personal development projects🦾.
I continued refining the UI direction for ToneDrill mini, the minimum-feature iOS app I implemented in Xcode last week.
Last week, I was excited to build the basic functionality of a working minimum-feature app in Xcode. This week, I shifted my focus to creating a clearer UI image for the app🎯.
I was not sure how to approach the UI design at first, but after discussing it with AI, I decided on a direction. I would like to keep using this approach as a base going forward🐎.
For web development, I finished reviewing the implementation of the portfolio site that Codex created last week❤️‍🔥.
I gained a better understanding of shadcn/ui and realized how convenient it is for building consistent UI components.
I was not able to work on TryHackMe this week, so I would like to make time for it again next week🔥.

I also want to thank everyone who commented on my previous Weekly Dev Log 2026-W11✨

Reading the comments on my previous Weekly Dev Log made me feel that I would also like to try writing standalone articles that go deeper into what I learned.

I hope I can share my honest learning process and thoughts in different formats, not only through Weekly Dev Logs.

Also, thank you so much for leaving positive comments on my personal, honest Weekly Dev Logs!

I always appreciate your comments, so please feel free to leave one if you have any thoughts or feedback.

📱 iOS (SwiftUI)

I used Codex and Figma to create the UI design for the minimum version of ToneDrill mini.
I asked Codex to generate several UI design ideas, then chose the one I liked and organized it as a design file in Figma.
ToneDrill mini will have multiple screens in the future, but I focused on designing only one main interaction screen first.
I started organizing a Mini Design System based on that one screen so that future screens can have a consistent UI.
At first, I considered organizing the design rules in a text file like Design.md, but I decided to organize them visually in Figma instead.
I organized the basic color structure, including background colors, text colors, button colors, and typography rules.

🎸 ToneDrill mini UI Image

Here are two UI images of ToneDrill mini: the current UI before creating the Figma design, and the temporary UI direction I created this week using Codex and Figma🥰.

I am excited to start implementing the app based on this new UI image🔥

(Current ToneDrill mini UI screenshot)

(ToneDrill mini UI screenshot decided this week)

🌐 Web Development

Posted my weekly dev log on Dev.to 📝.
Reviewed the structure of the portfolio home page created with React Router v7.

🔐 Security (TryHackMe)

I was not able to work on TryHackMe this week. I would like to make time for it again next week!

💡 Key Takeaways

📱 SwiftUI Learning

I noticed that if I ask Codex to create UI designs each time without clear rules, the colors, spacing, and font sizes can easily become inconsistent.
I learned that it is better to create one base UI design first, then organize the frame structure and Mini Design System based on that design.
I also considered asking Codex to implement a SwiftUI prototype first and then adjusting it in Xcode, but I felt that organizing the UI visually in Figma first was easier for me to understand.
Having the UI structure and color roles visible in Figma made it easier to understand the design than organizing everything only in text.
I learned that a visual design reference also makes it easier to imagine what needs to be changed after implementing the UI in SwiftUI.
For a personal iOS app like this, I felt that it is better to start with a small set of design rules based on one screen, rather than trying to build a large design system from the beginning.

🌐 Web Development Learning

Learned that sticky top-0 keeps the sidebar content visible near the top of the screen while scrolling.
Reviewed how Tailwind CSS utility classes are used to control layout in the profile sidebar.
Learned that flex flex-wrap is useful for arranging small elements naturally and letting them wrap when space is limited.
Learned that flex is better for content-sized inline groups, while grid is better for structured row-and-column layouts.
Reviewed the shadcn/ui Button component and learned that asChild lets a child element, such as an <a> tag, receive the button styles while keeping its original HTML meaning.
Rearned that this makes it possible to create a link that looks like a button, while still using the correct semantic element for navigation.
Reviewed the official shadcn/ui Button documentation and learned how asChild, variant, and size help create consistent button UI patterns.
Learned that shadcn/ui helps create consistent UI while allowing predefined design variations through component props, and its documentation makes it easy to understand how each prop affects the result.

🚀 Next Week

Finish organizing the Mini Design System for ToneDrill mini in Figma.
Organize the UI adjustment points for the portfolio site implemented by Codex in Notion, then start making small UI refinements.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W11

Umitomo — Fri, 26 Jun 2026 21:04:23 +0000

🗓️ This Week

While reviewing the code for the minimum-feature iOS app that Codex implemented for ToneDrill, I started coming up with many ideas for small improvements💡.
When I first started building the iOS app, I thought it would be enough to recreate the web version I had casually built before. However, once the app started taking shape, I naturally began wanting to add more features and improve the design🌋. At the same time, this is my first time building an iOS app, so I often do not know the best way to move forward. Human curiosity and ambition are interesting 😅.
Because of that, I discussed my ideas with ChatGPT, separated them into short-term tasks and medium- to long-term ideas, and organized a realistic development plan in Notion🗃️.
For now, I decided to focus on completing the minimum-feature version implemented by Codex. I changed the app layout from the default portrait orientation to landscape orientation and organized several UI ideas🦾.
I reviewed the program that Codex implemented last week based on my Figma design.
I learned more about React Router v7 features and several CSS functions.
Worked on the AI System Reconnaissance room from the AI Security Learning Path on TryHackMe this week 🤖.

📱 iOS (SwiftUI)

Organized feature ideas I would like to add to ToneDrill in Notion and separated them into short-term tasks and medium- to long-term tasks.
Changed the app layout from the default portrait-oriented design to a landscape-oriented design.
Planned the next UI improvement for the app: replacing horizontal scrolling with left and right buttons to switch the visible fret range.
Explored a design direction for a SwiftUI-drawn guitar fretboard background before using a real image background.
Worked with ChatGPT to define the direction for a fretboard-style UI in SwiftUI, organized the required display elements, and prepared them as a specification for Codex.
Prepared a concrete Codex prompt for generating a Figma draft based on the design task document and reference image.

🌐 Web Development

Posted my weekly dev log on Dev.to 📝.
Reviewed the structure of the portfolio home page created with React Router v7.
Checked how root.tsx, routes.ts, and home.tsx work together to render the top page.
Studied how the loader function passes page data to the home component.
Looked through home-page-layout.tsx and checked how the main area and profile sidebar are arranged.
Reviewed app.css to understand the layout, responsive design, and light/dark color settings.
Looked up grid-template-columns, minmax(), clamp(), and @media using MDN and ChatGPT.

🔐 Security (TryHackMe)

Worked on the AI System Reconnaissance room, part of the AI Security Learning Path on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

Learned how to configure an iOS app to support landscape orientation.
Learned how to adjust the UI layout so it fits neatly on the screen in landscape mode.
Learned that a SwiftUI-drawn fretboard background is a safer first step than placing buttons directly on top of a real guitar image.
Learned that building the fretboard UI with separate background and button layers will make it easier to replace the background with an image later.
Learned that Codex should first explain its planned Figma structure before actually creating or modifying the design.
Learned that giving Codex a task document, a reference image, and clear constraints helps reduce unexpected changes.

🌐 Web Development Learning

Learned that root.tsx provides the base HTML layout, and child routes are rendered through <Outlet />.
Learned that loader prepares data before the page component is rendered.
Learned that home-page-layout.tsx mainly controls the page structure, while app.css controls most of the visual design.
Learned how CSS Grid is used to create a two-column layout with a flexible main area and a fixed-width sidebar.
Learned that grid-template-columns defines the width rules for each grid column.
Learned that minmax() sets the minimum and maximum size of a grid column.
Learned that clamp() lets a value change flexibly within a minimum and maximum range.
Learned that @media rules can be used for different CSS conditions. In this project, they are used to change the layout based on the screen width.
Learned how media queries change the layout from three-column cards to two columns, and then to one column on smaller screens.
Learned how CSS variables are used to manage colors for light mode, dark mode, and portfolio-specific design tokens.

🔐 TryHackMe Learning

AI System Reconnaissance

Task 2: The AI Infrastructure Stack

I learned that AI infrastructure is not just a single AI model or server, but a collection of specialized services that support the whole machine learning lifecycle.
I understood that AI systems often expose unfamiliar ports and APIs, so traditional network scanning alone may miss important AI-related services.
I learned that services such as model serving endpoints, experiment tracking tools, vector databases, model registries, Jupyter notebooks, MinIO, and Prometheus can all become important reconnaissance targets.
Although there were many new terms and I could not fully understand every single one, I was able to understand the main purpose of this task: building a mental map of AI infrastructure components and their common ports.
Through the exercise, I learned how to compare AI-specific ports with traditional service ports and identify which hosts are likely running AI infrastructure.

🚀 Next Week

Design the UI structure for the minimum-feature version of ToneDrill in Figma.
Finish reviewing the program that Codex implemented last week based on my Figma design and deepen my understanding of how the code works.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W10

Umitomo — Thu, 18 Jun 2026 06:39:33 +0000

🗓️ This Week

While organizing ideas for my first iOS app, I remembered an old web app idea called ToneDrill, which I had casually built before to help practice note names on a guitar fretboard🎸. I decided to try turning it into an iOS app🛠️.
I clarified the purpose of ToneDrill, its minimum requirements, and its core features, then organized them in Notion📝.
I was curious to see how well Codex could implement an iOS app from those minimum requirements, so I gave it a try right away💡.
I reviewed the SwiftUI code generated by Codex and worked through the app logic to understand how it was implemented🔍. For now, I was able to create a working app, which felt like a meaningful step forward🚶.
I created the top page UI design for my portfolio website in Figma🎨. I focused on keeping the structure simple and implementation-friendly, and designed the UI with reusable components for each major part.
Based on what I learned from my previous failed attempt, I tried again to see how well Codex could implement a prototype from the Figma UI design (You can read about my previous attempt that didn’t go so well here😅.)
Worked on the AI Threat Modelling room from the AI Security Learning Path on TryHackMe this week🤖.

📱 iOS (SwiftUI)

Revisited an old web app idea called ToneDrill, which I had previously built casually as a guitar note-training app, and considered turning it into an iOS app.
Organized the app idea in Notion, including its purpose, target use case, minimum requirements, and core features.
Decided to aim for an MVP-level version first, instead of trying to build a fully featured app from the beginning.
Wrote down simple requirements and tested how accurately Codex could implement the initial version of the app.
Reviewed the iOS app implementation generated by Codex and examined the code in detail to understand how the logic worked.

🌐 Web Development

Posted my weekly dev log on Dev.to📝
Completed the top page UI design for my portfolio website in Figma.
Tried using Codex again to generate a prototype app based on the Figma UI design.

🔐 Security (TryHackMe)

Worked on the AI Threat Modelling room (part of the AI Security Learning Path) on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

🦄 What I learned by starting with a small app and minimum features

I started building the app with the mindset of creating small, steady progress instead of trying to build a large app right away.
Starting small made it much easier to take the first step mentally and actually begin building the app.
Even though the app is small, I realized that the knowledge I gained from tutorials alone was not enough to fully understand the implementation details.
I had to review and research the code step by step to understand how each part worked.
This made me realize that if I started with a much larger app, it would take a lot more time to understand the implementation while building it.
I also learned that I should define more clearly when and how I use Codex during development.
For now, my plan is to keep using AI actively until I can complete one working app, then evaluate where AI is most helpful and where I need to review the code more carefully myself.

🌐 Web Development Learning

❤️‍🔥 What I learned from retrying prototype generation with Figma MCP and Codex

Learned that I should first ask Codex to review the design system in the Figma UI design, then have it create rule files such as app.css and FIGMA_DESIGN_SYSTEM.md based on those design rules.
Learned that designing a Figma UI with implementation in mind is important when asking Codex to generate a prototype.
Instead of only creating a visual mockup, I structured the UI with clear frames, reusable components, and layout rules.
I also documented the design system in rule files so Codex could better understand the intended structure, spacing, colors, and component styles.
As a result, Codex was able to generate a prototype that closely matched the Figma design🔥.

🔐 TryHackMe Learning

AI Threat Modelling

Task 6: OWASP LLM Top 10 — Mapping Risks to Components

I learned that the OWASP LLM Top 10 helps map LLM-specific risks to the components where they occur.
OWASP LLM Top 10 is useful not only as a checklist, but also as an assessment tool for reviewing LLM architecture.
I learned that the LLM inference endpoint has the highest risk concentration, including prompt injection, sensitive information disclosure, excessive agency, system prompt leakage, misinformation, and unbounded consumption.
Vector databases and RAG pipelines require special attention because they can introduce indirect prompt injection, embedding weaknesses, and misinformation from stale or incorrect sources.

🚀 Next Week

Review the issues and improvements needed in the minimum-feature app generated by Codex, then start making code changes.
Ask Codex to help explore UI design ideas for the ToneDrill app and decide on the overall UI direction.
Review and understand the implementation details of the portfolio website prototype generated by Codex.
Continue posting small articles on Dev.to.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W09

Umitomo — Fri, 12 Jun 2026 00:10:44 +0000

🗓️ This Week

Completed the SwiftUI app development tutorial and tested the app I built on a real iPhone🦾
Learned the overall flow of building an iOS app with SwiftUI.
Organized my app ideas in Notion because I want to start building a real app next week🤔 I also realized that starting with a small app is important at this stage💡
Worked on the UI design for my portfolio site using the official shadcn/ui Figma template. I want to finish one design direction next week and then move on to implementation.
Worked on the AI Threat Modelling room from the AI Security Learning Path on TryHackMe this week🤖

📱 iOS (SwiftUI)

Completed the SwiftUI app development tutorial.
Learned how to run an app on a real iPhone by connecting it to my computer, without joining the Apple Developer Program yet.

🌐 Web Development

Posted my weekly dev log on Dev.to📝
Worked on my portfolio site UI design using the official shadcn/ui Figma template.

🔐 Security (TryHackMe)

Worked on the AI Threat Modelling room (part of the AI Security Learning Path) on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

🔬 What I learned from testing an app on a real iPhone

I need to connect my iPhone, choose it as the run destination, and configure Signing & Capabilities before running the app.
A unique Bundle Identifier is needed to identify the app.
Xcode uses my personal Apple Account to sign the app for testing on my iPhone.
I need to enable Developer Mode and trust the developer profile on the iPhone before launching the app.
Preview data and real app data are handled differently in SwiftUI/SwiftData.
In previews, sampleContainer is used, so includeSampleMoments is passed as true.
The diary entries I create on the real iPhone are saved in the app’s local storage on the device.
The data is not automatically saved to my Apple Account or iCloud.

🦄 What I learned from organizing ideas for my first iOS app

As a beginner developer, I should not try to build a large, market-ready app from the beginning.
Large apps usually include many hidden complexities, such as data management, user experience design, error handling, security, performance, and long-term maintenance.
Since I have a full-time job, my development time is limited, so starting too big would make it harder to keep making steady progress.
Starting with a small app helps me focus on one or two core ideas and understand each part more deeply.
Building something small first also makes it easier to finish, test, and improve the app step by step.
I realized that the goal at this stage is not to compete with polished apps on the market, but to build practical experience by completing small projects.
This approach should help me stay motivated while gradually improving my skills in real app development.

🌐 Web Development Learning

Learned more about how to create UI designs in Figma and how to design screens using components.
Practiced building a consistent portfolio site design based on a design system instead of creating each part separately.

🔐 TryHackMe Learning

AI Threat Modelling

Task2 AI-Specific Assets and Attack Surfaces

AI systems add new assets such as training data, model weights, embedding vectors, system prompts, feature stores, and model registries.
I learned that poisoned training data can corrupt a model’s behaviour at the source.
I learned that model weights are especially valuable because they define what the model has learned.
If model weights are stolen, an attacker may obtain a functional copy of the AI system.
I learned that system prompts can reveal the model’s behaviour, constraints, business logic, and security guardrails.
Embedding vectors are important in systems such as RAG pipelines, recommendation engines, and fraud detection systems.
Manipulating embeddings can change what information the model sees at query time.
Feature stores are important because they provide preprocessed data used as real-time model inputs.
Tampering with feature stores can affect model decisions without changing the model itself.
A compromised model registry can allow an attacker to replace a legitimate model with a backdoored one.
AI threat modelling needs to consider not only traditional application risks, but also AI-specific assets, behaviours, and failure modes.

Task3 Data Supply Chain and STRIDE's Gaps

I learned that AI systems have a data supply chain in addition to a traditional software supply chain.
Each stage of the AI data supply chain can become a point of compromise.
Data poisoning can start from data collection, labelling, or other early pipeline stages.
If poisoned data reaches training, the damage can become embedded in the model’s weights.
A compromised model registry can allow attackers to replace a validated model with a backdoored one.
A backdoored model may look normal until it receives specific trigger inputs in production.
LLM-based systems can introduce additional injection points through retrieval pipelines during inference.
AI threats such as data poisoning, adversarial manipulation, tool misuse, and model theft do not always fit neatly into traditional STRIDE categories.
The key takeaway is that AI threat modelling must cover the full data supply chain and AI-specific failure modes.

Task4 Adapting STRIDE for AI Systems

I learned that STRIDE does not need to be replaced, but it needs to be adapted for AI systems.
In AI systems, familiar STRIDE categories can appear in new forms, such as data source impersonation, data poisoning, model extraction, and inference cost exploitation.
AI decisions are harder to audit because the model version, input features, prompts, and retrieved context may not be fully recorded.
Tool-enabled AI systems can make privilege risks broader, because a jailbroken model may misuse databases, email systems, or other connected tools.
The key takeaway is that STRIDE is still a useful starting point, but some AI risks require additional AI-specific frameworks such as MITRE ATLAS.

Task5 MITRE ATLAS: The AI Threat Technique Catalogue

I learned that MITRE ATLAS is an AI-focused knowledge base for adversary tactics and techniques against AI and ML systems.
ATLAS complements STRIDE by adding AI-specific technical detail, documented techniques, mitigations, and real-world case studies.
I learned key ATLAS techniques such as Data Poisoning, Model Extraction, Evade ML Model, LLM Prompt Injection, and Backdoor ML Model.
ATLAS helps turn broad STRIDE findings into specific, actionable threat findings with technique IDs and defensive guidance.
Real-world cases such as ShadowRay and Morris II show that AI threats are not only theoretical, but can affect real AI infrastructure and RAG-based systems.

🚀 Next Week

Start building a small iOS app based on the app ideas I organized this week.
Finish one portfolio site UI design in Figma and start implementing it in code.
Continue posting small articles on Dev.to.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W08

Umitomo — Thu, 04 Jun 2026 02:13:06 +0000

🗓️ This Week

Completed one section of the SwiftUI tutorial 🦾 Since I want to continue through the tutorial until I can build the app for testing and run it on an actual iPhone, I’ll focus on that from next week.
I also wrote another standalone article this week. It was about my experience experimenting with Codex and Figma MCP to see how much UI design work I could delegate to AI📝 If you're interested, feel free to check it out 👇

I Thought Figma MCP Could Recreate Any Design. I Was Wrong.

Umitomo
Umitomo

Umitomo

Follow

Jun 2

I Thought Figma MCP Could Recreate Any Design. I Was Wrong.

#beginners #devjournal #ai #figma

4 reactions
5 comments

6 min read
I’ll continue working steadily on my portfolio site design by combining AI-generated UI ideas with the official shadcn/ui Figma design template.
Completed LLM Security room from the AI Security Learning Path on TryHackMe this week🤖

📱 iOS (SwiftUI)

Worked through the SwiftUI tutorial and completed "Reproduce a bug with unit tests"

🌐 Web Development

Posted my weekly dev log on Dev.to and a standalone article about my experience using Codex × Figma MCP 📝
Started learning UI design in Figma using community resources

🔐 Security (TryHackMe)

Completed LLM Security room (part of the AI Security Learning Path) on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

Reproduce a bug with unit tests

Learned that a streak should only increase when a moment exists on the next consecutive day.
Understood that multiple moments on the same day should not increase the streak more than once.
Learned how continue skips duplicate days while keeping the current streak.
Realized that break stops the calculation as soon as a gap in the streak is found.
Learned that fixing one bug can accidentally introduce new bugs in other scenarios.
Learned how to implement parameterized unit tests by preparing multiple input patterns and expected values.
Used @Test(arguments:) to run the same test logic with different test data.
Used #expect to compare the actual result with the expected value for each case.

🌐 Web Development Learning

While experimenting with automating UI design using Codex × Figma MCP, I learned that clearly defining design system rules first and then building the UI from small components is important for reducing the gap between the original Figma design and the implementation generated from its design data.

🔐 TryHackMe Learning

LLM Security

Threat Categories

Data-Based Threats

Training data extraction
Membership inference
Prompt leakage

Model-Based Threats

Model extraction
Model inversion

System-Based Threats

Prompt injection
Context Overflow
Memory Poisoning

User-Based Threats

LLM-powered social engineering
Trust exploitation

LLM Security Threat Cheat Sheet

Type	Threat	Target / Attack Surface	Input	Output
Data-Based	Training Data Extraction	Training dataset (confidentiality)	Crafted prompts designed to trigger memorised content	Verbatim or near verbatim training data (text, PII, secrets)
Data-Based	Membership Inference	Training dataset membership (privacy metadata)	Known candidate data sample already possessed by the attacker	Yes/no (or probability) decision indicating whether the sample was used in training
Data-Based	Prompt Leakage / System Prompt Exposure (LLM07:2025)	System prompt / developer instructions	Prompts asking the model to reveal or reflect on its instructions	Partial or full disclosure of hidden system or developer prompts
Model-Based	Weight Extraction (Model Stealing)	Model parameters (intellectual property)	Large volumes of carefully chosen API queries	A surrogate or distilled model replicating the original model's behaviour
Model-Based	Model Inversion	Model's internal representations	Unknown or partially known data, or model embeddings/outputs	New training data or attributes reconstructed from the model
System-Based	Context Window Poisoning (Prompt Injection)	LLM context window (instruction hierarchy)	Attacker controlled text embedded in input or retrieved content	Altered behaviour, policy bypass, unintended actions
System-Based	Context Overflow / Unbounded Consumption (LLM10:2025)	Context window size and system resources	Excessively large prompts or documents	Truncated safeguards, degraded responses, or denial of service
System-Based	Stateful Conversation Manipulation (Memory Poisoning)	Persistent conversation memory	Malicious statements intended to be stored as long term context	Persistent misinformation or corrupted future responses
User-Based	LLM-Powered Social Engineering	Human cognition and decision-making	Contextual or personal information used to craft persuasive output	Manipulated users (phishing success, fraud, coerced actions)
User-Based	Trust Exploitation / Misinformation (LLM09:2025)	User trust and judgment	Confident but incorrect or maliciously framed prompts	Users accepting false, unsafe, or harmful information

Key Takeaways

LLMs introduce a unique attack surface distinct from traditional ML systems, driven by natural language interaction, context handling, and emergent behaviour.
Data-based threats exploit how LLMs learn from and memorise training data, enabling attacks such as training data extraction, membership inference, and system prompt leakage.
Model-based threats target the model itself, including model extraction (theft of model behaviour or weights) and model inversion (reconstructing sensitive training data).
System-based threats arise from how LLMs process all inputs as a single context, enabling prompt injection, context window overflow, and memory poisoning.
User-based threats leverage LLMs as force multipliers for social engineering, increasing the effectiveness of phishing, scams, and trust exploitation.

🚀 Next Week

Work through the "Preparation for Distribution" section of the SwiftUI tutorial.
Continue posting small articles on Dev.to.
Explore Figma MCP and experiment with generating UI design ideas using AI.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.