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);

tamoot

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

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;

nekoruri

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

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

若手エンジニアの不足

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

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

balibali

<?php

class openpneTruncateTablesTask extends sfBaseTask
{
  protected function configure()
  {
    $this->addOptions(array(
      new sfCommandOption('application', null, sfCommandOption::PARAMETER_OPTIONAL, 'The application name', true),
      new sfCommandOption('env', null, sfCommandOption::PARAMETER_REQUIRED, 'The environment', 'dev'),
      new sfCommandOption('no-confirmation', null, sfCommandOption::PARAMETER_NONE, 'Whether to force dropping of the database')

mala

# 私が考える安全なプログラムを書くために必要なこと

今も昔も「入力によって挙動が大幅に変わるAPI」が世の中には多数存在していて、プログラマが本来意図した挙動と異なる動作を引き起こしている。

- ファイルを開こうとしたらコマンドを実行できてしまったり
- CSSセレクタを書いてるつもりがHTMLタグを生成してしまったり
- SELECT文を発行するつもりがDELETE文を発行できてしまったり

こういったときに
- 入力値検証をしないと危険になる

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)

rodionmoiseev

apply plugin: 'java'
apply plugin: 'scala'
// For those using Eclipse or IntelliJ IDEA
apply plugin: 'eclipse'
apply plugin: 'idea'

def findPlay20(){
  def pathEnvName = ['PATH', 'Path'].find{ System.getenv()[it] != null }
  for(path in System.getenv()[pathEnvName].split(File.pathSeparator)){
    for(playExec in ['play.bat', 'play.sh', 'play']){

methane

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

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

tokuhirom

SQLインジェクション対策について

教育的な観点ではなく実務的な観点から、僕の考えをまとめてみる。UTF-8 を利用し、SET NAMES を利用していなくて mysql で、クライアントプリペアドステートメントなケースを想定している。

SQL インジェクションとは

$foo=$_POST[‘id’];
query(“SELECT * FROM foo WHERE id=$foo”);

のように外部からの文字列をそのまま使用してクエリを組みたてたときに、意図せぬ SQL を発行されてしまう脆弱性のことである。