並び順

ブックマーク数

期間指定

  • から
  • まで

81 - 120 件 / 12766件

新着順 人気順

ciの検索結果81 - 120 件 / 12766件

  • Command Line Interface Guidelines

    Contents Command Line Interface Guidelines An open-source guide to help you write better command-line programs, taking traditional UNIX principles and updating them for the modern day. Authors Aanand Prasad Engineer at Squarespace, co-creator of Docker Compose. @aanandprasad Ben Firshman Co-creator Replicate, co-creator of Docker Compose. @bfirsh Carl Tashian Offroad Engineer at Smallstep, first e

      Command Line Interface Guidelines
    • もう初回コードレビューはAIに任せる時代になった - CodeRabbit -

      どんな人向けの記事? レビューによって心理的なダメージを受けやすい方 非エンジニアだが、エンジニアチームがどんな機能を作っているか知りたい方 業務が溜まっていて、レビューに割く時間を捻出するのに苦労している方 コピペできるコードも公開します 初回レビューをAIに任せると、いろんなロールの人の役に立つ レビューは得意ですか? 優秀なエンジニアしかいないチームであれば、PRは1トピックに絞って小さく明確なコミットによって作成され、適切な要約とともに提供されることでしょう。 しかし、実際にはいろいろな制約から、PRが想定よりずっと大きくなってしまったり、関連トピックと異なるコードが混じってしまうこともあります。 実際のところ、大きなPRを適切にレビューするのは難しいことです。また、自分が詳しくない領域のレビューを行わなければいけない機会もあります。 今回の記事は、レビューを作成してくれるAI C

        もう初回コードレビューはAIに任せる時代になった - CodeRabbit -
      • 見ているサイト上に露出している機密情報(APIトークン、IPアドレスなど)を見つけるブラウザ拡張を作りました

        見ているサイト上に露出している機密情報(APIトークン、IPアドレスなど)を見つけるブラウザ拡張を作りました SecretlintというAPIトークンなどの機密情報がファイル内に含まれているかをチェックできるツールを書いています。 Secretlintはコマンドラインツールとして動くので、主にCIやGitのpre-commit hookを利用して、リポジトリに機密情報が入るのを防止できます。 SecretlintでAPIトークンや秘密鍵などのコミットを防止する | Web Scratch 一方で、実際のウェブサービスなどは機密情報がファイルにハードコードされているわけではなく(Secrelint自体がこういうハードコードを防ぐツールです)、環境変数やDatabaseに保存していると思います。 このような場合にも、コードのミスなどによって公開するべきではない情報(秘密鍵、APIトークン、Sl

          見ているサイト上に露出している機密情報(APIトークン、IPアドレスなど)を見つけるブラウザ拡張を作りました
        • ブロガー界隈の有名フリーランスエンジニアを見てプログラミングを始めないでくれ - 渡るネットは嘘ばかり

          なんかマナブやばいな、ついでに色々見てたんですが、最近技術ではない方向で前に出てきてるエンジニアが増えてるようですね。 技術ブログは一般の人は見ないからわからないかもですが、技術ブログ系はエンジニアが見るだけで、基本的にそこで収益を得てるものも少ない印象があります。技術者の業界というのは業界の発展のために、無償で貢献(楽しみとしての人が多い)する人がすごく多く、それによってライブラリの充実の恩恵として再利用性や車輪の再発明を避けたりできてたりします。なので、この人達は金儲け系のブロガー界隈では話題にならないですね。 一般向けに言葉を発信する人が少なめだったというのもあるのかも知れませんが。というか、よく見たら取り上げようと思った人全員文系エンジニアですか…。文系エンジニアは技術よりお金に向かい、理系はお金より技術に向かう傾向でもあるんですかね。 今回はやまもとりゅうけん、マナブ、勝又健太さ

            ブロガー界隈の有名フリーランスエンジニアを見てプログラミングを始めないでくれ - 渡るネットは嘘ばかり
          • ソフトウェア設計についての原則や法則についてまとめてみた

            ソフトウェア設計について、YAGNIやSOLIDなど多くの原則・法則があることが知られていますが、その解釈にはぶれが存在することが多いです。そこで、特に有名なものあるいは有用と感じることが多いものをいくつかピックアップして、その解釈やトレードオフについてまとめてみました。 注意としては、SOLIDが入ってることからわかる通り、主にOOPに関する文脈になります。また、各原則の定義については概ね知っている前提で書いているのであまり初学者向けの記事ではないかもしれませんのでご承知おきください。 YAGNI(You ain't gonna need it.) YAGNIは、予測による実装が実際に役立つことは少ないという経験則から生まれた原則です。 一般にオーバーエンジニアリングが利益をもたらすケースは限定的で、どちらかというとプロジェクトに害を与えることが多いとされています。YAGNIは日々状況の

              ソフトウェア設計についての原則や法則についてまとめてみた
            • スタートアップはいかにしてその活力を失うのか | Yakst

              急成長するスタートアップがどうしてそのスピード感や勢いを失ってしまうことがあるのか、その背景にある構造とパターンを筆者の目から解き明かし、それを回避する方法を提案する。John Qian氏のブログ記事の翻訳。 [スタートアップ]原文 How a startup loses its spark (English) 原文著者 John Qian 原文公開日 2023-08-12 翻訳依頼者 翻訳者 doublemarket 原著者への翻訳報告 238日前 メールで報告済み 238日前 原著者承諾済み 編集 ちゃんとしたシードステージのスタートアップでは、エンジニアは業務経験を「夢中だ」と表現する。大きな会社では、得られるのは最良のケースでも「楽しい」程度だ。どうしてこうなってしまうのだろう。これは避けられないのだろうか。 スタートアップを夢中になれるものにするのは何なのかを調べてみよう。エンジ

              • Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々

                Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな

                  Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
                • 【永久保存版】0からAWSを勉強するならこのロードマップに従え! - Qiita

                  はじめに こんにちは!!@Sicut_studyです! 先日出しました記事が多くの方に見ていだきました! 今回はAWSのロードマップの紹介です。 AWSを勉強しようとしている人からよく聞くのが AWS勉強したいけど何からしたらよいかわからないから資格の勉強しています 資格を勉強するのもいいですが最速でAWSを実践的に使えるということを目的にするなら、その方法は個人的には微妙かなと思います。 私もこのロードマップを行ったあとに試しに資格をとってみましたが、あまり実務に速攻的に役立つという感じではありませんでした (高度なものなら違うかもしれません) 私も2年前はAWSについてまったく知りませんでした しかし、とあるタイミングで 先輩がやっているようなAWSの環境を作って管理するのを私もできるようにならないと高みにいくことはできない このように思うようになり、ロードマップに沿ってに1から学習を

                    【永久保存版】0からAWSを勉強するならこのロードマップに従え! - Qiita
                  • エンジニアの技術土台となる知識を得るための本の紹介 - Qiita

                    はじめに の参加記事になります。 個別の技術ではなく、エンジニアの成長のステップで読むと良い本の紹介 エンジニアとして成長していくときに、個々の技術を深く理解し使いこなしていくことは必要ですが、個々の技術を選ぶときにもどんな成長ステップがあるかを理解することも重要です。 実装をするという範囲をエンジニアの中心なのはありますが、実装以外の部分を理解するとその技術が最大限に活きるのかを理解するには周辺についても理解していく必要があります。そこで、実装を始める前の構造のパターン、実装を進めるエンジニアの環境などを知ることで、もっと効率的な開発が出来るようになるのかを理解していきたいけると良いと考えています。 この記事では私が経験した中でより良いWebシステムを作るという観点に立ったときに、広く理解しておくと良いと感じた本を紹介します。 これからエンジニアリングでどのような勉強をすればよいかを考え

                      エンジニアの技術土台となる知識を得るための本の紹介 - Qiita
                    • jQueryからTypeScript・Reactまで - Viteで始めるモダンで高速な開発環境構築 - ICS MEDIA

                      Vite(ヴィート=フランス語で「速い」の意味)は2020年に発表された新しいフロントエンドのビルドツールです。 開発者がVue.jsの作者であるEvan You氏であるため、Vue.jsのツールであると誤解されることもありますが、プレーンなJavaScript(バニラJS)からVue.js・React・Svelteといった流行のフレームワークまで、さまざまな環境で利用できる汎用的なツールです。 位置付けとしてはwebpackのようなバンドラーと呼ばれるものに近い存在ですが、それだけではありません。この記事では、Viteを導入してプレーンなJavaScriptから、TypeScript+Vue.js・Reactといったフレームワークまで、快適な開発環境を手に入れる方法を紹介します。 この記事で紹介すること: Viteの特徴と基本の仕組み 基本の使い方 Vite + SCSS Vite +

                        jQueryからTypeScript・Reactまで - Viteで始めるモダンで高速な開発環境構築 - ICS MEDIA
                      • 全国の小中学生に配布する27万8000円のPCが酷すぎると話題に : 痛いニュース(ノ∀`)

                        全国の小中学生に配布する27万8000円のPCが酷すぎると話題に 1 名前:ベンガルヤマネコ(北海道) [AU]:2020/01/30(木) 23:22:04.06 ID:/sDx2yXl0 CPU Intel Celeron N4000 メモリ 4GB ストレージ eMMC 64GB ディスプレイ 1920x1080, 10.1インチ, タッチ対応 OS Windows 10 Pro 64ビット その他 防水・防塵 3年リース価格27万8000円 【動画】小中学校のパソコン1人1台 「1台27万円」のケースも|NEWSポストセブン https://www.news-postseven.com/archives/20200130_1534882.html 関連スレ 小中学生全員にPC1台配置を実現した東京都渋谷区、リースで1台27万8千円 機種は富士通のARROWSタブで希望小売価格は8万

                          全国の小中学生に配布する27万8000円のPCが酷すぎると話題に : 痛いニュース(ノ∀`)
                        • 新 GitHub Actions 入門 - 生産性向上ブログ

                          github.blog GitHub Actions の新バージョンが 8/8 に発表されました。 www.kaizenprogrammer.com 自分は過去にも旧バージョン時に GitHub Actions の入門記事を書いていたのですが、新バージョンがこれまでと大きく変わってしまっているので、この記事ではあらためて GitHub Actions についていろいろ調べたり動かしてみたりした内容をまとめます。 目次 注意事項 GitHub Actions とは これまでの GitHub Actions とどこが変わったか コンセプト マルチプラットフォーム対応 HCL から YAML へ 料金 その他 GitHub Actions と Azure Pipelines 簡単な例 (Hello, World) ワークフローの設定 ワークフローとは ワークフローを実行するイベント ワークフロー

                            新 GitHub Actions 入門 - 生産性向上ブログ
                          • しずかなインターネットの技術構成

                            こんなWebサービスをリリースしたので、技術的な話をまとめておこうと思います。 元々このサービスは、趣味の延長線のような感じで開発を始めました。競合にあたるnoteやはてなブログなどのサービスが確固たる地位を築いているということもあり、「お金にはならないだろうけど、自分の趣味を詰め込んだものにしよう」というゆるい気持ちで開発を続けています(楽しい)。 選定の方針 趣味と言っても文章投稿サービスなので、ユーザーが少数であったとしても長期間運営しなければなりません。そのため、ユーザー数が少なければランニングコストが数千円/月以下、ユーザー数が増えたときは段階的にコストが上がるように選定を行いました。 アプリケーション フルスタックNext.jsアプリケーションをCloud Runにデプロイしています。各APIエンドポイントはNext.jsのAPI Routesで生やしています。 Next.js

                              しずかなインターネットの技術構成
                            • (年収270万で)プログラマーを引退して、医学部にきた俺が真面目に考えて..

                              (年収270万で)プログラマーを引退して、医学部にきた俺が真面目に考えてやろう。 ① 言葉は正しく使おう真面目に読んでいて、ちょっと気になる箇所がある。たとえば PostgreSQL を postgre とか書くヤツは現場では嫌われるぞ。少なくとも postgres と書いてくれ。お里が知れるぞ。 ② プライドが高い消えていくエンジニアの特徴だけど、叱責されたり馬鹿にされるのが嫌で VCS にコミットしないヤツ、または貪欲にコードレビューをされるのが嫌がるやつは、成長しない。 ③ エリート意識この業界は数年前には『デジタル土方』と揶揄される業界でした。ちなみに、アメリカでも「テック系はハードだから避ける」という雰囲気でした。つまり何をいいたいのかというと、ソフトウェアの開発者っていうのは「泥臭い領域」なんだよ。エリートとは程遠い場所にあるというね。 ④ 「某天市場の先輩には,ここ仕事量少な

                                (年収270万で)プログラマーを引退して、医学部にきた俺が真面目に考えて..
                              • UTF-8のテーブル(MySQL5.6)に竈門禰󠄀豆子が格納できない問題を調べてみた - Qiita

                                竈門禰󠄀豆子をMySQL5.6のテーブルにinsertしようとすると正しく格納できず、竈門禰となってしまうケースがあるという話を聞き、調べてみました。 実践 まずは試しにやってみます。 mysql> show create table verification\G *************************** 1. row *************************** Table: verification Create Table: CREATE TABLE `verification` ( `name` varchar(100) COLLATE utf8_bin DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin 1 row in set (0.01 sec) mysql> inse

                                  UTF-8のテーブル(MySQL5.6)に竈門禰󠄀豆子が格納できない問題を調べてみた - Qiita
                                • 「Codecov」への第三者からの不正アクセスによる当社への影響および一部顧客情報等の流出について

                                  (2022年9月26日追記) 本件に関する、セルフチェックページとお問合せ窓口の提供を終了いたしました。 この度は、お客さまをはじめ多くの関係者の皆様に多大なるご迷惑とご心配をおかけしましたことを、深くお詫び申し上げます。 株式会社メルカリは、当社が利用している外部のコードカバレッジツール※「Codecov」に対する第三者からの不正アクセスにより、当社のソースコードの一部および一部顧客情報(フリマアプリ「メルカリ」で2013年8月5日〜2014年1月20日に実行された売上金の顧客口座への振込みに関連した情報17,085件、2015年11月〜2018年1月の間におけるカスタマーサービス対応に関連した情報217件、2013年5月に実施したイベントに関連した情報6件、「メルカリ」および「メルペイ」の一部取引先等に関する情報7,966件、当社子会社を含む一部従業員に関する情報2,615件)が外部流

                                    「Codecov」への第三者からの不正アクセスによる当社への影響および一部顧客情報等の流出について
                                  • ヤマトの「クロネコマーク」、4月にデザイン変更。1957年以来初

                                      ヤマトの「クロネコマーク」、4月にデザイン変更。1957年以来初
                                    • 高校生が作った有料サービスがちょっと儲かったのでいろいろ書く

                                      Discordの有料読み上げBotを運営している高校3年生です。公開2年目で月に12kほど利益が出ています。 最大4つのボイスチャットで読み上げ可能 可用性99% Webダッシュボード などの機能があります。Discordを使っている方がいれば、ぜひ導入していただけるとうれしいです。 コミュニティの宣伝 未踏ジュニアに採択された採択者で、未踏ジュニアに挑戦したい方向けのコミュニティを始めました!約12人の採択者と話をしたり、質問できます!ぜひ共有していただけると幸いです🙏 なぜ作ることにしたのか? 昔(4年前)頃から無料のDiscordの読み上げBotは存在していましたが、どれも使う人数が多すぎて制限があったり、読み上げが遅くなったりするという問題がありました。そこで、有料の読み上げBotを運営することにしました。 料金体系 一律で月500円/20万文字のサブスクリプションにしました。g

                                        高校生が作った有料サービスがちょっと儲かったのでいろいろ書く
                                      • メルカリShops の技術スタックと、その選定理由 | メルカリエンジニアリング

                                        こんにちは。ソウゾウの Software Engineer (CTO) の @suguru です。連載:「メルカリShops」プレオープンまでの開発の裏側の1日目を担当させていただきます。 7月末にメルカリShopsという新しいサービスが公開されました。メルカリShops は、2021年1月にメルカリのグループ会社として設立したソウゾウが新たに立ち上げたサービスです。 この記事では、メルカリShops を作るにあたり、どういった技術、アーキテクチャを選定したのか、その背景と意思決定をまとめて共有したいと思います。 monorepo まず最初にプロジェクトをスタートしたときに、サービスのリポジトリを作るのですが、迷わず monorepo による構成を選択しました。monorepo は、システムを構成する複数のコンポーネントの独立性を保ちつつ、全ての構成を1つのリポジトリで管理する手法です。今

                                          メルカリShops の技術スタックと、その選定理由 | メルカリエンジニアリング
                                        • 「仕事のコード」を残す際のチェックリスト|Uchio Kondo

                                          最初に注意: この文章は「はじめに」「総論」が長いです🙃 追記@2021/08/11 17:46想像よりはるかに反響をいただいたので、せっかくだからと要点をMarkdownにしてGitHubに置いてみました。何かにご利用ください。 はじめに・「仕事のコード」、つまり、業務などで作ったコードが、なるべく負債にならず、なるべく俗人化しないようにするために留意すると良さそうなことを自分の経験などから列挙したものです。 ・ちなみに、「対象読者」に書いてありますが、そもそものモチベーションが「非エンジニアがノーコード系のサービスで作ったシステムが最近増えつつあるような...」というところでした。こういうのどう取り扱うといいんですかねとなった時、まずは運用できる形にしてもらいたい、という狙いがあります。結果的に、ジュニアなエンジニアが良いシステムを残す上でも使える知識かなと思います。 ・個別の項目に

                                            「仕事のコード」を残す際のチェックリスト|Uchio Kondo
                                          • 技術的負債とステークホルダと説明責任と / The Debt

                                            Talked at CloudNative Days Spring 2021 Online #CNDO2021. https://event.cloudnativedays.jp/cndo2021/talks/801

                                              技術的負債とステークホルダと説明責任と / The Debt
                                            • ヤマト運輸株式会社 | GitHub

                                              1919年の創業以来、日本初となる路線事業を開始し、1976年には個人間で簡単に荷物を送ることができる「宅急便」を発売するなど、日本全国を網羅する物流ネットワークを構築し、社会的インフラとして社会課題の解決に取り組んできた。現在は、宅配便サービス国内シェア第1位(シェア:46.6%、2021年度、国土交通省調べ※)、国内宅急便ネットワークカバー率100%を誇り、宅配便の年間取扱個数は約22.5億個(2021年3月期)に達した。2020年1月に経営構造改革プラン「YAMATO NEXT100」を策定し、データ・ドリブン経営を推進している。 ※令和3年度 宅配便等取扱個数の調査及び集計方法(国土交通省) 開発環境の内製化の実現に向けAzureとGitHubを採用 開発基盤を統一し、アジャイル開発とDevOpsを促進 ・AzureとGitHubを採用し開発基盤の内製化へシフト、DevOps導入を

                                              • エンジニアの目標設定って難しいよね、という話とOKRでなんとかできるのではという話|dora_e_m

                                                「目標設定、ニガテなんですよね」組織に属するメンバーを育成し、評価する。そのための材料として「目標設定」を活用している組織は多い。MBOか、それに類する形を採用しているところが多いのではないか。(観測範囲での判断なので今は違うかもしれない) そして、「目標設定」を行う組織は多いというのに、「私、目標設定得意なんですよ」というエンジニアの存在は寡聞にして存じ上げない。なぜなのだろう。 エンジニアの目標設定は難しい?組織のレベルでは、「売上○○円」「ユーザー数○○人」「平均DAU○○」といった目標が設定されることが多い。財務に直結するものだ。翻って、エンジニアたちは組織にどう貢献するのか。エンジニアリングだ。直接売上がどうこうではなく、「どうすればビジネスに貢献するか」から立脚された仮説に基づいて行動をしていくことになる。 こうすれば画面遷移数が減って使いやすくなる、その事により利用率が向上す

                                                  エンジニアの目標設定って難しいよね、という話とOKRでなんとかできるのではという話|dora_e_m
                                                • ヤフー全社横断「Webパフォーマンス改善」の取り組み (Core Web Vitalsスコアの向上)

                                                  ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、第11代黒帯(ヤフー内のスキル任命制度/Webフロントエンド領域)の浜田(@narirow)です。今回はヤフー全社で実施してきた、「Webパフォーマンス改善プロジェクト」についてお話ししたいと思います。 長期に渡る活動の結果、多くのサービスのWebパフォーマンスが徐々に向上しています。この記事では、取り組みの経緯や、多くのサービス分析を通してわかったコスパの良い施策(比較的簡単に実施できてスコアも上がりやすい施策)などをご紹介します。 全社横断でWebパフォーマンス改善を実施する経緯 さかのぼること2021年、Googleから以下のような案内がありました。 「Core Web VitalsがGoogle検索の検索順位に

                                                    ヤフー全社横断「Webパフォーマンス改善」の取り組み (Core Web Vitalsスコアの向上)
                                                  • (翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 - forest book

                                                    本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 blog.pragmaticengineer.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏ではなく、本稿のコメント欄にお願いします。 著者も機械翻訳を下地にしたやり方に関心をもたれたようです。 The article translated to Japanese: https://t.co/4uynyyhm4E The author was transparent and noted that the article is a modification of an ML-translated article. This person managed to transl

                                                      (翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 - forest book
                                                    • 【JTF2020】凡人エンジニアの生存戦略

                                                      【CICD2021】デプロイメントパイプラインの原理原則を再確認する / Confirm Deployment Pipeline Principle

                                                        【JTF2020】凡人エンジニアの生存戦略
                                                      • 【入門】インフラやるなら知っておきたいトピックのリンク集 - Qiita

                                                        インフラをやるうえで知っておきたいトピックを独断と偏見で選んでリンク集をつくりました. HTTP HTTP入門 [BurpSuiteJapan]HTTP基礎入門 RESTful API Web API入門 RESTful API 入門 KVS key-valueストアの基礎知識 KVS 超入門 - footmark NoSQL HBaseの概要とアーキテクチャ | Think IT(シンクイット) Oracle Cloud Hangout Cafe - 明解! NoSQLの勘所 - Speaker Deck データベース 2018-11-データベース / 2018-11 database - Speaker Deck SQLをはじめよう - 初心者でもわかる、構文とデータ取得の基本 - エンジニアHub|若手Webエンジニアのキャリアを考える! RDBとNoSQLにみるDB近現代史 データ

                                                          【入門】インフラやるなら知っておきたいトピックのリンク集 - Qiita
                                                        • 「スタートアップだからテストを書かない」は正しいか - An Epicurean

                                                          スタートアップのCTOクラスの人がたまにそういうことを言っているのを聞くことがあります。もしくは「スピード優先だからテストを書かない」等です。 それは真ではなく、言ってしまえば、未熟だからテストを書「け」ない、のではないでしょうか。ただ、スタートアップという言葉に未熟であるという意味が含まれているのであれば「スタートアップだからテストを書かない」という問は真になるかも知れません。スタートアップは得てして未熟なものだし、それでも良いからです。 テストを書かないというジャッジをするのは構いません。でもそれは、スタートアップだからでもスピード優先だからでもない。自分達が未熟だからで、そこには向き合うべきだと考えます。状況のせいにするのではなく、徹底的に自分ごと化する。それがスタートアップに求められる姿勢です。少なくとも技術のトップが自分たちの技術力に向き合わないのはまずいでしょう。 「スタートア

                                                            「スタートアップだからテストを書かない」は正しいか - An Epicurean
                                                          • とりあえずWebサービス作る時の私の技術選定ポイント@2022/02

                                                            はじめに inspired mogaさんのブラウザで動くサービスを作るときの技術選定が素晴らしい記事だったので、自分も書いてみる事にしました。 幸いにも技術選定からのお仕事をする機会が多くて、自分の中でパターンが大体決まってきているので言語化してみます。前提が同じサービスは無いので絶対的な正解は無いですが、なんかしらの参考になれば幸いです。 ※2022/02時点 私/よくあるお仕事について Web系のサービスなんかいい感じにするマンとして、フリーランスとして働いています。 準委任という形でスタートアップ企業をお手伝いする事が多いです。 MVPを作りたい、もしくはMVPは行けたのでちゃんと作り直したい、という要望があって参画して、まるっと作ってそのまま運用をします。作って終わりではなくて、運用や拡張性を考えてやってます(サービスに必要なのはもちろん、運用する自分が楽だから)。 前提 エンジニ

                                                              とりあえずWebサービス作る時の私の技術選定ポイント@2022/02
                                                            • Webエンジニア1年目の自分に捧げたい本・記事を超まとめ - Qiita

                                                              そろそろWebエンジニア3年目の折り返しになるので、Webエンジニアとして働く中でこれまで読んできた情報たちをまとめようと思い立ちました。 エンジニア3年目の今だからこそまとめられる情報として、「エンジニア1年目の1年間で読んでおきたかったな〜。」という本と記事をまとめておきます。 まとめ始めたら楽しくなってしまい、情報量が多くなってしまった...。全部手に取るのは不可能だと思うので、サーっと目を通して見て興味が湧いた本や情報を手にとっていただけると良いかと。 これからWebエンジニアになる人、Webエンジニア1年目の人の参考になれば幸いです。 これは何? Webエンジニア1年目が仕事を進める上で絶対に求められるであろう知識を、技術力・Web知識・仕事の進め方・キャリアの観点からまとめました。 「これだけ読んでおけば絶対大丈夫!!」という安易なものではありませんが、「どんな知識を学べばいい

                                                                Webエンジニア1年目の自分に捧げたい本・記事を超まとめ - Qiita
                                                              • Masanori Kusunoki / 楠 正憲 on Twitter: "COCOAは途中まで私たち補佐官も入っていたので、決して運用保守を軽視したつもりはなかったのですが、EN API自体のプライバシー哲学に沿おうとすると既存のデバッグ用ツールがほぼ使えなくなってしまったのと、EN APIの更新がスマ… https://t.co/iQ5kltAo9k"

                                                                COCOAは途中まで私たち補佐官も入っていたので、決して運用保守を軽視したつもりはなかったのですが、EN API自体のプライバシー哲学に沿おうとすると既存のデバッグ用ツールがほぼ使えなくなってしまったのと、EN APIの更新がスマ… https://t.co/iQ5kltAo9k

                                                                  Masanori Kusunoki / 楠 正憲 on Twitter: "COCOAは途中まで私たち補佐官も入っていたので、決して運用保守を軽視したつもりはなかったのですが、EN API自体のプライバシー哲学に沿おうとすると既存のデバッグ用ツールがほぼ使えなくなってしまったのと、EN APIの更新がスマ… https://t.co/iQ5kltAo9k"
                                                                • 【AWS】ぼくのかんがえたさいきょうの運用・監視構成 - Qiita

                                                                  AWSのインフラを運用・監視する上で使いやすいと思ったサービスを組み合わせて構成図を作成しました。それぞれのサービスの簡単な説明と類似サービスの紹介、また構成の詳細について説明していきます。 (開発で使用するようなサービスも紹介しますが、あくまでも運用・監視だけの構成です。) 各個人・企業によって環境は違うと思いますし、使いやすいと思うサービスは人それぞれだと思うので、これが正解という訳ではありませんが、参考にしてただければ幸いです。 参考になった教材を紹介した記事も作成しました。是非読んでみてください! 【AWS】さいきょうの運用・監視構成を作成するのに参考になった書籍 インフラエンジニア1年生がプログラミングを勉強するのに使った教材 全体図 こちらがAWSにおける"ぼくのかんがえたさいきょうの"運用・監視構成です。複雑で分かりづらいかと思うので、詳細に説明していきます。最後まで読めばこ

                                                                    【AWS】ぼくのかんがえたさいきょうの運用・監視構成 - Qiita
                                                                  • マクドナルドで一日分の栄養を取れる組み合わせを計算したら衝撃の結果に - Qiita

                                                                    コレステロールは最低摂取基準量はないので0としています(実はこれが伏線になっている)。 そして目的は、一日必要な栄養素を満たす最もカロリーの低い商品の組み合わせとします。金に糸目はつけません。健康第一! 解く 商品の数が96個、栄養素の数が16個なので、とても人間の手では解けません。そこでコンピューターの力を借ります。幸いPuLPというPythonで無料で利用できるソルバーがあるので、これで計算します。ちなみにExcelにもソルバーが搭載されていますが、この程度の数の決定変数でもエラーになって計算できませんでした。 # Import PuLP modeler functions from pulp import * # A new LP problem prob = LpProblem(name="mac", sense=LpMinimize) # Variables AA = LpVar

                                                                      マクドナルドで一日分の栄養を取れる組み合わせを計算したら衝撃の結果に - Qiita
                                                                    • 数時間かかる週一リリースを毎日何度も爆速でできるようにするまで / CI/CD Conference 2021

                                                                      CI/CD Conference 2021

                                                                        数時間かかる週一リリースを毎日何度も爆速でできるようにするまで / CI/CD Conference 2021
                                                                      • GitHub Actions 逆引きリファレンス

                                                                        1.この記事の立ち位置#自分がいつも調べていること、忘れがちな Tips や小ネタを列挙していく。そのため、網羅性は重視しない。 というのも、なにか調べていていろいろ読み漁った挙げ句、1周回って行き着くところは GitHub Actions の公式ドキュメントであり、たとえば Workflow の書き方は以下のページをよく開いている。 Workflow syntax for GitHub Actions - GitHub Docs それでも、公式ドキュメントで参照したい箇所を引っ張るための用語を知るまでに苦労することが往々にあり、この記事が、公式ドキュメントで参照したい箇所を導くための助けとなればと思い、書いていく。 2.Step と Job と Workflowの違いアレコレ#2-1.Step と Job と Workflow の違いの一行まとめ#Step < Job < Workflo

                                                                        • 20代後半から始める英語習得

                                                                          最近GoogleやMicrosoft、Amazonなどの大手の外資企業以外にも日本でソフトウェアエンジニアの採用することが増えてきた気がします。Twitterのタイムラインを見ても、海外に本社があり、英語を利用して働いている方がをちらほら見かけるようになってきました。年俸的にも外資の企業は魅力だったりしますが、管理職以外でソフトウェアエンジニアとして働き続けることを考えた際に、IC(Individual Contributor)というパスが日本の企業よりも、外資企業の方が明確なキャリアパスとして存在するというもの理由の一つな気がします。 私は現在CircleCIというCI(Continuous Integration:継続的インテグレーション)を支えるためのサービスを提供している企業でインフラストラクチャーエンジニアをしています。最初はサポートエンジニアとして入社し、1年くらい前にインフラ

                                                                            20代後半から始める英語習得
                                                                          • この無駄にゲームして過ごした時間を勉強に充てたら中国語もペラペラになるんじゃね~の!と思ったので1年間やった - どぶろくソロリティ血風録

                                                                            いつも心に谢谢您……(葱抓餅の袋より) なんとなく中国語をやってみるか、と思い立ったのが確か2021冬ぐらいなんだけど、独学で勉強を始めて概ね1年でHSK3級(体感だと中学英語ぐらいのレベル)に合格したのでその話を書きま~す。 最初に書いちゃうと、合格までにメインで使った教材は主にNHK中国語講座「まいにち中国語(2022年の”言いたいことから中国語”)」で基礎の基礎~文法を覚えて、HSK対策にSPRIX社のHSK単語トレーニングアプリで単語を補強した感じです。 NHKのテキスト6か月分 3,180円とアプリの1級~3級あわせた課金 1,610円。合計5,000円ぐらいなのでかなりお得に勉強できたと思う。 ちなみにどんぐらいできるようになったかというと、ワイの残念なお脳では1年ではペラペラにはならなかったものの、台湾旅行で簡単な注文のやりとりをしたり「オデ、コレ、ハンブンダケ、ホシイダケド

                                                                              この無駄にゲームして過ごした時間を勉強に充てたら中国語もペラペラになるんじゃね~の!と思ったので1年間やった - どぶろくソロリティ血風録
                                                                            • 「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由 - Qiita

                                                                              「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由チーム開発プロジェクト管理マネジメント はじめに 前回、なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのかの記事において、プロジェクト型の人員規模を柔軟に変化させる開発スタイルに関して、理論的なスケジュール削減の限界について考察しました。その際に、チーム型開発や組織とソフトウェアの紐付けについても示唆しました。 今回は、チームでソフトウェアを開発することに関して、「フロー効率」と「リソース効率」という観点から考察し、なぜ私たちはチームで開発するのか、あるいはなぜプロジェクト型を採用するのかについての考え方を深めていきたいと思います。 そして、組織における効率性の価値観が異なると、新しい効率性に関して理解をする前に「もったいない」と感じてしまい、新しい文化を取り入れづらくして

                                                                                「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由 - Qiita
                                                                              • 日経新聞が買い物難民を「自宅からスーパーやコンビニまで500m以上あり車の利用が困難な65歳以上の人」としていたがそのくらいは歩けばいいのでは?

                                                                                日本経済新聞 電子版(日経電子版) @nikkei 日経電子版の公式アカウントです。トップページで報じたニュースを中心に注目コンテンツを24時間発信。記事は会員向けを含みます。日経公式アカウント一覧は nikkei.com/edit/sns/?n_ci… nikkei.com リンク 日本経済新聞 「買い物難民」高齢者の4人に1人 農林水産省が支援策 - 日本経済新聞 「買い物難民」が増えている。65歳以上の高齢者のうち、約4人に1人が、住居の近くに商店がなく、食料確保に苦労していることが農林水産省の研究機関の推計でわかった。農村部だけでなく、都市部でも課題で、政府は移動販売や宅配サービスへの補助金を出すなど対策を急ぐ。青森県の南部町では平日5日、日用品や食品を載せた移動販売車が町内全域を回る。高齢化率はおよそ4割と、全国平均より1割高い。高齢者や病気を持つ 3 users 26

                                                                                  日経新聞が買い物難民を「自宅からスーパーやコンビニまで500m以上あり車の利用が困難な65歳以上の人」としていたがそのくらいは歩けばいいのでは?
                                                                                • 今のチームに来てから最も生産性が上がった考え方|牛尾 剛

                                                                                  多分今回のポストは多くの人には参考にならないだろう。相当ニッチなので。でもこれは自分にとってはとても大きなことだったので、忘れないように記録しておきます。 生産性の悩み あまりこの世界では生産性とはあいまいな言葉で、何をもって生産性が高いとは言いにくい。速いのが良いのではない。ただ、自分の実感として自分は生産性が良くないといつも感じていた。だからいろいろ努力したり、考え方をできる人を観察して真似してみたり、直接本人に聞いたりして工夫をしてきた。 実は自分はめっちゃコーディングが早い人になりたいわけではない。そうではなくて、「平均的」になりたいだけだ。それぐらいいければ「Strategy」でカバーできるどころかもっと上に行けると確信があったから。でもそうではなくて明らかに遅いのでそれが自分の足を引っ張っていた 努力の方向性 様々な努力をして、特に有効だったことを自分の本に書いたつもりではある

                                                                                    今のチームに来てから最も生産性が上がった考え方|牛尾 剛