Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

標準レベル未満のメンバーを開発プロセスの工夫で救えるか

開発プロセスを工夫することで、標準レベル未満のメンバーを救えるのか?という話。

satob.hatenablog.com

satob.hatenablog.com

少なくとも、開発プロセスは「標準レベル未満のメンバーを救うこと」が主目的ではないよなぁ、とは考えています。そういう救いのためには「できない所に触らせない」仕組みが必要で、それは開発プロセスじゃなくて役割分担とか開発フレームワークの役目だよね。

開発プロセス標準化によって普遍的に狙いたいのは以下のようなポイントで、この辺は開発者のレベル関係なく役に立つ。

  • 考えなくていいことを考えなくて済むようにする。どっちでも良さそうなことに決めを作る。
  • 開発に利用している技術や製品のgotchasを避ける。 *1

さて、それとは別に、たとえばCMMIによる生産性向上がすべて幻想か?と言われると、それも違うと思うわけです。ただ、CMMIが計測しているのは「開発者個人のスキルの改善」と「開発者のスキルとは関係ないプロセスの改善」であって、「開発者のスキル不足をプロセスがどれだけカバーできるようになったか」ではない、ということなのだという理解です。

あと、「開発プロセスが優れているために生産性が上がる」というケースが信じられない人でも、「開発プロセスがマズくて生産性が下がる」というケースは信じられるのではないかと思います。この際、開発プロセスが整備されていない(生産性の向上・低下の理由が多種多様すぎて、何が原因なのか切り分けもできない)状況では、あらゆる生産性の向上・低下の原因が「開発者個人の技能によるもの」と誤って認識されてしまうおそれがあり *2、そうならないためにも何らかの形で開発プロセスの整備が必要なんだろうな、と考えています。

*1:大学の技術者倫理の授業で「自分の専門について、自分以外は素人だと思いなさい。自分の専門以外について、自分は素人だと思いなさい」と教えられて、これは今でもよく覚えています。

*2:木下光生「貧困と自己責任の近代日本史」(人文書院, 2017, p.302)に、貧困の原因を考える際「貧困に至る理由の融通無碍さに起因して、自己責任を原因として結論してしまう」という話があり、同じ事象が開発者の生産性についても起こるんではないかと。

Use Enum defined in classes from PowerShell

If you have an enum like this:

namespace Foo {
    public class Bar {
        public enum Baz {
            A = 0,
            B = 1,
            C = 2
        }
    }
}

You can use this enum from PowerShell with [FQCN+Enum] notation like this:

Add-Type  @"
namespace Foo {
    public class Bar {
        public enum Baz {
            A = 0,
            B = 1,
            C = 2
        }
    }
}
"@

[System.Enum]::GetNames([Foo.Bar+Baz])

$BazA = [Foo.Bar+Baz]::A
$BazA

Change culture (locale) of current PowerShell process

You can change culture (locale) into English with chcp 437 in Windows 7.

In contrast, You cannot change culture with chcp in Windows 10.

In Windows 10, if you want to execute single PowerShell script in another culture, you can execute the script like this:

[Threading.Thread]::CurrentThread.CurrentUICulture = 'en-US'; .\myscript.ps1

If you want to change culture throughout every command in a PowerShell process, you have to change the culture setting cached in PowerShell runtime with reflection like this:

# example: Set-PowerShellUICulture -Name "en-US"

function Set-PowerShellUICulture {
    param([Parameter(Mandatory=$true)]
          [string]$Name)

    process {
        $culture = [System.Globalization.CultureInfo]::CreateSpecificCulture($Name)
       
        $assembly = [System.Reflection.Assembly]::Load("System.Management.Automation")
        $type = $assembly.GetType("Microsoft.PowerShell.NativeCultureResolver")
        $field = $type.GetField("m_uiCulture", [Reflection.BindingFlags]::NonPublic -bor [Reflection.BindingFlags]::Static)
        $field.SetValue($null, $culture)
    }
}

Note: Some cmdlets like Add-Type are not affected this setting.

(from https://gist.github.com/sunnyone/7486486 via https://twitter.com/altrive/status/401349992536756224?s=20)

Import assemblies for C# embedded in PowerShell

You can import assemblies (.NET DLLs) in PowerShell like this:

[void][reflection.assembly]::LoadWithPartialName("System.Drawing")
New-Object System.Drawing.Drawing2D.GraphicsPath

But you will get an error when you tring to use these assemblies in C# source embedded in PowerShell script. Assemblies loaded with LoadWithPartialName aren't referenced from embedded source.

[void][reflection.assembly]::LoadWithPartialName("System.Drawing")
Add-Type @"
using System.Drawing.Drawing2D;
"@
Add-Type : c:\tmp\_System\ama4povk.0.cs(1) : The type or namespace name 'Drawing2D' could not be found (are you missing a using directive or an assembly reference?)
c:\tmp\_System\ama4povk.0.cs(1) : >>> using System.Drawing.Drawing2D;
At line:1 char:1
+ Add-Type @"
+ ~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (Microsoft.Power...peCompilerError:AddTypeCompilerError) [Add-Type], Exception
    + FullyQualifiedErrorId : SOURCE_CODE_ERROR,Microsoft.PowerShell.Commands.AddTypeCommand

Add-Type : Cannot add type. Compilation errors occurred.
At line:1 char:1
+ Add-Type @"
+ ~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Add-Type], InvalidOperationException
    + FullyQualifiedErrorId : COMPILER_ERRORS,Microsoft.PowerShell.Commands.AddTypeCommand

With Add-Type, you have to specify assemblies with -ReferencedAssemblies option like this:

Add-Type -ReferencedAssemblies ("System.Drawing") @"
using System.Drawing.Drawing2D;
"@

Understandability of decision table depending on the countries

In software testing, decision table is an useful tool to identify and list up test cases and what you should check in those test cases. In Japan, there is a standard for decision table: JIS (Japanese Industrial Standard) X 0125:1986.

... But on the other hand, I’ve heard that in some countries, the decision table is not used for software testing. Additionally, they said they have explained why and how to use decision table to the developers in that countries, but the developers couldn’t understand why they use the table-format representation. More specifically, they said the developers in U.S. and Vietnam couldn’t understand the decision table, whereas the developers in China (and of course, Japan) could understand it without any difficulty.

I can’t guess it is caused by the personal skill level of those developers, by the culture they are on, or by the educational background of them (they can understand the decision table if they have written the Karnaugh diagrams, can’t they?). But this problem is very interesting for me...