2017年7月20日に行われた Rails Developers Meetup #3 の発表資料です。
個人開発のやっていき方
2017年7月20日に行われた Rails Developers Meetup #3 の発表資料です。
リアルかんばんやめたいという話をチームにした - パルカワ2
リアルかんばん派でしたが、リアルかんばんやめました。— ひさいち (@hisaichi5518) 2017年3月23日 話をしたというかモバイルチームメンバーにスライドを共有しただけです。 リアルかんばんをやめたいとは言いましたが、リアルかんばんの良いところである「かんばんの前で話しやすい」というのは捨てられないとiOSメンバーの1人から聞こえてきたので、事業部のiPad Proを使ってTrelloを表示してます。こんな感じ。立って見るとちょっと低めなのでもうちょい高めにしたいところ。 あと見積もりも時間でやってたんですが、相対見積もりをするようにしました。 スプリント計画で出てきたタスクをざっくり「S」「M」「L」に分けて、Mで一番タスク内容が想像しやすいものを3ポイントとし、この3ポイントのタスクと比べて他のタスクは「1, 2, 3, 5, 8, 13」の中ではどのポイントか?と見積も
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記
ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ？ 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから？ o 信用できないテストデータ も負債 o 現
衝撃的な効率性～最高の DevOps チームは「知っている事」で構成されていた～ - メソッド屋のブログ
今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、本人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って本物を見てみたかったのだ。 だから、今回Ｓａｍにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。 気になっていたSamの一言 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日本で行っ
2人で楽しくサービスやアプリを作る話
YAP(achimon)C::Asia Hachioji 2016mid in Shinagawa Talk 7/3 10:00- スライド資料です 子供のころは、秘密基地作ってる最中が一番楽しかったりしました。小さいサービスやアプリを2人で作るときに、企画・設計・開発を「2人で」楽しく進められるように、いくつかのサービスで行ってきた具体的な事例をベースに、簡単にできる方法を話します。 - アイスブレイク - ものづくりのフローを楽しく - ものづくりのフロー - ブレストの基本 - ホワイトボードの基本的な使い方 - スケジュール調整の基本 - イメージをすり合わせて一緒に形にしていく - リード・ファーストフォロワーを2人で使い分ける - アドホックペルソナと簡易シナリオ - リアルの時間を楽しく過ごす - メッセージやりとり - 開発合宿
「Androidチームのこれまでとこれから」という話をした。 - パルカワ2
Androidチームに新しいメンバーが増えた事とテクニカルリードという役割を僕が担う事になったので、Androidチームのメンバーに僕が現状考えている「テクニカルリードの役割と責任」「Androidチームの方針」「Androidチームの文化」について簡単にまとめました。 方針に関しては、今年のはじめに決めて結構良い感じだったので、そのまま進めるという感じです。 追記: 来てくれ！！！！！１ minne Androidアプリエンジニア（正社員） | エンジニア | 職種詳細 | GMOペパボ株式会社 参考 「いるだけで成長できる環境」へ - ペパボテックブログ チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ Tech Lead（TL/テックリード）の役割 - サンフランシスコではたらくソフトウェアエンジニア - Higepon’s blog 業務遂行能力
Dockerとchrootを組み合わせたシンプルなコンテナデプロイツール - ゆううきブログ
この記事ははてなエンジニアアドベントカレンダー2015の1日目です。今回は、既存の運用フローに乗せやすいDockerイメージへのchrootによるデプロイの考え方と自作のコンセプトツール droot を紹介します。 github.com 背景 Docker 本番導入の課題 Docker 導入の目的 Docker + chroot のアイデア droot: Dockerイメージにchrootするコンテナツール droot の使い方 droot push: Dockerイメージをtar ball化しS3にpushする droot pull: S3にpushしたイメージをダウンロードし展開する droot run: 展開先のディレクトリにchrootする droot の実装 droot push/pull の実装 droot run の実装 あわせて読みたい あとがき 背景 Dockerがリリー
もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita
はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelやPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ！！ - そこに仁義はあるのか(仮)
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
湯河原の老舗旅館が「開発合宿プラン」 元SEの旅館主人が発案
湯河原の老舗旅館「おんやど惠（めぐみ）」（湯河原町宮上、TEL 0465-63-3001）が現在、「開発合宿プラン」を提供している。 「おんやど惠（めぐみ）」の「開発合宿プラン」で利用する会議室 現役エンジニアの開発作業を応援することを目的とした同プラン。プロジェクトのメンバーが日常と異なる環境で効率よく開発作業を進行できるように、会議室の24時間利用やWi-Fi環境の整備などのサービスを充実させ、快適な開発環境とおもてなしを提供して利用者から喜ばれている。 同旅館を経営する室伏学さんは元システムエンジニア。1988年から1996年まで8年半にわたりプログラミング言語と格闘。結婚を機に全く畑違いの旅館経営に従事することになった。当時出たばかりの「Windows95」のノートPCと共に湯河原に移り住み20年がたった。 「湯河原は東京駅から約70分、横浜駅からはわずか50分、湯河原駅からはタク
アニメイトラボの開発者ブログをはじめました - アニメイトラボ開発者ブログ
"古きよき時代から来ました、まじめなSE、まじめにSE" CTOの @bash0C7 です。 このブログはアニメイトラボの開発者ブログです。 自分たちの日々の事業と開発の様子や技術情報を発信していきます。 技術者が働く場所としてアニメイトラボを認知もらえればとてもうれしいです。 アニメイトラボとは アニメイトラボは2014年10月に設立された新しい会社で、現在設立第一期目です。 インターネット技術を通じてアニメ業界のインフラをより強化していきます。 事業としては、アニメイトグループのインフラを活かした新規事業の企画・開発を進める他、「アニメイトTV」、「モバイルアニメイト」、「ポケット★ドラマCD」などのサービスを営んでいます。 WE'RE HIRING! わたしは、事業企画から開発、運用まで全てのステップとレイヤーで、最高な事業とシステムをこだわりもって自分たちで進められるように、技術畑
伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは？（前編） Chef、Docker、MicroservicesからReact、FRPまで。QCon TOkyo 2015
伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは？（前編） Chef、Docker、MicroservicesからReact、FRPまで。QCon TOkyo 2015 最新のITと関連技術をエンジニアの視点で掘り下げるイベント「QCon Tokyo 2015 Conference」が4月21日に都内で開催されました。 そのセッションの1つとしてKAIZEN platform Inc.の伊藤直也氏が行ったのが、「モダンWebシステム開発」と題して、最近のWebアプリケーションに関する技術に共通する傾向を探った講演です。 ChefやPuppetなどによるInfrastructre as CodeからImmutable Infrastructureなどのインフラ周りからReactなどのフロントエンドにまで共通する考え方とは何か、示唆に富むその内容をダイジェストで紹介します。 モダ
硬直しきったプロジェクトで働いた思い出 - tehepero note(・ω<)
2015-04-29 硬直しきったプロジェクトで働いた思い出 ふと昔いたプロジェクトについて思い出したので書く。 経歴 2006-2009 中小SIer 2009-2012 フリーランス 2012-現在 サイバーエージェント 今日の話は中小SIer時代のこと。本エントリでは所属会社と呼ばせてもらう。 所属会社について 社員30名くらいで、当時で設立8年目くらい。 自称ベンチャー企業 自社製品もあったが、基本客先に常駐するスタイル。いわゆるSES契約というやつ。月に一度、帰社日というやつがある。 プロジェクトジョインの経緯 2008年当時、体力の無い所属会社はリーマン・ショックの影響で火の車。1・2年目社員の多くが社内失業者に。 会社としては、社内失業者を何とか現場に出したい。3年目以降で会社の主力メンバーと共に、社内失業者がバーターでジョインできる現場が優先された。 所属会社の1年目若手（
バグをドラゴンと呼ぶ運用を始めて1ヶ月くらいたった - Konifar's WIP
1ヶ月くらい前、 「バグをドラゴンと呼んだらどうなるか」というTweetを見ました。 確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました！」「Aクラスのドラゴンを相手にしてる最中だってのに！」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い— 尾野（しっぽ） (@tail_y) March 18, 2015 これは天才的発想だなと思って職場で雑談で話してみたところ、 同僚のスペイン人エンジニアにバカウケしまして、 それからちょいちょいバグのことをドラゴンと呼ぶようになりました。 せっかくなので、どんな雰囲気になるのかまとめてみようと思います。 先に言っておくと、自分ともう1人スペイン人エンジニアが時々チャット上で使っているだけで、 正直そんなに流行ってないです。 なんかテンションが上がる バグ修正ってマイナスをゼロにするだけで何
新刊『スクラム実践入門』の紹介、あるいは、日本のソフトウェア開発の夜明け - delirious thoughts
発端は確か一昨年のCROSSで、@hsbtさん、稲尾さんの間で話が盛り上がったのが最初だったと記憶しているから、あれから約2年、強力なメンバーで共同執筆した『スクラム実践入門──成果を生み出すアジャイルな開発プロセス』が、いよいよ3/18に刊行される。 追記: 3/18に発売されました。 Amazonのリンクは以下。電子書籍をご希望の方は、版元のサイトで発売と同時に販売されるはずなので、そちらをお待ちください。 スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) 作者: 貝瀬岳志,原田勝信,和島史典,栗林健太郎,柴田博志,家永英治出版社/メーカー: 技術評論社発売日: 2015/03/18メディア: 単行本（ソフトカバー）この商品を含むブログを見る スクラムに関する類書は既にたくさん出ているし、それぞれに素晴らしい本ばかりで、いまさら屋上
社内ITシステムを構築・運用するのに最重要な3つのポイント - たごもりすメモ
自社で使用するシステムを開発する、とする。 このとき迂闊にやっていると、気付いたら過去に構築したシステムのメンテナンスにばかり時間をとられ、新しいコードがぜんぜん書けていない、という状況に陥ることがある。 こうなると地獄だ。新規の興味深いコードを書くなんてとんでもない、という状態になる。メンテナンスコストを下げるためのコードすら書けなくて永遠に悲惨な撤退戦を繰り返すことになる。絶対に避けなくてはならない。 ということで、自分が心掛けていることをざっと書く。 全く手を入れずに動き続ける状態を最初に作る もちろんシステムというものは生き物なので、ある程度のメンテナンスコストが必要になる。特に会社というものは生き物なのでシステム周囲の環境は常に変化する可能性がある。データ連携している別のシステムの仕様が変われば、当然そのデータを利用する側も対応しなければならない*1。 ということで、システムには
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
外注が主な企業でどのように内製開発を立ち上げ・進化させているのか？
自然とそうなる開発チームをつくるいとなむ #toteka
