本当の意味で仲が良い人
一定の距離を置いて付き合った方が仲良くできる人もいるけど、それって本当の意味で仲が良いと言えるのだろうか🤔 なんて考えてる
— Og🌗エンジニア🏝宮崎 (@koogawa) 2018年2月8日
数日前にこんなことをつぶやいたのだけど、なんとなく答えが出たのでメモしておく。
結論から言うと、それは本当の意味で仲が良いとは言えないと思う。適当な距離を置きながら付き合ってうまくやれたとしても、それは所詮、建前上の関係なんだと思う。
じゃあ、「本当の意味で仲が良い」とはどういうことなのか?
ひとつは仕事で長い間(少なくとも半年)一緒に働いてもうまくやれている人。人は一緒に働くと、だんだんその人の悪い部分が見えてくる。逆に言うと、しばらく一緒に働いてみないとその人の悪い所は見えないと思っている。(だから採用活動というのは難しいんだろうな)
もちろん悪いところがひとつもない人間なんて滅多にいないだろう。お互い悪いところを認めた上で、時には衝突しながらもうまくやれている人は仲が良い関係なんじゃないだろうか。
仕事で関わらなければうまくやれただろうなぁ、って人もたくさんいる
— Og🌗エンジニア🏝宮崎 (@koogawa) 2018年2月8日
一方で、一緒に仕事をする前はすごく仲が良かったのに、同じチームで仕事をしてみたら本当にいろいろと合わなくて、最終的に仕事以外ではお互いを避けるようになってしまった人もいる。
「この人と一緒に働いてみたい」とずっと憧れの存在だったのに、いざ一緒の会社で働いてみたらずいぶん印象が違ってがっかりした、なんてこともあるかもしれない。この場合は最初から無理に近づこうとはせずに、ずっと憧れの存在のままでいられたほうがお互いにとって幸せだったのかもしれない。
*
なんか薄っぺらい記事になってしまったけど、今日書きたいことは以上です。
2018年の目標
気が付けば2月になってしまいましたが、今年の目標を書いてみます。
基本的に仕事をしてる時以外と、帰宅後に子供が起きている時間は育児に集中したいので、その条件下でもできる範囲で目標を設定しました。
Stack Overflowで5000 reputationを目指す
以前から続けているスタックオーバーフロー活動を今後も続けていきます。そして、今年中に 5000 reputation を達成したいと思います。
reputation が 5000 に達すると、"Approve Tag Wiki Edits" 権限が付与されるようですが、その解説はまた別の機会に。
ちなみに、https://stargzr.net/?service=stackoverflow によると、今現在、日本で 5000 reputationを超えているエンジニアは id:KishikawaKatsumi さんただ1人のようです。*1
日本語版スタックオーバーフローはやらないの?
たまに聞かれますが、以前もつぶやいた通り
日本語版スタックオーバーフローでちょこちょこ編集してたら、謎のチャット部屋に突然呼び出されて文句言われたし、本家と比較すると色々と悲しい感じである😩
— Og🌗エンジニア🏝宮崎 (@koogawa) 2017年9月28日
日本語版の雰囲気にはあまり馴染めずにいます。(いきなりチャットルームに呼び出しとか本家ではやられたことない)
また、英語の勉強にもならないので、なるべく本家Stack Overflowのほうに貢献していきたいと思っています。
公開しているライブラリのメンテナンスを続けていく
ちょくちょくこのブログでも紹介しているのですが、foursquare API 向けのクライアントライブラリを公開しております。去年は念願だった公式デベロッパーサイトで紹介してもらう、という夢をかなえることができました。
だいぶニッチなライブラリですか、ちょっとでも使ってくれる人がいる限り、今後もメンテナンスは続けていきたいと思っています。今年は Swift 5 対応が待っていますね!
リモートでも参加できる勉強会に参加する
昨年、東京から宮崎に移住したこともあり、東京で開催される勉強会への参加は難しくなりました。しかし最近はリモートで参加できる勉強会も増えてきているので、今後もそういった勉強会には積極的に参加していきたいです。そして、隙あらば運営にも携わっていきたいと思っています。
ちょっと宣伝
早速ですが、私も運営として参加している Swift Tweets 2018 Spring が4月14日に開催されます!
Twitter 上で開催されるイベントなので、気になる方はぜひチェックしてみて下さい。
*
若者のノリで「やっていき!」と叫ぶのはツラい年齢になってしまいましたが、今年もゆったりとやっていきます。
*1:もちろん全てのエンジニアがStargzrに登録しているわけではないですし、実際にはもっとたくさんいることはわかってます
jflute さんの日記が面白かったのでほぼ全記事読ませていただきました
私は面白いブログを見つけると、過去の記事まで遡って読む習慣があります。
最近、フィードに流れてきた
意外と忘れがちな優秀なプログラマーになるための10のコツ - jfluteの日記
の記事をきっかけに、id:jflute さんのブログ記事も全部読んでみることにしました。(1ヶ月以上かかりました)
今回は jflute さんの記事の中でも特に面白かった記事を僭越ながら紹介させて頂きたいと思います。
※ここで言う「面白い」とは「勉強になる」「気付きがある」という意味合いが強いです
→ 何をやるかよりも誰とやるか
これはなんかわかるんですよね。
→ 会社は好きなのに去る人
これほど切ないことはないですね😢
→ レスポンスのない人にリクエストは送らない
確かにその通り。
→ わかります。
→ あるあるですね。つらい😩
→ 良かったところは「良かった!」って言わないと知らない間に消えちゃったりするんですよね。
→ おおきなかぶ。とても良い例えだと思います。
→ 「なんで」はすごく大事。多少ウザがられてでも聞いていきたいです。
→ 自走できるディベロッパーでありたいものです。
→ 勉強会に行かないと成長しないわけでもないです。ただ、"機会損失" になるかもしれないね、 って思うのです
まさに点と線だと思いました。
→ ドキュメントだけで、オープンソースの比較はできないよ、というお話です。
→ 両方だいじ、なんですね。
→ 誰がダウンロードしたのかもわからない
これわかるなぁ
→ 破片プログラマーの最大の悲しみは、破片であることを自覚せずに成長してしまうこと
自分で脱出するしかない、と。
→ どちらを選ぶも自由です。
→ 聴いてる音楽がそのままその時期のBGMに
これすごくわかるんですよね。
→ 「既存コードに合わせて終了」の姿勢は、 プロフェッショナルとして、どうでしょう?
うーん耳が痛い😓
→ 関係ないですが、私は本屋に行くと必ずトイレに行きたくなります。
→ そういう人が身近にいる環境を作るためにも、やっぱり行動するしかないんですね。
→ わたしもディズニーランドからアプリのリリースボタンを押したことならあります。
→ これがホントの DDD(ディズニー駆動開発)なんつって。
→ 質問や相談をするときは「その問題領域の背景」も 添えましょう
違うところに問題があったりするんですよね。
→ 「いわゆる "ハマっている" 人の多くは、 分析し切れてないのに、 必死に解決方法だけを探っている」
→ 点と点をつなぐ、誰かの話と似ていますね。
技術の話題ではないのですが、次のエントリもすべて読みました。(その7まであります)
自分も同じ時期に行ったんだけど、あんなに人が少ないディズニーシーは初めてだった(確かいつもの来場者数の1/3だった) / “再開したディズニーシーに行ってきました - jfluteの日記” https://t.co/lDqmOVE1L0
— Og🌗エンジニア🏝宮崎 (@koogawa) 2017年10月24日
Jflute さんの記事は、最後に美しい写真で締めくくるのが特徴的ですね。(ディズニーの写真でしょうか)
今後も読ませていただきます。
【StackOverflow活動記】信頼度3,000に到達、クローズ票に投票する権限が与えられました
コツコツ続けております。
本日、reputation(信頼度)が 3,000 を突破しました🎉
このタイミングで「Cast Close And Reopen Votes」権限が付与されました。
Cast Close And Reopen Votes 権限とは
公式サイトに詳しく説明があります。
Privileges - cast close & reopen votes - Stack Overflow
いろいろ書いてありますが、要は
- 不適切な質問をクローズ(誰も回答できない状態にする)する票を投じることができる
- クローズされた質問を再オープンする票を投じることができる
権限です。
不適切な質問とは?
- 過去に同様の質問が投稿されている
- 不明瞭、範囲が広すぎる、またはその他の問題があり、回答が困難である
- Help Center に書かれているような、Stack Overflow の趣旨から外れている質問
がそれに該当します。
クローズされた質問はどうなるのか?
クローズ票が5票に達すると、[on hold]
という文字がタイトルに追加されます。新しい回答はもう受け付けられません。この間に質問者が質問内容を改善した場合、その質問は reopen されることがあります。reopen のフローは公式サイト に詳しく書かれています。質問内容が改善されずに5日が経過すると、[closed]
という文字がタイトルに追加されます。
次の目標
次は 5,000 reputation で付与される approve tag wiki edits 権限を目指します💪
私の Stack Overflow 活動はまだまだ続きます。
【StackOverflow活動日記】Create Tag Synonyms 権限が付与されました
コツコツ続けております。(StackOverflow活動とは)
本日、reputation が 2,500 を突破しました🎉
同時に「Create Tag Synonyms」権限を付与して頂きました。
Create Tag Synonyms 権限とは
タグの別名を作成できる権限です。
例えば iOS に関する質問をする際、ほとんどのユーザーは ios
というタグを付けると思います。しかし、人によっては ios-sdk
や apple-ios
といったタグを付けることもあります。これだと、iOS関連の質問を見つけるのが難しくなってしまいますね。そこで、Stack Overflow にはタグに別名(Synonym)を付ける機能が用意されています。
例えば、ios
には ios-sdk
, apple-ios
, iphone-os
という Synonym が登録されています。
Synonym を使用して質問するとどうなるか?
Synonym を使用すると、Master(本当の名前)に自動的に変更されます。例えば、ios-sdk
というタグを使おうとした場合、タグは自動的に ios
に変換されます。この時、ユーザーには変更があった旨は通知されません。
また、Synonym から Master への自動変更回数はカウントされています。これらは /tags/synonyms から確認できます。それぞれの Synonym がどれだけ役に立っているか評価できるわけですね。
◆
いやー Stack Overflow ってホントに良く出来てますねー
まず、失敗することを確認してから先に進む
これが正しい、とかを言いたいわけではなく、自分はいつもこうやっているよー、というのをメモに残しておきます。
ケース1
例えば、Aというアプリを動かすにはBとCのライブラリが必要、というケースがあったとします。 こういった場合、自分はまず、BとCのライブラリを敢えてインストールせずにAを動かそうとします。 そこでエラーが出ればBをインストールして試し、ダメならCもインストールします。
理由
素直にBとCをインストールしてから始めればいいものを、何故こんな面倒なことをするのか、理由を考えてみました。
1. エラーが起きた場合どうなるか把握できる
最初から成功してしまうと、エラーになった場合の挙動などを知らずに先に進むことになります。最初に敢えて失敗しておくことで、後々エラーが起こった場合、素早く対処することができます。
2. BとCがなくても動いてしまう場合がある
ドキュメントには「BとCが必要」と書いてあっても、試しに実行してみたら何の問題もなく動いてしまうケースがあります。その場合「何故動いたのか」を調べていくことになるので、結果的に知識を深めることができます。
ありきたりの言葉ですが、疑うことは大事ですね。
ケース2
iOSアプリ開発を例に挙げます。URLSession
を使ってHTTP通信するケースを考えます。
let task = URLSession.shared.dataTask(with: url!) { data, response, error in if let data = data, let response = response { print(response) } else { print(error ?? "Error") } } task.resume()
この場合もまずは次のことを試します。
url
に nil を入れてみるurl
に実在しないデタラメのURLを入れてみるtask.resume()
を実行しない
理由
1. データがおかしくなった場合の挙動を知っておけるので、後々エラーになったときに役に立つ
これもケース1とほとんど同じですね。最初に失敗しておくことで、
- アプリがクラッシュした → お、
nil
が混入しとるな - レスポンスが返ってこない → そもそもリクエストしてる?
といった対応ができるようになります。
2. いきなり成功すると不安になるから
「一発でビルドが通った」
これほど不安なことはありません。 この気持、わかってくれる方もいらっしゃるのでは??
まとめ
ここに書いた内容が、他の皆さんもやっている「当たり前」の進め方なのかはわかりません。だからこそメモに残してみました。 俺も同じだよ!などあれば教えてください。
【StackOverflow活動日記】MapKit: MKAnnotation の Callout がうまく表示されない問題
割と続いております。StackOverflow活動日記です。
さて、今日回答したのはこちらの質問。
私が得意とする MapKit 関連の質問です。
この分野で多いのが、
- 地図上にピンが表示されない
- ピンをタップしたときに表示されるバルーンが思い通りにならない
- ピンがドラッグできない
- 地図上に線が引けない
等の質問です。そして、そのほとんどが delegate プロパティのセット忘れや、delegate メソッドの実装漏れによるものです。
今回も「ピンは表示されるけど、ピンをタップしたときに表示されるバルーンにCallout(ボタンみたいなの)が表示されないよ」といった内容でした。
▲この右側のボタンが表示されないようです
コメント欄のやり取りを見ると、どうやら delegate プロパティにはちゃんと self
がセットされている様子です。その後、Stackoverflow のチャットルームに移動したようですが、解決には至らなかったもようです。*1
となると、次に疑うのは delegate メソッド(viewForAnnotation)の実装漏れです。質問文に載せられたソースコードをじっくり見てみると、どうやらちゃんと実装されている様子・・・いや、よく見てみると
func mapView(mapView: MKMapView!, viewForAnnotation annotation: MKAnnotation!) -> MKAnnotationView!
になっていました。このメソッドは Swift 3 で
func mapView(_ mapView: MKMapView, viewFor annotation: MKAnnotation) -> MKAnnotationView?
に変わっています。そのため、このメソッドが呼ばれず、Callout の設定も実行されずにいたようです。
その旨を回答したところ、無事問題が解決されたようです👍
***
Accept + vote up により、reputation が +25 されました。
2,500 まであと少し!がんばります💪
*1:Stackoverflowにはディスカッションのためのチャットルームが用意されている。20 reputation以上のユーザなら誰でも入室することができる