During development, you may want to run a local server on your Mac and verify behavior from a mobile device.

If you start the server bound to 0.0.0.0, you can reach it from the same LAN using a private IP address (192.168.0.0/16). However, depending on security settings, only localhost may be allowed and private IP access may be blocked.

In that case, establish SSH port forwarding between the iOS device and your Mac so that the iOS device can access the Mac’s local environment using the localhost address directly.

Connection steps

1. Enable “Remote Login” in macOS Sharing

Open System Settings, go to Sharing, and turn on “Remote Login”. This allows connecting to the Mac over SSH.

2. Install WebSSH (SSH client) on iOS

Install WebSSH from the App Store. With its VPN-Over-SSH feature, other apps like Chrome and Safari can keep using the port‑forwarding setup.

3. Configure port forwarding

Launch WebSSH and configure as follows.

1. Enter the information confirmed in macOS Sharing:
   • Hostname
   • Username
   • Password
   • Private IP address
2. Port Forwarding settings
   • Example: if your Mac uses localhost:3000, enter 3000:localhost:3000.
3. Enable VPN-Over-SSH
   • This keeps the SSH tunnel active while using other apps.

4. Verify port forwarding

Once configured, open WebSSH on the iOS device and check that the port‑forwarding settings are applied.

Lately I’ve been improving my personal site a little every day, and it’s getting better. Here are some thoughts on having a personal site.

Why a personal site?

You fully control the content and design.

I also post on note, but the narrow text column makes code hard to read.

For tech posts I could use Qiita or Zenn and probably get more views, but those aren’t great for non‑tech posts.

I want a place that holds both tech and non‑tech posts—a site that conveys who I am. A personal site fits that.

How to build one

There are many options: no‑code tools like WordPress, Wix, and STUDIO are convenient for many people.

But hand‑crafting your site is also a good option. With a static site generator it’s quite simple.

Static site generators

Popular ones include Astro, Hugo, and Jekyll.

This site uses Next.js’s static generation.

Templates can get you a decent design quickly, and if you want to customize, you can change anything at the source level.

Static sites are also cost‑effective. This one is on Cloudflare Pages, and aside from the domain (~1,000 JPY/year), it costs essentially nothing to run.

Of course the barrier to entry is higher, and features you’d get via a WordPress plugin may require custom development.

But if you enjoy the act of building, I highly recommend it.

There’s a saying, “make haste slowly,” favored by Augustus more than 2,000 years ago.

The fact it survived to the present suggests people in any era often fail by rushing.

Japanese proverbs like “haste makes waste” carry a similar message, but “make haste slowly” adds that haste itself is also important—not just going slow. That nuance is why I like it.

In development it may be useful, too. Go too fast or too slow and you fail.

“Slow” in programming might mean:

• Writing readable code
• Writing unit tests
• Refactoring
• Maintaining documentation
• Introducing CI/CD

“Haste” might mean:

• Releasing early
• Getting user feedback early
• Implementing only what’s necessary
• Avoiding unnecessary abstraction

Both code quality and release speed matter—that’s “make haste slowly.”

Without some pressure I tend to lean “slow,” but under time pressure I sometimes go too fast and ignore quality.

When short on time, go “slow.” When time allows, “make haste.” I want to keep this balance in mind.

I’ve long felt that one ingredient for making something good is a mindset that truly accepts the significant time it takes.

Knowledge and skill matter, of course. But whether you genuinely accept the long hours may be a bigger factor than we realize.

Years ago I watched the video below and was shocked: the creator draws mazes for half a year and then burns them at the end. It’s a battle of endurance, and I came to think that such endurance is essential for making things.

In the end, making meaningful things often comes down to patience and stamina.

I decided to go freelance even though I didn’t have concrete projects lined up at resignation time. I wasn’t sure it would work out, but I quit thinking, “It’ll work out somehow.”

After that, people I met at conferences and former colleagues introduced me to projects, and I started freelancing smoothly.

Most of my work has come through acquaintances or people I met through work. To freelance, it seems important to first build relationships by spending time inside a company.

As a freelancer I took a “I’ll do anything” stance and got to touch many kinds of projects, for example:

• Mobile app development with React Native
• Mobile app development with Flutter
• Rails backend development
• API development in Python
• Backend APIs in Go
• Website development with Next.js
• AWS infrastructure with Terraform
• Machine learning / AI features

Early on I also did advisory/assessment work, but I find writing code myself more fun and impactful, so I’ve shifted away from purely advisory roles.

Unlike being an employee, nearly all of my working hours as a freelancer are programming, which suits me well.

While freelancing has gone better than expected, my original goal—personal projects—has often been pushed aside.

I planned to work three days a week on client work and spend four days on my own development, but I sometimes found myself effectively working seven days a week. That’s my big reflection over the past two years.

First, when schedules get tight, I tend to increase my hours out of a sense of service. Second, personal products may or may not make money, and even if they do, that’s in the future—so paid work naturally takes priority.

My software side projects often stalled and I lacked strong ideas, so recently I’ve focused more on hardware, aiming to build a mini‑robot.

Shirokuma Make

