Pythonで実装されたPythonインタプリタ「PyPy 1.2」リリース、JITコンパイラ採用で高速化を達成 - SourceForge.JP Magazine : オープンソースの話題満載

「PyPy」開発チームは3月12日、最新版となる「PyPy 1.2」を公開した。JIT(Just-In-Time)コンパイラを初めて搭載、パフォーマンス向上が最大の特徴となる。

PyPIと発音が同じで分かり辛いな!

情熱プログラマー ソフトウェア開発者の幸せな生き方

どこかのブログでオススメされていたので買った情熱プログラマーが届きました。

Amazon.co.jp: 情熱プログラマー ソフトウェア開発者の幸せな生き方: Chad Fowler, でびあんぐる: 本

内容紹介

本書は、等身大のプログラマの一人がキャリア開発の重要性を説き、そのための心構えなどを示したもの。「プログラマはビジネス視点を持って意識的なキャリア開発をすべき」という視点から、その実践方法を著者独特の生き生きとした共感できる語り口で伝える。

『My Job Went To India オフショア時代のソフトウェア開発者サバイバルガイド』(オーム社、2006年)の改題改訂第2版。

なん・・・だと・・・?

(内容が悪い訳ではありません。My Job Went To Indiaもう持ってます)

My Job Went To India オフショア時代のソフトウェア開発者サバイバルガイド

WebGLに期待してOpenGLの基礎を勉強して行きたい。

hello.c:

#include <GLUT/glut.h>

void display(void)
{
glClear(GL_COLOR_BUFFER_BIT);
glFlush();
}

void init(void)
{
glClearColor(0.0, 0.0, 1.0, 1.0);
}

int main(int argc, char *argv[])
{
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_RGBA);
glutCreateWindow(argv[0]);
glutDisplayFunc(display);
init();
glutMainLoop();
return 0;
}

Makefile:

PROGRAM = hello
SRCS = hello.c
OBJS = $(subst .c,.o,$(SRCS))

CFLAGS = -framework GLUT -framework OpenGL

$(PROGRAM): $(SRCS)
$(CC) $(CFLAGS) -o $@ $<

.PHONY: clean

clean:
$(RM) $(OBJS) $(PROGRAM)
% make
% ./hello

./hello

文字コード入門







「・・・。」







やってくれたのう

「やってくれたのう・・・Amazon・・・。」

関連:重複 - p0t

フレームワークで分析するのを本当にやめて欲しい: 切込隊長BLOG(ブログ) Lead‐off man's Blog

まあ、何を言いたいかというと、現場で頑張る人、現場を仕切る管理職、組織を率いる経営者と、立場によって知っておくべき枠組みや、価値観・優先順位は違うんだよ、ということ。4象限程度のフレームワークで仕事していいのは、現場や物理を相手にする物づくりの人たちだけ。

「問題を構成する最小限の要素の性質と関係を詳しく調べていけば全ての問題が解決するはず」というボトムアップ式の思考では対応できる問題の複雑度が低く、市場予測や経営といった複雑な問題を解決する手法として適さない。(できるとしても計算量が多すぎて現実的な時間無いに終わらない。)

それが理解されないというイラつきでしょうか。

こちらのブログの方はおそらく話したり書き殴ったりするより考えるスピードの方が速くて終わる頃には自分の中で結論はまとまっていて、既に次のことを考えているといった感じの人なんじゃないでしょうか。頭の回転が速い人を見ていてそうなのかな、と思うことがあります。

僕は頭の回転が遅く、話すのもゆっくりなので、風呂入ったり、誰かに話したり、ブログに書いたりしないと考えがまとまりません。

上記の点を相手に説明するとしたらこういう感じでしょうか。

線形代数に対して非線形科学があるように、ボトムアップだけが問題解決の手法ではない。ブラックボックスの群れの動きのパターンから法則を見つけだして予測し、制御する手法が市場予測や経営などには有効である。

メンドイのでSpidermonkeyで実行。

#!/usr/bin/env js                                                             

var human = function() {
var that = {}
that.say = function() {
print('Hello!')
return that
}
return that
}

var employee = function() {
var that = human()
that.has_work = true
return that
}

var neet = function() {
var that = human()
that.has_work = false
that.say = function() {
print('絶対に働きたくないでござる!')
return that
}
return that
}

human().say()
employee().say()
neet().say()
Hello!
Hello!
絶対に働きたくないでござる!

簡単。

JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス
プログラマーの力量を見極める--面接官になったら尋ねるべき質問実例集 - IT業界を生き抜く秘密10箇条 - ZDNet Japan

ソフトウェア開発者を採用する面接の場においては、応募者の専門家としての力量を見極めることが最も困難な作業の1つである。

現時点でプログラマーの面接についての自分の考えをまとめておきます。

結論:

  • プログラマー採用にあたって応募者の力量を見極めることは困難ではない。(面接で見極めることは困難である。)

前提:

  • 短時間の面接(対面して話す事)でプログラマーの力量を実用的な精度で見極めることは不可能である。
  • 中途採用において、PCやネットと切り離した無菌室状態での力量と現実世界での成果には大きな差がある。
  • 専門技能(プログラミング)の高低と人間性の良し悪しは無関係である。

採用方法:

  1. ソースを見る。(githubのアカウント名を教えてもらえれば十分である)
  2. 会って世間話する。

