目次・記事一覧(1) レトロゲーム(185) 日記(771) 雑文(512) 書籍・漫画関連(55) 子育て・子どもたち観察(115) ゲームブック(12) フォルクローレ・ケーナ・演奏関連(86) FF14(40) レトロでもないゲーム(336) 始めたばっか(13) アナログゲームいろいろ(37) 人狼(48) ネットの話やブログ論(61) 三国志大戦(20) 無謀的世評(52) ゴーストライター(16) 大航海時代ONLINE(40) FF3(6) Civ4(18)
中1週の第9弾 毎週水曜日のアップを楽しみにしてくださっていた皆さま、1週間の短期放牧、大変失礼いたしました。この企画を始めた当初からたくさんのリクエストをいただいていたナイスネイチャに取りかかったところ、時間が足りなくなってしまいまして…私はこのシリーズを書く際、当該馬の全レースの馬柱や記事を読み直すんですが、いかんせんネイチャの出走数が多すぎました。レース数にして「41」。過去8頭の中で最も多かったゴールドシップでさえ28戦ですし、しかもゴルシの時代とは違いネイチャが活躍した1990年代のうちの新聞ってまだデータ化されてないんですよ。つまり、パソコンでポチッとするのではなく、薄暗い資料室にこもってひとつずつ、紙をめくりながら探すしかないんです。で、探していると、あんな記事もこんな記事も出てきて、懐かしくなっていろいろ読んでいるうちに日が暮れて…って、すみません、私が悪いんですが、何とか
色々な原則や方法論はあれど、つまるところいかに変更容易性を確保するかと言う話に帰結するのでは。極論すれは、正しく動いていて変更する必要が無ければどのような作りになっていても構わない。一方、Web アプリケーションを稼働し続ける上で全く変更しなくて良いということもない。— Masashi Shinbara (@shin1x1) 2021年5月30日 ソフトウェア設計、開発には多くの原則や方法論がある。例えば、DRY 原則や SOLID 原則、デザインパターンにレイヤードアーキテクチャ、クリーンアーキテクチャなどある。さらに DDD にも多くの原則や方法論が含まれている。これらを変更容易性を高めるための手段として原則や方法論を捉えるというのが本エントリの論旨である。 原則や方法論の捉え方 変更容易性 本質的な変更と副次的な変更 外部変更容易性と内部変更容易性 原則を適用する指針 さいごに 原則
※(tmux用に交互表示の背景色スタイルをdarkblueにしています) 単純に送るだけなら、間に仲介(proxy)するソフトを使用すればlessでも可能ですが、ovcsでは ov のパッケージを使用することで、別プロセスでなく自前でサーバー化しています。 ovでは、複数ファイルに対応しているため、ページャーを閉じることなく、別のドキュメントを開くことができます。上記の動画でもページャーを閉じることなく[と]で結果表示を切り替えています。 lessも複数ファイルに対応していますが、「標準入力は一つ」のため複数のファイルを接合してしか受け入れることが出来ません。 ovcsサーバーでは、クライアントから新しく接続されたら、そこからの入力をドキュメントとして受け入れ、最後尾に追加して、さらに表示をそのドキュメントに切り替えます。 ドキュメントの切り替えはデフォルトのキーバインドで[で前に、]で後
自己紹介AppBrewで代表(兼新規事業リード)を務めている深澤です。https://appbrew.io https://initial.inc/companies/A-17314 clubhouseが流行った時にクローンサービスを作っていました。 https://note.com/yfuka86/n/n28bae17d6dcd 解決したい課題=リモートコミュニケーションの悩みコロナで急速にリモート化がすすみ、弊社AppBrewも50人ほどのフルタイムスタッフのほとんどがリモート勤務になりました。 僕自身含め、多くのスタッフが既存ツールを使いながら変化に適応する中で、形としては体裁を保ちつつも、やはり解決しきれていない問題があると感じるようになりました。それは、コミュニケーションハードルが高くなることです。 多くの会社はSlack/Zoom(あるいはその代替ツール)の構成で、それぞれ非同
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く