毎週やってる定例会のアジェンダに「これは月末の会で」としておくとスキップされがち - hitode909の日記
開発しているアプリケーションのフロントエンドの様子を見る会（フロントエンド草むしり会）を毎週30分ずつ開催している。 式次第の雰囲気を紹介するとこういう形で、毎週見るメトリクスやエラーに加えて、月に1回くらい様子を見たい項目もある。 アップデート関連は、Pull Requestが出たら都度対処するのだけど、それに加えて最近の様子はどうだろう、と眺める時間を取りたい。そういうものは月に1回くらい見ることにしている。 毎週 この会の大義を確認しよう 終わってない宿題を眺めよう エラーのメトリクスを見よう パフォーマンスのメトリクスを見よう 月の初めの会のみ Dependency Dashboardのアップデート候補を見よう Dependabot alertsを見よう ここで「月の初めの会のみ」としているのがポイントで、今回が月の初めかどうかは誰が見ても明らかで、間違いが起きにくい。 これを仮に
Wordleは4つの単語を覚えるだけで必ず正解できる - Qiita
Wordleとは？ フィードバックを頼りに、隠された 5 文字の英単語を当てるゲームです。 要は「マスターマインド」や「ヌメロン」等と呼ばれるゲームの英単語版です。 知らない方でも以下のような奇妙なツイートは目にしたことがあるかもしれません。 この記事は何？ Wordleにおいて、最初にある4つの単語を入力すれば 100% 正答にたどりつけることが Python を使った解析でわかりました。 具体的には、 それら 4 つの単語を入力した時点で解の候補が平均 1.1 個まで絞られる 96% 以上の確率で 5 回で正答できる 100% の確率で 6 回以内に正答できる といった感じです。 本記事では、それらの単語をどのように探したかをザックリ解説しつつ（ネタバレ防止のため）最後にその4つの単語をご紹介します。 （結果だけ見たい方はこちら） 方法 色々な英単語の組み合わせに対し「それらを入力した
コードのコメント、何をどう書けばよいのか
開発者向けQ＆Aサイト「Stack Overflow」は2021年12月23日（米国時間）、コードコメントを書くためのベストプラクティスを紹介した。これはミルズ大学のコンピュータサイエンスの教授であるエレン・スパータス氏による寄稿記事だ。 この記事は2021年7月5日に掲載されたもので、同ブログで2021年に人気を博した記事のトップ10の1つとして再掲載された。 スパータス氏は、「コメントは、出来の悪いコードの言い訳や修正として書くものではなく、（コードが表すものと）異なるタイプの情報を提供することで、良いコードを補完するものだ」との見解を示した。その理由としてシステムアーキテクトのピーター・ヴォーゲル氏が2013年に投稿したコメントに関する3つの事実を挙げた。 （1）コメントを書いて、維持するには費用がかかる （2）コンパイラはコメントを無視するため、コメントの内容が正しいかどうか機械的
TypeScript 型レベルプログラミング フリースタイルガイド - Object.create(null)
TypeScript の型レベルプログラミングのための真面目なスタイルガイドではありません. 型なしラムダ計算で喜ぶような人間が使うための諸刃の剣です. この記事の内容は TypeScript の 2022 年 1 月時点での最新版である 4.5.4 に基づいています. 将来のバージョンでの妥当性は保証しません. 「型〜」「〜型」という用語の「型」はしばしば省略します. 値レベルの話題は一切登場しません. 以前作った型レベル Brainfuck インタプリタはこのスタイルに則っているので参考にどうぞ. いつまでこのネタを引きずるんですか? パラメータに対して制約を付与しない 型定義のパラメータに対して extends を使って制約を付与すると, そのパラメータに与えられる引数を制約を満たすもののみに限定することができます. 例として, 以下の Append には string の部分型のみ
CSS Gradient Generator
.gradient { background-image: linear-gradient( 45deg, hsl(240deg 100% 20%) 0%, hsl(281deg 100% 21%) 8%, hsl(304deg 100% 23%) 17%, hsl(319deg 100% 30%) 25%, hsl(329deg 100% 36%) 33%, hsl(336deg 100% 41%) 42%, hsl(346deg 83% 51%) 50%, hsl(3deg 95% 61%) 58%, hsl(17deg 100% 59%) 67%, hsl(30deg 100% 55%) 75%, hsl(40deg 100% 50%) 83%, hsl(48deg 100% 50%) 92%, hsl(55deg 100% 50%) 100% ); } A front-end we
モブプログラミングを導入し、チーム一丸となってタスクに取り組むようになった話 | メルカリエンジニアリング
はじめに メルペイ ML Platformチームの@ysk24okです。この記事は、 Merpay Advent Calendar の4日目の記事です。 本記事では自チームにモブプログラミングを導入し、チーム一丸となってタスクに取り組むようになった話を共有します。 モブプログラミングとは モブプログラミング（以下モブプロ）とは、モブプログラミング・ベストプラクティスでは「3人以上の人々が1台のコンピューターの前に座って協力しながら問題を解決していくこと」と定義されています。Hunter Industries社のWoody Zuill氏が2015年頃からカンファレンスなどで発信しはじめたことで世の中に広まっていったと言われています。 モブプロでは1人のタイピストとその他のモブに分かれ、10分でタイピストを交代します。その他のモブは基本的にコードは書かず、問題解決のためのアイデアをタイピストを
イミュータブルでゆこうに参加してきた - 天の月
modeling-how-to-learn.connpass.com 今日はこちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。 会で話されていたこと イベント資料 イミュータブルデータモデルの極意～川島義隆さん～ 川島さんの問題意識～Division into cases～ Dataの場合分け EventとResourceの関係性 EventとResourceのサブタイプ Resource同士の関連付けをする際のコツ 記録として残すEvent, 残さないEvent ドメイン駆動設計とイミュータブルデータモデルの素敵な関係～増田亨さん～ イミュータブルについての厳格性 必ずイミュータブルにする際の設計パターン 増田さんがイミュータブルに拘る理由 ドメインイベントの観点から再考するソフトウェア設計～かとじゅんさん～ ドメインイベントとは ドメインイベントはなぜ有用か
ドメイン駆動設計とイミュータブルなクラス設計
クラスをイミュータブルに設計するパターンの紹介 ・閉じた操作 ・withメソッド ・イベントリポジトリ＆集約ファクトリ
Rust初心者殺しの文法10選 - Qiita
概要 この記事ではRust初心者が驚いたり混乱させられたりするようなRustの文法を10項目集めてみました。 これらの項目は知らないと理解できなかったりコンパイルエラーに悩まされたりする一見厄介なものたちなのですが、そのような直感的でない挙動を敢えてさせているところには重要な意味が込められていることが多いです。 そのため、これらの項目を通してRustが目指しているものや実現したい機能の一部を垣間見ることができると思います。 1. デフォルトの代入がムーブ Rustの最大の特徴が所有権の概念であることは有名ですが、それでもなお初心者殺しになるのがムーブです。 以下のコードがコンパイルエラーになるメジャーな言語は現状Rustくらいしか無いでしょう。 let mut a = vec![1, 2, 3]; let mut b = a; // ここでaの持つベクタの所有権がbにムーブされ、aは無効に
Node/Deno でソースコードにテストを書く
tl;dr ファイルをそれ単独で単体テストとして実行するボイラープレートを編み出した そのヘルパとして mizchi/test という実装を作った なぜソースコードにテストを書きたいか Rust や Python の doctest ではソースコードにテストを書く方法があります。 ソースコードにテストを書けると、コードとテストの心理的な距離が近くなってテストが書きやすくなる、という肌感があります。(諸説あります) 実装とテストが混ざって汚れるのが嫌という意見も理解できますが、それはありつつ認めた上で、あとでリファクタする前提で最初の一歩をその実装に書けると嬉しい、という気持ちがあります。 現状の Node だととりあえず assert するだけという単純なテストを書くことは可能ですが、構造化する方法がないので、簡単なスクラッチの時ぐらいしか行われません。 // test.js import
アセンブラをゼロから作って自作コンパイラをアセンブルするまで(日記)
GNU Assembler互換(サブセット)のアセンブラをGo言語でフルスクラッチで作ってみました。 開発22日目で自作Goコンパイラ(をセルフホストしたときに出力される20万行のアセンブリ)をアセンブルすることに成功しました。 どうやって作ったかというと、小さいコードを GNU Assembler (以下 as) に食わせて出力されたバイナリを観察する、を繰り返して中のロジックを推定し再現しました。as の実装は見ていません。(一瞬見たけど巨大すぎて何もわからなかった) アセンブラ自作は、やってみるとコンパイラ自作よりだいぶ簡単でハマりポイントも少ないので、学習テーマとしてはおすすめです。2箇所ほど難所(命令エンコーディングのルールを理解するのと、ジャンプ命令の最適化)がありましたがそれ以外はさくさく楽しく作れました。 作ってみた結果、アセンブリ言語の理解が深まったのはもちろんのこと、E
2021年 - これからFlutterを始める人へ学習方法のススメ
はじめに 非常に有り触れたタイトルになっていますが、最近私の周辺で Flutter を始める方が増えてきており（推奨している影響もある）、その都度同じリンクを貼るのが億劫になってきたのでまとめることとしました。ただこの手の内容だと「ただリンクを貼るだけ」みたいな記事も散見されますが、それだけだとつまらないのでそのリンク先で何が学べたか、どう感じたかも一言添えて紹介します。私も1年半前から Flutter に出会い1から学習した身ですので、これから Flutter を始める方とも感覚的には近いと認識しています。より再現性が高くなるよう、私が実際に学習で使用した内容を中心に取り扱っておりますので参考にして頂ければと思います。 対象となる読者 Flutter SDK も最近インストールした正にこれから始める人 学習するか迷っているが全体像を把握したい人 自分で手を動かしてものを作るのがはじめてな
Makefile の関数一覧
Makefile の組み込み関数の一覧です。 公式のドキュメントを読みながら、関数の引数と使い方について備忘録としてまとめました。 Makefile での関数の書き方は $(関数名 引数,...) または ${関数名 引数,...} です。 文字列操作・検索の関数 subst 文字列の置換です。使い方は $(subst 置換前,置換後,対象) FILES := hoge.c hoge.h fuga.c fuga.h all: @echo $(subst hoge,piyo,$(FILES)) # => piyo.c piyo.h fuga.c fuga.h patsubst パターンマッチによる文字列の置換です。使い方は $(patsubst 置換前,置換後,対象) FILES := hoge.c hoge.h fuga.c fuga.h all: @echo $(patsubst %.c
タイムゾーン呪いの書 (知識編)
「タイムゾーン呪いの書」は、もともと 2018年に Qiita に投稿した記事でしたが、大幅な改訂を 2021年におこない、同時にこちらの Zenn に引っ越すことにしました。 この改訂では Software Design 誌の 2018年 12月号に特集の一章として寄稿した内容も取り込みつつ、夏時間をめぐって各地で起きつつある変化について 2021年 6月現在の状況なども追加しました。そんな追記もしていたら記事全体が長大になってしまったため、この「知識編」と、「実装編」・「Java 編」に記事を分けました。「知識編」は、導入にあたる第一部です。 Qiita のほうは、引っ越した旨とこの引っ越し先へのリンクだけ追記して、しばらくそのまま残すつもりです。 はじめに タイムゾーンという概念のことは、ほとんどの人が聞いたことがあると思います。ソフトウェア・エンジニアでも多くの方が、時刻やタイムゾ
クラス設計本格入門 JJUGナイトセミナー 2021-6-16
イベントの動画 : https://www.youtube.com/watch?v=2Z1CJhPk-f8 オブジェクト指向プログラミングはクラス設計。 クラス設計はプログラムの分割。 クラス設計の焦点は、ビジネスルールを表現するクラスと、ビジネスアクションを表現するクラス。 クラス設計やパ…
ソフトウェア設計についての原則や法則についてまとめてみた
ソフトウェア設計について、YAGNIやSOLIDなど多くの原則・法則があることが知られていますが、その解釈にはぶれが存在することが多いです。そこで、特に有名なものあるいは有用と感じることが多いものをいくつかピックアップして、その解釈やトレードオフについてまとめてみました。 注意としては、SOLIDが入ってることからわかる通り、主にOOPに関する文脈になります。また、各原則の定義については概ね知っている前提で書いているのであまり初学者向けの記事ではないかもしれませんのでご承知おきください。 YAGNI（You ain't gonna need it.） YAGNIは、予測による実装が実際に役立つことは少ないという経験則から生まれた原則です。 一般にオーバーエンジニアリングが利益をもたらすケースは限定的で、どちらかというとプロジェクトに害を与えることが多いとされています。YAGNIは日々状況の
単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場
単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や
プログラマの抱いている名前についての誤謬
パトリック・ミッケンジー（Patrick McKenzie）さんのブログ・エントリ、 “Falsehoods Programmers Believe About Names” の日本語訳です。翻訳の公開を快諾してくださったミッケンジーさんに感謝します。 公開: 2012-02-22 Posted on June 17, 2010 by Patrick きょう、ジョン・グレアム゠カミング（John Graham-Cumming）が、正しくない文字が含まれているといって彼のラスト・ネームを受け付けないコンピュータ・システムへの不満の記事を書いていた。もちろん彼の名前に「正しくない」ところなどない。当人の申し出たものが当人を識別するものとしては相応しいのであって、定義からして名前とはそういうものである。このことにジョンは当然ながらいらだったし、そうなるのもきわめて正当なことだ。定義からすれば事実
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GraphQL を活用したスキーマ駆動開発の実践 / schema-driven development with GraphQL
「Electron 14」が正式公開 ～次のバージョンからリリース間隔は12週間→8週間に／Electronアプリの開発者はリリース間隔の変更とリリースポリシーの変更に注意
