DEV Community: Umitomo

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.

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

Umitomo — Tue, 02 Jun 2026 00:30:16 +0000

Introduction

Since I started publishing articles on Dev.to, I've been working on a personal project to transform my old blog website—which is no longer actively maintained—into a portfolio site♻️

As part of that project, I recently started learning Figma and UI design🎨 When I discovered Figma MCP, I imagined a future where generative AI could automatically create polished, modern, and visually appealing designs for me with minimal effort😎

Unfortunately, reality turned out to be quite different.

This article is a reflection on that experience and a reminder to my future self about what I learned along the way📝

TL;DR

I wanted to design a portfolio website in Figma, but quickly realized that UI design was more difficult than I expected.
I wondered whether using Codex and Figma MCP would allow me to outsource the design process to AI, so I decided to try it.
I couldn't magically generate the polished design I had imagined while also maintaining a well-structured Figma file with globally managed variants and reusable components.
I learned that defining design rules first and building components step by step helped produce results that were much closer to my original vision.
Even then, the process was not dramatically easier than expected, so I eventually decided to keep things simple and build my portfolio around the design principles already provided by shadcn/ui.

What I Tried with Figma MCP🎨

While planning the UI design for my portfolio website, I initially created simple wireframe-like layouts in Figma to explore the overall page structure and component placement before working on detailed designs.

At first, I wanted to keep things simple.

However, as I continued working on the project, I found myself wanting something more polished, more modern, and ultimately more impressive.

The problem was that I have very little confidence in my design skills. I'm an in-house IT engineer, not a professional developer or designer, so I often struggle to judge what makes a design truly good.

That led me to a simple idea:

What if I could let AI handle the design work for me?

While researching possible solutions, I discovered that Codex could interact with Figma through Figma MCP. By connecting the two, Codex could actually edit Figma files and create designs based on my instructions.

That sounded promising.

So I decided to give it a try.

Doesn't Everyone Dream at First?🎰

Before using it for my real portfolio project, I wanted to answer a few questions:

Can Codex really create designs directly in Figma?
Can it generate polished and visually appealing layouts?
How accurately can it turn a Figma design into a real web page?

Since it was also my first time using Codex, I decided to run a quick experiment.

My test process looked like this:

Install the Codex application.
Set up the Figma integration so Codex could write design data to Figma.
Create a blank Figma design file.
Create a local test project.
Send a simple prompt to Codex and verify whether it could generate a design inside Figma.
Ask Codex to build a web page from the generated design and evaluate how closely the implementation matched the design.

There are already plenty of great articles from DEV Community members explaining the setup process in detail, so I won't cover it here😂

The prompt I used was surprisingly simple:

Create a stylish portfolio website design.

(Screenshot of the generated Figma design)

(Screenshot of the web page generated from the Figma design)

And honestly?

The results were far better than I expected😮

The generated design looked great.

The generated web page closely matched the design.

For a moment, it genuinely felt like magic.

Reality Hits🪄

Encouraged by the results of my initial experiment, I decided to use the same approach for my actual portfolio project.

This time, I asked Codex to create a Figma design based on a homepage concept image generated by ChatGPT.

However, the results were very different from what I had expected.

At first glance, the generated design looked somewhat reasonable. But once I looked more closely, it lacked consistency. Component sizes, spacing, and layout rules all felt disconnected from one another.

It seemed as though the AI had focused only on the overall "polished feeling" of the image while missing the underlying structure that made the design work.

As a result, the entire page ended up feeling cluttered and disorganized.

To be honest, my only reaction was:

"Wait... how did it end up like this?"

Because my earlier experiment had produced surprisingly good results, I had assumed the same thing would happen with my real project.

Reality turned out to be much less forgiving.

It was at this point that I finally realized I had misunderstood something important.

The Problem Wasn't AI🔎

My first thought was:

"Maybe AI just isn't smart enough yet."

But the more I worked on the problem, the more I realized that the issue was somewhere else.

I had only provided the AI with a finished design image.

What I had not provided were the rules behind that design.

For example:

A color palette
Typography rules
Spacing guidelines
Component variants
A layout grid

None of those things had been defined.

A human designer might be able to infer some of those details from an image.

However, an AI generating designs through Figma MCP needs more than just a visual reference. It has to translate that image into actual components, layouts, and reusable design patterns.

In other words, I was essentially saying:

"Make it look like this image."

without having any design system in place.

