Skip to content

Instantly share code, notes, and snippets.

View curipha's full-sized avatar
🕊️
Pray for peace

OKAMOTO Taichi curipha

🕊️
Pray for peace
  • Kyoto, Japan
  • 19:26 (UTC +09:00)
View GitHub Profile
@matsubo
matsubo / credit_card_bin_codes.md
Last active June 11, 2024 05:23
Credit Card Bin Codes

概要

クレジットカード番号には法則があり、先頭6桁でカードの種類を識別、分類することができる。

詳細はISO/IEC 7812で規定されている。

ISO/IEC 7812 - Wikipedia https://ja.wikipedia.org/wiki/ISO/IEC_7812

先頭の6桁を銀行識別番号(Bank Identification Number、略称:BIN)ないしは発行者識別番号(Issuer Identification Number、略称:IIN)と呼び、この先頭6桁でカード発行会社(イシュア、issuer)が判るようになっている。

@shyouhei
shyouhei / gist:266178ffedab5767a5b69b972c76f88a
Created September 27, 2017 07:31
優秀なプログラマーになるためのコツ

優秀なプログラマーになるためのコツ

重要な順で

優秀なプログラマーになるには非常に長い時間がかかるという現実を直視すべし

優秀なプログラマーというのは寝ている間に異世界に召喚されて無双するのとはわけが違うんですよ。

自分の例で言うとプログラミングを始めた中学生の時から優秀なプログラマだったかって、そんなわけない。みんなヘッポコからスタートしているに決まってるわけです。以来二十余年、地道に生き恥を晒し続けてきた結果として、現在いちおう業界の末席を汚すところまで来ている。このプロセスから目を背けるべきではないです。優秀なプログラマーに生まれる人間なんかいない。優秀なプログラマーに「育つ」んだし、それには時間が必要。今日から無双したいと思うな。

@azu
azu / README.md
Last active March 15, 2024 09:59
スタートアップ/企業の調べ方
@ymmt2005
ymmt2005 / neco_skills.md
Last active September 24, 2023 10:59
Neco プロジェクトのスキルシート

Neco プロジェクトのスキルチェックシート

Neco は大量の物理サーバーを効率的に管理・運用することを目的とした開発プロジェクトです。 Kubernetes を中心に高度な自律運用の実現を目指しています。

本文書はプロジェクトに参加しているメンバーが身に着けている要素技術を並べたものです。

応募時点ですべてを身に着けている必要はまったくありません。 社内にはチュートリアル資料が多数用意されていますので、必要に応じて学べます。

@mpppk
mpppk / clean_architecture.md
Last active July 2, 2024 01:58
クリーンアーキテクチャ完全に理解した

2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。
と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。

このドキュメントを完成させるために、今後以下のような更新を予定しています。

  • TODO部分を埋める
  • 書籍を基にした理論・原則パートと、実装例パートを分割
    • 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。

2021/1/22追記:

これは私が支援先に提供した、1 on 1 に関するノウハウや、思いを述べたドキュメントを元にしています。企業の枠を超えて共有したいことが多いので、ここに貼ります。

概要

  • 世の中には 1 on 1 の本があるようですが、とりあえずは『1 on 1 で 何を話すのか? マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア』を読んでもらえればよいと思います (higepon さんに感謝!)。
  • 1 on 1 は 1 対 1 で話すミーティングで、基本定期的にやります。上長とメンバーとの間で行うのが基本です。
  • グループ/チームでのミーティングを補完するためのものです。
    • みんなの前では話しづらい、込み入った内容を話します。
    • チームとして行っているタスクの進捗確認に 1 on 1 を使うのは避けましょう。それは 1 on 1 の目的に沿っていません。
  • 基本、「メンバーの時間」と捉えてください。メンバーが話したいこと、上長に質問したいこと、相談したいことを話す時間です。
  • ですので、上長は相手の話をさえぎらず、聞くことに徹してください (話すのが得意な人、好きな人がマネージャになっている可能性が高いというバイアスに注意しましょうw)。
@ymmt2005
ymmt2005 / howto-tech-docs.md
Last active May 10, 2024 03:46
技術文書の書き方

技術文書の書き方

このメモは、私(@ymmt2005)が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。

科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。

しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。

@thesamesam
thesamesam / xz-backdoor.md
Last active June 27, 2024 15:18
xz-utils backdoor situation (CVE-2024-3094)

FAQ on the xz-utils backdoor (CVE-2024-3094)

This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don't yet know everything about what's going on.

Background

On March 29th, 2024, a backdoor was discovered in xz-utils, a suite of software that