なぜsystemdなのか？ | POSTD
このブログ記事は2014年5月21日に行った私の講演の内容に基づいています。 ここ数年、GNU/LinuxのディストリビューションはSysV initを避ける傾向にあり、代わりに多種多様な新しいinitシステムへと移行が進んでいます。SysV initに満足しているユーザにとっては、これは予想外の流れでしょう。問題なく使えるのに、なぜ多くのディストリビューションはSysV initに背を向けているのでしょうか。 この記事ではSysV initの問題点と、それに対してsystemdがどんな解決法を提供しているのか説明してみようと思います。 私は特にsystemdの大ファンだというわけではなく、ただ広く使われているツールだという認識以上の思い入れは無いことだけお断りしておきます。 initシステムの役割とは何か？ コンピュータが起動する時には、ビルトインされたファームウェア（コンピュータの場合
パイプとフィルタ ~ソフトウェア工学における有用なアーキテクチャ~ | POSTD
パイプライン は、最近のソフトウェアエンジニアリングにおいて、非常に便利な（そして驚くほど活用されていない）アーキテクチャパターンです。ソフトウェアでデータの流れを制御するためにパイプとフィルタを用いる考え方は、最初のUNIXシェルが作られた1970年代からあります。もしターミナルエミュレータでパイプ” | ”を使ったことがあるなら、”パイプとフィルタ”を活用できていることになります。以下の例を見てみましょう。 cat /usr/share/dict/words | # Read in the system's dictionary. grep purple | # Find words containing 'purple' awk '{print length($1), $1}' | # Count the letters in each word sort -n | # Sort l
マイクロサービス – 分散された大きな泥だんご | POSTD
モノリシックがダメだからといって、マイクロサービスが解決策になるわけではない ソフトウェア開発業界は流行に左右されやすいという証拠に、今マイクロサービスが、いたるところで大騒ぎされています。”次の大ブーム”だと思う人もいるでしょう。また、（10年前に”上出来”と見なされたような）大型のSOA、サービス指向アーキテクチャが単に軽量化して進化したものだと捉える人もいるでしょう。私は現在のマイクロサービスアーキテクチャに関しては好意的に見ています。しかし、だからといってこのアーキテクチャは決して万能薬ではありません。言うまでもないことかもしれませんが、多くの人が間違った理由でマイクロサービスに飛び付いているように思えるのです。 これは私の講演でよくお見せするスライドで、 以前ブログにも書きましたた が、ソフトウェアシステムを開発するにはいろいろな方法があります。まず、昔ながらのモノリシック（一枚
GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
テスト駆動開発（TDD）はもう終わっているのか？ Part 2 | POSTD
前編はこちらです 4：テストに伴うコスト 2014年5月27日 audio 今回のテーマは、テストとTDDのマイナス面です。 テストをやりすぎることがあるか、そして機能的なコードよりテストを重視するチームには問題があるかという点について議論しました。 議事録 Davidが会話の口火を切りました。 「トレードオフについて話すなら、当然そのマイナス面について理解しなければならない。なぜなら、欠点のないトレードオフは存在しないからだ」 このあと彼は続けて、TDDは開発者に何かを強制するわけではないが、ある一定の方向に導くことは確かだと言いました。 それから、最初の問題点として、テストの過剰な実施を取り上げました。 TDDでよく言われるのは、テストに失敗せずして1行のコードも書くべきでないということです。 Davidも当初はこの考え方を合理的だと思っていましたが、そのうち、テストをやり過ぎる傾向が
テスト駆動開発（TDD）はもう終わっているのか？ Part 1 | POSTD
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
Rubyにはウンザリ！動的型付け、副作用、およびオブジェクト指向プログラミング全般からの考察 | POSTD
この記事を書き上げるには、相当長い時間がかかりました。本来は今年の年明け、 Rubyの死 やデイヴィッド・ハイネマイヤー・ハンソンの TDDは死んだ がアップされて騒ぎになる前に投稿するつもりだったのです。昨年末に書いたツイートを見てください。 > Rubyにはもう飽き飽きした。理由はいろいろあるが、特にその副作用と、ステータスが可変なせいで大量のユニットテストを書かされるのにはウンザリだ。 @abevoelker Rubyの開発に関しては、大勢の人が心のどこかで何かおかしい、何かが欠けていると思っているようですが、たいていの人は責める対象を間違っています。Rubyで書いたアプリがとんでもない代物になったって？ それはあなたがきちんとテストコードを書かなかったか、テスト駆動開発（TDD）の指針に則って開発しなかったからです。もしくは、正しいデザインパターンに切り分けるための知識が不足してい
Go言語がダメな理由 | POSTD
私はGo言語が気に入っていますし、多くの場面で使用します。現にこのブログもGoで書いています。Goは便利な言語ですが、優れた言語とは言えません。つまり、悪くはないけれど、十分ではないということです。 満足できない言語を使用する際は注意が必要です。注意を怠ると、その言語を次の20年間使い続ける羽目になるかもしれないからです。 私のGoに対する主な不満を本文にまとめました。既に何度も指摘されていることも含まれていますが、中にはこれまでほとんど話題になっていない指摘もあります。 これから列挙する全ての課題には既に解決策があることを示すため、私が優良な言語と考えるRustやHaskellと比較して説明します。 汎用プログラミング 課題 誰でもさまざまな事柄に幅広く対応できるコードを記述したいと考えます。例えば数のリストの合計を求めるために定義した関数が、小数、整数、またその他の合計を求められるもの
GitHubでの”Merge pull request”の弊害 | POSTD
私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション （寄与貢献）を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
最高のプログラミング言語（または私は如何にして心配するのを止めてコードを愛するようになったか） | POSTD
常に世界のどこかで誰かが、この世で一番のプログラミング言語は何かというトピックで投稿し、忘れ去られた言語のすばらしい一面や、新しい言語の有用性を主張しています。どうやら、その順番が私に回ってきたのかもしれません。そろそろ私も、プログラミング言語についての自分の考えを皆さんにお伝えしようと思います。 始めに少し言い訳をさせてください。30以上の言語で開発した経験があり、他の人が書いた多くのコードと悪戦苦闘をしてきた開発者でもない限り、「自分の意見には客観性がある」とはとても言えないと思います。そんなわけで、このトピックを取り上げる他の多くの人と同じように、私の意見も偏っています。多くの言語に精通した開発者がこの話題自体を不毛だと感じるのは、このせいかもしれませんね。 要約: すばらしい言語 早速、このブログ限定ということで、私が考える”すばらしい言語”を発表しましょう。 アセンブリ言語： マ
ある中級プログラマの告白 | POSTD
私は中級レベルのプログラマです。 基本を理解するのは得意です。過去の失敗をきちんと分析できるくらい経験を重ねていますし、もっと知るべきことは山ほどあることも分かっています。 特筆すべきは、自分で身につけるべきことを知ったうえで、それを吸収しようと積極的かつ精力的に取り組んでいる点でしょう。 プログラマとしての能力は平均的なものに過ぎないと、心から納得するまで時間がかかりました。今では、よく理解できないままに誰かの意見を受け売りする必要など感じていません。知らないことがあっても、それを他人に悟られるのは怖くありません。 でも以前は違いました。信じられないかもしれませんが、私はかつてプログラミングの達人だったのです。 自分の能力を誤って評価していたのは、比較的孤独な環境でスキルを学んだためでしょう。当時はコンピュータを持っていることさえ、ちょっと特別なことでした。使い方を知っているとなれば、な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
