はじめに 時間管理が上手くなりたいと日々思っているため、このテーマにしました。 自戒の念を込めて😅 タイムマネジメントの王に!!! おれはなるっ!!!(CV.田中真弓) ※掲載内容は個人の見解であり、所属する企業を代表するものではありません。 参考にした書籍 『エンジニアのための時間管理術』 Thomas A. Limoncelli　著 株式会社クイープ　訳 発行年月日：2006年10月 ページ数：272 ISBN：978-4-87311-307-4 タイムマネジメントについての考え方や手法を取り入れたいと思い読みました。 時間管理した先のゴールは？ 自分のための時間・家族との時間を最大化する。 前提 エンジニアはタイムマネジメントが難しい。 プロジェクトワークと割り込みが入り混じる職業。 外部からの割り込みは生産性を低下させる。 中断した作業に戻るには時間がかかり、エラーが紛れ込む可能

1つのIssueが大きくなると1 Pull Requestで大量の差分が発生します。 そうなるとレビュワーに負担がかかり、コンフリクトの可能性も高まり、コードレビューを効率よく進めることができません。 このINVEST原則を守ることでチームはより効果的に作業を進め、柔軟に対応して開発を進めることができます。 Git Flow Git Flowは5種類(main, hotfix, release, develop, feature)のブランチを運用するブランチ戦略です。 2010年に提唱された有名なブランチ戦略です。 オンラインサービスのように継続的デリバリーするコードを想定して作られた戦略ではないです。 main ブランチ 常にリリースできる状態を保つ hotfix, develop へ切り出す このブランチへの直pushはNG hotfix ブランチ バグ修正など緊急時に対応するためのブ

汚いコードはよくない （2024.9.22 追記：続編を具体的にかきました！） コードを書くと、コードは増える プログラムは、ソースコードと呼ばれる文字列を記述する事で作成されます。このことを、単にプログラムを書く、コードを書く、などと言ったりします。 ほとんどの場合、プログラムを書くときには、その目的があります。 なにかの目的を達成するために、ソースコードと呼ばれる文字列を記述します。 この記述方法にはいろいろなものがあり、同じ目的を達成するにも無数の方法が存在します。 どの方法を選ぶかは作者に任されている、という言い方もできます。 ところで、ソースコードを記述していき、プログラムで実現できる事が細かくなるにつれて、文字の数はだんだんと増えていきます。 コードの増え方にもいろいろある この文字が増えていく様子を比喩的に表現することを考えます。例えば書類を積み上げることや、積み木を積み上げ

ふとGoogleフォトの残容量をみると2%を切りました。これがゼロ％になるとどうなるか通知が来ていました。 空き容量がなくなると、写真のバックアップや Gmail でのメールの送受信ができなくなります。 こ、怖い。GMailまで送受信できなくなっちゃうの！？ これは早急に対策を考えねば。 現状の分析 200GBのGoogleドライブの契約済み（年額3800円） Googleフォト自体にほぼ不満なし（唯一あるのは同期済み削除が素人泣かせなところ） 十数年分の持ち込み＋約９年でフォトに190GB、メール＆ドライブに8GB、残容量2%表示で残り3.8GB もうひとつ上の契約は2TB（年額13000円） 500GBもあれば10年以上は大丈夫な消費ペース 2TBはオーバースペックすぎる 500GBで5～6000円のプランがあれば、迷わず契約するところなんだけど・・・。 取れる手法 ストレージをひっ迫

ひろゆきさんが今話したいエンジニア（あるいはプロダクトの作り手）に聞いてみたかったことを聞いていく本連載。話題のプロダクトを、ひろゆきさんはどうみるのか？ 「僕ならこうつくる」というひろゆき案も飛び出すかも！？ 「世の中をあっと言わせるプロダクトが作りたい」エンジニアのみなさんにヒントを届けます。 ひろゆきさんが「今、話したい人」と対談する本連載。今回のゲストは、先の東京都知事選に出馬したAIエンジニアの安野たかひろさんです。 日本のAI研究をリードする松尾豊教授の研究室出身で、AIスタートアップ2社の経営者としての顔も持つ安野さんに対する一つ目の質問は

福島銀行の加藤容啓社長らは2024年9月10日までに日経FinTechなどの取材に応じた。加藤社長は2024年7月に稼働した新勘定系システムの開発を通じて「人がやるべき業務を再定義した」と語り、コンサルティング業務に人員を手厚く振り向ける考えを示した。今、新システムの実情に地銀界の関心が集まっている。 福島銀行は2024年7月16日、SBIホールディングス（HD）傘下のSBI地方創生バンキングシステムやフューチャーアーキテクトと組んで「次世代バンキングシステム」を稼働させた。これは米Amazon Web Services（アマゾン・ウェブ・サービス、AWS）のパブリッククラウド上で全面稼働させた国内初の勘定系システムといえる。 加藤社長は次世代システムについて「フルオープンAPI（アプリケーション・プログラミング・インターフェース）とルールエンジンが特徴だ」と強調した。外部のFinTech

