Join our community of software engineering leaders and aspirational developers. Always stay in-the-know by getting the most important news and exclusive content delivered fresh to your inbox to learn more about at-scale software development.
こんにちは。SmartHRでPM（プロダクトマネージャー）をしているadachiです。 最近、面接などで「SmartHRではどのような流れでプロダクトを作っているのか」という質問をよくいただくので、このあたりでいちど現状を整理しておこうと思い立ちました。 SmartHRでは、全社的にスクラム開発を採用しています。このブログにも スクラムに関する記事 がたくさんあるのでぜひ読んでいただきたいのですが、今回はもう少し引いた視点から、顧客から受けた要望がどのように開発されていくのかという全体の流れを取り上げてみたいと思います。 なお、開発プロセスは状況に合わせて日々更新されていますので、今回ご紹介するのは2021年6月時点での内容になります。 プロダクトの構成 SmartHRには、大きく分けて2種類のプロダクトがあります。ひとつはコア機能である「本体」で、もうひとつは本体にアドオンする形で使える
はじめに 筆者はオープンソースソフトウェア(OSS)に20年近くユーザないし開発者としてかかわってきました。その間ずっとOSSは様々な誤解を受けてきましたし、また、その誤解をもとに多くの根拠のない希望、その後の落胆を生んできました。何度も語られてきた陳腐な話題ではあるのですが、見かける頻度が多い誤解とそれに対する筆者の見解を書いておきます。 オープンソースはボランティアベースで開発されている。 これはyesでもありnoでもあります。ボランティアの定義は人により様々ですが、ここでは「有志が無償でやっている」くらいの意味だと考えてください。 まず、個人あるいは組織が誰からの利益を得ることもなくOSSを開発をしているという一般にイメージしやすいケースは数多くあります。ただしその目的は千差万別です。 ボランティアという字面から想像されるような世の中をよくしたい、世の中のためになりたい、という強い思
こんにちは、コーポレートエンジニアの小石(@koipai)です。 この記事では、毎月10〜20人が入社してくるSmartHRにおいて、従業員PCにかかる初期セットアップを自動化して、オンボーディングをちょっと楽に、そしてリモートワークにも対応できるシステム構築をした話をしたいと思います。 なにが課題だったのか まず、前段となる話、つまり僕がSmartHRに入社してJamf Proを触り始める以前の話をすると、僕が入社した2019年11月時点、SmartHRでは既にJamf Proが導入済み、ゼロタッチデプロイっぽいことはやっていた、という感じでした。 SelfServiceによる「なんちゃってゼロタッチデプロイ」 Jamf ProにはSelfServiceという、Jamf独自のアプリ配布用アプリが存在します。 そして、SelfServiceでは管理者によって登録されたアプリを従業員が任意で
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 本日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人（わだたくと）といいまして、
SansanでAndroidアプリケーションエンジニアをしている山口 です。リードエンジニアになって8ヶ月が過ぎました。 今回はSansan AndroidにおけるFlux移行について書こうかなと思います。 Flux移行の背景 アーキテクチャの変更に限らず新しいなにかの導入は理由があって行うものです。流行り廃りに敏感になることは重要かと思いますが、現状の開発に問題がない場合、あえて古い技術要素のまま開発を進めることは多々あります。今回Fluxへ移行する理由は以下の3つです。 体制の変更とそれに伴う現状のアーキテクチャにおける問題点を解決する データの表示というアプリの本来の目的にフォーカスする チームメンバーが好きになれるアーキテクチャを採用する 体制の変更とそれに伴う現状のアーキテクチャにおける問題点を解決する 前回この1年の変化を書かせていただいた中でチームメンバーの増加とMVPのレイ
はじめに メディアプレイヤー作っていますか？ 実際に作ろうとすると色々な対応が必要になることに気付かされます。 例えば、 アプリを落としても再生し続ける 電話が掛かってきたら止める イヤホンが抜けたらスピーカーで鳴らないように止める ループ・シャッフル ヘッドホンのボタンを押した時に曲を操作する などなど。 今回はこれらに対応できる、一般的な音楽プレイヤーを作っていきます。 MediaSessionとは 実装していく前に、MediaSessionに関して知っておく必要があります。 と言っても、仕組みを完全に理解する必要はありません。まずは再生できるまでを学習し、必要になったらより詳しい解説を都度見れば良いと思います。 なので詳しい解説は公式ドキュメントにお任せしますが、要するに 色々な所から送られてくるプレイヤーの操作・情報をMediaSessionを使って処理しよう ということです。 例
顧客はいったん継続課金を開始すると、特に大きな問題に遭遇しない限り概ね何ヶ月も継続して利用する傾向があります。最近のチャーンレート(解約率)は2~3%で、驚くほど低いものでした。ターゲット層である開発者はこだわりが強いため、彼らは熱心に他のMarkdownエディタを何年もかけていろいろ試しています。そして僕のアプリを最終的に選択しました。だからそう簡単に他に移ったり辞めないのでしょう。ちょうど彼のように： Your application is a life changer. I’ve tried numerous markdown based applications over the years and I’m so pleased to finally find a keeper! Awesome work! — James Lilliott しかし彼らは常によりよいツールを探し求め
誰かが書き始めると、他の人も書いてくれることを祈ってこのエントリを書いている。できるだけ、組織全体で使うツール（チャットツールとか）は選ばないようにした。 エンジニアが使うべき便利な windows アプリ一覧、みたいなのってどっかにまとめないの?— 徳永広夢 (@tokuhirom) October 2, 2018 RapidEE cmder 7-zip clibor Chrome, Firefox Mate Translate WinMerge そしてこれジオシティーズなので、大丈夫なのかが不安です。 Git Everything Process Explorer などsysinternals系 Crystal Disk Info ここで触れていないけど、実質必須になりそうなもの RapidEE www.rapidee.com Windowsの“環境変数”をGUIで編集できるソフト。各
本ブログポストは、マイクロソフトの意見ではなく、私個人の意見であることをお断りしておきます。 DevOps 普及活動の一環として、DevOps ハッカソンというイベントを実施しています。DevOps のプラクティスの一つとしてAutomated Testing (自動化されたテスト) があります。 それに関して複数の参加者の皆さんがこのようなことを言っていました。 「自動テストを書くのは好きではないです。何故かというと、自動化されたユニットテストを書いたら、同じ内容のエクセル方眼紙の仕様書を書かないといけないので、二重に書くのは無駄だし大変だと思うんです。」 はっきり言ってしまうと、このケースの単体テスト仕様書は完全なる無駄であると断言できます。 このポストではその理由をお話ししたいと思います。 1. 単体テストのイメージの違い この問題が起きている背景には、「単体テスト」というものがCO
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く