並び順

ブックマーク数

期間指定

  • から
  • まで

241 - 280 件 / 2670件

新着順 人気順

subversionの検索結果241 - 280 件 / 2670件

  • 個人的PCまわりセットアップまとめ - Qiita

    これは何 備忘録も兼ねて、PCのセットアップで自分のやることをまとめてみました。 随時更新していく予定です。 VS Code VS Codeの環境設定 setting.jsonに下記を追加します。 内容はコメントで書いているので、詳細は省きます。 { "editor.fontSize": 12, // フォントサイズを変更 "editor.guides.bracketPairs": true, // 対応している括弧にガイドを表示する "editor.minimap.renderCharacters": false, // ミニマップに実際の文字を表示しない "editor.renderControlCharacters": true, // 制御文字を表示する "editor.renderLineHighlight": "all", // 現在の選択行をハイライトする "editor.r

      個人的PCまわりセットアップまとめ - Qiita
    • git の develop ブランチは必要なのか、またはリリースtagについて

      songmu @songmu feature branchか、feature flagかっていうのは実は結論のない話なんだろうな、とは思ってる。僕はfeature branchに慣れすぎてしまったけど 2019-10-26 15:32:59 Kazunori Otani @katzchang Gitのリポジトリ/ブランチ戦略で確実に言えそうなのは、「分岐した状態をできるだけ短くしよう」で、それを実現するためにはじつはGitだけの問題じゃなかったりするので、みなさんがんばっていきましょう。 2019-10-26 18:03:42

        git の develop ブランチは必要なのか、またはリリースtagについて
      • トヨタ、ユーザーのメアド約30万件漏えいの可能性 ソースコードの一部、GitHubに5年間放置

        トヨタ自動車は10月7日、クルマ向けネットワークサービス「T-Connect」ユーザーのメールアドレスと「お客様管理番号」、29万6019件が漏えいした可能性があると発表した。 2017年7月以降にT-Connectユーザーサイトにメールアドレスを登録した人が該当する。氏名や電話番号、クレジットカード番号などが漏えいした可能性はないという。 原因は2017年12月にT-Connectユーザーサイトの開発委託先企業が、取り扱い規則に反してソースコードの一部を誤って公開設定のままGitHubアカウントにアップロードしたこと。その後、5年にわたって第三者がソースコードの一部にアクセスできる状態で放置されていた。ソースコードにはデータサーバへのアクセスキーが含まれ、これを利用するとサーバに保管しているメールアドレスやお客様管理番号にアクセスできたという。 トヨタは9月15日にGitHub上のソース

          トヨタ、ユーザーのメアド約30万件漏えいの可能性 ソースコードの一部、GitHubに5年間放置
        • 「メンバーを信用していないのでは?」 “ある指摘”から始まったLINEアプリ開発チームの生産性改善施策

          2021年11月10日と11日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2021」がオンラインで開催されました。そこで竹下秀則氏が、大規模クライアントアプリ開発チームの生産性を改善した仕組み化について紹介しました。まずはチームの成長と課題について。 LINEのクライアントアプリ開発チームの効率化事例 竹下秀則氏:みなさん、こんにちは。今日は「大規模クライアントアプリ開発チームの生産性を改善した仕組み化の数々」というタイトルでお話しします。LINE福岡開発1室所属のエンジニアリングマネージャー、竹下と申します。よろしくお願いいたします。 さっそくですが、本日のアジェンダはこちらになります。まずは私がマネージャーとして所属している、今日お話しする改善の舞台となったチームについて紹介します。 次にそこで直面した課題の数々について赤

            「メンバーを信用していないのでは?」 “ある指摘”から始まったLINEアプリ開発チームの生産性改善施策
          • Modern Web Development on the JAMstack を読んでまとめた - console.lealog();

            https://www.netlify.com/pdf/oreilly-modern-web-development-on-the-jamstack.pdf Netlify社が2019年に公開した本?PDFです。 せっかくJamstackの会社に入ったので、読んでおかないといけない気がして。 あとJamstackは人によって解釈が違ったりするとし、Jamstackの真髄について知っておきたいですよね?と思い。 ただこれなんと127ページもあるんですよね〜。 全編もちろん英語なので、読むのも中々に大変ですよね〜。 てなわけで、ざっくり訳してまとめまておきました。(それでも長いけど) はじめに ここ最近のWebの進化はすさまじい ブラウザもJavaScriptもパワフルになった その分ユーザーの要求も増える やることが増えると処理は遅くなる 遅いページは見向きもされないモバイル当たり前の世界だ

              Modern Web Development on the JAMstack を読んでまとめた - console.lealog();
            • 艦これユーザー「さぶれ」氏、SMBCのソースコードをGitHubに公開して失業&損害賠償700万円 | いろいろまとめbeans

              艦これユーザ「さぶれ」氏がツイッターで他のユーザと小競り合い ↓ ネットで面白がった連中に過去の言動が次々掘られる ↓ 「さぶれ」氏が仕事上で開発したSMBCのプログラムソースを、githubに勝手に公開していたことが分かる ↓ 直接企業に被害を与えることはあまり無いようなコードだが、そもそも流出してたという事実自体が 問題視され、ニュースになる ↓ twitterのIDが同じである「さぶれ」氏と思われる人物、賠償金700万円だと明かす 艦これのゲーム配信最大手である「きぃのん」 氏と今回の流出のきっかけとなったS氏がTwitterで論争となります(筆者はきぃのん氏の配信のリスナーです)。煽り合う中で、きぃのん氏の配信のリスナーがS氏の過去のTweetを調査し、S氏のGitHubアカウントを発見します。これを見た同じリスナーの「なぎ」氏 がGitHubに上がっているコードを見たところ「sm

                艦これユーザー「さぶれ」氏、SMBCのソースコードをGitHubに公開して失業&損害賠償700万円 | いろいろまとめbeans
              • RustでつくるGit入門

                Gitの仕組みを学び、Rustで実装する内容をまとめました。 Gitの仕組みの部分は無料公開されています。

                  RustでつくるGit入門
                • ようこそdotfilesの世界へ - Qiita

                  はじめに 少し前から話題になっているが、日本の労働生産性はG7で最も低いらしい。 日本生産性本部資料より https://www.jpc-net.jp/intl_comparison/intl_comparison_2018_press.pdf 日本は人口減少に突入していることもあって、「作業の効率化」や「自動化・省力化」をいうフレーズをあらゆる業種で聞くようになった。 ITエンジニアは、あらゆる職業の中でも最も効率化、自動化をして生産性を高められるといっても過言ではないだろう。プログラマの三大美徳(「怠惰」「短気」「傲慢」)にもあるように、同じことを何度もやらない、楽をするためにがんばるという生産性を意識した感性が重要視されているからだ。 生産性を高めることで、勉強する時間が作れたり、新しいことを経験したりするなどしてさらにスキルアップができ、さらに生産性が上がるという好循環を作り出すこ

                    ようこそdotfilesの世界へ - Qiita
                  • ひさしぶりにzshに戻りました - ちなみに

                    仕事用のマシンをM1 MacBook Proに交換してもらったので、開発環境を整え直しました。 2年ほど fish を使ってきたのだけれど、普段は良いのだけれど、ちょっと自動化したくなったときに、やはりPOSIX準拠じゃないシェルはなかなか難しかった。macOSの標準も zsh になったことだし、久しぶりに戻ってみることにした。 導入 現代なので XDG Base Directory Specification に乗っかっておくことにする。 Arch Linux の Wiki がよくまとまっていて助かるのでこれを参考にして進めた。 zshの場合は ZDOTDIR を指定するといいのだけれど、これをどこで指定するのかという問題がある。zshの起動時に最初に読み込まれるユーザー設定は ~/.zshenv なのだけれど、ここに ZDOTDIR を書くということは .zshenv だけホームディレ

                      ひさしぶりにzshに戻りました - ちなみに
                    • Gitを作ってみる(理解編) - Qiita

                      はじめに 都内でひっそり見習いエンジニアをしている@noshishiです。 addしてcommitするプログラムの作成を通じて、Gitを内部から理解しようという記事です。 前書き 昨年末、Gitの記事を書いて、理解できたなら作れるのではと思いったったのがこの記事の出発点です。 これを機に新しいプログラミング言語にも触れてみて、いろいろ学べたらと思いRustで今回挑戦しました。 (この時は、新たなことを同時に取り組み絶望すること知る由もない著者でした。軽い気持ちで手を伸ばした自分をしばきたいです。。。) 実際に作成した(継続開発中ですが)リポジトリは、こちらです。 ※一応ローカルでの一直線の開発はできそうな程度までは作成できました。コードのしょぼさはご容赦ください。 この記事だけでは説明しきれない部分があることをご容赦ください。 もちろん、間違い等あれば、ぜひコメントいただけると幸いです。

                        Gitを作ってみる(理解編) - Qiita
                      • 最近流行りのカタカナ語は漢字四文字で書ける説

                        エアロゾル→浮遊粒子 オーバーシュート→感染爆発 スーパースプレッダー→感染源者 サーキットブレーカー→市場停止 ロックダウン→都市封鎖 クラスター→集団感染

                          最近流行りのカタカナ語は漢字四文字で書ける説
                        • Gitは最初1244行しかなかった

                          概要 Junio C Hamanoさんに興味を持って調べていると、Linusさんが書いたGitの初版は1244行ということが分かりました。Gitの初版について、軽く行数の確認とビルドチャレンジをして、あまり調べずに動かしながら機能を推測してみました。 はじめに Highlights from Git 2.39 の冒頭で登場するcommit数が一番多い方「Junio C Hamano」さんを知らなかったので調べてみました。 gihyoのインタビュー記事が面白かったです。Junio C HamanoさんはGitのメンテナで、LinusさんからGitのメンテナを引き継いだすごい方だということを知りました。 このgihyoのインタビュー記事の中で「MLで流れてきたGitのコード行数は1244行だった」というところが気になりました。調べてみると、2020年にTwitterでRui Ueyamaさんへ

                            Gitは最初1244行しかなかった
                          • GitHubのURLをちょろっと書き換えるだけでコードを「Visual Studio Code」で閲覧できる素敵なサービスが話題に/トグルするブックマークレットも用意されている【やじうまの杜】

                              GitHubのURLをちょろっと書き換えるだけでコードを「Visual Studio Code」で閲覧できる素敵なサービスが話題に/トグルするブックマークレットも用意されている【やじうまの杜】
                            • Gitハンズオン研修 / Git Hands-on

                              新卒研修で行ったGit理解のためのハンズオン研修資料です。 資料中に出てくるマテリアルはこちら https://github.com/BrainPad/GitForBeginners2020

                                Gitハンズオン研修 / Git Hands-on
                              • GitHubが制作した次世代開発体験のためのコーディングフォント「monaspace」/トレンドを抑えつつ、独自技術「Texture healing」を盛り込んだ最先端のフォント【レビュー】

                                  GitHubが制作した次世代開発体験のためのコーディングフォント「monaspace」/トレンドを抑えつつ、独自技術「Texture healing」を盛り込んだ最先端のフォント【レビュー】
                                • コードより先にコミットメッセージを書く

                                  これは、フィヨルドブートキャンプ Advent Calendar 2021(Part 1) 13日目の記事です。 未経験からフィヨルドブートキャンプでプログラミングを勉強し、2021年3月から Tebiki 社でエンジニアとして働いている masuyama13 です。 入社当初、PR(プルリクエスト)を作成する際にコミットの整理に毎回かなり時間がかかるのが悩みでした。試行錯誤の結果、この悩みを解消することができたので紹介します。 それが、コードより先にコミットメッセージを書くという方法です。 コミットメッセージを先に書くやり方まず、タスクを分解して TODO リストを作ります。これから作業する内容がイメージできたら、コミットメッセージを一つ考えます。エディタなどにコミットメッセージを入力します。コミットメッセージが書けたら、それを常に意識しながらコーディングを進めます。作業中にコミットメッ

                                    コードより先にコミットメッセージを書く
                                  • 俺たちはもう GitHub のために ssh-keygen しなくていい

                                    ラブグラフ 開発インターンの arawi です。 今日は僕の大好きな GitHub CLI から認証の話をしていきます。 GitHub CLI は超便利です!今すぐ入れよう! TL;DR gh auth login で GitHub CLI を認証できる その過程で SSH key が必要なら GitHub CLI が作ってアップロードしてくれる GitHub CLI とは GitHub CLI は GitHub 謹製のコマンドラインツールです。 CLI 上で Repository, Issue, Pull Request への操作など、様々なことを行なうことができます。 超便利なので今すぐ入れるべきです。HomeBrew なら以下のコマンドで入ります。 詳しくはこちら:https://docs.github.com/ja/github-cli/github-cli/about-githu

                                      俺たちはもう GitHub のために ssh-keygen しなくていい
                                    • Latest topics > GitHubに多数ある自分のリポジトリのデフォルトブランチをmasterからtrunkに切り替えた - outsider reflex

                                      Latest topics > GitHubに多数ある自分のリポジトリのデフォルトブランチをmasterからtrunkに切り替えた 宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! « ポジショントークに騙されないようにしたいし、狭い視野でポジショントークじみた極論を言うよりも、メリットとデメリット両方を把握した上でソフトランディングを図っていきたい Main Chromiumのコミットメッセージの「よりinclusiveにする」とはどういう意味か、GitHubがしている事の何がキナ臭いのか » GitHubに多数ある自分のリポジトリのデフォルトブランチをmasterからtrunkに切り替えた - Jun 12, 2020 Gitのデフォルトブランチ名

                                      • エンジニアが開発しやすい環境作りをする

                                        はじめに 自分は渋谷のWeb系開発会社にて執行役員兼エンジニアをやっています。(新卒入社3年目) 直近では6~8名程のエンジニアがいるプロジェクトで、ディレクトリ設計やissue作成、コードレビュー、スケジュール管理、PMへのUI/UX及び機能提案などを行なっています。 その中で自分が「エンジニアチームにとって開発しやすい環境整備」を色々試し、実践してきたので整理していきます。 この記事の主な対象者 エンジニアチームの開発モチベーションを上げたい人 エンジニアにとって開発しやすい環境の作り方 おことわり 今回紹介するのは自分が実践してきた一例であり、必ずしも正解というわけではありません 「こうしなさい」ではなく「こうするとより良くなるかも」といったモチベで書いています 具体的な開発の設計を紹介するものではありません エンジニアが開発しやすい環境作り 5つのセクションに分けて紹介していきます

                                          エンジニアが開発しやすい環境作りをする
                                        • GitHub - banga/git-split-diffs: Syntax highlighted side-by-side diffs in your terminal

                                          You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                            GitHub - banga/git-split-diffs: Syntax highlighted side-by-side diffs in your terminal
                                          • GitHubの運用を「会社」にしていく話

                                            Ubie DiscoveryでSREなどをしている@itkqです。 UbieではGitホスティングにgithub.comを使っています。プロダクト開発に必要なprivateなコードベースはもちろん、OSSや就業規則といったドキュメントをpublicにホストしたりもしています。また、この記事を書いている時点で、メインのOrganizationのメンバーは121名です。 自分が入社したのは一年前(2021年1月)で、まだ情報システム専任の人がいませんでした。それから今に至るまで、GitHubの運用を「会社」にしていく話を書きます。 一年前のGitHubの運用 当時、UbieのOrganizationに所属していた人数は、業務委託含め80〜90名ぐらいで、Businessプランを利用していました。私はSREとして入社しましたが、情報システム専任の人がおらず、SREをはじめとする何名かのメンバーが

                                              GitHubの運用を「会社」にしていく話
                                            • すべてのウェブ開発者へ。人気GitHubリポジトリ9選 - Qiita

                                              本記事は、Simon Holdorf氏による「9 Popular GitHub Repos For Every Web Developer」(2021年4月4日公開)の和訳を、著者の許可を得て掲載しているものです。 こちらもどうぞ すべてのウェブ開発者へ。人気GitHubリポジトリ10選 便利なツール、参考になる例など はじめに GitHubは、最近の(ウェブ)開発に関連するすべてのワンストップショップです。フレームワーク、デモ、あらゆる種類のコレクションなど、GitHubで見つけられないものはないでしょう。しかし、この膨大な量が問題です。あまりにも多くのレポジトリがあるので、おそらく聞いたことのないクールなものがあります。 そこで今回も、知っておくべき最も人気のGitHubリポジトリを紹介することにします。各リポジトリには少なくとも30,000個の星が付いています。 1. Realwor

                                                すべてのウェブ開発者へ。人気GitHubリポジトリ9選 - Qiita
                                              • フロントエンドのデベロッパーが2021年に向けてチェックしておきたいこと

                                                フロントエンドのデベロッパーが2021年に向けて何に注目すべきかを紹介します。 特に上級職や転職など、ステップアップを目指す人は要チェックです! 10 Things Front-End Developers Should Learn in 2021 by Simon Holdorf 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに 1. フレームワーク 2. 静的サイトジェネレーター(SSG) 3. JAMstack 4. プログレッシブウェブアプリ(PWA) 5. GraphQL 6. コードエディタ/IDE 7. テスト環境 8. クリーンなコード 9. Git 10. ソフトスキル 終わりに はじめに 2021年は、フロントエンドの開発がテクノロジー業界で最もホットなトレンドの1つになることは間違いないでしょう。フ

                                                  フロントエンドのデベロッパーが2021年に向けてチェックしておきたいこと
                                                • GitHub、コードの脆弱性を発見してくれる「GitHub Code Scanning」発表、修正方法のアドバイスも。GitHub Satellite 2020

                                                  GitHub、コードの脆弱性を発見してくれる「GitHub Code Scanning」発表、修正方法のアドバイスも。GitHub Satellite 2020 GitHubは、オンラインイベント「GitHub Satellite 2020」において、コードの脆弱性を発見してくれる新機能「GitHub Code Scanning」を発表しました。 Code scanning, powered by CodeQL, helps protect your code from vulnerabilities you might otherwise miss. #GitHubSatellite pic.twitter.com/8vGq3eFWPE — GitHub (@github) May 6, 2020 GitHub Code Scanningは、昨年買収したSemmleのソフトウェアを基にし

                                                    GitHub、コードの脆弱性を発見してくれる「GitHub Code Scanning」発表、修正方法のアドバイスも。GitHub Satellite 2020
                                                  • ヘルプデスク業務を楽にするためにSlackとGitHub Projectを同期するヘルプデスクツールを自作した - MNTSQ Techブログ

                                                    こんにちは。MNTSQの下村です。 コーポレートエンジニアとして、MNTSQ従業員の生産系向上施策等を実施していたりします。 ( Twitterもやっている のでフォローしてもらえると嬉しいです! ) 本日は社員からの問い合わせ業務 いわゆる ヘルプデスク業務について効率化するためのツールを自作した 話を書いてみます。 この記事の要約 一人目コーポレートエンジニアとして参画したがヘルプデスク業務が非効率だったので効率化した。 質問に対して特定のemojiを押すとGitHub ProjectsのItemを作成するようにした。 SlackスレッドのコメントとGitHub ProjectsのItemを双方向同期するようにした。 Azure OpenAIも利用して効率化した。 きっかけ 2023年5月からMNTSQの一人目コーポレートエンジニアとして参画しています。 情報システムを色々と整備してい

                                                      ヘルプデスク業務を楽にするためにSlackとGitHub Projectを同期するヘルプデスクツールを自作した - MNTSQ Techブログ
                                                    • GitHub Discussionsでチームの暗黙知を共有する

                                                      Tebiki社のWebアプリケーションエンジニアの中山と申します。前職では、SIerでAIアプリの開発を3年弱経験し、現職のTebiki社では、to B向けSaaSの機能開発を行なっています。好きな言語は、C++, Python, Ruby です! この記事では、GitHub Discussionsの運用による知識のストック化と、新人オンボーディング時の負担軽減についてご紹介します! Tebiki社のDiscussionsとは?Tebiki社では、エンジニアチーム内の知識を共有するツールとして、GitHubのDiscussions機能を活用しており、これまでチーム内で議論した内容や暗黙知であった内容をQ&A形式で記録しています。 TebikiのDiscussionsDiscussionsの運用ルールDiscussionsを運用するにあたって、以下のようなルールを作っています。 Discus

                                                        GitHub Discussionsでチームの暗黙知を共有する
                                                      • GitHubのデータセンターでは、Mac miniを分解して取り出したメイン基板をラックマウントに使っている

                                                        GitHubのデータセンターでは、Mac miniを分解して取り出したメイン基板をラックマウントに使っている GitHubは、コードのビルドやテスト環境などで使えるGitHub-hosted runnerとして、Apple M1チップによる「M1 macOSランナー」を提供しています。 このM1 macOSランナーの実行環境として同社のデータセンターには大量のMac miniが稼働していますが、同社が先月(2023年12月)に公開した動画によると、この大量のMac miniはラックマウントのために分解されてメイン基板が取り出され、専用のシャーシに納められていると説明されています。 GitHubはどのようにしてMac miniをデータセンター内でラックマウントしているのか、動画の内容を紹介しましょう。 Mac miniを分解、メイン基板を専用シャーシに組み込む あるGitHubのオフィス。こ

                                                          GitHubのデータセンターでは、Mac miniを分解して取り出したメイン基板をラックマウントに使っている
                                                        • GitHub上に構築した小説執筆環境について

                                                          要点 小説執筆環境を GitHub 上に整備した 校正作業を自動化できた 執筆と情報管理を GitHub 上にまとめられた 小説執筆環境を GitHub 上に整備した 経緯 大学在学中や社会人 1 年目くらいまで、下記のような手法でバージョンを管理していた。 【確定版】2019 年 8 月版(2020 年 1 月 22 日改訂).docx まったく虫酸が走る。 不快極まりない。 ただちに一掃しなければならない。 趣味で不快になっていちゃ世話はない。 せめて不快さを感じない程度の環境を整備する必要があった。 執筆環境への要求事項は次のとおり。 自分でサーバ構築をせずとも使用できること バージョン管理機能が実装されていること クロスプラットフォーム対応であること 以上を満たし、かつ貧弱な端末やネットワークでも使用に堪える環境として、GitHub を選択した。 環境 前提条件 Windows10

                                                            GitHub上に構築した小説執筆環境について
                                                          • 業務で使えるかもしれない…!?GitHub Actions の Tips 集 / CI/CD Test Night #7

                                                            https://testnight.connpass.com/event/311263/

                                                              業務で使えるかもしれない…!?GitHub Actions の Tips 集 / CI/CD Test Night #7
                                                            • 業務端末としてLinuxデスクトップを使うために設定したこと - Plan 9とGo言語のブログ

                                                              2021年の11月に、業務端末としてDELL XPS 13を購入して、Linuxデスクトップに移行しました。いまでは快適に使えるようになりましたが、Linuxデスクトップに慣れていないこともあって思ったように動かず困ったところがあったので、導入にあたって悩んだところをまとめました。 ディスクの暗号化 業務利用の要件にディスクの暗号化があるので、bootパーティションを除いて暗号化しました。手順は過去記事に追記しました。 blog.lufia.org GNOME KDE Plasmaの方がスタイルは好みですし、実際に業務端末でも2ヶ月ほど使っていましたが、Wayland環境ではタッチパッドの左右スワイプが動かないとか、XWaylandで動作するアプリケーションを4Kディスプレイで表示するとぼやけた表示になるなど厳しいなと思いました*1。個人で使うものなら、少し効率が悪い程度なら問題にしません

                                                                業務端末としてLinuxデスクトップを使うために設定したこと - Plan 9とGo言語のブログ
                                                              • GitHub、ソフトウェア部品表の作成機能を無償公開--脆弱性管理を容易に

                                                                印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます ギットハブ・ジャパン(GitHub)は4月7日、クラウド上のリポジトリーからソフトウェアを構成するコンポーネントやライブラリーなどの状況を開発者が容易に把握、管理できる「ソフトウェア部品表」(SBOM)の作成機能「Export SBOM」を発表した。GitHubの全てのクラウドリポジトリーで無償利用できる。 SBOMは、企業や組織などで使われるソフトウェアの脆弱(ぜいじゃく)性を悪用したサイバー攻撃が深刻な被害をもたらしていることを踏まえて、2021年5月にJoe Biden米大統領が署名したサイバーセキュリティ対策の強化を目指す大統領令に盛り込まれた。同令では、ソフトウェア開発組織に対し、ソフトウェア製品を構成するコンポーネントやライ

                                                                  GitHub、ソフトウェア部品表の作成機能を無償公開--脆弱性管理を容易に
                                                                • GitLab、セキュリティ演習で社員にフィッシングメールを送信。その内容と、20%が引っ掛かったことを公開

                                                                  ソースコード管理ツールのGitLabを提供するGitLab,Incは、1200人以上いる社員全員がリモートで働いていることでも知られています。 そのGitLabが社内のセキュリティ対策演習として社員にフィッシングメールを送信。実際に引っ掛かった社員がいたことなどを明らかにしました。 具体的には「レッドチーム」と呼ばれる社内の専門チームが、ランダムに選んだ社員50人に対して、情報部門からの連絡を装った「あなたのノートPCがMacBook Proにアップグレードすることになりました」という内容のメールを送信。 メールの末尾に、手続きのためのリンクが張られており、このリンク先のフィッシングサイトでGitLab社員がIDとパスワードを入力すると、これらの情報が盗まれる、というものです。 フィッシングメールには怪しい点がいくつも込められていた ただしこのメールには、あらかじめフィッシングメールらしい

                                                                    GitLab、セキュリティ演習で社員にフィッシングメールを送信。その内容と、20%が引っ掛かったことを公開
                                                                  • コード変更で抜け漏れやミスを少なくするための習慣 - $shibayu36->blog;

                                                                    自分はこれまでの仕事で、バグ修正や機能追加でPullRequestを送るときに、考慮の抜けもれやケアレスミスが非常に少ない方であると思っている。振り返ってみて、これは自分に課している習慣が大いに効いていると思っているので、メモしておく。 毎回のcommit時 必要な部分だけをgit addし、git diff --cachedによって差分をセルフコードレビューした上でcommitする PullRequest作成時 filesの内容をセルフコードレビューし、直した方が良い部分は直す + わかりにくい部分にGitHub上でラインコメントを行う + コード上にコメントを残した方がいいならコメントする ユーザーの導線に影響するコードなら、必ず自動テストだけでなく、自分自身でユーザーの行動をトレースし、違和感がある部分が存在しないかチェックする。チェックした流れについては、PullRequest上に

                                                                      コード変更で抜け漏れやミスを少なくするための習慣 - $shibayu36->blog;
                                                                    • GitHub、YouTube動画をダウンロードする「youtube-dl」プロジェクトを削除

                                                                      GitHubは米国時間10月23日、米レコード協会(RIAA)から法律に基づく要請を受け、18件のプロジェクトを削除した。 この日に削除されたコードリポジトリはすべて、「youtube-dl」プロジェクトに関連するものだ。 youtube-dlはPythonで書かれたライブラリーで、開発者はこれを利用して、YouTube動画で使われているソースの音声ファイルや映像ファイルをダウンロードできる。 RIAAは、GitHubに送付した書簡の中で、「このソースコード(youtube-dlライブラリー)の明確な目的は、(i)YouTubeなどの許可されたストリーミングサービスで用いられている技術的保護措置を回避し、(ii)許可なく(中略)ミュージックビデオや録音された音声を複製して配布」することだと主張している。 RIAAは同プロジェクトのソースコードについて、「著作権で保護された以下の作品の複製や

                                                                        GitHub、YouTube動画をダウンロードする「youtube-dl」プロジェクトを削除
                                                                      • 共同開発を始めるときに便利な 5 つの GitHub Actions

                                                                        はじめに スタートアップ等において新しいプロダクトを始める時は、負債が無い代わりに何もありません。 そういった時に、ソフトウェアの品質を担保するための CI のセットアップが、初期から重要になってきます。 GitHub を使用している場合は、GitHub Actions を使用されることが殆どだと思うので、そちらを前提に進めていきたいと思います。 1. rhysd/actionlint 様々なエンジニアが action を追加したり、編集したりするようになった時、全員が正しい書き方で書いていくことは難しいです。 また、それを 1 人の GitHub Actions Expert がレビューしていくのは大変で、属人化してしまっているので、避ける方が望ましいです。 以下をコピペすれば、使用できます。 name: Actionlint on: push: branches: [ main ] p

                                                                          共同開発を始めるときに便利な 5 つの GitHub Actions
                                                                        • Gitを使ってやらかした時、git reflogさえ使えればわりかしなんとかなる - Qiita

                                                                          これは何 新人プログラマ応援イベントの参加記事です。 gitにはreflogというコマンドがあります。このコマンドを学んでおくとやらかしちゃった時も大体なんとかなるので記事にします。 git reflogってなに? git reflogとは、Gitで操作履歴を見ることができるコマンドです。 例えば branch1にチェックアウト branch1でbranch1.txtを作成し、コミットを作る masterにチェックアウト をすると、以下のようなreflogになります。 $ git reflog 4a4125a (HEAD -> master) HEAD@{0}: checkout: moving from branch1 to master 826a9dc (branch1) HEAD@{1}: commit: Create branch1.txt 4a4125a (HEAD -> mas

                                                                            Gitを使ってやらかした時、git reflogさえ使えればわりかしなんとかなる - Qiita
                                                                          • AutoGPTを徹底解剖!使い方をご紹介!【2023年4月25日最新版】

                                                                            一般的にChatGPTを使用する際には、プロンプトを入力して進めていく必要がありますが、プロンプトの作成は意外に難しいと感じる方も多いかもしれません。 AutoGPTは、プロンプトを作成せずとも自動的に行うべきことを提案してくれる、という驚くべき機能を持っています。AutoGPTは誰でも利用可能です。 今回PROMPTYでは、そんな話題のAutoGPTの特徴や始め方、使い方を解説していきます。 エンジニアではない方でも導入できるよう、できるだけわかりやすく説明しますので、1つずつ手順を踏みながら試してみてください。 ブックマーク必須!PROMPTYとは 国内最大級のChatGPTなどの生成AIのプロンプトエンジニア専門メディアです。 「プロンプトのテンプレ集」「生成AIの開発・活用ノウハウ」「海外の時事ニュース」など幅広い内容を取り揃えています。 一般的なニュースなどでは取り扱っていない最

                                                                              AutoGPTを徹底解剖!使い方をご紹介!【2023年4月25日最新版】
                                                                            • 10分で自分のGitHubプロフィールをカッコ良くする - Qiita

                                                                              自分の username/README.md を作る 何はともあれ、自分の README.md を作りましょう。 自分と同じ名前のリポジトリを作成しようとすると、かわいい注意書きが出ます。 「Public にして README を作成すると、 GitHub プロフィールを作れるよ〜」と書いてあります。 画像のように Public と Add a README file にチェックを入れて作成します。 GitHub Profile Summary Cards を使う 続きはこちらに移動しました。

                                                                                10分で自分のGitHubプロフィールをカッコ良くする - Qiita
                                                                              • 結局Githubに学習履歴を統一した方が諸々良かった

                                                                                改めて説明する必要もないのですが、本や動画サービスによるインプットに関してはマークダウン形式でまとながら行うため、そこまでアウトプットが苦ではありません。 逆に外部サービスを使った資格学習のための問題演習などは少し手間です。 読書や動画サービスのようにマークダウンにまとめながらアウトプットしてもよいのですが、資格系の問題演習は移動時間や隙間時間に利用することも多いので、都度Githubにコミットするのは難しいです。 なんとか作業を自動化したいので以下のような方法を利用するようにしてみました。 学習履歴のデータを取得する 例えばStudyplusではAPIが提供されています。 利用しているサービスによっては、このようにAPIを提供してくれていたりするので、これを利用してデータを取得します。 またサービスの利用規約を確認して、常識的な範囲で自身の学習履歴のデータをスクリプトを組んで取得するのも

                                                                                  結局Githubに学習履歴を統一した方が諸々良かった
                                                                                • GitHub CLI 1.0 is now available

                                                                                  ProductGitHub CLI 1.0 is now availableGitHub CLI brings GitHub to your terminal. It reduces context switching, helps you focus, and enables you to more easily script and create your own workflows. Earlier this year, we… GitHub CLI brings GitHub to your terminal. It reduces context switching, helps you focus, and enables you to more easily script and create your own workflows. Earlier this year, we

                                                                                    GitHub CLI 1.0 is now available

                                                                                  新着記事