http://peatix.com/event/121751/ での発表資料です
![情報共有 失敗あるある](https://cdn-ak-scissors.b.st-hatena.com/image/square/a99598caa2333abd4674b719fc3dade41720d5eb/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fcbfc83ef807d42238b1d6bce4e40fe0e%2Fslide_0.jpg%3F5481563)
GitHubのissueでタスクを管理しだすと最終的にかんばん形式でみたくなりますよね。 そんなときに便利なGitHubのissueをかんばん形式で表示してくれるサービス。 基本的にどれも機能にそこまで差異はないですが、課金体系などが微妙に違います。 Waffle.io GitHubのpublicリポジトリ、privateリポジトリなら無料で使える。 GitHub Enterpriseで利用する場合には有料なようです。 Waffle.io · Work Better on GitHub Issues HuBoard GitHubのpublicリポジトリなら無料、privateリポジトリは有料です。 但しソースコードが公開されているので、自分でホスティングすれば無料です。 HuBoard - GitHub issues made awesome. Zube publicリポジトリは無料。 p
「初アプリ開発でサラリーマンの給料超え。独立したが現在はギリギリ生活できるレベル」戦国時代を生きる地方のアプリ開発者に聞く。 今回は地方でアプリをつくって暮らしている、2名のアプリ開発者さんにお話を伺いました。アプリ業界が「だんだん厳しくなってきている」という声も。 1.北海道でアプリ開発をしているアソボックスさん ※株式会社アソボックス 代表取締役 赤羽 駿人さん アソボックスについて教えて下さい。 北海道でアプリ開発をしています。現在は法人化していますが、夫婦でアプリをつくっているので、実態としては「個人開発」に近いです。私がプログラミングで、妻は企画を担当しています。 とくに北海道にいて、不自由なことはないですね。不便なのは「amazonから荷物が届くのがちょっと遅い」というくらいでしょうか。 夫婦でアプリをつくっていて、メリットはありますか? 夫婦で仕事をするというのは、「仕事が家
20億行のコードを保存し、毎日4万5000回のコミットを発行しているGoogleが、単一のリポジトリで全社のソースコードを管理している理由 Googleは検索サービスやGoogle Apps、Google Cloud Platformなど巨大なサービスを多数運営しています。その同社は、20億行にもおよぶソースコードの管理をサービスやプロジェクトごとに分けず、すべて単一のリポジトリで管理しているそうです。 先週9月14日にサンノゼで開催されたイベント「@Scale」で、Googleによるセッション「The Motivation for a Monolithic Codebase: Why Google Stores Billions of Lines of Code in a Single Repsitory」(単一コードベースへの取り組み:なぜGoogleは単一リポジトリに数十億行ものコー
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
会員事業部*1の小川(@conceal_rs)です。 会員事業部ではプレミアムサービスの価値を向上させるために、日々機能改善や新しい機能やサービスの開発をしています。今回はサービス開発をするときにエンジニアがどういう役割を果たすといいかについて、私なりの経験からの話をしたいと思います。 サービス開発とは サービス開発とはユーザのみなさんに、アプリやウェブを通じて何らかの価値を提供することだと考えています。価値と言ってもいろいろなものや形態があり、Webサービスというとだいたいがツールぽいものを想像しますし、最近だとゲーミフィケーションを使った脳トレサービスなどもあります。また既存のサービスに新しい機能や体験を追加して価値を届けるということもサービス開発です。私が所属している会員事業部はプレミアムサービスを利用して頂いているユーザのみなさんに新しい価値を提供すべく、日々業務に勤しんでいます。
伊藤直也氏が語る、モダンな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などのフロントエンドにまで共通する考え方とは何か、示唆に富むその内容をダイジェストで紹介します。 モダ
(編注:2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
<前編のあらすじと後編のお話> 本企画のホストである伊藤直也(以下「naoya」)と、『フリークアウト』執行役員であり『ヤフー』のフェロー/名誉黒帯でもある明石信之(以下「明石」)。意外にも初顔合わせとなる二人だったが、Web業界を長年リードし続けてきたという共通項もあり、酒肴を愉しみながらのマネジメント談義は大いに盛り上がりを見せた。明石氏が『フリークアウト』に参画後、色を組織名にするなど、破天荒とも思える組織マネジメントの実例も披露され、その深い洞察にもとづく一手に、naoya氏は大いに感銘を受けるのだった――。 ⇒【前編】の記事はこちら 【後編】となる今回は、明石氏の『フリークアウト』における取り組みを掘り下げていくことで、そのマネジメント論の神髄に迫っていきます。大の魚好きという点でも一致する二人の会話は、酒の力もあってますますヒートアップしていきます。 — naoya:チーム名の
ここ八か月くらいずっとLidnaというウェブアプリケーションを作っていた。それをやっと今日、リリースできた。https://linda-tokyo.herokuapp.com/ (ChromeまたはiOSの場合はSafariでお楽しみください)パソコン、Android(マイクと音声編集対応)の場合はマイクが音声をキャッチしている間、Android(マイクと音声編集非対応)、iOSの場合は端末を振っている間、真ん中にある円が拡大していく。そのインプットが終わると、画像を使った簡単なアニメーションが流れる。 というのを同僚のデザイナー飯山さんと一緒にずっと作っていた。 https://www.facebook.com/yoshiyuki.iiyama.5ちなみにLindaという名前は、最初に飯山さんと企画会議をやったのが、リトルリンダという、外苑前にあるギャラリーカフェだったからだ。http
photo by crdotx ソニックガーデンでは頻繁に「Keep=よかったこと」「Problem=悪かったこと」「Try=次に試すこと」の3つのフレームワークで考える「KPT」による ふりかえり を実施しています。 継続的に個人・組織をカイゼンしていくためのフレームワークなので、問題を炙りだしてその解決策を考え次へのチャレンジを実践していくところ(ProblemとTry)にフォーカスされがちですが、今回はあまり注目されていないKeepを少し掘り下げてみます。 ここからは毎週末に実施している弟子とのふりかえりを例に話をすすめていきます。 KeepがなぜKeepなのか? よくあるふりかえりのKeepに 予定通りタスクを進められた 意識を変えれたのでうまくいくようになった などが挙がります。 うまくいったことは素晴らしいことですね。良いことなのでいっぱい褒めてあげましょう! ただ、褒めるだけ
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
スクレイピングとは、ウェブページから情報を取り出す処理を指します。そのためのプログラムやツールが存在します。 さて、ここで立場を変えて、情報を取り出されてしまうウェブサイト側の立場になって考えてみますと、スクレイピングはあまりうれしくない存在であることがわかります。 ニュースサイトは、コストと時間をかけて書いた記事をコピーされ転載されてしまう。 オンラインショップは、ライバルの他社に商品リスト、価格、在庫の変化、顧客の評価等を把握されてしまう。 インターネット広告は、自社が出している/仲介している広告の種類と量をライバルに把握されてしまう。 他社の情報は把握したいが、自社の情報は把握されたくないと考えるのは自然なことのようです。その証拠として、スクレイピングの普及に合わせて、自分のサイトがスクレイピングされることを防ぐための「アンチスクレイピングサービス」なるものが世に広まりつつある点を挙
背景 APIドキュメントを書くのが楽になるツールまとめ - Qiita iodocsで便利なREST APIドキュメントを作成する - Qiita これまでずっとREST APIドキュメントをwiki上で管理していて、重たいページ上で特殊記法使ったり、スタイルの調整に時間を取られるのが辛かった。そこで良さげなドキュメントツールを色々調べてたんだけど、最終的にapiary.ioが一番良さそうという結論になってきた。 このサービスの主な特徴。 markdown記法でAPIドキュメントを記述できる ドキュメントの生成と同時にAPIのモックサーバを用意してくれる サインアップから5分くらいあればドキュメント公開できる。ドキュメントのホスト先を気にしなくてもいい。 特にドキュメントと一緒にモックを作ってくれるのは他にはないポイントでかなり便利。 使ってみる サインアップはGithubアカウントで h
Qiita:Team 最高!!! ということで,前回のエントリーでは,プロダクトに Qiita:Team を提案・導入して,1週間使ってみました的な話を書いたけど,それからさらに1週間たったので,Qiita:Team KPT を企画してやってみた. Qiita:Team KPT KPT で挙がった項目をザックリとまとめて紹介しまーす. Keep 全体的に Qiita:Team を導入したことで,コラボレーションが活性化していて,非常に良いという声が多かった.提案してホント良かった! 業務的な暗黙知が共有されてきた 自己紹介や日報が面白くて会話が生まれる アイデアを書くハードルが低い レスポンスが早くなった Problem やっぱり,一部のメンバーが投稿しまくってて,他のメンバーは READ ONLY みたいな状況ではあるので,そこをどう KAIZEN していくかっていうところがポイントな気
はじめに こんにちは、モバイルファースト室の@y_310です。 部署名からもお分かりの通りクックパッドでは今年からスマートフォンアプリの開発に特に力を入れて取り組んできました。 実際に昨年と比べて開発体制が大きく変化しています。以前はアプリ開発専門のエンジニアのみで開発していたものを、サーバサイドエンジニアもアプリ開発を学び、自分が所属する部署に必要な機能をアプリに実装するようになりました。 そのため、以前は2、3人のチームでの開発だったものが、現在は多い時には複数の部署にまたがって10人ほどのエンジニアが1つのアプリにコミットする状況になりました。 そのような環境の変化によりアプリの品質維持が大きな課題となり、この半年間継続的に品質改善に取り組んできました。今回はその改善プロセスについてご紹介したいと思います。 課題 取り組みを始める前は、様々な部分で課題がありました。 具体例を上げると
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
こんにちは。技術部の吉川です。 今回はクックパッドの開発環境構成、特に開発用データベースの構成についてご紹介します。 開発環境の構成 クックパッドのシステム環境は以下のようなフェイズに分かれています。 ※ これはcookpad.comの構成で、サブシステムや個別のサービスはその規模や特性に応じて構成が異なります。 development 開発者が実際に開発を行う環境です。クックパッドでは仮想環境は用いず、手元のマシンでRailsアプリケーションを動かして開発を行っています。 データベースはローカルではなく、開発者全体で共通の開発用データベースに接続しています。 test 手元でテストを実行する場合は、ローカルマシンのデータベースを利用します。CI(rrrspec)などの場合も同様で、テスト実行サーバーのデータベースが利用されます。 staging stagingといえば準本番環境として、本
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く