「プログラミングの常識」を時々見直す必要性について｜Rui Ueyama
自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindowsの初期の頃に設計されたデータ構造には、メモリをバイト単位ででもいいから節約したいという意図の痕跡がいまでも多く見受けられる。DRAMの次に速い記憶装置はHDDだったので、メモリが足りなくなればHDDにデータを保存せざるを得ないのだが、DRAMとHDDのランダムアクセスの速度差は、机の上の本の開いているページを見るのと、その本をAmazonで注文して到着するのを待つのと同じくらいのスケールで違うの
Alignment and Autonomyな組織づくり - クックパッド開発者ブログ
はじめに サービス開発部部長の勝間(@ryo_katsuma)です。 普段は、エンジニア、デザイナ、ディレクターを含む様々な職種のメンバーのマネジメントを行っています。 今日は、私の部署における組織づくりの取り組みについてお話いたします。 背景 現在、私が所属しているサービス開発部は、年初の組織改編時に発足しました。レシピをさがす、のせるなどを含むレシピサービス、いわゆる「クックパッド」において、広告事業、会員事業など事業にまつわる開発以外のユーザーに触れる部分の開発を行っています。 クックパッドはPCウェブ、モバイルウェブ、モバイルアプリといくつかのプラットフォームをサポートしていますが、ここ最近の部署での開発はモバイルアプリを中心に行っています。 メンバーの数も他の部署と比較しても多く、学生アルバイトも含めて約45人が所属し、役割ごとに分割されたグループにも10人前後のメンバーが配置さ
はてなにおけるテックリード、そしてサービスプラットフォームチームのテックリードについて - Hatena Developer Blog
CTOのid:motemenです。 はてなでは一年ほど前から、ひとつの開発チームに一人、テックリードと呼ばれるエンジニアを置いています。テックリードという役割については、以下の有名な記事で語られているものからそれほどかけ離れてはいないと思いますが、組織によって微妙に異なる部分もあるはずですので、はてなの事情を交え紹介します。 テックリードは普段の仕事においては他のエンジニアと変わらず、会社組織上の上下関係があるわけでもありませんが、形式的には、テックリードにはチームの技術的な窓口となってもらっています。たとえば利用しているソフトウェアの脆弱性対応を全社的に行わなければならないときなど、技術的なレポートラインにおいてプロダクトに対する対応をまとめ、実施の報告を行う、というような具合です。 また、テックリードには、ディレクターなど非エンジニアとエンジニアとの橋渡し役になることも期待しています。
レガシーコードの触り方 / Working Effectively with Legacy Code
オープンセミナー2017@岡山
研究と開発のはざま - でかいチーズをベーグルする
博士を取ってからの3年間はアカデミックで仕事をしていたけど、4月から民間企業に移ることにした。転職するかどうかそうとう悩んだわけだけど、その時に研究についていろいろと考えたのでちょっと書いてみたい。 工学では研究と開発の違いなんて無い 誰もが納得するような明確な違いは無いと思う。あったら教えて欲しい。 実際、ほとんどの研究（論文）が何かを開発しているし、それが世の中の役に立たないと評価されない。逆に、ほとんどのプロダクトには新規性（もしくは他のプロダクトとの差異）がある。確かに、工学において研究と呼ばれるものは開発と呼ばれるものより平均的には基礎的なことをやっているとは思うけど、とはいえ明確な線引は出来ない。 研究を神格化しすぎる風潮があるんじゃないかな。 「研究者です」というと「すごい！」と言われることがよくある。そう言ってもらえるのは嬉しいけど、べつにすごくないよ。99%の研究者は世の
サービス成功のためにチーム開発でエンジニアができること - オールアバウトTech Blog
こんにちは、オールアバウトの筋トレエンジニア芸人の@musclemikiyaです。 普段はCafeSnapというiOS/Andorid向けのネイティブアプリの開発を行っています。 このアプリは大手チェーン以外の個性光るオシャレカフェの情報が満載なアプリですので、ぜひ使ってみてください。 さて、今回はサービスの成功可能性を高めるために、エンジニアがどのようにサービス開発に関わっていくかです。 エンジニアのサービスへの関わり方は様々だと思いますが、今回はよりサービス運営に近い立場のエンジニア（チーム）を想定しています。 ※チームの規模やフェーズによって当てはまらないこともあるので、一意見として参考にしていただければと思います。 コードを書く時間の最大化 ≠ サービスの成功 サービス開発をする上でエンジニアの重要な役割は、コードを書いて機能を実装することだと思います。 そう考えると、コードを書く
ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策 - メソッド屋のブログ
マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。 それは、「アメリカのエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。 私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた１つの仮説について共有したいと思います。 気軽に「聞けないこと」が生産性を阻害しているのでは？ 以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それ
あなたのチームの「いい人」は機能していますか？
近年増え始めている xOps についてのスライドです。RevOps、DataOps、DesignOps、Customer Ops などが生まれてきている背景としてのサブスクリプション化と SaaS について、そして xOps を実現するうえで必要なフローの概念と目標設定について書いています。またこうした流れの中でエンジニアが貢献できる部分が多くなっているのでは、と考えています。
【後編】大先輩のフリークアウトCTOが語ってくれた、マネジメントの深くてイイ話
＜前編のあらすじと後編のお話＞ 本企画のホストである伊藤直也（以下「naoya」）と、『フリークアウト』執行役員であり『ヤフー』のフェロー／名誉黒帯でもある明石信之（以下「明石」）。意外にも初顔合わせとなる二人だったが、Web業界を長年リードし続けてきたという共通項もあり、酒肴を愉しみながらのマネジメント談義は大いに盛り上がりを見せた。明石氏が『フリークアウト』に参画後、色を組織名にするなど、破天荒とも思える組織マネジメントの実例も披露され、その深い洞察にもとづく一手に、naoya氏は大いに感銘を受けるのだった――。 ⇒【前編】の記事はこちら 【後編】となる今回は、明石氏の『フリークアウト』における取り組みを掘り下げていくことで、そのマネジメント論の神髄に迫っていきます。大の魚好きという点でも一致する二人の会話は、酒の力もあってますますヒートアップしていきます。 — naoya：チーム名の
ソフトウェアエンジニアがたどる成長過程と失敗の行きつく先 | POSTD
これからご紹介する私の試みはなかなか難しい側面があり、物議をかもすかもしれません。また、お見せするのは初めてなので完璧とは言えないかもしれません。私はソフトウェアエンジニアのスキルとその影響力を評価するシステムを開発しようとしています。少なくとも、プログラマが成長していく理想的な成長過程を大まかに描いてみようと思います。評価スコアは0.0から3.0まであり、それぞれの数字は専門能力を開発していく際の出発点を表しています。 このシステムは主にビジネスの観点から見た、ソフトウェア業界が求めるものに基づく 実務的な スケールです。数学的な才能や高速アルゴリズムを書く能力、Linuxカーネルの内部構造に関するプログラマの理解の深さなどを評価するスケールではありません。もちろんこうした能力は重要ですし、通常、エンジニアのスキルとともに伸びていく能力ですが、私のシステムが焦点を当てたいのはそこではあり
アプリのリリースに必要な「引き算担当」について - @hitoshi annex on hatena
起業してアプリを出す。 一言で言ってしまえば簡単なんですけど、最初のそのアプリリリースの時に失敗する人が少なくない気がします。 僕の観測範囲だけでも、独立してアプリを出そうとして開発に失敗、「作り直し→リリース延期」となるケースを定期的に目撃しますので、それなりにそういう失敗をする人はいるんじゃないでしょうか。これが20代の若手が失敗したというならまだ分かるんですが、経営者としてすでに十分な実績のある、僕自身も尊敬するような方がその陥穽に陥ったりしていますので、これはもう能力とか才能の問題でなくて、むしろ「知識」の問題なんじゃないかと思うんですね。 そういう僕も、kiznaというアプリを出そうとして落とし穴にはまってしまい、結局日の目を見なかったという苦い経験をしていますので、こういう経験はちゃんと共有して、無駄な犠牲者が出ないようにすべきだと思うわけです。 というわけで、初めてアプリを出
はてなMackerelチームの開発フロー（スクラム、リモート）について話しました #nanapi_study #hatenatech - 詩と創作・思索のひろば
nanapi勉強会 vol4 - 【nanapi x はてな】はてなとnanapiの開発フロー - nanapi勉強会 | Doorkeeper 【nanapi x はてな】はてなとnanapiの開発フロー in Kyoto - connpass nanapi さんとはてなで開催した勉強会に登壇し、東京・京都で Mackerel チームの開発フローについて話してきました。自慢できるようなカッコイイことをやっているわけではないけれど、今こんな風に頑張っています、ということをお話したつもりです。 Workflow at Hatena Mackerel Team // Speaker Deck チームみんなで勉強する スクラムの導入時もリモートワーク開始時にも、チームメンバーには何冊か本を読んで予習しておいてもらいました。そうすることでチームメンバー全員が同じだけの知識を持って（全員その道に関し
Ameba流 scrumを浸透させていく方法
2014年3月の発表資料 2014年7月の資料 => http://www.slideshare.net/hiroosak/ca-36830962Read less
(情報系の)大学の学生はとても貴重な経験をしていることに気づかず、情報系でないプログラマー(僕)は情報系の学問的知識を、いつか求めるということ - nobkzのブログ
どもです、nobkzです。昔からずっと考えていることを、うだうだ書きます。 「Prologなんて何でやるんだ!!!」 とある情報系の学生のつぶやきでした。僕は衝撃を受けました。 情報系の人間じゃない僕 ぼくは、福岡のIT系の勉強会に足をよく運び、また主催として開催したりしています。Technical RockstarsにCTOとして就任し、FLOWer言語をTechnical Rockstarsで開発しています。そしていまでは近日中に公開予定のBaaSを開発中であって、LispやHaskell、Prologなどを書いてたりしています。一日中プログラミングの事を考えて生活しています。 そのせいか、他人にはどうも僕が完全に情報系の人間の様に見られるようです。そして、大学では情報系の学部なんだろうと、小さいころからやって来たのだろうと。 しかし、実際は違うのです。僕は九州大学芸術工学部音響設計学
Javaを使うメリットはありますか？ はい、それはもちろんあるに決まってます！ - ブログなんだよもん
/.Jに聞け：Javaを使うメリットは？ | スラッシュドット・ジャパン デベロッパー え、ありますよね？ Webアプリに限っても。 というか、上げてるデメリットが現代的じゃないなぁ... 個人的には少数精鋭チームを作れてないならJavaはかなり有りな選択だと思っています。 ※ Java使ってるメンバーがスキルが低いのではなく、LL系で高品質なものを作るのにスキルが必要で、例えスキルがあっても多人数開発にはあまり向かない、という意図 というわけで、自分が思うLL系言語ではなく、JavaでWebアプリを開発するメリットを書いてみます。 静的型づけ言語 HaskellとかOCamlとかScalaとか、その辺の超強力な型付け言語から見ると弱いですが、多くのLLと違い静的型付けな事が特徴です。 これは型というメタ情報を言語仕様に明確に取り込んでいるということです。以下のメリットがあります。 人間が
高速にドッグフードを食べる方法 - hitode909の日記
はてなエンジニアブロガー祭りで「高速にドッグフードを食べる方法」という題で発表してきた． 箸でドッグフード食べるパフォーマンスの話ではなくて，もとはマイクロソフト用語である，Eat your own dog food，自社製品を使ってより良くしよう，みたいなほうの話．はてなブログ開発しながら毎日使うとか，思い付きで作ってるわけではなくて，事実や根拠にもとづいて作ってるとか，安全に作るための仕組みとか，そういう話． 普段の勉強会では僕は主に3分くらいのLTをしていて，20分も話したことなかった．資料ぜんぜんできなくて，Keynote見るだけで疲弊してた．急に長くていい話できるはずないと思って，LT5連発という形にして，ドッグフードにまつわる話を5個するという形にしたところ，なんとかなった． 東京では情報が氾濫してるから，京都でこんなのやってますとか言っても，東京では常識みたいな冷たい反応をさ
グロースハックチームを作って1ヶ月運用してわかったこと | ランサーズ社長日記
いいね！ 360 ツイート B! はてブ 125 Pocket 372 昨年から今年にかけて、僕の周りでも非常に話題になったグロースハック。 数ヶ月前からランサーズでもグロースハック的なことを色々とやっていましたが、2013年10月からは、思い切って、既存のチームから明確に分離して、「グロースハックチーム」なるものを立ち上げてみました。 1ヶ月半くらいグロースハックチームを運営して、色々と気づいたことや成果をまとめてみました。 グロスハックチーム誕生秘話 ・小さい機能改善の優先度が下がりがち サービスの改善や機能追加などをするためには、開発リソースが必要です。開発リソースは「優先度」という魔法の言葉によって開発の順番が決められて行きます。順番が決められるので、小さな機能改善、やっても良くなるかどうかわからないもの、効果測定しにくい開発は、どうしても優先度が下げられ、リリースされない、という
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術的負債と向き合う
クックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について // Speaker Deck
はてなブログチームの開発フローとGitHub
