【日本人エンジニア必携】英語命名規則の決定版 - Qiita
弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 はじめに 英語での適切な命名は、コードの可読性や保守性を向上させるために重要です。適切な命名規則を守ることがコードの理解や共有において不可欠です。 英語での命名規則を学び、適切な命名を行うことで、コードの読みやすさや保守性を向上させ、チーム全体でのコードの理解を促進する手助けとなります。 この記事では、日本人エンジニアが英語での命名規則を理解し、適切な命名を行うための指針を提供します。 命名フローチャート 変数 関数 クラス 1. 変数 1-1. boolean 1-1-1. 存在するかどうかのフラグ 名詞 + exists
中途入社や部署異動で来た新メンバーを活躍しづらくするアンチパターン - Qiita
1. はじめに ソフトウェア開発のチームに、新しいメンバーが入ってくることはよくあります。 以前に新卒社員がチーム入ってきた場合の育成方法を紹介しました(こちら)。 今回は、新卒社員ではなく、他の会社から中途入社か同じ会社の部署異動で来る新メンバーの話です。 (エンジニアが数百人などで規模が大きい会社の場合、部署が違うと仕事のやり方が全く変わる場合があるので、今回は中途入社と他の部署からの異動を同じように「新メンバー」として扱います) 会社や部署が変わると仕事のやり方が大きく変わるため、仕事のやり方に戸惑うことが多いと思います。 本稿では、そのような「新メンバー」を活躍しづらくしてしまうアンチパターンとその対策を紹介します。 2. 中途入社や部署異動で来た新メンバーが適応することの困難さを理解する 中途入社や部署異動で来た新メンバーが組織に適応することは、新卒社員のそれとは別の難しさがあり
20代若手エンジニアに伝えたい「圧倒的に成長する秘訣」 - Qiita
20代で圧倒的に成長する人とパッとしない人の決定的な違い 2人の新入社員がいた。 同じ学歴レベル。 同じプログラミングの技術力。 同じ採用基準に合格。 それでも、入社から1年後、2年後、5年後になると、一人はバリバリ成長してチームリーダーを任されている一方、もうひとりはいつまで経っても大きな仕事を任せてもらえない…。 これはフィクションだが、こんなことはエンジニア業界に限らず日本中いたるところで発生している。 二人を分けた違いはなんだろうか?それは、、、 高い仕事の基準を自分に課していたかどうか。 君が20代で圧倒的に成長したいと本気で考えているなら、心して続きを読んで欲しい…。 仕事の基準を高く持つとは? いきなり抽象的な精神論を繰り出しても仕方ないので、具体的なシチュエーションを置いてみる。 例えば、明日からあるタスクを先輩社員と一緒にペアプログラミングでやることになったとしよう。凡人
Figmaの作業を効率化！ 知らないと損するショートカット集 - ICS MEDIA
ウェブ制作における定番になりつつあるデザインツール「Figma」。本記事では、Figmaの知らないと損するショートカットキーを紹介します。 よく使う便利な機能を呼び出すショートカットキーを覚えておくことで、作業効率が上がるのでしっかり覚えていきましょう。 本記事では基本機能のショートカットキーだけでなくマニアックなものまで紹介します。初心者はもちろん普段からFigmaを利用している方にも役立つ内容をまとめています。 ショートカットキー一覧の呼び出し（control+shift+?） Figmaでは、見やすいショートカットキー一覧をいつでも表示できます。ショートカットキーを忘れてしまった場合には、control+shift+?(macOS) /control+shift+?(Windows)を押しましょう。 画面下部にショートカット一覧が表示されます。使ったことのあるショートカットは色が付き
【徹底解説】これからのエンジニアの必携スキル、プロンプトエンジニアリングの手引「Prompt Engineering Guide」を読んでまとめてみた | DevelopersIO
【徹底解説】これからのエンジニアの必携スキル、プロンプトエンジニアリングの手引「Prompt Engineering Guide」を読んでまとめてみた こんにちは。CX 事業本部 Delivery 部のきんじょーです。 ここのところChatGPT と戯れてアプリを作ったり、様々なプロンプトの検証をしていましたが、言語モデルの性能を最大限に引き出すために、体系的にプロンプトエンジニアリングを学びたいと考えていました。 GitHub に「Prompt Engineering Guide」という素晴らしいリポジトリがあったので、読んで検証した内容をブログにまとめていきます。 本記事は、執筆時点の上記リポジトリの内容を元にしていますが、意訳や独自に検証した日本語のプロンプトを含みます。 上記リポジトリも絶賛開発中の段階のため、最新情報や原文が気になる方はリポジトリを直接参照してください。 目次 プ
僕がコードレビューの時に気をつけていること｜su-
いきなりがっつりとした記事を書くよりは慣れるために軽めの話を。 こんにちは、すーです。 今回は普段僕がコードレビュ(GitHubのPull Requestのレビュー)の時に気をつけていること、大切にしていることを書いてみます。 (※以降話は主にGitHubのPullRequest(PRと略します)上での話がメインだと捉えてもらえますと) 自分がレビューをするときまずは自分がレビュワーだった場合に、気をつけていることを。 ・ PRの概要、関連するIssueの内容をしっかり読む まずはじめにPRの概要や、関連するIssueの内容を確認します。 何も見ずにいきなりコードに目をやってしまうと的外れなレビューをしてしまう可能性もありますし、コードの善し悪しだけを追いがちになってしまいます。 どういう意図や背景があってこのPRが出されたのかを確認するのはとても大事になります。 ・ コメントに`[MUS
学習効率の良い書籍の読み方 - パンダのプログラミングブログ
書籍の読み方には2種類ある 書籍の読み方には大別して2通りある。最初から最後まで読む通読と、必要な箇所をピックアップして読む参照だ。 通読は小説を、参照は辞書を想像してもらうと良い。 技術書は実用書であり、後者の参照に向いている。 パターンのカタログのような書籍は特にそうだ。PoEAA 、GoFのデザインパターンはもちろん、リファクタリング、レガシーコード改善ガイドなどは、通読するより必要に応じて参照する方が良い。著者もそのことを知っていて、実は序文や第1章に通読より参照してほしいと書かれているケースがある。 参照方法は簡単だ。まず解決したい疑問を頭に浮かべて目次、もしくは巻末の索引からキーワード探す。自分の疑問に答えてくれそうな箇所があればそのページに飛んで読む。 その中で知らない単語があったり、参考文献が紹介されていればそれを辿って読む。知らない単語がある場合、大抵同じ書籍内の別の箇所
技術書を効率的に勉強する！難しい本でも読んで覚えられるコツ
ITエンジニアなどの知識労働者であれば、技術書を読む機会は多いのではないでしょうか？ 情報を探す際には、インターネットで解決する場合も多いですが、特定の分野を体系的に学んだり、技術書ならではの情報が得られるなど、本ならではのメリットも有るため、技術書を読む重要性は未だ健在だと思います。 しかし、特に海外の技術書などは、分厚かったり、難解だったりと、内容を理解しながら読み切るのは骨が折れるところです。 今回はそんな読むのが難しい本でも、能動的かつ効率的に読むための方法「SQ3R」をご紹介します。 SQ3Rは、1946年に米国の教育心理学者Francis P. Robinsonによって考案された、能動的かつ効率的に読書するための方法ですSQ3Rは主に5つのステップから構成されます。 もともとは大学の学生向けに考案されましたが、今では世界中の教育現場でも採用されている方法です。また、インドネシア
状態、結合、複雑性、コード量の順に最適化する - valid,invalid
There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結
エンジニアのための Figma 知識
本記事の多くは Inspect モードを前提に解説しています。 下記に Dev Mode に対応した解説を書いてみたのであわせてご参照ください。 https://codezine.jp/article/detail/18000 エンジニアにデザインツールの知識・習熟は必要か？ しなくても仕事はできると思うのですが、あるとよりクオリティの高い仕事ができることは間違いありません。 という訳でエンジニアがエンジニアとしての仕事をしていく上で「Figma のこういうことを知っておくと良さそう」という知識をまとめてみました。 ユースケースを考える まず始めにデザインは作らないはずのエンジニアが Figma を使う時にどんなユースケースがありそうかを考えてみます。 デザインを元に実装する時 デザインから何かを生成したい時(コードとか画像とか) 自分でちょこっとデザイン修正しちゃう この辺りがあるかな〜
ITエンジニアが投票した「ITエンジニア本大賞2022」ベスト10発表。「シェル・ワンライナー160本ノック」「モノリスからマイクロサービスへ」「恐れのない組織」など
ITエンジニアが投票した「ITエンジニア本大賞2022」ベスト10発表。「シェル・ワンライナー160本ノック」「モノリスからマイクロサービスへ」「恐れのない組織」など 「ITエンジニア本大賞」は、仕事の役に立った本、初学者におすすめの本、ずっと手元に置いておきたい本など、おすすめの本をITエンジニアがWeb投票で選ぶイベントです。 主催は翔泳社ですが、対象となる書籍は出版社を問わず技術書、ビジネス書全般となっています。刊行年も関係なく、これまで大賞に選出された書籍を除き、この1年を振り返っておすすめしたい書籍が対象となります。 今回発表されたのは技術書部門とビジネス書部門それぞれのベスト10です。現時点では50音順に並んでいます。 このなかから特に投票の多かった技術書3冊、ビジネス書3冊について、同社が2月17日と18日に開催する「Developers Summit 2021（デブサミ20
完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita
これはなにか エンジニア、ビジネスサイドの方に向けた、「良い要件定義の作り方」について書いた記事です。 長文がつらつらと書いてある本稿ですが、要するに言いたいことは、 ● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、 「あの人が作ったんだから大丈夫」と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要 ● UXから逆算する ● 削ぎ落とす ● 個ではなく、チームで作る ● レビューを徹底する ● 3つのシナリオを想定する ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれ
同じ組織で働く人は常に転職活動をしていてほしい
早いものでLINE株式会社に入社して3年が経ちました。今日から勤務4年目となり、業界としてはそれなりに長く働いている側に足を突っ込んできた自覚があります。仕事もエンジニアからマネージャーになり、役割も変わってきたところ。 現職でまだやりたいこともあるだけでなく、明確にバリューを出せていて組織からも評価されている現状、しばらく転職する予定はないのですが、一方で、私は常に他の選択肢がないかを探し続けています。 そして一緒に働く同僚やチームメンバーには語弊を恐れずに言えば「常に転職活動をしながら仕事をしてほしい」と思っています。 現職についてのエントリに興味がある人はそう多くないと思うので、3年目が終わった節目として、今日は市場を見て仕事をすることの重要性について書き記すことにしました。 自社に満足しているときほど、外部の働き方を知る必要がある 「あなたは今の仕事に満足していますか？」と聞かれた
究極のIT系最新技術情報収集用Slackチーム公開 - モヒカンSlack -
tl;dr コンピュータ系の情報収集用のSlack公開グループ（モヒカンSlack）を作ってみたよ。 皆さんで協力して育てていく共同RSSリーダーみたいなものだよ。 このSlackグループの情報を追っていればオッケーなので、情報取集が格段に楽になったよ。 誰でも無料で参加オッケーよ。下のどっちかからメールアドレスを入力して参加できるよ。 Invite people to mohikan Slackin Google Forms 参加者数 1,694名 (2016/10/7 時点) 4,077名 (2017/1/25 時点) 7,000名 (2017/8/25 時点) 11,747名 (2018/12/1 時点) チャネルのリストは「Gist」にあるよ。148チャネル(2017/1/25時点） 分野ごとにチャネルが別れていて、追いたい分野のものに参加すると良いよ プログラミング言語系(毎朝G
エンジニア向け デザイン基礎（社内勉強会の資料） - Qiita
これは何 私が所属している株式会社エイチームでは社内勉強会を自由に開ける制度があります。 エンジニア向けにデザインの基礎をレクチャーする会を開いたのですがせっかくだったらオープンにしようと思い、投稿しました。 今回の勉強会では「Webサービスを作る」レベルまでは踏み込めませんでしたが、ちょっとしたUIを作る際の手助けにはなれる気がしています。 なお、勉強会用に書いた原稿なので書き言葉としてあまり適切でない箇所もあります。 ご了承ください。 また、この研修の次の年に行った研修も記事として投稿しています。 設計の話 はじめに：デザイン業務の内訳とよくある誤解 デザイン業務の内訳 まず最初に設計の考え方をレクチャーするのですが、その前に1つ。 普段デザイナーが行っている業務について簡単に説明します。 後の方で話す内容と繋がってくるので、ちょっと本筋から外れますが聞いてください。 話を分かりやすく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ltやleなど演算子の略称 - Qiita
Yoshiki Kojima / chot Inc. on Twitter: "ChatGPT全社員導入に続いて、Copilot for Businessを全エンジニアメンバーに導入します。 https://t.co/zuOvDzahnJ"
https://twitter.com/seltzer/status/1636522996331606018
https://twitter.com/shiba_program/status/1562364092769239041
ふつうのプログラマのふつうの設計
