より筋肉質なチームにするために、開発者が見るべき21のDevOpsアウトプット指標 - Qiita
1. はじめに システム開発にまつわるチームや組織の活動は、指標なんかで測れるわけないやろ～、という声は根強いです。ましてや、それが人の評価になろうものなら、感情的な反発さえありえます。Martin Fowlerもこちらよりです。 一方で、何らかの指標で測れるはずじゃないの？という声も根強い気がします。測れんかったら、良くなったかどうか、どうやって判断すんねん、という意見ですね。DORA Metricsを擁するGoogleはこちらよりですかね。 私はどちらなのかというと、後者で、測れるものは測りたいタイプです。もちろん、すべてが正しく測れるなどとは思っていません。そもそも定性的な指標と定量的な指標のバランスが大事であり、定量的な指標でさえも、現実世界では正確性と計測コストはトレードオフだと思ってます。 しかし、ではじゃあ、具体的にどうすればいいのか？それをまとめてみましたので、ご覧ください
WSLには3つの「バージョン」がある - Qiita
Windows で Linux の機能を手軽に扱うことのできるWSL (Windows Subsystem for Linux)． 「WSL」と「WSL2」の2つがあるのはご存じの方も多いと思いますが，実は他にも「バージョン」があることをご存知でしょうか． 順に解説していきます． Ⅰ:「WSL1」と「WSL2」 WSLには，大きな仕組みの違いから2つのタイプがあります． WSL1（WSL）が先に開発されており，後発で WSL2 ができました． この種類のバージョンは，この2つのみです．（WSL1.1とか，WSL2.1とかはありません。） 現在のWSLのバージョンを確認するには，Powershell上で以下コマンドを実行します． （コマンドに失敗する場合は，Windowsのバージョンが古く，WSL2が利用できない可能性があります）
初学者が覚えたいチーム開発でのGit操作 - Qiita
はじめに 個人開発の場合はそんなに意識することがないGitですが、チーム開発においては重要な役割を果たします。 はじめのうちは構造が見えず混乱するかと思いますが、流れをイメージ出来ればそんなに難しいものではありません。 これを見れば開発に必要なGitコマンドとリポジトリの構造、Githubでの管理手順を理解し開発の現場で実践できるようになります。 そもそもGitとは？ 変更履歴を記録・追跡するための分散型バージョン管理システムである。 ざっくりいうとファイルのバージョン管理が簡単にできるツールといえます。 目次 Gitを理解するための基本用語 開発の流れ その他開発で覚えておきたい便利コマンドと注意点 vscodeでのGUI操作について 最後に Gitを理解するための基本用語 リポジトリ（repository） ファイルやディレクトリを入れて保存しておく貯蔵庫 リモートリポジトリ...特定
Go強化月間～開発する上で知っておくべき知見を共有しよう～ - Qiita
Cannot participate because closed. ClosedWhen you participate, we will assume that you have agreed to the terms of use Require logged in for participate. campaignHow to participate① Check rule and participateCheck rule of posting campaign and participate. ② Write articleWrite article with content that is consistent with the theme of posting campaign! ③ Register campaign and post articleRegister ca
オブジェクト指向プログラミングは終わった カプセル化が悪い(感想戦) - Qiita
が(良くも悪くも)注目頂き、その観測で思ったことのメモです。1年後の自分用です！ もっかい言いたいこと再考のポエムです。 概要 関数型には意図的に触れたくなかった 継承や再利用性への懐疑の共通認識 抽象化戦略開発戦略で補う話 タイトルは釣り 抽象化という言葉のふわっと感 カプセル化が問題 関数型言語には意図的に触れたくなかった ポリモーフィズムのくだりで、関数型のご指摘が多かったのですが、あえて直接は触れたくありませんでした。これは、オブジェクト指向 vs 関数型にしたくなかったからです。(結果、Rust/Goに被弾させました) なぜかと言えば、オブジェクト指向を(結果として)衰退させたのは、あくまでも 開発手法の変化 や設計論の精錬が主軸だと認識しています。 不確実性に適応する上で、継承やカプセル化による状態隠匿という戦略が、良い筋に動かず、オブジェクト指向なりに変化を遂げた結果だと考え
特別な理由なしにgit-flowを新規採用するべきではない - Qiita
私がこれまでGitの研修講師やブランチ戦略のコンサルティングをおこなってきた経験に基づいて、この記事を書きます。 Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A succ
まだ PostgreSQL の開発で疲弊してるの？ - Qiita
{ "plpgsqlLanguageServer.database": "データベース名", "plpgsqlLanguageServer.user": "ユーザ名", "plpgsqlLanguageServer.password": "パスワード", "plpgsqlLanguageServer.definitionFiles": [ // glob をサポート。 "**/*.sql", "**/*.psql", "**/*.pgsql" ], // Language Server が対応するファイルの拡張子はデフォルトで ['*.pgsql', '*.psql'] です。 // （ SQLite など他の RDS と競合させないためです。） // '*.sql' のファイルも対応させたい場合は、下記の設定を追加してください。 "files.associations": { "*.sq
テストコードをただ書くだけで満足している人々をこの記事でビンタしたい - Qiita
まえがき 世間ではテストをしないこと/テストを書かないことを悪とするみたいな文化が定着してきたのか、テストを書かない開発というのが減ってきてると思います。 では「正しくテストを書けているか」「テストを書く文化を生かしているか」というとどうでしょう？ これらの問いに答えられずテストを書くことをゴールにして満足していると、それは宝の持ち腐れならぬテストコードの持ち腐れとなります。 執筆のモチベーション この記事を印刷して札束のごとくビンタするのが目的です。 以下に該当すること”だけ”を考えているような場合はビンタされるかもしれません。（絶対ではないですが危ない可能性があります） うちはテスト書いてるから大丈夫！ちゃんと開発工数とは別に単体テスト工数も見積もってるよ！ ちゃんとホワイトボックス的に書いてカバレッジ担保しているからうちはちゃんとテストしてるよ！ コード修正の都度ちゃんとテストコード
Mac版DevToysがなかったので3日で作って公開した。 - Qiita
きっかけ こちらの記事で紹介されていたDevToysを使ってみたら非常に便利で、これは日常使いしたい！となりました。 しかしなんということでしょう。DevToysはWindowsアプリでありmacでは使えないではないですか！iOS・macアプリ開発者の私としてはmacを捨てるわけにはいかないので、mac版のDevToysを開発しました。 できたもの というわけで3日ほどでmac版DevToysクローンを作成しました。 以下のReleaseからダウンロードできます。 開発 可能な限り高速で開発をする必要があったため、他のOSSどううまく使うかが勝負です。 アプリ全体 他の開発中のmacアプリからユーティリティ系コードは大部分を流用しました。 これでだいぶ開発が楽になります。 Json <> Yaml OSSのYamsを用いて実装しています。本家DevToysではなぜか Yaml -> Jso
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
OSS未経験「なにから始めたらいいかわからない…」←これを一気に解決する神リポジトリ - Qiita
はじめに こんにちは。WEBエンジニアのmasakichiです。 OSSを始めたいと思いながらも「なにから始めたらいいかわからない…」と悩んでいませんか？ そんなOSS未経験者にGood First Issueというリポジトリをお勧めしたく記事にしました。 この記事で書いてあること この記事には以下の2つが書いてあります。 Good First Issueについて Good First Issueからコントリビュートするまでの流れ（経験談） Good First Issueとは OSSにコントリビュートしたことのない開発者でもすぐに始められる人気プロジェクトをピックアップしたキュレーションサイトです。 プロジェクトのリンク先はgithubリポジトリで管理されています。 リポジトリはこちら キュレーションサイトはこちら Good First Issueでは下記の基準を満たしたプロジェクトがピ
A Philosophy of Software Design：要約 - Qiita
概要 内容と動機 これは、「A Philosophy of Software Design」の要約になります。 本書の内容としては、筆者が経験ベースで、ソフトウェアの複雑性の原因とどれにどう向き合うのかをまとめた内容です。 普段チームで開発する中でわかりづらさや、設計に関する違和感を感じることがあります。 その自分の違和感が本当に正しいものなのか、仮にそうだとしたらきちんと言語化してレビューしたいという動機から本書を読むことにしました。 170ページの本書を完璧に要約することは困難なので、幾分自分にとって印象深かったことが選ばれていると思います。 逆に、その過程で触れられなかった章もありますので、その点ご留意ください。 また、ここでは具体例は少ないですが、ある程度大きなコードベースで開発した方であれば想像しながら読めるのではと思っています。 もし、具体例を参照したい場合は、ぜひ本書を読んで
Python開発者のためのセキュアコーディングのコツ10個 - Qiita
本記事は2021年9月27日に公開したPython security best practices cheat sheetを日本語化した内容です。 2019年、Snykは最初のPythonチートシートをリリースしました。それ以来、Pythonのセキュリティの多くの側面が変化しています。開発者向けセキュリティ企業として学んだこと、そしてPython特有のベストプラクティスに基づいて、Pythonのコードを安全に保つために、この最新のチートシートをまとめました。 【チートシート】2021年版Pythonセキュリティベストプラクティス 本記事では、下記に関するPythonのセキュリティに関するヒントを紹介します。 外部データを常にサニタイズする コードをスキャンする パッケージのダウンロードに注意 依存先パッケージのライセンスを確認する システム標準版のPythonを使用しない Pythonの仮
2022年の Flutter ロードマップ【要約】 - Qiita
最近、Flutterのロードマップが更新され、2022年のものが追加されました。 Flutterの最新情報は追いかけたい、でも英語読むのはめんどくさい！ そんな方に向けて、本記事ではこのロードマップの要約を記載します。 あくまで個人の要約ですので、細かいニュアンスや詳細を知りたい方は、 下記の元記事を読んでください。 時間がない人向け 短くまとめると、以下の内容でした。 開発者体験向上させる デスクトップのサポートをstableチャンネルにする Webも色々向上、ページ埋め込み機能を実装予定だ Material 3のサポートとか色々予定 Dartに静的メタプログラミングの追加予定 全文の要約 2022年、尽力する部分 開発者体験 開発者が愛するSDKを作りたい。 例えば、 共通の問題を解決するwidgetやプラグインの追加 現状のAPIの整理 単純に多く使われるパターンのAPIの導入 エラ
要求定義と要件定義の違いを考える - Qiita
要求定義と要件定義についての記事というのは需要があるようですね。 検索されるだけなのか？そもそも話し合いの中では、その「定義」を確定して、話しておくことが大事なのですよね。言語を学ぶ上で、まずはひらがなからカタカナからそしてローマ字など文字を学ぶように、プログラミング用語や現場で使う単語などというのは意識して使っていかないと追いつけなくなってしましますからね。 役割分担、期日を決めるなどマネージメントの方もプロジェクト進行では、考えていきたいですね。 ##最近の近況 バーチャルな世界に興味があり、バーチャルSNSなどにも顔を出しながら作業してます。 ##はじまり はぁ… なんでシステム開発が失敗するんだろう… 仕様の変更が多くて… 言った言ってないのトラブルから避けたい… システム動かしてみても全然使えない… 実は．． 事業運用をオペレーションレベルに展開しないままに、 システム開発をして
libbpf-rsを使ったRustとeBPFプログラミング - Qiita
この記事は、Supershipグループ Advent Calendar 2021の17日目の記事になります。 はじめに この記事ではeBPFを活用してLinuxカーネルにフック用プログラムを注入することにより、ネットワークパケット処理を拡張する例を示します。 その実装にあたり、Rustとlibbpfの統合を行うlibbpf-rsを使った開発体験を記したいと思います。 TL;DR libbpf-rsによってRustとeBPFを組み合わせたプログラムのコンパイルやロード処理の手間は省けるようになります。実際、システムコールの呼び出し部分はほとんど意識する必要がありませんでした。 一方でeBPFプログラミングで特に苦労したのは以下の点でした。 デバッグとテスト つまりeBPFプログラミングにおいて周辺的な問題がツールによって解決されていき、よりプログラムの機能そのものの問題に時間を割くことができ
「1枚のシート」でエンジニアとデザイナーのストレスが激減した話 - Qiita
「考慮もれ」「手戻り」をなくしたい モチベーションクラウドシリーズのデザイナーです。 フロントエンドエンジニアのみなさんは、画面デザインを見て「どう実装するんだ？」とストレスを感じたことはないですか？ 例えば... 👨💻 フロントエンド「Emptyのときはどうするんだろう？最初から考慮してほしいな...（ストレス）」 👩🎨 デザイナー「この状態も考えないといけないのか。確認するだけで1日終わるな...（ストレス）」 →お互いにとって、よくない！！！！！ こうした状態を受けて、お互いにとってストレスなく開発するために、デザイナーとフロントエンドで制作プロセスを改善しました。 今回は、プロセス改善のステップや導入してみて効果的だったツール（シート）についてお伝えします。 【まず初めに】 「UI Stack（状態デザイン）」の必要性の周知 UI Stackとは、UIの考慮すべき5つの
エンジニアリングマネージャーとしての開発力向上の取り組みついて - Qiita
スクワッド体制における留意点として、「Spotifyは "Spotifyモデル "を使っていない [3]」で以下のように述べられているように、単に方法論を真似るのではく、自分の組織と向き合い、学習して、進化し続けることが大切であると思います。READYFORにおいても日々、組織体制について議論し、改善を進めています。 ビジネスユニット、部門、チーム、マネージャーは、Spotifyの失敗した方法論に固執してはいけません。彼らはSptifyのモノマネよりも効果的に組織構造の役割と責任を伝えることができるのです。 あなたがSpotify Modelを見つけたのは、自分のチームをどのように構成するかをいつも考えていたからでしょう。でもここで止まってはいけません。学習を続けてください。 1-2. READYFORのスクワッド体制 READYFORの場合、どのようなスクワッド体制を敷いているか？ ひと
OCaml でゲームボーイエミュレータを書いた話 - Qiita
はじめに ブラウザ上で動くゲームボーイエミュレータを OCaml で書きました。以下のページで試せます。 デモページ いくつかの homebrew ROM も一緒になっているのでいろいろ遊んでみてください。おすすめは「Bouncing ball」と「Tobu Tobu Girl」です。最近のスマホならだいたい安定して 60 FPS 出るはずなので、スマホでも遊べます。 レポジトリはこちらです。 スクリーンショット なぜ OCaml でゲームボーイエミュレータ？新しいプログラミング言語を学ぶ過程で以下のように思ったことはないでしょうか？ 簡単なプログラムなら書けるが、中規模以上のコード1をどうやって書けばよいのか分からない 発展的な言語機能2も勉強しなんとなく理解した気になったが、実践のなかでどのように活用すればいいのかが分からない OCaml を本格的に勉強し始めてた数ヶ月前の筆者はまさに
「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由 - Qiita
「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由チーム開発プロジェクト管理マネジメント はじめに 前回、なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのかの記事において、プロジェクト型の人員規模を柔軟に変化させる開発スタイルに関して、理論的なスケジュール削減の限界について考察しました。その際に、チーム型開発や組織とソフトウェアの紐付けについても示唆しました。 今回は、チームでソフトウェアを開発することに関して、「フロー効率」と「リソース効率」という観点から考察し、なぜ私たちはチームで開発するのか、あるいはなぜプロジェクト型を採用するのかについての考え方を深めていきたいと思います。 そして、組織における効率性の価値観が異なると、新しい効率性に関して理解をする前に「もったいない」と感じてしまい、新しい文化を取り入れづらくして
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
