Table Storage は null 値でクエリできないよ
タイトルのとおりなのだけど 、SQL Server でいう where hoge is null みたいなクエリができない。
アプリケーションのユースケースとして null でクエリしないようにする、というのはもちろんだが、運用で「このカラムが null のものだけ調べたい」みたいなこともできないので注意。
そもそも思想として null を入れないようにすべきなのだろうけど not null 制約などはかけられないので実装レベルで気をつける必要がある。
とくに困るのは、あとからプロパティが追加された場合。プロパティの追加はマイグレーションが必須ではないので、新たなプロパティを持つレコードが追加されたら古いデータはそのプロパティに null をもってしまう。こうなるとプロパティが追加される前のレコードか後のレコードかが判別できないので、プロパティ追加前のレコードのみマイグレーションをかける、みたいなことができない。
教訓
- 不用意にプロパティを増やしてはいけない
- プロパティを増やす場合には、事前にマイグレーションするか、プロパティが増える前のレコードがどれかをわかるようにしとく
「テックリード」を比較する
テックリードってなんなの？の比較
ここ2年ほどでテックリードという役割をもつテック系企業が急増しています。
うん、テックリードね、技術のリードでしょ。
...うん。
アーキテクトとは違うのかな。なんか微妙にニュアンス違うよな。リードっていってるからマネジメントっぽいこともするのかな。
実際、テックリードとは何か、を語る資料はいろいろあります。なので記事を引用して比較してみます。
(なんだかもったいぶった導入になってしまいましたが、大した結論がある記事ではありません。。)
まず、いま Google 検索から テックリード でトップでヒットする記事がこちら。
本文で言及されていないので私の推測ですが Takamatsu さんが株式会社アカツキでテックリードを務められていたときの話に基づいているようです。
テックリードに求められるのは一言で言えば”技術でエンジニアチームをリードすること”である。
強調しておきたいのは、テックリードはマネージャーではない、ということである。
また @higepon さんのトークを取り上げた上で、テックリードの主な責任範囲は以下の3つであるとしています。
- コードの品質
- チームの生産性
- アーキテクチャ・設計
つづいて tech lead で Google 検索して上位にヒットするこちらの記事。
Kakovskyi 氏が Atlassian Stride / Kyiv Polytechnic Institute / Video Internet Technologies Ltd でのテックリードの経験に基づいて述べています。
彼の最初の考えは「テックリードはソフトウェアアーキテクトとチームリーダーを足したようなもの」でしたが、いまの彼の定義では誤りのようです。
最後に挙げられている「チームリーダーとテックリードの違い」「アーキテクトとテックリードの違い」がシンプルに表現されています。
- チームリーダーはプロジェクトではなく人物に責任をもつ。
- チームリーダーはピープルマネジメントを行う。
- チームリーダーは個別の貢献をすることを想定されていない。
- アーキテクトはより実践的かつ多様な経験をもつ。
- アーキテクトはより広範囲で複雑なシステムに対して求められる。
- アーキテクトは、残りのチームメンバーが作業できるようにするためのもっとも面倒な作業を担当する。
また、テックリードに求められるスキルとして以下を挙げています。
- プログラミング言語に対して実践的なスキルをもつ
- データストアに関する一定のスキルをもつ
- マルチタスクを伴うプロジェクトマネジメントのスキルをもつ
- ほかメンバーに技術的な作業をさせるためのコミュニケーションスキルをもつ
ほかにも、本文では具体的な話がいろいろと書かれています。日々の達成感を味わいづらい、というのは世知辛いものですね。
こうしてみると先述の Takamitsu さんの記事で言われていた「テックリードはマネージャーではない」という表現に違和感を覚えます。個人的な感覚ですが「マネージャー」という言葉がだいぶネガティブに響くことが関係しているような気がします。
なぜ「マネージャー」がネガティブに響くか。それは "マネージャー" によるマイクロマネジメントによってもたらされる疲弊、でしょうか。過剰なマネジメントによってメンバーは疲弊する、プロジェクトは結果的になんとかなってしまったため成功体験として "マネージャー" はそれを繰り返す、といった悪循環が世のいろいろなところで起きている。
興味深いことですが、書籍「エンジニアのためのマネジメントキャリアパス」では、時として (ジュニアメンバーに対しては) マイクロマネジメントも仕方ないことがある、と述べられています。そのバランスが難しい。
で、この「エンジニアのためのマネジメントキャリアパス」は「マネージャー (というかマネジメントを行うということ) ってキャリア選択も悪くないよ！！」と語りかけてくれます。残念ながらこの記事を書いているいま私はテックリードとは何かという問いに結論を出せていないのですが、テックリードはメンバーのマネジメントにも責任をもつ、ということは言ってもよさそうです。
消化不良で反省。。。またの機会にリベンジします。
人事になりました
入社から2年9ヶ月、エンジニアとしてプロダクト開発に取り組んできましたが、12月からは人事としてエンジニアの採用に専念することになりました。
なんで？？って100000回きかれているので改めて考えをまとめておきます。
キャリアを積むにあたってエンジニアのままでいくか
これは長年考えていることです。エンジニアリングは楽しいし、やりがいもあるし、ありがたいことに給料ももらえています。しかし、自分の強みがエンジニアとして活かせるか、自分が本当にエンジニアリングを好きなのか、という問いに対しては依然として迷いがありました。
勘違いされたくないことですが、ぼくは自身に対していろいろな面で常に問いをもっていて、その一つとしてエンジニアとしてのキャリアがあった、ということです。決してエンジニアとしてやっていく自信を失った、というわけではありません。むしろ、これから人事として幅広くエンジニアに会い、彼らがもつ新しい知識、技術の取っ掛かりから、自分のエンジニアとしてのスキルも広めたり深めたりすることにも使いたいです。
不連続な意思決定
先日、当社の社長と飲む機会がありました。そこで「最近オマエ悩み無い？」という話になったときに上記のような話をしたところ「人事いって採用やったら？」という提案を受けました。
私は岡本太郎の、人生は積み重ねるものではなくすり減らしていくものだ、という考え方が好きです。採用というキャリアの選択は脈絡がなく不連続なものですが、だからこそ、人生をすり減らす良い機会だと感じました。
組織として必要なポジション
これまで当社には、エンジニア出身で人事部専任の社員がいませんでした。当社はプロダクトの会社であり、これからどんどん拡大しようとしています。そのなかで優秀なエンジニアを採用していくためには、エンジニアリングを知っている者が採用に全力で取り組むことが有用だと、客観的に考えました。また、私は特殊な存在であることを好むので、そういった意味でも主観的に得をすると考えました。
面白そう
そして何より、素直に面白そうだと感じました。個人と対峙し、彼、彼女の人生に一部責任をもつこと。マスに向けて自社の魅力を伝えること。社内に向けて、あらためて自社で開発に従事できる喜びを共感できるようにすること。
と、夢のある話ばかりしてきましたが、成果を出さなければ意味がありません。いろいろやるべきこと & やりたいことがあるので、やっていきます！！！！
IT 勉強会の司会を担当したので心がけたことメモ
↓ で司会を担当したので忘れないうちに心がけたことをメモする。
カミカミだったのは、ご愛嬌。もっとゆっくりしゃべろ。。
開始前
- 静かだと居心地悪いので BGM があるとよい。
- 来場者への挨拶大事！！受付直後に挨拶 & 案内要員がほしい。
- WiFi の SSID / パスワードは表示されっぱなしが望ましい。 WiFi 情報とトイレ場所と注意事項なんかをアニメーションで切り替えながら投影しているパターンをよく見るが、かなりの確率で見落とされる (気がする) 。
開始のあいさつ
- 会の方向にもよるが、アイスブレイク重要。サクラを仕込んででも笑いを取るべき。発表者も来場者も緊張したまま発表に入ることを避けたい。
発表
- 発表前と発表後の拍手！！個人的には食い気味くらいが好き。
- 発表の切り替えをどうするか。発表者同士がマイクを受け渡すのか、司会が中継するのか。発表者が発表後に戸惑うと格好悪いので、司会はよく発表者の様子をみて、そうなりそうだったら素早くマイクを中継するようにする。ちなみに、この瞬間に沈黙が訪れるのが個人的に嫌なので、司会は一言コメントを挟むのが好み。
- 休憩を挟む場合、急に静かになると気まずい。ここでも BGM があったほうがよさげ。
懇親会
- 転換が必要かどうか事前に判断しておく。
- いろんな人と会話できるようにするため立食がよいだろう。
- 一人になってる人がいたら話しかける。
締め
- 司会は飲みすぎない。
- 酒が入るとだいたい盛り上がる。終了したい時間の10分前には「あと10分で終わるよ」のアナウンスを入れる。
- アナウンスはゆっくりしゃべるのが大事。「なんか喋ってんな～」を気づかせるため。また、全員が静かになるのを待つ必要はない。静かになっちゃうと次に話し始めるのが気まずい。
- 本当に締めるときは「ありがとうございました～」で、拍手。
- 締めたら BGM を流し、片付けを始め、帰ってねオーラを出す。
技術力向上だけに固執するのもダメかもしれんけど技術力も当然大事だよという話
先日、弊社CTOのインタビュー記事が軽くバズっていました。
ちょっと自分と考え方が違う、あるいは誤解されてそうなことがあるので書きます。
この記事で主張されているのは、「プロのエンジニアなら、経済価値に直結するコードを書くべき」とあるように、技術は価値をもたらさなければ、自己満足に過ぎない。つまり、技術力向上のみを目的としていて、価値をもたらすことを放棄してしまったエンジニアはダメだ。ということ。
ここで邪推されがちなのが、「では経済価値を生むのであれば、どんな汚いコードやアーキテクチャでも良いのか」ということ。これは決して真ではない。論理の誤謬だ。大事なのはバランスだし、かつ、「コードが経済価値を生むかどうか」と「コードが美しいかどうか」は純粋なトレードオフではない。
ここで技術者のちからが生きてくる。いま経済価値を生み、かつ美しい、すなわちメンテナンス性が高かったり不具合を起こしづらかったりするコードやアーキテクチャをいかに作るか。
記事にある、「世界で戦える事業」を支えるプロダクトは、2,3年で出来上がるようなものではなく、長期に渡って変更を繰り返すことが求められる。そこでは高い技術に基づく美しいコードやアーキテクチャが必要。これは弊社 CTO も当然認識しているはずだし、弊社の多くのエンジニアが共感してくれることだと思ってます。
そのためにはやっぱり技術を楽しむことが大事だし、新しい優れた技術を身につけることも必要。
尖った記事は、ただそれだけの断面を切り取られてバズりやすいけど、その根底には暗黙的に大事にされることがあるわけで。はてぶブコメから引用させていただくと、
シリコンバレーで働いて気付いた「技術力向上」だけに固執するエンジニアのダメさ【Sansan CTO 藤倉成太】 - エンジニアtype | 転職＠type
結局ベースにそれなりの技術力があって言える話しだからねこれ。前面に技術の話が出てこないだけで裏ではちゃんとキャッチアップしてるわけで。
2018/11/28 07:32
そのとおりです！！
vue で日付選択ドロップダウンリスト
ひとり Advent Calendar 今年もやります。ネタはやりながら考えます。
去年のぶんはこちら
vue で年月日をドロップダウンで選択する。よくみる UIで だけど各月が何日まであるか？を出すのが意外と面倒。
うるう年とか考えたくないのでそのへんは Moment.js にお任せしました。
あと、年や月が変更されたときに日が存在しなくなることがあるので最終日にするなどしてみた。
js の Date オブジェクトもそうだけど内部的には月が 0 始まりなのがハマりどころ。
もっとシンプルなやりかたがあるような気もしつつ。
ひとりタスクボード
2日目です。
タスク管理について。
僕はこれまでは、おもに Todoist と Google Calendar でやることを管理してました。
Todoist は Toggl と相性がよく、ポモドーロテクニックに向いているのが個人的に気に入っていました。
ただ、最近以下の事情により、ちょっとやり方を変えてみることに。
- 細切れのタスクが増えてきた。
- 細切れのタスクがたくさんある場合、ポモドーロテクニックはあまり効果的じゃない。
- 実際の作業はかなりの割合で PC で行う。タスク洗い出しやステータス変更などの行為を実際の作業を切り分けたい。
というわけで、物理的なタスクボードを使うようにしてみました。何年か前にも使っていたのですが再導入です。
ホワイトボードに区分を用意して、タスクをふせんで貼っていくというもの。区分は以下のとおり。
today
今日やるタスク。
future
いつかやるタスク。
doing
いまやってるタスク。
waiting
他者がボールをもっているタスク。
done
その日に終わったタスク。
よくあるタスクボードは todo / doing / done の3つの区分ですが todo の数が多すぎると優先度がわからなくなる and モチベーションが下がるので today と future で分け、また人に渡したタスクの扱いが所在なくなるので waiting を追加。というアレンジを加えています。
僕はもともとタスクの洗い出しとか何か考える際はプロジェクトペーパーを使っているので、その流れでタスクをふせんに書き出す、というのが自然にやれています。集中するポイントの転換にもなる。
課題は、 future がいつまでも残り続けること。。だいたい7つの習慣でいう第2領域なんですけどね。。
