「失敗しても何を残せるか」から逆算して選ぶ - Sexually Knowing
何かをやる上で失敗しないに越したことはないですし、そのリスクはあらかじめ減らせたり排除できると良いのはもちろんですが、どうしたってゼロにはできません。 それが新規事業のような不確実性の高い領域であればなおさらで、正解の見えない世界での判断は少なからず博打の性質を孕むことになります。 ソフトウェアエンジニアとしてそういった場面で判断をする時に、合理性で選択肢を減らしていった後で残った選択肢を選ぶ時の決め手として、自分は「失敗しても何を残せるか」という観点を持ち出します。 正解のない世界で自分を鼓舞するためのある種のまじないのようなものですが、これについて掘り下げてみます。 プレモーテムとは 終わりを意識して始める: プロジェクトのプレモーテムを行う方法 [2022] • Asana プレモーテム (premortem) とはプロジェクトの終了をまず予想し、そこから逆算してリスク要因を見つけた
jsondiff: JSONの構造の一部を無視して差分をとれるGoのライブラリを書いた - Sexually Knowing
github.com 背景 仕事でお世話になっているkayac/ecspressoの機能の中にローカルのタスク・サービス定義と現在使われている定義を比較して差分を出力してくれるものがある。 github.com これから加えようとしている差分をプレビューできるだけではなく、たとえばデプロイしようとしているわけでもないのに差分があればローカルの定義が古びていることがわかるのでCIに組み込めると便利。 しかし実際に使おうとすると困る点が見つかった。 たとえばタスク定義にイメージタグを書く際に {{ must_env 'IMAGE_TAG' }} のように環境変数を参照している時に「イメージタグ 以外 に差分がない」ことを確認するのが難しいということ。 理想的には image を無視したJSONの構造を比較して差分が出せると良い。あるいは出力されるdiffをパースして image の差分は無視す
生きているのならシェルスクリプトにだってなってみせる、そうPerlならね - Sexually Knowing
シェルスクリプトを書くのをやめる - blog.8-p.info これを見て: 夢の可能性が高くなってきたんですが、Perlのプラグマかなにかで、シェルスクリプトと混在できる……というか、存在しないサブルーチン呼び出しを外部コマンド呼び出しにするやつありませんでしたっけ— aereal / 青木華絵 (@aereal) 2021年9月16日 まじだ... https://t.co/IF6SyBR4o8— Kazuyoshi Kato (@kzys) 2021年9月16日 Shell - run shell commands transparently within perl - metacpan.org use Shell qw(cat ps cp); $passwd = cat('</etc/passwd'); @pslines = ps('-ww'), cp("/etc/passwd"
ひどい目に遭いそうなところからテストを書く - Sexually Knowing
blog.sushi.money 僕も最近は正常系から書くことが多いです。こうすると悪い設計に早く気付きやすいという利点があると感じています。 ここでは単体テストのような開発者向けのテストを想定していて、E2Eテストのようなテストでは必ずしも当てはまらないでしょう。 最初にテストを書く時には何も準備がない状態から始まりますが、その時にとても素朴な異常系から始まると整える事前条件が少なく済んで簡単に書けた、という体験になると思います。 そこからインクリメンタルに事前条件を積み重ねて、複雑なメソッドの動作を確かめていきますが、その場合の開発体験はコピペしつつちょっとずつ整えていくという風になり、都度の負担はそれほど高くならないでしょう。 一方、最初に正常系から書く場合、あらゆる事前条件を把握し、それを整えるコードを書く必要があります。 理想的に実装されたメソッドは、どちらの進め方であっても体験
やたらと短いエイリアスは使わない - Sexually Knowing
Gitもシェル (zsh) もよく使うコマンドをエイリアスとして設定して任意の入力で呼び出すことができる。 このエイリアスについていくつか派閥があると感じていて、おおまかには: エイリアスをまったく使わない 入力の手間を減らすため極限まで短いエイリアスを使う よく使うコマンド・オプションの組み合わせに説明的な名前をつける ……という派閥に分類できると思う。 自分は3つめの「よく使うコマンド・オプションの組み合わせに説明的な名前をつける」に属する。 短いエイリアスへの苦手意識 衝突しないようエイリアスを管理するのがだるい エイリアスは名前空間を通常のコマンドと共有しているので、それらと衝突しないよう管理しなければいけない。 短い名前を設定しても思い出せない よく使うコマンドなら手癖で打てるだろうけれど、ごくたまにしか使わないコマンドのごく短いエイリアスを思い出せる気がしない。 これはエイリア
各チームの大小様々なやっていることを共有する会をやったら予想外に盛り上がった話 - Sexually Knowing
前職で掲題のような取り組みを提案して始めてみたら予想以上に盛り上がったので書いておく。かなり低コストに始められるので以下に書くような課題感を持つところではおすすめできると思う。 どんな会か 会の名前は「今月のホットトピックス」と銘打った。 前職では毎週木曜日に社内勉強会が開催されており、月始めの枠の一部を借りて30分程度から始めた。 refs. 寿司と勉強会とエンジニア - Hatena Developer Blog 最近チームでやったことの書き出し 聞いてくれ・聞きたいの投票 司会による紹介 ……からなる。 まず書き出しは、ナレッジツール (Scrapbox) におもむろに「2020/8 ホットトピックス」というページを作り、各チームやその他有志といった見出しを置いておく。 このライブラリをアップデートしたとか、バグ報告をしたとか、大小いろいろな情報を書いてくれる。 並行して、ページに箇
人間が関わりあう時間の価値を最大化するためのオートメーション - Sexually Knowing
コードを書かない問題解決 ソフトウェアエンジニアとしての価値観とか仕草みたいなのはだいぶid:hitode909さんの影響を受けており、その中でも自分が大きく変わったと思うのは、問題解決の手段としてソフトウェアにこだわりすぎないという視点を手に入れたこと。 自分は本来的にはコードを書くのが大好き人間というかyak shaving大好き人間なので、コードを書きはじめて実現に至るまでのすべての寄り道を楽しいと思う性質だけど、一方、チームや組織という文脈でそれが常に正しくて価値が最大かというとそうではない。 ……ということに気が付かされたのはひとでさんと仕事していて自分がソフトウェアを作るという方法にこだわって悩んでいると「とりあえずスプレッドシートで運用してみませんか」とか提案してもらえることがあり、最初はえーコード書きたいよと思っていたものの実際にやってみるとそれくらいで事足りる頻度の作業だ
SNSで同僚をフォローするのをやめた - Sexually Knowing
SNSというかTwitterで同僚をフォローするのをやめて精神衛生が良くなった。 一緒に仕事をするうえでパーソナリティも知りたいなと思って基本的にフォローしていたのだけれど、最近それによって楽しいとか便利と思うことより、きついと感じる機会のほうが多くなったのでやめた。 『エンジニアのためのマネジメントキャリアパス』を読んだ そもそものきっかけは、チームでテックリードというエンジニアのリーダー的な役割を拝命したからだった。 チームを良くするためにという思いもあって、チームのエンジニアのそれも職能のうちの一部に限定して基礎的なマネジメントに手をつけはじめた。 会社にはシニアエンジニアによるメンタリング制度がありそちらはチーム 外 のエンジニアがメンターを務めることになっている。その制度とは別にテックリードとしてチームメンバーのキャリアプランなどを鑑みて、チームと個人がお互いにハッピーになるには
Vim で現在カーソルがあるテストメソッドを実行する - Sexually Knowing
Perl には Test::Class という JUnit 風にテストを書けるモジュールがある。すなわち: テスト用のクラスを定義し アサーションをインスタンスメソッドとして括り出す ことができる。 Test::Class はテスト実行時に環境変数 TEST_METHOD に与えられた値で実行するテストメソッドをフィルタリングすることができる。 Sometimes you just want to run a single test. Commenting out other tests or writing code to skip them can be a hassle, so you can specify the TEST_METHOD environment variable. The value is expected to be a valid regular expres
DataMapperの今後、最近watchしているプロジェクト - Sexually Knowing
ernie/squeel - GitHub Sequelと紛らわしい名前のSqueelは、ActiveRecord (Arel) を拡張して、よりベタ書きのSQLを減らそう、という試み。 Arelは "=", "IN", "BETWEEN" まではいいように抽象化しているけど、たとえば "LIKE" や ">=" といった演算はSQLをベタ書きしてプレースホルダを使わないといけなくなる。これは非常にイケていないな、と思っていたのだけど、やっぱりそう感じる人が他にもいたみたい。 Symbol#>= とかを定義したり、whereがブロックをとれるようになったりして、SQLのベタ書きがほとんど抑えられている。 solnic/virtus - GitHub 次期DataMapperで使われる予定の汎用的なProperty APIライブラリ。型やデフォルト値などを持つプロパティをPORO (Plai
padrino-gen の --tiny オプションによる構成の違い - Sexually Knowing
$ padrino g project sample --tiny $ mv sample sample.tiny $ padrino g project sample この状態で diff -r sample.tiny/ sample/ した結果: Only in sample/app: controllers Only in sample.tiny/app: controllers.rb Only in sample/app: helpers Only in sample.tiny/app: helpers.rb Only in sample.tiny/app: mailers.rb Only in sample/app: views diff -r sample.tiny/config/apps.rb sample/config/apps.rb 30c30 < set :sessio
関西闇RubyKaigi (#kyami) でPadrino::Validation::HTML5についてLTしました - Sexually Knowing
Padrino::Validation::HTML5 // Speaker Deck Padrinoについてなにも語らずいきなり未知のフレームワークのプラグインについてLTするという闇のハードコアトークでした。 けっこうな数の参加者が集まっていたので、とりあえず名前 (Padrino) だけでも覚えてもらえたらいいかな、くらいの勢いでぶっぱなしてきました。5分にまとまるか不安だったけどほぼジャストでした。ほかにも: Growlを切って発表中に通知が出る、というマヌケな事態を防げた iPod touchのRemote Keynoteアプリを使って、下を向いてぼそぼそ喋っている、みたいな寒いスタイルを回避できた 発表までにちゃんとスライドが完成した 情報を詰め込みすぎないほどよいスライドになった など、個人的にかなり実りのあるLTでした。20分くらいの発表をやったことがあるのですが、そのときは
Padrino::Validation::HTML5というgemをつくりました - Sexually Knowing
aereal/padrino-validation-html5 · GitHub つくりました。まだ荒削りですが、かなりべんりです。 モデルに定義されたバリデーションから適切な入力制約の属性値をもつフォームコントロールをつくれます。 ActiveModelというActiveSupportなんかとうまく連携できるようなモデルのインターフェースを提供するライブラリがあって、ActiveRecordをはじめとしてMongoMapperやMongoidなんかはそのまま動くはずです。 PadrinoのヘルパのひとつにFormBuilderというのがあって、これはRailsにもある、モデルからいいかんじにフォームコントロールをつくるヘルパ群となっています。実装はあっさりとしていて、form_forにオブジェクトを渡して、そこからコールバックから帰ってきたエラーメッセージとかカラム名とか引っ張っているわ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェア・テストと安全なソフトウェアを作ることについての思索 - Sexually Knowing