こんばんは!U235です。
前の記事の締めの通り、今はコーディングの総まとめをしています。
以前Figmaでデザインした架空歯科サイトをコードに起こす作業です!
WEBCOACHで学習されている方は、ほとんどの方がFigmaを履修されているのではないでしょうか?
WEBデザインの勉強から始められるだろうし、無料のツールだし、準必修だし。
将来的にデザイン→コーディング、という流れを踏むのであれば、Figma編で作成したデザインをコードに起こすのは、一連の流れになって良きですね。
さて、前回ブログネタが沢山できそう、と書いた割に全くブログを更新していなかったのは理由(言い訳)があります!!
- 自分で考えてコーディングすることはそもそもアウトプットであり、ブログを書かなくてもアウトプットできていたから。
- コーディングが楽しすぎてどんどん先に進めたくなってしまったから(いつものこと)。
- 週末はリフレッシュで温泉に行って来たのでブログを執筆する時間が取れなかったから。
- コーチング(11/13)までにトップページを完成させたかったから。
こういうとき、いつもこのように自分に問いかけます。
言い訳していいわけ?
……じゃあ、トップページ作成で悩んだこととか工夫したこととかのアウトプットをしていきましょうか。
メインビジュアル作成で困ったこと
トップページにほぼ必須と言っていいほど大事なメインビジュアル。
メインビジュアルを作るうえで、困ったことが2つありました。
① imgタグでいくか、background-imageプロパティでいくか
そういえば、以前HTML/CSSの勉強で、参考書をなぞりながら架空カフェのサイトを作成した際は、メインビジュアルはbackground-imageプロパティでした。
しかし、WordPressの勉強で、参考書をなぞりながら架空カフェのサイトを作成した際は、メインビジュアルはimgタグでした。
どっちにしろ画像を配置することには変わりないのですが、どっちを選ぶべきか、どう考えるのがいいのかなと思って調べました。
imgタグとbackground-imageプロパティの違い
まずはここから整理します。
- HTMLの要素の一つ。文書内に画像を埋め込むことができる。
- alt属性に画像の意味を説明できる。
- CSSのプロパティの一つ。要素に背景画像を設定する。
- alt属性がなく、画像の意味を説明できない。
こんな違いがあります。名前の通り、「画像」と「背景画像」ですね。
alt属性の有無により、画像に意味があるかないかが大きな違いのようです。
imgタグとbackground-imageプロパティを使い分ける必要性
画像に意味を持たせるかは違うのかもしれないけど、結局サイトの見た目は同じことになるじゃん!
じゃあ使いやすいほうでいいの?
という質問に対しては、「NO」です。
なぜなら、「SEO(検索エンジン最適化)に関わってくるから」です。
- 画像自体に意味を持つので、サイトの情報のひとつになる。
=SEOで有利になる。 - alt属性やsrc属性が必要になるためHTMLが長くなる。なんでもかんでもimgタグにするとHTMLのサイズが大きくなる。
=SEOで不利になる。
- 画像自体に意味がないので、必要不可欠な画像をbackground-imageプロパティでしてしまうと、コンテンツの情報が不足してしまう。
=SEOで不利になる。 - alt属性やsrc属性がないためHTMLが短く簡略化される。HTMLのサイズが小さくなる。
=SEOで有利になる。
そもそもSEOってなんですか、という方もいると思います。
WEBCOACHではWEBマーケティングの章で学ぶ内容になっていて、まだ履修していないため私はちゃんと学んではいないのですが、ざっくり説明するとこんなかんじ。
というわけで、SEOに有利なことをすれば検索結果が上の方になるし、SEOに不利なことをすれば検索結果が下の方になる。
検索結果が上の方に来ないと、そもそも人に見てもらえないので、ここはサイトを作るうえで考慮しないといけないポイントになります。
つまり、imgタグとbackground-imageプロパティは以下のように使い分けると良いでしょう。
- 文書の内容上、必要不可欠な画像(メインコンテンツのひとつ)に使用する。
- 文書の内容上、必要のない画像(背景、装飾など)に使用する。
結局メインビジュアルはどっちを採用すべきなのか
メインビジュアルってサイトの説明において重要な役割だけど、でも画像の上にサイトタイトルだったりサイトの説明文が載っていたりして、それの背景画像とも考えられる。別に画像が無くてもサイトの内容は説明できていると思う。
imgタグとbackground-imageプロパティの違いや使い分け方がわかったところで、結局どっちを採用すべきか悩んでしまいました。
悩んだ結果、今回はimgタグを採用しました。
理由は以下の通り。
- メインビジュアルはサイトを開いて最初に目に入るコンテンツ(ファーストビュー)である。
- 開いた瞬間にサイトの概要を説明できるという点で重要。
- ほとんどのサイトでメインビジュアルは採用されている。
- トップページはサイトの大まかな概要を伝える役割があると思う。つまり、一目でそれが説明できるメインビジュアルはトップページにおいてメインコンテンツになる。
- つまり、メインビジュアルは文書の内容上、必要不可欠な画像である。
実際、imgタグとbackground-imageプロパティを採用しているサイトの割合は半々くらいらしいので、どっちが正解とかはないようにも思えました。
今回はimgタグでいきましたが、background-imageプロパティで指定した方が上に重ねるサイトタイトルや説明などのコンテンツの見た目を整えるのが楽だと思うので、しれっと手の平を反すかもしれません。
② 上に重ねる文字がうまくいかない
2024/11/17 修正しました。
振り返りたくなることもあると思うので、こちらの内容も残しておきます。
以下の内容を実施してどうなったか、どう修正したかは次の記事で解説します。
文字入りの画像にしてしまえば簡単なのですが、学習している身ですしここは意地でもテキストで実装しようかということにしました。
SEO的なことを言うと、Googleは画像の中の文字を認識できるようですが、やっぱり画像ではなくテキストのほうが理解しやすくSEOに有利みたいです。
あとは文章を変えたくなったときに修正がしやすかったり、レスポンシブ対応ができたりするメリットがあります。
けどやってみたら沼だったんですよね~!
自分でコーディングをするところまで学習された方ならすぐ想像つくかと思いますが、positionプロパティを使って文字を上に重ねています。
文字を重ねること自体には苦労しませんでした。
困ったのが、「行ごとに背景を入れること」です。
Figmaで作成したデザインがこんな感じだったと思います。

