ソフトウェア開発」カテゴリーアーカイブ

iOS16 以降でデバイスの名前を取得したい

iOSアプリ開発している際に、端末を特定したい要件が入っています。

基本的にデバイスの固有情報をSwiftからUDIDやPhoneNumberを取得するのは非推奨ということで、端末固有の番号を生成するUUIDを端末特定に用いられることが多いと考えています。

ただ、今回の目的は別の外部からの情報と紐づけを行いたいので、アプリ内部で生成したUUIDでは目的を達成できないのではないかと。

そうなると、デバイス名を取得できればいいと考えているものの、Swiftでいう下記のコードはiOS16以降で実行すると

log.trace("name:\(UIDevice.current.name)")

無常にも結果は”iPhone”と返ってきました。

The entitlement for accessing the user-assigned device name instead of a generic device name
com.apple.developer.device-information.user-assigned-device-name | Apple Developer Documentation

いくつかの条件をクリアして権利を取得することができれば、デバイス名を取得することができそうだけど、正直面倒くさそう。。。

調べていると、MDM配下であれば設定値をプロファイルに追加で登録できそう

iOSアプリで端末のシリアル番号を取得する方法(MDM必須) #Swift – Qiita

ただ、ここで述べられている、「アプリ管理設定プロファイル」が、今回の案件で使っているMDMで言うところの何に当たるのかが不明。
このあたりはMDMを触っていないのでなんとも・・・。構成プロファイルとはまた別な気もするので確認かなぁ。

Claude3.5 sonet を使い始めています

GPTもいいのですが、最近はClaudeを使い始めています

Claude

日本語に関して、非常に自然な形での回答が返ってくることもいいのですが、Artifacts機能がなかなか素晴らしい。

簡単なツール作成であれば、それほど労力をかけずに作ることができるかもしれないポテンシャルを持っているように感じます。

ただ、GPTにしてもClaudeにしてもプログラムを書かせてもそれがそのまま動くということはなかなかなく、それなりに分かっている必要が出てしまいます。

Artifacts上で構築させたWebアプリケーションも、そもそもプレビューがエラーとなってしまうことも多々あり、GPTでは作成したコードの実行方法も教えてくれたのですがClaudeは聞かないと答えてくれません。

そして、往々にしてうまくいかないことも。。。
ただ、このあたりはすでにここまでできているのであればあと一歩。
壁を超えてくる日も近そうです。

WindowsとGPTが統合されて、ローカル環境のセットアップを含めて実行してくれるような未来も来るかもしれないと考えると、いよいよ持ってAI全盛期になりそうですね。

一方で、開発者に取って考えてみるとこれが開発の作業になってしまうと、楽ではあるものの開発者冥利に尽きるシーンに出くわすことが少なくなる。

さらに、とりあえずまずはAIに聞いてみると言うのは、スピードで考えれば良いことなのかもしれませんが、頭の中で論理立ててロジックを考えていくという訓練する場を減らすことにつながってしまう。
ローレベルの開発者がスキルアップをするシーンが奪われていくのではないかと要らぬ心配をしてしまいます。

それでも、使うメリットは高いと言わざるを得ないところが難しいですね。
良い付き合いができればいいと思うのですが。

そこはかと漂うIT使いこなしてない感

仕事で、Webアプリケーションのパフォーマンスを改善する必要があり調査しています。
基本的にはChromeのDeveloperToolsでNetworkタブで計測。
複数のLambdaで構築したAPIを呼び出していたりするので、処理時間の長いLambda関数に関してコードを見ながら短縮の余地がないかを探していました。

ただ、これって基本的にパフォーマンスが悪いという原因をバックエンドに求めていることになるんですよね。

私自身がフロントエンドよりもバックエンドの方が理解しているというのもあり、実際にバックエンド側でそれなりの時間がかかっているという予想は立っていたので今回のケースにおいてはそれでも良いのかもしれませんが、手順としてはちゃんと事実を知る必要がある。

では、どうすればいいのか?というと、もう少しDeveloperToolsの機能を使いこなしましょうね、ってことだと思う。

Lighthouse機能とか、しっかり使ったことなかったなぁ

