2019.6.22 DevLOVE Xで登壇したときの資料です。
2019.6.22 DevLOVE Xで登壇したときの資料です。
設計Night2018の資料です https://connpass.com/event/104821/
AWS Dev Day で発表した Backends For Frontends の話です。
はじめに 十名～数十名ぐらいのプロジェクトで開発することの多いドリコムだが， プロジェクトの中に「プロジェクトリード職」という役割を置いている。 プロジェクトの実現性と健全性を担保するのが仕事だ。 ディレクター，プロダクトデザイン，プランナー，アート，エンジニアリーダーという風に 職種別のリード職を設けていて，エンジニアリーダーの場合はアーキテクチャや安定稼働， (技術的な) ユーザビリティ等への専門性を持って責任を負うのと，エンジニアチームの チーム作りもミッションに加えている。 最近は開発ライン数が増えてきたこともあり，新卒 2，3 年目のリード職が増えてきた。 リード職になった人に「一メンバーだった頃と何が違う？」と聞くと， よく「視野が広くなった」と返ってくる。 視野が広くなるとは具体的にどういうことなのか，掘り下げてみようと思う。 主に 2 年目エンジニア向けのエントリです。 仕
DX: Developer Experience （開発体験）とは、あるシステムを「気持ちよく開発・保守できるかどうか」を示すもの 開発者は開発・保守という行為を通じたそのシステムのユーザーであり、DXはUXの一種である DXがよいと日々の開発を楽しめるようになり、気持ちに余裕ができる 気持ちの余裕がでるとコードの品質があがり保守時のデグレも減らせる また、DXがよい事自体がDXを高める動機になり、正のスパイラルを見込める つまり、「定められたタスク」（＝義務）以上のことを行うようになる DXが悪いと開発を楽しめず、「定められたタスク」以外のことをしたくなくなる DXは放置すると悪化するので、「DXがよくも悪くもない」プロダクトは時間が経つに連れ「DXが悪い」になる なので積極的にDXを良くしていく活動を奨励していくのがよい いくつか興味深いフィードバックがあったので記しておきます。 DX
会員事業部の三吉（@sankichi92）です。 クックパッドでは、GitHub Enterprise の Pull Request を使ったコードレビューを広く実施しています。 この記事では、私がコードレビューすることに対する苦手意識をなくすために意識したことを紹介します。 クックパッドでは、テックリードや新卒、インターン、バイトといった肩書きに関係なく、誰もがレビュワー・レビュイーになります。 チームやプロダクトによって開発ルールは少しずつ異なりますが、私の所属する会員事業部では、PR を出したときに GHE やチャットで部内のエンジニアにメンションして、その時にレビューできる人がレビューするという形を取っています。 私は、昨年2017年に新卒入社したのですが、それまでは個人開発や研究用のコードしか書いたことがなく、短期インターンシップを除くチーム開発の経験がありませんでした。 配属当
共著者として参加していた書籍『React，Angular，Vue.js，React Nativeを使って学ぶ はじめてのフロントエンド開発』が、2018/5/9に技術評論社さまより発売となりました。 React、Angular、Vue.js、React Nativeを使って学ぶ はじめてのフロントエンド開発 作者: 原一浩,taisa,小松大輔,永井孝,池内孝啓,新井正貴,橋本安司,日野洋一郎出版社/メーカー: 技術評論社発売日: 2018/05/09メディア: 単行本（ソフトカバー）この商品を含むブログを見る どんな本か React、Angular、Vue.js、React Nativeそれぞれが、同じサーバのAPIを参照し、同様の機能を持ったアプリケーションとして作成します。React Nativeは、ネイティブアプリを開発するためのフレームワークなため、SPA（Single-page
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きっぽい悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになっ
SmartHR のソフトウェアエンジニア ぷりんたい です。SmartHR には2017年2月に入社しました。 この記事は SmartHR 長時間のサービス停止を伴うシステムメンテナンスのお知らせ によせて書かれたものです。 ご挨拶 SmartHR では、昨年の6月より週2日という頻度で夜間のサービス停止を行ってきました。まずは、この運用形態を選択したことによりご利用中のお客様にはご不便をおかけしたことをお詫び申し上げます。 今日のクラウドサービスでは、無停止運用が当たり前といった風潮もありますが、なぜ SmartHR が停止メンテナンス運用を選択したのか、今後のサービス提供においてどのようなことを重視していくのかを技術者としての立場からご説明させて頂きます。 SmartHR の開発初期とマルチテナント問題 SmartHR は2015年2月に開発が始まり、同年11月にサービスインしました。
テスト書くのが当たり前、だけど・・・和田：次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。 でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし
レイトレ合宿10 レンダラー紹介 / Renderer Introduction, Ray Tracing Camp 10
2018-03-27プラットフォームをまたぎブレない仕様を実現するための、ネイティブアプリ開発施策こんにちは、開発本部の高井です。オンライン診療アプリ「CLINICS」のアプリ開発を主に担当しています。 CLINICS では Web に加えて、iOS 版と Android 版の各プラットフォームの仕様変更や機能追加などをほぼ同時に開発しているのですが、担当する人数が増えたりすることで、仕様に差が出たり、その結果手戻りが起きるということも増え始めていました。 そうした課題を解決するために実践した様々な施策の中から、特に有効だった 3 つの改善策について、今日はご紹介します。 背景CLINICS の開発チームでは 5 人ほどのエンジニアがタスク単位で全てのプラットフォームを実装したり、大きいタスクの場合はプラットフォーム毎に別の開発者が担当する形で開発しています。 そのような形で機能追加や不具
今年の夏頃から、特にサービスとして出すわけではなく、社内で使っているシステムのリプレースを行う事になりました。主な目的はレガシーすぎる設計をある低度モダンにする事、そして他のシステムと連携出来るようにする事、です。 対象のシステム 見積書や請求書などを管理・発行している。機能はそれなりに多いがUI操作はFormベース、テーブルタグで諸情報を表示するシンプルな物。ノンフレームワークで1画面1PHPファイルな古き良き時代のコード。おそらく10年ぐらい？稼働している。当初はPHP 5.1、PostgreSQL 8.x系だったが、現在はPHP 5.6とPostgreSQL 9.6で稼働しています。 その他の社内システム かつてはノンフレームワークだったり、太古のバージョンのCakePHPだったり、PHPが4系だったりしたが、概ねCodeIgniter 3系最新版 + PHP 5.6～7.1 + P
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
