アウトライナーを使うと何でもアウトライナーにしたくなる - nakaoka3のなんでもブログ
アウトライナーにハマる 長い文章を書くときに目次のような全体の枠組みを決めておく。その枠組みのことをアウトラインという。アウトライナーというのはそれを作るためのツールで、これだけ聞くとわざわざツールを使うのは大げさに感じる。ところが実際にアウトライナーを触って使い方に慣れてくると、すっかりアウトライナーが気に入ってしまった。 きっかけはアウトライナー座談会 きっかけは「苦しみの執筆論 千葉雅也×山内朋樹×読書猿×瀬下翔太：アウトライナー座談会」というwebの記事だ。この記事で名前を聞いたことのある学者やブロガーの方が使っているのを知って興味を持った。 第1回「書くこと」はなぜ難しいのか？ - 苦しみの執筆論 千葉雅也×山内朋樹×読書猿×瀬下翔太：アウトライナー座談会 | ジセダイ 記事を読むだけだとアウトライナーの素晴らしさはそんなに理解できなかった。とりあえずWorkflowyと言う紹介
釣りのためなら引っ越しもする。より良い釣り場を求めて移動を続ける者のこれまで、そしてこれから｜KINTOマガジン
ITエンジニアとして働くshimobayashiさんは、釣りという趣味に出会ったことで移動の範囲が増え、より良い釣り環境を求めて京都から三浦半島へ引っ越しをするに至りました。引っ越し先でも原付（リトルカブ）を購入し、移動をして、釣りを続けています。その過程で考えたことや移動範囲の拡張について書いていただきました。 2014年から釣りを趣味としているshimobayashiといいます。普段はITエンジニアとして働き、週3日（土日＋平日1日）程度のペースで釣りを楽しんでいます。 僕は半ば“釣りのため”に、京都から神奈川県の三浦半島へ、2年ちょっと前に引っ越しをしました。それは、「釣りをしていれば人生は幸せなのか？」という問いについて検証するためのものでした。 今もなお、検証は続いていますが、釣りという趣味を持ったことで、あちこちへと出かけるようになり、果ては自分の生活ごと移動させてしまいました
テックブログ運営で大変だった話とプロダクト開発に繋がった話
こんにちは。kyです。 今日はちょっと昔話というか、お話をしようと思います。ですので気軽に聞いてもらえると嬉しいです。 ここでお伝えしたいことは「テックブログの運営で大変だった話」と「課題を解決するプロダクトを作っていった話」です。僕なりに気づいたこともお伝えします。 昔、テックブログを作ったときの意気込みと大変だったこと 前の会社でPyQというWebサービスを数人で立ち上げたのですが、成長するにつれて、もっとお客様にPyQを知っていただく必要がありました。 マーケターのnanaもチームにジョインし「ブログを通して有益な情報を公開して、それでサービスを知ってもらおう！」と決めました。SEOだけを考えた残念な記事を量産するのでなく、ちゃんと問題の解決や知見になる記事を書こう！ということを大切にしました。 テクノロジーに関したWebサービスだったので、テックブログとも言えるブログを作り始めまし
Terraform Modules を Monorepo で versioning して管理 - スタディサプリ Product Team Blog
こんにちは。 SRE の @suzuki-shunsuke です。 Terraform Modules を Monorepo で versioning して管理するようにした話を紹介します。 先日紹介したとおり、弊プロダクトではインフラを Terraform の Monorepo で管理しており、 CI は GitHub Actions + tfaction で実行しています。 blog.studysapuri.jp 弊プロダクトの Terraform Modules の管理手法は、この 2.5 年の間に 2 回ほど変化がありました。 Terraform Monorepo 内で管理し Local paths で Module を指定 Module を versioning するために Module ごとにリポジトリを作成し、 Terraform Monorepo とは別リポジトリで管理 M
チームトポロジーを用いたRettyプロダクト開発体制の解説 #ちいとぽ - Retty Tech Blog
マネージャーの常松です。 2021年12月1日にTeam Topologiesの翻訳 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 (愛称 #ちいとぽ) が発売になりましたが、皆さんもう読まれましたか? この書籍には事前レビューから参加させていただいていたのですが、「出版されたら自社の開発体制を図にして話せると良いな」とずっと考えていました。ただタイミングを逸してしまい・・・ようやく筆をとったのが本記事です。 チームトポロジーとは 描いてみた & 解説 基本はストリームアラインドチーム SREチームを立ち上げ中 トポロジー図を元に角谷さんと話したこと XaaSはセルフサービスを目指す スマホアプリとWebで開発順序の依存関係がたまにある 開発部門外とのコミュニケーションをどう扱うか ストリームアラインドチームに専門の役目を持たせるか オンコール対応をフローとして描い
自動テスト速度改善 - 自動テストが品質のボトルネックとならないために - freee Developers Hub
freee人事労務の品質改善を専任で活動している keik です。 freee人事労務ではアプリケーション開発の自動テスト環境として CircleCI を利用しています。すべてのコードの変更は GitHub 上の Pull Request を経由して行われますが、Pull Request のマージ条件の一つとして自動テストをパスすることを求めるようにしています。 つまり、どんな些細な変更であっても、急ぎの変更であっても、リリースするためには基本的には自動テストの結果を待つ必要があります。一方で、コードベースは日々成長しており、それに比例して自動テストの実行時間も長くなっています。 ここに、ゆっくりと、ジレンマが生じはじめます。 品質を高める目的の自動テストだが、実行時間が長いと品質のボトルネックになりうる。 具体的には以下のようなシナリオが考えられます。 些細な改善が億劫になる（自動テスト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Chrome Dev Summit 2014: Let's build some apps with Polymer!