ashitakaeruuのブックマーク (1,076)

  • 今どきの言語ならこの2択、歯ごたえ十分のRustか型を使えるTypeScriptか

    日経クロステックが実施した「プログラミング言語利用実態調査2023」で「今後、スキルアップしたいと思う言語はどれですか」と複数回答可で尋ねたところ、トップ10の言語が分かった。それぞれの言語の特徴を解説する。 4位 Rust 多機能でC/C++並みに高速。ただし、難易度は高め 2015年に最初の安定版である「Rust 1.0」がリリースされたRustは、近年人気が高まっているプログラミング言語です。Rustの魅力は、高速に動くプログラムを、現代的なプログラミングテクニックを使うコードで作成できることです。これはプログラミング言語の歴史から見ても興味深い点です。 近年、プログラミング言語の進化の方向は、PythonRubyのように実行速度を犠牲にする代わりに様々な機能を提供するか、Go言語のように提供する機能を絞って実行速度の向上を追求するかという2つの道に分かれていました。その中で、Ru

    今どきの言語ならこの2択、歯ごたえ十分のRustか型を使えるTypeScriptか
  • Googleのはじめ方

    以下の文章は、Paul Graham による How to Start Google の日語訳である。 翻訳文書については、Shiro Kawai さんに誤訳の訂正を頂きました。ありがとうございました。 (これは、14~15歳の子たちに、いずれスタートアップを始めたいと思ったら何をやるべきかについて私が行った講演である。多くの学校が、スタートアップについて生徒に何か教えるべきだと考えている。これこそが、私が学校が生徒に教えるべきと思っていることだ。) あなた方のほとんどが、いわゆる現実世界に放り出されたら、いずれはある種の職に就かねばならないと考えているでしょう。それは正しくなくて、今日、私はあなた方が職に就かなくて済むために使える技を指南します。 その技は、自分の会社を始めることです。つまり、それは働くのを避ける技ではありません。自分の会社を始めたら、普通の職に就いた場合よりも懸命に

    Googleのはじめ方
  • 【ミノ駆動流】「思うように伝わらない」を解消する!エンジニアのための言語化力の鍛え方 - エンジニアtype | 転職type

    2024.05.21 スキル 「つまりどういうこと?」「要するにできるの、できないの?」「それって何の話だっけ」 技術的にどうするべきか正解は見えているのに、頑張って説明しても返ってくるのはそんな言葉ばかり……。「うまく伝えられない」という悩みを抱えるエンジニアは、少なくないのでは? 2023年のITエンジニア大賞・技術書部門で大賞を受賞した『良いコード/悪いコードで学ぶ設計入門』(技術評論社)の著者であり、SNSでの情報発信やイベント登壇でも活躍する「言語化のプロ」であるミノ駆動さんも、昔は「君が何を言ってるのか分からん」と上司に言われていたそう。 ミノ駆動さんはどのように言語化能力を伸ばしたのか。聞くと、出てきたのは「合意駆動」というキーワード。その正体とは? ミノ駆動さん(@MinoDriven) 新卒でNEC の関連会社に入社。その後キヤノンでの10年のエンジニア経験を経て、We

    【ミノ駆動流】「思うように伝わらない」を解消する!エンジニアのための言語化力の鍛え方 - エンジニアtype | 転職type
  • 技術Blogを毎月書くために心がけていること - Qiita

    はじめに こんにちは、京セラコミュニケーションシステム 西田(@kccs_hiromi-nishida)です。 いつもは技術的な内容を投稿していますが、今回は技術Blogを毎月書くために心がけていることを投稿しようと思います! 毎日投稿!とか毎週投稿!とかはちょっとハードルが高いな、けど継続して投稿したいと思っている方の一助になれば幸いです。 この記事の対象者 毎日Blog書くのはハードルが高いけど継続して投稿したいと思っている方 月に1くらいはBlogを書きたいと思っている方 前置き 継続して書いているといっても月1記事程度なので、それほど参考になるかはわかりません。 そして、私に合った方法というだけで、皆さんに合うかはわかりません。 ただ、こんなやり方もあるよ!というのを見ていただき、少しでも誰かの参考になれば嬉しいです。 まずは記事の骨組みを作ろう! 記事を作るとき、いきなり上から

    技術Blogを毎月書くために心がけていること - Qiita
  • テックリードに求められる「技術力」とは? 注目ベンチャー3社が語る、技術に特化して生きるキャリア

    2024年3月26日、オンラインイベント「マネージャーとテックリードどっちを選ぶ? エンジニアのキャリアについて音で語り合う」が開催された。キャディとカケハシ、ENECHANGEというテックベンチャー3社で、テックリードまたはエンジニアリングマネージャーとして活躍している方々が登壇した。今回はイベントの後半パートのパネルディスカッション「技術に特化して生きていくというキャリア。テックリードを担う上で必要なスキルと考え方とは?」の模様をレポートする。 テックリードとは何を担っているのか パネルディスカッションでは、テックリードとしてのキャリアパスを模索する人々に向け、IT企業各社のテックリードたちが必要なスキルや考え方について語った。 モデレーターはキャディ Drawer VP of Engineeringの藤倉成太氏。スピーカーはキャディ CADDi Drawer Growth部 I

    テックリードに求められる「技術力」とは? 注目ベンチャー3社が語る、技術に特化して生きるキャリア
  • 荒廃したテックブログの再生

    これは『2023年度を数字で振り返る「技術広報LT大会」』の登壇内容について、 口頭で話したことを補足しつつ、その他話せなかったこと含めてドキュメントにまとめたものです。 LT大会は楽しいですね、各社の発表も有益情報が多かったので、また行こうと思います。 TL;DR テックブログの投稿数が94倍、PV数が39倍に。 まずは、定石に則りアンチパターンを潰す。 自社の風土に合わせてローカライズしてアウトプットを継続する工夫を。 書きたいものを書いてもらった上で、「できる限り読まれる努力」は運営の責任。 当ドキュメントは色々私が書いてますが、全て編集長がやったことです。 荒廃したテックブログの再生 荒廃してました! レバテック開発部としては、年2しかテックブログを書いていませんでした。 荒廃の定義にもよりますが、私はこれを荒廃と見てました。 技術広報を促進していくタイミングで、まずはここから

    荒廃したテックブログの再生
  • draw.ioを使ってAWSの構成図を作成するコツ - Qiita

    案件でAWSの構成図を作成する機会があったので備忘兼ねて投稿します。 ※約5分で読めます 1. グループの内側から作成していく AWSの基的なグループ構成はこんな感じ 添付の場合、個人的には Public subnet or Private subnet > Availability Aone > VPC > Region > AWS Cloudの順番で作成することをオススメします。理由は内側のグループが肥大すると外側のグループの手直しが発生するためです。 今回作成した時に外側から作成してしまい、めっちゃ時間がかかってしまいました... 2. グループの左上を掴む 日語が下手ですみません。 なぜ左上を掴まないといけないか?試しにPublic subnetをクリックしてドラッグをすると、添付の様になりました。 クリックをするとグループの外から選択されてしまうため、選択したグループ内に存在

    draw.ioを使ってAWSの構成図を作成するコツ - Qiita
  • ターミナルから離れたくない…Tmux(&Neovim)の設定例🖊

    この記事の概要 tmuxneovimを組み合わせている様子… こんにちは!パン🍞と申します🏜 普段はフロントエンドを中心にパソコンをカタカタしている者です💻 私は普段のコーディング時のメインエディタとして、ターミナル環境下で、Neovimを用いています。 (Neo)Vimは、その独特な操作体系ゆえ慣れるまでがちょっぴり大変ですが、一度習熟すると非常に効率よくテキスト操作を行えるため、日々愛用しています。 また、開発作業の過程では、複数の画面を都度切り替えながらコーディングをしたり、複数のシェルを用いてコマンド操作を実行したくなる機会が多々あります。 例えば、 Viteでフロント開発環境を立ち上げてリアルタイムでコード変更を確認したい docker composeで複数のコンテナを立ち上げつつターミナルでログを確認したい それはそれとしてNeovimも並行して使いたい といった具合

    ターミナルから離れたくない…Tmux(&Neovim)の設定例🖊
  • 龍が如く7のすごいテストをなぜ我々は採用できないのか | フューチャー技術ブログ

    僕自身は龍が如くシリーズは、クロヒョウ2、極1、極2、0、3、4、5、6、0とやって、7はRPGだし主人公違うしなぁと思って、買うだけ買って後でやろうと積んでいたところ、CEDECのすごいテストの話を聞いて、(オリジナル版を積んでいたのに)インターナショナル版を買って始めてしまうぐらいインパクトがあり(そして積んでたのを後悔したぐらいよかった)ました。それ以降、維新極、7外伝、8は発売日に買ってプレイしてます。 こちらにその講演の詳細なレポートがこちらにあります。 https://www.famitsu.com/news/202009/11205564.html その8の発売前に龍が如くスタジオの技術責任者の方がXのアカウントを開設して、C++のコードを投稿されていたのですが、それに対してエンプラ開発目線で意見しているようなツイートを見かけて、「いや、システムの特性全然違うから」と思い筆を

    龍が如く7のすごいテストをなぜ我々は採用できないのか | フューチャー技術ブログ
  • デプロイ頻度やリードタイムの正確な計測にこだわらなくていい(前提はあるが) - mtx2s’s blog

    デプロイ頻度とリードタイムは、開発チームが自らのパフォーマンスをモニタリングするうえで欠かせないメトリクスである。それらが、収益性や市場占有率といった組織パフォーマンスに影響を与えるからだ。その調査結果は、DevOps Research and Assessment(DORA)が特定した4つのキーメトリクス、いわゆる「DORAメトリクス」の要素として浸透した(後述するが、DORAメトリクスで扱うのは、リードタイムではなく「変更のリードタイム」である)。 その重要性ゆえに、チームや組織はこれらのメトリクスの計測と可視化に努める。可能な範囲で正確な値が欲しい。そうして、チケット管理ツールやバージョン管理システムからテレメトリを収集、集計し、チームのモニタリングダッシュボードにその実績値を可視化するのだ。 しかし、しばらくメトリクスを運用してみると、その扱いづらさに気づく。計測値や集計値のばらつ

    デプロイ頻度やリードタイムの正確な計測にこだわらなくていい(前提はあるが) - mtx2s’s blog
  • いまさら聞けないgRPCの基礎 - Qiita

    はじめに この記事では、gRPCのgもRPCも何もわからないという方でもgRPCを理解できようにと思い書きました。できる限り丁寧な解説を目指したいと思うので、ここら辺がわかりにくかったなどがあればぜひコメントで教えてください! 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています!興味をお持ちいただける方は、こちらまで。 gRPCの概要 gRPCはオープンソースのRPCフレームワーク(後述)です。Googleによって開発され、2015年にオープンソースとして公開されました。gRPCは一般的にマイクロサービス間での通信や、モバイルアプリとバックエンドサーバー間の通信で用いられます。 マイクロサービスとは、機能ごとにサービスとして独立させることを指します。マイクロサービス

    いまさら聞けないgRPCの基礎 - Qiita
  • 最近Sassを使ってないなぁって話

    2023年10月26日 Webサイト制作 初学者向けの記事やSNSの投稿で「Sassはマジで必須!」なんて書いているのを見かけますが、私の場合、そういえば最近は素のCSSばかりでSassは使っていないなーと思ったので記事にしてみます。私自身Sassが大好きでずっとお世話になっていましたが、CSSの進化も著しく、使い所があまりなくなってきているんですよね。 ↑私が10年以上利用している会計ソフト! 変数やネスト、計算はCSSだけでOK 過去記事「Sass不要!CSSだけでも変数やネスト、演算子が使えるよ!」でも書いたとおり、Sassのメリットでもある変数やネスト、数値の計算はCSSだけでも可能です。 変数は過去記事「CSSで変数(カスタムプロパティ)を使ってみよう」で紹介したように、メディアクエリーによって柔軟に変化させたい時は、SassよりもCSSのカスタム変数の方が便利です。計算式を使い

    最近Sassを使ってないなぁって話
  • pull_request_target で GitHub Actions の改竄を防ぐ

    記事では GitHub Actions で pull_request event の代わりに pull_request_target を用い、 workflow の改竄を防いでより安全に CI を実行する方法について紹介します。 まずは前置きとして背景や解決したいセキュリティ的な課題について説明した後、 pull_request_target を用いた安全な CI の実行について紹介します。 記事では OSS 開発とは違い業務で private repository を用いて複数人で開発を行うことを前提にします。 長いので要約 GitHub Actions で Workflow の改竄を防ぎたい GitHub の branch protection rule や codeowner, OIDC だけでは不十分なケースもある pull_request event の代わりに pull_r

    pull_request_target で GitHub Actions の改竄を防ぐ
  • State of DevOps Report 2023 のまとめ

    2023 年版の State of DevOps Report が公開されました。 State of DevOps Report とは Google の DevOps Research and Assessment(DORA)チームが毎年公開している DevOps や開発生産性にまつわる年次レポートです。 記事で、今年のレポートの概要を簡単に見ていきたいと思います。 主な調査結果 Goodhart の法則を理解し、パフォーマンス向上の落とし穴を避ける 開発組織のパフォーマンスを評価する際、メトリクスの設定や評価の方法には注意が必要であり、特に「Goodhartの法則」という考え方を知っておくことが大切であると述べられています。 Goodhartの法則とは、簡単に言うと「測定が目標となると、それは良い測定基準でなくなる」という法則です。 この法則を踏まえた、パフォーマンスの評価や向上のため

    State of DevOps Report 2023 のまとめ
  • なかなかアウトプットできないあなたが技術記事を書くときのコツ

    技術記事を書くまでのステップについて順にコツを解説していきます。 特に、技術記事を書きたくてもテーマ選定が難しい、文章が苦手だ、なぜか筆が進まない、うまくまとめられないといった方に読んで欲しい記事です。 一応、エンジニア歴としては数年以内のジュニアレベルの方を想定しています。 以下のように技術記事を企画して、書いて、公開するためのプロセスごとにちょっとしたコツをまとめています。気になるセクションだけでも読んでいただければ幸いです。 テーマを決めよう 対象読者を決めよう 章立てを決めよう 書こう タイトルを決めよう 【余談】技術記事を書く理由とは 筆者について QiitaとZennにて6年以上の記事発信経験があり、 Qiitaでは5,942Contributionsを記録、 Zennでは3,253Likesをいただいています。 テーマを決めよう コツ:テーマのカテゴリによって執筆のポイントや

    なかなかアウトプットできないあなたが技術記事を書くときのコツ
  • リーダブルコードの要点整理と活用例まとめ

    はじめに 最近コードレビューの機会が増えてきたので、「リーダブルコード」を読み直しました。 リーダブルコードを読んでいく中で要点を整理し、実務の現場でコードを書いたりレビューをする際にどのように活用していくべきかを自分なりにまとめてみました。 この記事を読むことで、リーダブルコードの要点の把握と実際の活用例を学ぶことができます。 この記事の主な対象者 リーダブルコードの要点をサクッと知りたい人 初級~中級者(実務歴1~3年目)の人 コードレビューの機会が増えてきた人 これまで我流でコードを書いてきた人 リーダブルコードについて リーダブルコードはあくまで「こう書きなさい」と押し付け口調ではなく「こう書いた方がもっとよくなるよ」といった丁寧な語り口で書かれています。 それを前提として要点や活用方法をまとめていきます。 1章 理解しやすいコード 優れたコードについて リーダブルコードで優れたコ

    リーダブルコードの要点整理と活用例まとめ
  • 5年間 Laravel を使って辿り着いた,全然頑張らない「なんちゃってクリーンアーキテクチャ」という落としどころ

    この記事は Laravel Advent Calendar 2020 - Qiita 最終日の記事です。 TL;DR DDD や "真の" クリーンアーキテクチャは, Web 業界における大抵の現場ではオーバースペックだし,導入しても全員がついてこれるとは限らない app/UseCases ディレクトリだけ切って,ドメインごとに単一責務なクラスを置くと使いやすいよ ActiveRecord 指向のフレームワークで Repository パターンを無理に導入すると死ぬので, UseCase で Eloquent Model の機能を使うことを恐れるな はじめに Zenn では初投稿です。日Laravel コミュニティではもうお馴染みのようで実はあまり顔を出していない(?) @mpyw と申します。オンラインサロンの火付け役となった Synapse が最初の仕事でしたが,就職後すぐ会社が

    5年間 Laravel を使って辿り着いた,全然頑張らない「なんちゃってクリーンアーキテクチャ」という落としどころ
  • どうしてスタートアップのソフトウェア設計はいつもいつもブッ壊れてるんですかぁ? - タオルケット体操

    そんな皆さまの疑問にお答えします。 スタートアップのアーキテクチャがブッ壊れてるのってなんでェ? 先にざっくりまとめましょう。 巷でよく言及されるのはカネ、つまりは雇用するエンジニアの能力問題を元凶とする方が多いようです。 スタートアップの内情を知っていれば金と雇用の問題がどれだけ切実であるかについて異論を唱える人はいないとおもいます。しかし僕の考えによればこれはスタートアップのソフトウェア開発が抱える問題のうちのひとつ側面にすぎません。 つまりどんなに優秀な人間をかき集めようがスタートアップのソフトウェア設計は近い将来壊れる宿命にあるということです。 スタートアップの存在意義は未来の不確実性そのもの 普通のやつらの上を行け、ではありませんが。 スタートアップ企業はうまくいくかわからない事業をやることそのものに価値があります。 「誰からみてもうまくいくに決まってる」事業で金も人材も潤沢にあ

    どうしてスタートアップのソフトウェア設計はいつもいつもブッ壊れてるんですかぁ? - タオルケット体操
  • 開発生産性について議論する前に知っておきたいこと - Qiita

    はじめに 事業としてソフトウェア開発を行う企業にとって、自分たちの開発チームの生産性が十分に高いのか、あるいはそうでないのかについては大きな関心があります。 そのこと自体は、何かを計測し、改善するというのは営利企業としては健全です。一方で、ソフトウェアエンジニアリングの世界で「生産性の高さ」だと主張できる汎用性の高い指標は存在しません。こういった状況の中で、「生産性」を巡る議論は経営やビジネス部門とエンジニアチームとの間で繰り広げられ、場合によっては大きな不和や不信感につながることも珍しいことではありません。 今回は、エンジニアの開発生産性について、さまざまなステークホルダーと議論する上で把握しておきたいさまざまな論点について解説します。それによって、「我々が当に議論すべきテーマは何か」についての共通認識をつくるための土台を構築することを目的としています。 もしかしたら改善したいことは「

    開発生産性について議論する前に知っておきたいこと - Qiita
  • SOLID原則に従って行うリファクタリング実践 | メルカリエンジニアリング

    この記事は、Merpay Advent Calendar 2022 の21日目の記事です。 こんにちは。メルペイBackendエンジニアのfivestar(@fivestr)です。 記事では「SOLID原則」と呼ばれる設計原則に沿って実際に行ったリファクタリングについて、メルペイの「あと払い」サービスの開発現場事情を踏まえながらご紹介していきます。 あと払いの歴史とコード負債 私が所属するCredit Designチームではメルペイの「あと払い」や「メルペイスマートマネー」といった与信サービスの開発を行っています。中でも「あと払い」はメルカリが2017年にリリースした「メルカリ月イチ払い」を前身とする歴史の長いプロダクトであり、単純な機能追加だけでなく、設計上大掛かりな変更を伴う修正を繰り返しながら今日まで成長してきました。 例えば、あと払いをメルカードの決済・清算のバックエンドとして統

    SOLID原則に従って行うリファクタリング実践 | メルカリエンジニアリング