Looking back, it's no surprise that the results were disappointing.

Starting Over with Small Steps🚶‍♂️

So I changed my approach.

Instead of generating an entire page from the start, I decided to build the foundation first.

I began by creating a design specification file and defining things such as:

Colors
Typography
Spacing
Border radius values
Shadows

Next, I created small reusable components, including:

Buttons
Cards
Tags
Navigation elements

I then defined variants such as:

Primary
Secondary
Outline

Only after those pieces were in place did I move on to creating the page design itself.

The results were dramatically better.

The design was no longer chaotic, and the overall structure felt much more consistent.

Communication with the AI also became smoother, and providing feedback or requesting changes became significantly easier.

It Still Wasn't Magic👻

There was, however, one thing that surprised me.

The design was definitely better.

But the feeling I had during my first experiment—

"Wow, this is the future!"

—was gone.

In the end, I still needed to:

Organize design tokens
Design components
Define variants
Think through layouts

AI hadn't eliminated those tasks.

Instead, I realized something different:

The better your design system is, the more effectively you can use AI.

That felt much closer to reality.

What I Ended Up Doing🤖

Eventually, I decided to base my portfolio design on shadcn/ui, which had been my original plan from the beginning.

The reason was simple.

A lot of work had already gone into defining:

Component architecture
Variant patterns
Design consistency

and those decisions had been validated by a large community of developers.

To be clear, I still think Figma MCP and Codex are incredibly interesting technologies.

Using them made it obvious that the gap between design and implementation is getting smaller.

But the biggest lesson I learned was this:

AI is not a replacement for a design system.

AI can be an excellent assistant.

However, it is not a magical tool that can automatically generate a complete and well-structured design from a vague idea alone.

At least, not in the way I was hoping to use it.

What I Learned✨

This experience taught me three important lessons:

Think about your design system before asking AI to generate pages.
Design components before designing entire pages.
Good results require clear rules and constraints.

AI can create designs.

But it cannot magically create a design system for you.

Although the experience was a little frustrating, it ultimately helped me understand the importance of design systems far better than before.

Weekly Dev Log 2026-W07

Umitomo — Fri, 29 May 2026 00:18:11 +0000

🗓️ This Week

Completed two more sections of the SwiftUI tutorial 🦾 As I continue working through the tutorial, I can feel my understanding of SwiftUI fundamentals becoming more solid🔥
It was my first time posting a standalone article about reverse engineering📝 If you're interested, feel free to check it out 👇

A Curious Journey Into Reverse Engineering an AI-Generated Python .exe

Umitomo
Umitomo

Umitomo

Follow

May 26

A Curious Journey Into Reverse Engineering an AI-Generated Python .exe

#beginners #reversing #security #python

6 reactions
Add Comment

5 min read
I started creating UI designs for my future portfolio website in Figma. I was able to roughly sketch out the overall structure of the site, but I also realized how difficult it is to create modern and stylish UI designs. (It really made me realize I don’t have much design sense yet 😂💦)
While struggling with the design process, I came across several articles about Figma MCP. That made me interested in exploring how generative AI could help with UI design ideas, so I decided to start researching Figma MCP further.
Completed Securing AI Systems room from the AI Security Learning Path on TryHackMe this week🤖

📱 iOS (SwiftUI)

Worked through the SwiftUI tutorial and completed "Create an Algorithm for Badges" and "Add inclusive features"

🌐 Web Development

Posted my weekly dev log on Dev.to and a standalone article about my first attempt at reverse engineering 📝
Created rough portfolio website UI layouts in Figma
Used shadcn/ui component library design templates in Figma
Started learning UI design in Figma using community resources

🔐 Security (TryHackMe)

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

💡 Key Takeaways

📱 SwiftUI Learning

Add inclusive features

Learned that SwiftUI automatically adapts UI elements for Light and Dark Mode by default.
Learned how to preview and compare Light and Dark Mode layouts in the Xcode canvas.
Understood that system-provided semantic styles help SwiftUI automatically adjust UI appearance.
Learned that SwiftUI uses view modifiers to customize ScrollView behavior.
Understood that .scrollBounceBehavior(.basedOnSize) only enables bouncing when the content is larger than the visible area.
Learned that .defaultScrollAnchor(.center, for: .alignment) centers smaller content inside a ScrollView.
Learned that the dynamicTypeSize modifier can be applied to any SwiftUI view.
Learned how AttributedString(localized:) supports localization-aware text in SwiftUI.
Understood that (inflect: true) automatically changes words like “Day” and “Days” based on the number value.
Learned that SwiftUI can apply different font styles to specific parts of an AttributedString.
Realized that Apple provides built-in grammar inflection support for more natural localized UI text.

