なえT備忘録

何の参考にもならないかもしれませんが、いつかは参考になるようにします

アラサー未経験エンジニアが初現場で気をつけていた事

はいなえTです。

 

こんな記事いっぱいありますよね。未経験エンジニアとして初めての現場で、

どんな感じで揉まれて成長していったかみたいな話です。

色々話したい事はあるのですが、結論だけ箇条書きで書きます。

 

---------------------------------

①未経験エンジニア、駆け出しエンジニアという肩書きは捨てる

自分にとっては初めての業務ですが、現場のリーダー / メンバーにとって

「どのタスクが自力でできる / 聞きながらできる / できない 」かさえ分かれば

バックボーン等々、それ以上の情報は必要ないと思うんですね。(私個人の意見です)

 

未経験 / 駆け出しアピールをしても、面倒見の良い優しい人からは

「タスクを振りすぎてパンクしないか / 病んでしまわないか」と心配されますし、

そうでない人からは「だから何?仕事なんだから黙って働けよ」と思われるんじゃないでしょうか。(私個人の意見です)

 

自信ない態度や「私素人なので..」といった、謙遜のつもりで出した言葉は、優しい人にも厳しい人にもマイナスイメージしか与えません。なんというか、とにかく自分を下げるような発言は極力避けた方がいいでしょう。

 

※口を滑らし、「文系出身なので...」というワードを一度だけ出したことがあるのですが、リーダーが凄まじい嫌悪感を表していたのを今でも忘れられません。

 

②コミュニケーションのHubになる

今はリモートワークの現場に入っていますが、オンラインMTGは対面よりコミュニケーションが荒削りになります。

 

会議の中で分かりきった事でも「結論として、XXの使用はXXでいいんですね?」と声に出して発言することで、その場の全員が要約された結論を意識することができます。自分の中ではXXだ!と理解していても、人によっては違う解釈をしている事もあるので、あえて一度言葉に出すことで、認識の齟齬をあぶり出すことができますね。

 

また、グループチャットで都度「XXさんからXXの仕様についてXXというお話を伺いました。念の為共有させていただきます」と書いたり、PMと話す機会があれば今のpjの作業進捗を具体的に説明したり...

 

他の人が伝え漏れたり、見落としがちな情報を、自分起点で集約して共有するように振る舞うと、これが意外とチームの助けになります。自分がコミュニケーションのHubになる、という意識が近いかな...

 

「いちいち分かりきったことを口に出さなくて良い!」と怒るような人が周りにいれば、そういう人に限って見落としやミスコミュニケーションを起こしがちなので、より注意して情報の集約に努めましょう。最終的に、その人以外の周りの人から感謝されますよ。

---------------------------------

コミュニケーションばっかりですね...技術的な面なら、書籍の通読や既存ソースの読み込みでなんとかすりゃいい、位しか思いつかないですが、結局業務をスムーズに進めるなら円滑なコミュニケーションをとるのが一番手っ取り早いと思います。

チャット / 口頭ベースの情報の齟齬が、えらい事故の原因になるなんてしばしば...

 

何より、「1日8時間 週5日 は嫌でも仕事しなきゃいけないんだから、せめてその時間くらいは皆で気分よく過ごしましょうよ」 というマインドを持つといいですね。

 

ジュニアもベテランも、周りと良いコミュニケーションを取っていれば誰か助けてくれるし、建設的な対話が生まれて、より短い時間で物事が好転するでしょう。

 

規律を守りつつ、助け合いができるチームに貢献できるよう、私はこれからもいい子でいようと思います。

 

ただ、今後もこんな記事ばかり書いてると技術者として恥ずかしいので、もっと技術的な内容も発信するように努めます...

 

おわり!

恥を忍んで帰って参りました

なえTです

 

元々 iOSエンジニアを目指して独学でアプリ開発してリリースし、

SES企業に入社したらいつの間にかバックエンドエンジニアになったとです。

 

→リリースしたアプリ

Yotteko

Yotteko

  • Daisuke Doi
  • ナビゲーション
  • 無料

apps.apple.com

→未経験転職でつかったポートフォリオ

https://kyadx7.wixsite.com/naetos---workspace

 

メインの使用言語が古すぎ(Classic ASP / 2000年でリリース終了)て、

人と知識を共有する機会もなく、またその必要もねーかと思い

情報発信とか全然していませんでした。

 

エンジニアとして働き始めてちょうど1年が経ち、キャリアの棚卸しをしていた所

自分が何をしていたか、対外的に説明するための材料が全然ないことに気づき、またブログ書こうかと思った次第です。

 

参画先の情報漏洩にも繋がるし、あんまり細かいことは書けないですが

トラブルシューティングや、初参画の現場でどう役に立とうと頑張ったかなど

そういった事を書いてみようと思います。普通にブログですね。

 

じゃあの

NotionのAI自動入力 簡単に止めれそう

拙僧Notionをよく使っているのですが、何も入力していない行でSpaceキーを押すとAI入力モードになるのが邪魔で仕方がないと思っていました

 

