cocopyでAsanaのタスクのリンクをコピーするときにフルスクリーン版のURLをコピーする - hitode909の日記
Slackなどに貼られたAsanaのタスクのURLを開くと、タイムラインやリストなどの画面の上のモーダル画面に本文が出て、描画はあんまり速くなく、本文は画面の右端にしか出てないので、見づらいなと思っていた。 誕生日会プロジェクトにおける、ろうそくを買うタスク、とか、タスクの説明が数行くらいならいいけど、ソフトウェアを作っていたりとか込み入ったことをしていると、どうしても長文を読み書きしたくなることもある。 外部にリンクを貼るときくらいはフルスクリーン版にしておこう、と思って、cocopyでコピーするときに、URLの末尾に/fをつけるようにした。 (page) => { if (page.url.match(/\d$/)) { page.url = page.url + '/f'; } return { html: render('<a href="{{&url}}">{{title}}</
Mac のメニューバーで PR の状況を把握する - maiyama4's blog
仕事をしていると PR のレビュー依頼に一瞬で気づきたいので、メールや slack 連携などの通知を設定することになると思う。ただ、それだけだと一瞬で気づいたけど今は手が離せないので10分後くらいに見よう...と思ったまま忘れてしまうということが起こるのでなんらかの工夫が必要で、自分はメニューバーに関係する PR 一覧を表示している。 具体的には、以下のように、 自分がレビューするべき PR の数 自分が出していてマージされていない PR の数 をメニューバーに常に表示し、それをクリックすると PR へのリンクのリストが登場するようになっている（仕事の様子を公開するわけにはいかないのでダミーデータにしています）。 リストは３つのセクションに分けていて、 自分がレビューするべき PR すべて 自分が出してマージされていない PR すべて 自分が出してマージされた PR 直近３件 をそれぞれ表
チームに浸透させるのが近年では難しくなっている - id:onk のはてなブログ
昨日「動いたけどチームメンバーを説得するのが面倒で、秘蔵のブランチになってしまう」って言ったけど、この気持ちはどこから出てくるのか。 分かりやすい Cons があると、反発が予想できて、その反発を解決するところまで労力を割くほどの気持ちが無いので困る。「直ちに問題になるわけじゃないが、どちらかというとやった方がいい、でもリスクもある」という選択肢を選べずにズルズルと現状維持に向かう圧力は、ある。チームの同質性が高いうちはほとんど困らないんだが、人数が増えたり、別の職種が増えたりするごとに「面倒」さはどうしても増していく。 我々の信念として以下を持ってはいるが、現状維持に向かう圧力がある中で変化を加えるのはそこそこ労力が要り、閾値を超えると変化が発生しなくなってしまう。 業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。 素早く変えてもし仮にダメだったら素早く
稼働中の商用ネットワークでVRRPの切替検証を実施しちゃった話 - Qiita
ご挨拶 初めまして @moriya-snj です。 この記事は「本番環境でやらかしちゃった人 Advent Calendar 2019 - Qiita」の15日目の記事です。 みなさん盛大にやらかしている様で安心しております。 今回は私が社会人3ヶ月目でやらかした重大事故の記録を包み隠さず暴露するとともに当時フォローしてくださった先輩や上司お陰でなんとかこの業界で生き抜くこと出来ていることの感謝をお伝えすべく、キーボードに手を伸ばしております。 何をしでかしたか 顧客AがIP電話を導入するため、新たにVoIP用ネットワークを構築することとなった。 機器の設置等は別部署が行うため、設置依頼を出し、完了の報告をもらったため、ネットワーク機器のコンフィグなどを流し込み疎通確認などを行うこととなった。 疎通確認が完了し、お次はVRRPの切替確認を行おうとしたが、ここで誤って稼働中の顧客Bのネットワ
ソフトウェア設計の言語化スキルを磨くこと｜qsona
たとえば設計について議論するときや、コードレビューで指摘をするときに、「なぜその設計が良いと思うのか？」について言語化するのが上手だと、確実に良いことがあります。 言語化が上手にできるかが一つの壁なのではないか、と感じることもあります。後輩を育てたりチームをリードするような立場になると、特に必要性を感じるのではないかなと。 自分も、うまく言語化できたことですんなり議論を進められていると感じることは多いですし、逆に直感的な良さを言語化できなかったことで直感に反する方向に進んでしまい、結果よくなかったというような苦い経験もあります。 前提: ソフトウェア設計の良さは静的には決まらない良い設計・良いコードとは何なのか。という質問に一言で答えるなら、「保守性が高い」ことだと思います。つまり、今後の変更・拡張を、高速にバグが少なく行えるような状態が良い設計・良いコードです。(一般的にはこれで70%く
闇のDevOps DevOpsと業績評価 – ところてん – Medium
ここから、DevとOpsが協力すればより効率的になる＝DevOps、という言葉が生まれました。 当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。 ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか？ ハードウェアの時代その昔、産業の主役はハードウェアでした。 そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。 ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。 加えて、大量生産された製品の運用サポート（設置作業員、サポートセンタ）には、大量の人員が必要になってきます。 したがって、組織を研究
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