🌐 Web Development Learning

Reviewed several useful functions in Figma
Learned the importance of focusing on the overall page layout before designing detailed UI components

🔐 TryHackMe Learning

Securing AI Systems

Task 2 Anatomy of an AI System

Traditional apps use deterministic logic, while AI systems rely on probabilistic model inference.
AI systems accept free-form natural language, making input validation much harder.
Prompt Construction combines the system prompt, user input, and retrieved context before sending data to the LLM.
RAG allows LLMs to retrieve external knowledge from a vector store or other data sources.
A vector store contains embedded representations of internal documentation for retrieval-augmented generation (RAG)
Trust boundaries are points where data moves between different security contexts.
Major trust boundaries include user-to-system, system-to-LLM, LLM-to-tools, and system-to-user.
LLM-to-tools is especially sensitive because model output can trigger real actions.
Tool layers may execute database queries, API calls, or file operations on behalf of the LLM.
Security controls are needed at every boundary to reduce prompt injection and data leakage risks.

Task3 The AI Attack Surface

Studied the OWASP LLM Top 10 and how major risks affect AI-integrated systems.
Learned that MITRE ATLAS documents adversary tactics and exploitation techniques for AI systems.
Studied how the NIST AI RMF approaches AI security from a governance and risk management perspective.
Learned the difference between OWASP (vulnerabilities), ATLAS (attack techniques), and NIST AI RMF (risk governance).

Task4 System-Level Threats

Studied how LLM10 Unbounded Consumption can cause resource exhaustion and extreme cost increases through excessive requests.
Learned that system prompts may leak internal rules, tool information, and architecture details if exposed.(LLM07).
Understood that LLM output must never be trusted as safe input for downstream systems.(LLM05)
Learned that Excessive Agency occurs when AI systems are given unnecessary permissions, tools, or autonomy.(LLM06)
Learned that users may unintentionally leak sensitive information when using AI systems.(LLM02)
Studied how the OWASP LLM risks relate to the CIA triad across confidentiality, integrity, and availability.

Task 5 Secure Design Patterns

Learned that security controls are most effective when applied during the design stage of AI systems.
Learned that layered controls reduce the risk of end-to-end attack success.
Understood the importance of least privilege for AI tools, API tokens, and database access.
Learned that write operations should require human approval before execution.
Studied how input and output validation reduce prompt injection and downstream injection risks.
Learned that MLSecOps integrates security throughout the AI and machine learning lifecycle.

🚀 Next Week

Complete the badge algorithm in 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.

A Curious Journey Into Reverse Engineering an AI-Generated Python .exe

Umitomo — Tue, 26 May 2026 05:02:08 +0000

Introduction

I usually post weekly learning and development updates on Dev.to📝

This time, however, I decided to write a standalone article about something a little different — my first attempt at reverse engineering🦾

What started as simple curiosity quickly turned into an exciting journey of uncovering how a modern AI-generated Python application was actually structured internally🔎

TL;DR

Reverse engineered a PyInstaller-based Python .exe
Reconstructed a surprisingly large portion of the application's architecture from the packaged .exe
Analyzed .pyc files using tools like strings, pycdc, and pycdas
Learned how React/Vite frontend assets can be bundled into a standalone executable
Realized how difficult production frontend bundles are to understand without the original source code
Thought deeply about maintainability in the age of AI-generated applications

What I Reverse Engineered

As someone who works in IT administration and internal tooling, I often become curious about how applications are actually built under the hood.

This time, a coworker showed me a PDF-processing desktop application that had been created with the help of generative AI.

The overall architecture had already been explained to me verbally beforehand.
However, that led me to a simple but exciting question:

How much of an application's internal structure can actually be reconstructed just by reverse engineering the final .exe file?

That curiosity became the starting point of this exploration.

The application itself was a harmless internal utility designed for local use, and this investigation was performed purely within an authorized and educational context.

Rather than trying to analyze malware or bypass protections, I wanted to understand:

What information remains inside packaged executables
How modern Python applications are bundled
Whether frontend/backend structures could still be inferred after packaging
How much architectural detail could realistically be reconstructed from compiled artifacts alone

