XP 祭り 2016
概要 最近いろいろな方(社内、社外含め)に、エンジニアチームどうですか?良くなってますか?という質問を頂きます naoya さんってどうなんですか?やっぱりすごいですか?とも その度に「良くなってますよー」と返事をするのですが、肌感としてはあるもののしっかり言語化できていない そこで、naoya さんがCTOとして今年の春に一休に来てからをちょっと振り返ってみた 振り返ってみるとたった4ヶ月ということに驚いています :eyes: 良くなったと感じていること サービス開発の体制 技術基盤への投資 採用活動 情シスの整備 エンジニアの働く環境 それぞれについて サービス開発の体制 抱えていた課題 マーケティングとエンジニアとの間のコミュニケーションが上手くいかず、開発速度やサービスの意思決定のボトルネックになっていることがあった みんなで話して決める等、それぞれの役割が曖昧なままで開発を進める
2019年9月17日更新 フリーランスWebエンジニアとして自由に働き、お金を今よりも稼ぎたいですよね。 Webエンジニアがフリーランスになる時によくある悩みが「技術レベルを上げながら、収入を上げられるのか」ということと「フリーランスになったらちゃんと稼げるのか」ということですね。 せっかくフリーランスになっても低単価な案件しか見つからなかったり、案件探しが大変で疲れてしてしまうと「会社員の方がよかった...」となりかねません。 ぶっちゃけこの業界では、エンジニアは引く手あまたの状態です。良いWebエンジニアがいればフリーランスだろうと正社員だろうとバイトだろうと採用したいのが現状。案件に困ることはないかもしれませんが、効率よく良い案件を見つけられるかどうかで年収が数百万変わってくるんです。 ちなみに、フリーランスWebエンジニアが使えるツールを知っているかどうかでも年収が100万円くらい
note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける(当たりのつけかたにもいろいろあるのだが後述) 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う(エディタの undo でせっかく書いたコードを失わないため) 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ
From 2014 to 2021, Kite was a startup using AI to help developers write code. We have stopped working on Kite, and are no longer supporting the Kite software. Thank you to everyone who used our product, and thank you to our team members and investors who made this journey possible. Our journey at Kite While we built next-generation experiences for developers, our business failed in two important w
リンク http://mosa-siru.hatenablog.com/ テストなんか書かなくて良い 僕の考えるサービス開発の肝 - mosa_siru’s blog 世の中は一周まわってエンジニアリングの手法に溢れている。 テストを書け、ドキュメントを書いて冗長化しろ、コミットはわかりやすく、コーディング規約が、安定性が─── でも、それって本質なんだろうか? 新規サービスを作る際に肝だと思っていることをまとめてみた。 おことわり 以下は少人数で"普通"のアプリやWebサービスを自社で新規開発するときのことを想定しています。大人数で重厚なソシャゲを作るとか、ガチガチの金融系サービスを作るとか、コンシューマーゲーム開発とか、個人で好きなものを作るとか、受託とかは全く想定
「技術顧問」という言葉をご存じだろうか。自身のシステム開発の経験を生かし、契約した企業に対して開発に関するアドバイスを行う職業だ。この言葉が注目されるきっかけになったのが、Web業界でその名を知らない人はいない有名エンジニアの伊藤直也氏。同氏は、Webサイト改善サービスを提供している「Kaizen Platform」、宿泊予約サービスの「一休」、就活サイトなどを運営する「ハウテレビジョン」、求人情報の「リクルートジョブズ」といった企業の技術顧問を務めている。同氏に技術顧問という役割の本質を聞いた。 最初に技術顧問になった企業を教えてほしい。 最初に技術顧問になったのは、求人サイトなどを運営する「じげん」だ。2012年頭から1年間、コンサルティングを行った。具体的には、1週間か2週間に1回、1~2時間のミーティングを実施した。これで本当に何か変わるのかイメージできなかったが、たったこれだけで
私が新規WEBサービス立ち上げ時に取り組んだ内容についてWEBエンジニア向けにまとめた記事です。 例えばNginxの設定でHTTPヘッダーが正しく設定されているかを確認できるGoogleDevelopers PageSpeed Insights を知っていると大変有利です。もちろんPageSpeed Insightsを知らなくてもWEBサービスを公開・運用可能ですがユーザに意図せず不利益を与えていたり、知らず知らずのうちにモバイルフレンドリーでないとGoogleから検索ペナルティを加えられている可能性があります。この記事は独りで新規WEBサービスを立ち上げた際のノウハウと取り組んだ内容について記述しています。 1. 概要(5行くらいで) スマホ対応は必須。トラフィックの50%はスマホから発生する。 速度は武器!速いサイトはそれだけで価値がある。 SEOの内部対策は内部リンク整備とPageS
2015.12.17 ITニュース GoogleでChromeの開発などに携わったエンジニアである及川卓也氏がこのほど、技術情報共有サービス『Qiita』などを運営するIncrementsに加わった。 Microsoft、Googleと世界を舞台に活躍してきた大物技術者が、転職先として社員わずか13人のスタートアップを選んだことは、少なくない人に驚きをもって受け止められた。詳細はまだ明かせないということだが、及川氏をプロダクトマネジャーに迎えたIncrementsは、「Qiita3.0」とも呼ぶべき未来構想を描いているという。 (写真左から)この11月にIncrementsに加わった及川卓也氏と、代表取締役社長の海野弘成氏 2012年の会社創業とともにローンチした『Qiita』は、直後に1度ピボットを経験した後は、現在の「ノウハウ共有サイト」として右肩上がりの成長を遂げてきた。現在では月間
クックパッド編集室の加々美です。 現在、食や暮らしのトレンドを発信するメディアであるクックパッドニュースの開発に携わっています。 「総合職で入社した新卒がクックパッドでエンジニアになるまで」 というエントリを投稿した2015新卒の土谷と同様に、2014年に新卒として入社後、総合職から研修を経てエンジニアへと転向しました。 今回は、クックパッドニュースの管理機能の改善を行う際に注意した点についてお話します。 自分がその管理ツールを使う人になる 事業体制の変化もあり、現状のクックパッドニュースの管理画面に関して、いくつかの運用上の問題点が指摘されており、その改善を行いました。 管理画面改善の進め方としては 「現状の業務フローの把握」「問題点の把握」「理想の管理画面の設計」 という基本的な手順で取り組みました。 現状把握と問題点洗い出しの方法としてまず思いつくのはヒアリング中心で進めていく方法で
2006年にリリースされ、今年で10年目を迎えた日程調整ツール「調整さん」。イベントの幹事はメンバーにURLを送るだけで、出欠確認や日程調整が行えるサービスだ。20代以上のネットユーザーなら一度は利用したことがあるのではないだろうか。無料で簡単に使えて、当たり前のようにインターネット上に存在していた調整さんだが、2015年に入ってから密かに、驚くべき成長を遂げていた。 調整さんのMAU(Month Active User、月間利用者数)は2014年の7月時点で50万人ほどだった。これが、2015年3月には100万人、9月には200万人にまで伸びているのだ。シンプルな機能しか持たない古株のWebサービスに、この1年で一体何が起きたのだろうか。調整さんの開発チームを率いるリクルートホールディングス・MTL(メディアテクノロジーラボ)の山本一誠さんにお話を伺った。 手付かずで5年以上放置されてい
(訳注:2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注:2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳: プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション:なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest
同じTシャツを着ているのは決断の回数を減らすため Facebook社員・チャールズ氏(以下、チャールズ):それでは会場のみなさんが質問を考えている間に、ひとつ質問を読み上げましょう。イタリアのソレントから、アントニオさんの質問です。 「どうしてあなたは毎日同じTシャツを着ているのですか? ひょっとして1枚しか持っていないのですか?」 (会場笑) マーク・ザッカーバーグ氏(以下、マーク):実は同じものを何枚も持っています(笑)。この話はシェリルにしてもらいましょうか。 シェリル・サンドバーグ氏(以下、シェリル):7年間マークと一緒に働いていますが、私は聞かれるたびに「マークはあのTシャツをたくさん持っているのよ」と何度も答えました(笑)。 マーク:ありがとう、シェリル(笑)。これは単純なようでいて、奥が深い質問です。コミュニティにおいて、どのように責務を果たすべきだと考えているか、ということ
こんにちは!おおはしりきたけです。パート7の今回は、アジャイル開発で受託開発を行ったり、アジャイルのコーチングやidobataというグループチャットアプリなどの開発も行っている永和システムマネジメントのアジャイル事業部にお邪魔しました。インタビューに答えてくださったのは、Idobataエンジニアの寺田さんと、受託開発でエンジニアをやられている松島さんです。 突撃!隣の開発環境とは 技術事例やノウハウなどは、ブログや勉強会などで共有されることが多いと思います。しかし、各社の開発環境や開発体制などは意外と共有されていないこと多いと思います。ノウハウの流出になるかもしれませんが、それ以上に、より良い開発を目指している会社さん同士で情報交換を行い、良いチーム、良いプロダクトを作っていくという志の会社さんの為の情報共有のための企画になります。開発環境や開発体制なども技術領域によっても変わってくると思
日報を継続する方法があったら教えて欲しい、id:Songmu です。最近はMackerelチームのディレクター兼デベロッパーをやっています。 リモートワークと情報共有 Mackerelは、8名程度で開発しており、開発メンバーは京都・東京・愛知の3拠点に散らばっており、リモート勤務も各自の裁量で行えるようになっています。 リモートワークにおいては細かい情報共有をなるべく労力をかけずに行うことが必要になりますが、そのために以下のようなツールを利用しています。 開発手法としてスクラムを採用 Hatena::Groupによる情報共有 Github/Zenhubを用いたプロジェクト管理 Slackでのチャットコミュニケーション Zoomによるオンラインミーティング Mackerelチームでは、Hatena::Group上で日報を書くことを推奨しており、今回はその話です。 Mackerelチームの一日
主張 ソフトウェア開発prjがなかなかアジャイルにならないのはなぜかなぁと考えてみた。 昨今、エンジニアにおいては、知識としての共有の機会も増えているし、実際に経験済み、習慣化済みになってきているように思う。要は「しっくり」くることが多いのだと思う。 しかしながら、現実のprjが経験型のアプローチ(アジャイル)を取ることはまだまだ少ない。この要因として、エンジニアと協業する他のメンバー、あるいはprjの利害関係者(組織の上層部を含む)が予測型の進め方を望むからではないか、と感じている。 というわけで、エンジニアと仕事をするエンジニア以外の人に伝えたいと思い、書いてみる。そのためにはおそらく、アジャイル開発、スクラムのプラクティスがどうこう、というよりは、プロジェクトマネジメントの世界観として語る方がよいかというのが本稿。エンジニアとして、抽象的な「しっくり」の言語化にもなればよいと思う。最
─ 問題1 ─ data.csvファイルには、5人のプレイヤー(Alice, Bob, Jimmy, Kent, Ross)が二種類のゲーム(gameA, gameB)をプレイした結果が次のような形で格納されている。各ゲームの平均点を求めよ。 data.csv player,gameA,gameB Alice,84.0,79.5 Bob,20.0,56.5 Jimmy,80.0,31.0 Kent,90.5,15.5 Ross,68.0,33.0 data = File.read('data.csv') headers, *scores = data.lines.map { |line| line.chomp.split(',') } scores # => [["Alice", "84.0", "79.5"], ["Bob", "20.0", "56.5"], ["Jimmy", "80
電卓か。そうだ電卓だ。なぜ電卓か。欲しいのだ。なぜ電卓が欲しいのか。いや電卓が欲しいわけじゃない。じゃあ何なんだ。この電卓だから欲しいのだ。 カシオの関数電卓『CLASSWIZ』だ。正確にいえば、数学自然表示関数電卓だ。電卓なのでそこまで高くない。最上位機種『fx-JP900』も5700円前後だ。 恥ずかしながら三角関数も指数、対数も関係ない人生を歩んできた。今後もおよそ関係するとは思えない。思えないのだが、異様に欲しいのだ、これが。 実はこの電卓、電卓の歴史に新たな1ページを刻んだと言えるほど、進化を遂げた1台なのだ。電卓が進化なんてするのか。進化したらしいのだ。機能だけ説明しても理解しづらいと思うので、ぜひとも開発ストーリーをお聞きいただきたい。 わたしのような文系人間もトリコにした、魂こもった計算器屋の話である。 入試に電卓を使うのは当たり前 第一章。そもそも関数電卓とはいつ誰が使っ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く