AIにしても普通のToolにしても、特定の機能で頑張っているのではなくて、ちゃんと新しく追加された機能だったり、本来の手順としての使い方だったりということをもう少し勉強するべきなんだろうと改めて思った。

永遠にまだまだだな

久々にBuildに参加してみようかと

毎年のことですが、Microsoftの開発者向けイベント、Buildが月末に開催予定との案内が来ました

Microsoft Events – Microsoft Build Japan

セッション情報も公開されていましたが。。。

PowerPoint プレゼンテーション (microsoft.com)

思ったよりも数が少ない印象でした。

どう考えても今年のメインテーマとしてはAIであると思っているし、OpenAIを要するMicrosoftとしてはCopilotなりAzure AI なりで盛りだくさん!かと思ったら、そもそもセッション数が少なかった。

うーん、こんなモノだったかな?

いずれにしても、少しAzure関連の情報からは離れてしまっていたので、ざっくりと全体を聴きつつ、Copilotも見ていきたいです。

恥ずかしながら、ベータ版で触ったのみで有償化されてから触っていないんですよね。
試しにものづくりしてみたいと思ったときに、やっぱり試してみたいわけで。
お話を聞いてみて、判断していきたいところです。

Qiita Engineer Fest 2024が始まるよ

Qiita Engineer Festa 2024(キータ・エンジニア・フェスタ 2024) – Qiita

というわけで、Qiitaがイベントを行います。

年末に行われるアドベントカレンダー企画に近いのかな?と思ってみてみると。。。

Qiita Engineer Festa 2024 の記事投稿キャンペーンに紐づけて19記事投稿すると、「Qiitaオリジナルグッズ」を必ずプレゼント!38記事投稿すると更に特別な「Qiitaオリジナルグッズセット」を必ずプレゼント!

いや、どんだけ書かせるんだ!

まぁ、記事の文字数とかそういう制限はないみたいなので、極端な話、適当に落ちている話題で記事を書いても達成はできなくはないけれど、そういうことじゃないよねって気もする。

Organization対抗戦は、私が所属している会社では大っぴらにはやっていないので対象外。

残るはスポンサー企業テーマになるわけですが、今のところ5つの企業がスポンサードしているよう。
ちょっと気になるのはCodeAGIというもの。

CodeAGIで実際にコードを自動生成してレビューを投稿しよう! – Qiita

今どきめずらしく、クライアントアプリっぽい。
そして、いたるところにデザイナーではなくエンジニアが作ったっぽい資料感がたまらない。

記事連投とかはちょっと続く気がしないけれど、CodeAGIというものは少し触ってみても面白いかな、と思った。

新卒研修で教えることはなにか

Qiita見ていたら、毎年のことではあるけれど新卒研修に関する記事が

【2024年度】エンジニア向け研修資料まとめ #エンジニア – Qiita

リクルートやサイボウズなど、大手のベンダーはさすがの充実度である。

ただ、これだけの研修を用意できるのはもちろん素晴らしいのだけれど、その研修をこなすことができるだけの下地を持った新卒がいるということが一番素晴らしいとは思っている。

結局のところ、入社前段階で何をやっていたのか。
どこまで研鑽を積んできたのか?ということになるのではないだろうか。

正直言って、文系出身者や大学までプログラミングやってませんでした!みたいな人がこの研修を受けてどこまでついていくことができるのだろうか。
ついていくことができたとした場合、それはそれですごい地頭にだろう。

それでも、本当にこの内容を理解できているのだろうか。。。?
少なくとも講習だけで頭に入るとはとても思えないのだけど、それは所詮私程度の頭ということになるのかもしれない。

結局のところ、息子を見ていても中学・高校時代から情報系の授業が体系として組み込まれている現代において、新人研修の中身自体ももっと若手に作らせないと行けないのではないかとすら思えてくる。

根本的に前提が違うのかもしれない

そう考えると合点がいくわけだが、同時に、自分自身に対して若干寂しさを感じてしまうものですね。

そうは言っても、まだ10年以上は働かなければならないわけで、新卒研修の資料を見ながら、「新卒に教えている内容、わかんないんだけど」という気持ちを抑えながら勉強していくしかないわけです。