What made the process especially exciting was slowly piecing together the architecture from small clues hidden inside the executable.

Reverse Engineering Environment Setup

Since I was using Kali Linux on WSL for this experiment, I first prepared a small reverse engineering workspace.

Creating a Python Virtual Environment

mkdir -p ~/reverse
cd ~/reverse

python3 -m venv venv
source venv/bin/activate

At first, the virtual environment failed because python3-venv was missing:

sudo apt install python3.13-venv

After that, I recreated the environment successfully.

Installing Basic Analysis Tools

I installed a few basic tools for inspecting the executable and analyzing Python bytecode.

pip install pyinstaller

I also installed binutils so I could use strings:

sudo apt install binutils

Building `pycdc`

To inspect .pyc files more deeply, I built pycdc from source:

sudo apt install -y cmake g++ git

mkdir -p ~/reverse/tools
cd ~/reverse/tools

git clone https://github.com/zrax/pycdc.git

cd pycdc
mkdir build
cd build

cmake ..
make -j4

This generated:

pycdc
pycdas

which I later used to inspect Python bytecode files.

Extracting the PyInstaller Executable

After confirming the executable was likely packaged with PyInstaller, I used pyinstxtractor to extract its contents:

git clone https://github.com/extremecoders-re/pyinstxtractor.git

Then:

cd ~/reverse/pdf_exe

python ~/reverse/pyinstxtractor/pyinstxtractor.py PDF.exe

This generated a directory like:

PDF.exe_extracted/

Inside the extracted directory, I was finally able to inspect files such as:

app.pyc
pdf_stamp_processor.pyc
pdf-stamp-frontend/dist

This was the point where the application's overall structure started becoming much clearer.

How I Reverse Engineered It

Step 1 — Running `strings`

I first started with:

strings PDF.exe

Very quickly, I noticed Python-related strings:

python313.dll
pyi-python-flag
...

This strongly suggested that the application had been packaged using PyInstaller.

Step 2 — Inspecting the PyInstaller Archive

Next, I used:

pyi-archive_viewer PDF.exe

This helped confirm that the executable had been packaged using PyInstaller and allowed me to inspect the internal archive structure.

Step 3 — Analyzing `.pyc` Files

I then used:

pycdc
pycdas

to inspect the extracted Python bytecode files.

However, when running pycdc, I noticed that some parts of the bytecode could not be fully reconstructed.

In many cases, the output stopped after displaying messages like:

Unsupported opcode: CALL_KW (247)
from fastapi import FastAPI, File, UploadFile, Form, HTTPException
...
# WARNING: Decompyle incomplete

Instead of fully recovering the original source code, I had to combine multiple fragmented clues together:

Partial pycdc output
pycdas disassembly output
Extracted strings
Module names
API route names
Library imports

I also used generative AI to help interpret and organize those fragmented technical details while reconstructing the application's architecture.

Even with incomplete reconstruction, I was still able to identify:

FastAPI routes
PDF processing logic
OpenCV-based blank-space detection
PyMuPDF page rendering
Automatic browser launching
Local API endpoints such as:

/api/scan
/api/stamp_and_merge
/api/shutdown

Step 4 — Investigating the Frontend

The frontend bundle was much harder to understand.

The built JavaScript looked like this:

var e=Object.create,t=Object.defineProperty,...

At first, it felt almost impossible to read.

The extracted JavaScript was difficult to understand, and I could not initially tell what kind of frontend structure had originally existed before packaging.

By combining:

The extracted dist/ directory structure
The bundled JavaScript files
API communication behavior observed in the browser developer tools
And explanations generated through conversations with AI

I gradually started to understand how the frontend had likely been packaged and bundled, and that the application was probably using a modern frontend workflow similar to React/Vite.

At the same time, I also realized that the original frontend source structure itself was no longer included inside the executable.

Reconstructing the Architecture

By combining clues from strings, embedded .pyc files, frontend assets, and API routes, I was eventually able to reconstruct a rough picture of the application's architecture:

PDF.exe
    ↓
Launch FastAPI server
    ↓
Open browser automatically
    ↓
Serve React frontend
    ↓
React sends API requests
    ↓
Python processes PDFs locally

The application was not rendering a desktop GUI directly.

Instead:

FastAPI served static frontend files
React rendered the UI inside the browser
Python handled backend processing

What fascinated me most was not simply discovering the architecture itself, but realizing how much of it could still be reconstructed purely from packaged artifacts.