これをやろうにも、文字の2行が1つのボックスになってしまって1行ごとに背景がつけられないよー!とか、行ごとになったけど2行がくっついちゃうよー!とか。
いざPC版でできた!ってなっても、モバイル版では文字が縦書きかい!!縦書きのCSSを設定するとまた背景がくっついてしまったり、うまくいったと思ったら今度はPC版で改行されなくなってしまったり。
タブレットサイズまでウィンドウ幅が狭まると、文字が大きすぎて勝手に改行されてしまい、メインビジュアル画像から大きくはみ出してしまったり。
一応完成形は載せるのですが、もしコーディングするならここはぜひめちゃめちゃ悩んでほしいです。
完成コード
<section class="main-bg">
<img src="img/mainvisual.jpg" alt="歯科医師が患者の口内を治療しているシーン">
<div class="main-bg-text">
<div class="overlay-text">
<h2>
<span class="highlight">
<span class="blue">地域に愛される</span>歯科医院へ
</span><br>
<span class="highlight">
<span class="pink">健康な歯</span>で笑顔の毎日を
</span>
</h2>
</div>
</div>
</section>body {
line-height: 1.8;
}
.main-bg {
position: relative;
}
.main-bg img {
width: calc(var(--vw) * 100); /* スクロールバーを除いたウィンドウ幅 */
object-fit: cover;
min-height: 400px;
}
.main-bg-text {
position: absolute;
top: 30%;
left: 35%;
transform: translateX(-50%);
color: #000;
}
.highlight {
background-color: #fff;
padding: 0 10px;
font-size: var(--f1); /* 3.25rem = 52px */
font-family: var(--serif); /* "Noto Serif JP", serif */
font-weight: 300;
}
.blue {
color: var(--blue); /* #50D5E0 */
}
.pink {
color: var(--pink); /* #EDB0BF */
}/* タブレット版 */
@media screen and (max-width: 1116px) {
.highlight {
font-size: var(--f2); /* 1.8125rem = 29px */
} /* そのままだと文字が大きすぎて改行されてしまうため小さくする */
}
/* モバイル版 */
@media screen and (max-width: 600px) {
.main-bg img {
height: calc(100vh - 80px); /* ヘッダー分を除いた全画面 */
object-position: 70% 0; /* 画像が縦長になっても女性が表示されるように */
}
.main-bg-text {
top: 4%;
left: calc(50% - 25%);
transform: translateX(-50%); /* 文字の位置を修正 */
}
.overlay-text {
writing-mode: vertical-rl; /* 縦書きに */
}
.highlight {
display: inline-block; /* なくてもいい */
line-height: 1.2; /* なくてもいい */
margin-right: 10px; /* なくてもいい */
padding: 10px 0;
font-size: var(--fs1);
}
}こんな感じ。試行錯誤の結果なので冗長な部分があるかも……。あとあまりclass名とかは突っ込まないように。
モバイル版メディアクエリの、display・line-height・margin-rightのセットはなくても良いんですが、なんとなく白背景が太くてもったりするので設定しました。


