ひとりアドカレ最終日
Dear Great Hackers, Merry Christmas🎄
本記事は、「はじめてのひとりアドカレ2024 by hayami」の最終日Day25の記事です。
ひとりアドカレ完走だ！
アドカレを書きながら思ったことを取り留めもなく書き溜めてきました。
以下、成仏します。
初めてアドカレを書いてみて思ったこと
(と、少しのアドバイス)
どんな経験・技術記事であれ、技術記事や体験・経験を執筆してくれている人達への愛と感謝が湧いた
- さまざまな動機があるかと思うけれど、どれも本当にありがたい
- トントン拍子なエピソードも、そうでないエピソードもありがたい
読み手は書いている側の心持ちよりもかなりライトに読んでいることが多いため、気張りすぎなくていい
- 思えば、自分も誰かの記事に対して「正しいかジャッジしてやる」のような好戦的な気持ちで読むことはまずない
- 参考にならなかったら「参考にならなかったな」と思うくらい
- というか、そもそも感情が湧く間もなくざらーっと見ていることのほうが多い
- はじめはどこからか矢文やマサカリ（？）が飛んでくるかも… と思っていたけれど、相当突飛なことを書かない限りは飛んでこないので大丈夫
記事が読まれない = あなたが嫌いなわけではない
- 記事を書く前は思いもつかなかったのですが、記事が読まれるかどうかは記事が良質である・ちゃんと書かれている、という側面もありつつ、読み手との関連性があるかどうかの方に依存している
- たしかに自分も「ああこれきっとすごくいいことが書いてあるんだろうけど、自分の触ったことのある分野ではないしよくわからない（でもリスペクトはとても感じています）」という状態がかなりの頻度で生じている気がする
- 加えて、Qiitaのアルゴリズム上いいね！のたくさんつく記事はホーム画面に表示されるが、そうでなければ自分の付けたタグ or 自分をフォローしてくれている人の範囲にしか基本的に記事を届けにくい仕様になっている
- というか自分も全然今日書かれたすべての記事を追うとかできていないし…
書き手がどのくらい意気込んだかと記事がどのくらい評価されるかは、結構因果予測がむずかしい
- 意気込んだことが刺さらなかったり、気軽に書いたものが刺さったり
アドベントカレンダーに関しては、いいね数を気にするのは正直あまり意味がない気がする
- Qiitaの仕様上、技術記事としてQiita以外の媒体のURLをアドベントカレンダーに登録することが許されている
- となると、そもそも別媒体に書かれた記事にはいいねという概念自体が発生しないし、その結果、もちろんそのアドベントカレンダーにもいいね数は反映されない
- 記事の内容がQiitaに書いていればいいね！がつくようなものでも、いいね換算されることはない
- 私は4日目くらいまでは自分のアドベントカレンダーがカテゴリ何位かな、と結構気になっていたんですが、4日目くらいでこのことに気付いて確認しなくなりました
1記事書くのに平均1～3Hかかる
- 自分の中ですでに言語化・構造化できているものを書くときは1～1.5H程度(私の場合)
- インプットや調べもの込みで書くと2～4H程度かかる
ぱっと見の印象が大事
- 記事に画像が含まれているかどうか
- 文字だけの記事って、結構体力が必要そうな印象を与えているように思う
- 生成AIで作った画像を埋めてみたり、文字色を変えてみたり、絵文字をつけてみたりするとより良い
- 記事にコードが含まれているかどうか
- Markdown記法が崩れていないかどうか
- 構成がわかりやすく読み手を意識している印象を与えるかどうか
- 大項目・中項目などシャープで書く項目はちまちま書いてしまいがちだが、ぱっと見の大胆さが大事
- 2015～2016年頃のQiitaの記事は無骨でも2桁いいねのコンテンツがたくさんあるようだけど、コンテンツがインターネットに飽和している2024年現在、いかにアテンションを引けるか勝負が正直ある
- 技術記事とは、という気持ちではあるが…
ポエムは別媒体で書くと心理的に楽かも
- これは私はそうするようにしたよ、というだけの話なのですが、一応Qiitaのコミュニティガイドラインの一番上に「エンジニアにとって再利用性・汎用性の高い情報が集まる場をつくろう」と書いてあったため、俗にいう「ポエム（自分の見解や技術的再利用性の高くない知見）」は個人ブログの方に書くようにしました
- エンジニアが共感できる物言いはいいね！がたくさん付きやすいのですが、反面可燃性が高くもあるので…
記事執筆が遅れてもいいので、とにかく25日23:59までに書く！
- フルタイムで働きながら毎日記事を書くのは割とタフなこと
- 書いているだけえらいと思って諦めずに完走するのが大事
- 私は最終日に8記事書きました
- 真似しないようにしましょう
書いた記事一覧
Day1 ：アドカレ初参加の意気込み -はじめてのひとりアドカレ2024 by hayami
Day2 ：基本情報・応用情報を合格した1年後に思う、両試験を勉強してみてよかったこと
Day3 ：難解なコードを見た時にまず何を考えるか
Day4 ：【C#】8年越しでも愛が生まれた
Day5 ：【C#】Randomクラスで重複のない乱数を生成する方法３選
◆◆◆
Day6 ：『ノンデザイナーズ・デザインブック[第4版]』を読んだメモと、デザイン時の個人的チェックリスト
Day7 ：【技術書典17】初参加＆初寄稿の記録
Day8 ：【React】リコンシエーションの基礎について理解する
Day9 ：【Oracle】DBリンクを使ってテーブルのリフレッシュを手軽にDELETE/INSERTで行う
Day10：【DB設計】スキーマを分けるシチュエーション
◆◆◆
Day11：CSSすこし書ける人が考えていること・気をつけていること
Day12：アーキテクチャパターンとデザインパターンの違いと、それぞれのスコープを理解する
Day13：SQL発行回数を増やすかLINQで絞るか
Day14：データベースのレプリケーション(物理レプリケーション/論理レプリケーション)
Day15：アプリケーションの設計アンチパターン：BBoM（Big Ball of Mud / 大きな泥だんご）
◆◆◆
Day16：【C#】文字列結合時とStringBuilder使用時のパフォーマンス差異
Day17：viodのふるまいと思い出
Day18：勉強/開発/作業中によく聴くSpotify Playlist 3選
Day19：普通のデスク周り_20241225
Day20：「アジャイルことはじめ」のようなことをどうインプットするか
◆◆◆
Day21：技術書を読むときに心を折らないために心掛けていること
Day22：技術Podcast "Rebuild.fm"のすすめ
Day23：【C#】try~catchを2重にして通信の処理を待機する
Day24：仕事中いまいちパフォーマンスが上がらない時のTips
Day25：アドカレ完走の感想と少しのアドバイス -はじめてのひとりアドカレ2024 by hayami
まとめ
記事の書き溜めもなく、見切り発車で始めたひとりアドカレでしたが、無事完走することができました。みんなもひとりアドカレをしよう！（ひとりアドカレは計画的に）