What I Learned

Reverse Engineering Can Reveal More Than I Expected

Before starting this experiment, I assumed that most of an application's architecture would disappear once everything had been packaged into a standalone .exe.

However, I was surprised by how many clues still remained inside the executable:

Python runtime artifacts
PyInstaller structures
Embedded .pyc files
Frontend build outputs
API routes
Localhost references
Technology-specific strings

By connecting those small clues together step by step, I was able to reconstruct a surprisingly large portion of the application's overall architecture.

That process itself was one of the most exciting parts of the experience.

“Working Software” and “Understandable Software” Are Different Things

This experience also made me think deeply about AI-generated applications and software maintainability.

Generative AI can absolutely help create working applications quickly.
However, once only compiled artifacts remain, reconstructing the original design and development intent becomes much harder.

Even after reverse engineering the executable, I still could not fully reconstruct the original frontend source code or understand every implementation detail.

That limitation itself became an important lesson for me.

It reminded me that understanding software architecture and preserving maintainable source structures are just as important as making software work.

Especially in the age of AI-assisted development.

Final Thoughts

This reverse engineering journey was honestly a lot of fun.

What made the experience especially enjoyable was gradually reconstructing the application's architecture from small technical clues hidden inside the executable.

At the same time, the experience gave me a deeper appreciation for software architecture, maintainability, and the importance of preserving understandable source code alongside AI-generated applications.

Weekly Dev Log 2026-W06

Umitomo — Thu, 21 May 2026 01:25:54 +0000

🗓️ This Week

Made a little more progress in the SwiftUI tutorial🦾
Started the journey of building my future portfolio site✈️ First, I created the project files and set up a repository on GitHub. I also started reserching React Router v7 by reading its documentation. I'm moving forward little by little🔥
Completed the ContAInment room from the AI Security Learning Path on TryHackMe this week🤖

💡 Thoughts on the ContAInment Room

This room was a hands-on investigation exercise set in a scenario where a company had suffered a security breach, resulting in important data being encrypted and used for blackmail. The goal was to investigate the compromised environment and discover the hidden flags🔎

I felt that this room built nicely on the concepts I learned in the previous AI Forensics room. One thing I especially enjoyed was solving the investigation by using a dedicated AI assistant available inside the victim environment🤖

As I worked through the challenge, I had to think carefully about what looked suspicious and follow clues step by step while actively using Linux commands. It also turned out to be a great review of Linux operations and practical investigation workflows🔥

📱 iOS (SwiftUI)

Worked through the SwiftUI tutorial and completed Sections 7 and 8: "Create an Algorithm for Badges"

🌐 Web Development

Posted my weekly dev log on Dev.to 📝
Created a new React Router v7 project for my future portfolio site.

🔐 Security (TryHackMe)

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

💡 Key Takeaways

📱 SwiftUI Learning

Section 8: Calculate and Show Streaks

Learned how to calculate a daily streak by comparing saved dates with the current day.
Understood how reversing the array helps process moments from newest to oldest.
Learned how map and compactMap can transform Moment objects into simple day offsets like [0, 1, 2].
Understood how Calendar.dateComponents calculates date differences in calendar-based units.
Learned that multiple moments on the same day should count as a single streak day.
Realized that the streak variable represents the next expected day offset during the calculation.
Learned that comparing daysAgo == streak is a simple way to detect consecutive days.
Understood why using the end of the current day makes streak calculations more stable and predictable.
Learned that @ViewBuilder is used to build conditional or multiple-view UI structures, while Group is mainly used to organize existing views or share modifiers without affecting layout.
Understood that VStack creates all child views immediately, whereas LazyVStack generates views only when they become visible on screen.
Realized that LazyVStack is more suitable for scrollable, data-driven UIs with many or heavy views because it improves memory efficiency and performance.

🌐 Web Development Learning

React Router v7 Framework Mode is similar to Remix, so my Remix experience will still be useful.
root.tsx, routes.ts, and route files work together to render each page.

🔐 TryHackMe Learning

ContAInment

Identified useful indicators from attacker notes and used them to recover encrypted files.
Practiced DFIR-style investigation by following clues across logs, archives, and extracted data.
Used AI-assisted forensic tools to analyze encoded flag candidates and identify the correct flag.
Improved my understanding of how AI systems themselves can become targets in modern cyberattacks.

🚀 Next Week