頑張らねば

ソフトウェアアーキテクチャに関して

たまたまですが、イベントにいくつか参加しました
ここのところ、登録はすれどもなかなか参加できなかったりしていたのでちょっと久しぶりです

ソフトウェアアーキテクチャメトリクス – Forkwell Library #44

ソフトウェアアーキテクチャメトリクス – Forkwell Library #44 – connpass

https://amzn.to/3IgDAGe

毎度おなじみのForkwellさんによるイベント。今回は「ソフトウェアアーキテクチャメトリクス」という本の訳者さんが登壇。

オライリー本なので、なんとなくタイトルからアーキテクチャに対しての何かしらのメトリクスを取得するための手法だとかがまとまっているのかな?と思っていたのですが、そうではないよう。

10人のアーキテクトが思い思いに話をしている内容であって、訳者の方いわく「エッセイ」だと。
なるほど。

オライリー本は、時々そんな感じのエッセイ本を出しますよね。

言ってしまうと、まだ話をまとめるには時期尚早ということなのかもしれないな、と思った。

NECグループAWS活用の裏側大公開|Well-Architectedフレームワークとコミュニティ

NECグループAWS活用の裏側大公開|Well-Architectedフレームワークとコミュニティ – connpass

こちらはAWSに焦点を当てたもの。
でも、よくよく考えて見るとこちらもアーキテクトの選択で何を重要視するのか?だったり、選択したアーキが正しかったのかを振り返るという観点では通じるものがあるかもしれないな?と思った。

AWSの資格試験では基本的にUdemyを中心に勉強をすることが多いのですが、存在は知っていてもちゃんとWell-Architectedフレームワークを読んだことないな、と思いました。

落ち着いて考えてみると、一度それを頭に読み込んでから資格勉強したほうがいいのでは。。。と今更ながらに思ったわけです。

AWS Well-Architected – 安全で効率的なクラウドアプリケーション (amazon.com)

このあたりの資料はそれなりの頻度で更新されていきます。
そもそものAWSサービス自体が追加されていくので結構たいへんですよね。。。

イベントでは、どうやってこれらのレビューをやっていくのかとかも話されていたので興味深かったです。
一方で、自社でそこまで回していくのは、それなりに規模がないと厳しいような気もしましたが、そのあたりはしっかりと学んでいないものの言い訳なのかも。

うーん、勉強しないとですね

Microsoft Edgeへの移行を検討中

これまで、ブラウザはBraveを利用してきましたが、Microsoft Edgeがここのところ気になる機能を出しているので移行を検討中です。

SplitView

1つ目の気になる機能としてはSplitViewです

今、モニタとしては4年前に購入した29インチのウルトラワイドディスプレイを使用しています

https://amzn.to/42pQgnu

ウルトラワイドなので、ここにブラウザを半々に表示させて作業をしています。
左のブラウザでXを表示させながら右のブラウザでネットを見ていたり、X上で投稿された記事を右のブラウザにアドレスをコピペして表示させるなどですね。

Edgeのスプリットビューは、一つのタブを分割することができるようになります。

ツールバーの上記アイコンを押下することで画面が分割され、

左側のページ上にあるリンクをクリックすると、右側のビューに表示されるような感じ。

どちらのビューにデフォルトとして表示させるのかや、左右の切り替えはビュー右上にある3点リーダーをクリックして表示されるメニューで指定することができる

使ってみてよかったところと注意点

ウィンドウ自体を2つ配置すること自体は、これまで不便に感じたことはそれほどなかった。

ただ、この仕組みを使い始めるとなかなか便利である。
表示するページによっては、画面全体で見たいときもあればそうでなくても問題ないこともある。

タブごとにSplitするかどうかを選択することができ、更に分割位置も調整することができるのでその比率をいい感じにすることができる。

クリックした際に自動的に別ビューに表示されるのでコンテキストメニューから「別のタブで開く」を選択する必要性はない。

注意しないといけないのは、別のリンクをクリックするとビューの内容が更新されてしまう。
そのため、次々と新しいタブを開いていくとい運用は向かずに、一つ一つ読み終えてからリンクを開く必要性が生じてしまっている