この機能をオフにする(Notion AIの無効化)には、Notionのサポートチームに直接止めるよう連絡をしなければならないとのこと

 

めんどくさそうと思っていたが、Notionデスクトップアプリから簡単に連絡できたので備忘録

 

①右下のはてなマークを押して、Message supportを選択

②チャットでAI入力を止めたいと伝える


以上

チャットボットとの会話中、ワークスペース名やメールアドレスを尋ねられるので、それに応えると解除作業に移ってもらえる。

最後に"担当チームからメールで連絡します。"とチャットで回答がくるので、このメールが届けば作業完了なのだろうか

 

こんなに楽なら早く申請すればよかったーー

Swift selectorってなんぞや

なえTです

 

現職が異次元の忙しさに入り、家でも家事をしなければならず、

色々ままなりません

コード書くだけの時間を1億時間ほしい

 

Udemyで経路を描写するMapアプリの作り方講座を購入して触っています。

この講師の方はUIKitでもIB一切使わずコーディングしてくれるので性に合っています

自分も転職用の自作アプリ作ったら、今後はSwiftUIに移行しよう

 

今日はわすれがちなSelectorについて書きます。

 

例によって人様のブログを参考にしてます、恐縮です

さながら羅生門のババアのようになんでも拝借します

 

tetoblog.org

 

 

#selector 

 

Objective-Cに存在していた メソッドのようなもの(メソッドを起動させるためのメッセージデータ)

#selector( done ) と記述すると、done()という関数が使える

引数 action:にメソッドを投入したいときなどに使う。

 

 

@objc

 

Selectorでよびだすfuncは、@objcと先頭につけて宣言しないといけない。

これをしないとコンパイルで事故るらしい

@objc と記載されたfuncを書く際は、基本的にobjective-Cの仕様に沿った使われ方(selectorなど)をされ、そのときのお守りみたいなように考えれば良い

 

 

じゃあの

Swift staticの効果

構造体/クラス内で定数を宣言する。

 

struct Hoge {

 let hoge = hugahuga

 }

 

この定数をクロージャ外で呼び出す際、通常は構造体/クラスをインスタンス化させないと呼出できない。

 

let hoge = Hoge()

print (hoge.hoge)

//実行結果 hugahuga

 

しかし、構造体/クラス内で定数を宣言する際、前にstatic と記載すると、インスタンス化しなくても直接"型名.プロパティ"と記載することで呼出可能になる。

 

struct Hoge {

 static let hoge = hugahuga

 }

print (Hoge.hoge)

//実行結果 hugahuga

 

これは、構造体/クラス内で宣言した定数が、通常はinstance propertyとしてインスタンスに関連付いて登録される所、staticがついた定数はtype propertyとして型自体に登録されるため、インスタンス化しなくても呼出可能となる、ということ。

Model内で生成したColor構造体や、Constant構造体(ID等を保管する場所)が持つプロパティは、staticをつけて定数を宣言することで、他のクラスで呼び出しやすくすると吉

 

ちなみにstaticはメソッドにも使える

struct Hoge {

 static func hoge(){ 

    print (hugahuga)

 }

Hoge.hoge

//実行結果 hugahuga

Pods iOS Simulatorとのバージョン不一致エラーを解消

正月から次の3連休までぶっつづけで本読んで、経路作成アプリを作ろうとした所、location取得に際する非同期処理とマップ描写のタイミング合わせがうまくいかず、心がへし折れて入門書をやりなおしていたなえTです。

 

前回の学習ではちょっとしか触れなかったFirebaseを触り直しているのですが、PodsでFirebase SDKをインストールした際、各ライブラリのiOS最低要件 < iOSシミュレーターの実行可能なOS となり、Xcode上でグワシャーっとエラーが発生する件が気になったので解消法を調べました。(人様のサイトから情報をいただき恐縮です)

 

www.yururiwork.net

 

 

ライブラリの導入に使用した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
 

 

さあ頑張るぞ

 

 

Swift 実機ビルドエラー Signing for "gRPC-C++-gRPCCertificates-Cpp" requires a development team.

 

大したことでもないのですが、一応書いておきます

どうやらXcode14で実機ビルドを行うと、CocoaPodsに対してSigning(署名)の設定をしていないとエラーを吐かれるようです

この場合、上記のTeam 選択肢をNone -> 自分のチーム名に変更することで、ビルドが通るようになります。 エラーに書いてるまんまの対処法になりますが、突然エラーがでてびっくりした人(自分)の備忘録として。

 

 

 

 

おまけ

Q. さっきFirestoreのデータベースへの接続テストを行ったところ、認証エラーになりました。なぜでしょう?r

 

 

A.Firestoreへの接続期限を適当に設定したところ、6月に31日は存在しないためエラーになっていたようでした アホかな?

 

手作りおせちに気合を入れすぎたということにしておきましょう

皆様あけましておめでとうございます。今年も1年ご安全に!