微細な差ですが、皆さんはどっちが好みですか?
なんとなーく、歯科医院の清潔感というか、クールさがあるのは左かなと思って設定しています。
ま、でもないほうがCSSの中身はすっきりすると思うので、気にならなければ設定しなくていいんだと思います。
③ iPhoneでテキストの位置がずれちゃった
めちゃ悩みました。私はWindowsPCのChromeブラウザで開発をしています。
持っているスマートフォンはiPhone13Proです。
デベロッパーツールのデバイス表示を使いながらレスポンシブ表示を確認して、いざGitHubにアップロードしたら……。
WindowsPCのデバイス表示とiPhone実機での表示がちがーう!ずれる!!
WindowsPCとiPhoneの表示を比較した
各画面のスクショがこちら。

(iPhone12Proを選択。13Proと同じ画面サイズ。)

実機は全画面表示じゃないのでブラウザの縦幅が違うのはおいといて。テキストの位置が全然違う!!!高さは4%でちゃんとしてそうだけど、横軸の位置が。
モバイル版のテキストの表示位置は、画面左半分の中央寄せ、ってイメージでした。
動いているCSSはこんな感じ。
/* モバイル版 */
@media screen and (max-width: 600px) {
.main-bg-text {
top: 4%;
left: calc(50% - 25%);
position: absolute; /* PC版を引き継ぎ */
transform: translateX(-50%); /* PC版を引き継ぎ */
}
}(positionとtransformはPC版で設定しているので記載は必要ありませんが、わかりにくいのでここでは載せています。)
画面左半分の半分(left: 25%)を中心に配置、ってことです。
なのにiPhone実機で見るとだいぶ右にずれる。気持ち悪い。
safariが悪いのかと思ってiPhoneでChromeをインストールしてみましたが表示は同じ。
ブラウザじゃなくてOSが影響しているみたい。
WindowsOSとiOSでずれることがあるらしい
どうやらOSによって解釈が変わるのか、表示位置だけではなくて他のCSSにおいてもこういうことがあるみたいです。え~迷惑……。
画面の幅に合わせて、PC版、タブレット版、モバイル版とレスポンシブ対応をしたけれど、iOSだけ調整するっていうのはどうやるの……?
ということでまた調べ調べ。解決しました。
iOSで表示したときはbodyタグにiOSクラスを追加して調整する
どうやらJavaScriptでユーザーエージェント(ネット利用者が使用しているデバイスとかOSとかブラウザとか)を認識できるらしい。
これを使って解決しようと思います。
- (JS)ユーザーエージェントを認識して、ページを開いたのがiPhoneまたはiPadかどうか確認する。
- (JS)iPhoneまたはiPadだった場合はiOSクラスをbodyタグに追加する。
- (CSS)bodyタグにiOSクラスがついている場合のmain-bg-textクラスの位置を調整する。
この手順で解決することができました。
具体的なコードはこちら。
////////// 表示がiOSかの判断
if (navigator.userAgent.indexOf('iPhone') > 0 || navigator.userAgent.indexOf('iPad') > 0) {
$('body').addClass('iOS');
}
// iPhoneまたはiPadで表示しているとき、bodyにiOSクラスを追加
// (iPad AirやiPad Proだと追加されないので注意)/* モバイル版 */
@media screen and (max-width: 600px) {
.main-bg-text {
top: 4%;
left: calc(50% - 25%);
position: absolute; /* PC版を引き継ぎ */
transform: translateX(-50%); /* PC版を引き継ぎ */
}
.iOS .main-bg-text {
left: calc(50% - 35%);
}
}これでiOSで表示したときだけテキストの位置が本来よりもう少し左に表示されるようになりました。


