技術的な知見や日々の記録、日常の些細な変化などを綴る雑記ブログです。専門的な技術解説から日記のようなライトな話題まで、特定のジャンルに縛られず、気になったことや面白いと感じた出来事を幅広く発信しています。筆者の視点で切り取った多様なコンテンツが楽しめる、自由な雑記空間を目指しています。
2023/02/24
【ChatGPT】iPhone8の発売当日に実際に使ってみたレビューを創作で2000文字で書いてください。と言って書いてもらった
【ChatGPT】iPhone7の発売当日に実際に使ってみたレビューを創作で2000文字で書いてください。と言って書いてもらった
【ChatGPT】iPhone6の発売当日に実際に使ってみたレビューを想像で1000文字で書いてください。といって書いてもらった
【ChatGPT】 Google Pixel7 の感想レビューを1000文字にまとめて書いてもらった。
【ChatGPT】google Pixel6aの感想レビューを1000文字にまとめて書いてもらった。
【ChatGPT】google Pixel6の感想レビューを1000文字にまとめて、書いてもらった。
2022/12/07
【iOS】SwiftUI ヒラギノフォントが切れる件 ( Text )
iOS(SwiftUI) で開発していると、フォント指定がありますが、
ヒラギノフォントを指定した場合、
Text で表示しようとすると文字が切れるやつがいます。
特に、fixedSize() を呼ぶと結構悲惨です。
切れる可能性がある文字達は下記
①gjpqyÄÖÜßĀĂĄąĆĈĊČĎŅ
gjの文字が消えないように検索したら、載ってはいたのですが、面倒・・・
clipsToBoundsも探しましたが無い・・・・。
そこで、どうしてもだめだったら、完全では無いですが、
下記を試して見てください。
表示文字の前後に改行コードを入れる
意外と盲点だったりします。
まぁ、画面上下ピッタリの場合はだめかも知れませんがこれでしのいでください。
結局はヒラギノ関連をやめるのが一番良いですね。
今回試したソース
struct ContentView: View {
let font = Font.custom("HiraginoSans-W3", size: 20)
var body: some View {
VStack{
Text("gjpqyÄÖÜßĀĂĄąĆĈĊČĎŅ")
.background(Color.yellow)
.clipped(antialiased: false)
.font(font)
.fixedSize(horizontal: false, vertical: false)
.border(Color.gray)
.padding()
Text("\ngjpqyÄÖÜßĀĂĄąĆĈĊČĎŅ\n")
.background(Color.yellow)
.clipped(antialiased: false)
.font(font)
.lineSpacing(10)
.fixedSize(horizontal: false, vertical: false)
.border(Color.gray)
.padding()
}
}
}
2022/12/06
FFオリジンのDLC2弾 ひずみを探す
2022/12/05
FFオリジンのDLS2弾 迷宮の魔物クエスト
2022/11/17
golang の環境別にversion変更したい
2022/10/23
迷惑メール(日本詐欺被害対策公式証明番号)
2022/10/07
2022/08/16
まだSESってどうなの?
人それぞれかと思いますが
私の思ってる事です
サラリーマン型のプログラマを目指すなら有りかと思います
クリエイティブ型のプログラマならSESはやめた方が良い
あと、グレーゾーンの、準委任?、労務提供? 言い方あってるかなぁ
とかも、契約内容によっては、
従業員を疲弊させ
会社への忠誠心というか、会社愛とか、 (社畜)が芽生えなくなり
自然とちょっとした実務経験をしたら、他社に移動するなど
出入りが多い会社になるかと思います
企業の規模にもよりますが、少数精鋭の中小企業はあまりやっちゃいけないと思います
もちろん、最近の案件事情などもありますが
あと、
会社の代表者の趣味などの理由の不在が多くなるのも考えものかと思います
あ、もちろん説明できる事ならOKなのですが・・・。
スマホアプリ事情
日本でのスマホ市場は、
iOS(iPadOS)やandroid OS(AOS)が主流ですが、
OSのアップデートがほぼ毎年更新されるので、
アプリ開発者は一度リリースすると
OSのバージョンアップ毎に動作チェックをする事になる。
受託会社の人なら、毎年一定の仕事がくるので良いと思いますが、
発注者側からすると、毎年の更新が必要なので、
コストがかかる事を嫌がります
サーバーアプリケーションだと、
5年10年バージョンアップ無しなどがよく見かけます
サーバーの稼働費用のみでOKなわけです
アップデートを行うかは、発注者側が決めればよいのです。
ですが、スマホアプリは、
AppleやgoogleがOSやストアを握っているので
その会社の方針に従う必要がある。
そのため、アプリの更新タイミングなども
勝手に決められる事が多い
なので、スマホアプリは長期的にはいやがれるものだったりします。
しっかりとそのアプリを利用してもらって
広告扱いにするのか、収益を目的としたものにするのかを
曖昧にすると、改修コトスがかさむ事が多い。
単発の広告系ならよいですが、
長期的に運用するなら、運用コストも含めてちゃんと考えて開発する必要があります。
2022/07/14
【国葬】自分が生きている間に国葬が行われるなんて
安倍元首相、ご冥福をお祈りします。
タイトル申し訳ございません。
本当にショッキングな事件でしたよね。
私も最初聞いたときは、仕事中でしたが、
仕事の手が止まってしまいました。
国葬は賛否両論あるかもしれませんが、
賛成派です。
おそらく、テレビでも放送されるかと思うので、
テレビの前に正座して参加すると思います。
あと、色々と、各方面(外国の方もね)からの参加者も訪れるかと思うので、
お金の流れが生まれてくれると思います。
経済への刺激にもなるのかとも思ってます。
宗教の問題も表面化しているようですね。
そこら編もまともな運営をしていただきたいです。
色々とありましたが、お疲れさまでした。
ゆっくり休んでください。
2022/06/29
【golang】基礎 if 文 順番
golang を利用していて、複数条件の順番が気になったので
golangも同じように左側から 順番にやってくれる様子
順番変えると、エラーで落ちます。
どこかの言語のように、_abc?.A のような感じにできたりするのかな?
それとも、もっと良い書き方があるかもしれない。
2022/05/30
Flutterについて(受託開発)
よし、Flutterを覚えよう
10年くらい、android,iOSのアプリ開発(受託)をやってきました。
最近の傾向として、
スマホアプリの開発案件は全体で少なくなってきたかもしれません。
それと、アプリの難易度アップ(高機能なアプリ)が見受けられます。
少なくなってきた傾向として
・iOS ,android の両方の技術者が必要で、コストがかかる
・アプリの定期的な更新が必要でサーバーのランニングコストよりもかかる
このへんかなと、
あとは、フリーのエンジニアに叩き売りする感じのところもあるようです。
普通の企業でアプリを提案すると
最近は予算が問題でなかなか弱腰な事が多いです。
そこで、今後のアプリ開発を少しでも増やすため、
マルチプラットフォーム対応のものを利用して、
従来のアプリ開発の費用を減らして、数を回し、保守もらう流れを検討しています。
そこで目をつけたのが、Flutterでゲーム系でなければ敷居は低く参入できる。
Googleもある程度本気の様子なので。
今後2〜3年は確実にFlutterはあるりそうな気配もあります。
Flutter案件を提案して受託できるように勉強や情報収集していきます。
2022/05/12
Google アナリティクス 4 ってなに?
2023 年 7 月 1 日より、ユニバーサル アナリティクスでは標準プロパティで新しいデータの処理ができなくなります。それまでに Google アナリティクス 4 プロパティに切り替えて設定を進めておきましょう。
ねぇ、これって どうゆこと?
iOSのアプリが次々に削除されている様子です
Appleが公式サイト( https://developer.apple.com/news/?id=gi6npkmf )で発表したApp Store Improvementsという施策が開発者の間で波紋を呼んでいる。3年以上更新がなく、かつダウンロード数が極めて少ないアプリをApp Storeから削除するという方針だ。すでに280万本以上のアプリがこのプロセスによって削除されたという事実は、モバイルアプリ市場の巨大な新陳代謝を象徴している。
この施策の核心は、長期間メンテナンスされていないアプリ、いわゆる塩漬けアプリの排除にある。開発者として一度リリースしたアプリが手入れされずに放置されることは珍しくない。特に個人開発者や小規模なチームでは、次々と新しいプロジェクトに移る過程で、過去の遺産が管理外に置かれるケースは往々にしてある。Appleはこれらを品質低下のリスク要因と見なしている。
削除対象となる条件は2つある。1つ目は3年以内にアップデートが行われていないこと。技術的な観点から見れば妥当な期間だ。3年あればiOSのバージョンは3つ進み、iPhoneのハードウェアも大きく進化する。画面サイズの変更、ノッチやダイナミックアイランドの登場、プライバシー要件の厳格化など、3年前のコードベースが現在の環境で最適に動作する保証はない。古いAPIを使用し続けることは、セキュリティ上の脆弱性を招く可能性も否定できない。
2つ目の条件は、直近12ヶ月間でのダウンロード数が極めて少ない、あるいは全くないことだ。この条件が曲者で、極めて少ないという表現の具体的な閾値は公表されていない。しかし、文脈から読み取れるのは、新規ユーザーからの需要が消失しているアプリをターゲットにしているという点だ。既存のユーザーが継続して利用しているだけでは不十分で、ストアという市場において新たな価値を提供できていないアプリは退場を迫られる。
多くの開発者が抱く懸念は、完成されたツール系アプリの扱いだ。電卓や単位変換、特定の計算を行う単機能アプリなどは、一度完成すれば頻繁な更新を必要としない。機能がシンプルであればあるほど、バグも出にくく、OSの更新による影響も受けにくい。これらが更新不足という理由だけで削除されるのは理不尽に感じる。しかしAppleの論理では、プロモーションもメンテナンスも行われないアプリは、ストアの検索ノイズとなり、ユーザーが本当に求めている高品質な最新アプリへの到達を阻害する要因となる。
ポジティブな側面もある。削除通知を受け取った場合の猶予期間が、当初の30日から90日に延長された。この変更は開発者コミュニティからのフィードバックを受けたもので、90日あれば対応の余地は十分にある。大規模な改修を行わずとも、最新のXcodeでビルドし直し、最低限の動作確認を行って再提出するだけで、アップデートの実績は作れる。それだけでアプリの寿命を延ばすことができるのだから、開発者にとっては必須のメンテナンス作業として組み込むべきだろう。
削除されたとしても、そのアプリがこの世から消滅するわけではない。すでにユーザーの端末にインストールされているアプリは引き続き動作するし、アプリ内課金のリストア機能なども維持される。影響を受けるのはあくまで、App Storeでの新規発見とインストールだ。既存のユーザーベースを維持しつつ、ストア上での公開を終了するという選択肢も、ビジネスモデルによってはあり得る。
なぜAppleはここまで強硬に整理整頓を進めるのか。それはApp Storeというプラットフォームの信頼性を維持するためだ。ユーザーがアプリを検索したとき、動作しないアプリや画面レイアウトが崩れた古いアプリが表示されれば、iPhoneそのものの体験価値が下がる。最新の技術、最新のデザインガイドライン、最新のプライバシー保護機能に準拠したアプリだけが並ぶ場所でありたいというAppleの意思表示は明確だ。
280万本という削除数は、見方を変えればそれだけの数のアプリが役割を終えたということでもある。デジタルコンテンツは永遠に残ると思われがちだが、OSという土台が常に変化し続ける以上、その上で動くアプリもまた生物のように適応し続けなければならない。変化に対応できない種が淘汰されるのと同様に、更新されないアプリもまた姿を消していく。
開発者が取るべき行動はシンプルだ。App Store Connectに登録しているメールアドレスが有効かを確認し、Appleからの通知を見逃さないようにする。そして、自分のポートフォリオの中に最終更新日が2023年以前のアプリがないか棚卸しをする。もし該当するアプリがあり、それを存続させたいと願うなら、今すぐXcodeを開くべきだ。コードを書き換える必要すらなく、ただ最新の環境でビルドボタンを押すだけで救える命がある。
ダウンロード数の基準が曖昧なことへの不安は残る。極めて少ないという言葉が、月間10ダウンロードを指すのか、年間100ダウンロードを指すのかは誰も知らない。この不透明さは、開発者に常に緊張感を強いる。ボーダーライン上にいるアプリを持つ開発者は、この通知に怯えることになるだろう。しかし、逆に言えば、それほどギリギリの需要しかないアプリにどれだけのリソースを割くべきか、という冷徹なビジネス判断を迫られているとも言える。
ストアの品質担保はユーザーにとって最大の利益だ。検索結果が洗練され、安心してダウンロードできる環境が整えば、結果としてアプリ全体の利用率は向上する。現役で活動している開発者にとっては、放置された競合アプリが消えることで、自社のアプリがユーザーの目に留まる機会が増えるチャンスでもある。ゴミ屋敷を掃除しなければ新しい家具は置けない。App Store Improvementsは、アプリ経済圏を持続可能なものにするための必要な自浄作用だ。
技術的負債という言葉があるが、ストア上の公開状態を維持すること自体にもコストがかかる時代になった。放置こそが最大のリスクであり、何もしないことが即ち退場につながる。私たちは、ただコードを書くだけでなく、書いたコードが生き続けるための環境整備もまた、エンジニアリングの一部として受け入れなければならない。週末に久しぶりに古いリポジトリをcloneし、ライブラリの依存関係を解決し、ビルドエラーと格闘する。そんな泥臭い作業こそが、愛するアプリを守る唯一の手段だ。