まぁ、落ち着いて読んで行けよと言われればそのとおりなので、実際に問題になるのかは使ってみて考えることにする

コレクション

気になったものを保存する先として、お気に入り以外にコレクションと言う機能が追加されている

ツールバーの上記アイコンを押下することでコレクションを表示させることができる。

コレクションは、Webページ全体だけでなく、その中の画像や文字列のみを追加することができるので、ちょっとしたスクラップブックのようなイメージ。

追加したコンテンツは画像であれば画像、文字であれば文字がコレクションに追加されていき、クリックするとその元となったページが表示される。

使ってみてよかったところと注意点

何かしらテーマを持って調べ物をしている際に、面白いなって思ったことをメモ代わりに追加しておけるので、後で読もうかな?という感じでタブを開きっぱなしにするといったことを防ぐことができるかもしれない。

カテゴリごとにコレクションを作って、面白かった記事や文言を抜き出してコレクションに追加していけば、情報収集や整理が楽になりそうな気がする。
追加したコレクションにはメモを残すこともできる

メモを残すことで、対象をなぜコレクションに追加したのかを後から見返した際にすぐに気づくことができるようになる。

一方で、コレクションに追加したものをクリックすると新しいタブで表示されてしまう。

画像をクリックした際には画像を拡大表示する、テキストをクリックした際にはテキストを選択可能にするといったほうが個人的にはいいように感じるけど、そのあたりは情報が更新されている可能性だとか、著作権的になのか、リンクと言う形を取ったほうが安全とかそういうことがあるのかもしれない。

Microsoft Rewards

これまで、Braveを使ってきた一つの理由がBraveのReward機能だ。

Braveは広告のブロックに力を入れていて、Webページ上の広告を自動的に非表示にしてしまう。
一方で、Brave自身が定期的に広告を出すような仕組みを入れている。

このBraveがだす広告による収益は、Braveのユーザに仮想通貨(BAT)として還元される。

つまり、Braveを利用しているだけで仮想通貨を取得することができるのだ

これらに関しては、bitFlyerなど仮想通貨取引所でアカウント作成して連携しておく必要はあります。

さて、これまでの履歴を見てみると。。。

月によって、ものすごいばらつきがありますが、仮に、平均0.5BATとすると、2024/2/4現在

一ヶ月15円くらい・・・・?

うーん、別にこれで儲けようとか思ってはいないですが、これを理由に続けるかどうかはあまりに意味がないですね。

と思っていたら、Edgeにも Microsoft Rewards なるものが。

現在のRewadsポイントはウォレットを表示することで確認することができます。

Rewardsは、Bing使ったりしていると貯まるようで、ちょっとした日々の指定されたアクティビティをすることでも貯めることができる。

ためたRewadsはAmazonギフト券とかと交換することもできるようだが、そのために色々と頑張るのもちょっとバカバカしいので、これはあくまでオマケ機能と思っていたほうが良さそうだ。

しばらく使ってみて判断

まだ、本腰入れて移行するかは決めていないけれど、SplitViewで次々と表示させながら、気になったものをコレクションへ追加するという運用は、良さそうに思える。

XやGMailで届いたものを開いていったり、Kaggleのノートブックを集めていったりと、お気に入りでやってしまうには永続性がないものはコレクションに追加していき、必要がなくなった時点でコレクションごと削除、とか。

BingChatでGPTへの質問とかも気軽にできるようになっているので、しばらく使っていなかったけどEdgeの進化スピードは気づいたらすごいことになっているイメージ。

まだ埋もれた機能もあるだろうから、ちょっと一度しっかりと見てみると生産性がバク上がりするかもしれないな、と思った。

SoftwareDesign2月号

定期購読しているSoftwareDesignの2月号が届きました。

https://amzn.to/3UtdNSq

今月号の特集としてはテストとWeb APIセキュリティに関して。

テストに関しては、テスト技法に目を奪われがちなんだけど、そもそものテストの考え方を正していく必要があるとしてテストマニフェストが紹介されていた

https://www.growingagile.co/the-testing-manifesto/