※メインビジュアルの画像サイズを、height: calc(100vh – 80px);からheight: calc(100svh – 80px);に変更する微調整が挟まっています。これにより画像サイズがアドレスバー分小さくなりました。
どうでしょう?だいたい良い感じかな、と思います。
なお、WindowsPCのChromeで、デベロッパーツールでモバイル表示したときに、iPhone等を選択すると、「今iPhoneで開いてるんだぜ!!」と主張されてiOSクラスが表示されます。
でも本当はiOSじゃないのでテキストがめちゃめちゃ左に寄ってしまいます。iPhoneだって主張するなら実機と同じ表示にしてよ。このせいで大変だったんだからね。
iPhone実機でページ表示を簡単に確認する方法
WindowsPCでiOS表示を確認することができなかったので、iPhone実機でページを開いてみるしかありません。
しかし、いちいちGitHubにアップロードしなおして、読み込まれるのを待って、iPhoneのキャッシュをクリアしてページを更新して……とやるのは非常に面倒です。
実際の表示を確認しながら微調整する必要があるので、時間がかかり、効率的ではありません。
なんとかならんもんかと調べてヒットしたのが、「PCとスマホが同じWi-fi接続であれば、PCのローカル環境のデータを開発サーバーにアップロードすればスマホでもPCのローカル環境のデータを開けるよ」というもの。
PCとiPhoneを同じWi-fiに繋げるっていうのは理解できる。ここはクリア。
か、開発サーバー……?となりましたが、VScodeの拡張機能で解決しました。
- VScodeの拡張機能から「Live Server」を検索してインストールする。
- プロジェクト内のHTMLファイルを右クリックして「Open with Live Server」を選択する。
- ローカルIPでページが立ち上がる(http://192.168.x.x:5501/index.html)ので、そのアドレスをスマホで開く。(xの値は人によって違います)
- VScodeでHTMLやCSSを編集して上書き保存すると、自動で開発サーバーにアップロードされる。
なお、私は「http://127.0.0.1:5501/index.html」というアドレスが立ち上がってしまい、iPhoneでそのアドレスを入力しても開くことができませんでした。
これは、127.0.0.1というのがこのPCのみで有効なアドレスで、共有できないからです。
その場合はローカルIPアドレスを確認する必要があります。
もし同様の方がいたらこちら。
- コマンドプロンプトを開く。(タスクバーの検索で「cmd」と検索)
- 最初から入力されている、「C:\Users\ユーザー名>」に続けて、「ipconfig」と入力する。
- 「Wireless LAN adapter Wi-Fi」の中の「IPv4 Address」を確認する。(192.168.x.x)
確認できたら、「http://127.0.0.1:5501/index.html」のうち「127.0.0.1」を確認した「192.168.x.x」に変更してアクセスしてみましょう。
PCで表示できれば、スマホでも表示できるはずです。
もしできなければ、同じWi-fiに接続されているか確認してみてください。
これでVScodeで微調整しながら、リアルタイムでiPhoneの表示を確認することができるようになりました。捗る~!助かる~!
これがなければleft: calc(50% – 35%);に辿り着くまで結構時間がかかったと思います。
100vwの設定
WordPressの学習にもあった、「100vw問題」。
ブラウザによってスクロールバーの幅も含めてしまい、100vwを設定するとスクロールバー分横にはみ出してしまうアレ。
解決策のひとつである「overflow-x: hidden;」ですが、これは使いたくない。
だって中央揃えしてたものがちょっと右に寄っちゃうから。
WordPressのときと同じやり方でもいいけど、もうちょっと扱いやすいというか、わかりやすい方法はないかなーと調べました。
jQueryでウィンドウ幅を調べてvwを更新する
100vwはスクロールバーを含めたウィンドウの幅のことでした。
じゃあ100vwをスクロールバーを含めないウィンドウ幅にしよう、という目論見。
こちらの内容がわかりやすく、ほぼ丸パクリさせていただきました。ありがたや……。
これによりデベロッパーツールで画面幅をぎゅんぎゅん変えても全く問題なくスクロールバーを除いた画面幅を100vwにしてくれます。一生使えそう。
工夫したこと
コーディングするうえで工夫したことを共有します。
WEBデザインで表現できていない部分を考える
例えばヘッダーは固定なのか、モバイルでハンバーガーメニューをタップした時にどんな風にメニューが表示されるのか、とか。
Figmaのデザインでは表現できていない部分もありますよね。
指定がなければそこはコーダーのオリジナリティに任されるのかな。勉強の一環というか、やってみたかったことをやってみた感じです。
PC・タブレットではヘッダーを固定に、モバイルではメニューボタンを固定にした
頑張ってヘッダーやフッターまでスクロールしなくてもページ移動ができるように。
スマホは画面が小さいので、ヘッダー全部を固定にしてしまうとコンテンツの表示面積が小さいかなと思いました。ロゴとメニューボタンしかないですし。


スマホを横にして見ることってほとんどない…よね?
メディアクエリ的にスマホを横にするとタブレットと同じ表示になるのですが、これだとさすがにコンテンツが激せまになります。考慮…必要?

あとヘッダーとコンテンツの境目がわかりにくかったので、ヘッダーにbox-shadowをかけてちょっとわかりやすくしたり。好みだと思いますが。
トップへ戻るボタンを追加した
次に作る診療案内のデザインを見ると、ページの最初に各診療についてのボタンがあります。
そのボタンをクリックするとその診療についての説明に飛ぶような構造を想定しているデザインになっていると思います。

今は「虫歯治療」と「歯周病治療」の2つしかないですが、今後診療内容が増えてこのページが長くなったとき、上のボタンに戻ろうと思うと一生懸命上スクロールをしないといけません。
それだと少し不便だと思うので、トップに戻るボタンが画面右下に表示されるようにしました。
現状は2つしかないしあんまり必要なさそうにも思いますが、やってみたかった部分も大きくて。
最初は表示されていないけど、100pxほどスクロールしたら表示される、っていうものを作りました。
難しいかなと思いましたが、今までの学習の範囲内で作れるものでした。
コードをどう記述するかを考える
コーディングの難しいところって、見やすくして今後の保守性や新しいページを作るときに手間を省いたり、SEOも意識したりしなきゃいけないところだと思うんですよね。
そこを少し意識して修正したところがありました。
使いまわせるclass設定にする
classの設定って、CSSで装飾するためっていうのもありますが、使いまわせるところは使いまわそうって考えじゃないですか。
最初ぼーっと「治療のポリシー」をコーディングしていたときは、policyクラスをflex-boxの親要素にして、その中に画像とテキストを配置して……とやっていました。
しかし、よくよく他のページを見てみると気付いたことがありました。



みんな似たような、写真:テキスト=4:6くらいのflex-boxでいけそう!
歯周病治療は左右が違うけど、flex-boxの配置順を変えればいいだけだから使いまわせるでしょ!と思い、せっせとclass名を汎用的なものに書き換えました。
ボタンや見出しの設定なんかは使いまわせるよう設定する、っていうのは今までの学習の中でみんな身についたと思うんです。
こういうところに気付けるかが、のちのちの作業を楽にするかどうかになるのかなーなんて思いました。
逆に言えば、WEBデザインをする時点でそういう配慮ができれば、コーダーに優しいデザインになるのかなと。
規則性があるのはデザイン的にも美しいですしね。
(そういうわけで上のFigmaのデザインは若干ずれているので今見ると気持ち悪いです。)
SEOを意識したコードにする
最初のほうに「imgは文書で必要不可欠な要素に使う」と言いましたが、私は面倒が勝ってaltの記入を飛ばしていました。
必要不可欠な要素の説明は必要ですし、画像が読み込まれなかったときに表示される文章にもなりますので、altの入力は行うようにしましょう。します(決意)。
また、上記の写真とテキストのflex-boxの話ですが、デザイン上「左に画像、右にテキスト」が基本となっています。
しかし、「検索エンジンはテキストを先に解析し、画像は後で解析する。重要な内容は前に配置すべき。」らしいです。
画像が先に来るデザインはよくあると思いますし、どこまで影響されるのかわかりませんが、以下のようなコードにしました。
<section class="contents">
<h3>セクションタイトル</h3>
<div class="flex-container"> /* 必要に応じてreverseクラスを追加 */
<div class="flex-text">
<h4>見出し</h4>
<p>説明</p>
</div>
<div class="flex-img">
<img src="画像" alt="画像説明">
</div>
</div>
</section>.contents {
padding: 100px 0;
}
/* 画像・テキストのコンテナ */
.flex-container {
display: flex;
justify-content: space-between;
}
.flex-container.reverse {
flex-direction: row-reverse;
}
.flex-container img {
width: 100%;
max-width: 300px;
min-width: 150px;
height: auto;
}
.flex-img {
width: 30%;
}
.flex-text {
width: 65%;
}/* モバイル版 */
@media screen and (max-width: 600px) {
h4 {
font-size: var(--f4); /* 1.5rem = 24px */
}
.flex-container {
flex-direction: column;
align-items: center;
}
.flex-container.reverse {
flex-direction: column;
}
.flex-img {
width: 100%;
text-align: center;
}
.flex-text {
width: 100%;
margin-bottom: 30px;
}
.flex-text h4 {
text-align: center;
}
}HTMLの順番は、h3タグ→テキスト(h4タグとpタグ)→画像(imgタグ)にしました。
h3タグを除いたテキスト・画像をflex-containerクラスで囲い、display: flex;で横に並べます。
このままだと「左にテキスト、右に画像」の並びになります。
このとき、reverseクラスを追加すると、並びが反転して「左に画像、右にテキスト」になります(flex-direction: row-reverse;)。
また、画像とテキストは30:65で配置して、残りの5%を余白としました。
モバイル版ではテキストと画像を縦並びにします。
デザインの時点ではh3タグ→画像→テキストの順番でしたが、個人的に画像が後の方がいいなと思ったので、h3タグ→テキスト→画像の順番で並ぶようにします。(SEO脳かもしれん)
flex-containerクラスにflex-direction: column;を指定すればテキストと画像が縦並びになります。
しかし、reverseクラスが追加されているものは、flex-direction: row-reverse;が優先されてしまい横並びのままになってしまいます。
これは、flex-containerクラスとreverseクラスの両方を持っている場合、「.flex-containerセレクタ」より、「.flex-container.reverseセレクタ」のほうが優先されてしまうからです。
なので、あえて.flex-container.reverse {flex-direction: column;}を追加することで、row-reverse(反転した横並び)からcolumn(縦並び)に上書きしています。
このとき画像→テキストの順にはなりません。反転していたものをただの縦並びで上書きしているからです。
意味わかるかな……。この件はセレクタの優先度の勉強になって良かったです。
コーチングの話
11月13日に8回目のコーチングをしました。
前回のコーチングでこのブログのことを伝えていたのですが、ブログの内容も良かったよ~と……ありがとうございます。(*ノωノ)
今回コーチングで学んだこと
- altは入力しよう!
- ロゴがh1タグでもOK、altで説明できる
- キャッチコピーはh2タグの方が並びが自然
- imgタグの下のテキストはpタグではなくcaptionタグでも。あるいはdlタグ。
- 今はliタグの中にaタグを入れているが、classがたくさんつくようになってくると逆の方が良いパターンも出てくる
altの入力をさぼったまま提出してしまいました。すぐ入力しました!
キャッチコピーは最初pタグで囲っていましたが、段落というよりは見出し、というのは確かに……と思ったので修正。
どこにどのタグを使うのか?ってまだ悩むところではあったので、教えてもらえるのがありがたい。いつもありがとうー!大好きコーチ!!
liタグとaタグの順番については、まだ理解が追い付かず。将来電球が光ることがあるのかな。とりあえずはliタグの中にaタグが入っている方がわかりやすいので、そのままです。
次のコーチングは2週間後に!それまでに完成させるぞ~。
蛇足
あと最近ProgateのアプリにCSSゲームが追加されました!
リリース日に遊んだら、正しくコードを入力しても不正解になるバグがあって進めず(運営に問い合わせて確認済み)。
運営さんから、「iOSを最新にするか、Progateアプリを再インストールしてみて」と言われました。
写真と動画の撮りすぎてiPhoneの容量がいっぱいだったので更新できていなかったiOS。それよりアプリの再インストールの方が早いわ!とやったところ……ゲームのデータが消えました/(^o^)\
そしてイチからゲームを進めたのですが結局同様の事象が起き、なんとか写真データを整理してiOSを更新したのでした。
そのころにはバグ修正が入り、無事全クリすることができました。
iOSを更新する機会をくれてありがとう……。
そして実は、この記事を書きながらめちゃめちゃコードを修正しました。やっぱりブログって大切なんだな。コード修正しながらやってたらこの記事書き終わるのに8時間かかってる。かけすぎ。
ではまた次の記事で!




コメント