並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 772件

新着順 人気順

命名規則の検索結果1 - 40 件 / 772件

  • 【日本人エンジニア必携】英語命名規則の決定版 - Qiita

    弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています!興味をお持ちいただける方は、こちらまで。 はじめに 英語での適切な命名は、コードの可読性や保守性を向上させるために重要です。適切な命名規則を守ることがコードの理解や共有において不可欠です。 英語での命名規則を学び、適切な命名を行うことで、コードの読みやすさや保守性を向上させ、チーム全体でのコードの理解を促進する手助けとなります。 この記事では、日本人エンジニアが英語での命名規則を理解し、適切な命名を行うための指針を提供します。 命名フローチャート 変数 関数 クラス 1. 変数 1-1. boolean 1-1-1. 存在するかどうかのフラグ 名詞 + exists

      【日本人エンジニア必携】英語命名規則の決定版 - Qiita
    • 【無料公開】560万円かけて開発したサービスのソースコード

      ※月単価80万円を基準に、7ヶ月分の工数として560万円相当と換算しています。 最初に こんにちは! 普段はIT企業でWebエンジニアとして働いています。 現在はフリーランスとして活動し、Ruby(Ruby on Rails)、TypeScript(Next.js, React)、Pythonなどを使って、フロントエンドとバックエンドの両方に携わっています。 将来はソフトウェアエンジニアとしてアーキテクチャ・設計について自ら意思決定した上、プロジェクトを推進する事が出来るようになりたいです。 そのためさらにスキルを磨いていきたいと思っており、日々技術に対して情熱を持って仕事に取り組んでいます。 以前Qiitaで 退職して560万円相当の工数をかけてお金を稼ぐサービスを開発した という事でBizRankというビジネス書籍を紹介するサービスを開発しました。 今回はその後としてのお話になります。

        【無料公開】560万円かけて開発したサービスのソースコード
      • 3日後に命運が決まる、パルワールドという偶然の物語|ポケットペア

        パルワールドのリリースに至るまで、様々な経験をした。 各ゲームで、それぞれ新しい事を学び、人の縁を作っていった。 どのゲームが欠けても、こうはならなかっただろう。 4. パルワールドという偶然の物語 リリースされなかった幻の1作目が無ければ、オーバーダンジョンは生まれなかった。 オーバーダンジョンが無ければ、クラフトピアは生まれなかった。 クラフトピアが無ければ、パルワールドは生まれなかった。 そして、どのゲームも、本当に大変な困難を伴いながらリリースされた。 幻の1作目も、本当に何度も作り直した。プロトタイプは下手したら20個ぐらい作ったかも知れない。喧嘩・・・というか、意見の相違の議論も、何百回もした。 どうしても解決困難な問題にも必死に取り組んだ。 そしてそれは、報われなかった。 オーバーダンジョンも苦労した。Steamへゲームを公開するのが初めてだったので、何から何まで分からなかっ

          3日後に命運が決まる、パルワールドという偶然の物語|ポケットペア
        • Looker Studioの魅力と便利な使い方を紹介します - yasuhisa's blog

          初めて使ったBIツールはLooker Studioのid:syou6162です。これまでTableau / Looker(≠ Looker Studio) / Metabase / Redash / Connected Sheetsなど色々なBIツールを触ってきましたが、不満は色々ありつつも個人的に一番しっくりきて愛着があるのはLooker Studioです。このエントリでは、その魅力と便利な使い方や注意点について書きます。例によって、社内勉強会向けの内容を外向けに公開しているため、内容の網羅性などは特に担保していないことにご注意ください。 Looker Studioの魅力 利用のハードルが限りなく低い & Google Workspaceとの連携が便利 複雑過ぎることができないので、諦めが付けやすい ちゃんとBIツールになっている Looker Studioの便利な使い方 多様なデータソ

            Looker Studioの魅力と便利な使い方を紹介します - yasuhisa's blog
          • レベルアップしたい人必見 Qiita記事43選 - Qiita

            はじめに 本記事ではレベルアップしたいエンジニアが読んでおくべきQiita記事を紹介します。厳選に厳選を重ねた43記事です。全ての記事を読んでおく必要はありませんが、ちょっとでも「分からないな」「興味あるな」など思ったタイトルがあれば読んでみてください。 次の4種類に分類して紹介しています。参考にしてください。 フロントエンド バックエンド インフラ・Linux周りの知識 その他 それでは、早速紹介していきます! 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています!興味をお持ちいただける方は、こちらまで。 フロントエンド まず最初はフロントエンドエンジニアに読んでおくべきとおすすめできるQiita記事を11個選びました!フロントエンドエンジニアとしての基礎が身に付く

              レベルアップしたい人必見 Qiita記事43選 - Qiita
            • 5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる

              はじめに 本稿は、オープンソースの可観測性(Observability)プロジェクトである OpenTelemetry を取り上げた書籍「Learning Opentelemetry」の読書感想文です。従来の可観測性の課題であったデータの分断を解消し、トレース、メトリクス、ログなどの様々なテレメトリデータを統合的に扱うことができる OpenTelemetry は、可観測性の分野における革命的な存在と言えます。 過去10年間で、可観測性はニッチな分野から、クラウドネイティブの世界のあらゆる部分に影響を与える数十億ドル規模の産業へと発展しました。しかし、効果的な可観測性の鍵は、高品質のテレメトリデータにあります。OpenTelemetryは、このデータを提供し、次世代の可観測性ツールと実践を開始することを目的としたプロジェクトです。 learning.oreilly.com 本書の想定読者は、

                5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる
              • 可読性の高いコードを書くための実践ガイド - Qiita

                はじめに ソフトウェア開発において、コードの可読性はプロジェクトの成功に直結する重要な要素です。読みやすいコードは、メンテナンスや拡張を容易にし、チーム全体の生産性を向上させます。 しかし、「読みやすいコード」 の定義は人によって異なります。個々のスタイルや好みによって解釈が分かれることもあるでしょう。それでも、できる限り多くの人にとって理解しやすいコードを書くことが、プロフェッショナルとしての責任です。このガイドでは、そんな読みやすさを意識した具体的なテクニックなどを紹介していきます。「もう知ってるよ!」と思った方も、今一度できているかを確認してみてください。 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています!興味をお持ちいただける方は、こちらまで。 注意点 こ

                  可読性の高いコードを書くための実践ガイド - Qiita
                • すぐに役に立つものはすぐに陳腐化してしまうから方法ではなく設計の本を読む - API Design Patterns の読書感想文 - じゃあ、おうちで学べる

                  あなたがさっきまで読んでいた技術的に役立つ記事は、10年後も使えるでしょうか?ほとんどの場合でいいえ はじめに 短期的に効果的な手法や知識は、ソフトウェア開発の分野において、急速に価値を失う傾向があります。この現象は、私たちが何を重点的に学ぶべきかを示唆しています。最も重要なのは、第一に基本的な原理・原則、そして第二に方法論です。特定の状況にのみ適用可能な知識や即座に結果を出すテクニックは、長期的には有用性を失う可能性が高いです。これは、技術や手法が時間とともに進化し、変化していくためです。 learning.oreilly.com 「API Design Patterns」は、このような考え方を体現した書籍です。しかも480 ページもあります。本書は単なる手法の列挙ではなく、Web APIデザインの根幹をなす原則と哲学を探求しています。著者のJJ Geewax氏は、APIを「コンピュータ

                    すぐに役に立つものはすぐに陳腐化してしまうから方法ではなく設計の本を読む - API Design Patterns の読書感想文 - じゃあ、おうちで学べる
                  • 競プロ出身者・機械学習出身者の問題コード

                    https://anond.hatelabo.jp/20240625191650 競プロ出身者だけじゃなく、機械学習出身者も問題コードが多い 印象の問題ではなく実際に下記のようなコードが多い 念のため言っておくと底辺大や文系出身プログラマーも同様の傾向にある 正常系しか意識していない一番多いのはコレで異常系の動作を全く意識していない 入力値に想定外のものが入ることを考えていなかったりI/Oに関わるエラーについても配慮がない 「エラーが出たらとにかくtry-catchしてログ吐いて終わり」 ならまだマシな方で、「握りつぶして処理続行」みたいなことも平気でやる 「ここの処理でエラーログが出てるから対処よろしく」 「対処しました!(握りつぶし)」 とか滅茶苦茶多い セキュリティに関する意識が低い異常系の話と被るけど基本的に性善説でコード書くのでセキュリティの不備がめちゃくちゃ多い API作らせて

                      競プロ出身者・機械学習出身者の問題コード
                    • 大ヒットゲーム『Balatro』のコードが“力業”だとして共感呼ぶ。コードが汚くても、ゲームが完成してちゃんと動けばそれでいい - AUTOMATON

                      ゲームを制作する際に必要となるプログラム。そのコードの記述にあたっては「コーディングルール」などとして、構造の把握のしやすさなどが求められることがある。一方で今回、あるユーザーが『Balatro』のコードの一部を公開。コードにif文が多用されている点などから注目されているものの、「見づらかったり、複雑なコードでもほぼ問題なくゲームを完成させられる」事例として共感も呼んでいるようだ。 コードのわかりやすさ ゲームの制作にあたっては、基本的にはプログラミング言語を用いてソースコードを書くといった、プログラムの記述が必要となる。プログラミング言語としては、「C++」「C#」のほか「Java」「Ruby」など、さまざまな種類の言語が存在している。 またゲーム開発に限らず、複雑なプログラムを作成する際には、効率性や可読性が重視される傾向にある。つまり、ゲーム機やPCにおけるメモリやCPUなどといった

                        大ヒットゲーム『Balatro』のコードが“力業”だとして共感呼ぶ。コードが汚くても、ゲームが完成してちゃんと動けばそれでいい - AUTOMATON
                      • 2023年の話題&ベストセラーをまとめて紹介! Udemyで今年最大級のセール開催、生成AIなど対象講座が1,200円より - はてなニュース

                        世界中を席巻した生成AIは、ブームに終わることなく着実に社会のさまざまな場面で利用が進んでいます。特にChatGPTを始めとするテキスト生成はビジネスシーンですぐに適用可能なケースも多く、使いこなす人とそうでない人には大きな差が生じつつあります。 使いこなすノウハウにも一定の知見が貯まっており、定番となるセオリーが整理されています。正しく学ぶことができれば一気にキャッチアップできるでしょう。Udemyの講座でも、ChatGPTを使いこなすプロンプトの作法や、アプリケーションにLLM(大規模言語モデル)を組み込むノウハウ、AIをより深く知る数学知識などに人気があります。 この記事では、2023年11月17日(金)に始まるブラックフライデーセール(24日まで)、そして26日(日)から2日間のサイバーセールの対象になる人気講座から、エンジニアリングやビジネスシーンにおいて読者の成長を助けてくれる

                          2023年の話題&ベストセラーをまとめて紹介! Udemyで今年最大級のセール開催、生成AIなど対象講座が1,200円より - はてなニュース
                        • 「Tailwind CSSめっちゃ負債になりそう」はそうでもないのでは、と思っている

                          「Tailwind CSSめっちゃ負債になりそう」はそうでもないのでは、と思っている Tailwind CSS 1 を一目見た人、特にCSS初学者のうちけっこうな割合が「これエグい負債になりそう」と思う気がする。なぜなら実際にそのような意見をちらほら見るからなんだけども、自分はあんまりそうは思っていないし、微妙に今のCSSについて誤解があるような空気も感じるのでその理由を説明したい2。JSXと同じで嬉しさを理解して使い慣れればなんてことはないのだけど、一方でその背景にある話はJSXより複雑なので単純に使って慣れればいいという話でもなさそう。 なお、この記事は私の以下の2ツイートを膨らませたものです。 Tailwind CSS、剥がすのは大変そうだけどそれをもって重大な負債になると評せるかは微妙に思っている https://x.com/aumy_f/status/18220941478532

                          • 新人プログラマ アンチパターン:原理原則多すぎて脳みそOOMエラー - Qiita

                            この記事で伝えたいこと(忙しい人向け) 新人ほど「保守していく」ことの感覚が腹落ちしにくいのではないか説 我々は保守しやすいコードを書くべきであり、保守しやすいコードを達成するための手段として原理原則やデザインパターンが存在している 保守ってなんで必要なんだっけ?という体系的な理解を持ったうえで、具体的なテクニックを学んでいくことが大事 // 追記(2023/12/9) なんとミノ駆動 さんにコメントいただけました。 もちろん良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方は読んで影響を受けてます。 とってもうれしい。 想定読者 新卒 ~ 2年目くらいまでのプログラミング初心者 Webアプリの保守開発をしているエンジニア 3ヶ月前くらいの自分(未経験からエンジニアになって1年くらい) こんなことないでしょうか 先輩などから原理原則の観点を共有してもらったり、

                              新人プログラマ アンチパターン:原理原則多すぎて脳みそOOMエラー - Qiita
                            • ルールは現場で死にました - The Rules of Programming の読書感想文 - じゃあ、おうちで学べる

                              本日は人生の数ある選択肢のなかから、こちらのブログを読むという行動を選んでくださいまして、まことにありがとうございます。 はじめに プログラミングの世界には多くの指針や原則が存在します。Chris Zimmerman氏の「The Rules of Programming」(邦題:ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール)は、不変の知恵を凝縮した一冊です。これらの原則は、多くの開発現場で活用できる有益な内容となっていると思いました。 The Rules of Programming: How to Write Better Code (English Edition) 作者:Zimmerman, ChrisO'Reilly MediaAmazon 本書は、大ヒットゲーム『Ghost of Tsushima』などで知られるゲーム制作スタジオ、Sucker Pun

                                ルールは現場で死にました - The Rules of Programming の読書感想文 - じゃあ、おうちで学べる
                              • GopherがRust入門したので違いをまとめてみた

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

                                  GopherがRust入門したので違いをまとめてみた
                                • ログ基盤のFluentdをFluent Bitに移行して監視ツールを実装した話 - Mirrativ Tech Blog

                                  はじめまして、Azuma(@azuma_alvin)です。現在大学院の1年生で、2024年2月から4ヶ月間ミラティブのインフラチームにインターンとして参加しました。普段はインフラやMLOpsといった領域に興味があり、最近はVim環境の整備がマイブームです。 本記事では、ログ基盤をFluentdからFluent Bitへ部分移行した経緯とその2種類の監視ツールの実装についてお話しします。 記事の最後に、インターンから見たインフラチームの特徴と私が4ヶ月間で学んだことを紹介しています。興味がある方は末尾までスクロールしてぜひご覧ください。 1. 背景と目的 2. ミラティブのログ基盤について 3. ログ欠損の原因調査 Fluentdのバッファリングの仕組み fsnotifyを用いたバッファリングの観察 負荷試験 日付時刻フォーマットとワイルドカードによるログ欠損 ログ保存とサーバータイムスタン

                                    ログ基盤のFluentdをFluent Bitに移行して監視ツールを実装した話 - Mirrativ Tech Blog
                                  • Utility-first CSS(Tailwind CSS)が合理的であることの説明と、CSSによるUI開発小史

                                    目次 CSS小史 SUIT CSS - 命名規約ベースのCSS方法論 styled-components - CSS in JS Tailwind CSS - Utility-first CSS なぜインラインスタイルではダメなのか まとめ タイムライン 参考リンク CSS小史 CSSでアプリのUIを実装するための手法は、これまでいくかの変遷を辿ってきた。 はるか昔、CSSが生まれて間もないころには、関心の分離という文脈から、FONT要素などの物理タグはよくないものとされ、 コンテンツ(HTML)とスタイル(CSS)をきっちりと分離することが奨励されはじめた。 そこでは、HTMLはあくまで文書であり、CSSのクラスセレクタという接点でコンテンツと見た目が隔離されることで、それらは別世界のものとして管理されていた。 また、大規模サービス開発においていかにCSSを管理するかという問題意識はまだ

                                      Utility-first CSS(Tailwind CSS)が合理的であることの説明と、CSSによるUI開発小史
                                    • CSSのclass名やJavaScriptの関数名を付けるときに役立つ単語リストのまとめ -Classnames

                                      CSSのclass名やJavaScriptの関数名を付けるときに悩んだり、ネタ切れになったことはありませんか? BEM, OOCSS, SMACSSで命名する場合はそれを使用すればよいのですが、特定のテーマ別にグループ化された単語のリストが必要になるときもあります。そんなときに役立つ単語リストをまとめたClassnamesを紹介します。 Classnames Classnamesは、CSSのclass名やJavaScriptの関数名を付けるときに便利な単語をリスト化したものです。MITライセンスで、商用プロジェクトでも無料で利用できます。

                                        CSSのclass名やJavaScriptの関数名を付けるときに役立つ単語リストのまとめ -Classnames
                                      • ケント・ベックに学ぶ良いコードの書き方🗒️ - Qiita

                                        こんにちは、しが あきとし(@akitosihga)です。 先日あるMeetUpで良いコードの書き方について考える機会がありました。 『良いコード』の定義は幅広く様々な解釈があると思います。 その中でも、自分が敬愛するプログラマーのケント・ベックから学んだ事に焦点を当てて良いコードの書き方についてまとめました。 ケント・ベックとは テスト駆動開発(TDD)で有名なプログラマー アジャイル開発におけるエクストリームプログラミング(XP)の考案者としても有名 アジャイル開発関連の書籍に度々登場するCRCを発明したのも彼だったりする 代表的な著書は「テスト駆動開発」「エクストリームプログラミング」 TDDのイメージが強い彼ですが、実はコーディングに対して並々ならぬ情熱を持っているのです。 彼の著書「実装パターン」では以下のように語っています。 『 70年の人生は、20億秒を少し超えるに過ぎない。

                                          ケント・ベックに学ぶ良いコードの書き方🗒️ - Qiita
                                        • 『GitHub CI/CD実践ガイド』でGitHub ActionsとCI/CDを体系的に学ぼう - 憂鬱な世界にネコパンチ!

                                          『GitHub CI/CD実践ガイド――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用』という書籍を最近出版したので紹介します。本書ではGitHub Actionsの実装と、CI/CDの設計・運用を体系的に学べます。一粒で二度美味しい書籍です。筆者個人としては「実践Terraform」以来、4年半ぶりの商業出版になります。 gihyo.jp どんな本? GitHub利用者にとって、もっとも導入が容易なCI/CD向けのソリューションはGitHub Actionsです。GitHub Actionsの活用事例は多く、検索すればたくさん情報が出てきます。ただ断片的な情報には事欠かない反面、体系的に学習する方法は意外とありません。CI/CD自体がソフトウェア開発の主役になることもまずないため、なんとなく運用している人が大半でしょう。そこで執筆したのが『GitHub CI/

                                            『GitHub CI/CD実践ガイド』でGitHub ActionsとCI/CDを体系的に学ぼう - 憂鬱な世界にネコパンチ!
                                          • HTML,CSS初めて1ヶ月ぐらいの人に知って欲しいCSS設計のこと - Qiita

                                            「HTML,CSSだって難しいよ!」 初心者でも始めやすいって言ったの誰ですかね。最初は覚えるのに必死だし、少しわかるようになったかな?で始めたサイト制作(コーティング)もエラーだらけで頭を抱える日々。そんな修行を耐えているみなさんに知ってほしい、CSSの設計についてお話できたらなと思います。概念的なこと中心になりますので細かいことは下記の参考文書をご覧ください。 『インプレス社 Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法 谷拓樹著 2022年発行第1版』 注意 作者自身もプログラミング初めて1ヶ月の超初心者です。HTML、CSSを使ってデザインカンプを元にサイトを作れるぐらいのレベルです。なので僕より歴長い人はスルーしてもらっていいです。まだ初めたばかりの人は追いついてきてください。僕は先に行ってます。 初め 壊れない完璧な設計を

                                              HTML,CSS初めて1ヶ月ぐらいの人に知って欲しいCSS設計のこと - Qiita
                                            • 技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先?(後編)

                                              技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先?(後編) ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 この記事ではそのダイジェストを紹介します。記事は前編と後編の2つに分かれています。今お読みの記事は後編です。 森崎氏による補足説明 前編では、グループA(命名的問題)より、グループB(構造的問題)の方が正答率が大きいということ。一方でグループA(命名的問題)よりグループB(構造的問題)の方が読みにくさを感じた、という点に統計的に有意な差があったことが発表されました。 発表の後、オンラインイベントの参加者からの質問について森崎氏と和田氏

                                                技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先?(後編)
                                              • Reactベストプラクティス: react-hooks/exhaustive-depsのエラーを0にする - Hello Tech

                                                javascripter です。ハローでは、プロダクトのローンチ前からAutoReserve の開発に関わっています。 今回は、筆者が社内で書いている技術ガイドラインについて紹介します。 はじめに ハローでは、高品質なコードを維持し、開発チームの技術レベル向上を図るため、社内で継続的に技術Tipsやガイドラインの整備・蓄積を行っています。 チーム横断的に、有用な技術Tips、ベストプラクティス・コーディングガイドラインなど情報をNotion上に集約し、自由にエンジニアが閲覧・編集できるようになっています。 この取り組みの目的は以下の通りです: コード品質の向上と統一 開発チームメンバーの技術スキル向上 「どう」直すかでではなく「なぜ」そう修正すべきかまで理解してる人を増やす 効率的な開発プロセスの確立 新メンバーのオンボーディング支援 今回紹介するドキュメント 今回は、その中から「reac

                                                  Reactベストプラクティス: react-hooks/exhaustive-depsのエラーを0にする - Hello Tech
                                                • めざせコントリビューター【完全攻略本】

                                                  ああ あこがれの コントリビューターに なりたいな ならなきゃ ゼッタイなってやるーッ! 「はじめまして! プログラミングの せかいへ ようこそ!」 「わたしの なまえは ヤマダ」 「ひごろは Yamada UI Next.js Chakra UI Mantine Refine のコントリビューターをして おるよ」 改めまして、『まだマサラタウンにいるプログラマーのみなさん』こんにちは。プログラマーを始めて3年目の山田です。 今回は、みんなが憧れるOSSのコントリビューターになる、『1番道路』へ踏み入れるための完全攻略本です。そして、日本で大注目されている(はず)のYamada UIを題材にして進めていこうと思います。 また、この完全攻略本では以下の内容は省略しています。 OSSとは OSSに貢献することのメリット GitHubの使い方 Gitの使い方 理由は、この攻略本を見ているあなたは

                                                    めざせコントリビューター【完全攻略本】
                                                  • 「”><SCRIPT SRC=HTTPS://MJT.XSS.HT> LTD」という名前の企業が強制的に社名を変更させられた事例

                                                    社名にHTMLスクリプトタグを採用したソフトウェア開発企業が、企業登記所から「データベースの脆弱(ぜいじゃく)性につながる」として社名変更を強制されたという事例が、ソーシャルニュースサイトのHacker Newsで話題となっています。 Company forced to change name that could be used to hack websites | UK news | The Guardian https://www.theguardian.com/uk-news/2020/nov/06/companies-house-forces-business-name-change-to-prevent-security-risk UK govt aims to kill off Bobby Tables in Companies House name rules https:

                                                      「”><SCRIPT SRC=HTTPS://MJT.XSS.HT> LTD」という名前の企業が強制的に社名を変更させられた事例
                                                    • Pull Requestのレビュー負荷を軽減し、開発生産性を向上するためにチームで取り組んだこと - ZOZO TECH BLOG

                                                      はじめに こんにちは。WEARフロントエンド部Webチームの藤井です。私たちのチームでは、WEARのWebサイトのリプレイスと新規機能の開発を並行して進めています。これらの開発を推進する中で、Pull Requestのレビュー負荷を軽減し、開発生産性を向上させるための取り組みを行なってきました。本記事では、その中で効果的だった取り組みについてご紹介します。 目次 はじめに 目次 背景と課題 レビューの体制の薄さ スコープの広さ 仕様把握の負担 対応内容についての説明不足 処理の複雑性 仕様の抜け漏れ 動作確認の手間 課題解決に向けた取り組み レビュー体制の見直し Pull Requestを小さくする Issueを小さくする Pull Requestの粒度について明文化する 機械的なチェックの拡充 ESLintルールの拡充 Visual Regression Testの拡充 Pull Req

                                                        Pull Requestのレビュー負荷を軽減し、開発生産性を向上するためにチームで取り組んだこと - ZOZO TECH BLOG
                                                      • Terraform 公式がスタイルガイドを出したので読んで要約した - Qiita

                                                        3/30 に X で Terraform がトレンド入りしていて何事かと思ったら Terraform が公式ドキュメントとしてスタイルガイドを出したようです。 Terraform Style Guide いままで Terraform のスタイルに関して信頼できるドキュメントといえば Google Cloud の Terraform を使用するためのベスト プラクティス ぐらいしか知らなかったのですが、 Terraform 公式がようやく出してくれてありがたい限りです。 これでわざわざ社内の Terraform 規約を設けずとも「公式ドキュメントに従いましょう。」の一言で済みます。 ということで一通り読んだのでまとめました。 原文だと構文の簡単な使い方なども書いてありますが以下の要約ではだいたい省略しています。 詳細は原文を読んで確認してください。 要約 スタイルガイドについて コードのスタ

                                                          Terraform 公式がスタイルガイドを出したので読んで要約した - Qiita
                                                        • なぜCDKを使う「べき」なのだろう? - Uzabase for Engineers

                                                          はじめに 皆様こんにちは、ソーシャル経済メディア「NewsPicks」(Media Infrastructureチーム)エンジニアの北見です。 現在、私は弊社サービスの一部のインフラ刷新を行なっている最中で、ここ数ヶ月 AWS CDKを触っておりました。 前職では Infrastructure as Code として Terraform を使ったことがあるのですが、少なくともAWS を使うという条件においては CDKを使うべき という結論に辿り着きました。 今回はそのように考えるようになった理由について説明していこうと思います。 前提 Terraform はパブリッククラウドにおける Infrastructure as Code の走りとして様々な現場に導入実績があり、それに対するリスペクトは持つべきです。 しかしよくある「AvsB」というメリデメの構図で「どっちでもいいよ、好みだよ」と投

                                                            なぜCDKを使う「べき」なのだろう? - Uzabase for Engineers
                                                          • Next.jsを4年間使用してたどりついた、エンタープライズアプリケーションのフロントエンド開発・構築手法 | POSTD

                                                            はじめに 目まぐるしく進化するフロントエンド開発の世界では、常に最新の知識や技術をいち早く取り入れることが、エンタープライズアプリケーションの開発を成功させる上で欠かせません。Tailwind CSS、TypeScript、Turborepo、ESLint、React Queryなどを含む強力なツールキットとNext.jsを4年間使用してきた結果、開発に役立つさまざまな知見やベストプラクティスが得られました。この記事では、大企業向けフロントエンドアプリケーションのパフォーマンス、保守性、拡張性を最大限に高める設計・構築手法を紹介したいと思います。 注記:ここに記載する内容はあくまでも個人的な見解であり、筆者が推奨する手法が必ずしも適さない場合もあります。 効果的なエンタープライズ向けフロントエンドアーキテクチャの基本原則 エンタープライズ規模のアプリケーション向けにフロントエンドソリューシ

                                                              Next.jsを4年間使用してたどりついた、エンタープライズアプリケーションのフロントエンド開発・構築手法 | POSTD
                                                            • 君たちの知らないAPIデザインパターンの話をしよう

                                                              このように、REST の設計原則に従って API を構築することで、ほとんどの API 設計は直感的に、かつ問題なく行うことができます。 デザインパターンの紹介 ここからが本題です。大抵の場合、上の例で示したような API 設計で十分です。 ただ、複雑な要件では、上のような典型的な API 設計のみでは良いAPIを設計するための4つの特性を満たせないことがあり、そのような場合のためにデザインパターンが有効です。 カスタムメソッド 概要 カスタムメソッドは、標準的な CRUD 操作(作成、読み取り、更新、削除)では対応できない特定の操作が必要になる場合に便利です。例えば、メールの送信や即時の文書翻訳など、通常の create や update メソッドでは処理が難しい操作がこれに該当します。 参考までに、以下に Google が出しているカスタムメソッドの記事を示します。 実装例 以下は、カ

                                                                君たちの知らないAPIデザインパターンの話をしよう
                                                              • 祝🎉 POSIX.1-2024 (Issue 8) 改定!16年ぶりの大幅改定でシェルスクリプトはどう新しくなるのか? - Qiita

                                                                FreeBSD では 2024-05-31 に 200112 から 200809 への変更がようやく行われました(一度間違えて 200808 と書いてしまっていますが)。 https://cgit.freebsd.org/src/commit/?id=2e30926a68 https://cgit.freebsd.org/src/commit/?id=6e0278408e macOS は FreeBSD のユーザーランドのコマンドを使用しているため、そのせいで 200112 のままだった可能性も考えられますが、シェルやカーネルは FreeBSD のものではないため、FreeBSD が変更になったからと言って macOS が更新されるとは限らないでしょう。Solaris 10 と 11 ではディレクトリごとに準拠バージョンが異なるバイナリが配置されており以下のようになります。Solaris

                                                                  祝🎉 POSIX.1-2024 (Issue 8) 改定!16年ぶりの大幅改定でシェルスクリプトはどう新しくなるのか? - Qiita
                                                                • VSCode 中級者になるための Tips 集 - Adwaysエンジニアブログ

                                                                  こんにちは! エージェンシー事業部でアプリケーションエンジニアをしている23新卒の森田です! 4,5年前に Atom から VSCode に乗り換えてすっかり VSCode のことを相棒だと信じ、もう知らぬことはないとそう思っていました。 しかし、今年エンジニアとして業務で VSCode を使用していると、「あれっ、そんなこともできるの?」と日々相棒の新しい機能を発見しています。 完全に理解したと思ったところからさらに新しい面に気づかせてくれる VSCode は最高の相棒ですね!! そんなところでこのブログでは、VSCode を完全に理解した VSCode 初心者の僕が、VSCode やっぱわからん VSCode 中級者になるために使いこなす必要がありそうだなと思った機能の Tips 集をご紹介します。 筆者の環境は以下のとおりです。 Mac Apple シリコン Ventura 13.3

                                                                    VSCode 中級者になるための Tips 集 - Adwaysエンジニアブログ
                                                                  • AWS CodeBuildのGitHub Actions runnerサポートでLambdaが実行できるようになったので検証しました | CyberAgent Developers Blog

                                                                    AWS CodeBuildのGitHub Actions runnerサポートでLambdaが実行できるようになったので検証しました CTO統括室の黒崎(@kuro_m88)です。本日早朝に面白そうな発表を目にしました👀 AWS CodeBuild now supports managed GitHub Action runners AWS CodebuildがGitHub Actionsに対応したという内容ですが、要するにAWSがホストするGitHub Actions Runnerが出たということですね🎉 AWSがマネージしてくれることで、EC2(x64, arm)はもちろん、GPUとカスタムイメージも利用できるようです。 さらに注目したのはGitHub Actions RunnerとしてAWS Lambdaが使えるようです。Lambdaが使えると嬉しいポイントはActionsのjo

                                                                      AWS CodeBuildのGitHub Actions runnerサポートでLambdaが実行できるようになったので検証しました | CyberAgent Developers Blog
                                                                    • もう一度読むObservability Engineering - じゃあ、おうちで学べる

                                                                      はじめに 本書『Observability Engineering』は、複雑化の一途をたどる現代のソフトウェアシステムに立ち向かうための、強力な武器となる一冊であり本稿はその読書感想文です。Observability Engineering を今から知りたい方はもちろん、Observability Engineering の基礎を改めて学びたい方もぜひお読みください。この記事もかなりの長さになるので普通に書籍を読んだほうがいいかもです learning.oreilly.com 「Observability:可観測性」という言葉は、近年ソフトウェアエンジニアリングの世界で大きな注目を集めています。しかし、その概念の本質を理解し、実践に移すことは容易ではありません。 本書は、そのオブザーバビリティについて、その基本的な考え方から、具体的な実装方法、そして組織への適用まで、幅広くかつ深く解説して

                                                                        もう一度読むObservability Engineering - じゃあ、おうちで学べる
                                                                      • 理解しやすいコードの書き方~理解容易性の7つの観点~ - Qiita

                                                                        はじめに 「理解容易性」は「保守性」の観点の1つとして重視され、多くの原則や技法が紹介されているが、断片的かつ多様であり、全体像を理解することは難しい。 抽象度は高いが、体系的に観点を整理する事で、その理解の助けとなれば幸いである。 定義 「理解容易性」を簡単に言えば、「理解のしやすさ」であるが、その意味から掘り下げると、「思考する量」と言い換えることができる。 本記事では理解容易性を「思考量の少なさ」と定義し、7つの観点に整理した。 先に要約およびチェックリストを記載し、概略を記載した。 後に詳細で理解のため、各観点毎の説明と個別の原則や技法へのリンクを記載した。 要約 7つの観点の要約を先に示す。 (変数や関数の)名称は分かりやすくする (変数や関数の)役割は1つにする (変数や関数の)参照は狭くする (変数や関数の)状態は変えられなくする (関数やクラスの)面積は小さくする (関数や

                                                                          理解しやすいコードの書き方~理解容易性の7つの観点~ - Qiita
                                                                        • エンジニアが開発しやすい環境作り - Qiita

                                                                          はじめに 自分は現在、システム開発会社にて執行役員としてプロジェクトマネジメントやコンサルをしています。 今までのプロジェクトから得た経験を元に、エンジニアが開発しやすい環境作りについて、自分なりにまとめていきます。 対象者 エンジニアチームのモチベーションを上げたい人 エンジニアチームにとって開発しやすい環境作りを知りたい人 お断り 今回紹介するのは自分が実践してきた一例であり、必ずしも正解というわけではありません 「こうしなさい」ではなく「こうするとより良くなるかも」といったモチベで書いています GitHubで開発を進める前提 目次 ドキュメント整備 issueの作成 開発環境の整備 コードレビュー プロジェクトの開発進捗の管理について ドキュメント整備 まずはじめに、エンジニアが開発に入る際に必ず見る「README」の書き方を説明していきます。 自分がREADMEを書く時は「プロジェ

                                                                            エンジニアが開発しやすい環境作り - Qiita
                                                                          • 大規模データを扱う現場でどんな変化が? Snowflake導入5社のデータ基盤アーキテクチャと設計意図 - Findy Tools

                                                                            公開日 2024/03/12更新日 2024/07/25大規模データを扱う現場でどんな変化が? Snowflake導入5社のデータ基盤アーキテクチャと設計意図 スケーラビリティやデータ活用までのリードタイム、価格面での懸念に応える製品として注目を集めるSnowflake。特に大規模なデータを取り扱う現場では、Snowflake導入によってどんな変化があるのでしょうか。 本記事では、前回の第一弾でご紹介したChatworkさん、delyさん、GENDAさん、スターフェスティバルさんに引き続き、第二弾として大規模データを取り扱う5社に、データ基盤の設計思想やデータチームの方針にも触れながら、Snowflake導入の背景や効果を伺いました。 株式会社Algoage事業概要株式会社Algoageは、東京大学で機械学習の研究をしていたメンバーで2018年に創業したスタートアップです。AIを活用したサ

                                                                              大規模データを扱う現場でどんな変化が? Snowflake導入5社のデータ基盤アーキテクチャと設計意図 - Findy Tools
                                                                            • meviy に Rust が入りました - DTダイナミクス テックブログ

                                                                              形状認識処理のディレクターを務めている寺田です。昨年10月よりDTダイナミクス(ミスミグループ出資の戦略的IT子会社)のお世話になっています。 私が入社した時点では meviy の形状認識はすべて C++ で書かれていましたが、そこに Rust を導入したというお話です。 Rust で何作ったの? ゴチャゴチャと御託を並べる前に、まずは Rust で何を作ったのかを簡単に紹介しましょう。 大きく分けて下記の3領域に Rust を導入しました。 溶接リモデル機能 平板展開機能 自動テストツール ここでは先頭の「溶接リモデル」について簡単に紹介します。 この機能の内部実装を C++ から Rust に置き換えて、またロジックも大きく変更することによって、溜まっていた不具合を大幅に解消しました。 溶接リモデルとは 溶接リモデル 上図の左がリモデル前、右がリモデル後です。 板金製品は、平らな板金材

                                                                                meviy に Rust が入りました - DTダイナミクス テックブログ
                                                                              • 地球の新しい地質年代「人新世」の新設案を否決 その理由と背景は

                                                                                人類の活動は確実に地球環境を変えてきました。これを踏まえ、新しい地質年代として「人新世」を創設することが提唱され、2009年から国際地質科学連合の作業部会で議論が行われてきました。正式に地質年代として登録されるには、全部で3段階の議論が必要です。 国際地質科学連合の下部組織である第四紀層序小委員会にて2024年2月1日から6週間かけて審議と投票が行われた結果、人新世の創設は過半数の反対票で否決されました。ただし、この決定は人類が地球環境を変えたことを否定するものではなく、むしろ人新世という地質年代の重要性を鑑み、人類による環境改変を過小評価しないための否決であると言えます。 【▲図1: カナダ東部にあるクロフォード湖の湖底堆積物は、今回の案で人新世の基準となる地層として選ばれていました(Credit: Whpq (WikiMedia Commons / CC BY-SA 4.0) )】■新

                                                                                  地球の新しい地質年代「人新世」の新設案を否決 その理由と背景は
                                                                                • 開発効率を追い求めた実装プラクティス集

                                                                                  この記事は MICIN Advent Calendar 2023 の24日目の記事です。 前回はSaneさんの「データ基盤チームで社内インターンをやってみて」でした。 はじめに abekohです。MICINでMiROHAの開発をしております。 本記事では、書籍等から得た設計・実装パターンの知識や、実際にプロダクト開発で試して得られた経験などから編み出した、開発効率向上のためのWeb API開発のプラクティスを紹介します。 筆者が関わっているMiROHAは治験の業務支援を取り扱うプロダクトです。MiROHAの開発における特性として、以下のようなものが挙げられます。 治験業務に関するドメインが特有で複雑 前例が少なく、MVPを追求中。プロダクトのアプローチが頻繁に変わる 外部品質は高い水準が求められる これらの特性を意識して開発を促進させるために日々試行錯誤しております。 複雑なドメインに対す

                                                                                    開発効率を追い求めた実装プラクティス集