1日のスケジュールを可視化してタスク消化率の最適化を図る - LCL Engineers' Blog
1日のスケジュールを可視化してタスク消化率の最適化を図る モバイルアプリエンジニアの山下です。 今年からGoogleカレンダーにその日のタスクを予定として登録しています。 これにより、以下のメリットがあります。 日毎に消化したタスクを後から見返せる イベント・MTGや勤怠管理と一緒に予定を管理できる 他の人にスケジュールを共有できる 加えて、LCLでは始業の際に朝会で行うようなスケジュールの共有をチャット上で行っており、スケジュール内容をフォーマットに沿って投稿するようにGASを使って自動化しています。 techblog.lclco.com これらのメリットから始めた当初は満足していたのですが、運用から5ヶ月を経ちいくつかの問題が出てきました。 タスク消化時間を集計しづらい 同じタスクを分割して登録する必要がある 予定と作業時間の差分がみえなくなる 作業ノイズがわからない より詳しく落とし
メルカリが「急成長」「ほとんど中途採用」でも、強いチームでいられる理由
メルカリが「急成長」「ほとんど中途採用」でも、強いチームでいられる理由：メルカリ流「企業カルチャーの作り方」 急成長のフェーズにあり、さまざまな背景を持つメンバーばかりなのにも関わらず、強いチームとして知られるメルカリ。チームワークを深めるために必要なものはなんだろうか。 フリマアプリ「メルカリ」を展開するメルカリは、強いチームワークと企業文化で知られている。 組織が小さいうちは社員一人一人が交流でき、強いチームワークを発揮できても、大きくなってくると“壁”にぶつかる企業も多い。また、さまざまなバックグランドを持つ中途採用のメンバーが入社してくることで、会社のカルチャーや雰囲気が変わっていくこともある。 メルカリは、「毎月数十人が入社する」という急成長のフェーズにあり、なおかつ社員のほとんどが中途採用だ。ベンチャー企業からの20代の転職者もいれば、いわゆる“伝統的な日本企業”からやってきた
GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します - ぐるなびをちょっと良くするエンジニアブログ
こんにちは！テニスはじめました、小山です。開発部門でウエディンググループのリーダーをやっています。 今回は私が考えた新しいGitのブランチモデル「GitFeatureFlow」についてお伝えしたいと思います。 GitFeatureFlowとは Gitを使った開発をより快適にするため、GitFlow,GitHubFlow,GitLabFlowではない、新しいGitのブランチモデル「GitFeatureFlow」を考えました。 Gitを利用して開発を行う場合、Gitのブランチモデルをどうすべきか悩むことが多いかと思います。私自身もこの悩みに直面しました。既存のブランチモデルでは問題が解決できなかったので、GitFeatureFlowという新しいブランチモデルを考え、ウェディンググループに導入。今では快適にGit開発を行っています。 GitFeatureFlowで使う主なブランチはこの3つです。
Apache設定ファイルのIfModuleは消しておく方がよい。 - Qiita
Apacheの設定ファイルは、パッケージのデフォルトをそのまま使っていると、<IfModule>ディレクティブがたくさん記述してあると思います。 例 自分でサーバ管理する場合は、この<IfModule>は全部消したほうがいいと思います。 実際、マニュアルにも「普通の運用では使う必要がない」と書いてあります。 In normal operation, directives need not be placed in <IfModule> sections. 以下、IfModuleがなぜダメかの理由をのべます。 理由１：IfModuleがあると可読性が下がる <IfModule>で囲われていると、その設定が実際に有効になっているのかどうかがそこだけ見てもわかりません。 長大なhttpd.confの中にあるLoadModuleの森を探求したり、conf.modules.dディレクトリの中を探した
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
