はじめに こんにちは、kenです。みなさんコンフリクト解消してますか！ チーム開発をしているとコンフリクトとは嫌でも向き合うことになりますが、コンフリクト解消って緊張感のある作業なのでやりたくないですよね。 そんなコンフリクト解消をちょっぴり楽にする(かもしれない)コマンドを最近知ったので今回はそれを紹介します、その名もgit rerereです。 git rerereとは Gitの公式ドキュメント（日本語版）には次のように記載されています。 git rerere コマンドはベールに包まれた機能といってもいいでしょう。これは “reuse recorded resolution” の略です。その名が示すとおり、このコマンドは、コンフリクトがどのように解消されたかを記録してくれます。 そして、同じコンフリクトに次に出くわしたときに、自動で解消してくれるのです。 ここに書かれているように、git

はじめに 公式ドキュメントを読め！Qiitaを使うな このような発言はネットで時々見かけるような内容であり、ある程度プログラミングができるような方を中心に見かけるイメージのあるものです。 私はこの発言を見るたび思うことがあります。 Qiitaに投稿すべき内容を多くの人が間違っているからこのような発言が生まれている 今回は、「公式ドキュメントを読むべき理由」「Qiitaが適切な場合」「Qiitaに投稿すべき内容」について書いていきます。 公式ドキュメントを読め 「公式ドキュメントを読め」 これは私として気持ちがものすごくわかります。 公式ドキュメントにはだいたいの知りたい内容については書かれていますし、1次情報になるので情報が正確です。 QiitaやZennなどに解決方法がないかを時間を書けて調べるくらいならいきなり公式を見たほうが早く解決することも多いです。 その一方で「公式ドキュメントよ

