2017年5月17日水曜日

自分用メモ:yeoman-generatorの実体の場所

/usr/local/lib/node_modules/generator_***にある模様。
探すのに時間がかかったのでメモ

2017年4月24日月曜日

新しいdotnetコマンドで自己展開型(self contained)なバイナリを生成するには

VS.NET 2017系になって、Dotnet coreがproject.jsonからcsprojになりました。

以前は、project.jsonで自己展開型(.exeにビルドするやつ)にビルドするには、
project.jsonに、以下のようにruntimesセクションを追加して

"runtimes": {
  "win10-x64": {}
  "osx.10.10-x64: {}
}

dotnet build -r win10-x64

などとコマンドラインで叩くと-r(runtimes)オプションで指定した環境向けに単独で実行できるバイナリが生成されます。

VS.NET 2017では、project.jsonが廃止されて*.csprojになってしまったので、自己展開型のバイナリ生成が上記のやり方ではできなくなってしまいました。

VS.NET 2017のプロジェクトのプロパティからも設定できなかったが、csprojを直接編集することでできる模様。

<PropertyGroup>
  <RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>
  <RuntimeIdentifiers>osx.10.10-x64</RuntimeIdentifiers>
</PropertyGroup>

上記のようにした上で、

dotnet build -r win10-x64
dotnet build -r osx.10.10-x64

とコマンドラインで叩くと、指定した環境向けの実行バイナリが生成される。

参考: https://docs.microsoft.com/ja-jp/dotnet/articles/core/deploying/

どっちにしてもVS.NET上で指定はできないみたい。
→とわいえ、VS.NET 2017からDotnet Coreサポートは大分良くなったよ!!

2017年1月12日木曜日

マルチモニタをやめてみた

クラムシェルをやってみたくて一時的にマルチモニタをやめてみたら意外に作業が捗る事がわかった

理由を考えたところ作業スペースが有効に使え、マルチモニタのときは狭くて使って無かった紙とペンを使うようになったことと、何より集中力が上がった気がする。
目の前に余計な物がないのが良いみたいだ。
マルチモニタと作業効率でググると良いことしか書いてないページばかり引っ掛かるが、シングルモニタと集中力でググると真逆のことが書かれていて面白い。
マルチモニタ派の人は作業効率おしだがシングル派はかつてマルチモニタを使っていた人ばかりというのがより説得力がある。

結局は人それぞれなのかもしれないが、試しに片方のモニタの電源オフしてみるのも良いかも知れない

2017年1月11日水曜日

Anguler2@Windows with Webpackでエラーが発生する件について

Angular2をWindows環境で実行しようと、http://blog.stevensanderson.com/2016/10/04/angular2-template-for-visual-studio/からひっぱてきたテンプレートを使って動かそうとした際、
node_module/to-string-loader/src/to-string.jsの16行目でjavascriptのヒアドキュメントがILLEGALなsyntaxというエラーが発生してえらく難儀したのでメモしておく。

結論から言うと、node.jsのバージョンが 0.10.xxx で古かったらしく最新バージョンにアップしたら問題なく動作した。
最新版はここを参考に引っ張ってきた。※既にnode.jsにパスが通っている環境の場合、既存のパスの方が優先されたのでパスの調整が必要でした。

また、TypeScriptのバージョンもアップ(1.5.4→2.14)した。

普段はVisual Studio.Codeを使っているが、たまにVisual Studio.NETを使うのも良い気がした。

追記:
ここに既出ですね。→node.js 4.X以上じゃないとダメみたいですね。

2016年11月8日火曜日

typescript環境構築の自分用メモ

typescript環境構築の自分用メモ

yoは入れておく。
yo aspnetで足場は作れるようにしておく。

typings install dt~jquery --save --global

とかやると typings/globals/jquery/** に型定義ファイルができる。
typings/index.d.tsをrefernce指定すれば補完が効く。

gulpを使うためにgulpfile.jsを作っておく。

gulpfile.jsのなかみは以下のような感じ。

var gulp = require('gulp');
//var del = require('del');

var paths = {
unify: [
'app.js',
'app.js.map'
],
scripts: [
'TypeScript/**/*.tsx',
'TypeScript/**/*.ts',
'TypeScript/**/*.map'
]
}

gulp.task('default', function () {
//del(['wwwroot/TypeScript/**/*']);
//del(['wwwroot/js/*']);
gulp.src(paths.unify)
.pipe(gulp.dest('wwwroot/js'));
gulp.src(paths.scripts)
.pipe(gulp.dest('wwwroot/js/TypeScript'));
});

delはあってもなくてもよい。
ワークスペースのフォルダ構成は以下の感じ。

/TypeScript
   →ここに*.tsを入れとく
/Views
   →cshtmlはこの下に置かれる。
/Controllers
   →コントローラのコードはここに置かれる。
/wwwroot
   /js
      ここにコンパイルされたjsが配置される。



2016年11月7日月曜日

GOLANG@VS.CODE自分用メモ

GOPATHの設定をどうするか的な話。
プロジェクトごとにルートパスが違うのでシステムに単一のGOPATHだと
いやだなぁと思っていて、かと言って相対パスでローカルパッケージを
指定してもvs.codeでローカルパッケージだとインテリセンスが効かない
のも嫌だなぁというのをなんとか解決する話。

