ブックマークしました ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください Twitterで共有
昨日からのドワンゴ退職エントリからの現職エントリの流れに思うところがあり書かせてきただく。 はじめに断っておくが、私は件の現職エントリで言う所の「営業」(非エンジニアの企画職)にあたる職種である。 その視点からのエントリであり、エンジニアの視点ではないことをまずご了承いただきたい。 まず、私自身の話をする。 私は数年前に新卒でドワンゴに入社した。 アプリの企画がしたいと意気揚々と面接を受け、合格し、無事ドワンゴという当時人気絶頂のIT企業に入ることができた。 そして無事研修が終わったのち、自分が配属されたのは「イベント事業」であった。 最初の仕事はテントを運んで組み立てることだった。 その後イベントや生放送に関わってきたが、裁量労働制とは言え、コンテンツを作る側であるが故に、ほかの一般企業との打ち合わせややりとりなどで朝から晩まで作業や打ち合わせが詰まっており、まともに裁量などない状態であ
ニコニコカレンダーって?ニコニコカレンダーは(以下ニコカレ)、公式サイトの説明は次のようになっています。 ニコニコカレンダーとは、チームのムード、メンバーの気持ちやヤル気を見える化するツールです。 簡単に説明してしまえば、各メンバーが毎日退社直前に、その日の自分の気持ちをシールとして貼るというものです。貼るシールは一般的にはその日の気分をGood、Normal、Badの3種類に色分けをして貼りだします。チームによっては基本の3状態に加えてSad(悲しい)などと種類を増やしている場合もあります。公式サイトでは、黄はスマイリーのイメージでGood、赤がNormal、青がBadとなっています。(注:筆者がニコニコカレンダーを海外に紹介した時に、色についての感覚が違うというフィードバックをもらったことを思い出します。海外からのフィードバックでは、赤はバッドイメージでした。) シールにはその日の気分
ローカル環境でISUCON9予選のアプリケーションとベンチマーカーはGoとMySQLとDockerがあれば、Macなどローカル環境で動かすことができます。 ソースコードの取得まず、ソースコード一式をもってきます $ go get -d github.com/isucon/isucon9-qualify $ cd $GOPATH/src/github.com/isucon/isucon9-qualify 初期データの作成ベンチマーカー、アプリケーション両方が使う初期データの生成をします。 $ cd initial-data $ make makeを実行するとDocker コンテナの中で初期データの作成を行い、initial-data/result に結果が出力され、webapp/sql 以下へのコピーも行われます。 パスワードの生成があるため、時間がかかります。 画像データの展開初期データの
3行で シンプル/ミニマルな Lambda のデプロイツール lambroll を書いてるよ Lambda API 以外は極力触らないやつです 既存 function の移行も簡単です 開発の経緯 AWS Lambda を管理、デプロイするのに数年来 Apex を使っていましたが、最近更新がないと思っていたら案の定というか、残念ながら No longer maintained となってしまいました。 で、代替を探したのですが… Lambda管理、Apexがお亡くなりになってServerlessかSAMになるんだけど、本当は関数だけdeployできればよくて(IAMとか関連リソースはTerraformでやるんで)、それなら裏でCloudFormationが動くようなのじゃないシンプルなのがいいなあ。作れば作れるけどデプロイツールばっかり書くことになるな…— fujiwara (@fujiwa
2019/10/31 を持って8年間勤めてきたドワンゴを退職しました。 ドワンゴ退職エントリの旬は過ぎているよう気もしますし、こんな何年も放置していたブログで今更何をと思わなくもないですが、なんとなく自分の気持ちの整理もかねて適当に綴ってみようと思います。 何をやってきたか 各種のゲームデバイス、PS Vita, Wii U, 3DS, Nintendo Switch 上でのニコニコプレイヤーの実装をずっとやってきていました。 それぞれのデバイスでのシステム部分というか、ゲームデバイス上での非ゲームアプリケーションフレームワーク、そんなものを作り続けてきた感じです。 これらのニコニコ動画クライアントは、私の手を完全に離れてしまうことになります。 もっとできることはたくさんあるし、改善すべき点もたくさんある。愛用してくれているユーザーに対して自分が出来るはずのすべてを提供することができなかっ
2019/10/31(金)に開催されたEngineering Organization Festival 2019 で @t_wada さんの「質とスピード」という講演を聞き、とても感銘を受けたのでメモ。 品質とスピードはトレード・オフの関係にある。どちらを優先するか?要バランスだ。 そう思っていた時期が私にもありました。 けど、そんなことはなかった! ■追記 個人的な捉え方としては、 プロダクトを漸進的に成長させ、仮説検証ループするスピード上げようとすると、犠牲にした保守性があとで(意外とはやく1ヶ月後には)足枷になる。 保守性(テスト容易性、理解容易性、変更容易性)が低いとリードタイムが延びてスピードがどんどん落ちていくループをまわせなくなる。ってことかな、と思う。 スピードを上げようとしたのに、意外とはやくスピードが上がらなくなるジレンマ。 @t_wadaさんのスライド 素敵なグラレ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く