はじめまして。2019年1月に入社したSREスペシャリストのsonotsです。最近MLOpsチームのリーダーになりました。今回の記事はMLOpsの業務とは関係がないのですが、3月に弊社で実施した会社用GitHub個人アカウントの廃止について事例報告します。 TL;DR 会社用GitHubアカウントを作るべきか否か問題 会社用GitHubアカウントの利用で抱えた問題 1. OSS活動時にアカウントを切り替える必要があり面倒 2. GitHubの規約に準拠していない 会社用アカウントを廃止した場合にセキュリティをどのように担保するか GitHubのSAML single sign-on (SSO)機能について 会社用アカウントの廃止およびSSO有効化の実施 会社用GitHubアカウントを使い続ける場合 私用GitHubアカウントに切り替える場合 Botアカウントの場合 Outside Coll
今日は、日本の代表的なソフトウェア開発手法について紹介しよう。 その名も、メテオフォール型開発である*1。 第一節 通常のウォーターフォール型開発におけるプロジェクトはこのような形を取るが、 メテオフォール型開発ではこのような形が取られる。 そしてこうなる。 これはアジャイル型開発手法におけるサイクルであるが、 神の前では無力である。 神の一声は全てを崩壊させ、 民は一生懸命これを再建す。 これが、メテオフォール型開発*2である。 第二節 全てのスケジュールは天界の都合によって決まる。これを黙示録と呼ぶ。 ソフトウェア開発においてフィードバックは重要なファクターだが、 神にフィードバックは届かない。 ただし、祈りを捧げることはできる。この祈りはごくまれに届く。 神は様々な姿を取る。 外から現れることもあれば、 内に棲んでいることもある。 あるいは、まだ会っていない or 会うことすらできな
エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。 この記事は[Ateam Lifestyle x cyma Advent Calendar 2018]の5日目…当時、株式会社エイチームライフスタイルだった頃の記事です。現在はワンディーという会社でVPoEをしています。 はじめに最近のWEBサービス運営チームというと、事業運営や企画営業のチームと、エンジニアチームが一緒になって働く事が多いですよね。 そんな時、多くのエンジニアが、 「品質保持やリファクタリング、改善系のissue（タスク）の優先度がなかなか上がらず、着手できない・・・・・・」 といった悩みを抱えがちです。これなんですが、非エンジニアの皆さんからすると、 「エンジニアがすごいのは分かるんだけど、何をやってるか、なんでこんな時間がかかるのか、正直分からな
Electron Forge is an all-in-one tool for packaging and distributing Electron applications. It combines many single-purpose packages to create a full build pipeline that works out of the box, complete with code signing, installers, and artifact publishing. For advanced workflows, custom build logic can be added in the Forge lifecycle through its Plugin API. Custom build and storage targets can be h
Webフロントエンド パフォーマンス改善ハンドブック このパフォーマンス改善ハンドブックでは、ウェブアプリケーションにおけるフロントエンドのパフォーマンス改善について扱っています。 ダウンロード版 埋め込み動画を再生できないなど一部制限がありますが、ダウンロード版を配布しています。 PDF版 EPUB版 MOBI版 目的 このハンドブックでは過去に行った改善の事例を中心に紹介しています。 そのため、現在の最適な解決方法を提案するものではありません。 また、アプリケーションによっても最適な解決方法は異なります。 今回の事例ではViewライブラリにReactを使い映像再生プレイヤーなどある程度複雑な機能を持ったウェブアプリケーションのフロントを扱います。 具体的にはニコニコ生放送（以下「生放送」）で行った事例を中心に書かれています。 開発と平行して行われていたため、React 15から16の間
お初です。2017年10月入社の @kobaken です。iOSアプリ開発を生業にしております。 最近はすっかりスタァライトされてしまい、舞台創造科の一員になってしまいました。 普段は声優のことを考える傍ら、pixivやpixiv SketchのiOSアプリの開発をしています。 ところで、iOSアプリ開発をされている皆さんの中に、このような現象に頭を悩まされている方はいるでしょうか？ なかなか終わらないビルド……侵食されるCPUリソース……固まるIDE…… わかります。自分も以前までは上記の症例に頭を悩まされ、【精神破壊(メンタルブレイク)】される寸前でした。 どうにかして作業効率を上げないと僕が病んじゃう！そうすると開発の手が止まって、新しい価値をユーザに届けられなくなっちゃう！私これからどうすればいいの〜〜〜！……そんなとき僕たちの目の前に現れたのが「iMac Pro」でした。 iMa
Allow authors of pull requests to set status to pending while still working on it. By default, the WIP is setting a pull request status to pending if it finds one of the following terms in the pull request titles wip work in progress 🚧 The pro plan allows for configuration of both the terms and the locations that the app is looking for the terms. All revenue is donated to Processing | p5.js – one
Snappable guidesHold distance on the screenMultiple object measurementCleanShot integrationAdobe XD integrationScreenshot tool for taking screenshots of measurementsCustomize all shortcutsAdded onboarding tutorialTouchbar supportSelect object without snapping (with right drag)Move rectangle by pressing spaceFind dimensions by pressing dock iconMojave supportDownscale retina screenshots to 1xHide t
There are a set of rules to keep in mind: Perform work in a feature branch. Why: Because this way all work is done in isolation on a dedicated branch rather than the main branch. It allows you to submit multiple pull requests without confusion. You can iterate without polluting the master branch with potentially unstable, unfinished code. read more... Branch out from develop Why: This way, you can
どうもしんざきです。曲がりくねったSQLを読んで、モニターを威嚇しつつ不要なjoinを削除しまくる仕事で主に生計を立てています。 こんなまとめを読みました。 某大手企業の本社を辞めるという人『古い会社は社内の体制も古い。癒着してるシステム会社も全然ダメでテキストの左揃えを右揃えに変えるだけで300万取られる』（現在は非公開） ワイの妹ト○タの本社やめて転職するらしいんだけど、「古い会社は社内の体制も古くてダメ。癒着してるシステム会社も全然ダメで、テキストの左揃えを右揃えに変えるだけで300万取られる上、バグ（仕様）だらけで仕事にならない」って言ってたの印象深い。 これ、もともとの話の情報量が全然なくって、何のシステムの話かも分からなければシステムの規模も分からないので、300万が高いのか安いのか妥当なのか、というのは勿論なんとも言えないです。 もしかするとこれはぼったくり案件なのかもしれま
BEMのいいところは、それが何者なのかが明白ということに尽きる。とある要素を見たときに、そのスタイルがどこに書かれているのか、何を表しているのかがクラス名を見ればわかる。手を入れる際も、どこに追記すればよいのか、どれくらいの影響を及ぼすのかの大部分が推測できる。 レスポンシブ・デザインと相性がいいとか、流行りのコンポーネント指向と相性がいいなど、BEMの良さは他にもいくつか挙げられるけど、決定的なのは明瞭さであると思う。 BEMを使いはじめてかれこれ３，４年くらい経った。その間に色々な命名規則や設計思想が登場してきたけれども、今のところは浮気する程の魅力を他に感じることもなくBEM一筋でやってきている。ただし実践するにつけて、より明瞭で破綻しづらい設計を実現するために、様々な制約やガイドを設けてやってきたので、「もともとのBEM」からは多少なり離れているかもしれない。 ただし、それはBEM
今年の２月ごろ今までビビってやってなかった電話サポートをというものを050の電話番号を使って始めてみた。今年の2月、開始して二週間ぐらいでわかったことを記事にしたのが以下です。 個人アプリ開発者だけど電話サポートをやってみた もし、これきついなあって途中で思ったらいつでも辞めようと思ってたんだけど、いまのところ半年以上続いているので、その中で発見とか、わかったことをアップデートしてみる。 どのぐらいかかってくんの？ とりあえず、今は会計アプリのTaxnoteと、最近リリースした読み上げアプリのVoicepaperのヘルプに電話番号を書いている。 例えば、Taxnoteだと、設定画面の「ヘルプ」をタップすると一番上に「お電話での問い合わせ」と表示しているので、ヘルプを見た人は一番最初に電話での問い合わせが出来ると気づくようにしてる。 ちなみに、アプリのDL数はそんなに多くないので、問い合わせ
October 3, 2017 Daniel Imms, @Tyriar The rendering engine of the Integrated Terminal has been completely re-written with performance in mind for the upcoming version 1.17 of Visual Studio Code. In this version, we move away from a DOM-based rendering system to using the HTML canvas element. DOM Rendering It's somewhat surprising, but rendering an interactive terminal was possible in a system desig
Summary: Elaborate usability tests are a waste of resources. The best results come from testing no more than 5 users and running as many small tests as you can afford. Introduction Some people think that usability is very costly and complex and that user tests should be reserved for the rare web design project with a huge budget and a lavish time schedule. Not true. Elaborate usability tests are a
「Nexus 5X＆6P」のAndroid OSサポート終了 「Pixel 2」日本投入なくアプリ開発者が困惑 http://www.itmedia.co.jp/news/articles/1710/06/news108.html リファレンス実装がないと死ねるまず、一口にAndroidと言ってもメーカーや機種によっていろいろなカスタマイズが入っていることを思い出してほしい。 NexusやPixelはリファレンス実装として認識されているので、そいつらで動けば大体の端末で動く（事が多い）。 XperiaやGalaxyはメーカーにより色々手が入っているので、そいらに基づいて開発してしまうと、そいつらだけでたまたまうまくいくけど他の端末では動作しないような実装をしてしまう危険性が高まる。 なので、NexusあるいはPixelで実装を進め、XperiaやGalaxyで互換性テストをする、という開発
こんにちは、@yoheiMuneです。 先日、[フロントエンド] ローカルプロキシを用いて、本番サイトで開発/デバッグを行うというブログを書きましたが、本日はその続きでHTTPSサイトでもデバッグする方法をブログに書きたいと思います。 目次 HTTPS通信をローカルプロキシで確認＆改ざんする設定 先日のブログで紹介したCharlesでは、デフォルト設定ではHTTPsサイトに対応することはできません。追加で以下の設定を行います。 証明書の発行と適用 Charlesで利用する証明書の発行と適用を行います。これを用いてHTTPSの暗号化をCharles上で復号化して通信内容を見えるようにします。 Charlesのメニューから「help < SSL Proxing < Install Charles Root Certificate」で証明書のインストールを行います。そうすると、以下のようにキーチ
![[フロントエンド] ローカルプロキシのCharlesを使って、HTTPSサイトもデバッグする - YoheiM .NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/6a27b450cea620fe3d47540b44954ced37f87684/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fwww.yoheim.net%2Fimage%2F438.jpg)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