プログラミング、電子工作、3Dプリンターなどを用いて、オリジナルのプロダクトを作っています。

I’ve also been involved in the MIA project since last year, working on a hardware product there too.

ミーア / Mia

おしゃべりAIペットロボット「ミーア」は、100以上の種類の豊かな表情で、全国47の方言（大阪弁・博多弁・京都弁・沖縄弁など）を話します。毎日の中に、ちょっとした幸せと便利を。誕生日や記念日のプレゼントにピッタリです

Going forward I plan to work as a software engineer who can also do hardware development.

I used to enjoy programming for its own sake and wasn’t very interested in building actual apps or services. That changed after I joined an internal hackathon.

At Yahoo there was an annual Internal Hack Day—an in‑house hackathon where employees formed teams, built whatever they wanted over two days, and presented. I joined every year until I left. I even joked in team meetings that the most important part of my job at Yahoo was “participating in hackathons.”

For me, programming had been either a solo activity or a large‑team endeavor. Hackathons are different: you form a small team and build your own idea, which was a new kind of fun.

On my third try I had great teammates and we built a similar‑image search service called “I want to go to the Uyuni Salt Flats,” which won a prize. It suggested nearby sightseeing spots that looked like famous overseas locations. The system performed better than expected, and the effort was later featured on Yahoo’s tech blog.

ヤフーの社内ハッカソン「Internal Hack Day」を紹介します

12年の歴史をもつヤフーのクリエイター文化を語るには欠かせない社内ハッカソン「Internal Hack Day」について紹介します。

After the hackathon we wanted to keep building together, so we applied to SoftBank Group’s in‑house new‑business program “SoftBank InnoVenture”, were seconded there, and took on a new product challenge.

At InnoVenture we built an exercise service called “BAKOON!”.

It was a live‑streaming app for exercising with idols, with motion‑capture for visualizing activity and stamps for communication.

BAKOON! used React Native and Firebase; our technical approach is covered in this book:

React Nativeに支えられる企業：React Native Japan

2017 年 10 月に 「 React Native as a Service 」 という本を技術書典では出させていただきました。その第二弾となります！！ 本書は、実際に使われている企業様にインタビューを行い、React Nativeがどのようにつかわれているのか？ なぜ選んだのか？　どのようなライブリを使っているか？ などを書き上げた、実践的な事例集となっています。そのため、綺麗な話だけではなく、現実に即した知見を得ることができるため、React Nativeを使ったサービスを作ろうとしている、あるいはすでに運用をしている方のお役に立てるかと思います。是非とも我々がお役に立つことができ、ともにReact Nativeを盛り上げていけることを願っています。

Before this I hadn’t built a serious mobile app, nor much web frontend. I learned the basics as I went and somehow shipped.

We discussed product direction including engineering, and also designed the KPIs on the marketing and business side. It wasn’t just programming—I learned to think about the entire product. Marketing and business were more data‑analytical than I expected, and I felt I could leverage my math background.

We operated for about a year after launch and worked hard, but ultimately shut the service down. Still, the 0→1 experience changed what I wanted from programming. Rather than programming itself, I enjoyed deciding on an idea and building it into a product.

That gave me a new goal: build my own products. To secure development time, I decided to go independent as a freelancer.

When I joined Yahoo as a new grad, there was a large data‑science division, so I assumed I’d be assigned there based on my interviews. Instead I landed on the search team for Yahoo Shopping. It wasn’t my first choice, but in hindsight working on a real service was valuable.

My main work was adding features to the search API and operating the search engine. The codebase was large and mature, so I started by reading and understanding it.

Some software‑design ideas I’d read about hadn’t clicked before, but looking at a real, complex system made them concrete.

I was also impressed by the performance of in‑house tech compared to popular OSS. For example, the now‑open‑sourced full‑text engine Vespa and the NoSQL store mdbm were very fast. I’d assumed the most popular OSS was best, but the internal tools were often superior.

Teams owned APIs and subsystems, so feature work required cross‑team coordination. These days I usually work in 2–3 person teams with little coordination overhead, but back then I often visited other teams when launching a new feature or sunsetting an API. That kind of organizational collaboration is an important part of being a professional developer.

Doing both development and operations was another key experience. If you split them, priorities can get tossed back and forth; owning both helps balance trade‑offs.

One memorable recurring event was preparing for the annual sale day: forecasting traffic, adjusting server counts, and running load tests—things you only do at large scale. I don’t do that much now on smaller services, but I suspect it’ll come in handy again someday.

After joining the company I switched from Emacs/Vim to IntelliJ IDEA. At work I needed to handle many languages—PHP, Perl, Java, Go, Python—so I preferred an IDE with broad support and minimal setup.

Outside work I was into high‑performance systems, learning C++ and efficient programming. I even wrote toy languages and interpreters on the side, hoping to use C++ in a future project. I didn’t use C++ at work then, but now I’m using it heavily for firmware, and that learning has paid off.

I first tried programming in high school around 2008. I had my own desktop computer and installed Ubuntu to tinker with it. Controlling the machine from the shell felt fresh and fun.

