Socket to me
Illustration and design by Casey Labatt-Simon.Socket Mode enables you to build powerful Slack integrations safely behind your company’s firewall and unlocks access to the platform’s most interactive features — from the Events API to Block Kit to Workflow Builder. Today, millions of daily active users get exponential value from bringing their work into Slack. For developers, this means as Slack gro
一休の現在と、ここまでの道のり
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
期待のサービスはなぜ「総売り上げ3万5400円」でクローズに至ったのか――失敗から学び成長するための6項目
「失敗の振り返り」は、同じ間違いを繰り返さないために必要なこと……と分かっていても、できれば避けて通りたいツラい作業でもある。失敗したのが、自分自身が責任者として取り組んだプロジェクトであれば、なおさらだ。2019年4月24日に東京の大田区産業プラザPiOで開催された「明日の開発カンファレンス」では、あるサービスのプロダクトオーナー（PO）を務めた開発者が、あえて公開の場でその苦行に挑んだ。なぜ、そのサービスは失敗してしまったのか。立ち上げから、クローズまでの過程で、どのような意思決定があったのか。貴重な「公開振り返り」が行われた。 「総売り上げ:35400円 受託エンジニアが自社サービスのPOをやって学んだこと」と題したセッションを行ったのは、現在、永和システムマネジメントで「Agile Studio Fukui」のディレクターを務める岡島幸男氏だ。同社は受託開発ビジネスを主軸に、近年で
開発・運用本部向け新人研修2018の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。そろそろプロ野球シーズンの開幕が待ちきれなくなってきたコネクト支援チーム*1の酒井（@sakay_y）です。 サイボウズでは、新入社員全体研修の後に、開発系の新入社員に対して1ヶ月程度の開発研修をおこなっています*2。内容は、毎年改善を重ねていますが、基本的には講義＋実習です。本記事では、先日公開した2018年の研修の講義資料を、全体の流れに沿って紹介したいと思います。 開発・運用研修について 本研修は「開発本部・運用本部に配属される新入社員が、部署配属後に必要となる基礎的な知識/技術/ツールを学び、体験できる。」ことを目的にしています。 新入社員3〜4名を1チームとして、そこに担当のメンターが1名付いて研修を進めていきました。講義では先輩社員に講師をお願いし、開発演習では各チームにメンターとは別の先輩社員が担当スクラムマスター（！）として付きました。 スケジュール 7/2 〜
オーバーエンジニアリングと技術的負債を見極める––SmartHRが明かす、成長の軌跡と技術選定 - Part2
SmartHRのインフラの変遷 内藤研介氏：開発言語とコミュニティへの貢献に続きまして、ここからはインフラとか開発環境について、お金と技術的選択を軸にお話ししたいと思っております。 一般的に、私たちのようなB to Bサービスは、B to Cサービスに比べるとユーザー数は少ない傾向にあります。その中でもSmartHRは、主に社内の管理者が使うサービスなので、サービス自体の特性としてインフラの投資がめちゃくちゃ必要なものでもないです。 こちらの数字は、2015年11月に本番リリースした際のサーバ費用です。ステージング環境も含めた費用ですね。非常に経済的なアーキテクチャだったわけです。料金のうちのほとんどはAWSの、RDSというデータベースのサービスです。あとはElastiCacheというキャッシュのサービスとか、そういった部分が占めていました。 詳しい方が聞かれるとちょっと驚かれるかと思うん
組織変更したら部長がいなくなりました - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、最近愛媛から広島に移住した組織運営チームの水戸です。 2019年からサイボウズの開発本部から職能・地域毎に分かれた部署がなくなり、チーム主体の組織になりました。 組織変更をオープンに議論するというチャレンジングな試みの中で、新組織の理想はユーザー価値の最大化に定まり、個人やチームがより主体的に動ける組織構造に変わりました。 この記事では私がファシリテートを担当した組織変更をご紹介します。 開発本部の状況 開発本部の役割は製品を開発することです。 2018年までの開発本部はマトリクス組織を採用しており、プロダクト開発チームには様々な職能・地域毎に分かれた部署のメンバーが所属していました。 この組織構造は事業の中心がオンプレミスだった10年以上前から、事業の中心がクラウドに移った2018年に至るまで変わっていません。 一方、プロダクト開発チームに求められるものは大きく変わりました。
SLO、SLI、SLA について考える : CRE が現場で学んだこと | Google Cloud 公式ブログ
前回の『CRE が現場で学んだこと』シリーズでは、システムの可用性を担保するにあたってターゲットとする正確な数値をいかにして割り出すか、ということについてお話ししました。このターゲットをシステムのサービス レベル目標（SLO）と呼びます。 今後、システムが十分な信頼性を保って稼働しているか、またシステムにどんな設計やアーキテクチャの変更が必要かについて議論する際は、システムが継続的に SLO を満たしているという枠の中で語る必要があります。 SLO の適合性は直接測定することが可能です。システムにおいて精査が成功した頻度で計るのです。これをサービス レベル指標（SLI）といいます。システムが過去 1 週間 SLO を満たしつつ稼働していたかどうかを評価する場合に、SLI からサービスの可用率を把握するのです。定められた SLO を下回っているとなれば問題があるということですから、他の場所に
Netflixにおけるフルサイクル開発者―開発したものが運用する - CARTA TECH BLOG
こんにちは。fluctでiOS/Android向けSDKの開発をしているarimuraです。この記事ではPhilip Fisher-Ogden、Greg Burrell、Dianne MarshによるFull Cycle Developers at Netflix — Operate What You Buildを私が翻訳したものを著者の許可のもとに掲載しています。元の記事は弊社の技術力評価会のインプットの一つとして共有されており、そこで興味を持ったのが翻訳するきっかけとなりました。 以下、2018年5月時点における情報を記載したものであり Netflix TechBlog「Full Cycle Developers at Netflix」より引用したものである。 Netflixにおけるフルサイクル開発者―開発したものが運用する 2012年―Netflixでの重要なサービスの運用は骨の折れ
2時間スプリントでソロ、ペア、モブ、学習セッションを実験した - Mitsuyuki.Shiiba
忘れる前に走り書き的にメモ。 ## Day0 実験の場をゲット！ とあるチームのテックリードから「助けて欲しい」という相談があった。話を聞くと、プロジェクトが遅れている状況で、まだ大きく分けて3つの技術的課題が残ってて、でも、チームはその技術にあまり詳しくないので先が見えなくて不安。ということみたい。 チームの構成は、プロダクトオーナー、テックリード、エンジニア2人の4人チーム。開発手法にはスクラムを採用してる。スプリント期間は2週間。 「いいよー。水曜から金曜の3日間だけなら手伝えるし、それで不安は解決できると思う。スプリントはその間は止めようかな」と言いながら、折角だから実験させてもらおうかなと思い、条件を出した。「この3日間は全員がこの課題解決を最優先すること」それから「僕の好きにやらせてもらうねー」。 実験してみたかったのは、別々に作業するのと一緒に作業するのとではどっちがどうなん
Semantic Versioningをアプリケーション開発でやっていく · Tomohisa Oda
ソフトウェアのバージョン管理は、かつて曖昧なものでした。Semantic Versioningは、バージョニングを明確に定義し文書化したものです（TOMLやGitHub創設者で有名なTom Preston-Wernerのプロジェクト）。これにより、OSS界隈の人々はバージョニングの意味を共通認識可能なものとして、早くから導入していました。最近では、Goの標準モジュール管理としてもSemantic Versioningが利用されることになり、Goのライブラリ開発者は否が応でもSemantic Versioningを考える必要があります。 APIの変更に互換性のない場合はメジャーバージョンを、後方互換性があり機能性を追加した場合はマイナーバージョンを、後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。プレリリースやビルドナンバーなどのラベルに関しては、メジャー.マイナー.パッチの
クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？ - @kyanny's blog
TL;DR - 最初の一人はつらいけど後続はそうでもないので先駆者は自覚と誇りを持ってオールグリーンを維持しよう このエントリはMarionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogというエントリの続きにあたります。未読の方は先にそちらを一読されることをおすすめします。 Marionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogの結論で触れたように、今回テストを書くことにこだわったのは、「クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？」という問いに対する自分なりの回答を実践して検証してみたかったという理由があったからだ。 以前から「クライアント JavaScript (CoffeeScript や他の AltJS を
#TestingFrameworkMeeting に参加しました（１） - テスティングフレームワークの歴史 - @ledsun blog
参加した時のメモです。 t-wadaさん Testing Framwork Meeting テスティングフレームワークの歴史 http://www.slideshare.net/everzet/bdd-in-symfony2/42 のスライドがベース。 有史以前 make checkのように、テストを自動化する風習はあった。 開発者はそれぞれ秘伝の手法でテストコードを書いていた。 JUnit Kent BeckがJUnitを書いた。 1994 SUnit 1997 JUnit プロダクトコード書いてから、テストコードを書くまでの時間が短いほうが、 プロダクトコードに対する気づきが得られ、それをプロダクトコードに反映できることがわかった。 テストコードをさらに早く、プロダクトコードより早く書いた。 テストファーストが生まれ、ユーザーの視点でプロダクトコードを設計できるようになった。 自動テス
学生だってちゃんと開発したい！大学の授業でスクラムを導入しようと思った話 - Man page of CHIKU_WAIT(2)
前提 僕が居る公立はこだて未来大学では3年生の必修授業で「プロジェクト学習」と呼ばれる学科・コースの枠を超えた通年の開発演習があります。この授業ではサービスの開発や心理学研究、楕円曲線暗号のアルゴリズムの高速化やアルゴリズムの改良といった様々なテーマで最大15人程度のチームを組んで1年間取り組みます。実社会に根ざした問題群を解決していく方法を探求する取り組みらしいです。また、教員はあくまでもアドバイザーで、どんなことをするのか、何で開発するのか、どう開発していくのか、スケジュールはどうするのかすべて学生が主体となって決めていきます。そのため、チームによってですが、授業の時間以外も時間を費やすことが多く、3年生はプロジェクト学習に全力を注ぐと言っても過言ではないと思います。詳細はこちらを参照。www.fun.ac.jp 僕が所属しているプロジェクトは「ビーコンIoTで函館のまちをハックする
分かれたシステムをていねいにモノリスに集約する/Integrate decentralized systems to a monolith carefully
https://starttoday-tech.connpass.com/event/96477/ オウチーノではもともとサービスごとに異なる言語やFWを用いてシステムが分かれており、担当者もそれぞれ別々でした。そのため各サービスに精通した担当者が少なく、担当者は日々の運用で手一杯という状況下で、リプレイスもうまく進んではいませんでした。 そこでリプレイスよりも、分かれているシステムをひとつのモノリシックアプリケーションに集約することで、チームとしてよりワークすることをまずは目指しました。 一方で数多くのサービス機能を集約することは、そのモノリシックアプリケーションが急激に肥大化することも意味します。そこでモノリスにすることでの弊害をなるべく抑えつつ集約していく事例についてご紹介します。
スタートアップの技術選定とアプリケーションプラットフォーム - laiso
photo by pexels.com *1 この記事を書いたきっかけ niconegoto.hatenadiary.jp 「PinQulをクローズします」にて事業のふりかえりをしている文章の中に「アプリビジネスは完全にダウントレンドにある」という一節があって、ここから話題が広がっていったのを機に上記の記事を読みました。そして色々思うところがあったのです。 アプリビジネスは完全にダウントレンドというのは自分も前から思っていた。リッチな体験、通知を遅れることはアプリの利点だが、他PFからの流入なども含めたプロダクトのコアな検証はwebモバイルが1番早いはず。— sadakoa (@sadako_a_) August 16, 2018 (Twitter上で多くの共感を集めた投稿) 例えば「モバイルアプリがWebに負けはじめた理由」ではWebアプリがモバイルアプリに比べて優れているでろうという点
bosyuというサービスを作って譲渡するまでの流れ｜坪田 朋
bosyuをCasterさんに譲渡しました。 bosyuの運営会社についてbosyuは株式会社Basecampのサービスとしてリリースしました。普段はデザイン制作、プロトタイプ開発を仕事にしています。 9月で設立1周年を迎えるのでロゴを新しく作りました。 bosyuを作ろうと思ったきっかけ自分が欲しいと思ったのが一番のキッカケで、MVP開発の事例としても丁度良い規模なので作ることにしました。 ・MVP事例のポートフォリオワーク ・Twitter × OGPサービス増えた時期で自分でも作りたくなった ・規模的に丁度よく初期投資 / インフラコストも低い ・人材領域はマネタイズチャンスが多い ・最悪流行らなかったらクローズしやすい ・自分で使って数人採用できれば採算が合うような気がする ・実際にbosyu経由で複数のフリーランスの方と一緒に仕事してます 「譲渡した場合は折半」の約束でエンジニア
Google の Design Doc について
GoogleのDesign Docについて調べました．Design Docとは，Googleのエンジニアがソフトウエアを開発する際に必ず書くドキュメントです． 一般的にDesign Documentというと，設計仕様書のことをさすようです．設計仕様書はソフトウエアのシステム的な設計がどのように行われているかを記したドキュメントです．一方でGoogleのDesign Docは，あるソフトウエアについて，何を・なぜ・どのように作るかを記したもののようです．両者ともあつかっている対象や，対象としている読者が少しずつ異なっています．このエントリーではGoogleのDesign Docについて扱います． Design Docの内容 Design Docについては，Googleの鵜飼文敏さんによる以下のプレゼンテーションで触れられています． 鵜飼文敏さんの講演「ハッカーのソフトウェアエンジニアリング」
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクラムチームをやめて、20人でカンバン運用してきた半年間の軌跡 / Stop Scrum Start Kanban
Swagger (OpenAPI 2.0) を使ったAPI仕様Drivenな開発 / API-Spec-Driven development with Swagger
Webアプリケーションにおけるパスワードの管理について
