拙僧Notionをよく使っているのですが、何も入力していない行でSpaceキーを押すとAI入力モードになるのが邪魔で仕方がないと思っていました
この機能をオフにする(Notion AIの無効化)には、Notionのサポートチームに直接止めるよう連絡をしなければならないとのこと
めんどくさそうと思っていたが、Notionデスクトップアプリから簡単に連絡できたので備忘録
①右下のはてなマークを押して、Message supportを選択
②チャットでAI入力を止めたいと伝える
以上
チャットボットとの会話中、ワークスペース名やメールアドレスを尋ねられるので、それに応えると解除作業に移ってもらえる。
最後に"担当チームからメールで連絡します。"とチャットで回答がくるので、このメールが届けば作業完了なのだろうか
こんなに楽なら早く申請すればよかったーー
なえTです
現職が異次元の忙しさに入り、家でも家事をしなければならず、
色々ままなりません
コード書くだけの時間を1億時間ほしい
Udemyで経路を描写するMapアプリの作り方講座を購入して触っています。
この講師の方はUIKitでもIB一切使わずコーディングしてくれるので性に合っています
自分も転職用の自作アプリ作ったら、今後はSwiftUIに移行しよう
今日はわすれがちなSelectorについて書きます。
例によって人様のブログを参考にしてます、恐縮です
さながら羅生門のババアのようになんでも拝借します
#selector
Objective-Cに存在していた メソッドのようなもの(メソッドを起動させるためのメッセージデータ)
#selector( done ) と記述すると、done()という関数が使える
引数 action:にメソッドを投入したいときなどに使う。
@objc
Selectorでよびだすfuncは、@objcと先頭につけて宣言しないといけない。
これをしないとコンパイルで事故るらしい
@objc と記載されたfuncを書く際は、基本的にobjective-Cの仕様に沿った使われ方(selectorなど)をされ、そのときのお守りみたいなように考えれば良い
じゃあの
構造体/クラス内で定数を宣言する。
struct Hoge {
let hoge = hugahuga
}
この定数をクロージャ外で呼び出す際、通常は構造体/クラスをインスタンス化させないと呼出できない。
//実行結果 hugahuga
しかし、構造体/クラス内で定数を宣言する際、前にstatic と記載すると、インスタンス化しなくても直接"型名.プロパティ"と記載することで呼出可能になる。
struct Hoge {
static let hoge = hugahuga
}
//実行結果 hugahuga
これは、構造体/クラス内で宣言した定数が、通常はinstance propertyとしてインスタンスに関連付いて登録される所、staticがついた定数はtype propertyとして型自体に登録されるため、インスタンス化しなくても呼出可能となる、ということ。
Model内で生成したColor構造体や、Constant構造体(ID等を保管する場所)が持つプロパティは、staticをつけて定数を宣言することで、他のクラスで呼び出しやすくすると吉
ちなみにstaticはメソッドにも使える
struct Hoge {
static func hoge(){
print (hugahuga)
}
//実行結果 hugahuga
正月から次の3連休までぶっつづけで本読んで、経路作成アプリを作ろうとした所、location取得に際する非同期処理とマップ描写のタイミング合わせがうまくいかず、心がへし折れて入門書をやりなおしていたなえTです。
前回の学習ではちょっとしか触れなかったFirebaseを触り直しているのですが、PodsでFirebase SDKをインストールした際、各ライブラリのiOS最低要件 < iOSシミュレーターの実行可能なOS となり、Xcode上でグワシャーっとエラーが発生する件が気になったので解消法を調べました。（人様のサイトから情報をいただき恐縮です）
ライブラリの導入に使用したpodfileの最下部に、下記のコードを追記し、
ターミナルからpod update を実行すればよいとのことです
post_install do |installer|
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '9.0'
end
end
end
さあ頑張るぞ
大したことでもないのですが、一応書いておきます
どうやらXcode14で実機ビルドを行うと、CocoaPodsに対してSigning(署名)の設定をしていないとエラーを吐かれるようです
この場合、上記のTeam 選択肢をNone -> 自分のチーム名に変更することで、ビルドが通るようになります。 エラーに書いてるまんまの対処法になりますが、突然エラーがでてびっくりした人（自分）の備忘録として。
おまけ
Q. さっきFirestoreのデータベースへの接続テストを行ったところ、認証エラーになりました。なぜでしょう？r
A.Firestoreへの接続期限を適当に設定したところ、6月に31日は存在しないためエラーになっていたようでした アホかな？
手作りおせちに気合を入れすぎたということにしておきましょう
皆様あけましておめでとうございます。今年も1年ご安全に！
なえTです
最近SQLの学習から足を洗い、StoryboardなしでCGsize, CGPoint, CGRect等を用いてUIを作成していく練習をしています。
↓この本、非常にイイ
UIKit使うなら、StoryBoardを使ってUIを置いていくのがセオリーなんかもしれんけど、私はコードで組み立てていく方が好きかなぁ（エラーおこりにくいしコード差分もわかりやすいし）
リンク貼った本のUI、API通信機能の実装まですすめ、CocoaPodsからグラフを出力できるライブラリを利用しようとしたところ、pod initの実行中にエラーがでて詰まりました。
――― MARKDOWN TEMPLATE ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
### Command
```
/opt/homebrew/Cellar/cocoapods/1.11.3/libexec/bin/pod init
```
### Report
* What did you do?
* What did you expect to happen?
* What happened instead?
### Stack
```
CocoaPods : 1.11.3
Ruby : ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [arm64-darwin21]
RubyGems : 3.3.26
Host : macOS 12.6 (21G115)
Xcode : 14.2 (14C18)
Git : git version 2.37.1 (Apple Git-137.1)
Ruby lib dir : /opt/homebrew/Cellar/ruby/3.1.3/lib
Repositories :
```
### Plugins
```
cocoapods-deintegrate : 1.0.5
cocoapods-plugins : 1.0.0
cocoapods-search : 1.0.1
cocoapods-trunk : 1.6.0
cocoapods-try : 1.2.0
```
### Error
```
RuntimeError - [Xcodeproj] Unknown object version (56).
/opt/homebrew/Cellar/cocoapods/1.11.3/libexec/gems/xcodeproj-1.21.0/lib/xcodeproj/project.rb:228:in `initialize_from_file'
/opt/homebrew/Cellar/cocoapods/1.11.3/libexec/gems/xcodeproj-1.21.0/lib/xcodeproj/project.rb:113:in `open'
/opt/homebrew/Cellar/cocoapods/1.11.3/libexec/gems/cocoapods-1.11.3/lib/cocoapods/command/init.rb:41:in `validate!'
/opt/homebrew/Cellar/cocoapods/1.11.3/libexec/gems/claide-1.1.0/lib/claide/command.rb:333:in `run'
/opt/homebrew/Cellar/cocoapods/1.11.3/libexec/gems/cocoapods-1.11.3/lib/cocoapods/command.rb:52:in `run'
/opt/homebrew/Cellar/cocoapods/1.11.3/libexec/gems/cocoapods-1.11.3/bin/pod:55:in `<top (required)>'
/opt/homebrew/Cellar/cocoapods/1.11.3/libexec/bin/pod:25:in `load'
/opt/homebrew/Cellar/cocoapods/1.11.3/libexec/bin/pod:25:in `<main>'
```
――― TEMPLATE END ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
[!] Oh no, an error occurred.
Search for existing GitHub issues similar to yours:
If none exists, create a ticket, with the template displayed above, on:
https://github.com/CocoaPods/CocoaPods/issues/new
Be sure to first read the contributing guide for details on how to properly submit a ticket:
https://github.com/CocoaPods/CocoaPods/blob/master/CONTRIBUTING.md
Don't forget to anonymize any private data!
Looking for related issues on cocoapods/cocoapods...
- Pod init in xcode 14.1 and mac os ventura 13.0.1
https://github.com/CocoaPods/CocoaPods/issues/11656 [open] [11 comments]
9 hours ago
- pod init after update it to XCODE 14
https://github.com/CocoaPods/CocoaPods/issues/11546 [open] [18 comments]
5 days ago
- Error occurred when executing pod init
https://github.com/CocoaPods/CocoaPods/issues/11536 [open] [16 comments]
5 weeks ago
and 11 more at:
RuntimeError - [Xcodeproj] Unknown object version (56)とあるので、xcodeprojファイルのバージョン互換がうまくいっとらんのやろうなと判断
まずはCocoaPods側のバージョンを最新にしてセットアップし直すも、改善なし
ネットで調べてると、xcodeprojファイルのProject Formatを変更すると治るとの噂が
私のプロジェクトファイルのフォーマットはXcode 14.0互換と設定されていたので、もしやとおもいXcode13.0 互換へ変更
そしたら一発でpodfileの作成ができました。
Xcode14.0は今週くらいにupdateしたばっかなので、もしかしたらCocoaPods側がまだ互換性を持っていなかったのかもしれない。
いずれにせよ、コードと関係ないところで起きるエラーはイヤイヤなのである
ラチェットアンドクランク2のトラクタービームあてるとイヤイヤ言うロボットくらい嫌である
ラチェクラ2は思い出深いゲームで、偶然のバグでインソムニアックミュージアムにいくことができ、そこにあった没データやエフェクトの紹介コーナーがすごい記憶に残ってる
ゲームで使われてる技術ってすごいよな、この間見た初代クラッシュバンディクーを作ったエンジニアが、PS1のゲーム用CPUが本来の演算能力を発揮できてないから、カーネル部分？の別のCPUをバイパスして処理を行なってた話とか 超面白かった
あと、iPhoneが出るより前、先にiPodTouchが出始めた頃はApp Storeがなくて、アプリはブラウザと時計と地図とYoutubeくらいしかなかったんよな(あのころのYoutubeは多分Google買収前)
だから野良アプリ入れるために脱獄して、いろんなアプリ入れて、本体の機能をいじるプログラムも入れて、文鎮化して、気合いで直して、スプリングボードを改造して、メモリが足りずに死ぬほど重くなって、記憶容量から仮想メモリを作ってなんとか持ち堪える...みたいなことを中学校のころからやってました。
Tap Tap Revolutionとか死ぬほどやったし、あれのおかげでProdigyとかBlack TideとかFACT(当時はまだ外タレ)といった非常にいいバンドを見つけることができました。App Storeが出た後はTap Tap Revengeって名前でちゃんとストアで販売されてるのを見つけたり、でもいいのか悪いのか（普通に悪い）脱獄して文鎮化の恐怖に怯えながらやる音ゲーのほうがアドレナリンがやばかったり
思えばパソコン周りのことは昔から触れてたな、なんでこっちの道で飯食ってこうと思わなかったんだろうか...
どうもサルです。
私サルめは、構造体のことがわかったようでわからないまま、XcodeをシバいてStoryboardをいじいじしたりDelegateで通知をとばしたりViewControllerをいじいじしたりUserDefaultにデータをいれたりしていました。
流石にこのままではまずいと、頭のヘルメットが黄色に光り輝き始めたため、そろそろきちんと整理しようかと思い立った所存です。
こちらのサイトを参考にしました
>>>Swift の struct（構造体）では、値を保持するためのプロパティや関連する機能のメソッドなどをまとめて定義しておいて、必要な時にその struct のインスタンスを生成して使うことができます。
使い方としてはクラスと同じと言うことですね
書き方の例 >>>>>>>>>>>>>>
struct Fueltank {
var alert: String = "A"
var fuel: Int
init(alert: String, fuel: Int){
self.alert = alert
self.fuel = fuel
}
func indication(){
print("\(alert) is \(fuel)L")
}
}
var ind = Fueltank(alert: "Fuel Remaining Amount", fuel: 30)
ind.indication()
⇨結果 Fuel Remaining Amount is 30
クラスとの差異としては、①継承ができない ②参照渡しでなく値渡し ③デイニシャライザが使えない の3点。
①継承ができない については、新しくクラス、構造体を作成する際、その参照元として(スーパークラスのように)継承をおこなうことができない。クラスの継承については以前の記事で説明済み
②参照渡しでなく値渡しとなる とは、下記例で見比べるとわかりやすい。
構造体で実行した場合（値渡し）>>>>>>>>>>>>>>
struct Fueltank {
var alert: String = "A"
var fuel: Int
init(alert: String, fuel: Int){
self.alert = alert
self.fuel = fuel
}
func indication(){
print("\(alert) is \(fuel)L")
}
}
var ind = Fueltank(alert: "Fuel Remaining Amount", fuel: 30)
var ind2 = ind
ind2.fuel = 15
ind.indication()
ind2.indication()
⇨結果 Fuel Remaining Amount is 30L
Fuel Remaining Amount is 15L
クラスで実行した場合（参照渡し）>>>>>>>>>>>>>>
class Fueltank {
var alert: String = "A"
var fuel: Int
init(alert: String, fuel: Int){
self.alert = alert
self.fuel = fuel
}
func indication(){
print("\(alert) is \(fuel)L")
}
}
var ind = Fueltank(alert: "Fuel Remaining Amount", fuel: 30)
var ind2 = ind
ind2.fuel = 15
ind.indication()
ind2.indication()
⇨結果 Fuel Remaining Amount is 15L
Fuel Remaining Amount is 15L
値渡しの場合は、indと代入後にfuelプロパティを書き換えたind2の値が異なるが、
参照渡しの場合、両方とも同じ値となる。
これは、値渡しが通常の演算通り、代入時の値(30)を渡しているのに対し、
参照渡しは、値(30)のプロパティはここにありますよ、という情報を渡している。
値渡しされた変数(ind2)を書き換えても、代入元(ind)の値はかわらないが、
参照渡しされた変数(ind2)を書き換えると、参照元となるインスタンスのプロパティそのものを書き換えてしまい、代入元(ind)も同じプロパティを参照しているので、両者とも値が変わってしまう。
例えるなら、Webページ上にある画像に対して、A君がB君にコピーして渡すのが値渡し
B君が画像にどんなコラージュをあててもA君の画像はもとのまま
A君の画像
B君の画像
Webページ上にある画像に対して、A君がB君にページリンクを渡すのが参照渡し
B君がリンク元の画像にコラージュをあてると、同じリンクから参照しているA君の画像もコラ画像になってしまう。
A君の画像
B君の画像
要は値を渡すか参照元を渡すかって言う、まんまの意味なんですけどね。
ちなみに値渡しのところで、意図的に参照渡しを行いたい場合は、引数の前に＆をつかえば実行可能。詳しくは下記ページをご参照ください。
③デイニシャライザが使えないとは？
そもそもイニシャライザとは？
人のQiita記事で学び、自分のはてブでアウトプットするサル
イニシャラザの中身は、クラス、構造体がインスタンス化される際の、すべてのプロパティ、メソッドに対する初期値 ※基本的にすべて初期値が存在しなければならない。
UIKit Frameworkに最初から入っているスーパークラスなどではなく、自分でクラス、構造体を作成する場合、すべてのプロパティ、メソッドに初期値を設定する必要がある。
なぜ初期値が存在しないといけないかと言うと、クラス、構造体のプロパティ、メソッドに初期値がなければ、インスタンス化した際の初期値がない⇨nilとして処理され、型の不一致、および解放前メモリへの不正アクセス等でエラーが発生するため。（nilはオプショナル型、Any型以外では許容されていないよ！なのでこれらに限り初期値はなくてもOK）
値渡し、参照渡しの説明に使ったコードだと、こちらがイニシャライザ部分
ここでFueltank内の各プロパティの初期値を設定している。
※selfと記載することで、このクラス/構造体自身のメソッド、プロパティに代入する、という意味となる
init(alert: String, fuel: Int){
self.alert = alert
self.fuel = fuel
}
その後、インスタンス化したFueltankクラスの引数として、alertとfuelに引数を渡しているが、これはイニシャライザで定義した初期値を上書きしている、という事。
var ind = Fueltank(alert: "Fuel Remaining Amount", fuel: 30)
このイニシャライザ、クラスの場合は毎回必ず記述しないといけないが、構造体の場合はイニシャライザを定義しない場合、暗黙的に自動で全てのメソッド、プロパティに初期値が付与される。これを全項目イニシャライザとよぶ。
●車の構造体 イニシャライザなしでもインスタンス化可能
struct Car {
let model: String
let type: String
let price: Double
let serial: Int
}
実際には、下記のイニシャライザが自動で作成され、かつ省略されている。
init(model: String, type: String, price: Double, serial: Int){
self.model = model
self.type = type
self.price = price
self.serial = serial
}
基本的にイニシャライザは、インスタンス生成された際に一番最初に読み込まれる情報だが、逆にインスタンスが破棄される際(ある意味一番最後)に読み込まれるデイニシャライザ という構文もある。これは基本的に暗黙的に処理される内容だが、自分で内容を書くことも可能。
struct Car {
let model: String
let type: String
let price: Double
let serial: Int
init(model: String, type: String, price: Double, serial: Int){ //instance生成時呼出
self.model = model
self.type = type
self.price = price
self.serial = serial
}
deinit{ //instance終了時呼出
print("Car instance is terminated")
}
}
デイニシャライザはクラスのみ実行可能で、構造体では実行不可能。この違いがある
以上3点の差異について説明できました。書き方、使い方はクラスみたいなもんで、クラスは何らかの機能を有していて、インスタンス生成してクラス自体がもつ目的を遂行するのに対し、構造体は単なるデータ、処理をまとめて保持する倉庫みたいな認識でいいのかな？
また一つ賢くなったサルでした
山田亮一Forever
