働く環境としてのクリアコード（福利厚生編） - 2013-05-16 - ククログ
はじめに クリアコードでは一緒に働くプログラマーを募集しています。昨年6月からパッチ採用という採用方法にしましたが、それ以来、採用へのお問合せがほとんどなくなりました。今年2月からインターンの募集を開始しましたが、まだお問合せがありません。しかし、採用やインターンシップページヘのアクセスは増加しています。採用ページを見た方がクリアコードは何か特別なスキルを要求しているように感じたり、パッチ採用のプロセスは時間や労力がかかりそうだがそれだけのコストを払う価値があるか判断できない、あるいはそもそも応募するかどうか判断するための情報が不足していることが原因ではないかと仮説をたてました。 実際、パッチ採用を開始する前の去年4月に入社した社員に聞いてみると、「いやあ、パッチ採用してなくても応募するのは敷居が高かったですよ。踏ん切りつけるのに1ヶ月ぐらいかかりました。面接して次はペアプログラミングと言
継続インテグレーションは強みではなくなった: 柴田 芳樹 (Yoshiki Shibata)
Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境
PyFes LT 2012.08 で「使い捨て python コードの書き方」についてしゃべってきました - 科学と非科学の迷宮
使い捨て python コードの書き方 from Sho Shimauchi サポートの仕事におけるプログラミングというのは通常の開発と少し異なっています。 「1時間以内に数十GBのログを解析して問題を特定し対策を回答しなければいけない」などということはしょっちゅう発生しますので、ちまちま時間をかけてコードを書いていられません。 その代わりプログラムそのものをお客様に提供するわけではなく、解析の道具として手足のように使うことが要求されますので、基本的に品質は求められません。 そういう意味では、プログラミングコンテストに性質が近いかもしれません。あそこまでの高度なアルゴリズムを使うことは稀ですが。 先日 PyFes LT で話をした内容を要約すると、「作成スピード向上のためにもある程度のテストやコード管理は必要ですよ」ということです。 わずかでもテストを書いておけばケアレスミスの確認・修正時
取り違えてはいけない「時間管理 vs タスク管理」
[ 放っておいては、時間は常に手の中から滑りぬけてしまいます。しかし管理すべきなのは、時間なのでしょうか？ それともタスクなのでしょうか？ ブログ Stepcase Lifehack で「時間管理とタスク管理」という記事が投稿されていて、いつも自分が陥りがちな管理の「裂け目」がみえるようでしたのでご紹介したいと思います。 いつも混同しがちな時間管理と、タスク管理とはどのように異なり、どんな罠がひかえているのでしょうか。 時間 vs タスク 時間は当然ながら有限です、それに対して与えられた時間でやらなくてはいけない「タスク」は多くの場合無制限で、与えられた時間を大きくこえています。 そこで誰でもまずやってしまうのが、与えられた時間の中にできる限りのタスクを詰め込むという形での「時間管理」です。というのも、時間は残りがどれだけあるかわかりやすく、管理可能であるという幻想を与えてくれるからです。
Agile Tracker の提供開始
本日、Agile Tracker の提供を開始しました。 Agile Tracker は、Facebook のグループやイベントでそのまま使える、シンプルで高速なタスク （プロジェクト） 管理ツールです。最近は Facebook のメッセージやグループをビジネスで活用されている方が増えてきていますが （自分もその一人です）、とはいえ、複雑なタスク管理は外部のツールがないと煩雑になってしまうのが実情でした。その点を解決するのが Agile Tracker です。 Agile Tracker を活用することで、小中規模のタスク （プロジェクト） 管理は Facebook のみで十分可能になります。プロジェクトのメンバーで Facebook のグループを共有して、Agile Tracker を開く、準備はこれだけです。直ちにグループのメンバーのみで Agile Tracker のプロジェクトが使
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Pythonによる機械学習実験の管理