methane

go 1.1 scheduler

where

src/pkg/runtime proc.c asm_*.s

design

nekoruri

ついに顕在化しはじめた「vimリスク」

英語圏ではかなり前からvimで開発し続けることのリスクについて語られていたが、いよいよ具体的な弊害が出て来ているようなので、かいつまんでメモ。日本でもそう遠くない未来だと思う。

若手エンジニアの不足

Visual Studioのように需要が逼迫しているのに人材の供給が増えず需給ミスマッチが起っているわけでは無く、需要も供給も減るという状況下でわずかだが需要が上回っているとう性質の悪い状況がvimに起きている。特に深刻なのは安価な若手エンジニアの採用が絶望的に難しいという現実だ。TextMateが台頭して数年経ちXcodeがメインストリームの先頭を突っ走る2013年において新しくvimを勉強しようとする若者はよほどの物好きしかいない。30~40歳のvimエンジニアを雇うのはそれほど難しく無いだろうがコストがかかる。安価な20代前半の若手エンジニアを雇いたいという企業の思いとは裏腹にvimを新たに学ぶ若者は絶滅寸前だ。

とても優秀な若者を雇用できるチャンスが巡って来た。採用担当者はこう尋ねる。「vimは習得していますか？」「もちろんEclipse/NetBeans/Xcodeはお手の物です。IntelliJもある程度可能です」「もう一度伺いますがvimは習得していますか？」「申し訳ございません 未習得です」

methane

gogoutineてGOMAXPROCSを設定しない限りはシングルスレッドなんですねえ。

GOMAXPROCSはもうちょっとだけ複雑です。
同時に動けるgoroutineの数の制限なのですが、
read などのブロックするかもしれないシステムコールを発行する場合、発行前に「現在実行中のゴルーチン数」をデクリメントして、
システムコールから返ってきたらそれをインクリメントします。
で、デクリメントした時に、他に動けるスレッドがいなかったらスレッド起動して、他のgoroutineが動けるようにします。
他のスレッドがすでにあって眠っていたら、それを起こしてgoroutineを実行させます。
なので、ブロックする処理としない処理を混ぜてもいい感じに動くのです。
で、その、スレッドを作ったり起動したりするのが実はちょっとだけ重いので、ベンチマーク結果を良くするためにはその処理が走らないように、

karad

package controllers;

import play.*;
import play.mvc.*;
import controllers.*;
import views.html.*;
import org.fusesource.scalate.japi.TemplateEngineFacade;

import java.util.HashMap;
import java.util.Map;

amashigeseiji

command! -nargs=+ lazy autocmd VimperatorEnter .* <args>

"googlespreadshet{{{
autocmd LocationChange '((drive|docs)\.google\.com).*(/spreadsheet/).*[0-9]+$' <C-j>

"insert-modeでの<esc>キーはspreadsheetでのエスケープキーにする(insert-modeは抜けない)
lazy fmaps -u='((drive|docs)\.google\.com).*(/spreadsheet/).*[0-9]+$' -modes=i <esc>

"insert-mode/normal-modeの切り替え(iでinsert-mode/<C-j>でnormal-mode)
inoremap -u='((drive|docs)\.google\.com).*(/spreadsheet/).*[0-9]+$' <C-j> <esc>

naoyat

#!/usr/bin/env python
#coding:utf-8

import sys

def base64_encode_(in_data, padding=False):
    in_len = len(in_data)
    out_data = []
    for i in range(0, in_len, 3):
        out_data.append(in_data[i] >> 2)

tamoot

【あ】　あー、あの人に聞いて。別プロジェクトだけど。
【い】　いいから作っちゃって！
【う】　嘘でもいいからバグの数でっちあげて
【え】　影響範囲は調査済みです！問題ありません！(キリッ
【お】　おまかせしてください！(発注元へのアピール)
【か】　カイゼンを やってるヒマが ありません やってることには なってるけどね
【き】　昨日の仕様書に書いてない！
【く】　クラウドが強み！(クスクス
【け】　検討中というラストカード
【こ】　コードが仕様書だろJK

co3k

// ==UserScript==
// @name        append target versions to related issues
// @namespace   co3k.org
// @include     https://redmine.openpne.jp/issues/*
// @version     1
// ==/UserScript==

(function(){
    var xpathToIssueLink = "//*[@id='relations']//*[contains(@class, 'issues')]//tr/td[contains(@class, 'subject')]/a";
    var issueLinkResult = document.evaluate(xpathToIssueLink, document, null, XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null);

hayajo

ChangeLog を支える英語

ChangeLog を書く際によく使われる英語をまとめました。

ほとんど引用です。

基本形

Gab-km

GitHub Flow

• Scott Chacon on the Interwebs(リンク切れ)
• Scott Chacon on the Interwebs
• GitHub Flow - The best way to use Git and GitHub

31 Aug 2011

git-flowの問題点 (Issues with git-flow)