GOROOTを.bash_profileに設定する。

 export GOROOT=/usr/local/opt/go/libexec

.bash_profileにcode .とうつと起動するように仕込みを入れる。

code () {
    if [[ $# = 0 ]]
    then
GOPATH=$(pwd)
        open -a "Visual Studio Code"
    else
GOPATH=$(pwd)
        [[ $1 = /* ]] && F="$1" || F="$PWD/${1#./}"
        open -n -a "Visual Studio Code" --args "$F"
    fi
}

exportしないでGOPATHをワークスペースに設定しておく。
こうすると、vs.codeで自前パッケージのインテリセンスが有効になる。

起動後に.vscode下にtasks.jsonを作る。
以下のような感じ

{
    "version": "0.1.0",
    "command": "go",
    "showOutput": "always",
    "options": {
        "env": {
            "GOPATH": "${workspaceRoot}"
        }
    },
    "tasks" :[
        {
            "taskName": "build",
            "args": ["-v"],
            "isBuildCommand": true
        },
        {
            "taskName": "run",
            "args": ["-v"]
        },
        {
            "taskName": "test",
            "args": ["-v"],
            "isTestCommand": true
        }
    ]
}

options/env下にGOPATHを${workspaceRoot}で設定しておくのがポイント。
ワークスペース以下のフォルダ構造は以下のような感じにする。

${workspaceRoot}
    /pkg/... → ここの下に.aファイルが勝手にできる
    /src/[パッケージフォルダ]
    mainパッケージのファイルはベタ置き

デメリットはgo getしたやつは個別のワークスペースに展開されるので
ファイルサイズが大きくなる。
けれど、今時ならOKOKということで。

2017/01/11 追記
src下にmain.goを置くとデバッグできないのはdleveのバグっぽいが試していない。

2016年5月6日金曜日

Xamarin.Formsでカスタムコントロールを作るメモ

Xamarin.Formsでのカスタムコントロール構築

  • 共通プロジェクト側で、BoxViewを継承したクラスを作る
  • BoxViewを継承したクラスをメインのXamlページではっつける
  • プラットフォーム毎のプロジェクトでBoxViewの中を描画するためのRendererクラスを作る
// 例)
public class CustomControlClass : BoxView
{
}

RendererクラスのiOS/Android共通の要件は以下の通り。

  • assembly:ExportRenderer属性を設定する。
  • 例)[assembly:ExportRenderer(typeof(ShapeView), typeof(ShapeRenderer))]

RendererクラスのiOS固有の要件は以下の通り。

  • iOSの場合、VisualElementRenderer<>から継承する。 (Xamarin.Forms.Plarform.iOS名前空間で定義)
  • VisualElementRendererの型引数はターゲットとするViewBoxを継承したクラス。
  • Rendererクラスでは、Drawメソッド内にコントロール固有の描画コードを記述する。
//例)
[assembly:ExportRenderer(typeof(CustomControlClass), typeof(CustomControlRenderer))]
namespace Hoge.iOS
{
  public class CustomControlRenderer : VisualElementRenderer<CustomControlRenderer>
  {
    public override void Draw(System.Drawing.RectangleF rect)
    {
        // specify draw code here.
    }
  }
}

Android固有のRendererクラスの要件

  • Androidの場合、ViewRenderer<>から継承する。(Xamarin.Forms.Plarform.Android名前空間で定義)
  • ViewRenderer<>の型引数は2つで、一つ目は共通プロジェクトで定義したBoxViewを継承したクラス、2つ目は実際にコントロールの中身を描画するViewを継承したクラス(ここでは、CustomControlViewクラス)
// 例)

[assembly:ExportRenderer(typeof(CustomControlClass), typeof(CustomControlRenderer))]
namespace Hoge.Android
{
    public class CustomControlRenderer : ViewRenderer<CustomControlClass, CustomControlView>
    {
        protected override void OnElementChanged(ElementChangedEventArgs<CustomControlClass> e)
        {
            base.OnElementChanged(e);

            if(e.OldElement != null || this.Element == null)
            {
                return;
            }

            SetNativeControl(new Shape(Resources.DisplayMetrics.Density, Context)
            {
                ShapeView = Element
            });
        }

    }
}
  • Viewクラスの実装はOnDrawメソッド内でコントロール固有の描画コードを記述する。
// 例)
public class CustomControlView : Android.Views.View
{
    protected override void OnDraw(Canvas canvas)
    {
        // ここに固有の描画コードを記述する。
    }
}

カスタムコントロールの貼り付け方

共通クラスで書きます。
// 例) ここは前述の通り。

namespace Hoge
{
    public class CustomControlClass : BoxView
    {
    }
}
次に、これを使うxamlファイルは以下のように書きます。
<!--
    Hogeというアセンブリにカスタムコントロールが含まれている前提
-->
<ContentPage
    ....
    xmlns:ctrls="clr-namespace:Hoge;assembly=Hoge">

    <StackLayout>
        <ctrls:CustomControlClass />
    </StackLayout>
</ContentPage>