Oracle Exadata Database Service(Dedicated Infrastructure)：サービス概要のご紹介

初めて企業のインターンに参加しました。DMMさんのGo言語5daysのインターンです。今回はこのインターンの内容、またGo言語でのAPI開発で学んだTipsを中心に記事を書きます。 温かい目で見てくださると嬉しいです。記事の内容に誤りがあった場合は、いつでもご指摘ください 🙇‍♂️ インターン概要 今回のインターンは8月5日から8月9日の5日間にわたって行われました。最終日はオフィス開催で、4日間はオンラインでの開催でした。 初日と2日目は主にライブラリの使い方を学び、残りの3日間はハンズオン でAPIのエンドポイントを実装しました。このインターンの教材はDMMさんの新卒バックエンド研修の課題として使用されているため、難易度はとても高かったです。 私はGo言語を使用した経験がありますが、本で独学という勉強の仕方だったので、少し古い情報で学んでいたこともあり、 今回最近のバージョンに追加さ

一年前のGoCon Kyotoの発表資料をどこにも載せていなかったので、書いておきます。 Golangを使ったDB用負荷テストツールの開発 by @winebarrel github.com

はじめに Go 1.23 で iter パッケージが導入されました。この iter は抽象化されたイテレータを示す仕組みと実装です。未だどの様に活用して良いか分からない方もいると思いますので、使い方を簡単に解説しようと思います。 概念 iter パッケージは、現状は for-range でのみ利用可能です。スコープにコンテキストを持ったロジカルな列挙可能オブジェクトと、それを別のスコープにて for-range でイテレートする際に便利です。 これまでであれば、こういった実装は goroutine と channel を使いスコープを分割させる事で実装してきました。 package main func iter1[T any](a []T) func() (T, bool) { ch := make(chan T) go func() { defer close(ch) for _, v

はじめに Goで自作RDBMSに挑戦してみたログです。自作、といっても大部分は参考にした書籍の移植です。 ここ1年くらいRDBに向き合う機会が多く、その内部実装を手を動かしながら身を持って理解してみたいというモチベーションから始めてみました。ちょうど会社の『内部構造から学ぶPostgreSQL』読書会に参加したこともモチベーション上げるきっかけとなりました。 (他の方の記事ですが、読書会の記録はこちら↓) 『内部構造から学ぶPostgreSQL』読書会を完走した感想 ［改訂3版］内部構造から学ぶPostgreSQLの社内読書会振り返り データベースをデータの箱としか思っていなかった私の『内部構造から学ぶPostgreSQL』を読んだ感想 普段何気なく使ってるRDBMSですが、ACID特性を守るため・大量の読み書きを捌くため、非常に緻密に設計されております。 これを完全再現といかなくとも自分

こんにちは、リファクタリング大好きなミノ駆動です。 2024/07/20に発売された『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』を、訳者の増田亨氏よりご恵贈賜りました。 この記事は、この書籍の感想です。 著者の許可を得た上でのだいたんな意訳総評等の前にいの一番で伝えたいポイントです。 エリック・エヴァンス氏の『ドメイン駆動設計』は大変価値の高い知見が網羅されている一方、「ユビキタス言語」や「境界づけられたコンテキスト」といった独特の用語が登場したり、難しい言い回しをしていたり、読解がかなり難しい書籍です。 独自用語が登場するたびに「ユビキタス言語？なんだこれ？」とつまづきを覚え、内容理解に集中できず、読む手が止まってしまったことがある人も少なくないのではないでしょうか。 本書『ドメイン駆動設計をはじめよう』は『Learning Domain-Driv

いわゆる「ソフトウェア設計書」が設計ではなく、ソースコードが設計であるという話。 随筆です。考えマトメ中なので、ツッコミはそのあたり踏まえていただければ。 追記：ブコメに「設計の定義は？」とあったので末尾に追加しています。 追記(2024/8/15)：設計書ってなんだろう？というのも書いておきました。 ソフトウェアの「設計書」とはなんなのか - きしだのHatena このエントリで書いたのですけど、もうすこしちゃんと。 建築では多重下請けでやれてるのに業務システムでだめなのはなぜ？ - きしだのHatena このエントリでは次のように書いています。まあ、これで全てではあるのだけど。 「建築などの施工図面に相当するのはソースコードで、建築現場で多重下請けでやってる作業は、ソフトウェアだと(でも？)ビルドです」 あと「継続的デリバリーのソフトウェア工学」からの抜粋。 「継続的デリバリーのソフト

はじめに 今回は、コードレビュー観点表を作った話について少し書かせていただきます。 社内ではGitHubを用いてコードレビューを行っていて、バックエンドの開発においては、コーディングガイドラインも策定しています。 しかし開発において、ガイドラインに書かれている事項が全てではないため、コードレビューを行う際のポイントが自分の中で綺麗に整理しきれていませんでした。 また、ガイドラインの重要なポイントを十分に把握できず、効果的なコードレビューができていない現状がありました。これを改善するために、コードレビューの観点表を作成したことで、コードレビューの質が上がった話についてお話ししようと思います。 問題となっていたこと 一貫性がないレビュー 毎回レビューを行う際に、自分の中のレビューポイントが明確に決まっていなかったため、的確にレビューができていないこと レビューにかかる時間が長い 自分の中でのレ

はじめに ウホウホ。 Rustを使い始めてちょうど2年くらい経って、すこしRustのことがわかってきたので、改めてGoとRustのそれぞれの違いを整理したいなと思いこの記事を書きました。 筆者はウェブ開発の経験しかないので、ウェブを中心にまとめています。 気づいたらかなりな量になってしまったのとGopher向けにRustを紹介するような記事になってしまいましたが、よければ読んでみてください。 筆者について Goを使い始めて7年ほど経っていて、これまでCLI/TUIツールをいくつか作ってきました。 スペシャリストではないですが、プロダクトでGoを書く分には特に問題ないレベルかなと思います。 Rustは2022年夏ころから使い始めてちょうど2年ほど経ちました。 なにかツールを作ったわけではないですが、勉強がてらにいくつか作ったもの・書いた本があります。 普通にRustを書く分には問題ないですが

サービスの開発をしていてPMから施策案が出てきた時、ソフトウェアエンジニアとして施策案が本当にユーザーのためになりサービスの成長につながるか納得できないことがある。 このような時にただ文句や愚痴を言っても何も始まらない。エンジニアからも何らかのアクションを起こし施策を前に進める必要がある。 そこでエンジニアができるアクションについて、自分が思っていることを書いてみる。 納得できないケースは大まかにどのようなものがあるか 納得できないケースでは大まかに2つのケースがあるのかなと思っている。 (1) 施策をしたい目的や仮説自体に納得できていない (2) 施策の目的や仮説は良いが、それを達成する手段に納得できていない 1つ目は、たとえば「ターゲットとしているようなユーザーって本当にいるか？」「ユーザーにこういう課題があると言っているが本当にそういう課題があるか？」「この指標に繋がると言っているが

PHPに関する日本最大のカンファレンスである「PHPカンファレンス2024」が2024年12月22日（日）に開催されます。カンファレンス盛り上げ企画として、開催までの5ヶ月間にわたりPHPの技術記事の連載を企画しました。この記事のお読みの皆さんには、PHPのさまざまな技術に触れながらカンファレンス当日を楽しみにしていただければと思います。 第1回目の今回は、「PHPの中身の読み方」がテーマです。 はじめに プログラミング言語であるPHPは、オープンソースとしてその処理系のソースコードも公開されていて、誰でも中身を見ることができます。PHPの処理系そのものはC言語で書かれているので、PHPの実行の仕組みを理解するにはC言語の知識が必要となります。それなりに歴史があるプロジェクトなので深くまで探ろうとすると骨が折れますが、きちんと整理されたソースコード構成になっているので概要をざっくり把握する

読んで欲しいと思っている人 POやステークホルダーと品質について共通言語や目標が欲しい開発者 開発者と品質について共通言語や目標が欲しいPO スクラムで品質について困っている人 読むとわかること 完成の定義（Definition of Done）とはどんなものか スクラムと非機能的な品質の関係性 タイミーのWorkingRelationsSquadでどんな完成の定義を作り、活用していきたいと思っているか 完成の定義（Definition of Done）とは インクリメントが常に守るべき状態のことです。スクラムガイド1では以下のように説明されています。 完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述である。 プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕⽣する。 つまり完成の定義を満たしていない成果物は、いかに優れた機能であっ

はじめに 今回は、リーダブルコードを読んで備忘録としてメモしておいた内容を共有します。 自分はエンジニア１年目の時に実装時のチートシートとして使用してました。 良いコードとは プログラミングにおいて、短い行で書かれた頭のいいコード＝いいコードではない。 理解しやすいコードこそが良いコード。 読みやすいコードを書くことによって、バグを減らし保守性を高めることができる 自分しか理解できないコードを書くとコードの内容を忘れた頃の自分も苦労する 名前について 汎用的な名前を避ける。 スコープが小さければ短い名前も可。 不要な単語を捨てる。例: convertTostring → ToString エンティティごとに異なるフォーマットを使用する。例: インターフェースはアッパーキャメル。 他の意味と間違えられない名前を付ける。 Booleanの意味を明確にする。 名前を複数検討し、機能を知らない人に

はじめに データベース（DB）の設計は、システムの性能や保守性に大きな影響を与えます。 この記事では、最低限パフォーマンスの低下や管理の複雑化を引き起こさないようにするために覚えておくべきことを、アンチパターンとしてまとめました。 本記事は、 現在仕事でデータベースを扱っており、データ設計について今一度おさらいしたい データベースについての基礎知識やお作法を身に付けたい という人を対象として想定しています。 これらに当てはまる方はぜひ一度確認してみてください！ 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 DB設計アンチパターン 早速、DB設計におけるアンチパターンを紹介します。 それぞれアンチパターンのテーブルを見て