お問い合わせ対応の輪番制による運用をやめるに至った意思とそこからの学び - BASEプロダクトチームブログ
はじめに こんにちは。 Feature Dev1 グループでマネージャーをしている髙嶋です。 突然ですが、サービス運営するうえでユーザーからのお問い合わせ対応を無視することはできません。 そしていかに迅速かつ適切な内容で回答できるかどうかは、どこまでいってもゴールのない永遠の課題と言えるものでしょう。 ネットショップ作成サービス BASE に関するお問い合わせ対応についての運用に直近変化があったため、その経緯と効果（はある意味これからでもありますが）を共有させていただきたいと思います。 サマリとしては、概ね以下のような内容となります。 お問い合わせ対応のうち、技術的な観点が要求されるものはエンジニアに対して調査依頼がきます BASE では特定の部署が対応する形ではなく、開発組織横断で対応にあたっています 具体的には通称 cs_q というチャンネルに調査依頼がくるので、基本的には依頼がなされ
接触確認アプリの不具合という問題の所在は、OSSコミュニティではなくリリースプロセスの不備にあるのでは｜Hal Seki
接触確認アプリの不具合という問題の所在は、OSSコミュニティではなくリリースプロセスの不備にあるのでは いよいよリリースされた厚生労働省の接触確認アプリですが、「ストアで接触確認アプリと検索しても見つからない」「利用開始の日付が更新されてしまう」「初期設定時にBluetoothの許可をしないとアプリが立ち上がらない」などといった不具合が見つかり、Twitter 等で、接触確認アプリのベースとなるコードをオープンソースで開発し提供した Covid19Radar コミュニティ（以下OSSコミュニティ）に対して批判が出ています。 しかし、接触確認アプリの不具合に対して、問題の所在をOSSコミュニティそれ自体と捉えて、殊更これを責めるというのは、日本のOSSコミュニティの文化醸成のみならず、IT業界にとっても良いことでは無いと考えます。 「誰が悪い」といった責任論は問題の所在の全容を見えにくくして
経産省発の npm モジュール！住所や電話番号の正規化、ジオコーディングなどができる IMI コンポーネントツールを試した！
経産省発の npm モジュール！住所や電話番号の正規化、ジオコーディングなどができる IMI コンポーネントツールを試した！ Code for Japan の関さんが SNS でシェアしてて知ったのですが、経産省さんがなにやらオープンソースで住所や電話番号の正規化などなどをするツールを公開したとのこと。 https://info.gbiz.go.jp/tools/imi_tools/ 経産省が住所変換や法人種別名、電話番号の正規化に使えるIMIコンポーネントツールを公開しました。 ソースコードも公開。README にも使い方が丁寧に書かれていました。https://t.co/fPbV00EgZP 素晴らしい動き。こういう... #NewsPicks https://t.co/bew0qGKMFE — Hal Seki (@hal_sk) May 28, 2020 ぶっちゃけ当初はあまり期待
最新のブラウザで変わるCookieの取り扱いやPrivacyの考え方
2020/02/13 DevSumi 発表資料
一休の現在と、ここまでの道のり
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
20年でソフトウェア開発の景色はどのぐらい変わったのか？ - Qiita
PySpa統合思念体です。 某チャットで、「今時のOSSのプロジェクト管理とかのベストプラクティスが書いてある本ないかな、陳腐化早そうだしないか」みたいな話題が投入されました。その中で、エキスパートPythonプログラミングとか、Pythonプロフェッショナルプログラミングとかは思い出して紹介したけど、他の人からはShip It、Manage It、Release It三部作とか、達人プログラマーとかも出てきました。 このあたりの源流を辿ると、そういえば今流行ってる開発の源流としてはエクストリームプログラミングの開発系のプラクティスの遺伝子を受け継いでいるのが多いよな、そういえば当時から見て今ってどう変わっているのかな、という話題に。せっかくなので20年前を思い出しつつ、当時と今でどういう風に変わってきたのか適当にまとめてみます。 20年前の状況 XP白本こと、eXtreme Progra
about_mizchi_job.md
最新のステータス: 追記: 2019/7/10 転職しました。長らくのご愛顧誠にありがとうございました。 転職先をちょくちょく探しています。 興味ある方は twitter @mizchi へのリプライorDM、または mizchi2w@gmail.com まで。 メールは、反応が悪い、というか月末しか見ていません。メールの場合、送ったとtwitterで一言もらえると確認すると思います。 現在のステータス 良いところがあったら社員契約したい。全く急いでいない。 現在、フリーランスで 3 社との契約 + WebDB Press での隔月の連載を持っています。 面白そうな仕事をつまみ食いできる、フリーランスというあり方が嫌いなわけではないですが、先のことを考えながら仕事することや、月末の書類業、曜日ごとにやることが変わるコンテキストスイッチにやや消耗しています。また去年の税金にびっくりして、ちょ
069: LINE developers at work
@mntshさんをゲストに迎えてLINEのクライアント開発やリファクタリングについて話しました。 podcast feedを購読するか、DLしてお楽しみ下さい。 Show Notes:dex.fm — 059: Helping Software Engineers Be Successfulボーイスカウト・ルール | プログラマが知るべき97のことPaying back technical debt - A case study of LINE Android client -LINE DEVELOPER DAY 2017 A-4 - LINE LIVE（ラインライブ）| 国内最大級のライブ配信サービスLINEでのモバイルアプリ開発 / Mobile Application Development at LINE - Speaker DeckLINE Corporation | 募集職種一
Facebook、バグを自動で修正する新ツール「SapFix」開発
Facebookが、バグを発見し自動的に修正するよう開発した新しいツール「SapFix」を開発している。このツールは、Facebookの「Android」版アプリケーションを利用しているデバイスに安定したコードのアップデートを提供するために利用される。Facebookが把握している限り、人工知能（AI）を利用したテストおよびデバッグツールをこれだけの規模で実用向けに実現する初めてのものだという。 SapFixはさまざまな種類のバグとソフトウェアに対応できるよう開発されているため、これによって広範な企業が、高品質なコードの作成を高速化できるようになる可能性がある。 この新ツールは、「Sapienz」があってもなくても実行可能だ。SapienzもFacebookが開発したインテリジェントな自動ツールで、ソフトウェアをテストしてバグを検知する機能を備える。Facebookは「SapFix」を使用
リモートでスクラム開発とモブプログラミングを導入？ 関西在住のサイボウズエンジニアに聞く、メリット・デメリット - エンジニアtype | 転職type
2018.08.21 スキル スクラム、モブプログラミング、リモート。今が旬、もしくはこれからの潮流となっていきそうな開発手法をトリプルで採用している現場がある……。そう聞いて向かったのがサイボウズ。なぜこれらの手法を同時に採用したのか？ どんなメリットとデメリットがあるのか？ 関西在住のサイボウズ西日本開発部エンジニア2人にぶつけてみた。 サイボウズ株式会社 グローバル開発本部、西日本開発部、Yakumoチーム 三苫 亮氏（写真右）／グローバル開発本部、西日本開発部、kintoneチーム 榎原 聖太氏（写真左） リモート開発→リモートスクラム→リモートモブプログラミングの順で導入。「リモートは当たり前」という環境と意識が前提にあった 結論から言えば、このトリプルなアプローチは本番の局面で実施されていた。サイボウズのkintone開発チームと、kintoneをアメリカに提供するにあたって、
なぜ dev.to がこんなにも速く、こんなにも自分にとって感動的なのか
最初にいっておく。これは負け惜しみだ。 SPAとPWAの現状 自分は日本でReactの勝手エヴァンジェリストみたいなことをやっていて、SPAの重めのコンテンツをよく作ってるからか、「お前らフロントエンドを物事をややこしくして、重いページを量産してウェブを劣化させてるじゃないか！」みたいな批判を、名指しでよく受ける。なんで僕にいうかわからないけど、React = SPA みたいなイメージでスケープゴートにされてるんだろう。それはまあいい。 自分の仕事でSPA技術を使うところは、ちゃんと必要性もあるし理由も説明できる。ただ、やはり近年の複雑化/重量化について思うところはあるので、逆に振って AMP/PWA という選択肢を持っておきたくて、正直言うと依頼されたR&Dの仕事でもあったんだけど、一通り覚えた。なんだけど、今のところ仕事で使うタイミングがない。 PWA技術を仕事で使えなかった理由として
Macに別れを告げて、クラウド中心の開発生活を始めるまで - Qiita
昨年あたりから、Macやめたい病を患っていたのですが、2度の故障を経て、重たい腰を上げました。別にWindows使いたいわけもなく「ローカルが煩わしい」だけなので、Windowsアプリは一切インストールしていません。で、どうやって暮らしてるの? というお話です。 TL;DR このあたり↓を組み合わせていけば、クラウド生活可能: GCP (or AWS) Codeanywhere (or Koding or Cloud9) VPCネットワーク + VPN (IPsec+L2TP) + DNS Figmaほか、Webサービス各種 追記・この記事を書いていたら、AWS Cloud9が発表されました。選択肢が増えて何よりです。 はじめに 本稿は、筆者が「Mac断ち」あるいは「ローカルマシンから解脱(げだつ)」する過程で見えてきた、ベスト(かも)プラクティス集に近いものです。 よく使うテキストエディ
はじめてのスクラムマスター振り返り - てんてんのぶろぐ
去年の12月から約半年間、はじめてスクラムマスターを担当したので振り返りです。 プロジェクトの概要や技術的なアレコレはQiitaのSIの現場のiOSアプリケーション開発 - Qiitaという記事にまとめてあります。 チーム構成 開発チーム 開発チームは5人で、(アンチパターンですが)自分がスクラムマスターと開発者を兼任していました。 5人中スクラム経験者は1人のみ、技術的にもiOS開発経験者が1人というメンバー構成で、若手中心(2年目2人、3年目1人)かつ開発経験浅めのメンバーが多いチームでした。 また、2スプリント目から1人追加になったり、他プロジェクトの対応で2人抜けて戻ってきたりと、プロジェクト途中での人数の増減が何回か発生しました。 スクラムマスター スクラムマスターは自分が担当しました。 タイトルの通り、初めてのスクラムマスターでした。 2011年頃から社内のアジャイルサムライ読
GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey
果たしてGitLab.comで何が起きたのでしょうか？ これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時（世界協定時。日本時間2月1日午前8時）、YP氏（Yorick Peterse氏と思われる）はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時
Seleniumアレルギーのための処方箋 - Qiita
何年も前、SeleniumやWebDriverの話で盛り上がった記憶があります。ただ、その当時はまだRailsなどバックエンド中心の文脈でした。今、フロントエンドに軸足が移る中、ブラウザテストの状況はどうなったのでしょう? 不思議なことに、フロントエンド界隈でそれほど話題に上がって来ないですよね (私の周りだけ?)。結構大事なのに。実は皆さん、「Seleniumアレルギー」なんじゃないですか? 公式サイトに漂う ゼロ年代感(下図)。Javaへの躊躇、「めんどくさい」と聞かされ続けた過去、無意識に避けてしまうのがSeleniumです。 ただ、フロントエンドの文脈でこそ、ブラウザテストは重要度を増しています。そこで「Selenium触りたくない病」の筆者が、 四苦八苦した背景 と、2016年だからこそ 見えてきた落とし所 を書いてみたいと思います。 註: 思ったより長文になってしまいました。先
The DevOps 2.0 Toolkit
I Am Very Old! Preface Overview Audience About the Author The DevOps Ideal Continuous Integration, Delivery, and Deployment The Light at the End of the Deployment Pipeline The Implementation Breakthrough: Continuous Deployment, Microservices, and Containers Continuous Integration Continuous Delivery and Deployment Microservices Containers The Three Musketeers: Synergy of Continuous Deployment, Mic
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Engadget | Technology News & Reviews
時代が求めたSTNSと僕
untitled
ウェブ魚拓の「過去の魚拓」機能の停止につきまして | 株式会社アフィリティー