この書き方でも for 文は正常に動作します。 しかしながらこの書き方は 以下の書き間違いが生じることがあります。 for(var i = 0; i < array1.length; i++) { //長い処理 for(var i = 0; i < array2.length; i++) { } } 長い処理の中で i を宣言したことを忘れて 再び i を宣言してしまうことで 外側の for 文のカウントにバグが発生し 期待した動作にならない例になります。 私も他の人が作成した web アプリで このバグを見かけたことがあります。 for の変数を宣言する場合 必ず let で宣言して下さい。 var でなければ正常に動作しないのは 構造的欠陥のハズです。 let array1 = [1, 2, 3]; let array2 = [4, 5, 6]; for(let i = 0; i <

rebase で色々あったので、備忘録として簡単に書いていきます。 前提背景 開発作業中、元のブランチに変更があった場合、私は変更を取り込むために常に rebase を使用します。これを選ぶ主な理由は「コミットログが見やすく保たれるため」です。 Gitには同様のコマンドとして merge がありますが、これは変更を取り込む際にマージコミットを作成する点が異なります。私はマージコミットによってコミットログが煩雑になると感じています。 このような理由から、私はrebaseを積極的に使用しています。 何があったのか 簡単に言うと、レビュー中にブランチ元の変更があったので、 git rebase からの git push -f origin [ブランチ名] やったらレビュアーのコメントが吹き飛びました。 いやー、めっちゃ怒られたよね💦 原因 「レビュー中」という状況がまずかった。 コードを共有し

データベースとテーブルの作成 テスト用のデータベースtestdbを作成し、パフォーマンスチューニングを検証するためのcompanyおよびpersonテーブルを定義します。 CREATE DATABASE testdb; USE testdb; CREATE TABLE company ( company_id INT AUTO_INCREMENT PRIMARY KEY, company_name VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE person ( person_id INT AUTO_INCREMENT PRIMARY KEY, company_id INT, person_name VARCHAR(255) NOT NULL, email VARCH

はじめに こんにちは、WatanabeJin(@Sicut_study)です。 今回は私が初学者のときに最も苦労したDockerの技術を身につけるためのロードマップを紹介していきます。 Dockerが難しいのはなんといっても概念的なところだと思っています。新人時代の私は入社していきなり「Dockerで環境構築して」とだけ先輩に言われて何もわからない状態から自力でなんとか使えるところまで1ヶ月かけて学びました。(プログラミング経験なしでいきなりDockerは辛かった) その後、同じくプログラミング経験なしの方にDockerを指導した際に、この流れでやっていけば技術として身につくなと思ったのでまとめていきます。 概念が難しいDockerの学び方 私自身がものすごく1年目の時につまづいたDockerの勉強の仕方についてどのように身につけていったかを紹介します。… pic.twitter.com/

はじめに この度、転職とスキル向上を目的に個人サービス(Football League)をリリースしました。 ITに関する学習は約1年ほど、その内の半年でサービスの開発をしました！ まだまだ修正箇所はあるものの、ひとまず形にはなったのでサービスの使用技術や開発過程を共有したいと思います。 私自身、独学で学習してきたのでそういった方々にとって少しでも参考になれば幸いです。 自己紹介 商業高校卒(サッカー部⚽️) 25歳 青森住み🍏 職業はトマト農家です🍅 どのようなサービスか 本サービスは、欧州5大リーグのサッカーの試合結果やチーム情報などを閲覧することができるWebサイトです。 ただ情報を閲覧できるだけでは面白みがないので、お気に入りのチームやリーグを追加することもできます。 なぜ作ろうと思ったか 私自身、小学生の頃から社会人になった現在までサッカーをやっています。 サッカーだけではな

この記事はNuco Advent Calendar 2023の9日目の記事です。 はじめに この記事ではDockerで開発環境を行うために理解してほしい概念と実際の開発環境の構築手順について解説を行います。大きく分けて、 ・Dockerの概念理解 ・開発環境の構築 これらの章により構成されています。この記事を読むことで、Dockerファイル、イメージ、コンテナ、Docker compose、compose.ymlを理解できるようになることを目指しています。Dockerに触れてみたい、Dockerの理解があやふやという方は参考にしてみてください！ 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 Dockerとは まず、Do

株式会社ブレインパッドでデータサイエンティストをしているasanoです。 この記事はBrainPad Advent Calender 2023 1日目の記事シリーズ2です。 ※シリーズ1は@fuyu_quantさんの入力プロンプトを復元する技術 #ChatGPTです！ 今日はコードレビューの思想や心構えについて書きます。 はじめに コードレビューをより生産的に進めるには単にコーディングのスキルだけでなく、そもそものコードレビューに対する思想や心構えについても一定のリテラシーを求められると考えています。 コードレビューはどうしてもロジカルな話になるため伝え方にも気を付けないとモチベーションの低下に繋がりやすいと考えています。 そうなると当然パフォーマンスも下がってしまいます。 これを防ぐために自分は「コードレビューの思想・心構え」をまとめてチームのガイドラインとして使っています。 あくまで主

追記（2024年6月4日） この記事は、2023年9月時点の情報です。 当時と比較すると、ここ最近はLLMを取り巻く状況が大きく変化しました。 GPT-4oの登場によってより人間に近いチャットが出来るようになったり、Geminiに新しいモデルが追加されてGPT-4に負けず劣らずの精度が出せるようになったり、その陰でClaude3が着実に成長していたり。 LLMの競争は2023年よりも激しくなり、各社モデルの成長スピードも上がっていると感じています。 サブスクリプションプランを契約することによるメリットが、執筆当時よりも大きくなっていますし、選択肢も大幅に増えました。下記の無償版のチャットを試して、AIチャットの感覚がつかめてきたら、サブスクリプションを契約するのもアリだと考えています。 もちろん、無償版のAIチャットでも、Copilot（記事内ではBingと表記しています）であればGPT-

はじめに 開発者として経験を積んで、「人に頼むよりも自分でする方が早いから」 という考えに固執し、「人に頼まず自分でやってしまう」 という壁にぶつかることがあるかもしれません。リーダーに昇格した直後などは、自分で仕事をした経験はあるけれど、人に頼んだ経験がないなどの理由でそのような選択をするかもしれません。 頼んだ相手が自分よりも大きな見積もりを出してしまうことがあります。その場合、自分に多くの作業を割り振ってしまい、「自分だけが忙しくなる状況」 に陥ってしまうこともあります。 そこで今回は、簡単に読めてこういった状況を避けるのに役に立つ本を3冊程紹介したいと思います。 最強のエンジニアになるための話し方の教科書 技術力(200%) x 伝える力(0) = 真のパフォーマンス(0) (出典：最強のエンジニアになるための話し方の教科書) どんなに技術力があってもちゃんと伝えないとダメなんだな

エンジニア未経験のわたしがGitを学ぶ上で、この流れで記事を読むべきだったと思ったことを記載する。 完全に初学者意見のため、疑いながら読んでください。 私は下記の流れで学習することによって、理解をしやすいように感じた。 ①　Gitで何をしているかのイメージを掴む（コマンドなし） ②　Gitのイメージを、コマンドで実現している記事をみる ③　実際にGitのコマンドを打ちながら、出力と、頭の中のイメージのすり合わせ Gitで何をしているかのイメージを掴む（コマンドなし） こちらの記事は、Gitのイメージをコマンドなしで、わかりやすく図で示してくださっています。 記事にも記載されていますが、 ・重要なのは 「何」から「何」へ・「どんな作業」を行う のかを追う ・操作前と操作後でどんなことが起こっているのかをイメージする 上記の内容が、すごく同意で、重要だと感じている。いきなりコマンドを打ちながら

はじめに 私の開発チームでは、毎週おこなう振り返りの中でチームのパフォーマンス向上や問題点の改善を目的とした「トライ」という取り組みを考え、次の1週間でそれを実践するようにしています。 この記事では、これまでに試してきたトライの中で特に印象的だったものをいくつか紹介していきたいと思います。 みなさんの職場でも取り入れられそうなものがあれば、ぜひ参考にしてみてください。 18時〜翌朝6時は仕事禁止 言葉の通り、夕方18時から翌朝6時までの間に仕事をしてはダメ、というものです。 ねらい リミットがあることで仕事に集中できる 18時になったら合法的にタスクを手放せることによる心理的負荷の軽減 やってみて 集中力が高まる・心理的負担が軽減されることに関しては効果を感じた人が多かった印象です。また強制的に朝型になるので、生活リズムが改善された人もちらほらいたようです。 一方で、「タスクに追われている

何故かJavaは敬遠される！？ 筆者はIT業界に努めて17年ほどです。 SESとして働きに出ることが多かったのですが、近年はWebエンジニアとして PHP(Laravel)を使った開発が多くなってきています。 そんな開発現場ですが、プログラミング言語の話題に上がると 「Javaはわからない」 「Javaって難しいんでしょ？」 「環境構築がなぁ・・・」 なんて話をよく聞きます。 私はJavaの方が経験した期間が長かったので、特にそういった苦手意識は無いのですが Laravelの現場でもそういった話を聞くので、 「フレームワークの特性や、コードの書き方は結構似ているところが多いのに、何でみんな苦手なんだろう？」 と思ってしまうのです。 今回はそのギモンについて、私が思っていることを書いていきます。 （注：Java嫌いな人を論破したいわけではありませんｗ） 原因その１：インフラ構造上、難しいと思

はじめに 昨今の採用現場においてはソフトウェアエンジニアは売り手市場と言われ数年が経過していますが、2023年現在においても、デジタルトランスフォーメーションの加速により、これまでのIT企業の募集だけではなく、様々な企業がソフトウェアエンジニアを募集している状況にあると思います。 知り合いのリクルーターに話を聞くと、ここ最近米国のBigTech企業や、日本初のベンチャー企業のレイオフが目立ちますが、それはごく一部であり、多くの企業では引き続きソフトウェアエンジニアの需要は最も高く、この先10年以上はこの高い需要は続くだろうと言っていました。 引用元: 【2023年最新】厳選！エンジニア採用に強い15の採用媒体比較～最新市場動向や採用戦略も徹底解説 - type 私自身が就職した10年数年前は望んでソフトウェアエンジニアに就く人は理系出身のプログラミング趣向が強い人ばかりという印象でしたが、

はじめに 都内でWEBエンジニアとして働いているまさきちといいます。 受託開発企業に勤める中で経験したこと感じた事を語りたいと思います。 目次 この記事の対象読者 受託開発企業で働く中で感じたこと 複数案件を掛け持つのが当たり前 フロント、バック、インフラ全てこなせる必要あり ハードワークのため、体調やメンタルを壊してしまう人も クライアントワークが主なのでお客様の対応で消耗しがち 商流が深くなると厳しい環境になりがち テストコードや設計にかける時間が少なくなりがち 夜遅くまで残って仕事をしている人が多く、人生について考えさせられる。 技術力や知識よりも顧客折衷や、マネジメント力が評価されがち 効率重視なので技術が固定化されやすい 終わりに この記事の対象読者 WEB系エンジニアを目指そうと思っている方 受託開発企業の働き方について知りたい方 同じ受託開発企業に勤めていらっしゃる方 受託開

C#で名称を忘れやすい語句について、簡単な解説・用例とともにまとめました。 実装やコードレビューなどの場面でお役に立てば幸いです。 /// ドキュメンテーションコメント クラスやメンバーの説明を記述するのに利用する。 /// <summary> /// This class performs an important function. /// </summary> public class MyClass {}

こんにちはISSUEを運営している寒河江です。 今回は情報の少ないWebエンジニアの業務委託単価相場について調べてみました。 現在の単価が適正単価なのか、次の単価レンジに行くにはどうすればいいか。ISSUEの実績をふんだんに使い記事を書いてみたのでご一読いただけると幸いです。 オリジナルの記事はこちら ISSUE DB 3,000人の実績データから相場を作成 現在(2022年11月)ではISSUE上に1,800人以上のユーザーデータと2,000以上の単価診断結果があります。またISSUEではクラウドソーシング形式で企業とマッチングすることにより、報酬を獲得することができます。その際の契約時給単価を参考に今回の相場作成の参考にしています。ISSUE上でもリアルタイムの単価相場を確認できますのでご参考ください。 Webエンジニアの業務委託単価相場 わかりやすいように各業務委託単価とその技術能力

フルスタックエンジニア(full stack engineer) フルスタックエンジニアといえば、ハードウェア、ソフトウェアのすべての作業をこなす資格を持ち、作業可能な人をいうと、誰にでもわかりやすい。 <この項は書きかけです。順次追記します。> 20221113追記 フルスタックソフトウェアエンジニア　どこからどこまで https://t.co/BEzuwrZnE5 #Qiita @naokiakutagawaより 面白い！フルスタック再定義は居ると思ってる。フルって付けるのが良くないのかな・・ — いもいもくん (@ma_anago) November 12, 2022 ありがとうございます。フルってつけたらどこからどこまでを言わないと、フルかどうかがわからないですね。。 お互いのフルの範囲の違いを確認しないと意思は通じないかもしれない。 表題を「フルスタックソフトウェアエンジニア　ど