SoftwareDesignに掲載されていたものは2015年バージョンで、上記のものは2023年バージョンのようだ。
基本的な考え方が変わっているわけではなく、言葉を少し修正した形と紹介されていた。

checking functionality over Testing understanding

機能性をチェックするよりも、理解をテストするとでも訳すのだろうか?
SoftwareDesignでは「機能性をチェックするよりも、チームが理解している価値をテストする」とある。

これは、結構難しい問題に感じる。

本来、価値を提供するために機能を作り込んでいるはずのものが、機能を作ることが目的となってしまって気がつくとその価値が提供できていないのではないだろうか?ということだろうか。

そう考えると確かに、そしてまさに、アジャイルではないか

ソフトウェア開発ではプログラミングによって機能を作り込んでいく。ただ、出来上がったアプリケーションがその機能によってなんの価値を提供しているのかに立ち返って、常に検証し続ける必要がある。
そして、アジャイルの文脈ではその検証を繰り返してスプリントを回していく。

どうも、ウォーターフォールが染み付いてしまい、当初作った仕様に従った機能のテストしかできていないように感じてしまった。

改めて、このあたりに関しては気を引き締めていかないといけないと感じた。

先日、仕事でイベントに参加させていただいた際にOracleが提供している MySQL Heat Waveなるものを知った

Heat Wave

MySQL HeatWaveは、HeatWave In-Memory Query Acceleratorを搭載したフルマネージドのデータベース・サービスです。トランザクション、データウェアハウスやデータレイクをまたいだリアルタイム分析、機械学習を1つのMySQL Databaseに統合し、ETLの重複による複雑さ、レイテンシ、リスク、コストを排除した唯一のクラウド・サービスです。

HeatWave – 組み込みのMLによるインメモリ・クエリ・アクセラレータhttps://www.oracle.com/jp/mysql/heatwave/

ということで、DBとDataLakeが合体したような感じなのかしら。
OracleCloudだけでなく、AzureやAWSでも動作するとある。
そういう意味ではSnowFlakeの対抗になるものなんだろう

そう思ったら、あからさまに対抗意識を燃やしている記事があった

5 reasons why MySQL HeatWave on OCI is better than Snowflake
https://www.oracle.com/mysql/heatwave/heatwave-vs-snowflake/

こういった公式で出している比較がどれほど意味があるのか。
都合がいい条件での比較担っている可能性もあるので、なんとも言えないところはあるけど、AWSでも動作するというのであれば試してみても面白いのかもしれない。

ただし、こちらの記事を読むと、AWSで使う場合にもOracleCloudの契約が必要になるようだ

東京リージョンにやってきた MySQL HeatWave on AWS を試す (1) 初期設定編https://qiita.com/hmatsu47/items/8f202eef64ea57e7d948

うーん、それは結構面倒そうだ。

OracleとMicrosoft

色々とHeatWaveに関して調べていると、こんな記事も見つけた

Ellison氏は、OracleとMicrosoftの連携についても改めて語った。「Oracle Cloud」とAzureのマルチクラウドでは、データのイグレス/エグレスの料金がかからないほか、AzureのアプリケーションとOracle Cloudのデータベース間は非常に低遅延だという。また、Oracle Cloud/Azureにおける大半のサービスは双方のコンソールからアクセスできる

「ウォールドガーデンは崩壊した」–エリソン氏が語る、顧客を“庭の主”にするマルチクラウド
https://japan.zdnet.com/article/35194867/

マルチクラウドで業務を回しているユーザーも、なんでそうなったのかはベンダーがそれぞれそう構築したという後ろ向きな理由も多分にあるだろうが、それなりに増えている気がする。

その中で、クラウド間でのデータ連携は日常で発生していることを考えると、こういう動きというのは歓迎されるべきもので、現状で他はどうなんだ?というのは気になるところだけど、うまく見つけることができなかった。

OCI(Oracle Cloud Infrastructure)はこれまであまり気にしてこなかった面もあるので、ちょっと気に留めておいてもいいかもと、思ったです。

ちなみに、OCIと聞くとどうしてもOracle Call Interfaceを思い浮かべてしまうんですよね。。。あれ、今でもあるよね、きっと。