エウレカはPairs(ペアーズ)のiOSアプリをどのように作っているのか
この記事は「Eureka Advent Calendar 2021」1日目の記事です。 Pairs iOSアプリの開発にあたり、チームの体制やメンバーの動き方、開発の運用、そして実装方針など幅広く触れた内容となります。 エウレカのiOSチームの開発に興味があり、どのように作っていて、今の課題や次にやりたいことは？に関心のある方に向けた記事になります。 幅広く要点に触れつつ、各詳細には触れすぎない記事となりますので、詳しく知りたいという方はMuukii(Hiroshi Kimura)まで連絡をもらえればお答えします。 なお、一番下に私個人として、これからチャレンジしてみたいことが書いてあります。 概要チーム体制とメンバーの動き方ソースコード管理と申請などの開発における運用具体的な機能実装に関わる設計や技術チーム構成とプロジェクト会社の組織構造としてはチームは職種ごとに分けられています。 例
コードレビューにおけるレビュアー側のアンチパターン
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
フロントエンド開発の概要について
ここでは、フロントエンド開発の概要について説明していきます。 ＊元記事はこちらです。(英語) この記事でカバーしているものについてSingle-page Apps (SPAs)New-age JavaScriptUser InterfaceState ManagementCoding with StyleTestingLinting JavaScriptLinting CSSTypesBuild SystemPackage ManagementContinuous IntegrationHostingDeploymentSingle-page Apps (SPAs)かつてはサーバーサイドレンダリングという、別のURLを開くごとにページをリフレッシュしてサーバーから新たなHTMLページを送る手法が主流でしたが、最近のSPAsではクライアントサイドレンダリングというものが主流になっています。
ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
How we designed Foursquare Swarm 5.0
Over the past eight months, the Swarm team has been hard at work researching, prototyping, and building towards Swarm 5.0. On Tuesday, we launched. (Go download Swarm 5.0 now.) It was a big undertaking that involved a lot of people. Foursquare co-founder Dennis Crowley has already shared why we made me these changes, which means I can explain what, precisely, we were up to all this time. As a prod
エンジニア向けの社内情報共有ツールの紹介
FiNCのエンジニアの人数も50人を超え、チームを横断した情報共有の機運が高まっています。 もともと社内には情報共有ツールとしてConfluenceやGitHub Wikiなどがありましたが、前者はMarkdownなどのエンジニアがドキュメントを書きやすい機能が不足しており、後者は情報の検索性に難がありました。 エンジニアのコミュニケーションを活性化させるため、カジュアルに記事を投稿できて誰でも見ることができる、新しい情報共有ツールを導入をすることにしました。 今回は候補として検討した際に、以下の要件を満たしていた情報共有ツールを紹介します。 Markdownを使ってプレーンテキストで記述できる記事の更新履歴のdiffを見ることができるフィードで記事の一覧を見ることができるわかりやすい検索機能コメント欄でのやりとりができるWebhook(チャットツール連携)UML記法やスライドの埋め込みの
ソフトウェアのファーストフード化 – カワマタ さとし – Medium
ソフトウェアのファーストフード化ソフトウェアを否定するものではありません。むしろソフトウェアは好きです。ソフトウェアの「開発」に焦点を当てた考察になります。そして、僕自身の仕事に対する姿勢というか、スタンスを述べるものになります。 自分の仕事を思考する僕は最近、深い森に入るように仕事について考えることが多くなってきて、考えたことを誰かに話したり、こうやって文章として残したりしています。先日もUI Crunchというイベントにも登壇させていただき、「いい仕事」についてお話しさせていただきました。スライドはこちらです。https://speakerdeck.com/kwmt/iishi-shi-wosiyou 驚くほどに反響があり、自分でもびっくりしています。仕事に対して抱く感覚は人それぞれだと思いますが、僕なりには解釈ができるようにちょっとだけ熟してきた気がします。 ソフトウェアのデザインを
消しゴムの抑止力
消しゴムの抑止力 中学の時に、消しゴムの使用を禁止している数学の先生がいました。理由としては、 消しゴムで消さなくてもノートの余白は潤沢にある実際ノートを最後まで使い切る事はほぼ無い。間違えたり失敗したとしても、別に消す必要は無い。学習中は間違えるのが普通だし、間違えた記録が残っている方が情報量が多い。あとで見返すことも出来る。だから消しゴムで消すメリットはほとんど無いという感じの事だったと記憶しています。消しゴムを使うことをあまりにしつこく制止するので、当時は「変な先生だなあ」としか思わなかったけど、今となってはなんとなく、なぜ先生が消しゴムの使用を明示的に禁止していたのかわかる気がします。 僕の小学生の息子も宿題で間違った箇所を消しゴムで消すのですが、かなり面倒くさそうにしています。そもそも消しゴムってたいして消えないし、消しクズが出るし、紙もクシャクシャになるし、いいことが全然ないの
『メルカリ アッテ』に学ぶチームで行うサービス立ち上げの方法
メルカリのグループ会社、『atte（アッテ）』を運営する株式会社ソウゾウさんのイベント、『atte fes』に行ってきました。今回はブロガー枠で参加させてもらったので、レポートします。 まずは代表の松本龍祐氏のカンパイでスタート！ photo by ossam3つのプレゼンがあったのですが、僕の感想はこの3つです。 1．スターを吸収していくメルカリというチームの強さ2．サービス立ち上げにおけるチームの自己確信の大切さ3．事業思考をもっているチームの仕事のしやすさどれもチームの話が共通点だったので、プロデューサー、ディレクター、デザイナーから3つの視点でサービス立ち上げを見る、という構成でまとめてみました。どうぞ！ 1．プロデューサーから見たサービス立ち上げここで学ぶこと：立ち上げ〜チームづくり、コンセプトの決め方、新規事業のポイント まず、昨年は起業家の松本さんがなぜメルカリに入ったんだろ
iOS ヒューマンインターフェースの原則 — Medium
iOS のヒューマンインターフェースを理解するためにはまず UI 設計の原則を定めた聖典 iOS Human Interface Guidelines を読むことから始めなければなりません。ここにはプラットフォームの特徴から情報設計の原則、それぞれ何のための部品なのか、という解説がされています。なぜこうなったのか、なぜこれが良くてあれが駄目なのか、Apple の UI デザイナーは何を考えてこのような設計にしたのか、HIG ではそのようなところまでは説明されていないことがあります。いくら内容を丸暗記したとしても「 なぜ 」がわからなければ本質から理解したとは言えません。 よくある UI デザインにおける誤り、『磨りガラス効果がかっこいい』『アニメーションしておくとかっこいい』『ボタンは右配置の方が押しやすい』『色が綺麗』『流行っているから優れている』…などがありますが、そういうことではない
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
社内なら謝らなくて良いカルチャー
社内で仕事をしているとき、指摘や指導をすることがあるが、まだうちのカルチャーに慣れていない人は、すぐに「すいません」と謝る。でも、それは良くないよ、と言っている。 仕事の仕方や成果物に対しての指摘というのは、別に悪いことをしたからな訳ではないのだから、謝る必要などない。私に謝って欲しくて指摘している訳ではないのだ。 謝るってことは、私を向いて仕事をしていることになる。それは良くない。仕事はあくまでユーザやお客さまを向いてするものだ。社内の人に向いて仕事をするのではない。 だから指摘に対して謝る必要はない。良い仕事をしてもらいたい、成長してもらいたいから指摘をしているのだ。社長の顔色なんて見なくていい。良い仕事をすればいい。 同じチームにいて、良い仕事をして、成長していきたいというベクトルがあっているなら、謝ることなんてないのだ。そういうカルチャーの会社であり続けたいと思っている。 もちろん
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
iOS のポップアップUIのクローンライブラリを作りました