並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 18 件 / 18件

新着順 人気順

コードの検索結果1 - 18 件 / 18件

  • 脳に収まるコードの書き方を読んだ。面白かった。 - Mitsuyuki.Shiiba

    いただきましたー!わーい。脳に収めるぞー! @haradakiro @ryuzee pic.twitter.com/3Qd6EvPioU— SHIIBA Mitsuyuki (@bufferings) June 13, 2024 明日(2024年6月18日)発売! www.oreilly.co.jp どう書くのがいいんだろうなぁ? 複雑なコードと向き合うときは「あー、これはメモを取りながら読まないと迷子になるやつだ」ってなる。最初はわりとキレイに作られていたとしても、機能追加を重ねていくとだんだん読めなくなっていく。 だから「時間が経っても読みやすいコードってどう書くのがいいんだろうなぁ?何かヒントがあるかなぁ?」って思いながらこの本を開いた。先に書いておくと、ヒントはあった。 アウトサイドインのTDD 全然予想してなかったから、おー!と思ったのが、説明をTDDで進めていくってところ。好き

      脳に収まるコードの書き方を読んだ。面白かった。 - Mitsuyuki.Shiiba
    • C言語をマスターしたい人はGCCのバージョン14を使いましょう - pyopyopyo - Linuxとかプログラミングの覚え書き -

      C言語(C++を含む)を習得したい人,ポインタを勉強したい人はgcc-14を使いましょう.難しいところは gcc-14 が丁寧に解説してくれます C言語の難しいところ 例を示します.C言語で記述された,たった6行のソースコードです int main() { int buf[10]; buf[10] = 0; return 0; } このソースコードには問題があります.初見でわかるでしょうか? : : : 問題があるのは buf[10]=0 の部分です.C言語でやりがちなミスですが,これがバグやセキュリティホールの原因になります. C言語が難しい理由は二つあります.この手の問題を見逃しやすい点と,この手の問題を理解することが難しい点の二つです gcc 14 に解説してもらいましょう 上記の6行のソースコードをgcc14を使ってコンパイルしてみます ソースコードのファイル名は test.c と

        C言語をマスターしたい人はGCCのバージョン14を使いましょう - pyopyopyo - Linuxとかプログラミングの覚え書き -
      • 2024年版「基本的なウェブアプリケーションを構築する」のチュートリアル手順まとめてみた[Amplify Gen2対応] | DevelopersIO

        初めてAWSのサーバレスサービスを学習するときに利用できる「基本的なェブアプリケーションを構築する」の内容を2024年現在でも実行できる手順にしてみました こんにちは、臼田です。 みなさん、AWSのチュートリアル活用してますか?(挨拶 今回はAWSの初心者向けハンズオンコンテンツである基本的なウェブアプリケーションを構築するを2024年の現在版の手順としてまとめてみました。 このコンテンツはAWSのサーバレスなサービスを利用して、簡単にウェブアプリケーションを作成する体験ができるチュートリアルとなっており、登場するAWSの各サービスを理解するのにちょうどよい内容でした。しかし、リリースされてしばらく経っているのもあり、特に今回のAmplify Gen2リリースもあってだいぶ画面や操作方法などが変わってしまいました。 実現できる事自体は変わらないので、現時点でこのチュートリアルを初心者でも完

          2024年版「基本的なウェブアプリケーションを構築する」のチュートリアル手順まとめてみた[Amplify Gen2対応] | DevelopersIO
        • 『ルールズ・オブ・プログラミング』を読んだ #iknowtherulesjp - Don't Repeat Yourself

          Ghost of Tsushimaなどを作った会社の人が書いた本です。ゲーム開発におけるコードを書く際の教訓を整理し、改めて示し直したいい一冊だったと思います。大事なことですが、著者は決して「このルールを絶対使え」と言っているのではなくて、そもそもまず会社の製品の特性上、このようなルールを敷いておくと品質や生産性を高く保てたという前提があり、その前提を元に「ルールを選び取って自分たちのコーディング哲学を構築しよう」と推奨しています。 ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール 作者:Chris Zimmermanオーム社Amazon この手の本では『リーダブルコード』がよく薦められる傾向にあると思います。私にとってもリーダブルコードは確かに駆け出しの頃すごく役に立った記憶はあるのですが(もう10年くらい前に読んだので正直忘れた)、そこから知識がアップデートされ

            『ルールズ・オブ・プログラミング』を読んだ #iknowtherulesjp - Don't Repeat Yourself
          • GPT-4oをOCRとして使う - Re:ゼロから始めるML生活

            OpenAIからChatGPT-4oが発表されましたが、皆さんガンガンつかっていますでしょうか? さて、このChatGPT-4oですが、テキスト以外のデータも使用できるようになっているという特徴があります。 普通にテキストでのやり取りをしつつも画像データを扱えるということで、「実はこれいい感じのOCRとして使えるんじゃね?」って思っちゃったわけです。 ということで、今回はChatGPT-4oを使ってOCRを使うとどんなもんなのかやってみたいと思います。 やりたいこと やってみる とりあえずやってみる 請求書 名刺 参考文献 感想 やりたいこと 今回やりたいことはOCRです。早い話が画像ファイルを突っ込んでテキストを読み取りたいって感じです。 ただ、当たり前のようにOCRって言葉を使用していますがOCRって結構奥が深いです。 mediadrive.jp 単純に画像から文字を見つけて対応するテ

              GPT-4oをOCRとして使う - Re:ゼロから始めるML生活
            • エンジニアからマネージャになったときにあるだろうなぁってことを想像して遊ぶ - Mitsuyuki.Shiiba

              ソフトウェアエンジニアの話ね。想像して遊んでるだけね。 スキルは高い まず、マネージャになってほしいって言われる時点で「仕事を任せられる」というエンジニアなんだろうな。それは、つまりコードを書くことに加えて、プロダクトをなんとかしてリリースする力と責任感をもっていて、それが会社にとってプラスになっている。 だから、チームを任せて同じようなエンジニアを育てて欲しいと期待されている。自分自身も、自分のスキルをもっと会社の役に立てるぞー!とやる気になっている。 任せたい そういう人がマネージャになって、あるだろうなぁと思うのは「どう任せたらいいんだろう?」という悩み。 自分が手を動かせばプロジェクトがなんとかなるのは分かっている。でも、自分はマネージャの仕事があるし、そこは自分の役割ではないし、実際のところ手を動かす時間なんてない。それはメンバーにやってもらわないといけない。 ただ、だいたいの場

                エンジニアからマネージャになったときにあるだろうなぁってことを想像して遊ぶ - Mitsuyuki.Shiiba
              • 良いコードってどんなコードですか?という質問を受けたら何と答えるか - snoozer05's blog

                技術顧問先で、一生懸命コードに向き合っているプログラマーになりたての方から、次のような質問をもらいました。 最初に面談した時、1年後にいいコードが書ける、上手に書けることを目標にしましたが、 先日スクール時代の同期(それぞれRubyの会社で働いている)と話したところ、会社ごとにレビューの仕方やコードに関する基準がさまざまなようで、良いコードとはなんなのか疑問に感じました。「いいコード」とは、みたいな部分で島田さんの考え方をお聞きできたら嬉しいです。 この質問にぼくは次のような回答をしたのですが、「この質問が来たら他の人はどんな回答するんだろうな」に興味があるので、ここにしたためておきます。もしよかったら「若者にこれを聞かれたら自分ならこう答える」をコメントなどで残していってもらえたら嬉しいです。 とても大事な疑問を見つけられたんだなあと思います。 「良さとは何か」ということに向き合う必要の

                  良いコードってどんなコードですか?という質問を受けたら何と答えるか - snoozer05's blog
                • 「コードに早まってDRY原則を適用しないこと」とGoogleが呼びかけ

                  Googleに存在するコードを読みやすく保守しやすい形に保つ取り組みを行うグループ「Code Health」が、「DRYを早まって適用しないこと」と題した記事を公開しました。 Google Testing Blog: Don't DRY Your Code Prematurely https://testing.googleblog.com/2024/05/dont-dry-your-code-prematurely.html DRYは「Don't Repeat Yourself」の略称で、コードを重複させないことを重視する考え方です。重複するコードが存在していると、特定の機能を変更しようとした時に同じ機能を持つ部分を全て探して同時に変更する必要があり、見落としやミスが発生する危険性が高まります。一方、コードの重複を防げていれば一カ所だけを変更すればOKというわけ。 一見DRYを厳しく適用

                    「コードに早まってDRY原則を適用しないこと」とGoogleが呼びかけ
                  • 社内に詳しい人がいない領域のコードを触る時 - Konifar's ZATSU

                    自分も含めて社内に詳しい人がいない領域のコードをいじることってあるよね。特に歴史の長いサービスだと当時触っていた人が誰もいないとか。仮にいたとしても1年くらい触ってないとほとんど忘れてしまって知らないのと同じような状態になっていたりする。 自分もそういうことが何度もあって、雑にスタンスややってることをまとめておこうと思う。 前提のスタンス 「これを倒したら俺がこの領域で一番詳しい最強になるんや」という気持ちを持ってる 詳しい人がいない状態で属人化とか気にしても仕方ない。まずは自分が詳しくなってから考えるでよい 自分用メモを作る キャッチアップしたことを書き残していく。ドキュメントじゃなくてSlackに垂れ流すでもいい 過去のドキュメント・やりとりを探す 全体像を把握できるドキュメントがないかを探すのを最初にやってる ここは近道はない。とにかく全部集めて全部読む気持ちで臨む Google D

                      社内に詳しい人がいない領域のコードを触る時 - Konifar's ZATSU
                    • JavaScript 実行エンジン V8 の JIT 出力コードを読んでみよう

                      Chrome の JavaScript はとても高速なことでも有名ですが、その実行エンジンは V8 と呼ばれます。V8 自体は独立したモジュールであり、Node.js 等にも使われております。 V8 が JavaScript を高速に実行する技術の一つが JIT (Just In Time) コンパイルです(一般的に JIT と呼ばれます)。これは、そのまま実行すると遅い JavaScript を実行中にリアルタイムに直接マシンコードに変換し(これが Just In Time と呼ばれる所以です)、途中からそのコードに入れ替えて実行することで高速化を達成しています。特に何度も実行される関数で効力を発揮します。 JIT という名前は聞いたことがあろうとも、実際に JIT がどのようなコードを実行しているのかを確認する機会は滅多にないでしょう。この記事では、実際に V8 の JIT の出力を確

                      • すべてのコードやライブラリ自体が技術的負債である / 高利率な技術と低利率な技術 - Lambdaカクテル

                        技術的負債という言葉がある。もともとは、「楽するために導入したが、メンテにコストがかかるようになってしまった技術や構成」くらいの意味合いで使われているように思う。しかし、そもそも全部が負債ではないか、というのがこのメモの趣旨である。 負債 同僚とSlackで会話していると、「けっきょくどの言語を利用しても負債になるときはなるし、大抵負債になる」といった話になった。言われてみればそうで、基本的にコードというものは書いたそばから負債になっていく。去年書いたコードのことも思い出せない。 そんな中で思ったのだが、そもそも、負債になるコードと負債にならないコードとがあったり、技術が「負債化する」のではなく、コードや技術そのものが負債なのではないか。そして、どの言語で書こうが負債からは逃れることができない。負債にならないコードは存在しない。ゆえに、コードや技術は無ければ無いほど良い、ということになる。

                          すべてのコードやライブラリ自体が技術的負債である / 高利率な技術と低利率な技術 - Lambdaカクテル
                        • ARM に存在する JavaScript 専用命令「FJCVTZS」を追う(ついでに V8 をビルドする)

                          前回の記事では、JavaScript の実行エンジン V8 の JIT 出力コードを読んでみました。記事は M1 Mac 上で動かした結果でしたので、ARM アーキテクチャのアセンブラを読むことになりました。 さてそんな ARM アーキテクチャですが、最近の ARM には FJCVTZS という JavaScript 専用の機械語命令があるのをご存知でしょうか?CPU に、特定の言語(それもコンパイラを持たない JavaScript)専用の命令があると知ったとき、私は大いに驚きました(過去にも Jazelle みたいなものはありましたが) 今回は、この FJCVTZS 命令について、実際にどれだけ効果があるのか、V8 をビルドしながら調べてみましょう。 FJCVTZS 命令とは? FJCVTZS 命令は、Arm v8.3 から導入された JSCVT 命令の一つで、JavaScript の言

                          • 【超初心者向け】Pythonのテストの書き方(pytest, unittest) - Qiita

                            概要 pythonでテストコードを書くときがありますが、(筆者のように)超初心者からすると難しい用語や書き方がたくさん並んでいてハードルが高いです。 テストコードの入口となる最低限(最低限過ぎるかもしれませんが)の書き方を備忘を兼ねて書きます。 pythonでのテストコードを書く時のライブラリの種類 筆者が簡単に調べたところ、2つのライブラリがよく使われているようです。 unittest : python標準ライブラリ。インストールが必要ない。pytestと比較すると、柔軟なテストケースを書きづらい。 pytest : サードパーティ製のライブラリ。インストールの必要がある。柔軟なテストケースが書ける。pythonのテストコードを書く時のデファクトスタンダートになりつつある模様(これが本当かは確認していないですが、そういう記述を見かけることが多かったです)。 筆者個人としては、以下の3つの

                              【超初心者向け】Pythonのテストの書き方(pytest, unittest) - Qiita
                            • Don't DRY Your Code Prematurely

                              TotT 98 GTAC 61 James Whittaker 42 Misko Hevery 32 Anthony Vallone 27 Code Health 27 Patrick Copeland 23 Jobs 18 Andrew Trenk 12 C++ 11 Patrik Höglund 8 JavaScript 7 Allen Hutchison 6 George Pirocanac 6 Zhanyong Wan 6 Harry Robinson 5 Java 5 Julian Harty 5 Alberto Savoia 4 Ben Yu 4 Erik Kuefler 4 Philip Zembrod 4 Shyam Seshadri 4 Adam Bender 3 Chrome 3 Dillon Bly 3 John Thomas 3 Lesley Katzen 3 Ma

                                Don't DRY Your Code Prematurely
                              • GitHub Copilotと快適なユニットテストコード作成生活

                                こちらで登壇させていただいた資料です。 https://trident-qa.connpass.com/event/314818/ ※ こちらは2024/05/23 時点の私の考えとなります。更新の予定はございませんのでご了承ください

                                  GitHub Copilotと快適なユニットテストコード作成生活
                                • これは簡単で便利! レスポンシブ対応のフォントサイズをCSSのclamp()関数で定義できるツール -Type Fluidity

                                  フォントサイズをレスポンシブ対応にするときに、最近よく使用されている実装方法はclamp()関数による流体タイポグラフィです。CSSのclamp()関数を使用するとフォントサイズの最小値と最大値を定義してその間の値を流動的にすることができ、デバイスのスクリーンサイズが増えた現在に欠かせないテクニックです。 CSSでレスポンシブ対応のフォントサイズを超簡単に定義できるオンラインツールを紹介します。 Type Fluidity -GitHub Type Fluidityの特徴 Type Fluidityの使い方 Type Fluidityの特徴 流体タイポグラフィ(Fluid Typography)は、フォントサイズをレスポンシブ対応にする最新テクニックです。さまざまなスクリーンサイズに応じて固定値を定義する代わりに、CSSで単一の流体値を定義して、フォントの最小値と最大値の中でスクリーンサイ

                                    これは簡単で便利! レスポンシブ対応のフォントサイズをCSSのclamp()関数で定義できるツール -Type Fluidity
                                  • CSSはどんどん進化している! マグネットのようにくっつくエフェクトを実装するテクニック -CSS Anchor Positioning

                                    ナビゲーションのアイテムをホバーした時にマグネットのようにくっついてスライドさせるエフェクトをCSSで実装するテクニックを紹介します。 これまでは、JavaScriptがないと実装できないエフェクトでした。レスポンシブにも完全対応、アイテムが二段・三段と複数になっても、水平・垂直になってもエフェクトは追従します。 Anchor Magnet Slide Menu 実際の動作は、デモページでお楽しみください。 右上の矢印アイコンをクリックすると、アイテムの並びが垂直・水平になります。また、右下のアイコンをクリックすると、ダーク・ライトモードになります。 ※CSSのみで動作するのは、Chrome 125+です。それ以外のブラウザはポリフィルが使用されています。 See the Pen Anchor Magnet Slide Menu by coliss (@coliss) on CodePen

                                      CSSはどんどん進化している! マグネットのようにくっつくエフェクトを実装するテクニック -CSS Anchor Positioning
                                    • AIで簡単に実装コードを生成できる! テキストからCSSアニメーションのコードを生成できるツール -AI CSS Animations

                                      簡単にCSSアニメーションのコードを生成できるAIツールが登場しました。テキストや音声でプロンプトを入力するだけで、複雑なCSSアニメーションでも数秒でコードが生成されます。 生成されたCSSアニメーションはその場ですぐ...記事の続きを読む

                                        AIで簡単に実装コードを生成できる! テキストからCSSアニメーションのコードを生成できるツール -AI CSS Animations
                                      1