プログラマーの力量を見極めるにはソースを見れば良い。公開できるソースが無い場合は業務で作っているもの(たとえばブログ)を作ってソースを見せてもらえば良い。会う必要は無い。(ブログを見せてもらえば精度があがる)

プログラマーのとしての力量が十分であれば、それとは全く別に「自分たちと楽しく仕事ができるかどうか」を実際に会って確かめる。(要は人間性=良い人かどうかを確かめる)世間話をすればいい。(大抵プログラマー同士の世間話はプログラミングに関することになるが。)

この2番目のプロセスは応募者にとって会社側を精査する場でもある。なるべく良い印象を持ってもらえるようにおもてなししよう。また退職はコスト的に非常に大きな損失なので入社後にお互いのミスマッチが起きないようになるべく現状を正直に話そう。(ミスマッチに気づくのが早ければ早いほど損失は小さくなる)

実際に会う面接は高コストなのでこの順番を逆にしてはいけない。

たったこれだけで採用コストは減り、精度は格段に上がる。採用する側がスーパープログラマーである必要もない。(ソースが読めれば普通のプログラマーで問題無い)

プログラマーの専門職としての社会的価値は成果物である動くプログラムである。PCやネットと隔離せず、それをなるべく自由な状態で作って見せてもらおう。プログラマーの力量を見るのにソースより雄弁なものがあるだろうか?

イチローがどんなに人格者だろうが内野安打が打てなければ偏屈糞バッターだ。キム・ヨナがどんなに(もしもね)アバズレでもトップクラスのアイススケーターであることは疑いようが無い。

管理職としての技能が知りたいなら別のプロセスが必要だろう。

何故このやり方を皆がとらないのかについての組織論は、このやり方を自分が取れない組織に入った時にまた考えます。

% crontab -l
30 17 * * 2,5 GEM_HOME=/opt/local/lib/ruby/gems/1.8 /Users/komagata/bin/ticket_alert.rb

cronで実行するときはGEM_HOMEを指定するのがコツみたい。

ticket_alert.rb:

#!/usr/bin/env ruby
require 'rubygems'
require 'rb-skypemac'

class TicketAlert
def self.run!(chat_id, msg)
SkypeMac::Skype.send_(:command => "CHATMESSAGE #{chat_id} #{msg}")
end
end

if __FILE__ == $0
TicketAlert.run!('#komagata1111/$xxxxxxxxxxxx', <<-EOS)
お疲れ様です。駒形です。
チケット確認の時間が近いので各自、自分のチケットの期限の確認をお願い致します。

また、期限が過ぎた方に「理由」と「対策」を求めるメールをお送りしていますが、必ず返信していただくようお願い致します。
EOS
end

毎週火曜日・金曜日の18時にRedmineのタスク期限オーバーチェックを行っています。30分前にこのメッセージが全員参加Skypeチャットにこのメッセージを贈るのが上記のcronの設定です。(ここに書いてある「期限が過ぎた方にメールを送る」というのも別のcronジョブで自動化しています。(MechanizeでRedmineをスクレイプしている。)

これだけでタスクの期限オーバーは激減しました。

糞Mac

もう何がなにやら・・・

関連:俺の酷いMac - p0t

JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス

javascriptでシンプルな差分プログラミングのやり方が知りたかったのでJavaScript: The Good Partsを立ち読みしに行ってきました。正に俺のような中途半端に書いてる野郎に最適な本だったんですが、薄い本だけど立ち読みだけで理解出来なかったので買って読みました。

とりあえず今まではよくあるプロトタイプ型の継承で書いていたんですが、小クラスから親クラスのメソッド(コンストラクタ含む)を呼ぶやり方がわからず困ってました。(コードが重複したり、コンストラクタに処理を書くのを避けたりして効率が悪かった。)

たとえばこんな感じです。(面倒なのでSpidermonkeyで実行)

#!/usr/bin/env js

function Human() {
  this.name = 'human'
}
Human.prototype.greeting = function() {
  print('Im ' + this.name)
}

function Fukumoto() {}
Fukumoto.prototype = new Human
Fukumoto.prototype.greeting = function() {
  this.parent.greeting() // super()的なことがしたい
  print('Im ' + this.name + '........!!??')
}

var kaiji = new Fukumoto
kaiji.greeting()
/users/komagata/code/proto.js:13: TypeError: this.parent has no properties

この本の「5章 継承 5.4 関数型」に載ってた関数型の継承を使ってみました。(本に載っているのはプライベート変数・プライベートメソッドを導入した更に優れたやり方でしたが、ユルイ代わりにもっと簡単な実装にしてみました。)

#!/usr/bin/env js

var human = function() {
  this.name = 'human'
  this.greeting = function() {
    print('Im ' + this.name)
  }
  return this
}

var fukumoto = function() {
  var superior = human(),
      superior_greeting = superior.greeting,
      that = superior
  that.greeting = function() {
    superior_greeting()
    print('Im ' + superior.name + ' .......!!??')
  }
  return that
}

var kaiji = fukumoto()
kaiji.greeting()
Im human
Im human .......!!??

擬似クラス型やプロトタイプ型はどうも自分のやりたい事にとってオーバー過ぎる気がしてたのでシンプルなやり方に出来てとても嬉しいです。