IntelliJのマークダウンプレビューが、なんとなく実際に編集しているところとズレてスクロールされるのがストレスでした。
多分画像とか入れているせい。
この自動スクロール、オフにできる設定があったので、MEMO
IntelliJの設定から、 Language & Frameworks ＞ Markdown を開いて
「Sync scroll in the editor and preview」のチェックを外す
チェックを外してもエディタをスクロールするとふわふわ動く気がするけど、チェックつけない時よりも改善されていい感じです。
以前のブログで100日かけてエリック・エヴァンスのドメイン駆動設計を完読しましたと書きましたが、それに続いて Clean Architecture も完読しました！
4/21から始まり、（家庭の都合で2日おやすみもありましたが）毎日１章ずつ、全34章を無事に完読しました 🙌
そして、今回もそれぞれの章で学んだことを毎日ノートにまとめてツイートしていきました。
Clean Architectureもかなり長い間積んでいた本だったので、やっと消費できてよかった…。
ツイートはこちらのモーメントにまとめています。
今回は他の方のツイートも一緒にモーメントに追加していきました。
モーメントは100個までしかツイートを登録できず、前回は私のツイートしか追加できなかったので、嬉しい。
ノートは私の理解で書いているので、何よりも原書を読んでいただくのが一番だと思います！
ただ、読書会での意見交換のように、他の人の解釈を参考にしたいときや、原書を読んでみる前にどんなことが書いているのさっくりと雰囲気を掴んでいただくとか、そういった感じで皆さんのお役に立てると嬉しいです！
タイトルの通り、Software Design 4月号（3/18発売）に、Gitの入門向け記事を寄稿しました！
寄稿したのは第二特集の「本質から学ぶGit」の１章を担当しました。
第２章は、一緒に「いちばんやさしいGit&GitHubの教本 第2版 人気講師が教えるバージョン管理&共有入門 (「いちばんやさしい教本」シリーズ)」を執筆したよこなさんが担当されています！
Software Designは若手の頃から読んでいた雑誌だったので、その雑誌に寄稿できるというのが嬉しくてたまりません。
このような貴重な機会をいただいて、ありがとうございました。
執筆期間は全体で１ヶ月程度が確保されており、余裕を持って作業ができました。
（「いちばんやさしいGit&GitHubの教本」の第二版の修正・加筆時期と執筆期間が結構被っていたのですが、期間が長く助かりました…！）
連絡や執筆記事のやりとりは、メールとGoogle Driveを使って文書を共有する方法を選びました。
slackやTwitterのDMなどの連絡手段に対応しているとのこと、また、ドキュメントのやりとりも柔軟にご対応いただけるとのことでした。
Google Driveの機能を使ってフィードバックコメントをいただけたので、リアルタイムに対応ができましたし、対応状況の管理もしやすかったです。
初めての寄稿ということでこまめに確認依頼をしてしまいましたが、担当者の方はそれに合わせて丁寧に原稿をチェック・フィードバックしていただき、不安を解消しながら進められました。
見出し案の調整→草稿の作成→レイアウト調整→著者校正という大まかな流れで進めていきました。
どんどん記事ができていく、という体験はワクワクしてとてもよかったです。
最後の最後までここはこうした方がわかりやすいかも！というお願いをしましたが、それも快くご対応いただきました。
技術評論社様とインプレス社様にご協力いただき、「いちばんやさしいGit&GitHubの教本」の第二版をSoftware Designの読者プレゼントとしてご提供いただくことができました！
Software Designで記事を読んでいただき、もっとGitの概念について丁寧に知りたい・他にもコマンドやGitHubの使い方を知りたいなどあれば、是非書籍も読んでいただけると嬉しいです。
応募方法はSoftware DesignのP16をご参照ください！
めちゃくちゃよかった。また機会があれば寄稿させていただきたい。
寄稿した、Software Designの見本誌届いた〜🙌🙌🙌
— 100日後にエヴァンス本を完読したしょぼちむ📖 (@syobochim) March 17, 2022
明日発売です！ pic.twitter.com/tFMpVJBRQ0
2018年に出版した「いちばんやさしいGit&GitHubの教本」ですが、昨日の2022/3/17に第二版を発売いたしました！
出版した当初から、概念が分かりやすいなど、SNSやレビューなどでご好評いただいており、晴れて第二版の出版となりました！
みなさま本当にありがとうございます！
タイトルに『いちばんやさしい』とあるとおり、初心者の方でもGitやGitHubを使えるようになることを意識して解説しています。
Gitは開発者の必須知識になりつつあるので、まだGitの使い方を知らない・なんとなく使っているけどよくわかってない、という方は是非読んでいただけると嬉しいです！
出版してから新しく追加されたコマンドやオプションを追加しました！
また、GitHubについてもUIの変更に追随したり、新しい機能にも触れています。
初版でわかりにくかった共同作業の進め方についても、説明を追加してわかりやすくなっています。
書籍の内容については、第一版を出版したときのブログを引用して以下に記載します！
本書の1番の特徴は、Gitの操作にコマンドラインを使っていることです。
コマンドラインを使うことで、ツールの操作ではなくGitの理解に集中できる＋時代の移り変わりに左右されず、身につけた知識をずっと使っていけます。
コマンドラインの操作は難しいように感じられるかもしれませんが、画面イメージをたくさん使いながら未経験者の方でもわかるように解説しています。
各レッスンの最初には、その操作にどういった意味や役割があるのかを解説しており、しっかりとバージョン管理の流れを理解しながら読み進められるかと思います。
バージョン管理に必要となる基本的なGitの操作方法を、順序立てて丁寧に解説しています。
Gitを使うとどんなメリットがあるのかから始まり、必要なツールのインストール方法やターミナルの開き方、基本的な操作コマンドなど初心者の方でもつまづかないような説明もありつつ、最終的にはGitでファイルをバージョン管理し、履歴を確認するところまで操作できるようになります。
チーム開発を想定して、実践的なワークフローを試しながらGitHubを使っていきます。
チーム開発で絶対に必要となるプルリクエストの作り方、つまずきがちなブランチについての説明や、実際にチーム開発をしている時に一番困るであろうコンフリクトの解決など、必須となる知識を網羅する内容になっています。
皆さま、是非本書をご活用いただければ幸いです！
11/25から3/4の100日間かけてエリック・エヴァンスのドメイン駆動設計を完読しました！
ソフトウェア開発の複雑さに立ち向かうための方法に「ドメイン駆動設計」があります。
エリック・エヴァンスのドメイン駆動設計（以降、エヴァンス本）は発売から20年・日本語訳発売から10年経っても読まれていて、ドメイン駆動設計の原著であり、多くのエンジニアが名著という一冊です。
その分厚さや内容が難しそうというイメージからずっと積んだままになっていている人も多いのではないでしょうか。
私もそんな一人で、ドメイン駆動設計をなんとなく知った風に過ごしていましたが、ドメイン駆動設計に関する勉強会への参加をきっかけにエヴァンス本と向き合い、知ったこと・学んだことを毎日1ページにまとめてツイートする活動を始めました。
100日間中にお正月や誕生日もあったのですが、夫の実家にもエヴァンス本を持っていき、無事に完読することが出来ました！理解ある家族でありがたいです。
100日間のツイートはこちらのモーメントにまとめています！
twitter.com
大規模災害が起こった時の災害対策パターン、基本的なことだけど名前も含めて忘れがちになるので備忘のためにまとめておきます。
災害が起こった時の対策を考える前に、まず理解しておかなければいけないのがRTO（Recovery Time Objective / 目標復旧時間）とRPO（Recovery Point Objective / 目標復旧時点）です。
このRTOとRPOがどのくらい許容できるかが、災害復旧のためのアーキテクチャを選ぶための大前提の要件になります。
災害復旧のための構成を充実しようとすればするほどコストがかかってくるので、このRTO / RPOとコストのバランスを考えて構成のパターンを選択していきます。
RTOは障害が発生してからシステムがまた利用できるまでにかかる目標時間のことです。
この時間が長くなればシステムが使えない時間が長くなり、逆に短くなると災害が起こってもすぐにサービスが利用できるようになります。
災害が発生してしまったときに、特にライフラインに関わるシステムはこのRTOの時間を短くするような設計が必要です。
逆にゲームなど「災害が起こった時は止まっても仕方がないよね」といえるサービスについては長くてもそこまで問題にはなりません。
RPOは復旧作業が発生したときにどの時点の状況に戻すかの目標時点を示したものです。
この時点が大きくなると障害によって失うデータが大きくなり、逆に小さくなると失うデータは少なくなります。
例えば、RPOを1日とすると最大24時間のデータが消え、5分とすると最大5分のデータが消える可能性があります。
これはデータの重要度や、データを失ったときに取れるオペレーションなどを考慮して検討するといいと思います。
例えば、紙の帳簿をインプットする社内システムは紙があれば数日前のデータでも復旧できますが、ECサイトの決済系のデータは損失が許されません。
RTOとRPOのイメージはこちら。
ここからが本題です。災害復旧のためのパターンを４つ書いていきます。
バックアップ＆リストア以外はRPOを高くすることができます。
また、下に行くほどコストはかかりますが、RTOを短くできます。
コストバランスと求められるRTO / RPOを考えてパターンを選んでいきましょう。システムの重要度が高くなるほど下のパターンを選ぶ必要が出てきます。
また、災害復旧という観点で考えると災害対策用のデータセンターの場所も重要です。
例えば東京のデータセンターが潰れてしまうほどの災害が発生したときにもシステムを止めたくない場合は、関西のデータセンターに災害対策用の環境を用意する必要があります。
さらには、関東・関西のデータセンターが潰れてしまうほどの災害が発生したときもシステムを止めたくない場合は、海外のデータセンターに災害対策用の環境を用意することを検討します。
では、それぞれのパターンについてもまとめていきます。
最初の構成パターンはバックアップ＆リストアです。
RTOとRPOが他のパターンよりも大きくなってしまいますが、一番コストを抑えられるパターンです。
災害が発生したときにデータの損失がある程度許容され、サービス停止も長時間許される場合はこのパターンが適切です。
システムを運用していく上でデータはとても大切です。ある程度のデータ損失は許容されても、データを全て失ってしまうとサービスの継続ができなくなってしまうので、最低限バックアップをしておきましょう。
そして、災害復旧のときにはバックアップをリストアしてデータを復元し、システムを構築し直します。
このパターンのRTOはバックアップしたデータをリストアして構成を作り直すので長くなります。
システムを１から構築する時間とバックアップをリストアする時間を想定してRTOを計算します。
また、人の手が必要な作業もあると思いますが、災害発生したときにオペレーターがすぐに対応できない可能性も考える必要があります。
このパターンのRPOはバックアップの頻度とそれをコピーまたはレプリケーションする頻度に依存します。
日次でのバックアップをしている場合は、最大24時間のデータ損失が発生します。
次の構成パターンはコールドスタンバイ / パイロットライトです。
バックアップ＆リストアよりもRTOをRPOを小さくすることができ、ウォームスタンバイやホットスタンバイよりもコストも抑えられるのがこのパターンです。
災害が発生したときにデータは無くなってはいけないけれど、サービスの停止はある程度許される場合はこのパターンが適切です。
災害対策用のデータセンターにデータを同期させるスタンバイ用のデータベースを用意します。
データベースのスペックはコスト削減のために低いものにする場合があります。
コスト削減のために、データベース以外のアーキテクチャ（アプリケーション層など）は構築しません。
災害が発生したら、スタンバイ用のデータベースをマスターにして、残りのサービスの構築します。
このパターンのRTOはデータベースの構築とデータのリストアが不要な分、バックアップ＆リストアよりも短くなります。
データベース以外の領域を構築し、サービスを再開できる時間を想定してRTOを計算します。
また、人の手が必要な作業もあると思いますが、災害発生したときにオペレーターがすぐに対応できない可能性も考える必要があります。
このパターンのRPOはデータを同期しているため短くなります。
最終のデータ同期タイミングまでのデータが災害対策用のデータセンターに残っているのでデータ損失が発生しにくくなります。
データを同期レプリケーションしているか非同期レプリケーションしているかでRTOが変わります。
次のパターンはウォームスタンバイです。
RPOはコールドスタンバイと変わらず、RTOをより短くでき、コストをホットスタンバイよりも抑えられます。しかし、災害が発生したときにサービスのスペックが低くなるのがこのパターンです。
災害が発生したときにデータは無くなってはならず、サービス停止も数分から数時間までなら許容できる、またはサービスのスペックの縮退が許容できる場合はこのパターンが適切です。
コールドスタンバイの構成に加えて、データベース以外のレイヤーもサービスを構築します。
しかし、コスト削減のためにサービスが動く最低限の構成・スペックで構築しておきます。停止しておく場合もあります。
災害発生時は、サービス停止しておいた場合は起動し、リクエストの向き先を切り替えることでサービスが縮退された状態での素早い復旧ができます。
復旧後にスケールアップ・スケールアウトを追って実施することで、段階的にサービスのスペックを通常稼働と同じ状態に合わせられます。
このパターンのRTOはシステムが構築できているためコールドスタンバイよりも短くなります。
サービスを構築後に停止している場合は起動とリクエストの切り替えにかかる時間を、停止していない場合はリクエストの切り替えにかかる時間を想定してRTOを計算します。
人の手が必要な作業もあると思いますが、構築が事前に済んでいる分、比較的自動化がしやすくなります。なるべくRTOを短くするために自動化を検討します。
このパターンのRPOはコールドスタンバイと同じです。
最後のパターンはホットスタンバイ / マルチサイトです。
RPOはコールドスタンバイと変わらず、RPOを最小にできますが、コストが最もかかります。災害が発生したときにも即時に本番環境と同等のスペックを得られるのがこのパターンです。
災害が発生したときにもデータ損失をせずに、短時間で業務復旧する必要がある場合はこのパターンが適切です。
通常の構成と同じ構成を災害対策のためのデータセンターにも構築し、リクエストの切り替えをするだけでサービス継続できる状態にします。
サービスのスペックの縮退もありません。
このパターンのRTOは最も短くなります。
災害用のデータセンターにリクエストを切り替えるためにかかる時間を想定してRTOを計算します。
リクエストの切り替えもなるべくRTOを短くするために自動化をしましょう。DNSの設定による切り替えができるので自動化もしやすくなります。
このパターンのRPOはコールドスタンバイと同じです。
備忘のため、災害復旧のための４つのパターンをまとめてみました。
OSSをテーマにしたイベントの OSS X Users Meetingに参加してきたので、その参加レポートです！
oss-x-users-meeting.connpass.com
プログラミング言語が誕生してからどういった経緯・歴史を経て現在利用されているプログラミング言語になっていったかというお話をされていました。
「今までコンピューターでできなかったことが出来るようになると、それが人工知能って呼ばれる」など、発表の中で面白い表現が使われていて楽しくお話を聴けました！
ソフトウェアはもともと自由なものだったのが、商品化されて制限が厳しくなってきた、そんな中で再び自由を手に入れるためにフリーソフトウェアの考え方と、著作権を守るライセンスという考えが整理されていった。
オープンソースはソースコードはコードが公開されているだけでなく、自由なライセンスをつける必要がある。
オープンソースの定義という10項目がある。
↑はメモが間に合わなかったので、こちらから引用しました。後で読む。
オープンソースの定義 (v1.9) 注釈付 – Open Source Group Japan – オープンソース・グループ・ジャパン
オープンソースの定義は素晴らしいが、開発者が生活出来るようにどうすればいいかをこれからは考えていかなければならないという課題がある。
オープンソースはここ20年で出てきた新しい世界で、オープンソースがないときに比べて遥かに良くなっている。
オープンソースをこれから守っていきつつ、貢献していきましょう。
私はC++を触ったことがないので、こういうライブラリがあるんだ〜・こういう状況なんだ〜と初見のお話が多かったです。
質疑応答のところであったGitHubスポンサー、知りませんでした。
開発者を経済的に支援できる仕組み。
GitHub スポンサーについて - GitHub Docs
資料はこちら
speakerdeck.com
C++はまだまだオープンソースになっていない部分もあるが、オープン化自体は進んでいる。
そして、オープン化することで議論も活発になり、言語の進化が大幅に加速している。
高速化することで大きなメリットはあるけれど、教育が追いつかなくなっている。
変わりやすい最新のライブラリの設計をどう共有していくのかというのも課題。
オープンソースだと情報共有なども含めてボランティアに頼っているので、インセンティブをどう持たせるか・それに合わせて責任をどう持ってもらうかを考えていくことが、長く開発を続けていただくために必要。
GitHubスポンサーという仕組みがうまくいき始めているところもあるようで、それがもっと発展していけば良いかも。
GitHub スポンサーについて - GitHub Docs
C++の仕事が無くなったと良く聞くようになった。それは、C++が活躍する場が変化したことが原因。
C++はGUIやゲームなど、高速化のためのバックエンドとして利用するという需要が増えてきていて、領域に特化して言語が選ばれることは健全な流れ。
C#のバックエンドやPythonのバックエンドにもC++が利用されている。
特定の言語に固執せず、複数の言語を学んで適材適所でプログラミング言語を選んでいくのが良い。
Pythonの概要から、どんな歴史で開発されてきたのか、どう運営されているかなどのお話がありました。
後半では言語のアップデートやこれからのPythonの未来のお話など、勉強になりました！
資料はこちら
slides.takanory.net
Pythonで便利なライブラリを見つけるときはこのサイトがオススメ：Awesome Python
Pythonの妥協のないコードフォーマッター：Black
他にも旬なプロジェクトがいくつか紹介されていました！
Pythonのコミュニティも豊富
Python3.10のアップデートでは「Better error messages」という更新も入り、初心者に優しくなった
これからの未来：Pythonの高速化が進んでいきそう
The “Shannon Plan” ：4年で5倍の高速化(1年で1.5倍)
GitHub - markshannon/faster-cpython: How to make CPython faster.
Javaは古い？堅い？ダサい？→No!! という走りだしから始まって楽しいプレゼンでした。
JavaはOSSと共に歩んできた言語。エンタープライズ系で使われることが多い言語でありながら、開発環境・ライブラリ・フレームワークなどにOSSプロダクトが盛んに使われていた
言語も現在はOSS化され、企業でも提供を開始している
IDEはIntelliJ IDEAが主流。
追加で調べてみたら、2020年でシェア72%らしいです。良い。→数字で見る 2020年における Java の現状 | The IntelliJ IDEA Blog
主流になったOSSのプロダクトがJavaの標準機能として取り込まれている。
そうやって企業・団体・エンジニアの貢献によって、JavaのOSSエコシステムは成熟していった。
しかし、その一方でJava界隈のOSSで起きた問題もいろいろあった。
Javaは Write Once, Run Anywhereというポリシーを守るため、JavaではないものをJavaと認めないという意思があった。（不要なJavaの分断を防ぐという意味では良い判断。）
JavaであるかどうかについてはTechnology Compatibility Kit (TCK) で互換性のチェックを通っているかで判断している。
以下については、そういった考えがある中で、Javaと認められないことよって起こった事件。
※現在はOpenJDKが唯一のOSS版Javaになっている。
今の主流は各社が提供するOpenJDKを利用することが主流。
各社によって少しずつ提供するツールは異なるが、コア機能については100%同じ。他の部分も99%は同じ。
Javaのように長い歴史と巨大なエコシステムを伴うものをOSS化していく上で相当な努力があった。
WebAssembly、聞いたことはあるけれど触ったことがなかったし概念もよく分かってなかったので、そもそもWebAssemblyってなに？ってところからお話いただいたのとてもありがたかったです。
Rust.Tokyo 2021： 9/18 開催
WebAssemblyは C / Rust / Assembly Script などをコンパイルしてブラウザで高速に動かせるようにしたもの
ブラウザの上でJavaScriptではないプログラム（C++など）を動かしたいというニーズはずっとあった。
VimをWebAssemblyで動かしてブラウザ上で動かしているというツールも既にある。
他にも、Webアプリでは Acrobat / Squoosh / Zoom / Autocad、サーバレス環境では Envoy / Istio など、利用例は広がっている。
WebAssemplyが利用されるにつれてニーズが分類できるようになってきた。それがエコシステムとパフォーマンス。
パフォーマンスについて、WebAssemblyはネイティブよりも1.2倍遅いと言われてはいるが、ブラウザで処理することでAPIでアクセスすることもなくなり、そのレイテンシがいらなくなるなど、純粋に比較することは難しい。
パフォーマンスはJavaScriptよりも安定していると言われている。常に同じようなパフォーマンスで動いてほしいというニーズに合っている。
現在はパフォーマンスよりもエコシステムについての期待が高い。
既にある資産をJavaScriptに書き直すのではなく、WebAssemblyを使うと少ないコストでブラウザ上で動かせるというメリットが大きい。
手に馴染んだ言語が使え、開発者体験をの向上が期待できる。（学習コストや既存資産の活用など）
WebAssemblyの利用事例：Shopify
Getting started
言語を選定する上で、Performance x Flexibility x Security を考える必要がある。WebAssemblyは以下の通りニーズを満たせる。
WebAssemblyはコンパイル・デコンパイルができるので、コンパイル後のもののコードが読めるというメリットもある。
Wasmファイルはコンパイルによって作られる関数定義のまとまり
WebAssemblyの辛いところ
全体を通して、OSS化によって言語の発展が活発になっているというポジティブさを感じました。
その一方で、ボランティアで成り立っている以上、開発者の生活をどう支えていくかについて課題を感じているという意見も複数あり、OSSの難しさもあるなぁと思いました。
セッション途中で紹介されたGitHubスポンサーがとても良い仕組みですね。
楽しかった〜！
![Software Design (ソフトウェアデザイン) 2022年04月号 [雑誌]](https://m.media-amazon.com/images/I/51lS2XfM6KL._SL500_.jpg "Software Design (ソフトウェアデザイン) 2022年04月号 [雑誌]")
