新卒1年目から新規プロダクトのサーバーサイド開発を任され、様々な技術書を読んだり社内外のエンジニアに相談しながら開発を進めていった結果学ぶことが色々ありました。この勉強会では、そうした経験から私がバックエンド開発の際に考えていることや大事だと思っていることについてお話します。
![仕事でバックエンド開発するときに考えていること / GEEK-SAI-2022-AUTUMN-yanyan-Backend-Study](https://cdn-ak-scissors.b.st-hatena.com/image/square/99d8348e31fb27f68af0e02d4b5bcaaa3c4290e7/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F3efbda090f46452da34173bcf87880b6%2Fslide_0.jpg%3F23060442)
運営者ギルドという、個人や少人数チームでWebサービスやアプリを作っている人のSlackチームがありまして、そこで furuta さんやnaichi さんとチャットしていて、個人サービスを作っていて「モチベーションが続かない」「いつの間にか辛くなってくる」という個人開発あるあるについて話していました。 個人開発は「自分の作りたいもの」を「自分の使いたい技術」で「自分の好き」に作れる最高の舞台です。クリエイターならやらない手はないでしょう。 しかし、何も考えずにいざ足を踏み入れてみると、思ったよりも険しい道だと気づくのです。 仕事でもなく「自分が作りたくて作っていた」はずなのに、いつの間にかどこかに逃げ出してしまうモチベーション。何ヶ月経っても作り終わらない現代のサグラダ・ファミリア。仕事がバタついて1週間面倒見ていなかっただけで「え、なにこのクソコード」と毒づいてしまうほど荒れ果てたmas
2018年10月13日、株式会社AbemaTVが主催するイベント「AbemaTV Developer Conference 2018」が開催されました。3度目の開催となる今回のテーマは「PAST→FUTURE」。開局から2年半の実績を元に、快適な視聴体験を届けるための取り組みや、大規模な同時接続に対するシステム開発・運用に寄って得られた技術的知見を共有します。プレゼンテーション「AbemaTVのアーキテクチャの変遷 」に登壇したのは、株式会社AbemaTVの山中勇成氏。日本初のインターネットテレビ局、AbemaTVの開局から今日までのアーキテクチャーの変遷について、サービスの歴史とともに振り返ります。講演資料はこちら AbemaTVのアーキテクチャの変遷 山中勇成氏(以下、山中):こんにちは。このセッションでは「AbemaTVのアーキテクチャの変遷」というタイトルで、AbemaTVが開局前
こんにちは。阿部と申します。とある渋谷のIT企業でエンジニアのお仕事をしています。普段はブログを書いていないのですが、お勤め先の社内ブログ用に以前執筆した記事をlean-agile podcastで紹介していただく事になり、当時の記事を今回こちらのプラットフォームでも公開する事にしました。長文になりますが、ご興味を持たれた方は是非ご覧ください。 「海外と日本でのソフトウェア開発職の文化を振り返ってみた」という記事のタイトルにしているのですが、この話のモチベーション・裏付けとしてまず自分のバックグラウンドを簡単に説明しておきます。私は名前によらず外国籍・海外育ちで、今までヨーロッパと日本それぞれでベンチャー・中小企業・大手の仕事環境を6社ほど転々とし、色々な国のエンジニアと仕事をしてきました。 (*ちなみに、日本語で記事を書くのはあまり得意でないので、言葉遣いがおかしいところは大目に見ていた
個人開発の高校野球ゲームが収益1,290万円超えるまでにやった3つのこと。引退かけたアプリ開発者が語る「課金収益10倍」ドラフト課金の思わぬ効果。 名古屋で野球ゲームをつくっている個人開発者を取材しました。「個人開発者特集2018」の第三回です。 ※furuApplications 古田 悠さん 月100万円いかなければ「アプリ開発者をやめる」 簡単に自己紹介をお願いできますか? 名古屋で活動している個人アプリ開発者です。いまは野球シミュレーションゲーム(シリーズ3作品)を主につくって生活しています。 独立して1〜2年は、貯金を食いつぶしながら生活してたのですが、シリーズ2作目の野球ゲームで、月に30万円はなんとか稼げるようになって。 そこでようやく、アプリで生活できるようになりました。 それはそれでスゴイですよね。 ただ、厳しい状況から脱したものの、結婚していて子供もいたので、正直なとこ
こんにちは、技術部モバイル基盤グループの茂呂(@slightair)です。 先日のiOSDCは大盛況でしたね。とても楽しく、実りあるカンファレンスでした。この記事で僕は ididblog! ということにしようと思っています 😋 クックパッドからは @giginet と僕の二人が登壇しました。発表を聞きに来ていただいた方はありがとうございました。 @giginet の 詳解Fastfile という発表中でさらっと話された、”毎週自動的にリリースされる”という言葉が気になった方はいるのではないでしょうか。実はこのリリースフローについての話もプロポーザルに出していたのです(もっともっと細かくリリースをしてユーザーに最速で価値を届けるためのリリースフロー)。 この記事ではこのリリースフローについての話をしたいと思います。 クックパッドアプリの開発体制 クックパッドアプリの開発体制は人数の変動はあ
俺コン Vol.1 / Day. 2 https://orecon.connpass.com/event/64285/ Firebase, Google Analytics, Fabric, Apple App Analytics の個人的使い分け http://starhoshi.hatenablog.com/entry/2017/07/04/Firebase%2C_Google_Analytics%2C_Fabric%2C_Apple_App_Analytics_%E3%81%AE%E5%80%8B%E4%BA%BA%E7%9A%84%E4%BD%BF%E3%81%84%E5%88%86%E3%81%91 Rails サーバから Google Analytics API で情報を取得する手順 http://bekkou68.hatenablog.com/entry/2014/08/20
140年の歴史を持つ日本経済新聞社が、日経電子版アプリで内製化とアジャイル開発に挑戦した理由と現実、そして課題とは(前編) 日本を代表する新聞社のひとつである日本経済新聞社は、スマートフォンから記事を読むことができる日経電子版を提供しています。そしてこのスマートフォンアプリ開発において、同社は内製化とアジャイル開発による迅速なリリース体制を実現しました。 講演者自身が「古い体質」と説明する企業で、それまで外注によって開発されてきたアプリを、どのように内製化へ持ち込み、アジャイル開発の体制を実現していったのでしょうか。 1月12日と13日に行われたスクラムのイベント「Regional SCRUM GATHERING Tokyo 2017」では、同社でモバイルアプリケーションの開発チームを担当する武市大志が登壇。内製化やアジャイル開発を実現するために改革と改善を繰り返してきた背景と事情を詳しく
speakerdeck.com 先日のUnity道場京都スペシャルの公開資料です。 技術よりは開発でのノウハウを述べられています。 (後半は自社ライブラリからの説明) 気に留めておくメモ ・メンバー誰でもクライアント(unity)、サーバー(Ruby on Rails)に対応できる ・Team GeekによるHRT(謙虚、尊敬、信頼) 自分の置かれている環境では分業制なんですが、マルチスキルを持っておいた方がいいのでしょうか。 スキルは業務を通じて学んでいくところが多いのですが、そういったスケジュールが取られないのが実情でしょう。 数年前までは、開発が終わったらしばらくは基礎研究として、好きな分野を調べたりできたのですが、 今は即運営に回されたりするので、そういった機会が少ないのは不幸と言えます。 反面、こうした勉強会の機会が増えたり、情報の収集には苦労しなくていいのは助かります。 結局、
重要なのは、この「煩わしさ」は、「そのタスクを完了した際に、どれだけ体力と意欲を使い果たすか」 の指標であることです。 「技術的には難しくないから、経験の浅い人にまとめてやってもらおう」と、そうした「だるいタスク」を集中させてしまうと、あっという間に人員が疲弊して 最悪離職します 恥ずかしながらこういう経験があります。 「だるさ見積り」した => 予測工数の -5%〜+5% の前倒しor遅延 で済んだ 「だるさ見積り」しなかった => +20%〜40% も遅延した。 終わった後の生産性の低さも本当にもう酷かった。 ごめんなさい。。。。 やろう!『だるさ』見積り!本当に大事だよ! [見積もり編] 3. OKR を意識したバックログ 具体的には Github の issue サマリを記載していく事柄で実践します Objectives : この PullRequest で何ができてほしいのか サ
少し前の記事(「プログラミング未経験者がWEBエンジニアになるためにやるべきこと」)の元になったプログラミング初心者の二人が、それぞれ無事Railsのチュートリアルまで終わらせていざ自分のサービスを作りたい!ってなった時に、さて何から手をつけたらいいんやろう?という同じ悩みにぶつかって同じようなアドバイスをしてたので、またその内容をまとめてみました。 初心者に限らず、小規模WEBアプリを作る時にこういうことをしとくといいかなっていう個人的な手法みたいなのをざっくり書いていきます。 SPONSERD LINK 前提 一般的なシステム開発は下記のフローで進んでいきます。 要件定義 設計 開発 テスト リリース ウォーターフォールはこれを1回流して完成、アジャイルはこれを小さく切ってぐるぐる回すというイメージですが、「初めての個人アプリを最初にリリースするまで」という状況では、一番困るのは2の設
この記事は何か? この記事はスマホゲーム開発をしているプログラマーのぼくが、スマホゲームの変遷と求められてきたスキルを振り返り、2015年の今現在求められるスキルを考えます。 あくまでぼくの周りから感じたものなので、いけてるディベロッパーにいる人はもっと進んでいるのではないかと思います。 ちょっと長いので、結論だけを知りたい場合は下部のまとめだけご覧ください。 ぼくは誰か? ぼくはゲーム開発会社でスマホゲームを開発しているプログラマーです。 mobageやGREEのプラットフォームで、各社が自由にWEBブラウザゲームを公開できるようになった時からゲーム開発をしてきました。 WEB業界出身な人間で、スーパーなプログラマーではないことに注意してください。 WEBブラウザゲーム前期 「DeNAの怪盗ロワイヤル」「コナミのドラゴンコレクション」「Cygamesの進撃のバハムート」などのゲームが流行
本日、はてな教科書に新たにSwiftの教科書を加えました。先進的なプログラミング言語であるSwiftを学習するのに最適な教材です。 「はてな教科書」はもともと、およそ1週間でWebアプリケーション開発の基本を身につけるために、PerlやJavaScript、MySQLなどを用いて実際にWebアプリケーションを作ってみる教材として作られてきました。はてなサマーインターンシップや、はてなの入社時研修に利用されています。最初はWebアプリケーションのための教科書でしたが、はてなでは近年の多様なニーズにあわせて年々内容を更新してきました。 はてな教科書 はてなサマーインターン2015では新しく様々な内容が追加されましたが、今回はそのうちSwiftに関する部分を先行して公開します。昨日Appleが正式にリリースしたSwift 2を全面的に採用した教科書で、Appleプラットフォームアプリ開発の学習や
参考 2019/1/1現在の日本語ドキュメントをもとに再編成しています。 最新版は英文を確認ください。 In-App Purchaseプログラミングガイド 公式ドキュメント 失敗しない iOS In-App Purchase プログラミング iOS の アプリ内課金(In-App Purchase) 組込方法 Apple Pay In-App Purchaseについて StoreKitフレームワークを使用してアプリケーション内にストアを組み込む方法 販売できないもの 実物の商品やサービスを販売することはできない。 仮想通貨 ポルノ、誹謗、中傷、ギャンブルに関連するもの ギャンブルのシミュレー ションであれば問題なし。 販売できるもの 電子商品や電子サービス デジタルコンテンツ(電子書籍、雑誌、写真など) 機能プロダクト 機能のロック解除や拡張。 App内課金の種類 Consumable(消
公開2015.02.21 更新2017.12.03 仕事・技術 アプリ開発用のSwift対応のiOS開発本を意図せず3冊買うことになったので内容の比較と私の失敗について紹介したいと思います。 まずはiOS開発勉強用に購入した3冊についてですが、見事に初心者向け、中級者向け、上級者向けの3冊を購入した感じになったのでそれぞれの特長をふまえてご紹介します。 初心者はコレから!iPhoneアプリ開発「超」入門 初心者は絶対にこの本からはじめると良いと思います。 すべてを網羅的に、という本ではありませんが、それだけに必要なことに絞ってカラーで綺麗な図表を用いて書かれています。 難解になりがちなアプリ開発の本にも関わらず文章も非常にわかりやすく、著者の「絶対に挫折させない」という想いが随所に感じられる良書です。 とにかく他の2冊に比べてずば抜けてわかりやすい本で、「絶対に挫折しない」の名に恥じぬ素晴
それぞれのフェーズの詳細を書いておきます 見積フェーズ 見積り用のQ&A 見積フェーズでは発注側に企画書や画面イメージ、参考になる他アプリを提示してもらい見積金額を提示します。見積用の資料としてRFPがあれば曖昧な仕様にならずに見積もりを行うことも出来るかもしれませんが、発注側がRFPを用意してくれることは稀です。もし発注側が大手で契約を頻繁に行なっているようであればRFPを作成して頂くほうがスムーズに進みますとダメ元で言ってみるのも有効です。 そもそも、発注側はまずは規模感を知りたい、他社と比較したい事が多く、技術的に難しい場合があっても大きな工数や金額を出してしまうと話が進まなくなってしまうので、見積書には技術的に課題があるポイントや開発する上でのリスクを明示し、それを説明し工数・金額の数字の妥当性を理解してもらいましょう。またこの段階で仕様認識の齟齬がある場合も、上記のやりとりで早め
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く