タグ

管理に関するiori_oのブックマーク (8)

  • 働く環境としてのクリアコード(福利厚生編) - 2013-05-16 - ククログ

    はじめに クリアコードでは一緒に働くプログラマーを募集しています。昨年6月からパッチ採用という採用方法にしましたが、それ以来、採用へのお問合せがほとんどなくなりました。今年2月からインターンの募集を開始しましたが、まだお問合せがありません。しかし、採用やインターンシップページヘのアクセスは増加しています。採用ページを見た方がクリアコードは何か特別なスキルを要求しているように感じたり、パッチ採用のプロセスは時間や労力がかかりそうだがそれだけのコストを払う価値があるか判断できない、あるいはそもそも応募するかどうか判断するための情報が不足していることが原因ではないかと仮説をたてました。 実際、パッチ採用を開始する前の去年4月に入社した社員に聞いてみると、「いやあ、パッチ採用してなくても応募するのは敷居が高かったですよ。踏ん切りつけるのに1ヶ月ぐらいかかりました。面接して次はペアプログラミングと言

    働く環境としてのクリアコード(福利厚生編) - 2013-05-16 - ククログ
    iori_o
    iori_o 2013/05/16
    "なお、休暇中に仕事の連絡があることはまずありません。事前にお客様に通知したり、他の担当者がカバーできる体制を用意しています。"
  • 継続インテグレーションは強みではなくなった

    Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境

    継続インテグレーションは強みではなくなった
    iori_o
    iori_o 2012/11/02
    "組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。"
  • PyFes LT 2012.08 で「使い捨て python コードの書き方」についてしゃべってきました - 科学と非科学の迷宮

    使い捨て python コードの書き方 from Sho Shimauchi サポートの仕事におけるプログラミングというのは通常の開発と少し異なっています。 「1時間以内に数十GBのログを解析して問題を特定し対策を回答しなければいけない」などということはしょっちゅう発生しますので、ちまちま時間をかけてコードを書いていられません。 その代わりプログラムそのものをお客様に提供するわけではなく、解析の道具として手足のように使うことが要求されますので、基的に品質は求められません。 そういう意味では、プログラミングコンテストに性質が近いかもしれません。あそこまでの高度なアルゴリズムを使うことは稀ですが。 先日 PyFes LT で話をした内容を要約すると、「作成スピード向上のためにもある程度のテストやコード管理は必要ですよ」ということです。 わずかでもテストを書いておけばケアレスミスの確認・修正時

    PyFes LT 2012.08 で「使い捨て python コードの書き方」についてしゃべってきました - 科学と非科学の迷宮
  • 取り違えてはいけない「時間管理 vs タスク管理」

    [ 放っておいては、時間は常に手の中から滑りぬけてしまいます。しかし管理すべきなのは、時間なのでしょうか? それともタスクなのでしょうか? ブログ Stepcase Lifehack で「時間管理とタスク管理」という記事が投稿されていて、いつも自分が陥りがちな管理の「裂け目」がみえるようでしたのでご紹介したいと思います。 いつも混同しがちな時間管理と、タスク管理とはどのように異なり、どんな罠がひかえているのでしょうか。 時間 vs タスク 時間は当然ながら有限です、それに対して与えられた時間でやらなくてはいけない「タスク」は多くの場合無制限で、与えられた時間を大きくこえています。 そこで誰でもまずやってしまうのが、与えられた時間の中にできる限りのタスクを詰め込むという形での「時間管理」です。というのも、時間は残りがどれだけあるかわかりやすく、管理可能であるという幻想を与えてくれるからです。

    取り違えてはいけない「時間管理 vs タスク管理」
  • Agile Tracker の提供開始

    日、Agile Tracker の提供を開始しました。 Agile Tracker は、Facebook のグループやイベントでそのまま使える、シンプルで高速なタスク (プロジェクト) 管理ツールです。最近は Facebook のメッセージやグループをビジネスで活用されている方が増えてきていますが (自分もその一人です)、とはいえ、複雑なタスク管理は外部のツールがないと煩雑になってしまうのが実情でした。その点を解決するのが Agile Tracker です。 Agile Tracker を活用することで、小中規模のタスク (プロジェクト) 管理は Facebook のみで十分可能になります。プロジェクトのメンバーで Facebook のグループを共有して、Agile Tracker を開く、準備はこれだけです。直ちにグループのメンバーのみで Agile Tracker のプロジェクトが使

    Agile Tracker の提供開始
  • Pythonによる機械学習実験の管理

    Le document, écrit par John K. Ousterhout, aborde le sujet de la programmation de haut niveau à travers le biais du scripting pour le 21e siècle. Il présente les avantages et l'importance croissante des langages de scripts dans le développement logiciel moderne. L'auteur plaide pour une adoption plus large de ces outils afin d'améliorer la productivité des programmeurs.

    Pythonによる機械学習実験の管理
  • git-daily 的なブランチ方針がしっくりきました

    ソースコード管理でのブランチの切り方を模索してきました。いったん落ち着いたので書き残しておきます。 前提条件は以下のとおりです。 iPhone アプリがアクセスするウェブAPIを開発する。 サーバサイドの開発者はふたり。大阪と東京。 他の案件とかけもち。 行き着いたところ Mercurial git-flow/git-daily に似たブランチ方針 機能追加、開発中機能のバグ修正: default ブランチから、XXX ブランチを切って機能追加/変更し、default へマージする。 リリース: default ブランチから、release/XXX ブランチを切って、ステージングでテスト/修正。終わったら、default と master へマージし、master の先頭を番サーバにデプロイする。 リリース済不具合の修正: master ブランチから、hotfix/XXX ブランチを切っ

  • daemontools howto

    前書き この文書は DJB 氏の daemontools パッケージに興味を持たれる方やこれから導入・運用を行おうとする方に向けて書かれたものです。daemontools パッケージの概要、導入・設定方法、使用例などをまとめています。しかし、各ツールを詳細に説明するものではありません。そのため、この文書を読んだ後に、マニュアル*1 を読んでください。日語訳*2もあります。 また、新山さんの daemontools FAQ*3もありますのでそちらもご覧下さい。 註記 *1) "daemontools" http://cr.yp.to/damontools.html *2) "daemontools(日語訳)" http://www.emaillab.org/djb/tools/daemontools/top.html *3) "daemontools FAQ" http://tanaka

  • 1