タグ

ブックマーク / www.clear-code.com (24)

  • おすすめ.ssh/config設定 - 2023-04-03 - ククログ

    はじめに つい先日、GitHubのRSA SSHホスト鍵が突如差し替えられるという一件がありました。 We updated our RSA SSH host key 詳細に関しては識者による解説に委ねますが、ちょうどタイムリーな話題だったので、SSHをより安全に利用するという観点でおすすめ設定についていくつか紹介します。 なお、クリアコードではSSH以外にもおすすめzsh設定やおすすめEmacs設定という記事も公開しているので参考にしてみてください。 2023年5月11日更新:StrictHostKeyCheckingをyesにする場合の安全なknown_hostsの更新方法について追記しました。 おすすめ設定について クリアコードでは、.ssh/configのおすすめ設定を https://gitlab.com/clear-code/ssh.d にて公開しています。 これは、社内で.ss

    おすすめ.ssh/config設定 - 2023-04-03 - ククログ
  • 「雑に立てられるissue」で疲弊しないためにOSS開発者ができること - 2021-12-04 - ククログ

    要約:OSS開発プロジェクト運営者の側でとれる対策はいくつかあるよ。issueは基準を設けてどんどん閉じてしまおう。GitHubならActionsで自動化も簡単だよ。自動テストを整備するように、必要なコストだと思って割り切るといいよ。 結城です。 GitHub Actionsに関することならなんでもありらしいアドベントカレンダーとのことでしたので、ほんのちょっとかすっているだけではありますが、4日目にエントリーさせて頂きます。 「軽率に寄せられる報告や要望がOSS開発者を疲弊させる」という問題について語るOSS開発者は少なくないです。私の観測範囲内では最近も、イシュートラッカーにissueを立てようとすること自体に待ったをかける記事1や、「要望には初手で『なぜ自分で実装しない?』と訊ね、次に『継続的にメンテナンスしてくれるの?』と訊ねるドライな対応がおすすめ」という趣旨に受け取れる発言など

    「雑に立てられるissue」で疲弊しないためにOSS開発者ができること - 2021-12-04 - ククログ
    raimon49
    raimon49 2021/12/05
    具体案が並んでいてとても学びが多い。スコープを明示するの本当に大事だ。
  • Google ChromeのGUIから辿る、ドキュメント化されていない仕様の調査 - 2021-07-08 - ククログ

    先日、当社の法人向けFLOSSサポート業務の一環として、Google Chromeのドキュメント化されていない仕様について調査のご依頼を頂きました。 具体的には、インストール済みの拡張機能の自動更新について、 更新を停止する方法はあるかどうか。 自動更新処理はどの程度の間隔で実行される仕様か。 というお問い合わせでした。 記事では、これらのお問い合わせに回答するために何をどのように調査したかの紹介を通じて、詳細を把握していないOSSのソースコードの歩き方の例を示してみます。 まずはWeb検索 前者については、「Google Chrome extension update disable」といったキーワードでWeb検索を行ったところ、Chromiumのイシュートラッカー上にあった拡張機能のバージョンを固定できるようにして欲しいという要望が見つかり、そこに記載されている内容から、「現時点では

    Google ChromeのGUIから辿る、ドキュメント化されていない仕様の調査 - 2021-07-08 - ククログ
    raimon49
    raimon49 2021/08/01
    巨大コードベースを探索していく調査過程の言語化。
  • tDiaryからJekyllへの移行 - 2020-12-24 - ククログ

    このブログシステムを10年以上メンテナンスしている須藤です。 このブログシステムは2008年5月から運用しています。Rubyを使って実現したいと思って運用開始時からtDiaryを使って実現していました。tDiaryはWebアプリケーションとして動かすことを想定していますが、このサイトはできるだけ静的なHTMLとしてコンテンツを提供したかったのでtDiaryで管理しているコンテンツを静的なHTMLに変換するフリーソフトウェアを開発してそれを使っていました。このたび、そのtDiaryベースのブログシステムをJekyllを使ったシステムに移行しました。 この記事を書いているのはJekyllに移行してなにか問題が発生していないか気づいた人がいたら教えて欲しいからです。気づいた人は https://gitlab.com/clear-code/website/-/issues にissueを作るか、直

    tDiaryからJekyllへの移行 - 2020-12-24 - ククログ
  • OSSへフィードバックしてみたいけど、英語でどう書けばいいのか分からない - 2019-07-12 - ククログ

    結城です。 ここまで、OSSへのフィードバックをやってみようとした時に躓きがちなポイントについて、フィードバックするトピックの見つけ方、報告に盛り込むとよい内容、その情報の送り届け先の選び方の知見をそれぞれ述べてきました。 ところで、それらの技術的な内容以前のハードルとして、言語の壁という物もあります。実際にOSS Gateワークショップでも、フィードバック内容をまとめた後、英語でそれを書き直すという段階で手こずっておられる方がかなり多い印象があります。 ITエンジニア向けに「こういう英語表現を覚えよう」という情報を紹介する記事は時々見かけます。ですが、ワークショップでビギナー参加者の方が英語を書くのに苦労している様子を実際に見ている印象では、必要なのはそういった記事で紹介される「実際の現場でよく使われる単語や熟語の情報」ではなく、「実際の現場で英文を書く時に行われる考え方の解説」の方であ

    OSSへフィードバックしてみたいけど、英語でどう書けばいいのか分からない - 2019-07-12 - ククログ
  • OSSへのフィードバックはユーザーフォーラムとイシュートラッカーのどちらに書くべきか? - 2019-06-18 - ククログ

    ※注:この記事の対象読者は、「OSSを使用していてトラブルに遭遇しているか、改善の提案があり、その情報を開発元に伝えたいが、どこで伝えればよいかわからない」という人です。「どういう体裁で報告すればよいか分からない」「何を報告すればよいか分からない」という人向けの話はまた日を改めて書くつもりです。 結城です。 OSS Gateワークショップで、初めてフィードバックをしようとしているビギナー参加者のサポートをしていると、ビギナー参加者から以下のような質問を受ける事があります。 こんな簡単な・くだらないレベルの事を報告してもいいんでしょうか? ユーザーフォーラムとイシュートラッカー(バグトラッキングシステム)1のどちらに報告すればいいんでしょうか? どのプロジェクト(開発元)に報告すればいいんでしょうか? これらの点に対する筆者の回答は、端的には以下のようになります。 簡単でも些細でも何でも、あ

    OSSへのフィードバックはユーザーフォーラムとイシュートラッカーのどちらに書くべきか? - 2019-06-18 - ククログ
    raimon49
    raimon49 2019/06/30
    初めの一歩としてのIssue報告。いい記事。
  • Vimで単語を囲む方法をいくつか - 2018-04-23 - ククログ

    横山です。 社内から「Vimで単語をクォーテーション("..."など)で囲むのによい方法はないか」という質問をもらったので、調べたことをまとめました。 主に4つくらいのやり方がありそうだったので、順番に紹介します。 普通に入力 ciw 置換 プラグイン 普通に入力 普通にiでインサートモードに切り替えて入力する方法です。 ポイントは、単語単位で移動することと、ドットコマンドを活用することです。 bで単語の先頭に移動 "を入力 eで単語の末尾に移動 lで右側に移動 .(ドット)を入力(直前の編集操作が繰り返されて、"が入力される) 以下は、phw/peekとwavexx/screenkey(どちらもAPTでインストール可能)を使って取得したGIFアニメです。 ciw cから始まるコマンドを使うことで、文字列を削除(カット)しつつインサートモードに切り替えることができます。 削除対象範囲は以下

    Vimで単語を囲む方法をいくつか - 2018-04-23 - ククログ
    raimon49
    raimon49 2018/05/06
    テキストオブジェクトをキーマップしちゃう方法もあるか。なるほど。
  • PostgreSQLで日本語全文検索 - LIKEとpg_bigmとPGroonga - 2015-05-25 - ククログ

    PostgreSQLアンカンファレンス@東京(2015/5/30)でPostgreSQLの日語全文検索まわりについて紹介しようかとたくらんでいます。しかし、現時点(2015-05-25)でキャンセル待ちで、当日参加できないかもしれないので紹介しようと用意している内容をここにまとめます。 内容 この資料の目的は、PostgreSQLで使える次の3つの方法の特性を紹介し、ユーザーが適切な方法を選択するための材料を提供することです。 LIKE pg_bigm PGroonga(ぴーじーるんが) LIKE LIKEのメリット・デメリットは次の通りです。 メリット 標準で使える インデックス作成不要(= データ更新が遅くならない) データが少なければ十分速い デメリット データ量に比例して遅くなる ユーザーがLIKEを使うかどうかの判断基準は「十分速いかどうか」(= 「データが少ないかどうか」)で

    PostgreSQLで日本語全文検索 - LIKEとpg_bigmとPGroonga - 2015-05-25 - ククログ
    raimon49
    raimon49 2015/06/07
    業務用アプリケーション程度なら、LIKEで十分に実用に足りる。
  • クリアなコードの作り方: 正規表現はマッチしすぎに気をつける - 2015-03-25 - ククログ

    正規表現は短い表現でたくさんのパターンを記述できるため適切に使えばとても便利な機能です。しかし、雑に正規表現を使ってしまうと思わぬバグになったり、わかりにくいプログラムになってしまいます。「動く」正規表現は書けるけど、「適切な」正規表現はまだ書けない、という初級者向けの話です。 例: 拡張子を変更する 正規表現を使って実現することが多い処理として「拡張子を変更する」という処理があります。次のような処理です。

    クリアなコードの作り方: 正規表現はマッチしすぎに気をつける - 2015-03-25 - ククログ
    raimon49
    raimon49 2015/03/28
    マッチしすぎる正規表現を防ぐ
  • Rubyのテスティングフレームワークの歴史(2014年版) - 2014-11-06 - ククログ

    2014年12月にRuby 2.2がリリースされる予定です1。 Ruby 2.2にはRuby 1.9.1のときに外されたtest-unitというテスティングフレームワークが再びバンドルされる予定です。Rubyのテスティングフレームワーク周りに詳しくない人にはよくわからない状況でしょう。そこで、Rubyのテスティングフレームワークの歴史を説明することで状況を整理します。 名称の整理 この説明の中ではたくさんのテスティングフレームワークが登場します。似たようなものもあるため、最初にテスティングフレームワークの名称を整理します。この説明の中で登場する名称は次の通りです。 RubyUnit Lapidary rubyunit Test::Unit test/unit test-unit miniunit minitest RSpec 違いがわかりますか?ざっくり説明すると次の通りです。 RubyU

    Rubyのテスティングフレームワークの歴史(2014年版) - 2014-11-06 - ククログ
    raimon49
    raimon49 2014/11/08
    闇だ Ruby本体開発チームだけが使うテスティングフレームワークtest/unitが存在するのか……
  • いろいろ考えると日本語の全文検索もMySQLがいいね! #osc2014tk - 2014-10-24 - ククログ

    関連リンク: スライド(Rabbit Slide Show) スライド(SlideShare) スライド(Speaker Deck) リポジトリー(スライドのソースだけでなく、スライドの中で示しているベンチマークを実行するスクリプトなども置いてあります。) 内容 今回の発表は「すでにMySQLを使っていて」、「全文検索についてよく知らない」けど、「日語の全文検索を実現したい」という人向けの内容になっています。そのため、トークナイザーや転置索引といった話はあえて外しました。 MySQLを使うと、そのような詳細を知らなくてもそこそこの機能の日語の全文検索を実現できる、ということを伝えました。 データ量が少ない場合は適切なcollationを設定すればLIKEでも十分な機能と性能が得られて、運用の手間も増えません。LIKEで十分なら無理して専用の全文検索サーバーは必要ありません。 データ量が

    いろいろ考えると日本語の全文検索もMySQLがいいね! #osc2014tk - 2014-10-24 - ククログ
    raimon49
    raimon49 2014/10/24
    Groonga改めMroonga、トランザクション非サポートのためマスターをInnoDBでスレーブをMroongaにする工夫など 良いっていう導入事例を聞くことが増えて来た
  • GitHubのWikiが変更されたら差分付きで通知する方法 - 2014-04-09 - ククログ

    一人でWikiを使っている場合はそんなことはありませんが、複数人でWikiを使っている場合はだれかがWikiを変更したらそれを知りたいものです。複数人でWikiを使っている場合は、情報共有のために使うことが多いです。Wikiが変更されたことがわかると、最新の情報を入手することが容易になるため、情報共有という目的を達成しやすくなります。 最新の情報の入手のしやすさという点では「どのように」変更がわかるかが重要です。例えば、次のような変更の知り方があります。下にいくほど最新の情報を入手するための手間が減るので最新の情報を入手しやすくなります。 定期的にWikiの注目しているページをブラウザーで開き、変更がないか確認する。注目しているページが複数ある場合は繰り返し確認する。 定期的にWikiをブラウザーで開き、「最近更新されたページリスト」を確認する。更新されたページのうち、前回確認したときより

    GitHubのWikiが変更されたら差分付きで通知する方法 - 2014-04-09 - ククログ
    raimon49
    raimon49 2014/04/10
    git-utils、tDiaryプロジェクトでも使っているらしい。
  • Autotools事始め - 2013-09-12 - ククログ

    はじめに クリアコードが関わるプロジェクトの多くでは、ビルドシステムとしてAutotoolsを使用しています。そのため、新しくプロジェクトに参加した開発者にもAutotoolsに関わる修正を担当してもらうことがあります。しかし、個々の開発者のバックグラウンドは様々であり、必ずしもすべての開発者がAutotoolsに関する知識を持っているわけではありません。その上、プログラミング言語などの基礎的な知識とは異なり、学校の授業や企業の研修などでAutotoolsについて学ぶことができる機会は稀であり、まとまった解説書も少ないなどといった事情があるため、その使い方を伝授するのには毎度手間を要しているというのが実状です。 そこで、これから数回に分けてAutotoolsの使い方を解説していくことを予定しています。 Autotoolsとは Autotoolsとは、autoconf、automake、li

    Autotools事始め - 2013-09-12 - ククログ
    raimon49
    raimon49 2013/09/26
    makeターゲットの紹介。
  • デバッグしやすいassert_equalの書き方 - 2011-02-28 - ククログ

    デバッグしやすいassert_equalの書き方とデバッグしにくいassert_equalの書き方があるのは知っていますか?1 デバッグしやすいassert_equalの書き方を2パターン紹介します。 まとめたassert_equal まず、1つ目のよくみるデバッグしにくいassert_equalの書き方です。 def test_parse assert_equal(29, parse_integer("29")) # (1) assert_equal(29, parse_integer("+29")) # (2) assert_equal(-29, parse_integer("-29")) # (3) end これがデバッグしにくいのは、(1)が失敗したら(2)、(3)が実行されないからです。すべてのassert_equalが実行されて、どのassert_equalが失敗したかを確認す

    デバッグしやすいassert_equalの書き方 - 2011-02-28 - ククログ
    raimon49
    raimon49 2013/07/12
    まとめる、まとめないを意識
  • RubyKaigi 2013の予告:ステッカー・チラシの配布とRubyHirobaでの企画案と発表内容 #rubykaigi - 2013-05-28 - ククログ

    株式会社クリアコード > ククログ > RubyKaigi 2013の予告:ステッカー・チラシの配布とRubyHirobaでの企画案と発表内容 #rubykaigi 早いもので今週後半(2013/5/30-6/1)はRubyKaigi 2013です。クリアコードはシルバースポンサーとしてRubyKaigi 2013を応援しています。 今回はRubyKaigi 2013に関連した以下の情報をお伝えします。 rroongaステッカーの配布 チラシの配布 RubyHiroba 2013でやりたいこと 6/1 13:30からの発表「Be a library developer!」の内容 rroongaステッカーの配布 RubyKaigi 2013ではスポンサーがノベルティを配布する場所を用意してくれるそうです。ちょうどrroongaのステッカーがあるのでそれを配布する予定です。以下のデザインです。

    RubyKaigi 2013の予告:ステッカー・チラシの配布とRubyHirobaでの企画案と発表内容 #rubykaigi - 2013-05-28 - ククログ
  • GDBでデバッグするなら-g3オプション - 2013-05-08 - ククログ

    RubyPythonなどのスクリプト言語では実行中に例外が発生するとバックトレースを出力してくれます。バックトレースがあるとどこで問題が発生したかがわかるためデバッグに便利です。一方、CやC++では不正なメモリアクセスをすると、バックトレースではなくcoreを残して1終了します2。デバッガーでcoreを解析するとバックトレースを確認できます。 このように、CやC++でデバッグするときにデバッガーはなくてはならない存在です。スクリプト言語にもデバッガーはありますが、デバッガーを使わなくてもデバッグできる範囲が広いため、CやC++をデバッグするときのほうがデバッガーのありがたさがわかります。 この記事では、広く使われているデバッガーであるGDBをもっと便利に使うためのGCCのコンパイルオプション-g3を紹介します。 サンプルプログラム まず、この記事で使うサンプルプログラムを示します。マクロ

    GDBでデバッグするなら-g3オプション - 2013-05-08 - ククログ
  • わかりやすいコミットメッセージの書き方 - 2013-04-24 - ククログ

    もう1年以上前になりますが、コミットメッセージの書き方を説明しました。ざっくりまとめると、以下のことを説明しています。 わかりやすいコミットメッセージがいかに大切か どのようなコミットメッセージがわかりやすいか(具体例付き) この説明をしてからも、日々コミットしていくなかで新たに得られた「どうすればもっとわかりやすいコミットメッセージになるか」という知見が増えていました。これは、コミットへのコメントサービスの提供を開始した1ことも影響しています。このサービスでは、コミットへコメントするときに「どうして自分は他の書き方よりもこの書き方をわかりやすいと感じるか」を説明しています。その過程で「なんとなくこっちの方がよさそう」だったものを「具体的にこういうときにこう感じるのでこっちの方がよさそう」と何かしら理由を考えるようになりました。これにより、今までそれぞれの開発者でなんとなくだった考えが共有

    わかりやすいコミットメッセージの書き方 - 2013-04-24 - ククログ
    raimon49
    raimon49 2013/04/29
    git revertはそのまま定型のメッセージを使ってしまっていたので反省。typoの情報を「^」で残しておくテクニックを盗みたい。
  • シェルスクリプトで「ビルドスクリプト」を作る時に便利なテクニック - ククログ(2012-10-11)

    プログラムの種類によっては、そのまま実行できるものと、実行できるようにするために「ビルド」が必要なものとがあります。Cなどのコンパイルが必要な言語で書かれたプログラムは当然ビルドが必要ですし、コンパイルが不要な言語であっても、インストーラパッケージを作るというビルド作業が必要な場合はあります。 ビルド作業の自動化のためのツールとしてmakeなどがありますが、そこまで格的な事をやる必要がない場合は、シェルスクリプトで「ビルドスクリプト」を作るのが手軽でおすすめです。この記事では、そのような場合に役立つシェルスクリプトのテクニックを4つご紹介します。 エラーの気付きやすさとデバッグのしやすさを高める メッセージに色を付ける シェル関数をライブラリにする 一時的に作業ディレクトリの中に入る エラーの気付きやすさとデバッグのしやすさを高める はじめに紹介するテクニックは問題が発生した時に気づきや

    シェルスクリプトで「ビルドスクリプト」を作る時に便利なテクニック - ククログ(2012-10-11)
    raimon49
    raimon49 2012/10/12
    set -e -xと同様の情報を局所的に得られるよう"$@"や$?と組み合わせた関数と、echo -eでエスケープシーケンス出力してエラーを知らせる例。cdは処理ごとに括弧でひとまとめに。
  • リーダブルコードの解説 - 2012-06-11 - ククログ

    注: 記事中の「解説」の部分のライセンスは「Creative Commons 表示 - 非営利 - 継承」です。「解説」は「クリアコード」(「ClearCode Inc.」)によって変更されています。変更前の原著作者は「オライリー・ジャパン」です。「Creative Commons 表示 - 非営利 - 継承」なので再配布や変更や翻訳などはライセンスに従って自由に行えますが、営利目的で利用することはできません。 https://amazon.co.jp/dp/B0064CZ1XEの翻訳である「リーダブルコード」が今月(2012年6月23日)発売されます。すでに予約できるようです。 https://amazon.co.jp/dp/4873115655 書の内容は原書の紹介記事を参照してください。 日語版の訳者は角さんです。これまでの訳書と同様にとても読みやすく訳されています。翻訳なので読

    リーダブルコードの解説 - 2012-06-11 - ククログ
    raimon49
    raimon49 2012/07/13
    良い書評。最近買ったので読み終わったら、もう一度この記事も読みたい。
  • デバッグしやすいHTMLのテストの書き方 - 2012-01-18 - ククログ

    注意: 長いです。 一言まとめ: withinとtest-unit-capybaraを使ってHTMLのテストを書くと問題を見つけやすくなる。あわせて読みたい: デバッグしやすいassert_equalの書き方 HTMLに対するテストに限らず、開発を進めていく中でテストが失敗する状況になることは日常的にあることです。HTMLの場合は、入力フォームのラベルを変更したり、項目を追加したら既存のテストが失敗するようになるでしょう。そのとき、どのようにテストを書いていれば原因を素早く見つけられるのかを説明します。ポイントは「注目しているノードを明示すること」です。 HTMLテストのライブラリ さて、Rubyで処理結果のHTMLをテストするときにはどんなライブラリを使っていますか?The Ruby ToolboxにあるBrowser testingカテゴリを見てみると、Capybaraが最も使われてい

    デバッグしやすいHTMLのテストの書き方 - 2012-01-18 - ククログ
    raimon49
    raimon49 2012/06/04
    テストコードのメンテナンスビリティ