ミーティングのデッドコードを見直す - nakaoka3の技術ブログ
開発チームの定例ミーティングで、式次第のテンプレートにはあるのに飛ばしているアジェンダがあった。１年以上、２週間に1度は目にしていたはずなのに今まで気に留めてもいなかった。 今開発しているサービスは、リリースしてから８年以上の歴史があるプロダクトで、開発メンバーの入れ替わりも多い。１年前と今ではほとんど顔ぶれが変わっている。そういう状況なので、存在するけど誰も気に留めていない幽霊みたいなアジェンダが生まれてしまったのだろう。 普通のプログラマなら自分の開発しているプログラムの中にデッドコードがあったら迷わず削除する。ミーティングで飛ばされてるアジェンダに対しても、消すか飛ばさないようにするかどっちかにした方がいいだろう。リファクタリングに似ているな、とふと思った。 デッドコードの場合は削除してもいいか自明だけど、ミーティングのアジェンダは消して問題ないか事前に知ることが難しい。あとコードを
Google スプレッドシートのテーブル機能が便利 - nakaoka3の技術ブログ
最近スプレッドシートを開くと、右側に「表」という良いされたテンプレートがおすすめさるれ。これを使って挿入された表を見ると「テーブル」という機能が使われている。「テーブル」とは、カラムに型をつけたり、テーブル名で参照できるようにする機能だということが、調べてみるとわかった。 スプレッドシートを新規作成すると右側になんかある 範囲をテーブル名で選択する テーブルでない場合、注文された個数の平均を計算するのは、以下のようにセルで範囲を指定する必要があった。 =AVERAGE('シート1'!$C$2:$C$6) それがテーブルだと、テーブル名とカラム名によって範囲を指定することができる。以下の例ではテーブルに orders という名前をつけている。「個数」が列の名前だ。 =AVERAGE(orders[個数]) 普通のプログラミング言語の連想配列(辞書、マップ、ハッシュ）から値を取り出す操作に似て
YAPC::Kyoto 2023 参加 感想 - nakaoka3の技術ブログ
YAPC::Kyoto 2023に参加しました。Perlはここ数年仕事で使っているので初めて参加してみました。Japan Perl Associationが主催するカンファレンスですが、Perl以外の話題もたくさんあり刺激になりました。 yapcjapan.org デプロイの歴史についての話がありました。CGI時代のことは知らないし、あらためて自分でやる機会はないと思うので勉強になりました マルチテナントの話はまさに仕事で直面している問題なので、自分ごととして聞くことができました。 Honoの話は、Bunによって一気に人気になったというストーリーがおもしろかったです。複数のルーターを実装している話も興味深かったです。 ChatGPTの話題がいくもありました。今一番関心がある話題なので、話が聞けてよかったです。 大西さんによる熱いキーノートも刺激になりました。 ところで久しぶりに、物理的に人
『Go言語プログラミングエッセンス』は最新ベストプラクティスがまとまっていてGo初心者によさそう - nakaoka3の技術ブログ
今月からGo言語を仕事で触り始めました。Go言語についての知識不足が不安なので、『Go言語プログラミングエッセンス』という先日発売された書籍を読んでいます。自分のようなGo初心者にちょうどいい、かつ実用的な情報がまとまっている本でした。 gihyo.jp この本の想定読者はおそらく、すでに他のプログラミング言語を習得してこれからGoを触り始める人や、一通りGoの文法を学んで、本格的に開発で使っていこうという人なのだと思います。 開発環境、webアプリケーション開発に必要なパッケージ、テスト、ベンチマーク、DBの扱い方など、これから開発で使う人がちょうど知りたい内容がまとまっています。 以下が目次です。 第1章 プログラミング言語Goとは 第2章 開発環境の準備 第3章 基本的な文法 第4章 基本テクニックとベストプラクティス 第5章 Webアプリケーションの開発に必要な要素 第6章 速いプ
最短時間で読めるように、認知負荷が高すぎないコードを書く( 『リーダブルコード』『プログラマー脳』) - nakaoka3の技術ブログ
コードは他の人が最短時間で理解できるように書かなくてはいけない。 『リーダブルコード』 p3 今週、機能開発をしているプロダクトのコードを読んでいて、理解が難しく時間がかかってしまい、頭を悩ませていました。 何かヒントになるものはないかと『リーダブルコード』を眺めていて、「コードは他の人が最短時間で理解できるように書かなくてはいけない」という一文を見つけました。 www.oreilly.co.jp コードが「読んで理解できるか」にとどまらず「最短時間で理解できるか」という、積極的な目標になっているのが気に入りました。 既存のコードベースに機能追加するとき、既存のコードで理解に時間がかかるコードがあっても、目的の変更には直接影響しないし、そこを改善するには後回しになっていました。 その結果、リファクタリングはしたいと思っているものの、リファクタリングに使う時間を確保できないということがよくあ
新チームに異動したら、とりあえずPull Request を作るのがよさそう - nakaoka3の技術ブログ
新しいチームに入ったとき、最初に軽めのタスクをもらえると、Pull Request を作ってCIのテストが落ちることで、開発に必要なことが色々と知れるので便利です。 会社で異動があって、2/1付で別のチームに異動になりました。 軽めのタスクをもらって、とりあえずこの辺を変更したらいいかな？くらいで変更して Pull Reqeuset を作ると、CIで実行しているテストが失敗して、このファイルの変更をしたらスナップショットを更新しないといけない、GraphQLのスキーマファイルを変更するとGraphQL Code Generator で型生成をしないといけない、というようなことを指摘してくれます。 最初に全部の説明を聞くのは疲れるし、聞くだけで理解するのは大変です。説明する方も大変だと思います。作業しながらテストが落ちる様子を見ながらやると、手を動かしながら、コードを見ながらなので頭に入って
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