Complete the badge algorithm in the SwiftUI tutorial.
Continue posting small articles on Dev.to and start creating Web UI designs in Figma.
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-W05

Umitomo — Fri, 15 May 2026 04:44:53 +0000

🗓️ This Week

Made a little more progress in the SwiftUI tutorial.
Started researching web technology stacks and creating a roadmap to gradually turn my current blog into a portfolio site using React Router v7. I'm moving forward little by little.
Completed the AI Forensics room from the AI Security Learning Path on TryHackMe this week.

💡 Thoughts on the AI Forensics Room

The AI Forensics room was much deeper and more challenging than I initially expected, and each task took a significant amount of time to complete. However, it turned out to be an incredibly valuable learning experience 🔥

Task 5, "Practical - The Digital Trail," was especially impressive. It was a story-driven hands-on investigation where I analyzed a compromised company environment after attackers stole critical proprietary source code 🔎

Instead of simply reading explanations, I had to actively investigate logs, suspicious files, reverse shells, persistence mechanisms, and data exfiltration activity step by step.

Because I was constantly thinking, investigating, and connecting the dots myself, the experience felt far more practical and realistic. It gave me a much deeper understanding of how AI-assisted DFIR investigations work in real-world scenarios.

One of the biggest lessons I learned from this room was that AI is a powerful tool, but human insight is still essential. AI can quickly detect suspicious activity, but investigators still need to analyze the context and validate the findings themselves.

📱 iOS (SwiftUI)

Worked through the SwiftUI tutorial and completed Sections 6 and 7: "Create an Algorithm for Badges"

🌐 Web Development

Posted my weekly dev log on Dev.to 📝
Researched how to transform my current blog site into the portfolio site I want to build in the future.
Created a roadmap with ChatGPT to gradually turn my blog site into a portfolio site.

🔐 Security (TryHackMe)

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

💡 Key Takeaways

📱 SwiftUI Review

Reviewed how SwiftData automatically creates relationships between @Model objects through model properties.
Understood how bidirectional relationships work between Moment and Badge models.
Learned that Group is useful when applying modifiers to conditionally displayed views.
Realized that SwiftUI modifiers can only be attached to actual views, not directly to an if statement.
Reviewed how @ViewBuilder allows a custom SwiftUI view to accept and display child views passed from outside.
Understood that .offset(y:) moves a view from its original position to fine-tune layouts.

🔐 TryHackMe Learning

AI Forensics Task 3 — AI & DFIR

Learned how AI and machine learning are transforming modern DFIR investigations.
Studied how CNN models can detect image tampering and manipulated content.
Learned how machine learning is used in dynamic malware analysis.
Understood that API call sequences represent program behavior patterns.
Studied how API sequences can be converted into 2D images for AI analysis.
Learned why CNN-based image recognition models can classify malware behavior.
Learned how NLP models help identify phishing emails and suspicious communications.
Understood how AI can reconstruct incident timelines from fragmented evidence.
Studied how AI accelerates forensic analysis and improves detection capabilities.
Understood that AI enhances human investigators rather than replacing them.
Learned the importance of combining AI-assisted analysis with human expertise in cybersecurity.

AI Forensics Task 4 — AI Legal & Ethical Implications

Learned that AI in forensics must be explainable and defensible in court.
Understood how “black box” AI models can weaken the credibility of digital evidence.
Learned that biased AI systems can lead to real-world injustice and wrongful accusations.
Studied the importance of maintaining chain of custody and audit trails when using AI in DFIR.
Understood why undocumented AI processing can make forensic evidence legally challengeable.
Learned that privacy and legal compliance are critical when handling sensitive evidence with AI tools.
Studied how Federated Learning and offline AI environments help preserve privacy.
Learned that AI should enhance human investigators, not replace human judgment and responsibility.

AI Forensics Task 5 — Practical: The Digital Trail

Learned how AI and machine learning can support DFIR investigations by identifying suspicious logs and files.
Studied how attackers use reverse shells to gain and maintain remote access to compromised systems.
Learned how hidden files, /tmp, and /dev/shm are commonly abused for stealth and persistence.
Understood how attackers disguise malicious tools as legitimate system utilities to evade detection.
Studied how SSH key abuse and authorized_keys modification can enable stealthy privilege escalation.
Learned how fake telemetry logs and masquerading techniques help attackers blend into normal environments.
Understood how compressed and Base64-encoded archives can be staged for data exfiltration.
Learned how DFIR investigations connect evidence from logs, bash history, suspicious files, and network activity.
Studied how AI can misclassify legitimate files as suspicious, highlighting the importance of human validation.
Learned that AI enhances investigations, but human reasoning and contextual analysis remain essential in DFIR.

