Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近、社内でよく話をする内容についてまとめました。 企業がOSS化するといろいろメリットがあると思っていて、社内でもそこのコンセンサスはうちの技術横断部門のメンバー間では取れていたりするのですが、自社以外の人とかと話をする時もあるので、いろいろまとめておきます。 なお、この文章では本業をOSSにしつつビジネスを回そうみたいなElasticsearchとかMongoDBとかMySQLみたいな話題はとりあげず、本業が別にある会社がOSS化する、という部分に特化した話です。 9/13に追記 よく言われるメリットとデメリット メリットは、公開す
目次 目次 はじめに 技術選択の各論 開発環境 targetSdkVersion minSdkVersion Kotlinの導入 HTTP Client Dependency Injection Image Loader Debugging Android Emulator on Jenkins コードレビューbot リリースエンジニアリング おわりに はじめに 技術部の門田( @_litmon_ )です。 Android版クックパッドアプリで採用している技術の現状確認 2015年版 から3年、Androidアプリ開発を取り巻く環境も大きく変わってきました。 本エントリでは、以前のエントリからこれまでにAndroid版クックパッドアプリにあった技術選択の推移や、現在の状況を記していきます。 技術選択に関する基本的な方針などは変わっていないので、前回のエントリ( Android版クックパッド
追記: 前提部分 開発環境を docker-compose で抽象することが最近のベストプラクティスだとされているが、フロントエンドをコンテナに突っ込むと無視できないIOボトルネックが発生する。 とくにwebpackのファイル監視からのビルドで発生する高頻度のIO処理を捌くために、フロントエンドだけはホスト環境に移したほうがいい、という主張。 これについて speakerdeck.com 自分の意見 Web開発者の主要な開発環境である Docker for Mac は I/O がとにかく遅い (3x~5x) data volume の driver やら cache を工夫しても遅い npm install/webpack は 基本的に I/O ヘヴィー とくに大規模開発時の watch => build がクリティカル webpack.conifg の entry で自分が関与する部分以
こんにちは、株式会社AbemaTVでiOS、tvOSを開発している波戸 @dekatotoro と申します。 先日開催されたサイバーエージェントグループの技術カンファレンスCA BASE CAMP 2019にて登壇した、 継続的な開発スタイル 「AbemaTV iOSアプリを週一で リリースしている話」 について紹介させていただきます。 当日の発表では、AbemaTVのiOSチームで取り組んだ開発フローの改善について、前提となる開発体制とコードベースを交えてお話しました。本記事では、当日の発表スライドを元に紹介していきたいと思います。 発表スライドは以下になります。 Agenda 開発体制 コードベース 開発フロー 今後の取り組み まとめ 1. 開発体制 現在AbemaTVの開発局は約80名程います。 Direction, Android, iOS, Web, Server, QA…といた
freee Tech Night #2 の発表資料になります。 https://freee-tech-night.connpass.com/event/122276/ P18, 過去の発表資料はこちら https://speakerdeck.com/tohashi/hurontoendofal…
2019-03-27 フロントエンドエンジニアが UI 設計〜実装で考えていること おはこんばんちは、開発本部エンジニアの大岡です。 先日、TechLunch という社内勉強会で「フロントエンジニアが UI 設計〜実装で考えていること」という内容で発表しました。UI 設計から実装の細かい話ではなくどういう気持ちで望んでるかという話で、基本的なことしか書いていませんが紹介させていただければと思います。 UI 設計 UI 設計をデザイナーがして、それをエンジニアが実装する場合とエンジニアが単独で UI 設計から実装までする場合があります。今回はそれぞれのケースで、フロントエンドエンジニアがどういうことを考えてるかを紹介します。 とその前に、他人と UI について話すときに気をつけてる言葉で分かりやすくまとまっているツイートがあったので紹介します。 自分が他の人に UI デザインの説明をするとき
うろ覚えの記憶だが、2013 年に Twitter でこの話題が拡散されていたと思う。Web 業界では誰もが知っていながら誰もが認識しているわけではなかった簡潔な表現に、当時の私は衝撃ではなく、うまいこと言うなと感心していた。 しかし、当時はまだまだ Web 技術は発展途上でありながら先進的なイメージがあったように思う。ソフトウェア開発の未来が Web 技術であることは多くの人は認識していたが、Web はさして大きくないリソース上の制約を設けつつ、さして多様性のないプロトコル上の制約を受けつつ、特定技術に絞れば2年ぐらいやればその分野の詳しい人になれるという、Web 業界以外のソフトウェアエンジニアからみたとき、スキルとしてどこかチャラいイメージがあった。 知人の Linux Kernel 開発者とゲームの話をしていたとき、経験や知識の積み重ねで勝てないゲームは嫌いだという話になって、その
最近のフロントエンドに関するお気持ち。正直まとまってはない。 最近、こんな感じのツイートや記事が増えた。 web 技術をキャリアの中心にしない シングルページアプリケーション (以下SPA) の台頭により、私の観測範囲ではモダンな Web サイトは SPA で作られるようになった。サーバーサイドは JSON を返す API サーバーとなり、DB やバックエンドシステムのプロキシのような存在になりつつある。 私はサーバーサイドエンジニアとしてキャリアを積んできた。SPA が流行りだした頃、いずれサーバーサイドエンジニアは不要になって自分のキャリアを考え直さなくてはいけない時期がくるのではないかと戦々恐々としていた。 自分も元々、SPA を他サイトとの「差別化技術」と定義していた。ブラウザのタブページのライフサイクルにおいて、初期化プロセスを一回にまとめてシームレスな遷移を実現する技術。たとえ
クックパッドといえば料理レシピのサービスでお馴染みだろう。サービスのスタートは1998年の3月とのことなので、2019年の今年で実に21年目を迎える。 そんなWebサービス業界では老舗とも言える同社が主催し、サービス開発の手法や考え方について知見や学びを共有する勉強会「Cookpad Product Kitchen」が2018年12月6日（木）に開催された。 イベントでは、クックパッドの新規サービス開発部 UXエンジニア 出口貴也氏とデザイン・イノベーション・ファーム Takramでリードデザインエンジニアを務める神原啓介氏とが登壇。約75名の参加者を相手に、出口氏と神原氏それぞれが「なぜデザインとエンジニアリングの融合に取り組もうと思ったのか？ プロジェクトにとって、デザインとエンジニアリングを越境することはどのような効果を生むか？」などといったトピックについて、それぞれが実践的に取り組
Yahoo! JAPANのIaaSを支えるKubernetesクラスタ、アップデート自動化への挑戦 #yjtc
Automated Dependency Updates with RenovateAI-enhanced description The document discusses the use of Renovate, an automated dependency update tool that saves time and reduces risks in software projects by managing dependency updates on platforms like GitHub. It highlights features such as customizable settings, automated pull requests, and support for various package managers. The document also men
モバイルエンジニアの@chiiia12です。 私がQuipperのモバイルチームにjoinした際に驚いたことの一つが、自動化スクリプト/便利ツール等が多く使われていることでした。 今回はモバイルチームで最近導入されたものをいくつか紹介したいと思います。 DeployGateのビルドバージョン通知 私達のチームではDeployGateを使ってQAチームやデザインチームに開発中のアプリを配布しています。 QAテスト期間中は、不具合を改修した後に改修が含まれたバージョンのアプリをQAチームに確認をお願いしています。その際にDeployGateのバージョンを伝えてテストをしてもらっていますが、開発者にとってはDeployGateのビルドバージョンを確認するのはひと手間かかる作業になっていました。 これをissueがリンクされたpull requestのマージをトリガーに、どのDeployGateの
この記事はdely Advent Calendar 2018の7日目の投稿です。 昨日は、Androidエンジニアのkenzoが「Androidにいい感じの動きをさせていく話（ViewPagerとその他Viewとの連動）」というタイトルで投稿しました。 Android開発を行っている方はぜひチェックしてみてください。 Qiita: https://qiita.com/advent-calendar/2018/dely Adventar: https://adventar.org/calendars/3535 1. はじめに こんにちは、delyでkurashiruのiOSエンジニアをしているほりぐち（ @takaoh717 ）です。 今回は、delyが運営しているレシピ動画サービス「kurashiru（クラシル）」のiOSアプリがどのようなフローを経てストアに公開されているかをざっくりとご
freeeの価値基準の一つである、ユーザーにとって「本質的（マジ）で価値ある」ものを届けるということ。本連載ではそれに向かって、日々挑戦を続ける開発現場の事例をお伝えします。今回はfreeeのモバイルアプリ開発における、ブランチ運用方法の見直しや自動化の取り組みについて紹介します。 対象読者 モバイルアプリ開発において、Gitやリリース周りをもっとラクに運用したい方向け。 freeeのモバイルアプリ開発変遷 freeeでは現在、モバイルアプリの開発を専業で行っているエンジニアは6名いて、その6名で「会計freee」「人事労務freee」という2種類のアプリを、iOS／Androidの両OS向けに提供しています。 ただこの規模になったのもここ最近の話で、2年前は2～3人のエンジニアでOS別も含めて4つのアプリの開発を行っていました。 エンジニアの人数が増えたおかげで、飛び交うPullRequ
反省文。 tl;dr・「後から改善すれば良い」のスタンスは、返済コストを甘く見積もっている結果 ・負債の返済にはコーディング以外の工数が大きくかかってくる ・技術的負債を"徐々に"返済することは様々な面で良い 出社即リファクタリング最近出社した直後に、こっそりリファクタリングの時間を一定程度取るようにしている。朝のウォーミングアップがてら改善作業をしていると、瞑想みたいな効果があって大変気分がよくなるし、その後のコーディングも生産性が上がる。大体こういう気分。 具体的な作業は、アーキテクチャの方針が固まってなかった時代のコードの１つのエンドポイントだけ、適切なレイヤ化を施したり、単体テストが可能なメソッドとして切り出しつつ実際にテストを書いたり、テストに必要な共通処理を定義したり、だ。 初期から機能追加を重点的に行ってきたプロダクトでは、スピード優先の名目で多くの負債が生まれる。こうした負
HRTech領域で「若者の価値を最大化する」事業を展開している株式会社Traimmuというスタートアップで共同創業者・CTOをしている佐野です。 突然ですが「Tech Lead（テックリード）」というポジションをご存知ですか？ Twitterの投票機能でアンケートをとってみたところ、約35%がテックリードになりたい、そして約半数がテックリードについてよく知らないとのことでした。 cf.) https://twitter.com/yppon_s/status/1086106209424306177 現在、弊社で「テックリード」ポジションのエンジニアを絶賛募集中なのですが、自分自身もテックリードとして働いた経験がなく、どういったエンジニアがテックリードとして相応しいのかを考えたり調べたりしている中で、Jason Liszkaさんの記事「Good Tech Lead, Bad Tech Lead
個人開発者の欲求5段階説Jan 07, 2019 意識低い個人開発論ポエム言いたいだけ以前に「死なないWebサービスの作り方」みたいな記事を書いたところ、ありがたいことに最近は個人開発の相談をいただいたりすることも出てきました。（おそれ多い！） しかしすごく当たり前の話なんですが、個人開発者と言ってもステージはいろいろだし、そもそも目指すところが違ってたりもします。その前提によってアドバイスする内容も全然変わってくるなと。 自分が個人開発でいま何を目指していて、そのために何をするとよさそうなのか。 その辺りの会話の叩き台として、ざっくり整理してみようというのがこの記事の目的です。 半分以上タイトルを言いたかっただけなので、軽い気持ちで見てもらえたら幸いです。 前提と言い訳みんな大好きマズローさんみんな大好きマズローさんの欲求5段階説。あらゆるところで引用されまくってるのでもはや説明は不要で
この記事はeureka Advent Calendar 2018 18日目の記事です。 そろそろ2018年も終わりかけですが、皆さんいかがお過ごしでしょうか。Webチームの竹内(a.k.a. BOXP)です。 もう今年も終わりということで、この記事では我々Webチームが今年新たに導入していったJavaScriptのライブラリを紹介がてら振り返りたいと思います。 目次1. normalizr2. reselect3. redux-thunk4. webpack-bundle-analyzer5. jest6. renovate最後に1. normalizrnormalizr はReduxやFluxのStoreに格納するデータの正規化を行うライブラリです。 抽象的な言い方をしましたが要するに同じIDを持つオブジェクトを簡単に共通化出来るもので、例えば以下のようにオブジェクトを正規化します Be
基盤チームの川井 (@fohte) です。 今回は、monorepo と呼ばれる複数のリポジトリを単一のリポジトリで管理する運用方法の紹介と、実際にその運用に切り替えた話をします。 弊社は GitHub Enterprise を使っており、Git Flow を独自に拡張した master, develop, feature ブランチの 3 種類からなる運用フローを採用しています。 今回はその環境を前提としてお話します。 monorepo とは？ monorepo は、複数リポジトリを単一のリポジトリで管理するという Git リポジトリの運用方法の一つです。 monorepo のメリットとしては以下の点が挙げられます。 密結合なリポジトリの運用が楽になる 複数リポジトリに横断した修正が簡単にできるようになる 例えば、あるリポジトリ A の変更に従って別のリポジトリ B も変更するとき、リポジ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