Working via the shell makes automation easy, and I thought mastering Linux commands would let me truly use a computer well. My “programming” began with simple shell scripts strung together.

Later I wanted to learn real programming beyond shell scripts. The internet said “learn C first,” so I bought a beginner‑friendly C book titled “Shirouto Kuma‑kun’s C Class” (Japanese).

しろうとクマくんとＣ言語の授業

本の通販なら紀伊國屋書店ウェブストア、電子書籍ストアKinoppy！店舗受取で送料無料。図書カードNEXTも使える。紀伊國屋ポイントが貯まる・使える。コミックや雑誌も豊富な品揃え。国内・海外主要都市に店舗を展開する紀伊國屋書店のECサイト。

I “felt like I got it,” but looking back I probably would’ve struggled even with FizzBuzz.

Next I picked up a Windows game‑programming book.

１４歳からはじめるＣ言語わくわくゲームプログラミング教室Ｖｉｓｕａｌ　Ｓｔｕｄｉｏ　２００８編―Ｗｉｎｄｏｗｓ　ＸＰ／Ｖｉｓｔａ対応

プログラミング言語の王様「Ｃ」を無料の「ビジュアルスタジオ」ですぐにはじめよう。

I wrote a simple side‑scrolling action game in C, mostly by copying from the book. It ran, but I can’t say I truly understood it.

Heading into university, I was torn between studying information science or electrical/electronic engineering. I ended up at the University of Electro‑Communications in the Information and Communication Engineering course, where I could learn both.

In my first year there was a C programming class. I had forgotten much of what I learned in high school, so I started over. There were students who finished assignments incredibly fast—it was eye‑opening. Also, Emacs was required for programming in class, and I became a keen Emacs user.

I wanted to get better and started learning Python. It’s the most popular language now, but back then it wasn’t common in Japan. That rarity actually attracted me.

I remember reading “Minna no Python” as my first Python book and finally being able to write something practical.

みんなのＰｙｔｈｏｎ （改訂版）

最新バージョン「３．０」を含め、スクリプト言語Ｐｙｔｈｏｎの“今”を徹底解説。

During undergrad I didn’t work part‑time or hang out much; I mostly stayed home coding. Living alone, I sometimes wouldn’t see anyone for days and wondered if I was okay with my future.

After getting comfortable with Python, I wanted low‑level knowledge and read books in that area. One that stuck with me was “Hacking: The Art of Exploitation.” Although it’s mainly about security, it finally made C click for me.

Ｈａｃｋｉｎｇ：美しき策謀―脆弱性攻撃の理論と実際 （第２版）

ハッカーの視点に立ち、攻撃手法を詳しく分析。防御方法の本質が理解できる究極のセキュリティガイド。ベストセラー待望の改訂版。

I also studied assembly language.

アセンブリ言語の教科書

アセンブリ言語とは、コンピュータと密接に関わっているプログラミング言語です。本書では、そのアセンブリ言語をサンプルプログラムを例にとりながら丁寧に解説していきます。

I read many other books, but I wasn’t interested in application development at the time, so not many were practical.

I also didn’t plan to get a programming job—coding was just a hobby—so practicality wasn’t top of mind.

In my fourth year I joined a Brain‑Computer Interface (BCI) lab and mainly programmed with MATLAB and Octave. For experiments using visually evoked potentials, I wrote programs to present visual stimuli on a PC with PsychoToolbox.

Python was my strongest language then, so I pushed to build experimental apps in Python. I controlled the EEG device’s DLL via ctypes, and a mistake could blue‑screen the PC—rough times.

Eventually the experiment app settled on MATLAB, and I used Python for analysis and visualization.

Around then, machine learning was gaining attention. I learned with scikit‑learn and, in a seminar, worked through Bishop’s yellow book “Pattern Recognition and Machine Learning.”

パターン認識と機械学習 上 - 丸善出版 理工・医学・人文社会科学の専門書出版社

機械学習とパターン認識の理論や手法を解説 元田　浩 監訳

Later I studied data analysis with pandas, which I still use now and then.

Pythonによるデータ分析入門 第2版

NumPy、SciPy、pandas、Matplotlib、Jupyterをはじめ、高機能で使いやすい数学・科学計算用ライブラリが充実しているPythonは、科学計算、統計解析、機械学習のみならず、金融や経済分野でも広く利用されています。本書はPythonの代表的なデータ分析ツール、pandasの開発者Wes McKinneyによる、データ分析を行うための基本を網羅しています。すべてのサンプルコードはダウンロード可能で、Jupyter Notebookで対話的に試し、実際に手を動かしながら知識を確実なものにすることが可能です。Python 3に対応した待望の改訂版です。

In my first year of the master’s program, I started programming as a job through part‑time work and internships—improving search and building ranking models. Large language models didn’t exist yet, so it was fun trying various feature‑engineering ideas to move metrics.

Doing near‑production work made me realize I’d accumulated a decent skill set.

My research was going okay too, and I enjoyed the deep‑dive nature of research, so I considered a PhD. But internships were very close to real‑world development, and I felt I’d enjoy it as a job.

And that’s how I ended up becoming a professional programmer.