ヤフーが新本社、“歩きにくいオフィス”でイノベーション創出、週休3日制導入も検討ヤフーは2016年9月27日、2016年10月1日に移転する新本社を報道関係者に公開した。新本社は、東京・千代田区の東京ガーデンテラス紀尾井町内に設ける。オフィス設計に当たって重視したのは、「イノベーションを生み出す」こと。そのために、フリーアドレス制を導入する、あえて“歩きにくい”レイアウトを採用する、社外の人が自由に使えるスペースを設ける、などの工夫を盛り込んだ（写真1）。
発言広場 - 新入社員プログラマーですが周りについていけません
まだ満足のいく回答を得られていないみたいなので二度目の回答を 一回目の回答で文系と書きましたが、それは世の中から法則性を見付け定式化できる能力があるかどうかという意味です Jiamari459さんは、RPGなどのコンピューターゲームはしますか？ するとしてキャラクターのレベルが上がって強くなったとき、将来どれくらい強くなるか知りたいと思いますか？ そして知りたいならどうやって知ろうとしますか？ インターネットで検索するのが一番早くてスマートな問題解決方法かもしれません でも、私の場合なら幾つかのレベルのサンプルから計算式を推測します (武器のレベル+キャラクターの能力値)×技による倍率-敵のレベル+乱数 といった感じです こうして次のレベルの数値を予測しレベルを上げて計算式の正しさを証明していきます これは科学的手法そのもので、いわゆる理系と呼ばれる人達はこの能力が長けています 掛け算九九
サーバントリーダーシップが陥れる「良い兄貴問題」 - Noize
今回の記事ではエンジニアやIT業界ではすでに定着した感のあるポッドキャスト『rebuild.fm』の#123について触れてみたいと思う。 rebuild.fm いきなり横道にそれるが、podcastはランニング中や移動中に1.5倍速で流して聞けるのが便利。一方でメモがとれず終わった後にきちんと整理する時間を取らないと「要旨はなんだったのか」が曖昧になり自分に残らない感があるのが悩ましいですね。 今回のゲストである @naoya_itoさんが『エンジニアチームのリーダーシップ』というテーマについて『Fate/Zero』というアニメの11話「聖杯問答」になぞらえてうまく例えていた。 「聖杯問答」の内容について、超端的に言うと、世代を超えた3人の王が統治の仕方を論じ、民や臣に厚いタイプの王が大いなる野望を追いかけるタイプの王に負ける、という話。 趣旨：サーバントリーダーシップの是非 放送を通じた
開発者の生産性：Noと言える技術 | POSTD
生産性を維持するのは難しいことです。 特に開発者の立場では。 ゾーン（超集中状態）に入るには時間がかかりますが、入ったゾーンから引きずり出されるのは簡単です。 例えば、 * ミーティング * Eメール * 作る予定の機能や、修正すべきバグ などに意識が分散されてしまいます。確認しておかないと、気付いたら何もする時間がなくなっています。 これを解決するための秘策があります： あらゆることに” no “と言うのです。 私たちのやり方をお教えしましょう。 ミーティングは木曜日だけ ミーティングは生産性を奪います。私たちは経験から、いつもミーティングの前後に45分の時間が消えてしまうことに気付きました。さらに、Skypeでのたわいないおしゃべりでも15分間が失われます。 45分後にミーティングがあると思うと、重要なことは始められません。同じように、電話やミーティングが終わってから、即座に大きな問題
"Microservices"を読んだ
James Lewis氏とMartin Fowler氏による“Microservices”を読んだ．以前ざっと目を通したが，最近よく耳にするようになったのでちゃんと読んだ．以下はそのメモ． 概要 “Microservices” とはソフトウェアシステムの開発スタイルである 近年このスタイルでの開発を見てきて良い結果が出ている 初出は2012年の3月の“Micro services - Java, the Unix Way” Microserviceは一連の小さなサービスで1つのアプリケーションを開発する手法 それぞれのサービスは自身のプロセスで動いており，軽量な機構（e.g., HTTP API）を通じて情報をやりとりする これらのサービスは独立して自動デプロイされる 一枚岩として構築されるMonolithicスタイルのアプリケーションと比較すると分かりやすい 一般的なエンタープライズのア
昔ながらの「片手間に書くJavaScript」の限界 - mizchi's blog
Javascriptを使うのをやめろ：Railsの時代遅れ云々についての結論 - Qiita この記事は、全体的に自分の業務以外の評価基準やトレンドを知らないんだなという感じで、わざわざ付き合うと精神的に消耗する感じがした。ただ、それが彼らの本職でない以上、自分もこの結論に至るのは仕方ないと感じている部分はある。 真の問題は、自分がレガシーなJavaScriptを書いているという自覚がない人間が、ここ数年の技術トレンドから乖離したコードを書き続けることで他のエンジニアやエコシステムそのものに悪影響を及ぼしているケースが散見されている。一行書く毎にグローバル汚染するスクリプトを見せられてもメンテ出来んと言われても、はいそうですねとしか言えないし、そういう人に最近のライブラリを触らせると遅くなるというのは、画面全体を一つのMustacheテンプレートにしてBackbone.Modelのパラメー
意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観
意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観 書いた人: ると 猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜という記事がありました。手続き型からの発展としてのオブジェクト指向という史観を書いた記事です。しかし、そこで次のように述べられている史観は少々単純化しすぎです。 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 手続き型プログラミングの時代は、少なくとも思想的にはそこまで暗黒的ではありませんでしたし、「データと手続きをひとかたまりにする」の
Treehouse: 本当にフラット、つまりマネージャーがいなくなった会社、そして個の時代がくるのか？ - ワザノバ | wazanova.jp
http://blog.teamtreehouse.com/working-in-a-flat-company 1) Treehouseで起きていること プログラミング/デザインのオンラインコースを運営しているTreehouseは、６月に週４日勤務にしたことに続き、９月に、フラットカンパニー宣言をしました。つまり、マネージャーと呼ばれる人が社内から突然いなくなったということです。 会社は、幅広めのゴール、ミッションステートメント、キャッシュフローへのインパクトのガイドラインのみを提示。それ以外の優先順位の判断は社員に任せる。 社内のプロジェクトは、提案 -> 社内フォーラムサイトで議論 -> 投票 -> 自主的判断で各メンバが “Join”ボタンを押して自分をアサイン、というプロセスで進みます。そして、各メンバは、1日1回ステータスをサイトでアップデートすることで進捗管理。各プロジェクトに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クソエンジニア発言１０連発 by yodatomato