🚀 Next Week

Complete the badge algorithm in the SwiftUI tutorial.
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-W04

Umitomo — Sat, 09 May 2026 05:36:45 +0000

🗓️ This Week

I had a long holiday during Golden Week in Japan and really enjoyed the break!
Because of that, I didn't have as much learning time compared to last week 😂
I made a little more progress in the SwiftUI tutorial
It was my first time using GitHub Copilot in Xcode, and I tried using the chat feature to generate unit tests. I'd also like to gradually explore more advanced features such as custom instructions.

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

Since English is not my native language, I was honestly a bit nervous about posting in English at first. But interacting with people on this platform has been a really valuable learning experience for me.

The kind comments and discussions gave me more confidence to continue sharing my learning journey here. Thank you so much😊

📱 iOS (SwiftUI)

Worked through the Swift tutorial and completed Section 5: "Create an Algorithm for Badges"
Used GitHub Copilot in Xcode to generate unit tests for badge sorting logic.

🌐 Web Development

Posted my weekly dev log on Dev.to 📝

🔐 Security (TryHackMe)

Worked on the AI Forensics room (part of the AI Security Learning Path) on TryHackMe

💡 Key Takeaways

Reviewed the basics of building SwiftUI views using NavigationStack, ScrollView, and HStack
Learned how to integrate AI-assisted code generation into the testing workflow.

TryHackMe Learning

AI Forensics

Learned how AI/ML enhances DFIR through large-scale data processing, anomaly detection, and scalable analysis
Explored practical AI use cases in DFIR tools, including phishing detection, malware classification, alert prioritisation, and event correlation
Learned the difference between deterministic systems and probabilistic AI models, and why non-determinism can become a challenge in digital forensics
Studied key AI evaluation metrics such as accuracy, precision, and recall, and learned why these metrics can be misleading when viewed in isolation
Understood the “Garbage In, Garbage Out (GIGO)” principle and how low-quality training data can lead to unreliable AI outputs
Learned that AI can accelerate DFIR workflows, but human oversight and validation are still essential in forensic investigations

🚀 Next Week

Continue working on the badge algorithm (Section 6) in the SwiftUI tutorial
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)

Keep learning cybersecurity on TryHackMe

Weekly Dev Log 2026-W03

Umitomo — Tue, 28 Apr 2026 06:21:07 +0000

🗓️ This Week

Finally finished the Cyber Security 101 learning path and discovered the AI Security Learning Path on TryHackMe
Completed 2 rooms from the AI Security Learning Path this week
Decided to continue working on the SwiftUI tutorial (also explored React Native with Expo out of curiosity)

📱 iOS (SwiftUI)

Ran unit tests for badge unlocking logic and stepped through them using breakpoints
Researched the differences between SwiftUI and React Native (with Expo) to determine the best platform for my learning

🌐 Web Development

Posted my weekly learning and development log on Dev.to📝

🔐 Security (TryHackMe)

Completed 2 rooms from the AI Security Learning Path on TryHackMe (AI Models & Data, Prompt Engineering)

💡 Key Takeaways

Learned how to use the po command and the map function in the console during debugging
Chose SwiftUI to focus on native iOS development (compared to React Native with Expo)

TryHackMe Learning

AI Models & Data

Learned that most AI models rely heavily on Common Crawl, a large public dataset collected from the internet
Realized that unclear data provenance and hidden sensitive data can lead to security risks
Learned that training decisions can impact security, including potential data leakage
Understood that optimization techniques introduce trade-offs between efficiency and security
Learned that fine-tuning inherits risks from base models such as bias and unsafe behavior
Realized that models are black boxes and difficult to fully audit
Learned that model cards are important but often incomplete

Prompt Engineering

Learned that LLMs process text as tokens and generate probabilistic outputs
Learned how parameters like temperature and top-p affect responses
Learned that effective prompts require clear instructions, context, format, and constraints
Understood the difference between system prompts and user prompts
Practiced prompt techniques such as zero-shot, few-shot, and Chain-of-Thought

🚀 Next Week

Continue working on the badge algorithm (Section 5) in the SwiftUI tutorial
Continue posting small articles on Dev.to
Continue working on the AI security Learning Path